Recently, I have been publishing some Ansible roles on GitHub, so I have been thinking about what kind of CI to set up.

The most famous tool for this task is Molecule (that’s what we use at work). It can run entire test playbooks to make sure they work exactly as expected.

I really don’t have the time to do that, and my roles are not critical for production, so I settled for a simple linting pipeline. I am using the also well-know ansible-lint which will validate the YAML files and enforce Ansible best practices.

WireGuard is a fast and modern VPN protocol.

It is a point-to-point VPN, which means it does not have a client-server architecture, but peers, and does not rely on a PKI, unlike OpenVPN. It is super simple to setup to connect multiple machines together.

WireGuard supports roaming, which means you can switch between network connections and not have to reconnect to your peers. On servers, it’s rarely useful, but when one of the peer is a mobile client like a laptop or a smartphone, it’s a life saver, because the usage of WireGuard is completely transparent.

Here’s a quick tip, that also applies to any linux machine using dhcpd.

Every now and then my Raspberry Pi or my router can reboot, and I’m not certain than my Pi will get the same IP address from the DHCP server.

Sure, I could fix it on the DHCP server using the Pi’s MAC address, but if you’re a lazy bum like me you can tell dhcpd to request a specific IPv4 address.

Hetzner recently introduced Block Volumes for their cloud product. It’s a very useful feature that allows to add tons of fast and redounded storage to VMs.

I wanted to move my Nextcloud over Hetzner Cloud for quite some time now, but was unable to do so because of the available storage. Now I can!

Since my Nextcloud contains sensitive and personal data, I don’t really want to my files to be written on a public Ceph storage cluster… Fortunately, I can encrypt my volume very easily thanks to cryptsetup. In this tutorial, I will show you how.

After 3 years of service, my Raspberry Pi’s filesystem finally got corrupted. I expected it to crash earlier, but it lasted for quite a while!

Even if I had backups, I did have to reinstall it from scratch. I was using Munin to monitor my Raspberry Pi, and I think it’s a good solution for this kind of device because it’s lightweight and performs very little I/O.

Anyway I decided to upgrade my monitoring stack, as on the rest of my infrastructure, with the Telegraf - InfluxDB - Grafana (TIG) stack. I used an USB key (🤷🏻‍♂️) as the storage for InfluxDB. We’ll see how it runs in the long term!

Caddy’s default TLS configuration is very good. It includes a lot of features that older and well-known servers like Nginx or Apache don’t enable by default.

From the tls module’s documentation:

Caddy implements these TLS features for you automatically. It is the only server to do so by default:

• Session identifiers
• Session ticket key rotation
• OCSP stapling
• Dynamic record sizing
• Application-layer protocol negotiation
• Forward secrecy
• HTTP/2 (for the HTTP server)
• Certificate management (including auto-renew)
• Man-In-The-Middle detection (for HTTPS sites)

Pretty awesome isn’t it? It also enables TLS 1.2 only by default and will support TLS 1.3 soon. FYI Caddy does not have its own TLS implementation by relies on the crypto/tls module of Go.

TLS 1.3 is the new TLS version that will power a faster and more secure web for the next few years.

The final release of TLS .13 has been out since august 2018. The final draft is supported by OpenSSL in its 1.1.1 version.

LibreSSL does not support TLS 1.3 as of today, since they want to do a clean implementation.

Nginx supports TLS 1.3 since version 1.13.0 (released in April 2017), when built against OpenSSL 1.1.1. Before the stable OpenSSL release, it has been possible to build Nginx with OpenSSL 1.1.1 pre-releases, containing TLS 1.3 drafts. It is important to note that drafts of RFC 8446 can be incompatible.

When running a GlusterFS cluster, you may want to use the volume(s) on the servers themselves.

During the boot process, GlusterFS will take a bit of time to start. systemd-mount, which handles the mount points from /etc/fstab, will run before the glusterfs-server service finishes to start.

The mount will fail so you will end up without your mounted volume after a reboot.

After doing to some research to fix this issue, I stumbled upon this Ubuntu bug report from 2011 (!). At the time, systemd wasn’t the init system, but in 2016 someone posted a pretty good solution for systemd systems.

When I began publishing public Docker images, I was using the GitHub integration with the Docker Hub to automatically build and publish my images.

However, the Docker Hub is very slow to build images and has very, very limited configuration options.

Then I discovered Drone which allowed me to build images on my own server, tag them, etc. The thing is I’m limited by the drone-docker plugin and I can’t do everything I want with it.

In my last post I presented Drone, an extremely light CI/CD server.

One cool and satisfying thing is to be automatically notified of the output of your pipelines. In a company, you would probably use a Slack or HipChat bot. For a personal use, I think a Telegram bot is a good idea.

Let’s setup one!

Creating a Telegram bot

Setting up a bot is free and actually very easy. You can do everything from a Telegram client.