>> Ulrich Windl schrieb am 25.10.2018 um 08:59 in Nachricht <5BD169CB.6FC :

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

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 <=

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!

Vermutlich ist das Modul in SLES12 SP4 nicht mehr enthalten! Ich habe auch kein entsprechendes Modul zum Nachinstallieren gefunden.

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

>> Michael Ströder <michael(a)stroeder.com&gt; schrieb am 25.10.2018 um 16:11 in

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.

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.

> " 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?

>> Quanah Gibson-Mount <quanah(a)symas.com&gt; schrieb am 29.10.2018 um >> 17:03 in

--On Monday, October 29, 2018 9:03 AM +0100 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de&gt; 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.

>> Jason Trupp <jtrupp(a)symas.com&gt; schrieb am 30.10.2018 um 14:51 in Nachricht

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(a)openldap.org; quanah(a)symas.com Subject: Re: Antw: Re: Upgrading from 2.4.26 to 2.4.41: Stricter checks prevent startup? >>> Quanah Gibson-Mount <quanah(a)symas.com&gt; schrieb am 29.10.2018 um >>> 17:03 in Nachricht <F73964C4E931CAA3C41163BE(a)[192.168.1.39]&gt;: > --On Monday, October 29, 2018 9:03 AM +0100 Ulrich Windl > <Ulrich.Windl(a)rz.uni-regensburg.de&gt; 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