Le Blog Utux

HTTP 200 GET /

Red Hat rime avec cul de sac

Rédigé par uTux 10 commentaires

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 :

I feel that much of the anger from our recent decision around the downstream sources comes from either those who do not want to pay for the time, effort and resources going into RHEL or those who want to repackage it for their own profit. This demand for RHEL code is disingenuous.

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

On va tous mourir

Rédigé par uTux Aucun commentaire

Oh mon dieu, IMB achète Red Hat, ça sort vraiment de nulle part mais j'imagine que tout le monde est maintenant au courant.

Même si j'essaie de rationaliser la chose en me disant que cela ne devrait pas changer grand chose, du moins pas avant quelques années, j'ai tout de même envie de me mettre en PLS et de pleurer sous mon bureau. Red Hat c'est un symbole, c'est une boite qui a un rayonnement énorme sur Linux, tant en terme de contributions que de choix politiques. C'est aussi une des distributions les plus présentes en entreprise. Ça et tout l'écosystème qui va avec: KVM, libvirt, ovirt, Ansible, GlusterFS, Ceph, Openshift, Fedora, CentOS... et au final cette entreprise se fait racheter comme un vulgaire opérateur de téléphonie.

J'ai toujours eu du mal à comprendre pourquoi une entreprise qui fonctionne bien accepte de se faire racheter par un plus gros, ça me dépasse complètement et c'est quelque chose de très négatif à mes yeux, comme s'il n'y avait que l'argent qui comptait (on parle quand même de 34 milliard de dollars).

Je me dis maintenant que j'ai bien fait de m'orienter sur Debian, tant pour mes serveurs que mes stations de travail. Et j'espère qu'IBM ne se comportera pas comme Oracle en sabrant tout ce qui fait que Red Hat est une entreprise cool.

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

Fil RSS des articles de ce mot clé