As mentioned earlier, there are other files that you will need to complete your network installation. These files concern higher level configurations of the network software. Each of the important ones are covered in the following sub-sections, but you will find there are others that you will have to configure as you become more familiar with the network suite.
If you have been following this document you should at this stage have built an rc file to configure each of your network devices with the correct addresses, and set up whatever routing you will need for your particular network configuration. You will now need to actually start some of the higher level network software.
Now would be a really good time to read Olaf's Network Administrators Guide, as it really should be considered the definitive document for this stage of the configuration process. It will help you decide what to include in this file, and more importantly perhaps, what not to include in this file. For the security conscious it is a fair statement to say that the more network services you have running, the more likely the chance of your system having a security hole: Run only what you need.
There are some very important daemons (system processes that run in the background) that you will need to know a little about. The man pages will tell you more, but they are:
inetd is a program that sits in the background and manages internet
connection requests and the like. It is smart enough that you don't need to
leave a whole bunch of servers running when there is nothing connected to them.
When it sees an incoming request for a particular service, eg telnet,
or ftp, it will check the /etc/services
file, find what
server program needs to be run to manage the request, start it, and hand
the connection over to it. Imagine it as a master server for your internet
servers. It also has a few simple standard services inbuilt. These are
echo, discard and generate services used for various
types of network testing.
syslogd is a daemon that handles all system logging. It accepts
messages generated for it and will distribute them according to a set of rules
contained in /etc/syslogd.conf
. For example, certain types of messages
you will want to send to the console, and also to a log file, where others
you will want only to log to a file. syslogd allows you to specify
what messages should go where.
The following is a sample rc.inet2 file that Fred built. It starts a large number of servers, so you might want to trim it down to just those services that you actually want to run. To trim it down, simply delete or comment out the stanzas (if to fi) that you don't need. All each stanza does is test that the relevant module is a file, that it exists, echoes a comment that you can see when you boot your machine, and then executes the commands with the arguments supplied to ensure that it runs happily in the background. For more detailed information on each of the deamons, check either the Network Administrators Guide or the relevant man pages.
#! /bin/sh
#
# rc.inet2 This shell script boots up the entire INET system.
# Note, that when this script is used to also fire
# up any important remote NFS disks (like the /usr
# distribution), care must be taken to actually
# have all the needed binaries online _now_ ...
#
# Version: @(#)/etc/rc.d/rc.inet2 2.18 05/27/93
#
# Author: Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org>
#
# Constants.
NET="/usr/etc"
IN_SERV="lpd"
LPSPOOL="/var/spool/lpd"
# At this point, we are ready to talk to The World...
echo -e "\nMounting remote file systems ..."
/bin/mount -t nfs -v # This may be our /usr runtime!!!
echo -e "\nStarting Network daemons ..."
# Start the SYSLOG daemon. This has to be the first server.
# This is a MUST HAVE, so leave it in.
echo -n "INET: "
if [ -f ${NET}/syslogd ]
then
echo -n "syslogd "
${NET}/syslogd
fi
# Start the SUN RPC Portmapper.
if [ -f ${NET}/rpc.portmap ]
then
echo -n "portmap "
${NET}/rpc.portmap
fi
# Start the INET SuperServer
# This is a MUST HAVE, so leave it in.
if [ -f ${NET}/inetd ]
then
echo -n "inetd "
${NET}/inetd
else
echo "no INETD found. INET cancelled!"
exit 1
fi
# Start the NAMED/BIND name server.
if [ ! -f ${NET}/named ]
then
echo -n "named "
${NET}/named
fi
# Start the ROUTEd server.
# NOTE: routed is now obselete. You should now use gated.
#if [ -f ${NET}/routed ]
#then
# echo -n "routed "
# ${NET}/routed -q #-g -s
#fi
# Start the GATEd server.
if [ -f ${NET}/gated ]
then
echo -n "gated "
${NET}/gated
fi
# Start the RWHO server.
if [ -f ${NET}/rwhod ]
then
echo -n "rwhod "
${NET}/rwhod -t -s
fi
# Start the U-MAIL SMTP server.
if [ -f XXX/usr/lib/umail/umail ]
then
echo -n "umail "
/usr/lib/umail/umail -d7 -bd </dev/null >/dev/null 2>&1 &
fi
# Start the various INET servers.
for server in ${IN_SERV}
do
if [ -f ${NET}/${server} ]
then
echo -n "${server} "
${NET}/${server}
fi
done
# Start the various SUN RPC servers.
if [ -f ${NET}/rpc.portmap ]
then
if [ -f ${NET}/rpc.ugidd ]
then
echo -n "ugidd "
${NET}/rpc.ugidd -d
fi
if [ -f ${NET}/rpc.mountd ]
then
echo -n "mountd "
${NET}/rpc.mountd
fi
if [ -f ${NET}/rpc.nfsd ]
then
echo -n "nfsd "
${NET}/rpc.nfsd
fi
# Fire up the PC-NFS daemon(s).
if [ -f ${NET}/rpc.pcnfsd ]
then
echo -n "pcnfsd "
${NET}/rpc.pcnfsd ${LPSPOOL}
fi
if [ -f ${NET}/rpc.bwnfsd ]
then
echo -n "bwnfsd "
${NET}/rpc.bwnfsd ${LPSPOOL}
fi
fi
echo network daemons started.
# Done!
Name Resolution is the process of converting a hostname in the familiar
dotted notatiion (e.g. tsx-11.mit.edu
) into an IP address which the
network software understands. There are two principal means of achieving this
in a typical installation, one simple, and one more complex.
/etc/hosts
contains a list of ip addresses and the hostnames they map
to. In this way, you can refer to other machines on the network by name, as
well as their ip address. Using a nameserver (see section `named') allows
you to do the same name->ip address translation automatically. (Running
named allows you to run your own nameserver on your linux machine).
This file needs to contain at least an entry for 127.0.0.1
with the
name localhost
. If you're not only using loopback, you need to add
an entry for your ip address, with your full hostname (such as
loomer.vpizza.com
). You may also wish to include entries for your
gateways and network addresses.
For example, if loomer.vpizza.com
has the ip address
128.253.154.32
, the /etc/hosts
file would contain:
# /etc/hosts
# List of hostnames and their ip addresses
127.0.0.1 localhost
128.253.154.32 loomer.vpizza.com loomer
# end of hosts
Once again you will need to edit this file to suit your own needs. If you're
only using loopback, the only line in /etc/hosts
should be for
127.0.0.1
, with both localhost
and your hostname after it.
Note that in the second line, above, there are two names for
128.253.154.32
: loomer.vpizza.com
and just loomer
.
The first name is the full hostname of the system, called the "Fully Qualified
Domain Name", and the second is an alias for it. The second allows you to
type only rlogin loomer instead of having to type the entire hostname.
You should ensure that you put the Fully Qualified Domain Name in the line
before the alias name.
`I dub thee ..'
named is the nameserver daemon for many unix-like operating systems.
It allows your machine to serve the name lookup requests, not only for itself,
but also for other machines on the network, that is, if another machine wants
to find the address for `goober.norelco.com'
, and you have this machines
address in your named database, then you can service the request and
tell other machines what `goobers'
address is.
Under older implementations of Linux tcp/ip, to create aliases for machine names,
(even for your own machine), you had to run named on your Linux machine
to do the hostname to IP address conversion. One problem with this is that
named is comparitively difficult to set up properly, and maintain.
To solve this problem, a program called hostcvt.build
was made
available on Linux systems to translate your /etc/hosts
file into the
many files that make up named database files. However even with this
problem overcome, named still uses CPU overhead and causes network
traffic.
The bottom line is this: You do not need to run named on your Linux
system. The SLS instructions will probably tell you to run hostcvt.build
to setup named. This is simply unnecessary unless you want to make
your Linux system function as a nameserver for other machines, in which case
you probably should learn some more about named anyway. When looking
up hostnames, your linux machine will first check the /etc/hosts
file,
and then ask the nameserver out on the net.
The only reason you may want to run named would be if:
hosts
file and not
need to query a nameserver at all. Generally namelookup isn't that slow and
should work fine over a slip link anyway.In general, you do NOT need to run named: this means that you can
comment it out from your rc.inet2
file, and you don't have to
run hostcvt.build
. If you want to alias machine names, for example,
if you want to refer to loomer.vpizza.com
as just loomer
,
then you can add as alias in /etc/hosts
instead. There is no reason to
run named unless you have a specific requirement to do so. If you
have access to a nameserver, (and your network administrators will tell you its
address), and most networks do, then don't bother running named.
If you're only using loopback, you can run named and set your
nameserver address to 127.0.0.1
, but since you are the only machine
you can talk to, this would be quite bizzarre, as you'd never need to call it.
The /etc/networks
file lists the names and addresses of your own,
and other, networks. It is used by the route command, and allows you
to specify a network by name, should you so desire.
Every network you wish to add a route to using the route command
should have an entry in the /etc/networks
file, unless you also
specify the -net
argument in the route command line.
Its format is simliar to that of /etc/hosts
file above, and an
example file might look like:
#
# /etc/networks: list all networks that you wish to add route commands
# for in here
#
default 0.0.0.0 # default route - recommended
loopnet 127.0.0.0 # loopback network - recommended
mynet 128.253.154.0 # Example network CHANGE to YOURS
#
# end of networks
The system has some library functions called the resolver library. This file specifies how your system will lookup host names. It should contain at least the following two lines:
order hosts,bind
multi on
These two lines tell the resolve libraries to first check the
/etc/hosts
file, and then to ask the nameserver (if one is present).
The multi entry allows you to have multiple IP addresses for a given
machine name in /etc/hosts
.
This file comes from the implementation of the resolv+ bind library for Linux. You can find further documentation in the resolv+(8) man page if you have it. If you don't, it can be obtained from:
sunsite.doc.ic.ac.uk
/computing/comms/tcpip/nameserver/resolv+/resolv+2.1.1.tar.Z
This file contains the resolv+.8 man page for the resolver library.
This file actually configures the system name resolver, and contains two
types of entries: The addresses of your nameservers (if any), and the name of
your domain, if you have one. If you're running your own nameserver (i.e
running named on your Linux machine), then the address of your
nameserver is 127.0.0.1
, the loopback address.
Your domain name is your fully qualified hostname (if you're a registered
machine on the Internet, for example), with the hostname component removed.
That is, if your full hostname is loomer.vpizza.com
, then your
domain name is vpizza.com
, without the hostname loomer
.
For example, if you machine is goober.norelco.com
, and has a
nameserver at the address 128.253.154.5
, then your
/etc/resolv.conf
file would look like:
domain norelco.com
nameserver 127.253.154.5
You can specify more than one nameserver. Each one must have a
nameserver entry in the resolv.conf
file.
Remember, if you're running on loopback, you don't need a nameserver.
After you have configured everything else, there is one small task that remains, you need to configure your own machine with a name. This is so that application programs like sendmail can know who you are to accept mail, and so that your machine can identify itself to other machines that it might be connected to.
There are two programs that are used to configure this sort of information, and they are commonly misused. They are hostname and domainname.
If you are using a release of net-tools
earlier than 1.1.38
then you can include a command in your /etc/rc
file that looks like
this:
/bin/hostname -S
and this will cause the hostname command to read a file called
/etc/HOSTNAME
which it expects will contain a "Fully Qualified
Domain Name", that is, your machines hostname including the
domainname. It will split the F.Q.D.N. into its DNS hostname and domainname
components and set them appropriately for you.
For example, the machine above would have the file /etc/HOSTNAME
:
goober.norelco.com
If you are using the hostname that came with net-tools-1.1.38
or later, then you would add a command at the end of your
/etc/rc.d/rc.inet1
file like:
/bin/hostname goober.norelco.com
or if you have upgraded from a previous release, you could add:
/bin/hostname -F /etc/HOSTNAME
and it would behave in the same way as for the earlier version.
The /bin/domainname
command is for setting the N.I.S.
domain name NOT the D.N.S. domain name. You do not need to set
this unless you are running NIS, which is briefly described
later.
There are of course many other files in the /etc
directory which
you may need to dabble with later on. Instead of going into them here, I'm
going to provide the bare minimum to get you on the net. More information
is available in Olaf's Network Administration Guide. It picks up
where this HOWTO ends, and some more information will be provided in
later versions of this document.
Once you have all of the files set up, and everthing in the right place, you should be able to reboot you new kernel, and net away to your hearts content. However I strongly suggest that you keep a bootable copy of your old kernel and possibly even a `recovery disk', in case something goes wrong, so that you can get back in and fix it. You might try HJLu's `single disk boot disk', or `disk1' from an SLS distribution.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter