Re: [vserver] Vserver kernel support

From: Corey Wright <undefined_at_pobox.com>
Date: Fri 16 May 2008 - 22:44:27 BST
Message-Id: <20080516164427.b4b4757b.undefined@pobox.com>

On Fri, 16 May 2008 20:15:46 +0200
Peter Mann <Peter.Mann@tuke.sk> wrote:

> On Fri, May 16, 2008 at 10:24:27AM -0700, Roderick A. Anderson wrote:
> > No distribution I'm aware of since Linux-Vserver is not part of the
> > main line kernel source. (Is that the correct phrase?)

"vanilla" is usually the "slang" adjective i see used for a kernel directly
from kernel.org, but "mainline" is usually understood to mean the same.

> Debian Etch (stable) has support for vserver with kernel 2.6.18
> http://packages.debian.org/linux-image-vserver

if the 2.6.18+vserver kernel in etch works for you, then use it. it's what
i would be using on my server if 2.6.18 didn't have a SATA driver that
caused my raid array to resync weekly.

> > That said, I'm really happy with CentOS 5 and Daniel's YUM repository.
>
> http://rpm.hozac.com/dhozac/centos/5/vserver/x86_64/ contains 2.6.22
> (but maybe without recent security updates for vanilla kernel)

daniel, are you patching the centos kernels with vserver (ie
centos-distributed kernel source + vserver patch), or are you merely
packaging for centos a vanilla kernel patched with vserver? and i presume
you are tracking security updates for the kernel.

if i can get source for a vanilla kernel patched with vserver and security
updates from your centos SRPMs, then i might just use that and just compile
it myself for debian.

> > Of course you could always roll your own kernel.
>
> yes, but it's hard to backport all security updates into the last
> vserver supported kernel ...

yes, it's hard to do it yourself (unless you are following linux kernel
development because things change so rapidly and today's security update
might not apply both physically & logically to the last now-unsupported
kernel release), but that's why you find someone else to do it for you.

> i don't have problem with recompiling kernel, but which supported source
> can i use for recent kernel? on many servers i'm still using supported
> debian vserver kernel 2.6.18 with backported recent vanilla kernel
> patches, for example:

the most recent vserver stable patch is 2.2.0.7 for kernel 2.6.22. the
most recent security patch to 2.6.22 is maintained by oliver pinter. i
have advertised this fact on this mailing list [1] and elsewhere [2]. it
all patches cleanly except for the EXTRAVERSION in the top-level Makefile
(which is to be expected when using patches from two or more sources).

that describes my kernel sources until a new vserver stable patch comes out
for a recent kernel.

[1]
http://list.linux-vserver.org/archive?mss:978:200804:aahmcfjcnaaembflfhob
[2] http://lwn.net/Articles/281711/

> i'm asking because i don't know in detail other distributions and their
> kernel support - so if some distribution has e.g. supported 2.6.22, i can
> try patch it with vserver patch ...

i don't know of a widespread distro that provides kernel sources patched
with vserver, besides debian for etch (and i don't know that it will resume
once a new vserver stable patch is released as debian has scaled back on
the number of build variations). most of the popular distros patch their
kernel sources so heavily that merging the vserver patch is a tedious
affair (assuming you know enough about the kernel and C programming to
undertake the task at all). that's why i use a vanilla kernel: despite the
manual effort to regularly build new kernel versions to maintain security
support, it's the easiest kernel source to patch with vserver and the only
one the linux-vserver project supports.

i formerly used ubuntu's kernel source, because each release had a minimum
of 18 months of security support, and i merged the closest vserver stable
patch with it, but i got tired of spending a whole weekend performing the
merge and worrying if i merged everything correctly so as to not introduce
any security problems (eg debian's openssl fiasco). yeah, i probably spend
an equivalent amount of time over 18 months compiling each new kernel
release and vserver patch as i would previously spend merging, but it's
pretty evenly distributed across 18 months and a relatively easy task
(which is good for security).

corey

-- 
undefined@pobox.com
Received on Fri May 16 22:44:49 2008
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Fri 16 May 2008 - 22:44:54 BST by hypermail 2.1.8