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
Builds for EL8 have a new home
by Viktor Ashirov
Hello,
epel-modular repository for EL8 was discontinued:
https://pagure.io/epel/issue/198
On February 15, 2023 EPEL 8 modules will be archived and removed:
https://lists.centos.org/pipermail/centos-devel/2022-October/120635.html
See the forwarded email below for more details.
This means we can no longer provide new upstream builds of 389-ds-base
through the EPEL repository.
Good news is that our copr repositories now have builds for EL8:
https://copr.fedorainfracloud.org/coprs/g/389ds/389-directory-server
https://copr.fedorainfracloud.org/coprs/g/389ds/389-directory-server-next
And if you have an existing installation using 389-directory-server module
from EPEL, you can switch to our copr repositories and reset the old module:
# dnf copr enable @389ds/389-directory-server
# dnf update 389-ds-base cockpit-389-ds
# dnf module reset 389-directory-server
In case of any issues, please let us know or open an issue at
https://github.com/389ds/389-ds-base/issues/new/choose
Thanks.
--
Viktor
---------- Forwarded message ---------
From: Troy Dawson <tdawson(a)redhat.com>
Date: Thu, Sep 29, 2022 at 12:10 AM
Subject: [CentOS-devel] EPEL 8 Modules get the axe on Halloween 2022
To: The CentOS developers mailing list. <centos-devel(a)centos.org>
When EPEL-8 was launched, it came with some support for modules with the
hope that a module ecosystem could be built from Fedora packages using RHEL
modules as an underlying tool. This has never happened and we have ended up
with a muddle of modular packages which will 'build' but may not install or
even run on an EL-8 system. Attempts to fix this and work within how EPEL
is normally built have been tried for several years by different people but
have not worked.
At this point we are saying that this experiment with modules in EPEL has
not worked and we will focus our resources on what does work.
Schedule of EPEL 8 Module Retirement:
Next Week:
- epel-release will be updated.
-- epel-modular will set enabled = 0
-- epel-modular full name will have "Deprecated" in it
October 31 2022:
- The EPEL 8 modules will be archived and removed.
-- The mirror manager will be pointed to the archive.
- Packagers will no longer be able to build EPEL 8 modules.
After October 31st (Actual date to be determined):
- epel-release will be updated again.
-- epel-modular repo configs will be removed.
Questions and Answers:
Question: Will I still be able to access the modules after October 31st?
Answer: It is not recommended, because the modules will not get any
security or bug fixes, but yes. They will be in the Fedora archives,
and the mirror managers will point at them.
Question: What will you be dressed as on Halloween?
Answer (Troy): A Penguin
EPEL Steering Committee
[1] - https://pagure.io/epel/issue/198
_______________________________________________
CentOS-devel mailing list
CentOS-devel(a)centos.org
https://lists.centos.org/mailman/listinfo/centos-devel
1 year, 5 months
Replication between 389-Directory and RHDS
by John Thurston
We have several instances of 389-Directory (1.4.4.17), and are
considering a move to Red Hat Directory Server 12.
The implementation in question has a single read-write instance, with
several read-only replicas. We could hail mary the whole thing to RHDS,
but the thought of that gives me deep shivers. I'd prefer to (one by
one) change out the replicas, letting the new RHDS instances be
populated from the existing 389-Directory instance.
Are 389-->RHDS replication agreements even possible?
Alternatively, are RHDS-->389 replication agreements possible?
--
--
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
1 year, 5 months
