Hi to all,
is it now save to use mmr of cn=config with OpenLDAP 2.6? I got it running with 4 server. I'm installing all 4 server with Ansible so I created a basic configuration: ------------------ dn: cn=config objectClass: olcGlobal cn: config olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/symas/run/slapd.pid olcArgsFile: /var/symas/run/slapd.args olcToolThreads: 1 olcServerID: 4
dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema
# Read all needed schema from variable in default/main.yml include: file:///opt/symas/etc/openldap/schema/core.ldif include: file:///opt/symas/etc/openldap/schema/cosine.ldif include: file:///opt/symas/etc/openldap/schema/nis.ldif include: file:///opt/symas/etc/openldap/schema/inetorgperson.ldif include: file:///opt/symas/etc/openldap/schema/dyngroup.ldif include: file:///opt/symas/etc/openldap/schema/kerberos.openldap.ldif
# Read all modules from variable in default/main.yml dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /opt/symas/lib/openldap olcModuleLoad: back_mdb olcModuleLoad: back_monitor olcModuleLoad: autoca.la olcModuleLoad: otp.la olcModuleLoad: argon2.la olcModuleLoad: syncprov olcModuleLoad: back_monitor olcModuleLoad: accesslog.la
dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcSizeLimit: 500 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to dn="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcPasswordHash: {ARGON2}
dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig olcBackend: {0}mdb
dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by * break
dn: olcDatabase={1}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to dn.subtree="cn=monitor" by dn.exact=cn=admin,cn=config read by dn.exact=cn=admin,dc=example,dc=net read
dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcmdbConfig olcDatabase: {2}mdb olcSuffix: dc=example,dc=net olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcSizeLimit: unlimited olcTimeLimit: unlimited olcDbCheckpoint: 512 30 olcDbDirectory: /var/symas/openldap-data olcDbIndex: default eq olcDbIndex: objectClass olcDbIndex: entryUUID olcDbIndex: entryCSN olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: mail pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbIndex: description pres,eq,sub olcDbIndex: title pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbMaxSize: 85899345920 olcAccess: {0} to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcAccess: {3} to attrs=userPassword by anonymous auth by self write by * none olcLimits: {0} dn.exact="uid=repl-user,ou=users,dc=example,dc=net" time=unlimited size=unlimited olcLimits: {1} dn.exact="uid=ldap-admin,ou=users,dc=example,dc=net" time=unlimited size=unlimited
------------------ The "ServerID" is different for every server, every thing else is identical.
Then I created a file to change the serverID: ------------------ dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 ldap://ldap01.example.net olcServerID: 2 ldap://ldap02.example.net olcServerID: 3 ldap://ldap03.example.net olcServerID: 4 ldap://ldap04.example.net ------------------
and a file to configure the replication: ------------------ dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov
dn: olcDatabase={0}config,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=1 provider=ldap://ldap01.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes olcSyncRepl: rid=2 provider=ldap://ldap02.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes olcSyncRepl: rid=3 provider=ldap://ldap03.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes olcSyncRepl: rid=4 provider=ldap://ldap04.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes - add: olcMirrorMode olcMirrorMode: TRUE ------------------
When I configure the server via Ansible (everything in one playbook) the replication of cn=config is not working. When I only do the basic configuration via Ansible and then add the change of serverID and then the replication of cn=config step by step on every single server: ------------- ldapmodify -Y EXTERNAL -H ldapi:/// -f serverid.ldif ldapmodify -Y EXTERNAL -H ldapi:/// -f repl_config.ldif ------------- everything is fine. The two files "serverid.ldif" and "repl_config.ldif" are the files Ansible created, so the content of the file is the same.
Can it be, that the problem is because Ansible first sets all the ServerIDs on all servers and then configure the replication of cn=config on all servers?
For setting up the configuration I took: https://www.openldap.org/devel/admin/replication.html Starting at 18.3.3
What I don't understand: Do I realy have to put all Servers in the replication, even the server it self? So do I realy have to add on Server-01, the Server "server-01, server-02, server-03 ,server-04" to the replication? Dosn't it mean that server-01 is replicating to it self? If it's correct, can someone explain why? O did I understud something wrong on the webpage?
Stefan
--On Tuesday, December 7, 2021 4:52 PM +0100 Stefan Kania stefan@kania-online.de wrote:
Hi to all,
is it now save to use mmr of cn=config with OpenLDAP 2.6? I got it running with 4 server.
Can it be, that the problem is because Ansible first sets all the ServerIDs on all servers and then configure the replication of cn=config on all servers?
The documentation clearly states that for cn=config replication, the serverID must be in # URI format.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
The documentation clearly states that for cn=config replication, the serverID must be in # URI format.
olcServerID: 1 ldap://ldap01.example.net olcServerID: 2 ldap://ldap02.example.net olcServerID: 3 ldap://ldap03.example.net olcServerID: 4 ldap://ldap04.example.net
It's URI format or not?
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Tuesday, December 7, 2021 7:15 PM +0100 Stefan Kania stefan@kania-online.de wrote:
The documentation clearly states that for cn=config replication, the serverID must be in # URI format.
olcServerID: 1 ldap://ldap01.example.net olcServerID: 2 ldap://ldap02.example.net olcServerID: 3 ldap://ldap03.example.net olcServerID: 4 ldap://ldap04.example.net
It's URI format or not?
It is, but that's from a MOD. The configs don't start *out* that way.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Am 07.12.21 um 20:47 schrieb Quanah Gibson-Mount:
--On Tuesday, December 7, 2021 7:15 PM +0100 Stefan Kania stefan@kania-online.de wrote:
The documentation clearly states that for cn=config replication, the serverID must be in # URI format.
olcServerID: 1 ldap://ldap01.example.net olcServerID: 2 ldap://ldap02.example.net olcServerID: 3 ldap://ldap03.example.net olcServerID: 4 ldap://ldap04.example.net
It's URI format or not?
It is, but that's from a MOD. The configs don't start *out* that way.
--Quanah
Quanah you aked: What does the test suite do?
Can I use the test suit in some way with the symas packages, or do I need to compile openldap to get the test suit? At the end I would like to use the symas-packages.
Stefan
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Thursday, December 9, 2021 2:10 PM +0100 Stefan Kania stefan@kania-online.de wrote:
Quanah you aked: What does the test suite do?
Can I use the test suit in some way with the symas packages, or do I need to compile openldap to get the test suit? At the end I would like to use the symas-packages.
No, the symas packages do not include the test suite. However, cn=config replication is tested in the test suite, both with syncrepl and delta-syncrepl, and passes.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
The problem is solved, in my configuration I wrote: ---------------- dn: olcDatabase={2}mdb,cn=config objectClass: olcmdbConfig ---------------- but with 2.6 ldapmodify is looking for: objectClass: olcMdbConfig
so it must be a capital "M". With a small "m" you will get "err=53" "server unwilling to perform"
@Quanah: In your blog about mmr it's also with a small "m", maybe you can change it.
Am 07.12.21 um 16:52 schrieb Stefan Kania:
Hi to all,
is it now save to use mmr of cn=config with OpenLDAP 2.6? I got it running with 4 server. I'm installing all 4 server with Ansible so I created a basic configuration:
dn: cn=config objectClass: olcGlobal cn: config olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/symas/run/slapd.pid olcArgsFile: /var/symas/run/slapd.args olcToolThreads: 1 olcServerID: 4
dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema
# Read all needed schema from variable in default/main.yml include: file:///opt/symas/etc/openldap/schema/core.ldif include: file:///opt/symas/etc/openldap/schema/cosine.ldif include: file:///opt/symas/etc/openldap/schema/nis.ldif include: file:///opt/symas/etc/openldap/schema/inetorgperson.ldif include: file:///opt/symas/etc/openldap/schema/dyngroup.ldif include: file:///opt/symas/etc/openldap/schema/kerberos.openldap.ldif
# Read all modules from variable in default/main.yml dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /opt/symas/lib/openldap olcModuleLoad: back_mdb olcModuleLoad: back_monitor olcModuleLoad: autoca.la olcModuleLoad: otp.la olcModuleLoad: argon2.la olcModuleLoad: syncprov olcModuleLoad: back_monitor olcModuleLoad: accesslog.la
dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcSizeLimit: 500 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to dn="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcPasswordHash: {ARGON2}
dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig olcBackend: {0}mdb
dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by * break
dn: olcDatabase={1}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to dn.subtree="cn=monitor" by dn.exact=cn=admin,cn=config read by dn.exact=cn=admin,dc=example,dc=net read
dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcmdbConfig olcDatabase: {2}mdb olcSuffix: dc=example,dc=net olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcSizeLimit: unlimited olcTimeLimit: unlimited olcDbCheckpoint: 512 30 olcDbDirectory: /var/symas/openldap-data olcDbIndex: default eq olcDbIndex: objectClass olcDbIndex: entryUUID olcDbIndex: entryCSN olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: mail pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbIndex: description pres,eq,sub olcDbIndex: title pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbMaxSize: 85899345920 olcAccess: {0} to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcAccess: {3} to attrs=userPassword by anonymous auth by self write by * none olcLimits: {0} dn.exact="uid=repl-user,ou=users,dc=example,dc=net" time=unlimited size=unlimited olcLimits: {1} dn.exact="uid=ldap-admin,ou=users,dc=example,dc=net" time=unlimited size=unlimited
The "ServerID" is different for every server, every thing else is identical.
Then I created a file to change the serverID:
dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 ldap://ldap01.example.net olcServerID: 2 ldap://ldap02.example.net olcServerID: 3 ldap://ldap03.example.net olcServerID: 4 ldap://ldap04.example.net
and a file to configure the replication:
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov
dn: olcDatabase={0}config,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=1 provider=ldap://ldap01.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes olcSyncRepl: rid=2 provider=ldap://ldap02.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes olcSyncRepl: rid=3 provider=ldap://ldap03.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes olcSyncRepl: rid=4 provider=ldap://ldap04.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes
add: olcMirrorMode olcMirrorMode: TRUE
When I configure the server via Ansible (everything in one playbook) the replication of cn=config is not working. When I only do the basic configuration via Ansible and then add the change of serverID and then the replication of cn=config step by step on every single server:
ldapmodify -Y EXTERNAL -H ldapi:/// -f serverid.ldif ldapmodify -Y EXTERNAL -H ldapi:/// -f repl_config.ldif
everything is fine. The two files "serverid.ldif" and "repl_config.ldif" are the files Ansible created, so the content of the file is the same.
Can it be, that the problem is because Ansible first sets all the ServerIDs on all servers and then configure the replication of cn=config on all servers?
For setting up the configuration I took: https://www.openldap.org/devel/admin/replication.html Starting at 18.3.3
What I don't understand: Do I realy have to put all Servers in the replication, even the server it self? So do I realy have to add on Server-01, the Server "server-01, server-02, server-03 ,server-04" to the replication? Dosn't it mean that server-01 is replicating to it self? If it's correct, can someone explain why? O did I understud something wrong on the webpage?
Stefan
--On Monday, January 10, 2022 5:02 PM +0100 Stefan Kania stefan@kania-online.de wrote:
The problem is solved, in my configuration I wrote:
dn: olcDatabase={2}mdb,cn=config objectClass: olcmdbConfig
but with 2.6 ldapmodify is looking for: objectClass: olcMdbConfig
so it must be a capital "M". With a small "m" you will get "err=53" "server unwilling to perform"
@Quanah: In your blog about mmr it's also with a small "m", maybe you can change it.
The fact that OpenLDAP is treating them as different values is a bug and actively being worked on. And why the issue you filed has not been closed out. ;)
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Monday, January 10, 2022 5:46 PM +0100 Stefan Kania stefan@kania-online.de wrote:
Am 10.01.22 um 17:13 schrieb Quanah Gibson-Mount:
And why the issue you filed has not been closed out.
As RESOLVED and ??? FIXED is not right so which status should I choose?
Hi Stefan,
You should leave the bug status alone, the development team will track it through the stages.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Am 10.01.22 um 17:54 schrieb Quanah Gibson-Mount:
--On Monday, January 10, 2022 5:46 PM +0100 Stefan Kania stefan@kania-online.de wrote:
Am 10.01.22 um 17:13 schrieb Quanah Gibson-Mount:
And why the issue you filed has not been closed out.
As RESOLVED and ??? FIXED is not right so which status should I choose?
Hi Stefan,
You should leave the bug status alone, the development team will track it through the stages.
Ok, so what should I do? Only write what I did to make it work?
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Monday, January 10, 2022 6:02 PM +0100 Stefan Kania stefan@kania-online.de wrote:
Am 10.01.22 um 17:54 schrieb Quanah Gibson-Mount:
--On Monday, January 10, 2022 5:46 PM +0100 Stefan Kania stefan@kania-online.de wrote:
Am 10.01.22 um 17:13 schrieb Quanah Gibson-Mount:
And why the issue you filed has not been closed out.
As RESOLVED and ??? FIXED is not right so which status should I choose?
Hi Stefan,
You should leave the bug status alone, the development team will track it through the stages.
Ok, so what should I do? Only write what I did to make it work?
There is nothing further for you to do at this time. ;) It's been reproduced by the developers and they are working on a fix. If you want to test the fix once it's available, that would be great.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com schrieb am 10.01.2022 um 17:13 in
Nachricht <EFFA4EF447F3AF5F486AF7F3@[192.168.1.14]>:
‑‑On Monday, January 10, 2022 5:02 PM +0100 Stefan Kania <stefan@kania‑online.de> wrote:
The problem is solved, in my configuration I wrote: ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ dn: olcDatabase={2}mdb,cn=config objectClass: olcmdbConfig ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ but with 2.6 ldapmodify is looking for: objectClass: olcMdbConfig
so it must be a capital "M". With a small "m" you will get "err=53" "server unwilling to perform"
@Quanah: In your blog about mmr it's also with a small "m", maybe you can change it.
The fact that OpenLDAP is treating them as different values is a bug and actively being worked on. And why the issue you filed has not been closed out. ;)
But maybe still the examples should contain the correct CamelCase as the words are harder to read otherwise (olcmdbconfig).
‑‑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
-
Quanah Gibson-Mount -
Stefan Kania -
Ulrich Windl