LPI Linux Certification in a Nutshell (11 page)
Read LPI Linux Certification in a Nutshell Online
Authors: Adam Haeder; Stephen Addison Schneiter; Bruno Gomes Pessanha; James Stanger
Tags: #Reference:Computers
rpm
rpm-i[options]
(also rpm --install)
rpm-U[options] (also rpm --upgrade)
rpm-e[options] (also rpm --uninstall)
rpm-q[options] (also rpm --query)
rpm-V[options] (also rpm --verify)
The
install mode
(
rpm
-i
) is used to install new packages. A variant of install
mode is the
upgrade mode
(
rpm
-U
), where an installed package is upgraded to a more
recent version. Another variant is the
freshen mode
(
rpm
-F
), which upgrades only packages that have an older
version already installed on the system. But
rpm
’s
-F
option has
limited value, since it doesn’t handle
dependency
changes at all. In other
words, if a new version of a package requires that another package
be installed,
-F
won’t automatically install
the new package, even if it is listed on the command line.
- --force
Allows the replacement of existing packages and of files
from previously installed packages; for upgrades, it allows
the replacement of a newer package with an older one.
(Literally, it is equivalent to setting all of the options
--replacepkgs
,
--replacefiles
, and
--oldpackage
.)
Use this option with caution
.- -h
(also
--hash
) Prints a string of 50 hash marks (
#) during installation as a progress
indicator.- --nodeps
Allows you to install a package without checking for
dependencies.
This command should be avoided because
it makes the dependency database
inconsistent
.- --test
Runs through all the motions except for actually writing
files; it’s useful to verify that a package will install
correctly prior to making the attempt. Note that verbose and
hash options cannot be used with
--test
,
but
-vv
can.- -v
Sets verbose mode. (Package names are displayed as the
packages are being installed.)- -vv
Sets really verbose mode. The manpage describes this as
“print lots of ugly debugging information.”
To install a new package, simply use the
rpm
-i
command with the name of a package file. If the new
package depends upon another package, the install fails, like
this:
#rpm -i gcc-2.96-113.i386.rpmerror: failed dependencies:
binutils >= 2.11.93.0.2-6 is needed by gcc-2.96-113
cpp = 2.96-113 is needed by gcc-2.96-113
glibc-devel is needed by gcc-2.96-113
To correct the problem, the dependency must first be
satisfied. In this example,
gcc
is dependent on
binutils, cpp
, and
glibc-devel
, which all must be installed first
(or at the same time, as in this example):
#rpm -i binutils-2.11.93.0.2-11.i386.rpm cpp-2.96-113.i386.rpm \glibc-devel-2.2.5-44.i386.rpm gcc-2.96-113.i386.rpm
Upgrading an existing package to a newer version can be done
with the
-U
option. Upgrade mode is really a
special case of the install mode, where existing packages can be
superseded by newer versions. Using
-U
, a
package can be installed even if it doesn’t already exist, in which
case it behaves just like
-i
:
#rpm -U gcc-2.96-113.i386.rpm
This mode is used to remove installed packages from
the system. By default,
rpm
uninstalls a
package only if no other packages depend on it.
- --nodeps
rpm
skips dependency checking with
this option enabled.
This command should be avoided
because it makes the dependency database
inconsistent
.- --test
This option runs through all the motions except for
actually uninstalling things; it’s useful to verify that a
package can be uninstalled correctly without breaking other
dependencies prior to making the attempt. Note that verbose
and hash options cannot be used with
--test
, but
-vv
can.
Package removal is the opposite of installation and has the
same dependency constraints:
#rpm -e glibc-develerror: removing these packages would break dependencies:
glibc-devel is needed by gcc-2.96-113
Installed packages and raw package files can be
queried using the
rpm -q
command. Query mode
options exist for package and information selection.
- -a (also --all)
Display a list of all packages installed on the system.
This is particularly useful when piped to
grep
if you’re not sure of the name of a
package or when you want to look for packages that share a
common attribute.- -f
filename(also
--file
) Display the package that contains a particular
file.- -p
package_filename Query a package file (most useful with
-i
, described next).
- -c (also --configfiles)
List only configuration files.
- -d (also --docfiles)
List only documentation files.
- -i
package Not to be confused with the
install
mode
. Display information about an installed
package, or when combined with
-p
, about
a package file. In the latter case,packageis a filename.- -l
package(also --list) List all of the files contained in
package. When used with
-p
, thepackageis a filename.- -R (also --requires)
List packages on which this package depends.
To determine the version of the software contained in an RPM
file, use the query and package information options:
#rpm -qpi openssh-3.4p1-2.i386.rpm | grep VersionVersion : 3.4p1 Vendor: Red Hat, Inc.
For installed packages, omit the
-p
option and specify a package name instead of a package filename.
Notice if you have multiple versions of the same package installed,
you will get output for all of the packages:
#rpm -qi kernel-source | grep VersionVersion : 2.4.9 Vendor: Red Hat, Inc.
Version : 2.4.18 Vendor: Red Hat, Inc.
Version : 2.4.18 Vendor: Red Hat, Inc.
List the files contained in a package:
#rpm -qlp gnucash-1.3.0-1.i386.rpm/usr/bin/gnc-prices
/usr/bin/gnucash
/usr/bin/gnucash.gnome
/usr/doc/gnucash
/usr/doc/gnucash/CHANGES
(...output continues ...)
For an installed package, enter query mode and use the
-l
option along with the package name:
#rpm -ql kernel-source/usr/src/linux-2.4.18-14
/usr/src/linux-2.4.18-14/COPYING
/usr/src/linux-2.4.18-14/CREDITS
/usr/src/linux-2.4.18-14/Documentation
/usr/src/linux-2.4.18-14/Documentation/00-INDEX
/usr/src/linux-2.4.18-14/Documentation/BUG-HUNTING
/usr/src/linux-2.4.18-14/Documentation/Changes
(...output continues ...)
List the documentation files in a package:
#rpm -qd at/usr/doc/at-3.1.7/ChangeLog
/usr/doc/at-3.1.7/Copyright
/usr/doc/at-3.1.7/Problems
/usr/doc/at-3.1.7/README
/usr/doc/at-3.1.7/timespec
/usr/man/man1/at.1
/usr/man/man1/atq.1
/usr/man/man1/atrm.1
/usr/man/man1/batch.1
/usr/man/man8/atd.8
/usr/man/man8/atrun.8
Use
-p
for package filenames.
List configuration files or scripts in a package:
#rpm -qc at/etc/at.deny
/etc/rc.d/init.d/atd
Determine what package a particular file was installed from.
Of course, not all files originate from packages:
#rpm -qf /etc/fstabfile /etc/fstab is not owned by any package
Those that are package members look like this:
#rpm -qf /etc/aliasessendmail-8.11.6-15
List the packages that have been installed on the
system:
#rpm -qa(... hundreds of packages are listed ...)
To search for a subset withkernelin the name, pipe the previous
command togrep:
#rpm -qa | grep kernelkernel-source-2.4.18-24.7.x
kernel-pcmcia-cs-3.1.27-18
kernel-utils-2.4-7.4
kernel-doc-2.4.18-24.7.x
kernel-2.4.18-24.7.x
Files from installed packages can be compared against
their expected configuration from the RPM database by using
rpm -V
.
- --nofiles
Ignores missing files.
- --nomd5
Ignores MD5 checksum errors.
- --nopgp
Ignores PGP checking errors.
On the Exam
Make certain that you are aware of
rpm
’s major operational modes and their
commonly
used mode-specific
options. Knowledge of specific options will be necessary. Read
through the
rpm
manpage at least once.
(Topic 103)
This Topic covers the essential skill of working interactively with
Linux command-line utilities. Although it’s true that GUI tools are
available to manage just about everything on a Linux system, a firm
understanding of command-line utilities is required to better prepare you to
work on any LSB-compliant Linux distribution.
The family of commands that are part of Linux and Unix systems have a
long history. Individuals or groups that needed specific tools contributed
many of the commands in the early days of Unix development. Those that were
popular became part of the system and were accepted as default tools under
the Unix umbrella. Today, Linux systems carry new and often more powerful
GNU
versions of these historical commands, which are
covered in LPI Topic 103.1.
This LPI Topic has eight Objectives:
- Objective 1: Work on the Command Line
This Objective states that a candidate should be able to
interact with shells and commands using the command line. This
includes using single shell commands and one-line command sequences to
perform basic tasks on the command line, using and modifying the shell
environment, including defining, referencing, and exporting
environment variables, using and editing command history, and invoking
commands inside and outside the defined path. Weight: 4.- Objective 2: Process Text Streams Using
Filters This Objective states that a candidate should be able to
apply filters to text streams. Tasks include sending text files and
output streams through text utility filters to modify the output, and
using standard Unix commands found in the GNU
coreutils
package. Weight: 3.- Objective 3: Perform Basic File
Management This Objective states that candidates should be able to
use the basic Linux commands to copy, move, and remove files and
directories. Tasks include advanced file management operations such as
copying multiple files recursively, removing directories recursively,
and moving files that meet a wildcard pattern. The latter task
includes using simple and advanced wildcard specifications to refer to
files, as well as using
find
to locate and act on
files based on type, size, or time. This also includes usage of the
commands
tar, cpio
, and
dd
for archival purposes. Weight: 4.- Objective 4: Use Streams, Pipes, and
Redirects This Objective states that a candidate should be able to
redirect streams and connect them to efficiently process textual data.
Tasks include redirecting standard input, standard output, and
standard error, piping the output of one command to the input of
another command, using the output of one command as arguments to
another command, and sending output to both
stdout
and a file. Weight: 4.- Objective 5: Create, Monitor, and Kill
Processes This Objective states that a candidate should be able to
manage processes. This includes knowing how to run jobs in the
foreground and background, bring a job from the background to the
foreground and vice versa, start a process that will run without being
connected to a terminal, and signal a program to continue running
after logout. Tasks also include monitoring active processes,
selecting
and sorting processes for
display, sending signals to processes, and killing processes. Weight:
4.- Objective 6: Modify Process Execution
Priorities This Objective states that a candidate should be able to
manage process execution priorities. The tasks include running a
program with higher or lower priority, determining the priority of a
process, and changing the priority of a running process. Weight:
2.- Objective 7: Search Text Files Using Regular
Expressions This Objective states that a candidate should be able to
manipulate files and text data using regular expressions. This
includes creating simple regular expressions containing several
notational elements, as well as using regular
expression
tools to perform searches
through a filesystem or file content.
Weight: 2
.- Objective 8: Perform Basic File Editing Operations Using
vi This Objective states a candidate should be able to edit
files using
vi
. This includes
vi
navigation, basic
vi
modes, and inserting, editing, deleting, copying, and finding text.
Weight: 3.
The tools and concepts discussed here represent important and
fundamental aspects of working with Linux and are essential for your success
on Exam 101.
Every computer system requires a human interface component.
For Linux system administration, a text interface is typically used. The
system presents the administrator with a
prompt
, which at its simplest is a
single character such as$or#. The prompt signifies
that the system is ready to accept typed commands, which usually occupy
one or more lines of text. This interface is generically called the
command line
.
It is the job of a program called a
shell
to
provide the command prompt and to interpret commands. The shell provides
an interface layer between the Linux kernel and the end user, which is how
it gets its name. The original shell for Unix systems was written by
Stephen Bourne and was called simply
sh
. The default Linux shell is
bash
, the
Bourne-Again
Shell
, which is a GNU variant of
sh
. This
chapter will not cover all aspects of the
bash
shell.
At this point, we are primarily concerned with our interaction with
bash
and the effective use of commands.
The shell is a powerful programming environment, capable
of automating nearly anything you can imagine on your Linux system. The
shell is also your interactive interface to your system. When you first
start a shell, it does some automated housekeeping to get ready for your
use, and then presents a command prompt. The command prompt tells you
that the shell is ready to accept commands from its
standard
input
device, which is usually the keyboard. Shells can run
standalone, as on a physical terminal, or within a window in a GUI
environment. Whichever the case, their use is the same.
During execution,
bash
maintains a
set of
shell variables
that contain information
important to the execution of the shell. Most of these variables are
set when
bash
starts, but they can be set
manually at any time.
The first shell variable of interest in this topic is called
PS1, which simply stands for
Prompt String
1
. This special variable holds the contents of the command
prompt that are displayed when
bash
is ready to
accept commands (there is also a PS2 variable, used when
bash
needs multiple-line input to complete a
command). You can easily display the contents of PS1, or any other
shell variable, by using theechocommand with the
variable name preceded by the$symbol:
$echo $PS1\$
The\$output tells us that
PS1 contains the two characters\and$. The backslash character
tells the shell not to interpret the dollar symbol in any special way
(that is, as a
metacharacter
, described later in
this section). A simple dollar sign was the default prompt for
sh
, but
bash
offers options
to make the prompt much more informative. On your system, the default
prompt stored in PS1 is probably something like:
[\u@\h \W]\$
Each of the characters preceded by backslashes has a special
meaning to
bash
, whereas those without
backslashes are interpreted literally. In this example,\uis replaced by the username,\his replaced by the system’s hostname,\Wis replaced by the unqualified
path (or basename) of the current working directory, and\$is replaced by a$character (unless you are
root
, in which case\$is replaced by#). This yields a prompt of the form:
[adam@linuxpc adam]$
How your prompt is formulated is really just a convenience and
does not affect how the shell interprets your commands. However,
adding information to the prompt, particularly regarding system, user,
and directory location, can make life easier when hopping from system
to system and logging in as multiple users (as yourself and
root
, for example). See the
online documentation on
bash
for more information on customizing
prompts, including many more options you can use to display system
information in your prompt.
Another shell variable that is extremely important during
interactive use isPATH, which
contains a list of all the directories that hold commands or other
programs you are likely to execute. A default path is set up for you
when
bash
starts. You may wish to modify the
default to add other directories that hold programs you need to
run.
Every file in the Linux filesystem can be specified in terms
of its location. The
less
program, for example,
is located in the directory
/usr/bin
. Placing
/usr/bin
in yourPATHenables you to execute
less
by simply typinglessrather than the explicit/usr/bin/less.
Also be aware that "
.
" (the current
directory) is not included in thePATHeither implicitly (as it is in
DOS
) or explicitly for security reasons. To
execute a program named
foo
in the current
directory, simply run./foo.
For
bash
to find and execute the command
you enter at the prompt, the command must be one of the
following:
A
bashbuilt-in
command that is part of
bash
itselfAn executable program located in a directory listed in the
PATHvariableAn executable program whose filename you specify
explicitly
The shell holdsPATHand
other variables for its own use. However, many of the shell’s
variables are needed during the execution of programs launched from
the shell (including other shells). For these variables to be
available, they must be
exported
, at which time
they become
environment variables
. Environment
variables are passed on to programs and other shells, and together
they are said to form the
environment
in which
the programs execute.PATHis
always made into an environment variable. Exporting a shell variable
to turn it into an environment variable is done using the
export
command:
$export MYVAR
Do not include a preceding dollar sign when defining or
exporting a variable (because in this command, you don’t want the
shell to expand the variable to its value). When a variable is
exported to the environment, it is passed into the environment of all
child processes. That is, it will be available to all programs run by
your shell. Here is an example that displays the difference between a
shell variable and an environment variable:
$echo $MYVAR
No output is returned, because the variable has not been
defined. We give it a value, and then echo its value:
$MYVAR="hello"$echo $MYVARhello
We’ve verified that the variableMYVARcontains the value “hello”. Now we
spawn a subshell (or child process) and check the value of this
variable:
$bash$echo $MYVAR
Typing
bash
spawned another copy of the
bash shell. This child process is now our current environment, and as
you can see from the blank line that ends the example, the variableMYVARis not defined here. If we
return to our parent process and export the variable, it becomes an
environment variable that can be accessed in all child
processes:
$exit$export MYVAR$bash$echo $MYVARhello
Typing the
export
command without any
arguments will display all of the exported environment variables
available to your shell. The
env
command will accomplish the
same thing, just with slightly different output.
Along the same lines are the bash built-in commands
set
and
unset
. The command
set
with no arguments will display of list of
currently set environment variables. The command
unset
will allow you to clear the value of an
environment variable (assuming it is not read-only). The
set
command also gives you the ability to change
the way
bash
behaves. The following are some
examples of using
set
to modify your interactive
shell.
To change to
vi
-style editing mode:
$set –o vi
This example automatically marks variables that are modified or
created for export to the environment of subsequent commands:
$set –o allexport
To view the current settings for the variables that
set
can modify, run
set
–o
.
Commands issued to the shell on a Linux system generally consist
of four
components
:
A valid command (a shell built-in, program, or script found
among directories listed in thePATH, or an explicitly defined
program)Command options, usually preceded by a dash
Arguments
Line acceptance (i.e., pressing the Enter key), which we
assume in the examples
Each command has its own unique syntax, although most follow a
fairly standard form. At minimum, a
command
is
necessary:
$ls
This simple command lists the contents of the current working
directory. It requires neither options nor arguments. Generally,
options
are letters or words
preceded by a
single or
double dash and are added after the command and
separated from it by a space:
$ls -l
The
-l
option modifies the behavior of
ls
by listing files in a longer,
more detailed format. In most cases, single-dash options can be either
combined or specified separately. To illustrate this, consider these
two equivalent commands:
$ls -l -a$ls -la
By adding the
-a
option,
ls
displays files beginning with a dot (which it
hides by default). Adding that option by specifying
-la
yields the same result. Some commands offer
alternative forms for the same option. In the preceding example, the
-a
option
can be replaced with
--all
:
$ls -l --all
These double-dash, full-word options are frequently found in
programs from the GNU project. They cannot be combined like the
single-dash options can. Both types of options can be freely
intermixed. Although the longer GNU-style options require more typing,
they are easier to remember and easier to read in scripts than the
single-letter options.
Adding an
argument
further refines the
command’s behavior:
$ls -l *.c
Now the command will give a detailed listing only of C program
source files, if any exist in the current working directory.
Using the asterisk in
*.c
allows any file
to match as long as it ends with a
.c
extension. This is known as
file globbing
. More
information on file globbing and using wildcards can be found later
in this chapter.
Sometimes, options and arguments can be mixed in any
order:
$ls --all *.c -l
In this case,
ls
was able to determine that
-l
is an option and not another file
descriptor
.
Some commands, such as
tar
and
ps
, don’t require the dash
preceding an option because at least one option is expected or
required. To be specific,
ps
doesn’t require a
dash when it is working like BSD’s version of
ps
.
Since the Linux version of
ps
is designed to be
as compatible as possible with various other versions of
ps
, it sometimes does need a dash to distinguish
between conflicting options. As an example, try
ps
-e
and
ps e
. The first version invokes
a Linux-specific option that shows everyone’s processes, not just your
own. The second version invokes the original BSD option that shows the
environment variables available to each of your commands.
Also, an option often instructs the command that the subsequent
item on the command line is a specific argument. For example:
$sort name_list$sort –k 2 name_list
These commands invoke the
sort
command to sort the lines in
the file
name_list
. The first
command just sorts beginning with the first character of each line,
whereas the second version adds the options-k 2. The-koption tells the command to break each
line into fields (based on whitespace) and to sort the lines on a
particular field. This option requires a following option to indicate
which field to sort on. In this case, we have told
sort
to sort on the second field, which is useful
if
name_list
contains people’s
names in a “Joe Smith” format.
Just as any natural language contains exceptions and variations,
so does the syntax used for GNU and Unix commands. You should have no
trouble learning the
essential
syntax for the commands you need to use often. The capabilities of the
command set offered on Linux are extensive, making it highly unlikely
that you’ll memorize all of the command syntax you’ll ever need. Most
system administrators are constantly learning about features they’ve
never used in commands they use regularly. It is standard practice to
regularly refer to the documentation on commands you’re using, so feel
free to explore and learn as you go.
