Gentoo Archives: gentoo-server

From: Kerin Millar <kerframil@×××××.com>
To: gentoo-server@l.g.o
Subject: Re: [gentoo-server] Server Packages for Gentoo
Date: Wed, 01 Oct 2008 10:55:25
Message-Id: 279fbba40810010355q5da249b0k47edad2306422afc@mail.gmail.com
In Reply to: Re: [gentoo-server] Server Packages for Gentoo by Robert Bridge
1 2008/9/30 Robert Bridge <robert@××××××××.com>
2
3 On Tue, 30 Sep 2008 09:17:42 -0700 (PDT)
4 BRM <bm_witness@×××××.com> wrote:
5
6 > That's a matter of choosing what you install; but that's not specific
7 > to Gentoo.
8 >
9 > MySQL on Gentoo is not going to be any different than MySQL on RHEL
10 > or SLES. However, stability - due to differences in versions,
11 > patches, etc. - might be different; but should be close to the same.
12
13 Or better ...
14
15 Except the Gentoo version will move a lot faster, potentially causing
16 problems...
17
18 This is potentially true but (a) the term "problems" can be interpreted in
19 different ways (b) it actually cuts both ways (warning: long anecdote
20 follows before leading up to my point) ...
21
22 Recently I volunteered some time to help a friend deal with some serious
23 issues he was having in running a popular community site. He'd recently
24 migrated to a dedicated host running CentOS and had assumed that this would
25 address all of the scalability issues he was encountering beforehand. In
26 fact, the situation became worse. When I investigated I discovered that
27 apache/mod_php was running the server into the ground, eventually causing
28 the kernel's OOM killer to spring into action. This situation was not helped
29 by the rather horrid bespoke configuration, with core software having been
30 re-packaged adly by the ISP and effectively held together with rubber-bands
31 and sticky tape. Simply put, it was a complete and utter mess and hopelessly
32 unstable.
33
34 Due to the comparitively limited amount of physical RAM and the behaviour
35 exhibited by apache, I suggested that he run lighttpd and php-cgi. I wasn't
36 particularly suprised to find that CentOS did not have official packages and
37 I had to resort to using third-party repositories containing hoplessly
38 outdated packages to find what I needed (or face building from source). I
39 was effectively fighting to be able to make the distro do what I wanted it
40 to do.
41
42 After addressing that, he continued to encounter stability issues. I the
43 suggested that he might consider moving to a more flexible distro with a
44 broader range of packages on offer. After learning of the options made
45 available to him by the ISP, the only one that seemed remotely palatable was
46 Debian. He conducted a full re-installation accordingly, and I set up
47 lighttpd, php5-cgi and a number of other components in the stack.
48 Interestingly, not everything he wanted was available - namely the apc
49 opcode cache. Cue messing around installing build-essential and a number of
50 other dependencies manually before having to manually build apc from source.
51
52 Anyway, after setting everything up, things seemed to go well initially. But
53 it wasn't before long before disaster struck - after a certain load various
54 php-cgi processes would "run away" and consume inordinate amounts of
55 processor time, with lighttpd unable to service further requests as a
56 result. The only way to address the problem would be to run pkill -9
57 php5-cgi && pkill lighttpd. Worse, after doing so, the MySQL database that
58 powered his backend would be subtly corrupted - enough to break the bulletin
59 board software at the heart of the site! This would simply happen again and
60 again.
61
62 I pursued every angle that I could possibly think of. This is where Debian
63 started to seriously get in my way. I knew that it was a bug, but I hadn't
64 yet identifed which. I wanted to update the key components in the stack to
65 see if the problem had already been addressed. I pinned a newer version of
66 lighttpd from lenny to no avail. I wanted to try a newer version of php but
67 Debian simply does not offer an up-to-date package. Furthermore, it became
68 apparent that "unmasking" (to use a Gentoo-centric term) new software in
69 Debian is very much an all or nothing affair, which is decidedly not what I
70 wanted.
71
72 To cut a long story short, I became throughly fed up with the situation and
73 realised that something needed to be done. I therefore conducted a
74 precarious - but ultimately successful - remote migration to Gentoo in-situ
75 and, guess what? After setting up a lean and mean base system and installing
76 lighttpd-1.4.19 and php-5.2.6 fresh out of portage, the site proceeded to
77 work beautifully and without a hitch. And MySQL, which had been a CPU hog on
78 Debian, now runs noticeably more efficiently. Incidentally, after doing a
79 bit more digging I figured out that the system had probably been affected by
80 PHP bug 40286 [1]. At the time of writing, Debian have done nothing about
81 this bug [2] and, I suspect, not a greal deal concerning the 180 or so other
82 bugs that have been fixed upstream in PHP since the 5.2.0 release.
83
84 Simply put, Gentoo enabled me to get to where we needed to go - on a fast
85 track to stability no less. And it didn't get in my whilst doing it. In
86 fact, it enabled me to simplify the complexity of the base system to a
87 significant extent through the discriminating employment of USE flags. And,
88 with fantastic components such as openrc/baselayout-2, eselect,
89 webapp-config and, - not least - portage itself, it's a joy to manage.
90
91 In actual fact, the components of the base system are _not_ really updated
92 all that often in Gentoo, despite a lot of nonsense that one often hears to
93 the contrary. Since this deployment, there have been 3 minor package updates
94 (one of which was a system package, man-pages) and - what do you know -
95 today a new version of lighttpd is released which fixed 4 security bugs and
96 it's already in the tree. I glanced over the upstream ChangeLog and had no
97 hesitation in applying it to the system in question immediately.
98 Incidentally, I wonder how long it will take the "enterprise" distros to
99 backport the necessary fixes, assuming they even bother at all?
100
101 And this leads me up to the point I'm trying to make. There are other
102 distros out there that like to position themselves as the natural choice for
103 sysadmins who seek "stability" or require "enterprise" class packages. They
104 would effectively have you believe that it's viable to run a bunch of frozen
105 packages on a general-purpose system because they are doing the heavy
106 lifting and claim to be backporting the fixes that matter. My view is that
107 this is largely a sham - there are countless security bugs are never
108 backported, and that's before you even get to the non-security bugs that
109 have a high impact.
110
111 Take the kernel for example - it's probably not an exaggeration to say that
112 Gentoo has one of the most pro-actively maintained kernel patchsets around
113 [3] in terms of maintaining branches that upstream like to drop like
114 yesterday's bad news, largely thanks to the combined efforts of the kernel
115 herd on genpatches [4], and the maintainer of hardened-extras. I'd invite
116 anyone who doubts this to take a look at, say, the work that was done on the
117 2.6.23 branch of hardened-sources [5], above and beyond the related
118 genpatches set, then to compare and contrast with your favourite
119 "enterprise" distro and see exactly how good a job they are doing of looking
120 after your interests. Sure, it's recently been dropped from the tree because
121 we only have the manpower to maintain to maintain so many releases, but it's
122 _still_ probably a far safer kernel than you're getting in the likes of RHEL
123 or Debian! And I'm not even talking about the grsecurity/PaX related stuff
124 here, but actual fixes that come from the stable-queue upstream or, in some
125 cases, are not to be found in the stable queue at all (or are not submitted
126 because upstream don't care anymore).
127
128 From my perspective, all these distros do is provide the illusion that you
129 are safe in not pro-actively managing your system and completely avoiding
130 the fact of the matter that, yes, there comes a time when software really
131 should be upgraded. For pretty much all of the open-source software that I
132 use on the backend, upgrades typically go very smoothly and fix a heck of a
133 lot more than is ever broken.
134
135 Well, this post turned out to be a lot longer than I had anticipated. But
136 I've seen so many comments that allude to Gentoo somehow being unfit for
137 purpose because it doesn't freeze off a so-called "stable" tree so many
138 times that, frankly, I get fed up with it and figured that something had to
139 be said. Gentoo, whilst certainly having its fair share of foibles, doesn't
140 get enough credit for the things that it does well and the things that it
141 does right. If one doesn't like the way that Gentoo does things then there
142 are surely other distros out there that will meet one's expectations, such
143 as they are.
144
145 My take: Gentoo is so much more pleasant to manage and administer that I
146 feel like a duck out of water whenever I'm charged with managing anything
147 else. The technology is generally light-years ahead of its contemporaries
148 and I honestly do sleep a lot easier at night knowing that my systems are
149 powered by it. Finally, any extra time expended in managing it is for me (a)
150 well within the margins of what I consider a reasonable amount of effort (b)
151 time well spent (c) produces tangible benefits (more than I could possibly
152 mention here).
153
154 Cheers,
155
156 --Kerin
157
158 [1] http://bugs.php.net/bug.php?id=40286
159 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431799
160 [3] http://bugs.gentoo.org/show_bug.cgi?id=185022#c3
161 [4] http://dev.gentoo.org/~dsd/genpatches/
162 [5] http://confucius.dh.bytemark.co.uk/~kerin.millar/trunk/2.6.23/

Replies

Subject Author
Re: [gentoo-server] Server Packages for Gentoo Robert Bridge <robert@××××××××.com>