Re: bug in Release( entry *VE ) RH 7.3

On Friday, Jun 6, 2003, at 16:08 US/Eastern, Ezra Nugroho wrote:
> At that time wackamole at first declares that
> "INTERFACE ETH0:1 64.255.110.80 DOWN"
>
> All the above makes sense, wackamole has balanced the VIP assignments
> accross two servers. However, apparently when wackamole brought eth0:1
> on first, it accidentally took eth0:2 down without telling spread.
> Wackamole things that all VIP are acquired, but they are not!
>
> Could it be a bug in the Release( entry *VE ) function, particularly 
> for
> RHN 7.3?

I've seen that problem on Linux before.  It has to do with Linux's 
screwy interface system.

The ioctl()'s for upping and downing interfaces on FreeBSD, MacOS X and 
Solaris are very straight forward and always behave the way one expects.

I've seen a few problems on Linux where you ioctl() down eth0:n and it 
will drop n and everything above it (n+1, n+2, etc.).  So, I guess I 
would say it is a bug in Wackamole not handling some of the quirks of 
Linux's interface ioctl()s.

In the wackamole distribution, there is a file ife.c.. there should be 
a make target called ife (for testing).  I think that it may require 
alarm.o to be added to the dependencies and objects on the link line, 
but after running "make ife", you should have a concise tool to perform 
the same actions that wackamole does when attempting to up/down 
interfaces:

./ife help will give you options.

To do: add a few IP addresses and then remove the IP on eth0:1.  If it 
removes eth0:2 and up, then it is a bug in ife-sockpacket.c -- patches 
welcome :-D

-- 
Theo Schlossnagle
Principal Consultant
OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
Phone:  +1 410 872 4910 x201     Fax:  +1 410 872 4911
1024D/82844984/95FD 30F1 489E 4613 F22E  491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA  3D 90 B9 9F BE 27 24 E7