[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: help needed for further investigation

Thank you, Dieter. I might consider this as a last effort.
3000+ Machines rely on this service and about 30000+ customer accounts.
Maybe even the customer's clients: 3 million and more.

Did you mean the replica or the provider slapd? (I guess it's the provider, though)

-----Original Message-----
From: openldap-technical [mailto:openldap-technical-bounces@openldap.org] On Behalf Of Dieter Klünter
Sent: Donnerstag, 14. Februar 2019 22:43
To: openldap-technical@openldap.org
Subject: Re: help needed for further investigation

Am Wed, 13 Feb 2019 14:41:07 +0000
schrieb <Thomas.Meller@t-systems.com>:

> Hello together. I am the heir of a setup based on RHEL 6.10 and
> Openldap 2.4.45 (ltb) A master syncrepls to a slave in
> type=refreshOnly using bindmethod=sasl, saslmech=external.
> 
> The mapped techuser resides in ou=ServiceUser. All Clients also use
> user objects in the same ou to bind to the servers.
> 
> I need to set new acls and decided to include a dedicated acl- and
> limits-configfile. The ACLs checked via slapacl look fine and run
> without problems on the test environment. (Which is based on the same
> 2.4.45 rpms, but the replica runs on RHEL 7.5)
> 
> All slapd configuration make use of database mdb and an explicitly
> set maxsize. (which is sized sufficiently: 12 GB, 49 MB used)
> 
> When implementing the configuration on a running system, the replica
> deletes the ou (that one with all the service user objects). Which is
> not what I want 8-/
> 
> How can I find out more about the reason for this peculiar result?
> I set the loglevel to 'stats sync' on the replica and 'sync' on the
[..]

Run slapd in debugging mode and use acl sny stats. That is something
like 

./slapd -d acl -h ldap://:9007/ and further options.

-Dieter


-- 
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E