Repository: freedomofpress/securedrop

Issue #4358: Ansible commands sometimes fail with "waiting for privilege escalation prompt"
Created: 2019-04-19T23:31:15Z
When you run a command like securedrop-admin logs -- a fairly simple playbook -- the playbook may sometimes fail with the error "Timeout (62s) waiting for privilege escalating prompt:" on both app and mon, even though both servers are reachable via ssh app and ssh mon from the same workstation.
Removing the ~/.ansible directory on the Admin Workstation resolves and ensures successful playbook run, so this appears to be related to Ansible control-path files as previously described in #1957.
Unfortunately no clear steps to reproduce yet; I've encountered it once today after running the logs command twice, with no significant difference in the two runs, so it may be related to Tor network issues as well.

Duplicate issue #5042: continuously having to retry 'securedrop-admin install' [ansible running out of hosts]
Created: 2019-11-27T02:56:59Z
Description
Testing: https://github.com/freedomofpress/securedrop/releases/tag/1.2.0-rc1
./securedrop-admin install fails with following:
TASK [common : Add disabled kernels modules to modprobe.d blacklist.] **********
ok: [mon] => (item=btusb)
fatal: [mon]: FAILED! => {"msg": "Timeout (62s) waiting for privilege escalation prompt: "}
ok: [app] => (item=btusb)
ok: [app] => (item=bluetooth)
ok: [app] => (item=iwlmvm)
ok: [app] => (item=iwlwifi)

NO MORE HOSTS LEFT *************************************************************

NO MORE HOSTS LEFT *************************************************************
        to retry, user: --limit @/home/amnesia/Persistent/securedrop/install_files/ansible-base/securedrop-prod.retry

PLAY RECAP *********************************************************************
app                        : ok=59    changed=1    unreachable=0   failed=0
localhost                  : ok=11    changed=0    unreachable=0   failed=0
mon                        : ok=58    changed=1    unreachable=0   failed=1

More info
Why does one have to retry the install X number of times in order to get it to work?
I'm working on QA for nuc7 testing (see #5004). I ran the installer earlier today when testing v2 onion addresses, which failed a couple times because of the error above. When I turned on v3 onion addresses and ran the installer, I consistently began seeing this error.
The instructions in the securedrop-admin output say:
 to retry, user: --limit @/home/amnesia/Persistent/securedrop/install_files/ansible-base/securedrop-prod.retry

But --limit is not an option for securedrop-admin so in order to try this you have to modify the
ansible-playbook call in the installer... probably.... here: https://github.com/freedomofpress/securedrop/blob/5fab77394a7af02cf00aa851a25eff6f7c8468dd/admin/securedrop_admin/__init__.py
Steps to Reproduce

run ./securedrop-admin install for v2
run ./securedrop-admin install for v3

(It might just be that you have to run it multiple times.)
Expected Behavior
There should be an easy way to pass the limit option to the installer. Also I'd like to run the final task separately so I don't have to wait so long to get there since very little is changing as you can see in the output above.
Actual Behavior
There isn't an easy way for an admin to specify ansible limit option as the instructions tell us to do.

Closing comment (2019-12-03T20:39:55Z): Closing as duplicate of #4358/#4364 but adding #4364 to nominations for next sprint as this one comes up a lot and we have a WIP fix in #4366.