[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP instance as syncREPL replica and Slurpd master
Howard Chu wrote:
> Bruno Lezoray EMSM wrote:
>> Howard Chu wrote:
>>>>> In OpenLDAP 2.3 this will require one more slapd process (while
>>>>> eliminating the slurpd process).
>>>>>
>>>>> 1 provider
>>>>> 2 regular consumer
>>>>> 2A back-ldap consumer
>>>>> 3 external replica
>> To follow with the same restrictions:
>>
>> Only the 2nd instance can establish TCP connections on 1st and 3rd
>> instances. TCP connections in the other direction is forbidden >:o .
>
> That was obvious, given your firewall setup.
>
>> Is it possible to configure the different instances to enable
>> replication in the both direction ?
>> 1 <-> 2 <-> 3
>
> Of course, but that would be a bad idea. Think about what you're
> doing. The reason you put a *read-only* replica outside the firewall
> is because it resides on an untrusted network. If you start accepting
> changes from it, it's like punching a hole in your firewall and
> letting the outside world in.
I have a problem on the operational platform with the initial
configuration 1 -> 2 -> 3. It looks linked to the ppolicy overlay that
is available on all instances (it changes nothing if i disable it on the
instances 2 and 3).
I have the following error in the logs of the 3rd instance:
Sep 25 17:58:29 ora-sym-rec01 RR15[20537]: [ID 249368 local5.debug]
conn=0 op=166 MOD dn="ou=24458949618350,ou=partenaires,o=xxxxxxx,c=fr"
Sep 25 17:58:29 ora-sym-rec01 RR15[20537]: [ID 396994 local5.debug]
conn=0 op=166 MOD attr=objectClass ou refPartner dateCreation
structuralObjectClass entryUUID creatorsName createTimestamp
groupeFonctionnel accesApplication dateValidite description entryCSN
modifiersName modifyTimestamp hasSubordinates objectClass ou refPartner
structuralObjectClass entryUUID creatorsName createTimestamp
groupeFonctionnel dateValidite dateCreation description entryCSN
Sep 25 17:58:29 ora-sym-rec01 RR15[20537]: [ID 588225 local5.debug]
conn=0 op=166 RESULT tag=103 err=16 text=modify/delete: hasSubordinates:
no such attribute
The entry on the 3rd instance contains before the modification:
dn: ou=24458949618350,ou=partenaires,o=xxxxxxx,c=fr
structuralObjectClass: organizationalUnitPartenaireXXX
entryUUID: c79b095c-eb70-102b-8d76-f115de4b6614
creatorsName:
createTimestamp: 20070830181549Z
entryCSN: 20070913110815Z#000002#00#000000
modifiersName: cn=PBP,ou=appli,o=xxxxxxx,c=fr
modifyTimestamp: 20070913110815Z
entryDN: ou=24458949618350,ou=partenaires,o=xxxxxxx,c=fr
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE
objectClass: top
objectClass: organizationalUnit
objectClass: organizationalUnitPartenaireXXX
ou: 24458949618350
refPartner: 24458949618350
dateCreation: 20070425083800Z
groupeFonctionnel: MMBR_RES
accesApplication: bandeau
dateValidite: 20071231000000Z
description: EDC
I don't understand why it refuse to change the hasSubordinates attribute.
Any idea ?
Rgds, Bruno.