GuiGui's Show

Rappel : si une instruction blacklist <nom_module> ajoutée dans /etc/modprobe.d/blacklist.conf (ou autre fichier .conf dans le même dossier) n'empêche pas le chargement d'un module dans le noyau Linux, on peut utiliser l'instruction install <nom_module> /bin/true. J'avais oublié.

Quelle différence ? Un module a un nom présentable (genre « uvcvideo ») et des noms techniques qui correspondent aux matériels pris en charge par le module (exemple : « usb:v0416pA91Addcdscdpic0Eisc01ip00in* » est la désignation technique d'un ensemble de caméras USB pris en charge par le module uvcvideo).

blacklist a pour effet d'inhiber les noms techniques. Donc, quand Linux détecte un matériel, il cherche dans les modules, il ne trouve pas de nom qui correspond au matériel, donc il ne charge pas le module (pourtant présent sur le système), donc le matériel n'est pas activé / pris en charge. En revanche, si le module est désigné par son nom présentable par un autre module ou par l'administrateur système (modprobe <nom_module>), alors il sera chargé.

install permet de faire exécuter une commande au lieu de charger un module. Tout le temps. Même si le module est appelé par son nom présentable par l'adminsys ou par un autre module.

Commande pour vérifier que modprobe a bien pris en compte une configuration déposée dans /etc/modprobe.d/ : modprobe --showconfig. C'est très verbeux, donc il faut y aller à coup de grep.

Il n'est pas forcément nécessaire de reconstruire l'initrd (avec update-initramfs -vuk <version_noyau>) après l'exclusion d'un module. C'est utile uniquement si l'initrd est susceptible de charger ledit module, donc plutôt sur les modules de matériels (pas vboxnetflt, le module "réseau pont" de VirtualBox, par exemple) nécessaires au boot (pas uvcvideo pour une caméra USB, par exemple).

Hier, via mon emploi, j'ai découvert anaconda, une distribution python toute intégrée plutôt axée sur le calcul scientifique / la fouille de masses de données / les réseaux de neurones, etc. Elle vient avec sa propre version de python (et, comme elle la met prem's dans le PATH, cette version l'emporte sur celle du système…), son propre gestionnaire de paquets et d'environnements (conda), et des tas d'autres choses. Attention si tu veux utiliser miniconda (implémentation plus légère de conda) à la place d'anaconda : certains logiciels font la différence et refusent de s'exécuter…

Je me demande : dépôts apt, dépôts yum, snap, flatpak, appimage, PEAR, CPAN, PyPI, npm, yarn, CTAN, forge Puppet, Docker Hub, etc., etc. Et conda qui fait le même boulot que pip… Quand est-ce qu'on a foiré ?

Bien sûr, je comprends : diversité, absence de centralisation critique (je vais nuancer ce point), réponse à des besoins différents notamment en termes de temporalité (cycle de vie), d'acceptation des paquets, et de fonctionnalités.

Mais, quand même quoi… Ça nous fait revenir au principe "télécharger tel logiciel depuis ici, tel autre logiciel depuis là"… Comme sous winwin où il faut se rendre sur le site web de chaque éditeur (même s'il existe des embryons de réponse comme Ninite).

Les éditeurs de logiciels sont implicitement invités à publier dans tous les types de dépôts compatibles avec leur techno (distribution GNU/Linux, langage, etc.). Je pense au xkcd 927 sur les standards… C'est juste intenable, peu d'éditeurs vont s'amuser à ça, et surtout pas les petits…

Quand avons-nous foiré ?

Je veux accéder à distance à l'interface graphique d'une machine Ubuntu 20.04. Protocole VNC, RDP, NX, peu importe. Facile, non ? Ha, j'ai deux critères qui rendent la chose compliquée :

• Je veux voir l'écran de connexion et pouvoir saisir mon identifiant et mon mot de passe afin d'effectuer une véritable ouverture de session, en déclenchant les mêmes sous-systèmes que si j'étais en présentiel ;
  
  
• Je veux réduire le plus possible mon impact sur la machine. Hors de question de désactiver Wayland dans GNOME ou de remplacer GNOME par xfce (ce que font la majorité des tutoriels). J'ai bien conscience que GNOME n'est pas le plus adapté pour de la prise en main à distance, mais ce besoin n'est pas guidé par des impératifs techniques et il n'est pas négociable.

Je ne sais pas ce qu'il en est aujourd'hui, mais, il y a plus de 10 ans, c'était très simple à faire sous winwin : ultraVNC et zout.

Avec Ubuntu 20.04, cela semble être impossible. J'ai essayé TightVNC, TigerVNC, x11vnc, vino, x2go, et xrdp.

TigerVNC s'en sort le moins mal. Ce tutoriel est fonctionnel. La session s'ouvre, tout est utilisable. Il ne faut pas verrouiller la session (attention au délai d'inactivité) sinon on ne pourra pas la déverrouiller, car il y a une sorte de boucle permanente qui fait échouer l'authentification, comme si quelqu'un appuyait sur la touche entrée en permanence. Il ne faut pas non plus que l'utilisateur ait ouvert sa session en présentiel, sinon il ne pourra pas la récupérer à distance. Cependant, ça ne répond pas à mon besoin : je suis directement connecté à ma session, sans passer par l'écran de connexion, ce que je ne veux pas.

Je pense que ça doit aussi fonctionner avec TightVNC. Je pense que TigerVNC a fonctionné, car le tutoriel indique un contenu plus sensé pour le fichier ~/.vnc/xstartup. Je pense qu'utiliser ce fichier avec TightVNC produira le même résultat.

Pour le futur, voici des contenus de ~/.vnc/xstartup qui fonctionnent sur un système Ubuntu 20.04 fraîchement installé (donc Wayland + GNOME + …) :

#!/bin/sh
exec /etc/vnc/xstartup
vncconfig -iconic &
dbus-launch --exit-with-session gnome-session &

ou :

unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
exec /usr/bin/gnome-session &

x11vnc ne prend pas en charge Wayland / gdm3 (tous les tutos désactivent Wayland dans GNOME depuis Ubuntu 18.xx et installent lightDM). Il n'arrivait pas à se raccorder à l'afficheur 1024 (qui était celui de Wayland), en tout cas. Je n'ai pas non plus trouvé la socket censée être crée par gdm3 via laquelle xrdp est censé récupérer le cookie d'authentification…

xdmcp ne fonctionne pas avec Wayland, a priori.

xrdp ne fonctionne pas. vinagre (client RDP, VNC, etc. de GNOME) crashe en s'y connectant ou affiche une boîte de dialogue de connexion (là où, normalement, on saisit son identifiant, son mdp de passe e tle type de session) totalement vide. Remmina (autre client VNC, RDP, etc.) tourne en boucle « essai 0/20, 1/20, 0/20 (non, pas d'erreur de frappe), etc. ». On aperçoit l'écran de connexion vide. Ce qui m'ennuie, c'est qu'on trouve des tutoriels xrdp pour Ubuntu 20.04 qui datent du 22 mai 2020. Leurs auteurs ne peuvent pas même pas tous mentir ni avoir tous hallucinés ! Mais, j'ai beau partir d'une Ubuntu 20.04 fraîchement installée et suivre rigoureusement les instructions, ça ne fonctionne pas.

vino ne fonctionne pas. Je n'ai pas réussi à l'activer sans passer par l'interface graphique (même en utilisant gsettings, gconftool, etc.). Si je le lance à la main via SSH, il affiche « Cannot open display: », voire « No protocole specified ».

x2go ne fonctionne pas, mais en plus, il réclame un algorithme assurant l'intégrité de la communication qui est déprécié (hmac-sha1). Rien de méchant (a priori, SHA-1 n'est pas dangereux quand il est utilisé dans un algorithme HMAC), mais c'est rigolo.

Mes collègues ont testé TeamViewer. C'est ce qui fonctionne le mieux, mais ça ne répond pas au besoin : on est directement connecté à la session, sans passer par l'écran de connexion. Comme TeamViewer est un logiciel privateur, je n'ai pas passé de temps dessus.

J'ai passé 4 h sur tout ça. Il m'a fallut 15 minutes pour accéder à la machine en présentiel malgré les restrictions et les procédures liées au Covid et en incluant le transport. 4 h = 240 m = le temps passé pour un accès distant pas fonctionnel = 16 accès en présentiel sans limite de durée. Parfois, il n'y a pas de réponse technique à un problème.

Résumé : si l'interface graphique d'Ubuntu se gèle pendant son installation dans une machine virtuelle KVM + virt-manager, soit tu la laisses se terminer en la surveillant avec iotop sur l'hôte (quand il n'y a plus d'écritures, l'installation est terminée), soit tu affectes, à la machine virtuelle, un modèle de CPU « kvm64 » ou un modèle supporté par ton CPU réel / physique.

L'installation d'Ubuntu dans une machine virtuelle KVM (+ interface graphique virt-manager, donc libvirt) sur mes ordinateurs a jamais trop fonctionné.

Avec la version 18.10, l'installeur se gelait lors de la saisie du nom d'utilisateur. Le pointeur de la souris bougeait, mais l'interface graphique ne réagissait plus.

Avec la version 20.04, l'installeur se gèle aux trois quarts de la copie des fichiers. Le pointeur de la souris bouge, mais l'interface graphique ne réagit plus. L'heure n'avance plus. Le diaporama des fonctionnalités essentielles d'Ubuntu (lecteur multimédia, communauté, accessibilité, etc.) ne se déroule pas. Sur l'hôte, un iotop montre que la machine virtuelle écrit toujours sur son disque dur. Si l'on attend la fin des écritures puis que l'on redémarre la machine virtuelle, le système Ubuntu installé fonctionne parfaitement. C'est donc uniquement un problème d'interface graphique gelé.

Dans virt-manager, je choisis bien « Ubuntu 18.04 LTS » (j'ai pas plus récent) comme système d'exploitation, car je sais que ça active / désactive des paramètres en douce et que ça conseille des valeurs plutôt sensées pour la quantité de RAM et autres. J'alloue deux cœurs CPU et 2 Go de RAM à la machine virtuelle. Allouer 4 Go de RAM (le reste demeure inchangé) change rien. J'utilise un disque dur VirtIO de 20 Go dynamique, rien de folichon.

Par le plus grand des hasards, j'ai trouvé une solution : il faut changer le modèle de CPU de la machine virtuelle. Par défaut, « copier la configuration du processeur de l'hôte » est coché dans la rubrique « Configuration » de l'item « Processeurs » dans les paramètres de la machine virtuelle. Mais, si l'architecture du CPU hôte n'est pas disponible, virt-manager va en choisir une autre lors du démarrage de la machine virtuelle. Sur mon ordinateur équipé d'un Intel Core i5-4200M (architecture Haswell), virt-manager choisit une architecture « Haswell-noTSX ». Sur mon ordinateur équipé d'un Intel Core i5-7300HQ (architecture Kaby Lake), virt-manager choisit une architecture « Skylake-client ». Dans les deux cas, l'interface graphique de l'installeur d'Ubuntu 20.04 se fige.

Dans les deux cas, choisir un modèle de CPU « kvm64 » ou « IvyBridge » (sur le i5-7300HQ) résout ce problème.