things are changed. If a task can be broken down into several small tasks, each with individual test plans and back-out plans, then the job becomes much simpler.

Developing a Test Plan

Each change to a system needs to be tested. 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 there users or processes dependent upon the file?
2. If yes, can the users or processes still access the file?
3. If no, then make it available (change permissions, add directory to path, create link, and so on).
4. Does it do what it is supposed to do?
5. If yes, okay; if no, then fix it.

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 of a change that affects them.

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

Many different tools can be used to communicate to users. In order 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, then that information needs to be communicated only to the users currently logged on to the system. If, on the other hand, you want to announce a birthday, then that information needs to be announced either to all users, or to all users who log on to the system that day. Or, perhaps a user is remotely logged on 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. In the following sections, several different tools for communication are discussed; some are commands, and others are concepts. In addition, examples are given to illustrate which tool would be best given the particular need. The following are the communication tools that are discussed in the upcoming sections:

• write: One-way communication with another user currently logged on the system.
• Echo to the device: One-way communication with another user currently logged on the system.
• wall: One-way communication with all other users currently logged on the system.
• talk: Interactive two-way communication with another user currently logged on the system.
• mesg: Controls message reception (talk and write) from other nonroot users currently logged on the system.
• motd: Message of the day received by users when they log on the system.
• Electronic mail: For sending messages to and receiving messages from users whether or not they are currently logged on the system.
• Pre-login message /etc/issue: The message is displayed on a terminal at time of login. User does not have to log on to see this message.

write

The write command enables a user to write a message to a 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. Anything you type, until you hit Ctrl+C, will be echoed to that user's display. For example, I tried to write a message to my friend Rich, who was logged on to mk.net:

shell:/home/dpitts$ write rbowen

Hello Rich.  How are you today?

shell:/home/dpitts$

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, though, I turned off my mesg (mesg n). Here's what happened:

shell:/home/dpitts$ write dpitts

write: you have write permission turned off.

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

shell:/home/dpitts$ mesg y

shell:/home/dpitts$ write dpitts



Message from dpitts@shell 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

shell:/home/dpitts$

It is displaying everything that I type, and then echoing it back to me with write. That is why there are two identical lines. Had this gone to another terminal, then I would have seen what I typed, and when I hit Enter, it would have been sent to the user I had indicated.

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 dpitts@shell on ttyp0 at 20:10 ...

After I had held down the Ctrl key and pressed the C key, it disconnected me from the write program, indicated by the last line showing the end of the file (EOF).

Echo to the Device

Echoing to a device is similar to the write command. It has a similar result in that it writes output to a device (such as a terminal), but it uses a different mechanism, and thus, potentially, has different results. Let me see if I cannot send some output to someone's terminal as I log on to mk.net.

First, I look to see who is logged on:

shell:/home/dpitts$ who -u

root     ttyp1    Aug 13 10:01 00:05 (laptop.mk.net)

rbowen   ttyp2    Aug 13 17:29 00:44 (rbowen.is.lex.da)

dpitts   ttyp3    Aug 13 18:13   .   (d13.dialup.seane)

I am logged on (dpitts), the system administrator is logged on (root) and my good friend Rich Bowen is logged on (rbowen).

Next, I try to echo a comment and send it to my terminal type:

shell:/home/dpitts$ echo hello >/dev/tty/p3

bash: /dev/tty/p3: Not a directory

Oops, I did it wrong. I should have sent it to /dev/ttyp3, like this:

shell:/home/dpitts$ echo hello /dev/ttyp3

hello /dev/ttyp3