Good morning,
I am attempting to follow the admin guide in setting up n-way multi-master replication. re: http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
I'm running OpenLDAP 2.4.7, from Buchan Milne's RPMs, DB 4.6 on CentOS 5.1.
I have setup a working directory on both nodes, then removed all data to start fresh, converting my slapd.conf to a slapd.d with slaptest.
ie, # /etc/init.d/ldap stop # rm -rf /var/lib/ldap/* # slaptest -f slapd.conf -F slapd.d # /etc/init.d/ldap start
Since I already had cn=config setup from my slapd.conf file, I skipped that part of the admin guide's instructions. I then modified the directory with the following LDIF, replacing the URI and credential values with my environment specific ones:
dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 ldap://ldapserver1 olcServerID: 2 ldap://ldapserver2
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov
dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://ldapserver2 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldap://ldapserver1 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE
I received no errors on running the modify command to add the changes from this LDIF.
I then attempted to make a change and have it replicated, very simple to start with, using the following LDIF:
dn: cn=config changetype: modify replace: olcSecurity olcSecurity: ssf=256
Once I successfully made this change on ldapserver1, I received the following errors in the logs of ldapserver2 (continuously repeating):
ldapserver2 slapd2.4[12172]: conn=15 op=0 EXT oid=1.3.6.1.4.1.1466.20037 ldapserver2 slapd2.4[12172]: conn=15 op=0 STARTTLS ldapserver2 slapd2.4[12172]: conn=15 op=0 RESULT oid= err=0 text= ldapserver2 slapd2.4[12172]: conn=15 fd=17 ACCEPT from IP=10.12.2.25:4174 (IP=0.0.0.0:389) ldapserver2 slapd2.4[12172]: conn=15 fd=17 TLS established tls_ssf=256 ssf=256 ldapserver2 slapd2.4[12172]: conn=15 op=1 BIND dn="cn=config" method=128 ldapserver2 slapd2.4[12172]: conn=15 op=1 BIND dn="cn=config" mech=SIMPLE ssf=0 ldapserver2 slapd2.4[12172]: conn=15 op=1 RESULT tag=97 err=0 text= ldapserver2 slapd2.4[12172]: conn=15 op=2 SRCH base="cn=config" scope=2 deref=0 filter="(cn=config)" ldapserver2 slapd2.4[12172]: conn=15 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= ldapserver2 slapd2.4[12172]: conn=15 op=3 UNBIND ldapserver2 slapd2.4[12172]: conn=15 fd=17 closed ldapserver2 slapd2.4[12172]: olcServerID: value #1: <olcServerID> unknown factor <80>A<C2> ldapserver2 slapd2.4[12172]: olcServerID: value #1: <olcServerID> unknown factor <D0>A<C2> ldapserver2 slapd2.4[12172]: null_callback : error code 0x50 ldapserver2 slapd2.4[12172]: syncrepl_entry: rid=002 be_modify failed (80) ldapserver2 slapd2.4[12172]: do_syncrepl: rid=002 retrying (4 retries left) ldapserver2 slapd2.4[12172]: olcServerID: value #1: <olcServerID> unknown factor ldapserver2 slapd2.4[12172]: olcServerID: value #1: <olcServerID> unknown factor ldapserver2 slapd2.4[12172]: null_callback : error code 0x50
Any idea what I may have done wrong here?
Thanks! Josh Miller, RHCE
I should add one minor correction here, as I copied from the wrong ldif, I added tls support with the following entries:
olcSyncRepl: rid=001 provider=ldap://ldapserver2 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" starttls=yes tls_reqcert=never type=refreshAndPersist tls_cacert=/etc/pki/tls/certs/cert.crt retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldap://ldapserver1 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" starttls=yes tls_reqcert=never type=refreshAndPersist tls_cacert=/etc/pki/tls/certs/cert.crt retry="5 5 300 5" timeout=1
Joshua Miller wrote:
dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://ldapserver2 binddn="cn=config"bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldap://ldapserver1 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE
Joshua Miller wrote:
Once I successfully made this change on ldapserver1, I received the following errors in the logs of ldapserver2 (continuously repeating):
ldapserver2 slapd2.4[12172]: olcServerID: value #1: <olcServerID> unknown factor <80>A<C2> ldapserver2 slapd2.4[12172]: olcServerID: value #1: <olcServerID> unknown factor <D0>A<C2> ldapserver2 slapd2.4[12172]: null_callback : error code 0x50 ldapserver2 slapd2.4[12172]: syncrepl_entry: rid=002 be_modify failed (80) ldapserver2 slapd2.4[12172]: do_syncrepl: rid=002 retrying (4 retries left) ldapserver2 slapd2.4[12172]: olcServerID: value #1: <olcServerID> unknown factor ldapserver2 slapd2.4[12172]: olcServerID: value #1: <olcServerID> unknown factor ldapserver2 slapd2.4[12172]: null_callback : error code 0x50
I should also note that the issue seems to be go away once I restart both ldap servers with the change appearing on both sides.
- Josh, RHCE
Joshua Miller wrote:
Good morning,
I am attempting to follow the admin guide in setting up n-way multi-master replication. re: http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
I'm running OpenLDAP 2.4.7, from Buchan Milne's RPMs, DB 4.6 on CentOS 5.1.
There are a couple hundred bug fixes since 2.4.7, you should try this with 2.4.9.
Hello all, At last I am managing to import everything successfully to OpenLDAP. Hoever, on a regular (possibly daily) basis I need to reimport everything, and make sure that old entries are not lingering. At the moment, to do this I am stopping OpenLDAP, deleting the database files, starting it again, and reimporting everything. I seem to be having problems with some connections lingering when the server is stopped, and it takes a while for these to time out. Is there any way I can delete the contents of the database without needing to know what is in there, using openldap commands, and without stopping and starting OpenLDAP? Thank you,
Chris
Just after writing this, I seem to have found my answer with a properly crafted ldapdelete command:
ldapdelete -x -D "cn=Manager,dc=emea,dc=corp,dc=local" -w password -r "dc=root,dc=com" However, If I try and query openldap (anonymously) while the delete is happening, the ldapdelete command starts outputting:
ldap_search: Internal (implementation specific) error (80) additional info: internal error
As well as causing my LDAP client to return errors (other than the expected "no results"). Any idea why this is happening? Do I need to do something special before I start a recursive delete to allow normal LDAP requests to still function (even if they return nothing).
Thank you,
Chris
Hello all, At last I am managing to import everything successfully to OpenLDAP. Hoever, on a regular (possibly daily) basis I need to reimport everything, and make sure that old entries are not lingering. At the moment, to do this I am stopping OpenLDAP, deleting the database files, starting it again, and reimporting everything. I seem to be having problems with some connections lingering when the server is stopped, and it takes a while for these to time out. Is there any way I can delete the contents of the database without needing to know what is in there, using openldap commands, and without stopping and starting OpenLDAP? Thank you,
Chris
Clemson, Chris (IHG) writes:
on a regular (possibly daily) basis I need to reimport everything, and make sure that old entries are not lingering. (...)
Just after writing this, I seem to have found my answer with a properly crafted ldapdelete command:
ldapdelete -x -D "cn=Manager,dc=emea,dc=corp,dc=local" -w password -r "dc=root,dc=com"
Actually that sounds like a bad solution to your problem. Instead of the search failing, your clients will receive wrong information until you've rebuilt your database. That is, they'll be told that some people or users/groups or whatever you use your directory for, do not exist in your organization.
At our site we instead run a diff-ldif script: It takes a full LDIF dump of the current and the desired database, and produces an LDIF file which can be fed to ldapmodify. There are a few scripts like that around. I could attach ours, but it's old, tailored for our site, and uses gobs of memory (for both LDIFs). Try googling for a newer one first:-)
Anyway, an alternative if you use the cn=config database is to slapadd a new database off-line and then point your running slapd's database directory at it without taking down slapd. That gives you an "atomic" update of the database. All your clients notice is a brief wait for all outstanding operations to complete before the change can take place.
It's cumbersome though, unless someone can think of a simpler way:
Preparation:
- Put 'database config' in slapd.conf and a rootpw for it. It has default rootdn cn=config. See man slapd-config.
- If you have a DB_CONFIG file (you should), you may want to copy its contents to dbconfig directives in slapd.conf. That way you won't need to copy the DB_CONFIG file around when you create a new database directory.
- Create a cn=config directory with slapd -f slapd.conf file -F config directory. From now on start slapd with that -F instead of -f slapd.conf. (Or if you prefer slapd.conf you can make its database 'directory' directive refer to a symlink which you must keep updated to refer to the correct directory, or something like that.)
Replacing database contents:
- Make a new database directory where you'll build your new database. Copy DB_CONFIG if you didn't put it in dbconfig directives as above.
- Make a copy of your configuration, and modify it to use the new database directory. Make sure it won't touch the running slapd's data, and that it won't do any replication or other magic.
- slapadd -F new-config -l new-data.ldif. Or if you are using overlays which you want to take effect while adding data: Start another slapd with arguments -F new-config -h ldapi://<URL-escaped private socket file for that slapd>. ldapadd -H <same ldapi URL> -f new-data.ldif. Then stop that slapd.
- Finally you can ldapmodify attribute olcDbDirectory of entry olcDatabase={1}bdb,cn=config (assuming it's the first database) so it refers to your new database directory. slapd closes the old database and opens the new one. If using slapd.conf, update the directory symlink as mentioned above.
openldap-technical@openldap.org
-
Clemson, Chris (IHG) -
Hallvard B Furuseth -
Howard Chu -
Josh Miller -
Joshua Miller