openldap-technical December 2011

openldap-technical@openldap.org

88 participants
101 discussions

slapd hanging - meta backend - Solaris 10
by Lincoln Souzek 05 Dec '11

05 Dec '11

Hello, I've seen a couple of instances where slapd becomes unresponsive, apparently because the threads are waiting on a backend meta DB. We're running slapd 2.4.23 on Solaris 10 (update 11/06). We have 128 threads configured and when I attach with truss, I see 130 allocated, most of which look like this: /53: lwp_park(0x00000000, 0) (sleeping...) When I run pstack against the PID, the stack for almost all of the threads looks like one of the two threads below, both of which are somewhere within meta_back_search: ----------------- lwp# 20 / thread# 20 -------------------- fee40408 lwp_park (0, 0, 0) 00140e64 ldap_build_search_req (110f0c0, 599eb90, 2, 79db010, 79db0a0, 0) + 2c 001412bc ldap_pvt_search (110f0c0, 599eb90, 2, 79db010, 79db0a0, 0) + d4 000cd494 ???????? (3f45d70, f4fffd58, f4fff478, f4fff294, 0, 2b822c0) 000cd7fc meta_back_search (3f45d70, f4fffd58, 2, 2, 24d400, 0) + 1e0 000a0928 ???????? (3f45d70, f4fffd58, f4fff8e0, 28ff20, 2ac1b8, 14) 000a12dc ???????? (f4fff8e0, f4fffd58, 2, 2, 24d400, 28ff20) 000a3950 overlay_op_walk (8000, f4fffd58, 8000, 28fe18, 28ff20, 818) + 4c 000a3ae4 ???????? (3f45d70, f4fffd58, 2, 1e6000, a3ba0, 28fe18) 00041e08 fe_op_search (3f45d70, f4fffd58, 3f45e70, f4fffad8, 1ee5f8, 1ee6f0) + 3f8 00041528 do_search (3f45d70, f4fffd58, fee6cbc0, 1e6000, 16ec00, f4fffad8) + 590 0003f8e4 ???????? (f4fffe08, 3f45d70, fee6cbc0, fe2d4400, 2683c8, 0) 0013ca30 ???????? (2683b8, f5000000, 0, 0, 13c8d4, 1) fee40368 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 21 / thread# 21 -------------------- fee40408 lwp_park (0, 0, 0) 0013e5c8 ldap_result (10ea3b0, 43e, 2, f47ff488, f47ff290, 0) + 3c 000cddf0 meta_back_search (53fe5b8, f47ffd58, 2, 2, 0, 1) + 7d4 000a0928 ???????? (53fe5b8, f47ffd58, f47ff8e0, 28ff20, 2ac1b8, 14) 000a12dc ???????? (f47ff8e0, f47ffd58, 2, 2, 24d400, 28ff20) 000a3950 overlay_op_walk (8000, f47ffd58, 8000, 28fe18, 28ff20, 818) + 4c 000a3ae4 ???????? (53fe5b8, f47ffd58, 2, 1e6000, a3ba0, 28fe18) 00041e08 fe_op_search (53fe5b8, f47ffd58, 53fe6b8, f47ffad8, 1ee5f8, 1ee6f0) + 3f8 00041528 do_search (53fe5b8, f47ffd58, fee6cbc0, 1e6000, 16ec00, f47ffad8) + 590 0003f8e4 ???????? (f47ffe08, 53fe5b8, fee6cbc0, fe2d4800, 2683c8, 0) 0013ca30 ???????? (2683b8, f4800000, 0, 0, 13c8d4, 1) fee40368 _lwp_start (0, 0, 0, 0, 0, 0) I took a core dump while the process was running but I'm not really sure how to proceed from here. Is there any way to get more information on what was happening with these threads at the time? In either case, is this a situation that should be handled with a general timeout directive? We currently only have a network-timeout and a bind timeout specified: network-timeout 3 timeout bind=3 Thanks, Lincoln

2 1

ldap_add_s - mods.mod_values empty
by Sean Ryan 05 Dec '11

05 Dec '11

Hello, Firstly, I hope this is the correct list Relevant versions: O/S: Debian Etch (server) - Debian Lenny (client) Slapd : OpenLDAP: slapd 2.3.30 Client libs : libldap2 (debian) I'm seeing some problems using the ldap_add_s function call - For some reason the mods.mod_values array *appears* to be empty - slapd reports that it's missing values for the attribute type and wireshark confirms that to be the case (partial extract below). addRequest entry: macaddress=002145ccfadf,dc=nodomain attributes: 2 items Item macaddress type: macaddress vals: 0 items The below is the partial source code involved. Code : char * vals[LdapDefaults::MAX_MODS][2]; ACE_DEBUG((LM_DEBUG, "(%t) Add Entry %s:%s %D \n", tempName, tempValue)); vals[loopcount][0] = new char [LdapDefaults::MAX_OPTION_LEN]; vals[loopcount][1] = 0; opTypes[loopcount] = new char [LdapDefaults::MAX_OPTION_LEN]; mod[loopcount].mod_op = 0; strcpy (opTypes[loopcount], tempName); strcpy (vals[loopcount][0], tempValue); mod[loopcount].mod_type = new char [LdapDefaults::MAX_OPTION_LEN]; strcpy (mod[loopcount].mod_type ,opTypes[loopcount]); mod[loopcount].mod_values = vals[loopcount]; loopcount ++; ++ nvpBegin ; for (int counter = 0 ; counter < loopcount ; counter ++) { mods[counter] = &mod[counter]; mods[counter]->mod_values = sn_values; ADA_DEBUG ((LM_DEBUG, "Value == %s\n", mods[counter]->mod_values[0])); } mods[loopcount] = 0; errCode = ldap_add_s(pld, tempDn , mods) ; addRequest entry: macaddress=002145ccfadf,dc=nodomain attributes: 2 items Item macaddress type: macaddress vals: 0 items There are a couple of curious things here. 1. Assigning mod->mod_values to a statically declared array ( char *sn_values[] = { "Jensen", NULL }; mods[counter]->mod_values = sn_values;) does not change the behavior 2. Debugging the contents of mods[i]->mod_values[0] immediately before and after the call to ldap_add_s shows that the correct values as being present in the structure. 3. Building a standalone test application and directly linking my library produced works as expected. Any thoughts on how to debug this further much appreciated. Thanks Sean

1 0

Re: LDAP query to Active Directory backend
by Khaled Blah 05 Dec '11

05 Dec '11

Thanks for your reply, Michael! I should have mentioned that I have tested this code with an OpenLDAP server (2.4.23) and a Lotus Notes server (ver. 8) and both of them return UTF-8 encoded data (like I expected it). The only difference are the parameters which I use to start the query on these backends (bind DN, filter, etc...). Regards, Khaled

1 1

rootDSE
by W.Siebert＠t-systems.com 04 Dec '11

04 Dec '11

Hello, is it posible to add an attribute to rootDSE? regards Waldemar

2 1

Re: RWM
by masarati＠aero.polimi.it 04 Dec '11

04 Dec '11

> Hello, > > the slapd-meta backend (OpenLDAP version: 2.4.26 and 2.4.28) has an own > rewriting module. If I want to use rewriting and remaping, do I have to > install rwm-overlay although I have meta installed? not sure what you mean by "installed"; if you mean "loaded" when built as run-time loadable modules, then the answer is "no". The two modules (back-meta and slapo-rwm) are orthogonal. p.

1 0

extract response controls after ldap_sasl_interactive_bind_s()
by Michael Ströder 04 Dec '11

04 Dec '11

HI! Disclaimer: I'm not a C programmer. I'd like to evaluate response controls (e.g. ppolicy) also when doing a SASL bind. I'm using python-ldap which in turn uses OpenLDAP C API's function ldap_sasl_interactive_bind_s(). But currently there's no way to extract the server's response controls. The server I'm testing with is returning the ppolicy response control and others. I looked at clients/tools/common.c but it seems to me it also uses ldap_sasl_interactive_bind_s() and no response controls are extracted. Do I have to use ldap_get_option(ld,LDAP_OPT_SERVER_CONTROLS) separately? Does that work? Ciao, Michael.

2 5

RWM
by W.Siebert＠t-systems.com 03 Dec '11

03 Dec '11

Hello, the slapd-meta backend (OpenLDAP version: 2.4.26 and 2.4.28) has an own rewriting module. If I want to use rewriting and remaping, do I have to install rwm-overlay although I have meta installed? My predecessor recently left the company. How can I check which backends and overlays are already installed? Kind regards Waldemar

1 0

Re: OpenLDAP syncrepl woes
by Jeffrey Crawford 02 Dec '11

02 Dec '11

Ok will give that a try stay tuned. Jeffrey On Thu, Dec 1, 2011 at 11:39 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, December 01, 2011 9:38 AM -0800 Jeffrey Crawford > <jeffreyc(a)ucsc.edu> wrote: > >>> Humm that didn't seem to work. I'm rebuilding so I'll give that another >>> try. >> >> >> Finally got to do another test. I tested by changing the permissions >> of the replication account permissions and tried restarting with slapd >> -c rid=<number> where the number is the id of the rid= definition in >> the olcSyncrepl configuration. It didn't seem to work (Note the >> permission changes were just what attributes the account could see) >> >> Just for grins I also tried rid=0 and rid by itself. None seemed to >> work. I'm guessing I'm just doing something wrong but not sure what it >> is. > > > Well, rid can't be zero. rid has to be the rid you selected in the replica > for that master connection. Looking at test058, it looks like the correct > syntax is to use -c rid=<rid>,csn=0 > > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Failure while importing an exported ldif file
by Axel Birndt 02 Dec '11

02 Dec '11

Hi @All, now while my ldapserver is working on my testmachine, i'am trying to import my ldif files. I read the thread http://www.openldap.org/lists/openldap-software/200711/msg00069.html but the import isn't working for me. abirndt@lvps83-169-33-218:~/openldap_2axels-company$ sudo slapadd -F /etc/ldap/slapd.d -n 0 -l dc_2axels-company_dc_de_export.ldif slapadd: line 1: database (cn=config) not configured to hold "dc=2axels-company,dc=de" slapadd: line 1: database (cn=config) not configured to hold "dc=2axels-company,dc=de" abirndt@lvps83-169-33-218:~/openldap_2axels-company$ sudo slapadd -F /etc/ldap/slapd.d -n 0 -l cn_config_export.ldif I created my backupfiles with the following commands: sudo slapcat -b cn=config -F /etc/ldap/slapd.d/ >cn_Config_export.ldif sudo slapcat -b dc=2axels-company,dc=de -F /etc/ldap/slapd.d/ >dc_2axels-company_dc_de_export.ldif I'am also looking in google for solving this, but in my mind i haven't the right keywords... Could anyone give me a hint or a link for reading, how to import the created ldif files from above to a new ldap-server? -- Gruß Axel ------------------------------

2 4

Re: memberof overlay deployment
by Bryce Powell 02 Dec '11

02 Dec '11

Hi, I tried the method suggested by Marco to populate memberOf attributes of existing entries: >> How would you recommend getting memberof values populated in the existing directory? > If you can afford a sequence of: > stop -> slapcat -> drop db -> slapadd > Everything gets populated as desired. I tried this and the directory was restored minus the memberOf attributes. I used the following commands on version 2.4.11 (yes, I know I have to upgrade ...) : /usr/local/sbin/slapcat -l data_20111201.ldif (..drop db..) /usr/local/sbin/slapadd -c -v -l data_20111201.ldif 'Manual' group membership updates do result in the memberOf attributes getting updated, so I know the overlay is working. Thanks, Bryce Powell

5 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2011