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