PROJET AUTOBLOG


Le blog de Seboss666

Site original : Le blog de Seboss666

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Powerline.bash, le retour !

lundi 30 mars 2020 à 18:30

Pour ceux qui lisent le blog depuis un moment, vous savez que j’utilise Powerline pour décorer mon shell, ainsi que celui de mes machines virtuelles à la maison. Dans l’ensemble j’en suis très content, mais le projet qui m’avait lancé sur la personnalisation de mon shell, powerline.bash, est revenu sous mes yeux, et oui, j’ai craqué, j’ai décidé de basculer dessus. Voyons donc pourquoi.

Si vous avez relu mon billet d’origine, l’installation de Powerline, notamment pour avoir un statut git assez visuel est assez lourde, en gros, en plus des paquets powerline et powerline-fonts, il me faut en plus un paquet pip et une configuration maison plutôt chargée à pousser. Autant dire que le contenu du playbook ansible pour déployer tout ça est assez fat, mais bon, c’est pas non plus la mort.

Powerline a ses propres problèmes, et certains m’avaient d’ailleurs été relevés. Le principal, c’est la latence. Il arrive parfois qu’il mette un temps visible à rendre la main, ouvrir un nouveau shell, et le problème empire quand votre CPU est déjà particulièrement chargé comme c’est souvent le cas dernièrement sur mon laptop du boulot. J’ai en plus eu des soucis à l’époque de la bascule Python 3.7 > 3.8 sous Manjaro, ce qui m’avait poussé à devoir tout refaire (en gros j’avais plus de prompt le temps que je corrige). Je n’ai jamais réussi non plus à l’avoir sur deux lignes, et plusieurs tentatives pour personnaliser plus avant se sont toujours soldées par des échecs. Je ne pense pas être plus bête qu’un autre, mais là quand même… Il y a certainement d’autres contrariétés qui ne me reviennent pas en tête là tout de suite, mais voilà, j’ai été donc frustré plus d’une fois avec son utilisation.

« Ha, ha, ha, ha, staying alive… »

Et au gré de mes flux RSS, Etienne Bersac, le développeur de powerline.bash, a fait un journal sur linuxfr pour discuter des mises à jour. C’était l’occasion de découvrir que contrairement à ce que je pensais, je n’avais pas activé les notifications sur le dépôt, ça m’apprendra à être plus vigilant. Donc, depuis le temps, il y a eu pas mal de petits raffinements et de corrections, de nouveaux segments, cvia des contributions externes, et celui sur git a bien évolué. C’est beaucoup plus intéressant désormais.

J’ai donc retesté le bousin, l’installation et la configuration sont toujours aussi simples, ça tient à un git clone et l’ajout de deux lignes dans le bash_aliases. Dans mon cas évidemment, ça demande aussi de virer/commenter les lignes nécessaires à Powerline.

Je vais la faire courte, j’ai tout de suite été conquis. Certes, les détails concernant le statut du dépôt git sont un peu moins fournies (j’avais le nombre de fichiers avec leur statut quand le dépôt n’était pas à jour, ainsi que le nombre de commits à pousser), mais c’est désormais plus parlant, les couleurs sont mieux choisies, on voit qu’on a des trucs à pousser, il y a le support de plus d’icônes. Et c’est finalement largement suffisant pour éviter de lancer des commandes sans avoir bien vérifié le statut du dépôt auparavant, ça économise pas mal de commandes git status, toujours bon à prendre.

Dossier, venv python, statut git, tout ce qu’il faut quoi 🙂

Quant à la vitesse de chargement et de réponse, c’est évidemment le jour et la nuit. J’ai donc entrepris de rebasculer mon profil dessus sur tous mes serveurs. l’occasion de reprendre mes playbooks pour les remettre au gout du jour, cela faisait un moment qu’ils n’avaient pas été lancés, et j’ai également découvert plusieurs manques ou faiblesses (genre le playbook qui supprime la ligne pour charger acme.sh sur le bastion…). Petite particularité par rapport à la doc, j’ai opté pour un déploiement du dépôt dans /opt, comme ça il n’est cloné qu’une fois pour tous les utilisateurs que je modifie. Le module git d’ansible se chargera des pull la prochaine fois, et voilà.

Et je pense que je vais envisager de le pousser aussi sur mes serveurs « publics », comme celui que j’utilise pour ce blog (qui va vraiment avoir besoin qu’on lui refasse une beauté, ça devient intenable).

En tout cas, c’est du beau boulot, encore merci à Etienne, ainsi qu’aux contributeurs qui sont mentionnés dans le README. Je ne dis pas que j’en ferai partie dans un futur proche, mais j’avais déjà participé à l’époque en terme de remontée de bug sur Ubuntu 16.04 – eh oui, tant qu’il est supporté, on doit le prendre en compte, même s’il sent vraiment la naphtaline maintenant-, et j’ai le segment Kubernetes à tester sur le pc du boulot (pas encore à la maison, je pense qu’en termes de priorité la VM du blog est prioritaire). Donc y’a peut⁻être encore des trucs à remonter ou contribuer 🙂

Youtube-dl sur un NAS Synology, c’est possible !

mercredi 25 mars 2020 à 18:30

En partant chez ma mère pour mieux vivre le confinement prolongé qui se profile devant nous, j’ai embarqué son NAS trop longtemps en maintenance avec un disque dur neuf pour le remettre en service. Et parmi ce que j’ai prévu de lui faire faire, il y a la même chose que chez moi, sauf que le Download Station embarqué ne sait plus récupérer les vidéos sur YouTube. Qu’à cela ne tienne il y a une solution !

Le NAS

Le NAS est un ancien Synology DS215j. C’est un modèle pouvant accueillir deux disques, avec un processeur Armada 375 plus que poussif, et un système d’exploitation basé sur Linux mais avec une interface web de gestion qui est d’une lenteur hallucinante. Je l’avais acheté après la mort de mon serveur perso monté avec des composants d’occasion qui est en fait toujours en vie, seulement un des disques était mort, mais je n’avais pas eu suffisamment confiance pour relancer cette machine dont la consommation ne me convenait plus.

Ce NAS était équipé de deux disques de 2To, configurés en SHR, parce que Synology ne pose pas la question à l’installation et utilise son RAID maison. Déjà ça m’avait gonflé, et à l’époque je n’avais pas plus creusé que ça et je l’avais laissé en l’état. Mais avec la saturation des disques, et leur âge grandissant couplé au bruit plus important de leur mécanique, je l’avais embarqué pour lui refaire une santé et une upgrade de disque.

Cette période de maintenance s’est donc terminée avec la remise en service sur un unique disque dur de 4To, le seul en état de marche à disposition, qui était destiné à mon propre NAS, qui pourra attendre pendant mon absence.

DSM 6 sur ce NAS, c’est l’enfer

Et c’est peu de le dire. Si visuellement peu de choses ont changé dans l’interface du système d’exploitation de Synology, la gourmandise en performance est là : la moindre action fait grimper le CPU dans les tours, un simple listing des trois pauvres dossiers partagés créés suffit, c’est bien simple, chaque action prend plusieurs secondes pour voir son résultat. Et ce n’est pas que côté serveur, le navigateur en prend aussi pour son grade, je ne sais pas avec quels pieds de lépreux l’interface a été codée, mais c’est une catastrophe.

Malgré tout, les fonctionnalités sont là, à part que le Download Station ne sait plus récupérer les vidéos YouTube. Apparemment il ne repose pas sur youtube-dl comme Takeasy sur Asustor (mais qui n’a pas été mis à jour depuis plus d’un mois, ce qui fait que certains sites auparavant supportés ne fonctionnent plus).

« Oh mais y’a Python 3 ! »

La lumière au bout du tunnel 🙂 En effet, dans le gestionnaire de paquets de DSM, il est possible d’installer Python 3, en pus de Python 2 qui est déjà installé. L’installation via l’interface est simple, comme n’importe quel paquet. Reste ensuite à activer SSH et les home directory, pour ensuite se connecter à son compte en ligne de commande.

Youtube-dl s’installe via pip. Mais par défaut, pip ne semble pas disponible. Arf. Mais c’est partiellement faux. De toute façon, pour tout projet qui nécessite d’utiliser pip, il est recommandé de passer par un virtualenv, un environnement virtuel adapté à un projet en particulier. Et ça tombe bien, python 3 permet d’en créer d’une manière particulièrement simple :

seboss666@Mariz_NAS:~$ python3 -m venv yt

Et hop, quelques longues secondes après, on a un dossier yt qui contient notre virtualenv :

seboss666@Mariz_NAS:~/yt$ ll
total 36
drwxr-xr-x 7 seboss666 users 4096 Mar 22 22:53 .
drwxr-xr-x 5 seboss666 users 4096 Mar 22 22:51 ..
drwxr-xr-x 2 seboss666 users 4096 Mar 22 22:53 bin
drwxr-xr-x 4 seboss666 users 4096 Mar 22 22:53 etc
drwxr-xr-x 2 seboss666 users 4096 Mar 22 22:51 include
drwxr-xr-x 3 seboss666 users 4096 Mar 22 22:51 lib
-rw-r--r-- 1 seboss666 users   61 Mar 22 22:52 pip-selfcheck.json
-rw-r--r-- 1 seboss666 users   75 Mar 22 22:51 pyvenv.cfg
drwxr-xr-x 4 seboss666 users 4096 Mar 22 22:53 share

Ensuite on l’active comme n’importe quel venv :

seboss666@Mariz_NAS:~/yt$ source bin/activate
(yt) seboss666@Mariz_NAS:~$ pip --version
pip 7.1.2 from /volume1/homes/seboss666/yt/lib/python3.5/site-packages (python 3.5)

Notez le petit (yt) qui permet de visualiser qu’on est dans un virtualenv python. Et surprise, pip est bien présent ! Par contre il sent fort la napthaline. On va donc en profiter pour le mettre à jour, et tenter d’installer youtube-dl :

(yt) seboss666@Mariz_NAS:~$ pip install --upgrade pip
Collecting pip
  Downloading https://files.pythonhosted.org/packages/54/0c/d01aa759fdc501a58f431eb594a17495f15b88da142ce14b5845662c13f3/pip-20.0.2-py2.py3-none-any.whl (1.4MB)
    100% |████████████████████████████████| 1.4MB 45kB/s 
Installing collected packages: pip
  Found existing installation: pip 7.1.2
    Uninstalling pip-7.1.2:
      Successfully uninstalled pip-7.1.2
Successfully installed pip-20.0.2
(yt) seboss666@Mariz_NAS:~$ pip install youtube-dl
Collecting youtube-dl
  Downloading youtube_dl-2020.3.8-py2.py3-none-any.whl (1.8 MB)
     |████████████████████████████████| 1.8 MB 3.7 MB/s 
Installing collected packages: youtube-dl
Successfully installed youtube-dl-2020.3.8

Eh ben, ça semble parfait ! Il faut juste s’assurer d’un dernier détail. En effet, sur plusieurs sites pratiquant le HLS ou le DASH, la vidéo et l’audio sont séparés en flux distincts, et youtube-dl a l’habitude d’utiliser ffmpeg pour recoller les morceaux :

(yt) seboss666@Mariz_NAS:~/yt$ which ffmpeg
/bin/ffmpeg

Cool 🙂 Je ne sais par contre pas si c’est installé de base sur le NAS, ou si ça provient d’un autre paquet comme le serveur multimédia, installé afin de fournir du DLNA au lecteur Bluray, et qui a une option de transcodage vidéo, d’où le recours potentiel à ffmpeg. Dans le doute, vous pourrez vérifier par vous-même, moi c’est déjà installé et configuré je touche plus à rien.

Le problème de l’indexation multimédia

Eh oui, si ce n’est pas une astuce en vrac, c’est pas juste pour pouvoir vous faire l’historique du NAS et une critique de ses performances, vous le voyez à la simplicité ça aurait pu tenir en un seul paragraphe ou presque. Quand on télécharge un fichier avec Download Station, ou qu’on pousse un fichier par SMB (le partage réseau), le fichier est presque immédiatement disponible pour le lecteur Bluray. Malheureusement, pour une raison que j’ignore, ce n’est pas le cas pour les vidéos récupérées par youtube-dl, et de mémoire les vidéos poussées via rsync/ssh non plus.

Il faut donc, dans ce cas, forcer une réindexation qui va prendre plus ou moins de temps en fonction de la taille de la bibliothèque, et qui se déclenche avec la commande suivante :

(yt) seboss666@Mariz_NAS:/volume1/Download$ sudo synoindex -R all

Bon après, l’interface du lecteur Bluray LG est une honte et le rafraîchissement provoque une erreur qui demande de retourner à l’accueil pour refaire tout le chemin vers le dossier voulu. Mais ça fonctionne 🙂

Les NAS maison me manquent (et les vrais lecteurs multimedia aussi)

J’avoue, entre la puissance famélique, l’indexation sélective, et l’interface pénible du bluray, je regrette vraiment OpenMediaVault, minidlna et Kodi. Disposer d’un lecteur Bluray disposant d’une interface aussi propre que Kodi est illusoire, ne serait-ce que parce que ce dernier ne dispose pas de toutes les technologies pour lire des bluray pourris par des DRM qui imposent de payer des licences à sept chiffres, dont on devrait pourtant avoir les clés pour des raisons d’interopérabilité. VLC s’y est cassé les dents, notamment grâce aux pressions de Sony qui se gave en licences, et rien n’a bougé depuis (il faut dire que le marché stagne, voire baisse quand la VOD en streaming explose, donc sont pas pressés de filer les clés de la bagnole). Mon raspberry Pi sous LibreELEC me donne toujours entière satisfaction, sauf pour le plugin YouTube qui m’a poussé à me tourner vers d’autres solutions.

Quant à Openmediavault, le projet est toujours maintenu et toujours aussi intéressant, le problème, c’est que le matériel pour le faire tourner sera forcément plus volumineux, consommateur de ressources, et potentiellement beaucoup plus cher. Même si en termes de consommation on sera proche avec mon microserveur, atteindre un tarif de 180€ pour la base sans les disques relève du miracle, puisque c’est juste le prix de la carte mère avec CPU soudé sans la RAM, sans le boitier, sans l’alimentation, autant d’éléments inclus pour le prix. Avec un CPU x86 toutefois, on aurait accès à beaucoup plus de puissance et d’usages, ce que j’avais fini par faire à l’époque sur mon NAS maison, avec l’ajout d’une machine virtuelle en plus du reste.La problématique du CPU dans les NAS a parfaitement été analysée par David, je vous laisse lire son dossier si vous souhaitez creuser le sujet. Minidlna fonctionne quelque soit la méthode pour ajouter un fichier, puisque c’est le noyau et uniquement lui qui prévenait de l’arrivée d’un fichier, peu importe qu’il soit déposé via une application, un partage réseau, un transfert SSH.

Bref, comme trop souvent avec l’informatique, la liberté et le confort ont un prix, et pour les usages de ma mère, la liberté et la performance ne sont pas des priorités absolues, donc on va s’en contenter. Par contre, son lecteur Bluray/home cinema donne quelques signes de fatigue, et ça coûte cher à remplacer, j’espère que ça tiendra encore quelques années.

Brider les services vidéo sur le Web, une très mauvaise idée !

dimanche 22 mars 2020 à 10:30

J’ai été particulièrement énervé par tous les discours alarmistes sur la possible « saturation d’Internet », et des demandes débiles de nos dirigeants auprès de certains acteurs de se brider volontairement pour l’éviter. D’une part parce que c’est faux, et d’autre part parce que nos dirigeant profitent une fois de plus d’un contexte exceptionnel pour mettre à mal notre outil préféré. Et ça commence à être pénible.

Ça n’aura échappé à personne : impossible de dépasser le 480p sur YouTube, Netflix « n’existe plus » en 4K, ni même voire en FullHD (les résolutions sont certainement toujours là, mais vu la gueule de la compression ça fait pas envie). Et là, dernière connerie demandée par Thierry Breton, le report du lancement de Disney+, service de streaming vidéo à la demande par abonnement du géant de la production audiovisuelle américain, lancement qui se faire le 24 mars et qui est repoussé de deux semaines.

C’est une énorme connerie pour plusieurs raisons. Déjà, parce que comme l’a déjà très bien écrit Stéphane Bortzmeyer (cet homme écrit décidément très peu d’âneries comparé à moi, donc vous gênez pas pour le lire), la raison invoquée est le risque de saturation des réseaux, ce qui est complètement faux actuellement, même si certains symptômes pourront le laisser penser. Comme un nez qui coule ou une légère toux, en ces temps de paranoïa liée au virus, ne signifie pas qu’on l’a chopé, les autres maladies n’ont pas décidé de prendre des vacances. Une sensation de « lenteur » du réseau à un niveau local pourra se produire sans que le réseau dans sa globalité soit souffrant. D’ailleurs dire LE réseau n’a pas de sens, Internet est un assemblage de nombreux réseaux, actuellement entre 40 000 et 50 000, là où ça peut pêcher par moments c’est dans les points d’interconnexion de ces réseaux. Mais d’une part chaque réseau à plusieurs interconnexions, et d’autre part, augmenter ces capacités est beaucoup plus facile que ne le croient nos dirigeants. Vraiment, lisez le billet de Stéphane, vous comprendrez.

À la limite, si vraiment on pense que les services de vidéo à la demande font chier, ce ne sont pas juste Netflix et YouTube qu’il faut coincer, mais tout le monde, et à tous les niveaux. Normalement dans un monde neutre, si on veut dire qu’un type de service n’est pas prioritaire, ce sont tous les acteurs qui doivent être touchés, pour la bonne et simple raison qu’il ne faut pas créer de distorsion de concurrence. Hors, aucune annonce auprès de Dailymotion, de Whatsapp, TikTok, Snap, des services de replays des chaînes françaises (qui passent tous par le Web), et en gros, tous les services de communications ou de diffusion vidéo (Twitch, Mixer, etc). Tous ces acteurs sont soit non essentiels (et encore une fous de plus, quand ont voit les initiatives des profs qui partagent ou commencent à créer du contenu pour les gamins, on comprend qu’il y a un problème à demander à brider youtube), soit peuvent brider la qualité de leur service sans que ça ne change fondamentalement la fonction. Un live snap en SD, vu l’intérêt de base du service, ça tuera personne, et ça n’empêche pas de comprendre ce qui se dit. Idem pour les outils de visio-conférence, de toute façon vu la qualité déplorable des webcams y compris dans les laptops les plus chers du marché, je pense qu’on peut dire qu’il n’est pas grave que la définition soit un peu réduite pour la vidéo. C’est un peu plus chiant sur les partages d’écran par contre parce que la compression tue la lisibilité des textes.

Pareil, on n’y pense pas mais avec les live Facebook qui se multiplient de la part des artistes qui ne peuvent plus se produire sur scène mais qui veulent quand même partager (comme quoi il n’est pas seulement question d’argent et de droit d’auteur, n’est-ce pas Pascal Rogard ?), vu le trafic drainé par Facebook, ça fait un peu mal au cul en théorie aussi, alors pourquoi ne pas avoir également demandé à Marky Mark de brider son service ? Enfin bref, vous avez l’idée, pour moi si on doit brider un type de service, c’est pour tout le monde pareil, quel que soit la taille de l’acteur, aucune discrimination. C’est ce qu’on appelle la neutralité.

Retarder Disney+ est aussi une énorme connerie à l’heure du confinement des gamins chez eux. Alors que certains parents commencent déjà à affûter leur pelle, et que Disney a consciencieusement retiré ses contenus, dont tous ceux qu’il possède grâce aux multiples rachats de ces dernières années : Marvel, Fox, etc, de tous les services concurrents, Netflix en tête (ce qui a provoqué d’ailleurs la fin des productions conjointes au niveau des séries TV, dommage pour Punisher et Daredevil), des services concurrents, ceux qui attendent de pied ferme de pouvoir enfin redonner des doses de Reine des neiges aux gamins pendant qu’ils essaient de bosser vont devoir ronger leur frein. Ou alors relancer le téléchargement illégal via Bittorrent, ce qui est donc l’inverse de l’objectif visé par ces services qui est que d’une manière ou d’une autre, les utilisateurs paient pour visionner le contenu, ce que ce cher Pascal souhaite.

Aucun journaliste ne s’est interrogé sur la possibilité que ce ne soit que du pur lobbying, ou du pur protectionnisme économique, voire pire du copinage à la limite du conflit d’intérêt. Tous les services touchés par la demande de bridage sont américains et pas européens, et on sait à quel point les dirigeants européens sont embêtés de voir ces entreprises respecter les règles d’optimisation fiscales qu’ils ont votés pendant plus de vingt ans. Et on sait aussi que les opérateurs européens aimeraient grandement faire payer aussi les services américains pour que le trafic passe par eux, en mode « Canalsat » où les abonnés paient pour le visionnage, mais de l’autre côté les chaînes paient aussi pour être diffusées. Le problème c’est que ce n’est pas le même type de réseau, mais passons. Personne ne semble aussi s’émouvoir du passé de Thierry Breton, qui a passé quelques années à la tête d’un certain France Télécom, qui s’est depuis définitivement renommé en Orange. Je n’ai aucun doute sur la compétence du personnage au poste qu’il occupe actuellement et qui lui a permis de lancer ses demandes, vu le profil c’est d’ailleurs probablement un très bon choix. Mais ça me gène un peu quand même du coup dans ce contexte, un ancien copain chez l’opérateur aurait pu lui souffler l’idée que ça ne m’étonnerait pas plus que ça.

Surtout que techniquement, les opérateurs savent eux-même brider les flux, ils savent même brider des protocoles depuis très longtemps. Qui n’a pas été surpris à une époque, chez Free en non-dégroupé, de ne plus pouvoir faire de bittorrent ou d’e-mule du jour au lendemain ? protocoles qui se sont mis à refonctionner soit via vpn ou via des fonctions d’obfuscation des protocoles ? Une fois de plus, c’est économique. À l’image du confinement physique que personne ne semble vouloir respecter en région parisienne, haut lieu du nombrilisme à la française qui commence à provoquer des sueurs dans les hôpitaux proches des régions où ces connards ont fui, pourquoi on ne « confinerait pas » les connexions internet dans leur ensemble ? Il n’est absolument pas nécessaire actuellement que chaque foyer dispose d’un Gigabit voire plus de bande passante, la moitié voire le tiers suffit amplement pour plusieurs personnes en parallèle. Mais si les opérateurs le font d’eux-même, les utilisateurs vont se tourner alors massivement vers les services clients, qui ne savent déjà pas gérer les demandes habituelles des utilisateurs, et donc coûter cher.

En termes d’images c’est génial aussi, « regardez, on peut faire plier les ricains », qui évidemment n’ont pas envie de passer pour les méchants dans le contexte, même si c’est entièrement faux. Après tout ils mettent le service à disposition, ils ne forcent pas les utilisateurs à s’en servir, ni l’appareil ou le réseau depuis lequel ils y accèdent. Le problème, c’est que les opérateurs ne veulent pas non plus qu’on sache à quel point ils sont mauvais en gestion de réseau, enfin surtout en gestion d’interconnexion. Ce sont tous des services américains, et les interconnexions avec les USA passent par l’Atlantique, ce qui coûte cher. Historiquement les opérateurs français paient le minimum syndical, et on a un historique de problèmes notamment le soir qui est long comme le bras. Moi-même pendant plus d’un an et demi, j’ai expérimenté ces problèmes d’accès à des services Hors France chez Free. Quand la signature et le déploiement d’une interconnexion directe du réseau de Free avec Google a eu lieu, le lien qui était utilisé pour tous les services US semble-t-il a eu du mieux, et là où Twitter avait pas mal de problèmes le soir, miracle tout allait mieux. Mais ça n’allait pas toujours parfaitement, et Netflix avait régulièrement des soucis le soir, ça pixellisait pas mal, le lecteur réduisant la qualité pour tenter d’éviter la coupure dans la lecture. Mais ça ne suffisait pas. Quand Netflix a annoncé des signatures de partenariat avec plusieurs opérateurs Français, dont Free, comme c’est surprenant les problèmes ont disparu. C’est con ça fait plus d’un an j’ai pas les graphes smokeping pour vous montrer les niveaux monstrueux de pertes de paquets que j’avais à l’époque.

L’augmentation de la latence de Netflix sur ma connexion ADSL hier, alors que je suis pas chez moi. Et c’est normal, y’a pas de problème.

Les opérateurs savent donc s’adapter sans avoir besoin de demander à un encostardé de gesticuler pour demander aux américains de se brider d’eux-même. Le problème n’est donc pas technique, et ces gesticulations sont à la limite de la honte. Mais de la même façon qu’on voit bien que la gestion de la crise sanitaire a toujours eu une priorité économique (pas très surprenant de la part d’un président ancien banquier et copains des grands patrons), ces gesticulations ne sont qu’un indice de plus qui montre bien à quel point la population est bien le dernier cadet des soucis que veulent traiter les dirigeants.

En attendant, les utilisateurs, eux, vont subir ces décisions, et s’adapter, très souvent de la pire des manières, comme c’est le cas actuellement pour les gamins et profs qui s’organisent autour de Youtube, whatsapp, Google apps plutôt que les ENT de leurs écoles qui ne fonctionnent déjà pas bien en temps normal, et plus du tout en cette période de crise. Et il faudra que nos dirigeants expliquent à Disney pourquoi il n’engrange pas les utilisateurs qu’il pensait avoir après les avoir affamé, quand ils auront repris goût au téléchargement illégal, goût qui avait pris des années pour leur faire en partie oublier, car ce sera le seul moyen de retrouver à la fois les titre et la qualité qu’on s’attend à avoir, y compris en temps de crise ?

Bref ça me gonfle. En attendant, je vais remettre en place le NAS chez ma maman, elle aussi n’a pas tous ses contenus et y’a du taf. Bon dimanche, bon courage, et RESTEZ CHEZ VOUS BORDEL !!!

Zstd : c’est quoi ce format de compression ?

vendredi 6 mars 2020 à 18:30

Certains diront que je débarque, mais le fait est qu’il y a eu une récente actualité autour de ce format relativement récent de compression sans perte, car il commence à être utilisé par défaut sur Arch Linux, et par conséquent, Manjaro. On s’est déjà intéressé à la compression sous plusieurs formes par le passé, ça fait longtemps, voyons pourquoi ce format gagne en popularité.

C’est en effet suite à une note de mise à jour du 20 janvier dernier que j’ai entendu réellement parler de zstd :

Upstream notice

:

 

Arch updated their default compression to zstd 18. We adopted to the same standard. More and more packages will have the zst extension from now on.

Bon, OK, un nouveau format que je ne connaissais pas. C’est pas si choquant, ma veille n’est pas spécialement orientée sur ces sujets, donc on va un peu s’intéresser à ce nouveau venu qui semble avoir beaucoup de succès auprès de différentes distributions Linux comme on va le voir.

Here comes a new challenger

Zstandard, parce que c’est son vrai nom, est tout récent dans l’univers des algorithmes de compression sans perte, car il n’est développé que depuis 2015. Enfin presque, car un de ses principes fondamentaux remonte à… 1977. L’utilisation d’un dictionnaire n’est donc pas nouveau pour la compression, il est même d’ailleurs au cœur du format LZMA qui a gagné en popularité grâce à un outil que vous devez connaître, 7-zip. Autant dire qu’on connaît bien les maths derrière ça; pas moi personnellement hein, je suis pas encore assez bon, mais y’a des furieux qui maîtrisent bien le sujet, et si vous voulez en savoir plus, Wikipedia est votre ami.

Mais alors quel est l’attrait de ce petit nouveau pas si nouveau d’un point de vue conceptuel ? Pourquoi est-il soutenu par Facebook ? Eh bien, sa grande promesse n’est pas lié à sa performance de compression, mais sa rapidité. Rapidité à la fois pour la compression mais aussi la décompression, peut-être encore plus pour la décompression d’ailleurs, car ses performances varient peu quelque soit le niveau de compression choisi au départ. Quant au niveau de compression, il est censé être comparable à gzip, tout en étant plus rapide que celui-ci.

Et si on testait nous-même ?

Pour vérifier ça, j’ai fait deux petits tests afin de mesurer cette promesse. Le premier est sur un unique fichier WAV, qui ne devrait pas donner de très bons résultats sur le taux de compression, l’autre sur un dossier composite à savoir une copie du blog, donc un mix entre fichiers textes et images, plus intéressant. Ce dossier sera « concaténé » dans un fichier tar, même si zstd est capable d’itérer sur un dossier en mode récursif, ce que ne savent pas nécessairement faire ses cousins.

Pour chaque test, j’ai fait une copie distincte du fichier d’origine pour limiter les impacts du cache noyau par une lecture répétée. J’utilise time pour mesurer le temps de traitement, compression et décompression, et les paramètres par défaut pour chaque commande. Voilà, les conditions sont posées, passons aux résultats.

Fichier WAV

$ time gzip Alestorm\ -\ Sunset\ On\ The\ Golden\ Age.gz.wav 

real	0m22,659s
user	0m22,001s
sys	0m0,566s
$ time xz Alestorm\ -\ Sunset\ On\ The\ Golden\ Age.xz.wav 

real	1m16,755s
user	4m40,875s
sys	0m1,676s
$ time zstd Alestorm\ -\ Sunset\ On\ The\ Golden\ Age.zst.wav 
Alestorm - Sunset On The Golden Age.zst.wav : 97.96%   (514968188 => 504438852 bytes, Alestorm - Sunset On The Golden Age.zst.wav.zst) 

real	0m1,096s
user	0m1,169s
sys	0m0,550s

Eh bien le moins qu’on puisse dire, c’est que c’est effectivement très rapide. Et quid de la taille ?

$ l
total 2,8G
drwxr-xr-x 2 seboss666 seboss666 4,0K 02.03.2020 17:34  ./
drwxr-xr-x 8 seboss666 seboss666 4,0K 02.03.2020 17:22  ../
-rw-r--r-- 1 seboss666 seboss666 477M 02.03.2020 17:28 'Alestorm - Sunset On The Golden Age.gz.wav.gz'
-rw-r--r-- 1 seboss666 seboss666 492M 02.03.2020 17:27 'Alestorm - Sunset On The Golden Age.wav'
-rw-r--r-- 1 seboss666 seboss666 472M 02.03.2020 17:28 'Alestorm - Sunset On The Golden Age.xz.wav.xz'
-rw-r--r-- 1 seboss666 seboss666 492M 02.03.2020 17:28 'Alestorm - Sunset On The Golden Age.zst.wav'
-rw-r--r-- 1 seboss666 seboss666 482M 02.03.2020 17:28 'Alestorm - Sunset On The Golden Age.zst.wav.zst'

On voit que le xz est largement au dessus des deux autres concurrents, mais le prix en temps de compression est très élevé. Ici, on voit que le zstd est moins performant par défaut que gzip, mais comme je l’ai dit, ce n’est pas nécessairement représentatif car le format de fichier ne se prête pas vraiment à l’objectif, de ce côté les formats liés à la compression audio ont de meilleurs résultats. Et le temps de compression est vingt fois plus court, donc facile d’être séduit par le petit dernier de la bande.

Ça, c’est pour la compression, voyons donc les résultats de décompression :

$ time gzip -d Alestorm\ -\ Sunset\ On\ The\ Golden\ Age.gz.wav.gz 

real	0m5,306s
user	0m4,822s
sys	0m0,445s
$ time xz -d Alestorm\ -\ Sunset\ On\ The\ Golden\ Age.xz.wav.xz 

real	0m43,681s
user	0m42,892s
sys	0m0,659s

$ time zstd -d Alestorm\ -\ Sunset\ On\ The\ Golden\ Age.zst.wav.zst 
Alestorm - Sunset On The Golden Age.zst.wav.zst: 514968188 bytes               

real	0m0,797s
user	0m0,339s
sys	0m0,435s

Une fois encore, on voit que xz est loin derrière en termes de rapidité, alors que zstd caracole en tête.  Il semble donc tenir une grande partie de ses promesses.

Dossier du blog

Passons à quelque chose de plus représentatif des pratiques d’archivage. Déjà ce qui est marrant, c’est la différence entre le dossier d’origine, et le fichier tar utilisé pour le test :

$ du -shc blog*
822M	blog
799M	blog.tar

Il y a donc près de 30Mo de perdus en petits fichiers qui prennent plus de place dans le système de fichiers que leur taille réelle. Mais on est pas là pour en faire l’analyse, revenons à nos moutons. Même motif que précédemment, copie du fichier tar pour chaque algorithme, voilà le résultat de compression :

$ time gzip blog.gz.tar 

real	0m38,189s
user	0m36,724s
sys	0m1,170s
$ time xz blog.xz.tar 

real	2m0,761s
user	7m24,399s
sys	0m2,488s
$ time zstd --rm blog.zst.tar 
blog.zst.tar         : 90.08%   (836802560 => 753810165 bytes, blog.zst.tar.zst) 

real	0m5,070s
user	0m4,118s
sys	0m1,317s

Euh, ok, là encore, zstd est loin devant en termes de rapidité, xz est hors concours de par sa lenteur, et ça donne quoi sur les tailles résultantes ?

$ l
-rw-r--r--  1 seboss666 seboss666 720M 02.03.2020 18:02  blog.gz.tar.gz
-rw-r--r--  1 seboss666 seboss666 799M 02.03.2020 17:58  blog.tar
-rw-r--r--  1 seboss666 seboss666 702M 02.03.2020 18:03  blog.xz.tar.xz
-rw-r--r--  1 seboss666 seboss666 719M 02.03.2020 18:03  blog.zst.tar.zst

Ah ! Effectivement, cette fois le résultat est proche de gzip, mais donc pour un traitement huit fois plus rapide. Et ça en compression. Et en décompression ?

$ time gzip -d blog.gz.tar.gz 

real	0m8,573s
user	0m7,003s
sys	0m0,988s
$ time xz -d blog.xz.tar.xz 

real	0m43,338s
user	0m41,663s
sys	0m1,268s
$ time zstd -d --rm blog.zst.tar.zst 
blog.zst.tar.zst    : 836802560 bytes                                          

real	0m3,048s
user	0m0,529s
sys	0m1,146s

Bon, les temps de décompression sont un peu moins impressionnants, mais tout de même, près de trois fois plus rapides. J’arrête là les manipulations, je pense qu’on a nos réponses.

Pas étonnant qu’il soit populaire

À voir les chiffres, on comprend un peu mieux le choix d’abord d’Ubuntu, puis d’Arch Linux et donc de Manjaro, de basculer sur ce format plutôt qu’un autre. Arch Linux utilisait xz jusqu’ici, et on voit que si ça fonctionne bien d’un point de vue stockage, et donc économie en transfert de données via Internet, le coût en termes de performances à la fois en compression et décompression ne vaut finalement pas la chandelle. Autant consommer un peu plus d’espace disque, un peu plus de réseau, pour finalement gagner en temps de travail aussi bien à la création qu’à l’installation. Ça serait intéressant de comparer le coût énergétique entre le transfert additionnel sur le réseau, et les calculs nécessaires pour générer les archives, mais c’est un peu compliqué et hors scope ici.

Reste que le format est soutenu par Facebook, et naturellement ça fait un peu peur, mais vu la finalité, il y a peu à craindre quant à sa pérennité, contrairement au support PHP d’HHVM qui a pris fin il y a un an. Si l’utilitaire zstd n’est pas dispo nativement sur votre système, vous pouvez vous tourner vers le dépôt Github qui regorge d’informations à son sujet, avec d’autres chiffres de performances, effectués sur une machine hors de portée du commun des mortels.

En tout cas, je pense que c’est une bonne décision d’y être passé sur Arch Linux, et pour avoir souffert avec quelques créations de paquets AUR qui prennent beaucoup de temps même avec xz en multiithread, j’espère que la plupart des recettes basculeront sur ce format rapidement.

Debian, VMware, Terraform sont dans un bateau…

lundi 2 mars 2020 à 18:30

J’ai eu récemment à déployer une vingtaine de machines sur un cluster Private Cloud Vmware fourni par OVH. J’ai pour ça testé le code qu’un de leurs ingénieurs a partagé sur le blog d’OVH, mais ça ne s’est pas déroulé comme prévu. Et la solution a pris du temps, et c’est dégueulasse…

Un vrai parcours du combattant

Mes machines doivent être déployées en Debian 9 (on pleure pas trop vite s’il vous plait), pas le choix parce qu’il nous manque encore des prérequis internes pour la bonne gestion de Debian 10 chez nous. Qui dit déploiement par terraform dit d’abord création d’un template Debian 9.

Au passage je vous recommande vivement de vous intéresser à Terraform si vous comptez bosser de l’infrastructure « cloud », y’a une quantité hallucinante de providers et c’est vraiment un outil sympa à utiliser, qui s’intègre assez facilement dans un flux de déploiement automatisé de bout en bout.

Au début mon manager m’a filé un dépôt avec une configuration Packer, autre outil développé par Hashicorp, qu’il avait utilisé pour du CentOS 7. Après avoir passé une après-midi à essayer de comprendre comment fonctionne le preseed de l’installateur Debian, et échoué à le faire utiliser avec Packer (au passage, si on compare preseed à kickstart, preseed c’est de la merde en barre), j’ai décidé de créer mon template à la main à partir de l’iso officielle 64bit, avec installation d’open-vm-tools, comme recommandé par la documentation de VMware.

Puis, une fois le template prêt et rangé dans son dossier, je prépare le code rapidement et procède à une première tentative de création d’une machine virtuelle à partir du template. Comme on l’imagine, puisqu’on en parle aujourd’hui, ça ne s’est pas vraiment déroulé comme je l’attendais :

Error: error sending customization spec: Customization of the guest operating system 'debian9_64Guest' is not supported in this configuration. Microsoft Vista (TM) and Linux guests with Logical Volume Manager are supported only for recent ESX host and VMware Tools versions. Refer to vCenter documentation for supported configurations.

Et il supprime la machine virtuelle. Arf. Il se trouve que j’ai le même message après une tentative manuelle depuis l’interface web en cochant l’option qui correspond à la personnalisation de l’OS. Damned. Déjà, le message est sympathique car il parle de Vista, cancer nécessaire de Microsoft qui aura quand même permis à terme d’avoir le génial Windows 7 (qui vient de prendre sa retraite), mais aussi et plus surprenant, de LVM. Surprenant car je sais que VMware supporte parfaitement LVM dans ses différents outils, pour avoir bouffé du VMware Converter sur un projet précédent. Sans plus de conviction, je perds donc du temps à recréer un second template partitionné sans LVM cette fois; même punition, même message, l’erreur est donc générique et débile.

Je me tourne alors vers le support OVH, en leur donnant tous les détails de mes manipulations et tests. Leur réponse, en substance :

On reproduit, mais on comprend pas non plus

Et en effet, en cherchant partout sur les docs VMware ça devrait pas bloquer. Mais des réponses comme celle-ci ne m’avancent pas à grand chose.

Il fallait que j’avance donc j’ai déployé mes machines de pré-production à la main, fourni les accès à l’agence de développement et j’ai un peu laissé de côté, pendant que je relançais à intervalle régulier le support pour avoir des nouvelles.

Réponse quelques dizaines de jours et partage de traces terraform & co plus tard : il faut modifier le type de machine virtuelle qu’on crée à Ubuntu, même si on installe Debian dedans. Mentir à l’hyperviseur, bravo, il est vrai que je l’avais vu passer dans mes recherches Google, mais ça ne me plaît pas vraiment et donc, j’ai pas testé. Mais maintenant et au point où on en est, pourquoi pas. Le support me dit que je peux tester avec leur template, mais ça échoue sur la même erreur, bravo.

J’entreprends donc de refaire un nouveau template, en mentant, avec LVM, et je réinstalle les mêmes packages. Nouvelle tentative de déploiement : ça semble fonctionner, je n’ai plus le message d’erreur de personnalisation, mais pas de bol, ça échoue une étape plus tard. Ce coup-ci cependant, Terraform me laisse la machine pour débug, et affiche ce message :

An error occurred while customizing VM client-test1-preprod1. For details reference the log file <no_log> in the guest OS.

j’ai vraiment pas de bol, il devrait y avoir un fichier de log, il n’existe pas. Je découvre malgré tout un truc bizarre : la machine virtuelle est bien démarrée, mais la carte réseau n’est pas connectée, alors que la case est bien cochée dans le template. Je refouille sur Google, et là, je tombe sur un message récent, qui n’existait pas au début de mon problème, qui parle d’un souci avec l’unit systemd d’open-vm-tools.

Je retourne donc dans le template (qu’on convertit en machine virtuelle pour pouvoir en modifier le contenu), et plutôt que de modifier le fichier original qui pourrait être écrasé par une éventuelle mise à jour, j’exploite les capacités d’override de systemd dont vient de parler Cascador sur le Blog Libre :

$ export EDITOR=vim
$ sudo systemctl edit open-vm-tools.service
#Contenu de l'override
[Unit]
After=dbus.service

On repasse en template, et on relance terraform, et là, 1m30s après :

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Et tout ça, ça a pratiquement pris encore une après-midi qui n’a pas pu être consacrée à d’autres sujets (dont une investigation sur une corruption fréquente de base RPM sur du Redhat 7 qui semble causée par une configuration qu’on déploie chez tous les clients…).

Comme d’habitude, je cherche et constate que personne n’a remonté le problème chez Debian. J’ai failli le faire, avant de comparer au paquet Debian 10, et je me suis ravisé, car de toute façon, Debian 9 n’a plus qu’un an et demi devant lui, et le nombre de projets qu’on sera amené à mener dans un environnement similaire fait qu’on pourra supporter cette petite bidouille. J’ai tout de même partagé au support OVH qui pourra, au besoin, transmettre aux futurs infortunés qui seraient contraints au même déploiement sans avoir lu cet article.

VMware, c’est de la merde ?

En vrai pas tant que ça, mais effectivement sur ce point, Debian et Ubuntu partageant une base commune, je ne comprend pas pourquoi il ne « supporterait » pas le fait de déclarer correctement qu’on utilise une Debian, surtout qu’il bosse parfaitement derrière : hostname, fichier interfaces, tout est là, proprement configuré. On rage d’autant plus du coup d’avoir perdus plusieurs après-midi et patienté plusieurs jours sur un truc aussi bête.

Et dans le dépôt d’open-vm-tools, il n’y a pas de fichier d’unit systemd, je pense donc que c’est une faiblesse introduite par le mainteneur du paquet pour Debian. D’ailleurs, quand on voit le nombre de différences entre celui pour Debian 9 et celui pour Debian 10, c’est qu’il a dû être plus longuement testé et donc les problèmes mieux identifiés. Donc là non plus on ne peut pas entièrement blâmer les développeurs, même si un petit coup de pouce documentaire n’aurait pas été de trop de la part de l’éditeur. On salue par contre sans problème le choix des licences rattachées au code publié, pas évident puisque VMware est un éditeur de logiciel majoritairement propriétaire à la base.

De mon côté, j’aimerai tester Terraform sur un autre hyperviseur, en l’occurrence Proxmox puisque je l’utilise chez moi et sur le serveur physique qui héberge entre autre ce blog, mais il n’y a pas de provider officiel, juste un provider indépendant qui semble du coup avoir ses propres contraintes qu’il faudra apprivoiser. Par contre vu le rythme actuel de publication, ça sera dans deux ans hein ^^’