389-users August 2018

389-users@lists.fedoraproject.org

22 participants
34 discussions

Announcing 389 Directory Server 1.3.8.8
by Mark Reynolds 29 Aug '18

29 Aug '18

389 Directory Server 1.3.8.8 The 389 Directory Server team is proud to announce 389-ds-base version 1.3.8.8 Fedora packages are available on Fedora 27. https://koji.fedoraproject.org/koji/buildinfo?buildID=1139178 <https://koji.fedoraproject.org/koji/buildinfo?buildID=1139178> Bodhi https://bodhi.fedoraproject.org/updates/FEDORA-2018-ab880c1bc5 <https://bodhi.fedoraproject.org/updates/FEDORA-2018-ab880c1bc5> The new packages and versions are: * 389-ds-base-1.3.8.8-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.8.tar.bz2> Highlights in 1.3.8.8 * 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.8 * Revert “Ticket 49372 - filter optimisation improvements for common queries” * Revert “Ticket 49432 - filter optimise crash”

1 0

Announcing 389 Directory Server 1.4.0.16
by Mark Reynolds 29 Aug '18

29 Aug '18

389 Directory Server 1.4.0.16 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.0.16 Fedora packages are available on Fedora 28, 29, and rawhide. Rawhide https://koji.fedoraproject.org/koji/buildinfo?buildID=1139175 <https://koji.fedoraproject.org/koji/buildinfo?buildID=1139175> Fedora 29 https://koji.fedoraproject.org/koji/buildinfo?buildID=1139177 <https://koji.fedoraproject.org/koji/buildinfo?buildID=1139177> Fedora 28 https://koji.fedoraproject.org/koji/buildinfo?buildID=1139176 <https://koji.fedoraproject.org/koji/buildinfo?buildID=1139176> Bodhi https://bodhi.fedoraproject.org/updates/FEDORA-2018-aaf73e583d <https://bodhi.fedoraproject.org/updates/FEDORA-2018-aaf73e583d> The new packages and versions are: * 389-ds-base-1.4.0.16-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.16.tar.bz2> Highlights in 1.4.0.16 Bug fixes 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.16 * Revert “Ticket 49372 - filter optimisation improvements for common queries” * Revert “Ticket 49432 - filter optimise crash” * Ticket 49887 - Fix SASL map creation when –disable-perl * Ticket 49858 - Add backup/restore and import/export functionality to WebUI/CLI

1 0

dirsrv becomes completely unresponsible
by Jan Kowalsky 22 Aug '18

22 Aug '18

Hi all, we still struggeling with multiple problems in our 389-ds setup. I already opened the threads "disk i/o: very high write rates" and "ldapsearch performance problem". Another (the biggest) problem is, that dirsrv becomes suddenly totally unresponsive. The server is still running, no errors in error-log - but ldap queries are not answered and run in timeouts. The only way is to restart it. After restart everything is fine - for a while. But sometimes it hangs immediately again after restart. I logged a straces while dirsrv was unresponsive: https://nextcloud.datenkollektiv.net/s/qD8ojQZztMqbQtp Maybe someone has an idea? Thanks and regards. Jan

3 3

Having problem setting a read only replica (different database generation ID)
by Patrick Dung 22 Aug '18

22 Aug '18

Hello, I had an DS instance with data. I had problem setting a read only replica. The master server can connect to the slave but it had problem initialize the slave. I had tried to use the same method to create another slave instance in the master server (using a different port) Replication does not start. The error message is the same. For both cases, the slave instances are brand new, it is empty without any data. slapd-cms1 (master) [21/Aug/2018:16:12:16.362357876 +0800] - DEBUG - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=Replication Agreement cms1 to cms1b" (cms1:2389): State: backoff -> backoff [21/Aug/2018:16:12:16.367449793 +0800] - DEBUG - NSMMReplicationPlugin - conn_connect - agmt="cn=Replication Agreement cms1 to cms1b" (cms1:2389) - Trying non-secure slapi_ldap_init_ext [21/Aug/2018:16:12:16.369104649 +0800] - DEBUG - NSMMReplicationPlugin - conn_connect - agmt="cn=Replication Agreement cms1 to cms1b" (cms1:2389) - binddn = cn=replicator,cn=config, passwd = <REDICATED> [21/Aug/2018:16:12:16.372538122 +0800] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=Replication Agreement cms1 to cms1b" (cms1:2389): Replication bind with SIMPLE auth resumed [21/Aug/2018:16:12:16.374333105 +0800] - DEBUG - NSMMReplicationPlugin - conn_cancel_linger - agmt="cn=Replication Agreement cms1 to cms1b" (cms1:2389) - No linger to cancel on the connection [21/Aug/2018:16:12:16.378484502 +0800] - DEBUG - _csngen_adjust_local_time - gen state before 5b7bc8c70001:1534838983:0:0 [21/Aug/2018:16:12:16.379573648 +0800] - DEBUG - _csngen_adjust_local_time - gen state after 5b7bc9600000:1534839136:0:0 [21/Aug/2018:16:12:16.398745479 +0800] - DEBUG - NSMMReplicationPlugin - acquire_replica - agmt="cn=Replication Agreement cms1 to cms1b" (cms1:2389): Replica was successfully acquired. [21/Aug/2018:16:12:16.399914497 +0800] - DEBUG - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=Replication Agreement cms1 to cms1b" (cms1:2389): State: backoff -> sending_updates [21/Aug/2018:16:12:16.402441965 +0800] - WARN - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=Replication Agreement cms1 to cms1b" (cms1:2389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. [21/Aug/2018:16:12:16.412642556 +0800] - DEBUG - NSMMReplicationPlugin - release_replica - agmt="cn=Replication Agreement cms1 to cms1b" (cms1:2389): Successfully released consumer [21/Aug/2018:16:12:16.413664186 +0800] - DEBUG - NSMMReplicationPlugin - conn_start_linger -agmt="cn=Replication Agreement cms1 to cms1b" (cms1:2389) - Beginning linger on the connection [21/Aug/2018:16:12:16.416302958 +0800] - DEBUG - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=Replication Agreement cms1 to cms1b" (cms1:2389): State: sending_updates -> start_backoff [21/Aug/2018:16:12:19.418319466 +0800] - DEBUG - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=Replication Agreement cms1 to cms1b" (cms1:2389): State: start_backoff -> backoff [21/Aug/2018:16:12:19.419789083 +0800] - DEBUG - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=Replication Agreement cms1 to cms1b" (cms1:2389): State: backoff -> wait_for_changes [21/Aug/2018:16:12:45.421513358 +0800] - DEBUG - replication - multimaster_mmr_postop - error 0 for oparation 561. [21/Aug/2018:16:13:15.436245528 +0800] - DEBUG - replication - multimaster_mmr_postop - error 0 for oparation 561. [21/Aug/2018:16:13:16.437671170 +0800] - DEBUG - NSMMReplicationPlugin - linger_timeout - agmt="cn=Replication Agreement cms1 to cms1b" (cms1:2389) - Linger timeout has expired on the connection [21/Aug/2018:16:13:16.438990759 +0800] - DEBUG - NSMMReplicationPlugin - close_connection_internal - agmt="cn=Replication Agreement cms1 to cms1b" (cms1:2389) - Disconnected from the consumer slapd-cms1b (slave) [21/Aug/2018:16:11:48.532245798 +0800] - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 2389 for LDAP requests [21/Aug/2018:16:11:48.534478125 +0800] - INFO - slapd_daemon - Listening on /var/run/slapd-cms1b.socket for LDAPI requests [21/Aug/2018:16:11:50.617214069 +0800] - DEBUG - replication - multimaster_mmr_postop - error 0 for oparation 561. [21/Aug/2018:16:12:16.383019206 +0800] - DEBUG - NSMMReplicationPlugin - consumer_connection_extension_acquire_exclusive_access - conn=1 op=3 Acquired consumer connection extension [21/Aug/2018:16:12:16.385344779 +0800] - DEBUG - NSMMReplicationPlugin - multimaster_extop_StartNSDS50ReplicationRequest - conn=1 op=3 repl="dc=local,dc=nonet": Begin incremental protocol [21/Aug/2018:16:12:16.387493146 +0800] - DEBUG - csngen_adjust_time - gen state before 5b7bc9440001:1534839108:0:0 [21/Aug/2018:16:12:16.388905774 +0800] - DEBUG - _csngen_adjust_local_time - gen state before 5b7bc9440001:1534839108:0:0 [21/Aug/2018:16:12:16.390557696 +0800] - DEBUG - _csngen_adjust_local_time - gen state after 5b7bc9600000:1534839136:0:0 [21/Aug/2018:16:12:16.392326474 +0800] - DEBUG - csngen_adjust_time - gen state after 5b7bc9600001:1534839136:0:0 [21/Aug/2018:16:12:16.394008974 +0800] - DEBUG - NSMMReplicationPlugin - replica_get_exclusive_access - conn=1 op=3 repl="dc=local,dc=nonet": Acquired replica [21/Aug/2018:16:12:16.395846688 +0800] - DEBUG - NSMMReplicationPlugin - multimaster_extop_StartNSDS50ReplicationRequest - conn=1 op=3 repl="dc=local,dc=nonet": StartNSDS90ReplicationRequest: response=0 rc=0 [21/Aug/2018:16:12:16.397719862 +0800] - DEBUG - NSMMReplicationPlugin - consumer_connection_extension_relinquish_exclusive_access - conn=1 op=3 Relinquishing consumer connection extension [21/Aug/2018:16:12:16.404985230 +0800] - DEBUG - NSMMReplicationPlugin - consumer_connection_extension_acquire_exclusive_access - conn=1 op=4 Acquired consumer connection extension [21/Aug/2018:16:12:16.407091172 +0800] - DEBUG - replication - multimaster_mmr_postop - error 0 for oparation 561. [21/Aug/2018:16:12:16.409703770 +0800] - DEBUG - NSMMReplicationPlugin - replica_relinquish_exclusive_access - conn=1 op=4 repl="dc=local,dc=nonet": Released replica held by locking_purl=conn=1 id=3 [21/Aug/2018:16:12:16.411965844 +0800] - DEBUG - NSMMReplicationPlugin - consumer_connection_extension_relinquish_exclusive_access - conn=1 op=4 Relinquishing consumer connection extension Thanks.

2 4

Password Policies and lastLoginTime
by Harvey, Robert 20 Aug '18

20 Aug '18

Is it possible to turn on recording of users Last Login times in selected OUs without turning on alwaysRecordLogin in cn=config,cn=Account Policy Plugin,cn=plugins,cn=config? I'm using ds389 to service SSSD Centos and RHEL (6 and 7) clients and some some Solaris 10 and 11 clients. Currently with about client 80 systems. With 10 masters and with alwaysrecordlogin set to ON, with 2 replication agreements outbound from each of the ds389 servers, the replication could barely keep up and sometime has to wait for 10 minutes of more to be able access a replication destination. There was far too many updates for the replication to handle just from these few client systems last login times. Each ds389 server is bare metal install on X4-2 server running Centos 7. I need to track the user's (humans) last log in times. I do not need (and I don't see that it is possible) to track the last login times of all the machine accounts. I had turn off the alwaysRecordLogin. Thanks, Bob Harvey

2 1

Re: Using dbmon.sh
by William Brown 20 Aug '18

20 Aug '18

On Thu, 2018-08-16 at 19:49 +0000, Paul Whitney wrote: > 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? I think the counters used to be 32bit atomically incremented integers, so perhaps you have hit the max values and it's rolled over? Mark may know more. What version of 389 are you using? Has your server been up for a reallllyyyyyy long time? Thanks! -- Sincerely, William

1 0

Help with NSS Database
by Cassandra Reed 20 Aug '18

20 Aug '18

Hi Everyone, We are in a sticky spot right now where we need to install a new certificate in our 389 Production system, but we do not have the password that was used when the system was built years ago. We have tried all of the possible passwords that we can think of, to no avail. Is there a way to blow away the old password or even blow away the NSS Database and create a new one? We need a new certificate installed ASAP to be able to move forward with a big project, so this is an issue with a lot of visibility. Any help is appreciated!! -Cassandra Cassandra Reed 978-762-4222 EDP Systems Analyst III North Shore Community College 1 Ferncroft Road, Danvers MA 01923

3 2

user privileges needed to run repl-monitor.pl
by Sergei Gerasenko 17 Aug '18

17 Aug '18

Hi, I’ve been using repl-monitor.pl for monitoring replication problems. I would like to use an account with a minimal set of permissions needed for the functionality. I created a user and added the permission to Read Replication Agreements. Now the user can read the agreements but fails on: $ruv = $conn->search($replicaroot, "one”, "(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectClass=nsTombstone))”, 0, qw(nsds50ruv nsruvReplicaLastModified nsds5AgmtMaxCSN)); Rather, the $ruv is empty after that call. When running with a privileged account, everything works. What are the permissions needed for that search to work for a brand new account? Thanks, Sergei

2 6

LDAP group to provide 389-console access?
by Nick W. Harrison 17 Aug '18

17 Aug '18

Hello - I am wanting to provide some GUI-based management console for my coworkers. To that end, I'm trying to make it so members of a certain LDAP-based group can login to 389-console as themselves, register LDAP instances, and start managing those LDAP instances with "directory administrator" permissions. When I was installing 389 to begin with, the install process asked me to create an admin user. That admin user can login to the admin console GUI and manage the LDAP services fine, but now I want to designate members of an LDAP group to manage the instance through the 389 admin console as well. When I add this group to the "Directory Administrators" group built-in to 389 DS and login to Admin Console, I only see a blank screen and no option to add 389 instances to manage. Not sure where to go now. I appreciate any advice. Nick

2 1

Announcing 389 Directory Server 1.4.0.15
by Mark Reynolds 16 Aug '18

16 Aug '18

389 Directory Server 1.4.0.15 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.0.15 Fedora packages are available on Fedora 28, 29, and rawhide. Rawhide https://koji.fedoraproject.org/koji/taskinfo?taskID=29119556 <https://koji.fedoraproject.org/koji/taskinfo?taskID=29119556> Fedora 29 https://koji.fedoraproject.org/koji/taskinfo?taskID=29120673 <https://koji.fedoraproject.org/koji/taskinfo?taskID=29120673> Fedora 28 https://koji.fedoraproject.org/koji/taskinfo?taskID=29121909 <https://koji.fedoraproject.org/koji/taskinfo?taskID=29121909> The new packages and versions are: * 389-ds-base-1.4.0.15-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.15.tar.bz2> Highlights in 1.4.0.15 Bug fixes 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.15 * Ticket 49029 - Internal logging thread data needs to allocate int pointers * Ticket 48061 - CI test - config * Ticket 48377 - Only ship libjemalloc.so.2 * Ticket 49885 - On some platform fips does not exist

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