389-users March 2023

389-users@lists.fedoraproject.org

8 participants
8 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 11 Dec '23

11 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

Crash with SEGV after compacting
by Niklas Schmatloch 12 Jul '23

12 Jul '23

Hi My organisation is using a replicated 389-dirsrv. Lately, it has been crashing each time after compacting. It is replicable on our instances by lowering the compactdb-interval to trigger the compacting: dsconf -D "cn=Directory Manager" ldap://127.0.0.1 -w 'PASSWORD_HERE' backend config set --compactdb-interval 300 This is the log: [03/Aug/2022:16:06:38.552781605 +0200] - NOTICE - checkpoint_threadmain - Compacting DB start: userRoot [03/Aug/2022:16:06:38.752592692 +0200] - NOTICE - bdb_db_compact_one_db - compactdb: compact userRoot - 8 pages freed [03/Aug/2022:16:06:44.172233009 +0200] - NOTICE - bdb_db_compact_one_db - compactdb: compact userRoot - 888 pages freed [03/Aug/2022:16:06:44.179315345 +0200] - NOTICE - checkpoint_threadmain - Compacting DB start: changelog [03/Aug/2022:16:13:18.020881527 +0200] - NOTICE - bdb_db_compact_one_db - compactdb: compact changelog - 458 pages freed dirsrv(a)auth-alpha.service: Main process exited, code=killed, status=11/SEGV dirsrv(a)auth-alpha.service: Failed with result 'signal'. dirsrv(a)auth-alpha.service: Consumed 2d 6h 22min 1.122s CPU time. The first steps are done very quickly, but the step before the 458 pages of the retro-changelog are freed, takes several minutes. In this time the dirsrv writes more than 10 G and reads more than 7 G (according to iotop). After this line is printed the dirsrv crashes within seconds. What I also noticed is, that even though it said it freed a lot of pages the retro-changelog does not seem to change in size. The file `/var/lib/dirsrv/slapd-auth-alpha/db/changelog/id2entry.db` is 7.2 G before and after the compacting. Debian 11.4 389-ds-base/stable,now 1.4.4.11-2 amd64 Does someone have an idea how to debug / fix this? Thanks

4 15

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

2.x query performance problem
by Claas Vieler 30 Mar '23

30 Mar '23

3 15

Multiple 389DS instances on Kubernetes
by Ronald Wimmer 22 Mar '23

22 Mar '23

Does it make sense to run multiple 389DS pods on Kubernetes and set up replication amongst them manually as described in https://directory.fedoraproject.org/docs/389ds/howto/howto-deploy-389ds-on-… What are your thoughts? Cheers, Ronald

1 0

Migration from OpenLDAP to 389 Directory Server Failed
by Kresna Satya 14 Mar '23

14 Mar '23

Hi everyone, currently I would like to move the LDAP tool from OpenLDAP and 389 Directory Server. The data and configuration are saved in OpenLDAP and I would like to migrate to 389 Directory Server. So far, migration runs well but after migration I cannot see the data in 389 Directory Server. My environment server: - Ubuntu 22.04 in WSL 2. - OpenLDAP version 2.5.13 (run slapd -VV) - 389 Directory Server version 2.0.15-1 ( <https://packages.ubuntu.com/jammy/389-ds> https://packages.ubuntu.com/jammy/389-ds) Here's my GitHub repo to reproduce the migration steps from OpenLDAP to 389 Directory Server: <https://github.com/kresnasatya/migrate-openldap-to-389-ds-failed> https://github.com/kresnasatya/migrate-openldap-to-389-ds-failed I also follow the YouTube tutorial from this video presented by William Brown https://www.youtube.com/watch?v=qrbtWOXOhtA. Unfortunately, it doesn't work after the migration step. Could you please guide me how to solve the problem? Thank you.

3 4

Replication agreements creation order
by Alberto Crescente 13 Mar '23

13 Mar '23

Hello, I would like to create a three nodes cluster with multi-master system, but when I go to define the agreements between nodes I get different results depending on the order in which I create the agreements. The nodes hostname are test-389-ds-1, test-389-ds-2 and test-389-ds-3. If I define the agreements in the following order, some replications fail after the last agreement creation: test-389-ds-1 -> test-389-ds-2 test-389-ds-2 -> test-389-ds-1 test-389-ds-1 -> test-389-ds-3 test-389-ds-3 -> test-389-ds-1 test-389-ds-2 -> test-389-ds-3 If I define the agreements in the following order, all is ok: test-389-ds-1 -> test-389-ds-2 test-389-ds-2 -> test-389-ds-1 test-389-ds-1 -> test-389-ds-3 test-389-ds-2 -> test-389-ds-3 test-389-ds-3 -> test-389-ds-1 test-389-ds-3 -> test-389-ds-2 Error log test-389-ds-1 [10/Mar/2023:18:26:01.268922410 +0100] - ERR - agmt="cn=agreement-test-389-ds-1-to-test-389-ds-2" (test-389-ds-2:636) - clcache_load_buffer - Can't locate CSN 640b564b000100030000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [10/Mar/2023:18:26:01.272854351 +0100] - ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl - agmt="cn=agreement-test-389-ds-1-to-test-389-ds-2" (test-389-ds-2:636): CSN 640b564b000100030000 not found, we aren't as up to date, or we purged [10/Mar/2023:18:26:01.273957365 +0100] - ERR - NSMMReplicationPlugin - send_updates - agmt="cn=agreement-test-389-ds-1-to-test-389-ds-2" (test-389-ds-2:636): Data required to update replica has been purged from the changelog. If the error persists the replica must be reinitialized. Error log test-389-ds-2 [10/Mar/2023:17:14:47.939971206 +0100] - INFO - NSMMReplicationPlugin - repl5_tot_run - Finished total update of replica "agmt="cn=agreement-test-389-ds-2-to-test-389-ds-3" (test-389-ds-3:636)". Sent 15 entries. [10/Mar/2023:18:13:11.579175020 +0100] - INFO - task_export_thread - Beginning export of 'userroot' [10/Mar/2023:18:13:11.581387379 +0100] - INFO - bdb_db2ldif - export userroot: Processed 17 entries (100%). [10/Mar/2023:18:13:11.582475585 +0100] - INFO - task_export_thread - Export finished. Error log test-389-ds-3 [10/Mar/2023:18:27:29.275950935 +0100] - ERR - agmt="cn=agreement-test-389-ds-3-to-test-389-ds-1" (test-389-ds-1:636) - clcache_load_buffer - Can't locate CSN 640b564d000000030000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [10/Mar/2023:18:27:29.277963218 +0100] - ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl - agmt="cn=agreement-test-389-ds-3-to-test-389-ds-1" (test-389-ds-1:636): CSN 640b564d000000030000 not found, we aren't as up to date, or we purged [10/Mar/2023:18:27:29.283542396 +0100] - ERR - NSMMReplicationPlugin - send_updates - agmt="cn=agreement-test-389-ds-3-to-test-389-ds-1" (test-389-ds-1:636): Data required to update replica has been purged from the changelog. If the error persists the replica must be reinitialized. # ds-replcheck offline -b dc=test,dc=com -m tmp/test-389-ds-1.ldif -r tmp/test-389-ds-2.ldif --rid 1 ... Missing Entries ===================================================== Entries missing on Replica: - cn=repl keep alive 3,dc=test,dc=com (Created on Supplier at: Fri Mar 10 16:09:47 2023) Entry Inconsistencies ===================================================== cn=repl keep alive 1,dc=test,dc=com ---------------------------------------- - Attribute 'keepalivetimestamp' is different: Supplier: - Value: 20230310171215Z - State Info: keepalivetimestamp;adcsn-640b64ef000000010000;vucsn-640b64ef000000010000: 20230310171215Z - Date: Fri Mar 10 18:12:15 2023 Replica: - Value: 20230310161215Z - State Info: keepalivetimestamp;adcsn-640b56df000000010000;vucsn-640b56df000000010000: 20230310161215Z - Date: Fri Mar 10 17:12:15 2023 Is there a method to know the correct sequence of definition of the agreements? Regards, Alberto.

3 5

Problem with 389-ds authentication
by Mr Mysteron 08 Mar '23

08 Mar '23

Hi. I'm running two 389-ds instances on Centos9 servers, one master and one readonly slave server. Global pwpolicy is PBKDF2_SHA256 and local pwpolicy is SSHA512. The mail-servers are querying the readonly slave server for LDAP data. All servers are using TLS for encryption. I'm running a two mail servers, one for incoming mail with Dovecot as an imap frontend and one for Postfix smtp with Dovecot as a SASL authentication backend. The Dovecot imap server has been running LDAP authentication flawlessly, but I recently switched the Postfix smtp server over to Dovecot SASL authentication. Here's when everything started taking an interesting turn. The incoming Dovecot imap server is set to do an authentication bind: auth_bind = yes while the smtp server with Postfix + Dovecot SASL authentication does not do an auth_bind. The authentication process started failing on the smtp server with the following error message for every authenticated user: dovecot[721505]: auth: Error: ldap(USERNAME): Unknown scheme PBKDF2-SHA512 Changing password for a user will allow authentication against the LDAP from the smtp server, but when the imap server authenticates and use auth_bind, then no LDAP authentication is possible do on the smtp server and the above error message appears again for the user. I found out, that when I also use auth_bind for Dovecot on the smtp server everything works. What I hope someone could explain for me is, what's happening with the slave queries against the 389-ds ro server instance when the imap server authenticates the user with auth_bind enabled and the smtp server cannot authenticate the user when auth_bind is not enabled. The servers are binding prior to auth_bind with a dn = cn=binduser,ou=bindaccount,dc=example,dc=com user so that part is working as intended. Thank you. BR, /MrM

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users March 2023