emlwks999

Lanceur automatique d'agent ssh éphémère

2026-01-08T22:46:54+01:00

Lanceur automatique d'agent ssh éphémère

Palaiseau, le 8 janvier 2026

Cher Journal,

J'ai régulièrement besoin de travailler avec un agent ssh par machine, mais en ayant simultanément de multiples terminaux sur ladite machine, histoire de mieux profiter de l'agent sur toutes mes connexions. Au fur et à mesure du temps qui est passé, j'ai raffiné mon approche afin de m'assurer que je n'accumule pas d'agents oubliés jusqu'au prochain redémarrage de la machine, que j'ai bien accès au même agent depuis de multiples connexions simultanées, ou que je sois en mesure d'arrêter un agent immédiatement après m'être déconnecté d'un système, sans attendre une expiration de la clé privée en mémoire. Le résultat est deux morceaux de code répartis dans les scripts de login et de logout de mon shell, en l'occurrence bash.

Mon fichier ~/.profile contient le segment de code suivant, qui consiste essentiellement à essayer de retrouver dans la table des processus, un ssh-agent que je puisse utiliser pour stocker et récupérer mes clés SSH privées après les y avoir stockées avec ssh-add, la dernière étape du script consistant à vérifier que le ssh-agent est bien installé et à le démarrer s'il n'y en avait aucun en route :

# start up an SSH agent, or try to hook to an existing one if any
SSH_AGENT_PATTERN='(([/]usr)?[/]bin[/])?ssh-agent'
SSH_AGENT_CMDLINE="$( \
	grep -El "$SSH_AGENT_PATTERN" /proc/*/cmdline 2> /dev/null || true
)"
if [ -n "$SSH_AGENT_CMDLINE" ]
then
	SSH_AGENT_PID="$( \
		echo "$SSH_AGENT_CMDLINE" \
		| sed -n 's@/proc/\(.*\)/cmdline@\1@p' \
	)"
	SSH_AUTH_SOCK="$( echo $HOME/.ssh/agent/s.*.agent.* )"
	# Check for old style ssh-agent socket if new style is not found.
	if [ "$SSH_AUTH_SOCK" = "$HOME/.ssh/agent/s.*.agent.*" ]
	then SSH_AUTH_SOCK="$( echo /tmp/ssh-*/agent.* )"
	fi
	if [ -r "$SSH_AUTH_SOCK" ]
	then
		export SSH_AGENT_PID SSH_AUTH_SOCK
		printf 'Existing agent running with PID %s at %s\n' \
			"$SSH_AGENT_PID" \
			"$SSH_AUTH_SOCK"
	else
		printf 'WARNING: ssh-agent running with PID %s, but without\n' \
			"$SSH_AGENT_PID"
		printf '         a usable socket.  Please investigate!\n'
			
	fi
elif command -v ssh-agent > /dev/null
then
	printf 'ssh-agent: '
	eval $(ssh-agent)
fi
unset SSH_AGENT_PATTERN
unset SSH_AGENT_CMDLINE

L'intérêt de mettre ce segment de code dans le fichier ~/.profile est que je peux également m'en servir tel quel pour les situations où j'utilise un Bourne Shell classique, comme le Debian Alquimst Shell « dash ». J'ai par ailleurs un script de nettoyage dans mon fichier ~/.bash_logout qui va compter le nombre de sessions qui me restent sur la machine. S'il ne reste plus de sessions, alors l'agent est arrêté ; il faut noter que le comptage a lieu dans un sous-shell comptant comme une session à part :

# Don't run when ps is not available, this mostly means we are just leaving
# a minimal schroot at the moment.
if ! command -v ps > /dev/null 2>&1
then return
fi

# Check whether there are still some login shells running, and if not, then
# shutdown all agents (and not just the one recorded in the environment).
NRSHELLS="$(
	ps aux \
	| grep '^'"$USER"' .* \([-]bash\|bash  *[-]l\|bash  *[-]-login\)$' \
	| wc -l
)"

printf 'login shells left: %s\n' "$NRSHELLS"

# Remark one needs to accout for the running subshell.  Note also that
# some operating systems may dupplicate the number of occurrences of
# bash, due to leftover `sh -c bash` processes, so the figure needs to
# be set to three under such circumstances.
if [ "$NRSHELLS" -le 2 ]
then
	SSH_AGENT_PATTERN="^$USER"' .* \(\(\/usr\)\?\/bin\/\)\?ssh-agent'
	SSH_AGENT_PIDS="$(
		ps aux \
		| sed -n "/$SSH_AGENT_PATTERN/ s/^$USER"' \+\([^ ]\+\) .*/\1/ p'
	)"
	for PID in $SSH_AGENT_PIDS
	do
		printf 'killing ssh-agent %s\n' "$PID"
		kill "$PID"
	done
	unset SSH_AGENT_PATTERN SSH_AGENT_PIDS PID
fi
unset NRSHELLS

Je ne crois pas qu'il y ait d'équivalent au ~/.bash_logout en Bourne Shell, mais c'est mieux que rien. Le mécanisme exposé est suffisamment robuste pour capturer des service ssh-agent ayant été démarrés par des services systemd ou bien par des environnements de bureau. Il peut être nécessaire de raffiner un peu le SSH_AGENT_PATTERN en fonction des situations, par exemple si ssh-agent est invoqué pour lancer l'environnement graphique lui-même : longtemps la commande générique a été x-session-manager, puis depuis que j'utilise Sway pour bénéficier de Wayland, l'agent ssh se trouve lancer directement sway. Je ne garantis pas de la robustesse de l'ensemble à toutes les situations qui pourraient se présenter dans la nature, mais jusqu'à présent je n'ai jamais eu à m'en plaindre. Ou alors, si j'ai eu à m'en plaindre, je me suis dépêché de faire les ajustements nécessaires pour que ce ne soit plus le cas.

Corrections du 10 janvier : j'ai initialement rédigé cette entrée pour reporter ces segments de code dans un environnement professionnel et noté quelque problèmes qui n'ont pas survécu aux subtiles variations d'environnement avec ce que j'ai implémenté à la maison. D'une part, la socket (chaussette ? Merci Vincent Bernat…) peut apparaitre dans un sous-répertoire du home correspondant au glob ~/.ssh/agent/s.*.agent.* ou bien /tmp/ssh-*/agent.* pour les implémentations plus anciennes ; j'avais initialement oublié le second glob, mais c'est corrigé. D'autre part, j'ai commis une erreur de débutant en inversant les chevrons des scripts au moment de la conversion en HTML préformaté. Une fois ces deux soucis corrigés, j'ai pu utiliser mes agents ssh comme j'en ai l'habitude.

Mises à jour de « carnet »

2025-08-03T20:07:37+02:00

Mises à jour de « carnet »

Palaiseau, le dimanche 3 août 2025

Cher Journal,

Faisant suite à ma publication de carnet à la fin du mois de juin, j'ai continué à produire des mises à jour à intervalles réguliers, pour corriger des bogues et rajouter des fonctionnalités qui se sont avérées utiles pour moi. Dans ma précédente entrée de blog, le carnet était mis à disposition en version 1.1.2. Il est désormais disponible en version 1.6.1. Je suis la nomenclature de version sémantique, c'est-à-dire que le numéro majeur n'est changé que quand j'introduis des changements cassants, par exemple je sortirais carnet en version 2 quand j'aurais décidé de changer le format des entrées pour faciliter certaines tâches. Les numéros de version successives suggèrent donc l'introduction de nombreuses nouveautés.

1.2.y : limite de temps

En version 1.2, j'ai introduit une variable d'environnement CARNET_OVERTIME, permettant de configurer un mécanisme d'alerte quand le temps passé à remplir des entrées de carnet devient excessif par rapport à l'heure de la première entrée. C'est utile pour limiter le temps d'écran dans une journée, dans une certaine mesure, mais comme le suggère le nom de la variable, la fonctionnalité est avant tout prévue pour limiter le risque d'entrer dans un régime d'heures supplémentaires. La détection de temps excessif ne tourne pas par défaut. Elle est activée quand CARNET_OVERTIME contient un entier décrivant le temps standard à passer entre la première et la dernière entrée de carnet sur une journée. Quelqu'un travaillant en trois huit peut ainsi avoir un tel export dans ses fichiers de configuration du shell :

CARNET_OVERTIME=8
export CARNET_OVERTIME

Quelqu'un ayant un temps de travail de sept heures trente quotidienne avec une pause déjeuner d'une heure trente pourrait ajuster la variable à :

CARNET_OVERTIME=9
export CARNET_OVERTIME

Les alertes se matérialisent alors dans le champs libre après l'horaire. Voici un exemple tiré de la page d'accueil révisée de carnet :

________________________________________________________________________
Date : Wednesday (2025-07-09)

09:23 :
Starting the day,

[…]

18:42 : warning: overtime for 19m.
Ouch, I'm running late, it's time to go.

Pour l'instant, le détecteur d'heures supplémentaires ne prend que les heures entières, mais je serais bien inspiré d'inclure le support des minutes en plus des heures afin de permettre un grain plus fin pour ajuster le temps de travail.

1.3.y : feuillets

La série 1.3.y de carnet a introduit la notion de feuillets. Chaque entrée saisie dans le carnet est un feuillet, qui peut être référencé par sa date et son heure dans un format rappelant la RFC 3339, à savoir : AAAA-MM-JJThh:mm. Par exemple, j'ai gardé la référence d'un feuillet enregistré le 5 juillet dernier à 23:34 et je souhaite m'y référer :

$ carnet -f 2025-07-05T23:34
/home/emollier/doc/carnet/2025-27.txt:560
23:34 : sur fond de : Oddland - Skylines
Je viens d'implémenter le système de navigation dans les feuillets.  Le
mécanisme se compose de multiples modifications.  La plus évidente est
l'ajout de l'option --feuillet, que je mentionne déjà dans mon entrée du
2025-07-05T18:23.  J'ai quelque craintes que l'option ne soit confuse au
premier abord, […]

Le mécano est accompagné d'un subtil ajustement de l'affichage des feuillets, qui met visuellement en valeur les références à d'autre feuillets dans le format spécifié ci-dessus. Cela facilite la navigation d'un feuillet à l'autre, ce qui peut amener à des résultats intéressants dans les carnets densément référencés entre feuillets :

$ carnet -f 2025-07-05T18:23
/home/emollier/doc/carnet/2025-27.txt:499
18:23 :
J'ai passé un petit coup de balai.  Pour l'idée de faire un Zettelkasten
en utilisant le carnet (Cf: 2025-07-05T11:25), il me faut deux choses :

  * construire facilement un marqueur pour référencer un ticket par sa
    date et son heure, ce que je peux faire très simplement en ajustant
    le format de sortie de la fonction de recherche ; manifestement je
    pars sur un format YYYY-MM-DDThh:mm, parce que c'est ce qui me
    semble le plus évident ;
  * ajouter une option pour référencer une entrée par son marqueur ;
    j'hésite sur le nom de l'option, peut-être quelque chose comme
    --feuillet ?

On voit ainsi un début de navigation de référence en référence dans une base de connaissances. Le mécanisme vient en complément du moteur de recherche, qui est ajusté pour l'occasion pour indiquer les références des feuillets ressortis lors de la recherche :

$ carnet --search sauvegarde | head -n5
2024-42.txt : vendredi (2024-10-18T18:33) :
Le mécano de surveillance de mes sauvegardes manuelles sur mes disques
externes me signale que je n'ai pas lancé de `backup` depuis plus de
vingt-quatre heures.  Je viens de corriger ça, la sauvegarde devrait
être terminée dans quelque minutes.

$ carnet -f 2024-10-18T18:33
/home/emollier/doc/carnet/2024-42.txt:357
18:33 :
Le mécano de surveillance de mes sauvegardes manuelles sur mes disques
externes me signale que je n'ai pas lancé de `backup` depuis plus de
vingt-quatre heures.  Je viens de corriger ça, la sauvegarde devrait
être terminée dans quelque minutes.

J'ai accompagné cette fonctionnalité d'un fichier de registre nommé register.txt, à placer dans le répertoire contenant le carnet (par défaut ~/Documents/carnet). Il s'agit d'un texte de forme libre, mais dans lequel il est encouragé de noter des références vers des feuillets d'intérêt, qui sont par exemple fortement connectées à des sujets d'intérêt stockés dans le carnet. Le fichier peut être récupéré automatiquement si l'on passe l'option --feuillet sans préciser de référence Mon fichier de registre correspond à peu près à ceci, quoique pour la brièveté les références et les mots clés sont limités à un exemple, et enregistre d'une part des références et d'autre part des mots clés pour le moteur de recherche :

$ carnet --feuillet
Registre des entrées d'intérêt
==============================

Notice
------

        $ carnet -f YYYY-MM-DDThh:mm  # références
        $ carnet -s YYYY-MM-DDThh:mm  # références inverses
        $ carnet -s '<motif>'       # mots clés


Références
----------

2025-07-27T17:02 : jalons pour carnet version 2.


Mots clés
---------

<debian>
        Le système d'exploitation, contient les références à mon
        activité au sein du projet Debian.

Comme toujours, les références seront en surbrillance pour faciliter le copiage et le collage, facilitant du même coup la navigation entre les entrées.

1.4.y : gestion de tâches

J'ai essayé tant bien que mal d'examiner un certain nombre d'outils de gestion de tâche pendant un certain nombre d'années. Fort de l'expérience des systèmes de suivi de ticket professionnel, j'ai cherché pendant longtemps quelque chose d'assez léger pour être utilisable machinalement, mais en même temps suffisamment tolérant pour qu'une simple tâche en apparence puisse se transformer en véritable projet. À ce titre, j'ai essayé cil pendant plusieurs années, alors même que le projet est archivé par son auteur en amont, depuis 2018. Bien que l'outil ait été presque approprié à mon cahier des charges, il y a quelque chose qui n'est jamais passé, quelque chose que je n'ai toujours pas réussi à déterminer, mais qui a à voir avec la fluidité d'utilisation de l'outil. J'ai fini par remarquer que j'avais tendance à laisser des notes dans mes cahiers, sous forme de choses à faire marquées par un TODO en début de ligne ou par un carré blanc, à remplir pour matérialiser une tâche résolue. J'ai pu éventuellement retrouver ce genre de marques dans mon carnet dans des feuillets datant de 2024. J'ai donc fini par implémenter un raccourci pour retrouver les tickets associés à des tâches en cours, via l'option de carnet --todo, dont voici un exemple de sortie avec une tâche que j'ai noté à faire pendant la rédaction de la présente entrée de journal :

$ carnet --todo | tail -n8
2025-31.txt : dimanche (2025-08-03T18:21) : on air: Thought Chamber - Kerakryps
[ ] Il faudrait que CARNET_OVERTIME supporte les heures partielles,
c'est-à-dire que je permette de passer une heure au format « hh:mm »,
au lieu d'un entier décrivant une simple heure « h ».


________________________________________________________________________
34 feuillets found.

Avec l'option de recherche --search, je peux retrouver les références inverses à un feuillet, ce qui fait un suivi de ticket à peu de frais :

$ carnet --search 2025-08-03T18:21
2025-31.txt : dimanche (2025-08-03T18:56) : on air: Jon Anderson and The Band Geeks - Still A Friend
Je réfléchis à 2025-08-03T18:21 pour rajouter le support des minutes.  À
vue de nez, mon code raisonne déjà en minutes, donc il me suffirait
d'isoler les minutes si un caractère deux-points ':' est présent et de
les rajouter au total.


________________________________________________________________________
1 feuillet found.

Quand j'aurais fini avec la tâche enregistrée dans le feuillet 2025-08-03T18:21, je rajouterais une astérisque entre les crochets pour marquer la tâche comme résolue. L'option --todo admet un argument pour spécifier les tâches qui ne sont ni vierges ni résolues, par exemple je peux avoir des tâches dans un état pending, pour indiquer qu'elles sont en attente d'un évènement, par exemple d'une date ou de la résolution d'une autre tâche.

$ carnet --todo pending | head -n5
2025-28.txt : samedi (2025-07-12T22:46) :
[pending] Je suis en train de travailler sur l'implémentation de la
gestion de tâches du carnet, et cette entrée représente un exemple de
tâche en pause.

Comme il est pénible de taper l'expression rationnelle complète permettant de trouver les tâches résolues, notamment par mon usage de l'astérisque pour les marquer comme telles, il y a également une option --done qui sert de raccourci pour ressortir les tâches dans un état résolu :

$ carnet --done
[…]
________________________________________________________________________
2025-28.txt : samedi (2025-07-12T22:49) :
[*] Ce marqueur représente une tâche terminée.

[…]

1.5.y : édition de feuillet ciblé

Sur un grand nombre de feuillets et de semaines, j'ai commencé à avoir des difficultés à aller éditer les tâches ouvertes depuis pas mal de temps pour aller les résoudre. J'ai donc introduit l'option -ef, ou --edit-feuillet, pour immédiatement démarrer l'éditeur de texte à l'emplacement du feuillet sélectionné. Par exemple, une fois que j'aurais résolu le problème de gestion des minutes dans la fonctionnalité de gestion du temps, je lancerais directement l'éditeur au bon endroit à partir de la référence du feuillet avec :

$ carnet -ef 2025-08-03T18:21

Ce complément est essentiel pour la gestion de tâches, afin de les changer d'état, mais également pour la création de connexions entre feuillets. Les feuillets passés ne sont pas statiques, il peuvent être édités dans le futur s'il semble intéressant de les relier à de nouvelles entrées. Par exemple ce feuillet de 2024 fait référence à des entrées de 2025 :

$ carnet -f 2024-10-27T10:24
/home/emollier/doc/carnet/2024-43.txt:418
10:24 :
J'ai un problème de longue date avec Apache httpd […]

J'ai tenté de renforcer les dépendances au 2025-04-10T20:02, mais sans
succès au 2025-04-11T19:54.

1.6.y : modules utilisateurs

J'ai commencé à parler de mon script de gestion de carnet, ou de journal de bord, ou peu importe, à mes collègues au bureau, et il y a eu comme un semblant d'intérêt pour l'outil. Ce qu'il se passe est que je suis pris de cours avec les cas d'usage qu'on a pu me présenter. Du coup, pour compenser, j'ai implémenté un petit mécanisme d'exécution de module personnalisé à stocker dans le répertoire du carnet, et à exécuter avec l'option -m, ou --module. J'ai un petit module de type hello world dans mon carnet, à fins de démonstration :

$ carnet -m hello world
hello, world!
arguments passed were:
  - world
my carnet environment is:
CARNET_EDITOR=vi
CARNET_DIR=/home/emollier/doc/carnet
CARNET_LANG=fr_FR.UTF-8

$ cat doc/carnet/hello 
#! /bin/sh
set -e
printf -- 'hello, world!n'
test -z "$*" || printf -- 'arguments passed were:n'
for arg in "$@"
do printf -- '  - %sn' "$arg"
done
printf -- 'my carnet environment is:n'
env | grep ^CARNET_

Des collègues ont pu ainsi implémenter un système de recherche personnalisé basé sur autre chose que des expressions rationnelles. Me concernant, je compte également me servir de ce système pour évaluer la faisabilité de futures fonctionnalités ou d'efforts de portage.

Conclusions

Ça fait beaucoup d'un coup, je ne sais pas trop s'il vaut mieux que je fasse des mises à jour fréquentes sur le sujet. Je ne vois pour l'instant pas de fonctionnalités supplémentaires à rajouter. Ce qu'il me manque, c'est une référence de feuillet à facilement copier et coller depuis un fichier ouvert avec un éditeur de texte. Un tel changement nécessiterait de modifier le format du fichier d'entrées pour exposer directement la date au format AAAA-MM-DDThh:mm. Une fois que je serais confiant que c'est la bonne approche et que j'aurais mis en place l'outillage pour manipuler le nouveau format de fichier, alors il sera temps de basculer carnet en version 2.

L'autre détail qui me chiffonne avec carnet est qu'il s'agit d'un script shell de plus de huit cent lignes :

$ wc -l carnet
832 carnet

C'est excessif de près d'un ordre de grandeur pour un script Shell. J'ai rationalisé tant bien que mal un découpage des éléments compliqués en fonctions, en gardant à l'esprit de m'assurer que chaque fonction soit autant que possible constituées de primitives indépendantes, gardant en tête l'Art of Unix Programming, où il est question de préserver la finesse de la couche de glu, à la conjonction entre les fonctions de bas niveau et les fonctions de haut niveau ; je présume que ça contribue à préserver la complexité du code source sous contrôle. Et encore, une grosse portion du code, celle qui couvrait l'affichage des statistiques, a été isolée dans son script en Perl :

$ wc -l carnet_activity.pl 
435 carnet_activity.pl

Je ne sais pas trop comment consolider le tout. Chaque fonctionnalité dépend d'outils très précis et un certain nombre de choses se passe moyennement bien quand il y a de légères différences d'implémentation, ce qui suggère que le portage de carnet vers d'autres distributions que Debian pourrait être un problème. J'ai tenté de limiter la casse en faisant en sorte que carnet fonctionne correctement sur NetBSD 10 ; carnet 1.6.1 n'y montre pas de problèmes évidents, exception faite des difficultés à digérer les espaces insécables dans son terminal système wsvt25.

Rafraichissement du Réveil matin

2025-07-26T11:26:22+02:00

Rafraichissement du Réveil matin

Palaiseau, le samedi 26 juillet 2025

Cher Journal,

J'ai récemment apporté des ajustement à mon ancien article Réveil matin avec MOCP. Les ajustements ont été motivés pendant que j'étais en déplacement à la DebConf25 à Brest la semaine dernière, et que j'ai eu besoin de me réveiller tôt à plusieurs reprises pour diverses raisons, mais que j'ai eu des difficultés à configurer correctement le mécanisme sur la machine que j'avais apporté avec moi. La machine en question tournait en Debian 13 trixie, un pré-version du système qui doit sortir le 9 août prochain, et mes premières tentatives de mise en route du réveil n'ont pas fonctionné comme je m'y attendais. Après avoir un peu cherché et expérimenté, j'ai éventuellement pu déterminer qu'il me manquait la définition de la variable d'environnement XDG_RUNTIME_DIR dans le contexte d'exécution de cron(1). J'ai donc rajouté une note à ce sujet dans l'article et j'en ai profité pour effectuer une relecture.

L'article tirait son origine d'une ancienne machine qu'un utilisait mutuellement avec des copains vers la fin de l'École d'Ingénieurs. À ce titre, il a déjà plus de douze ans. Lors de la relecture, j'ai cru bon de devoir en mettre à jour un certain nombre de portions. L'article est resté quasiment inchangé depuis sa rédaction sur dismorphia.info, abstraction faite du segment manquant qui avait été ajouté en 2018, peu après que je mette en place emlwks999 en tant que successeur de mes pages personnelles. J'ai par là même eu l'occasion de constater l'évolution de mon style d'écriture en une décennie : par exemple mon style passé, relativement haché, est devenu apparemment beaucoup plus homogène. Je sens également l'influence de mon expérience à la rédaction de textes à fins de publications, notamment sur les listes de diffusion : mon style est moins directif tout en étant aussi informatif, du moins c'est l'impression que j'en ai en comparant mon texte sur le réveil matin avant et après relecture. Je pense qu'il reste encore pas mal de coquilles à gauche et à droite, mais je me sens mieux avec l'état dans lequel se trouve l'article si je le compare à son ancienne version.

Je suis un peu surpris de constater le temps que j'ai pu passer à utiliser une telle manière de me réveiller. Au départ, ce ne devait être qu'une geekerie passagère, mais le mécanisme a tendance à se faire oublier assez facilement. En tout et pour tout, je ne touche aux réglages qu'une fois par mise à jour majeure de système d'exploitation, si nécessaire, ou quand je suis en déplacement avec une machine non configurée, par exemple la semaine dernière pour la DebConf25, ou occasionellement en cas de transition entre heure d'été et heure d'hiver. J'ai une légère tendance à vouloir lisser la transition entre les deux horaires en effectuant un décalage d'une demi heure en avance de phase, et un recalage à l'heure initiale une semaine après le changement, quand je ne suis pas tout bonnement en train d'ignorer le changement d'heure en décalant le réveil d'une heure pour ne rien changer à mon cycle de sommeil par rapport au réveil. Bref, tout ça pour dire que cette façon de se réveiller n'a rien de particulièrement contraignante.

Publication de « carnet »

2025-06-30T23:49:14+02:00

Publication de « carnet »

Palaiseau, le lundi 30 juin 2025

Cher Journal,

Je n'ai rien publié depuis le mois d'octobre, 2024, mais voyons tout de même si je sais encore comment rédiger des entrées de weblog publiques. Bien que je sois resté silencieux pendant des mois, je ne suis pas resté non plus inactif. Le gros de mon emploi du temps a été dédié à continuer d'apporter des contributions au projet Debian Med, dans la dynamique dans laquelle je me suis lancé depuis la crise Covid. Il a pu y avoir bien sûr des périodes avec plus ou moins d'activité ; j'ai aussi perdu beaucoup de temps précieux à tester, pardon à jouer à, Minetest, renommé depuis Luanti ; avec des greffons bien choisis, ça m'est assez irrésistible.

Mais j'ai aussi passé un peu de temps à un petit projet sans grande envergure, afin de me faciliter la vie pour enregistrer des notes prises sur des sujets pêle-mêle, sans avoir à réfléchir de ce que je vais en faire, où je fais les ranger, et ainsi de suite.

Ce projet est carnet : un logiciel facilitant la prise de note dans une sorte de journal de bord. Pour prendre une note, je tape juste dans mon invite de commande :

$ carnet

et je me retrouve avec mon éditeur de texte préféré à taper directement au bon endroit, dans le bon fichier, avec un marqueur indiquant la bonne heure.

Ce besoin a fait suite à une tentative de mise en place d'un Zettelkasten qui, quoique étant un outil éminemment puissant pour l'organisation des idées par leur mise en réseau, nécessite suffisamment de méthodologie pour rendre la création et l'intégration de notes assez consommatrice de temps libre ; par ailleurs, certains problèmes que je pouvais me poser par rapport à la prise et l'archivage de notes n'avaient pas leur place dans un Zettelkasten, comme par exemple comment se compare le temps que je passe à contribuer à Debian par rapport au temps que je passe sur les jeux vidéos. Une motivation supplémentaire a été que, à titre professionnel, je dois enregistrer mes activités dans un outil de pointage qui a une ergonomie discutable, mais surtout dans lequel j'ai graduellement injecté de plus en plus d'informations, sans être en réelle mesure de pouvoir un jour les en déterrer. À partir de ce qui devait initialement être un petit script enrobant quelque commandes pour lancer un éditeur de texte et permettant de retrouver des notes, j'ai fini par me retrouver avec un petit projet logiciel à part entière.

Le script s'est graduellement étoffé pour intégrer un petit moteur de statistiques montrant divers histogrammes d'activité, accessibles en lançant :

$ carnet -a

Cette fonctionnalité toute secondaire s'est retrouvée à créer une boucle de rétroaction dans laquelle j'ai eu davantage envie de rajouter des notes et d'écrire des choses. La fonction s'est tellement complexifiée qu'il est arrivé un point où je l'ai complètement réécrite en Perl. Pourquoi le Perl a-t-on pu me demander ? J'ai pu trouver plein de raisons plus ou moins bonne, mais je crois que la réponse la plus honnête que je puisse fournir est que j'avais envie de m'amuser, et j'ai trouvé l'écriture en Perl plus amusante que d'autre langages de script similaires. Avec le temps, j'ai même pu commencer à identifier des motifs d'activité, en fonction des vacances, des activités auxiliaires impliquant ou non de passer du temps sur l'outil informatique, et cætera.

Curieusement, la fonctionnalité de recherche d'entrées n'est arrivée que plus tard, quand la taille de mon carnet a commencé à être suffisamment excessive pour rentre les recherches manuelles assez pénibles. Intégrer une fonction au carnet pour les recherches m'a permis de faciliter la récupérations d'entrées correspondant à des motifs d'expressions rationnelles arbitraires :

$ carnet -s '<dar>'
2025-26.txt : mercredi (2025-06-25) : 09:27 :
Je suis en train de me rafraichir les idées dans la documentation de
l'outil d'archivage sur disque dar(1)[1].  Je m'en sers comme une
commande tar un peu plus évoluée pour avoir un accès plus rapide à mes
index de fichiers, mais je pourrais faire plus, comme par exemple baser
ma stratégie de sauvegardes dessus (ce que je ne fais pas pour
l'instant, parce que mes sauvegardes peuvent tout à fait tenir sur un
seul medium de stockage).

[1] : http://dar.linux.free.fr/doc/presentation.html

Je rajouterais très probablement d'autre fonctionnalités au fur et à mesure que le besoin s'en fera sentir ; par exemple, j'ai en tête une option pour alerter sur le risque de saisir des heures supplémentaires, dans un contexte professionel, signalant donc la fin de la journée. Le projet est loin d'être fini, même si le numéro de version, aujourd'hui 1.1.2, suggère un programme sorti de publication bêta.

Initialement, j'avais appelé le projet « journal », mais j'ai eu quelque craintes d'entrer en collision avec des outils réels contemporains ou futurs. Parce que « journal » est beaucoup plus commun que « carnet », j'ai fini par adopter ce dernier nom ; l'adaptation n'a pas été immédiate, car ça faisait déjà quelque semaines que je me servais de mon script. Je ne m'étendrais pas plus dessus. J'ai déjà commenté, avec largesse, à propos de son fonctionnement sur sa page d'accueil, quoiqu'en langue Anglaise.

Fermeture du serveur IRC

2024-10-22T22:38:15+02:00

Fermeture du serveur IRC

Palaiseau, le mardi 22 octobre 2024

Cher Journal,

Cette entrée de journal est pour annoncer que je coupe le service IRC sur emlwks999.eu, car il n'est plus utilisé que par des robots scanneurs à la recherche de vulnérabilités à exploiter. Le pair avec lequel on avait monté une fédération est également éteint depuis un certain temps. C'est donc effectivement la fin de notre mini réseau.

Depuis le lundi 15 juillet 2019, ce serveur IRC est déployé sur emlwks999.eu, alors emlwks999.hd.free.fr. Il avait eté déployé afin d'implémenter une mini fédération IRC pour discuter avec les copains, et j'avais ainsi appris quelque rudiments du fonctionnement en détail d'un réseau IRC, son administration, et la notion d'opérateur, qui en IRC est différente et plus puissante que la notion d'administrateur, sous entendu « de canal ». Bref, j'ai trouvé cela d'un intérêt qui m'avait agréablement surpris. La fédération elle même avait été implémentée le vendredi 19 juillet 2019, c'est à dire à la fin de la même semaine.

Le temps a passé, et un certain nombre de choses ont changé. Comme je l'écrivais dans mon article sur IRC il y a une décennie, déjà, IRC est un protocole qui date de 1988, je n'étais même pas né, et internet avait une population très différente à ce moment là, moins hostile en termes de menaces informatiques mais encore très exclusive à cause des moyens nécessaires pour mettre en œuvre un accès à internet. D'une part, la criminalité informatique a explosé dans les années 90 et 2000, pour atteindre une échelle industrielle décrite par Edward Snowden en 2013. Cet évènement a provoqué un essor du développement de plateforme de discussions et d'échange de messages chiffrés, dont je pense aujourd'hui que l'exemple le plus emblématique est l'écosystème d'outil de discussions basés sur matrix.org. Ces outils sont devenus matures à la fin des années 2010, avec les dernières fonctionalités ajoutées à marche forcée en 2020 au plus fort de la crise Covid. Le protocole IRC, bien qu'il ait pu évoluer avec assez de modifications pour au moins chiffrer les données en transit, n'a jamais été adapté pour du chiffrement de messages de bout en bout, mettant les serveurs IRC dans une position de concentration des échanges d'information.

Malgré tout, le protocole IRC est toujours utilisé aujourd'hui, et on a vu il y a seulement trois ans la création du réseau IRC Libera Chat sur les cendres de FreeNode suite à un échec critique de gouvernance. Je suis moi-même présent sur le réseau OFTC (lui même fondé en 2001) afin de discuter sur quelques uns des canaux Debian qui y sont hébergés. Je n'y suis que rarement de près ce qu'il s'y passe, quoique je peux être un peu plus actif en cas de conférence ; dans ces circonstances, IRC reste un outil puissant et léger pour se coordonner. Mais IRC reste inadapté pour échanger des messages confidentiels.

Une autre chose a changé et que j'ai du mal à m'expliquer, mais j'en touchais deux mots à un collègue pas plus tard que cet après midi : j'ai du mal à suivre une conversation au format clavardage. Le courriel me pose beaucoup moins de problèmes curieusement : les messages arrivent à un seul endroit que j'ai à surveiller, ils ne se mélangent que de la manière dont je demande à mon client mail des les trier, et je peux ranger chaque message comme je souhaite une fois que j'en ai pris connaissance et ai éventuellement répondu. Le clavardage fournit une granularité au niveau d'une discussion, ce qui résulte tout de suite en de multiples canaux distinct. Peut-être que je n'ai simplement pas trouvé de client de clavardage adapté à ma façon de traiter les messages ?

Site web rétabli en IPv6

2024-05-13T21:17:39+02:00

Site web rétabli en IPv6

Palaiseau, le lundi 13 mai 2024

Cher Journal,

En procédant à ma vérification mensuelle des certificats TLS pour les domaines emlwks999.hd.free.fr et emlwks999.eu, j'ai dû procéder à un renouvellement manuel du domaine fourni par Free. Seulement, mes tentatives ont fini en échec répétés pour cause de connexions refusées par mon serveur web, d'après le message d'erreur renvoyé par le certbot. En grattant dans le fichier de journal indiqué dans le message d'erreur, j'ai noté que le cerbot côté Let's Encrypt rebondit sur de multiple domaines pour résoudre emlwks999.hd.free.fr, avant de finalement tenter une connexion via l'adresse IP en version 6. Pour une raison qui m'échappe, mon serveur Apache a cessé d'écouter les requêtes sur les ports IPv6 : toutes mes tentatives de connexion avec n'importe quel client web (Firefox, GET, etc) se sont soldées par des connexions refusées.

Visiblement, j'ai dû avoir cassé quelque chose à un moment dans la configuration des écoutes sélectives par ports. J'ai essayé de voir si je n'ai pas manqué quelque chose dans mon fichier /etc/apache2/ports.conf, mais il n'y a rien de particulier à y signaler :

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf

Listen 80

<IfModule ssl_module>
	Listen 443
</IfModule>

<IfModule mod_gnutls.c>
	Listen 443
</IfModule>

Après quelque tentatives de raccorder le service explicitement sur les interfaces IPv6, et essuyer des erreurs de port déjà en cours d'utilisation, j'ai fini par rétablir le fichier de configuraton dans son état que je pensais initial, et redémarré le service :

$ sudo systemctl restart apache2

Les interfaces IPv6 étaient alors de nouveau disponibles. J'ignore pourquoi ou comment le service des addresses IP modernes a cessé, pendant que le schéma historique a continué à fonctionner. Ma conjecture est que ma machine pourrait avoir démarré le serveur web avant que l'interface ne soit disponible en IPv6. J'ai ajouté une configuration SLAAC explicite dans mon fichier d'interface pour m'assurer de bien avoir une configuration IPv6 pour considérer l'interface comme disponible, au format interfaces(5), en vue d'hypothétiquement faciliter les prochains redémarrages :

iface enp1s0 inet6 auto

Après arrêt et redémarrage de l'interface, la déclaration statique en IPv4 est revenue tout de suite, mais la déclaration automatique en SLAAC a pris de l'ordre d'une dizaine de secondes pour revenir, après que l'activation des interfaces réseau ait rendu la main. J'ignore depuis combien de temps le problème est présent, mais si c'est deux jours, alors ça coïnciderait avec le dernier redémarrage de la machine, ce qui validerait la conjecture.

Il y a probablement plusieurs morales à cette histoire. La première est de surveiller activement l'expiration de ses certificats TLS Let's Encrypt, au cas où quelque chose ne se passe pas comme prévu. La deuxième est que bien que techniquement supérieure, l'implémentation d'IPv6 reste manifestement très marginale, et donc il peut s'écouler du temps avant de se rendre compte d'un problème n'affectant que le circuit IPv6. La troisième est qu'il reste probablement quelque points à améliorer pour que le suivi des cibles réseau ne soit pas surprenant, notamment au vu des interfaces qui démarrent à différentes vitesses, et qui peuvent potentiellement affecter le démarrage des services qui dépendent du réseau si ce dernier n'est activé que partiellement.

Disque en panne et intégrité des sauvegardes

2023-07-22T15:43:37+02:00

Disque en panne et intégrité des sauvegardes

Palaiseau, le samedi 22 juillet 2023

Cher Journal,

C'est après presque quatorze ans de bons et loyaux services que mon premier disque dur externe a rendu son dernier octet. Il s'agissait d'un Verbatim M7519 de 640 Go acheté fin 2009, disque rotatif de 3”½ avec une carte d'alimentation dédiée de 24 W, contrastant avec l'usage contemporain qui veut que les volumes de stockage externes soient maintenant directement alimentés par leur port USB. Le bouton d'allumage et arrêt avait quelque ratés sur la fin : j'ai dernièrement eu du mal à éteindre le disque après avoir effectué dessus des sauvegardes mensuelles. C'est en voulant effectuer un test de restauration des dites sauvegardes que je me suis rendu compte de la panne.

Je présume que le bouton d'allumage a finalement lâché. Si j'ai du temps pour bricoler, peut-être que je pourrais découpler le disque de son boitier pour m'en resservir dans une machine, par exemple. Je n'utilisais plus ce disque que pour des sauvegardes mensuelles en cas de gros pépins avec mes volumes de stockage plus récents. Comme le disque était déjà ancien, mon idée était de ne plus avoir à compter dessus que en cas de situation invraisemblable qui impliquerait la destruction de mes autres archives régulières et irrégulières. J'avais pu donc m'en servir pour quelque expériences risquées, comme tester le support du bit bigtime, introduit dans le système de fichier XFS afin de permettre le support des partitions existantes au delà de l'an 2038.

L'incident souligne l'importance de vérifier régulièrement l'état de ses sauvegardes et archives.

Sortie de Debian 12 bookworm

2023-06-11T14:32:27+02:00

Sortie de Debian 12 bookworm

Palaiseau, le dimanche 11 juin 2023

Cher Journal,

Debian 12 bookworm est sortie hier soir.

L'annonce officielle a été envoyée par courriel le samedi 10 juin à 19:56:04… heure de New York, donc suffisamment tard hier soir pour ce que ce soit ce matin à Palaiseau. L'annonce de la publication est disponible sur le site web du projet Debian. Je ne détaille pas les changements car c'est déjà fait dans les notes de publications, et je ne veux pas gâcher les surprises. Pour les éléments qui m'intéressent, le noyau natif est Linux 6.1, et le compilateur système est Gcc 12. Merci à l'équipe de publication, qui a eu un samedi assez chargé !

Détail amusant : la date correspond jour pour jour à la validation de ma candidature en tant que Développeur Debian, le 10 juin 2021, comme un fait exprès. À noter que j'ai été officiellement DD à partir du 23 juin 2021, comme rapporté par le site des nouveaux mainteneurs.

Ça fait un bon bout de temps que je n'ai plus envoyé de paquets dans l'archive, mais de ce que je vois de mes manipulations de ce matin, j'ai encore une vague idée de comment m'y prendre. :)

Garder les journaux systèmes sous contrôle dans Debian 11

2022-07-23T19:34:59+02:00

Garder les journaux systèmes sous contrôle dans Debian 11

Palaiseau, le 23 juillet 2022

Cher Journal

Je note ici dès fois que ça serve à quelqu'un : depuis Debian 11, les journaux systèmes sont configurés pour grossir indéfiniment. Bien que l'intention de départ ne soit honorable, à savoir conserver des informations de dépannage et autres sortes d'enquêtes aussi longtemps que possible, l'espace disque n'est pas extensible à l'infini (n'en déplaise aux professionnels de l'infonuagique).

Une investigation avec du, ou bien ncdu qui est davantage adapté à la recherche de fichiers goinfres dans une arborescence, devrait montrer que beaucoup d'espace est consommé par /var/log/journal, en comparaison avec le reste des journaux systèmes :

$ sudo du -sh /var/log/* | sort -hr | head -n3
1.1G	/var/log/journal
17M	/var/log/apt-cacher-ng
16M	/var/log/installer

Je fais du ménage relativement régulièrement, donc la consommation ne file pas, mais 1,1 Gio de consommé, c'est déjà particulièrement excessif pour du journal système. En comparaison, les fichiers de journaux historiques n'excèdent que rarement les quelque dizaines de mébioctets de taille ; bien entendu ces valeurs dépendent aussi beaucoup de l'usage de la machine :

$ sudo du -sh syslog* kern.log* auth.log*
2.8M	syslog
3.5M	syslog.1
620K	syslog.2.gz
664K	syslog.3.gz
592K	syslog.4.gz
36K	syslog.6.gz
24K	syslog.7.gz
168K	kern.log
48K	kern.log.1
8.0K	kern.log.2.gz
28K	kern.log.3.gz
24K	kern.log.4.gz
1.9M	auth.log
2.8M	auth.log.1
232K	auth.log.2.gz
188K	auth.log.3.gz
188K	auth.log.4.gz

Le répertoire /var/log/journal contient l'intégralité des journaux systèmes dans un format de base de donnée binaire. Ce format n'est pas sans intérêt puisqu'il permet de retrouver facilement des informations diverses en fonction de nombreux paramètres, l'exemple typique étant de lister les évènements qui se sont produit sur une plage de temps quelque part dans le passé. On se référera avantageusement au manuel de journalctl(1) à ce sujet.

Historiquement, les journaux sont gardés sous contrôle au moyen d'outils comme logrotate(8). Les archives des journaux sous /var/log/journal sont gérées différemment, de part leur nature de base de données, qui se prête moins bien à rsyslog, mais mieux à d'autre formes de manipulations. La commande journalctl comprend un ensemble de commandes pour effacer les archives les plus anciennes, en fonction de la stratégie que tout un chacun voudrait appliquer. Il y a des stratégies pour conserver au moins un certain intervalle de temps, ou bien une certaine quantité de journaux, tout dépend des besoins de conservation des journaux. Typiquement, sur une machine sur laquelle je ne m'inquiète pas plus que ça des enregistrements de journaux, un bon ménage peut être fait avec :

$ sudo journalctl --vacuum-size=10M
[…]

$ sudo du -sh /var/log/* | sort -hr | head -n3
33M	/var/log/journal
17M	/var/log/apt-cacher-ng
16M	/var/log/installer

Comme on peut le voir, la taille est légèrement supérieure après ménage. C'est parce que le répertoire contient différent types de bases de données. Il y a les journaux en cours d'écriture, et les journaux archivés. La partie des journaux archivés est la seule éligible à être nettoyée à coups d'aspirateur à données (vacuum), le reste étant en cours d'utilisation. Ça vaudrait probablement le coup de faire un ménage régulier pour éviter les incidents du type « disque plein ». Je me demande s'il y a une option de configuration pour désactiver la conservation ad vitam des journaux ? Autrement, passer un coup de d'aspirateur une fois tous les mois peut tout à fait se faire dans /etc/cron.monthly/.

Ça fait un bon bout de temps que je n'ai plus écrit grand chose dans ce journal. Quelque part, comme l'écrivait Soljénitsyne, c'est bon signe, ça veut dire que le reste avance. Ceci étant, la faute reposait probablement en bonne partie sur un clavier trop usé ; j'ai fini par en changer après avoir étudié de près les mécanismes disponibles sur le marché, de bonne réputation, et confortables à utiliser. Ce sera peut-être un sujet pour plus tard.

Retombées de l'éruption M4 du 28 mars

2022-03-31T23:03:18+02:00

Retombées de l'éruption M4 du 28 mars

Palaiseau, le jeudi 31 mars 2022

Cher Journal,

L'éruption M4 de lundi dernier s'est manifestée ce matin en provoquant une tempête géomagnétique mineure, avec un indice K_p de 5. Il y a éventuellement eu quelque faibles fluctuation dans le réseau électrique, et quelques oiseaux migrateurs ont pu être déviés de leur trajectoire. La NOAA fournit un graphe combiné de l'évolution de l'intensité des éruptions, du flux de protons et de l'activité géomagnétique, ainsi qu'une échelle qui permet d'interpréter l'amplitude des trois phénomènes en fonction de leur impact sur les activités humaines. Ça m'a grandement facilité la lecture des graphiques, et en plus maintenant je comprend mieux les annonces du SIDC qui, pour des raisons évidentes, expose essentiellement des grandeurs physiques : K_p, flux de protons, classification des éruptions, intensité du champ magnétique…

Par ailleurs, flaremail a rapporté une nouvelle éruption pendant que je rédigeais cette entrée, il devrait donc y avoir encore quelques choses à dire dans les jours à venir :

A class M9.6 solar X-ray flare occurred on 2022/03/31 with peak time 18:35UT

Si je commence à rédiger une entrée par jour en me substituant au SIDC, je risque de ne plus mettre grand chose d'autre dans le journal dans les mois qui viennent. Comme dirait Arka'an, dont c'est le métier :

avec un max du pic prévu pour 2025, y a des chances …

Éruption de classe X1.3

2022-03-30T22:01:14+02:00

Éruption de classe X1.3

Palaiseau, le mercredi 30 mars 2022

Cher Journal,

Décidément, il y a de l'activité solaire dernièrement. Un EMC classée X1.3 s'est produite vers 19:37. La magnitude est supérieure à l'éruption de classe M4 enregistrée lundi. Je serais curieux de voir l'image résultante, mais la vidéo SWAP couvrant cet horaire n'est pas encore disponible à l'heure où j'écris ces lignes.

Le pic causé par l'éruption M4 d'avant hier est encore visible, mais l'éruption X1.3 a collé bonne baffe dans la courbe d'émission de rayons X du jour. L'outil d'alerte flaremail rapporte :

A class X1.3 solar X-ray flare occurred on 2022/03/30 with peak time 17:37UT

À suivre… Comme c'est excitant !

Première suite à l'EMC du 28 mars 2022

2022-03-29T22:46:54+02:00

Première suite à l'EMC du 28 mars 2022

Palaiseau, le mardi 29 mars 2022

Cher Journal,

Cette entrée se voulait initialement un simple relai des nouvelles du SIDC. Pour faire court, la vitesse des matériaux de l'éruption d'hier est estimée par les astronomes à la baisse, à environs 735 km/s, et devraient arriver le 31 mars aux aurores. Une éjection de masse coronale supplémentaire a été enregistrée un peu plus tard hier et semble se propager à une vitesse d'environs 784 km/s, ce qui la ferait arriver le 31 mars en soirée. Dans les deux cas, les éruptions solaires proviennent de la tâche NOAA 2975.

Pour ce qui est de l'état d'alerte des systèmes les plus exposés aux vents solaires, je ne sais pas pour sûr, mais j'ai cru comprendre que les appareils en production en ont vu d'autres au cours des dernières décennies. Par ailleurs, l'éruption n'a pas explosé les échelles des indices servant à quantifier la force des éruptions solaires, donc je présume qu'on est encore assez loin d'un éventuel nouvel évènement de Carrington. Ceci étant, il est vrai qu'au début du mois dernier, une tempête géomagnétique a provoqué la perte d'une quarantaine de satellites Starlink qui étaient en cours de mise en orbite.

Pour ce qui est des atténuations radio mentionnées hier, elles ne sont nullement causées par du rayonnement X mais bien évidemment par des ondes radio ; les fréquences entre ces deux classes d'ondes électromagnétiques ne sont pas tout à fait les mêmes. Mon clavier a dû fourcher…

Les prochaines nouvelles à ce sujet devraient être pour le 31 mars. Qui sait, peut-être que des amateurs enregistreront des images d'aurores polaires ? Il est aussi très possible que j'oublie tout bonnement le sujet d'ici là.

Sur un autre sujet, toujours en lien avec le soleil, Guru Meditation rapporte que l'analyse des 24 dernières années de données relatives au soleil suggère la présent de vortex rétrogrades dont la vitesse n'est pas facilement expliquée par la physique solaire telle qu'on la conçoit pour le moment.

EMC du 28 mars 2022

2022-03-28T23:28:26+02:00

EMC du 28 mars 2022

Palaiseau, le lundi 28 mars 2022

Cher Journal,

Ça fait quelque mois que je n'ai plus rien écrit de sérieux ici, la faute à l'hibernation cet hivers, sans doute. Voyons si je sais encore taper du texte en html sans me mélanger les pinceaux.

Depuis l'EMC de novembre dernier, documentée entre autres locations chez Stéphane Bortzmeyer, je jette régulièrement un petit coup d'œil au site du SIDC pour voir comment évolue le soleil au jour le jour, par curiosité. Je n'ai pas fait les études d'astrophysique adéquates pour bien comprendre, et encore moins correctement interpréter, toutes les grandeurs qui sont publiées au jour le jour sur leur site, mais j'essaie de me documenter.

Peu après le déjeuner, j'ai jeté un œil sur les derniers enregistrements vidéo du SWAP, qui montrait très clairement une éjection de masse coronale en direction de la terre aujourd'hui à 11:29 temps universel. La vidéo devrait être mise à disposition dans les archives du de mars 2022 à la fin du mois. À l'instant t l'outil d'alertes presto affiche :

The proton flux of >10MeV exceeded the 10pfu threshold on 13:25UT. This is
a result of the M4.0 class flare for region NOAA 2975, peak time March 28th
11:29UT, in combination with the radio bursts of type II (11:23UT) and type
IV (11:37UT) that followed. The event is ongoing.

Un message antérieur indiquait que la vitesse d'éjection des matériaux solaires était d'un peu plus de 1200 km/s, mais je n'arrive pas à le retrouver ; cela représente 300 km/s de plus que l'éruption du mois de novembre dernier. S'il n'y a pas de ralentissement du vent solaire, comme l'éruption a eu lieu dans l'axe en direction de la terre, j'imagine que l'accroissement du vent solaire devrait nous atteindre demain dans la soirée. Évidemment, si le flux ralentit d'ici là, j'ai toutes les chances de me tromper.

Ailleurs sur le web, en cherchant des éléments via Wikipedia au sujet de la météo spatiale, j'ai fini par tomber sur un site vraisemblablement basé en Espagne, qui rassemble l'ensemble des graphiques liés à la météo solaire sur un seul panneau de contrôle, et de ce que j'en comprends, les éruptions sont classées par quantité d'émission de rayons X, et peuvent être de type A, B, C, M ou X. L'éruption d'aujourd'hui a été catégorisée M4. Sur un autre site, spaceweather.com, j'ai pu lire que le rayonnement X a causé des interférences très nettes aux opérateurs radios, un peu partout en Afrique, dans la partie du sud de l'atlantique, et probablement en Espagne aussi.

Je pense essayer de suivre ça de prêt demain, du moins si mon emploi du temps me le permet. En tout cas, de ce que je vois sur un forum dédié à l'observation et aux prévisions de la météo spatiales, les passionnés sont excités comme des puces. Je ne sais pas dans quel état d'alerte sont les opérateurs des différents réseaux, électrique et Internet, par contre.

Hibernation

2022-02-24T12:04:06+01:00

Hibernation

Zzzz…quoi ?