Travis CI and Dependabot added to Anonimatron

With new European rules like the GDPR and local variations like the Dutch AVG, interest in Anonimatron is increasing. Although I do not keep track of who is using it and where, sometimes new requirements do pop up. Recently a feature was added to Anonimatron 1.9.2 to also anonymize files.

In the wake of those additions, I planned to give Travis CI a try to automate the builds. It turns out that Travis CI integrates beautifully with GitHub, and automatically builds branches and pull requests right out of the box.

Mattermost Delete Channel “fixed”

Users of Mattermost have probably noticed the less-than-optimal interface design where de Delete option is right above the Leave option in the Channel menu. On a busy server, you can imagine having quite a few incidents where people accidentally completely delete a channel.

In the Open Source version of Mattermost, everybody van do anything, because there is no sensible security model with roles. Mattermost Inc. seems to think that the Open Source community is not entitled to roles, which I (and others with me) strongly disagree with.

Forking Mattermost, learning Golang and enabeling security, improving a few other issues for the open source community along the way is a plan. But there is a simpler workaround for people running Mattermost inside Nginx.

Installing GPG keys for Debian Backports

For Let’s Encrypt to automatically renew certificates on your Raspberry Pi, you probably want to install certbot. The installation instructions of certbot tell you to make use of the Debian Backports packages. Following the instructions to install backports packages into apt-get on raspbian (which is a Debian Jessie), you will probably run into the following error:

$ sudo apt-get update
...
W: GPG error: http://ftp.debian.org jessie-backports InRelease:
   The following signatures couldn't be verified because the public
   key is not available: NO_PUBKEY 8B48AD6246925553 NO_PUBKEY
   7638D0442B90D010

macOS Sierra SSH “Permission Denied”

If you used DSA keys to log in to your SSH server and have upgraded your client machine to macOS Sierra (or OSX Sierra if you like), you probably ran into this problem:

client$ ssh -p 8123 george@10.0.0.10 -i ~/.ssh/id_dsa 
Permission denied (publickey).

The answer to this problem is replacing the DSA key with an RSA key, but how do you do on the server when your only means for connecting is the OSX client machine you just upgraded? Here’s how:

Open a port in OSX Mavericks’ Firewall

The new firewall in Mavericks is great. For the common user. For a developer, not so much. If you are a Java developer like me, and you just need to open one port (say, 8080) so that the web application you’re working on is accessable from another computer, you can’t. I disabled the Firewall altogether for a few days, but it didn’t feel right.

I googled around and to make a long story short, here’s how to open port 8080 on any interface to any application on your OSX Mavericks installation in 3 steps:

sudo vim /etc/pf.conf

Then add the following lines at the end of the file:

# Open port 8080 for TCP on all interfaces
pass in proto tcp from any to any port 8080

Test (and, according to the documentation, load) your edits with:

sudo pfctl -vnf /etc/pf.conf

Reboot.

(I have found at least 5 pieces of voodoo to make the Firewall restart and reload, but none of them seemed to work reliably, so pardon the reboot)

You can close it by commenting out the lines in pf.conf and reboot again. If anybody knows of an easier way to do this, preferably in one terminal command, and without rebooting, let me know.

Hope this helps.