Hi,
when setting up a cluster with 1+x masters and 1+x slaves, is it possible to use a single cn=config replicated between all of these? Or do masters and slaves need to have different settings anyhow. I'd like not to have to manage schema information and acls in two places.
Best, Karsten
Hi,
On Mon, 16 Dec 2013, Karsten Heymann wrote:
Hi,
when setting up a cluster with 1+x masters and 1+x slaves, is it possible to use a single cn=config replicated between all of these? Or do masters and slaves need to have different settings anyhow. I'd like not to have to manage schema information and acls in two places.
as you generally tend to have slightly different settings on masters and slaves there is currently no other way byt to have separate sets of cn=config for masters and slaves.
I have been thinking about a feature request to allow per host differences in cn=config but have not yet had the time to write it up.
Greetings Christian
Christian Kratzer wrote:
Hi,
On Mon, 16 Dec 2013, Karsten Heymann wrote:
Hi,
when setting up a cluster with 1+x masters and 1+x slaves, is it possible to use a single cn=config replicated between all of these? Or do masters and slaves need to have different settings anyhow. I'd like not to have to manage schema information and acls in two places.
as you generally tend to have slightly different settings on masters and slaves there is currently no other way byt to have separate sets of cn=config for masters and slaves.
Use syncrepl suffixmassage. Read this thread. http://www.openldap.org/lists/openldap-technical/201104/msg00206.html
I have been thinking about a feature request to allow per host differences in cn=config but have not yet had the time to write it up.
Greetings Christian
Hi,
On Mon, 16 Dec 2013, Howard Chu wrote:
Christian Kratzer wrote:
Hi,
On Mon, 16 Dec 2013, Karsten Heymann wrote:
Hi,
when setting up a cluster with 1+x masters and 1+x slaves, is it possible to use a single cn=config replicated between all of these? Or do masters and slaves need to have different settings anyhow. I'd like not to have to manage schema information and acls in two places.
as you generally tend to have slightly different settings on masters and slaves there is currently no other way byt to have separate sets of cn=config for masters and slaves.
Use syncrepl suffixmassage. Read this thread. http://www.openldap.org/lists/openldap-technical/201104/msg00206.html
interesting. I never noticed that. One still has to keep full parallel copies of different cn=config variations.
I had been thinking about a schmeme of having additional attributes under cn=config that would specify to which servers they apply using their respective server URI.
Something like the following:
dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=org
dn: cn=master-subconfig,olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig objectClass: xxxServerConfig olcDatabase: mdb xxxServerConfigURI: ldap://ldap-master-1 xxxServerConfigURI: ldap://ldap-master-2 olcSyncrepl: id=1 provider=ldap://ldap-master-1 ... olcSyncrepl: id=2 provider=ldap://ldap-master-2 ... olcMirrorMode: TRUE
dn: cn=slave-subconfig,olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig objectClass: xxxServerConfig olcDatabase: mdb xxxServerConfigURI: ldap://ldap-slave1 xxxServerConfigURI: ldap://ldap-slave2 olcSyncrepl: id=1 provider=ldap://ldap-master-1 ... olcSyncrepl: id=2 provider=ldap://ldap-master-2 ... olcMirrorMode: FALSE
that would allow one put site wide shared defaults into the parent entry and group servers with differences under subentries.
Above example has the same provider specs on masters and slaves but I would like to build larger clusters where they would perhaps differ on each group of servers.
I would expect to merge shared and specific configuration on each host.
Would such a proposal be interesting as a feature request ?
Several open points would need to be solved though:
1. How to cope with the top level cn=config entry.
2. How to handle cases where for example olcDbDirectory is enforced as MUST in the schema for olcMdbConfig and we only define it in the parent entry but default it in the slaves.
That is do we need to repeat MUST attributes on every config item.
3. How to best handle backward compatibility.
...
Greetings Christian
Christian Kratzer wrote:
Hi,
On Mon, 16 Dec 2013, Howard Chu wrote:
Christian Kratzer wrote:
Hi,
On Mon, 16 Dec 2013, Karsten Heymann wrote:
Hi,
when setting up a cluster with 1+x masters and 1+x slaves, is it possible to use a single cn=config replicated between all of these? Or do masters and slaves need to have different settings anyhow. I'd like not to have to manage schema information and acls in two places.
as you generally tend to have slightly different settings on masters and slaves there is currently no other way byt to have separate sets of cn=config for masters and slaves.
Use syncrepl suffixmassage. Read this thread. http://www.openldap.org/lists/openldap-technical/201104/msg00206.html
interesting. I never noticed that. One still has to keep full parallel copies of different cn=config variations.
I had been thinking about a schmeme of having additional attributes under cn=config that would specify to which servers they apply using their respective server URI.
Something like the following:
dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=org dn: cn=master-subconfig,olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig objectClass: xxxServerConfig olcDatabase: mdb xxxServerConfigURI: ldap://ldap-master-1 xxxServerConfigURI: ldap://ldap-master-2 olcSyncrepl: id=1 provider=ldap://ldap-master-1 ... olcSyncrepl: id=2 provider=ldap://ldap-master-2 ... olcMirrorMode: TRUE dn: cn=slave-subconfig,olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig objectClass: xxxServerConfig olcDatabase: mdb xxxServerConfigURI: ldap://ldap-slave1 xxxServerConfigURI: ldap://ldap-slave2 olcSyncrepl: id=1 provider=ldap://ldap-master-1 ... olcSyncrepl: id=2 provider=ldap://ldap-master-2 ... olcMirrorMode: FALSEthat would allow one put site wide shared defaults into the parent entry and group servers with differences under subentries.
One of the changes that has been waiting in the wings for a long time is to move syncrepl config out of the olcDatabase entry and into its own olcOverlay entry. At that point a lot of config needs will make a lot more sense, and there'll be no need for gyrations of shared/merged config.
- How to best handle backward compatibility.
We've done this transition once before, changing backglue/subordinate from a database keyword into its own overlay. I don't think it will present any special problems.
Hi,
On Tue, 17 Dec 2013, Howard Chu wrote: <snipp/>
One of the changes that has been waiting in the wings for a long time is to move syncrepl config out of the olcDatabase entry and into its own olcOverlay entry. At that point a lot of config needs will make a lot more sense, and there'll be no need for gyrations of shared/merged config.
that would be most welcome together with a feature to allow specific configurations for spefific servers so that we could maintain a single cluster wide cn=config tree.
Would be nice for 2.5 ;)
Greetings Christian
Hi,
thank you all for the clarification.
2013/12/17 Christian Kratzer ck-lists@cksoft.de
Hi,
On Tue, 17 Dec 2013, Howard Chu wrote:
<snipp/>
One of the changes that has been waiting in the wings for a long time is
to move syncrepl config out of the olcDatabase entry and into its own olcOverlay entry. At that point a lot of config needs will make a lot more sense, and there'll be no need for gyrations of shared/merged config.
that would be most welcome together with a feature to allow specific configurations for spefific servers so that we could maintain a single cluster wide cn=config tree.
Would be nice for 2.5 ;)
So, for now I will maintain two copies of cn=config, but if this feature would be included sometime and I could get rid of one that would definitely be awesome.
Best wishes, Karsten
Christian Kratzer ck-lists@cksoft.de schrieb am 16.12.2013 um 21:50 in
Nachricht alpine.BSF.2.00.1312162147180.27797@pohjola.cksoft.de:
Hi,
On Mon, 16 Dec 2013, Karsten Heymann wrote:
Hi,
when setting up a cluster with 1+x masters and 1+x slaves, is it possible to use a single cn=config replicated between all of these? Or do masters and slaves need to have different settings anyhow. I'd like not to have to manage schema information and acls in two places.
as you generally tend to have slightly different settings on masters and slaves there is currently no other way byt to have separate sets of cn=config for masters and slaves.
Could one store the slave config tree somewhere outside cn=config in the master and then sync to the slaves from there (so to say multi-master that configtree between the master and the slaves' cn=config)?
Regards, Ulrich
I have been thinking about a feature request to allow per host differences in cn=config but have not yet had the time to write it up.
Greetings Christian
-- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer
openldap-technical@openldap.org
-
Christian Kratzer -
Howard Chu -
Karsten Heymann -
Ulrich Windl