Menu
▾
▴
bigdata-developers
|
From: Bryan T. <br...@sy...> - 2010-07-15 22:23:29
|
Brian,
Could you please update NicUtil and the build.xml file to parameterize them for the ethernet interface? That value is currently a hardwired in NicUtil to "eth0". I would like to see if I can get the federation to stand up on on a Windows Server machine by specifying the appropriate Ethernet interface in build.properties (I finally tracked down which interface is used by the Windows 2008 Server (eth3 in this specific case)).
I wonder if we could find an "appropriate" default interface by testing all interfaces reported by NicUtil.getNetworkInterfaceArray("all") until we find one for which an IP address is returned by NicUtil.getIPAddress. Would that make any sense?
Thanks,
Bryan
> -----Original Message-----
> From: Brian Murphy
> Subject: Re: NicUtil
>
> ext Bryan Thompson wrote:
> > Brian,
> >
> > I am having a difficulty with NicUtil on a Windows Server
> 2008 machine.
> >
> > getIpAddressByLocalHost => 192.168.1.103
> >
> > getIpAddress eth0 => NIC_DOES_NOT_EXIST
> >
> > The machine has both IPv4 and IPv6 capability, but only
> IPv4 is setup.
> > It's using DHCP and I tried changing it to a dixed IP, but that did
> > not resolve the situation. Can you suggest what the
> problem might be?
>
> Yes, whereas the network names 'eth0', 'eth1', etc. are the
> common defaults on linux, Windows seems to do things
> differently. If you execute ipconfig on you Windows box, the
> output should display a line of the form:
>
> Ethernet adapter <589D05FD-D5A8-4054-B671-C12A19220CB9>
>
> It's been a while since I've looked at Windows, but I believe
> that if you were then to write some Java code that retrieved
> and displayed the network interface(s) on that box (for
> example, using NicUtil.getNetworkInterfaceArray("all")), you
> would see that the network interface name(s) that are
> displayed are of the form 'ethN' for some value of N; rather
> than the value ipconfig displays. If I recall correctly,
> somewhere deep down in the bowels of Java, it appears that
> Java does some sort of mapping from the ethernet adapter name
> that Windows knows to an 'ethN' form. Unfortunately, it seems
> that the algorithm Java uses to determine the value of N does
> not necessarily follow the order one would expect; that is, 0
> is not always the first value, followed by 1 for the next
> interface, and so on.
>
> For example, I recall a Windows node with 4 network
> interfaces in which Java mapped the interfaces to something
> like [eth11, eth15, eth16, and eth19].
>
> The use of 'eth0' was made the default to cover the common
> case; to minimize how often folks would have to determine and
> then supply a system's network interface name.
>
> For what it's worth, to address the Windows situation
> described above, I imagine one could write some additional
> code that determines if one is running on Windows, and then
> interprets 'eth0' as a desire to use the first interface,
> 'eth1' as the second interface, and so on. Since Windows
> isn't a requirement for DataOS though, I didn't focus on
> investigating such additional functionality.
>
> Brian
>
>
>
>
|
|
From: Brian M. <btm...@gm...> - 2010-07-16 14:06:38
|
On Thu, Jul 15, 2010 at 6:22 PM, Bryan Thompson <br...@sy...> wrote:
Could you please update NicUtil and the build.xml file to parameterize them
> for the ethernet interface? That value is currently a hardwired in NicUtil
> to "eth0".
Um, where do you see eth0 "hardwired" in NicUtil?
The only place where eht0 is mentioned in that class is
in one of the versions of the getInetAddress convenience
method; the version that allows one to pass in a Configuration,
and then defaults to eth0 if the given Configuration does
not specify an entry with the given entry name. Additionally,
as far as I can tell, that version of getInetAddress is never
called anywhere in the Bigdata code.
So it's not clear to me why you would characterize eth0 as
"hardwired".
I would like to see if I can get the federation to stand up on on a Windows
> Server machine by specifying the appropriate Ethernet interface in
> build.properties (I finally tracked down which interface is used by the
> Windows 2008 Server (eth3 in this specific case)).
>
When you say "get the federation to stand up on a Windows Server machine",
do you mean "use bigdataCluser(16).config/bigdataStandalone.config in
combination with 'bigdata start' to start the appropriate services", or do
you
mean "run the tests on the Windows box using build.xml"?
Although I would generally have guessed that "stand up a federation"
refers to the former, the fact that you initially requested that "build.xml
be updated" makes me think that maybe you mean the latter.
If the former, I'm not sure what sort of "parameterization updates" you
think need to be made to NicUtil that would help you in that case;
especially given that bigdataCluser(16).config/bigdataStandalone.config
currently do not use NicUtil, but specify explicit IP addresses instead.
On the other hand, if it's the latter -- that is, if you want to run the
tests
on Windows -- then I'm still not sure what you mean by "parameterization
updates"
of either NicUtil or build.xml. Are you asking that a system property be
set when the junit target is executed that specifies the network interface
on which to export the services? Or something else?
If you are asking for a new system property in build.xml, then I'm still
not sure what this has to do with NicUtil. I believe such a system property
would affect only the test config files, not NicUtil. There are about five
test related config files that use eth0 as the network interface name, but
all but one of them fall back to local host if eth0 does not exist on the
system. The one config file that doen't fallback to local host may be
a bug; I'll have to look into it.
> I wonder if we could find an "appropriate" default interface by testing all
> interfaces reported by NicUtil.getNetworkInterfaceArray("all") until we find
> one for which an IP address is returned by NicUtil.getIPAddress. Would that
> make any sense?
>
It might make sense, yes; especially in a development -- rather than
deployment
scenario. In a deployment scenario, although I could imagine that there may
be some deployment scenarios where one doesn't care what interface(s) their
network traffic is sent over, it's been my experience that that is typically
not
the case. So I would generally expect that one would want to explicitly
specify the network interface names in a real deployment, and fail fast if
one or more of the expected/specified interfaces are not available.
So I think your suggestion for adding a method that walks through
the network interfaces and returns an appropriate default IP may
be a useful convenience for development scenarios, but I'm still
not sure where the requested "parameterization" of NicUtil and
build.xml fits in with this suggestion.
With respect to deployment scenarios though, I caution anyone
who may be contemplating relaying on such a default mechanism
in their own real deployments; as I can assure you that we certainly
won't be deploying bigdata with default network interfaces.
Anyway, once I get a better sense of the problem, I'll start
investigating what sort of changes can/should be made.
BrianM
|
|
From: Bryan T. <br...@sy...> - 2010-07-16 14:12:36
|
Ah, my fault. It is LookupStarter on line #73 which references NicUtil using "eth0".
private static String thisHost = NicUtil.getIpAddress("eth0");
That is the bit which is unparameterized.
Thanks,
Bryan
________________________________
From: Brian Murphy [mailto:btm...@gm...]
Sent: Friday, July 16, 2010 9:35 AM
To: big...@li...
Subject: Re: [Bigdata-developers] NicUtil
On Thu, Jul 15, 2010 at 6:22 PM, Bryan Thompson <br...@sy...<mailto:br...@sy...>> wrote:
Could you please update NicUtil and the build.xml file to parameterize them for the ethernet interface? That value is currently a hardwired in NicUtil to "eth0".
Um, where do you see eth0 "hardwired" in NicUtil?
The only place where eht0 is mentioned in that class is
in one of the versions of the getInetAddress convenience
method; the version that allows one to pass in a Configuration,
and then defaults to eth0 if the given Configuration does
not specify an entry with the given entry name. Additionally,
as far as I can tell, that version of getInetAddress is never
called anywhere in the Bigdata code.
So it's not clear to me why you would characterize eth0 as
"hardwired".
I would like to see if I can get the federation to stand up on on a Windows Server machine by specifying the appropriate Ethernet interface in build.properties (I finally tracked down which interface is used by the Windows 2008 Server (eth3 in this specific case)).
When you say "get the federation to stand up on a Windows Server machine",
do you mean "use bigdataCluser(16).config/bigdataStandalone.config in
combination with 'bigdata start' to start the appropriate services", or do you
mean "run the tests on the Windows box using build.xml"?
Although I would generally have guessed that "stand up a federation"
refers to the former, the fact that you initially requested that "build.xml
be updated" makes me think that maybe you mean the latter.
If the former, I'm not sure what sort of "parameterization updates" you
think need to be made to NicUtil that would help you in that case;
especially given that bigdataCluser(16).config/bigdataStandalone.config
currently do not use NicUtil, but specify explicit IP addresses instead.
On the other hand, if it's the latter -- that is, if you want to run the tests
on Windows -- then I'm still not sure what you mean by "parameterization updates"
of either NicUtil or build.xml. Are you asking that a system property be
set when the junit target is executed that specifies the network interface
on which to export the services? Or something else?
If you are asking for a new system property in build.xml, then I'm still
not sure what this has to do with NicUtil. I believe such a system property
would affect only the test config files, not NicUtil. There are about five
test related config files that use eth0 as the network interface name, but
all but one of them fall back to local host if eth0 does not exist on the
system. The one config file that doen't fallback to local host may be
a bug; I'll have to look into it.
I wonder if we could find an "appropriate" default interface by testing all interfaces reported by NicUtil.getNetworkInterfaceArray("all") until we find one for which an IP address is returned by NicUtil.getIPAddress. Would that make any sense?
It might make sense, yes; especially in a development -- rather than deployment
scenario. In a deployment scenario, although I could imagine that there may
be some deployment scenarios where one doesn't care what interface(s) their
network traffic is sent over, it's been my experience that that is typically not
the case. So I would generally expect that one would want to explicitly
specify the network interface names in a real deployment, and fail fast if
one or more of the expected/specified interfaces are not available.
So I think your suggestion for adding a method that walks through
the network interfaces and returns an appropriate default IP may
be a useful convenience for development scenarios, but I'm still
not sure where the requested "parameterization" of NicUtil and
build.xml fits in with this suggestion.
With respect to deployment scenarios though, I caution anyone
who may be contemplating relaying on such a default mechanism
in their own real deployments; as I can assure you that we certainly
won't be deploying bigdata with default network interfaces.
Anyway, once I get a better sense of the problem, I'll start
investigating what sort of changes can/should be made.
BrianM
|
|
From: Brian M. <btm...@gm...> - 2010-07-16 15:43:20
|
On Fri, Jul 16, 2010 at 10:11 AM, Bryan Thompson <br...@sy...> wrote: Ah, my fault. It is LookupStarter on line #73 which references NicUtil > using "eth0". > Okay. For what it's worth, the original intent of the LookupStarter class was to provide a convenient utility for the build.xml to use to auto-start and auto-stop a lookup service that is external to the running of the junit tests themselves. It was never intended to be used in deployment. At some point I believe you moved that class from the test area to the bigdata source area. That fact, and the fact that there's commented out code in the JiniServicesHelper class that references LookupStarter, seems to imply that there's a possible/future intent to use that utility in the ServicesManagerService deployment mechanism. It would be my recommendation to not do this. Instead, I would recommend that the Jini ServiceStarter/NonActivatableServiceDescriptor mechanism continue to be used. BrianM |
|
From: Bryan T. <br...@sy...> - 2010-07-16 15:52:08
|
Brian, This currently blocking running unit tests against the federation on a single machine when that machine does not use eth0. Let's take up the issue of how to start services separately. Thanks, Bryan ________________________________ From: Brian Murphy [mailto:btm...@gm...] Sent: Friday, July 16, 2010 11:43 AM To: big...@li... Subject: Re: [Bigdata-developers] NicUtil On Fri, Jul 16, 2010 at 10:11 AM, Bryan Thompson <br...@sy...<mailto:br...@sy...>> wrote: Ah, my fault. It is LookupStarter on line #73 which references NicUtil using "eth0". Okay. For what it's worth, the original intent of the LookupStarter class was to provide a convenient utility for the build.xml to use to auto-start and auto-stop a lookup service that is external to the running of the junit tests themselves. It was never intended to be used in deployment. At some point I believe you moved that class from the test area to the bigdata source area. That fact, and the fact that there's commented out code in the JiniServicesHelper class that references LookupStarter, seems to imply that there's a possible/future intent to use that utility in the ServicesManagerService deployment mechanism. It would be my recommendation to not do this. Instead, I would recommend that the Jini ServiceStarter/NonActivatableServiceDescriptor mechanism continue to be used. BrianM |
Thanks for helping keep SourceForge clean.
X