Re: [gentoo-server] Server Packages for Gentoo

Re: [gentoo-server] Server Packages for Gentoo

[BRM]

How's this one?

Sorry about that - ( I tried something different this time, but for the most part...) unfortunately I can't do anything about it since it's Yahoo's webmail interface...Also why I'm not replying in-line, but at the top.

Ben



----- Original Message ----
From: Robert Bridge <robert@robbieab.com>
To: gentoo-server@lists.gentoo.org
Sent: Tuesday, September 30, 2008 1:28:46 PM
Subject: Re: [gentoo-server] Server Packages for Gentoo

On Tue, 30 Sep 2008 09:17:42 -0700 (PDT)
BRM <bm_witness@yahoo.com> wrote:

> That's a matter of choosing what you install; but that's not specific
> to Gentoo.
> 
> MySQL on Gentoo is not going to be any different than MySQL on RHEL
> or SLES. However, stability - due to differences in versions,
> patches, etc. - might be different; but should be close to the same.

Except the Gentoo version will move a lot faster, potentially causing
problems...

BRM: Can you please fix you mail client so it includes the in-reply-to
and/or references headers so that it stops spawning a new thread
every time you reply.

RE: [gentoo-server] Server Packages for Gentoo

[Spahn, Daniel]

----Original Message-----
From: BRM [mailto:bm_witness@yahoo.com]
Sent: Tuesday, September 30, 2008 1:36 PM
To: gentoo-server@lists.gentoo.org
Subject: Re: [gentoo-server] Server Packages for Gentoo

How's this one?

Sorry about that - ( I tried something different this time, but for the most part...) unfortunately I can't do anything about it since it's Yahoo's webmail interface...Also why I'm not replying in-line, but at the top.

Ben



----- Original Message ----
From: Robert Bridge <robert@robbieab.com>
To: gentoo-server@lists.gentoo.org
Sent: Tuesday, September 30, 2008 1:28:46 PM
Subject: Re: [gentoo-server] Server Packages for Gentoo

On Tue, 30 Sep 2008 09:17:42 -0700 (PDT)
BRM <bm_witness@yahoo.com> wrote:

> That's a matter of choosing what you install; but that's not specific
> to Gentoo.
>
> MySQL on Gentoo is not going to be any different than MySQL on RHEL
> or SLES. However, stability - due to differences in versions,
> patches, etc. - might be different; but should be close to the same.

Except the Gentoo version will move a lot faster, potentially causing
problems...

BRM: Can you please fix you mail client so it includes the in-reply-to
and/or references headers so that it stops spawning a new thread
every time you reply.


Now that I've seen some ideas, here is what I was thinking by enterprise-level software:

Software that is secure within its domain, dedicated to a function, runs lean and without bloat, stable, as isolated from the OS as possible, and scalable. Software in this class must be part of some kind of security monitoring/advisory system (i.e. GLSA). Here's what I mean by all this:

Secure within its domain means that it only get those privileges absolutely necessary to its function- it should not have to run as root, for example. It should be possible to isolate the security level of any given software package, and should not run as a user account with an easy-to-crack password.

Dedicated to a function means it should not try to do it all- a DHCP server should manage IP addresses, not try to be a DNS, database, firewall, and desktop widget all at once.

Running lean and without bloat means it should only use necessary resources- no memory holes to speak of, no extra features or gui's, if possible.

Stable obviously means not prone to crashing.

Isolated from the OS meaning that, when it does crash, it doesn't take the whole server with it- if it must crash, it should only affect its own domain, which should be easy to sanitize without requiring a server reboot (Linux does this very well natively anyway).

Scalable is just what it means- deployable to a group of users as easily as to just one user.

As a Linux server, the basic type is LAMP, which are packages that have a strong reputation. How about additional functions that a LAMP cannot handle? How about network-level authentication? I have read about the Linux version of AD, but I am more curious abobut experiences with the associated packages, as well as security and functionality weaknesses, as well as potential security oversights. Any thoughts?

Thanks!

Re: [gentoo-server] Server Packages for Gentoo

[Ajai Khattri]

On Tue, 30 Sep 2008, BRM wrote:

> unfortunately I can't do anything about it since it's Yahoo's webmail
> interface...Also why I'm not replying in-line, but at the top.

I believe that's simply called laziness. :-)



-- 
A

Re: [gentoo-server] Server Packages for Gentoo

[BRM]

Correction on that:

A "static package" is never for "security reasons". It's for "administration" reasons. Please don't confuse the two.

If someone was truly looking at the "security reasons", then they would try to stick with newer software - especially in the F/OSS world - since it nearly always fixes the older security issues (or at worse propagates them), usually gets the fixes faster, and even though it might introduce new issues, those issues are likely unknown to any.

Yes, the 'static package' issue is nice for administrators that don't want to upgrade software very often. But that really is not very good practice security wise.

Unfortunately, those same administrators are usually left without a choice as they are running other software that doesn't work with the newer software - whether it is something in-house or third-party. F/OSS usually overcomes that limitation a lot faster -- especially in the Gentoo world -- since software gets updated more often. If it's not the 'without a choice' issue, then its just laziness on their part since upgrading the software would benefit them in many respects.

RHEL/SLES are targeted more at the people that need that static packaging b/c of third party apps - not security.

As Kerin mentioned - those static packages may not get those security updates. In fact, they will likely miss a lot of updates - bug fixes (whether security or not) or minor security updates (that could be major!) that the static package vendor does not deem worthy enough to port. Worse yet, those static packages may have their own security flaws that are not in the main package due to those backports or other vendor mistakes. For example - the recent OpenSSL debacle on Debian.

My primary point here is that "static packages" are not for security reasons. Never has been and never will be. And anyone saying such is flat out lieing to you (knowingly or not) or at best propogating false information.

Now, the only real issue that you do raise is that yes, SLES/RHEL and others may for some be better because they provide a full compliment of already compiled libraries against a given compiler set; so you may not run into the _compilation_ side of the house that upgrading a compiler or library could run into. However, I would argue that that is likely a rare issue in the Gentoo world if you use the right profile, are careful of what you unmask, and you follow the recommended guidelines for using Gentoo on a production system - e.g. having your own portage mirror, and stage to a non-production system, and then after verification on the non-production system pushing to production. Those guidelines should be followed any way in a well designed production environment.

Ben


----- Original Message ----
From: Robert Bridge <robert@robbieab.com>
To: gentoo-server@lists.gentoo.org
Sent: Wednesday, October 1, 2008 10:34:04 AM
Subject: Re: [gentoo-server] Server Packages for Gentoo

On Wed, 1 Oct 2008 11:55:21 +0100
"Kerin Millar" <kerframil@gmail.com> wrote:

> Well, this post turned out to be a lot longer than I had anticipated.
> But I've seen so many comments that allude to Gentoo somehow being
> unfit for purpose because it doesn't freeze off a so-called "stable"
> tree so many times that, frankly, I get fed up with it and figured
> that something had to be said. Gentoo, whilst certainly having its
> fair share of foibles, doesn't get enough credit for the things that
> it does well and the things that it does right. If one doesn't like
> the way that Gentoo does things then there are surely other distros
> out there that will meet one's expectations, such as they are.

Right, imagine a live server getting hit by the expat problem, or a
major gcc/glibc change? They hurt, they seriously hurt.

That's what the "static package" people are referring to. A server that
can be set up, and once running should need minimal updating, for
security reasons. You can't do that safely in Gentoo.

Some people are happy with regularly changing packages, restarting
services every month because a new version of the server is in tree,
dealing with the breakage induced by things like python upgrades, bash
upgrades, portage upgrades, gcc upgrades, ... 

But for a 24/7 uptime on a high load server, most people consider those
to be unacceptable. Now Gentoo can be got to not do those, but as
anyone will tell you, updating a Gentoo box after a year is painful,
and when you have to update to cover a critical security hole? Now try updating a Debian box after a year?

Don't mistake one awkward piece of software which is not supported in
the other distros for the general properties of those distros. Gentoo
is good for tweaking, it's good for doing "Your own thing", that does
not make it automagically better than Debian or RHEL, or SLES in the
high-stability stakes. And, sorry to say this, one nice anecdote
doesn't either.

YMMV
Rob.

Re: [gentoo-server] Server Packages for Gentoo

[Arturo 'Buanzo' Busleiman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

BRM wrote:
> A "static package" is never for "security reasons". It's for "administration" reasons. Please don't confuse the two.

I deeply agree!

> If someone was truly looking at the "security reasons", then they would try to stick with newer software - especially in the F/OSS world - since it nearly always fixes the older security issues (or at worse propagates them), usually gets the fixes faster, and even though it might introduce new issues, those issues are likely unknown to any.

I'd like to add that the policy of using old, "verified", secure software is relatively flawed, as
every day we find methods to exploit coding vulnerabilities that were previously thought of as
"un-exploitable"...

- --
Arturo "Buanzo" Busleiman
Independent Linux and Security Consultant - SANS - OISSG - OWASP
http://www.buanzo.com.ar/pro/eng.html
Mailing List Archives at http://archiver.mailfighter.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI45LTAlpOsGhXcE0RCr/8AJ417MK1I6pjyVWw86cdqK8ny4Dt+QCePKur
YU/u2aLIE9lvJNo2uEFgBeM=
=7suo
-----END PGP SIGNATURE-----

Re: [gentoo-server] Server Packages for Gentoo

[BRM]

[-- Attachment #1: Type: text/plain, Size: 9793 bytes --]

Kerin -

Thanks for the great point-of-fact. And I honestly have to agree. Portage is certainly the reason I choose Gentoo for all my systems. It's just so much superior to anything else out there - in terms of use only Debian's system even comes close to comparing.

Ben


----- Original Message ----
From: Kerin Millar <kerframil@gmail.com>
To: gentoo-server@lists.gentoo.org
Sent: Wednesday, October 1, 2008 6:55:21 AM
Subject: Re: [gentoo-server] Server Packages for Gentoo


2008/9/30 Robert Bridge <robert@robbieab.com>

    On Tue, 30 Sep 2008 09:17:42 -0700 (PDT)
    BRM <bm_witness@yahoo.com> wrote:

    > That's a matter of choosing what you install; but that's not specific
    > to Gentoo.
    >
    > MySQL on Gentoo is not going to be any different than MySQL on RHEL
    > or SLES. However, stability - due to differences in versions,
    > patches, etc. - might be different; but should be close to the same.

Or better ...

    Except the Gentoo version will move a lot faster, potentially causing
    problems...

This is potentially true but (a) the term "problems" can be interpreted in different ways (b) it actually cuts both ways (warning: long anecdote follows before leading up to my point) ...

Recently I volunteered some time to help a friend deal with some serious issues he was having in running a popular community site. He'd recently migrated to a dedicated host running CentOS and had assumed that this would address all of the scalability issues he was encountering beforehand. In fact, the situation became worse. When I investigated I discovered that apache/mod_php was running the server into the ground, eventually causing the kernel's OOM killer to spring into action. This situation was not helped by the rather horrid bespoke configuration, with core software having been re-packaged adly by the ISP and effectively held together with rubber-bands and sticky tape. Simply put, it was a complete and utter mess and hopelessly unstable.

Due to the comparitively limited amount of physical RAM and the behaviour exhibited by apache, I suggested that he run lighttpd and php-cgi. I wasn't particularly suprised to find that CentOS did not have official packages and I had to resort to using third-party repositories containing hoplessly outdated packages to find what I needed (or face building from source). I was effectively fighting to be able to make the distro do what I wanted it to do.

After addressing that, he continued to encounter stability issues. I the suggested that he might consider moving to a more flexible distro with a broader range of packages on offer. After learning of the options made available to him by the ISP, the only one that seemed remotely palatable was Debian. He conducted a full re-installation accordingly, and I set up lighttpd, php5-cgi and a number of other components in the stack. Interestingly, not everything he wanted was available - namely the apc opcode cache. Cue messing around installing build-essential and a number of other dependencies manually before having to manually build apc from source.

Anyway, after setting everything up, things seemed to go well initially. But it wasn't before long before disaster struck - after a certain load various php-cgi processes would "run away" and consume inordinate amounts of processor time, with lighttpd unable to service further requests as a result. The only way to address the problem would be to run pkill -9 php5-cgi && pkill lighttpd. Worse, after doing so, the MySQL database that powered his backend would be subtly corrupted - enough to break the bulletin board software at the heart of the site! This would simply happen again and again.

I pursued every angle that I could possibly think of. This is where Debian started to seriously get in my way. I knew that it was a bug, but I hadn't yet identifed which. I wanted to update the key components in the stack to see if the problem had already been addressed. I pinned a newer version of lighttpd from lenny to no avail. I wanted to try a newer version of php but Debian simply does not offer an up-to-date package. Furthermore, it became apparent that "unmasking" (to use a Gentoo-centric term) new software in Debian is very much an all or nothing affair, which is decidedly not what I wanted.

To cut a long story short, I became throughly fed up with the situation and realised that something needed to be done. I therefore conducted a precarious - but ultimately successful - remote migration to Gentoo in-situ and, guess what? After setting up a lean and mean base system and installing lighttpd-1.4.19 and php-5.2.6 fresh out of portage, the site proceeded to work beautifully and without a hitch. And MySQL, which had been a CPU hog on Debian, now runs noticeably more efficiently. Incidentally, after doing a bit more digging I figured out that the system had probably been affected by PHP bug 40286 [1]. At the time of writing, Debian have done nothing about this bug [2] and, I suspect, not a greal deal concerning the 180 or so other bugs that have been fixed upstream in PHP since the 5.2.0 release.

Simply put, Gentoo enabled me to get to where we needed to go - on a fast track to stability no less. And it didn't get in my whilst doing it. In fact, it enabled me to simplify the complexity of the base system to a significant extent through the discriminating employment of USE flags. And, with fantastic components such as openrc/baselayout-2, eselect, webapp-config and, - not least - portage itself, it's a joy to manage.

In actual fact, the components of the base system are _not_ really updated all that often in Gentoo, despite a lot of nonsense that one often hears to the contrary. Since this deployment, there have been 3 minor package updates (one of which was a system package, man-pages) and - what do you know - today a new version of lighttpd is released which fixed 4 security bugs and it's already in the tree. I glanced over the upstream ChangeLog and had no hesitation in applying it to the system in question immediately. Incidentally, I wonder how long it will take the "enterprise" distros to backport the necessary fixes, assuming they even bother at all?

And this leads me up to the point I'm trying to make. There are other distros out there that like to position themselves as the natural choice for sysadmins who seek "stability" or require "enterprise" class packages. They would effectively have you believe that it's viable to run a bunch of frozen packages on a general-purpose system because they are doing the heavy lifting and claim to be backporting the fixes that matter. My view is that this is largely a sham  - there are countless security bugs are never backported, and that's before you even get to the non-security bugs that have a high impact.

Take the kernel for example - it's probably not an exaggeration to say that Gentoo has one of the most pro-actively maintained kernel patchsets around [3] in terms of maintaining branches that upstream like to drop like yesterday's bad news, largely thanks to the combined efforts of the kernel herd on genpatches [4], and the maintainer of hardened-extras. I'd invite anyone who doubts this to take a look at, say, the work that was done on the 2.6.23 branch of hardened-sources [5], above and beyond the related genpatches set, then to compare and contrast with your favourite "enterprise" distro and see exactly how good a job they are doing of looking after your interests. Sure, it's recently been dropped from the tree because we only have the manpower to maintain to maintain so many releases, but it's _still_ probably a far safer kernel than you're getting in the likes of RHEL or Debian! And I'm not even talking about the grsecurity/PaX related stuff here,
 but actual fixes that come from the stable-queue upstream or, in some cases, are not to be found in the stable queue at all (or are not submitted because upstream don't care anymore).

From my perspective, all these distros do is provide the illusion that you are safe in not pro-actively managing your system and completely avoiding the fact of the matter that, yes, there comes a time when software really should be upgraded. For pretty much all of the open-source software that I use on the backend, upgrades typically go very smoothly and fix a heck of a lot more than is ever broken.

Well, this post turned out to be a lot longer than I had anticipated. But I've seen so many comments that allude to Gentoo somehow being unfit for purpose because it doesn't freeze off a so-called "stable" tree so many times that, frankly, I get fed up with it and figured that something had to be said. Gentoo, whilst certainly having its fair share of foibles, doesn't get enough credit for the things that it does well and the things that it does right. If one doesn't like the way that Gentoo does things then there are surely other distros out there that will meet one's expectations, such as they are.

My take: Gentoo is so much more pleasant to manage and administer that I feel like a duck out of water whenever I'm charged with managing anything else. The technology is generally light-years ahead of its contemporaries and I honestly do sleep a lot easier at night knowing that my systems are powered by it. Finally, any extra time expended in managing it is for me (a) well within the margins of what I consider a reasonable amount of effort (b) time well spent (c) produces tangible benefits (more than I could possibly mention here).

Cheers,

--Kerin

[1] http://bugs.php.net/bug.php?id=40286
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431799
[3] http://bugs.gentoo.org/show_bug.cgi?id=185022#c3
[4] http://dev.gentoo.org/~dsd/genpatches/
[5] http://confucius.dh.bytemark.co.uk/~kerin.millar/trunk/2.6.23/

[-- Attachment #2: Type: text/html, Size: 11274 bytes --]

Re: [gentoo-server] Server Packages for Gentoo

[BRM]

That's a matter of choosing what you install; but that's not specific to Gentoo.

MySQL on Gentoo is not going to be any different than MySQL on RHEL or SLES.
However, stability - due to differences in versions, patches, etc. - might be different; but should be close to the same.

Ben



----- Original Message ----
From: Graham Murray <graham@gmurray.org.uk>
To: gentoo-server@lists.gentoo.org
Sent: Tuesday, September 30, 2008 11:05:08 AM
Subject: Re: [gentoo-server] Server Packages for Gentoo

BRM <bm_witness@yahoo.com> writes:

> Unless my understanding is wrong...
>
> The idea of 'enterprise-level' packages with respect to Linux is more
> or less stable packages over a long time period.

Why? Is it not be more a matter of scalability than stability? So that,
for example, an enterprise level database application might need to
handle tables with tens of millions of rows and thousands of
transactions per second. Or a file or email server be able to handle
tens of thousands of user accounts etc.

Re: [gentoo-server] Server Packages for Gentoo

[Robert Bridge]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

On Tue, 30 Sep 2008 09:17:42 -0700 (PDT)
BRM <bm_witness@yahoo.com> wrote:

> That's a matter of choosing what you install; but that's not specific
> to Gentoo.
> 
> MySQL on Gentoo is not going to be any different than MySQL on RHEL
> or SLES. However, stability - due to differences in versions,
> patches, etc. - might be different; but should be close to the same.

Except the Gentoo version will move a lot faster, potentially causing
problems...

BRM: Can you please fix you mail client so it includes the in-reply-to
and/or references headers so that it stops spawning a new thread
every time you reply.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-server] Server Packages for Gentoo

[Kerin Millar]

[-- Attachment #1: Type: text/plain, Size: 9313 bytes --]

2008/9/30 Robert Bridge <robert@robbieab.com>

    On Tue, 30 Sep 2008 09:17:42 -0700 (PDT)
    BRM <bm_witness@yahoo.com> wrote:

    > That's a matter of choosing what you install; but that's not specific
    > to Gentoo.
    >
    > MySQL on Gentoo is not going to be any different than MySQL on RHEL
    > or SLES. However, stability - due to differences in versions,
    > patches, etc. - might be different; but should be close to the same.

Or better ...

    Except the Gentoo version will move a lot faster, potentially causing
    problems...

This is potentially true but (a) the term "problems" can be interpreted in
different ways (b) it actually cuts both ways (warning: long anecdote
follows before leading up to my point) ...

Recently I volunteered some time to help a friend deal with some serious
issues he was having in running a popular community site. He'd recently
migrated to a dedicated host running CentOS and had assumed that this would
address all of the scalability issues he was encountering beforehand. In
fact, the situation became worse. When I investigated I discovered that
apache/mod_php was running the server into the ground, eventually causing
the kernel's OOM killer to spring into action. This situation was not helped
by the rather horrid bespoke configuration, with core software having been
re-packaged adly by the ISP and effectively held together with rubber-bands
and sticky tape. Simply put, it was a complete and utter mess and hopelessly
unstable.

Due to the comparitively limited amount of physical RAM and the behaviour
exhibited by apache, I suggested that he run lighttpd and php-cgi. I wasn't
particularly suprised to find that CentOS did not have official packages and
I had to resort to using third-party repositories containing hoplessly
outdated packages to find what I needed (or face building from source). I
was effectively fighting to be able to make the distro do what I wanted it
to do.

After addressing that, he continued to encounter stability issues. I the
suggested that he might consider moving to a more flexible distro with a
broader range of packages on offer. After learning of the options made
available to him by the ISP, the only one that seemed remotely palatable was
Debian. He conducted a full re-installation accordingly, and I set up
lighttpd, php5-cgi and a number of other components in the stack.
Interestingly, not everything he wanted was available - namely the apc
opcode cache. Cue messing around installing build-essential and a number of
other dependencies manually before having to manually build apc from source.

Anyway, after setting everything up, things seemed to go well initially. But
it wasn't before long before disaster struck - after a certain load various
php-cgi processes would "run away" and consume inordinate amounts of
processor time, with lighttpd unable to service further requests as a
result. The only way to address the problem would be to run pkill -9
php5-cgi && pkill lighttpd. Worse, after doing so, the MySQL database that
powered his backend would be subtly corrupted - enough to break the bulletin
board software at the heart of the site! This would simply happen again and
again.

I pursued every angle that I could possibly think of. This is where Debian
started to seriously get in my way. I knew that it was a bug, but I hadn't
yet identifed which. I wanted to update the key components in the stack to
see if the problem had already been addressed. I pinned a newer version of
lighttpd from lenny to no avail. I wanted to try a newer version of php but
Debian simply does not offer an up-to-date package. Furthermore, it became
apparent that "unmasking" (to use a Gentoo-centric term) new software in
Debian is very much an all or nothing affair, which is decidedly not what I
wanted.

To cut a long story short, I became throughly fed up with the situation and
realised that something needed to be done. I therefore conducted a
precarious - but ultimately successful - remote migration to Gentoo in-situ
and, guess what? After setting up a lean and mean base system and installing
lighttpd-1.4.19 and php-5.2.6 fresh out of portage, the site proceeded to
work beautifully and without a hitch. And MySQL, which had been a CPU hog on
Debian, now runs noticeably more efficiently. Incidentally, after doing a
bit more digging I figured out that the system had probably been affected by
PHP bug 40286 [1]. At the time of writing, Debian have done nothing about
this bug [2] and, I suspect, not a greal deal concerning the 180 or so other
bugs that have been fixed upstream in PHP since the 5.2.0 release.

Simply put, Gentoo enabled me to get to where we needed to go - on a fast
track to stability no less. And it didn't get in my whilst doing it. In
fact, it enabled me to simplify the complexity of the base system to a
significant extent through the discriminating employment of USE flags. And,
with fantastic components such as openrc/baselayout-2, eselect,
webapp-config and, - not least - portage itself, it's a joy to manage.

In actual fact, the components of the base system are _not_ really updated
all that often in Gentoo, despite a lot of nonsense that one often hears to
the contrary. Since this deployment, there have been 3 minor package updates
(one of which was a system package, man-pages) and - what do you know -
today a new version of lighttpd is released which fixed 4 security bugs and
it's already in the tree. I glanced over the upstream ChangeLog and had no
hesitation in applying it to the system in question immediately.
Incidentally, I wonder how long it will take the "enterprise" distros to
backport the necessary fixes, assuming they even bother at all?

And this leads me up to the point I'm trying to make. There are other
distros out there that like to position themselves as the natural choice for
sysadmins who seek "stability" or require "enterprise" class packages. They
would effectively have you believe that it's viable to run a bunch of frozen
packages on a general-purpose system because they are doing the heavy
lifting and claim to be backporting the fixes that matter. My view is that
this is largely a sham  - there are countless security bugs are never
backported, and that's before you even get to the non-security bugs that
have a high impact.

Take the kernel for example - it's probably not an exaggeration to say that
Gentoo has one of the most pro-actively maintained kernel patchsets around
[3] in terms of maintaining branches that upstream like to drop like
yesterday's bad news, largely thanks to the combined efforts of the kernel
herd on genpatches [4], and the maintainer of hardened-extras. I'd invite
anyone who doubts this to take a look at, say, the work that was done on the
2.6.23 branch of hardened-sources [5], above and beyond the related
genpatches set, then to compare and contrast with your favourite
"enterprise" distro and see exactly how good a job they are doing of looking
after your interests. Sure, it's recently been dropped from the tree because
we only have the manpower to maintain to maintain so many releases, but it's
_still_ probably a far safer kernel than you're getting in the likes of RHEL
or Debian! And I'm not even talking about the grsecurity/PaX related stuff
here, but actual fixes that come from the stable-queue upstream or, in some
cases, are not to be found in the stable queue at all (or are not submitted
because upstream don't care anymore).

From my perspective, all these distros do is provide the illusion that you
are safe in not pro-actively managing your system and completely avoiding
the fact of the matter that, yes, there comes a time when software really
should be upgraded. For pretty much all of the open-source software that I
use on the backend, upgrades typically go very smoothly and fix a heck of a
lot more than is ever broken.

Well, this post turned out to be a lot longer than I had anticipated. But
I've seen so many comments that allude to Gentoo somehow being unfit for
purpose because it doesn't freeze off a so-called "stable" tree so many
times that, frankly, I get fed up with it and figured that something had to
be said. Gentoo, whilst certainly having its fair share of foibles, doesn't
get enough credit for the things that it does well and the things that it
does right. If one doesn't like the way that Gentoo does things then there
are surely other distros out there that will meet one's expectations, such
as they are.

My take: Gentoo is so much more pleasant to manage and administer that I
feel like a duck out of water whenever I'm charged with managing anything
else. The technology is generally light-years ahead of its contemporaries
and I honestly do sleep a lot easier at night knowing that my systems are
powered by it. Finally, any extra time expended in managing it is for me (a)
well within the margins of what I consider a reasonable amount of effort (b)
time well spent (c) produces tangible benefits (more than I could possibly
mention here).

Cheers,

--Kerin

[1] http://bugs.php.net/bug.php?id=40286
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431799
[3] http://bugs.gentoo.org/show_bug.cgi?id=185022#c3
[4] http://dev.gentoo.org/~dsd/genpatches/
[5] http://confucius.dh.bytemark.co.uk/~kerin.millar/trunk/2.6.23/

[-- Attachment #2: Type: text/html, Size: 10306 bytes --]

Re: [gentoo-server] Server Packages for Gentoo

[Robert Bridge]

[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]

On Wed, 1 Oct 2008 11:55:21 +0100
"Kerin Millar" <kerframil@gmail.com> wrote:

> Well, this post turned out to be a lot longer than I had anticipated.
> But I've seen so many comments that allude to Gentoo somehow being
> unfit for purpose because it doesn't freeze off a so-called "stable"
> tree so many times that, frankly, I get fed up with it and figured
> that something had to be said. Gentoo, whilst certainly having its
> fair share of foibles, doesn't get enough credit for the things that
> it does well and the things that it does right. If one doesn't like
> the way that Gentoo does things then there are surely other distros
> out there that will meet one's expectations, such as they are.

Right, imagine a live server getting hit by the expat problem, or a
major gcc/glibc change? They hurt, they seriously hurt.

That's what the "static package" people are referring to. A server that
can be set up, and once running should need minimal updating, for
security reasons. You can't do that safely in Gentoo.

Some people are happy with regularly changing packages, restarting
services every month because a new version of the server is in tree,
dealing with the breakage induced by things like python upgrades, bash
upgrades, portage upgrades, gcc upgrades, ... 

But for a 24/7 uptime on a high load server, most people consider those
to be unacceptable. Now Gentoo can be got to not do those, but as
anyone will tell you, updating a Gentoo box after a year is painful,
and when you have to update to cover a critical security hole? Now try updating a Debian box after a year?

Don't mistake one awkward piece of software which is not supported in
the other distros for the general properties of those distros. Gentoo
is good for tweaking, it's good for doing "Your own thing", that does
not make it automagically better than Debian or RHEL, or SLES in the
high-stability stakes. And, sorry to say this, one nice anecdote
doesn't either.

YMMV
Rob.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

RE: [gentoo-server] Server Packages for Gentoo

[Spahn, Daniel]

As the one who started this thread, it probably makes sense for me to comment on this a bit, because I agree. Gentoo is a distribution that has a utopian (IMHO) mixture of flexibility and compatibility. It is designed to accommodate such a wide variety of applications, that mailing lists like this one are necessary for certain niches. I would choose Gentoo for a server OS because it is so deeply compatible with hardware, and because of the package management system. Many on this thread have complained about Portage in a server environment, but the default installation only requires the initial emerge --sync- there's no emerge system or emerge world that is mandated or automated. Packages can be masked or blocked at the package level, or the machine level, and it is relatively easy to set up a local rsync mirror to update emerge, which can then be a point of control for all servers on the network, if they are properly configured. I started this thread, not because Gentoo is not ready for the server room, but because I need to learn more before I set it up for server applications. I have experimented with Redhat, CentOS, FC, Arch, DSL, Mandrake/Mandriva, Debian, FreeBSD, and some other distros, but Gentoo has always been the best when applied to my methods and standards. That's why I ask such questions- I need to identify my weak areas to leverage Gentoo's strong ones.

Dan

Computer Systems Manager

-----Original Message-----
From: Robert Bridge [mailto:robert@robbieab.com]
Sent: Wednesday, October 01, 2008 10:34 AM
To: gentoo-server@lists.gentoo.org
Subject: Re: [gentoo-server] Server Packages for Gentoo

On Wed, 1 Oct 2008 11:55:21 +0100
"Kerin Millar" <kerframil@gmail.com> wrote:

> Well, this post turned out to be a lot longer than I had anticipated.
> But I've seen so many comments that allude to Gentoo somehow being
> unfit for purpose because it doesn't freeze off a so-called "stable"
> tree so many times that, frankly, I get fed up with it and figured
> that something had to be said. Gentoo, whilst certainly having its
> fair share of foibles, doesn't get enough credit for the things that
> it does well and the things that it does right. If one doesn't like
> the way that Gentoo does things then there are surely other distros
> out there that will meet one's expectations, such as they are.

Right, imagine a live server getting hit by the expat problem, or a
major gcc/glibc change? They hurt, they seriously hurt.

That's what the "static package" people are referring to. A server that
can be set up, and once running should need minimal updating, for
security reasons. You can't do that safely in Gentoo.

Some people are happy with regularly changing packages, restarting
services every month because a new version of the server is in tree,
dealing with the breakage induced by things like python upgrades, bash
upgrades, portage upgrades, gcc upgrades, ...

But for a 24/7 uptime on a high load server, most people consider those
to be unacceptable. Now Gentoo can be got to not do those, but as
anyone will tell you, updating a Gentoo box after a year is painful,
and when you have to update to cover a critical security hole? Now try updating a Debian box after a year?

Don't mistake one awkward piece of software which is not supported in
the other distros for the general properties of those distros. Gentoo
is good for tweaking, it's good for doing "Your own thing", that does
not make it automagically better than Debian or RHEL, or SLES in the
high-stability stakes. And, sorry to say this, one nice anecdote
doesn't either.

YMMV
Rob.

Re: [gentoo-server] Server Packages for Gentoo

[Kerin Millar]

2008/10/1 Robert Bridge <robert@robbieab.com>:
> Right, imagine a live server getting hit by the expat problem, or a
> major gcc/glibc change? They hurt, they seriously hurt.

Well, allow me to retort. How exactly does a glibc upgrade break
anything? I've used gentoo for a long time and have not had a glibc
upgrade break anything once. Not ever. Nor have I ever encountered
anyone that has claimed a glibc upgrade to break anything. Downgrades
are a different matter, as is well known.

As for gcc updates, the only occasion that I recall there being any
significant migration issue was the C++ ABI change between gcc-3.3 and
gcc-3.4. Allow me to point out then:

* The change was documented and a migration procedure presented
* Upgrading gcc between anything but a minor point release in gentoo
does _not_ then make it the default compiler (the user must run
gcc-config to switch and source /etc/profile to activate the new
compiler). In fact, the process of upgrading has _no_ effect
whatsoever in itself.
* Nobody is forcing you to upgrade. Hey, I still run my hardened
systems on gcc-3.4.6 and they work fine.

And, even where there are major changes in the base system and uptime
is of importance, how hard is to roll a new chroot with
FEATURES="buildpkg" then simply replace the host system based on the
generated packages? I've counselled many users over the years via IRC
(usually the kind who don't like to upgrade things for a protracted
period and are this in a self-induced quandary) with a 100% success
rate, every single time. This is not an idle boast, this is a fact.

>
> That's what the "static package" people are referring to. A server that
> can be set up, and once running should need minimal updating, for
> security reasons. You can't do that safely in Gentoo.

Which security reasons exactly? How exactly are the majority of
security bugs that are continuously found to be mitigated without
software being updated by some means?

>
> Some people are happy with regularly changing packages, restarting
> services every month because a new version of the server is in tree,
> dealing with the breakage induced by things like python upgrades, bash
> upgrades, portage upgrades, gcc upgrades, ...

Are you seriously stating that there are gcc, python, bash and portage
upgrades - all of which you say are breaking - every month or are we
verging on unsubstantiated hyperbole here? I've already touched upon
the topic of gcc. When was the last time a bash upgrade broke your
system? How about portage?

As for python, I wasn't aware that major new point releases of python
were forthcoming on a monthly basis - that's news to me. The upgrade
process turned out to be trivial for me. It's even easier if you keep
a chroot handy for testing and with which to generate binary packages
that can be immediately consumed by any system that needs migrating.
Or you could just mask python-2.5 until such time as you feel like
upgrading. Really ... it's not that bloody hard.

>
> But for a 24/7 uptime on a high load server, most people consider those
> to be unacceptable. Now Gentoo can be got to not do those, but as
> anyone will tell you, updating a Gentoo box after a year is painful,
> and when you have to update to cover a critical security hole? Now try updating a Debian box after a year?

Yes, I realise that some environments enforce such constraints.
Personally, I have absolutely no problem maintaining an acceptable
level of uptime with my servers using Gentoo. And, as I alluded to
earlier, I've managed to help people update systems that are years out
of date with ease. It's a different process, granted, and it may not
seem as intuitive to one man as it does to another. But don't tell me
that it can't be done because it's simply not true. If I wanted to run
Gentoo for a whole year without shutting down a single service or
issuing a single reboot, I would have absolutely no qualms in doing
so.

The uptime argument is particularly pertinent as far as kernel
upgrades are concerned and this is something that affects all distros.
Frankly, I'd rather have frequent kernel updates that close as many
security holes as possible than none. It's ultimately up to me as to
whether I want to consume these updates anyway.

>
> Don't mistake one awkward piece of software which is not supported in
> the other distros for the general properties of those distros. Gentoo
> is good for tweaking, it's good for doing "Your own thing", that does
> not make it automagically better than Debian or RHEL, or SLES in the
> high-stability stakes. And, sorry to say this, one nice anecdote
> doesn't either.

I'm glad you thought the anectode was nice - there are plenty more
where that came from :) Seriously though, I consider the packages in
Gentoo to exhibit much greater stability in terms of exhibiting
performant and bug-free operation and am very happy with it. I concur
that there is no single property of a given distro that makes it
automatically "better" or "worse" than another. Yet there is a lot of
unsubstantiated bullshit that gets bandied around about Gentoo, and
other systems are seldom called out on their weaknesses. If Debian,
RHEL or SLES suit anyone else's needs better than great. I still stand
by my original post and am delighted to be doing my "own thing", as
you put it. To each their own.

Cheers,

--Kerin

Re: [gentoo-server] Server Packages for Gentoo

[Pavel Labushev]

Robert Bridge пишет:

> That's what the "static package" people are referring to. A server that
> can be set up, and once running should need minimal updating, for
> security reasons.

What security reasons are you talking about? Hardened Gentoo is the most 
secure linux distribution available.

> You can't do that safely in Gentoo.

You can't do exactly that. But that's not the only way. With Gentoo, you 
can do another things to make your servers reliable and secure.

> Some people are happy with regularly changing packages, restarting
> services every month because a new version of the server is in tree,
> dealing with the breakage induced by things like python upgrades, bash
> upgrades, portage upgrades, gcc upgrades, ... 

Some people do their job. And that people has no in-production problems 
*at all* regarding changes in the tree.

> But for a 24/7 uptime on a high load server, most people consider those

For a 24/7 uptime on a high load server, some people consider 
reliability through redundancy, stress and regress pre-production 
testing, dedicated and secure chroot environments for every sinlge 
service with minimal amount of packages and enabled USE flags, and so on...

> to be unacceptable. Now Gentoo can be got to not do those, but as
> anyone will tell you, updating a Gentoo box after a year is painful,

Don't do full update at once after a year.

> and when you have to update to cover a critical security hole? Now try updating a Debian box after a year?

Debian and security... Hmmm...

> Don't mistake one awkward piece of software which is not supported in
> the other distros for the general properties of those distros. Gentoo
> is good for tweaking, it's good for doing "Your own thing", that does

Gentoo is good for people who care to invest their time and effort 
instead of whining.

> not make it automagically better than Debian or RHEL, or SLES in the
> high-stability stakes.

Gentoo is absolutely better for me.

Re: [gentoo-server] Server Packages for Gentoo

[kashani]

Robert Bridge wrote:
> On Wed, 1 Oct 2008 11:55:21 +0100
> "Kerin Millar" <kerframil@gmail.com> wrote:
> 
>> Well, this post turned out to be a lot longer than I had anticipated.
>> But I've seen so many comments that allude to Gentoo somehow being
>> unfit for purpose because it doesn't freeze off a so-called "stable"
>> tree so many times that, frankly, I get fed up with it and figured
>> that something had to be said. Gentoo, whilst certainly having its
>> fair share of foibles, doesn't get enough credit for the things that
>> it does well and the things that it does right. If one doesn't like
>> the way that Gentoo does things then there are surely other distros
>> out there that will meet one's expectations, such as they are.
> 
> Right, imagine a live server getting hit by the expat problem, or a
> major gcc/glibc change? They hurt, they seriously hurt.

Unless you tested them on your test box.

> That's what the "static package" people are referring to. A server that
> can be set up, and once running should need minimal updating, for
> security reasons. You can't do that safely in Gentoo.

Been doing it for six years in production.

> Some people are happy with regularly changing packages, restarting
> services every month because a new version of the server is in tree,
> dealing with the breakage induced by things like python upgrades, bash
> upgrades, portage upgrades, gcc upgrades, ... 

Or not dealing with any breakages because we did our jobs as admins and 
wrote up an actual upgrade plan which we then tested on staging. Which 
is the same thing anyone who does not want an outage does whether it's 
Gentoo, Oracle, RHEL, Cisco, Windows, whatever. People who take their 
distros word for anything eventually have outages.

> But for a 24/7 uptime on a high load server, most people consider those
> to be unacceptable. Now Gentoo can be got to not do those, but as
> anyone will tell you, updating a Gentoo box after a year is painful,
> and when you have to update to cover a critical security hole? Now try updating a Debian box after a year?

Don't wait a year to apply updates?

> Don't mistake one awkward piece of software which is not supported in
> the other distros for the general properties of those distros. Gentoo
> is good for tweaking, it's good for doing "Your own thing", that does
> not make it automagically better than Debian or RHEL, or SLES in the
> high-stability stakes. And, sorry to say this, one nice anecdote
> doesn't either.

http://forums.gentoo.org/viewtopic-t-504541.html

One of the strengths that people tend to miss.
	"Where Gentoo has really shines is in projects that fail. No really. 
We've all done that "hey lets try upgrading to Apache 2.2 and see how 
well it works." In Gentoo you change a few lines, emerge apache, run 
some tests, realize it's not quite there, change a few lines, emerge 
apache again, and you're back to where you started. Total time about two 
hours.
Or even projects that go somewhere. "Hey I need X packages for testing." 
Gentoo installs, some minor tweaks, and hand off to the dev. When we go 
to production I know I can get the same package because I let Gentoo do 
the work rather than half ass a build because I didn't have time for non 
production issues when the project had no priority. Naturally there some 
changes in config in production, but we can go to production faster 
without having to repackage, re QA, and then release. "

kashani

Re: [gentoo-server] Server Packages for Gentoo

[BRM]

Unless my understanding is wrong...

The idea of 'enterprise-level' packages with respect to Linux is more or less stable packages over a long time period.
However, this requires a lot longer period than is typical to Gentoo to my understanding as Gentoo typically moves packages through to being updated more frequently.

But to find what you are looking for (again if my understanding is correct) one would normally setup their own portage mirror, and maintain their own derivative profiles - marking items as masked until they have passed their own internal testing - e.g. the 'gentoo->staging->production' recommended cycle.

I am also thinking the closest profile to what you are looking for is probably the 'hardened' profile, which does lead me to a related question (for everyone) that I have been thinking about asking:

the 'server' profile has notes about only being for certain users; and recommends the 'hardened' profile for servers. Does the 'hardened' profile require use of SELinux or similar auditing/permission tools (e.g. AppArmor)? I'm currently using 'server' on my own server at home; but have not gotten to the point of being ready to try SELinux, etc - namely b/c I still have a lot software to install and configure, etc - so I haven't tried to move to the 'hardened' profile. So I'm wondering what all the differences are between 'hardened' and 'server' - I primarily figured it was more for the SELinux/AppArmor users. Please advise.

Again, I could be wrong - so anyone please chime in to correct me.

HTH,

Ben



----- Original Message ----
From: Ramon van Alteren <ramon@vanalteren.nl>
To: gentoo-server@lists.gentoo.org
Sent: Tuesday, September 30, 2008 4:28:35 AM
Subject: Re: [gentoo-server] Server Packages for Gentoo

Spahn, Daniel wrote:
> Is there a list of enterprise-level server packages for Gentoo somewhere?

As opposed to the h@x0r l33t software list :-)

I wouldn't know how to qualify software into enterprise-level server
packages and non enterprise-level server packages.


If you're looking for a specific package, try packages.gentoo.org

Ramon

Re: [gentoo-server] Server Packages for Gentoo

[Graham Murray]

BRM <bm_witness@yahoo.com> writes:

> Unless my understanding is wrong...
>
> The idea of 'enterprise-level' packages with respect to Linux is more
> or less stable packages over a long time period.

Why? Is it not be more a matter of scalability than stability? So that,
for example, an enterprise level database application might need to
handle tables with tens of millions of rows and thousands of
transactions per second. Or a file or email server be able to handle
tens of thousands of user accounts etc.

[gentoo-server] Server Packages for Gentoo

[Spahn, Daniel]

[-- Attachment #1: Type: text/plain, Size: 119 bytes --]

Is there a list of enterprise-level server packages for Gentoo somewhere?
Thanks!

Dan
Computer Systems Manager


[-- Attachment #2: Type: text/html, Size: 2118 bytes --]

Re: [gentoo-server] Server Packages for Gentoo

[Ramon van Alteren]

Spahn, Daniel wrote:
> Is there a list of enterprise-level server packages for Gentoo somewhere?

As opposed to the h@x0r l33t software list :-)

I wouldn't know how to qualify software into enterprise-level server
packages and non enterprise-level server packages.


If you're looking for a specific package, try packages.gentoo.org

Ramon