|
|
Chapter 4
Basic Configuration and Administration
Certification Objectives
4.01 Adding, Deleting, and Modifying User Accounts
4.02 The Basic User Environment
4.03 File System Configuration
4.04 Using the Red Hat Package Manager
4.05 Basic Networking
4.06 chkconfig and ntsysv
4.07 Virtual Consoles
4.08 kbdconfig, timeconfig, mouseconfig
4.09 Mounting Floppy Disks and Removable Media
4.10 Sound Cards and the sndconfig Utility
linuxconf 2
Deleting a User Account with linuxconf 20
Home Directories and /etc/skel 42
Window Manager Configuration File Locations. 50
File System Types. 55
Validating a Package Signature. 86
To Add and Remove Components. 94
NOTE: Be very careful about which packages you remove from your system. Like most Linux utilities, RPM assumes omniscience, and will silently let you shoot yourself in the foot. Removing the passwd or kernel package would be devastating. 113
Adding Updates, Security Fixes, and Other Items. 114
Verifying One or More Packages. 127
Seeing What Packages Are Installed. 139
Creating and Using Custom RPMs. 157
Building Custom Source and Binary RPMs. 175
Building an RPM from a Tar Archive. 181
The /etc/sysconfig/ Files Used in Network Setup. 221
/etc/sysconfig Files for Clock, Mouse, Static-routes, Keyboard, and PCMCIA.. 224
Setting Up a Network Interface. 227
The Boot Process. 290
The chkconfig Utility. 305
The ntsysv Utility. 311
Between X Display and Virtual Consoles. 323
kbdconfig. 329
timeconfig. 334
mouseconfig. 338
After installation is complete on your Red Hat Linux system, you still have some work to do to make the system functional. User accounts need to be set up, file systems configured, and some packages may need to be added or removed.
This chapter will get you started with the basics that every Red Hat Linux administrator should know about their system. At the end of this chapter, you should know how to manage user accounts and environments, configure and mount file systems, use RPM to manage packages, configure PCMCIA, manage system daemons, and configure virtual consoles, keyboards, and mice.
CERTIFICATION OBJECTIVE 4.01
Adding, Deleting, and Modifying User Accounts
After installation, your system has only a single login account along with the root account. For some installations, you'll want to create more accounts. Even if you're going to be the only user on the system, it's a good idea to create a single, nonprivileged account to do your day-to-day work, and use the root account only for administering the system. Accounts can be added to Red Hat Linux systems using various utilities like vi (manual method), useradd (command line oriented) and the linuxconf utility (text or graphical interface).
linuxconf
linuxconf can be run in graphical or character mode. If you have already configured X, and are running a graphical desktop, llinuxconf will start in graphical mode. Otherwise, it will start in character mode. In either mode, the instructions are the same. Figure 4-1 shows linuxconf in graphical mode.
Figure 4-1:
The linuxconf main screen
Exercise 4-1
Adding a User with linuxconf
To add a user with linuxconf:
1. Run /bin/linuxconf.
2. Open Config ½ User accounts ½ Normal ½ User accounts. (This notation indicates you should open the Config tab, followed by the User accounts tab, then the Normal tab, and, finally, the User accounts tab. This will open the User Accounts form, as shown in Figure 4-2.) If you have more than 15 accounts on the system, linuxconf will present a Filter control screen. You can use this screen to select a smaller range of accounts to view, or just click Accept to view all accounts.
3. Select the Add button.
4. Complete the form (Figure 4-3) and click the Accept button. The only required field is Login Name, but you will most likely want to specify more information for each account. Table 4-1 describes each field.
5. You will be prompted to enter the user's password. The password should be at least six characters (you'll get an error message if it's less than six characters, but linuxconf will allow you to use the password anyway), and should contain a mix of upper- and lowercase letters, numbers, and symbols to keep it from being easily guessed. Enter the password in the Confirmation field to ensure you haven't misspelled it, then choose Accept.
6. When you are done adding users, click Quit to exit linuxconf.
Figure4-2:
The User Accounts form
Figure 4-3:
User account creation
Field
Instructions
The Account is enabled
Make sure this is checked if you want the user to be able to log in. If you're creating an administrative account that won't be used to log in, (some app needs it to run) uncheck this box.
Login name
The user logs in with this name. The Login name should only contain alphanumeric characters, and the - and _ characters. In almost all cases, the Login name should not contain uppercase letters. Although a login name can be up to 256 characters, you typically want to keep it to 10 or less, for ease of account maintenance. Examples: nickS, DGcatherine, heatherR, willr.
Full name
The full name of the user. Example: Dana Gordon.
group (opt)
The numeric group ID (GID) the user will belong to. By default, Red Hat Linux creates a new group for every new user. If you want all your users to be in the Users group, enter "users" here.
Supplementary groups
Enter any additional groups you want this user to be a member of.
Home directory (opt)
By default, Red Hat Linux places new home directories in /home/username.
Command interpreter (opt)
Enter the name of the shell program this user will use. Red Hat Linux defaults to the Bourne Again Shell (bash).
User ID (opt)
The user will be assigned the next available User ID (UID), if left blank. In most cases, it's best to leave this blank.
Must keep # days
If set to a positive number, the user must keep new passwords this many days before being allowed to change it.
Must change after # days
If set to a positive number, the user must change their password after this many days.
Warn # days before expiration
If set to a positive number, the user will be warned when logging on this many days before their password expires.
Account expire after # days
If set to a positive number, the account will be locked after this many days. This is a good setting for temporary logins.
Table 1: User Fields
Although creating user accounts may seem to be a straightforward process, there are a few things to watch out for:
* linuxconf will let you get away with using invalid characters in usernames, such as %, &, *, and !. However, many Linux programs will fail to function with usernames that contain these characters.
* If your installation doesn't require each user to have their own unique group ID (GID), assign your users to the Users group. There's rarely a need for each user to have an individual GID, and having most users assigned to the Users group makes system administration easier. However, the reason for the individual group ID system is for security purposes. By default, everyone in the same group will likely have access to each other's files. With every user having a separate GID, file security is heightened. Each user will have to explicitly provide access to their files.
* Ask your users to use passwords that are difficult to guess. Spouses' and dogs' names make bad passwords. Several words strung together with numbers or symbols make better passwords, such as "toy+jobs" or "rule%key." These are easy to remember, yet difficult to guess.
* Discourage the use of shared accounts, where several people use a single account. Shared accounts are almost always unnecessary, and are easily compromised.
* If you'll be using Network File System (NFS), make sure users maintain the same UID across systems. NFS can provide a centralized management of all user accounts across all participating machines. This greatly simplifies account maintenance at the expense of adding both administrative and additional network overhead.
Deleting a User Account with linuxconf
Removing user accounts is as straightforward as adding them, with a few exceptions. When you remove a user from your system, you'll have to make some choices about how (or if) you will save the files in the user's home directory. linuxconf gives you several choices regarding this decision.
Exercise 4-2
Deleting a User Account with linuxconf
1. Run /bin/linuxconf.
2. Select Config ½ User accounts ½ Normal ½ User accounts. This will open the User accounts form. If you have more than 15 accounts on the system, linuxconf will present a Filter control screen. You can use this screen to select a smaller range of accounts to view, or just choose Accept to view all accounts.
3. Select the account to be deleted.
4. Press the del button.
5. Select the appropriate option for the account data (see Table 4-2).
6. Choose the Accept button.
Deleting Account Data Option
Action
Archive the account's data
Data stored in the user's home directory is archived in /home/oldaccounts, under the filename username-yyyy-mm-dd-pid.tar.gz,(where username is the name of the deleted user; yyyy, mm, and dd are, respectively, the year, month, and day the account was deleted. pid is the process ID of the linuxconf process that created this file; and .tar.gz indicates this file was tar'd and gzip'd.
The user's home directory is then removed.
Delete the account's data
The user's home directory and all its contents are removed.
Leave the account's data in place
Nothing is done to the user's home directory and its contents.
Table 2: Delete Account Options
It is important to note that only files in the deleted user's home directory are processed. Any files owned by the deleted user stored outside the home directory still exist, under the UID of the deleted user. If a new user is created with the old user's UID, the new user owns those files.
Exercise 4-3
Modifying a User Account Using linuxconf
1. Run /sbin/linuxconf.
2. Select Config ½ User accounts ½ Normal ½ User accounts. This will open the User Accounts form. If you have more than 15 accounts on the system, linuxconf will present a Filter control screen. You can use this screen to select a smaller range of accounts to view, or just choose Accept to view all accounts.
3. Select the account to be modified.
4. Make the desired modifications to the account.
5. Choose Accept.
CERTIFICATION OBJECTIVE 4.02
The Basic User Environment
Each user on your Red Hat Linux system has an environment when logged on to the system. The environment defines where a user looks for programs to be executed, what the login prompt looks like, what terminal type is being used, and more. This section explains how default environments are set up.
Home Directories and /etc/skel
Red Hat Linux makes it easy to run a set of standard templates to propagate to new users' home directories via /etc/skel.
Home Directories
The home directory is the initial directory in which users are placed when they first log on to a Red Hat Linux system. For most normal users, this will be /home/username, where username is the user's login name. Users typically have write permission in their own home directory, so they're free to read and write their own files there. In Chapter 5, you'll learn how to configure disk quotas, so users don't allocate more than their fair share of disk space.
/etc/skel
The /etc/skel directory contains default environment files for new accounts. linuxconf copies these files to the home directory when a new account is created. Depending on the software installed, the files included in /etc/skel and their purpose are listed in Table 4-3.
Files
Purpose
.Xdefaultsscreenrc
Contains default settings for a few common X applications, if X is installed
.bashrc
The individual per-interactive-shell startup file
.bash_logout
Source the commands in this file upon logout
.bash_profile
The personal initialization file, executed for login shells
.kde, .kderc
The KDE desktop environment customization, if installed
Desktop
The GNOME desktop environment customization, if installed
Table 3: Files in /etc/skel and Their Purpose
As the system administrator, you can edit these files, or place your own files in /etc/skel. When new users are created, these files will be propagated to the new users' home directories. Additional entries are placed there by various programs during installation, such as emacs and secure shell.
Window Manager Configuration File Locations
Red Hat Linux comes with several window managers. You will at some point want to configure one or more of them for use on your system. Window manager configuration files are stored in /etc/X11/<windowmanager>, where <windowmanager> is the name of the window manager. Within the window manager subdirectory, there is usually a file named system.<windowmanager>, which contains default behavior for the window manager.
CERTIFICATION OBJECTIVE 4.03
File System Configuration
There are as many, if not more, file system types as there are operating systems. Red Hat Linux can understand many of these formats.
File System Types
At the heart of every Red Hat Linux installation are the file systems on which it relies. Linux supports a rich set of different file system types (see Table 4-4).
File System Type
Description
ADFS
The Acorn Disc Filing System. The standard file system of the Acorn's RISC-PC systems and the Archimedes line of machines. Currently, Linux supports ADFS as read-only.
Amiga FFS
The Fast File System is used by Amiga Systems computers.
Apple HFS
The Hierarchical File System used by the Apple Mac Plus, and all later Macintosh computers.
MS-DOS, VFAT, and UMSDOS
These file systems allow you to read MS-DOS-formatted file systems. MS-DOS lets you read pre-Windows 95 partitions. VFAT lets you read Windows 95 partitions, and UMSDOS allows you to run Linux from a DOS partition (not currently supported by Red Hat). Note that it is possible to read a Windows 95 partition with only MS-DOS support enabled, but you will not be able to see the long filenames generated by Windows 95.
ISO 9660 CDROM
The standard file system used on CD-ROMs. It is also known as the "High Sierra file system," or HSFS on other UNIX systems.
Minix
The standard file system for the Minix operating system. This is the original default Linux file system, although the ext2 file system has since superceded it.
NTFS
NTFS is the file system for Microsoft Windows NT. Currently it is only supported as read-only.
OS/2 HPFS
The standard file system for IBM's OS/2 operating system. Currently it is only supported as read-only.
/proc
The /proc file system is the Linux virtual file system. Virtual means that it doesn't occupy real disk space. Instead, files are created on the fly when you access them. /proc is used to provide information on kernel configuration and device status.
/dev/pts
The /dev/pts file system is the Linux implementation of the Open Group's Unix98 PTY support.
QNX
The standard file system for the QNX 4 operating system.
ROM
The ROM file system is a read-only file system, intended primarily for initial RAM disks.
Second Extended (ext2)
The standard file system for the Linux operating system.
System V and Coherent
The standard file system for Coherent, SCO, and Xenix.
UFS
The standard file system for BSD and BSD derivatives, SunOS, and NeXTstep.
Coda
Coda is a networked file system similar to NFS. Currently Linux supports Coda clients only.
NFS
The Network file system. This is the networked file system most commonly used among Linux and UNIX computers.
SMB
Server Message Block (SMB) is a protocol used by Windows for Workgroups, Windows 95, Windows NT, and OS/2 LAN Manager to share printers and files remotely.
NCP
Netware Core Protocol (NCP) is the network file system used by Novell, over the IPX protocol. NCP allows Linux to use NCP as a client.
Table 4: Linux File System Types
If you have the kernel source RPMs loaded on your system, you can see which file systems any version or distribution of Linux currently supports. Look at the file /usr/src/linux/fs/file systems.c.
The File System Table
Information about your local and remotely mounted file systems is stored in /etc/fstab. Each file system is described on a separate line. Each line is composed of multiple fields, each separated by spaces or tabs. When your system boots, it processes each file system in the order listed.
A sample /etc/fstab might look like the following:
/dev/hda1 / ext2 defaults 1 1
/dev/hda2 swap swap defaults 0 0
/dev/hda5 /usr ext2 defaults 1 2
/dev/hda7 /tmp ext2 defaults 1 2
/dev/hda8 /var ext2 defaults 1 2
/dev/hda9 /home ext2 defaults 1 2
/dev/hdc /cdrom iso9660 ro,noauto,user 0 0
none /proc proc defaults 0 0
Table 4-5 provides a description of each field.
(NOTE: throughout this book, you may see references to utility(#). This indicates the utility name and which man page this utility can be found in. You do not need the (#) part to use the utility. For example, fsck(8) means you could read the manual page for the command using "man 8 fsck.")
Field Name
Description
fs_spec
Describes the block device or remote file system to be mounted.
fs_file
Describes the mount point (the directory the file system will be mounted as). For swap partitions, this should be "none."
fs_vfstype
Describes the file system type. Valid file system types are minix, ext, ext2, xiafs, msdos, hpfs, iso9660, nfs, and swap. This field can also be set to "ignore," which will cause the system to ignore the entry. Ignoring an entry is useful for marking unused partitions.
fs_mntops
Mount options. Specifies mounting options. Mount options are covered later in this section.
fs_freq
Used by the dump(8) command to determine which file systems need to be dumped. A value of 0 indicates that the file system does not need to be dumped.
fs_passno
Used by the fsck(8) program to determine the order in which file systems are checked upon boot. The root file system should have an fs_passno setting of 1, and other local file systems should have an fs_passno of 2. Remote file systems should have an fs_passno of 0, which indicates they should not be checked on boot.
Table 5: Field Functions
Mount Options
Although most file systems in /etc/fstab are given the mount option of Default, there are other options you can use. Options are listed in /etc/fstab, and are separated by commas (no spaces or tabs). The standard mount options are listed in Table 4-6.
Mount Option
Description
async
I/O is done asynchronously to this file system.
atime
Timestamps for each inode are updated when accessed.
auto
Can be mounted with the -a option of the mount(8) command.
defaults
Use the default mount options: rw, suid, dev, exec, auto, nouser, and async.
dev
Interpret character or block special devices on the file system.
exec
Allow binaries (programs) to be executed on this file system.
noatime
Timestamps for each inode are not updated when accessed.
noauto
Cannot be mounted with the -a option of the mount(8) command (it must be mounted explicitly).
nodev
Do not interpret character or block special devices on the file system.
noexec
Do not allow binaries (programs) to be executed on this file system.
nosuid
Do not allow setuid or setgid permissions on programs to take effect.
nouser
Do not allow nonroot users to mount this file system.
remount
Attempt to remount a file system that has already been mounted. This is typically used to change mount options, and is only used by the mount(8) command (never used in /etc/mnttab).
ro
Mount the file system as read-only.
rw
Mount the file system as read-write.
suid
Allow setuid or setgid permissions on programs to take effect.
sync
I/O is done synchronously to this file system.
user
Allow nonroot users to mount this file system. This option also sets the noexec, nosuid, and nodev options, unless overridden.
Table 6: Mount Options
Some file system types supported by Red Hat Linux have additional options. If you are using non-ext2 file systems on your system, consult the mount(8) man page for more information regarding special mount options for your file system types.
You can also access file system information via linuxconf.
Exercise 4-4
Run /sbin/linuxconf
Open Config ½ File systems ½ Access local drive. This opens the Local Volume display similar to Figure 4-4.
Figure 4-4:
File system information in linuxconf
CERTIFICATION OBJECTIVE 4.04
Using the Red Hat Package Manager
One of the mundane, yet necessary, duties a Systems Administrator faces is software management. Applications and patches come and go. After months or years of adding, upgrading, and removing software applications, it's hard to tell just what's on a system, what version a software package is, and what other applications it depends on. Outdated files often wind up laying around because nobody's quite sure what they belong to. Worse, you may install a new software package only to find it has overwritten a crucial file from a currently installed package. The Red Hat Package Manager (RPM) was designed to eliminate these problems. With RPM, software is managed in discrete "packages," a collection of the files that make up the software, and instructions for adding, removing, and upgrading those files. RPM also makes sure you never lose configuration files by backing up existing ones before overwriting. RPM also tracks which version of an application is currently installed on your system.
A key feature of RPM is that filenames can be specified in Uniform Resource Locator (URL) format. For example, if you know that the package foo.rpm is on the FTP server ftp.rpmdownloads.com, in the /pub directory, you can specify that filename as ftp://ftp.rpmdownloads.com/pub/fee.rpm.RPM is smart enough to log on to the FTP server anonymously and pull down the file. You can also use the format ftp://<username>:<password>@hostname:<port>/path/to/remote/package/file.rpm, where <username> and <password> are the username and password you need to log on to this system non-anonymously, and <port> specifies a nonstandard port used on the remote machine. You may use these formats anywhere a filename is called for in RPM.
What Is a Package?
In the generic sense, a package is a container. It includes the files needed to accomplish a certain task, such as the binaries, configuration, and documentation files in a software application. It also includes instructions on how and where these files should be installed, and how the installation should be accomplished. A package also includes instructions on how to uninstall itself. RPM packages are often identified by filenames that usually consist of the package name, the version, the release, and the architecture for which they were built. For example, the package penguin-3.26.i386.rpm indicates this is the (fictional) Penguin Utilities package, version 3, release 26. i386 indicates it has been compiled for the Intel architecture. Note that although this is the conventional method of naming RPM packages, the actual package name, version, and architecture information are read from the contents of the file by RPM, not the filename. You could rename the file blag.rpm, but it would still install as penguin-3.26.i386.rpm.
What Is RPM?
At the heart of RPM is the RPM database. This database tracks where each file in a package is located, its version, and much more. The RPM also maintains an MD5 checksum of each file. Checksums are used to determine if a file has been modified, which comes in handy if you need to verify the integrity of one or more packages. The RPM database makes adding, removing, and upgrading packages easy, because RPM knows which files to handle, and where to put them. RPM also takes care of conflicts between packages. For example, if package X, which has already been installed, has a configuration file called /etc/someconfig, and you attempt to install a new package, Y, which wants to install the same file, RPM will manage this conflict by backing up your previous configuration file before the new file is written. The workhorse of the RPM system is the program rpm. rpm is the "driver" responsible for maintaining the RPM databases. Of rpm's 10 modes of operation, we will cover the four most common: query, install, upgrade, and remove.
Validating a Package Signature
RPM has two methods of checking the integrity of a package: MD5 checksum and GPG signature. MD5 alone is adequate for verifying that the file is intact (no data was lost or corrupted while copying or downloading the file). GPG is used to establish the authenticity of the file; it can be used to confirm, for example, that an RPM file is indeed an official Red Hat RPM. Red Hat provides a GPG public key for its RPM files; the key is located in the RPM-GPG-KEY file on your distribution CD, or can be downloaded from www.redhat.com/about/contact.html.
To authenticate your RPMs using GPG, import the key file using the command (assuming it's a CD-based keyfile):
# gpg --import RPM_GPG_KEY
You can then verify both the integrity and authenticity of an RPM with a command like this:
# rpm --checksig pkg-0.0.0-0.rpm
If you don't want to use GPG, you can check the integrity of the package only using:
1.# rpm --checksig --nogpg pkg-0.0.0-0.rpm
To Add and Remove Components
RPM makes it easy to add and remove software packages to your system. It keeps a database regarding the proper way to add, upgrade, and remove packages, making it as simple as running a single command to add and remove software.
Install Mode
The Install mode, as its name suggests, is used to install RPM packages on your system. Installing a package is accomplished with the -i option.
# rpm -i penguin-3.26.i386.rpm
Or, if the package was stored on a remote FTP server, you could use:
# rpm -i ftp://ftp.rpmdownloads.com/pub/penguin-3.26.i386.rpm
Before installing the package, RPM performs several checks. First, it makes sure the package you're trying to install isn't already installed-RPM won't let you install a package on top of itself. It also checks to make sure you aren't installing an older version of the package. Next, RPM does a dependency check. Some packages depend on other packages being installed first. In this example, you've just downloaded the latest RPM version of Penguin utilities, and now want to install it.
# rpm -i penguin-3.26.i386.rpm
failed dependencies:
iceberg >= 7.1 is needed by penguin-3.26.i386.rpm
This error indicates the penguin package failed to install because it requires the Iceberg package, version 7.1 or later. You'll have to find and install the Iceberg package, and any packages Iceberg may require.
Finally, RPM checks to see if any configuration files would be overwritten by the installation of this package. RPM tries to make intelligent decisions about what to do with conflicts. If RPM replaces an existing configuration file with one from the new package, a warning will appear on the screen.
# rpm -i penguin-3.26.i386.rpm
warning: /etc/someconfig saved as /etc/someconfig.rpmsave
It's up to you to look at both files and determine what, if any, modifications need to be made.
Upgrade Mode
The -u switch is used to upgrade existing packages. For example, if Penguin utilities, version 3.25, is already installed, issuing the command:
# rpm -u penguin-3.26.i386.rpm
will replace the old version of the package with the new one. In fact, one of the quirks of RPM's Upgrade mode is that the older package doesn't even have to exist. -u works identically to -i in this case.
Remove Mode
The rpm -e command removes a package from your system. Like the Install mode, RPM does some housekeeping before it will let you remove a package. First, it does a dependency check to make sure no other packages depend on the package you are removing. If you have modified any of the configuration files, RPM makes a copy of the file, appends .rpmsave to the end of it, and then erases the original. Finally, after removing all files from your system and the RPM database, it removes the package name from the database.
NOTE: Be very careful about which packages you remove from your system. Like most Linux utilities, RPM assumes omniscience, and will silently let you shoot yourself in the foot. Removing the passwd or kernel package would be devastating.
Adding Updates, Security Fixes, and Other Items
Red Hat Linux is constantly being updated. As bugs or security problems are found, they are posted to Red Hat's Errata Web page, located at http://www.redhat.com/support/docs/errata.html. You should check this page regularly to ensure your system is up to date.
Exercise 4-5
Updating from the Red Hat Errata Page
Here's a good checklist to follow whenever you check the errata page:
1. Go to http://www.redhat.com/support/docs/errata.html. Select the Red Hat Linux General Errata link.
2. Scroll down to the Overview section. Go through the lists, selecting each package listed.
3. If you have an affected package loaded on your system, consider upgrading it with the recommended replacement.
4. Before replacing an affected package, consider the ramifications. You may need to bring the system down to single-user, or perform a reboot.
5. When performing the upgrade, watch for configuration file warnings. If your local configuration files are replaced with new files, you may need to change the new configuration files to reflect your current settings.
6. Thoroughly test the new package. Make sure you have it configured correctly.
7. If a package is listed in the errata but not installed on your system, chances are there's no reason to put it on your system now. Read the detailed errata entry for that package carefully, and only install it if needed.
Red Hat has now included an RH Network Software Manager service that you can configure to check for revised packages, new packages, errata, and other information. You may obtain a free trial subscription to the service by registering at www.redhat.com/network; thereafter, a charge for the service is applied.
Verifying One or More Packages
Verifying an installed package compares information about that package with information from the RPM database on your system, or the original package. Verify does a check against the size, MD5 checksum, permissions, type, owner, and group of each file in the package. Here are a few verify examples:
* Verify all packages
# rpm --verify -a
* Verify all files within a package against an RPM file
# rpm --verify -p fileutils-4.0-1.i386.rpm
* Verify a file belonging to a particular package
# rpm --verify --file /bin/ls
If the files or packages you were verifying checked out okay, you will see no output; otherwise, you'll see what checks failed. The output will be a string of eight characters, possibly with a "c" denoting configuration file, followed by the filename that failed. Each character in the eight-character field contains the result of a particular test. A "." (period) indicates that test passed. The following example shows /bin/vi with an incorrect group ID assigned to it:
# rpm --Verify --file /bin/vi
......G. /bin/vi
Table 4-7 lists the failure codes and their meanings.
Failure Code
Meaning
5
MD5 checksum
S
File size
L
Symbolic link
T
File modification time
D
Device
U
User
G
Group
M
Mode
Table 7: Failure Codes
Seeing What Packages Are Installed
Without RPM, you'd need to search around your file systems to figure out if a particular software package is installed. RPM makes it easy for you to figure out what RPM packages are installed, and to get information about those packages.
Query Mode
One of the strengths of RPM is that, ideally, every package or application file on your system is accounted for. Using RPM's query mode, you can determine which packages are installed on your system, or what file belongs to a particular package. This can be a big help if you want to locate a file that belongs to a certain package. Query mode can also be used to identify what files are in an RPM file before you install it. This lets you see what files are going to be installed on your system before they're actually written.
The -q switch is used to query packages. By itself, -q will give you the version of a specified package. If you want to see which version of the tin newsreader you have on your system, you would issue the following command:
# rpm -q tin
tin-1.4.4-2
If you want to see which installed package owns a file, use the -f modifier. Here we want to see which package owns /etc/passwd.
# rpm -q -f /etc/passwd
setup-2.3.4-1
Likewise, if you want to generate a list of files belonging to a certain package, use the -l modifier.
# rpm -q -l tin
/etc/X11/applnk/Internet/tin.desktop
/usr/bin/rtin
/usr/bin/tin
/usr/share/doc/tin-1.4.4
/usr/share/doc/tin-1.4.4/README
/usr/share/doc/tin-1.4.4/doc
/usr/share/doc/tin-1.4.4/doc/CHANGES
/usr/share/doc/tin-1.4.4/doc/CHANGES.old
/usr/share/doc/tin-1.4.4/doc/DEBUG_REFS
/usr/share/doc/tin-1.4.4/doc/INSTALL
/usr/share/doc/tin-1.4.4/doc/TODO
/usr/share/doc/tin-1.4.4/doc/WHATSNEW
/usr/share/doc/tin-1.4.4/doc/auth.txt
/usr/share/doc/tin-1.4.4/doc/filtering
/usr/share/doc/tin-1.4.4/doc/good-netkeeping-seal
/usr/share/doc/tin-1.4.4/doc/internals.txt
/usr/share/doc/tin-1.4.4/doc/iso2asc.txt
/usr/share/doc/tin-1.4.4/doc/pgp.txt
/usr/share/doc/tin-1.4.4/doc/rcvars.txt
/usr/share/doc/tin-1.4.4/doc/reading-mail.txt
/usr/share/doc/tin-1.4.4/doc/tin.1
/usr/share/doc/tin-1.4.4/doc/tin.defaults
/usr/share/doc/tin-1.4.4/doc/umlaute.txt
/usr/share/doc/tin-1.4.4/doc/umlauts.txt
/usr/share/man/man1/tin.1.gz
One of the most common modifiers to -q is -a, query all packages on your system. A default Workstation system has over 350 packages installed. Here's a truncated output:
# rpm -q -a
chkconfig-1.2.16-1
sed-3.02-8
psmisc-19-4
XFree86-libs-4.0.1-1
glib-1.2.8-4
...
wmconfig-0.9.9-3
xfig-3.2.3c-3
xtoolwait-1.2-5
For even more information about a package, use the -i (information) modifier.
# rpm -q -i passwd
Name : passwd Relocations: (not relocateable)
Version : 0.64.1 Vendor: Red Hat, Inc.
Release : 4 Build Date: Wed 12 Jul 2000 04:56:03 AM PDT
Install date: Thu 15 Feb 2001 07:03:11 AM PST Build Host: porky.devel.redhat.com
Group : System Environment/Base Source RPM: passwd-0.64.1-
4.src.rpm
Size : 17004 License: BSD
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Summary : The passwd utility for setting/changing passwords using PAM.
Description :
The passwd package contains a system utility (passwd) which sets
and/or changes passwords, using PAM (Pluggable Authentication
Modules).
To use passwd, you should have PAM installed on your system.
#
Table 4-8 lists some of the most important entries:
Name
The name of the package.
Version
The version of the package.
Release
The number of times this package has been released using the same version of the software.
Install Date
When this package was installed on your system.
Group
Your RPM database is divided into groups, which describes the functionality of the software. Every time you install a package, it will be grouped accordingly.
Size
The total size in bytes of all the files in the package.
License
The license the original software has been released under.
Table 8: Important Entries
Typically, the filename will indicate what's inside the package, but not always. You may receive a package simply named glibc.rpm, which isn't really helpful. You can use the -p modifier to find out what version and release this RPM contains (and perhaps rename it appropriately).
# rpm -q -p glibc.rpm
glibc-2.0.7-29
Creating and Using Custom RPMs
Source RPMs are, as the name indicates, the source codes used to build architecture-specific packages. Source RPMs are identified with the string "src" appearing where the architecture indicator normally appears, such as:
polarbear-2.07-2.src.rpm
Binary RPMs are built from source RPMs. The source RPM contains the source code and specifications necessary to create the binary RPM.
Installing Source RPMs
Like normal RPMs, a source RPM (SRPM) is installed using the -i option. This will place the contents of the SRPM within the /usr/src/redhat directory structure.
The /usr/src/redhat/ Directory Structure
There are five subdirectories within the /usr/src/redhat directory structure (see Table 4-9).
Directory
Purpose
/usr/src/redhat/SOURCES
Contains the original program source code
/usr/src/redhat/SPECS
Contains spec files, which control the RPM build process
/usr/src/redhat/BUILD
Source code is unpacked and built here
/usr/src/redhat/RPMS
Contains the resulting binary RPM
/usr/src/redhat/SRPMS
Contains the SRPM created by the build process
Table 9: Subdirectories with the /usr/src/redhat Directory Structure
When you build an SRPM, you will build it within this structure. If you install an SRPM, it will be extracted into this structure.
Changing Compile Options for a Source RPM
While most precompiled RPMs will serve your needs, there are times when you will want to modify the source code or compile options in the corresponding SRPMs.
The Spec File
To change the compile options in an SRPM, you must understand spec files. The spec file is stored in /usr/src/redhat/SPECS/<packagename>.spec. The spec file controls the way a package is built, and what actions are performed when it is installed or removed from a system. There are eight different sections in a spec file (see Table 4-10).
Section
Description
Preamble
Describes what information a user sees when he or she requests information about this package. It also contains a description of the package's function and the version, as well as information about the sources and patches used. It may also contain an icon to be used if the package is manipulated with a graphical RPM manager.
Prep
If work needs to be done to the source code before actually building it, it's described here. At a minimum, this usually means unpacking the source code. The contents of this section are a shell script.
Build
***Commands to actually compile the spec file and build the sources are in a shell script here.
Install
Commands to install the software on a system.
Install and uninstall scripts
This section contains scripts that will be run on the end user's system to install or remove the software. RPM can execute a script before the package is installed, after the package is installed, before the package is removed, and after the package is removed.
Verify
Although RPM takes care of most verification tasks, a script can be inserted here to take care of extra tasks the package builder may want to do.
Clean
A script can be specified here to perform any necessary cleanup tasks.
File list
This is a list of files in the package.
Table 10: Spec File Sections
You would change the compile-time options for a package in the build section of the spec file. Here's a sample build section in a spec file:
%build
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/bin $RPM_BUILD_ROOT/etc
./configure --prefix=/usr --exec-prefix=/
make CFLAGS="$RPM_OPT_FLAGS" LDFLAGS=-s
This section, a shell script, begins with some housekeeping. The fourth line runs the configure script in the software package, followed by a "make." You could, for example, modify the make command line to include another definition after LDFLAGS. The compile time options being passed in $RPM_OPT_FLAGS are defaults, set by RPM.
Building Custom Source and Binary RPMs
By now, you should understand how to modify an SRPM spec file to change compile time options in the Build section. However, there's much more to building customized RPMs. Once you have modified the spec file, you need to tell RPM to build a new RPM and SRPM.
Starting a Build
You build an RPM with the build option of RPM, -b. You will normally modify the -b option with an "a," which means all steps of the build operation must be performed. The RPM build operation is directed at a spec file. For example, the command:
# rpm -ba foo-2.2.spec
directs RPM to create a binary and source RPM from this spec file.
Building an RPM from a Tar Archive
Now that you understand the basics of building an RPM from an SRPM, it's relatively easy to build an SRPM and RPM from a tar archive.
Obtain the Source Files
You'll need to obtain the source code for the package you want to create. You'll need to locate the FTP or Web site for the software you want, obtain the latest version (or whatever version you want to use), and download it. Once you have a copy, put it in the SOURCES directory.
Create the Spec File
Here's where you get to brew a spec file from scratch. Depending on how complicated your source software is, you may wind up with a rather complex spec file. However, for this run, we're going to just cover the basics you'll need to get a spec file running.
The Preamble
You'll need to fire up your favorite text editor and start working on the spec file. Let's start with the preamble section. Here's the preamble (abridged) from fileutils-3.16.spec:
Summary: GNU File Utilities
Name: fileutils
Version: 3.16
Release: 10
Copyright: GPL
Group: Utilities/File
Source0: ftp://prep.ai.mit.edu/pub/gnu/fileutils-3.16.tar.gz
Source1: DIR_COLORS
Patch: fileutils-3.16-mktime.patch
Patch1: fileutils-3.16-glibc21.patch
Buildroot: /var/tmp/fileutils-root
Summary(de): GNU-Datei-Utilities
Summary(fr): Utilitaires fichier de GNU
Summary(tr): GNU dosya iþlemleri yardýmcý yazýlýmlarý
Prereq: /sbin/install-info
%description
These are the GNU file management utilities. It includes programs
to copy, move, list, etc, files.
The ls program in this package now incorporates color ls!
Preamble entries consist of a tag, followed by a colon, followed by information. Some entries are language-specific; these are denoted by a two-letter country code in parentheses just before the colon. The order of the lines is unimportant. Table 4-11 lists entries that may be included in the preamble.
Tag
Description
Name
The name of the package.
Version
The version of the software being packaged.
Release
The number of times this software has been packaged. This will become part of the package label and filename.
Buildroot
The directory this package was built in.
Copyright
Contains the software's copyright information.
Group
Which RPM group this software should be packaged in.
Patch
Patches applied to the software.
Source
There are two entries for this tag. The first indicates where the packaged software's source may be found. The second gives the name of the source file in the SOURCES subdirectory.
Summary
A short, one-line description of the software being packaged.
URL
This tag, if present, usually indicates the home page, or where documentation for the software can be found.
Distribution
The product line this package was created for. This is normally used by Linux distribution companies such as Red Hat Software to indicate which release this package was part of.
Vendor
The group or organization that distributes the software being packaged.
Packager
The group or organization that packaged this software.
Description
This entry may take up more than one line. It is a detailed description of the packaged software.
Table 11: Preamble Entries
The Prep Section
The prep section prepares the source files for packaging. Usually the prep section starts by removing the leftovers from any previous builds, and unarchives the source files. A sample prep section might look like this:
%prep
/bin/rm -rf $RPM_BUILD_DIR/foo-2.2
/bin/tar xzf $RPM_SOURCE_DIR/foo-2.2.tar.gz
Note that the prep section is nothing more than a shell script. The environment variables RPM_BUILD_DIR and RPM_SOURCE_DIR are preset by RPM. They expand to /usr/src/redhat/BUILD and /usr/src/redhat/SOURCE, respectively. This prep script extracts the contents of foo-2.2.tar.gz into the SOURCE directory. If we needed to do any patching to the sources, it would be done here.
There is, by the way, a predefined macro that will handle both of the steps we coded in the previous example. The %setup macro removes any files left over from a previous build, and then extracts the contents of the source file. Now, our prep script becomes:
%prep
%setup
The Build Section
Like the prep section, the build section is also a shell script. This script will handle building binary programs out of the source code. Depending on the software, this step may be very easy, or quite involved. A sample build script might be:
%build
make clean
./configure -prefix=/usr -exec-prefix=/
make
These commands run "make clean" to ensure any old object and configuration files are removed. Then the software's configure script (with some additional options) is run, which configures the software for the platform you're compiling on. The make command with no arguments is then run to compile the software.
The Install Section
Yet another shell script, the install section, allows you to build install targets within the source distribution. For uncomplicated software, this may be as simple as:
%install
make install
The Files Section
This is a list of files that will become part of the package. Any files you want to distribute in the package must be listed here.
You may specify a %doc directive on a line, which indicates the file listed on this line is documentation. That file will be placed in the /usr/doc/<package> subdirectory when the end user installs this package on the system. Here's an example of a files section from our fictional package foo-2.2:
%files
%doc README
%doc FAQ
/usr/bin/foo
/usr/man/man1/foo.1
The preceding example shows that the files README and FAQ will be placed in the /usr/doc/foo-2.2 subdirectory.
Building the RPM and SRPM
At this point, it's just a matter of running:
# rpm -ba foo-2.2.spec
to build your RPM and SRPM. Some other modifiers that are handy to run with the -b option are listed in Table 4-12.
Option
Description
-bp
Execute only the prep section.
-bl
Check the files section to make sure all the files exist.
-bc
Execute only the build section.
-bi
Execute only the install section.
-bs
Build only the SRPM.
--test
Do not execute any build stages. (Useful for testing the syntax of your spec file.)
Table 12: Modifiers
Testing Your RPM
It's important you test your RPM thoroughly before releasing it for general distribution. Install it, uninstall it, run the program through its paces. Make sure the documentation and man pages were installed correctly, and that configuration files are present and have sane defaults.
Like many Linux tools, RPM has short options with long option equivalents. For example, the -i option (a "short" option) can also be specified using the --install option (a "long" option). You can learn which options have "long" equivalents by checking the man pages for that command.
CERTIFICATION OBJECTIVE 4.05
Basic Networking
The network is where the power of Red Hat Linux really comes alive; however, getting there may not be trivial. As in all other things Linux, it's a learning experience.
The /etc/sysconfig/ Files Used in Network Setup
We'll start our tour in the /etc/sysconfig directory. This is where Red Hat Linux stores and retrieves its networking information. With linuxconf, you'll almost never have to touch these files, but it's good to know they're there (see Table 4-13).
Filename
Description
/etc/sysconfig/network
This file stores your system's host name, IPV4 forwarding information, your NIS domain, your gateway and gateway device, and whether or not your system uses any type of networking. Some of these values may not be present, depending on how your system is configured.
/etc/sysconfig/network-scripts/
This directory, as its name implies, stores the networking scripts necessary for your system to get itself up on the network.
/etc/sysconfig/network-scripts/ifcfg-lo
The loopback device configuration script. If you're running TCP/IP, you will almost always have a loopback device configured. The loopback isn't a real device, but a dummy interface designed to test your TCP/IP stack.
/etc/sysconfig/network-scripts/ifcfg-*
Each network interface on your machine will, if it is configured, have an associated ifcfg-* script. For example, the first Ethernet card on your system, eth0, will have a corresponding ifcfg-eth0 script. This file contains information about the interface's IP address, netmask, what network it's on, its broadcast address, and whether it should be brought up at boot time. Depending on the type of interface (such as PPP or SLIP), it may contain other information.
/sbin/ifup /sbin/ifdown
These scripts take a network interface as an argument. The ifup script brings the specified interface up; ifdown takes it down.
/etc/sysconfig/network-scripts/network-functions
This script contains functions used by other network scripts to bring network interfaces up and down. This script should never be called directly.
/etc/sysconfig/network-scripts/chat-*
Chat scripts for PPP and SLIP connections.
/etc/sysconfig/network-scripts/ifup-post
This script is called whenever a network device (SLIP excluded) comes up. This script calls the ifup-routes script for static routes, configures aliases for the given device, sets the host name if it's not already set (and if it can resolve a name to the IP address), and sends a SIGIO to programs that have requested notification of network events.
/sbin/pump
pump is a command and a daemon process that manages network interfaces controlled by either DHCP or BOOTP protocol. It is normally started automatically by the /sbin/ifup script for devices configured by BOOTP or DHCP.
To query the status of interface eth0:
/sbin/pump -i eth0 --status
/etc/sysconfig/network-scripts/ifup-* and etc/sysconfig/network-scripts/ifdown-*
These scripts bring up or take down, respectively, their assigned protocols. For example, ifup-ipx brings up the IPX protocol
/sbin/ifconfig
This is the main network interface configurator utility used to set the network parameters on any specific interface.
Table 13: Files in the /etc/sysconfig Directory
/etc/sysconfig Files for Clock, Mouse, Static-routes, Keyboard, and PCMCIA
While we're in /etc/sysconfig, let's take a little detour and discuss some of the other things in here that make your system run (see Table 4-14).
File
Description
/etc/sysconfig/clock
Contains defaults for the system clock. There are currently only two entries:
UTC=true|false-Indicates whether or not the clock is set to UTC (Universal Time Code).
ARC=true|false-On alpha platforms, indicates the ARC console's 42-year time offset is in effect.
/etc/sysconfig/mouse
Contains mouse configuration information. Entries include:
MOUSETYPE=type, where type is one of the following: microsoft, mouseman, mousesystems, ps/2, msbm, logibm, atibm, logitech, mmseries, or mmhittab. (See the Hardware-HOWTO in /usr/doc/HOWTO for information on supported mice.)
XEMU3=yes|no-Indicates whether a three-button mouse should be emulated on two-button mice. If you have a two-button mouse, you'll want to select three-button emulation to run X, which uses the third button extensively. The third button is simulated by pressing the first and second buttons simultaneously.
/etc/sysconfig/static-routes
Contains lines in the form of:
device net network netmask mask gw gateway
These values correspond to arguments in the route(8) command.
/etc/sysconfig/keyboard
Contains a single line, indicating which keyboard map to use:
KEYTABLE="/usr/lib/kbd/keytables/us.map"
/etc/sysconfig/pcmcia
Contains PCMCIA configuration information. The most relevant value in here is:
PCMCIA=yes|no-Indicates whether PCMCIA modules should be loaded on boot. Setting this to Yes would tell the kernel to load PCMCIA modules automatically at boot time. This setting is typically only needed for PCMCIA-enabled devices such as laptops.
Table 14: /etc/sysconfig Files for Clock, Mouse, Static-routes, Keyboard, and PCMCIA
Setting Up a Network Interface
Using linuxconf, you can modify your system name, as well as add, remove, and edit network interfaces.
Exercise 4-6
Changing Your System Name with linuxconf
1.From either a GUI or console terminal, run linuxconf.
2.Open Config ½ Networking ½ Client tasks ½ Basic host information. You will see a display similar to Figure 4-5. The default host name is "localhost.localdomain."
3.Replace this with a new host name, (for example, rh7) followed by the domain name your server is in (if you are in example.com domain, then use rh7.example.com).
4.Select the Act/Changes button for your new host name to take effect. NOTE: The Act/Changes button runs scripts that take more than a nanosecond, so do NOT keep clicking if the prompt doesn't instantly disappear. It is working in the background and will remove the prompt when it is done. I know it is hard, but you just have to be patient at times; this being one of those times.
5.At the command line, enter the command "hostname." You should see your new name.
6.Reboot the machine and you should see the login prompt reflect your new host name.
Figure 4-5:
Changing the host name in linuxconf
Exercise 4-7
Modifying Network Interfaces with linuxconf
1. From a GUI or console terminal, start linuxconf.
2. Open Config ½ Networking ½ Client tasks ½ Basic host information.
3. Select the Adaptor 1 tab (or the tab corresponding to the interface you wish to modify). You will see a form similar to the one shown in Figure 4-6.
Figure 4-6:
Modifying network interfaces with linuxconf
NOTE: record your current settings for this interface before proceeding.
4. Change the IP value to 192.168.1.11 and the network mask to 255.255.255.0.
NOTE: This is a non-routing IP address and will stop all access to the Internet if connected. It will also stop all access to your local network unless this is within the same network as your local network. The assumption is that this is not a valid local IP address and should isolate you from all other hosts on the local network. Test this by trying to ping any other host.
5. Select the Act/Changes button, then wait for the process to complete.
6. At the command prompt, enter ifconfig and display your new IP settings.
7. Repeat steps 1-3 and then reset the values to your previous settings. Select the Act/Changes button and wait for the process to complete. Run ifconfig from a command line to check the old values are being used.
There are many values associated with each network interface. The minimum you need is a valid and unique IP address and the corresponding network mask. linuxconf provides a convenient form for you to fill out for each device. You may enter or modify any of the values in this form. Table 4-15 lists each field and its description.
Field
Description
Primary name + domain
The host name and domain name that will be bound to this interface.
Aliases
Any aliases you wish this interface to be known by.
IP address
The IP address assigned to this interface.
Netmask
The netmask used by this subnet.
Net device
The device this interface uses.
Kernel module
If the driver for this module isn't loaded statically in the kernel, then the loadable module will need to be identified here.
I/O port
Only necessary if the driver requires you specify an I/O port.
Irq
Only necessary if the driver requires you specify an IRQ setting.
Table 15: Fields
You may then select the Act/Changes button for your new interface edits to take effect.
ifup/ifdown
Recall that for each network interface present on your system, there is a corresponding ifcfg-* file in /etc/sysconfig/network-scripts. You can bring an interface up, or take it down, using the ifup and ifdown commands. You can also use the device name directly with the ifup and ifdown commands. The following two commands do the same thing:
ifup ifcfg-eth0
ifup eth0
Either one of the preceding commands will bring up the eth0 network interface.
ifconfig
The ifconfig command is used to configure and display network devices. Here is some sample output of an ifconfig command:
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 08:00:20:74:17:33
inet addr:207.174.142.141 Bcast:207.174.142.143 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1426914 errors:0 dropped:0 overruns:0
TX packets:1199517 errors:1 dropped:0 overruns:0
The preceding command is querying the first Ethernet device on the system, eth0. With only the device as an argument, ifconfig only displays information about the specified interface. When invoked with no parameters, ifconfig shows all interfaces. Table 4-16 lists what the significant fields in the ifconfig output mean.
Field
Description
RX and TX
Indicates how many error-free packets have been received and transmitted, respectively. It also shows how many errors occurred, how many packets were dropped, and how many overruns occurred. An overrun usually happens when packets come in faster than the kernel can service the interrupt.
Inet addr
The IP address assigned to this interface.
Bcast
The network broadcast address.
Mask
The netmask used by this subnet.
Table 16: Significant Fields in the ifconfig
As indicated, ifconfig is also used to configure network interfaces. The following command would be used to change the IP address of the eth0 interface:
# ifconfig eth0 207.174.142.142
The first parameter, eth0, tells us which interface is being configured. The next argument, 207.174.142.142, indicates the new IP address being assigned to this interface. If we want to make sure our change worked, we issue the ifconfig command again, to view its current settings.
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 08:00:20:74:17:33
inet addr:207.174.142.142 Bcast:207.174.142.143 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1426914 errors:0 dropped:0 overruns:0
TX packets:1199517 errors:1 dropped:0 overruns:0
Looking at the output of our command, we successfully changed the IP address on the eth0 interface to 207.174.142.142. There are a number of other parameters used with ifconfig for modifying interface information (see Table 4-17).
Parameter
Description
Up
Marks the interface up to the IP stack.
Down
Marks the interface down to the IP stack.
netmask mask
Assigns a subnet mask to the interface. The mask can be entered as a 32-bit hexadecimal number preceded by the string 0x, as a dotted quad of decimal numbers, or as a string of hexadecimal numbers.
Pointopoint
Used to configure PPP links that only involve two hosts.
broadcast address
While ifconfig allows you to change the broadcast address, you'll almost never have to use this option, except in very old networking environments.
metric number
Allows you to set a metric value for the routing table entry created for the interface. You will almost never need to set this.
mtu bytes
Sets the maximum transmission unit.
Arp
Allows ARP, the Address Resolution Protocol, to detect the physical addresses of hosts on the network. This is on by default.
-arp
Turns ARP off.
Promisc
Puts the interface in promiscuous mode. This allows the interface to receive all packets on the network, whether they were destined for this host or not. This is most commonly used for analyzing the network for problems or bottlenecks.
-promisc
Turns off promiscuous mode.
Table 17: Parameters Used with ifconfig for Modifying Interface Information
netstat -r
The netstat command is used to display a plethora of network connectivity information. The most commonly used option to netstat, -r, is used to display the kernel routing tables. Here's a sample netstat -r output:
# netstat -n -r
Kernel routing table
Destination Gateway Genmask Flags Metric Ref Use
127.0.0.1 * 255.255.255.255 UH 1 0
191.72.1.0 * 255.255.255.0 U 1 0
191.72.2.0 191.72.1.1 255.255.255.0 UGN 1 0
Did you notice we used a -n flag? -n tells netstat to display addresses as IP addresses, instead of as host names. This makes it a little easier for us to see what's going on.
The Destination column shows the different routes we set up for our network to access. The Gateway column indicates gateway addresses. A gateway, as its name implies, is a route a packet must take first to get to its destination. If no gateway is necessary, an asterisk is printed. The Genmask column shows the "generality" of the route. When attempting to determine a suitable route for an IP address, the kernel will go through the routing table and take a bitwise AND of the Genmask and the address, before comparing it to a route target. The Flags column describes the route. The values that may appear are listed in Table 4-18.
Flag
Description
G
The route uses a gateway.
U
The interface to be used is up.
H
Only a single host can be reached via this route.
D
This entry was created by an ICMP redirect message.
M
This entry was modified by an ICMP redirect message.
Table 18: The Ref column indicates how many other routes rely on this entry
arp as a Diagnostic Tool
The arp command is used to view or modify the kernel's Address Resolution Protocol (ARP) table. Using arp, you can detect problems such as duplicate addresses on the network, or you can manually add arp entries when arp queries fail. Here's a sample arp command, showing all arp entries known to the kernel:
# arp -a
IP address HW type HW address
10.40.6.2 10Mbps Ethernet 00:00:C0:2C:33:CA
10.40.6.3 10Mbps Ethernet 00:00:C0:4A:B3:42
10.40.6.6 10Mbps Ethernet 00:00:C0:0C:A6:A2
The IP address column shows the IP addresses of the hosts it knows about. The "HW type" column shows the hardware type of the host, while the "HW address" column shows the Ethernet address of the device queried.
You can use the -H option to limit arp's output to the hardware specified. The hardware type can be ax25, ether, or pronet. The default is ether.
A common problem the arp command addresses is when a host on the network is configured with the IP address of a preexisting host on the network. Such cases happen by mistake, but may also happen under circumstances that are more nefarious. In any case, you'll want to remove the offending machine's arp entry from your arp table, and add the correct arp entry. To remove an arp entry, use the -d option.
# arp -d bugsy
This removes all arp information for the host "bugsy." To add an arp entry, use the -s option.
# arp -s bugsy 00:00:c0:cf:a1:33
This entry will add the host bugsy to the arp table. Note that an Ethernet, not an IP address, must be specified. The Ethernet address is a physical address associated with the network card.
CERTIFICATION OBJECTIVE 4.06
chkconfig and ntsysv
Red Hat Linux provides two utilities that assist the system's administrator in configuring and maintaining the startup and shutdown process. The ntsysv utility provides a screen-oriented interface, while chkconfig provides a command-line interface.
The Boot Process
Understanding how your system boots and shuts down will help you immensely as a Red Hat Systems administrator. Red Hat Linux uses a process called System V init. To understand the process better, let's go through the steps Red Hat Linux takes to boot itself up to a usable system.
The init program is called by the kernel when it starts up. The init process in turn runs /etc/rc.d/rc.sysinit. rc.sysinit performs a number of tasks, including configuring the network, setting up the default keymapping, starting up swapping, and setting the host name. The init process then determines which runlevel it should be in by looking at the initdefault entry in /etc/inittab. A runlevel is defined as a group of activities. For example, the entry:
id:5:initdefault:
indicates this system should start up in runlevel 5. After determining which runlevel it should be at, init runs the appropriate scripts to insure the activities intended for that runlevel are started. System V init scripts are stored in the directory /etc/rc.d. Within this directory are the following subdirectories:
init.d
rc0.d
rc1.d
rc2.d
rc3.d
rc4.d
rc5.d
If the default runlevel is 5, init will look in /etc/rc.d/rc5.d and run each "start" script it finds there. A start script is any file or symbolic link with a name beginning with the character S. However, if you run an ls -l command in this directory, you'll find that there are no real files here, only symbolic links to the actual scripts in /etc/rc.d/init.d.
# ls -l
[root@jctx init.d]# ls -l
total 182
-rwxr-xr-x 1 root root 1535 Jul 15 2000 amd
-rwxr-xr-x 1 root root 798 Aug 4 2000 anacron
-rwxr-xr-x 1 root root 1289 Aug 17 2000 apmd
-rwxr-xr-x 1 root root 908 Aug 11 2000 arpwatch
-rwxr-xr-x 1 root root 1171 Aug 23 2000 atd
-rwxr-xr-x 1 root root 8385 Aug 23 2000 autofs
-rwxr-xr-x 1 root root 1177 Aug 5 2000 bootparamd
-rwxr-xr-x 1 root root 1678 Aug 23 2000 ciped
-rwxr-xr-x 1 root root 1304 Aug 24 2000 crond
-rwxr-xr-x 1 root root 1189 Aug 30 2000 dhcpd
-rwxr-xr-x 1 root root 7663 Aug 21 2000 functions
-rwxr-xr-x 1 root root 1598 Jul 15 2000 gated
-rwxr-xr-x 1 root root 1390 Jul 28 2000 gpm
-rwxr-xr-x 1 root root 3388 Aug 2 2000 halt
-rwxr-xr-x 1 root root 1625 Aug 23 2000 httpd
-rwxr-xr-x 1 root root 1382 Jul 20 2000 identd
-rwxr-xr-x 1 news news 2538 Jul 24 2000 innd
-rwxr-xr-x 1 root root 2737 Aug 17 2000 ipchains
-rwxr-xr-x 1 root root 1130 Aug 2 2000 irda
-rwxr-xr-x 1 root root 14837 Aug 24 2000 isdn
-rwxr-xr-x 1 root root 1605 Aug 16 2000 kadmin
-rwxr-xr-x 1 root root 1084 Aug 16 2000 kdcrotate
-rwxr-xr-x 1 root root 1298 Aug 27 2000 keytable
-rwxr-xr-x 1 root root 434 Jul 24 2000 killall
-rwxr-xr-x 1 root root 1316 Aug 16 2000 kprop
-rwxr-xr-x 1 root root 1235 Aug 16 2000 krb524
-rwxr-xr-x 1 root root 1235 Aug 16 2000 krb5kdc
-rwxr-xr-x 1 root root 1427 Aug 30 2000 kudzu
-rwxr-xr-x 1 root root 2098 Aug 22 2000 ldap
-rwxr-xr-x 1 root root 609 Aug 23 2000 linuxconf
-rwxr-xr-x 1 root root 2277 Sep 25 2000 lpd
-rwxr-xr-x 1 root root 1282 Aug 5 2000 mars-nwe
-rwxr-xr-x 1 root root 1326 Aug 21 2000 mcserv
-rwxr-xr-x 1 root root 1798 Aug 30 2000 mysqld
-rwxr-xr-x 1 root root 1573 Jan 27 02:11 named
-rwxr-xr-x 1 root root 3360 Aug 22 2000 netfs
-rwxr-xr-x 1 root root 5812 Aug 6 2000 network
-rwxr-xr-x 1 root root 2257 Aug 2 2000 nfs
-rwxr-xr-x 1 root root 1722 Aug 2 2000 nfslock
-rwxr-xr-x 1 root root 2077 Aug 30 2000 nscd
-rwxr-xr-x 1 root root 1347 Aug 23 2000 ntpd
-r-xr-xr-x 1 root root 4077 Aug 22 2000 pcmcia
-rwxr-xr-x 1 root root 1388 Aug 10 2000 portmap
-rwxr-xr-x 1 root root 3081 Aug 24 2000 postgresql
-rwxr-xr-x 1 root root 1492 Aug 8 2000 pppoe
-rwxr-xr-x 1 root root 1066 Aug 18 2000 pvmd
-rwxr-xr-x 1 root root 1071 Aug 5 2000 pxe
-rwxr-xr-x 1 root root 1541 Aug 2 2000 random
-rwxr-xr-x 1 root root 1068 Aug 17 2000 rarpd
-rwxr-xr-x 1 root root 2264 Jul 24 2000 rawdevices
-rwxr-xr-x 1 root root 907 Aug 4 2000 reconfig
-rwxr-xr-x 1 root root 1734 Oct 6 2000 rhnsd
-rwxr-xr-x 1 root root 1405 Aug 5 2000 routed
-rwxr-xr-x 1 root root 1010 Aug 5 2000 rstatd
-rwxr-xr-x 1 root root 1114 Aug 5 2000 rusersd
-rwxr-xr-x 1 root root 1074 Aug 5 2000 rwalld
-rwxr-xr-x 1 root root 1007 Aug 10 2000 rwhod
-rwxr-xr-x 1 root root 1721 Aug 22 2000 sendmail
-rwxr-xr-x 1 root root 1489 Jul 24 2000 single
-rwxr-xr-x 1 root root 1502 Aug 14 2000 smb
-rwxr-xr-x 1 root root 975 Jul 20 2000 snmpd
-rwxr-xr-x 1 root root 2567 Jul 28 2000 squid
-rwxr-xr-x 1 root root 1259 Jul 17 2000 sshd
-rwxr-xr-x 1 root root 950 Dec 5 2000 sshd2
-rwxr-xr-x 1 root root 1180 Aug 7 2000 syslog
-rwxr-xr-x 1 root root 1515 Aug 1 2000 ups
-rwxr-xr-x 1 root root 942 Aug 4 2000 vncserver
-rwxr-xr-x 1 root root 2630 Aug 30 2000 xfs
-rwxr-xr-x 1 root root 1716 Oct 17 2000 xinetd
-rwxr-xr-x 1 root root 1797 Aug 20 2000 ypbind
-rwxr-xr-x 1 root root 1439 Aug 16 2000 yppasswdd
-rwxr-xr-x 1 root root 1454 Aug 16 2000 ypserv
What's going on here? System V init knows that scripts starting with an S (startup) mean to run the script when entering the runlevel specified by the directory name. For example, /etc/rc2.d is the directory containing all the S scripts (or links) to be executed upon entering run level 2. Scripts that start with K (kill) are also run upon entering a runlevel; in fact, they are executed before the S scripts. These K scripts will stop any process that may already be running, but aren't intended to be in that runlevel. By using symbolic links, any changes that need to be done to the real init scripts only need to be implemented in one place: /etc/rc.d/init.d. In addition, the two numbers after the S or K indicate the order in which the script should be run. System V init runs the scripts alphanumerically, so the order displayed by ls is the order in which they will be run.
Startup scripts can usually take one of a few arguments, that always include the words "start" and "stop," which mean exactly what they say. For example, the smb (Samba) and sshd (secure shell daemon) management scripts have these options:
# /etc/rc.d/init.d/smb
Usage: /etc/init.d/smb {start|stop|restart|status|condrestart}
# service smb # service is a shortcut to the management scripts
Usage: /etc/init.d/smb {start|stop|restart|status|condrestart}
# service sshd
Usage: sshd {start|stop|restart|condrestart|status}
#
So, when entering any runlevel, all the K scripts in the specified runlevel directory will be run with a stop argument. Then, all the S scripts in the same directory will be run with the start argument. Red Hat Linux uses the definitions for System V init runlevels listed in Table 4-19.
Runlevel
Description
0
Halt
1
Single-user mode-maintenance (clean backups/restores), repairs
2
Multiuser, without NFS
3
Multiuser mode (standard text mode login assumed)
4
Unused
5
X11 (standard X mode login as well as text mode login)
6
Reboot (never set the runlevel to this value!)
Table 19: System V init Runlevels
It should go without saying that if you set your initdefault to 0, your system will immediately halt when it comes up. Likewise, if you set the initdefault to 6, your machine will exist in a perpetual state of rebooting. Neither of these situations is desirable.
Make sure you go through the /etc/rc.d hierarchy and /etc/inittab, and /etc/rc.d/rc.sysinit files, and understand what's happening along the way. This is the key to understanding what's happening during the boot process.
The chkconfig Utility
The chkconfig command gives you a simple way to maintain the /etc/rc.d directory structure. With chkconfig, you can add, remove, and change services, list startup information, and check the state of a particular service. If you want to see which runlevels the Sendmail service is configured for, you should run:
# chkconfig --list sendmail
sendmail 0 ff 1ff 2n 3n 4n 5n 6ff
which indicates that the sendmail service is configured to run only on runlevels 2-5. If you want to turn the Sendmail service off for runlevel 4, you run:
# chkconfig --level 4 sendmail off
Now Sendmail is configured to run only on runlevels 2, 3, and 5. To turn it back on, you run the same command, substituting "on" for "off." With chkconfig, you can also add or delete services. Adding a service sets up the appropriate links within the /etc/rc.d/ hierarchy. Deleting a service removes any symbolic links in the /etc/rc.d hierarchy.
The ntsysv Utility
The ntsysv command takes the functionality of chkconfig and wraps it into an easy-to-use screen interface. By default, ntsysv configures the current runlevel. You can specify a different runlevel with the -level flag.
The ntsysv interface is extremely easy to use. Select the service you want to modify using the arrow keys. You then toggle the service on or off using the spacebar. Selecting OK will commit the changes, while selecting Cancel will cancel any changes you made (see Figure 4-7).
Figure 4-7:
ntsysv
CERTIFICATION OBJECTIVE 4.07
Virtual Consoles
Because Red Hat Linux is a multitasking operating system, it allows you to have more than one login session on the system console at a time. It supports this behavior through the virtual console system.
You switch between virtual consoles using alt-Function-key sequences. For instance, to switch to virtual console 2, hold down the alt key, and press f2. You can switch between adjacent virtual consoles by pressing alt-right arrow or alt-left arrow. For example, to move to virtual console 2 while on virtual console 3, press alt-left arrow (this does not work in X consoles). By default, Red Hat Linux comes with the first six virtual consoles configured. You can enable up to 12 virtual consoles by editing the appropriate /etc/inittab entries. Here are the default /etc/inittab entries for the first six virtual consoles:
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
Virtual consoles really bring the multiuser capabilities of Linux to life. You can be viewing a man page on one console, compiling a program in another, and editing a document in yet another virtual console.
Between X Display and Virtual Consoles
The X Display is also considered a virtual window and is assigned to the next numbered console after the text based consoles. By default, there are six virtual consoles configured with Linux, so the X Display would be assigned to console 7. However, within the Gnome or KDE, if multiple virtual desktops are configured, you switch between these multiple desktops by pressing alt-fn, where n is the number of the desktop. For four virtual desktops, you have alt-f1 (=top-left), alt-f2 (=top-right), alt-f3 (bottom-left), and alt-f4 (bottom-right) for quick access. The number of X Display desktops is configurable, but defaults to four.
To switch between X Display and virtual consoles, you are forced to use a ctrl-alt-Function-key sequence to get back to the text based virtual modes, but you only need to switch back from text to X Display by using alt-f7. You do not need the ctrl key as well when going from text console mode to X Display.
CERTIFICATION OBJECTIVE 4.08
kbdconfig, timeconfig, mouseconfig
Three screen-oriented programs included with Red Hat Linux make configuring your keyboard, system time, and mouse easier.
kbdconfig
The kbdconfig utility allows you to set the type of keyboard you have. Figure 4-8 shows the kbdconfig screen. You can use your right- and left-arrow, and pgup and pgdn keys to traverse the list of keyboards. Highlight the proper keyboard, then press the return key to accept the new setting, or the esc key to exit without saving. Changes made here are saved to the /etc/sysconfig/keyboard file.
Figure 4-8:
kbdconfig
timeconfig
The timeconfig utility allows you to set your time zone. Figure 4-9 shows the timeconfig screen. If your system clock is set to Greenwich Mean Time (GMT), select the Hardware Clock Set To GMT entry. You can use your right- and left-arrow, and pgup and pgdn keys to traverse the list of time zones. Highlight the proper time zone, then press the return key to accept the new setting, or the esc key to exit without saving. Changes made here are saved to the /etc/sysconfig/clock file.
Figure 4-9:
timeconfig
mouseconfig
The mouseconfig utility allows you to set your mouse to the correct type. Figure 4-10 shows the mouseconfig screen. You can use your right- and left-arrow, and pgup and pgdn keys to traverse the list of mouse types. Highlight the proper mouse type, then press the return key to accept the new setting, or the esc key to exit without saving. If you are using a two-button mouse, and wish to emulate three buttons (by clicking both buttons at the same time), select the Emulate 3 Buttons entry. Changes made here are saved to the /etc/sysconfig/mouse file.
Figure 4-10:
mouseconfig |
|
IP卡
狗仔卡
发表于 2003-1-19 19:03:17
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
楼主