Hi,<br><br>Three quick issues about slapd 2.4.<br><br>1. I&#39;m setting up a syncrepl replication. In the process of testing, I had added three syncprov overlays instead of one, and I ended up with:<br>dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config<br>

objectClass: olcOverlayConfig<br>objectClass: olcSyncProvConfig<br>olcOverlay: {0}syncprov<br>structuralObjectClass: olcSyncProvConfig<br>entryUUID: 600b89e6-9317-102e-9872-8714c398f98b<br>creatorsName: cn=admin,cn=config<br>

createTimestamp: 20100111160900Z<br>entryCSN: 20100111160900.858973Z#000000#000#000000<br>modifiersName: cn=admin,cn=config<br>modifyTimestamp: 20100111160900Z<br><br>dn: olcOverlay={1}syncprov,olcDatabase={0}config,cn=config<br>

objectClass: olcOverlayConfig<br>objectClass: olcSyncProvConfig<br>olcOverlay: {1}syncprov<br>olcSpCheckpoint: 20 10<br>structuralObjectClass: olcSyncProvConfig<br>entryUUID: 600ba142-9317-102e-9873-8714c398f98b<br>creatorsName: cn=admin,cn=config<br>

createTimestamp: 20100111160900Z<br>entryCSN: 20100111160900.859584Z#000000#000#000000<br>modifiersName: cn=admin,cn=config<br>modifyTimestamp: 20100111160900Z<br><br>dn: olcOverlay={2}syncprov,olcDatabase={0}config,cn=config<br>

objectClass: olcOverlayConfig<br>objectClass: olcSyncProvConfig<br>olcOverlay: {2}syncprov<br>olcSpSessionlog: 500<br>structuralObjectClass: olcSyncProvConfig<br>entryUUID: 600badea-9317-102e-9874-8714c398f98b<br>creatorsName: cn=admin,cn=config<br>

createTimestamp: 20100111160900Z<br>entryCSN: 20100111160900.859909Z#000000#000#000000<br>modifiersName: cn=admin,cn=config<br>modifyTimestamp: 20100111160900Z<br><br>The thing is, that I cannot delete any of them because cn=config does not support delete operation. <br>

Is this ok to leave it as is? or any workaround to get rid of the unwanted ones?<br><br>2. About N-Way replication... What&#39;s the best authentication to use? Because RootDN is the admin, and in simple authentication I would store cleartext password in the syncrepl configuration, I&#39;m assuming that the best here would be to use some SASL mech?<br>

<br>3. Assuming a running normal replication(master-slave) with refreshAndPersist, is there any method of checking of the status of the replication? like show slave status in MySQL. I have tested it with cutting the transmission by iptables, and ok, it caught up after reconnection, but the master did not complain at all when the connection was not there...<br>

<br clear="all">-- <br>Best regards,<br>Radosław Antoniuk<br><br>