Securedrop: ./securedrop-admin sdconfig failure on SMTP host checking

[kushaldas]

Bug

Description

Some random times, the ./securedrop-admin sdconfig command fails on validation on SMTP .

Steps to Reproduce

.$ ./securedrop-admin sdconfig

Expected Behavior

It should pass.

Actual Behavior

TASK [validate : Perform SMTP lookup check.] *******************************************************************
fatal: [localhost]: FAILED! => {"changed": false, "cmd": ["torify", "host", "-W=10", "-R=3", "-T", "-4", "smtp.gmail.com", "8.8.8.8"], "delta": "0:00:03.061367", "end": "2017-12-20 17:55:05.760958", "failed": true, "rc": 1, "start": "2017-12-20 17:55:02.699591", "stderr": "", "stderr_lines": [], "stdout": ";; connection timed out; no servers could be reached", "stdout_lines": [";; connection timed out; no servers could be reached"]}
...ignoring

TASK [validate : Validate SMTP relay connection.] **************************************************************
fatal: [localhost]: FAILED! => {
    "assertion": "'has address' in smtp_validate_result.stdout", 
    "changed": false, 
    "evaluated_to": false, 
    "failed": true, 
    "msg": "The SMTP relay domain failed during lookup. This domain is the server contacted for authentication in order to send OSSEC email notifications. You should manually edit the file `group_vars/all/site-specific` and confirm that the `smtp_relay` var is set correctly."

Comments

We can remove the whole validate or something similar.

[conorsch]

Marking as ignore_errors: yes seems the sane approach here, so we still inform the Admin, but don't abort execution of the install. However, the rewrite in #2758 means we'll need another strategy, so let's wait until that's merged to tackle this error.

[redshiftzero]

If we hit this during 0.5.1 QA, I suggest we add ignore_errors: yes to the Validate SMTP relay connection task (as @conorsch suggests) for 0.5.1, as this has been reported as a source of frustration by current admins

[conorsch]

I've already hit this error during QA, and encourage the stopgap solution of setting ignore_errors: yes. After release, we can circle back and attempt a more elegant solution that provides "warning" messages (via debug) to Admins.

[eloquence]

Since we've disabled this check and don't see high importance of re-enabling, @conorsch @redshiftzero and I agreed to close this issue for the time being.