hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/tests/scripts
Modified Files: defines.sh 1.147 -> 1.148 Added Files: test049-sync-config NONE -> 1.1
Log Message: Test slave bootstrapping via syncrepl
For anyone curious, this test shows how to use back-config and syncrepl to dynamically configure and populate a server.
Two stub entries (cn=config and olcdatabase=config,cn=config) are slapadded to initialize the master and slave configurations. Then ldapadd/ldapmodify are used to load the syncprov module, add a syncrepl consumer to the config database, and add the syncprov overlay to the config database on the master.
Then ldapmodify is used to start a syncrepl consumer on the slave's config database.
The rest of the script adds schema, a database backend and content for the backend on the master, all of which get replicated to the slave.
The dilemma of how not to wipe out the consumer configuration once the complete master configuration is replicated onto it is solved with this trick: the master has both a provider and a consumer configured on it, and the consumer points at the master. The syncrepl config handler checks to see if its providerURI matches any of the current server's listenerURIs. If there's a match, the config is a no-op. (It gets parsed but no consumer task is triggered.)
Howard Chu wrote:
For anyone curious, this test shows how to use back-config and syncrepl to dynamically configure and populate a server.
Great!
Two stub entries (cn=config and olcdatabase=config,cn=config) are slapadded
I guess it would be possible to start also with a minimal slapd.conf containing just some schema and some
database config rootpw secret
or so, right? Maybe this is more intuitive, and could be tested too.
p.
Pierangelo Masarati wrote:
Howard Chu wrote:
For anyone curious, this test shows how to use back-config and syncrepl to dynamically configure and populate a server.
Great!
Two stub entries (cn=config and olcdatabase=config,cn=config) are slapadded
I guess it would be possible to start also with a minimal slapd.conf containing just some schema and some
database config rootpw secret
or so, right? Maybe this is more intuitive, and could be tested too.
If you mean, start with minimal slapd.conf, converted with -f/-F, yes that would certainly work. Starting with a slapd.conf and not converting it would be somewhat pointless, as none of the subsequent actions would be saved to any file.
Anyway, I didn't think the conversion case was very interesting, the conversion is known to always work. I wanted to test starting from a minimal LDIF because I wanted to test the creation of defaults for omitted entries (cn=schema, olcdatabase=frontend). Those entries are always automatically created for you during a conversion, so there's nothing to test there.
Howard Chu wrote:
The dilemma of how not to wipe out the consumer configuration once the complete master configuration is replicated onto it is solved with this trick: the master has both a provider and a consumer configured on it, and the consumer points at the master. The syncrepl config handler checks to see if its providerURI matches any of the current server's listenerURIs. If there's a match, the config is a no-op. (It gets parsed but no consumer task is triggered.)
It occurs to me that a more real-world approach may be to use a second DB on the provider and a modified translucent overlay that uses back-relay instead of back-ldap. E.g., create a back-ldif DB with suffix "cn=config,cn=slave" that is translucently relayed to the cn=config tree. This would allow the main config items to be passed through, but also provide the opportunity to override some settings (rootDNs, passwords, ACLs, indices) with slave-specific settings. Put a rewrite overlay on top of that to remap entry DNs from "cn=config,cn=slaves" to just "cn=config" on search replies. And then finally the syncprov overlay to actually handle the replication.
Of course, that first requires that slapo-rwm gets dynamic config support.
-
Howard Chu -
Pierangelo Masarati