I was listening to an interesting talk from Laura Frank from Codeship. In case you build or maintain a Continuous {Integration, Delivery} environment this definitely worth watching and they describe how they used LXC and now Docker to build their CI/CD infrastructure.


Interesting to me, the description in the YAML file reminded me quickly on a course I needed to pass during my study in parallel computing. The exam had one section where you had to describe parallel and sequential processes with some high level constructs. You had to describe a given time sequence graph for processes on n processors with the primitives BEGIN/END for sequential parts and COBEGIN/COEND for parallel processes.

We are all happy when we are able to get IPv6 connectivity for our new servers. In case the network is provided by someone else and some kernel settings you can get in some tricky situations.

With IPv6 there are so many addresses your Laptop and Mobile can have a unique public IPv6 address forever - pretty cool huh? The downside is, it would be pretty easy to trace every connection you ever do back to your device - this really not what you want! When you provide a service this behavior is not so useful. Otherwise there are several ways to autoconfigure your IPv6 configuration, beside DHCPv6 the interesting one is stateless address configuration.

Stateless address configuration means, your server is allowed to construct himself an IPv6 address without the need of DHCPv6 server. Simple explained, a router with IPv6 runs the Router Advertisement daemon. He sends via link local router advertisement (RA) packets and inform others "Hey! I'm the default router for the 2001::/64 network". This advertisements are sent out at a certain interval and this way your server gets the information what the LAN IPv6 network is.

The RA packets can have some flags:

  • A: Autonomous Address Autoconfiguration tells your server it should perform a stateless address assignment
  • M: Managed Address Configuration tells your server it should use stateful DHCPv6 to acquire its address and other DHCPv6 options

With the flag set to A your server will create an IPv6 address in the given network space. To make your server "untracable" the Privacy Extensions kicks in and basically randomizes and changes your IPv6 address over time.

You can verify the configuration with

sysctl -a | grep use_temp

net.ipv6.conf.VPN.use_tempaddr = 2
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.em1.use_tempaddr = 2
net.ipv6.conf.em2.use_tempaddr = 2
net.ipv6.conf.lo.use_tempaddr = 2

In Ubuntu you can set the kernel settings so they survive a restart set the configuration in

cat /etc/sysctl.d/10-ipv6-privacy.conf

net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2

If you want to set the parameter as default for every new network device set

sysctl -w net.ipv6.conf.all.use_tempaddr=0
sysctl -w net.ipv6.conf.default.use_tempaddr = 0

This setting can also be configured for a specific interfaces, here the command for eth0

sysctl -w net.ipv6.conf.eth0.use_tempaddr=0

If you have the kernel settings set to 2 means prefer privacy addresses and use them over the normal address. Set the kernel parameter to 0 to disable privacy extensions.

OpenNMS uses SNMP and during the provisioning and discovers IPv6 addresses. For the provisioning there are not a lot of possibilities to figure out if an interface is down or doesn't exist anymore. If you have Privacy Extentions enabled your server looks somehow like the screenshot below.

OpenNMS with IPv6 temporary addresses

In this situation you can exclude the IP interfaces with an IP match policy or you disable Privacy Extensions on your server.

Links around this topic:

Notifications are important if you do monitoring. I never liked mail notifications from monitoring systems where all the information is hidden in non-sense text. Otherwise notifications never look the same, so I'm always forced to read all that useless crap again and again. This is an approach to improve the usability of monitoring notifications using more a table pattern which helps me to recognize useful information much quicker.

Probably a lot of E-Mail guys will hate me for the reason I'm using HTML in mails. The notifications work so much better for me so I don't care. I've used just inline CSS and there is no JavaScript involved. All the things are in the mail and there are no external resources loaded. Here is how I work with OpenNMS mail notifications.

Mailbox with OpenNMS notifications
My Mailbox with OpenNMS notifications.

I use a tagged subject line <1> to get notifications filtered. The severity variable in OpenNMS notification is used to assign a color.

To get quickly to the source of the problem, I created the object information as a link <2>. In this case it gets me to the resoure graphs of the node which had the high threshold exceeded notification.

I've created a inline CSS style named after OpenNMS severities so the status color <3> is correct assigned based on the severity of the event which triggered the notification. Additionally the measured value which exceeded the threshold is red colored <4> and added also some context information how the threshold is configured.

The links to the notification and event details jump to the correct places in OpenNMS <5>.

To give some more context what kind of node has a problem, I've added some asset information which are imported form the OpenNMS Provisioning system. I can see what operating system is installed, product number, serial number and where it is located.

I ran into an issue regarding the RESOLVED prefix for resolved notifications. The prefix is added not just to the subject, also added as the first line of the original notification. Probably there is some code change necessary to get this thing sorted.

If you like mail notifications and you want to give it a try, I've dropped my configuration in a GitHub repository. The notifications look also nice on my phone and happy to add some monitoring love to OpenNMS.

Feel free to fork, improve and share.

Am 30.03.2015 haben wir im Büro 2.0 in Berlin einen Workshop mit OpenNMS durchgeführt. Die Zielgruppe waren NeueinsteigerInnen und alle die Interesse an Monitoring mit freier Software haben. Es wurden Installationszenarien, das Provisioning und beispielhaft diverse Monitore für Anwendungen und Dienste eingerichtet.

Die Slides sind unter einer freien CC-BY 3.0 lizenziert und stehen auf GitHub zur Verfügung.

Büro 2.0 in Berlin
Workshop im Büro 2.0.

Für diejenigen, die kurzentschlossen sind – hier eine letzte Erinnerung für einen kostenfreien Kickstart workshop zu OpenNMS. Die Registrierung und Anfahrt findet ihr unter: