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 replicaTo 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 <-> 3Of 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: [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: [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: [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 "*, +".
- is it possible to disable the schema checking on the replica ?
- is it possible to limit the list of attributes to updates ?