It is only recently that I've discovered the Advent of Code, a coding challenge happening on December (though available all year) since 2015 and it is quite unique. I've set out to solve the 2015 puzzles in AWK (you can find my solutions here). Very soon one of them required to compute (a lot of) MD5 hashes. After some research, I found out there are basically three solutions:

  1. Using a pipe. This is expected to be slow, relying on an external program, but very simple to implement.
  2. Write a dynamic extension in C or C++. This should yield very good performances, but would be limited to GNU Awk and tedious to deploy as it would require compiling.
  3. Implement MD5 in AWK. This is expected to be portable and very slow, but more importantly a lot of fun.

In this post I'll go through the implementation of MD5 in AWK by first writing a GNU Awk version (because of some of its features), then porting to AWK, and finally optimizing. The main challenge is that MD5 is basically a lot of bitwise operations on 32-bits integers and AWK has neither. If that sounds interesting to you, sit comfortably and read on — this is going to be a long ride.


Not long ago, I had to setup an Ubuntu VM (I'm running them through bhyve by the way, and it's really sweet). But the day after, to my surprise, the lovely heartbeat email $hostname daily run output I've been used to was nowhere to be found. After a quick check, the Ubuntu cron "periodic" stuff doesn't output anything unless something go wrong.

I could easily add scripts into the /etc/cron.daily directory, but then I would have to handle the output "by hand" if they should or should not report something and the email subject would be the ugly cron line: Cron <root@$hostname> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

Ultimately I realized that my dream was something like OpenBSD daily(8) that I am used to (they say old habits die hard). Since they are simple POSIX shell scripts, I've hacked them a bit to run on Ubuntu.


Hi everyone, happy new year :)

While Dovecot support a lot of different password schemes, making both Postfixadmin and Roundcube playing nice by using something else than the old MD5 scheme need a little work.

In this post I'll explain how to configure them to use a Blowfish scheme (BLF-CRYPT in the Dovecot terminology), but you can easily adapt the steps to use something else. You should already have Dovecot, Postfixadmin, and Roundcube (with the password plugin) up and running.


Ahoy !
I realized that forgot about half of the Rspamd & Dovecot in my last article, so here is an attempt to correct this misstep.

In this article we'll configure Dovecot's Sieve to understand how Rspamd assign spam score and headers to emails. Then, we'll implement policies to reject or filter spam from Sieve. If needed, we'll use the spamtest and spamtestplus Sieve extensions.

i3wm Logo

Since the update to 15.04 "Vivid Vervet" I've experienced some new input issues: I could not input some characters, most notably those requiring a combination of key to press. With a swiss-french layout I could not input stuff like ` ^ ~ and use my configured compose key. The culprit was unknown to me until then: IBus.

To solve this issue, you can either launch im-config(8) as user and select the "none" Input Method or simply do:

% echo "run_im none" > ~/.xinputrc
Now restart X and enjoy your keyboard back.
FreeBSD Logo

I had an issue while trying to run a php-fpm FastCGI process from a FreeBSD jail using nginx from the host. Like many others I experienced the infamous White Screen Of Death™ but no errors were logged at all (even with the full debug config all set from both php-fpm.conf and php.ini).


# ...
upstream princesse-bulldozer-php-fpm {
    server [2a01:4f8:120:5388:0:b:249:1]:9000;
} server {
    listen   *:80;
    listen   [::]:80;
    # ...
    root /usr/jails/;
    index index.php;
    # Pass all .php files onto a php-fpm/php-fcgi server.
    location ~ [^/]\.php(/|$) {
        fastcgi_index index.php;

        fastcgi_pass princesse-bulldozer-php-fpm;
        # fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param SCRIPT_FILENAME /home/$fastcgi_script_name;
        include fastcgi_params;
  1. As nginx is run from the host, using the "full" path as root is correct.
  2. Since php-fpm is jailed, the SCRIPT_FILENAME path should not use $document_root
  3. … but use the "jailed" path instead.

Hope it can avoid a couple of painful debugging out there :)