UNIX System Administration phần 8 docx

DFS Command Summary
UNIX System Administration © 1998 University Technology Services, The Ohio State University 205
DFS Command SummaryDFS Command Summary
20.4.6.2 Sharing and Unsharing Resources
To share resources use the share and shareall commands and unshare them with the unshare and
unshareall commands. You can specify file system types (-F) a description of the resource (-d) and
various options to control client access (-o, with ro/rw, or rw=client[:client2]). With the unshare(all)
commands you can only specify a file system type, so you can unshare all nfs file types with the
command:
# unshareall -F nfs
The shareall command shares all resources specified in the /etc/dfs/dfstab file, or a named file.
When invoked with no arguments the share command displays the resources currently shared, e.g.:
# share
- /cdrom ro=ace:tardis:gallifrey “nyssa cdrom”
20.4.6.3 Displaying Available Resources
To display mounted resources information use the dfmounts command. This command shows the
local resources that are shared along with the clients that have the resource mounted.
# dfmounts
RESOURCE SERVER PATH CLIENTS
- nyssa /cdrom gallifrey
To display available resources from remote or local systems use the dfshares command, e.g.:
# dfshares
RESOURCE SERVER ACCESS TRANSPORT
nyssa:/cdrom nyssa - -
20.5 DFS Command Summary
The following table summarizes the commands used to administer Distributed File Systems in
SunOS.
TABLE 20.2 DFS Command Summary
SunOS 4.X SunOS 5.X Description
mount -a mountall Mount all file systems
umount -a umountall Unmount all file systems

exportfs share Share file systems
exportfs -u unshare Unshare file systems
exportfs -a shareall Share all file systems
showmount -d dfmounts Show mounted file systems
showmount -e dfshares Show shared file systems
Distributed File System Administration
206 © 1998 University Technology Services, The Ohio State University UNIX System Administration
Distributed File System AdministrationDistributed File System Administration
20.6 IRIX 5.X, Ultrix and Digital UNIX
IRIX 5.X, Ultrix, and Digital UNIX all use /etc/exports to specify the files available for sharing over
the network. IRIX, similar to SunOS 4.X, requires you to run /usr/etc/exportfs to actually export
those files. Ultrix and Digital UNIX do not use the exportfs command.
20.7 NFS statistics
20.7.1 netstat
netstat can be used to show the per-protocol statistics with the -s options, e.g. on SunOS 4.1.X:
# netstat -s
udp:
0 incomplete headers
0 bad data length fields
0 bad checksums
0 socket overflows
tcp:
21392 packets sent
13925 data packets (1565473 bytes)
23 data packets (901 bytes) retransmitted
…
If udp reports socket overflows then increase the number of nfsds, as user processes aren’t draining
the sockets quickly enough. Typically a SunOS 4.X server starts, by default, 8 NFS daemons. On
some systems it may be more appropriate to have 12 → 20 nfsds.
20.7.2 nfsstat

The nfsstat command can be used to display statistics related to NFS activity. This command is
useful when trying to debug NFS and RPC problems. nfsstat also has options to show both client
and server information.
20.7.2.1 Server
On the server use nfsstat -ns (-n ⇒ NFS information; -s ⇒ server) to examine the statistics, e.g.:
% nfsstat -ns
Server nfs:
calls badcalls
69350 0
null getattr setattr root lookup readlink read
0 0% 54682 78% 266 0% 0 0% 7138 10% 748 1% 3352 4%
wrcache write create remove rename link symlink
0 0% 1465 2% 421 0% 247 0% 84 0% 5 0% 0 0%
mkdir rmdir readdir fsstat
3 0% 0 0% 902 1% 37 0%
NFS statistics
UNIX System Administration © 1998 University Technology Services, The Ohio State University 207
NFS statisticsNFS statistics
Of these RPC calls, root and wrcache are not currently used by NFS.
If readlink is high (>10%) replace symbolic links with mount points wherever possible on the client
to improve NFS performance.
If getattr is > 50% check for non-default attribute caching.
20.7.2.2 Client
To display client statistics, on the client execute nfsstat -rc (-r ⇒ RPC information; -c ⇒ client), e.g.:
% nfsstat -rc
Client rpc:
calls badcalls retrans badxid timeout wait newcred timers
307703 54 31 24 82 0 0 2037
where
calls total number of RPC calls received

badcalls timeouts resulting from RPC error
retrans retransmission count
badxid duplicate responses from server
timeout # of RPC calls timed out
wait calls that had to wait on a busy CLIENT handle
newcred refreshes of authentication information
If retrans > 5% of total calls, then requests are not reaching the server.
If badxid ~ timeout, then most requests are reaching the server, and the server is the bottleneck.
If badcalls ~ timeout, then soft-mounted filesystems are failing.
You can check the NFS mounted file system states for the client with nfsstat -m (-m ⇒ NFS stats for
each mounted file system), e.g.:
% nfsstat -m
/usr/local from server:/usr/local
Flags: vers=2,proto=udp,auth=unix,hard,intr,dynamic,rsize=8192,wsize=8192,retrans=5
Lookups: srtt=7 (17ms), dev=4 (20ms), cur=2 (40ms)
Reads: srtt=7 (17ms), dev=4 (20ms), cur=2 (40ms)
Writes: srtt=31 (77ms), dev=3 (15ms), cur=5 (100ms)
All: srtt=7 (17ms), dev=4 (20ms), cur=2 (40ms)
/opt/ftp from susan:/opt/ftp
Flags: vers=3,proto=tcp,auth=unix,hard,intr,link,symlink,acl,rsize=32768,wsize=32768,retrans=5
All: srtt=0 (0ms), dev=0 (0ms), cur=0 (0ms)
where
srtt smoothed round-trip time
dev estimated deviation
cur current backed-off timeout value
Distributed File System Administration
208 © 1998 University Technology Services, The Ohio State University UNIX System Administration
Distributed File System AdministrationDistributed File System Administration
If srtt > 50 ms, then the mount point is slow, either at the server or because of network problems.
If Lookups: cur > 80 ms, or Reads: cur > 150 ms, or Writes: cur > 250 ms, it’s taking tool long to

process the requests on the server side (either server or network).
If you frequently see the "NFS server not responding" error message it maybe time to increase the
timeo setting on the mount in /etc/fstab or /etc/vfstab (SunOS 5.X).
To correct for slow servers, (i.e. badxid ~ timeout) increase the RPC timeout (timeo option of the
mount command). To correct for badcalls ~ timeout, increase retrans and possibly timeo option
values. It is recommended that soft mounts not be used for writable filesystems or for executable files.
Soft is recommended for only non-executable file systems mounted read-only. For other filesystems
’hard,intr,bg’ is recommended. If the network is the bottleneck (i.e. badxid ~ 0) it may be necessary
to decrease the NFS buffer sizes: rsize and wsize, on the client from 8kB to 2kB. Network bottlenecks
can also have other causes, e.g. the interconnection device (gateway, router, bridge) may be limiting.
UNIX System Administration © 1998 University Technology Services, The Ohio State University 209
CHAPTER 21 Network Information
Services (NIS and NIS+)
21.1 What is it and what does it do for you?
The Network Information Service (NIS) allows networked machines to have a common interface
regardless of the workstation that you log into. This service was formerly known as the Yellow Pages,
or YP. With NIS you have the same passwd and group files (same uid and gid) and can be placed into
the same home directory on each of your machines.
These services are considerably expanded under SunOS 5.X as Network Information Services Plus
(NIS+). The Solaris 2 CDROM provides an NIS+ version that will run under SunOS 4.1.X in case
you want to mix and match servers.
21.2 NIS
21.2.1 Initialization
Install the NIS software during installation with suninstall, or later with /usr/etc/install/add_services.
Initialize the NIS domain by running /usr/etc/ypserv, on the server and on its clients running
/usr/etc/ypbind. This is done in /etc/rc.local. The NIS servers can also be NIS clients. You can
have slave servers for redundancy.
You need to specify a domainname, e.g. department, etc. in /etc/rc.local. This is completely separate
from the IP domain name. Normally the NIS domainname is put in the file /etc/defaultdomain for
use during startup. If this file does not exist or has the contents "noname", it is assumed that you are

not using NIS. The domainname can be set or displayed with the domainname command.
You originally set up the NIS databases on the server with the command /usr/etc/yp/ypinit -m/s
(master/slave). In the simple case the server is the master for all maps in the database. All databases
are built from scratch with ypinit. To update changed databases, e.g. after installing a new user:
# cd /var/yp; make
This will push the new databases to all the machines in the NIS domain.
If you have more than one NIS server you may wish to bind a particular machine with a specific server.
This can be done with the ypset command in conjunction with using the -ypset option to ypbind.
To display your current NIS server use the ypwhich command.
Network Information Services (NIS and NIS+)
210 © 1998 University Technology Services, The Ohio State University UNIX System Administration
Network Information Services (NIS and NIS+)Network Information Services (NIS and NIS+)
To display contents of the NIS tables you can use the ypcat and ypmatch commands. ypcat lists the
specified table. ypmatch matches a keyword with the specified table, e.g.:
% ypmatch frank passwd
frank:jkl/fdasjklKY:101:10:Frank G Fiamingo:/home/tardis/frank:/usr/bin/tcsh
21.2.2 Databases controlled by NIS
The information in the NIS maps is in a database format using the ndbm library. Each map has 2 files:
.pag, and .dir. These are contained in a subdirectory of /var/yp named after your NIS "domain". The
databases are:
Name Service
aliases mail aliases and addresses
bootparams boot and NFS mount information for diskless clients
ethers hostname and ethernet addresses
group group names and gid’s
hosts hostname and internet addresses
netgroup netgroup membership list
netid map of local userID/groupID/group access-list and hosts for DES
netmasks network number and netmask
networks network number and internet name

passwd username and password information
protocols internet protocol names and numbers
publickey public and secret keys for secure NFS
rpc RPC program name and number
services internet service name, port number, and protocol
To tell the SunOS 4.1.X system to use the NIS database for passwd and group files put entries such as:
+::0:0:::
as the last entry in the /etc/passwd file of the NIS clients, i.e. all NIS password entries are valid on
this host. Other examples of limitations and exclusions are, for /etc/passwd:
+frank: - frank is a valid user, use his entry from the NIS database.
+frank:::::/home/new/frank: - frank is a valid user, all entries are as in the NIS database, except his
login directory.
+@group:*:0:0:::/bin/true - the group "group" can’t login, but users in this group can refer to
their home directories.
-@group::0:0::: - exclude this group from entry.
and for /etc/group:
+: - all entries in the NIS group database are valid here.
+group: - the NIS group "group" is valid.
+project:::frank,bob - only the member frank and bob of group "project" are valid.
NIS+
UNIX System Administration © 1998 University Technology Services, The Ohio State University 211
NIS+NIS+
SunOS 5.X clients will use the NIS database if nis and compat (for NIS +/- entry compatibility) are
specified for the passwd entry in /etc/nsswitch.conf, e.g.:
passwd: compat files nis
To use the default NIS passwd table there is no need to add additional entries to /etc/passwd on the
SunOS 5.X client.
21.3 NIS+
SunOS 5.X provides an enhanced version of NIS, NIS+, that is upwardly compatible with NIS. The
new service provides for a hierarchical name space, similar to that used by the Internet. This allows

for a distributed authority mechanism. User’s can be given access to an entire database, or just
particular entries within a database. Administrators can be restricted to changing files only within
their domain.
NIS+ propagates only changes in the maps, not the entire map. This allows for much faster updates.
Entries are changeable anywhere on the NIS+ network. You don’t have to be on the server to change
the maps.
The authorization model for NIS+ is similar to that for the UNIX file system. Each item in the
namespace has an access rights list associated with it. These rights grant access to owner of the item,
group owner of the item, and all others.
21.3.1 Domains
The NIS+ domain is composed of a directory object and all of its children. The NIS+ namespace is
made up of all the domains below the root directory. Each name is composed of a series of characters
separated by a (.). These character sequences are known as labels. The label furthest to the right is
closest to the root of the namespace. The (.) name is reserved to indicate the global root namespace;
the root directory name always ends with a (.). NIS+ names are not case sensitive.
The root server is the server for the root (.) domain. There is only one root server for a domain.
A master server serves a domain. A master server is a client of the server directly above it in the
hierarchy.
A replica server is a copy of the master server, formerly known as a slave server. This provides
redundancy for the service.
Network Information Services (NIS and NIS+)
212 © 1998 University Technology Services, The Ohio State University UNIX System Administration
Network Information Services (NIS and NIS+)Network Information Services (NIS and NIS+)
21.3.2 Objects
There are three types of objects:
• directory objects which form the framework of the namespace
• table objects which store the information
• group objects which are used for security
The directory objects are at the top of the namespace. Directory objects contain the names,
addresses, and authentication information for systems within the domain. Objects within the database

are stored as children of the directory object. The directory object at the top of the hierarchy is known
as the root directory. You can add directory objects beneath the root directory and beneath other
directory objects.
The table objects identify table databases. The table object contains the scheme by which columns
within the table can be identified and searched. Each table contains information about users,
machines, or resources on the network. The normal set of 16 tables store information for:
hosts bootparams password cred
group netgroups mail aliases timezone
networks netmasks ethers services
protocols rpc auto.home auto.master
The group objects contain a list of members of the group. An NIS+ group is a collection of users and
workstations identified by a single name. They are assigned access rights as a group. Essentially,
this is used to set security.
All objects have a common set of properties. These are:
principal owner
group owner
access rights
unique id
time to live values
Also, each object type specifies information describing the type.
Link objects point to the name of another object.
21.3.3 Names
In general you can name directories any name you like. Two names are reserved, however: org_dir
and groups_dir. They are reserved only for the objects that store the NIS+ table and group objects,
respectively. An NIS+ domain consists of a directory object, the groups_dir and org_dir
subdirectories, and a set of NIS+ tables.
Names that identify objects in the namespace are known as regular names.
NIS+
UNIX System Administration © 1998 University Technology Services, The Ohio State University 213
NIS+NIS+

Index names identify rows within a table. These are compound names containing a search criterion
and a regular name. The regular name specifies the table to search, while the search criterion
specifies the column values to search for within the table.
21.3.4 Authorization and Authentication
NIS+ authorization allows four classes of principals:
• owner of the object
• group set of specified users
• world set of authenticated users
• nobody all clients
and four access rights:
• read read contents of objects
• modify change objects
• create add objects to tables and directories
• destroy remove objects from tables and directories
Authentication is based on secure RPC. Solaris 2 supports three levels:
• none no authentication
• LOCAL AUTH_SYS RPC authentication
• DES AUTH_DES Secure RPC
DES authentication is the most secure, but if you are running with Secure RPC you will not be able to
mount files from servers not running Secure RPC (i.e. SunOS 4.X servers).
Authentication is performed for every NIS+ request. If credentials can not be confirmed the client is
treated as nobody.
21.3.5 Configuration
The familiar yp* commands have been replaced with commands beginning with nis. The NIS+
administrative commands are located in /usr/bin, /usr/sbin and /usr/lib/nis.
Starting with SunOS 5.3 Sun has added some scripts to assist you in setting up an NIS+ system.
These scripts can be found in /usr/lib/nis. They automate setting up servers, clients, and populating
NIS+ tables. The scripts are:
• nisserver set up NIS+ servers, root master, non-root master, and replica servers
• nisclient initialize NIS+ credentials for hosts and users

• nispopulate populate NIS+ tables from files or NIS maps
Network Information Services (NIS and NIS+)
214 © 1998 University Technology Services, The Ohio State University UNIX System Administration
Network Information Services (NIS and NIS+)Network Information Services (NIS and NIS+)
21.3.5.1 Initialize a Server
The nisinit command is used to setup a client, master server, or replica server for NIS+. To initialize
the root server use the -r option:
# nisinit -r
This should only be run once for the name space. It uses the domainname specified in
/etc/defaultdomain and places it’s root object in the directory /var/nis.
21.3.5.2 Tables
The nissetup shell script is found in /usr/lib/nis. It creates org_dir and groups_dir directories and the
standard tables, though empty, in an NIS+ directory. The domain should have first been created with
the /usr/bin/nismkdir command. Subdirectories are removed with the nisrmdir command. Copies of
the information are automatically passed to replica servers.
21.3.5.3 Credentials
The /usr/bin/nisaddcred command is used to create credentials for an NIS+ principal. These
credentials are stored in the cred.org_dir public key table. You can add local or des credentials for
the principal, e.g.:
# nisaddcred -p <uid> -P login.domain local
21.3.5.4 Permissions
Change permission attributes of an object with the /usr/bin/nischmod command. You must have
modify access to the object before you can change the attributes.
The /usr/bin/nisls command can be used to list the objects and permissions of an NIS+ directory.
21.3.5.5 Table Entries
The /usr/lib/nis/nisaddent utility is used to add table entries. It can use NIS maps, /etc files, NIS+
tables, or command line arguments as it’s source. With nisaddent you can dump entries from a table
into a file. To enter the /etc/hosts table into the NIS+ database you could do the following.
# cat /etc/hosts | /usr/lib/nis/nisaddent -av hosts
adding stdin to table hosts.org_dir.your.domain.

adding/updating localhost
adding/updating nyssa

You can administer NIS+ tables with /usr/bin/nistbladm. This command will allow you to create and
delete tables, add entries to and modify entries within tables, and remove entries from tables.
You can display NIS+ tables and objects with the /usr/bin/niscat command, e.g.:
# niscat -h netmasks.org_dir
# number mask comment
128.146 255.255.255.0
The commands nismatch and nisgrep in /usr/bin can be used to match keywords and grep for regular
expressions, respectively, in NIS+ tables.
NIS+
UNIX System Administration © 1998 University Technology Services, The Ohio State University 215
NIS+NIS+
21.3.5.6 Defaults
Default values for principal name, domain name, host name, group name, access rights, time to live,
and search path can be obtained with the nisdefaults command in /usr/bin.
21.3.6 NIS+ Setup
These next few sub-sections indicate how to set up root, master, and replica servers, and client
machines.
21.3.6.1 Root Master Server
1. Choose a domainname
# domainname acs.ohio-state.edu.
# domainname > /etc/defaultdomain
2. Choose the NIS+ version for nsswitch.conf
# cp /etc/nsswitch.nisplus /etc/nsswitch.conf
3. Initialize the server
# nisinit -r
where
-r root server

4. Start the daemon
# rpc.nisd -rS 0
where
-r indicates a root server
-S 0 sets the security level to 0, i.e. non-secure, does not enforce access controls
5. Setup the NIS+ directory structure
# /usr/lib/nis/nissetup acs.ohio-state.edu.
6. Add data to the tables
cat <file> | nisaddent -a <tablename>
where
-a specifies to add entries without deleting existing entries
7. Verify the entries, e.g.
# niscat hosts.org_dir
21.3.6.2 SubDomain Server (Non-Root Master)
The root and master servers can be the same machine.
1. Become a client of the parent domain
# domainname wks.acs.ohio-state.edu.
# domainname > /etc/defaultdomain
# cp /etc/nsswitch.nisplus /etc/nsswitch.conf
# nisinit -c -H <domain server hostname>
where
-c initializes an NIS+ client
-H hostname specifies hostname is the trusted server
Network Information Services (NIS and NIS+)
216 © 1998 University Technology Services, The Ohio State University UNIX System Administration
Network Information Services (NIS and NIS+)Network Information Services (NIS and NIS+)
2. Start the daemon in non-secure mode
# rpc.nisd -S 0
3. Make the directories for the databases
# nismkdir -m <subdomain server name> wks.acs.ohio-state.edu.

where
-m hostname create the directory with hostname as the master server
4. Restart the NIS+ daemon
# ps -ef | grep rpc
# kill <pid>
# rpc.nisd -S 0
5. Setup the NIS+ tables
# /usr/lib/nis/nissetup wks.acs.ohio-state.edu.
6. Add data to the tables
# cat <file> | nisaddent -a <tablename>
21.3.6.3 Replica Server
A replica server binds to a domain.
1. Become a client of the parent domain
# domainname wks.acs.ohio-state.edu.
# domainname > /etc/defaultdomain
# cp /etc/nsswitch.nisplus /etc/nsswitch.conf
# nisinit -c -H <domain server hostname>
2. Start the daemon
# rpc.nisd -S 0
3. Make the directories for the databases
# nismkdir -s <replica server hostname> acs.ohio-state.edu.
where
-s hostname specify hostname to be a replica server for the existing directory,
<domain name>
4. Replicate the domain
# /usr/lib/nis/nisping acs.ohio-state.edu.
21.3.6.4 Client
A client binds to a sub-domain.
1. Setup the sub-domain
# domainname wks.acs.ohio-state.edu.

# domainname > /etc/defaultdomain
2. Choose the NIS+ version for nsswitch.conf
# cp /etc/nsswitch.nisplus /etc/nsswitch.conf
3. Initialize the client
# nisinit -c -H <domain server hostname>
NIS+
UNIX System Administration © 1998 University Technology Services, The Ohio State University 217
NIS+NIS+
21.3.7 Credential Setup
To gain authorization to change NIS+ databases you need to create your security credentials for the
NIS+ principals. These credentials are stored in the cred.org_dir table in the default NIS+ domain.
21.3.7.1 Root Master
Setting Up Credentials for the Root Master Server
1. Login as root on the root master server and create the credential for the root master at the
highest security level
# nisaddcred des
2. Create the group nisadmin and the master host to the group
# nisgrpadm -c nisadmin.acs.ohio-state.edu.
# nisgrpadm -a nisadmin.acs.ohio-state.edu. master_host_name.acs.ohio-state.edu.
3. Update the NIS+ keys
# nisupdkeys acs.ohio-state.edu.
# nisupdkeys org_dir.acs.ohio-state.edu.
# nisupdkeys groups_dir.acs.ohio-state.edu.
4. Kill and restart the rpc.nisd with the new security level enforced
# ps -ef | grep rpc.nisd
# kill rpc.nisd_pid_number
# rpc.nisd -r
5. Set the permissions and group ownerships for the directories
# nischmod g=rmcd acs.ohio-state.edu. org_dir.acs.ohio-state.edu. groups_dir.acs.ohio-
state.edu.

# nischgrp nisadmin.acs.ohio-state.edu. acs.ohio-state.edu.
6. Set the environmental variable NIS_GROUP. To do this permanently add this variable to
/.profile and /.login, e.g.
# setenv NIS_GROUP nisadmin.acs.ohio-state.edu.
21.3.7.2 Clients
Setting Up Credentials for Client Hosts
1. Login as root on the root master server and define the client host as a principal. You’ll be
prompted for the root password of the client host. You can also add the client host to the
group nisadmin.acs.ohio-state.edu.
# nisaddcred -p -P host_name.acs.ohio-state.edu. des
2. To allow the root user on the client host to update the maps, add that host to the NIS+
group, nisadmin.acs.ohio-state.edu.
# nisgrpadm -a nisadmin.acs.ohio-state.edu. host_name.acs.ohio-state.edu.
3. Login as root on the client host and enter the password for root of that host.
# keylogin -r
Password:
Network Information Services (NIS and NIS+)
218 © 1998 University Technology Services, The Ohio State University UNIX System Administration
Network Information Services (NIS and NIS+)Network Information Services (NIS and NIS+)
4. If the root user on the client host is to update the maps, then on the client host set the envi-
ronmental variable NIS_GROUP. To do this permanently add this variable to /.profile
and /.login, e.g.
# setenv NIS_GROUP nisadmin.acs.ohio-state.edu.
21.3.7.3 Users
Setting Up Credentials for Users
1. Login as root on the root master server and create the user account. This can be done with
admintool. Add a password for the user account using the nispasswd command and add
the credentials using nisaddcred.
# admintool
# nispasswd login_name

Password:
# nisaddcred -p uid# local
# nisaddcred -p unix.uid#@acs.ohio-state.edu -P login_name.acs.ohio-state.edu. des
Password:
2. To allow the user to change the NIS+ maps, the user must be added to the NIS+ group,
nisadmin.acs.ohio-state.edu.
# nisgrpadm -a nisadmin.acs.ohio-state.edu. login_name.acs.ohio-state.edu.
3. If the user is to update the maps using admintool you must create the group sysadmin with
gid=14 and then add this user as a member of the sysadmin group.
4. Set the user’s environment variable NIS_GROUP. To do this permanently add this vari-
able to ~/.profile and ~/.login, e.g.
# setenv NIS_GROUP nisadmin.acs.ohio-state.edu.
UNIX System Administration © 1998 University Technology Services, The Ohio State University 219
CHAPTER 22 Adding Clients
22.1 Clients
There are four types of SunOS clients: diskless, dataless, standalone, and AutoClient. These must all
be served by an NFS file server over the network. The diskless client has no disk. It must get root,
swap, home, and system files from the server. The dataless client has a small local disk. It may have
root and swap local, with system and home files on the server. The standalone client has all the files
necessary to run the OS but may desire additional file systems from the server, e.g. the user home
directories. The AutoClient is similar to the diskless client, except that it has a small disk for local
caching.
An AutoClient should have an entire disk, of at least 100 MB, devoted to it. It uses the Cache File
System (cachefs) to locally store /, /usr, and other cachefs mounted file systems. It can also use NFS
to mount other file systems. It allows for fast access with centralized administration because there’s
no permanent data on the client. Everything is quickly reproduced by rebooting over the network from
the server. You can install a client with the Solstice Host Manager GUI tool of SunOS 5.5+.
Under SunOS 5.3-5.4 you add clients with the Admintool Host Manager GUI tool. We look at these
admintool and solstice utilities in another chapter.
22.2 Server configuration and software

A server can be of the same (homogeneous) or different (heterogeneous) architecture from the
client(s). If different it needs to have the executables for the client architecture installed in addition
to its own, e.g if you have a sun4 server with sun3 and sun3x clients you need to have:
/export/root client root partitions /
/export/swap client swap files swap
/export/exec/sun3 Sun3 client system files /usr
/export/exec/kvm/sun{3,3x} client kernel files /usr/kvm
/export(usr)/share files shared by all systems, e.g. man /usr/share
/export/sun3/local locally compiled programs for Sun3/3x /usr/local
Under SunOS 4.1.X if your server was not installed as a heterogeneous server you can add different
architecture executables to the server by running the program /usr/etc/install/add_services along with
Adding Clients
220 © 1998 University Technology Services, The Ohio State University UNIX System Administration
Adding ClientsAdding Clients
the appropriate install tapes/CDROMs for these architectures. Add_services is a menu-based program
that sets up a system as a server for an additional architecture or to add additional software from the
release tapes/CDROMs.
22.3 Installing the client of a server, SunOS 4.1.X
On the server add the client’s ethernet address to /etc/ethers, and the IP address to /etc/hosts. Then
cd to /usr/etc/install and run add_client. e.g.
# (cd /usr/etc/install; ./add_client)
usage: add_client [[options] clients]
where ’clients’ is the name of the any number of clients to add and
[options] are one or more of the following for each client:
-a arch architecture type (e.g. sun3, sun4, etc.)
-e path path to client’s executables
-f path path to client’s share location
-h path path to client’s home directory
-i interactive mode - invoke full-screen mode
-k path path to client’s kernel executables

-m path path to client’s mail
-p print information of existing client
-r path path to client’s root
-s path path to client’s swap
-t termtype terminal to be used as console on client
-v verbose mode - reports progress while running
-y type client’s NIS type (client, or none)
-z size size of swap file (e.g. 16M, 16000K, 32768b etc.)
-n prints parameter settings and exits w/o adding client
To run the program interactively use the -i option to add_client, e.g.:
# (cd /usr/etc/install; ./add_client -i)
This will invoke a full-screen display for entering the client information similar to the display used
during Suninstall.
This program will add all the necessary information to the /etc/bootparams file, make the boot file in
/tftpboot (using the client’s hex IP address in the file name, which is a symbolic link to the boot
program for the appropriate architecture of the client), create the client’s root file system in
/export/root/client_name, create the client’s swap file as /export/swap/client_name, add entries
in /etc/exports to export the necessary file systems to the client, and add entries in the client’s
/etc/fstab file (/export/root/client_name/etc/fstab on the server) to enable the client to mount the
server’s file systems at boot. You’ll need to make sure that the appropriate entry is in /etc/ethers for
the clients ethernet address, hostname pair.
You will then need to run exportfs to correctly export the file systems to the new client. You should
then be able to boot the new client. First, though, check the server’s /etc/bootparams and /etc/exports
file to make sure that the entries are appropriate.
JumpStart
UNIX System Administration © 1998 University Technology Services, The Ohio State University 221
JumpStartJumpStart
22.4 JumpStart
To add a client that you want to boot via jumpstart follow the steps below. First copy the install
CDROM to disk. In this example that CDROM is copied to /jumpstart/solaris_2_5.

1. Go to the jumpstart directory and add the client:
cd /jumpstart/solaris_2_5
2. This updates /etc/bootparams, /etc/ethers, /etc/hosts, & /tftpboot.
./add_install_client -i ip_address -e ethernet_address -s nyssa:/jump-
start/solaris_2_5/export/exec/kvm/sparc.Solaris_2.5 hostname sun4c
3. If you're running with TCPwrapper enable the client to access in.tftpd by editing
/etc/hosts.allow.
4. If /tftpboot did not exist at boot time run "/etc/init.d/nfs.server start" to enable the server
to start /usr/sbin/rpc.bootparamd.
5. Boot the client from the network:
ok boot net - install
22.5 AutoClient
Solstice AutoClient software comes with Solaris 5.5.1 on the same CDROM as the AdminSuite
software. Both these applications should be installed. You can use either the Solstice Host Manager
tool or the /opt/SUNWadm/2.2/bin/admhostadd command to add the client. First setup the OS
Server; again, this can be done with the Solstice Host Manager tool. If you’re using NIS be sure to
setup a timezone map with entries of the form:
hostname timezone or domainname timezone
e.g.:
nis_domain US/Eastern
The admhostadd program lets you specify the same type information you would fill in the Host
Manager. Use it in the form:
admhostadd -i IP_addr [ -e ethernet_addr ]
[ -x type=host_type ] [ -x tz=timezone ] [ -x term=type ]
[ -x fileserv=file_server ] [ -x root=directory ]
[ -x swap=directory ] [ -x swapsize=size [ -x disconn=Y|N ]
[ -x install=Y|N ] [ -x installpath=server:/path ]
[ -x bootpath=server:/path ] [ -x profile=server:/path ]
[ -x os=version ] [ -x diskconf=configuration ]
[ -x ns=NIS|NIS+|NONE ] [ -x domain=domain|rhost=host ]

host
Adding Clients
222 © 1998 University Technology Services, The Ohio State University UNIX System Administration
Adding ClientsAdding Clients
As with the diskless client you need to make sure that your /etc/ethers and /etc/bootparams files (or
the NIS(+) equivalent maps) are properly setup and that the OS server properly shares the files
needed by the client.
The AutoClient can then be booted from the network similar to a diskless client, e.g.:
ok boot net
Unix System Administration © 1998 University Technology Services, The Ohio State University 223
PART III Selected Topics
Useful Utilities
Print Service
Mail
World Wide Web
Usenet
System Security
Secure Shell
224 © 1998 University Technology Services, The Ohio State University Unix System Administration
Selected Topics
UNIX System Administration © 1998 University Technology Services, The Ohio State University 225
CHAPTER 23 Usenet
23.1 Usenet
Usenet is a world-wide network of computers, most of them UNIX, that run netnews software. It’s a
public forum for the exchange of news articles, similar to bulletin boards. The articles are exchanged
between sites by mutual agreement between the System Administrators of the sites. This requires
either an ethernet or UUCP connection between the machines. Users can post, read, and reply to
articles in any of over 13000 different topics, or newsgroups on the Internet. Locally you can find
newsgroups that range from osu.general (site specific to OSU) to comp.sys.sun.admin (the Sun
administrators list) to alt.tv.simpsons.

The major Usenet headings are:
comp - computer science related groups
sci - sciences other than computer science,
news - netnews software and general interest for netnews users,
rec - discussions of recreational activities,
soc - discussions of social topics,
talk - extended discussion of special topics (e.g. talk.politics),
misc - groups other than those listed above.
also:
can - Canadian
clari - Clarinet (UPI) news feed
bit - BITNET lists
Groups within these headings are created by consensus of the Usenet users. In addition there are other
groups such as "alt" for alternate, that are created at the whim of individual users. These groups may
not be carried by all Usenet news sources. Additionally there are groups with more limited
distribution, such as cle, cmh, and oh, and local groups, such as osu, cis, and uts.
Usenet
226 © 1998 University Technology Services, The Ohio State University UNIX System Administration
UsenetUsenet
23.2 Reading news, rn/rrn/xrn/trn/nn
Reading news requires a program that can select news groups, articles within those groups, and page
through them. It should also be able to keep track of articles you’ve read and topics you want to see,
or don’t want to see.
Many popular read news programs are derived from rn:
• rn - simple unthreaded newsreading,
• trn - adds threading and other useful features to rn; can use nntp to read news on a remote
server.
• xrn - X-windows newsreader which uses nntp to query a news server.
There are also nntp newsreaders for Macs and PCs. The OSU HomeNet/ResNet/OfficeNet software
from UTS now includes these. With this software you can connect to the news server from your

desktop computer.
23.3 Network news transfer protocol, nntp
nntp is the Network News Transfer Protocol. This protocol controls the transfer of news articles
form the news server to your machine. NNTP server machines contain a full installation of
USENET news. They allow remote sites to connect and read, transfer and/or post news, as controlled
by the nntp_access file in /usr/lib/news, e.g.:
host/net read/xfer/no post/no newsgroups (!not.allowed)
nntp can operate either as a stand-alone server, or as a server under inetd. News articles are placed
in the news spool as numbered files in directories specified by the group name, e.g.
comp.sys.sun.admin would become /var/spool/news/comp/sys/sun/admin.
There are three major news servers on Campus:
magnus.acs.ohio-state.edu
zaphod.mps.ohio-state.edu
news.cis.ohio-state.edu
23.4 Disk space requirements
A full news feed requires massive amounts of disk space, currently a Gbyte or more of disk space per
day and growing rapidly. Also, since the articles are generally smaller than the default inodes/disk
space of 2 Kbytes, you may run out of inodes before you run out of disk space. You should anticipate
this when you set up the news partition and run newfs with the desired inode density.
Relevant UNIX newsgroups
UNIX System Administration © 1998 University Technology Services, The Ohio State University 227
Relevant UNIX newsgroupsRelevant UNIX newsgroups
23.5 Relevant UNIX newsgroups
23.5.1 UNIX - news
clari.nb.unix UPI stories related to UNIX
23.5.2 SunOS
comp.sys.sun.admin Sun administrators list
comp.sys.sun.apps
comp.sys.sun.announce
comp.sys.sun.hardware

comp.sys.sun.misc
comp.sys.sun.wanted
comp.unix.solaris Solaris 2 (SunOS 5.X) related concerns
osu.sys.sun Local Sun related concerns
23.5.3 HP-UX
comp.sys.hp.hpux HP-UX administrators list
comp.sys.hp.hardware
comp.sys.hp.apps
comp.sys.hp.misc
osu.sys.hp Local HP-UX related concerns
23.5.4 Ultrix
comp.unix.ultrix Ultrix administrators list
osu.sys.dec.ultrix Local Ultrix related issues
23.5.5 SGI
comp.sys.sgi.announce
comp.sys.sgi.admin SGI administrators list
comp.sys.sgi.apps
comp.sys.sgi.bugs
comp.sys.sgi.graphics
comp.sys.sgi.hardware
comp.sys.sgi.misc
osu.sys.sgi Local SGI related issues
23.5.6 Linux
osu.sys.linux Local Linux users list
comp.os.linux.admin Linux administrators list
comp.os.linux.announce
comp.os.linux.development
comp.os.linux.misc
comp.os.linux.help
Usenet

228 © 1998 University Technology Services, The Ohio State University UNIX System Administration
UsenetUsenet
23.5.7 NeXT
comp.sys.next.sysadmin NeXT users list
comp.sys.next.announce
comp.sys.next.misc
comp.sys.next.programmer
comp.sys.next.hardware
comp.sys.next.software
comp.soft-sys.nextstep
cmh.sys.next Local NeXT users list
23.5.8 AIX
comp.unix.aix IBMs AIX users list
23.5.9 Digital Unix and OSF/1
comp.unix.osf.osf1 OSF/1 related concerns
23.5.10UNIX - technical
comp.unix.admin UNIX Administration
osu.network Networking issues at OSU/OSC
osu.unix Local UNIX concerns
comp.unix.shell UNIX shell (sh, csh, tcsh, bash, etc.)
23.5.11 Security
alt.security Discussions of Security Issues
comp.security.announce Security Announcements
comp.security.misc
comp.security.unix
23.5.12 Sources
alt.sources
comp.sources.misc
comp.sources.reviewed
comp.sources.sun

comp.sources.unix
23.5.13 Perl
comp.lang.perl.moderated
comp.lang.perl.announce
comp.lang.perl.modules
comp.lang.perl.tk
comp.lang.perl.misc
UNIX System Administration © 1998 Frank Fiamingo 229
CHAPTER 24 Useful Utilities
24.1 Format online manual pages, catman
catman creates the display files used by the manual command, man. These files are put in directories
under /usr/man to match the /usr/man/man* entries, i.e. /usr/man/cat[1-8,l,n] (SunOS 4.1.X) or
/usr/man/cat[1[,b,c,f,m,s],2,3[,b,c,e,g,i,k,m,n,r,s,t,x],4,4b,5,6,7,9[,e,f,s],l,n] (SunOS 5.X) and a
database of the one-line synopses are put in /usr/man/whatis (SunOS 4.1.X) or /usr/man/windex
(SunOS 5.X) for use by the whatis and "man -k keyword" commands. Running catman doubles the
space required to contain the man pages, but allows the man command to execute considerably faster.
The man pages generally follow the conventions given in the following table.
You can install other man pages under any hierarchy, e.g. /usr/local/man or /usr/lang/man, and
make them accessible to the man command by setting the MANPATH environment variable to
include them, i.e. for the C-shell:
% setenv MANPATH /usr/local/man:/usr/man:/usr/lang/man
and for the Bourne shell:
MANPATH=/usr/local/man:/usr/man:/usr/lang/man ; export MANPATH
TABLE 24.1 Man Page Placements
SunOS 4.X SunOS 5.X Description
man1 man1 user commands - from the shell prompt
man2 man2 system calls - C functions interfacing between user programs and the kernel
man3 man3 user level library functions - C library functions for user programs
man4 man7 & man9 device drivers and network interfaces - describes access to special files in /dev
man5 man4 file formats - describes formats used by system programs

man6 man6 games and demo descriptions
man7 man5 miscellaneous - including standards and text processing
man8 man1m system administration - commands for system maintenance and operation
manl manl locally installed man pages
mann mann new man pages