ZSH shortcut: quickly commit using a function

I have many private git repos to manage all the configuration files, ansible playbooks, source code and other stuff you would want to version. Most of them are just for me to view and often I want to quickly ‘save’ my current process by creating a commit I can go back to.

I just recently switched to zsh after years of using bash – never had I thought that my life would change that much. So many neat little things that are really helpful and make my life easier. Themes, plugins and the oh so amazing oh-my-zsh really make it a pleasure to do stuff on the console. (I always have to bite my tongue once I SSH into a server that only has sh or bash now.

So in order to commit quicker without having to write two to three commands like add, commit & push one can create a function that does all that and takes some arguments in case you need them. During my research, as any scientist should do properly before reinventing the wheel, I found Hasan has thought of the same thing a couple years back. Here is my version of it:

gitc() {
        if [ "$1" != "" ]
                git commit -a -m "$1"
                git commit -a -m update # default commit message is `update`
        git push


The road to Kubernetes

I finally wanted to setup my own kubernetes cluster as everyone I talk to, said its the hottest shit.

I’m using three VMs, hosted at Netcup running the latest Debian 9 Stretch build. I’ve installed most basic tools for me and also already set up docker using this amazing ansible role. Make sure to disable any swap you have configured – kubelet will not start otherwise.

The documentation on how to install things is pretty good, but I’ve missed some details, that I banged my head on, so I will copy most snippets over for future reference. Keep in mind, that this might have already changed and is no longer working at the time you read this.

First install all needed CLI tools on each of the three hosts:

apt-get update && apt-get install -y apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
apt-get update
apt-get install -y kubelet kubeadm kubectl

Start the systemd Service for kubelet, our kubernetes manager – also on every node.

systemctl enable kubelet && systemctl start kubelet

Now the docs are a bit unspecific, but here’s a command to set the correct cgroup on Debian 9.


First check what cgroup docker is running under:

docker info | grep -i cgroup

Then use this replacement command to add the cgroup to the systemd service file and restart kubelet:

sed -i "s/bin\/kubelet/bin\/kubelet --cgroup-driver=cgroupfs/g" /lib/systemd/system/kubelet.service
systemctl daemon-reload
systemctl restart kubelet


Verify everything is working with:

systemctl status kubelet

If you see a failed state, you can use journalctl -xe to check for the error message. (You did disable your swap right? ;] – Hint swapoff -a)

Now we should be ready to setup our master node.

kubeadm init

If anything goes wrong, you can reset your master node using the following:

kubeadm reset

At this point init took me all the way and got stuck on the following message:

[init] This might take a minute or longer if the control plane images have to be pulled.

In my logs (journalctl) I could see some message related to docker, cni and Network problems. A quick google search lated lead me to this quickfix:

#domain bestsrv.de
#search bestsrv.de

Comment out the domain and search part in that file.

Then I got the following message:

"server4" is forbidden: not yet ready to handle request

Turns out, I had a service listening on port 80/443/8080 – make sure to stop that before you run init.

After that we need to install a pod network, that will allow our pods to talk to each other. By default kubernetes only bundles rudimentary networking but to fully utilize all feature, we will use weave:

export kubever=$(kubectl version | base64 | tr -d '\n')
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$kubever"

To enable the master to run pods, run the following command:

kubectl taint nodes --all node-role.kubernetes.io/master-

Then run the following command on your two other servers:

kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>

To finish up, we will copy the kube config file to our local machine in order to administer the cluster locally.

mkdir -p $HOME/.kube
scp server4.wdkk.de:/etc/kubernetes/admin.conf .kube/config
chown $(id -u):$(id -g) $HOME/.kube/config

Now we have a ready to go cluster and start using it.

I’ll post some basic commands in the next days.

Termina(l)te your way in style

Usually I love to use guake as my terminal in gnome, as it quickly hides using the F12 key and you always have your terminal in reach.

When doing more server heavy tasks, I often end up having several tabs in guake which tends to be messy. In those cases I love to use Terminator – the ultimate Terminal.

Quickly installed using the following:

# Debian / Ubuntu
apt install terminator

# Arch Linux
pacman -S terminator

Then you can use the following keyboard shortcuts to easily spawn new terminals the GUI way, instead of using tmux.

Ctrl-Shift-E: will split the view vertically
Ctrl-Shift-O: will split the view horizontally
Ctrl-Shift-W: will close the view where the focus is on
Ctrl-Shift-Q: will exit terminator

As a good friend and I today noticed: using all those fancy commands like tmux directly might be faster, but sometimes the GUI way is easier and more intuitive.

Arch Linux: Touchpad right click no longer working

I’ve been using Arch on my XPS 2015 edition since the very beginning. Not only was the support of the software components newer/better than Dell’s official Ubuntu version for the developer edition, but also I absolutely love the rolling release before it was cool.

So as we are bleeding edge, sometimes things break. Arch moved over to wayland some time ago, but like two days ago my touchpad’s right & middle click stopped working. Quick google search later revealed, that my gnome settings had the following option set to ‘fingers’. That didn’t work as my XPS has ‘areas’ – so switching it over with this simple command, fixed things for me.

gsettings set org.gnome.desktop.peripherals.touchpad click-method 'areas'


Easily add your Github SSH Keys to any Server or Docker Image

The default way to copy your ssh key(s) to a remote server is to use the ssh-copy-id command. This will create a secure connection to the remote server over SSH and then check if the user exists, create the folder&files if needed and add your keys. Works, Easy, Simple.

My problem is, that often I’m already in the shell and I logged in with some password combination, that I would need to enter a second time to copy my ids. Also I don’t always have all my keys on one machine. As I often get asked by my colleagues, what my SSH keys are, there is a nifty trick you can do, instead of sending them over via E-Mail.

Github allows to get your public SSH keys with only your username: https://github.com/<username>.keys

So with a little bit of magic we can utilize this and run the following command on an existing SSH connection to create a new authorized_keys file and download our keys from Github to the file.

curl https://github.com/kordianbruck.keys > ~/.ssh/authorized_keys


You can always use >> instead to append your keys. This can also be used in automated docker builds, where you have a SSH server running inside your container (which you probably shouldn’t ;D).


Github requires referer header field to login

So I’ve had this happen for some time now and could not determine the perpetrator as it was happening not really too often. From time to time I would encounter a error when trying to Login to Github:

Oops! Something went wrong. Please try again later.

In many cases this was related to something using oAuth but not in mine. I simply wanted to login to Github as usual.

So after some trial and error, I’ve noticed that disabling the “Referer Control” extension in chrome or chromium would solve the issue. My guess is they simply use that to prevent XSRF attacks.

Solution: Add an exception in the settings for Github as shown below

LetsEncrypt now used everywhere

So today I decided to move all my certificates from StartSSL to LetsEncrypt. Not only is StartSSL really a bad CA with recent problems, but also they limit you with several obstacles that just don’t make any sense. They really just want you to sign up for one of their “great” extended validation thingys. Over the last couple months they have really improved the web interface but still this is not enough to deal with today’s challenges of delivering secure connections to users easily. Their new APIs and StartEncrypt service are merely a late effort, trying to outbid LE with a worse service. Not worth the time or effort.

The biggest problem is, that today I run multiple domains on my server and I need to provide one single certificate with all domains via Dovecot / Postfix. StartSSL allows you to have up to five domain names in the certificates they sign. (For example www.bruck.me and bruck.me would be a total of two domain names) So I’ve ran out of the possibility of using all my domains with one StartSSL certificate. Well, LE offers up to 100 domain names in one certificate. Of course wildcard certificates would be nicer, but this will work as well.

I can really recommend acmetool as an interface tool with LE. I didn’t want any of that fancy magic stuff, as I use a nice webinterface to manage all my webhosts. acmetool generates the certificates after verification and puts them into a central location on the disk. It also manages renewals automatically, so I don’t have to deal with those either. Exactly what I was looking for! Setup is quite easy! Excellent job LE, on making this whole process open source and providing us with the possibility to build any client we want!

So, to summarize: acmetool great, letsencrypt even better, StartSSL meeeh.

No connection within eduroam WiFi at TUM

So recently I’ve not been able to connect to the eduroam WiFi at the Technische Universität München in Garching Forschungszentrum. I’m guessing the RBG is running some specialized DHCP server that is not compatible with the newest NetworkManager version in Arch Linux. So to fix this, edit the file “/etc/NetworkManager/Networkmanager.conf” and comment out this file like so:


Credits to Philipp and Simon, for saving me lots of headaches.

“libGL error: unable to load driver: i965_dri.so” fix

So I actually rarely encounter any problems with my Arch Linux, but sometimes they just want to see the world burn. Apparently after updating the mesa driver, so library got lost.

Easy fix:

# Arch Linux
mv ~/Android/Sdk/tools/lib64/libstdc++/libstdc++.so.6{,.bak}
mv ~/Android/Sdk/tools/lib64/libstdc++/libstdc++.so.6.0.18{,.bak}
ln -s /usr/lib/libstdc++.so  ~/Android/Sdk/tools/lib64/libstdc++/

Thanks to proft.me for providing this!