TL;DR: Use use_vmac directive in keepalived when using multicast and your carrier allows multiple MAC addresses per interface. If that’s not an option, migrate away from netplan/systemd-networkd, e.g. to ifupdown.

I’ve written a small tool to warm-up HTTP caches, e.g. services like nginx.

Source code as well as compiled releases are available at Github.

When configuring or programming SSL/TLS servers, at some point a SSL/TLS cipher suite and a list of supported protocols have to be chosen. Unfortunately, not all configuration options are safe. :(

Meet sslsecure.vim! A plugin for the Vim editor, that marks insecure SSL/TLS cipher suites and protocols as errors. See all potentially insecure options right in your editor!

Features

• Mark insecure SSL ciphers as errors
• Mark insecure SSL protocols as errors
• Works with all configuration files (web servers, mail servers, …)
• Works with all source code (independently on the used programming language)
• Works on top of regular syntax highlighting

I’m editing nginx configuration files. A lot. Naturally, I’ve tried several plugins for my favorite editor vim - but ran around a lot of problems:

• Most of the plugins available are outdated.
• Even syntax highlighting of the current vim plugin distributed with the nginx release has some deficits.
• I’ve been tired of copying around secure ssl_cipher directives, etc.

So, I’ve created a new, super-cool and mega-advanced vim plugin for nginx!

Ladies and gentlemen: Please welcome, chr4/nginx.vim!

Edit: This plugin was integrated into Vim and Neovim upstream!

Features

The plugin is based on the recent vim plugin distributed with nginx-1.12.0 and additionally features the following syntax improvements:

• Highlight IPv4 and IPv6 addresses
• Mark insecure ssl_protocols as errors
• Inline template syntax highlight for ERB and Jinja
• Inline syntax highlight for LUA
• Improve integer matching
• Syntax highlighting for proxy_next_upstream options
• Syntax highlighting for sticky options
• Syntax highlighting for upstream server options
• More to come!

Furthermore:

• Remove annoying delimiters, resulting in strange word boundaries

One Go feature which I’m using regularly is cross-compiling Go code to other platforms (usually from macOS to linux-amd64).

In Go, this is a built-in feature that “just works”. The following command produces a statically linked ELF binary which can simply be copied and run on a Linux machine:

Note: This is a follow-up post to Writing An Interpreter In Rust

Thanks for all your feedback, explainations and pull requests! I’m pretty overwhelmed by the feedback and I can confirm that the Rust community is very friendly and extremly helpful.

In this post, I want to quickly review some of the changes to my implementation of the Monkey interpreter I’ve made with your help. I’ve implemented a small benchmark (Disclaimer: I’ve just put next_token() into a #[bench], I’m not sure whether that’s the best practise for this kind of tests), and the results are really impressive so far!

Last month, Thorsten Ball released his first book: Writing An Interpreter In Go. It’s an awesome book that teaches its readers how to write their own programming language, step by step. It comes bundled with the complete Go code, including tests.

While reading it, I was looking for a challenge. I’m a huge fan of Rust, a safe systems programming language by Mozilla, so I thought it might be a good exercise to port the Go implementation of the programming language “Monkey” to Rust.

Here’s an example of what Monkey code looks like (you can find more examples here):

Mozilla launched a “free, automated and open” certificate authority called Let’s encrypt. As the name suggests, it provides free certificates trusted by all (major) browsers and operating systems. I’m using it heavily (on this blog, for example).

This blog post shows how Syncthing can be used to deploy letsencrypt certificates in an environment with multiple servers (e.g. in a round-robin scenario) without adding a single-point-of-failure.

I recently wrote pg-check-cert, a small tool to check whether a postgresql server’s SSL certificate is about to expire. It was featured in PostgreSQL Weekly Issue 164.

This script connects to a postgresql instance, checks the certificate and displays the amount of days left before it expires. It’s intended to be used for monitoring your postgresql certificates, using a monitoring tool like Zabbix or Nagios.

Around the year 2000-2002 (back in the days when Snort was still super young (and I haven’t heard of it yet), I decided to write a small network traffic analyser, which could serve as a “poor man’s intrusion detection system”. It was basically a C daemon configured with a ini-like configuration file, watching for network events.

If I remember correctly, I wanted a way to detect the (then pretty new and fancy) nmap stealth scan mechanisms (like half open, xmas, etc), and counter them with alerts and on demand firewall rules.

I just stumbled upon the old C source on my harddrive ssd on my macOS machine and tried make just to see what would happen. Back then I operated some FreeBSD/ OpenBSD and Linux servers, and I didn’t really expect much to happen besides tons of errors.

As it apparently still compiles and runs today (even on macOS), I’ve decided to upload the code to Github.

I encountered the following issue when running RabbitMQ on a host with the hostname 1.rabbitmq.staging:

Homebrew is arguably the best package manager for OSX around. It’s a great project, I’ve been using it for years, and it’s doing what it’s supposed to in a very clean manner. Unfortunately, the team decided to track the behaviour of its users via Google Analytics.

This is bad.

1. Open Source is about trust. Trust is underminded by things like tracking.
2. Do not track your users. In the rare case you really need anonymous data, ask your users first.
3. Never use Google products (or any other “big data” company that relies on making money out of the data you provide) to track your users.
4. Using Google’s tracking and then calling it “anonymous” is a lie. Google collects tons of information of its users and even non-users. There’s no way to know what data Google will relate internally. Even if you don’t get to see all of the collected information, Google still has them.
5. Opt-out is never an excuse. It always excludes most users (which either don’t care, or have more severe things to care about than protecting their privacy in every random app they’re using).

Read on to lean howto fix the issue for at least yourself.

I’m using systemd-networkd on Archlinux on one of my servers to configure the static IP addresses. While this seems pretty straight-forward, there’s a big issue that you can bump into when trying to configure multiple IP addresses. As this took me some time to figure out and it’s not well documented, I decided to leave a blog post for future me (and possibly others).

I recently co-founded an email SaaS for developers called developermail.io where tech-savy people can configure their email mailboxes using git. We just released a new feature, which enables you to use high-entropy passwords with our services.

In this blogpost I’ll quickly show you howto generate more secure passwords for your developermail.io account and mailboxes.

Since OpenSSH 6.x came out, a lot of new ciphers where introduced. I was wondering, which ones where the best and what I should use, and I read a few articles on the internet to find out.

I’m certianly not a cryptographer, so if you have any suggestions howto further improve the configuration below, feel free to contact me.

As a general statement, one should avoid ECDSA and use Ed25519 instead, and due to the fixed key length of DSA that ssh-keygen uses, DSA should also be avoided. RSA keys should be at least 2048 bits long, perhaps 4096 bits is the better choice.

I don’t like messy dotfiles.

The thought of having tons of random configuration entries in files like my .zshrc really bothers me, so I implemented something that works like a conf.d like directory structure for my shell dotfiles.

I also still use the bash shell in certian situations, and I want a more or less consistent environment, no matter which shell I use (bash, zsh).

With the following setup, it’s possible to have the following:

• A directory called zshrc.d, which includes multiple, zsh related configuration files.
• A directory called bashrc.d, including multiple configuration files concerning bash.
• A directory called rc.d, including configuration items needed by both shells.
• A directory called login.d, including elements included by .bash_profile resp. .zlogin.

This keeps your dotfiles nice and clean, and also allows you do have additional files on systems where you need them, without them being included on all your systems (e.g. your $GOPATH).

I’m using Androids repo tool from time to time when dealing with large groups of git repositories. In most situations, it is too bloated though. Some git “batch” commands I found very useful, like repo status, checking the status of all git repositories recursively.

To mimic this (and other) behaviour in a simple way, I created the following bash/zsh function (put this in your .bashrc or .zshrc, or another file where you define functions in your dotfiles)

Today I found out howto resize guest partitions on OpenNebula (or in general with libvirt, which OpenNebula uses underneath for KVM virtualization).

I’m using a LVM storage for virtual machines. So resizing them is pretty easy.

When doing maintenance on a web application, you probably have a custom 503 site, showing your customers that the servers are currently lying on the operating table.

At the dynamic ridesharing service flinc, we touch a certian file on our reverse proxies (e.g. using capistrano deploy:web:disable) when maintenance begins. Nginx then serves a static “we’ve disabled the site for maintenance” site, instead of the actual content.

But wouldn’t it be nice to test your web application before going live for your customers? It sure would. Unfortunately, this is not as simple as a task as you might think, because you cannot nest if directives in an Nginx location and if is evil.

Today, I released iptables-ng, a cookbook to maintain iptables rules on different machines using chef.

But why another cookbook? There are two fairly often used around

• iptables from Opscode
• simple_iptables from Dan Crosta

Well, I wanted a tool which can do all the following:

• Configure iptables rules in a consistent and nice way for all distributions
• Be configured by using LWRPs only
• Be configured by using node attributes only
• Respect the way the currently used distribution stores their rules
• Provide a good-to-read and good-to-maintain way of deploying complex iptables rulesets
• Provide a way of specifying the order of the iptables rules, in case needed
• Only run iptables-restore once during a chef run, and only if something was actually changed
• Support both, ipv6 as well as ipv4
• Be able to assemble iptables rules from different recipes (and even cookbooks), so you can set your iptables rule where you actually configure the service

When doing quick maintenance tasks on a server, you can use the following approach to keep your site available:

• Failover the backnet IP address of the host to another host
• Use arping to tell the network that this IP was switched
• Remove the IP from the host that needs maintenance

In case you do not have a full high availability setup available, you can use ipswitch, a small tool I wrote to assist with this kind of simple failover tasks.

You can install it using

$ gem install ipswitch

Just a short post about some useful cleanup commands for Debian and Ubuntu systems. There are (to my knowledge) no build in task solving the following things

• Remove old kernels (while keeping the currently running and the latest)
• Purge removed packages (especially after autoremoving unneeded dependencies)

By default, the connections between the chef-client and the chef-server are not secured. This is a short post on howto encrypt and verify your connections.

As of chef-11 (unlike chef-10), SSL is enabled by default. But (naturally, as Opscode cannot create trusted certificates for your domain) the certificates are not verified. This essentially means that the connection is not secure at all.

Unless you only use chef in a trusted network, you should invest some time in securing your clients connections.

One thing that was annoying me for a long time, was that, using Capistrano deployment, you cannot spawn a new vanilla virtual machine, and bring it to a fully up-and-running state with just one Chef command.

make deploy_revision compatible with Capistrano, so deployments can happen with Capistrano, until we’ve decided to fully migrate to Chef, or to stick with the push deployment

On our rails and worker servers at flinc, we recently migrated the ruby version management from rvm to chruby.

Besides the usual arguments against rvm, like preferring unpatched cd commands, there was another reason:

The fnichol’s chef rvm cookbook has some issues.