389-users March 2021

389-users@lists.fedoraproject.org

11 participants
18 discussions

dsconf idempotency
by Marco Favero 29 Mar '21

29 Mar '21

Hello, I like to use [dsconf](https://directory.fedoraproject.org/docs/389ds/design/dsadm-dsconf.… to manage my 389ds instances. I like also Ansible to manage the configuration. From Ansible, if I run dsconf command I see some problems of idempotency. For example, if I run the first time in a new fresh installation ``` dsconf -D cn=Directory Manager -w **** ldap://localhost:389 plugin attr-uniq set attribute uniqueness --subtree=c=en --enabled=on --attr-name=uid --across-all-subtrees=off ``` it returns 0 and the output *Successfully changed the cn=attribute uniqueness,cn=plugins,cn=config*. If I re run the same command I will see: *There is nothing to set in the cn=attribute uniqueness,cn=plugins,cn=config plugin entry* and the exit status is 1. Of course I can manage the output in Ansible in order to reclassify as well the task result. But I have to do that in a lot of cases (best effort). Of course I can use some idempotent ldapmodify module, but I like to trust `dsconf`. So I wonder if you could consider the benefit to make `dsconf` more idempotent. For instance, in the above case the exit status could be 0. The same behavior could be adopted in all results of "already exists" output messages when the value to set is equal to the value already present (ie: `dsconf -D cn=Directory Manager -w *** ldap://localhost:389 backend index add ...` returns "already exists" and the exit status 1 if the idex is already defined) If you have any other hints to address this problem could let me know. Thank you very much Kind Regards Marco

3 3

Password Upgrade on Bind modify
by Jan Tomasek 23 Mar '21

23 Mar '21

Hi, I've upgraded from older 389DS to 1.4.4.11 and realized that server started upgrading hashing algorithm of userPassword it is fine, but it also moves forward passwordExpirationTime. I know I can set dn: cn=config nsslapd-enable-upgrade-hash: off to disable this feature. Is there way how to only disable passwordExpirationTime updating and keep password hash upgrading enabled? -- ----------------------- Jan Tomasek aka Semik http://www.tomasek.cz/

2 1

Announcing 389 Directory Server 1.4.4.14
by thierry bordaz 19 Mar '21

19 Mar '21

389 Directory Server 1.4.4.14 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.4.14 Fedora packages are available on Fedora 33. Fedora 33: https://koji.fedoraproject.org/koji/taskinfo?taskID=64115273 <https://koji.fedoraproject.org/koji/taskinfo?taskID=64115273> - Koji https://bodhi.fedoraproject.org/updates/FEDORA-2021-3eed313617 <https://bodhi.fedoraproject.org/updates/FEDORA-2021-3eed313617> - Bohdi The new packages and versions are: * 389-ds-base-1.4.4.14-1 Source tarballs are available for download at Download 389-ds-base Source <https://github.com/389ds/389-ds-base/archive/389-ds-base-1.4.4.14.tar.gz> Highlights in 1.4.4.14 * Bug and Security fixes Installation and Upgrade See Download <https://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install the server use *dnf install 389-ds-base* To install the Cockpit UI plugin use *dnf install cockpit-389-ds* After rpm install completes, run *dscreate interactive* For upgrades, simply install the package. There are no further steps required. There are no upgrade steps besides installing the new rpms See Install_Guide <https://www.port389.org/docs/389ds/howto/howto-install-389.html> for more information about the initial installation and setup See Source <https://www.port389.org/docs/389ds/development/source.html> for information about source tarballs and SCM (git) access. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list: https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.o… If you find a bug, or would like to see a new feature, file it in our GitHub project: https://github.com/389ds/389-ds-base * Bump version to 1.4.4.14 * Issue 4671 - UI - Fix browser crashes * Issue 4229 - Fix Rust linking * Issue 4658 - monitor - connection start date is incorrect * Issue 4656 - Make replication CLI backwards compatible with role name change * Issue 4656 - Remove problematic language from UI/CLI/lib389 * Issue 4459 - lib389 - Default paths should use dse.ldif if the server is down * Issue 4661 - RFE - allow importing openldap schemas (#4662) * Issue 4659 - restart after openldap migration to enable plugins (#4660) * Issue 4663 - CLI - unable to add objectclass/attribute without x-origin * Issue 4169 - UI - updates on the tuning page are not reflected in the UI * Issue 4588 - BUG - unable to compile without xcrypt (#4589) * Issue 4513 - Fix replication CI test failures (#4557) * Issue 4646 - CLI/UI - revise DNA plugin management * Issue 4644 - Large updates can reset the CLcache to the beginning of the changelog (#4647) * Issue 4649 - crash in sync_repl when a MODRDN create a cenotaph (#4652) * Issue 4513 - CI - make acl ip address tests more robust * Issue 4619 - remove pytest requirement from lib389 * Issue 4615 - log message when psearch first exceeds max threads per conn

1 0

Announcing 389 Directory Server 1.4.3.22
by thierry bordaz 19 Mar '21

19 Mar '21

389 Directory Server 1.4.3.22 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.3.22 Fedora packages are available on Fedora 32. https://koji.fedoraproject.org/koji/taskinfo?taskID=64103798 <https://koji.fedoraproject.org/koji/taskinfo?taskID=64103798> - Fedora 32 https://bodhi.fedoraproject.org/updates/FEDORA-2021-35654cb13a <https://bodhi.fedoraproject.org/updates/FEDORA-2021-35654cb13a> - Bodhi The new packages and versions are: * 389-ds-base-1.4.3.22-1 Source tarballs are available for download at Download 389-ds-base Source <https://github.com/389ds/389-ds-base/archive/389-ds-base-1.4.3.22.tar.gz> Highlights in 1.4.3.22 * Bug and Security fixes Installation and Upgrade See Download <https://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install the server use *dnf install 389-ds-base* To install the Cockpit UI plugin use *dnf install cockpit-389-ds* After rpm install completes, run *dscreate interactive* For upgrades, simply install the package. There are no further steps required. There are no upgrade steps besides installing the new rpms See Install_Guide <https://www.port389.org/docs/389ds/howto/howto-install-389.html> for more information about the initial installation and setup See Source <https://www.port389.org/docs/389ds/development/source.html> for information about source tarballs and SCM (git) access. New UI Progress (Cockpit plugin) The new UI is complete and QE tested. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list: https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.o… If you find a bug, or would like to see a new feature, file it in our GitHub project: https://github.com/389ds/389-ds-base * Bump version to 1.4.3.22 * Issue 4671 - UI - Fix browser crashes * lib389 - Add ContentSyncPlugin class * Issue 4656 - lib389 - fix cherry pick error * Issue 4229 - Fix Rust linking * Issue 4658 - monitor - connection start date is incorrect * Issue 2621 - lib389 - backport ds_supports_new_changelog() * Issue 4656 - Make replication CLI backwards compatible with role name change * Issue 4656 - Remove problematic language from UI/CLI/lib389 * Issue 4459 - lib389 - Default paths should use dse.ldif if the server is down * Issue 4663 - CLI - unable to add objectclass/attribute without x-origin

1 0

Finding cause of 389ds sefault crash
by Nelson Bartley 18 Mar '21

18 Mar '21

Good afternoon Our ns-slapd crashed earlier today, with a segfault in libback-ldbm.so while the system was running a bdb_db_compact_one_db action. Is there anyway to trackdown/diagnose what might have caused the segfault? Some type of DB integrity check or something? Nelson

3 2

Re: Chain on Update problem
by William Brown 09 Mar '21

09 Mar '21

> On 9 Mar 2021, at 15:45, Grant Byers <Grant.Byers(a)aarnet.edu.au> wrote: > > FWIW, Red Hat don't want a bar of it given we're not running their IPA or RHDS products. We've enabled anonymous binds on our production masters to work around this issue, but as far as I'm concerned, the bug can languish. That doesn't seem right ... many of the RH 389 devs are on this list and I'll personally vouch that they care a lot about this kind of issue :) In my experience even if you aren't running RHDS/IPA if you raise an RH bugzilla, they'll support you. Perhaps your issue is with the phone/email support services? Another option is to raise it upstream against the version you are running. https://github.com/389ds/389-ds-base Regardless, once again, I guarantee that the RH developers of 389-ds really do care :) > > Regards, > Grant > From: William Brown <wbrown(a)suse.de> > Sent: Tuesday, March 9, 2021 9:27 AM > To: 389-users(a)lists.fedoraproject.org <389-users(a)lists.fedoraproject.org> > Subject: [389-users] Re: Chain on Update problem > > [External Mail] > > > > On 8 Mar 2021, at 20:42, Pierre Rogier <progier(a)redhat.com> wrote: > > > > Hi Grant, > > > > Good finding about the root cause ! > > > > About the solution, I think we should continue to send an anonymous bind but considers that ping is successful if the return code is either LDAP_SUCCESS or LDAP_INAPPROPRIATE_AUTH > > (anyway we do not care that the bind is really successful, we only want to know that server > > is responsive) > > > > FYI: My concerns with the search are that: > > - we would hit the same issue if acl deny the search > > But do we see many ACI on the rootdse to deny this? IIRC that would cause a lot of issues. > > > - it would increase the root dse contention > > The rootdse is fully in memory and when it populates the response it takes a series of locks over different config types. The extensions and features all look like a read lock, but the sasl mechs are a mutex so that would be my only concern. I don't think that it would be "too much" though, since how often would chaining really need to do these keep alive checks? > > > Perhaps the "best" option here is a config toggle that flips between rootdse or the target backed for the anonymous keep alive check. > > Alternately we could specify what DN is checked by anonymous for the check. I'd prefer the toggle just to help limit what we need to test though, and it makes configuration and admin a bit easier. > > > > > Regards > > Pierre > > > > On Mon, Mar 8, 2021 at 5:56 AM Grant Byers <Grant.Byers(a)aarnet.edu.au> wrote: > > Confirmed. I made the following simple change and it allows cb_ping_farm to work with anonymous binds only enabled for rootdse; > > > > > > diff -urN a/ldap/servers/plugins/chainingdb/cb_conn_stateless.c b/ldap/servers/plugins/chainingdb/cb_conn_stateless.c > > --- a/ldap/servers/plugins/chainingdb/cb_conn_stateless.c 2020-03-17 04:52:57.000000000 +1000 > > +++ b/ldap/servers/plugins/chainingdb/cb_conn_stateless.c 2021-03-08 14:04:48.413647052 +1000 > > @@ -883,7 +883,7 @@ > > /* NOTE: This will fail if we implement the ability to disable > > anonymous bind */ > > - rc = ldap_search_ext_s(ld, NULL, LDAP_SCOPE_BASE, "objectclass=*", attrs, 1, NULL, > > + rc = ldap_search_ext_s(ld, "", LDAP_SCOPE_BASE, "objectclass=*", attrs, 1, NULL, > > NULL, &timeout, 1, &result); > > if (LDAP_SUCCESS != rc) { > > slapi_ldap_unbind(ld); > > > > > > I don't believe this will break any functionality, but since we're running RHEL7, i'll raise this with Red Hat directly and they can review and/or push upstream. > > > > Regards, > > Grant > > > > From: Grant Byers <Grant.Byers(a)aarnet.edu.au> > > Sent: Monday, March 8, 2021 12:27 PM > > To: 389-users(a)lists.fedoraproject.org <389-users(a)lists.fedoraproject.org> > > Subject: Re: [389-users] Re: Chain on Update problem > > > > Thanks. > > > > I have tested various combinations of the tuning params without success. I've done further debugging and confirmed that it always starts after a bind operation timeout. Looking into the chaining plugin code, I see that on operation timeout results in a call to cb_ping_farm to see if we can find another server in the pool that is available. However, it performs this operation (the comment is telling); > > > > /* NOTE: This will fail if we implement the ability to disable > > anonymous bind */ > > rc = ldap_search_ext_s(ld, NULL, LDAP_SCOPE_BASE, "objectclass=*", attrs, 1, NULL, > > NULL, &timeout, 1, &result); > > if (LDAP_SUCCESS != rc) { > > slapi_ldap_unbind(ld); > > cb_update_failed_conn_cpt(cb); > > return LDAP_SERVER_DOWN; > > } > > > > So basically, because we've disallowed anonymous bind for anything but rootdse, it will always fail to find another available server. I have confirmed this by allowing anonymous bind on our masters while the issue was present, then subsequent binds on the consumers start working again. > > > > I would think it more appropriate for that code to do a search against the rootdse instead. Is there any good reason why it shouldn't? If not, I might test modifying it. > > > > > > Thanks, > > Grant > > > > > > From: William Brown <wbrown(a)suse.de> > > Sent: Friday, March 5, 2021 3:52 PM > > To: 389-users(a)lists.fedoraproject.org <389-users(a)lists.fedoraproject.org> > > Subject: [389-users] Re: Chain on Update problem > > > > [External Mail] > > > > > > > On 5 Mar 2021, at 12:03, Grant Byers <Grant.Byers(a)aarnet.edu.au> wrote: > > > > > > Hi All, > > > > > > Version: 1.3.10 > > > > > > In our environment, we'd like to use a chaining backend to push BIND operations up to masters by way of the consumer (rather than client referral). We'd like to do this to ensure password lockout attributes are propagated to all consumers equally via our standard replication agreements. This is described here - https://directory.fedoraproject.org/docs/389ds/howto/howto-chainonupdate.ht…. > > > > > > NOTE, we do not have hubs in our topology. Just masters and consumers, so no intermediate chaining. > > > > > > We tested this process in our environment and it worked beautifully until we took it to production. Currently, we have just 2 masters and they are both sitting on some over-subscribed hardware that suffers from I/O starvation at certain times of the day. The plan is to scale out our masters eventually, but we're a little hamstrung with other projects and priorities. It worked extremely well until that time of day when masters suffered from I/O starvation, and hence, very long I/O wait times. This is generally short lived and happens at alternate times of the day for each of the masters. However, it seems that once both nsfarmservers have "failed", there is never any attempt by the consumer to retry them. This leads to bind errors as follows; > > > > > > ldapwhoami -x -D "<binddn>" -W > > > Enter LDAP Password: > > > ldap_bind: Operations error (1) > > > additional info: FARM SERVER TEMPORARY UNAVAILABLE > > > > > > Except it is not temporary. It never recovers, even though all members of nsfarmservers are now healthy again (and are never unhealthy at the same time). We can confirm this by performing binds from the consumers directly against the masters. I thought that setting nsConnectionLife to something larger than 0 (indefinite) would help this, but it has not. > > > > The chain on update appears to use the chaining plugin timeouts, so you could look at adjusting these parameters which may help. > > > > nsBindTimeout > > nsOperationTimeout > > nsBindRetryLimit > > nsMaxResponseDelay > > nsMaxTestResponseDelay > > > > > > > > > > > > Is this by design, a bug, or an implementation fault on my behalf? Configuration below; > > > > > > Thanks, > > > Grant > > > > > > > > > > > > ## On masters, create a dedicated user for chaining backend > > > dn: cn=proxy,cn=config > > > objectClass: person > > > objectClass: top > > > cn: proxy > > > sn: admin > > > > > > ## On all consumers, create chaining backend; > > > dn: cn=chainbe1,cn=chaining database,cn=plugins,cn=config > > > objectclass: top > > > objectclass: extensibleObject > > > objectclass: nsBackendInstance > > > nsslapd-suffix: <suffix> > > > nsfarmserverurl: ldaps://<master1>:636 <master2>:636/ > > > nsMultiplexorBindDN: <binddn>> > > > nsMultiplexorCredentials: <bindpw> > > > nsCheckLocalACI: on > > > nsConnectionLife: 30 > > > cn: chainbe1 > > > > > > ## On all consumers, add the backend and repl_chain_on_update function > > > dn: cn="<suffix>",cn=mapping tree,cn=config > > > changetype: modify > > > add: nsslapd-backend > > > nsslapd-backend: chainbe1 > > > - > > > add: nsslapd-distribution-plugin > > > nsslapd-distribution-plugin: libreplication-plugin > > > - > > > add: nsslapd-distribution-funct > > > nsslapd-distribution-funct: repl_chain_on_update > > > > > > ## On all servers, enable global pasword policy > > > dn: cn=config > > > changetype: modify > > > replace: passwordIsGlobalPolicy > > > passwordIsGlobalPolicy: on > > > > > > _______________________________________________ > > > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > > > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… > > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > > > — > > Sincerely, > > > > William Brown > > > > Senior Software Engineer, 389 Directory Server > > SUSE Labs, Australia > > _______________________________________________ > > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > _______________________________________________ > > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > > > > > -- > > -- > > > > 389 Directory Server Development Team > > _______________________________________________ > > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs, Australia > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia

2 1

Re: Chain on Update problem
by Pierre Rogier 08 Mar '21

08 Mar '21

Hi Grant, Good finding about the root cause ! About the solution, I think we should continue to send an anonymous bind but considers that ping is successful if the return code is either LDAP_SUCCESS or LDAP_INAPPROPRIATE_AUTH (anyway we do not care that the bind is really successful, we only want to know that server is responsive) FYI: My concerns with the search are that: - we would hit the same issue if acl deny the search - it would increase the root dse contention Regards Pierre On Mon, Mar 8, 2021 at 5:56 AM Grant Byers <Grant.Byers(a)aarnet.edu.au> wrote: > Confirmed. I made the following simple change and it allows cb_ping_farm > to work with anonymous binds only enabled for rootdse; > > > diff -urN a/ldap/servers/plugins/chainingdb/cb_conn_stateless.c > b/ldap/servers/plugins/chainingdb/cb_conn_stateless.c > --- a/ldap/servers/plugins/chainingdb/cb_conn_stateless.c 2020-03-17 > 04:52:57.000000000 +1000 > +++ b/ldap/servers/plugins/chainingdb/cb_conn_stateless.c 2021-03-08 > 14:04:48.413647052 +1000 > @@ -883,7 +883,7 @@ > /* NOTE: This will fail if we implement the ability to disable > anonymous bind */ > - rc = ldap_search_ext_s(ld, NULL, LDAP_SCOPE_BASE, "objectclass=*", > attrs, 1, NULL, > + rc = ldap_search_ext_s(ld, "", LDAP_SCOPE_BASE, "objectclass=*", > attrs, 1, NULL, > NULL, &timeout, 1, &result); > if (LDAP_SUCCESS != rc) { > slapi_ldap_unbind(ld); > > > I don't believe this will break any functionality, but since we're running > RHEL7, i'll raise this with Red Hat directly and they can review and/or > push upstream. > > Regards, > Grant > > ------------------------------ > *From:* Grant Byers <Grant.Byers(a)aarnet.edu.au> > *Sent:* Monday, March 8, 2021 12:27 PM > *To:* 389-users(a)lists.fedoraproject.org <389-users(a)lists.fedoraproject.org > > > *Subject:* Re: [389-users] Re: Chain on Update problem > > Thanks. > > I have tested various combinations of the tuning params without success. > I've done further debugging and confirmed that it always starts after a > bind operation timeout. Looking into the chaining plugin code, I see that > on operation timeout results in a call to cb_ping_farm to see if we can > find another server in the pool that is available. However, it performs > this operation (the comment is telling); > > /* NOTE: This will fail if we implement the ability to disable > anonymous bind */ > rc = ldap_search_ext_s(ld, NULL, LDAP_SCOPE_BASE, "objectclass=*", > attrs, 1, NULL, > NULL, &timeout, 1, &result); > if (LDAP_SUCCESS != rc) { > slapi_ldap_unbind(ld); > cb_update_failed_conn_cpt(cb); > return LDAP_SERVER_DOWN; > } > > So basically, because we've disallowed anonymous bind for anything but > rootdse, it will always fail to find another available server. I have > confirmed this by allowing anonymous bind on our masters while the issue > was present, then subsequent binds on the consumers start working again. > > I would think it more appropriate for that code to do a search against the > rootdse instead. Is there any good reason why it shouldn't? If not, I might > test modifying it. > > > Thanks, > Grant > > > ------------------------------ > *From:* William Brown <wbrown(a)suse.de> > *Sent:* Friday, March 5, 2021 3:52 PM > *To:* 389-users(a)lists.fedoraproject.org <389-users(a)lists.fedoraproject.org > > > *Subject:* [389-users] Re: Chain on Update problem > > [External Mail] > > > > On 5 Mar 2021, at 12:03, Grant Byers <Grant.Byers(a)aarnet.edu.au> wrote: > > > > Hi All, > > > > Version: 1.3.10 > > > > In our environment, we'd like to use a chaining backend to push BIND > operations up to masters by way of the consumer (rather than client > referral). We'd like to do this to ensure password lockout attributes are > propagated to all consumers equally via our standard replication > agreements. This is described here - > https://directory.fedoraproject.org/docs/389ds/howto/howto-chainonupdate.ht… > . > > > > NOTE, we do not have hubs in our topology. Just masters and consumers, > so no intermediate chaining. > > > > We tested this process in our environment and it worked beautifully > until we took it to production. Currently, we have just 2 masters and they > are both sitting on some over-subscribed hardware that suffers from I/O > starvation at certain times of the day. The plan is to scale out our > masters eventually, but we're a little hamstrung with other projects and > priorities. It worked extremely well until that time of day when masters > suffered from I/O starvation, and hence, very long I/O wait times. This is > generally short lived and happens at alternate times of the day for each of > the masters. However, it seems that once both nsfarmservers have "failed", > there is never any attempt by the consumer to retry them. This leads to > bind errors as follows; > > > > ldapwhoami -x -D "<binddn>" -W > > Enter LDAP Password: > > ldap_bind: Operations error (1) > > additional info: FARM SERVER TEMPORARY UNAVAILABLE > > > > Except it is not temporary. It never recovers, even though all members > of nsfarmservers are now healthy again (and are never unhealthy at the same > time). We can confirm this by performing binds from the consumers directly > against the masters. I thought that setting nsConnectionLife to something > larger than 0 (indefinite) would help this, but it has not. > > The chain on update appears to use the chaining plugin timeouts, so you > could look at adjusting these parameters which may help. > > nsBindTimeout > nsOperationTimeout > nsBindRetryLimit > nsMaxResponseDelay > nsMaxTestResponseDelay > > > > > > > Is this by design, a bug, or an implementation fault on my behalf? > Configuration below; > > > > Thanks, > > Grant > > > > > > > > ## On masters, create a dedicated user for chaining backend > > dn: cn=proxy,cn=config > > objectClass: person > > objectClass: top > > cn: proxy > > sn: admin > > > > ## On all consumers, create chaining backend; > > dn: cn=chainbe1,cn=chaining database,cn=plugins,cn=config > > objectclass: top > > objectclass: extensibleObject > > objectclass: nsBackendInstance > > nsslapd-suffix: <suffix> > > nsfarmserverurl: ldaps://<master1>:636 <master2>:636/ > > nsMultiplexorBindDN: <binddn>> > > nsMultiplexorCredentials: <bindpw> > > nsCheckLocalACI: on > > nsConnectionLife: 30 > > cn: chainbe1 > > > > ## On all consumers, add the backend and repl_chain_on_update function > > dn: cn="<suffix>",cn=mapping tree,cn=config > > changetype: modify > > add: nsslapd-backend > > nsslapd-backend: chainbe1 > > - > > add: nsslapd-distribution-plugin > > nsslapd-distribution-plugin: libreplication-plugin > > - > > add: nsslapd-distribution-funct > > nsslapd-distribution-funct: repl_chain_on_update > > > > ## On all servers, enable global pasword policy > > dn: cn=config > > changetype: modify > > replace: passwordIsGlobalPolicy > > passwordIsGlobalPolicy: on > > > > _______________________________________________ > > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… > > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs, Australia > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- -- 389 Directory Server Development Team

3 2

Error while trying to add Object -> unknown object class "olcSchemaConfig"
by dd4321 Dey 08 Mar '21

08 Mar '21

Hi I am trying to use LDAP service which is installed in the IPA server to authenticate Guacamole users. Guacamole and LDAP integration specifies that i need to create an additional object called guacConfigGroup. To accomplish that, i have downloaded the supplied ldif file from https://guacamole.apache.org/doc/1.2.0/gug/ldap-auth.html and executed ldapadd utility command with the following ldif file: Command ======== # ldapadd -h idm.mydomain.net -p 389 -x -D "cn=Directory Manager" -w 'secret' -f guacConfigGroup.ldif guacConfigGroup.ldif ================ dn: cn=guacConfigGroup,cn=schema,cn=config objectClass: olcSchemaConfig cn: guacConfigGroup olcAttributeTypes: {0}( 1.3.6.1.4.1.38971.1.1.1 NAME 'guacConfigProtocol' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {1}( 1.3.6.1.4.1.38971.1.1.2 NAME 'guacConfigParameter' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcObjectClasses: {0}( 1.3.6.1.4.1.38971.1.2.1 NAME 'guacConfigGroup' DESC 'Guacamole configuration group' SUP groupOfNames MUST guacConfigProtocol MAY guacConfigParameter ) However, i am getting the following error while trying to add guacConfigGroup object adding new entry "cn=guacConfigGroup,cn=schema,cn=config" ldap_add: Object class violation (65) additional info: unknown object class "olcSchemaConfig" Any insights will be highly appreciated ! Regards

3 3

Re: Chain on Update problem
by Grant Byers 07 Mar '21

07 Mar '21

Confirmed. I made the following simple change and it allows cb_ping_farm to work with anonymous binds only enabled for rootdse; diff -urN a/ldap/servers/plugins/chainingdb/cb_conn_stateless.c b/ldap/servers/plugins/chainingdb/cb_conn_stateless.c --- a/ldap/servers/plugins/chainingdb/cb_conn_stateless.c 2020-03-17 04:52:57.000000000 +1000 +++ b/ldap/servers/plugins/chainingdb/cb_conn_stateless.c 2021-03-08 14:04:48.413647052 +1000 @@ -883,7 +883,7 @@ /* NOTE: This will fail if we implement the ability to disable anonymous bind */ - rc = ldap_search_ext_s(ld, NULL, LDAP_SCOPE_BASE, "objectclass=*", attrs, 1, NULL, + rc = ldap_search_ext_s(ld, "", LDAP_SCOPE_BASE, "objectclass=*", attrs, 1, NULL, NULL, &timeout, 1, &result); if (LDAP_SUCCESS != rc) { slapi_ldap_unbind(ld); I don't believe this will break any functionality, but since we're running RHEL7, i'll raise this with Red Hat directly and they can review and/or push upstream. Regards, Grant ________________________________ From: Grant Byers <Grant.Byers(a)aarnet.edu.au> Sent: Monday, March 8, 2021 12:27 PM To: 389-users(a)lists.fedoraproject.org <389-users(a)lists.fedoraproject.org> Subject: Re: [389-users] Re: Chain on Update problem Thanks. I have tested various combinations of the tuning params without success. I've done further debugging and confirmed that it always starts after a bind operation timeout. Looking into the chaining plugin code, I see that on operation timeout results in a call to cb_ping_farm to see if we can find another server in the pool that is available. However, it performs this operation (the comment is telling); /* NOTE: This will fail if we implement the ability to disable anonymous bind */ rc = ldap_search_ext_s(ld, NULL, LDAP_SCOPE_BASE, "objectclass=*", attrs, 1, NULL, NULL, &timeout, 1, &result); if (LDAP_SUCCESS != rc) { slapi_ldap_unbind(ld); cb_update_failed_conn_cpt(cb); return LDAP_SERVER_DOWN; } So basically, because we've disallowed anonymous bind for anything but rootdse, it will always fail to find another available server. I have confirmed this by allowing anonymous bind on our masters while the issue was present, then subsequent binds on the consumers start working again. I would think it more appropriate for that code to do a search against the rootdse instead. Is there any good reason why it shouldn't? If not, I might test modifying it. Thanks, Grant ________________________________ From: William Brown <wbrown(a)suse.de> Sent: Friday, March 5, 2021 3:52 PM To: 389-users(a)lists.fedoraproject.org <389-users(a)lists.fedoraproject.org> Subject: [389-users] Re: Chain on Update problem [External Mail] > On 5 Mar 2021, at 12:03, Grant Byers <Grant.Byers(a)aarnet.edu.au> wrote: > > Hi All, > > Version: 1.3.10 > > In our environment, we'd like to use a chaining backend to push BIND operations up to masters by way of the consumer (rather than client referral). We'd like to do this to ensure password lockout attributes are propagated to all consumers equally via our standard replication agreements. This is described here - https://directory.fedoraproject.org/docs/389ds/howto/howto-chainonupdate.ht…. > > NOTE, we do not have hubs in our topology. Just masters and consumers, so no intermediate chaining. > > We tested this process in our environment and it worked beautifully until we took it to production. Currently, we have just 2 masters and they are both sitting on some over-subscribed hardware that suffers from I/O starvation at certain times of the day. The plan is to scale out our masters eventually, but we're a little hamstrung with other projects and priorities. It worked extremely well until that time of day when masters suffered from I/O starvation, and hence, very long I/O wait times. This is generally short lived and happens at alternate times of the day for each of the masters. However, it seems that once both nsfarmservers have "failed", there is never any attempt by the consumer to retry them. This leads to bind errors as follows; > > ldapwhoami -x -D "<binddn>" -W > Enter LDAP Password: > ldap_bind: Operations error (1) > additional info: FARM SERVER TEMPORARY UNAVAILABLE > > Except it is not temporary. It never recovers, even though all members of nsfarmservers are now healthy again (and are never unhealthy at the same time). We can confirm this by performing binds from the consumers directly against the masters. I thought that setting nsConnectionLife to something larger than 0 (indefinite) would help this, but it has not. The chain on update appears to use the chaining plugin timeouts, so you could look at adjusting these parameters which may help. nsBindTimeout nsOperationTimeout nsBindRetryLimit nsMaxResponseDelay nsMaxTestResponseDelay > > Is this by design, a bug, or an implementation fault on my behalf? Configuration below; > > Thanks, > Grant > > > > ## On masters, create a dedicated user for chaining backend > dn: cn=proxy,cn=config > objectClass: person > objectClass: top > cn: proxy > sn: admin > > ## On all consumers, create chaining backend; > dn: cn=chainbe1,cn=chaining database,cn=plugins,cn=config > objectclass: top > objectclass: extensibleObject > objectclass: nsBackendInstance > nsslapd-suffix: <suffix> > nsfarmserverurl: ldaps://<master1>:636 <master2>:636/ > nsMultiplexorBindDN: <binddn>> > nsMultiplexorCredentials: <bindpw> > nsCheckLocalACI: on > nsConnectionLife: 30 > cn: chainbe1 > > ## On all consumers, add the backend and repl_chain_on_update function > dn: cn="<suffix>",cn=mapping tree,cn=config > changetype: modify > add: nsslapd-backend > nsslapd-backend: chainbe1 > - > add: nsslapd-distribution-plugin > nsslapd-distribution-plugin: libreplication-plugin > - > add: nsslapd-distribution-funct > nsslapd-distribution-funct: repl_chain_on_update > > ## On all servers, enable global pasword policy > dn: cn=config > changetype: modify > replace: passwordIsGlobalPolicy > passwordIsGlobalPolicy: on > > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

1 0

Re: Chain on Update problem
by William Brown 07 Mar '21

07 Mar '21

> On 5 Mar 2021, at 12:03, Grant Byers <Grant.Byers(a)aarnet.edu.au> wrote: > > Hi All, > > Version: 1.3.10 > > In our environment, we'd like to use a chaining backend to push BIND operations up to masters by way of the consumer (rather than client referral). We'd like to do this to ensure password lockout attributes are propagated to all consumers equally via our standard replication agreements. This is described here - https://directory.fedoraproject.org/docs/389ds/howto/howto-chainonupdate.ht…. > > NOTE, we do not have hubs in our topology. Just masters and consumers, so no intermediate chaining. > > We tested this process in our environment and it worked beautifully until we took it to production. Currently, we have just 2 masters and they are both sitting on some over-subscribed hardware that suffers from I/O starvation at certain times of the day. The plan is to scale out our masters eventually, but we're a little hamstrung with other projects and priorities. It worked extremely well until that time of day when masters suffered from I/O starvation, and hence, very long I/O wait times. This is generally short lived and happens at alternate times of the day for each of the masters. However, it seems that once both nsfarmservers have "failed", there is never any attempt by the consumer to retry them. This leads to bind errors as follows; > > ldapwhoami -x -D "<binddn>" -W > Enter LDAP Password: > ldap_bind: Operations error (1) > additional info: FARM SERVER TEMPORARY UNAVAILABLE > > Except it is not temporary. It never recovers, even though all members of nsfarmservers are now healthy again (and are never unhealthy at the same time). We can confirm this by performing binds from the consumers directly against the masters. I thought that setting nsConnectionLife to something larger than 0 (indefinite) would help this, but it has not. The chain on update appears to use the chaining plugin timeouts, so you could look at adjusting these parameters which may help. nsBindTimeout nsOperationTimeout nsBindRetryLimit nsMaxResponseDelay nsMaxTestResponseDelay > > Is this by design, a bug, or an implementation fault on my behalf? Configuration below; > > Thanks, > Grant > > > > ## On masters, create a dedicated user for chaining backend > dn: cn=proxy,cn=config > objectClass: person > objectClass: top > cn: proxy > sn: admin > > ## On all consumers, create chaining backend; > dn: cn=chainbe1,cn=chaining database,cn=plugins,cn=config > objectclass: top > objectclass: extensibleObject > objectclass: nsBackendInstance > nsslapd-suffix: <suffix> > nsfarmserverurl: ldaps://<master1>:636 <master2>:636/ > nsMultiplexorBindDN: <binddn>> > nsMultiplexorCredentials: <bindpw> > nsCheckLocalACI: on > nsConnectionLife: 30 > cn: chainbe1 > > ## On all consumers, add the backend and repl_chain_on_update function > dn: cn="<suffix>",cn=mapping tree,cn=config > changetype: modify > add: nsslapd-backend > nsslapd-backend: chainbe1 > - > add: nsslapd-distribution-plugin > nsslapd-distribution-plugin: libreplication-plugin > - > add: nsslapd-distribution-funct > nsslapd-distribution-funct: repl_chain_on_update > > ## On all servers, enable global pasword policy > dn: cn=config > changetype: modify > replace: passwordIsGlobalPolicy > passwordIsGlobalPolicy: on > > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users March 2021