The new server status page, which is a front end to a Nagios 3.0.6 installation, shipped today. As in, it went live on the work servers, and it’s now the primary view for the health of our servers. It’s been months of work, debugging and network discovery to get where we are today.

Some of the features that were planned for the 1.0 release didn’t make it. But, shipping is a feature, and it’s the most important one. The other important thing is I’ve spent a lot of time making sure that the architecture is sound, so we can scale out with more monitored devices, and up with richer tools and features.

Have you ever used an old IBM typewriter or one of their Model M computer keyboards from the 1980s? The ones that weighed twice what a laptop now weighs, and feel like they were cast out of a solid block of stone? The ones with the loud clicky keys, that had proper tactile response as you hit the keys, letting you know damn sure that you had gotten the key pressed all the way in? They are, arguably, the best keyboards ever made. Other people have tried to emulate their keyboards, finding buckling spring switches and other esoteric materials, but they usually wind up costing huge piles of cash. And while the keys themselves are very nice, they don’t have the ruggedness of the old IBM slabs.

I’ve lusted after a Model M for years. The problem with them is they were made with the dominant interface standard of the time – the PS/2 connector. It’s hard to get a computer with that port that will run a modern OS, and I’ve never heard good things about the PS/2 to USB adapters on the Mac.

There’s good news. PCKeyboards has the Model M, in all it’s retro glory, fitted out for USB, for $69.00 +S&H. That’s not bad, especially considering that the next best USB keyboard, the Matias Tactile Pro (which is out of production again while they spool up for their 3rd generation) usually costs well north of $150.

Apparently, most Mac users also use windows. I feel bad for them. Of the 7 PC’s I use or work with on a daily basis, none of them run Windows. Only 6 of them could, as my main Mac at work is a G5 tower, and they don’t do the Virtual Machine thing.

A vote for Qais is a vote for freedom. Vote early, vote often. (Even if they spelled his name wrong.)

By default, pixelpost browses archives by category. Which is all well and good, until you actually use the software for longer than say, a month. By default, it loads up all of the pictures in the All category. For me, that’s more than 730 400×300 pixel images. More than half of my google image results load index.php?x=browse, which loads every thumbnail.

To fix this, I enabled the paged archives addon, and then went to work hacking about in the tags. Now, everything links around properly, and the paged archive is what loads. The second problem which was harder to fix, was changing the behivhor of the x=browse link to only show 10 images if no date range was selected. Most of the problem was digging around to see which function was actually being used, and then to add an extra $limit = " LIMIT 10,10"; inside the last set of if/else brackets.

Rocking. Next task: get the archive date list to appear next to the thumbnails. Alas, PHP/Perl is easier than CSS.

Feature requests for software development fall into a couple of categories – one of them being the “if we had unlimited development resources, what would we want to see”. I’ve taken to calling those requests “jetpacks and moving sidewalks”. It’s not practical to think about implementing them now, but it helps keep you motivated when slogging through tedious debugging or implementing yet another feature you aren’t really excited about. Like a light in the darkness, you know where you’re trying to get to, and you know what to design towards.

Currently, my project is redeveloping the monitoring and notification system for the campus. It’s based on Nagios and NDOUtils, with a whole lot of custom code and web front ends thrown in to manage the configuration files. Feature creep is everywhere. I’m trying to keep it down to manageable level, but it can be hard. Recently, we’ve hit a major slowdown due to other groups on campus, and I’m getting the jetpack feeling again.

First off, I want to let people set their own notification options from a web site. Allow them to pick the address or addresses that get sent to when something goes wrong, as well as the time periods and event levels these addresses are valid for. These aren’t for the general pager system/on call stuff – this is to let people like myself get a lot more data about the state of the network. The paging of the oncall staff member would still happen via the operators. This is currently in progress. It’s fleshed out in concept, but needs a lot more user testing before I can release it to the wild.

Second, I want to get some physical phones to plug into the backs of the servers to be able to send and receive SMS messages, without using the campus networks. This would allow us to notify people even when email or the internet is down, and would allow the SMS system to respond to incoming pages as well. For example, you could respond to an alert with the phrase ack to acknowledge the problem, or next to alert the next on call person because you are otherwise detained. You could also schedule on-demand host and service checks from the road. In the true jetpack version of this, you’d be able to get the server to actually dial a number and play a pre-recorded message, complete with a touch-tone menu system. I’ll settle for bidirectional communication that’s not tied to our email system first. Of course, we have to get money approved for this, and with the budget realities we are working with, it may take some time.

Third is the concept of scale. The pause in progress recently has made me start mining through the nagios-discuss list, and I’ve come across the Distributed Nagios eXecutor. In short, it takes the tedious process of maintaining a lot of configuration files and multiple instances of Nagios off your hands, and handles the dispatch, execution and processing of check commands. It’s designed to scale to as many nodes as you give it, which allows you to add check capacity easily. I need to find out if you can run the nodes in multiple networks (with different network permissions) and have it target checks to the right boxes. If that’s possible, it may be a solid upgrade route for the 2.x or 3.x release of this monitoring project. Even if not, it may help solve the problem of scale as we bring more and more hosts online.

When I first started shooting with my D200 4 years ago, I was amused with the AUTO ISO setting. I had thought to myself, “Why would I ever shoot at anything past ISO 400”? Above 400, the noise starts to show up. Unlike with the D70, the noise is somewhat bearable, but it’s still there, and very distracting. I tried without much luck to refine my shooting style, adopt better camera-holding techniques, or lug about heavy tripods. None of them work – especially the last one. Even when I’ve packed my tripod to come with me, it’s usually left in the car, due to it’s bulk and added weight.

As much as I hate the noise in the shots, I also hate discarding whole sets of shots because I was trying to compensate for a low shutter speed, and not doing a good job. The last panorama I shot standing on a parking deck in the Spice Souk of Dubai was ruined by motion blur. Without a $1300 plane ticket, there’s no way to shoot that again. And, honestly, my work isn’t yet worth that much money to take a single panorama.

The reason I bring all of this up was I noticed recently that I’ve set my AUTO ISO all the way up to 1600, and I almost never turn it off. Of course, if I’m shooting on a tripod at night, sure. Otherwise, I just leave it alone. The reason? A grainy picture is better than a blurry one. I can work with a grainy picture. I can’t fix a blurry one.