Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

RHN Bind Update Brings Down RHEL Named

kdawson posted more than 6 years ago | from the remind-me-of-your-name-again dept.

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

cancel ×

312 comments

Sorry! There are no comments related to the filter you selected.

You didn't test before deploying an update? (5, Insightful)

Anonymous Coward | more than 6 years ago | (#24240283)

So, you didn't test the update on a non-production server? Just install any old patch and let it take your network down? Who do you work for again? I have to make sure not to do business with that.

Re:You didn't test before deploying an update? (0)

Anonymous Coward | more than 6 years ago | (#24240517)

So, you didn't test the update on a non-production server?...Who do you work for again?

Possibly /., to judge by the non-command of editing on display in the writeup.
I kinda think I know what it's saying. Then again, ambiguity begets problems begets business opportunities, so maybe the lack of clarity is more feature than bug in the long run.

Re:You didn't test before deploying an update? (5, Insightful)

suso (153703) | more than 6 years ago | (#24240753)

Actually, I caught the error just from looking at the output of up2date/yum. It clearly said named.conf saved to named.conf.rpmsave. So all you have to do is compare what changed, implement any changes and copy named.conf.rpmsave over named.conf.

  Just as I said on the day of the release, be careful, don't just blindly update things.

Re:You didn't test before deploying an update? (0)

Anonymous Coward | more than 6 years ago | (#24240771)

yeah dumb***.

sysadmin 101 Day 1: No unattended updates. Test the updates.

You weren't hit, you were dumber than the person who made a mistake w/ the package.

Re:You didn't test before deploying an update? (0)

Anonymous Coward | more than 6 years ago | (#24240779)

True, but the point of the article is that this shouldn't have happened. What if they really didn't have a test server and their boss heard about it and urgently asked them to patch? There's plenty of managers out there trying to teach you how to do your job and who don't bother to pay a bit extra for a test server, even after the production server goes down because of similar mistakes.

Re:You didn't test before deploying an update? (0)

Anonymous Coward | more than 6 years ago | (#24241011)

Sysadmin 101 Day 1: No unattended updates. Make sure and test your updates.

Re:You didn't test before deploying an update? (3, Insightful)

illumin8 (148082) | more than 6 years ago | (#24241067)

So, you didn't test the update on a non-production server? Just install any old patch and let it take your network down? Who do you work for again? I have to make sure not to do business with that.

No kidding. The only "schoolboy error" as the submitter put it, was not testing the patch on a non-production server before deploying it on a production DNS server.

A schoolboy error? (4, Insightful)

something_wicked_thi (918168) | more than 6 years ago | (#24240285)

What? And isn't it an error of similar proportion to upgrade your primary DNS servers without first testing the new install?

Re:A schoolboy error? (4, Informative)

imipak (254310) | more than 6 years ago | (#24240499)

Note as well that the initial release included a default conf file which specified a fixed source port, which of course breaks the fix.

[Updated 10th July 2008] We have updated the Enterprise Linux 5 packages in this advisory. The default and sample caching-nameserver configuration files have been updated so that they do not specify a fixed query-source port. Administrators wishing to take advantage of randomized UDP source ports should check their configuration file to ensure they have not specified fixed query-source ports.

Personally I'm surprised there's not been more uproar about the requirement to move internal DNS servers (yes, that means your Windows Domain Controllers in most corporate environments) outside any NAT'ing devices (eg: firewalls), as many NATs also break the fix by rewriting outbound UDP DNS queries to use the same or incremental source ports, which also breaks the fixes. Anyone here moved their AD outside the firewall?

Mod parent up! (3, Insightful)

Chrisq (894406) | more than 6 years ago | (#24240783)

I am sure that many people do not realise that going through a NAT device usually means that predictable port numbers will be allocated.

Of course until we get details of the hole and fix we cannot be 100% sure but it is very likely that exposing predictable port numbers (which the fix randomised) reintroduces the hole.

If DNS software vendors had a year's notice then why didn't the NAT firewall vendors. They could have introduced a patch at the same time.

Re:Mod parent up! (1)

afidel (530433) | more than 6 years ago | (#24241049)

Apparently [checkpoint.com] they did, either that or Checkpoint's protection feature for the general class of DNS poisoning attacks just happened to protect against this one too. However, even if it did protect against it I doubt they could have release a same day press release stating it did if they hadn't been notified of the vulnerability ahead of time.

Re:Mod parent up! (2, Informative)

something_wicked_thi (918168) | more than 6 years ago | (#24241071)

Judging by the CERN details, it sounds like there are two things you need to do. You need to be able to predict the 16-bit random number, and the 16-bit random port. My reading (and this was very brief, so someone *please* correct me if I'm wrong here) is that the older DNS servers had two flaws: a flaw in the RNG for the 16-bit transaction number, and they used fixed or predictable ports.

A NAT will reintroduce only the second problem because it gives you predictable ports, but obviously, relying solely on the unpredictability of a 16-bit transaction id is a little scary. Because of the birthday paradox, (assuming the attacker has perfect knowledge about which port you're choosing) an attacker would need to send only something on the order of 2^8 packets to poison the cache.

Re:A schoolboy error? (1, Insightful)

evilviper (135110) | more than 6 years ago | (#24240845)

Personally I'm surprised there's not been more uproar about the requirement to move internal DNS servers (yes, that means your Windows Domain Controllers in most corporate environments) outside any NAT'ing devices (eg: firewalls),

NAT is not a firewall.
A firewall is not NAT.

I wouldn't think that practically any major sites are running their public-facing DNS servers from behind a NAT (though I expect most are behind a firewall).

Re:A schoolboy error? (1)

db32 (862117) | more than 6 years ago | (#24240997)

Personally I'm surprised that this is getting modded Informative. I suppose the NAT piece is informative, but I think "Anyone here moved their AD outside the firewall?" qualifies as either -1 Job or +5 Funny.

Re:A schoolboy error? (3, Informative)

igb (28052) | more than 6 years ago | (#24241185)

Hand off DNS queries emerging from AD servers inside your firewall to caching-only servers in your DMZ. I have all my AD servers on RFC1918 IP numbers with no NAT, because they strike me as devices I'd prefer to keep as far away from the big bad Internet as possible.

ian

Re:A schoolboy error? (0, Offtopic)

geekymachoman (1261484) | more than 6 years ago | (#24240543)

IMHO, rhel should have tested this. If they announce offical new version of some app, and it turns out to brake stuff, then that's theirs fault. Maybe admins should stop being lazy, and start installing 'network' services which are crucial server components, by hand, from source, which gives them more flexibility and control then rpm -i.. No ? Ok then, chrooting ? I chroot my bind's, so, if I update, the rpm package can only mess up files like /etc/named.conf which I don't use, since all of config files are in /chroot/named/ and redhat isnt aware of that. Binary file has a switch to start from chroot... you edit /etc/sysconfig/bind or something like that, and do /etc/init.d/named start - Thats it. If you can easyli chroot some service (like named), then do it. You can only gain something from it.

Re:A schoolboy error? (3, Insightful)

something_wicked_thi (918168) | more than 6 years ago | (#24240675)

IMHO, rhel should have tested this.

'Course they should. Nobody said otherwise.

I'm not sure what you're getting at with building from sources. Seems like overkill and doesn't solve the main problem because you can still screw it up. All anyone's saying is that you should test this on a server that you don't care about, or at least test it on one, before upgrading all of them.

MS (4, Insightful)

FozE_Bear (1093167) | more than 6 years ago | (#24240297)

If it was a Microsoft product, we'd all be carrying pitchforks and torches....

Re:MS (1)

sleekware (1109351) | more than 6 years ago | (#24240351)

Unless you are one of the slaves who is forced to use Microsoft, and therefore your protest abilities are rather slim to none.

Re:MS (1, Insightful)

Anonymous Coward | more than 6 years ago | (#24240485)

But nobody is using RH in production anyway.

Re:MS (0)

GNUALMAFUERTE (697061) | more than 6 years ago | (#24240571)

Well, one thing is for sure: nobody should.

Long live Slackware! ( And long live old-school sysadmins that compile their own software )

We have proved to be right, once again.

Re:MS (0)

Anonymous Coward | more than 6 years ago | (#24240529)

Yes... because businesses use Microsoft products. There's only one person complaining since nobody uses RHEL.

Re:MS (0, Troll)

Minwee (522556) | more than 6 years ago | (#24240623)

If it was a Microsoft product, we'd all be carrying pitchforks and torches....

If it was a Microsoft product, we'd still be waiting for the patch.

Re:MS (4, Informative)

prandal (87280) | more than 6 years ago | (#24240729)

MS08-037 was released on the same day, and was much loved by ZoneAlarm users :-)

Re:MS (0)

Anonymous Coward | more than 6 years ago | (#24241055)

Other security products worked just fine with that update. Zonealarm is a piece of shit.

Re:MS (1)

altamira (639298) | more than 6 years ago | (#24240733)

Ehm, no. The patch for this precise issue has been released by MS on July 8 (953230 MS08-037), more than a week ago.

Re:MS (-1)

Anonymous Coward | more than 6 years ago | (#24240861)

/poster/sbin/sarcasmd --on

Thats unpossible, evree buddy nos that klosed sorse software releases updates aftur open sorse software! /poster/sbin/sarcasmd --off

Re:MS (1)

hughesjr (734512) | more than 6 years ago | (#24240671)

sure, if it was really a bug ... in this case, it is totally user error and the installing of a package called caching-nameserver.

Re:MS (1)

Eighty7 (1130057) | more than 6 years ago | (#24241039)

If it was a Microsoft product, we'd all be carrying pitchforks and torches....

To put this in /. terms, Red Hat's got good karma. Contributing to the community for over a decade kinda does that.

Re:MS (-1)

Anonymous Coward | more than 6 years ago | (#24241195)

Brilliant point. Interesting how all the smart-ass Slashdotters contract their critical abilities and pull out the typical linux-has-no-bugs-provided-you-hire-100000-security-analysts-to-find-and-patch-its-holes-for-you-first excuses just as a critical mistake hits a popular Linux distribution. Hypocrisy!

What kind of an idiot would...? (0)

Anonymous Coward | more than 6 years ago | (#24240299)

What kind of an idiot would do something like that? You'd think they're running RHEL or something.

Re:What kind of an idiot would...? (3, Interesting)

ThePhilips (752041) | more than 6 years ago | (#24240741)

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]

But, you plan on making one! (0, Offtopic)

C_Kode (102755) | more than 6 years ago | (#24240303)

I am frankly surprised there has not been more of an uproar about this. ...but you plan on making one! OOH-RA!

Re:But, you plan on making one! (-1, Redundant)

Outdoor83 (1081759) | more than 6 years ago | (#24240383)

There's been no uproar because no one uses RHEL anymore.

Re:But, you plan on making one! (1)

MikeDawg (721537) | more than 6 years ago | (#24240495)

If you don't check out how neat the RHN satellite server, or the new spacewalk server is, you're really missing out. It is really nice in the enterprise environment.

New update? (1)

KasperMeerts (1305097) | more than 6 years ago | (#24240311)

Why do we have to fix this ourselves. Can't RHT just issue a new update fixing it?
Also, don't they test their updates?

Re:New update? (2, Insightful)

CrackerJackz (152930) | more than 6 years ago | (#24240509)

Because the named.conf file gets stomped, the 'backup' RPMSAVE file it creates is the caching-only file, not the original named.conf file.

I caught this a couple of weeks ago on a test server (where *all* patches should be tested first, Microsoft or otherwise) best way to fix? cp /etc/named.conf /root/named.conf.backup ; up2date-nox -u ; cp /root/named.conf.backup /etc/named.conf ; /etc/init.d/named restart

Little to no downtime on the prod servers :)

Re:New update? (3, Funny)

Anonymous Coward | more than 6 years ago | (#24240607)

Yes, as an official red hat representative, I can say that we can. All you need to do at this time is respond posting your server addresses and login credentials. We will fix it from there.

Re:New update? (5, Funny)

I cant believe its n (1103137) | more than 6 years ago | (#24240743)

Yes, as an official red hat representative, I can say that we can. All you need to do at this time is respond posting your server addresses and login credentials. We will fix it from there.

Ok, the login name is root and I use the default password: password for all our production machines.
Oh, I almost forgot. Our IP is 207.46.19.254

Please let our CEO know that I was the one who gave you this information.

They are all busy ... (1)

PolygamousRanchKid (1290638) | more than 6 years ago | (#24240329)

I am frankly surprised there has not been more of an uproar about this.

... maybe they are all still busy fixing their servers, and don't have time to post now?

Re:They are all busy ... (0)

Anonymous Coward | more than 6 years ago | (#24240359)

unknown host slashdot.org

applying patches without testing them? (0, Redundant)

BenLutgens (56508) | more than 6 years ago | (#24240339)

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.

Re:applying patches without testing them? (1)

sleekware (1109351) | more than 6 years ago | (#24240393)

Guess he didn't have a lab (or decided not to use it). I've been guilty of that before... :P

what, it's not tagged with "haha" (0)

Anonymous Coward | more than 6 years ago | (#24240345)

Linux fanbois strike again

TCO (2, Interesting)

toxygen01 (901511) | more than 6 years ago | (#24240347)

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.

Re:TCO (1)

msuarezalvarez (667058) | more than 6 years ago | (#24240399)

The accountants doing the computation just called and they need a little more time before they have a good estimate on the cost of this: they are waiting for their computers to finish defragmenting their disks and for their antivirus apps to scan every word file for vba worms.

bug details (5, Informative)

tommis (1328303) | more than 6 years ago | (#24240353)

Here's the bug details: https://bugzilla.redhat.com/show_bug.cgi?id=453340 [redhat.com]

One of the bug comments says: "Latest caching-nameserver renamed my named.conf to named.conf.rpmsave in /var/named/chroot/etc" - so this should mean that you can still restore the lost conf file.

Re:bug details (2, Informative)

Chris Mattern (191822) | more than 6 years ago | (#24240457)

In other words, as somebody else posted, he installed the "caching-nameserver" package and got, surprise, a caching nameserver. Shocking.

Re:bug details (5, Informative)

hughesjr (734512) | more than 6 years ago | (#24240641)

it is not a bug to get a caching nameserver if you install caching-namesever ... it would be a bug to install caching-nameserver and NOT GET a caching nameserver.
A caching name server IS one that does not have any zones and only looks up zones from the DNS root servers. It is a configuration error to install the caching-nameserver package on a machine that doing anything other being a caching name server.
Stupid admins have been complaining about this for 5 years ... but the documentation and bug entries all make it clear NOT to install the caching-namesever packages on DNS servers that control zones.

Parent should be modded up (2, Informative)

dstech (807139) | more than 6 years ago | (#24240909)

I wish I had mod points with which to mod you up. This is NOT a bug, and a few RHEL test machines I have here updated just fine, keeping their zone files as expected.

Um... (4, Funny)

wellingtonsteve (892855) | more than 6 years ago | (#24240355)

"I am frankly surprised there has not been more of an uproar about this"

That's because the entire Internets are now broken!

Re:Um... (1)

I cant believe its n (1103137) | more than 6 years ago | (#24240785)

You mean my internet

:3.

argh (2, Insightful)

Fackamato (913248) | more than 6 years ago | (#24240365)

I guess the syadmins could put in an option in a configuration file somewhere on what files to "keep untouched" when doing package upgrades, no? So that the configuration file wouldn't be overwritten. I think I've seen something similar in Debian distros. Anyway when I install a new (custom) kernel in Ubuntu for example, synaptic asks me if I want to overwrite GRUB's menu.lst with the newly generated one, view the differences or keep my old one etc. Surely there's something similar in Redhat?

That why they get paid (3, Insightful)

nicolas.kassis (875270) | more than 6 years ago | (#24240367)

Half of whole point of a subscription to RHEL is to ensure that patches they put out are properly QAed. The other side is support, but I never had a chance to test that part out.

Re:That why they get paid (2, Insightful)

MikeDawg (721537) | more than 6 years ago | (#24240423)

Umm. . . I disagree completely. The only way I would consider a patch "put out properly" if it was tested in my exact, or near exact environment. I can only assume that I'm not important enough for that.

No worries (2, Interesting)

FlyingBishop (1293238) | more than 6 years ago | (#24240377)

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.

Re:No worries (0, Troll)

ettlz (639203) | more than 6 years ago | (#24240637)

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

Ah, well then, you just keep on rolling them dice, OK?

Re:No worries (2, Insightful)

larry bagina (561269) | more than 6 years ago | (#24240649)

Idiotic.... like Debian's openssl "enhancements" that made the random number generator not so random?

Re:No worries (0)

Anonymous Coward | more than 6 years ago | (#24240903)

Idiotic.... like Debian's openssl "enhancements" that made the random number generator not so random?

He didn't say that Debian was flawless. Just that it didn't have this specific flaw and that when this kind of flaws happen, people should be mad. He also didn't say that he wasn't mad when Debian had it's bug.

(note that I don't comment on if this is a bug to be mad about as I don't know the subject. /. consensus seems to be this was user error...)

What about Debian's OpenSSL bug (2)

dfcamara (1268174) | more than 6 years ago | (#24240935)

Recent Debian's OpenSSL bug was orders of magnitude worse...

You are WRONG :D (5, Interesting)

hughesjr (734512) | more than 6 years ago | (#24240385)

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.

Re:You are WRONG :D (0, Redundant)

mrbluze (1034940) | more than 6 years ago | (#24240415)

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

Re:You are WRONG :D (1)

MicktheMech (697533) | more than 6 years ago | (#24240481)

/. QA is worse than the poster's?

Re:You are WRONG :D (1)

Stevious (73794) | more than 6 years ago | (#24240557)

Sounds like user error to me. I applied the recent update to BIND and still have the same named.conf I had before the update on both my primary and backup machines.

Re:You are WRONG :D (1)

Kamokazi (1080091) | more than 6 years ago | (#24240583)

There is a reason a lot of articles used to get tagged 'kdawsonfud'

Re:You are WRONG :D (0)

Anonymous Coward | more than 6 years ago | (#24240711)

I've installed the patches on a number of RHEL systems and had no such problems.

This post, especially the title, is misiniformation.

Re:You are WRONG :D (1)

vegiVamp (518171) | more than 6 years ago | (#24240751)

Point, but even then, it's still a config file, which should never ever ever be touched by a package update if it's been user-modified.

Re:You are WRONG :D (1, Insightful)

hughesjr (734512) | more than 6 years ago | (#24240995)

BUT ... how can you create a caching-nameserver without changing that file???
If you do not change that file, you do NOT have a caching-namesever ... which was the whole point of installing that package.

Re:You are WRONG :D (1)

vegiVamp (518171) | more than 6 years ago | (#24241097)

Packages should never even touch configfiles without asking for permission in triplicate.

I'm not familiar with the package in question, but I assume it also installed some binaries. If it found that there already was a configfile of that name, it should have asked what to do.

If setting up the caching-nameserver was a matter of changing config options, you don't need a package for that, you need a HOWTO.

Re:You are WRONG :D (0)

Anonymous Coward | more than 6 years ago | (#24240973)

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

Because suckers like us keep reading and commenting regardless. Slashdot can continue to post whatever crap they like with impunity because they know that the value of their site comes from the comments.

Slashdot is never going to improve.

Re:You are WRONG :D (0)

Anonymous Coward | more than 6 years ago | (#24241103)

We can improve the comments.

Test your patches (2, Insightful)

MikeDawg (721537) | more than 6 years ago | (#24240395)

What kind of environment are you in where you don't first test your patches that are going out to live production machines? Regardless of the fact that it is linux and not windows, you should always test your patches before you roll them production.

Re:Test your patches (0)

mrbluze (1034940) | more than 6 years ago | (#24240429)

...you should always test your patches before you roll them production.

But that would cost time and money.

Re:Test your patches (1)

MikeDawg (721537) | more than 6 years ago | (#24240447)

. . . and DNS servers not responding doesn't?

Re:Test your patches (1)

mrbluze (1034940) | more than 6 years ago | (#24240491)

. . . and DNS servers not responding doesn't?

That was my point (with sarcasm quotes missing)

Re:Test your patches (1)

jeiler (1106393) | more than 6 years ago | (#24240489)

Not to mention that it would involve actually doing things correctly.

Old News (1)

lib3rtarian (1050840) | more than 6 years ago | (#24240397)

This update was released via RHN more than two weeks ago.

Red Hat's been kind of iffy lately (2, Informative)

propanol (1223344) | more than 6 years ago | (#24240401)

A few months prior to the release of RHEL 5.2, they released a kernel update (2.6.18-53.1.6.el5) in which they had added a patch for an issue that could make a system oops upon when files with names of a certain character were present on NFS shares. However, this patch also contained a bug which broke NFS lookup caching and subsequently crippled NFS performance to the point of NFS being completely unusable when working with multiple smaller files. They released a patch for it, but it would only apply cleanly to their testing kernel (which would later become the kernel shipped with 5.2) and they refused to backport it to their then-stable kernel. Shortly after, the vmsplice flaw was found forcing people to update and bring this bug upon them. For us it wasn't that big a problem since we're using CentOS and don't have anything requiring us to use standard RHEL packages (so we backported the patch and built our own kernel package), but a large amount of corporate RHEL users are required to use only standard RHEL system packages because of service contracts with hardware vendors and hence they could do little to remedy this bug. As we were among the first to report this and post about it on mailing lists, we received a lot of communication from corporate RHEL users/sysadmins asking us for help on this, further proving that this was a major issue that should have been addressed right away and not post-poned to the next major release.

Experienced Monkeys... (2, Insightful)

spankymm (1327643) | more than 6 years ago | (#24240405)

...check for rpm mouse droppings by running find.

RH may have made a small coding mistake - you made an even bigger one.

caching-nameserver (1)

novadragoon (746815) | more than 6 years ago | (#24240421)

Did the OP have the package caching-nameserver installed? If so, that packages whole point is to change the bind configuration into doing just caching.

A true BOFH excuse (1)

necromcr (836137) | more than 6 years ago | (#24240437)

I'm writing it down as you read this!

Common Red Hat Mistake (2, Interesting)

Spazmania (174582) | more than 6 years ago | (#24240445)

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 (1)

houghi (78078) | more than 6 years ago | (#24240573)

openSUSE has warnings in those files NOT to use them and tell you which one you need to use. e.g. for Apaches http.conf it says:
# If possible, avoid changes to this file.
It then goes on to exlain a lot about what to place where.

There are many other files like that. Another example:
# PLEASE DO NOT CHANGE /etc/bash.bashrc There are chances that your changes
# will be lost during system upgrades. Instead use /etc/bash.bashrc.local
# for your local settings, favourite global aliases, VISUAL and EDITOR
# variables, etc ...

So if you decide to not read what is in those files and just change them and then do an upgrade, don't be surprised if the system works as intended.

I like also how you use 'almost never', 'tend to work' and 'often'.

Don't like the OpenSUSE way (0)

Anonymous Coward | more than 6 years ago | (#24240755)

I've been using SuSE for ages but I never quite liked its way of shoo-shooing me away from config files (like XF86config, which I had to edit to get my video card to work).

Some time ago I got so fed up with Flash constantly crashing Firefox I renamed the plugin file. So now OpenSUSE is constantly bickering about 5 new updates but refuses to install them because it's gotten confused about the missing .so file.

It's fine to have graphical config utilities but they should be smart enough to cope with manual editing. If that's not possible, how about just sticking with manual editing.

Re:Common Red Hat Mistake (0)

Anonymous Coward | more than 6 years ago | (#24240595)

Negative claims without any examples for proofs is just trolling.

Re:Common Red Hat Mistake (1, Interesting)

Anonymous Coward | more than 6 years ago | (#24240645)

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.

Nope. (1)

juiceg (700027) | more than 6 years ago | (#24240511)

[root@struct etc]# rpm -q bind
bind-9.3.4-6.0.2.P1.el5_2

[root@struct etc]# grep zone named.conf | wc -l
49

Freshly updated and restarted the service. Still have all my zones. Sounds like someone didn't do too well on the RHCE?

Well (3, Insightful)

ledow (319597) | more than 6 years ago | (#24240569)

Yeah, it's a silly mistake.

But you should be testing things like this first, and whenever you upgrade you should really be looking at/for all .rpmsave or equivalent files first to make sure nothing has changed in the meantime. Otherwise, you're just removing your config and replacing it with the default whatever happens. You should also be checking .rpmnew (or equivalent) each time to check that it hasn't changed in terms of syntax, defaults etc. (which, let's be honest, is quite likely for such an important update - especially given that we hardly know what the exact problem is yet). I wouldn't go so far as to suggest intimate analysis of packages while they are still packed unless the systems you are running are quite critical to the operation of a business.

Part human-error on RH's part (it happens). Part incompetence in not testing the updates yourself first. Chances are that if I were affected by this, I would catch it as part of "right, what did that package change?", or notice as part of usual testing later, and then just move the file. I probably wouldn't even bother to send RH a note.

If you have a DNS server, that suggests that there are reliant computers. As courtesy to all those reliant computers you HAVE to test changes and check carefully what they are doing first. If you were "stung" by it, it suggests you hit this problem on ALL your DNS servers and/or that you only have one DNS server anyway. To deploy packages like this on such a setup is just asking for trouble.

Don't forget! (4, Informative)

prandal (87280) | more than 6 years ago | (#24240579)

Don't forget to check your named.conf on RHEL 5.x (and CentOS 5.x).

Make sure that any lines like

query-source port 53;
query-source-v6 port 53;

are commented out or deleted so that forwarded DNS queries come from random ports.

Restart BIND if necessary.

caching-nameserver vs. bind-chroot (1)

uberlinuxguy (586546) | more than 6 years ago | (#24240605)

The file I actually had replaced was

/var/named/chroot/etc/named.conf

That file is not owned by caching-nameserver, but is owned by the bind-chroot package.

Re:caching-nameserver vs. bind-chroot (1)

hughesjr (734512) | more than 6 years ago | (#24240943)

I just pulled up the SRPM and looked, and bind-chroot has:
%ghost %config(noreplace) %prefix/etc/named.conf
%ghost %config(noreplace) %prefix/etc/named.caching-nameserver.conf
%ghost %config(noreplace) %prefix/etc/rndc.key
It should not replace that file with an .rpmsave file

Can't say I miss this kind of problem. (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#24240619)

This is one of the reasons I use Gentoo: the etc-update utility. I can see what changed in /etc and perform merges and edits as needed. Also, portage tells me if something in /etc needs updating after a package update.

It's annoying to see Gentoo criticized because of the my-CFLAGS-are-better-than-yours idiots and the internal politics. Gentoo has a lot of stuff that I wish other distros picked up, like its replacement for init that puts dependency info in the /etc/init.d files so they can abandon the /etc/rc[0-6].d/[SK][0-9][0-9]* mess (line numbers? This is the 21st century), and its replacement of numbered runlevels with named ones (so I can have as many as I need).

Configuration management (2, Interesting)

cluening (6626) | more than 6 years ago | (#24240703)

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

Automatic Updates for Fools (0)

Anonymous Coward | more than 6 years ago | (#24240705)

Anyone who allows automatic updates is a fool. Do you really trust the updater to not install a backdoor somewhere in your system while you aren't watching?

In any case, Redhat is guilty of sloppy authoring (and ultimately poor design) of rpm scripts which is a significant contributor to configuration problems.

Try eradicating SELinux from your system and see the mayhem caused by various rpms erroneously depending on what should be an optional module.

Which distro? (0)

Anonymous Coward | more than 6 years ago | (#24240715)

If I just needed to setup a DNS server, which distro would anyone recommend? I have an old BSD 4.8 with bind 8.somethin and I know it all needs to be canned.

Re:Which distro? (1)

MichaelSmith (789609) | more than 6 years ago | (#24240947)

I use netbsd but a current openbsd or freebsd would be fine I am sure.

not on EL3 it didn't (0)

Anonymous Coward | more than 6 years ago | (#24240719)

my RHEL3 nameservers were upgraded by up2date without any problem whatsoever.

Suprised... (1, Redundant)

kenh (9056) | more than 6 years ago | (#24240745)

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

You Should Be FIRED. (0)

Anonymous Coward | more than 6 years ago | (#24240907)

Let's just blindly patch overnight and hope all patches work, then piss/moan when something breaks. Really smart, BTW, on a production DNS server!

JR : "I have a gun in my room, I'll just go shoot him, and. . . "
Dr. Evil: "We'll just close the door and assume everything went according to our plan."

At least... (1)

xalorous (883991) | more than 6 years ago | (#24241197)

...the file was backed up and not deleted.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>