Description of problem: These critical issues with ISC BIND 9.2.4, that were fixed with 9.2.5, need backporting to the RHEL 9.2.4 release: --- 9.2.5 fixes backported to RHEL-4 BIND 9.2.4 --- 1808. [bug] zone.c:notify_zone() contained a race condition, zone->db could change underneath it. [RT #13511] 1800. [bug] Changes #1719 allowed a INSIST to be triggered. [RT #13428] 1789. [bug] Prerequisite test for tkey and dnssec could fail with "configure --with-libtool". 1784. [cleanup] "libtool -allow-undefined" is the default. Leave hooks in configure to allow it to be set if needed in the future. 1773. [bug] Fast retry on host / net unreachable. [RT #13153] 1772. [bug] Change #1740 needed more work in 9.2 as bit-labels are still supported. [RT #13015] 1771. [bug] Built-in zones did not have SOA or NS records. [RT #13015] 1770. [bug] named-checkconf failed to report missing a missing file clause for rbt{64} master/hint zones. [RT#13009] 1767. [port] Builds on IPv6 platforms without IPv6 Advanced API support for (struct in6_pktinfo) failed. [RT #13077] 1766. [bug] Update the master file timestamp on successful refresh as well as the journal's timestamp. [RT# 13062] 1764. [bug] dns_zone_replacedb failed to emit a error message if there was no SOA record in the replacment db. [RT #13016] 1760. [bug] Host / net unreachable was not penalising rtt estimates. [RT #12970] 1753. [bug] Don't serve a slave zone which has no NS records. [RT #12894] 1752. [port] Move isc_app_start() to after ns_os_daemonise() as some fork() implementations unblock the signals that are blocked by isc_app_start(). [RT #12810] 1750. [port] lib/bind/make/rules.in:subdirs was not bash friendly. [RT #12864] 1747. [bug] BIND 8 compatability: named/named-checkconf failed to parse "host-statistics-max" in named.conf. 1744. [bug] If tuple2msgname() failed to convert a tuple to a name a REQUIRE could be triggered. [RT #12796] 1743. [bug] If isc_taskmgr_create() was not able to create the requested number of worker threads then destruction of the manager would trigger an INSIST() failure. [RT #12790] 1742. [bug] Deleting all records at a node then adding a previously existing record, in a single UPDATE transaction, failed to leave / regenerate the associated SIG records. [RT #12788] 1741. [bug] Deleting all records at a node in a secure zone using a update-policy grant failed. [RT #12787] 1740. [bug] Replace rbt's hash algorithm as it performed badly with certain zones. [RT #12729] NOTE: a hash context now needs to be established via isc_hash_create() if the application was not already doing this. 1739. [bug] dns_rbt_deletetree() could incorrectly return ISC_R_QUOTA. [RT #12695] 1738. [bug] Enable overrun checking by default. [RT #12695] 1734. [cleanup] 'rndc-confgen -a -t' remove extra '/' in path. [RT #12588] 1733. [bug] Return non-zero exit status on initial load failure. [RT #12658] 1730. [port] Determine the length type used by the socket API. [RT #12581] 1725. [port] linux: update error message on interaction of threads, capabilities and setuid support (named -u). [RT #12541] 1723. [cleanup] Silence compiler warnings from t_tasks.c. [RT #12493] 1722. [bug] Don't commit the journal on malformed ixfr streams. [RT #12519] 1721. [bug] Error message from the journal processing were not always identifing the relevent journal. [RT #12519] 1720. [bug] 'dig +chase' did not terminate on a RFC 2308 Type 1 negative response. [RT #12506] 1719. [bug] named was not correctly caching a RFC 2308 Type 1 negative response. [RT #12506] 1718. [bug] nsupdate was not handling RFC 2308 Type 3 negative responses when looking for the zone / master server. [RT #12506] 1714. [bug] dig/host/nslookup were only trying the first address when a nameserver was specified by name. [RT #12286] 1713. [port] linux: extend capset failure message to say: please ensure that the capset kernel module is loaded. see insmod(8) --- 9.2.4 released --- Version-Release number of selected component (if applicable): bind-9.2.4-2_EL How reproducible: 100% Steps to Reproduce: Attempt reproduce any of the above issues Actual results: They can be reproduced Expected results: They should be fixed Additional info:
The fixes for the above issues have been backported and built into the bind-9.2.4-10_EL4 release.
In reply to comment #3, From Florian La Roche (laroche): > > This looks like a big list to backport. Any possibility to reduce the list > or check with QA if they would revision the bind server? (Sounds unlikely > to me, as this is one of our core packages.) > I carefully went through the complete list of ISC Bug fixes in ISC BIND 9.2.5 since 9.2.4 was released - there were 54 - and whittled this down to the 35 bugs listed above. I identified the patches for each bug, reviewed the code, and backported it to 9.2.4 . I have verified that the extensive test suite shipped with BIND-9 runs successfully on all platforms with these patches applied. All the code submitted for these bug fixes has been in FC-3's BIND-9.2.5 since Mar 11 2005 . No new features are implemented by this code - it fixes known 9.2.4 bugs only . The code has been tested by FC-3-4-5 users for 8 months. If upgrading to BIND 9.3.1 in RHEL-4 / RHEL-3, as I would recommend doing, and as has been requested by many customers, to obtain the new 9.3.1 features: o DNSSEC support ( 9.2.4 DNSSEC support is obsolete and broken ) o dual stack IPv4 / IPv6 support + selective disabling with '-4'/'-6' options o improved slave zone support : ixfr-from-differences, max-journal-size, masters clause o advertised EDNS UDP size can now be set, edns-udp-size o check-names is now implemented; rrset-order is more complete and for which I have built custom 9.3.1 releases for RHEL-3 and RHEL-4, available from my people page, after many customers tried building their own 9.3.1 bind packages and failed, and as requested by ISC, is not an option, then we must at least provide users the relevant fixes to existing 9.2.4 code. Just because customers have not raised BZs / Issue Trackers about the above issues until now does not mean they will not do so in the future if we leave these bugs in the RHEL BIND releases. There has to be some way whereby we can be proactive in resolving known issues before customers report them. Please can we add the appropriate ACKs to this bug, and to its RHEL-3 clone (Bug 170326) so we can avoid delivering known BIND bugs to RHEL customers.
(In reply to comment #4) > Need guidance on testing for these backported issues. Withholding QE ack until > we get some clarification on the testing scope. Currently there's nothing > listed in the advisory "how to test" section. The 'HOW TO TEST' section of errata RHBA-2005:764 and HBA-2005:804 are filled in with full details of how to test all the bugs fixed by the errata.
When considering whether to ACK/NACK this bug, please bear in mind: All the code submitted for these bug fixes o has been in FC-3's BIND-9.2.5 since Mar 11 2005 and all subsequent FC-4 / Rawhide releases, and has been tested by FC-3-4-5 users for 8 months. o No new features are implemented by this code - it fixes known 9.2.4 bugs only. o Has been developed and tested by upstream ISC BIND developers to fix known bugs, and has gone through their stringent community code review and testing processes. o The test suite shipped with BIND has been updated to test all the issues listed above, so it can be tested quite simply by running the BIND test suite as described in the errata HOW TO TEST.
(In reply to comment #9) > Excellent... could you help us by putting the test suite in RHTS? I'm planning to do so for Fedora releases, with a 'bind-test-*.rpm' . The BIND test suite is already run automatically by the older "test grid" system. The test suite, as mentioned in the previous comments, is part of the upstream BIND source release, and differs for each release to test new issues / as the BIND source differs . No part of it is shipped in the BIND binary distribution RPMs. At the moment, RHTS is based on separate test scripts outside the package source, so I cannot just copy the bind test suite from one source release into the RHTS CVS and expect it to work for every BIND source release . I'm planning to build a separate bind-test-*.rpm as part of each BIND build, and then I can submit RHTS test scripts to invoke it . But we'd need to ensure somehow that the bind-test-*.rpm was never included in the packages to be installed (by default, every subpackage built gets installed). And I don't want to make further changes to the RHEL BIND releases just to enable generation of the test RPM . With the Fedora bind.spec, you can run the test suite automatically by : # rpmbuild --define "test 1" ... -ba bind.spec Again I don't want to modify the RHEL bind.spec just to add this new feature, but I can do so if desired. To run the bind test suite for RHEL releases: 1. Build bind from the source rpm. With the bind-*.src.rpm in /tmp, as the 'root' user, from /tmp: # rpmbuild --define "_sourcedir /tmp" \ --define "_builddir /tmp" \ --define "_srcrpmdir /tmp" \ --define "_rpmdir /tmp" \ --target `uname -i` \ --rebuild bind-*.src.rpm # service named stop # cd bind-*/bin/tests # system/ifconfig.sh up # make test 2>&1 | tee test.log # echo $? # system/ifconfig.sh down # service named start The "make test" command should return with 0 exit status and this command: # grep '^R:' test.log | egrep -v 'PASS$' should print no output.
(In reply to comment #11) > You don't need to copy the tests into the RHTS subsystem. You can just have a > runtest.sh which invokes the tests that are in the installed package. > > Effectively, all you need to do is have the runtest.sh invoke the bindtest rpm. > If need be it could also retrieve them from an external source. > > So if the tests were able to be part of the old test Grid there is no reason > they couldn't be part of the RHTS. > Yes, but there are no tests in the installed bind package. They were part of the old test grid, because the RPM was built from source as part of the test, and thus the tests could be built and run. RHTS uses the existing installed binary RPMS, and thus has no access to the BIND test suite. I could make a RHTS test script which rebuilds BIND from source and runs the test suite - I'll investigate doing this. But the test script has to be run as root, and I've found problems if there is also a named daemon running on the host while the test suite is being run, so the test script would have to stop the named service on the RHTS host, probably not a good idea. The bind test suite builds >50 executables and has >100 PERL test scripts that are not part of the BIND distribution. I could easily update the RHEL bind RPMs to build a bind-test RPM, but this RPM should not be built by default, otherwise it will be shipped by default - if it's not built by default, you'd have to rebuild the bind RPM from scratch anyway to generate it. And I didn't want to update the RHEL bind.spec files just to create the tests - If you'd like me to do so, I can. I can append a shell script to the errata "HOW TO TEST" that will build the BIND src.rpm with testing enabled and run the test suite - this then can be submitted to RHTS - I'll do this early next week.
The impact of this is high enough to carry forward the request to the next Update. In addition there other requests for this component possibly justifying a QA slot. Moving to the next Update, clearing all ACKs.
This issue is on Red Hat Engineering's list of planned work items for the upcoming Red Hat Enterprise Linux 4.4 release. Engineering resources have been assigned and barring unforeseen circumstances, Red Hat intends to include this item in the 4.4 release.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0288.html