note that none of the interface stuff would be necessary if /etc/systemd/journal-upload.conf could be re-mapped inside the snap via a layout (which is forbidden due to its location). it would also not be necessary to worry if the file exists on the host already in this case …
i wonder if the layouts code couldnt just whitelist this particular file for re-mapping and we could forget about the interface at all …
Having the remote journal export configuration as an option in snapd may be a better long-term approach. This snap may help to fill a gap in the short-term.
Well, adding the binary to core/core18/core20 and exposing the config via snap set should be able to go fast once people have decided that is the direction (it after all wouldn’t be tied to a snapd release).
well, given the fact that you need to import a bunch of certificates to gain https forwarding, i fear it wont be that fast.
plain http is surely quick though (just an on/off toggle in the config), but for https we need a configuration tool that imports the certs into the system.
I’m thinking about this as basically a request for remote syslog support, and traditional remote syslogging does not use certificates, so, IME, adding plain immediately and then adding certificate support later seems ‘ok’. This is just my opinion of course and will defer to @pedronis and the snapd team’s plans in this area.
Wouldn’t something like this side-step the issues for a while:
layout:
/etc/systemd/journal-upload.conf:
bind-file: $SNAP_DATA/etc/journal-upload.conf
(that’s one the original use cases for layouts)
Then the snap doesn’t need afaict system-files and it will have “snap set” ways to write the config.
it would, if it was allowed, /etc/systemd is a protected path it seems, that is what i meant above regarding white-listing.
I tried and seems to work, and afaik it isn’t:
well, i got an error message at snap install time, i’ll have to re-build the snap with layout to give you the exact error message i got on the core18 system i tried it on …
will report back with the error as soon as i have that …
here is the error:
$ sudo snap install --dangerous logsync-james_0.2_amd64.snap
error: cannot perform the following tasks:
- Run configure hook of "logsync-james" snap if present (run hook "configure":
-----
cannot update snap namespace: cannot write to "/etc/systemd/journal-upload.conf" because it would affect the host in "/etc/systemd"
snap-update-ns failed with code 1: File exists
-----)
using snapcraft.yaml and configure hook as in:
I dug a little deeper, seems the above happens when the target file does not exist at all.
It seems bind-mounting the whole of /etc/systemd in the layout instead works with some additional changes to the configure hook … I created a PR for @jamesj to merge that should make the package go through without manual review… (we might want to ask for auto-connections of the interfaces though, up to james)
It looks like things start to work with the bind: $SNAP_DATA/systemd layout (great!). I noticed the snap is called ‘logsync-james’. Is this meant to be an officially supported snap or technique (thinking through my own and others use (ref. Change in logging behaviour on Ubuntu Core))
i just uploaded https://snapcraft.io/logsync-receiver and will write a doc here in the forum how to set up both sides (well, essentially you only need to set the ip on the client with a snap set command).
i think initially james only wanted to make a proof of concept … but given how well this setup actually works and how easy it is the client snap should probably be re-named to logsync 
i created
Exactly, it was just a proof-of-concept to show an approach to remote debugging a device. I guess I could rename it now that @ogra has removed the need for the system-files interface.
Some of these I find interesting. I suggest once the name is changed, following Process for aliases, auto-connections and tracks and we can discuss why it needs some of these interfaces.
the exotic ones (time-control, daemon-notify, network-control) are just for quietening systemd log spam, they are technically not needed for the app to work …
dropping everything but log-observe, network and network-bind gets me the following log output (yet with a properly working app):
Dez 14 12:37:13 anubis systemd[1]: Started Service for snap application logsync-james.upload.
Dez 14 12:37:13 anubis audit[9713]: AVC apparmor="DENIED" operation="open" profile="snap.logsync-james.upload" name="/proc/1/environ" pid=9713 comm="systemd-journal" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Dez 14 12:37:13 anubis audit[9713]: AVC apparmor="DENIED" operation="capable" profile="snap.logsync-james.upload" pid=9713 comm="systemd-journal" capability=12 capname="net_admin"
Dez 14 12:37:13 anubis audit[9713]: AVC apparmor="DENIED" operation="sendmsg" profile="snap.logsync-james.upload" name="/run/systemd/notify" pid=9713 comm="systemd-journal" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
Dez 14 12:37:13 anubis audit[9713]: AVC apparmor="DENIED" operation="sendmsg" profile="snap.logsync-james.upload" name="/run/systemd/notify" pid=9713 comm="systemd-journal" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
Dez 14 12:37:13 anubis kernel: audit: type=1400 audit(1576323433.449:4075): apparmor="DENIED" operation="open" profile="snap.logsync-james.upload" name="/proc/1/environ" pid=9713 comm="systemd-journal" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Dez 14 12:37:13 anubis kernel: audit: type=1400 audit(1576323433.449:4076): apparmor="DENIED" operation="capable" profile="snap.logsync-james.upload" pid=9713 comm="systemd-journal" capability=12 capname="net_admin"
Dez 14 12:37:13 anubis kernel: audit: type=1400 audit(1576323433.449:4077): apparmor="DENIED" operation="sendmsg" profile="snap.logsync-james.upload" name="/run/systemd/notify" pid=9713 comm="systemd-journal" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
Dez 14 12:37:13 anubis kernel: audit: type=1400 audit(1576323433.449:4078): apparmor="DENIED" operation="sendmsg" profile="snap.logsync-james.upload" name="/run/systemd/notify" pid=9713 comm="systemd-journal" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
I am also observing similar “sendmsg - denied” messages with my snap .Can we ignore this error messages in a strict confinement?
This thread is very old @jithcr - please feel free to open a new thread under the snap category for help with that.