UNIX: The Complete Reference (2007)

Part III: System Administration

Chapter 13: Basic System Administration

Overview

Every computer owner must be concerned with the basic tasks of system administration. Those who use non-UNIX operating systems like Windows 2000 or XP have system administration responsibilities. Whether the system is being used by one person as a home-based system, or by a group of people in an office environment, someone needs to administer the machine. In particular, that person needs to install the system software; all of the programs that will be used; and hardware devices such as printers, disk drives, and scanners. He or she will also periodically need to delete unnecessary files, defragment and optimize hard disks, and regularly back up the data.

The same is true with any UNIX operating system, whether it is on a personal computer (typically Linux, FreeBSD, or Mac OS X), a midsized server (again Linux or one of the other UNIX variants), or a large mainframe (such as Solaris, HP-UX, or AIX). The extent of administration you must do will depend on how you use your system. If you have a personal workstation or you are your system’s only user, initial administration may be as simple as connecting the computer’s hardware; installing software; and defining a few basics such as the system name, the date, and the time.

Because UNIX is a multiuser operating system, you may want to set up your system so that many people can use it. As an administrator, you will assign a login name, a password, and a working directory to each user. You will probably want to connect additional terminals or PCs so that several users can work at the same time.

You will also need to protect the information on your system. To do this, you’ll have to monitor available disk space and processing performance, protect against security breaches, and regularly back up the data. Depending on the kind of work being done on your system, you may need to add software or printers, networks, and other hardware peripherals.

This chapter will familiarize you with basic concepts and procedures that go into administering the UNIX System for these major variants: Linux, Solaris, Mac OS X, AIX, and HP-UX. It is divided into four major sections: administrative concepts, setup procedures, maintenance tasks, and security Important administrative topics that require greater depth of explanation are covered in Chapter 14. Topics needed for mail, network, and Internet administration are covered in Chapters 15 and 17. For further information on administration, see the administrative documentation that comes with your system.

Although you don’t need to be a UNIX guru to do basic system administration, you do need to be familiar with basic UNIX features and have some skill in editing and issuing commands. There is much to learn, but being a competent system administrator is a valuable role, worth the effort it takes to learn the necessary skills.

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.

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

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.

Setup Procedures

The following is a set of the most basic procedures you need to do to get your system going. Some procedures you will probably only do once, such as defining the computer’s name and creating default profiles for your users. Others you will repeat over time, such as adding new users.

You should check the documentation that comes with your system to see if additional setup procedures are required.

Installing the Console Terminal

Before you can set up your UNIX system, you must set up the computer and its console terminal

The console is where you must do your initial setup, because it is the only terminal defined when the system is first started. For small systems, the console will be the screen and keyboard that come with the computer. For large systems, there may be a completely separate terminal that may produce paper printouts.

Some administrators like to have messages from the console printed on paper in order to maintain a paper audit trail of system activities. Important messages about the system’s activities and error conditions are directed to the console. For example, a running commentary is sent to the console as the system is started up. This commentary keeps the administrator informed as hardware diagnostics are run; as the file system is checked for errors; and as processes providing system services to printers, networks, and other devices are started up. This is commonly done for many administrative tasks. Notice that standard output and standard error for one of the commands in the earlier crontab example were sent to /dev/ console. Clearly, one could direct system messages to a file, rather than to a paper terminal. However, if the system goes down, or if the file system crashes, this file will not be available.

The instructions that come with your computer will tell you how to set up the computer and console.

Installation

Procedures for installing UNIX System application software, as well as the operating system itself, are different from one system to the next. It’s not possible to give specific, detailed advice about system installation in a book of this kind. You should consult the software installation instructions that come with your computer’s operating system to see how this is done. While each variant may have its own procedures, they enable you to install your software either through a menu interface or by using command-line instructions.

Installing Software Packages

It is easy to install new software packages on your UNIX system. Although there are slight differences in how each of the UNIX variants performs this task, the basic operations are the same. For instance, Red Hat Linux developed a tool called rpm (Red Hat Package Management) that enables you to install software packages. This package has been migrated to other Linux distributions as well. HP-UX has a software distributor based on the pkgadd routine, and Solaris also uses the pkgadd routine to install software packages.

The pkgadd command transfers the software package from disk, tape, or CD-ROM to install it on the system. You can do the installation directly from the distribution medium or copy the software to a spool directory first. A command of the format

# pkgadd -d /dev/fd0 package1

will directly install package1 onto your system from a floppy disk defined as /dev/fd0. The command

# pkgadd -d /cdrom/cdrom0/s0/Solaris_10

will prompt you for the name of the package you want to install, and it will then install it into your default directory

If you wish, you can copy the software into the spool directory to install some other time. The command

# pkgadd -s /var/spool/pkg

will copy the software into the spool directory instead of installing it. When used without options, pkgadd looks in the default spool directory (typically /var/spool/pkg) and installs the package.

If you are a Linux user, a lot of software packages may be installed over the Internet by going directly to the download page on the site offering the software (such as http://www.tucows.com). If you use Red Hat, you can use the Update Agent called up2date to check for newer versions of software packages currently loaded on your machine, download them, and even install them automatically, as well as download and install new software packages.

On other Linux distributions that use the rpm manager, the yum tool allows you to update software packages that are known in the yum repository (either /etc/yum.repos.d or /etc/yum/repos.d by default) according to the configuration file /etc/yum.conf.

Most Linux distributions can use an older tool developed by the Debian Project called apt-get, which is part of the apt (Advanced Package Tool) suite of tools. apt-get is a command-line tool that allows a user to update, install, and remove software packages known to a list defined in /etc/apt/sources.list according to the configuration file /etc/apt.conf.

Distributions based on Debian Linux can also use the Synaptic Package Manager synaptic, which is a graphical implementation of apt to install, upgrade, and remove software packages using a user-friendly GUI based on Gtk+ (part of the GIMP toolkit for creating graphical user interfaces).

Installation Defaults

Most UNIX-based systems will contain an installation defaults file generally referred to as admin. admin defines default actions to be taken in installing a software package. There are no standard naming conventions for this file, but typically the default admin file is /var/ sadm/install/admin/default. If you wish to change the default installation parameters, copy the current admin file to a new filename, and edit this new file-never edit the admin file itself. Table 13–1 shows the installation parameters that can be defined. If a parameter does not have a value, pkgadd asks the installer how to proceed.

Here you see a conservative set of admin installation defaults:

basedir=default

runlevel=quit

conflict=quit

setuid=quit

action=quit

partial=quitinstance=unique

idepend=quit

rdepend=quit

space=quit

This set minimizes the effects of any package installation on the rest of the system and quits the installation if any potential problem is detected.

Powering Up

Once the computer and console are set up and the initial software is installed, you can power up the system following the instructions in your system’s documentation.

If the system comes up successfully, you should see a series of diagnostic messages, followed by the “Console Login:” prompt. After that, you should type the word root to log in as the system’s superuser. You will not have to enter a password if one was not assigned yet, but you have to press ENTER after the “Password:” prompt. For instance,

Console Login: root

Password:

You should then set a root password as soon as possible, to avoid security problems-unless you can guarantee that you will be the only user on the machine.

The Superuser

Most administration must be done as superuser, using the root login. The superuser is the most powerful user on the system. It is as superuser that you will have complete control of the system’s resources. You can start and shut down the system, open and close access to any file or directory, delete or change any part of the system, and generally change the system’s configuration.

Becoming the Superuser

You have two ways to become the superuser. You can log in to the console as root. If you are at another terminal and attempt to log in as root, you’ll be denied access. If you’re not at the console and you need to have superuser privileges, you can first log in as a regular user and then use the su command to get root privileges, as shown here:

$ /bin/su -

Password:

#

After you log in as root, you will have superuser privileges. The-(dash) on the command line tells the su command that you want to change the shell environment to the superuser’s environment. So, for example, the home directory would be set to / and the path variable would be set to include the directories where administrative commands are located. (You can return to the original user’s privileges and environment by keying CTRL-D.)

Linux administrators should understand how LILO (the Linux Loader) can be used to boot Linux from a floppy, thus giving whoever performs the boot procedure superuser (root) privileges. In order to avoid unwanted root access to your system, it’s a good idea not to leave these types of floppies around.

The root Prompt

Note that this is the shell prompt for root:

#

You will see the # prompt throughout this section instead of the $ or other user shell prompts, such as %, shown for other users in the rest of the book.

Maintaining the Superuser Login

Because the capabilities of the superuser are so great, you should exercise extreme caution when you are the superuser. It’s a good idea to adopt a few simple rules when administering your system as superuser:

§ Keep the root prompt equal to the # character. This will help you remember when you have total power over the system.

§ Restrict access to superuser capabilities to those who really need it. Don’t give the root password out to anyone who doesn’t need total control of the whole system.

§ Change the root password often. Keeping the same password for long periods of time makes the system more vulnerable.

§ Do not do any work on the system except system administration when you are logged in as root or superuser. Even if you are the only user on your system, don’t make root your usual login. A typing mistake by a normal user may have little impact; the same mistake by root could demolish the whole system.

§ Make the root environment different from your normal environment. You want to make yourself aware of when you have root privileges. Make your root environment very different from your normal user environment. Don’t use the same or similar .profile as a user and as root. Minimize the use of aliases in your root login. Make the PATH variable for root as short as practical; don’t include your user directories in your root PATH.

Besides the superuser, other special administrative logins have other, more limited uses. These users are described later in this chapter.

Setting Date/Time

You must set the current date and time on your system. To set the date and time to July 15, 2006, 11:17 P.M., do the following:

# date 1215231706

Sat Jul 15 23:17:00 EST 2006

This breaks down to July (12) 15 (15), 11:17 P.M. (2317), 2006 (06).

Whenever you want to see the current date and time, type date with no options.

Setting the Time Zone

You can set the time zone you are in by modifying the /etc/TIMEZONE file. In this file, the TZ environment variable is set as follows:

TZ=EST5EDT

export TZ

The preceding entry says that the time zone is eastern standard time (EST), this time zone is five hours from GMT (5), and the name of the time zone when and if daylight saving time is used is eastern daylight time (EDT). The system will automatically switch between standard and daylight saving time when appropriate. Note that /etc/TIMEZONE is not available in Red Hat Linux. See http://www.linuxsa.org.au/tips/time.html for details on how to set the time zone. On Solaris /etc/TIMEZONE is a symlink (symbolic link) to /etc/default/init.

Setting System Names

You need to assign a system name and a communications node name to your system. It is most important to assign names to your system if it is going to communicate with other systems.

The system name, by convention, is used to identify the type of operating system you are running (though no particular syntax is required). The communications node name, on the other hand, is used to identify your computer. For example, networking applications such as mail (see Chapter 8) and uucp use the node name when sending mail or doing file transfers. Internet applications also use the node name, referring to it as the hostname of the system.

Here is an example of how to set your computer’s system name to UNIX1 and its node name to trigger in UNIX variants other than Linux:

# setuname -s UNIX1 -n trigger

You can type uname -a to see the results of the setuname command.

In Linux, Solaris, and AIX, the equivalent command to set or display the system name is hostname:

# hostname trigger

will set the system host name from whatever it is currently to trigger. hostname without an argument will print the current system host name.

Using Administrative Logins

Administrative logins are assigned by the system before the system is delivered. However, these logins have no passwords. In order to avoid security breaches through these logins, you must define a password for each when you set up your system.

The reason for having special administrative logins is to allow limited special capabilities to some users and application programs, without giving them full root user privileges. For example, the uucp login can do administrative activities for Basic Networking Utilities. A uucp administrator could then set up files that let the system communicate with remote systems, without giving that user permission to use other confidential administrative commands or files (see the companion web site for more information on uucp).

To assign a password to the sysadm administrative login, type this:

# passwd sysadm

New Password:

Re-enter new password:

You will be asked to enter the password twice. (For security reasons, the password will not be echoed as you type it.) You should then repeat this procedure, replacing sysadm with each of the special user names listed here, and any other special user names that you may have on your system:

Another way to secure these special user logins is to set the shell for the account to /bin/false in the /etc/passwd file.

Startup and Shutdown (Changing System States)

The UNIX System has several different modes of operation called system states. These system states make it possible for you, as an administrator, to limit the activity on your system when you perform certain administrative tasks.

For example, if you are adding a communications board to your computer, you would change to system state 0 (power-down state) and the system will be powered off. Or if you want to run hardware diagnostics, you can change to system state 5 (firmware state) and the UNIX operating system will stop, but you will be able to run diagnostic programs at the firmware level. However, note that this only applies to non-Intel-based UNIX systems.

The two types of running system states are single-user states (1, s, or S) and mult-user states (2 and 3). When you bring up your system in single-user state, only the root file system (/) is accessible (mounted) and only the console terminal can access the system. When you bring up the system in multiuser state, usually all other file systems on your computer are mounted. Processes are started that allow general users to log in. (State 3, Network File System state, is a multiuser state that also starts NFS and mounts file systems across the network from other systems. See Chapters 15 and 17 for more information on NFS.)

By default, your system will go into multiuser state (2) when it is started up. In general, going to higher-numbered system states (e.g., from 1 to 2, or 2 to 3) starts processes and mounts file systems, making more services available. Going to lower-numbered system states, conversely tends to make fewer services available.

You may want your system to come up in another state or, more likely, you may need to change states to do different kinds of administration while the system is running.

To change the default system state, you must edit the /etc/inittab file and edit the initdef ault line. Here is an example of an initdefault entry that brings the system up in state 3, the Network File System (NFS) state:

is:3:initdefault:

The next time the system is started, all multiuser processes will be started, plus NFS services will be started. Coming up in NFS state (3) is appropriate if you are sharing files across a network using NFS (see Chapter 17 for details). Windows NT/2000/XP administrators use their own versions of NFS in setting up shared folders and shared devices for Windows users.

You can also use single-user state(s) if, for example, you want to check the system after it is booted and before other users can access it. Most often, however, computer systems are set to come up in multiuser state (2).

When your system is up and running, you may decide you want to change the current state. If, for example, you are in single-user mode and want to change to multiuser mode, type the following:

# init 2

All level 2 multiuser processes will be started, and users will be able to log in.

Startup Directories

UNIX uses daemon information (see Chapter 11) in some key directories to help in the startup process. The directories are init.d and the rcX.d directories (where X is a number that equates to a state level, described later). These directories are stored in the /etc/rc.d directory on Linux distributions, the /sbin directory on HP-UX, and in the /etc directory on Solaris.

The init.d directory contains daemons that will always be started up on initialization (system start). These scripts set up accounting, start cron, manage system resources, and set up environments not handled by entries in the /etc/inittab file.

The rcX.d directories contain specific scripts that are run depending on the run level at which the system is initialized. For example, if the run level at initialization is set to 3 (multiuser mode), scripts in the /etc/rc3.d directory will be executed at initialization. These scripts can either start or kill processes, or perform a combination of both. The numbering scheme tells the system in what order to perform the scripts in the directory For example, the contents of an /etc/rc2.d directory may look something like this:

ls /etc/rc2.d

K20spc

K76 snmpdx

S74syslog

S74xntpd

The scripts beginning with the letter K are kill scripts and are processed before any S, or startup, scripts. In addition, the scripts are processed in numerical order within a type. Therefore, the scripts listed in the example will be processed in the order in which they appear.

By convention, most of the K series scripts are in the directory /etc/rc1.d, with fewer in /etc/rc2.d. The directory /etc/rc2.d contains a combination of K and S scripts. The directory /etc/rc3.d usually contains just S scripts.

System State Summary

Here is a list of the numbers representing possible system states and their meanings:

The shutdown Command

You can shut down your machine using the init command; however, it is more common to use the shutdown command. shutdown can be used not only to power down the computer, but also to go to a lower state. The benefit of using shutdown is that it lets you assign a grace period so that your users will have some warning before the shutdown actually begins. UNIX administrators should be careful to always power down using shutdown. Just as Windows users know that you can’t just turn off the power, UNIX administrators should understand that files, devices, and even processes can be left in damaged or even unrepairable states if the machine is just turned off.

For example, you can leave multiuser state (2) and go to single-user state (S) if you want to have the system running but want all other users off the system. Or you could go down from state 2 to firmware state (5) if you want to run hardware diagnostics.

The following example of the Solaris 10 shutdown command,

# shutdown -g 60 -I 6 "System is powering down for maintenance. Please log off."

tells the system to shut down after waiting for a grace period of one minute (-g 60), and to stop the UNIX system and reboot immediately to the level defined by initdefault in the inittab file (-i 6). It also sends a message to the users telling the reason for the shutdown.

Other UNIX variants have similar command syntaxes. For example, Linux allows the use of a variable for the time to shutdown of “now,” meaning start the shutdown immediately. Check the built-in Help feature or the man page for your system to see which options are correct for your variant.

Managing User Logins

UNIX is a multiuser system, and access to the system and permissions within the system is restricted to people who have been assigned logins and passwords. The system administrator has the responsibility of maintaining the user logins. This includes defining the default user environment, adding users, aging passwords, changing passwords, and removing user logins. You must be the superuser to perform any of these functions.

Display Default User Environment

Before you add users to your system, you should display default user addition information. These defaults will show you information that will be used automatically when you add a user to your system (unless you specifically override it). For example,

# useradd -D

group=other, 1 basedir=/home skel=/etc/skel

shell=/bin/sh inactive=0 expire=0

In the preceding example, typing the command useradd -D shows you that the next time you add a user, it will be assigned to the group other, with a group ID of 1; its home directory will be placed under the /home directory; useful user files and directories (such as a user’s .profile file and rje directory) will be picked up from the /etc/skel directory and be put into the user’s home directory; and the shell used when the user logs in will be /bin/sh (/bin/bash for Linux users). No value is set for the number of days a login must be inactive before being turned on, and the login will not expire on a specific date. Note that users are added in AIX by using the SMIT interface (see the example earlier in this chapter).

Changing Default User Environment

You can change the default user environment values by typing useradd -D along with any of the following options: -g (group), -b (base directory), -f (inactive), or -e (expire). For example,

# useradd -D -g test -b /usr2/home -f 100 -e 10/15/06

After you run this command, by default, any user you add will be assigned to the group test. The user will have a home directory of its login name under the /usr2/home directory, the account will be deactivated if the user does not log in for 100 days, and if still active, the login will expire on October 15, 2006.

Here are just two of the reasons you may want to change useradd defaults:

§ The file system containing /home is getting full, so you may want to add future users’ home directories to another file system.

§ You may decide that, to maintain security, all logins will expire, either after a certain number of days of inactivity or on a particular date.

Default profile Files

After a user logs in and as part of starting up the user’s shell, two profile files are executed. The first is the system profile /etc/profile, which is run by every user, and the second is the .profile in the user’s home directory, which is only run by the user who owns it.

The intent of these two files is to set up the environment each user will need to use the system. As an administrator, you are only responsible for delivering profiles that will provide the user with a workable environment the first time the user logs in. The user should then tailor the .profile file to the user’s own needs (see the description of .profile in Chapter 4).

Before a logged-in user gets a shell prompt to start working, robust profiles will usually display messages about the system (message of the day). They will also set up a $PATH so that the user can access basic UNIX System programs, tell the user if there is mail, make sure the user’s terminal type is defined, and set the user’s shell prompt.

You can edit the /etc/profile and the /etc/skel/.profile files to add some of the items shown in the examples that follow or to add other items that make the user’s environment more useful.

The .profile in the /etc/skel directory is copied to a user’s home directory when the user is first added. By setting up a skeleton .profile, you can avoid the problem many first-time UNIX System users have of scrambling for a usable .profile. Once your users have working profiles, you should instruct them to exercise caution in editing their own .profile files to avoid corrupting their own environment by mistake. Some administrators go to the extent of setting up separate files that contain common environment variables (see Chapter 4) to avoid this.

Example/etc/profile

Here is a typical /etc/profile (note that the # on a line is followed by a comment describing the entry):

PATH=/bin:/usr/bin

LOGNAME='logname' # Set LOGNAME to the user's name

if [ "$LOGNAME" = root ]

then

PATH=/sbin:/usr/sbin:/usr/bin:/etc # Set root path

PATH=$PATH:/letc:/usr/lbin

else

PATH=$PATH::/usr/lbin:/usr/add-on/local/bin # Path for others

trap ""1 2 3

news -s # Report how many news items are unread by user

trap ""1 2 3

fi

trap "" 1 2 3

export LOGNAME # Make user's logname available to user's shell

. /etc/TIMEZONE # Make local time zone available to user's shell

export PATH # Make the PATH available to user's shell

trap "" 1 2 3 # Let user to break out of Message-Of-The-Day

cat -s /etc/motd

trap "" 1 2 3

if mail -e # Check if there's mail in the user's mailbox

then

echo "you have mail" # If so, print "you have mail"

fi

umask 022 # Define default permissions assigned to files

# the user creates

Note that Red Hat Linux uses /etc/localtime to store the time. See the web page at http://www.linuxsa.org.au/tips/time.html for more details on setting and viewing the time zone.

Example .profile

Here is a typical user’s .profile:

stty echoe echo icanon ixon

stty erase '^h' # Set backspace character to erase

PS1="'uuname -l':$ " # Set shell prompt to "system name:$: "

HOME=/home/$LOGNAME # Define the HOME variable

PATH=$PATH:$HOME/bin:/bin:/usr/bin:/usr/localbin # Set PATH

TERM=vt100 # Set the terminal definition

MAIL=/var/mail/$LOGNAME # Set variables for user's mailbox

MAILPATH=/var/mail/$LOGNAME

echo "terminal? \c" # Ask user for the terminal being used

read TERM # set TERM to terminal name entered

export PS1 HOME PATH TERM # Export variables to the shell.

# Prompt user to see news

echo "\nDo you want to read the current news items [y]?\c"

read ans

case $ans in

[Nn] [Oo]) ; ;

[Yy] [Ee] [Ss]) news | /usr/bin/pg -s -e;;

*) news | /usr/bin/pg -s -e;;

esac

unset ans

umask 022 # Set the user's umask value

Adding a User

There are a few ways to add users to your UNIX system. One is to use the menu interface for your system and follow the prompts. This method requires a minimum knowledge of all of the defaults in setting up a user-the user’s group ID, home directory default mailbox, etc. The other way to add a user is to use a command-line interface. Many system administrators prefer this method over the menu interface, as it affords you more control. We will discuss the command-line utilities here.

Most UNIX variants use the useradd command to identify a new user to the system and allow the new user to access the system. This command protects you from having to edit the /etc/passwd and /etc/shadow files manually It also simplifies the process of adding a user by using the useradd defaults described earlier. The following is an example of how to add a user with the user name of abc:

# useradd -m abc

This will define the new user abc using information from the default user environment described previously. The -m option will create a home directory for the user in /home/abc (you may have to change ownership of the directory from root by using chown).

useradd Options

To set different information for the user, you could use any of the following options instead of the default information:

User Passwords

A new login is locked until a password is added for it. You add initial passwords for every regular user just as you do for administrative users:

# passwd username

You will then be asked to type an initial password. You should use this password the first time you log in, and then change it to one known only to you (for security reasons). Chapter 2 covers some of the requirements placed on valid passwords in UNIX and provides some suggestions for how to select a password and what to avoid when creating one.

As an administrator, you assign users their initial passwords. If you can’t ask what password a user wants, it’s best to assign a temporary password and force the user to change it. One way to do this is to assign a password (e.g., the user’s initials followed by the user’s ID number), and to activate the login at the end of the day with password aging set to force an immediate password change. Thus, the first time the new user logs in, the system asks for a new password. A command sequence to do this would look like this:

# useradd -m abc

# passwd abc

Enter password for login:

New Password:

# passwd -f abc

The useradd command adds the user’s login and home directory the first passwd command sets the user’s password to whatever is assigned by the system administrator, and the second passwd -f forces the user to change passwords at the next login by forcing the expiration of the password for abc.

Lost Passwords

Passwords are not recorded by the UNIX system. The password entries in /etc/passwd or in /etc/shadow do not contain the user’s password. Nor is there any easy way to determine a password if it is forgotten or lost. You will, from time to time, receive calls from users who have forgotten their password. If you are sure that the caller is, in fact, the owner of the login, you have two ways to restore his or her privileges. One way is to use the command sequence

# passwd abc

Enter password for login:

New Password:

# passwd -f abc

which will allow you to enter a new password for the user abc and require that it be changed the first time abc logs in. An alternative is to use the sequence

# passwd -d abc

This deletes the password entry for abc. The next time abc logs in, he or she will not be prompted for a password. If the /etc/default/login file contains the field “PASSREQ=YES”, then a password is required for all users. The use of the -d option will remove the password for the user, but that user will be required to specify a password on the next login attempt. The first approach is slightly more secure, since only a user who knows the assigned password can log in; with the second approach, anyone who calls is allowed to log in and specify a new password.

If root deletes a password for a user with the passwd -d command and password aging is in effect for that user, the user will not be allowed to add a new password until the NULL password has been in use for the minimum number of days specified by aging. This is true even if PASSREQ in /etc/login/default is set to YES. This results in a user without a password. It is recommended that the -f option be used whenever the -d (delete) option is used. This will force a user to change the password at the next login.

Aging User Passwords

Passwords are an important key to UNIX user security. As mentioned in Chapter 2, UNIX enforces several rules regarding password format and length. You, as system administrator, can also force users to regularly change their passwords by implementing password aging.

You use the passwd command to specify the minimum and the maximum number of days a password can be in effect. Aging prevents a user from using the same password for long periods, and it prevents the user, when forced to change, from changing back, by enforcing a minimum duration. For example,

# passwd -x30 -n7 minnie

will require minnie to change her password every 30 days, and to keep the password for at least one week.

In establishing password aging, variables in /etc/default/passwd set the defaults for aging. The passwd command can be used to change these defaults on a per-user basis:

§ MAXWEEKS = number, where number is the maximum number of weeks that a password can be in effect

§ MINWEEKS = number, where number defines the minimum number of weeks a password has to be in effect before it can be changed

§ WARNWEEKS = number, where number is the number of weeks before the password expires that the user will be warned

Blocking User Access

You can block a user from having access to your system in a number of ways. You can use this command to lock a login so that the user is denied access:

# passwd -1 abc

If user abc is to gain access to her account and its files, the superuser will have to run passwd again for this login.

You can limit or block a user’s access by changing the user’s shell. For example, the command

# usermod -s /usr/bin/rsh abc

will modify the user’s login definition on the system and change abc’s shell to the restricted shell, which limits the user’s access to certain commands and files. If you set the default shell to some other command, such as this, for example,

# usermod -s /bin/true abc

then abc will be logged off immediately after every login attempt. UNIX will go through the login process, exec /bin/true in place of the shell, and when true immediately completes, log out the user.

Hard Delete of a User

If you no longer want a user and his files to be on your system, you can use the userdel command:

# userdel -r abc

The preceding example will remove the user abc from the system and delete abc’s home directory (-r). Once you remove a user, any other files owned by that user that are still on the system will still be owned by that user’s user ID number. If you did an ls -1 on such files, the user ID would be listed in place of the user’s name.

Soft Delete of a User

The userdel command eliminates a user from the /etc/passwd and /etc/shadow files and deletes the user’s home directory You may not want to be so abrupt. Often users share files in a project, and other users may need to be able to recover material in abc’s directory The following procedure is useful to block any further access to the system by a user while allowing others to access shared files:

# passwd -l abc

Find any other users who are in the same group as abc, and send them mail informing them that abc’s login is being closed:

# grep abc /etc/group

abc::568:abc, lsb, oca, gxl

# mailx lsb oca gxl

Subject: abc login

Cc:

I will be deleting the home directory of abc.

If you have need for any of those files please let me know.

Fondly, your SysAdmin

Make the user’s home directory permissions 000 so that the directory is inaccessible to everyone but root as read-only root can still access the directory to change back the permissions (see Chapter 3 for more details on setting octal permission modes). To do this, type

# chmod 000 /home/abc

Arrange an at command to delete the user’s home directory in one month, by typing:

# at now + 1 month 2>/dev/console <<%%

rm -r /home/abc

%%

Adding a Group

Creating groups can be useful in cases where you want a number of users to have permissions to a particular set of files or directories.

For example, you may want to assign users who are writing manuals to a group called docs and give them permission to a directory containing documents, or assign users who are testing software programs to a group called test that has access to some special testing programs. See Chapter 3 for a description of how to set group access permissions. Windows NT administrators are also familiar with the concept of groups and group permissions for programs and files, since the NT environment borrowed this useful capability from UNIX.

To add a group called test to your system, type the following:

# groupadd test

The command will add the name “test” to the /etc/group file, and the system will assign a group ID number.

Once a group is created, you can assign users to that group. To assign a new user to an existing group, use useradd. For example,

# useradd -g project -G test bcd

will add the new user, bcd, to the system with project as the primary (default) group, and test as the secondary group.

For existing users, you use the usermod command. For example,

#usermod -g project -G test abc

will do the same for existing user abc.

Deleting a Group

If you find you no longer need a group you previously added, you can delete it this way:

# groupdel test

The command will delete the name “test” from the /etc/group file. Note that if you want to change a group name, you can use the groupmod command:

# groupmod -n TryNot test

This will change the group’s name from test to TryNot.

Setting Up Terminals and Printers

You need to identify to the UNIX System the terminals, printers, or other hardware peripherals connected to your computer.

Ports

Each physical hardware port (the place where you connect the cable from the hardware to your computer) is usually represented by a file under the /dev directory It is through this file, called a device special fileor simply a device, that the hardware is accessible from the operating system. Usually these devices are created for you automatically when you install a hardware board and its associated software.

Configuration

Once hardware is connected, you usually need to configure it into the operating system. The procedure for configuring hardware can involve a complex series of steps that could include editing configuration files manually, starting and stopping port monitors, and adding and enabling the specific services provided by the hardware.

It is strongly recommended that you configure peripheral hardware through your system’s menu interfaces unless you are very familiar with the environments under which these devices operate. The following examples show a basic terminal and printer setup.

Adding a Terminal

After you have connected a terminal to a particular port on your computer (see your computer’s documentation for details on ports and cables), you must tell the system to listen for login requests from that port. Traditionally, this has been done by adding an entry to the /etc/inittab file, like this:

ct:234:respawn:/usr/lib/saf/ttymon -g -m Idterm -d /dev/contty -1 contty

The preceding entry is identified by the two-letter entry name ct. This entry says, in system states 2, 3, or 4, start up the command /usr/lib/saf/ttymon as a stand-alone process for the “contty” port (/dev/contty).Then push the “Idterm” module onto the device (to add some additional services) and get the definitions needed for the terminal port from an entry named “contty” in the /etc/ttydefs file. respawn means that if the process dies, and you are still in states 2, 3, or 4, the process will be restarted.

The entry in the /etc/ttydefs file for “contty” that is used in the preceding entry looks like

contty:9600 hupcl opost onlcr erase ^h:9600 sane ixany tab3 erase ^h::contty

and says that for the entry “contty,” the initial and final flags for the terminal are set to the following values:

§ Initial flags 9600 hupcl opost onlcr erase ^h

§ Final flags 9600 sane ixany tab3 erase ^h

The meanings of the flags are as follows:

You could add a separate entry to the /etc/inittab file for each port on your computer that is connected to a terminal. This would cause a separate process to be run for each terminal on the system. However, the recommended way to start up processes to monitor ports is to use the Service Access Facility (see Chapter 14). This facility enables you to have a single process monitor several ports at once, and it also gives you greater flexibility in providing other services for ports.

Adding a Printer to Your System

Printing documents is an important part of any UNIX system. System V-based systems use the lp command set, while Berkeley-based systems use the lpr command set. Since the command structures are the same, we will describe the lp command set here.

When the Line Printer (lp) Utilities are installed, a shell script is usually set up to start the lp scheduler when your system enters a multiuser state. When you add a printer, you need to stop the lp scheduler, identify the printer, restart the scheduler, say that the printer is ready to accept jobs, and enable the printer.

In the following example, a simple dot-matrix printer will be added and connected to port 11 (/dev/term/11) to get it running. Note that this is a simple example. The lp utilities are powerful tools that let you configure a variety of printers, change printer attributes, and connect printers to networks and remote computers. Once you have connected the printer to the port on your computer, you should make sure the port has the correct permissions, user ownership (lp), and group ownership (bin) for printing. Use the following:

# chown lp /dev/term/11

# chgrp bin /dev/term/11

# chmod 600 /dev/term/11

# ls -1 /dev/term/11

crw-------1 lp bin 1, 0 Oct 27 13:39 /dev/term/11

To shut down the lp scheduler, type this:

# /usr/sbin/lpshut

Print services stopped.

To identify the printer to the lp system, type this:

# lpadmin -p duke -i /usr/lib/lp/model/standard -l/dev/term/11

This will set the printer’s name to duke, use the /usr/lib/lp/model/standard file for the definition of the interface to the printer, and identify port 11 (/dev/term/11) as the port it is connected to. Restart the lpscheduler by typing this:

# /usr/lib/lpsched

Print services started.

Allow the printer to accept lp requests by typing this:

# accept duke

Destination "duke" now accepting requests.

Then enable the printer by typing this:

# enable duke

Printer "duke" now enabled.

The printer should now be available for printing. You can check it by printing a text file as follows:

# lp -dduke testfile

This command will direct the contents of file testfile to the printer (duke).

Using CUPS to Administer Printers

Since so many UNIX variants exist today, it is difficult to develop printer drivers to support all of the different UNIX printing systems. For this reason, CUPS (Common UNIX Printing System) was developed by a company called Easy Software Products. It provides a common printing system interface, based on the Internet Printing Protocol (IPP). CUPS defines how to manage jobs and set printer options, but also adds some security features for printing over the Internet. Once CUPS is installed on your system, it provides a complete printer management environment that includes the lp and lpr subsystems and all of their commands.

CUPS is available under the GNU Public License for Linux, Mac OS, and other UNIX variants. More information about CUPS can be found at www.cups.org.

Maintenance Tasks

Once your system is set up, it is important that you stay in touch with your computer and its users. The remainder of this chapter describes how you can help ensure the good working condition of your system. This includes means for checking on the system and suggestions about what you can do if you find something wrong.

Several subjects pertaining to ongoing maintenance are not in this chapter but are important for keeping your system working. See Chapter 14 for discussions of these and other administrative topics not covered here.

Communicating with Users

If more than one or two people are using your system, you will probably want to use some of the tools the UNIX System provides to communicate with users. The talk command, the wall command, the newscommand, and the /etc/motd file are of particular interest.

The talk Command

If you want to chat with someone on your machine or another machine, you can use the talk command to do so. This facility is the forerunner of the chat capability used by many Internet users, and is similar to IM (instant messaging) capabilities. For example, the user jennifer on machine sis1 can set up an interactive talk session with the user sharlene on machine sis2 by issuing the command

talk sharlene@sis2

This will send a message to the screen for user sharlene with text similar to this:

Message from TalkDaemon@sis1 at 10:03 a.m.

talk: connection requested by jennifer

talk: respond talk jennifer@sis1

Sharlene would then reply

talk jennifer@sis1

to complete the connection. Each user can then type text that will be displayed on the other user’s screen. The conversation is ended when one of the participants enters an interrupt (or EOF character). At this point the other participant will receive a message that the conversation has been terminated.

If you don’t want to be disturbed during a work session, you can prevent other users from attempting to contact you by using the mesg command. Entering

mesg -n

at your command prompt will set your terminal to reject messages from other users. Entering

mesg -y

will reset your terminal to allow subsequent messages from other users.

The wall Command

If you want to immediately send a message to every user that is currently logged in, you can use the wall command. This is most often used when you need to bring down the system in an emergency while other users are logged in. Here is an example of how to use the wall command:

# wall

I need to bring the system down in about 5 minutes.

Log off now or risk having your work interrupted.

I expect to have it running again in about two hours.

CTRL-D

The message will be directed to every active terminal on the system. It will show up right in the middle of the user’s work, but it will not cause any damage. Note that you must end the wall message by typing a CTRL-D.

/usr/news Messages

Longer messages can be written in a file and placed in the /usr/news directory Any user can read the news and, if the permissions to /usr/news directory are open, write their own news messages. To read the news, type the following:

$ news

notice (root) Wed Jul 12 11:30:15 2006

We just purchased another printer to

attach to trigger. If you have any

suggestions about where it should be

located, please send mail to trigger!root.

You will see all news messages that have been added since the last time you read your news. The name of the file is the message name, the user is shown in parenthesis, and the date/time the message was created is also listed.

Message of the Day (/etc/motd)

The message-of-the-day file (/etc/motd) is used to communicate short messages to users on a more regular basis. You can simply add information to the /etc/motd file using a text editor. The information will then be displayed automatically when the user logs in. The description of the /etc/profile file shows how the motd file is read.

Following is an example of the kind of information you might want to put in your computer’s /etc/motd file:

10/10: Trigger down at 1:00 pm today for 1 hour to add cards.

Checking the System

If you are doing administration for a system that is already set up, you will want to familiarize yourself with the system. For instance, you will want to know the system’s name, its current run state, the users who have logins to the system, and who are logged in. You might also be interested in what processes are currently running, the file systems that are available for storing data, and how much space is currently available in each file system.

The following commands will help you find out how the system is configured and what activities are occurring on the system.

Display System Name (uname)

You can use the uname -a command to display all system name information. Other options to uname let you display or change parts of this information. Here’s an example of uname with the -a option:

# uname -a

SunOS attlis 10 sun4u sparc SUNW, Ultra-Enterprise

“SunOS" identifies the operating system name, “attlis” is the computer’s communication node name, “10" is the operating system release (Solaris 10), and “sun4u…" is the machine hardware name (here a Sun Enterprise5000).

You will need to know the node name if you want to tell other users and systems how to identify your system. The operating system version is important to know if a software package you want to run is dependent on a particular operating system version.

If you just want to know the operating system name, you can use uname with the -s option. Similar to the previous example,

# uname -s

SunOS

indicates that the machine’s operating system name is SunOS.

Display Current System State (who)

You can use the who command to see whether your system is in single-user state or one of the multiuser states. To display the current system state of your computer, type this:

# who -r

· run-level 2 Oct 16 16:16 2 0 S

You see that the run level is 2 (multiuser state). Other information includes the process termination status, process ID, and process exit status.

Display User Names

To see the names of those who have logins on your system, along with their user IDs, group names/IDs, and other information, type this:

# logins

root 0 other 1 0000-Admin(0000)

sysadm 0 other 1 0000-Admin(0000)

daemon 1 other 1 0000-Admin(0000)

bin 2 bin 2 0000-Admin(0000)

sys 3 sys 3 0000-Admin(0000)

uucp 5 uucp 5 0000-uucp(0000)

lp 7 tty 7nuucp 10

10 0000-uucp(0000)

oamsys 101 other 1 Object Architecture Files

mib 102 docs 77 Ida Beecher

gwagner 210 docs 77 Greg Wagner

gkw 212 docs 77 Karen Williams

oasys 215 other 1 Object Architecture Files

Some reasons you might want to do this are that you forgot Ida Beecher’s user name; you want to add gwagner’s login to another system and you want to use the same UID number he has on this system; or you need to see which users are in the docs group because you want to add the whole group to another machine.

Display Who Is on the System

To get a list of who is currently logged into the system, the ports where they are logged in, the times/dates they logged in, how long a user has been inactive (“.” if currently active), and the process ID that relates to each user’s shell, type this:

# who -u

root console Oct 18 13:06 . 3158

mcn term/12 Oct 18 20:06 . 8224

You may want to do this to check who is on the system before you shut it down. Or you may want to check for terminals that have been inactive for a long time, since long inactivity may mean that users left for the day without turning off their terminals.

Display System Definition

Most UNIX systems have some sort of utility that will display basic system definition information. This might include such information as the device used to access swap space (/dev/swap), the UNIX System boot program (/boot/KERNEL), the boards that are in each slot in the computer, and the system’s tunable parameters.

Among the most important items of system information are tunable parameters. Tunable parameters help set various tables for the UNIX System kernel and devices and put limits on resources usage. For example, the MAXUP parameter limits the number of processes a user (other than superuser) can have active simultaneously in the kernel.

Usually the default tunable settings are acceptable. However, if you are having performance problems or are running applications that place heavy demands on the system, such as networking applications, you should explore your system’s tunables. Check the documentation that comes with your system for a description of its tunables.

The sysdef utility is used on some UNIX variants to display system definition information. Here is an example of some of the contents:

# sysdef

* Hostid

806d5cid

* Devices

/dev/swap 17,1 0 30192 28804

. (long list of devices may follow)

.

* Tunable Parameters

*

100 buffers in buffer cache (NBUF)

60 entries in callout table (NCALL)

25 processes per user id (MAXUP)

.

.

.

Other variants have similar utilities to list devices and drivers. For example, in AIX you use the lsdev -C command, in HP-UX you use the sbin/ioscan command, and in Red Hat Linux you use the cat/proc/devices command.

Display Mounted File Systems

File systems are specific areas of storage media (such as hard disks) where information is stored. When a file system is mounted, it becomes accessible from a particular point in the UNIX System directory structure. See Chapters 3 and 14 for a description of file systems.

To display the file systems that are mounted on your system, use the mount command, like this:

# mount

/ on /dev/root read/write/setuid on Thu Jul 27 15:06:40 2006/proc on /proc

read/write on Thu Jul 27 15:06:41 2006

/stand on /dev/dsk/c1d0s3 read/write on Thu Jul 27 15:06:44 2006

/var on /dev/dsk/c1d1s8 read/write on Thu Jul 27 15:07:11 2006

/usr on /dev/dsk/c1d0s2 read/write on Thu Jul 27 16:47:44 2006

/home2 on /dev/dsk/c1d0sa read/write on Thu Jul 27 16:47:48 2006

/home on /dev/dsk/c1d1s9 read/write on Thu Jul 27 16:47:52 2006

The information that is returned tells you the point in the directory structure on which the file system is mounted, the device through which it is accessible, whether the file system is read-only or readable and writable, and the date on which it was last mounted. This listing will also include any file systems that are mounted from another system across the network (remote).

After you have changed system states, you can check the mounted file systems to make sure they were successfully mounted and unmounted as appropriate.

Display Disk Space

Occasionally you will want to check how much disk space is available on each file system on your system to make sure that there is enough space to serve your users’ needs. To see the amount of disk space available in each file system on your system, use the df command as follows:

# df -k

/ (/dev/root ): 12150 blocks 2339 files

total: 25146 blocks 3136 files

/proc (/proc ): 0 blocks 185 files

total: 0 blocks 202 files

/stand (/dev/dsk/c1d0s3): 1095 blocks 45 files

total: 5148 blocks 51 files

/var (/dev/dsk/c1d1s8): 37128 blocks 2145 files

total: 40192 blocks 2496 files

/usr (/dev/dsk/c1d0s2): 29982 blocks 7330 files

total: 86308 blocks 10784 files

/home2 (/dev/dsk/c1d0sa): 1972 blocks 93 files

total: 2000 blocks 96 files

/home (/dev/dsk/c1d1s9): 59420 blocks 3988 files

total: 108504 blocks 6752 files

For each file system, you will see the mount point, related device, total number of blocks of memory, and files used. Listed underneath the blocks and files used are the total number of each available in the file system.

Even if you check nothing else, check this information occasionally If you begin to run out of either blocks of memory or the number of files you can create in that file system, consider following one of these courses:

§ You can distribute files to different file systems that have more room. In particular, you may want to relocate software add-on packages or one or more users to a file system with more space.

§ You can delete files you no longer need. Do a cleanup of administrative log files and spool files (see the description of the du command coming up). Also encourage your users to do the same.

You can copy files that do not need to be immediately accessible onto tape or floppy storage. You can always restore them later if you need to.

Display Disk Usage

If you are running out of disk space, you can use the du command to see how much space is being used by each directory. The following example shows the amount of disk space used by each directory under the directory /var/spool:

# du /var/spool

4 /var/spool/pkg

4 /var/spool/locks

52 /var/spool/uucp/trigger

88 /var/spool/uucp

4 /var/spool/uucppublic

8 /var/spool/lp/admins

4 /var/spool/lp/fifos

4 /var/spool/lp/requests

4 /var/spool/lp/system

4 /var/spool/lp/tmp

36 /var/spool/lp

140 /var/spool

Note that each directory shows the amount of space used in it and each directory below it.

Some files and directories will grow over time. In particular, you should keep an eye on log files. These are files that keep records of different types of activities on the system, such as file transfers and system resource usage. You can set up your system to delete these files at given times (see the description of cron earlier in this chapter).

Here is a list of some of the files and directories that you should monitor:

§ /var/spool/uucp This directory contains files that are waiting to be sent by the Basic Networking Utilities. Files that cannot be sent because of bad addressing or network problems can accumulate here.

§ /var/spool/uucppublic This directory contains files that are received by Basic Networking Utilities. If these files are not retrieved by the users they are intended for, the directory may begin to fill up.

§ /var/adm/sulog This file contains a history of commands run by the superuser. It will grow if it is not truncated or deleted occasionally

§ /var/cron/log This file contains a history of jobs that are kicked off by the cron facilities. Like sulog, it should be truncated or deleted occasionally

System Activity Reporting (sar)

You can gather a wide variety of system activity information from your UNIX system using the sar command and related tools. The sar command can show you performance activity of the central processor or of a particular hardware device. Activity can be monitored for different time periods.

Here are a few examples of the reports you can generate using the sar command with various options:

# sar -d

SunOS attlis 10 sun4ru 07/21/06

13:46:28 device %busy avque r+w/s blks/s avwait avserv

13:46:58 sd01 6 1.6 3 5 13.8 23.7

sd04 93 2.1 2 4 467.8 444.0

13:47:28 sd04 13 1.3 4 8 10.8 32.3

sd05 100 3.1 2 5 857.4 404.1

13:47:58 sd04 17 .7 2 41 .6 48.1

sd09 100 4.4 2 6 1451.9 406.5

Average sd04 12 1.2 3 18 8.4 34.7

sd09 100 3.2 2 5 925.7 418.2

The information given by the preceding command shows disk activity for various hard disk devices. At given times, it shows the percentage of time each disk was busy, the average number of requests that are outstanding, the number of read and write transfers to the device per second, the number of blocks transferred per second, and the average time (in milliseconds) that transfer requests wait in the queue and take to be completed. The command

# sar -u

SunOS attlis 10 sun4ru 07/21/06

10:02:07 %usr %sys %wio %idle

10:02 :27 82 18 0 0

10:02 :47 39 35 16 10

10:03 :07 7 28 16 50

10:03 :27 1 16 0 83

Average 32 24 8 36

shows the central processor unit utilization. It shows the percentage of time the CPU is in user mode (%usr), system mode (%sys), waiting for input/output completion (%wio), and idle (%idle) for a given time period. It is possible to run sar as a cron job to take snapshots of your system throughout the day You can store this information in a file to be viewed by the superuser. If you wish to get an accurate picture of system performance, this is a good way to do it.

Check Processes Currently Running (ps -ef)

You can use the ps command with the -ef options to see all the processes currently running on the system. You may want to do this if performance is very slow and you suspect either a runaway process or that particular users are using more than their share of the processor.

Following is an example of some of the processes you would typically see on a running system:

# ps -ef

UID PID PPID C STIME TTY TIME COMD

root 1 0 0 Oct 29 ? 14:47 /sbin/init

root 213 1 0 Oct 29 ? 0:40 /usr/lib/saf/sac -t 300

root 3107 1 0 Nov 01 ? 0:04 /usr/lib/lp/lpsched

root 103 1 0 Oct 29 ? 0:03 /usr/slan/lib/admdaemon

root 113 1 0 Oct 29 ? 3:03 /usr/sbin/cron

root 216 1 0 Oct 29 ? 0:04 /usr/lib/saf/ttymon -g

-m Idterm -d /dev/contty -1 contty

root 3157 1 0 Nov 01 console 0:03 /usr/lib/saf/ttymon

-g -p Console Login: -m Idterm -d /dev/console -1 console

root 217 1 0 Oct 29 ? 0:01 /usr/sbin/hdelogger

root 221 213 0 Oct 29 ? 0:21 /usr/lib/saf/ttymon

root 222 213 0 Oct 29 ? 0:19 /usr/lib/saf/ttymon

mcn 4431 221 4 02:43:20 term/11 0:03 -sh

mcn 4436 4431 32 02:43:57 term/11 11:54 testprog

If the system is very slow, you may want to check for runaway processes on your system. If you see a process that is consuming a great deal of CPU time, you may want to consider killing that process (see Chapter 11).

To kill the runaway process called testprog in the preceding example, you first need to know that you kill process ids (PIDs), not process names. Since the PID for testprog is 4436, typing

kill -9 4436

will terminate the process unconditionally

The Sticky Bit

An innovative feature of UNIX in the early days of small machines was the concept of the sticky bit in file permissions. As originally implemented, if an executable file had the sticky bit set, the operating system would not delete the program text from memory when the last user process terminated. The program text would be available in memory when the next user of the file executed it. Consequently, the program did not need to be loaded, and execution was much faster. This was a useful feature, improving performance, in the days of small machines and expensive memory Today, however, with fast disk drives and cheap memory, using the sticky bit to keep a program in memory is obsolete, and most UNIX systems simply ignore it.

One feature of the sticky bit is important for system administration. Setting the sticky bit has important effects when it is set on a directory Using the sticky bit on directories provides some added security Some directories on the UNIX System must allow general read, write, and search permission, for example, tmp and spool A danger with this arrangement is that others could delete a user’s files. In most current UNIX versions, the sticky bit can be set for directories to prevent others from removing a user’s files. If the sticky bit is set on a directory, files in that directory can only be removed if one or more of the following conditions is true:

§ The user owns the file.

§ The user owns the directory

§ The user has write permission for the file.

§ The user is the superuser.

In order to set the sticky bit, you use the chmod command, like this:

# chmod 1753 progfile

or

# chmod +t progfile

In order to change the access permissions of a file, you must either own the file or be the superuser. To see if the sticky bit is set, use the ls -l command to check permissions. If you set the sticky bit of a file, a twill appear in the execute portion of the others permissions field, like this:

$ ls -l vi

-rwxr-xr-t 5 bin bin 213824 Jul 1 2006 vi

Security Tips for System Administrators

You can do many things as an administrator to help secure your system against unauthorized access and the damage that can result. In addition to securing your local machine, there are a number of methods to “armor” your system against network attacks. We discuss the network security issues and methods of guarding against intruders in greater depth in Chapter 12 and Chapter 17.

What follows is a list of security tips for administrators for local machines.

Use Only Authorized Commands Make sure the authorized versions of commands that allow system access are used. These commands include

If someone is able to replace these commands with his own versions, change their ownership permissions, or move his own versions of these commands ahead of the real ones in a user’s $PATH, that person may be able to secure other people’s passwords or complete information about how to access remote systems.

Protect Your Superusers Passwords, particularly root passwords, should not be given over the phone, written down, or told to users who do not need to know them. Change privileged passwords frequently, and use different passwords for different machines, to limit the amount of access if a password is discovered. Close off permissions to superuser login directories so that nobody can write to their bin or change their .profile. Limit the number of setuid programs (those that give one user the permissions of another) to those that are necessary Don’t make setuid programs world-readable. Remove unnecessary setuid programs from the system. The following command will mail a list of all setuid root files to sysadmin.

# /usr/bin/find / -user root -perm -4000 -print

/usr/ucb/mail -s "setuid root files" sysadmin

If you need to perform superuser tasks while logged in as a normal user, use the sudo command to allow you to temporarily perform the superuser task you need to. This will return you to normal user privileges upon completion of the task, and avoid involuntarily leaving a user with root privileges. Specific users can also be granted access to specific limited root-level commands used for system administration functions (which are logged for security purposes) using sudo.

Provide Accountability Set up your system in a way that will provide accountability Each user should have his or her own login and user ID so that the user is solely responsible for the use of that login. If you do want to provide a special-purpose login that many people can use for a specific task, such as reading company news, you should not allow that login to access the UNIX system shell. Use commands like useradd and passwd or the menu interface provided with your system to add users and change passwords. This will ensure that the /etc/passwd and /etc/shadow are kept in sync.

Protect Administrative Files Administrative files should be carefully protected. If log files such as sulog, which tracks superuser activity, are modified, someone could attempt to break in as superuser could be hidden. If files in the crontab directory, especially those owned by root, sys, and other administrative logins, are modified, someone could start up processes with the owner’s privileges at given times. If startup files, such as inittab and rc.Xd, are modified, commands could start up when your system changes states that would allow unauthorized access to your system.

A secure system requires that you set it up in a secure way and then continually monitor the system to be sure that no one has compromised that security Some of the techniques you can use are discussed in the following sections.

Use Password Aging Use password aging to make your users change their passwords at set intervals. Here is an example of how to set password aging:

# passwd -x 40 -n 5 abc

In this example, the maximum amount of time that user abc can go without changing her password is 40 days. The next time abc logs in after 40 days, she will be told to enter a new password. After the password is changed, it cannot be changed again for at least five days (this will prevent a user from immediately changing back to the old password).

Limit setuid Programs Check for setuid and setgid programs. These are programs that give a user, or group, the access permissions of another user or group. These files should be limited to only those that are necessary, and they should never be writable. Here are some examples of standard setuid programs that reside in /bin:

# ls -1 /bin

-r-sr-xr-x 1 root bin 36488 Oct 11 20:20 /bin/at

-r-sr-xr-x 1 root bin 17300 Oct 11 20:21 /bin/crontab

---s-x-x 1 uucp uucp 66780 Oct 11 07:58 /bin/cu

-r-sr-xr-x 1 root root 38472 Oct 11 11:34 /bin/su

In each case, the command provides that user’s privileges to any user who runs the command. Make sure the commands are not writable and that they are owned by administrative logins.

Use Full Pathnames When accessing commands that ask you for password information, use full pathnames, such as /bin/su. Use these commands only on trusted terminals, preferably only from the console.

Analyze Log Files You should analyze log files for attempts to misuse your system. Here are two important log files:

Summary

This chapter should have given you a sense of what goes into administration for a UNIX system. Once you have your system installed, the material in this chapter will provide a good idea of what you need to do to add and delete users, and generally administer the system. Basic commands and important concepts are touched on. However, some subjects that are not considered essential for starting up and getting to know your system are not described here, but rather in the next chapter. Also, most of the commands in this chapter have many other options than those described here. If you are interested in understanding how to perform administration using a menu interface, familiarize yourself with your menu interface and its icons before attempting to perform system administration. Learn, if possible, what the underlying activities are that take place when a menu icon is used instead of the command-line interface. You may someday encounter a machine on which you have to use command-line interfaces.

The next chapter covers new topics, such as managing disk storage, and expands on previously discussed topics, such as using the UNIX file system. Once you feel comfortable with this chapter and the next, it is recommended that you obtain a System Administrator’s Guide for your particular version of UNIX. This will explain each administrative command and file format in greater detail.

How to Find Out More

Many good books are available on System Administration. Here are a number for beginners (and for some more experienced system administrators as well):

· Bauer, Kirk. Automating UNIX and Linux Administration. Berkeley, CA: Apress, 2003.

· Calkins, Bill. Solaris 10 System Administration Exam Prep 2. Indianapolis, IN: Que, 2005.

· Feiler, Jesse. Mac OS X: The Complete Reference. Berkeley CA: McGraw-Hill/Osborne, 2001.

· Frisch, Æleen. Essential System Administration. 3rd ed. Sebastopol, CA: O’Reilly & Associates, Inc., 2002.

· Maxwell, Steven. UNIX System Administration: A Beginner’s Guide. Berkeley, CA: McGraw-Hill/Osborne, 2002.

· Michael, Randal K. AIX 5L Administration. Berkeley, CA: McGraw-Hill/Osborne, 2002.

· Negus, Christopher, and Thomas Weeks. Linux Troubleshooting Bible. Indianapolis, IN: John Wiley & Sons, 2004.

· Nemeth, Evi, Garth Snyder, Scott Seebass, and Trent Hein. UNIX System Administration Handbook. 3rd ed. Englewood Cliffs, NJ: Prentice Hall, 2000.

· Petersen, Richard. Red Hat Enterprise Linux and Fedora 4: The Complete Reference. 3rd ed. Berkeley, CA: McGraw-Hill/Osborne, 2005.

· Poniatowski, Marty. HP-UX 10.X System Administration. Englewood Cliffs, NJ: Prentice Hall, 1995.

· Poniatowski, Marty. HP-UX 11i System Administration. Englewood Cliffs, NJ: Prentice Hall, 2003.

· Winsor, Janice. Solaris System Administrator’s Guide. Mountain View, CA: Sun Microsystem Press, 1998.

Web Sites with Useful Information on System Administration

Numerous web sites offer valuable system administration information for each of the variants discussed in this chapter. Here are just a few for each of the variants discussed throughout this book.

Linux has an online Linux System Administrator’s Guide 0.9, by Lars Wirzenius. It is one of the better guides and includes many tips and tricks. You can get it at http://www.tldp.org/LDP/sag/html/index.html There is a good online entry on Linux Administration Made Easy (LAME), part of the Linux Documentation Project, at http://www.tldp.org/LDP/lame/LAME/linux-admin-made-easy/.

Sun Microsystems has a site with System Administration info and FAQs about the Solaris 10 environment at http://www.sun.com/bigadmin/products/sol10.html.

HP has a site with useful information about administration of HP-UX 11.0 systems at http://docs.hp.com/en/oshpux11.0.html. HP also has a similar site for HP-UX 10.0 systems at http://docs.hp.eom/en/oshpux10.x.html. There is a site for registration for HP-UX 11 administration courses at http://www.mindiq.com/ilt/hpux/hp200.php.

For AIX users, there is a discussion of unique issues regarding AIX system administration at http://www.unet.univie.ac.at/aix/aixbman/admnconc/sys_mgmt.htm. There is also course registration information for AIX system administration at http://www.mindiq.com/ilt/aix/ap200.php.

Mac OS users can find a short description of basic system administration functions at http://campus.umr.edu/cis/desktop/documentation/mac/osx/basic_system_administration.pdf as well as some system administration tech-tips and recipes at http://www.tech-recipes.com/mac_system_administration.html.

Newsgroups to Consult for Information on System Administration

You can gain a lot of insight into the issues of system administration simply by following the discussion in the USENET newsgroup comp.unix.admin. You will probably also want to read the newsgroup(s) devoted to the specific machine or version of UNIX you are using. The following newsgroups address questions dealing with administration and general use for particular operating systems. Usually, if you lack relevant or useful documentation, you will get useful information back when you post questions to the appropriate newsgroups. Some useful newsgroups are

· comp.os.linux.admin

· comp.sys.sun.admin

· comp.sys.hp.hpux

· comp.unix.aix

· comp.unix.solaris

· comp.mac.sys.*

· comp.unix.questions

Journals and Publications on System Administration

There are a number of journals and publications on system administration for UNIX variants.

For Linux, here are a few good journals:

· http://www.linuxjournal.com/-Linux Journal (also available in print at newsstands)

· http://www.linuxmagazine.com/-Linux Magazine (also available in print at newsstands)

· http://www.linuxtoday.com/-Linux Today

· http://www.linuxplanet.com/linuxplanet/- Linux Planet

· http://linuxgazette.net-Linux Gazette

· http://www.linuxfocus.org/-Linux Focus

For Solaris:

· http://www.adminschoice.com/-Admin’s Choice (technical tips, articles, discussions)

For HP-UX:

· http://www.hpl.hp.com/hpjournal/journal.html-The HP Journal online

For AIX:

· http://www.eservercomputing.com/ME2/Default.asp-eServer Magazine (covers AIX)

For Mac OS:

· http://www.mactech.com/index.html-Mac Tech: The Journal of Macintosh Technology

· http://www.macworld.com/-Mac World: The Mac Product Experts

· http://www.macaddict.com/-Mac Addict (A better machine, a better magazine)

For all of the variants above:

· http://www.samag.com/-Sys Admin: The Journal for UNIX/Linux Administrators