Page 326
Nope, that was wrong again, although it did go to my terminal (because of the echo command); what I needed to do was to take the output and send it to the device /dev/ttyp3, not have it echo /dev/ttyp3 back to me. Therefore, I should have done it like this:
shell:/home/dpitts$ echo hello> /dev/ttyp3 hello
Well, I finally got it right. Now to send it to Rich:
shell:/home/dpitts$ echo hello rich > /dev/ttyp2 bash: /dev/ttyp2: Permission denied
Permission denied! I wonder why that happened? Let me look at the permissions on his device:
shell:/home/dpitts$ ls -la /dev/ttyp2 crw--w---- 1 rbowen tty 3, 2 Aug 13 18:14 /dev/ttyp2
Well, I am not the owner of the device, and I am not in the group tty. The permissions for the rest of the world is no read, write, or execute. That is why I did not have permission to write to his terminal type.
So, even though I could write to rbowen, I did not have the permission to send something directly to his terminal.
Sometimes administrators need to send a message to all the users currently logged on the system. This type of communication is typically used when the administrator needs to inform everyone about something that affects them. One time the wall command is typically used is when a system is about to shut down. The system administrator, instead of just blowing everyone off the system, might want to give them time to close their applications and save their data. The wall command stands for write all. Just like the write command, it only sends the text to the terminal, and the computer does not treat it as input from that user. The standard for wall is that it gets its information to display from a file. You can either do this or use a less than sign to send it information from the command line. 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 on first (I didn't want to upset anyone). 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 on:
shell:/home/dpitts$ who dpitts ttyp1 Aug 24 00:10 (d4.dialup.seanet)
Good, I was the only one logged on. Therefore, I issued the following command:
shell:/home/dpitts$ wall test
Broadcast Message from dpitts@shell
(/dev/ttyp1) at 0:11 ...
system shutting down!
Page 327
Note that the output tells that it is a Broadcast Message from dpitts@shell. It also tells what terminal I am on and the current time. It then gives the message. This information is important if something unfortunate were about to happen and you wanted to respond. If the output was anonymous (as it is when writing to a device), then the people receiving the information would not know to whom to respond.
Writing to a device, either with write, wall, or literally to the device, is strictly one-way communication. This has its benefits, but also has its drawbacks. For example, what if the person receiving the data wanted to respond to the message? This could be done with a series of write commands, or with the talk command. The talk command notifies the second person that you want to talk. The command tells the other person what to type 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. So, as one person types, the other person sees the information.
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 this authority. The syntax for that command is mesg y or mesg n. The y parameter allows the communication and the n parameter disallows the communication with normal users.
The motd (message of the day) command is a good way of passing information to whomever happens to log in that particular day. Typically, this 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. The motd command is a good way to communicate if the information is either not that important or is only important to a person if he or she logs in.
The 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 mk.net, I get the following message:
Welcome to shell.mk.net!
Electronic mail is quickly becoming the medium from which much communication is passing between people these days. Many companies now consider e-mail to be a necessary element in accomplishing their business and spend great amounts of money making sure that people receive their electronic mail.
Page 328
Electronic mail is a great way of communicating with others when time is not a critical factor. It can be sent to individuals or to entire lists of people. One of the benefits of electronic mail is that information can be passed to one or more individuals whenever they happen to log in and check their mail. Another benefit of electronic mail is that it can be sent to other people on other servers. If you are connected to the Internet, then the mail can be sent practically anywhere.
The /etc/issue file contains the message that is displayed when a Telnet session is initiated. 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 things like a notice that printers are not working or an explanation of the purpose of the workstation that they are trying to log on to. The following example is the pre-login message I get when I log on to mk.net:
/etc/issue pre-login message ****************************** ** MK Computer Associates ** ****************************** ** UNIX shell server ** ** (shell.mk.net) ** ****************************** ** Login on this machine is ** ** restricted to web site ** ** development activities ** ** ONLY, thank you. ** ****************************** shell login:
As you can see from the pre-login message, this particular server is restricted to Web site development activities (ONLY). I know, in this case, that I should not use this server to perform engineering computations, for example.
Although the /etc/issue file can be as long as you want it to be, it is best to keep it short. The reason for this is that if it is too long people won't read it and it will scroll off their screen, and those who might have read it will probably not take the time to scroll back to see what, if anything, they missed.
One of the things that all system administrators realize at some point is that they cannot possibly know everything about the operating system; it is too complex and changes on a regular basis. A good system administrator, though, knows where to turn to get help. Because you are reading this book, you have at least started on your way to being a good system administrator. This book unleashes many of the tools and "secrets" of the Red Hat Linux operating system. With a book of this type, the index becomes very important. A book like this is not bought to