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 ([email protected]) 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
