I suspect I've broken a fundamental rule of how sync works on OpenLDAP but here goes ...
We've been running a single OpenLDAP server for a while now so I wanted to get some resiliency into place. We are using version 2.4.28 on Ubuntu 12.04.
The original machine is a VM so I cloned it and built two further servers from that clone. I then followed the instructions in https://help.ubuntu.com/12.04/serverguide/openldap-server.html to add the provider bits to server A and the consumer bits to server B.
That works fine.
So, since I had a working consumer, I added the provider bits to the original LDAP server and changed the configuration on server B so that it queries that server and not server A. Syncing now fails and I'm getting the following in the log:
slapd[8201]: conn=1059 fd=18 ACCEPT from IP=127.0.0.1:52374 (IP=0.0.0.0:389) slapd[8201]: conn=1059 op=0 BIND dn="cn=XXX,dc=YYY,dc=ZZZ" method=128 slapd[8201]: conn=1059 op=0 BIND dn="cn=XXX,dc=YYY,dc=ZZZ" mech=SIMPLE ssf=0 slapd[8201]: conn=1059 op=0 RESULT tag=97 err=0 text= slapd[8201]: conn=1059 op=1 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(?objectClass=auditWriteObject)(?reqResult=0))" slapd[8201]: conn=1059 op=1 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN slapd[8201]: conn=1059 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text= slapd[8201]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT (32) No such object slapd[8201]: do_syncrep2: rid=000 (32) No such object slapd[8201]: conn=1059 op=2 UNBIND
I've double-checked the configuration on the provider and if I revert the configuration on server B so that it consumes from server A, it all works again.
Have I broken a fundamental rule? If I have, how can I fix it? If I haven't, what have I done wrong?
Thanks.
Philip
Le 05/12/2013 14:38, Philip Colmer a écrit :
I suspect I've broken a fundamental rule of how sync works on OpenLDAP but here goes ...
We've been running a single OpenLDAP server for a while now so I wanted to get some resiliency into place. We are using version 2.4.28 on Ubuntu 12.04.
The original machine is a VM so I cloned it and built two further servers from that clone. I then followed the instructions in https://help.ubuntu.com/12.04/serverguide/openldap-server.html to add the provider bits to server A and the consumer bits to server B.
That works fine.
So, since I had a working consumer, I added the provider bits to the original LDAP server and changed the configuration on server B so that it queries that server and not server A. Syncing now fails and I'm getting the following in the log:
slapd[8201]: conn=1059 fd=18 ACCEPT from IP=127.0.0.1:52374 (IP=0.0.0.0:389) slapd[8201]: conn=1059 op=0 BIND dn="cn=XXX,dc=YYY,dc=ZZZ" method=128 slapd[8201]: conn=1059 op=0 BIND dn="cn=XXX,dc=YYY,dc=ZZZ" mech=SIMPLE ssf=0 slapd[8201]: conn=1059 op=0 RESULT tag=97 err=0 text= slapd[8201]: conn=1059 op=1 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(?objectClass=auditWriteObject)(?reqResult=0))" slapd[8201]: conn=1059 op=1 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN slapd[8201]: conn=1059 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text= slapd[8201]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT (32) No such object slapd[8201]: do_syncrep2: rid=000 (32) No such object slapd[8201]: conn=1059 op=2 UNBIND
I've double-checked the configuration on the provider and if I revert the configuration on server B so that it consumes from server A, it all works again.
Have I broken a fundamental rule? If I have, how can I fix it? If I haven't, what have I done wrong?
Thanks.
Philip
Hi,
The "IP=127.0.0.1" in the first log line make me thinks your server is asking itself for the accesslog, which means it thinks it is the provider. As you have cloned the original server (which is aimed to be the provider), wouldn't you have some line in your /etc/hosts on server B that resolves your_provider_dns_name to 127.0.0.1 ? That would explain why it works when configured to ask server A (it resolve to the real IP of server A), and not when configured to ask to your original server (it resolve its dns_name as itself : 127.0.0.1).
Just a guess...
Regards,
Well spotted. It was indeed in the hosts file and I didn't spot that during testing because I was using nslookup to check IP addresses.
Thanks.
Philip
On 5 December 2013 15:50, Yann Cézard yann.cezard@univ-pau.fr wrote:
Le 05/12/2013 14:38, Philip Colmer a écrit :
I suspect I've broken a fundamental rule of how sync works on OpenLDAP but here goes ...
We've been running a single OpenLDAP server for a while now so I wanted to get some resiliency into place. We are using version 2.4.28 on Ubuntu 12.04.
The original machine is a VM so I cloned it and built two further servers from that clone. I then followed the instructions in https://help.ubuntu.com/12.04/serverguide/openldap-server.html to add the provider bits to server A and the consumer bits to server B.
That works fine.
So, since I had a working consumer, I added the provider bits to the original LDAP server and changed the configuration on server B so that it queries that server and not server A. Syncing now fails and I'm getting the following in the log:
slapd[8201]: conn=1059 fd=18 ACCEPT from IP=127.0.0.1:52374 (IP=0.0.0.0:389) slapd[8201]: conn=1059 op=0 BIND dn="cn=XXX,dc=YYY,dc=ZZZ" method=128 slapd[8201]: conn=1059 op=0 BIND dn="cn=XXX,dc=YYY,dc=ZZZ" mech=SIMPLE ssf=0 slapd[8201]: conn=1059 op=0 RESULT tag=97 err=0 text= slapd[8201]: conn=1059 op=1 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(?objectClass=auditWriteObject)(?reqResult=0))" slapd[8201]: conn=1059 op=1 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN slapd[8201]: conn=1059 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text= slapd[8201]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT (32) No such object slapd[8201]: do_syncrep2: rid=000 (32) No such object slapd[8201]: conn=1059 op=2 UNBIND
I've double-checked the configuration on the provider and if I revert the configuration on server B so that it consumes from server A, it all works again.
Have I broken a fundamental rule? If I have, how can I fix it? If I haven't, what have I done wrong?
Thanks.
Philip
Hi,
The "IP=127.0.0.1" in the first log line make me thinks your server is asking itself for the accesslog, which means it thinks it is the provider. As you have cloned the original server (which is aimed to be the provider), wouldn't you have some line in your /etc/hosts on server B that resolves your_provider_dns_name to 127.0.0.1 ? That would explain why it works when configured to ask server A (it resolve to the real IP of server A), and not when configured to ask to your original server (it resolve its dns_name as itself : 127.0.0.1).
Just a guess...
Regards,
-- Yann Cézard - administrateur systèmes serveurs Centre de ressources informatiques - http://cri.univ-pau.fr Université de Pau et des pays de l'Adour - http://www.univ-pau.fr bâtiment d'Alembert (anciennement IFR), rue Jules Ferry, 64000 Pau Téléphone : +33 (0)5 59 40 77 94
--On Thursday, December 05, 2013 1:38 PM +0000 Philip Colmer philip.colmer@linaro.org wrote:
I suspect I've broken a fundamental rule of how sync works on OpenLDAP but here goes ...
We've been running a single OpenLDAP server for a while now so I wanted to get some resiliency into place. We are using version 2.4.28 on Ubuntu 12.04.
Big mistake, as mentioned numerous times on the list. Use a current build.
Your log indicates that there is no accesslog DB, so I'd start with investigating there after you fix the first problem.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org