Man pages

1.

MAN PAGES
To discover additional information about a command or configuration file, you can use the man (short for
manual) page. For example, to learn more about the ls command, execute man ls.

2.

MOVEMENT COMMANDS

3.

4.

YOU CAN USE THE -K OPTION TO THE MAN COMMAND AND HAVE IT
SEARCH FOR A “KEYWORD”

5.

THIS COULD BE BECAUSE THE DATABASE THAT HOLDS A LIST OF MAN
PAGES AND DESCRIPTIONS HAS NOT BEEN BUILT OR UPDATED.

6.

COMMAND HELP OPTIONS
SOME COMMANDS SUPPORT AN OPTION THAT PROVIDES SOME BASIC
HELP FEATURES.

7.

THE HELP COMMAND

8.

THE INFO COMMAND
EACH MAN PAGE IS SIMPLY A SINGLE TEXT DOCUMENT, INFO PAGES ARE MORE LIKE
READING CONTENT FROM A WEBSITE THAT HAS HYPERLINKS TO PROVIDE MORE
STRUCTURE.

9.

MOVEMENT COMMANDS FOR THE INFO COMMAND

10.

THE /USR/SHARE/DOC DIRECTORY
WHICH DOCUMENTATION IS AVAILABLE IN THIS DIRECTORY DEPENDS ON WHAT SOFTWARE
HAS BEEN INSTALLED.

11.

INTERNET RESOURCES

12.

FILE EDITING (VIM)

13.

14.

15.

REPLACING TEXT

16.

COPYING, MOVING, AND PASTING TEXT

17.

CHANGING TEXT

18.

SAVING AND QUITTING VIM

19.

WHEN THINGS GO WRONG
FIRST, THE BAD NEWS: SOMETHING IS GOING TO GO WRONG. COMMANDS WILL FAIL,
PROGRAMS WILL CRASH, AND CONFIGURATIONS WILL HAVE ERRORS.
The Science of Troubleshooting
1. Gather all relevant information related to the problem. This is an important step because we tend to want to
solve problems quickly without researching them completely. This can easily result in a faulty
conclusion, which in turn can further complicate the problem.
2. Determine what is the most likely cause of the problem. Again, avoid jumping to a conclusion about the first
possible cause. Really consider what other conditions may have caused the problem and make an
educated guess at the most likely cause.
3. Document the actions you plan to perform to solve the problem before taking any action. This is perhaps
the most commonly overlooked step in this process, but it’s a critical one. If you document the actions you
plan to take, it will be easier to undo anything that did not work correctly. Part of this step could also
include making backup copies of critical files before modification.

20.

THE SCIENCE OF TROUBLESHOOTING (CONT.)
4. Perform only the documented actions to solve the problem. Note the emphasis on the word only. Do not
decide halfway through solving the problem to go off on a different tangent. If you decide your plan is not
going to work, back track out of the solution (undo the steps to that point) and form a new plan of attack.
5. Determine if the problem has been correctly solved. This step may seem unnecessary to mention, but you will
find that often you think you’ve solved a problem only to discover sometime in the future that you really did
not. This is fairly common when you solve problems for others; for example, if you are a system
administrator and attempt to solve a problem for another user.
6. If the problem is not correctly solved, use the documentation from Step 3 to get back to the state the system
was in when you started this process. Then go back to Step 2 and perform Steps 2–5 again.

21.

THE SCIENCE OF TROUBLESHOOTING (CONT.)
7. If the problem is solved, determine if any additional problems now exist as a result of the actions you took.
This is a commonly overlooked step. For example, you may have modified a user account to provide specific
access to a directory, but this modification results in the user not having access to other directories that the user
previously had access to. You obviously cannot check everything, but think to yourself “what problems could
this solution create?” before going on to the next step.
8. Store the documentation that you created, including the actions that did not solve the problem, using a technique
that will be easy for you to retrieve in the future. We find that some problems crop up again and again, and our brains just
are not adept at remembering the solutions we previously worked so hard at discovering. Create a troubleshooting log
or handbook for yourself or your organization to make solving problems easier in the future. Also, keep in
mind that your solution could cause more problems, which might not surface until sometime in the future. Having a log
of what you did can make life a lot easier in the future.
9. Consider what you can do to prevent this problem from happening in the future. Be proactive, as it can save you
time, increase productivity, and protect you (and others) from big headaches down the road.

22.

NOTIFYING USERS
IT IS IMPORTANT TO ENSURE THAT USERS ARE KEPT UP TO DATE REGARDING CHANGES IN THE
NETWORK OR SYSTEM. LINUX HAS SEVERAL METHODS TO AUTOMATE NOTIFYING USERS OF THIS SORT
OF INFORMATION.
Pre- and Post-login Messages
Consider carefully what information you want to display.
Too much information and you risk users only reading a small portion. Too little, and you risk not providing enough
information.
The /etc/issue File

23.

Note that these special values are
actually used by a process called
agetty.
The agetty command is what
provides the login prompt.

24.

To test changes in the /etc/issue
file, you need to be able to log in
via the command line.

25.

THE /ETC/ISSUE.NET FILE
The /etc/issue file is only displayed when a user logs in via a local command-line login. If a user logs in from a
remote system, you can display a message by placing information in the /etc/issue.net file.
If you are allowing both telnet and SSH connections, keep the special character sequences in the
/etc/issue.net file and change the Banner setting in /etc/ssh/sshd_config to point to another location:

26.

THE /ETC/MOTD FILE
A friendly welcome message: Let users know you are happy they are here. Seriously, you have no idea how
many regular users, especially newbies, are intimidated by logging in to a Linux machine. Offer some friendly
advice, provide some helpful resources (like the tech support or help desk information), and let users
know they are not alone.
A “don’t you dare” warning message: Okay, we know this sounds like the opposite of the previous suggestion.
However, on your mission-critical servers, you do not want to be all nice and happy. Make sure users
know how closely this server is monitored. Let them know that if they break the rules, the results will be severe.
Upcoming changes: If you are planning on bringing down this system for maintenance next Tuesday, make note
of it in the /etc/motd file. If you are adding new software in the coming weeks, indicate that with a notice in the
/etc/motd file.
Purpose of the system: If this is your web server, why not make that clear when the user logs in? Users should
know what sort of system they are working on or logging on to, and the /etc/motd file is a great place to make
this clear. You can only imagine how many times system administrators have heard “Oh, I didn’t know that was
our mail server!” when the user is asked “Why did you run this CPU- intensive program on that system?”

27.

BROADCASTING MESSAGES
THE WALL COMMAND
To avoid displaying the banner at the top of the message, use the -n option when executing the
wall command.

28.

To ignore a wall message in a specific terminal, set your mesg value to
“no” by executing the following command:

29.

THE SHUTDOWN COMMAND