Forums

C M
C M
Offline
Resolved
2 votes
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:

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
Friday, October 20 2017, 03:32 PM
Share this post:
Responses (29)
  • Accepted Answer

    Friday, November 03 2017, 08:51 PM - #Permalink
    Resolved
    0 votes
    Dave Loper wrote:

    NOTE: You can see a template copy of slapd.conf in this post: https://www.clearos.com/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.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, November 03 2017, 07:57 PM - #Permalink
    Resolved
    0 votes
    Dave Loper wrote:

    NOTE: You can see a template copy of slapd.conf in this post: https://www.clearos.com/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.
    The reply is currently minimized Show
  • Accepted Answer

    Jim Shanks
    Jim Shanks
    Offline
    Friday, November 03 2017, 04:35 PM - #Permalink
    Resolved
    0 votes
    Look at Dave Loper's post in this thread. It fixed our system.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, November 03 2017, 04:03 PM - #Permalink
    Resolved
    2 votes
    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://www.clearos.com/clearfoundation/social/community/account-manager-won-t-start,-slapd,-smb-fail-to-start-on-reboot
    The reply is currently minimized Show
  • Accepted Answer

    Friday, November 03 2017, 03:34 PM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Friday, November 03 2017, 02:56 PM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Friday, November 03 2017, 02:39 PM - #Permalink
    Resolved
    0 votes
    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) $
    mockbuild@build64-1.clearsdn.local:/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.
    The reply is currently minimized Show
  • Accepted Answer

    Jim Shanks
    Jim Shanks
    Offline
    Friday, November 03 2017, 02:10 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, November 03 2017, 01:58 PM - #Permalink
    Resolved
    0 votes
    @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 reply is currently minimized Show
  • Accepted Answer

    Jim Shanks
    Jim Shanks
    Offline
    Friday, November 03 2017, 01:30 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, October 25 2017, 02:33 PM - #Permalink
    Resolved
    0 votes
    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!
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, October 25 2017, 09:13 AM - #Permalink
    Resolved
    0 votes
    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 reply is currently minimized Show
  • Accepted Answer

    C M
    C M
    Offline
    Tuesday, October 24 2017, 10:28 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    C M
    C M
    Offline
    Tuesday, October 24 2017, 10:27 PM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 24 2017, 07:57 PM - #Permalink
    Resolved
    0 votes
    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!
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 24 2017, 06:54 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 24 2017, 06:51 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 24 2017, 06:04 PM - #Permalink
    Resolved
    0 votes
    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...
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 24 2017, 03:08 PM - #Permalink
    Resolved
    0 votes
    Any fix yet? My oldest slapd.conf (March 10th, 2017 configuration backup) matches my current slapd.conf, yet slapd still will not start.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, October 23 2017, 09:38 PM - #Permalink
    Resolved
    0 votes
    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?
    The reply is currently minimized Show
  • Accepted Answer

    C M
    C M
    Offline
    Monday, October 23 2017, 07:50 PM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Monday, October 23 2017, 03:15 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, October 20 2017, 09:20 PM - #Permalink
    Resolved
    0 votes
    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) $
    mockbuild@build64-1.clearsdn.local:/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
    The reply is currently minimized Show
  • Accepted Answer

    C M
    C M
    Offline
    Friday, October 20 2017, 08:01 PM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    C M
    C M
    Offline
    Friday, October 20 2017, 07:59 PM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Friday, October 20 2017, 07:53 PM - #Permalink
    Resolved
    0 votes
    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?
    The reply is currently minimized Show
  • Accepted Answer

    C M
    C M
    Offline
    Friday, October 20 2017, 07:15 PM - #Permalink
    Resolved
    0 votes
    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 reply is currently minimized Show
  • Accepted Answer

    Friday, October 20 2017, 05:50 PM - #Permalink
    Resolved
    0 votes
    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 developer@clearfoundation.com, we can take a look.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, October 20 2017, 04:48 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
Your Reply