How to modify the attribute nsslapd-encryptionalgorithm in Centos?
Stop Master servers and set nsslapd-encryptionalgorithm. The allowed value is AES or 3DES.
--- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com> escreveu:
De: Rich Megginson <rmeggins(a)redhat.com>
Assunto: Re: [389-users] changelog
Para: "Denise Cosso" <guanaes51(a)yahoo.com.br>
Data: Terça-feira, 4 de Junho de 2013, 16:34
On 06/04/2013 01:26 PM, Denise Cosso
CentOS release 6.3 (Final)
As far as replication goes - you will need to use a security layer
(SSL, TLS, or GSSAPI) to protect the clear text password on the wire
As far as encrypting it in the changelog - not sure
--- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com>
De: Rich Megginson <rmeggins(a)redhat.com>
Assunto: Re: [389-users] changelog
Para: "General discussion list for the 389 Directory
Cc: "Denise Cosso" <guanaes51(a)yahoo.com.br>
Data: Terça-feira, 4 de Junho de 2013, 16:11
06/04/2013 12:39 PM, Denise Cosso wrote:
Description of problem:
When a userPassword is changed in a server with changelog, the hashed password
is logged and also a cleartext pseudo-attribute version. It looks like this:
This unhashed version is used in winsync where the cleartext version of the
password must be written to the AD.
Now if the DS is involved in replication with another DS, the change will be
replayed exactly as it is logged to the other DS replicas, including the
cleartext pseudo-attribute password.
What platform? What version of 389-ds-base are you
389 users mailing list
I got 389 running on a remote linux box,and I would like to get use of
the Console without the need of exporting the X-Windows whenever I want
to make a change as I also would prefer not to keep tweaking the
configuration files all the time.
is there anyway of doing this through any remote client?
Any advise on this matter?
Thanks very much
We need to implement password expiration because of some policy. The
problem is users are not able to bind to ldap anymore, after I switch on
password expiration for our ou=People subtree . The ldap command line
tools and 389-console both just hang forever when trying to connect.
This happens even when the user changes the password right before
switching on the password expiration so the password cannot be expired
yet. When I use the wrong password, then I get "ldap_bind: Invalid
credentials (49)", but when I use the correct password, then it's just a
hang. If I switch off password expiration then everything returns to
normal again. I've followed the guide at
I've tried both 389ds 22.214.171.124 on CentOS 6 and 389ds 126.96.36.199 on Fedora
20 with the same results.
Is password expiration working in 389ds at all?
Thanks in advance,
I’m afraid this will be a total newb question.
I’m currently running 389 DS 188.8.131.52-1.el6 and have seen the notice that 1.2.11.X will be discontinued soon (as of 24-Oct-2014). [It probably has already been discontinued since the COPR repository is no longer there.]
I’d like to switch from 1.2.11 to 184.108.40.206 and have yum downgraded to 220.127.116.11-48.el6_6.
However, when I try to "yum upgrade 389-ds-base 389-ds-base-devel 389-ds-base-libs” it tells me "No Packages marked for Update”. Am I doing something wrong?
I’ve followed the directions on http://www.port389.org/docs/389ds/download.html and epel-release-6-8.noarch.rpm is already installed. [That doc is still telling me to install the temporary COPR, by-the-way.]
Thanks in advance,
I have an use case where particular search operations on the same data in
1.2.5 and 1.2.11 differ significantly.
1.2.5 is on Centos 5.9 and 1.2.11 on Centos 5.11. I'm asking this as i'm in
the middle of upgrade process and I come across this performance issue.
After feeding both versions with data from the same text dump, particular
search operation takes 0.5s in 1.2.5 to complete whereas in 1.2.11 it takes
ldapsearch -D 'uid=root,ou=users,o=xxx' -x -b
'uid=someuser,dc=domain,dc=pl,o=xxx' -s subtree -w pass
There is a set of 40 acls at the dc=pl,o=xxx node and 9 more on
dc=domain,dc=pl,o=xxx. The acl allowing 'uid=root,ou=users,o=xxx' to access
everything is at o=xxx.
I did already manage to figure out that the more acis i remove the shorter
the search operation is. However even with those aci in place, search on
1.2.5 returns significantly faster.
I would like to ask if there are any factors that would make search
operations longer while jumping from 1.2.5 to 1.2.11?
I need to know how to cfg 389-admin console to be able to display the
total number of entries in DS ( the count number) , seems that Appache
Studio has a limitation to 2000 entries/counts ( is this correct ?), I
increase the browsing options to 100000 for DS Users but will show as (
2000) beside Users
We've been really pleased with our 389 servers, which have been successfully running as a multi-master pair in production for 7 weeks, following (elapsed) months of development.
Unfortunately, in the last few days their performance has radically degraded to the point where they are becoming unusable due to excessive memory consumption. At first, we suspected a recent update to the package - but are no longer convinced that's the problem.
I'd really appreciate any suggestions on how to troubleshoot this further.
389 ignores its 4GB userRoot nsslapd-cachememsize and its overall memory usage expands to encompass all of the server's 8GB RAM - and a large proportion of its 10GB swap. The service eventually fails, and hangs the server.
As per the previous guidance for RHEL 6 installations, we had been using the packages from the COPRS repository (389-ds-base-18.104.22.168-1 aka 22.214.171.124 B2014.247.2316).
(As several of our applications require CoS/dynamic attributes, earlier versions of the RHEL packages were unusable for us until this fix was ported: https://fedorahosted.org/389/ticket/47762#comment:8 - which was only recently applied to the RHEL packages).
Due to an unfortunate misconfiguration, the production servers received automated updates - and were upgraded to RHEL 6.6, the latest COPRS package (126.96.36.199-1), and a new kernel :-/
The directory contains 236,340 entries, and id2entry.db4 is 3.6GB.
We've tried to balance isolating the problem with maintaining a critical service for our users:
* An additional 8GB RAM (and additional CPU) was added to the VM to mitigate the immediate problem - but this was soon swallowed up too.
* Attempting to reproduce this on our equivalent development servers has not been successful, even when subjecting them to load.
* Downgrading to the RHEL packages (188.8.131.52-48 aka 184.108.40.206 B2014.300.2010) as per Noriko's very helpful procedure below (though I stopped the services prior to the downgrade). No obvious difference.
* Rebooting into the previous kernel (2.6.32-431.29.2). This slowed the problem, but only to an extent.
Not attempted yet:
* Turning on debugging on the production servers, as they're in a fragile and sluggish state.
* Building the latest 1.3.x build on RHEL 6. Will be attempting this soon...
* Installing RHEL 7.0 on a fresh VM, as we don't have experience with 7 yet.
* Downgrading to the previous COPRS package, as no longer publicly available(?)
Please let me know if more information would help...
From: 389-users-bounces(a)lists.fedoraproject.org<mailto:email@example.com> [mailto:firstname.lastname@example.org] On Behalf Of Noriko Hosoi
Sent: 25 October 2014 00:05
To: 389-announce(a)lists.fedoraproject.org<mailto:email@example.com>; General discussion list for the 389 Directory server project.
Subject: [389-users] Please take an action: 389 Directory Server 1.2.11.X Discontinued for EL6
389 Directory Server 1.2.11.X Discontinued for EL6
The 389 Directory Server team announces the binary release of 389-ds-base version 1.2.11 for EL6 will be stopped via temporary COPR repository. We encourage you to switch it to the official version included in the Red Hat Enterprise Linux 6 distribution or its equivalent OS.
How to switch to the official version
Remove a yum repo file which points to the temporary COPR repository (e.g., nhosoi-389-ds-base-epel6-epel-6.repo) from /etc/yum.repos.d.
If the current 389 Directory Server 1.2.11 has the greater build number than 15, for instance, 220.127.116.11, downgrade it once by "yum downgrade" as follows.
yum downgrade 389-ds-base 389-ds-base-libs
Then, upgrade to make sure you have the latest version.
yum upgrade 389-ds-base
After upgrade completes, run setup-ds-admin.pl -u to update your directory server/admin server/console information.
See Install_Guide<http://www.port389.org/docs/389ds/legacy/install-guide.html> for more information about the initial installation, setup, and upgrade
See Source<http://www.port389.org/docs/389ds/development/source.html> for information about source tarballs and SCM (git) access.
This email has been scanned by MessageLabs' Email Security
System on behalf of the University of Brighton.
For more information see http://www.brighton.ac.uk/is/spam/
we've migrated our production systems to 389ds version 18.104.22.168. Everything seems fine now, the only new messages i see in error logs (several times per day) are
[15/Nov/2014:03:58:43 +0100] - replica_generate_next_csn: opcsn=5466c164000000010000 <= basecsn=5466c164000000020000, adjusted opcsn=5466c164000100010000
[15/Nov/2014:10:38:38 +0100] - replica_generate_next_csn: opcsn=54671f1f000000010000 <= basecsn=54671f1f000000030000, adjusted opcsn=54671f1f000100010000
Are these only information messages that can be safely ignored or they may be a manifestation of some potential problem?
In source code (./ldap/servers/plugins/replication/repl5_replica.c) it looks like a serious one (SLAPI_LOG_FATAL):
slapi_log_error (SLAPI_LOG_FATAL, NULL,
"opcsn=%s <= basecsn=%s, adjusted opcsn=%s\n",
opcsnstr, basecsnstr, opcsn2str);
We are trying to move our database from the much older 1.1.2 version to
1.2.11 on a Centos 6 platform. When trying to initialize the 1.2.11
database with a ldif file exported from the older database I am getting
tons of syntax violations. The schema (99user.ldif + dse.ldif extensions)
is the same. Does the newer version have stricter rules?
import userRoot: WARNING: skipping entry
"cn=23609-17622,ou=other,ou=23609,ou=enterprises,o=x.com" which violates
attribute syntax, ending line 7196556 of file "/tmp/qa-db-mod.ldif”