I've had conversations about this multi-homed host problem with
several people in several contexts. It always seems to come down
to "damn, this is a pain".
The last time we talked about this, we were trying to figure out why,
with a multi-homed machine, you want want to limit some services to
some interfaces. It seemed that the most likely use case was that
people would want to separate "user" traffic from "admin" traffic.
It also seemed possible, but less likely, that people would want to
limit certain kinds of traffic to certain interfaces/networks, e.g.,
only allow multicast on a certain network or only allow ssh on a certain
network.
To make this all work, all the code that needs a host name for a machine
needs to be very clear about what it's going to use that host name for,
and choose the appropriate one of the many available. If we even want
to keep Server.getHost, we would have to be very clear about which host
name it returned. It might be better to do as Tom suggests and split it
into Server.getAdminHost, etc.
The nodehost value is probably a good default for the "admin host",
unless the admin listener overrides it. If the admin listener is
bound to a specific address, it seems that that's the address you're
going to need to connect to to connect to the admin listener. The
only obvious case I can think of where that might not be true is if
you were connecting through a proxy server, but I don't think we do
anything to allow any of our connections to be made through a proxy
server.
Joe Di Pol wrote on 08/ 9/10 10:49 AM:
>
> If I take a step back from GlassFish and generalize this I
> see:
>
> Configuration information that defines what hostname(s) the server
> should bind to.
>
> Configuration information that defines what hostname clients
> should connect to.
>
> In the world of DNS aliases, VIPS, etc these can be different
> for your general server.
>
> In our case I think the admin-listener information is the former, and
> node-host is the later. The node-host is the hostname that
> clients (the DAS) should connect to when they need to do GlassFish
> administrative stuff.
>
> So the current behavior seems correct to me. I guess then the question
> is should it be optimized for expected GlassFish deployments, like
> you propose, to eliminate potential human error.
>
> Are we sure there is not a valid use case where the hostname the DAS
> should use to connect to an instance is different from the hostname
> the admin-listener is bound to (other than the 0.0.0.0 case)?
>
> Joe
>
>
> Tom Mueller wrote:
>> I'm working on issue 12666, which is to make sure that the DAS and
>> clustering will work on a multi-address server, i.e., a server with
>> multiple NICs. It is possible to get this to work, but there is some
>> questionable behavior regarding command replication and commands that
>> invoke commands on instances. I'd like to get some input as to whether
>> this questionable behavior needs to be fixed.
>>
>> As an example, consider the list-instances command. This command runs
>> __locations and uptime on each instance. It gets the server name for
>> the instance by calling Server.getHost, which looks up the nodehost
>> attribute for the node element for the server. It never looks at the
>> "address" property of the admin-listener to which it is going to
>> connect. To get the list-instances command to work correctly in the
>> multi-address case, the listeners are configured to bind to a
>> particular hostname (rather than 0.0.0.0), so the nodehost for the
>> node for the instance has to be set to use the same hostname as the
>> admin-listener for that instance. (This is the questionable behavior).
>>
>> To fix this, we could have Server.getHost look at the admin-listener
>> for the host, and if the "address" property is not 0.0.0.0, then
>> return that. Otherwise, look at the nodehost value for the node as it
>> does currently. Or, we could add a new method, Server.getAdminHost, or
>> we could get rid of Server.getHost and have Server.getAdminHost and
>> Server.getNodeHost. This all depends on what callers of Server.getHost
>> are really expecting to get.
>>
>> The same problem occurs with command replication. I didn't dig into
>> it, but I expect that it is calling Server.getHost also to determine
>> what hostname to use in replicating the command. Vijay, can you
>> confirm that this is how command replication gets the hostname?
>>
>> Thoughts?
>> Thanks.
>> Tom
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>