openldap-technical

openldap-technical@openldap.org

10 participants
9793 discussions

Ldap sync has broken from time to time
by skeletor 15 Dec '21

15 Dec '21

Hi. We have a one master and 8 slaves. From time to time replication has broken and data has stopped to update on slaves. In logs i see next: syncrepl_null_callback : error code 0x50 syncrepl_entry: rid=000 be_modify cn=union,ou=roles,dc=staff,dc=com (80) syncrepl_entry: rid=000 be_modify failed (80) do_syncrepl: rid=000 rc 80 retrying do_syncrep1: rid=000 starting refresh (sending cookie=rid=000,csn=20211213150433.004754Z#000000#000#000000) do_syncrep2: rid=000 LDAP_RES_INTERMEDIATE - SYNC_ID_SET syncrepl_message_to_entry: rid=000 DN: cn=union,ou=roles,dc=staff,dc=com, UUID: 67c22522-0749-1039-933a-fdc6b5a9b3b7 syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 4 "error code 0x50" means other ldap error. How to determine, what exactly wrong? There is no dependence with slaves or versions: - master has 2.4.50 - slaves have different versions: 2.4.50, 2.4.55, 2.4.57. All of slaves can breake. We use next configuration: syncrepl rid=000 provider=ldaps://ldap-master.domain.com type=refreshAndPersist retry="5 5 300 +" searchbase="dc=staff,dc=com" attrs="*,+" bindmethod=simple binddn="cn=slapd-slave,ou=services,dc=staff,dc=com" We can't try newer version, because use Oracle solaris and there are only 2.4.X versions. Should we create a bug or it was fixed in newer versions?

2 1

Symas OpenLDAP 2.6.0-5 released
by Quanah Gibson-Mount 14 Dec '21

14 Dec '21

Symas OpenLDAP 2.6.0 patch level 5 has been released for all supported platforms. It includes the following changes since the prior release: Fixed slapo-lastbind to work with 2.6 lastbind-precision configuration (ITS#9725) Added slapd config keyword for logfile format (ITS#9745) Fixed slapo-dynlist compare operation for static groups (ITS#9747) Fixed slapo-accesslog to fix inconsistently normalized minCSN (ITS#9752) Fixed slapd-mdb to update indices correctly on replace ops (ITS#9753) Fixed slapo-syncprov to generate a more accurate accesslog query (ITS#9756) New contrib module: slapo-allowed is now available. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Symas OpenLDAP 2.5.9-5 released
by Quanah Gibson-Mount 14 Dec '21

14 Dec '21

Symas OpenLDAP 2.5.9 patch level 5 has been released for all supported platforms. It includes the following changes since the prior release: Fixed slapo-dynlist compare operation for static groups (ITS#9747) Fixed slapo-accesslog to fix inconsistently normalized minCSN (ITS#9752) Fixed slapd-mdb to update indices correctly on replace ops (ITS#9753) Fixed slapo-syncprov to generate a more accurate accesslog query (ITS#9756) Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: 2.6 slapadd bug? - SHA512 userPassword hash get 2 characters appended to the end at import
by Dave Macias 13 Dec '21

13 Dec '21

Thank you Quanah for the input. I will say that i always turn off line wrap “ldif-wrap=no” when i export. Dont like how it looks with the wrap. So each attribute is one line on import. I still have yet to try what Michael suggested about scping the mdb files over. I’ll report on that hopefully this week. Thank you, Dave On Dec 6, 2021, 12:46 PM -0500, Quanah Gibson-Mount <quanah(a)symas.com>, wrote: > > > --On Saturday, December 4, 2021 2:58 AM -0500 Dave Macias > <davama(a)gmail.com> wrote: > > > > > > > Hello, > > > > Playing with 2.6 on rhel8 > > > > When imported my data.ldif I noticed i no longer could bind and my > > credentials would fail. Thought it was simply my account and tried with > > other test accounts and failed too. > > > > When i compare the userPassword attributes from the source to my 2.6 > > environment, i see there are two extra characters at the end. > > > > So original looks like: (and whats in data.ldif file) > > > > userPassword:: e2Nblablasuperdupper512hashthatendshere > > > > vs the one in 2.6 > > > > userPassword:: e2Nblablasuperdupper512hashthatendshereXX > > > > This happens on all the userPassword attributes that are SHA512. The XX > > characters seem random, no pattern to it. In other words each > > userPassword attribute has its own XX characters. > > I've generally seen issues like this when a script that munges data fails > to correctly delete multi-line attribute values and the leftover bits get > tacked onto the previous attribute. One way around this is to turn off > LDIF line wraps on export. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com>

1 1

OpenLDAP 2.6.0 testing call #3
by Quanah Gibson-Mount 13 Dec '21

13 Dec '21

This is the third testing call for OpenLDAP 2.6.0 Release. This is expected to be the final testing call. Generally, get the code for RE26: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. A list of items fixed and added in 2.6 can be found at: <https://bugs.openldap.org/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFI…> A major change with 2.6 is the optional ability to bypass syslog for logging (ITS#6949). This significantly improves slapd and lloadd performance. Additionally, the following deprecated backends have been removed: back-ndb back-shell Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

Re: Antw: [EXT] OpenLDAP Upgrade
by Ulrich Windl 13 Dec '21

13 Dec '21

>>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am 09.12.2021 um 17:54 in Nachricht <9E71A1C6CC6C9A43887B2B56(a)[192.168.1.3]>: > > ‑‑On Tuesday, December 7, 2021 8:39 AM ‑0800 Quanah Gibson‑Mount > <quanah(a)symas.com> wrote: > >> >> >> ‑‑On Tuesday, December 7, 2021 9:57 AM +0000 santoshk.sethi(a)tcs.com wrote: >> >>> Thanks Emmanuel, >>> Is it a stable version we can reply upon? Because the request is for a >>> production environment which are running critical business applications >>> >>> As part the OS upgrade (6.4 to 7.9), the default OpenLDAP comes in >>> RHEL7.9 is openldap‑servers‑2.4.44‑24.el7_9. >>> >>> This is a existing setup in production. We just want to upgrade it (rpm >>> ‑Uvh) :) on the exisitng RPMs. >> >> OpenLDAP 2.6 is the current release series. OpenLDAP 2.4 is no longer in >> support. As I noted previously, Symas provides pre‑built binaries via a >> repository as described at <https://repo.symas.com/soldap/>. Paid >> support is optionally available as well. > > Also, I'd note again that the vendor supplied builds are woefully out of > date and are generally unsuitable for a production environment, especially > one running business critical applications. Well, as long as those vendors offer support for their packages it's discussable whether those packages are suitable for production environments. At the moment I'm taking part in some online training, and I found out that the OS of the training environment had its last update in 2019, so probably the effective date of the software is even older. The company offering the training has _lots_ of money, however... Not all production environment needs bleeding edge software. Regards, Ulrich

2 3

OpenLDAP Upgrade
by santoshk.sethi＠tcs.com 13 Dec '21

13 Dec '21

HI, We have OpenLDAP 2.4.xx running in RHEL6.4. We are planning to upgrade the RHEL version to 7.9 and then upgrade the OpenLDAP to 2.6. The OpenLDAP installed are all RPMs #rpm -qa | grep -i openldap openldap-2.4.23-31.el6.x86_64 compat-openldap-2.3.43-2.el6.x86_64 openldap-devel-2.4.23-31.el6.x86_64 openldap-servers-2.4.23-31.el6.x86_64 openldap-clients-2.4.23-31.el6.x86_64 But the package for OpenLDAP available is binary packages. I need help how to upgrade considering the existing LDAP database, schema and configuration are required to be there after the upgrade. We have 2 Master server, 2 Consumer server and 2 loadbalancer running keepalived. Appreciate if anyone can help to upgrade the OS as well as the OpenLDAP package. Thanks Santosh

4 9

deltasync replication with 2.6 not working
by Stefan Kania 10 Dec '21

10 Dec '21

Hi to all, I still experimenting with openldap 2.6 and the deltasyncrepl with four hosts. I use debian 11 and the symas packages. I set up all four hosts with the following ldif-files. Starting with the basic settings: --------------------------------------- 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 # create cn=config #dn: olcBackend={0}mdb,cn=config #objectClass: olcBackendConfig #olcBackend: {0}mdb dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema 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 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 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: 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 --------------------------------------- After all four host have the same basic settings I change the "serverId" with the following LDIF-File. My problem is the same, even when I put the serverIds into the basic setup. The reason why I split the serverId from the basic settings is because I use Ansible to configure all hosts. ------------------------- 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 ------------------------- The next step is setting up the deltasync replication with the following LDIf-file: ------------------------- dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 dn: olcDatabase={3}mdb,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {3}mdb olcDbDirectory: /var/symas/accesslog olcSuffix: cn=accesslog olcAccess: {0}to dn.subtree="cn=accesslog" by dn.exact="uid=repl-user,ou=users,dc={first_dc}},dc=net" read by dn.exact="cn=admin,dc=example,dc=net" read olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcLimits: dn.exact="cn=uid=repl-user,dc=example,dc=net" time=unlimited size=unlimited olcSizeLimit: unlimited olcTimeLimit: unlimited olcMonitoring: TRUE olcDbCheckpoint: 0 0 olcDbIndex: entryCSN eq olcDbIndex: objectClass eq olcDbIndex: reqEnd eq olcDbIndex: reqResult eq olcDbIndex: reqStart eq olcDbIndex: reqDN eq olcDbMode: 0600 olcDbSearchStack: 16 olcDbMaxsize: 85899345920 dn: olcOverlay=syncprov,olcDatabase={3}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 200 dn: olcOverlay={1}accesslog,olcDatabase={2}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE olcAccessLogPurge: 01+00:00 00+04:00 dn: olcDatabase={2}mdb,cn=config changetype: modify replace: olcSyncrepl olcSyncrepl: rid=102 provider=ldap://ldap02.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes olcSyncrepl: rid=103 provider=ldap://ldap03.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes olcSyncrepl: rid=104 provider=ldap://ldap04.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes - replace: olcMirrorMode olcMirrorMode: TRUE ------------------------- The olcSyncrepl is different on each host this one is from ldap01.example.net so the host is not in the list. On each other host everything is setup the same. When in Start slapd I always getting this error messsages (on server ldap1: --------------------- ez 09 15:20:56 ldap01 slapd[2406]: conn=1035 fd=18 ACCEPT from IP=192.168.56.48:56760 (IP=0.0.0.0:389) Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=0 STARTTLS Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=0 RESULT oid= err=0 qtime=0.000024 etime=0.000299 text= Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 fd=18 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=1 BIND dn="uid=repl-user,ou=users,dc=example,dc=net" method=128 Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=1 BIND dn="uid=repl-user,ou=users,dc=example,dc=net" mech=SIMPLE bind_ssf=0 ssf=256 Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=1 RESULT tag=97 err=0 qtime=0.000033 etime=0.026849 text= Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior reqControls entryCSN Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=2 syncprov_op_search: got a persistent search with a cookie=rid=101,sid=004,csn=20211208190517.239632Z#000000#001#000000 Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=2 syncprov_findbase: searching Dez 09 15:20:56 ldap01 slapd[2406]: findbase failed! 32 Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=2 SEARCH RESULT tag=101 err=32 qtime=0.000019 etime=0.000166 nentries=0 text= Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=3 UNBIND Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 fd=18 closed --------------------- The rid 101 is NOT configured on this host, because it's ldap01 The same configuration is working on a Debian 10 with the openldpa-packages from debian. One more thing on debian 10 I see_ ---------------------- root@hm-01:~# ss -a | grep ldap | awk '{print$1 " " $2 " " $5 " " $6}' u_str LISTEN /var/run/slapd/ldapi 13381 tcp LISTEN 0.0.0.0:ldaps 0.0.0.0:* tcp LISTEN 0.0.0.0:ldap 0.0.0.0:* tcp ESTAB 192.168.56.41:ldap 192.168.56.44:35400 tcp ESTAB 192.168.56.41:ldap 192.168.56.42:57096 tcp ESTAB 192.168.56.41:ldap 192.168.56.43:54992 tcp ESTAB 192.168.56.41:33408 192.168.56.42:ldap tcp ESTAB 192.168.56.41:50268 192.168.56.43:ldap tcp LISTEN [::]:ldaps [::]:* tcp LISTEN [::]:ldap [::]:* ---------------------- What i expected because of "refreshAndPersist" on the Debian 11 host with the symas packages I see: --------------------- root@ldap01:~# ss -a | grep ldap | awk '{print$1 " " $2 " " $5 " " $6}' u_str LISTEN /var/symas/run/ldapi 14159 tcp LISTEN 0.0.0.0:ldaps 0.0.0.0:* tcp LISTEN 0.0.0.0:ldap 0.0.0.0:* tcp LISTEN [::]:ldaps [::]:* tcp LISTEN [::]:ldap [::]:* --------------------- So there is no permanent connection, that also shows the log. Error 32 means "no such object" but which object is missing. The accesslog DB files are there. The slapd is NOT running as rootI change all the permissions and settings to run slapd as unprivileged user. I'm lost :-) Stefan

2 2

RE: [EXT]:Re: OpenLDAP SSLV3 disable
by Quanah Gibson-Mount 09 Dec '21

09 Dec '21

--On Tuesday, December 7, 2021 10:00 PM +0000 "Ballem, Narayanan" <Narayanan.Ballem(a)Staples.com> wrote: > HI Quanah/Geert, > > Hope this email finds you well !!! > > Continues to the below email with Gnutls I am facing an issue with sync > between master/slave with mirror mode on. As per the earlier suggestion, > I am trying to re-compile OpenLDAP with Openssl on the Redhat server. > It's failing to find OpenSSL libraries though I defined explicitly in the > user profile but still not helping. > > Any idea how I can point to the OpenSSL libraries? > > > ./configure --prefix=/opt/dirsvcs --with-tls=openssl > > configure: error: Could not locate TLS/SSL package Check the output in the config.log file as to why it had the error. Generally, I'd guess because you didn't set the CPPFLAGS and thus it couldn't find the header files. Alternatively, you could simply deploy the builds from Symas, which link to OpenSSL already and skip building OpenLDAP yourself. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Antw: [EXT] mmr of cn=config with OpenLDAP 2.6
by Stefan Kania 09 Dec '21

09 Dec '21

Am 09.12.21 um 08:12 schrieb Ulrich Windl: >>>> Stefan Kania <stefan(a)kania-online.de> schrieb am 07.12.2021 um 16:52 in > Nachricht <37d8d0c0-fd4a-885d-7a8c-3874412eaa06(a)kania-online.de>: > > ... >> 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? > > Ebery change has a "change ID" (entryCSN): If a server receives an update having the same change ID that is already present, the update will be ignored, and maybe more importantly it won't propagate that update any further. That's how I understand it. So it does not harm. > Ok, that makes sense, but why only for the replication of cn=config. If you set up a mmr for the main DB you don't put only the other server into the Replication. If you have ldap1 ldap2 ldap3 lda4, on ldap1 you only have ldap2 ldap3 and ldap4 in the configuration. That's what I like to understand :-) >> >> Stefan > > > >

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical