We have a setup with 2 multi-masters and 3 consumers. We are now building new host and want to put them in place ultimately at the same IP address as the original ones. I need some advice on how to do this quickly and cleanly.
To add a new consumer the idea now is to set it up and set up replications agreements from each master using consumer DNS name (don't start continuous replication yet). After initializing new consumer from one master - turn off old consumer, remove old consumer agreement from each master, and re-IP new consumer. Do we need to restart masters to re-read DNS or will it pick that up when it starts the next replication? Is this the best way to do this?
Deborah Crocker, PhD
Systems Engineer III
Office of Information Technology
The University of Alabama
Tuscaloosa, AL 36587
Office 205-348-3758 | Fax 205-348-9393
I'm trying to set tls-protocol-min to TLS 1.0 but it's not working, I used
dsconf and ldapmodify like this:
Also tried to set on variables like this:
dsconf RNP security set --tls-protocol-min="TLS1.0"
Set Allow Weak Ciphers to on, but seems to be related to ssl3 and not TLS.
Change cipher suite to all
All commands seems to works, also modify my dse.ldif but When I start my
[28/Apr/2020:23:10:58.855549735 -0300] - INFO - Security Initialization -
slapd_ssl_init2 - Configured SSL version range: min: TLS1.1, max: TLS1.2
[28/Apr/2020:23:10:58.858132149 -0300] - INFO - Security Initialization -
slapd_ssl_init2 - NSS adjusted SSL version range: min: TLS1.2, max: TLS1.2
This last try was setting to --tls-protocol-min="TLS1.1"
Greetings 389 users,
I am a sysadmin that has never really used LDAP before. I have installed 389-ds and am a little stuck as to how to start.
I am using Debian Buster...
From the site:
I see it recommends setting a .dsrc file to ease usage as the root user:
For local instance administration (on the server), you want to use settings like:
# cat ~/.dsrc
# Note that '/' is replaced to '%%2f'.
uri = ldapi://%%2fvar%%2frun%%2fslapd-localhost.socket
basedn = dc=example,dc=com
binddn = cn=Directory Manager
I don't have the socket file in my installation. I don't see any sockets owned by the directory service:
# systemctl status dirsrv(a)gopher.service
● dirsrv(a)gopher.service - 389 Directory Server gopher.
Loaded: loaded (/lib/systemd/system/dirsrv@.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-05-13 12:38:22 CDT; 2h 5min ago
Main PID: 12270 (ns-slapd)
Status: "slapd started: Ready to process requests"
Tasks: 25 (limit: 4722)
└─12270 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-gopher -i /var/run/dirsrv/slapd-gopher.pid
# tree /var/run/dirsrv
The Debian package states to initialize the server to run the command: /usr/sbin/setup-ds
I don't know if that is a distribution agnostic program or not. The command did prompt me for a password - which I entered.
When I run a command like dsidm or ldapmodify, the command prompts me for a password. I enter the one that was prompted for with setup-ds, but I get:
SASL/SCRAM-SHA-1 authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
I guess I have two questions.
1. Should there be a socket somewhere owned by slapd for local communication?
2. What password should I enter for ldap<command> and dsidm?
Thanks for any pointer, advice, or help!
As per below scenario trying to enable 2FA but no luck , please let me know if any one faced this kind of issue and how it was resolved
I'm trying to enable 2FA authentication only in 2 hosts out-of 5 hosts
test case 1 ) I have enabled 2FA in global configuration of FREEIPA but is working on all 5hosts
test case 2) Disabled 2FA in Global configuration of freeipa and enabled OTP indicator only 2 hosts but OTP mechanism doesn't working
389 (master) <=> 389 (master)
In a master to master replication, start to see this error :
[31/Mar/2020:17:30:52.610637150 +0000] - WARN - NSMMReplicationPlugin -
replica_check_for_data_reload - Disorderly shutdown for replica
dc=rnp,dc=local. Check if DB RUV needs to be updated
Even after restart the service the problem persists, I have to disable and
re-enable replication (and replication agr) on both sides, it works for
some time, and the problem comes back.
389 Directory Server 22.214.171.124
The 389 Directory Server team is proud to announce 389-ds-base version
Fedora packages are available on Rawhide (Fedora 33).
The new packages and versions are:
Source tarballs are available for download at Download
Highlights in 126.96.36.199
* Bug fixes
Installation and Upgrade
See Download <http://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 Cockpit UI plugin use *dnf install cockpit-389-ds*
After rpm install completes, run *dscreate interactive*
For upgrades, simply install the package. There are no further
There are no upgrade steps besides installing the new rpms
more information about the initial installation and setup
See Source <http://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
If you find a bug, or would like to see a new feature, file it in our
Pagure project: https://pagure.io/389-ds-base
* Bump version to 188.8.131.52
* Issue 51078 - Add nsslapd-enable-upgrade-hash to the schema
* Issue 51054 - Revise ACI target syntax checking
* Issue 51068 - deadlock when updating the schema
* Issue 51042 - try to use both c_rehash and openssl rehash
* Issue 51042 - switch from c_rehash to openssl rehash
* Issue 50992 - Bump jemalloc version and enable profiling
* Issue 51060 - unable to set sslVersionMin to TLS1.0
* Issue 51064 - Unable to install server where IPv6 is disabled
* Issue 51051 - CLI fix consistency issues with confirmations
* Issue 50655 - etime displayed has an order of magnitude 10 times
smaller than it should be
* Issue 49731 - undo db_home_dir under /dev/shm/dirsrv for now
* Issue 51054 - AddressSanitizer: heap-buffer-overflow in ldap_utf8prev
* Issue 49761 - Fix CI tests
* Issue 51047 - React deprecating ComponentWillMount
* Issue 50499 - fix npm audit issues
* Issue 50545 - Port dbgen.pl to dsctl
* Issue 51027 - Test passwordHistory is not rewritten on a fail attempt
389 Directory Server Development Team
I have two servers, an older CentOS7 server running 389-ds-base-184.108.40.206-5.el7, and a newer CentOS8 server running 389-ds-base-220.127.116.11-7.module_el8.1.0+234+96aec258, and I want to set up multi-master-replication between them.
The replication agreement for CentOS7-> CentOS8 works great, replication is working fine.
The replication agreement for CentOS8 -> CentOS7 doesn’t work, giving the following strange error:
[07/May/2020:18:42:59.201795217 +0200] - 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 “x.x.x:636”)
At the core of the above message is "network error 0”, otherwise known as “success”.
Does this ring a bell with anyone?