We have the following setup.
Active Directory Server in US.
389 DS Server in Italy.
We are able to access the Active Directory Server from 389 DS.
We installed the sync agreement. No body is touching the AD, the number of
objects that should copied is 21. But every time we are running the
replication agreement, the number of objects being copied is always
different. How can that be if there is no change happening at the AD
Is the replication done over UDP or TCP.
Also is it because of distance and delay that is causing the
If some can elaborate in this issue, it would be really helpful.
Specifically, I'm referring to the two incompatible schemas for rfc2307
vs rfc2307bis. In the past, it was possible to just delete 10rfc2307.ldif
from /etc/dirsrv/<instance>/schema and replace it with the file supplied
Now, with the new directory layout in 220.127.116.11, there is nothing to delete
in /etc/dirsrv/<instance>/schema. And since the two schemas are
incompatible, I can't load the other one by dropping it in there.
It seems the only thing I'm able to do is remove
/usr/share/dirsrv/schema/10rfc2307.ldif to get the other file to load.
That's global for all instances on the server, though. Is there any way to
make this change for just one instance?
Office of Information Technology
389 Directory Server 18.104.22.168
The 389 Directory Server team is proud to announce 389-ds-base version
Fedora packages are available on Fedora 30 and rawhide.
<https://koji.fedoraproject.org/koji/taskinfo?taskID=35621238> - Rawhide
<https://koji.fedoraproject.org/koji/taskinfo?taskID=35620824> - Fedora 30
The new packages and versions are:
Source tarballs are available for download at Download
Highlights in 22.214.171.124
* Bug fixes
Installation and Upgrade
See Download <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 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 <https://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
New UI Progress (Cockpit plugin)
The new UI is broken up into a series of configuration tabs. Here is a
table showing the current progress
Configuration Tab Finished Written in ReactJS
Server Tab Yes No
Security Tab No No
Database Tab Yes Yes
Replication Tab Yes No
Schema Tab Yes No
Plugin Tab Yes Yes
Monitor Tab Yes Yes
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 126.96.36.199
* Issue 49361 - Use IPv6 friendly network functions
* Issue 48851 - Investigate and port TET matching rules
* Issue 50446 - NameError: name ‘ds_is_older’ is not defined
* Issue 49602 - Revise replication status messages
* Issue 50439 - Update docker integration to work out of source directory
* Issue 50037 - revert path changes as it breaks prefix/rpm builds
* Issue 50431 - Fix regression from coverity fix
* Issue 50370 - CleanAllRUV task crashing during server shutdown
* Issue 48851 - investigate and port TET matching rules
* Issue 50417 - Fix missing quote in some legacy tools
* Issue 50431 - Fix covscan warnings
* Revert “Issue 49960 - Core schema contains strings instead of
* Issue 50426 - nsSSL3Ciphers is limited to 1024 characters
* Issue 50052 - Fix rpm.mk according to audit-ci change
* Issue 50365 - PIDFile= references path below legacy directory /var/run/
* Issue 50428 - Log the actual base DN when the search fails with
“invalid attribute request”
* Issue 50329 - (2nd) Possible Security Issue: DOS due to
ioblocktimeout not applying to TLS
* Issue 50417 - Revise legacy tool scripts to work with new
* Issue 48851 - Add more search filters to vfilter_simple test suite
* Issue 49761 - Fix CI test suite issues
* Issue 49875 - Move SystemD service config to a drop-in file
* Issue 50413 - ds-replcheck - Always display the Result Summary
* Issue 50052 - Add package-lock.json and use “npm ci”
* Issue 48851 - investigate and port TET matching rules filter
* Issue 50355 - NSS can change the requested SSL min and max versions
* Issue 48851 - investigate and port TET matching rules
* Issue 50390 - Add Managed Entries Plug-in Config Entry schema
* Issue 49730 - Remove unused Mozilla ldapsdk variables
At the moment we perform TCP health check via F5 on ports 389/636 (historical inheritance) – which isn’t sufficient for HA.
We are moving to an env where NSX and F5 may co-exist – and have an opportunity to re-work the LB health check for HA (on existing F5 and upcoming NSX).
If running NSX and/or F5 (or other load balancers) – how do you determine health on ldap node?
We have 2 read/write (1 active at given time) – replicating to N read-only nodes.
I'm still evaluating some options to securize dynamic nodes and I have some questions regarding certutil and nss databases:
Can I create NSS databases on any directory/server and then move files to "/etc/dirsrv/slapd-instance_name" ?
If cert8.db and key3.db files are found in that directory are they used automatically by slapd process on reboot?
If both answers are affirmative I'll try to script it and hook it within my node creation flow.
is there any other detail I should take care of with this approach?
I'm trying to upgrade my environment and I've reinstalled my CentOS
machines to CentOS 7 except for one. I've got my DNS for my LAN working
just fine. So now it's time for Directory Server.
What is a GOOD tutorial to follow? My environment includes 26 physical
and KVM virtual machines; 4 Windows 7 machines and 1 ArcaOS (OS/2)
machine. What is a DS configuration to go for?
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