>>>>> "Russ" == Russ Allbery <[email protected]> writes:
Russ> The real long-term solution is to convert both services to use
Russ> systemd socket activation.
Josh Tripplet (SP?) and I had a long conversation about socket
activation at Debconf.
my position is that socket activation is a bad choice for network
services where the primary user of the socket is non-local. The issue
is that inherently socket-activation requires the socket configuration
to live in systemd.
That involves splitting configuration between systemd and the service.
I have the information on where to listen in systemd and the information
on how to configure the sockets in a service specific manner still in
the service's configuration.
To make matters worse, this configuration can get out of sync.
To me, the harm of duplicating configuration information, splitting
configuration information and allowing configuration to get out of sync
is far worse than the complexity of other dependency management
strategies.
Amusingly, krb5-kdc is one service where there really is very little
per-socket configuration, so with the current code base, my argument
doesn't particularly apply for krb5-kdc. (Josh and I were discussing
RADIUS, where it very much does apply.) My argument does seem to apply
to web services, slapd, etc.
So, yeah, it seems like socket-activation could be a solution for
krb5-kdc for the simple reason that krb5-kdc has too poor of a
configuration experience to make it a bad idea.
--Sam
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
