Hello,
I try to replicate the olcAccess, olcLimits and olcDbIndex Attributes here is the Database where the olcx Attributes located on the Master ---------------- dn: olcDatabase={1}mdb,cn=config olcAccess: {0}to dn.exact="" by * read olcAccess: {1}to attr=entry,uid by anonymous auth by * break ... ----------------
I created an ldif to add there olcSyncrepl to the slave: ---------------- dn: olcDatabase={1}mdb,cn=config changetype: modify add:olcSyncrepl olcSyncrepl: rid=001 provider=ldap://ldapserver.example.net type=refreshandpersist retry="60 10 120 5" searchbase="olcDatabase={1}mdb,cn=config" attrs="olcAccess,olcLimits,olcDbIndex" bindmethod=simple binddn="cn=admin,cn=config" credentials=***** ---------------- When I try to add it to my config i always get: ---------------- root@ldapserver-02:/daten# ldapmodify -Y EXTERNAL -H ldapi:/// -f sync-config.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={1}mdb,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: Base DN "olcDatabase={1}mdb,cn=config" is not within the database naming context ----------------
Here are all dn-entries from the master: ---------------- dn: cn=config dn: cn=module{0},cn=config dn: cn=schema,cn=config dn: cn={0}core,cn=schema,cn=config dn: cn={1}cosine,cn=schema,cn=config dn: cn={2}nis,cn=schema,cn=config dn: cn={3}inetorgperson,cn=schema,cn=config dn: cn={4}kerberos,cn=schema,cn=config dn: cn={5}sshkey,cn=schema,cn=config dn: olcBackend={0}mdb,cn=config dn: olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}config,cn=config dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config dn: olcDatabase={1}mdb,cn=config dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config dn: olcOverlay={1}syncprov,olcDatabase={1}mdb,cn=config dn: olcDatabase={2}mdb,cn=config ----------------
And from the slave: ---------------- dn: cn=config dn: cn=module{0},cn=config dn: cn=schema,cn=config dn: cn={0}core,cn=schema,cn=config dn: cn={1}cosine,cn=schema,cn=config dn: cn={2}nis,cn=schema,cn=config dn: cn={3}inetorgperson,cn=schema,cn=config dn: cn={4}kerberos,cn=schema,cn=config dn: cn={5}sshkey,cn=schema,cn=config dn: olcBackend={0}mdb,cn=config dn: olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}config,cn=config dn: olcDatabase={1}mdb,cn=config ----------------
What do I have to put into the "searchbase"?
Replication of the object-DB is working. But I want the ACLs to be replicated too. Here is the ldif-file I used to set up the object-db replication --------------- dn: olcDatabase={1}mdb,cn=config changetype: modify add:olcSyncrepl olcSyncrepl: rid=000 provider=ldap://ldapserver.example.net type=refreshandpersist retry="60 10 120 5" searchbase="dc=example,dc=net" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=admin,dc=example,dc=net" credentials=***** ---------------
thank's for any help
Stefan
--On Saturday, January 4, 2020 5:35 PM +0100 Stefan Kania stefan@kania-online.de wrote:
Hello,
I try to replicate the olcAccess, olcLimits and olcDbIndex Attributes here is the Database where the olcx Attributes located on the Master
Hi Stefan,
What you're talking about is replicating the cn=config database itself, not the binary database.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hi Quanah,
I kow that there is a problem, but at the moment I don't know how to solve it, can you give me a hint about my configuration of the replication.
Stefan
Am 07.01.20 um 02:08 schrieb Quanah Gibson-Mount:
--On Saturday, January 4, 2020 5:35 PM +0100 Stefan Kania stefan@kania-online.de wrote:
Hello,
I try to replicate the olcAccess, olcLimits and olcDbIndex Attributes here is the Database where the olcx Attributes located on the Master
Hi Stefan,
What you're talking about is replicating the cn=config database itself, not the binary database.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Tuesday, January 7, 2020 12:36 PM +0100 Stefan Kania stefan@kania-online.de wrote:
Hi Quanah,
I kow that there is a problem, but at the moment I don't know how to solve it, can you give me a hint about my configuration of the replication.
The admin guide discusses how to replicate cn=config. If you have questions that are more specific in nature after reading the guide, please follow up. I would note generally what you're discussing will require full cn=config replication, which either means switching to MMR vs provider/consumer, or defining an alternate replicated config database that the replicas pull from.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Michael Ströder michael@stroeder.com schrieb am 07.01.2020 um 20:41 in
Nachricht 771d7e42-1e54-a783-92cb-e3ead597ad12@stroeder.com:
On 1/7/20 8:13 PM, Quanah Gibson-Mount wrote:
The admin guide discusses how to replicate cn=config.
Hmm, I vaguely remember that the conclusion on this list was that replicating cn=config is currently not considered reliable enough.
But it works "well enough" for many cases. I think: Let users try it, and let users decide whether it does the job.
Ciao, Michael.
On 1/13/20 11:53 AM, Ulrich Windl wrote:
Michael Ströder michael@stroeder.com schrieb am 07.01.2020 um 20:41 in
Nachricht 771d7e42-1e54-a783-92cb-e3ead597ad12@stroeder.com:
On 1/7/20 8:13 PM, Quanah Gibson-Mount wrote:
The admin guide discusses how to replicate cn=config.
Hmm, I vaguely remember that the conclusion on this list was that replicating cn=config is currently not considered reliable enough.
But it works "well enough" for many cases. I think: Let users try it, and let users decide whether it does the job.
Nobody and nothing prevents a user from trying anything and be happy with that.
But "users" have to be well aware of what they can expect to be a stable and supported configuration (after meeting prerequisites). So that they don't complain and blame others later.
E.g. in case of replicating cn=config "users" have to understand the strong dependency on stable IP addresses and or hostnames used for replicas in LDAP URL part of the serverID. Which is not really obvious to beginners.
Ciao, Michael.
Michael Ströder michael@stroeder.com schrieb am 13.01.2020 um 12:02 in
Nachricht 246dd12f-13ce-1c1d-33a8-36bf807b8231@stroeder.com:
On 1/13/20 11:53 AM, Ulrich Windl wrote:
Michael Ströder michael@stroeder.com schrieb am 07.01.2020 um 20:41
in
Nachricht 771d7e42-1e54-a783-92cb-e3ead597ad12@stroeder.com:
On 1/7/20 8:13 PM, Quanah Gibson-Mount wrote:
The admin guide discusses how to replicate cn=config.
Hmm, I vaguely remember that the conclusion on this list was that replicating cn=config is currently not considered reliable enough.
But it works "well enough" for many cases. I think: Let users try it, and
let
users decide whether it does the job.
Nobody and nothing prevents a user from trying anything and be happy with that.
But "users" have to be well aware of what they can expect to be a stable and supported configuration (after meeting prerequisites). So that they don't complain and blame others later.
E.g. in case of replicating cn=config "users" have to understand the strong dependency on stable IP addresses and or hostnames used for replicas in LDAP URL part of the serverID. Which is not really obvious to beginners.
Agreed (I'd add certificate paths, too). So I'd add such warning to the configuration guide. (If it's documented, it's a feature)
Ciao, Michael.
Thank you all for the your answers. I did it like I did it before. I put all the ACLs in the global part of the configuration and replicate just e the part with the ACLs, that works fine. I hope replication of attributes from the cn=config will work with 2.5 :-)
Stefan
Am 13.01.20 um 13:22 schrieb Ulrich Windl:
Michael Ströder michael@stroeder.com schrieb am 13.01.2020 um 12:02 in
Nachricht 246dd12f-13ce-1c1d-33a8-36bf807b8231@stroeder.com:
On 1/13/20 11:53 AM, Ulrich Windl wrote:
Michael Ströder michael@stroeder.com schrieb am 07.01.2020 um 20:41
in
Nachricht 771d7e42-1e54-a783-92cb-e3ead597ad12@stroeder.com:
On 1/7/20 8:13 PM, Quanah Gibson-Mount wrote:
The admin guide discusses how to replicate cn=config.
Hmm, I vaguely remember that the conclusion on this list was that replicating cn=config is currently not considered reliable enough.
But it works "well enough" for many cases. I think: Let users try it, and
let
users decide whether it does the job.
Nobody and nothing prevents a user from trying anything and be happy with that.
But "users" have to be well aware of what they can expect to be a stable and supported configuration (after meeting prerequisites). So that they don't complain and blame others later.
E.g. in case of replicating cn=config "users" have to understand the strong dependency on stable IP addresses and or hostnames used for replicas in LDAP URL part of the serverID. Which is not really obvious to beginners.
Agreed (I'd add certificate paths, too). So I'd add such warning to the configuration guide. (If it's documented, it's a feature)
Ciao, Michael.
--On Monday, January 13, 2020 12:02 PM +0100 Michael Ströder michael@stroeder.com wrote:
On 1/13/20 11:53 AM, Ulrich Windl wrote:
Michael Ströder michael@stroeder.com schrieb am 07.01.2020 um 20:41 in
Nachricht 771d7e42-1e54-a783-92cb-e3ead597ad12@stroeder.com:
On 1/7/20 8:13 PM, Quanah Gibson-Mount wrote:
The admin guide discusses how to replicate cn=config.
Hmm, I vaguely remember that the conclusion on this list was that replicating cn=config is currently not considered reliable enough.
But it works "well enough" for many cases. I think: Let users try it, and let users decide whether it does the job.
Nobody and nothing prevents a user from trying anything and be happy with that.
But "users" have to be well aware of what they can expect to be a stable and supported configuration (after meeting prerequisites). So that they don't complain and blame others later.
And they have to understand taht changin gsome attributes simply will break replication because of missing matching rules. Which is why I don't generally recommend using replication of cn=config until 2.5 where the matching rules were added.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Michael Ströder -
Quanah Gibson-Mount -
Stefan Kania -
Ulrich Windl