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.

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.

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.

The number of packages is a red herring (you can tell by looking in /var/log/yum.log). Have you forwarded the file to Peter?

Nick Howitt wrote:

The number of packages is a red herring (you can tell by looking in /var/log/yum.log). Have you forwarded the file to Peter?

Yes, I sent the email. I responded in the forum, but it hasn't shown up yet

Nick Howitt wrote:

The number of packages is a red herring (you can tell by looking in /var/log/yum.log). Have you forwarded the file to Peter?

From the logs, it looks like there were 351 packages updated on Oct. 20

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

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.

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.

suffix          "dc=my-domain,dc=com"

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?

Thanks,
Chris

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?

Any fix yet? My oldest slapd.conf (March 10th, 2017 configuration backup) matches my current slapd.conf, yet slapd still will not start.

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...

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.

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.

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!

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

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.

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.

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!

Has anyone gotten this fixed? I have a server down and even restoring the backup config files isn't getting it restarted. I don't think removing the directory and resinstalling is an option as I have a Zarafa server running.

@Jim - By any chance, do you have a folder named /etc/openldap/slapd.d? If so, what's in it?

What version of openldap are you running:

rpm -qv openldap

B

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.

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.

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

Same problem here this morning. I have not installed anything, only automatic updates, of which there were many this morning. Will moving the suggested folder fix the problem? Thank you

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

Look at Dave Loper's post in this thread. It fixed our system.

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.

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.