389-users November 2024

389-users@lists.fedoraproject.org

8 participants
6 discussions

high 'wtime' with 2.4.5
by John Thurston 06 Dec '24

06 Dec '24

I have a new instance of 2.4.5, on which I'm seeing a very high* 'wtime' in the access log. From https://www.port389.org/docs/389ds/design/access-log-new-time-stats-design.… I read > * *wtime* - This is the amount of time the operation was waiting in > the work queue before being picked up by a worker thread. > Is this still an accurate description of 'wtime' ? If true, I suspect the high values I'm seeing have nothing to do with the version of the software I'm running, and everything to do with the system on which the software is running. Work has arrived, and been queued, but there aren't enough worker-threads to keep the queue serviced in a timely manner. * 'high' as in 3,000% longer than what I see on a totally different system running 1.4.4 -- -- 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 4

Problem updating IPA due to 389
by Sava Savchev 28 Nov '24

28 Nov '24

I am running two IPA servers in replication on Oraclelinux8 with version ipa-server-4.9.13-10.0.1 and 389-ds version 1.4.3.39-8 When I try to update IPA to ipa-server-4.9.13-12.0.2 it fails on ipa-server-upgrade due to dirsrv not starting: ipa-server-upgrade Upgrading IPA:. Estimated time: 1 minute 30 seconds [1/9]: saving configuration [2/9]: disabling listeners [3/9]: enabling DS global lock [4/9]: disabling Schema Compat [5/9]: starting directory server [error] CalledProcessError: CalledProcessError(Command ['/bin/systemctl', 'start', 'dirsrv@.service'] returned non-zero exit status 1: 'Job for dirsrv@.service failed because the control process exited with error code.\nSee "systemctl status dirsrv@.service" and "journalctl -xe" for details.\n') [cleanup]: stopping directory server [cleanup]: restoring configuration IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. Unexpected error - see /var/log/ipaupgrade.log for details: CalledProcessError: CalledProcessError(Command ['/bin/systemctl', 'start', 'dirsrv@.service'] returned non-zero exit status 1: 'Job for dirsrv@.service failed because the control process exited with error code.\nSee "systemctl status dirsrv@.service" and "journalctl -xe" for details.\n') The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information In dirsrv logs there is: ERR - NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd/cldb When I downgrade to the previous installed IPA version - 4.9.13-10.0.1, everything is back to normal. I have another cluster with the same configuration and I successfully updated. The only difference is that on the failing one I have enabled changelog encryption.

2 1

Rhel 9.4 389-DS 2.4.5 Provider fails to fully initialize Rhel 9.4 389-DS 2.4.5 Consumer database.
by Bouvet, Timothy A 22 Nov '24

22 Nov '24

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

1 0

root groups
by Michael DiDomenico 15 Nov '24

15 Nov '24

is there a restriction on what groups 389ds will return for user root? my ldap tree is working fine, all the normal users seem to be in the right groups as returned by getent/id, but when i query root it doesn't return any group info. a google search didn't pull anything immediately relevant, but i'm still looking thanks

2 2

Setting Up 389 DS Nodes for HAProxy Behind F5 Load Balancers
by Trevor Fong 15 Nov '24

15 Nov '24

Hi There, I'm trying to set up 389 DS nodes (2.4.5) for to use the Proxy protocol for HAProxy load-balancing behind F5 load-balancers. I've been following https://www.port389.org/docs/389ds/howto/howto-test-haproxy-ldaps.html and https://docs.redhat.com/en/documentation/red_hat_directory_server/12/html/c… . The Red Hat docs say "the nsslapd-haproxy-trusted-ip attribute configures the list of trusted proxy servers." I have at least 5 IP's I would need the 389 DS nodes to trust, but nsslapd-haproxy-trusted-ip does not want to accept a CIDR nor does it seem to accept multiple values. It also doesn't want to accept a comma delimited list of IP's. Does anyone know the correct syntax/setup for multiple HAProxy trusted IP's? Are there any further docs available? Thanks, Trev

2 4

Using modifyTimeStamp in queries
by tdarby＠arizona.edu 01 Nov '24

01 Nov '24

We have an application that needs to query for and return thousands of entries with modifyTimeStamp greater than a given time. This is turning out to be too slow for this app and so I'm wondering if there's any way to speed this up other than throwing more CPU at it. Tim Darby

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users November 2024