--On Thursday, September 10, 2009 8:56 PM +0200 Tihomir Culjaga
> So, the situation is that i have 2 ldif files i'm recreating the database
> /usr/local/libexec/slapadd -l /home/tculjaga/file2.ldif -f
> /usr/local/libexec/slapadd -l /home/tculjaga/file2.ldif -f
I would suggest you just make these a single file, so all the work can be
done at one time.
> I tried to re-index with /usr/local/libexec/slapindex -f
> /usr/local/etc/openldap/slapd.conf -v
> restart slapd process, restart the machine ... it is always the same
Nothing here indicates a problem with your indices. Running slapindex
repeatedly is a waste of your time.
> [root@l01lnp2 traces]# /usr/local/libexec/slapd -V
> @(#) $OpenLDAP: slapd 2.4.16 (Sep 9 2009 14:39:44) $
I would strongly urge you to upgrade to 2.4.18 (for reasons I will note
> [root@l01lnp2 traces]# /usr/local/BerkeleyDB.4.7/bin/db_stat -V
> Berkeley DB 4.7.25: (May 15, 2008) - unpached!
You need to rebuild BDB 4.7.25 with the 4 patches from Oracle. There are
known issues when running BDB 4.7 without them.
> [root@l01lnp2 traces]# du -c -h /var/lib/ldap/*.bdb
> 200K /var/lib/ldap/bestMatchPrefix.bdb
> 3.8G /var/lib/ldap/dn2id.bdb
> 6.2G /var/lib/ldap/id2entry.bdb
> 1.8M /var/lib/ldap/objectClass.bdb
> 1.2M /var/lib/ldap/originatorPrefixID.bdb
> 48M /var/lib/ldap/uniqueID.bdb
> 10G total
Since your database is a total of 10 GB in size, for slapadd to work at
optimum efficiency, you need at least 10GB of cache for your DB_CONFIG
file. Unfortunately, you only have 10GB of RAM. Essentially, your system
is under powered for your database size.
> [tculjaga@l01lnp2 ~]$ cat ot.ldif | grep -c "dn: "
> [tculjaga@l01lnp2 ~]$ cat l01sipdir1.ldif | grep -c "dn: "
> [tculjaga@l01lnp2 ~]$
So you have 10,096,452 entries total.
> [root@l01lnp2 traces]# cat /var/lib/ldap/DB_CONFIG | grep -v "#"
> set_cachesize 0 3221225472 1
> set_lg_regionmax 262144
> set_lg_bsize 2097152
You only have a 3GB DB cachesize configured here. Expect things to perform
sub optimally. It would have been easier to set this by going
set_cachesize 3 0 1
Which would have the same effect, since the first number is the number of
gigabytes to allocate.
> Please find attached slapd.conf
Ok, so the relevant bits from here are:
Which means you have a cachesize of 2.5 million, an idlcachesize of 7.5
million, and (with OL 2.4.16) a dncachesize of 5 million.
I would highly advise you upgrade to OpenLDAP 2.4.18, and change the
slapd.conf settings to:
dncachesize 0 (which means unlimited).
And setting no cache or idlcachesize, and fixing your DB_CONFIG. But you
also need to buy a substantial amount of RAM for a DB of this size. :P I
would advise you upgrade to at least 32GB total. Then you can more
optimally tune the system.
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration
I have installed OpenLdap and PHPLdapAdmin.
I have added a user which objectclass is :
objectClass inetOrgPerson posixAccount shadowAccount
I need to add a new attribute which will be application specific
(application which will need LDAP authentication and based on the attribute
value, it will provide service to the user).
When I tried to do the same by adding attribute and value to ldif files and
then adding the ldif file, it showed error:
ldap_add: Undefined attribute type (17) additional info: AppAttribute1:
attribute type undefined.
Do I need to modify related schema for the same?
Please suggest some suitable way to do the same. Is there any way that I can
do it from the PhpLDAPAdmin GUI?
Thanks in advance.
I got an issue with OpenLDAP....
BDB 4.7 and OpenLDAP 2.4.18 is runnong on CentOS 5.3 installed on an HP
DL380 G5 machine with 10 GB RAM.
The database is quite big...ldif file is ~2GB. I manage to load the ldif
file into the DB with ldapadd.
Well, so far so good, i'm able to search entries. My application on a
different server connects to LDAP and requests entire subtree
(ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr) and within a minute and
half, it gets everything.
Now, the problem comes when you add some few more entries to the DB with
ldapadd... in my case 2 entries
carrier: Telekom Austria
The application doesn't get all entries ... as LDAP server stops respnding.
In brief, i run ldapsearch manually and i get it stuk after a while:
[root@l01lnp2 ldap]# time ldapsearch -h localhost -x -b
ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr -D cn=admin,dc=ot,dc=hr
# extended LDIF
# base <ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr> with scope
# filter: (objectclass=*)
# requesting: ALL
# bestMatchPrefixList, sipDirektor, ot.hr
# 7, bestMatchPrefixList, sipDirektor, ot.hr
destination: Russian Federation
# 043010, 046010.100.8000.100, 99893, bestMatchPrefixList, sipDirektor,
# 039010, 046010.100.8000.100, 99893, bestMatchPrefixList, sipDirektor,
It hangs here ... and i have to stop ldapsearch (CTRL + C)
I have the same issue on the BDB4.3 and OpenLDAP 2.3 that comes with CentOD
5.3 distribution as well.
What m'I missing?
What can i do ?
I already tried to:
reindex (slapindex -f slapd.conf)
I was wondering if there is a way to let specific users access (write ) given fields :
• all my users are in a single branch
• all my users are inetOrgPerson + posixAccount
• users are distributed in several groups according to their gidNumbers
• some users are priviledged and also belong to a given posixGroup
I would like to know if it is possible to write an acl so that :
a priviledge user can modify some fields ( shell, homeDirectory ) of users whose gidNumber matches the gidNumber of the priviledged user
Now I know that 2.4 is the recommended level, however, this system is not ready to be converted (yet).
It's running 2.3.39 on AIX 5.3 (BDB 4.4.20 with all patches) and in the master in a master/slave (slurpd) environment. I could upgrade to 2.3.43 (if you think it will help), but we are planning moving it to 2.4 soon.
We had an issue with an ldapsearch that would not finish - it connected, but failed to return information.
When I "truss"-ed the pid, it was switching between threads but acted like
The slapd daemon responded to kill -HUP and stopped successfully. db_recover was:
[svc1:/ldap/db/database] # /opt/pware/bin/db_recover -v -h .
Finding last valid log LSN: file: 545 offset 8672731
Recovery starting from 
Recovery complete at Wed Sep 9 15:22:45 2009
Maximum transaction ID 8005cffa Recovery checkpoint 
Then we ran a script that stops the DB and does an export (which looks good) and tars up the db files and log file. Shortly thereafter searching for the same entry cause a hang, but slapd stopped successfully. Then ran db_recover again:
[svc1:/ldap/db/database] # db_recover -v -h .
Finding last valid log LSN: file: 545 offset 8900926
Recovery starting from 
Recovery complete at Wed Sep 9 15:29:37 2009
Maximum transaction ID 800000ad Recovery checkpoint 
Unfortunately we had the log level set to 0, so we never saw the details in syslog. Is 256 the correct value (which logs quite a bit of stuff) for a busy server?
Is this a corrupt environment? Corrupt index? Should we remove the environment and reindex the database? We are trying to avoid reloading from the export, if possible.
Again, we are just trying to breathe some life into this server for the short term as moving to 2.4 right this minute has other implications we just can't change at the moment.
Appreciate any ideas on this.
I'm currently monitoring the cache efficiency in a BerkeleyDB backend,
as examined with db_stat -m. About 24 hours after starting slapd I
noticed a significant drop in several indexes, while the general
activity did not change much at that time. Also, the systems using the
service did not experience any reduction in availability or response.
The cache efficiency in percentage remains at 99%.
Its MirrorMode peer experienced a similar drop at the exact same time,
though for fewer indexes.
The affected nodes are in a refreshAndPersist, retry="60 +" MirrorMode
setup. Backend database is configured as hdb. The binaries in use are
the latest RPMs from Buchan Milne (openldap2.4-servers-2.4.17-3.rhel5,
which comes packed with its own BerkeleyDB 4.7 libraries), running on a
The graphs are available at http://www.ruberg.no/tmp/slapd.html. The
drops occured just before 15:00.
The nodes are in the same IP network without any routers or firewalls
in-between. Replication between the nodes works flawlessly.
Is this kind of drop normal behaviour? Has slapd stopped asking its
backend (or peer) for data and started serving everything from its own
buffer? Since the observations correlate between the active and the
passive node I currently suspect this involves the replication mechanism(s).
(The reason some indexes are not currently graphed is that the numbers
read from db_stat are suffixed with SI units when above 10 million, and
the monitoring tool doesn't account for that yet.)
Thanks for any pointers and ideas,
Our current setup is 2 active directories, with one openLdap.
Our applications syncs with openLdap, openLdap acts as a proxy to the active
directories, meaning we can see both AD's in OpenLdap.
This is great, but when we setup trusts in Active Directory, openLdap
detects them as simple folders, and does not apply the trust.
Therefore when we sync we only get the top folder, the trust inside it is
ignored. meaning we are missing a level.
Is there anyway of making openLdap detect these trusts and apply them ?
I realise this borders on a Java development question but I presume there
is an ldap-specific side of it as well so - here we go.
We use an OpenLDAP service to authenticate and authorize users of server
based web applications written as JSP/EJB pages.
We have a reasonably working solution to let assorted exception messages
filter back to the user.
Much more difficult getting the warning messages back telling for instance
that the password is about to expire or that it already has expired and so
and so many grace logins remain, due to ppolicy.
I can see them in the ldap server application log but how to access them
programmatically boggles my mind.
I'm a happy user of the stock OpenLDAP in RHEL/CENTOS 5 which is based on
OpenLDAP 2.3.27 however now I need slapo-memberof.
Do I need to upgrade to OpenLDAP 2.4 to use this?
Does anyone have this functioning under RHEL/CENTOS?