Disable Anonymous Bind
by Christian Palacios
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
1 year, 2 months
Replcation failing since update to 389-ds-base-2.0.15-1.module_el8+14185+adb3f555.x86_64
by Brian Collins
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
1 year, 2 months
Retro Changelog trimming causes deadlock
by Kees Bakker
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
1 year, 2 months
I have some problem with 389 Directory Server container project
by Hu, Xudong
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 year, 2 months
Retro Changelog trimming not working
by Kees Bakker
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
1 year, 2 months
Announcing 389 Directory Server 2.0.16
by Mark Reynolds
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.fedorapr...
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 year, 2 months
