PROJET AUTOBLOG


Le blog de Seboss666

Site original : Le blog de Seboss666

⇐ retour index

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 ^^’

Note de service : j’ai dû toucher aux commentaires

samedi 25 janvier 2020 à 16:11

En effet, depuis quelques semaines le blog est la cible d’attaques répétées de bots poussant quantité de merdes dans les commentaires sur différents articles. J’ai du coup dû modifier les réglages donc pas de panique si vous êtes désormais « modéré », je vous explique tout.

Voilà pourquoi j’ai du intervenir :

Ça devient ingérable, avec les paramètres actuels, on va réduire considérablement la surface pour juguler.

Donc, j’ai du réduire le délai d’ouverture des commentaires. Historiquement, vous aviez le droit d’intervenir même sur un billet datant des origines du blog, désormais seule la dernière année est « ouverte ». De plus, avant je plaçais les commentaires contenant plus de deux liens en modération, désormais c’est à partir d’un seul lien. C’est chiant je sais, surtout sur les commentaires qui ajoutent des liens pour compléter ou débattre sur le sujet de l’article, mais pas trop le choix dans l’immédiat.

Pourquoi t’utilises pas akismet comme tout le monde ?

Ben oui c’est WordPress après tout, et akismet est fourni par défaut. Ben c’est parce qu’akismet me fait passablement chier avec les commentaires que j’essaie régulièrement de poster sur les blogs des confrères, donc j’ai pas envie d’imposer un truc qui ne me plaît pas (ne fais pas aux autres toussa…). J’ai déjà eu l’occasion d’en parler dans une réflexion sur mon pseudonyme, je vais pas vous refaire tout le tableau.

Par contre, je vais chercher une solution un peu plus robuste parce que faut pas déconner, ça devient pénible. Le souci, c’est que la plupart des solutions, captcha en tête, reposent sur des éléments que je ne veux pas intégrer sur le blog (coucou reCaptcha de Google), ça complique donc la recherche.

<script async src="https://platform.twitter.com/widgets.js" charset="utf-8">

Voilà, c’est pas grand chose, mais c’est suffisamment impactant sur le fonctionnement du blog pour que j’en parle vite fait. Sur ce, je retourne me reposer en ce weekend bien trop court à mon goût, et on se dit à bientôt pour de nouvelles lectures 😉

Réduire la consommation de ressources liée à la télémétrie de Windows 10

samedi 11 janvier 2020 à 10:30

Peu avant que je migre mon PC de boulot sous Linux, un des derniers évènements qui m’a gonflé particulièrement est une saturation du PC par un process que je ne connaissais pas, et en découvrant son rôle, ça a été encore plus rageant. Il y a tout de même une solution, tant mieux j’ai envie de dire, voyons donc ce qu’il en est.

Les symptômes

Sans prévenir, en pleine journée, un process nommé « Microsoft Compatibility Telemetry » tabasse le SSD qui est déjà bien handicapé par l’antivirus foireux qu’on nous impose au boulot. Télémétrie, la fameuse excuse de Microsoft pour collecter, sur votre dos, vos usages de vos outils informatiques, sans anonymisation évidemment parce que le ciblage des données, c’est leur nouveau pétrole. Déjà que ça me gonfle sévère, alors si en plus ça m’empêche d’utiliser mon ordinateur, à fortiori mon outil de travail, non merci.

Le traitement

Médicament 1

Il faut passer par le gestionnaire de politiques locales pour couper la chique à cette horreur. Pour ça deux techniques, soit commencer à taper « gpedit » dans le menu démarrer, soit passer par le raccourci Win+R et taper « gpedit.msc » dans la fenêtre d’exécution de programmes. Ensuite, se rendre sur « Computer Configuration », »Administrative templates », « Windows Components », « Data collection and Preview builds ». Vous devriez tomber sur une entrée « Allow Telemetry », sur laquelle vous pouvez double-cliquer afin d’en modifier les propriétés, la plus importante étant « Disabled ». Normalement, ça devrait suffire, sinon, passez au médicament 2.

Médicament 2

Si l’éditeur de politiques ne suffit pas à calmer le saligaud, l’autre solution est de passer par la base de registres, le vénérable regedit qui n’a pas changé depuis Windows 95 au moins. Même technique pour le lancer, sans surprise validez l’autorisation de modifications sur le système.

Pour le chemin, ce coup-ci, c’est « HKEY_LOCAL_MACHINE« , « SOFTWARE« , « Policies« , « Microsoft« , « Windows« , « Data collection » (c’est pénible de voir ça partout). Cette fois, il faut créer une nouvelle valeur « DWORD (32 bit)« , avec le nom « Allow Telemetry », et lui donner la valeur 0. Comme souvent avec la base de registres, le meilleur effet se verra après un reboot (du grand classique Windows quoi).

Un petit bol d’air, dans un océan de fumée

Plusieurs années après l’introduction de Windows 10, malgré les nombreux rapports et interrogations d’associations, d’experts indépendants et étatiques, Microsoft continue d’espionner les moindres usages de vos machines, officiellement pour mieux mesurer et prioriser les corrections et changements à venir dans un système qui évolue désormais plus souvent au fil du temps. Quand on voit les paramètres par défaut qu’il faut désactiver de partout, quand on voit que les domaines utilisés pour remonter la télémétrie ne peuvent pas être bloqués car partagés avec Windows Update, nul doute que non, Windows n’est plus un système d’exploitation recommandable pour le commun des mortels.

Mais bon, malgré toutes les alertes possibles et imaginables, les gens sont encore étonnés quand on leur met sous le nez l’ampleur de la perte de contrôle et la surveillance constante dont ils sont l’objet. Comme d’habitude, il faudra que ça aille trop loin pour qu’ils se réveillent…