Advanced Configurations.

# 11 Advanced Configurations.

Contents of this section

The configurations above have described how a typical Linux workstation might be configured for normal end-user operation. Some of you will have other requirements which will require slightly more advanced configurations. What follows are examples of some the more common of these.

## 11.1 PPP - Point to Point Protocol.

The Point to Point Protocol is a modern and efficient protocol for conveying multiple protocols, tcp/ip for one, across serial links, that a lot of people use in place of slip. It offers enhanced functionality, error detection and security options. It corrects a number of deficiencies that are found in slip, and is suitable for both asynchronous links and synchronous links alike.

An important feature of PPP operation is dynamic address allocation, and this feature will almost certainly be exploited by your PPP server. This feature allows a PPP client, with a specially formatted frame, to request its address from the server. In this way configuration is somewhat less messy than with slip, since this ability to retrieve your address must occur outside of the protocol.

The authors of the Linux port are `Michael Callahan, <callahan@maths.ox.ac.uk>` and `Al Longyear, <longyear@netcom.com>`. Most of this information has come from the documentation that accompanies the PPP software. The documentation is quite complete, and will tell you much more than I present here.

The Linux PPP code has come out of Alpha testing and is now available as a public release. The 1.0.0 Linux PPP code is based on Paul Mackerras's free PPP for BSD-derivative operating systems. The 1.0.0 release is based on version 2.1.1 of the free PPP code.

The PPP code comes in two parts. The first is a kernel module which handles the assembly and disassembly of the frames, and the second is a set of protocols called LCP, IPCP, UPAP and CHAP, for negotiating link options, bringing the link into a functioning state and for authentication.

### Why would I use PPP in place of SLIP ?

You would use PPP in place of SLIP for a few reasons. The most common are:

Your Internet Provider supports only PPP

  The most obvious reason you would use PPP in favour of SLIP is when your Internet Provider supports PPP and not SLIP. Ok, I said it was obvious.

You have a normally noisy serial line

  PPP provides a frame check sequence for each and every frame transmitted, SLIP does not. If you have a noisy serial line, and you are using SLIP, your error correction will be performed end to end, that is between your machine and the destination machine, whereas with PPP the error detection occurs locally, between your machine and the PPP server. This makes for faster recovery from errors.

You need to make use of some other feature PPP offers.

  PPP provides a number of features that SLIP does not. You might for example want to carry not only IP, but also DECNET, or AppleTalk frames over your serial link. PPP will allow you to do this.

### Where to obtain the PPP software.

The ppp software is available from:

sunsite.unc.edu

> `

>     /pub/Linux/system/Networking/serial/ppp-2.1.2a.tar.gz

> `

This file contains the kernel source, and the pppd source and binary. Version 1.0.0 is meant for use with kernels 1.0.x and 1.1.x. No support is currently available for Fred's Net-2E kernel.

### Installing the PPP software.

Installation of the PPP software is fairly straightforward.

### The kernel driver.

Some support for ppp has been built into the kernel for some time. Configuring the kernel is fairly easy, the following should work ok:

> `

>     # cd /usr/src
>     # gzip -dc ppp-2.1.2a.tar.gz | tar xvf -
>     # cp /usr/src/ppp-2.1.2a/linux/ppp.c /usr/src/linux/drivers/net
>     # cp /usr/src/ppp-2.1.2a/pppd/ppp.h /usr/src/linux/include/linux

> `

You will then need to uncomment the `CONFIG_PPP` line in `/usr/src/linux/config.in`. If you are running a version of the kernel that is 1.1.4 or higher, then you will also need to comment out or delete the macro definition of `NET02D` in the file `/usr/src/linux/drivers/net/ppp.c`. If you are running an even more recent version then you make not to make any changes at all.

You can then do a make config, select PPP support, and follow with a make dep;make.

When you reboot with the new kernel you should see messages at boot time that look something like these:

> `

>     PPP: version 2.1.1 (4 channels)
>     TCP compression code copyright 1989 Regents of the University of California
>     PPP line discipline registered.

> `

Now, try looking at the contents of `/proc/net/dev`. It should look something like this:

> `

>       Inter-|   Receive                  |  Transmit
>        face |packets errs drop fifo frame|packets errs drop fifo colls carrier
>           lo:      0    0    0    0    0        0    0    0    0     0    0
>         ppp0:      0    0    0    0    0        0    0    0    0     0    0
>         ppp1:      0    0    0    0    0        0    0    0    0     0    0
>         ppp2:      0    0    0    0    0        0    0    0    0     0    0
>         ppp3:      0    0    0    0    0        0    0    0    0     0    0

> `

This indicates that the kernel driver is installed correctly.

### pppd

If you want to recompile pppd, type make in the `pppd` subdirectory of the installation. There will be some warnings when compiling `lcp.c`, `upap.c` and `chap.c` but these are OK.

If you want to recompile chat, consult `README.linux` in the `chat` directory.

To install, type make install in the `chat` and `pppd` directories. This will put chat and pppd binaries in `/usr/etc` and the `pppd.8` manual page in `/usr/man/man8`.

`pppd` needs to be run as `root`. You can either make it suid root or just use it when you are root. make install will try to install it suid root, so if you are root when you try to install it, it should work ok.

### Configuring and using the PPP software.

Like slip, you can configure the PPP software as either a client or a server. The chat performs a similar function to the dip program in that it is used to automate the dialling and login procedure to the remote machine, unlike dip though, it does not perform the ioctl to convert the serial line into a PPP line. This is performed by the pppd program. pppd can act as either the client or the server. When used as a client, it normally invokes the chat program to perform the connection and login, and then it takes over by performing the ioctl to change the line discipline to ppp and then steps out of the way to let you operate.

Please refer to the pppd and chat man pages for more information. Please also refer to the README file that comes with the ppp software, as its description of the operation of these utilities is much more complete than I have described here.

### Configuring a PPP client by dial-up modem.

This is perhaps what most of you will want to do, so it appears first. You would use this configuration when you have a network provider who supports ppp by dialup modem. When you want to establish your connection you simply have to invoke the pppd program with appropriate arguments.

The following example might look a little confusing at first, but it is easier to understand if you can see that all it is doing is taking a command line for the chat program as its first argument and then others for itself later.

> `

>     pppd connect 'chat -v "" ATDT5551212 CONNECT "" ogin: ppp word: password'\
>           /dev/cua1 38400 debug crtscts modem defaultroute 192.1.1.17:

> `

What this says is:

- Invoke the chat program with the command line:

  > `

  >     chat -v "" ATDT5551212 CONNECT "" ogin: ppp word: password

  > `

  Which says: Dial 5551212, wait for the `CONNECT' string, transmit a carriage return, wait for the string `ogin:', transmit the string `ppp', wait for the string `word:', transmit the string `password', and quit.
- Use serial device `/dev/cua1`
- Set its speed to 38400 bps.
- debug means log status messages to syslog
- crtscts means use hardware handshaking to the modem - recommended.
- modem means that pppd will attempt to hang up the call before and after making the call.
- defaultroute instructs pppd to add a routing entry that makes this the default route. In most cases this will be what you want.
- 192.1.1.17: says to set the ppp interfaces address to `192.1.1.17`. This argument normally looks like x.x.x.x:y.y.y.y, where x.x.x.x is your ip address, and y.y.y.y is the ip address of the server. If you leave off the server's address, pppd will ask for it, and x.x.x.x will be set to your machines ip address.

Please refer to the pppd and chat man pages for more information. Please also refer to the README file that comes with the ppp software, as its description of the above is much more complete than I have described here.

### Configuring a PPP client via a leased line.

Configuring a PPP client via a leased line is almost as straightforward as for configuring slip with slattach. You will still use the pppd program, but since you won't need to establish the modem link the arguments to the chat program can be much simpler.

The example I'm presenting here assumes that the ppp server doesn't require any special login procedure. I do this because every login procedure will be different, and if you are simply running a local connection then it is possible that you might have it set up this way.

> `

>     pppd connect 'echo connecting...' defaultroute noipdefault debug \
>           kdebug 2 /dev/cua0 9600

> `

This will echo a message to your screen, and set your default route via the ppp interface. The noipdefault argument instructs the pppd program to request the address to use for this device from the server. Debug messages will go to syslog. The kdebug 2 argument causes the debug messages to be set to level 2, this will give you slightly more information on what is going on. It will use `/dev/cua0` at 9600 bps.

If your ppp server does require some sort of login procedure, you can easily use the chat program as in the example for the dialup server to perform that function for you.

Please refer to the pppd and chat man pages for more information. Please also refer to the README file that comes with the ppp software, as its description of the above is much more complete than I have described here.

### Configuring a PPP server.

Configuring a PPP server is similar to establishing a slip server. You can create a special `ppp' account, which uses an executable script as its login shell. The `/etc/passwd` entry might look like:

> `

>     ppp:EncPasswd:102:50:PPP client login:/tmp:/etc/ppp/ppplogin

> `

and the `/etc/ppp/ppplogin` script might look like:

> `

>     #!/bin/sh
>     exec /usr/etc/pppd passive :192.1.2.23

> `

The address that you provide will be the address that the calling machine will be assigned.

Naturally, if you want multiple users to have simultaneous access you would have to create a number of startup scripts and individual accounts for each to use, as you can only put one ip address in each script.

### Where to obtain more information on PPP, or report bugs.

Most discussion on PPP for Linux takes place on the PPP mailing list.

To join the Linux PPP channel on the mail list server, send mail to:

> `

>     linux-activists@niksula.hut.fi

>     with the line:

>     X-Mn-Admin: join PPP

>     at the top of the message body (not the subject line).

> `

Please remember that when you are reporting bugs or problems you should include as much information relevant to the problem as you can to assist those that will help you understand your problem.

You might also like to check out:

RFCS 1548, 1331, 1332, 1333, and 1334. These are the definitive documents for PPP.

W. Richard Stevens also describes PPP in his book `TCP/IP Illustrated Volume 1', (Addison-Wessley, 1994, ISBN 0-201-63346-9).

## 11.2 Configuring Linux as a Slip Server.

If you have a machine that is perhaps network connected, that you'd like other people be able to dial into, and provide network services, then you will need to configure your machine as a server. If you want to use slip as the serial line protocol, then currently you have two options as to how to configure your Linux machine as a slip server. I will present a summary of both.

### Slip Server using sliplogin

sliplogin is a program that you can use in place of the normal login shell for slip users that converts the terminal line into a slip line. The caller will login as per the standard login process, entering their username and password, but instead of being presented with a shell after their login, sliplogin is executed which searches its configuration file (`/etc/slip.hosts`) for an entry with a login name that matches that of the caller. If it locates one, it configures the line as an 8bit clean line, and uses an ioctl call to convert the line discipline to slip. When this process is complete, the last stage of configuration takes place, where sliplogin invokes a shell script which configures the slip interface with the relevant ip address, netmask and sets appropriate routing in place. This script is usually called `/etc/slip.login`, but in a similar manner to getty, if you have certain callers that require special initialisation, then you can create configuration scripts called `/etc/slip.login.loginname` that will be run instead of the default.

### Where to get sliplogin

sliplogin can be obtained from:

sunsite.unc.edu

> `

>     /pub/Linux/system/Network/serial/sliplogin.tar.gz

> `

The tar file contains both source, precompiled binaries and a man page. To install the binaries into your `/sbin` directory, and the man page into section 8, do the following:

> `

>     # cd /usr/src
>     # gzip -dc .../sliplogin.tar.gz | tar xvf -
>     # cd src
>     # make install

> `

If you want to recompile the binaries before installation, add a `make clean` before the `make install`. If you want to install the binaries somewhere else, you will need to edit the `Makefile` install rule.

### Configuring `/etc/passwd` for Slip hosts.

You need to create some special logins for Slip callers in your `/etc/passwd` file. A convention commonly followed is to use the hostname of the calling host with a capital `S' prefixing it. So, for example, if the calling host is called `radio` then you would create a `/etc/passwd` entry that looked like:

> `

>     Sradio:FvKurok73:1427:1:radio slip login:/tmp:/sbin/sliplogin

> `

Note: the caller doesn't need any special home directory, as they will not be presented with a shell from this machine, so `/tmp` is a good choice. Also note that sliplogin is used in place of the normal login shell.

### Configuring `/etc/slip.hosts`

The `/etc/slip.hosts` file is the file that sliplogin searches for entries matching the login name to obtain configuration details for this caller. It is this file where you specify the ip address and netmask that will be assigned to the caller, and configured for their use. A sample entry for host `radio' might look like:

> `

>     Sradio    `hostname`    radio    <netmask>    <opt1>    <opt2>

> `

The `/etc/slip.hosts` file entries are:

1. the login name of the caller.
2. ip address of the server machine, ie this machine.
3. ip address that the caller will be assigned.
4. the netmask assigned to the calling machine in hexadecimal notation eg 0xffffff00 for a Class C network mask.
5. optional parameters to enable/disable compression and other features.

Note: You can use either hostnames or IP addresses in dotted decimal notation for fields 2 and 3. If you use hostnames then those hosts must be resolvable, that is, your machine must be able to locate an ip address for those hostnames, otherwise the script will fail when it is called. You can test this by trying trying to telnet to the hostname, if you get the `Trying nnn.nnn.nnn...' message then your machine has been able to find an ip address for that name. If you get the message `Unknown host', then it has not. If not, either use ip addresses in dotted decimal notation, or fix up your name resolver configuration.

The most commonly used optional paramaters for the `opt1` and `opt2` fields are:

normal

  to enable normal uncompressed slip.

compress

  to enable van Jacobsen header compression (cslip)

Naturally these are mutually exclusive, you can use one or the other. For more information on the other options available, refer to the man pages.

### Configuring the `/etc/slip.login` file.

After sliplogin has searched the `/etc/slip.hosts` and found a matching entry, it will attempt to execute the `/etc/slip.login` file to actually configure the slip interface with its ip address and netmask.

The sample `/etc/slip.login` file supplied with the sliplogin package looks like this:

> `

>     #!/bin/sh -
>     #
>     #       @(#)slip.login  5.1 (Berkeley) 7/1/90
>     #
>     # generic login file for a slip line.  sliplogin invokes this with
>     # the parameters:
>     #      1        2         3        4          5         6     7-n
>     #   slipunit ttyspeed loginname local-addr remote-addr mask opt-args
>     #
>     /sbin/ifconfig $1 $4 pointopoint $5 mtu 1500 -trailers up
>     /sbin/route add $5
>     exit 0

> `

You will note that this script simply uses the ifconfig and route commands to configure the slip device with its ipaddress, remote ip address and netmask, and creates a route for the remote address via the slip device. Just the same as you would if you were using the slattach command.

### Configuring the `/etc/slip.logout` file.

When the call drops out, you want to ensure that the serial device is restored to its normal state so that future callers will be able to login correctly. This is achieved with the use of the `/etc/slip.logout` file. It is quite simple, and again, I'll present the sample included in the sliplogin package.

> `

>     #!/bin/sh -
>     #
>     #               slip.logout
>     #
>     /sbin/ifconfig $1 down
>     /sbin/route del $5
>     exit 0

> `

All it does is `down' the interface and delete the manual route previously created.

### Slip Server using dip.

Let me start by saying that some of the information below came from the dip man pages, where how to run Linux as a slip server is briefly documented.

To configure Linux as a slip server, you need to create some special slip accounts for users, where dip (in slave mode) is used as the login shell. Fred suggests that he has a convention of having all of his slip accounts begin with a capital `S', eg `Sfredm'.

Because the login program won't accept arguments to the login shell, you will need to create a small program that looks like the following:

> `

>     /* dip-i.c - from a mail message of Karl kkeyte@esoc.bitnet */
>     int main()
>     {
>        execlp("dip", "dip", "-i", (char *) 0);
>     }

> `

Compile it with: `gcc -O dip-i.c -o dip-i`

Give it permissions `555`. I recommend calling it `/usr/bin/dip-i` as shown below.

A sample `/etc/passwd` entry for a slip user looks like:

> `

>     Sfredm:ij/SMxiTlGVCo:1004:10:UUNET:/tmp:/usr/bin/dip-i
>     ^^         ^^        ^^  ^^   ^^    ^^   ^^
>     |          |         |   |    |     |    \__ shell program running
>     |          |         |   |    |     |         dip -i as login shell
>     |          |         |   |    |     \_______ Home directory
>     |          |         |   |    \_____________ User Full Name
>     |          |         |   \__________________ User Group ID
>     |          |         \______________________ User ID
>     |          \________________________________ Encrypted User Password
>     \___________________________________________ Slip User Login Name

> `

After the user logs in, the login(1) program, if it finds and verifies the user ok, will execute the shell program dip-i which will execute the dip command in input mode (`-i`). dip now scans the `/etc/net/diphosts` file for an entry for the given user name. Therefore, each slip user must also have an entry in `/etc/net/diphosts`.

You will have to re-read section `Proxy Arp' to arrange for your machine to proxy arp for the slip users who will be using your system if you want them to have access to any network that your server machine might be connected to.

### Configuring `/etc/net/diphosts`

`/etc/net/diphosts` is used by dip to lookup preset configurations for remote hosts. These remote hosts might be users dialing into your linux machine, or they might be for machines that you dial into with your linux machine.

The general format for `/etc/net/diphosts` is as follows:

> `

>     Suwalt::145.71.34.1:SLIP uwalt:CSLIP,1006
>      ^    ^  ^            ^         ^     ^
>      |    |  |            |         |     \___ MTU
>      |    |  |            |         \_________ protocol (SLIP, CSLIP,
>      |    |  |            |                    KISS)
>      |    |  |            \___________________ comment field
>      |    |  \________________________________ IP address of the other
>      |    |                                    side, or host.domain.name
>      |    \___________________________________ unused (compat. with passwd)
>      \________________________________________ login name (as returned by
>                                                getpwuid(getuid()))

> `

An example `/etc/net/diphosts` entry for a remote slip user might be:

> `

>     Sfredm::145.71.34.1:SLIP uwalt:SLIP,296

> `

which specifies a slip link with MTU of 296, or

> `

>     Sfredm::145.71.34.1:SLIP uwalt:CSLIP,1006

> `

which specifies a cslip-capable link with MTU of 1006.

When a user logs in, they will receive a normal login, and password prompt, at which they should enter their slip-login userid and password. If they check out ok, then the user will see no special messages, they should just change into slip mode at their end, and then they should be able to connect ok, and be configured with the parameters from the `diphosts` file.

## 11.3 Using the Automounter Daemon - AMD.

This section has been supplied by `Mitch DSouza`, and I've included it with minimal editing, as he supplied it. Thanks Mitch.

### What is an automounter, and why would I use one ?

An automounter provides a convenient means of mounting filesystems on demand, i.e. when requried. This will reduce both the server and the client load, and provides a great deal of flexibility even with non-NFS mounts. It also offers a redundancy mechanism whereby a mount point will automatically switch to a secondary server should a primary one be unavailable. A rather useful mount called the union mount gives the automounter the ability to merge the contents of multiple directories into a single directory. The documentation msut be read thoroughly to make full use of its extensive capabilities.

A few important points must be remembered - (in no particular order):

- amd maps are not compatible with Sun maps, which in turn are not compatible with HP maps ad infinitum. The point here however is that amd is freely available and compatible with all the systems mentioned above and more, thus giving you the ability to share maps if amd is installed throughout your network. Mitch uses it with a mixture of Linux/Dec/NeXt/Sun machines.
- Sun automount maps can be converted to amd style maps by using the perl script in the `contrib` directory - `automount2amd.pl`.
- You must have the portmapper running before starting amd.
- UFS mounts do not timeout.
- UFS mounts, in the case of Linux only, have been extended to deal with all varieties of native filesystems (i.e. minix, ext, ext2, xiafs ...) with the default being minix. This undocumented feature is accessed in the opts option like:

  > `

  >      ..., opts:=type=msdos,conv=auto

  > `

- Do not mount over existing directories unless you use a direct automount option, otherwise it is like mounting your disk on `/home` when some user directory is `/home/fred`.
- Always turn on full logging with the `-x all' option to amd if you have any troubles. Check also what the command:

  > `

  >     % amq -ms

  > `

  reports, as it will indicate problems as they occur.
- GNU getopt() is too clever for its own good sometimes. You should always use `--' before the non-options e.g.

  > `

  >     # /etc/amd -x all -l syslog -a /amd -- /net /etc/amd.net

  > `

### Where to get AMD, the automounter daemon.

amd can be obtained from:

sunsite.unc.edu

> `

>     /pub/Linux/system/Misc/mount/amd920824upl67.tar.gz

> `

This contains ready-to-run binaries, full sources and documentation in texinfo format.

### An example AMD configuration.

You do not configure the automounter from the `/etc/fstab` file, which you will already be using to contain information about your fileystems, instead it is command line driven.

To mount two nfs filesystems using your `/etc/fstab` file you would use two entries that looked like:

> `

>     server-1:/export/disk  /nfs/server-1  nfs  defaults
>     server-2:/export/disk  /nfs/server-2  nfs  defaults

> `

i.e. you were nfs mounting `server-1` and `server-2` on your linux disk on the `/nfs/server-1` and `/nfs/server-2` directories.

After commenting out, or deleting the above lines from your `/etc/fstab` file, you could amd to perform the same task with the following syntax:

> `

>     /etc/amd -x all -l syslog -a /amd -- /nfs /etc/amd.server
>     |      | |    | |       | |     |  | |  | |             |
>     |      | |    | |       | |     |  | |  | |             |
>     `------' `----' `-------' `-----' -' `--' `-------------'
>      |        |      |         |      |   |    |
>      (1)      (2)    (3)       (4)    (5) (6)  (7)

> `

Where:

1. The full amd binary path (obviously optional) depending on your $PATH setting, so just `amd' may be specified here.
2. `-x all' means turn full logging on. Read the documentation for the other logging levels
3. `-l syslog' means log the message via the syslog daemon. This could mean put it to a file, dump it, or pass it, to an unused tty console. This (syslog) can be changed to the name of a file, i.e. `-l foo' will record to a file called foo.
4. `-a /amd' means use the `/amd` directory as a temporary place for automount points. This directory is created automatically by amd and should be removed before starting amd in your `/etc/rc` scripts.
5. `--' means tell getopt() to stop attempting to parse the rest of the command line for options. This is especially useful when specifying the `type:=' options on the command line, otherwise getopt() tries to decode it incorrectly.
6. `/nfs' is the real nfs mount point. Again this is automatically created and should not generally contain subdirectories unless the `type:=direct' option is used.
7. The amd map (i.e. a file) named `amd.server' contains the lines:

   > `

   >     # /etc/amd.server
   >     /defaults    opts:=rw;type:=nfs
   >     server-1     rhost:=server-1;rfs:=/export/disk
   >     server-2     rhost:=server-2;rfs:=/export/disk

   > `

Once started and successfully running, you can query the status of the mounts with the command:

> `

>     % amq -ms

> `

Now if you say:

> `

>     % ls /nfs

> `

you should see no files. However the command:

> `

>     % ls /nfs/server-1

> `

will mount the host `server-1' automatically. voila! amd is running. After the default timeout has expired, this will automatically be unmounted. Your `/etc/password` file could contain entries like:

> `

>      ...
>     linus:EncPass:10:0:God:/nfs/server-1/home/linus:/bin/sh
>     mitch:EncPass:20:10:Mitch DSouza:/nfs/server-1/home/mitch:/bin/tcsh
>     matt:EncPass:20:10:Matt Welsh:/nfs/server-1/home/matt:/bin/csh

> `

which would mean that when Linus, Matt, or Mitch are logged in, their home directory will be remotely mounted from the appropriate server, and umounted when they log out.

## 11.4 Using Linux as a router

Linux will function just fine as a router. You should run a routing daemon such as gated, or if you have simple routing requirements use hard coded routes. If you are using a late version kernel (1.1.*) then you should ensure that you have answered `y' to:

> `

>     IP forwarding/gatewaying (CONFIG_IP_FORWARD) [y] y

> `

when building your kernel.

Olaf Kirch's Network Administrators Guide discusses network design and routing issues, and you should read it for more information. A reference to it is in the "Related Documentation" section of this document.

Next Chapter, Previous Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter