Eric Bergen

Are you afraid of nagios because of the config files? Don’t worry you’re not alone. GroundWork to the resuce! GroundWork is a set of packages that takes the pain out of configuration for nagios. It’s a web based GUI that supports importing existing nagios configs, audo discovery of servers and much more. I hate for this to sound like an advertisement for GroundWork but it does solve most of my major complaints about nagios. The most important of which is that it’s a pain to setup and configure. GroundWork with basic checks can be setup on a friday afternoon.

I do have a few complaints. First the configuration EZ and configuration sub menus aren’t logical. Configuration doesn’t have commit. In order for any changes to take effect you have to go back to the Configuration EZ menu. This should really be changed to have configuration basic and advanced, both with commit capability. Easy is essentially worthless.

Another issue is the use of RRD for performance historical data. This paragraph deserves it’s own post and I’ll write it some day. For now I’ll just cover the main issue I have not with RRD itself but the way RRD is used most of the time. RRD is purely for round robin data. Historical performance data is not round robin. Hell it has “history” right in the name. This data should be kept as long as possible. It’s useful for planning capacity for future events based on previous events. Aggregating away history data into month or year graphs means it’s impossible to go back and see what traffic looked like on dec 25th 2005 or any other random date(s) because RRD has either purged it or aggregated it away into a yearly view. I know it’s possible to disable the aggregation on rrd but the preallocation of data files makes this impractical for long term data storage and constantly changing servers and services. Once again RRD is a fine tool for what’s it meant to be used for it’s just not meant for historical data.

Anyway if you like nagios but are afraid of the configs give GroundWork a try. Beware! If you install it on a server with and existing apache package GroundWork will overwrite /etc/init.d/httpd

When I first moved to down town Mountain View the person at the leasing office spent about 15 minutes trying to convince me that DSL/Cable availability wasn’t an issue because Google was going to provide free internet to all of Mountain View. I tried to explain that WiFi wasn’t good enough because I routinely ssh into servers across the country thus ping time is critical. My initial assumptions about Google WiFi have been proven right over the past two years. Unless you’re aligned with Google just right it doesn’t work. I’ve tried from in buildings, in parkings lots all around town my conclusion is that it’s a compete and total failure.

I’m willing to give them a few more months to get it working in downtown mountain view. What I can’t forgive is the fact that they can’t get it working from their own campus. I’m at Google HQ building 43 right now for the MySQL Meetup and I can see an SSID for Google WiFi from my laptop but I can’t connect to it long enough to even authenticate through wifi.google.com. To me a good way to promote your free wifi service is to have it readily available on your campus.

I’ll continue the hunt for a google wifi “hotspot” in down town mountain view but don’t hold your breath.

Recently I’ve been making more modifications to the MySQL source. Part of making modifications is testing them. For years I’ve been curious why there are both tests and mysql-test sub directories in the source tarballs. Arjen Lentz tells me that tests is old and that mysql-test is the current testing framework. This makes sense since the manual testing pages are all about mysql-test.

Are there plans to clean up the remnants of the old testing framework? What else is there in the tarball that’s outdated and needs to be removed?