System Administration in UNIX:Device Management and Services and After-Word.
Device Management and Services
Technically the system administrator is responsible for every device, for all of its usage and operation. In particular, the administrator looks after its installation, upgrade, configuration, scheduling, and allocating quotas to service the user community. We shall, however, restrict ourselves to the following three services:
1. Terminal-based services, discussed in Section 19.5.1
2. Printer services, discussed in Section 19.5.2
3. Disc space and file services, discussed in Section 19.5.3. We shall begin with the terminal settings and related issues.
The Terminal Settings
In the context of terminal settings the following three things are important:
1. Unix recognizes terminals as special files.
2. Terminals operate on serial lines. Unix has a way to deal with files that are essentially using serial communication lines.
3. The terminals have a variety of settings available. This is so even while the protocols of communication for all of them are similar.
From the point of terminal services provisioning and system configuration, system administration must bear the above three factors in mind. Unix maintains all terminal related information in tty files in /etc/dev directory. These files are special files which adhere to the protocols of communication with serial lines. This includes those terminals that use modems for communication. Some systems may have a special file for console like /etc/dev/console which can be monitored for messages as explained in the chapter on X-Windows. Depending upon the terminal type a serial line control protocol is used which can interrogate or activate appropriate pins on the hardware interface plug.
The following brief session shows how a terminal may be identified on a host:
login: bhatt Password:
Last login: Tue Nov 5 00:25:21 from 203.197.175.174 [bhatt@iiitbsun bhatt]$hostname
iiitbsun
[bhatt@iiitbsun bhatt]$tty
/dev/pts/1 [bhatt@iiitbsun bhatt]$
termcap and terminfo files: The termcap and terminfo files in the directory /etc or in
/usr/share/lib/terminfo provide the terminal database, information and programs for use in the Unix environment. The database includes programs that may have been compiled to elicit services from a specific terminal which may be installed. The programs that control the usage of a specific terminal are identified in the environment variable TERM as shown in the example below:
[bhatt@localhost DFT02]$ echo $TERM xterm
[bhatt@localhost DFT02]$
Table 19.5: Options under stty.
There are specific commands like tic, short for terminal information compilation. Also, there are programs that convert termcap to terminfo whenever required. For detailed discussions on terminal characteristics and how to exploit various features the reader may refer to [2]. We shall, however, elaborate on two specific commands here.
These are the tset and stty commands.
1. tset Command: The tset command is used to initialize a terminal. Usually, the command sets up initial settings for characters like erase, kill, etc. Below we show how under C-Shell one may use the tset command:
$setenv TERM `tset - Q -m ":?vt100"
Sometimes one may prepare a temporary file and source it.
2. stty command: We briefly encountered the stty command in Section 19.2. Here we shall elaborate on stty command in the context of options and the values which may be availed by using the stty command. In Table 19.5 we list a few of the options with their corresponding values.
There are many other options. In Table 19.5 we have a sample of those that are available. Try the command stty -a to see the options for your terminal. Below is shown the setting on my terminal:
[bhatt@localhost DFT02]$ stty -a
speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc ixany imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke
[bhatt@localhost DFT02]$
Lastly, we discuss how to attach a new terminal. Basically we need to connect a terminal and then we set-up the entries in termcap and/or in terminfo and configuration files. Sometimes one may have to look at the /etc/inittab or /etc/ttydefs as well. It helps to reboot the system on some occasions to ensure proper initialization following a set-up attempt.
Printer Services
Users obtain print services through a printer daemon. The system arranges to offer print services by spooling print jobs in a spooling directory. It also has a mechanism to service the print requests from the spooling directory. In addition, system administrators need to be familiar with commands which help in monitoring the printer usage. We shall begin with a description of the printcap file.
The printcap file: Unix systems have their print services offered using a spooling system. The spooling system recognizes print devices that are identified in /etc/printcap file. The printcap file serves not only as a database, but also as a configuration file. Below we see the printcap file on my machine:
# /etc/printcap
#
# DO NOT EDIT! MANUAL CHANGES WILL BE LOST!
# This file is autogenerated by printconf-backend during lpd init.
#
# Hand edited changes can be put in /etc/printcap.local, and will be included. iiitb:\
:sh:\
:ml=0:\
:mx=0:\
:sd=/var/spool/lpd/iiitb:\
:lp=|/usr/share/printconf/jetdirectprint:\
:lpd_bounce=true:\
:if=/usr/share/ printconf/mf_wrap per:
The printcap file is a read-only file except that it can be edited by superuser ROOT.
The entries in printcap files can be explained using Table 19.6. With the file description and the table we can see that the spooling directory for our printer, with printer name iiitb is at /var/spool. Also note we have no limit on file size which can be printed.
Table 19.6: The printcap file: printer characteristics.
Printer spooling directory: As we explained earlier, print requests get spooled first. Subsequently, the printer daemon lpd honours the print request to print. To achieve this, one may employ a two layered design. Viewing it bottom up, at the bottom layer maintain a separate spooling directory for each of the printers. So, when we attach a new printer, we must create a new spooling directory for it. At the top level, we have a spooling process which receives each print request and finally spools it for printer(s). Note that the owner of the spool process is a group daemon.
Printer monitoring commands: The printer commands help to monitor both the health of the services as also the work in progress. In table 19.7 we elaborate on the commands and their interpretations.
Table 19.7: The printer commands.
To add a printer one may use a lpadmin tool. Some of the system administration practices are best learned by assisting experienced system administrators rarely can be taught through a textbook.
Disk space allocation and management
In this section we shall discuss how does a system administrator manage the disk space. We will also like the reader to refer to Section 2.7.1 where we stated that at the time of formatting, partitions of the disk get defined. The partitions may be physical or logical. In case of a physical partition we have the file system resident within one disk drive. In case of logical partition, the file system may extend over several drives. In either of these cases the following issues are at stake:
1. Disk file system: In Chapter 2 we indicated that system files are resident in the root file system. Similarly, the user information is maintained in home file system created by the administrator. Usually, a physical disk drive may have one or more file systems resident on it. As an example, consider the mapping shown in Figure
The names of file systems are shown in bold letters. Figure 19.1: Mapping file systems on physical drives.
other file systems. Note that the disk drive with the root file system co-locates the var file system on the same drive. Also, the file system home extends over two drives. This is possible by appropriate assignment of the disk partitions to various file systems. Of course, system programmers follow some method in both partitioning and allocating the partitions. Recall that each file system maintains some data about each of the files within it.
System administrators have to reallocate the file systems when new disks become available, or when some disk suffers damage to sectors or tracks which may no longer be available.
2. Mounting and unmounting: The file systems keep the files in a directory structure which is essentially a tree. So a new file system can be created by specifying the point of mount in the directory tree. A typical mount instruction has the following format.
mount a-block-special-file point-of-mount
Corresponding to a mount instruction, there is also an instruction to unmount. In Unix it is umount with the same format as mount.
In Unix every time we have a new disk added, it is mounted at a suitable point of mount in the directory tree. In that case the mount instruction is used exactly as explained. Of course, a disk is assumed to be formatted.
3. Disk quota: Disk quota can be allocated by reconfiguring the file system usually located at /etc/fstab. To extend the allocation quota in a file system we first have to modify the corresponding entry in the /etc/fstab file. The system administration can set hard or soft limits of user quota. If a hard limit has been set, then the user simply cannot exceed the allocated space. However, if a soft limit is set, then the user is cautioned when he approaches the soft limit. Usually, it is expected that the user will resort to purging files no longer in use. Else he may seek additional disk space. Some systems have quota set at the group level. It may also be possible to set quota for individual users. Both these situations require executing an edit quota instruction with user name or group name as the argument. The format of edquota instruction is shown below.
edquota user-name
4. Integrity of file systems: Due to the dynamics of temporary allocations and moving files around, the integrity of a file system may get compromised. The following are some of the ways the integrity is lost:
• Lost files. This may happen because a user ahs opened the same file from multiple windows and edited them.
• A block may be marked free but may be in use.
• A block may be marked in use but may be free.
• The link counts may not be correct.
• The data in the file system table and actual files may be different.
The integrity of the file system is checked out by using a fsck instruction. The argument to the command is the file system which we need to check as shown below.
fsck file-system-to-be-checked
On rebooting the system these checks are mandatory and routinely performed. Consequently, the consistency of the file system is immediately restored on rebooting.
5. Access control: As explained earlier in this chapter, when an account is opened, a user is allocated a group. The group determines the access. It is also possible to offer an initial set-up that will allow access to special (licensed) software like matlab suite of software.
6. Periodic back-up: Every good administrator follows a regular back-up procedure so that in case of a severe breakdown, at least a stable previous state can be achieved.
After-Word
In this moduler we have listed many tasks which system administrators are required to perform. However, as we remarked earlier, the best lessons in system administration are learned under the tutelage of a very experienced system administrator. There is no substitute to the “hands-on" learning.
Comments
Post a Comment