Keeping a computer log...

Keeping a computer logbook is not an option for most positions. If you’re working on your own, whether running your own site or just learning Linux/Unix, keeping records and notes are still important.

How often does the average computer professional have to create a brand new filesystem? Set up a new printer? Install security certificates? Patch the operating system?  Unless you’re working in a large company, not that often.

My first computer was a Commodore 64. My next computer was a mini-mainframe with a customized UNIX operating system. I was very lucky because my mentor didn’t try to introduce me to everything at once, just what I needed to be able to keep the system running for the users. That meant backups, user accounts and managing a database. When something came up that I didn’t have the knowledge and skill to handle, I got an in-depth lesson on it and was drilled until I was comfortable with the new skills. The problem was that those new skills could go unused for months at a time.

What tends to happen is that new skill gets rusty because you don’t need it every day. When you do need to use that particular set of skills again, you have to relearn that skill set, or at least review so you don’t do something to your system that takes the weekend to fix.

It is easiest to review and refresh. And it’s easier to review if you kept notes or records of what you did in the first place. And Information Technology (IT) people often keep terrible notes. Oh we will keep them, but they’re in the form of sticky notes on the monitor edge, or legal pads that have multiple subjects. Sticky notes wind up floating to the floor, Legal pads wind up filed under something else.

I’m one of the worst folks for not liking to write things down. Study notes are the one exception. But record-keeping is definitely not one of my favorite things. But I found a nearly painless way of keeping track of system activities.

The first book I ever got about Unix system administration was “Unix Administration Guide for System V” by Rebecca Thomas And Rik Farrow. The authors approached Unix the same way. One piece at a time: user account management, filesystems, backups, startup and shutdown, printing, system accounting, communications, security and troubleshooting. I still have that book on my reference shelf. And of all the help that book provided, it was a seven-line script in the first chapter that has been my best friend and companion. They called it logger. I’ve renamed it “loggit” so it doesn’t conflict with any system logger files or processes.

The authors took advantage of basic Unix utilities and shell scripting. (Sorry, Linux wasn’t around yet.) When you typed logger, the cursor jumped down one line and you could type anything you needed to. When you were done, type Control-D and your prompt came back. The script entered a time stamp, and put everything you typed into a simple text file. Then you could print that file and put it in a notebook for safekeeping.

This does at least two things. First, it satisfies the requirement to keep a separate, written computer logbook that documents any modifications and problems, along with what you did to fix them. Secondly, it also helps you out with troubleshooting. If something worked yesterday and there is an entry for work done on the server last night, check that part first to see if the work “broke” something.

This little script has been with me every since. Over the years, I’ve modified that script, though it still does the same thing the original script did. I’ve added to the timestamp, the hostname of the server where the loggit entry was created. I’ve also added a bit of code that puts the actual user as the author. If you’re working as root, you want to know the real user that was doing the work, not the effective user ID. And I’ve added a line of equal marks (=====) and a blank line as a visual cue for the end of an entry.

The most recent change was making sure that this file could be used on a Raspberry Pi. The only thing I really had to worry about was where and how to create the logfile and directory. All you need to do is run the script the first time with sudo loggit. That gives you the permissions you need to create the logfile in the system log directory.

Remember if you do choose to keep this logfile, this needs to be backed up! This logfile is just as important as any configuration file on your system. All that effort of documenting what you did won’t do you any good if you don’t have a copy of it when your system crashes.

Check out Installing & Using loggit if you would like to try it out.

To install an easy way to review the logfile, check out readloggit.