Bug 1259923 - if a policy zone updated during regular operation, then RPZ summary data to fall out of sync
if a policy zone updated during regular operation, then RPZ summary data to f...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: bind (Show other bugs)
6.8
All Linux
medium Severity high
: rc
: ---
Assigned To: Petr Menšík
Petr Sklenar
: OtherQA, Patch
Depends On:
Blocks: 1269194 1254457 1359261
  Show dependency treegraph
 
Reported: 2015-09-03 15:43 EDT by Sameer Jadhav
Modified: 2017-03-21 06:06 EDT (History)
4 users (show)

See Also:
Fixed In Version: bind-9.8.2-0.55.rc1.el6
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-03-21 06:06:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
baskported relevant part of the upstream fix (2.36 KB, patch)
2016-03-03 06:59 EST, Tomáš Hozza
no flags Details | Diff

  None (edit)
Comment 2 Tomáš Hozza 2015-10-05 08:15:28 EDT
Hi.

Please provide reproducer so engineering and QE can verify the fix.

Thank you!
Comment 3 Tomáš Hozza 2015-10-06 11:17:46 EDT
Hi.

Based on the information provided in ticket I tried this:

1. generated sample RPZ zone with 3 millions of records using simple script:
https://gitlab.com/thozza/random-scripts/blob/master/gen_rpz_zone.py


scenario 1:
- configured server (A) as master with one RPZ zones each 3m records.
- configured sserver (B) with RPZ zone which was slave and transfered from the server (A).
- I was querying server (B) with random queries while:
 - I removed all entries but SOA from the RPZ zone file on server (A)
 - The server (B) transfered the zone using AXFR
 - I changed the RPZ zone on server (A) back to 3m records.
 - The server (B) transfered the zone using AXFR

The querying server (B) never locked up and the query resolution never took more than 1 second


scenario 2:
Same as scenario 1 but with two RPZ zones.


I can try to blindly map the changes from upstream to the RHEL-6 code, but having the reproducer is needed to verify that the issue is fixed.

Thanks.
Comment 4 Tomáš Hozza 2015-10-09 04:15:22 EDT
I went through the patch you requested as the one that should fix the issue. 

First part of the patch (patching rbtdb.c) is applicable to the RHEL-6 version of BIND. Based on my understanding this is preventing the possible inconsistencies when zone is updated and addition/deletion of a node fails.

However the second part of the patch (patching rpz.{c,h}) is changing code that is not even present in el6 version of BIND, therefore it can not affect the behavior.

Without a reproducer I can not proceed with the work on possible fix.

Please provide step-by-step reproducer and also backtrace from all threads when bind is in "locked" state (attach to bind while running using 'gdb -p <pid>' and then run 'thread apply all bt'. Don't forget to install the debuginfo packages before doing this, otherwise the backtrace will be worthless.).

Setting Devel Cond NAK 'Reproducer' and 'Patch' for now.
Comment 11 Tomáš Hozza 2016-03-03 06:59 EST
Created attachment 1132733 [details]
baskported relevant part of the upstream fix
Comment 27 errata-xmlrpc 2017-03-21 06:06:13 EDT
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.

https://rhn.redhat.com/errata/RHBA-2017-0651.html

Note You need to log in before you can comment on or make changes to this bug.