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:
Maybe someone has an idea?
Thanks and regards.
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
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.
On Thu, 2018-08-16 at 19:49 +0000, Paul Whitney wrote:
> 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?
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
Any help is appreciated!!
EDP Systems Analyst III
North Shore Community College
1 Ferncroft Road, Danvers MA 01923
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?
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.
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