jesus at omniti
Jun 6, 2003, 9:03 PM
Views: 793
Permalink
|
|
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
|
bug in Release( entry *VE ) RH 7.3
