389-users October 2022

389-users@lists.fedoraproject.org

9 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

DS not recognizing credentials after OS upgrade ( 389-ds 1.3.10.2-16)
by Ghiurea, Isabella 27 Oct '22

27 Oct '22

HI we are running 2 DS in multi master replication , this week the Sysadmin decided to apply OS patches updates on both servers, after patches applied one DS is working fine with no issues and one is back online but we can not access DS or run ldap search or import , no errors just plain "invalid credentials" ,, any help where to look for ? here is the version info: OS on both hosts :Linux 3.10.0-1160.76.1.el7.x86_64 #1 SMP Wed Aug 10 16:21:17 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux ####Before OS patches both of each servers were running : 389-ds-base-1.3.10.2-14.el7_9.x86_64 389-ds-console-1.2.16-1.el7.noarch 389-ds-base-libs-1.3.10.2-14.el7_9.x86_64 ############################################################? #####After OS patches running: 389-ds-base-1.3.10.2-16.el7_9.x86_64 389-ds-base-libs-1.3.10.2-16.el7_9.x86_64 389-ds-console-1.2.16-1.el7.noarch

1 0

389ds memory limits in kubernetes
by Juan R Moral 19 Oct '22

19 Oct '22

Hello, I have a StafulSet in Kubernetes based on https://directory.fedoraproject.org/docs/389ds/howto/howto-deploy-389ds-on-… I set a memory limit to 6Gi image: quay.io/389ds/dirsrv:latest ... limits: memory: "6Gi" Doing some performance test with 4k entries (query every entry in a loop), the used memory is increased on every test until kubernetes kills the pod (twentieth test aproximately). terminated Reason:Reason: OOMKilled - exit code: 0 Logs only shows NOTICE - ldbm_back_search - Unindexed search: search base="ou=myou,dc=XXX,dc=XXX" scope=2 filter="(objectClass=nsperson)" conn=18 op=46 when I get all entries in my ou ldapsearch -D "cn=directory manager" -W -b "ou=myou,dc=XXX,dc=XXX" -H ldap://localhost:3389 -s sub "(objectclass=nsPerson)" uid Maybe a tunning problem or a mem leak? Regards

2 5

Reminder - how to unsubscribe yourself
by Mark Reynolds 04 Oct '22

04 Oct '22

There have been a lot of people just sending "unsubscribe" messages to the list. At the bottom of every email from this list there is a link to unsubscribe yourself. I don't mind doing it, but it's very easy to do it yourself. Just a reminder... -- Directory Server Development Team

2 2

Fwd: 389 DS stop reponding
by jfdesir 03 Oct '22

03 Oct '22

Hi, I'am facing an issue that i can't solve. I have recently install two new LDAP servers (ubuntu 18.04 /389 DS 1.3.7.10) All about 12hours, the LDAP stop responding evenif the process is there. When i make a restart, it take a long time (so i have to kill the process). I have 2 old 389 (version 1.3.2.16) with the same base that function verry well Is there a knowed bug about that? Regards,

2 1

389ds and PKCS11 - how does 389ds read certificates/keys from p11kit?
by Graham Leggett 03 Oct '22

03 Oct '22

Hi all, 389ds as shipped by RHEL9 is linked to NSS, which in theory supports PKCS11, but in practice I can't get to work. Most specifically, when you display a 389ds NSS database using modutil, you see p11-kit-proxy (good), but it reports "There are no slots attached to this module” (bad). Has anyone got an explanation as to why this might be? [root@seawitch ~]# modutil -list -dbdir /etc/dirsrv/slapd-seawitch Listing of PKCS #11 Modules ----------------------------------------------------------- 1. NSS Internal PKCS #11 Module uri: pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.79 slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services uri: pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203 slot: NSS User Private Key and Certificate Services token: NSS Certificate DB uri: pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203 2. p11-kit-proxy library name: p11-kit-proxy.so uri: pkcs11:library-manufacturer=PKCS%2311%20Kit;library-description=PKCS%2311%20Kit%20Proxy%20Module;library-version=1.1 slots: There are no slots attached to this module status: loaded ————————————————————————————— At the very least the system and default CA databases should be visible, but alas no: [root@seawitch ~]# p11-kit list-modules p11-kit-trust: p11-kit-trust.so library-description: PKCS#11 Kit Trust Module library-manufacturer: PKCS#11 Kit library-version: 0.24 token: System Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.24 flags: token-initialized token: Default Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.24 flags: write-protected token-initialized Regards, Graham —

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users October 2022