openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

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

OLC configuration
by Jacques Foucry 28 Nov '13

28 Nov '13

Hello folks, I think I can use and manage a small LDAP. I can configure it but... with the old slapd.conf method. I need to configue a new one and it's time for me to understand the OLC configuration way. Did you have a good tuto (in french?) to help to help me? The official docs are to hard for me. Thanks in advance, Jacques Foucry -- Jacques Foucry *NOVΛSPARKS * IT Manager Tel : +33 (0)1 42 68 12 61 jacques.foucry(a)novasparks.com

2 1

p12 files for user-auth in slapd.conf question
by lux-integ 28 Nov '13

28 Nov '13

Greetings, I am a complete beginner leaning to use openldap. I read through a few of the manuals online. I am finding the access-control manual ( http://www.openldap.org/doc/admin24/access-control.html ) the hardest to understand. I would like to know if it is possible to authenticate users using p12 (pkcs12 certificates/key pair ) and IF SO what would be a) the standard shemas to be included in slapd.conf to make this possible ? , b) the entry for olcAccess ( in slapd.conf) for users to be authenticared via their p12 files ? , b) the location and storage method in the database for these .p12 files ? or IF NOT SO what is the recommended equivalent to p12 files and how would they be deployed.? thanks in advance sincerely luxInteg

2 1

OpenLDAP with ppolicy and SSSD configuration question.
by Viviano, Brad 28 Nov '13

28 Nov '13

Hello, I've searched the archives of this list, the web as best I can, and have this same question asked to the sssd-devel mailing list and can not seem to find an answer this my question. I have a RHEL 6.4 server with OpenLDAP 2.4.23-32.el6_4.1 and sssd 1.9.2-129.el6, both installed as standard RPM's from Redhat. I have ppolicy configured in slapd and on another RHEL6.4 system have sssd setup as a client. Everything works fine with password expires, grace periods, etc and sssd, if the user has to enter their password. But, if the user is using an SSH public key, setting the account as locked or the password is expired still allows them to log in. I can't seem to find a good solution that forces the user to change their password before they can login. The specifics are. sshd_config is configured to use PAM. My pam.d auth config is standard for RHEL6 which is: auth required pam_env.so auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so I've confirmed that when a user logs in from ssh with both password and ssh keys, they are going through the PAM sss.so just fine, by turning up the debugging levels and watching the logs. I've read everything I can find on sssd and it appears that for all cases of LDAP, sssd wants a single true/false value along the lines of nsAccountLocked. I can't find anything in ppolicy that sets true/false for account locked like other LDAP implementations do, all ppolicy seems to provide is pwdAccountLockedTime. While the issue seems more like a limitation on sssd's side, I thought I'd ask on this list to see if anyone has been able to come up with a solution or if there is something in ppolicy I am missing for a true/false on, is DN=X locked or not. Thanks, -Brad Viviano =================================================== Brad Viviano High Performance Computing & Scientific Visualization Lockheed Martin, Supporting the EPA Research Triangle Park, NC 919-541-2696 HSCSS Task Order Lead - Ravi Nair 919-541-5467 - Nair.Ravi(a)epa.gov High Performance Computing Subtask Lead - Durward Jones 919-541-5043 - Jones.Durward(a)epa.gov Environmental Modeling and Visualization Lead - Heidi Paulsen 919-541-1834 - Paulsen.Heidi(a)epa.gov

7 24

Q: monitoring attributes
by Ulrich Windl 28 Nov '13

28 Nov '13

Hi! I found out why I never was successful with cn=monitor: By default '*' attributes show almost nothing; you'll have to use '+' attributes (in my version at least). I'm not very happy with the decision, because you'll get the truely operational attributes also. If the whole subtree cn=Monitor is invisible in naming contexts, I see little reason to hide the "normal" attributes as operational in the whole subtree. Seeing those operational atributes, I noticed that "creatorsName" and "modifiersName" are both present but have an empty value. That doesn't look very nice, especially as createTimestamp and modifyTimestamp do have proper values. Using monitoredObject for all monitored values gives a unique interface, but having all possible results in monitoredInfo is not very usable, especially if there's no description. For example (some attributes removed for brevity): --- dn: cn=Uptime,cn=Time,cn=Monitor structuralObjectClass: monitoredObject monitoredInfo: 153543 hasSubordinates: FALSE --- It's not clear (denying the obvious) what the units of uptime are: seconds, minutes, etc. It seems to me that "monitoredType" or "monitoredInfoType" and "monitoredUnit" (for measurable infos) are missing. Shouldn't "monitorCounter" be named "monitoredCounter" to use the same pattern as "monitoredInfo"? I could not find the schema for the monitoring objects in any file. Can I retrieve a readable schema from openLDAP? The other thing is that I'm not too happy with are spaces in RDNs, like " cn=Connection 2111,cn=Connections,cn=Monitor", or "cn=Database 2,cn=Databases,cn=Monitor". I'd prefer are more common pattern for IDs like "Connection-2111" or "Connection_2111". Also: is "cn=Connection 0,cn=Connections,cn=Monitor" a bug? I see it twice: --- dn: cn=Connection 0,cn=Connections,cn=Monitor structuralObjectClass: monitorConnection (...) monitorConnectionNumber: 0 monitorConnectionProtocol: 0 monitorConnectionOpsReceived: 0 monitorConnectionOpsExecuting: 0 monitorConnectionOpsPending: 0 monitorConnectionOpsCompleted: 0 monitorConnectionGet: 0 monitorConnectionRead: 0 monitorConnectionWrite: 0 monitorConnectionMask: L monitorConnectionListener: monitorConnectionPeerDomain: unknown monitorConnectionPeerAddress: unknown monitorConnectionLocalAddress: monitorConnectionStartTime: 19700101000000Z monitorConnectionActivityTime: 19700101000000Z (...) --- Regards, Ulrich

4 10

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical