Hi!
I wonder whether there is a summary of additional checks that may prevent 2.4.41 from starting in a 2.4.26 MMR configuration (What I did was upgrading SLES11 SP4 to SLES12 SP3). What I found out is:
1) olcServerID does not longer accept fifferent URIs mapping to the same ID, like here (" slapd[3299]: olcServerID: value #1: <olcServerID> multiple server ID URLs matched, only one is allowed 1"): olcServerID: 1 ldap://host.domain.org:389 olcServerID: 1 ldaps://host.domain.org:636 (The idea was that whatever URI is used to contact the server, the server ID is the same) As we do not actually use ldaps for replication that second line could be dropped easily
2) After fixing the first problem, I get another one: "5bd06634 <= str2entry: str2ad(olcAccessLogDB): attribute type undefined". The schema files seem to be the same, and the manual page slapo-accesslog also seems to be the same.
Any instructions fixing all the issues that may prevent 2.4.41 from starting up? (please no comments on "2.4.41 is obsolete" unless exactly these problems were fixed in a later version) I'm continuing with BDB, BTW, and also please no comments on "MDB is better", please.
Regards, Ulrich
For issue 2):
# slapcat -n0 -F /etc/openldap/slapd.d -l /tmp/0.ldif 5bd1a671 UNKNOWN attributeDescription "OLCACCESSLOGDB" inserted. 5bd1a671 UNKNOWN attributeDescription "OLCACCESSLOGOPS" inserted. 5bd1a671 UNKNOWN attributeDescription "OLCACCESSLOGPURGE" inserted. 5bd1a671 UNKNOWN attributeDescription "OLCACCESSLOGSUCCESS" inserted. 5bd1a671 UNKNOWN attributeDescription "OLCACCESSLOGOLD" inserted. 5bd1a671 config error processing olcOverlay={1}accesslog,olcDatabase={0}config,cn=config: slapcat: bad configuration directory!
Ich bin ein gutes Stück weitergekommen, was Ihre Suche deutlich einschränken sollte: SLES11SP4: rksaph03:~ # strings /usr/lib/openldap/slapd | grep AccessLogDB ( OLcfgOvOc:4.1 NAME 'olcAccessLogConfig' DESC 'Access log configuration' SUP olcOverlayConfig MUST olcAccessLogDB MAY ( olcAccessLogOps $ olcAccessLogPurge $ olcAccessLogSuccess $ olcAccessLogOld $ olcAccessLogOldAttr $ olcAccessLogBase ) ) ( OLcfgOvAt:4.1 NAME 'olcAccessLogDB' DESC 'Suffix of database for log content' SUP distinguishedName SINGLE-VALUE )
SLES12SP3: rksapv07:/etc/openldap/slapd.d # strings /usr/lib/openldap/slapd | grep AccessLogDB #nix!
Vermutlich ist das Modul in SLES12 SP4 nicht mehr enthalten! Ich habe auch kein entsprechendes Modul zum Nachinstallieren gefunden.
Können Sie das Problem an die Entwicklung eskalieren?
Mit freundlichen Grüßen Ulrich Windl
Ulrich Windl schrieb am 25.10.2018 um 08:59 in Nachricht <5BD169CB.6FC :
161 : 60728>:
Hi!
I wonder whether there is a summary of additional checks that may prevent 2.4.41 from starting in a 2.4.26 MMR configuration (What I did was upgrading
SLES11 SP4 to SLES12 SP3). What I found out is:
- olcServerID does not longer accept fifferent URIs mapping to the same ID,
like here (" slapd[3299]: olcServerID: value #1: <olcServerID> multiple
server
ID URLs matched, only one is allowed 1"): olcServerID: 1 ldap://host.domain.org:389 olcServerID: 1 ldaps://host.domain.org:636 (The idea was that whatever URI is used to contact the server, the server ID
is the same) As we do not actually use ldaps for replication that second line could be dropped easily
- After fixing the first problem, I get another one: "5bd06634 <=
str2entry:
str2ad(olcAccessLogDB): attribute type undefined". The schema files seem to
be the same, and the manual page slapo-accesslog also seems to be the same.
Any instructions fixing all the issues that may prevent 2.4.41 from starting
up? (please no comments on "2.4.41 is obsolete" unless exactly these problems were fixed in a later version) I'm continuing with BDB, BTW, and also please no comments on "MDB is better", please.
Regards, Ulrich
"Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de schrieb am 25.10.2018 um
14:12 in Nachricht 5BD1B342020000A10002DC15@gwsmtp1.uni-regensburg.de:
For issue 2):
Sorry: I had mixed pasting the contents in two different messages composed concurrently on the same subject -- please ignore!
On 10/25/18 2:12 PM, Ulrich Windl wrote:
For issue 2):
# slapcat -n0 -F /etc/openldap/slapd.d -l /tmp/0.ldif 5bd1a671 UNKNOWN attributeDescription "OLCACCESSLOGDB" inserted. 5bd1a671 UNKNOWN attributeDescription "OLCACCESSLOGOPS" inserted. 5bd1a671 UNKNOWN attributeDescription "OLCACCESSLOGPURGE" inserted. 5bd1a671 UNKNOWN attributeDescription "OLCACCESSLOGSUCCESS" inserted. 5bd1a671 UNKNOWN attributeDescription "OLCACCESSLOGOLD" inserted. 5bd1a671 config error processing olcOverlay={1}accesslog,olcDatabase={0}config,cn=config: slapcat: bad configuration directory!
I suspect slapo-accesslog is not loaded.
Please compare the output of '/usr/sbin/slapd -VVV' of both installations. The command lists statically linked modules.
Vermutlich ist das Modul in SLES12 SP4 nicht mehr enthalten! Ich habe auch kein entsprechendes Modul zum Nachinstallieren gefunden.
slapo-accesslog is probably not statically linked anymore but is likely dynamically loadable.
On my system (openSUSE Tumbleweed):
$ rpm -ql openldap2|grep accesslog /usr/lib64/openldap/accesslog-2.4.so.2 /usr/lib64/openldap/accesslog-2.4.so.2.10.9 /usr/lib64/openldap/accesslog.la /usr/lib64/openldap/accesslog.so /usr/share/man/man5/slapo-accesslog.5.gz
Adding "accesslog" to attribute 'olcModuleLoad' in entry cn=module{0},cn=config should fix that. Depending on your config this applies to some other backend and overlay modules as well.
Ciao, Michael.
Michael Ströder michael@stroeder.com schrieb am 25.10.2018 um 16:08 in
Nachricht dcb21c52-3112-3a8e-ade6-16c7c573ceb6@stroeder.com:
On 10/25/18 2:12 PM, Ulrich Windl wrote:
For issue 2):
# slapcat -n0 -F /etc/openldap/slapd.d -l /tmp/0.ldif 5bd1a671 UNKNOWN attributeDescription "OLCACCESSLOGDB" inserted. 5bd1a671 UNKNOWN attributeDescription "OLCACCESSLOGOPS" inserted. 5bd1a671 UNKNOWN attributeDescription "OLCACCESSLOGPURGE" inserted. 5bd1a671 UNKNOWN attributeDescription "OLCACCESSLOGSUCCESS" inserted. 5bd1a671 UNKNOWN attributeDescription "OLCACCESSLOGOLD" inserted. 5bd1a671 config error processing olcOverlay={1}accesslog,olcDatabase={0}config,cn=config: slapcat: bad configuration directory!
I suspect slapo-accesslog is not loaded.
This is correct. In addition to the version change, SUSE had changed the packing of openldap: The older version had accesslog compiled in, while the newer version has a loadable module (AFAIK).
Regards, Ulrich
On 10/25/18 8:59 AM, Ulrich Windl wrote:
As we do not actually use ldaps for replication that second line could be dropped easily
As a side note:
You should really use LDAPS or LDAP with StartTLS ext.op. for replication. Otherwise a MITM attacker could trick a replica into delivering false data to clients.
Are you using StartTLS in syncrepl statement?
Ciao, Michael.
Michael Ströder michael@stroeder.com schrieb am 25.10.2018 um 16:11 in
Nachricht 5ddb70fe-958b-2913-2426-0a7db4a9ef6d@stroeder.com:
On 10/25/18 8:59 AM, Ulrich Windl wrote:
As we do not actually use ldaps for replication that second line could be
dropped easily
As a side note:
You should really use LDAPS or LDAP with StartTLS ext.op. for replication. Otherwise a MITM attacker could trick a replica into delivering false data to clients.
Are you using StartTLS in syncrepl statement?
Ciao, Michael.
Hi!
Thanks for the "heads up"; fortunately I have "starttls=critical" for each syncrepl ;-)
Regards, Ulrich
--On Thursday, October 25, 2018 9:59 AM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Hi!
I wonder whether there is a summary of additional checks that may prevent 2.4.41 from starting in a 2.4.26 MMR configuration (What I did was upgrading SLES11 SP4 to SLES12 SP3). What I found out is:
- olcServerID does not longer accept fifferent URIs mapping to the same
ID, like here (" slapd[3299]: olcServerID: value #1: <olcServerID> multiple server ID URLs matched, only one is allowed 1"): olcServerID: 1 ldap://host.domain.org:389 olcServerID: 1 ldaps://host.domain.org:636 (The idea was that whatever URI is used to contact the server, the server ID is the same) As we do not actually use ldaps for replication that second line could be dropped easily
It is clearly defined in the slapd-config(5)/slapd.conf(5) man pages that the serverID parameter is REQUIRED to be unique. You have "1" twice.
" Non-zero IDs are required when using multimaster replication and each master must have a unique non-zero ID."
Note the words "must have" and "unique".
--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 25.10.2018 um 16:50 in
Nachricht <209ED46A1CC190DCC021AC3D@[192.168.1.39]>:
‑‑On Thursday, October 25, 2018 9:59 AM +0200 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
Hi!
I wonder whether there is a summary of additional checks that may prevent 2.4.41 from starting in a 2.4.26 MMR configuration (What I did was upgrading SLES11 SP4 to SLES12 SP3). What I found out is:
- olcServerID does not longer accept fifferent URIs mapping to the same
ID, like here (" slapd[3299]: olcServerID: value #1: <olcServerID> multiple server ID URLs matched, only one is allowed 1"): olcServerID: 1 ldap://host.domain.org:389 olcServerID: 1 ldaps://host.domain.org:636 (The idea was that whatever URI is used to contact the server, the server ID is the same) As we do not actually use ldaps for replication that second line could be dropped easily
It is clearly defined in the slapd‑config(5)/slapd.conf(5) man pages that the serverID parameter is REQUIRED to be unique. You have "1" twice.
Hi!
Yes, you are right, regarding the docs, but still I wonder, why all the different URIs for a multi-homed LDAP-server should not use the same ID: If the ID designates the database where the data came from, that would make sense. Forcing different server IDs for every interface the server uses does not make that much sense to me.
The manual says on ServerID: "Specify an integer ID from 0 to 4095 for this server". I think when adding the optional URL, that should be included in the uniqueness requirement, so that all "(ID, URI) pairs actually have to be unique. If one should use different IDs, depending on the URI, I wonder how to fulfill the "each master must have a unique ID." (with "a unique ID" meaning "exactly one unique ID") requirement.
" Non‑zero IDs are required when using multimaster replication and each master must have a unique non‑zero ID."
Note the words "must have" and "unique".
Yes, that's the specification, but does it really make sense?
Regards, Ulrich
--On Monday, October 29, 2018 9:03 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Yes, you are right, regarding the docs, but still I wonder, why all the different URIs for a multi-homed LDAP-server should not use the same ID: If the ID designates the database where the data came from, that would make sense. Forcing different server IDs for every interface the server uses does not make that much sense to me.
That's not how things work and that is not what the documentation is saying. You specify only a single serverID and URI *per server* not per URI that the server uses.
" Non‑zero IDs are required when using multimaster replication and each master must have a unique non‑zero ID."
Note the words "must have" and "unique".
Yes, that's the specification, but does it really make sense?
Yes.
--
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 29.10.2018 um 17:03 in
Nachricht <F73964C4E931CAA3C41163BE@[192.168.1.39]>:
--On Monday, October 29, 2018 9:03 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Yes, you are right, regarding the docs, but still I wonder, why all the different URIs for a multi-homed LDAP-server should not use the same ID: If the ID designates the database where the data came from, that would make sense. Forcing different server IDs for every interface the server uses does not make that much sense to me.
That's not how things work and that is not what the documentation is saying. You specify only a single serverID and URI *per server* not per URI that the server uses.
I don't quite understand (replicated cn=config for MMR): Assume a server has two IP addresses and names n1.d.o, n2.d.o associated with it. So the olcServerID: 1 ldap://n1.d.o:389 olcServerID: 1 ldap://n2.d.o:389 ...other servers... is illegal. How would the correct statement look like? How would it look like if I also include ldaps: URIs?
" Non‑zero IDs are required when using multimaster replication and each master must have a unique non‑zero ID."
Note the words "must have" and "unique".
Yes, that's the specification, but does it really make sense?
Yes.
Regards, Ulrich
Good morning Ulrich,
I believe there is a misunderstanding regarding the purpose for multiple olcServerIDs in the slapd.d configuration. By listing server ids for all of the masters in your MMR architecture, you can essentially make all of your master servers' configurations identical. Slapd will apply the serverID that matches the server's FQDN and ignore the rest.
Domain/IP address resolution should be handled by DNS; not the slapd configuration. The serverID is only used by the other producer servers for communication, so set each olcServerID to use the FQDN known by the other producer/master servers in the MMR architecture.
3 Master MMR Architecture Example: olcServerID: 1 ldap://server1.example.com olcServerID: 2 ldap://server2.example.com olcServerID: 3 ldap://server3.example.com
Jason Trupp Symas Corporation (855) LDAP-GUY
-----Original Message----- From: openldap-technical [mailto:openldap-technical-bounces@openldap.org] On Behalf Of Ulrich Windl Sent: Tuesday, October 30, 2018 2:03 AM To: openldap-technical@openldap.org; quanah@symas.com Subject: Re: Antw: Re: Upgrading from 2.4.26 to 2.4.41: Stricter checks prevent startup?
Quanah Gibson-Mount quanah@symas.com schrieb am 29.10.2018 um 17:03 in
Nachricht <F73964C4E931CAA3C41163BE@[192.168.1.39]>:
--On Monday, October 29, 2018 9:03 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Yes, you are right, regarding the docs, but still I wonder, why all the different URIs for a multi-homed LDAP-server should not use the same ID: If the ID designates the database where the data came from, that would make sense. Forcing different server IDs for every interface the server uses does not make that much sense to me.
That's not how things work and that is not what the documentation is saying. You specify only a single serverID and URI *per server* not per URI that the server uses.
I don't quite understand (replicated cn=config for MMR): Assume a server has two IP addresses and names n1.d.o, n2.d.o associated with it. So the olcServerID: 1 ldap://n1.d.o:389 olcServerID: 1 ldap://n2.d.o:389 ...other servers... is illegal. How would the correct statement look like? How would it look like if I also include ldaps: URIs?
" Non‑zero IDs are required when using multimaster replication and each master must have a unique non‑zero ID."
Note the words "must have" and "unique".
Yes, that's the specification, but does it really make sense?
Yes.
Regards, Ulrich
Jason Trupp jtrupp@symas.com schrieb am 30.10.2018 um 14:51 in Nachricht
002501d47057$b65cd5b0$23168110$@symas.com:
Good morning Ulrich,
I believe there is a misunderstanding regarding the purpose for multiple olcServerIDs in the slapd.d configuration. By listing server ids for all of
the masters in your MMR architecture, you can essentially make all of your master servers' configurations identical. Slapd will apply the serverID that
matches the server's FQDN and ignore the rest.
Hi!
That part of information is exactly missing in the manual page (slapd-config(5)):
olcServerID: <integer> [<URL>] Specify an integer ID from 0 to 4095 for this server (limited to 3 hexadecimal digits). The ID may also be specified as a hexa- decimal ID by prefixing the value with "0x". These IDs are required when using multimaster replication and each master must have a unique ID. Note that this requirement also applies to separate masters contributing to a glued set of databases. If the URL is provided, this directive may be specified multiple times, providing a complete list of participating servers and their IDs. The fully qualified hostname of each server should be used in the supplied URLs. The IDs are used in the "replica id" field of all CSNs generated by the specified server. The default value is zero. Example:
olcServerID: 1 ldap://ldap1.example.com olcServerID: 2 ldap://ldap2.example.com
Domain/IP address resolution should be handled by DNS; not the slapd configuration. The serverID is only used by the other producer servers for communication, so set each olcServerID to use the FQDN known by the other producer/master servers in the MMR architecture.
3 Master MMR Architecture Example: olcServerID: 1 ldap://server1.example.com olcServerID: 2 ldap://server2.example.com olcServerID: 3 ldap://server3.example.com
You are not going into detail of what I wrote: If you have a multi-homed server with different FQHNs for the IP addresses, you still want the server (the host, not the interface) to have ONE uniqie ID.
What if your server1.example.com and server2.example.com are two interfaces on the same server (maybe for redundancy purpose)?
Regards, Ulrich
Jason Trupp Symas Corporation (855) LDAP-GUY
-----Original Message----- From: openldap-technical [mailto:openldap-technical-bounces@openldap.org] On
Behalf Of Ulrich Windl Sent: Tuesday, October 30, 2018 2:03 AM To: openldap-technical@openldap.org; quanah@symas.com Subject: Re: Antw: Re: Upgrading from 2.4.26 to 2.4.41: Stricter checks prevent startup?
Quanah Gibson-Mount quanah@symas.com schrieb am 29.10.2018 um 17:03 in
Nachricht <F73964C4E931CAA3C41163BE@[192.168.1.39]>:
--On Monday, October 29, 2018 9:03 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Yes, you are right, regarding the docs, but still I wonder, why all the different URIs for a multi-homed LDAP-server should not use the same ID: If the ID designates the database where the data came from, that would make sense. Forcing different server IDs for every interface the server uses does not make that much sense to me.
That's not how things work and that is not what the documentation is saying. You specify only a single serverID and URI *per server* not per URI that the server uses.
I don't quite understand (replicated cn=config for MMR): Assume a server has two IP addresses and names n1.d.o, n2.d.o associated with it. So the olcServerID: 1 ldap://n1.d.o:389 olcServerID: 1 ldap://n2.d.o:389 ...other servers... is illegal. How would the correct statement look like? How would it look like if I also include ldaps: URIs?
" Non‑zero IDs are required when using multimaster replication and each master must have a unique non‑zero ID."
Note the words "must have" and "unique".
Yes, that's the specification, but does it really make sense?
Yes.
Regards, Ulrich
--On Tuesday, October 30, 2018 9:03 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
I don't quite understand (replicated cn=config for MMR): Assume a server has two IP addresses and names n1.d.o, n2.d.o associated with it. So the olcServerID: 1 ldap://n1.d.o:389 olcServerID: 1 ldap://n2.d.o:389 ...other servers... is illegal. How would the correct statement look like? How would it look like if I also include ldaps: URIs?
You would just pick one of those URI's. The way the olcServerID URI works is it is attempting to match that URI against a URI used with slapd's "-h" option when slapd is started. I.e., if you started slapd with:
-h "ldap://n1.d.o:389 ldap://n2.d.o:389 ldaps://n1.d.o:636 ldaps://n2.d.o:636 ldapi:///"
Then your olcServerID attribute could be any of:
olcServerID: 1 ldap://n1.d.o:389
OR
olcServerID: 1 ldap://n2.d.o:389
OR
olcServerID: 1 ldaps://n1.d.o:636
OR
olcServerID: 1 ldaps://n2.d.o:636
Pick whichever one makes you happiest. But ONLY one.
Hope that helps!
--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
-
Jason Trupp -
Michael Ströder -
Quanah Gibson-Mount -
Ulrich Windl