[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Sync working in lab but not in production



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
>