I am using a new installation on Cento 7 updated.
I am using these packages for 389DS
The netstat on both ports 389 and 636 show that the daemon is listening on
as a workaround i modified nsslapd-listenhost and nsslapd-securelistenhost
it's the first time I ma getting this behavior.
I have two servers running with multi master replication. The servers are
running RHEL 7.4 with 389-ds installed via yum using the rhel-7-server-rpms
repository. The hosts are behind a load balancer and all client access is through
the load balancer.
I would like to upgrade to the latest release available in rhel-7-server-rpms. I
have the following packages installed related to 389ds:
Only two of those packages appear to have updates available; 389-ds-base and 389-ds-base-libs.
Is this the correct procedure?
1. remove server1 from the load balancer config to halt client requests
2. stop the dirsrv and dirsrv-admin services on server1
3. run "yum upgrade 389-ds-base 389-ds-base-libs" on server1
4. run "setup-ds-admin.pl -u" on server1
5. restart dirsrv and dirsrv-admin on server1
6. verify replication is still working
7. add server1 back to load balancer config
8. repeat steps 1-7 on server2
I presume that replication will continue to work after upgrading server1 but before
upgrading server2. I believe that at step 4, I don't *also* have to run "setup-ds.pl".
Is that correct?
University of Louisiana at Lafayette
After upgrading from 389 version 184.108.40.206-33.el6_5.x86_64 to
220.127.116.11-97.el6_10.x86_64, we're finding that the Directory Manager
account can bypass configured password policies and set user passwords to
anything. I believe this is now by design, but is there a configuration
file flag to revert to the previous behavior where Directory Manager needed
to conform to the password policy?
If not, how do we create a user account in 389 ldap server with rights to
check and update user password hashes, and still enforce configured