We have been using 389-ds as part of FreeIPA. In one of our environments,
we have 2 389-ds installations with replication.
Randomly, the 389-ds on either of them completely freezes and there are
high number of CLOSE_WAITs on tcp/389 port.
Only way to recover from this situation is to either reboot or "kill -9"
the ns-slapd process. Graceful restarts get stuck indefinitely.
One curious thing when this happens, a search using "ldapsearch" command
seems to work but a search using a python-ldap client does not. FreeIPA
does not work either.
Any pointers on troubleshooting this would be appreciated.
The scenario is simple: we have a subtree in the DIT with a few thousand
children node. The parent node of the subtree has a few acis including a
couple of macro acis that apply to each of the child nodes. We've
observed a significant performance degradation when trying to list all
the children in the presence of the macro acis.
Profiling on the client code show that although the first few child
nodes were fetched quite fast there is a clear delay buildup as the
retrieval progresses. The buildup is not present when the macro acis are
removed. Also, it is faster to split the list in chunks and retrieve
Is it possible that as the macro acis are resolved they are added to the
list of acis of the parent node so that the last nodes are evaluated
against many more acis than the first ones and hence the observed delay
in their retrieval? Is there a workaround for this?
I have a curious situation with our LDAP ecosystem at work. I have 2 LDAP
hosts in one data center (one is a replication supplier, one is a consumer)
and 1 consumer host in a separate data center(DC-B).
The issue is expired users can still successfully authenticate against the
consumer host DC-B, even though LDAP shows that the password is expired.
I've compiled outputs from each host into the following paste:
We are using an old version of 389-ds (as you can see from the paste),
version 184.108.40.206, and as far as I can tell (i'm a relative LDAP neophyte)
our configuration and replication properties are as expected, but I'm not
sure if there might be a permissions issue, some other issue, or a bug in
the old version we're using.
What else should I check next?
On a large 389 implementation - where downtime is not an option - are there
pros/cons to having the KDC on same server as 389 (sharing the database) -
or having the KDC on separate, redundant, servers?
I deleted my root suffix, and now, in the admin console, I can't recreate
the suffix, tells me it already exists.
Any ideas what file I can go edit to clean up any orphaned references to it
I have recycled the server, I have done a restore from backup.
I have multiple domain in my scenario, for that i have configure virtual
I require open-source web-console for creation user. 389-console is not
According to requirement, if i create any user for one domain, for other
domain same should be create as i press submit button.
Have their any solution..
*Keen & Able Comp. Pvt. ltd.*
we are trying to understand are performance issues and start
investigating the ACI's and indexes , I need to know if all "default
indexes" showing in 389-console admin are necessary beside the one which
we create for our application requirement :
- there are a 1/2 dozen of default indexes which are were there with DS
mailalternateAddress, ntUserDomain, ntUserDomainid,
seeAlso,numsubordinates etc... Can we just go an remove this indexes
from DS ( using admin console?) , are they been used internally by
-Is there a way to export all indexes in ldif file same we are doing
with ACI's , how?
We are seeing running a ldapsearc cmd line for count of groups ( 7000
entries with memberOf plugin enabled) takes aprox 17-18 sec with server
cfg fro multimaster replication and this is not acceptable by our users.
we are running 389DS version with OS :Linux proc5-02
2.6.32-431.el6.x86_64 #1 SMP Thu Nov 21 13:35:52 CST 2013 x86_64 x86_64
What is the recommended way to remove a database with the following
Would it be simply stopping slapd, remove the path and start slapd?
I have come across an issue when I restart the dirsrv-admin process or the actual 389 server where I am unable to login to the 389-console with my user ID and get the following message:
Cannot logon because of an incorrect User ID, Incorrect Password or Directory problem
Response: HTTP/1.1 401 Authorization Required
If I then login using the built-in admin account, close the console and then try to login using my user ID it now works. I have built 389 servers at multiple sites and they all have the same issue. Can people test if they have the same issue or if they have any ways that this can be solved?
Here are some extracts from /var/log/dirsrv/admin-serv/error (it has been altered slightly to remove ip's and domain names.)
# failed login with my user account
[Thu Sep 17 11:16:08 2015] [notice] [client xxx.xxx.xxx.xxx] admserv_host_ip_check: ap_get_remote_host could not resolve xxx.xxx.xxx.xxx
[Thu Sep 17 11:16:08 2015] [error] [client xxx.xxx.xxx.xxx] user test1 not found: /admin-serv/authenticate
# successful login as admin
[Thu Sep 17 11:33:50 2015] [notice] [client xxx.xxx.xxx.xxx] admserv_host_ip_check: ap_get_remote_host could not resolve xxx.xxx.xxx.xxx
[Thu Sep 17 11:33:50 2015] [notice] [client xxx.xxx.xxx.xxx] admserv_check_authz(): passing [/admin-serv/authenticate] to the userauth handler
# successful login with my user account
[Thu Sep 17 11:34:41 2015] [notice] [client xxx.xxx.xxx.xxx] admserv_host_ip_check: ap_get_remote_host could not resolve xxx.xxx.xxx.xxx
[Thu Sep 17 11:34:41 2015] [notice] [client xxx.xxx.xxx.xxx] admserv_check_authz(): passing [/admin-serv/authenticate] to the userauth handler
When starting the server the below lines appear in the log
[Thu Sep 17 11:09:32 2015] [notice] caught SIGTERM, shutting down
[Thu Sep 17 11:10:05 2015] [notice] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
[Thu Sep 17 11:10:06 2015] [notice] Access Host filter is: *.domain.com
[Thu Sep 17 11:10:06 2015] [notice] Access Address filter is: *
[Thu Sep 17 11:10:07 2015] [notice] Apache/2.2.15 (Unix) configured -- resuming normal operations
[Thu Sep 17 11:10:07 2015] [notice] Access Host filter is: *.domain.com
[Thu Sep 17 11:10:07 2015] [notice] Access Address filter is: *
389 packages installed
Any help would be much appreciated
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.