RE: help needed for further investigation

[Thomas.Meller]

Thank you altogether.
finally I found the reason, being a mere re-order of one permission. A case I 
needed to extend my checkscript to.
As side effect I learned how the replication mechanics work in detail.
... which is helpful in itself.

-Original Message-
From: Quanah Gibson-Mount [mailto:qua...@symas.com] 
Sent: Donnerstag, 14. Februar 2019 17:12
To: Meller, Thomas; openldap-technical@openldap.org
Subject: Re: help needed for further investigation

--On Wednesday, February 13, 2019 2:41 PM + thomas.mel...@t-systems.com 
wrote:

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

Use refreshAndPersist, use delta-syncrepl

You don't provide enough usable information past that to help you any. 
Generally the replicator DN should have no limits applied to it, and have 
full read access to everything on the master.  Since you didn't provide 
your replication configuration nor your ACLs, there's no way of knowing 
what issue(s) you may encounter.

--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>

RE: help needed for further investigation

[Thomas.Meller]

Thank you, Dieter. I might consider this as a last effort.
3000+ Machines rely on this service and about 3+ 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-boun...@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 +
schrieb :

> 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

Re: help needed for further investigation

[Dieter Klünter]

Am Wed, 13 Feb 2019 14:41:07 +
schrieb :

> 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

Re: help needed for further investigation

[Quanah Gibson-Mount]

--On Wednesday, February 13, 2019 2:41 PM + thomas.mel...@t-systems.com 
wrote:



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.


Use refreshAndPersist, use delta-syncrepl

You don't provide enough usable information past that to help you any. 
Generally the replicator DN should have no limits applied to it, and have 
full read access to everything on the master.  Since you didn't provide 
your replication configuration nor your ACLs, there's no way of knowing 
what issue(s) you may encounter.


--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

help needed for further investigation

[Thomas.Meller]

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 master. (fs 
size is limited for logs)
The access limits are in place for this replication account and read access is 
granted as well. (might be I need to set something extra for operational 
attributes?)
limits dn.subtree="ou=ServiceUser,..."
size=unlimited
(this is the replica)
sizelimit unlimited
timelimit 10
and
limits dn.subtree="ou=ServiceUser,..."
size=unlimited
time=120
(in this order, this is the master)
What do I need to look at to find what's missing? I am no openldap crack, but 
no newbie as well. Yet my openldap knowledge ist not very extended.

Which further infos do I need to supply to maybe get help?

The include statements for limits and acls are defined before the database 
configuration.
I avoid using dynamic configuration to keep it all simple.

Overlays in use:
chain
dynlist
valsort
memberof
ppolicy
(replica)

syncprov
ppolicy
unique
dynlist
memberof
refint
valsort
(master)

Thank you,
Thomas