openldap-technical

openldap-technical@openldap.org

4 participants
9973 discussions

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

Date format
by Frans Lanting - IT Admin 18 Apr '14

18 Apr '14

Hi Folks, This refers to the OpenLDAP found in OS X Server, which Apple calls Open Directory. I'm trying to determine the time when an OpenLDAP replica got its last update from the OpenLDAP master, so on a replica I do the following: % sudo slapconfig -getreplicaconfig Replica LDAP server Updated: 2014-04-18 22:29:01 +0000 List Of Replicas od-example.com - OK My question is the date/time format as seen above, since it does not appear to be GMT/UTC or the server time, so any clarification on this would be most appreciated! I don't see any reference to this slapconfig man page or in Apple server documentation. Thanks in advance, Dan

2 1

attribute for storing SSH RSA host keys
by ML mail 16 Apr '14

16 Apr '14

Hello, On my already existing OpenLDAP server I would like to add an attribute in order to store SSH RSA host keys. Currently there are no such attributes (for example: sshRSAHostKey) in any standard schemas. What would be the best strategy to add this attribute to my OpenLDAP server? Create a new objectClass? or simply add it to another already standard objectClass such as the NIS schema? Regards ML

4 6

Re: OpenLDAP Metadirectory
by Thomas Stegbauer 16 Apr '14

16 Apr '14

Hi, i have in my company two ActiveDirectories. as i have an application which has only the possiblity to query one LDAP-server for authentication i thought about a metadirectory as described here: http://ltb-project.org/wiki/documentation/general/sasl_delegation and here https://www.memolinux.info/doku.php?id=unix:ldap:openldapads&s=meta#backend… so i started with openldap 2.4.31 from debian 7.4. my starting configuration looks like below: what i was missing from the docu, i need a schema, where sAMAccountName, proxyAddresses and so on is defined. so i created the msad.schema as described here: http://serverfault.com/questions/151688/configuring-openldap-as-a-active-di… now i don't get an error when i startup slapd. but when i do an search to the metadirectory for example: "ldapsearch -x -D cn=manager,dc=meta -b dc=meta uid=testuser", i see in the wireshark -the bindreques -the searchrequest within DC=D6200,DC=comp,DC=com -but the search criteria looks like this: (!(objectclass=*)) not (objectclass=*) which finds nothing. and gives me 0 results. also i found: http://www.openldap.org/lists/openldap-technical/201206/msg00168.html But what here unclear, what schema definitions do i need with this? could someone point me to my error, as i am nearly blind for comparing. Thomas slapd.conf ========== # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/msad.schema pidfile /var/run/slapd/slapd.pid loglevel 99 # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_hdb moduleload back_ldap moduleload back_meta moduleload rwm access to * by * read # Database database meta suffix "dc=meta" rootdn "cn=Manager,dc=meta" rootpw secret # LDAP 1 uri "ldap://192.168.0.2:3268/ou=vzp,dc=meta" lastmod off suffixmassage "ou=vzp,dc=meta" "DC=D6200,DC=comp,DC=com" idassert-bind bindmethod=simple binddn="CN=Meta,CN=Users,DC=D6200,DC=comp,DC=com" credentials="secret" mode=none flags=non-prescriptive idassert-authzFrom "dn.exact:cn=Manager,dc=meta" overlay rwm rwm-map objectclass account user rwm-map attribute mail proxyAddresses rwm-map attribute uid sAMAccountName rwm-map attribute cn name rwm-map attribute * # LDAP 2 uri ldap:// 192.168.13.2 :3268/ou=azp,dc=meta lastmod off suffixmassage "ou=azp,dc=meta" "DC=d5820,DC=muc,DC=com" idassert-bind bindmethod=simple binddn="CN=Meta,CN=Users,DC=d5820,DC=muc,DC=com" credentials="secret" mode=none flags=non-prescriptive idassert-authzFrom "dn.exact:cn=Manager,dc=meta" overlay rwm rwm-map objectclass account user rwm-map attribute mail proxyAddresses rwm-map attribute uid sAMAccountName rwm-map attribute cn name rwm-map attribute *

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical