Candidates should be able to notify the users about current issues related to the system.
Automate communication with users through logon messages
Inform active users of system maintenance
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 file
/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.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.
As mentioned before,
/etc/motd is displayed once
authentication has been established. It can be used to
remind users of a particular upcoming system event. For example
“Server going down for maintenance at 6pm this evening.”.
In medium and large environments, its use has become somewhat
irrelevant, and this is particularly so where single sign on
techniques are employed that employ login methods that may not
even show the messsage anymore. It can create confusion
when it is not updated properly and its phrasing is unprecise,
like in our example above.
wall is used to broadcast a message of at most 22 lines to all interactive terminals. By default the command can be used by any user, but often is reconfigured so only root can use it. A user not wishing to receive broadcast messages may use the mesg to write disable their terminals. The broadcaster may use the finger command to see which terminals are write disabled.
You can specify two options with the wall command:
-n option, which only works for the root user and
the message itself. The
-n suppresses the standard
broadcast banner and replaces it with a remote broadcast banner.
This option has meaning only when wall is used
over the rpc.walld daemon. The second argument,
the message itself can also be typed on
in which case it must be terminated with an EOF (end of file,
in most cases Ctrl+D).
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 can be used with the
-k. This makes
shutdown do a 'dry-run': it emulates the
shutdown, but does NOT shut down the system.
When you use the -k options you can append broadcast messages as part of the command line too, like in a “real” shutdown.
Please note that shutdown
will still temporarily disallow user logins as it will create the
/etc/nologin file. It will be removed after
the 'dry run' but your users will not be able to log in into the
system as long as it is there.
In the event that a running shutdown needs
to be cancelled, the shutdown may be called
-c option, 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.