Re: gethostname returns loginname on "Pather Server" version
Re: gethostname returns loginname on "Pather Server" version
- Subject: Re: gethostname returns loginname on "Pather Server" version
- From: Allan Nathanson <email@hidden>
- Date: Sat, 7 Feb 2004 12:54:03 -0500
As has been mentioned on this list (and others) numerous times, there
are many ways to find out what IP address are currently in use on a
system. The gotcha is that there are lots of people who believe that a
system has one and only one IP address. This is no longer the case.
Many systems have more than one IP address. Which one do you want?
But, to answer your question... Using BSD calls the recommended API
would be getifaddrs(3) to get the addresses (yes, plural) and then
"pick one". If you want to step up a layer you can use the
SystemConfiguration.framework APIs to capture what we believe to be the
"primary" IP address. ... and many other APIs exist.
But, before you go down this path... Why do you need the hosts IP
address in the first place? Do you really think you can do something
useful with it? What do you do if the address you get is on a private
network behind a NAT?
- Allan
On Feb 7, 2004, at 6:55 AM, Sanjay Arora wrote:
That means relying on the name returned by gethostname() isn't
sufficient,
as it may not have any association with a DNS name.
given these scenarios then, what would be the best and consize way for
a
to find the IPAddress of the System in a BSD way which works for all
systems.
Regards
Sanjay
-----Original Message-----
From: Allan Nathanson [mailto:email@hidden]
Sent: Saturday, February 07, 2004 7:41 AM
To: Jason Linhart
Cc: email@hidden
Subject: Re: gethostname returns loginname on "Pather Server" version
Why can't I name my computer "admin"? Should all currently defined
login names be excluded as possible host names?
And as to any conventions used for setting the BSD hostname
(gethostname(3), sethostname(3))... You are correct that the standards
are ambiguous. Suggesting that the name have some relevance to a hosts
DNS name, while a nice idea, makes a number of assumptions including:
- the system is actually connected to a network
- the system has only one network interface
- the system has only one IP address
- only one name is associated with the one IP address
Unfortunately, you can't make any of these assumptions. The world of
computers is no longer as simple as the days when all computers were
large, bolted to the floor, and non-functional unless the network was
accessible.
What are we (Apple) doing? Here's the algorithm that we use to set the
BSD hostname:
1. if available, use the name specified in the /etc/hostconfig file
(HOSTNAME=my-host-name)
... and this name need not have any association with a DNS
name
2. if available, use the name provided by the DHCP/BOOTP server for
the "primary" IP address
... and this name need not have any association with a DNS
name
3. if available, use the [first] name returned by a reverse DNS
(address-->name) query for the "primary" IP address
4. if available, use the rendezvous hostname
5. use "localhost"
In short, we "try" to set the BSD hostname to something reasonable but
there are no guarantees.
- Allan
p.s. I believe that Mac OS X Server systems tend to set a fixed name in
the /etc/hostconfig file.
On Feb 6, 2004, at 8:35 PM, Jason Linhart wrote:
On 2/6/04 7:47 PM Justin Walker (email@hidden) wrote:
Bottom line: don't use gethostname(); anyone with root access on that
machine can set the 'hostname' to be anything he wants. It is not
related to any "standard", except by convention.
There are a great many things that a program with root access can do,
but
just because they can do something, that doesn't make that behavior
either correct or useful.
There is a clear standard. gethostname() is defined both by POSIX and
by
Darwin in the same way. Just because the standard is not enforced by
the
kernel doesn't mean that violating the standard is not a bug.
The difficulty here is not the lack of a standard, it is the ambiguity
of
the standard. The spec calls for the "standard host name".
Unfortunatly,
that is ambiguous. The spec is not specific enough to require a valid
DNS
name, but it is specific enough to disallow things which could not
possibly be a host name. A DNS name would be compliant, an AppleTalk
name
would be compliant, a name typed into a system configuration dialog
box
as "Commputer Name" would be compliant, various other things would be
compliant, but a user name would not be compliant.
Jason
-----------------
email@hidden
-----------------
Dr. Seuss books . . . can be read and enjoyed on several levels. For
example, 'One Fish Two Fish, Red Fish Blue Fish' can be deconstructed
as a searing indictment of the narrow-minded binary counting system.
-- Peter van der Linden, Expert C Programming, Deep C Secrets
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.