openldap-software October 2008

openldap-software@openldap.org

55 participants
54 discussions

RE24: Locker killed to resolve a deadlock
by Michael Ströder 13 Oct '08

13 Oct '08

HI! Playing with recent RE24 and MIT Kerberos' LDAP backend I noticed this in syslog: Oct 11 10:15:35 nb2 slapd[3888]: => bdb_dn2id_add 0x8d: put failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock -30995 Oct 11 10:15:35 nb2 slapd[3888]: => bdb_dn2id_add 0x8c: put failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock -30995 Oct 11 10:15:35 nb2 slapd[3888]: conn=5 fd=29 closed Oct 11 10:15:35 nb2 slapd[3888]: => bdb_dn2id_add 0x8d: put failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock -30995 Can't reproduce though. Under which circumstances can this happen? Ciao, Michael.

2 1

pwdAccountLockedTime and delta-syncrepl
by Sam Tran 11 Oct '08

11 Oct '08

Dear All, I have an LDAP provider and its consumer running OpenLDAP 2.3.43, the replication mode being delta-syncrepl. Password policy is enabled on both servers. I performed the following tests: 1- Tried N bind attempts to *LDAP provider* with N = pwdMaxFailure and wrong password. N pwdFailureTime attributes and one pwdAccountLockedTime attribute were added to the binding DN on provider. All changes were replicated to the consumer. As a result it was *not* possible to bind to either the provider or the consumer using the correct password. Changing the password on the provider removed the pwdFailureTime and pwdAccountLockedTime attributes on the provider. Changes were replicated to the consumer. As a result it was possible to bind to either the provider or the consumer using the new password. All works as designed. 2- Tried N bind attempts to *LDAP consumer* with N = pwdMaxFailure and wrong password. N pwdFailureTime attributes and one pwdAccountLockedTime attribute were added to the binding DN on consumer. As a result it was *not* possible to bind to the consumer using the correct password. Changing the password on the provider caused the pwdFailureTime attributes to be removed on the consumer. But the pwdAccountLockedTime attribute was still present in the binding DN on the consumer. As a result it was *still not* possible to bind to the consumer using the new password. Is this the expected behavior? I thought that changing the password on the provider would remove both the pwdFailureTime and pwdAccountLockedTime attributes on the consumer, thus allowing me to bind to the consumer. Any help on the matter would be very much appreciated. Thanks. -- Sam

2 4

Re: load problem in mirror mode
by ghenry＠OpenLDAP.org 10 Oct '08

10 Oct '08

----- "Hugo Monteiro" <hugo.monteiro(a)fct.unl.pt> wrote: > Gavin Henry wrote: > > Can you put your config online somewhere? > > > > Thanks. > > > > > > My appologies for the late reply, but life got in the way. :) > > The configuration files for both nodes, their respective DB_CONFIG > file, > and the ldap proxy config file can be reached here: > > http://pessoa.fct.unl.pt/hmmm/ > There were some mistakes in the docs that have been fixed: http://www.openldap.org/devel/cvsweb.cgi/~checkout~/admin/replication.sdf?r… Also, you don't have a serverID -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

3 3

load problem in mirror mode
by Hugo Monteiro 10 Oct '08

10 Oct '08

Hello list, I've set up 2 servers in mirror mode, running version 2.4.10 from debian unstable (2.4.10-3). Those two servers are only accessed by a proxy openldap server, version 2.3.30-5 from debian stable, using the back_ldap backend. This setup makes the proxy server to use one of the backend servers at a time, falling back to the other node in the case that the current backend is no longer available. So far so good, on to the problem; From time to time, one of the nodes starts to get high CPU loads. This happens in a random way, sometimes it's the current backend that starts to get the high load, sometimes it's the "stand by" server that starts to get the high load. Strangely the high load isn't like i've seen happen before, in other setups, with slapd consuming constantly 99% of cpu resources. A top command shows variations of CPU usage, making one think that it's just a peak of load, but it really doesn't go away. A simple restart of the daemon makes things all right again. Another strange thing is that if the load happens on the "stand by" server, and although the current backend's load is just fine, the queries start to get affected and start taking 3-4 seconds or more to get the results. I do know that the problem isn't with the proxy server since there's no obvious variation on the used resources and the problems persist if i issue the queries directly to the backend servers. Both the mirror nodes and the proxy are set on Xen virtual machines, all the machines have their clock in sync (through ntpd on dom0). When things are fine, the usual load on the machines never exceeds 0.20. The proxy server has 2 vcpus and 1GB of ram, while the backend machines have 3 vcpus and 2GB of ram. They aren's all in the same physical server and there isn't any kind of resource overbooking so far (neither mem or cpu) on the host systems they are running. The database occupies a bit less than 700MB on disk, and both backends have a defined cachesize of 1750MB, which is more than enough. I also have never see the system use any swap so far. From the logs, while using log level of stats + sync i cannot see any irregularity. I've searched the ITS database but could not find any report that would mach these criteria. If i've neglected any information, please advise. Any help would be much appretiated. Regards, Hugo Monteiro. -- ci.fct.unl.pt:~# cat .signature Hugo Monteiro Email : hugo.monteiro(a)fct.unl.pt Telefone : +351 212948300 Ext.15307 Centro de Informática Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.ci.fct.unl.pt apoio(a)fct.unl.pt ci.fct.unl.pt:~# _

2 2

increase sizelimit on subtree
by Hallvard B Furuseth 09 Oct '08

09 Oct '08

Is it possible to give a subtree of a database higher sizelimits (hard, unchecked) than the rest of the database? I thought I'd managed it by putting the subtree in a subordinate database, but now that gets the same limit anyway, even when I search with the subtree DN as baseDN. -- Hallvard

2 2

ldapdelete struggle
by LÉVAI Dániel 07 Oct '08

07 Oct '08

Hi! I'm having this problem with deleting an entry from my ldap database. Here is what I'm doing: # search for the entry $ ldapsearch -ZZWx '(mail=*uzem*)' Enter LDAP Password: [...] dn:: Y249w5x6ZW1lbHRldMO1IEJyaWfDoWQsY249ZGFuaWVsbCxjbj1hZGRyZXNzYm9va3MsZGM9Z WNlbnRydW0sZGM9aHU= [...] # numResponses: 2 # numEntries: 1 # got the dn, it is encoded in base64, so I'm trying to delete it: $ cat ldap_delete.ldif dn:: Y249w5x6ZW1lbHRldMO1IEJyaWfDoWQsY249ZGFuaWVsbCxjbj1hZGRyZXNzYm9va3MsZGM9Z # ^^ that is one line in the file $ ldapdelete -ZZWx -vf ldap_delete.ldif ldap_initialize( <DEFAULT> ) Enter LDAP Password: deleting entry "dn:: Y249w5x6ZW1lbHRldMO1IEJyaWfDoWQsY249ZGFuaWVsbCxjbj1hZGRyZXNzYm9va3MsZGM9Z" ldap_delete: Invalid DN syntax (34) additional info: invalid DN I've tried it without the dn:: prefix too, but it didn't work. Could someone help me with this? Thanks in advance! Daniel -- LEVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1

3 6

slapd hangs on startup from unclean shutdown
by Adam Williams 07 Oct '08

07 Oct '08

I'm running openldap 2.3.43 on a Fedora 9 Linux x64-bit system. I've had to hard reboot this system a few times without cleanly shutting it down. upon startup, most of the time slapd hangs when trying to start due to not shutting down cleanly. The only way to get it going again is to go into single user mode, delete everything in /var/lib/ldap and then loading a nightly backup.ldif with slapadd. Is are there any settings/configuration changes I can make to slapd to have it start up from unclean shutdowns?

2 1

Problem with adding entries
by Amanda Swearngin 07 Oct '08

07 Oct '08

I am unable to add any entries to my Openldap server. Here is the error message that I'm getting: ldap_bind: Server is unwilling to perform (53) additional info: operation not supported within naming context I have no idea what this means. Here is my configuration file (slapd.conf): # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules: # modulepath /usr/lib/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la #moduleload back_passwd.la # moduleload back_shell.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. # TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt # TLSCertificateFile /etc/pki/tls/certs/slapd.pem # TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: #access to dn.base="" by * read #access to dn.base="cn=Subschema" by * read #access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # ldbm and/or bdb database definitions ####################################################################### database bdb suffix "dc=rcf,dc=unl, dc=edu" rootdn "cn=Manager,dc=rcf,dc=unl,dc=edu" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {CRYPT}neyDfOno9u/rg # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain for this database # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM #Access controls defaultaccess none access to attrs=userPassword by self write by * auth access to * by self write by * read by * auth Here is the ldap.conf file: # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=rcf, dc=unl, dc=edu BINDDN cn=Manager,dc=rcf,dc=unl,dc=edu HOST 10.147.99.4 #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never And here is an example entry that I'm trying to add; dn: uid=aswearngin,ou=People,dc=rcf,dc=unl,dc=edu uid: aswearngin cn: Amanda surname: Swearngin title: Undergrad groupName: swanson mailLocalAddress: mandamarie05(a)hotmail.com telephoneNumber: 555-5555 department: Computer S campus: UNL-City college: Arts & Sciences objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword: {crypt}$1$bGtPvMog$k25rfZEgKjlvsdNb8r1BX0 shadowLastChange: 14154 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 505 gidNumber: 506 homeDirectory: /home/aswearngin This is the command that I'm using along with several variations of this: ldapadd -x -D "cn=Manager, dc=rcf, dc=unl, dc=edu" -W -f mysqlpasswd12.ldif I hope this is enough information to give you a sense of my situation. I am new to this and I am really confused as to how it works, so it would be awesome if someone could help me with this. Thanks Amanda _________________________________________________________________ Want to do more with Windows Live? Learn “10 hidden secrets” from Jamie. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!5…

3 2

relay backend doesn't support pagedResult control
by Guillaume Rousse 05 Oct '08

05 Oct '08

Hello list. I managed to get a correct relay backend configured, so as to remap attributes, thanks to previous help from people here. It works OK through ldapsearch. However, I still can't use it with the target cisco appliance, as pagedResult control doesn't work: Oct 2 14:07:29 etoile slapd[30006]: conn=118 op=1 SRCH base="ou=telephony,dc=msr-inria,dc=inria,dc=fr" scope=2 deref=3 filter="(objectClass=inetOrgPerson)" Oct 2 14:07:29 etoile slapd[30006]: conn=118 op=1 SRCH attr=uid givenname initials sn manager departmentnumber telephonenumber mail title homephone mobile pager Oct 2 14:07:29 etoile slapd[30006]: conn=118 op=1 SEARCH RESULT tag=101 err=12 nentries=0 text=critical control unavailable in context When debug level is set to 1, I get this: Oct 2 14:16:15 etoile slapd[6002]: => get_ctrls Oct 2 14:16:15 etoile slapd[6002]: => get_ctrls: oid="1.2.840.113556.1.4.319" (critical) Oct 2 14:16:15 etoile slapd[6002]: <= get_ctrls: n=1 rc=0 err="" Reading ITS 5191, I understand it is supposed to have been fixed in 2.4 release. However, I'm using 2.4.11, and I'm still getting the problem. Should I reopen the ticket ? Here's my configuration, if that matters. Trying to make the relay database subordinate to the other one doesn't change the problem. database relay suffix ou=telephony,dc=msr-inria,dc=inria,dc=fr overlay rwm rwm-suffixmassage ou=users,dc=msr-inria,dc=inria,dc=fr rwm-map attribute telephoneNumber homePhone rwm-map attribute telephoneNumber database bdb suffix "dc=msr-inria,dc=inria,dc=fr" rootdn "cn=root,dc=msr-inria,dc=inria,dc=fr" -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62

3 3

dn cache size exceeds the limits
by p_pavlos＠freemail.gr 04 Oct '08

04 Oct '08

Hi, During performance testing with SLAMD we noticed the dncache exceeds the limit. As a result the system starts to swap a lot and the responses of slapd are very slow. Has anyone seen that behavior before? Here are the facts: slapd.conf monitoring on tool-threads 4 cachesize 450000 dncachesize 450000 idlcachesize 450000 cachefree 90000 # ldapsearch -x -D "cn=xxxx" -w xx -b 'cn=database 2,cn=databases,cn=monitor' -s sub '(objectclass=*)' '*' '+' | grep -i Cache olmBDBEntryCache: 398306 olmBDBDNCache: 482001 <<========== olmBDBIDLCache: 449999 # slapd -V @(#) $OpenLDAP: slapd 2.4.11 (Sep 11 2008 10:58:58) $ root@node3:/usr/src/redhat/BUILD/openldap-2.4.11/servers/slapd #db_stat -V Berkeley DB 4.6.21: (September 27, 2007) # uname -r 2.6.9-67.ELsmp # cat /etc/redhat-release Red Hat Enterprise Linux AS release 4 (Nahant Update 6) Cheers, Pavlos

3 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software October 2008