Here is a patch that make sure the correct hostname is used
in the SM_NOTIFY message what is sent from a rebooted server
that has multiple network interfaces.
Using the network part of the destination address, the correct network
interface is found. Then a gethostbyaddr() on that interface is done,
which yields the correct hostname that should be sent in the notify
message....
Comments?
SteveD.
On Tue, Nov 23, 2004 at 03:28:07PM -0500, Steve Dickson wrote:
> Here is a patch that make sure the correct hostname is used
> in the SM_NOTIFY message what is sent from a rebooted server
> that has multiple network interfaces.
>=20
> Using the network part of the destination address, the correct network
> interface is found. Then a gethostbyaddr() on that interface is done,
> which yields the correct hostname that should be sent in the notify
> message....
>=20
> Comments?
It has been a while since I looked at this code, but:
1. What happens when you run statd with the "-n" option?
Does this patch override the name the user gave?
2. Does this really find the correct hostname?
If I'm not mistaken, the nfs client needs to get a SM_NOTIFY message
with the hostname that it actually mounted from, right?
This may or may not match the hostname that the server find when
running gethostbyaddr on the interface's IP, so one can easily find
scenarios where this patch will cause statd to stop working.
Now, there new behavious may actually be better, but I'm not sure
it's acceptable to change it anyway?
Could an alternative be to send out SM_NOTIFY messages for multiple
hostnames? Both the one from gethostname() and the ones found by
reverse lookup from the interfaces? Then I guess the meaning of the
"-n" option could be changed to _add_ a hostname to the list of
names to broadcast for?=20
--=20
Ragnar Kj=F8rstad
Software Engineer
Scali - http://www.scali.com
High Performance Clustering
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Tue, Nov 23, 2004 at 07:46:04PM -0500, Steve Dickson wrote:
> Ragnar Kj=F8rstad wrote:
> >1. What happens when you run statd with the "-n" option?
> > Does this patch override the name the user gave?
> >
> hmm.... this is a problem, since the global SM_stat_chge.mon_name
> that the -n sets is now ignored... I guess I was thinking it would be b=
etter
> for statd to dynamically set the name that sent the notify message.
> But it would probably be a smart to maintain the same functionality.
>=20
> Question: do people actually run multiple statds using the -n to define
> the interface they monitor? That's a scenario I guess I didn't think=
=20
> of but
> it sound a bit awkward....
Let me just explain why -n was added in the first place:
HA NFS-servers typically have a "floating IP" which is an alias on eth0
on the active server. Clients mount by using a hostname that maps to
this floating IP. In case of a failover the secondary server needs to
send out a SM_NOTIFY with the same hostname.
-n allowed us to specify that the same notify-name should be used on
both servers, and what that name should be.
So, in this case one doesn't run multiple statds, only a single one that
should use a different hostname from gethostname().
> >2. Does this really find the correct hostname?
> > If I'm not mistaken, the nfs client needs to get a SM_NOTIFY message
> > with the hostname that it actually mounted from, right?
> right....
>=20
> > This may or may not match the hostname that the server find when
> > running gethostbyaddr on the interface's IP, so one can easily find
> > scenarios where this patch will cause statd to stop working.
>
> I don't think this is an issue... as long as the hostname and all of it=
s=20
> aliases
> resolve to the same ip address, things should work since its the ip add=
ress
> the kernel needs to find the lock that has to be reclaimed...=20
OK, so the client maps the name back to the IP?
and compares it to gethostbyname() on the hostname that it used to
mount?
Is this in the specification, or only the linux-implementation?
If that's the case, are we allowed to just send the IP instead of the
name?
> Now the=20
> problem
> arises when the hostname resolves to a different ip address....=20
> something this patch
> is trying to address...
I didn't know the client actually compared IPs - I thought it compared
the actual names.
Then I guess it's less of a problem than I thought.
A couple of cases where I think it would fail though:
- If you have inconsistant name-resolution (/etc/hosts) in
your system.
- If you have aliases (eth0, eth0:0) with different IPs but on the
same network. The current patch (if I read it correctly) will then
use the name from the last alias, which is kind of random.
The second case may be very relevant to the HA-problem which "-n" was
originally added for.
=20
> > Now, there new behavious may actually be better, but I'm not sure
> > it's acceptable to change it anyway?
>
> Is this truly a big thing? to explicitly define the hostname that will=20
> be monitored?
There are two reasons to keep -n:
1. There could still be some use for the functionality.
Personally I mostly care about the HA-problem, so if that is solved
through some other means, I won't protest if it is removed.
Others may use it for other things though.
2. Backwards compability
Personally I don't have a problem with breaking existing
installations that use "-n" if it's documented properly (e.g. in
the manpage, changelog, and maybe you should get a warning if you try
to use it) and if the same functionality can be achived some other
say. (see 1). Others may be more concerned though.
> > Could an alternative be to send out SM_NOTIFY messages for multiple
> > hostnames?=20
> >
> I believe this is how some of the Unixs out there do it... but that=20
> always seem a bit
> verbose and non-exact...
Verbosity: yes, but unless we know what IP the client actually used=20
there is no other way to make sure we reach all clients.
Non-exact: I agree, but if we could send out the IPs instead of the
names it would be more exact.
> >Both the one from gethostname() and the ones found by
> > reverse lookup from the interfaces? Then I guess the meaning of the
> > "-n" option could be changed to _add_ a hostname to the list of
> > names to broadcast for?=20
>
> Again I think this is a bit messy especially with hosts that have a ton=
=20
> of interfaces and
> aliases.... but anything is better than how it works today.... imho...
Hmm, the more I think about it the more sure I am that it should be
possible to record what IP the client _actually_ used? Then we would
only have to send one NOTIFY to each client, and we would reach all
clients, independently of aliases and all that stuff.
If we sent the IP rather than the name (not sure we're allowed to?) we
would also eliminate the problem of inconsistent name-resolution
(allthough this is a very minor problem), making the system
bullet-proof.
--=20
Ragnar Kj=F8rstad
Software Engineer
Scali - http://www.scali.com
High Performance Clustering
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Ragnar Kj=F8rstad wrote:
>On Tue, Nov 23, 2004 at 03:28:07PM -0500, Steve Dickson wrote:
> =20
>
>>Here is a patch that make sure the correct hostname is used
>>in the SM_NOTIFY message what is sent from a rebooted server
>>that has multiple network interfaces.
>>
>>Using the network part of the destination address, the correct network
>>interface is found. Then a gethostbyaddr() on that interface is done,
>>which yields the correct hostname that should be sent in the notify
>>message....
>>
>>Comments?
>> =20
>>
>
>It has been a while since I looked at this code, but:
>1. What happens when you run statd with the "-n" option?
> Does this patch override the name the user gave?
> =20
>
hmm.... this is a problem, since the global SM_stat_chge.mon_name
that the -n sets is now ignored... I guess I was thinking it would be bet=
ter
for statd to dynamically set the name that sent the notify message.
But it would probably be a smart to maintain the same functionality.
Question: do people actually run multiple statds using the -n to define
the interface they monitor? That's a scenario I guess I didn't think=20
of but
it sound a bit awkward....
>2. Does this really find the correct hostname?
> If I'm not mistaken, the nfs client needs to get a SM_NOTIFY message
> with the hostname that it actually mounted from, right?
> =20
>
right....
> This may or may not match the hostname that the server find when
> running gethostbyaddr on the interface's IP, so one can easily find
> scenarios where this patch will cause statd to stop working.
> =20
>
I don't think this is an issue... as long as the hostname and all of its=20
aliases
resolve to the same ip address, things should work since its the ip addre=
ss
the kernel needs to find the lock that has to be reclaimed... Now the=20
problem
arises when the hostname resolves to a different ip address....=20
something this patch
is trying to address...
> Now, there new behavious may actually be better, but I'm not sure
> it's acceptable to change it anyway?
> =20
>
Is this truly a big thing? to explicitly define the hostname that will=20
be monitored?
> Could an alternative be to send out SM_NOTIFY messages for multiple
> hostnames?=20
>
I believe this is how some of the Unixs out there do it... but that=20
always seem a bit
verbose and non-exact...
>Both the one from gethostname() and the ones found by
> reverse lookup from the interfaces? Then I guess the meaning of the
> "-n" option could be changed to _add_ a hostname to the list of
> names to broadcast for?=20
> =20
>
Again I think this is a bit messy especially with hosts that have a ton=20
of interfaces and
aliases.... but anything is better than how it works today.... imho...
SteveD.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
[email protected] wrote on 11/23/2004 04:46:04 PM:
> Ragnar Kj=F8rstad wrote:
> >On Tue, Nov 23, 2004 at 03:28:07PM -0500, Steve Dickson wrote:
> >
> >
> >>Here is a patch that make sure the correct hostname is used
> >>in the SM_NOTIFY message what is sent from a rebooted server
> >>that has multiple network interfaces.
> >>
> >>Using the network part of the destination address, the correct netw=
ork
> >>interface is found. Then a gethostbyaddr() on that interface is don=
e,
> >>which yields the correct hostname that should be sent in the notify=
> >>message....
> >>
> >>Comments?
> >>
> >>
> >
> >It has been a while since I looked at this code, but:
> >1. What happens when you run statd with the "-n" option?
> > Does this patch override the name the user gave?
> >
> >
> hmm.... this is a problem, since the global SM_stat_chge.mon_name
> that the -n sets is now ignored... I guess I was thinking it would be=
better
> for statd to dynamically set the name that sent the notify message.
> But it would probably be a smart to maintain the same functionality.
> Question: do people actually run multiple statds using the -n to defi=
ne
> the interface they monitor? That's a scenario I guess I didn't thi=
nk
> of but
> it sound a bit awkward....
Yes, for HA NFS the server uses statd with -n and -N (notify only) for =
the
all the interfaces and aliases.
I posted a patch
http://marc.theaimsgroup.com/?l=3Dlinux-nfs&m=3D110064006512730&w=3D2
This fix will send the notify msg using the IP address specified with t=
he
-n option to statd. This will fix
the problem that statd in the kernel (on the client side) has of not be=
ing
able to convert mon_name to an IP address (no gethostbyname() in the
kernel) and any other clients that ignore the mon_name in the notify ms=
g
and use the source IP address from the RPC request.
> >2. Does this really find the correct hostname?
> > If I'm not mistaken, the nfs client needs to get a SM_NOTIFY mess=
age
> > with the hostname that it actually mounted from, right?
> >
> >
> right....
> > This may or may not match the hostname that the server find when
> > running gethostbyaddr on the interface's IP, so one can easily fi=
nd
> > scenarios where this patch will cause statd to stop working.
> >
> >
> I don't think this is an issue... as long as the hostname and all of =
its
> aliases
> resolve to the same ip address, things should work since its the ip
address
> the kernel needs to find the lock that has to be reclaimed... Now the=
> problem
> arises when the hostname resolves to a different ip address....
> something this patch
> is trying to address...
> > Now, there new behavious may actually be better, but I'm not sure=
> > it's acceptable to change it anyway?
> >
> >
> Is this truly a big thing? to explicitly define the hostname that wil=
l
> be monitored?
> > Could an alternative be to send out SM_NOTIFY messages for multip=
le
> > hostnames?
> >
> I believe this is how some of the Unixs out there do it... but that
> always seem a bit
> verbose and non-exact...
> >Both the one from gethostname() and the ones found by
> > reverse lookup from the interfaces? Then I guess the meaning of t=
he
> > "-n" option could be changed to _add_ a hostname to the list of
> > names to broadcast for?
> >
> >
> Again I think this is a bit messy especially with hosts that have a t=
on
> of interfaces and
> aliases.... but anything is better than how it works today.... imho..=
.
> SteveD.
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real use=
rs.
> Discover which products truly live up to the hype. Start reading now.=
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> NFS maillist - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs=
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
--- nfs-utils-1.0.6/utils/statd/rmtcall.c.orig 2004-11-24 05:42:13.494353000 -0500
+++ nfs-utils-1.0.6/utils/statd/rmtcall.c 2004-11-24 06:02:37.935145000 -0500
@@ -26,6 +26,7 @@
#include <sys/socket.h>
#include <sys/time.h>
#include <netinet/in.h>
+#include <net/if.h>
#include <arpa/inet.h>
#include <rpc/rpc.h>
#include <rpc/pmap_prot.h>
@@ -34,6 +35,7 @@
#include <netdb.h>
#include <string.h>
#include <unistd.h>
+#include <ifaddrs.h>
#include "sm_inter.h"
#include "statd.h"
#include "notlist.h"
@@ -73,7 +75,44 @@ statd_get_socket(int port)
return sockfd;
}
-
+/*
+ * Using the NL_ADDR(lp), reset (if needed) the hostname
+ * that will be put in the SM_NOTIFY to the hostname
+ * that is associated with the network interface
+ * that was monitored
+ */
+static void
+reset_my_name(notify_list *lp)
+{
+ struct ifaddrs *ifa = NULL, *ifap;
+ struct in_addr netaddr, tmp;
+ struct sockaddr_in *sin, *nsin;
+ struct hostent *hp;
+
+ netaddr.s_addr = inet_netof(NL_ADDR(lp));
+ if (getifaddrs(&ifa) >= 0) {
+ for (ifap = ifa; ifap != NULL; ifap = ifap->ifa_next) {
+ if (ifap->ifa_addr->sa_family != AF_INET)
+ continue;
+ if (!(ifap->ifa_flags & IFF_UP))
+ continue;
+ sin = (struct sockaddr_in *)ifap->ifa_addr;
+ nsin = (struct sockaddr_in *)ifap->ifa_netmask;
+ tmp.s_addr = sin->sin_addr.s_addr & nsin->sin_addr.s_addr;
+ if (memcmp(&tmp.s_addr, &netaddr.s_addr, sizeof(netaddr.s_addr)))
+ continue;
+ hp = gethostbyaddr((char *)&sin->sin_addr,
+ sizeof(sin->sin_addr), AF_INET);
+ if (hp == NULL)
+ continue;
+ if (strcmp(NL_MY_NAME(lp), hp->h_name)) {
+ free(NL_MY_NAME(lp));
+ NL_MY_NAME(lp)= strdup(hp->h_name);
+ }
+ }
+ }
+ return;
+}
/*
* Try to resolve host name for notify/callback request
*
@@ -283,6 +322,7 @@ process_entry(int sockfd, notify_list *l
{
struct sockaddr_in sin;
struct status new_status;
+ stat_chge new_stat;
xdrproc_t func;
void *objp;
u_int32_t proc, vers, prog;
@@ -309,9 +349,19 @@ process_entry(int sockfd, notify_list *l
/* Use source address for notify replies */
sin.sin_addr = lp->addr;
+ /*
+ * Unless a static hostname has been defined
+ * set the NL_MY_NAME(lp) hostname to the
+ * one associated with the network interface
+ */
+ if (!(run_mode & STATIC_HOSTNAME))
+ reset_my_name(lp);
func = (xdrproc_t) xdr_stat_chge;
- objp = &SM_stat_chge;
+ new_stat.state = MY_STATE;
+ new_stat.mon_name = NL_MY_NAME(lp);
+
+ objp = &new_stat;
break;
case NOTIFY_CALLBACK:
prog = NL_MY_PROG(lp);
--- nfs-utils-1.0.6/utils/statd/statd.c.orig 2004-11-24 05:42:15.099369000 -0500
+++ nfs-utils-1.0.6/utils/statd/statd.c 2004-11-24 05:52:27.570265000 -0500
@@ -288,6 +288,7 @@ int main (int argc, char **argv)
}
break;
case 'n': /* Specify local hostname */
+ run_mode |= STATIC_HOSTNAME;
MY_NAME = xstrdup(optarg);
break;
case 'P':
--- nfs-utils-1.0.6/utils/statd/statd.h.orig 2004-11-24 05:42:14.899371000 -0500
+++ nfs-utils-1.0.6/utils/statd/statd.h 2004-11-24 05:53:50.516929000 -0500
@@ -79,6 +79,7 @@ extern int run_mode;
/* LH - notify_only mode would be for notifying hosts on an IP alias
* that just came back up, for ex, when failing over a HA service to
* another host.... */
+#define STATIC_HOSTNAME 8 /* Always use the hostname set by -n */
/*
* Program name and version pointers -- See statd.c for the reasoning
On Wed, Nov 24, 2004 at 07:00:08AM -0500, Steve Dickson wrote:
> >If that's the case, are we allowed to just send the IP instead of the
> >name?
> >=20
> >
> No, since the spec says a the id_mon needs to be character string....
"10.0.0.1" is a character string as much as any - unless the
specification says something more about this?
> >- If you have aliases (eth0, eth0:0) with different IPs but on the
> > same network. The current patch (if I read it correctly) will then
> > use the name from the last alias, which is kind of random.
>
> Well it would not be random, it would be the first interface....
>=20
> >The second case may be very relevant to the HA-problem which "-n" was
> >originally added for.
> >=20
> >
> Yes... the -n flag wold be the answer here...
Unless, of course, a more general fix would handle this automatically.
And I think that could be something along the lines:
- loop over all available interfaces
- for each interface, send a message to all clients that belong on
this subnet
- the message could be based on the IP or gethostbyaddr(IP).
In short, this is exactly like what your patch does except that:
- if there are multiple matching interfaces (e.g. aliases) we
send messages for all
- I still don't understand why we don't send the IP instead of
the name.
Unlike sending messages for all names to all clients it's not too
verbose.
--=20
Ragnar Kj=F8rstad
Software Engineer
Scali - http://www.scali.com
High Performance Clustering
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
[email protected] wrote on 11/24/2004 09:35:25 AM:
> On Wed, Nov 24, 2004 at 07:00:08AM -0500, Steve Dickson wrote:
> > >If that's the case, are we allowed to just send the IP instead of =
the
> > >name?
> > >
> > >
> > No, since the spec says a the id_mon needs to be character string..=
..
> "10.0.0.1" is a character string as much as any - unless the
> specification says something more about this?
That would help statd that is running in the kernel and can not do
gethostbyname(). The problem right now is that the kernel statd ignores=
the
mon_name in the notify msg altogether and uses the uses the source IP
address from the RPC request. It would be nice if we send the notify ms=
g
from the same source as is specified in the -n option. This way what ev=
er
the client uses will result in the same the IP.
see:
http://marc.theaimsgroup.com/?l=3Dlinux-nfs&m=3D110064006512730&w=
=3D2
>
>
> > >- If you have aliases (eth0, eth0:0) with different IPs but on the=
> > > same network. The current patch (if I read it correctly) will the=
n
> > > use the name from the last alias, which is kind of random.
> >
> > Well it would not be random, it would be the first interface....
> >
> > >The second case may be very relevant to the HA-problem which "-n" =
was
> > >originally added for.
> > >
> > >
> > Yes... the -n flag wold be the answer here...
> Unless, of course, a more general fix would handle this automatically=
.
> And I think that could be something along the lines:
> - loop over all available interfaces
> - for each interface, send a message to all clients that belong on
> this subnet
> - the message could be based on the IP or gethostbyaddr(IP).
>
> In short, this is exactly like what your patch does except that:
> - if there are multiple matching interfaces (e.g. aliases) we
> send messages for all
> - I still don't understand why we don't send the IP instead of
> the name.
>
> Unlike sending messages for all names to all clients it's not too
> verbose.
> --
> Ragnar Kj=F8rstad
> Software Engineer
> Scali - http://www.scali.com
> High Performance Clustering
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real use=
rs.
> Discover which products truly live up to the hype. Start reading now.=
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> NFS maillist - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs=
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, Nov 24, 2004 at 05:08:11PM -0500, Steve Dickson wrote:
> Ragnar Kj=F8rstad wrote:
> >On Wed, Nov 24, 2004 at 07:00:08AM -0500, Steve Dickson wrote:
> >>No, since the spec says a the id_mon needs to be character string....
> >
> >"10.0.0.1" is a character string as much as any - unless the
> >specification says something more about this?
>
> Well here is what the spec says wrt to mon_names:
> "For maximum portability and interworking, it is recommended that=20
> applications
> and users define host names containing only the characters of the Porta=
ble
> Filename Characters defined in ISO/IEC 9945-1:1990."
>=20
> So doing some like would probably cause interopability issues with othe=
r
> OSes....
Well, I don't have the ISO/IEC 9945-1:1990 easily available, but I have
a hard time imagining a standard for Portable Filename Characters that
don't include number and '.'.
However, if it's possible that it will create compabilityproblems,
you're probably right - it's not worth the effort. After all, it only
matters if you have inconsistencies in your name-resolution system.=20
> >In short, this is exactly like what your patch does except that:
> >- if there are multiple matching interfaces (e.g. aliases) we
> > send messages for all
>
> Yes see your point, but is aliasing all that common in non-HA environme=
nts?
I don't have any statistics on that, but I don't think it's totally
unheard of :)
> The relatively simple patch I'm proposing is a small step in the right=
=20
> direction which would make statd work correctly on multihome servers.
Yes, I think it is.
> Should we strive to make statd more HA friendly, YES! but I would
> suggest one step at time.... Meaning we should propose this match to Ne=
il
> for inclusion in upstream and then build on it... imho...
I have no problem with that.
I had just hoped I could trick you into fixing one more thing once you
were on a roll :-)
--=20
Ragnar Kj=F8rstad
Software Engineer
Scali - http://www.scali.com
High Performance Clustering
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, Nov 24, 2004 at 10:43:04AM -0800, Marc Eshel wrote:
> > "10.0.0.1" is a character string as much as any - unless the
> > specification says something more about this?
>=20
> That would help statd that is running in the kernel and can not do
> gethostbyname(). The problem right now is that the kernel statd ignores=
the
> mon_name in the notify msg altogether and uses the uses the source IP
> address from the RPC request. It would be nice if we send the notify ms=
g
> from the same source as is specified in the -n option. This way what ev=
er
> the client uses will result in the same the IP.
> see:
> http://marc.theaimsgroup.com/?l=3Dlinux-nfs&m=3D110064006512730&w=
=3D2
Yes, let me adjust my proposal:
And I think that could be something along the lines:
* loop over all available interfaces
* for each interface, send a message to all clients that belong on
this subnet
* the message could be based on the IP or gethostbyaddr(IP).
+ make sure the outgoing message is sent from the interface it
applies to, so that it works with clients that look at the
source address instead of the name. (or look at both, but only
accept the message if they match).
I think this would cover absolutely all cases (with the exception of
source NAT, and that's pretty obscure!?), so I think it's fair to remove
"-n". (rather, it should give the user a message the option is obsolete
and is beeing ignored)
OK, so I didn't actually look closely at the code to if this could be
easily coded, but how hard can it be? :-)
--=20
Ragnar Kj=F8rstad
Software Engineer
Scali - http://www.scali.com
High Performance Clustering
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Ragnar Kj=F8rstad wrote:
>On Wed, Nov 24, 2004 at 07:00:08AM -0500, Steve Dickson wrote:
> =20
>
>>>If that's the case, are we allowed to just send the IP instead of the
>>>name?
>>>
>>>
>>> =20
>>>
>>No, since the spec says a the id_mon needs to be character string....
>> =20
>>
>
>"10.0.0.1" is a character string as much as any - unless the
>specification says something more about this?
> =20
>
Well here is what the spec says wrt to mon_names:
"For maximum portability and interworking, it is recommended that=20
applications
and users define host names containing only the characters of the Portabl=
e
Filename Characters defined in ISO/IEC 9945-1:1990."
So doing some like would probably cause interopability issues with other
OSes....
>In short, this is exactly like what your patch does except that:
>- if there are multiple matching interfaces (e.g. aliases) we
> send messages for all
> =20
>
Yes see your point, but is aliasing all that common in non-HA environment=
s?
The relatively simple patch I'm proposing is a small step in the right=20
direction
which would make statd work correctly on multihome servers.
Should we strive to make statd more HA friendly, YES! but I would
suggest one step at time.... Meaning we should propose this match to Neil
for inclusion in upstream and then build on it... imho...
SteveD.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Ragnar Kj=F8rstad wrote:
>I had just hoped I could trick you into fixing one more thing once you
>were on a roll :-)
> =20
>
Yes I was keenly aware of such efforts.... 8-) and a well place
Bugzilla report would be a good way to continue that effort,
since I do think tis important to make the HA support in nfs-utils
work as well as possible... Its just at this point of the release
cycle (at the end), I'm a bit hesitant to make any more changes
than are totally necessary.
SteveD.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs