openldap-technical

openldap-technical@openldap.org

23 participants
9804 discussions

Re: OpenLDAP 2.4.31 available
by Clément OUDOT 27 Apr '12

27 Apr '12

Le 23 avril 2012 18:49, OpenLDAP Project <project(a)openldap.org> a écrit : > OpenLDAP 2.4.31 is now available for download as detailed on our download page: > > http://www.openldap.org/software/download/ > Hi, for people using RPMs, I published some here: http://ltb-project.org/wiki/download#openldap Clément.

2 1

replicating and refint
by Marc Patermann 26 Apr '12

26 Apr '12

Hi, on a master server overlay syncprov and overlay refint (refint_attributes member memberOf) are set. Now on object, which is in a group is deleted. Refint changes the group by deleting the member. The changed user object and the group are to be replicated. The user is. The group is not: Apr 26 17:31:04 server slapd[6475]: syncrepl_entry: rid=401 ou=group,ou=foo Apr 26 17:31:04 server slapd[6475]: syncrepl_entry: rid=401 entry unchanged, ignored (ou=group,ou=foo) dn: ou=group,ou=foo modifyTimestamp: 20110704123836Z modifiersName: cn=Referential Integrity Overlay entryCSN: 20110704123836.000000Z#000001#000#000000 So this is advertised for replication, but the does not happen. This is 2.4.26, has this changed in later versions? Marc

2 1

ldapsearch: Search for Operational Attributes using wildcards
by Uncle Hildegard 26 Apr '12

26 Apr '12

Hi there, I don't understand what's happening here so hopefully someone can help me with this. I have a DIT that contains objects like this: uid=test,ou=user,ou=sales,o=Testcompany Now I want to find out all objects that have "sales" in their DN. Since DN is not an attribute one can search for I used the the operational attribute "entryDN": ldapsearch -x "(entryDN=*sales*)" cn That search didn't find anything. After that I tried ldapsearch -x "(entryDN=uid=test,ou=user,ou=sales,o=Testcompany)" cn and got the expected result. Now it seems that as soon as I use a wildcard in the filter argument the search returns nothing. Even ldapsearch -x "(entryDN=uid=test,ou=user,ou=sales,o=Testcompan*)" cn returns nothing. I've also tried things like ldapsearch -x "(entryDN:dnSubtreeMatch:=*sales*)" cn which returned no result either. Any ideas what I'm doing wrong? Any help would be greatly appreciated! Cheers -- Markus

3 4

OpenLDAP unresponsible after modify/replication operation
by Arturo Borrero Gonzalez 26 Apr '12

26 Apr '12

Hi there, I have an active-active LDAP cluster with N-way multi-master configuration. The slapd version is: 2.4.23-7.2 (Debian Squeeze) After a modify operation in the cn=config tree, we get and unresponsible server (all nodes in the cluster) This is the log (256 loglevel) for the node who gets the original MOD operation. Note the time cut between 12:23:55 and 12:42:54 The deferring operation message was repeated before that cut, and today It's the first time I see it. [...] Apr 26 12:23:55 ldap2 slapd[19556]: conn=7352 op=0 RESULT tag=97 err=0 text= Apr 26 12:23:55 ldap2 slapd[19556]: conn=7352 op=2 UNBIND Apr 26 12:23:55 ldap2 slapd[19556]: conn=7352 fd=204 closed Apr 26 12:23:55 ldap2 slapd[19556]: conn=1399 op=27 MOD dn="olcDatabase={1}hdb,cn=config" Apr 26 12:23:55 ldap2 slapd[19556]: conn=1399 op=27 MOD attr=olcAccess *** Apr 26 12:42:54 ldap2 slapd[19556]: do_syncrepl: rid=001 rc -5 retrying (4 retries left) Apr 26 12:42:54 ldap2 slapd[19556]: do_syncrepl: rid=006 rc -5 retrying (4 retries left) Apr 26 12:42:54 ldap2 slapd[19556]: do_syncrepl: rid=003 rc -5 retrying (4 retries left) Apr 26 12:42:54 ldap2 slapd[19556]: conn=1399 op=27 RESULT tag=103 err=0 text= Apr 26 12:42:54 ldap2 slapd[19556]: conn=7353 fd=135 ACCEPT from IP=[xxx:xx:xx:xx::xx]:58394 (IP=[::]:636) Apr 26 12:42:54 ldap2 slapd[19556]: conn=7354 fd=136 ACCEPT from IP=xx.xx.x.xx:58617 (IP=0.0.0.0:636) Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=5551 deferring operation: too many executing Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=3876 deferring operation: too many executing Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=3876 deferring operation: too many executing Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=3876 deferring operation: pending operations Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=3876 deferring operation: too many executing Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=3876 deferring operation: pending operations Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=3876 deferring operation: too many executing Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=3876 deferring operation: pending operations Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=3876 deferring operation: too many executing Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=3876 deferring operation: pending operations Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=3876 deferring operation: too many executing Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=3876 deferring operation: pending operations Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=3876 deferring operation: too many executing Apr 26 12:42:54 ldap2 slapd[19556]: conn=1399 fd=48 closed (connection lost) Apr 26 12:42:54 ldap2 slapd[19556]: conn=1451 fd=50 closed (connection lost) [...] Apr 26 12:42:54 ldap2 slapd[19556]: conn=7224 op=2 UNBIND Apr 26 12:42:54 ldap2 slapd[19556]: conn=7224 fd=134 closed Apr 26 12:42:54 ldap2 slapd[19556]: conn=6456 op=6 RESULT tag=97 err=0 text= Apr 26 12:42:54 ldap2 slapd[19556]: conn=5551 op=8 ABANDON msg=8 Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=2035 deferring operation: too many executing Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=2035 deferring operation: pending operations Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=2035 deferring operation: too many executing Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=2035 deferring operation: pending operations Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=2035 deferring operation: too many executing Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=2035 deferring operation: pending operations Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=2035 deferring operation: too many executing Apr 26 12:42:54 ldap2 slapd[19556]: conn=5551 op=10 ABANDON msg=10 Apr 26 12:42:54 ldap2 slapd[19556]: conn=3876 op=13 ABANDON msg=13 Apr 26 12:42:54 ldap2 slapd[19556]: conn=1242 op=24 ABANDON msg=24 Apr 26 12:42:54 ldap2 slapd[19556]: conn=1242 op=26 ABANDON msg=26 Apr 26 12:42:54 ldap2 slapd[19556]: conn=1242 op=28 ABANDON msg=28 Apr 26 12:42:54 ldap2 slapd[19556]: conn=1242 op=30 ABANDON msg=30 Apr 26 12:42:54 ldap2 slapd[19556]: conn=1242 op=31 UNBIND Apr 26 12:42:54 ldap2 slapd[19556]: conn=1242 fd=38 closed Apr 26 12:42:54 ldap2 slapd[19556]: conn=5967 op=7 ABANDON msg=7 Apr 26 12:42:54 ldap2 slapd[19556]: conn=5967 op=8 UNBIND Apr 26 12:42:54 ldap2 slapd[19556]: conn=5967 fd=118 closed Apr 26 12:42:54 ldap2 slapd[19556]: conn=2405 op=12 ABANDON msg=12 Apr 26 12:42:54 ldap2 slapd[19556]: conn=2405 op=13 UNBIND Apr 26 12:42:54 ldap2 slapd[19556]: conn=2405 fd=44 closed Apr 26 12:42:54 ldap2 slapd[19556]: conn=2181 op=24 ABANDON msg=24 Apr 26 12:42:54 ldap2 slapd[19556]: conn=2181 op=26 ABANDON msg=26 Apr 26 12:42:54 ldap2 slapd[19556]: conn=2181 op=28 ABANDON msg=28 Apr 26 12:42:54 ldap2 slapd[19556]: conn=2181 op=30 ABANDON msg=30 Apr 26 12:42:54 ldap2 slapd[19556]: conn=5551 op=6 ABANDON msg=6 Apr 26 12:42:54 ldap2 slapd[19556]: conn=2181 op=31 UNBIND Apr 26 12:42:54 ldap2 slapd[19556]: conn=5924 op=5 ABANDON msg=5 Apr 26 12:42:54 ldap2 slapd[19556]: conn=5924 op=7 ABANDON msg=7 Apr 26 12:42:54 ldap2 slapd[19556]: conn=5924 op=9 ABANDON msg=9 Apr 26 12:42:54 ldap2 slapd[19556]: conn=5924 op=10 UNBIND Apr 26 12:42:54 ldap2 slapd[19556]: conn=5924 fd=115 closed Apr 26 12:42:54 ldap2 slapd[19556]: conn=1389 op=9 ABANDON msg=9 Apr 26 12:42:54 ldap2 slapd[19556]: conn=1167 op=15 UNBIND Apr 26 12:42:54 ldap2 slapd[19556]: conn=1167 fd=37 closed Apr 26 12:42:54 ldap2 slapd[19556]: conn=1903 op=10 ABANDON msg=10 Apr 26 12:42:54 ldap2 slapd[19556]: conn=1903 op=11 UNBIND Apr 26 12:42:54 ldap2 slapd[19556]: conn=1903 fd=58 closed Apr 26 12:42:54 ldap2 slapd[19556]: conn=4400 op=3 ABANDON msg=3 Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=6631 deferring operation: too many executing Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=6631 deferring operation: pending operations Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=6631 deferring operation: too many executing Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=6631 deferring operation: pending operations Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=6631 deferring operation: too many executing Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=6631 deferring operation: pending operations Apr 26 12:42:54 ldap2 slapd[19556]: connection_input: conn=6631 deferring operation: too many executing Apr 26 12:42:54 ldap2 slapd[19556]: conn=4400 op=5 UNBIND [...] In other node, also a cut in the log [...] Apr 26 12:22:40 ldap3 slapd[7650]: conn=8292 op=1 SRCH base="dc=xxx,dc=es" scope=2 deref=0 filter="(objectClass=*)" Apr 26 12:22:40 ldap3 slapd[7650]: conn=8292 op=1 SRCH attr=* + Apr 26 12:22:40 ldap3 slapd[7650]: conn=8292 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Apr 26 12:22:40 ldap3 slapd[7650]: conn=8292 op=2 UNBIND Apr 26 12:22:40 ldap3 slapd[7650]: conn=8292 fd=158 closed Apr 26 12:22:41 ldap3 slapd[7650]: conn=8293 fd=158 ACCEPT from IP=192.168.21.21:44703 (IP=0.0.0.0:636) Apr 26 12:22:41 ldap3 slapd[7650]: conn=8294 fd=163 ACCEPT from IP=192.168.21.22:58503 (IP=0.0.0.0:636) Apr 26 12:22:41 ldap3 slapd[7650]: conn=8295 fd=164 ACCEPT from IP=192.168.21.22:58506 (IP=0.0.0.0:636) Apr 26 12:22:41 ldap3 slapd[7650]: conn=8293 fd=158 TLS established tls_ssf=128 ssf=128 Apr 26 12:22:41 ldap3 slapd[7650]: conn=8294 fd=163 TLS established tls_ssf=128 ssf=128 Apr 26 12:22:41 ldap3 slapd[7650]: conn=8295 fd=164 TLS established tls_ssf=128 ssf=128 Apr 26 12:22:42 ldap3 slapd[7650]: slap_client_connect: URI=ldaps://ldap1.xxx.xx/ DN="cn=admin,cn=config" ldap_sasl_bind_s failed (-5) *** Apr 26 12:42:54 ldap3 slapd[7650]: do_syncrepl: rid=001 rc -5 retrying (4 retries left) Apr 26 12:42:54 ldap3 slapd[7650]: null_callback : error code 0x35 Apr 26 12:42:54 ldap3 slapd[7650]: null_callback : error code 0x35 Apr 26 12:42:54 ldap3 slapd[7650]: null_callback : error code 0x35 Apr 26 12:42:54 ldap3 slapd[7650]: conn=8297 fd=165 ACCEPT from IP=[xxx:xxx:xxx:xx::5]:42973 (IP=[::]:636) Apr 26 12:42:54 ldap3 slapd[7650]: conn=8296 fd=160 ACCEPT from IP=192.168.21.22:58509 (IP=0.0.0.0:636) Apr 26 12:42:54 ldap3 slapd[7650]: conn=8293 op=1 UNBIND Apr 26 12:42:54 ldap3 slapd[7650]: conn=8293 op=0 BIND dn="cn=admin,cn=config" method=128 [...] In other node, also a cut after the replication operation, the my service restart: [...] Apr 26 12:22:37 ldap1 slapd[5945]: conn=8377 fd=159 closed (connection lost) Apr 26 12:22:37 ldap1 slapd[5945]: conn=8373 fd=156 closed (connection lost) Apr 26 12:22:37 ldap1 slapd[5945]: conn=8374 fd=157 closed (connection lost) Apr 26 12:22:37 ldap1 slapd[5945]: conn=8375 fd=158 closed (connection lost) Apr 26 12:22:41 ldap1 slapd[5945]: conn=8378 fd=158 ACCEPT from IP=192.168.21.23:57377 (IP=0.0.0.0:636) Apr 26 12:22:41 ldap1 slapd[5945]: conn=8379 fd=159 ACCEPT from IP=192.168.21.23:57379 (IP=0.0.0.0:636) Apr 26 12:22:41 ldap1 slapd[5945]: conn=8380 fd=160 ACCEPT from IP=192.168.21.22:33628 (IP=0.0.0.0:636) Apr 26 12:22:41 ldap1 slapd[5945]: conn=8381 fd=161 ACCEPT from IP=192.168.21.22:33629 (IP=0.0.0.0:636) Apr 26 12:22:41 ldap1 slapd[5945]: conn=8379 fd=159 TLS established tls_ssf=128 ssf=128 Apr 26 12:22:41 ldap1 slapd[5945]: conn=8380 fd=160 TLS established tls_ssf=128 ssf=128 Apr 26 12:22:41 ldap1 slapd[5945]: conn=8379 op=0 BIND dn="cn=admin,dc=xxx,dc=es" method=128 Apr 26 12:22:41 ldap1 slapd[5945]: conn=8379 op=0 BIND dn="cn=admin,dc=xxx,dc=es" mech=SIMPLE ssf=0 Apr 26 12:22:41 ldap1 slapd[5945]: conn=8379 op=0 RESULT tag=97 err=0 text= Apr 26 12:22:41 ldap1 slapd[5945]: conn=8379 op=1 SRCH base="dc=xxx,dc=es" scope=2 deref=0 filter="(objectClass=*)" Apr 26 12:22:41 ldap1 slapd[5945]: conn=8379 op=1 SRCH attr=* + Apr 26 12:22:41 ldap1 slapd[5945]: conn=8381 fd=161 TLS established tls_ssf=128 ssf=128 Apr 26 12:22:41 ldap1 slapd[5945]: conn=8381 op=0 BIND dn="cn=admin,dc=xxx,dc=es" method=128 Apr 26 12:22:41 ldap1 slapd[5945]: conn=8381 op=0 BIND dn="cn=admin,dc=xxx,dc=es" mech=SIMPLE ssf=0 Apr 26 12:22:41 ldap1 slapd[5945]: conn=8381 op=0 RESULT tag=97 err=0 text= Apr 26 12:22:41 ldap1 slapd[5945]: conn=8381 op=1 SRCH base="dc=xxx,dc=es" scope=2 deref=0 filter="(objectClass=*)" Apr 26 12:22:41 ldap1 slapd[5945]: conn=8381 op=1 SRCH attr=* + Apr 26 12:22:41 ldap1 slapd[5945]: conn=8378 fd=158 TLS established tls_ssf=128 ssf=128 Apr 26 12:22:42 ldap1 slapd[5945]: conn=8379 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 26 12:22:42 ldap1 slapd[5945]: conn=8381 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 26 12:22:42 ldap1 slapd[5945]: slap_client_connect: URI=ldaps://ldap3.xxx.xx/ DN="cn=admin,cn=config" ldap_sasl_bind_s failed (-5) *** Apr 26 12:42:54 ldap1 slapd[5945]: daemon: shutdown requested and initiated. Apr 26 12:42:54 ldap1 slapd[5945]: conn=1009 fd=13 closed (slapd shutdown) Apr 26 12:42:54 ldap1 slapd[5945]: conn=1013 fd=20 closed (slapd shutdown) Apr 26 12:42:54 ldap1 slapd[5945]: conn=1014 fd=21 closed (slapd shutdown) [...] Any idea? Best regards. -- /* Arturo Borrero Gonzalez || cer.inet(a)linuxmail.org */ /* Use debian gnu/linux! Best OS ever! */

2 1

How to query ldap root DNs ?
by Bhargav Mistry 26 Apr '12

26 Apr '12

Hi, I have written a java tool which configures ldap servers for master master replication and proxy push. I need to query the root DNs for config and bdb databases so that I can use it in the tool but I am not sure how to query it ? I want to query the dn from the file olcDatabase={2}bdb.ldif but I don't know how? olcDatabase={2}bdb.ldif dn: olcDatabase={2}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {2}bdb olcSuffix: dc=my-domain,dc=com olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,dc=my-domain,dc=com olcSyncUseSubentry: FALSE I tried using the following command line search query but it doesn't return any results: ldapsearch -x -b "" -s base "objectClass=olcBdbConfig" -H ldap://myserver-1:389 -D "cn=config" -w 'secret' any help is highly appreciated. Thanks. This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp

4 4

Open ldap master slave replication not properly syncing
by dhanushka ranasinghe 26 Apr '12

26 Apr '12

Hi guys , i have master slave LDAP replication setup , where master have close to 38000 records, when i start the slave server its starts syncing from master , but when the sync finished slave only sync records close to 30000,. is there any reson for this. please note that , and in slave slapd.conf file it has entry "sizelimit 55000" both the servers have identical times: and in the slave log file i can see the "do_syncrep2: rid=004 CSN too old, ignoring" entry. is there any way sort this issue. Thank You Dhanushka

2 1

ldap server doesn't run after inserting some groups (cn)
by stefano malini 26 Apr '12

26 Apr '12

Hi, I had a good LDAP server on Debian Squeeze, everything was ok. I was able to login using ldap users, i was able to make research using ldapsearch. Now, after adding an ldif file with some groups it doesn't run. Trying ldapsearch the answer is ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) What can be happened?

2 3

Way to email users when their password is about to expire?
by Kline, Sara 25 Apr '12

25 Apr '12

Hey all, Our OpenLDAP environment is up and functional and is working great. I was asked if there is a way to have the server email users when their account password is about to expire. For instance, 7 days before expiration they get an email that lets them know their password will expire on date x. Is there functionality within OpenLDAP to do this, or has anyone written a script that would do it? We are using the policy overlay to enforce the password policy. Sara Kline System Administrator Transaction Network Services, Inc 4501 Intelco Loop, Lacey WA 98503 Wk: (360) 493-6736 Cell: (360) 280-2495 ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

4 3

mismatch between slapd.conf and olcDatabase
by Nagaraj Panyam 25 Apr '12

25 Apr '12

Hi, This is a question from an absolute novice. I just installed openldap (RHEL 6.1), and created a config file with suffix "dc=example, dc=com" And started up slapd. However, the value of "dc" in the olcDatabase files remains "dc=my-domain,dc=com" How does one remove this mismatch? Secondly, how does one see the contents of /var/lib/ldap/log.0000000001 Thanks a lot for the support. - Raj

3 2

syncrepl issue not replicating all changes
by Mark Coetser 25 Apr '12

25 Apr '12

Hi Guys debian stable openldap 2.4.23-7.2 I have multiple consumers with a single provider, when making changes too the provider ie creating a new user, sometimes the change doesnt propagate too all the consumers some have the correct entries and some dont. If I then compare the contextcsn on both the provider and the consumer it is identical on the consumers with the missing entry. The only way I can then resync is by shutting down openldap on the consumer deleting the tree and restarting which then syncs the directory with the missing entry. How would I go about troubleshooting this issue? Or am I missing something simple? Any help would be appreciated. -- Thank you,

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical