Multitasking Concepts

The fact that UNIX is multitasking means that many processes can be competing for the same resources at the same time. A lot of busy users can quickly gobble up your file system space and drain available processor time. As an administrator, you can control the priorities that different users and processes have for using your computer’s central processor.

Administrative Interfaces

Most computers that run UNIX offer two methods for administering a system: a menu interface called a desktop, and a set of commands.

Desktop menus typically provide an easier way to administer your system because they tend to be both visually oriented and task-oriented . Desktop menus lead you through a task, present you with options for all required information, check for mistakes as you go along, and tell you whether or not the task completed successfully To complete the same task without menus often means running several commands. The feedback you receive from these commands and the error checking that is done is usually not as complete as it is with menus.

Choosing Desktop Interfaces or Commands

When you are starting UNIX System administration, you should begin by using the desktop interface that comes with your system. Using desktop menus will reduce your margin for error and help teach you about the system. You also need not worry about dozens of commands and options.

The examples of administration in this chapter are done with commands, even though an equivalent may exist in the desktop menu interface. There are three reasons for doing this:

• Desktop menu interfaces are often very different from one operating system to the next . Therefore, showing one type of menu interface may not help you much if your operating system does not have that interface.

• Commands and options tend to be similar from one UNIX system to the next. You could use the commands shown in this chapter on almost any computer running UNIX. If a command shown here is not available on your system, chances are the concepts presented with the command will still be useful to you. For example, if your system does not have the useradd command (or adduser , for Linux) described later, it will still help to understand the concepts of user names , user IDs, home directories, and profiles when you add a user.

• Desktop Menu interfaces do not let you see what is actually happening, and over time you may lose the understanding of how particular processes work.

Linux System Administration Menu Interfaces

Most Linux distributions have built-in system administration tools. Red Hat, for example, uses a tool called GnoRPM , which replaced glint , to perform file management and software package management. This tool is available under the GNOME desktop (see Chapter 6). GNOME is the most widely used desktop environment under Linux and has a number of menu options that allow you to perform system administration functions.

Linuxconf is a tool that is available on most Linux distributions to provide a wide variety of configuration services. YaST is the setup and configuration tool used in SUSE Linux to install software, configure hardware, setup networks, servers, and much more.

Almost all Linux distributions have system administration tools for both client machines as well as servers. As an example, Red Hat Linux uses the Red Hat Console to perform most system administration on servers. Figure 13–1 shows the Red Hat Console. Red Hat Console is a GUI-based front end for Red Hat Administration Server that allows you to manage servers as well as users. Within the Red Hat Console there is a service called the Certificate System (CS) that allows you to configure servers as well as perform other tasks.

Figure 13–1: The Red Hat Console

The Solaris System Administration Menu Interface

Prior to Solaris 9, system administrators used admintool as its system administration menu interface. Even though it was rich in features, it was rarely used by more experienced system administrators. Most simple tasks, such as file management and manipulation, can be done using CDE (see Chapter 7), or the latest Solaris tool, called the System Management Console (SMC). This tool works extremely well in installations with multiple systems but may be too advanced for small or single-system installations. The SMC allows the system administrator to perform a wide range of tasks, including user administration, configuring the system, providing accounting, executing jobs, monitoring processes, and network management. Figure 13–2 shows the Solaris System Management Console.

Figure 13–2: SMC main screen

For other more complex tasks, and for most single-system environments , most Solaris system administrators prefer to use command-line interfaces so that they have better control over the various processes that are executed in completing the task.

The HP-UX System Administration Menu Interface (SAM)

The administrative menu interface for HP-UX is called SAM (System Administration Manager). The look of this menu interface is very similar to the Mac OS X menu interface. You can perform most user, file, network, and software administration using this interface. Figure 13–3 shows the SAM main menu.

Figure 13–3: The HP System Administration Manager (SAM)

The Mac OS X System Administration Menu Interface

Apple has a rich tradition of integrating applications with a strong graphical user interface (GUI). Mac OS X Tiger uses the Aqua Desktop environment, as shown in Fig. 13–4, to perform a wide range of user and system administration functions. Administrators that have used previous versions of the Macintosh-or even Windows 2000-environment find the icons familiar, with increased functionality. While there are some system administration functions that can be performed in other menus under Mac OS X, the System Preferences menu provides the most familiar tools, such as user administration, hardware and network administration, system configuration, and desktop management.

Figure 13–4: The Mac OS X Aqua desktop interface

The AIX System Administration Interface

The AIX system administration interface is called the System Management Interface Tool (SMIT). SMIT provides a menu-driven interface similar to older-style UNIX graphical menus run under the X Window System. AIX menus are organized into specific task areas, such as software installation, system configuration, and device management. The menu screen provides the initial classes of tasks from which to select. Figure 13–5 shows a sample menu screen. Selector screens further refine what the task will perform on, such as a printer or an object. The dialog screen is the interface between the selected task and the actual command line or shell that performs the task.

Figure 13–5: AIX sample menu screen for user administration

System administrators may add applications to run customized system management routines via the Applications menu screen.

Commands

Although menus are better for beginning administrators, traditionally Linux/UNIX System administration has been done by running individual commands. The commands can have a wide variety of options, making them powerful and flexible.

Standard UNIX System administrative commands are contained in the following directories: /sbin, /usr/sbin, /usr/bin, and /etc. You should make sure that those directories are in your path. To check, print your path :

# echo $PATH /sbin:/usr/sbin:/usr/bin:/etc

As you add applications, you may want to add other directories to your path. You could also add your own directory of administrative commands that you create yourself.

Running Administrative Commands

Because individual commands can be run without the restrictions of a menu interface, you can take advantage of shell features:

• You can group together several commands into a shell script. For example, you could create a shell script that checks how much disk space is being used by each user’s home directory (see the du command) and automatically send a mail message to each user that is consuming more than a certain number of blocks of space (see Chapter 14).

• You can queue up commands to run at a given time. For example, if you wanted to run regularly the disk space usage shell script described in the previous paragraph, you could set up a cron job, described in the next section.

As you become more experienced with administration, you will probably use more commands. For simple procedures, it is usually faster to type a single command than to go through a set of menus.

Scheduling Commands with cron

The cron facility lets you execute jobs at particular dates and times. Windows 2000 and XP administrators use a similar concept, called the Windows Task Scheduler. Usually, a job consists of one or more commands that can be run without operator assistance. Each job can be set up to run regularly, or on one particular occasion.

Although cron may be available to all users on the system, it is particularly useful to administrators who want to run regular maintenance tasks automatically

Here are some of the things you may want to do with cron:

• Set up backup procedures to run on a regular schedule during hours when the system is not busy (see Chapter 14).

• Set up system activity reports to collect data about system activity during specific hours, days, weeks, or months of the year.

• Set up commands to check the age and size of system logs and delete or truncate them if they are too old or too large.

• Set up a command to output reports to a printer later in the day when you know the printer will not be busy

How to Set Up cron Jobs

You have four potential ways to set up cron jobs. The first is to create a file of the commands in the crontab format and install it so that the job can run again and again at defined intervals (crontab command). The second is to use the run- parts routine that is available on most Linux distributions and is an enhancement to crontab. The third is to run the job once at a particular time in the future ( at command). The fourth is to run the job immediately (batch command). See Chapter 11 for more on these last two commands.

crontab Command   Users who are allowed to use the cron facility-for example, those whose lognames are listed in /etc/cron.d/cron.allow (or /etc/cron.allow in Linux)-can create their own crontab files and install them in their $HOME directory When the system is delivered, a root crontab file should already exist. To add jobs to the root crontab file, type

# crontab -e

This will open the root file in /var/spool/cron/crontabs ( /usr/spool/cron/crontabs for Linux) using ed, or whatever editor is defined in your $EDITOR variable.

Each line in a crontab file contains six fields that are separated by spaces or tabs. The first five fields are integers that identify when the command is run, and the sixth is the command itself. Possible values for the first five fields, in order, are as follows :

Multiple entries in a field should be separated by commas. An asterisk represents all legal values. A dash ( − ) between two numbers means an inclusive range.

Here are examples of three typical crontab file entries; follow the six-field format to create your own crontab entries:

00 17 * * 1, 2, 3, 4, 5 /usr/sbin/ckbupscd >/dev/console 2>1 0, 30 * * * * /usr/lib/uucp/uudemon.poll > /dev/null 10,25,40,55 * * * * /etc/rfs/rmnttry >/dev/null #rfs

The first entry says to run /usr/sbin/ckbupscd (to check for scheduled backups ) at 5:00 P.M., Monday through Friday, every week, in every month, in every year. It also says to direct output and error conditions to the console terminal (/dev/console). The second example runs uudemon.poll at one minute and 30 minutes after the hour on every hour of every day of every month. Output is directed to /dev/null. The third example runs rmnttry every 15 minutes, starting at 10 minutes after the hour, on every hour of every day of every month.

run-parts Command   Linux system administrators can create directory structures to avoid creating and editing large crontab files that run procedures at different times, by using the run-parts routine. If your distribution does not have this package preloaded, you must first download it from one of the sponsoring sites, such as packages.debian.org/stable/source/ debianutils. Once you have downloaded it into your current directory, you should note the version number (x.xx) and run the following script with the version number replaced:

$mv run-parts-x.xx /tmp $cd /tmp/runparts-x.xx $sudo ./install.sh

This script first moves the run-parts routine into the /tmp directory It then changes the current directory to where you just moved the file. It finally installs the routine, by temporarily becoming superuser (you will be prompted for the superuser password at the end of this script for security reasons). This routine takes advantage of specific directories that are in/etc/cron that run jobs at the same time intervals (called the etc/cron.* directories).

You now can add any cron scripts into /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly, or /etc/cron.yearly directories, based on when you want to run the script. (Note: These directories are owned by root .)