RHN Bind Update Brings Down RHEL Named 312
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."
TCO (Score:1, Interesting)
No worries (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.
You are WRONG :D (Score:5, Interesting)
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.
Common Red Hat Mistake (Score:3, 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.
Re:Common Red Hat Mistake (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.
Configuration management (Score:3, Interesting)
Have you considered using a configuration management tool such as Bcfg2 [bcfg2.org] or cfengine to make sure your own config files are restored after package updates are made? You can never really trust those package maintainers...
Re:What kind of an idiot would...? (Score:4, 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]
On Blindly Updating - OS X Server 10.3.x (Score:3, 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 [apple.com]
Re:You didn't test before deploying an update? (Score:3, Interesting)
Can the same line be used to defend Microsoft the next time they screw up a bug-fix or "service pack"?
Oh so LATE (Score:3, Interesting)
Thanks ./, ive known about this for TWO WEEKS.
And no one died.
So there.