changing configured server hostnames results in duplicate /etc/hosts entries

[cfm]

Description

If the {app,monitor}_hostname values are changed in site-specific after initial installation, the new hostnames will be appended to, rather than updated in, each server's /etc/hosts. As a consequence, the next unattended-upgrades run that happens to pull in a new version of securedrop-ossec-agent will fail.

Yes, this is a bit of a corner case....

Steps to Reproduce

Encountered during #6103:

1. Install the instance (./securedrop-admin {sdconfig,install,tailsconfig}) with incorrect {app,monitor}_hostname values.
2. Correct the {app,monitor}_hostname values in ./securedrop-admin sdconfig and deploy them via ./securedrop-admin install.
3. Await a new SecureDrop version (or do QA for one ;-).

Expected Behavior

Presenting symptom: unattended-upgrades succeeds.

Underlying condition: /etc/hosts contains only the corrected hostnames.

Actual Behavior

Presenting symptom: unattended-upgrades fails on securedrop-ossec-agent:

Preparing to unpack .../securedrop-ossec-agent_3.6.0+2.1.0~rc1+focal_amd64.deb ...                                      
Unpacking securedrop-ossec-agent (3.6.0+2.1.0~rc1+focal) over (3.6.0+2.0.2+focal
) ...                                   
Setting up securedrop-ossec-agent (3.6.0+2.1.0~rc1+focal) ...                   sed: -e expression #1, char 96: unterminated `s' command                        
dpkg: error processing package securedrop-ossec-agent (--configure):
 installed securedrop-ossec-agent package post-installation script subprocess re
turned error exit status 1              
Errors were encountered while processing:                                       
 securedrop-ossec-agent                                                         
E:Sub-process /usr/bin/dpkg returned an error code (1)

Underlying condition: /etc/hosts contains duplicate entries for the original and corrected hostnames:

vagrant@app-prod:~$ cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       app-prod        app-prod

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
192.168.121.245  mon securedrop-monitor-server-alias
192.168.121.245  mon-prod securedrop-monitor-server-alias

Comments

It's probably not worth trying to make securedrop-ossec-agent's postinst script more robust:

securedrop/install_files/securedrop-ossec-agent/DEBIAN/postinst

Lines 23 to 24 in 21a162d

	mon_ip=$(grep -oP "^\\d+\.\\d+\.\\d+\.\\d+(?=.*securedrop-monitor-server-alias)" /etc/hosts)
	sed -i -e "s/<server-hostname>securedrop-monitor-server-alias<\/server-hostname>/<server-ip>$mon_ip<\/server-ip>/g" /var/ossec/etc/ossec.conf

Rather, the Ansible task setup_etc_hosts should ideally change the configured hostnames in place rather than adding them even if they've changed:

securedrop/install_files/ansible-base/roles/common/tasks/setup_etc_hosts.yml

Lines 29 to 38 in 012d30e

	- name: Add local IPv4 addresses for SecureDrop servers to /etc/hosts.
	lineinfile:
	dest: /etc/hosts
	regexp: "{{ item.hostname }}"
	line: "{{ item.ip }} {{ item.hostname }}"
	backup: yes
	with_items: "{{ ip_info }}"
	tags:
	- host_aliases
	- static-hosts

[cfm]

#6103 (comment) suggests that hostname changes may also break related testinfra tests run via securedrop-admin verify.

[conorsch]

We could use a blockinfile call on the /etc/hosts munging to clobber all SD-related changes on Ansible updates, which should resolve. This is definitely a bug, but quite an edge case. During sync today, we decided it doesn't need to be resolved in 2.1.0 final, since it wasn't introduced by logic in that release series.