[xenial] Reinstate LTS upgrade notification

[eloquence]

In #3546, we set Prompt to never in /etc/update-manager/release-upgrades to suppress premature OSSEC notifications. In order to perform the update to Xenial via do-release-upgrade, it needs to be reset to lts. We can do so in postinst so the admin does not have to do it manually.

To avoid spurious 18.04 notifications, this should be done on Trusty, while on Xenial Prompt should be set to never. We can inspect lsb_release -sc to avoid forking the build logic.

As a stretch goal, we should consider customizing the OSSEC notification that will be sent to 14.04 users. The default notification will say:

/etc/cron.weekly/update-notifier-common:
New release '16.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Ideally, the notification should point to:

https://securedrop.org/xenial-upgrade

This is the redirect also pointed to via #4055. Having the OSSEC alert point to this link will help prevent admins from attempting the upgrade without following the documentation.

Part of #3204.

[heartsucker]

There are two ways we could do this, and I want some feedback from the team on how we should do this.

sed / perl / grep / etc

We can do something like:

if ! grep -q 'Prompt=never' /etc/update-manager/release-upgrades; then
    echo 'Prompt=never' >> /etc/update-manager/release-upgrades
fi

Which will very likely do the right thing since that file isn't being changed or updated very often. However, if extra configs are added or sections or anything, it may break

Use crudini

There is a CLI tool available on Ubuntu called crudini that allows us to read and set config options from INI files. For eample

crudini --set /etc/update-manager/release-upgrades DEFAULT Prompt never

To make this available, we add this to the Depends section in the control file. This feels like the most robust way to manipulate INI files, and what I prefer. However, I can understand the desire to keep the dependencies as minimal as possible.

---

I would be curious to hear what @conorsch, @emkll, and @redshiftzero have to say about this.

[redshiftzero]

For approach 2 (crudini): recall that we have outstanding issue #3376, i.e. we can't actually add an apt dependency unless it's in /etc/apt/security.list. which unfortunately it looks like the package you're referring to isn't 😢 - so for 0.12.0, this is a no-go.

That means that approach 1 (sed) is the name of the game, i.e. updating the securedrop-config postinst logic we added in PR #3546.

Regarding the OSSEC alert (which would be realllly good to modify as there is a danger that admins see the alert prior to our upgrade guide which will contain additional instructions of what to do), we'd want to add a rule to install_files/securedrop-ossec-server/var/ossec/rules/local_rules.xml, something similar to this should do the trick.

[heartsucker]

Ah yeah, right about #3376. D'oh. sed it is then.

[conorsch]

Agreed that we should substitute in-line, rather than parse the INI format. We should avoid appending to the file via >>, since we can safely expect the line to be there, given previous config munging. See the approach introduced in #3546; we should update that logic to enforce the new expected state, honoring Trusty/Xenial behaviors.