Blog de dada

DevOps, bidouilleur et routard plein de logiciels libres

J'ai fait de la vidéoprotection

Rédigé par dada / 29 avril 2020 / 1 commentaire


Nan, je déconne ! J'ai fait de la vidéosurveillance. Il faut savoir appeler un chat un chat et je vous redirige vers cet article histoire de bien rigoler. Bref.

La genèse

Après avoir découvert la présence d'excréments sur la terrasse du jardin familial, nous avons déclaré que c'était de la merde de loir. Ni une, ni deux, on installe une cage pour capturer l'animal et le renvoyer chez le voisin plus loin. Il s'est avéré que nous nous sommes plantés et que c'était les rejets d'un hérisson !

Du coup, pour m'amuser, et ayant déjà une partie de la configuration disponible, j'ai décidé de mettre en place un système pour voir la créature se balader.

Le matériel

En photo, ça ne donne pas grand chose mais c'est rigolo :

  • Un Raspberry Pi B de 2011
  • Une webcam USB
  • Une batterie externe de 6 000 mAh
  • Un projecteur avec détecteur de mouvement

Configuration du Raspberry Pi

Raspbian

Pour commencer, installez l’indétrônable Raspbian dans la carte SD de votre Raspberry. Pensez à prendre une carte avec un peu d'espace disque. Ceci dit, ce n'est pas la peine d'en prendre une de 32 ou 64Go si, comme moi, vous utilisez le RPi 1 : cette vieille bête ne permet pas de jouer avec des grosses définitions. Oubliez le 1080p ou le 720p, ça sera bien moins.

Note : J'ai récemment appris que Ubuntu avait enfin une version dédiée au nano-ordinateur. C'est cool mais elle n'est compatible qu'avec les RPi modèles 2 à 4 : mon vieux jouet de 2011 n'est pas supporté.

Motion

Comme plus ou moins tout le monde, c'est Motion que j'utilise. Cet outil permet de détecter des mouvements en analysant, en gros, les changements de couleur des pixels. C'est très simple et très efficace.

Pour l'installer :
apt install motion
Niveau configuration, voici ce que j'ai modifié dans /etc/motion/motion.conf
daemon on
framerate 24
threshold 500
pre_capture 2
post_capture 2
Le fichier est assez long et indigeste. Je n'ai absolument pas tout lu. Si vous voulez en faire le tour, préparez un peu de café.

En faisant mes tests, je me suis rendu compte que si je voulais avoir le meilleur équilibre entre la puissance du RPi et la qualité/fluidité de la vidéo, je devais garder la résolution par défaut (320x240) et passer le framerate à 24. Augmenter l'une ou l'autre de ces variables sur un modèle B non overclockable, c'est mettre la machine à genou très vite.

Niveau détection du mouvement, le hérisson étant une petite créature, j'ai pas mal augmenté la sensibilité de Motion en la passant de 1500 à 500.

Si vous êtes des pros en matière de vidéo, je suis preneur d'info (simples) autour des réglages.

Au passage, je remercie ma nièce et son doudou pour le test grandeur nature de déclenchement de l'enregistrement :


Voyez qu'on ne fait pas de miracle avec ce genre de matos et que ça donne une ambiance flippante à une scène qui ne montre qu'une peluche de chat au bout d'un bambou.

Maintenant que le RPi fonctionne, que Motion tourne quand on le lui demande et que la batterie est chargée, y'a plus qu'à se préparer à allumer le dispositif à la tombée de la nuit. Si j'en crois mes logs, j'ai tout branché à 19h56. D'après ce site, j'ai maximum 7h devant moi.

Et le projecteur ?

L'animal que je cible dort le jour et se déplace de nuit. Ma webcam est toute naze. Du coup, il me faut un truc qui éclaire la zone filmée en cas de passage de la bête. Un petit projecteur avec détecteur de mouvement fait le boulot.  

Un projecteur qui fonctionne sur batterie et une batterie pour le RPi : oui, pas moyen de tirer un câble électrique jusqu'à la zone cible.

Le résultat

On s'en doute, toute cette opération repose sur une chance folle. Et je crois avoir eu de la chance :


C'est mignon, non ? Moi, je suis très fier !

Si on s'amuse à récapituler la chance qu'il a fallu pour avoir 20 secondes d'images floues :
  • La lumière s'est allumée quand le hérisson est passé
  • Motion a bien sauvegardé le passage de la bête
  • La batterie a tenu jusqu'au passage de la cible
  • La webcam posée en équilibre n'est pas tombée
  • Tout ce bordel était au bon endroit
  • Quand la batterie a lâché, l'arrêt brutal du RPi n'a pas corrompu les vidéos
  • Branché peu avant 20h, tout s'est arrêté vers 1h20. Loin des 7h théoriques
Bref. Courage à toutes celles et ceux qui n'ont pas la chance de profiter d'un peu de verdure.

Des bisous

Coronavirus, confinements solidaires

Rédigé par dada / 17 mars 2020 / 1 commentaire


Je relaie modestement la dernière vidéo de DataGueule en espérant que le message touche plus de monde que le coronavirus.




Alors que l’épidémie de coronavirus continue de s’étendre en Europe, il est vital de rappeler un fait essentiel : le COVID-19 ne circule pas de lui-même, ce sont les hommes et les femmes qui le font circuler. Chacune et chacun d’entre nous peut donc agir pour limiter sa propagation et ralentir au plus vite l’engorgement dramatique de nos hôpitaux. La seule action cruciale, nécessairement collective, tient en trois mots : “Restons chez nous”.

Classé dans : / Mots clés : aucun

De l'alerting à base de logs

Rédigé par dada / 12 février 2020 / 2 commentaires


Cela fait un moment que je cherche un moyen de déclencher des alertes à partir d'erreurs spécifiques dans les logs. En fait, ça fait depuis la sortie de Loki que j'en rêve.



Pour rappel, le couple Loki/Promtail, permet de centraliser des logs dans Grafana pour les visualiser calmement plus tard. En gros, ça peut donner un truc comme ça, ou comme ça.
Après avoir mis tout ça en place, je trouvais dommage de ne pas pouvoir continuer l'intégration jusqu'au bout : repérer un message d'erreur dans des logs et transformer l'écran de monitoring en sapin de Noël.

En fait, c'était déjà possible, j'avais juste raté l'information !

Préambule

Ce dont je vais parler dans la suite du billet nécessite d'avoir déjà la stack Loki + Promtail + Grafana + Prometheus + Alert-manager. Ça demande un peu d'huile de coude et de temps mais ça s'installe très bien.

Les Pipelines

Promtail, comme tout exporter, expose des metrics de toute sorte. De base, il fait des choses simples, mais avec les Pipelines, on peut pousser le truc plus loin : ajouter le timestanp à une ligne de log, modifier des labels, ajouter clairement le numéro de ligne du log et, on y est, créer une metric custom !

Créer une metric custom

On va commencer par un exemple très simple :
scrape_configs:
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: varlogs
      __path__: /var/log/*log
      hostname: diaspodon.fr
  pipeline_stages:
  - match:
      selector: '{job="varlogs"}'
      stages:
      - regex:
          expression: ".*(?P<error_message>error_message.*)"
      - metrics:
          error_total:
            type: Counter
            description: "total count of errors"
            source: error_message
            config:
              action: inc
Ceci est une partie de la configuration du Promtail en place sur mon serveur Mastodon. Ce n'est pas la plus propre du monde mais ça fera l'affaire.

Le job

On y voit la configuration qui permet de remonter les logs système de /var/log/*.log avec le label varlogs et un hostname forcé :
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: varlogs
      __path__: /var/log/*log
      hostname: diaspodon.fr

Le pipeline

On enchaîne ensuite avec le fameux pipeline, que je vais présenter en deux parties : le selector et les metrics 

- La partie selector
  pipeline_stages:
  - match:
      selector: '{job="varlogs"}'
      stages:
      - regex:
          expression: ".*(?P<error_message>error_message.*)"
Le selector permet de s'y retrouver. On va aller chercher à bidouiller les logs du job varlogs, pas ailleurs. Le stage permet de mettre en place une expression régulière en RE2, la version Google est regexp, pour filtrer l'information dont on a besoin.
Ici, je veux qu'une action soit déclenchée à chaque fois que error_message apparaît dans les logs. Celles et ceux qui ont une instance Mastodon savent de quoi je parle. Pour les autres, c'est quand un message ne peut pas atteindre son destinataire. C'est très courant.

- La partie metrics

Pour finir, la partie metrics est carrément celle qui nous intéresse le plus : elle va, comme son nom l'indique, créer une metric qui sera remontée à Prometheus.
      - metrics:
          error_total:
            type: Counter
            description: "total count of errors"
            source: error_message
            config:
              action: inc
On va lire la configuration lentement : La variable error_total sera de type Counter avec la description "total count of errors" et sera alimentée par error_message, défini dans la regexp précédente (entre les <>). De 0, la variable sera incrémentée de 1 à chaque match.

Prometheus

Vérifier la configuration

Vous voyez le truc ? On vient de mettre en place une metric custom qui sera remontée par Promtail vers Prometheus. À l'heure où j'écris ces lignes, cette metric ressemble à ça :
root@diaspodon ~ # curl -s http://localhost:9080/metrics   | grep custom
# HELP promtail_custom_error_total total count of errors
# TYPE promtail_custom_error_total counter
promtail_custom_error_total{filename="/var/log/daemon.log",hostname="diaspodon.fr",job="varlogs"} 92831
promtail_custom_error_total{filename="/var/log/syslog",hostname="diaspodon.fr",job="varlogs"} 50050
On retrouve bien la metric déclarée dans Promtail : error_total, avec son nom complet : promtail_custom_error_total.

Vous me direz que ce n'est pas très joli et vous aurez parfaitement raison. C'est un exemple, juste un exemple !

Mettre en place de l'alerting

Maintenant que vous avez des données dans Prometheus, rédiger une règle d'alerting est assez simple. On devrait s'en sortir avec ce type de chose :
  - alert: Error_total
    expr: promtail_custom_error_total > 1
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Instance {{ $labels.instance }} is invaded by custom errors!"
Simple, rapide, efficace. Si une erreur apparaît, elle sera repérée et une alerte sera déclenchée. Y'a plus qu'à faut qu'on vérifier que votre installation spamme correctement les développeurs pour les mettre sur le coup rapidement.

Pour aller plus loin

Je viens de rapidement parcourir le sujet pour vous donner envie d'y mettre le nez. En l'état, la configuration proposée a un gros problème : une fois qu'une erreur est détectée, le Counter sera incrémenté et rien ne lui permettre de revenir à 0. C'est assez chiant.

J'ai deux façons de contourner le problème : la première avec les développeurs, la deuxième avec ses seuls moyens.

Si les développeurs sont adorables, ils peuvent mettre en place un petit bout de code qui va écrire dans les logs que tout est revenu à la normale. En passant du Counter à une Gauge, on peut dire à Promtail d'incrémenter la metric quand un souci est détecté puis de la décrémenter quand tout redevient fonctionnel. Ça permet de jongler entre 0 et 1 et pas plus.

Par contre, si vous êtes tout seul, vous pouvez tricher en décidant de mettre en place une règle d'alerting qui fait un rate() sur 1h, ou la durée que vous voulez, pour avoir des passages à vide et des périodes de souci. Ça permet d'éviter de passer d'un Counter à une Gauge mais ça demande à mettre un délai de retour au calme long et d'être assidu sur les chan/salon/mail d'alerting.

Bref, c'est encore un point sur lequel je réfléchis. Si vous avez des idées, je prends.

Enfin voilà.

Des bisous

Comment faire comprendre à quelqu'un qu'il a tort

Rédigé par dada / 25 janvier 2020 / 1 commentaire


Maintenant que le titre vous a bien attiré par ici, le voici en entier : Comment faire comprendre à quelqu'un qu'il a tort (et pourquoi c'est une mauvaise question).

Nous devons cet incroyablement trop long titre de vidéo à Mr.Sam (Peertube, Youtube), vidéaste sceptique belge. Je suis encore dans une période de découverte de ce mouvement dit sceptique et je dois bien avouer que j'y trouve beaucoup de jus de cerveau. Du coup, je vous invite à vous y pencher aussi. L'instance Skeptikon est votre amie.

En prélude, le toot de Mathdatech qui me semble être une incroyablement bonne entrée en matière :


Il résume presque à lui tout seul ce que fait comprendre la vidéo de 2h ci-dessous. Presque, puisque Mr.Sam n'oriente absolument pas son discours autour du logiciel libre. Pas du tout même.

Bref, maintenant, la vidéo :


Si je vous en parle dans ce blog de libriste convaincu, c'est que je trouve que nous serions bien avisés de tous tirer des leçons de ce que ce vidéaste prend le temps de nous expliquer.

Se concentrer sur le logiciel libre, mettre de côté tout ce qui n'a pas la bonne licence, exclure l'achat d'outils qui ne respectent pas les libertés fondamentales : c'est une démarche impossible à faire comprendre dans un dialogue frontal. C'est un engagement qui peut être vu comme une fantaisie qui n'apporte que des contraintes si le ou la libriste s'y prend mal lors de son explication. Et c'est foutu. Définitivement.

Du coup, prendre le temps de s'intéresser à la rhétorique, à l'art oratoire et à la construction du dialogue avec son interlocuteur doit faire partie de notre bagage de compétences si nous voulons lutter à armes égales avec les discours des startups ou autres GAFAM. Ils ont le savoir "faire rêver", nous avons des choix de société : c'est un combat incroyablement délicat et difficile.

Bref, je vous encourage vraiment à aller voir le travail de Mr.Sam et bon week-end à vous.

Se faire un réveil 4.0 avec un Raspberry Pi

Rédigé par dada / 15 janvier 2020 / 10 commentaires


Je me suis toujours méfié des objets connectés. Ce n'est un secret pour personne : une grande partie des babioles vendues sous la bannière IoT ou objet connecté sont des machins non sécurisés, non maintenus, non écologiques et d'un intérêt plus que discutable.


Ceci dit, avec l'aide de la WebThings Gateway de Mozilla, il est possible de commencer à jouer avec son matériel existant pour le rendre connecté. Ce truc permet de garder le contrôle des-dits machins connectés puisque le cerveau de ces choses sera dans votre salon et pas sur des serveurs obscurs à l'autre bout du monde.

Un exemple que je vous propose : mettre de côté votre ancien réveil, qui marche très bien, pour le remplacer par un Raspberry Pi.

Les ingrédients

Pour ce faire, il vous faudra :
  • un Raspberry Pi (du Zero au RP4)
  • des enceintes classiques
  • un câble jack
  • l'URL de streaming de FranceInfo

Le Raspberry Pi

Vous allez commencer par utiliser WebThings Gateway comme système d'exploitation de votre Raspberry Pi. C'est une Rasbpian, basée sur Debian donc, modifiée par Mozilla, rien de plus.
Je ne vais pas m'éterniser sur la procédure d'installation : c'est très simple.
Il suffit d'aller télécharger l'image disponible ici, de flasher la carte SD avec et de placer cette-dite carte dans l'ordinateur.

Une fois que la bête a démarré, un nouveau réseau Wifi va apparaître. Connectez vous y depuis votre PC et suivez la procédure de configuration :
  • connectez-la au réseau wifi de votre box
  • créez un compte utilisateur
  • choisissez l'URL qui va bien
L'attribution de l'URL peut prendre du temps, ne paniquez pas, ne touchez à rien : Mozilla vous enverra un lien par mail quand tout sera effectif.

Installer l'extension Radio

Par défaut, WTG ne fait pas grand chose. Tout comme pour Firefox, Mozilla s'appuie sur les gens pour fournir des extensions en pagaille. Et ça marche plutôt pas mal si j'en crois le dépôt officiel.

Je vous laisse cliquer dans les menus pour installer Radio : Settings > Add-ons > le + en bas à droite -> Internet radio. 

L'add-on vient avec quelques webradios inconnues au bataillon. Pas grave, on va installer celle qui nous intéresse : la radio d'État.


Pour récupérer l'adresse de streaming, je suis passé par ce lien qui m'a permis de trouver ça :
  • http://direct.franceinfo.fr/live/franceinfo-midfi.mp3
Il est possible que le flux change ou qu'il ne soit pas vraiment fonctionnel alors prenez le temps de le vérifier. L'autre jour, par exemple, j'avais bien un flux lu mais il ne contenait pas le moindre son : méfiez-vous.

Maintenant, vous devriez avoir WTG correctement configuré dans votre Raspberry Pi. Il ne reste plus qu'à créer la règle qui va permettre d'allumer tout ça aux heures voulues.

Mettre en place le réveil 4.0

WTG fonctionne, en gros, avec deux principes : les choses (things) et les règles (rules).

Les règles permettent de faire faire des choses à vos choses. Vous suivez ?


Dans le cadre du réveil, on va s'amuser à dire à WTG d'activer la chose radio, avec le volume qui va bien, à l'heure qui va bien. Le panneau de création d'une règle est coupé en deux :
  • À gauche, la ou les conditions d'entrée
  • À droite, la ou les conditions de sortie


On va remarquer la complexité relative de la règle puisqu'il faut :
- Deux choses Clock qui déclenchent deux événements à 7h du matin
- Une chose Radio qui allume la radio
- Une chose Radio qui fixe le volume

En une seule phrase, la logique ressemble à ça : À 7h du matin, tu allumes la radio et à 7h du matin, tu montes le volume à 75.
La partie volume de ma règle n'est pas obligatoire. Elle est présente dans mon exemple parce que le volume de base, 50, est trop faible à mon goût.

Aller un peu plus loin

Dans mon cas personnel, j'ai décidé d'ajouter une règle qui arrête la radio à 8h. Pourquoi ? Parce que je dois impérativement décoller à 8h sans quoi je rate mon train.


Si vous avez capté la logique, j'ai utilisé une chose Clock qui se déclenche à 8h et une chose Radio qui arrête la boucle d'informations du matin.

Et voilà !

Conclusion

Vous n'avez plus qu'à laisser votre imagination tourner. Avec WTG, vous pouvez avoir des objets connectés qui se contrôlent depuis un ordinateur dans votre salon que vous pouvez arrêter quand vous le voulez et qui est entièrement open-source.

C'est sans intérêt, donc indispensable ! Bonne année !