It looks like I am running 7.4. After the update installed on October 20th updating ldap to 2.4.44-5.v7, slapd will not start. Here is the relevant log entries:
Searching on google suggests that there is a mismatch with the ppolicy.ldif file, but the one installed looks to be correct:
Any ideas?
Thanks,
Chris
Oct 20 11:25:33 fs01 prestart.sh: Checking configuration file failed:
Oct 20 11:25:33 fs01 prestart.sh: 59ea156d User Schema load failed for attribute "pwdMaxRecordedFailure". Error code 17: attribute type undefined
Oct 20 11:25:33 fs01 prestart.sh: 59ea156d config error processing olcOverlay={0}ppolicy,olcDatabase={3}bdb,cn=config: User Schema load failed for attribute "pwdMaxRecordedFailure". Error code 17: attribute type undefined
Oct 20 11:25:33 fs01 prestart.sh: slaptest: bad configuration file!
Oct 20 11:25:33 fs01 nslcd[1210]: [48eaa1] <passwd="ldap.ldap"> failed to bind to LDAP server ldap://127.0.0.1/: Can't contact LDAP server: Transport endpoint is not connected
Oct 20 11:25:33 fs01 nslcd[1210]: [48eaa1] <passwd="ldap.ldap"> no available LDAP server found: Can't contact LDAP server: Transport endpoint is not connected
Oct 20 11:25:33 fs01 systemd: slapd.service: control process exited, code=exited status=1
Oct 20 11:25:33 fs01 systemd: Failed to start OpenLDAP Server Daemon.
Oct 20 11:25:33 fs01 systemd: Unit slapd.service entered failed state.
Oct 20 11:25:33 fs01 systemd: slapd.service failed.
Searching on google suggests that there is a mismatch with the ppolicy.ldif file, but the one installed looks to be correct:
-r--r--r-- 1 root root 4570 Aug 12 08:11 ppolicy.ldif
Any ideas?
Thanks,
Chris
Share this post:
Responses (29)
-
Accepted Answer
Dave Loper wrote:
NOTE: You can see a template copy of slapd.conf in this post: https://sfj48-fkj200.heiksthsd.cf/clearfoundation/social/community/account-manager-won-t-start,-slapd,-smb-fail-to-start-on-reboot
Dave, thanks for pointing me in the right direction. I was able to rebuild the config file and bring everything back online. -
Accepted Answer
Dave Loper wrote:
NOTE: You can see a template copy of slapd.conf in this post: https://sfj48-fkj200.heiksthsd.cf/clearfoundation/social/community/account-manager-won-t-start,-slapd,-smb-fail-to-start-on-reboot
Dave,
Thanks for pointing me in the right direction. Ldap and services are backup and running. -
Accepted Answer
-
Accepted Answer
Some systems were running a patch that originated from CentOS that borks their LDAP. The 3 steps to validate are:
1) Move the /etc/openldap/slapd.d folder out of the way. (The CentOS RPM creates this folder)
mv /etc/openldap/slapd.d /tmp/
2) Make sure that you have a valid slapd.conf file in the /etc/openldap/ directory. This file should have (at least) all of the schema:
# Schemas
#----------------------------------------------------------
# Core schemas
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
# ClearFoundation base
include /etc/openldap/schema/rfc2307bis.schema
include /etc/openldap/schema/clearfoundation.schema
# ClearCenter extension
include /etc/openldap/schema/clearcenter.schema
# Password policy extension
include /etc/openldap/schema/ppolicy.schema
# RADIUS extension
include /etc/openldap/schema/RADIUS-LDAPv3.schema
# Kolab extension
include /etc/openldap/schema/rfc2739.schema
include /etc/openldap/schema/kolab2.schema
# Horde extension
include /etc/openldap/schema/horde.schema
# Samba extension
include /etc/openldap/schema/samba3.schema
# OwnCloud
include /etc/openldap/schema/owncloud.schema
# Zarafa extension
include /etc/openldap/schema/zarafa.schema
# Kopano extension
include /etc/openldap/schema/kopano.schema
The Kopano is new so if the file you have doesn't have all of these and the Kopano as well, please find a valid copy in backup or as one of the files in this directory. Restore this file to its proper place.
3) Validate that the slapd.conf file is owned by ldap. If not, run:
chown ldap:ldap /etc/openldap/slapd.conf
NOTE: You can see a template copy of slapd.conf in this post: https://sfj48-fkj200.heiksthsd.cf/clearfoundation/social/community/account-manager-won-t-start,-slapd,-smb-fail-to-start-on-reboot -
Accepted Answer
-
Accepted Answer
No! You don't want to downgrade to the el7 openldap RPM...You actually want openldap-2.4.44-5.v7.x86_64 (build for ClearOS)...somewhere along the line you installed an openldap package outside of the ClearOS repo ecosystem.
I believe if you just move the slapd.d folder out of they way and stay on openldap-2.4.44-5.v7, you should be able to start OpenLDAP. Eg.:
mv /etc/openldap/slapd.d /tmp/
service openldap restart
B -
Accepted Answer
System updated last night to the 10/20 release. And now LDAP is not running. Here's the service status. Looks like a bad schema attribute. Any idea's how to fix?
[root@portkey openldap]# systemctl status slapd.service -l
● slapd.service - OpenLDAP Server Daemon
Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Fri 2017-11-03 10:15:33 EDT; 43s ago
Docs: man:slapd
man:slapd-config
man:slapd-hdb
man:slapd-mdb
file:///usr/share/doc/openldap-servers/guide.html
Process: 5239 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=1/FAILURE)
Process: 5221 ExecStartPre=/usr/libexec/openldap/prestart.sh (code=exited, status=0/SUCCESS)
Nov 03 10:15:33 portkey.inbandnetworks.com runuser[5225]: pam_unix(runuser:session): session opened for user ldap by (uid=0)
Nov 03 10:15:33 portkey.inbandnetworks.com prestart.sh[5221]: Checking configuration file failed:
Nov 03 10:15:33 portkey.inbandnetworks.com prestart.sh[5221]: 59fc7a05 User Schema load failed for attribute "pwdMaxRecordedFailure". Error code 17: attribute type undefined
Nov 03 10:15:33 portkey.inbandnetworks.com prestart.sh[5221]: 59fc7a05 config error processing olcOverlay={0}ppolicy,olcDatabase={3}bdb,cn=config: User Schema load failed for attribute "pwdMaxRecordedFailure". Error code 17: attribute type undefined
Nov 03 10:15:33 portkey.inbandnetworks.com prestart.sh[5221]: slaptest: bad configuration file!
Nov 03 10:15:33 portkey.inbandnetworks.com slapd[5239]: @(#) $OpenLDAP: slapd 2.4.44 (Aug 12 2017 06:10:11) $
[email protected]:/builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd
Nov 03 10:15:33 portkey.inbandnetworks.com systemd[1]: slapd.service: control process exited, code=exited status=1
Nov 03 10:15:33 portkey.inbandnetworks.com systemd[1]: Failed to start OpenLDAP Server Daemon.
Nov 03 10:15:33 portkey.inbandnetworks.com systemd[1]: Unit slapd.service entered failed state.
Nov 03 10:15:33 portkey.inbandnetworks.com systemd[1]: slapd.service failed. -
Accepted Answer
The folder slapd.d contents are:
folder named: cn=config
filed named: cn=config.ldif
The contents of the folder cn=config are:
-rw------- 1 ldap ldap 500 Apr 28 2016 cn=module{0}.ldif
drwxr-x--- 2 ldap ldap 4096 Apr 28 2016 cn=schema
-rw------- 1 ldap ldap 60760 Apr 28 2016 cn=schema.ldif
-rw------- 1 ldap ldap 584 Apr 28 2016 olcDatabase={0}config.ldif
-rw------- 1 ldap ldap 654 Apr 28 2016 olcDatabase={-1}frontend.ldif
-rw------- 1 ldap ldap 536 Apr 28 2016 olcDatabase={1}monitor.ldif
drwxr-x--- 2 ldap ldap 48 Apr 28 2016 olcDatabase={2}bdb
-rw------- 1 ldap ldap 1370 Apr 28 2016 olcDatabase={2}bdb.ldif
drwxr-x--- 2 ldap ldap 4096 Apr 28 2016 olcDatabase={3}bdb
-rw------- 1 ldap ldap 2874 Apr 28 2016 olcDatabase={3}bdb.ldif
As for the version of LDAP running. It's actually not running at all, but at about 4:00 AM this morning the system auto-updated to: openldap-2.4.44-5.v7.x86_64 frpm: openldap-2.4.40-9.el7_2.x86_64
If I could just downgrade to 2.4.40-9.el7_2.x86_64, I would, but I don't have confidence that it will rebuild the configuration files correctly and I really don't want to lose all of my Zarafa accounts. That would take quite a while to rebuild manually. -
Accepted Answer
-
Accepted Answer
-
Accepted Answer
The missing /etc/openldap/schema folder is very telling. A number of packages drop files into that directory:
- openldap-servers
- app-openldap-core
- samba
In order for that directory to disappear the rpm/yum way is to uninstall these packages. That likely didn't happen, so it must be something else! -
Accepted Answer
Working out remote access is just a question of opening tcp port 22 (ssh) in the incoming firewall and putting your login credentials into the link Peter gave, but please only do it if you have a strong root password. It would be great if the Devs could have a look around the server as it is a bit of a nasty issue which seems to affect more than one system but they have not seen it on any of theirs nor have I on mine. -
Accepted Answer
Peter Baldwin wrote:
What happened to to the /etc/openldap/schema directory? Yikes! Would it be possible to get remote access to the system? If so, please submit a support ticket via your ClearCenter account - https://secure.clearcenter.com/portal/ticket_manage.jsp Please put "Attention: ClearOS Developers" in the subject of the ticket and we can go from there.
Unfortunately, I don't believe I can get the time to work out remote access. -
Accepted Answer
Dave Loper wrote:
Sorry you are running into issues here. This is somewhat of a corner case since it doesn't happen globally. None of the machines implementing the beta exhibited this behavior so we are trying to determine the root cause.
If you have used only verified updates or update then it would be more simple to find the 'combination' of apps and services that causes this problem. If you have used unverified updates at any point it means that you many have gotten a piece of native CentOS code stuck in a config file that we leave alone after initialization.
Please check your yum logs and see if a warning or event associated with the ldap package (eg. rpmsave) is mentioned.
I went through the yum logs which cover since the initial install in April of 16 and I see no warnings, errors or rpmsave. It seems I should try Hance's method, unless a developer thinks that is a bad idea.
Thanks,
Chris -
Accepted Answer
This is how I fixed it. It may not be right, but it worked for me.
So, after downgrading to openldap 2.4.40,
yum remove openldap-servers-2.4.44-5.v7.x86_64
yum remove openldap-clients-2.4.44-5.v7.x86_64
yum downgrade openldap-2.4.40
yum install openldap-servers-2.4.40
yum install openldap-clients-2.4.40
yum install app-openldap-core-2.3.22-1.v7
yum install app-openldap-core-2.3.22-1.v7
yum install app-openldap-core
yum install app-mail-core
yum install app-network-map
yum install app-samba-core
yum install app-shell-extension-core
I was then able to start slapd.
systemctl start slapd.service
However, in the web interface, clicking on accounts resulted in "Oops - Invalid DN"
To reinitialize openldap, I ran the command:
app-openldap-directory-initialize -f
I could then access the Users part of the web interface, but of course, no users....So
I SET UP ALL THE USERS AGAIN. This wasn't too bad for me, as there were only a dozen or so.
Fixed
After all of this, I can OpenVPN again!
I did not have to re-issue certs to the clients. The existing ones still work. This saved a bunch of headaches.
I turned off automatic updates for this machine. When I look at the updates part of the web config, the offending updates:
openldap 2.4.44-5.v7
openldap-clients 2.4.44-5.v7
openldap-server 2.4.44-5.v7
are there in the list, waiting to be installed again. No thanks, I'm full! -
Accepted Answer
Sorry you are running into issues here. This is somewhat of a corner case since it doesn't happen globally. None of the machines implementing the beta exhibited this behavior so we are trying to determine the root cause.
If you have used only verified updates or update then it would be more simple to find the 'combination' of apps and services that causes this problem. If you have used unverified updates at any point it means that you many have gotten a piece of native CentOS code stuck in a config file that we leave alone after initialization.
Please check your yum logs and see if a warning or event associated with the ldap package (eg. rpmsave) is mentioned. -
Accepted Answer
What happened to to the /etc/openldap/schema directory? Yikes! Would it be possible to get remote access to the system? If so, please submit a support ticket via your ClearCenter account - https://secure.clearcenter.com/portal/ticket_manage.jsp Please put "Attention: ClearOS Developers" in the subject of the ticket and we can go from there. -
Accepted Answer
I've now downgraded to openldap 2.4.40. That was fun. Slapd will start now, but it says 'oops, invalid DN' when trying to go to accounts in the web interface. The fun continues....
If anyone has suggestions, please let me know. This is the first time in YEARS that I've had a problem like this, where an update broke something. I've been using this software since ClarkConnect 2. TIA... -
Accepted Answer
-
Accepted Answer
I have checked the config file in the oldest config file backup, and this line does exist.
suffix "dc=my-domain,dc=com"
Hmmmm.... that means the incorrect configuration file was in place before the October 20 upgrade. When the October 20 update came along, it restarted the OpenLDAP server and the new configuration file was pushed into service. So where did this broken slapd.conf configuration file come from? -
Accepted Answer
Peter Baldwin wrote:
Many thanks for the configuration backup. It looks like the /etc/openldap/slapd.conf configuration file reverted back to the OpenLDAP default instead of preserving the already existing configuration file used in ClearOS. This situation would definitely occur if OpenLDAP was re-installed, and I'm sure there are other scenarios that could cause the same problem.
Find your oldest configuration in the Configuration Backup app. Unpack that file and take a look at the /etc/openldap/slapd.conf configuration. If you see the following:
suffix "dc=my-domain,dc=com"
... then we know that the problem existed before the ClearOS 7.4 upgrade. If you don't see this configuration parameter, then doing a restore of this old configuration will get things back on track.
I have checked the config file in the oldest config file backup, and this line does exist.
I can tell you that users could connect fine until the October 20 upgrade. The prior entry in the logs for upgrade or install was August 23 and that was the plex app being updated. I did not re-install openldap manually. It was upgraded as part of the October 20 upgrade. Prior to that upgrade, it was upgraded to app-openldap-core-2.3.23-1.v7 on June 13. And again, the system was fully functional before the upgrade on October 20, and is not now. Is there anywhere else the config file would be, or can I recreate it some way?suffix "dc=my-domain,dc=com"
Thanks,
Chris -
Accepted Answer
Many thanks for the configuration backup. It looks like the /etc/openldap/slapd.conf configuration file reverted back to the OpenLDAP default instead of preserving the already existing configuration file used in ClearOS. This situation would definitely occur if OpenLDAP was re-installed, and I'm sure there are other scenarios that could cause the same problem.
Find your oldest configuration in the Configuration Backup app. Unpack that file and take a look at the /etc/openldap/slapd.conf configuration. If you see the following:
suffix "dc=my-domain,dc=com"
... then we know that the problem existed before the ClearOS 7.4 upgrade. If you don't see this configuration parameter, then doing a restore of this old configuration will get things back on track. -
Accepted Answer
hi i have too problem for begin slapd service, i execute the command "service slapd status" and watch the messange send me
[root@pptp openldap]# service slapd status
Redirecting to /bin/systemctl status slapd.service
● slapd.service - OpenLDAP Server Daemon
Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Fri 2017-10-20 14:34:12 CDT; 28s ago
Docs: man:slapd
man:slapd-config
man:slapd-hdb
man:slapd-mdb
file:///usr/share/doc/openldap-servers/guide.html
Process: 7097 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=1/FAILURE)
Process: 7077 ExecStartPre=/usr/libexec/openldap/prestart.sh (code=exited, status=0/SUCCESS)
Oct 20 14:34:12 pptp runuser[7081]: pam_unix(runuser:session): session closed for user ldap
Oct 20 14:34:12 pptp prestart.sh[7077]: Checking configuration file failed:
Oct 20 14:34:12 pptp prestart.sh[7077]: 59ea4fb4 User Schema load failed for attribute "pwdMaxRecordedFailure". Error code 17: attribute type undefined
Oct 20 14:34:12 pptp prestart.sh[7077]: 59ea4fb4 config error processing olcOverlay={0}ppolicy,olcDatabase={3}bdb,cn=config: User Schema load failed for attribute "pwdMaxRecordedFailure". Error co... type undefined
Oct 20 14:34:12 pptp prestart.sh[7077]: slaptest: bad configuration file!
Oct 20 14:34:12 pptp slapd[7097]: @(#) $OpenLDAP: slapd 2.4.44 (Aug 12 2017 06:10:11) $
[email protected]:/builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd
Oct 20 14:34:12 pptp systemd[1]: slapd.service: control process exited, code=exited status=1
Oct 20 14:34:12 pptp systemd[1]: Failed to start OpenLDAP Server Daemon.
Oct 20 14:34:12 pptp systemd[1]: Unit slapd.service entered failed state.
Oct 20 14:34:12 pptp systemd[1]: slapd.service failed.
Hint: Some lines were ellipsized, use -l to show in full.
please help me my users cant be connect -
Accepted Answer
-
Accepted Answer
-
Accepted Answer
-
Accepted Answer
Nick Howitt wrote:
Can I ask how many files you got on your update? I only had a partial update with 266 packages but it missed a whole bunch I was expecting as well (all the app-* packages, kernel etc). I believe the devs are having another look at the repos to check they have the correct update.
I'm not sure how to tell how many, but looks like it is more than 266. -
Accepted Answer
Could you send us a configuration backup snapshot? In the ClearOS web-based interface, go to "System - Backup - Configuration Backup" in the menu. If you can send that file to [email protected], we can take a look. -
Accepted Answer
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »