389-users July 2021

389-users@lists.fedoraproject.org

11 participants
9 discussions

ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0
by Graham Leggett 12 Dec '23

12 Dec '23

Hi all, We have a long standing 389ds master LDAP server that was found to be unable to contact it’s slaves. Most specifically, the slaves show nothing in their logs about any kind of connection, while the master is logging this: [12/Nov/2019:21:39:47.212715697 +0000] - ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0 (Unknown error, host “ldap01:636”) Key is "system error 0 (no error)”, which leaves us stumped. The error is obviously “success”. Has anyone seen this kind of thing before? This is 389ds running on CentOS7 as follows: 389-ds-base-1.3.9.1-10.el7.x86_64 Regards, Graham —

3 9

Plugin development licensing
by DUVERT Vincent 09 May '23

09 May '23

Hello, I have a question regarding the licensing of developed 389-ds plugins. The FAQ (https://directory.fedoraproject.org/docs/389ds/FAQ/licensing.html#directory…) indicates that the Directory Server core code is licensed under a GPL + Exception license that allows non-GPL 389-ds plugins to link to 389-ds and to use specific header files. However, the LICENSE file in the current 389-ds-base source does not contain this exception. It was apparently removed by the following commit, when the license was changed to GPLv3+: https://pagure.io/389-ds-base/c/88cae401aee39a19ac6b07c3c36ee8daa07192e7 Does that means that the license exception does not apply to the current version of 389-ds? Regards, Vincent Duvert

2 2

adjust nsslapd-idlistscanlimit
by Erwin Weitlaner 29 Jul '21

29 Jul '21

We are running a 389 Directory Server as our Identity Store Backend for years. Recently I saw the number of unindexed searches inreased and CPU consumption doubled. After some investigation I found that the number of entries with a certain objectClass (with a certain base DN) became higher than 4000 causing that unwanted behaviour. After some further investigation I saw that other object classes (eg. groups and org-units) have numbers between 6000 and 10000. Searches on these objectClasses also show 'notes=A'. So I tend to change the value of nsslapd-idlistscanlimit to 12000. Your Opinion?

1 0

DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock
by Kees Bakker 28 Jul '21

28 Jul '21

Hi, This is in a IPA deployment. We have three masters/replicas in a triangular topology, A-B, B-C, C-A. The systems are called: rotte, linge and iparep4. rotte is CentOS 7, with 389-ds-base-1.3.9.1-13.el7_7.x86_64 linge and iparep4 are CentOS 8 Stream, with 389-ds-base-1.4.3.23-2.module_el8.5.0+835+5d54734c.x86_64 Yesterday I removed some members from a user group on rotte. This caused the follow errors on linge (and on iparep4). Jul 26 11:44:37 linge.example.com ns-slapd[282944]: [26/Jul/2021:11:44:37.947738548 +0200] - ERR - NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn - retry (49) the transaction (csn=60fe8535001000030000) failed (rc=-30993 (BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock)) Jul 26 11:44:38 linge.example.com ns-slapd[282944]: [26/Jul/2021:11:44:38.000964611 +0200] - ERR - NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn - Failed to write entry with csn (60fe8535001000030000); db error - -30993 BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock Jul 26 11:44:38 linge.example.com ns-slapd[282944]: [26/Jul/2021:11:44:38.025996273 +0200] - ERR - NSMMReplicationPlugin - write_changelog_and_ruv - Can't add a change for cn=vpn_users,cn=groups,cn=accounts,dc=example,dc=com (uniqid: 31283c01-a16511e9-93cf90e8-ab7c8ee8, optype: 8) to changelog csn 60fe8535001000030000 Jul 26 11:44:38 linge.example.com ns-slapd[282944]: [26/Jul/2021:11:44:38.062640602 +0200] - ERR - NSMMReplicationPlugin - process_postop - Failed to apply update (60fe8535001000030000) error (1). Aborting replication session(conn=53596 op=65) On rotte jul 26 11:44:39 rotte.example.com ns-slapd[2705]: [26/Jul/2021:11:44:39.055890736 +0200] - WARN - NSMMReplicationPlugin - repl5_inc_update_from_op_result - agmt="cn=meTolinge.example.com" (linge:389): Consumer failed to replay change (uniqueid 31283c01-a16511e9-93cf90e8-ab7c8ee8, CSN 60fe8535001000030000): Operations error (1). Will retry later. jul 26 11:44:39 rotte.example.com ns-slapd[2705]: [26/Jul/2021:11:44:39.058198988 +0200] - WARN - NSMMReplicationPlugin - repl5_inc_update_from_op_result - agmt="cn=meTolinge.example.com" (linge:389): Consumer failed to replay change (uniqueid 31283c01-a16511e9-93cf90e8-ab7c8ee8, CSN 60fe8535003300030000): Operations error(1). Will retry later. jul 26 11:44:39 rotte.example.com ns-slapd[2705]: [26/Jul/2021:11:44:39.069825407 +0200] - ERR - NSMMReplicationPlugin - release_replica - agmt="cn=meTolinge.example.com" (linge:389): Unable to send endReplication extended operation (Operations error) jul 26 11:44:46 rotte.example.com ns-slapd[2705]: [26/Jul/2021:11:44:46.561562313 +0200] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meTolinge.example.com" (linge:389): Replication bind with GSSAPI auth resumed As far as I can see the user group is correctly modified on all replicas. But it doesn't look healthy to me. Is there anything I can do to see what went wrong? Is there something to improve in the configuration? -- Kees

2 6

memberOf Plugin report inconsistent states
by Tobias Ernstberger 15 Jul '21

15 Jul '21

Hello, it is well known and documented, that the memberOf attribute can have inconsistent states (e.g. by manipulating it directly). There is also a Fix-Up Task to repair that. Question: Is there also a way to report/list all current inconsistent states, that the Fix-Up Task might repair? Motivation for that is to evaluate the impact of the Fix-Up Task to reduce/manage operational risks. Possible action might be to evaluate manually for all reported issues if they need to be cleaned up in the memberOf attribute, or added as regular group membership to the group Mit freundlichen Grüßen / Kind regards Tobias Ernstberger IT-Architect Identity and Access Management IBM Security Expert Labs +49 151 15138929 tobias.ernstberger(a)de.ibm.com IBM Security IBM Deutschland GmbH Vorsitzender des Aufsichtsrats: Sebastian Krause Geschäftsführung: Gregor Pillen (Vorsitzender), Agnes Heftberger, Gabriele Schwarenthorer, Markus Koerner, Christian Noll, Nicole Reimer Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, HRB 14562 / WEEE-Reg.-Nr. DE 99369940 https://www.ibm.com/privacy/us/en/

3 3

Cockpit and 389
by Gary Waters 12 Jul '21

12 Jul '21

Hello Everyone, I have been having trouble with Cockpit and 389 since I upgraded to 389-ds-base to 1.4.X from 1.3.X. I was initially having trouble with rendering the replication page but I have determined that the monitoring page is not rendering as well. (or maybe I am not waiting log enough, I waited 15 minutes). Has anyone had any luck on making this work again ? Ctrl-Shift-J had errors about some CSP stuff, but I allowed everything from the url via Chrome and Brave Browser settings, so now the only error (apparently a big one for both pages) is index.js:117 Uncaught TypeError: Cannot read property 'length' of undefined at Function.<anonymous> (index.js:117) at cockpit.js:1 at cockpit.js:1 at A (cockpit.js:1) I tried upgrading to the latest cockpit 389 plugin but it still doesnt work. Red Hat Enterprise Linux release 8.4 (Ootpa) 4.18.0-305.7.1.el8_4.x86_64 389-ds-base-libs-1.4.3.17-1.module_el8+10764+2b5f8656.x86_64 389-ds-base-1.4.3.17-1.module_el8+10764+2b5f8656.x86_64 cockpit-389-ds-2.0.4-2.module_el8+12009+23f3e50a.noarch python3-lib389-1.4.3.17-1.module_el8+10764+2b5f8656.noarch Thanks, Gary

3 3

ldapsearch Please help!
by kckong1＠yahoo.com 09 Jul '21

09 Jul '21

Current Environment:- 389-Directory/1.4.3.22 B2021.082.0613 Oracle Linux 8.2 I want to make the user raduser able to execute ldapsearch to get the record output. The raduser's objectClass - directoryServerFeature (structural) - inetOrgPerson (structural) - organisationalPerson (structural) - person (structural) - top (abstract) # ldapsearch -LLL -w password -H ldap://localhost:389 -D "cn=Directory Manager" - output the ldap records. # ldapsearch -LLL -w password -H ldap://localhost:389 -D "uid=raduser,ou=Administrator,o=mydatabase" - NO OUTPUT, confirmed the credential is valid DIT > ROOT DSE as below:- - o=mydatabase -- cn=Directory Manager - ou=Administrator -- uid=raduser - ou=subscriber -- uid=user1 -- uid=user2 -- uid=user3 -- and more...

1 0

Re: Replica's nsslapd-referral uri is ldap: instead of ldap:
by Mark Reynolds 02 Jul '21

02 Jul '21

On 7/2/21 8:35 AM, Collins, Brian (CAI - Atlanta) wrote: > > Thanks for the quick reply, Mark. > > Also, thank you to you and the folks at Red Hat for all the work in > the newer releases. Two things stand out: dsconf and not having to > run X. There is much more, but those two are a great benefit. > Thanks, that's nice to hear! Wait until the UI rewrite is done ;-) > > So I executed the following, named fixreferral.ldif > > dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config > > changetype: modify > > replace: nsslapd-referral > > nsslapd-referral: ldaps://auth01.example.com:636/dc%3Dexample%2Cdc%3Dcom > > nsslapd-referral: ldaps://auth02.example.com:636/dc%3Dexample%2Cdc%3Dcom > > Using: ldapmodify -x -D "cn=Directory Manager" -W -H ldaps://auth04 -f > fixreferral.ldif > > Then issued: systemctl restart dirsrv@auth04 > > When I checked, however, it had reverted to: > > # grep nsslapd-referral dse.ldif > > nsslapd-referral: ldap://auth01.example.com:389/dc%3Dexample%2Cdc > > nsslapd-referral: ldap://auth02.example.com:389/dc%3Dexample%2Cdc > > BUT... dse.ldif.startOK has this: > > nsslapd-referral: ldaps://auth01.example.com:636/dc%3Dexample%2Cd > > nsslapd-referral: ldaps://auth02.example.com:636/dc%3Dexample%2Cd > > So it would appear to be reverting AFTER the restart. Which makes me > think it's something that it is receiving from the supplier possibly? > Ugh, so the replication plugin is probably rewriting it. Odd that it "worked" in 1.3.x because I don't recall any changes around referrals in a long time. We will need investigate it. Can you open a github issue describing the issue, and how it's blocking password updates? https://github.com/389ds/389-ds-base/issues/new/choose Thanks, Mark > Thanks again, > > Brian > > *From: *Mark Reynolds <mareynol(a)redhat.com> > *Date: *Thursday, July 1, 2021 at 8:22 PM > *To: *"General discussion list for the 389 Directory server project." > <389-users(a)lists.fedoraproject.org>, "Collins, Brian (CAI - Atlanta)" > <Brian.Collins(a)coxautoinc.com> > *Subject: *Re: [389-users] Replica's nsslapd-referral uri is ldap: > instead of ldap: > > Hi Brian, > > You can just change nsslapd-referral attribute to use ldaps instead of > ldap. > > Now you "should" be able to do that in the console, but I just found > out that there is a bug in the console where we don't actually grab > the referrals from the mapping tree entry. <sigh> Glad I found it > now because the cockpit console is going through a rewrite (to migrate > to Patternfly 4). So I will fix that, but it doesn't help you today. > > So for now you will need to use ldapmodify to change the > nsslapd-referral attribute. I would say to use dsconf but it is also > broken for properly setting referrals <sigh again>. Once I fix dsconf > it would work like this: > > #dsconf slapd-supplier1 backend suffix set userroot --del-referral > ldap://localhost:636 <ldap://localhost:636> > > #dsconf slapd-supplier1 backend suffix set userroot --add-referral > ldaps://localhost:636 <ldaps://localhost:636> > > Right now dsconf updates the referral on the wrong entry :-( We'll get > this all fixed up! > > HTH, > > Mark > > On 7/1/21 6:04 PM, Collins, Brian (CAI - Atlanta) wrote: > > Good day, > > I am doing prep work for replacing our older 389 servers (1.3.8) > running on RHEL 7 with newer ones on RHEL 8 and 1.4.4. > > I have the two RHEL 7 boxes in a multi-master replication setup. > > For this phase of testing I have one read-only replica on 1.4.4, > as a consumer to the two current servers. I set up a Linux client > to login using SSSD, bound to the consumer. It works fine except > when I want to change passwords. I was getting "Operation > requires a secure connection." After a lot of digging, I think I > found the culprit there: on the consumer, in "dn: > cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" the > nsslapd-referral uri for my two current servers is ldap: instead > of ldaps:. Indeed, in the cockpit console, the Remote RUV list > shows both servers as ldap:. > > But on the two suppliers, the old servers, the referral uri is ldaps. > > When I set up the replication agreement for the new consumer, I > did it just as I did for the current setup, so I don't feel like > that's where I went wrong. > > Thanks in advance for any pointers, > > Brian Collins > > > > _______________________________________________ > > 389-users mailing list --389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to389-users-leave(a)lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > > Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ <https://urldefense.com/v3/__https:/docs.fedoraproject.org/en-US/project/cod…> > > List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines <https://urldefense.com/v3/__https:/fedoraproject.org/wiki/Mailing_list_guid…> > > List Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fedo… <https://urldefense.com/v3/__https:/lists.fedoraproject.org/archives/list/38…> > > Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure <https://urldefense.com/v3/__https:/pagure.io/fedora-infrastructure__;!!Gh9p…> > > -- > Directory Server Development Team -- Directory Server Development Team

3 5

Replica's nsslapd-referral uri is ldap: instead of ldap:
by Collins, Brian (CAI - Atlanta) 02 Jul '21

02 Jul '21

Good day, I am doing prep work for replacing our older 389 servers (1.3.8) running on RHEL 7 with newer ones on RHEL 8 and 1.4.4. I have the two RHEL 7 boxes in a multi-master replication setup. For this phase of testing I have one read-only replica on 1.4.4, as a consumer to the two current servers. I set up a Linux client to login using SSSD, bound to the consumer. It works fine except when I want to change passwords. I was getting "Operation requires a secure connection." After a lot of digging, I think I found the culprit there: on the consumer, in "dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" the nsslapd-referral uri for my two current servers is ldap: instead of ldaps:. Indeed, in the cockpit console, the Remote RUV list shows both servers as ldap:. But on the two suppliers, the old servers, the referral uri is ldaps. When I set up the replication agreement for the new consumer, I did it just as I did for the current setup, so I don't feel like that's where I went wrong. Thanks in advance for any pointers, Brian Collins

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users July 2021