- openldap-technical - openldap.org

Empty directory memory consumption
by Ivan Kurnosov 18 Oct '17

18 Oct '17

Hi, I have found, that just installed slapd (2.4.42+dfsg-2ubuntu3.2) on ubuntu 16.04 consumes 730MB+ or resident memory (RSS). It's an empty database (with `cn=config` only and whatever comes by default), is it supposed to consume so much memory? -- With best regards, Ivan Kurnosov

1 0

Re: Admin roles by group membership per OU
by Quanah Gibson-Mount 16 Oct '17

16 Oct '17

--On Monday, October 16, 2017 6:05 PM +0200 Ervin Hegedüs <airween(a)gmail.com> wrote: >> Hm, yes, that's correct. You'll need to do something like utilize by * >> break appropriately, or have multiple "access to userPassword" ACLs by >> group, then a catchall after that. > > I'm sorry - could you give me an example? Sure, no problem. :) One way to do it is to have an access line per subtree for those attributes, adding the group permission, with a final access to just userPassword itself limiting off all other access for anything outside of those trees: dn: olcDatabase={1}mdb,cn=config olcAccess: {0}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write ... Addtional subtree ACLs with groups for userPassword/shadowLastChange access... olcAccess: {#}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {#}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {#}to * by * read The other option is to use "by * break", which tells slapd to continue processing additional rules. If you do that, you'll need to be particularly careful not to give access beyond what you intended. For that purpose, I added a final ACL rule that says zero access to userPassword prior to the "* by * read" ACL. dn: olcDatabase={1}mdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by * break olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read ... Additional subtree ACLs with groups ... olcAccess: {#} to userPassword by * none olcAccess: {#}to * by * read --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Admin roles by group membership per OU
by Quanah Gibson-Mount 16 Oct '17

16 Oct '17

--On Monday, October 16, 2017 5:55 PM +0200 Ervin Hegedüs <airween(a)gmail.com> wrote: > without any real testing, I'm afraid that the rule{0} gives the > write access to cn=groupabcadmin to _all_ db, not just the ou=ABC > Cumstomer subtree. > > Em I right? Hm, yes, that's correct. You'll need to do something like utilize by * break appropriately, or have multiple "access to userPassword" ACLs by group, then a catchall after that. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Admin roles by group membership per OU
by Quanah Gibson-Mount 16 Oct '17

16 Oct '17

--On Monday, October 16, 2017 11:45 AM +0200 Ervin Hegedüs <airween(a)gmail.com> wrote: > dn: olcDatabase={1}mdb,cn=config > olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by > anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by * none > olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by > self write by group.exact="cn=groupabcadmin,ou=ABC > Customer,dc=core,dc=hdt,dc=hu" write by > dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {2}to * by * read > > > and a member of cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu > can modify any attributes at any users under the ou=ABC Customer, > EXCEPT the userPassword - when I want to modify that, I get > permission error: That would be expected, given your ACLs. > How can I combine the attrs and group permissions? Should I list > all attributes in rule? You need to add a rule in the userPassword ACL to allow the group to write to the attribute. ACLs are processed in the order they are listed, and STOP at the first match. This is clearly documented in the slapd.access(5) man page. I.e., you would need: dn: olcDatabase={1}mdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {2}to * by * read I would note again that "by * none" is implicit on any ACL, there's no need to specifically list it. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Initialize ldap with mdb
by Howard Chu 16 Oct '17

16 Oct '17

Michael Ströder wrote: > rammohan ganapavarapu wrote: >> You mean we can resize db any time? > > You can increase but *not decrease* maxsize later. > >> Wouldn't it be nice to have no max >> limit and grow db dynamically? > > Not possible with a memory-mapped DB. > Others can explain better in detail why. "No limit" is kind of a pointless phrase. The physical limit will always be the size of free space in your filesystem. Aside from that you can simply do what the documentation says - configure a huge size and let the DB grow dynamically within that size. Use 64TB or whatever, and forget about it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Admin roles by group membership per OU
by Quanah Gibson-Mount 16 Oct '17

16 Oct '17

--On Thursday, October 12, 2017 6:32 PM +0200 Ervin Hegedüs <airween(a)gmail.com> wrote: > rules: > > olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by > anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by * none > olcAccess: {1}to dn.base="" by * read > olcAccess: {2}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by > self write by group.exact="cn=groupabcadmin,ou=ABC > Customer,dc=core,dc=hdt,dc=hu" write by self write by anonymous auth by > dn="uid=repuser,dc=mycompany,dc=hu" read olcAccess: {3}to * by * read Your olcAccess: {1} value does not belong in your back-MDB database. That rule goes in the {-1}frontend,cn=config portion of the database as a global access rule. You probably also want a rule that reads: to dn.base="cn=subschema" by * read in the {-1}frontend,cn=config database as well. So for your back-mdb database, what one would expect is more something like: olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {2}to * by * read --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

Ensure uniqueness over multiple attributes?
by Karsten Heymann 13 Oct '17

13 Oct '17

Hi, does the unique overlay support checking multiple values for a single uniqueness check? Our clients can use emails in two attributes (think mail and mailAlias) and addresses have to be unique in regard to both fields, which means an address that is used in either of them cannot be used in any other of them. Is that possible? +Karsten

3 4

Re: [ldapmodify] multiple entries of the same attibute
by Quanah Gibson-Mount 13 Oct '17

13 Oct '17

--On Friday, October 13, 2017 6:06 PM +0200 richard lucassen <mailinglists(a)lucassen.org> wrote: > How do I tell ldapmodify just to delete 1 particular item with > AttributeValue=X, and not all of them? You do a delete+add, just like Dieter said. What you did in your example was a replace op. I.e., you'd do something like: dn: <whatever> changetype: modify delete: mail mail: my-value - add: mail mail: my-value --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Small tip to speed up large imports with ldapadd
by Quanah Gibson-Mount 13 Oct '17

13 Oct '17

--On Friday, October 13, 2017 5:44 PM +0200 Karsten Heymann <karsten.heymann(a)gmail.com> wrote: > > Hi Quanah, > > > > 2017-10-13 16:15 GMT+02:00 Quanah Gibson-Mount <quanah(a)symas.com>: > > Why not just set dbnosync option as documented in the > slapd-mdb(5)/slapd-bdb(5)/slapd-hdb(5) man pages? > > > > > I tried that as well, and it made the import faster, but at least in my > setup using eatmydata still was a *lot* faster. > > > Another option, which I didn't think about when building my test setup, > would have been to put the data directory into a ram disk during the > import and move it to disk afterwards. > > > Either way, each variant seem quite similiar with regard to what effort > they take, so I'm quite happy with my setup. If you're using back-mdb, you could play with the writemap environment flag as well. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Small tip to speed up large imports with ldapadd
by Karsten Heymann 13 Oct '17

13 Oct '17

Hi Quanah, 2017-10-13 16:15 GMT+02:00 Quanah Gibson-Mount <quanah(a)symas.com>: > > Why not just set dbnosync option as documented in the > slapd-mdb(5)/slapd-bdb(5)/slapd-hdb(5) man pages? > I tried that as well, and it made the import faster, but at least in my setup using eatmydata still was a *lot* faster. Another option, which I didn't think about when building my test setup, would have been to put the data directory into a ram disk during the import and move it to disk afterwards. Either way, each variant seem quite similiar with regard to what effort they take, so I'm quite happy with my setup. BR Karsten

1 0

Re: [ldapmodify]multiple entries of the same attibute
by Quanah Gibson-Mount 13 Oct '17

13 Oct '17

--On Friday, October 13, 2017 3:29 PM +0200 Ralf Mattes <rm(a)mh-freiburg.de> wrote: >> Is there a way to tell ldapmodify to change just a particular entry? > > A change of a single value equals a delete of that value plus an add of > the new value, doesn't it? Yes. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Small tip to speed up large imports with ldapadd
by Quanah Gibson-Mount 13 Oct '17

13 Oct '17

--On Friday, October 13, 2017 4:57 PM +0200 Karsten Heymann <karsten.heymann(a)gmail.com> wrote: > - I like the way ldapadd logs complete entries it failed to import, that > makes analyising the cause of the import error much simpler, after e.g. > fixing the schema I can ldapdd these error files directly again to see if > the fix works Why not just set dbnosync option as documented in the slapd-mdb(5)/slapd-bdb(5)/slapd-hdb(5) man pages? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Small tip to speed up large imports with ldapadd
by Karsten Heymann 13 Oct '17

13 Oct '17

Hi, as I am in the situation where I have to do large imports with ldapadd, I wanted to share a little tip that is saving me a lot of time and may be helpful to others too. As I don't care for data consistency *while* importing (if the import should abort, I can alway restart the process), I'm stopping the regular slapd and run it manually under the control of 'eatmydata', a little tool that LD_PRELOAD's all filesystem sync operations to noops. This has increased the speed of my import tests by several orders of magnitude. Here's my script (slightly obfuscated): systemctl stop slapd rm -f /srv/ldap/data/* systemd-run --unit=slapd-fastimport eatmydata /usr/sbin/slapd -d 0 -s 0 -h ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d sleep 2 ldapadd -Y EXTERNAL -H ldapi:/// -Q -c -S errorlog -f data.ldif systemctl stop slapd-fastimport sleep 2 systemctl start slapd grep Error: errorlog | sort | uniq -c | sort -n Best regards Karsten

2 2

Admin roles by group membership per OU
by Ervin Hegedüs 12 Oct '17

12 Oct '17

Hi, here is my scenario: dn: dc=mycompany,dc=hu dn: ou=ABC Customer,dc=mycompany,dc=hu +- dn: cn=group1abc,ou=ABC Customer,dc=mycompany,dc=hu +- dn: cn=group2abc,ou=ABC Customer,dc=mycompany,dc=hu +- dn: cn=groupabcadmin,ou=ABC Customer,dc=mycompany,dc=hu +- dn: uid=user1,ou=ABC Customer,dc=mycompany,dc=hu +- dn: uid=user2,ou=ABC Customer,dc=mycompany,dc=hu dn: ou=XYZ Customer,dc=mycompany,dc=hu +- dn: cn=group1xyz,ou=XYZ Customer,dc=mycompany,dc=hu +- dn: cn=group2xyz,ou=XYZ Customer,dc=mycompany,dc=hu +- dn: uid=user1,ou=XYZ Customer,dc=mycompany,dc=hu +- dn: uid=user2,ou=XYZ Customer,dc=mycompany,dc=hu ... the cn=groupabcadmin,ou=ABC Customer node above looks like this: dn: cn=groupabcadmin,ou=ABC Customer,dc=mycompany,dc=hu objectClass: groupOfNames cn: groupabcadmin member: uid=user1,ou=ABC Customer,dc=mycompany,dc=hu I'ld like to set up, that the all member of cn=groupabcadmin group, now the "uid=user1,ou=ABC Customer",... user can write the db (add, modify, delete) under his own OU, specially the ou=ABC Customer,dc=mycompany,dc=hu. I've found this example: http://www.openldap.org/faq/data/cache/52.html Now the config looks like this: dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=mycompany,dc=hu olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by * read olcAccess: {3}to dn.children="ou=ABC Customer,dc=mycompany,dc=hu" by self write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=mycompany,dc=hu" write by * auth olcLastMod: TRUE The uid=user1 user password is right, I can read with it from DB. But when I would like to add a new user, I've got: ldap_add: Insufficient access (50) additional info: no write access to parent and in log: Oct 11 17:03:16 open-ldap slapd[25821]: mdb_dn2entry("uid=user2,ou=abc customer,dc=mycompany,dc=hu") Oct 11 17:03:16 open-ldap slapd[25821]: => mdb_dn2id("uid=user2,ou=abc customer,dc=mycompany,dc=hu") Oct 11 17:03:16 open-ldap slapd[25821]: <= mdb_dn2id: get failed: MDB_NOTFOUND: No matching key/data pair found (-30798) Oct 11 17:03:16 open-ldap slapd[25821]: => mdb_entry_decode: Oct 11 17:03:16 open-ldap slapd[25821]: <= mdb_entry_decode Oct 11 17:03:16 open-ldap slapd[25821]: => access_allowed: add access to "ou=ABC Customer,dc=mycompany,dc=hu" "children" requested Oct 11 17:03:16 open-ldap slapd[25821]: => dn: [2] Oct 11 17:03:16 open-ldap slapd[25821]: => acl_get: [3] attr children Oct 11 17:03:16 open-ldap slapd[25821]: => acl_mask: access to entry "ou=ABC Customer,dc=mycompany,dc=hu", attr "children" requested Oct 11 17:03:16 open-ldap slapd[25821]: => acl_mask: to all values by "uid=user1,ou=abc customer,dc=mycompany,dc=hu", (=0) Oct 11 17:03:16 open-ldap slapd[25821]: <= check a_dn_pat: * Oct 11 17:03:16 open-ldap slapd[25821]: <= acl_mask: [1] applying read(=rscxd) (stop) Oct 11 17:03:16 open-ldap slapd[25821]: <= acl_mask: [1] mask: read(=rscxd) Oct 11 17:03:16 open-ldap slapd[25821]: => slap_access_allowed: add access denied by read(=rscxd) Oct 11 17:03:16 open-ldap slapd[25821]: => access_allowed: no more rules Oct 11 17:03:16 open-ldap slapd[25821]: mdb_add: no write access to parent Oct 11 17:03:16 open-ldap slapd[25821]: send_ldap_result: conn=1208 op=1 p=3 Oct 11 17:03:16 open-ldap slapd[25821]: send_ldap_result: err=50 matched="" text="no write access to parent" Oct 11 17:03:16 open-ldap slapd[25821]: send_ldap_response: msgid=2 tag=105 err=50 Oct 11 17:03:16 open-ldap slapd[25821]: conn=1208 op=1 RESULT tag=105 err=50 text=no write access to parent What do I miss? Thanks, a.

3 8

Question about automounting nfs directories within ldap
by Bänsch, Christian (TF) 12 Oct '17

12 Oct '17

Dear Community, thank you for your help to made my ldap configuration runnable and the login for users working. Now I have the next question about automounting nfs directories. In my /etc/exports I have several directories /export/home 10.188.114.0/25(fsid=0,rw,sync,root_squash,secure,no_subtree_check) /export/software/linux 10.188.114.0/25(rw,root_squash,sync,subtree_check,secure) /export/calculate 10.188.114.0/25(rw,root_squash,sync,no_subtree_check) I want to export when the ldap user is going to login. But when I do this, I´ll get those error messages. Oct 9 09:59:13 fautm89 automount[13131]: attempting to mount entry /home/iwtm009 Oct 9 09:59:13 fautm89 automount[13131]: >> mount.nfs: access denied by server while mounting fautm89.ltm.uni-erlangen.de:/export/home/iwtm009 Oct 9 09:59:13 fautm89 automount[13131]: mount(nfs): nfs: mount failure fautm89.ltm.uni-erlangen.de:/export/home/iwtm009 on /home/iwtm009 Oct 9 09:59:13 fautm89 automount[13131]: failed to mount /home/iwtm009 Oct 9 10:00:01 fautm89 automount[13131]: attempting to mount entry /local/calculate Oct 9 10:00:01 fautm89 automount[13131]: >> mount.nfs: access denied by server while mounting fautm89.ltm.uni-erlangen.de:/export/calculate Oct 9 10:00:01 fautm89 automount[13131]: mount(nfs): nfs: mount failure fautm89.ltm.uni-erlangen.de:/export/calculate on /local/calculate Oct 9 10:00:01 fautm89 automount[13131]: failed to mount /local/calculate Oct 9 10:00:14 fautm89 automount[13131]: attempting to mount entry /local/linux Oct 9 10:00:14 fautm89 automount[13131]: >> mount.nfs: access denied by server while mounting fautm89.ltm.uni-erlangen.de:/export/software/linux Oct 9 10:00:14 fautm89 automount[13131]: mount(nfs): nfs: mount failure fautm89.ltm.uni-erlangen.de:/export/software/linux on /local/linux Oct 9 10:00:14 fautm89 automount[13131]: failed to mount /local/linux When I do e.g. a ls -la in /home on the server, I get drwx------ 79 iwtm009 tm 4096 Aug 22 13:15 iwtm009/ on the client I get dr-xr-xr-x 2 root root 0 Oct 9 09:47 iwtm009 Should I have to adjust this in slapd configuration or am I just blind to see it? -- Thank you in advance and best regards, Christian

2 2

Re: Replication error
by Quanah Gibson-Mount 12 Oct '17

12 Oct '17

--On Tuesday, October 10, 2017 6:39 PM +0200 Ervin Hegedüs <airween(a)gmail.com> wrote: > binddn="uid=repuser,dc=my,dc=domain,dc=hu" > Anyway - how can I solve this problem? Your uid=repuser,dc=my,dc=domain,dc=hu user does not have "read" access on the userPassword attribute. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

Re: make test seg fault related to libc
by Quanah Gibson-Mount 12 Oct '17

12 Oct '17

--On Wednesday, October 11, 2017 1:02 PM -0700 Scott Classen <sclassen(a)lbl.gov> wrote: ># ulimit -a Hm, well, that doesn't appear to be it. :/ You might look at the testrun logs and see what slapd is logging when it dies as well. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: make test seg fault related to libc
by Quanah Gibson-Mount 11 Oct '17

11 Oct '17

--On Wednesday, October 11, 2017 10:44 AM -0700 Scott Classen <sclassen(a)lbl.gov> wrote: > Hello, > > I've built openldap 2.4.45 on a CentOS 7.4.1708 machine with the > following configuration: I've seen this happen when a ulimit value was unreasonably small. Check the limits on -m or -v perhaps. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

make test seg fault related to libc
by Scott Classen 11 Oct '17

11 Oct '17

Hello, I've built openldap 2.4.45 on a CentOS 7.4.1708 machine with the following configuration: ./configure --enable-bdb=no --enable-hdb=no --enable-mdb --with-tls=openssl --enable-spasswd --enable-syslog --enable-modules --enable-cleartext --enable-overlays --enable-accesslog --enable-auditlog --with-threads --enable-shared --enable-ldap --enable-monitor --enable-deref --enable-slapd --enable-ppolicy --enable-memberof When I run make test I receive numerous segmentation faults: output from make test: > ./scripts/test028-idassert: line 252: 28923 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 > >>>>> test028-idassert completed OK for mdb. > > >>>>> Starting test029-ldapglue for mdb... > running defines.sh > ### This test requires the ldap backend and glue overlay. > ### If available, and explicitly requested, it can use SASL bind; > ### note that SASL must be properly set up, and the requested > ### mechanism must be available. Define SLAPD_USE_SASL={yes|<mech>}, > ### with "yes" defaulting to DIGEST-MD5 to enable SASL authc[/authz]. > Using proxyAuthz with simple authc... > Running slapadd to build slapd database... > Starting local slapd on TCP/IP port 9011... > Starting remote slapd 1 on TCP/IP port 9012... > Starting remote slapd 2 on TCP/IP port 9013... > Using ldapsearch to check that slapd is running... > Using ldapsearch to check that slapd is running... > Using ldapsearch to check that slapd is running... > Testing ldapsearch as uid=bjorn,ou=People,dc=example,dc=com for "dc=example,dc=com"... > Filtering ldapsearch results... > Filtering original ldif used to create database... > Comparing filter output... > Testing ldapsearch as anonymous for "dc=example,dc=com"... > Filtering ldapsearch results... > Filtering original ldif used to create database... > Comparing filter output... > >>>>> Test succeeded > ./scripts/test029-ldapglue: line 222: 28992 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 > ./scripts/test029-ldapglue: line 222: 28994 Segmentation fault (core dumped) $SLAPD -f $CONF2 -h $URI2 -d $LVL $TIMING > $LOG2 2>&1 > ./scripts/test029-ldapglue: line 222: 28996 Segmentation fault (core dumped) $SLAPD -f $CONF3 -h $URI3 -d $LVL $TIMING > $LOG3 2>&1 > >>>>> test029-ldapglue completed OK for mdb. In /var/log/messages: > Oct 11 09:31:42 www kernel: slapd[9039]: segfault at 1100fffff7 ip 00007febd7a2f4dc sp 00007ffe832541f8 error 4 in libc-2.17.so[7febd79af000+1b8000] > Oct 11 09:31:42 www kernel: slapd[8997]: segfault at 1100fffff7 ip 00007f48923e44dc sp 00007ffec5a22658 error 4 in libc-2.17.so[7f4892364000+1b8000] > Oct 11 09:31:42 www kernel: slapd[8975]: segfault at 1100fffff7 ip 00007f01a727d4dc sp 00007ffd9a127698 error 4 in libc-2.17.so[7f01a71fd000+1b8000] > Oct 11 09:31:42 www abrt-hook-ccpp: Process 8975 (slapd) of user 0 killed by SIGSEGV - ignoring (repeated crash) > Oct 11 09:31:42 www abrt-hook-ccpp: Process 9039 (slapd) of user 0 killed by SIGSEGV - dumping core > Oct 11 09:31:42 www abrt-hook-ccpp: Process 8997 (slapd) of user 0 killed by SIGSEGV - dumping core I don't see any obvious problems with the linked libraries: [me@here openldap-2.4.45]# ldd servers/slapd/slapd linux-vdso.so.1 => (0x00007ffd98751000) libltdl.so.7 => /lib64/libltdl.so.7 (0x00007f930d78b000) libicuuc.so.50 => /lib64/libicuuc.so.50 (0x00007f930d412000) libicudata.so.50 => /lib64/libicudata.so.50 (0x00007f930be3d000) libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f930bc20000) libssl.so.10 => /lib64/libssl.so.10 (0x00007f930b9ae000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f930b54c000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f930b332000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f930b116000) libc.so.6 => /lib64/libc.so.6 (0x00007f930ad52000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f930ab4e000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f930a846000) libm.so.6 => /lib64/libm.so.6 (0x00007f930a543000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f930a32d000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f930a0f6000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f9309ea8000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f9309bc0000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f93099bc000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f9309788000) libz.so.1 => /lib64/libz.so.1 (0x00007f9309572000) /lib64/ld-linux-x86-64.so.2 (0x000055eefaf24000) libfreebl3.so => /lib64/libfreebl3.so (0x00007f930936e000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f9309160000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f9308f5c000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f9308d34000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f9308ad2000) Any advice or suggestions would be welcome. Regards, Scott

1 0

Re: Upgrade from 2.4.40 to 2.4.44
by Quanah Gibson-Mount 11 Oct '17

11 Oct '17

--On Friday, September 15, 2017 9:18 AM -0700 Ryan Tandy <ryan(a)nardis.ca> wrote: > IIRC slapcat doesn't work in this case, because it fails to initialize > the ppolicy module. > > The linked CentOS and RHEL bugs recommend downgrading slapd to the > previously working version and using ldapmodify. Yeah, that's ugly :/ Another reason we really need to get slapmodify out, and some way to execute it with an option to not load modules or similar. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 3

Replication error
by Ervin Hegedüs 10 Oct '17

10 Oct '17

Hi, I (think I) setting up completly a master-slave replication. The replication user can access from the slave (ldapsearch works). Here is the config, what I added on slave: dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=001 provider=ldaps://master:636/ bindmethod=simple binddn="uid=repuser,dc=my,dc=domain,dc=hu" credentials=SECRET searchbase="dc=my,dc=domain,dc=hu" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 3" interval=00:00:05:00 tls_cacert=/etc/ldap/CAcert.pem tls_cert=/etc/ldap/slave_cert.pem tls_key=/etc/ldap/slave_key.pem tls_reqcert=demand And now I found these lines in syslog: Oct 10 17:36:40 open-ldap2 slapd[4640]: Entry (cn=admin,dc=my,dc=domain,dc=hu): object class 'simpleSecurityObject' requires attribute 'userPassword' Oct 10 17:36:40 open-ldap2 slapd[4640]: null_callback : error code 0x41 Oct 10 17:36:40 open-ldap2 slapd[4640]: syncrepl_entry: rid=001 be_add cn=admin,dc=my,dc=domain,dc=hu failed (65) Oct 10 17:36:41 open-ldap2 slapd[4640]: do_syncrepl: rid=001 rc 65 retrying (4 retries left) I think this occures, because the cn=admin,dc=... user is a simpleSecurityObject, and could't access the userPassword from the ldapsearch - or not :). Anyway - how can I solve this problem? Thanks, a.

1 0

Preauth Issue with SASL-Passthrough and Kerberos Backend
by Ulrich Tehrani 06 Oct '17

06 Oct '17

Hi all, i setup an openldap server which is used as MIT-Kerebros backend. User-Principals have - besides the kerberos attributes - appropriate objectclasses (e.g. simplesecurityObject, organizationalRole) to make also a simple authentication with the attribut userpassword possible. To consolidate both credentials i made a setup of SASL-Pasthrough with backend Kerberos. So i set the value of the userpassword attribut to. {SASL}<user>@<realm> and made the required configurations for the saslauthd. With this configuration all kind of authentications will use the kerberos-password. I made various tests but there seems to be an issue with preauthentication in openldap. I got the follwoing result: =>testsaslauthd is always working if the preauth flag is on or off =>ldapsearch -x is only working with preauth-flag disabled. => It makes no difference if MIT Kerberos use its normal backend Keep in mind: For clear testing condtions saslauthd-caching has to be disabled ! Don't use the -c Option in saslauthd - otherwise it could happen that your ldapsearch -x is working because you had success with a former testsaslauthd-command ! Has someone a similar setup which is working with enabled preauth ? Or does someone know if this is supported or not ? I use LDAP 2.4.44 with cyrus-sasl-2.1.23. Thanks in advance. Kind regards Uli -- =================================== Ulrich Tehrani Am Ulrichshof 19 79189 Bad Krozingen

2 1

Re: Can't get lmdb to build on FreeBSD 12
by Howard Chu 04 Oct '17

04 Oct '17

Russell Haley wrote: > Hi, > > Sorry for the silly question, but I've stumped myself and my C is > weak. Normally lmdb builds fine without issue on most of the platforms > I try (Debian Jessie, FreeBSD 10.3 & 12), but it's stopped compiling > on my TrueOS box, which is FreeBSD 12. I've tried gcc and clang 4.0 > and 3.9. Try using GNU make. It looks like whatever make you're using doesn't have the proper default build rules. > ------------------------ > > russellh@prescott:~/Git/lmdb/libraries/liblmdb% make > cc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast > -Wuninitialized -v mdb_stat.c -o mdb_stat > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on > LLVM 4.0.0) > Target: x86_64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > "/usr/bin/cc" -cc1 -triple x86_64-unknown-freebsd12.0 -emit-obj > -disable-free -main-file-name mdb_stat.c -mrelocation-model static > -mthread-model posix -mdisable-fp-elim -masm-verbose > -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v > -dwarf-column-info -debug-info-kind=standalone -dwarf-version=2 > -debugger-tuning=gdb -resource-dir /usr/bin/../lib/clang/4.0.0 -O2 -W > -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized > -fdebug-compilation-dir /usr/home/russellh/Git/lmdb/libraries/liblmdb > -ferror-limit 19 -fmessage-length 237 -pthread -fobjc-runtime=gnustep > -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o > /tmp/mdb_stat-852384.o -x c mdb_stat.c > clang -cc1 version 4.0.0 based upon LLVM 4.0.0 default target > x86_64-unknown-freebsd12.0 > #include "..." search starts here: > #include <...> search starts here: > /usr/bin/../lib/clang/4.0.0/include > /usr/include > End of search list. > "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 > --hash-style=both --enable-new-dtags -o mdb_stat /usr/lib/crt1.o > /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/mdb_stat-852384.o > -lgcc --as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc > --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o > /tmp/mdb_stat-852384.o: In function `main': > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:104: > undefined reference to `mdb_env_create' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:106: > undefined reference to `mdb_strerror' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:111: > undefined reference to `mdb_env_set_maxdbs' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:114: > undefined reference to `mdb_env_open' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:116: > undefined reference to `mdb_strerror' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:121: > undefined reference to `mdb_env_stat' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:122: > undefined reference to `mdb_env_info' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:136: > undefined reference to `mdb_reader_list' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:139: > undefined reference to `mdb_reader_check' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:141: > undefined reference to `mdb_reader_list' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:147: > undefined reference to `mdb_txn_begin' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:149: > undefined reference to `mdb_strerror' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:257: > undefined reference to `mdb_env_close' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:160: > undefined reference to `mdb_cursor_open' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:162: > undefined reference to `mdb_strerror' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:165: > undefined reference to `mdb_stat' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:171: > undefined reference to `mdb_cursor_get' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:171: > undefined reference to `mdb_cursor_get' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:199: > undefined reference to `mdb_cursor_close' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:203: > undefined reference to `mdb_dbi_open' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:205: > undefined reference to `mdb_strerror' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:209: > undefined reference to `mdb_stat' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:(.text+0x5d6): > undefined reference to `mdb_strerror' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:255: > undefined reference to `mdb_txn_abort' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:221: > undefined reference to `mdb_cursor_open' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:223: > undefined reference to `mdb_strerror' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:226: > undefined reference to `mdb_cursor_get' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:234: > undefined reference to `mdb_dbi_open' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:239: > undefined reference to `mdb_stat' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:245: > undefined reference to `mdb_dbi_close' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:226: > undefined reference to `mdb_cursor_get' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:247: > undefined reference to `mdb_cursor_close' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:253: > undefined reference to `mdb_dbi_close' > /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:241: > undefined reference to `mdb_strerror' > cc: error: linker command failed with exit code 1 (use -v to see > invocation) > *** Error code 1 > > Stop. > make: stopped in /usr/home/russellh/Git/lmdb/libraries/liblmdb > > ---------------------------------- > The full output is here with uname, git status and compiler info: > http://termbin.com/io9d > > Any help would be grand. > > Thanks, > Russ > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 2

Re: lmdb as a Lua database
by Russell Haley 04 Oct '17

04 Oct '17

Brilliant. May I ping you for more information? I'm tightly coupled to my current toolchain but will use this for reference. Russ On Wed, Oct 4, 2017 at 9:21 AM, Леонид Юрьев <leo(a)yuriev.ru> wrote: > take a look at https://github.com/PositiveTechnologies/libfpta > > regads. > > > 2017-10-04 9:20 GMT+03:00 Russell Haley <russ.haley(a)gmail.com>: >> On Tue, Oct 3, 2017 at 11:19 PM, Russell Haley <russ.haley(a)gmail.com> wrote: >>> Hi, >>> >>> So I'm using LMDB to create a simple 'database' system for lua that >>> will allow me to directly serialize and store lua table data. So far I >>> have used the wonderful lmdb wrapper lightningmdb and created a simple >>> API to hide some of the mechanisms. >>> >>> Honestly, your API is so well thought out, I'm doing a disservice by >>> removing a lot of the powerful features. However, I press ahead and >>> beg forgiveness. :) >>> >>> I have two questions: >>> >>> 1) There is a simplified vs cursor API. I am starting to suspect that >>> the simplified functions are just basic wrappers around the cursor >>> API? I ask because if this is the case, I could just remove my support >>> for the simplified API and only have to support one set of functions. >>> >>> 2) The key lookup is blazing fast (so awesome, this thing is going to >>> smoke!). I wanted to create a way of indexing the data elements within >>> the database by allowing users to create lua functions that parse the >>> lua table values. >>> --a basic table that would be serialized into a lmdb database called t1 >>> t1 = { >>> 1={col_a="test",col_b="item1"}, >>> 2={col_a="not-a-test",col_b="item2"}, >>> 3={col_a="test",col_b="item3"} >>> } >>> >>> --The function that would be called per-row to create an index. >>> local function(k,v) >>> >>> return v.col_a, k >>> end >>> >>> The idea would be to use the dupsort feature to create an 'index' >>> database with data structured as: >>> >>> not-a-test, 2 >>> test, 1 >>> test, 3 >> >> Sorry, hit send in gmail by accident. Anyway, the idea is to use the >> dupsort feature to create indexes. Is this feasible? Any input or >> direction would be fantastic. >> >> Thanks! >> Russ >>

1 0

Re: lmdb as a Lua database
by Howard Chu 04 Oct '17

04 Oct '17

Russell Haley wrote: > Hi, > > So I'm using LMDB to create a simple 'database' system for lua that > will allow me to directly serialize and store lua table data. So far I > have used the wonderful lmdb wrapper lightningmdb and created a simple > API to hide some of the mechanisms. > > Honestly, your API is so well thought out, I'm doing a disservice by > removing a lot of the powerful features. However, I press ahead and > beg forgiveness. :) > > I have two questions: > > 1) There is a simplified vs cursor API. I am starting to suspect that > the simplified functions are just basic wrappers around the cursor > API? I ask because if this is the case, I could just remove my support > for the simplified API and only have to support one set of functions. Yes, everything uses cursors internally. > 2) The key lookup is blazing fast (so awesome, this thing is going to > smoke!). I wanted to create a way of indexing the data elements within > the database by allowing users to create lua functions that parse the > lua table values. > --a basic table that would be serialized into a lmdb database called t1 > t1 = { > 1={col_a="test",col_b="item1"}, > 2={col_a="not-a-test",col_b="item2"}, > 3={col_a="test",col_b="item3"} > } > > --The function that would be called per-row to create an index. > local function(k,v) > > return v.col_a, k > end > > The idea would be to use the dupsort feature to create an 'index' > database with data structured as: > > not-a-test, 2 > test, 1 > test, 3 Sure, that's generally what dupsort is for. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Initialize ldap with mdb
by Howard Chu 04 Oct '17

04 Oct '17

rammohan ganapavarapu wrote: > Howard, > > If it doesnt swap, what will it do in case of db size is larger than actual > RAM? also how does it manage the physical RAM? meaning what % system RAM does > it use? It doesn't manage physical RAM at all, the OS does. There is no fixed % of system RAM that it will use, the OS will let it use whatever is available. > is it configurable ? No. > will it case any OOM issues? No. > i am trying to > migrate from hdb to mdb in prod so trying to understand mdb. How does it work > in case of reads and writes? > > Thanks, > Ram > > On Tue, Oct 3, 2017 at 4:15 PM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > Quanah Gibson-Mount wrote: > > --On Tuesday, October 03, 2017 11:47 AM -0700 rammohan ganapavarapu > <rammohanganap(a)gmail.com <mailto:rammohanganap@gmail.com>> wrote: > > > Ok, but are there any casses where DB size can grow bigger then > RAM and > what will happen in that case? > > > Same thing that happens in any such case.. it'll start swapping. > > > LMDB never uses swap. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > <http://www.openldap.org/project/> > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Multiple index for a node
by Ervin Hegedüs 04 Oct '17

04 Oct '17

Hi there, is there any way to use multiple keys for a node in a LPD tree? I mean, there are several subtree-s: ou=company1,dc=foo,dc=com ou=company2,dc=foo,dc=com and I have to store the users under these subtrees. Sometimes the users have same names, eg. John Smith, and the nodes will be: uid=jsmith,ou=company1,dc=foo,dc=com uid=jsmith,ou=company2,dc=foo,dc=com but the any other attributes (sn, cn, ...) also the same. How do I set up the indexes? Thanks, a.

2 4

lmdb as a Lua database
by Russell Haley 04 Oct '17

04 Oct '17

Hi, So I'm using LMDB to create a simple 'database' system for lua that will allow me to directly serialize and store lua table data. So far I have used the wonderful lmdb wrapper lightningmdb and created a simple API to hide some of the mechanisms. Honestly, your API is so well thought out, I'm doing a disservice by removing a lot of the powerful features. However, I press ahead and beg forgiveness. :) I have two questions: 1) There is a simplified vs cursor API. I am starting to suspect that the simplified functions are just basic wrappers around the cursor API? I ask because if this is the case, I could just remove my support for the simplified API and only have to support one set of functions. 2) The key lookup is blazing fast (so awesome, this thing is going to smoke!). I wanted to create a way of indexing the data elements within the database by allowing users to create lua functions that parse the lua table values. --a basic table that would be serialized into a lmdb database called t1 t1 = { 1={col_a="test",col_b="item1"}, 2={col_a="not-a-test",col_b="item2"}, 3={col_a="test",col_b="item3"} } --The function that would be called per-row to create an index. local function(k,v) return v.col_a, k end The idea would be to use the dupsort feature to create an 'index' database with data structured as: not-a-test, 2 test, 1 test, 3

1 1

Can't get lmdb to build on FreeBSD 12
by Russell Haley 04 Oct '17

04 Oct '17

Hi, Sorry for the silly question, but I've stumped myself and my C is weak. Normally lmdb builds fine without issue on most of the platforms I try (Debian Jessie, FreeBSD 10.3 & 12), but it's stopped compiling on my TrueOS box, which is FreeBSD 12. I've tried gcc and clang 4.0 and 3.9. ------------------------ russellh@prescott:~/Git/lmdb/libraries/liblmdb% make cc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -v mdb_stat.c -o mdb_stat FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin "/usr/bin/cc" -cc1 -triple x86_64-unknown-freebsd12.0 -emit-obj -disable-free -main-file-name mdb_stat.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v -dwarf-column-info -debug-info-kind=standalone -dwarf-version=2 -debugger-tuning=gdb -resource-dir /usr/bin/../lib/clang/4.0.0 -O2 -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -fdebug-compilation-dir /usr/home/russellh/Git/lmdb/libraries/liblmdb -ferror-limit 19 -fmessage-length 237 -pthread -fobjc-runtime=gnustep -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o /tmp/mdb_stat-852384.o -x c mdb_stat.c clang -cc1 version 4.0.0 based upon LLVM 4.0.0 default target x86_64-unknown-freebsd12.0 #include "..." search starts here: #include <...> search starts here: /usr/bin/../lib/clang/4.0.0/include /usr/include End of search list. "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o mdb_stat /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/mdb_stat-852384.o -lgcc --as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o /tmp/mdb_stat-852384.o: In function `main': /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:104: undefined reference to `mdb_env_create' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:106: undefined reference to `mdb_strerror' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:111: undefined reference to `mdb_env_set_maxdbs' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:114: undefined reference to `mdb_env_open' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:116: undefined reference to `mdb_strerror' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:121: undefined reference to `mdb_env_stat' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:122: undefined reference to `mdb_env_info' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:136: undefined reference to `mdb_reader_list' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:139: undefined reference to `mdb_reader_check' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:141: undefined reference to `mdb_reader_list' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:147: undefined reference to `mdb_txn_begin' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:149: undefined reference to `mdb_strerror' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:257: undefined reference to `mdb_env_close' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:160: undefined reference to `mdb_cursor_open' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:162: undefined reference to `mdb_strerror' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:165: undefined reference to `mdb_stat' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:171: undefined reference to `mdb_cursor_get' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:171: undefined reference to `mdb_cursor_get' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:199: undefined reference to `mdb_cursor_close' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:203: undefined reference to `mdb_dbi_open' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:205: undefined reference to `mdb_strerror' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:209: undefined reference to `mdb_stat' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:(.text+0x5d6): undefined reference to `mdb_strerror' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:255: undefined reference to `mdb_txn_abort' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:221: undefined reference to `mdb_cursor_open' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:223: undefined reference to `mdb_strerror' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:226: undefined reference to `mdb_cursor_get' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:234: undefined reference to `mdb_dbi_open' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:239: undefined reference to `mdb_stat' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:245: undefined reference to `mdb_dbi_close' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:226: undefined reference to `mdb_cursor_get' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:247: undefined reference to `mdb_cursor_close' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:253: undefined reference to `mdb_dbi_close' /usr/home/russellh/Git/lmdb/libraries/liblmdb/mdb_stat.c:241: undefined reference to `mdb_strerror' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make: stopped in /usr/home/russellh/Git/lmdb/libraries/liblmdb ---------------------------------- The full output is here with uname, git status and compiler info: http://termbin.com/io9d Any help would be grand. Thanks, Russ

1 0

Re: Initialize ldap with mdb
by Howard Chu 04 Oct '17

04 Oct '17

Quanah Gibson-Mount wrote: > --On Tuesday, October 03, 2017 11:47 AM -0700 rammohan ganapavarapu > <rammohanganap(a)gmail.com> wrote: > >> >> Ok, but are there any casses where DB size can grow bigger then RAM and >> what will happen in that case? > > Same thing that happens in any such case.. it'll start swapping. LMDB never uses swap. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Initialize ldap with mdb
by Quanah Gibson-Mount 04 Oct '17

04 Oct '17

--On Wednesday, October 04, 2017 2:18 AM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > rammohan ganapavarapu wrote: >> You mean we can resize db any time? > > You can increase but *not decrease* maxsize later. I've been able to decrease it just fine, as long as it wasn't below the actual size of the DB. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Initialize ldap with mdb
by rammohan ganapavarapu 04 Oct '17

04 Oct '17

You mean we can resize db any time? Wouldn't it be nice to have no max limit and grow db dynamically? On Oct 3, 2017 4:05 PM, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote: --On Tuesday, October 03, 2017 5:04 PM -0700 rammohan ganapavarapu < rammohanganap(a)gmail.com> wrote: > Ok, i am just testing it, i will follow those recommendations, but this > is what i did as work around: > > > So i have updated the olcDbMaxSize to below value and now i am able to do > ldapadd, but i was in the impression that once u set the maxsize at the > time of ldap initialization you can't update that, right? > Incorrect. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Initialize ldap with mdb
by Quanah Gibson-Mount 04 Oct '17

04 Oct '17

--On Tuesday, October 03, 2017 5:12 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > You mean we can resize db any time? Wouldn't it be nice to have no max > limit and grow db dynamically? MDB needs a max size at startup, so you have to define one. Generally, it's recommended to set a large value. I wrote a script once to resize MDB upwards as it got close (20%) to its maxsize. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Initialize ldap with mdb
by Quanah Gibson-Mount 04 Oct '17

04 Oct '17

--On Tuesday, October 03, 2017 5:04 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Ok, i am just testing it, i will follow those recommendations, but this > is what i did as work around: > > > So i have updated the olcDbMaxSize to below value and now i am able to do > ldapadd, but i was in the impression that once u set the maxsize at the > time of ldap initialization you can't update that, right? Incorrect. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Initialize ldap with mdb
by rammohan ganapavarapu 04 Oct '17

04 Oct '17

Ok, i am just testing it, i will follow those recommendations, but this is what i did as work around: So i have updated the olcDbMaxSize to below value and now i am able to do ldapadd, but i was in the impression that once u set the maxsize at the time of ldap initialization you can't update that, right? echo "dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcDbMaxSize olcDbMaxSize: 21474836480" |ldapmodify -x -D "cn=config" -H ldap://localhost:10389 -w So the above operation will resize the db? Thanks, Ram On Tue, Oct 3, 2017 at 4:01 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Tuesday, October 03, 2017 4:53 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > >> Ok, this is what i see in ldap logs, this could be because of >> maxsize? olcDbMaxSize: 102400 >> >> >> mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize >> limit reached (-30792) >> > > Yes. Again, as I said before, you need to set a *large* maxsize. Like > the one I recommended previously. > > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Initialize ldap with mdb
by Quanah Gibson-Mount 04 Oct '17

04 Oct '17

--On Tuesday, October 03, 2017 4:53 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Ok, this is what i see in ldap logs, this could be because of > maxsize? olcDbMaxSize: 102400 > > > mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize > limit reached (-30792) Yes. Again, as I said before, you need to set a *large* maxsize. Like the one I recommended previously. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Initialize ldap with mdb
by rammohan ganapavarapu 04 Oct '17

04 Oct '17

There are two mdb files {data,lock}.mdb both owned by processes user. On Tue, Oct 3, 2017 at 3:41 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Tuesday, October 03, 2017 3:53 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > and now i am trying to add below and getting index generation failed >> error, db dir and slapd.d owned by slapd processes user. >> > > What about the *.mdb files themselves? > > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 1

Re: Initialize ldap with mdb
by Quanah Gibson-Mount 04 Oct '17

04 Oct '17

--On Tuesday, October 03, 2017 3:53 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > and now i am trying to add below and getting index generation failed > error, db dir and slapd.d owned by slapd processes user. What about the *.mdb files themselves? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Initialize ldap with mdb
by rammohan ganapavarapu 03 Oct '17

03 Oct '17

Quanah, I am not converting hdb to mdb, i am setting up fresh install with mdb, i have generated cn=config using slapd.conf and i was able to start the slapd, now i am trying to create my org structure. ldapsearch -x -D "cn=manager,dc=example,dc=com" -H ldap://localhost:10389 -LLL -w <> -b "dc=example,dc=com" dn: dc=example,dc=com objectClass: dcObject objectClass: organization dc: example o: Example description: Example dn: ou=global,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: global dn: ou=users,ou=global,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: users description: All global users in system and now i am trying to add below and getting index generation failed error, db dir and slapd.d owned by slapd processes user. dn: ou=userroles,ou=global,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: userroles Thanks, Ram On Tue, Oct 3, 2017 at 2:18 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Tuesday, October 03, 2017 3:07 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > >> Quanah, >> >> >> Any thing changed int index with mdb? i am getting this error when i try >> to add my top level entry. >> > > Why are you using ldapadd? Did you not read the process Michael and I > both described? > > It sounds like your mdb database is owned by root while your slapd process > runs as a different user? > > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Initialize ldap with mdb
by Quanah Gibson-Mount 03 Oct '17

03 Oct '17

--On Tuesday, October 03, 2017 3:07 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Any thing changed int index with mdb? i am getting this error when i try > to add my top level entry. Why are you using ldapadd? Did you not read the process Michael and I both described? It sounds like your mdb database is owned by root while your slapd process runs as a different user? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Initialize ldap with mdb
by rammohan ganapavarapu 03 Oct '17

03 Oct '17

Quanah, Any thing changed int index with mdb? i am getting this error when i try to add my top level entry. cat add.ldif dn: ou=userroles,ou=global,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: userroles adding new entry "ou=userroles,ou=global,dc=example,dc=com" ldap_add: Other (e.g., implementation specific) error (80) additional info: index generation failed Thanks, Ram On Tue, Oct 3, 2017 at 11:36 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Tuesday, October 03, 2017 12:29 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > >> Thank you, one more question on mdb side, may be last question :) >> >> >> How can i migrate/convert from hdb/bdb to mdb? >> > > Generally, you slapcat your existing HDB database to an LDIF file, update > your configuration for slapd to use MDB instead, and then use slapadd to > import the LDIF file. > > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Initialize ldap with mdb
by rammohan ganapavarapu 03 Oct '17

03 Oct '17

Thank you, one more question on mdb side, may be last question :) How can i migrate/convert from hdb/bdb to mdb? Ram On Tue, Oct 3, 2017 at 11:09 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Tuesday, October 03, 2017 11:47 AM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > >> Ok, but are there any casses where DB size can grow bigger then RAM and >> what will happen in that case? >> > > Same thing that happens in any such case.. it'll start swapping. > > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

2 1

Re: Initialize ldap with mdb
by Quanah Gibson-Mount 03 Oct '17

03 Oct '17

--On Tuesday, October 03, 2017 12:29 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Thank you, one more question on mdb side, may be last question :) > > > How can i migrate/convert from hdb/bdb to mdb? Generally, you slapcat your existing HDB database to an LDIF file, update your configuration for slapd to use MDB instead, and then use slapadd to import the LDIF file. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Initialize ldap with mdb
by Quanah Gibson-Mount 03 Oct '17

03 Oct '17

--On Tuesday, October 03, 2017 11:47 AM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Ok, but are there any casses where DB size can grow bigger then RAM and > what will happen in that case? Same thing that happens in any such case.. it'll start swapping. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Initialize ldap with mdb
by rammohan ganapavarapu 03 Oct '17

03 Oct '17

Ok, but are there any casses where DB size can grow bigger then RAM and what will happen in that case? On Oct 3, 2017 10:18 AM, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote: > --On Tuesday, October 03, 2017 11:03 AM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > >> Quanah, >> >> >> Quick question regarding "maxsize" in mdb, slapd-mdb man page says we >> have to preallocate the db size based on future growth of your data, that >> means will it create a data.mdb of maxsize? what i read from docs is, mdb >> loads whole database into memory, is it right? if my db size is grater >> then my RAM how does mdb handles? do we have any configuration options to >> set RAM allocation for mdb as i may have other applications sharing the >> same RAM? >> > > It uses RAM in accordance to the size of the database, not the maxsize. > Generally, you set the maxsize value to something really large and forget > about it. I would note you already have a fairly large database. However, > MDB should use significantly *less* RAM than your old back-hdb database > overall, because your old back-hdb DB had to use multiple caches in RAM as > a part of the slapd process (cachesize, idlcachesize, dncachesize) in > addition to the BDB cache (set_cachesize in DB_CONFIG). > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Initialize ldap with mdb
by Quanah Gibson-Mount 03 Oct '17

03 Oct '17

--On Tuesday, October 03, 2017 11:03 AM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Quick question regarding "maxsize" in mdb, slapd-mdb man page says we > have to preallocate the db size based on future growth of your data, that > means will it create a data.mdb of maxsize? what i read from docs is, mdb > loads whole database into memory, is it right? if my db size is grater > then my RAM how does mdb handles? do we have any configuration options to > set RAM allocation for mdb as i may have other applications sharing the > same RAM? It uses RAM in accordance to the size of the database, not the maxsize. Generally, you set the maxsize value to something really large and forget about it. I would note you already have a fairly large database. However, MDB should use significantly *less* RAM than your old back-hdb database overall, because your old back-hdb DB had to use multiple caches in RAM as a part of the slapd process (cachesize, idlcachesize, dncachesize) in addition to the BDB cache (set_cachesize in DB_CONFIG). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Initialize ldap with mdb
by rammohan ganapavarapu 03 Oct '17

03 Oct '17

Quanah, Quick question regarding "maxsize" in mdb, slapd-mdb man page says we have to preallocate the db size based on future growth of your data, that means will it create a data.mdb of maxsize? what i read from docs is, mdb loads whole database into memory, is it right? if my db size is grater then my RAM how does mdb handles? do we have any configuration options to set RAM allocation for mdb as i may have other applications sharing the same RAM? Thanks, Ram On Tue, Oct 3, 2017 at 8:08 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Monday, October 02, 2017 5:14 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > >> Thank you, would you recommend different user for replication or just use >> the roodn? i know its upto me but just trying to follow the best >> practices :) >> > > It is generally recommended not to use the rootdn for replication. > > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Initialize ldap with mdb
by Quanah Gibson-Mount 03 Oct '17

03 Oct '17

--On Monday, October 02, 2017 5:14 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Thank you, would you recommend different user for replication or just use > the roodn? i know its upto me but just trying to follow the best > practices :) It is generally recommended not to use the rootdn for replication. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: slapd: null_callback : error code 0x14
by Quanah Gibson-Mount 03 Oct '17

03 Oct '17

--On Monday, October 02, 2017 2:20 PM -0700 "Paul B. Henson" <henson(a)acm.org> wrote: > On Mon, Sep 25, 2017 at 04:31:40PM +0200, Ondřej Kuzník wrote: > >> I'd apply it everywhere you have syncprov configured, these could send a >> cookie with too little information for a replica to spot and skip a >> duplicate. > > Hmm, I applied the patch to all four of my servers but I'm still seeing > the errors :(... Are you positive the servers are in sync at this point? I.e., did you freshly reload from whatever you consider your golden master them after applying the patch? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Initialize ldap with mdb
by rammohan ganapavarapu 03 Oct '17

03 Oct '17

Thank you, would you recommend different user for replication or just use the roodn? i know its upto me but just trying to follow the best practices :) Ram On Mon, Oct 2, 2017 at 2:38 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Monday, October 02, 2017 3:30 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > > database config >> # rootdn directive for config >> rootdn "cn=admin,cn=config" >> rootpw {SSHA}XXXXXXXXX >> > > As noted in the slapd-config(5) man page, the default rootdn for cn=config > is cn=config. I'd generally go with the default. You would need to set > the rootpw as you've done above though. ;) > > I.e., I'd just do: > > database config > rootpw {SSHA}XXXXXXXXXXXXXXXX > > And go with the default rootdn. > > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Initialize ldap with mdb
by Quanah Gibson-Mount 02 Oct '17

02 Oct '17

--On Monday, October 02, 2017 3:30 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > database config ># rootdn directive for config > rootdn "cn=admin,cn=config" > rootpw {SSHA}XXXXXXXXX As noted in the slapd-config(5) man page, the default rootdn for cn=config is cn=config. I'd generally go with the default. You would need to set the rootpw as you've done above though. ;) I.e., I'd just do: database config rootpw {SSHA}XXXXXXXXXXXXXXXX And go with the default rootdn. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Initialize ldap with mdb
by rammohan ganapavarapu 02 Oct '17

02 Oct '17

Quanah, My slapd.d dir is empty and my initialization script only create config if slapd.d dir is empty, i tried with slapd.conf every thing looks good except i don't find a way to connect to cn=config db as i don't see roodDN in "cn\=config/olcDatabase\=\{0\}config.ldif" Thanks, Ram On Mon, Oct 2, 2017 at 1:35 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Monday, October 02, 2017 2:19 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > >> >> Hi, >> >> >> >> I am trying to follow this thread ( >> http://blog.roeften.com/2015/03/openldap-24-on-centos-7-using-mdb.html ) >> to initialize the ldap config in non-default directory but i am getting >> this error. >> >> >> cat example.ldif | slapadd -v -F /opt/data/slapd.d -n 0 -d -1 >> >> >> >> >> 59d29ce6 >>> dnPrettyNormal: <cn=config> >> 59d29ce6 <<< dnPrettyNormal: <cn=config>, <cn=config> >> 59d29ce6 str2entry: entry -1 has multiple DNs "cn=config" and >> "cn=module,cn=config" >> slapadd: could not parse entry (line=1) >> >> >> If i add one by one (one dn at a time) it seems to be working. >> >> >> Any idea? >> > > Well, if you already have your own cn=config database, then you're just > making a real mess out of it. That would be my guess. I'm not sure why > you're following some random "how to" guide. If you already had a working > slapd.conf, then all you needed to do was convert it to cn=config using > "slaptest". > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 1

Re: Initialize ldap with mdb
by Quanah Gibson-Mount 02 Oct '17

02 Oct '17

--On Monday, October 02, 2017 2:19 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > > Hi, > > > > I am trying to follow this thread ( > http://blog.roeften.com/2015/03/openldap-24-on-centos-7-using-mdb.html ) > to initialize the ldap config in non-default directory but i am getting > this error. > > > cat example.ldif | slapadd -v -F /opt/data/slapd.d -n 0 -d -1 > > > > > 59d29ce6 >>> dnPrettyNormal: <cn=config> > 59d29ce6 <<< dnPrettyNormal: <cn=config>, <cn=config> > 59d29ce6 str2entry: entry -1 has multiple DNs "cn=config" and > "cn=module,cn=config" > slapadd: could not parse entry (line=1) > > > If i add one by one (one dn at a time) it seems to be working. > > > Any idea? Well, if you already have your own cn=config database, then you're just making a real mess out of it. That would be my guess. I'm not sure why you're following some random "how to" guide. If you already had a working slapd.conf, then all you needed to do was convert it to cn=config using "slaptest". --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: slapd: null_callback : error code 0x14
by Quanah Gibson-Mount 02 Oct '17

02 Oct '17

--On Thursday, September 21, 2017 9:59 PM -0700 "Paul B. Henson" <henson(a)acm.org> wrote: > It seems there are updates for that group coming from rid 002 > (egeria.ldap.cpp.edu) and 003 (minerva.ldap.cpp.edu), but none from rid > 001 (themis.ldap.cpp.edu) which is serverid 4, where the change was > actually made? Oh, I thought you had said you only had two masters. This could well be ITS#8444 (ignore the ITS title, it has nothing to do with memberOf), where there are out of sync problems with 3+ MMR nodes and delta-syncrepl when syncprov checkpoints. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 4

Initialize ldap with mdb
by rammohan ganapavarapu 02 Oct '17

02 Oct '17

Hi, I am trying to follow this thread ( http://blog.roeften.com/2015/03/openldap-24-on-centos-7-using-mdb.html ) to initialize the ldap config in non-default directory but i am getting this error. cat example.ldif | slapadd -v -F /opt/data/slapd.d -n 0 -d -1 59d29ce6 >>> dnPrettyNormal: <cn=config> 59d29ce6 <<< dnPrettyNormal: <cn=config>, <cn=config> 59d29ce6 str2entry: entry -1 has multiple DNs "cn=config" and "cn=module,cn=config" slapadd: could not parse entry (line=1) If i add one by one (one dn at a time) it seems to be working. Any idea? Thanks

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by rammohan ganapavarapu 02 Oct '17

02 Oct '17

Quanah, Thank you. Ram On Mon, Oct 2, 2017 at 10:11 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Monday, October 02, 2017 10:59 AM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > >> Quanah, >> >> >> Where can i get a minimal slapd.conf/cn=config for mdb? also all >> supported properties for mdb? >> > > The man page for slapd-mdb notes what its configuration options are: > > <http://www.openldap.org/software/man.cgi?query=slapd-mdb& > apropos=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html> > > If you want a minimal slapd.conf for mdb, it's pretty basic: > > database mdb > directory </path/to/database> > index <indices> > maxsize 85899345920 > <db specific ACLs> > > > You could use slaptest to convert that trivially to cn=config > representation. > > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by Quanah Gibson-Mount 02 Oct '17

02 Oct '17

--On Monday, October 02, 2017 10:59 AM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Where can i get a minimal slapd.conf/cn=config for mdb? also all > supported properties for mdb? The man page for slapd-mdb notes what its configuration options are: <http://www.openldap.org/software/man.cgi?query=slapd-mdb&apropos=0&sektion=…> If you want a minimal slapd.conf for mdb, it's pretty basic: database mdb directory </path/to/database> index <indices> maxsize 85899345920 <db specific ACLs> You could use slaptest to convert that trivially to cn=config representation. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by rammohan ganapavarapu 02 Oct '17

02 Oct '17

Quanah, Where can i get a minimal slapd.conf/cn=config for mdb? also all supported properties for mdb? Thanks, Ram On Fri, Sep 29, 2017 at 2:32 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Friday, September 29, 2017 2:50 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > >> Quanah, >> >> >> Yes that is the plan but till i moved to latest version with mdb, i have >> to live with it. Regarding upgrading to latest with mdb, how can i >> migrate from hdb to mdb with out downtime? can i add latest openldap with >> mdb as replica to existing older/hdb instance? >> > > Yes, you can have an mdb-based server that is a replica from an existing > back-hdb server. > > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

country attribute
by richard lucassen 02 Oct '17

02 Oct '17

Hello list, Just a newbie question: I try to create a simple addressbook in LDAP and I just wondered why there is no country attribute in the standard structure: objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson Just an "st" attribute, but this should not be used for a country AFAIK. Is there an easy way to add the country or friendlyCountryName as a MAY attribute without having to create my own objectClass? R. -- richard lucassen http://contact.xaq.nl/

4 10

What is the current OLC way to replace the nis schema with the rfc2307bis schema?
by John Lewis 02 Oct '17

02 Oct '17

What is the current OLC way to replace the nis schema with the rfc2307bis schema? There are hacks published, but I couldn't find a document that takes advantage of OLC, removes the nis schema, and installs the rfc2307bis schema. It feels like something that I would do often enough that I would want to be able to do it one ldapmodify operation. There is a problem. There wasn't delete support in OLC 2.4 2012 in http ://www.openldap.org/lists/openldap-technical/201204/msg00245.html. OLC does support delete in 2.5 as of 2013 https://www.slideshare.net/ld apcon/whats-new-in-openldap. Since that has been established, what is the least hacky way to replace the nis schema with the rfc2307bis schema in 2.4?

2 1

Email based self registration
by John Lewis 02 Oct '17

02 Oct '17

Is there an application that supports both email based self registration and OpenLDAP storage of the account data?

2 1

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 2:50 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Yes that is the plan but till i moved to latest version with mdb, i have > to live with it. Regarding upgrading to latest with mdb, how can i > migrate from hdb to mdb with out downtime? can i add latest openldap with > mdb as replica to existing older/hdb instance? Yes, you can have an mdb-based server that is a replica from an existing back-hdb server. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by rammohan ganapavarapu 29 Sep '17

29 Sep '17

Quanah, Yes that is the plan but till i moved to latest version with mdb, i have to live with it. Regarding upgrading to latest with mdb, how can i migrate from hdb to mdb with out downtime? can i add latest openldap with mdb as replica to existing older/hdb instance? Thanks for all you suggestions Ram On Fri, Sep 29, 2017 at 1:38 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Friday, September 29, 2017 2:31 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > >> Quanah, >> >> >> Sorry i was searching for one attribute, i have close to 80mil entries. >> > > Then these settings may be too low: > > cachesize 100000 > idlcachesize 300000 > > Essentally, cachesize needs to hold your working set of data (active > entries). So this is saying slapd will only cache 100,000 active entries. > It will then be removing/adding entries in blocks of one (cachefree > defaults to 1 if not set). idlcachesize generally is 3x cachesize. > > If your active set is > 100,000 users, then you need to increase the > cachesize and idlcachesize parameters accordingly. You may also need to > increase cachefree from its default of "1". > > Overall, you would likely be much better served to switch to back-mdb, > where you do not have to set any of these parameters at all. > > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 5:03 PM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > At Fri, 29 Sep 2017 10:29:11 -0700 Quanah Gibson-Mount <quanah(a)symas.com> > wrote: > >> >> --On Friday, September 29, 2017 2:17 PM -0400 Robert Heller >> <heller(a)deepsoft.com> wrote: >> >> > Signature Algorithm: sha1WithRSAEncryption >> >> The above is probably your problem. I believe MozNSS will no longer >> accept SHA1 certs. This was in the link I sent you yesterday. >> Generate a more secure cert (I.e., SHA256 or higher). > > I replaced the certs with SHA256 versions and it is still not working: You need logs from SSSD detailing why it is failing to negotiate. As you noted before, ldapsearch/ldapwhoami etc work for you. If that is still the case now with your new certs, you will need to pursue support with RedHat, as this clearly is not an OpenLDAP issue. Sorry I can't be of any more help than that. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 2:31 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Sorry i was searching for one attribute, i have close to 80mil entries. Then these settings may be too low: cachesize 100000 idlcachesize 300000 Essentally, cachesize needs to hold your working set of data (active entries). So this is saying slapd will only cache 100,000 active entries. It will then be removing/adding entries in blocks of one (cachefree defaults to 1 if not set). idlcachesize generally is 3x cachesize. If your active set is > 100,000 users, then you need to increase the cachesize and idlcachesize parameters accordingly. You may also need to increase cachefree from its default of "1". Overall, you would likely be much better served to switch to back-mdb, where you do not have to set any of these parameters at all. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by rammohan ganapavarapu 29 Sep '17

29 Sep '17

Quanah, Sorry i was searching for one attribute, i have close to 80mil entries. Thanks, Ram On Fri, Sep 29, 2017 at 12:19 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Friday, September 29, 2017 1:00 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > >> I have roughly 57077 entires, so set_cachesize in slapd.conf will take >> highest priority than the one in DB_CONFIG file? >> > > If you ever delete the DB_CONFIG file, it would be created with the > setting from slapd.conf. Better to remove it. > > You say you have only 57,077 entries in your DB, yet your id2entry bdb > file is nearly 8GB in size? That doesn't make sense unless your BDB > database is very corrupted or you have insanely huge entries containing > gigabytes of binary data or something. > > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Thursday, September 28, 2017 5:37 PM -0400 Douglas Duckworth <dod2014(a)med.cornell.edu> wrote: > > What would you recommend as a replacement for SSSD? I am running it > across Centos 6 and 7 clients without any issue using TLS. There is nss-pam-ldapd/nslcd. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Thursday, September 28, 2017 2:08 PM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > OK, I have narrowed things down to slapd and sssd not playing nice with > each other. slapd is able to listen on ldaps (port 636) and accept SSL > connections (eg from openssl s_client and other applications using > straight SSL). slapd will also listen on ldap (port 389), but refuses > to negotiate a TLS connection on port 389. It also refuses to negotiate > TLS connection on port 636. sssd seems to *insist* on negotiating a TLS > connection on port 636 or port 389 and won't just connect using ssl to > port 636. (At least that is what I *think* is going on.) > > So, I either need to get slapd to do TLS negotiation on port 389 OR port > 636, or get sssd to NOT do TLS negotiation on port 636 and just connect > with SSL. You're using a bit of a confusing word soup. ldaps == Deprecated, non-standard way of securing connection to LDAP. Usually on port 636 startTLS == RFC standard way of securing connections to LDAP. Usually on port 389 If you are using ldaps, then you want startTLS to be disabled if you are using startTLS, then you want it enabled. Your SSD config has: ldap_id_use_start_tls = false so this would be correct with use with ldaps:/// You don't provide any error messages or other useful information, so one can only specualte what issues you may be having. I would note that most versions of openssl s_client do not support startTLS with LDAP (Thus you cannot use it to test port 389). That feature was only recently added to OpenSSL. If you want to test startTLS on port 389, your best bet is to use an ldap client utility such as ldapwhoami, like: ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 5

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 1:00 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > I have roughly 57077 entires, so set_cachesize in slapd.conf will take > highest priority than the one in DB_CONFIG file? If you ever delete the DB_CONFIG file, it would be created with the setting from slapd.conf. Better to remove it. You say you have only 57,077 entries in your DB, yet your id2entry bdb file is nearly 8GB in size? That doesn't make sense unless your BDB database is very corrupted or you have insanely huge entries containing gigabytes of binary data or something. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by rammohan ganapavarapu 29 Sep '17

29 Sep '17

I have roughly 57077 entires, so set_cachesize in slapd.conf will take highest priority than the one in DB_CONFIG file? Thanks, Ram On Fri, Sep 29, 2017 at 11:47 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Friday, September 29, 2017 12:39 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > >> Quanah, >> >> >> These are the settings i have in slapd.conf >> >> grep cach /etc/openldap/slapd.conf >> cachesize 100000 >> idlcachesize 300000 >> dbconfig set_cachesize 0 2097152 0 >> > > So how many total entries are in your database? You still haven't answered > that. > > Also, your dbconfig set_cachesize parameter is disturbingly low. You > should delete it to ensure the value in your DB_CONFIG file (8 0 1 remains > honored). > > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 12:39 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > These are the settings i have in slapd.conf > > grep cach /etc/openldap/slapd.conf > cachesize 100000 > idlcachesize 300000 > dbconfig set_cachesize 0 2097152 0 So how many total entries are in your database? You still haven't answered that. Also, your dbconfig set_cachesize parameter is disturbingly low. You should delete it to ensure the value in your DB_CONFIG file (8 0 1 remains honored). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by rammohan ganapavarapu 29 Sep '17

29 Sep '17

Quanah, These are the settings i have in slapd.conf grep cach /etc/openldap/slapd.conf cachesize 100000 idlcachesize 300000 dbconfig set_cachesize 0 2097152 0 On Fri, Sep 29, 2017 at 9:36 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Friday, September 29, 2017 10:31 AM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > >> Quanah, >> >> >> Thank you, please find the below db_stat output of whole db, i think >> which has all the cache details. >> > > The settings I'm talking about all come from slapd.conf/cn=config. They > are for the back-hdb backend, not for the underlying BDB library. > > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 11:29 AM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Friday, September 29, 2017 2:17 PM -0400 Robert Heller > <heller(a)deepsoft.com> wrote: > >> Signature Algorithm: sha1WithRSAEncryption > > The above is probably your problem. I believe MozNSS will no longer > accept SHA1 certs. This was in the link I sent you yesterday. Generate > a more secure cert (I.e., SHA256 or higher). See also: <https://access.redhat.com/blogs/766093/posts/3050871> where SHA1 is explicitly noted as being phased out. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 2:17 PM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > Signature Algorithm: sha1WithRSAEncryption The above is probably your problem. I believe MozNSS will no longer accept SHA1 certs. This was in the link I sent you yesterday. Generate a more secure cert (I.e., SHA256 or higher). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 10:31 AM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Thank you, please find the below db_stat output of whole db, i think > which has all the cache details. The settings I'm talking about all come from slapd.conf/cn=config. They are for the back-hdb backend, not for the underlying BDB library. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by rammohan ganapavarapu 29 Sep '17

29 Sep '17

Quanah, Thank you, please find the below db_stat output of whole db, i think which has all the cache details. sudo db_stat -h /var/lib/ldap/ -m *8GB Total cache size* 1 Number of caches 1 Maximum number of caches 8GB Pool individual cache size 0 Maximum memory-mapped file size 0 Maximum open file descriptors 0 Maximum sequential buffer writes 0 Sleep after writing maximum sequential buffers 0 Requested pages mapped into the process' address space 3653M Requested pages found in the cache (97%) 108M Requested pages not found in the cache (108847411) 12025 Pages created in the cache 108M Pages read into the cache (108846747) 904893 Pages written from the cache to the backing file 108M Clean pages forced from the cache (108193873) 25799 Dirty pages forced from the cache 0 Dirty pages written by trickle-sync thread 632880 Current total page count 632684 Current clean page count 196 Current dirty page count 1048573 Number of hash buckets used for page location 3816M Total number of times hash chains searched for a page (3816725185) 4 The longest hash chain searched for a page 1138M Total number of hash chain entries checked for page (1138407303) 22M The number of hash bucket locks that required waiting (0%) 3853441 The maximum number of times any hash bucket lock was waited for (0%) 20M The number of region locks that required waiting (5%) 0 The number of buffers frozen 0 The number of buffers thawed 0 The number of frozen buffers freed 112M The number of page allocations (112558585) 411M The number of hash buckets examined during allocations (411746763) 817981 The maximum number of hash buckets examined for an allocation 108M The number of pages examined during allocations (108226732) 45 The max number of pages examined for an allocation *1059517 Threads waited on page I/O* Pool File: labeledURI.bdb 4096 Page size 0 Requested pages mapped into the process' address space 1208388 Requested pages found in the cache (98%) 12848 Requested pages not found in the cache 0 Pages created in the cache 12848 Pages read into the cache 58547 Pages written from the cache to the backing file Pool File: entryUUID.bdb 4096 Page size 0 Requested pages mapped into the process' address space 861152 Requested pages found in the cache (87%) 121983 Requested pages not found in the cache 715 Pages created in the cache 121983 Pages read into the cache 87555 Pages written from the cache to the backing file Pool File: entryCSN.bdb 4096 Page size 0 Requested pages mapped into the process' address space 8632364 Requested pages found in the cache (97%) 194590 Requested pages not found in the cache 540 Pages created in the cache 194590 Pages read into the cache 5284 Pages written from the cache to the backing file Pool File: mail.bdb 4096 Page size 0 Requested pages mapped into the process' address space 160116 Requested pages found in the cache (96%) 5158 Requested pages not found in the cache 8 Pages created in the cache 5158 Pages read into the cache 779 Pages written from the cache to the backing file Pool File: o.bdb 4096 Page size 0 Requested pages mapped into the process' address space 20658 Requested pages found in the cache (84%) 3786 Requested pages not found in the cache 2 Pages created in the cache 3786 Pages read into the cache 611 Pages written from the cache to the backing file Pool File: uid.bdb 4096 Page size 0 Requested pages mapped into the process' address space 337280 Requested pages found in the cache (82%) 72796 Requested pages not found in the cache 286 Pages created in the cache 72796 Pages read into the cache 35684 Pages written from the cache to the backing file Pool File: objectClass.bdb 4096 Page size 0 Requested pages mapped into the process' address space 9471473 Requested pages found in the cache (99%) 1007 Requested pages not found in the cache 0 Pages created in the cache 1007 Pages read into the cache 11899 Pages written from the cache to the backing file Pool File: id2entry.bdb 16384 Page size 0 Requested pages mapped into the process' address space 1589M Requested pages found in the cache (97%) 42M Requested pages not found in the cache (42465108) 4226 Pages created in the cache 42M Pages read into the cache (42464602) 15359 Pages written from the cache to the backing file Pool File: roleOccupant.bdb 4096 Page size 0 Requested pages mapped into the process' address space 2593856 Requested pages found in the cache (99%) 18997 Requested pages not found in the cache 0 Pages created in the cache 18997 Pages read into the cache 7577 Pages written from the cache to the backing file Pool File: sn.bdb 4096 Page size 0 Requested pages mapped into the process' address space 38868 Requested pages found in the cache (94%) 2238 Requested pages not found in the cache 10 Pages created in the cache 2238 Pages read into the cache 1969 Pages written from the cache to the backing file Pool File: ou.bdb 4096 Page size 0 Requested pages mapped into the process' address space 66618 Requested pages found in the cache (97%) 1869 Requested pages not found in the cache 5 Pages created in the cache 1869 Pages read into the cache 3387 Pages written from the cache to the backing file Pool File: dn2id.bdb 4096 Page size 0 Requested pages mapped into the process' address space 2003M Requested pages found in the cache (96%) 65M Requested pages not found in the cache (65777491) 5705 Pages created in the cache 65M Pages read into the cache (65777333) 19992 Pages written from the cache to the backing file Pool File: cn.bdb 4096 Page size 0 Requested pages mapped into the process' address space 38M Requested pages found in the cache (99%) 169540 Requested pages not found in the cache 528 Pages created in the cache 169540 Pages read into the cache 656250 Pages written from the cache to the backing file On Fri, Sep 29, 2017 at 8:36 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, September 28, 2017 8:33 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > >> [root@localhost ldap]# db_stat -d id2entry.bdb >> Thu Sep 21 22:16:15 2017 Local time >> >> >> date >> ^CKilled >> > > > I can tell you that doing the above is very bad, as it can leave > unfinished read transactions alive in the database, causing problems. So > doing the db_recover you did after that was a good thing to do. > > What you haven't addressed is what your cachesize/idlcachesize/dncachesize/cachefree > parameters are for slapd, nor what the total number of DNs are in your > database. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Friday, September 29, 2017 1:07 PM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > At Fri, 29 Sep 2017 10:47:48 -0400 brendan kearney <bpk678(a)gmail.com> > wrote: > >> >> >> SASL is a "glue" between LDAP and Kerberos, that translates an identity >> established through Kerberos AuthN to an LDAP Distinguished Name (among >> other possible uses). When communications between Kerberos and LDAP >> happen, SASL also provides encryption. >> >> I have setup Kerberos, SASL, OpenLDAP and SSSD all on Fedora and it all >> works. I dont have to muck with SSL/TLS and the different >> implementations with their specific nuances. > > Don't you still need a SSL Certificate? That is, SSL/TLS is still there > someplace? No. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Thursday, September 28, 2017 8:33 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > [root@localhost ldap]# db_stat -d id2entry.bdb > Thu Sep 21 22:16:15 2017 Local time > > > date > ^CKilled I can tell you that doing the above is very bad, as it can leave unfinished read transactions alive in the database, causing problems. So doing the db_recover you did after that was a good thing to do. What you haven't addressed is what your cachesize/idlcachesize/dncachesize/cachefree parameters are for slapd, nor what the total number of DNs are in your database. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Douglas Duckworth 29 Sep '17

29 Sep '17

SSSD should be configured to bind TLS with ldap:389 not ldaps:636. Increase SSSD log verbosity to get more information. I have also found that slapd logging can help determine bind issues. How does one estalish their own CA that's trusted by other Root CA's? Perhaps try disabling verification of the chain then see if bind happens. On Sep 28, 2017 9:14 PM, "Robert Heller" <heller(a)deepsoft.com> wrote: > At Thu, 28 Sep 2017 16:08:42 -0700 Quanah Gibson-Mount <quanah(a)symas.com> > wrote: > > > > > --On Thursday, September 28, 2017 7:28 PM -0400 Robert Heller > > <heller(a)deepsoft.com> wrote: > > > > > At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount < > quanah(a)symas.com> > > > wrote: > > > > > >> > > >> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller > > >> <heller(a)deepsoft.com> wrote: > > >> > > >> > > >> > Slapd is reporting TLS Negotiation failure when SSSD tries to > connect > > >> > to it. For both port 389 (ldap:///) and 636 (ldaps:///). So I > guess > > >> > something is wrong with slapd's TLS configuration -- it is failing > to > > >> > do TLS Negotiation, either it is just not doing it or it is doing > it > > >> > wrong (somehow). Unless SSSD is not configured properly. > > >> > > >> You need to start with the following: > > >> > > >> >> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w > > >> > > >> to test startTLS > > >> > > >> and > > >> > > >> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w > > >> > > >> to test without startTLS > > >> > > >> If you can get those to work, then you can move on to SSSD. > > > > > > [heller@c764guest ~]$ ldapwhoami -x -ZZ -H ldap://c764guest:389 -D > > > cn=Manager,dc=deepsoft,dc=com -W ldap_start_tls: Connect error (-11) > > > additional info: TLS error -8157:Certificate extension not > found. > > > > This may be of help: > > <https://urldefense.proofpoint.com/v2/url?u=https- > 3A__serverfault.com_questions_640910_my-2Dcertificate- > 2Ddoesnt-2Dwork-2Don-2Dall-2Dmachines&d=DwIBAg&c= > lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e- > CbhH6xUjnRkaqPFUS2wTJ2cw&m=fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s= > h0ZJ27HydY4c7iw8uXd-1iadz94M-ZzNGL7KMfOsi2w&e=> > > > > > [heller@c764guest ~]$ ldapwhoami -x -H ldaps://c764guest:636 -D > > > cn=Manager,dc=deepsoft,dc=com -W Enter LDAP Password: > > > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > > > > This may mean slapd isn't listening on port 636 (With no -d -1 info, hard > > to know for sure). It may also simply be a different manifistation of > the > > error above. > > I added a -d option (picked 10), and discovered that it wanted the full > name > as specificed in the certificate. That fixed ldapwhoami and I put that in > ldap.conf, smb.conf, and in sssd.conf, but sssd is still not behaving > (samba > is though, mostly -- it might also be having issues since sssd is not > working)... > > > > > --Quanah > > > > > > -- > > > > Quanah Gibson-Mount > > Product Architect > > Symas Corporation > > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.symas.com&d=DwIBAg&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s=4Jyip- > C583CeHTI2N1wXllUKzrjwwvY9tqyl3tZVq8w&e=> > > > > > > -- > Robert Heller -- 978-544-6933 > Deepwoods Software -- Custom Software Services > https://urldefense.proofpoint.com/v2/url?u=http-3A__www. > deepsoft.com_&d=DwIBAg&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s=hf9o7fTr6iLSDpsS6xK6nGDWhZo- > N7aXcKoRAXfrPUE&e= -- Linux Administration Services > heller(a)deepsoft.com -- Webhosting Services > > >

2 1

Re: Re: Openldap periodic cpu spikes in one of the servers in two node MMR
by rammohan ganapavarapu 29 Sep '17

29 Sep '17

Thank you, from the provided stack trace, can any one tell what is the issue? Ram On Thu, Sep 28, 2017 at 11:46 PM, Ulrich Windl < Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > >>> rammohan ganapavarapu <rammohanganap(a)gmail.com> schrieb am 29.09.2017 > um 04:33 > in Nachricht > <CALm_VjjtxJM+dEDbERPKQOz3pO84ONddvC+EzwznH2=gNwgNMw(a)mail.gmail.com>: > > Still looking for help > > Hi! > > If you have a lot of disk space and you are willing to slow don slapd > while debugging, you could try to use ltrace instead of strace to get some > more details. Depending on the compiler's optimizations you may miss some > string and memory functions, however. > > Regards, > Ulrich > > > >

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by brendan kearney 29 Sep '17

29 Sep '17

SASL is a "glue" between LDAP and Kerberos, that translates an identity established through Kerberos AuthN to an LDAP Distinguished Name (among other possible uses). When communications between Kerberos and LDAP happen, SASL also provides encryption. I have setup Kerberos, SASL, OpenLDAP and SSSD all on Fedora and it all works. I dont have to muck with SSL/TLS and the different implementations with their specific nuances. Though you dont know much about Kerberos, its not too difficult to implement. You seem to have the aptitude to do so. Might just be a matter of reading up on how to. On Sep 29, 2017 10:00 AM, "Robert Heller" <heller(a)deepsoft.com> wrote: > At Fri, 29 Sep 2017 07:52:34 -0400 brendan kearney <bpk678(a)gmail.com> > wrote: > > > > > > > Late ti the thread, so forgive the stupid question, but why arent you > using > > SASL and forgoing all the OpenSSL vs MozNSS kerfuffle? If you have > OpenLDAP > > and SSSD going on, surely Kerberos is something you are able to setup. > > Does SASL replace TLS/SSL? I thought SASL had to do with password hashing > and > not anything to do with the connection protocol. I know basicly nothing > about > Kerberos. > > > > > On Sep 29, 2017 2:20 AM, "Michael Wandel" <m.wandel(a)t-online.de> wrote: > > > > > On 28.09.2017 21:41, Robert Heller wrote: > > > > Will these spit out useful error messages? If I just get "TLS > > > Negotiation > > > > failure" it is not going to be helpful. > > > > > > > > > > You can make it a little bit more verbose with the option "-d -1" > > > > > > It is only a suggestion, but can you test the parameter > > > > > > TLS_REQCERT allow > > > > > > in your /etc/openldap/ldap.conf > > > > > > This ist not a good option for production systems, but it seems you > come > > > in trouble with your certificates. > > > > > > You have to set your > > > > > > TLS_CACERT > > > xor > > > TLS_CACERTDIR > > > > > > correctly in your /etc/openldap/slapd.conf to work stressless with your > > > ssl/tls. > > > > > > best regards > > > Michael > > > > > > > At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount < > quanah(a)symas.com> > > > wrote: > > > > > > > >> > > > >> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller > > > >> <heller(a)deepsoft.com> wrote: > > > >> > > > >> > > > >>> Slapd is reporting TLS Negotiation failure when SSSD tries to > connect > > > to > > > >>> it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess > > > >>> something is wrong with slapd's TLS configuration -- it is > failing to > > > do > > > >>> TLS Negotiation, either it is just not doing it or it is doing it > > > wrong > > > >>> (somehow). Unless SSSD is not configured properly. > > > >> > > > >> You need to start with the following: > > > >> > > > >>>> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w > > > >> > > > >> to test startTLS > > > >> > > > >> and > > > >> > > > >> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w > > > >> > > > >> to test without startTLS > > > >> > > > >> If you can get those to work, then you can move on to SSSD. > > > >> > > > >> --Quanah > > > >> > > > >> -- > > > >> > > > >> Quanah Gibson-Mount > > > >> Product Architect > > > >> Symas Corporation > > > >> Packaged, certified, and supported LDAP solutions powered by > OpenLDAP: > > > >> <http://www.symas.com> > > > >> > > > >> > > > > > > > > > > > > > -- > > > Michael Wandel > > > Braakstraße 43 > > > 33647 Bielefeld > > > > > > > > > > > > -- > Robert Heller -- 978-544-6933 > Deepwoods Software -- Custom Software Services > http://www.deepsoft.com/ -- Linux Administration Services > heller(a)deepsoft.com -- Webhosting Services > >

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > Slapd is reporting TLS Negotiation failure when SSSD tries to connect to > it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess > something is wrong with slapd's TLS configuration -- it is failing to do > TLS Negotiation, either it is just not doing it or it is doing it wrong > (somehow). Unless SSSD is not configured properly. You need to start with the following: >> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w to test startTLS and ldapwhoami -x -H ldaps://myhost:636 -D binddn -w to test without startTLS If you can get those to work, then you can move on to SSSD. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 4

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Douglas Duckworth 29 Sep '17

29 Sep '17

I went with SSSD instead as it allows offline auth and autofs caching. On Sep 28, 2017 4:51 PM, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote: > --On Thursday, September 28, 2017 5:37 PM -0400 Douglas Duckworth > <dod2014(a)med.cornell.edu> wrote: > > > > > What would you recommend as a replacement for SSSD? I am running it > > across Centos 6 and 7 clients without any issue using TLS. > > There is nss-pam-ldapd/nslcd. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.symas.com&d=DwIFaQ&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > LzcKRiZzvWOzEj0Z8e60eBR_Ko8L_x3Z2raLoWXdyUA&s= > CyClJ9BrAhTZzEZ72MrchueJLdrQJoYUs-edF8f0Uw8&e=> > >

1 0

Openldap periodic cpu spikes in one of the servers in two node MMR
by rammohan ganapavarapu 29 Sep '17

29 Sep '17

Hi, I have two node MMR ldap cluster with hdb, but for some reason one of the servers CPU get spiked every minute, I am not sure what is causing this spike every minute, we have same server configuration in both the server. Also when i do db_stat on *.bdb files this server is taking too long to respond for db_stat, i am pasting top and strace out put of that thread here. Also attach a graph shows cpu spikes and active threads spikes in both the servers (green and yellow lines), *Openldap Version: openldap-2.4.43* [root@localhost ldap]# db_stat -d id2entry.bdb Thu Sep 21 22:16:15 2017 Local time date ^CKilled [root@localhost ldap]# date Thu Sep 21 22:27:54 UTC 2017 * du -sh id2entry.bdb* *7.6G id2entry.bdb* DB_CONFIG sudo cat /var/lib/ldap/DB_CONFIG |grep -v "^#" set_cachesize 8 0 1 set_lg_regionmax 262144 set_lg_bsize 2097152 set_lk_max_locks 3000 set_lk_max_objects 1500 set_lk_max_lockers 1500 *Top output of busy thread at the time of cpu spike:* ldap_top..20170922.165808.886367620: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:01.04 slapd ldap_top..20170922.165811.390769103: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:01.04 slapd ldap_top..20170922.165813.895158022: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:01.04 slapd ldap_top..20170922.165816.399627768: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:01.04 slapd ldap_top..20170922.165818.903936890: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:01.04 slapd ldap_top..20170922.165821.408275241: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:01.04 slapd ldap_top..20170922.165823.912707039: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:01.05 slapd ldap_top..20170922.165826.417287284: 61437 ldap 20 0 14.8g 13g 8.2g R 101.8 47.5 18:02.51 slapd ldap_top..20170922.165828.922186726: 61437 ldap 20 0 14.8g 13g 8.2g R 99.8 47.5 18:05.01 slapd ldap_top..20170922.165831.427101922: 61437 ldap 20 0 14.8g 13g 8.2g R 99.8 47.5 18:07.51 slapd ldap_top..20170922.165833.931996934: 61437 ldap 20 0 14.8g 13g 8.2g R 99.8 47.5 18:09.92 slapd ldap_top..20170922.165836.436814788: 61437 ldap 20 0 14.8g 13g 8.2g R 99.8 47.5 18:12.42 slapd ldap_top..20170922.165838.941597309: 61437 ldap 20 0 14.8g 13g 8.2g R 99.8 47.5 18:14.92 slapd ldap_top..20170922.165841.446448385: 61437 ldap 20 0 14.8g 13g 8.2g R 99.8 47.5 18:17.18 slapd ldap_top..20170922.165843.951329579: 61437 ldap 20 0 14.8g 13g 8.2g R 97.8 47.5 18:19.67 slapd ldap_top..20170922.165846.456172321: 61437 ldap 20 0 14.8g 13g 8.2g R 99.8 47.5 18:21.85 slapd ldap_top..20170922.165848.961017603: 61437 ldap 20 0 14.8g 13g 8.2g R 99.8 47.5 18:24.35 slapd ldap_top..20170922.165851.465897714: 61437 ldap 20 0 14.8g 13g 8.2g R 101.8 47.5 18:26.49 slapd ldap_top..20170922.165853.970797751: 61437 ldap 20 0 14.8g 13g 8.2g S 57.9 47.5 18:28.77 slapd ldap_top..20170922.165856.475641225: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.77 slapd ldap_top..20170922.165858.980268851: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.77 slapd ldap_top..20170922.165901.485817704: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.77 slapd ldap_top..20170922.165903.990499397: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165906.495260168: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165909.078879876: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165911.583657585: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165914.088384025: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165916.593114635: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165919.097562041: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165921.602221629: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165924.106739600: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165926.611115008: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165929.115600777: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165931.620082217: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd ldap_top..20170922.165934.124916755: 61437 ldap 20 0 14.8g 13g 8.2g S 0.0 47.5 18:28.78 slapd *strace output on that thread around that time:* grep "16:58:26" ldap_strace.61437 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea40, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea40, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea40, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea40, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x560271548120, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x560271548120, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) 16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0 *Here is the disk activity metrics and corresponding pstack ouput captured at different time when the system is not serving any traffic other than replication:* 04:20:32 PM 19169 0.00 10042.00 0.00 slapd 04:20:34 PM 19169 0.00 45850.00 0.00 slapd 04:20:36 PM 19169 0.00 35706.00 0.00 slapd 04:20:38 PM 19169 0.00 37096.00 0.00 slapd 04:20:40 PM 19169 0.00 43654.00 0.00 slapd 04:20:40 PM PID kB_rd/s kB_wr/s kB_ccwr/s Command 04:20:42 PM 19169 0.00 42948.00 0.00 slapd 04:20:44 PM 19169 0.00 43272.00 0.00 slapd 04:20:46 PM 19169 0.00 37084.00 0.00 slapd 04:20:48 PM 19169 0.00 22740.00 0.00 slapd 04:20:50 PM 19169 0.00 23540.00 0.00 slapd 04:20:52 PM 19169 0.00 23540.00 0.00 slapd 04:20:54 PM 19169 0.00 7458.00 0.00 slapd 04:20:56 PM 19169 0.00 0.00 0.00 slapd 04:20:58 PM 19169 0.00 0.00 0.00 slapd 04:21:00 PM 19169 0.00 0.00 0.00 slapd 04:21:02 PM 19169 0.00 0.00 0.00 slapd 04:21:04 PM 19169 0.00 0.00 0.00 slapd 04:21:06 PM 19169 0.00 0.00 0.00 slapd 04:21:08 PM 19169 0.00 0.00 0.00 slapd 04:21:10 PM 19169 0.00 30.00 0.00 slapd 04:21:12 PM 19169 0.00 0.00 0.00 slapd 04:21:14 PM 19169 0.00 0.00 0.00 slapd 04:21:16 PM 19169 0.00 0.00 0.00 slapd 04:21:18 PM 19169 4.00 346.00 0.00 slapd 04:21:20 PM 19169 24.00 1012.00 0.00 slapd 04:21:20 PM PID kB_rd/s kB_wr/s kB_ccwr/s Command 04:21:22 PM 19169 0.00 14.00 0.00 slapd 04:21:24 PM 19169 6.00 1098.00 0.00 slapd 04:21:26 PM 19169 24.00 302.00 0.00 slapd 04:21:28 PM 19169 82.00 598.00 0.00 slapd 04:21:30 PM 19169 82.00 582.00 0.00 slapd 04:21:32 PM 19169 10.00 114.00 0.00 slapd 04:21:34 PM 19169 14.00 1854.00 0.00 slapd 04:21:36 PM 19169 6.00 608.00 0.00 slapd 04:21:38 PM 19169 6.00 502.00 0.00 slapd 04:21:40 PM 19169 10.00 992.00 0.00 slapd 04:21:42 PM 19169 28.00 5620.00 0.00 slapd 04:21:44 PM 19169 0.00 0.00 0.00 slapd 04:21:46 PM 19169 0.00 0.00 0.00 slapd 04:21:48 PM 19169 0.00 0.00 0.00 slapd 04:21:50 PM 19169 0.00 0.00 0.00 slapd 04:21:52 PM 19169 0.00 0.00 0.00 slapd 04:21:54 PM 19169 0.00 1018.00 0.00 slapd 04:21:56 PM 19169 0.00 44146.00 0.00 slapd 04:21:58 PM 19169 0.00 39188.00 0.00 slapd 04:22:00 PM 19169 0.00 43206.00 0.00 slapd 04:22:00 PM PID kB_rd/s kB_wr/s kB_ccwr/s Command 04:22:02 PM 19169 0.00 39266.00 0.00 slapd 04:22:04 PM 19169 0.00 43240.00 0.00 slapd 04:22:06 PM 19169 0.00 44358.00 0.00 slapd 04:22:08 PM 19169 0.00 43790.00 0.00 slapd 04:22:10 PM 19169 0.00 38186.00 0.00 slapd 04:22:12 PM 19169 0.00 36304.00 0.00 slapd 04:22:14 PM 19169 0.00 42903.48 0.00 slapd 04:22:16 PM 19169 0.00 42246.00 0.00 slapd 04:22:18 PM 19169 0.00 9720.00 0.00 slapd *Thu Sep 21 16:20:40 UTC 2017* Thread 14 (Thread 0x7fc4eb57c700 (LWP 19171)): #0 0x00007fc702d3d8e3 in epoll_wait () from /lib64/libc.so.6 #1 0x00005638f66beda9 in ?? () #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 13 (Thread 0x7fc4ead7b700 (LWP 19172)): #0 0x00007fc704acce6c in __db_tas_mutex_unlock () from /lib64/libdb-4.7.so #1 0x00007fc704b74738 in __dbc_close () from /lib64/libdb-4.7.so #2 0x00007fc704b7492d in ?? () from /lib64/libdb-4.7.so #3 0x00007fc704b750da in __dbc_get () from /lib64/libdb-4.7.so #4 0x00007fc704b7f9dd in __dbc_get_pp () from /lib64/libdb-4.7.so #5 0x00005638f67a458c in hdb_id2entry () #6 0x00005638f679b6f8 in hdb_cache_find_id () #7 0x00005638f675041d in hdb_search () #8 0x00005638f67304c2 in overlay_op_walk () #9 0x00005638f6730624 in ?? () #10 0x00005638f66c69e9 in fe_op_search () #11 0x00005638f66c62b6 in do_search () #12 0x00005638f66c3ad4 in ?? () #13 0x00005638f66c3e3b in ?? () #14 0x00007fc705441afa in ?? () from /lib64/libldap_r-2.4.so.2 #15 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x7fc4ea57a700 (LWP 19173)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 11 (Thread 0x7fc4e9d79700 (LWP 19174)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 10 (Thread 0x7fc4e9578700 (LWP 19175)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x7fc4e8d77700 (LWP 19176)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x7fc4d7fff700 (LWP 19179)): #0 0x00007fc7032229ad in connect () from /lib64/libpthread.so.0 #1 0x00007fc705458d0c in ldap_connect_to_host () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc705442ece in ldap_int_open_connection () from /lib64/libldap_r-2.4.so.2 #3 0x00007fc705455f1d in ldap_new_connection () from /lib64/libldap_r-2.4.so.2 #4 0x00007fc7054424bf in ldap_open_defconn () from /lib64/libldap_r-2.4.so.2 #5 0x00007fc705457458 in ldap_send_initial_request () from /lib64/libldap_r-2.4.so.2 #6 0x00007fc70544c63f in ldap_sasl_bind () from /lib64/libldap_r-2.4.so.2 #7 0x00007fc70544ca19 in ldap_sasl_bind_s () from /lib64/libldap_r-2.4.so.2 #8 0x00005638f66baf52 in slap_client_connect () #9 0x00005638f672997d in ?? () #10 0x00007fc705441afa in ?? () from /lib64/libldap_r-2.4.so.2 #11 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #12 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x7fc4d77fe700 (LWP 19293)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x7fc4d6ffd700 (LWP 23630)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 5 (Thread 0x7fc4d67fc700 (LWP 23631)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7fc4d5ffb700 (LWP 23632)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7fc4d57fa700 (LWP 23633)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7fc4d4ff9700 (LWP 23634)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fc705895780 (LWP 19169)): #0 0x00007fc70321cf17 in pthread_join () from /lib64/libpthread.so.0 #1 0x00005638f66c0dc9 in slapd_daemon () #2 0x00005638f66a7d68 in main () *Thu Sep 21 16:20:42 UTC 2017* Thread 14 (Thread 0x7fc4eb57c700 (LWP 19171)): #0 0x00007fc702d3d8e3 in epoll_wait () from /lib64/libc.so.6 #1 0x00005638f66beda9 in ?? () #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 13 (Thread 0x7fc4ead7b700 (LWP 19172)): #0 0x00005638f66cfa88 in entry_decode () #1 0x00005638f67a44a2 in hdb_id2entry () #2 0x00005638f679b6f8 in hdb_cache_find_id () #3 0x00005638f675041d in hdb_search () #4 0x00005638f67304c2 in overlay_op_walk () #5 0x00005638f6730624 in ?? () #6 0x00005638f66c69e9 in fe_op_search () #7 0x00005638f66c62b6 in do_search () #8 0x00005638f66c3ad4 in ?? () #9 0x00005638f66c3e3b in ?? () #10 0x00007fc705441afa in ?? () from /lib64/libldap_r-2.4.so.2 #11 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #12 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x7fc4ea57a700 (LWP 19173)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 11 (Thread 0x7fc4e9d79700 (LWP 19174)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 10 (Thread 0x7fc4e9578700 (LWP 19175)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x7fc4e8d77700 (LWP 19176)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x7fc4d7fff700 (LWP 19179)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x7fc4d77fe700 (LWP 19293)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x7fc4d6ffd700 (LWP 23630)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 5 (Thread 0x7fc4d67fc700 (LWP 23631)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7fc4d5ffb700 (LWP 23632)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7fc4d57fa700 (LWP 23633)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7fc4d4ff9700 (LWP 23634)): #0 0x00007fc70321f905 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fc705441b4b in ?? () from /lib64/libldap_r-2.4.so.2 #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fc705895780 (LWP 19169)): #0 0x00007fc70321cf17 in pthread_join () from /lib64/libpthread.so.0 #1 0x00005638f66c0dc9 in slapd_daemon () #2 0x00005638f66a7d68 in main () Thu Sep 21 16:20:44 UTC 2017 Thread 14 (Thread 0x7fc4eb57c700 (LWP 19171)): #0 0x00007fc702d3d8e3 in epoll_wait () from /lib64/libc.so.6 #1 0x00005638f66beda9 in ?? () #2 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #3 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 13 (Thread 0x7fc4ead7b700 (LWP 19172)): #0 0x00005638f6706b30 in ad_keystring () #1 0x00005638f6706c6e in slap_bv2ad () #2 0x00005638f66cf9d6 in entry_decode () #3 0x00005638f67a44a2 in hdb_id2entry () #4 0x00005638f679b6f8 in hdb_cache_find_id () #5 0x00005638f675041d in hdb_search () #6 0x00005638f67304c2 in overlay_op_walk () #7 0x00005638f6730624 in ?? () #8 0x00005638f66c69e9 in fe_op_search () #9 0x00005638f66c62b6 in do_search () #10 0x00005638f66c3ad4 in ?? () #11 0x00005638f66c3e3b in ?? () #12 0x00007fc705441afa in ?? () from /lib64/libldap_r-2.4.so.2 #13 0x00007fc70321bde5 in start_thread () from /lib64/libpthread.so.0 #14 0x00007fc702d3d30d in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x7fc4ea57a700 (LWP 19173)): After i did db_recover db_stat is responding fast but cpu spikes are still there, is there any way to find if my db is bad? Thanks, Ram

2 3

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Thursday, September 28, 2017 7:28 PM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount <quanah(a)symas.com> > wrote: > >> >> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller >> <heller(a)deepsoft.com> wrote: >> >> >> > Slapd is reporting TLS Negotiation failure when SSSD tries to connect >> > to it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess >> > something is wrong with slapd's TLS configuration -- it is failing to >> > do TLS Negotiation, either it is just not doing it or it is doing it >> > wrong (somehow). Unless SSSD is not configured properly. >> >> You need to start with the following: >> >> >> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w >> >> to test startTLS >> >> and >> >> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w >> >> to test without startTLS >> >> If you can get those to work, then you can move on to SSSD. > > [heller@c764guest ~]$ ldapwhoami -x -ZZ -H ldap://c764guest:389 -D > cn=Manager,dc=deepsoft,dc=com -W ldap_start_tls: Connect error (-11) > additional info: TLS error -8157:Certificate extension not found. This may be of help: <https://serverfault.com/questions/640910/my-certificate-doesnt-work-on-all-…> > [heller@c764guest ~]$ ldapwhoami -x -H ldaps://c764guest:636 -D > cn=Manager,dc=deepsoft,dc=com -W Enter LDAP Password: > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) This may mean slapd isn't listening on port 636 (With no -d -1 info, hard to know for sure). It may also simply be a different manifistation of the error above. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 28 Sep '17

28 Sep '17

--On Thursday, September 28, 2017 11:26 PM +0200 Dieter Kluenter <dieter(a)dkluenter.de> wrote: > OK, back to basics, > 1. check whether sssd is compiled with openssl's libcrypto: RHEL uses MozNSS for everything, not openssl. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Douglas Duckworth 28 Sep '17

28 Sep '17

What would you recommend as a replacement for SSSD? I am running it across Centos 6 and 7 clients without any issue using TLS. Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690 On Thu, Sep 28, 2017 at 4:28 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, September 28, 2017 2:18 PM -0700 Quanah Gibson-Mount > <quanah(a)symas.com> wrote: > > > --On Thursday, September 28, 2017 4:41 PM -0400 Robert Heller > > <heller(a)deepsoft.com> wrote: > > > >> Will these spit out useful error messages? If I just get "TLS > >> Negotiation failure" it is not going to be helpful. > > However, you may have hit a known and unfixed bug in SSSD: > > <https://urldefense.proofpoint.com/v2/url?u=https- > 3A__pagure.io_SSSD_sssd_issue_2896-3Fcversion-3D0-26cnum- > 5Fhist-3D6&d=DwICAg&c=lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_ > 78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m=Ja4DjRR6Qj8_V_ > dfdMKRYjRAr1xpbNW8S-ZCeuu0wVU&s=LX7sB7YqYEcVA8ShS- > BKldCvsNEKG_FtNXsHvAu313g&e=> > > You may be better off using a better written piece of software. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.symas.com&d=DwICAg&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > Ja4DjRR6Qj8_V_dfdMKRYjRAr1xpbNW8S-ZCeuu0wVU&s=dEVYmbtnrd3EzH7Xm1Pk8GYotr6_ > kbuWkSoBh6UEV7I&e=> > > >

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 28 Sep '17

28 Sep '17

--On Thursday, September 28, 2017 2:18 PM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, September 28, 2017 4:41 PM -0400 Robert Heller > <heller(a)deepsoft.com> wrote: > >> Will these spit out useful error messages? If I just get "TLS >> Negotiation failure" it is not going to be helpful. However, you may have hit a known and unfixed bug in SSSD: <https://pagure.io/SSSD/sssd/issue/2896?cversion=0&cnum_hist=6> You may be better off using a better written piece of software. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 28 Sep '17

28 Sep '17

--On Thursday, September 28, 2017 4:41 PM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > Will these spit out useful error messages? If I just get "TLS > Negotiation failure" it is not going to be helpful. Sure, if you add "-d -1" to the parameters you pass in to ldapwhoami. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Robert Heller 28 Sep '17

28 Sep '17

OK, I have narrowed things down to slapd and sssd not playing nice with each other. slapd is able to listen on ldaps (port 636) and accept SSL connections (eg from openssl s_client and other applications using straight SSL). slapd will also listen on ldap (port 389), but refuses to negotiate a TLS connection on port 389. It also refuses to negotiate TLS connection on port 636. sssd seems to *insist* on negotiating a TLS connection on port 636 or port 389 and won't just connect using ssl to port 636. (At least that is what I *think* is going on.) So, I either need to get slapd to do TLS negotiation on port 389 OR port 636, or get sssd to NOT do TLS negotiation on port 636 and just connect with SSL. How the hell do I get that to happen? here are my config files: [root@c764guest heller]# cat /etc/openldap/slapd.d/cn\=config.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 ba294eab dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcPidFile: /var/run/openldap/slapd.pid olcTLSCACertificatePath: /etc/openldap/certs structuralObjectClass: olcGlobal entryUUID: 7e6a3298-30da-1037-9c4f-458bcc6c0ce0 creatorsName: cn=config createTimestamp: 20170918163057Z olcTLSCACertificateFile: /etc/openldap/certs/ca-cert.pem olcTLSCertificateFile: /etc/pki/tls/certs/c764guest.cert olcTLSCertificateKeyFile: /etc/pki/tls/certs/c764guestkey.pem entryCSN: 20170927144348.897441Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170927144348Z [root@c764guest heller]# cat /etc/sssd/sssd.conf [domain/default] autofs_provider = ldap cache_credentials = True ldap_search_base = dc=deepsoft,dc=com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldaps://192.168.250.98/ ldap_id_use_start_tls = false ldap_tls_cacert = /etc/openldap/certs/ca-cert.pem ldap_default_bind_dn = uid=sssd,ou=People,dc=deepsoft,dc=com ldap_default_authtok = sssd [sssd] services = nss, pam, autofs domains = default [nss] homedir_substring = /home [pam] debug_level = 0x7770 ldap_id_use_start_tls = false [sudo] [autofs] [ssh] [pac] [ifp] [root@c764guest heller]# cat /etc/openldap/ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=deepsoft,dc=com URI ldaps://192.168.250.98/ TLS_CACERT /etc/openldap/certs/ca-cert.pem TLS_CACERTDIR /etc/openldap/certs TLS_REQCERT demand #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on TLS_REQCERT allow -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

3 2

Re: Attribute map/substitution
by Quanah Gibson-Mount 28 Sep '17

28 Sep '17

--On Wednesday, September 27, 2017 11:53 AM +0200 Ervin Hegedüs <airween(a)gmail.com> wrote: > The problem is, that (for example) ntPassword and lmPassword attributes > are doesn't exists (sAMAccountName and objectSid also...). > > I thing that the ntPassword is the sambaNTPassword, which is part of the > samba.scheme. > > But how can I configure the OpenLDAP to server these attributes? The larger question is, does it actually need those attributes to function? If so, then you'll need to find schema defining them, add that schema to your OpenLDAP server, and then populate them. It may well not *require* them to be present in the entry (for example, it looks at all of: ntPassword, lmPassword, userPassword). My guess would be that as long as it can access one of those it is fine. However, the fact that it's trying to get a value back for a password shows that the piece of software is poorly written and should be avoided. There's zero reason for it to have read access to a password attribute. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: need an example of using "ldap_search_s" function using the "attr" parameter.
by Quanah Gibson-Mount 28 Sep '17

28 Sep '17

--On Monday, September 25, 2017 11:56 PM +0000 Don jessup <djessup72(a)yahoo.com> wrote: > To limit the information coming back from the server I only want the > values of the "sAMAccountName" attribute. Every time I try populating > the "attrs" parameter I get an error. I was wondering if I could be > pointed to an example or 2 that uses the parameter. ldap_search_s is deprecated, you should be using ldap_search_ext_s instead. However, libraries/libldap/sasl.c has a trivial example of using attrs with ldap_search_s: char *attrs[] = { "supportedSASLMechanisms", NULL }; rc = ldap_search_s( ld, "", LDAP_SCOPE_BASE, NULL, attrs, 0, &res ); --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

meta backend , rwm AD source , uppercase to lowercase
by Nicolas Renault 28 Sep '17

28 Sep '17

Hello, My question, I have a meta backend that work perfectly but on the dev team somebody ask me : Why on AD this organizationalUnit have these valuies on attrs : managedBy: CN=Surname Name,OU=Users,DC=domain,DC=fr seeAlso: CN=Sunrame2 Name2,OU=Users,DC=domain,DC=fr and on meta on the same OU : managedBy: cn=surname name,ou=Users,ou=meta,dc=domain,dc=fr seeAlso: cn=Surname2 Name2,ou=Users,ou=META,dc=domain,dc=fr the AD is "bind" to ou=META,dc=domain,dc=fr ( suffixemassage) all OU on meta have the same behavior so * why on managedBy attr all is modified in lowercase and only CN and OU on seeAlso ? * how work uppercase to lowercase with meta backend ? is overlay rwm implicated ? my meta backend config is very long but somme informations moduleload back_meta moduleload rwm moduleload valsort moduleload memberof moduleload dynlist moduleload sssvlv.so moduleload collect moduleload pcache moduleload back_monitor moduleload back_ldap moduleload back_mdb overlay rwm rwm-rewriteEngine on rwm-normalize-mapped-attrs yes ... lot of rewrite rules etc. version : @(#) $OpenLDAP: slapd 2.4.44 $ opensuse-buildservice(a)opensuse.org openSUSE Leap 42.2 thanks for your answers. Nicolas

1 0

Re: Locker killed to resolve a deadlock
by Quanah Gibson-Mount 27 Sep '17

27 Sep '17

--On Wednesday, September 27, 2017 3:05 PM +0900 Jorgen Lundman <lundman(a)lundman.net> wrote: > we have told it to syncrepl from scratch into an empty > directory. Catastrophically bad idea with OpenLDAP 2.4.36. You may want to read over the various sync issues that have been fixed since that release (Current release is 2.4.45). The only safe way for you to reload another server will be slapcat/slapadd. Generally, I'd strongly advise upgrading to a current release and switching to back-mdb, eliminating BDB entirely. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Attribute map/substitution
by Ervin Hegedüs 27 Sep '17

27 Sep '17

Hi folks, here is a Captive Portal (from Aruba), and we would like to integrate it with OpenLDAP tu authenticate users (for 802.1x). The server is a Debian 8, with OpenLDAP 2.4. I've set up the loglevel, and I see the query in the log: Sep 27 09:56:50 srv slapd[19709]: filter: (&(uid=airween)(objectClass=*)) Sep 27 09:56:50 srv slapd[19709]: attrs: Sep 27 09:56:50 srv slapd[19709]: ntPassword Sep 27 09:56:50 srv slapd[19709]: lmPassword Sep 27 09:56:50 srv slapd[19709]: radiusReplyMessage Sep 27 09:56:50 srv slapd[19709]: radiusFilterId Sep 27 09:56:50 srv slapd[19709]: userPassword Sep 27 09:56:50 srv slapd[19709]: userCertificate Sep 27 09:56:50 srv slapd[19709]: sAMAccountName Sep 27 09:56:50 srv slapd[19709]: objectSid Sep 27 09:56:50 srv slapd[19709]: The problem is, that (for example) ntPassword and lmPassword attributes are doesn't exists (sAMAccountName and objectSid also...). I thing that the ntPassword is the sambaNTPassword, which is part of the samba.scheme. But how can I configure the OpenLDAP to server these attributes? I've found the slapo-rwm manpages, but nothing more useful informations... Could anybody helps to explain, how rwm's works? What do I need to do with this OpenLDAP (eg. modify the existing config) to solve that problem? On CP side there isn't any way to change the attributes - as I saw. Thanks, a.

1 0

Re: Locker killed to resolve a deadlock
by Quanah Gibson-Mount 27 Sep '17

27 Sep '17

--On Tuesday, September 26, 2017 9:56 AM +0900 Jorgen Lundman <lundman(a)lundman.net> wrote: > > Unfortunately, this is not our experience - although it is possible the > message is just a distraction. > > slapd stops all syncrepl, and responding, until they call us to restart > it. Interesting, I wonder if the BDB database has corrupted. Have you tried rebuilding the database(s) on the system via slapcat/slapadd? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Locker killed to resolve a deadlock
by Quanah Gibson-Mount 26 Sep '17

26 Sep '17

--On Friday, September 22, 2017 4:26 PM +0900 Jorgen Lundman <lundman(a)lundman.net> wrote: > This has started to cause trouble, in the last month or so. The errors > are: > > Sep 22 06:08:26 vmx02 slapd[14039]: [ID 960831 local4.debug] => > bdb_idl_delete_key: c_get failed: DB_LOCK_DEADLOCK: Locker killed to > resolve a deadlock (-30994) These can be safely ignored. See <http://www.openldap.org/lists/openldap-software/200810/msg00055.html> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

need an example of using "ldap_search_s" function using the "attr" parameter.
by Don jessup 26 Sep '17

26 Sep '17

I trying to use the "ldap_serach_s" function and my filter works great if put NULL in for the "attrs" parameter. Here is example filter [(&(member=cn=Bob,ou=colo,dc=bigco,dc=com,dc=local)(objectCategory=Group))] To limit the information coming back from the server I only want the values of the "sAMAccountName" attribute. Every time I try populating the "attrs" parameter I get an error. I was wondering if I could be pointed to an example or 2 that uses the parameter. ThanksDon

1 0

Re: slapd: null_callback : error code 0x14
by Quanah Gibson-Mount 25 Sep '17

25 Sep '17

--On Friday, September 22, 2017 10:15 PM -0700 "Paul B. Henson" <henson(a)acm.org> wrote: > I see there was a proposed patch posted on 8/25 that's been applied to > RE24, I'll add that to my system and see if the issue goes away. Am I > correct in my assumption that the patch only needs to be applied to the > system that is receiving the updates? I believe that is correct. :) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Olc deployment vs slapd.conf based deployment
by Howard Chu 25 Sep '17

25 Sep '17

Peter wrote: >> olcSchemaFile: {0}include: file://$ABS_SCHEMADIR/core.ldif >> olcSchemaFile: {1}include: file://$ABS_SCHEMADIR/cosine.ldif >> olcSchemaFile: {2}include: file://$ABS_SCHEMADIR/inetorgperson.ldif > > That is a very nice proposal, it would sort of give us the good things of both > worlds. It means you would not be able to edit the schema contained within these directives over LDAP, since those elements aren't themselves part of the cn=config DIT. So no, it's not the good things of both worlds. > IMHO schema is the only thing where cn=config makes life harder than slapd.conf. > > Being a long time lurker on this list it is fun to see that although same > subjects like config alternatives, turn up again and again, the arguments and > solution proposals at least sometimes do progress. > > Cheers > > Peter > > > > Am 15.09.2017 um 20:33 schrieb Quanah Gibson-Mount: >> --On Friday, September 15, 2017 12:24 PM -0700 Ryan Tandy <ryan(a)nardis.ca> >> wrote: >> >> >>> There was some talk, either in IRC or on -devel, of creating a way for >>> cn=config to reference schema files (possibly LDIF) on disk rather than >>> importing them into the config database. I think that would be an >>> improvement. Importing schemas into cn=config is cool - especially if you >>> want to replicate the config - but I'm not sure it's a good default. >> >> Since ordering is mandatory, it would be nice if you could just do something >> like: >> >> olcSchemaFile: {0}include: file://$ABS_SCHEMADIR/core.ldif >> olcSchemaFile: {1}include: file://$ABS_SCHEMADIR/cosine.ldif >> olcSchemaFile: {2}include: file://$ABS_SCHEMADIR/inetorgperson.ldif >> >> >> etc. Then you could change the schema files on disk, and cn=config would >> just load them in when it started. It'd certainly make the behavior >> analagous to slapd.conf, and allow for easier rollback/testing. >> >> --Quanah >> >> >> -- >> >> Quanah Gibson-Mount >> Product Architect >> Symas Corporation >> Packaged, certified, and supported LDAP solutions powered by OpenLDAP: >> <http://www.symas.com> >> >> > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Openldap 2.4.40-13.el7 on CentOS 7 and SSL/TLS
by Quanah Gibson-Mount 23 Sep '17

23 Sep '17

--On Friday, September 22, 2017 5:32 PM -0400 Christopher Wood <christopher_wood(a)pobox.com> wrote: > Two things I notice from below: > > olcTLSCACertificateFile: /etc/openldap/certs/ca_cert.pem > -rw-r--r--. 1 root root 1696 Sep 22 14:18 ca-cert.pem > > Underscore in the first, dash in the second. Good catch! It's also important to note that RedHat links to MozNSS rather than GnuTLS or OpenSSL, so the standard caveats apply, and be sure to follow the documentation to MozNSS when setting up both the slapd and client (ldapsearch) side of things. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

Openldap 2.4.40-13.el7 on CentOS 7 and SSL/TLS
by Robert Heller 22 Sep '17

22 Sep '17

What is the *correct* way to set up Openldap to use SSL/TLS? The documentation is somewhat confusing. My cn=config.ldif file looks like this: dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcPidFile: /var/run/openldap/slapd.pid olcTLSCACertificatePath: /etc/openldap/certs olcTLSCACertificateFile: /etc/openldap/certs/ca_cert.pem olcTLSCertificateFile: /etc/openldap/certs/c764guest.cert olcTLSCertificateKeyFile: /etc/openldap/certs/privkey.pem structuralObjectClass: olcGlobal entryUUID: 7e6a3298-30da-1037-9c4f-458bcc6c0ce0 creatorsName: cn=config createTimestamp: 20170918163057Z entryCSN: 20170918163057.597791Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20170918163057Z in /etc/openldap/certs are these files: [root@c764guest heller]# ls -l /etc/openldap/certs total 104 -rw-r--r--. 1 root root 5137 Sep 22 14:42 c764guest.cert -rw-r--r--. 1 root root 1074 Sep 22 14:37 c764guest.csr -rw-r--r--. 1 root root 1696 Sep 22 14:18 ca-cert.pem -rw-r--r--. 1 root root 65536 Sep 18 12:30 cert8.db -rw-r--r--. 1 root root 16384 Sep 18 12:30 key3.db -r--r-----. 1 root ldap 45 Jan 10 2016 password -rw-r--r--. 1 root root 1834 Sep 22 14:37 privkey.pem -rw-r--r--. 1 root root 16384 Jan 10 2016 secmod.db /etc/sysconfig/slapd contains: # OpenLDAP server configuration # see 'man slapd' for additional information # Where the server will run (-h option) # - ldapi:/// is required for on-the-fly configuration using client tools # (use SASL with EXTERNAL mechanism for authentication) # - default: ldapi:/// ldap:/// # - example: ldapi:/// ldap://127.0.0.1/ ldap://10.0.0.1:1389/ ldaps:/// SLAPD_URLS="ldapi:/// ldap://127.0.0.1/ ldap://192.168.250.98/ ldaps:///" # Any custom options #SLAPD_OPTIONS="-s 128" # Keytab location for GSSAPI Kerberos authentication #KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab" /etc/openldap/ldap.conf contains: # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=deepsoft,dc=com URI ldaps://192.168.250.98/ TLS_CACERT /etc/openldap/certs/ca-cert.pem TLS_CACERTDIR /etc/openldap/certs TLS_REQCERT demand #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS_CACERTDIR /etc/openldap/cacerts # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on But now when I try to do a ldapsearch I get: [heller@c764guest ~]$ ldapsearch -x ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) even though: [root@c764guest heller]# netstat -a|grep ldap tcp 0 0 0.0.0.0:ldaps 0.0.0.0:* LISTEN tcp 0 0 c764guest.deepsoft:ldap 0.0.0.0:* LISTEN tcp 0 0 localhost:ldap 0.0.0.0:* LISTEN tcp 0 0 c764guest.deepsof:33302 c764guest.deepsoft:ldap ESTABLISHED tcp 0 0 c764guest.deepsoft:ldap c764guest.deepsof:33302 ESTABLISHED tcp6 0 0 [::]:ldaps [::]:* LISTEN Is this correct? I am not sure if I should be using ldaps:/// or not. And I am not sure what the proper "magic" to get TLS working is. -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

2 1

Re: Getting ldappasswd and PAM in the same page under CentOS 7
by Quanah Gibson-Mount 22 Sep '17

22 Sep '17

--On Friday, September 22, 2017 10:45 AM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > Operation 11 *seems* to be fetching the uid, using self, which has write > access, which implies read access, which seems to work just fine, using > ldapsearch from the command line: > > [heller@c764guest ~]$ ldapsearch -D > uid=test2user,ou=People,dc=deepsoft,dc=com -W -LLL '(uid=test2user)' uid > Enter LDAP Password: > dn: uid=test2user,ou=People,dc=deepsoft,dc=com > uid: test2user Is PAM actually bound as uid=testuser2, or is it bound as anonymous or some other DN? I can't tell from the little snippet of log that was in this thread. So yes, it works for you using ldapsearch when you bind as uid=test2user, but is that what pam is using? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Getting ldappasswd and PAM in the same page under CentOS 7
by Robert Heller 22 Sep '17

22 Sep '17

I am having a hard time setting a user password using ldap (OpenLDAP 2.4.40-13.el7) on a CentOS 7 system. I have installed OpenLDAP 2.4.40-13.el7 (stock CentOS 7 server and client), nss-pam-ldapd (0.8.13-8.el7) and used authconfig to enable ldap. I have created a user in the ldap database, and getent works just fine -- the uid and gid are seen, etc. But I cannot set the user's password in a way that works for su (and presumably login/slogin, etc.). I am using ldappasswd to set the user's password. I am thinking that PAM and ldappasswd are using *different* oneway encryption methods and I am guessing I need to update a configuration somewhere (either for pam, sssd, or nslcd), but I am not finding it. -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

5 13

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 22 Sep '17

22 Sep '17

--On Friday, September 22, 2017 8:38 AM -0400 Frank Swasey <Frank.Swasey(a)uvm.edu> wrote: > My take away from this lengthy discussion is the following: > > 1) cn=config is not ready for "make; make test; make install" level of > upgrade. Until it is, it is not usable in a production environment. I've been doing binary upgrades on deployments using cn=config for years (Since 2011 or so), with servers all across the globe. However, I didn't use ppolicy in my configurations. The real issue with ppolicy is that it shouldn't be shipping with a separate schema, and instead it should have its configuration schema fully internalized. I've already made a note to that that needs to be fixed for OpenLDAP 2.5 so it doesn't occur again. Outside of that, I'm not aware of it being deficient in comparison to slapd.conf, and I'm quite aware of numerous ways in which it is substantially better. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 22 Sep '17

22 Sep '17

--On Friday, September 22, 2017 10:47 AM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > The current ITS system is already scheduled for replacement. The current > OpenLDAP infrastructure is already being migrated *being migrated (one server complete, one underway as time allows). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 22 Sep '17

22 Sep '17

--On Wednesday, September 20, 2017 6:40 PM +0200 Ondřej Kuzník <ondra(a)mistotebe.net> wrote: > In terms of that, some of us would like to have a different bug tracking > system, if it supports attaching patches to it I guess that's something > you'd find a bit more welcoming. The current ITS system is already scheduled for replacement. The current OpenLDAP infrastructure is already being migrated (The old git-master server was migrated earlier this year). The larger issue with migrating the other piece of infrastructure is it is a mess to detangle. It's a rather old debian box that still has freeBSD binaries on it from when it was migrated from freeBSD to debian, and the current software setup is... interesting. ;) So as a part of migrating it to the new server, I'm redoing the configurations and documenting everything as I go along. It's rather time consuming. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Proper Way To Securely Bind With LDAP Server
by Douglas Duckworth 22 Sep '17

22 Sep '17

Hi As I have read the StartTLS extended operation seems to be preferred over SSL: http://www.openldap.org/faq/data/cache/605.html Therefore* I have always* used -ZZ with ldap://URI to bind to my server. Eg: ldapsearch -ZZ -b base -H ldap://server -D uid=admin,ou=users,base -W cn=search I thought this would thus encrypt my password by encapsulating the TCP 389 connection with TLS encryption. However, to my severe dismay, I can see my password in "-d3" debug output, using the above command, as well as when dropping the -ZZ and using ldaps:// Can you please provide guidance? ldap_url_parse_ext(ldap://ldap.server.domain) ldap_create ldap_url_parse_ext(ldap://ldap.server.domain:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ldap.server.domain:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying LDAP_SERVER:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_write: want=31, written=31 0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037 ldap_result ld 0xdea060 msgid 1 wait4msg ld 0xdea060 msgid 1 (infinite timeout) wait4msg continue ld 0xdea060 msgid 1 all 1 ** ld 0xdea060 Connections: * host: ldap.server.domain port: 389 (default) refcnt: 2 status: Connected last used: Fri Sep 22 10:23:35 2017 TLS certificate verification: subject: CN=ldap.server.domain,OU=BLAH,issuer: CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US, cipher: *AES-256*, *security level: high*, secret key bits: 256, total key bits: 256, cache hits: 0, cache misses: 0, cache not reusable: 0 Enter LDAP Password: <-- I Enter Password The server logs show: Sep 22 10:27:41 server slapd[21471]: conn=131126 op=1 BIND dn="admin" method=128 Sep 22 10:27:41 server slapd[21471]: conn=131126 op=1 BIND dn="admin" mech=SIMPLE ssf=0 The password then appears in -d3 output after I authenticate. However, I do not see the password in tcpdump using a full packet capture on both the client and ldap server. As expected I do see the password in tcpdump when dropping the -ZZ and using -x for simple bind. So in summary seeing credentials when using -ZZ and -d3 should not bring concern as they're encrypted over the wire. So I guess can you explain how "-d3" works? Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690

1 0

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 22 Sep '17

22 Sep '17

--On Friday, September 15, 2017 12:24 PM -0700 Ryan Tandy <ryan(a)nardis.ca> wrote: > There was some talk, either in IRC or on -devel, of creating a way for > cn=config to reference schema files (possibly LDIF) on disk rather than > importing them into the config database. I think that would be an > improvement. Importing schemas into cn=config is cool - especially if you > want to replicate the config - but I'm not sure it's a good default. Since ordering is mandatory, it would be nice if you could just do something like: olcSchemaFile: {0}include: file://$ABS_SCHEMADIR/core.ldif olcSchemaFile: {1}include: file://$ABS_SCHEMADIR/cosine.ldif olcSchemaFile: {2}include: file://$ABS_SCHEMADIR/inetorgperson.ldif etc. Then you could change the schema files on disk, and cn=config would just load them in when it started. It'd certainly make the behavior analagous to slapd.conf, and allow for easier rollback/testing. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

Re: Olc deployment vs slapd.conf based deployment
by Howard Chu 22 Sep '17

22 Sep '17

Frank Swasey wrote: > My take away from this lengthy discussion is the following: > > 1) cn=config is not ready for "make; make test; make install" level of > upgrade. Until it is, it is not usable in a production environment. Nobody is denying that more work needs to be done. Where did you ever get that impression? > 2) As usual, the OpenLDAP developers are saying "my way or the highway". This is totally ignorant and off base. Crazy suggestions like "OpenLDAP should change its license to suit my needs" are completely ludicrous. Nobody within the OpenLDAP Project has the authority to do that. There's no *my way* here, there's simply reality vs delusion. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Olc deployment vs slapd.conf based deployment
by Howard Chu 22 Sep '17

22 Sep '17

Radovan Semancik wrote: > Hi, > > On 09/18/2017 02:44 PM, Howard Chu wrote: >> These perennial arguments keep coming up. If you want things to improve, >> contribute. Anyone can write a manpage. Hardly anyone ever does. Everyone >> sits back and moans while waiting for someone else to fix things for them. >> That's not what open source projects and communities are about. > > I would ... if this was a wiki, or github-like pull request and if there was > an example of how a good result should look like. But it does not make sense > for me to spend few hours just figuring out how to contribute documentation > fix. So you're still saying, it's fine for other people to put in the hours to produce something you benefit from, but it's too much trouble for you to contribute in return. And in the meantime, it's perfectly OK for you to sit back and complain that things haven't been fixed. Got it. If that's the way everybody feels then we can all just shut off the lights and go home now. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 3

Locker killed to resolve a deadlock
by Jorgen Lundman 22 Sep '17

22 Sep '17

openldap-2.4.36 db-4.8.30.NC Solaris-10u11 Hello list, We've been running those LDAP versions for years and we have been pretty pleased with it. But then "they" went and added an automated test script, that adds some records every 10 mins, confirms they are replicated all the way to the frontends, then deletes the records. This has started to cause trouble, in the last month or so. The errors are: Sep 22 06:08:26 vmx02 slapd[14039]: [ID 960831 local4.debug] => bdb_idl_delete_key: c_get failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) Sep 22 06:13:37 vmx02 last message repeated 36 times Sep 22 06:13:44 vmx02 slapd[14039]: [ID 960831 local4.debug] => bdb_idl_delete_key: c_get failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) Sep 22 06:20:17 vmx02 last message repeated 39 times Until we restart slapd. Setup is: prov (1 writer) -> ldapmaster -> ldapslave(s) -> frontend(s) -> ldapslave(s) -> frontend(s) -> frontend(s) The problem happens the most on frontend servers, but occasionally on ldapslaves, and twice now on ldapmaster. So we don't think it is syncrepl related. One answer would be to stop the 10min "ldap sync test" script of course, but it would be nice to solve the actual problem. slapd.conf, on slaves/frontend look like: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/company-schema/qmail.schema include /usr/local/etc/openldap/company-schema/local.schema include /usr/local/etc/openldap/company-schema/RADIUS-LDAPv3.schema include /usr/local/etc/openldap/company-schema/AmavisdLDAP.schema include /usr/local/etc/openldap/company-schema/analyse.schema include /usr/local/etc/openldap/company-schema/formail.schema include /usr/local/etc/openldap/company-schema/filter.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args loglevel sync database monitor access to dn.subtree="cn=Monitor" by dn="cn=admin,dc=company,dc=jp" read by * none database bdb suffix "dc=company,dc=jp" rootdn "cn=admin,dc=company,dc=jp" lastmod on checkpoint 128 15 overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 cachesize 10000 idlcachesize 15000 directory /usr/local/var/openldap-data index objectClass eq index uid eq index uidNumber eq index mail eq index mailAlternateAddress pres,eq index deliveryMode eq index accountStatus eq index gecos eq index radiusGroupName eq index o pres,eq index entryCSN,entryUUID eq dbconfig set_lk_detect DB_LOCK_DEFAULT dbconfig set_lg_max 52428800 dbconfig set_cachesize 0 67108864 1 dbconfig set_flags db_log_autoremove dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 syncrepl rid=345 provider=ldap://ldapslave01 type=refreshAndPersist interval=00:00:00:30 searchbase="dc=company,dc=jp" filter="(objectClass=*)" attrs="*,+" scope=sub schemachecking=off bindmethod=simple binddn="uid=replicate,o=companyserver.jp,ou=admin,dc=company,dc=jp" credentials="<secret>" retry="60 10 300 +" updateref ldap://ldapmaster01 -- Jorgen Lundman | <lundman(a)lundman.net> Unix Administrator | +81 (0)90-5578-8500 Shibuya-ku, Tokyo | Japan

1 0

Re: slapd: null_callback : error code 0x14
by Quanah Gibson-Mount 22 Sep '17

22 Sep '17

--On Tuesday, September 19, 2017 7:40 PM -0700 "Paul B. Henson" <henson(a)acm.org> wrote: > Hmm. I only have one active master, and it's the only server receiving > updates. Let me try including some more detail on an error from this > morning. > > So here's the error on the replica: > > Sep 19 03:56:19 coeus slapd[43551]: null_callback : error code 0x14 > Sep 19 03:56:19 coeus slapd[43551]: syncrepl_message_to_op: rid=003 > be_modify uid=egr44503,ou=group,dc=cpp,dc=edu (20) Well, my first question is, do you see these changes to this group entry in the log from your other rid as well? I.e., if it is being applied twice, you should see each modification logged twice. Usually with sync logging, you have lines noting what the CSN is that's being processed as well. There's not enough log information here to act on. :) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

Re: olcPasswordHash per database
by Howard Chu 21 Sep '17

21 Sep '17

Nikos Voutsinas wrote: > Hello, > > We need for a specific database (olcDatabase) to force an SHA password hash, > while keeping the default hashing scheme for the rest of them (the SSHA). > However it seems that olcPasswordHash is not allowed with-in an olcDatabase > object. > > What's the suggested method to overwrite the default password hash for a > specific db? Not currently supported. You're welcome to submit a patch to implement this. In the meantime, you can run a separate slapd instance, and tie it back in to the first slapd using back-ldap. Overall it's probably a bad idea though. If you have anything outside of slapd depending on the specific password hash mechanism, you're doing something wrong. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

olcPasswordHash per database
by Nikos Voutsinas 21 Sep '17

21 Sep '17

Hello, We need for a specific database (olcDatabase) to force an SHA password hash, while keeping the default hashing scheme for the rest of them (the SSHA). However it seems that olcPasswordHash is not allowed with-in an olcDatabase object. What's the suggested method to overwrite the default password hash for a specific db? Thank you in advance Nikos

2 1

Re: Instructions for Open LDAP library?
by Martin van den Nieuwelaar 20 Sep '17

20 Sep '17

On 19/09/17 08:00, John Lewis wrote: > On Mon, 2017-09-18 at 14:31 +1200, Martin van den Nieuwelaar wrote: >> Hi People, >> >> I'm writing an application using Qt and wish to use the openldap >> library >> within my program to query an LDAP server. I have been searching >> for >> instructions on using the library from a client point of view but >> have >> not been successful. I tried using the man pages and I think I'm >> part >> way there but have reached an impasse on the correct way (or any way >> at >> all for that matter) to extract the results from an LDAPMessage >> *. I >> have an example search working using the command line program >> ldap_search, so the next thought is to look at the source for >> ldap_search and see what calls it makes to figure things out. This >> somehow seems like the wrong way to be going about things however. >> >> Is there something equivalent for openldap to the documentation for >> libcurl, https://ec.haxx.se/libcurl-easyhandle.html ? If there is >> that >> would be brilliant. > The libcurl library supports LDAP. Howard Chu even wrote a new LDAP > implementation for it back in 2010 to make it fully asynchronous. Is > there a good reason not to use it? > Thanks for the suggestion. I hadn't even thought to see if libcurl could perform LDAP queries, but indeed it looks like it can so this is definitely worth looking into. In the interim I did get my Qt program working, not by using the openldap library calls for which I'm still none the wiser but by using Qt's very capable and well documented QProcess class for running external programs and calling the ldapsearch command line program. Thanks again for the reply. -- R A Ward Ltd. | We take the privacy of our customers seriously. Christchurch | All sensitive E-Mail attachments MUST be encrypted. New Zealand

1 0

Using overlay rwm to rewrite search base depending on search filter
by Clément OUDOT 20 Sep '17

20 Sep '17

Hello, I am playing with overlay rwm to try to change the base DN of a search depending on a value in search filter. The goal is to rewrite base "dc=example,dc=com" to "dc=test,dc=example,dc=com" if I have (uid=login@test) in the LDAP filter. Has someone already done this? My configuration for the moment is the following, but I don't understant how to capture a value in searchFilter context to use it in searchDN context: dn: olcOverlay={0}rwm,olcDatabase={1}meta,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: rwm olcRwmRewrite: rwm-rewriteEngine on olcRwmRewrite: rwm-rewriteContext searchFilter olcRwmRewrite: rwm-rewriteRule "uid=(.*(a))(.*)" "uid=$0$1" ":" olcRwmRewrite: rwm-rewriteContext searchDN olcRwmRewrite: rwm-rewriteRule "dc=example,dc=com" "dc=${searchFilter($1)},dc=example,dc=com" ":" Thanks for your help! Clément.

1 1

Re: slapd: null_callback : error code 0x14
by Quanah Gibson-Mount 20 Sep '17

20 Sep '17

--On Friday, September 15, 2017 8:48 PM -0700 "Paul B. Henson" <henson(a)acm.org> wrote: > So I've been putting off posting about this, but I recently upgraded to > 2.4.45, stopped using the memberof overlay, no longer have a node with > serverID 0, and overall think my ldap servers should be in good shape > :), and it's still happening, so I thought it was time... > > I'm getting weird errors in my logs about group replication changes: > > Sep 15 03:55:16 minerva slapd[71654]: null_callback : error code 0x14 > Sep 15 03:55:16 minerva slapd[71654]: syncrepl_message_to_op: rid=003 > be_modify uid=arc464,ou=group,dc=cpp,dc=edu (20) These aren't "wierd errors". 0x14=20. I.e., you're simply getting the same error logged twice. > As far as I can tell, all the updates succeed and the objects are > exactly the same on all the replicas, so these failures just seem to be > log noise? Well, error code 20 is "type or value already exists". If the replica and the masters are starting from the same point, this would tend to imply that the replica is receiving the change multiple times, and it's failing on the subsequent modify operations. There's not enough information here to really deduce much beyond that. I've seen this occur in MMR situations where two masters were updating the same entries within a short window of each other. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Antw: Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 19 Sep '17

19 Sep '17

--On Tuesday, September 19, 2017 7:31 PM +0200 Radovan Semancik <radovan.semancik(a)evolveum.com> wrote: > What I meant were external contributions from people outside of the core > team. And I have obviously missed (at least) one such contribution. I'm > sorry for this. My fault. And I get your point and I apologize for this > confusion. One thing you're likely missing is that -devel is generally used for discussion of new feature requests. The ITS system (and thus the openldap-bugs list) are where discussion generally occurs for contributions related to existing features. So the -devel list is generally much lower traffic. For example, this is the archive for September (so far): <http://www.openldap.org/lists/openldap-bugs/201709/> > I just want to point out I haven't failed to notice that all of my other > points got ignored. I didn't think any of the rest of what you said was valid so there was nothing to address. You came in with a premise that was not based on fact. There are numerous people contributing that are not direct project team members, and they don't have issues with the contribution process. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Antw: Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 19 Sep '17

19 Sep '17

--On Tuesday, September 19, 2017 11:54 AM +0200 Radovan Semancik <radovan.semancik(a)evolveum.com> wrote: > Regarding the pull requests and discussions: I have checked the devel > mailing list for several months and I haven't see any discussion > regarding a contribution. Really? You must not have looked very hard then. <http://www.openldap.org/lists/openldap-devel/201709/msg00000.html> covers some 22 contributions. <http://www.openldap.org/lists/openldap-devel/201709/msg00003.html> discussions some contributions related to man page fixes. <http://www.openldap.org/lists/openldap-devel/201706/msg00004.html> covers work I did to make TLS command line options for the ldap* tools <http://www.openldap.org/lists/openldap-devel/201706/msg00006.html> is part of an ongoing discussion of allowing ldap clients to use a specific local address <http://www.openldap.org/lists/openldap-devel/201706/msg00000.html> is a discussion about adding ldap_init_fd contribution from samba etc. > What I see as a major problem is that there is no will. OpenLDAP project > clearly needs major improvement. But there are almost no contributors to > improve the project. As demonstrated by the above you clearly are incorrect. I would generally suggest you withhold comment on the project until you have some clue what you're talking about. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 19 Sep '17

19 Sep '17

--On Friday, September 15, 2017 12:49 AM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > Personally I strongly prefer static configuration because it's so much > easier to control it with the usual idempotent config management > techniques (puppet, ansible, etc.) which you need for the rest of the > system anyway. Those are all systems designed to manage flat file configurations. cn=config is not a flat file configuration, so it makes sense they're fairly useless when confronted with a concept that's significantly more forward thinking. > I'd even state that it's a strong plus of OpenLDAP compared to other LDAP > server implementations to still provide this configuration method. I think it's a strong plus to be able to reconfigure a standalone server into an MMR cluster with zero downtime, along with other critical configuration bits, such as deploying new schema, additional overlays, etc. Being able to fully automate deployments w/o requiring restarts was an exceptional win for me. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

7 11

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 19 Sep '17

19 Sep '17

--On Monday, September 18, 2017 8:48 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: >> b) Since cn=config is simply a tree, you could have your cn=config in >> git, commit your changes there, and use a tool like ldapdiff to create >> changesets to apply programatically. > > So instead of writing a single file (in one FS transaction) after letting > slaptest check it I have to write several files (multiple FS operations), > diff that and then apply multiple LDAP operations. Hm? How is this any different really than tracking slapd.conf in git? And plenty of people break out slapd.conf into multiple files and use "include" handling to pull, such as with schema, ACLs, etc. I see no difference here. > Yeah, sounds really great regarding error handling. How does this differ from slapd.conf? You get no error handling with that, either, if you modify it and commit it to git. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

Re: Antw: Re: Olc deployment vs slapd.conf based deployment
by Radovan Semancik 19 Sep '17

19 Sep '17

On 09/19/2017 08:56 AM, Ulrich Windl wrote: > Please don't mix git with github! While github makes some things > easier to do, it's not required to use gir (as you surely know). The > problem with using github is that everybody has to use github then > (will pull requests and related discussions be visible in the mailing > list?). That's obviously not a correct statement. It is not true that "everybody has to use github". The true statement would be "people may use github as an alternative contribution path". I do not propose to make a complete switch to github. What I propose is to make official github/gitlab mirror and use that as an alternative contribution path. Regarding the pull requests and discussions: I have checked the devel mailing list for several months and I haven't see any discussion regarding a contribution. So obviously, this method does not work well either. I'm using github for years and I contribute to several projects. And there are always some ways how to cope with github. Sometimes the github discussions are limited to the technicalities of the merge and all other discussion is referred to mailing list. In addition to that github has hooks that can be used to direct the comments directly to the mailing list. The best solution that I have seen is probably in the Apache CXF project where pull request comments are automatically synchronized with bug tracking system comments. There is always a way ... if there is a will. What I see as a major problem is that there is no will. OpenLDAP project clearly needs major improvement. But there are almost no contributors to improve the project. I'm trying to explain that there may reasons why people are not keen to contribute. But what I see as a response only makes all of this worse. I'm sorry about that. Really sorry. > You could still use "format-patch" to send your change requests via > E-Mail. You could still write your letter by hand, put it into envelope and send it by post. But we are usually not doing that these days, are we? I'm quite sure we all know the reasons. -- Radovan Semancik Software Architect evolveum.com

1 0

Re: Olc deployment vs slapd.conf based deployment
by Howard Chu 18 Sep '17

18 Sep '17

Michael Ströder wrote: > Quanah Gibson-Mount wrote: >> b) Since cn=config is simply a tree, you could have your cn=config in >> git, commit your changes there, and use a tool like ldapdiff to create >> changesets to apply programatically. > > So instead of writing a single file (in one FS transaction) after letting > slaptest check it I have to write several files (multiple FS operations), diff > that and then apply multiple LDAP operations. slapcat -b cn=config -> 1 LDIF file. > P.S.: The day slapd.conf option is dropped from slapd I should start writing > my own LDAP server. ;-) You better get started now, if you want it to be ready to use by then. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

--On Thursday, September 14, 2017 10:59 PM -0500 Andy Dorman <adorman(a)ironicdesign.com> wrote: Hi Andy, > FWIW, we also need the git trail of changes over time. I have not > figured out a good way to do that with OLC. Well, there are a few options I suppose: a) You could set up an accesslog database that stores the changes made to cn=config over time. If you had to have it in git, it shouldn't be particularly difficult to write a tool to parse those changes out into some format you desire b) Since cn=config is simply a tree, you could have your cn=config in git, commit your changes there, and use a tool like ldapdiff to create changesets to apply programatically. Then you keep a full git history of your configuration, and have the ability to create changesets out of it. It might actually be kind of useful to develop something like ldapdiff (or update it accordingly) that works specificaly with git commits. You could build an entire automation setup for pushing out changes from that. ;) > === To add the same attribute to our dev server running OLC: > > - print the current OLC config to copy exactly how the current object > class is stored for use in my changes.ldif file. I do this because the > first time I did an OLC change I had a typo and the server was down for > almost an hour while I tried to find the typo and recover. > > - prepare a change.ldif file using the old OLC config for the object > class along with the new attribute definition. Adding the same new > attribute as above looks like this: > > dn: cn={5}antespam,cn=schema,cn=config > changetype: modify > add: olcAttributeTypes > olcAttributeTypes: ( idInteger:29 NAME 'asEstReportCardSpan' DESC 'How > many days of data to include in EST Report Cards' SUP idInteger ) > - Looks correct. > delete: olcObjectClasses > olcObjectClasses: ( idDomain:1 NAME 'asDomain' DESC 'A domain using > AnteSpam' SUP top AUXILIARY MUST ( asSidelineServer $ asPlan ) MAY ( > asAcceptUnknown $ asActive $ asAdvanced $ asBlockList $ asCountAccepted $ > asCountDiscarded $ asCountRejected $ asCountSent $ asCountSidelined $ > asCountVirus $ asDestination $ asDisposeThreshold $ asPassList $ > asSidelineThreshold $ asSpam $ asVirus $ asCountValid $ > asCountUnconfirmed $ asCountInvalid $ asCountIndependent $ > asAddressListReminder $ asRejectInvalidSender $ asPingAddress $ > asBlockArchive $ asBlockDoc $ asBlockDocOn $ asBlockExecutable $ > asBlockGeoIP $ asBlockNonLatin $ asBlockPassDoc $ asExternalAuth $ > asAlias $ asPayInterval $ asPlanStart $ asPlanCredit $ asBackup $ > asBackupUsageStats $ asEmergencyEmail $ asEmergencyEmailOn $ > asEmergencyEmailOff $ asEmergencyEmailUsed $ fmExternal $ asOutbound $ > asOutboundAccount $ asOutboundNotify $ asBPReportEmail $ > fmMaxRecipientsPer24Hr $ asUstEnabled $ asUstUsage ) ) > - You can delete by index number. It'd be simpler to do something like delete: olcObjectClasses olcObjectClasses: {3} (Or whatever index number it is). This avoids having to write out the entire object for the delete operation. I've used that as well with ACLs, which is handy. Although if you have a useful ldapdiff tool, then it'll generate this correctly for you as well. > add: olcObjectClasses > olcObjectClasses: ( idDomain:1 NAME 'asDomain' DESC 'A domain using > AnteSpam' SUP top AUXILIARY MUST ( asSidelineServer $ asPlan ) MAY ( > asAcceptUnknown $ asActive $ asAdvanced $ asBlockList $ asCountAccepted $ > asCountDiscarded $ asCountRejected $ asCountSent $ asCountSidelined $ > asCountVirus $ asDestination $ asDisposeThreshold $ asPassList $ > asSidelineThreshold $ asSpam $ asVirus $ asCountValid $ > asCountUnconfirmed $ asCountInvalid $ asCountIndependent $ > asAddressListReminder $ asRejectInvalidSender $ asPingAddress $ > asBlockArchive $ asBlockDoc $ asBlockDocOn $ asBlockExecutable $ > asBlockGeoIP $ asBlockNonLatin $ asBlockPassDoc $ asEstReportCardSpan $ > asExternalAuth $ asAlias $ asPayInterval $ asPlanStart $ asPlanCredit $ > asBackup $ asBackupUsageStats $ asEmergencyEmail $ asEmergencyEmailOn $ > asEmergencyEmailOff $ asEmergencyEmailUsed $ fmExternal $ asOutbound $ > asOutboundAccount $ asOutboundNotify $ asBPReportEmail $ > fmMaxRecipientsPer24Hr $ asUstEnabled $ asUstUsage ) ) > > - After the changes.ldif is done, I just pass it to ldapmodify and, as > long as there are no typos, everything works beautifully. > > And lastly, I will admit I haven't researched it recently, but when OLC > first came out I did not find any docs on how to set OLC up in a > master-slave arrangement so the OLC changes on the master are replicated > to the slaves? At least I assume that is how changes should be handled? This is already covered in test059 in the OpenLDAP test suite. ;) For this scenario what you have is: provider server with: cn=config db (master configuration) back-ldif db (replica configuration) replica server(s) that use syncrepl with the suffixmassage parameter to replica from the back-ldif DB on the master. This allows you to isolate out the replica configuration, since it by definition has to differ from the provider configuration. To update the replica configs, you simply do a write to the ldap provider's back-ldif DB, and the replicas all pull it down immediately. One write op -> Updates all replicas. > So anyway, we need a git trail of changes (or some sort of change log) > and I need to figure out how to set up delta-syncrepl for cn=config and > then seamlessly and safely transition 15 slaves and a master. If I can > do this I will jump on the cn=config wagon. This is possible as noted above. ;) I've put it on my to-do list however to create a test script that covers delta-sync replication for cn=config (There's none currently covering that). Then it can be used as an example. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

--On Monday, September 18, 2017 8:18 PM +0200 Radovan Semancik <radovan.semancik(a)evolveum.com> wrote: > On 09/18/2017 06:25 PM, Quanah Gibson-Mount wrote: >> Numerous projects have BSD-style licenses, this isn't OpenLDAP >> specific. So yes, you should already have a legal team, if that's >> necessary in your case, that's familiar with dealing with FOSS >> licenses, to review them. > > Not really. Not that many any more. But in fact I try to avoid using such > projects. Certainly I do not consider contributions into these. I think > that is not worth the effort. Unfortunately, I have to conclude that > OpenLDAP project seems to confirm my assumption. You generally seem fairly convinced the world is aligned against you. I'm not sure there's a solution to that that the OpenLDAP project can help you with. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Instructions for Open LDAP library?
by Martin van den Nieuwelaar 18 Sep '17

18 Sep '17

Hi People, I'm writing an application using Qt and wish to use the openldap library within my program to query an LDAP server. I have been searching for instructions on using the library from a client point of view but have not been successful. I tried using the man pages and I think I'm part way there but have reached an impasse on the correct way (or any way at all for that matter) to extract the results from an LDAPMessage *. I have an example search working using the command line program ldap_search, so the next thought is to look at the source for ldap_search and see what calls it makes to figure things out. This somehow seems like the wrong way to be going about things however. Is there something equivalent for openldap to the documentation for libcurl, https://ec.haxx.se/libcurl-easyhandle.html ? If there is that would be brilliant. I also tried searching for 3rd party howtos and tutorials and there are a few of those but invariably they use now deprecated library calls. Regards, -Martin -- R A Ward Ltd. | We take the privacy of our customers seriously. Christchurch | All sensitive E-Mail attachments MUST be encrypted. New Zealand

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

--On Monday, September 18, 2017 8:11 PM +0200 Radovan Semancik <radovan.semancik(a)evolveum.com> wrote: > On 09/18/2017 06:27 PM, Quanah Gibson-Mount wrote: >> git is a pretty standard tool. Interestingly, numerous people seem to >> have no issue using git to check out the source, do a git format >> patch, and submit it for inclusion with the project. You can see this >> rather trivially by looking at my scratch repo where I've been >> consolidating contributed patches for review and inclusion in OpenLDAP: > > Yes, git is great tool and it is standard. No doubt about that. But why > there is no official OpenLDAP repo on github/gitlab? There is: <https://github.com/openldap/openldap> > Why the people > cannot contribute by simple pull requests? It is rather simple to set up > and maintain. And it lowers the entry barrier by a huge amount. Would be > ideal for fixes in man pages. Once you've gone to the work to do a change and commit it, there is little difference from that point of doing a pull request or a git format patch. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by Howard Chu 18 Sep '17

18 Sep '17

Radovan Semancik wrote: > On 09/18/2017 06:25 PM, Quanah Gibson-Mount wrote: >> Numerous projects have BSD-style licenses, this isn't OpenLDAP specific. So >> yes, you should already have a legal team, if that's necessary in your case, >> that's familiar with dealing with FOSS licenses, to review them. > > Not really. Not that many any more. But in fact I try to avoid using such > projects. Certainly I do not consider contributions into these. I think that > is not worth the effort. Unfortunately, I have to conclude that OpenLDAP > project seems to confirm my assumption. The OpenLDAP license has been in use in its present form since 2003. It has certainly stood the test of time, which is something many other licenses cannot claim. Relicensing all of the code would be a non-trivial effort, as well. Basically everything you've posted amounts to "why doesn't this project that has been running for 19 years not conform to my newbie expectations?" It is not the community's obligation to conform to newcomers' expectations. It's the newcomer's obligation to observe existing community policies. That's true in all communities, not just open source. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

--On Monday, September 18, 2017 7:13 PM +0200 Radovan Semancik <radovan.semancik(a)evolveum.com> wrote: > >> That's incorrect. It's a BSD-style license, it doesn't get much more >> basic than that. <https://en.wikipedia.org/wiki/BSD_licenses> > > The point is that is may be BSD-style license. But it is not a BSD > license. I may need to run OpenLDAP license with our company lawyer to > make sure it is BSD-like and to be sure about the implications that might > be hidden there. I would not need to do that with a BSD license. > Everybody knows that one already. That's the power of standardization. It > saves time and lowers barriers. Numerous projects have BSD-style licenses, this isn't OpenLDAP specific. So yes, you should already have a legal team, if that's necessary in your case, that's familiar with dealing with FOSS licenses, to review them. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

--On Monday, September 18, 2017 7:08 PM +0200 Radovan Semancik <radovan.semancik(a)evolveum.com> wrote: > On 09/18/2017 05:20 PM, Howard Chu wrote: >> Radovan Semancik wrote: >>> I would ... if this was a wiki, or github-like pull request and if >>> there was an example of how a good result should look like. But it >>> does not make sense for me to spend few hours just figuring out how >>> to contribute documentation fix. >> >> So you're still saying, it's fine for other people to put in the hours >> to produce something you benefit from, but it's too much trouble for >> you to contribute in return. And in the meantime, it's perfectly OK >> for you to sit back and complain that things haven't been fixed. Got it. > > I'm afraid that you haven't got the point. According to my experience > people are willing to contribute. I'm willing to contribute. Just the > barrier is too high. But the worst thing is that I feel that the barrier > could be much lower if there was a bit of will to lower it. But the will > is just not there. And I do not see why. It is not 1990s any more. There > are ways how to make cooperation easier. Why not use them? git is a pretty standard tool. Interestingly, numerous people seem to have no issue using git to check out the source, do a git format patch, and submit it for inclusion with the project. You can see this rather trivially by looking at my scratch repo where I've been consolidating contributed patches for review and inclusion in OpenLDAP: <https://github.com/quanah/openldap-scratch> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

--On Monday, September 18, 2017 6:02 PM +0200 Radovan Semancik <radovan.semancik(a)evolveum.com> wrote: > Again, it would be probably already contributed to the project if the > process was more user friendly. But what do I really need to do to > contribute? First, I have to decide whether I'm OK to contribute under > OpenLDAP license. The license is not really standard and I have to check > whether there are some obligations or limitations for my future work. That's incorrect. It's a BSD-style license, it doesn't get much more basic than that. <https://en.wikipedia.org/wiki/BSD_licenses> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by Howard Chu 18 Sep '17

18 Sep '17

Radovan Semancik wrote: > Hi, > > The "cn=config" configuration method is clearly superior. However, there are > serious practical issues. Firstly, the documentation leaves a lot to be > desired. Until recently almost all examples shown the slapd.conf way, > cn=config equivalent was simply missing. Unless I have missed something most > manual pages still assume the slapd.conf configuration method. And so on. These perennial arguments keep coming up. If you want things to improve, contribute. Anyone can write a manpage. Hardly anyone ever does. Everyone sits back and moans while waiting for someone else to fix things for them. That's not what open source projects and communities are about. > Secondly, there are operations that simply cannot be done using ldpamodify in > cn=config (e.g. removal of a suffix database). And thirdly and most > importantly: it is a real pain to remember the configuration schema and write > a multi-line ldapmodify command-line even for simple operations. In most cases you don't need to write multi-line ldapmodify commands. That's what ordering prefixes are for. > Especially > given that you have to translate suffix names (dc=example,dc=com) to > configuration DNs (olcDatabase={1}mdb,cn=config), set up non-trivial > configuration (e.g. replication) and so on. The cn=config method may be > superior. But it is not user friendly. Not even close. > > But, OpenLDAP is an open source project. If there is something that a user > does not like then there is always something that can be done about it. For > example, I like cn=config, but I hate the lack of tooling. Therefore I have > created the missing tools: > > https://github.com/Evolveum/slapdconf Again, if you want the project to improve - contribute. 3rd party tooling dilutes the knowledge pool. If you think you've improved some aspect of the code, contribute it back to the Project. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

--On Thursday, September 14, 2017 3:06 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Hi, > > > I am trying to see what is the best and recommended way of > deploying/starting ldap, OLC or conf file based? i was in the impression > that conf file based is easy and more controllable approach than OLC? slapd.conf is deprecated, and support for it will be removed in a future release. It is recommended taht new deployments use cn=config. I would say "easy and more controllable" are not measurable, nor are they relevant. I find cn=config to be trivially easy, for example, and allows me to execute much better control over my deployments. YMMV. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 3

Unknown server id in contextCSN
by Tim 18 Sep '17

18 Sep '17

Heya, Currently running OpenLDAP 2.4.40 (most recent Centos patch) in a MirrorMaster environment. The two instances have olcServerIds of 101 and 102.. Within the syncprepl, each server is using a RID of 999. Everything appears to be working fine - but each of my providers now have replication cookies that seem to reference some other servers?? contextCSN: 20170918082017.961842Z#000000#*065*#000000 contextCSN: 20170915112957.845512Z#000000#*066*#000000 Is this an oddity/bug? Or could someone point me in the right direction to better understand what I'm seeing and where I've got confused? Thanks in advance. -- Tim tim(a)yetanother.net

2 2

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

--On Thursday, September 14, 2017 6:30 PM -0500 Andy Dorman <adorman(a)ironicdesign.com> wrote: > I have our dev server using OLC and it takes me twice as long to modify > it's config than the 15 other servers we have running openLDAP. It takes all of ldapadd/modify to modify cn=config. If you're having that much difficulty, it sounds like you don't understand how to use cn=config. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 4

SASL Passthrough Kerberos Authentication Backend - Preauthentication
by Uli Tehrani 18 Sep '17

18 Sep '17

Hi all, i wanted to use SASL-Passthrough with kerberos-Backend to have a common Password for LDAP and Kerberos Authentication. LDAP-Authentication is only working with the preauthentication Flag disabled. Is this normal or did i make a mistake ? Do i have other possibilities to have a common Password and Password-Policy ? Thanks in advance Kind regards Uli -- =================================== Ulrich Tehrani Am Ulrichshof 19 79189 Bad Krozingen +497633806246 u_tehrani(a)yahoo.de =================================== .

1 0

slapd: null_callback : error code 0x14
by Paul B. Henson 16 Sep '17

16 Sep '17

So I've been putting off posting about this, but I recently upgraded to 2.4.45, stopped using the memberof overlay, no longer have a node with serverID 0, and overall think my ldap servers should be in good shape :), and it's still happening, so I thought it was time... I'm getting weird errors in my logs about group replication changes: Sep 15 03:55:16 minerva slapd[71654]: null_callback : error code 0x14 Sep 15 03:55:16 minerva slapd[71654]: syncrepl_message_to_op: rid=003 be_modify uid=arc464,ou=group,dc=cpp,dc=edu (20) Sep 15 03:56:32 minerva slapd[71654]: null_callback : error code 0x14 Sep 15 03:56:32 minerva slapd[71654]: syncrepl_message_to_op: rid=002 be_modify uid=ce427l01,ou=group,dc=cpp,dc=edu (20) Sep 15 03:56:53 minerva slapd[71654]: null_callback : error code 0x14 Sep 15 03:56:53 minerva slapd[71654]: syncrepl_message_to_op: rid=003 be_modify uid=chm250l01,ou=group,dc=cpp,dc=edu (20) They sporadically happen on my replicas, on random groups, not typically the same groups on each one on any given day: Sep 15 04:04:52 egeria slapd[29652]: null_callback : error code 0x14 Sep 15 04:04:52 egeria slapd[29652]: syncrepl_message_to_op: rid=001 be_modify uid=soc202,ou=group,dc=cpp,dc=edu (20) Sep 15 04:02:38 coeus slapd[3333]: null_callback : error code 0x14 Sep 15 04:02:38 coeus slapd[3333]: syncrepl_message_to_op: rid=001 be_modify uid=mat321,ou=group,dc=cpp,dc=edu (20) I'm updating the member and memberUid attributes: Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205558 MOD dn="uid=soc202,ou=group,dc=cpp,dc=edu" Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205558 MOD attr=member Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205558 RESULT tag=103 err=0 text= Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205559 MOD dn="uid=soc202,ou=group,dc=cpp,dc=edu" Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205559 MOD attr=memberUid Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205559 RESULT tag=103 err=0 text= Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205560 MOD dn="uid=soc202,ou=group,dc=cpp,dc=edu" Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205560 MOD attr=member Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205560 RESULT tag=103 err=0 text= Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205561 MOD dn="uid=soc202,ou=group,dc=cpp,dc=edu" Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205561 MOD attr=memberUid Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205561 RESULT tag=103 err=0 text= Sep 15 03:55:15 themis slapd[3035]: conn=125451 op=174816 MOD dn="uid=arc464,ou=group,dc=cpp,dc=edu" Sep 15 03:55:15 themis slapd[3035]: conn=125451 op=174816 MOD attr=member Sep 15 03:55:15 themis slapd[3035]: conn=125451 op=174816 RESULT tag=103 err=0 text= Sep 15 03:55:15 themis slapd[3035]: conn=125451 op=174817 MOD dn="uid=arc464,ou=group,dc=cpp,dc=edu" Sep 15 03:55:15 themis slapd[3035]: conn=125451 op=174817 MOD attr=memberUid Sep 15 03:55:15 themis slapd[3035]: conn=125451 op=174817 RESULT tag=103 err=0 text= As far as I can tell, all the updates succeed and the objects are exactly the same on all the replicas, so these failures just seem to be log noise? Any thoughts on what's going on? Thanks...

1 0

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Friday, September 15, 2017 12:47 PM -0700 Ryan Tandy <ryan(a)nardis.ca> wrote: > On Fri, Sep 15, 2017 at 11:44:47AM -0700, Quanah Gibson-Mount wrote: >> Generally it's considered a no-no. For this instance, it may be the >> easiest route if you can do it without breaking things. ;) > > If you do take that path, it's best if you make some kind of online > modification to the same schema entry afterwards (even a no-op), so that > slapd writes out the backing file again with a regenerated checksum and > so forth. You can also just delete the CRC line from the file, or recalculate the CRC. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Friday, September 15, 2017 12:41 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > But updating schema.ldif file in disk is not recommended way right? Generally it's considered a no-no. For this instance, it may be the easiest route if you can do it without breaking things. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by rammohan ganapavarapu 15 Sep '17

15 Sep '17

Quanah, But updating schema.ldif file in disk is not recommended way right? Thanks, Ram On Fri, Sep 15, 2017 at 11:33 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Friday, September 15, 2017 12:24 PM -0700 Ryan Tandy <ryan(a)nardis.ca> > wrote: > > > There was some talk, either in IRC or on -devel, of creating a way for >> cn=config to reference schema files (possibly LDIF) on disk rather than >> importing them into the config database. I think that would be an >> improvement. Importing schemas into cn=config is cool - especially if you >> want to replicate the config - but I'm not sure it's a good default. >> > > Since ordering is mandatory, it would be nice if you could just do > something like: > > olcSchemaFile: {0}include: file://$ABS_SCHEMADIR/core.ldif > olcSchemaFile: {1}include: file://$ABS_SCHEMADIR/cosine.ldif > olcSchemaFile: {2}include: file://$ABS_SCHEMADIR/inetorgperson.ldif > > > etc. Then you could change the schema files on disk, and cn=config would > just load them in when it started. It'd certainly make the behavior > analagous to slapd.conf, and allow for easier rollback/testing. > > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > >

1 0

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Friday, September 15, 2017 8:49 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > Quanah Gibson-Mount wrote: >> --On Friday, September 15, 2017 7:57 PM +0200 Michael Ströder >> <michael(a)stroeder.com> wrote: >>> I strongly disagree. It's a schema shipped by OpenLDAP >>> installation. So this update should have simply worked. >> >> Since the schema is stored in the cn=config DB, there's not an >> option to replace the ppolicy LDIF in cn=config on upgrade. It >> has to be scripted. > > I fully understand the technical reason for what went wrong. > > But the sysadmin should not be required to script anything in case a > schema file always shipped by OpenLDAP was updated by a regular OpenLDAP > update. It should simply work like it does with other LDAP server > implementations and cn=config. The OpenLDAP project only provides one thing -- Source code. So no, the sysadmin is actually responsible for ensuring upgrade procedures between versions work for their deployment. If they are using a build of OpenLDAP provided by their OS vendor, then the OS vendor is going to be responsible. However, it is non-trivial for the OS vendor to be aware of what configuration(s) a given end-user is using, and whether or not they are affected by any specific change. Again why I think this particular change should not have gone into RE24. It was a significant breaking change that is non-trivial for end users to deal with. We generally keep such things out of RE24. There are many great logging updates in RE25 for example that can be incredibly helpful for people on RE24 (operation duration, TLS cipher suite logging, etc), but we don't pull them in as it could break tools that depend on the existing 2.4 format. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Friday, September 15, 2017 9:12 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > This change led to a non-trivial breakage because the back-config > concepts and best practices have serious deficiencies. I actually wrote a utility for Zimbra that replaces the schema in back-config for me on upgrades. This problem would have never manifested there. ;) But it still relies on knowing the exact weighting of the schema files, which in an environment like Zimbra, I could do since I controlled it. For $random installation, it is non-trivial. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Friday, September 15, 2017 7:57 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > I strongly disagree. It's a schema shipped by OpenLDAP installation. So > this update should have simply worked. Since the schema is stored in the cn=config DB, there's not an option to replace the ppolicy LDIF in cn=config on upgrade. It has to be scripted. > I did test the update with my own installations. > But they simply use slapd.conf. > And it worked. ;-} This would imply you updated the schema files at the same time. If you kept the 2.4.40 ppolicy.schema file with your new configuration, it would not have "simply" worked. Your comparison is not analagous. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Friday, September 15, 2017 10:01 AM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > And the upgrade issue with 'pwdMaxRecordedFailure' (see other mail > thread) serves as good example how easy it is to run into a operational > dead-end with cn=config. There's no easy way to fix this afterwards > without violating what's considered best practice for maintaining > cn=config. I could give several other examples for this kind of > operational dead-ends. In retrospect, I think the ITS that introduced that change should not have gone into RE24. ;) Unfortunately, one thing that people seldom test in testing calls is upgrade scenarios from older versions of OpenLDAP to a current release, with a variety of configurations, so it was not caught as an issue prior to release. Certainly another reason as to why we need 2.5 out with slapmodify (and possibly a flag to disable loading some modules in that scenario). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Upgrade from 2.4.40 to 2.4.44
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Friday, September 15, 2017 9:23 AM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > I manually updated the ppolicy.ldif and restarted slapd and it seems > working fine, can i do that way? Not recommended, but yes. > So the idle processed wold be slapcat cm=config from 2.4.40 and add new > attribute, upgrade ldap to 2.4.44 and slapadd back? well, slapcat cn=config from 2.4.40, add the attribute to the LDIF, slapadd it back, and then upgrade to 2.4.44. > Is it possible to do ldapmodify 2.4.40 schema with new attribute? yes. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Upgrade from 2.4.40 to 2.4.44
by rammohan ganapavarapu 15 Sep '17

15 Sep '17

I manually updated the ppolicy.ldif and restarted slapd and it seems working fine, can i do that way? So the idle processed wold be slapcat cm=config from 2.4.40 and add new attribute, upgrade ldap to 2.4.44 and slapadd back? Is it possible to do ldapmodify 2.4.40 schema with new attribute? Thanks On Sep 15, 2017 8:10 AM, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote: > --On Thursday, September 14, 2017 9:30 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > >> If i accident allt upgrade rpm to 2.4.44 is there any way to fix this >> issue? >> > > Use slapcat to export the cn=config database, modify the schema to add the > attribute, and use slapadd to restore it. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Upgrade from 2.4.40 to 2.4.44
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Thursday, September 14, 2017 9:30 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > If i accident allt upgrade rpm to 2.4.44 is there any way to fix this > issue? Use slapcat to export the cn=config database, modify the schema to add the attribute, and use slapadd to restore it. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Friday, September 15, 2017 10:09 AM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > Quanah Gibson-Mount wrote: >> I think it's a strong plus to be able to reconfigure a >> standalone server into an MMR cluster with zero downtime, > > I don't buy this argument. If you're really eager reaching high > availability you have to implement a decent load-balancer and test > correct fail-over anyway. And then your MMR cluster will have zero > down-time (seen from the LDAP clients) during re-configuration even when > restarting the replicas one after another. I'm talking about the process of taking a single provider + multiple replica environment and trivially transitioning that to an MMR environment, where it can either be a mix of providers and replicas, or all providers, etc. With the replicas configured to pull from 1+ providers. You can do that entire transition via cn=config with no downtime. With slapd.conf, you will have to stop the provider (outage) to reconfigure it into an MMR capable scenario. And I've never needed a load balancer with properly written software that understands how to parse multiple LDAP URI's for failover. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Antw: Re: Olc deployment vs slapd.conf based deployment
by Michael Ströder 15 Sep '17

15 Sep '17

Ulrich Windl wrote: >>>> Michael Ströder <michael(a)stroeder.com> schrieb: >> Personally I would never replicate cn=config. > > You mean "via LDAP"? Yes. > I think the best way for an unreliable MMR LDAP server is > to run it with different configs on each node ;-) Yes. >> Use a decent config management system instead. > > to replicate the config, right? No, to *install* a specific config for the target system. Ciao, Michael.

1 0

Upgrade from 2.4.40 to 2.4.44
by rammohan ganapavarapu 15 Sep '17

15 Sep '17

Hi, I have ldap server with 2.4.40 and I have upgraded to 2.4.44 as part of yum upgrade, now I am not able to bring up ldap server , i am getting some ppolicy maxrecord failure attribute error, we are using ppolicy overlay, any advice how to fix this issue? Thanks

2 1

Re: Upgrade from 2.4.40 to 2.4.44
by rammohan ganapavarapu 15 Sep '17

15 Sep '17

Quanah, Thank you ,is there any thing else do i have to take care to upgrade from <=2.4.40 to 2.4.44? is there any upgrade doc that i can use? Ram On Thu, Sep 14, 2017 at 6:50 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, September 14, 2017 7:24 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > I have ldap server with 2.4.40 and I have upgraded to 2.4.44 as part of >> yum upgrade, now I am not able to bring up ldap server , i am getting >> some ppolicy maxrecord failure attribute error, we are using ppolicy >> overlay, any advice how to fix this issue? >> > > > The schema for ppolicy was changed in 2.4.43. You have to add the the > following attribute to ppolicy.ldif: > > olcAttributeTypes: {16}( 1.3.6.1.4.1.42.2.27.8.1.30 NAME > 'pwdMaxRecordedFailure' EQUALITY integerMatch ORDERING integerOrderingMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) > > This should be done *prior* to upgrading. Unfortunately, it appears this > requirement was not well communicated. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 1

Re: Upgrade from 2.4.40 to 2.4.44
by rammohan ganapavarapu 15 Sep '17

15 Sep '17

If i accident allt upgrade rpm to 2.4.44 is there any way to fix this issue? On Sep 14, 2017 6:50 PM, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote: --On Thursday, September 14, 2017 7:24 PM -0700 rammohan ganapavarapu < rammohanganap(a)gmail.com> wrote: I have ldap server with 2.4.40 and I have upgraded to 2.4.44 as part of > yum upgrade, now I am not able to bring up ldap server , i am getting > some ppolicy maxrecord failure attribute error, we are using ppolicy > overlay, any advice how to fix this issue? > The schema for ppolicy was changed in 2.4.43. You have to add the the following attribute to ppolicy.ldif: olcAttributeTypes: {16}( 1.3.6.1.4.1.42.2.27.8.1.30 NAME 'pwdMaxRecordedFailure' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) This should be done *prior* to upgrading. Unfortunately, it appears this requirement was not well communicated. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Upgrade from 2.4.40 to 2.4.44
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Thursday, September 14, 2017 7:24 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > I have ldap server with 2.4.40 and I have upgraded to 2.4.44 as part of > yum upgrade, now I am not able to bring up ldap server , i am getting > some ppolicy maxrecord failure attribute error, we are using ppolicy > overlay, any advice how to fix this issue? The schema for ppolicy was changed in 2.4.43. You have to add the the following attribute to ppolicy.ldif: olcAttributeTypes: {16}( 1.3.6.1.4.1.42.2.27.8.1.30 NAME 'pwdMaxRecordedFailure' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) This should be done *prior* to upgrading. Unfortunately, it appears this requirement was not well communicated. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Olc deployment vs slapd.conf based deployment
by rammohan ganapavarapu 15 Sep '17

15 Sep '17

Thank you. On Sep 14, 2017 5:37 PM, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote: > --On Thursday, September 14, 2017 6:30 PM -0500 Andy Dorman < > adorman(a)ironicdesign.com> wrote: > > I have our dev server using OLC and it takes me twice as long to modify >> it's config than the 15 other servers we have running openLDAP. >> > > It takes all of ldapadd/modify to modify cn=config. If you're having that > much difficulty, it sounds like you don't understand how to use cn=config. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > >

1 0

Re: Import LDIF from old OpenLDAP Server
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Thursday, September 14, 2017 1:49 PM +0200 "Bänsch, Christian (TF)" <christian.baensch(a)fau.de> wrote: > dn: dc=ltm,dc=uni-erlangen,dc=de > dn: o=ltm,dc=uni-erlangen,dc=de These are clearly different root objects. You'll need to adjust the database root in your configuration to import your old database. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: I can't seem to find the answer to these olcAccess questions
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Tuesday, September 12, 2017 10:40 PM -0500 Nick Gray <nick(a)graysaustin.com> wrote: > I read the man page, but I guess I understood that the first rule only > matched everything as a far as "what" to access. I thought it went what, > who, permissions > > My intent was to enable both of these to work. > > Access to all > dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage > and access to all dn.base=" cn=Manager,dc=local,dc=bob,dc=com" to manage > as well Then it is a single ACL: olcAccess: {0} to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn="cn=Manager,dc=local,dc=bob,dc=com" manage --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Olc deployment vs slapd.conf based deployment
by rammohan ganapavarapu 14 Sep '17

14 Sep '17

Hi, I am trying to see what is the best and recommended way of deploying/starting ldap, OLC or conf file based? i was in the impression that conf file based is easy and more controllable approach than OLC? Thanks, Ram

1 0

Import LDIF from old OpenLDAP Server
by Bänsch, Christian (TF) 14 Sep '17

14 Sep '17

Dear list members, My apologies in advance, if it´s not the right place to ask for. I´m an absolute beginner in OpenLDAP and my first job is to relieve our old OpenLDAP Servers installed onto SLES 10.x. and migrate it to new hard- and software. Therefore I´ve installed and configured a test machine with Ubuntu 16.04 LTS to test the migration, import and later login and so on. OpenLDAP is version 2.4.42, installed from package manager. Later OpenLDAP should be running as a "provider/comsumer" for replica. The provider on a new hardware, the consumer within a VM. Both OS should be Ubuntu 16.04 LTS. After initial configuration slapcat show the following entries onto the test machine. ***** dn: dc=ltm,dc=uni-erlangen,dc=de objectClass: top objectClass: dcObject objectClass: organization o: ltm dc: ltm structuralObjectClass: organization entryUUID: bfca1276-1852-1037-80bd-373544139e33 creatorsName: cn=admin,dc=ltm,dc=uni-erlangen,dc=de createTimestamp: 20170818111847Z entryCSN: 20170818111847.816167Z#000000#000#000000 modifiersName: cn=admin,dc=ltm,dc=uni-erlangen,dc=de modifyTimestamp: 20170818111847Z dn: cn=admin,dc=ltm,dc=uni-erlangen,dc=de objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e1NTSEF9YUJ2VGF1YVgxODJpNE1zaTVwNkRnVWR2NDN1TnFzZUI= structuralObjectClass: organizationalRole entryUUID: bfd1af40-1852-1037-80be-373544139e33 creatorsName: cn=admin,dc=ltm,dc=uni-erlangen,dc=de createTimestamp: 20170818111847Z entryCSN: 20170818111847.866104Z#000000#000#000000 modifiersName: cn=admin,dc=ltm,dc=uni-erlangen,dc=de modifyTimestamp: 20170818111847Z ***** First I´ve tried with a copy from the original LDAP-Server DB.ldif file from the old server to import, but it fails. Here´s an "extract" from a few lines of DB.LDIF" ***** dn: o=ltm,dc=uni-erlangen,dc=de o: ltm objectClass: organization structuralObjectClass: organization entryUUID: c517ac96-315a-102c-8517-630622d96f14 creatorsName: cn=Administrator,o=ltm,dc=uni-erlangen,dc=de modifiersName: cn=Administrator,o=ltm,dc=uni-erlangen,dc=de createTimestamp: 20071127173437Z modifyTimestamp: 20071127173437Z entryCSN: 20071127173437Z#000000#00#000000 ... ***** After that I´ve created with ldapsearch created an save.ldif file to avoid those lines like creators and modifiers from the running LDAP-Server and tried to import into the new one but it also fails. The error was Server is unwilling to perform (53) additional info: no global superior knowledge Now I´m a little bit confused about import. So I tried to modify the new server entry like the old - my thougt was a conflict in the dn: o=ltm,dc=uni-erlangen,dc=de - but I´ve got no chance. Modifying the new entry onto the test machine says: " Strong(er) authentication required" Could you please give me any hint? Or is there another way? Any help would be greatly appreciated! If you need additional information, please let me know. Thanks in advance! -- Yours sincerely, Christian Baensch

1 0

Re: Where is the '-C' option to 'ldapsearch' documented?
by Howard Chu 13 Sep '17

13 Sep '17

Brian Reichert wrote: > On Tue, Sep 12, 2017 at 01:00:25PM -0700, Ryan Tandy wrote: >> On Tue, Sep 12, 2017 at 03:56:07PM -0400, Brian Reichert wrote: >>> Is this a supported option? Is it documented somewhere officially? >>> I couldn't find it after a quick search... >> >> According to http://www.openldap.org/its/?findid=7177 it is "deprecated >> and intentionally undocumented". > > Helpful pointer, thanks! > > If it's deprecated, what's the approved method of coercing ldapsearch > to pursue referrals? > ldapsearch shouldn't pursue referrals. The directory server you're using should chain requests for you instead of ever returning referrals. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 3

Re: Where is the '-C' option to 'ldapsearch' documented?
by Howard Chu 13 Sep '17

13 Sep '17

Brian Reichert wrote: > On Tue, Sep 12, 2017 at 10:07:29PM +0100, Howard Chu wrote: >> Brian Reichert wrote: >>> On Tue, Sep 12, 2017 at 01:00:25PM -0700, Ryan Tandy wrote: >>>> On Tue, Sep 12, 2017 at 03:56:07PM -0400, Brian Reichert wrote: >>>>> Is this a supported option? Is it documented somewhere officially? >>>>> I couldn't find it after a quick search... >>>> >>>> According to http://www.openldap.org/its/?findid=7177 it is "deprecated >>>> and intentionally undocumented". >>> >>> Helpful pointer, thanks! >>> >>> If it's deprecated, what's the approved method of coercing ldapsearch >>> to pursue referrals? >>> >> ldapsearch shouldn't pursue referrals. The directory server you're using >> should chain requests for you instead of ever returning referrals. > > Regrettably, the directory server, in this case, is Active Directory. > > https://technet.microsoft.com/en-us/library/cc978014.aspx > > Active Directory returns referrals in accordance with RFC 2251. > > https://social.technet.microsoft.com/Forums/ie/en-US/41d26e7a-a65c-47fe-b81… > > I don't see Microsoft changing their tune anytime soon. :/ > > I have to admit, this is the first I've heard of chaining a request. > > This might a way out for me: > > http://blog.heeresonline.com/2014/04/activedirectory-ldap-referrals-chasing/ > > In any event, it's clear that directory servers _can_ return > referrals, and as such, it surprises me that there isn't a supported > way for OpenLDAP's tool to honor such a configuration. > > I presume this has been discussed to death on this list, but I > couldn't find any historical threads on the topic. Can you provide > some references? The option was removed from the documentation back in 2002. Most likely any discussion would have been on the openldap-software mailing list, which was used before openldap-technical was created. I suggest you look at http://lmgtfy.com/?q=site:openldap.org+referral+ldapsearch -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

I can't seem to find the answer to these olcAccess questions
by Nick Gray 13 Sep '17

13 Sep '17

I have a very simple config that I can show with ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config olcDatabase=\* dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: {-1}frontend olcAccess: {0} to * by dn="cn=Manager,dc=local,dc=bob,dc=com" manage dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0} to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external l,cn=auth" manage olcAccess: {1} to * by dn="cn=Manager,dc=local,dc=bob,dc=com" manage dn: olcDatabase={1}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth" read by dn.base="cn=Manager,dc=my-domain,dc=com" read by * none dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbIndex: objectClass eq,pres olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub olcDbDirectory: /data/openldap olcRootDN: cn=Manager,dc=local,dc=bob,dc=com olcSuffix: dc=local,dc=bob,dc=com olcRootPW: {SSHA}3E+8/IcRHHTNez5QXlyRMP6mCZODN3LE olcAccess: {0} to * by dn="cn=Manager,dc=local,dc=bob,dc=com" manage With this config,.shouldn't this work as well ldapsearch -x -W -D cn=Manager,dc=local,dc=bob,dc=com -b cn=config olcDatabase=\* My other question is where is there a reference to exactly what "gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth" means. I can't seem to find one. Thanks Nick

2 2

Where is the '-C' option to 'ldapsearch' documented?
by Brian Reichert 12 Sep '17

12 Sep '17

I was debugging some random issue involving pursuing referrals, and found a note on this page: http://etutorials.org/Server+Administration/ldap+system+administration/Part… And it makes this assertion: By default, the ldapsearch tool shipped with OpenLDAP 2 prints information about referral objects but does not automatically follow them. ... To follow the search referral, give the -C (chase referrals) option when you invoke ldapsearch: And, by golly, it worked! I'm using the openldap-ltb-2.4.39-2.el6.x86_64 RPM package, and that package's manpage and 'ldapsearch --help' show nothing about this option. Is this a supported option? Is it documented somewhere officially? I couldn't find it after a quick search... -- Brian Reichert <reichert(a)numachi.com> BSD admin/developer at large

2 2

Re: OpenLDAP taker a long time (90s+) to shutdown
by Quanah Gibson-Mount 12 Sep '17

12 Sep '17

--On Tuesday, September 12, 2017 8:52 PM +0900 Alexandre Rosenberg <arekkusu(a)r42.ch> wrote: > dbnosync Why did you set this? > I was wondering what is the expected time for OpenLDAP to shutdown. > Also I am unsure if the checkpoiont setting could be related. It generally depends on how much information there is to flush out to disk, and that can depend on the speed of the disk subsystem. I would note, for example, that in some AWS environments, this can take an exceptionally long time. YMMV. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: I can't seem to find the answer to these olcAccess questions
by Quanah Gibson-Mount 12 Sep '17

12 Sep '17

--On Tuesday, September 12, 2017 1:38 PM -0700 Ryan Tandy <ryan(a)nardis.ca> wrote: > On Mon, Sep 11, 2017 at 04:18:20PM -0500, Nick Gray wrote: >> With this config,.shouldn't this work as well >> >> ldapsearch -x -W -D cn=Manager,dc=local,dc=bob,dc=com -b cn=config >> olcDatabase=\* > > The rules on your config database are: > > olcAccess: {0} to * by > dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage > olcAccess: {1} to * by dn="cn=Manager,dc=local,dc=bob,dc=com" manage > > The first matches everything (*), so the second is never consulted. Which is specifically noted in the slapd.access(5) man page: The optional field <control> controls the flow of access rule application. It can have the forms stop continue break where stop, the default, means access checking stops in case of match. So as noted in the man page, ACL processing stops at the first matching access rule. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Invalid credentials problem
by Quanah Gibson-Mount 12 Sep '17

12 Sep '17

--On Tuesday, September 12, 2017 2:34 PM +0000 JC <lovecraftesque(a)yahoo.com> wrote: > > > > Thanks. I now know. Perhaps OpenLDAP might return a somewhat less > misleading error diagnostic in situations like this? It is not misleading, it is as per RFC. The issue is more, being new to LDAP, you're not aware of what the message means. ;) Also, please keep replies on the -technical list. More specifically, invalid credentials simply means some part of the credentials supplied is incorrect. In your case it was the DN. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

OpenLDAP taker a long time (90s+) to shutdown
by Alexandre Rosenberg 12 Sep '17

12 Sep '17

Hello, I run into a issue where OpenLDAP would not shutdown within 90s. Sometimes shutdown is fast and sometimes not. This concern production server getting a fair amount of traffic. The reason I am mentioning 90s is because this is the default timeout for sytemd service. After that time it sends SIGKILL to the process. I am running latest OpenLDAP (2.45) with MDB database (~1GB). The server is a consumer of another OpenLDAP Server. Maybe more importantly following directive are present under the MDB database configuration. dbnosync checkpoint 500 5 I was wondering what is the expected time for OpenLDAP to shutdown. Also I am unsure if the checkpoiont setting could be related. Best, Alex

1 0

Re: Controls answers, OID unicity
by Howard Chu 12 Sep '17

12 Sep '17

Côme Chilliet wrote: > Hello, > > As some may know I’m working toward supporting controls in php-ldap. > > I’m facing two questions regarding controls to help me build the API: > - Is it possible to have several controls with the same OID in a request or response? (if not it would allow me to parse the answer to a control hash with oid as keys) > -> I tried to put twice the same control with «LDAP_CONTROL_PRE_READ» and got the error "preread control: specified multiple times", but I do not know if this is specific to preread or if it’s a rule. Not possible, no. > - Is the critical field of controls used in responses? It seems openldap server let it to false always (or I’m failing to parse it). RFC4511 section 4.1.11 is quite explicit here - the critical field in responses is always false. > > I could not find information about these subjects in RFC 2251, if there is an other RFC on this subject bringing more information do not hesitate to point me to it :-) > > Côme > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Controls answers, OID unicity
by Côme Chilliet 12 Sep '17

12 Sep '17

Hello, As some may know I’m working toward supporting controls in php-ldap. I’m facing two questions regarding controls to help me build the API: - Is it possible to have several controls with the same OID in a request or response? (if not it would allow me to parse the answer to a control hash with oid as keys) -> I tried to put twice the same control with «LDAP_CONTROL_PRE_READ» and got the error "preread control: specified multiple times", but I do not know if this is specific to preread or if it’s a rule. - Is the critical field of controls used in responses? It seems openldap server let it to false always (or I’m failing to parse it). I could not find information about these subjects in RFC 2251, if there is an other RFC on this subject bringing more information do not hesitate to point me to it :-) Côme

1 0

Re: pwdAccountLockedTime not in ppolicy.ldif
by Quanah Gibson-Mount 11 Sep '17

11 Sep '17

--On Monday, September 11, 2017 3:01 PM +0200 Jacques Loonen <j.loonen(a)ru.nl> wrote: Hi Jacques, > We use cn = config, so we load ppolicy.ldif. pwdaccountlockedtime is not > included in this file. It is not included in ppolicy.schema or ppolicy.ldif. It is a hard-coded part of the ppolicy overlay. My guess is that while you included the ppolicy overlay in your slapd.conf configuration, you failed to properly load it when using cn=config. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Invalid credentials problem
by Quanah Gibson-Mount 11 Sep '17

11 Sep '17

--On Sunday, September 10, 2017 12:19 AM +0000 JC <lovecraftesque(a)yahoo.com> wrote: > rootdn "uid=root,ou=People,dc=owns4,dc=com" ># ldapwhoami -x -H ldap://myipaddress -D "dc=owns4,dc=com" -w xyzabc > ldap_bind: Invalid credentials (49) What makes you believe that "dc=owns4,dc=com" is a valid identity to bind as? It certainly doesn't match the rootdn you configured. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Using TLS connecting to a AD server. openldap2.4.42
by Quanah Gibson-Mount 11 Sep '17

11 Sep '17

--On Sunday, September 10, 2017 2:25 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > I thought you have to set LDAP_OPT_X_TLS_NEWCTX to 0 *after* setting all > TLS-related options to let libldap reinitialize the client's SSL context. > Doesn't that work as expected? Well, my point was, he's doing: ldap_set_option (ld, LDAP_OPT_X_TLS_REQUIRE_CERT, &reqcert); when instead you have to do: ldap_set_option (NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &reqcert); and then set up a new TLS context. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

pwdAccountLockedTime not in ppolicy.ldif
by Jacques Loonen 11 Sep '17

11 Sep '17

Hello all, We are trying to migrate our LDAP servers from eDirectory to OpenLDAP. We have replication and replication of pwdaccountlockedtime and pwdfailuretime working. Our provisioning system (Dell Quest) has trouble filling the pwdaccountlockedtime attribute. The reason for this is that this attribute is not present in the schema. We use cn = config, so we load ppolicy.ldif. pwdaccountlockedtime is not included in this file. In ppolicy.schema, pwdaccountlockedtime has been identified, but this is for the slapd.conf variant. How can we load pwdaccountlockedtime in the schedule using the cn = config method? Can anyone provide us with more information about this? Thanks in advance! We are useing openldap-2.4.44.-5.el7.x86_64 - In 2.4.45 pwdaccountlockedtime seems also not included in ppolicy.ldif Kind regards, Jacques Loonen Radboud University Nijmegen - The Netherlands Met vriendelijke groet, Jacques Loonen http://jloonen.ruhosting.nl/@59B6:7AC1/ -- ICT-Specialist - Radboud Universiteit Nijmegen - http://www.ru.nl/ ICT Servicecentrum - http://www.ru.nl/isc/ Geert Grooteplein-Zuid 41, 6525 GA Nijmegen E-mail: j.loonen(a)ru.nl <mailto:j.loonen@ru.nl> - Tel.: +31(0)24-36 17828

1 0

Re: pcache overlay, caching DNs
by Howard Chu 11 Sep '17

11 Sep '17

Roel van Meer wrote: > Hi list! > > I've been figuring out how to get the pcache overlay to work, but I'm stuck > with one thing: caching of DNs. > > Take this example config: > > overlay pcache > pcache bdb 10000 2 500 100 > directory /var/lib/ldap/cache > > pcacheAttrset 0 * > pcacheAttrset 1 uid > > pcacheTemplate (uid=) 0 300 > pcacheTemplate (uid=) 1 300 > > This works for queries like: > > ldapsearch "uid=foo" '*' > > or > > ldapsearch "uid=foo" 'uid' > > but NOT for: > > ldapsearch "uid=foo" 'dn' > > Can anyone tell me if it is at all possible to use pcache for caching DNs? > > > Things I have tried so far: > > - adding 'dn' as a pcacheAttrset, but then slapd fails to start > with the error "line 63: attribute type undefined". That should have told you already, you're barking up the wrong tree. DN is not an attribute. > - adding 'distinguishedName' as a pcacheAttrset, and then the > result is cached when I request the distinguishedName > attribute, but not when the dn is requested. > > I've tried openldap 2.4.40 and 2.4.44 (specifically, the version from Debian > jessie and the version from jessie-backports). > > Thanks a lot, > > Roel > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Invalid credentials problem
by JC 10 Sep '17

10 Sep '17

I have just installed the OpenLDAP server, version 2.4.42, in my Linux. I have done some basic configuration for a fictitious domain owns4.com. My slapd.conf has the following contents: include /etc/openldap/schema/core.schemainclude /etc/openldap/schema/cosine.schemainclude /etc/openldap/schema/nis.schemainclude /etc/openldap/schema/own.schema pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/libexec/openldapmoduleload back_bdb.la database bdbsuffix "dc=owns4,dc=com" rootdn "uid=root,ou=People,dc=owns4,dc=com" rootpw xyzabc directory /var/lib/openldap dbconfig set_cachesize 0 2097152 0 index objectClass eq lastmod on access to attrs=userPassword,shadowLastChange by dn="cn=root,dc=owns4,dc=com" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=root,dc=owns4,dc=com" write by * read After launching the slapd daemon with /usr/libexec/slapd -d 7 I can issue a few commands that are apparently successful: # ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts -LLLdn:namingContexts: dc=owns4,dc=com # ldapwhoami -x -H ldap://myipaddressanonymous myipaddress is the IP address of the system where I am issuing the commands, which is the same as where the OpenLDAP daemon is running. However, the next command is not successful: # ldapwhoami -x -H ldap://myipaddress -D "dc=owns4,dc=com" -w xyzabcldap_bind: Invalid credentials (49) It elicits the following output from slapd: 59b4713e slap_listener_activate(7): 59b4713e >>> slap_listener(ldap:///)59b4713e connection_get(13)59b4713e connection_get(13): got connid=100159b4713e connection_read(13): checking for input on id=1001ber_get_nextldap_read: want=8, got=8 0000: 30 21 02 01 01 60 1c 02 0!...`.. ldap_read: want=27, got=27 0000: 01 03 04 0f 64 63 3d 6f 77 6e 73 34 2c 64 63 3d ....dc=owns4,dc= 0010: 63 6f 6d 80 06 78 79 7a 61 62 63 com..xyzabc ber_get_next: tag 0x30 len 33 contents:59b4713e op tag 0x60, time 1504997694ber_get_nextldap_read: want=8 error=Resource temporarily unavailable59b4713e conn=1001 op=0 do_bindber_scanf fmt ({imt) ber:ber_scanf fmt (m}) ber:59b4713e >>> dnPrettyNormal: <dc=owns4,dc=com>=> ldap_bv2dn(dc=owns4,dc=com,0)<= ldap_bv2dn(dc=owns4,dc=com)=0 => ldap_dn2bv(272)<= ldap_dn2bv(dc=owns4,dc=com)=0 => ldap_dn2bv(272)<= ldap_dn2bv(dc=owns4,dc=com)=0 59b4713e <<< dnPrettyNormal: <dc=owns4,dc=com>, <dc=owns4,dc=com>59b4713e do_bind: version=3 dn="dc=owns4,dc=com" method=12859b4713e ==> bdb_bind: dn: dc=owns4,dc=com59b4713e bdb_dn2entry("dc=owns4,dc=com")59b4713e => bdb_dn2id("dc=owns4,dc=com")59b4713e <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988)59b4713e send_ldap_result: conn=1001 op=0 p=359b4713e send_ldap_result: err=49 matched="" text=""59b4713e send_ldap_response: msgid=1 tag=97 err=49ber_flush2: 14 bytes to sd 13ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 0....a...1.... 59b4713e connection_get(13)59b4713e connection_get(13): got connid=100159b4713e connection_read(13): checking for input on id=1001ber_get_nextldap_read: want=8, got=7 0000: 30 05 02 01 02 42 00 0....B. ber_get_next: tag 0x30 len 5 contents:59b4713e op tag 0x42, time 1504997694ber_get_nextldap_read: want=8, got=0 59b4713e ber_get_next on fd 13 failed errno=0 (Success)59b4713e conn=1001 op=1 do_unbind59b4713e connection_close: conn=1001 sd=13 Isn't the argument to -w in this command supposed to be the same as the value of rootpw in slapd.conf? If so, why is this not working? What are the "ldap_read: want=8 error=Resource temporarily unavailable" and "bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found " diagnostics all about?

2 1

Re: Using TLS connecting to a AD server. openldap2.4.42
by Quanah Gibson-Mount 10 Sep '17

10 Sep '17

--On Friday, September 08, 2017 6:48 PM +0000 Don jessup <djessup72(a)yahoo.com> wrote: > int reqcert = LDAP_OPT_X_TLS_NEVER; > ldap_set_option (ld, LDAP_OPT_X_TLS_REQUIRE_CERT, &reqcert); > > Is there way to make this work programmatically without using the > ldap.conf? Yes. The problem is the TLS options generally have to be set globally. You might want to look at <https://github.com/quanah/openldap-scratch/commit/59dbb01122ad92ef2a6e05cc3…> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Using TLS connecting to a AD server. openldap2.4.42
by Don jessup 08 Sep '17

08 Sep '17

I'm working on client program to connect to an AD server over TLS. I have found out if I set the int reqcert = LDAP_OPT_X_TLS_NEVER;ldap_set_option (ld, LDAP_OPT_X_TLS_REQUIRE_CERT, &reqcert); programmatically I'm not able to connect to the AD server over TLS. If I set the option "TLS_REQCERT never" in the /usr/local/etc/openldap/ldap.conf everything works. Is there way to make this work programmatically without using the ldap.conf? Here is example code below: #define LDAP_SERVER "ldaps://10.235.217.52:636" int main( int argc, char **argv ){ LDAP *ld; int rc; char bind_dn[100]; /* Open LDAP Connection */ if( ldap_initialize(&ld, LDAP_SERVER) ) { perror("ldap_open"); return( 1 ); } // set option telling LDAP if we need to use a cert. //int reqcert = LDAP_OPT_X_TLS_NEVER; // if (ldap_set_option (ld, LDAP_OPT_X_TLS_REQUIRE_CERT, &reqcert) != LDAP_OPT_SUCCESS) // { // perror("ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT"); // return (1); // } int desired_version = LDAP_VERSION3; /* set the LDAP version to be 3 */ if (ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, &desired_version) != LDAP_OPT_SUCCESS) { perror("ldap_set_option PROTOCOL_VERSION"); return (1); } struct timeval timeout; timeout.tv_sec = 10; timeout.tv_usec = 0; if (ldap_set_option (ld, LDAP_OPT_NETWORK_TIMEOUT, &timeout) != LDAP_OPT_SUCCESS) { perror("ldap_set_option LDAP_OPT_NETWORK_TIMEOUT"); return (1); } sprintf(bind_dn, "%s", "bigco\\bob"); printf("Connecting as %s...\n", bind_dn); /* User authentication (bind) */ rc = ldap_simple_bind_s(ld, bind_dn, "Testit123"); if( rc != LDAP_SUCCESS ) { fprintf(stderr, "ldap_simple_bind_s: %s\n", ldap_err2string(rc)); return( 1 ); } printf("Successful authentication\n"); ldap_unbind(ld); return( 0 );} ThanksDon

1 0

Re: Failing consumers over to second mirror master provider
by Tim 08 Sep '17

08 Sep '17

Perfect! Thanks guys - I was confusing syncRepl with other replication mechanisms I've had experience of and assumed that updates coming in via syncRepl would be blindly replayed to any connected consumers. Just the push I needed in the right direction. On Fri, Sep 8, 2017 at 3:09 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Friday, September 08, 2017 10:37 AM -0400 Frank Swasey < > Frank.Swasey(a)uvm.edu> wrote: > > Today at 7:43am, Tim wrote: >> >> I realise that the RID has to be unique - so am I right in thinking that >>> there is no way for the failover to seamless, and replication must be >>> re-established by removing the existing syncrepl statement, on the >>> consumers, and re-adding it with the secondaries details? >>> >>> Or am I missing a trick here as to how the process could be smoother? >>> >> >> You are missing the point. >> >> You say you have a load balancer that decides which of your MMR partners >> should receive the traffic. Your consumers should be configured in such >> a way that both MMR partners will accept the connection. >> >> For example... >> >> My MMR partners are ldap7p and ldap7q. The load balanced VIP is ldap7rw. >> My consumers are set up with unique RIDs (the RID is unique for each >> consumer) and their provider is ldap7rw. It does not matter whether the >> load balancer sends the traffic to ldap7p or ldap7q - the consumer is >> talking to ldap7rw. >> > > Consumers can also be configured with > 1 syncrepl stanza, and simply talk > to both masters at the same time. There is no need for them to be > reconfigured at all. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > -- Tim tim(a)yetanother.net

1 0

Re: Failing consumers over to second mirror master provider
by Quanah Gibson-Mount 08 Sep '17

08 Sep '17

--On Friday, September 08, 2017 10:37 AM -0400 Frank Swasey <Frank.Swasey(a)uvm.edu> wrote: > Today at 7:43am, Tim wrote: > >> I realise that the RID has to be unique - so am I right in thinking that >> there is no way for the failover to seamless, and replication must be >> re-established by removing the existing syncrepl statement, on the >> consumers, and re-adding it with the secondaries details? >> >> Or am I missing a trick here as to how the process could be smoother? > > You are missing the point. > > You say you have a load balancer that decides which of your MMR partners > should receive the traffic. Your consumers should be configured in such > a way that both MMR partners will accept the connection. > > For example... > > My MMR partners are ldap7p and ldap7q. The load balanced VIP is ldap7rw. > My consumers are set up with unique RIDs (the RID is unique for each > consumer) and their provider is ldap7rw. It does not matter whether the > load balancer sends the traffic to ldap7p or ldap7q - the consumer is > talking to ldap7rw. Consumers can also be configured with > 1 syncrepl stanza, and simply talk to both masters at the same time. There is no need for them to be reconfigured at all. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Antw: Re: Removing Berkeley DB Log Files
by Quanah Gibson-Mount 08 Sep '17

08 Sep '17

--On Friday, September 08, 2017 9:55 AM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > I think that's a good example why an ID should be different from the > user's common (sur)name. If you have jdoe as memeber of some groups, > youll have some additional fun unless LDAP is smart enough to adjust > those... Sure, it was purely an example. There are plenty of cases where subtree renames may be required. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Failing consumers over to second mirror master provider
by Tim 08 Sep '17

08 Sep '17

Hey, I have, what I hope is, a vanilla mirror-master setup, There is a load balancer in between the providers and consumers, that ensures that the writes will consistently be written to a single provider, until it becomes unavailable - at which point writes will failover to the hot-stand by. With regards to replication for the consumers - currently they all have a single provider explicitly defined within their configuration and I'm trying to understand what options are available with which the failover from one provider to the other would best be handled if the master was to die? I realise that the RID has to be unique - so am I right in thinking that there is no way for the failover to seamless, and replication must be re-established by removing the existing syncrepl statement, on the consumers, and re-adding it with the secondaries details? Or am I missing a trick here as to how the process could be smoother? Thanks in advance -- Tim tim(a)yetanother.net

2 1

Re: Antw: syncrepl error (53) with 3-way delta-mmr (consumer state is newer than provider)
by Sven Mäder 08 Sep '17

08 Sep '17

On 09/04/2017 08:51 AM, Ulrich Windl wrote: >>>> Sven Mäder <maeder(a)phys.ethz.ch> schrieb am 01.09.2017 um 16:53 in > Nachricht > <2832441b-362f-9429-8c56-32995cff5ef1(a)phys.ethz.ch>: >> Hi Ulrich >> >> Thank you for your response. >> >> On 08/31/2017 09:37 AM, Ulrich Windl wrote: >>> Hi! >>> >>> Some of the time ntpd needs to sync may be host name resolution (if you > use >>> names). Methods to speed up initial synchronization inlude "iburst", >> "minpoll" >>> and adding a large crowd of servers. Note that reducing minpoll could > reduce >>> the final accuracy (just as increasing "maxpoll" does). Depending on your >>> network and load I would not rely on a time offset less than a few ten >>> milliseconds. How well LDAP can operate then is a different question. >> We have 2 timeservers (stratum 1) in our local net with gps clock source: >> server time1.phys.ethz.ch minpoll 4 maxpoll 10 iburst >> server time2.phys.ethz.ch minpoll 4 maxpoll 10 iburst >> >> minpoll is already set at its lowest value, although I do not understand >> what this option does. I may increase its value, increasing accuracy sounds >> good. > The manual explains what "minpoll" does. Basically it is the starting poll > interval. Short values cause adjustment to be made faster than nomal. However > if subsequent polls fail, the clock could continue to run with wrong correction > values and the accumulate some time error (i.e. make things worse). A big > maxpoll might not correct he clock in time. And you probably should have an odd > number of time servers. > Reading the correct manuals helps, looks like the debian manpages are outdated (ntp version 1:4.2.8p10+dfsg-3) compared to the manpages of the upstream source tarball (ntp-4.2.8p10.tar.gz) and to the manuals on http://doc.ntp.org/current-stable/. Even the upstream source tarball is not in line with the manuals on the website.According the manual on http://doc.ntp.org/current-stable/confopt.html it is now possible to use a minimal poll interval of 3. Thanks to your inputs I started playing around with minpoll and maxpoll. Looks like on my setup a maxpoll of 10 is too high, as the accumulated time errorstarts to increase notably from poll interval >6. See attached graph (ntp_graph_phd-aa_20170908.png) or https://people.phys.ethz.ch/~rda/img/ntp_graph_phd-aa_20170908.png I also noticed, that a higher rootdelay or the variation of the delay has a big impact on the time offset. Under normal conditions we have a delay of 0.3 - 0.4 ms in our local network (offset: ~0.050 ms). But the servers which are in the same subnet as our ntp servers sometimes have to make ARP requests if the poll interval is higher. The ntp server has to do the same. This results in a root delay of ~1.5ms, which I think confuses ntp which in turn results in offsets of 0.500-1.500 ms. See attached graph (ntp_graph_phd-debug-aa_20170908.png) or https://people.phys.ethz.ch/~rda/img/ntp_graph_phd-debug-aa_20170908.png >> # ntptrace >> localhost: stratum 2, offset 0.000008, synch distance 0.031825 >> time1.ethz.ch: stratum 1, offset -0.000001, synch distance 0.000298, >> refid 'PPS' >> >> # ntpq -c pe >> remote refid st t when poll reach delay offset >> jitter >> > ============================================================================ >> == >> LOCAL(0) .LOCL. 5 l 149m 64 0 0.000 0.000 >> 0.000 >> *time1.ethz.ch .PPS. 1 u 251 256 377 0.426 0.009 >> 0.026 >> +time2.ethz.ch .PPS. 1 u 64 256 377 0.430 -0.003 >> 0.019 >> >> Looks like the time offset is only a few microseconds once ntp is in sync. > Yes, looks good. > >>> Also note for Linux (on most platforms) and NTP one problem is that the >>> frequency correction needed for the clock can vary significantly between >> boots; >>> thus the tijme for "perfect sync" can be quite long. See attached image for >> an >>> example. >> This is very interesting, we will look further into this. >> I am thinking about waiting in the startup process until ntp is in >> "perfect sync"and start slapd after that. Maybe I can use the loopstats >> file to check/automate this. > Perfect sync can take quite some time (due to design of NTP) [From RFC 1305: > "This yields a PLL risetime of > about 52 minutes, a maximum overshoot of about 4.8 percent in about 1.7 hours > and a settling time > to within one percent of the initial offset in about 8.7 hours."] > The good thing is that NTP itself provides performance numbers to check. Maybe > start with clk_wander being low, rootdisp being low, and offset being low. > There are some pathological cases where the numbers are low while the clock in > in a bad condition. > Thanks, monitoring these numbers using graphs helps me a lot.I am looking forward to the results of some long term tests with different settings, to see what gives the most stable and accurate time for our ldap servers. >>> Updating one entry on different servers within a very short time (shorter >> than >>> the time of syncing) will probably cause trouble. What real-life situation >>> causes such? >> Probably none. But we have a logparser, which writes "last use" statistics >> of our users to ldap, this is done in "realtime". We also use openldap as >> kerberos KDC database backend, which writes on successful/failed >> authentication attempts. The chance is probably very low if the time offset >> is lower than the network delay. > Maybe you could centralize the logparser to run on only one host at a time... > > Regards, > Ulrich > > Kind regards Sven

1 0

Re: Antw: Re: Removing Berkeley DB Log Files
by Quanah Gibson-Mount 08 Sep '17

08 Sep '17

--On Thursday, September 07, 2017 12:03 PM -0400 Douglas Duckworth <dod2014(a)med.cornell.edu> wrote: > > Why would you want to rename a subtree? I can only think of a scenario > if for example we would have to sync with another LDAP cluster that > perhaps had ou=Accounts whereas we have ou=People. A subtree is simply any DN that has children. So if you, for example, had: dn: uid=jdoe, cn=people, dc=example, dc=com dn: signature=work, uid=jdoe, cn=people, dc=example, dc=com And jdoe got divorced and changed their last name, and wanted their uid updated, you could do a subtree rename to fix her entry and all children entries at the same time. Otherwise, you'd have to either delete the existing entries and create new ones, or create new ones and delete the old ones, etc. Or stop everything, do an export, fix the data, reimport. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Antw: Re: Removing Berkeley DB Log Files
by Douglas Duckworth 07 Sep '17

07 Sep '17

Ah, this recursive change would be extremely useful for us given that example. Thanks for pushing me to abandon bdb. I'll do that once the old cluster's no longer in use. On Sep 7, 2017 11:15 AM, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote: > --On Thursday, September 07, 2017 12:03 PM -0400 Douglas Duckworth > <dod2014(a)med.cornell.edu> wrote: > > > > > Why would you want to rename a subtree? I can only think of a scenario > > if for example we would have to sync with another LDAP cluster that > > perhaps had ou=Accounts whereas we have ou=People. > > A subtree is simply any DN that has children. > > So if you, for example, had: > > dn: uid=jdoe, cn=people, dc=example, dc=com > dn: signature=work, uid=jdoe, cn=people, dc=example, dc=com > > And jdoe got divorced and changed their last name, and wanted their uid > updated, you could do a subtree rename to fix her entry and all children > entries at the same time. Otherwise, you'd have to either delete the > existing entries and create new ones, or create new ones and delete the old > ones, etc. Or stop everything, do an export, fix the data, reimport. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.symas.com&d=DwIFaQ&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > eaHUs775FiDziz6vOPByKLyL8czWp4lI31AYF8-i3C4&s= > oOnY5I8rAHwXosqpofTs9gxnDk9jYzqhI4LgtQXzKeY&e=> > >

1 0

Re: Antw: Re: Removing Berkeley DB Log Files
by Douglas Duckworth 07 Sep '17

07 Sep '17

Why would you want to rename a subtree? I can only think of a scenario if for example we would have to sync with another LDAP cluster that perhaps had ou=Accounts whereas we have ou=People. Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690 On Thu, Sep 7, 2017 at 11:00 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, September 07, 2017 8:57 AM -0700 Quanah Gibson-Mount > <quanah(a)symas.com> wrote: > > > Yes. LDAP is a protocol. It doesn't care what the underlying storage DB > > is. So you could have a back-hdb master and a back-mdb consumer, etc. > > Although I would note, don't do a subtree rename until all backends in use > support it. ;) > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.symas.com&d=DwICAg&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > VP9PaF9h0TG3hKW5JyTRk11nKzg5E7oJrVOiTo8H5ss&s=zs3UlQjg5PMR-7ut_ > HMW98Jj3be5u1Ji1HtHeSxSm4I&e=> > >

1 0

Re: Antw: Re: Removing Berkeley DB Log Files
by Quanah Gibson-Mount 07 Sep '17

07 Sep '17

--On Thursday, September 07, 2017 8:57 AM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > Yes. LDAP is a protocol. It doesn't care what the underlying storage DB > is. So you could have a back-hdb master and a back-mdb consumer, etc. Although I would note, don't do a subtree rename until all backends in use support it. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Antw: Re: Removing Berkeley DB Log Files
by Quanah Gibson-Mount 07 Sep '17

07 Sep '17

--On Thursday, September 07, 2017 11:19 AM -0400 Douglas Duckworth <dod2014(a)med.cornell.edu> wrote: > > We have one provider and one consumer running syncrepl. All of our > important clients are using sssd, configured to cache everything, with > the consumer set as secondary ldap server. I have verified that > everything works properly in sssd if the provider goes offline. > > Can I flip the provider to hdb, or mdb, and keep consumer as bdb, with > syncrepl still running, then later change the consumer? Yes. LDAP is a protocol. It doesn't care what the underlying storage DB is. So you could have a back-hdb master and a back-mdb consumer, etc. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Antw: Re: Removing Berkeley DB Log Files
by Douglas Duckworth 07 Sep '17

07 Sep '17

We have one provider and one consumer running syncrepl. All of our important clients are using sssd, configured to cache everything, with the consumer set as secondary ldap server. I have verified that everything works properly in sssd if the provider goes offline. Can I flip the provider to hdb, or mdb, and keep consumer as bdb, with syncrepl still running, then later change the consumer? Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690 On Thu, Sep 7, 2017 at 10:03 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, September 07, 2017 8:45 AM -0400 Douglas Duckworth > <dod2014(a)med.cornell.edu> wrote: > > > > > Can't one dump the database to LDIF then make changes? That's probably > > not going to work for Amazon or Facebook but we only have 4000 entries in > > our database. > > That would be the only way to do a subtree rename with back-bdb, yes. > Again, there's no reason to use back-bdb. > > back-bdb: Introduced in OpenLDAP 2.1 to replace back-ldbm > back-hdb: Introduced in OpenLDAP 2.2 to replace back-bdb > back-mdb: Introduced in OpenLDAP 2.4 to replace both back-bdb and back-hdb > > If you're using back-bdb, at least move to back-hdb. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.symas.com&d=DwIFaQ&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > T4QUYvunGpzAlWdSQVnXzovTYA5PPC2r_droZTewjpQ&s=OtEn0Ve3-TwnPsoq_Ujr9NKy_ > rbTo5XhJTn8hxcsT1Y&e=> > >

1 0

Re: Antw: Re: Removing Berkeley DB Log Files
by Quanah Gibson-Mount 07 Sep '17

07 Sep '17

--On Thursday, September 07, 2017 8:45 AM -0400 Douglas Duckworth <dod2014(a)med.cornell.edu> wrote: > > Can't one dump the database to LDIF then make changes? That's probably > not going to work for Amazon or Facebook but we only have 4000 entries in > our database. That would be the only way to do a subtree rename with back-bdb, yes. Again, there's no reason to use back-bdb. back-bdb: Introduced in OpenLDAP 2.1 to replace back-ldbm back-hdb: Introduced in OpenLDAP 2.2 to replace back-bdb back-mdb: Introduced in OpenLDAP 2.4 to replace both back-bdb and back-hdb If you're using back-bdb, at least move to back-hdb. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

pcache overlay, caching DNs
by Roel van Meer 07 Sep '17

07 Sep '17

Hi list! I've been figuring out how to get the pcache overlay to work, but I'm stuck with one thing: caching of DNs. Take this example config: overlay pcache pcache bdb 10000 2 500 100 directory /var/lib/ldap/cache pcacheAttrset 0 * pcacheAttrset 1 uid pcacheTemplate (uid=) 0 300 pcacheTemplate (uid=) 1 300 This works for queries like: ldapsearch "uid=foo" '*' or ldapsearch "uid=foo" 'uid' but NOT for: ldapsearch "uid=foo" 'dn' Can anyone tell me if it is at all possible to use pcache for caching DNs? Things I have tried so far: - adding 'dn' as a pcacheAttrset, but then slapd fails to start with the error "line 63: attribute type undefined". - adding 'distinguishedName' as a pcacheAttrset, and then the result is cached when I request the distinguishedName attribute, but not when the dn is requested. I've tried openldap 2.4.40 and 2.4.44 (specifically, the version from Debian jessie and the version from jessie-backports). Thanks a lot, Roel

1 0

glibc 2.25 mutex bug
by Howard Chu 07 Sep '17

07 Sep '17

I spent the past few days trying to reproduce a deadlock in LMDB I've been seeing on a recently updated Arch Linux system. It turns out there's a bug in mutex locking in glibc 2.25. https://sourceware.org/bugzilla/show_bug.cgi?id=21778 Be aware, if your system has upgraded to glibc 2.25 you really need to get onto glib 2.26 otherwise you're going to run into a lot of mysterious hangs. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Antw: Re: Removing Berkeley DB Log Files
by Douglas Duckworth 07 Sep '17

07 Sep '17

Can't one dump the database to LDIF then make changes? That's probably not going to work for Amazon or Facebook but we only have 4000 entries in our database. On Sep 6, 2017 10:32 PM, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote: --On Monday, September 04, 2017 11:33 AM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: >>>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am 01.09.2017 um 21:58 >>>> in > Nachricht <2032476F3CBBE8B34FB96BAD(a)[192.168.1.30]>: >> --On Friday, September 01, 2017 11:48 AM -0400 Douglas Duckworth >> <dod2014(a)med.cornell.edu> wrote: >> >>> >>> Vinyl records are back in style. So it seems slapd.conf and bdb. >> >> Yeah, I got to spend 2+ hours with a customer today because they chose >> to use back-bdb, and it lacks subtree rename... so something that >> should have been trivial to resolve was a long drawn out process. >> There are good reasons things have progressed beyond slapd.conf and >> back-bdb. > > I wonder: Aren't both mdb and bdb key-value databases? So if one backend > implements a subtree rename, the other could do it as well. I think it's > nor fair to blame BDB itself for that... back-hdb supports subtree rename. Pay attention to the difference between back-bdb and back-hdb, both which sit on top of BDB. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <https://urldefense.proofpoint.com/v2/url?u=http- 3A__www.symas.com&d=DwICAg&c=lb62iw4YL4RFalcE2hQUQealT9- RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= WmwoyUOPXDE8GHw4h-NuBEidgQPN6jTRQs_xA0Fm-NM&s=c1SywnbtcEvvlu6yLxToeeC3Ckjr39 2inXrymwgMLBs&e=>

1 0

Re: Fwd: REG: I thought I got the ACLs, but......
by 8zero2 operations 07 Sep '17

07 Sep '17

Thanks man, was searching down the wrong subtree :/, These are the two things I was doing wrong. 1.) I thought i need explicit access to entry and children attributes. 2.) I was searching in root DN and was expecting the accessible DNs to come in result, whereas access(search/read/write access) will also be needed. finally pheww.. I spent one whole day trying to understand this :/ Regards, Mail: 8zero2.in(a)gmail.com Facebook: www.facebook.com/8zero2 Twitter: @8zero2_in Blog: blog.8zero2.in On Wed, Sep 6, 2017 at 8:30 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, September 06, 2017 6:15 PM +0530 8zero2 operations < > 8zero2ops(a)gmail.com> wrote: > > So here is my scenario I have an ou of "user" and an ou of "Administrator" >> now one user from administrator branch should be able to edit anything in >> user branch and the other user should only be able to read the branch >> "user", also I want userPassword to be visible to only Administrator >> which has write permissions. >> > > I suggest reading up on the "entry" pseudo-attribute as documented in the > slapd.access(5) man page. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Antw: Re: Removing Berkeley DB Log Files
by Quanah Gibson-Mount 07 Sep '17

07 Sep '17

--On Monday, September 04, 2017 11:33 AM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: >>>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am 01.09.2017 um 21:58 >>>> in > Nachricht <2032476F3CBBE8B34FB96BAD(a)[192.168.1.30]>: >> --On Friday, September 01, 2017 11:48 AM -0400 Douglas Duckworth >> <dod2014(a)med.cornell.edu> wrote: >> >>> >>> Vinyl records are back in style. So it seems slapd.conf and bdb. >> >> Yeah, I got to spend 2+ hours with a customer today because they chose >> to use back-bdb, and it lacks subtree rename... so something that >> should have been trivial to resolve was a long drawn out process. >> There are good reasons things have progressed beyond slapd.conf and >> back-bdb. > > I wonder: Aren't both mdb and bdb key-value databases? So if one backend > implements a subtree rename, the other could do it as well. I think it's > nor fair to blame BDB itself for that... back-hdb supports subtree rename. Pay attention to the difference between back-bdb and back-hdb, both which sit on top of BDB. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: BDB VS HDB for openldap2.4
by Quanah Gibson-Mount 07 Sep '17

07 Sep '17

--On Wednesday, September 06, 2017 8:20 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > What is the recommended backend db for openldap2.4 dbd or hdb? which > one give better performance? back-mdb is the recommended backend for OpenLDAP 2.4. back-bdb and back-hdb are both deprecated and will be removed from a future release. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: BDB VS HDB for openldap2.4
by rammohan ganapavarapu 07 Sep '17

07 Sep '17

What is the recommended backend db for openldap2.4 dbd or hdb? which one give better performance? Thanks, Ram

1 0

Re: hdb_search: 163 does not match filter
by Quanah Gibson-Mount 06 Sep '17

06 Sep '17

--On Wednesday, September 06, 2017 10:05 AM -0400 Bernard Fay <bernard.fay(a)gmail.com> wrote: > > Hello, > > > I see a lot of "hdb_search: x does not match filter" in the log file of > my openldap server. > > > Does someone know what it this about? Should I by worried about this? > How can I fix this if it need to be fixed? It looks like you have your log level set to "TRACE". Thus you are simply seeing hdb parse through every entry and whether or not it matches the supplied filter. It's generally a waste to have that high of a log level set unless you're tracking down a specific problem. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Fwd: REG: I thought I got the ACLs, but......
by Quanah Gibson-Mount 06 Sep '17

06 Sep '17

--On Wednesday, September 06, 2017 6:15 PM +0530 8zero2 operations <8zero2ops(a)gmail.com> wrote: > So here is my scenario I have an ou of "user" and an ou of "Administrator" > now one user from administrator branch should be able to edit anything in > user branch and the other user should only be able to read the branch > "user", also I want userPassword to be visible to only Administrator > which has write permissions. I suggest reading up on the "entry" pseudo-attribute as documented in the slapd.access(5) man page. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

hdb_search: 163 does not match filter
by Bernard Fay 06 Sep '17

06 Sep '17

Hello, I see a lot of "hdb_search: x does not match filter" in the log file of my openldap server. Does someone know what it this about? Should I by worried about this? How can I fix this if it need to be fixed? [root@ slapd]# slapd -V @(#) $OpenLDAP: slapd 2.4.40 (Mar 31 2016 15:24:52) $ mockbuild(a)worker1.bsys.centos.org: /builddir/build/BUILD/openldap-2.4.40/openldap-2.4.40/servers/slapd Thanks, Bernard

1 0

Fwd: REG: I thought I got the ACLs, but......
by 8zero2 operations 06 Sep '17

06 Sep '17

Hi, I have a ACL problem, I am not able to figure out what I am doing wrong. Or if there is something wrong in what I understood. So here is my scenario I have an ou of "user" and an ou of "Administrator" now one user from administrator branch should be able to edit anything in user branch and the other user should only be able to read the branch "user", also I want userPassword to be visible to only Administrator which has write permissions. here is my initial ACL for it {0}to attrs=userPassword by dn.exact="uid=domain.admin,ou= Administrator,dc=example,dc=com" write by anonymous auth {1}to dn.subtree="ou=user,dc=example,dc=com" attrs=entry,children by dn.exact="uid=domain.admin,ou=Administrator,dc=example,dc=com" write by dn.exact="uid=domain.auth,ou=Administrator,dc=example,dc=com" read now using above acl none of the user domain.auth or domain.admin is able read/write/search in "user" ou. Only if I add the following ACL to it. {2} to * by dn.exact="uid=domain.admin,ou=Administrator,dc=example,dc=com" write by dn.exact="uid=domain.auth,ou=Administrator,dc=example,dc=com" read everything works as i want it to work. Mail: 8zero2.in(a)gmail.com Facebook: www.facebook.com/8zero2 Twitter: @8zero2_in Blog: blog.8zero2.in

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical