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.
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.
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
script command. For example, I can keep track of
the date I did some experiments with
$ 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
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
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
←[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
$ 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
received a beep; I then tried to tab at
sno and had my input
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
you are finished, either press
or type the word
exit. I find that this method produces less
script so I don't need to clean up the file
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.
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
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
$ 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