On 12/19/2013 09:19 AM, Joe Mou wrote:
Here are the results of that command:
$ ldapsearch -xLLL -D "cn=directory manager" -W -b
dc=the,dc=flatiron,dc=com '(objectclass=ldapsubentry)'
Enter LDAP Password:
dn: cn=Password Policy,cn=accounts,dc=the,dc=flatiron,dc=com
cn: Password Policy
cosspecifier: memberOf
cosAttribute: krbPwdPolicyReference override
costemplatedn: cn=cosTemplates,cn=accounts,dc=the,dc=flatiron,dc=com
objectClass: top
objectClass: ldapsubentry
objectClass: cosSuperDefinition
objectClass: cosClassicDefinition
description: Password Policy based on group membership
Ok. Looks like IPA uses CoS for password policy based on group
membership using the memberof attribute in each user's entry.
I think we can temporarily disable this.
First, save the above entry to a file e.g. pwpolicycos.ldif
Next, ipactl restart
Just after the directory server is restarted, delete this entry:
ldapdelete -x -D "cn=directory manager" -W "cn=Password
Policy,cn=accounts,dc=the,dc=flatiron,dc=com"
Once everything is working again, add back the entry:
ldapmodify -x -D "cn=directory manager" -W -a -f pwpolicycos.ldif
On Thu, Dec 19, 2013 at 7:07 AM, Rich Megginson <rmegg...@redhat.com
<mailto:rmegg...@redhat.com>> wrote:
On 12/19/2013 02:19 AM, Joe Mou wrote:
Thanks for the speedy reply. I am running on Fedora 19.
$ rpm -q 389-ds-base
389-ds-base-1.3.1.16-1.fc19.x86_64
$ rpm -q nss
nss-3.15.3-1.fc19.x86_64
Not sure what's going on, but let's see if we can get it
"unstuck". It seems there is a conflict between the Class of
Service plugin and the Member Of plugin. I think we may be able
to disable the CoS plugin to allow the deletion to proceed.
Do the following search to see what CoS definitions there are:
ldapsearch -xLLL -D "cn=directory manager" -W -b
dc=the,dc=flatiron,dc=com '(objectclass=ldapsubentry)'
On Wed, Dec 18, 2013 at 2:54 PM, Rich Megginson
<rmegg...@redhat.com <mailto:rmegg...@redhat.com>> wrote:
On 12/18/2013 12:43 PM, Joe Mou wrote:
I have a broken IPA replica that appears to be suffering
from a hung directory server. The master seems to be working
fine, but LDAP requests to the replica hang indefinitely. I
attached gdb to ns-slapd and suspect a deadlock in cos_cache.c.
Thread 7 seems to be hung on an LDAP delete for a user
account that we recently removed. Every time the directory
server is started, it tries to issue this delete, apparently
to sync the replica.
I have been unsuccessful in trying to remove the offending
replica because ipa-replica-manage seems to need to make
LDAP requests against the replica. For example:
$ ipa-replica-manage del p-ipa-wd02.prod.the.flatiron.com
<http://p-ipa-wd02.prod.the.flatiron.com>
^CConnection to 'p-ipa-wd02.prod.the.flatiron.com
<http://p-ipa-wd02.prod.the.flatiron.com>' failed:
Insufficient access: SASL(0): successful result:
Unable to delete replica 'p-ipa-wd02.prod.the.flatiron.com
<http://p-ipa-wd02.prod.the.flatiron.com>'
^CTraceback (most recent call last):
File "/usr/sbin/ipa-replica-manage", line 1252, in <module>
main()
KeyboardInterrupt
Backtraces of the suspicious threads and log excerpts are at
http://p.flatiron.com/~jmou/ipa/
<http://p.flatiron.com/%7Ejmou/ipa/> . I was only able to
install a limited set of debugging symbols; let me know if I
can be of more help.
Any help in fixing this replica or even just removing it
would be greatly appreciated!
What is your platform? rpm -q 389-ds-base
There were some hangs with rhel 6.4.z. Please update to the
latest 389-ds-base (1.2.11.15-30 or later) and nss 3.15.3 or
later.
Joe
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com <mailto:Freeipa-users@redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
