Re: arpwatch & systemd
Hello,
>since I'm using arpwatch and it has been orphaned for a while now, I am
>thinking about adopting this package. I've started picking a few
>easy enough bugs in the BTS and fixed them. Before I'm ready to
>officially declare my intent I wanted some advice in particular on
>supplying systemd unit files for this package (other feedback is
>welcome as well of course).
>
>The current LSB init script checks /etc/arpwatch.conf for lines
>matching '^[a-z]'.
>
>* If there are any, it uses a multi instance mode using information
> from this configuration file to add additional parameters (in
> addition to what is read from /etc/default/arpwatch) as command
> arguments (which may be different for the interfaces)
>* If there are no such lines, it will just use the parameters
> from /etc/default/arpwatch to start one instance of arpwatch.
>
>Note that /etc/arpwatch.conf is not a "usual" configuration file in that
>it is never read by arpwatch but only by the init system to construct
>the arguments to be passed to arpwatch when executing.
>
>Thoughts on about how to provide a systemd unit file (inspired a lot by
>how openvpn handles multiple instances):
>* I want the processes for different interfaces supervised individually
> by systemd; the only way how to do this I know about is to supply
> a template unit file (arpwatch@.service) which can be
> instanciated with an instance name (which will in my case be an
> interface name).
>
>* I want to keep supporting different parameters for the different
> instances; the easiest way to support this seems to be using the
> EnvironmentFile directive, with allows to use the contents of the
> variables when invoking arpwatch; however, this means I need a
> separate configuration file for each interface.
>* I do not consider starting arpwatch without the `-i` parameter to
> specify an interface useful (it uses pcap_lookupdev in that case,
> which allows you to find "the default" device on which to capture,
> for whatever that means). I think that people running arpwatch
> should have an opinion on which network interface arpwatch should run
> on.
>So what I have done is:
>* I've dropped the "one instance" mode as I always want to have the
> interface(s) specified, even if it's only one.
>* I've converted /etc/arpwatch.conf to individual configuration files
> in /etc/arpwatch/IFNAME.iface which have a shell source-able syntax
> (I've adjusted the LSB init script accordingly) and can be used with
> systemd's EnvironmentFile= directive.
>* Consequently there is no /etc/arpwatch.conf any more, I removed it.
>* As I don't know which interface the admin is going to use, I cannot
> provide a "default" configuration file with helpful comments. As a
> current workaround I have created an /etc/arpwatch/README file which
> briefly explains the interface configuration.
>* I've added an INTERFACES= variable to /etc/default/arpwatch:
> - This allows specifying which interfaces to run on, but is only used
> by the LSB init script and ignored by systemd.
> - For systemd I expect the administrators to explicitly enable and
> start the instantiated unit files using systemctl; alternatively
> we could write a generator for systemd, similar to what openvpn
> does, to activate all the instances specified in INTERFACES.
>
>I would like advice on the concept itself: Is it ok or should a take a
>different approach? Can someone point me to a package that handles a
>similar service startup situation differently (better)?
>
O>her than that I'm quite concerned about the upgrade path:
>* I do remove /etc/arpwatch.conf from the package (but this will of
> course stay in the filesystem); converting this into individual files
> in /etc/arpwatch/IFNAME.iface in a maintainer script would be
> possible…
>* I have a README file in /etc/arpwatch/ which is not a configuration
> file. Is there a better solution and, if not, would this be
> acceptable?
>* After the upgrade, the service has to be explicitly activated for the
> interfaces it should be started on, even if the service was
> previously running (again, could be handled in a maintainer script
> at least for some cases, but is not easy to do considering how the
> different init systems need a different form of activation)
>* In any case I do not think that we can offer a seamless upgrade path
> for all cases.
>
>Sorry for the wall of text. You can find the current status in the
>following git repository in the *staged-changes* branch (this is
>work-in-progress and will see force commits):
>https://git.somlen.de/arpwatch.git
before having a deep look (and I won't until you request an RFS sponsorship,
I have a question:
did you consider to merge the work from Fedora?
they already have a systemd service, and IIRC the project seems somewhat dead upstream,
so merging their work and sending them patches might be beneficial for both distros.
Please try to have a similar working tool, rather than diverging too much,
specially when upstream is not active anymore.
I don't think you want people having issues when switching from Fedora to Debian and
vice-versa, specially with systemd configuration files :)
(as pkg-security team we might have some interests in having the package under our team,
so you might find sponsors asking us to review your work!)
TIA
Just my .02$
Gianfranco
Reply to: