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.
Let me start by saying that some of the information below came from the dip man pages, where in fact 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.
/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, PPP)
| | | \___________________ 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.
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 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):
contrib
directory -
automount2amd.pl
.
..., opts:=type=msdos,conv=auto
/home
when some user directory is /home/fred
.
% amq -ms
reports, as it will indicate problems as they occur.
# /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
fileystems, instead 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 umounted when they log out.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter