-
Notifications
You must be signed in to change notification settings - Fork 690
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stale Ansible SSH control master failures in securedrop-admin install #4364
Comments
2 tasks
eloquence
added a commit
that referenced
this issue
Apr 25, 2019
These instructions should be removed once #4364 is reliably resolved.
1 task
emkll
added a commit
that referenced
this issue
Apr 25, 2019
[docs] Add instructions for deleting ~/.ansible/cp to work around #4364
kushaldas
pushed a commit
that referenced
this issue
Sep 25, 2019
These instructions should be removed once #4364 is reliably resolved.
I ran into this a while back, see #5042 (comment) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
When running
securedrop-admin install
, steps immediately after reboots of the servers can fail with errors likeTimeout (62s) waiting for privilege escalating prompt
, as Ansible's SSH control masters are stale.This might be related to #4358, though it's not clear if all SSH failures happen after reboots.
Steps to Reproduce
I was able to reliably induce this problem with a clean install of the 0.12.2 RC, at
Set sysctl flags for grsecurity
, which happens immediately after a reboot.Expected Behavior
That the Ansible playbook could still connect to the servers after they've been rebooted.
Actual Behavior
Instead, it fails as it tries to use the stale SSH control masters.
Comments
An effective fix is already used in
restart-tor-carefully.yml
: the Ansible control path directory is simply removed, preventing communication with the old master processes.The text was updated successfully, but these errors were encountered: