Ansible scripts depend on English locale

[sigvei]

Description

After the upgrade to xenial and 0.12.0, ./securedrop-admin install fails on the ‘tor-hidden-services: Ensure correct Tor version installed’ step.

It turns out both app and mon had /etc/default/profile written with some local locale settings (LANG=nb_NO.UTF-8). The unprivileged user does not use these settings, but when the ansible script escalates privileges, env is set with this locale. This, in turn, makes the script in ansible_base/installed_files/ansible_base/tor-hidden-services/tasks/install-tor.yml fail, because it explicitly tests for installed.

I am not sure why the default profile was written this way, or why it changed between versions of Ubuntu. I do however believe I had to set the keyboard langauge during initial setup (due to an automated password with characters I had no idea how to type on an English keyboard with a physical Norwegian layout). I know I could possibly have changed the keyboard layout without changing the locale, but the docs did not instruct me to not change it. Anyway, I don't think it's good to require users to keep the locale at English, and that locale-dependent scripts should be fixed.

A possible replacement for manually parsing apt-cache is apt-list, which has a slightly less human output.

[zenmonkeykstop]

Replicated, error message is:

TASK [tor-hidden-services : Ensure correct Tor version installed.] *************
fatal: [app]: FAILED! => {"msg": "The conditional check 'extract_tor_version.stdout is version('0.3.4.9', '>=')' failed. The error was: Version comparison: LooseVersion instance has no attribute 'version'"}
fatal: [mon]: FAILED! => {"msg": "The conditional check 'extract_tor_version.stdout is version('0.3.4.9', '>=')' failed. The error was: Version comparison: LooseVersion instance has no attribute 'version'"}

[zenmonkeykstop]

Replicated as follows (against an existing Trusty instance for expediency's sake):

• installed Ubuntu 14.04 on mon server, selecting Norwegian/Nyorsk as language, Noreg as locale
• this resulted in a /etc/default/locale like:

LANG="nn_NO.UTF-8"
LANGUAGE="nn_NO:nn:no_NO:no:nb_NO:nb:en"

• nuked ssh-over-tor config for mon to allow for a run of the playbook against it
• ran ./securedrop-admin install, generated above error for mon server only (as expected)
• sshed to mon (user@ip) and ran sudo update-locale LANG=, which changed /etc/default/locale to:
  LANG= #LANGUAGE="nn_NO:nn:no_NO:no:nb_NO:nb:en"
• then ran ./securedrop-admin install, which completed successfully

It should be safe to restore locale settings after the fact if required, but as the Ansible playbook stands it would be necessary to change locale settings again before each securedrop-admin install run.

Locale behaviour after a do-release-upgrade run still needs to be tested.

[rmol]

I believe I've worked out how to control the locale during Ansible execution, so that the servers can be installed with a non-English locale. This should mean there'll be no need for changing the locale just to run securedrop-admin.

It does of course mean that command output will be in English, but given that all of the Ansible output is in English, this shouldn't greatly reduce the usability. There are also a few new warnings about the raw module not supporting the environment keyword; this is because the environment module is being used at the top of plays, and the warnings are harmless.

I've tested it on fresh Trusty installs in a few locales (no, de, fr) and checked it again after upgrading to Xenial. It seems to work throughout.