openldap-technical

openldap-technical@openldap.org

20 participants
9802 discussions

RE: OPENLDAP HANGS DAILY
by Quanah Gibson-Mount 05 Dec '13

05 Dec '13

<http://ltb-project.org/wiki/download> --On December 5, 2013 at 2:36:07 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > This was built from source, the OS flavor is 5.9 (originally built on > 5.7). The rpm versions were/are too old. > > Is the link to the LTB packages? > http://ltb-project.org/wiki/documentation/openldap-rpm > > Thanks > Dave > > -----Original Message----- > From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Sent: Thursday, December 05, 2013 2:19 PM > To: Borresen, John - 0442 - MITLL; Michael Ströder; > openldap-technical(a)openldap.org Subject: RE: OPENLDAP HANGS DAILY > > You can quickly upgrade if you use the LTB packages... Which are more > sanely built than the RH ones anyway, which I'm going to guess you are > using based on the version. > > --Quanah > > --On December 5, 2013 at 1:53:15 PM -0500 "Borresen, John - 0442 - MITLL" > <John.Borresen(a)ll.mit.edu> wrote: > >> Yea, I was afraid you were going to say that. >> >> -----Original Message----- >> From: Michael Ströder [mailto:michael@stroeder.com] >> Sent: Thursday, December 05, 2013 1:30 PM >> To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org >> Subject: Re: OPENLDAP HANGS DAILY >> >> Borresen, John - 0442 - MITLL wrote: >>> I just restarted with the group, and the OpenLDAP software has not >>> been upgraded - currently 2.4.23 (that will be coming...hopefully). >>> Anyway, an issue that was brought to my attention upon starting was >>> that slapd needs to be restarted daily. It is still running, it just >>> stops responding (no one can log in). Nothing has, previously, been >>> found in the logs. The other day, during my initial search through >>> the slapd logs I found: >> >> Please upgrade first. Everything else is waste of yours and others time. >> >> Ciao, Michael. >> >> >> > > > > -- > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: Sync working in lab but not in production
by Philip Colmer 05 Dec '13

05 Dec '13

> Big mistake, as mentioned numerous times on the list. Use a current build. OK - I'll test the upgrade process. Thanks for the pointer on that. Philip On 5 December 2013 16:45, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, December 05, 2013 1:38 PM +0000 Philip Colmer > <philip.colmer(a)linaro.org> wrote: > >> I suspect I've broken a fundamental rule of how sync works on OpenLDAP >> but here goes ... >> >> We've been running a single OpenLDAP server for a while now so I >> wanted to get some resiliency into place. We are using version 2.4.28 >> on Ubuntu 12.04. > > > Big mistake, as mentioned numerous times on the list. Use a current build. > > Your log indicates that there is no accesslog DB, so I'd start with > investigating there after you fix the first problem. > > --Quanah > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

Sync working in lab but not in production
by Philip Colmer 05 Dec '13

05 Dec '13

I suspect I've broken a fundamental rule of how sync works on OpenLDAP but here goes ... We've been running a single OpenLDAP server for a while now so I wanted to get some resiliency into place. We are using version 2.4.28 on Ubuntu 12.04. The original machine is a VM so I cloned it and built two further servers from that clone. I then followed the instructions in https://help.ubuntu.com/12.04/serverguide/openldap-server.html to add the provider bits to server A and the consumer bits to server B. That works fine. So, since I had a working consumer, I added the provider bits to the original LDAP server and changed the configuration on server B so that it queries that server and not server A. Syncing now fails and I'm getting the following in the log: slapd[8201]: conn=1059 fd=18 ACCEPT from IP=127.0.0.1:52374 (IP=0.0.0.0:389) slapd[8201]: conn=1059 op=0 BIND dn="cn=XXX,dc=YYY,dc=ZZZ" method=128 slapd[8201]: conn=1059 op=0 BIND dn="cn=XXX,dc=YYY,dc=ZZZ" mech=SIMPLE ssf=0 slapd[8201]: conn=1059 op=0 RESULT tag=97 err=0 text= slapd[8201]: conn=1059 op=1 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(?objectClass=auditWriteObject)(?reqResult=0))" slapd[8201]: conn=1059 op=1 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN slapd[8201]: conn=1059 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text= slapd[8201]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT (32) No such object slapd[8201]: do_syncrep2: rid=000 (32) No such object slapd[8201]: conn=1059 op=2 UNBIND I've double-checked the configuration on the provider and if I revert the configuration on server B so that it consumes from server A, it all works again. Have I broken a fundamental rule? If I have, how can I fix it? If I haven't, what have I done wrong? Thanks. Philip

3 3

Found bug in GET_BOTH_RANGE
by Alain 04 Dec '13

04 Dec '13

I found a bug where the data was not updated in a call to cursor get with GET_BOTH_RANGE Here is what I did to fix it, but not 100% sure it covers everything correctly: rc = mc->mc_dbx->md_dcmp(data, &d2); if (rc) { if (op == MDB_GET_BOTH || rc > 0) return MDB_NOTFOUND; data->mv_data = d2.mv_data; //added data->mv_size = d2.mv_size; //added rc = 0; } Please confirm. Thanks Alain

1 0

2.4.26 : too many open files
by Aaron Bennett 04 Dec '13

04 Dec '13

Hi, I just ran into this yesterday on CentOS 6 / OpenLdap 2.4.36, my own build against bdb 5.1.29 and OpenSSL. Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): /var/lib/ldap/log.0000032796: log file unreadable: Too many open files Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): PANIC: Too many open files Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): PANIC: fatal region error detected; run recovery Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): PANIC: fatal region error detected; run recovery Dec 2 16:55:40 animal slapd[13735]: null_callback : error code 0x50 I never did anything to change the default process limit, looks like it's set to 1024 in /proc/$(pidof slapd)/limits. Is there anything I can do short of an automatic restart to prevent that from cropping up again? I have an MMR via Syncrepl setup with nothing too complicated; can't think of any reason offhand that slapd would need to have more than 1024 files open. Best, Aaron --- Aaron Bennett Manager of Systems Administration Clark University ITS W:508.793.7315

5 5

LDAP issue with SASL 2.1.26
by Sergey Emantayev 04 Dec '13

04 Dec '13

Hello, We successfully use OpenLDAP C SDK 2.4.36 integrated with Cyrus-SASL 2.1.23. Recently we have upgraded Cyrus-SASL to 2.1.26 and encountering the next issue. LDAP search consistently fails. We analyzed this issue and found the following behavior. When we use OpenLDAP with Cyrus-SASL 2.1.23 the LDAP Message Search Request payload is wrapped in GSS-API payload. When we use OpenLDAP with Cyrus-SASL 2.1.26 the LDAP Message Search Request payload is not wrapped in GSS-API payload at all. LDAP Search Request looks like clear text LDAP Search Request and not like LDAP SASL Search Request. In both cases - with Cyrus-SASL 2.1.23 and with Cyrus-SASL 2.1.26 – LDAP SASL Bind succeeds and LDAP SASL bindResponse looks identical with Cyrus-SASL 2.1.23 and with Cyrus-SASL 2.1.26. On the SASL support mail list I was suggested to setup minssf parameter. We have double checked that it's set correctly (=1). Please advise how to troubleshoot the issue. Thanks & Regards, Sergey

1 0

Memory leak question
by Markus Moeller 03 Dec '13

03 Dec '13

Hi I am using openldap 2.2.4.33 with cyrus-sasl 2.1.25 to do a sasl bind and get the following valgrind leak message. Looking through the source it seems to be a variable only used inside the openldap library and not related to what I provide to ldap_sasl_interactive_bind_s. ==14039== 34 (32 direct, 2 indirect) bytes in 2 blocks are definitely lost in loss record 561 of 666 ==14039== at 0x4C2C27B: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==14039== by 0x558E764: ber_memalloc_x (memory.c:228) ==14039== by 0x558A8B7: ber_get_stringal (decode.c:582) ==14039== by 0x558AFF5: ber_scanf (decode.c:806) ==14039== by 0x535535D: ldap_parse_sasl_bind_result (sasl.c:327) ==14039== by 0x5351FE1: ldap_int_sasl_bind (cyrus.c:551) ==14039== by 0x5355810: ldap_sasl_interactive_bind (sasl.c:474) ==14039== by 0x5355A0C: ldap_sasl_interactive_bind_s (sasl.c:511) ==14039== by 0x44DDC9: tool_sasl_bind (ldap.c:2338) Is that a real memory leak or is it something I did wrong ? Thank you Markus

3 4

Ldap simple bind problems on slaves during network outage
by Christian Kratzer 03 Dec '13

03 Dec '13

Hi, we are currently chasing a strange issue at a customers site where the ldap slaves become unresponsive when network connectivity to master ldaps and dns servers is lost. They have a setup of two masters and two slaves at separate sites. There is a load balancer sitting in front of the slaves that performs regular health checks consisting of binds followed by a search of their binddn. During regular operations the load balancers health checks look as follows [1] Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 fd=36 ACCEPT from IP=192.0.2.189:33852 (IP=192.0.2.129:389) Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=0 BIND dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" method=128 Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=0 BIND dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" mech=SIMPLE ssf=0 Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=0 RESULT tag=97 err=0 text= Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=1 SRCH base="ou=system,dc=example,dc=org" scope=1 deref=0 filter="(cn=keepalive-check-lb)" Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=1 ENTRY dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 op=2 UNBIND Dec 2 14:38:05 ldap slapd[57585]: connection_closing: readying conn=3924716 sd=36 for close Dec 2 14:38:05 ldap slapd[57585]: connection_resched: attempting closing conn=3924716 sd=36 Dec 2 14:38:05 ldap slapd[57585]: conn=3924716 fd=36 closed When they experience a network outage separating the slaves from the masters and the dns servers the load balancers are not able to bind the slaves: Dec 2 14:38:50 ldap slapd[57585]: conn=3924725 fd=44 ACCEPT from IP=192.0.2.188:35761 (IP=192.0.2.129:389) Dec 2 14:38:50 ldap slapd[57585]: connection_closing: readying conn=3924725 sd=44 for close Dec 2 14:38:50 ldap slapd[57585]: connection_close: deferring conn=3924725 sd=44 Dec 2 14:38:50 ldap slapd[57585]: conn=3924725 op=0 BIND dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" method=128 Dec 2 14:38:50 ldap slapd[57585]: conn=3924725 op=0 BIND dn="cn=keepalive-check-lb,ou=system,dc=example,dc=org" mech=SIMPLE ssf=0 Dec 2 14:38:50 ldap slapd[57585]: connection_resched: attempting closing conn=3924725 sd=44 Dec 2 14:38:50 ldap slapd[57585]: conn=3924725 fd=44 closed (connection lost) We have not been able to reproduce this problem in a lab setup which is supposed to be identical to the production setup. It does not seem to be related to the servers not being able to perform reverse mapping on the client ips. We run a mixture of 2.4.35 and 2.4.38 on CentOS 6.4. In the lab the slaves are able to perform queries just fine without connectivity to the masters or to their dns servers. The servers are currently running with following loglevel: dn: cn=config olcLogLevel: Conns olcLogLevel: Stats olcLogLevel: Stats2 olcLogLevel: Sync It seems we only get to the point where the bind credentials are parsed after which the connection is closed. This could of course be a problem with the load balancer prematurely closing the connection. I am trying to eliminate any causes in the ldap servers. Any ideas on how to debug this or where we could look. Greetings Christian [1] dns and ips obfuscated to protect the customer -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

2 2

Getting internal error, index points to a 00 page!?
by Alain 02 Dec '13

02 Dec '13

Hi, I converted an application from BDB to LMDB (using Java/JNI) and now I'm getting this error when doing an mdb_cursor_get with SET. In debugging, at that point mp is empty: mp = 0x0000000015ddb000 {mp_p={p_pgno=0 p_next=0x0000000000000000 } mp_pad=0 mp_flags=0 ...} The code where this happens is called many times before without issue, so I'm at a lost to explain what is going on. I'm including the debug output from the session. If anybody can point me in the right direction, I will do whatever tests or debugging is needed. BTW, lines numbers might be a bit off as I needed to make minor changes to run under MS VS at line 329, added code for lack of support for __func__: #ifdef _MSC_VER //MS C++ doesn't support __func__ # define DPRINTF0(fmt, ...) \ fprintf(stderr, "%s:%d " fmt "\n", __FUNCTION__, __LINE__, __VA_ARGS__) #else # define DPRINTF0(fmt, ...) \ fprintf(stderr, "%s:%d " fmt "\n", __func__, __LINE__, __VA_ARGS__) #endif Thanks Alain

2 2

Unable to add umlaut character dn to the openLDAP 2.4.32
by pramod kulkarni 29 Nov '13

29 Nov '13

Hi , I am having trouble in adding user with dn having umlaut characters using ldapmodify tool,It is giving invalid syntax what I need to do ? please help dn:uid=Röichard,ou=newUsers,dc=cricbox,dc=in ldap_add: Invalid DN syntax (34) additional info: invalid DN Regards, pk

3 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