Le Blog Utux

HTTP 200 GET /

5 systèmes que j'aimerais tester

Rédigé par uTux Aucun commentaire

Ceci est une liste purement subjective de systèmes d'exploitations que j'aimerais bien tester en desktop ou en serveur "si j'avais le temps, si j'avais un use case, si j'avais un vieux notebook qui traîne dans un coin, si j'avais un petit serveur dispo pour monter un lab..."

GhostBSD

GhostBSD screenshot

J'adore FreeBSD, cela fait plus de 10 ans que je l'utilise sur 1 ou 2 serveurs dans un coin d'Internet ou de ma maison. A l'origine il me servait pour les jails - avant que Docker n'existe - sur une machine trop peu puissante pour supporter toute forme de virtualisation. J'avais même des jails en Debian GNU/kFreeBSD afin de combiner le meilleur des deux mondes.

Cependant, je n'ai jamais pu me motiver à utiliser FreeBSD en desktop car outre l'installation laborieuse de l'environnement de bureau complet, certaines features sont un peu moins pratiques que chez Linux (keymap, Wifi, hibernation...). Je dois admettre également que Docker me manque, bien que je pourrais apprendre à m'en passer en buildant mes propres jails.

GhostBSD est à FreeBSD ce que Manjaro est à Archlinux : une version prête à l'emploi pour un usage desktop. Et c'est un peu triste à dire mais depuis que DesktopBSD et PC-BSD/TrueOS sont morts, il ne reste que GhostBSD et NomadBSD pour remplir ce rôle.

GhostBSD pourrait être une bonne solution pour me permettre d'expérimenter le desktop sous FreeBSD.

Q4OS (Trinity)

Q4OS screenshot

Q4OS est une distribution Debian fournie avec l'environnement KDE Plasma ou Trinity, un fork de KDE 3.5 toujours maintenu. Alors que ce dernier n'est pas aussi populaire que MATE (qui rempli le même rôle en continuant à faire vivre l'esprit de GNOME2) Q4OS fait beaucoup d'efforts pour en proposer une version bien intégrée et agréable visuellement.

J'avoue que KDE 3.5 titille une fibre nostalgique en moi, même si je m'en souviens surtout comme d'un environnement bordélique et surchargé. Q4OS pourrait me donner l'occasion de me réconcilier avec ce DE.

Mageia

Mageia screenshot

On ne présente plus Mageia, le fork le plus fidèle à l'esprit d'origine de feu Mandriva. Je suis habituellement très critique envers cette distribution pour diverses raisons mais je dois avouer qu'elle a le mérite d'être encore là et d'être toujours indépendante. Dans un précédent article je disais même que je pourrais me réfugier dessus si jamais un jour Debian venait à disparaitre (ce qui était un pur exercice de pensée).

Utiliser sérieusement et longuement Mageia me permettrait peut-être de comprendre l'amour que portent certains utilisateurs à cette distribution qui manque gravement de moyens et qui vit dans le passé :)

OpenSuse

OpenSUSE screenshot

Lorsque l'on s'aventure sur le territoire des distributions Linux développées par une entreprise, on a généralement affaire au trio Red Hat, Ubuntu et SUSE. OpenSuse est la distribution communautaire gratuite disponible en deux cuvées : Leap (alignée sur la version de Suse Linux Enterprise Server - ou SLES) ou Tumbleweed (rolling release).

A l'instar de Drakeconf pour Mageia, OpenSuse dispose d'un outil graphique de configuration - Yast2 - dont j'ai beaucoup de mal à comprendre l'intérêt mais heureusement rien ne nous oblige à l'utiliser.

Suse ayant encore une bonne image auprès du grand public, en produisant gratuitement une distribution stable d'une grande qualité, j'aimerais bien trouver un jour un cas d'usage pour OpenSuse en desktop ou en serveur.

OpenIndiana

OpenIndiana screenshot

Après avoir écumé les distributions Linux et être passé par FreeBSD, NetBSD, OpenBSD... que reste-t-il ? Et bien la famille Solaris semble constituer une bonne piste. Le hic c'est qu'il n'existe plus vraiment de communauté pour maintenir les forks libres que sont OpenIndiana et OmniOS.

Malgré tout j'aimerais bien que ces systèmes reviennent en force afin de nous proposer un peu d'exotisme dans le monde des sysadmins.

openfortivpn + SAML (SVPNCOOKIE) on Linux

Rédigé par uTux Aucun commentaire

Bla bla bla, boring and very long introduction that no ones cares about.

Install openfortivpn from Debian's repositories:

sudo apt install openfortivpn

Open a web browser and log in to your organization's fortinet SSL-VPN portal. Right click anywhere on the page, Inspect, and go to the Network tab in order to copy the SVPNCOOKIE= cookie.

Now open a terminal and run:

sudo openfortivpn --cookie SVPNCOOKIE=....

And voila!

Sometimes the connection may fail with the following error:

ERROR:  Could not get VPN configuration (HTTP status code).

For some reason this often happens to me when I use Firefox to grab the cookie, however I have no problem with google-chrome. I haven't tested other browsers.

J'ai tout migré sous aarch64 (ou presque)

Rédigé par uTux Aucun commentaire

Le blog vient de passer sous un sku cax11 chez Hetzner:

  • 2 vCPU Arm64 Ampere® Altra®.
  • 4 GB RAM.
  • 40 GB SSD.
  • 20 TB trafic.
  • NixOS vanilla.

Soit à peu près le double de la version x86 pour le même prix.

Et oui, j'ai bien mentionné NixOS vanilla, ou upstream. Contrairement à l'immense majorité des "bidules" en ARM qui nécessitent un OS spécialement modifié pour pouvoir booter, on a affaire ici à une machine virtuelle QEMU avec un firmware UEFI Tiano Core, qui permet de faire tourner n'importe quelle distribution Linux compilée en aarch64 ! L'installation a été réalisée avec nixos-infect. Voici le résultat d'un uname -a:

Linux prd-web-1 6.1.57 #1-NixOS SMP Tue Oct 10 20:00:46 UTC 2023 aarch64 GNU/Linux

Si j'en ai le courage, je m'attaquerai à la migration de mon serveur Yunohost actuellement en x86. Cela promet d'être laborieux puisque cela nécessite de copier tous mes e-mail, mais cela en vaut la peine.

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 ;)

Fil RSS des articles de ce mot clé