openldap-technical April 2014

openldap-technical@openldap.org

61 participants
55 discussions

import new schema via ldapmodify
by Nikos Voutsinas 26 Apr '14

26 Apr '14

Hello all, While practising with the cn=config, I tried to import a new schema to an Openldap 2.4.39 server by using the ldapmodify cmd. Can someone please enlighten me on why the 1st ldif works but not the 2nd one? The "{4}", which is the only difference between the 1st and the 2nd ldif, is the index of the next available object under cn=schema,cn=config 1st (works) ============= dn: cn={4}eduPerson,cn=schema,cn=config changetype: add objectClass: olcSchemaConfig cn: eduPerson dn: cn={4}eduPerson,cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: ( 1.3.6.1.4.1.5923.1.1.1.1 NAME 'eduPersonAffiliation' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) - add: olcObjectClasses olcObjectClasses: ( 1.3.6.1.4.1.5923.1.1.2 NAME 'eduPerson' AUXILIARY MAY ( eduPersonAffiliation ) ) - ============= 2nd (doesn't work) ============= dn: cn=eduPerson,cn=schema,cn=config changetype: add objectClass: olcSchemaConfig cn: eduPerson dn: cn=eduPerson,cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: ( 1.3.6.1.4.1.5923.1.1.1.1 NAME 'eduPersonAffiliation' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) - add: olcObjectClasses olcObjectClasses: ( 1.3.6.1.4.1.5923.1.1.2 NAME 'eduPerson' AUXILIARY MAY ( eduPersonAffiliation ) ) - ============= The command used, looks like this: ldapmodify -h localhost -p 389 -D cn=admin,cn=config -x -W -f <filename> Thanks, Nikos

1 0

How can i setup acl on openldap(ubuntu 12.04)
by Tian Zhiying 25 Apr '14

25 Apr '14

Hi My server is ubuntu 12.04 64bit, install openldap via apt-get, now i want to setup acl,how can i quickly to setup it. Before i use centos 5, slapd.conf on /etc/openldap dir, but slapd.conf is not on /etc/ldap dir at ubuntu 12.04. Tian Zhiying

2 1

Re: LMDB: fast writes: removing the write mutex ?
by Simon Majou 25 Apr '14

25 Apr '14

MDB_NOLOCK doesn't fit, from the doc : #MDB_NOLOCK Don't do any locking. If concurrent access is anticipated, the caller must manage all concurrency itself. I still want the concurrency managed on reads. On Fri, Apr 25, 2014 at 3:06 PM, Hallvard Breien Furuseth <hbf(a)mail.uio.no>wrote: > I wrote: > >> On 13. april 2014 18:04, Simon Majou wrote: >> (...) >> >> In that case, how can I disable the write lock ? >>> Would commenting LOCK_MUTEX_W() & UNLOCK_MUTEX_W() make the trick ? >>> >> >> You could use MDB_NOTLS in LMDB 0.9.7 or later, but then you must >> synchronize threads yourself which does not sound like what you >> want. Also, then you must not write when there are too old readers. >> > > Oops, I meant MDB_NOLOCK. MDB_NOTLS is about readers. > > > > -- Best regards, Simon

1 0

failed bind after password update
by Emmanuel Dreyfus 24 Apr '14

24 Apr '14

Hi After heartbeat we force password resets and we observe an odd behavior: after a password is changed, a replica will fail bind just as if the password was wrong (LDAP_INVALID_CREDENTIALS), while another replica will accept it. slapcat show idential userPassword hashes everywhere: master, bad replica and good replica. Destroying the replica data and resyncrhonizing it fixes the problem. Is there some kind of bind cache somewhere? This is OpenLDAP 2.4.33 -- Emmanuel Dreyfus manu(a)netbsd.org

1 0

slapcat -F failing to backup
by Mike_Mcarthur＠kaltire.com 24 Apr '14

24 Apr '14

Hello; I am running an older version of openldap and having issues in our production environment. We would backup our openldap db by running slapcat -F /etc/openldap/slapd.d/ Recently htat backup fails and causes issues with our ldap db. [root@l900pldp01v ~]# slapcat -F /etc/openldap/slapd.d/ ch_calloc of 1 elems of 800000008 bytes failed slapcat: ../../../servers/slapd/ch_malloc.c:107: ch_calloc: Assertion `0' failed. Aborted When I run this same command in our test system the backups succeed. Any ideas on what the error is talking about? Thank you Mike M

2 2

[LMDB] Access violation
by Alain 23 Apr '14

23 Apr '14

Hi, We've now started to receive regular access violation after running our application for about 30-45 minutes of heavy processing. We are at commit 5bda356 and running under Windows 2k8 R2 Datacenter, service pack 1 Here's what I found from the log file produced by the Java JVM about crashing. The issue happens after our application call db_put. It occurs in mdb_xcursor_init0 (inlined within mdb_cursor_init) at: if (txn->mt_dbs[dbi].md_flags & MDB_DUPSORT) { mdb_tassert(txn, mx != NULL); mc->mc_xcursor = mx; mdb_xcursor_init0(mc); mdb_xcursor_init0(MDB_cursor *mc) { MDB_xcursor *mx = mc->mc_xcursor; mx->mx_cursor.mc_xcursor = NULL; <------here or: 0000000180008A9C: 4D 89 4B 10 mov qword ptr [r11+10h],r9 //mc->mc_xcursor = mx; (6736) 0000000180008AA0: 49 89 59 10 mov qword ptr [r9+10h],rbx //mx->mx_cursor.mc_xcursor = NULL; (6651) Looking at the register it is clear that cursor_init is called with a dbi of zero and a null mx pointer. >From the stack I was able to trace the call to mdb_cursor_init to come from mdb_page_alloc at: if (op == MDB_FIRST) { /* 1st iteration */ /* Prepare to fetch more and coalesce */ oldest = mdb_find_oldest(txn); last = env->me_pglast; mdb_cursor_init(&m2, txn, FREE_DBI, NULL); <-----here the question then is why and how we can have had dupsort turned on for FREE_DBI so that init cursor could have triggered this code. I am working on publishing a change to the above line to disregard FREE_DBI, but that looks like a patch that doesn't address the cause of this issue: if (dbi && txn->mt_dbs[dbi].md_flags & MDB_DUPSORT) { I'm at a real lost how DUPSORT can ever be turned on for FREE_DBI and if that's now a symptom a another problem. Thanks for you help and insight Alain

1 0

SAML Identity Provider for OpenLDAP
by Marc Patermann 22 Apr '14

22 Apr '14

Hi, I searching for proven "extention" to use my OpenLDAP directory data with an SAML identity provider. I found LemonLDAP:NG and OpenAM as possible candidates. Howtos and success stories are welcome! Marc

4 3

Re: (ITS#7840) bug with initial/seed syncrepl
by Jephte Clain 22 Apr '14

22 Apr '14

hello, thanks for your answer. see my response below 2014-04-20 7:13 GMT+04:00 Howard Chu <hyc(a)symas.com>: > Jephte.Clain(a)univ-reunion.fr wrote: >> >> Full_Name: Jephte CLAIN >> Version: 2.4.39 >> OS: Debian 6 64bits >> URL: http://jclain.fr/openldap-its/ >> Submission from: (NULL) (93.176.62.129) >> >> >> I have scripts to test several replication scenarii, that setup the LDAP >> environment then allow me to play with parameters as I see fit. >> >> I believe that there is a bug with the "seed replication" that allow one >> to >> build an exact clone of a master with minimal configuration on the slave >> side. > > > There is no bug. The syncrepl consumer is working as designed. If you want > the consumer's entries to be automatically overwritten, create the consumer > first so that its seed entries have older timestamps than the provider. ok, it works as designed. I just didn't know what the design was :-) quoting man slapd: Use only the rid part to force a full reload. I guess I didn't notice that the word "full" have a different meaning here than usual about creating the consumer first. you are kidding, right? in production, the provider exists long before the consumer is set up. the tests I do are based on the production state. anyway, my automated scripts "touch" the provider after setting up the slave, so this is not a problem. It's just that I would prefer not to have wasted time wondering why the slave was not being updated even though I asked for a "full" reload Thanks for your answer. It's now clearer in my mind. I Cc the openldap-technical list, this can help others. > >> note: the tests below require 2 VMs, or running the two slapd instances in >> chroots, because a clone replica requires the data files to be in the same >> path... > > > That's far overkill. All you need to do is configure your test scripts to > use relative pathnames. test049 (and others) in the test suite already > operates this way. ok thanks for pointing this out It has been a while since I read the tests scripts. I should have paid more attention... > > Closing this ITS. > >> I attach two scripts to replicate the problem. they require root (they >> uses >> chroots) >> this is with openldap 2.4.39 on debian squeeze. some paths may have to be >> fixed >> in the scripts below >> >> use jclain-20140419-0start.sh to: >> - create a ldap server to be served on ldap://localhost:3890 >> - start the master in chroot >> (the logs are in /jclain-slapd-test/master.data/slapd.log) >> - create a seed ldap replica to be served on ldap://localhost:3891 with >> ldap://localhost:3890 as the provider >> - start it in chroot with option -c rid=0 >> (the logs are in /jclain-slapd-test/slave.data/slapd.log) >> >> use jclain-20140419-1stop.sh to: >> - stop the servers >> - umount the chroots >> >> If I understand the manual correctly, after 0start.sh, the replica should >> be >> identical to the master thanks to -c rid=0 >> BUT, the log on the replica says: >> >> 534d5481 dn_callback : new entry is older than ours cn=config ours >> 20140415154713.807278Z#000000#000#000000, new >> 20140415154704.888204Z#000000#000#000000 >> >> and indeed, the seed entries are NOT overwritten >> I have to "touch" them on the master to force the replication. >> >> I have uploaded the scripts to http://jclain.fr/openldap-its/ >> >> thanks in advance >> >> > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- cordialement, Jephté Clain Direction des Systèmes d'Information et des Usages Numériques - 2IG Tél. 0262 93 86 31 Fax. 0262 93 81 06

1 1

TLS init def ctx failed: -73
by ChiiSama 20 Apr '14

20 Apr '14

Hi, does anybody knows what main: TLS init def ctx failed: -73 means ? I replaced my CA, key and cert files. I generated the new certs like the previous before with Debian Stable / CA.pl Script (-newca/newcert). Standard 4096 Bit, rsa/sha certs. Greeting -- Mit freundlichen Grüßen ChiiSama mailto:ChiiSama@gmx.net

2 1

bug(?) with initial/seed syncrepl
by Jephte Clain 19 Apr '14

19 Apr '14

hello, (note: english is not my primary language. I'll do my best to be clear...) I have scripts to test several replication scenarii, that setup the LDAP environment then allow me to play with parameters as I see fit. I believe that there is a bug with the "seed replication" that allow one to build an exact clone of a master with minimal configuration on the slave side. Before I fill an ITS, I'd like to confirm with you that I do the right thing (tm) note: the tests below require 2 VMs, or running the two slapd instances in chroots, because a clone replica requires the data files to be in the same path... this is openldap 2.4.39 on debian squeeze I attach a script to replicate the problem. it requires root (it uses chroots) use 0start.sh to: - create a ldap server to be served on ldap://localhost:3890 - start the master in chroot (the logs are in /jclain-slapd-test/master.data/slapd.log) - create a seed ldap replica to be served on ldap://localhost:3891 with ldap://localhost:3890 as the provider - start it in chroot with option -c rid=0 (the logs are in /jclain-slapd-test/slave.data/slapd.log) use 1stop.sh to: - stop the servers - umount the chroots If I understand the manual correctly, after 0start.sh, the replica should be identical to the master thanks to -c rid=0 BUT, the log on the replica says: 534d5481 dn_callback : new entry is older than ours cn=config ours 20140415154713.807278Z#000000#000#000000, new 20140415154704.888204Z#000000#000#000000 and indeed, the seed entries are NOT overwritten I have to "touch" them on the master to force the replication. so my question is: do I use the -c option correctly, or is there a bug? thanks for your help. regards, -- Jephté Clain Direction des Systèmes d'Information et des Usages Numériques - 2IG Tél. 0262 93 86 31 Fax. 0262 93 81 06

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical April 2014