Slashdot Mirror


Gentoo On Server Considered Harmful

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

7 of 372 comments (clear)

  1. Some serious crack smoking... by (H)elix1 · · Score: 4, Interesting

    Gentoo allows you to be on the cutting edge, just like all the other distributions. The primary difference is it makes it very easy for those who don't know what they are doing to be there. Most folks running SuSE, RH, or one of the other 'package' based distributions won't build their own RPM, etc. There is nothing stopping one of the 'normal' distributions from upgrading the kernel with each release. I certainly don't update everything on my Gentoo box because it is there, on my server.

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

  2. Agreed. by MrNaz · · Score: 5, Interesting

    I have been a server admin for web/database for about 3 years now. I agree that bleeding edge is *not* where server admins want to be. There's a reason that Debian is widely considered the best server OS despite being rather far behind the bleeding edge. Tried and tested is better than the latest and greatest when you rely on the machine being up. It's also worth noting that the military doesn't use any COTS technology within 5 years of it being released.

    --
    I hate printers.
  3. some truth, but for many Gentoo is appropriate by Anonymous Coward · · 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:

    A profile update will touch a very large number of configuration files, and it may even alter your startup process. Obviously this is not something you want to do to any server. ................. The end result: the machine had to be resuscitated on-site with associated downtime.

    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.

    As you might be aware, FreeBSD has a nice little program called portaudit........... Now, Gentoo also has something like portupgrade. What it doesn?t have is portaudit. ............ In all fairness, Gentoo has an experimental command called "glsa-check".

    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.

  4. Lack of support contract considered harmful by fabu10u$ · · Score: 4, Interesting

    For a true production server where downtime costs thousands or millions of dollars a minute, you need the insurance of having people to escalate to if you have a problem. If for no other reason than to CYA in a liability / management-political situation. That's the real reason not to run your production on Gentoo (though the technical problem mentioned is probably what's kept anyone serious from selling a support contract for it).

    --
    They say the mind is the first thing to ... uh, what's that saying again?
  5. Cannot say I disagree. by atomic-penguin · · Score: 4, Interesting

    It's been said before by many. I cannot say I disagree with the article. With more traditional distributions of Linux, you always have standardized packages with some amount of quality control. Bugs and security holes slip through to the end users all the time. Often your end users report these bugs to the upstream maintainer. Occasionally, the end user even submits fixes upstream.

    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.

    --
    /^([Ss]ame [Bb]at (time, |channel.)){2}$/
  6. Re:This article makes good points. by saleenS281 · · Score: 4, Interesting

    And that my friend, is the niche Opensolaris will quickly start filling.

  7. Re:This article makes good points. by dbIII · · Score: 4, Interesting

    Lesson learnt: Dont use gentoo on production systems.

    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?