Les installateurs facilitants pour Archlinux… Mieux vaut en rire qu’en pleurer, surtout en cas de pépins…

Je dois vous raconter mes petites mésaventures matinales pour vous faire mieux comprendre le pourquoi du comment de ce billet. Mais commençons par un peu de contexte.

Hier soir, le 22 novembre, je suis allé sur le forum d’EndeavourOS et je suis tombé sur un fil concernant une modification concernant le logiciel CUPS qui est l’outil de gestion des imprimantes dans le monde linuxien.

En effet, Apple qui a maintenu durant des années le code de CUPS l’a laissé pourrir toute l’année 2020. Si on regarde au niveau des modifications de code en ce 23 novembre 2020, une seule entrée le 27 avril pour dire que CUPS 2.3.3 était sorti. Je ne sais pas pourquoi, mais ce code en train de se dessécher à l’air libre, ça me rappelle les conditions de naissance d’un certain LibreOffice.

Un fork – plus qu’utile pour une fois – a été lancé par l’organisation OpenPrinting. Sur le fil du forum d’EndeavourOS, j’ai appris qu’il fallait modifier le service pour lancer cups. En effet, on est passé du service org.cups.cupsd à cups.service. Ce qui est ennuyeux pour les installations automatisées.

Autant dire que la plupart des installateurs facilitant sont impactés jusqu’à la sortie d’une nouvelle version et si on utilise un d’entre eux actuellement, comme Anarchy, EndeavourOS, RebornOS ou encore Calam Arch Installer, c’est mal barré pour avoir le service CUPS fonctionnel au démarrage si le besoin s’en fait sentir.

J’en ai profité pour prévenir Chennux qui maintient un « fork » de mon guide d’installation pour Archlinux sur github. Ainsi qu’Anarchy pour qu’il corrige le code touché par la modification du service utilisé.

Imaginez donc la bonne surprise avec un installateur non à jour en ce qui concerne CUPS. Bienvenue dans les joies de l’administration d’une base Archlinux.

J’ai fini la parenthèse du contexte. Ce matin, je vais sur youtube et je tombe sur une vidéo promouvant Calam Arch Installer (qui ressemble étrangement à EndeavourOS sur le plan des principes utilisés). Je me suis dit que la vidéo en question tombait bien mal.

Une nouvelle fois, ce n’est pas l’installation d’une Archlinux qui est complexe, il suffit de savoir lire et d’avoir de bonnes bases en anglais. C’est la maintenance sur le long terme, et quand ce petit genre de pépin arrive, nombre de personnes qui ne se doutaient pas de la difficulté d’administrer une installation d’Archlinux bazarderont le tout.

Mais il est vrai que ce n’est que la quinzième fois que je parle de ce problème… Mais comme on dit : il n’y a pas pire sourd que la personne qui se bouche les oreilles. Sur ce, bonne journée 🙂

Ah, la grande famille Archlinuxienne ;)

C’est un commentaire d’Éric sur mon précédent billet en vrac’ qui m’a donné envie de faire ce court billet. Car il faut le dire : se retrouver dans la famille Archlinuxienne, ce n’est pas évident.

Il y a un peu de tout, et surtout n’importe quoi. Mais essayons de faire un inventaire de l’ensemble sans oublier trop de monde au passage.

Outre la maison mère, on trouve les projets qui sont des Archlinux plus ou moins pures dont voici la liste, du moins les projets encore activement développés au moment où je rédige cet article :

  1. EndeavourOS
  2. RebornOS
  3. Anarchy (un installateur)
  4. Zen Installer (un autre installateur)
  5. Arco Linux et ses innombrables images ISO
  6. Artix Linux, anciennement Archlinux OpenRC
  7. Obarun, une Archlinux avec s6 comme init par défaut
  8. Parabola GNU/Linux, la Archlinux 100% Libre
  9. Garuda Linux, un peu spéciale 🙂

Les distributions qui y ressemblent sans en être vraiment ? On peut citer KaOS qui est une cousine d’Archlinux, car elle utilise pacman mais sans être une base Archlinux, mais une base Linux From Scratch.

Il serait dommage d’oublier la fille la plus célèbre d’Archlinux, j’ai dénommé Manjaro Linux qui n’est pas en odeur de sainteté dans certains cercles bien informés 🙂

Sans oublier l’idéologique TromJaro, qui me fait demander si les personnes derrière le projet n’abuse pas de gateaux spatiaux… 😀

Enfin, pour finir, je citerais le duo de script archfi / archdi qui permettent l’installation d’une base Archlinux en partant de l’image d’installation officielle.

Une douzaine de projets et encore, j’ai dû en oublier au passage, je tiens à m’excuser pour les dits oublis. Autant dire qu’une araignée n’y retrouverait pas ses petits…

Mais, c’est ainsi que vit le logiciels libre, de forks en forks, qu’ils soient plus ou moins bien justifiés, plus ou moins bien assumés.

Déjà un an EndeavourOS ? Bon anniversaire alors !

En septembre 2019, j’écrivais un article où je précisais que j’étais un des membres de l’équipe de modération du forum d’EndeavourOS, un installateur pour Archlinux de très bonne qualité. Au point d’avoir été cité à l’époque dans un article qui parlait des « héros cachés » du projet.

Fred Bezies – For bringing out bug reports on our ongoing work on the Github page.

Ce qui m’a valu une place de modérateurs et la confirmation que le surnom que je me suis auto-attribué – et qui fait toujours rire – de BugMan est justifié. Je me suis aussi impliqué à mon niveau – mais moins qu’à l’époque Tux’n’Vape – dans le projet. J’ai une machine virtuelle qui me permet de compiler des images ISO quand j’en ai besoin qui est vieille de plusieurs mois et qui est toujours en excellent état.

Mon implication la plus forte reste sur le forum où je donne des coups de main de temps à autres, et surtout à la traduction des annonces – fortement aidé par Deepl.com pour gagner du temps – et de l’outil d’accueil « Welcome » dont Florent (ou Florian ?) alias FLVAL avait commencé la traduction et que j’ai repris.

Si je me suis approché du projet, c’est qu’il a compris dès le départ ce qui avait été l’échec d’Antergos, en dehors d’un installateur en éternelle version bêta : vouloir trop en faire.

Dans les notes de publication de l’image ISO du premier anniversaire, la plus grande annonce, c’est l’arrivée d’une version pour ARM.

C’est logique après tout. Mais ce qui est bien avec ce projet dont les serveurs sont financés pour les deux ans à venir, c’est qu’en cas d’arrêt total, les installations pourront continuer d’être mises à jour, car c’est une Archlinux pure et dure qui est installée, avec les petits inconvénients que cela entraine.

Mon cadeau à ce premier anniversaire, c’est une vidéo pour montrer en action les nouveautés de l’outil Welcome en version 3.0 et de l’excellent AKM.

On se dit – pour ce sujet – rendez-vous dans un article pour juillet 2021 et le deuxième anniversaire d’EndeavourOS ? 🙂

C’est vrai, c’est bien connu, Archlinux ça ne tient pas le choc dans le temps :)

Un petit billet d’humour sur une rumeur tenace sur Archlinux. Je suis Archlinuxien depuis plus de 10 ans. Et en moyenne, mes installations tenaient dans les deux ans. Il faut dire que je leur en mettais plein la… figure et j’étais bien content de les voir tenir aussi longtemps 🙂

Cependant, en ce 15 juin 2020, je viens de m’apercevoir que mon installation actuelle d’Archlinux faite à l’époque en utilisant l’outil Anarchy – pour gérer l’UEFI que je ne maitrisais pas franchement en 2018 – approche petit à petit des 900 jours. Oui, 900 !

Pour être plus précis, 839 jours. Donc au 15 août 2020, les 900 jours seront atteints. Les 1000 ? Au 23 novembre 2020. Tiens, une idée pour un billet dans quelques mois, c’est cool 🙂

Comme quoi, on peut très bien avoir des installations vieilles de deux ans voire plus qui sont toujours en vie sur une Archlinux.

Il y a une formule du droit romain qui dit ceci : « Quod gratis asseritur, gratis negatur » ce qu’on peut traduire par : « Ce qui est affirmé sans preuve peut être nié sans preuve ».

Voici donc la sortie de la commande head /var/log/pacman.log -n 20. En gros, les 20 premières lignes du fichier qui enregistre les activités de pacman.


[2018-02-27 17:39] [PACMAN] Running 'pacman -r /mnt -Sy --force --cachedir=/mnt/var/cache/pacman/pkg --noconfirm bash bzip2 coreutils cryptsetup device-mapper dhcpcd diffutils e2fsprogs file filesystem findutils gawk gcc-libs gettext glibc grep gzip inetutils iproute2 iputils jfsutils less licenses linux logrotate lvm2 man-db man-pages mdadm nano netctl pacman pciutils pcmciautils perl procps-ng psmisc reiserfsprogs s-nail sed shadow sysfsutils systemd-sysvcompat tar texinfo usbutils util-linux vi which xfsprogs alsa-utils base-devel cpupower cups cups-pdf dialog efibootmgr ffmpegthumbnailer git grml-zsh-config grub gst-libav gst-plugins-bad gst-plugins-base gst-plugins-good gst-plugins-ugly gtk3-print-backends gtk-engine-murrine gvfs gvfs-mtp gvfs-smb libreoffice-fresh libreoffice-fresh-fr lightdm lightdm-gtk-greeter lightdm-gtk-greeter-settings linux-headers mate mate-extra mesa-libgl networkmanager network-manager-applet ntfs-3g pamac-aur pavucontrol pulseaudio pulseaudio-alsa screenfetch ttf-dejavu unzip vim wget wireless_tools wpa_actiond wpa_supplicant xdg-user-dirs xf86-video-ati xorg-apps xorg-server xorg-xinit xterm zsh zsh-completions zsh-syntax-highlighting'
[2018-02-27 17:39] [PACMAN] synchronizing package lists
[2018-02-27 17:44] [ALPM] transaction started
[2018-02-27 17:44] [ALPM] installed linux-api-headers (4.14.8-1)
[2018-02-27 17:44] [ALPM] installed tzdata (2018c-1)
[2018-02-27 17:44] [ALPM] installed iana-etc (20180221-1)
[2018-02-27 17:44] [ALPM] installed filesystem (2017.10-2)
[2018-02-27 17:44] [ALPM] installed glibc (2.26-11)
[2018-02-27 17:44] [ALPM] installed gcc-libs (7.3.0-1)
[2018-02-27 17:44] [ALPM] installed ncurses (6.1-3)
[2018-02-27 17:44] [ALPM] installed readline (7.0.003-1)
[2018-02-27 17:44] [ALPM] installed bash (4.4.019-1)
[2018-02-27 17:44] [ALPM] installed bzip2 (1.0.6-7)
[2018-02-27 17:44] [ALPM] installed attr (2.4.47-3)
[2018-02-27 17:44] [ALPM] installed acl (2.2.52-4)
[2018-02-27 17:44] [ALPM] installed gmp (6.1.2-1)
[2018-02-27 17:44] [ALPM] installed libcap (2.25-1)
[2018-02-27 17:44] [ALPM] installed gdbm (1.14.1-1)
[2018-02-27 17:44] [ALPM] installed db (5.3.28-3)
[2018-02-27 17:44] [ALPM] installed perl (5.26.1-2)

En l’espace de presque 940 jours, je suis passé d’un noyau Linux 4.14.x ou 4.15.x au 5.7.2. Soit une quinzaine de versions (du 4.14 ou 15 au 4.20, puis du 5.0 au 5.7). Sans oublier la tétrachiée de versions mineures intermédiaires. De même, mon installation est passée de gcc 7.3.x à la version 10.1, de la glibc 2.26 à la 2.31, a connu Mate-Desktop 1.20, 1.22, 1.24 et actuellement Gnome 3.36. Autant dire que ça a pas mal bougé 🙂

Sans oublier les logiciels installés une fois puis viré, les émulateurs, les virtualisateurs, etc… Mon installation a même survécu – grâce aux bons soins d’un certain BabaOrhum – au passage du système d’un disque dur vers un nvme…

Continuer la lecture de « C’est vrai, c’est bien connu, Archlinux ça ne tient pas le choc dans le temps 🙂 »

Archlinux et la mise à jour moisie de Samba, suite mais pas fin ?

Dans un précédent article, je parlais de l’arrivée d’une version moisie – une version de développement vieille de près de 4 mois – de Samba sur Archlinux.

Outre le fait qu’il y avait un bug lié à Python 3.8 qui cassait le fonctionnement de samba-tool, une deuxième couche du problème est rapidement apparu, et ne concerne que certains périphériques.

La version 4.12.0 – on en est à la 4.12.0-3 en ce 2 avril 2020 – est arrivée sur les dépôts de test. J’ai donc profité de l’occasion pour débloquer les paquets ignorés. Un redémarrage plus tard, j’avais toujours le même problème : impossible d’accéder aux partages de ma FreeBox Revolution serveur.

Après quelques recherches, je me suis aperçu que le code de la FreeBox pour cette fonctionnalité est restée bloquée sur le protocole SMBv1… Un bug a été ouvert sur l’outil de suivi de Free en octobre 2017 et n’est toujours pas clos.

Si on en croit les commentaires, c’est le passage du code en GPLv3 qui bloque la montée en version du protocole.

Bref, c’est la mouise… Comment le contourner ? Si vous avez un périphérique bloqué sur cet ancien protocole déprécié et que vous utilisez une Archlinux, il faut modifier le fichier /etc/samba/smb.conf et rajouter dans la section [global] ceci, dixit un message de David C. Rankin sur la liste de publication arch-general.


client min protocol = NT1
server min protocol = NT1

Une autre option étant d’employer CORE à la place de NT1.

Continuer la lecture de « Archlinux et la mise à jour moisie de Samba, suite mais pas fin ? »