RE24: Locker killed to resolve a deadlock
by Michael Ströder
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.
14 years, 3 months
pwdAccountLockedTime and delta-syncrepl
by Sam Tran
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
14 years, 4 months
load problem in mirror mode
by Hugo Monteiro
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:~# _
14 years, 4 months
increase sizelimit on subtree
by Hallvard B Furuseth
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
14 years, 4 months
ldapdelete struggle
by LÉVAI Dániel
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
14 years, 4 months
slapd hangs on startup from unclean shutdown
by Adam Williams
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?
14 years, 4 months
Problem with adding entries
by Amanda Swearngin
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...
14 years, 4 months
relay backend doesn't support pagedResult control
by Guillaume Rousse
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
14 years, 4 months
dn cache size exceeds the limits
by p_pavlos＠freemail.gr
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
14 years, 4 months
