>>>>> "Russ" == Russ Allbery <r...@debian.org> writes:
Russ> Sam Hartman <hartm...@debian.org> writes:
>> 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.
Russ> That's actually one of the things that I like about it. From
Russ> a systems administration perspective, I would far rather
Russ> configure all of the sockets in one place with one syntax
Russ> rather than fighting with obscure flags and configuration
Russ> formats to configure this separately for every service in some
Russ> unique, special snowflake way. That's particularly true given
Russ> that most services do not support properly configuring
Russ> sockets. For example, I usually can't set IPv6 freebind, I
Russ> often can't even configure three bind addresses but not all
Russ> addresses, I often don't have control over whether IPv6 gets
Russ> IPv4-mapped addresses, and so forth.
I,'d agree with that if all you had to specify was which sockets to
listen on.
Most services however don't treat all sockets equally.
Web servers have entirely different vhost configuration per socket.
I believe slapd can have separate tls configurations per socket but it's
been a while since I've dived through the slapd configuration mess.
Basically my claim is that socket activation is great for cases where
all the configuration about the socket can be specified in systemd and
dreadful elsewhere.
--Sam
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
