openldap-technical August 2019

openldap-technical@openldap.org

33 participants
47 discussions

PID file /var/run/openldap/slapd.pid not readable (yet?) after start
by Paul Pathiakis 14 Aug '19

14 Aug '19

Hi.... After the previous issue... I went to startup slapd and got the error above. I don't even know how to address that. Slapd won't even start. I'm on CentOS 7. :( systemctl status slapd.service ● slapd.service - OpenLDAP Server Daemon Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled) Active: failed (Result: timeout) since Wed 2019-08-14 11:34:15 EDT; 2min 7s ago Docs: man:slapd man:slapd-config man:slapd-hdb man:slapd-mdb file:///usr/share/doc/openldap-servers/guide.html Process: 15117 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=0/SUCCESS) Process: 15102 ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited, status=0/SUCCESS) Main PID: 14277 (code=exited, status=0/SUCCESS) Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com systemd[1]: Starting OpenLDAP Server Daemon... Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com runuser[15105]: pam_unix(runuser:session): session opened for user ldap by (uid=0) Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com runuser[15105]: pam_unix(runuser:session): session closed for user ldap Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com slapd[15117]: @(#) $OpenLDAP: slapd 2.4.44 (Jan 29 2019 17:42:45) $ mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.44/openlda...s/slapd Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com systemd[1]: PID file /var/run/openldap/slapd.pid not readable (yet?) after start. Aug 14 11:34:15 NewLDAP.hq.boston-engineering.com systemd[1]: slapd.service start operation timed out. Terminating. Aug 14 11:34:15 NewLDAP.hq.boston-engineering.com systemd[1]: Failed to start OpenLDAP Server Daemon. Aug 14 11:34:15 NewLDAP.hq.boston-engineering.com systemd[1]: Unit slapd.service entered failed state. Aug 14 11:34:15 NewLDAP.hq.boston-engineering.com systemd[1]: slapd.service failed. Hint: Some lines were ellipsized, use -l to show in full. [root@NewLDAP openldap]# systemctl start slapd.service Job for slapd.service failed because a timeout was exceeded. See "systemctl status slapd.service" and "journalctl -xe" for details. Thank you, P.

3 2

mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792)
by Paul Pathiakis 14 Aug '19

14 Aug '19

Hi, I'm reloading a DB into OpenLDAP after an upgrade. It starts off fine with: ldapadd -f ./20190812-200001.ldif -v -D "cn=root,dc=hq,dc=example,dc=com" -h newldap.hq.example.com -W -c However, during the load, it gets through a few hundred entries and then: adding new entry "cn=ZRO001-INTERNAL,ou=ZRO001,ou=Projects,dc=hq,dc=example,dc=com"ldap_add: Other (e.g., implementation specific) error (80) additional info: index generation failed During the load, it seems that the indexes are failing as well. Could I have what the issue is?How do I correct it?What are the commands I run properly load this (and generate the indexes)?How do I make sure enough space for the DB and the indexes is allocated? @(#) $OpenLDAP: slapd 2.4.44 (Jan 29 2019 17:42:45) $ mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd Thank you! P.

2 1

Re: Multi-master replication : read_config: no serverID / URL match found. Check slapd -h arguments.
by Quanah Gibson-Mount 14 Aug '19

14 Aug '19

--On Wednesday, August 14, 2019 11:23 AM +0200 HG <hanspeter.sloot(a)gmail.com> wrote: > > olcServerID: 1 ldap://linux1014.ts.aa-srv.com > olcServerID: 2 ldap://linux1015.ts.aa-srv.com Neither of those has a trailing slash. You noted: SLAPD_URLS="ldapi:/// ldap://linux1014.ts.aa-srv.com/" doesn't start, but SLAPD_URLS="ldapi:/// ldap://linux1014.ts.aa-srv.com" starts. I would expect this. As I said before, it's a MATCH between what's provided in the olcServerID field and the -h option to slapd (SLAPD_URLS in your case). I.e., the software is functioning as documented. If you want it to match on the trailing slash, adjust your olcServerID values to include a trailing slash. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Username case
by JC 14 Aug '19

14 Aug '19

I have an OpenLDAP 2.4.42 server in which I have loaded an LDIF file that contains (among other entries) the following: # james, staff, yoyodyne.com dn: uid=james,ou=staff,dc=yoyodyne,dc=com uid: james cn: james objectClass: account objectClass: posixAccount loginShell: /bin/bash uidNumber: 1010 gidNumber: 100 homeDirectory: /home/james Separately, I have a Centos 7 box that retrieves user information from the OpenLDAP server above, by means of the Name Service Switch framework in the Centos 7 system. Users to be authenticated in this box may not be defined locally, but in the OpenLDAP server alone; PAM has been configured in the Centos system so that, for such users, and when attempting to log in over SSH, a directory is created in the Centos box on the fly as necessary, using the path retrieved from the OpenLDAP server in the homeDirectory attribute for the user. The authentication itself is carried out by a remote RADIUS server; PAM is correctly configured for this too. This works fine as described, in that when one attempts to log in over SSH into the Centos system as james, provided that the right password is supplied, the '/home/james' directory is created in the Centos system and an interactive SSH session is established. What I would be interested in next is an OpenLDAP setup so that the entry for a given user can be retrieved from the OpenLDAP server in a case-insensitive manner. The goal is to be able to authenticate username, password pairs over the SSH interface in the Centos7 system, with the username being cases-insensitive. As far as I can tell, in the process of establishing an SSH session, the OpenSSH daemon in the Centos 7 system will attempt to verify that the username is valid by invoking the gepwnam() Linux system call. This function will attempt to retrieve information for its argument - a username string - in a case-sensitive way. It first looks into the relevant local files and, if nothing is found and the NSS framework is appropriately configured, it will next attempt to obtain the data from an LDAP server. PAM helps me here by providing a PAM module (pam_regex) which enables me to normalize incoming usernames - in essence, this module makes is easy to recast all incoming usernames to strings where all uppercase letters are transformed into their lowercase versions. The problem that I have is that OpenSSH invokes getpwnam() both before and after the pam_regex module has been invoked. Thus, if the username received from the client is, say, James, OpenSSH will invoke getpwnam("James") first, and getpwnam("james") later, after pam_regex has normalized "James". The upshot here seems to be that what I would need is an OpenLDAP setup such that when getpwnam("james") and getpwnam("James") - or any other case combination of "James" - are invoked, the OpenLDAP server would return the same user data. Now it seems to be the case that, with a user entry in OpenLDAP as described above, getpwnam("james") will look for an entry such that the its uid attribute takes the value "james". I.e. if the value of uid is, say, "James" then it will be ignored. Which, following the discussion above, doesn't fit my goal. I guess that the question would be the following: Is it possible to configure OpenLDAP so that getpwnam() can retrieve a given entry from the OpenLDAP server in a case-insensitive way? How would one create an entry for a user identified as James so that getpwnam("James"), getpwnam("james"), getpwnam("JAMES"), etc. would all cause the OpenLDAP server to return exactly the same Linux user data (uidNumber, gidNumber, homeDirectory)? Other than the obvious and impractical approach consisting of creating identical entries for all the case combinations of the target name, that is.

4 5

OpenLDAP 2.5 plans and community engagement
by Ondřej Kuzník 13 Aug '19

13 Aug '19

Hi all, as 2.4 has finally stabilised and the ITS list is getting shorter not longer (thanks to Quanah's tireless efforts), the project can finally tackle some of the long-standing pain points. So this post aims to outline where we are/want to move to as well as to start a discussion and hopefully get you, the community, more involved on the road to 2.5 and beyond. We would love to welcome more people to participate in the project and make it more active and resilient. People of various skills and experience can make a difference, I am personally happy to assist anyone who wants to contribute with getting up to speed and start helping out, and for sure I'm not the only one. Also OpenLDAP is about more than just C programming and I'll try to outline the main areas where we want to focus our work in the short term here: One of the pain points in the 2.4 release cycle was the level of testing done on the code before we have released. There are issues with the existing test suite that make testing hard and I will come to how this could be tackled in a later email. In the short term however, we could benefit from having the tests we have run more often and on more diverse environments. If you have a chance to run it regularly, in a loop and report issues picked up, that would be a definite help. If you could help extend the test suite to cover scenarios that are of interest to you and are not appropriately covered yet, even better. Another issue frustrating both users and contributors to the project has been the existing jitterbugs bug tracker (a.k.a. ITS), which has by now outlived its usefulness. Plans to move to a project-hosted Gitlab instance + Bugzilla (via Gitlab's built in Bugzilla integration) are being made and this should make the issue tracker searchable again, help with triage as well as greatly improve the visibility into our release process. Especially after the migration, this would be another opportunity for anyone with just a bit of spare time to help by triaging open issues so we can make timely releases of better quality. I'm sure everyone agrees our website could do with a redesign. We've started looking into this but it has been a slow process so far and if you can contribute here, that might speed things up. It doesn't need much, keeping it a collection of static html pages, just a slight reorganisation of the content that is more friendly to anyone visiting it for the first time plus a simplistic design along the lines of many other open source projects (openssl.org for example) would go a long way. This leads to documentation, much of which is already hosted on the website. While I believe there is good work to be done on the admin guide, it is one of the better parts of our documentation. This is where user feedback on its usefulness is more important, please read it, have people on your team read it and show it people just getting started and report which parts are confusing, how they could be improved. We also intend to document our contributor guidelines in a more readable way. The FAQ site however is on the opposite side of the spectrum and will be removed at some later point. There have been two suggestions how to replace it. We could use Gitlab internal wiki or a static webpage site based on Gitlab pages and we want to transfer over articles that are still relevant. In general, moving to Gitlab should let us integrate CI much better, especially if there are people willing to integrate and manage external runners. As mentioned above, we could definitely do with more regular testing on non-Linux platforms, e.g. *BSD or Windows+MSYS2. Pull requests might then also be automatically tested. Let us know what the pain points have been with OpenLDAP when you were just starting, right now and if you have a suggestion how to make it easier to start using it. Or if you wanted to contribute, has anything discouraged you? There are things we might not be able to influence easily (LDAP itself can be complex), but a fresh look might help direct efforts in the right direction. Thanks ever so much for reading this far. This email is long enough already so I will follow up with another one about my long term plans to overhaul the test infrastructure and other tools that might be worth introducing to help with setting up and managing OpenLDAP deployments. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

11 39

Re: Multi-master replication : read_config: no serverID / URL match found. Check slapd -h arguments.
by HG 13 Aug '19

13 Aug '19

Hi, For example: When /etc/sysconfig/slapd contains: SLAPD_URLS="ldapi:/// ldap://linux1014.ts.aa-srv.com/" # Any custom options SLAPD_OPTIONS="-4" # Keytab location for GSSAPI Kerberos authentication #KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab" systemctl start slapd fails But with: SLAPD_URLS="ldapi:/// ldap://linux1014.ts.aa-srv.com" # Any custom options SLAPD_OPTIONS="-4" # Keytab location for GSSAPI Kerberos authentication #KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab" It starts without any trouble. I took me hours to find this :-( Regards Hans Op ma 12 aug. 2019 om 18:03 schreef Quanah Gibson-Mount <quanah(a)symas.com>: > --On Monday, August 12, 2019 12:38 PM +0200 HG <hanspeter.sloot(a)gmail.com> > > wrote: > > > When I stop and start the slapd service the latter fails with : > > Aug 12 11:33:17 ldap1.domain.com slapd[30972]: @(#) $OpenLDAP: slapd > > 2.4.44 (Jan 29 2019 10:05:51) $ > > It means that there is no match between what you defined as the URI's > associated with olcServerID and the -h argument to slapd, so it cannot > link > a serverID to this instance of slapd. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

Filter memberOf attributes
by Markus Ludwig Grandpré 13 Aug '19

13 Aug '19

Dear list members, i've recently read that dn syntax in memberOf attributes does not allow substring matching in an ldap search filter like: (memberOf=cn=41*) Is there another way implement a substring search in memberOf attributes? Given the following structure: dn: cn=user0,ou=people,o=univeritaet konstanz,c=de memberOf: cn=410000,ou=groups,o=univeritaet konstanz,c=de dn: cn=user1,ou=people,o=univeritaet konstanz,c=de memberOf: cn=410001,ou=groups,o=univeritaet konstanz,c=de dn: cn=user2,ou=people,o=univeritaet konstanz,c=de memberOf: cn=410002,ou=groups,o=univeritaet konstanz,c=de ... dn: cn=user100,ou=people,o=univeritaet konstanz,c=de memberOf: cn=410100,ou=groups,o=univeritaet konstanz,c=de dn: cn=user101,ou=people,o=univeritaet konstanz,c=de memberOf: cn=420000,ou=groups,o=univeritaet konstanz,c=de ... is there an appropriate ldap search filter expression that can be used to filter all memberOf attributes that begin with 41? Whereby compound ldap search expressions like: (| (memberOf=cn=410000,ou=groups,o=univeritaet konstanz,c=de) (memberOf=cn=410001,ou=groups,o=univeritaet konstanz,c=de) (memberOf=cn=410002,ou=groups,o=univeritaet konstanz,c=de) ... (memberOf=cn=410100,ou=groups,o=univeritaet konstanz,c=de) ) are not intended to become implemented, because in real world they would get much too long and therefore too hard to maintain. Best regrads, Markus -- Markus Ludwig Grandpré Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) DV-Anwendungsprogrammierer / Abteilung Basisdienste 78457 Konstanz, Deutschland ++49 7531 88 4342

1 0

Transaction commit speed
by Sam Dave 13 Aug '19

13 Aug '19

Hi, Are transaction commits always fast (almost instantaneous) operations compared to the read or write operations within it? Is it possible for say an mdb_cursor_get or mdb_put to be faster than a subsequent mdb_txn_commit, and if so under what circumstances can that happen? This is relevant info for UI applications showing a progress indicator. If an mdb_txn_commit is always fast, we can rely on the _get/_put count to calculate the percentage. Thanks, Sam

3 2

Re: Multi-master replication : read_config: no serverID / URL match found. Check slapd -h arguments.
by HG 12 Aug '19

12 Aug '19

Thanks I understood that already. But I found out that SLAPD_URLS in /etc/sysconfig/slaps has an issue. It contains ldapi:/// and ldap:/// When I modify the latter in ldap://xxx.yyy.com/ slaps will not work. After removing the last / it works fine. Looks like a bug Op ma 12 aug. 2019 18:03 schreef Quanah Gibson-Mount <quanah(a)symas.com>: > --On Monday, August 12, 2019 12:38 PM +0200 HG <hanspeter.sloot(a)gmail.com> > > wrote: > > > When I stop and start the slapd service the latter fails with : > > Aug 12 11:33:17 ldap1.domain.com slapd[30972]: @(#) $OpenLDAP: slapd > > 2.4.44 (Jan 29 2019 10:05:51) $ > > It means that there is no match between what you defined as the URI's > associated with olcServerID and the -h argument to slapd, so it cannot > link > a serverID to this instance of slapd. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Multi-master replication : read_config: no serverID / URL match found. Check slapd -h arguments.
by HG 12 Aug '19

12 Aug '19

Hello all, I am trying to setup multi-master replication while following the instructions on: https://www.itzgeek.com/how-tos/linux/centos-how-tos/configure-openldap-mul… When I stop and start the slapd service the latter fails with : Aug 12 11:33:17 ldap1.domain.com slapd[30972]: @(#) $OpenLDAP: slapd 2.4.44 (Jan 29 2019 10:05:51) $ mockbuild(a)x86-ol7-builder-02.us.oracle.com: /builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd Aug 12 11:33:17 ldap1.domain.com slapd slapd[30972]: read_config: no serverID / URL match found. Check slapd -h arguments. Aug 12 11:33:17 ldap1.domain.com slapd slapd[30972]: slapd stopped. Aug 12 11:33:17 ldap1.domain.com slapd slapd[30972]: connections_destroy: nothing to destroy. The openldap version is:2.4.44-21.el7_6.x86_64 I have filled /etc/sysconfig/slapd with the right url's. Also used strace to see whether I could determine the cause. This looks like a bug to me. Can anyone help? Regards Hans

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2019