|
Hi,
The last statement is important and the Debian folks should do that
ASAP. I've done the same thing in our company distribution. We have a
ipvsadm-2.2, a ipvsadm-2.4 and a ipvsadm-2.6. Whichever kernel you boot,
you get the right tool with it.
Mind to share these packages? :)
I wish I could. I can give you the email address of our manager in
charge, maybe you can persuade him to open the design of our distribution.
We have an own package management format since non of the existing ones
fulfilled our requirements in terms of security and scalability back in
those days when we started it (1996). So even if I gave you the related
packages, you wouldn't be able to use them :).
It's a very special distro, made for the telecommunication industry that
requires high availability and reliability at all costs. Most people
(except the ones in the high security or high performance network
computing areas) would not be interested in using it anyway.
<sidenote>
But basically the design of choosing the correct configuration item
based on the triple <running Kernel, C library, API version of a
specific tool> is rather simple (solved the legacy part of a system as
well):
1. Make sure you get every configuration you need for every tool you use
in a meta language format, so you can describe API changes, library
changes and most importantly the name of the binary.
2. Separate form and function of the binary's semantic, create multiple
parts of configuration files, like xinetd does for example with the
/etc/xinetd.d/ directory and then you have every packages config
file related to xinetd in the directory with the package name.
3. Upon booting simply evaluate a global variable which says what kernel
you're running. Since you almost never call your binaries
interactively, you'll have shell scripts doing the work for you. Make
sure you never call a binary by its name but wrap it into a variable
which gets the global variable's value appended.
4. Set up different development environments, one for glibc, one for
uclibc (easy 64bit LFS, small statically linked binaries), each one
with 2.x and 3.x compilers, and each one with a 2.2.x, 2.4.x and a
2.6.x kernel. You might be surprised at the high amount of breakage.
5. Configuration needs to be handled in meta language (XML for example),
and it needs to be failsave (we use CVS to backup configuration). If
an upgrade has to be done and a daemon cannot start, there always has
to be a fallback, always. So if you upgrade to a 2.4.x kernel, the
whole service the server provided must be testifiably be equal to the
service provided while running under a 2.2.x kernel or you need to
fall back. If that does not work, you always have a hot standby :)
Example:
We build high performance packet filters with 16 NICs and thousands
of packet filter rules. We never wrote ipfwadm or ipchains or
iptables rules into a shell script and let it run by a start script
upon boot. We defined a meta language for packet filter flow
description which then gets interpreted according to the kernel
context we run in. The difficulty lies in the semantical correctness
of the produced output. Our meta firewall configuration done in 1996
for customers can still be used nowadays. Sometimes security-wise it
is not a bad idea to still run a 2.0.x kernel, if you don't need all
the new features.
We've done that with our distribution since the requirement was to
handle thousands of nodes (only networking and security tasks) around
the globe with a minimum of people, failures and service costs.
</sidenote>
Best regards,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
