Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierLinux

Calculate Linux se libère de ses versions !

2 avril 2024 à 22:41
Bonjour à tous,

Depuis le 29 décembre 2022, où nous avions annoncé la sortie de Calculate Linux 23, il n'y a pas eu de version majeure.

En effet, rien ne justifiait de sortir une une nouvelle version, puisqu'il n'y avait aucune réelle nouveauté à mettre en avant. Le développement suit son court, seules les nouvelles versions des environnements de bureau, des logiciels, et des composants tels que le noyau linux évoluent en version.

Les "nightly builds", ces images générées périodiquement (tous les 2-3 jours) deviendront officiellement les versions principales, à l'instar de Gentoo ou Arch Linux. Ces nightly builds ont, en effet, déjà été déplacées dans le dossier release.

Cette approche présente plusieurs avantages. En effet, le temps que nous consacrons à la préparation et à la promotion des nouvelles versions peut être consacré à d'autres améliorations, et bien sûr, vous obtiendrez toujours les dernières et les meilleures mises à jour du système.

Aussi, maintenant, obtenir des images fraîches et à jour sera un jeu d'enfant, plus besoin d'aller chercher les images "nightlies", qui pouvaient sembler "non stables" par certains.

Tout le monde y gagne !

Si vous souhaitez donc utiliser Calculate Linux, vous pouvez vous rendre sur le site officiel : https://wiki.calculate-linux.org/download
Je vous rappelle que linuxtricks.fr est toujours un miroir officiel en France pour récupérer vos paquets !

Chronologie de l'attaque contre le logiciel libre xz

2 avril 2024 à 19:59
Bonjour à tous,

Je vous propose une traduction française d'un excellent article récapitulant la chronologie de l'attaque contre le logiciel libre xz dont vous retrouvez la source dans les sources en bas de l'article.
Je sais que certains d'entre vous ont des difficultés à comprendre l'Anglais, voici donc le tout en Français


Pendant plus de deux ans, un attaquant utilisant le nom de "Jia Tan" a travaillé comme un contributeur diligent et efficace à la bibliothèque de compression xz, se voyant finalement accorder l'accès au commit et à la maintenance. Grâce à cet accès, il a installé une porte dérobée très subtile et soigneusement cachée dans liblzma, une partie de xz qui se trouve également être une dépendance d'OpenSSH sshd sur Debian, Ubuntu, Fedora et d'autres systèmes Linux basés sur systemd. Cette porte dérobée permet à l'attaquant d'envoyer des commandes cachées au début d'une session SSH, ce qui lui donne la possibilité d'exécuter une commande arbitraire sur le système cible sans se connecter : une exécution de code à distance ciblée et non authentifiée.

L'attaque a été rendue publique le 29 mars 2024 et semble être la première attaque sérieuse connue de la chaîne d'approvisionnement contre un logiciel open source largement utilisé. Elle marque un tournant dans la sécurité de la chaîne d'approvisionnement des logiciels libres, pour le meilleur ou pour le pire.

Ce billet est une chronologie détaillée que j'ai construite sur l'aspect ingénierie sociale de l'attaque, qui semble remonter à la fin de l'année 2021. Les événements clés sont indiqués en gras.

Prologue

2005-2008 : Lasse Collin, avec l'aide d'autres personnes, conçoit le format de fichier .xz en utilisant l'algorithme de compression LZMA, qui compresse les fichiers à environ 70 % de ce que fait gzip Au fil du temps, ce format est largement utilisé pour compresser les fichiers tar, les images du noyau Linux et bien d'autres choses encore.
https://github.com/kobolabs/liblzma/blob/87b7682ce4b1c849504e2b3641cebaad62aaef87/doc/history.txt

Jia Tan entre en scène, avec des acteurs de renom

2021-10-29 : Jia Tan envoie un premier patch inoffensif à la liste de diffusion xz-devel, ajoutant le fichier ".editorconfig".
https://www.mail-archive.com/[email protected]/msg00512.html

2021-11-29 : Jia Tan envoie un second patch inoffensif à la liste de diffusion xz-devel, corrigeant un problème de compilation apparemment reproductible. D'autres correctifs qui semblent (même rétrospectivement) être corrects suivent.
https://www.mail-archive.com/[email protected]/msg00519.html

2022-04-19 : Jia Tan envoie encore un autre correctif inoffensif à la liste de diffusion xz-devel.
https://www.mail-archive.com/[email protected]/msg00553.html

2022-04-22 : "Jigar Kumar" envoie le premier d'une série de courriels se plaignant du fait que le correctif de Jia Tan n'a pas atterri. ("Les correctifs passent des années sur cette liste de diffusion. Il n'y a aucune raison de penser que quelque chose va arriver bientôt"). À ce stade, Lasse Collin a déjà intégré quatre des correctifs de Jia Tan, marqués par "Thanks to Jia Tan" dans le message de livraison.
https://www.mail-archive.com/[email protected]/msg00557.html

2022-05-19 : "Dennis Ens" envoie un mail à xz-devel pour demander si XZ pour Java est maintenu.
https://www.mail-archive.com/[email protected]/msg00562.html

2022-05-19 : Lasse Collin répond en s'excusant pour la lenteur et ajoute "Jia Tan m'a aidé en dehors de la liste avec XZ Utils et il pourrait avoir un rôle plus important à l'avenir, au moins avec XZ Utils. Il est clair que mes ressources sont trop limitées (d'où les nombreux courriels en attente de réponses), il faut donc que quelque chose change à long terme."
https://www.mail-archive.com/[email protected]/msg00563.html

2022-05-27 : Jigar Kumar envoie un email de pression au fil de discussion sur les correctifs. "Plus d'un mois et pas plus près d'être fusionné. Ce n'est pas une surprise.
https://www.mail-archive.com/[email protected]/msg00565.html

2022-06-07 : Jigar Kumar envoie un email de pression au fil de discussion Java. "Il n'y aura pas de progrès tant qu'il n'y aura pas de nouveau mainteneur. Dennis, vous feriez mieux d'attendre qu'il y ait un nouveau mainteneur ou de forker vous-même. Soumettre des patchs ici n'a plus de sens de nos jours. Le mainteneur actuel s'est désintéressé ou n'a plus envie de maintenir. C'est triste à voir pour un repo comme celui-ci."
https://www.mail-archive.com/[email protected]/msg00566.html

2022-06-08 : Lasse Collin se défend. "Je n'ai pas perdu l'intérêt, mais ma capacité à m'occuper du projet a été assez limitée, principalement à cause de problèmes de santé mentale à long terme, mais aussi à cause d'autres choses. Récemment, j'ai travaillé hors liste avec Jia Tan sur XZ Utils et peut-être qu'il aura un rôle plus important à l'avenir, nous verrons. Il est également bon de garder à l'esprit qu'il s'agit d'un projet de loisir non rémunéré."
https://www.mail-archive.com/[email protected]/msg00567.html

2022-06-10 : Lasse Collin fusionne le premier commit avec Jia Tan comme auteur dans les métadonnées git ("Tests : Created tests for hardware functions").
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=aa75c5563a760aea3aa23d997d519e702e82726b

2022-06-14 : Jugar Kumar envoie un email de pression. "Avec votre rythme actuel, je doute fort de voir la version 5.4.0 sortir cette année. Le seul progrès depuis avril a été de petits changements dans le code de test. Vous ignorez les nombreux patchs qui pourrissent sur cette liste de diffusion. En ce moment vous étouffez votre repo. Pourquoi attendre la version 5.4.0 pour changer de mainteneur ? Pourquoi retarder ce dont votre repo a besoin ?"
https://www.mail-archive.com/[email protected]/msg00568.html

2022-06-21 : Dennis Ens envoie un courriel de pression. "Je suis désolé pour vos problèmes de santé mentale, mais il est important d'être conscient de ses propres limites. Je comprends que c'est un projet de loisir pour tous les contributeurs, mais la communauté veut plus. Pourquoi ne pas renoncer à la maintenance de XZ for C pour pouvoir accorder plus d'attention à XZ pour Java ? Ou transmettre XZ pour Java à quelqu'un d'autre pour qu'il se concentre sur XZ pour C ? Essayer de maintenir les deux signifie que ni l'un ni l'autre ne sont bien maintenus".
https://www.mail-archive.com/[email protected]/msg00569.html

2022-06-22 : Jigar Kumar envoie un courriel de pression au fil de discussion sur le correctif C. "Est-ce qu'il y a des progrès sur ce sujet ? Jia, je vois que tu as des commits récents. Pourquoi ne peux-tu pas faire ce commit toi-même ?"
https://www.mail-archive.com/[email protected]/msg00570.html

2022-06-29 : Lasse Collin répond : "Comme je l'ai laissé entendre dans des emails précédents, Jia Tan pourrait avoir un rôle plus important dans le projet à l'avenir. Il a beaucoup aidé en dehors de la liste et est déjà pratiquement un co-mainteneur. :-) Je sais qu'il ne s'est pas encore passé grand chose dans le dépôt git, mais les choses se font à petits pas. Dans tous les cas, un changement de mainteneur est déjà en cours, au moins pour XZ Utils".

Jia Tan devient mainteneur

À ce stade, Lasse semble avoir commencé à travailler encore plus étroitement avec Jia Tan. Evan Boehs observe que Jigar Kumar et Dennis Ens avaient tous deux des adresses électroniques nameNNN@mailhost qui n'apparaissaient jamais ailleurs sur Internet, ni dans xz-devel. Il est probable qu'il s'agissait de faux créés pour pousser Lasse à donner plus de contrôle à Jia. Cela a fonctionné. Au cours des mois suivants, Jia a commencé à répondre aux fils de discussion sur xz-devel en faisant autorité sur la version 5.4.0 à venir.

2022-09-27 : Jia Tan donne un résumé de la version 5.4.0. ("La version 5.4.0 qui contiendra le décodeur multi thread est prévue pour décembre. La liste des problèmes ouverts liés à la 5..4.0 [sic] en général que je suis sont...")
https://www.mail-archive.com/[email protected]/msg00593.html

2022-11-30 : Lasse Collin change l'email de rapport de bogue de son adresse personnelle à un alias qui va à lui et Jia Tan, note dans le README que "les mainteneurs du projet Lasse Collin et Jia Tan peuvent être contactés via [email protected]".
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=764955e2d4f2a5e8d6d6fec63af694f799e050e7

2022-12-30 : Jia Tan fusionne son premier commit directement dans le repo xz ("CMake : Update .gitignore for CMake artifacts from in source build"). À ce stade, nous savons qu'ils ont accès au commit.
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=8ace358d65059152d9a1f43f4770170d29d35754

2023-01-11 : Lasse Collin marque et construit sa version finale, v5.4.1.
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=18b845e69752c975dfeda418ec00eda22605c2ee

2023-03-18 : Jia Tan marque et construit sa première version, v5.4.2.
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=6ca8046ecbc7a1c81ee08f544bfd1414819fb2e8

2023-03-20 : Jia Tan met à jour la configuration de Google oss-fuzz pour leur envoyer des bogues.
https://github.com/google/oss-fuzz/commit/6403e93344476972e908ce17e8244f5c2b957dfd

2023-06-22 : Hans Jansen envoie une paire de correctifs, fusionnés par Lasse Collin, qui utilisent la fonction "GNU indirect function" pour sélectionner une fonction CRC rapide au démarrage. Le dernier commit est retravaillé par Lasse Collin et fusionné par Jia Tan. Ce changement est important car il fournit une possibilité par laquelle le code obfusqué peut modifier les tables de fonctions globales avant qu'elles ne soient remappées en lecture seule. Alors que ce changement pourrait être une innocente optimisation de performance en soi, Hans Jansen revient en 2024 pour promouvoir le code backdoor xz et sinon il n'existe pas sur internet.
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=23b5c36fb71904bfbe16bb20f976da38dadf6c3b
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=b72d21202402a603db6d512fb9271cfa83249639
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=ee44863ae88e377a5df10db007ba9bfadde3d314

2023-07-07 : Jia Tan désactive le support de ifunc pendant les constructions de oss-fuzz, prétendant que ifunc est incompatible avec l'assainisseur d'adresses. Cela peut être inoffensif en soi, mais c'est aussi un travail de fond pour utiliser ifunc plus tard.
https://github.com/google/oss-fuzz/commit/d2e42b2e489eac6fe6268e381b7db151f4c892c5

2024-01-19 : Jia Tan déplace le site web vers les pages GitHub, leur donnant le contrôle de la page web XZ Utils. Lasse Collin a probablement créé les enregistrements DNS pour le sous-domaine xz.tukaani.org qui pointe vers les pages GitHub. Après la découverte de l'attaque, Lasse Collin a supprimé cet enregistrement DNS pour revenir à tukaani.org, qu'il contrôle.
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=c26812c5b2c8a2a47f43214afe6b0b840c73e4f5

Début de l'attaque

2024-02-23 : Jia Tan fusionne le code binaire d'une porte dérobée bien caché dans certains fichiers d'entrée de tests binaires. Le README disait déjà (bien avant que Jia Tan n'apparaisse) "Ce répertoire contient un tas de fichiers pour tester la gestion des fichiers .xz, .lzma (LZMA_Alone), et .lz (lzip) dans les implémentations de décodeurs. La plupart des fichiers ont été créés à la main avec un éditeur hexadécimal, il n'y a donc pas de meilleur "code source" que les fichiers eux-mêmes". Disposer de ce type de fichiers de test est très courant pour ce genre de bibliothèque. Jia Tan en a profité pour ajouter quelques fichiers qui ne seraient pas examinés attentivement.
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0

2024-02-24 : Jia Tan marque et construit la v5.6.0 et publie une distribution xz-5.6.0.tar.gz avec un build-to-host.m4 supplémentaire et malveillant qui ajoute la porte dérobée lors de la construction d'un paquet deb/rpm. Ce fichier m4 n'est pas présent dans le dépôt des sources, mais de nombreux autres fichiers légitimes sont également ajoutés lors de la construction du paquet, il n'est donc pas suspect en soi. Mais le script a été modifié par rapport à la copie habituelle pour ajouter la porte dérobée.
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=2d7d862e3ffa8cec4fd3fdffcd84e984a17aa429

2024-02-24 : Gentoo commence à voir des crashs dans la version 5.6.0. Cela semble être un bug d'ifunc, plutôt qu'un bug dans la porte dérobée cachée, puisque c'est le premier xz avec les changements d'ifunc de Hans Jansen.
https://bugs.gentoo.org/925415

2024-02-26 : Debian ajoute xz-utils 5.6.0-0.1 à unstable.
https://tracker.debian.org/news/1506761/accepted-xz-utils-560-01-source-into-unstable/

2024-02-28 : Debian ajoute xz-utils 5.6.0-0.2 à unstable.
https://tracker.debian.org/news/1507917/accepted-xz-utils-560-02-source-into-unstable/

2024-02-29 : Sur GitHub, @teknoraver envoie une pull request pour arrêter de lier liblzma à libsystemd. Il semble que cela aurait fait échouer l'attaque. Kevin Beaumont spécule que le fait de savoir que cela était sur le point de se produire a pu accélérer le calendrier de l'attaquant. Il n'est pas clair s'il existe des discussions antérieures qui les auraient mis la puce à l'oreille.
https://github.com/systemd/systemd/pull/31550
https://doublepulsar.com/inside-the-failed-attempt-to-backdoor-ssh-globally-that-got-caught-by-chance-bbfe628fafdd

2024-02-28 : Jia Tan casse la détection de landlock dans le script configure en ajoutant une typo subtile dans le programme C utilisé pour vérifier le support des landlocks. Le script configure essaye de construire et d'exécuter le programme C pour vérifier le support des blocs, mais comme le programme C a une erreur de syntaxe, il ne sera jamais construit et exécuté, et le script décidera toujours qu'il n'y a pas de support des blocs. Lasse Collin est listé comme le committer ; il peut avoir manqué la subtile coquille, ou l'auteur peut être falsifié. Probablement le premier, puisque Jia Tan n'a pas pris la peine de forger un committer sur ses nombreux autres changements. Ce patch semble préparer quelque chose d'autre que la modification de sshd, puisque le support de landlock fait partie de la commande xz et non de liblzma. Ce qui n'est pas clair exactement.
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=a100f9111c8cc7f5b5f0e4a5e8af3de7161c7975
https://docs.kernel.org/userspace-api/landlock.html

2024-03-04 : Les distributions RedHat commencent à voir des erreurs Valgrind dans _get_cpuid de liblzma (l'entrée de la porte dérobée). La course est lancée pour corriger cela avant que les distributions Linux ne creusent trop profondément.
https://bugzilla.redhat.com/show_bug.cgi?id=2267598

2024-03-05 : Le pull request libsystemd est fusionné pour supprimer liblzma. Une autre course est lancée, pour obtenir la porte dérobée de liblzma avant que les distributions ne cassent complètement l'approche.
https://github.com/systemd/systemd/commit/3fc72d54132151c131301fc7954e0b44cdd3c860

2024-03-05 : Debian ajoute xz-utils 5.6.0-0.2 à testing.
https://tracker.debian.org/news/1509743/xz-utils-560-02-migrated-to-testing/

2024-03-05 : Jia Tan apporte deux corrections de bogues pour ifunc. Ceux-ci semblent être de vrais correctifs pour le bogue ifunc actuel. Un commit fait un lien vers le bogue de Gentoo et corrige également un bogue de GCC en amont.
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=4e1c97052b5f14f4d6dda99d12cbbd01e66e3712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115

2024-03-08 : Jia Tan livre un prétendu correctif Valgrind. C'est une fausse piste, mais elle est efficace.
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=82ecc538193b380a21622aea02b0ba078e7ade92

2024-03-09 : Jia Tan met à jour les fichiers de la porte dérobée. Il s'agit de la correction Valgrind actuelle, qui modifie les deux fichiers de test contenant le code d'attaque. "Les fichiers originaux ont été générés de manière aléatoire sur ma machine. Pour mieux reproduire ces fichiers à l'avenir, une graine constante a été utilisée pour recréer ces fichiers."
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=74b138d2a6529f2c07729d7c77b1725a8e8b16f1

2024-03-09 : Jia Tan marque et construit la version 5.6.1 et publie la distribution xz 5.6.1, qui contient une nouvelle porte dérobée.
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=fd1b975b7851e081ed6e5cf63df946cd5cbdbb94

2024-03-20 : Lasse Collin envoie à LKML un ensemble de correctifs remplaçant son email personnel avec lui-même et Jia Tan comme mainteneurs du code de compression xz dans le noyau. Il n'y a aucune indication que Lasse Collin ait agi de manière malveillante ici, il a juste nettoyé les références à lui-même en tant que seul mainteneur. Bien sûr, Jia Tan a pu en être l'instigateur, et la possibilité d'envoyer des correctifs xz au noyau Linux aurait été un bon point d'appui pour les travaux futurs de Jia Tan. Nous n'avons pas encore atteint le niveau de confiance, mais ce serait un pas de plus.
https://lkml.org/lkml/2024/3/20/1009
https://lkml.org/lkml/2024/3/20/1008

2024-03-25 : Hans Jansen est de retour (!), déposant un bogue Debian pour obtenir la mise à jour de xz-utils vers la version 5.6.1. Comme dans la campagne de pression 2022, plus d'adresses name###@mailhost qui n'existent pas sur internet se manifestent pour plaider en faveur de cette mise à jour.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708

2024-03-28 : Jia Tan dépose un bogue Ubuntu pour obtenir la mise à jour de xz-utils vers la version 5.6.1 de Debian.
https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2059417

Attaque détectée

2024-03-28 : Andres Freund découvre le bogue, notifie en privé Debian et distros@openwall. RedHat assigne le CVE-2024-3094.

2024-03-28 : Debian revient sur la version 5.4.5, introduisant la version 5.6.1+really5.4.5-1.
https://tracker.debian.org/news/1515519/accepted-xz-utils-561really545-1-source-into-unstable/

2024-03-29 : Andres Freund poste un avertissement de porte dérobée sur la liste publique oss-security@openwall, disant qu'il l'a trouvé "au cours des dernières semaines".
https://www.openwall.com/lists/oss-security/2024/03/29/4

2024-03-29 : RedHat annonce que la porte dérobée xz a été livrée dans Fedora Rawhide et Fedora Linux 40 beta.
https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users

2024-03-30 : Debian arrête les constructions pour reconstruire leurs machines de construction en utilisant Debian stable (au cas où le malware xz aurait échappé à leur bac à sable ?).
https://fulda.social/@Ganneff/112184975950858403


Ce qui suit est un ajout de ma part :
Et depuis les distributions Linux concernées ont communiqué et ont corrigé les paquets :

Fedora / Red Hat :
=> Suivi chez RH https://bugzilla.redhat.com/show_bug.cgi?id=2272210
=> Fedora Rawhide (Dev concernée), depuis le paquet a été retiré : Downgrade à faire : https://bodhi.fedoraproject.org/updates/FEDORA-2024-d02c7bb266
=> Fedora 38 + 39 non concernées (stables) et beta de 40 succintement (dans updates-testing quelques heures) https://packages.fedoraproject.org/pkgs/xz/xz/

OpenSuse :
=> Non concerné sur Leap et SLES : https://www.suse.com/c/suse-addresses-supply-chain-attack-against-xz-compression-library/
=> Seule TW est concernée https://build.opensuse.org/request/show/1163302 Downgrade a faire

Debian :
=> Stable non concerné https://packages.debian.org/bookworm/xz-utils
=> Testing + Sid concernées et downgrade fait https://lists.debian.org/debian-security-announce/2024/msg00057.html
=> Kali Linux (distrib orientée sécu basée sur ... Testing concernée) : https://www.kali.org/blog/about-the-xz-backdoor/

Ubuntu :
=> 22.04 LTS non concerné https://packages.ubuntu.com/jammy/xz-utils
=> 23.10 Non concerné https://packages.ubuntu.com/mantic/xz-utils
=> Future 24.04 non concernée => pas de comm d'ubuntu https://packages.ubuntu.com/noble/xz-utils

Gentoo :
=> Affectée aussi https://bugs.gentoo.org/show_bug.cgi?id=928134 (probablement pas OpenRC)
=> Paquets masqués : https://packages.gentoo.org/packages/app-arch/xz-utils (auparavant Testing pas stable)

Arch :
=> Concernée : https://archlinux.org/news/the-xz-package-has-been-backdoored/
=> Pas de retour a 5.4 mais suppression des fichiers .m4 https://security.archlinux.org/AVG-2851

En espérant que ce résumé vous a plu !

Gentoo : Migration vers le profile 23

2 avril 2024 à 16:52
Bonjour à tous,

Depuis le 22 mars 2024, il est possible de basculer du profile 17.1 vers 23.0 de Gentoo.
Les nouveaux profils 23.0 activent par défaut certaines fonctionnalités de durcissement de la chaîne d'outils et d'amélioration des performances, et normalisent les paramètres.
Pour plus d'infos, vous pouvez aller voir cette page : https://www.gentoo.org/support/news-items/2024-03-22-new-23-profiles.html

Les profiles 17.0, 17.1, 20.0 et 22.0 seront marqués comme obsolètes courant mai 2024 et supprimés un an plus tard.
Il est donc nécessaire de faire la transition dès maintenant.

Voici la procédure de mise à niveau du profil pas à pas.

Avant toute chose, vérifiez que vous avez bien des backups de votre système. Ceci n'est qu'un rappel, cela doit être fait régulièrement :)

Etape 1 :
- Vérifiez que le système est complètement à jour comme habituellement.
- Vérifiez que glibc soit plus récent que 2.36 ou que musl plus récent que 1.2.4 (suivant ce que vous utilisez)

Etape 2 :
- Si vous utilisez un profil obsolète depuis longtemps (le 17.0 par exemple), faites d'abord la transition vers la 17.1 avant de passer en 23.0)

Etape 3 :
- Si vous utilisez actuellement systemd dans une configuration split-usr, vous devez d'abord terminer la migration vers le profil merged-usr correspondant de la même même version de profil avant : https://www.gentoo.org/support/news-items/2022-12-01-systemd-usrmerge.html
- Si vous utilisez actuellement openrc, migrez d'abord vers la version 23.0, en conservant l'agencement. Si vous voulez passer de split-usr à merged-usr, faites-le après.

Etape 4 :
- Lancez emerge --info et notez la valeur de CHOST (par exemple CHOST="x86_64-pc-linux-gnu")

Etape 5 :
- Si la variable CHOST a été définie dans /etc/portage/make.conf retirez-la.

Etape 6 :
- Repérez le profile utilisé : eselect profile list (par exemple default/linux/amd64/17.1)
- Sélectionnez le profile 23.0 correspondant à votre profil actuel.
Les profils 17.1 étaient par défaut split-usr. Les profils 23.0 sont par défaut merged-usr.
Ne changez pas votre arborescence maintenant. Restez dans le même schéma
Plus d'infos ici : https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_table

Sur mon système, OpenRC, j'ai : default/linux/amd64/17.1
Je vais donc basculer sur : default/linux/amd64/23.0/split-usr

Etape 7 :
- Supprimez le contenu du cache des paquets binaires si vous les utilisez : rm -r /var/cache/binpkgs/*

Etape 8 :
- Si vous utilisez des paquets binaires, dans le fichier ou le dossier /etc/portage/binrepos.conf, mettez à jour l'URI du profile binaire : https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_table

Etape 9 :
- Recompilez binutils dans la même version : emerge --ask --oneshot sys-devel/binutils (2mn25 sur dual core)
- Rejouez la configuration des binutils avec binutils-config -l puis binutils-config 1
- Recompilez gcc (sans recompiler glibc !!) : emerge --ask --oneshot sys-devel/gcc --nodeps (1h40 sur dual core)
- Rejouez la configuration des gcc avec gcc-config -l puis gcc-config 1
- Recompilez glibc : emerge --ask --oneshot sys-libs/glibc (20mn sur dual core) ou musl suivant votre cas : emerge --ask --oneshot sys-libs/musl

Etape 10 :
- Relancez emerge --info pour vérifier si la variable CHOST a changé par rapport à l'étape 4
Si la valeur n'a pas changé, passez à l'étape 13 directement

Etape 11 :
- Revérifiez avec binutils-config and gcc-config si les versions sont les bonnes

Etape 12 :
- Vérifiez dans /etc/env.d, /etc/env.d/binutils, et /etc/env.d/gcc s'il n'y a pas de fichiers se référant à la variable CHOST

Etape 13 :
- Rechargez l'environnement avec env-update && source /etc/profile

Etape 14 :
- Réémergez libtool : emerge --ask --oneshot libtool (37 secondes sur dual core)

Etape 15 :
- Supprimez à nouveau par sécurité le contenu du cache des paquets binaires si vous les utilisez : rm -r /var/cache/binpkgs/*

Etape 16 :
- Recompilez TOUT votre système : emerge --ask --emptytree @world
- Cela peut prendre énormément de temps... suivant ce que vous avez installé

Evidemment, rebootez :)

Note : 17h30minutes le réémerge du @world (1411 paquets) sur le AMD Ryzen 5 2600X :)

ALERTE SECURITE : Une backdoor dans xz sous Linux (porte dérobée)

30 mars 2024 à 12:00
Bonjour à tous...

Dans cet article, je vous partage le script de ma vidéo sur l'alerte de sécurité (autour du code malicieux découvert dans les libs xz) touchant certaines distributions Linux.
J'ai publié le 29 Mars au soit plein d'informations sur un fil sur Twitter : https://twitter.com/_adriend_/status/1773782014648299702
Vous avez été nombreux à me demander une vidéo récapitulative sur le sujet.
Voici le script pour vous permettre une lecture plutôt qu'un visionnage, où j'ai recompilé et réordonné ce que j'ai tweeté.
C'est sous forme de liste à puce, mais les idées essentielles sont là.

Red Hat a communiqué ce 29 mars :
https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users
- Sont concernées les derni-res versions de xz (5.6.0 et 5.6.1)
- Contient un code malicieux qui permet de faire un accès non autorisé sur le système (backdoor)
- Vulnérabilité assignée CVE-2024-3094.
- Les vulnérabilités et expositions courantes (CVE) sont un ensemble de menaces de sécurité qui sont incluses dans un système de référence qui décrit les risques connus du public.

Qu'est ce que XZ :
Xz = compression de format (comme bzip2 ou gzip ou zstd)
Beaucoup utilisé sous Linux (tar.xz, compressiion de modules noyaux etc...)

A propos du code malveillant
- Concernés 5.6.0 et 5.6.1
- Code obfusqué, non présent dans le code source mais dans les archives mise à dispo
- Code ajouté dans les tar : https://web.archive.org/web/20240329182710/https://github.com/tukaani-project/xz/releases
- GITHUB du projet désactivé ce matin : https://github.com/tukaani-project/xz/releases
- Lors de la compilation depuis les sources le code malveillant se construit si la macro M4 est exécutée
- Lorsque autoconf est appelé (lors de la construction de paquets sous Linux deb, rpm, arch, etc...)
- Le code interfère avec l'authentification dans sshd via systemd
- Donc permet de prendre le contrôle non autorisé d'une machine ar la suite

Le lien malicious code de l'article (RedHat) donne toutes les infos techniques
https://www.openwall.com/lists/oss-security/2024/03/29/4
- Vulnérabilité découverte par Andres Freund
- S'interrogeait sur les lenteurs d'SSH et consommation élevéede CPU
- Ce n'est pas un chercheur en sécurité mais il a constaté la supercherie

Depuis les distributions Linux ont été très réactives depuis la découverte
Vulnérabilité présente depuis la version 5.6.0 de xz publiée le 24 février

Distribs impactées :
RHEL : Pas d'impact sur RHEL 9 dernière version possèdant la version 5.2.x

Fedora :
PLEASE IMMEDIATELY STOP USAGE OF ANY FEDORA RAWHIDE INSTANCES
=> Suivi chez RH https://bugzilla.redhat.com/show_bug.cgi?id=2272210
=> Fedora Rawhide (Dev concernée), depuis le paquet a été retiré : Downgrade à faire : https://bodhi.fedoraproject.org/updates/FEDORA-2024-d02c7bb266
=> Fedora 38 + 39 non concernées (stables) et beta de 40 non plus (était dans UP-TEST) https://packages.fedoraproject.org/pkgs/xz/xz/

OpenSuse :
=> Non concerné sur Leap et SLES : https://www.suse.com/c/suse-addresses-supply-chain-attack-against-xz-compression-library/
=> Seule TW est concernée https://build.opensuse.org/request/show/1163302 Downgrade a faire

Debian :
=> Stable non concerné https://packages.debian.org/bookworm/xz-utils
=> Testing + Sid concernées et downgrade fait https://lists.debian.org/debian-security-announce/2024/msg00057.html
=> Kali Linux (distrib orientée sécu basée sur ... Testing concernée) : https://www.kali.org/blog/about-the-xz-backdoor/

Ubuntu :
=> 22.04 LTS non concerné https://packages.ubuntu.com/jammy/xz-utils
=> 23.10 Non concerné https://packages.ubuntu.com/mantic/xz-utils
=> Future 24.04 non concernée => pas de comm d'ubuntu https://packages.ubuntu.com/noble/xz-utils

Gentoo :
=> Affectée aussi https://bugs.gentoo.org/show_bug.cgi?id=928134 (probablement pas OpenRC)
=> Paquets masqués : https://packages.gentoo.org/packages/app-arch/xz-utils (auparavant Testing pas stable)

Arch :
=> Concernée : https://archlinux.org/news/the-xz-package-has-been-backdoored/
=> Pas de retour a 5.4 mais suppression des fichiers .m4 https://security.archlinux.org/AVG-2851

Que penser de ça :
- Code malicieux bien planqué qui est resté 1 mois sans être découvert
- Cela peut aussi arriver dans le monde de l'Open Source
- Découverte "par hasard" par Andres Freund
- Grande réactivité des acteurs de l'OPensource pour patcher les systèmes
- Réactivité du CERT sur Twitter https://twitter.com/CERT_FR/status/1773770991346286940 (Centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques.)
- Rolling Releases touchées plus rapidement (car par définition, intégration plus rapide des nouvelles versions, et donc des bugs et des ... codes malicieux) - Idem pour les versions de développment des distribs Linux (qui ne sont pas utilisées en prod ... normalement)
- Stables Releases, et version LTS épargnées due à des versions figées de versions de logiciels da,s la distribution
- Impact finalement limité dans ce cas, mais si non détecté, ça aurait pu être plus "grave" (Exemple : Intégration d'un XZ 5.6 vérolé dans Ubuntu 24.04 LTS qui sort prochainement et qui n'est pas maintenu à jour par l'administrateur !?)

Que faire :
- Si on utilise un système concerné : le mettre à jour VOIRE LE RÉINSTALLER (On ne sait pas s'il y a des résidus ou déjà eu une prise de contrôle avec ajout d'autres "cochonneries")
- Pour les sysadmins : se renseigner sur la suite. Etre vigilent sur ses systèmes même ceux non concernés (comme toujours)
- Toujours mettre à jour ses systèmes, ses applications, et mettre à jour ses outils de sécurité (Antivirus, EDR, ...)

A propos de l'auteur du code malicieux :
- Vu sur ycombinator : https://news.ycombinator.com/item?id=39865810
- L’auteur apparent de la porte dérobée fait partie du projet xz depuis 2 ans.
- Il a fait le forcing pour intégrer dans Fedora 40 et 41 la nouvelle version soit disant "super nouvelles fonctionnélités"
- Les projets où cette personne a contribuer vont être vigilents je pense...

Pour résumer très rapidement cette backdoor xz/liblzma CVE-2024-3094 c’est : ( https://twitter.com/_adriend_/status/1773801887617151386 )
- Un code caché dans les fichiers de données de test du projet
- Injecte du code pendant le processus de construction de la compilation (et construction des DEB/RPM/PKG)
- Redirige des fonctions cryptographiques utilisées lors des connexions SSH
- Permet un accès au sysytème en contournant les politiques des accès
Détecté par Andres Freund !


Il peut y avoir des fautes de frappe, désolé, mes scripts sont toujours tapés vite, sous forme de listes à puce.
Vous avez le script brut de décoffrage :)

Migration de Clementine à Strawberry

19 janvier 2024 à 22:32
Bonsoir à tous,

Comme vous le savez sans doute, j'utilise le logiciel Clementine depuis des années.
J'ai découvert ce lecteur de musique sous Mandriva 2011, car il était livré par défaut dessus.

Simple, rapide, efficace, il m'a suivi depuis 13 ans.

Cependant, il est en Qt4 pour la version 1.3 et une version 1.4-rc2 est compilée avec Qt5 mais le développement est très ralenti depuis un bon moment.
Il souffre de bugs avec Wayland (que j'utilise depuis mon passage sous Fedora 39 - https://www.linuxtricks.fr/news/10-logiciels-libres/537-pc-fixe-je-passe-de-gentoo-a-fedora/ )
Un des bugs le plus embêtant est notamment la perte du clavier sur plusieurs applications quand Clementine est lancé. Impossible de saisir du texte dans Vivaldi, Google Chrome, Clementine lui même et d'autres.
Je pensais que Teamviewer ou Remmina étaient en cause sur ce bug, car j'utilise en effet souvent Teamviewer ou Remmina en même temps que Clementine. Je prends le contrôle depuis le PC fixe Fedora sur le PC DJ et modifie les TAGS avec Clementine en même temps.

Mais finalement, j'ai diagnostiqué que l'ouverture de Clementine entraine la perte du clavier, car ce soir, j'ai voulu écouter de ma musique avec le logiciel.

Un fork existe depuis un moment, et s'appelle Strawberry (que j'utilise sur le PC DJ Windows 10 d'ailleurs).
Vous avez compris le jeu de mot, Clémentine/Fraise... OK.

D'ailleurs, j'ai utilisé Strawberry sur le PC DJ Windows 10 car ils sont été très réactifs pour corriger un bug de transcodage OGG->MP3 ( https://github.com/strawberrymusicplayer/strawberry/issues/856 )
Chez Clementine, je n'ai pas ouvert de bug, car il en existe un depuis 2017 qui n'est toujours pas résolu ( https://github.com/clementine-player/Clementine/issues/4647 )

La solution de migrer vers le fork semblait une évidence, mais j'avais une flemme monumentale de reparamétrer Strawberry, car j'ai paramétré Clementine avec mes playlists, ma bibliothèque etc.
Les bugs trops importants avec Wayland m'ont décidé à sauter le pas.

La base de données des paramétrages est en sqlite et copier/coller les préférences du dossier Clementine à Strawberry ne fonctionnait pas.

Cependant, il existe une astuce pour copier les paramétrages, en manipulant la base de données.

En effet, cela fait plus de 13 ans que j'utilise le logiciel, il est bien garni !


Dans un premier temps, après installation, on ouvre Strawberry et on le referme pour que les fichiers par défaut soient créés.

Ensuite, on ouvre sqlite3

Code BASH :
sqlite3


On attache les 2 BDD:
Code SQL :
ATTACH '/home/adrien/.local/share/strawberry/strawberry/strawberry.db' AS strawberry;
ATTACH '/home/adrien/.config/Clementine/clementine.db' AS clementine;


On purge la BDD Strawberry :
Code SQL :
  DELETE FROM strawberry.directories;
DELETE FROM strawberry.subdirectories;
DELETE FROM strawberry.songs;
DELETE FROM strawberry.playlists;
DELETE FROM strawberry.playlist_items;


Ensuite, on importe les collections :
Code SQL :
INSERT INTO strawberry.directories (path, subdirs) SELECT path, subdirs FROM clementine.directories;
INSERT INTO strawberry.subdirectories (directory_id, path, mtime) SELECT directory, path, mtime FROM clementine.subdirectories;
INSERT INTO strawberry.songs (ROWID, title, album, artist, albumartist, track, disc, YEAR, originalyear, genre, compilation, composer, performer, GROUPING, comment, lyrics, beginning, LENGTH, bitrate, samplerate, directory_id, url, filetype, filesize, mtime, ctime, unavailable, playcount, skipcount, lastplayed, compilation_detected, compilation_on, compilation_off, compilation_effective, art_automatic, art_manual, effective_albumartist, effective_originalyear, cue_path, rating)
SELECT ROWID, title, album, artist, albumartist, track, disc, YEAR, originalyear, genre, compilation, composer, performer, GROUPING, comment, lyrics, beginning, LENGTH, bitrate, samplerate, directory, filename, filetype, filesize, mtime, ctime, unavailable, playcount, skipcount, lastplayed, sampler, forced_compilation_on, forced_compilation_off, effective_compilation, art_automatic, art_manual, effective_albumartist, effective_originalyear, cue_path, rating FROM clementine.songs WHERE unavailable = 0;
UPDATE strawberry.songs SET SOURCE = 2;
UPDATE strawberry.songs SET artist_id = '';
UPDATE strawberry.songs SET album_id = '';
UPDATE strawberry.songs SET song_id = '';


Et les playlists :
Code SQL :
INSERT INTO strawberry.playlists (ROWID, name, last_played, special_type, ui_path, is_favorite, dynamic_playlist_type, dynamic_playlist_data, dynamic_playlist_backend)
SELECT ROWID, name, last_played, special_type, ui_path, is_favorite, dynamic_playlist_type, dynamic_playlist_data, dynamic_playlist_backend FROM clementine.playlists WHERE dynamic_playlist_type ISNULL;


Les éléments des playlists :
Code SQL :
INSERT INTO strawberry.playlist_items
   (ROWID,
   playlist,
   collection_id,
   title,
   album,
   artist,
   albumartist,
   track,
   disc,
   YEAR,
   originalyear,
   genre,
   compilation,
   composer,
   performer,
   GROUPING,
   comment,
   lyrics,
   beginning,
   LENGTH,
   bitrate,
   samplerate,
   directory_id,
   url,
   filetype,
   filesize,
   mtime,
   ctime,
   unavailable,
   playcount,
   skipcount,
   lastplayed,
   compilation_detected,
   compilation_on,
   compilation_off,
   compilation_effective,
   art_automatic,
   art_manual,
   effective_albumartist,
   effective_originalyear,
   cue_path,
   rating
   )
   SELECT ROWID,
      playlist,
      library_id,
      title,
      album,
      artist,
      albumartist,
      track,
      disc,
      YEAR,
      originalyear,
      genre,
      compilation,
      composer,
      performer,
      GROUPING,
      comment,
      lyrics,
      beginning,
      LENGTH,
      bitrate,
      samplerate,
      directory,
      filename,
      filetype,
      filesize,
      mtime,
      ctime,
      unavailable,
      playcount,
      skipcount,
      lastplayed,
      sampler,
      forced_compilation_on,
      forced_compilation_off,
      effective_compilation,
      art_automatic,
      REPLACE(art_manual, '.config/Clementine/albumcovers','.local/share/strawberry/strawberry/collectionalbumcovers'),
      effective_albumartist,
      effective_originalyear,
      cue_path,
      rating FROM clementine.playlist_items WHERE TYPE = 'Library';
UPDATE strawberry.playlist_items SET SOURCE = 2;
UPDATE strawberry.playlist_items SET TYPE = 2;
UPDATE strawberry.playlist_items SET artist_id = '';
UPDATE strawberry.playlist_items SET album_id = '';
UPDATE strawberry.playlist_items SET song_id = '';


On recrré les tables FTS :
Code SQL :
DELETE FROM strawberry.songs_fts;
INSERT INTO strawberry.songs_fts (ROWID, ftstitle, ftsalbum, ftsartist, ftsalbumartist, ftscomposer, ftsperformer, ftsgrouping, ftsgenre, ftscomment)
SELECT ROWID, title, album, artist, albumartist, composer, performer, GROUPING, genre, comment FROM strawberry.songs;


On détache les BDD :
Code SQL :
DETACH clementine;
DETACH strawberry;


Et on ferme sqlite3 :
Code SQL :
   .quit


On synchronise le cache des covers :
Code BASH :
cp ~/.config/Clementine/albumcovers/* ~/.local/share/strawberry/strawberry/collectionalbumcovers/


Et on copie le fichier de conf :
Code BASH :
cp ~/.config/Clementine/Clementine.conf ~/.config/strawberry/strawberry.conf


Et voilà !

strawberry



Il m'a juste suffi de désépingler de mon dock Clementine pour mettre Strawberry et de désinstaller Clementine !

Bonne année 2024 !

1 janvier 2024 à 10:50

bonne-annee-2024



Bonjour à tous,

Comme chaque année au premier Janvier, je vous souhaite mes meilleurs vœux de bonheur à tous et à toutes !

J'espère qu'en ces temps difficiles, vous trouverez pour 2024 ce qui vous manquait en 2023 !

Je profite de ce billet, comme pour les années précédentes, pour dresser un bilan.

Début 2023, je n'avais pas forcément d'objectifs définis pour l'année, par conséquent je n'ai ni été surpris, ni été déçu ! En effet, l'année dernière, je n'avais pas pu attendre tous les objectifs fixés dus à d'importants changements dans ma vie personnelle et professionnelle.

Pour 2024, l'objectif sera de passer le site Linuxtricks sur la version 6 du moteur PHPBoost.
Cette nouvelle version apporte un peu de modernité, supporte des versions PHP plus récentes et améliore l'ergonomie du site avec les petits écrans.
Cependant, comme tout changement de moteur, je vais devoir adapter le thème du site. C'est finalement ça le plus compliqué.

Le site quant à lui, bien que peu complété cette année a encore a bien progressé en audience, la chaîne Youtube a continué son développement, on a même passé les 50.000 abonnés, avec une vidéo mémorable réalisée en partie grâce à l'intelligence artificielle. Si vous ne l'avez pas vue, c'est ici : https://www.youtube.com/watch?v=1sKhiebm0w0

Nous avons créé ou modifié près de 107 pages sur le "Wiki", en transformant certaines pages "mémo" en y ajoutant des précisions, des explications détaillées. Initialement, le site était fait pour moi uniquement. Beaucoup de tutos ne rentrent donc pas dans des explications ou des détails mais abordent les sujets en allant droit au but. Grossomodo : Une phrase, la commande puis une phrase et la commande.


Concernant sur Youtube, j'ai publié 119 vidéos cette année, contre 104 l'année dernière. C'est un peu plus que l'année dernière, mais je ne suis pas à la recherche de publications à un rythme fou non plus.
Cependant, les vidéos attitent et cette année, je vous fournis quelques statistiques détaillées de la chaine car les outils d'analyse de Youtube sont excellents :
- 1 800 597 vues sur l'année 2023
- 157 747 heures cumulées visionnées en 2023
- 9333 abonnés de plus en 2023 pour atteindre 51 536 abonnés au total !

Avec un petit peu plus de vidéos, et probablement de meilleure qualité, les statistiques sont meilleures que l'année 2022.
Concernant les revenus mensuels générés par Youtube, ils ont baissé de 21,7% depuis le 18 octobre, où j'annonçais la suppression sur mes vidéos des publicités mid-roll. On en a parlé dans cette vidéo https://www.youtube.com/watch?v=zWAtnC5s8aU . Pour sortir cette statistique, je m'appuie sur la valeur du paneau de statistique intitulée "Revenus pour 1 000 vues (RPM)" afin de prendre une moyenne représentative. Cependant, cette baisse a été constatée dans les virements mensuels.
Selon les statistiques de la chaine, les publicités représentent 92.3% des revenus. 6.1% sont les souscriptions et 1.6% les produits "SUPER" (Super Chat sur les lives ou Super Thanks sur les vidéos). La part de la publicité est très importante, ce qui implique cette chute de revenus.
Mais je préfère retirer ces publicités pénibles pour le visionnement. Il reste toujours de quoi autofinancer la chaine, le site, les noms de domaine, les frais et un peu de surplus pour faire des dons à des associations ou des projets libres.

Rapide point habituel pour les lives «CKOIKIDI», ils continuent sur leur lancée avec un public moyen de 87 viewers sur l'année. C'est pas mal, un peu mieux que l'année dernière. Nous avons testé en Novembre le direct en simultané sur Twitch (qui l'autorise depuis cet automne). Cette plateforme est plus adaptée aux directs, et je la connais bien puisqu'on est déjà dessus. J'y reviendrai dans quelques instants. Bien que techniquement, le premier essai était parfaitement concluant, je ne continureai pas l'aventure du multistream pour plusieurs raisons :
- Il est complexe de porter une attention au public sur les deux plateformes. Le live c'est un moment d'échange. Je préfère me focaliser sur une seule plateforme, Youtube, pour répondre aux questions, et interagir avec vous qui me regardez, c'est ce qu'on attend d'un live.
- Bien que j'ai communiqué sur les réseaux, les personnes qui étaient sur Twitch étaient principalement des curieux qui étaient en même temps sur Youtube. Donc aucun intérêt. Pas de "nouvelles têtes" que je croise chez des streamers Twitch tech (Fixoulab, AHP_Nils, Nidouille). Probablement que mon contenu (que ce soit la forme, le fond ou l'horaire) ne les intéresse pas. Je n'élargis donc pas l'audience.
- Ce fut aussi contre-productif car la chaine Twitch est dédiée à la musique, et j'ai eu des habitués espagnols, polonais, et américains qui se sont demandés ce qui se passait. Je ne veux donc pas mélanger la musique avec mes viewers français et internationaux et l'informatique en français uniquement.


En 2023, on a continué à mixer sur Twitch. Et au mois de Novembre, j'ai eu l'occasion de participer à de nombreux Raid Trains internationaux ! Cela a été génial, j'ai adoré. Vous le savez sans doute, la musique me passionne tout autant que l'informatique, et j'ai pu m'éclater dans ce domaine. J'ai pu, comme l'année dernière voyager un peu et rencontrer IRL des DJ, et ça c'est cool ! On n'a pas tenu les 3 streams par semaine à chaque fois, mais les Mercredis et Dimanches ont été toujours tenus. Le stream du Vendredi soir est une variable d'ajustement qu'on a peu annulé. Les revenus Twitch ont été un peu meilleurs, grâce à la générosité des viewers. Les revenus de Twitch sont à 99,7% dus aux abonnements, bits et dons. Les 0.3% c'est la publicité qui ne rémunère pas du tout sur cette plateforme contrairement à Youtube. Twitch n'est quant à lui pas du tout auto-suffisant financièrement. Ayant à peine remboursé la DDJ-400, j'ai acquis la DDJ-FLX10 avec tous les cables et cartes son pour mixer avec du matériel de meilleure qualité et avec plus de fonctionalités. Mais mixer, c'est pour le plaisir. Certains vont au cinéma, moi je m'éclate à mixer sur Twitch et dans la vie réelle, et ma dépense va là dedans. Je ne pense pas qu'en 2024, on pourra rembourser tous ces nouveaux équipements qui ont couté 2000€ (contrôleur + cables + carte son + micro). Si ça vous, intéresse, pour le moment, je suis là de 19h30 à 22h le Mercredi pour de la Trance, et le Dimanche pour du son chill Melodic Techno & Progressive House. Le vendredi, on est là (mais pas systématique) à partir de 19h30, pour une durée indéterminée, et des styles de musiques électronique variés (Funky House, Techno, HandsUp, Eurodance, ...) cela dépend, c'est totalement aléatoire :)

3 équipes me font dorévavant confiance :
- Golden Force : https://www.twitch.tv/team/goldenforce
- Eyeteam : https://www.twitch.tv/team/eyeteam
- TDJs : https://www.twitch.tv/team/tdjs

Si vous voulez me suivre, voici le lien : https://www.twitch.tv/adrienLT_DJ, nous avons passé en fin d'année les 2000 abonnés ! Je maintiens toujours le compte Instagram, dédié à la musique : https://www.instagram.com/adrienlt_dj/


Tant qu'à parler des réseaux sociaux, en 2023, je me suis inscris sur 2 nouveaux réseaux : BlueSky (la copie de Twitter) et Threads (le Twitter de Meta). Je suis présent historiquement sur Twitter (mon réseau principal) et Mastodon (depuis 2019).

Sur Mastodon, j'ai recommencé à poster un peu, mais c'est que du cross-post de certains Tweets. Et puis m'y connectant peu, si vous répondez à un Tweet sur Mastodon, bah j'y réponds 1 semaine après :D

Quand je me suis inscrit sur BlueSky, j'y voyais un réseau nouveau, ressemblant à Twitter mais en fait, avec le recul, en cette fin d'année, il n'est pas intéressant pour plusieurs points :
- Il y a les mêmes guignols que sur twitter à dire n'importe quoi
- Pour ceux que je suis sur Twitter et Bluesky : ils postent le même contenu donc ça n'a pas d'intérêt
- Il manque énormément de comptes intéressants, notamment les sportifs, la presse, les organisations, les transports, ...
De plus, j'ajouterais que Twitter est parfaitement réglé aujourd'hui, avec des mots masqués par exemple, des listes personnalisées. Sur bluesky certaines fonctions ne sont pas encore implémentées, il faut tout refaire et il manque du contenu.

Cependant, Threads lui est beaucoup plus intéressant. Il est lié à un compte Instagram. J'ai créé en Juillet 2023 2 comptes : adrien_linuxtricks (que je n'utilise plus) et adrienlt_dj (lié au Instagram de la musique).
Utilisant Instagram pour les comptes "Musique", j'ai instantanément retrouvé les comptes de mes artistes favoris. Je me suis aussi abonnés aux comptes Tennis que je suis aussi sur Twitter.
Je vais continuer à utiliser Threads, mais comme alternative à Twitter sur le domaine de la musique et en écrivant en anglais.
Ainsi, on a 2 réseaux qui se ressemblent , fonctionnent pareil, mais je vais en faire 2 usages différents.
Ainsi ceux qui me suivent sur Twitter pour l'informatique ne seront pas pollués par les contenus musicaux.

Twitter restera donc présent, car il est pour l'heure irremplaçable pour ma veille IT, suivre les actualités régionales, nationales et internationales, les informations des institutions (Ministères, ANSSI, ...) et les actualités tennis. Désolé d'avance pour ceux qui me suivent sur Twitter, mais l'Open d'Australie arrive, je risque de répondre et tweeter un peu sur le sujet prochainement :)


Pour finir ce bilan 2023, je reviens sur le site Linuxtricks.
Vous êtes aussi de plus en plus nombreux à consulter mon site d'année en années.

En quelques chiffres :
  • Plus de 4594 visiteurs uniques journaliers en 2023 contre 4099 en 2022
  • Sur l'année 2023, 1551149 pages ont été vues, contre 1447641 en 2022. Le site continue d'être vu. Je suis content évidemment pour un site mémo personnel à la base.
  • 80% des visites viennent de France, le reste de l'étranger avec les États Unis, Le Royaume Uni, le Canada, Belgique et Suisse ! La chine a entre dans le classement juste derrière la Suisse.


Voici quelques stats sur le TOP 5 des systèmes d'exploitation de mes visiteurs:
Windows 10 (36.4%) : +1%
Linux (28.3%) : -1%
Windows 7 (8.7%) : -2%
Android (7,7%) : +1%
Mac OS (6.7%) : -0.1%

A noter que le plus gros site référent (c'est à dire le site qui est consulté juste avant) est DuckDuckGo. On a ensuite QWant, Youtube, Startpage, Ecosia puis Brave.
De nombreux sites sont très bien référencés, je pense notamment à crontab et sudo. Je vais donc travailler prochainement pour enrichir ces pages, ajouter des explications supplémentaires pour améliorer la qualité des articles les mieux référencés et les plus vus.

N'oubliez pas, comme d'hab, les flux RSS sont à votre disposition dans la section A propos, RSS :
Pour le Wiki, c'est ici : https://www.linuxtricks.fr/syndication/rss/wiki
Pour la partie Blogue : https://www.linuxtricks.fr/syndication/rss/news

J'en profite pour rappeler que par respect, s'il vous plait, quand vous citez / Copiez-collez un article qui a été rédigé ici, mentionnez la source et redistribuez le avec la même licence comme l'indique la licence du site. ( CC BY SA )

Merci à tous et longue vie à Linuxtricks !

Fedora 40 va fusionner /usr/sbin et /usr/bin

27 décembre 2023 à 20:40
Bonjour à tous,

Dans un précédent article, nous avions abordé l'arrivée dans Fedora de VLC ( https://www.linuxtricks.fr/news/10-logiciels-libres/538-fedora-vlc-arrive-dans-les-depots-officiels-mais/ ). J'ai eu d'excellents retours sur cet article et la vidéo associée, et vous avez été nombreux à me redemander du contenu d'actualité comme celui-ci.

C'est pourquoi, j'aborde avec vous ici un des changement annoncé de Fedora 40, qui pourra entrainer un changement similaire prochainement sur d'autres distributions Linux telles que Debian par exemple : la fusion de /usr/sbin et /usr/bin.

Pour rappel, voici un extrait de l'article détaillé https://www.linuxtricks.fr/wiki/arborescence-du-systeme-linux :
Arborescence du système Linux - Linuxtricks :

/bin (binaries) => Exécutables essentiels au système, utilisables par tous les utilisateurs (ls pwd cp)
/sbin (super binaries) => Contient les programmes système essentiels utilisables par l'admin uniquement.

/usr/bin => contient des exécutables et des commandes utilisées par les utilisateurs du système.
/usr/sbin => contient des exécutables et des commandes utilisées par l'admin système


Il y a quelques années déjà, la plupart des distributions ont déplacé le contenu de /bin dans /usr/bin et le contenu de /sbin dans /usr/sbin
Cette opération (appellée usr-merge) a simplifié l'arborescence du système. Historiquement, /usr pouvait être une partition séparée, et donc on retrouvait directement dans /bin et /sbin des programmes pour les utilisateurs et l'administrateur permettant d'utiliser le système de base et de monter les partitions (cat, cp, ip, ls, pwd, ... fdisk, fsck, init*, iptables**, lvm, mkfs, mount, resize2fs,)
* init est remplacé par systemd maintenant pour la gestion de l'initialisation
** iptables est remplacé par nftables pour contrôler netfilter.

Une des raisons de cette simplification se retrouve à nouveau dans cette deuxième étape, et nous alons détailler cela ensemble.

Alors, vous allez me dire que cette simplification peut sembler mineure, mais elle a des implications très intéressantes, aussi bien pour les développeurs que pour les utilisateurs.

La distinction entre /usr/bin (programmes essentiels exécutables par l'utilisateur) et /usr/sbin (outils d'administration du système nécessitant généralement les privilèges de l'administrateur) avait du sens à l'époque quand les binaires liés statiquement étaient la norme. Je ne m'étends pas sur ce sujet qui peut être complexe, mais ce qu'il faut comprendre, c'est que les systèmes Linux ont maintenant évolué et disposent de bibliothèques liées dynamiquement. Par conséquent, les cette séparation n'est plus utile.

Les binaires contenus dans /usr/bin et /usr/sbin sont installés par les paquets fournis par la distribution Linux. Les binaires installés manuellement le seront généralement dans /usr/local/bin ou éventuellement dans /opt/nom_de_l_application. Il est donc facile de gérer un éventuel doublon, c'est à dire un programme portant le même nom dans /usr/bin et /usr/sbin.

Concrètement, ce qui va se passer lors de la migration sera la chose suivante :
1- Déplacement des binaires de /usr/sbin dans /usr/bin
2- Suppression de /usr/sbin (alors vide)
3- Création d'un lien symbolique de /usr/sbin vers /usr/bin

Ce lien symbolique permettra de garder la compatibilité avec des scripts que vous aviez écrits (ou livrés par des éditeurs) qui appelleraient un programme de la forme suivante :
Code BASH :
/usr/sbin/monprogramme


Tout comme on voit encore des scripts BASH avec le shebang suivant :
Code BASH :
#! /bin/bash


Cela fonctionne encore même si bash est dans /usr/bin car le lien symbolique de /bin pointe dans /usr/bin

Vous pouvez d'ailleurs voir le vrai chemin de la commande avec :
Code BASH :
readlink -f /bin/bash


Cette fusion va offrir de nombreux avantages :
1- Pour les packageurs : Les développeurs de la distribution, qui vous mettent à disposition les paquets pour toutes vos applications n'auront plus à hésiter pour placer le binaire dans /usr/bin ou /usr/sbin. De plus cela va permettre d'harmoniser entre toutes les distributions Linux l'emplacement des exécutables.
Certaines commandes sont accessibles par l'administrateur et par l'utilisateur comme la commande ip. Elle permet d'afficher la configuration IP, les routes (usage utilisateur) mais permet également de définir une adresse IP, modifier une route (usage administrateur). Alors où placer ce binaire ?
A l'heure actuelle, sous Debian le chemin complet est /usr/bin/ip là où dans les Red Hat like, le chemin est /usr/sbin/ip
2- Pour les utilisateurs : Les utilisateurs n'auront plus à chercher où se trouve la commande. Plus de problème de commande qui n'est pas dans le $PATH de l'utilisateur l'obligeant à créer un alias ou faire un lien symbolique dans /usr/bin (ce qui est moche).
3- Amélioration de l'expérience : Une structure de répertoire plus propre permet de simplifier la compréhension du système, et surtout d'améliorer les dépannages en cas de mode dégradé. L'analyse des journaux peut aussi devenir moins fastidieuse.
4- Amélioration des performances : Les programmes lancés ou outils de débugage auront moins de vérifications de répertoires à faire, ce qui peut légèrement améliorer la réactivité du système, mais ça ne sera pas foufou, on est d'accord.


Ce changement est en cours de discussion mais si il est approuvé, cela sera effectif pour Fedora 40.
Dans le cas de Fedora, les infrastructures qui rebuild les paquets, et les macros installant les binaires dans /usr/sbin (%_sbindir) seront mis à jour automatiquement lors du Mass Rebuild.

Certains paquets qui contiennent des binaires dans /usr/bin et /usr/sbin ont été identifiés et seront modifiés en conséquence. C'est le cas de hddtemp :

Code BASH :
rpm -ql hddtemp-0.3-0.54.beta15.fc39.x86_64

Code TEXT :
/usr/bin/hddtemp
...
/usr/sbin/hddtemp


Le travail sur ces paquets identifiés est en cours pour les adapter et ne causer aucune régrassion.

Après cet état des lieux, je vous donne mon avis. Il va être très court : je trouve que c'est en effet une excellente chose, pour une fois qu'on silmplifie les choses, autant en profiter !
Et vous qu'en pensez-vous ?
Pensez-vous aussi que les autres distributions doivent adopter cette simplification ?

Fedora : VLC arrive dans les dépôts officiels mais ...

15 décembre 2023 à 12:11
Bonjour à tous,

Comme vous le voyez dans le titre, VLC arrive dans les dépôts officiels de Fedora.
Si je vous en parle aujourd'hui, c'est qu'il y a un petit truc qui me chagrine dans cette "bonne nouvelle". J'en profite également pour vous informer si vous utilisez VLC.

Je suis très assidu dans le développement de Fedora depuis de nombreuses années, et je m'informe régulièrement sur les actualits et changements du projet ainsi que des actualités du monde Red Hat. Cette actualité ne fait pas beaucoup de bruit, cependant, je souhaite la développer à travers ce billet.

A titre personnel, je n'utilise pas ce logiciel. J'utilise Clémentine pour le lecteur de musique (qui sait gérer toute la bibliothèque musicale que j'ai), et SMPlayer pour regarder des vidéos.


VLC, depuis très longtemps, est présent dans le dépôt RPM Fusion.
Ce dépôt est incontournable sur Fedora, vous l'installez une fois en quelques lignes de commandes et il reste persistant après chaque montée de version de Fedora. On en a fait un article sur le site accessible à cette adresse : https://www.linuxtricks.fr/wiki/fedora-ajouter-le-depot-rpm-fusion

Avec l'abandon en amont du backend Phonon GStreamer chez Fedora, il est devenu nécessaire d'ajouter vlc à Fedora même, et aussi de restructurer le paquet pour servir à la fois de cadre multimédia et d'application pour l'utilisateur final. En effet, VLC n'est pas "QUE" l'application graphique pour lire une musique ou visionner une vidéo. Par conséquent, les paquets vlc sont maintenant sur le point d'être testés pour F38 et supérieurs ainsi que dans EPEL9, remplaçant les paquets vlc fournis par RPM Fusion.

Au moment de la rédaction de cet article, voici les compilations générées chez Fedora :

Code :
NVR    Built by    Finished descending sort    State
vlc-3.0.20-4.fc38    ngompa    2023-12-15 05:11:30    complete
vlc-3.0.20-4.fc39    ngompa    2023-12-15 05:07:54    complete
vlc-3.0.20-4.el9    ngompa    2023-12-15 05:05:28    complete
vlc-3.0.20-4.fc40    ngompa    2023-12-15 04:59:58    complete
vlc-3.0.20-3.el9    yselkowitz    2023-12-15 03:29:50    complete
vlc-3.0.20-3.fc38    yselkowitz    2023-12-15 01:25:52    complete
vlc-3.0.20-3.fc39    yselkowitz    2023-12-15 01:12:07    complete
vlc-3.0.20-3.fc40    yselkowitz    2023-12-15 01:11:21    complete



Cette démarche semble intéressante pour les utilisateurs de VLC, car on pourra l'installer sans ajouter de dépôt additionnel. L'avoir au format RPM nous évite aussi d'installer la version Flatpak, pour ceux qui préfèrent les paquets natifs.

Oui mais. Car il y a un MAIS.

La version de VLC dans les dépôts de Fedora sera compilée avec tous les plugins activés sauf pour faad2/x264/x265.
Ces codec ne sont pas inclus dans la distribution Fedora par défaut car ils sont liés à des questions de brevets logiciels et de licences. Cela n'est pas nouveau et la problématique existe depuis très longtemps. C'est pour cela que RPM Fusion existe.

Au moment de l'écriture de cet article, RPM Fusion fournit également VLC sous la version 3.0.20-1.

Vous l'avez vu, dans le tableau ci-dessus, Fedora le fournit dans la version 3.0.20 également mais à une révision supérieure (3.0.20-4)
Par conséquent, lorsque le paquet VLC arrivera dans les dépôts, celui-ci sera mis à jour lors de la mise à jour du système, basculant ainsi de la version "RPM Fusion" vers la version "Fedora" sans action manuelle de la part de l'utilisateur. Cependant, cela entrainera une impossibilité de lire des vidéos dont les codecs ont été retirés.


Yaakov Selkowitz (Packageur de VLC dans Fedora qui a initié l'import) a déposé un bug sur le bugzilla de RPM Fusion pour avertir de ce changement.

Il y a un petit problème quand même dans cette affaire, c'est qu'il peut y avoir une régression de fonctionnalités pour l'utilisateur et que ce changement a été fait sans aucune coordination avec le projet RPM Fusion, prenant de court cette dernière. En effet, le paquet risque d'être disponible rapidement, ne laissant pas de temps à RPM Fusion de trouver une solution "transparente" pour les utilisateurs ayant installé VLC.

Yaakov Selkowitz propose néanmoins une solution en indiquant que :
Yaakov Selkowitz :
Parce que vlc utilise une architecture de plugins, il serait à la fois inutile et contre-productif pour vous [RPM Fusion] de continuer à produire un paquetage complet juste pour activer ces plugins. Au lieu de cela, veuillez considérer un paquetage vlc-plugins-freeworld avec seulement ces trois plugins activés.

Si les nouveaux paquets vlc créent des problèmes de mise à jour pour les utilisateurs existants, les bogues doivent être signalés sur le paquet vlc de Fedora.


Nicolas Chauvet, le mainteneur de VLC dans RPM Fusion a répondu, un peu dégouté sur la façon de faire :

Nicolas Chauvet :
Le fait que cette communication ait lieu juste après l'importation du paquet en dit long sur le mépris du projet et de ses utilisateurs.

Certains auraient pu se porter volontaires pour un paquet vlc-freeworld en complément de celui de Fedora, ou pour tout autre problème inattendu induit par ce mouvement. Mais en imposant l'introduction du paquet dans Fedora sans publicité appropriée "en avance sur le calendrier", vous violez le travail de nombreux contributeurs et la possibilité pour les utilisateurs finaux de tester le paquet.

Le fait d'imposer une "Importance majeure" pour obtenir un retour d'information alors que cela aurait pu être correctement coordonné peut être perçu comme du harcèlement.

En ce qui me concerne, je trouve ce comportement dégoûtant et haineux.
Je ne ferai pas d'autres commentaires à ce sujet car j'ai déjà dépassé mon temps de parole.

N'oubliez pas que chacun a le droit de participer à son rythme.


Dans les travaux précédents tous avait été cordonné correctement. Lorsque je parle des travaux précédents, je pense à :
- Octobre 2022 : Accélération vidéo Intel avec intel-media-driver
- Octobre 2022 : Accélération vidéo AMD avec mesa-va-drivers-freeworld et mesa-vdpau-drivers-freeworld
- ffmpeg avec les codecs soumis à brevet logiciel en installant ffmpeg au lieu de ffmpeg-free :

Dans la majorité des cas, ça se passe bien, mais avec VLC, on a un p'tit couac !
En tout cas, si vous utilisez VLC et Fedora, et que vous avez dans les prochains jours des fichiers qui ne se lisent plus, vous savez d'où ça peut venir.

En tout cas, restez connecté sur le site de RPM Fusion, section CommonBugs pour suivre le déroulé et les éventuelles actions à effectuer !

Je ne doute pas, qu'en faisant cet article et en mettant en lumière une petite coquille d'organisation entre les mainteneurs de Fedora et ceux de RPM Fusion, que certains vont pouvoir déverser leur haine sur la distribution Fedora Linux, comme ils savent si bien le faire, sur leur blogue ou les groupes de leur communauté.

Et vous, qu'en pensez-vous ?
Voulez-vous plus d'informations de ce type ? Sur le blogue Linuxtricks ? En vidéo ? En Tweet ?

PC Fixe, je passe de Gentoo à Fedora

28 novembre 2023 à 12:32
Bonjour à tous,

Comme vous l'avez vu dans le titre de cet article, j'utilise maintenant Fedora Linux sur le PC fixe. J'ai réalisé l'installation de la distribution début Novembre 2023.
A travers cet article, je vais expliquer mon choix, car dans le monde du libre, il faut souvent se justifier.
Ce billet de blogue permettra également à celles et ceux qui me demandent pourquoi de les rediriger ici.

Pour une fois, il va y avoir de la lecture sur le blogue, prenez un peu de temps devant vous, suivant la longueur de l'article.


Historique rapide de mon chemin de Linuxien "utilisation maison" sur mon poste principal :

J'ai commencé avec Mandriva 2008, et depuis, je n'ai plus quitté Linux en usage personnel.
Fedora Linux, je l'ai utilisé sur mon PC portable ASUS N76VZ de 2012 à 2015 avec l'environnement de bureau Cinnamon. Elle était en triple boot avec Mageia Cauldron KDE (qui était la future Mageia 3) et Calculate Linux KDE.
J'utilisais avant 2012 Mandriva puis Mageia et j'en étais content, cependant, lorsque j'ai acquis mon nouveau PC portable ASUS, il disposait d'une carte réseau filaire Atheros demandant un kernel très récent et disposait de la "nouvelle" technologie "Optimus" de NVidia, qui ne fonctionnait que manuellement avec "bumblebee" de façon assez aléatoire.
Sur ce PC, je n'avais pas retenu les bases Debian, Ubuntu et Linux Mint, j'avais des kernel panic au bout de 10 minutes d'utilisation. (système installé)
Calculate Linux était assez nouveau pour moi, et je suis resté sur Fedora Linux quelques temps, installant Fedora 17 et l'utilisant jusqu'à Fedora 20, où j'ai définitivement switché après, en monoboot sur Calculate Linux, car je m'y sentais bien.
En 2018, j'acquiers ma tour, montée en Belgique et apportée par Serge, avec qui nous avons fait plusieurs streams sur Youtube sur le sujet de Gentoo.
En janvier 2020, j'installe par curiosité Gentoo sur le PC Fixe, en chroot depuis Calculate, ce qui me permettait de travailler et installer Gentoo en prenant mon temps.
Fin 2021, début 2022, je ne sais plus exactement, à la suite de la bascule de Pulseaudio à Pipewire sur Calculate, je ne pouvais plus enregistrer de vidéo avec OBS Studio, le son grésille. Après une rebascule sur Pulseaudio, je décide d'utiliser définitivement Gentoo à la place de Calculate, pour avoir la maîtrise de mon système et des changements. C'est l'inconvénient d'une distribution "rolling release", les nouveautés arrivent au fil de l'eau, au travers d'une mise à jour banale. Sur une distribution fixed release, ces évolutions arrivent généralement au moment d'un saut de version, le changement est donc maïtrisé puisqu'on peut faire cette opération quand on en a envie.
Bien que les mises à jour de Gentoo, via compilation, soient parfois longues, ce n'est pas grave, puisque j'utilise régulièrement le PC lorsque je le mets à jour en même temps. Par exemple, si je rentre à 19h, et que j'utilise le PC jusqu'à 22h, bien que je mange entre temps, une grosse mise à jour n'excède pas 3 heures.


A propos du PC portable d'appoint :

Je possède un PC portable sur lequel j'avais aussi installé Gentoo. Il y avait cependant moins de logiciels car n'utilisant que peu l'ordinateur, je voulais minimiser le temps de mises à jour et ne pas le laisser allumé une nuit complète par exemple. En février 2023, je décide de basculer le portable sur Fedora. Cette machine étant allumée peu souvent, je passais plus de temps à l'allumer et la mettre à jour que de l'utiliser. Le cas d'usage est très différent du PC fixe, car c'est un portable d'appoint, pour partir en vacances, ou pour faire des formations Linux dans les établissements dans lesquels j'interviens.
J'en ai profité pour :
- chiffrer le disque au complet, car seule la partition home l'était auparavant
- installer les mêmes applis que sur le PC fixe, n'ayant plus de compilation j'ai pu harmoniser les applications.
J'ai créé un script à cette époque pour installer / gérer les logiciels et faire la post-installation de la machine. Ainsi, la config faite sur ce PC peut être réinstallée à l'identique rapidement ailleurs. J'avais ce type de script pour Gentoo, j'ai fait le même pour Fedora.
Caché :


fedo-fixe-script-postinst




A propos de l'utilisation du PC fixe :

J'utilise mon PC Fixe tous les jours, pour enregistrer des vidéos sur ma chaîne, mais surtout pour :
- travailler (mails, comptabilité auto-entreprise, démarches administratives, astreintes, télétravail, achat et tri de musique pour activité de DJ)
- me divertir (Twitch, Eurotruck Simulator, American Truck Simulator, surf sur internet)
- veille technologique et entraide (Telegram, Forums, Machines virtuelles).
Je n'ai clairement plus le temps ni l'envie de maintenir mon système d'exploitation. Si je veux apprendre, tester ou configurer, je le fais à travers de machines virtuelles. Je possède un PC portable dédié aux tests sur du matériel physique.
Bien que j'ai appris énormément avec Gentoo, et qu'elle fonctionne au poil sur le PC Fixe, c'était le moment pour moi de changer, car elle ne répond plus à mon besoin, sur mon PC quotidien.
Il y a des semaines où je n'ai clairement pas envie de "faire de l'informatique" à la maison en rentrant, j'en fais déjà tous les jours au boulot, ou quand je donne des formations, au minimum 39h par semaine.

Mi-octobre, j'ai adapté le script de post-install de Fedora Linux du PC portable à Alma Linux 9, car j'étais à la recherche d'une tranquilité. J'ai packagé les applications manquantes dans mon cépôt COPR "el-apps" ( https://copr.fedorainfracloud.org/coprs/adriend/el-apps ), mais le retour à GNOME40 était un peu violent. Même si je suis à la recherche de tranquilité d'administration du système, j'aime bien avoir des applications à jour, et de bénéficier des améliorations de l'environnement de bureau.
L'utilisation en tout flatpak ne me convenait pas, après avoir testé l'ensemble dans une machine virtuelle pour me rendre compte du cas d'usage.


Participation au challenge Fedora de Gaming Linux FR :

j'ai donc installé Fedora Linux 39 en participant au challenge "Fedora" lancé par VinceFF qui chapote l'équipe de Gaming Linux FR. Elle est présente en dual-boot avec Gentoo.
Régulièrement, cette communauté Linux autour du Gaming, mais pas que, lance des défis. Chacun peut participer en installant la distribution Linux sélectionnée. Le but est de maintenir le système durant un mois, et d'en dresser le bilan, avec des utilisateurs et usages différents.
Je ne participe pas à leur défis mensuels, car je n'ai pas de temps à perdre à réinstaller mon système tous les mois.

Cependant, j'ai souhaité participer à ce challenge pour plusieurs raisons :
- Je contribue à Fedora Linux
- Je baigne dans le monde Red Hat dans le cadre professionnel (de la vraie Red Hat, pas un clone aujourd'hui)
- C'est une distribution que j'aime particulièrement
- Je crontribue à Alma Linux qui est une dérivée de Red Hat, dont Fedora est sa distribution mère
- J'utilise Fedora Linux sur le PC Portable d'appoint qui me satisfait pleinement
- C'est une fixed release dynamique mais stable.
- Le timing du challenge était parfait avec ma volonté de stabilité.


Installation et personnalisation de Fedora :

Après avoir installé le système le 7 novembre au soir, et exécuté le script de post-installation dans la foulée, je me suis retrouvé avec un système opérationnel en 20 minutes (installation et post-installation).
Utilisant un schéma de partitionnement LVM, j'ai au préalable dupliqué mon /home (j'avais de la place sur le SSD). Avant il était commun entre Gentoo et Calculate Linux car je n'avais pas de soucis de version entre les 2 distributions. Calculate construit ses binaires avec ce qui est disponible sous Gentoo, et donc avec les mêmes versions de logiciels, d'environnement de bureau, ...
J'ai réutilisé le volume logique root de Calculate pour la racine de Fedora, et réutilisé le /boot de Calculate pour Fedora.
Bien que Fedora Linux ait écrasé Calculate Linux sur le PC fixe, cette dernière est encore sur d'autres machines pour les contributions à cette dernière.
J'ai réinstallé les mêmes applications natives Gentoo au format RPM et les mêmes Flatpak. J'ai conservé le même environnement de bureau, à savoir GNOME. Ainsi, la personnalisation des applications et de l'environnement n'était pas à refaire.
Le script est disponible sur githib à cette adresse : https://github.com/aaaaadrien/fedora-config


Problèmes rencontrés avec Fedora Linux :

Je n'ai rencontré que quatre problèmes mineurs :
1- OBS Studio installé sous forme de RPM chez Fedora ne propose pas le même plugin de sources web que OBS Studio de Gentoo. J'ai du remettre les 5 sources web manuellement (ce sont les décors pour les live, j'en utilise très peu, je n'aime pas trop les overlays chargés)
Caché :


fedo-fixe-obs



- Kdenlive possédait une zone blanche sur la fenêtre à onglets effets/composition. J'ai déclaré le bug en donnant la solution (dépendances manquantes) et cela a été corrigé en moins de 24h : https://bugzilla.redhat.com/show_bug.cgi?id=2248589
Caché :


fedo-fixe-kdenlive



- Les jeux Eurotruck Simulator et American Truck Simulator sont les 2 seuls jeux pour lesquels le plein écran ne se fait pas, la barre supérieure de GNOME Shell reste, et la barre de titre de la fenêtre s'affiche, décalant le 1920x1080 du jeu d'une cinquantaine de pixels vers le bas. Ces deux jeux ayant des informations importantes en bas de l'écran mais pas en haut, je déplace manuellement une fois la fenêtre avec Alt+F7, et je peux jouer des heures sans rebouger la fenêtre. Seuls ces deux jeux sont concernés, et uniquement sous Wayland, j'avais le même problème sous Gentoo + Wayland et d'autres utilisateurs utilisant Wayland ont remonté cela. Je ne souhaite pas repasser sur Xorg, ça ne me dérange pas plus que ça. Il faut attendre que SCS Software (l'éditeur du moteur du jeu) corrige le problème.
Lorsque le jeu se lance, ça donne ça :
Caché :


fedo-fixe-atsdefaut


Après déplacement avec Alt+F7 de la fenêtre sous la barre gnome-shell, cela n'empêche pas de jouer :
Caché :


fedo-fixe-atsaltf7



- Virtualbox : J'utilise aussi des machines virtuelles VirtualBox, dont certaines avec des interfaces sont en "bridge". L'interface réseau sous Gentoo s'appelait eth0, là c'est enp24s0. Donc VirtualBox m'averti juste que l'interface n'existe pas, et me propose de corriger le réseau au lancement, rapide et efficace :
Caché :


fedo-fixe-vbox




Utilisation, et retour sur l'expérience globale :

Depuis, je n'ai fait qu'utiliser le système et le mettre à jour. Visuellement rien n'a changé.
La dernière fois que j'ai éteint Gentoo, j'utilisais Xorg et Pulseaudio. Cette Fedora utilise Wayland et Pipewire, mais on ne se rend compte de rien.

Je vais conserver le système et continuer à utiliser Fedora Linux car j'ai retrouvé tout ce que j'avais précédemment.
Tous mes périphériques fonctionnent comme sur Gentoo (microphone BIRD UM1 USB, volant + pédales Logitech MOMO Racing)
Toutes mes applications sont là et fonctionnelles.
Tous les jeux Steam fonctionnent (J'utilisais Steam en Flatpak sur Gentoo pour éviter le multilib, j'ai donc installé Steam en flatpak pour Fedora également)
GNOME possède quelques fonctionalités supplémentaires, grâce à la présence de systemd sur Fedora notamment. Je peux aussi me connecter en RDP depuis le PC Windows 10 où je mix quand j'en ai besoin, ce qui m'évite d'utiliser Teamviewer, et ça fonctionne bien avec Wayland
Sur les extensions, j'ai retrouvé mes 2 extensions, à savoir dash-to-dock et appindicator. J'étais avec GNOME 45 sous Gentoo, c'est pareil sous Fedora, aucune surprises, d'autant que ce sont des extensions largement connues.
Caché :


fedo-fixe-gnome-custom



J'ai remarqué quelques améliorations côté performances avec Fedora, l'environnement de bureau GNOME est plus fluide. C'est un ressenti, je n'ai pas fait de benchmark à ce sujet. C'est pourtant la même configuration puisque mon dossier personnel a été dupliqué avec ses préférences.
En revanche, kdenlive est plus rapide au rendu, et c'est factuel puisque je suis en moyenne à un rendu de 20% de la vidéo totale (pour 15mn de vidéo, le rendu dure 3 minutes), là où sous Gentoo, le rendu était de 75% de la vidéo (ces mêmes 15 minutes de vidéo étaient encodés en 12 minutes). Comme pour GNOME, même profil de sortie, même format de vidéo. Même version de ffmpeg, de melt, de kdenlive. Seule la version du noyau a changé.


Conclusion :

Bref, une transition en douceur, qui est passée inaperçue, mais je ne me faisais pas de soucis avec Fedora Linux.
On le sait tous, c'est une distribution mère, la base de Red Hat Enterprise Linux, elle est stable et robuste. Bien que je la qualifie régulièrement de laboratoire de Red Hat, ce n'est pas une version Beta, et on l'a vu pour cette version 39, la sortie a été retardée à cause de bugs plutôt gênants.

En tout cas, j'espère que cet article vous a plu. Il était assez long, ce n'est pas souvent !

Aviez-vous senti que j'allais changer de distribution ?
Mon choix vers Fedora vous surprend-t-il ou vous le trouvez logique ?

N'hésitez pas à vous exprimer dans les commentaires !

Fedora 39 : Testez DNF 5 et Benchmark

12 novembre 2023 à 17:07
Bonjour à tous,

Fedora 39 est sortie depuis quelques jours déjà.
Certains reprochent à la commande dnf (la commande permettant d'installer/supprimer/mettre à jour des paquets) d'être lente.
Je sais qu'on est de plus en plus pressés dans notre société, mais bon... certains sont vraiment des impatients :gene:

Sachez que DNF (actuellement DNF3) est développé en python3 :
Code BASH :
file /usr/bin/dnf

Code TEXT :
/usr/bin/dnf: symbolic link to dnf-3


Code BASH :
file /usr/bin/dnf-3

Code TEXT :
/usr/bin/dnf-3: Python script, ASCII text executable


Une réécriture est en cours et ne dépendra plus de python puisque dnf5 est dorénavent un binaire compilé, à partir d'un code source écrit en C++.
Un programme compilé est "normalement" plus rapide qu'un programme dont le code est interprété. De plus, il est optimisé au passage.

Il devrait être intégré par défaut dans Fedora 41, cependant il est déjà dans les dépôts depuis la version 39 de Fedora.

Si vous souhaitez le tester, installez simplement dnf5 et ses bibliothèques via cette commande en root :

Code BASH :
dnf install dnf5 dnf5-plugins


Une fois installé, il ne remplace pas le dnf classique. Il faudra utiliser la commande dnf5 qui a la même syntaxe que dnf (3) :

Code BASH :
dnf5 install paquet
dnf5 remove paquet
dnf5 upgrade
....


Si vous souhaitez ne pas utiliser la commande dnf5 mais remplacer le dnf classique par dnf5, je vous déconseille de toucher au lien symbolique /usr/bin/dnf

Vous pouvez créer un lien symbolique dans /usr/local/bin (qui est avant dans la variable $PATH) :

Code BASH :
sudo ln -sv /usr/bin/dnf5 /usr/local/bin/dnf


Et voilà, à chaque fois que vous invoquerez la commande dnf, dnf5 sera appelé.

Si vous souhaitez revenir à dnf-3 original, supprimez le lien symbolique :

Code BASH :
rm /usr/local/bin/dnf


N'hésitez pas à rapporter les bugs à l'équipe de Fedora afin de contribuer à dnf5 et à vous rendre utile !

Edit le 14/11/2023 - 20h00 : Benchmark maison :

dnf-3 : VM Fedora fraichement installée.
dnf5 : clone de la VM ci-dessus + installation de dnf5 comme indiqué

Code BASH :
time sudo dnf5 upgrade -y --download-only --refresh

44s avec dnf5

Code BASH :
time sudo dnf upgrade -y --download-only --refresh

1min29s avec dnf-3


Code BASH :
time sudo dnf5 upgrade -y 

4min44s avec dnf5

Code BASH :
time sudo dnf upgrade -y 

5min22s avec dnf-3


Code BASH :
time sudo dnf5 install htop -y

3,141s avec dnf-5

Code BASH :
time sudo dnf install htop -y

5,786s avec dnf-3

Fedora 39 : Testez DNF 5

12 novembre 2023 à 17:07
Bonjour à tous,

Fedora 39 est sortie depuis quelques jours déjà.
Certains reprochent à la commande dnf (la commande permettant d'installer/supprimer/mettre à jour des paquets) d'être lente.
Je sais qu'on est de plus en plus pressés dans notre société, mais bon... certains sont vraiment des impatients :gene:

Sachez que DNF (actuellement DNF3) est développé en python3 :
Code BASH :
file /usr/bin/dnf

Code TEXT :
/usr/bin/dnf: symbolic link to dnf-3


Code BASH :
file /usr/bin/dnf-3

Code TEXT :
/usr/bin/dnf-3: Python script, ASCII text executable


Une réécriture est en cours et ne dépendra plus de python puisque dnf5 est dorénavent un binaire compilé, à partir d'un code source écrit en C++.
Un programme compilé est "normalement" plus rapide qu'un programme dont le code est interprété. De plus, il est optimisé au passage.

Il devrait être intégré par défaut dans Fedora 41, cependant il est déjà dans les dépôts depuis la version 39 de Fedora.

Si vous souhaitez le tester, installez simplement dnf5 et ses bibliothèques via cette commande en root :

Code BASH :
dnf install dnf5 dnf5-plugins


Une fois installé, il ne remplace pas le dnf classique. Il faudra utiliser la commande dnf5 qui a la même syntaxe que dnf (3) :

Code BASH :
dnf5 install paquet
dnf5 remove paquet
dnf5 upgrade
....


Si vous souhaitez ne pas utiliser la commande dnf5 mais remplacer le dnf classique par dnf5, je vous déconseille de toucher au lien symbolique /usr/bin/dnf

Vous pouvez créer un alias dans votre .bashrc en ajoutant cette ligne :

Code BASH :
alias dnf="/usr/bin/dnf5"


Et voilà, à chaque fois que vous invoquerez la commande dnf, dnf5 sera appelé.

N'hésitez pas à rapporter les bugs à l'équipe de Fedora afin de contribuer à dnf5 et à vous rendre utile !

Ubuntu 22.04 : Rester (ou revenir) sur le kernel 5.15

8 août 2023 à 18:16
Bonjour à tous,

Ubuntu a décidé de basculer vers le noyau 6.2 pour ceux qui utilisent le kernel "HWE".
Problème, ce paquet est installé par défaut sur Ubuntu 22.04 sur certaines configuration (même celles installées à la sortie d'Ubuntu 22.04 en avril 2022).
Le kernel 5.15 LTS fourni au début d'Ubuntu 22.04 LTS n'est pas déprécié et sera supporté jusqu'en 2032.
Un noyau plus récent peut être utile pour notamment pouvoir installer Ubuntu 22.04 LTS sur des PC nouvellement sortis (drivers récents inclus).

Certains utilisateurs de cartes graphiques NVidia anciennes, avec leurs pilote propriétaire se voient face à un écran noir. D'autres reviennent sur Nouveau (pilote libre) mais ce dernier manque de performance.

Nous allons voir comment revenir sur le noyau5.15 LTS qui sera supporté jusqu'en 2032 par Ubuntu.

D'abord, on constate qu'on est sur un noyau plus récent :

Code BASH :
uname -r

Code TEXT :
6.2.0-26-generic


Si on liste les paquets linux-image avec la commande suivante :

Nom des paquets : linux-image
Code BASH :
dpkg -l linux-image*

Code :
||/ Nom                                    Version             Architecture Description
+++-======================================-===================-============-=====================================
un  linux-image                                             (aucune description n'est disponible)
ii  linux-image-5.15.0-25-generic          5.15.0-25.25        amd64        Signed kernel image generic
ii  linux-image-6.2.0-26-generic           6.2.0-26.26~22.04.1 amd64        Signed kernel image generic
ii  linux-image-generic-hwe-22.04          6.2.0.26.26~22.04.7 amd64        Generic Linux kernel image
un  linux-image-unsigned-5.15.0-25-generic                  (aucune description n'est disponible)
un  linux-image-unsigned-6.2.0-26-generic                   (aucune description n'est disponible)


On constate qu'on a le 5.15, le 6.2 et le métapaquet linux-image-generic-hwe-22.04

A cet instant (Aout 2023) ce matépaquet tire le kernel 6.2

Si on cherche les métapaquets du kernel via la commande :
Code BASH :
apt search linux-image-generic


On a les résultats suivants :
Code :
linux-image-extra-virtual/jammy-updates,jammy-security 5.15.0.78.75 amd64
  Extra drivers for Virtual Linux kernel image
linux-image-extra-virtual-hwe-22.04/jammy-updates 6.2.0.26.26~22.04.7 amd64
  Extra drivers for Virtual Linux kernel image
linux-image-extra-virtual-hwe-22.04-edge/jammy-updates 6.2.0.26.26~22.04.7 amd64
  Extra drivers for Virtual Linux kernel image
linux-image-generic/jammy-updates,jammy-security 5.15.0.78.75 amd64
  Image du noyau Linux générique
linux-image-generic-hwe-20.04/jammy-updates,jammy-security 5.15.0.78.75 amd64
  Generic Linux kernel image (dummy transitional package)
linux-image-generic-hwe-20.04-edge/jammy-updates,jammy-security 5.15.0.78.75 amd64
  Generic Linux kernel image (dummy transitional package)
linux-image-generic-hwe-22.04/jammy-updates,now 6.2.0.26.26~22.04.7 amd64  [installé, automatique]
  Image du noyau Linux générique
linux-image-generic-hwe-22.04-edge/jammy-updates 6.2.0.26.26~22.04.7 amd64
  Image du noyau Linux générique


Le linux-image-generic-hwe-22.04 correspond à l'image Linux générique utilisée par Ubuntu.
Avec la commande :
Code BASH :
apt show linux-image-generic-hwe-22.04


On voit en dépendance sur le noyau linux en version 6.2 :
Code :
Depends: linux-image-6.2.0-26-generic, linux-modules-extra-6.2.0-26-generic, linux-firmware, intel-microcode, amd64-microcode


Le linux-image-generic correspond à l'image noyau de base d'Ubuntu (5.15)
Avec la commande :
Code BASH :
apt show linux-image-generic


On voit en dépendance sur le noyau linux en version 5.15 :
Code :
Depends: linux-image-5.15.0-78-generic, linux-modules-extra-5.15.0-78-generic, linux-firmware, intel-microcode, amd64-microcode


L'astuce consiste à remplacer le métapaquet linux-image-generic-hwe-22.04 par le linux-image-generic

Code BASH :
apt install linux-image-generic


Ca installe une version plus récente de la branche 5.15 :
Code :
Les NOUVEAUX paquets suivants seront installés :
  linux-image-5.15.0-78-generic linux-image-generic linux-modules-5.15.0-78-generic linux-modules-extra-5.15.0-78-generic


Une fois installé, on reboot la machine.
Si on ne fait rien au niveau du GRUB, on démarre sur le noyau le plus récent (toujours le 6.2 à cet instant).
Au niveau du GRUB (juste après l'écran du BIOS ou de l'UEFI), presser MAJ pour faire afficher ce dernier (qui est masqué par défaut sur Ubuntu si c'est le seul système installé).
Sélectionner "Advanced Option for Ubuntu" et chercher le dernier noyau 5.15 installé.

Vérifier qu'on a bien démarré sur le kernel 5.15 :
Code BASH :
uname -r

Code :
5.15.0-78-generic


Maintenant que le métapaquet "classique" du noyau générique d'ubuntu est installé, on va supprimer celui correspondant au HWE (qui vient chercher actuellement le noyau 6.2 mais qui plus tard pourra vous proposer un 6.5 ou autre) :

Code BASH :
apt autoremove linux-image-generic-hwe-22.04


On revérifie les paquets linux-image installés avec :
Code BASH :
dpkg -l linux-image*

Code :
+++-======================================-===================-============-=====================================
un  linux-image                                             (aucune description n'est disponible)
rc  linux-image-5.15.0-25-generic          5.15.0-25.25        amd64        Signed kernel image generic
ii  linux-image-5.15.0-78-generic          5.15.0-78.85        amd64        Signed kernel image generic
ii  linux-image-6.2.0-26-generic           6.2.0-26.26~22.04.1 amd64        Signed kernel image generic
ii  linux-image-generic                    5.15.0.78.75        amd64        Generic Linux kernel image
un  linux-image-unsigned-5.15.0-25-generic                  (aucune description n'est disponible)
un  linux-image-unsigned-5.15.0-78-generic                  (aucune description n'est disponible)
un  linux-image-unsigned-6.2.0-26-generic                   (aucune description n'est disponible


Il reste encore les résidus du kernel 6.2 (sinon, ils sont encore en premier dans GRUB) :
Code BASH :
apt autoremove linux-*-6.2.0-*-generic


Avec cette commande, ça supprime les headers, modules, extras...

On reboot et on vérifie que c'est tout bon.

Mise à niveau MX21 -> MX23

31 juillet 2023 à 21:07
Bonjour à tous,

Dans ce billet, nous allons voir comment mettre à niveau MX21 vers MX23.

Pour rappel, MX Linux :
- est une distribution basée sur Debian Stable
- propose l'environnement de bureau Xfce par défaut
- possède une "barre des tâches" sur la gauche
- possède des outils maison de configuration
- propose par défaut SysV et peut démarrer si on le souhaite avec systemd

La version 21 est basée sur Debian 11.
Debian 12 est arrivée récemment, et MX Linux a publié sa version 23 basée sur celle ci.

MX Linux ne propose pas de mise à niveau, et donc indique dans sa documentation officielle de réinstaller la version 23 de zéro.

Debian permet de mettre à niveau son système (certes en ligne de commande). Il est donc possible de mettre à niveau MX Linux mais en étant attentifs à certains points.

J'ai réalisé la mise à niveau avec succès de ma MX 21 de test vers la version 23, sur laquelle j'ai installé des logiciels évidemment, des flatpaks et des logiciels qui installent un dépôt tiers (Vivaldi + Google Chrome).

Je vous fais un petit résumé des actions à effectuer, mais n'oubliez pas de faire une sauvegarde de vos documents (et de manière générale, faites des sauvegardes régulièrement).

Procédure de mise à niveau MX21 -> MX23

Toutes les commandes sont à passer en root :
Code BASH :
su -


Dans un premier temps, mettez à jour complètement le système :
Code BASH :
apt update && apt full-upgrade


Ensuite, installez les clés de vérification de signature des paquets de la MX23 (oui ce paquet est dans les dépôts de la MX21) :
Code BASH :
apt install mx23-archive-keyring


Une fois fait, on va remplacer dans les fichiers de sources le nom de code "bullseye" (Debian 11) par "bookworm" (Debian 12) :
Code BASH :
cd /etc/apt/sources.list.d/
sed -e 's/bullseye/bookworm/g' -i *.list

Notons qu'il y a plusieurs fichiers avec l’extension .list, le sed remplacera dans tous ces fichiers.
MX21 utilise le nom de code bullseye et MX23 le nom de code bookworm, par conséquent, il n'y a pas d'autre opération à faire pour les sources de MX Linux.

Debian 12 a introduit un nouveau dépôt "non-free-firmware" dans lequel se trouvent les firmwares non libres. On va rajouter ce dépôt dans les fichiers .list situés au même endroit en remplaçant "non-free" par "non-free non-free-firmware" via un sed à nouveau :
Code BASH :
sed -e 's/non-free/non-free non-free-firmware/g' -i *.list


Une fois fait, on va rafraîchir la liste des paquets disponibles avec ces nouvelles sources :
Code BASH :
 apt update


Puis installer les mises à jour :
Code BASH :
apt full-upgrade


Au cours de la mise à niveau, certains fichiers de configuration demanderont à être éventuellement replacés par un nouveau.
Vu que MX Linux apporte des personnalisations en plus par rapport à sa base Debian, indiquer de conserver le fichier de configuration existant à l'exception de :
- kmod : changement de la variable PATH
- networking : changement de la variable PATH + des changements dans le fichier importants
J'ai retenu ces 2 fichiers en analysant les différences afin de rester cohérent avec les nouveautés de Debian et conserver les personnalisations de MX Linux.

Le problème est que ces questions sont posées régulièrement au cours de la mise à niveau, donc on ne peut pas la lancer et partir 30 minutes...

Une fois la mise à niveau terminée, on reboot :
Code BASH :
reboot


Et voilà, on est sur MX 23 !

J'espère que ce billet vous aura plu.

Debian 12 (Bookworm) est là !

10 juin 2023 à 11:00
Bonjour à tous,

Bien que nous n'ayons pas énormément parlé de Debian sur le blog, et que nous avons peu de tutos sur elle, cette distribution vient d'être publiée en version 12. Son petit nom de code, que je ne sais écrire que par un copier coller : Bookworm !

Cette nouvelle version n'a rien d'extraordinaire, car les "nouveautés" sont déjà présentes dans les autres distributions Linux depuis de nombreux mois. Mais c'est normal, la philosophie de Debian, c'est la stabilité. Casser une Debian est mission impossible, si vous ne bidouillez pas les paquets avec des "backports" et que vous restez sur la version stable.

Essentiellement utilisée sur des serveurs, et par conséquent sans interface graphique, Debian propose de nombreux environnements de bureaux.

Cette Debian 12 va essentiellement rafraichir les composants du système.

L'outil d'installation n'a pas changé depuis de nombreuses années, et avec cette Debian 12, l'installer ne changera toujours pas. Par défaut, le dépôt non-free-firmware est ajouté aux sources, facilitant le support de matériels nécessitant des pilotes non libre. Bonne nouvelle qui évite notamment une perte de temps considérable pour trouver l'ISO "non-free" sur le site de Debian. La détection de Windows 11 a été intégrée s'il est présent dans un cadre de multiboot.

Pour le noyau Linux, on passe du 5.10 au 6.1 (toujours du LTS chez Debian). Ainsi du matériel plus récent pourra être supporté et les performances peuvent être améliorées dans certains cas. On a, pour les gamers, l'inclusion du patch fsync depuis la version 5.16, que du bonheur !
Les possesseurs de carte NVidia récentes pourront bénéficier d'un pilote vidéo pus récent. En effet il passe de la version 470 à 525. Chez AMD et Intel, les pilotes libres évoluent avec les mises à jour du noyau.
Toutes ces nouveautés permettent notamment de prendre en charge beaucoup de nouveaux appareils ARM, et RISC-V

L'environnement de bureau par défaut GNOME passe de la version 3.38 à 43. Un peu de rafraichissement visuel avec des applications en GTK4. Si vous souhaitez utiliser des extensions pour améliorer l'expérience GNOME, j'ai compté 34 extensions dans les dépôts. Les plus utilisées y sont telles que Dash-to-dock, appindicator, weather, gsconnect ou desktop-icons-ng.
Autre changement pour les utilisateurs de GNOME, l'utilisation par défaut de Pipewire en place de Pulseaudio. Pipewire fonctionne de paire avec Wayland, qui sera actif par défaut également.

Pour celles et ceux qui utilisent d'autres environnements de bureau on notera :
- KDE Plasma passe de 5.20 à 5.27 (et les Applications de 20.12 à 22.12)
- Xfce passe de 4.16 à 4.18
- Cinnamon passe de 4.8 à 5.6
- Mate passe de 1.24 à 1.26
- LXQt passe de 0.16 à 1.2
- LXDE est toujours là ...

Au niveau des applications, Debian ne déroge pas à la règle du stable stable stable.
On retrouvera donc parmi les applications phares :
- Firefox en version ESR, version 102 au moment de la sortie de Debian 12
- LibreOffice passe de la version 7.0 à 7.4 qui restera dans cette version pendant tout le cycle de vie de Debian 12

Côté outils de développement, on notera que :
- Python passe de 3.9 à 3.11. Python 2 est définitivement abandonné. Il n'est en effet plus supporté depuis 2 ans.
- Java OpenJDK passe de la version 11 à 17 (qui est une LTS)
- Perl passe de 5.32 à 5.36, vous savez j'adore le Perl :)
- Nodejs passe de la version 12 à la version 18
- PHP passe de 7.4 à 8.2
J'en ai peut être oublié, je vous ai listé ceux que j'utilise le plus ou que je connais :)

Côté serveurs, des montées de version sont à prévoir :
- Apache httpd reste en version 2.4
- NGinx passe de 1.18 à 1.22
- Haproxy passe de 2.2 à 2.6
- Samba de 4.13 à 4.17
- Mariadb passe de 10.5 à 10.11
- Postgre SQL passe de la version 13 à la version 15.
- Glusterfs passe de 9.2 à 10.3

Le processus de mise à jour est manuel, comme d'habitude, en changeant le nom de code dans le fichier sources.list. Je vous ai rédigé un article à ce sujet ici : https://www.linuxtricks.fr/wiki/debian-mettre-a-niveau-de-bullseye-11-vers-bookworm-12

Les notes de version ne sont pas aussi claires selon moi que celles de Fedora ou de Red Hat :)
J'espèce que cette synthèse vous aura plu, et j'espère ne rien avoir oublié.

Bien sûr, pour télécharger Debian, c'est ici : https://www.debian.org/download

:magic:

Edit au 10-06-2023 13:30 : Les notes officielles sont dispo ici, et finalement plus claires que ce que j'avais pu trouver il y a quelques jours à la rédaction de cet article : https://www.debian.org/News/2023/20230610

Ubuntu ne va plus fournir Flatpak dans ses ISO ! Le Point, Mon Avis !

27 février 2023 à 08:10
Bonjour à tous,

Vendredi j'ai fait une vidéo sur le sujet, mais je souhaite, pour celles et ceux qui lisent le site, apporter mon avis par ce billet.

Dans une annonce récente, publiée il y a quelques jours, que vous retrouverez dans les sources de l'article, Canonical annonce arrêter de fournir les Flatpak par défaut. Nous allons rentrer dans les détails de cette annonce.

Tout d'abord, lorsque vous installez des logiciels dans Ubuntu, vous avez 3 possibilités :
- Les paquets DEB : Ce sont les paquets fournis dans les dépôts d'Ubuntu depuis sa création en 2006. Ce sont les paquets historiques, issus de Debian. Comme les RPM chez Fedora. Ils sont compilés et fournis par les développeurs de la distribution.
- Les paquets SNAP : Ce sont des paquets universels. Cette technologie est développée par Canonical et permet aux développeurs de distribuer leurs applications directement aux utilisateurs. Ils permettent une isolation des applications si besoin (ce qu'on appelle le sandboxing en anglais ou bac à sable) et permettent de bénéficier de versions plus récente des logiciels lorsqu'on utilise la version LTS par exemple.
- Les paquets FLATPAK : Ce sont aussi des paquets universels, qui existent sous Linux depuis 2007 (appelés à l'époque XDG-APPS) et qui offrent les mêmes avantages que les paquets SNAP présentés précédemment.

On pourrait rentrer dans les détails techniques des différences entre ces trois types de paquets mais ce n'est pas l'objet de ce billet.

Pour en revenir à l'annonce, nous apprenons que : Flatpak ne sera plus disponible "prêt à l'emploi" dans aucune des versions officielles d'Ubuntu, incluant leurs variantes.

Alors rentrons un peu dans le détail de cette actualité. Les développeurs d'Ubuntu on accepté de ne plus fournir de support PAR DEFAUT de flatpak, c'est à dire le paquet flatpak, des applications flatpak et les plugins pour gérer flatpak à travers la logithèque graphique (le Ubuntu Store, Discover dans Kubuntu, etc.). Cette décision prendra effet à partir de la version 23.04 d'Ubuntu et dans ses 8 variantes officielles.

Par conséquent, seuls les paquets DEB et SNAP seront disponible par défaut.

Chez Ubuntu, le choix est justifié en indiquant que cela, je cite : "améliorera l'expérience Ubuntu out of box" pour les nouveaux utilisateurs.
Ils clarifient même, ce qu'est pour eux l'expérience Ubuntu. Ils nous précisent en fait que quelqu'un qui utilise Ubuntu ou une de ses variante qui offre des Flatpak pourrait supposer que la technologie reçoit le même niveau de support, de correction de bug et de contrôle qualité que les applications présentes dans les dépôts au format DEB ou aux SNAP qui eux sont mis à disposition par la communauté de développeurs d'Ubuntu et de Canonical. Ce qui n'est pas le cas, car les flatpak sont gérés indépendamment.

Alors tout ça, c'est valable à partir d'Ubuntu 23.04.

Il faut quand même relativiser, car quand l'annonce indique que ce n'est pas installé par défaut, ce n'est pas la même chose que "pas installé du tout". Il sera tout à fait possible d'installer librement flatpak (via apt install flatpak) puis d'installer le dépôt flathub en suivant le guide sur leur site (ainsi que tous les plugins pour les éventuelles logithèques graphiques utilisées). Ensuite, il sera possible comme avant d'installer les applications flatpak.
Aussi, il est bon de noter qu'évidemment, flatpak ne sera pas supprimé lorsque vous passerez à Ubuntu 23.04 s'il était installé précédemment, et les applications installées sous ce format ne seront pas désinstallées !

Ca ce sont les faits de l'annonce.

Après, si vous me demandez mon avis là dessus, je ne sais pas trop quoi penser.
Je peux comprendre que la politique s'applique à Ubuntu Desktop (la saveur officielle), pour rester dans un écosystème maitrisé pour offrir le support durant toute sa durée de vie, puisque Canonical fournit du support contre de l'argent.
Après, pour les variantes officielles, il y avait 2 possibilités :
- Laisser les variantes décider de ce qu'elles fournissent (et de laisser un peu de libertés pour ajouter des éléments et combler les lacunes d'Ubuntu, que ce soit par l'environnement de bureau ou les outils et donc possiblement garder flatpak)
- Harmoniser les variantes avec la politique de la saveur officielle afin de garder une cohérence dans la gamme de distribution dans son ensemble.

Parfois, les variantes innovent sur les logiciels et technologies fournies. On remarquera des différences sur les environnements de bureau mais aussi sur les outils d'installation, les gestionnaires de connexion, les thèmes d'icônes ou certaines applications remplacées par d'autres. Ici, je parle bien de logiciels et outils inclus, pas une version différente (comme une version de noyau différent).
Isoler Flatpak pour les variantes, ça semble un peu violent, par rapport aux tolérances citées précédemment.
Sans compter que flatpak c'est développé activement, c'est robuste, et c'est pas un truc développé par trois gus dans leur garage.
Après, on peut comprendre l'objectif de vouloir harmoniser ses pratiques même avec les variantes.

Le principal, c'est que cette suppression n'est pas forcée ni imposée, pour celles et ceux qui utilisent flatpak, c'est déjà ça... Enfin, pour le moment!

Cependant, je ne suis pas spécialement convaincu par l'argumentation avancée par Canonical. Elle semble un peu légère je trouve, car j'ai l'impression qu'il n'y a pas spécialement de bonnes raisons techniques derrière cette décision.

Je ne pense pas que Snap soit meilleur que Flatpak ou inversement, ils ont des objectifs différents.
Par exemple, vous avez des moteurs de base de données en SNAP, et des outils en ligne de commande. Ce que ne fait pas FLATPAK.
Après, Canonical a clairement choisi de mettre en avant son nouveau système de paquets et de retirer des installations par défaut un de ses confrère.

Ca c'est mon petit avis sur la question,

Et vous qu'est ce que vous pensez de cette décision ?
Est-ce que ça va rendre meilleur Ubuntu ?
Ou au contraire est-ce que ça va faire détester encore plus cette distribution ?

N'hésitez pas à vous exprimer dans les commentaires.
❌
❌