We have 5 servers running OpenLDAP, 001 - 005. Server is CentOS 6.4, LDAP version is openldap-servers-2.4.23-32.el6_4.1.x86_64, current replication topology is:
001 <=> 002 001 <=> 003 001 <=> 004 001 <=> 005
001 is where the phpLDAPAdmin GUI is running on. 002 - 005 are behind a load balancer, 001 is never directly accessed from clients. I understand this makes 001 the single point of failure in terms of replication, but we would like to fix the current issues before exploring more changes.
The issue we are running is intermittent failure in replication. Replication is configured as multi-way master with mirror mode, it always works from 001 to the rest, but sometimes fails the other direction. This is particularly bad when user changes password and it doesn't get replicated to back to 001, and when that happens it doesn't get replicated to the rest of the other servers. In the log we see the following error messages sometimes, but when replication fails sometimes there is no log:
Error Log: Jan 21 10:56:42 001 slapd[27161]: do_syncrepl: rid=004 rc -2 retrying (4 retries left)
Another issue is failure on slapd service. On each of the server we have a cronjob running that basically dumps the database using slapcat once an hour. However once every 2 weeks or so we would find slapd dead right around the same time slapcat was run. There is no obvious error in ldap log, system log, or dmesg. According to the documentation it is safe to run slapcat while slapd is running, is this not true?
Below is the replication section of the configuration on 001 and 004. If someone could advise on this it would be very much appreciated.
moduleload syncprov.la serverid 1
cachesize 50000 idlcachesize 50000
syncrepl rid=002 provider=ldap://002.server.com binddn="uid=replication,ou=Services,dc=server,dc=com" bindmethod=simple credentials=******** searchbase="dc=server,dc=com" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_reqcert=never
* repeat for 003, 004, and 005 *
mirrormode true
overlay syncprov syncprov-checkpoint 1000 60 syncprov-sessionlog 100 index entryCSN,entryUUID eq
On Wed, Jan 21, 2015 at 01:30:51PM -0800, Tony S. Wu wrote:
We have 5 servers running OpenLDAP, 001 - 005. Server is CentOS 6.4, LDAP version is openldap-servers-2.4.23-32.el6_4.1.x86_64, current replication
2.4.23 is a very old version - released 2010/06/30. There have been about 750 updates to the code-base since then: http://www.openldap.org/software/release/changes.html
It is very unlikely that RedHat have incorporated all those fixes into their distro, so you will not get much help here if you continue to use their version.
Your first move should be to build OpenLDAP from current source: http://www.openldap.org/software/download/
You can easily set it to install in /usr/local or some other place of your choice to avoid over-writing the RedHat version so that you can run tests and still be able to revert if you need to.
I would advise that you use a new location to store the database, and that you load it from LDIF using slapadd. Don't try to use new code with the existing database (though it may well work as the version is similar enough).
Building from current source gives you the opportunity to switch to LMDB so you don't even need to link the Berkeley DB libraries. LMDB (database mdb) is highly recommended.
Andrew
On Thu, Jan 22, 2015 at 12:52:13PM +0000, Andrew Findlay wrote:
Your first move should be to build OpenLDAP from current source: http://www.openldap.org/software/download/
FWIW, I'm using the LTB RPMs in production on CentOS 6.5 64-bit hosts:
http://ltb-project.org/wiki/documentation/openldap-rpm
They install in a different place, so they cn go in alongside the vendor's default install. As they are in a different place, you'll need to explicitly point to your current config files/directories (-f, -F, etc.)
But, they've been solid for us.
Andrew
| From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 |
Tony,
Tony S. Wu schrieb (21.01.2015 22:30 Uhr):
We have 5 servers running OpenLDAP, 001 - 005. Server is CentOS 6.4, LDAP version is openldap-servers-2.4.23-32.el6_4.1.x86_64, current replication topology is:
001 <=> 002 001 <=> 003 001 <=> 004 001 <=> 005
001 is where the phpLDAPAdmin GUI is running on. 002 - 005 are behind a load balancer, 001 is never directly accessed from clients. I understand this makes 001 the single point of failure in terms of replication, but we would like to fix the current issues before exploring more changes.
what kind of benefit do you expect from this setup?
Marc
Hi all, I have the same problem, I'm running on OpenLDAP 2.4.39-8.el6. Sometimes the ldap server is blocked ? Can you help me i have the same ldap replication topology Thunks a lot
2015-01-22 15:45 GMT+01:00 Marc Patermann <hans.moser@ofd-z.niedersachsen.de
:
Tony,
Tony S. Wu schrieb (21.01.2015 22:30 Uhr):
We have 5 servers running OpenLDAP, 001 - 005. Server is CentOS 6.4, LDAP version is openldap-servers-2.4.23-32.el6_4.1.x86_64, current replication topology is:
001 <=> 002 001 <=> 003 001 <=> 004 001 <=> 005
001 is where the phpLDAPAdmin GUI is running on. 002 - 005 are behind a load balancer, 001 is never directly accessed from clients. I understand this makes 001 the single point of failure in terms of replication, but we would like to fix the current issues before exploring more changes.
what kind of benefit do you expect from this setup?
Marc
On Thu, Jan 22, 2015 at 03:49:52PM +0100, sofien BLOUZA wrote:
I have the same problem, I'm running on OpenLDAP 2.4.39-8.el6. Sometimes the ldap server is blocked ? Can you help me i have the same ldap replication topology
The answer is the same: you must start by updating to a current version of the OpenLDAP server. There are a lot of bugfixes so this will probably solve your problem.
You can build from source:
Or you can use the LTB RPMs:
Andrew
Andrew Findlay andrew.findlay@skills-1st.co.uk schrieb am 23.01.2015 um 15:04
in Nachricht 20150123140445.GB22805@slab.skills-1st.co.uk:
On Thu, Jan 22, 2015 at 03:49:52PM +0100, sofien BLOUZA wrote:
[...]
The answer is the same: you must start by updating to a current version of the OpenLDAP server. There are a lot of bugfixes so this will probably solve your problem.
I have a logic problem with this: If the update will only "probably" solve the problem, why "must" he update? ;-)
You can build from source:
Or you can use the LTB RPMs:
Andrew
| From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 |
On Fri, Jan 23, 2015 at 04:10:47PM +0100, Ulrich Windl wrote:
The answer is the same: you must start by updating to a current version of the OpenLDAP server. There are a lot of bugfixes so this will probably solve your problem.
I have a logic problem with this: If the update will only "probably" solve the problem, why "must" he update? ;-)
Because until he does, people on this list will assume that the problem is due to a bug that has already been fixed.
Andrew
I certainly understand the logic behind upgrading, but it’s probably not going to be possible for us because we are moving away from OpenLDAP, and management won’t dedicate additional resources to building / testing a new environment. I just need it stable enough to get us through the transition.
We have other smaller domains with only 2 controllers configured with mirror mode that aren’t having any issue. So what I really need to know is if my configuration is sound (1 replication hub to 4 other controllers), or perhaps mirrormode or refreshAndPersist has limitations, or other tuning advices.
Tony S. Wu tonyswu.mac@gmail.com
On Jan 23, 2015, at 7:10 AM, Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Andrew Findlay andrew.findlay@skills-1st.co.uk schrieb am 23.01.2015 um 15:04
in Nachricht 20150123140445.GB22805@slab.skills-1st.co.uk:
On Thu, Jan 22, 2015 at 03:49:52PM +0100, sofien BLOUZA wrote:
[...]
The answer is the same: you must start by updating to a current version of the OpenLDAP server. There are a lot of bugfixes so this will probably solve your problem.
I have a logic problem with this: If the update will only "probably" solve the problem, why "must" he update? ;-)
You can build from source:
Or you can use the LTB RPMs:
Andrew
| From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 |
Tony S. Wu wrote:
I certainly understand the logic behind upgrading, but it’s probably not going to be possible for us because we are moving away from OpenLDAP, and management won’t dedicate additional resources to building / testing a new environment. I just need it stable enough to get us through the transition.
And now you really expect volunteers here to help with your old setup in their spare time?
Ciao, Michael.
openldap-technical@openldap.org
-
Andrew Findlay -
Brian Reichert -
Marc Patermann -
Michael Ströder -
sofien BLOUZA -
Tony S. Wu -
Ulrich Windl