11:53 a.m.
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
12:50 p.m.
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 CK Software GmbH
Email: ck(a)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
6:09 p.m.
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
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1:56 a.m.
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 CK Software GmbH
Email: ck(a)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
2:23 a.m.
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: FALSE
that 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.
3. 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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:37 a.m.
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
--
Christian Kratzer CK Software GmbH
Email: ck(a)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
5:24 a.m.
Hi,
thank you all for the clarification.
2013/12/17 Christian Kratzer <ck-lists(a)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
1:04 a.m.
New subject: Antw: Re: Replicate cn=config between masters and slaves?
>> Christian Kratzer <ck-lists(a)cksoft.de> schrieb am
16.12.2013 um 21:50 in
Nachricht
<alpine.BSF.2.00.1312162147180.27797(a)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(a)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
3571
days inactive
3578
days old
openldap-technical@openldap.org
7 comments
4 participants
participants (4)
-
Christian Kratzer -
Howard Chu -
Karsten Heymann -
Ulrich Windl