209
Chapter 11. Miscellaneous Tools
This chapter contains odds and ends that dont really fit any of the categories described in previous chapters. Most of the software presented here isnt really designed with network troubleshooting in
mind, but it is, nonetheless, quite useful. These are tools that will make your life easier. With a few notable exceptions, you should already be familiar with most of the tools described here.
Consequently, the descriptions of the tools are, for the most part, fairly brief. Feel free to jump around in this chapter as needed.
11.1 Communications Tools
If you are going to effectively administer remote systems, you will need to log on remotely. Even with small networks, it isnt reasonable to jump up and run to the remote system every time you need to do
this. This section has three subsections. First, a quick review of techniques you can use to record or log your activities when using familiar tools like telnet, rlogin, and X Windows. Next comes a
discussion of vnc, a tool that allows you to view a computers graphical display remotely. Then I briefly discuss security concerns for these tools including a short description of ssh.
11.1.1 Automating Documentation
This book has assumed that you are familiar with tools like telnet, rlogin, and X Windows. To use these tools effectively, youll want to be able to record or log your activities from time to time.
Arguably, one reason documentation is so often flawed is that it is usually written after the fact. This is often done from memory or an incomplete set of notes several days after changes have been made.
While the best time to write documentation is as you go, often this simply isnt possible. When your network is down and management is calling every five minutes asking if its fixed yet, you probably
wont be pausing to write much down.
There are a few things you can do to help simplify writing documentation after the fact. First, get copious printouts at every stage, preferably with some kind of time and date stamp. When a
production system is down, it is not the time to worry about the cost of paper. Several commands you are probably already familiar with may be easy to overlook with the stress of dealing with a dead
system.
If you are using X Windows, you can use the xwd command to capture windows. To use this command, in an xterm window, type:
bsd1 xwd -out xwdfile
You can then click on the window you want to capture. In this example, the file xwdfile will be created in the current directory. The file can be examined later or printed using tools such as xv or gimp. Be
sure to give these files meaningful names so that you can sort things out later.
If you are using a text-based interface and are interested in capturing the output of a single command, you may be able to use the tee command. This command allows you to send output from a command
to both the screen and a file. For example, the following command will display the output of the command
arp -a
on the screen and write it to the file outfile:
210
bsd1 arp -a | tee outfile
The tee command may require special measures to work. For example, you must use the option -l with tcpdump if you want to use tee. An example was given in
Chapter 5 . As with xwd, you should be
careful to use meaningful filenames, particularly if you are capturing windows on the fly. An alternative to tee is script. It can be used to capture the output of a single command or a series of
commands. To capture a series of commands, you start script and then issue the commands of interest. For example, the following command will create the file scriptfile and return to the system prompt:
bsd1 script scriptfile Script started, output file is scriptfile
Everything that is displayed on your terminal will be logged to the file scriptfile. One advantage of logging a series of commands is that you can embed documentation into the file as you go. Simply
type the comment character for your shell, and everything else you type on the line will be ignored. For example, with the Bourne shell, you might type something like:
bsd1 Well, the foo program didnt work. \ Lets try the bar program.
The \ character was used to continue the comment on a new line. When you are done logging a session, type
exit
or press Ctrl+D as in:
bsd1 exit Script done, output file is scriptfile
You can now print or edit the file as desired. One option that is often overlooked is to include a command with the script command. For example:
bsd1 script scriptfile ifconfig -a
will run the program ifconfig -a, writing the output to the file scriptfile and displaying the output on the screen as well. This file will include two time and date stamps, one at the beginning and one at the
end of the file.
You should be aware of a few problems with using script. First, the file can get very big very quickly. This shouldnt be much of a problem unless you are pressed for disk space, but it can be painful to
read after the fact. Second, it is all too easy to lose the file. For example, if a system crashes or is halted, the file may be lost in the process. Third, commands that directly control the screen such as vi
tend to fill the output file with garbage. Finally, since a new shell is started by script, environmental changes made while script is running may be lost.
If you are connecting to a remote system using a variant of telnet, you may be able to log the session or print the screen. This is particularly true for PC implementations of telnet. See the documentation
for the version you are using.
11.1.2 vnc
Kategori