Karl Katzke

I’ve installed Semantic Mediawiki in our existing mediawiki instance at work to start tracking some of the data we need to retain for compliance and audit documentation purposes.

As the list of things that we support has grown, the number of servers has grown, and our documentation overhead has grown. Most of this documentation is in a relatively well-maintained mediawiki instance, but there are various parts of this solution that aren’t ideal. Namely that most of the documentation that we need to be able to generate for inspection on a moment’s notice is in manually generated lists, and is usually also pretty out of date. The need to document things like ‘who is served by, owns or knows the most about this application or server?’ has increased at the same time as the categories for each of those have broadened and blurred into one another. A good example is that two years ago, we supported two home-grown web applications deployed on one server. This year, we support upwards of ten web applications in four or five different frameworks deployed on three servers with a separate database server… and that’s just stuff that’s home-grown, not things we run in Drupal or Plone or some other framework.

The out of date problem has been partially solved by a quick run through the database with an out-of-date template and some snarky emails to the responsible administrators, but a longer-term solution that made it easy to extract the data needed to be put into place. Looking through the available mediawiki plugins revealed the Semantic extension.

The general gist of the plugin is that the data you need to extract is already in the document and just needs to be tagged as such. In our environment, especially, there’s tons of places where lists need to be generated — list of servers supported by a person, list of servers running which operating system, etc. so on so forth.

The nice thing about the Semantic Mediawiki extension is that it’s freeform. We have some servers that are maintained by one person, some servers where it’s preferable to contact one person over another, and some servers that are collectively maintained and used by as large as six people. The nature of semantic tagging means that we can put as many [[maintainer::kkatzke]] tags in as we want to, and then place them in the document in ways that are readable to a human as well as a computer.

The inline queries make it possible to generate lots of interesting lists right off the bat. I put a template in everyone’s user page that used the {{PAGENAME}} variable as an element of the inline query, and we can suddenly see what servers a person is responsible just by going to their User: page. By using the Special:Ask page to rite a query of the pages tagged with Category:server and display ?maintainer, we can extract the current maintainer information for either a report or just to know who to bust out of bed at midnight.

Now all I need is a way to keep the admins to keep it up to date. Since this approach will be easier than the current manual list templates, that should be about half of it… for the rest, I’m looking into crontab-activated cattle prods that will activate one week before campus IT reports are due.