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
    $ rpm -q nss

    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
        ^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

        ^CTraceback (most recent call last):
          File "/usr/sbin/ipa-replica-manage", line 1252, in <module>

        Backtraces of the suspicious threads and log excerpts are at
        <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 ( or later) and nss 3.15.3 or


        Freeipa-users mailing list
        Freeipa-users@redhat.com  <mailto:Freeipa-users@redhat.com>

Freeipa-users mailing list

Reply via email to