right order mmr-main-DB combined with mmr cn=config
by Stefan Kania
Hello,
I'm still working on replication of cn=config. The replication of the
main DB is working with delta-syncrepl but I still have problems getting
mmr running for cn=config. As I use Ansible to configure it here my
question:
Is the order of setting up the replication relevant?
What I do at the moment:
Setting up a basic config for all 4 servers:
-----------------------------------------
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: 1 ldap://ldap01.example.net
olcServerID: 2 ldap://ldap02.example.net
olcServerID: 3 ldap://ldap03.example.net
olcServerID: 4 ldap://ldap04.example.net
# 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
-----------------------------------------
As you can see serverID is already set to URL-style for all servers ;-)
But now I'm not sure, do I have to set up the replication for cn=config
on all 4 servers and then set up replication of the main DB on just one
of the servers and let it be replicated by the cn=config-replication?
Or do I have to set up replication of the main DB on all servers first
and then add the replication of cn=config to all servers and only
replicate the changes made afterwards?
Or do I have to set up the replication of main-DB and replication of
cn=config on one server at a time?
Or can I do it either way?
The testsuit is showing using updateref on the replication of the
main-DB do I really need it for mmr? If yes, do I need it for mmr of
cn=config?
I could not find any example that uses both, mmr for main-DB and mmr for
cn=config.
here is the order of my set up for cn=config 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
tls_reqcert=allow
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
tls_reqcert=allow
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
tls_reqcert=allow
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
tls_reqcert=allow
-
add: olcMultiprovider
olcMultiprovider: TRUE
------------------------
And last but not least the set up of the main-DB replication:
-----------------------
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
tls_reqcert=allow
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
tls_reqcert=allow
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
tls_reqcert=allow
-
add: olcMultiprovider
olcMultiprovider: TRUE
-----------------------
This is the ldif for the first server so olcSyncrepl for
ldap01.example.net is not configured. On the other servers is the same
the own URI has no olcSyncrepl entry. Here olcUpdatRef is not
configured. Replication of the main-DB is running. BTW olcUpdateRef is
also not configured in the howto of Quanah ;-) So it must be ok :-)
Could you please take a look if I did something wrong. I don't know
where to look anymore.
1 year, 9 months
ldap_search_ext_s fails with "Operations error" when using root as base dn
by Alex Ditu
Hi,
When I try to query the root of my AD with
scope LDAP_SCOPE_SUBTREE ldap_search_ext_s() fails with "Operations error".
It happens only when I set the ldap_search_options.base to the domain DN
(eg. DC=example,DC=com). If I use a more specific base, such as
CN=Computers,DC=example,DC=com the operation succeeds. Is there a
limitation to the search function?
pseudocode snippet:
```
ldap_search_options ldap_opts;
ldap_opts.base = "DC=example,DC=com";
ldap_opts.scope = LDAP_SCOPE_SUBTREE;
```
1 year, 9 months
Ldap sync has broken from time to time
by skeletor
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?
1 year, 9 months
Symas OpenLDAP 2.6.0-5 released
by Quanah Gibson-Mount
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 year, 9 months
Symas OpenLDAP 2.5.9-5 released
by Quanah Gibson-Mount
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 year, 9 months
Re: 2.6 slapadd bug? - SHA512 userPassword hash get 2 characters appended to the end at import
by Dave Macias
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 year, 9 months
Re: Antw: [EXT] OpenLDAP Upgrade
by Ulrich Windl
>>> 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
1 year, 9 months
OpenLDAP Upgrade
by santoshk.sethi＠tcs.com
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
1 year, 9 months
deltasync replication with 2.6 not working
by Stefan Kania
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
1 year, 9 months
