[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Hostname "Chicken and Egg"



Rick Stevens wrote:
Bob Kinney wrote:

Happy Holidays all--

I'm running RH9, and recently switched from being directly connected to
the internet (dhcp giving me a publicly routed address) to being behind
a router.

I reconfigured my IP address to be a static, private one now, and my hostname now comes up as "localhost.localdomain". I'm trying to name the
host "vectra".


Looking at the man page for hostname, it says that:
" The host name is usually set once at system startup in
/etc/rc.d/rc.inet1 or /etc/init.d/boot (normally by reading the con-
tents of a file which contains the host name, e.g. /etc/hostname)."


Although the files mentioned aren't there, I found in /etc/rc.sysinit
a section that seems to set the hostname by *calling* /bin/hostname.   >>
HOSTNAME=`/bin/hostname`
if [ -f /etc/sysconfig/network ]; then
    . /etc/sysconfig/network
else
    NETWORKING=no
fi
if [ -z "$HOSTNAME" -o "$HOSTNAME" = "(none)" ]; then
    HOSTNAME=localhost
fi


Fine.  Yes, it runs /bin/hostname and /bin/hostname will return null if
the hostname hasn't been set yet.  The next bit tests to see if the file
"/etc/sysconfig/network" exists.  If it does, then it is executed.  If
not, the variable NETWORKING is set to "no".

As you can see by this stuff you quoted:

[root localhost init.d]# cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=localhost.localdomain
[root localhost init.d]#

running /etc/sysconfig/network will set NETWORKING to yes and set the
hostname to "localhost.localdomain".

The next test says "if the variable HOSTNAME is null (zero length) OR
if HOSTNAME contains the string "(none)", then set HOSTNAME to
localhost".

It would seem that the hostname is being set either by the
/etc/sysconfig/network file, or by the fallout case listed in
/etc/rc.sysinit (if -z $HOSTNAME ...).


That's exactly right.

I don't know why the hostname command would fail:

[root localhost init.d]# cat /etc/hostname
vectra
[root localhost init.d]#


Because that's now how things are set up.  If you follow the rest of the
startup sequence, in the /etc/rc.d/init.d/network bit, it checks to see
if /etc/sysconfig/network exists, and if it does, runs it.  It then
checks to see if NETWORKING is set to "yes".  If so, it launches the
necessary /etc/sysconfig/network-scripts/ifcfg-* scripts to bring the
network interfaces up.  It then calls "/sbin/hostname $HOSTNAME" to
set the host name.

Wow! Lots of network questions this week!

Now, as for setting things up, your hostname IS set by the "HOSTNAME="
bit of /etc/sysconfig/network.  If, however, you use DHCP, your DHCP
server can replace your hostname when it hands you your IP address,
route and DNS servers.

If you DON'T use DHCP, then whatever you put in /etc/sysconfig/network
sticks.  The problem is, you may not have your IP address associated to
your hostname and the odds are that it won't be in a DNS server
anywhere, either, since you're on a private network.  So things like "X"
won't work anymore.

How do you fix that?  For a fixed IP, go ahead and put your FQDN in
the /etc/sysconfig/network's "HOSTNAME=" section (by FQDN, I mean
your hostname.yourdomainname.tld,, in your case "vectra.mydomain.com").
THEN edit /etc/hosts and add a line that contains your fixed IP, a tab,
your FQDN, a tab, then your hostname, e.g.

192.168.0.10 vectra.mydomain.com vectra

By putting this in /etc/hosts, the system never asks DNS for the IP
associated with your hostname--it has it in its local tables.  X will
start normally and life will be good again.  ;-)

Also, what does the line ". /etc/sysconfig/network" do?
Is "." (dot) a command?


Well, yes.  It actually means "run the shell on this script".  The
line:

. /etc/sysconfig/network

is the same as saying

sh /etc/sysconfig/network

Necessary because /etc/sysconfig/network doesn't have the execute bit
set, nor does it have "#!/bin/bash" or "#!/bin/sh" as the first line.

Whew! I've been busy today!

Actually, "." means "source", or "run the script IN THIS SHELL" so that variables set will also be set for this process. My second statement about "sh" is wrong, as the variables set in the script would be set only for the subshell and the current shell still won't know about them.

Now, I'm getting punchy!
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens vitalstream com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-   To err is human.  To forgive, a large sum of money is needed.    -
----------------------------------------------------------------------


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]