I'm one of many RedHat orphans looking for a new home now that support for
my old RH 7.3 distro is ending at the end of the year. I'm trying to find a
new distro to replace it, and I'm mainly eyeing Debian and Fedora.

The box we're running is a mainly an e-mail, web, and RealAudio server. For
that reason, a lot of the bells and whistles that come with most distros
(this box will probably sit in a corner and never run XWindows at all), but
I probably want enough newer features (including a 2.4 kernel) that if I'm
going to go with Debian, it will probably be the "testing" (sarge) release
rather than "stable" (woody).

One of the biggest factors for picking a distro for our situation will be
will be timely bugfixes and security patches.

I'm familiar with RedHat's up2date system, and it seems like they've
generally been pretty good getting patches and fixes done within a day or
two of an incident report. I wonder if someone could tell me how Debian
handles security patches.

Specifically, if I understand their website correctly, security patches are
first done for "stable", then applied to "unstable" as time and resources
permit. When do patches get applied to "testing"? Pretty quickly? Or only
after they've been in the "unstable" release for a while?

To put it another way, if another OpenSSH vulnerability is discovered and
I'm running "testing", how long would it take before an updated package
would be available for downloading and installing?

And if timely security patches are important to us, should I be using a
different release? Or a different distro altogether?

Thanks to anyone who can help!

In article <bpdl1001tmj@enews1.newsguy.com>, George Adams wrote:
> I'm one of many RedHat orphans looking for a new home now that support for
> my old RH 7.3 distro is ending at the end of the year. I'm trying to find a
> new distro to replace it, and I'm mainly eyeing Debian and Fedora.
>
> The box we're running is a mainly an e-mail, web, and RealAudio server. For
> that reason, a lot of the bells and whistles that come with most distros
> (this box will probably sit in a corner and never run XWindows at all), but
> I probably want enough newer features (including a 2.4 kernel) that if I'm
> going to go with Debian, it will probably be the "testing" (sarge) release
> rather than "stable" (woody).

Don't jump to conclusions. The Woody install disks (3.0r1) come with
a 2.4.18 kernel with security fixes since then backported.
And if you don't like that, you can always build your own.
Most of my Woody boxes are running 2.4.22. I don't bother to
"debianize" my kernels because I don't distribute them.

Woody 3.0r2 will be released this week.

>
> One of the biggest factors for picking a distro for our situation will be
> will be timely bugfixes and security patches.

Then I think your best choices are Woody and OpenBSD.


> I'm familiar with RedHat's up2date system, and it seems like they've
> generally been pretty good getting patches and fixes done within a day or
> two of an incident report. I wonder if someone could tell me how Debian
> handles security patches.

It's equally timely.


> Specifically, if I understand their website correctly, security patches are
> first done for "stable", then applied to "unstable" as time and resources
> permit. When do patches get applied to "testing"? Pretty quickly? Or only
> after they've been in the "unstable" release for a while?

Woody is a production system. It gets security updates right away.
A lot of the packages are based on quite old versions of the "upstream"
sources (PHP and KDE are ancient at this point...) but the maintainers follow
the upstreams and backport any security updates.


> To put it another way, if another OpenSSH vulnerability is discovered and
> I'm running "testing", how long would it take before an updated package
> would be available for downloading and installing?

It seems to me we always get OpenSSH updates within two days of the
announcement.

Testing is not a production system. If you care about stability
and reliability and security, you should not use testing.
You can't even be sure it will install on any particular day.
For a server like the one you described, testing would be a mess.
If you really need an up-to-date PHP, it would be easier to
just use the upstream for that one product.
A few days ago, I built Apache 2.0.48 and PHP-4.3.4 on Woody just to see
if they would work. It only took a few minutes and they work fine.
But I still run Debian's Apache 1.3.26 (+ fixes) on the server that matters.


> And if timely security patches are important to us, should I be using a
> different release? Or a different distro altogether?

Once you get used to apt-get you'll wonder how you lived without it.
Woody (aka "stable") is the way.


Cameron

["Followup-To:" header set to comp.os.linux.misc.]

On 2003-11-18, George Adams <g_adams27@hotmail.com> wrote:
> I wonder if someone could tell me how Debian
> handles security patches.
>
> Specifically, if I understand their website correctly, security patches are
> first done for "stable", then applied to "unstable" as time and resources
> permit.

This may be the impression you get from http://www.debian.org/security/faq,
but that describes the work done by the security team. In practice,
usually the regular Debian maintainer will upload a new version to unstable
in a timely way.

> When do patches get applied to "testing"? Pretty quickly? Or only
> after they've been in the "unstable" release for a while?

A package can be moved from unstable to testing in two days IF it is marked
"urgency: high" AND satisfies four other criteria related to bugginess and
overall distribution consistency:
http://www.debian.org/devel/testing

> To put it another way, if another OpenSSH vulnerability is discovered and
> I'm running "testing", how long would it take before an updated package
> would be available for downloading and installing?

It could take weeks and weeks if, for example, the new ssh depends on
libraries that are not ready to be moved into testing.

> And if timely security patches are important to us, should I be using a
> different release?

Certainly you should not be running testing; no one should recommend that.
You could run stable+security patches, or unstable, or a mixed
testing+unstable system taking advantage of features like apt_preferences
(not everyone likes the preferences documentation, but at least there is a
man page in section 5).

--
Paul Kimoto
This message was originally posted on Usenet in plain text. Any images,
hyperlinks, or the like shown here have been added without my consent,
and may be a violation of international copyright law.

George Adams wrote:
>
> I'm one of many RedHat orphans looking for a new home now that support for
> my old RH 7.3 distro is ending at the end of the year. I'm trying to find a
> new distro to replace it, and I'm mainly eyeing Debian and Fedora.
>
> The box we're running is a mainly an e-mail, web, and RealAudio server. For
> that reason, a lot of the bells and whistles that come with most distros
> (this box will probably sit in a corner and never run XWindows at all), but
> I probably want enough newer features (including a 2.4 kernel) that if I'm
> going to go with Debian, it will probably be the "testing" (sarge) release
> rather than "stable" (woody).
>
> One of the biggest factors for picking a distro for our situation will be
> will be timely bugfixes and security patches.

I'd strongly suggest using Debian/stable rather than testing in that
situation.

Why exactly do you feel you need testing? The only thing you
specifically mention is a 2.4 kernel. Debian/stable offers 2.4.18.
Plus stable has all the timely security updates you'd need on a server.

BTW, there's absolutely no reason you can't run your own kernel. My
server & firewall boxes all run Debian/stable with custom 2.4.22 kernels
I compile myself from the vanilla kernel.org sources. It works
flawlessly.

Thanks for the reply, Cameron. I'll give woody another look, though you're
right in assuming we'd probably need more recent versions of Apache, PHP,
etc. Which brings up a question:

> A few days ago, I built Apache 2.0.48 and PHP-4.3.4 on Woody just to see
> if they would work. It only took a few minutes and they work fine.
> But I still run Debian's Apache 1.3.26 (+ fixes) on the server that
matters.

During the first few months of my using RH 7.3 (and later 8.0 and 9.0), I
installed custom-compiled versions of Apache, PHP and a few other things and
uninstalled the default RH RPMs for those packages. This worked out fine,
until security issues became more of a problem. A vulnerability in, say,
OpenSSL suddenly meant that I had to recompile Apache/mod_ssl, PHP, and
whatever else I had that depended on certain SSL libraries. I eventually
decided to do away with my custom-compiled programs as much as possible,
re-installed the RH RPMS, and let "up2date" take care of the patching for
me.

i.e. when I had to decide between "newest features but manual maintenance"
vs. "older version but automated updates", I usually went with the latter.

Would the process (and drawbacks) of installing custom programs on Debian be
the same? i.e. if I decide that I just have to have features x,y, and z in
a newer version of PHP that woody doesn't have, am I going to have to just
resign myself to doing the manual recompile/reinstall thing that I did back
in my old RH days?

If that's true, and if (as you say) woody has a number of very stable,
secure, but "ancient" programs, then I may end up having more programs I
have to maintain by hand than I did back with RH.

Thanks again.

George Adams writes:
> If that's true, and if (as you say) woody has a number of very stable,
> secure, but "ancient" programs, then I may end up having more programs I
> have to maintain by hand than I did back with RH.

Rather than fetch the upstream source and build and maintain the program by
hand you should fetch the Debian source package from Unstable and backport
it. In most cases this is quite painless.
--
John Hasler
john@dhh.gt.org (John Hasler)
Dancing Horse Hill
Elmwood, WI

George Adams wrote:
> Would the process (and drawbacks) of installing custom programs on Debian be
> the same? i.e. if I decide that I just have to have features x,y, and z in
> a newer version of PHP that woody doesn't have, am I going to have to just
> resign myself to doing the manual recompile/reinstall thing that I did back
> in my old RH days?

I'm a Red Hat refugee, too, and a Debian newbie because of it. So
take what I say with a grain of salt. <grin>

First, you can use a technique called "apt-pinning" to run selected
packages from testing or unstable, but with most packages from stable.
Google "apt-pinning" for details.

Sometimes it doesn't work, though, if a package was compiled to
require, for example, a higher version of glibc than what's in stable.
In that case, I've found it's fairly easy to say

# get build requirements from testing
apt-get -t testing build-dep randompkg

# get source from testing and build it
apt-get -t testing source -b randompkg

# install newly built package
dpkg -i randompkg*.deb

Note that in both cases you'll have to pay extra attention to
vulnerabilities in the package you install either of these ways, since
you won't be receiving "stable" level updates to them. But that's
also true if you roll your own from the upstream source, and it's not
nearly as easy.

If I'm completely out of line with what I've said, I hope someone who
knows better will correct me. <grin>

Ed

George Adams wrote:

> Thanks for the reply, Cameron. I'll give woody another look, though
> you're right in assuming we'd probably need more recent versions of
> Apache, PHP,
> etc. Which brings up a question:

*SNIPPED*

> Would the process (and drawbacks) of installing custom programs on Debian
> be
> the same? i.e. if I decide that I just have to have features x,y, and z
> in a newer version of PHP that woody doesn't have, am I going to have to
> just resign myself to doing the manual recompile/reinstall thing that I
> did back in my old RH days?
>
> If that's true, and if (as you say) woody has a number of very stable,
> secure, but "ancient" programs, then I may end up having more programs I
> have to maintain by hand than I did back with RH.
>
> Thanks again.

Another avenue not really discussed yet is "backports". There are a number
of repositories that have ported the newest versions of software so you can
install them on a standard Woody machine. I run several Debian production
machines running Woody with backported PHP-4.3.4, MySQL-4.x (can't remember
the sub version) etc. Most of my backports come from
http://www.backports.org/. They are timely with their bug and security
fixes (less than 2 days for the most recent SSH bugs). No problems yet

Backports are great because they integrate into Debian's normal packaging
system without you needing to know whether it's a backport or a standard
Woody package. You simply add the list of backport repositories to
/etc/apt/sources.list then do "apt-get update" and voila - you're ready to
install the new versions available in the repositories.

FWIW, this laptop I'm writing on is Debian Woody with backported KDE-3.1.4
etc and it has never missed a beat (or an update) YMMV

--James
__________________________________
A random quote of nothing:

A Parable of Modern Research:

Bob has lost his keys in a room which is dark except for one
brightly lit corner.
"Why are you looking under the light, you lost them in the dark!"
"I can only see here."