Keyspan Drivers and Linux (Debian/Ubuntu/Mint)

The drivers for the Keyspan USB-Serial Adapter are in the mainline kernel (as of 2.6.x), as Keyspan notes. However, the drivers are (according to Keyspan) not in the Debian or Ubuntu kernels.

This is only partly true: Debian refused to use the Keyspan drivers due to their license; the fact that Keyspan drivers were missing from the latest Ubuntu kernels is a bug (#334285).

Since Linux Mint is based on Ubuntu, one can only hope that the kernel bug is fixed soon; I’d wanted to use my Keyspan driver with my laptop running Linux Mint 7.

Pair Administration

One particular aspect of agile programming caught my fancy this last week or so: the pair programming concept. Specifically, agile programming includes the idea that programmers work in pairs, thus reducing bugs and increasing productivity. (Note that this is just one part of agile development.)

I thought to myself, that would be perfect for major maintenance projects as well. For instance, if you have to reboot a server, and make sure it comes back up with its plethora of services – why not work in pairs?

The more junior system administrator could be the driving administrator, and the seasoned professional could watch over their shoulder to make sure all is well.

Since human error is the number one cause of errors, this seems like a good way to reduce errors and increase server uptime. One of the benefits of pair programming is to reduce errors; perhaps pair administration would result in the same. The oft-repeated quote says that “many eyes make shallow bugs”; perhaps “many eyes make better uptime!”

If you try it, let us know your experiences.

NO PUBKEY errors from APT (Ubuntu Linux)

When you are using APT (the package manager for Debian and Ubuntu Linux), you might receive some NO PUB_KEY errors – warnings that no public key could be found for one software repository or another. You can keep on going without fixing these warnings, but in the interest of security you should fix the problem. It is rather simple, after all.

Firstly, if you are running Ubuntu, you can use the Ubuntu key server to help you fix this problem. The server uses the SKS Key Server software to provide this valuable service.

The method is to first import the key into GPG (GNU Privacy Guard) via the Ubuntu key server (or indeed, any other), and then import it into APT via the apt-key command:

gpg --keyserver subkeys.pgp.net --recv 0123456789ABCDEF
gpg --export --armor 89ABCDEF | sudo apt-key add -

In place of 0123456789ABCDEF put the tag given in the NO PUB KEY message, and then insert the code given in the response from gpg in place of 89ABCDEF for the export.

However: apt-key has an apparently little known command option that will pass options directly to gpg. Using this option (“adv”), the update of the key can be done in one step instead of two:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 0123456789ABCDEF

If you already have the appropriate gpg key – or can get it from an appropriate web site or FTP site – you can add it directly to your APT key ring using apt-key. For example, here is an example adapted from Google’s Linux Repository Configuration page:

wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -

One could just as easily use any other method to get the file that supported the given URL. Remember that you must add the key as root; it won’t work otherwise. If you have the file locally, this is sufficient:

sudo apt-get add somekeyfile.gpg

Hope this helps you.

UNIX at 40

It was August 1969 that the work that would lead to UNIX began. That was the month that Woodstock took place, Mariner 7 flew by Mars, President Nixon visited Romania, Charles Manson and his followers committed numerous heinous murders, and Hurricane Camille struck the U.S.

There have been some nice articles on the history of UNIX; the folks at what was Bell Labs have a nice article, as well as an article by Dennis Ritchie, one of the originators of UNIX with Ken Thompson. The UNIX Heritage Society has a nice bunch of pages, though not very many. The Wikipedia article on UNIX is nice, too.

Perhaps the definitive history can be found in Peter Salus‘s book A Quarter Century of UNIX. The BBC news article on 40 Years of UNIX talked to Dr. Salus extensively. ComputerWorld also has a nice article on the past 40 years of UNIX and in addition a nice timeline.

One of things that always struck me is how many things have their roots in UNIX and Bell Labs:

• UNIX (of course)
• C
• RATFOR (who knew?)
• Bourne Shell (and the concept that a shell could run as a user program)
• awk
• Pipes
• Text-based configuration
• Regular Expressions
• The concept that “everything is a file”
• One single hierarchical file system (instead of multiple “drives” as in OpenVMS and CP/M and Windows)

And this doesn’t cover all of the things that descended from UNIX or were designed with UNIX such as Perl,

Powered by ScribeFire.

Unit Testing and System Administration

Unit tests are a programmer’s best friend – they help the programmer to fix bugs and keep them fixed, by continually testing to make sure that the bug is fixed.

In administering a system, certain services must be available, and certain products must be installed and configured. Install processes like HP-UX Ignite or Solaris Jumpstart can help, as can products like cfengine.

However, a unit test environment can be of great use to make sure that all went according to plan. Nagios is the best known of these – yes, a unit tester. Consider: do you need NFS? Test for an NFS volume. Do you require a database to be up? Check via TCP that the server’s connection is available.

In addition, if you’ve bounced a server only to find that you forgot something: create a unit test for it (that is, create a check in Nagios). If an active check won’t work, use a passive check: a check that runs on the server and reports back to Nagios.

If you continue to add checks as you think of them or encounter trouble, eventually you will find that you are much more in tune with your servers. Don’t forget to add NagiosGrapher to get the benefit of performance history too. With both Nagios and NagiosGrapher, you’ll be all set.

Powered by ScribeFire.

One-Time Checklists: Planning Ahead

Have you ever done something as simple as reinstall an operating system – only to find you missed something important? What if you have to apply patches? Upgrade databases? If you forget something simple and critical…. this is definitely not something you want to do. What can we do to avoid such scenarios?

Several days ahead of time, make a checklist. Keep adding as you think of things that need to be done during the process. If it is a reinstall, do you need to copy SSH keys? Install third-party software like sudo and rsync? Reconfigure the kernel for your environment? Put all of these down on your checklist.

Break your checklist down with titles – so that you know what step you are at and so you can find it easily. For a reinstallation, you could use headings like:

• Preparation
• Reboot and Install
• Postconfiguration

…and so forth.

Break the checklist down into specific tasks: an item like Configure Server is insufficient: what items need to be configured? How? Make the items specific and detailed.

Use the checklist during your maintenance, and keep notes on the sheets as you do them – and as you find things that you might have missed. Write them right on the checklist – and keep the checklist. Next time you do something similar, you can start with the original checklist.

In this way, you will miss nothing – and people who come after you will thank you profusely. Just keep the old checklists in places people can find them. A three-ring binder would be just right. Date the checklists too, put a title on them (“Reinstall of HP-UX 11i v3) and put them in some kind of order.

Productivity: Going with the Flow

When you write down your things to do (you are writing down your things to do aren’t you?) then you need to keep them front and center at all times. If you put them into your PDA, then checking your PDA daily has to seem like second nature. If you write them onto a sheet of paper, then checking with that sheet of paper should be a daily reflex. If you use an Internet site such as ToodleDo or Nozbe (my two favorites!) then you have to check daily.

The important thing here is to go with what is natural; don’t attempt to change your habits but work with them instead. When someone gives you something to do what do you reach for? If writing down a to-do item takes too much effort, it will be skipped or avoided. If checking your list takes too much effort, you will avoid it.

Once you have your list of things to do, put it into your “trusted system” as David Allen calls it. Don’t leave them hanging out there. This “trusted system” has to be the one you check daily. Putting things into this trusted system also requires habit and requires paying attention to the effort required: make it as effortless as possible – which will reduce or eliminate the tendency to avoid it.

Where possible, use your natural tendencies to make your system work for you; this will make you more productive since you are checking your tasks daily and doing them rapidly.