I have a very old installation of open-ds sitting around and recently we
got the "go" for upgrading it.
I installed ds389 on CentOS7 64bit, from EPEL.
The first obstacle I hit when simply trying to import users from and
export of the old server is that the ldif-export has the passwords in
formats like this:
or (very few)
I created a user in 389-ds and exported it and it did not contain any
What is the default algorithm that is used to encrypt passwords?
How can I switch it to sha512 - and how can I store encrypted passwords
with different algorithms?
We've got multi-master replication setup between two masters. The replication recently broke after being stable for a few years, and in troubleshooting it appears that the issue is that both masters have the same nsDS5ReplicaId defined (both are set to 2). Both masters have nearly the same output from running:
$ ldapsearch -x -b 'cn=replica,cn="dc=someorg,dc=com",cn=mapping tree,cn=config' -D "cn=Directory Manager" -W
# replica, dc\3Dsomeorg\2Cdc\3Dcom, mapping tree, config
dn: cn=replica,cn=dc\3Dsomeorg\2Cdc\3Dcom,cn=mapping tree,cn=config
nsDS5ReplicaBindDN: cn=replication manager,cn=config
The only difference in this output between the two servers is the nsds5ReplicaChangeCount.
I believe I can use ldapmodify to change the replica ID on one of the nodes, but am unsure whether or not this is the proper way to fix the issue - or if there is anything additional that needs to take into account when making this change.
We inherited this LDAP system a while ago, and are not very familiar with how replication works in general, so we're reluctant to try this in fear of causing more damage by doing the wrong thing.
If anyone has a suggestion or advice on this, your comments would be appreciated.
On 08/14/2018 11:32 AM, Paul Whitney wrote:
> Hi guys,
> Am looking to improve performance in my 389 DS deployment. In
> reviewing the documentation, the recommended size for the LDBM cache
> is the sum of the backend database + 15% of the backend database. For
> me that comes out to almost 27GB. Seems high considering the database
> cache is set very high as well. Is that a recommended setting or is
> there a better practice?
Well the more of the database you can keep in the cache the better the
performance. However, you are talking about the same cache: LDBM cache
is the same thing as the database cache.
But you should also include the entry cache for your database. So you
almost want to double that to 50GB total ;-) 27 GB for DB cache, and
20 GB for entry cache (this varies of course for the entry cache and it
will probably be less than 20GB, but you won't know until you start
priming the entry cache and checking the database monitor - trying to
achieve 99% cache hit ratio).
> Paul M. Whitney
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://email@example.com...
I am attempting to create an index which will allow searches on the memberUID
attribute to be case insensitive. Using the 389-console, I created an Additional Index
for memberuid and added "caseIgnoreIA5Match" as a Matching Rule. This did not
produce the desired result.
Initially I would simply like to know if what I am asking for is possible. From reading
the docs it seems it should be. I am able to force a caseIgnoreIA5Match by using an
extensible match search filter.
Once I know it is possible and that I am following the correct procedure then I can
provide as much detail as necessary to assist in debugging.
University of Louisiana at Lafayette
Am looking to improve performance in my 389 DS deployment. In reviewing the documentation, the recommended size for the LDBM cache is the sum of the backend database + 15% of the backend database. For me that comes out to almost 27GB. Seems high considering the database cache is set very high as well. Is that a recommended setting or is there a better practice?
Paul M. Whitney
In running the old iPlanet (and then, Sun) DS (389's ancestor) for
around a decade I gradually moved towards doing almost everything on the
command line both for efficiency and stability (early versions of the
gui console sometimes crashed the server). Sun's last release, DSEE 7,
came with the kind of command line utilities now being developed for
389, allowing you to do everything at the CLI you used to need the gui
for (like setting up replication). About the only thing I missed was the
console's graphical aci editor, which is still the best way for new
admins to learn the aci system. In fact I used the console aci editor
just this week to prototype access controls for an OpenDJ directory
service (OpenDJ is an all-java server that grew out of Sun DS).
We run ldap 389, here in a computer science department
We need to have an easy management tool for setup and manage ldap
accounts. Required functionalities among others are:
*query users based on criteria i.e, select all users that belong to the
same group, and easily update their gid , and at the same time to
update the corresponding group with the new additions
*batch import of multiple users at once
*select multiple users for deactivate/activate/delete?
Has anybody uses such a tool, with above functionalities and even more?
*Computer Science Department| University of Cyprus*
*(**dir no: ****++357 22892727****/central no :****++357
22892700**/****fax no **:++357 22892731