URL: https://linuxfr.org/users/tontonbenoit/journaux/laisser-openrc-de-cote-dans-gentoo Title: Laisser OpenRC de côté dans Gentoo Authors: Tonton Benoit Date: 2014年12月02日T18:28:10+01:00 License: CC By-SA Tags: openrc, gentoo, systemd et debian Score: 44 Dans [cette dépêche](https://linuxfr.org/news/pourquoi-les-zelateurs-et-detracteurs-de-systemd-ne-s-entendront-jamais) et aussi ailleurs il est souvent sous-entendu que les Gentooistes sont parmi les plus hostiles à systemd, pourtant on est quelques-uns sous cette distribution à avoir fait le grand saut et en être plutôt satisfait, d'autant plus que l'upstream, malgré son choix de conserver OpenRC par défaut, fait tout pour nous simplifier la vie. Le grand saut ? Enfin pas totalement, OpenRC et derrière lui le paquet sysvinit restent désespérément accrochés au profil de base. Ce qui fait que désinstallés, ils reviendront à la prochaine mise à jour et ce même si aucun autre paquet n'en dépend. # La solution # Une fois systemd installé, configuré comme init par défaut et que vous êtes satisfait de son fonctionnement vous pouvez commencer à envisager de vous passer d'OpenRC. Pour faire vite : ``` mkdir /etc/portage/profile echo '-*sys-apps/openrc'>> /etc/portage/profile/packages emerge --deselect openrc sysvinit ``` Et maintenant ? OpenRC est désélectionné du profil de base (et de toute sa descendance) et éventuellement aussi de votre fichier world, ça ne veut pas dire pour autant qu'il sera automatiquement désinstallé, si un `emerge --ask --depclean` ne vous propose pas sa suppression (et celles de sysvinit) vérifiez qu'un paquet installé ne dépend pas d'openrc ou sysvinit et bloque leur suppression, utilisez la commande `equery` du paquet gentoolkit pour cela : `equery depends openrc sysvinit ` Normalement, sur une Gentoo à jour avec des paquets pas trop exotiques, seul virtual/service-manager dépend d'openrc (et on s'en fout, il dépend alternativement de systemd et ne devrait donc pas bloquer la désinstallation) et seul openrc dépend de sysvinit (ça tombe bien...). # Les bugs # La politique de Gentoo est d'offrir un maximum de choix à l'utilisateur et ce n'est pas pour « troller » les « zélateurs » de systemd qu'OpenRC est conservé, mais car sa suppression pose encore quelques problèmes : ## /etc/init.d/functions.sh ## Ce fichier, installé par OpenRC et donc historiquement sensé être présent sur toutes les installations de Gentoo est utilisé hors de la phase d'init par pas-mal de programmes tiers mais spécifiques à Gentoo, pour faire, entre autres, des zolies sorties colorées en mode texte. Problème, si on vire OpenRC, y'a pû. D'où l'idée de fournir ces fonctions dans un autre paquet, c'est sys-apps/gentoo-functions qui s'y colle et il est normalement installé dans toutes les Gentoo à jour maintenant. Mais ce paquet fait les choses proprement, /etc/init.d/functions.sh ? Pas trop l'endroit pour ce genre de chose ! functions.sh se retrouve donc dans /lib/gentoo et les programmes dépendants de ce fichiers doivent donc être mis à jour. Vous pouvez suivre l'état d’avancement de cette tâche sur le [bugzilla](https://bugs.gentoo.org/show_bug.cgi?id=504116) de Gentoo et si vous utilisez des programmes pas encore patchés un petit `ln -s /lib/gentoo/functions.sh /etc/init.d` devrait suffire, en attendant. ## halt ## Le paquet sys-apps/systemd-sysv-utils fournit les commandes habituellement fournies par sysvinit (`telinit`, `runlevel`, `reboot`, `poweroff`...) maintenant que vous avez dégagés sysvinit, vous pouvez l'installer, ça vous évitera de vous retrouver comme une poule face à une cuillère au moment d'éteindre votre ordinateur. Sur une distribution Linux moderne, la commande `halt` va appeler `init 0` et c'est le RC script correspondant qui va décider de la version à appeler au final (`halt` ou `poweroff`) et donc généralement `poweroff` considéré par les mainteneurs comme correspondant plus au souhait de l'utilisateur. systemd, lui, s'offre le luxe d'avoir une unité différente pour chacune de ces commandes et la commande `halt` se comporte donc « correctement » (càd fait la même chose que la commande `halt -f` qui ne passe pas par l'init), ce qui a pour effet de ne pas éteindre « électriquement » l'ordinateur, c'est ici le rôle de la commande `poweroff`. Si vous avez l'habitude d'éteindre avec la commande `halt` et que vous n'arrivez pas à changer, pour `poweroff` (argh quatre caractères de plus) ou `halt -p` (argh trois caractères de plus) cela peut vous déranger. Bien sûr rien d'insurmontable ici, vous pouvez faire un alias dans votre shell favori, ou dire à systemd de ce comporter comme les autres inits : `ln -s /usr/lib64/systemd/system/systemd-poweroff.service /etc/systemd/system/systemd-halt.service`. # Pourquoi ce journal ? # Pour diffuser une astuce à jour, j'ai supprimé OpenRC hier soir et eu beaucoup de mal à trouver comment faire vu que les articles à ce sujet glanés sur Google datent de minimum un an, que leurs conseils à ce sujet sont complètement périmés et que la page man de portage n'est pas très claire sur la syntaxe de certains fichiers. Et non, je n'ai rien contre OpenRC, c'est un bon système d'init moderne avec suivi des processus, gestion des cgroups, plugins... Beaucoup plus proche de systemd ou upstart (et en mieux, face à ce dernier) que des init SysV traditionnels à la Debian < Jessie ou *BSD. Juste que j'aime pas avoir des programmes installés en doublon.

AltStyle によって変換されたページ (->オリジナル) /