What I did not check, was if the federation process worked if the ethernet
interface was listed first in chandev.conf.
Here's why I think it is broken.
The target node, 'Phalen' already KNOWS what it's DNS name and IP address
are. Furthermore, so does the WebSphere node on 'Calhoun'. It was given the
DNS name of the target server to perform the action against. Previous
messages in the process indicate success at resolving 'Phalen' at the
correct IP address because it actually managed to shut WebSphere down on
that system to do the federation actions.
There is NO way that WebSphere on 'Calhoun' can learn about what the IP
address of the hipersocket on Phalen is. Phalen, in the process of being
federated HAS to tell the process on Calhoun about itself, including the IP
address of the ethernet interface it is using. It reports the wrong
information, and of course, the sanity check in the process running on
Calhoun fails. I agree the sanity check is absolutely required. But the
question is still why are you returning the first network device/IP address
you discover? Why are you not asking whether or not this interface is
correct. This of course, only becomes an issue if you 1) define the
hipersocket interface before installing WebSphere and 2) whether or not you
made the changes to chandev.conf so that the entry that corresponds to hsi1
is after the entry for eth0.
David Boyes
<[EMAIL PROTECTED]
e.net> To
Sent by: Linux on [EMAIL PROTECTED]
390 Port cc
<[EMAIL PROTECTED]
IST.EDU> Subject
Re: WebSphere and multi-node cells
09/08/2004 11:29
AM
Please respond to
Linux on 390 Port
<[EMAIL PROTECTED]
IST.EDU>
I think I'd argue it's not a bug at all.
> I added the hipersocket interface to /etc/chandev.conf on
> this particular
> system by hand because yast doesn't appear to do that. In
> doing so, I put
> it ahead of the ethernet interface. This changes the order in which it
> appears in /proc/qeth. The hipersocket address in that
> situation gets top
> billing.
So far, Working As Designed.
> It appears that WebSphere in the Federation process,
> interrogates the node
> being brought in and gets some information from that system.
> Specifically,
> it appears to return the first interface defined in either
> /etc/chandev.conf, or more likely, /proc/qeth, as the
> ethernet interface to
> use to talk to that node.
Looks like it's trying to do a gethostbyname() or gethostbyaddr() and,
getting nothing from DNS or /etc/hosts, failing with a message. Again,
WAD.
> The IP address is returned to the
> node on the
> system that is doing the federation, and of course the lookup
> by hostname
> isn't going to resolve to the IP address of the hipersocket. It's
> non-routeable and not defined to our DNS.
This is actually the problem, IMHO. DNS has been around for over 20
years now. "Security" by not listing hosts in DNS is a fallacy. It just
makes migration and maintenance harder, and causes problems like this.
There's no good reason *not* to define every valid IP address in your
organization in DNS forward and reverse zones, and keep in mind that a
host name *can* resolve to multiple addresses, eg:
fubar IN A x.y.z.q
IN A p.d.q.b
or
fubar IN CNAME fubar-eth0.
fubar-eth0 IN A x.y.z.q
fubar-eth1 IN A p.d.q.b
with appropriate PTR records in the reverse zones.
The CNAME in the second example is because I prefer to list individual
interfaces separately (eg, fubar, fubar-eth1, fubar-eth2, etc) in case I
need to move them around later without having to touch all the clients
or a VIPA requirement comes along, but either syntax above will work
properly to allow gethostbyname() or gethostbyaddr() to work. If you're
using a modern BIND (post-version 5), you can split-horizon it so that
external lusers get a different view than internal users w/o a lot of
effort. Note that the first example is NOT guaranteed to return the
addresses in the order you list them, so in that case, it DOES matter
whether the address is routable and whether your DNS is in split-horizon
mode or not.
In any case, if the IP address returned from DNS is not routable, other
people won't be able to get to it anyway. If the reason it's not in DNS
is political, it's easy to set up a local caching BIND instance and use
that within your box as the first DNS in the chain, and let it recurse
up the chain for the other stuff -- better yet, get your network admins
to delegate you a proper subdomain for stuff inside the box, and
maintain it yourself.
I'd commend the WAS programmers in this case -- checking to see if the
IP address actually matches the host name is a good bit of defensive
programming.
-- db
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
