Hello,
I have a problem with my ldap servers. We have a farm of 4 openldap servers that synchronizes its information from a fifth. These servers are used as user backend for our mail system.
The problem we have is that sometimes mail systems launchs searches and get 0 entries, but there are entries matching the query. In fact, if they launch the query after a few seconds, it gets the results.
My ldap servers are debian servers (etch version) with openldap 2.3.30-5 (debian version) and 1GB of memmory running in a xen VM.
These are the logs I get (these are from a script that joins the logs of the ldap server by operation). The two first gets 0 entries, but the third (launched from the same client and the same ldap user) gets 1 entry. Between the queries there were no modification operation (add, mod or del) with this entry:
Mar 24 11:01:59 canis2 conn=202855 op=43 (IP=155.54.212.199) SRCH (base=ou=Usuarios,dc=Telematica, scope=2, filter=(&(objectClass=posixAccount)(uid=lsc63903)(irisUserStatus=urn:mace:rediris.es:um.es:userstatus:correo:estado:activo)), attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass ) -> tag=101, err=0, text= , nentries=0
Mar 24 11:01:59 canis2 conn=202855 op=44 (IP=155.54.212.199) SRCH (base=ou=Usuarios,dc=Telematica, scope=2, filter=(&(objectClass=posixAccount)(uid=lsc63903)(irisUserStatus=urn:mace:rediris.es:um.es:userstatus:correo:estado:activo)), attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass ) -> tag=101, err=0, text= , nentries=0
Mar 24 11:32:10 canis2 conn=696 op=101481 (IP=) SRCH (base=ou=Usuarios,dc=Telematica, scope=2, filter=(&(objectClass=posixAccount)(uid=lsc63903)(irisUserStatus=urn:mace:rediris.es:um.es:userstatus:correo:estado:activo)), attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass ) -> tag=101, err=0, text= , nentries=1
Any idea?
If I understand correctly you have one master and 4 replicas, and you are querying the replicas. What replication method are you using? If you are using syncrepl you can look at the contextCSN to determine if the replicas are in sync. The query looks like:
ldapsearch -h server -b dir-base-dn "objectclass=*" -s base contextcsn
You will want to compare the master to the replica and if the two are in sync the values will be the same.
If you are using slurpd you would look at the slurpd.status and slurpd.replog files and compare the last time that you see in the slurpd.replog with the values you see in the slurpd.status. When everything is synced up the times should all matched.
Even though you say there where no modifications it is nice to be sure that the replicas are all in sync before you look at other causes.
Bill
--On Wednesday, March 25, 2009 01:38:18 PM +0100 "Angel L. Mateo" amateo@um.es wrote:
Hello,
I have a problem with my ldap servers. We have a farm of 4 openldap servers that synchronizes its information from a fifth. These servers are used as user backend for our mail system.
The problem we have is that sometimes mail systems launchs searches and get 0 entries, but there are entries matching the query. In fact, if they launch the query after a few seconds, it gets the results.
My ldap servers are debian servers (etch version) with openldap 2.3.30-5 (debian version) and 1GB of memmory running in a xen VM.
These are the logs I get (these are from a script that joins the logs of the ldap server by operation). The two first gets 0 entries, but the third (launched from the same client and the same ldap user) gets 1 entry. Between the queries there were no modification operation (add, mod or del) with this entry:
Mar 24 11:01:59 canis2 conn=202855 op=43 (IP=155.54.212.199) SRCH (base=ou=Usuarios,dc=Telematica, scope=2, filter=(&(objectClass=posixAccount)(uid=lsc63903)(irisUserStatus=urn:mace :rediris.es:um.es:userstatus:correo:estado:activo)), attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass ) -> tag=101, err=0, text= , nentries=0
Mar 24 11:01:59 canis2 conn=202855 op=44 (IP=155.54.212.199) SRCH (base=ou=Usuarios,dc=Telematica, scope=2, filter=(&(objectClass=posixAccount)(uid=lsc63903)(irisUserStatus=urn:mace :rediris.es:um.es:userstatus:correo:estado:activo)), attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass ) -> tag=101, err=0, text= , nentries=0
Mar 24 11:32:10 canis2 conn=696 op=101481 (IP=) SRCH (base=ou=Usuarios,dc=Telematica, scope=2, filter=(&(objectClass=posixAccount)(uid=lsc63903)(irisUserStatus=urn:mace :rediris.es:um.es:userstatus:correo:estado:activo)), attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass ) -> tag=101, err=0, text= , nentries=1
Any idea?
-- Bill MacAllister whm@stanford.edu Systems Software Programmer, ITS Unix Systems, Stanford University
El mié, 25-03-2009 a las 11:12 -0700, Bill MacAllister escribió:
If you are using slurpd you would look at the slurpd.status and slurpd.replog files and compare the last time that you see in the slurpd.replog with the values you see in the slurpd.status. When everything is synced up the times should all matched.
Even though you say there where no modifications it is nice to be sure that the replicas are all in sync before you look at other causes.
(Sorry, I forgot this detail)
I'm replicating with slurpd, but slurpd is synced and all replicas are ok. In fact, I'm having the problem with ldap entries which haven't been updated in years.
Angel L. Mateo wrote:
El mié, 25-03-2009 a las 11:12 -0700, Bill MacAllister escribió:
If you are using slurpd you would look at the slurpd.status and slurpd.replog files and compare the last time that you see in the slurpd.replog with the values you see in the slurpd.status. When everything is synced up the times should all matched.
Even though you say there where no modifications it is nice to be sure that the replicas are all in sync before you look at other causes.
(Sorry, I forgot this detail)
I'm replicating with slurpd, but slurpd is synced and all replicas are ok. In fact, I'm having the problem with ldap entries which haven't been updated in years.
Another idea: this kind of result (or lack of) could be caused by bad indexes. Try reindexing your database (take it offline, first, of course).
Jonathan Clarke jclarke@linagora.com escribió:
Another idea: this kind of result (or lack of) could be caused by bad indexes. Try reindexing your database (take it offline, first, of course).
I have already done this with no result :-( The only files I didn't rebuild was id2entry and dn2entry. Is there any way to recreate them?
openldap-software@openldap.org