Le Blog Utux

HTTP 200 GET /

De Kubernetes à NixOS

Rédigé par uTux 4 commentaires

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.

Le drame CentOS 8

Rédigé par uTux 2 commentaires

La nouvelle est tombée il y a quelques jours : le support de CentOS 8 se terminera fin 2021 et la distribution basculera à 100% sur le modèle Stream. C'est un changement de gouvernance brutal et destructeur pour ses utilisateurs car CentOS ne sera plus un clone de Red Hat gratuit mais plutôt son pendant "Windows Insider".

Il faut bien comprendre que CentOS c'est quelque chose de gros : c'est la 2e distribution la plus utilisée au monde sur les serveurs Web Linux en 2020 avec 18,8% de parts de marché. Moi qui travaille avec du Cloud et du Linux en entreprise, je confirme que ça représente à la louche 60% de nos serveurs (non Windows) peut-être même plus.

Qu'est-ce qui plaît autant dans cette distribution encore plus en retard que Debian et avec des dépôts tellement vides qu'il n'y a ni nginx ni htop ?

  • C'est basiquement un clone gratuit de Red Hat, donc très stable et certifiée par des tas de constructeurs de matériel et éditeurs de middlewares.
  • Support incroyablement long, une dizaine d'années.
  • Bénéficie de l'énorme documentation en ligne de Red Hat.
  • La pauvreté des dépôts est compensée par EPEL et SCL (mais aussi tout un tas d'autres).
  • La version du kernel est vieille mais les drivers et correctifs de sécurité sont backportés dedans.
  • Certains n'aiment pas les libertés prises par Debian dans le packaging de certaines applications (par exemple Apache). CentOS est un peu plus proche de l'upstream sur ce point.

En gros CentOS était une distribution incassable, prévisible, ennuyeuse, et avec un support extrêmement long. On comprend alors que l'abandon de cette stabilité au profil d'un modèle de type "testing" ou "insider" va totalement à l'encontre de ce qui faisait son intérêt. Mais alors, que peut-on faire ?

Si possible, ne plus déployer de CentOS 8 en attendant que la situation se stabilise. Cette annonce a provoqué de très nombreux retours négatifs de la communauté et il est évident que le projet se rend compte qu'il se saborde lui-même. En ce qui me concerne j'espère soit une annulation de cette décision, soit au contraire un message clair qui indique qu'IBM/Red Hat ne veut plus de CentOS dans sa forme actuelle, dans les deux cas nous serions fixés sur l'avenir.

En attendant, si vous devez déployer de nouveaux serveurs, il existe des alternatives :

  • Si vous n'avez aucune fidélité à RHEL/CentOS ou aux RPMs, Debian et Ubuntu sont des alternatives de choix. J'ai une nette préférence pour la première que j'ai toujours trouvé plus légère, plus stable, et qui n'installe pas snap par défaut.
  • CentOS 7 reste une option à ne pas négliger, car supportée jusqu'en 2024.
  • Si vous avez besoin de la compatibilité RHEL/CentOS 8, il y a Oracle Linux. Alors oui le nom fait peur car quand on parle d'Oracle on pense aux tarifs exorbitants, à OpenOffice, et aux pratiques crapuleuses, il n'empêche que la distribution est bien gratuite et qu'elle perdure depuis 2013, en plus d'être elle aussi un clone de Red Hat. Elle est fournie avec deux kernel : RHCK (compatible Red Hat / CentOS) et UEK (Unbreakable Enterprise Kernel, plus récent et ne nécessitant pas de reboot). Oracle Linux est à mon sens l'alternative la plus crédible à CentOS. Pour couronner le tout, un script de migration est disponible : lien vers un retour d'expérience.
  • Je ne recommande pas Rocky Linux, c'est beaucoup trop tôt. Des tas de distributions naissent et meurent chaque année, ou se retrouvent parfois dans un état intermédiaire façon Mageia, donc attendons de voir si Rocky aura les moyens de ses ambitions. Elle n'est de toutes manières pas encore disponible.

Il est urgent d'attendre, laissez passer les fêtes pour voir comment la situation évolue. Voilà mon avis sur le feuilleton CentOS ;)

Linux sur desktop: Linus se trompe

Rédigé par uTux 13 commentaires

Article écrit en réaction aux propos de Linus Torvalds, qui affirme que Si Linux a de la peine à s'imposer sur le desktop c'est à cause de la fragmentation de l'écosystème. Forcément c'est un titre alléchant, le papa de Linux qui ressasse un troll vieux de plus de 10 ans, y'a matière à attirer les clics et les commentaires.

En tant qu'utilisateur de Linux depuis 12 ans, ancien prosélyte, ancien techos helpdesk, je pense fortement que ce n'est pas vrai et que le monsieur se trompe. Même s'il est un dictateur reconnu et probablement un bon développeur, je pense que le problème n'est pas technique.

Mauvais raisonnement

Excusez l'analogie un peu sexiste, mais on ne fait pas un enfant en 3 mois avec 3 femmes. Affirmer que mettre tous les gens sur une distribution unique et un environnement graphique unique permettrait d'atteindre une qualité supérieure reste à prouver tant il y a de facteurs en jeu.

De plus il ne faut pas oublier que la grande majorité des distributions Linux et des logiciels libres sont gratuits et faits par des gens qui s'éclatent, des contributeurs réguliers ou occasionnels, bref des gens à qui on ne peut pas donner d'ordres. Il n'y aurait aucune légitimité à rediriger ces gens là vers un projet unique, la plupart cesseraient juste de contribuer et nous devrions être content de les avoir actuellement même s'ils sont "répartis" sur différents projets.

D'autre part ce raisonnement part du principe que cet éparpillement provoque un déficit de moyens au niveau des distributions, alors que des organisations telles que Red Hat, Fedora, Suse, Debian, Ubuntu, ont déjà énormément de contributeurs et même des moyens financiers.

Et pour finir faisons une analogie avec les voitures: si demain on décide qu'il est inutile d'avoir plusieurs constructeurs automobile puisqu'au final les voitures se ressemblent toutes, est-ce que cela augmentera la qualité des véhicules ? Non, cela donnera juste un énorme monopole à quelqu'un.

Linux ou le fantasme d'un Windows gratuit

On aura beau avoir la distribution la plus peaufinée, la plus performante, la moins buguée, il y aura toujours des reproches sur l'impossibilité de trouver les mêmes logiciels que Windows, faire les mêmes manipulations, avoir la même compatibilité. En gros nous avons un espèce de fantasme d'un Linux qui serait un Windows gratuit amélioré, bien sûr cela n'est pas possible.

Par contre, plutôt que d'avoir Linux avec un environnement Windows, il est possible de faire l'inverse. Aujourd'hui on peut installer Debian 9 sur Windows 10, sans virtualisation, sans émulation, avec accès natif aux dépôts de la distribution. Et ça marche plutôt bien. Peut-être la convergence Windows/Linux est-elle déjà là et qu'au final l'intérêt de Linux sur desktop est de moins en moins pertinent.

La vente liée

Enfin on ne peut continuer la réflexion sans évoquer l'éternelle vente liée. Il est probable que l'écrasante majorité des utilisateurs ne sait pas installer un système d'exploitation, n'a pas envie d'apprendre (à juste titre), voire ne sait même pas ce qu'est un OS. Donc à partir du moment où chaque ordinateur vendu dans le monde vient avec Windows, la compétition n'est pas juste.

Conclusion

Alors qu'il a gagné sur mobile, Linux ne s'imposera jamais sur desktop, car c'est un marché bloqué, car il est trop tard pour changer les habitudes des gens, et parce qu'il est plus pragmatique de parier sur la convergence des environnement avec WSL qui permet d'avoir Linux sur Windows. Avec les efforts récents de Microsoft dans l'opensource je ne serais pas surpris de voir un rachat de Canonical prochain pour faire face à IBM.

Plutôt que de chercher à révolutionner 20 ans d'informatique grand public, s'isoler et se trouver des ennemis partout, tenter d'aller contre un courant beaucoup trop fort, le combat devrait être mené sur un autre front. On ne pourra pas déployer de Linux sur les PC grand public, en revanche on peut faire vivre son écosystème. On a des logiciels libres populaires qui marchent bien: Firefox, VLC, LibreOffice, c'est à mon sens là dessus qu'il faut investir nos efforts.

Firewalld, c'est bien

Rédigé par uTux 6 commentaires

Il y a deux ans j'affirmais aimer systemd dans l'article systemd, c'est bien. Aujourd'hui je parle de Firewalld, un service et ensemble d'outils permettant de gérer le pare-feu sous Linux.

La base du firewall sous Linux c'est iptables, et quand on a compris et beaucoup pratiqué, c'est pas si compliqué. Mais il y a toujours deux points qui me gênent:

  • Il n'y a pas de service officiel pour charger les règles au démarrage, il faut faire son propre script ou en emprunter à droite à gauche.
  • Les règles sont quand même indigestes et bas niveau, ce qui n'est pas toujours nécessaire.

Firewalld implémente un système de "zones" dans lesquelles vous allez définir des paramètres, autoriser des services: internet, public, dmz... elles peuvent être définies à partir de l'interface ou de la source, c'est assez souple. Le paramétrage se fait soit en cli (firewalld-cmd) soit graphiquement (firewall-config) ou encore au travers d'une api et introduit la notion de "permanent" pour savoir si il faut conserver les modifications au démarrage.

Bien entendu, firewalld est un service système donc il n'y a pas de script à écrire pour charger ses règles au boot, il suffit de l'activer dans sytemd.

Firewalld est présent sur Fedora, CentOS, RedHat mais peut être installé sur d'autres sytèmes comme Debian car il est proposé dans les dépôts. Et moi, je migre mes serveurs sur Firewalld avec prise en charge par Ansible, parce que je gagne un temps fou et je fais les choses proprement.

Merci Red Hat ces logiciels qui terminent en "d" et qui modernisent un peu Linux :)

Notes: NixOS / efi installation

Rédigé par uTux Aucun commentaire

Notes sur l'installation de NixOS / efi:

Après avoir booté l'iso:

passwd
systemctl start sshd
ip addr

Connexion ssh root@ip pour faire l'installation plus aisément:

gdisk /dev/vda
n 1 [entrée] +100M EF00
n 2 [entrée] +2G 8200
n 3 [entrée] [entrée] 8300
w y
mkfs.vfat -F32 /dev/vda1
mkswap /dev/vda2
swapon /dev/vda2
mkfs.xfs /dev/vda3
mount /dev/vda3 /mnt
mkdir /mnt/boot
mount /dev/vda1 /mnt/boot
nixos-generate-config --root /mnt/
[Editer mnt/etc/nixos/configuration.nix]
nixos-install
reboot

Après avoir booté la distribution:

sudo nix-channel --add https://nixos.org/channels/nixos-17.09-small nixos
sudo nixos-rebuild switch --upgrade

Utilisé en machine virtuelle Bhyve. Xfs pour le lolz.

Et bien sûr on oublie pas la documentation :)

Fil RSS des articles de ce mot clé