Re: Still learning! (kernel help)

On Mon, 2 Jan 2006, Shane R. Spencer wrote:

> Disclaimer -- I use Debian.. and this may be more wordy than it has to
> be.
>
> I think I am conflicted about this issue (Compiling a non-distro
> available kernel on an enterprise level distro) .. and won't say much
> more about my personal conflict other than the purpose of CentOS is
> scalability and enterprise scalability/package management. It may not be
> the best thing out there for say laptops (why LVM a typical laptop?)..
> but on single or multiple servers its strengths are enterprise level
> flexibility.. if everything is kept up-to-date via binary packages on
> all servers under your scope it would be easy to maintain as all the
> software installed came from the same source.. can be transitioned
> easily from server to server and so on.

Running a stock distro kernel *especially* for enterprise situations is, in my
opinion, insane. Keep in mind that most vendors compile in everything they
can just to make sure the system will run out of the box on the widest array
of hardware. From a security perspective that opens more attack vectors from
users when module auto-loading is enabled, not to mention some of the latest
filesystem driver exploits. From a performance perspective a bloated kernel
(along with a bloated "optimized" system libraries) can be detrimental to cache
coherency on SMT machines (or even SMT/SMP machines like the POWER5 that allow
micropartitions).

When I'm spouting my nonsense you also have to consider my affliction as a
minimalist. I can't stand running a kernel with a bunch of crap enabled that
I'll never need or use. That's protected me more than once from kernel
vulnerabilities that the stock distro kernels were vulnerable from.

As for LVM on laptops: why wouldn't you LVM *everywhere* (well, not on a
flash drive in an embedded system)? Partitioning on any system is fundamental
to robustness and security and LVM makes it easier to manage, rather than
swagging where the storage really needs to go.

> That being said, there is a huge transition in-between 2.6.9 and 2.6.14
> so when using a 2.6.9 be very indepth with your gui config and look over
> every possible option that an old config may have nulled out, Typically
> if you use a source package for this newer kernel it will work well
> since it provides a config suitable for your distro. Importing an old
> config should be fine, however if your distro uses an initrd you must
> consider using it and not statically compiling in all the things you
> think you want for a few different reasons. I can only say this based on
> what Debian does when installing a packaged kernel, not really how
> CentOS handles it, but they are going to be really close.
>
> Mainly initrd's are not evil space mongering slowdowns, and are
> incredibly useful. A distros packaged kernel will typically use an
> initrd and a smart mkinitrd script to set up a minimal initrd to init
> all your detected hardware. Including intelligent scripts for
> initilalizing lvm/evms/raid setups, specific chipset drivers for
> IDE/SCSI,etc.., and loading the file system module for your / mount.

I strongly dislike initrds (outside of boot cds). With the sole exception of
wanting to have / LVM-managed I have yet to see any reason why I would need
one (software RAID can autodetect on boot, so you don't need initrd for that,
either). It certainly hasn't been necessary for anything I'm doing, at any
rate. I could see where some more exotic hardware might need it, but luckily
even my micropartitioning setups on POWER5 w/virtual I/O SCSI & NICs don't.

> Basically when you install the packaged kernel. It custom tunes an
> initrd to your system, making the package work across multiple
> motherboards from the same package. In debian they segregate x86 into
> 386, k7(-smp), and 686(-smp) which helps narrow down the different
> packaged kernels that work with the stable distribution, they all have
> the same modules available, however the processor and a few
> other .config params are changed to optimize the kernel against the
> target processor, simplifying many sysadmins jobs. I personally
> maintain a small inter-company debian repository for some Via C3 tuned
> kernels, our main routers are Via PD1000's which we have 5 of throughout
> several offices of the company, they are slow to compile on however
> quick enough and low power so we use them everywhere. Without a feed for
> a stable kernel package that makes a specific initrd for each of the
> servers (some differently configured) it would take more effort than I
> want to offer to maintain seperate trees on all those unique hosts. I
> also maintain a Geode tuned kernel package from 2.6.14 sources with a
> very minimal set of modules for some embedded wireless routers, still
> using an initrd to help load up some modules. This option also allows
> me to load modules before the rootfs is mounted with specific parameters
> if those need changed (mainly SquashFS/UnionFS).

This is a valid point if you have a large amount of whiteboxes around. But,
if you can do it, the better idea would be to standardize your hardware
platform as much as possible. Sounds like you're using Linux on a bunch of
embedded systems, which would benefit from initrds. We'll see if I change my
mind when I start playing with those. ;-)

> Think that should be just enough beating around the bush? :) I don't
> know how RPM packaging of a kernel works, only dpkg but if you are going
> to go through the effort to compile 2.6.14 (from SRPM's I assume) you
> should do it using a smart config (from the SRPM) that CentOS would
> prefer, one configured not only to your processor but to the "enterprise
> level" distribution you are using. Since debian 2.6.14 is in the
> "unstable" dist, I backport it as well as udev and module-init-tools to
> stable whenever I have to use it (which I rarely have to) and try to
> compile and maintain the source package located on a machine I want to
> be in charge of packaging kernels and extra packages I am going to use
> in our infrastructure. I for the most part using the configs that the
> distributions kernel package maintainers prefer. Bringing a working
> config up from scratch isn't difficult, however I often run into systems
> "Speed Racer Configed by Leet Haxors" and the ex-maintainers never kept
> the kernel tree, threw away the configs and left out this one tiny
> little module that could have been usefull. Instead of a bandaid
> solution, getting the right tree, assuming the config, compiling all the
> modules and installing just this one little .ko file
> into /lib/modules/.../kernel/driver/somewhere/ where future admins will
> never know what I did. I typically scrap the running kernel and install
> an up-to-date kernel that the distro will have no problems with.
> Cleaning out all non-distro related kernel poopies along the way.
> Offering a lot of flexibility and a straight forward maintenance
> solution to the admins.

Which leads to why the kernel maintainers add the /proc/config.gz option. :-)

> This is a biased view from a person who has made a lot of mistakes along
> the way :)
>
> Let me know if this helps or makes you insane.

:-) Definitely food for thought, and some good points.

         --Arthur Corliss
           Bolverk's Lair -- http://arthur.corlissfamily.org/
           Digital Mages -- http://www.digitalmages.com/
           "Live Free or Die, the Only Way to Live" -- NH State Motto
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Tue Jan 3 12:51:58 2006