A6
Distributed file systems
A6.1
Introduction
Files systems typically use a directory structure which is based on folders which contain files
and/or subfolders. They store three main types of files:
•
•
•
Information. This will typically be user files, such as word processor files, spreadsheets,
and e-mail messages.
Program files. These will typically be application programs, such as a WWW browser
program, word processor program, spreadsheet program, and so on.
Configuration data. These will be important data which define the configuration of the
user’s computer. Typical storage will be hardware configuration data for the computer,
the setup of user’s desktop, and so on.
In the past, most information was stored locally on a computer, or centrally on a mainframe
computer, but there is now a trend to distribute information around networks. This has
many advantages over traditional localized information (Figure A6.1):
•
•
•
•
•
•
•
•
•
File system mirrors the corporate structure. File systems can be distributed over a corporate network, which might span cities, countries or even continents. The setup of a
complete network file system over a corporation can allow the network to mirror the
logical setup of the organization, rather than its physical and geographical organization. For example, the Sales Department might be distributed around the world, but the
network in which they connect to is identical to the way that the Sales Department is
organized.
Easier to protect the access rights on file systems. In a distributed file system, it is typical to have a strong security policy on the file system, and each file will have an owner
who can define the privileges on this file. File systems on user computers tend to have
limited user security.
Increased access to single sources of information. Many users can have access to a
single source of information. Having multiple versions of a file can cause a great deal of
problems, especially if it is not known as to which one is the most up to date.
Automated updates. Several copies of the same information can be stored, and when
any one of them is updated, they are synchronized to keep each of them up-to-date.
Users can thus have access to a local copy of data, rather than accessing a remote copy
of it. This is called mirroring files.
Improved backup facilities. A user’s computer can be switched-off, but their files can
still be backed up from the distributed file system.
Increased reliability. The distributed file system can have a backbone which is constructed from reliable and robust hardware, which are virtually 100% reliable, even
when there is a power failure, or when there is a hardware fault.
Larger file systems. In some types of distributed file systems, it is possible to build-up
large file systems from a network of connected disk drives.
Easier to administer. Administrators can easily view the complete file system.
Interlinking of databases. Small databases can be linked together to create large data-
•
bases, which can be configured for a given application. The future may also bring the
concept of data mining, where agent programs will search for information with a given
profile by interrogating databases on the Internet.
Limiting file access. Organizations can setup an organization file structure, in which
users can have a limited view of the complete file system.
in the past, the structure of file systems has been based on the physical connection of file
systems to the network. An enhanced method of organizing file systems is to setup a structure which mirrors the organizational structure of the organization. This makes it easier for
users to view the file system, as it is more logical in its structure. This is important because
for most users the organizational structure makes more sense to them than the structure of
files on a computer system. Figure A6.2 shows two file structures. The one on the left-hand
side is possibly easier for an experienced user to use, and the one on the right-hand side is
more intuitive to someone who understands the organizational structure of the organization. File systems, such as Novell NDS and Microsoft Active Directory try to setup file
systems that have a global file structure which try to mirror the structure of the organization. In these systems, resources, other than files such as printers, and file servers can be
mapped onto the file system.
Most file systems have a hierarchical file structure, which has directories that contain
subdirectories files and devices. The file system, itself, is a tree on a single server (normally a
single disk or a physical partition) which has a specified root. Some systems use a mount
system that mounts file systems onto a single tree, while others use a forest of file systems,
where the file systems appear individually. If possible, the mounting of a drive system
should be transparent to the user, and should be done automatically so that the user treats
the mounted drive just as a local resource. A major problem, though, is the security of the
remotely connected drive, thus each mounted drive must have strict rules on the access
rights for the local user.
Administration
services
Mounted as
a local drive
Localized
file storage
(rather than
accessing a
remote file)
Network
Distributed
databases
Networked file
system (NFS)
Figure A6.1
108
Handbook of the Internet
Centralized
configuration
(passwords, user IDs,
and so on)
Distributed file system
\\
users
users
orgname
orgname
config
config
sales
sales
progs
progs
fred
fred
production
production
research
research
UK
UKOffice
Office
bert
bert
Figure A6.2
US
USOffice
Office
Traditional file structure v. corporate structure
Drives can either be mounted locally to a computer as a single tree (as UNIX) or as a forest
of drives (as used with Microsoft Windows). In Figure A6.3, one of the computers has created a single tree that uses its local drives to create the /etc and /user directories, and then
mounts two networked drives to give /progs and /sys. The global file system will then be
mounted onto the common tree, with four subdirectories below the top-level directory (/).
The advantages of this type of system are:
•
•
•
The structure of the file system and the drives that are mounted are transparent to the
user. As far as the user is concerned the complete file system is viewable.
Every user can view the complete file system, if required.
The file system is consistent around the network, and can be setup on a per computer
basis.
With the forest of disks, a disk drive is mounted locally as if it is a local drive. In the example
in Figure A6.3, the remote drives have been mounted as E: and F:. Its main advantage over
the global file system is that:
•
•
It is easier to determine if the remote drive is mounted, as it will appear as a mounted
resource. With a single tree it is often difficult to determine if a drive is loaded onto the
global file system as the basic structure still exists.
Less complex than a global file, and easier to mount drives, but can become complex to
setup if there are many remote drives to be mounted.
Its main disadvantage is it is more difficult to setup than the single tree system as the local
mount drive must be specified, along with the path. In the global file system, files are
mounted on the system in a consistent way, such as with E:\FREDS_DRIVE. If the local system does not mount the remote drive onto the required disk partition, there may be
problems in the configuration of the system.
Distributed file systems 109
Single
tree
Global
file system
File
system
/etc
Drives mounted
over the network
to create a single tree
/progs
/user
/sys
Networ
Network
Networ
kk
C:
Forest of
drives
E:
D:
Figure A6.3
A6.2
F:
Drives mounted
over the network
to a forest of drives
Distributed file system
NFS
The Network File System (NFS) is defined in RFC1094 and allows computers to share the
same files over a network. It was originally developed by Sun Microsystems, and has the
great advantage that it is independent of the host operating system and can provide data
sharing among different types of systems (heterogeneous systems). This is achieved using
Remote Procedure Call (RPC), on top of XDR, which provides a standard method of representing data types. RPC is defined in RFC1057, and XDR is RFC1014.
NFS uses a client-server architecture where a computer can act as an NFS client, an NFS
server or both. An NFS client makes requests to access data and files on servers; the server
then makes that specific resource available to the client. NFS servers are passive and stateless. They wait for requests from clients and do not maintain any information on the client.
One advantage of servers being stateless is that it is possible to reboot servers without adverse consequences to the client. Servers do not preserve the current status of any of their
clients, which means that a client can simply retry a request from a server, if it fails to get a
response (in the event of a failure of the network or the server). If the server was stateful, the
client would have to know that a server had crashed or that the network connection had
broken, so that it knew which state is should be in, when the connection was returned, or
when the server came back on-line.
The server grants remote access privileges to a restricted set of clients, which allows
clients to mount remote directory trees onto their local file system. The components of NFS
are as follows (Figure A6.4 shows how the protocols fit into the OSI model):
•
•
110
NFS remote file access may be accompanied by network information service (NIS).
External data representation (XDR), which is a universal data representation, used by all
nodes, and provides a common data representation if applications are to run transparently on a heterogeneous network or if data is to be shared among heterogeneous
systems. Each node translates machine-dependent data formats to XDR format when
sending and translating data. XDR enables heterogeneous nodes and operating systems
to communicate with each other over the network.
Handbook of the Internet
•
•
Remote Procedure Call (RPC) allows clients to transparently execute procedures on remote systems of the network. NFS services run on top of the RPC, which corresponds to
the session layer of the OSI model.
Network lock manager (rpc.lockd) allows users to coordinate and control access to
information on the network. It supports file locking and synchronizes access to shared
files.
Application
NFS
NIS
Presentation
XDR
Session
RPC
Transport
TCP
Network
IP
Data link
Ethernet/
Token Ring
Physical
Figure A6.4
A6.2.5
NFS services protocol stack
NFS protocol
NFS assumes a hierarchical file structure. It can be used to mount file systems which map
into a single tree (as the UNIX file system), or it can be used to add a file system as one of a
forest of drives (as Microsoft Windows). NFS looks up one component of a pathname, at a
time, as different file systems use different separators to identify a pathname (for example,
UNIX uses ‘/’ and Microsoft Windows uses ‘\’, while others use periods).
The main NFS protocol is defined as a set of procedures with arguments and results defined using the RPC language. Each of the procedures is synchronous, and the client can
assume that a response from a request completes the operation. The procedures used are:
No.
0
Procedure
void NULL(void)
1
attrstat GETATTR(fhandle)
2
attrstat SETATTR(sattrargs)
Name
No
operation
Get file
attributes
Set file
attributes
Description
Used for server testing.
Returns the attributes of the file specified by fhandle.
The sattrargs contains fields which are either –1 or
are the new value for the file attributes. The sattargs
structure is:
struct sattrargs {
fhandle file;
sattr attributes;
};
where fhandle is the file handle that is passed between the client and the server. The structure of the
sattr is:
Distributed file systems 111
struct sattr {
unsigned int mode;
// file mode
unsigned int uid;
// user identification number
unsigned int gid; // group identification number
unsigned int size; // size of the file
timeval atime;
// time file last accessed
timeval mtime;
// time file last modified
};
6
readres READ(readargs)
Read from
file
Reads a number of bytes of data (given by count),
from a given file offset. The format of the readargs
structure is:
struct readargs {
fhandle file;
// used to represent file
unsigned offset; // starting position
unsigned count; // number of bytes to be
read
unsigned totalcount; // not used
};
8
attrstat WRITE(writeargs)
Write to
file
Writes data to a file starting at a given offset. The
format of writeargs structure is:
struct writeargs {
fhandle file;
// used to represent
file
unsigned beginoffset;
unsigned offset;
unsigned totalcount;
nfsdata data;
// not used
// starting position
// not used
// data to be written
};
9
diropres
CREATE(createargs)
Create file
Creates a file in the given directory, with a given set
of attributes. The format of the createargs structure
is:
struct createargs {
diropargs where;
sattr attributes;
};
The format of the diropags structure is:
struct diropargs {
fhandle dir;
// used to represent directory
filename name; // name of file
};
10
stat REMOVE(diropargs)
11
stat RENAME(renameargs)
12
112
stat LINK(linkargs)
Handbook of the Internet
Remove
file
Rename
file
Create
link to file
See above.
The format of the renameargs structure is:
struct renameargs {
diropargs from;
diropargs to;
};
For example, from.name is changed to to.name.
The format of the linkargs structure is:
struct linkargs {
fhandle from;
diropargs to;
13
14
stat SYMLINK(symlinkargs)
diropres MKDIR(createargs)
Create
symbolic
link
Create
directory
15
stat RMDIR(diropargs)
Remove
directory
16
readdirres
READDIR(readdirargs)
Read from
directory
};
The format of the aymlinkargs structure is:
struct symlinkargs {
diropargs from;
path to;
sattr attributes;
};
The format of the createargs structure is:
struct createargs {
diropargs where;
sattr attributes;
};
The format of the readdirargs structure is:
struct readdirargs {
fhandle dir;
nfscookie cookie; // Used to get the entries
// starting at the beginning of the directory
unsigned count;
// maximum number of entries
};
Figure A6.5 shows a client sending RPC procedures to the server, which responds back with
the required data, parameters or with a status flag. Typical status flags are: NFS_OK (success), NFSERR_PERM (not owner), NFSERR_NOENT (no such file or directory), NFSERR_IO
(some sort of hard error occurred), NFSERR_NXIO (no such device or address),
NFSERR_ACCES (permission denied), NFSERR_EXIST (the file specified already exists),
NFSERR_NODEV (no such device) and NFSERR_NOTDIR (not a directory).
A6.2.5
Network Information Service (NIS)
As networks grow in size, it becomes more difficult for the system administrator to maintain
the security of the network. An important factor is the maintenance of a passwords file,
where new users are added with the group, and any other information (such as their default
home directory). In most networks, a user should be able to log into any computer within a
domain. Thus, a global password and configuration files are required. This can be achieved
with NIS, which is an optional network control program which maintains the network configuration files over a network. NIS allows the system manager to centralize the key
configuration files on a single master server. If anyone wants to log into the network the
master server is consulted (or one of its slave servers). Figure A6.6 illustrates some of the
files that the server maintains; these include password (which contains the passwords for all
the users within the domain), and groups (the group that the user is associated with). It is
thus easy for the system administrator to add and delete users from the NIS server, and
these changes will be reflected over the domain. A user cannot log into any of the clients,
without the client checking with the server to see if they have a valid login and password.
Previously NIS was named Yellow Pages (YP), but has changed its name as this is a registered trademark of the British Telecommunications company. NIS normally administers the
network configuration files such as /etc/group (which defines the user groups),
/etc/hosts (which defines the IP address and symbolic names of nodes on a network),
/etc/passwd (which contains information, such as user names, encrypted passwords,
Distributed file systems 113
home directories, and so on). An excerpt from a passwd file is:
root:FDEc6.32:1:0:Super user:/user:/bin/csh
fred:jt.06hLdiSDaA:2:4:Fred Blogs:/user/fred:/bin/csh
fred2:jtY067SdiSFaA:3:4:Fred Smith:/user/fred2:/bin/csh
NFS server
Remotely accessed
file system
Network
Network
RPC procedures
getattr, setattr,
read, write,
create, remove,
rename, link,
symlink, mkdir,
rmdir, readdir
NFS client
File system either
mounted onto a single
tree or as a forest
of drives
Figure A6.5
RPC response
Requested data,
parameters or
status flag (such as:
NFS_OK and
NFSERR_PERM)
RPC procedures and responses
This passwd file has three defined users; these are root, fred and fred2. The encrypted
password is given in the second field (between the first and second column), and the third
field is a unique number that defines the user (in this case fred is 2 and fred2 is 3). The
fourth field in this case defines the group number (which ties up with the /etc/groups
file). An example of a groups file is given next. It can be seen from this file that group 4 is
defined as freds_grp, and contains three users: fred, fred2 and fred3. The fifth field is
simply a comment field and in this case it contains the user’s names. In the next field each
user’s home directory is defined and the final field contains the initial UNIX shell (in this
case it is the C-shell).
root::0:root
other::1:root,hpdb
bin::2:root,bin
sys::3:root,uucp
freds_grp::4:fred,fred2,fred3
A sample listing of a directory shows that a file owned by fred has the group name
freds_grp.
> ls -l
-r-sr-xr-x
-r-xr-xr-x
dr-xr-xr-x
-r-xr-sr-x
-r-xr-xr-x
114
1
13
2
1
2
fred
fred
fred
fred
fred
Handbook of the Internet
freds_grp
freds_grp
freds_grp
freds_grp
freds_grp
24576
40
1024
24576
16384
Apr
Apr
Aug
Apr
Apr
22 2000 file1
22 2000 file2
5 14:01 myfile
22 2000 text2.ps
22 2000 temp1.txt
#/etc/protocols
#/etc/protocols
ip
0
ip
0
icmp
1
icmp
1
ggp
3
ggp
3
tcp
6
tcp
6
Master NIS server maintains:
/etc/passwd
Domain passwords
/etc/groups
Domain groups
/etc/hosts
IP addresses and host names
/etc/rpc
RPC processes
/etc/network
Used to map IP address to networks
/etc/protocols
Known network layer protocols
/etc/services
Known transport layer protocols
IP
IP
ICMP
ICMP
GGP
GGP
TCP
TCP
Server
#/etc/groups
#/etc/groups
root::0:root
root::0:root
other::1:root,hpdb
other::1:root,hpdb
bin::2:root,bin
bin::2:root,bin
sys::3:root,uucp
sys::3:root,uucp
freds_grp::4:fred,fred2,fred3
freds_grp::4:fred,fred2,fred3
Clients
100000
100000
100001
100001
100002
100002
100003
100003
100004
100004
bath
bath
compuserve
compuserve
niss
niss
hensa
hensa
janet
janet
#/etc/passwd
#/etc/passwd
root:FDEc6.32:1:0:Super unser:/user:/bin/csh
root:FDEc6.32:1:0:Super unser:/user:/bin/csh
fred:jt.06hLdiSDaA:2:4:Fred Blogs:/user/fred:/bin/csh
fred:jt.06hLdiSDaA:2:4:Fred Blogs:/user/fred:/bin/csh
fred2:jtY067SdiSFaA:3:4:Fred Smith:/user/fred2:/bin/csh
fred2:jtY067SdiSFaA:3:4:Fred Smith:/user/fred2:/bin/csh
NIS
NIS
Domain
Domain
#/etc/rpc
#/etc/rpc
portmapper
portmapper
rstatd
rstatd
rusersd
rusersd
nfs
nfs
ypserv
ypserv
#/etc/hosts
#/etc/hosts
138.38.32.45
138.38.32.45
198.4.6.3
198.4.6.3
193.63.76.2
193.63.76.2
148.88.8.84
148.88.8.84
146.176.2.3
146.176.2.3
portmap sunrpc
portmap sunrpc
rstat rstat_svc
rstat rstat_svc
rusers
rusers
nfsprog
nfsprog
ypprog
ypprog
#/etc/services
#/etc/services
ftp
21/tcp
ftp
21/tcp
telnet
23/tcp
telnet
23/tcp
smtp
25/tcp
smtp
25/tcp
pop3
110/tcp
pop3
110/tcp
Figure A6.6
#/etc/networks
#/etc/networks
loopback
127.0.0.0
loopback
127.0.0.0
localnet
146.176.151.0
localnet
146.176.151.0
Production 146.176.142.0
Production 146.176.142.0
NIS domain
An excerpt from the /etc/hosts file is shown next.
138.38.32.45
198.4.6.3
193.63.76.2
148.88.8.84
146.176.2.3
146.176.151.51
bath
compuserve
niss
hensa
janet
sun
The /etc/protocols file contains information with known protocols used on the Internet.
# The form for each entry is:
# <official protocol name> <protocol number> <aliases>
# Internet (IP) protocols
ip
icmp
ggp
tcp
egp
pup
udp
hmp
xns-idp
rdp
0
1
3
6
8
12
17
20
22
27
IP
ICMP
GGP
TCP
EGP
PUP
UDP
HMP
XNS-IDP
RDP
#
#
#
#
#
#
#
#
#
#
internet protocol, pseudo protocol number
internet control message protocol
gateway-gateway protocol
transmission control protocol
exterior gateway protocol
PARC universal packet protocol
user datagram protocol
host monitoring protocol
Xerox NS IDP
"reliable datagram" protocol
The /etc/netgroup file defines network-wide groups used for permission checking when
doing remote mounts, remote logins, and remote shells. Here is a sample file:
Distributed file systems 115
# The format for each entry is: groupname member1 member2 ...
# (hostname, username, domainname)
engineering hardware software (host3, mikey, hp)
hardware (hardwhost1, chm, hp)
(hardwhost2, dae, hp)
software (softwhost1, jad, hp)
(softwhost2, dds, hp)
NIS master server and slave server
With NIS, a single node on a network acts as the NIS master server, with a number of NIS
slave servers, which receive their NIS information from the master server. The slaves are
important in that they hold copies of the most up-to-date version of the NIS database, so if
the master were to crash, or become uncontactable, the slaves could still provide password,
group, and other NIS information to the clients in the domain. The slaves also relieve the
workload on the master, as it may become busy responding to many NIS requests. When a
client first starts up it sends out a broadcast to all NIS servers (master or slaves) on the network and waits for the first one to respond. The client then binds to the first that responds
and addresses all NIS requests to that server. If this server becomes inoperative then an NIS
client will automatically rebind to the first NIS server which responds to another broadcast.
Figure A6.7 illustrates this.
Table A6.1 outlines the records which are used in the NIS database (or NIS map). This
file consists of logical records with a search key and a related value for each record. For example, in the passwd.byname map, the users’ login names are the keys and the matching
lines from /etc/passwd are the values.
Master NIS
Server maintains:
/etc/passwd
/etc/groups
/etc/hosts
/etc/rpc
/etc/network
/etc/protocols
/etc/services
and so on.
Master sends updates to
NIS slaves
NIS
NIS
Domain
Domain
2. Client broadcasts
an NIS request to the
domain
3. The client then binds to
the first server which
responds
Slave NIS
server
Figure A6.7
116
Handbook of the Internet
Slave NIS
server
NIS domain
1. Client is
started
NIS
client
Table A6.1
NIS map
group.bygid
group.byname
NIS database components
File maintained
/etc/group
Description
Maintains user groups.
hosts.byaddr
hosts.byname
/etc/hosts
Maintains a list of IP addresses and symbolic names.
netgroup.byhost
netgroup.byuser
/etc/netgroup
networks.byaddr
networks.byname
/etc/network
Contains a mapping of network group
names to a set of node, user and NIS domain names.
Defines network-wide groups used for
permission checking when doing remote
mounts, remote logins, and remote shells.
passwd.byname
passwd.byuid
/etc/passwd
Contains details such as user names and
encrypted passwords.
protocols.byname
protocols.bynumber
/etc/protocols
Contains information with known protocols used on the Internet.
rpc.bynumber
rpc.byname
/etc/rpc
Maps the RPC program names to the RPC
program numbers and vice versa. This file
is static; it is already correctly configured.
services.byname
servi.bynp
/etc/services
mail.byaddr
mail.aliases
/etc/aliases
NIS domain
An NIS domain is a logical grouping of the set of maps contained on NIS servers. The rules
for NIS domains are:
•
•
•
All nodes in an NIS domain have the same domain name.
Only one master server exists on an NIS domain.
Each NIS domain can have zero or more slave servers.
An NIS domain is a subdirectory of /usr/etc/yp on each NIS server, where the name of
the subdirectory is the name of the NIS domain. All directories that appear under
/usr/etc/yp are assumed to be domains that are served by an NIS server. Thus to remove
a domain being served, the user deletes the domain’s subdirectory name from
/etc/etc/yp on all of its servers.
The start-up file on most UNIX systems is the /etc/rc file. This automatically calls the
/etc/netnfsrc file which contains the default NIS domain name, and uses the program
domainname.
Distributed file systems 117
A6.2.5
NFS remote file access
To initially mount a remote directory (or file system) onto a local computer the superuser
must do the following:
•
•
On the server, export the directory to the client.
On the client, mount (or import) the directory.
For example suppose the remote directory /user is to be mounted onto the host miranda as
the directory /win. To achieve this operation the following are setup:
1.
The superuser logs on to the remote server and edits the file /etc/exports adding the
/user directory.
2.
The superuser then runs the program exportfs to make the /user directory available to
the client.
% exportfs -a
3. The superuser then logs into the client and creates a mount point /win (empty directory).
% mkdir /mnt
4. The remote directory can then be mounted with:
% mount miranda:/user /win
NFS maintains the file /etc/mnttab which contains a record of the mounted file systems.
The general format is:
special_file_name dir type opts freq passno mount_time cnode_id
where mount_time contains the time the file system was mounted using mount. Sample
contents of /etc/mnttab could be:
/dev/dsk/c201d6s0
/dev/dsk/c201d5s0
castor:/win
miranda:/win
spica:/usr/opt
triton:/win
/
/win
/net/castor_win
/net/miranda_win
/opt
/net/triton_win
hfs
hfs
nfs
nfs
nfs
nfs
defaults
defaults
rw,suid
rw,suid
rw,suid
rw,suid
0
1
0
0
0
0
1
2
0
0
0
0
850144122
850144127
850144231
850144291
850305936
850305936
1
1
0
0
0
0
In this case there are two local drivers (/dev/dsk/c201d6s0 is mounted as the root directory
and /dev/dsk/c201d5s0 is mounted locally as /win). There are also four remote directories
which are mounted from remote servers (castor, miranda, spica and triton). The directory mounted from castor is the /win directory and it is mounted locally as
/net/castor_win.hfs defines a UNIX format disk and nfs defines that the disk is mounted
over NFS.
A disk can be unmounted from a system using the umount command, e.g.
% umount miranda:/win
118
Handbook of the Internet
A6.2.5
NIS commands
NIS commands allow the maintenance of network information. The main commands are as
follows:
•
•
•
•
•
•
•
•
domainname which displays or changes the current NIS domain name.
ypcat which lists the specified NIS map contents.
ypinit which, on a master server, builds a map using the networking files in /etc. On a
slave server the map is built using the master server.
ypmake which is a script that builds standard NIS maps from files such as
/etc/passwd, /etc/groups, and so on.
ypmatch which prints the specified NIS map data (values) associated with one or more
keys.
yppasswd which can be used to change (or install) a user’s password in the NIS passwd
map.
ypwhich which is used to print the host name of the NIS server supplying NIS services
to an NIS client.
ypxfr which transfers the NIS map from one slave server to another.
For example the command:
ypcat group.byname
lists the group name, the group ID and the members of the group. Here is an example of
changing a user’s password for the NIS domain. In this case, the user bill_b changes the
network-wide password on the master server pollux.
% yppasswd
Changing NIS password for bill_b...
Old NIS password: ********
New password: *******
Retype new password: *******
The NIS passwd has been changed on pollux, the master NIS passwd
server.
The next example uses the ypcat program.
% ypcat group
students:*:200:msc01,msc02,msc03,msc04
nogroup:*:-2:
daemon::5:root,daemon
users::20:root,msc08
other::1:root,hpdb
root::0:root
The next example shows the ypmake command file which rebuilds the NIS database.
# ypmake
For NIS domain eece:
The passwd map(s) are up-to-date.
Building the group map(s)... group build complete.
Pushing the group map(s): group.bygid group.byname
Distributed file systems 119
The hosts map(s) are up-to-date.
The networks map(s) are up-to-date.
The rpc map(s) are up-to-date.
The services map(s) are up-to-date.
The protocols map(s) are up-to-date.
The netgroup map(s) are up-to-date.
ypmake complete:
A6.2.5
Network configuration files
The main files used to setup networking are as follows:
/etc/checklist
/etc/exports
/etc/inetd.conf
/etc/netgroup
/etc/netnfsrc
/etc/rpc
/usr/adm/inetd.sec
is a list of directories or files that are automatically mounted at boot
time.
contains a list of directories or files that clients may import.
contains information about servers started by inetd (the Internet
daemon). Listing A6.1 shows an example of the inetd.conf file. It
can be seen that it includes the service name, socket type (stream
or datagram), the protocol (TCP or UDP), flags, the owner, the
server path, and any other arguments. Lines which begin with the
‘#’ character are ignored by inetd. It can be seen that many of the
Internet-related programs, such as FTP and TELNET are started
here, as well as the login program (LOGIN).
contains a mapping of network group names to a set of node, user,
and NIS domain names.
is automatically started at run time and initiates the required daemons and servers, and defines the node as a client or server.
maps the RPC program names to the RPC program numbers and
vice versa.
checks the Internet address of the host requesting a service against
the list of hosts allowed to use the service.
Listing A6.1 (inetd.conf)
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
# Echo, discard and daytime are used primarily for testing.
echo
stream
tcp
nowait
root internal
echo
dgram
udp
wait
root internal
discard stream
tcp
nowait
root internal
discard dgram
udp
wait
root internal
daytime stream
tcp
nowait
root internal
daytime dgram
udp
wait
root internal
time
dgram
udp
wait
root internal
#
# These are standard services.
ftp
stream
tcp
nowait
root /usr/sbin/tcpd /usr/sbin/wu.ftpd
telnet
stream
tcp
nowait
root /usr/sbin/tcpd /usr/sbin/in.telnetd
#
# Shell, login, exec and talk are BSD protocols.
shell
stream
tcp
nowait
root /usr/sbin/tcpd /usr/sbin/in.rshd
login
stream
tcp
nowait
root /usr/sbin/tcpd /usr/sbin/in.rlogind
talk
dgram
udp
wait
root /usr/sbin/tcpd /usr/sbin/in.ntalkd
ntalk
dgram
udp
wait
root /usr/sbin/tcpd /usr/sbin/in.ntalkd
#
# Pop mail servers
pop3
stream
tcp
nowait
root /usr/sbin/tcpd /usr/sbin/in.pop3d
120
Handbook of the Internet
#
bootps
#
finger
systat
netstat
dgram
udp
wait
root
/usr/sbin/tcpd /usr/sbin/in.bootpd
stream
stream
stream
tcp
tcp
tcp
nowait
nowait
nowait
daemon
guest
guest
/usr/sbin/tcpd /usr/sbin/in.fingerd
/usr/sbin/tcpd /usr/bin/ps -auwwx
/usr/sbin/tcpd /bin/netstat -f inet
Daemons
Networking programs normally initiate networking daemons which are background processes and are always running. Their main function is to wait for a request to perform a task.
Typical daemons are:
biod
inetd
nfsd
pcnfsd
portmap
which is asynchronous block I/O daemons for NFS clients.
which is an Internet daemon that listens to service ports. It listens for service
requests and calls the appropriate server. The server it calls depends on the
contents of the /etc/inetd.conf file.
which is the NFS server daemon. It is used by the client for reading and writing to a remote directory and it sends a request to the remote server nfsd
process.
which is a PC user authentication daemon.
which is an RPC program to port number conversion daemon. When a client
makes an RPC call to a given program number, it first contacts portmap on the
server node to determine the port number where RPC requests should be
sent.
Here is an extract from the processes that run a networked UNIX workstation:
UID
root
root
root
root
root
root
root
root
root
root
root
root
root
A6.3
PID
100
138
104
106
122
116
123
128
131
133
135
4652
4649
PPID
1
1
1
1
120
1
120
1
1
1
1
1
1
C
STIME TTY
0 Dec 9 ?
0 Dec 9 ?
0 Dec 9 ?
0 Dec 9 ?
0 Dec 9 ?
0 Dec 9 ?
0 Dec 9 ?
0 Dec 9 ?
0 Dec 9 ?
0 Dec 9 ?
0 Dec 9 ?
0 14:33:15 ?
0 14:33:15 ?
TIME
0:00
0:00
9:20
0:00
0:00
0:00
0:00
0:02
0:00
0:00
0:00
0:00
0:00
COMMAND
/etc/portmap
/etc/inetd
/usr/etc/ypserv
/etc/ypbind
/etc/nfsd 4
/usr/etc/rpc.yppasswdd
/etc/nfsd 4
/etc/biod 4
/etc/pcnfsd
/usr/etc/rpc.statd
/usr/etc/rpc.lockd
/etc/pcnfsd
/usr/etc/rpc.mountd
Other distributed file systems
Active Directories, and Novell NDS will be discussed in the NOS section.
Distributed file systems 121