Odds and Ends

by Dru Lavigne
01/23/2003

One of the reasons I look forward to the holiday season is that it provides the opportunity to get reacquainted with the inner workings of my FreeBSD system. During the rush of the rest of the year it seems that everything I learn is on a need-to-know basis. So with the excitement of a four year old on Christmas Eve, I break open the eggnog, pump up the volume on the PC speakers, and start reading through the notes I've made to myself over the past year.

It always reminds me of how I felt after my first successful FreeBSD install. After the initial "omg, I just installed Unix!", I sorta sat there in a stunned daze and wondered "now what?" There was just so much to learn, so many man pages to read, so many commands to try out. Not to mention the fact that I kept getting lost and couldn't remember where I was and where I had saved things.

Keeping Track

It was then that I acquired two habits which helped me scale the initial learning curve. The first was to subscribe to the freebsd questions mailing list. This is a fairly high volume list, but the information that can be learned from it is invaluable. In the beginning I'd set aside an hour a day to read through the responses. If something sounded interesting, I would try it out on my own system. If I couldn't get it to work, I appended that particular post to an ever-growing file of things to try again at a later date.

Related Reading The Unix CD Bookshelf By O'Reilly Media, Inc.

At first that file seemed huge; everything I read sounded interesting, and I wasn't very good yet at getting things to work. But after a few months of persistence, I noticed that I was making progress. It was like getting used to a new language. As I'd read through that file, the information in it seemed less strange and started to make more sense. Pieces were starting to fit together. One day as I was reading through the mailing list, someone asked a question and I actually knew the answer. That was a very good feeling.

The second habit I acquired was taking the time to document everything. I bought two notebooks. The first I labeled "stuff I tried"; the second I labeled "stuff that works". Since I have a knack for discovering all of the wrong ways to do something before I stumble upon a way that works, my first notebook filled up very quickly. I was, however, left with a record of all possible error messages and how I managed to get past them to a working solution. This became an invaluable troubleshooting tool. Knowing how to reproduce an error is as important as knowing how to accomplish something without errors.

The second notebook eventually turned into my little black book of accomplishments. Once I figured out how to do something, I didn't have to reinvent the wheel when I needed to do it again six months later. I could simply look it up and follow my own step-by-step instructions. It was also an excellent way to chart my progress as those empty pages slowly transformed into the stuff I knew how to do on a Unix system.

At some point, I retired those notebooks and started to maintain notes in my home directory. There are several ways to keep track of your own experimentations. The first is to record your input and resulting output using the script command. For example, I can keep track of the date I did some experiments with snort:

$ script snort.dec.28.2002

This command tells the script utility to copy all input and output to a file called snort.dec.28.2002. When you use the script command, you'll receive a message stating the script has started and the name of the output file you specified. You will also be presented with a fortune, if you normally receive a fortune when you login. At this point, you can carry on as usual. Once you've finished recording what you set out to do, end the script by pressing Ctrl-d. You'll see a message like this:

Script done, output file is snort.dec.28.2002

The script utility is an excellent way to record how you accomplished something; it also creates a file that is handy to send to someone else so they can see what errors you are running across. It has its limitations, though, since it records everything, including escape characters. For example, here is the first line from one of my script files:

←[1mdlavigne6@~←[m: cd /s•←[K/ysr/•←[K•←[K•←[K•←[K•←
[Kusr/ports/security/sn•o•rt

It's a bit hard to tell, but this is what script was recording:

$ cd /usr/ports/security/snort

The resulting output is unreadable for several reasons. One, I use a customized prompt which contains control characters. Second, I had problems typing that day. Instead of /usr, I typed /s and had to backspace a character; than I typed /ysr and had to backspace three characters. Finally, I use tab completion; you can see that I tried to tab at sn but received a beep; I then tried to tab at sno and had my input completed to snort.

The file utility does warn that this happens:

$ file snort.dec.28.2002

   snort.dec.28.2002: ASCII English text, with CRLF, CR, LF line terminators, 
   with escape sequences

All is not lost, though. This command will get rid of most of the garbage characters:

$ more snort.dec.28.2002 | col -b > snort.dec.28.2002.clean

The result is much more readable:

 1mdlavigne6@~m: cd /usr/ports/security/snort

	file snort.dec.28.2002.clean
	snort.dec.28.2002.clean: ASCII English text

You'll find that if you use an editor during a script session, the results from the edit will be a bit messy when you re-read your script file. For this reason, I tend to use the echo command to send little comments to myself:

$ echo #once you open up /etc/rc.conf
   echo #change this line: linux_enable="NO"
   echo # to this: linux_enable="YES"
   echo # and add this line: sshd_enable="YES"

These comments help me to remember why I opened certain files and what I did when I was in there.

Another way of recording a session is to open an interactive shell:

$ csh -i | & tee acid.dec.29.2002

Again, you'll receive a fortune and everything you type will be recorded to the file name specified after the word tee. When you are finished, either press Ctrl-c or Ctrl-d or type the word exit. I find that this method produces less garbage then script so I don't need to clean up the file using the col -b command. However, if I try to use vi from an interactive shell, I'll receive this message:

ex/vi: Vi's standard input and output must be a terminal.

The pico editor will work, but the results will still be very messy when I read the resulting session file.

One of the cool things about recording to a file with either script or csh -i is that the results can be watched "live" from another terminal. For example, another user on the system can use the tail command to watch the file as it is created:

$ tail -f acid.dec.29.2002

This can be very handy if you are troubleshooting a problem and need another user's input on the error messages you are receiving.

Pages: 1, 2

Next Page