We have a two machine 389DS multimaster cluster holding about 850.000 users. It's been working great for over three years now.
But we are creating some big groups, that will have about 150.000 users in them.
I've read in the list some posts about groups larger than that.
But I would like to know if there is any limit or precaution when working with groups this size?
We use the 389 Directory Server version 22.214.171.124.
In the documentation of the Red Hat Directory Server it says, as many as 20 masters are supported in an MMR. It sounds to be a hardcoded limitation defined to avoid overloaded servers and network. Shouldn't it be depending on the MMR topology, i.e. rather on the total number of replication agreements within the whole scenario? Or does "20 masters" indeed mean that the limitation of the MMR topology is the number of 380 replication agreements as shown in the "fully connected mesh" scenario (https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...) with 20 masters and 20x19 replication agreements?
Is there someone who possibly has experience with scenarios of more than 20 master servers?
Forwarding to the correct list...
First it is NOT 389 Actrive Directory Server. Active Directory is
Microsoft's LDAP server...
Going back to your question, there is no 389-admin package on CentOS 8
anymore. There is a new Web UI that is a Cockpit plugin
(cockpit-389-ds). For more info see the admin guide:
-------- Forwarded Message --------
Subject: 389-AD on CentOS 8
Date: Wed, 21 Oct 2020 10:03:09 +0100
From: Frank Allotey <noblyfrank(a)gmail.com>
I wanted to get hands-on experience with the 389 active directory but
then after doing the installation on a server I seem not to find my way
around for an admin console.
After further research on how to get the admin console failed I decided
to revert to CentOS 7 but some of the repositories are not available for
Kindly assist with the necessary support to achieve this.
Allotey Frank Kpakpo
/The content of this email is confidential and intended for the
recipient specified in message only. It is strictly forbidden to share
any part of this message with any third party, without a written consent
of the sender. If you received this message by mistake, please reply to
this message and follow with its deletion, so that we can ensure such a
mistake does not occur in the future./
Thank you ! yes there were groups associate to that users,removing them solved the issues
From: 389-users-request(a)lists.fedoraproject.org [mailto:email@example.com]
Sent: Wednesday, October 14, 2020 9:02 PM
Subject: 389-users Digest, Vol 185, Issue 12
Send 389-users mailing list submissions to
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of 389-users digest..."
1. Re: ldapdelete error (Mark Reynolds)
Date: Wed, 14 Oct 2020 08:03:00 -0400
From: Mark Reynolds <mreynolds(a)redhat.com>
Subject: [389-users] Re: ldapdelete error
To: "General discussion list for the 389 Directory server project."
<389-users(a)lists.fedoraproject.org>, William Brown <wbrown(a)suse.de>
Content-Type: text/plain; charset=utf-8; format=flowed
ldapdelete has a "-r" option to recursiviely delete. So that would
solve your problem, but you better make sure you know what is under that
user entry before blindly removing it and its child entries :-)
On 10/13/20 10:23 PM, William Brown wrote:
> Generally this means there is content still under the ou=Users. You can't do a subtree delete in LDAP, so that's probably the error here. Can you check what's under the OU?
>> On 14 Oct 2020, at 10:32, Ghiurea, Isabella <Isabella.Ghiurea(a)nrc-cnrc.gc.ca> wrote:
>> Hi List
>> I’m looking for a solution for the following ldapdelete error in a multimaster replication cfg with memberof pluging enabled locally on each server and excluded from replication agreement :
>> ldapdelete -D "cn=directory manager" -W -x "ou=Users,ou=ds,dcxxxxx " "(uid=9995)"
>> Enter LDAP Password:
>> ldap_delete: Operation not allowed on non-leaf (66)
>> My DS version is : 389-ds-base-126.96.36.199-24.el7_5.x86_64
>> Running a basic search for this error seems this was a known bug in older version 7 years ago which I assume is been fixed.
>> Thank you
>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: https://firstname.lastname@example.org...
> William Brown
> Senior Software Engineer, 389 Directory Server
> SUSE Labs, Australia
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://email@example.com...
389 Directory Server Development Team
Subject: Digest Footer
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://firstname.lastname@example.org...
End of 389-users Digest, Vol 185, Issue 12
I'm looking for a solution for the following ldapdelete error in a multimaster replication cfg with memberof pluging enabled locally on each server and excluded from replication agreement :
ldapdelete -D "cn=directory manager" -W -x "ou=Users,ou=ds,dcxxxxx " "(uid=9995)"
Enter LDAP Password:
ldap_delete: Operation not allowed on non-leaf (66)
My DS version is : 389-ds-base-188.8.131.52-24.el7_5.x86_64
Running a basic search for this error seems this was a known bug in older version 7 years ago which I assume is been fixed.
I'm looking at applying local password policy to our existing users.
Reading the Red Hat Directory Server Deployment Guide, I see the
If I'm reading this correctly, it would appear that users will no
longer be able to bind to the directory server after application of the
policy if their existing password doesn't meet the policy we apply. Is
this true? If so, is there a way to prevent this, and only apply the
policy on password modify operations?
 "When a user attempts to bind to the directory, Directory Server
determines whether a local policy has been defined and enabled for the
To determine whether the fine-grained password policy is enabled,
the server checks the value (on or off) assigned to the nsslapd-
pwpolicy-local attribute of the cn=config entry. If the value is off,
the server ignores the policies defined at the subtree and user levels
and enforces the global password policy.
To determine whether a local policy is defined for a subtree or
user, the server checks for the pwdPolicysubentry attribute in the
corresponding user entry. If the attribute is present, the server
enforces the local password policy configured for the user. If the
attribute is absent, the server logs an error message and enforces the
global password policy.
The server then compares the user-supplied password with the value
specified in the user's directory entry to make sure they match. The
server also uses the rules defined by the password policy to ensure
that the password is valid before allowing the user to bind to the
suddenly one of our ldap-servers crashed and don't restart.
When restarting dirsrv we find in logs:
libdb: BDB2034 unable to allocate memory for mutex; resize mutex region
mmap in opening database environment failed trying to allocate 500000
bytes. (OS err 12 - Cannot allocate memory)
Same error, if we run dbverify.
We are running version 3.5.17 of 389-ds on debian stretch:
Ram doesn't seem to be the problem. Only 200 MB of 4GB is used.
The server is part of a replicated cluster. Other servers (running same
software version - more or less on the same virtualisation hardware) are
But we got similar errors also some times in the past. But restarting
the service was always possible.
Thanks and kind regards
Glad to have helped. If you have more specific questions or details, we are happy to help at any time. Thanks!
> On 8 Oct 2020, at 17:29, Vincent Lemière <vincent(a)lemiere.org> wrote:
> Thanks for your reply,
> I agree with you.
> Duration and quality of links are more qualified.
> The TTL value is more qualified to grant transaction.
> I needed to know if some other solution could be envisaged.
> Your answer confirms my view.
> Thanks a lot
> -----Message d'origine-----
> De : William Brown <wbrown(a)suse.de>
> Envoyé : mercredi 7 octobre 2020 00:29
> À : vincent(a)lemiere.org; 389-users(a)lists.fedoraproject.org
> Objet : Re: [389-users] Table of duration and acceptable distance between two synchronized directories.
> Hi there,
> (removing 389-devel list from reply, this is probably better on the 389-users list :) )
> We don't have tables per-say. We don't have these because there are many factors involved that you need to consider when designing this kind of topology.
> For example, what rate of changes do you expect to be incoming? How much latency and bandwidth exists between the replicas? How many replicas do you want to deploy? How much latency are you willing to tolerate between the nodes becoming consistent?
> We are aware of a number of deployments that have high rates of change (thousands of writes per second) that are replicating between continents (ie US/EU). However they also have high bandwidth/low latency links between these locations to assist this.
> So I think there are more questions to answer here about your potential deployment and your specific concerns you have.
>> On 7 Oct 2020, at 07:24, 389ds(a)lemiere.org wrote:
>> do you have tables estimating the reasonable distance to synchronize two 389 directories between two sites. Are there tables of recommendations depending on the distance?
>> What software tools or scripts allow evaluating it.
>> Vincent Lemiere
>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To
>> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>> Fedora Code of Conduct:
>> List Guidelines:
>> List Archives:
> William Brown
> Senior Software Engineer, 389 Directory Server SUSE Labs, Australia
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
do you have tables estimating the reasonable distance to synchronize two 389
directories between two sites. Are there tables of recommendations depending
on the distance?
What software tools or scripts allow evaluating it.
Being an absolute NOOB, mailing the first time to this group, I hope you're
patient with my lack of knowledge ...
I have an issue with following documentation (is this the right place for
My company works with RHDS11 (RHEL8) so I tried to recreate some stuff
useradd -c "RedHat Directory Server" -u 389 -g 389 -s /sbin/nologin slapd
groupadd -g 389 ds
Needs to be done before the installation of "389-base", or user and group
will be created automatically (dirsrv.dirsrv).
Adapting basic configuration as described (instance.inf):
group = ds
user = slapd
ERR - dse_read_one_file - The configuration file
could not be accessed,
after a copy:
cp /usr/share/dirsrv/schema/60trust.ldif /etc/dirsrv/schema/
instance creation works like a charm ...
Sorry again for being annoying, but ...
where am I doing wrong?
also having some SELinux related questions,
is this the right place for such kind of issues?