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
