Bruno Lezoray EMSM wrote: 
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

After some investigations, it doesn't seem to be linked to ppolicy.
SyncREPL tries to delete the internal attribute hasSubordinates on the replica.
I tried to limit the attribute list with the syncrepl parameter attrs="*,entryUUID,entryCSN,contextCSN" but it's only used for looking modified entries. When it obtains the list,  it looks up each entry with the attribute list "*, +".

Few questions:
- is it possible to disable the schema checking on the replica ?
- is it possible to limit the list of attributes to updates ?

Rgds, Bruno.