mdb_idl_fetch_key: cursor failed: Invalid argument (22)
by Roman Rybalko
I have such error in logs:
null_callback : error code 0x50
syncrepl_entry: rid=001 be_add
logID=502,logID=402,logHost=mail.xxx.xxx.xx,logName=main,cn=test failed (80)
do_syncrepl: rid=001 rc 80 retrying (2 retries left)
and then every 2-3 minutes:
=> mdb_idl_fetch_key: cursor failed: Invalid argument (22)
MDB is running on replication consumer.
I shutted down the replication provider for reindexing.
The consumer was not fully synced at that time.
Than I changed olcDbMaxSize on the replication consumer.
Than I started the provider again.
Seems the error happened first time right after olcDbMaxSize was
increased from 5G to 8G. I've never changed it before.
Sep 30 16:07:01 lintest slapd[518]: conn=1089 op=1 MOD
dn="olcDatabase={1}mdb,cn=config"
Sep 30 16:07:01 lintest slapd[518]: conn=1089 op=1 MOD attr=olcDbMaxSize
Sep 30 16:07:03 lintest slapd[518]: conn=1089 op=1 RESULT tag=103 err=0
text=
Sep 30 16:07:03 lintest slapd[518]: conn=1089 op=2 UNBIND
Sep 30 16:07:03 lintest slapd[518]: conn=1089 fd=12 closed
Sep 30 16:07:03 lintest slapd[518]: => mdb_idl_fetch_key: cursor failed:
Invalid argument (22)
slapd version git a1c2dc6
db size 3.7Gb
What this error is about? Is it serious?
Should I recreate the DB on the consumer? Seems replication is stalled.
--
WBR,
Roman Rybalko
10 years, 12 months
LDAP and MD5 authentication issues.
by S K
Hi,
I am newbie to LDAP and I am having a issue. I have to work with MD5
authentication as the application we are going to use has to bind to a LDAP
server with password generated using MD5. I am not able to authenticate
with password generate using the perl script or using the md5 executable.
But if I generate the passwords using slappassword and MD5 I am fine. Can
somebody please explain what I am doing wrong and how I can authenticate
using perl or md5 exe generated password. Any help is greatly appreciated.
Passwords generated using this perl script. for example. MD5 for hello
perl -e 'use Digest::MD5 qw(md5_hex);print uc(md5_hex("hello"))."\n";'
5D41402ABC4B2A76B9719D911017C592
Using slappasswd
./slappasswd -h \{MD5\} -s hello
{MD5}XUFAKrxLKna5cZ2REBfFkg==
My LDIF file user MD5A assigned perl or md5 exe generated MD5 password and
user MD5B assigned slappasswd generated MD5 password.
dn: cn=MD5A, ou=hr, o=test
objectClass: top
objectClass: person
objectClass: organizationalPerson
cn: MD5A
sn: MD5A
userpassword: {MD5}5D41402ABC4B2A76B9719D911017C592
title: admin
dn: cn=MD5B, ou=hr, o=test
objectClass: top
objectClass: person
objectClass: organizationalPerson
cn: MD5B
sn: MD5B
userpassword: {MD5}XUFAKrxLKna5cZ2REBfFkg==
title: admin
Import LDIF:
# /usr/local/bin/ldapadd -x -W -D "cn=admin" -f users.ldif
Enter LDAP Password:
adding new entry "o=test"
adding new entry "ou=hr,o=test"
adding new entry "cn=MD5A, ou=hr, o=test"
adding new entry "cn=MD5B, ou=hr, o=test"
ldapsearch fails for MD5A with error 49 and for MD5B it works fine.
# /usr/local/bin/ldapsearch -x -w hello -D "cn=MD5A, ou=hr, o=test"
ldap_bind: Invalid credentials (49)
# /usr/local/bin/ldapsearch -x -w hello -D "cn=MD5B, ou=hr, o=test"
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# test
dn: o=test
objectClass: top
objectClass: organization
o: test
# hr, test
dn: ou=hr,o=test
objectClass: top
objectClass: organizationalUnit
ou: asqmatrix
ou: hr
# MD5A, hr, test
dn: cn=MD5A,ou=hr,o=test
objectClass: top
objectClass: person
objectClass: organizationalPerson
cn: MD5A
sn: MD5A
userPassword:: e01ENX01RDQxNDAyQUJDNEIyQTc2Qjk3MTlEOTExMDE3QzU5Mg==
title: admin
# MD5B, hr, test
dn: cn=MD5B,ou=hr,o=test
objectClass: top
objectClass: person
objectClass: organizationalPerson
cn: MD5B
sn: MD5B
userPassword:: e01ENX1YVUZBS3J4TEtuYTVjWjJSRUJmRmtnPT0=
title: admin
# search result
search: 2
result: 0 Success
# numResponses: 5
# numEntries: 4
Thanks,
SK
10 years, 12 months
Re: ldapsearch stalling when performing searches with a large number of results
by Mark Cairney
My olcDB values are listed below (minus the olcDbConfig entries). I'm not sure if you need the indexes but I've left them in anyway:
olcDbDirectory: /usr/local/authz/var/openldap-data/authorise
olcAddContentAcl: FALSE
olcDbCacheFree: 1
olcDbCacheSize: 400000
olcDbCheckpoint: 10240 10
olcDbDirtyRead: FALSE
olcDbDNcacheSize: 0
olcDbIDLcacheSize: 1200000
olcDbIndex: autoMountKey eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: eduniCategory eq
olcDbIndex: eduniCollegeCode eq
olcDbIndex: eduniIdmsId pres,eq
olcDbIndex: eduniIDStatus eq
olcDbIndex: eduniLibraryBarcode pres,eq
olcDbIndex: eduniOrganisation pres,eq,sub
olcDbIndex: eduniOrgCode eq
olcDbIndex: eduniSchoolCode eq
olcDbIndex: eduniServiceCode pres,eq
olcDbIndex: eduniType eq
olcDbIndex: eduniUnitCode eq
olcDbIndex: eduPersonAffiliation pres,eq
olcDbIndex: eduPersonEntitlement pres,eq
olcDbIndex: eduPersonPrimaryAffiliation eq
olcDbIndex: eduPersonPrincipalName eq
olcDbIndex: eduPersonScopedAffiliation pres,eq
olcDbIndex: eduPersonTargetedID eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: gecos pres,eq,sub
olcDbIndex: gidNumber pres,eq
olcDbIndex: krbName pres,eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: memberOf pres,eq
olcDbIndex: memberUid eq
olcDbIndex: objectClass eq
olcDbIndex: sn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber pres,eq
olcDbIndex: uniqueMember pres,eq
olcDbIndex: userPassword eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbNoSync: FALSE
olcDbSearchStack: 16
olcDbShmKey: 0
and my DB_CONFIG file contains:
set_cachesize 4 0 1
set_flags DB_LOG_AUTOREMOVE
set_lk_max_objects 5000
set_lk_max_lockers 5000
set_lg_regionmax 41943040
set_lg_dir /usr/local/authz/slapd/trans-logs
set_lk_max_locks 10000
set_lg_bsize 20971520
set_lg_max 83886080
I'm not using an SHM key (should I be?).
The search that I spotted this behaviour probably means nothing outside our environment as it's against a value in our local schema but for completeness it was:
(&(eduniCategory=201)(objectclass=inetorgperson))
I've seen the same behaviour with similar searches which we would expect to return a large number of results e.g. (&(eduPersonAffiliation=student)(objectclass=inetorgperson)) or indeed
against groups with a lot of members.
>
> You may wish to read over <https://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning>. You can easily map the information there to a non-zimbra installation.
Thanks- your documentation on the DB tuning and SHM key is excellent. I can see a couple of things which I might change based on it but I'll wait to hear back before I jump in and start playing around with parameters.
>
> --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
>
/****************************
Mark R Cairney
ITI UNIX Section
Information Services
Tel: 0131 650 6565
Email: Mark.Cairney(a)ed.ac.uk
****************************/
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
11 years
range search on Generalized Time attribute
by Marco Schirrmeister
Hi,
OpenLDAP 2.4.32 and also tried with latest RE24
BDB 4.8.30
My DB_CONFIG looks like this.
set_lk_detect DB_LOCK_DEFAULT
set_flags DB_TXN_NOSYNC
set_flags DB_LOG_AUTOREMOVE
set_lg_max 10485760
set_cachesize 0 1073741824 1
set_lk_max_locks 4000
set_lk_max_lockers 4000
set_lk_max_objects 4000
set_lg_regionmax 262144
set_lg_bsize 20971520
set_lg_dir /var/lib/ldap2.4/ogilvy.com/bdb/
In our stage directory I noticed a range search is not returning anything on a specific attribute with generalizedTime syntax.
On production it works fine.
Here is an example command.
$ ldapsearch -x -H ldaps://ds71 -D cn=manager,dc=ogilvy,dc=com -w 'secret' -b ou=people,dc=ogilvy,dc=com -LLL '(&(lastchangeDate<=20111107235959Z)(lastchangeDate>=20111107151200Z))' dn lastchangedate
$
I know my entry falls in that range.
$ ldapsearch -x -H ldaps://ds71 -D cn=manager,dc=ogilvy,dc=com -w 'secret' -b ou=people,dc=ogilvy,dc=com -LLL '(uid=marco.schirrm*)' lastchangedate dn: uid=marco.schirrmeister(a)ogilvy.com,ou=people,dc=ogilvy,dc=com
lastchangeDate: 20111107151301Z
$
The attribute is indexed.
index lastchangeDate eq
Schema has this.
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
I tried recreating the index, but all that did not help.
Same problem exists if I use bach-hdb.
I tried that same dataset with back-mdb and the search returned what I expected.
So I thought it's maybe Berkeley DB bug.
I then tried bdb 5.3.15 some time ago and also the latest 5.3.21.
I see the same issue with this versions.
I first thought it's the amount of entries that cause that issue. It's not really much, but stage has less the prod.
So tried to create different test datasets to see if I can reproduce it.
I was not able to reproduce it with the test datasets. The ldapsearch always returned what I wanted.
I'm now a little bit lost if my DB_CONFIG settings are maybe bad. Or if it is something in Berkeley DB or OpenLDAP.
Any ideas?
I'm going to switch to mdb soon. But was wondering if that is something serious or not.
Here is the slapd.conf.
I omitted all the schema includes and index lines.
include /etc/openldap2.4/slapd.access.ogilvy.conf
pidfile /var/run/ldap2.4/slapd.pid
argsfile /var/run/ldap2.4/slapd.args
modulepath /usr/lib64/oldap24/openldap2.4
moduleload back_monitor.la
moduleload accesslog.la
moduleload syncprov.la
moduleload auditlog.la
TLSCertificateFile /etc/pki/tls/certs/ogilvy.com.crt
TLSCertificateKeyFile /etc/pki/tls/private/ogilvy.com.rsa
TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
loglevel stats
sasl-secprops noplain,noanonymous,noactive
serverID 40 ldaps://ds71.ogilvy.com
database bdb
suffix "dc=ogilvy,dc=com"
rootdn "cn=manager,dc=ogilvy,dc=com"
rootpw FooBarBaz
directory /var/lib/ldap2.4/ogilvy.com
limits dn.exact="cn=manager,dc=ogilvy,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
limits dn.exact="uid=replicator,ou=admin,dc=ogilvy,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
limits group/ogilvyGroup/uniqueMember="cn=svcgrp-unlimitedsearch,ou=groups,dc=ogilvy,dc=com" size.soft=unlimited size.hard=unlimited
cachesize 150000
dirtyread
sizelimit 90000
checkpoint 256 5
conn_max_pending_auth 2000
idlcachesize 450000
dncachesize 150000
monitoring on
overlay syncprov
syncprov-checkpoint 256 5
syncprov-sessionlog 5000
database config
rootdn "cn=admin,cn=config"
rootpw FooBarBaz
include /etc/openldap2.4/slapd.access.config.conf
database monitor
rootdn cn=monitor
rootpw FooBarBaz
--
Marco
11 years
Suggestion about slapd.conf
by Net Warrior
Hi there
I't been long time since I did not administer LDAP, now I have the
need to do it again cuz a new proyect , reading the docs I found that
lots of interesting
things were included and some will be deprecated as for example
slapd.conf, I need to apply some ACL, I'm familliar with the old
slapd.conf style, but the
documentation says slapd.conf will be deprecated sooner latter.
My doubt is that it will be deprecated for the core LDAP configuration
or if something will be still possible to do through it, reading the
documentation ( 2.4 ) I see
examples regarding the old style and do not know if that's for
compatibility or not. Still I do not get familiar with the oclAccess
and the new cn=something structure.
Thanks for your time and support
Best Regards
11 years
syncrepl failure
by manu＠netbsd.org
Hi
I had a master/replicas setup that has been working for years. Recently,
I discovered that a replica sometime failed to return existing entries:
no error, it just returned nentries=0, for a few queries, then went back
to normal.
I suspected some database corruption: I killed slapd, removed the
databases, restarted slapd so that it resync from master. It pulled a
few hundreds of records and then got its up to date contextCSN while a
lot of entries are still missing. Restarting slapd exhibit a stright
failure in syncrepl:
Sep 28 06:34:29 motul slapd[2901]: do_syncrepl: rid=217 rc -2 retrying
How do I debug that? I had the problem with OpenLDAP-2.4.21/
db-4.7.25.3. I tried upgrading the replica to OpenLDAP-2.4.32 /
db-4.8.30 but it did not change anything. Is there a chance that
upgrading the master (runs 2.4.21 too) will help?
During the short time syncrepl runs, logs are filled with stuff like
this, I wonder if it is a related problem or not:
Sep 28 03:30:16 motul slapd[269]: conn=-1 op=0 => bdb_dn2id_add
dn="uid=user,ou=foo,dc=example,dc=net" ID=0x7c: put failed:
DB_LOCK_DEADLOCK: Locker killed to r
esolve a deadlock -30994
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
11 years
dynlist, memberof,and authentication
by Richard Pijnenburg
Hi all,
I've created a group with the dynlist overlay to create dynamic groups.
Now i want to implement authentication with it but seem to be unable to
search on it with nss-pam-lib or sssd.
Before i start configuring all that stuff i wanted to see what
search/filter string i need to make and been playing around to get the
member.
When i search with base the dynamic group i get all the members/
# ldapsearch -x -b 'cn=prod,ou=isp,ou=acl,dc=ispavailability,dc=com'
dn: cn=prod,ou=isp,ou=acl,dc=ispavailability,dc=com
objectClass: groupOfURLs
cn: prod
memberURL:
ldap:///cn=sysadmin,ou=isp,ou=groups,dc=ispavailability,dc=com?memb
er?sub?
member: uid=richard,ou=people,dc=ispavailability,dc=com
So i thought i'll create a search string for the cn and the member.
# ldapsearch -x
'(&(cn=prod)(member=uid=richard,ou=people,dc=ispavailability,dc=com))'
And i get nothing....
So i thought about using the memberof overlay with it.
# ldapsearch -x uid=richard memberof
I get the static group trough the memberof overlay but not the dynamic
group.
Am i missing something or am i trying to do something that's simply not
possible?
Cheers.
Richard
11 years
Implementing ACL, using non-local groups
by Tio Teath
Is it possible to implement ACL, using groups which are accessed via
ldap-proxy, i.e. non-local groups? I've managed to setup
authentication for users, which are in remote LDAP server only, but
looks like remote groups are ignored in case of using 'group.exact='
statement.
11 years
(no subject)
by Tio Teath
Is it possible to implement ACL, using groups which are accessed via
ldap-proxy, i.e. non-local groups? I've managed to setup
authentication for users, which are in remote LDAP server only, but
looks like remote groups are ignored in case of using 'group.exact='
statement.
11 years
Re: nslcd and Ubuntu 10.04
by Adam Wolfe
Many thanks, Christopher. I'm on nslcd 0.7.2 right now. Definitely a place to start. Very appreciated.
Christopher Wood <christopher_wood(a)pobox.com> wrote:
>http://ubuntuforums.org/showthread.php?t=1633524
>
>http://lists.arthurdejong.org/nss-pam-ldapd-users/2011/msg00082.html
>
>My fix was to "apt-get source nslcd" on a Debian Squeeze box, then use those files to build a new deb on Ubuntu and shove the result in my repository. Presto, working nslcd on Ubuntu 10.04.
>
>On Wed, Sep 26, 2012 at 04:46:30PM -0400, Adam Wolfe wrote:
>> I'm having trouble keeping my servers connected to our openLDAP server.
>>
>> All through syslog I see messages like this:
>>
>> Sep 26 14:06:01 hostname nslcd[930]: [2aeb87] connected to LDAP server
>> [1]ldaps://ldap.domain.com/
>> Sep 26 14:07:01 hostname nslcd[930]: [aae0a3] ldap_result() failed: Can't
>> contact LDAP server
>> Sep 26 14:07:01 hostname nslcd[930]: [74310e] ldap_result() failed: Can't
>> contact LDAP server
>> Sep 26 14:07:01 hostname nslcd[930]: [aae0a3] ldap_abandon() failed to
>> abandon search: Other (e.g., implementation specific) error
>> Sep 26 14:07:01 hostname nslcd[930]: [b2a65f] ldap_result() failed: Can't
>> contact LDAP server
>> Sep 26 14:07:01 hostname nslcd[930]: [b2a65f] ldap_abandon() failed to
>> abandon search: Other (e.g., implementation specific) error
>> Sep 26 14:07:01 hostname nslcd[930]: [74310e] ldap_abandon() failed to
>> abandon search: Other (e.g., implementation specific) error
>> Sep 26 14:07:01 hostname nslcd[930]: [73c9b8] ldap_result() failed: Can't
>> contact LDAP server
>> Sep 26 14:07:01 hostname nslcd[930]: [73c9b8] ldap_abandon() failed to
>> abandon search: Other (e.g., implementation specific) error
>> Sep 26 14:07:01 hostname nslcd[930]: [73c9b8] connected to LDAP server
>> [2]ldaps://ldap.domain.com/
>>
>> I'm at the point where I want to start blaming the server, but this is
>> happening on all the new servers I am bringing up (Ubuntu 10.04) and not
>> on the older servers (8.04).
>> Everything seems fine and we can sudo and su with our ldap accounts and
>> then out of no where "so-and-so is not in the sudoers file". A simple "id
>> user" re-establishes the connection and all is well again for a while.
>>
>> Has anyone else ran into this and finally, permanently made it work?
>>
>> References
>>
>> Visible links
>> 1. file:///tmp/ldaps:/ldap.domain.com/
>> 2. file:///tmp/ldaps:/ldap
>
11 years
