Tools you can’t miss when starting a project #3 – document repository

Last week I decided to help what I think is a very good idea (more on that, I’m sure, in the future) try and get itself off the ground. In my mental preparations for this task, I began to wonder what we were going to need at the very beginning stages that would allow our work to proceed. I came up with this list:

  • Collaborative Software
  • Version Control System
  • Document Repository (with versioning abilities)
  • Issue Tracking Software

In the past couple of weeks I’ve talk about Collaborative Software as well as making sure your Version Control was up and running from the get go. Next on the list is the newest addition to my bullet points, as well as the one I personally know the least about. Although it’s the one I’ve personally dealt with the least, it’s also the tool that I’m quickly becoming a huge huge advocate for requiring.

Here’s the problem as I see it. When a project is first starting there is a lot of communication going on surrounding lots of decisions that are hard or impossible to change once a project is in motion or growing. These communications take the form of email, shared docs, official paper thingies, napkins, business cards, pages ripped from magazines, etc. Not only should you be documenting these decisions to shed light on them down the road, but you should also be versioning them whenever possible to show future contributors or employees how they evolved over time during these heady first days of your new endeavor.

This is where most groups fall down. This tool doesn’t exist in an infrastructure until way further down the road, if it exists at all. Those important initial documents, outlining visions and values and processes and structures are either a static document or lost altogether. I’ve seen groups tackle this two different ways in the past, and both involve another crucial tool being a stunt-double.

First I saw a group try and make their collaborative software shoehorn into this tool’s feature-set. If you have a robust collaborative software  application like Confluence it can work, but it’s going to be a huge effort to keep up with all of the attachements and mixes of media. It just wasn’t meant to be a document repository. Unfortunately this group was trying to use Trac, and it was a massive, confusing failure.

The second attempt I’ve seen at this was to try to use a version control system (in this case subversion) to handle the document repository duties. This also, technically, can perform the task. It CAN keep version copies of just about anything. However, the problem arose as this company grew. First off, the hierarchy of documents was amazingly complex in structure and permissions requirements, so managing SVN was significantly more complex than just maintaining a codebase. Secondly, the IT staff had constant trouble as CPAs and Project Managers and Sales Reps and Executives and everybody else tried to navigate and maintain this maze on a daily basis. This is still limping along, but begging for a better solution.

The best tool I’ve seen so far to handle something like this is Alfresco, by Alfresco, Inc. It tries to be a one-stop shop for several tools (collaboration, records management, web publishing, etc. according to their website), but where it really excels is Document Management. It’s simple, well thought out and it just works. There are, however, a few drawbacks.

  1. It has a community and an “Enterprise” edition. The Enterprise edition is a completely different animal based off of the publicly available source code. I just don’t like those fauxpen source models. Never have…
  2. Technically, there is a weak link in their application change. Whenever you view a document, you get a flash-based preview on the page, which is great. It uses a headless OpenOffice daemon to open the file and convert it to a PDF. It then uses pdf2swf to convert it to a flash object to display on the page. Clever, to be sure. And about as stable as mashed potatoes. We actually have a zabbix check that automatically restarts OpenOffice when it randomly eats itself on this server.
So I haven’t found the best tool out there, I don’t think for document management. If anyone knows of anything else I’d love to hear about it. But I do think that having this solution in place as a project gets off the ground is critically important to help document that process and inform people down the road.

Zabbix 1.8.4 with Postrgesql 9.0 on CentOS 5.5

If there is any single application that I consider myself a complete and utter homer for, it’s Zabbix. I’ve talked about it here, and my hope is to toss out at least one fun Zabbix-related tidbit each week.

Today’s fun is something that I ran into just this past week. We are currently running Zabbix version 1.8.4. The latest stable version of Zabbix is currently 1.8.5, but we’ll likely hold out until Version 2.0 before we upgrade.

A couple of months ago we moved our Zabbix installation off of a shared utility server to it’s very own HP DL-380 full of RAM and hard disks. When we made this move we also upgraded Postgresql from 8.4 to 9.0 using PGDG. All seemed well and good until it came time to build out some really cool maps that Zabbix makes so easy. My first map was going to be a map of the health of our VPN network utilizing some fun network latency checks that I’d just made using Zabbix Simple Checks.

When I went to add the first map background, it said it uploaded it just fine. But in the Zabbix GUI it didn’t show my cool US Map. When I looked at the stock images that come with Zabbix none of them showed up, either. In place of the graphic it simply said “No Image”. Clicking on that link kicked up a PHP error that the data wasn’t a valid image type. Zabbix stores these graphics in the database as BLOBS, and uses php-gd to render them into the page.

After approximately 3 hours of staring at PHP and random googling, I stumbled upon ZBX-3063.

As it turns out, there was a change in Postgresql 9.0 that altered how it outputs binary data. This change caused Zabbix to flip its biscuit a little bit. Happily there’s a simple patch, outlined in the Zabbix issue tracker.

#diff -u
— 2010-09-30 13:14:29.000000000 +0400
+++ 2010-09-30 14:12:21.000000000 +0400
@@ -83,6 +83,10 @@
$error = ‘Error connecting to database’;
$result = false;
+/* if pg_version exist and begins with the nines then set bytea_output = ‘escape’, as PG9 new hex bytea default type output. */
+ elseif(($ver = pg_version($DB[‘DB’])) && preg_match(‘/^9.*/’,$ver[‘server’])){
+ DBexecute(‘set bytea_output = escape’);
+ }
case ‘ORACLE’:
$connect = ”;

And *POOF*. An apache reload and Zabbix is happily rendering my cool maps and dots. Click the pic below to enlarge.

5AM VPN Health map.
5AM VPN Health map.

One of the coolest things about Zabbix is the ability to create maps. In this map each dot represents one of our VPN endpoints, changing colors if issues arrive. Each line changes color depending on VPN latency and packet loss as well.  Total time to make it – 20 minutes.