These files are simply plain text files, used to communicate a simple, and usually very short message to the user. The /etc/issue is displayed at the moment before authentication begins, whereas the /etc/motd (Message of the Day) file is displayed once a user has been authenticated. Typically, the /etc/issue will contain something like a host identification, for example "Welcome to Production Server hostname, running O/S xxx, and Oracle version xxx". In today's ultra security aware production environments, where we try to help a potential hacker as little as possible, it has become the trend to simply issue some kind of warning, for example "Warning: Authorized users only". The only difference between /etc/issue, and /etc/issue.net is that /etc/issue.net is displayed when the inbound connection has a remote source. It should be noted that these files are used only by authorisation techniques employing login, for example telnet, which in security aware environments is often restricted, in favour of ssh for example, which does not use the issue files.

/etc/motd is displayed once authentication has been established, and is really intended to remind users of a particular upcoming system event, perhaps removing the overhead of mailing a whole bunch of users who may not have even read their mail. For example "Server going down for maintenance at 6pm this evening.", however in medium and large environments, its use has become somewhat irrelevant, and this is particularly so where single sign on techniques are employed. It can also create as much confusion as it brings clarity, when not updated in time, for example as a last step in releasing the system after maintenance has been completed.

wall is used to broadcast a message of maximum 22 lines to all interactive terminals, and may be called by any user as default, but is often restricted to root only use. Any user not wishing to receive broadcast messages may use the mesg to write disable their terminals, and a broadcaster may use the finger command to see which terminals are write disabled. It has only two possible arguments, firstly the root only option -n, which suppresses the standard broadcast banner, replacing it with a remote broadcast banner, and is possible only when used remotely through the rpc.walld daemon. The second argument, the message itself, which must be terminated with an EOF (end of file) when not supplied as a direct argument to wall.

As its name suggests, the shutdown command is used to shutdown a server gracefully, stepping down through the run level kill scripts, and optionally halting, or rebooting the server. The shutdown command itself is not discussed here, and this small section explains only the communicative steps that shutdown takes before, and during the system shutdown.

The last argument to the shutdown may optionally be used to broadcast some custom message explaining the purpose of the shutdown, and when it is expected to be returned to production. For example:

# Shutdown -H +10 Server halting in 10 minutes for change change number. Expected up at 00:00:00. 
        

Shutdown has also the curious -k option, which simulates a shutdown without actually executing one, and from the user perspective is in essence an actual shutdown. Broadcast messages may also be appended to the command arguments, as in a "real" shutdown. You might be fooled into thinking that the usage of the -k option is safe, since it is only a simulation. This is not so, and you need to be aware that the /etc/nologin is created, and subsequently removed, after the command has completed.

In the event that a running shutdown needs to be cancelled, the shutdown may be called with the "-c" argument, and again a broadcast message added to the command line to inform the users of the U-turn. As with all forms of message broadcasts, the receiving terminals must be write enabled.