LVS is patched into the kernels in some distributions. Other distributions have kernels that won't patch with LVS. It's impossible for us to support any of this. Your best approach is to talk to the vendor. One solution would be to have LVS in the standard kernel, and the patches applied by distros would have to be compatible with LVS. This solution hasn't been available. Our approach has been to tell you that you're on your own. This has solved our problem, but still some people need to use these distros. In some work situations, the suits like using known distributions for security reasons. However, security should be set by specification (e.g. must pass a set of tests) rather than implementation ("we'll accept the Fred distro"). In this way any box can be certified, without knowing the implementation details. Changes to the software can be recertified without restricting the software on the box.
PB peterbaitz (at) yahoo (dot) com 12 Apr 2002
 | Note |
|---|---|
Joe: <rant> Occasionally someone outside the LVS mailing list, who has been paid by their employer to write some LVS code, releases their code without any support, without consulting us beforehand to see if the code would be useful, and does not offer to help with our code with similar functionality. Piranha is one of these. The only point of this code is to claim turf, rather than to help LVS. When people try it out and can't get it to work, and can't get any help from the author/vendor, they come to the LVS mailing list expecting us to fix their problem. My response is to boycott the code. However other people think differently and are happy to use such code. If you get code to work with LVS that has been developed by these outside people, then it's fine with me. You can ask about this code on the LVS mailing list, but you'll have to realise that the pool of people who know about it is smaller and that other people on the mailing list (e.g. me) have a jaundiced view of the code after dealing with the people who produced it. Piranha is a RedHat product. If you want more information about it, you should contact RedHat, who has setup a Piranha mailing list. (There is not much information available there according to people who've tried it.) Some people on the LVS mailing list may be able to answer questions on Piranha, so there is no harm in posting Piranha questions there. The files on the LVS website have all the capabilities of LVS and are supported on the mailing list. If you want supported LVS functionality, you could start with the standard LVS files. </rant> | |
Ramish Patel:
I am using Red Hat Linux 7.2, kernel 2.4.7-10, and I have attempted to apply numerous patches to it for lvs, only two of which have been successfully applied without errors
Horms horms (at) verge (dot) net (dot) au 31 Jul 2002
Firstly I would stronly recommend that you start with a kernel from kernel.org (such as 2.4.18) rather than using Red Hat's Kernel unless you know what you are doing. ipvs-1.0.4 does not work out of the box with the Kernel shipped with Red Hat 7.2 and vice versa.
However if you want to do this here is a rough guide.
- You need to apply the linux_kernel_ksyms.c.diff and linux_net_netsyms.c.diff
- You need to remove the existing version of LVS which is present in the 7.2 kernel. You can do this by examining the patches that are provided with the kernel src.rpm and the spec.file.
- Compile the kernel - a few minor things may fail. Again this is the "way of pain".
- Build the kernel modules provided in the ipvs/ subdirectory of ipvs-1.0.4.tar.gz. You will need to make modifications to the source to get this to work, but they should be minor.
The recipe was posted in the mailing list.
Alex has started (Sep 2002) maintaining http://www.nrh-up2date.org/howto/lvs/ RedHat LVS kernel binaries
This recipe bypasses all the problems of trying to figure out which version of LVS that RedHat has patched into the kernel. You ignore the RedHat patches and build a recent LVS as modules.
Matthew S. Crocker matthew (at) crocker (dot) com 26 Nov 2002
Redhat 8.0 comes with LVS in the kernel but I think it is version 1.0.4. I have had good luck by just rebuilding the latest patches and installing them in the modules directory. I don't patch the kernel, I'm hoping the kernel patch is pretty stable and hasn't changed in a while. So, just install the RH kernel rpm, the kernel-source RPM. Then install ipvs-1.0.7, and make modules_install.
pb peterbaitz (at) yahoo (dot) com 26 Nov 2002
I know Red Hat 8.0 with the following RPMs:works fine for NAT Routing EXCEPT the Piranha-GUI is all messed up due to some Apache 2 and/or PHP scripts thing. Therefore I've stuck with Red Hat 7.3 plus all errata including latest kernel kernel-smp-2.4.18-18.7.x and the above RPM's all work nicely on 7.3.
Alex Kramarov alex (at) incredimail (dot) com 26 Nov 2002
kernel-smp-2.4.18-18.7.x also has the same patch applied (1.0.4). and you shouldn't feel sorry that you have to use 7.3 - 8.0 is far from being a stable server platform. don't use hearteat (if you cluster your directors) with that kernel though - only with 2.4.18-10 or earlier.
pb peterbaitz (at) yahoo (dot) com 26 Nov 2002
I am using kernel 2.4.18-18.7 in both directors at the moment and heartbeat has worked fine. And just prior to this time, they had kernel 2.4.18-17.7 and also worked perfectly - failover was always fine.
Gegory Boehnlein damin (at) damin (dot) nacs (dot) net 10 Aug 2003
I spent a lot of time making modified RedHat 7.3 RPMS (before I discovered the UltraMonkey page) to deploy Julian's hidden arp patch. Now that I know UltraMonkey will be doing this on a regular basis, I'l most likely just implement their kernel. For those that are interested, the results of my work can be downloaded from:
ftp://ftp.nacs.net/pub/lvs kernel-2.4.20-19.7.lvs.i386.rpm kernel-2.4.20-19.7.lvs.src.rpm kernel-BOOT-2.4.20-19.7.lvs.i386.rpm kernel-doc-2.4.20-19.7.lvs.i386.rpm kernel-source-2.4.20-19.7.lvs.i386.rpm README.kernel |
This is a drop in replacement for RedHat 7.3 systems that implements the following patch for LVS-DR Real Servers.
http://www.ssi.bg/~ja/hidden-2.4.20pre10-1.diff |
The purpose of this patch is to change the ARP behavior for addresses attached to specific interface:
- don't reply for broadcast probes
- don't announce the addresses in the ARP probes
- the addresses are not selected by the source address autoselection mechanism.