Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1049525

Summary: Server hangs in cos_cache when adding a user entry
Product: Red Hat Enterprise Linux 7 Reporter: Nathan Kinder <nkinder>
Component: 389-ds-baseAssignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Sankar Ramalingam <sramling>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: jgalipea, mkosek, nhosoi, nsoman, spoore
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.3.1.6-17.el7 Doc Type: Bug Fix
Doc Text:
Cause: In processing CoS definition entry, if cosTemplateDn is not yet given, when cosAttribute is processed, the entry's parent entry DN is set to cosTemplateDn automatically. Consequence: The parent entry could be an ancestor entry of an entry to be updated. If the entry is a target of betxn type of plug-ins, it causes a deadlock. Fix: The parent entry DN is now added only when codTemplateDn is not provided. Result: Even if cosAttribute and cosTemplateDn are listed in the order in the CoS definition entry and betxn type plug-ins are enabled, updating an entry does not cause a deadlock.
 Story Points: ---
Clone Of:
: 1109443 (view as bug list) Environment:
Last Closed: 2014-06-13 10:53:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1109443    

Description Nathan Kinder 2014-01-07 17:01:12 UTC 
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47649

Originally reported on the IPA mailing list: https://www.redhat.com/archives/freeipa-users/2013-December/msg00106.html

I am running IPA on Fedora 19 with one master and one replica. Originally I had an issue where the replica would hang while starting up. It appeared to be a deadlock in cos_cache.c which caused any LDAP request to hang. I was able to workaround this issue with Rich's suggestion: https://www.redhat.com/archives/freeipa-users/2013-December/msg00117.html

Now the server no longer hangs while starting up. However it does hang when adding a new user with `ipa user-add joe-test --first=joe --last=test`. The backtrace (attached) seems to still indicate a deadlock in cos_cache.c. Both the master and replica hang depending where the request is sent.

I was also apparently able to remedy the replica by running `ipa-replica-manage re-initialize --from p-ipa-wd01.prod.the.flatiron.com`. Now user add requests to the replica work fine while user add requests to the master hang.
Comment 1 Scott Poore 2014-01-13 15:34:21 UTC 
So is the test for this bug simply to setup an IPA Master and Replica and add a user on the replica?  If it hangs, we see this?  Are we going to need a backtrace during the user-add to confirm here?

Thanks,
Scott
Comment 2 Noriko Hosoi 2014-01-13 18:08:18 UTC 
(In reply to Scott Poore from comment #1)
> So is the test for this bug simply to setup an IPA Master and Replica and
> add a user on the replica?
The reporter of the bug wrote so. It looks like a timing issue in the COS cache.  So, you may need to stress the server until the hang occurs...

> If it hangs, we see this?  Are we going to need
> a backtrace during the user-add to confirm here?

If it hangs, the add does not finish -- it hangs in the DS backend.  Yes, please attach gdb to the hung DS and get the backtrace.

Thank you!
--noriko
Comment 3 Noriko Hosoi 2014-01-14 21:29:42 UTC 
(In reply to Scott Poore from comment #1)
> So is the test for this bug simply to setup an IPA Master and Replica and
> add a user on the replica?  If it hangs, we see this?  Are we going to need
> a backtrace during the user-add to confirm here?
> 
> Thanks,
> Scott

Hi Scott,

Did you have a luck to reproduce the hang?

Aside from the effort, could you find out some way to get the full content of the entry of an user to be added with this command line "ipa user-add joe-test --first=joe --last=test"?

This is the DN of the entry in the original ticket (https://fedorahosted.org/389/ticket/47649):
uid=joe-test,cn=users,cn=accounts,dc=...

I'm especially interested in what objectclass'es are found in the entry.

Thanks,
--noriko
Comment 4 Noriko Hosoi 2014-01-15 00:38:39 UTC 
Hi Scott, I have one more question...

I've installed ipa with no option.  Then I found this COS definition in the DS, but I don't see any COS template entries to map from memberOf (cosspecifier) to krbPwdPolicyReference (cosAttribute).  Do you happen to know how the COS templates are being added?  I guess it's in the IPA installation phase?  That might be a key for this hang...

   dn: cn=Password Policy,cn=accounts,dc=example,dc=com
   description: Password Policy based on group membership
   objectClass: top
   objectClass: ldapsubentry
   objectClass: cosSuperDefinition
   objectClass: cosClassicDefinition
   costemplatedn: cn=cosTemplates,cn=accounts,dc=example,dc=com
   cosAttribute: krbPwdPolicyReference override
   cosspecifier: memberOf
   cn: Password Policy
Comment 5 Scott Poore 2014-01-15 15:15:32 UTC 
Noriko,

Sorry, I haven't had a chance to dig more into this yet.  So, I haven't been able to reproduce it yet.

I'm not sure I understand your question in comment #3:

> could you find out some way to get the full content of the entry of an 
> user to be added with this command line "ipa user-add joe-test 
> --first=joe --last=test"?

Are you asking about using ipa command line to specify all attributes for the uesr?  That should be possible.  "ipa help user-add" shows all options supported and for setting any attributes not directly suppported there is the --addattr flag as well.

For you question in comment #4:

> Do you happen to know how the COS templates are being added?  I guess 
> it's in the IPA installation phase? 

I would think so, but, we may need to confirm with someone from IPA dev that knows better.  Looking at /var/log/ipaserver-install.log though, I do see some enties for cosspecifier.  So, maybe that is where it's being setup.

I'll add Martin as well so he can maybe answer your question.

Thanks,
Scott
Comment 6 Noriko Hosoi 2014-01-16 19:58:36 UTC 
Thank you, Scott.

I found if we run "ipa pwpolicy-add ...", it adds a cosTemplate entry.  (I followed the example on this page: http://www.freeipa.org/page/GroupPasswordPolicy, but with the cosTemplate, I could not make the server hang happen...)

Now I'm wondering if there could be any ipa-server-install option which adds pwpolicy automatically?  It sounded the bug reporter did not add password policy manually.  In the meantime, I'm asking him if he has cosTemplate entries in his DS or not...
Comment 7 Noriko Hosoi 2014-01-21 00:18:17 UTC 
Hi Scott, Hi Martin,

I need your help to understand this bug/ticket.  I'm trying to reproduce the bug but as you see on the 389 ticket 47649, the effort has been fruitless so far...

More I investigate, more I'm confused.  Could you please take a look at this comment?
https://fedorahosted.org/389/ticket/47649#comment:15

I wonder if there is any chance that IPA adds an ordinary user as a cos entry?  Unless a cos related objectclass, user-add has no chance to call cos_cache_change_notify and hangs there.  Since it's in the libdb transaction, it makes other threads hang...

Any input would be greatly appreciated.
Comment 9 Namita Soman 2014-02-13 17:05:39 UTC 
Please add steps to verify this using IPA
Comment 10 Noriko Hosoi 2014-02-13 17:42:38 UTC 
(In reply to Namita Soman from comment #9)
> Please add steps to verify this using IPA

I don't know how it happened but the reporter installed IPA and he did something in the first password configuration.  The password policy cosdefinition usually has this attribute order (see FREEIPA/install/share/bootstrap-template.ldif).  (Note: cosTemplateDn is located before cosAttribute):
  dn: cn=Password Policy,cn=accounts,$SUFFIX
  changetype: add
  description: Password Policy based on group membership
  objectClass: top
  objectClass: ldapsubentry
  objectClass: cosSuperDefinition
  objectClass: cosClassicDefinition
  cosTemplateDn: cn=cosTemplates,cn=accounts,$SUFFIX
  cosAttribute: krbPwdPolicyReference override
  cosSpecifier: memberOf

But somehow, his costemplatedn is placed at the end.  I'm not sure how it happened to his system.
  dn: cn=Password Policy,cn=accounts,dc=example,dc=com
  description: Password Policy based on group membership
  objectClass: top
  objectClass: ldapsubentry
  objectClass: cosSuperDefinition
  objectClass: cosClassicDefinition
  cosAttribute: krbPwdPolicyReference override
  cosspecifier: memberOf
  cn: Password Policy
  costemplatedn: cn=cosTemplates,cn=accounts,dc=example,dc=com

Once you have this cosDefinition, adding any user under the password policy management failed by the bug.  It should have been fixed.
Comment 11 Martin Kosek 2014-02-14 07:37:37 UTC 
Hello, I personally never reproduced this one. I actually do not know how the "cn=Password Policy,cn=accounts,dc=example,dc=com" works, it is in our DS bootstrap template for IPA installation, but it never shows up in a running IPA version.
Comment 12 Noriko Hosoi 2014-02-17 07:01:12 UTC 
(In reply to Martin Kosek from comment #11)
> Hello, I personally never reproduced this one. I actually do not know how
> the "cn=Password Policy,cn=accounts,dc=example,dc=com" works, it is in our
> DS bootstrap template for IPA installation, but it never shows up in a
> running IPA version.

Once the Password policy is configured on IPA, it looks the entry is added to the DS by IPA.  I think one of the python scripts does the job.  But I also don't know how the odd attribute order was introduced at the customer's site...
Comment 14 Noriko Hosoi 2014-03-17 19:07:17 UTC 
Steps:

Enable Password Policy.  Then you should be able to see this entry ($SUFFIX is replaced with your real suffix)
 dn: cn=Password Policy,cn=accounts,$SUFFIX
 description: Password Policy based on group membership
 objectClass: top
 objectClass: ldapsubentry
 objectClass: cosSuperDefinition
 objectClass: cosClassicDefinition
 cosTemplateDn: cn=cosTemplates,cn=accounts,$SUFFIX
 cosAttribute: krbPwdPolicyReference override
 cosSpecifier: memberOf

Delete "cosTemplateDn: cn=cosTemplates,cn=accounts,$SUFFIX" from this entry once, then add it back.  Then, you will see the attribute order as follows:
 dn: cn=Password Policy,cn=accounts,$SUFFIX
 description: Password Policy based on group membership
 objectClass: top
 objectClass: ldapsubentry
 objectClass: cosSuperDefinition
 objectClass: cosClassicDefinition
 cosAttribute: krbPwdPolicyReference override
 cosSpecifier: memberOf
 cosTemplateDn: cn=cosTemplates,cn=accounts,$SUFFIX <== added at the end

Then, restart the DS, which made the server hang and the server did not restart.  If it does, you can mark VERIFIED.
Comment 15 Scott Poore 2014-03-20 00:48:25 UTC 
I can see in ipaserver-install.log where this seems to have been added by the bootstap I'm guessing?

I however do not see this on a running server after install:

[root@rhel7-1 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test"

[root@rhel7-1 ~]# 
 
How can I "Enable Password Policy" so that I can see this?

Or, would this apply to another dn for IPA configuration?

Can I delete and re-add the entry from scratch?  That doesn't seems 

[root@rhel7-2 yum.repos.d]# ldapdelete -D 'cn=Directory Manager' -w Secret123 "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test"

[root@rhel7-2 yum.repos.d]# ldapadd -D 'cn=Directory Manager' -w Secret123 <<EOF
> dn: cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test
> description: Password Policy based on group membership
> objectClass: top
> objectClass: ldapsubentry
> objectClass: cosSuperDefinition
> objectClass: cosClassicDefinition
> cosAttribute: krbPwdPolicyReference override
> cosSpecifier: memberOf
> cosTemplateDn: cn=cosTemplates,cn=accounts,dc=ipa1,dc=example,dc=test
> EOF
adding new entry "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test"

Even after adding it I can't see it:

[root@rhel7-2 yum.repos.d]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test"

So, what am I doing wrong?

Thanks,
Scott
Comment 16 Noriko Hosoi 2014-03-20 00:57:05 UTC 
Sorry, I'm not familiar with the IPA Password Policy configuration.  Could someone who is an expert tell us how to enable/configure it?

My experience on this issue was ...
. the reporter of the 389 trac ticket 47649 installed IPA and configured Password Policy.
. from the very beginning, the directory server does not run but did hang in the startup phase.
. the cause of the hang was CoS Cache bug, which is supposed to verify.
. the reporter also do not recall what he did in the first IPA installation and put the server to the state.
Comment 17 Rich Megginson 2014-03-20 01:01:42 UTC 
(In reply to Scott Poore from comment #15)
> I can see in ipaserver-install.log where this seems to have been added by
> the bootstap I'm guessing?
> 
> I however do not see this on a running server after install:
> 
> [root@rhel7-1 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b
> "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test"
> 
> [root@rhel7-1 ~]# 
>  
> How can I "Enable Password Policy" so that I can see this?
> 
> Or, would this apply to another dn for IPA configuration?
> 
> Can I delete and re-add the entry from scratch?  That doesn't seems 
> 
> [root@rhel7-2 yum.repos.d]# ldapdelete -D 'cn=Directory Manager' -w
> Secret123 "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test"
> 
> [root@rhel7-2 yum.repos.d]# ldapadd -D 'cn=Directory Manager' -w Secret123
> <<EOF
> > dn: cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test
> > description: Password Policy based on group membership
> > objectClass: top
> > objectClass: ldapsubentry
> > objectClass: cosSuperDefinition
> > objectClass: cosClassicDefinition
> > cosAttribute: krbPwdPolicyReference override
> > cosSpecifier: memberOf
> > cosTemplateDn: cn=cosTemplates,cn=accounts,dc=ipa1,dc=example,dc=test
> > EOF
> adding new entry "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test"
> 
> Even after adding it I can't see it:
> 
> [root@rhel7-2 yum.repos.d]# ldapsearch -xLLL -D "cn=Directory Manager" -w
> Secret123 -b "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test"
> 
> So, what am I doing wrong?

Entries with objectclass: ldapsubentry are invisible to normal ldap searches.  You have to ask for such entries explicitly by objectclass:

[root@rhel7-2 yum.repos.d]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test" 'objectclass=ldapsubentry'

> 
> Thanks,
> Scott
Comment 18 Scott Poore 2014-03-20 15:07:20 UTC 
Noriko,

I believe Password Policy should be enabled from the start.  There is a default global_policy policy on a normal IPA server install.  Just in case, I also tested by adding a new one though.

Rich,

Ok, that makes much more sense now.  I was wondering if it was hidden like the tombstone stuff.  Thanks for the info.

So, getting closer to verifying this one.  I'm still having a problem though.  I can delete and re-add costemplatedn but, it's not showing up at the end of the attribute print order:

[root@rhel7-1 ~]# rpm -q 389-ds-base
389-ds-base-1.3.1.6-13.el7.x86_64

[root@rhel7-1 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test" "objectclass=ldapsubentry"
dn: cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test
description: Password Policy based on group membership
objectClass: top
objectClass: ldapsubentry
objectClass: cosSuperDefinition
objectClass: cosClassicDefinition
costemplatedn: cn=cosTemplates,cn=accounts,dc=ipa1,dc=example,dc=test
cosAttribute: krbPwdPolicyReference override
cosspecifier: memberOf
cn: Password Policy

[root@rhel7-1 ~]# ldapmodify -D 'cn=Directory Manager' -w Secret123 <<EOF
> dn: cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test
> changetype: modify
> delete: costemplatedn
> EOF
modifying entry "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test"

[root@rhel7-1 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test" "objectclass=ldapsubentry"
dn: cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test
description: Password Policy based on group membership
objectClass: top
objectClass: ldapsubentry
objectClass: cosSuperDefinition
objectClass: cosClassicDefinition
cosAttribute: krbPwdPolicyReference override
cosspecifier: memberOf
cn: Password Policy

[root@rhel7-1 ~]# ldapmodify -D 'cn=Directory Manager' -w Secret123 <<EOF
> dn: cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test
> changetype: modify
> add: costemplatedn
> costemplatedn: cn=cosTemplates,cn=accounts,dc=ipa1,dc=example,dc=test
> EOF
modifying entry "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test"

[root@rhel7-1 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test" "objectclass=ldapsubentry"
dn: cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test
costemplatedn: cn=cosTemplates,cn=accounts,dc=ipa1,dc=example,dc=test
description: Password Policy based on group membership
objectClass: top
objectClass: ldapsubentry
objectClass: cosSuperDefinition
objectClass: cosClassicDefinition
cosAttribute: krbPwdPolicyReference override
cosspecifier: memberOf
cn: Password Policy

And I try to restart directory server to see if it will hang but, it does not.

[root@rhel7-1 ~]# ipactl restart
Restarting Directory Service
Restarting krb5kdc Service
Restarting kadmin Service
Restarting named Service
Restarting ipa_memcached Service
Restarting httpd Service
Restarting pki-tomcatd Service
Restarting ipa-otpd Service
ipa: INFO: The ipactl command was successful

I also tried deleting the entire entry again and re-adding and that didn't hang on restart either.
Comment 19 Noriko Hosoi 2014-03-20 17:02:39 UTC 
Hi Scott,

Interesting...  It seems an added attribute is placed at the top?  Then, could you delete cosAttribute and add it back?  All we need to have is the order.

But if you already tried the order (cosAttribute is placed before cosTemplateDn) in this attempt and server started normally, I believe you verified the bug fix.
> I also tried deleting the entire entry again and re-adding and that didn't hang on restart either.

Thanks!
--noriko
Comment 20 Scott Poore 2014-03-20 18:20:59 UTC 
Not sure if I was clear but the previous tests I tried were against an older version of 389-ds-base.

I got an error trying to delete cosAttribute.

[root@rhel7-2 ~]# ldapmodify -D 'cn=Directory Manager' -w Secret123 <<EOF
dn: cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test
changetype: modify
delete: cosAttribute
EOF                                                                  
modifying entry "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test"
ldap_modify: Object class violation (65)
	additional info: missing attribute "cosAttribute" required by object class "cosSuperDefinition"


So, I tried deleting again and re-adding.  I see this order when I do that:

[root@rhel7-2 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test" "objectclass=ldapsubentry"
dn: cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test
cn: Password Policy
description: Password Policy based on group membership
objectClass: top
objectClass: ldapsubentry
objectClass: cosSuperDefinition
objectClass: cosClassicDefinition
cosAttribute: krbPwdPolicyReference override
cosspecifier: memberOf
costemplatedn: cn=cosTemplates,cn=accounts,dc=ipa1,dc=example,dc=test


So, that is with the Order in question right?  cosAttribute before costemplatedn to cause the hang?

This was with 389-ds-base-1.3.1.6-14.el7.x86_64 to try to reproduce the hang.  So far, I have been unable to reproduce the hang.  

Unless there is another suggestion for how I can reproduce this hang on a pre-patched version, I think I'm going to upgrade, quick check, and verify this one as Sanity Only.

Thanks,
Scott
Comment 21 Noriko Hosoi 2014-03-20 18:31:12 UTC 
(In reply to Scott Poore from comment #20)
> So, that is with the Order in question right?  cosAttribute before
> costemplatedn to cause the hang?

Yes, it's supposed to do...

> This was with 389-ds-base-1.3.1.6-14.el7.x86_64 to try to reproduce the
> hang.  So far, I have been unable to reproduce the hang.  

It's different from what I observed...  But I think the steps you took are all correct.

> Unless there is another suggestion for how I can reproduce this hang on a
> pre-patched version, I think I'm going to upgrade, quick check, and verify
> this one as Sanity Only.
> 
> Thanks,
> Scott

Thank you!
--noriko
Comment 22 Scott Poore 2014-03-21 00:52:31 UTC 
Verified.  

(Sanity Only since I was never able to reproduce this particular hang).

Version ::

389-ds-base-1.3.1.6-23.el7.x86_64

Results ::

After upgrading RPM to patched version:

* Restart IPA services after upgrade:

[root@rhel7-2 ~]# ipactl restart
Restarting Directory Service
Restarting krb5kdc Service
Restarting kadmin Service
Restarting named Service
Restarting ipa_memcached Service
Restarting httpd Service
Restarting pki-tomcatd Service
Restarting ipa-otpd Service
ipa: INFO: The ipactl command was successful

* Search for CN:

[root@rhel7-2 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test" "objectclass=ldapsubentry"
dn: cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test
cn: Password Policy
description: Password Policy based on group membership
objectClass: top
objectClass: ldapsubentry
objectClass: cosSuperDefinition
objectClass: cosClassicDefinition
cosAttribute: krbPwdPolicyReference override
cosspecifier: memberOf
costemplatedn: cn=cosTemplates,cn=accounts,dc=ipa1,dc=example,dc=test

* Since costemplatedn is last, restart DS again to make sure it doesn't hang:

[root@rhel7-2 ~]# systemctl restart dirsrv.target

* Check slapd process:

[root@rhel7-2 ~]# ps -ef|grep slapd
dirsrv    9063     1  6 19:37 ?        00:00:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-IPA1-EXAMPLE-TEST -i /var/run/dirsrv/slapd-IPA1-EXAMPLE-TEST.pid -w /var/run/dirsrv/slapd-IPA1-EXAMPLE-TEST.startpid
root      9109  2321  0 19:38 pts/0    00:00:00 grep --color=auto slapd

* Check IPA status:

[root@rhel7-2 ~]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
ipa_memcached Service: RUNNING
httpd Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa: INFO: The ipactl command was successful

* Delete costemplatedn from entry:

[root@rhel7-2 ~]# ldapmodify -D 'cn=Directory Manager' -w Secret123 <<EOF
> dn: cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test
> changetype: modify
> delete: costemplatedn
> EOF
modifying entry "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test"

* Search for CN:

[root@rhel7-2 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test" "objectclass=ldapsubentry"
dn: cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test
cn: Password Policy
description: Password Policy based on group membership
objectClass: top
objectClass: ldapsubentry
objectClass: cosSuperDefinition
objectClass: cosClassicDefinition
cosAttribute: krbPwdPolicyReference override
cosspecifier: memberOf

* Add costemplatedn back to entry:

[root@rhel7-2 ~]# ldapmodify -D 'cn=Directory Manager' -w Secret123 <<EOF
> dn: cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test
> changetype: modify
> add: costemplatedn
> costemplatedn: cn=cosTemplates,cn=accounts,dc=ipa1,dc=example,dc=test
> EOF
modifying entry "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test"

* Search for CN:

[root@rhel7-2 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test" "objectclass=ldapsubentry"
dn: cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test
costemplatedn: cn=cosTemplates,cn=accounts,dc=ipa1,dc=example,dc=test
cn: Password Policy
description: Password Policy based on group membership
objectClass: top
objectClass: ldapsubentry
objectClass: cosSuperDefinition
objectClass: cosClassicDefinition
cosAttribute: krbPwdPolicyReference override
cosspecifier: memberOf

* Restart DS and check for hang:

[root@rhel7-2 ~]# systemctl restart dirsrv.target

* Delete the entire entry:

[root@rhel7-2 ~]# ldapdelete -D 'cn=Directory Manager' -w Secret123 "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test"

* Search for CN:

[root@rhel7-2 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test" "objectclass=ldapsubentry"
No such object (32)
Matched DN: cn=accounts,dc=ipa1,dc=example,dc=test

* Re-add entry with specific order where costemplatedn is last:

[root@rhel7-2 ~]# ldapadd -D 'cn=Directory Manager' -w Secret123 <<EOF
> dn: cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test
> cn: Password Policy
> description: Password Policy based on group membership
> objectClass: top
> objectClass: ldapsubentry
> objectClass: cosSuperDefinition
> objectClass: cosClassicDefinition
> cosAttribute: krbPwdPolicyReference override
> cosSpecifier: memberOf
> cosTemplateDn: cn=cosTemplates,cn=accounts,dc=ipa1,dc=example,dc=test
> EOF
adding new entry "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test"

* Search for CN:

[root@rhel7-2 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w Secret123 -b "cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test" "objectclass=ldapsubentry"
dn: cn=Password Policy,cn=accounts,dc=ipa1,dc=example,dc=test
cn: Password Policy
description: Password Policy based on group membership
objectClass: top
objectClass: ldapsubentry
objectClass: cosSuperDefinition
objectClass: cosClassicDefinition
cosAttribute: krbPwdPolicyReference override
cosspecifier: memberOf
costemplatedn: cn=cosTemplates,cn=accounts,dc=ipa1,dc=example,dc=test

* Restart DS and check for hang:

[root@rhel7-2 ~]# systemctl restart dirsrv.target

* Check IPA status:

[root@rhel7-2 ~]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
ipa_memcached Service: RUNNING
httpd Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa: INFO: The ipactl command was successful
Comment 23 Ludek Smid 2014-06-13 10:53:26 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.