Dirk Heinrichs <dirk.heinri...@altum.de> writes: > I once wrote systemd service files for the KDC and Admin Server for > Exherbo. Maybe they can be used as a starting point.
Some comments on these, since I've been spending a bunch of time looking at systemd lately for some reason..... > [Unit] > Description=Kerberos 5 Admin Server > After=syslog.target network.target After=syslog.target isn't necessary with systemd in Debian, since syslog uses socket activation. It would be very nice to do without After=network.target. The question is what happens if kadmind is started before the network is fully up (if, for instance, IPv6 address negotiation is still in progress). That, in turn, is a question of whether kadmind listens to wildcard addresses, or if it tries to bind to all local addresses (for kpasswd, for instance), and if the latter, whether it handles new addresses coming up after it's started. > [Service] > PIDFile=/run/kadmind.pid > ExecStart=/usr/sbin/kadmind -P /run/kadmind.pid Type=simple ExecStart=/usr/sbin/kadmind -nofork $DAEMON_ARGS would be better, assuming there isn't some problem with -nofork mode of which I'm unaware. For Debian, we'll also need: EnvironmentFile=/etc/default/krb5-admin-server There's also the RUN_KADMIND flag in /etc/default/krb5-admin-server. My preferred solution to this is what I did with lbcd: on upgrade of the package, have postinst call update-rc.d krb5-admin-server disable if RUN_KADMIND is set to false, and then document (in NEWS) that people should just use update-rc.d krb5-admin-server disable going forward. This is the correct way to disable a service and works with all supported init systems. > [Unit] > Description=Kerberos 5 Key Distribution Center > After=syslog.target network.target Similar comments here about both of these. > [Service] > PIDFile=/run/krb5kdc.pid > EnvironmentFile=/etc/conf.d/krb5kdc.conf > ExecStart=/usr/sbin/krb5kdc -P /run/krb5kdc.pid $KDC_ARGS In Debian: PIDFile=/var/run/krb5-kdc.pid EnvironmentFile=/etc/default/krb5-kdc ExecStart=/usr/sbin/krb5kdc -P /var/run/krb5-kdc.pid $KDC_ARGS In both cases, it would be good to send upstream patches to support socket activation and then add socket units, since that will make it way easier for the administrator to configure the listening sockets. krb5kdc could use a "don't fork" option so that the PID file workaround isn't required. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
