Description of problem: After installation of ldap server openldap-servers slapd wont start. Log shows error: Jul 1 00:11:53 kaaber slapd[11451]: @(#) $OpenLDAP: slapd 2.4.25 (Apr 19 2011 22:44:52) $#012#011iurt@jonund.mageia.org:/home/iurt/rpm/BUILD/openldap-2.4.25/servers/slapd Jul 1 00:11:53 kaaber slapd[11451]: main: TLS init def ctx failed: -1 Jul 1 00:11:53 kaaber slapd[11451]: slapd stopped. Jul 1 00:11:53 kaaber slapd[11451]: connections_destroy: nothing to destroy. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. urpmi openldap-server 2./etc/init.d/ldap restart - slapd wont start
@ Andres Sorry for responding so late. We are very short on triagers. We are still on the same version of openldap-servers, so I guess nothing changed, but please tell us if I am wrong @ Buchan Do you mind triaging this bug report?
CC: (none) => bgmilne, bgmilne, marja11Source RPM: (none) => openldap-servers
NP, I can try :) Well package version is 2.4.26 right now iwch is newer. But new problems with systemd I guess. I'm not very much familiar with systemd Stopping ldap (via systemctl): [ OK ] awk: cmd. line:1: warning: regexp component `[:space:]' should probably be `[[:space:]]' Starting ldap (via systemctl): Failed to issue method call: Unit ldap.service failed to load: No such file or directory. See system logs and 'systemctl status ldap.service' for details. [FAILED] Generating a 1024 bit RSA private key .................................++++++ .................................................++++++ writing new private key to '/etc/pki/tls/private/ldap.pem' ----- [root@kaaber anz]# /etc/init.d/ldap restart Restarting ldap (via systemctl): Job failed. See system logs and 'systemctl status' for details. [FAILED] [root@kaaber log]# /etc/init.d/ldap restart Restarting ldap (via systemctl): Job failed. See system logs and 'systemctl status' for details. [FAILED] [root@kaaber log]# /var/log/ldap/ is empty - no log files
@ Andres Thanks a lot :D I missed that you are on cauldron, I don't know why I saw "1" there, must be the end of the week :[ BTW, it was Buchan I asked to triage, he is the openldap maintainer ;) I haven't been around long enough to know how to handle this bug report
Jul 1 00:11:53 kaaber slapd[11451]: main: TLS init def ctx failed: -1 This usually indicates that the SSL certificates specified in the configuration cannot be loaded (not present, or not readable by ldap user). I'm not currently running a current cauldron anywhere, or systemd either ... I would say a systemd bug/issue (e.g. in ldap.service), package is identical on other platforms and has no problems.
(In reply to comment #4) > Jul 1 00:11:53 kaaber slapd[11451]: main: TLS init def ctx failed: -1 > > This usually indicates that the SSL certificates specified in the configuration > cannot be loaded (not present, or not readable by ldap user). > > I'm not currently running a current cauldron anywhere, or systemd either ... > > I would say a systemd bug/issue (e.g. in ldap.service), package is identical on > other platforms and has no problems. @ D.Morgan Do you mind helping with this?
CC: (none) => dmorganecSource RPM: openldap-servers => openldap-servers, sytemd
Source RPM: openldap-servers, sytemd => openldap-servers, systemd
i add it on my todolist for soon.
Blocks: (none) => 2120
(In reply to comment #6) > i add it on my todolist for soon. Cauldron changed a lot since the end of october. Is this bug still valid?
Keywords: (none) => NEEDINFO
still fails here, i *try* to understand what happens
Keywords: NEEDINFO => (none)
(In reply to comment #8) > still fails here, i *try* to understand what happens Thanks :) Is it OK if I assign it to you?
This is not a systemd but at all but would be nice if someone can migrate it to systemd
Created attachment 1502 [details] Patch to generate a single bundle for the private key and certificate
This is caused by the fact that openldap expects the private key and the certificate in the same file. The patch above addresses that using the RPM SSL helper.
CC: (none) => ofosos
Keywords: (none) => PATCH
s/openldap expects/our openldap configuration specifies/ TLSCertificateFile /etc/pki/tls/private/ldap.pem TLSCertificateKeyFile /etc/pki/tls/private/ldap.pem TLSCACertificateFile /etc/pki/tls/private/ldap.pem Which implies there is a different possible fix as well. The patch here doesn't seem to address fixing the configuration on upgrades. Would have been nice if whoever switched to using the helper tested sufficiently.
I have committed a fix (r205953) changing the paths in the default config file, and updating the other method of creating a cert (gencert.sh) to have the same behaviour. This is the better fix (not exposing the server key in a file that needs to be world-readable to be of any value, and not providing bad security practice examples). I have some other small fixes I would like to ship as well, but I hope to push a new package today or tomorrow.
Status: NEW => ASSIGNED
Assignee: bugsquad => bgmilne
Blocks: 2120 => (none)
@Buchan: btw can you convert openldap to systemd ? you can reuse fedora files i think
Source RPM: openldap-servers, systemd => openldap-servers
(In reply to comment #15) > @Buchan: btw can you convert openldap to systemd ? you can reuse fedora files i > think +1
The package with the changes (r205953) fixing the original issue here was pushed to cauldron on 16 Feb 2012. Please open separate bugs for conversion to systemd (which I haven't had time for yet).
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED