Slashdot Mirror


RHN Bind Update Brings Down RHEL Named

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."

10 of 312 comments (clear)

  1. TCO by toxygen01 · · Score: 1, Interesting

    I wonder if this is included in Total Cost of Ownership. i.e. I'm really interested in estimates how big loss this mistake generated to big companies.

  2. No worries by FlyingBishop · · Score: 2, Interesting

    I don't need to worry about that, I run Debian

    Also, I don't run my own DNS. But if I were paying someone to make sure my patches weren't idiotic, I'd be pretty pissed, whether the patch was for something I used or not.

  3. You are WRONG :D by hughesjr · · Score: 5, Interesting

    This article is absolutely wrong.

    The user has misconfigured their DNS and has installed a package called, SURPRISE, caching-nameserver along with the other bind packages.

    caching-nameserver IS just that, a caching-nameserver. It SHOULD NEVER BE installed on a DNS server that is used for Primary or Secondary DNS control. The bind packages do not in any way modify named.conf, but if you want a caching nameserver and if you have installed the caching-nameserver package, then you would EXPECT that it would replace the named.conf file.

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

  4. Common Red Hat Mistake by Spazmania · · Score: 2, Interesting

    Red Hat makes this mistake a LOT. It makes the update process very unreliable. SuSE isn't as bad but they still have problems if you customize a piece of software's configuration in an unexpected way.

    Debian is king here. The incremental patches almost never break a configuration and the major release upgrades tend to work; they often change package names if the new "version" has a major incompatible change in the configuration.

    --
    Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
    1. Re:Common Red Hat Mistake by Anonymous Coward · · Score: 1, Interesting

      Give me a break. He has caching-nameserver installed which is supposed to do that. This is user error, pure and simple. It's time for them to hire an RHCE.

  5. Configuration management by cluening · · Score: 2, Interesting

    Have you considered using a configuration management tool such as Bcfg2 or cfengine to make sure your own config files are restored after package updates are made? You can never really trust those package maintainers...

    --
    Posted from the wireless couch.
  6. Re:What kind of an idiot would...? by ThePhilips · · Score: 3, Interesting

    On most (all?) other distros it works perfectly. I had Debian for ages in production (supporting piles of services) with apt-get update/upgrade running regularly. SuSE and Gentoo also do good job keeping you informed about changes in updates and if post-update human interaction is needed.

    The crucial difference here is mindset of RH. It didn't changed the damm yota in the decade. The very same problem why I threw away RH6/7 in past from production, the very same stupidity of RH, is still there.

    RH is only distro I have ever tried - and I tried many of them - would silently without any warning or prompt replace your config files with shipped version. It took them ages to learn that files can be renamed - yet it didn't went thru completely it seems.

    This is not a single mistake. This is happening now for more than a decade now: RH during maintenance can and does override your configuration. The RH folks simply have no trivial respect to their users...

    [/rants]

    --
    All hope abandon ye who enter here.
  7. On Blindly Updating - OS X Server 10.3.x by not_hylas(+) · · Score: 2, Interesting

    GUILTY.
    Seems the person that prepared the patch is a new hire at Red Hat.

    Beware Latest 10.3.x security update - it replaces /etc/named.conf:

    http://discussions.apple.com/message.jspa?messageID=5876624

    --
    ~hylas
  8. Re:You didn't test before deploying an update? by mi · · Score: 2, Interesting

    The only "schoolboy error" [...] was not testing the patch on a non-production server before deploying it on a production

    Can the same line be used to defend Microsoft the next time they screw up a bug-fix or "service pack"?

    --
    In Soviet Washington the swamp drains you.
  9. Oh so LATE by alexborges · · Score: 2, Interesting

    Thanks ./, ive known about this for TWO WEEKS.

    And no one died.

    So there.

    --
    NO SIG