Administrative Concepts


If you are administering a newer version of Windows, such as Windows NT/2000 or XP, you have a good feel for the complexity of managing multiple users and simultaneous tasks. You will also understand why Microsoft saw advantages to emulating the UNIX environment; namely the capability to share common resources across multiple users. Though you could run UNIX as a single-user operating system, ordinarily you will configure it to support many users running many processes at the same time.

This section describes the concepts of administration for multiple users and multiple processes. It also compares the different types of administrative interfaces (commands and menus) and provides a short description of the directory structure as it relates to administration.

Multiuser Concepts

If you are supporting other users on your machine, you will have to consider their needs as well as your own. You will need to assign them logins and passwords, so that they can access the system, and to add terminals (or PCs), so that they can all work at the same time.

You will probably want to schedule machine maintenance and shutdowns for off-hours, so that you will not have to kick users off the system during the times they need it most. Also, you will want to use the tools provided with UNIX to alert your users about system changes, such as some newly installed software or the addition of a printer. You will also need to service their requests, for example, to restore files to the system from copies stored on tape archives.

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.

image from book
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.

image from book
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.

image from book
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.

image from book
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.

image from book
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:

Minutes

Use 00 through 59 to specify the minute of each hour the command is run.

Hours

Use 0 through 23 to specify the hours of each day the command is run.

Days/Month

Use 1 through 31 to specify the day of each month the command is run.

Months

Use 1 through 12 to specify the month of each year the command is run.

Days/Week

Use 0 through 6 to specify the days of each week the command is run (Sunday is 0).

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.)

Directory Structure

To most users, the UNIX System directory structure appears as a series of connected directories containing files. To administrators, this series of directories is, itself, a set of file systems. The concept of root as the highest level of the directory structure for all UNIX directories and devices is discussed in detail in Chapter 3. This is a different concept for most PC users, who are used to associating files relative to their current drive (e.g., the C drive).

Each file system is assigned a part of the space (called a partition) from a storage medium (usually a hard disk) on your computer. The file system can then be connected to a place in the directory structure. This action is called mounting, and the place is called the mount point. See Chapter 14 for detailed information on mounting file systems. The standard UNIX System file systems are mounted automatically, either in single-user or multiuser state. (See the description of system states later in this chapter.)

Once a file system is mounted, all files and directories below that mount point will consume space on the file system’s partition of the storage medium. (Of course, if another file system is mounted below the first mount point, its files and directories would be stored on its own partition.)

Important administrative files are distributed among the different file systems. The philosophy behind the distribution has changed drastically in newer versions of UNIX and Linux.

Previously, the UNIX System directory tree was oriented toward the root (/) file system, containing files needed for single-user operation, and the user file system (/usr), containing files for multi-user operation. Interspersed among them were files that were specific to the system and those that could easily be shared among a number of systems.

Most variants of UNIX categorize files into directories containing

  • Machine private files   These are files that support the particular system on which they reside. These include boot files (to build the system’s kernel, set tunable parameter limits, and configure hardware drivers) and accounting logs (to account for the users and processes that consume the system’s resources). These files are in the root file system (i.e., they are available when the machine is brought up in single-user state).

  • Machine-specific sharable files   These include executable files and shared libraries that were compiled to run on the same type of system. So, for example, you could share these types of files across a network among several systems of the same type. These kinds of files are typically contained in the /usr file system.

  • Machine-independent sharable files   These include files that can be shared across the network, regardless of the type of system you are using. For example, the terminfo database files, which contain compiled terminal definitions, are considered sharable. The /usr/share directory typically contains these types of files.

With this arrangement, whole directories of common files can be shared across a network, yet only files that pertain to a specific system would have to be kept on that system. As a result, computers with small hard disks or no hard disks would be able to run the UNIX System, because few files would have to be kept locally

Chapter 14 offers a description of the UNIX file system and files typically associated with typical directory structures. Chapter 3 includes descriptions of each of the major tree structures.




UNIX. The Complete Reference
UNIX: The Complete Reference, Second Edition (Complete Reference Series)
ISBN: 0072263369
EAN: 2147483647
Year: 2006
Pages: 316

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net