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
