STATD - SM_NOTIFY have wrong ID_NAME on multihost servers.

PATCH In review Steve Dickson 3 participants 12 messages Nov 23, 2004 – Nov 26, 2004

Subsystems (2)

NFS client NFS server

lore

Share & tools

lore

Steve Dickson

author

2004-11-23 20:28 UTC #0 lore raw

PATCH 1/1 STATD - SM_NOTIFY have wrong ID_NAME on multihost servers.

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.

utils/statd/rmtcall.c renamed from utils/statd/rmtcall.c.orig +47 -2

@@ -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 @@
 
 	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 @@
 {
 	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,14 @@
 
 		/* Use source address for notify replies */
 		sin.sin_addr   = lp->addr;
+		/* Make sure the correct hostname is sent */
+		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);

Ragnar Kjørstad

2004-11-23 23:26 UTC #1 lore raw

Quoted 10 lines · Steve Dickson

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

Steve Dickson

author

2004-11-24 00:44 UTC #2 lore raw

Quoted 12 lines · Ragnar Kj=F8rstad wrote:

On Tue, Nov 23, 2004 at 03:28:07PM -0500, Steve Dickson wrote:
=20
Quoted 9 lines
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....

Quoted 9 lines

Quoted 3 lines
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....

Quoted 5 lines

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....

Quoted 5 lines

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...

Quoted 4 lines

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?

Quoted 3 lines

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...

Quoted 6 lines

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

Ragnar Kjørstad

2004-11-24 02:01 UTC #3 lore raw

Quoted 6 lines · Steve Dickson

Quoted 3 lines · 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

Quoted 5 lines

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

Quoted 2 lines

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().

Quoted 10 lines

Quoted 3 lines
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
Quoted 3 lines
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

Quoted 2 lines

aliases
resolve to the same ip address, things should work since its the ip add=

ress

Quoted 1 line

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?

Quoted 5 lines

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

Quoted 5 lines

Quoted 2 lines
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.

Quoted 6 lines

Quoted 3 lines
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.

Quoted 6 lines

Quoted 4 lines
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

Quoted 2 lines

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

Marc Eshel

2004-11-24 04:42 UTC #11 lore raw

In reply to Steve Dickson

[email protected] wrote on 11/23/2004 04:46:04 PM:

Quoted 10 lines

Quoted 8 lines · Ragnar Kj=F8rstad wrote:
Quoted 5 lines · Steve Dickson
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

Quoted 1 line

Quoted 1 line
Quoted 1 line
interface is found. Then a gethostbyaddr() on that interface is don=

Quoted 8 lines

Quoted 8 lines
Quoted 7 lines
which yields the correct hostname that should be sent in the notify=
message....
Comments?

Quoted 7 lines

Quoted 5 lines
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

Quoted 4 lines

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=

Quoted 1 line

the interface they monitor? That's a scenario I guess I didn't thi=

Quoted 2 lines

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.

Quoted 2 lines

Quoted 2 lines
2. Does this really find the correct hostname?
If I'm not mistaken, the nfs client needs to get a SM_NOTIFY mess=

age

Quoted 7 lines

Quoted 3 lines
with the hostname that it actually mounted from, right?
right....
Quoted 2 lines
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=

Quoted 4 lines

Quoted 3 lines
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

Quoted 2 lines

aliases
resolve to the same ip address, things should work since its the ip

address

Quoted 7 lines

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...

Quoted 6 lines

Quoted 5 lines
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=

Quoted 3 lines

be monitored?
Quoted 1 line
Could an alternative be to send out SM_NOTIFY messages for multip=

Quoted 8 lines

Quoted 2 lines
hostnames?
I believe this is how some of the Unixs out there do it... but that always seem a bit
verbose and non-exact...
Quoted 2 lines
Both the one from gethostname() and the ones found by
reverse lookup from the interfaces? Then I guess the meaning of t=

Quoted 5 lines

Quoted 4 lines
"-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=

Quoted 2 lines

of interfaces and
aliases.... but anything is better than how it works today.... imho..=

Quoted 6 lines

SteveD.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real use=

rs.

Quoted 6 lines

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=

Steve Dickson

author

2004-11-24 11:57 UTC #4 lore raw

In reply to Ragnar Kjørstad

Quoted 16 lines · Ragnar Kjørstad

Quoted 13 lines · Steve Dickson
Quoted 5 lines · Ragnar Kjørstad
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.

Quoted 9 lines

Quoted 5 lines
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 of but it sound a bit awkward....
Let me just explain why -n was added in the first place:

thanks... that gave me a bit more insight on how the -n is used....

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
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.

Quoted 10 lines

Quoted 5 lines
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...
OK, so the client maps the name back to the IP?
and compares it to gethostbyname() on the hostname that it used to mount?

close, the client statd does the gethostbyname() and send the ip address to the kernel via loopback... The kernel then uses that ip address along with protocol and version to locate the lock.

Quoted 6 lines

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?

No, since the spec says a the id_mon needs to be character string....

Quoted 12 lines

Quoted 7 lines
Now the problem
arises when the hostname resolves to a different ip address.... something this patch is trying to address...
I didn't know the client actually compared IPs - I thought it compared the actual names.

The kernel searches the list of nlm_hosts look for the correct ipaddr,proto,vers threesome...

Quoted 7 lines

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.

Well I don't think it possible to program for a screwy DNS servers, or should we try.... imho...

Quoted 5 lines

- 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....

Quoted 4 lines

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...

Quoted 4 lines

<>
There are two reasons to keep -n:

I see your point.... especially since all the HA code is now in the updated FC3 nfs-utils... Believe me the last thing I want to do is break that code.... ;-) so attached is an updated patch that should not affect the HA code at all....

SteveD.

utils/statd/rmtcall.c renamed from utils/statd/rmtcall.c.orig +52 -2

@@ -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);

utils/statd/statd.c renamed from utils/statd/statd.c.orig +1 -0

@@ -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':

utils/statd/statd.h renamed from utils/statd/statd.h.orig +1 -0

@@ -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

Ragnar Kjørstad

2004-11-24 17:35 UTC #5 lore raw

Quoted 5 lines · Steve Dickson

Quoted 4 lines
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?

Quoted 11 lines

Quoted 3 lines
- 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
Quoted 4 lines
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

Marc Eshel

2004-11-24 18:43 UTC #6 lore raw

[email protected] wrote on 11/24/2004 09:35:25 AM:

Quoted 2 lines · Steve Dickson

Quoted 1 line
Quoted 1 line
If that's the case, are we allowed to just send the IP instead of =

the

Quoted 4 lines

Quoted 4 lines
Quoted 3 lines
name?
No, since the spec says a the id_mon needs to be character string..=

Quoted 2 lines

"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

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
- 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=

Quoted 5 lines

Quoted 5 lines
Quoted 1 line
use the name from the last alias, which is kind of random.
Well it would not be random, it would be the first interface....
Quoted 1 line
The second case may be very relevant to the HA-problem which "-n" =

was

Quoted 6 lines

Quoted 4 lines
Quoted 3 lines
originally added for.
Yes... the -n flag wold be the answer here...
Unless, of course, a more general fix would handle this automatically=

Quoted 24 lines

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

Quoted 3 lines

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real use=

rs.

Quoted 6 lines

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ørstad

2004-11-24 20:35 UTC #7 lore raw

Quoted 5 lines · Marc Eshel

Quoted 2 lines
"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

Quoted 2 lines

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=

Quoted 1 line

from the same source as is specified in the -n option. This way what ev=

Quoted 3 lines

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

Steve Dickson

author

2004-11-24 22:05 UTC #8 lore raw

In reply to Ragnar Kjørstad

Quoted 9 lines · Ragnar Kj=F8rstad wrote:

On Wed, Nov 24, 2004 at 07:00:08AM -0500, Steve Dickson wrote:
=20
Quoted 6 lines
Quoted 6 lines
If that's the case, are we allowed to just send the IP instead of the name?
    =20

Quoted 8 lines

Quoted 3 lines
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....

Quoted 5 lines

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ørstad

2004-11-24 23:25 UTC #9 lore raw

Quoted 11 lines · Steve Dickson

Quoted 5 lines · Ragnar Kj=F8rstad wrote:
Quoted 1 line · Steve Dickson
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

Quoted 3 lines

Filename Characters defined in ISO/IEC 9945-1:1990."
=20
So doing some like would probably cause interopability issues with othe=

Quoted 1 line

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

Quoted 5 lines

Quoted 3 lines
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 :)

Quoted 1 line

The relatively simple patch I'm proposing is a small step in the right=

=20

Quoted 1 line

direction which would make statd work correctly on multihome servers.

Yes, I think it is.

Quoted 2 lines

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=

Quoted 1 line

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

Steve Dickson

author

2004-11-26 12:58 UTC #10 lore raw

Quoted 4 lines · 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