Hello,
I’m looking at create a snap package of Suricata, but I have some questions that I have not been able to find answers to, or just need some feedback on.
First Suricata is a network monitoring app, it uses af-packet or lipcap to open an interface.
It typically runs as a daemon (via systemd) and like accesses the following files:
- configuration files in /etc/suricata
- log files in /var/log/suricata (stuff NOT suitable for systemd journal)
- various other cache and state in /var/lib/suricata
So far my snap includes the configuration files in the snap, but they are not usable. Would I use some sort of hook to copy these into $SNAP_DATA, then the user can edit them there?
For logging, it looks like I should log to $SNAP_DATA as well? Again, this isn’t normal application logs you might have systemd handle. This is alert logging, file extractions, and so on.
And finally for the cache data, I’m guessing $SNAP_DATA again?
I’d like to use the snap daemon feature for launching this as a daemon as well. Is there an equivalent to systemd’s environment file to pull in some user settings from a file like /etc/default/suricata? Before running as a daemon there is one important parameter that must be set (the interface to listen on) for the application to work.
For my test snap, I’m using strict confinement, but still appear to be able to listen on the interface. is this expected?
And finally, we maintain 2 releases of the code and don’t want to force users to upgrade until they are ready. For example, a user may decide to stay on 4.1 even though 5.0 is out. Is there where tracks come into play? Everytime we do a new release (not patch releases) we’d request a track for that new release. For example, we’d start off requesting tracks 4.1 and 5.0… And when we release, 6.0 for example, we’d request that track?
Also, pointers to any snaps that may do any of the above would be useful.
Thank you for any input!