Gentoo On Server Considered Harmful 372
Siker writes in to point out his blog post — Why Gentoo Shouldn't Be On Your Server — which seems to have stirred up a lot of discussion, including a thread on the Gentoo forums. From the post: "I firmly believe in updating server software only when you need to. If you don't need new features, and things are working, why change anything? If you update anything you will undoubtedly need to update configuration files. You will need to fix things that break in the upgrade process... This is hard with Gentoo. Gentoo wants you to change a lot of stuff. It wants to be bleeding edge."
And?? (Score:5, Informative)
I agree... so why does this preclude using Gentoo?
Just because you _can_ update all the time doesn't mean you should. I've used gentoo for various purposes (server, desktop, laptop). What I usually do is get it setup and install all the packages I need and then leave it for a _long_ time... only upgrading packages that I either need the new capability of or for security purposes.
Look... I personally don't think Gentoo is the best server OS out there... but I also don't think that just because the package system makes it really easy to tinker with the system that Gentoo is inherently unstable...
Friedmud
Part of "article" not quite correct. (Score:5, Informative)
Yea. Not quite. This is what the "ACCEPT_KEYWORDS=" setting in make.conf is for. If you don't have it set, you get "stable" packages. If you do have it set, you get the unstable stuff.
Further, with the use of the files in
Haven't read the rest yet, but wanted to point that out.
Re:This article makes good points. (Score:5, Informative)
The problem isnt updating often... it's when you DONT update often.
We had one system which we didnt bother to update. (Dont fix what isnt broken)
Then one day we had to upgrade some of the services.. which in turn required lots of libraries to be upgraded.
In the end, we had to upgrade kernel.. cause libraries didnt support 2.4 kernel.
Stuff change too much in gentoo to put it simple.. It's easier to keep updating often
emerge sync && emerge -u world
Then iron out all config-changes. Find out which undocumented features were changed, which keys to add to startup script etc.
Lesson learnt: Dont use gentoo on production systems. Run it on your desktop computer you play around with...
Re:This article makes good points. (Score:4, Informative)
I agree. Every now and then a program's latest version doesn't agree with a config script somewhere, but that's what etc-update is for. If something borks, you can always ask the gentoo forums [gentoo.org], which is an invaluable source of information for all things gentoo. That and the gentoo-wiki [gentoo-wiki.com].
Also, no one is 'requiring' anyone to upgrade. I administer hundreds of gentoo servers and you don't always need to keep up to date to be secure. Part of the nice thing about gentoo is that you're only installing the packages you need, so if you know of a vulnerability in a script you use, you don't have to upgrade your whole portage tree just to plug a hole.
My post to the gentoo forums (Score:5, Informative)
If someone is running a server room with many live production systems where downtime must be in seconds per year, they should ALWAYS have a test environment and a production environment. Gentoo makes it extremely easy to produce this setup. Imagine if you will, this setup:
1) Master rsync system (contains the portage sync used by all the systems)
2) Test boxes for each role needed (perhaps you have 3 different kinds of servers, WWW, Mail, DB)
3) Many production boxes
What you would end up doing is creating a fairly generic gentoo install (by generic, I mean hardware independent - like i686 or whatever you feel comfortable that will be supported for the lifecycle of the servers). All production servers are identical to the test boxes at the beginning of this example and have a simple backup of the whole test environments (perhaps a large tarball saved on a separate drive). A new update is necessary for apache so you do an emerge --sync on the master rsync system. Then you rsync all the test boxes so they have the same portage tree. You then run the necessary installs on the test systems to make sure that it works, if it doesn't, then you research why and figure out if its easier to fix after the update, or if the update needs to be done differently, if you need to, you can restore the test system from the backup and start over. After you have all the test boxes running well, you can then rsync the production boxes and reproduce the steps necessary to get them updated.
Once all this is said and done, the production boxes will all be updated successfully (and the updates were tested on the test boxes) and the test boxes will at this point have the same configuration as the production boxes. You would make a new backup of the test boxes and wait for the next time you have to do this cycle. As long as the boxes really are identical, you could even run konsole (or another xterm that allows you to send your input to multiple console windows) and perform the identical steps on all the same type of boxes (sending your update commands to 20 or even 50 servers at once).
I'm sorry, but in any real production environment, I see NO issues with this setup. It may be a bit time consuming if you have a lot of etc-updates to do, but still, the basic update should be painless to that point.
-Jason Pf.
Re:*sigh* (Score:2, Informative)
Re:This article makes good points. (Score:4, Informative)
Re:This article makes good points. (Score:3, Informative)
Re:CentOS updates (Score:5, Informative)
Yes, it's yum.
I assume it uses yum, or something like it, being RedHat, but does it pull from RedHat's servers directly, or are there separate CentOS repositories?
CentOS Repositories
In that case, how closely do the CentOS repos track the 'official' RHEL ones, in terms of patches and bugfixes?
The official RHEL ones are publicly available, and tracked by CentOS very well. The only changes they make are for trademark requirements. Thus far it has been bug for bug compatible with RHEL.
Not that you'd probably want to do it on a true 'production' system, but can you do the CentOS equivalent of 'apt-get upgrade' and be reasonably assured of not breaking things?
Yes
I've always been intrigued with CentOS, and it does seem to have a good reputation as far as stability is concerned, but after growing up with apt-get (and before that, nightmarish experiences with dependency hell on some very early RedHat systems), I've developed a certain perhaps-unwarranted negative bias of everything else.
I prefer yum myself. I used apt when it first came out, and loved it. Since I got my first 64 bit machine I just prefer something that handles the dual architecture a little better. For the most part they're about the same though.
Re:This article makes good points. (Score:5, Informative)
The joy of portage all the way. Continuous upgrade versus release cycles. 15 years of dealing with both have convinced me that portage is good only in two places:
Everything in between - forget it. Update hell, dll hell, etc. If you use portage (either the BSD or Gentoo incarnation) you die and releases are the exact and only solution to this. You can stamp servers with a "released" OS out of workshop by truckload and you can be more or less confident that updates will not break a lot of things. The only problem is upgrades to next release but if you are using The One OS to rule them all [debian.org] even that is not a problem.
Re:This article makes good points. (Score:5, Informative)
First reason, is that you don't have to upgrade those production machines all that often. I sit down and read any security advisory that seems to affect me. And, not surprisngly, there are actually very few remote vulnerabilities that hit Gentoo-hardened. Furthermore, those tend to be in software right in a leaf of the dependency tree, or software I might consider disabling (or limiting to trusted hosts) to the next maintainance cycle.
And there comes it - once in 6 months a massive emerge -uDB world && emerge -uDk world && revdep-rebuild && perl-cleaner (better don't omit the latter two). The system is nicely trimmed down and the build runs on a few machines I have available, so it doesn't take any epic amounts of time. In fact, I even seen it done within half an hour. Still, back when it did take a better part of the day, I simply run the first command a day earlier and then used the packages, what of course is a breeze.
Finally comes the configuration updating. I haven't seen it easier anywhere. The first nice thing is that Gentoo developers don't toy around them - they usualy come as the original software developers intended. But what really makes a difference is the toolchain. By far, I have seen no other distro that automagicaly within the standard package system uses revision control for configs. And then, it gets the trivial updates done for me, and puts me into vimdiff anytime any decision is required.
At most times, this means no downtime at all, as everything runs smoothly. In case of a kernel upgrade, or anything going wrong (once till now), we still have redundancy. So there are no visible drawbacks of using Gentoo on those servers... Unless I, and my boss, am missing something.
Re:This article makes good points. (Score:3, Informative)
If you are serving static content, use something tested like Debian stable.
If your business depends on you being at the technological front edge, (Etrade for example) then you run something like Gentoo or Debian unstable (Etrade runs Gentoo, but Debian unstable has packages of about the same age and quality.)
If you run something like Debian SID, Gentoo, FreeBSD current, or Microsofts current beta server, you need to set up a test server, and you need to have a staged rollout, but you were going to do that anyways if the site was at all critical. If you are just running a file server, or static web server or some such similar server, Debian Stable, windows 2003 Server, Solaris, and some versions of FreeBSD are all worth a look as you can get them supported in 2008, even if you don't decide to upgrade. (longer than that, a popular release of FreeBSD is probably the only server with a real chance of getting security patches back ported to it.)
The comments to the article really point to some of the things the author was unaware of, and happily accepted the advice and hints. I have never used Gentoo, but there are people and organizations that run large server farms with Gentoo, so it clearly is suitable for some server use.
Re:This article makes good points. (Score:3, Informative)
What almost everyone who really uses Debian in production does is run the stable software for everything that can be gotten away with running the stable version, and specific backports of sandbox tested versions from unstable. (In many cases backports.org [backports.org] or other publicly available repositories have actually done the hard work for you.)
In this way you avoid having changes that you haven't specifically asked for sinking your production machines, and can easily keep up with security updates. When you're dealing with whole fleets of systems, this becomes a not inconsiderable advantage.
Gentoo FTW (Score:3, Informative)
I also love that Gentoo has THEE quickest reaction time to security updates, leaving your competition vulnerable and you safe. I've got multiple computers running gentoo. One is my home desktop that I didn't use for probably 2 months. In that period of time there were 800 packages that had to be updated, I'm now down to about 200 that I still have to finish, and that is exactly what this article talks about. However, a server won't have that many packages to begin with because it won't have gnome, kde, beryl, nvidia, dvd support, mythtv and other optional programs, and games! However, my gentoo server, left alone for 2-3 years probably would require everything to be updated, it would flow much more smoothly than a desktop update.
Gentoo is great on serveres as long as you don't have everyting installed. Gentoo is great on desktops as long as you keep upgrading. Gentoo rox.
Re:This article makes good points. (Score:3, Informative)
If your mythbox "just works" and isn't exposed to the outside world, JUST LEAVE IT ALONE. People like you make bad admins, regardless of OS or distro.
As for the haters, Gentoo is not the be all of Distros, but let's not pretend that the other distros are perfect mmm'kay? Gentoo is what it is. Requires effort and gives the users lots of choices on how things are configured. If you are willing to pay the price [of taking the time to set it up] you are rewarded with a flexible OS.
Otherwise, plomp that knoppix/fedora CD in and use the software as configured by other people.
Tom