This lesson introduces the student to concepts that are
important to understanding what happens when a Linux system
starts. Objectives important to this lesson:
Predicting resource needs
The chapter begins by confusing the reader with a section on user
notifications, which is the last item in its
list of objectives. The list, on inspection, is arranged in the
order of objective numbers, not in the order of presentation. Oh,
well. Let's follow the author.
The author tells us that Linux includes six utilities that can be
used to communicate information to users. She discusses each of
them, starting with the last one in her list.
/usr/bin/wall - Unlike email, the wall
utility can only be used to communicate with logged in users.
Also, users must have their mesg status set to
y (yes), and must have a terminal window open. If a user's mesg
status is set to n (no), the wall utility cannot write to that
user's terminal/device, unless wall is being used by a user with
root permissions. Wall can take input from the keyboard of the
person sending the massage, or it can be fed the name of a text
file as an argument. The message is broadcast to all available
/bin/notify-send - This one requires
super-user privileges, and the syntax is much more complicated,
as shown on page 43. Read the explanation below the example on
that page. Note that the display of the message is prettier, but
using this utility is a good deal harder when it is something
you don't do a lot. The video below simplifies it better than
/sbin/shutdown -This one is used on servers
to alert users of a reboot, shutdown, or other emergent event.
It includes the option of sending a wall message to users that
will ignore the state of their mesg settings. Like wall, the
message only reaches uses who have a terminal window open.
/etc/issue - This one sends a message that
users see on their terminal login screen. It is not immediate
(fluid) like the first three utilities. Three variants on the
utility are discussed, /etc/issue, /etc/issue.net (for web based
logins), and /etc/motd (message of the day)
The author turns to issues related to backups.
For a VM that you only run for practice, this is not an issue, but
for a VM or a full installation that you use for a business need,
backups are a reality. Several concepts are covered quickly:
classification of data to prioritize backup
and restoration requirements - Data is bound to fall into
several categories. You may want to begin by asking business
owners how long they can wait for a data restore? A month? Low
priority. A week? Medium. Need it now? High priority. How out of
date can the data be? The less important the data is,the longer
you can wait between backups.
Backup media, backup storage locations,
backup frequency are all topics that need
discussion and regular review. Do we make live backups
electronically? Are we happy with less frequent backups to tape
or hard drive? Do we store the backups off site?
Recovery is the process of restoring
lost data. To understand the following understand
this: an Archive bit is a bit in a file that
is turned ON when the file is changed;
it is used to flag files that have changed since the last
Standard backup schemes:
Full - a backup of all files
in the target; sets the archive bit of each file to OFF
once the backup is made
Incremental - a backup of target
files that are new or changed since the last
backup; depends on the fact that programs that change files
typically set the archive bit to ON when a
change is made; sets archive bit to OFF for
all files it copies
Differential - a backup of all files
new or changed since the last Full
backup; copies all files whose archive bit is set to ON;
does not change the archive bit of files it
copies because they will be copied again in the next
Copy - like a Full backup, but it does
not change the archive bits of files it
copies. This is typically not part of a standard backup
strategy, but an option to work around the system. It is like
the scheme that the text calls continuous backup.
To keep them straight in your mind, remember these facts:
What does it back up?
What does it do to the archive bit?
Resets all archive bits.
everything different from the last backup
Resets the archive bits of files it copies.
copies everything "different from Full"
(Different from the last Full backup.)
Does not reset any archive bits.
makes a Full backup
Does not reset any archive bits.
The time required to create backups should be
considered along with the time to restore a backup. When
you consider the two concepts as two sides of the answer to a
question (What method should I use?), the answer may be the most
common choice: Differential. It is the best compromise in
terms of backup time versus restore time. Note also, that all
standard methods require a full backup on a regular cycle. The
recommendation is usually to run a Full backup weekly.
The text offers a list of directories that you may want to back
up. The list is longer than you might think, because it contains
some that the author does not recommend for
backup. The text also discusses using the tar
utility (tape archiver) to make backups. It is easiest to
understand tar if I tell you it is a predecessor of zip files. The
text discusses some options for using it, but it is a little hard
to follow. Tar does not have to include compression, but it makes
little sense to create a tar file without compression. See the
On page 72, the topic changes to program installation. This
relates to the discussion of tar in that you may have to download
a tar compressed package, unpack it,
read installation notes, compile the
source code to machine code, and move the "binaries"
to locations where your users will find them. (Binaries are
machine language files, typically built by compiling them on a
system on which they will be used.) In addition to placing the
binaries in good folders (typically bin folders), you should set
permissions that make them executable, which you probably know how
The last major topic in the chapter is measuring resource usage,
which is another way of saying measuring system performance. Page
79 lists several items to measure, which you should consider, and
the next two pages list several utilities that can measure how
these resources are being used. The author specifically recommends
the sar utility, the system activity reporter. It reports data
collected by the sadc utility, the system activity data collector.
That should be enough for this week.
Week 2 Assignment: Hardening your server
Lab 2: Harden
your CentOS machine, using the provided link to
recommendations for doing so. Document what you do, and
turn in your lab report by 6pm next Monday.