Previous Next Contents Main Page

11. Configuring the network daemons.

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.

11.1 /etc/rc.d/rc.inet2 (the second half of rc.net)

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.

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. inetd doesn't manage all servers and services that you might run, but it manages most of the usual ones. Normally services such as udp based services, or services that manage their own connection multiplexing such as World Wide Web servers or muds would be run independently of inetd. Generally the documentation accompanying such servers will tell you whether to use inetd or not.

syslogd.

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.

11.2 A sample rc.inet2 file.

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, <[email protected]>
#

# Constants.
NET="/usr/sbin"
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.
# NOTE: you probably don't need to run named.
#if [ ! -f ${NET}/named ]
#then
#        echo -n "named "
#        ${NET}/named
#fi

# Start the ROUTEd server.
# NOTE: routed is now obsolete. 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!

11.3 Other necessary network configuration files.

There are other network configuration files that you will need to configure if you want to have people connect to and use your machine as a host. If you have installed your linux from a distribution then you will probably already have copies of these files so just check them to make sure they look ok and if not you can use the following samples.

A sample /etc/inetd.conf file.

Your /etc/rc.d/rc.inet2 file will have started inetd, syslogd and the various rpc servers for you. You will now need to configure the network daemons that will be managed by inetd. inetd uses a configuration file called /etc/inetd.conf.

The following is an example of how a simple configuration might look:

#
# The internal services.
#
# Authors:      Original taken from BSD UNIX 4.3/TAHOE.
#               Fred N. van Kempen, <[email protected]>
#
echo    stream tcp nowait root  internal
echo    dgram  udp wait   root  internal
discard stream tcp nowait root  internal
discard dgram  udp wait   root  internal
daytime stream tcp nowait root  internal
daytime dgram  udp wait   root  internal
chargen stream tcp nowait root  internal
chargen dgram  udp wait   root  internal
#
# Standard services.
#
ftp     stream tcp nowait root  /usr/sbin/tcpd in.ftpd ftpd
telnet  stream tcp nowait root  /usr/sbin/tcpd in.telnetd
#
# Shell, login, exec and talk are BSD protocols.
#
shell   stream tcp nowait root  /usr/sbin/tcpd in.rshd
login   stream tcp nowait root  /usr/sbin/tcpd in.rlogind
exec    stream tcp nowait root  /usr/sbin/tcpd in.rexecd
talk    dgram  udp wait   root  /usr/sbin/tcpd in.talkd
ntalk   dgram  udp wait   root  /usr/sbin/tcpd in.talkd
#
# Status and Information services.
#
finger  stream tcp nowait root  /usr/sbin/tcpd in.fingerd
systat  stream tcp nowait guest /usr/sbin/tcpd /usr/bin/ps -auwwx
netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat
#
# End of inetd.conf.

The inetd man page describes what each of the fields are, but put simply, each entry describes what program should be executed when an incoming connection is received on the socket listed as the first entry. Those entries which have incoming where the program name and arguments would be are those services that are provided internally by the inetd program.

The conversion between the service name in the first column and the actual socket number it refers to is performed by the /etc/services file.

A sample /etc/services file.

The /etc/services file is a simple table of Internet service names and the socket number and protocol is uses. This table is used by a number of programs including inetd, telnet and tcpdump. It makes life a little easier by allowing us to refer to services by name rather than by number.

The following is a sample of what a simple /etc/services file might look like:

#
# /etc/services - database of service name, socket number
#                 and protocol.
#
# Original Author:
#     Fred N. van Kempen, <[email protected]>
#
tcpmux     1/tcp
echo       7/tcp
echo       7/udp
discard    9/tcp   sink null
discard    9/udp   sink null
systat     11/tcp  users
daytime    13/tcp
daytime    13/udp
netstat    15/tcp
chargen    19/tcp  ttytst source
chargen    19/udp  ttytst source
ftp-data   20/tcp
ftp        21/tcp
telnet     23/tcp
smtp       25/tcp  mail
time       37/tcp  timserver
time       37/udp  timserver
name       42/udp  nameserver
whois      43/tcp  nicname    # usually to sri-nic
domain     53/tcp
domain     53/udp
finger     79/tcp
link       87/tcp  ttylink
hostnames  101/tcp hostname   # usually to sri-nic
sunrpc     111/tcp
sunrpc     111/tcp portmapper # RPC 4.0 portmapper TCP
sunrpc     111/udp
sunrpc     111/udp portmapper # RPC 4.0 portmapper UDP
auth       113/tcp authentication
nntp       119/tcp usenet     # Network News Transfer
ntp        123/tcp            # Network Time Protocol
ntp        123/udp            # Network Time Protocol
snmp       161/udp
snmp-trap  162/udp
exec       512/tcp            # BSD rexecd(8)
biff       512/udp comsat
login      513/tcp            # BSD rlogind(8)
who        513/udp whod       # BSD rwhod(8)
shell      514/tcp cmd        # BSD rshd(8)
syslog     514/udp            # BSD syslogd(8)
printer    515/tcp spooler    # BSD lpd(8)
talk       517/udp            # BSD talkd(8)
ntalk      518/udp            # SunOS talkd(8)
route      520/udp routed     # 521/udp too
timed      525/udp timeserver
mount      635/udp            # NFS Mount Service
pcnfs      640/udp            # PC-NFS DOS Authentication
bwnfs      650/udp            # BW-NFS DOS Authentication
listen     1025/tcp listener  # RFS remote_file_sharing
ingreslock 1524/tcp           # ingres lock server
nfs        2049/udp           # NFS File Service
irc        6667/tcp           # Internet Relay Chat
# End of services.

The telnet entry tells us that the telnet service uses socket number 23 and the tcp protocol. The domain entry tells us that the Domain Name Service uses socket number 52 and both tcp and udp protocols. You should have an appropriate /etc/services entry for each /etc/inetd.conf entry.

A sample /etc/protocols file.

The /etc/protocols file is a table of protocol name with its corresponding protocol number. Since the number of protocols in use is small this file is quite trivial.

#
# /etc/protocols - database of protocols.
#
# Original Author:
#   Fred N. van Kempen, <[email protected]>
#
ip   0   IP   # internet protocol
icmp 1   ICMP # internet control message protocol
igmp 2   IGMP # internet group multicast protocol
ggp  3   GGP  # gateway-gateway protocol
tcp  6   TCP  # transmission control protocol
pup  12  PUP  # PARC universal packet protocol
udp  17  UDP  # user datagram protocol
idp  22  IDP
raw  255 RAW
#
# End of protocols.

11.4 Name Resolution.

Name Resolution is the process of converting a hostname in the familiar dotted notation (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

/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.

named - do I need thee ?

`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 comparatively 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 only reason you may want to run named would be if:

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 bizarre, as you'd never need to call it.

/etc/networks

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 similar 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

/etc/host.conf

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.

/etc/resolv.conf

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 128.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.

Configuring your Hostname - /etc/HOSTNAME

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.

11.5 Other files.

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 everything in the right place, you should be able to reboot your 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 a Linux distribution.


Previous Next Contents Main Page