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
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
—
5 months
Crash with SEGV after compacting
by Niklas Schmatloch
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
10 months, 1 week
DS not recognizing credentials after OS upgrade ( 389-ds 1.3.10.2-16)
by Ghiurea, Isabella
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 year, 6 months
389ds memory limits in kubernetes
by Juan R Moral
Hello,
I have a StafulSet in Kubernetes based on
https://directory.fedoraproject.org/docs/389ds/howto/howto-deploy-389ds-o...
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
1 year, 7 months
Reminder - how to unsubscribe yourself
by Mark Reynolds
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
1 year, 7 months
Fwd: 389 DS stop reponding
by jfdesir
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,
1 year, 7 months
389ds and PKCS11 - how does 389ds read certificates/keys from p11kit?
by Graham Leggett
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
—
1 year, 7 months
