Created attachment 378528 [details] systemd service file Attached are some files to make net-analyzer/darkstat works with the new systemd init. I could not make the pid file parametrable, not sure why but the ExecStopPost does not work with an environement variable, preventing the service to restart. The original configuration had the --no-promisc flag by default, you may want to set it back. Also I have put the configuration file in /etc/sysconfig/darkstat, not sure if this is where you guys want to put it.
Created attachment 378532 [details] Configuration file
Comment on attachment 378532 [details] Configuration file ># darkstat base configuration Where should this configuration file be stored? /etc/sysconfig/darkstat by the looks of it. Is that a valid path for a systemd service environment file? > >#The interface darkstat is going to monitor >INTERFACE="eth0" As opposed to the openrc scripts, this script does not explain how to run several instances of darkstat on different interfaces. ># Other options: >#DARKSTAT_OPTS="--no-promisc --no-dns --user darkstat" >DARKSTAT_OPTS="--no-dns --user darkstat" Looks like a local change to the defaults (as in files/darkstat-confd) that perhaps should not have leaked here. > ># The directory to which the program chroots after initialization. ># If you change this, please note the variable below and adjust ># the permissions accordingly. Note that if you want to use the ># --daylog option in EXTRAOPTS, the files are logged relative ># to the chroot-directory; see the man-page for details. >CHROOT=/var/lib/darkstat >
(In reply to Jeroen Roovers from comment #2) > ># The directory to which the program chroots after initialization. > ># If you change this, please note the variable below and adjust > ># the permissions accordingly. Note that if you want to use the > ># --daylog option in EXTRAOPTS, the files are logged relative > ># to the chroot-directory; see the man-page for details. > >CHROOT=/var/lib/darkstat I was going to comment on this, too. 8-) In the ebuild, a lot of work is done in pkg_postinst() to ensure that DARKSTAT_CHROOT_DIR is properly set. However, as that is based on the conf.d file and not the proposed systemd environment file, systemd users could be left with the incorrect directory when DARKSTAT_CHROOT_DIR is read from the installed but unused conf.d file. IIRC resolving it by reading systemd service environment variables from conf.d files is somewhat of a faux pas in systemd land.
(In reply to Jeroen Roovers from comment #2) > Comment on attachment 378532 [details] > Configuration file > > ># darkstat base configuration > > Where should this configuration file be stored? /etc/sysconfig/darkstat by > the looks of it. Is that a valid path for a systemd service environment file? Generally these things are handled with drop-ins in Gentoo. See the latest deluged as an example (there might be better ones but this is the first one I spotted). > > > >#The interface darkstat is going to monitor > >INTERFACE="eth0" > > As opposed to the openrc scripts, this script does not explain how to run > several instances of darkstat on different interfaces. Not sure that they need to be feature-equivalent, but the best way to do that would be with an instantiated service. Fetchmail has an example that is non-trivial to look at. > > > ># The directory to which the program chroots after initialization. > ># If you change this, please note the variable below and adjust > ># the permissions accordingly. Note that if you want to use the > ># --daylog option in EXTRAOPTS, the files are logged relative > ># to the chroot-directory; see the man-page for details. > >CHROOT=/var/lib/darkstat > > You'll probably want to use RootDirectory for this. I'm not sure if the pid file removal is necessary with systemd but if so then you'll need to set RootDirectoryStartOnly=true so that the post-exec command isn't jailed. Systemd also has a myriad of containerization features that might be a better option than chroot, but RootDirectory is the way to do chroot. Just stick it in the drop-in (possibly escaped) and users can do with it as they will. ProtectSystem and ReadWritePaths might be a simpler way to accomplish the same goal, unless you need to restrict reads too. I haven't looked into what this package actually does or what if any work the chroot needs to set up/etc.
