Announcing 389 Directory Server 1.3.8.8
by Mark Reynolds
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...
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”
5 years, 7 months
dirsrv becomes completely unresponsible
by Jan Kowalsky
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
5 years, 7 months
Having problem setting a read only replica (different database generation ID)
by Patrick Dung
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.
5 years, 7 months
Password Policies and lastLoginTime
by Harvey, Robert
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
5 years, 7 months
Re: Using dbmon.sh
by William Brown
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
5 years, 7 months
Help with NSS Database
by Cassandra Reed
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
5 years, 7 months
user privileges needed to run repl-monitor.pl
by Sergei Gerasenko
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
5 years, 7 months
LDAP group to provide 389-console access?
by Nick W. Harrison
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
5 years, 7 months