Slashdot Mirror

← Back to Stories (view on slashdot.org)

RHN Bind Update Brings Down RHEL Named

Posted by kdawson on from the remind-me-of-your-name-again dept.

alexs writes "Red Hat's response to update bind through RHN, patching the DNS hole, made a fatal error which will revert all name servers to caching only servers. This meant that anyone running their own DNS service promptly lost all of their DNS records for which they were acting as primary or secondary name servers. Expect quite a few services provided by servers running RHEL to, errr, die until their system administrators can restore their named.conf. Instead of installing etc/named.conf to etc/named.rpmnew, Red Hat moved the current etc/named.conf to etc/named.conf.rpmsave and replaced etc/named.conf with the default caching only configuration. The fix is easy enough, but this is a schoolboy error which I am surprised Red Hat made. Unfortunately we were hit and our servers went down overnight while RHN dropped its bomb and I am frankly surprised there has not been more of an uproar about this."

3 of 312 comments (clear)

  1. applying patches without testing them? by BenLutgens · · Score: 0, Redundant

    So unless I miss my guess, these patches took down your production DNS servers. This leads me to believe you are applying patches blind, without testing them.

    Serves you right. Submit a bug report and quit whining.

    --
    "If you love someone, set them free. If they come home, set them on fire." - George Carlin
  2. Re:You are WRONG :D by mrbluze · · Score: 0, Redundant

    The real question is, how does crap like this get posted as a feature article on slashdot.

    And the obvious non-answer is "you must be new here".

    --
    Do it yourself, because no one else will do it yourself. [beta blockade 10-17 Feb]
  3. Suprised... by kenh · · Score: 1, Redundant

    I must say that I am very suprised that this patch acted one way in the posters test environment and another when it was installed on their production machine... That's very odd.

    What, he didn't test it before placing it in production? Never mind, move along - nothing to see here.

    If the poster made an error (as suggested by a previous post), or if he installed a patch without testing it, bad on the original poster - but if the patch truely was bad (a possibility), then bad on RHN for letting something bad out of QA and into production. But RHN's possible mistake doesn't absolve the system admin for not testing the patch before using it.

    The only way this isn't the original poster's error is if the patch worked different in production than in test, but no one is claiming that AFAIK.

    No matter what you pay for support to RHN, you are ultimately responsible for your systems, not RHN or any other vendor...

    --
    Ken