RE: piranha patch to allow colocation of director/realserver

Lon,

Thanks for your interest.

Because I don't know if I'm authorized to put the patch into the list
directly I decided to keep it here (TEMPORARY):=20
http://89.253.238.200/files/piranha-0.8.4-advertise-address.patch

Well, after some tidying it grew to 500 lines, sorry ;-)
I followed the original author's C coding style.
I also have some sort of intermediate SRPM.

Code changes:
 - added new `advertise_address' option to lvs.cf in virtual server
section.
 - added logic to select the method: classic or advertise
 - added advertise/unadvertise functions
 - added/modified helper functions to call arptables and send_arp
 - modified some version information - FIX ME

Changes to lvs.cf(5) - PER-VIRTUAL SERVER SECTION:
  advertise_address =3D <virtual-address> <advertise-device>
i.e.:
  advertise_address =3D 192.168.0.35 eth0

Piranha will advertise the virtual address on the selected device only
when active. It will hide the virtual address when it is passive using
arptables.
Note that `advertise_address' is mutually exclusive with `address'
option and if pulse see both then it will complain and fail to run.

Changes to network design:
Collocate the director and real server on the same box. Idea is to have
two boxes - each with director and real server.

Changes in machine setup:
With the new option pulse will no longer do ifconfig up/down of VIF.
You have to bind the virtual address to loopback manually and provide
appropriate initial ARP screening of it in /etc/sysconfig/arptables.
Please read 6.8 of LVS-HOWTO document:
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.arp_problem.html
When pulse becomes active it will unblock the ARP and send gratuitous
message.

Why arptables?
Yes, it is clumsy but portable across RHEL[345].
I could use sysctls but I wish to use functionality on RHEL 3 and 4.

Possible caveats:
- If you change the real IP address - please update the ARP screening.
You can't avoid mangling of source IP address in the OUT chain.
- I tested only direct routing (because it is vital for web security
gateway to see the untouched source IP address). Not sure that NAT/TUN
will work in local mode.

Next steps:
If you recognize my work useful please let me know - I can proceed with
GUI.
I could also try fixing the send_arp program to avoid obsolete
SOCK_PACKET syscall that make complains on newer kernels.

---
Peter