Après 10 ans d’exploitation du blog sur Ubuntu 16.04, migration vers FreeBSD

 (crocidb.com)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Le VPS DigitalOcean basé sur Ubuntu 16.04 LTS était en fin de support et posait un risque de sécurité, mais il a conservé 1491 jours d’uptime jusqu’à sa mise hors service
  • Le nouveau serveur a été déplacé vers un VPS Hetzner en Allemagne avec FreeBSD 14.3, offrant de meilleures spécifications que l’ancien serveur à 13 $/mois pour moins de 6 euros par mois
  • Des environnements isolés par site ont été créés avec Jails et Bastille, et un jail Caddy gère le SSL et le reverse proxy avant de transmettre à chaque jail nginx
  • Lors des tests de charge, le nouveau serveur FreeBSD a affiché un débit de traitement des requêtes de 3 à 11 fois supérieur après ajustement de kern.ipc.somaxconn pour supporter 10 000 connexions simultanées
  • La migration a nécessité d’apprendre la mise en réseau et la configuration de FreeBSD, mais la centralisation des réglages et la qualité de la documentation ont rendu l’ensemble plus simple à mettre en place que prévu

Contexte de la migration

  • Le blog existant tournait depuis plus de 10 ans sur un VPS DigitalOcean, avec Ubuntu 16.04 LTS dans le datacenter de New York
    • Ubuntu 16.04 LTS n’était plus supporté depuis au moins 5 ans et ne recevait plus de mises à jour des dépôts de paquets apt
    • Un système ancien est désavantageux sur le plan de la sécurité, et un ancien blog WordPress séparé avait déjà subi sur un vieux VPS une attaque injectant des liens vers des sites de casino et de paris
  • En plus du blog, l’ancien serveur hébergeait quelques autres sites, mais il s’agissait pour la plupart de sites statiques
    • Même le blog le plus populaire se limitait en général à quelques milliers de pages vues par mois, sauf lorsque certains articles devenaient viraux sur Hacker News
    • Le serveur servait les fichiers statiques via nginx/1.10.3, avec des configurations par site dans /etc/nginx/sites-available
    • Le blog était généré avec Hugo, et l’ancien processus de déploiement était : rédaction en local → commit et push du dépôt → connexion SSH au serveur → pull du dépôt → exécution de hugo
  • L’ancien VPS avait aussi servi au départ pour des tests et de la programmation, ce qui y avait laissé beaucoup de logiciels obsolètes
    • Malgré cela, il fonctionnait correctement, avec un uptime de 1491 jours au moment de l’arrêt, soit environ 4 ans sans redémarrage
  • Le nouveau serveur a été déplacé vers un VPS Hetzner en Allemagne, avec de meilleures caractéristiques pour moins de la moitié du coût mensuel précédent
    • L’ancien serveur DigitalOcean proposait 2 Go de RAM, 1 vCPU, 50 Go de disque, 2 To de trafic mensuel, pour 13 $/mois
    • Même l’offre Hetzner la moins chère doublait la mémoire et le CPU, avec un peu moins de stockage mais 10 fois plus de trafic
    • La configuration Hetzner finalement retenue offrait de meilleures performances pour moins de 6 euros par mois

Pourquoi choisir FreeBSD

  • FreeBSD a été choisi pour expérimenter un nouveau système en conditions réelles de production
    • Ses points forts incluent une conception intégrée, la stabilité, la sécurité et les Jails
  • Les Jails sont une fonctionnalité de virtualisation/conteneurisation intégrée à FreeBSD depuis plus de 25 ans
    • Ils permettent d’exécuter des « mini-systèmes » en sandbox, sans accès au système hôte
    • Alors que des solutions de conteneurs comme Docker conviennent davantage au packaging d’applications et ont un caractère éphémère et immuable, les Jails se rapprochent plutôt de sous-systèmes ou de mini-VM partageant le même noyau
  • ZFS était aussi un choix attrayant comme système de fichiers serveur
    • Il offre l’intégrité des données et des fonctions de snapshot, avec certaines similarités avec Btrfs côté Linux
    • ZFS était jugé bien plus mature que Btrfs, et des snapshots fréquents permettent de moins dépendre des solutions payantes de snapshot ou de sauvegarde du fournisseur VPS
  • L’architecture visée consistait à avoir un Jail par site, chacun contenant nginx et les outils de build nécessaires
    • Un jail principal pour le serveur web devait jouer le rôle de reverse proxy connecté à l’extérieur
    • L’idée était qu’en cas de compromission d’un jail donné, il soit possible de le supprimer et de le recréer

Installation de FreeBSD et mise en place de Bastille

  • L’écran de création de VM chez Hetzner proposait peu d’images système de base, et BSD n’y apparaissait pas directement
  • Bastille a été retenu pour simplifier la gestion des Jails
    • Les nombreuses étapes nécessaires à la création manuelle d’un jail peuvent être gérées via la commande bastille
    • Exemples de commandes : bastille list, bastille create, bastille console
    • L’installation et l’activation ont suivi la documentation de démarrage de Bastille
pkg install bastille
sysrc bastille_enable="YES"

Réseau et architecture du reverse proxy

  • Toute la stack repose sur un unique jail Caddy qui gère tous les domaines et certificats SSL, puis reverse-proxy le trafic vers un jail par site
    • Chaque jail de site ne contient que les outils nécessaires pour construire et servir le site
    • On peut voir cette architecture comme plusieurs machines virtuelles sur un même réseau
  • L’interface réseau virtuelle interne a été créée sous le nom bastille0
sudo sysrc cloned_interfaces+="lo1"
sudo sysrc ifconfig_lo1_name="bastille0"
sudo service netif cloneup
sudo sysrc ifconfig_bastille0="inet 10.0.0.1 netmask 255.255.255.0"
  • Une interface loopback clonée a été renommée bastille0 et affectée au réseau 10.0.0.1/24
  • Les jails fonctionnent sur cette interface réseau
  • Les requêtes HTTP/HTTPS externes sont redirigées vers le jail Caddy à l’aide de règles PF (Packet Filter)
    • Le fichier /etc/pf.conf configurait l’interface externe vtnet0, l’interface interne bastille0 et tailscale1
    • Le trafic sur les ports 80 et 443 est redirigé vers 10.0.0.5, futur serveur Caddy
ext_if = "vtnet0"
int_if = "bastille0"
vpn_if = "tailscale1"
set skip on $int_if
set skip on $vpn_if
nat on $ext_if from 10.0.0.0/24 to any -> ($ext_if)
rdr pass on $ext_if proto tcp from any to any port {80, 443} -> 10.0.0.5
block all
pass out quick on $ext_if keep state
  • PF et la passerelle ont été activés avec les commandes suivantes
sysrc pf_enable="YES"
service pf start
sysrc gateway_enable="YES"

Configuration de Caddy et des jails par site

  • L’ancien serveur utilisait nginx depuis longtemps, mais la nouvelle configuration adopte Caddy pour automatiser la gestion des certificats SSL
    • Dans l’environnement nginx précédent, les certificats devaient être renouvelés périodiquement avec certbot, et plusieurs renouvellements avaient été oubliés
  • Avant de créer le jail Caddy, la release FreeBSD a été bootstrapée dans Bastille
bastille bootstrap 14.3-RELEASE
  • Le jail Caddy a été créé avec l’adresse IP 10.0.0.5
bastille create caddy 14.3-RELEASE 10.0.0.5 bastille0
bastille start caddy
  • Le nom du jail est caddy, la release 14.3-RELEASE, et l’interface bastille0
  • bastille list permet de vérifier l’état d’exécution, et bastille console caddy d’ouvrir un shell dans le jail
  • L’installation de Caddy et l’activation du service ont été effectuées dans le jail
pkg install caddy
sysrc caddy_enable="YES"
service caddy start
  • Le fichier de configuration de Caddy se trouve dans /usr/local/etc/caddy/Caddyfile à l’intérieur du jail
    • Pour gérer le fichier depuis l’hôte, il est possible de monter un répertoire de l’hôte dans le jail
    • Dans l’exemple, le montage utilise nullfs avec l’option lecture seule ro afin d’empêcher Caddy de modifier sa configuration
bastille mount caddy /usr/local/etc/my-caddy-config /usr/local/etc/caddy nullfs ro 0 0

Déploiement des sites et du blog

  • Le premier site déployé a été es.cro.to, avec un dépôt géré via un dépôt GitHub
    • Le dépôt a été placé sur l’hôte dans /usr/local/www/escroto, puis monté en lecture seule dans le jail du site
    • Tous les sites sont organisés sous /usr/local/www sur l’hôte
  • Le jail escroto a été créé à partir du template nginx de Bastille
bastille bootstrap https://github.com/bastillebsd/templates
bastille create escroto 14.3-RELEASE 10.0.0.11 bastille0
bastille template escroto www/nginx
  • L’adresse IP attribuée est 10.0.0.11
  • La page par défaut de nginx est servie depuis /usr/local/www/nginx, conformément aux usages FreeBSD
  • Le répertoire du site sur l’hôte est monté en lecture seule dans le jail
bastille mount escroto /usr/local/www/escroto /usr/local/www/escroto nullfs ro 0 0
  • Un script de déploiement est utilisé pour éviter d’exposer le répertoire .git du dépôt sur le web
rm -fr /usr/local/www/nginx/*
cp -R /usr/local/www/escroto/* /usr/local/www/nginx/
rm -fr /usr/local/www/nginx/.git
  • Le déploiement d’une nouvelle version consiste à mettre à jour le dépôt sur l’hôte, puis à exécuter le script de déploiement dans le jail
cd /usr/local/www/escroto
git pull
bastille cmd escroto /root/deploy.sh
  • La configuration Caddy redirige cro.to de manière permanente vers es.cro.to, puis reverse-proxy es.cro.to vers 10.0.0.11
cro.to {
    redir https://es.cro.to{uri} permanent
}
es.cro.to {
    reverse_proxy 10.0.0.11
}
  • Le blog utilise Hugo et est géré via un dépôt GitHub
    • Le dépôt a été cloné sur l’hôte dans /usr/local/www/blog
    • Le jail blog a été créé de façon similaire à escroto, avec l’IP 10.0.0.12
bastille create blog 14.3-RELEASE 10.0.0.12 bastille0
bastille template blog www/nginx
bastille mount blog /usr/local/www/blog /usr/local/www/blog nullfs ro 0 0
  • Hugo a été installé à l’intérieur du jail blog
bastille pkg blog update
bastille pkg blog install gohugo
  • Le script de déploiement du blog vide la racine web nginx et génère la sortie Hugo dans /usr/local/www/nginx
rm -fr /usr/local/www/nginx/*
cd /usr/local/www/blog
hugo -d /usr/local/www/nginx
  • Avant de basculer le DNS, les tests ont été faits en reliant crocidb.cro.to au nouveau serveur de blog au lieu du domaine existant
crocidb.cro.to {
    reverse_proxy 10.0.0.12
}

Benchmarks et tests de charge

  • Avant de modifier les enregistrements DNS, une comparaison a été faite entre la capacité de charge de l’ancien serveur crocidb.com et du nouveau crocidb.cro.to
    • Les visiteurs du blog viennent principalement d’Amérique du Nord, puis d’Europe et d’Amérique du Sud, de sorte que le nouveau serveur allemand peut introduire un peu plus de latence pour certains utilisateurs
    • L’intérêt principal portait sur la vitesse de service d’un site statique et sur la résistance à une forte charge
  • Des outils en ligne gratuits comme GTMetrix, Pingdom et WebPageTest ont aussi été utilisés, mais les différences observées entre les deux serveurs relevaient surtout de la latence
  • Pour les benchmarks HTTP, les outils wrk et hey ont été utilisés
    • Ces deux outils génèrent un grand nombre de requêtes simultanées et collectent la latence, les réponses en erreur, le débit, etc.
  • Lors de l’exécution de wrk depuis un autre VPS Hetzner, le nouveau serveur a nettement pris l’avantage
wrk -t4 -c100 -d30s --latency https://crocidb.com/
  • Les options correspondaient à 4 threads, 100 connexions simultanées et 30 secondes d’exécution
  • L’ancien serveur affichait une latence moyenne de 89.63ms, 833.41 requêtes/s et un débit de 8.29MB/s
  • Le nouveau serveur affichait une latence moyenne de 6.75ms, 12260.10 requêtes/s et 130.80MB/s
  • La machine de test se trouvant dans le même datacenter que le nouveau serveur, la comparaison n’était pas parfaitement équitable
  • Une autre tentative a consisté à lancer wrk depuis plusieurs régions via Proton VPN, mais les résultats ont été plus faibles qu’espéré
    • L’ancien serveur tournait autour de 300 requêtes/s en moyenne, contre environ 800 pour le nouveau
    • L’approche a finalement été abandonnée au profit de vrais VPS répartis dans plusieurs régions, plutôt qu’un VPN grand public

Tests régionaux à partir de VPS Vultr

  • Vultr a été choisi afin d’utiliser une infrastructure différente de celles de DigitalOcean et Hetzner
    • Les régions ont été limitées à Londres, São Paulo, Silicon Valley et Tokyo pour réduire la charge de travail manuelle
    • Dans chaque région, la VM Fedora la moins chère a été créée pour exécuter les tests
  • L’outil final retenu a été hey, jugé plus adapté
./hey_linux_amd64 -n 1000000 -c 10000 -t 10 -z 5m -h2 https://crocidb.com/ > crocidb.com.log
./hey_linux_amd64 -n 1000000 -c 10000 -t 10 -z 5m -h2 https://crocidb.cro.to/ > crocidb.cro.to.log
  • La configuration était de 1,000,000 requêtes au total, 10,000 requêtes simultanées, un timeout de 10 secondes, une durée totale de 5 minutes et HTTP/2 activé
  • La charge générée était largement supérieure à celle d’un trafic de blog réaliste
  • Lors de la première exécution, le nouveau serveur FreeBSD n’a pas supporté 10 000 connexions simultanées et a échoué dès le début
    • Une vérification de la taille des files de sockets avec netstat -Lan a montré des valeurs à 128
    • La valeur par défaut de kern.ipc.somaxconn étant 128, elle a été augmentée ainsi
sysctl kern.ipc.somaxconn=16384
  • Dans le test depuis São Paulo, les deux serveurs ont renvoyé beaucoup d’erreurs, mais le serveur FreeBSD a traité les 1,000,000 requêtes attendues alors que le serveur Ubuntu n’a même pas renvoyé 20,000 requêtes
    • L’ancien serveur Ubuntu n’a complété qu’environ 7% des requêtes totales
    • Le nouveau serveur FreeBSD en a complété environ 94%
    • À Tokyo, le taux de réussite du nouveau serveur était un peu plus faible, mais pas au point d’être jugé inquiétant
  • En nombre de requêtes par seconde, le nouveau serveur faisait entre 3 et 11 fois mieux que l’ancien
    • Sur les percentiles de latence, la montée du nouveau serveur restait plus linéaire jusqu’à environ 90%, donc plus prévisible
    • Même sous forte charge, les résultats montraient que le contenu de la page d’accueil du blog pouvait être reçu en moins de 3,5 secondes depuis la plupart des régions du monde
  • Les résultats de Tokyo n’ont pas été analysés en profondeur
    • L’analyse par phase de requête fournie par hey suggérait que le trafic vers le Japon pouvait être plus lent
    • Les valeurs de DNS dial-up/lookup du second domaine semblaient anormalement basses, avec une possible influence du CNAME
    • Les valeurs resp wait et resp read étaient aussi anormalement élevées ; comme seules les requêtes réussies étaient comptabilisées, il est possible que l’ancien serveur ait répondu rapidement au début puis ait pratiquement bloqué les nouvelles requêtes ensuite

Bascule finale et enseignements clés

  • Même si les benchmarks n’ont pas répondu à toutes les questions, les résultats ont été jugés satisfaisants et les enregistrements DNS ont été basculés vers le nouveau serveur
    • Le blog fonctionne désormais officiellement sur le serveur Hetzner sous FreeBSD
  • Mettre en place une machine d’hébergement de sites sous FreeBSD a nécessité plusieurs heures d’essais, de corrections, de builds et d’échecs, mais s’est révélé moins complexe que prévu
    • Il aurait aussi été possible d’utiliser un service d’hébergement répondant aux besoins, par exemple OpenBSD Amsterdam
    • Une autre option aurait été Proxmox pour disposer de conteneurs et d’un tableau de bord de gestion
    • Côté alternatives FreeBSD, Sylve est également mentionné
    • Le choix d’une installation maison s’est avéré satisfaisant car très formateur
  • L’ancien serveur Ubuntu restait lui aussi très robuste
    • Il a bien encaissé la charge du site pendant 10 ans, dont les 4 dernières années sans redémarrage
    • Il fonctionnait de manière stable sans nécessiter d’effort de configuration important
  • La configuration de FreeBSD s’est révélée plus simple que prévu, notamment grâce à son approche centralisée des réglages système et à la qualité de la documentation en ligne
  • Pour construire soi-même une machine d’hébergement de blog, il a fallu acquérir des connaissances réseau dépassant le cadre habituel d’un développeur de jeux
    • L’apprentissage d’un autre système a été plaisant, et OpenBSD ou NetBSD pourraient être essayés la prochaine fois
    • La conclusion note aussi que, puisque l’essentiel du trafic du blog provient du crawling de systèmes d’IA, l’utilité pratique de tout ce travail reste limitée

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Commentaires sur Hacker News

  • Ma plus grosse erreur, ça a été une trop longue disponibilité
    arjie.com tournait depuis plus de 10 ans sur un VPS Hetzner, donc quand Hetzner a voulu retirer la machine sous-jacente, je n’avais absolument aucune idée de ce que mon moi adolescent avait configuré
    J’ai des sauvegardes, mais le site est hors ligne depuis 10 ans
    Maintenant, je fais en sorte que tout puisse être déplacé, et je le déplace réellement quelques fois pour vérifier que ça fonctionne

    • La phrase « ma plus grosse erreur, ça a été une trop longue disponibilité » est juste
      Je me souviens de l’époque où l’uptime d’une machine était vu comme une médaille d’honneur
      Je n’ai pas particulièrement gagné en sagesse avec l’âge, mais aujourd’hui je regarde plutôt la disponibilité du service
      Avant déjà, des enregistrements DNS comme les MX allaient dans ce sens, et les vieux clusters étaient assez ésotériques, mais on en a retenu des leçons comme le split brain, ce qui m’amène encore aujourd’hui à expliquer pourquoi les clusters Proxmox à 2 nœuds tombent en panne et pourquoi on recommande un witness supplémentaire
      VMware avait aussi eu tort de masquer autrefois les problèmes des clusters HA à 2 nœuds avec un énorme bricolage, et si cette méthode existe encore, elle est probablement toujours mauvaise
      Une longue disponibilité veut dire qu’on n’a pas appliqué les correctifs, et appliquer des correctifs, c’est l’activité préférée de tout le monde
    • Ça me fait penser au sanctuaire d’Ise au Japon
      Il est entièrement démonté puis reconstruit tous les 20 ans, et dans Breakneck de Dan Wang, que j’ai lu récemment, il explique que cette pratique de reconstruction préserve un savoir qui, sinon, se perd avec le temps
      Wang oppose le sanctuaire d’Ise à Notre-Dame, et pense qu’une partie de la difficulté à reconstruire le toit de Notre-Dame peut venir de cette perte de connaissance
      Je ne connais pas assez bien les deux édifices pour dire si la comparaison est vraiment équitable, mais j’aime bien le principe
      Ce n’est qu’une petite métaphore dans le livre, mais je le recommande chaudement dans son ensemble
    • Sur une VM, une longue disponibilité a assez peu de sens
      Un redémarrage prend quelques secondes, et les mises à niveau peuvent se faire sans interruption en basculant simplement le DNS vers une nouvelle instance
      C’est différent pour une machine physique qu’on ne peut pas dupliquer facilement
    • J’ai commencé à mettre ma configuration dans un gros dépôt de playbooks Ansible
      Pas besoin que tout soit entièrement géré par Ansible, j’y mets surtout la configuration initiale, et je continue encore à faire beaucoup de choses à la main
    • Il m’arrive aussi de laisser des Architectural Decision Records même pour des projets perso
      Ça paraît un peu ridicule, mais c’est utile plus souvent qu’on ne l’imagine

  • Pour l’usage perso / hobby, je fais tourner la plupart des choses avec Caddy en frontal + Docker Compose
    Pour un site simple, Caddy sert directement le contenu, et pour une « web app », je conteneurise presque tout, puis Caddy gère la terminaison TLS et le reverse proxy vers l’application dans Docker
    En général, j’utilise une structure ~/apps/appname, avec dans chaque répertoire d’app le fichier Docker Compose et le répertoire de données monté
    Après un compose down, je peux récupérer les données en (s)ftp pour les archiver à long terme ou déplacer le site / service
    J’ai longtemps fait tourner plusieurs VM sur un serveur dédié, mais je suis passé à des VPS séparés chez OVH, et pour faire tourner du mail chez OVH, il faut éviter les VM de zone locale qui n’autorisent pas l’hébergement mail
    Ça peut varier selon l’environnement

    • J’ai commencé à utiliser Traefik sur un projet, et c’était une belle amélioration par rapport à nginx proxy manager
      NPM est excellent aussi et son interface web est correcte, mais avec Traefik, il suffit de décrire dans le fichier Docker Compose le comportement voulu
    • Ma configuration à la maison est similaire
      Sauf que c’est Unraid qui fait tourner les conteneurs, dont un outil de la famille nginx conçu pour servir de reverse proxy aux autres services
    • Je fais pratiquement pareil
      J’hésite simplement à passer de Debian à quelque chose de plus orienté conteneurs et immuable côté système/OS, comme Flatcar
      FreeBSD a des avantages techniques intéressants, mais qu’on aime ou pas, la valeur par défaut de beaucoup de logiciels open source, c’est Docker, et je n’ai ni le temps ni l’envie de tout migrer vers des jails FreeBSD

  • J’ai fait exactement la même chose il y a quelques semaines
    Le serveur n’avait plus été mis à jour depuis vers 2015, et il y avait un blog Ghost de l’époque avec node 0.10 installé
    J’ai procédé d’une manière un peu plus brutale : j’ai juste fait une sauvegarde, puis j’ai lâché un agent Hermes (Gemini 3.1 Pro) dessus
    Il a appliqué toutes les mises à niveau et tous les correctifs nécessaires, puis a même migré vers des équivalents actuels
    Ensuite, il a aussi pas mal renforcé le serveur et supprimé des services inutilisés, et sans assistance IA, j’aurais probablement continué à repousser ça

    • Même sans IA, la mise à jour en elle-même est très facile à faire
      Le vrai problème, c’est le risque que quelque chose casse, et c’est précisément ce qu’une sauvegarde permet d’atténuer

  • J’ai pris du plaisir à utiliser FreeBSD sur un serveur perso
    Il y avait quelque chose de cool, propre, simple, presque « punk rock »
    Mais j’ai fini par abandonner à cause de plusieurs gros points de douleur : PM2 avait des bugs sur FreeBSD et c’était l’outil que j’utilisais pour gérer les processus ; j’ai essayé de faire tourner les démons via rc.d à la place, mais la configuration des logs était trop compliquée ; pour le pare-feu, il y avait trop de choses à régler à la main si on voulait aussi coller aux bonnes pratiques de sécurité, par exemple sur la gestion d’ICMP, et il me manquait un modèle prêt à l’emploi comme les valeurs par défaut d’UFW

    • FreeBSD inclut aussi ce genre de modèles par défaut
      C’est implémenté avec IPFW plutôt qu’avec PF
      Il faut regarder la clé firewall_type dans rc.conf : https://cgit.freebsd.org/src/tree/libexec/rc/rc.conf?id=8e08...
      Pour configurer simplement un pare-feu de machine unique, on peut utiliser firewall_type=client, ou firewall_type=workstation si on héberge quelque chose
      Dans ce dernier cas, firewall_myservices et firewall_allowservices permettent de contrôler quels ports ouvrir et quels réseaux/IP peuvent y accéder
      Pour une passerelle NAT très simple, il suffit de firewall_type=simple avec firewall_simple_(iif|inet|oif|onet)(_ipv6)? pour définir les noms d’interface côté FAI / côté interne, ainsi que les plages réseau IPv4/IPv6
      L’implémentation exacte de chaque option se trouve dans /etc/rc.firewall : https://cgit.freebsd.org/src/tree/libexec/rc/rc.firewall?id=...
    • Je me demande si tu utilisais PM2 pour la supervision
      Pour les logs des démons rc.d, à l’unix, on peut simplement utiliser logger(1) pour les messages simples, ou rediriger vers un fichier puis laisser newsyslog(8) gérer la rotation / la taille
      Pour le pare-feu, je recommande The Book of PF[0]
      Le PF de FreeBSD a des différences de syntaxe avec le pf d’OpenBSD, mais c’est largement suffisant pour comprendre comment fonctionne un pare-feu et quels types de règles il faut écrire
      [0]: https://nostarch.com/book-of-pf-4e
    • PM2 a toujours eu des bugs, quel que soit l’OS
      Au début c’est super pratique, mais en même temps c’était un logiciel pénible à utiliser, et les mises à jour de variables d’environnement lors du déploiement n’ont jamais fonctionné comme prévu une seule fois
    • Mon principal problème, c’était que ça ne tenait pas après une coupure de courant
      Quand l’alimentation sautait, au redémarrage il fallait lancer un fsck manuel sur le système de fichiers

  • C’est un peu un autre sujet, mais je me demande quelle distribution Linux gratuite a aujourd’hui le cycle de support le plus long
    Pendant un moment, j’ai utilisé CentOS 7 pour de petites VM, parce qu’il recevait des mises à jour de sécurité pendant très longtemps et qu’il y avait peu de risque qu’une mise à jour casse quelque chose
    Après avoir regardé un peu, j’ai l’impression qu’Alma/Rocky Linux est aujourd’hui le meilleur choix, avec 10 ans de support
    Je me demande simplement si c’est bien maintenu

    • J’ai moi aussi fait tourner CentOS sur des serveurs pendant plus de 10 ans dans l’espoir d’avoir de la stabilité à long terme et la tranquillité d’esprit
      Mais sur des périodes aussi longues, l’écosystème dérive beaucoup, et maintenir des applications modernes sur cet OS devient de plus en plus difficile
      Des paquets d’infrastructure comme glibc, les combinaisons Python/Apache, GCC, etc. finissent peu à peu par ne plus coller aux stacks applicatives actuelles
      Et les montées de version sont devenues douloureuses ensuite, pas seulement parce que je m’étais moi-même coincé avec un mélange de paquets bizarre, mais aussi parce que le chemin d’upgrade lui-même n’a jamais été plus qu’une best effort
      Je crois que j’ai abandonné en passant de 6 à 7, puis j’ai fini par comprendre qu’en réalité, ce qu’il me fallait, c’était Fedora
      Avec des mises à jour annuelles ou semestrielles, plus besoin de se battre avec les paquets de la distribution, la configuration reste à jour et fonctionnelle, les upgrades majeures de distro sont fluides, et l’interruption de service reste minimale
      Je ne pense plus jamais revenir à une « distribution serveur »
    • Alma n’est plus strictement compatible avec les sources RHEL, ce qui lui donne un peu de latitude
      Par exemple, ils peuvent publier plus vite une mise à jour du noyau corrigeant une faille d’élévation de privilèges
      Rocky, de son côté, a répondu avec un dépôt de sécurité optionnel qui apporte des mitigations d’exploit en attendant que ça descende de RHEL
      À en juger par les événements récents, les deux semblent plutôt bien maintenus
    • Je ne vois pas bien pourquoi ne pas utiliser une distribution rolling release sur un serveur perso
      Tous les services tournent dans des conteneurs, et on laisse simplement l’OS de base se mettre à jour automatiquement aussi souvent que nécessaire
      J’ai choisi openSUSE MicroOS, et avec des mises à jour et redémarrages presque quotidiens, je suis assez confiant dans l’état de santé du serveur
      Les mises à jour atomiques permettent aussi, si quelque chose casse et qu’on n’a pas envie de s’en occuper tout de suite, d’appuyer sur le bouton de rollback dans Cockpit et de regarder ça plus tard quand on a du temps
    • C’est en quelque sorte parier que ce que tu héberges ne survivra pas plus longtemps que le cycle d’upgrade
      Et quand l’upgrade finit par arriver, elle risque d’être assez douloureuse
      Je pense qu’il vaut mieux faire plus souvent de petits sauts de version qu’un gros bond après des années quand tout a déjà changé
    • Si tu veux du totalement gratuit, ou si tu as beaucoup de machines, Alma et Rocky sont les bons choix
      Si l’enregistrement chez Red Hat ne te dérange pas, il y a aussi RHEL, qui donne gratuitement accès aux mises à jour pour jusqu’à 10 machines par compte enregistré
      RHEL est clairement la plus stable des grandes distributions, et Alma comme Rocky sont essentiellement des clones downstream de RHEL

  • Je suis dans le même bateau
    J’ai deux vieux serveurs laissés à l’abandon « trop » longtemps, et maintenant j’ai peur d’y toucher pour les mettre à jour
    En même temps, vu tout le cirque que les distributions Linux font autour de la vérification / preuve d’âge, je me demande si je ne vais pas carrément partir
    J’ai aussi essayé Artix, mais ça a cassé après un redémarrage la semaine dernière, probablement parce qu’une précédente mise à jour du noyau avait mal tourné, au point de devoir ressortir une ISO de secours
    J’ai donc remplacé cette machine par Devuan, mais je réserve encore mon jugement
    Je n’ai pas de gros reproches pour l’instant, mais c’est encore la phase de rodage
    Sur mon portable, j’utilise Arch, mais la communauté me semble assez hostile à cause des questions de censure, donc j’attends d’avoir un week-end libre pour tout effacer et installer autre chose
    Je ne veux pas de drame politique dans mes logiciels
    Fait intéressant, c’est la première fois que j’achète un nouveau portable et que je n’amorce jamais Windows avant d’installer directement Linux, et tout a « simplement fonctionné »
    C’est triste de voir, au moment où Linux devient vraiment enthousiasmant à utiliser, les gros acteurs accepter des étapes d’érosion de la vie privée comme l’IA partout, la preuve / vérification d’âge, ou la télémétrie activée par défaut
    Avec tout ce genre de choses, ma réaction est simplement « nope »

    • J’ai déjà laissé un serveur Ubuntu de côté pendant 10 ans avant de le mettre à jour en 20 minutes, sans douleur
      Ce serveur tourne toujours aujourd’hui sur la dernière LTS
      Je ne sais même plus s’il avait démarré en Ubuntu 4 ou 6, mais ça s’est bien passé tout du long
      Peut-être que faire des upgrades lentement permettait d’éviter la souffrance des early adopters
      Aujourd’hui, j’utilise bien plus Debian
      Avec toutes les attaques sur la chaîne d’approvisionnement, Debian Stable est vraiment un bijou, et même s’il faut parfois gérer à part quelques paquets pour avoir des versions plus récentes, j’aime cet esprit d’ingénierie sobre et un peu à l’ancienne
    • Sur la vérification / preuve d’âge, je pense que tu es mal informé
    • Si une précédente mise à jour du noyau a cassé la machine après redémarrage, c’est surtout un problème d’Arch/Artix
      Ce sont parmi les plus rapides à suivre le courant amont, et pas toujours les meilleurs sur la stabilité
      Mais ça ne veut pas dire qu’une distro rolling doit forcément fournir la toute dernière version de tout
      J’utilise Void Linux depuis quelques mois : c’est une rolling release, mais avec un noyau LTS et le noyau mainline en option, et les mainteneurs privilégient davantage des versions applicatives stables que des mises à jour rapides
    • Mes serveurs / VM tournent généralement sous FreeBSD ou Alpine
      J’ai aussi un peu de Debian là où c’est nécessaire, par exemple pour Proxmox, des VPS qui ne prennent pas en charge Alpine, ou du matériel lié au travail
      J’ai aussi quelques systèmes de test sous Chimera, mais je ne compte pas trop en dépendre avant la sortie d’une version stable
      J’expérimente aussi un peu AerynOS
    • J’aimerais que FreeBSD ait un cycle de support plus long
      La durée de support d’une release est inférieure à un an, donc si on rate la fenêtre d’upgrade, la suite devient plus compliquée que sur d’autres distributions comme Debian Stable

  • Je suis passé à Debian et Ubuntu pour les serveurs, mais dans ma jeunesse, au milieu des années 2000, j’étais à fond dans FreeBSD
    Je passais en réalité plus de temps à configurer et bidouiller qu’à faire des choses vraiment utiles
    À l’époque, il était difficile de trouver des serveurs dédiés ou VPS proposant des BSD, et j’avais l’impression de finir chez des gens comme Panix.com
    Avant ça, je me souviens aussi d’une société appelée 15MinuteServers, dans le New Jersey il me semble, qui proposait du BSD
    Bon, là je suis juste en train de radoter par nostalgie

    • Aujourd’hui, chez mes fournisseurs, l’installation est assez simple
      J’utilise FreeBSD chez Hetzner et OVH, et j’ai aussi essayé Vultr avant
    • OVH a un template FreeBSD
      Et la plupart des fournisseurs de VM/VPS KVM permettent l’accès console et le montage d’ISO utilisateur, donc on peut installer ce qu’on veut

  • Si fastfetch indique plus de mémoire utilisée qu’en réalité, c’est probablement à cause du ZFS ARC
    Comme le page cache sous Linux, cette mémoire peut être récupérée à tout moment, et les outils la nomment différemment : https://www.linuxatemyram.com/

  • Je me souviens que quand quelqu’un m’a expliqué Docker pour la première fois, j’ai répondu : « ah, tu veux dire jail ? »
    Comme l’explique l’article, ce n’est pas exactement la même chose
    kqueue a aussi été une grande victoire
    Un immense merci aux développeurs de FreeBSD
    J’ai fait tourner ma première entreprise pendant 15 ans sur FreeBSD, et l’uptime comme la résilience étaient remarquables

  • J’ai moi aussi un serveur Ubuntu 16.04 que j’ai peur de mettre à jour
    Son uptime actuel est de 1281 jours, et à ce stade, j’ai presque mauvaise conscience à l’idée de le redémarrer

    • Tu peux copier le système de fichiers sur une autre machine avec dd, puis le démarrer dans un émulateur comme qemu pour faire une répétition générale
      Il faut juste faire attention s’il y a des services qui se lancent automatiquement et se connectent vers l’extérieur
    • Je ne vois pas ce qui fait peur
      Tu as bien des sauvegardes, non ?
      Sur Debian/Ubuntu, on peut configurer assez facilement des mises à jour automatiques régulières et des redémarrages, ce qui ne laisse la maintenance manuelle que pour les upgrades de version majeure
    • Mon plus vieux serveur est encore en 8.04