I am running Gentoo as a desktop system.
If I do a emerge -e world, it takes about 11h for compiling. I have a fast actual computer.

To prevent such a long compile time, you can use the precompiled ebuilds. Maybe a link to servers with precompiled packages should be mentioned on www.gentoo.org.

Config files:
In progress: overwrite unchanged config files without asking. I think this helps a bit. Maybe the developers should write an update program, which copies the changed parts (e.g. keyboard layout, timezone, clock settings) to the new config files.

P.S.: i think, it is possible to setup an additional computer only for compiling ebuilds. This computer serves the precompiled packages. So a compiler is not nessecary on the servers.

Last edited by Keruskerfuerst on Mon Jan 22, 2007 12:33 pm; edited 4 times in total

When you install a server you expect to have running for a very long time and not to touch any configuration file unless absolutely necessary (security/bug related).

Gentoo requires a lot of time from admins, and non Gentoo guys won't be able to maintain the servers so it still a big risk compared to traditional RH, Debian or BSD*
That and the fact that having a compiler on a server is considered a potential security flaw._________________"Because two groups of consumers drive the absolute high end of home computing: the gamers and the porn surfers." /.
My gentoo projects, Kelogviewer and a QT4 gui for etc-proposals

I´m running two servers with gentoo.
Every week i update them like this:

"emerge -uvDp world"
pick the updates i really want

"emerge -v portage" (if neccessary)

"emerge -v some-ebuilds" (about 5-10 ebuilds)

"revdep-rebuild --pretend" (if i have merged some big stuff)

My servers stay on the bleeding edge where i want, if i want it. (e.g. test some new mailserver)
etc-update is rarely more than 10 files, but only 1-2 need to be altered, the rest is usually fine.
Never ever have i broke the system while updateing config files or "replacing the base-system". Updating the profiles have never resulted in downtime for me.

The whole process usually won´t take more than 15 mins of my time. While the system is compiling i can do some other stuff.
And no i don´t upgrade gcc with every emerge, and do something like "emerge -e world". I just don´t need to.

I´m very happy that gentoo won´t settle with a stable release, i want my packages fresh

I don't mean to nit pick, but shouldn't any updates to any production system be tested in a sandbox first, then applied to the production system once they are known to be complete, working and stable?

I know it means you can't do things the same way you might with RHEL for example, but this isn't RHEL, it's Gentoo and the whole concept is different. If you want to use it in a production environment, then certain protocols/methods have to be used if you don't want it to bite you in the ass.

If this means that it shouldn't be on a server, I don't know, but you should know wether or not you need the features only offered by Gentoo enough to make the other hoops you may have to jump through worthwile. If it's not worthwhile then it's not that 'gentoo-shouldnt-be-on-your-server', rather that 'gentoo-shouldnt-be-on-my-server'.

I do admit that most of the problems mentioned do exist, and it's a good article to read if you are considering a distro for a server, I just maintain that they are a trade offs against something else.

Maybe it's just because I have my own little way of maintaining Gentoo and keeping us both happy that I consider some of his arguments trivial, and some of his solutions a bit off the ball.(re-install from scratch, erm, that's on of the top 5 reasons why I use Gentoo, so I don't have to re-install, ever)

Last edited by pteppic on Mon Jan 22, 2007 1:36 pm; edited 1 time in total

I run a server on Gentoo too and it is perfect for my needs but in a professional dozens-of-servers-per-admin setup I would agree with him. However he seems to be mistaken about the profile updates. I never had those update anything that wasn't updated by normal emerge updates too. It just changes the default use flags and similar stuff so it isn't a big deal. baselayout updates are probably what he describes.

I trust gentoo, I run 6 fully up to date x86 and x86_64 servers 8 come mid March. I have been using gentoo for 3+ years now and like I said I trust the stable tree. For the most part I even stay up to date with gentoo-sources.. I run sync and -uDpN nightly in cron pipe it to an email then update each morning. Anything mission critical I update after hours. Distcc allows me to build pretty quickly. I don't run X and I use -* in my make.conf and use package.use for everything else. As the developers in my company always say during QA, "It works on my machine" or simply, "it works for me"

I run one SLES box and contract for a guy to maintain his two RedHat Boxes. I find gentoo much easier to maintain.. But to be fair I do not work all that much in these environments.

the short, opinions are like assh@$3s and everyone has one. Gentoo just works for me._________________write quit bang

I would never even think about to install gentoo for a production server that I don't want to touch/keep up to date besides security fixes. But if you want to run a bleeding edge server with all the new fancy stuff, you gotta have a great updatesystem like gentoo has. There is no distribution out that I know of, that is easier to upgrade (emerge) with the features (USE Flags) that I want to be included. This target doesn't meet the expectations of most enterprises of course, but it'll meet with the expectations of the common gentoo user._________________Antonino Catinello | http://catinello.eu

The best way to keep a system stable is to get it working and then not changing anything. This is hard with Gentoo. Gentoo wants you to change a lot of stuff. It wants to be bleeding edge.

One of the tricks that new Gentoo users often fail to figure out is how customizable Gentoo really is. It's especially common in review articles, that really only review the installation process and a quick survey of package management/eye-candy. It's very easy to think that just because a new package version goes stable, it should be emerged. Or, in the reviewer's assesment, must be emerged. Gentoo gives you the tools and the options. Upgrade if you want, or don't.

I'd never dream of updating a production server (or even production desktop) as often as portage is updated. I'd watch glsa daily, but beyond that, unless I wanted a new feature from a package, I wouldn't upgrade essential system elements without significant planning and research.

So, sure the reviewer is right that a bleeding edge system with a constantly evolving package-set is not an advisable server solution. However, I think he completely missed the boat on what's possible with Gentoo, probably because it's unlikely he spent enough time understanding the distribution.

Unfortunately that is not that true. This is true on a 6 month or so timeframe, but longer than than and old ebuild start to drop out... if you sync you can't rebuild your machine as-is anymore.
I had a server that I didn't not 'refresh' for a couple of year (I installed new packages, upgraded some others.. but never touched the toolchain, the kernel or any other core components)...
Well one day the 'profile' dropped out of portage... I was forced into a painful and broken upgrade, with stuff blocking left and right, requiring an awful lot of forum/google-digging.

I do still use gentoo for servers, but you just can install and forget. you have to keep them somewhat up-to-date. not on a daily basis, but at least follow the profile upgrade schedule... (that is a serious clean-up once or twice a year - which is not a bad idea anyway regardless of the distribution).

In my view, his goals (a faster server, despite old hardware) weren't a good match for Gentoo's strengths. Gentoo's strength isn't hardware performance optimization. Remember the "ricer" flame wars? Rather its strength is its flexible application configuration, which provides control over their dependencies.

In my experience Gentoo's "compile to upgrade, even fix security bugs" approach isn't a good fit for older, slower, hardware. Instead its ability to provide security enhanced application installations along with a minimal installed software footprint are great strengths for servers.

This is made possible by the magic of portage which provides for the configured elimination of unnecessary application features and their related dependencies at the time of server software build and installation. One weakness is having to cross-compile binary packages in order to remove the build tool chain from the server's application suite.

Yes, you pay for that flexibility, in that its harder to install and maintain Gentoo as a stable, secure, system, than some operating systems. Yet that isn't the entire story either, as to my thinking, secure, stable, servers aren't trivial affairs. They are generally high profile hacker targets with significant installation and ongoing installed software management needs and thus costs, both in terms of expertise and invested time.

My home network's server is an ancient Compaq 486 that is happily providing minimal mail and DNS services by running OpenBSD. Yet my workstation is an amd64 monster that happily dual boots windows XP (for World of Warcraft *sigh*) and Gentoo (stable x86 Linux) for everything else. My network serves my particular needs extremely well and yes Gentoo, albeit not as a server, is a critical component within that network.

Were my network's server's application suite more complex, with more severe security risks, and running on modern hardware, I'd definitely be taking another look at using Gentoo as its operating system._________________----- Glorandar

And a page on gentoo.org, like a little 80x 240 poll square, telling about stable/unstable - profile updates.. Maybe a clock ticking away until new 'big updates' so users/maintainers can prepare.

I especialy liked the comment of Dashnu, who mentioned -* in make.conf and management through package.use and package.keywords. Now that I'm using Gentoo over 2 years I'm also using make.conf use="" less and less, and start to use package.use and package.keywords more and more. (and of course I know -* is not al that smart and a good balance between systemwide useflags and package.use useflags is the golden road).

I really like the option button in Porthole that automagicaly adapts package.keywords to your needs! Wonderfull, such an option should there be for emerge and the use flags ^^ so that the useflags you chose from the command line in USE="" would be automagicaly saved in package.use! Death to systemwide useflags that screw up your system after an emerge world or emerge system when you forgot to put a useflag in package.use! (And yes that is a human-side fault but like laws, systems can change or be expanded/improved to deal with such things! Especialy for new gentoo users, which we love to have).

Ontopic:

The writer of the review is mentioning the right problems for the wrong reasons and I agree: he should take a better look at gentoo... When I first started, I had to reinstall a whole system because I was lost. Just takes time to get to know all the nifty up sides._________________Calling atheism a religion, is like calling bald a haircolour.

I don't mean to nit pick, but shouldn't any updates to any production system be tested in a sandbox first, then applied to the production system once they are known to be complete, working and stable?

With other distributions, this is expected from the developers. The case is different for Gentoo, which puts the admin in charge. But in the end, the big question is, how much you care about your production system, and how much time you're willing to spend on making it run smoothly. It's no matter which distribution is on it. If an admin is not willing to spend time on controlled updates, the chances are he doesn't care much for other aspects of running a production server either.

Sure with Gentoo you have only one version : stable, so it is easy and convenient to use it as a sandbox where you can test and precompile any package before deploying them.

The point is, you do not need to do it with others distro.

So, you thing that more work load and responsability is easy to take for an admin ?
If your gentoo server break after an update, Management can break hell on you, if your RHEL break you just pipe the shitstorm._________________"Because two groups of consumers drive the absolute high end of home computing: the gamers and the porn surfers." /.
My gentoo projects, Kelogviewer and a QT4 gui for etc-proposals

Over at www.zoto.com, we've got 16 gentoo servers in a rack in our colo, and another 5 dev/staging boxes running in our offices. I will admit that we've done our best to keep the hardware consistent so when it comes time to update, we just emerge once and ship binary packages around, but in a heterogeneous enviromment, I don't see it being much more difficult. Downtime is something that's going to happen to a box. I don't care what OS you run, it will happen. The trick is designing your infrastructure to handle it. Gentoo is a great OS for cluster environments. You just have to use a little forethought._________________To err is human; To really foul things up requires a computer.

"I run gentoo on my servers (3 of them), and yes Gentoo may be harmful if you don't know what you're doing. If you're the the kind of person who updates everyday, and stays bleeding edge, it's relatively easy to bring down your own server for a good couple of hours to a few days.

But if you have a good schedule for when you want to update your system, it's as good as any other linux distro out there. What this guy wanted was probably something like Redhat, or Debian (don't nitpick). I don't run enterprise servers, I run basic gaming/radio/website setups, the website server is updated once every 4 days, but I don't get a lot of traffic, and I can afford to have my system come down for a few hours while I figure out what is going wrong.

My gaming server is my testbed, since I update that once a day, if something goes wrong I don't mind digging into it to figure out what went wrong, this usually helps me keep the other sites from screwing up when they update, and I can troubleshoot problems on them before they happen.

Regardless of what you run, there is going to be downtime associated with your distro, and gentoo is no exception. If the guy who wrote this article had any experience with Gentoo, he'd know the hardships that come with it. I'd never reccommend someone to use Gentoo as their server operating system if they've never used it, even if they've had a few months using it, but that doesn't mean it's a bad choice for a server operating system."

I can imagine these forums are going to be slow for a while due to the slashdot effect _________________"If it moves, compile it."

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.

Rediulous post. I came across it on Slashdot. I'm happy to see that some of the comments (on Slashdot) are in favor of Gentoo.

Gentoo can definitely run on a server, and run well. I run Gentoo on a company development server and it works great. I run a script every day that syncs and runs glsa-check. Based on this a decide if I need to do any securoty updates or not. Other than that things stay mainly static. I can also alwyas count on my Gentoo server to get up to date if I need it to be, unlike other distros that may end support after a period of time.

Bottom line... you need to know how to use Gentoo if you want to put it on a server. I'm starting to get sick of people complaining about their terrible times with Gentoo, when it just seems that they really don't know enough about the administration of Gentoo.

BTW - If you don't want to do any compilation on the server, either use GRP releases, compile the packages in a staging environment, or use a portage BINHOST.

One of the tricks that new Gentoo users often fail to figure out is how customizable Gentoo really is.

Yes, indeed.

That's one of the biggest reasons to run Gentoo. As far as Gentoo on a server...it's certainly doable, but as always, certain precautions that are not specific to Gentoo need to be taken:

1. Always, ALWAYS, ALWAYS test ANY and ALL updates on NON-PRODUCTION machines before applying them to production machines.
2. Know what it is you are needing to update and why. If you don't have any better reason that "version X.Z is newer than X.Y," then don't do it.
3. If it ain't broke, don't fix it. Leave a well-running machine alone. (I consider security holes "broken.")
4. Always back up your data and preferably your OS too, so if your update goes badly on your production box for some reason, you can get back up and running pretty much where you left off in short order.
5. Don't run beta software on a server unless there is no other option. No ACCEPT_KEYWORDS="~arch" on the server, for God's sake!

If anybody follows those rules with any distribution or any OS, they should be fine. In my experience with Gentoo. updates can sometimes cause some little weird hiccups, but they are usually very fixable, unlike some binary distros. I generally get the fix quickly from looking on these forums as people who run ~arch systems run into them before I do. But one very good thing about Gentoo as far as making a server is that you only need to install exactly what you need to accomplish the task at hand. This is not necessarily doable with other distros. Gentoo is admittedly harder to admin than most other distros, but it's not all that hard and if you're a paid sysadmin, it shouldn't be too hard for you. I'm just an average schmuck and I get along just fine running Gentoo on two machines._________________Unix is user friendly- it is just picky who its friends are.

i have seven production servers running gentoo. and they are doing just fine.
i've chosen gentoo because of great and admin-friendly customization options.
we have failover setup, so for every upgrade i switch the site to run on primary machines only, update secondaries, do switch, if everything works for two-three days, i proceed with updating the rest of the servers.
i have two bootable installations on each machine, primary one getting updated every 6 months, secondary, also called 'emergency' - sitting there and ready for troubleshooting (never had to use it).
most of the time i'm 1000km or more away from the site itself, having 'hands on' option from BT i can still resolve most of the problems related to failing hardware.