389-users November 2019

389-users@lists.fedoraproject.org

12 participants
20 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

Replication with SSLCLIENTAUTH: server sent no certificate
by Eugen Lamers 02 Feb '21

02 Feb '21

I'm trying to setup a replication with a certificate based authentication between supplier and consumer. The certificates in the certdb at /etc/dirsrv/slapd-XXX contain the very same CA with which the respective server certificates in the certdbs have been signed. The certificates all have the 'u' flag, and the CA has the C and T flag. The replication (on the supplier) has been setup such that TLS and certificate based authentication is used, see extract from the replication agreement object: objectclass: nsds5ReplicationAgreement nsds5replicahost: <consumer-hostname> nsds5replicaport: 389 nsds5replicatransportinfo: TLS nsds5replicabindmethod: SSLCLIENTAUTH Trying to initialize the consumer raises this error in the error-log of the supplier (the host sending the starttls connection request): Replication bind with EXTERNAL auth failed: LDAP error 48 (Inappropriate authentication) (missing client certificate) The certificate that the server should have sent can, however, be used with the ldap commandline tools as ldapsearch. In this case a wireshark trace clearly shows that the client sends the certificate during the TLS handshake, while in the above case it doesn't. The TLS handshake defines that the client has to send an "empty certificate" if it does not have a certificate that has been issued by a CA offered by the server during the handshake. I can't see a reason for the client to think the condition isn't met. The certificate with which the server (supplier) is setup is the only one available. Is it possible that the server does not know which certificate it has to use for authentication with the consumer server? And if so, how do I make the server know? The 389-ds in use is the version 1.4.1.6~git0.5ac5a8aad. The problem was the same with 1.4.0.3. Thanks, Eugen

3 11

Problem browsing LDAP with Outlook
by Chris Bryant 26 Aug '20

26 Aug '20

When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS. When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well. I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also. Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration. Thanks, Chris USA.NET You Run Your Business. We'll Run Your Email. This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.

3 2

MemberOf group restrictions to a client system (server and client running CentOS 7)
by Janet Houser 06 Aug '20

06 Aug '20

Hi, I'm new to 389-ds and last week downloaded and installed the software. I have a running instance of the server, and I've added TLS/SSL. I've configured a CentOS 7 client to be able to query the server using TLS/SSL, and all appears working. I've created users and groups on the 389-ds server successfully. For each user and group, I've enabled posix attributes and my client can see the unix users and groups using the "getent password" or "getent group" commands. Now, here's where I'm getting tripped up.......... I need to limit which users have access to which systems. I've been trying to do this via memberOf group limitations. I found the following online resource (https://thornelabs.net/2013/01/28/aix-restrict-server-login-via-ldap-groups…) which is close enough to CentOS that the initial commands worked. I enabled the MemberOf plugin and changed the attributes per the link, and restarted the system. I created a test group (that I didn't enable a posix GID) and tried to add a single user via: Right click on group -- > click Properties --> then Members --> click Add --> Search for user --> click Add. When I try to go this route (which worked before enabling the memberOf plugin) it worked. Now it seems I get the error: "Cannot save to directory server. netscape.ldap.LDAPException: error resiult(65): Object class violation" And the messages file throws the error (/var/log/dirsrv/slapd-<instancename>/errors: "Entry "uid=test,ou=People,dc=int,dc=com" -- attribute "memberOf" not allowed [17/Feb/2016:11:22:58 -0700] memberof-plugin - memberof_postop_modify: failed to add dn (cn=testgroup,ou=Groups,dc=int,dc=com) to target. Error (65)" So it seems my server isn't quite using the memberOf plugin properly, but I'm not sure what else to enable. I'll have to solve this issue before I even try to filter login access via groups on my client system. I should mention that if I go under the advanced tab for one of the groups I created, I can add the the attribute "uniquemember", but I'm not sure what I should set the "value" to be. I've tried creating new users to see if I could set their "uniquemember" attributes, but no luck. It seems that I don't have the ability to set this attribute on individual users, only groups. This might not be the right road to head down when trying to restrict access to servers via groups, so I'm open to any suggestions. Any suggestions would be appreciated.

6 19

userPassword changed to PBKDF2_SHA256 after bind
by Francesc Guasch 09 Dec '19

09 Dec '19

Hello. After upgrade to 389 release 1.4 I experienced an odd behaviour. If I add a new user, then I bind with that user. The userPassword attribute gets changed to {PBKDF2_SHA256}. These are the steps I follow to reproduce it: 1- add a new entry with MD5 password, it is like this: {MD5}N7... 2- connect to LDAP and bind with the user just created 3- connect with admin and retrieve the password, it is {PBKDF2_SHA256} I may have been doing something wrong but my code worked on previous releases of 389-ds. I extracted code from my project to build a full test on it. I uploaded it to gist: https://gist.github.com/frankiejol/9e099ba828c8cbdff361783c177643da This is 1.4.1.6-4. So I have seen there is 1.4.2 release but I haven't been able to build it. It gets stuck on make lib389 ModuleNotFoundError: No module named 'packaging' make: *** [Makefile:14474: lib389] Error 1 Anyway, it looks like a bug or maybe a configuration issue ? thank you for your time

3 8

Converting OpenLdap ACL policies to 389-ds aci policies.
by Dharmalingam S 27 Nov '19

27 Nov '19

Hi, Thanks for quick response in both IRC and forums. Please find the following test ACL policies which am trying to convert. olcAccess: to dn.subtree="dc=test,dc=com" attrs=userPassword by dn.exact="cn=repl,dc=test,dc=com" write by group.exact="cn=DirectoryAdmins,ou=Groups,dc=test,dc=com" write by dn.children="ou=DirectoryAdmins,dc=test,dc=com" write by self write by anonymous auth (( need to find)) by * none I. aci: (target = "ldap:///dc=test,dc=com")(targetattr = "userPassword")(version 3.0; acl "ACI for userPassword attribute"; allow(write) (userdn = "ldap:///cn=repl,dc=test,dc=com") OR (groupdn = "ldap:///cn=DirectoryAdmins,ou=Groups,dc=test,dc=com") OR (groupdn = "ldap:///ou=DirectoryAdmins,dc=test,dc=com") OR (userdn = "ldap:///self");) ## TODO: ## read and search opeartions are there need to verify with auth # aci: (targetattr = "userPassword")(version 3.0; acl "Enable only auth for anonymous"; # allow(read, search) userdn= "ldap://anyone") aci: (targetattr = "userPassword")(version 3.0; acl "Disable for all other users"; deny(all) (userdn= "ldap:///all");) II. With multiple allow in one rule: aci: (target = "ldap:///dc=test,dc=com")(targetattr = "userPassword")(version 3.0; acl "ACI for userPassword attribute"; allow(write) (userdn = "ldap:///cn=repl,dc=test,dc=com"); allow(write)(groupdn = "ldap:///cn=DirectoryAdmins,ou=Groups,dc=test,dc=com"); allow(write)(groupdn = "ldap:///ou=DirectoryAdmins,dc=test,dc=com"); allow(write)(userdn = "ldap:///self");) Kindly can you review and let me know if i am wrong. Thanks & Regards Cooldharma06

2 1

Query about entryCSN and nsUniqueID in place of entryUUID
by cool dharma06 27 Nov '19

27 Nov '19

Hi all, i have OpenLDAP in my environment. And i am experimenting 389-ds and their functionalities. In my OpenLDAP, i have entries with following attributes: entryCSN, contextCSN, entryUUID. 1. For entryCSN and contextCSN - any equivalent attribute available in 389-ds 2. When i check for the above attributes in 389-ds, i am unable to find those attributes. From the post link, its mentioned like we can use nsUniqueID in place of entryUUID. but we might face issue during Sync/repl. Is this issue got fixed. https://pagure.io/389-ds-base/issue/137 Any suggestions for the above queries. Thanks & Regards cooldharma06

4 11

389ds and Get Effective Rights control: neither entryLevelRights nor attributeLevelRights returned
by Graham Leggett 19 Nov '19

19 Nov '19

Hi all, After adding the Get Effective Rights control to some java code as follows, everything is worked as before, except neither the entryLevelRights nor the attributeLevelRights attributes are returned to me. 389-ds-base-1.2.11.15-97.el6_10.x86_64 is logging the following, which looks hopeful: [18/Nov/2019:00:41:16 +0200] conn=1567060 op=5 SRCH base="dc=x,dc=x,dc=x" scope=2 filter="(&(objectClass=mailRec ipient)(mail=mail(a)example.com))" attrs="* entrylevelrights attributelevelrights aci" authzid="mail=minfrin(a)example.com,ou= external,dc=x,dc=x,dc=x" [18/Nov/2019:00:41:16 +0200] conn=1567060 op=5 RESULT err=0 tag=101 nentries=1 etime=0 - entryLevelRights: vadn However neither the entrylevelrights nor the attributelevelrights attributes are being returned in the response, and I have run out of ideas - what am I missing? The java code to add the control is as follows: BerByteArrayOutputStream berStream = new BerByteArrayOutputStream( dn.length() + 50, true); BerOctetString berString = new BerOctetString( ("dn:" + dn).getBytes()); berString.encode(berStream, true); berStream.close(); List<Control> controls = new ArrayList<Control>(Arrays.asList(ctx .getRequestControls())); controls.add(new BasicControl("1.3.6.1.4.1.42.2.27.9.5.2", true, berStream.getArray())); ctx.setRequestControls(controls.toArray(new Control[controls.size()])); Regards, Graham —

2 5

Announcing 389 Directory Server 1.4.2.4
by Mark Reynolds 14 Nov '19

14 Nov '19

389 Directory Server 1.4.2.4 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.2.4 Fedora packages are available on Fedora 30 and rawhide. https://koji.fedoraproject.org/koji/taskinfo?taskID=38997267 <https://koji.fedoraproject.org/koji/taskinfo?taskID=38997267> - Rawhide https://koji.fedoraproject.org/koji/taskinfo?taskID=38999035 <https://koji.fedoraproject.org/koji/taskinfo?taskID=38999035> - Fedora 30 Bodhi https://bodhi.fedoraproject.org/updates/FEDORA-2019-97dde340b9 <https://bodhi.fedoraproject.org/updates/FEDORA-2019-97dde340b9> The new packages and versions are: * 389-ds-base-1.4.2.4-1 Source tarballs are available for download at Download 389-ds-base Source <https://releases.pagure.org/389-ds-base/389-ds-base-1.4.2.4.tar.bz2> Highlights in 1.4.2.4 * Security and Bug 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 fully functional. There are still parts that need to be converted to ReactJS, but every feature is available. Configuration Tab Functional Written in ReactJS Server Tab Yes No Security Tab Yes Yes Database Tab Yes Yes Replication Tab Yes Yes Schema Tab Yes No Plugin Tab Yes Yes Monitor Tab Yes Yes 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 Pagure project: https://pagure.io/389-ds-base * Bump version to 1.4.2.4 * Issue 50634 - Fix CLI error parsing for non-string values * Issue 50659 - AddressSanitizer: SEGV … in bdb_pre_close * Issue 50716 - CVE-2019-14824 (BZ#1748199) - deref plugin displays restricted attributes * Issue 50644 - fix regression with creating sample entries * Issue 50699 - Add Disk Monitor to CLI and UI * Issue 50716 - CVE-2019-14824 (BZ#1748199) - deref plugin displays restricted attributes * Issue 50536 - After audit log file is rotated, DS version string is logged after each update * Issue 50712 - Version comparison doesn’t work correctly on git builds * Issue 50706 - Missing lib389 dependency - packaging * Issue 49761 - Fix CI test suite issues * Issue 50683 - Makefile.am contains unused RPM-related targets * Issue 50696 - Fix various UI bugs * Issue 50641 - Update default aci to allows users to change their own password * Issue 50007, 50648 - improve x509 handling in dsctl * Issue 50689 - Failed db restore task does not report an error * Issue 50199 - Disable perl by default * Issue 50633 - Add cargo vendor support for offline builds * Issue 50499 - Fix npm audit issues -- 389 Directory Server Development Team

1 0

Announcing 389 Directory Server 1.4.0.31
by Mark Reynolds 14 Nov '19

14 Nov '19

389 Directory Server 1.4.0.31 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.0.31 Fedora packages are available on Fedora 29 Fedora 29 https://koji.fedoraproject.org/koji/taskinfo?taskID=38980725 <https://koji.fedoraproject.org/koji/taskinfo?taskID=38980725> Bodhi F29 https://bodhi.fedoraproject.org/updates/FEDORA-2019-95d4df2047 <https://bodhi.fedoraproject.org/updates/FEDORA-2019-95d4df2047> The new packages and versions are: * 389-ds-base-1.4.0.31-1 Source tarballs are available for download at Download 389-ds-base Source <https://releases.pagure.org/389-ds-base/389-ds-base-1.4.0.31.tar.bz2> Highlights in 1.4.0.31 Security and bug fixes Installation and Upgrade See Download <https://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install, use *dnf install 389-ds-base*, then run *dscreate*. To install the Cockpit UI plugin use *dnf install cockpit-389-ds* See Install_Guide <https://www.port389.org/docs/389ds/howto/howto-install-389.html> for more information about the initial installation, setup, and upgrade 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 fully functional! There are still parts that need to be converted to ReactJS, but everything works. Configuration Tab Functional Written in ReactJS Server Tab Yes No Security Tab Yes Yes Database Tab Yes Yes Replication Tab Yes Yes Schema Tab Yes No Plugin Tab Yes Yes Monitor Tab Yes Yes 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 Pagure project: https://pagure.io/389-ds-base * Bump version to 1.4.0.31 * Issue 50499 - Fix npm audit issues * Issue 50699 - Add Disk Monitor to CLI and UI * Issue 50716 - CVE-2019-14824 (BZ#1748199) - deref plugin displays restricted attributes * Issue 50696 - Fix various UI bugs * Issue 50689 - Failed db restore task does not report an error -- 389 Directory Server Development Team

1 0

Announcing 389 Directory Server 1.4.1.10
by Mark Reynolds 14 Nov '19

14 Nov '19

389 Directory Server 1.4.1.10 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.1.10 Fedora packages are available on Fedora 30 and 31. https://koji.fedoraproject.org/koji/taskinfo?taskID=38976441 <https://koji.fedoraproject.org/koji/taskinfo?taskID=38976441> - Fedora 31 https://koji.fedoraproject.org/koji/taskinfo?taskID=38978324 <https://koji.fedoraproject.org/koji/taskinfo?taskID=38978324> - Fedora 30 Bodhi https://bodhi.fedoraproject.org/updates/FEDORA-2019-f5c518d477 <https://bodhi.fedoraproject.org/updates/FEDORA-2019-f5c518d477> - Fedora 31 https://bodhi.fedoraproject.org/updates/FEDORA-2019-1bc68862f0 <https://bodhi.fedoraproject.org/updates/FEDORA-2019-1bc68862f0> - Fedora 30 The new packages and versions are: * 389-ds-base-1.4.1.10-1 Source tarballs are available for download at Download 389-ds-base Source <https://releases.pagure.org/389-ds-base/389-ds-base-1.4.1.10.tar.bz2> Highlights in 1.4.1.10 * Security fix and Bug 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 fully functional. There are still parts that need to be converted to ReactJS, but every feature is available. Configuration Tab Functional Written in ReactJS Server Tab Yes No Security Tab Yes Yes Database Tab Yes Yes Replication Tab Yes Yes Schema Tab Yes No Plugin Tab Yes Yes Monitor Tab Yes Yes 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 Pagure project: https://pagure.io/389-ds-base * Bump version to 1.4.1.10 * Issue 50712 - Version comparison doesn’t work correctly on git builds * Issue 50706 - Missing lib389 dependency - packaging * Issue 50499 - Fix npm audit issues * Issue 50699 - Add Disk Monitor to CLI and UI * Issue 50716 - CVE-2019-14824 (BZ#1748199) - deref plugin displays restricted attributes * Issue 50696 - Fix various UI bugs * Issue 50689 - Failed db restore task does not report an error -- 389 Directory Server Development Team

1 0

Using sec-activate to enable SSL for admin server
by Grant Byers 08 Nov '19

08 Nov '19

Hi, I've mostly completed automated deployment of a 389ds cluster via Ansible. The final piece of the puzzle is the enablement of SSL/TLS for the Admin server. From what I understand, I should be able to use the sec-activate tool to do this; /usr/lib64/dirsrv/cgi-bin/sec-activate /etc/dirsrv/admin-serv on What I can't figure out is how to authenticate. When I run this, it prompts me repeatedly for Ënter Admin Server Administrator password:". I have tried both the RootDN and ConfigDirectoryAdminPwd passwords, but neither seem to work. Can anyone suggest what's going on here & how I might get past it? Thanks, Grant

3 4

Red Hat Directory Server 11 documentation
by Marc Muehlfeld 07 Nov '19

07 Nov '19

Hi, Red Hat released Directory Server 11.0 today, and the documentation is available on the Customer Portal: https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ The guides for this version describe setting up and managing Directory Server using Cockpit and the new command-line utilities (dsconf, dsctl, dscreate, and dsidm). Additionally, a lot of content has been rewritten and added. The Installation Guide also describes migration procedures from Directory Server 10. Regards, Marc PS: To report a documentation bug, please open a ticket: https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Directory%20S… -- Marc Muehlfeld (Senior Technical Writer) Customer Content Services _______________________________________________________________________________ Red Hat GmbH, Werner-von-Siemens-Ring 14, 85630 Grasbrunn, Germany http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander

2 1

Re: Unexpected failure while searching
by Morgan, Iain (ARC-TN)[InuTeq, LLC] 06 Nov '19

06 Nov '19

On 11/5/19, 14:29, "William Brown" <wbrown(a)suse.de> wrote: > On 6 Nov 2019, at 07:22, Iain Morgan <Iain.Morgan(a)nasa.gov> wrote: > > Hello, > > The list server seems to have delayed the original message for > moderation, so I'mtrying again with a different subject. > > I should note that the issue below may not be new: Even with our > previous generation of LDAP servers, our regression tests were only ever > run againsta single, non-replicated server. > > -- > Iain Morgan > ---- Forwarded message from Iain Morgan <Iain.Morgan(a)nasa.gov> ----- > > Date: Mon, 4 Nov 2019 17:11:52 -0800 > From: Iain Morgan <Iain.Morgan(a)nasa.gov> > To: 389-users(a)lists.fedoraproject.org > Subject: Unexpected 'admin limit exceeded' error > > Hello, > > I have a set of tests that are run against 389s a large number of times > as part of our regular testing. The tests primarily simulate account and > group > group management operations although there is also some testing of the > password policy enforcement. > > These tests were running fine against a single server configured without > replication. However, I recently started running these tests against a > server that is configured for multi-master replication with another host > running the same version of 389-ds. > > After successfully completing more than 700 iterations of the test suite, the tests unexpectedly failed > with err=11 while doing a a search. The curious thing is that the log > message reports nentries=1. > > [04/Nov/2019:15:23:50.792301129 -0800] conn=479376 op=2 SRCH base="ou=People,dc=nas,dc=nasa,dc=gov" scope=2 filter="(|(uid=testacct)(uid=aftertest))" attrs="1.1" > [04/Nov/2019:15:23:50.804542570 -0800] conn=479376 op=2 RESULT err=11 tag=101 nentries=1 etime=0.0012354224 Looking this up, it looks like err=11 is an administrative limit error, so it's likely that the partial-candidate set during index searching was larger than your limits allows. This could be due to the following settings: https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_docu… https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_docu… If my memory is correct, lookthroughlimit is how many entries we will filter-test in a candidate set (such as a full table scan scenario, or a really large query that is not fully indexed), and idlistscanlimit is a limit on how large an index list can be (in an attempt to discard large indexes hoping a smaller candidate index appears later in the query, essentially a naive form of query optimisation). As a result this makes me consider perhaps it's an indexing related problem? It may also be worth checking you have correct indexes for uid= under: dn: cn=uid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config (Ignore dn: cn=uid,cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config as this is a template index definition, and does not affect your actual indexing procedures.) Followed by potentially re-indexing your DB. You can always check your indexes are in good states with: cd /var/lib/dirsrv/slapd-instance/db/<backend name>/ dbscan -f uid.db4 -n -k "=testacct" dbscan -f uid.db4 -n -k "=aftertest" Both should have output like: =testacct <some integer greater than 0> Does that help? Thanks, that input was definitely helpful. The dbscan output appears to confirm that it is an indexing issue. Combining the results from dbscan for the two uid's shows that it was indeed hitting the nsslapd-lookthroughlimit setting. I'm not sure why it was not encountering this issue prior to setting up replication. I've previously run several thousand iterations of these tests without hitting this problem. Running db2index.pl has cleaned things up, so I suppose a workaround would be to have the test suite run db2index.pl after some number of iterations. -- Iain Morgan

2 1

MMR Incremental Update running long with many changes sent
by Oleg Cohen 06 Nov '19

06 Nov '19

Greetings, I am running 389-DS cluster v1.4.0.13 on CentOS 7. I have two nodes at the moment with a replication agreement set on both. I have initialized replica on NODE2 from NODE1. A replication agreement started from NODE2 to NODE1 and is now running non-stop for a number of hours. The number of changes sent is large. Is there any way I can figure out what is happening and get to the bottom of it? Not sure this behavior is normal. I would appreciate any suggestions on how to resolve/remediate this situation. Thank you! Oleg

3 4

Fwd: Unexpected failure while searching
by Iain Morgan 05 Nov '19

05 Nov '19

Hello, The list server seems to have delayed the original message for moderation, so I'mtrying again with a different subject. I should note that the issue below may not be new: Even with our previous generation of LDAP servers, our regression tests were only ever run againsta single, non-replicated server. -- Iain Morgan ---- Forwarded message from Iain Morgan <Iain.Morgan(a)nasa.gov> ----- Date: Mon, 4 Nov 2019 17:11:52 -0800 From: Iain Morgan <Iain.Morgan(a)nasa.gov> To: 389-users(a)lists.fedoraproject.org Subject: Unexpected 'admin limit exceeded' error Hello, I have a set of tests that are run against 389s a large number of times as part of our regular testing. The tests primarily simulate account and group group management operations although there is also some testing of the password policy enforcement. These tests were running fine against a single server configured without replication. However, I recently started running these tests against a server that is configured for multi-master replication with another host running the same version of 389-ds. After successfully completing more than 700 iterations of the test suite, the tests unexpectedly failed with err=11 while doing a a search. The curious thing is that the log message reports nentries=1. [04/Nov/2019:15:23:50.792301129 -0800] conn=479376 op=2 SRCH base="ou=People,dc=nas,dc=nasa,dc=gov" scope=2 filter="(|(uid=testacct)(uid=aftertest))" attrs="1.1" [04/Nov/2019:15:23:50.804542570 -0800] conn=479376 op=2 RESULT err=11 tag=101 nentries=1 etime=0.0012354224 No error is logged in the error log. This is on RHEL 7.7 with the 1.3.9.1-10 RPMs provided by Red Hat. -- Iain Morgan ----- End forwarded message ----- -- Iain Morgan

2 1

Announcing 389 Directory Server 1.4.0.30
by Mark Reynolds 05 Nov '19

05 Nov '19

389 Directory Server 1.4.0.30 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.0.30 Fedora packages are available on Fedora 29 Fedora 29 https://koji.fedoraproject.org/koji/taskinfo?taskID=38715661 <https://koji.fedoraproject.org/koji/taskinfo?taskID=38715661> Bodhi F29 https://bodhi.fedoraproject.org/updates/FEDORA-2019-01a5328b48 <https://bodhi.fedoraproject.org/updates/FEDORA-2019-01a5328b48> The new packages and versions are: * 389-ds-base-1.4.0.30-1 Source tarballs are available for download at Download 389-ds-base Source <https://releases.pagure.org/389-ds-base/389-ds-base-1.4.0.29.tar.bz2> Highlights in 1.4.0.30 Bug fixes Installation and Upgrade See Download <https://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install, use *dnf install 389-ds-base*, then run *dscreate*. To install the Cockpit UI plugin use *dnf install cockpit-389-ds* See Install_Guide <https://www.port389.org/docs/389ds/howto/howto-install-389.html> for more information about the initial installation, setup, and upgrade 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 fully functional! There are still parts that need to be converted to ReactJS, but everything works. Configuration Tab Functional Written in ReactJS Server Tab Yes No Security Tab Yes Yes Database Tab Yes Yes Replication Tab Yes Yes Schema Tab Yes No Plugin Tab Yes Yes Monitor Tab Yes Yes 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 Pagure project: https://pagure.io/389-ds-base * Bump version to 1.4.0.30 * Fix cherry-pick error in lib389 * Bump version to 1.4.0.29 * Issue 50592 - Port Replication Tab to ReactJS * Issue 50067 - Fix krb5 dependency in a specfile * Issue 50545 - Port repl-monitor.pl to lib389 CLI * Issue 50497 - Port cl-dump.pl tool to Python using lib389 * Issue 49850 - cont -fix crash in ldbm_non_leaf * Issue 50634 - Clean up CLI errors output - Fix wrong exception * Issue 50634 - Clean up CLI errors output * Issue 49850 - ldbm_get_nonleaf_ids() slow for databases with many non-leaf entries * Issue 50655 - access log etime is not properly formatted * Issue 50653 - objectclass parsing fails to log error message text * Issue 50646 - Improve task handling during shutdowns * Issue 50622 - ds_selinux_enabled may crash on suse -- 389 Directory Server Development Team

3 4

Re: urp_fixup_add_cenotaph errors
by Morgan, Iain (ARC-TN)[InuTeq, LLC] 05 Nov '19

05 Nov '19

On 9/8/19, 15:40, "William Brown" <wbrown(a)suse.de> wrote: > On 7 Sep 2019, at 08:33, Morgan, Iain (ARC-TN)[InuTeq, LLC] <iain.morgan(a)nasa.gov> wrote: > > Hello Marc, > > Yes, it is 389-ds-base1.3.9.1-10.el7, but we are not using IPA and there are no memberOf plugin errors. The actual modrdn operations have error=0. If we may, can we ask what the modrdn operations were, and to ask a little about your tree layout so we could try to understand more about this? Sure, there's nothing unusual regarding the tree layout. There's a single backend with ou=People,.... and ou=Groups,.... One thing that may be relevant is that this is a stand-alone server -- replication has not been configured. From the access log: [09/Sep/2019:15:05:08.577399600 -0700] conn=2233897 op=2 SRCH base="ou=Groups,dc=nas,dc=nasa,dc=gov" scope=2 filter="(|(cn=temp)(cn=testgroup))" attrs="cn" [09/Sep/2019:15:05:08.577630700 -0700] conn=2233897 op=2 RESULT err=0 tag=101 nentries=1 etime=0.0000323261 [09/Sep/2019:15:05:08.578316196 -0700] conn=2233897 op=3 MODRDN dn="cn=temp,ou=Groups,dc=nas,dc=nasa,dc=gov" newrdn="cn=testgroup" newsuperior="(null)" [09/Sep/2019:15:05:08.581595207 -0700] conn=2233897 op=3 RESULT err=0 tag=109 nentries=0 etime=0.0003326527 From the errors log: [09/Sep/2019:15:05:08.580235717 -0700] - ERR - conn=2233897 op=3 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 -- Iain Morgan

3 6

Announcing 389 Directory Server 1.4.1.9
by Mark Reynolds 04 Nov '19

04 Nov '19

389 Directory Server 1.4.1.9 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.1.9 Fedora packages are available on Fedora 30 and rawhide. https://koji.fedoraproject.org/koji/taskinfo?taskID=38715880 <https://koji.fedoraproject.org/koji/taskinfo?taskID=38715880> - Fedora 31 https://koji.fedoraproject.org/koji/taskinfo?taskID=38715551 <https://koji.fedoraproject.org/koji/taskinfo?taskID=38715551> - Fedora 30 Bodhi https://bodhi.fedoraproject.org/updates/FEDORA-2019-2efc25f4ff <https://bodhi.fedoraproject.org/updates/FEDORA-2019-2efc25f4ff> - Fedora 31 https://bodhi.fedoraproject.org/updates/FEDORA-2019-87a9b13ffb <https://bodhi.fedoraproject.org/updates/FEDORA-2019-87a9b13ffb> - Fedora 30 The new packages and versions are: * 389-ds-base-1.4.1.9-1 Source tarballs are available for download at Download 389-ds-base Source <https://releases.pagure.org/389-ds-base/389-ds-base-1.4.1.9.tar.bz2> Highlights in 1.4.1.9 * Bug 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 fully functional. There are still parts that need to be converted to ReactJS, but every feature is available. Configuration Tab Functional Written in ReactJS Server Tab Yes No Security Tab Yes Yes Database Tab Yes Yes Replication Tab Yes Yes Schema Tab Yes No Plugin Tab Yes Yes Monitor Tab Yes Yes 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 Pagure project: https://pagure.io/389-ds-base * Bump version to 1.4.1.9 * Issue 50592 - Port Replication Tab to ReactJS * Issue 49850 - cont -fix crash in ldbm_non_leaf * Issue 50634 - Clean up CLI errors output - Fix wrong exception * Issue 50634 - Clean up CLI errors output * Issue 49850 - ldbm_get_nonleaf_ids() slow for databases with many non-leaf entries * Issue 50655 - access log etime is not properly formatted * Issue 50653 - objectclass parsing fails to log error message text * Issue 50646 - Improve task handling during shutdowns * Issue 50622 - ds_selinux_enabled may crash on suse * Issue 50499 - Fix npm audit issues -- 389 Directory Server Development Team

1 0

Announcing 389 Directory Server 1.4.2.3
by Mark Reynolds 04 Nov '19

04 Nov '19

389 Directory Server 1.4.2.3 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.2.3 Fedora packages are available on Fedora (rawhide). https://koji.fedoraproject.org/koji/taskinfo?taskID=38746765 <https://koji.fedoraproject.org/koji/taskinfo?taskID=38746765> - Rawhide The new packages and versions are: * 389-ds-base-1.4.2.3-1 Source tarballs are available for download at Download 389-ds-base Source <https://releases.pagure.org/389-ds-base/389-ds-base-1.4.2.3.tar.bz2> Highlights in 1.4.2.3 * Bug 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 fully functional. There are still parts that need to be converted to ReactJS, but every feature is available. Configuration Tab Functional Written in ReactJS Server Tab Yes No Security Tab Yes Yes Database Tab Yes Yes Replication Tab Yes Yes Schema Tab Yes No Plugin Tab Yes Yes Monitor Tab Yes Yes 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 Pagure project: https://pagure.io/389-ds-base * Bump version to 1.4.2.3 * Issue 50592 - Port Replication Tab to ReactJS * Issue 50680 - Remove branding from upstream spec file * Issue 50669 - Remove nunc-stans in favour of reworking current conn code (add.) * Issue 48055 - CI test - automember_plugin(part1) * Issue 50677 - Map subtree searches with NULL base to default naming context * Issue 50669 - Fix RPM build * Issue 50669 - remove nunc-stans * Issue 49850 - cont -fix crash in ldbm_non_leaf * Issue 50634 - Clean up CLI errors output - Fix wrong exception * Issue 50660 - Build failure on Fedora 31 * Issue 50634 - Clean up CLI errors output * Issue 48851 - Investigate and port TET matching rules filter tests(match more test cases) * Issue 50428 - Log the actual base DN when the search fails with “invalid attribute request” * Issue 49850 - ldbm_get_nonleaf_ids() slow for databases with many non-leaf entries * Issue 50655 - access log etime is not properly formatted * Issue 50653 - objectclass parsing fails to log error message text * Issue 50646 - Improve task handling during shutdowns * Issue 50627 - Support platforms without pytest_html * Issue 49476 - backend refactoring phase1, fix failing tests * Issue 49476 - refactor ldbm backend to allow replacement of BDB * Issue 50349 - additional fix: filter schema check must handle subtypes * Issue 48851 - investigate and port TET matching rules filter tests(indexing more test cases) * Issue 50638 - RecursionError: maximum recursion depth exceeded while calling a Python object * Issue 50636 - Crash during sasl bind * Issue 50632 - Add ensure attr state so that diffs are easier from 389-ds-portal * Issue 50619 - extend commands to have more modify options * Issue 50499 - Fix npm audit issues -- 389 Directory Server Development Team

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users November 2019