Hi mentors,
[I'm on list]
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)?
Other 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
Thank you
Lukas Schwaighofer
Attachment:
pgpU1GPVzJdSI.pgp
Description: OpenPGP digital signature