ITS 2330 - Linux III

Chapter 2, Maintaining the System

Objectives:

This lesson introduces the student to concepts that are important to understanding what happens when a Linux system starts. Objectives important to this lesson:

  1. Resource usage
  2. Predicting resource needs
  3. Installing programs
  4. Backup
  5. Notifying users
Concepts:

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 users.
  • /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 the text.



  • /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 backup.
    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 differential backup
    • 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:

Backup type What does it back up? What does it do to the archive bit?
Full copies everything Resets all archive bits.
Incremental everything different from the last backup Resets the archive bits of files it copies.
Differential copies everything "different from Full"
(Different from the last Full backup.)
Does not reset any archive bits.
Copy 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 video below.


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 to do.

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.