Bug#877512: slapd: enabled systemd integration (untested patch)

[Ryan Tandy]

On Wed, Jun 28, 2023 at 08:48:14PM +0200, Moritz Mühlenhoff wrote:
>OTOH, moving to the systemd unit might also be a good opportunity to reduce
>some complexity? Looking at slapd.default shipped with the current package
>SLAPD_SENTINEL_FILE, SLAPD_PIDFILE and SLAPD_NO_START are all settings which
>are no longer relevant with a systemd unit or can equally be achieved with
>commands built-in to systemd (e.g. systemctl mask).

Yes, definitely meaning to review and drop at least those, as well as 
migrating /var/run/slapd to tmpfiles.d.

>Then there's a handful of settings which IMHO probably very people actually modify
>(SLAPD_USER, SLAPD_USER, SLAPD_CONF, SLAPD_SERVICES) and which folks wanting
>to modify can always tweak with a local unit override/dropins.

Hmm. So on upgrade I suppose we would want to automatically migrate 
those settings to a drop-in? That actually sounds doable; such a drop-in 
would probably not have to be a conffile.

SLAPD_CONF is also used (at least) by anyone who still uses a slapd.conf 
file instead of cn=config. Using -f or -F depending on what SLAPD_CONF 
points to was the main reason I assumed we'd need a wrapper script. But 
that could also be replaced by a drop-in.

>The most commonly used option is probably SLAPD_OPTIONS, which could also
>be read via an EnvironmentFile from /etc/default.

Right. Although if that's the only thing still being consumed, I'd be 
tempted to just let it go too. :)

Another (lower priority) thing I meant to look into is the sd_notify(3) 
support. Enabling that means changing the service type and adding the -d 
flag to stop slapd from detaching.

Thanks for the input, it really does help. :)

Ryan