389-users December 2022

389-users@lists.fedoraproject.org

4 participants
5 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

Builds for EL8 have a new home
by Viktor Ashirov 14 Dec '22

14 Dec '22

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

2 2

Replication between 389-Directory and RHDS
by John Thurston 06 Dec '22

06 Dec '22

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

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users December 2022