10 Must-Have Linux Tools

4. Head to the dump: When managing a network, solution providers may need to debug the network setup to ensure all routing is occurring properly. Solution providers may also need to intercept and display TCP/IP and other packets being transmitted over the network. The unencrypted information can be viewed using tcpdump, a network debugging tool that runs under the command line. Built upon the libpcap packet capture library, the utility prints out the headers of packets that match a Boolean expression. Flags and options, such as -w and -a, improve the information captured by tcpdump. In this case, the -w flag is used to save the packet data for later analysis and the -a flag is used to convert network and broadcast addresses to names. On networks with a high volume of traffic, tcpdump output can be hard to read. Using tcpdump with Berkeley Packet Filter formats the output in a more usable fashion.

5. Chain gang: Sometimes a single command is just not enough. Solution providers often write short scripts to accomplish some tasks, such as finding a certain set of files and performing an aggregate action on the resulting list. The scripts often consist of two or three commands, and output from each command is piped into temporary files for processing. A short script could create a list of files that fit a certain criteria, pipe it to a temporary file, and then process the generated list to perform, for example, a search or a word count.

The xargs command makes short scripts unnecessary. Like the way "and" connects two clauses together in grammar, xargs connects the find command with another command. The usage, find . -name 'filename' | xargs second-command, allows xargs to apply the second command to the found list. No piped list, no temporary files. For example, find . -name 'index.html' | xargs grep -l 'styles.css' looks for all index.html files in the current directory and all subdirectories beneath, and then searches for the string "styles.css" in those files. The final output will show only the paths of those index.html files that is using that particular stylesheet. The find ... xargs construct can be used with other commands as well.

6. Use the windows: Solution providers who perform remote management are well-familiar with the following scenario: After logging into a remote server via an SSH connection, the characters suddenly stop appearing on the screen and a "Connection Closed" message appears. A half-completed task now has to be started over because the session was lost for whatever reason.

Chances are that the screen utility is already installed on the system, usually in /usr/bin/screen. Otherwise, it can easily be downloaded as a package for a given distribution. Screen is started from the command line, and it creates a window that functions just like a normal shell, except for a few special characters. Using CTRL-A sends commands to screen instead of the normal shell, and CTRL-A ? displays the help page with all the commands for screen.

This utility is a keeper -- it makes disconnects less disastrous, and it also allows multiple windows within one SSH session. Without screen, running four or five SSH sessions with several tasks in each shell would require 15 SSH sessions, logins and windows. For example, a solution provider can be running TOP to see what is happening on the system and can then open a new window with "CTRL-A c" to run ps -ef. The beauty of screen is that TOP will stay running.

Screen also keeps the session open and the job running regardless of whether or not the user is logged in. If the solution provider starts a job or a download in screen at a client site, the process will continue even after logging out. The solution provider can login, re-attach to the screen and get back to work. Logging is also a snap in screen, since "CRL-A H" creates a running log of the session. Screen will append data to the file through multiple sessions, giving solution providers a log of changes made to remote servers.

7. A look back in time: Speaking of logging, solution providers look at several different logs to figure out what is happening on the system. Is a system not detecting a particular piece of hardware? Is an application not returning expected results? Is the Web server showing strange errors? Logs help solution providers collect information about what's happening and try to find out what is going on.

However, log files also can get long, and it's tedious to have to reopen the file after each change to see what new log message is generated. The tail -f command helps with troubleshooting by allowing solution providers to look at the end of the file in real-time. The file is not opened in an editor such as vi or emacs so no edits can be made. It shows what the last thing in the file is, and keeps the buffer open so when new messages are written to the file, it appears on the screen instantly. Users can test different configurations and commands in one window and instantly see log messages without having to reopen the file and navigate to the end of the file each time.

NEXT: Who you gonna call?