Previous Next Contents Main Page

12. Advanced Configurations.

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.

The details of the AX.25, Ottawa PI and generic SCC drivers have been moved to the HAM-HOWTO.

12.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 the ability to negotiate such parameters as IP address allocation automatically and with ease 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, <[email protected]> and Al Longyear, <[email protected]>. 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 is now well and truly 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.2d.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. Version 2.1.2 is intended for kernel version 1.2.x, and the latest 2.2.0 pppd is intended for kernels 1.3.x.

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. so you are advised to run a modern kernel. Configuring the kernel is fairly easy, the following should work ok:

# make config   (remembering to answer yes to PPP support)
# make dep
# make          (remember to install the new kernel after recompiling!)

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

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

These indicate that the PPP support has in fact been compiled into your kernel.

Now, try looking at the contents of /proc/net/dev. You should be careful not to use more or less on the files in the /proc filesystem, as some of them check the filesize first and it is a feature of the /proc filesystem that the files are zero length, so use:

# cat /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

To extract the ppp software and associated utilities the following should work ok:

# cd /usr/src
# gzip -dc ppp-2.1.2d.tar.gz | tar xvf -

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/sbin 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 program performs a similar function to the dip program in that it is used to automate the dialing 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, performs a number of steps in configuring your machine to talk to the remote machine 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 invoke the pppd program with no arguments. This configuration assumes that your PPP server will assign you an address dynamically. What to do if you have a static address is explained later.

The pppd program has a number of command line arguments that govern its behaviour. These arguments can all be placed in a configuration file so that the commands do not appear in the argument list when someone on the system uses the ps command. This is particularly important when pppd invokes the chat program as it needs the password to use to login to the server and you don't normally want this visible to users of the system.

The file that pppd uses is called the /etc/ppp/options file.

A good starting point for a `typical' PPP installation might look like:

connect /etc/ppp/ppp-connect
/dev/ttyS1
19200
crtscts
modem
lock
asyncmap 0
defaultroute

This specifies that:

  1. pppd should use the /etc/ppp/ppp-connect script to dial the modem and login.
  2. pppd should use the ttyS1 device at 19200 bits per second, with crtscts hardware handshaking and respect the modem signals (Carrier Detect particularly) to detect if the modem is still on-line or if the call has finished.
  3. pppd should create a lock file for the tty device to ensure that other processes do not attempt to open it while pppd is using it.
  4. That the line is `8 bit clean', that is, that all characters are able to pass freely across the line. The asyncmap option determines which characters the pppd should escape and by default this is set to all control characters. Most modern PPP servers are 8 bit clean and setting the asyncmap to 0 tells pppd not to escape any characters.
  5. pppd should create a defaultroute via the ppp device when the connection is successfully established.

The next step is to configure the /etc/ppp/ppp-connect script. You would normally use the chat program that comes with pppd within this script as it is very simple to use and quite lightweight.

To start, you need to know what the login sequence for your PPP server looks like. The following is a fictional example that I'll base the sample script on:

CONNECT 14400

Welcome to XYZ PPP server!

login:                      <you enter your username>^M
password:                   <you enter your password>^M

Now entering PPP:

The chat program expects as arguments a send/expect sequence, meaning that it wants a series of `what it should expect, followed by what it should send' pairs. The /etc/ppp/ppp-connect should not not be world readable. A sample to deal with the hypothetical example above might look like:

#!/bin/sh
# A chat script to login to the XYZ PPP server.
#
NUM=5552857
UID=terryd
PASSWD=secret1
#
/usr/sbin/chat -v "" ATZ OK ATDT$NUM CONNECT ogin: $UID word: \\q$PASSWD PPP:

I've embellished the script with a sequence to initialise the modem before dialling (the ATZ. It is good practise to initialise your modem to something sensible before you start).

Note the "" argument, this means `wait for nothing' and is used when you want to start the sequence by sending something.

The -v argument tells chat to be verbose. In this mode it will send a transcript of the logon to syslog so that you can see what is happening. Note the \\q before the $PASSWD in the script. This tells chat not to echo the following text to syslog. In this way your password won't be logged in the system log.

You would want to use the chmod 600 /etc/ppp/ppp-connect to ensure that other users cannot read the script file and obtain your password.

To start your PPP session with the above configuration you would need only type: pppd and it all should happen automagically. You should observe the logon occurring in the system log and when it is finished you should see a default route in your routing table when you use the: route -n command pointed via your new ppp0 device.

If you use a static IP address you can specify that by including a line similar to the following in your /etc/ppp/options file:

nnn.nnn.nnn.nnn:

Where: nnn.nnn.nnn.nnn is your IP addresss. Note this will only work if your Internet Service Providers is configured to allow you to do so. The colon `:' is important.

There are many other options you may want to read about that you can include in your options file. Please refer to the pppd and chat man pages for more information.

Configuring a PPP client via a leased line.

Configuring a PPP client via a leased line is very simple. 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 defaultroute noipdefault debug \
kdebug 2 /dev/cua0 9600

This will open the serial device, generate the ioctl to change it into a pppdevice, 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/sbin/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.

The PPP-HOWTO is an excellent reference to obtain more comprehensive information than I have provided here.

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

To join the Linux linux-ppp channel on the mail list server, send mail to:

[email protected]
with the line:
subscribe linux-ppp
in the message body. The subject line is ignored.

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

12.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 three options as to how to configure your Linux machine as a SLIP server. My preference would be to use the first presented, sliplogin, as it seems the easiest to configure and understand, but I will present a summary of each, so you make your mind.

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. It allows you to configure your Linux machine as either a static address server, users get the same address everytime they call in, or a dynamic address server, where users get an address allocated for them which will not necessarily be the same as the last time they called.

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 specifically for them.

There are either three or four files that you need to configure to get sliplogin working for you. I will detail how and where to get the software and how each is configured in detail. The files are:

Where to get sliplogin

sliplogin can be obtained from:

sunsite.unc.edu

/pub/Linux/system/Network/serial/sliplogin-2.0.tar.gz

The tar file contains both source, precompiled binaries and a man page.

To ensure that only authorised users will be able to run sliplogin program, you should add an entry to your /etc/group file similar to the following:

 ..
SLIP::13:radio,fred
 ..

When you install the sliplogin package, the Makefile will change the group ownership of the sliplogin program to SLIP, and this will mean that only users who belong to that group will be able to execute it. The example above will allow only users radio and fred to execute sliplogin.

To install the binaries into your /sbin directory and the man page into section 8, do the following:

# cd /usr/src
# gzip -dc .../sliplogin-2.0.tar.gz | tar xvf -
# <..edit the Makefile if you don't use shadow passwords..>
# 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.

Please read the README files that come with the package for more information.

Configuring /etc/passwd for Slip hosts.

Normally you would 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 could create a /etc/passwd entry that looked like:

Sradio:FvKurok73:1427:1:radio SLIP login:/tmp:/sbin/sliplogin

It doesn't really matter what the account is called, so long as it is meaningful to you.

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. Sample entries for two hosts, one a static configuration for host radio and another, a dynamic configuration for user host albert might look like:

#
Sradio    44.136.8.99    44.136.8.100   0xffffff00   normal
Salbert   44.136.8.99    DYNAMIC        0xffffff00   compressed
#

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. If this field is coded DYNAMIC then an ip address will be allocated based on the information contained in your /etc/slip.tty file discussed later. Note: you must be using at least version 1.3 of sliplogin for this to work.
  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 (See section Name Resolution).

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

normal

to enable normal uncompressed SLIP.

compressed

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
arp -s $5 <hw_addr> pub
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.

Note also the use of Proxy ARP to ensure that other hosts on the same ethernet as the server machine will know how to reach the dial-in host. The <hw_addr> field should be the hardware address of the ethernet card in the machine. If your server machine isn't on an ethernet network then you can leave this line out completely.

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 in format.

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

All it does is `down' the interface and delete the manual route previously created. It also uses the arp command to delete any proxy arp put in place, again, you don't need the arp command in the script if your server machine does not have an ethernet port.

Configuring the /etc/slip.tty file.

If you are using dynamic ip address allocation (have any hosts configured with the DYNAMIC keyword in the /etc/slip.hosts file, then you must configure the /etc/slip.tty file to list what addresses are assigned to what port. You only need this file if you wish your server to dynamically allocate addresses to users.

The file is a table that lists the tty devices that will support dial-in SLIP connections and the ip address that should be assigned to users who call in on that port.

Its format is as follows:

# slip.tty    tty -> IP address mappings for dynamic SLIP
# format: /dev/tty?? xxx.xxx.xxx.xxx
#
/dev/ttyS0      192.168.0.100
/dev/ttyS1      192.168.0.101
#

What this table says is that callers that dial in on port /dev/ttyS0 who have their remote address field in the /etc/slip.hosts file set to DYNAMIC will be assigned an address of 192.168.0.100.

In this way you need only allocate one address per port for all users who do not require an dedicated address for themselves. This helps you keep the number of addresses you need down to a minimum to avoid wastage.

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. Please also beware that the following has been based on the dip337j-uri.tgz package and probably will not apply to other versions of dip.

dip has an input mode of operation, where it automatically locates an entry for the user who invoked it and configures the serial line as a SLIP link according to information it finds in the /etc/diphosts file. This input mode of operation is activated by invoking dip as diplogin. This therefore is how you use dip as a SLIP server, by creating special accounts where diplogin is used as the login shell.

The first thing you will need to do is to make a symbolic link as follows:

# ln -sf /usr/sbin/dip /usr/sbin/diplogin

You then need to add entries to both your /etc/passwd and your /etc/diphosts files. The entries you need to make are formatted as follows:

To configure Linux as a SLIP server with dip, you need to create some special SLIP accounts for users, where dip (in input mode) is used as the login shell. A suggested convention is that of having all SLIP accounts begin with a capital `S', eg `Sfredm'.

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

Sfredm:ij/SMxiTlGVCo:1004:10:Fred:/tmp:/usr/sbin/diplogin
^^         ^^        ^^  ^^   ^^   ^^   ^^
|          |         |   |    |    |    \__ diplogin 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 diplogin command. dip, when invoked as diplogin knows that it should automatically assume that it is being used a login shell. When it is started as diplogin the first thing it does is use the getuid() function call to get the userid of whoever has invoked it. It then searches the /etc/diphosts file for the first entry that matches either the userid or the name of the tty device that the call has come in on and configures itself appropriately. By judicious decision as to whether to give a user an entry in the diphosts file, or whether to let the user be given the default configuration you can build your server in such a way that you can have a mix of static and dynamically assigned address users.

dip will automatically add a `Proxy-ARP' entry if invoked in input mode, so you do not need to worry about manually adding such entries.

Configuring /etc/diphosts

/etc/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/diphosts is as follows:

 ..
Suwalt::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006
ttyS1::145.71.34.3:145.71.34.2:255.255.255.0:Dynamic ttyS1:CSLIP,296
 ..

The fields are:

  1. login name: as returned by getpwuid(getuid()) or tty name.
  2. unused: compat. with passwd
  3. Remote Address: IP address of the calling host, either numeric or by name
  4. Local Address: IP address of this machine, again numeric or by name
  5. Netmask: in dotted decimal notation
  6. Comment field: put whatever you want here.
  7. protocol: Slip, CSlip etc.
  8. MTU: decimal number

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

Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:SLIP,296

which specifies a SLIP link with remote address of 145.71.34.1 and MTU of 296, or:

Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006

which specifies a cSLIP-capable link with remote address 145.71.34.1 and MTU of 1006.

Therefore, all users who you wish to be allowed a statically allocated dial-up IP access should have an entry in the /etc/diphosts and if you want users who call a particular port to have their details dynamically allocated you must have an entry for the tty device and do not configure a user based entry. You should remember to configure at least one entry for each tty device that your dialup users use to ensure that a suitable configuration is available for them regardless of which modem they call in on.

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.

SLIP server using the dSLIP package.

Matt Dillon <[email protected]> has written a package that does not only dial-in but also dial-out SLIP. Matt's package is a combination of small programs and scripts that manage your connections for you. You will need to have tcsh installed as at least one of the scripts requires it. Matt supplies a binary copy of the expect utility as it too is needed by one of the scripts. You will most likely need some experience with expect to get this package working to your liking, but don't let that put you off.

Matt has written a good set of installation instructions in the README file, so I won't bother repeating them.

You can get the dSLIP package from its home site at:

apollo.west.oic.com

/pub/linux/dillon_src/dSLIP203.tgz

or from:

sunsite.unc.edu

/pub/Linux/system/Network/serial/dSLIP203.tgz

Read the README file and create the /etc/passwd and /etc/group entries before doing a make install.

12.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 required. 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 MST be read thoroughly to make full use of its extensive capabilities.

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

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 filesystems, 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 unmounted when they log out.

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

12.5 NIS - Sun Network Information System.

There is now an NIS-HOWTO which you should read if you are interested in using NIS. It details how to obtain, install and configure the NIS system for Linux.


Previous Next Contents Main Page