I talked a while ago about the monitoring stack I was using: TIG. I have moved to something else for the past year, so I wanted to talk about my experience with it.

This post won’t be a tutorial, for two reasons. First of all, it’s way too complex to be contained in single post, and secondly I have set up the whole stack using Ansible roles I made myself.

The main difference between a Telegraf + InfluxDB setup and Prometheus + Node Exporter is the exporter part. We could differentiate these as push mode and poll mode. Basically, Telegraf will push the metrics to InfluxDB while Prometheus will poll the data from Node exporter.

About a year ago, I started to manage my laptop via Ansible (as much as I could, at least). I had some software installed via snapcraft, a new package manager from Canonical.

There was no Ansible module for snaps at the time, which was pretty surprising considering snapcraft has been getting quite some traction in the past few years. I assume it’s mostly used on desktops, and Ansible is mostly used on servers, hence the missing module.

I have trouble finding this every time I need so I figured out I’d make a post out of it.

Single-node Elasticsearch clusters make sense for non-critical data when money has to be saved, or testing/dev.

By default, ES will create multiple shards for each index, with at least one replica. However, on one node the shards will never get replicated, so the cluster health will always be yellow.

To fix that, you need to create a template that will match all futures indexes and set those settings. Ideally you’ll want to do that before indexing anything.

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.

I recently got a Dedibox from Online.net in order to move my Nextcloud instance over (need that storage!).

Since I’m really interesting in FreeBSD these days, I decided to use it on this new server along with ZFS.

FreeBSD 12.0-RELEASE only came out a few days ago so there is no installation option available on the online.net console yet. However, FreeBSD 11.1-RELEASE is available. The thing, it only allows to use UFS. I don’t like proprietary installers anyway, so I decided that I’d install FreeBSD manually on this box. Plus, it really feels great being in total control of my machine, in the sense that I know how it is set up.

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.