Weirdly, if you follow, there was an update which fixed things into a broken state. It appears that OpenLDAP seems to have always been broken and would allow you to use mismatched certificates and keys and it should not have done. This was fixed upstream and released as part of the 7.5 update for the Community, and a bit later for Business. Because it now detects the mismatch it refuses to start, which is better behaviour. The devs thing something like a 7.4 iso went out already containing a key. The initialisation script then copied over the bootstrap certificate but not the key because one already existed hence the mismatch. This has now been fixed. The devs want to see your log in case one of the patches has not worked.

Nick

Log file attached.

The more I think about it the more I agree it was an old ISO which weirdly I had used before successfully. It's a v7.4 ISO

Could it be that there were new updates between then and now which broke things?

Nick

Log file attached.

The more I think about it the more I agree it was an old ISO which weirdly I had used before successfully. It's a v7.4 ISO

Could it be that there were new updates between then and now which broke things?

Is there any chance of attaching your /var/log/system for more investigations?

OK, thanks for letting me know. There is a suspicion of a faulty old installation iso which comes with a /etc/openldap/certs/clearos-key.pem preinstalled which is messing things up. The fix should get round it, but either has not been released or does not work as expected. Can I suggest you download another iso otherwise you risk hitting this issue with every installation?

Nick

Sorry to be the bearer of GOOD news, but re-running your amended commands has fixed it and I can now finish off configuring the system before shipping to Korea.

Thanks for your assistance

Nick

Thanks for this, the solution didn't work, it failed to copy one file as it didn't exist!

cp: cannot stat ‘/etc/pki/CA/private/bootstrap.key’: No such file or directory

I tried the .key file from /etc/pki, didn't work either

Output of second command:

 slapd -h "ldap://127.0.0.1/" -u ldap -f "/etc/openldap/slapd.conf" -d 256

5bb34455 @(#) $OpenLDAP: slapd 2.4.44 (Jul  4 2018 20:05:05) $

        mockbuild@build64-1.clearsdn.local:/builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd

TLSMC: MozNSS compatibility interception begins.

tlsmc_convert: INFO: cannot open the NSS DB, expecting PEM configuration is present.

tlsmc_intercept_initialization: INFO: successfully intercepted TLS initialization. Continuing with OpenSSL only.

TLSMC: MozNSS compatibility interception ends.

TLS: could not use key file `/etc/openldap/certs/clearos-key.pem'.

TLS: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch x509_cmp.c:341

5bb34455 main: TLS init def ctx failed: -1

5bb34455 slapd stopped.

5bb34455 connections_destroy: nothing to destroy.

[root@kor-srv-pxy log]#

I'm thinking the install may not have gone cleanly and a rebuild is the order of the day. The system isn't live yet.

Please can you try the first fix here? Can you let me know if it works because it is supposed to have been fixed for new installations?

[edit]
That is a jump to the possible solution. If it does not work, try starting ldap manually and post the error:

slapd -h "ldap://127.0.0.1/" -u ldap -f "/etc/openldap/slapd.conf" -d 256

[/edit]

Nick

This is going to be a standalone, we're not going down the Master/Slave route

 journalctl -xe

Oct 02 10:30:34 kor-srv-pxy.avx.com systemd[1]: slapd.service: control process exited, code=exited status=1

Oct 02 10:30:34 kor-srv-pxy.avx.com systemd[1]: Failed to start OpenLDAP Server Daemon.

-- Subject: Unit slapd.service has failed

-- Defined-By: systemd

-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

--

-- Unit slapd.service has failed.

--

-- The result is failed.

Oct 02 10:30:34 kor-srv-pxy.avx.com systemd[1]: Unit slapd.service entered failed state.

Oct 02 10:30:34 kor-srv-pxy.avx.com systemd[1]: slapd.service failed.

Oct 02 10:30:34 kor-srv-pxy.avx.com servicewatch[15801]: restarting slapd

Oct 02 10:30:37 kor-srv-pxy.avx.com sudo[15960]: clearsync : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/sbin/tr

Oct 02 10:30:37 kor-srv-pxy.avx.com events[15962]: openldap_online - event occurred

Oct 02 10:30:37 kor-srv-pxy.avx.com events[15965]: openldap_online - triggered hook: mail

Oct 02 10:30:42 kor-srv-pxy.avx.com events[15968]: openldap_online - triggered hook: samba

Oct 02 10:35:01 kor-srv-pxy.avx.com systemd[1]: Started Session 74 of user root.

-- Subject: Unit session-74.scope has finished start-up

-- Defined-By: systemd

-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

--

-- Unit session-74.scope has finished starting up.

--

-- The start-up result is done.

Oct 02 10:35:01 kor-srv-pxy.avx.com systemd[1]: Starting Session 74 of user root.

-- Subject: Unit session-74.scope has begun start-up

-- Defined-By: systemd

-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

--

-- Unit session-74.scope has begun starting up.

Oct 02 10:35:01 kor-srv-pxy.avx.com systemd[1]: Started Session 75 of user root.

-- Subject: Unit session-75.scope has finished start-up

-- Defined-By: systemd

-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

--

-- Unit session-75.scope has finished starting up.

--

-- The start-up result is done.

Oct 02 10:35:01 kor-srv-pxy.avx.com systemd[1]: Starting Session 75 of user root.

-- Subject: Unit session-75.scope has begun start-up

-- Defined-By: systemd

-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

--

-- Unit session-75.scope has begun starting up.

Oct 02 10:35:01 kor-srv-pxy.avx.com CROND[16013]: (root) CMD (LANG=en_US /usr/clearos/apps/base/deploy/servicewatch

Oct 02 10:35:01 kor-srv-pxy.avx.com CROND[16014]: (root) CMD (/usr/sbin/events-notification -i > /dev/null 2>&1)

Oct 02 10:35:01 kor-srv-pxy.avx.com servicewatch[16029]: sanity checking slapd

lines 2175-2221/2221 (END)

Hope the above helps

Is this on the master or slave? Did you get anything from "journalctl -xe" and from your logs? Did yuo try to set a Publish Policy in the Directory Server? If so, what to?