Improve packaging practices related to Systemd

[mbainter]

Goal

Align closer to packaging best practices, particularly in regard to how the service is managed. Allow those deploying the software to have better control over that without wrestling with the package.

Context

I ran into this same problem with Kolide. NFPM is great, but a little effort into implementing good packaging practices for something like this would be greatly appreciated. Right now, the package you provide is exceedingly basic. In particular:

• In postrm it deletes everything no matter what. It should remove the core package and leave the configuration and and osquery database unless the purge flag is set.
• After install, it does a daemon-reload and start without honoring local presets.
• Because it doesn't do any checking, on any upgrade or reinstall of the package it will similarly overwrite the local configuration

If I, as a systems administrator, want to deploy an override file that governs how osquery runs, I end up in a race condition with the current package. I have to write automation around the package install to:

1. prevent osquery from making connections
2. install the package
3. stop the service
4. delete any initial data from osquery
5. deploy the override file
6. remove network restrictions
7. enable/start the service

If, instead, these packages were built in accordance with Debian/Ubuntu packaging guidelines and systemd recommended practices, I could do:

1. call systemctl preset orbit disable
2. Install fleet-osquery.deb
3. Deploy override file
4. call systemctl preset orbit enable
5. enable/start orbit

It would be nice if NFPM supported this natively as a best-practice for anything with a service, but it does allow you to customize your pre/post inst/rm scripts and that's enough to implement this. It would just require a little bit of effort to leverage the built-in tools like deb-systemd-helper.

Potential solutions

These are untested -- they're just rough outlines of what this might look like.

honoring presets in postinst:

  if deb-systemd-helper debian-installed 'orbit.service'; then
    if deb-systemd-helper --quiet was-enabled 'orbit.service'; then
      deb-systemd-helper enable 'orbit.service' >/dev/null || true
    fi
    if deb-systemd-helper --quiet was-enabled orbit.service; then
      deb-systemd-invoke restart orbit.service
    if
    deb-systemd-helper update-state 'orbit.service' >/dev/null || true
  fi  

handling purge and cleanup in postrm:

  rm -rf /usr/local/bin/orbit /etc/default/orbit /opt/orbit
  if [ "$1" = "purge" ]; then
    deb-systemd-helper purge 'orbit.service' >/dev/null || true
    rm -rf /var/lib/orbit /var/log/orbit
  fi

[jamesps-ebi]

I agree there could be improvements to these workflows. The postrm script in fleet-osquery_1.17.0_amd64.deb has this content:

#!/bin/sh

rm -rf /var/lib/orbit /var/log/orbit /usr/local/bin/orbit /etc/default/orbit /usr/lib/systemd/system/orbit.service /opt/orbit

This is causing any customisation in /etc/default/orbit to be removed on every upgrade. So I don't think that /etc/default/orbit should be touched at all during install/upgrade unless it doesn't already exist.