Archlinux OpenRC : une idée généreuse desservie par une mise en oeuvre lourdingue ?

J’ai pu discuter, suite à l’histoire du bug de systemd lié à un déni de service en local dont vous trouverez la version technique sur l’outil de suivi de systemd, avec l’équipe de Devuan qui sabrait une nouvelle fois le champagne. Leur faisant remarquer qu’il n’y avait pas de version avec OpenRC, la réponse me fit comprendre qu’une image ISO était envisageable, du moins, une fois certains problèmes techniques corrigés.

En faisant quelques recherches, je suis tombé sur ce fil sur la liste de publication de la Devuan, en date du 11 septembre concernant les mésaventures avec OpenRC.

Ayant déjà pu apprécié Manjaro Linux OpenRC, j’ai voulu voir où en était la maison mère, Archlinux avec l’outil d’init en question. Fin 2015, j’avais « OpenRCisé » une Archlinux avec Mate Desktop. J’ai voulu partir cette fois directement de l’ISO proposée pour finir avec une session en Mate Desktop gtk3.

Grace à mon moteur de recherche préféré, je suis tombé sur le projet Arch-OpenRC qui propose une image ISO qui intègre directement OpenRC.

Apparement, le complément d’instructions pour l’installation est fourni par le site systemd-free.org, déjà utilisé dans mon article de décembre 2015.

J’ai donc récupéré l’ISO du mois d’octobre 2016 via wget. En gros, l’ISO sortie la veille de la rédaction de l’article.

[fred@fredo-arch ISO à tester]$ wget -c http://heanet.dl.sourceforge.net/project/archopenrc/arch-openrc/archlinux-openrc-2016.10.01-dual.iso
–2016-10-01 22:09:22– http://heanet.dl.sourceforge.net/project/archopenrc/arch-openrc/archlinux-openrc-2016.10.01-dual.iso
Résolution de heanet.dl.sourceforge.net (heanet.dl.sourceforge.net)… 2001:770:18:aa40::c101:c142, 193.1.193.66
Connexion à heanet.dl.sourceforge.net (heanet.dl.sourceforge.net)|2001:770:18:aa40::c101:c142|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 825229312 (787M) [application/octet-stream]
Sauvegarde en : « archlinux-openrc-2016.10.01-dual.iso »

archlinux-openrc-20 100%[===================>] 787,00M 2,95MB/s in 5m 37s

2016-10-01 22:15:00 (2,33 MB/s) — « archlinux-openrc-2016.10.01-dual.iso » sauvegardé [825229312/825229312]

Puis VirtualBox a été mon allié dans cette quête.

Si l’ISO démarre bien sur OpenRC, il y a un problème de conception du fichier /etc/pacman.conf. Au lieu de mettre en haut de liste les dépots dédié à l’installation d’OpenRC et de ses outils, ils sont tout en bas.

En clair, si on ne modifie pas l’ordre des dépots, on démarre la première fois avec un système « hybride ». Si ça arrive à démarrer. Bref, c’est pas comme si c’était précisé en toute lettre dans le ficher… Merde, ça l’est ! Par chance, la version installée du fichier /etc/pacman.conf est correct sur ce point précis. Bizarre que ce ne soit pas directement le cas dans l’image ISO pour installer le système.

L’installation est la même entre une Archlinux avec systemd et une avec OpenRC sauf quelques modifications. Les points de différences principaux ?

  1. Pour définir le nom de la machine, c’est dans le fichier /etc/conf.d/hostname et non /etc/hostname
  2. S’il faut toujours remplir le /etc/locale.conf, le clavier se définie dans /etc/conf.d/keymaps
  3. Activer un service se fait via la commande rc-update add nom-du-service default au lieu de systemctl enable nom-du-service.
  4. Il faut passer par le fichier /etc/conf.d/xdm pour définir le gestionnaire de connexion à utiliser.
  5. Par défaut, l’installation définit l’heure en mode UTC. Il faut aller dans /etc/conf.d/clock pour avoir du localtime en cas de double démarrage avec MS-Windows.
  6. La ligne d’ajout d’un utilisateur est plus longue.
  7. On doit rajouter Consolekit pour remplacer l’outil systemd-logind.

Le début de l’installation se passe pas trop mal.

Bref, on peut estimer que l’installation est identique à 90% entre les deux systèmes d’initialisation. Des captures d’écran pour la configuration du nom de la machine et du clavier à utiliser :

À noter que certains paquets alternatifs sont directement instaléls, d’autres pas. Si on demande cups, c’est la version systemdisée qui s’installe. Pour avoir la version pour OpenRC, il faut préciser directement cups-nosystemd. Idem pour networkmanager.

De plus, il semble y avoir un bug étrange… Si on mets les dépôts openrc en haut du fichier /etc/pacman.conf, ce dernier est complètement explosé dans le chroot… Quelle joie ! Le contournement est relativement simple.

Avant de passer en chroot, il suffit de copier le fichier /etc/pacman.conf pour avoir quelque chose de fonctionnel.

J’ai pu remplacer les versions systemd par les versions OpenRC des paquets concernés. À savoir au minimum cups-nosystemd et networkmanager-openrc.

La deuxième couche :

J’en ai profité pour activer NetworkManager avec un :

rc-update add NetworkManager default

Pour cups – tant que j’y étais – il m’a fallu rajouter cups-openrc… Remplaçant au passage certains éléments non échangés au passage. Les deux dépots dédiés auraient-ils des problèmes au niveau de la gestion des conflits de paquets ?

L’activation de cups ?

rc-update add dbus default
rc-update add cupsd default

Une fois redémarré, j’ai pris le guide sur systemd-free pour rajouter les éléments manquants et voir quels éléments alternatifs n’ont pas été installé au premier passage.

J’ai donc copié les deux lignes suivantes :

pacman -S --needed dbus-openrc procps-ng-nosystemd netifrc
pacman -S --needed acpid-openrc alsa-utils-openrc autofs-openrc consolekit consolekit-openrc cgmanager-openrc cronie-openrc dbus-openrc cups-openrc displaymanager-openrc fuse-openrc haveged-openrc hdparm-openrc openssh-openrc samba-openrc syslog-ng-openrc

Et la suite :

La ligne suivante concerne l’activation des services. J’ai repris la ligne, mais en faisant sauter xdm temporairement. Donc :

for daemon in acpid alsasound autofs dbus consolekit cronie cupsd fuse haveged hdparm smb sshd atd; do rc-update add $daemon default; done

Quand j’ai voulu installer xorg, j’ai eu droit à un autre conflit : celui entre xorg-server-common et xorg-server-common-nosystemd… On se demande si les développeurs des dépots ont pensé à remplir les lignes conflicts() des PKGBUILD… Sans oublier un deuxième conflit au niveau du duo xorg-server et xorg-server-nosystemd…

Voici la sortie d’un pacman -S xorg…

D’ailleurs, il y a un ultime conflit entre mesa et mesa-nosystemd… Résultat des courses ? Une installation à la main en précisant le nosystemd à chaque fois.

Pour rajouter le compte utilisateur, je me suis inspiré la page configuration du site systemd-free :


useradd -m -g wheel -c 'nom de l'utilisateur' -s /bin/bash/nom-de-connexion
gpasswd -a nom-de-connexion video
gpasswd -a nom-de-connexion audio
gpasswd -a nom-de-connexion input
gpasswd -a nom-de-connexion power
gpasswd -a nom-de-connexion lp
gpasswd -a nom-de-connexion scanner
gpasswd -a nom-de-connexion optical
gpasswd -a nom-de-connexion storage

Pour la série de gpasswd, c’est pour remplacer la commande usermod qui n’a pas fonctionnée 🙁

J’ai enfin pu rajouter Mate-Desktop Gtk3, avec LibreOffice, les pilotes pour cups, Mozilla Firefox, Mozilla Thunderbird et tout l’équipement qui va bien. Puis j’ai lancé Kazam pour faire la capture vidéo. Utilisant Pamac, j’ai eu droit à une petite surprise en faisant une recherche basique pour le paquet syslog-ng qui s’occupe des fichiers de log…

J’ai décidé de capturer l’ensemble en vidéo.

Je dois dire que l’installation d’une Archlinux qui me prend 40 minutes voire 50 minutes avec un environnement lourd m’a pris plus de 90 minutes pour contourner toutes les chausse-trappes que j’ai listé dans l’article. Sans oublier nombre de paquets qui auraient dû être installé et ne l’ont pas été…

Autant l’installation de la Manjaro OpenRC est une partie de plaisir, autant celle de la ArchLinux OpenRC est une purge à l’huile de ricin frelatée. Il y a encore énormément de chemin à faire pour la rendre crédible aux yeux des personnes voulant utiliser le duo OpenRC avec une base Archlinux.

Il faut vraiment être motivé pour y arriver. Si vous voulez une base Archlinux avec OpenRC, n’allez pas plus loin que la Manjaro OpenRC. Après, libre à vous de voir un début de calvitie apparaitre suite à l’installation de la Archlinux OpenRC.

7 réflexions sur « Archlinux OpenRC : une idée généreuse desservie par une mise en oeuvre lourdingue ? »

  1. je ne sais combien de bug de sécurité vont être trouvé en attirant les spécialistes de la sécurité sur systemd,
    nous avons le mainteneur d’OpenRC côté Manjaro qui a repris en synthèse a moyen terme d’AGWA
    il est bien difficile de voir a moyen terme ou va systemd, j’espère qu’il ne deviendra pas un 2eme sous-systeme linux ,
    a ce jour je n’ai toujours pas compris pourquoi systemd tente de gérer les DNS et les réseaux par exemple.

    pas mal de distributions non pas forcement d’option de secours vis à vis de systemd

    si jamais d’autres anomalies sont trouvés par la suite , obligeant a revoir la gestion de démarrage des services systèmes , nous avons au moins OpenRC plus ou moins à jour pour la Manjaro.

    dans le lien , un autre élément a été pointé , un codage en dur d’un offset , chose dont on sait qu’il doit être absolument banni en terme de règle de codage depuis 50 ans…

    1. Manjaro OpenRC est installable sans se chopper une cirrhose du foie à cause d’une consommation excessive d’aspirine.

      Je n’utilise pas la fonction DNS pour système, ni encore moins les fonctionnalités réseau. Pour le réseau, je passe par NetworkManager qui fait le travail qui va bien.

      OpenRC est à peu près potable, même si sa configuration est parfois chiante.

      Aucun logiciel n’est sans bug. Mais on ne peut pas rester éternellement avec sysVinit. OpenRC et systemd apporte des réponses. Tout comme runit.

      J’utilise le minimum de systemd, à savoir sa gestion des services. Que ce la connexion réseau, la gestion de l’heure je passe des outils idoines.

Les commentaires sont fermés.