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."
This article makes good points. (Score:5, Insightful)
The promise of Gentoo for me is being able to continually upgrade and never get outside of that window of support.
I actually have a new shared user system that is running Gentoo that is kinda in beta right now. This article was very useful for me because it brings up those points about stability that concern me. Its kinda an experiment.
I think I may try Debian next.
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, Insightful)
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
How is it Gentoo's fault that the services you run require updated libraries? How is it Gentoo's fault that the libraries you use require a 2.6 kernel?
Seems to me the blame lies with the services and the libraries respectively, and performing the same upgrade would require the same kernel update on other distros too.
Re:This article makes good points. (Score:5, Insightful)
So in a way, yes, it is Gentoo's fault. It's just the way the distro is designed. Everything at the latest revisions possible. Great for a home system, not good for a server you have to maintain.
Re: (Score:3, Funny)
Re:This article makes good points. (Score:5, Insightful)
Yes new patches come out all the time, but the real question is whether you trust developers to improve their code over time, or to destroy it. We've seen one end of the spectrum with what MS did between 98 and ME, and I believe that gentoo shows us the other end. While you theoretically always ARE at the bleeding edge with Gentoo, it does have a "safe window" built in, the way it handles portage with the keyword system. New packages are usually in CVS within 48 hours of release. If they compile and run, they get thrown into the ~arch (testing) rapidly. Then, depending on what kind of update has been done on it, you'll have to wait anywhere from 2 days to 5 months to see it come down into the actual arch repository, which is deemed the "stable" gentoo. I personally run ~arch, yet I can't seem to recall a problem that portage couldn't solve with minimum input on my part.
Yes, I'm a gentoo fanboy, but I'm not so glued down into distro patriotism to refuse to see flaws where they are.
Some people seem to want to spend time in maintenance to keep a system up to date and continually tinker and let their knowledge grow by frequent maintenance, and other people seem more interested in setting something up and being lazy about having to deal with updates/upgrades. I personally trust that most open source coders, and especially the ones for the big projects like apache, ssh, mysql and others of that caliber, usually improve the code from release to release, not damage it. Security fixes, bug fixes, and plain new features are usually the goal of coders, and I trust that they do that.
Re: (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
Bukd your own binaries (Score:3)
These binary updates can be pushed out to other machines and installed once any config file issues have been ironed out on your package-build machine. For extra kudos, all machines can be used as distcc-servers so that package compilation can be accelerated.
Finally, to reduce load on gentoo's servers and to help keep the machines in sync, th
Re: (Score:3, Insightful)
Real production environments, at least at the enterprise level, are built around stable, well tested binary packages that just work, change control processes, updates that can be applied safely with minimal technical
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 th
Re:Bukd your own binaries (Score:4, Insightful)
If you want something that you know isn't going to change much, and certainly never in a way that breaks anything, use Debian Stable -- and be prepared to build the odd package from source {it really isn't as bad as it's made out to be} if you have to have a massively up-to-date version of something. They have a more-than-King-size package repository.
Re:This article makes good points. (Score:5, Interesting)
I would see that lesson instead as don't experiment on your production systems. Obsolete hardware is useful for testing out stuff like this.
The reason I don't run gentoo on production systems is simply becuase I am not familiar enough with it and it is different enough from other distributions of linux and other versions of *nix to make things confusing. It's the same reason I don't use reiserfs - if it all messes up how can I or any moderately skilled linux user get things back into operation?
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:4, Interesting)
If you are dealing with 2-3 packages you can do that by using backports.org or backporting yourself. If you need more and these are an essential part of the business there is no difference between portage and backporting/local packaging. In ether case they have a tendency to break and you need local developer/sysadmin time allocated to that. Portage gives you no advantage whatsoever because the resource you gain in keeping more than 3-4 packages synced to their projects HEADs you will lose in infrastructure upgrade creep. Every time I have looked at this in the past taking out the numbers out of the ticketing and workflow control systems have proven that this is the case. I have yet to see one case where this is not.
Re:Not if you're using Debian (Score:5, Insightful)
Many itadmins and most developers have a problem with understanding of the "establish a platform and build on it" and "platform freeze before development" ideas. They think that everything is a fair game and the results (in man hours wasted on piecing everything together for release) are usually quite obvious.
Re: (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 sta
Re: (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 th
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: (Score:3, Interesting)
Gentoo does reasonably well with configuration stuff (certainly better than any other system I've seen), but I still think it should be better; it'd be really nice if upgrades that change config files would be built but not installed, and then you'd be guided through updating the config fi
Redhat 6.2 (Score:5, Funny)
Re: (Score:3, Insightful)
Re: (Score:2)
Re:Redhat 6.2 (Score:4, Funny)
Re:Redhat 6.2 (Score:4, Interesting)
My Gentoo system was up 309 days [snerk.org] before I realized that the PSU fan had stopped turning and the motherboard overheated and blew 6 capacitors which is why the clock got so far out of sync (the computer thought it was April when I rebooted it back in November) which explains the graph weirdness.
Prior to that I had an uptime well over 200 days ruined by a blackout that outlasted my UPS.
I perform updates here and there on my server periodically and perform a full-scale "bleeding edge" upgrade whenever I'm forced to reboot the machine.
Re:Redhat 6.2 (Score:4, Funny)
Dude, install NTP. Then you could have kept the machine going without those useless capacitors!
Re: (Score:3, Interesting)
I've got to admit, I've got a relatively short uptime right now on Gentoo, only 98 days, 15:27. (There was a power outage due to a storm.) But in that time, I've upgraded versions of asterisk, postgresql, apache, squid, samba, PHP, and mythTV. I've also recompiled the system using a new compiler, and the only service downtime I had was when the recompile of PHP was finished, merging it in crashed Apache. Total downtime? Less than 15 minutes. Now this is a home server, and I wouldn't be nearly so aggre
Comment removed (Score:5, Insightful)
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.
Re:This article makes good points. (Score:4, Informative)
Re:This article makes good points. (Score:5, Insightful)
Which is why IT Pros prefer Red Hat Linux or its unencumbered variants link CentOS, White Box, and Scientific. Better testing up front thanks to the Red Hat gang, and longer shelf life. Which is why most commercial software chooses to support it first, it provides a stable base.
Re: (Score:2)
Not really. "Pros" typically don't care about platform-delivered apps, and they certainly don't care about crap like various RedHat knockoffs. Stability is OK, but in the end it comes down to one thing: paid support. Which is wh
Re: (Score:2)
Re:This article makes good points. (Score:4, Interesting)
What kind of dope uses Fedora on a production server?
Use CentOS - I'm running CentOS 4, and anticipate not having to do *ANYTHING* to my production systems except use them, keep them turned on, and keep them updated (which is about 5 min/week) until 2010 or so.
Re: (Score:3, Interesting)
Here is where I make myself sound like an old man talking to his children about walking through the snow both ways. I knew someone would have to make a remark like this.
I've been using RedHat and thus Fedora for 10 years now. I started out on Linux on the RedHat track. And thus I'm more familiar with it. CentOS wasn't even in diapers and there weren't many other choices. Now that there are things like CentOS, I've actually gotten tired of dealing wit
CentOS updates (Score:2, Interesting)
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? I assume it's the latter. In that case, how closely do the CentOS repos track the 'official' RHEL ones, in terms of patches and bugfixes? Not that you'd
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: (Score:3, Interesting)
It's arrogant, elitist (and ignorant) comments like this that really drive me crazy.
What you use in your production environment depends on different things; Knowledge and preference of the admins, business needs, type of environment, etc.
At my current employer, we're moving away from debian towards fedora for a very specific reason: Our requirements dictate that we *need* functionality that doesn't exist in 1000 year old software that's housed in debian p
Re: (Score:2)
Long
Re: (Score:2, Insightful)
The stability of Gentoo on ANY system is user controlled. Period. Yes functioning hardware is first and foremost, but running a stable/unstable system is entirely set up by user config settings. Its THIS ability in Gentoo, that will determine just what software gets updated at what stage of their particular development.
I keep reading posts in here about constant updates, and bleeding edge, which in turn produce broken Databases, unstable systems etc. If people don't know ho
Re: (Score:3, Informative)
Re:This article makes good points. (Score:5, Interesting)
Re: (Score:3, Insightful)
on the contrary, this article makes NO good points. First of all, he is using old hardware and then he complains about the time it takes to compile packages. Duh. Slow computer + large packages like Apache and MySQL = a lot of time spent compiling. The writer talks about the inital install taking a long time. Yes, my first time installing Gentoo using the CLI took a long time, too, because I was spending more time reading the documentation than performing the steps. The documentation is stupendous, bt
Re: (Score:3, Insightful)
[Debian stable] even still has SysV init which is a dying "Legacy UNIX" thing... so the OSX, Ubuntu, Slowlaris etc. crowds say..
I'm a long-time Debian user, and I also think it's an ugly legacy UNIX thing. It's much better to have some sort of process supervisor that will restart crashed servers, and that will deal with dependencies in some sort of sane manner. The problem is that Debian is huge, and the amount of work required to switch to a new system would be almost equally as huge, but the benefits are comparatively small, so there's never been a push to change to something different.
The bright side of it is, like most of
Re:This article makes good points. (Score:5, Insightful)
I run Gentoo on my own machine, and most of my users WANT bleeding edge versions, a lot of custom options here and there. The system is using a hardened kernel, stack protection and everything is compiled for 64bit (k8). I don't know of any distros that can do that for every package. So far I have had 1 package problem, and that was resolved by 'uncaching' some stuff and redo the emerge of that package. In general, gentoo is easy to maintain, provided you update regularly. As for the people whining about compile times, this is a server, using it at 100% cpu now and then, provided the compilation has a low priority impacts noone. Compiler time is a non-issue, i'm not running X, soundcards, usb, video drivers, gui-browsers etc, there's not all that much to upgrade.
It should be noted that I sync the portage tree from a euro-mirror to a local mirror 6 times a day, and having 3-4 meg a sec to the files-repository makes downloads take an average of 2-3 seconds. Coupled with two beefy processors and lots of ram, Gentoo is brilliant for me. And yes, I have permission from the rsync-maintainer to synch that often.
Some serious crack smoking... (Score:5, Interesting)
I run Gentoo on a server. The server is stripped down beyond what a typical 'router' distro looks like - one of the reasons I went with Gentoo is I could really trim the system down for the job at hand. My server only gets updates for security, and once in a while a bug fix that impacts the applications running on the server. Not often. When I need to compile something big, the last place I'd do it on is the server itself - it has another task. I take one of my workstations with far more GCC horsepower and let distccd [gentoo.org] do the work for the poor little pizza box. Beyond the initial build, I doubt those boxes have ever compiled anything.
Since it is a source-based distro, I also am not trapped by RPM's or other packages no longer getting provided for my system. One of the applications I had was using RH9 (with paid support) only to have them drop maintenance on it and have the vender drag their feet moving to another platform (clue stick, they had issues with the 2.6 kernel, so would not 'support' any platform but RH 8 and later 9. The enterprise editions? Forget about it... You want to live in the suck, you try keeping one of those boxes alive and secure years after it EOL.
Re: (Score:3, Insightful)
Re:Some serious crack smoking... (Score:4, Insightful)
Re: (Score:3, Insightful)
It's just not trendy to knock on Slackware, so everyone targets Gentoo.
Some people also love to ignore advances that are made. The article mentions how long it took to install Gentoo. He claims that there was not an installer when he performed his installation more than a year ago. This is false. There was an installer, but it was considered experimental. Since then, the installer has become the de facto installation method on x86/amd64 and will be the default method on other architectures as support
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
Re: (Score:2)
From what I have heard, it does mean that. Not updating a Gentoy box for half a year or even longer often means that any attempt to upgrade it will be hard and painful.
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: (Score:2)
Re: (Score:2)
Not for me! (Score:5, Funny)
I use to run Gentoo on a Personal Server (Score:4, Interesting)
* MySQL DATADIR is /var/lib/mysql
* Previous datadir found, it's YOUR job to change
* ownership and have care of it
* Sorry, plain up/downgrade between different version of MySQL is (still)
* un-supported.
I vowed never to use Gentoo again, and promptly moved that machine to Debian. I use to run Gentoo on all my desktop machines in the pre-ubuntu days, because it had the most bleeding edge desktop packages and optimizations. After Ubuntu came on the seen, Gentoo had no advantage for me. Its still a great learning too though. I highly recommend for aspiring Linux geeks.
Re: (Score:3, Insightful)
Anyway, it sounds like you're blaming Gentoo for something that is MySQL's fault. (Assuming that the format was changed, and not just the db dir location). It's probably because you went from 3.x to 4.x or similar.
Re: (Score:3, Insightful)
No, I should run a distro where I don't have to be on the defense against stupid design choices. I should choose a distro where stable really means stable.
I know that apt-get update && apt-get dist-upgrade (on Debian Stable) is unlikely to break anything. Testing is still prudent, but you know that nothing so insanely stupid
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
There's no such thing as "Gentoo Version 3" or whatever. A package is marked stable after it is deemed to be... well, stable. Gentoo does have a mechanism whereby you can ask it to tell you what it proposes to update before it actually goes away and does it (emerge -p), and on any system this is exactly what you should use to make sure you're not trying to do a major update on your database.
The one issue here
Agreed. (Score:5, Interesting)
The Problem With Gentoo... (Score:5, Insightful)
Gentoo is only good for ricers, Gentoo is bleeding edge and unstable, Gentoo is only good for X deployment
The truth about Gentoo is that it is not really a distribution. Gentoo Linux does not make "releases" and it does not aim to cover one area of the market alone.
In Gentoo's packaging system, called portage, the aim is not only to provide up-to-the-minute packages (which it does) but also to provide a wide variety of both tested and verified "stable" packages as well as more bleeding-edge, testing packages.
This, along with a properly configured make.conf and /etc/portage file system, allows you to pull down the packages you want that have been verified as stable (and are also under watch by the Gentoo security project) and keep track of their libraries with revdep-rebuild.
Stop branding Gentoo with stereotypes that label it as X distribution, the project even calls itself a "metadistribution" capable of dropping into multiple roles.
Re: (Score:2)
The problem with Gentoo is that Gentoo users assume that most people care about configuration options. They assume that people want the most up-to-date packages. They assume that there's no reason to have stable, long-term supported releases.
The vast majority of the market wants something that's not a moving target. I can install Debian or CentOS, keep it up to date with yum or apt-get, and never worry a
Re:The Problem With Gentoo... (Score:4, Insightful)
Huh? We assume no such thing. In fact, we really don't care what "most people" want, at all. We make no assumptions about support. It is Gentoo detractors who tend to claim that we do. We don't. What we care about is making Gentoo. If Gentoo doesn't fit your needs, don't friggin' use it! Trust me, you won't hurt our feelings. If you think Debian is better, use it. If you think Windows is better, use it. You aren't harming us in any way by using what you feel is the best tool for the job. In fact, that is exactly what we try to give to our users. We give them a set of tools to allow them to build what they want.
I think the biggest issue is that people seem to have this closed-minded view of software and Gentoo. They're stuck in this way of thinking that lends towards doing what the vendor tells you to do. They run Red Hat. They run Debian. They don't think that you can build what you want. Gentoo provides the tools to do just that. For many of my clients, I have built custom Gentoo-based distributions. What they get themselves is slightly different than Gentoo. They get pre-compiled packages. They get a very nice Internet-based update system for these packages. They don't jump into make.conf, at all. They don't need to make these kind of changes. Instead, I have built a custom distribution with the software that the customer wants on it. They install it from CD, and it has exactly what they want on it and nothing else. Gentoo is the tool that builds this system. I am using Gentoo as it was intended, to build exactly what I want. People tend to forget that it is impossible to make something that fits every need. Rather than try to do so, like other distributions do, we instead provide the tools to allow you to build it on your own. It's a completely different philosophy, which is why I understand that so many people simply don't get it.
This whole argument is trivially debunked (Score:3, Insightful)
some truth, but for many Gentoo is appropriate (Score:5, Interesting)
First of all, I find it interesting that FreeBSD never seems to get these complaints and hate about having to recompile packages with portupgrade all the time, and being able to tweak the flags, etc. In this respect, it's just like gentoo!!! Except without a lot of the fancy features like etc-update and slots and masking and multiple supported versions. Yes, the "base system" is more stable on FreeBSD (which is both a blessing and curse), but what is it about Gentoo that attracts so many haters/inexperienced admins, hmm??
Anyway, I run Gentoo on servers. (Also FreeBSD). I think it's great. I can't stand stuff like Red Hat, which makes it difficult to customize anything, so I'd always resort to installing stuff "by hand", which was a huge pain. Or creating a custom RPM, which was an even bigger pain (RPM is basically a huge clusterfuck in general).
Being able to set up ebuild "overlays" is great. Being able to set up custom profiles that contain all the software needed for a particular app is great. Writing ebuilds is a piece of cake. Turning on/off various features system-wide is very helpful. The mechanism for merging configs (etc-update or dispatch-conf) is nice. Being able to pin down specific versions with masking is good. Etc. For the record, I've never tweaked the CFLAGS in my life.. that's just not why I use Gentoo.
The author writes this:
I have no idea what happened to him. Updating your profile is basically moving a symlink, which changes some lists of base packages and other high-level build configuration. It doesn't "touch" anything in your system. Sure, you have to some upgrades afterwards, but you have to do that regularly anyway on Gentoo. Compare it to upgrading FreeBSD from 5.x to 6.x, which is much more involved.
I've been using glsa-check for a while now, it works great. It tells me what's got known holes and I just update those packages, and their dependencies. What problem did he have with it, besides the "experimental" status? Yeah it can "do stuff", but I don't use those options, I just use it to get a list of packages with known holes. Heck I could probably write a script to do the very same thing.
Suppose you need to patch one of your installed packages by the way.. it's very easy to create custom ebuilds on Gentoo. Sometimes I plug security holes that I've found on my own for instance.
I have a simple strategy with Gentoo servers: keep an identical test/staging server nearby and do your updates on that machine first. Run your application tests and then upgrade the production machine. If you want, build binary packages on the staging machine. I would do this even with Red Hat, Debian, etc.
Another point: I've NEVER run "emerge -u world". I always do the packages in small groups or chunks and then updated configs, restarted daemons, and run tests after each one. This seems like a much better strategy than what some people do.
Also, I gotta say, it's probably not a good idea to run Gentoo on a production server unless you've got at least 5 years of Linux admin under your built. You also need to FOLLOW the Gentoo newsletter, AT LEAST, so you can get a heads-up when config files change or files are moved around. It happens from time to time.
Really, the only valid point he makes that generalizes to servers other than his own is the following: Gentoo takes more time to keep running. But you have to weigh that against the flexibility you get, just like any "build vs. buy" decision.
Re: (Score:2)
FreeBSD vs. Gentoo (particularly portaudit/glsa) (Score:2)
I'd imagine that there are fewer FreeBSD desktop users than Gentoo desktop users, and I believe it is the "clueless user" stories that cause the most ribbing. I also think that FreeBSD has a bigger presence in the server space. Yahoo runs FreeBSD
Re:some truth, but for many Gentoo is appropriate (Score:4, Interesting)
As was pointed out in an earlier post, gentoo is a meta-distribution, whereas FreeBSD is complete operating system. Overall, the "FreeBSD experience" is significantly different from the "Gentoo experience." FreeBSD feels much more polished, and is therefore less likely to produce frustrated blog entries.
I administer Gentoo, FreeBSD, and RHEL boxes, and have several years of Solaris experience. There is a lot to like about gentoo but the final point that you acknowledge, "Gentoo takes more time to keep running," is extremely important, and worth elaborating on in a whole paragraph of its own.
It does require more time and effort to build a gentoo box in the first place; it take more time/effort to provide a secure environment (glsa-check is still in beta, for good reasons); it requires more time/effort to ensure that your dev, staging, and production environments are all in sync. Yes, it can be done, and quite elegantly, but it costs more (time == money) to do that on gentoo than using other solutions.
That is the core frustration of every negative gentoo review that I've read. The most common counter-argument to those complaints boils down to, "You just haven't spent enough time to appreciate the elegant beauty that is gentoo." Allow me to offer a counter-counter-argument.
Once upon a time, I took the time to fully appreciate the beauty that is emacs. I accepted the truism that emacs doesn't meet you halfway, that you have to go to emacs; I read books on the subject; I made it my default editor; I created a highly customized
I think of gentoo as the "emacs" of operating systems - really cool, but with a high pain threshold before the cool starts paying for itself.
Re: (Score:3, Insightful)
The problem with USE flags is that every Gentoo build environment is __too__ unique. With FreeBSD, everyone is running, debugging, and fixing the same stuff. Consequently, most of the ports build & work to
*sigh* (Score:5, Insightful)
Re: (Score:2, Insightful)
Re: (Score:3, Insightful)
Incidentally, I've run Gentoo for years on laptops, servers, you name it. I switched to Ubuntu about a year ago for desktops, but still use Gentoo on a server.
What I like about Ubuntu in particular is that every six months you can pretty much EXPECT all your packages, for the most part, to be updated to the most current stable versions. With Gentoo it's so much more haphazard. Yeah, Linux itself is haphazard...right, I know. With Gentoo, however, you're tied to the maintainer of th
Re: (Score:2, Informative)
Re:*sigh* (Score:4, Funny)
Oh! I Guess Non-MS SW Has "Issues" Too! (Score:3, Funny)
Where, oh where, is the standard Slashdot drivel from you sanctimonious Slashdot twits?
You've got to be kidding me... (Score:5, Insightful)
updates portage... Emerge flags include "--pretend", "--ask" and "--fetchonly" among several others, learn to
use them.
to each their own (Score:4, Insightful)
- one can create a copy of the source files repository
- one can create a repository for self-compiled binary packages and install from there
- one can use the global repositories, and still get a stable version by restricting available packages by version
- finally, as others say, one can use the stable version.
Since the blogger seems to have missed these obvious ways, he hasn't read the documentation, and hence is not a competent administrator, hence his opinion is not very valuable.
Having not even read the article... (Score:2)
...I wonder where the debate stems from. Gentoo is a nice OS and all that, but it's not one that includes the features most server admins want: stability, non-intrusive security upgrades, support for commercial software, minimum hassle, minimum maintenance, and minimum surprises!
Of course, if you absolutely want to, Gentoo is perfectly capable of running on a server. It's just not something I would use myself, or recommend to any others. People who do so, do it because they are already Gentoo fans, not be
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.
Lack of support contract considered harmful (Score:4, Interesting)
Nonsense (Score:5, Insightful)
Any binary distribution has two modes of updates. One is an updated package within the same release; the other is a mass-update from one release to another. Gentoo combines the two, since the distinction is artificial. What you call "changing a lot of stuff" is merely keeping packages reasonably current so that you never have to do a mass-update or complete reinstall.
Anyone who considers the Gentoo update process too difficult either hasn't used Gentoo (upgrades are easy, and there aren't that many of them if you stick to stable x86) or has never dealt with package conflicts in binary distributions. That is the real horror I want to avoid, and I avoid it nicely by running Gentoo.
Updating (Score:3, Insightful)
It does NOT force you to do anything.
"You will need to fix things that break in the upgrade process..." Like what?
This past year there have been some major changes in the Linux world like:
glibc, gcc, xorg, apache(Gentoo went to the standard) and mysql are some the things I can think off of the top of my head.
Because of how Gentoo updates, big updates like these might break things if your not watching what your doing.
And if your blindly updating your system and overwriting confings when you do etc-update, its your own damm fault.
There comes a point in where a package is marked 'stable' for some distros, but if you look on the project site, its old and outdated.
http://gentoo-install.com/ [gentoo-install.com]
"Considered Harmful" considered harmful (Score:2)
"Something Considered Harmful" is one of the more cliche ways to title an essay like this. Can't we come up with *slightly* better titles? Like, say, the one the blog post used?
Anyway, it's been said [meyerweb.com] far better than I could manage already, so I won't keep ranting here.My gentoo server... (Score:4, Funny)
So, now when server issue has been explained exhaustingly, we can talk about my gentoo programer's desktop, gentoo electronics lab and drill machinery controller, gentoo adsl/wifi router and gentoo tv/multimedia nano-itx box.
From my point of view, Siker is just a moron and I mean it seriously.
Cannot say I disagree. (Score:5, Interesting)
Gentoo is so system dependent compared to other distros. The end result, instead of having 1 package for some function, you have 1^n packages for that same function. Given 'n' amount of users with differing hardware and compile time arguments. The Qaulity Assurance ends at the user, always. You ultimately have a quality control department that consists of one, the user.
Any system upgrade or maintenance procedures in production environments are usually limited to a few hours at most. It does not make sense to spend six hours compiling what could have been installed, configured, and tested in 6 minutes with a pre-compiled package. In the event of a hardware failure, I find it reassuring when a Linux distro can be loaded onto a spare box in 15 minutes. Then spend a few more minutes restoring configurations from a good backup.
But that's just my opinion. To each his own. If it works for you, then go with it. Otherwise, I'd say it is a fairly level-headed review.
Re: (Score:2)
Compile-Time (Score:2)
Not anymore. (Score:5, Insightful)
I used Gentoo for several years. I learned an awful lot about Linux from it. And I appreciate the work that goes into it. But my servers run Debian now, for one reason - quick, reliable updates. I support several small businesses, I don't have the resources to maintain test environnments to check the impact of upgrades. And not having multiple powerful systems at many sites means distcc is not an option. And the recompiles occasionally necessary for apache or samba or postfix or mysql put an unreasonable strain on servers that are typically not high powered and are supporting multiple users. So for quick, reliable system updating apt-get beats emerge every time.
I'm not knocking gentoo. It's a great system for testing stuff, and evaluating software. But in the 3 minutes it took me to type this post, I could update 5 servers that hadn't been updated in a week.
Never updating a server? (Score:3, Insightful)
I do agree that there are certain things you needn't update. A local server without a connection to any user you do not trust your data with (i.e. nobody but you, if you're smart) running on rock stable software that gets feature adds rather than bugfixes in new versions is a candidate for this. And for this server (singular, probably worldwide), the setup is ok.
Not updating a server connected to the internet is an invitation for hackers. No matter how "stable" or "solid" or "secure" a system is deemed to be at the moment of its compilation. Time and again there are bugs found in software that has been considered stable and safe for years. OpenSSH is hardly the most insecure application out there, and I would NOT want to see what happens to a server that does not update it.
And, last but not least, when you don't want to update Gentoo, you don't have to. It's fine and satisfied if you don't do an update sync. Actually, you reduce the workload of the servers if you don't.
So what the hell is this fuss about?
Linux.com had a different take (Score:2)
I think Gentoo CAN work in the server room. glsa [gentoo.org] and other tools make it a better candidate than it was a few years ago.
Some of the other popular distros capable of running X-less (e.g. Debian) and the *BSDs have been and are in wider production deployment. Of course, if one is tied to a storage, database, or backup vendor, one may be tied to Red Hat or SUSE.
Gentoo on a University Cluster (Score:2)
So? (Score:4, Insightful)
I'll be more than happy to let the folks at Canoical, Red Hat, Novell, or wherever be the ones to put in several hours of work; I simply can't, at home, put in the hours required to maintain a "stable" system. When I quit using Gentoo a couple of years ago, it was to the point where I'd search the forums before I'd ever install a piece of software. And you know what? That gets old. Real old. Especially if you're sitting in front of what should be a desktop machine and you're waiting for revdep-rebuild to rebuild a couple dozen packages because libpng applied a non-backwards-compatible patch that fixed a major security flaw.
Sorry, kids, but although I can deal with running a Gentoo system, I choose to run Kubuntu 6.10. Not because I'm too much of a wuss to run Gentoo, or because I'm too stupid to run anything other than Ubuntu, but because I'd rather spend the hour or so of computer time I have at home some days getting pix and video of my adorable girl (now at toddler age) ready for the grandparents. Not glamorous, and doesn't help push the state of the art, but it's much more gratifying than, say (I'm making this one up), trying to chase down the ruby package maintainer to get him to apply a patch so that you can use Getopt::Long without having to edit files by hand.
Re: (Score:3, Insightful)
OK, you're a jerk ;)
Sure, kubuntu is great on a desktop, but how does that relate to the article, running Gentoo on a sever? Gentoo lends itself quite nicely to a server environment. Personally any server I've run in the past 4 years has run Gentoo. I've run others before and I've tired others since. I've come to realize that the initial time you spend building a Gentoo server (minus compile time) is about equivalent to the amount of time I've had to spend going back to customize things I didn't like abo
FreeBSD (Score:3, Interesting)
Daniel's original premise seems to have been (which I agree with) that there are some elements of FreeBSD which are highly desirable, which at the time, Linux didn't have. Ports, portaudit, portupgrade...they're all good things. Ubuntu has an equivalent of portaudit and portupgrade combined, and of course the Red Hat autoupdate was probably the first on Linux, but the difference between those and the two commands I mentioned is that the Ubuntu and Red Hat services both focus on binaries...portupgrade anywayz focuses on source, which is something that at least some of us want.
I don't advocate using source compilation all the time, or if I do, at least not during the day or when you're active...set something up to do it while you're asleep or while the system isn't being used...that way it won't bother you. To be honest also, the main reason why I advocate compiling from source is simply for the reason that if you stop doing a certain thing for long enough, the ability to do said thing when you *do* want to has a tendency to disappear. If you maintain the attitude of compiling from source when it doesn't matter, there'll still be enough people doing it that the option to do so will still be there when it *does*.
There are a lot of people out there who don't want to do anything that even vaguely resembles self-responsibility or proactivity, at least where using a computer is concerned. That's fine, but said people need to realise that the fascist nature of such things as Vista is merely the ultimate logical extension of them wanting multinational corporations to act as their wetnurse. It's been an eternal truth in politics and other areas as well as IT that freedom and proactivity genuinely go hand in hand...If you don't want one, you're not going to get the other.
I stuck my head in the sand and I got run over... (Score:4, Insightful)
Quote: "If you don't need new features, and things are working, why change anything?"
Translation: "Never change a working system."
Quote: "...I ran the dreaded but most needed "emerge world"..."
Translation: "My system worked but I updated everything"
Quote: "I had nearly no idea of what I was updating..."
Translation: "I didn't bother to check what was going to change"
Quote: "I tried to read the enormous emerge log file..."
Translation: "I didn't bother to read the log file about what had changed"
Quote: "...the machine had to be resuscitated..."
Translation: "I changed it, it doesn't work anymore and I can't be bother to read the documentation"
Basically, he made a bad choice for his environment. Horses for courses.
Not at all (Score:5, Insightful)
But on the stable branch, I've actually been very surprised with how
As for the points the author raised against Gentoo:
1) Too long to do initial install.
This one gives it away from the start. You only install once. But this is at the top of the list. I can't remember how long it took me to install Gentoo on this server, but it was probably 2 days or something. Who cares? That's what time I take installing *any* server. You don't just whack it together and put it into production. You install, you read, you test, you frig around some more. What's wrong with that? The author is no server administrator.
2) Same as point one, just repeated
WTF? Seriously, this author has his head up his arse. On the one hand, he later says that you shouldn't update willy-nilly on servers, and yet then says that it takes ages to update everything. So what, exactly, is he trying to achieve? It takes me about 10 - 15 minutes to update MySQL, which is the most common package I update. What's wrong with that? I back things up, shut down MySQL, emerge the new MySQL package, test, and import form backups if required. No problem? Where is this guy's problem, seriously?
3) Don't like updates, even if they are to more stable packages
Nothing forces you to update packages. Also, no-one claims that packages updates *won't* break things ( though my experience is that in the stable branch, updates *don't* break things ). But if you don't want to update, don't. No problem. If you do want to update, the tools are there to update easily. Sure you should pay attention to what you're doing. It goes without saying.
4) Same as point 3, but with the update impetus being security instead of stablity
Doesn't deserve a response really.
I challenge this author to prove that he's actually used Gentoo Linux for more than 7 days without running crying back to Linspire.
You *must* do controlled, conservative refreshes. (Score:3, Insightful)
There are two kinds of "broke", there are gaps in functionality
Case in point. The company I work for is in a mad dash to upgrade for the DST time change. And for those of you thinking "duh, you just upgrade your timezone files"... no it's not that easy. Some Sun systems require firmware upgrades, almost all of the systems prior to 2005 require binary updates because they can't handle a timezone that has two rulesets (e.g. they would apply the new 2007 rules to timestamps from 2005), most JVM's have to be patched or upgraded and some applications inexplicably do their own calculations and have to be update as well.
The majority of the company has the "if it ain't broke" mentality and were running everything from NT 4.0 on DEC Alpha's and Sun 2.4 to Windows 2003 64-bit and Solaris 10. Upgrading the older machines is an absolute nightmare because the vendor patches are built one, two even three years worth of patches that we haven't applied. What should be a relatively simple upgrade task has broken applications all over the place and has our QA and Engineering staff bleary eyed and ready for it all to just end.
The answer is controlled refresh. Twice a year you sync up your servers with a certain patchset. You don't go crazy... you just get vendor required patches and include them in your dev and qa cycles. And you DO NOT USE EOL OS' in an enterprise environment. Ever. This includes commercial and FOSS packages.
Full Disclosure : I run two gentoo boxes at my house my workstation and my mythtv box. I patch them about once a week because I like to tinker. My web/file/mysql server is running on a stripped down Debian system that only gets patched every few months or if there is an advisory that comes out.
Re:It's a dirty job (Score:5, Insightful)
That is, unless you really dislike your customers that much, be they actual customers or other divisions in your business.
Re: (Score:2)
I'd say you are, if you want a stable version to be getting changes made to it.
Re: (Score:2)
Dude, that's a lot better than to have all those packages depend on non-modular X packages that don't exist anymore. Actually I'd almost say I'm impressed that they managed to update all those dependencies so quickly. Although depending on both (OR, not AND) would be better, of course...