Aymeric / APLU(.FR)Site d'Aymeric (ou d'aplufr) pour parler de Linux, de technique.. enfin de tout et surtout de n'importe quoi !2023-09-19T19:41:16+02:00Aymericurn:md5:9a770342f58fde945e9ce016459f8f12DotclearQuelle version de LineageOS pour le Wileyfox Swift ?urn:md5:2e75b3d20dbb8337c38d5c7d7b4562802021-07-29T11:17:00+02:002021-07-30T11:17:31+02:00APLUandroidAndroidcracklinglineageosSwift<p>Ce billet sera mis à jour au fil des mises à jour de LineageOS pour vous indiquer quelle version de LineageOS j’utilise, vous pouvez bien sûr prendre les devants et passer sur une autre version, mais parfois certaines mises à jour sont problématiques…</p>
<p><u>Au 20 juillet 2021</u> : lineage-17.1-20210706-microG-crackling.zip, pas de soucis rencontré.<br />
Le patch de sécurité est celui du 5 juin 2021.</p> <h3>Historique</h3>
<p><u>Au 26 avril 2020</u> : lineage-16.0-20200423-microG-crackling.zip, pas de soucis rencontré.<br />
Le patch de sécurité est celui du 5 avril 2020.</p>
<p><u>Au 7 avril 2020</u> : lineage-16.0-20200402-microG-crackling.zip, pas de soucis rencontré.<br />
A noté un changement de mainteneur côté LineageOS, il n’y pas eu de version pendant un mois.<br />
Le patch de sécurité est celui du 5 mars 2020.</p>
<p><u>Au 11 janvier 2020</u> : lineage-16.0-20200106-microG-crackling.zip, pas de soucis rencontré.<br />
Le patch de sécurité est celui du 5 décembre 2019.</p>
<p><u>Au 21 décembre 2019</u> : lineage-16.0-20191216-microG-crackling.zip, pas de soucis rencontré.<br />
Le patch de sécurité est celui du 5 décembre 2019.</p>
<p><u>Au 5 novembre 2019</u> : lineage-16.0-20191104-microG-crackling.zip, pas de soucis rencontré.<br />
Le patch de sécurité est celui du 5 octobre 2019.</p>
<p><u>Au 7 octobre 2019</u> : lineage-16.0-20190930-microG-crackling.zip, pas de soucis rencontré.<br />
Le patch de sécurité est celui du 5 septembre 2019.</p>
<p><u>Au 10 septembre 2019</u> : lineage-16.0-20190909-microG-crackling.zip, pas de soucis rencontré mais la mise à jour du firmware interne du téléphone est obligatoire. Un billet va être publié dans les prochains jours pour expliquer cette mise à jour. Pour le reste il s’agit d’une installation normale du système.<br />
Le patch de sécurité est celui du 1 août 2019.</p>
<p><u>Au 18 mai 2018</u> : lineage-14.1-20180516-microG-crackling.zip, pas de soucis rencontré.<br />
Le patch de sécurité est celui du 5 avril 2018.</p>
<p><u>Au 18 avril 2018</u> : lineage-14.1-20180418-microG, pas de soucis rencontré.<br />
Le patch de sécurité Android est celui du 5 avril 2018.</p>
<p><u>Au 17 mars 2018</u> : lineage-14.1-20180314-microG, pas de soucis rencontré.<br />
Le patch de sécurité Android est celui du 5 février 2018.</p>
<p><u>Au 28 janvier 2018</u> : lineage-14.1-20180122-microG, pas de soucis rencontré.<br />
Le patch de sécurité Android est celui du 5 janvier 2018.</p>
<p><u>Au 01 décembre 2017</u> : lineage-14.1-20171129-microG, attention il s’agit d’un changement de ROM bien que basée sur LineageOS, un billet explicatif arrive prochainement.<br />
Le patch de sécurité Android est celui du 6 novembre 2017.</p>
<p><u>Au 01 novembre 2017</u> : lineage-14.1-20171031, pas de soucis rencontré.<br />
Le patch de sécurité Android est celui du 5 octobre 2017. Cette version inclu les correctifs pour limiter l’attaque sur le protocole WPA.</p>
<p><u>Au 16 octobre 2017</u> : lineage-14.1-20171016, pas de soucis rencontré.<br />
Le patch de sécurité Android est celui du 5 octobre 2017. Cette version n’apporte pas le correctif pour limiter l’attaque sur le protocole WPA (voir <a href="https://www.krackattacks.com/" hreflang="en">krack</a>).</p>
<p><u>Au 24 septembre 2017</u> : lineage-14.1-20170918, pas de soucis rencontré.<br />
Le patch de sécurité Android est celui du 5 septembre 2017 qui corrige un grand nombre de vulnérabilité.</p>
<p><u>Au 13 septembre 2017</u> : lineage-14.1-20170911, pas de soucis observé.<br />
Le patch de sécurité Android est celui du 5 août 2017.</p>
<p><u>Au 09 septembre 2017</u> : lineage-14.1-20170904, pas de soucis observé. Je n’ai pas effectué de test sur les autres versions publiées. Cette version corrige <a href="https://source.android.com/security/bulletin/2017-08-01" hreflang="en">plusieurs vulnérabilités critique</a>.<br />
Le patch de sécurité Android est celui du 5 août 2017.</p>
<p><u>Au 09 août 2017</u> : toujours la version lineage-14.1-20170717, la version lineage-14.1-20170807 qui corrige d’importantes failles de sécurité rend l’écran inactif, plutôt génant donc. Je n’ai pas le temps de tester les versions intermediaire.</p>
<p><u>Au 24 juillet 2017</u> : lineage-14.1-20170717, pas de soucis observé. Je n’ai toujours pas effectué de test sur les autres versions publiées.<br />
Le patch de sécurité Android est celui du 5 juillet 2017.</p>
<p><u>Au 27 juin 2017</u> : lineage-14.1-20170626, pas de souci observé. Le système de GPS GLONAS fonctionne (il ne fonctionnait pas dans les versions précédentes). Je n’ai, là non plus, pas eu l’occasion de tester les autres versions publiées dans le mois de juin.<br />
Le patch de sécurité Android est celui du 5 juin 2017.</p>
<p><u>Au 02 juin 2017</u> : lineage-14.1-20170529 fonctionne sans problème, je n’ai pas eu l’occasion de tester les autres versions publiées dans le mois de mai.</p>
<p><u>Au 09 mai 2017</u> : lineage-14.1-20170508 semble fonctionner normalement, sans les problèmes des <a href="https://jira.lineageos.org/browse/REGRESSION-395" hreflang="en">deux précédentes</a> versions. Cependant la source du problème n’a pas été identifiée.</p>
<p><u>Au 06 mai 2017</u> : lineage-14.1-20170410, il y a un problème avec la version lineage-14.1-20170424 ainsi que la version lineage-14.1-20170501, lors de la désactivation du wifi, le téléphone redémarre.</p>Conversion de VHS au format numériqueurn:md5:fb9b9c6c14c9be49654636f651dade7e2021-03-01T18:00:00+01:002021-03-02T15:39:53+01:00APLUmediacenteracquisitionffmpegnumeriquevhsvideo<p>Récemment je me suis (re)lancé dans la numérisation de vieille VHS (certaines ont plus de 20 ans) pour les conserver dans un format numérique… et aussi pouvoir les regarder (nostalgie).</p>
<p>Voici ma méthode ainsi que quelques conseils</p> <h2>Prérequis</h2>
<h3>Matériel</h3>
<p>D’abord il faut évidemment un lecteur de magnéto VHS, dans mon cas j’en avais déjà un à disposition. Ensuite un (vieux) PC avec une carte d’acquisition vidéo, dans mon cas j’utilise une (vieille) carte Phillips SAA7134 (c’est une carte en PCI).</p>
<p>Bref on reste dans le vieux, mais ce n’est pas bien grave.</p>
<p>Le magnéto VHS dispose d’une sortie SCART, la carte d’acquisition d’une entrée composite et S-Video. Si le signal composite est facile à récupérer, c’est aussi celui ayant la plus mauvaise qualité, on utilise donc un autre (ancien) appareil entre les deux qui est capable de convertir en S-Video (on peut trouver sinon des petits boîtiers à brancher directement pour convertir le SCART).</p>
<p>Donc pour résumer on a :</p>
<ul>
<li>Un magnéto VHS qui sort en SCART.</li>
<li>Un appareil qui reçoit du SCART et sort du S-Video + audio sur une prise séparée.</li>
<li>Un PC avec une carte acquisition en S-Video, une carte son et un disque dur.</li>
<li>Une télé qui reçoit à la fois la sortie de l’appareil intermédiaire et du PC (c’est quand même plus pratique de voir ce que l’on fait).</li>
</ul>
<h3>Logiciels</h3>
<p>Le PC est installé avec un Debian 8 (oui c’est vieux, le PC a été installé en 2015 uniquement pour cet usage et n’a jamais été mis à jour depuis).</p>
<p>Sur ce PC on a :</p>
<ul>
<li>Une interface graphique (mate en l’occurrence)</li>
<li>Pulseaudio</li>
<li>FFmpeg</li>
<li>xawtv</li>
</ul>
<p>Concernant ffmpeg, pour ne pas vous palucher la doc : les filtres vidéos (ou audio), sont séparés par des virgules et les options du filtre avec des deux points.</p>
<h2>Étape 1 — la capture</h2>
<p>Le PC est vieux, c’est un P4, et il n’est pas assez performant pour effectuer l’acquisition et la conversion en temps réel. De plus en raison d’un décalage entre les signaux de luminance et chrominance, je suis obligé d’effectuer une petite manipulation. De ce fait on effectue la capture en format rawvideo (zéro compression) et rawaudio.</p>
<p>On commence d’abord par initialiser la carte d’acquisition en mode PAL-BG et S-Video avec les deux commandes suivantes :</p>
<pre>
v4lctl setnorm PAL-BG
v4lctl setinput S-video</pre>
<p>Une fois fait, on utilise FFmpeg pour effectuer la capture, j’utilise l’option filter_complex de FFmpeg pour extraire les signaux Y, U et V dans 3 fichiers distincts directement (l’utilisation des [y][u][v] permet de récupérer les flux avec l’option -map).</p>
<p>La variable "$duration" correspond à la durée de la capture, sous la forme "HH:MM:SS" ou "MM:SS".</p>
<p>Les variables $Y, $U, $V et $A correspondent respectivement aux fichiers vidéos Y, U et V et au fichier audio (stocké en .wav).</p>
<pre>
ffmpeg -y -thread_queue_size 16 -t "$duration" \
-f alsa -ac 2 -i pulse -t "$duration" -thread_queue_size 16 \
-f video4linux2 -i /dev/video0 \
-c:a pcm_s16le -r 25 -filter_complex "[1:v]extractplanes=y+u+v[y][u][v]" \
-map "[y]" -f rawvideo $Y \
-map "[u]" -f rawvideo $U \
-map "[v]" -f rawvideo $V \
-map 0 $A \
-loglevel error -stats</pre>
<p>Petite spécification ici, il n’y a pas de codec, container pour les flux vidéos donc l’extension n’a aucune importance.</p>
<p>Le signal capturé est un signal TV donc de 720 × 576 pixels, on est à environ 1Go / minute.</p>
<p>Une fois cette étape finie, la cassette peut être rangée, on a la vidéo dans 3 fichiers et l’audio séparé.</p>
<p>La machine que j’utilise pour faire la capture étant particulièrement… vieille, je copie donc mes fichiers bruts sur une autre machine pour passer à la post-conversion (le bonus c’est que je peux continuer à numériser pendant que je fais la post-conversion).</p>
<h2>Étape 2 — pré-stabilisation</h2>
<p>Cette étape dépend de votre source, dans mon cas il s’agit de vidéo filmé avec un caméscope, l’image bouge légèrement, on va donc en plus de la numériser la stabiliser.</p>
<p>Vous pouvez zapper cette partie si vous n’en avez pas besoin, il faudra aussi supprimer le filtre correspondant à l’étape suivante.</p>
<p>Comme je le disais dans l’étape 1, en raison d’un décalage entre la luminance et la chrominance je suis obligé d’effectuer une manipulation. Le détail complet est disponible en anglais ici : <a href="https://stackoverflow.com/questions/37368614/fixing-with-ffmpeg-the-chrominance-position-on-a-video-after-capturing" hreflang="en">https://stackoverflow.com/questions/37368614/fixing-with-ffmpeg-the-chrominance-position-on-a-video-after-capturing</a>.</p>
<p>Pour faire simple, le signal de chrominance est décalé de quelques lignes par rapport au signal de luminance ce qui donne une image baveuse. Les flux étant en rawvideo, on peut se permettre de « manger » quelques pixels en lisant ignorant quelques octets dans le fichier. C’est ce que fait la commande dd.</p>
<pre>
FFREPORT="file=ff.logs:level=32" ffmpeg \
-f rawvideo -framerate 25 -pix_fmt gray -video_size 720x576 -i "$Y" \
-f rawvideo -framerate 25 -pix_fmt gray -video_size 360x288 -i <(dd status=none if="$U" bs=360 skip=4 ; dd status=none if="$U" bs=360 count=4) \
-f rawvideo -framerate 25 -pix_fmt gray -video_size 360x288 -i <(dd status=none if="$V" bs=360 skip=4 ; dd status=none if="$V" bs=360 count=4) \
-aspect 4:3 \
-filter_complex "[0][1][2]mergeplanes=0x001020:yuv420p,bwdif,vidstabdetect,crop=iw:320:0:0,blackdetect[v]" \
-map "[v]" \
-c:v rawvideo \
-loglevel error -stats \
-f null -</pre>
<p>Les filtres utilisés dans ffmpeg sont donc :</p>
<ul>
<li>mergeplanes, qui vient combiner les flux Y, U et V en un seul flux vidéo couleur</li>
<li>bwdif, qui permet de désentrelacer la vidéo (initialement j’utilisais yadif mais le résultat donne une image un peu moins nette – sauf a utilisé yadif avec mcdeint mais le temps CPU devient trop important).</li>
<li>vidstabdetect, qui concerne la pré-stabilisation (ce filtre génère un fichier qui sera utilisé à l’étape suivante)</li>
<li>crop est utilisé pour ne garder que le haut de l’image</li>
<li>blackdetect est utilisé pour détecter la fin du fichier.</li>
</ul>
<p>Pour ces deux derniers filtres, le magnéto affiche un message avec sur un fond noir indiquant la fin de la VHS, j’utilise donc le filtre crop pour ne regarder que le haut de l’image et blackdetect pour trouver l’apparition du fond noir. Ils peuvent donc être retirés selon votre usage.<br />
À noter qu’ici les logs n’apparaissent pas à l’écran mais sont écrit dans le fichier ff.logs, c’est dans ce fichier qu’on trouvera les informations du filtre blackdetect.</p>
<p>Ici le fichier audio reste inutilisé et aucun fichier n’est produit (à l’exception du fichier transform.trf du filtre vidstabdetect), on indique explicitement à ffmpeg de rien écrire et on utilise force l’utilisation du codec vidéo "rawvideo" (autant éviter des cycles CPU inutiles).</p>
<h2>Étape 3 — conversion</h2>
<p>C’est à cette étape qu’on obtient une vidéo regardable et que l’on peut réutiliser plus tard !</p>
<p>La commande utilisée est donc la suivante :</p>
<pre>
ffmpeg -y \
-f rawvideo -framerate 25 -pix_fmt gray -video_size 720x576 -i "$Y" \
-f rawvideo -framerate 25 -pix_fmt gray -video_size 360x288 -i <(dd status=none if="$U" bs=360 skip=4 ; dd status=none if="$U" bs=360 count=4) \
-f rawvideo -framerate 25 -pix_fmt gray -video_size 360x288 -i <(dd status=none if="$V" bs=360 skip=4 ; dd status=none if="$V" bs=360 count=4) \
-i "$A" \
-filter_complex "[0][1][2]mergeplanes=0x001020:yuv420p,bwdif,vidstabtransform,fftfilt=dc_Y=0:weight_Y='1+squish(1-(Y+X)/100)',fftdnoiz,eq=brightness=-0.1:contrast=0.8[v]" \
-map "[v]" \
-map 3:a \
-c:a aac -b:a 192k \
-c:v libx264 -crf 25 -preset medium -aspect 4:3 \
-metadata title="$title" \
-stats \
-loglevel error \
"mavideo_stabilise.mkv"</pre>
<p>Les filtres ici deviennent un peu plus… complexe !</p>
<ul>
<li>mergeplanes, comme à l’étape 2 on refait un signal vidéo en YUV420p à partir des trois fichiers.</li>
<li>bwdif, comme à l’étape 2 on applique un filtre pour retirer l’entrelacement.</li>
<li>vidstabstransform applique la stabilisation de la vidéo ce qui améliore la qualité de visionnage (surtout pour une source filmée avec un caméscope à bout de bras).</li>
<li>fftfilt est utilisé pour augmenter la netteté de l’image, je n’ai pas inventé cette ligne elle se trouve dans la doc ffmpeg ! J’ai fini par utiliser ce filtre à la place d’un autre filtre qui fait la même chose (unsharp) car je trouve le résultat de meilleure qualité (même s’il est plus lent)</li>
<li>fftdnoiz est un filtre qui permet de retirer le bruit de la vidéo, ce n’est pas le meilleur (nlmeans à l’air encore plus performant) mais en termes de qualité / rapidité sur plusieurs tests, c’est celui que j’ai retenu.</li>
<li>eq permet de diminuer un peu la luminosité et le contraste, à adapter en fonction de la source.</li>
</ul>
<p>Concernant les filtres antibruits, j’ai testé:</p>
<ul>
<li>hqdn3d, il est très rapide mais le résultat était plutôt bof</li>
<li>nlmeans, le résultat est très propre… mais bien trop long sur mon i5 (la vitesse tombe à 1 image par seconde)</li>
<li>fftdnoiz, le résultat est propre et le temps d’encodage reste raisonnable.</li>
</ul>
<p>Ensuite en termes de codec vidéo on utilise le classique H264 avec la libx264, le "Constant Rate Factor" à 25 au lieu 23 par défauts (0 signifie une compression sans perte et 51 une image très compressée). En termes de poids vidéo final / qualité c’est parfaitement raisonnable (on convertit des VHS il ne s’agit pas de film en 4k).</p>
<p>Pour le codec audio je suis parti sur AAC, pas parce que c’est le meilleur… simplement parce que ça facilite la compatibilité dans 99% des appareils.</p>
<p>À noter que cette vidéo n’est pas coupée avec les valeurs détectées par le filtre blackdetect de l’étape précédente, j’effectue cette découpe dans une dernière passe (j’ai toujours un doute sur la capacité du filtre à trouver la fin du fichier correctement).</p>
<p>Une fois toutes ces étapes passées on obtient donc un fichier d’environ 350Mo pour 30 minutes de film.</p>
<p>La machine utilisée pour faire la post-conversion est un NUC Intel j5005 et il faut environ 4h pour 30 minutes de film, ce n’est pas très rapide, mais on a le temps et comme la vidéo convertie est plutôt bien par rapport à la source, autant prendre un peu de temps !</p>
<h2>Étape 4 — bonus – la coupure de fin</h2>
<p>Cette étape est clairement facultative, comme je disais précédemment, le magnétoscope indique la fin de la VHS, a l’étape 2 on a cette information dans le fichier de log "ff.logs".</p>
<p>En utilisant cette expression régulière :</p>
<pre>
lastblack=$(tr -d '\r' < "ff.logs" | sed -rne 's/.*\[blackdetect.*\] black_start:([^ ]*) .*$/\1/p' | tail -n1)</pre>
<p>On récupère le message du filtre qui correspond à la phrase du magnéto, précisément on récupère juste le début de l’image noire.</p>
<p>On repasse ça a ffmpeg pour lui dire de copier notre fichier "mavideo_stabilise.mkv" jusqu’à la durée trouvée.</p>
<pre>
ffmpeg -y \
-loglevel error \
-stats \
-i "mavideo_stabilise.mkv" \
-c copy \
-to "$lastblack" \
"mavideo_stab_coupe.mkv"</pre>
<h2>Conseils</h2>
<p>Déjà vous vous doutez bien que je ne retape pas toutes les commandes à chaque fois, j’ai donc deux scripts pour faire tout ça plus ou moins automatiquement.</p>
<ol>
<li>pour effectuer la capture sur la vieille machine.</li>
<li>pour effectuer la post-conversion sur une autre machine.</li>
</ol>
<p>Ensuite, même si votre machine est performante et que vous n’avez pas besoin de bricoler comme moi les différends les signaux vidéos, je vous recommande de faire en 2 étapes :</p>
<ol>
<li>capturer en rawvideo</li>
<li>post-conversion (filtre etc) dans un format numérique « pour visionage »</li>
</ol>
<p>Pourquoi : Parce qu’a un moment on se rend compte qu’il faudrait changer le contraste, qu’il y’a trop de bruit, trop de ça, que finalement ça serait bien de stabiliser la vidéo, etc. Si on a les fichiers bruts on peut repartir de fichiers pour appliquer les filtres sans pertes de qualité par rapport à la capture.<br />
Autrement, on part d’une image comprimée, qu’on bricole pour la re-comprimé, on perds a chaque étapes des informations et donc de qualité.</p>
<p>Et puis le stockage ne coute plus si cher que ça aujourd’hui, on trouve facilement des disques de 2To ou plus à des prix raisonnables, il n’y a pas besoin de SSD ! Et avec un disque de 2To on peut stocker environ 30 heures de film en rawvideo de qualité TV.</p>
<p>Enfin la capture en rawvideo minimise la charge CPU et assure une capture fluide de la vidéo, la plupart des filtres vidéos sont gourmands en ressource et dans le cas d’une capture ffmpeg ne peut pas dire au magnéto « ralenti, je n’arrive pas à suivre ».</p>
<p>Enfin faites vos tests !!</p>
<p>Les filtres que j’utilise sont bien pour mes vidéos et mon installation, ça ne sera pas forcément toujours le cas !</p>
<p>Capturez donc quelques minutes d’une VHS avec des pleins de couleurs et travailler sur ce petit extrait de vidéo pour avoir un rendu correct.</p>
<p>Vous pouvez utiliser les options -to et -ss de ffmpeg pour extraire un petit bout.</p>
<p>Aussi, pour le signal vidéo, si vous trouvez une carte d’acquisition qui supporte directement le signal RVB utilisez ça, ensuite S-Video mais évitez à tout prix le signal composite !</p>HeaPi ou piloter des convecteurs électrique avec un Raspberry Piurn:md5:b46ab6dfc215492522372d7e6c8073032020-11-07T10:10:00+01:002020-11-09T12:41:04+01:00APLUHardwarechauffageconvecteursdiydomotiqueheapiradiateursraspberrypi <p>HeaPi est un projet que j’ai réalisé (en me basant sur plein de trucs déjà existant) pour contrôler l'ensemble mes convecteurs avec un RaspberryPi et un peu de code pour remplacer un boîtier électronique de gestion des convecteurs.</p>
<p>Mais avant de rentrer dans le sujet, un peu de théorie et sur le fonctionnement du fil pilote sur les radiateurs électriques.</p>
<p>Note, si vous voulez zapper ce billet et partir directement voir <a href="https://gitlab.com/mulx/heapi/-/tree/master">les sources, c’est par là </a>!</p>
<h1>Fonctionnement du fil pilote</h1>
<p>Le principe de fonctionnement est relativement simple : le radiateur dispose de 3 fils, 4 avec la terre :</p>
<ol>
<li>La phase</li>
<li>Le neutre</li>
<li>Le fil pilote</li>
<li>La terre (optionnel dans certains cas, eh oui !)</li>
</ol>
<p>La phase et le neutre sont utilisés pour transporter la puissance est sont donc alimentés en 230 volts directement depuis le tableau électrique.</p>
<p>Le fil pilote lui ne transporte pas de puissance mais simplement une signalisation que le circuit de commande du radiateur va détecter pour choisir entre les 4 modes de fonctionnement (ou 6 selon les convecteurs). Ce signal de commande, cet ordre, est envoyé par un boîtier de commande en utilisant la phase. Il est situé dans le coffret électrique pour la connexion avec les radiateurs et une partie déportée pour la commande par l'utilisateur, avec des boutons et des leds.</p>
<p>Voici la liste des 6 ordres et les signaux électriques à transmettre :</p>
<ol>
<li>Mode confort : pas de signal sur le fil pilote ;</li>
<li>Mode économique (souvent confort -3 °C) : alternance 230 volts complète ;</li>
<li>Mode hors gel (souvent 8 °C) : demi-alternance 230 volts négative ;</li>
<li>Mode arrêt/délestage : demi-alternance 230 volts positive ;</li>
<li>Mode confort - 1° (uniquement en version 6 ordres) : 297 secondes sans signal et alternance 230 volts complète pendant 3 secondes ;</li>
<li>Mode confort - 2° (uniquement en version 6 ordres) : 293 secondes sans signal et alternance 230 volts complète pendant 7 secondes.</li>
</ol>
<p>Pour résumer dans un tableau avec des dessins</p>
<p><img alt="" class="media" height="435" src="https://www.aplu.fr/v2/public/heapi/ordre_fil_pilote.jpg" style="margin: 0px auto; display: table;" width="576" /></p>
<p>La bascule de ces différents modes ne se fait que si le convecteur est en mode "Programmation", "Auto", "Fil pilote" ou tout autre nom choisi par le fabricant, à l’exception du mode "Arrêt" qui est, généralement, prioritaire peu importe le mode choisi sur le sélecteur du convecteur.</p>
<p>En effet, sur une installation électrique qui dispose du boîtier contrôle du chauffage, ce dernier se situe dans le tableau electrique, et est connecté avec le compteur EDF sur la borne de télé-information (présente à ma connaissance, tous les modèles électroniques). Cette télé-information remonte des informations en boucle qui contiennent entre autres :</p>
<ul>
<li>la puissance souscrite/puissance de coupure ;</li>
<li>la puissance actuellement consommée ;</li>
<li>le type de contrat (heure pleine/creuse, plein tarif, tarif couleurs, etc) ;</li>
<li>le mode actuel (heure pleine/creuse, etc).</li>
</ul>
<p>Lorsque le boîtier de contrôle du chauffage détecte que la puissance actuellement consommée et égale ou très proche de la puissance de coupure, il va envoyer un ordre "Arrêt" à l'ensemble des radiateurs (ou par zone dans un fonctionnement multi zones) pendant quelques secondes, le temps que la puissance consommée redescende. Le but étant de faire du délestage pour éviter de faire disjoncter l'installation complète.</p>
<p>Bien sûr, ça la partie théorique, dans la pratique certains radiateurs ne respectent pas cette ordre "Arrêt" s’ils ne sont pas en mode "Programmation" et puis ça n'empêchera pas votre compteur de disjoncter si vous utilisez le four, une plancha, vos plaques de cuissons, ainsi qu’un aspirateur et quelques projecteurs de 1000 watts en même temps !</p>
<p>Aussi, ce boîtier qui commande les radiateurs n'est pas obligatoirement muni d'un capteur de température puisque chaque radiateur peut être réglé sur une température de confort (et parfois éco) qui de toute façon contrôlera ou non si le radiateur doit chauffer. En effet, l'usage du fil pilote sur un radiateur n'est pas obligatoire, le radiateur doit fonctionner même si le fil pilote n'est pas utilisé (auquel cas le mode programmation est équivalent au mode confort).</p>
<p>Exemple typique, s’il fait 30°C dans la pièce (plein été et vous venez de terminer une bonne raclette), que la température de confort demandée est de 21°C sur le radiateur, peu importe le mode du radiateur (éco, confort ou programmation) le radiateur ne chauffera pas !</p>
<p>C'est clair ? Alors passons à la pratique !</p>
<h1>Le RaspberryPi</h1>
<p>Le RaspberryPi est un mini ordinateur qui ne consomme pas beaucoup de courant, possède un connecteur GPIO (General Purpose Input Output - donc des entrées sorties contrôlables logiciellement). Bref, c’est une base mais il y a un petit détail qui a une grande importance :</p>
<p>Commander un signal en 230 volts avec un RaspberryPi ne peut pas se faire directement. En effet, un RaspberryPi a des sorties en 3 ou 5 volts et si on fait passer du 230 volts dedans, vous aurez au mieux cramé le pi, au pire un nouveau radiateur électrique (qui risque de ne pas fonctionner bien longtemps), bref vous avez compris, ce n'est pas fait pour.</p>
<h1>Carte de commande</h1>
<p>Alors pour contrôler du 230 volts, il faut une carte et des composants qui vont isoler la partie basse tension (les commandes en 0 / 5 volts du Raspberry Pi) avec le secteur.</p>
<p>Pour ce faire, on utilise un opto coupleur, qui d'un côté reçoit une tension en 0 ou 5 volts et de l'autre côté laisse, ou pas, passer la tension. En gros, c’est un interrupteur piloté en 5 volts.</p>
<p>Comme vu au-dessus, les 4 principaux ordres nécessitent de ne faire passer dans certains cas qu'une demi alternance. Pour régler ce problème, on utilise deux optocoupleurs (des MOC3041) et 2 diodes, ce qui donne le montage suivant.</p>
<p>Ainsi, si on alimente l'optocoupleur avec une tension de 5 volts par le Raspberry Pi, il devient passant et laisse passer la phase qui arrive sur une de ses bornes "haute tension". Ensuite la diode est reliée entre le fil pilote et l'optocoupleur et ne laisse passer qu'une demi alternance.<br />
Si on arrête d'alimenter l'optocoupleur, ce dernier ne laisse plus passer la tension et il n'y a donc plus la demi alternance.<br />
En utilisant ce même principe mais avec une diode dans l'autre sens, on peut laisser passer soit l'alternance positive, soit négative, soit l'alternance complète ou enfin rien.</p>
<p>Les composants utilisés sont détaillés un peu plus loin, le but ici était de réaliser un typon dont le choix précis des composants sur Fritzing n'avait pas d'importante, leur forme, position et boitier si :</p>
<p><img alt="" class="media" src="https://www.aplu.fr/v2/public/heapi/.heapi_schematics_m.png" style="margin: 0 auto; display: table;" /></p>
<p>Vous trouverez <a href="https://gitlab.com/mulx/heapi/-/tree/master/docs">ici les sources du projet</a> Fritzing, ce qui permet notamment de sortir le <a href="https://www.aplu.fr/v2/public/heapi/pcb.pdf">schéma typon</a> utilisé pour fabriquer la carte électronique.<br />
Je suis de mon côté passé par <a href="https://www.aercim.com/" hreflang="fr">AERCIM</a>, une entreprise Toulousaine qui fabrique les cartes (sans les composants), puis j'ai acheté et soudé l'ensemble des composants sur la carte à savoir :</p>
<ul>
<li>Un connecteur pour brancher le fil pilote et la phase ;</li>
<li>3 pins pour pouvoir brancher la carte avec le Raspberry Pi ;</li>
<li>2 MOC3041 ;</li>
<li>2 diodes 1N007 ;</li>
<li>2 résistances de 390 ohms.</li>
</ul>
<p>Ce qui donne ceci :</p>
<table align="center" border="0" cellpadding="1" cellspacing="1" style="width:100%;">
<tbody>
<tr>
<td><a class="media-link" href="https://www.aplu.fr/v2/public/heapi/carte_composants.jpg"><img alt="" class="media" src="https://www.aplu.fr/v2/public/heapi/.carte_composants_s.jpg" style="margin: 0 auto; display: table;" /></a></td>
<td><a class="media-link" href="https://www.aplu.fr/v2/public/heapi/carte_pistes.jpg"><img alt="" class="media" src="https://www.aplu.fr/v2/public/heapi/.carte_pistes_s.jpg" style="margin: 0 auto; display: table;" /></a></td>
</tr>
</tbody>
</table>
<p>On a donc en bas de la carte les connexions qui seront réalisées avec le Raspberry Pi et en haut (le truc rouge) ce qui permettra de connecter la phase et le fil pilote.</p>
<h1>Allez, on branche</h1>
<p>Pour le branchement sur le Raspberry Pi, on utilise le site <a href="https://pinout.xyz/" hreflang="en">https://pinout.xyz/</a> qui permet de savoir à quoi correspond chaque pin sur le RaspberryPi (masse, 5v permanent, 3v3 ou GPIO).</p>
<p>Ce qui nous intéresse, ce sont donc les GPIO et la masse (Ground), mais dans la toute simplicité on remarquera vite que le nom de la pin GPIO2 par exemple correspond physiquement à la position 3 tandis que la GPIO1 est sur la 28.</p>
<p>Pour l'exemple qui va suivre, on va brancher une carte sur les pin physiques 3 et 5 ainsi que la masse (pin 6 par exemple).</p>
<p>Pour des raisons pratiques, j’ai nommé avec un code couleur les pins sur la carte de commande, de gauche à droite sur la première photo : jaune, vert et noir (correspondant à la masse). Si vous cherchez une raison sur ces couleurs, ce sont les 2 premiers câbles de mon kit Arduino que j'avais sous la main au moment du test.</p>
<p>Ce qui nous donne donc ceci :</p>
<table align="center" border="1" cellpadding="1" cellspacing="1" height="108" width="500">
<tbody>
<tr>
<td>COULEUR</td>
<td>PIN PI</td>
<td>PIN SOFT</td>
</tr>
<tr>
<td>JAUNE</td>
<td>3</td>
<td>2</td>
</tr>
<tr>
<td>VERT</td>
<td>5</td>
<td>3</td>
</tr>
<tr>
<td>NOIR</td>
<td>6</td>
<td>
<p>N/A</p>
</td>
</tr>
</tbody>
</table>
<p>Ensuite, on utilise le programme bash <a href="https://gitlab.com/mulx/heapi/-/blob/master/gpio">présent ici</a> pour pouvoir contrôler la carte, pour ce premier test, les codes couleurs n'ont pas d'importance, ça viendra plus loin.</p>
<p>En envoyant les commandes suivantes on va activer un des MOC mais pas l'autre :</p>
<pre>
bash ./gpio mode 2 out
bash ./gpio mode 3 out
bash ./gpio write 2 1
bash ./gpio write 3 0</pre>
<p>Le fait que les 2 entrées des toutes mes cartes soient nommées jaune (yellow) et verte (green) permet derrière d'établir une table de vérité valable pour toutes les cartes qui est la suivante :</p>
<table align="center" border="1" cellpadding="1" cellspacing="1" style="width:500px;">
<tbody>
<tr>
<td>Mode</td>
<td>Yellow</td>
<td>Green</td>
</tr>
<tr>
<td>Confort</td>
<td>0</td>
<td>0</td>
</tr>
<tr>
<td>Arrêt/Stop</td>
<td>0</td>
<td>1</td>
</tr>
<tr>
<td>Frost</td>
<td>1</td>
<td>0</td>
</tr>
<tr>
<td>Éco</td>
<td>1</td>
<td>1</td>
</tr>
</tbody>
</table>
<p>Bon ça c’est un exemple, mais quitte à remplacer le boîtier de commande des radiateurs, pourquoi ne pas utiliser plusieurs cartes de commandes, chacune pour une zone/pièce (qui permet de commander un ou plusieurs radiateurs) ?!</p>
<p>Et puis, pourquoi ne pas faire un petit programme (en bash) pour ne pas avoir à taper à chaque fois les bonnes valeurs ?</p>
<h1>On voit les choses en grand !</h1>
<p>J'ai décidé que pour mon besoin j'allais utiliser 4 cartes, ce qui me permet d'avoir 4 zones (chaques zones peut avoir un ou plusieurs radiateurs) que je peux commander chacune comme je veux.</p>
<p>Histoire de faire ça proprement, on place tout ça dans une petite boite : 4 cartes de commandes, le RaspberryPi et l'ensemble des câbles pour tout connecter.<a class="media-link" href="https://www.aplu.fr/v2/public/heapi/install-box.jpg"><img alt="" class="media" src="https://www.aplu.fr/v2/public/heapi/.install-box_s.jpg" style="margin: 0 auto; display: table;" /></a></p>
<p>Avant de refermer j’ai utilisé un oscilloscope pour contrôler que chaque carte fonctionne comme prévu.</p>
<p><a class="media-link" href="https://www.aplu.fr/v2/public/heapi/test-basse-tension.jpg"><img alt="" class="media" src="https://www.aplu.fr/v2/public/heapi/.test-basse-tension_s.jpg" style="margin: 0 auto; display: table;" /></a></p>
<p>Dans ce montage, il manque une carte pour récupérer les informations du compteur EDF, principalement pour déclancher un délestage... et un fusible.</p>
<p>J’espère avoir la place pour ajouter la carte de délestage dans mon boîtier mais ce n’est pas dans mes priorités.</p>
<p>Pour le fusible, j’ai réalisé que j’aurais dû protéger les MOC par un fusible de faible intensité (une centaine milliampère) car clairement si pour une raison ou une autre, un des radiateurs court-circuite le fil pilote avec le neutre, je peux être sûr que ce seront les MOC qui vont cramer en premier en espérant que ça ne fasse pas de dégât plus grave.<br />
Bref, c’est donc prévu d'en ajouter un pour protéger l'ensemble des cartes, en attendant que je mesure la consommation, c’est branché sur un fusible de 2A du tableau électrique.</p>
<h1>Côté programmation</h1>
<p>Le code utilisé est entièrement disponible sur <a href="https://gitlab.com/mulx/heapi/">mon dépôt git</a>, et il y a plusieurs fichiers :</p>
<ul>
<li>heapi.sh - la seule commande à utiliser pour tout contrôler !</li>
<li>cards - le seul fichier à modifier pour faire correspondre aux branchements ;</li>
<li>crontab.example - un exemple d'une crontab pour commander ça de manière totalement automatique, on y vient ;</li>
<li>libheapi - un ensemble de fonction pour commander les cartes ;</li>
<li>gpio - la librairie vue plus haut qui permet de contrôler les sorties GPIO du RaspberryPi ;</li>
<li>Les autres ne sont pas utilisés ou contiennent uniquement de la documentation.</li>
</ul>
<h2>Le fichier cards</h2>
<p>C’est le seul fichier, avec la crontab, qu'il faut modifier au moins une fois.</p>
<p>Ce fichier contient la liste des cartes et fait la correspondance entre le nom de la carte la correspondance avec le GPIO. </p>
<p>Vous pouvez mettre n'importe quel nom pour les cartes, mais ce nom doit impérativement commencer par "card" et ne pas avoir d'espace et la première lettre en majuscule.</p>
<p>Ensuite pour chaque carte il faut définir les variables yellow et green avec la correspondance GPIO vue par le logiciel (donc pas le branchement physique).</p>
<p>Voici un extrait du fichier :</p>
<pre>
#/bin/bash
### IMPORTANT!
# All card must start by:
# card
# eg: cardMyStupidCard
###
#first card
cardSejour1 ()
{
yellow=2
green=3
}
#card 2
cardChambre ()
{
yellow=27
green=17
}
</pre>
<h2>Le fichier heapi.sh</h2>
<p>C’est votre boîtier de commande, si je peux dire ainsi.</p>
<p>Il s'utilise simplement, tout d'abord faut initialiser les sorties GPIO configurées dans le fichiers cartes, pour ça on va lancer la commande suivante :</p>
<pre>
bash ./heapi.sh init</pre>
<p>Cette commande doit être lancée après chaque redémarrage du RaspberryPi, on verra dans le fichier crontab comment cette problématique est traitée.<br />
Lorsque cette commande est lancée, tous les radiateurs sont automatiquement configurés en mode "hors gel".</p>
<p>Ensuite on peut utiliser la commande list pour lister l'ensemble des cartes configurées</p>
<pre>
bash ./heapi.sh list
chambre
sejour1</pre>
<p>Pour passer les radiateurs connectés à ma carte chambre en mode confort et ceux du séjour1 en mode éco ? Rien de plus simple :</p>
<pre>
bash ./heapi.sh chambre conf
bash ./heapi.sh sejour1 eco
</pre>
<p>Et enfin, si on souhaite savoir dans quel mode est le radiateur de la chambre, on utilise la commande suivante :</p>
<pre>
bash ./heapi.sh chambre stat</pre>
<p>Ce qui nous donne le résulat suivant :</p>
<pre>
Yellow: 'out 0'
Green: 'out 0'
mode: conf</pre>
<p>Et c’est tout ! Les noms des modes disponibles sont :</p>
<ul>
<li>conf pour confort ;</li>
<li>eco pour économique ;</li>
<li>frost pour hors-gel ;</li>
<li>stop pour arrêt.</li>
</ul>
<h2>Crontab ?</h2>
<p>La crontab est un fichier que l'on donne au logiciel crontab pour qu'il execute des commandes à certains moment précis (heure, jours, etc)</p>
<p>Pour la mettre en place vous pouvez recopier le fichier crontab.example et executer la commande suivante, en partant du principe que l'ensemble du logiciel heapi est installé dans le dossier /root).</p>
<pre>
cp /root/heapi/crontab.example /root/heapi/crontab
ln -s /root/heapi/crontab /etc/cron.d/heapi</pre>
<p>Pour le fonctionnement de la crontab, je ne vais pas expliquer en détail, allez voir la documentation qui est bien plus complète.</p>
<p>Je vais juste détailler l'exemple suivant :</p>
<pre>
# m h dom mon dow user command
@reboot root /root/heapi/heapi.sh init
40 22 * * * root /root/heapi/heapi.sh chambre conf
0 0 * * * root /root/heapi/heapi.sh chambre eco
0 5 * * * root /root/heapi/heapi.sh chambre conf
30 6 * * 1-5 root /root/heapi/heapi.sh chambre stop
30 8 * * 6,7 root /root/heapi/heapi.sh chambre stop
</pre>
<p>La ligne commançant par @reboot permet d'executer la commande init à chaque démarrage du raspberry Pi.</p>
<p>Ensuite, tous les jours à 22 heures 40, la zone chambre passe en mode confort, puis à minuit en mode éco jusqu’à 5 heures où on remet le mode confort. Enfin à 6 heures 30 du lundi au vendredi on éteint complètement le chauffage, sauf le samedi et dimanche où le chauffage reste actif jusqu'à 8 heures 30.</p>
<h1>Encore un peu plus de doc ?</h1>
<p>Le reste de la documentation est sur le git, c’est plus ou moins détaillé mais avec ce billet plus les documents présents vous devriez arriver à dupliquer ça chez vous !</p>
<p>Merci au blog <a href="https://telefab.fr/2013/11/10/controle-a-distance-des-radiateurs/">Téléfab</a> pour toute la partie carte et schéma et pour m'avoir donné l'idée d'aller plus loin et surtout au boîtier EJ 110T de Hager qui en tombant en panne et un boitier neuf afficher dans les 250 euros m'a bien motivé pour faire quelque chose de « mieux » !</p>
<p>En bonus quelques images.</p>
<figure style="margin: 0 auto; display: table;"><a class="media-link" href="https://www.aplu.fr/v2/public/heapi/test-bt2.jpg"><img alt="Test avec oscilloscope, nov. 2020" class="media" src="https://www.aplu.fr/v2/public/heapi/.test-bt2_s.jpg" /></a>
<figcaption>Test avec l'oscilloscope</figcaption>
</figure>
<figure style="margin: 0 auto; display: table;"><a class="media-link" href="https://www.aplu.fr/v2/public/heapi/in-action-alpha.jpg"><img alt="Version alpha du projet, nov. 2020" class="media" src="https://www.aplu.fr/v2/public/heapi/.in-action-alpha_s.jpg" /></a>
<figcaption>Version alpha du projet, directement branché sur les radiateurs !</figcaption>
</figure>
<figure style="margin: 0 auto; display: table;"><a class="media-link" href="https://www.aplu.fr/v2/public/heapi/box-closed.jpg"><img alt="Une fois la boite fermé, nov. 2020" class="media" src="https://www.aplu.fr/v2/public/heapi/.box-closed_s.jpg" /></a>
<figcaption>Une fois la boite fermé</figcaption>
</figure>Capteurs de température dans les salles de Tetaneutral.neturn:md5:13d8daa305c4228382e0ee8cee7347902020-07-11T11:56:00+02:002020-07-11T11:56:00+02:00APLUHardwaretempertemperaturetetaneutral.net <p>Depuis quelques jours, des courbes de température des 3 salles associatives de Tetaneutral (Myrys & TLS00) sont visibles sur un graphique ici : <a href="https://temper.aplu.fr/">https://temper.aplu.fr/</a> et les données peuvent être téléchargées en CSV.<br />
Cela vient compléter le capteur de température et d'humidité déjà présent à TLS00 depuis plusieurs années et qui est géré par Matthieu : <a href="https://herrb.eu/uthum">https://herrb.eu/uthum</a></p>
<h2>Les capteurs</h2>
<p><a class="media-link" href="https://www.aplu.fr/v2/public/usb-temper-photo.jpg"><img alt="" class="media" src="https://www.aplu.fr/v2/public/.usb-temper-photo_s.jpg" style="float: right; margin: 0 0 1em 1em;" /></a>Sur la partie technique, ces capteurs de type TEMPer sont intégrés dans des clefs USB, ces clefs USB sont vues comme des claviers par l'OS.</p>
<p>Elles fonctionnent donc "sans driver", le fabricant partant du principe que n'importe quel OS aura un driver pour gérer un clavier USB en natif.</p>
<p>Ensuite, le principe pour lire les données est d'utiliser un hack qui fonctionne sous Windows mais pas sous Linux (et sûrement pareil pour *BSD). En effet, pour lire les données, il suffit d'ouvrir Excel et de rester appuyer sur la touche "Ver maj" (Caps to Excel).</p>
<p>Sur les claviers, il y a un voyant indiquant l'état du verrouillage numérique et verrouillage majuscule. Ce voyant est géré entièrement par l'OS qui, lorsqu'il reçoit le signal correspondant d'un clavier, envoie un signal sur l'ensemble des claviers pour allumer la led associée. Ce n'est pas le clavier qui gère cet état, tous les claviers envoient simplement une indication de "touche enfoncée" "touche relâchée" (peu importe les touches).</p>
<p>Windows, lorsque l'on reste appuyer sur une de ces fameuses touches de verrouillage, envoie de manière répétitive l'indication au clavier d'allumer ce voyant (en fait Windows réagit de la même manière que lorsque l'on reste appuyer sur une autre touche, il fait de la répétition). Sous Linux ce n'est pas le cas, l'OS sait qu'il a déjà envoyé le signal et n'envoie donc pas le signal en permanence.</p>
<p>La clef USB détecte donc la présence de ce signal pour allumer le voyant lorsqu'il est envoyé plusieurs fois en de suite, le firmware dedans s'active et envoie les mêmes signaux qu'un clavier enverrait pour écrire du texte et vient donc taper, entre autres, la température.</p>
<p>À savoir : ça utilise encore quelques astuces d'Excel (qui fonctionnent aussi avec LibreOffice) pour "saisir" la date (par exemple si vous faites "ctrl+point- virgule") tout comme l'utilisation de la touche "tabulation" pour se déplacer d'une colonne à l'autre ou "entrée" pour passer d'une ligne à l'autre.</p>
<p>Bien sûr la clef n'a pas connaissance du type de clavier qui est configuré (QWERTY, AZERTY, etc) et partira du principe que le clavier est un US QWERTY.</p>
<p>Ces explications sont tirées de cette page wiki : <a href="https://github.com/edorfaus/keytemper/wiki/Direct-to-Excel">https://github.com/edorfaus/keytemper/wiki/Direct-to-Excel</a> (en anglais).</p>
<p>La bonne chose pour Linux est donc la présence de ce projet : <a href="https://github.com/edorfaus/TEMPered">https://github.com/edorfaus/TEMPered</a> qui est donc capable d'envoyer la séquence permettant d'activer la clef USB et de lire le retour pour en extraire les informations qui nous intéressent, à savoir la température.</p>
<p>Voici donc pour la partie clef USB.</p>
<h2>L'affichage sur un site web</h2>
<p>Pour la partie graphique et extraire des données en CSV, cela se fait en deux étapes.</p>
<ol>
<li>Un petit script exécuté à intervalle régulier vient lancer la commande permettant de lire la température, ajoute la date et envoie ça sur mon serveur ;</li>
<li>Côté serveur, les CSV reçus sont concaténés pour être mis à disposition du script php qui générera la page avec le javascript requis pour afficher les graphiques.</li>
</ol>
<p>À noter que toute cette partie a été faite initialement il y a plus de 7 ans à <a href="https://www.la-rache.com/presentation.html">"la-rache</a>" et n'a quasiment pas évolué depuis, donc s’il y a des personnes qui souhaitent améliorer la partie rendu, ne pas hésiter à me contacter qu'on en discute <img src="https://www.aplu.fr/v2/?pf=smile.svg" alt=":)" class="smiley" /></p>
<h2>Un peu de Docker</h2>
<p>Le projet permettant de lire les capteurs fonctionne bien sous Debian car les librairies sont disponibles mais pas sous Fedora.</p>
<p>On peut donc utiliser le Dockerfile (ou l'image directement) présente ici : <a href="https://hub.docker.com/r/aplu/tempered">https://hub.docker.com/r/aplu/tempered</a> pour utiliser une image Docker avec Debian.</p>
<p>En lancera ensuite la commande suivante pour récupérer la température (en partant du principe que la clef sera vue sur hidraw1 (le nom peut changer, vous trouverez le nom en executant la commande dmesg).</p>
<pre>
<span class="mx_MTextBody mx_EventTile_content"><span class="mx_EventTile_body" dir="auto">docker run -it --device=/dev/hidraw1 aplu/tempered </span></span></pre>
<p>Vous trouverez sur mon git ici <a href="https://gitlab.com/mulx/TEMPered/">https://gitlab.com/mulx/TEMPered/</a> l'ensemble des fichiers avec un docker-compose permettant de faire fonctionner ça de manière automatique avec docker.</p>
<p>Merci à Id2ndR pour la partie Docker :)</p>Les télécommandes infrarouge sous Linuxurn:md5:8b1203bc61d1d530136dd4e10ce353102020-01-01T15:15:00+01:002020-11-04T01:53:38+01:00Id2ndRHardwareinfrarougeLIRCmediacenter <h1>Les télécommandes infrarouge sous Linux</h1>
<p>Article mis-à-jour en différenciant les informations spécifiques à <span style="color:#27ae60;">Ubuntu 20.04 en vert</span>, et celles spécifiques à <span style="color:#ff8c00;">Ubuntu 18.04 en orange</span>;</p>
<h2>Historique</h2>
<p>Les télécommandes infrarouge étaient classiquement gérées par LIRC (Linux Infrared Remote Control) sous Linux pendant longtemps.</p>
<p>Depuis début 2016, on utilise plutôt libinput pour gérer tous les périphériques d'interface utilisateurs (clavier/souris etc) dont les télécommandes.</p>
<h2>Fonctionnement</h2>
<p>Avec un système récent et l'arrivée de libinput, les codes des télécommandes sont gérés directement dans le noyau. La table (keytable) est généralement chargé avec le pilote du récepteur (ou de la carte TV). Pour le vérifier :</p>
<pre>
$ dmesg | grep "IR keymap" -C5</pre>
<p>Le système est alors près à utiliser la télécommande.</p>
<h2>Utilisation / Configuration</h2>
<p>Sur les variantes de debian, il faut avoir installé le paquet <em>ir-keytable</em>. Sous les variantes de RedHat, il faut avoir installé le paquet <em>v4l-utils</em>.</p>
<p>Une fois la table de touche (keytable) identifiée au niveau noyau, le fichier /etc/rc_maps.cfg est lu, permettant de sélectionner le fichier de correspondance entre les codes infrarouge des touches, et les touches habituelles d'un clavier multimédia. Ce second fichier est situé dans un dossier rc_keymaps (/lib/udev/rc_keymaps sur Ubuntu).</p>
<h2>Débogguage</h2>
<p>Tout d'abord, s'assurer que lirc ne tourne pas avant toute opération, sinon il empêche la capture des événements :</p>
<pre>
$ sudo systemctl stop lircd.service lircd.socket</pre>
<p>Vérifier la configuration active, qui doit à minima retourner un périphérique infrarouge :</p>
<pre>
$ ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event1) with:
Name: Avermedia A835B(3835)
Driver: dvb_usb_af9035, table: rc-it913x-v2
Supported protocols: nec
Enabled protocols: nec
Extra capabilities: <access denied></pre>
<p>Ici, la table rc-it913x-v2 a été chargé par le noyau, ce qui se traduit par le chargement du fichier /lib/udev/rc_keymaps/it913x_v2 via la configuration /etc/rc_maps.cfg.<br />
Malheureusement dans mon cas les code des touches ne correspondent pas du tout à ceux qu'émet ma télécommande.</p>
<p>On va alors supprimer les codes enregistrés, et tester ceux envoyés par la télécommande</p>
<pre>
$ sudo ir-keytable -v -c
$ sudo ir-keytable -v -t
</pre>
<p>Les nouveaux codes sont à enregister dans un nouveau fichier de correspondance.</p>
<p>Pour vérifier si un fichier de correspondance adapté ou proche n'existerait pas déjà, chercher quelques codes émis par la télécommande (0x0516 dans l'exemple ci-dessous) :</p>
<pre>
$ grep '0x0516' /lib/udev/rc_keymaps/*</pre>
<p>Pour avoir une idée des correspondances possibles (liste complète <a href="https://github.com/torvalds/linux/blob/master/include/uapi/linux/input-event-codes.h">ici</a>) :</p>
<pre>
$ <span style="color:#ff8c00;">cut -d' ' -f2 /lib/udev/rc_keymaps/* | sort -u | sed /table/d</span>
$ <span style="color:#27ae60;">cut -d'"' -f2 /lib/udev/rc_keymaps/* | grep KEY | sort -u</span>
</pre>
<p>Une fois créé, charger le fichier (ici avec le fichier <span style="color:#ff8c00;">avermedia-rm-hv.rc</span> ou <span style="color:#27ae60;">avermedia-rm-hv.toml</span> pour l'exemple), puis tester les touches :</p>
<pre>
$ fichier_correspondance=avermedia-rm-hv.toml
$ sudo ir-keytable -v -c -w ${fichier_correspondance}
$ sudo ir-keytable -v -t</pre>
<p>Une fois satisfait de la table, il faut la faire charger à chaque démarrage, à la place de l'ancienne table :</p>
<pre>
$ sudo cp ${fichier_correspondance} /etc/rc_keymaps/
$ table_par_defaut=$(ir-keytable 2>&1 | grep -E '(table|Default keymap)' | awk '{print $NF}')
$ sudo sed -i -re /${table_par_defaut}/s:[[:alnum:]_]+\$:${fichier_correspondance}: /etc/rc_maps.cfg</pre>
<h3>Agancement du clavier</h3>
<p>Une particularité avec les KEY_0 à KEY_9 est qu'elle correspondent aux touches au dessus de la zone des lettres sur un clavier. Aussi sur un clavier avec agancement qwerty, ce sont les chiffres, mais sur un clavier azerty, il s'agit de caractère de ponctuation/accent etc.</p>
<p>Une solution à ce problème est d'utiliser KEY_NUMERIC_0 à KEY_NUMERIC_9 à la place.</p>
<h2>Utilisation avec Kodi</h2>
<p>Kodi s'appui toujours sur LIRC pour exploiter pleinement les télécommandes. En effet, sans LIRC, Kodi exploitera les touches comme un clavier multimédia, ce qui fonctionnera pour les flêches de direction et le volume, mais pas pour la fonction retour/quitter par exemple, car elle n'existe pas sur un clavier.</p>
<p>Démarrer lirc et vérifier les informations que ce dernier renvoit, en essayant quelques touches :</p>
<pre>
$ sudo systemctl start lircd
$ irw
000000008001006a 00 KEY_RIGHT devinput-32
000000008001006a 01 KEY_RIGHT devinput-32
</pre>
<p>Bien noter le nom du périphérique renvoyé par lirc, dans mon cas <strong>devinput-32</strong>. C'est le périphérique pour lequel la correspondance des fonctions doit être faite dans Kodi. Cette correspondance est dans le fichier <em>/usr/share/kodi/system/Lircmap.xml</em>.</p>
<p>Si les touches renvoyées par libinput à travers lirc ne correspondent pas à une fonction dans Kodi, il est possible d'en rajouter ou de les modifier en surchargeant la configuration avec le fichier <em>.kodi/userdata/Lircmap.xml</em>. Dans mon cas, j'ai rajouté la fonction retour à la touche correspondante, ainsi que le retour à l'accueil ; voici mon fichier :</p>
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<lircmap>
<remote device="devinput-32">
<start>KEY_HOME</start>
<back>KEY_BACK</back>
</remote>
</lircmap>
</pre>
<p>Pour prendre en compte ces changements, il faut redémarrer Kodi.</p>
<h2>Ressources complémentaires</h2>
<ul>
<li>Débogguage bas niveau de l'infrarouge: <a href="https://sigmdel.ca/michel/ha/opi/ir_01_fr.html">https://sigmdel.ca/michel/ha/opi/ir_01_fr.html</a></li>
<li><a href="http://lirc.org/html/devinput.html">http://lirc.org/html/devinput.html</a></li>
<li>Fonctionnement libinput puis lirc : <a href="http://www.lirc.org/html/configuration-guide.html#key-symbols-using-linux-input-layer">http://www.lirc.org/html/configuration-guide.html</a></li>
<li>Configuration irkeytable sous Ubuntu : <a href="https://doc.ubuntu-fr.org/irkeytable">https://doc.ubuntu-fr.org/irkeytable</a></li>
<li>Configuration LIRC pour Kodi : <a href="https://kodi.wiki/view/LIRC">https://kodi.wiki/view/LIRC</a></li>
</ul>Kodi, le média-center polyvalenturn:md5:6f6647cc2840bb4996732402dea5c1452019-12-22T20:37:00+01:002020-05-03T10:37:41+02:00Id2ndRmediacenterkodimediacenter <h1>Kodi mediacenter</h1>
<h2>Présentation</h2>
<p><a href="https://kodi.tv/">Kodi</a> est un logiciel médiacenter : il essaye de lire tous les médias, locaux ou distant</p>
<p>Voici quelques possibilités permises par Kodi :</p>
<ul>
<li>gestion des collections de musiques, films, images</li>
<li>lecture des sources Internet (exemples : youtube, allociné, etc)</li>
<li>lecture et synchronisation avec une médiathèque (exemples : <a href="https://jellyfin.org/">Jellyfin</a> ou Plex)</li>
<li>pilotage par différents terminaux : clavier/souris, appli smartphone, navigateur web, télécommande infra-rouge ou bluetooth</li>
<li>extensible au travers de nombreuses extensions</li>
<li>etc</li>
</ul>
<div class="postmsg">
<p>Kodi 18 est sortie en 2019 et support le décodage matériel des vidéos (suivant la plateforme), le support des DRM (permettant la lecture de certains flux protégés, tel que 6play par exemple).</p>
<h2>Installation</h2>
<p>Kodi existe en tant que logiciel pour différente plateforme (Linux, Windows, Android, etc) : c'est la façon la plus rapide de l'essayer.</p>
<p>Il est également possible de l'installer sur un matériel dédié à l'usage média-center, comme par exemple un appareil branché à une TV et/ou un home-cinéma. Les raspberry-pi sont font partis des équipements les moins chers pour un tel usage. A partir du Raspberry-pi 4, il devient possible de profiter du décodage matériel des vidéos encodé en HEVC/x265.<br />
Il existe une distribution dédié, permettant l'installation facile de Kodi : <a href="https://libreelec.tv/">libreelec</a>.</p>
<h2>Utilisation</h2>
<p>Suivant votre installation de Kodi, lancer simplement le logiciel, ou utiliser une périphérique associé à votre matériel.</p>
<h3>Utilisation via un smartphone</h3>
<p>Pour piloter Kodi à partir de son smartphone, activer l'accès à distance dans Kodi</p>
<p>Paramètre > Contrôle > Accès distant via HTTP.</p>
<p><a class="media-link" href="https://www.aplu.fr/v2/public/id2ndr/SettingsServicesControl-leia.jpg"><img alt="" class="media" src="https://www.aplu.fr/v2/public/id2ndr/SettingsServicesControl-leia.jpg" style="margin: 0px auto; display: table; width: 465px; height: 300px;" /></a></p>
<p>Installer l'application Kore sur votre téléphone. Enfin, connecter son téléphone à votre Wi-Fi, et rechercher Kodi sur le réseau.</p>
</div>Wileyfox - mise à jour vers LineageOS 15.1 et 16urn:md5:a8494d75dbc35d611090eb118fdfe8c42019-09-13T13:37:00+02:002019-10-07T14:33:36+02:00APLUandroidandroidlineageosSwiftTWRPwileyfox <p>Avant de commencer, il important d’effectuer une sauvegarde de vos données, vous pouvez tout perdre (surtout que nous sommes un vendredi 13 !).</p>
<p>À titre d’information lors de ma migration de LineageOS 14.1 vers 15.1 je n’ai rien perdu (sauf ma carte SD mais ça n’a aucun rapport, elle avait déjà des signes de faiblesses avant), pas plus qu’avec la migration vers LineageOS 16 mais je ne vous conseille pas de jouer avec le feu.</p>
<h2>Petit rappel de base</h2>
<p>Sur votre téléphone, il y a 3 niveaux de démarrage:</p>
<ul>
<li>Le mode fastboot, c’est un mode bas niveau qui permet de mettre à jour assez arbitrairement pas mal de choses sans trop de vérification ;</li>
<li>Le mode recovery, c’est un système léger qui permet de mettre à jour le système Android installé à côté ;</li>
<li>Le système Android qui vous sert à jouer et téléphoner.</li>
</ul>
<p>Habituellement, lors des mises à jour, on n’utilise que le mode recovery pour mettre à jour Android.</p>
<p>Vous pouvez avoir le système Android complètement cassé, si vous avez le recovery, c’est récupérable. Vous pouvez avoir le recovery complètement mort mais continuer à utiliser votre téléphone.</p>
<p>Les étapes de démarrage du téléphone ensuite sont : chargement du bootloader, puis activation d’un des modes.</p>
<p>Les étapes ci-dessous ne peuvent pas être réalisées si vous ne possédez par un ordinateur pour effectuer les manipulations.</p>
<h2>Mise à jour du bootloader</h2>
<p>Si comme moi vous avez un téléphone qui n’a pas reçu les mises à jour de CyanogenOS avant sa mort, il va falloir d’abord mettre à jour le bootloader du téléphone pour supporter une nouvelle version du recovery.</p>
<p>Cela ne signifie pas que mon téléphone n’est pas à jour, simplement les micrologiciels n’ont pas reçu les dernières mises à jour de l’éditeur.</p>
<p>Pour effectuer la mise à jour, il faut passer le téléphone en mode fastboot. Depuis un système android déjà actif. Le plus simple est de lancer la commande</p>
<pre>
adb reboot fastboot</pre>
<p>Sinon il faut éteindre le téléphone et allumer en appuyant simultanément sur le bouton volume up et power.</p>
<h3>Est-ce que je dois faire la mise à jour ?</h3>
<p>La manière la plus simple et de regarder l’écran du téléphone lorsqu’il est en fastboot (voir le paragraphe au dessus).</p>
<p>Si l’écran ressemble à ça :</p>
<p><a class="media-link" href="https://www.aplu.fr/v2/public/android/fastboot_old.png"><img alt="" class="media" src="https://www.aplu.fr/v2/public/android/.fastboot_old_s.png" style="margin: 0 auto; display: table;" /></a></p>
<p><strong>Vous devez faire la mise à jour !</strong></p>
<p>Si l’écran ressemble à ça :</p>
<p><a class="media-link" href="https://www.aplu.fr/v2/public/android/fastboot_new.png"><img alt="" class="media" src="https://www.aplu.fr/v2/public/android/.fastboot_new_s.png" style="margin: 0 auto; display: table;" /></a></p>
<p>Pas besoin de faire la mise à jour, tout va bien, passez directement à l’étape suivante (installer TWRP).</p>
<h3>Installer la nouvelle version du bootloader</h3>
<p>Sur votre PC, il faut récupérer le <a href="https://www.aplu.fr/files/android/radio-20161215-crackling.zip">fichier suivant</a> qui contient l’ensemble des fichiers requis pour la mise à jour.</p>
<p>Ces fichiers se trouvent aussi dans <a href="https://www.aplu.fr/files/android/CyanogenOS/cm-13.1.2-ZNH2KAS3LG-crackling-signed-42f2b8e414.zip">l’image dans l’image officielle de CyanogenOS 13.x disponible ici</a> (ou sur d’autres sites similaire) mais pour plus de simplicité seuls les fichiers utiles sont extraits.</p>
<p>Ensuite, branchez le téléphone au PC et effectuez les commandes suivantes :</p>
<pre>
fastboot flash aboot emmc_appsboot.mbn
fastboot flash rpm rpm.mbn
fastboot flash tz tz.mbn
fastboot flash hyp hyp.mbn
fastboot flash modem NON-HLOS.bin
fastboot flash sbl1 sbl1.mbn
fastboot flash splash splash.img
fastboot reboot bootloader
</pre>
<h2>Mise à jour du recovery - Mise à jour de TWRP</h2>
<p>Une fois le bootloader mis à jour, on va procéder à la mise à jour du recovery, ce qui permettra d’installer les nouvelles versions d’Android.</p>
<p>Pour ce faire, on récupère la dernière image <a href="https://eu.dl.twrp.me/crackling/">TWRP sur leur site</a>, à cette date j’utilise la version 3.2.3-0.</p>
<p>Et on exécute la commande suivante pour l’installer sur le téléphone.</p>
<pre>
fastboot flash recovery twrp-3.2.3-0.img</pre>
<h2>Installation de la nouvelle version d’Android</h2>
<p>Ensuite la mise à jour s’effectue traditionnellement, on télécharge le fichier zip avec la mise à jour et on l’installe.</p>
<p>Je vous renvoie <a class="ref-post" href="https://www.aplu.fr/v2/post/2017/04/04/lineageos-sur-wileyfox-swift">vers le billet précédent pour la suite de la procédure</a>.</p>
<p>Pensez à prendre les versions récentes de LineageOS :-)</p>Un kernel tout neuf pour l’Odroid-C1 !urn:md5:bda113f5d851a5ad78fd93f8601e962b2019-04-29T14:33:00+02:002019-05-08T20:56:49+02:00APLUsysadminC1hardkernelkernellinuxodroid <p>Pour ceux qui ne le savent pas, je suis l’heureux possesseur d’une carte ARM nommée Odroid-C1. Cette carte a été fabriquée autour de 2014/2015 par Hardkernel.</p>
<p>La version du noyau fourni avec la carte est 3.10, avec énormément de patchs "made by hardkernel" pour que tout fonctionne bien. Seulement, depuis bientôt deux ans, il n’y a plus de mise à jour et déjà les mises à jour à l’époque n’étaient pas fréquentes et ne suivaient pas vraiment les patchs de sécurité.</p>
<p>Bref, j’ai donc décidé qu’il était temps d’essayer d’avoir une nouvelle version du kernel pour cette carte.</p>
<p>Le support de cette carte par la version principale de Linux (mainline) existe grace au projet communautaire Linux for Amlogic Meson (<a href="http://linux-meson.com/doku.php)">http://linux-meson.com/doku.php</a>). Il a débuté fin 2015 avec ce patch (<a href="https://github.com/torvalds/linux/commit/4a69fcd3a10803854852481ab16031563d2d5381">https://github.com/torvalds/linux/commit/4a69fcd3a10803854852481ab16031563d2d5381</a>) qui a atterri dans la version 4.4 de Linux.</p>
<h2>Avant de commencer</h2>
<p>Je n’ai pas fait un test complet de la carte, il est donc possible que certaines choses ne fonctionnent pas correctement ou moins bien qu’avec le kernel d’origine.</p>
<p>Ce billet s’adresse à des personnes qui ont des bonnes connaissances de Linux et de son fonctionnement, il ne s’agit pas d’un tutoriel à appliquer tel que mais il doit être adapté pour votre cas (et carte).</p>
<h2>Support matériel</h2>
<p>La puce principale du C1 est un Amlogic S805, comme indiquée ici : <a href="https://wiki.odroid.com/odroid-c1/hardware/hardware">https://wiki.odroid.com/odroid-c1/hardware/hardware</a>.</p>
<p>Le tableau de la page <a href="http://linux-meson.com/doku.php">http://linux-meson.com/doku.php</a> nous donne le support de cette puce.</p>
<p>Attention, lors de l'écriture de ce billet, la sortie HDMI n'est pas supportée ! Ce nouveau noyau ne vous sera donc utile que si vous avez un usage sans écran (headless).</p>
<h2>Solution rapide</h2>
<p>Récupérer les fichiers sur le dépôt <a href="https://gitlab.com/mulx/kernel-odroidc1/" title="OdroidC1 - Kernel">git suivant</a> et sauter directement à la partie "installation".</p>
<p>Dans cette archive, vous trouverez le fichier uImage (le kernel) et les modules.</p>
<h2>Préparation - Compilation</h2>
<p>Avant tout, il faut préparer l’environnement de compilation, car on ne va pas compiler sur la carte ARM, ça serait bien trop long et ça risque de cramer la carte SD (même si on peut utiliser un disque usb pour éviter ça).</p>
<p>On va donc réaliser une cross-compilation depuis un PC, pour ce cas, je pars du principe que vous êtes avec une Debian Stretch, si ce n’est pas le cas, désolé <img src="https://www.aplu.fr/v2/?pf=smile.svg" alt=":)" class="smiley" /></p>
<p>D’abord, il faut installer les paquets requis pour les différentes étapes</p>
<pre>
apt install gcc-arm-linux-gnueabihf build-essential flex bison libssl-dev bc u-boot-tools ccache fakeroot ncurses-devel libncurses-dev lzop gcc-arm-none-eabi git</pre>
<p>Ensuite, on récupère la version stable de Linux (actuellement la version 5)</p>
<pre>
mkdir $HOME/compile
cd $HOME/compile
git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git -b linux-5.0.y linux
cd linux</pre>
<p>La version 5.0 n’est pas une version avec un support à long terme, il faudra donc suivre les évolutions jusqu’à "tomber" sur une version dite LTS.</p>
<p>Avant tout, quelques variables d'environnement sont à définir</p>
<pre>
export PATH=/usr/lib/ccache:$PATH
export CROSS_COMPILE=arm-linux-gnueabihf-
export LOADADDR=0x00208000
export ARCH=arm
export INSTALL_MOD_PATH=$HOME/compile/linux-modules/</pre>
<p>La liste des options à activer pour avoir un kernel fonctionnel, voici le <a href="https://gitlab.com/mulx/kernel-odroidc1/blob/master/config" title="config">fichier « config »</a> à placer dans le dossier à la racine des sources, il faut le nommer ".config".</p>
<p>Vous pouvez sélectionner et modifier les options en faisant make menuconfig. Dans la config proposée ici, la plupart des options du kernel sont configurées en mode "module" afin de faire une image assez petite tout en proposant une configuration qui permettrait de brancher une clef tv en usb ou une carte wifi sans problème sur la carte odroid.</p>
<p>Une fois les options définies, il faut générer l’image ainsi que les fichiers dit "device tree" et bien sûr, les modules.</p>
<pre>
make -j4 uImage dtbs modules</pre>
<p>Je passe l’option j4 car j’ai un PC avec 4 cœurs ce qui permet d’accélerer le temps de compilation.</p>
<p>Une fois la compilation effectuée, on va faire</p>
<pre>
make modules_install</pre>
<p>Et maintenant il ne reste plus qu’à copier les fichiers sur la carte odroid.</p>
<p>Les fichiers dont on va avoir besoin dans la compilation qu'on a effectuée sont :</p>
<ul>
<li>Le fichier « DTB », située ici : <em>arch/arm/boot/dts/meson8b-odroidc1.dtb </em></li>
<li>L’image du noyaux, située ici : <em>arch/arm/boot/uImage</em></li>
<li>les modules dans, située dans : <em>arch/arm/lib/modules </em>(ainsi que dans <em>$INSTALL_MOD_PATH</em>)</li>
</ul>
<h2>Installation</h2>
<p>Si vous prenez les fichiers présents sur le git ou ceux de la compilation, l’installation est identique.</p>
<p>Les opérations de copie de fichiers (modules, kernel et DTB) peuvent être faite en branchant la carte SD sur un PC, ou depuis le C1 via le réseau ou une clef usb. La génération de l'initramfs doit elle être faite dans l'environnement cible, c'est-à-dire sur le C1. Elle nécessite un OS Debian ou Ubuntu sur le C1.</p>
<p>Dans le doute, faites les opérations depuis le C1, afin que les chemins correspondent à ceux de ce billet.</p>
<h3>Les modules</h3>
<p>On copie les fichiers des modules dans /lib/modules/ (si vous avez fait une compilation vous-mêmes ils sont dans : $INSTALL_MOD_PATH, sinon ils sont dans le répertoire <em>lib/modules</em> sur le git).</p>
<h3>Le kernel, l’initramfs et le DTB</h3>
<p>Le kernel est le fichier nommé <em>uImage</em> et le DTB <em>meson8b-odroidc1.dtb</em>, ces deux fichiers sont à copier dans le répertoire de boot de votre carte (en général /boot ou /media/boot).</p>
<p>Par souci de version, j’ajoute au fichier uImage le numéro de version (exemple uImage-3.10.148)</p>
<h4>Génération de l’initramfs</h4>
<p><span class="author-a-5z122zz73zaz70zjz68zvqqc6z90zz76zz83z0 i">Important, cette opération doit être faite depuis le C1 !</span></p>
<p>Pour générer l’initramfs, on utilise les commandes suivantes :</p>
<pre>
VERSION=5.0.10
update-initramfs -c -k $VERSION
mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n uInitrd -d /boot/initrd.img-$VERSION /boot/uInitrd-$VERSION
</pre>
<h3>Le boot.ini</h3>
<p>Il reste ensuite à modifier le fichier boot.ini pour démarrer sur notre nouveau noyau.</p>
<p>Les seules modifications absolument nécessaires au boot.ini par rapport au boot.ini fourni par la version ubuntu-minimal de hardkernel sont les 3 lignes fatload.</p>
<p>Si vous avez des doutes, vous <a href="https://gitlab.com/mulx/kernel-odroidc1/blob/master/boot/boot.ini" title="boot.ini">pouvez prendre celui-là</a> comme exemple.</p>
<p>Pour utiliser le boot.ini qui est en exemple, il faut récupérer l’UUID de votre partition système (rootdev plus loin), pour ça on peut utiliser la commande suivante :</p>
<pre>
blkid $(mount | awk '/ \/ /{print$1}')</pre>
<p>Il faut modifier les deux variables suivante pour correspondre aux informations de votre carte.</p>
<pre>
ethaddr
rootdev</pre>
<p>Il faut aussi changer vers la fin du fichier les noms des fichiers uImage et uInitrd.</p>
<pre>
fatload mmc 0:1 0x21000000 uImage-5.0.10
fatload mmc 0:1 0x22000000 uInitrd-5.0.10
#fatload mmc 0:1 0x21800000 meson8b_odroidc.dtb
fatload mmc 0:1 0x21800000 meson8b-odroidc1.dtb
</pre>
<h3>Post-conf (network)</h3>
<p>Pour une raison inconnue, définir l’adresse MAC de la carte réseau dans le boot.ini ne suffit pas, il faut aussi la définir dans le fichier de configuration <em>/etc/network/interfaces.</em></p>
<p>Il y a aussi un problème de stabilité si on laisse la carte réseau en gigabit, je force donc la carte en 100Mbit full duplex (merci <a href="http://rglinuxtech.com/?p=1831" hreflang="en" title="ARM64 – Odroid C2 – Hack to Fix Ethernet Hangs..">Adventures with Linux</a>).</p>
<pre>
iface eth0 inet dhcp
hwaddress ether 00:1e:06:cb:e2:4d
up ethtool -s $IFACE speed 100 duplex full autoneg off </pre>
<p>Si vous utiliser NetworkManager il faudra faire les modifications dans NetworkManager.</p>
<p>Sur Ubuntu, NetworkManager est installé, et remplace ifupdown.<br />
Cependant, en héritant de la conf dans /etc/network/interfaces.d/eth0 en lecture seule, il n'est pas capable de positionner l'adressse Mac de l'interface.</p>
<p>De plus, une fois l'interface active, il n'est pas possible de changer son adresse... or vous êtes connecté à l'odroid via le réseau en ssh ! La solution consiste a ajouter le paquet ifupdown : <em>apt install ifupdown</em>.</p>
<p>Après le redémarrage, la commande ifup sera lancée par le service networking, et l'adresse Mac sera positionnée en accord avec le fichier /etc/network/interfaces.d/eth0.</p>
<p>L'autre solution (non testée) aurait été une gestion complète via NetworkManager, en supprimant le fichier /<em>etc/network/interfaces.d/eth0</em> et en une ligne <em>mac-address</em> dans la section <em>[Ethernet]</em> du fichier <em>/etc/NetworkManager/system-connections/ethernet-eth0</em>.</p>
<h2>Il manque un module pour chez moi !</h2>
<p>Si vous avez besoin de modules ou d’option pour le noyaux qui ne sont pas disponible dans le binaire mis à disposition, merci d’ouvrir un ticket sur le <a href="https://gitlab.com/mulx/kernel-odroidc1/issues">gitlab.</a></p>
<h2>Ressources complémentaires</h2>
<ul>
<li>Compilations et tests automatisée de différents noyaux pour le C1 : <a href="https://kernelci.org/boot/meson8b-odroidc1/">https://kernelci.org/boot/meson8b-odroidc1/</a></li>
<li>Guide complet pour compiler un nouveau noyau sur ARM : <a href="https://github.com/umiddelb/armhf/wiki/How-To-compile-a-custom-Linux-kernel-for-your-ARM-device">https://github.com/umiddelb/armhf/wiki/How-To-compile-a-custom-Linux-kernel-for-your-ARM-device</a></li>
<li>Le wiki officiel : <a href="https://wiki.odroid.com/odroid-c1/odroid-c1">https://wiki.odroid.com/odroid-c1/odroid-c1</a></li>
<li>Le forum Odroid : <a href="https://forum.odroid.com/viewforum.php?f=111">https://forum.odroid.com/viewforum.php?f=111</a></li>
</ul>
<h2>Remerciement</h2>
<p>Merci à Id2ndR pour les remarques et amélioration de l’article.</p>
<p>Merci à Meriem pour les relectures :)</p>Les problèmes d'alimentation ou d'affichage du raspberry-piurn:md5:b76c58f0a42d01a053255f43f6b73fae2019-02-17T11:18:00+01:002020-11-04T01:53:03+01:00Id2ndRHardwareraspberrypi <h2>Problème d'interférence</h2>
<p>Ici on est dans un cas fréquent, référencé <a href="https://elinux.org/R-Pi_Troubleshooting#Interference_visible_on_a_HDMI_or_DVI_monitor" moz-do-not-send="true">ici</a> (capture d'écran avec les pixels verts).<br />
Ma solution a été de réduire la bande passante nécessaire sur le cable HDMI. Je suis passé à une résolution FullHD (1080p) mais à une fréquence de 30Hz au lieu des 60Hz par défaut, et le phénomène a disparu.<br />
Autre piste (en anglais) <a href="https://howtoraspberrypi.com/raspberry-pi-hdmi-not-working/" moz-do-not-send="true">ici</a>.</p>
<p>Il faut également dans la mesure du possible :<br />
- tester différent cable hdmi, en privilégiant ceux qui sont plus court<br />
- en parallèle, augmenter le niveau du signal hdmi, comme indiqué sur le cas plus haut : j'ai passé config_hdmi_boost=8 dans le fichier config.txt de la première partition de la caste microSD. Je précise qu'avec tout à l'identique, mais un rpi2b au lieu du rpi3b+, je n'avais pas de problème. Je n'ai pas monté la valeur au delà de 9, ne constatant pas vraiment d'impact.<br />
- tester avec différentes alimentations</p>
<p>D'autres réglages d'affichage ne m'ont pas aidés. Au final j'ai conservé les réglages par défaut : activer la <i>Synchronisation lecture et affichage</i> ; et <i>ne pas adapter la fréquence de rafraîchissement à la vidéo</i>.</p>
<h2>Problème d'image qui disparait pendant quelques secondes</h2>
<p>Une fois les interférences réglées (par le passage à 30Hz), il restait un problème qui rendait l'expérience média-center très frustrante : l'image pouvait sauter quelques secondes par moment.</p>
<p>Pour diagnostiquer le problème, il faut essayer de corréler les événements. Dans mon cas, ce qui m'a mit la puce à l'oreille est le fait que ça coupe lorsque que je commençais à naviguer dans les menus du médiacenter Kodi. Généralement, lorsque j’interagissais pas avec Kodi, ça coupait quasiment pas.</p>
<p>Il faut tester différentes alimentations, pour vérifier qu'on n'a pas l'éclair qui apparait à l'écran avec une des alimentations (indiquant un problème de puissance d'alimentation). J'ai fini par acheter l'alimentation officielle RaspberryPi, qui est, comme on peut le lire sur Internet un peu partout, de bien meilleure qualité que bien d'autres, et ce même avec une puissance de 2,5A max. Avec elle, plus de crainte possible.</p>
<p>La confirmation du diagnostique : par une connexion SSH.<br />
En se connectant en ssh, il est possible de faire chauffer le raspberry pi, en occupant le CPU de celui ci. La carte est équipée de 4 cœurs, alors on peut progressivement les "charger" 1 par 1. L'astuce est toute simple : lancer une boucle infinie dans un shell. Pour celà, on se connecter en ssh (login/pass dépendant du système que vous avez choisi), et on lance la boucle suivante :</p>
<pre>
while true; do : ; done</pre>
<p>L'objectif est alors de constater si les coupures d'affichage apparaissent plus souvent. En montant à 3 cœurs chargés, l'image n'apparaissait que très rarement => le diagnostique était établi : la carte chauffait trop !</p>
<p>La solution a été de brancher le petit ventilateur de mon boitier (en 3,3V ça suffit, soit les pin 1 et 6 sur ce schéma disponible à <a class="moz-txt-link-freetext" href="https://pinout.xyz/pinout/pin1_3v3_power#" moz-do-not-send="true">https://pinout.xyz/pinout/pin1_3v3_power#</a>). Le problème a disparu instantanément.</p>
<h2>Problème avec un périphérique USB</h2>
<p>Je reçois la TNT à travers un tuner USB. Mais certaines chaines ne fonctionnaient pas correctement voir pas du tout.<br />
Le diagnostique a été très difficile à établir. Il faut d'abord commencer par se renseigner sur les fréquences de la TNT chez soi (voir <a href="https://www.csa.fr/matnt/couverture" moz-do-not-send="true">ici</a>), simplifier au maximum les branchements (s'il y a des T ou autres).<br />
Enfin, on va profiter de TV headend, qui nous indique le niveau de signal, et le SNR. Mon diagnostique a été l'observation des variations sur ces 2 indicateurs : le tuner arrivait à accrocher le signal (le niveau SNR passait alors de 0 à près de 20dB), mais trop peu de temps (maximum 2 secondes, et des coupures systématiques plus ou moins longues après) : celà ne permet pas le décodage du flux vidéo qui nécessite une accroche sur 5 à 10 secondes pour être stable (dépendant du délai entre les trames I, voir explications <a href="https://fr.wikipedia.org/wiki/Compression_vid%C3%A9o#Fonctionnalit%C3%A9s_de_MPEG-1" title="ici">ici</a>).<br />
Ceci traduit un problème d'alimentation du tuner, l’empêchant de faire correctement son travail. Le passage à l'alimentation officielle du raspberry pi a ainsi résolu le problème.<br />
L'autre diagnostique possible aurait été de brancher le tuner sur un ordinateur et de comparer la réception à l'aide de ce dernier.</p>Activer le Wake-on-WiFi (WoWLAN) sous Linuxurn:md5:18795643abb11020ddb9dd9058d485e62017-12-21T21:12:00+01:002017-12-25T12:33:39+01:00APLUHardwarewakeonlanWiFiWoWLAN <p>Cet article est fortement inspiré de ce billet de <a href="https://www.cyberciti.biz/faq/configure-wireless-wake-on-lan-for-linux-wifi-wowlan-card/" hreflang="en">nixCraft</a>, qui explique comment activer le Wake-on-LAN mais <em>via</em> la carte WiFi (ou Wake-on-WLAN) sous Linux.</p>
<h2>Le Wake-on-LAN c’est quoi ?</h2>
<p>Le terme anglais est assez explicite de lui-même, cela permet de réveiller un ordinateur (PC fixe, portables, serveurs, etc) <em>via</em> le réseau.</p>
<p>Le fonctionnement est simple : la carte réseau reste active même lorsque le PC est éteint, lorsque plusieurs paquets particuliers (nommés magic-paquet) sont reçus, cela déclenche un réveil de la machine (sortie veille ou allumage). Cela fonctionne quel que soit le système d’exploitation et il faut simplement être sur le même réseau (donc non, vous ne pouvez pas réveiller la machine de votre voisin avec cette technique).</p>
<p>La commande pour initier le réveil <em>via</em> Linux est <em>wakeonlan</em> et l’utilisation est très simple :</p>
<pre>
wakeonlan 40:16:7E:6E:70:D3</pre>
<p>Le <em>40:16:7E:6E:70:D3 </em>correspond à l’adresse MAC de la carte réseau.</p>
<h2>Et le Wake-on-WiFi (ou WoWLAN) ?</h2>
<p>C’est le même principe mais <em>via</em> le WiFi et ce n’est pas activé par défaut.</p>
<p>Et contrairement au réseau filaire, où la carte n’est que dans un état passif, ici la carte doit rester connectée au point d’accès et toutes les cartes ne sont pas compatibles avec ce fonctionnement (et cela consomme aussi de facto plus d’énergie).</p>
<h3>Identifier la carte WiFi</h3>
<p>Dans un premier temps, il faut identifier la carte physique qui gère le WiFi. Pour ce faire, on utilise la commande <em>iw dev</em> :</p>
<pre>
# iw dev
phy#2
Interface wlan0
ifindex 85
wdev 0x200000001
addr ac:72:89:c8:8e:3f
type managed
channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
txpower 15.00 dBm</pre>
<p>Ici, on obtient le nom physique de l’interface, <em>phy2</em>.</p>
<h3>Vérifier l’état de la carte</h3>
<p>Ensuite, on va vérifier l’état de la carte avec la commande ci-dessous :</p>
<pre>
# iw phy2 wowlan show
WoWLAN is disabled.</pre>
<p>Si votre carte ne supporte pas cette fonctionalité, vous obtiendrez le message suivant :</p>
<pre>
# iw phy0 wowlan show
command failed: Operation not supported (-95)</pre>
<h3>Activation</h3>
<p>La commande à utiliser est du style <em>iw phy2 wowlan enable [mode]</em>. Je ne vais pas rentrer dans le détail des différents modes possibles, voici la liste et une explication succinte :</p>
<ul style="list-style-type: square;">
<li><em>any</em> réveil sur n’importe quelle activité ;</li>
<li><em>disconnect</em> réveille le PC sur une déconnexion (perte du WiFi) ;</li>
<li><em>magic-packet </em>active sur la réception d’un paquet magique ;</li>
<li><em>gtk-rekey-failure</em> en cas d’un échec du renouvellement des GTK (clefs de chiffrement temporaire) ;</li>
<li><em>eap-identity-request </em>sur une demande d’identité EAP ;</li>
<li><em>4way-handshake </em>lors d’une session d’échange de clefs ;</li>
<li><em>rfkill-release </em>réveille lorsque RF-Kill est libéré ;</li>
<li><em>net-detect </em>sur une détection d’un réseau ;</li>
<li><em>tcp</em> réveille sur une connexion TCP ;</li>
<li><em>patterns</em><em> </em>lors de la réception d’un <em>pattern</em> particulier.</li>
</ul>
<p>Pour activer certains modes sur ma carte WiFi, je vais utiliser la commande suivante :</p>
<pre>
# iw phy2 wowlan enable disconnect magic-packet gtk-rekey-failure rfkill-release eap-identity-request</pre>
<p>Ensuite, la commande <em>show</em> donne l’état des modes actifs :</p>
<pre>
# iw phy2 wowlan show
WoWLAN is enabled:
* wake up on disconnect
* wake up on magic packet
* wake up on GTK rekeying failure
* wake up on EAP identity request
* wake up on RF-kill release
</pre>
<p>Il ne reste plus qu’à tester.</p>
<h3>Tester le fonctionnement</h3>
<p>Il suffit de placer votre PC en veille (RAM) et d’envoyer, par exemple, le paquet magique avec la commande <em>wakeonlan.</em></p>
<p>Vous pouvez utiliser la commande suivante pour placer votre PC en veille.</p>
<pre>
# sh -c 'echo mem > /sys/power/state'</pre>
<p>Puis envoyer le paquet magique depuis une autre machine :</p>
<pre>
# wakeonlan ac:72:89:c8:8e:3f</pre>
<p>Si votre PC sort de veille, alors cela fonctionne, sinon il est possible que votre carte ne supporte le fonctionnement qu’à moitié.</p>
<p> </p>Migration de LineageOS vers LineageOS for µGurn:md5:0659b812d545b0a21cef1a4eaea9a5be2017-12-06T12:00:00+01:002017-12-10T01:01:17+01:00APLUandroidGooglelineageosmicrog <p>Je viens de migrer mon téléphone de la version de <a href="http://lineageos.org/" hreflang="en">LineageOS</a> vers la version <a href="https://lineage.microg.org/" hreflang="en">LineageOS for µG</a>.</p>
<h2>Qu’est-ce que cette version apporte en plus ?</h2>
<p>Deux choses :</p>
<p>L’intégration native de F-Droid et de F-Droid Privileged Extension (qui permet d’installer directement depuis F-Droid comme c’est le cas nativement avec le Google PlayStore).</p>
<p>L’intégration des applications microG. Il s’agit d’un projet open-source qui a ré-implémenté les services rendus par les applications propriétaires de Google qui sont livrées avec les Google Apps. On retrouve par exemple la localisation <em>via</em> le réseau ou l’utilisation des API Google Maps pour certaines applications (c’est ce que l’on appelle les GmsCore et GSF).</p>
<p>À part ces deux points-là, c’est la même chose qu’un LineageOS « pur ».</p>
<p>Le principal intérêt en ce qui me concerne est sur la partie localisation passive avec une base locale sur le téléphone. C’est-à-dire sans consommation de données et sans que des informations soient envoyées sur Internet, tout en permettant aux applications qui demandent ma localisation de l’obtenir. Le résultat donne une estimation de quelques centaines de mètres à un kilomètre près, ça dépendra de la précision des sources de localisation.</p>
<p>C’est assez idiot mais ça permet par exemple d’avoir la météo de Toulouse quand on est à Toulouse (en acceptant la localisation dans Firefox) ou encore d’avoir la carte OsmAnd directement positionnée sur l’endroit où l’on se trouve !</p>
<h2>Comment migrer sans perdre les données ?</h2>
<p>Cette procédure est valable pour le Wileyfox Swift mais est adaptable aux autres téléphones supportés par LineageOS.</p>
<p>Il faut d’abord télécharger deux fichiers depuis <a href="https://download.lineage.microg.org/" hreflang="en">https://download.lineage.microg.org/</a></p>
<ol>
<li>Dans le répertoire <em>extra</em> le fichier : <em>lineageos-for-microg-keys-migration.zip</em></li>
<li>Dans le répertoire <em>crackling</em> (ou le nom correspondant à votre téléphone) une version plus récente de LineageOS que celle que vous avez sur le téléphone (dans mon cas j’avais la version <em>lineage-14.1-20171127-nightly-crackling-signed.zip</em> je suis passé sur la version <em>lineage-14.1-20171129-microG-crackling.zip</em>)</li>
</ol>
<p>Ensuite, désinstallez, si vous les avez déjà, les applications suivantes :</p>
<ul>
<li>UnifiedNlp et les locations providers qui fonctionnent avec (comme MozillaNlpBackend, LocalGsmNlpBackend ou encore NominatimNlpBackend)</li>
<li>toutes les Google Apps.</li>
</ul>
<p>Puis redémarrez votre téléphone sur le recovery (TWRP).</p>
<p>Ce n’est pas obligatoire mais je recommande de faire une sauvegarde depuis TWRP de votre système avant.</p>
<p>Puis, toujours depuis le recovery, installez dans l’ordre et sans redémarrer <em>lineageos-for-microg-keys-migration.zip</em> puis <em>lineage-14.1-20171129-microG-crackling.zip</em> (ou toute autre version plus récente que la version de LineageOS).</p>
<p>C’est tout, il ne reste plus qu’à redémarrer, ce qui va prendre plus de temps que d’habitude, c’est normal.</p>
<h2>Post-configuration</h2>
<p>Dans les petits réglages à faire ensuite, il faut simplement aller activer quelques options de µG, par défault elles sont désactivées.</p>
<p>Ces réglages se font depuis les « Parmètres de microG ».</p>
<h3>UnifiedNlp</h3>
<p>Il s’agit de toute la partie localisation passive et configuration des plugins.</p>
<p>De mon côté, j’ai choisi d’installer LocalGsmNlpBackend (disponible sur F-Droid) qui est capable de me positionner avec une base locale (à mettre à jour manuellement) des signaux GSM. Vous pouvez aussi compléter ce besoin avec le service, en ligne, de Mozilla, le plugin est déjà installé (mais pas activé par défault).</p>
<p>L’autre plugin que j’ai activé est NominatimNlpBackend qui permet de transformer une adresse en coordonnées GPS en allant interroger OpenStreetMap.</p>
<h3>Services Google</h3>
<p>De mon côté, je n’ai rien d’activé dans cette partie-là.</p>
<p>Enregistrement du terminal, je n’ai pas fait, je n’ai pas prévu et je n’y vois pas l’utilité.</p>
<p>Google Cloud Messaging, certaines applications peuvent en avoir besoin. Il s’agit d’un mécanisme pour faire passer des messages entre un serveur et une application de manière simple (pour les développeurs), c’est à ce besoin que répond le GCM. Si vous l’activez, vous pouvez configurer la fréquence et n’autoriser que certaines applications à en profiter.</p>
<p>Google SafetyNet, encore une fois, des services fournis par Google pour les développeurs pour qu’ils puissent effectuer des vérifications de sécurité au niveau de leur application. Pour plus de détails sur ce que fait SafetyNet, je vous renvoie vers <a href="https://koz.io/inside-safetynet/" hreflang="en">ce billet, en anglais</a>. À noter qu’avec µG, il y a moyen d’utiliser d’autres serveurs que ceux de Google, mais je ne connais aucune implémentation à ce jour.</p>
<h2>Vérification du fonctionnement</h2>
<p>Il y a une partie Auto-Verification, vous devez avoir toutes les cases au vert, sauf éventuellement « optimisation de la batterie ». Si ce n’est pas le cas, un reboot peut souvent aider.</p>
<h2>Ajout du dépôt µG dans F-Droid</h2>
<p>Ceci permet de garder les applications µG à jour car le projet évolue rapidement et les dépôts F-Droid sont souvent en retard.</p>
<p>La méthode la plus simple consiste à aller sur la <a href="https://microg.org/fdroid.html" hreflang="en">page suivante</a>.</p>KSP / CdLurn:md5:17a171bcc1be19545cae1b7fc2d4d7d92017-11-20T07:49:00+01:002017-11-20T18:48:48+01:00APLUtout et riengpgksp <p>Petit message rapide par rapport à la Key Signing Party qui a eu lieu dimanche entre 12h et 14h pendant le Capitole du Libre.</p>
<p>Contrairement à ce que j’ai pu dire, le whois est anonymisé, donc vous ne pourrez pas vérifier les informations. Si par hasard vous venez ici, voici quelques éléments qui pourront peut être vous convaincre.</p>
<p>Je suis le numéro 37 sur le papier, j’avais un talkie-walkie, et le badge STAFF (rouge) présent sur la photo si dessous et un t-shirt rouge.</p>
<figure style="margin: 0 auto; display: table;"><a class="media-link" href="https://www.aplu.fr/v2/public/ksp2017-laptop.jpg"><img alt="ksp2017-laptop.jpg" class="media" src="https://www.aplu.fr/v2/public/.ksp2017-laptop_s.jpg" /></a>
<figcaption>badge and keys, nov. 2017</figcaption>
</figure>
<p>Aymeric.</p>
<p> </p>
<p><strong>EDIT :</strong></p>
<p>Les clefs qui devait l’être ont été signé avec <em>pius</em>, vous avez normalement reçu un mail, ouvrez le et suivez les deux commandes <em>gpg</em>.</p>Et KRACK le Wi-Fiurn:md5:0fb8d47a099ee4f407a589372790ea332017-10-17T20:00:00+02:002017-10-18T19:04:45+02:00APLUsysadminKRACKsécuritéWEPWiFiWPA <p>Oui, le titre est naze, je sais. Je n’y peux rien, c’est le nom de la dernière vulnérabilité sur le Wi-Fi.</p>
<h2>Version courte</h2>
<p>Le Wi-Fi n’est pas sécurisé et vos données transitent en clair.</p>
<h2>Version longue</h2>
<p>Le Wi-Fi n’a jamais été sécurisé et vos données transitent en clair avec un pseudo chiffrement qui ne tient pas la route.</p>
<p>Je m’explique, le Wi-Fi émet dans toutes les directions et, contrairement aux nuages radioactifs, ne s’arrête pas aux murs (affaibli mais ça passe quand même), donc si vous pouvez contrôler qui est chez vous, vous ne pouvez pas contrôler ce que fait votre voisin.</p>
<p>Et dans le Wi-Fi, il y a deux parties : le client (votre téléphone, votre PC) et le point d’accès (la box). Les deux diffusent dans toutes les directions. Il est possible d’utiliser des antennes directionnelles pour cibler un point mais c’est plus rarement utilisé.</p>
<p>On peut considérer trois types de Wi-Fi.</p>
<h3>Le Wi-Fi OPN (Open)</h3>
<p>C’est le type de Wi-Fi que vous trouvez dans les gares, dans les hôtels et sur les box, le Freewifi, le Orange, etc.</p>
<p>Pas de mot de passe (parfois un portail captif), pas de chiffrement, n’importe qui à proximité peut écouter ce qui passe.</p>
<p>Bref. Vous vous baladez à poil, et sans capote !</p>
<h3>Le Wired Equivalent Privacy (WEP)</h3>
<p>C’est la première tentative de mettre un mot de passe sur du Wi-Fi. Idéalement, oui, c’est sécurisé, les données sont chiffrées avec mot de passe.</p>
<p>Sauf que raté, plusieurs vulnérabilités sont présentes dans le protocole même et permettent à n’importe qui de récupérer le mot de passe en quelques minutes. Une fois le mot de passe obtenu, vous pouvez écoutez tout le trafic.</p>
<p>Bref. Vous vous baladez avec un string moulant transparent et une capote trop petite.</p>
<h3>Le Wi-Fi Protected Access (WPA et WPA2)</h3>
<p>Conçu pour corriger les problèmes du WEP, cette version apporte un nouveau chiffrement, plus sécurisé.</p>
<p>Raté.</p>
<ul>
<li>En 2008 et 2009, des chercheurs trouvent une vulnérabilité dans la première version WPA-TKIP qui permet de déchiffrer et d’injecter des paquets, sans avoir le mot de passe du réseau. L’attaque n’est pas réalisable avec les ressources de l’époque mais elle existe.</li>
<li>En 2011, une vulnérabilité est trouvée sur la partie WPS (permet de se connecter avec un code pin simple plutôt que le mot de passe). L’attaque permet en quelques heures de récupérer le mot de passe, et donc déchiffrer le trafic.</li>
<li>N’importe qui peut vous déconnecter du réseau. Quand je dis n’importe qui, je veux vraiment dire N’IMPORTE QUI. Pas besoin d’être connecté au Wi-Fi ou de recevoir le signal du point d’accès.</li>
<li>Possibilité de récupérer le mot de passe, il suffit de capturer la partie connexion avec l’AP (le moment où il y a l’échange de clef) pour ensuite retrouver le mot de passe. C’est long, mais les puissances de calculs aujourd’hui rendent l’attaque de plus en plus réalisable.</li>
<li>L’absence de <em>Forward Secrecy</em> font qu’une fois que vous avez le mot de passe, il est possible de déchiffrer le trafic, présent, passé ou futur (tant que le mot de passe de change pas, évidemment).</li>
<li>Enfin, le meilleur pour la fin, l’attaque <a href="https://www.krackattacks.com/" hreflang="en" title="KRACK : Breaking WPA2">KRACK</a>, d’où le nom de l’article, permet de déchiffrer et injecter le trafic sans avoir le mot de passe.</li>
</ul>
<p>Bref. Vous vous baladez avec une chemise débraillée et en calbut, avec une capote KRACKÉE (trouée quoi).</p>
<h2>Et KRACK le Wi-Fi</h2>
<p>KRACK est une vulnérabilité dans le protocole, pas dans l’implémentation, et si la plupart des autres vulnérabiltés peuvent être corrigées au niveau du point d’accès (ce qui est « réalisable »), KRACK est à corriger niveau client, en modifiant le protocole pour ne plus respecter la norme (en tout cas plus la version initiale).<br />
Pour faire simple, tous les téléphones, tablettes, PC, caméra IP, imprimante, vibro, IoT, etc. sont donc concernés.</p>
<p>Et c’est là que ça devient compliqué.</p>
<h3>Compliqué, comme compliqué</h3>
<p>Si les PC (sous Linux, Windows, Mac, BSD, etc) seront mis à jour rapidement, ce n’est pas forcement le cas du reste.</p>
<p>Si on regarde Android, on peut trouver des stats sur les versions en vogue. Cette capture a été realisée aujourd’hui.</p>
<figure style="margin: 0 auto; display: table;"><a class="media-link" href="https://www.aplu.fr/v2/public/android/android-market-2017-10.png"><img alt="android-market-2017-10.png" class="media" src="https://www.aplu.fr/v2/public/android/.android-market-2017-10_s.png" /></a>
<figcaption>android market, oct. 2017</figcaption>
</figure>
<p>Si on compare avec les versions d’android supportées cela donne ça :</p>
<figure style="margin: 0 auto; display: table;"><a class="media-link" href="https://www.aplu.fr/v2/public/android/android-security-2017-10.png"><img alt="android-security-2017-10.png" class="media" src="https://www.aplu.fr/v2/public/android/.android-security-2017-10_s.png" /></a>
<figcaption>android support, oct. 2017</figcaption>
</figure>
<p>Donc, toutes les versions avant Android 4.4 ne sont plus supportées, il y a aujourd’hui 7,8% d’équipements concernés. Si on considère qu’il y a 1,5 milliards d’équipements Android, cela fait autour de 120 millions de périphériques.</p>
<p>La version 4.4 bien que supportée par Google n’est plus mise à jour au niveau des utilisateurs finaux, car malheureusement les constructeurs préfèrent s’occuper du prochain appareil que de supporter les anciens, cela fait donc à la louche 220 millions d’équipements.</p>
<p>Pour le millard d’équipements restant, croisons les doigts pour que ça soit encore mis à jour.</p>
<p>Et je ne parle là que du cas Android, pas de tout le reste des IoT totalement à l’abandon.</p>
<h3>Que faire ?</h3>
<p>Malheureusement, à part harceler le SAV de vos équipements pour leur demander d’appliquer les correctifs, pas grand chose. Cela dit, si ne serait-ce que 10 millions de personnes appellent le SAV ça devrait peut-être faire bouger les choses…</p>
<h2>Mais que faire, alors ?!</h2>
<p>Une solution propre, ne plus utiliser le Wi-Fi, mais cela n’est pas une réponse acceptable.</p>
<p>La pire des solutions serait de revenir à WEP ou du réseau ouvert, restez en WPA2, même s’il y a des vulnérabités, et même s’il restera toujours des équipements plus vulnérables que d’autres, c’est l’option la moins pire.</p>
<p>La meilleure solution c’est de chiffrer tout le trafic, donc s’assurer que l’on va bien sur les versions HTTPS des sites, si vous lisez vos mails avec client lourd (ex Thunderbird) que c’est bien SSL ou STARTTLS, idéalement utiliser un VPN (avec chiffrement), etc.</p>
<p>Bref. Mettre une capote même si on reste plus où moins à poil en dessous.</p>
<p>Quant au reste des équipements, appeler le SAV et expliquez leur que vous êtes inquiets pour la sécurité de vos données et que vous souhaitez une mise à jour. Allez voir vos voisins et demandez leur de faire de même.</p>
<h2>Allez plus loin ?</h2>
<p>Si vous avez besoin de renseignements supplémentaires, et si vous êtes sur Toulouse, n’hésitez pas à passer à la CryptoParty le<a href="http://www.bibliotheque.toulouse.fr/cryptoparty.html" hreflang="fr"> samedi 28 octobre de 14h à 18h à la mediathèque</a>. Ce problème du Wi-Fi y sera abordé ainsi que d’autres points concernant la vie privée.</p>[Coup de gueule] Rappel du code de la routeurn:md5:94d10de4b33bd6725951dce3780f318e2017-09-08T08:45:00+02:002017-12-20T16:27:00+01:00APLUtout et riencode de la route <p>Petit billet sans aucun rapport avec l’informatique, j’ai fait quelques milliers de kilomètres ces derniers jours en voiture, voici donc un petit coup de gueule, ou rappel du code de la route, que tout le monde doit respecter.</p>
<h2>À droite !</h2>
<p>Pour commencer, je rappelle qu’en France (comme dans beaucoup de pays), on roule à droite. Donc s’il y a plusieurs voies, il faut rouler à droite. Toujours. Il n’y a pas de mais. À droite. La voie la plus à droite quoi qu’il arrive. Et si les voies ne sont pas délimitées par un marquage au sol, le plus à droite possible tel que la chaussée, la route, le permet.</p>
<p>Le code, il dit que : « En marche normale, tout conducteur doit maintenir son véhicule près du bord droit de la chaussée, autant que le lui permet l'état ou le profil de celle-ci. »</p>
<p>Les seuls cas où vous n’allez pas prendre la voie la plus à droite sont :</p>
<ul>
<li><a href="https://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=4E15299A3AA5BFD8BF48EAFD80EF11EF.tpdila20v_3?idArticle=LEGIARTI000006842219&cidTexte=LEGITEXT000006074228&dateTexte=20080531" hreflang="fr">Pour effectuer un dépassement, car on dépasse par la gauche</a> ;</li>
<li><a href="https://www.legifrance.gouv.fr/affichCode.do?idSectionTA=LEGISCTA000006159607&cidTexte=LEGITEXT000006074228&dateTexte=20080531" hreflang="fr">Si la voie de droite est une voie pour véhicule lent et que votre véhicule vous permet de rouler à une vitesse supérieure à 60km/h sur la portion en question</a> ;</li>
<li>Les sens giratoires (c’est un peu plus complexe, ça dépend de là où vous allez).</li>
</ul>
<p>À ma connaissance, c’est tout.</p>
<p>Donc vous n’avez strictement aucune raison de rester sur les autres voies si vous n’entrez pas dans les points ci-dessus.</p>
<h2>Le clignotant !</h2>
<p>Le clignotant, c’est la petite lampe qui marche une fois sur deux. C’est normal, c’est prévu pour. En général, on commande ça depuis un petit truc qui dépasse sur votre gauche au volant. En termes code de la route, ça s’appelle « Feux indicateurs de direction ». C’est forcement présent, car obligatoire si votre véhicule est équipé d’un moteur et que le poids total en charge est supérieur à 500 kg (ce qui fait que toutes les voitures en sont équipées et que sur un cyclomoteur, ce n’est pas obligatoire).</p>
<p>On va faire simple, le code il dit que : « <a href="https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006074228&idArticle=LEGIARTI000006842127" hreflang="fr">Tout conducteur qui s'apprête à apporter un changement dans la direction de son véhicule ou à en ralentir l'allure doit avertir de son intention les autres usagers, notamment lorsqu'il va se porter à gauche</a> » ainsi que : « <a href="https://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=4E15299A3AA5BFD8BF48EAFD80EF11EF.tpdila20v_3?idArticle=LEGIARTI000006842216&cidTexte=LEGITEXT000006074228&dateTexte=20080531" hreflang="fr">Avant de dépasser, tout conducteur doit s'assurer qu'il peut le faire sans danger</a> »</p>
<p>Donc deux choses, on parle d’avertir de son intention, ça ne signifie pas que vous devenez prioritaire. Donc on s’assure qu’il n’y a personne dans la nouvelle direction, que l’on ne va pas gêner les autres véhicules, puis on change (et non ce n’est pas parce qu’il y a la place de votre voiture que c’est sans danger, j’en parle après mais il y a un truc qu’on appelle distance de sécurité).</p>
<h2>Téléphone et bouffe au volant</h2>
<p>C’est très simple : « <a href="https://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=4E15299A3AA5BFD8BF48EAFD80EF11EF.tpdila20v_3?idArticle=LEGIARTI000030800800&cidTexte=LEGITEXT000006074228&dateTexte=20170904" hreflang="fr">L'usage d'un téléphone tenu en main par le conducteur d'un véhicule en circulation est interdit</a> ». Cela ne vous empêche pas de vous en servir comme GPS, vous ne devez simplement pas le tenir dans les mains.</p>
<p>Et le coup du casque pour le kit main libre ou pour écouter de la musique, même combat : « Est également interdit le port à l'oreille, par le conducteur d'un véhicule en circulation, de tout dispositif susceptible d'émettre du son, à l'exception des appareils électroniques correcteurs de surdité. »</p>
<p>Quant à la bouffe, « <a href="https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006074228&idArticle=LEGIARTI000019277061" hreflang="fr">Tout conducteur doit se tenir constamment en état et en position d'exécuter commodément et sans délai toutes les manœuvres qui lui incombent</a> » . Donc quand vous êtes en train de chercher à récupérer cette foutue tomate cerise au fond de votre salade en boite, vous n’êtes ni en état ni en condition pour continuer à conduire en toute sécurité.</p>
<p>Et puis merde, si vous êtes sur l’autoroute, il y a des aires quasiment tous les 10 ou 20 km (ce qui vous permet de vous arrêter environ toutes les 10 minutes en respectant les limitations de vitesse). En ville, il y a des places de parking, arrêtez-vous pour manger et faire une pause !</p>
<h2>Distance de sécurité</h2>
<p>La règle est simplissime « <a href="https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI000006842131&cidTexte=LEGITEXT000006074228" hreflang="fr">Elle correspond à la distance parcourue par le véhicule pendant un délai d'au moins deux secondes</a> »</p>
<p>Sur autoroute, vous verrez souvent les panneaux « un trait danger, deux traits sécurité » on parle des traits de la voie de droite (de toute façon, vous roulez à droite, hein ?) qui marque la séparation pour la bande d’arrêt d’urgence. Si vous roulez à 130 km/h ça fait environ 70 m. Pour vous donnez une autre idée, 70 mètres, c’est la distance qu’éclairent vos feux de route (phares). Donc si vous êtes capable de lire la plaque du véhicule, vous êtes vraiment trop près.</p>
<p>Pour l’évaluer quand vous roulez, repérez quand le véhicule devant passe devant un objet, un signe, et comptez 2 secondes, si vous y êtes avant, c’est que vous êtes trop près.</p>
<p>En ville, cette distance est donc d’environ 30 m, ce qui correspond à la distance qu’éclairent vos feux de croisement (ou les codes pour les anciens).</p>
<p>L’excuse du « oui mais ça roule il n’a aucune raison de freiner » n’est pas valable. Vous n’êtes pas dans la voiture de devant, peut-être que le conducteur va faire un AVC, peut-être une qu’une araignée va atterrir sur le volant semant la panique à bord, un oiseau va traverser la route et le conducteur va piler, le véhicule va tomber en panne, etc.</p>
<h2>Dépassement</h2>
<p>Que tu roules avec une 2cv, une Porsche, une Audi, ou n’importe quelle voiture, les règles sont les mêmes :</p>
<p>« <a href="https://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=AA27B947D68F6EDE3974AAE1966DEBE8.tpdila20v_3?idArticle=LEGIARTI000006842236&cidTexte=LEGITEXT000006074228&dateTexte=20170904" hreflang="fr">Lorsqu'ils sont sur le point d'être dépassés, les conducteurs doivent serrer immédiatement sur leur droite sans accélérer l'allure</a> » Vu que tu roules déjà à droite la seule chose que tu ne dois pas faire c’est accélérer, tu maintiens ton allure. Ça peut froisser ton égo de te faire doubler par une Renault 4L alors que tu es confortablement assis dans le fauteuil en cuir de ta belle Audi A4 version sport, mais ce n’est pas une raison pour accélérer. Si la personne t’a rattrapé, te dépasse, c’est que tu roules moins vite qu’elle. Donc tu te laisses dépasser, tu respires et ça passera.</p>
<p>Ensuite, toi qui es dans ta 4L qui vient d’effectuer un dépassement (en utilisant bien sûr tes clignotants), tu reviens dans la voie de droite sans ralentir. « <a href="https://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=AA27B947D68F6EDE3974AAE1966DEBE8.tpdila20v_3?idArticle=LEGIARTI000006842227&cidTexte=LEGITEXT000006074228&dateTexte=20170904" hreflang="fr">Tout conducteur qui vient d'effectuer un dépassement par la gauche doit revenir sur sa droite sans provoquer le ralentissement du véhicule dépassé</a> »</p>
<p>En gros, le seul cas où tu as le droit de dépasser par la droite c’est dans les bouchons « <a href="https://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=AA27B947D68F6EDE3974AAE1966DEBE8.tpdila20v_3?idArticle=LEGIARTI000006842234&cidTexte=LEGITEXT000006074228&dateTexte=20170904" hreflang="fr">Lorsque, sur les routes à sens unique et sur les routes à plus de deux voies, la circulation s'est, en raison de sa densité, établie en file ininterrompue sur toutes les voies, le fait que les véhicules d'une file circulent plus vite que les véhicules d'une autre file n'est pas considéré comme un dépassement</a> »</p>
<h2>Conclusion</h2>
<p>C’est juste un rappel de quelques règles du code de la route, normalement tu devrais déjà connaître, il y en a plein d’autres mais ce sont celles qui sont le moins respecté sur les trajets que j’ai effectués (essentiellement autoroute).</p>
<p>Donc, on roule à droite, on ne téléphone pas, on roule à droite, on dépasse par la gauche, on roule à droite, on ne téléphone pas, on utilise les clignotants, on respecte les distances de sécurité, on roule à droite et on dépasse par la gauche. Ah, oui, j’oubliais, le plus important : on roule à droite.</p>
<p>Sinon, tout ce que j’ai cité au-dessus est passible d’amendes allant d’un point sur votre permis à une suspension.</p>
<p>Merci !</p>
<h2>Bonus</h2>
<p>Je vous laisse le soin de chercher l’article en question dans le code, mais sachez qu’il est parfaitement légal de faire tirer un véhicule à quatres roues par six chevaux. Donc la prochaine fois que vous tombez en panne, allez à la ferme du coin emprunter des chevaux pour rentrer chez vous.</p>EXT4, augmentation à chaud et erreur de GDTurn:md5:b11193a37e2d5859d3347101f19e0df02017-07-31T22:25:00+02:002017-07-31T22:25:00+02:00APLUsysadminext4gdtlinuxresize2fs <p>Selon les technologies de stockage que vous utilisez, il est possible d’augmenter à chaud la taille d’un disque d’une machine Linux.</p>
<p>Soit par LVM, soit parce que vous êtes sur une solution de virtualisation, ou d’autres solutions farfelues.</p>
<p>Si vous utilisez ext4 (le système de fichiers le plus « standard » sous Linux), la commande magique pour agrandir à chaud, c’est :</p>
<pre>
resize2fs /dev/mondevice</pre>
<p>Vous avez un beau message indiquant :</p>
<pre>
Filesystem at /dev/vg/lv_home <span class="hljs-keyword">is</span> mounted <span class="hljs-keyword">on</span> /home; <span class="hljs-keyword">on</span>-line resizing required...</pre>
<p>Et si tout se passe bien,</p>
<pre class="code not-hl hljs cs">
The filesystem <span class="hljs-keyword">on</span> /dev/vg/lv_home <span class="hljs-keyword">is</span> now <span class="hljs-number">319283200</span> blocks <span class="hljs-keyword">long</span>.</pre>
<p>Mais là, c’est le drame, car vous obtenez le cryptique message</p>
<pre>
<code>resize2fs: Not enough reserved gdt blocks for resizing</code></pre>
<p>Ou encore</p>
<pre>
<code>resize2fs: permission denied to resize filesystem</code></pre>
<h2>Panique à bord ? Il faut tout recommencer ?</h2>
<p>Pas du tout, la raison est simple, vous pouvez augmenter un disque, à chaud, jusqu’à une certaine limite, par exemple 1000x la taille initiale.</p>
<p>La limite dépend de beaucoup d’options qui sont calculées lors du formatage initial.</p>
<p>Dans ce cas, la seule solution c’est de démonter le système de fichier et de l’augmenter à froid.</p>
<p>Donc :</p>
<pre>
<code>umount /home
e2fsck -f /dev/vg/lv_home
resize2fs /dev/vg/lv_home
mount /home</code></pre>
<p>À noter que cette erreur ne se produit, normalement, plus avec des kernels récents.</p>Joyeux SysAdmin Dayurn:md5:5ed9a2dab203d5053a69b901c1998c8d2017-07-28T00:01:00+02:002017-07-28T00:01:00+02:00APLUsysadminsysadminday <p>Comme tous les ans depuis 2000, le SysAdminDay a lieu le dernier vendredi de juilllet.</p>
<p>Merci donc de nous faire des gâteaux, de nous apporter des pizzas, etc. et de prendre soin de tous vos administrateurs système qui s’occupent de faire fonctionner du mieux possible les infrastructures qui tiennent parfois avec des bouts de ficelle.</p>
<p>Pourquoi un sysadminday ? Parce que, comme le dit très bien le site officiel <a href="http://sysadminday.com/" hreflang="en">SysAdmin Day</a>, 365 jours par ans, voire parfois 366 jours, on est traité comme de la merde à réparer, à faire « tomber en marche » des solutions foireuses vendues par des commerciaux plus attirés par la prime que par les retours des personnes qui vont gérer la solution ensuite, et tout ça en gardant le sourire, en changeant votre foutu mot de passe pour la 4e fois de la journée… Et au final, vous connaissez mon numéro, mon e-mail mais vous ne savez pas que je sais que vous passez 95 % de la journée à lire <a href="http://lemonde.fr/" hreflang="fr">Le Monde</a>, à glander sur <a href="http://www.demotivateur.fr/entertainment/quand-la-fiction-rattrape-la-realite-10724" hreflang="fr">Démotivateur</a>, à vous demander si <a href="http://www.legorafi.fr/2013/03/20/toulouse-il-se-fait-abattre-de-46-balles-dans-le-corps-pour-avoir-demande-un-pain-au-chocolat/" hreflang="fr">à Toulouse on appelle vraiment une chocolatine une chocolatine</a>, voire à regarder des <a href="https://www.youtube.com/watch?v=QH2-TGUlwu4">vidéos originales</a>.</p>
<p>Alors, une fois par an, prenez soin de nous et posez-vous la question de savoir si on a vraiment envie que vous nous racontiez que vous avez changé de mot de passe suite à la mort de votre chat offert par votre tante il y a 6 mois ? Si on préfère passer notre soirée à restaurer votre foutu mail que vous avez supprimé par erreur de la corbeille ? Si quand on vient de passer la nuit à réparer les serveurs de production parce que vous avez ouvert "Mes photos de vacances.zip.exe", on aime se faire insulter parce qu’il n’y a toujours pas de papier dans l’imprimante ?</p>
<p>Pour le fun, une petite musique que j’apprécie fortement qui résume bien mon, notre, metier : <a href="https://www.youtube.com/watch?v=udhd9fmOdCs">SysAdmin Song</a> (oui, je sais, YouTube).</p>Augmenter la bande passante avec TCP BBRurn:md5:da20f2630f9633d4ec4c156fbf9bb6882017-07-24T00:11:00+02:002017-07-24T16:36:17+02:00APLUsysadminlinuxtcp bbr <p>Il y a quelques jours, je suis tombé sur un article qui explique comment Google a augmenté le débit et réduit la latence de son infrastructure avec un nouveau algorithme de congestion pour TCP : BBR.</p>
<p><a href="https://cloudplatform.googleblog.com/2017/07/TCP-BBR-congestion-control-comes-to-GCP-your-Internet-just-got-faster.html" hreflang="en">On parle ici d’une augmentation de 4 à 15 % selon les tests de Google</a>.</p>
<p>Pour activer cet algorithme, il faut disposer d’un kernel Linux récent avec le support des bonnes options.</p>
<h2>Vérifier les options du kernel</h2>
<p>La commande suivante doit vous retourner au moins la ligne CONFIG_TCP_CONG_BBR et CONFIG_NET_SCH_FQ.</p>
<pre>
$ egrep 'CONFIG_TCP_CONG_BBR|CONFIG_NET_SCH_FQ' /boot/config-$(uname -r)
CONFIG_TCP_CONG_BBR=m
CONFIG_NET_SCH_FQ_CODEL=m
CONFIG_NET_SCH_FQ=m</pre>
<p>Si vous n’avez pas, inutile de continuer, mettez à jour un kernel Linux plus récent, je n’ai pas regardé l’introduction des patchs, mais le kernel 4.9 de debian le supporte.</p>
<h2>Activer l’algorithme TCP BBR</h2>
<p>La solution la plus simple, créer un fichier nommé : /etc/sysctl.d/88-tcp_bbr.conf</p>
<p>avec le contenu suivant :</p>
<pre>
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr</pre>
<p>Puis lancer la commande suivante avec les droits root.</p>
<pre>
sysctl --system</pre>
<h2>Vérifier la prise en compte</h2>
<p>Pour vérifier la prise en compte, rien de plus simple que d’afficher les valeurs prises par le système :</p>
<pre>
# sysctl net.core.default_qdisc net.ipv4.tcp_congestion_control
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr</pre>
<p>On constate ici que les deux options de configuration ont les bonnes valeurs.</p>
<p>À défaut, vous aurez le résultat suivant (il s’agit de l’algorithme par défaut)</p>
<pre>
# sysctl net.core.default_qdisc net.ipv4.tcp_congestion_control
net.core.default_qdisc = pfifo_fast
net.ipv4.tcp_congestion_control = cubic</pre>Installation de EPEL sur RHEL7urn:md5:d51c12266658d1c1b9487aaa15b046812017-07-21T22:00:00+02:002017-07-24T16:16:23+02:00APLUsysadminlinuxrhelsysadmin <p>Utiliser un système RedHat Enterprise Linux ou CentOS c’est bien, mais parfois on a envie d’avoir un peu plus de logiciels que juste ceux supportés par RedHat.</p>
<p>Dans ce cas, on se tourne vers EPEL, <span class="mw-headline" id="Extra_Packages_for_Enterprise_Linux_.28EPEL.29">Extra Packages for Enterprise Linux. Il s’agit d’un repository qui contient bien plus de logiciels, supportés entièrement par la communauté.</span></p>
<p><span class="mw-headline">Pour l’installer, la solution la plus simple, c’est de télécharger et installer le fichier suivant </span><a href="https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm">https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm</a> (pour RHEL 7), pour RHEL 6 il faudra utiliser le lien suivant : <a href="https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm">https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm</a>.</p>
<p>Ce qui peut être fait en ligne de commande en une seule étape :</p>
<pre>
cd /tmp
wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum install epel-release-latest-7.noarch.rpm</pre>
<p>Ensuite, vous pouvez installer un peu plus de logiciels (comme htop par exemple).</p>
<pre>
# yum repolist
Modules complémentaires chargés : product-id, search-disabled-repos,
: subscription-manager
id du dépôt nom du dépôt statut
epel/x86_64 Extra Packages for Enterprise Linux 7 - 11 909
rhel-7-server-rpms/7Server/x86_64 Red Hat Enterprise Linux 7 Server (RPMs 14 598
repolist: 26 507</pre>
<p> </p>
<p> </p>Stockage, iSCSI, Multipath et Linuxurn:md5:6e854711d089b6d3e3406b5c2d210b392017-06-21T18:49:00+02:002017-07-21T20:53:20+02:00APLUsysadminiscsilinuxlunmultipathsysadmin <p>Ou comment faire tomber tout ce beau monde en marche, assez simplement <img src="https://www.aplu.fr/v2/?pf=smile.svg" alt=":)" class="smiley" /></p>
<h2>De quoi parle-t-on ?</h2>
<h3>iSCSI</h3>
<p>iSCSI c’est un protocole pour accéder à un disque, un morceau de disque, bref à un espace de stockage à travers le réseau (<em>via</em> des adresses IP).</p>
<p>Dit autrement, vous avez une machine avec plein de disques d’un côté du réseau, et une machine avec une (ou plusieurs) cartes réseau et vous souhaitez accéder à vos disques directement <em>via</em> le réseau ? C’est ce que permet de faire iSCSI.</p>
<h3>Multipath</h3>
<p>Le multipath, comme le nom peut le laisser entendre, c’est permettre d’accéder à la même chose par plusieurs chemins.</p>
<p>Appliqué au stockage, ça veut dire qu’on va accéder sur la même ressource de stockage <em>via</em> plusieurs liens, ce qui permet d’avoir de la redondance en cas de perte, et éventuellement, une répartition de charge. Ça peut être vu de manière équivalente <a class="ref-post" href="https://www.aplu.fr/v2/post/2014/05/24/Agr%C3%A9gation-de-liens-%28bonding%29-sous-Linux-%28Debian/Ubuntu%29">à ce qui avait décrit dans ce billet, sur le bonding réseau</a>.</p>
<h2>Mise en pratique</h2>
<p>Ici, je ne vais pas expliquer comment partager la ressource de stockage. Plusieurs raisons :</p>
<ul>
<li>On utilise en général des technologies de stockage différentes les unes des autres, et chacune a ses propres manières de faire la partie « serveur » (<em>target</em>) ;</li>
<li>La ressource de stockage peut être <em>via</em> Ceph/RDB, une baie dédiée (type Dell, IBM, EMC²), du VSAN VMware, une grappe raid… ou un simple disque dur.</li>
</ul>
<p>En termes de stockage, lorsqu’on partage un espace qui sera vu comme un disque, on appelle ça un LUN (<em>Logical Unit Number</em>), on doit donc définir sur l’équipement qui fait le stockage que le LUN numéro <em>xyz</em> sera publié pour le serveur <em>Charlie</em>. Pour ça, on présente le LUN dans un target et ce target au serveur. Il peut y avoir plusieurs LUN dans le même target et, à ma connaissance, un LUN ne peut pas être dans plusieurs targets.</p>
<p>Puisque l’on souhaite mettre du multipath ensuite, on doit donc s’assurer que le target sera joignable par plusieurs addresses IP (qui seront potentiellement sur des équipements réseau différents le long du chemin, sinon on se retrouve avec un SPoF qu’on va chercher à éviter).</p>
<p>Une fois le LUN « publié » depuis notre serveur Linux, on va pouvoir attacher ce volume au serveur.</p>
<p>Sur CentOS/RedHat, il faut installer le paquet iscsi-initiator-utils ; pour Debian/Ubuntu, il faut installer open-iscsi.</p>
<p>Dans les deux cas, on se retrouve avec une commande : iscsiadm.</p>
<h2>iscsiadmin</h2>
<p>Avant de commencer, on va (re)définir quelques valeurs par défaut qui sont plus adaptées pour la suite.</p>
<p>Ces réglages se font dans le fichier /etc/iscsi/iscsid.conf</p>
<p>Il y a quelques variables qui peuvent être définies, elles permettent d’avoir des mots de passe et du chiffrement, ce n’est pas obligatoire mais fortement recommandé.</p>
<pre>
node.session.auth.authmethod = CHAP
node.session.auth.username = username
node.session.auth.password = password!
discovery.sendtargets.auth.authmethod = CHAP
discovery.sendtargets.auth.username = username
discovery.sendtargets.auth.password = password!</pre>
<p>Cette valeur doit être modifiée, elle définit au bout de combien de secondes une session iSCSI qui n’est plus valable (par exemple le chemin réseau est KO) l’erreur sera remontée au-dessus. Vu autrement, au bout de combien de secondes, en cas de perte, on aura des erreurs et le LUN sera vu comme hors ligne, comme nous allons mettre du multipath ensuite, il est préférable d’avoir cette valeur à 0.</p>
<pre>
node.session.timeo.replacement_timeout = 0</pre>
<p>Une fois les options modifiées, lancez ou relancez le service iscsid.</p>
<p>Une fois ces réglages faits, avec la commande iscsiadm on va demander à la partie stockage, d’envoyer la liste des « targets » auquels le serveur a accès.</p>
<pre>
# iscsiadm -m discovery -t sendtargets -p 10.10.199.4
10.10.199.4:3260,2 iqn.1998-01.com.foo:4beb2e86-9c13-45f7-be3d-5eb96b7b62a6
</pre>
<p>On répète la même commande pour toutes les IP où notre LUN est joignable.</p>
<p>Une fois l’ensemble des discovery réalisés, la commande suivante permet de passer en ligne tous les LUNs.</p>
<pre>
# iscsiadm -m node -L all</pre>
<p>Si vous faites la commande <em>lsblk -pS</em> vous devriez voir plusieurs nouveaux disques (ici de sdb à sdm, je vous laisse deviner la solution de stockage utilisée :)).</p>
<pre>
# lsblk -pS
NAME HCTL TYPE VENDOR MODEL REV TRAN
/dev/sda 0:0:0:0 disk VMware Virtual disk 2.0
/dev/sdb 8:0:0:0 disk VMware Virtual SAN 0001 iscsi
/dev/sdc 3:0:0:0 disk VMware Virtual SAN 0001 iscsi
/dev/sdd 9:0:0:0 disk VMware Virtual SAN 0001 iscsi
/dev/sde 10:0:0:0 disk VMware Virtual SAN 0001 iscsi
/dev/sdf 8:0:0:1 disk VMware Virtual SAN 0001 iscsi
/dev/sdg 3:0:0:1 disk VMware Virtual SAN 0001 iscsi
/dev/sdh 9:0:0:1 disk VMware Virtual SAN 0001 iscsi
/dev/sdi 10:0:0:1 disk VMware Virtual SAN 0001 iscsi
/dev/sdj 8:0:0:2 disk VMware Virtual SAN 0001 iscsi
/dev/sdk 3:0:0:2 disk VMware Virtual SAN 0001 iscsi
/dev/sdl 9:0:0:2 disk VMware Virtual SAN 0001 iscsi
/dev/sdm 10:0:0:2 disk VMware Virtual SAN 0001 iscsi</pre>
<h2>Le multipath</h2>
<p>Pour configurer le multipath, ça va être relativement plus simple à faire. Sous CentOS/RHEL, il faut installer le paquet device-mapper-multipath et sous Debian/Ubuntu : multipath-tools.</p>
<p>Ensuite, il suffit de créer le fichier /etc/multipath.conf avec le contenu suivant :</p>
<pre>
defaults {
user_friendly_names yes
find_multipaths yes
features "1 queue_if_no_path"
path_grouping_policy failover
no_path_retry 100
}</pre>
<p>Une relance du service multipathd suffit en général pour prendre en compte les modifs.</p>
<p>Il est possible d’être plus specifique dans le fichier de configuration mais dans le cas présent, ces options suffisent pour nos besoins.</p>
<p>Une fois fait, la commande multipath -l permet de lister les différents agrégats de disque réalisés :</p>
<pre>
# multipath -l
mpathd (1VMware_VITDEVIDc7593159e1fd795a1d02901b0eafc51b) dm-4 VMware ,Virtual SAN
size=400G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| `- 8:0:0:2 sdj 8:144 active undef running
|-+- policy='service-time 0' prio=0 status=enabled
| `- 9:0:0:2 sdl 8:176 active undef running
|-+- policy='service-time 0' prio=0 status=active
| `- 3:0:0:2 sdk 8:160 active undef running
`-+- policy='service-time 0' prio=0 status=enabled
`- 10:0:0:2 sdm 8:192 active undef running
mpathc (1VMware_VITDEVIDa05931591221cbf9f449901b0eafc615) dm-3 VMware ,Virtual SAN
size=200G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| `- 8:0:0:1 sdf 8:80 active undef running
|-+- policy='service-time 0' prio=0 status=active
| `- 3:0:0:1 sdg 8:96 active undef running
|-+- policy='service-time 0' prio=0 status=enabled
| `- 9:0:0:1 sdh 8:112 active undef running
`-+- policy='service-time 0' prio=0 status=enabled
`- 10:0:0:1 sdi 8:128 active undef running
mpatha (1VMware_VITDEVID3dc72e59d49bb331d68b901b0eafc615) dm-2 VMware ,Virtual SAN
size=100G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| `- 3:0:0:0 sdc 8:32 active undef running
|-+- policy='service-time 0' prio=0 status=enabled
| `- 8:0:0:0 sdb 8:16 active undef running
|-+- policy='service-time 0' prio=0 status=active
| `- 9:0:0:0 sdd 8:48 active undef running
`-+- policy='service-time 0' prio=0 status=enabled
`- 10:0:0:0 sde 8:64 active undef running</pre>
<p>Ici, on se retrouve avec 3 disques, mpathd, mpathc, et mpatha qui sont joignables par 4 chemins différents.</p>
<p>Pour l’usage ensuite, on accèdera non plus à sdX mais à mpathX, ainsi l’abstraction multipath permet de garantir l’accès au stockage.</p>
<p> </p>
<p> </p>Wileyfox Swift bloqué sur TWRP ?urn:md5:b8099cae91a3889770f2f349e78b03322017-05-07T07:05:00+02:002017-06-27T21:30:25+02:00APLUandroidandroidcracklinglineageosSwiftTWRPwileyfox <p>Si vous aviez <a class="ref-post" href="https://www.aplu.fr/v2/post/2017/04/04/lineageos-sur-wileyfox-swift">lu attentivement le billet précédent</a>, je vous avais dit de ne pas faire la mise à jour depuis le téléphone sous peine de rester bloquer sur TWRP…</p>
<p>Bon, maintenant votre téléphone reste sur TWRP et vous ne savez plus comment vous en sortir ?</p>
<p>Rassurez-vous votre téléphone n'est pas foutu, voici deux méthodes pour revenir sur le système Android et sortir du mode recovery.</p>
<h2>Méthode 1</h2>
<p>Depuis TWRP redémarrer le téléphone en mode fastboot (ou bootloader) puis, depuis un PC executer la commande suivante :</p>
<pre>
fastboot continue</pre>
<p>Dans certains cas, cette modification n'est que temporaire, je vous conseille donc fortement de redémarrer le téléphone pour valider.</p>
<h2>Méthode 2</h2>
<p>Cette méthode, bien que fonctionnelle est dangereuse, soyez donc prudent sous peine de bloquer complètement le téléphone.</p>
<p>Lorsque le téléphone est en mode recovery, depuis le PC, lancer la commande suivante :</p>
<pre>
adb shell</pre>
<p>Vous devez obtenir un shell sur le téléphone Android, avec les deux commandes suivantes. On va identifier les mémoires à effacer :</p>
<pre>
~ # find /dev/block/platform/ -name "*fota*"
~ # find /dev/block/platform/ -name "*misc*"
/dev/block/platform/7824900.sdhci/by-name/misc</pre>
<p>Ces deux commandes vont retourner des résultats, dans mon exemple, seule la recherche de la mémoire "misc" retourne un resultat.</p>
<p>Une fois le ou les deux mémoires identifiées, on va lancer la commande suivante :</p>
<pre>
dd if=/dev/zero of=resultat-de-la-commande-précédente</pre>
<p>Dans mon cas :</p>
<pre>
dd if=/dev/zero of=/dev/block/platform/7824900.sdhci/by-name/misc</pre>
<p>Une fois réalisé, il n’y a plus qu’à rebooter le téléphone.</p>
<p> </p>