Devoxx France 2018 – Petite sélection

À la mi-avril avait lieu le Devoxx France à Paris, cycle de conférence sur 3 jours, à destination des développeurs. Voici quelques interventions qui ont retenu mon attention.

Laissez tomber Express, passez à son successeur
Présentation de Koa. Plus léger qu’Express, avec juste le minimum et surtout le support des fonctions async par défaut.

Gagner des super pouvoirs avec le terminal
Petit tour d’horizon sur tout ce qu’il est possible de faire directement dans son terminal (avec les « bons » logiciels).

Attention ! Ne mets pas cette clé tu risques de te faire hacker très fort !
Sur le danger de tout ce qui ressemble à une clé USB et ce qu’il est possible de faire avec un micro-controleur très simple.

T’es plutôt merge ou rebase ?
Petit point sur Git.

Les Tests End to End avec des raspberry pi chez leboncoin
Un impressionnant système de test auto sur mobile, construit de zéro.

Quand une documentation devient un problème et que faire alors
Bonnes pratiques et retour d’expérience sur la gestion d’une documentation.

NodeJS 5 bonnes raisons pour lesquelles vous devriez y jeter un oeil
Introduction à NodeJS et l’environnement JS en 2018.

RxJS Les clefs pour comprendre les observables
Quelques explications sur les observables. Quelques exemples intéressants.

Angular et performances
Optimiser Angular. Nouveautés.

RetourAuxSources Les cookies HTTP
Tous savoir sur les cookies !

Ajout du champ Certification Authority Authorization (CAA) à la zone DNS

Je m’étais intéressé il y a de cela plusieurs semaines aux entêtes de sécurité du protocole http et j’en avais également profité pour regarder du côté de la zone DNS. Je m’étais donc occupé d’ajouter un champ CAA, pour Certification Authority Authorisation à la zone DNS de mon domaine.

Quelques mots sur le champ en question. Le but est d’indiquer publiquement quelles autorités de certification sont aptes à générer un certificat pour le domaine concerné (zéro, une ou plusieurs). Si une tentative de génération d’un certificat devait être tenté par une autre autorité, celle-ci devrait échouer car ne figurant pas comme autorité autorisée. A condition bien sûr que l’autorité de certification prenne en compte le champ CAA et le respecte. L’objectif étant de réduire le risque que quelqu’un demande et obtienne un certificat pour votre domaine sans y être autorisé.

Pour la mise en place sur unicoda.com, cela nous donne la configuration suivante :

Trois paramètres possibles: issue, issuewild et iodef. Dans l’ordre, issue restreint la génération des certificats pour le domaine, issuewild restreint la génération de certificat « wildcard » (et ignore tout autre champ comportant issue). Enfin, iodef permet de spécifier un moyen de communication (mailto, http ou https) pour signaler une violation du champ CAA.

Pour davantage d’informations, rien de mieux que d’aller lire directement la RFC : RFC 6844. On peut également consulter les explications de Let’s Encrypt.

RuneAudio comme lecteur de musique

A l’heure d’une réinstallation de RuneAudio, petit point sur la façon dont je profite de ma bibliothèque musicale numérique.

Commençons par planter le décor. L’intégralité de ma musique est stockée sur mon NAS et accessible via un partage samba. Pour la diffusion du son, je dispose d’une petite chaîne Hifi datant de l’époque du début des lecteurs MP3. Pas de connexion Bluetooth, pas de WiFi, pas de port USB, mais une entrée auxiliaire… et un lecteur cassette ! Pour faire le lien entre les deux composants, j’ai choisi un Raspberry Pi dans sa troisième version afin de disposer du WiFi intégré.

Pour la partie logicielle, j’ai testé différentes projets libres : Pi MusicBox, Volumio et RuneAudio. Les deux dernières solutions se distinguent particulièrement par leur interface et leurs fonctionnalités. Mon choix s’est en définitive porté vers RuneAudio dans sa version 0.4-beta. Version plutôt stable malgré son statut de beta. La recherche est le point noir, et retourne en permanence « undefined ». Le problème est connu, mais n’est pas forcément simple à corriger; d’après ce que j’avais pu lire en parcourant le forum.

Inventaire des composants avant montage (Écran tactile non visible).

Pour profiter au mieux du système, j’ai ajouté un écran tactile au Pi, afin de pouvoir contrôler et afficher la liste de lecture, sans avoir à passer par un autre périphérique externe. Le tout, assemblé dans un support  à charnière bien pratique. Par ailleurs, une application Android simple est disponible afin de piloter RuneAudio à partir de son téléphone sans avoir à passer par l’interface web via un navigateur (à condition d’être connecté sur le même réseau).

Mise en place du Pi.

Après presque deux ans d’utilisation, ce montage me donne entière satisfaction. Pas ou peu de problème jusqu’à ce que j’effectue des modifications de configuration du côté de mon routeur, et que la connexion automatique au WiFi devienne quasi impossible (d’où la réinstallation évoquée au début). Dernièrement, l’ajout d’une alimentation à interrupteur m’évite de devoir accéder à la multiprise pour couper l’alimentation du Pi et rends l’ensemble bien plus pratique. Je ne vais pas préciser ici toutes les fonctionnalités, avantages et inconvénients de RuneAudio, et je vous quitte donc sur une photo en situation.

Conversion flac vers mp3

Dans le but de pouvoir lire des fichiers de ma bibliothèque musicale sur un appareil n’étant pas en mesure de lire le format flac, j’ai cherché à résoudre le problème de la conversion d’un fichier audio au format flac vers le format mp3. Après recherche, voici la commande que j’obtiens en utilisant ffmpeg :

ffmpeg2.8 -y -i tangerine.flac -codec:a libmp3lame -ab 320k -map_metadata 0 -id3v2_version 3 -write_id3v1 1 tangerine.mp3

Étape suivante pour rendre la conversion plus pratique, on applique la commande à tous les fichiers flac du répertoire à l’aide d’une boucle for :

for f in *.flac; do ffmpeg -i "$f" -acodec libmp3lame -ab 320k -map_metadata 0 -id3v2_version 3 -write_id3v1 1 "${f%.flac}.mp3"; done

Enfin, dernière amélioration, on exécute la commande pour tous les fichiers finissant par .flac présent dans le répertoire courant et dans tous les sous-répertoires :

find -name "*.flac" -exec ffmpeg2.8 -y -i {} -acodec libmp3lame -ab 320k -map_metadata 0 -id3v2_version 3 -write_id3v1 1 {}.mp3 \;

A noter que pour cette dernière commande, le nom du fichier traité sera de la forme Tangerine.flac.mp3. A l’issue de cette dernière commande, nous disposons donc des fichiers flac et de leur copie encodée en mp3. Ayant travaillé sur une copie de mes fichiers musicaux, je peux donc me débarrasser des fichiers flac pour ne conserver que les nouveaux fichiers :

find -name "*.flac" -exec rm {} \;

Il ne reste plus qu’à copier les fichiers restants sur le support destiné à l’appareil.

Procédure de restauration de sauvegarde… Surprise !

Depuis plusieurs mois donc, mes services auto-hébergés sont sauvegardés quotidiennement de façon automatique et incrémentale. Je suis en théorie protégé contre la perte de mes données en cas de panne matérielle du support de stockage de mon serveur. Ça, c’est la théorie, il me restait en l’occurrence à valider le processus de sauvegarde en m’assurant de la façon de restaurer les données.

J’ai donc commencé ces derniers jours l’écriture d’un script ansible permettant de redéployer automatiquement l’ensemble de mes services sur un nouveau serveur si besoin. L’occasion rêvée de vérifier que la restauration de sauvegarde fonctionne correctement.

Après configuration de duplicity sur la nouvelle machine, je tente donc de restaurer un fichier pris au hasard:

duplicity restore --file-to-restore path/to/wallabag/vendor/jdorn/sql-formatter/LICENSE.txt -t now cf+hubic:// test/LICENSE-restored.txt

J’obtiens une erreur dès les premières tentatives : No backup chains found, et lis au détour d’une page web qu’il faut à priori effectuer un list-current-files au préalable. Il faudra que je vérifie cette information lors du test réel de mon script sur un système vierge. Je découvre donc que duplicity récupère dans un premier temps tous les fichiers manifest. La récupération des fichiers se poursuit, et c’est le drame :

Giving up after 1 attempts. NoSuchObject: Object 'duplicity-inc.20180212T113006Z.to.20180213T113007Z.manifest.gpg' doesn't exist (HTTP 404)

L’un des fichiers n’est pas renvoyé par hubiC. Il est néanmoins visible dans l’interface, mais impossible de le récupérer, la requête effectuée par l’interface web retourne elle aussi une mauvaise erreur 404. Ce problème de manifeste manquant concerne une chaîne secondaire, mais impacte malheureusement l’ensemble de la collection. Impossible de restaurer les données via duplicity…

Continuer la lecture de « Procédure de restauration de sauvegarde… Surprise ! »