I have two openldap servers 2.4.23 running in a multimaster setup whose
content diverged at some point. Fortunatly, I had different backup files
for both, which allowed to me to reconciliate content manually. I
reimported the resulting ldif file in one of the server, re-exported it
through slapcat, and reimported it in the other server, after dropping
all existing databases (including acceslog one).
However, I end up with two bases with multiple and divergent contextCSN
Any attempt to manually reduce this to a single value in the backup file
before restoration ended in infinite refresh request from the second
servers and "stale cookie" error messages.
So, my questions are:
- is this an expectable state to have multiple values for contextCSN ?
- does it hurt, beyond making synchronisation checking almost impossible ?
- how to return to a stable situation ?
I can't change ldap version easily, and I'd rather return to classic
master-slave setup if the problem is not fixable otherwise.
BOFH excuse #213:
Change your language to Finnish.
We have a situation where all the LDAP client OS runs with RHEL V5.7 and
LDAP Server should be in master-master configuration. We can't have the
OpenLDAP servers at RHEL V5.7 as multi master configuration is
introduced only from RHEL V6 (OpenLDAP V2.4 support).
To achieve this we decided to have OpenLDAP Servers running with RHEL V6
and have master-master configuration, retain the clients with RHEL 5.7
Do you foresee any issue in having OpenLDAP servers with V2.4 and
Clients with V2.3? Accordingly, We will be starting the pilot test this
week to see is there any issue.
We are setting up mirror mode masters with eight fairly heavily
loaded slaves (consumers).
Should they all slave from both masters?
An alternative is to slave from one, where a floating IP address is
that of "the master".
Please can anyone share their experience?
Would all slaves being consumers to two masters result in any marked
increased load on any of the servers?
Nick Urbanik http://nicku.org 808-71011 nick.urbanik(a)optusnet.com.au
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24
I disclaim, therefore I am.
I've 2 servers in MirrorMode, a part of the tree wil also be partially
replicated to 3 slaves.
Do I really need an LDAP proxy or Load balancer(s) so writes are only
directed to one server?
In our LDAP, the number of writes will be very very low, most of them will
be reads (authentication, ssh keys, puppet nodes...)
Any benefit in using 'normal' n multimaster instead of MirrorMode?
my server restarted because of power failure and corrupted the database.
Now the command:
slapcat | grep "uid=" | wc -l
displays 918 users
and the command
ldapsearch -LLL -x -h localhost -b "dc=prodemge,dc=gov,dc=br" uid | grep
"uid=" | wc -l
displays the correct number of 1520 users.
I've tested the command:
usr/sbin/slapd_db_recover -h /var/lib/ldap -c
but not solved the problem.
What can I do to try to fix it?
Adonai S. Canez
I have some special requirements for a ldap installation. I want to use
a central ldap for a group of users having access to different services.
The user should be able to set a different password for each service. I
try to keep the effort low, therefor I particularly do not want to
modify each of the services. (They all authenticate via ldap-bind.)
To archive the desired features I tried to use the following entity
The uid=alex entity is the real account. Storing the name, uid, the
master password for this account and possibly other attributes. The
"sub"-entities with cn=service* should only store the password, if it is
set to a special value.
Now the problem: It should be find the service entities if matched
against attributes of the "master" account. That means that I want to
search for (uid=alex) and want to find all the three dns mentioned above
(but only the first dn should keep the real data - I do not want to sync
all data on every change into all "sub"-entities).
What I have tried so far:
- collect-overlay: Apart from the problem, that I have to specify the
explicit master dn (it is impossible to specify some thing like
uid=*,ou=People...), the collected attributes could not be matched
with an filter during ldap search.
- rwm-overlay: I did not find a context, where I could rewrite the dn,
that is matched against a filter and I do not know if it is possible.
The searchFilterAttrDN context sounds promising, but I did not find
So what can I do, to get it working. It seems, that maybe an
ldap-backend or meta-backend proxying the requests to the local server,
could used to archive that, but I wanted to know if there is any easier
If the attributes are inherited the ldap-bind with the password fallback
could be archived in a way with the rwm-overlay:
olcRwmRewrite: rwm-rewriteEngine "on"
olcRwmRewrite: rwm-rewriteMap slapd usermap
olcRwmRewrite: rwm-rewriteContext "bindDN"
olcRwmRewrite: rwm-rewriteRule "^(cn=[^,]+),(uid=[^,]+),.*$"
olcRwmRewrite: rwm-rewriteRule "^cn=[^,]+,(uid=[^,]+),.*$"
I'm trying to configure ppolicy but It's not working when I set
pwdMaxAge and pwdWarning (I am able to login when my password is suppose
to be expired)
I tried with shadowAccount instead of PwdPolicy and It is working well.
This is my relevant setting in slapd.conf
My ldip file is:
Thanks in advance!