389-users August 2018

389-users@lists.fedoraproject.org

22 participants
34 discussions

Using dbmon.sh
by Paul Whitney 16 Aug '18

16 Aug '18

Hi, I am using the dbmon.sh program to see how my database cache is performing. I am puzzled with the results: dbcachefree: -1639628800 free% -10006900 hit% 90 Do the negative values reflect me needing to increase the LDBM cache? Paul M. Whitney

1 0

Importing users from open-ds
by rainer＠ultra-secure.de 16 Aug '18

16 Aug '18

Hi, 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: {SSHA}actual_encrypted_password_here or {SSHA512}actual_encrypted_password_here or (very few) {ssha}actual_encrypted_password_here I created a user in 389-ds and exported it and it did not contain any such hint. 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? Best Regards Rainer

2 5

Multi-master replication broken - duplicate replica IDs?
by Devon Peters 15 Aug '18

15 Aug '18

Hi folks, 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 objectClass: nsDS5Replica objectClass: top nsDS5ReplicaRoot: dc=someorg,dc=com nsDS5ReplicaType: 3 nsDS5Flags: 1 nsDS5ReplicaId: 2 nsds5ReplicaPurgeDelay: 604800 nsDS5ReplicaBindDN: cn=replication manager,cn=config cn: replica nsState:: AgAAAAAAAADES3NbAAAAAAAAAAAAAAAAAgAAAAAAAAABAAAAAAAAAA== nsDS5ReplicaName: 52c33a02-368211e1-a5228b52-eb63f05c nsds5ReplicaChangeCount: 17190 nsds5replicareapactive: 0 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. Thanks, -devon

2 1

Re: LDBM recommended Setting
by Mark Reynolds 15 Aug '18

15 Aug '18

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). Mark > > Thanks, > > 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://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject…

3 2

Replication error multimaster_mmr_postop - error 0 for oparation 561
by Harvey, Robert 14 Aug '18

14 Aug '18

I have this ds-389 version installed on centos 7 389-ds-base-libs-1.3.7.5-21.el7_5.x86_64 This system is now a stand alone server, it use to part of a multi-master setup. I've ran cleanruv on it. There are no current replication agreements. The server name is caroldaps14. I'm getting the following in the error log, does anyone know what this means? [14/Aug/2018:09:14:16.471982187 -0700] - DEBUG - NSMMReplicationPlugin - changelog program - cl5GetOperationCount - Found DB object 0x55ff8bbed900 [14/Aug/2018:09:14:42.889265858 -0700] - DEBUG - replication - multimaster_mmr_postop - error 0 for oparation 561. [14/Aug/2018:09:15:12.891109581 -0700] - DEBUG - replication - multimaster_mmr_postop - error 0 for oparation 561. [14/Aug/2018:09:15:42.893029772 -0700] - DEBUG - replication - multimaster_mmr_postop - error 0 for oparation 561. [14/Aug/2018:09:16:12.894773802 -0700] - DEBUG - replication - multimaster_mmr_postop - error 0 for oparation 561. [14/Aug/2018:09:16:42.896604786 -0700] - DEBUG - replication - multimaster_mmr_postop - error 0 for oparation 561. [14/Aug/2018:09:17:12.898430104 -0700] - DEBUG - replication - multimaster_mmr_postop - error 0 for oparation 561. [14/Aug/2018:09:17:42.900260784 -0700] - DEBUG - replication - multimaster_mmr_postop - error 0 for oparation 561. [14/Aug/2018:09:18:12.902171728 -0700] - DEBUG - replication - multimaster_mmr_postop - error 0 for oparation 561. [root@caroldaps14 aharvero]# ldapsearch -x -D 'cn=directory manager' -h localhost -p 2389 -W -b'dc=vzwnet,dc=com' '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=vzwnet,dc=com> with scope subtree # filter: (&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone)) # requesting: ALL # # replica, dc\3Dvzwnet\2Cdc\3Dcom, mapping tree, config dn: cn=replica,cn=dc\3Dvzwnet\2Cdc\3Dcom,cn=mapping tree,cn=config objectClass: top objectClass: nsds5replica objectClass: extensibleObject cn: replica nsDS5ReplicaRoot: dc=vzwnet,dc=com nsDS5ReplicaId: 10 nsDS5ReplicaType: 3 nsDS5Flags: 1 nsds5ReplicaPurgeDelay: 604800 nsDS5ReplicaBindDN: cn=replication manager,cn=config nsState:: CgAAAAAAAADsFWJbAAAAAAAAAAAAAAAAKgUAAAAAAAABAAAAAAAAAA== nsDS5ReplicaName: 11d04882-007011e8-827a9b7a-f3a493c7 nsds50ruv: {replicageneration} 5a67870b0000000a0000 nsds50ruv: {replica 10 ldap://caroldaps14.nss.vzwnet.com:2389} 5a67a7640000000 a0000 5b621b160000000a0000 nsruvReplicaLastModified: {replica 10 ldap://caroldaps14.nss.vzwnet.com:2389} 00000000 nsds5ReplicaChangeCount: 30 nsds5replicareapactive: 0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1

1 0

Attempting to make memberUID searches case insensitive
by Patrick Landry 14 Aug '18

14 Aug '18

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. TIA -- Patrick Landry Director, UCSS University of Louisiana at Lafayette patrick.landry(a)louisiana.edu

3 11

LDBM recommended Setting
by Paul Whitney 14 Aug '18

14 Aug '18

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? Thanks, Paul M. Whitney

1 0

simple question: do I need an admin server at all ?
by Phil Lembo 11 Aug '18

11 Aug '18

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).

2 1

Announcing 389 Directory Server 1.3.8.7
by Mark Reynolds 10 Aug '18

10 Aug '18

389 Directory Server 1.3.8.7 The 389 Directory Server team is proud to announce 389-ds-base version 1.3.8.7 Fedora packages are available on Fedora 27. https://koji.fedoraproject.org/koji/taskinfo?taskID=28971371 <https://koji.fedoraproject.org/koji/taskinfo?taskID=28971371> https://bodhi.fedoraproject.org/updates/FEDORA-2018-a45016e03f <https://bodhi.fedoraproject.org/updates/FEDORA-2018-a45016e03f> The new packages and versions are: * 389-ds-base-1.3.8.7-1 Source tarballs are available for download at Download 389-ds-base Source <https://releases.pagure.org/389-ds-base/389-ds-base-1.3.8.7.tar.bz2> Highlights in 1.3.8.7 * Bug fix and security fix Installation and Upgrade See Download <http://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install, use *yum install 389-ds* yum install 389-ds After install completes, run *setup-ds-admin.pl* if you have 389-admin installed, otherwise please run *setup-ds.pl* to set up your directory server. To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run *setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please run *setup-ds.pl* 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. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list: https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.o… 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 1.3.8.7 * Ticket 49890 - SECURITY FIX - ldapsearch with server side sort crashes the ldap server * Ticket 49893 - disable nunc-stans by default

1 0

Announcing 389 Directory Server 1.4.0.14
by Mark Reynolds 10 Aug '18

10 Aug '18

389 Directory Server 1.4.0.14 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.0.14 Fedora packages are available on Fedora 28 and 29(rawhide). Rawhide(F29) https://koji.fedoraproject.org/koji/taskinfo?taskID=28969308 <https://koji.fedoraproject.org/koji/taskinfo?taskID=28969308> F28 https://koji.fedoraproject.org/koji/taskinfo?taskID=28970373 <https://koji.fedoraproject.org/koji/taskinfo?taskID=28970373> The new packages and versions are: * 389-ds-base-1.4.0.14-1 Source tarballs are available for download at Download 389-ds-base Source <https://releases.pagure.org/389-ds-base/389-ds-base-1.4.0.14.tar.bz2> Highlights in 1.4.0.14 Bug fixes and security fix Installation and Upgrade See Download <http://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install, use *dnf install 389-ds-base*, then run *dscreate*. For Cockput UI plugin use “dnf install cockpit-389-ds” See Install_Guide <http://www.port389.org/docs/389ds/howto/howto-install-389.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. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list: https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.o… 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 1.4.0.14 * Ticket 49891 - Use “__python3” macro for python scripts * Ticket 49890 - SECURITY FIX - ldapsearch with server side sort crashes the ldap server * Ticket 49029 - RFE -improve internal operations logging * Ticket 49893 - disable nunc-stans by default * Ticket 48377 - Update file name for LD_PRELOAD * Ticket 49884 - Improve nunc-stans test to detect socket errors sooner * Ticket 49888 - Use perl filter in rpm specfile * Ticket 49866 - Add password policy features to CLI/UI * Ticket 49881 - Missing check for crack.h * Ticket 48056 - Add more test cases to the basic suite * Ticket 49761 - Fix replication test suite issues * Ticket 49381 - Refactor the plugin test suite docstrings * Ticket 49837 - Add new password policy attributes to UI * Ticket 49794 - RFE - Add pam_pwquality features to password syntax checking * Ticket 49867 - Fix CLI tools’ double output

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users August 2018