Enodev.fr / Christophe's log

Des robots pour visiteurs

Christophe Vu-Brugier — Sun, 26 Jan 2025 15:00:00 GMT

Quand je lis les journaux de mon serveur Web, j'ai l'impression que la plupart des visiteurs sont des robots.

La part des visiteurs qui s'identifient comme des robots via leur user agent est passée de moins de 30 % début 2024 à 40 % en décembre.

L'entraînement des modèles d'IA générative tels que les LLM nécessite un corpus toujours plus grand de données. Les entreprises du secteur ont donc développé des programmes qui parcourent le Web pour enregistrer le contenu des sites visités. Aux visiteurs de longue date que sont Googlebot et Bingbot se sont ajoutés GPTBot, ClaudeBot, Amazonbot, et bien d'autres.

Comment évaluer la part des robots parmi les visiteurs à partir des journaux ?

Les serveurs Web comme Apache enregistrent des informations sur les requêtes HTTP traitées dans un fichier journal des accès. Parmi ces informations figure l'en-tête user agent de la requête HTTP. Il s'agit d'une chaîne de caractère qui identifie le navigateur Web.

Le user agent des robots d'indexation contient en général les termes bot, crawler ou spider. Toutefois, un robot peut prétendre être un banal navigateur Web en usurpant son user agent.

Je suggère d'utiliser le logiciel libre Angle-grinder pour analyser le fichier journal des accès d'Apache et estimer le ratio des requêtes valides envoyées par des robots.

$ agrind -f a.log "* | apache | where status == 200 | if(contains(toLowerCase(contentlength), 'bot'), 1, 0) as bot_req | avg(bot_req) as bot_req_ratio"
bot_req_ratio
---------------------
0.40

Les pipelines, séparés par le caractère |, sont composés ainsi :

Toutes les entrées du fichier journal sont sélectionnées avec le caractère *.
Le parser pour le format du journal d'Apache interprète les champs.
Seules les requêtes dont le statut de réponse HTTP est 200 sont conservées. En effet, de nombreuses requêtes sont invalides et ne nous intéressent pas. Par exemple, des requêtes émanant de robots à la recherche de vulnérabilités à exploiter.
De façon étrange, le user agent est contenu dans le champ contentlength. Si le champ contient la chaîne de caractères "bot", on définit le champ bot_req à 1, sinon à 0. On peut étendre cette condition pour inclure les termes moins fréquents "crawler" et "spider".
Enfin, la valeur moyenne du champ bot_req est calculée.

Quels sont les robots les plus actifs ?

Voici la liste des cinq robots les plus actifs sur ce site en 2024.

Rang	Nom du robot	Propriétaire	Part des requêtes HTTP
1	Googlebot	Google	4.72 %
2	GPTBot	OpenAI	2.82 %
3	bingbot	Microsoft	1.50 %
4	YandexBot	Yandex	1.34 %
5	Bytespider	ByteDance	1.01 %

Comment a évolué l'activité des robots au cours de l'année ?

Les graphiques qui suivent représentent l'activité des robots les plus connus sous la forme d'une carte thermique du calendrier.

Chaque case symbolise un jour de l'année. Les jours se suivent verticalement du lundi au dimanche et sont groupés par mois. La couleur d'une case varie du jaune pâle au rouge foncé en fonction du nombre de requêtes HTTP reçues ce jour là.

Les graphiques sont affichés par la bibliothèque JavaScript Cal-Heatmap.

Googlebot

Très actifs, les robots de Google ont visité le site tous les jours en 2024.

GPTBot

Les robots d'OpenAI ont visité le site 212 jours en 2024. Rares en début d'année, ils ont été très présents en octobre.

Bingbot

Les robots de Microsoft ont visité le site tous les jours en 2024.

YandexBot

Les robots de Yandex ont visité le site 342 jours en 2024 mais ont été plus discrets à partir du mois de septembre.

Bytespider

Les robots de ByteDance ont visité le site 254 jours en 2024 et ont été plus actifs de juillet à septembre.

AmazonBot

Les robots d'Amazon apparaissent au septième rang et se distinguent dans leurs accès : ils indexent l'ensemble du site une fois par mois.

ClaudeBot

Classés au neuvième rang par leur activité, les robots d'Anthropic ont visité le site 50 jours en 2024, principalement en avril et en mai.

IA quelqu'un ?

Les robots représentent une part croissante des visiteurs de ce site. Ils deviendront peut-être majoritaires en 2025.

Toutefois, j'aimerais qu'ils butinent plus sobrement le contenu du site pour ne pas consommer inutilement ses ressources informatiques.

Ils pourraient s'inspirer de l'efficacité discrète de ce butineur insaisissable.

Un Moro-sphinx (Macroglossum stellatarum) butine du Chèvrefeuille.

XZ backdoor lessons: reproducing target-isns release tarballs

Christophe Vu-Brugier — Sat, 13 Apr 2024 09:00:00 GMT

Andres Freund detected a backdoor in XZ, a data compression library, and disclosed it as CVE-2024-3094 at the end of March 2024.

Many good articles describe how the attackers implanted the backdoor:

LWN: Free software's not-so-eXZellent adventure.
LWN: How the XZ backdoor works.
Russ Cox: Timeline of the XZ open source attack.

The attackers prepared the backdoor for more than two years and completed their work when they became maintainers. They published a release tarball with a malicious build script not present in the source code. The attackers uploaded the release tarball to GitHub.

I maintain target-isns, a niche free software project packaged in several Linux distributions. There is not much activity in the project because it is mostly done. The last release of target-isns – version v0.6.8 – happened in May 2020. I built the release tarball on my machine and uploaded it to GitHub.

I believe that one of the lessons of the XZ backdoor episode is "Trust, but verify". Applied to target-isns releases I published, this could mean:

How can users verify that the release tarball of target-isns matches the source code?
How can we improve the release process of target-isns to ease that verification?

How to verify a release tarball built with git-archive

target-isns is written in C and built with CMake. A custom target, named dist, invokes git-archive to generate a tarball of the source code. Ironically, the tarball is compressed with XZ.

To verify that the release tarball matches the source code, we must compare the checksum of the published release tarball with one built locally from the source code.

How to compute the checksum of the published release tarball

Let's download the release tarball for target-isns v0.6.8 from GitHub and compute its SHA256 checksum:

$ curl -OL --silent https://github.com/open-iscsi/target-isns/releases/download/v0.6.8/target-isns-0.6.8.tar.xz
$ sha256sum target-isns-0.6.8.tar.xz
544de09a2073242b21f6859841a5016c79c4006a53435a79b5cfc6602a59db97  target-isns-0.6.8.tar.xz

How to reproduce the release tarball from the source code

We clone the repository with git clone and checkout the tag we want with --branch v0.6.8:

$ git clone --branch v0.6.8 https://github.com/open-iscsi/target-isns.git
$ cd target-isns

The command git show v0.6.8 reports that the tagger (it's me) signed the tag with GnuPG.

My about page mentions the fingerprint of my public GnuPG key. We import that key ¹.

$ gpg --keyserver keyserver.ubuntu.com --search-key 81D01C4E399FFEDEDBD93D7F08390B7DF2FC1876
gpg: data source: http://185.125.188.27:11371
(1)     Christophe Vu-Brugier <cvubrugier@example.org>
          4096 bit RSA key 08390B7DF2FC1876, created: 2011-06-16
Keys 1-1 of 1 for "81D01C4E399FFEDEDBD93D7F08390B7DF2FC1876".  Enter number(s), N)ext, or Q)uit > 1
gpg: key 08390B7DF2FC1876: public key "Christophe Vu-Brugier <cvubrugier@example.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1

After importing my public key, we verify the tag with git tag --verify ¹:

$ git tag --verify v0.6.8
object 52e4fd427b1aff902ef4e7bce9a9c2f6b358a5eb
type commit
tag v0.6.8
tagger Christophe Vu-Brugier <cvubrugier@example.org> 1588947171 +0200

target-isns v0.6.8
gpg: Signature made Fri May  8 14:13:16 2020 UTC
gpg:                using RSA key 81D01C4E399FFEDEDBD93D7F08390B7DF2FC1876
gpg:                issuer "cvubrugier@example.org"
gpg: Good signature from "Christophe Vu-Brugier <cvubrugier@example.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 81D0 1C4E 399F FEDE DBD9  3D7F 0839 0B7D F2FC 1876

The tag signature is correct. We build a release tarball and compare its checksum with the published release tarball.

# mkdir build
$ cd build/
$ cmake ..
-- The C compiler identification is GNU 12.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /target-isns/build
$ make dist
Built target dist
$ sha256sum target-isns-0.6.8.tar.xz
544de09a2073242b21f6859841a5016c79c4006a53435a79b5cfc6602a59db97  target-isns-0.6.8.tar.xz

The checksum (544de09a) of the generated tarball matches the checksum of the published tarball: we reproduce the release tarball.

I reproduced the release tarball on Debian 12 (bookworm). Does that work with other Linux distributions?

Reproducing the release tarball from other Linux distributions

I use Podman to build the release tarball in several Linux containers.

Linux distribution	Release tarball reproduced	Git version	XZ version
Alpine 3.19.1	Yes	2.43.0	5.4.5
Arch Linux	No	2.44.0	5.6.1
Debian 11 (bullseye)	Yes	2.30.2	5.2.5
Debian 12 (bookworm)	Yes	2.39.2	5.4.1
Fedora 39	Yes	2.44.0	5.4.4
Ubuntu 22.04 (jammy)	Yes	2.34.1	5.2.5
Ubuntu 24.04 (noble, pre-release)	Yes	2.43.0	5.4.5
Rocky Linux 8	Yes	2.39.3	5.2.4
Rocky Linux 9	Yes	2.39.3	5.2.5

The release tarball is reproducible everywhere except on Arch Linux. The output of git archive is the same but XZ compresses the tarball differently. A binary search with git bisect finds the commit that introduce the change:

XZ: Use threaded mode by default (as if --threads=0 was used).

XZ (version 5.6.1) on Arch Linux compresses data with several threads by default. With --threads=1, we can force XZ to compress data with just one thread. With that, we can reproduce the release tarball of target-isns on Arch Linux.

Usually, there are different ways for a compressor to represent the original data. That's why a compressor output may differ when its algorithm or parameters change. To reduce the risk of compressed tarballs varying across platforms, target-isns releases could switch to a compressor less likely to change such as gzip.

Future work

While existing release tarballs of target-isns are reproducible, we should improve the release process.

Document the release process.: A document should describe how releases are made and how to reproduce them.
Setup a continuous integration pipeline to generate the release tarball from a tag.: A continuous integration job should automatically generate the release tarball from a tag. The job should run in a container (for example a Docker image). With that, users could reproduce the release tarballs by running the same container image on their machine.
Sign the release tarball with GnuPG.: The maintainer should download the tarball generated by the release pipeline, reproduce it, and test it. Then, they should publish the release tarball, the SHA256 checksum file, and sign these files with their private GnuPG key.

A crab spider (Misumena vatia) caught a bee.

I removed my email from the command output. ↩↩

Statistiques d'accès au site en IPv6

Christophe Vu-Brugier — Sat, 30 Sep 2023 20:55:42 GMT

Le mois dernier, j'ai observé que bien que mon serveur Web possédât une adresse IPv6, aucun navigateur Web ne s'y connectait via ce protocole. J'avais tout simplement oublié d'associer un enregistrement IPv6 address record au nom de mon domaine dans la zone DNS.

Un mois plus tard, la lecture des logs de mon serveur Web confirme qu'une partie des navigateurs Web s'y connectent en IPv6 et je peux mesurer dans quelle proportion.

Dites AAAA

Sur Internet, le service DNS associe les noms de domaine Internet avec leurs adresses IP.

La plupart des sites Internet déclarent des adresses IPv4 dans leur zone DNS à travers des enregistrements DNS A (A pour Adresse).

Conscients de l'épuisement des adresses IPv4, de plus en plus de sites Internet sont aussi accessibles en IPv6. Pour permettre aux navigateurs Web de résoudre leur nom de domaine en adresses IPv6, ils ajoutent des enregistrements DNS AAAA dans leur zone DNS. Les quatre "A" dénotent le fait qu'une adresse IPv6 (128 bits) est quatre fois plus longue qu'une adresse IPv4 (32 bits).

Sous Linux, l'outil dig permet d'effectuer des requêtes DNS en ligne de commande et donc de vérifier si un site Internet déclare être accessible en IPv4 et en IPv6.

Pour afficher l'adresse IPv4 associée à un nom de domaine :

$ dig +short enodev.fr A
159.69.222.76

Et pour obtenir l'adresse IPv6 éventuellement associée :

$ dig +short enodev.fr AAAA
2a01:4f8:1c1e:b2d0::1

Qui AAAAccède ?

Le fichier journal des accès du serveur HTTP Apache enregistre les requêtes qu'il a traitées.

Dans le format par défaut du fichier journal des accès, l'adresse IP du client figure au début de chaque ligne.

L'extrait de journal suivant présente une requête HTTP effectuée par un navigateur Web connecté en IPv4 suivie d'une requête formulée par un autre navigateur Web connecté en IPv6 :

24.35.90.123 - - [01/Oct/2023:00:03:20 +0200] "GET /posts/rusticity-convert-an-integer-to-an-enum.html HTTP/2.0" 200 6966 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36"
2a02:8308:285:e800:9807:3eea:1a93:1234 - - [01/Oct/2023:00:03:30 +0200] "GET /posts/rusticity-convert-an-integer-to-an-enum.html HTTP/2.0" 200 6966 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36 Edg/117.0.2045.43"

Analyse des accès avec Angle-grinder

Angle-grinder est un outil en ligne de commande qui permet d'interpréter des données en effectuant des opérations de tri, de sélection, de groupement, ou des calculs. Angle-grinder est notamment capable d'interpréter directement un fichier journal des accès d'Apache. Ceci va nous aider à mesurer dans quelle proportion les navigateurs Web se connectent au site en IPv6.

Voici une façon de compter le nombre d'adresse IP différentes qui se sont connectées au serveur HTTP avec Angle-grinder:

$ agrind -f apache.log "* | apache | count_distinct(ip) as unique_ipaddrs"
unique_ipaddrs
----------------------
5326

Les pipelines, séparés par le caractère |, sont composés ainsi :

Toutes les entrées du fichier journal sont sélectionnées avec le caractère *.
Le parser pour le format du journal d'Apache interprète les champs.
L'opérateur d'agrégation count_distinct() est appelé sur le champ nommé ip. La colonne de résultat est nommée unique_ipaddrs.

Pour dénombrer le nombre d'adresse IPv6 différentes, il suffit d'ajouter un filtre qui sélectionne les adresses IP qui contiennent le séparateur :.

$ agrind -f apache.log "* | apache | contains(ip, ':') as is_ipv6 | where is_ipv6 | count_distinct(ip) as unique_ipv6addrs"
unique_ipv6addrs
------------------------
500

9,4 % des navigateurs Web se connectent donc au site en IPv6. La part des requêtes HTTP effectuées en IPv6 est assez proche – 10 % – comme on peut le constater avec la requête suivante :

$ agrind -f apache.log "* | apache | contains(ip, ':') as is_ipv6 | if(is_ipv6, 1, 0) as ipv6_req | avg(ipv6_req) as ipv6_req_ratio"
ipv6_req_ratio
----------------------
0.10

Il sera intéressant de suivre la progression du ratio des accès réalisés en IPv6 dans le temps.

Note: en décembre 2024, 14 % des requêtes HTTP sont effectuées en IPv6.

Une épeire fasciée sur sa toile. Connectée en IPv6 ?

Réalisation d'un nichoir bûche

Christophe Vu-Brugier — Sat, 20 Mar 2021 15:00:00 GMT

Au printemps 2018, j'ai construit un nichoir pour mésange charbonnière à partir d'une grosse bûche. Cet abri a depuis accueilli plusieurs nichées, signe que les mésanges s'y plaisent. Puisque la période de nidification approche, voyons comment réaliser ce type de nichoir simple et rustique.

Matériel

Une bûche. Dans mon cas, les dimensions étaient les suivantes : longueur = 34 cm, diamètre = 18 cm.
Une hache à fendre.
Une scie à bûche.
Une scie à cloche.
Un marteau.
Des clous.
Des vis à bois.
Des pattes d'assemblage.

Étapes de construction

Scier deux rondelles aux extrémités. Elle constitueront la base et le toit.
Fendre la bûche en quatre dans le sens de la longueur.
Fendre chaque quartier en biais pour constituer la pièce à vivre.

Pour une mésange charbonnière, la surface au sol minimale est un carré de 10 cm de côté (0.01 m² loi Carrez). La hauteur sous plafond conseillée est d'environ 25 cm.
Dégrossir les bords intérieurs sans chercher à les rendre lisses : les aspérités permettent aux oiseaux de grimper.
Percer le trou d'envol. Le diamètre conseillé pour une mésange charbonnière est de 32 à 34 mm.
Clouer les murs à la base.
Visser les pattes de fixation pour finir d'assembler les murs.
Caler le toit. Le toit doit être amovible pour permettre de nettoyer l'intérieur du nichoir mais il ne doit pas s'envoler au moindre coup de vent.

Place à l'observation

La construction de votre nichoir bûche est achevée. Une fois solidement fixé à un arbre, nul doute qu'un couple de mésanges ne tardera pas à le remarquer et à y faire son nid douillet. À bonne distance – pour ne pas les déranger – vous aurez tout loisir d'observer leur va-et-vient incessant. Bonne observation !

Mésange charbonnière au nichoir

Fin du QIF à la Société Générale

Christophe Vu-Brugier — Fri, 22 Nov 2019 18:00:00 GMT

Mise à jour : le QIF est de retour à la Société Générale depuis février 2020. Mais cet article reste pertinent si vous préférez manipuler le relevé de vos opérations au format CSV.

J'utilise GnuCash depuis une dizaine d'années pour tenir mes comptes. J'ai l'habitude d'importer le relevé des opérations au format QIF dans GnuCash. Or depuis la refonte du site Internet destiné aux particuliers, la Société Générale ne propose plus l'export du relevé des opération au format QIF. À la place, la banque au carré rouge et noir propose un fichier CSV contenant les opérations réalisées au cours des six derniers mois.

Contactée, la Société Générale m'a informé « ne pas pouvoir changer le format proposé par le site ».

Je constate qu'à l'image des GAFAM, la Société Générale cherche à capter les données de ses clients pour les exploiter et néglige leur partage avec ces mêmes clients qui en sont pourtant les propriétaires. Ainsi, le site Internet de la Société Générale propose d'importer des comptes externes, c'est-à-dire tenus dans d'autres établissements bancaires. Mais quiconque veut rapatrier ses données doit se contenter d'un fichier CSV réduit à la portion congrue.

Nous allons étudier les problèmes liés au fichier CSV fourni par la Société Générale et développer ensemble ~~l'esprit d'équipe~~ une solution pour faciliter son import dans GnuCash.

Du CSV à la française

Après avoir téléchargé le fichier CSV, observons ses propriétés :

$ file Export_17052019_16112019.csv
Export_17052019_16112019.csv: ISO-8859 text, with CRLF line terminators

Le fichier est encodé en ISO 8859 et les retours à la ligne sont matérialisés par deux octets CR+LF comme il est d'usage sous Windows.

Que contiennent donc nos données ?

$ head Export_17052019_16112019.csv
="0201900016400270";17/05/2019;16/11/2019;
date_comptabilisation;libellé_complet_operation;montant_operation;devise;
15/11/2019;CARTE X7527 15/11 METRO    ;-14,90;EUR;
13/11/2019;VIR RECU    8527975563S DE: Boulot SAS MOTIF: BOULOT OCTOBRE 2019 33 REF: BOULOT OCTOBRE 2019 33;2188,28;EUR;
11/11/2019;PRELEVEMENT EUROPEEN 7997325297 DE: DODO GESTION ID: FR65ZZZ233162 MOTIF: 081 LOYER DODO;-614,50;EUR;
10/11/2019;CARTE X7527 10/11 RESTO    ;-11,00;EUR;
09/11/2019;CARTE X7527 09/11 BRICO    ;-14,50;EUR;

Nous avons affaire à la variante française du CSV qui utilise le point-virgule pour délimiter les colonnes et la virgule pour partager la partie entière et la partie décimale d'un nombre.

La première ligne débute par le numéro de compte. La notation ="0123" est une astuce pour indiquer à Microsoft Excel de préserver le zéro au début d'un nombre. Suivent les dates de début et de fin des données exportées. Les dates sont exprimées au format français JJ/MM/AAAA.

La deuxième ligne contient les intitulés de colonnes qui sont donc la date de comptabilisation, le libellé de l'opération, son montant et la devise. Nous remarquons que la ligne se termine par un séparateur point-virgule inutile.

Nettoyer le fichier CSV avec Pandas

Après avoir observé les données, nous ouvrons notre boîte à outils d'apprenti Data Scientist. Nous choisissons Python et Pandas. Python est un langage de programmation qu'on ne présente plus : il est même enseigné au Lycée. Pandas est une bibliothèque Python destinée à la fouille de données. Python et Pandas, voilà une excellente compagnie pour le paresseux que je suis.

Charger

La bibliothèque Pandas fournit la fonction read_csv() avec de nombreux paramètres permettant de nettoyer le fichier CSV.

import pandas as pd

df = pd.read_csv('Export_17052019_16112019.csv',
                 sep=';', decimal=',', header=1,
                 parse_dates=True, dayfirst=True,
                 usecols=range(4), index_col=0,
                 names=['date', 'description', 'amount', 'currency'],
                 encoding='ISO-8859-1')

Parmi les paramètres :

sep et decimal adaptent le comportement de read_csv() pour la variante française du CSV.
header indique que la ligne des entêtes est la deuxième ligne (la première ligne ayant pour indice zéro).
dayfirst sélectionne le format de date européen où le jour apparaît avant le mois (les États-Unis fêtent Noël le 12/25).
index_col précise que la première colonne – la date – sert d'index.

La fonction read_csv() retourne un objet de type DataFrame. Voici son contenu affiché par Python :

>>> df
                                                  description   amount currency
date
2019-11-15                        CARTE X7527 15/11 METRO       -14.90      EUR
2019-11-13  VIR RECU    8527975563S DE: Boulot SAS MOTIF: ...  2188.28      EUR
2019-11-11  PRELEVEMENT EUROPEEN 7997325297 DE: DODO GESTI...  -614.50      EUR
2019-11-10                        CARTE X7527 10/11 RESTO       -11.00      EUR
2019-11-09                        CARTE X7527 09/11 BRICO       -14.50      EUR

Filtrer

La version précédente du site Internet de la Société Générale proposait d'exporter les transactions au format QIF depuis le dernier téléchargement. La nouvelle mouture propose un export au format CSV des transactions des six derniers mois.

Par conséquent, nous sommes désormais contraint de relever dans GnuCash la date de la dernière transaction déjà importée afin de filtrer les données CSV à importer et limiter les doublons.

La première colonne – la date – ayant été choisie comme index, l'opération se fait simplement avec un slice :

>>> df = df['2019-11-15':'2019-11-13']
>>> df
                                                  description   amount currency
date
2019-11-15                        CARTE X7527 15/11 METRO       -14.90      EUR
2019-11-13  VIR RECU    8527975563S DE: Boulot SAS MOTIF: ...  2188.28      EUR

Distinguer les dépôts et les retraits

Le CSV exporté depuis le site Internet de la Société Générale comprend une seule colonne montant. Or GnuCash exige de distinguer dépôt et retrait.

Nous devons donc ajouter deux colonnes au tableau et les remplir à partir du montant.

Pour une transaction donnée :

Si le montant est positif, il s'agit d'un dépôt. Nous copions la valeur du montant dans la colonne dépôt et nous écrivons zéro dans la colonne débit.
Si le montant est négatif, il s'agit d'un retrait. Nous copions la valeur absolue du montant dans la colonne retrait et nous écrivons zéro dans la colonne dépôt.

Avec Pandas, les colonnes dépôt et retrait peuvent être calculées à partir du montant de la manière suivante :

df['deposit']  = df['amount'].apply(lambda x: x if x > 0 else 0)
df['withdraw'] = df['amount'].apply(lambda x: abs(x) if x < 0 else 0)

En Python, le mot clé lambda définit une fonction anonyme. Dans la première instruction, la colonne dépôt est remplie en appliquant au montant la fonction qui pour x retourne x s'il est positif et 0 dans le cas contraire.

Voici à quoi ressemble notre tableau suite à l'ajout des colonnes dépôt et retrait :

                                                  description   amount currency  deposit  withdraw
date
2019-11-15                        CARTE X7527 15/11 METRO       -14.90      EUR     0.00      14.9
2019-11-13  VIR RECU    8527975563S DE: Boulot SAS MOTIF: ...  2188.28      EUR  2188.28       0.0

Exporter à destination de Gnucash

La méthode to_csv() permet de sauvegarder un DataFrame dans un fichier au format CSV.

df.to_csv('gnucash.csv',
          sep=';', decimal=',',
          columns=['description', 'deposit', 'withdraw'])

Seules sont exportées les colonnes utiles à GnuCash : date (implicite car il s'agit de l'index), description, dépôt, et retrait.

Notre fichier CSV « nettoyé » est prêt à être importé dans GnuCash.

Importer le fichier CSV final dans GnuCash

Dans l'interface graphique de GnuCash, nous cliquons sur : fichier → importer → importer des transactions depuis un CSV.

Après avoir sélectionné notre fichier CSV, GnuCash nous présente la fenêtre d'aperçu de l'import.

Nous appliquons les réglages suivants :

Le point-virgule est défini comme séparateur de colonnes.
La première ligne qui correspond à l'entête est ignorée.
Le type des données de chaque colonne est précisé.
Un compte cible est renseigné pour l'ensemble des transactions (champ account).

Le wiki de GnuCash décrit plus en détail comment importer des transactions au format CSV.

Pour aller plus loin

Le script csv-socgen.py reprend l'ensemble du code présenté ici. Il ne s'agit que d'un premier jet.

Le script mérite d'être amélioré pour remplir automatiquement le compte destinataire et modifier la description si elle correspond à un motif donné. Ainsi, le compte destinataire de la transaction ayant pour description METRO serait automatiquement renseigné en Dépenses:Transports publics:Métro. Remarquons que la banque affiche une catégorie pour chaque transaction sur son site Internet mais que cette information ne figure pas dans le fichier CSV. À nous de ruser.

Un ancien slogan de la Société Générale clamait « On est là pour vous aider ». Cette ambition a disparu en 2019 avec un slogan devenu « C'est vous l'avenir ». Alors, ne comptez que sur vous-même pour tenir vos comptes !

Rénovo X240 Full HD

Christophe Vu-Brugier — Sat, 31 Mar 2018 17:12:24 GMT

Après avoir réparé le clavier, voici venu le moment d'améliorer l'écran de mon Lenovo ThinkPad X240 pour le confort de mes petits yeux.

La lecture de ce fil de discussion sur Reddit m'a convaincu de remplacer l'écran LCD d'origine d'une résolution de 1366×768 pixels par un modèle Full HD plus récent atteignant 1920×1080 pixels.

J'ai opté pour le modèle d'écran LCD suivant: 00HN899. Je l'ai acheté sur eBay pour un peu moins de 80 euros et je l'ai reçu chez moi deux jours plus tard en provenance de Tallinn (Estonie).

Je me suis assuré que le câble qui relie la carte mère à l'écran est compatible Full HD : la mention FHD figure bien sur le câble et je n'ai donc pas eu besoin de changer le câble.

L'écran LCD est maintenu par des clips sur ses bords et son démontage ne nécessite aucun outil particulier comme illustré dans cette vidéo.

Sous Debian, j'ai constaté que l'affichage était plus fin mais que les polices de caractères étaient bien trop petites pour être lisible. Par défaut, le serveur graphique X définit la résolution à 96×96 DPI. J'ai corrigé le problème en augmentant la résolution à 144×144 DPI dans le fichier ~/.Xresources. Il faut définir le paramètre Xft.dpi:

$ grep dpi ~/.Xresources
Xft.dpi: 144

Rénovo X240

Christophe Vu-Brugier — Sun, 29 Oct 2017 14:18:25 GMT

J'ai récupéré un ordinateur portable Lenovo ThinkPad X240 pour lui donner une seconde jeunesse¹. Au départ, il s'agissait simplement de changer le clavier qui était défectueux depuis qu'il avait été aspergé d'une tasse de café. Et puis la loi de Murphy a frappé une deuxième fois cette machine.

La gamme des ordinateurs ThinkPad est très répandue en entreprise ce qui explique qu'on trouve aisément des pièces de rechange. Après avoir suivi les instructions de cet excellent tutoriel vidéo pour changer le clavier, je démarrais l'ordinateur déjà fier de ma réparation. Aussitôt, j'entendis un léger claquement – Plop – accompagné par l'odeur âcre d'un composant électronique qui venait de brûler. Le message d'erreur suivant s'affichait à l'écran : Fan error. Ça ne sentait pas bon…

Effectivement, le ventilateur ne tournait plus ce qui interrompait la séquence de démarrage. J'essayais alors une astuce trouvée sur Internet : lors du démarrage, je soufflais fortement à travers la sortie d'aération du ventilateur pour le mettre en mouvement et faire croire au BIOS que le ventilateur fonctionnait. L'ordinateur démarrait bien mais le ventilateur demeurait immobile sous Linux ; je décidais sagement d'éteindre la machine pour éviter que son processeur ne surchauffe.

Le lendemain, je démontais le ventilateur pour le tester séparément. Ne disposant pas d'une source de courant continu de 5 volts, j'en bricolais une en coupant un câble USB. En effet, entre le fil rouge et le fil noir, la tension est de 5 volts. Ainsi alimenté, le ventilateur brassait l'air à plein régime.

En observant avec plus d'attention la carte mère, je remarquais une tâche noire à côté du connecteur du ventilateur. Je tenais le coupable : un composant électronique avait bel et bien grillé.

À ce stade, je ne connaissais ni la nature ni les caractéristiques du composant qui avait grillé. Heureusement, un collègue trouvait sur ce forum les schémas électroniques du Lenovo X240². À la page 50 du document, se trouvait la réponse à ma question : le défunt composant était un fusible qui pouvait supporter un courant d'une intensité de 2 ampères. Il a eu très chaud !

J'ai la chance de travailler dans l'électronique grand public et d'avoir des collègues électroniciens qui savent souder des composants montés en surface. Ils sont très adroits parce que les composants montés en surface sont minuscules (à titre d'exemple le fusible mentionné mesure 1 mm × 0.5 mm). Il n'aura fallu que cinq minutes à l'un de mes collègues pour remplacer le regretté fusible par un fil, faute de disposer d'un remplaçant³. Voici le résultat :

Et le patient dans tout ça ? Il se porte bien puisque c'est depuis le Rénovo X240 que j'écris ces lignes.

Merci Guillaume. ↩
Merci Rémi. ↩
Merci Jean-Luc. ↩

Rusticity: convert an integer to an enum

Christophe Vu-Brugier — Wed, 06 Sep 2017 18:00:00 GMT

I am learning how to program in Rust. Thinking in Rust is a delightful experience and the more I practice Rust the more I feel how it empowers developers to solve complex problems with confidence.

However, I sometimes get frustrated on my way to rusticity. For instance, when a programming task easily done in C or Python requires more work in Rust. I experienced this when trying to convert an integer to an enum. This blog post compares how this is usually done in C and how to do it safely in Rust.

Converting an integer to an enum in C

In C, the enumeration constants have the type int. Thus, an integer value can be directly assigned to an enum.

#include <stdio.h>

enum atomic_number {
    HYDROGEN = 1,
    HELIUM = 2,
    // ...
    IRON = 26,
};

int main(void)
{
    enum atomic_number element = 26;

    if (element == IRON) {
        printf("Beware of Rust!\n");
    }

    return 0;
}

While it is easy to assign an integer value to an enum, the C compiler performs no bounds checking. Nothing prevents us from assigning an impossible value to an atomic_number enum.

Converting an integer to an enum in Rust, the naïve way

Let's write a similar program in Rust:

enum AtomicNumber {
    HYDROGEN = 1,
    HELIUM = 2,
    // ...
    IRON = 26,
}

fn main() {
    let element: AtomicNumber = 26;
}

When we try to compile and run the program with cargo run, the Rust compiler reports a mismatched types error:

error[E0308]: mismatched types
 --> src/main.rs:9:33
  |
9 |     let element: AtomicNumber = 26;
  |                  ------------   ^^ expected enum `AtomicNumber`, found integer
  |                  |
  |                  expected due to this

The compiler error clearly indicates that AtomicNumber and integer are two different types.

To explicitly convert an integer to our AtomicNumber enum, we can write a conversion function that takes an unsigned 32-bits integer as parameter and returns an AtomicNumber.

enum AtomicNumber {
    HYDROGEN = 1,
    HELIUM = 2,
    // ...
    IRON = 26,
}

impl AtomicNumber {
    fn from_u32(value: u32) -> AtomicNumber {
        match value {
            1 => AtomicNumber::HYDROGEN,
            2 => AtomicNumber::HELIUM,
            // ...
            26 => AtomicNumber::IRON,
            _ => panic!("Unknown value: {}", value),
        }
    }
}

fn main() {
    let element = AtomicNumber::from_u32(26);
}

The from_u32() function is an associated function of the AtomicNumber type because it is associated with that type, and unlike a method does not take a first parameter named self.

There are several issues in from_u32():

When the given value does not match any variant in the enumeration, panic!() terminates the program.
Both the enumeration definition and the conversion function match enumeration variants with integers. This duplication is error-prone.
The conversion function grows with the number of variants.

The periodic table contains more than 100 elements. Implementing a conversion function for atomic numbers is boring and error-prone. There is a better way.

Converting an integer to an enum in Rust with num-derive

A more elegant solution is to use the FromPrimitive trait from the num crate coupled with syntax extensions from the num-derive crate.

In Cargo.toml, add dependencies for num, num-derive, and num-traits:

[dependencies]
num = "0.4"
num-derive = "0.4"
num-traits = "0.2"

Then, use the #[derive] attribute:

extern crate num;
#[macro_use]
extern crate num_derive;

#[derive(FromPrimitive)]
enum AtomicNumber {
    HYDROGEN = 1,
    HELIUM = 2,
    // ...
    IRON = 26,
}

fn main() {
    let element = num::FromPrimitive::from_u32(26);
    match element {
        Some(AtomicNumber::IRON) => println!("Beware of Rust!"),
        Some(_) => {},
        None => println!("Unknown atomic number")
    }
}

The #[derive(FromPrimitive)] attribute instructs the Rust compiler to generate a basic implementation of the FromPrimitive trait for the AtomicNumber enumeration. Unlike our handwritten from_u32() function, the conversion function generated by the Rust compiler returns an Option which is either Some atomic number or None if the given integer does not match any known atomic number. This is much safer than calling panic!().

With the #[derive(FromPrimitive)] attribute our Rust program is nearly as concise as the same program written in C with the bonus of being safer.

Harder, better, safer, rustier

While I had some hard time figuring how to convert an integer value to an enum variant in Rust, I feel reassured by its type safety and pleased by its ecosystem of crates.

Rust on the pont de Bir-Hakeim

Le paquet targetcli-fb intègre Debian

Christophe Vu-Brugier — Tue, 20 Dec 2016 19:00:00 GMT

Depuis quelques mois, le paquet targetcli-fb qui permet de configurer une target iSCSI avec LIO fait partie de Debian Testing (la version en cours de développement de Debian 9 "Stretch").

L'intégration de targetcli-fb vient combler un manque dans Debian. En effet, aucun utilitaire n'est fourni dans l'actuelle Debian Stable (Debian 8 "Jessie") pour configurer une target iSCSI avec LIO.

Je participe à la maintenance du paquet targetcli-fb dans Debian avec deux contributeurs plus expérimentés : Christian Seiler et Ritesh Raj Sarraf. J'utilise Debian depuis de nombreuses années et c'est un juste retour des choses que de contribuer modestement (et librement) au projet.

L'iSCSI sous Linux étant un sujet rarement traité sur le web francophone, j'évoquerai comment s'en servir dans un futur article.

Time-lapse de fleurs de safran

Christophe Vu-Brugier — Tue, 01 Nov 2016 15:00:00 GMT

Mi octobre, j'ai eu le plaisir d'assister à l'ouverture des fleurs de safran (Crocus sativus) dans le potager de mes parents. L'occasion était belle de fixer sur la ~~pellicule~~ carte SD les étapes de la floraison pour en faire un time-lapse.

Cette vidéo accélérée 1500 fois a été réalisée en prenant une image toutes les 5 minutes puis en générant une vidéo qui fait défiler 5 images par seconde.

Pour réaliser la vidéo, j'ai employé deux logiciels en ligne de commande : ImageMagick et ffmpeg. ImageMagick a permis de recadrer, redimensionner et légender chaque image tandis que ffmpeg a été utilisé pour combiner les images en une vidéo au format H.264.

Recadrage et redimensionnement

Au moment de la prise de vue, j'ai oublié de configurer mon appareil photo pour prendre des clichés aux dimensions de la vidéo finale : 1920×1080 pixels. J'ai donc enregistré des images dont les dimensions étaient trop grandes : 4608×3456 pixels (ratio ⁴⁄₃). Il a fallu recadrer et réduire chaque image à sa dimension finale : 1920×1080 pixels (ratio ¹⁶⁄₉).

Les deux étapes de recadrage et de redimensionnement ont été réalisées par une seule commande convert en utilisant les options -crop et -resize :

$ convert -crop 3840x2160+0+1130 -resize 50% source.jpg destination.jpg

Cet appel à la commande convert recadre d'abord l'image aux dimensions 3840×2160 en décalant le cadre de 1130 pixels vers le bas (et 0 pixel vers la droite) puis divise ses dimensions par deux pour aboutir à une image de 1920×1080 pixels.

Extraction de l'heure de prise de vue et ajout de la légende

J'ai extrait la date et l'heure de la prise de vue pour chaque image avec le programme exiftool :

$ exiftool -DateTimeOriginal image.jpg
Date/Time Original              : 2016:10:17 08:37:09

Ensuite, j'ai utilisé la commande convert pour ajouter une undercolor box qui contient la légende.

$ convert source.jpg -pointsize 50 -font Inconsolata -fill white -undercolor '#00000080' -annotate +8+50 " Légende " destination.jpg

La légende est écrite en caractères blancs (-fill white) de 50 points de hauteur (-pointsize 50), dans une police à chasse fixe (-font Inconsolata). Un fond noir en semi transparence (-undercolor '#00000080') augmente la lisibilité.

Création de la vidéo au format H.264 à partir des images

La dernière étape a consisté à combiner les images en une vidéo avec ffmpeg.

$ ffmpeg -framerate 5/1 -i image-%03d.jpg -c:v libx264 -pix_fmt yuv420p -r 30 video.mp4

Les images défilent au rythme de cinq par seconde (-framerate 5/1) et le codec vidéo choisi est x264 pour coder un flux vidéo H.264 (-c:v libx264). J'ai du contraindre le pixel format avec -pix_fmt yuv420p parce que Firefox 45 considère que la vidéo est corrompue quand le pixel format par défaut (yuv422p) est employé.