I have a memory issue with 389-ds 1.2.5 in a CentOS 5.5 64bits 4GB ram.
The server swaps when the server physical memory increase over 75% approx.
When the swap is full the server reaches 100% of physical memory and the SO
kills the ns-ldapd process.
Out of memory: Killed process 30383, UID 99, (ns-slapd).
The cache sizes are:
nsslapd-cachememsize: 125829120 (for each 26 db)
Which can be the problem?
We are planning a Windows synchronization setup, but are being kind of
blocked by the inability to sync attributes other than the hard-coded
list (we need specifically displayName and optionally some of the the
eduPerson schema). Can this be achieved by creating a plugin? Should we
expect problems if we just locate the list in the source, add
displayName and rebuild?
Deyan Stoykov, dstoykov(a)uni-ruse.bg
Computing and Information Services Center
University of Ruse
On 12/17/2012 10:42 PM, George Stoynev wrote:
> Hi all,
> I tried to search through the list but did not find what I was looking
> I am testing 389-ds installation and password policies implementation.
> I installed it both on Ubuntu 12.04 Server and on CentOS 6.3. Still in
> the beginning as I am stuck finding why the Ubuntu client does not
> honor server's password policies.
> The install is pretty basic, I ran setup-ds-admin.pl
> <http://setup-ds-admin.pl>, followed by the default options and got a
> LDAP server running. Then from the console (not too comfortable with
> the commands in this case), enabled Fine-Grained password policy for
> the whole tree and ticked "User must change password after reset". All
> good for now. And here is the trick:
> On CentOS, I just ran authconfig-tui and enabled LDAP Client
> Authentication. Then "su - test_ldap" was successful and I got a
> message, stating "You are required to change your LDAP password
> immediately.". Happy!
> But, I cannot make Ubuntu client to do the same. The best I can do
> with it is to login to the server. It does not honor the password
> policies - no notifications for the users, login successful after
> password expired, etc.
> The Ubuntu client is 12.04 and I strictly followed their community
> wiki to set up PAM and be able to login. Btw, "getent passwd" and "id"
> works just fine, I can bind to the server, but no password policies.
> How I can fix this?
Replying to the right list.
> Any advice will be greatly appreciated!
> Thank you,
> George S.
The 389 team is pleased to announce the availability of Release
Candidate 2 of version 1.3.0 for Testing. This release supports slapi
transactions, improves performance, as well as fixes numerous bugs.
* Tracking tickets for 1.3.0 release -
The new packages and versions are:
NOTE: 1.3.0 will not be available for Fedora 17 or earlier, nor for EL6
or earlier - 1.3.0 will only be available for Fedora 18 and later. We
are trying to stabilize current, stable releases - upgrades to 1.3.0
will disrupt stability.
yum install 389-ds --enablerepo=updates-testing
yum upgrade 389-ds-base --enablerepo=updates-testing
How to Give Feedback
The best way to provide feedback is via the Fedora Update system.
Go to https://admin.fedoraproject.org/updates
In the Search box in the upper right hand corner, type in the name of
In the list, find the version and release you are using (if you're not
sure, use rpm -qi <package name> on your system) and click on the release
On the page for the update, scroll down to "Add a comment" and provide
Or just send us an email to 389-users(a)lists.fedoraproject.org
If you find a bug, or would like to see a new feature, use the 389 Trac
* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download
Hi all - thanks for reading!
We're planning a deployment of RHDS in our environment right now. We want to setup multi-mastering, however I'm confused by the "20 masters per replication scenario" limit that's in the Redhat documentation. There doesn't seem to be any explanation around this limit that I can find.
- Each database (with one or more suffix assigned to it) seems to be what is considered as a "server" when it comes to replication scenarios - is that the case?
- Does this mean you are limited to 20 databases marked as Masters, in an instance of directory server?
- Or is it the limit 20 masters of a single database, spread across different instances of DS/machines?
- How is this limit enforced, if it is? This part confuses me, the "limit" seems thrown into the documentation with no context.
We can design the architecture to avoid ever worrying about the 20 database limit, but we're concerned about storing a ton of directory information that is currently located in separate (different vendor) directory servers, all in a single RH/389 DS "database". We might have some naming conflicts as well as policy constraints there as well - so we're just trying to get a handle on the implications of scaling the architecture up.
And how might all this apply different to 389, if at all ?
We had an incident today using the 389-console GUI where our groups were
inadvertently deleted. We are in the process of recreating them (not too
bad, just tedious). I am looking at finding a way to back up our data
periodically so should this happen again, we can restore from backup. I
see online a script called db2ldif.pl. However, I can't find that
anywhere on our installation.
1) We are using 389-ds version 1.2.1 on CentOS 5.7 x64. Where can I get
2) If this is not the best way to do this, what IS the proper way to
backup our data? We are replicating to another server, but once that
groups were gone, that replicated to the other server and now BOTH were
Thanks for any tips!
Common ARTS Software Development
It there some way to find out when a 389 <-> AD password sync operation fails?
We're seeing issues where passwords are accepted by the side making the
change, but then the other side rejects it. But we don't see any messages in
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
I'm testing group sync between 389ds and Microsoft AD. It works
otherwise, but incremental updates are not working. Any changes to
groups on 389 side do not get synced to AD unless I do a full manual
update triggered via console. Syncing users works normally. Would
someone have an idea why?
I have setup two directory servers on multi-master replication and would
like to setup them as fail over servers on the client side.
I am using sssd on client side, and I did specify both ldap servers on
/etc/openldap/ldap.conf and /etc/sssd/sssd.conf like below
[root@dsl cacerts]# cat /etc/openldap/ldap.conf
[root@dsl cacerts]# cat /etc/sssd/sssd.conf
ldap_uri = ldaps://ldap02.mam.net, ldaps://ldap.mam.net
I am using Centos 6.3 on both side and yum installed the directory server
from default Centos repo.
According to RH document, if you want to create the replication user, you
must edit the dse.ldif file and put the user information there.
I tried to use 389-console, create user (which use uid=repman) then try to
enable cn=repman, but there is error saying that directory server refuse to
do the renaming.
What is the correct way to create cn=repman only by using 389 console?
Sharuzzaman Ahmat Raslan