LPI Linux Certification in a Nutshell (7 page)
Read LPI Linux Certification in a Nutshell Online
Authors: Adam Haeder; Stephen Addison Schneiter; Bruno Gomes Pessanha; James Stanger
Tags: #Reference:Computers
To determine the default runlevel at boot time,
init
reads the configuration file
/etc/inittab
looking for a line containing
the wordinitdefault, which will look
like this:
id:N:initdefault:
In the preceding,Nis a valid runlevel
number, such as 3. This number is used as the default runlevel by init.
The
S
scripts in the corresponding
/etc/rcN.d
directory are executed
to start their respective services. If you change the default runlevel
for your system, it will most likely be in order to switch between the
standard text login runlevel and the GUI login runlevel. In any case,
never change the default runlevel to 0 or 6, or your system will not
boot to a usable state.
From time to time, you might be unsure just what runlevel your
system is in. For example, you may have logged into a Linux system from
a remote location and not know how it was booted or maintained. You may
also need to know what runlevel your system was in prior to its current
runlevel—perhaps wondering if the system was last in single-user mode
for maintenance.
To determine this information, use the
runlevel
command. It displays the
previous and current runlevel as integers, separated by a space, on
standard output. If no runlevel change has occurred since the system was
booted, the previous runlevel is displayed as the letterN. For a system that was in runlevel 3 and is
now in runlevel 5, the output is:
#runlevel3 5
For a system with a default runlevel of 5 that has just completed
booting, the output would be:
#runlevelN 5
runlevel
does not alter the system runlevel.
To do this, use the
init
command (or the historical
alias
telinit
).
The
init
or
telinit
command sends signals to the executing
init
process, instructing it to change to a specified runlevel. You must be
logged in as the superuser to use the
init
command.
Generally, you will use a runlevel change for the following
reasons:
To shut down the system using runlevel 0
To go to single-user mode using runlevel 1
To reboot the system using runlevel 6
init
initn
The command puts the system into the specified
runlevel,n, which can be an integer
from 1 through 6.
init
also supportsSands, which are equivalent to runlevel 1,
andq, which tells
init
to reread its configuration file,
/etc/inittab
.
Shut down immediately:
#init 0
Reboot immediately:
#init 6
Go to single-user mode immediately:
#init 1
or:
#init s
The
telinit
command may be used
in place of
init
.
telinit
is simply a link to
init
, and the two may be used
interchangeably.
When shutdown is initiated, all users who are logged
into terminal sessions are notified that the system is going down.
In addition, further logins are blocked to prevent new users from
entering the system as it is being shut down.
shutdown []options[time]warning_message
The
shutdown
command brings the system
down in a secure, planned manner. By default, it takes the system
to single-user mode. Options can be used to halt or reboot the
system instead. The command internally uses
init
with an appropriate runlevel argument to
affect the system change.
The mandatorytimeargument tells
the shutdown command when to initiate the shutdown procedure. It
can be a time of day in the formhh:m,
or it can take the form+n, wherenis a number of minutes to wait.timecan also be the wordnow, in which case
the
shutdown proceeds immediately.
warning_messageis sent
to the terminals of all users to alert them that the shutdown will
take place. If thetimespecified is
more than 15 minutes away, the command waits until 15 minutes
remain before shutdown to make its first announcement. No quoting
is necessary inwarning_messageunless the
message includes special characters such as*or'.
- -f
Fast boot; this skips the filesystem checks on the
next boot.- -h
Halt after shutdown.
- -k
Don’t really shut down, but send the warning messages
anyway.- -r
Reboot after shutdown.
- -F
Force filesystem checks on the next boot.
To reboot immediately (not recommended on a system with
human users, because they will have no chance to save their
work):
#shutdown -r now
To reboot in five minutes with a maintenance message:
#shutdown -r +5 System maintenance is required
To halt the system just before midnight tonight:
#shutdown –h 23:59
Following are the two most common uses of shutdown by people
who are on single-user
systems
:
#shutdown –h now
and:
#shutdown –r now
These cause an immediate halt or reboots,
respectively.
Although it’s not really a bug, the
shutdown
manpage notes that omission of the
requiredtimeargument yields unusual
results. If you forget thetimeargument, the command will probably exit without an error message.
This might lead you to believe that a shutdown is starting, so
it’s important to use the correct syntax.
On the Exam
You need to be familiar with the default runlevels and the
steps that the init process goes through in switching between
them.
Installation and Package Management (Topic 102)
Many resources, such as the book
Running
Linux
(O’Reilly), describe Linux installation. This
section of the test does not cover the installation of any particular Linux
distribution; rather, its Objectives focus on four installation Topics and
packaging tools.
- Objective 1: Design Hard Disk Layout
This Objective covers the ability to design a
disk partitioning scheme for a Linux system. The
Objective includes allocating filesystems or swap space to separate
partitions or disks and tailoring the design to the intended use of
the system. It also includes placing
/boot
on a
partition that conforms with the BIOS’s requirements for booting.
Weight: 2.- Objective 2: Install a Boot Manager
An LPIC 1 candidate should be able to select, install,
and configure a boot manager. This Objective includes providing
alternative boot locations and backup boot options using either LILO
or GRUB. Weight: 2.- Objective 3: Manage Shared Libraries
This Objective includes being able to determine the
shared libraries that executable programs depend on and install them
when necessary. The Objective also includes stating where system
libraries are kept. Weight: 1.- Objective 4: Use Debian Package
Management This Objective indicates that candidates should be able
to perform package management on Debian-based systems. This indication
includes using both command-line and interactive tools to install,
upgrade, or uninstall packages, as well as find packages containing
specific files or software. Also included is obtaining package
information such as version, content, dependencies, package integrity,
and installation status. Weight: 3.- Objective 5: Use Red Hat Package Manager
(RPM) An LPIC 1 candidate should be able to use package
management systems based on RPM. This Objective includes being able to
install, reinstall, upgrade, and remove packages as well as obtain
status and version information on packages. Also included is obtaining
package version, status, dependencies, integrity, and signatures.
Candidates should be able to determine what files a package provides
as well as find which package a specific file comes from. Weight:
3.
Part of the installation process for Linux is designing the
hard disk partitioning scheme. If you’re used to systems that reside on a
single partition, this step may seem to complicate the installation.
However, there are advantages to splitting the filesystem into multiple
partitions and even onto multiple disks.
You can find more details about disks, partitions, and Linux
filesystem top-level directories in
Chapter 7
. This Topic covers
considerations for implementing Linux disk layouts.
A variety of factors influence the choice of a disk layout plan
for Linux, including:
The amount of disk space
The size of the system
What the system will be used for
How and where backups will be performed
Filesystems and partitions holding user data should be
maintained with a maximum amount of free space to accommodate user
activity. When considering the physical amount of disk space
available, the system administrator may be forced to make a trade-off
between the number of
partitions in use and the availability of free disk
space. Finding the right configuration depends on system requirements
and available filesystem resources.
When disk space is limited, you may opt to reduce the number of
partitions, thereby combining free space into a single contiguous
pool. For example, installing Linux on a PC with only 1 GB of
available disk space might best be implemented using only a few
partitions:
- /boot
50 MB. A small
/boot
filesystem in
the first partition ensures that all kernels are below the
1024-cylinder limit for older kernels and BIOS.- /
850 MB. A large root partition holds everything on the
system that’s not in
/boot
.- swap
100 MB.
On larger platforms, functional issues such as backup strategies
and required filesystem sizes can dictate disk layout. For example,
suppose a file server is to be constructed serving 100 GB of
executable data files to end users via NFS. Such a system will need
enough resources to compartmentalize various parts of the directory
tree into separate filesystems and might look like this:
- /boot
100 MB. Keep kernels under the 1024-cylinder limit.
- swap
1 GB, depending on RAM.
- /
500 MB (minimum).
- /usr
4 GB. All of the executables in
/usr
are shared to workstations via read-only NFS.- /var
2 GB. Since log files are in their own partition, they
won’t threaten system stability if the filesystem is
full.- /tmp
500 MB. Since temporary files are in their own partition,
they won’t threaten system stability if the filesystem is
full.- /home
90 GB. This big partition takes up the vast bulk of
available space, offered to users for their home directories and
data.
On production servers, much of the system is often placed on
redundant media, such as mirrored disks. Large filesystems, such as
/home
, may be stored on some form of disk array
using a hardware controller.
Before you may access the various filesystem partitions
created on the storage
devices
,
you first must list them in a filesystem table. This process is
referred to as
mounting
, and the directory you
are mounting is called a
mount point
. You must
create the directories that you will use for mount points if they do
not already exist. During system startup, these directories and mount
points may be managed through the
/etc/fstab
file, which contains the information about filesystems to mount when
the system boots and the directories that are to be mounted.
A superblock is a block on each filesystem that contains
metadata information about the
filesystem layout. The information contained in the
block includes the type, size, and status of the mounted filesystem.
The superblock is the Linux/Unix equivalent to Microsoft systems’ file
allocation table (FAT), which contains the information about the
blocks holding the top-level directory. Since the information about
the filesystems is important, Linux filesystems keep redundant copies
of the superblock that may be used to restore the filesystem should it
become corrupt.
The master boot record (MBR) is a very small program
that contains information about your hard disk partitions and loads
the operating system. This program is located in the first sector of
the hard disk and is 512 bytes. If this file becomes damaged, the
operating system cannot boot. Therefore, it is important to back up
the MBR so that you can replace a damaged copy if needed. To make a
backup of the MBR from the hard drive and store a copy to your
/home
directory, use the
dd
command. An example of such a
backup command is:
dd if=/dev/hda of=~/mbr.txt count=1 bs=512
The preceding example assumes that your hard drive is
/dev/hda
. With this command you are taking one
copy (count=1) consisting of 512
bytes (bs=512) from
/dev/hda
(if=/dev/hda) and copying it to a file named
mbr.txt
in
/home
(of=~/mbr.txt).
If you need to restore the MBR, you may use the following
command:
dd if=~/mbr.txt of=/dev/hda count=1 bs=512
Linux may be booted from a Live USB, similar to booting
from a Live CD. One difference between booting to the USB opposed to
the CD is that the data on the USB device may be modified and stored
back onto the USB device. When using a Live USB distribution of Linux,
you can take your operating system, favorite applications, and data
files with you wherever you go. This is also useful if you have
problems and are not able to boot your computer for some reason. You
may be able to boot the system using the Live USB and access the hard
drive and troubleshoot the boot issue.
In order to boot from the USB device, you will need to make the
USB device bootable. This requires setting up at least one partition
on the USB with the bootable flag set to the primary partition. An MBR
must also write to the primary partition on the USB. There are many
applications that can be used to create live USB distributions of
Linux, including Fedora Live USB Creator and Ubuntu Live USB Creator.
The computer may also need the BIOS to be configured to boot from
USB.
Some older computers may not have support in the BIOS to boot
from a USB device. In this case it is possible to redirect the
computer to load the operating system from the USB device by using an
initial
bootable CD. The bootable CD boots the
computer
, loads the necessary USB
drivers into memory, and then locates and loads the filesystem from
the USB device.
The role of the system should also dictate the optimal
disk layout. In a traditional Unix-style network with NFS file
servers, most of the workstations won’t necessarily need all of their
own executable files. In the days when disk space was at a premium,
this represented a significant savings in disk space. Although space
on workstation disks isn’t the problem it once was, keeping
executables on a server still eliminates the administrative headache
of distributing updates to workstations.
Some backup schemes use disk partitions as the basic
unit of system backup. In such a scenario, each of the filesystems
listed in
/etc/fstab
is backed up separately, and
they are arranged so that each filesystem fits within the size of the
backup media. For this reason, the available backup device
capabilities can play a role in determining the ultimate size of
partitions.
Using the
dd
command as discussed earlier,
you can back up each of the individual partitions. The command may
also be used to back up the entire hard drive. To back up a hard drive
to another hard drive, you would issue the following command, whereif=/dev/hdxrepresents the hard
drive you want to back up andof=/dev/hydrepresents the target or
destination drive of the backup:
dd if=/dev/hdx of=/dev/hyd
If you are just interested in making a backup of the partition
layout, you can also use the
sfdisk
command to
create a copy of the partition table:
sfdisk -d /dev/hda > partition_backup.txt
Then, if you need to restore the partition table, you can use
the
sfdisk
command again:
sfdisk /dev/hda < partition_backup.txt
When you install Linux, you’re asked to configure a
swap
, or
virtual memory
, partition. This
special disk space is used to temporarily store portions of main memory
containing programs or program data that are not needed constantly,
allowing more processes to execute concurrently. An old rule of thumb
for Linux is to set the size of the system’s swap space to be double the
amount of physical RAM in the machine. For example, if your system has
512 MB of RAM, it would be reasonable to set your swap size to at least
1 GB. These are just guidelines, of course. A system’s utilization of
virtual memory depends on what the system does and the number and size
of processes it runs. As hard disk and memory gets cheaper and Linux
application footprints grow, the guidelines for determining swap sizes
become more and more about personal preference. However, when in doubt,
using twice the amount of main memory is a good starting point.
Here are some guidelines for partitioning a Linux
system:
Keep the root filesystem (
/
) simple by
distributing larger portions of the directory tree to other
partitions. A simplified root filesystem is less likely to be
corrupted
.Separate a small
/boot
partition below
cylinder 1024 for installed kernels used by the system boot loader.
This does not apply to newer BIOS and kernels (e.g., 2.6.20).Separate
/var
. Make certain it is big
enough to handle your logs, spools, and mail, taking their rotation
and eventual deletion into account.Separate
/tmp
. Its size depends on the
demands of the applications you run. It should be large enough to
handle temporary files for all of your users
simultaneously
.Separate
/usr
and make it big enough to
accommodate kernel building. Making it standalone allows you to
share it read-only via NFS.Separate
/home
for machines with multiple
users or any machine where you don’t want to affect data during
distribution software upgrades. For even better performance (for
multiuser environments), put
/home
on a disk
array and use Logical Volume manager (LVM).Set swap space to at least the same size (twice the size is
recommended) as the main memory.
On the Exam
Since a disk layout is the product of both system requirements
and available
resources
, no
single example can represent the best configuration. Factors to
remember include placing the old 2.2.x kernel below cylinder 1024,
effectively utilizing multiple disks, sizing partitions to hold
various directories such as
/var
and
/usr
, and the importance of the root filesystem
and swap space size.
