PROJET AUTOBLOG


Le blog de Seboss666

Site original : Le blog de Seboss666

⇐ retour index

Résoudre les problèmes de Microsoft Teams avec KDE sous Linux

mercredi 9 septembre 2020 à 18:00

Microsoft a mis à disposition il y a plusieurs mois déjà son client Teams pour les linuxiens. Il est très proche fonctionnellement de la version Windows, avec aussi peu de réglages que son homologue, et son statut de preview fait qu’il est souvent à la bourre sur les toutes dernières évolutions introduites dans le client. Il a aussi d’autres problèmes qui dépendent de l’environnement de bureau dans lequel vous tournez, et ça a été mon cas avec KDE.

KDE mon amour (je l’ai déjà faite, non ?)

KDE, c’est l’environnement qu’on dit sympa pour les nouveaux utilisateurs parce que proche de Windows. Alors les gens qui disent ça n’ont soit pas vu un Windows depuis longtemps, soit jamais utilisé KDE non plus. Parce que l’environnement qui repose sur le toolkit graphique Qt est un bordel sans nom tellement il est configurable dans tous les sens. J’en utilise moi-même probablement qu’un petit tiers des capacités, et ce nombre est probablement surestimé.

Je l’ai quand même sélectionné quand j’ai basculé mon laptop pro sous Linux, j’en avais parlé, parce que maintenant que la génération 5 avait maturé, je me suis dit que ça serait suffisamment stable et je voulais voir ce qu’ils en avaient fait après avoir apprécié la version 4. Globalement, c’est fluide, en fonction des thèmes c’est visuellement proche d’un Windows mais avec quelques spécificités parce que bon sinon ça serait pas KDE (pour ceux qui veulent vraiment mimer y’a l’incognito mode de Kali :D). C’est un environnement plaisant dont j’ai pu modifier les aspects que je voulais pour le rendre plus fluide pour mes besoins, et c’est finalement ce qu’on demande en priorité à son environnement de bureau.

Malgré tout, sur le Latitude 5470 j’ai quand même eu quelques galères. La consommation mémoire est déjà un peu élevée, genre 800Mo à froid, sans rien de chargé. Ensuite, en fonction des mises à jour j’ai déjà eu des soucis avec des freezes de l’écran de verrouillage. Comprenez que l’image est figée à l’écran, mais la souris bouge, et si on saisit le mot de passe au clavier, ça fonctionne, juste on ne le voit pas. Et ça, aussi bien sur le noyau d’origine à l’installation (4.19 LTS) que celui que j’ai sélectionné après, le 5.4 LTS. La solution était de rebasculer sur un TTY, et de revenir sur la session graphique pour qu’il reprenne le dessin. Bizarre autant qu’étrange, mais c’était limité au login screen.

J’ai quand même pris un peu de temps pour chercher un peu. Kwin, qui est le composant responsable du dessin de tout ça, et qu’on appelle à juste titre compositeur de fenêtres, dispose lui-même, à l’image du reste de l’environnement, de pas mal de réglages, sur les effets, et aussi sur un point important, le mode de rendu. Chez moi, et je n’ai aucune idée de pourquoi, le mode de rendu sélectionné était OpenGL 2, alors que le pilote et le GPU intégré supportent, au moins sous Linux, OpenGL 3.3+ depuis la génération Haswell, c’était en 2014. Vérification faite, depuis cet été Intel a validé OpenGL 4.6 pour tout ce qui est Broadwell+, ce qui est le cas de Skylake. Et dans les options proposées, je n’ai qu’un OpenGL 3.1. J’ai donc tenté le coup, c’est plus stable effectivement, mais rien de révolutionnaire sur la consommation CPU ou RAM. Moins de bug, c’est toujours ça.

$ glxinfo
(...)
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) HD Graphics 520 (SKL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.0.7
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
(...)

Ça n’empêche pas de temps en temps d’avoir un énorme message d’erreur sur fond noir me disant qu’il faut déverrouiller la session via la ligne de commande dans un TTY justement, ceci dit c’est assez rare pour ne pas poser plus de problème que ça.

Tu voulais pas nous parler de Teams ?

Alors pourquoi je m’attarde sur tout ça ? Déjà pour dire que l’environnement sur lequel il s’exécute a déjà quelques soucis graphiques avérés au moins par le passé. Ensuite parce qu’évidemment, avec une utilisation toujours plus poussée de Teams voire même une utilisation exclusive depuis quelques mois maintenant, je ne peux pas me permettre d’avoir un outil non fonctionnel. Certains éléments ne dépendent pas de moi, comme la téléphonie, dont la procédure de migration que j’ai pu lire me donne encore des migraines tellement elle est complexe par rapport aux tests du début qui fonctionnaient bien mais qui, selon Microsoft, posaient « des problèmes de sécurité ». Pour d’autres c’est lié à mon PC et lui seul, donc autant chercher à agir.

En dehors d’une consommation CPU et RAM démesurée qui est régulièrement pointée du doigt et qui ne semble pas la priorité de Microsoft (ajouter les fonds custom sur les visio et les grilles 3×3 « à la Zoom », c’est tellement plus important), le principal problème que j’ai rencontré est pratiquement impossible à capturer et visible uniquement par mes interlocuteurs : le partage d’écran « clignote », et on voit régulièrement des bouts de fonds d’écran par dessus les fenêtres, ce qui est particulièrement désagréable pour eux. Au début justement je pensais que c’était dû à l’OpenGL 2, mais le passage à OpenGL 3.1 n’a rien réglé. Je me suis dit que j’étais maudit, j’ai repensé au fait qu’Electron, qui est le framework applicatif utilisé pour développer Teams, repose sur Chromium, qui n’utilise pas Qt mais GTK comme toolkit. Possible, après tout Pierre-Marie qui va me faire payer une taxe à chaque fois que je le cite l’utilise sans souci avec Cinnamon, même si lui utilise la version non-officielle, donc la version d’Electron pourrait jouer.

Au passage dans les recherches, je vois que la consommation CPU peut être un peu réduite en désactivant l’accélération matérielle. Me demandez pas pourquoi mais c’est vrai, j’ai décoché l’accélération matérielle, redémarré l’application et ça va un peu mieux. Ça reste toujours Bagdad sur le Core i5 en conférence audio/vidéo, mais bon, le reste du temps, c’est à dire au « repos » il est beaucoup plus calme. Mais rien de mieux sur le partage d’écran qui clignote toujours. Et en continuant de chercher, je finis par retomber sur cette histoire de mode de rendu.

En effet, j’ai évoqué différentes versions d’OpenGL, mais il existe une dernière option pour Kwin qui s’appelle Xrender. Ce mode de rendu historique remonte à 2001 et déjà à l’époque permettait d’exploiter les capacités d’accélération des cartes graphiques pour s’occuper d’un ou plusieurs aspects de l’environnement de bureau. Il est toujours supporté sur les installations récentes qui reposent encore sur X.org, et c’est mon cas. Certains semblent avoir réussi à calmer les glitches du partage d’écran avec, et comme je n’avais aucune information sur le fait que ça pourrait faire mal au CPU et/ou à la RAM, j’ai tenté.

Eh ben devinez quoi, c’est la solution ! Donc pour avoir Teams + KDE + x  = partage d’écran, x = Xrender. J’étais content, j’allais pouvoir repartager mon écran facilement, c’est d’autant plus important en ces temps de télétravail continu.

Le retour de la vengeance des bugs bizarre de KDE

Et oui, tel un Jason Voorhees qu’on croit mort et qui revient toujours, un nouveau bug encore plus étrange est venu se mettre en travers de ma route : de manière très aléatoire, même si je pensais à un lien direct avec Teams, ce n’est plus l’écran de verrouillage qui freeze mais le bureau, carrément ! Je peux encore basculer entre les fenêtres avec Alt+Tab, mais plus question d’utiliser le menu KDE ou la barre des tâches. Et même certaines fenêtres finissent par un peu souffrir et freezer elles aussi. La solution trouvée sur un forum est de « tuer » plasmashell et de le relancer dans la foulée. Ce qui fonctionne, mais pour un temps plus ou moins limité avant de devoir recommencer.

Retour donc dans les méandres de la recherche sur le web, pour découvrir que cette fois-ci, c’est la combinaison Xrender + noyau 5.14 qui semble problématique, et que 4.19 permettra de retrouver sa stabilité. Au point où j’en étais j’ai tenté. Et au bout d’une semaine sans freeze avec moults partages d’écrans et sessions audio/vidéo Teams, force est de constater que le résultat est là. Le prix à payer est que les noyaux plus récents disposent d’améliorations de performances et/ou d’autonomie qui ne sont pas critiques non plus, surtout en ce moment où le laptop est constamment relié au secteur.

Un possible basculement sur XFCE ?

Par rapport à ce que j’utilise de KDE, franchement je me pose la question. la version 4.14 a amélioré son support GTK 3, qui est le toolkit sur lequel repose la majorité de mes applications en dehors de KeepassXC et VLC. Firefox, Thunderbird, LibreOffice, Sublime Text, Terminator, Teams, la liste n’est pas complète mais vous avez l’idée. Le problème, c’est que pouvoir basculer dessus demande tellement de changements sur le système que je me demande comment je vais procéder, la réinstallation étant probablement le mieux.

En attendant, j’ai retrouvé une stabilité nécessaire, ce qui une fois de plus nous montre bien que non, « Linux » c’est pas pour tout le monde, quelque soit la qualité du matériel.


PS : j’ai écrit cet article au mois de mai, il se trouve qu’entre temps, j’ai découvert une conséquence malencontreuse, à savoir que docker est cassé dans ce contexte, depuis la dernière mise à jour de Docker il y a une régression qui casse le dossier /var/run quand on tente un pull. Les détails et malheureusement la solution inapplicable dans mon cas sont à consulter dans cette issue. Une raison de plus pour passer sur container dockerless ?

Quelques astuces diverses, dix-neuvième

dimanche 6 septembre 2020 à 12:00

Ça faisait un bail en plus que je n’avais plus proposé de pot pourri de bidouilles directes et variées. C’est pas faute de bricoler, faut juste trouver le temps d’avoir des choses utiles/intéressantes à proposer 🙂

Désactiver le motd pourri d’Ubuntu Server

J’ai appris qu’une Ubuntu pouvait s’amuser à aller chercher des infos à l’extérieur, et surtout en transmettre, pour vous afficher un message de bienvenue à la connexion SSH. C’est sale, mais fort heureusement, il y a moyen de le désactiver, il faut modifier le fichier /etc/default/motd-news :

# Enable/disable the dynamic MOTD news service
# This is a useful way to provide dynamic, informative
# information pertinent to the users and administrators
# of the local system
ENABLED=0

On l’aura compris, c’est le ENABLED=0 qui fait le taf. (source)

youtube-dl, youtube, erreur 403

Alors que sur certaines vidéos je n’ai aucun problème avec youtube-dl, il arrive de temps en temps que je prenne une belle erreur 403. Non pas que la vidéo soit privée (il sait me l’afficher), mais c’est lié à un problème avec le cache interne de youtube-dl.

Pour le réinitialiser, il suffit de relancer le téléchargement avec l’option qui va bien :

$ youtube-dl -f 137+140 --rm-cache-dir https://www.youtube.com/watch?v=Og3JM8abqxI

Sinon, je vous conseille de chercher d’abord dans les issues déjà présentes sur le dépôt Github avant de vous lancer dans un gros débug méchant, la solution a de grandes chances d’avoir déjà été proposées.

Icones Paper, Manjaro : AUR !

J’ai eu des soucis avec des icônes qui ne s’affichaient plus correctement. Il s’avère que le paquet community « paper-icon-theme-git » n’a pas l’air très maintenu. Et il existe une version AUR avec exactement le même nom (ce dont je ne suis pas fan, c’est la fête aux conflits). Yay dispose cependant d’un flag ‘-a’ pour forcer l’installation du paquet AUR plutôt que le paquet community :

$ yay -Ss paper-icon-theme
aur/paper-icon-theme 1.5.0-2 (+39 0.00%) 
    Paper is an open source desktop theme and icon project by Sam Hewitt
aur/paper-icon-theme-git 805.8c7bf8d2-1 (+216 0.98%) 
    Paper is an icon theme for GTK based desktops and fits perfectly the paper-gtk-theme
community/paper-icon-theme-git 746.04115106-1 (40.3 MiB 57.4 MiB) 
    Paper is an icon theme for GTK based desktops and fits perfectly the paper-gtk-theme
 ~  blog  images 
$ yay -Sa paper-icon-theme-git
:: Checking for conflicts...
:: Checking for inner conflicts...
[Repo Make: 2]  ninja-1.10.0-1  meson-0.54.0-2
[Aur: 1]  paper-icon-theme-git-805.8c7bf8d2-1

Par la suite ça gueulera que le paquet local est plus récent que le paquet distant, mais c’est pas grave 😀

Docker, Alpine, telnet sont dans un bâteau…

J’avais besoin de faire un test rapide de connexion au SMTP Free depuis le container gitea, qui est basé sur alpine. Pour avoir à disposition la commande telnet qui n’es pas présente par défaut, il faut un petit paquet en plus :

/ # telnet smtp.free.fr 587
/bin/sh: telnet: not found
/ # apk add busybox-extras
fetch http://dl-cdn.alpinelinux.org/alpine/v3.11/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.11/community/x86_64/APKINDEX.tar.gz
(1/1) Installing busybox-extras (1.31.1-r9)
Executing busybox-extras-1.31.1-r9.post-install
Executing busybox-1.31.1-r9.trigger
OK: 59 MiB in 71 packages
/ # busybox-extras telnet smtp.free.fr 587
Connected to smtp.free.fr
220 smtp2-g21.free.fr ESMTP Postfix
QUIT
221 2.0.0 Bye
Connection closed by foreign host
/ #

Cloner un dépôt git sans son historique

Coup de main d’un collègue de boulot qui migre nos Wiki vers un cluster OpenShift. Lors du build des images, il clone la source de mediawiki depuis Github, et constate que ça prend beaucoup trop de temps, et à raison : le dossier fait 1 Go !!! Dans ce contexte, on a pas besoin de l’historique complet de git, on peut donc contourner ce problème avec l’option --depth de git :

git clone --depth 1 https://github.com/wikimedia/mediawiki -b REL1_34

Comme ça on récupère l’arborescence de la branche/tag/ref qu’on indique, sans tout l’historique git qui va avec et qui est inutile dans l’image Docker finale 😉

Thunderbird/Lightning : masquer les weekends

Je n’utilise pas de calendrier perso, mais au boulot oui, mais par contre, contrairement à Outlook, Lightning m’affiche les semaines complètes, ce qui ne m’intéresse pas puisque les weekend je ne travaille pas. Il est tout de même possible de masquer ces weekends inutiles, mais c’est pas intuitif. Il faut avoir le calendrier affiché, ouvrir le menu, Affichage, Calendar, Current view, Workweek days only. Et voilà 🙂

ArchLinux/Manjaro : paquets AUR au format Zstd

J’ai déjà parlé du format Zstd et de ses avantages et inconvénients. ArchLinux et par conséquent Manjaro passent petit à petit le format des paquets sur cet algo de compression. Mais au détour d’une lourde mise à jour de Skype qu’on installer par AUR, j’ai vu que c’était toujours l’efficace mais très lent xz qui était toujours aux commandes. Pour corriger ça, direction le fichier /etc/makepkg.conf, et modifier les deux paramètres :

#On change l'extension pour préférer le format
PKGEXT='.pkg.tar.zst'
#On change les options pour maximiser l'utilisation du processeur pour la compression
COMPRESSZST=(zstd -T0 -c -z -q -)

Convertir les fichiers .msg pour Thunderbird sous Linux

Microsoft et ses formats pourris binaires… Ayant été contraint d’utiliser Outlook pendant quelques années, j’ai gardé quelques fichiers en local au format .msg, et il est encore fréquent d’en trouver en pièce jointe de certains messages. On s’en doute, c’est un format maison que ne comprennent pas les autres clients mails, Thunderbird en tête.

Heureusement, il existe un petit utilitaire qui permet de convertir msg en eml, écrit en perl, un langage qui me résistera toujours je pense, mais qui permet semble-t-il pas mal de choses. Installable sur Arch/Manjaro via AUR, s’appelle aussi libemail-outlook-message-perl sous Debian/Ubuntu.

Afficher le détail de la connexion WiFi sous Linux

Incroyable, mais je n’ai trouvé aucune information sur comment afficher les détails techniques de la connexion Wifi en cours : bande de fréquence, norme, canal, alors que NetworkManager a quand même bien mûri, je n’ai que la puissance du signal. C’est chiant, frustrant surtout quand on teste la Livebox 5 flambante neuve de la petite soeur qui vient de passer à la fibre.

Le plus simple que j’ai trouvé, c’est wavemon, dispo sur Debian/Ubuntu et Arch/Manjaro, un utilitaire qui permet d’afficher en ligne de commande les détails que je souhaitais :

Le débit et la bande de fréquence me font dire que je suis bien en WiFi AC, confirmant les bons débits que j’expérimente sur la connexion 🙂

Terraform : identifier les variables non-utilisées

Quand on fait évoluer un code terraform, il est possible que certaines variables soient devenues inutiles. Dans ce cas, pour les identifier et faire le ménage dans les déclarations (dans votre fichier variables.tf le plus souvent), vous pouvez exploiter ce petit one-liner :

$ for name in $(grep variable variables.tf | cut -d '"' -f 2); do grep $name *.tf | grep -v variable >/dev/null || echo $name is unused; done
client is unused
$

Et ça suffira pour aujourd’hui, mais on n’est pas à l’abri de voir d’autres morceaux un peu plus costauds dans le futur (ou plus originaux 🙂 )

De Docker Swarm à Kubernetes avec k3s

mardi 25 août 2020 à 18:00

Après plusieurs mois d’attentes et de réflexion, je me suis enfin sorti les doigts du cul et j’ai changé le SSD du micro-serveur. Double espace pour monter de nouvelles VMs, pour lesquelles j’ai décidé non pas de rester sur Docker Swarm, mais de pleinement embrasser Kubernetes, via un projet très intéressant. Et comme souvent, voici le récit de ce voyage, parce qu’il fût semé d’embûches, de celles qu’on ne voit évidemment pas dans les tutos « hello world ».

Avertissement : ceci n’est pas un tuto complet, mais juste un gros retour d’expérience avec les réflexions qui vont avec.

Kubernetes… Le projet initié par Google et libéré depuis est sur toutes les lèvres des décideurs informatiques capturés tels des lapins par les phares des marketeux des agences Web qui pensent pouvoir se passer de qualité. Il est vrai que comparé à du Docker pur, et même à Swarm, il a une quantité d’avantages. Mais il a aussi ses inconvénients, et ça peut vite s’emballer.

Je suis toujours aussi critique sur la conteneurisation des applications, et surtout de son usage souvent mauvais, à l’image d’un php accessible qui permet trop facilement de faire de la merde. Mais pour le manipuler depuis plus d’un an et demi, force est de reconnaître que K8s (le nom abrégé de Kubernetes) me plaît beaucoup, bien que je lui trouve aussi des défauts. C’est selon moi, à date évidemment, la meilleure implémentation d’orchestration de conteneurs que l’on puisse trouver.

À l’image du cluster Swarm qui était surtout à la base un moyen d’entretenir mes compétences Docker, l’évolution du cluster est donc un moyen d’expérimenter et d’entretenir mes compétences sur et autour de Kubernetes.

Rancher, un acteur clé du monde de la conteneurisation

Rancher est une société qui développe beaucoup d’outils et de services centrés sur les containers. OS de supervision de cluster, orchestrateur docker, providers de stockage, et j’en passe. Leur expertise dans ce domaine n’est plus à faire, et beaucoup de leurs outils sont open source.

C’est un acteur de poids qui cherche en permanence de nouveaux moyens de mettre ces technos à la portée du plus grand nombre, des gros serveurs de data centers, aux petits auto hébergés comme moi qui voudraient aussi en profiter. Et dans cette catégorie, tous n’ont pas un serveur comme le mien, qui n’est déjà pas bien puissant, mais encore plus petit. D’ailleurs on verra que finalement j’utilise plusieurs projets liés venant de Rancher.

Je vous recommande de vous intéresser à leurs produits, certains sont intéressants, comme l’utilitaire qui permet de faire de la centralisation de la gestion de clusters, et ce quelque soit leur origine (maison, « cloud-provided », etc), parce que parfois, la ligne de commande c’est chiant même quand on adore 🙂 (Ils ont aussi un catalogue de formations et de certifications qui peut vous intéresser)

k3s, la réponse pour nano-pc

Un des reproches qu’on fait souvent à k8s est sa lourdeur, à savoir que les composants permettant de faire le boulot consomment beaucoup de ressources eux-mêmes. Chez Microsoft ils nous indiquaient un chiffre, certes un peu au doigt mouillé, d’une dizaine de pourcents pour les nœuds worker. Et les masters doivent aussi être si possible des brutes, surtout en mémoire vive (merci etcd). De manière général, on recommande que chaque machine du cluster dispose d’au moins 4 coeurs et de 8Go de RAM. C’est juste la capacité globale de mon micro-serveur actuellement, c’est un peu compliqué.

Et Rancher avait une cible : le Raspberry PI, un nano-pc disponibles aux alentours d’une trentaine euros, sur architecture ARM, d’abord conçu pour le monde de l’éducation, mais qui a bien dépassé ce cadre (on en doute même du succès auprès de cette cible primaire, tant les bidouilleurs se sont jetés dessus). Avec environ 1Go de RAM pour les PI 3, il est évident qu’il n’est pas possible en l’état de faire tourner la bête. Ils ont donc bossé, cherché comment réduire au maximum, parfois en allant jusqu’à remplacer des composants du control plane par d’autres plus légers.

k3s est né. Avec k3s vous pouvez monter un cluster Kubernetes à base de machines aussi peu puissantes que des Raspberry PI (3 et suivants), ce qui tombe bien puisque je déploie en général des machines virtuelles aux caractéristiques proches sur mon serveur. Je ne suis ni le premier ni le dernier à en parler, mais je vais m’inspirer du travail déjà produit, ne serait que pour valider que c’est réutilisable dans d’autres situations. Et surtout, j’ai des outils déjà déployés qu’il faut que je transfère, car je n’ai pas non plus envie de me paver les deux clusters en maintenance.

Spoiler, c’est pas des Pi 4 😛

Et comme indiqué au début, j’ai pas prévu de me faire mal avec des raspberry PI, j’ai juste un micro-serveur dont j’ai déjà parlé dans le passé.

Monter un cluster en mode « Infra as Code »

Parce que ça fait aussi partie des mes activités au boulot désormais, j’avais envie de déployer tout le cluster en mode Infrastructure-as-Code. Rien de révolutionnaire, j’ai visé l’utilisation de Terraform pour déployer mes machines, et d’Ansible pour faire leur configuration de base.

Je pensais faire la transition en douceur entre Docker Swarm et Kubernetes, mais quelques mésaventures avec le LVM de Proxmox VE m’ont poussé à carrément réinstaller celui-ci dans sa dernière version et donc refaire les machines de zéro. Ce fut également l’occasion de tout refaire à base de Debian 10 (dont j’aurais sûrement l’occasion de faire quelques remarques plus tard). Comme je suis toujours en télétravail prolongé chez ma mère, ça s’est fait lors d’un aller-retour rapide chez moi, car j’ai dû aller au boulot chercher ma Yubikey. J’ai juste pris le temps de réinstaller Proxmox VE sur un SSD flambant neuf deux fois plus gros que celui d’origine, et réinstaller le bastion à la main pour pouvoir faire tout le boulot à distance par la suite, j’avais déjà à disposition mes rôles de bases d’Ansible c’est donc allé très vite.

Déployer des machines avec Terraform suppose d’avoir à disposition un template de machine à déployer. Au final j’ai suivi la plupart des instructions partagées par Anthony (et sur lequel j’ai apporté une précision après avoir rencontré des soucis), après tout pourquoi réinventer la roue quand la solution existe déjà ? L’article propose l’installation bout-en-bout d’un kube complet via kubeadm, je me suis juste inspiré de la partie Terraform car je compte bien rester sur du k3s. Je suis parti sur une base d’un master/deux workers, et j’ai cette fois déployé des machines à 2vCPU et 2 Go de RAM. La seule contrariété finalement que j’ai rencontré c’est que j’étais à distance, et que l’interface de Proxmox VE n’est pas joignable de l’extérieur. Je suis donc passé par un transfert de port via SSH pour exposer en local le port 8006, et c’est localhost qui était désigné comme adresse dans la configuration du provider pour taper sur l’API de Proxmox. Et pour l’anecdote, l’instance Consul qui me sert à stocker mes tfstate était déployée sur Docker Swarm, du coup dans l’immédiat le tfstate reste en local sur mon poste.

$ ssh -L 8006:127.0.0.1:8006 root@pimousse.seboss666.ovh

Pour la partie configuration de base, comme je disais, j’ai déjà mes rôles Ansible, que j’ai remis à jour pour prendre en compte les changements effectués dans Debian 10. Certains paquets ont changé de nom ou ont disparu, d’autres n’étaient pas inclus de base dans l’image utilisée pour le template, et j’ai également eu à faire une ou deux modifications mineures dans l’environnement bash (via powerline.bash), en vue justement de pouvoir utiliser k3s par la suite.

Pour l’installation de k3s et la création du cluster lui-même, ça a été un peu plus compliqué. J’avais ressorti un article d’itwars et surtout le dépôt Github gardé après avoir lu l’article de Zwindler sur une telle opération sur des machines Scaleway. Cette première version n’avait que peu bougé, et surtout, j’ai perdu du temps en recopiant tout plutôt qu’en clonant, parce qu’au passage j’effectuais en direct mes propres changements dans les tâches, et ça avait abouti à un truc qui ne fonctionnait pas, en tout cas pas complètement. Avant de me rendre compte que le contenu du dépôt a été repris et amélioré de manière communautaire directement par Rancher. Avec toute la maintenance qui va avec, et bizarrement, après avoir fait les deux/trois modifications qui s’imposaient (entre autres désactivation de l’installation de Traefik pour faire la mienne, et la personnalisation du réseau, personnalisation de l’inventaire comme le préconise la doc), ça a fini par tomber en marche. Mais comptez deux après-midi de perte de temps quand même, si c’est pas un boulot de champion ça…

Comme je prévois d’utiliser quelques softs sans forcément pousser la configuration de ouf, j’ai cherché à installer Helm, que je viens d’évoquer, en tentant quelques tâches Ansible. Après plusieurs échecs minables parce que je ne suis parfois pas doué (ou pas concentré), j’ai finalement retrouvé la mémoire, à savoir qu’il existe une base de données plutôt fournie de rôles communautaires qui s’appelle Ansible Galaxy. J’ai donc fouillé dedans et il n’a pas fallu une minute pour que Helm soit installé. On ne regarde pas assez souvent ce que les gens ont contribué sur Galaxy, c’est une vraie mine d’or.

Convertir mes services, en mode feignant ?

À l’image de Gogs, qui était passé de « bare metal » à Docker Swarm, j’ai ensuite dû me pencher sur la conversion du fichier docker stack/compose en manifestes Kubernetes. On va le voir, de la même façon qu’on déclare un réseau, des services, et des volumes, il faut aussi déclarer plusieurs types d’objets pour faire le boulot, l’architecture globale n’ayant cette-fois-ci pas trop besoin de changer puisqu’on est déjà dans un contexte container.

Par contre, même les plus aguerris vous le dirons, la syntaxe des manifestes k8s, écrit le plus souvent en yaml, est pour le moins verbeuse. À tel point que si on définit une stack Swarm dans un fichier unique généralement, les bonnes pratiques consistent à créer un fichier par objet ou type d’objet pour Kubernetes. Oui, on en est là.

De cette complexité est né l’outil Kompose, un véritable must have selon moi qui permet de créer des manifestes K8s à partir de fichiers docker-compose. Ils sont rarement exploitables en l’état mais permettent de mâcher le boulot pour avoir la structure qui va bien, un peu à l’image d’ansible-galaxy qui peut vous générer la structure d’un module Ansible pour vous, dans l’optique d’une publication.

La question sensible des volumes persistants…

Toujours cette satanée persistance dont personne ne veut prendre en charge les problèmatiques. C’est faux en partie, Kubernetes embarque nativement pas mal de plugins pour des technos de stockage diverses et variées, notamment celles des fournisseurs de cloud qui proposent des services Kubernetes hébergés et gérés prêts à l’emploi, ces plugins permettant alors, depuis Kubernetes, de « commander » automatiquement des volumes de différents types.

K3s étant simplifié, par défaut tous ces plugins sautent et seul le hostpath et l’emptydir persistent. C’est embêtant parce que j’utilise déjà du NFS et il est possible de déclarer les PV NFS sans problème, mais pas les PVC (et on parle de plusieurs heures à essayer). Comme je l’indiquais dans le billet dédié à ce sujet maintenant les volumes NFS sont déclaré explicitement dans mes stacks, et non plus via un montage global sur chaque nœud. J’ai de toute façon prévu de m’en débarrasser, rappelez-vous, quand tout redémarre le temps de démarrage du NAS faisait que mes services tentaient de démarrer sans leur volume, avec un résultat parfois intéressant, mais il faut bien que je transfère les données. Une des solutions de contournement, serait d’utiliser le nfs-client-provisioner, pluggé sur mon partage global, qui crée des dossiers dynamiquement, dans lesquels je synchroniserai éventuellement les data le temps de faire cette migration. Mais au final, si le nfs-client-provisioner est là, il n’est que très peu utilisé.

Pour disposer de volumes persistants au sein même du cluster, j’ai décidé d’utiliser un autre projet de Rancher, Longhorn. J’ai eu par contre la désagréable surprise de voir sa lourdeur pour mon cluster, donc tant pis, on verra à l’usage. Un autre élément à prendre en compte, c’est que les volumes Longhorn ne supporte que le mode d’écriture RWO, pour Read-Write-Once, ce qui veut dire pas de replicas d’un même pod, et surtout pas de rolling update. Aussi, même en déclarant un volume aussi petit que 32Mi via PVC, il a créé un PV d’1Go, et le PVC mentionne aussi 1Go. Fort heureusement ce sont des volumes « dynamiques », à savoir qu’ils consomment réellement uniquement ce qu’on y met, mais si on vide manuellement un volume, le fichier correspondant sous-jacent sur l’OS n’est pas redimensionné, à l’image d’une image disque de machine virtuelle (ce qu’on avait pu voir à l’époque sur le format qcow2).

Pour contourner la limitation du RWO, il existe un provisioner « longhorn-nfs » disponible dans la dernière version qui va créer un volume unique d’une certaine taille (20Go par défaut), et l’exposer en NFS via une StorageClass, ce qui permet du coup de bénéficier des rolling updates. J’arrive toujours pas à me décider si je vais tout utiliser de cette manière, on verra à l’usage.

… et le réapprentissage de l’Ingress controller

Comme je l’ai évoqué un peu plus tôt, même si k3s est fourni avec Traefik, la version embarquée me plait moyennement car la 2.2 apporte beaucoup de fonctions sympatiques. Pour l’installation de cette version, là encore rien de transcendant, je me suis basé sur le travail de configuration « simple » mis à disposition par Djerfy, en l’adaptant légèrement pour mes besoins. J’avais commencé par Helm, mais j’avais un petit risque de passer à côté de la souplesse de personnaliser complètement l’outil. Je peux maintenant exposer les ports via la box, et faire tout le boulot qu’on demande d’un reverse-proxy. Et voilà, j’ai la base pour redéployer mes services désormais.

Traefik a l’air très intéressant, mais son implémentation dans Kubernetes amène pas mal de concepts que je dois réapprendre, par rapport à un Ingress Controller plus classique (Nginx étant le plus répandu, et j’ai pratiqué haproxy lors d’un projet client). Et sinon, là où ça restera compliqué pour la conversion, c’est que je crois que Kompose ne crée pas les fichiers d’Ingress, je n’ai donc aucune base de travail. Pas étonnant, aucun label particulier pour l’aider, son travail à partir du docker-compose se limite donc à l’exposition du service.  L’avantage c’est que tout est documenté, mais ça n’empêche pas que je doives apprendre toute la syntaxe de configuration, adapter les « tricks » que j’avais pu faire sur mon reverse-proxy Nginx, et surtout, trouver un moyen de coupler les IngressRoute propres à Kubernetes à des bouts de configuration plus statiques pour les quelques services qui ne seront pas dans le cluster, l’interface du NAS en premier lieu.

En tout cas pas mécontent d’avoir dans mes contacts proches un Djerfy qui est Traefik Ambassador pour m’épauler (bien qu’il soit parfois lui-même en train de déterrer des trucs), ça aide bien pendant cette mini-traversée du désert 🙂

La mise en pratique de la migration de service

Pour l’article je vais prendre l’exemple simple de Smokeping. Un container, deux volumes, un port, on peut difficilement faire plus accessible. Voici d’ailleurs la stack actuelle :

version: "3.2"

volumes:
  smokedata:
    driver_opts:
      type: nfs
      o: "addr=1.2.3.4,rw,nfsvers=3,nolock,soft,exec"
      device: ":/Docker/smokeping/data"
  smokeconfig:
    driver_opts:
      type: nfs
      o: "addr=1.2.3.4,rw,nfsvers=3,nolock,soft,exec"
      device: ":/Docker/smokeping/config"

networks:
  smokeping:
    driver: overlay

services:
  smokeping:
    image: linuxserver/smokeping:191068eb-ls64
    networks:
      - "smokeping"
    ports:
      - "20080:80"
    environment:
      - "PUID=1001"
      - "GUID=1001"
      - "TZ=Europe/Paris"
    volumes:
      - type: volume
        source: smokedata
        target: /data
        volume:
          nocopy: true
      - type: volume
        source: smokeconfig
        target: /config
        volume:
          nocopy: true
    deploy:
      replicas: 1
      restart_policy:
        condition: any

Passons maintenant à Kompose, pas besoin de détailler son installation, il suffit de suivre la doc (rtfm quoi). Pour son utilisation, il suffit de le lancer en lui indiquant le fichier compose et paf, ça fait des chocapic, ou presque. On constate qu’il a créé plusieurs fichiers yaml, dont on va détailler les éléments :

-rw-r--r-- 1 seboss666 seboss666  271 18.08.2020 19:55 smokeconfig-persistentvolumeclaim.yaml
-rw-r--r-- 1 seboss666 seboss666  268 18.08.2020 19:55 smokedata-persistentvolumeclaim.yaml
-rw-r--r-- 1 seboss666 seboss666 1,4K 10.08.2020 19:40 smokeping-deployment.yaml
-rw-r--r-- 1 seboss666 seboss666  294 10.08.2020 19:40 smokeping-networkpolicy.yaml
-rw-r--r-- 1 seboss666 seboss666  381 10.08.2020 19:40 smokeping-service.yaml

On a donc deux persistent volume claims, un deployment, un networkpolicy et un service. Il manque encore l’IngressRoute et un ou deux éléments annexes dont on va parler juste après.

Voyons un peu à quoi ressemblent ces fichiers, celui du deployment étant assez intéressant :

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: smokeping
  annotations:
    kompose.cmd: kompose convert -f ./smokeping_stack.yml
    kompose.version: 1.21.0 (992df58d8)
  creationTimestamp: null
  labels:
    io.kompose.service: smokeping
  name: smokeping
spec:
  replicas: 1
  selector:
    matchLabels:
      io.kompose.service: smokeping
  strategy:
    type: Recreate
  template:
    metadata:
      annotations:
        kompose.cmd: kompose convert -f ./smokeping_stack.yml
        kompose.version: 1.21.0 (992df58d8)
      creationTimestamp: null
      labels:
        io.kompose.network/smokeping: "true"
        io.kompose.service: smokeping
    spec:
      containers:
      - env:
        - name: GUID
          value: "1001"
        - name: PUID
          value: "1001"
        - name: TZ
          value: Europe/Paris
        image: linuxserver/smokeping:191068eb-ls64
        imagePullPolicy: ""
        name: smokeping
        ports:
        - containerPort: 80
        resources: {}
        volumeMounts:
        - mountPath: /data
          name: smokedata
        - mountPath: /config
          name: smokeconfig
      restartPolicy: Always
      serviceAccountName: ""
      volumes:
      - name: smokedata
        persistentVolumeClaim:
          claimName: smokedata
      - name: smokeconfig
        persistentVolumeClaim:
          claimName: smokeconfig
status: {}

Je l’avais dit que c’était particulièrement verbeux ? C’est un des reproches que je fais à la techno. Pareil pour les volumes, dans Swarm, vous déclarez un volume, vous l’utilisez, point barre. Ici il faut déclarer un volume (PersistentVolume), déclarer qu’on va l’utiliser (PersistentVolumeClaim), et ensuite l’attacher dans le Deployment en le déclarant. Et tout ça avec 10 fois plus de lignes. Et encore, grâce à Longhorn, on « simplifie » parce qu’il n’y a besoin que du VolumeClaim, le PV étant provisionné de manière dynamique derrière. Vient ensuite le service, sans lequel le port de l’application n’est pas réellement exposé, et même là, ça reste de la communication « interne », à moins de faire un service de type nodePort, qui réplique finalement le comportement de docker Swarm.

Car oui, en temps normal dans un cluster K8s, c’est l’Ingress Controller qui est chargé de faire le lien entre l’extérieur et les services. Et donc Kompose ne s’occupe absolument pas de cet aspect, il faut que je bosse le sujet. Pour Smokeping, je suis le seul à y accéder, on a donc une IngressRoute classique avec juste un auth basic http. Un modèle qui sera réutilisé pour la plupart des services je pense, comme c’était le cas sur mon Nginx. Ce setup a une particularité : il a besoin d’un secret, pour stocker le couple utilisateur:motdepassehashé, d’un Middleware qui est une ressource Custom créée par le déploiement de Traefik pour déclarer cette authentification, et dans l’IngressRoute lui-même, l’appel à ce Middleware. Certes je pourrais regrouper ces éléments dans le même fichier, mais pour l’exercice, ça fait donc trois fichiers de plus :

-rw-r--r-- 1 seboss666 seboss666  271 18.08.2020 19:55 smokeconfig-persistentvolumeclaim.yaml
-rw-r--r-- 1 seboss666 seboss666  268 18.08.2020 19:55 smokedata-persistentvolumeclaim.yaml
-rw-r--r-- 1 seboss666 seboss666 1,4K 10.08.2020 19:40 smokeping-deployment.yaml
-rw-r--r-- 1 seboss666 seboss666  351 18.08.2020 20:33 smokeping-ingressroute.yaml
-rw-r--r-- 1 seboss666 seboss666  211 18.08.2020 20:17 smokeping-middleware.yaml
-rw-r--r-- 1 seboss666 seboss666  294 10.08.2020 19:40 smokeping-networkpolicy.yaml
-rw-r--r-- 1 seboss666 seboss666  237 18.08.2020 20:16 smokeping-secret.yaml
-rw-r--r-- 1 seboss666 seboss666  381 10.08.2020 19:40 smokeping-service.yaml

Dans l’immédiat je n’ai pas appliqué la NetworkPolicy, parce que je dois l’adapter à mon installation d’abord, mais ça fait partie des bonnes pratiques que je recommande vivement d’appliquer en production pour isoler vos applications entre elles. J’ai d’autres priorités dans l’immédiat, et je radote je sais, mais c’est le stockage.

Revenons vite fait à l’Ingress pour mentioner un dernier morceau : pour la génération du mot de passe dans le secret, je recommande d’utiliser openssl qui a l’avantage, sous Linux, d’être déjà fourni par la plupart des distributions :

$ echo -e "user:$(openssl passwd -apr1 superpassword)\n"

Au passage vous pouvez aussi utiliser htpasswd du paquet httpd-tools/apache2-tools.

La migration du stockage des applications a été une autre aventure. J’évoquais la possible utilisation du nfs-client-provisioner, mais faire un premier déploiement avec un tel volume, procéder au rsync depuis le NAS sur le dossier créé, puis depuis le pod refaire un rsync sur le volume final, c’était beaucoup trop lourd. J’ai finalement trouvé quelque chose de pas super souple, mais beaucoup plus simple. On commence par créer le namespace et les pvc, et on crée un micro-déploiement qui monte ces deux volumes. Je me suis basé sur nginx parce que c’est léger, rapide, avec un compte root pour éviter les problèmes de permissions pendant les manipulations. Ensuite sur le master, j’ai également monté le partage Docker du NAS en NFS de manière dynamique, parce que ça n’a pas vocation à persister, et j’ai donc copié les données des volumes via « kubectl cp », sachant que derrière, il peut y avoir encore quelques manipulations à l’intérieur du pod nginx parce que les chemins sont souvent mal interprétés (ou alors je suis mauvais, je me suis fait une raison avec le temps). Une fois terminé, je supprime le déploiement temporaire pour lancer le vrai déploiement. Pour l’instant, je n’ai pas rencontré de difficulté. Ça restera la partie la plus pénible des autres migrations.

L’accès au cluster de l’extérieur, pas trivial

En effet, pour accéder à l’admin du cluster via kubectl, ça se fait via https sur le port 6443 du master. Je n’ai pas l’intention de l’exposer à l’extérieur dans l’immédiat, mais pour déployer des services dessus à distance ou procéder aux interventions de manière générale, il va falloir une solution. Exposer le control plane n’est jamais une bonne idée, après quelques tergiversations je vais faire ça avec une connexion SSH qui redirige le port 6443 du master vers le port 6443 local, et en plus je fais ça via le fichier ~/.ssh/config plutôt que via la ligne de commande, ce qui me permet de gagner du temps :

Host k3s-master
        LocalForward 6443 127.0.0.1:6443

Me reste à utiliser une copie du fichier kubeconfig en remplaçant l’ip du master par 127.0.0.1. On retrouve donc la même méthode que pour le déploiement via terraform vu plus haut, avec un poil de « sucre » en plus en vue d’une utilisation plus régulière.

Enfin pour la partie Ingress Controller, j’ai déjà indiqué comment je comptais procéder, j’expose les ports 80 et 443 du master via le NAT de la box. Le tout malheureusement en full IPv4 car toujours pas de vrai pare-feu ipv6 sur la Freebox (et ça sera bientôt aussi le cas sur Livebox, la fibre étant au programme pour septembre, Free n’étant pas encore à jour dans l’Oise malgré une promesse de disponibilité fin 2019).

Les différences avec le cluster swarm, la suite

La principale différence vient du fait que je n’ai qu’une seule machine qui joue le rôle de master/control plane, quand toutes les VMs du swarm étaient manager. Vu que tout est sur la même machine physique, j’ai envie de dire que ce n’est pas trop grave. Exit également portainer pour l’instant, même s’il supporte k8s désormais, et qui avait déjà sauté à l’occasion d’une petite corruption de configuration suite à une mauvaise manipulation lors d’une mise à jour. Je n’ai pas encore pour l’instant envisagé de réinstaller une forme de dashboard « global », en dehors de celui de Traefik et de Longhorn, je verrai dans le futur si j’en ressens le besoin.

Même si à l’époque j’aurais pu exposer le port d’admin de Docker Swarm pour me connecter de l’extérieur, la configuration est beaucoup plus rudimentaire, et sur ce point Kubernetes est bien plus facilitant. Attention, ce n’est pas nécessairement recommandé, d’ailleurs la conf par défaut de k3s crée un simple token et j’avoue que je tenterai bien d’ajouter une authentification via certificat client, ce qui est bien plus sécurisant.

J’ai pu constater la réactivité de k8s par rapport à des actions de mises à jour ou de relancement d’application, de mon point de vue c’est plus rapide sur kube quand on tue un pod pour qu’il réapparaisse, et surtout, j’ai désormais la possibilité de faire du rolling update (via longhorn-nfs), limitant très fortement les indisponibilités en cas de mise à jour. Un élément plutôt impactant à prendre en compte tiens d’ailleurs, qui a couru dès le début de l’installation du cluster : sans la fibre, pas mal de manipulations prennent du temps, le téléchargement de chaque binaire par exemple (via Ansible, k3s était téléchargé sur trois serveurs en même temps, idem pour Helm), ou chaque image docker de plusieurs centaines de Mo est pénalisant.

Les chantiers pour la suite

Tellement, déjà, en l’état j’ai redéployé un peu comme un gougnafier, et il manque des éléments qui seront importants surtout vu la capacité du cluster actuellement, à savoir les requests et limits pour éviter tout débordement d’une application. Voici l’état de la consommation avec Traefik, Longhorn, le nfs-client-provisioner, smokeping et gitea :

$ kubectl top nodes
NAME            CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
k3s-master      408m         20%    1156Mi          57%       
k3s-worker-01   364m         18%    640Mi           32%       
k3s-worker-02   399m         19%    797Mi           39%

L’idée va être de laisser tourner un peu sans ces limites, voir le comportement (via ctop ou kube-capacity par exemple), et appliquer les limites raisonnables en conséquence. Dans le même état d’esprit, des liveness/readiness ne seront pas de trop pour redémarrer automatiquement les services, pour l’instant c’est le désert.

J’ai déjà évoqué l’utilisation de Longhorn, reléguant le NFS aux seules sauvegardes. Justement je n’ai absolument pas parlé de sauvegardes, ça sera peut-être l’occasion de bosser sur Velero, histoire de sauvegarder le contenu des volumes car sauvegarder les VMs ne suffira peut-être pas à assurer le boulot. Il ne sera d’ailleurs pas nécessairement utile de sauvegarder toutes les machines, au moins le master, les nodes pouvant être réinstallés/ajoutés à l’envi via terraform/ansible.

À l’image du backup, il manque le déploiement d’une forme de monitoring. C’est d’autant plus nécessaire qu’on est justement dans un mode contraint de ressources, et comme je compte bien réinstaller Prometheus, pas dans le cluster lui-même mais sur un Raspberry Pi qui fera le travail dédié (avec celui de bastion certainement pour laisser toutes les ressources du serveur au cluster). Possible encore que je me base sur le travail de Stéphane Robert qui a eu l’amabilité de tout partager.

Enfin, il sera l’occasion de commencer à bosser sur de l’intégration continue, dans la continuation de ma migration vers gitea, ce sera donc drone qui sera potentiellement amené dans le futur à déployer les mises à jour de mes services kube sur le cluster.

En dehors du stockage, on parle donc d’automatiser les choses un maximum, en bon feignant qui se respecte, mais le feignant va quand même devoir pas mal se retrousser les manches pour arriver au résultat voulu 🙂

Par contre, cela va devoir se faire dans une enveloppe de ressources plutôt compliquée à gérer, car en l’état, voilà l’état du cluster :

On le voit, c’est serré, même sur le NAS qui participe au calcul du stockage. Il est temps que je rentre chez moi pour m’occuper de tout ça 🙂


PS : On a pu le voir ici, je n’ai pas eu à réinventer la roue, j’ai pu grandement bénéficier du travail déjà effectué et surtout partagé par d’autres, et je tiens encore à tous les remercier. Je n’ai pas eu l’occasion de beaucoup améliorer ou compléter leur travail, à part mes mésaventures avec Terraform sur le déploiement des VMs après la création du template que j’ai remonté, et des échanges en direct avec Djerfy par rapport aux bricoles autour de Traefik. Cet article est donc aussi un témoignage de mon amour pour leur travail. Un jour peut-être je pourrais moi-même en faire plus.

Firefox pour Android : le renouveau, imparfait une fois de plus

vendredi 21 août 2020 à 12:00

Oui, un nouvel article sur le blog depuis plus d’un mois ! Et pour parler de Firefox, notre navigateur mobile préféré, mais pas pour le bureau, pour Android ! Cela fait plus d’un an que Mozilla travaille à une refonte totale du butineur mobile, et pour l’utiliser moi-même depuis plusieurs mois, il est temps de vous en parler, car il commence sa carrière « stable ».

Un vieux code poussif, consommateur de RAM

C’est un fait, le Firefox pour Android actuel a toujours quelques avantages, avec notamment un support étendu des extensions, mais il n’est pas réputé pour ses performances, sa réactivité, ou sa légèreté. C’est un vrai gouffre à batterie qui en plus n’offre plus aucun confort dans un monde mobile sous perfusion Chromesque, monde poussant les développeurs JavaScript à toujours plus de paresse dans l’optimisation du poids de leurs horreurs.

De plus, le code du navigateur lui-même n’avait plus aucune marge de manœuvre pour corriger le tir, avec pour conséquence, une grosse stagnation dans le support des standards du web, même si on a pu le voir récemment avec WebRTC, il arrive parfois que Firefox traîne un peu (faire un VPN hébergé aux USA, c’est tellement plus urgent…), sans parler que la consommation de mémoire déclenchait facilement la mise en veille du navigateur, ce qui fait toujours tâche quand ça se passe à un simple switch d’application (genre on est sur son navigateur, on répond à un SMS, en revenant sur le navigateur il avait été déchargé car prenant trop de place…). Ce qui a poussé Mozilla à prendre la décision de repartir de zéro, gardant cette version stable en mode maintenance, ne corrigeant que le strict nécessaire en matière de sécurité et de stabilité. Stabilité étant probablement le maître mot, parce que j’ai utilisé la version preview, puis beta, et c’est pas toujours d’une fiabilité remarquable, leur statut n’est de toute façon pas prévu pour ça

Comme je l’ai dit, le support d’extensions de toute sorte fait la force de Firefox mobile, mais malheureusement, certaines étant d’abord conçues pour un ordinateur plus classique, l’ergonomie et parfois la stabilité ne sont pas trop au rendez-vous. Pour ma part j’ai le plus souvent limité mes usages mobiles à l’ajout d’un bloqueur de publicités, et là-dessus uBlock Origin ne déçoit pas. Ce support d’extensions était donc un passage obligé du petit nouveau, avec quelques surprises à la clé.

Here comes a new challenger, nouvelle architecure, chrome-like

Alors, il faut comprendre un peu comment fonctionne Android, et surtout certains de ses composants. Tout le monde connaît Chrome, le navigateur maison, avec Blink, son moteur de rendu. Mais il y a un « petit frère », car Android met à disposition des applications qui ont besoin d’afficher du contenu web une version allégée du moteur, sous le nom de WebView (logique), qui suit les numérotations de Chrome dans la pratique. Certains développeurs peu inspirés reposent d’ailleurs entièrement sur cette WebView pour faire leur « application », avec souvent un résultat peu amène pour l’intégration native d’Android. Je n’exclus pas qu’au final Chrome se base sur la WebView pour faire son taf de navigateur web, vous avez tout à fait le droit de me corriger si ce n’est pas le cas.

Et justement, le nouveau Firefox a choisi cette approche, en développant d’un côté le moteur, appelé GeckoView, qui se base en partie sur les technos développées pour Quantum, et destiné, à l’instar de WebView, à pouvoir être exploité dans des applications tierces. Et de l’autre, l’interface qui exploite GeckoView. Ces choix ont permis de prioriser certains développements, performance en tête, pendant que d’un autre côté, le développement de l’interface pouvait se faire à un rythme différent.

Des performances de ouf, des nouveautés bienvenues

C’est le constat le plus flagrant selon moi : malgré un Android un peu trop agressif sur la gestion d’applications et de la mémoire, le rechargement du navigateur et du ou des onglets courants est impressionnant, presque plus rapide que sur mon ordinateur portable à base de Core i5. C’est bien simple, je ne vois plus aucun problème à revenir dessus, le seul souci serait d’avoir un formulaire en cours de remplissage qui du coup serait dégommé, ce qui arrive très rarement (vu que j’utilise l’application mobile wordpress pour gérer les brouillons…).

J’ai pu également voir du mieux sur l’affichage de certains sites qui ne sont pourtant pas mobile-friendly, sans avoir besoin de recourir au mode lecture. Globalement le support des standards récents, et notamment ceux liés au mobile, fait un sacré bon en avant et c’est tant mieux.

Les temps de chargement des pages même les plus lourdes sont incomparables, je n’ai pas de chiffres à fournir en comparaison de Chrome Mobile, car comme sur « bureau » je le fuis comme la peste, mais comparé au vieux Firefox c’est vraiment le jour et la nuit. C’est bien simple, je n’ai pas lancé l’ancien Firefox depuis plusieurs mois, bien qu’il soit toujours installé. Et pour cause, quand il faut pratiquement 10 secondes à froid pour qu’il charge mon FreshRSS, ça devient éliminatoire.

Du côté des autres nouveautés pour l’instant, il parait qu’on a droit au Picture-in-picture, que je n’ai pas eu l’occasion de tester, et le support des PWA. D’un côté, j’aime l’idée de ne plus dépendre des stores fermés des dealers de plateforme mobiles que sont Android et iOS, d’un autre, le fait de tout faire en JavaScript me donne toujours des envies de vomir vu la lourdeur toujours plus grande des frameworks et des applications en question. Pour rappel, PWA veut dire Progressive Web App, en clair, un application web, qui passe par le navigateur en temps normal, mais qu’on « installe » comme une application mobile plus classique. Tous les inconvénients d’un fonctionnement JavaScript dans un navigateur, sans les avantages d’une application plus native avec ses performances et son optimisation à la plateforme cible. Je reproche déjà aux navigateurs web de bureau d’être devenus des usines à gaz, et on reproduit exactement les mêmes erreurs sur mobile, à l’heure ou l’autonomie stagne effroyablement. Ce fonctionnement est justment rendu possible grâce à la GeckoView.

Des groupes d’onglets quoi

Le reste est toujours d’actualité, protections contre le pistage, synchronisation Firefox Sync, navigation privée. Comme le déploiement n’est pas encore généralisé sur la version stable, je reste en beta, qui est un peu plus stable que la preview, mais je recommande quand même d’attendre qu’il soit plus naturellement poussé sur le canal stable pour l’utiliser au quotidien, sauf si évidemment l’aventure ne vous fait pas peur.

Des problèmes de jeunesse, extensions en tête

Et ce n’est pas pour rien : si le « phoenix » impressionne par ses performances, ce n’est pas le cas de son interface : c’est simple, c’est beaucoup trop limité par rapport au Firefox « original », beaucoup moins de menus à disposition, et même la disparition regrettable du about:config, avec le faux prétexte qu’un seul mauvais réglage peut faire définitivement planter le navigateur, alors que c’était dispo depuis des années et que les critiques n’étaient pas vraiment tournées vers ce genre de problème.

J’évoque les extensions, c’est un autre gros gros manque potentiel, chaque release du navigateur vient avec une liste certes grandissante, mais très limitée d’extensions validées pour fonctionner avec le nouveau moteur. On atteint même pas la dizaine actuellement, voici la liste :

Certaines sont reconnues, indispensables, d’autres sont plus ciblées voire élitistes dans le cadre de Noscript, mais avouez que ça fait sacrément chiche. Alors que j’envisage de remplacer mon KeepassKC local par Bitwarden (via Bitwarden_rs, sur mon cluster k3s, teasing), il n’y a pas d’extension disponible pour le navigateur afin de remplir les champs automatiquement. C’est plutôt frustrant, et je pense qu’il y avait plus urgent que « Search by Image » par exemple pour rendre de suite le navigateur attractif. Et non, Mozilla a déjà mon historique et mes trop nombreux marque-pages stocké chez lui via Firefox Sync (parce qu’on ne peut toujours pas installer de serveur Firefox Accounts en nodejs avec leur ersatz de documentation), pas question de stocker les identifiants chez eux. Et concernant le support futur des autres extensions, ben bon courage pour avoir des infos, manifestement personne ne sait, même pas les développeurs desdites extensions.

En dehors de ça, j’ai plusieurs réserves sur l’interface principale, avec une dominante « violet sur noir » qui ne m’inspire pas particulièrement. Ce n’est pas foncièrement moche, ou très mal organisé, mais voilà, y’a pas d’effet wouahouh, j’ai même du mal avec les options de nouvel onglet, avec un système de collections dont j’ai vraiment beaucoup de mal à saisir l’intérêt, quand ce qui m’intéresse au « rechargement » c’est d’avoir à minima la liste des onglets ouverts pour rapidement basculer dessus. Et là encore, sans extensions pour corriger ça…

Du violet partout…

La gestion des moteurs de recherche a aussi vu un gros retour en arrière en termes d’ergonomie. Bon certes j’utilise encore Qwant qui est facilement disponible, mais pour ceux qui ne sont pas « inclus », il faut manuellement ajouter l’url du champ de recherche. Alors que par le passé, sur un site présentant un champ de recherche, on pouvait rester appuyé sur le champ pour l’ajouter directement à la liste des moteurs de recherche disponibles. Certes, 95% des lambdas continueront d’utiliser Google, ce qui est désolant, mais avouez que ça ne semble pas compliqué de conserver un tel fonctionnement sur la nouvelle interface ?

Sérieux ? En 2020 ?

Et parmi les bugs que je rencontre encore, si le téléchargement de fichiers est fonctionnel (oui ça n’a pas toujours été le cas), l’ouverture automatique dans l’application idoine, ou l’affichage des applications candidates à l’ouverture d’un fichier, pose toujours problème. J’en viens à télécharger le fichier, et passer par l’explorateur de fichiers, soit celui fourni par Huawei, soit via l’interne de VLC quand il s’agit de podcasts, encore faut-il connaître le chemin. La peinture est encore vraiment fraîche.

C’est de la bombe pour les usages légers

On le voit donc, ce « Firefox nouveau » n’a probablement pas un goût de banane, mais ses performances font sourire et dans le bon sens du terme. Cela s’est cependant traduit par une finition très inégale, une couverture fonctionnelle très imparfaite, et il reste beaucoup de chemin à parcourir. C’est plutôt étrange de voir Mozilla rusher la sortie, quand bien même la stabilité est au rendez-vous pour le canal stable (c’est peu l’objectif de son nom), avec des conséquences plus importantes peut-être que pour la transition Quantum pour les versions de bureau, qui ont pu se faire de manière beaucoup plus graduelles.

Maintenant on peut comprendre Mozilla : l’ancienne version est un boulet qu’ils se traînent depuis un peu trop longtemps, et avec les récentes annonces sur les restrictions de personnel qui se profilent, il est essentiel de se débarrasser des versions obsolètes pour n’avoir que l’essentiel, un navigateur mobile paré pour le futur, un futur qu’il doit rattraper rapidement.

DroidCam : c’est cool, mais ça pourrait être bien mieux

samedi 13 juin 2020 à 11:01

Avec le confinement, il se trouve que je n’ai pas pu voir ma sœur depuis le nouvel an. Idem pour ma mère, qui de son côté s’est flingué le dos. Pour organiser une visioconférence de « consolation », j’ai redécouvert à quel point les webcam integrées dans les laptop sont affreuses. Et si on tentait le smartphone en guise de remplaçant ?

Il n’y a qu’à voir les rageux fans d’Apple gueuler sur la qualité médiocre (c’est même pire que ça : c’est moins bon qu’avant) de la cam intégrée aux derniers macbook pro qui coutent deux smic pour comprendre le problème : même chez Apple qui fait rarement dans le compromis, un composant pourtant peu onéreux par rapport au reste de la machine se retrouve être juste honteux. Apple, qui vante les qualités de son application Facetime, qui utilise une source vidéo affreuse, ça fait tâche dans le tableau.

Mais il ne faut pas croire que le problème est spécifique à la marque à la pomme, sans vouloir aller jusqu’à des webcam 4k60fps intégrées (on a pas souvent les réseaux pour envoyer une telle image, sans parler de la décoder à l’autre bout de la « ligne »), la différence flagrante de la qualité des webcams comparées aux évolutions constantes année après année des capteurs de smartphone me rend perplexe, à croire qu’on ne peut pas capitaliser sur ces évolutions. Je suis de près l’apparition des modèles de laptop qui sortent avec une plateforme Ryzen 4000 (partie CPU de Ryzen 3000 et GPU Vega en 7nm), et le constat est le même à chaque fois : quelque soit la cible de l’appareil, la webcam est au maximum en 720p 30fps, ce qui est désormais limite en 2020. Je demande pas la lune, mais avoir au moins du fullHD avec en bonus, sur les hauts de gamme, du 60FPS, me parait loin d’être impossible ni trop cher en 2020, non ?

Arrive quand même l’horreur : la webcam du PC de ma mère. Un modèle 17″ Asus à base de Core i3 4000m d’il y a donc six ans, fourni avec Windows 8.1, dont la webcam est sobrement intitulée « USB Camera ». Le mieux que j’ai pu apprendre est qu’elle est fabriquée par Realtek, mais je n’ai rien trouvé d’autre comme référence ni pilote, car c’est celui de Microsoft qui est utilisé, et qui date de… 2006. Vous la sentez la merde ?

Voilà, et encore, c’est une image fixe, en 640×480 donc, la résolution que j’utilisais pour mon écran en 2002. Et je vous épargne la photo le soir avec 4 fois moins de lumière. Dans la pratique en vidéo si on arrive à obtenir 10 images par seconde c’est tout le bout du monde. Alors imaginez quand un Skype vous étire ça sur l’intégralité de votre écran 16 pouces (celui de ma sœur), ça donne quelque chose de tellement immonde que je renonce à vous l’afficher, pour préserver votre santé mentale et visuelle.

Le smartphone en remplacement ?

J’avais déjà eu cette idée dans le passé, sans avoir été au bout de la démarche en cherchant et en testant, mais avec l’idée de la comparaison naturelle entre la qualité d’image des smartphones même d’entrée de gamme (en gros, pour le prix d’une Logitech StreamCam, on a un smartphone 4G complet avec un écran de 6″…),  cette expérimentation a naturellement refait surface. Entre le débit d’image, la résolution, la gestion de la lumière bien plus optimale, les possibilités éventuelles sur le zoom et j’en passe, bref, c’est une aventure qui se tente.

J’ai donc eu l’occasion de faire le test sur deux ordiphones différents : mon Huawei P20 Lite dont il est prévu que je vous donne des nouvelles pour ses deux ans, et le Huawei Y5 version 2019. Mais tout smartphone Android un peu récent fera l’affaire, pour peu qu’il ait un peu de patate quand même, parce qu’on a vu la différence entre les deux déjà, on va le voir.

DroidCam, l’application de référence

Malgré son nom, DroidCam est techniquement disponible sur Android et iOS, et les applications PC Windows ET Linux sont également de la partie. Oui oui, aussi pour Linux, mais j’ai eu l’occasion de faire le test d’abord sur Windows, comme ça pas de jaloux.

Pour rappel, l’application fonctionne en deux parties : la partie installée sur mobile capture l’image du téléphone et crée un « serveur vidéo », qu’on peut ensuite soit consulter directement dans un navigateur (on a que l’image), soit contacter via l’appli client sur PC qui va créer une webcam virtuelle pour y transmettre le flux récupéré sur le téléphone. On peut aussi capturer le son du smartphone, mais pour avoir tenté de faire un comparatif, la qualité du micro ambiant du smartphone n’est pas forcément plus agréable que le micro intégré du laptop, et on est toujours à des années lumière des micro-casques donc… Deux modes de fonctionnement sont possibles, le premier simple via le wifi/réseau local, le deuxième via USB qui demande un peu plus de manipulations que je n’ai pas testé.

Premier constat : les devs sont bons, les applications aussi bien mobiles que PC sont simples et très fonctionnelles. Par contre, leur site web c’est de la merde en barre : aucun menu de navigation, ni de moteur de recherche, on doit sauter de page en page pour tenter de trouver nos informations (j’en ai surtout eu besoin pour la partie Linux, j’y reviendrai). On se croirait revenu sur un de mes premiers essais de site web en 1998 en cours d’informatique en seconde.

Deuxième constat : l’application mobile existe en deux versions, une « gratuite » et une payante. Je mets gratuite entre guillemets parce qu’on sait que désormais, l’affichage de publicité n’a rien d’innocent et désintéressé dans l’univers Google et du Web en général. Pire, et là c’est vraiment gonflé de leur part, la résolution du flux vidéo du smartphone est limitée, dans la version gratuite, à 640×480. On garde les autres avantages comme la gestion de la lumière et la fluidité relative à la puissance du smartphone, mais merde, on est plus en 2002. La version payante propose en plus une tétrachiée d’options supplémentaires qui permettent de contrôler plusieurs éléments du smartphone directement depuis l’appli, comme le zoom, l’autofocus, la balance des blancs, l’allumage du flash, etc, mais ils auraient au moins pu amener le 720p par défaut quoi !

Usage sous Windows, avec le laptop de ma mère

Comme je l’ai évoqué, l’application est simple, efficace, s’installe sans pourrir votre PC. On aimerait voir des freeware comme ça plus respectueux de nos machines en 2020 ! L’interface est simple, on lance, on saisit l’adresse IP du téléphone (et le port si on s’est amusé à le changer), et une seconde après on a l’image qui doit s’afficher, sauf si on a laissé le téléphone sur la table évidemment 😀 Mais il suffit dès lors de cadrer l’image qu’on souhaite partager. En fonction des téléphones et de l’usage final, on peut poser le « capteur » contre l’écran , ça masquera une petite partie de celui-ci mais si on n’a rien à manipuler en paralèlle, ça peut le faire.

Ensuite sous Skype, on sélectionne la webcam « DroidCam » et on constate le résultat :

On a la même résolution, mais on est à des années lumière en termes de qualité et de fluidité. Ma sœur me l’a fait remarquer quand on s’est amusé à faire un comparatif entre les deux 😀 En clair, solution validée, même pour ma maman quand elle se retrouvera autonome pour ça.

Usage sous Linux, laptop pro et perso (c’est pareil)

Pareil parce que les deux sont sous Manjaro, la seule différence c’est que sur le PC du boulot je suis resté en noyau 4.19, alors que sur mon perso c’est du noyau 5.4. Oui, que du LTS. Je vous expliquerai probablement pourquoi sur le laptop du boulot j’ai du revenir au 4.19 en 2020, c’est marrant aussi. Enfin dans les deux cas, j’ai pu faire fonctionner le système sans trop de problèmes, mais évidemment, ça n’a pas été aussi fluide que sous Windows. L’installation aucun souci, via AUR c’est d’une simplicité absolue. Mais la suite…

D’abord, le module noyau v4l2loopback-dc qui permet de créer la webcam virtuelle n’est pas chargé par défaut, il faut manuellement « modprober » ce qui se fait en mode administrateur. On a vu plus souple, le point positif c’est que le module est fourni via DKMS il est donc mis à jour proprement en cas d’update noyau. Et c’est là en fait que j’ai découvert la limitation de la résolution, le module crée par défaut une webcam en 640×480, même si le flux est en résolution supérieure. Il faut aller modifier, toujours en mode administrateur, le fichier de configuration du module pour changer les paramètres (pensez à créer le fichier chez vous s’il n’existe pas déjà) :

#cat /etc/modprobe.d/v4l2loopback-dc.conf
options v4l2loopback_dc width=960 height=720

Ensuite décharger le module (modprobe -r), et le recharger, parce qu’évidemment les paramètres ne sont pas pris à chaud. Et attention, si on met une sortie qui n’est pas dans le même format que la source, l’image est déformée. Dans mon cas j’ai quand même poussé jusqu’à 720p, ça étire un peu le flux d’origine mais comme je garde le ratio, c’est moins dégueulasse. On constate quand même une légère augmentation du bruit visible en faible luminosité.

Ensuite, la gestion du son est encore à part et vu les manipulations de la documentation j’ai abandonné direct. On parle de module Alsa, qui reste semble-t-il toujours aux commandes alors qu’on manipule pulseaudio au quotidien, donc j’ai du mal à comprendre comment ça fonctionne. 2020, et la gestion du son sous Linux a encore 20 ans de retard sur Windows, et on se demande pourquoi Linux ne s’impose toujours pas…

Enfin, une fois la partie « bas niveau » en place, on peut lancer l’application qui a exactement la même tête que sous Windows, donc adresse IP à saisir, et ensuite, on sélectionne la caméra dans Skype/Teams. La bonne surprise cependant, c’est que là où dans l’application Windows on me dit que les contrôles sont réservés à la version DroidCamX (donc payante), sous Linux je peux contrôler le zoom, l’autofocus et le flash  😀 Sur le laptop boulot on a donc une webcam avec la même résolution, mais l’ouverture est plus large, l’image plus fine et lumineuse et la fluidité un peu meilleure. Sur le laptop perso, la webcam fait déjà du 720p avec une gestion relativement propre de la lumière, la fluidité n’est pas parfaite mais ça peut suffire pour des petites visio-conférences. Y’a quand même du bruit donc faut pas être exigeant sur la qualité de l’image.

L’alternative qui n’a pas fonctionné pour moi

J’ai cherché à voir si une option permettant une meilleure qualité sans devoir balancer sa carte bancaire à Google existait. Il semblerait, elle s’appelle Iriun Webcam, dont le fonctionnement est siimilaire à savoir appli mobile+appli desktop. Il permet d’exploiter la 4K si le téléphone le permet, mais de mon côté, j’ai rencontré beaucoup de problèmes. Déjà, l’installation avec le paquet AUR déconne parce que le md5 de l’archive téléchargée par le script d’installation n’est pas le même. Les développeurs n’ont pas spécialement envie de penser qu’on est sur PC et qu’on a besoin de contrôles de versions, donc j’ai tenté l’installation à la main (on clone le dépot AUR, on modifie le PKGBUILD, et makepkg -si dans la foulée). Mais une fois v4l2loobpack manuellement chargé au niveau du noyau (module officiel pour faire une webcam virtuelle) et le logiciel lancé, ben écran noir sur la capture, pourtant le smartphone indique bien que la connexion est établie. Aussi, le flux semble coupé très très régulièrement, du coup, au bout d’un quart d’heure de manipulations sans résultat, j’ai lâché l’affaire.

Je ne l’ai pas testé non plus sous Windows, si vous avez expérimenté avec hésitez pas à partager, à ce moment de l’histoire j’ai décidé que j’avais autre chose à faire que de débugger des applis qui ne me donnent déjà pas beaucoup d’infos sur leur fonctionnement.

Ça manque cruellement d’open-source

Car oui, tous les éléments testés ici ne sont pas open-source. Et c’est un vrai problème des deux côtés, aussi bien au niveau du smartphone où l’on dépend du store fermé de Google ou d’Apple, que du côté du PC où l’on ne peut pas forcément s’assurer que l’application n’en fait pas un peu trop, pour un logiciel qui a accès à la webcam. Sur Linux, comme ça dépend d’un module noyau (modifié dans le cas de DroidCam), c’est un peu tendu pour s’assurer du suivi du bon support lors des montées de version (même si globalement l’infrastructure v4l2 est assez stable).

Il y a bien eu une application appelée SmartCam, dont les fichiers sont toujours disponibles, mais elle n’a pas été mise à jour depuis 2013 voire plus vieux encore pour certains, et autant dire que ça commence à faire vraiment trop dans le monde de l’informatique.

En attendant, et vu la qualité du résultat même avec une résolution décevante avec la version gratuite, vous avez une solution de rechange pour les webcam intégrées aux laptop, ou pour votre PC de bureau. Y’a juste un truc que j’ai pas vraiment abordé : le fait qu’il faut poser le téléphone dans une position pas trop désavantageuse pour votre visage 😀

PS : c’est évident pour certains, mais je rappelle que si vous êtes moche comme moi à la base, une bonne webcam ou un bon smartphone n’y changera rien. On verra juste mieux à quel point vous êtes moche 😀