Hello List
I already searched the archives but did not find a clue.
I am using slapd 2.4.9 on Ubuntu Hardy. I set up two servers, one master, one slave. On the master, i have cn=config with samba schema included.
On the slave, i do a full clean install via:
rm -rf slapd.d/* slaptest -f slapd.conf.old -F slapd.d chown openldap:openldap slapd.d -R
This gives me an empty database and standard cn=config with nothing but standard build-in schema. (core, cosine, nis, inetorgperson)
Going further, i insert the syncrepl statement on the slave
ldapadd -W -x -D "cn=admin,cn=config" -f init_slave_db.ldif
---- dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcSyncRepl olcsyncrepl: {0}rid=001 provider=ldap://masterLDAP binddn="cn=replication,dc=tree" bindmethod=simple credentials=<PW> searchbase="dc=tree" type=refreshAndPersist interval=00:00:00:10 - add: olcUpdateRef olcUpdateRef: ldap://masterLDAP -----
Now, my whole LDAP dc=tree is aviable on the slave. If i now insert syncrepl for cn=schema,cn=config
ldapadd -W -x -D "cn=admin,cn=config" -f init_slave_config.ldif
------ dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: rid=002 provider=ldap://masterLDAP binddn="cn=admin,cn=config" bindmethod=simple credentials=<PW> searchbase="cn=schema,cn=config" type=refreshOnly interval=00:00:00:10 ---
When i now want to change the slave daemon loglevel by entering olcLoglevel, i get an error 53: no update referral
summing up, when i insert schema replication, i can not change anythin in cn=config on my slave - not only in cn=schema,cn=config.
Is that default behavior or do i miss something?
Any hints appreciated.
Daniel
Hell Again
Unfortunately, i still have a problem to replicate my schema with openldap 2.4.
I found one thread in the archives [1], but it did not help me much.
Can anyone give me some hints how to replicate my masster schema to the slave, but still be able to change e.g. LogLevel on my slave?
Regards
Daniel
[1]http://www.openldap.org/lists/openldap-software/200702/msg00100.html
Daniel Paufler wrote:
... Now, my whole LDAP dc=tree is aviable on the slave. If i now insert syncrepl for cn=schema,cn=config
ldapadd -W -x -D "cn=admin,cn=config" -f init_slave_config.ldif
dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: rid=002 provider=ldap://masterLDAP binddn="cn=admin,cn=config" bindmethod=simple credentials=<PW> searchbase="cn=schema,cn=config" type=refreshOnly interval=00:00:00:10
When i now want to change the slave daemon loglevel by entering olcLoglevel, i get an error 53: no update referral
summing up, when i insert schema replication, i can not change anythin in cn=config on my slave - not only in cn=schema,cn=config.
Is that default behavior or do i miss something?
Daniel Paufler wrote:
Hell Again
Unfortunately, i still have a problem to replicate my schema with openldap 2.4.
I found one thread in the archives [1], but it did not help me much.
Can anyone give me some hints how to replicate my masster schema to the slave, but still be able to change e.g. LogLevel on my slave?
Regards
Daniel
[1]http://www.openldap.org/lists/openldap-software/200702/msg00100.html
Daniel Paufler wrote:
... Now, my whole LDAP dc=tree is aviable on the slave. If i now insert syncrepl for cn=schema,cn=config
ldapadd -W -x -D "cn=admin,cn=config" -f init_slave_config.ldif
dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: rid=002 provider=ldap://masterLDAP binddn="cn=admin,cn=config" bindmethod=simple credentials=<PW> searchbase="cn=schema,cn=config" type=refreshOnly interval=00:00:00:10
When i now want to change the slave daemon loglevel by entering olcLoglevel, i get an error 53: no update referral
summing up, when i insert schema replication, i can not change anythin in cn=config on my slave - not only in cn=schema,cn=config.
How are you binding again for the loglevel change?
Hello Gavin
Gavin Henry wrote:
Unfortunately, i still have a problem to replicate my schema with openldap 2.4.
How are you binding again for the loglevel change?
I always use cn=admin,cn=config to bind to the cn=config context. Should i use a different DN?
Regards
Daniel
----- "Daniel Paufler" d.paufler@ergomedia.de wrote:
Hello Gavin
Gavin Henry wrote:
Unfortunately, i still have a problem to replicate my schema with openldap 2.4.
How are you binding again for the loglevel change?
I always use cn=admin,cn=config to bind to the cn=config context. Should i use a different DN?
What are you ACLs for this user? I think cn=config rootdn is hardcoded. I need to double check.
Hello Gavin
Gavin Henry wrote:
Gavin Henry wrote:
Unfortunately, i still have a problem to replicate my schema with openldap 2.4.
How are you binding again for the loglevel change?
I always use cn=admin,cn=config to bind to the cn=config context. Should i use a different DN?
What are you ACLs for this user? I think cn=config rootdn is hardcoded. I need to double check.
I set this user to full access before converting to cn=config.
database config rootdn "cn=admin,cn=config" rootpw <secret>
i dont have other acl related to that user yet. Before i inserted my syncrepl stuff, i was able to change everything.
I think its caused by "if you are syncrepl, refer all writes to master". Unfortunateley, i only want to sync cn=schema,cn=config and not the whole cn=config.
Regards
Daniel
Gavin Henry wrote:
----- "Daniel Paufler"d.paufler@ergomedia.de wrote:
Hello Gavin
Gavin Henry wrote:
Unfortunately, i still have a problem to replicate my schema with openldap 2.4.
How are you binding again for the loglevel change?
I always use cn=admin,cn=config to bind to the cn=config context. Should i use a different DN?
What are you ACLs for this user? I think cn=config rootdn is hardcoded. I need to double check.
That is the default value, yes, but it can be explicitly set to anything else.
The point in the original post is that ordinarily, turning a database into a replica makes it only writable by the replication agent (slurpd in older releases, or syncrepl in current releases). In order to allow other locally generated changes to the database, you have to configure mirrormode/multimaster.
Hello Howard
Howard Chu wrote:
The point in the original post is that ordinarily, turning a database into a replica makes it only writable by the replication agent (slurpd in older releases, or syncrepl in current releases). In order to allow other locally generated changes to the database, you have to configure mirrormode/multimaster.
In my original post, i only want to replicate cn=schema,cn=config. Unfortunately, my syncrepl directive is locking the whole cn=config tree / database.
The loglevel change was only an example. Another example is different indexes for different slaves (e.g. email-slave, samba-slave, ...) or maybe another hdb-backend on one of the slaves. The point is changes to cn=config wich does not relate to cn=schema,cn=config but currently needs a referal.
My question is, wether is behavior is correct or not. In my case, i only want to replicate a subtree of cn=config (e.g. cn=schema,cn=config) and not the whole cn=config. Furthermore i still want to be able to change certain things differently on my slaves. configuring mirrormode will replicate my changes to the master, right? In that case, debuging one slave will set the loglevel / indexes / whatever on the master an all other slaves. I think, thats not desirable.
Regards
Daniel
openldap-software@openldap.org
-
Daniel Paufler -
Gavin Henry -
Gavin Henry -
Howard Chu