Manual review of logsync snap

jdstrand · December 3, 2019, 7:32pm

jamesj:

This uses a built-in feature of systemd to allow logs to be sent to a remote systemd log service. The journal-upload.conf has the URL of the remote service and can also define the location of TLS certs to allow the connection to be over HTTPS.

@ogra has modified the approach in the snap so we don’t need full read access to /etc/systemd . Does that change your view on the snap?
plugs:
  config-logsync:
    interface: system-files
    write:
      - /etc/systemd/journal-upload.conf
I can request this in a separate forum post as a suggestion for snap set as well.

This seems reasonable for the snap, but in Change in logging behaviour on Ubuntu Core there was discussion that core itself might ship systemd-journal-remote itself and allowing the use of system-files as specified for this snap might break that functionality. @pedronis can you comment? This could potentially be avoided by disallowing the snap write access to /etc/systemd/journal-upload.conf and having the user have to write out /etc/systemd/journal-upload.conf for the snap to read (at least then, it is an overt administrative action).

Also, I’m not familiar with systemd-journal-remote specifically, but can say that journald’s binary log format is not compatible with other versions of journald (eg, a core 16 journalctl can’t read core 18’s binary log format). Does systemd-journal-remote not suffer from these problems? If so, can you detail how it will behave correctly and robustly when, say, an Ubuntu Core 18 system uses this snap to send logs to a Debian system? An Ubuntu 16.04 LTS system? An Ubuntu 20.04 LTS system? A RHEL system?

Similarly, this snap will be installable anywhere-- how will its systemd-journal-remote work with the binary log format on the host for other versions of systemd?