389-users July 2022

389-users@lists.fedoraproject.org

9 participants
9 discussions

Disable Anonymous Bind
by Christian Palacios 29 Jul '22

29 Jul '22

Hi there, We have an instance of 389 and I have been asked to disable anonymous bind on it because our current security policies don't allow it. Can you please suggest ways to fix this? Unfortunately, I don't have the admin account, so I'm hoping to also get help with that. Thank you, -Christian

4 6

Announcing 389 Directory Server 2.1.4
by Mark Reynolds 28 Jul '22

28 Jul '22

389 Directory Server 2.1.4 The 389 Directory Server team is proud to announce 389-ds-base version 2.1.4 Fedora packages are available on Fedora 36 http://koji.fedoraproject.org/koji/buildinfo?buildID=2038470 <http://koji.fedoraproject.org/koji/buildinfo?buildID=2038470> https://bodhi.fedoraproject.org/updates/FEDORA-2022-233e21f455 <https://bodhi.fedoraproject.org/updates/FEDORA-2022-233e21f455>- Bodhi The new packages and versions are: * 389-ds-base-2.1.4-1 Source tarballs are available for download atDownload 389-ds-base Source <https://github.com/389ds/389-ds-base/archive/389-ds-base-2.1.4.tar.gz> Highlights in 2.1.4 * Bug fixes&RFEfor allowingECDSAprivate keys * Transition fromBDB(libdb) toLMDBbegun.BDBis still the default backend, but it can be changed toLMDBfor early testing. Installation and Upgrade SeeDownload <https://www.port389.org/docs/389ds/download.html>for information about setting up your yum repositories. To install the server use*dnf install 389-ds-base* To install the CockpitUIplugin use*dnf install cockpit-389-ds* After rpm install completes, run*dscreate interactive* For upgrades, simply install the package. There are no further steps required. There are no upgrade steps besides installing the new rpms SeeInstall_Guide <https://www.port389.org/docs/389ds/howto/howto-install-389.html>for more information about the initial installation and setup SeeSource <https://www.port389.org/docs/389ds/development/source.html>for information about source tarballs andSCM(git) access. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list:https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproj… If you find a bug, or would like to see a new feature, file it in our GitHub project:https://github.com/389ds/389-ds-base * Bump version to 2.1.4 * Issue 5383 -UI- Various fixes andRFE’s for UI * Issue 4656 - Remove problematic language from source code * Issue 5380 - Separate cleanAllRUVcode into new file * Issue 5322 - optime&wtime on rejected connections is not properly set * Issue 5375 -CI- disableTLShostname checking * Issue 5373 - dsidm user get_dn fails with search_ext() argument 1 must be str, not function * Issue 5371 - Update npm and cargo packages * Issue 3069 -RFE- SupportECDSAprivate keys forTLS (#5365) -- Directory Server Development Team

1 0

Replcation failing since update to 389-ds-base-2.0.15-1.module_el8+14185+adb3f555.x86_64
by Brian Collins 20 Jul '22

20 Jul '22

Good day, We have an LDAP cluster on RHEL 8. We were running 1.4.4.17-1.module_el8+13163+e27841f7.x86_64 and recently updated to 2.0.15-1.module_el8+14185+adb3f555.x86_64. Since then, replication fails from any server to any other server. What I am seeing in /var/log/dirsrv/slapd-pro01/errors is: [19/Jul/2022:15:20:20.174222661 -0400] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=pro01topro02" (pro02:636) - Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) (TLS: hostname does not match subjectAltName in peer certificate) and [19/Jul/2022:15:46:41.092806631 -0400] - ERR - slapi_ldap_bind - Could not send bind request for id [cn=replication manager,cn=config] authentication mechanism [SIMPLE]: error -1 (Can't contact LDAP server), system error -5987 (Invalid function argument.), network error 0 (Unknown error, host " pro02.example.com:636") I regenerated and reinstalled the certs for pro01 and pro02, adding the SAN. But that did not help things any. Did I miss something in the update to v2? Thanks in advance, Brian Collins

2 2

Retro Changelog trimming causes deadlock
by Kees Bakker 20 Jul '22

20 Jul '22

Hi, It's me again, about Retro Changelog trimming :-(. Last time it was about the maxage configuration, for which I created an issue [1]. This time, the problem is that of a deadlock. When I have maxage set to 2d (the default), then soon after restart the server starts to do the trimming. Unfortunately it quickly runs into a deadlock. All accesses to the server (e.g ldapsearch) hang forever. And because this is a replica, the other servers are complaining too. Looking at a gdb stack trace I see the following. $ sudo cat gdb-trace-ns-slapd-4.txt | grep -E '^(Thread|#[01] .*lock)' Thread 41 (Thread 0x7fefa3e72700 (LWP 170190)): #0 0x00007fef9f9b52f5 in pthread_rwlock_wrlock () at target:/lib64/libpthread.so.0 #1 0x00007fef8e9f2750 in map_wrlock () at target:/usr/lib64/dirsrv/plugins/schemacompat-plugin.so Thread 40 (Thread 0x7feef147d700 (LWP 170184)): Thread 39 (Thread 0x7feeef2f9700 (LWP 170178)): Thread 38 (Thread 0x7feef1c7e700 (LWP 170171)): Thread 37 (Thread 0x7feef247f700 (LWP 170169)): Thread 36 (Thread 0x7feef37ff700 (LWP 170166)): Thread 35 (Thread 0x7feef67ff700 (LWP 170165)): Thread 34 (Thread 0x7feef75fe700 (LWP 170164)): #0 0x00007fef9f9b4ec2 in pthread_rwlock_rdlock () at target:/lib64/libpthread.so.0 #1 0x00007fef8e9f2612 in map_rdlock () at target:/usr/lib64/dirsrv/plugins/schemacompat-plugin.so Thread 33 (Thread 0x7feef7dff700 (LWP 170163)): Thread 32 (Thread 0x7feef89fe700 (LWP 170162)): #0 0x00007fef9f9b4ec2 in pthread_rwlock_rdlock () at target:/lib64/libpthread.so.0 #1 0x00007fef8e9f2612 in map_rdlock () at target:/usr/lib64/dirsrv/plugins/schemacompat-plugin.so Thread 31 (Thread 0x7feef91ff700 (LWP 170161)): #0 0x00007fef9f9b4ec2 in pthread_rwlock_rdlock () at target:/lib64/libpthread.so.0 #1 0x00007fef8e9f2612 in map_rdlock () at target:/usr/lib64/dirsrv/plugins/schemacompat-plugin.so Thread 30 (Thread 0x7feef9dfe700 (LWP 170160)): #0 0x00007fef9f9b4ec2 in pthread_rwlock_rdlock () at target:/lib64/libpthread.so.0 #1 0x00007fef8e9f2612 in map_rdlock () at target:/usr/lib64/dirsrv/plugins/schemacompat-plugin.so Thread 29 (Thread 0x7feefa7ff700 (LWP 170159)): Thread 28 (Thread 0x7feefb7ff700 (LWP 170158)): Thread 27 (Thread 0x7feefc3fe700 (LWP 170157)): #0 0x00007fef9f9b4ec2 in pthread_rwlock_rdlock () at target:/lib64/libpthread.so.0 #1 0x00007fef8e9f2612 in map_rdlock () at target:/usr/lib64/dirsrv/plugins/schemacompat-plugin.so Thread 26 (Thread 0x7feefcdff700 (LWP 170156)): #0 0x00007fef9f9b4ec2 in pthread_rwlock_rdlock () at target:/lib64/libpthread.so.0 #1 0x00007fef8e9f2612 in map_rdlock () at target:/usr/lib64/dirsrv/plugins/schemacompat-plugin.so Thread 25 (Thread 0x7feefe1fe700 (LWP 170155)): #0 0x00007fef9f9b4ec2 in pthread_rwlock_rdlock () at target:/lib64/libpthread.so.0 #1 0x00007fef8e9f2612 in map_rdlock () at target:/usr/lib64/dirsrv/plugins/schemacompat-plugin.so Thread 24 (Thread 0x7feefebff700 (LWP 170154)): #0 0x00007fef9f9b4ec2 in pthread_rwlock_rdlock () at target:/lib64/libpthread.so.0 #1 0x00007fef8e9f2612 in map_rdlock () at target:/usr/lib64/dirsrv/plugins/schemacompat-plugin.so Thread 23 (Thread 0x7feeff7da700 (LWP 170153)): Thread 22 (Thread 0x7feefffdb700 (LWP 170152)): #0 0x00007fef9f9b4ec2 in pthread_rwlock_rdlock () at target:/lib64/libpthread.so.0 #1 0x00007fef8e9f2612 in map_rdlock () at target:/usr/lib64/dirsrv/plugins/schemacompat-plugin.so Thread 21 (Thread 0x7fef007dc700 (LWP 170151)): Thread 20 (Thread 0x7fef00fdd700 (LWP 170150)): #0 0x00007fef9f9b4ec2 in pthread_rwlock_rdlock () at target:/lib64/libpthread.so.0 #1 0x00007fef8e9f2612 in map_rdlock () at target:/usr/lib64/dirsrv/plugins/schemacompat-plugin.so Thread 19 (Thread 0x7fef02fd9700 (LWP 170148)): Thread 18 (Thread 0x7fef037da700 (LWP 170147)): Thread 17 (Thread 0x7fef03fdb700 (LWP 170146)): Thread 16 (Thread 0x7fef049e3700 (LWP 170145)): Thread 15 (Thread 0x7fef051e4700 (LWP 170144)): Thread 14 (Thread 0x7fef059e5700 (LWP 170143)): Thread 13 (Thread 0x7fef071ff700 (LWP 170140)): Thread 12 (Thread 0x7fef081ff700 (LWP 170139)): Thread 11 (Thread 0x7fef08ffe700 (LWP 170138)): Thread 10 (Thread 0x7fef097ff700 (LWP 170137)): Thread 9 (Thread 0x7fefa3e93700 (LWP 170136)): Thread 8 (Thread 0x7fef0a5ff700 (LWP 170135)): Thread 7 (Thread 0x7fef0b3ff700 (LWP 170134)): Thread 6 (Thread 0x7fef0ca09700 (LWP 170133)): Thread 5 (Thread 0x7fef0d20a700 (LWP 170132)): Thread 4 (Thread 0x7fef0da0b700 (LWP 170131)): Thread 3 (Thread 0x7fef0e20c700 (LWP 170130)): Thread 2 (Thread 0x7fef0ea0d700 (LWP 170129)): Thread 1 (Thread 0x7fefa3f98240 (LWP 170127)): The version info: 389-ds-base-libs-1.4.3.28-6.module_el8.6.0+1102+fe5d910f.x86_64 389-ds-base-1.4.3.28-6.module_el8.6.0+1102+fe5d910f.x86_64 For the time being I have changed maxage to 200d, to avoid trimming, to avoid deadlock. But in the long run it causes to changelog to grow and grow. One server has over 2GB, another server has already more than 4GB in the changelog db. [1] https://github.com/389ds/389-ds-base/issues/5368 -- Kees

3 4

I have some problem with 389 Directory Server container project
by Hu, Xudong 18 Jul '22

18 Jul '22

Hello I want to ask a question with using 389ds/dirsrv 389 Directory Server Container in dockerhub when I use 389ds,the default login administrator is cn=Directory Manager,but I want to change or add another login username,How I shoud do?please help me! Thank you very much

1 0

Retro Changelog trimming not working
by Kees Bakker 14 Jul '22

14 Jul '22

Hi, Retro Changelog Trimming continues to give me headaches. In short, trimming does not work. The number of entries keep piling up. One server now has a 4Gb database (480 days of changelogs). Another server has about 2Gb (218 days). We were using rpm packages 389-ds-base-1.4.3.23-10.module_el8.5+946+51aba098.x86_64 389-ds-base-libs-1.4.3.23-10.module_el8.5+946+51aba098.x86_64 This version has a known problem [1], so I know that trimming does not work. This week I upgraded one system to 1.4.2.28-6.module_el8.6.0+1102+fe5d910f I'm a bit puzzled, trimming still doesn't work. With enabled debug I see this message about every five minutes. (Also a few debug lines after restart.) Jul 13 10:01:52 iparep4.example.com ns-slapd[140367]: [13/Jul/2022:10:01:52.304836309 +0200] - DEBUG - plugin_print_lists - Retro Changelog Plugin (precedence: 25) Jul 13 10:01:54 iparep4.example.com ns-slapd[140367]: [13/Jul/2022:10:01:54.286755784 +0200] - DEBUG - plugin_print_lists - Retrocl postoperation plugin (precedence: 25) Jul 13 10:02:12 iparep4.example.com ns-slapd[140367]: [13/Jul/2022:10:02:12.211710079 +0200] - DEBUG - plugin_dependency_startall - Starting object plugin Retro Changelog Plugin Jul 13 10:02:12 iparep4.example.com ns-slapd[140367]: [13/Jul/2022:10:02:12.566700485 +0200] - DEBUG - DSRetroclPlugin - cn=changelog already existed Jul 13 10:02:12 iparep4.example.com ns-slapd[140367]: [13/Jul/2022:10:02:12.604862146 +0200] - DEBUG - retrocl - Got changenumbers 15888 and 2578430 Jul 13 10:02:12 iparep4.example.com ns-slapd[140367]: [13/Jul/2022:10:02:12.661391716 +0200] - DEBUG - DSRetroclPlugin - retrocl_start - nsslapd-attribute: Jul 13 10:02:12 iparep4.example.com ns-slapd[140367]: [13/Jul/2022:10:02:12.694197373 +0200] - DEBUG - DSRetroclPlugin - retrocl_start - nsuniqueid:targetUniqueId Jul 13 10:02:12 iparep4.example.com ns-slapd[140367]: [13/Jul/2022:10:02:12.719301803 +0200] - DEBUG - DSRetroclPlugin - retrocl_start - Attributes: Jul 13 10:02:12 iparep4.example.com ns-slapd[140367]: [13/Jul/2022:10:02:12.744411445 +0200] - DEBUG - DSRetroclPlugin - - nsuniqueid [targetUniqueId] Jul 13 10:02:16 iparep4.example.com ns-slapd[140367]: [13/Jul/2022:10:02:16.294477996 +0200] - DEBUG - DSRetroclPlugin - retrocl_housekeeping - changelog does not need to be trimmed Jul 13 10:03:14 iparep4.example.com ns-slapd[140367]: [13/Jul/2022:10:03:14.217129558 +0200] - DEBUG - DSRetroclPlugin - retrocl_housekeeping - changelog does not need to be trimmed Jul 13 10:08:13 iparep4.example.com ns-slapd[140367]: [13/Jul/2022:10:08:13.902950611 +0200] - DEBUG - DSRetroclPlugin - retrocl_housekeeping - changelog does not need to be trimmed Jul 13 10:13:13 iparep4.example.com ns-slapd[140367]: [13/Jul/2022:10:13:13.193109483 +0200] - DEBUG - DSRetroclPlugin - retrocl_housekeeping - changelog does not need to be trimmed [root@iparep4 ~]# ldapsearch -H ldaps://$HOSTNAME -D "cn=Directory Manager" -y p -LLL -o ldif-wrap=no -b 'changenumber=15888,cn=changelog' changeNumber changeTime dn: changenumber=15888,cn=changelog changeNumber: 15888 changeTime: 20210317141532Z This is strange because on the other server with 1.4.3.23 I get these messages: Jul 12 11:17:19 rotte.example.com ns-slapd[2398871]: [12/Jul/2022:11:17:19.710733008 +0200] - DEBUG - DSRetroclPlugin - cltrim: ldrc=0, first_time=1638871758, cur_time=11908500 Jul 12 11:17:19 rotte.example.com ns-slapd[2398871]: [12/Jul/2022:11:17:19.711707843 +0200] - DEBUG - DSRetroclPlugin - retrocl_housekeeping - changelog does not need to be trimmed Jul 12 11:22:19 rotte.example.com ns-slapd[2398871]: [12/Jul/2022:11:22:19.910817088 +0200] - DEBUG - DSRetroclPlugin - cltrim: ldrc=0, first_time=1638871758, cur_time=11908800 Jul 12 11:22:19 rotte.example.com ns-slapd[2398871]: [12/Jul/2022:11:22:19.911893609 +0200] - DEBUG - DSRetroclPlugin - retrocl_housekeeping - changelog does not need to be trimmed [root@rotte ~]# ldapsearch -H ldaps://$HOSTNAME -D "cn=Directory Manager" -y p -LLL -o ldif-wrap=no -b 'changenumber=1,cn=changelog' changeNumber changeTime dn: changenumber=1,cn=changelog changeNumber: 1 changeTime: 20211207100918Z In other words, with 1.4.3.28 I don't get to see the message with first_time and cur_time. I'm quite puzzled how that can happen. The code is like this (stripped a bit): if (!ts.ts_s_trimming) { int must_trim = 0; /* See if we need to trim */ /* Has enough time elapsed since our last check? */ if (cur_time - ts.ts_s_last_trim >= (ts.ts_c_max_age)) { /* Is the first entry too old? */ time_t first_time; ... slapi_log_err(SLAPI_LOG_PLUGIN, RETROCL_PLUGIN_NAME, "cltrim: ldrc=%d, first_time=%ld, cur_time=%ld\n", ldrc, first_time, cur_time); if (LDAP_SUCCESS == ldrc && first_time > (time_t)0L && first_time + ts.ts_c_max_age < now_maxage) { must_trim = 1; } } if (must_trim) { ... } else { slapi_log_err(SLAPI_LOG_PLUGIN, RETROCL_PLUGIN_NAME, "retrocl_housekeeping - changelog does not need to be trimmed\n"); } } Puzzled, because I don't understand why "cur_time - ts.ts_s_last_trim >= (ts.ts_c_max_age)" is FALSE. [1] https://github.com/389ds/389-ds-base/issues/4869 -- Kees

3 7

Announcing 389 Directory Server 2.0.16
by Mark Reynolds 06 Jul '22

06 Jul '22

389 Directory Server 2.0.16 The 389 Directory Server team is proud to announce 389-ds-base version 2.0.16 Fedora packages are available on Fedora 35 Fedora 35: https://koji.fedoraproject.org/koji/taskinfo?taskID=89131293 <https://koji.fedoraproject.org/koji/taskinfo?taskID=89131293>- Koji https://bodhi.fedoraproject.org/updates/FEDORA-2022-f0087e233f <https://bodhi.fedoraproject.org/updates/FEDORA-2022-f0087e233f>- Bodhi The new packages and versions are: * 389-ds-base-2.0.16-1 Source tarballs are available for download atDownload 389-ds-base Source <https://github.com/389ds/389-ds-base/archive/389-ds-base-2.0.16.tar.gz> Highlights in 2.0.16 * Bug and Security fixes Installation and Upgrade SeeDownload <https://www.port389.org/docs/389ds/download.html>for information about setting up your yum repositories. To install the server use*dnf install 389-ds-base* To install the CockpitUIplugin use*dnf install cockpit-389-ds* After rpm install completes, run*dscreate interactive* For upgrades, simply install the package. There are no further steps required. There are no upgrade steps besides installing the new rpms SeeInstall_Guide <https://www.port389.org/docs/389ds/howto/howto-install-389.html>for more information about the initial installation and setup SeeSource <https://www.port389.org/docs/389ds/development/source.html>for information about source tarballs andSCM(git) access. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list:https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproj… If you find a bug, or would like to see a new feature, file it in our GitHub project:https://github.com/389ds/389-ds-base * Bump version to 2.0.16 * Issue 5221 - fix covscan (#5359) * Issue 4984 -BUG- pid file handling (#4986) * Issue 5353 -CLI- dsconf backend export breaks with multiple backends * Issue 5345 -BUG- openldap migration fails when ppolicy is active (#5347) * Issue 5323 -BUG- improve skipping of monitor db (#5340) * Issue 5323 -BUG- Fix issue in mdb tests with monitor (#5326) * Issue 5329 - Improve replication extended op logging * Issue 5343 - Various improvements to winsync * Issue 4932 -CLI- add parser aliases to long arg names * Issue 5332 -BUG- normalise filter as intended * Issue 5126 - Memory leak in slapi_ldap_get_lderrno (#5153) * Issue 5311 - Missing Requires for acl in the spec file * Issue 5333 - 389-ds-base fails to build with Python 3.11 * Issue 5170 -BUG- incorrect behaviour of filter test (#5315) * Issue 5324 - plugin acceptance test needs hardening * Issue 5323 -BUG- migrating database for monitoring interface lead to crash (#5321) * Issue 5304 - Need a compatibility option about sub suffix handling (#5310) * Issue 5302 - Release tarballs don’t contain cockpit webapp * Issue 5237 - audit-ci: Cannot convert undefined or null to object * Issue 5170 -BUG- ldapsubentries were incorrectly returned (#5285) * Issue 4970 - Add support for recursively deleting subentries * Issue 5284 - Replication broken after password change (#5286) * Issue 5291 - Harden ReplicationManager.wait_for_replication (#5292) * Issue 5279 - dscontainer: TypeError: unsupported operand type(s) for /: ‘str’ and ‘int’ * Issue 5170 -RFE- Filter optimiser (#5171) * Issue 5276 -CLI- improve task handling * Issue 5273 -CLI- add arg completer for instance name * Issue 2893 -CLI- dscreate - add options for setting up replication * Issue 4866 -CLI- when enabling replication set changelog trimming by default * Issue 5241 -UI- Add account locking missing functionality (#5251) * Issue 5180 - snmp_collator tries to unlockNULLmutex (#5266) * Issue 5098 - Fix cherry-pick error * Issue 4904 - Fix various small issues * Issue 5260 -BUG- OpenLDAPallows multiple names of memberof overlay (#5261) * Issue 5252 - DuringDEL, vlv search can erroneously returnNULLcandidate (#5256) * Issue 5210 - Python undefined names in lib389 * Issue 4959 -BUG- Invalid /etc/hosts setup can cause isLocalHost (#4960) * Issue 5249 - dscontainer: ImportError: cannot import name ‘get_default_db_lib’ from ‘lib389.utils’ * Issue 5242 - SECURITY_FIX- Craft message may crash the server (#5243) * Issue 5234 -UI- rename Users and Groups tab * Issue 5217 - Simplify instance creation and administration by non root user (#5224) * Issue 5227 -UI- No way to move back to Get Started step (#5233) -- Directory Server Development Team

1 0

Announcing 389 Directory Server 2.1.3
by Mark Reynolds 06 Jul '22

06 Jul '22

389 Directory Server 2.1.3 The 389 Directory Server team is proud to announce 389-ds-base version 2.1.3 Fedora packages are available on Fedora 36 https://koji.fedoraproject.org/koji/taskinfo?taskID=89124762 <https://koji.fedoraproject.org/koji/taskinfo?taskID=89124762> https://bodhi.fedoraproject.org/updates/FEDORA-2022-e9b27d8c48 <https://bodhi.fedoraproject.org/updates/FEDORA-2022-e9b27d8c48>- Bodhi The new packages and versions are: * 389-ds-base-2.1.3-1 Source tarballs are available for download atDownload 389-ds-base Source <https://github.com/389ds/389-ds-base/archive/389-ds-base-2.1.3.tar.gz> Highlights in 2.1.3 * Bug fixes * Transition fromBDB(libdb) toLMDBbegun.BDBis still the default backend, but it can be changed toLMDBfor early testing. Installation and Upgrade SeeDownload <https://www.port389.org/docs/389ds/download.html>for information about setting up your yum repositories. To install the server use*dnf install 389-ds-base* To install the CockpitUIplugin use*dnf install cockpit-389-ds* After rpm install completes, run*dscreate interactive* For upgrades, simply install the package. There are no further steps required. There are no upgrade steps besides installing the new rpms SeeInstall_Guide <https://www.port389.org/docs/389ds/howto/howto-install-389.html>for more information about the initial installation and setup SeeSource <https://www.port389.org/docs/389ds/development/source.html>for information about source tarballs andSCM(git) access. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list:https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproj… If you find a bug, or would like to see a new feature, file it in our GitHub project:https://github.com/389ds/389-ds-base * Bump version to 2.1.3 * Issue 5221 - fix covscan (#5359) * Issue 5353 -CLI- dsconf backend export breaks with multiple backends * Issue 5345 -BUG- openldap migration fails when ppolicy is active (#5347) * Issue 5323 -BUG- improve skipping of monitor db (#5340) * Issue 5323 -BUG- Fix issue in mdb tests with monitor (#5326) * Issue 5329 - Improve replication extended op logging * Issue 5343 - Various improvements to winsync * Issue 4932 -CLI- add parser aliases to long arg names * Issue 5332 -BUG- normalise filter as intended * Issue 5126 - Memory leak in slapi_ldap_get_lderrno (#5153) * Issue 5311 - Missing Requires for acl in the spec file * Issue 5333 - 389-ds-base fails to build with Python 3.11 -- Directory Server Development Team

1 0

Announcing 389 Directory Server 2.2.2
by Mark Reynolds 06 Jul '22

06 Jul '22

389 Directory Server 2.2.2 The 389 Directory Server team is proud to announce 389-ds-base version 2.2.2 Fedora packages are available on Rawhide (f37) Rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1996683 <https://koji.fedoraproject.org/koji/buildinfo?buildID=1996683> The new packages and versions are: * 389-ds-base-2.2.2-1 Source tarballs are available for download atDownload 389-ds-base Source <https://github.com/389ds/389-ds-base/archive/389-ds-base-2.2.2.tar.gz> Highlights in 2.2.2 * Enhancement, and Bug fixes Installation and Upgrade SeeDownload <https://www.port389.org/docs/389ds/download.html>for information about setting up your yum repositories. To install the server use*dnf install 389-ds-base* To install the CockpitUIplugin use*dnf install cockpit-389-ds* After rpm install completes, run*dscreate interactive* For upgrades, simply install the package. There are no further steps required. There are no upgrade steps besides installing the new rpms SeeInstall_Guide <https://www.port389.org/docs/389ds/howto/howto-install-389.html>for more information about the initial installation and setup SeeSource <https://www.port389.org/docs/389ds/development/source.html>for information about source tarballs andSCM(git) access. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list:https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproj… If you find a bug, or would like to see a new feature, file it in our GitHub project:https://github.com/389ds/389-ds-base * Bump version to 2.2.2 * Issue 5221 - fix covscan (#5359) * Issue 5294 - Report Portal 5 is not processing anXMLfile with (#5358) * Issue 5353 -CLI- dsconf backend export breaks with multiple backends * Issue 5346 - New connection table fails withASANfailures (#5350) * Issue 5345 -BUG- openldap migration fails when ppolicy is active (#5347) * Issue 5323 -BUG- improve skipping of monitor db (#5340) * Issue 5329 - Improve replication extended op logging * Issue 5343 - Various improvements to winsync * Issue 4932 -CLI- add parser aliases to long arg names * Issue 5332 -BUG- normalise filter as intended * Issue 5327 - Validate test metadata * Issue 4812 - Scalability with high number of connections (#5090) * Issue 4348 - Add tests for dsidm * Issue 5333 - 389-ds-base fails to build with Python 3.11 -- Directory Server Development Team

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users July 2022