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.
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,
<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 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.
You would use PPP in place of SLIP for a few reasons. The most common are:
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.
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.
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.
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.
Installation of the PPP software is fairly straightforward.
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.
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.
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.
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:
/etc/ppp/ppp-connect script to
dial the modem and login.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.lock file for the tty
device to ensure that other processes do not attempt to open it while
pppd is using it.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.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 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 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.
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:
Majordomo@vger.rutgers.edu
subscribe linux-ppp
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).
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.
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:
/etc/passwd, for the dialin user accounts./etc/slip.hosts, to contain the information unique to each
dial-in user./etc/slip.login, which manages the configuration of the routing
that needs to be performed for the user./etc/slip.tty, which is required only if you are configuring
your server for dynamic address allocation and contains a table
of addresses to allocate/etc/slip.logout, which contains commands to clean up after the
user has hung up or logged out.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.
/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.
/etc/slip.hostsThe /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:
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.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:
to enable normal uncompressed SLIP.
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.
/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.
/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.
/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.
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.
/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:
login name: as returned by getpwuid(getuid()) or tty name.unused: compat. with passwdRemote Address: IP address of the calling host, either numeric or by nameLocal Address: IP address of this machine, again numeric or by nameNetmask: in dotted decimal notationComment field: put whatever you want here.protocol: Slip, CSlip etc.MTU: decimal numberAn 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.
Matt Dillon <dillon@apollo.west.oic.com> 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.
This section has been supplied by Mitch DSouza and I've included
it with minimal editing, as he supplied it. Thanks Mitch.
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):
contrib directory -
automount2amd.pl.
..., opts:=type=msdos,conv=auto
/home
when some user directory is /home/fred.
% amq -ms
# /etc/amd -x all -l syslog -a /amd -- /net /etc/amd.net
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.
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:
/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.
# /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.
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.
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.