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

Some openldap 2.4 questions



Hi,

Three quick issues about slapd 2.4.

1. I'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:
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
structuralObjectClass: olcSyncProvConfig
entryUUID: 600b89e6-9317-102e-9872-8714c398f98b
creatorsName: cn=admin,cn=config
createTimestamp: 20100111160900Z
entryCSN: 20100111160900.858973Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20100111160900Z

dn: olcOverlay={1}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {1}syncprov
olcSpCheckpoint: 20 10
structuralObjectClass: olcSyncProvConfig
entryUUID: 600ba142-9317-102e-9873-8714c398f98b
creatorsName: cn=admin,cn=config
createTimestamp: 20100111160900Z
entryCSN: 20100111160900.859584Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20100111160900Z

dn: olcOverlay={2}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {2}syncprov
olcSpSessionlog: 500
structuralObjectClass: olcSyncProvConfig
entryUUID: 600badea-9317-102e-9874-8714c398f98b
creatorsName: cn=admin,cn=config
createTimestamp: 20100111160900Z
entryCSN: 20100111160900.859909Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20100111160900Z

The thing is, that I cannot delete any of them because cn=config does not support delete operation.
Is this ok to leave it as is? or any workaround to get rid of the unwanted ones?

2. About N-Way replication... What'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'm assuming that the best here would be to use some SASL mech?

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...

--
Best regards,
Radosław Antoniuk