RE: get host IP address -- MIDRANGE-L

Based on your reply, it sounds like this is a FAQ, so I apologize for
posting it.

Yeah, here it is in the Midrange.com FAQ:http://faq.midrange.com/index.pl?file=59


Here's a related discussion from earlier in the week:
http://archive.midrange.com/midrange-l/200508/threads.html#01506

Here's the discussion from August 16th (started by Dwayne Allison) wherethe same thing was asked (note that you participated in this discussion!)

http://archive.midrange.com/midrange-l/200508/threads.html#00833

Here's my description of why I wouldn't use DNS to solve the problem, fromAugust 17th:

http://archive.midrange.com/midrange-l/200508/msg00936.html

And that's just within the past month on this particular mailing list:) So, yeah, it's a FAQ. :)

But, I don't mind you posting it again, it's obviously that it's somethingthat people don't understand, so I thought I'd give a more verbose answerthis time.

Since the tool could be running in shops with many iSeries and the
WebService consumer (i.e. Tivoli) needs to differentiate between different
iSeries somehow, CBE needs to have the IP tag field populated by our tool.
Based on these requirements, I'd say it falls under "auditing and like"
definition from your post (i.e. system management and tracking).


I agree.

I realize that iSeries can have many network interfaces, but we can'tput them all in, only one. I looked at your code and it looks likeyou're using ioctl calls to get info on each interface. This seems likethe "right" approach, but how do we pick one of the interfaces? Isthere a naming convention for the Ethernet line interfaces? I thinkthat's the one we'd want, right? I mean what would be the point ofputting loopback or dial-up interface address? Ethernet lines are morelikely to be used in their internal LAN.

Yep, that's the problem... and I think you're probably approaching it thebest way that you can. gethostname() is the right API to find out whatthe system operator considers the "canonical name" of the system. The IPaddress that it corresponds to SHOULD be the "One True IP Address" of thesystem.


Unfortunately, there are a lot of scenarios where this won't work.

The most obvious -- a situation where they've set up an internalnetwork that doesn't use domain names. They do everything directly by IPaddress -- in that situation, there won't be a domain name to look up toget the IP address.

Or, they may have a bogus hostname set up for their system. Very littlerelies on the host name that's configured under CHGTCPDMN, so it may notbe correct. In this case, gethostname() will return something, butgethostbyname() may fail, or worse, if they used the name of anothercomputer, it may give you wrong information.

Of course, the fix is relatively simple... just tell whomever isinstalling the software that they have to have a valid hostname set upwith CHGTCPDMN and that it should resolve to the IP address. If not, tellthem to change their host name search priority to *LOCAL and put the hostin the hosts table.

But, that's the problem with th gethostname/gethostbyname solution, itrelies on the user to have their system configured properly, and to beusing DNS. Unfortunately, it's probably your best option. It's the waythat Sendmail does it, if that means anything to you.

Other than that, all you can really do is have a configuration optionwhere the system operator tells you which interface to extract the infofrom.

Presently, we have gethostname-gethostbyname-inet_ntoa working in our
development environment by selecting first element of the h_addr_list array,
but as you say, what are the guarantees of it working in all environments.
I don't know how likely they're to have hosts table or DNS setup. I'd think
if they're running something like Tivoli, they'd need something like that,
wouldn't they?

I know absolutely nothing about Tivoli. I'm not even sure what it is. I'vebeen to Tivoli Gardens in Italy, but I don't think that's what you mean :)