Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
John_Gill Trusted Contributor.
Trusted Contributor.

Intruder Logout - slow eDir


Running Suse 11sp3 and OES11sp2. Recently the network went down due to power issues. I have done a timesync and eDir repair with "ndsrepair -T and -S and -R" and all seems to be good now.

A few users have password issues and a number of accounts get "Intruder Lockout". After unlocking the account with iManager and resetting the password, the user with still cannot login. After many refreshes and 10 minutes later the account gets unlocked and all is good.

eDir sync just seems to be very slow ....

Any help in this regard would be appreciated.
Labels (1)
1 Reply
Knowledge Partner
Knowledge Partner

Re: Intruder Logout - slow eDir

Is everything in your tree in one (1) partition, or do you have the tree
split up in to something other than the default [root] partition?

If you run the following from a box holding a replica of all partitions,
what do you get as output?

ndsrepair -T

ndsrepair -E

It may also help to know how big the eDirectory database (DIB) is, or how
many objects you have in the tree, but really the only thing that matters
which may impact slowness is the rate of changes happening.

If I were you I would, other than what is above, next go to iMonitor on
each box and watch changes made to see how quickly they are visible on all
servers in a given replica ring. For example, pull up a tab in Firefox or
Chrome for iMonitor (not iManager) on each server and go to a particular
object (a test user for example). Next use LDAP (preferably, because you
can point to a particular box and not worry about tree walking) or
iManager to change a user in some way, for example change their password.
In all of the iMonitor tabs refresh the object to see how long until they
show an updated modification timestamp. If it happens quickly (within a
few seconds at worst) you're fine. Not, document how long along with
where the change started (which server you used to change the password)
and which servers were slow being reached and how much, and then we can
look at that specifically.

If you can, check changes in all directions as networking misconfiguration
could potentially cause changes to be faster going from server A to server
B, but slower going from server B to server A. A power outage would not
cause that to happen normally, but if clients used to point to server B,
and now server B restarted (power outage) so now they are working with
server A instead, it may seem as if the reboot caused slowness when
actually it was slow all along but nobody did it the slow way before.

Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.