On 2/19/26 10:12 PM, Ondřej Kuzník wrote:
On Thu, Feb 19, 2026 at 09:13:57PM +0530, Pirate Praveen wrote:On 2/19/26 6:57 PM, Ondřej Kuzník wrote:It could be related to actual (TLS?) startup which doesn't happen for slap* tool setup. If you start slapd by hand with `-d config` (or `-d any` if you want full output) does anything new show up on stderr? If it does start up just fine, then I'd look the way of how it's started (selinux/apparmor/... interference) as well but let's start from the bottom.Interestingly running slapd manually seems to work. These are the steps I did, 1. delete olcTLSCipherSuite: NORMAL 2. Set olcSecurity: tls=0 3. Remove ldaps:/// from slapd -h in systemd service file 4. Update source.list and install slapd from trixie 4. start with slapd -d config -h "ldap:/// ldapi:///" 5. Add olcTLSCipherSuite: HIGH 6. Remove olcSecurity: tls=0 Still systemctl start slapd fails, but systemd still cannot start. Manually running this same command (after creating the directories and adjusting permissions) works fine, but somehow systemd is failing to start it. # cat /etc/systemd/system/slapd.service.d/override.conf [Service] ExecStart= ExecStartPre=/bin/mkdir -p /var/run/slapd ExecStartPre=/bin/chown openldap:openldap /var/run/slapd ExecStart=/usr/sbin/slapd -h "ldap:/// ldapi:///" -F /etc/ldap/slapd.d -u openldap -g openldapIf it starts up from the shell, then it definitely sounds like an issue with how systemd sets up the environment. Likely sandboxing or something similar. Add -d to the ExecStart invocation (and potentially olcLogFile: <path> to cn=config if you can't/don't want to read stderr) and see where you get.
ExecStart=sh -c 'mkdir -p /run/slapd; \
chown "$SLAPD_USER":"$SLAPD_GROUP" /run/slapd; \
[ -d "$SLAPD_CONF" ] && confflag=-F || confflag=-f; \
exec /usr/sbin/slapd -d0 \
${SLAPD_SERVICES:+-h "$SLAPD_SERVICES"} \
${SLAPD_USER:+-u "$SLAPD_USER"} \
${SLAPD_GROUP:+-g "$SLAPD_GROUP"} \
${SLAPD_CONF:+$confflag "$SLAPD_CONF"} \
$SLAPD_OPTIONS'
I think /run/slapd vs /var/run/slapd in override file was conflicting.
After removing the override, slapd is starting now.
I think we still need to document how to actually do the migration if
someone has set a value for olcTLSCipherSuites.
My draft for this document (I think this should be included in trixie in a stable update and referenced in release notes:
Since cipher suite names are not compatible between GNUtls and OpenSSL, if you have set any value for this variable, you will need to delete this variable before the upgrade, and set a suitable value after the upgrade is completed.
If you don't remove any incompatible options, you will see this error in slapd logs after the upgrade and slapd service will fail to start.
main: TLS init def ctx failed: -1 error:0A0000B9:SSL routines::no cipher match
You can run this command to see if any value is set, ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config -s base|grep olcTLSCipherSuite For example, if you have set this to NORMAL, you need to create an ldif file # cat delete-ciphersuite.ldif dn: cn=config changetype: modify delete: olcTLSCipherSuite olcTLSCipherSuite: NORMAL and run ldapmodify -Y EXTERNAL -H ldapi:/// -f ./delete-ciphersuite.ldif You can set a suitable value compatible with OpenSSL after the upgrade. # cat add-ciphersuite.ldif dn: cn=config changetype: modify add: olcTLSCipherSuite olcTLSCipherSuite: HIGH ldapmodify -Y EXTERNAL -H ldapi:/// -f ./add-ciphersuite.ldif You might want to remove/etc/systemd/system/slapd.service.d/override.conf as runtime directories are now handled correctly in the systemd service file.
What does systemctl cat slapd.service say? Is there anything in the kernel audit logs to indicate apparmor issues (and what does aa-status say about slapd?) Regards,
OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
