ipvsadm version mismatch in debian

Roberto Nibali ratz at drugphish.ch
Sun Oct 17 20:26:50 BST 2004


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


More information about the lvs-users mailing list