Le Blog Utux

Il fut une époque où je ne comprenais vraiment pas l'intérêt de Red Hat car j'y voyais une distribution payante avec très peu de logiciels disponibles dans les dépôts (même pas nginx) et des composants encore plus obsolètes que Debian. Et puis à force de voir son clone gratuit - la distribution communautaire CentOS - utilisé partout en entreprise j'ai enfin compris ce qui plaît :

• Le support de 10 ans (à une époque j'étais naïf, je pensais que les entreprises installaient rapidement les mises à jour et n'aimaient pas se traîner des vieux logiciels... en fait c'est tout l'inverse !)
• Les correctifs de sécurité backportés, ce qui permet de mettre à jour sans vraiment mettre à jour.
• L'écosystème logiciel et matériel, c'est rassurant d'avoir un contrôleur SCSI dont le driver est certifié Red Hat.
• SELinux (rires dans la salle).

Red Hat a toujours eu un modèle économique surprenant car d'un côté ils vendaient leur distribution commerciale (Red Hat Enterprise Linux - ou RHEL) et de l'autre ils sponsorisaient un clone gratuit (CentOS) identique au bug près (1:1 bug). Et pendant très longtemps, cela a permis à beaucoup de gens - particuliers et entreprises - de profiter de l'écosystème Red Hat - sans devoir payer un centime.

Phase 1 : sabordage de CentOS

Suite au rachat surprise de Red Hat par IBM en 2019, cette politique est en train de changer, et le message est clair : ils en ont marre des gens qui ne paient pas, il va falloir passer à la caisse. Ainsi l'ouverture des hostilités a commencé avec un changement de politique de CentOS :

• CentOS 8, qui devait suivre le cycle de RHEL 8, ne sera finalement pas supportée 10 ans mais à peine un an.
• CentOS n'a plus vocation à être un clone gratuit de RHEL mais sera un équivalent à "Windows Insider". Vous ne l'utiliserez plus pour profiter de la stabilité de Red Hat, mais pour tester les nouveautés en amont.

Ces changements ont sabordé l'intérêt même de CentOS et il n'a pas fallu longtemps avant de voir fleurir de nouveaux projets alternatifs avec pour objectif de fournir à nouveau un clone de RHEL gratuit : AlmaLinux, Rocky Linux, ou encore Oracle Linux qui existait déjà depuis presque 10 ans, mais en vrai personne n'aime Oracle et personne ne leur fait confiance :)

Phase 2 : blocage de l'accès aux sources

Là encore Red Hat ne voyait pas d'un bon œil la prolifération de clones gratuits de RHEL, ils décidèrent donc de réserver l'accès aux sources à leurs clients. Désormais, les seules sources publiques seront celles de CentOS, qui rappelons-le n'est plus la même chose que Red Hat. Or, les clones ont besoin des sources de RHEL, ce qui pose évidemment un problème.

Ce qui selon moi enfonce le clou, c'est ce communiqué de Red Hat de la part Mike McGrath, "Vice President of Core Platforms Engineering at Red Hat" (pas de traduction pour ne pas dire de bêtise). Le passage croustillant est :

Voilà, les termes sont lâchés, ceux qui se plaignent seraient les gens qui ne paient pas. On est donc pas très loin d'une rhétorique anti open source, un retour 20 ans en arrière quand Linux était vu comme un truc d'illuminés et que l'informatique des gens sérieux c'était vendre des logiciels propriétaires en boite.

Alors oui, c'est leur droit, d'autant que le débat sur la manière de gagner de l'argent avec du logiciel gratuit est sans fin. Mais à partir du moment où Red Hat prend en otage du code source pour obliger les utilisateurs à passer à la caisse, c'est une pratique du monde propriétaire.

Red Hat est dans la légalité, dans son bon droit, mais les utilisateurs doivent comprendre que les choses n'iront pas en s'arrangeant, bien au contraire.

Conclusion

Dans mon article Le drame CentOS 8 je disais qu'il était urgent d'attendre que la situation se clarifie et qu'il ne fallait plus installer de CentOS 8. Aujourd'hui, la situation me paraît suffisamment claire : payez vos licences Red Hat ou partez chez Debian.

Il est illusoire de penser qu'il suffit de passer sous Alma ou Rocky pour résoudre le problème car l'avenir de ces distributions communautaires parait aujourd'hui incertain, d'autant que nous ne sommes pas à l'abri d'une nouvelle surprise de la part de Red Hat.

Faites des choix courageux, ne laissez pas pourrir vos infrastructures juste parce que vous n'avez pas le budget ou le temps pour vous en occuper. Ne prenez pas du CentOS juste pour avoir l'air d'un pro et affirmer fièrement à vos clients que vous travaillez avec du Red Hat. Ne croyez pas que faire les mises à jour dans 10 ans sera moins chiant que de les faire dans 5 ans, bien au contraire.

Si vous voulez rester dans la Red Hat family (CentOS, Rocky, Alma) faites-le pour de bonnes raisons. Ne restez pas volontairement prisonnier d'un écosystème qui ne veut plus de vous.

Liens

• https://linuxfr.org/news/l-affaire-des-sources-memo-des-clones-de-red-hat-entreprise-linux-rhel
• https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes

J'aime bien OpenBSD. Malgré sa réputation de vieux système Unix implacable sur la sécurité, il est d'une simplicité déconcertante, cohérent, et bien documenté. Un inconvénient tout de même était la difficulté d'installer les mises à jour (il fallait télécharger et décompresser soi-même les sets, ou booter sur un CDROM) mais ce point a enfin été résolu avec syspatch et sysupgrade. Mettre à jour OpenBSD est désormais aussi simple que n'importe quelle distribution Linux !

Sachez qu'il est possible d'installer OpenBSD chez hetzner, car l'hébergeur fournit un accès kvm (même sur les serveurs virtuels à bas prix) et permet de piocher dans une bibliothèque d'ISOs bootables. NixOS, Arch, FreeBSD, ... et OpenBSD. Un gros +1 pour Hetzner qui laisse cette liberté aux utilisateurs (et en plus ils ont un provider Terraform, si ça c'est pas qualitatif...).

J'ai donc installé un petit serveur OpenBSD afin d'héberger 1 ou 2 sites statiques pour un side project. Le but était surtout de m'amuser et utiliser httpd, le serveur web builtin de ce système d'exploitation.

Commençons par parler des points positifs. OpenBSD et httpd sont très simples à configurer, la lecture des manpage est presque suffisante en soit, alors que pour Linux je commence toujours par regarder des exemples, avant d'attaquer la documentation. Un client acme est également intégré dans le système, il n'y a rien besoin d'installer pour se générer des certificats Let's Encrypt. Et... c'est à peu près tout. Je pourrais dire que httpd est léger et sécurisé, mais quand il s'agit de servir des contenus statiques, c'est à peu près toujours le cas.

Passons maintenant aux points négatifs. Tout d'abord, il y a cette blague (pas drôle) des messages d'erreur en Comic Sans MS (et oui) dont on peut heureusement se débarrasser, au prix d'une petite bidouille. Mais ça ce n'est pas grand chose, car le plus gros problème avec httpd selon moi, c'est qu'il ne fait vraiment pas grand chose, à part servir des pages web. Par exemple il n'est pas possible de spécifier de Header set Cache-Control "max-age=604800, public", qui permet d'indiquer aux navigateurs qu'ils doivent mettre en cache les ressources statiques. Et ça se ressent fortement sur le temps de chargement de vos pages.

En fait, httpd a besoin d'être complété par relayd, un reverse-proxy beaucoup plus complet. Le problème est que sa configuration est un poil plus complexe, et que ça m'ennuie un peu d'avoir un reverse-proxy sur la même machine tout ça pour ajouter un simple header dans les réponses. Au final, je suis resté sur du 100% httpd, sans le cache, et mes sites ont du se contenter de performances honorables mais pas optimales.

Aujourd'hui l'expérience est terminée, et j'ai re migré mes sites statiques vers NixOS + Apache.

I have been playing with OpenBSD and httpd lately. It's a really simple and fun webserver to use, despite suffering huge limitations, but I quickly stumble across this horror:

No joke. httpd will serve all errors messages with the infamous Comic sans ms font. It's probably a troll from the maintainers, at least I hope so. Comic sans ms sucks, I don't want that on my server. Fortunately, there is a simple way to disable it.

Add this line into your /etc/httpd.conf:

Then create the file /var/www/errdocs/err.html with the following content:

                                                                                                           
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>$RESPONSE_CODE $HTTP_ERROR</title>
<style type="text/css"><!--
body { background-color: white; color: black; }
hr { border: 0; border-bottom: 1px dashed; }
@media (prefers-color-scheme: dark) {
body { background-color: #1E1F21; color: #EEEFF1; }
a { color: #BAD7FF; }
}
--></style>
</head>
<body>
<h1>$RESPONSE_CODE $HTTP_ERROR</h1>
<hr>
<address>$SERVER_SOFTWARE</address>
</body>
</html>

Then restart httpd:

Explanation: httpd manage says:

A custom error document may contain the following macros that will be expanded at runtime:

$HTTP_ERROR
    The error message text.
$RESPONSE_CODE
    The 3-digit HTTP response code sent to the client.
$SERVER_SOFTWARE
    The server software name of httpd(8).

So I just took the source code of a 404 error page, removed the Comic sans ms part in the CSS and replaced the values (error code, message, server identity) by the proper variables. Now all errors messages should be generated with this new template, with a fallback font.

If you need to install Zabbix-Agent2 on Ubuntu 16.04, you will find out that there is no available packages in Zabbix repository (unlinke Zabbix-Agent). You can try to use packages for other Linux systems, even RPMs, but you will always end up with library or ABI issues. The only way to make it work is compilation.

Install requirements:

apt install -y libpcre++-dev build-essential zlib1g-dev libssl-dev

Get Zabbix source code:

wget https://cdn.zabbix.com/zabbix/sources/stable/6.2/zabbix-6.2.4.tar.gz
tar xf zabbix-6.2.4.tar.gz

You need at least Go 1.17 (for Zabbix 6.2.4):

wget https://go.dev/dl/go1.19.3.linux-amd64.tar.gz
tar xf go1.19.3.linux-amd64.tar.gz
export PATH=$PATH:/root/go/bin

You should now be able to build Zabbix-Agent 2. I took these options from Zabbix documentation and made some ajustements from what I found in packages in Zabbix repository:

cd zabbix-6.2.4
./configure \
--enable-agent2 \
--enable-static \
--prefix=/usr \
--sysconfdir=/etc/zabbix \
--libdir=/usr/lib/zabbix \
--with-curl \
--with-openssl

Note: According Zabbix documentation, the --enable-static flag is useful if you want to create your own package and use it on other systems.

You can now build and install:

make install

You can now remove Go if you don't need it. A few steps are required to make Zabbix-Agent 2 work:

addgroup --system --quiet zabbix
adduser --quiet --system \
--disabled-login \
--ingroup zabbix \
--home /var/lib/zabbix \
--no-create-home zabbix
mkdir -p /etc/zabbix/zabbix_agent2.d/plugins.d
mkdir /run/zabbix/
chown -R zabbix:zabbix /run/zabbix
mkdir /var/log/zabbix
chown -R zabbix:zabbix /var/log/zabbix

Create /etc/logrotate.d/zabbix_agent2:

/var/log/zabbix/zabbix_agent2.log {
    weekly
    rotate 12
    compress
    delaycompress
    missingok
    notifempty
    create 0640 zabbix zabbix
}

In the packages from Zabbix repository we have /usr/lib/tmpfiles.d/zabbix-agent2.conf:

d /run/zabbix 0755 zabbix zabbix - -

Don't forget to create a /etc/zabbix/zabbix_agent2.conf file. Here is a sample.

Finally, create a systemd unit file in /lib/systemd/system/zabbix-agent2.service:

[Unit]
Description=Zabbix Agent 2
After=syslog.target
After=network.target

[Service]
Environment="CONFFILE=/etc/zabbix/zabbix_agent2.conf"
EnvironmentFile=-/etc/default/zabbix-agent2
Type=simple
Restart=on-failure
PIDFile=/run/zabbix/zabbix_agent2.pid
KillMode=control-group
ExecStart=/usr/sbin/zabbix_agent2 -c $CONFFILE
ExecStop=/bin/sh -c '[ -n "$1" ] && kill -s TERM "$1"' -- "$MAINPID"
RestartSec=10s
User=zabbix
Group=zabbix

[Install]
WantedBy=multi-user.target

Reload, enable and start this new service:

systemctl daemon-reload
sytemctl enable --now zabbix-agent2

Check that everything works:

systemctl status zabbix-agent2
tail /var/log/zabbix/zabbix_agent2.log

Profit!

Il y a un an et demi, j'annonçais avoir migré mon blog sur Kubernetes (K3s). Bien que je sois globalement satisfait du résultat et que cela m'a permis de beaucoup apprendre, je rencontre tout de même des désagréments :

• Kubernetes, c'est lourd. Comptez 1 GB de RAM à vide. Pour être à l'aise, j'ai du prendre un VPS avec 4GB de RAM, là où 2 suffiraient largement sans Kubernetes.
• Absence de support d'IPv6. En 2022 c'est franchement difficile à justifier.
• La gestion des Ingress est complexe. J'utilise Traefik mais c'est compliqué, il m'a fallu quasiment 2 jours pour faire fonctionner les certificats ACME, et les montées de version ne se passent pas toujours très bien.
• Comme prévu, les mises jour à demandent un peu plus d'efforts car les composants ne sont pas gérés par la distribution. Il faut donc:
  • Mettre K3s à jour régulièrement.
  • Reconstruire et livrer les images même si l'application n'a pas changé, juste pour être sûr de ne pas trimbaler de failles de sécurité dans les librairies.
  • Mettre à jour Traefik régulièrement.

Bref, même si je trouve que Kubernetes est une super solution qui a mis en valeur les containers et l'écosystème Linux, c'est clairement overkill pour moi et je souhaite me simplifier la vie. Et si au passage je peux me former à de nouvelles technos, c'est un plus.

La solution de facilité aurait été d'installer Debian et de coder quelques roles Ansible mais l'inconvénient est que je n'apprendrais rien de nouveau. Je suis donc parti sur NixOS. C'est une distribution où la configuration s'effectue de manière déclarative via le langage Nix, avec gestion des états et possibilité de rollback.

En effet lorsque vous gérez votre distribution Linux avec Ansible, Puppet ou Salt, vous pouvez déployer une configuration et des applications, en revanche le retour en arrière n'est pas géré. Par exemple si vous avez déployé Apache et que vous voulez changer pour Nginx, c'est à vous de coder la manière dont Ansible va désinstaller Apache, sinon il sera toujours présent. Avec NixOS, si vous retirez toute référence à httpd dans votre configuration, il ne sera plus du tout présent à la prochaine génération du système. C'est un fonctionnement atomic et stateful.

Pour l'installation, j'ai utilisé nixos-infect, un script à lancer sur la plupart des distributions Linux afin de les remplacer par NixOS. Associé à un cloud-init, il permet de faire le déploiement via Terraform de manière complètement automatique, ce qui est vraiment cool il faut le dire. Et pour les gens qui préfèrent une installation à la main, sachez que Hetzner proposer une ISO NixOS et un accès console distante même pour les VPS, c'est donc totalement possible :)

Pour la partie hébergement web, voici mon fichier de configuration /etc/nixos/web.nix :

{ config, lib, pkgs,  ...}:

let
  defaultVirtualHost = {
    documentRoot = "/var/www/html/blank";
    addSSL = true;
    forceSSL = false;
    sslServerKey = "/var/www/ssl/snakeoil.key";
    sslServerCert = "/var/www/ssl/snakeoil.pem";
    locations."/" = {
      index = "index.html";
    };
  };
  makeVirtualHost = webroot:
    { documentRoot = "${webroot}";
      forceSSL = true;
      enableACME = true;
      locations."/" = {
        index = "index.php";
      };
      extraConfig = ''
        <Directory "${webroot}">
          AllowOverride All
        </Directory>
      '';
    };
in {
  security = {
    acme = {
      email = "hostmaster@example.org";
      acceptTerms = true;
    };
  };
  services = {
    httpd = {
      enable = true;
      mpm = "prefork";
      adminAddr = "hostmaster@example.org";
      enablePHP = true;
      phpPackage = pkgs.php80;
      phpOptions = "display_errors = off";
      extraConfig = ''
        SetOutputFilter DEFLATE
        ServerSignature Off
        ServerTokens prod
        <FilesMatch ".(ico|pdf|jpg|jpeg|JPEG|png|gif|js|css)$">
          Header set Cache-Control "max-age=3600, public"
        </FilesMatch>
      '';
      extraModules = [
        "deflate"
      ];
      virtualHosts =
        {"_default_" = defaultVirtualHost;
         "utux.fr"   = (makeVirtualHost "/var/www/html/utux.fr");
        };
    };
  };
}

Explications : j'ai d'autres vhosts non mentionnés ici, et à chaque fois leur configuration est identique. Pour éviter d'avoir à répéter du code, j'utilise let (permet de définir des variables et des fonctions) ainsi que in (pour les appliquer). Je ne connais pas de moyen plus propre de faire des loop pour le moment, car c'est le but. Étant donné que j'utilise PluXml, il ne faut pas oublier le AllowOverride All qui permet aux .htaccess de fonctionner, sinon les fichiers XML qui contiennent les data deviennent accessible, ce qui fait fuiter pas mal d'infos sensibles.

Pour le moment, ça marche plutôt bien. Le serveur consomme 119 Mo de RAM, soit quasiment 10x moins que Kubernetes :) Et en prime le support de l'IPv6 est revenu.

En conclusion, je suis content de pouvoir enfin tester NixOS en production. Bien que je ne sois pas encore familier avec le langage Nix, et que je le trouve bien trop compliqué par rapport à un bon vieux Ansible, j'estime que c'est l'avenir de Linux sur serveur. Les distributions devront être atomiques, et leur configuration centralisée, versionnée et reproductible. J'espère que ceci est le début d'une aventure positive.