389-users

389-users@lists.fedoraproject.org

5 participants
6608 discussions

389DS Version 3.1.3-1 on copr?
by Bryan K. Walton 09 Jul '25

09 Jul '25

Hi, We are currently running 389-ds-base and cockpit-389-ds (both version 2.2.9) from the copr repo. I've been monitoring https://copr.fedorainfracloud.org/coprs/g/389ds/389-directory-server/packag… and for the last few months, the builds for 3.1.3 have been failing. Should we be getting our 389-ds rpms from another location? Thanks, Bryan

2 2

user password change issue
by Van Remoortere, Arnaud 07 Jul '25

07 Jul '25

Hi there, I've created a posixAccount with a userPassword and can login using this user over SSH, the issue is that although "Allow Users to Change their Passwords" is selected in General Settings, I only managed to allow a user to change their own password by writing an ACI: (target="ldap:///cn=jack,ou=users,dc=lab")(targetattr="userPassword")(version 3.0; acl "password"; allow(write) userdn="ldap:///cn=jack,ou=users,dc=lab";) I'm hoping to not need an ACI for each user if there's a better way? Thanks Arnaud

3 6

How are you using the PAM PTA plugin? Survey
by Mark Reynolds 26 May '25

26 May '25

Hi Everyone, We are curious how everyone is using the PAM PTA plugin. There are basically two ways to configure the plugin, and they somewhat conflict with one another. Previous to 2012 you could only configure the plugin through the main plugin entry under cn=config: cn=PAM Pass Through Auth,cn=plugins,cn=config But after 2012 we added "config" child entries under the main plugin entry: cn=config, cn=PAM Pass Through Auth,cn=plugins,cn=config For backwards compatibility we still allowed users to use the main plugin entry although the child entry approach is what we wanted to use moving forward. So we've had this dual configuration approach and the CLI/UI weren't handling both correctly. Anyway we'd like to make this consistent and only allow the child entry config, but we'd like to know how everyone is using the PAM PTA plugin. Are you using the main config entry, or are you using the child entry approach? Thanks in advance for sharing your input! -- Identity Management Development Team

3 2

Rhel 9.4 389-DS 2.4.5 Provider fails to fully initialize Rhel 9.4 389-DS 2.4.5 Consumer database.
by Timothy Bouvet 18 May '25

18 May '25

389 community, We are currently testing an upgrade of our LDAP infrastructure centos 7.9 389-ds-1.3.11.1-5.el7_9 to Rhel 9.4 389-ds 2.4.5-9.el9_4. We are wanting to use the replication method to upgrade alongside production and not fully shutdown our center for the migration which would be impactful. The error I am reporting is for initialization of replicas by a rhel 9.x provider. Appears to be something related to rhel 9.x and 389-ds 2.x. Note: I have not seen any other issues besides replica initialization. Our site has run 389-DS for many years w/o issue and never have seen this issue before. I have done numerous tests to try and isolate this failure. I tried a smaller database and it still fails. different providers and consumers have the same error for rhel 9.x Provider. Rhel 9.4 389-DS 2.4.5-9 Provider fails to fully initialize Rhel 9.4 389-DS 2.4.5-9 Consumer database. A Rhel 8.10 provider 389-ds 2.4.5-1 can load our whole data base w/o error on the same consumer Rhel 9.4 389-DS 2.4.5-9 on port 636 LDAPS. I tried rhel 9.4 389-ds 2.4.5-1 (same version that worked on Rhel 8.10) and it fails to the same consumer. I tried changing ports and protocol on rhel 9.4 Provider - Port 636 LDAPS fails, 389 STARTTLS fails, 389 LDAP works on rhel9.4. The issue is rhel 9.x provider initializing database on rhel 9.4 consumer (fails Sending 33552 entries with TLS). I have tried restricting Provider and consumer to TLS 1.2 then TLS 1.3 and both fail. I tried tuning nsds5ReplicaFlowControlWindow and Debug logs show it gets past the authentication piece and starts to load the consumer and then gets ERR – factory destructor - ERROR bulk import abandoned on consumer. The Provider shows Error "Failed to send extended operation: LDAP error 51 (Server is busy)". I did try tuning nsds5ReplicaFlowControlWindow and nsds5ReplicaFlowControlPause with various values with little success. I also worry is I start slowing down the Provider to replica traffic it will impact performance. The error logs below are with nsslapd-errorlog-level=24576 and default values for the mentioned tunables. LDAP Debug Provider Error Log: [13/Nov/2024:15:54:37.386325753 -0600] - DEBUG - NSMMReplicationPlugin - acquire_replica - agmt="cn=ldap-repb-test-ra" (ldap-repb-test:636): Replica was successfully acquired. [13/Nov/2024:15:54:37.388243309 -0600] - INFO - NSMMReplicationPlugin - repl5_tot_run - Beginning total update of replica "agmt="cn=ldap-repb-test-ra" (ldap-repb-test:636)". [13/Nov/2024:15:54:37.390191833 -0600] - DEBUG - NSMMReplicationPlugin - replica_subentry_check - replication keep alive entry <cn=repl keep alive 8,dc=ncsa,dc=illinois,dc=edu> already exists [13/Nov/2024:15:54:37.513840430 -0600] - ERR - NSMMReplicationPlugin - perform_operation - agmt="cn=ldap-repb-test-ra" (ldap-repb-test:636): Failed to send extended operation: LDAP error 51 (Server is busy) [13/Nov/2024:15:54:37.515818173 -0600] - DEBUG - NSMMReplicationPlugin - check_flow_control_tot_init - agmt="cn=ldap-repb-test-ra" (ldap-repb-test:636) - Invalid message ids [ msgid sent: -1, rcv: 5] [13/Nov/2024:15:54:37.519877720 -0600] - ERR - NSMMReplicationPlugin - repl5_tot_log_operation_failure - agmt="cn=ldap-repb-test-ra" (ldap-repb-test:636): Received error 51 (Server is busy): for total update operation LDAP Consumer (Replica) Error Log: [13/Nov/2024:15:54:37.345059927 -0600] - DEBUG - NSMMReplicationPlugin - replica_disable_replication - replica dc=ncsa,dc=illinois,dc=edu is acquired [13/Nov/2024:15:54:37.378553066 -0600] - INFO - bdb_instance_start - Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [13/Nov/2024:15:54:37.383226816 -0600] - DEBUG - bdb_ldbm_back_wire_import - bdb_bulk_import_start returned 0 [13/Nov/2024:15:54:37.383985431 -0600] - DEBUG - NSMMReplicationPlugin - multisupplier_extop_StartNSDS50ReplicationRequest - encoded response: 0 [13/Nov/2024:15:54:37.384635904 -0600] - DEBUG - NSMMReplicationPlugin - multisupplier_extop_StartNSDS50ReplicationRequest - Finished encoding payload [13/Nov/2024:15:54:37.385240342 -0600] - DEBUG - NSMMReplicationPlugin - multisupplier_extop_StartNSDS50ReplicationRequest - conn=162194 op=3 repl="dc=ncsa,dc=illinois,dc=edu": StartNSDS90ReplicationRequest: response=0 rc=0 [13/Nov/2024:15:54:37.385907940 -0600] - DEBUG - NSMMReplicationPlugin - consumer_connection_extension_relinquish_exclusive_access - conn=162194 op=3 Relinquishing consumer connection extension [13/Nov/2024:15:54:37.390220175 -0600] - DEBUG - bdb_ldbm_back_wire_import - bdb_bulk_import_queue returned 0 with entry dc=ncsa,dc=illinois,dc=edu [13/Nov/2024:15:54:37.505440971 -0600] - DEBUG - bdb_ldbm_back_wire_import - bdb_bulk_import_queue returned 0 with entry cn=Directory Administrators,dc=ncsa,dc=illinois,dc=edu [13/Nov/2024:15:54:37.507799711 -0600] - DEBUG - bdb_ldbm_back_wire_import - bdb_bulk_import_queue returned 0 with entry ou=Groups,dc=ncsa,dc=illinois,dc=edu [13/Nov/2024:15:54:37.509710361 -0600] - DEBUG - bdb_ldbm_back_wire_import - bdb_bulk_import_queue returned 0 with entry ou=People,dc=ncsa,dc=illinois,dc=edu [13/Nov/2024:15:54:37.511664842 -0600] - DEBUG - bdb_ldbm_back_wire_import - bdb_bulk_import_queue returned 0 with entry cn=repl keep alive 5,dc=ncsa,dc=illinois,dc=edu [13/Nov/2024:15:54:37.513327884 -0600] - DEBUG - bdb_ldbm_back_wire_import - bdb_bulk_import_queue returned 0 with entry ou=resource_delta,dc=ncsa,dc=illinois,dc=edu [13/Nov/2024:15:54:37.514630160 -0600] - DEBUG - bdb_ldbm_back_wire_import - bdb_bulk_import_queue returned 0 with entry ou=resource_vforge,dc=ncsa,dc=illinois,dc=edu [13/Nov/2024:15:54:37.516008120 -0600] - DEBUG - bdb_ldbm_back_wire_import - bdb_bulk_import_queue returned 0 with entry ou=resource_holli,dc=ncsa,dc=illinois,dc=edu .. .. .. [13/Nov/2024:15:54:37.530146158 -0600] - DEBUG - bdb_ldbm_back_wire_import - bdb_bulk_import_queue returned 0 with entry cn=PD Managers,ou=Groups,dc=ncsa,dc=illinois,dc=edu [13/Nov/2024:15:54:37.542448330 -0600] - ERR - factory_destructor - ERROR bulk import abandoned [13/Nov/2024:15:54:37.584123281 -0600] - ERR - bdb_import_run_pass - import userroot: Thread monitoring returned: -23 [13/Nov/2024:15:54:37.585520872 -0600] - ERR - bdb_public_bdb_import_main - import userroot: Aborting all Import threads... [13/Nov/2024:15:54:43.494296253 -0600] - ERR - bdb_public_bdb_import_main - import userroot: Import threads aborted. [13/Nov/2024:15:54:43.496403618 -0600] - INFO - bdb_public_bdb_import_main - import userroot: Closing files... [13/Nov/2024:15:54:43.503149502 -0600] - ERR - bdb_public_bdb_import_main - import userroot: Import failed. [13/Nov/2024:15:54:43.506359910 -0600] - DEBUG - NSMMReplicationPlugin - consumer_connection_extension_destructor - Aborting total update in progress for replicated area dc=ncsa,dc=illinois,dc=edu connid=162194 [13/Nov/2024:15:54:43.507738378 -0600] - ERR - process_bulk_import_op - NULL target sdn [13/Nov/2024:15:54:43.509027437 -0600] - DEBUG - NSMMReplicationPlugin - replica_relinquish_exclusive_access - conn=162194 op=-1 repl="dc=ncsa,dc=illinois,dc=edu": Released replica held by locking_purl=conn=162194 id=3 -Tim

6 6

Referral during replication initialization
by Filip Slunecko 28 Apr '25

28 Apr '25

Hi, I have been trying to figure out how to set referrals during replication initialization. When a consumer starts initialization any ldapsearch gets back this. Referral (10) Matched DN: dc=example,dc=com Referral: ldap://supplier-001.example.com:389 Referral: ldap://supplier-002.example.com:389 Is it possible to change it? The problem is that * We do not run suppliers on non-ssl ports and we want to remove non-ssl from consumers too. * I do not want to point the traffic to suppliers when a server replicates. A workaround is to remove the server from the rotation, but it would be awesome to use referral for it. It makes everything much easier. I tried to set referral, like this: dsconf -D "cn=Directory Manager" ldaps://${hostname} config replace nsslapd-referral="ldaps://supplier-001.example.com:636/" -d 1 but that works only for non dc=example,dc=com domains. Thanks! Filip

1 0

Cant edit ACIs after importing database
by Julian Kippels 28 Mar '25

28 Mar '25

Hi, I just installed a completely fresh system and created a new instance of 389 with a single database (userroot). When I use this database everything works as expected. But after I imported an ldif-file which was exported from another instance of 389 (same version number) I can't edit/add/delete any ACIs anymore. Everything just stalls. This happenes both when I use ldapmodify and using the cockpit web interface. Editing other entries still works, I have only encountered this problem with ACI-entries so far. Does anyone have a clue what is happening here? Thanks Julian

2 1

New error messages with EL9
by Orion Poplawski 06 Mar '25

06 Mar '25

We recently updated all 6 of our IPA replicas to EL9 and so we're monitoring them closely for any issues. I've seen the following message in the slapd errors log a couple of times on different servers and am wondering if it is anything to be concerned about: [02/Feb/2025:20:27:54.176404718 -0700] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "dc=nwra,dc=com" (op=0x7f840be70e00 idx_pl=0) => op not changed in PL [02/Feb/2025:20:57:56.553507369 -0700] - ERR - decode_repl_ext_response - decoding failed: response_code (Ok) ruv_bervals (Ok) data_guid (Ok) data (Ok) bvdata (No data) [02/Feb/2025:20:57:56.555181048 -0700] - ERR - NSMMReplicationPlugin - release_replica - agmt="cn=IPA2-IPA1" (IPA1:389): Unable to parse the response to the endReplication extended operation. Thanks, Orion -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

2 7

Re: [Freeipa-users] Re: Deadlock in directory server,
by Thierry Bordaz 03 Mar '25

03 Mar '25

Hi Laurent, 389-Directory/3.1.1 B2024.289.0000 Looking at the stacktrace, i wonder if there is a possible deadlock in retroCL triming. Where thread 4 acquired the cn=changelog backend lock then hang for a write TXN and thread 20 created a write TXN (blocking thread 4) and wait for cn=changelog backend lock. Thread 4 (Thread 0x7f680c2b56c0 (LWP 3980786) "ns-slapd"): #0 0x00007f6d14081332 in __pthread_mutex_lock_full () at target:/lib64/libc.so.6 #1 0x00007f6d0f6b6bd2 in mdb_txn_renew0 () at target:/lib64/liblmdb.so.0.0.0 #2 0x00007f6d0f6b73c4 in mdb_txn_begin () at target:/lib64/liblmdb.so.0.0.0 #3 0x00007f6d0ef88b55 in dbmdb_start_txn () at target:/usr/lib64/dirsrv/plugins/libback-ldbm.so #4 0x00007f6d0ef8c745 in dbmdb_txn_begin () at target:/usr/lib64/dirsrv/plugins/libback-ldbm.so #5 0x00007f6d0ef113bd in dblayer_txn_begin () at target:/usr/lib64/dirsrv/plugins/libback-ldbm.so #6 0x00007f6d0ef3be7b in ldbm_back_delete () at target:/usr/lib64/dirsrv/plugins/libback-ldbm.so #7 0x00007f6d142297b4 in op_shared_delete.lto_priv () at target:/usr/lib64/dirsrv/libslapd.so.0 #8 0x00007f6d142ccd9d in delete_internal_pb.isra () at target:/usr/lib64/dirsrv/libslapd.so.0 #9 0x00007f6d14223f56 in slapi_delete_internal_pb () at target:/usr/lib64/dirsrv/libslapd.so.0 #10 0x00007f6d0ec095be in delete_changerecord () at target:/usr/lib64/dirsrv/plugins/libretrocl-plugin.so #11 0x00007f6d0ec0a853 in changelog_trim_thread_fn () at target:/usr/lib64/dirsrv/plugins/libretrocl-plugin.so #12 0x00007f6d13e4d3d7 in _pt_root () at target:/lib64/libnspr4.so #13 0x00007f6d1407e168 in start_thread () at target:/lib64/libc.so.6 #14 0x00007f6d1410214c in __clone3 () at target:/lib64/libc.so.6 Thread 20 (Thread 0x7f68025fe6c0 (LWP 3980449) "ns-slapd"): #0 0x00007f6d1407a7e9 in __futex_abstimed_wait_common () at target:/lib64/libc.so.6 #1 0x00007f6d1407d239 in pthread_cond_wait@@GLIBC_2.3.2 () at target:/lib64/libc.so.6 #2 0x00007f6d13e467db in PR_EnterMonitor () at target:/lib64/libnspr4.so #3 0x00007f6d0ef11405 in dblayer_txn_begin () at target:/usr/lib64/dirsrv/plugins/libback-ldbm.so #4 0x00007f6d0ef2bced in ldbm_back_add () at target:/usr/lib64/dirsrv/plugins/libback-ldbm.so #5 0x00007f6d142190f0 in op_shared_add.lto_priv () at target:/usr/lib64/dirsrv/libslapd.so.0 #6 0x00007f6d142cce7c in add_internal_pb.isra () at target:/usr/lib64/dirsrv/libslapd.so.0 #7 0x00007f6d142151d5 in slapi_add_internal_pb () at target:/usr/lib64/dirsrv/libslapd.so.0 #8 0x00007f6d0ec0bfd4 in retrocl_postob () at target:/usr/lib64/dirsrv/plugins/libretrocl-plugin.so #9 0x00007f6d1427b5c0 in plugin_call_func.lto_priv () at target:/usr/lib64/dirsrv/libslapd.so.0 #10 0x00007f6d1427b931 in plugin_call_plugins () at target:/usr/lib64/dirsrv/libslapd.so.0 #11 0x00007f6d0ef441cd in ldbm_back_modify () at target:/usr/lib64/dirsrv/plugins/libback-ldbm.so #12 0x00007f6d14267360 in op_shared_modify.lto_priv () at target:/usr/lib64/dirsrv/libslapd.so.0 #13 0x00007f6d1426910e in do_modify () at target:/usr/lib64/dirsrv/libslapd.so.0 #14 0x000056425298e8bb in connection_threadmain () #15 0x00007f6d13e4d3d7 in _pt_root () at target:/lib64/libnspr4.so #16 0x00007f6d1407e168 in start_thread () at target:/lib64/libc.so.6 #17 0x00007f6d1410214c in __clone3 () at target:/lib64/libc.so.6 At the same time, I wonder if it could be related to https://github.com/389ds/389-ds-base/issues/6644. Could you try to disable retroCL trimming to see if can give a relief. best regards thierry On 3/3/25 9:04 AM, Florence Blanc-Renaud via FreeIPA-users wrote: > Hi, > > you can reach out the directory server developers at > 389-users(a)lists.fedoraproject.org. > They will ask you to provide logs obtained as described here > <https://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs> > (Debugging Hangs), with the exact version and OS you have installed on > your machines. > > flo > > On Sat, Mar 1, 2025 at 7:33 PM ARNAL Laurent via FreeIPA-users > <freeipa-users(a)lists.fedorahosted.org> wrote: > > Hello, > > Some more infos : I've reinstalled the replica this afternoon. > Now the replication seems to work ok again. > But I've still have the deadlock after that. > > Laurent. > -- > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to > freeipa-users-leave(a)lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > >

1 0

Odd behavior on dsconf backend export
by CHAMBERLAIN James 28 Feb '25

28 Feb '25

When I back up my directory server, I see a bunch of entries in the resulting LDIF which only include the RDN rather than the full DN. Here is one example: # entry-id: 3 dn: ou=Groups nsUniqueId: 59ac5a03-1dce11ee-ae5b886f-9de8b2ea objectClass: top objectClass: organizationalunit ou: Groups creatorsName: cn=directory manager modifiersName: cn=directory manager createTimestamp: 20230708203145Z modifyTimestamp: 20230708203145Z I can’t find that entry when I search for its nsUniqueId. Restoring the LDIF to a new DS on a fresh OS install must put the entries in there, as they show up in the new system's backups; but ldapsearch can’t find them and affected user accounts are unusable. The command I’m using for the backup is: /usr/sbin/dsconf -D "$bind_dn" -y $pass_file ldap://localhost backend export -l $ldif_file userRoot The command for restores is likewise: /usr/sbin/dsconf -vvv -D "$bind_dn" -y $pass_file ldap://localhost backend import userRoot $ldif_file We loop checking the status of the import task, and when it has completed run a reindex. The LDIF file has 16,000 entries: 10000 with “good” DNs and 6000 with “bad” DNs: $ grep "^dn:" userRoot-latest.ldif | grep ',' | wc -l 9953 $ grep "^dn:" userRoot-latest.ldif | grep -v ',' | wc -l 5957 My system is running Rocky Linux 8.10 with 389-ds-base-2.0.15-1.module_el8+14185+adb3f555.x86_64. Anyone have any idea what’s going on, and how I might fix it? Have I missed something in the documentation? Thanks, James This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged. If you are not one of the named recipients or have received this email in error, (i) you should not read, disclose, or copy it, (ii) please notify sender of your receipt by reply email and delete this email and all attachments, (iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email. Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer https://www.3ds.com/privacy-policy/contact/

1 0

Debugging schema replication errors
by John Thurston 19 Feb '25

19 Feb '25

We have a three-server installation; one R/W, replicating to two R/O instances. They are running 389-Directory/2.5.2 On the R/W instance, we are seeing a steady stream of errors of like: > ERR - NSMMReplicationPlugin - agmt="cn=S1" (az1:636): Schema > replication update failed: Constraint violation > ERR - NSMMReplicationPlugin - agmt="cn=S1" (az1:636): Warning: unable > to replicate schema: rc=1 for both replication targets (i.e. both S1 and S2) I've exported, and examined, the replication change log. I don't see anything in it I don't expect to see. It's full of normal, day-to-day attribute adjustments. I think the next step is enabling replication logging on a consumer. And I think this is accomplished by adding 8,192 to the value in nsslapd-errorlog-level of cn=config On our test servers, I've found I can change this value by stopping the instance and editing the dse.ldif Is there another way to do this which does not require stopping and starting the instance? -- -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston(a)alaska.gov Department of Administration State of Alaska

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users