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
2 months, 2 weeks
new dirsrv with RHEL9
by solarflow99
Hi, I am having a problem with a new dirsrv setup, getting a linux client
to authenticate with LDAP. I have done all the usual things to
troubleshoot, if anyone has seen this or knows what can be done I would
sure appreciate any help. Here's what i'm noticing:
- I need to have the bind_dn of Directory Manager specified to lookup
almost anything in LDAP, not sure why this is?
- sssd can find a sample user I created but still there seems to be a
problem, it looks like PAM but I did use authselect to use the sss profile:
$ *ldapsearch -x -LLL -D "cn=Directory Manager" -W -b ou=people,o=solarflow
-H ldap://dev2.local '(uid=john)' cn gidNumber userPassword*
Enter LDAP Password:
dn: uid=john,ou=people,o=solarflow
cn: John Smith
gidNumber: 10001
userPassword:: e1BCS0RGMixxxxxxx...xxx==
*$ sssctl domain-status ldap*
Online status: Online
Active servers:
LDAP: dev2.local
Discovered LDAP servers:
- dev2.local
localhost ~* $ sssctl user-checks john*
user: john
action: acct
service: system-auth
sss_getpwnam_r failed with [0].
User name lookup with [john] failed.
SSSD InfoPipe user lookup result:
- name: john
- uidNumber: 10001
- gidNumber: 10001
- gecos: John Smith
- homeDirectory: /home/john
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: User not known to the underlying authentication module
PAM Environment:
- no env -
localhost ~ *$ getent passwd john*
localhost ~ *$ id john*
id: ‘john’: no such user
*$ authselect current*
Profile ID: sssd
Enabled features:
- with-mkhomedir
- with-pamaccess
- with-sudo
*Here is my sssd.conf:*
[sssd]
config_file_version = 2
domains = LDAP
#services=pam
debug_level = 6
[domain/LDAP]
id_provider = ldap
auth_provider = ldap
#chpass_provider = ldap
ldap_uri = ldap://dev2.local
ldap_search_base = o=solarflow
ldap_default_bind_dn = cn=Directory Manager
ldap_default_authtok = my_secret_password
cache_credentials = True
debug_level = 6
3 months, 1 week
Unable to establish replication with STARTTLS
by John Thurston
I have two hosts with 389-Directory/1.4.4.17 B2021.280.1354 on CentOS
Stream release 8 (4.18.0-448.el8.x86_64)
On a.state.ak.us, there is one instance defined (call this instance #1)
On b.state.ak.us, there are two instances defined (call them #2 and #3)
Instances #1 and #3 have GlobalSign certificates installed. Instance #2
currently has a Let's Encrypt certificate installed. All instances also
have root and intermediate certs in their databases for GlobalSign,
which are marked with Trust Flags "CT,,".
I can define instance #2 as a supplier, and define a replication
agreement which populates #3. This works with both LDAPS and STARTTLS.
If I, instead, try to define the same replication agreement on instance
#1, it fails with:
> slapi_ldap_bind - Error: could not send startTLS request: error -11
> (Connect error)
>
> NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=DS11-1to3"
> (b:389) - Replication bind with SIMPLE auth failed: LDAP error -11
> (Connect error) (error:1416F086:SSL
> routines:tls_process_server_certificate:certificate verify failed
> (unable to get issuer certificate))
>
> slapi_ldap_bind - Error: could not send startTLS request: error -11
> (Connect error)
I am unable to figure out how instances #1 and #2 differ.
Instance #1 has long-established supplier-agreements (using both LDAPS
and STARTTLS) with other instances of 389-Directory. So I know instance
#1 can function correctly as a supplier. Instance #3 demonstrates it can
be a consumer when supplied by instance #2. I can perform LDAPS and
STARTTLS queries from a.state.ak.us to instance #3, so I know it is
listening on the network and not blocked by a host-based firewall.
Any suggestions of where to look, or config-attributes to check, would
be appreciated.
--
--
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
3 months, 3 weeks
Access to 389-ds in Cockpit without sudo to root
by Brian Mattey (UK)
Hi,
I would like to grant a non-privileged user (cannot sudo to root) access to 389-ds configuration in Cockpit. (I've googled a _lot_ for this and can't find any way to do it).
Thanks,
Brian
3 months, 3 weeks