Red Hat Linux 7 Unleashed

Red Hat Linux 7 Unleashed

By William Ball

Performing System Maintenance

The overall function of a system administrator is to keep the system up and running. Not only does this mean applying the latest software updates, adding and replacing hardware, and adding new software, but it also means being part soothsayer, part instructor, and part detective. The system administrator must

Each of these tasks can be daunting. For example, it takes years of training and practice to understand completely how everything in Linux works, and just about the time you figure out everything, it changes.

The first task is the reason for this book and is covered throughout. The other five items are examined in more detail in the following sections.

Planning Processes

Red Hat is a complex operating system. Many files and processes are dependent upon other files and processes. Therefore, when you are preparing to make a change to the system, it only makes sense to define a process for the task. The amount of planning and documenting required for the task should obviously depend on the complexity of the task, but it should at least touch on the following items:

Creating a Back-Out Plan

Creating the back-out plan is the most important part of making a change to a system. In determining the back-out plan, consider the time required to perform the task, the time required to test the change, and the time required to back out of the current process and return to the former process. An important part of the back-out plan is a decision point—a predetermined point when you decide to continue with the current process or to implement the back-out plan. This could be a decision based on a time limit, a lack of system resources, malfunctioning equipment, poorly written software, or another problem that requires returning to the former process.

Making Changes in Small Increments

It is easier to back out of small changes than it is to back out of big and multiple changes. It is also easier to plan a series of smaller changes than it is to plan one large change. Diagnosing problems is considerably easier when fewer things are changed than when a large number of things are changed. The job becomes much simpler if you can break a task down into several small tasks, each with individual test plans and back-out plans.

Developing a Test Plan

You must test each system change. Even a small change, such as moving a file from one location to another, should have a test plan. The test plan should be appropriate to the task. In the example of moving a file, the test plan could be as simple as the following:

  1. Are users or processes dependent upon the file?
  2. If yes, can the users or processes still access the file?
  3. If no, make it available (change permissions, add directory to path, create link, and so on).
  4. Does the file do what it is supposed to do?
  5. If yes, okay; if no, fix and retest.

A task as simple as moving a file requires five steps to properly test. Imagine the difficulty of testing a large change.

Communicating Effectively and in a Timely Manner

Communicating the result of changes to the system is the final element of a successful system change. Success does not necessarily mean that the task was completed without errors. In fact, it could mean that the task could not be completed and the back-out plan was successfully implemented. Communication also means letting the users know in advance about a change that affects them.

Communication, on a larger level, is information passed between one user and another, whether it's one-way communication or a dialog. Although it is imperative to have this communication before, during, and after a system change, communication does not have to stop nor should it stop there. Some system administrators communicate announcements, local news, jokes, and just about anything else to users on a regular basis.

You can use many different tools to communicate with users. To decide which tool to use, you need to determine the purpose of the communication. For example, if you are about to shut down a system, you need to communicate that information only to the users currently logged in to the system. If, on the other hand, you want to announce a birthday, you need to announce that information either to all users or to all users who log in to the system that day. Perhaps a user is remotely logged in to a system and is having problems. A user with only one phone line cannot call in the problem without disconnecting. This situation requires an entirely different form of communication. The following sections discuss several different tools for communication; some are commands, and others are concepts. In addition, examples illustrate which tool is best for that particular need. The following communication tools are discussed in the upcoming sections:

write

The write command enables a user to write a message to another user's terminal. The syntax is the command followed by the user ID of the person to whom you want to write. This places you in a write shell; you cancel the write shell by pressing Ctrl+C. You type a message and press Enter and the text is displayed on the other user's terminal.

CAUTION

A message is lost if the sender presses Ctrl+C after typing in the message without pressing Enter.

For example, I tried to write a message to my friend Shaggy.

[scooby@cartoons]$ write shaggy
Hello Shaggy.  How are you today?
[scooby@cartoons]$

I didn't receive a reply.

I wasn't sure that I was doing it right, so I tried to send a message to myself. Before I did, I turned off my mesg (mesg n). Here's what happened:

[scooby@cartoons]$ write scooby
write: you have write permission turned off.

As a further test, I turned my mesg on (mesg y) and tried again:

[scooby@cartoons]$ mesg y
[scooby@cartoons]$ write scooby

Message from scooby@cartoons on ttyp0 at 20:10 ...
hello
hello
It enters what I type, and then echoes it back to me.
It enters what I type, and then echoes it back to me.
type <ctrl>c
type <ctrl>c
EOF
[scooby@cartoons]$

It displayed everything that I typed and then echoed it back to me with write. Had this gone to another terminal when I typed and pressed Enter, the message would have been sent to the indicated user.

You will notice that when I received the message, I got an initial line that told me who the message was from, the tty (terminal type) I was on, and the time local to the server:

Message from scooby@cartoons on ttyp0 at 20:10 ...

Pressing Ctrl+C disconnected me from the write program, indicated by the last line showing the end of the file (EOF).

wall

Administrators sometimes need to send a message to all users currently logged in to the system. This type of communication is typically used when the administrator needs to inform everyone about something that affects them. The wall command is typically used when a system is about to shut down. Instead of just blowing everyone off the system, the system administrator might want to give users time to close their applications and save their data.

The wall command is short for write all. Just like the write command, it only sends the text to the terminal, and the computer does not treat the text as input from that user. The standard for wall is that it gets its information to display from the user's input. You can either use this method or use a less-than sign to send it information directly from a file.

In the following example, I have a small file that says system shutting down! The system was not really shutting down, so I made sure no one was logged in first. When a wall command is issued, the output goes to everyone currently logged in, including the person issuing the command.

Here's how I checked to see who was logged in:

[scooby@cartoons]$ who
scooby   ttyp1    Aug 24 00:10 (d4.dialup.seanet)

I was the only one logged in. Therefore, I issued the following command with the filename:

[scooby@cartoons]$ wall < test
Broadcast Message from scooby@cartoons
(/dev/ttyp1) at 0:11 ...
system shutting down!

Note that the output indicates that it is a broadcast message from scooby@cartoons. It also mentions the terminal I am on and the current time before giving the message. This information is important if something unfortunate were about to happen and a user wanted to respond. If the output were anonymous (as it is when writing to a device), then the people receiving the information would not know to whom to respond.

talk

Writing to a device with write or wall is strictly one-way communication. One-way communication has benefits as well as drawbacks. For example, what if the person receiving the data wants to respond to the message? She could use a series of write commands or the talk command. The talk command notifies the second person that you want to talk. The command tells the other person what to type in order to finish initializing a talk session.

When the session is established, each person receives a split window. When the first person types information on the top window, it is echoed in the bottom window of the second person's display and vice versa. Also, displaying in both windows happens as each letter is typed. As one person types, the other person sees the information.

mesg

The mesg command was briefly mentioned in the discussion on write. The mesg command is used to allow or disallow others from writing or walling messages to you. Of course, root overrides the mesg authority. The syntax for this command is mesg y or mesg n. The y parameter allows the communication, and the n parameter disallows the communication with normal users.

motd

motd (message of the day) is a good way to pass information on to whomever happens to log in that particular day. Typically, it is a reminder or an announcement of some type. Many companies use it to announce birthdays and other days of significance or to remind users of an event or telephone number to call. motd is a good way to communicate if the information is either not that important or only important to a person if he or she has logged in.

motd is actually a file that has its contents displayed upon login. The file is kept in the /etc directory and is called motd (/etc/motd). For example, when I log in to my computer, I receive the following message:

The system will be down tomorrow for a hardware upgrade.
Hope you are having a great day!

NOTE

motd is only seen with a command-line login. This message of the day will not be seen if the user is logging in graphically as with KDE or GNOME.

Pre-Login Message

The /etc/issue file contains the message that is displayed when logging in on the console or a virtual screen (Alt+F1, F2, and so on). The /etc/issue.net file is seen on terminals opened through Telnet. Following the issue statement, the session prompts for the login and password. This pre-login message is a good place to put something that you want everyone to see before they log in to the system. This could include a notice that printers are not working or an explanation of the purpose of the workstation where they are trying to log in. The following example is the pre-login message I get when I log in to my workstation:

login.gif

Figure

Although the /etc/issue file (and /etc/issue.net file) can be as long as you want it to be, it is best to keep it short. If it is too long, people won't read it, and it will scroll off their screens; those who might have read it will probably not take the time to scroll back to see what, if anything, they missed.

NOTE

Like motd, the pre-login message is only seen with a command-line login. This pre-login message is not seen if the user is logging in graphically as with KDE or GNOME.

Share ThisShare This

Informit Network