Monitoring OpenVPN ports and the ways of Open Source

Years ago I wrote a small OpenVPN port monitoring script for my former employer. Over the time, it got multiple contributions from various users, evolving it into quite some sophisticated piece of software. For me, this is a powerful example how Open Source works even in small ways.

Years ago I created a small Python script to monitor OpenVPN ports for my employer of that time, credativ – under an Open Source license, of course. To be frank: for me it was one of my first Nagios/Icinga monitoring scripts, and one of my first serious Python attempts, thus the code was rather simple. Others probably would have done it in half the time with much better code. But it worked, it met the requirements, the monitoring people were happy.

Over the years, even when I left credativ and stopped working regularly on monitoring environments I carried on to be the maintainer of the code base.

And in fact over time it evolved quite a bit and got many more features:

• IPv6 support
• Python 3 support
• UDP retries
• response validation
• dynamic HMAC digests
• proper Python packaging structure

There were even packages created for Gentoo.

All those features and additions were not written by me, but by multiple contributors. This was only possible because the script was released under an Open Source license, here MIT, to begin with.

For me this rather small, simple example shows one particular way of how Open Source can work: different people had rather similar problems. Instead of re-inventing the wheel and writing their own scripts each time they picked something (I) which already existed and (II) solved parts of their problems, in this case my script. They extended it to fulfil their needs, and submitted the changes. Over time, this lead to a surprisingly sophisticated and powerful script which can be used by many others to solve an even broader range of similar problems. The process was not coordinated, unplanned, but created a worthwhile result from which all parties benefit.

This way of developing Open Source software is quite common – the Linux kernel is arguably the most prominent example, but a broad range of other projects are developed that way as well: Ansible, PostgreSQL, Apache, Kubernetes, etc. But as shown above, this development model does not only benefit the really large, well known projects, but works for small, specialized solutions as well.

To me, this is one of the most preferred ways to show and explain the benefits of Open Source to others: different parties working together – not even necessarily at the same time – on the same source to solve similar problems, extending the quality and capabilities of the solution over time, creating worth for all parties involved and even everyone else who just wants to use the solution.