0

I've tried to override the standard slapd (OpenLDAP) daemon start parameters with systemd, but as soon as I override the ExecStart, the daemon fails to start. My questions is why it fails and how I can change the start parameters of the daemon?

I've overrided systemd slapd.service file with:

root@debian:~ $ systemctl edit slapd
[Service]
ExecStart=
ExecStart=/usr/sbin/slapd -h "ldap:/// ldaps:/// ldapi:///" -g openldap -u openldap -F /etc/ldap/slapd.d

Here just a few things to debug:

root@debian:~ $ systemctl cat slapd
# /run/systemd/generator.late/slapd.service
# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/slapd
Description=LSB: OpenLDAP standalone server (Lightweight Directory Access Protoc
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=remote-fs.target
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/slapd start
ExecStop=/etc/init.d/slapd stop

Running the daemon without overriding show:

root@debian:~ $ systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
   Loaded: loaded (/etc/init.d/slapd; generated; vendor preset: enabled)
   Active: active (running) since Mon 2018-07-30 11:33:40 CEST; 1h 20min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 429 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/slapd.service
           └─509 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d

Running the daemon with overrriding, after "systemctl daemon-reload" and "systemctl restart slapd" throws the following errrors:

root@debian:~ $ sudo systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
   Loaded: loaded (/etc/init.d/slapd; generated; vendor preset: enabled)
  Drop-In: /etc/systemd/system/slapd.service.d
           └─override.conf
   Active: failed (Result: exit-code) since Mon 2018-07-30 13:50:13 CEST; 37s ago
     Docs: man:systemd-sysv-generator(8)

Jul 30 13:50:11 udamc systemd[1]: Starting LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)...
Jul 30 13:50:13 udamc slapd[438]: @(#) $OpenLDAP: slapd  (Aug 10 2017 19:12:46) $
                                          Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>
Jul 30 13:50:13 udamc slapd[438]: daemon: bind(9) failed errno=2 (No such file or directory)
Jul 30 13:50:13 udamc slapd[438]: slapd stopped.
Jul 30 13:50:13 udamc slapd[438]: connections_destroy: nothing to destroy.
Jul 30 13:50:13 udamc systemd[1]: slapd.service: Control process exited, code=exited status=1
Jul 30 13:50:13 udamc systemd[1]: Failed to start LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol).
Jul 30 13:50:13 udamc systemd[1]: slapd.service: Unit entered failed state.
Jul 30 13:50:13 udamc systemd[1]: slapd.service: Failed with result 'exit-code'.
1

Your Debian system isn't actually using a real systemd unit for slapd. Rather it's using an ancient style init script slapd located in the /etc/init.d directory. The systemd unit is a generated unit that just attempts to call the init script.

If you can't upgrade to Debian stable, then make your customizations to the old init script.

  • Thank you, your right, i just figured out in debian I can use /etc/default/slapd to edit the start parameters, this way i don't have to edit the init script directly. – chao-samu Jul 30 '18 at 19:47
0

Did slapd really stop before restarting? I suspect that something's missing with ExecStop.

Since this is Debian probably wrapping an old SysV init script I'd also recommend to use a separate unit file stored in /etc/systemd/system/ with different name. And make sure that service slapd is disabled and stopped. This also allows you to use some other security related configuration options and it ensures that nothing fails after upgrade in case the Debian packager changes the unit file.

See below what I use. systemd starts slapd as non-privileged user. Also note the type=simple and PIDFile=. Of course YMMV.

#-----------------------------------------------------------------------
# initiate:   systemctl enable ae-slapd.service
# start:      systemctl start ae-slapd.service
# get status: systemctl status ae-slapd.service
#-----------------------------------------------------------------------

[Unit]
Description=AE-DIR OpenLDAP server
Requires=network.target
After=network.target

[Service]
Type=simple
Environment=LDAPNOINIT=1
PIDFile=/opt/ae-dir/run/slapd/slapd.pid
ExecStart=/usr/lib64/slapd -n ae-slapd -l LOCAL4 -s 7 -f /opt/ae-dir/etc/openldap/slapd.conf -h 'ldapi://%%2Fopt%%2Fae-dir%%2Frun%%2Fslapd%%2Fldapi ldap://*:389 ldaps://*:636' -o slp=off
User=ae-dir-slapd
Group=ae-dir-slapd
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
MemoryDenyWriteExecute=yes
# various hardening options
PrivateTmp=yes
ProtectSystem=full
ProtectHome=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectControlGroups=yes
NoNewPrivileges=yes
MountFlags=private
SystemCallArchitectures=native
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
PrivateDevices=yes

[Install]
WantedBy=multi-user.target

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.