Bug 829387

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Please add steps to reproduce / verify all necessary scenarios

This bug covers a lot of small development tasks. Test should focus on doing changes in DB and look for following pattern in log:

"(psearch) failed"

This message indicates a bug, usually. 

Usual tests with zone/record addition/modification/deletion through IPA cli and DNS dynamic update should be enough.

When testing, there are messages in logs like:
Dec 18 08:59:09 qe-blade-01 named[15750]: update_record (psearch) failed, dn 'idnsname=allll,idnsname=newzone,cn=dns,dc=testrelm,dc=com' change type 0x4. Records can be outdated, run `rndc reload`: not found
Dec 18 08:59:22 qe-blade-01 named[15750]: update_record (psearch) failed, dn 'idnsname=aa2,idnsname=newzone,cn=dns,dc=testrelm,dc=com' change type 0x4. Records can be outdated, run `rndc reload`: not found
Dec 18 08:59:37 qe-blade-01 named[15750]: update_record (psearch) failed, dn 'idnsname=aaaa,idnsname=newzone,cn=dns,dc=testrelm,dc=com' change type 0x4. Records can be outdated, run `rndc reload`: not found
Dec 18 09:00:00 qe-blade-01 named[15750]: update_record (psearch) failed, dn 'idnsname=afsdb,idnsname=newzone,cn=dns,dc=testrelm,dc=com' change type 0x4. Records can be outdated, run `rndc reload`: not found
Dec 18 09:00:11 qe-blade-01 named[15750]: update_record (psearch) failed, dn 'idnsname=cname,idnsname=newzone,cn=dns,dc=testrelm,dc=com' change type 0x4. Records can be outdated, run `rndc reload`: not found
Dec 18 09:00:28 qe-blade-01 named[15750]: update_record (psearch) failed, dn 'idnsname=txt,idnsname=newzone,cn=dns,dc=testrelm,dc=com' change type 0x4. Records can be outdated, run `rndc reload`: not found
Dec 18 09:01:35 qe-blade-01 named[15750]: update_record (psearch) failed, dn 'idnsname=8,idnsname=4.4.4.in-addr.arpa.,cn=dns,dc=testrelm,dc=com' change type 0x4. Records can be outdated, run `rndc reload`: not found
Dec 18 09:01:47 qe-blade-01 named[15750]: update_record (psearch) failed, dn 'idnsname=naptr,idnsname=newzone,cn=dns,dc=testrelm,dc=com' change type 0x4. Records can be outdated, run `rndc reload`: not found
Dec 18 09:01:59 qe-blade-01 named[15750]: update_record (psearch) failed, dn 'idnsname=dname,idnsname=newzone,cn=dns,dc=testrelm,dc=com' change type 0x4. Records can be outdated, run `rndc reload`: not found
Dec 18 09:02:16 qe-blade-01 named[15750]: update_record (psearch) failed, dn 'idnsname=cert,idnsname=newzone,cn=dns,dc=testrelm,dc=com' change type 0x4. Records can be outdated, run `rndc reload`: not found


Is the above indicating a bug or should the steps to verify this bug be revised?

This message is harmless in some specific cases, it depends ...

Did you delete whole zone in one shot or something similar? I would like to see which IPA command caused this message.

The messages are showing up when deleting record, not a complete zone.

Steps taken:
Add a new zone:
# ipa dnszone-add --name-server=ipaqa64vma.testrelm.com. --admin-email=ipaqar.redhat.com --serial=2010010701 --refresh=303 --retry=101 --expire=1202 --minimum=33 --ttl=55 newzone
  Zone name: newzone
  Authoritative nameserver: ipaqa64vma.testrelm.com.
  Administrator e-mail address: ipaqar.redhat.com.
  SOA serial: 2010010702
  SOA refresh: 303
  SOA retry: 101
  SOA expire: 1202
  SOA minimum: 33
  SOA time to live: 55
  BIND update policy: grant TESTRELM.COM krb5-self * A; grant TESTRELM.COM krb5-self * AAAA; grant TESTRELM.COM krb5-self * SSHFP;
  Active zone: TRUE
  Dynamic update: FALSE
  Allow query: any;
  Allow transfer: none;


Add record type a 
# ipa dnsrecord-add newzone allll --a-rec 1.2.3.4
  Record name: allll
  A record: 1.2.3.4

Delete record type a 
# ipa dnsrecord-del newzone allll --a-rec 1.2.3.4
----------------------
Deleted record "allll"
----------------------

From this delete action, /var/log/messages has:
Jan  7 13:58:16 ipaqa64vma named[30416]: update_record (psearch) failed, dn 'idnsname=allll,idnsname=newzone,cn=dns,dc=testrelm,dc=com' change type 0x4. Records can be outdated, run `rndc reload`: not found

...and so on...as I go to next delete test:
# ipa dnsrecord-add newzone aa2 --a-rec 1.2.3.4,2.3.4.5
  Record name: aa2
  A record: 1.2.3.4, 2.3.4.5

# ipa dnsrecord-del newzone aa2 --a-rec 1.2.3.4,2.3.4.5
--------------------
Deleted record "aa2"
--------------------


From this delete action, /var/log/messages has:
Jan  7 13:58:21 ipaqa64vma named[30416]: update_record (psearch) failed, dn 'idnsname=aa2,idnsname=newzone,cn=dns,dc=testrelm,dc=com' change type 0x4. Records can be outdated, run `rndc reload`: not found

What is the timing of the commands?
Are you able to provide minimal working example which produces the error above?
Could you provide SSH access to the host?

Investigation results:
In this particular case is the message above harmless.

Command "ipa dnsrecord-del newzone allll --a-rec 1.2.3.4" causes IPA to delete attribute and the empty object in two separate steps. BIND receives Entry Change Notification about *change* and attempts to read new data from LDAP, but the whole object disappeared in a meanwhile (because it was deleted by IPA).

Optimizatin described in https://fedorahosted.org/bind-dyndb-ldap/ticket/41 should prevent this message from popping up.

marking verified. ran automated tests and checked /var/log/messages for "(psearch) failed". verified using ipa-server-3.0.0-19.el6.x86_64

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0359.html