Re: ipvsadm version mismatch in debian

To: " users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: ipvsadm version mismatch in debian
From: Roberto Nibali <ratz@xxxxxxxxxxxx>
Date: Sun, 17 Oct 2004 21:26:50 +0200

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.

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 :)

   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.

Best regards,
Roberto Nibali, ratz
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
<Prev in Thread] Current Thread [Next in Thread>