July 2011 - openldap-technical

by Venish Khant

Hi all I am using cpan Net::LDAP module to access LDAP entries. I want to search LDAP entries using Net::LDAP search method. When I do search, I want some limited number of entries from search result, for this(searching) process I am using Net::LDAP::Control::VLV module. But I get error on VLV response control. Please, any one have idea about this error. * Error:* Died at vlv.pl line 50, This is my example. I changed the font style of line 50 #!/usr/bin/perl -w use Net::LDAP; use Net::LDAP::Control::VLV; use Net::LDAP::Constant qw( LDAP_CONTROL_VLVRESPONSE ); use Net::LDAP::Control::Sort; sub procentry { my ( $mesg, $entry) = @_; # Return if there is no entry to process if ( !defined($entry) ) { return; } print "dn: " . $entry->dn() . "\n"; @attrs = $entry->attributes(); foreach $attr (@attrs) { #printf("\t%s: %s\n", $attr, $entry->get_value($attr)); $attrvalue = $entry->get_value($attr,asref=>1); #print $attr.":". $entry->get_value($attr)."\n"; foreach $value(@$attrvalue) { print "$attr: $value\n"; } } $mesg->pop_entry; print "\n"; } $ldap = Net::LDAP->new( "localhost" ); # Get the first 20 entries $vlv = Net::LDAP::Control::VLV->new( before => 0, # No entries from before target entry after => 19, # 19 entries after target entry content => 0, # List size unknown offset => 1, # Target entry is the first ); my $sort = Net::LDAP::Control::Sort->new( order => 'cn' ); @args = ( base => "dc=example,dc=co,dc=in", scope => "subtree", filter => "(objectClass=inetOrgPerson)", callback => \&procentry, # Call this sub for each entry control => [ $sort, $vlv ], ); $mesg = $ldap->search( @args ); # Get VLV response control *($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die;* $vlv->response( $resp ); # Set the control to get the last 20 entries $vlv->end; $mesg = $ldap->search( @args ); # Get VLV response control ($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die; $vlv->response( $resp ); # Now get the previous page $vlv->scroll_page( -1 ); $mesg = $ldap->search( @args ); # Get VLV response control ($resp) = $mes # Now page with first entry starting with "B" in the middle $vlv->before(9); # Change page to show 9 before $vlv->after(10); # Change page to show 10 after $vlv->assert("B"); # assert "B" $mesg = $ldap->search( @args );g->control( LDAP_CONTROL_VLVRESPONSE ) or die; $vlv->response( $resp ); -- Venish Khant www.deeproot.co.in

7 years

4
11
0 / 0

Loading LDAP schema files into cn=config

by Mark Cave-Ayland

Hi all, Having started to look at the changes required to migrate from a slapd.conf setup to a cn=config setup, one of things I'm struggling with is how to load new LDAP schemas into cn=config. I've seen the guides similar to this one here: http://blogger.ziesemer.com/2011/01/ldap-authentication-for-samba.html which suggest hacking together a temporary slapd.conf file containing just the include directives, run slaptest, and then hack the output so that it can be loaded into cn=config using ldapadd. Given that this is a quite a common task, is there no way of generating the LDIF directly to be loaded into the directory, e.g. slaptest -s /etc/ldap/schema/myschema.schema [ -n <schemanum> ] -l myschema.ldif Or then again, is this functionality already there but I just haven't managed to find it yet? I'd be grateful if someone could point me in the right direction and/or give me some hints as to the best way to manage schemas in the new regime. Many thanks, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

11 years, 7 months

13
49
0 / 0

Authenticate Mac OS X users against OpenLDAP on Debian

by Mi

We added a Mac to our network, and I would like the network users to be able to login with their existing credentials on our Debian openLDAP server. I configured the LDAP access on the Mac, and it can indeed see the users and groups from the openldap server. But when I try to login after clicking "Other...", the login window shakes around, and nothing happens. The server logs show the connection from the Mac and it's searches ( http://pastebin.com/MB2JswAa). (Logging is configured with Parse, Stats, Stats2, Sync. Is there something else I should add to logging that may be useful?) On the Mac, I didn't find anything looking helpful in the logs (http://pastebin.com/yRreFQrJ), but maybe I don't know what to look for. I found many instructions on the Internet which concentrate on mounting user homes from the server over NFS. This is NOT what we want. Users would be authenticated with openldap, but have their homes locally on the Mac, like normal users. I also saw many mentions of adding the apple schema, and I have done that. But maybe I now need to actually use parts of that schema in the user records? Thanks for any help...

11 years, 8 months

3
3
0 / 0

OpenLDAP freezes and doesn't respond

by Cyril GROSJEAN

I randomly notice my OpenLDAP server freezes, and I can't udnerstand why. I have a few LDAP clients (ldapsearch, a legacy Java app. and ApacheDirectoryStudio), running from different systems, either locally on the OpenLDAP server, or on another OpenLDAP server, or on a remote workstation, and none manages to get an answer from OpenLDAP. The connection is established but each client gets stuck waiting for any result. The last time, it occured only a few minutes after the OpenLDAP daemon was restarted, under very low load. I use OpenLDAP 2.4.23, over Red Hat Enterprise Linux Server release 5.4 (Tikanga), Kernel version 2.6.18-164.el5, amd64 architecture over VMWare. I also use BDB 4.8.30, and OpenLDAP's been compiled with the following options: ./configure --prefix=/opt/openldap-2.4.23 --enable-dynamic=yes --enable-dynlist=yes --enable-memberof=yes --enable-ppolicy=yes --enable-accesslog=yes --enable-sssvlv=yes I noticed only 74 established connections on port 389 (according to netstat) when the freeze occurs. The OpenLDAP server is set in syncrepl mirror mode replication, and the other OpenLDAP server (only used as a hot stand-by) works fine (but doesn't receive any load) I only have the following lines at the end of the OpenLDAP log: (IP @ and suffixes voluntarily hidden) Jul 12 10:19:32 dev-ldap1 slapd[28525]: conn=3377 fd=65 ACCEPT from IP=.......:3820 (IP=0.0.0.0:389) Jul 12 10:19:32 dev-ldap1 slapd[28525]: conn=3377 op=0 BIND dn="employeeNumber=02071,ou= people,dc=...." method=128 Jul 12 10:20:05 dev-ldap1 slapd[28525]: connection_input: conn=3377 deferring operation: binding Jul 12 10:20:07 dev-ldap1 slapd[28525]: conn=3378 fd=66 ACCEPT from IP=......:3823 (IP=0.0.0.0:389) The stack of the slapd process shows the following: # *pstack 28525* Thread 18 (Thread 0x408e4940 (LWP 28529)): #0 0x0000003a53ad4018 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000041d76e in ldap_pvt_sasl_mutex_dispose () #2 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #3 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 17 (Thread 0x41360940 (LWP 28530)): #0 0x0000003a5460ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002ba988b6cdd2 in __db_pthread_mutex_lock () #2 0x00002ba988b6c426 in __db_tas_mutex_lock () #3 0x00002ba988bfcb49 in __lock_get_internal () #4 0x00002ba988bfd2c2 in __lock_get_pp () #5 0x00000000004af398 in ldap_pvt_sasl_mutex_dispose () #6 0x00000000004b04ca in ldap_pvt_sasl_mutex_dispose () #7 0x0000000000492a80 in ldap_pvt_sasl_mutex_dispose () #8 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #9 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #10 0x0000000000422736 in ldap_pvt_sasl_mutex_dispose () #11 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #12 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #13 0x0000000000422ec7 in ldap_pvt_sasl_mutex_dispose () #14 0x00000000004205a5 in ldap_pvt_sasl_mutex_dispose () #15 0x0000000000420b7f in ldap_pvt_sasl_mutex_dispose () #16 0x00002ba9886e08a8 in ldap_int_thread_pool_wrapper () #17 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #18 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 16 (Thread 0x41b61940 (LWP 28531)): #0 0x0000003a5460ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002ba988b6cdd2 in __db_pthread_mutex_lock () #2 0x00002ba988b6c426 in __db_tas_mutex_lock () #3 0x00002ba988bfcb49 in __lock_get_internal () #4 0x00002ba988bfd2c2 in __lock_get_pp () #5 0x00000000004af398 in ldap_pvt_sasl_mutex_dispose () #6 0x00000000004b04ca in ldap_pvt_sasl_mutex_dispose () #7 0x00000000004b4183 in ldap_pvt_sasl_mutex_dispose () #8 0x00000000004b802e in ldap_pvt_sasl_mutex_dispose () #9 0x0000000000481a7a in ldap_pvt_sasl_mutex_dispose () #10 0x0000000000482547 in ldap_pvt_sasl_mutex_dispose () #11 0x00000000004decab in ldap_pvt_sasl_mutex_dispose () #12 0x0000000000481b4a in ldap_pvt_sasl_mutex_dispose () #13 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #14 0x000000000043be3e in ldap_pvt_sasl_mutex_dispose () #15 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #16 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #17 0x000000000043c83f in ldap_pvt_sasl_mutex_dispose () #18 0x00000000004205a5 in ldap_pvt_sasl_mutex_dispose () #19 0x0000000000420b7f in ldap_pvt_sasl_mutex_dispose () #20 0x00002ba9886e08a8 in ldap_int_thread_pool_wrapper () #21 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #22 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 15 (Thread 0x42362940 (LWP 28532)): #0 0x0000003a5460ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002ba988b6cdd2 in __db_pthread_mutex_lock () #2 0x00002ba988b6c426 in __db_tas_mutex_lock () #3 0x00002ba988bfcb49 in __lock_get_internal () #4 0x00002ba988bfd2c2 in __lock_get_pp () #5 0x00000000004af398 in ldap_pvt_sasl_mutex_dispose () #6 0x00000000004b04ca in ldap_pvt_sasl_mutex_dispose () #7 0x00000000004b4183 in ldap_pvt_sasl_mutex_dispose () #8 0x00000000004b802e in ldap_pvt_sasl_mutex_dispose () #9 0x0000000000481a7a in ldap_pvt_sasl_mutex_dispose () #10 0x0000000000482547 in ldap_pvt_sasl_mutex_dispose () #11 0x00000000004decab in ldap_pvt_sasl_mutex_dispose () #12 0x0000000000481b4a in ldap_pvt_sasl_mutex_dispose () #13 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #14 0x000000000043be3e in ldap_pvt_sasl_mutex_dispose () #15 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #16 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #17 0x000000000043c83f in ldap_pvt_sasl_mutex_dispose () #18 0x00000000004205a5 in ldap_pvt_sasl_mutex_dispose () #19 0x0000000000420b7f in ldap_pvt_sasl_mutex_dispose () #20 0x00002ba9886e08a8 in ldap_int_thread_pool_wrapper () #21 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #22 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 14 (Thread 0x42b63940 (LWP 28533)): #0 0x0000003a5460ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002ba988b6cdd2 in __db_pthread_mutex_lock () #2 0x00002ba988b6c426 in __db_tas_mutex_lock () #3 0x00002ba988bfcb49 in __lock_get_internal () #4 0x00002ba988bfd2c2 in __lock_get_pp () #5 0x00000000004af398 in ldap_pvt_sasl_mutex_dispose () #6 0x00000000004b04ca in ldap_pvt_sasl_mutex_dispose () #7 0x00000000004b4183 in ldap_pvt_sasl_mutex_dispose () #8 0x00000000004b802e in ldap_pvt_sasl_mutex_dispose () #9 0x0000000000481a7a in ldap_pvt_sasl_mutex_dispose () #10 0x0000000000482547 in ldap_pvt_sasl_mutex_dispose () #11 0x00000000004decab in ldap_pvt_sasl_mutex_dispose () #12 0x0000000000481b4a in ldap_pvt_sasl_mutex_dispose () #13 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #14 0x000000000043be3e in ldap_pvt_sasl_mutex_dispose () #15 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #16 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #17 0x000000000043c83f in ldap_pvt_sasl_mutex_dispose () #18 0x00000000004205a5 in ldap_pvt_sasl_mutex_dispose () #19 0x0000000000420b7f in ldap_pvt_sasl_mutex_dispose () #20 0x00002ba9886e08a8 in ldap_int_thread_pool_wrapper () #21 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #22 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 13 (Thread 0x43364940 (LWP 28534)): #0 0x0000003a5460ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002ba988b6cdd2 in __db_pthread_mutex_lock () #2 0x00002ba988b6c426 in __db_tas_mutex_lock () #3 0x00002ba988bfcb49 in __lock_get_internal () #4 0x00002ba988bfd2c2 in __lock_get_pp () #5 0x00000000004af398 in ldap_pvt_sasl_mutex_dispose () #6 0x00000000004b04ca in ldap_pvt_sasl_mutex_dispose () #7 0x00000000004b4183 in ldap_pvt_sasl_mutex_dispose () #8 0x00000000004b802e in ldap_pvt_sasl_mutex_dispose () #9 0x0000000000481a7a in ldap_pvt_sasl_mutex_dispose () #10 0x0000000000482547 in ldap_pvt_sasl_mutex_dispose () #11 0x00000000004decab in ldap_pvt_sasl_mutex_dispose () #12 0x0000000000481b4a in ldap_pvt_sasl_mutex_dispose () #13 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #14 0x000000000043be3e in ldap_pvt_sasl_mutex_dispose () #15 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #16 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #17 0x000000000043c83f in ldap_pvt_sasl_mutex_dispose () #18 0x00000000004205a5 in ldap_pvt_sasl_mutex_dispose () #19 0x0000000000420b7f in ldap_pvt_sasl_mutex_dispose () #20 0x00002ba9886e08a8 in ldap_int_thread_pool_wrapper () #21 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #22 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x43b65940 (LWP 28535)): #0 0x0000003a5460ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002ba988b6cdd2 in __db_pthread_mutex_lock () #2 0x00002ba988b6c426 in __db_tas_mutex_lock () #3 0x00002ba988bfcb49 in __lock_get_internal () #4 0x00002ba988bfd2c2 in __lock_get_pp () #5 0x00000000004af398 in ldap_pvt_sasl_mutex_dispose () #6 0x00000000004b04ca in ldap_pvt_sasl_mutex_dispose () #7 0x00000000004b4183 in ldap_pvt_sasl_mutex_dispose () #8 0x00000000004b802e in ldap_pvt_sasl_mutex_dispose () #9 0x0000000000481a7a in ldap_pvt_sasl_mutex_dispose () #10 0x0000000000482547 in ldap_pvt_sasl_mutex_dispose () #11 0x00000000004decab in ldap_pvt_sasl_mutex_dispose () #12 0x0000000000481b4a in ldap_pvt_sasl_mutex_dispose () #13 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #14 0x000000000043be3e in ldap_pvt_sasl_mutex_dispose () #15 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #16 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #17 0x000000000043c83f in ldap_pvt_sasl_mutex_dispose () #18 0x00000000004205a5 in ldap_pvt_sasl_mutex_dispose () #19 0x0000000000420b7f in ldap_pvt_sasl_mutex_dispose () #20 0x00002ba9886e08a8 in ldap_int_thread_pool_wrapper () #21 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #22 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 11 (Thread 0x44366940 (LWP 29755)): #0 0x0000003a5460ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002ba988b6cdd2 in __db_pthread_mutex_lock () #2 0x00002ba988b6c426 in __db_tas_mutex_lock () #3 0x00002ba988bfcb49 in __lock_get_internal () #4 0x00002ba988bfd2c2 in __lock_get_pp () #5 0x00000000004af398 in ldap_pvt_sasl_mutex_dispose () #6 0x00000000004b04ca in ldap_pvt_sasl_mutex_dispose () #7 0x0000000000492a80 in ldap_pvt_sasl_mutex_dispose () #8 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #9 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #10 0x0000000000422736 in ldap_pvt_sasl_mutex_dispose () #11 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #12 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #13 0x0000000000422ec7 in ldap_pvt_sasl_mutex_dispose () #14 0x00000000004205a5 in ldap_pvt_sasl_mutex_dispose () #15 0x0000000000420b7f in ldap_pvt_sasl_mutex_dispose () #16 0x00002ba9886e08a8 in ldap_int_thread_pool_wrapper () #17 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #18 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 10 (Thread 0x44b67940 (LWP 29756)): #0 0x0000003a5460ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002ba988b6cdd2 in __db_pthread_mutex_lock () #2 0x00002ba988b6c426 in __db_tas_mutex_lock () #3 0x00002ba988bfcb49 in __lock_get_internal () #4 0x00002ba988bfd2c2 in __lock_get_pp () #5 0x00000000004af398 in ldap_pvt_sasl_mutex_dispose () #6 0x00000000004b04ca in ldap_pvt_sasl_mutex_dispose () #7 0x00000000004b4183 in ldap_pvt_sasl_mutex_dispose () #8 0x00000000004b802e in ldap_pvt_sasl_mutex_dispose () #9 0x0000000000481a7a in ldap_pvt_sasl_mutex_dispose () #10 0x0000000000482547 in ldap_pvt_sasl_mutex_dispose () #11 0x00000000004decab in ldap_pvt_sasl_mutex_dispose () #12 0x0000000000481b4a in ldap_pvt_sasl_mutex_dispose () #13 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #14 0x000000000043be3e in ldap_pvt_sasl_mutex_dispose () #15 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #16 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #17 0x000000000043c83f in ldap_pvt_sasl_mutex_dispose () #18 0x00000000004205a5 in ldap_pvt_sasl_mutex_dispose () #19 0x0000000000420b7f in ldap_pvt_sasl_mutex_dispose () #20 0x00002ba9886e08a8 in ldap_int_thread_pool_wrapper () #21 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #22 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x45368940 (LWP 29757)): #0 0x0000003a5460ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002ba988b6cdd2 in __db_pthread_mutex_lock () #2 0x00002ba988b6c426 in __db_tas_mutex_lock () #3 0x00002ba988bfcb49 in __lock_get_internal () #4 0x00002ba988bfd2c2 in __lock_get_pp () #5 0x00000000004af398 in ldap_pvt_sasl_mutex_dispose () #6 0x00000000004b04ca in ldap_pvt_sasl_mutex_dispose () #7 0x0000000000492a80 in ldap_pvt_sasl_mutex_dispose () #8 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #9 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #10 0x0000000000422736 in ldap_pvt_sasl_mutex_dispose () #11 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #12 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #13 0x0000000000422ec7 in ldap_pvt_sasl_mutex_dispose () #14 0x00000000004205a5 in ldap_pvt_sasl_mutex_dispose () #15 0x0000000000420b7f in ldap_pvt_sasl_mutex_dispose () #16 0x00002ba9886e08a8 in ldap_int_thread_pool_wrapper () #17 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #18 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x45b69940 (LWP 29758)): #0 0x0000003a5460ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002ba988b6cdd2 in __db_pthread_mutex_lock () #2 0x00002ba988b6c426 in __db_tas_mutex_lock () #3 0x00002ba988bfcb49 in __lock_get_internal () #4 0x00002ba988bfd4ea in __lock_vec () #5 0x00002ba988bfe12b in __lock_vec_pp () #6 0x00000000004af514 in ldap_pvt_sasl_mutex_dispose () #7 0x00000000004af900 in ldap_pvt_sasl_mutex_dispose () #8 0x000000000048d323 in ldap_pvt_sasl_mutex_dispose () #9 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #10 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #11 0x00000000004de44d in ldap_pvt_sasl_mutex_dispose () #12 0x000000000042ee25 in ldap_pvt_sasl_mutex_dispose () #13 0x00000000004319c8 in ldap_pvt_sasl_mutex_dispose () #14 0x0000000000432749 in ldap_pvt_sasl_mutex_dispose () #15 0x00000000004ae91b in ldap_pvt_sasl_mutex_dispose () #16 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #17 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #18 0x000000000043be3e in ldap_pvt_sasl_mutex_dispose () #19 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #20 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #21 0x000000000043c83f in ldap_pvt_sasl_mutex_dispose () #22 0x00000000004205a5 in ldap_pvt_sasl_mutex_dispose () #23 0x0000000000420b7f in ldap_pvt_sasl_mutex_dispose () #24 0x00002ba9886e08a8 in ldap_int_thread_pool_wrapper () #25 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #26 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x4636a940 (LWP 29759)): #0 0x0000003a5460ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002ba988b6cdd2 in __db_pthread_mutex_lock () #2 0x00002ba988b6c426 in __db_tas_mutex_lock () #3 0x00002ba988bfcb49 in __lock_get_internal () #4 0x00002ba988bfd2c2 in __lock_get_pp () #5 0x00000000004af398 in ldap_pvt_sasl_mutex_dispose () #6 0x00000000004b04ca in ldap_pvt_sasl_mutex_dispose () #7 0x00000000004b4183 in ldap_pvt_sasl_mutex_dispose () #8 0x00000000004b802e in ldap_pvt_sasl_mutex_dispose () #9 0x0000000000481a7a in ldap_pvt_sasl_mutex_dispose () #10 0x0000000000482547 in ldap_pvt_sasl_mutex_dispose () #11 0x00000000004decab in ldap_pvt_sasl_mutex_dispose () #12 0x0000000000481b4a in ldap_pvt_sasl_mutex_dispose () #13 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #14 0x000000000043be3e in ldap_pvt_sasl_mutex_dispose () #15 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #16 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #17 0x000000000043c83f in ldap_pvt_sasl_mutex_dispose () #18 0x00000000004205a5 in ldap_pvt_sasl_mutex_dispose () #19 0x0000000000420b7f in ldap_pvt_sasl_mutex_dispose () #20 0x00002ba9886e08a8 in ldap_int_thread_pool_wrapper () #21 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #22 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x46b6b940 (LWP 29760)): #0 0x0000003a5460ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002ba9886df7fb in ldap_pvt_thread_rmutex_lock () #2 0x00000000004d4c74 in ldap_pvt_sasl_mutex_dispose () #3 0x0000000000481b4a in ldap_pvt_sasl_mutex_dispose () #4 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #5 0x00000000004de44d in ldap_pvt_sasl_mutex_dispose () #6 0x000000000042ee25 in ldap_pvt_sasl_mutex_dispose () #7 0x00000000004319c8 in ldap_pvt_sasl_mutex_dispose () #8 0x0000000000432749 in ldap_pvt_sasl_mutex_dispose () #9 0x00000000004ae91b in ldap_pvt_sasl_mutex_dispose () #10 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #11 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #12 0x000000000043be3e in ldap_pvt_sasl_mutex_dispose () #13 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #14 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #15 0x000000000043c83f in ldap_pvt_sasl_mutex_dispose () #16 0x00000000004205a5 in ldap_pvt_sasl_mutex_dispose () #17 0x0000000000420b7f in ldap_pvt_sasl_mutex_dispose () #18 0x00002ba9886e08a8 in ldap_int_thread_pool_wrapper () #19 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #20 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 5 (Thread 0x4736c940 (LWP 29761)): #0 0x0000003a5460ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002ba988b6cdd2 in __db_pthread_mutex_lock () #2 0x00002ba988b6c426 in __db_tas_mutex_lock () #3 0x00002ba988bfcb49 in __lock_get_internal () #4 0x00002ba988bfd2c2 in __lock_get_pp () #5 0x00000000004af398 in ldap_pvt_sasl_mutex_dispose () #6 0x00000000004b04ca in ldap_pvt_sasl_mutex_dispose () #7 0x00000000004b4183 in ldap_pvt_sasl_mutex_dispose () #8 0x00000000004b802e in ldap_pvt_sasl_mutex_dispose () #9 0x0000000000481a7a in ldap_pvt_sasl_mutex_dispose () #10 0x0000000000482547 in ldap_pvt_sasl_mutex_dispose () #11 0x00000000004decab in ldap_pvt_sasl_mutex_dispose () #12 0x0000000000481b4a in ldap_pvt_sasl_mutex_dispose () #13 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #14 0x000000000043be3e in ldap_pvt_sasl_mutex_dispose () #15 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #16 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #17 0x000000000043c83f in ldap_pvt_sasl_mutex_dispose () #18 0x00000000004205a5 in ldap_pvt_sasl_mutex_dispose () #19 0x0000000000420b7f in ldap_pvt_sasl_mutex_dispose () #20 0x00002ba9886e08a8 in ldap_int_thread_pool_wrapper () #21 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #22 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x47b6d940 (LWP 29762)): #0 0x0000003a5460ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002ba988b6cdd2 in __db_pthread_mutex_lock () #2 0x00002ba988b6c426 in __db_tas_mutex_lock () #3 0x00002ba988bfcb49 in __lock_get_internal () #4 0x00002ba988bfd2c2 in __lock_get_pp () #5 0x00000000004af398 in ldap_pvt_sasl_mutex_dispose () #6 0x00000000004b04ca in ldap_pvt_sasl_mutex_dispose () #7 0x00000000004b4183 in ldap_pvt_sasl_mutex_dispose () #8 0x00000000004b802e in ldap_pvt_sasl_mutex_dispose () #9 0x0000000000481a7a in ldap_pvt_sasl_mutex_dispose () #10 0x0000000000482547 in ldap_pvt_sasl_mutex_dispose () #11 0x00000000004decab in ldap_pvt_sasl_mutex_dispose () #12 0x0000000000481b4a in ldap_pvt_sasl_mutex_dispose () #13 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #14 0x000000000043be3e in ldap_pvt_sasl_mutex_dispose () #15 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #16 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #17 0x000000000043c83f in ldap_pvt_sasl_mutex_dispose () #18 0x00000000004205a5 in ldap_pvt_sasl_mutex_dispose () #19 0x0000000000420b7f in ldap_pvt_sasl_mutex_dispose () #20 0x00002ba9886e08a8 in ldap_int_thread_pool_wrapper () #21 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #22 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x4836e940 (LWP 29763)): #0 0x0000003a5460ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002ba988b6cdd2 in __db_pthread_mutex_lock () #2 0x00002ba988b6c426 in __db_tas_mutex_lock () #3 0x00002ba988bfcb49 in __lock_get_internal () #4 0x00002ba988bfd2c2 in __lock_get_pp () #5 0x00000000004af398 in ldap_pvt_sasl_mutex_dispose () #6 0x00000000004b04ca in ldap_pvt_sasl_mutex_dispose () #7 0x0000000000492a80 in ldap_pvt_sasl_mutex_dispose () #8 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #9 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #10 0x00000000004758a4 in ldap_pvt_sasl_mutex_dispose () #11 0x000000000047ce54 in ldap_pvt_sasl_mutex_dispose () #12 0x00000000004214d3 in ldap_pvt_sasl_mutex_dispose () #13 0x00002ba9886e08a8 in ldap_int_thread_pool_wrapper () #14 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #15 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x48b6f940 (LWP 29764)): #0 0x0000003a5460ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002ba988b6cdd2 in __db_pthread_mutex_lock () #2 0x00002ba988b6c426 in __db_tas_mutex_lock () #3 0x00002ba988bfcb49 in __lock_get_internal () #4 0x00002ba988bfd2c2 in __lock_get_pp () #5 0x00000000004af398 in ldap_pvt_sasl_mutex_dispose () #6 0x00000000004b04ca in ldap_pvt_sasl_mutex_dispose () #7 0x00000000004b4183 in ldap_pvt_sasl_mutex_dispose () #8 0x00000000004b802e in ldap_pvt_sasl_mutex_dispose () #9 0x0000000000481a7a in ldap_pvt_sasl_mutex_dispose () #10 0x0000000000482547 in ldap_pvt_sasl_mutex_dispose () #11 0x00000000004decab in ldap_pvt_sasl_mutex_dispose () #12 0x0000000000481b4a in ldap_pvt_sasl_mutex_dispose () #13 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #14 0x000000000043be3e in ldap_pvt_sasl_mutex_dispose () #15 0x0000000000481bc2 in ldap_pvt_sasl_mutex_dispose () #16 0x0000000000482127 in ldap_pvt_sasl_mutex_dispose () #17 0x000000000043c83f in ldap_pvt_sasl_mutex_dispose () #18 0x00000000004205a5 in ldap_pvt_sasl_mutex_dispose () #19 0x0000000000420b7f in ldap_pvt_sasl_mutex_dispose () #20 0x00002ba9886e08a8 in ldap_int_thread_pool_wrapper () #21 0x0000003a546064a7 in start_thread () from /lib64/libpthread.so.0 #22 0x0000003a53ad3c2d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x2ba988eb9bd0 (LWP 28525)): #0 0x0000003a546077e5 in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041b3e2 in ldap_pvt_sasl_mutex_dispose () #2 0x000000000040960e in ldap_pvt_sasl_mutex_dispose () #3 0x0000003a53a1d994 in __libc_start_main () from /lib64/libc.so.6 #4 0x00000000004080d9 in ldap_pvt_sasl_mutex_dispose () #5 0x00007ffff6e2df58 in ?? () #6 0x0000000000000000 in ?? () I have 2 different suffixes, but didn't notice any obvious problem with the database or file system (space left, corruption, bad file owner and so on). For example, the db_stat -c gives the following result on the main database: 579 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 10000 Maximum number of locks possible 10000 Maximum number of lockers possible 10000 Maximum number of lock objects possible 1 Number of lock object partitions 951 Number of current locks 1686 Maximum number of locks at any one time 16 Maximum number of locks in any one bucket 0 Maximum number of locks stolen by for an empty partition 0 Maximum number of locks stolen for any one partition 114 Number of current lockers 130 Maximum number of lockers at any one time 933 Number of current lock objects 1586 Maximum number of lock objects at any one time 3 Maximum number of lock objects in any one bucket 0 Maximum number of objects stolen by for an empty partition 0 Maximum number of objects stolen for any one partition 125M Total number of locks requested (125419838) 125M Total number of locks released (125418879) 0 Total number of locks upgraded 138 Total number of locks downgraded 15 Lock requests not available due to conflicts, for which we waited 0 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 8MB 464KB The size of the lock region 0 The number of partition locks that required waiting (0%) 0 The maximum number of times any partition lock was waited for (0%) 0 The number of object queue operations that required waiting (0%) 0 The number of locker allocations that required waiting (0%) 45 The number of region locks that required waiting (0%) 3 Maximum hash bucket length I've also backed up the content of the /proc/28525 directory for further analysis. What else could I do ?

11 years, 9 months

4
4
0 / 0

syncrepl: consumer state is newer than provider

by Mahadevan, Venkatasubramanian

Hello, I have 2 OpenLDAP servers with the following configuration: -- OpenLDAP 2.4.26-Release running on Red Hat Enterprise 5.5 -- The two servers are setup in a mirrored multi-master configuration. Below is the relevant portion of the slapd.conf: server1 ---------- syncrepl rid=002 provider=ldaps://server2 type=refreshAndPersist retry="5 5 300 +" searchbase="o=ourdomain.ca" attrs="*,+" bindmethod=simple binddn="cn=Replication Manager,o=ubc.ca" credentials=something mirrormode TRUE overlay syncprov syncprov-checkpoint 100 10 server2 ---------- syncrepl rid=001 provider=ldaps://server1 type=refreshAndPersist retry="5 5 300 +" searchbase="o=ourdomain.ca" attrs="*,+" bindmethod=simple binddn="cn=Replication Manager,o=ubc.ca" credentials=something mirrormode TRUE overlay syncprov syncprov-checkpoint 100 10 The servers have their clocks synchronized using ntp. Below is the output of ntpq: server1 ---------- ntpq> peer remote refid st t when poll reach delay offset jitter ============================================================================== +hub.ubc.ca 93.113.2.250 3 u 594 1024 377 1.252 1.110 1.520 *dns3.ubc.ca 192.53.103.108 2 u 92 1024 377 1.648 2.670 0.157 server2 ---------- ntpq> peer remote refid st t when poll reach delay offset jitter ============================================================================== +hub.ubc.ca 93.113.2.250 3 u 332 1024 377 0.706 3.487 0.900 *dns3.ubc.ca 192.53.103.108 2 u 325 1024 377 1.631 3.668 0.022 As far as I can tell the clocks appear to be in sync with each other, so hopefully this is not a cause of the replication issues I am having. The problem is that the servers are now refusing to synchronize with each other (replication was working before) but not it does not. The log files on the servers are filled with entries like: server1 ---------- Jul 29 13:48:54 ldapdev1 slapd[11989]: do_syncrep2: rid=002 LDAP_RES_SEARCH_RESULT Jul 29 13:48:54 ldapdev1 slapd[11989]: do_syncrep2: rid=002 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jul 29 13:48:54 ldapdev1 slapd[11989]: do_syncrep2: rid=002 (53) Server is unwilling to perform Jul 29 13:48:57 ldapdev1 slapd[11989]: conn=1081 op=1 SRCH base="o=ubc.ca" scope=2 deref=0 filter="(objectClass=*)" Jul 29 13:48:57 ldapdev1 slapd[11989]: conn=1081 op=1 SRCH attr=* + Jul 29 13:48:57 ldapdev1 slapd[11989]: conn=1081 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! server2 ---------- Jul 29 13:50:52 ldapdev2 slapd[7996]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT Jul 29 13:50:52 ldapdev2 slapd[7996]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jul 29 13:50:52 ldapdev2 slapd[7996]: do_syncrep2: rid=001 (53) Server is unwilling to perform Jul 29 13:50:55 ldapdev2 slapd[7996]: conn=1102 op=1 SRCH base="o=ubc.ca" scope=2 deref=0 filter="(objectClass=*)" Jul 29 13:50:55 ldapdev2 slapd[7996]: conn=1102 op=1 SRCH attr=* + Jul 29 13:50:55 ldapdev2 slapd[7996]: conn=1102 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! So it is looking like the ContextCSN cookies on both servers are out of sync. Digging further into this, I did a search for the ContextCSN values on both servers and got the following values: server1 ---------- 20110729165747.697237Z#000000#001#000000;20110726161604.535176Z#000000#002#000000 server2 ---------- 20110728220449.050499Z#000000#001#000000;20110728223211.933995Z#000000#002#000000 So my question is: how does one get the server synchronization cookies back into sync and ensure that replication is restarted succesfully again? As of now, all I see is the log files filling up with messages as shown above and the sync cookies not being updated. Any help or pointers are appreciated. Thanks! cheers, Ven

11 years, 10 months

4
5
0 / 0

Memory usage (ITS 6660): Is there a patch to 2.4.23 version to fix the problem ?

by Friedrich Locke

Dear list members, i am running openlda 2.4.23 and i am facing memory usage problems (ITS 6660). I am not given the option to change to 2.4.23. Is there a patch to fix this problem? Thanks once more.

11 years, 10 months

4
12
0 / 0

SSL server certificate that has an intermediary certificate in the chain

by Francis Swasey

I have searched the faq-o-matic, google, the admin guide, and I cannot find any documentation that will allow me to set up my OpenLDAP 2.4.25 server using an SSL certificate that was issued from a CA that uses intermediate certificates (by, which I mean to indicate any commercial SSL cert company currently selling certs). Apache has the SSLCertificateChainFile directive to handle this. OpenLDAP seems to be lacking this functionality. I have tried placing both the server certificate and the intermediate certificate in the same file. OpenLDAP won't start if I put the intermediate certificate first, and openssl fails to verify the certificate chain if I put the server certificate first in the file. Have I missed something obvious or has OpenLDAP really forced me into the position of needing to add the intermediate certificate from my SSL CA Vendor into my trusted store on all my clients? -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

11 years, 10 months

6
16
0 / 0

chaining and referral object with two referrals

by Andreas Haubod

Hello, I use the overlay "chain" on one Server (lets call "global-ldap-01.site." ). How does the overlay chain behave, if it get an referral object with two referrals: dn: ou=finance,dc=mycomapny,dc=com objectClass: referral objectClass: extensibleObject ref: ldap://ldap-01-p.site/ou=finance, dc=mycomapny,dc=com ref: ldap://ldap-01-s.site/ou=finance, dc=mycomapny,dc=com This referral is in the DIT from the global-ldap-01 database, but refers to other ldap-servers. (ldap-01-p and ldap-01-s are configured as N-Way multi-master and located in different data centers) The objective is, that I can shut down one server (or if one Server fails) and the system is running without "bigger" disruption. If I turn off the ldap-01-p, ldap-01-s will be used from the global-ldap-01 So that works fine. If the ldap-01-p comes back, the global-ldap-01 use it again automatically. But if the Server ldap-01-p is down a longer time and I turn on this server, it has to replicate with the running ldap-01-s first. Can I control or configure this preemption and behavior? Thank and kindly regards Meike

11 years, 10 months

1
0
0 / 0

Re: SlapD is using more CPU

by Édnei

Hello, sorry for the message delayed. So, how many clients you have in this server ? On 28-07-2011 05:28, arun.sasi1(a)wipro.com wrote: > > Hi, > > Below are the latest unexpected service outage log > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3273 op=2 SEARCH > RESULT tag=101 err=32 nentries=0 text= > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3276 fd=36 ACCEPT > from IP=134.32.44.37:60341 (IP=0.0.0.0:389) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3276 op=0 BIND > dn="cn=admin,dc=emb,dc=slb,dc=com" method=128 > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3276 op=0 BIND > dn="cn=admin,dc=emb,dc=slb,dc=com" mech=SIMPLE ssf=0 > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3276 op=0 RESULT > tag=97 err=0 text= > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3276 op=1 SRCH > base="dc=emb,dc=slb,dc=com" scope=2 deref=0 > filter="(&(objectClass=posixAccount)(uidNumber=470649))" > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3276 op=1 SRCH > attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell > gecos description objectClass > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3276 op=1 SEARCH > RESULT tag=101 err=0 nentries=1 text= > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3262 op=8 SRCH > base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 > filter="(&(objectClass=sambaGroupMapping)(sambaSID=s-1-1-0))" > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3262 op=8 SRCH > attr=gidNumber sambaSID sambaGroupType sambaSIDList description > displayName cn objectClass > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3262 op=8 SEARCH > RESULT tag=101 err=0 nentries=0 text= > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3273 op=3 SRCH > base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 > filter="(&(objectClass=sambaGroupMapping)(gidNumber=65534))" > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3273 op=3 SRCH > attr=gidNumber sambaSID sambaGroupType sambaSIDList description > displayName cn objectClass > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3273 op=3 SEARCH > RESULT tag=101 err=0 nentries=0 text= > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3260 op=3 SRCH > base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 > filter="(&(objectClass=sambaGroupMapping)(gidNumber=65534))" > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3260 op=3 SRCH > attr=gidNumber sambaSID sambaGroupType sambaSIDList description > displayName cn objectClass > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3260 op=3 SEARCH > RESULT tag=101 err=0 nentries=0 text= > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3262 op=9 SRCH > base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 > filter="(&(objectClass=sambaGroupMapping)(sambaSID=s-1-5-2))" > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3262 op=9 SRCH > attr=gidNumber sambaSID sambaGroupType sambaSIDList description > displayName cn objectClass > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3262 op=9 SEARCH > RESULT tag=101 err=0 nentries=0 text= > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3276 fd=36 closed > (connection lost) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: daemon: shutdown > requested and initiated. > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3173 fd=19 closed > (slapd shutdown) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=4 fd=21 closed > (slapd shutdown) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=0 fd=22 closed > (slapd shutdown) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=1 fd=23 closed > (slapd shutdown) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3230 fd=24 closed > (slapd shutdown) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=6 fd=25 closed > (slapd shutdown) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=805 fd=26 closed > (slapd shutdown) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3223 fd=27 closed > (slapd shutdown) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3246 fd=28 closed > (slapd shutdown) > > Thanks, > > -Arun > > *From:*Arun Sasi V (WI01 - Manage IT) > *Sent:* Tuesday, July 26, 2011 9:39 AM > *To:* 'Édnei' > *Subject:* RE: SlapD is using more CPU > > Hi, > > I can show you the settings by live meeting session... there we can > chat or can call too... > > Can I have your number and also let me know your convenient time to > share the session... > > Thanks, > > -Arun > > *From:*Arun Sasi V (WI01 - Manage IT) > *Sent:* Tuesday, July 26, 2011 9:16 AM > *To:* 'Édnei' > *Cc:* openldap-technical(a)openldap.org > *Subject:* RE: SlapD is using more CPU > > Fyi... > > Thanks, > > -Arun > > *From:*Édnei [mailto:ednei.felipe.rodrigues@gmail.com] > *Sent:* Tuesday, July 26, 2011 2:11 AM > *To:* Arun Sasi V (WI01 - Manage IT) > *Cc:* openldap-technical(a)openldap.org > *Subject:* Re: SlapD is using more CPU > > Hello. > Do you show us the settings ? > On 25-07-2011 04:54, arun.sasi1(a)wipro.com > <mailto:arun.sasi1@wipro.com> wrote: > > Hello Team, > > Whenever the number of search increase to the master server... slapd > is utilizing more about more than 100%... What could be the reason and > also is there any bench mark defined... > > Whenver it goes 100% slapd server is getting stopped... > > Thanks & Regards, > > *Arun Sasi V* > > *Please do not print this email unless it is absolutely necessary. * > > The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of the > addressee(s) and may contain proprietary, confidential or privileged > information. If you are not the intended recipient, you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately and destroy all copies of this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient > should check this email and any attachments for the presence of > viruses. The company accepts no liability for any damage caused by any > virus transmitted by this email. > > www.wipro.com <http://www.wipro.com> > > *Please do not print this email unless it is absolutely necessary. * > > The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of the > addressee(s) and may contain proprietary, confidential or privileged > information. If you are not the intended recipient, you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately and destroy all copies of this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient > should check this email and any attachments for the presence of > viruses. The company accepts no liability for any damage caused by any > virus transmitted by this email. > > www.wipro.com >

11 years, 10 months

2
2
0 / 0

sudo via ldap

by Tim Dunphy

Hello list! I have configured an ldap server to include the sudo schema. In my slapd.conf file i have the following entry in my schemas section: include /usr/local/etc/openldap/schema/sudo.schema On my one test client I have the following ldap.conf: host 127.0.0.1 base dc=summitnjhome,dc=com sudoers_base ou=sudoers,ou=Services,dc=summitnjhome,dc=com binddn cn=pam_ldap,ou=services,dc=summitnjhome,dc=com bindpw secret scope sub pam_password exop nss_base_passwd ou=staff,dc=summitnjhome,dc=com nss_base_shadow ou=staff,dc=summitnjhome,dc=com And in my nsswitch I have the following entry: sudoers: ldap I can authenticate and search through the pam_ldap account as well as anonymously. I have my user account setup in the directory this way: # summitnjhome.com dn: dc=summitnjhome,dc=com dc: summitnjhome objectClass: dcObject objectClass: organization o: Summit NJ Home # staff, summitnjhome.com dn: ou=staff,dc=summitnjhome,dc=com ou: staff objectClass: organizationalUnit # sudoers, Services, summitnjhome.com dn: ou=sudoers,ou=Services,dc=summitnjhome,dc=com ou: sudoers objectClass: organizationalUnit objectClass: top # defaults, sudoers, Services, summitnjhome.com dn: cn=defaults,ou=sudoers,ou=Services,dc=summitnjhome,dc=com objectClass: top objectClass: sudoRole cn: defaults description: Default sudoOption's go here # %summitnjops, sudoers, Services, summitnjhome.com dn: cn=%summitnjops,ou=sudoers,ou=Services,dc=summitnjhome,dc=com objectClass: top objectClass: sudoRole cn: %summitnjops sudoHost: ALL sudoRunAsUser: ALL sudoCommand: ALL sudoOption: !authenticate sudoUser: %summitnjops sudoUser: bluethundr # bluethundr, summitnjops, staff, summitnjhome.com dn: uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com uid: bluethundr cn: Timothy P. Dunphy givenName: Timothy P. sn: Dude mail: bluethundr(a)example.com mailRoutingAddress: bluethundr(a)mail.example.com mailHost: mail.summitnjhome.com objectClass: inetLocalMailRecipient objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top userPassword:: e0NSWVBUfWNySmg3NGtXbHRXeVE= uidNumber: 1001 gidNumber: 1002 homeDirectory: /home/bluethundr gecos: Timothy P. loginShell: /bin/bash But when I attempt to sudo from the user account, the ladap server searches the correct DN but does not find the user account from what I can tell, tho I am still trying to get the hang of parsing ldap log files: [bluethundr@LBSD2:/usr/home/bluethundr]$sudo -i Password: bluethundr is not in the sudoers file. This incident will be reported. >From the log: Jul 30 22:02:30 LBSD2 slapd[95958]: conn=349346 op=1 SRCH base="ou=sudoers,ou=Services,dc=summitnjhome,dc=com" scope=2 deref=0 filter="(cn=defaults)" I was hoping I could get some advice on how to perhaps adjust either the directory structure or the ldap query so that the sudo user can be found. I'm including my slapd.conf file, dump of the directory (named snjh.ldif) and more complete logs in hopes that someone out there can help track down the solution to the problem. The log file is basically a snapshot in time of the event when I try to log in as the sudo user. Thanks in advance! Tim

11 years, 10 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2011