Blog

Found a post whilst reading a post by the Standalone Sysadmin… and it is a beauty. Michael Janke has a post comparing ad-hoc versus structured systems management.

One of the items that Michael says is essential for structuring your systems management is automation. As Matt Simmons says:

Remember, if you can script it, script it. If you can’t script it, make a checklist

In the Windows world automation has been a pretty tough ask until Windows PowerShell came onto the scene. Whilst it was possible to script Windows with VBScript, it wasn’t easy or quick. If it isn’t easy and quick it probably won’t happen.

… between various flavours of Windows. Not sure what Microsoft have done on Vista and Server 2008 but it hasn’t half slowed down WMI performance. Thankfully the latest release candidate of Windows 7 has much improved performance.

Oops!

Paessler have introduced a new product called Multi Server Simulator, currently available as a pre-release version, that creates a simulated network of devices and switches.

The main use for network simulators is for testing network management software. However, network simulators do have plenty of uses outside of software development.

If you are evaluating network monitoring software you may not want to unleash it on your live network. Network simulators like Multi Server Simulator allow you to create a test lab completely separated from your live network. There isn’t much point in subjecting your network to a piece of software if it can’t scale up to the job.

The recent controversy over the ICINGA Nagios fork brought into focus the relative activity of the various network management projects.

One of the main complaints aimed at Nagios was the slow speed of development. The following graphs, taken from the open source directory ohloh, show the number of committers and the number of commits over the last three years for Nagios, OpenNMS and Wireshark. I can’t vouch for how accurate the stats are but I think they do provide some insight into the development processes of the respective projects.

A real world example of what Tarus Balog from OpenNMS has been banging on about recently with his critique of open core or fauxpen source as Tarus calls it.

A product manager who has an open product and a closed product plainly has a decision to make over which features go into which product. Give too much away and the value add of the closed enterprise product is insufficient to warrant the licence fees. Put too many features into the enterprise product and the open source offering becomes useless.

The first ICINGA beta has been released with a new GUI written in PHP 5 utilising the Agavi MVC framework. A project roadmap is available so you can see where the project is headed.

If you’ve ever wanted to know the status of your Nagios installation without having to open a browser, you may find Naguino a fun and useful addition to your monitoring toolkit.

All you need is the Arduino board, an ethernet board, a LCD screen and some software.

Ethan Galstad, the Nagios founder, has responded to recent criticisms of Nagios and to the recent ICINGA fork. It does seem a little ironic that, although the ICINGA founders claim one of the drivers behind the fork was a lack of communication, Ethan Galstad claims they didn’t communicate their dissatisfaction to him.

Open source is a term used to cover permissive licenses for software. Generally speaking, if software is covered by an open source license, you have a right to the source code for that software, as well as the ability to modify that software and distribute your changes to others.

What are Trademarks?

“A trademark, trade mark, or trade-mark is a recognizable sign, design or expression which identifies products or services of a particular source from those of others.”

Matt Asay over at The Open Road commented recently that forks are a sign of strength in open source. I’m sure he’s right, but they are not necessarily a sign of strength for the project being forked. The one positive thing is that it makes the community sit up and review the root cause of the fork.

As Andreas Ericsson says in his post The future of Nagios, recent events have demonstrated weaknesses in the structure of the Nagios project, specifically that Ethan Galstad is the only committer of fixes and enhancements to Nagios. A single committer is fine until the committer doesn’t have sufficient time to work on the project as might be required to keep up with community submitted fixes and enhancements. Understandably, individual contributors are going to get frustrated that their patches and enhancements are not being incorporated into the project.