chr4

Devops Diary

Homebrew betrayed us all to Google

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.

Edit: I’ve been contacted by a Homebrew maintainer and have been asked to remove the link to the Github issue. His arguments about keeping the issue to the topic convinced me, and I was sad to hear that he apparently received tons of personally insulting emails. When I asked for a more appropriate way to provide feedback, he didn’t give any and stated that they won’t make the tracking procedure opt-in. They also have removed all comments regarding complaints about their tracking from the issue. I wrote a final comment in the comment section, which was deleted immediately. For completeness, I’m quoting it here:

While I can understand you want to keep this Issue productive, I find it disturbing how Homebrew deals with massive complaints from an open-source loving community (see HN, Reddit, etc. discussions). Don’t just delete this away and hope everybody just forgets about this.

I know this will probably be deleted in a minute and you guys will probably ban me, but I’m still writing this so people get notified via email/ etc.

There are people out there for whom this is a serious issue. I beg you do not take this lightly. I want to tell people “Homebrew is good, use it” and not “Homebrew is kinda good, but before you use it make sure to paste this-and-this in your terminal and also block this and that, otherwise you’ll be tracked”.

Dualstack multiple IP addresses with systemd-networkd

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).

Increase password entropy on developermail.io

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.

Howto secure openssh-6.x

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.

conf.d like directories for zsh/bash dotfiles

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).

gittree: bash/zsh function to run git commands recursively

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)

Nested if workaround for Nginx to allow a specific ip address access to a disabled site

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.

iptables-ng cookbook for chef

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

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

ipswitch - migrate IP addresses without downtime

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