PragmaGeek

Ignorez les conseils des automobilistes, faites du vélo

2026-04-20T00:00:00+02:00

Quand j’ai préparé mon déménagement en Guadeloupe l’été dernier, les gens m’ont dit “Ici, les routes sont trop dangereuses, il n’y a pas d’infrastructures adaptées, les gens roulent n’importe comment, personne ne fait de vélo, il n’y a pas de chemins VTT, les coins intéressants dans le Parc National sont interdits aux VTT, ne prend pas ton vélo, tu devras tout faire en voiture”.

J’étais très déçu. Je suis cycliste dans l’âme. Je n’en fais pas autant que je devrais, en particulier pour le loisir, mais j’avais pris l’habitude de me déplacer à vélo pour les petits trajets dans mon village et dans les villages voisins, par principe. Ça m’aérait, me faisait du bien, de l’exercice.

J’ai donc hésité à prendre mes vélos dans le déménagement. C’est que c’est volumineux un vélo, et chaque mètre cube coûte cher quand on voyage à l’autre bout du monde. J’ai laissé mon vélo électrique long-tail en métropole (ma belle-sœur l’utilise désormais dans Lyon), mais j’ai par principe quand même pris mon VTC avec porte-bagage, et mon vieux mais fiable VTT, au cas où (je suis cycliste dans l’âme, je vous dis).

Au début, effectivement, grosse déception. Routes étroites et en mauvais état, quasiment aucune piste ou bande cyclable. Des centre-bourg dans lesquels il n’y a que peu de commerces, ces derniers se concentrant dans des zones commerciales géantes, accessible exclusivement en voiture. Il y a quand même quelques stations de vélo en libre service dont personne ne se sert (on se demande bien pourquoi), probables vestiges d’une époque où des crédits européens étaient dédiés à leur développement.

En Guadeloupe, tout le monde prend sa bagnole pour aller au travail, à la boulangerie, faire ses courses, à la plage, pour ses loisirs, pour tout. C’est comme en métropole, mais en pire. Ici, on prend sa voiture pour faire 1 km pour rejoindre la voie verte sur laquelle on peut ensuite courir en sécurité. On fait 30km de route pour aller chercher un coin de nature où faire du VTT.

Résultat : des bouchons, monstrueux, tous les jours aux heures de pointe. Un réseau routier qui n’est pas dimensionné. 45 minutes pour faire 2km sur la voie rapide. Des axes routiers sans passerelle piéton qui séparent les lieux de vie et les lieux de commerce. Les plus démunis, se déplaçant à pied, doivent traverser des 2×3 voies à 90km/h pour faire leurs courses (c’est pas pour rien que la Guadeloupe a une mortalité routière trois fois supérieur à celle de l’Hexagone).

Le développement urbain a visiblement été anarchique. Les maisons individuelles s’étalent sur des kilomètres le long des routes, là où se trouvaient auparavant des pâtures ou des plantations. Les centre-villes sont généralement les quartiers les plus pauvres, où s’agglutinent des petites maisonnettes de plain-pied, pour certaines en très mauvais état. Le centre-ville de Pointe-à-Pitre, principalement constitué d’immeubles de plusieurs étages, comprend de nombreux bâtiments indignes, presque à l’état de ruine. Les commerces ne sont pas accessibles à pied, donc les gens prennent la bagnole, et quand on vit à Bagnole-Land, la plus grosse difficulté, c’est de se rendre compte qu’un monde sans voiture est possible. Il faut faire ce que personne n’ose : se lancer, défricher le terrain, et montrer que c’est possible.

Il m’a donc fallu 6 mois pour me motiver à utiliser mon vélo, dans un premier temps pour aller à l’école de musique à 10 minutes de trajet. C’est un peu vallonné, mais pas insurmontable. Faut savoir par où passer, mais c’est globalement sûr, à 80% dans des lotissements calmes, hors des gros axes routiers, 10% sur les trottoirs, et 10% dans la circulation urbaine (pas le choix, pas de trottoir).

Fun fact : il faut faire un tel détour en voiture pour rejoindre cette école de musique, que ça prend 9 minutes C’est donc presque aussi rapide d’y aller à vélo (le retour se fait par contre sans détour, donc l’avantage est clairement à la voiture, mais ce n’est pas la question).

Puis ce weekend, n’ayant pas de contrainte horaire, j’ai poussé jusqu’à aller à ma répétition hebdomadaire du Jazz Band à Pointe-à-Pitre à vélo. À peine plus de 10 km, contre 8.5km en voiture. 35 minutes de trajet, dont la moitié sur une belle piste cyclable. Quelques épisodes de pluie fine m’ont rafraîchi. J’avais prévu le vêtement de pluie dans le sac, mais je ne l’ai pas sorti. Je suis arrivé un peu humide, mais pas trempé. Par 30°C, ça n’est pas problématique.

De toute manière, avec la température et l’exercice, j’aurais été humide de transpiration. Le principal, c’est d’être propre pour éviter de sentir le chien mouillé. J’ai évité de justesse une averse plus forte, qui est passée durant la répétition. Une pluie tropicale ultra-intense, assez habituelle ici, du genre gros orage d’été qui ravine tout en 10 minutes, avant que le soleil ne revienne aussi vite qu’il est parti.

Mes camarades musiciens ont tous été positivement intrigués par mon trajet en vélo. Certains m’ont demandé si j’étais passé par la 2×2 voies à 90km/h… Je leur ai rappelé qu’il y avait quand même des pistes cyclables, des passerelles piéton, etc. Ça a fait parler. Ça a montré que c’était possible.

Le retour, vers 18 heures, s’est bien passé, au sec, juste avant la nuit, avec mes petites lumières rouges et blanches de chez Décathlon, satisfait de mon activité. Je me suis prouvé à moi-même qu’il était possible de se déplacer sans voiture sur ce trajet “semi-long”.

J’ai repensé à ceux qui me disaient que je ne ferai pas de vélo en Guadeloupe. Bien évidemment, c’était des gens qui n’étaient pas eux-mêmes cyclistes, et qui exagéraient le problème. Ils n’imaginaient pas qu’on pouvait traverser les lotissements calmes pour aller faire ses courses, qu’il y avait quand même quelques pistes cyclables, qu’on pouvait sans trop de difficulté éviter les routes les plus dangereuses en passant par le réseau secondaire/tertiaire.

Morale de l’histoire : N’écoutez pas les bagnolards, ils vous diront forcément qu’on ne peut pas faire de vélo. Osez, défrichez le terrain, montrez l’exemple, pour votre bien-être, et pour avoir une chance de susciter des vocations.

Ah, et j’aurais dû emporter mon long-tail électrique. Il m’aurait été utile…

Sélectionner la disposition clavier sur GDM

2024-11-24T00:00:00+01:00

Depuis quelques années, l’écran de connexion Gnome Display Manager, autrement appelé GDM, ne bascule plus automatiquement la configuration du clavier vers celle configurée par défaut par l’utilisateur pour lequel il demande le mot de passe. C’est problématique pour les gens qui utilisent au quotidien une disposition de clavier particulière (Colemak, Dvorak, ou Bépo dans mon cas), mais qui doivent laisser par défaut la configuration du système en Azerty pour permettre son utilisation par d’autres personnes.

Cela oblige donc l’utilisateur d’une disposition alternative à s’authentifier avec un clavier azerty, avant de retrouver le confort de sa disposition fétiche une fois la session ouverte.

Après plusieurs années de souffrance (oui, oui, sortez les mouchoirs), je viens de trouver comment avoir accès à plusieurs dispositions du clavier dès l’écran de connexion.

Il se trouve que GDM ne donne accès qu’aux dispositions configurées pour le système, qui est donc Azerty (ou Qwerty) par défaut, mais le système peut en avoir plusieurs. GDM les prend toutes en compte, et permet de basculer facilement de l’une à l’autre. Voyons comment faire.

La manipulation est valable sur Debian (Trixie/Testing dans mon cas), donc elle devrait être similaire sur tous les dérivés de Debian, et adaptable pour les autres distributions.

La disposition par défaut du système est enregistrée dans le fichier /etc/default/keyboard (ou dans /etc/vconsole.conf, qui est un lien symbolique vers celui-ci).

Par défaut, sur un système avec clavier Azerty, ce fichier contient ceci :

# KEYBOARD CONFIGURATION FILE

# Consult the keyboard(5) manual page.

XKBMODEL="pc105"
XKBLAYOUT="fr"
XKBVARIANT="latin9"
XKBOPTIONS=""

BACKSPACE="guess"

Si on configure le système pour avoir le clavier Bépo, ça donne ceci de différent (testez avec sudo dpkg-reconfigure keyboard-configuration) :

XKBLAYOUT="fr"
XKBVARIANT="bepo"

Par défaut, l’utilitaire dpkg-reconfigure ne semble permettre de paramétrer qu’une seule disposition, mais pour en avoir deux, il suffit de les noter ensemble, séparés d’une virgule :

XKBLAYOUT="fr,fr"
XKBVARIANT="latin9,bepo"

GDM propose désormais le choix entre les deux dispositions, via un menu en haut de l’écran.

Le raccourci clavier Meta + Espace permet même de basculer rapidement de l’un à l’autre. Un véritable bonheur.

Les autres utilisateurs de l’ordinateur continueront d’utiliser la disposition Azerty correspondant à ce qui est inscrit physiquement sur le clavier physique, et je pourrai rapidement basculer en Bépo pour entrer mon mot de passe aisément. J’aurais préféré que ce soit automatique pour moi, comme c’était le cas il y a quelques années, mais je m’en contenterai.

La bonne manière de faire un script Nautilus en Bash

2022-01-05T00:00:00+01:00

On trouve toutes sortes de scripts Nautilus sur internet, car ils peuvent rendre des services aussi variés que précieux, mais beaucoup de ceux que l’on croise présentent des défauts de conception majeurs : ils n’itèrent pas, ou mal, sur la liste des fichiers qui leurs sont fournis, et ils ne peuvent pas gérer des fichiers situés sur un système virtuel distant monté par GFVS, typiquement un partage Samba, Webdav ou (S)FTP. Ce billet va tenter de définir une manière fiable et universelle de gérer les fichiers sélectionnés et fournis aux scripts Nautilus.

Les scripts Nautilus, kézako ?

Nautilus est le nom historique du navigateur de fichiers du projet Gnome. Il s’appelle désormais Gnome Files. On en retrouve des dérivés nommées Caja ou Nemo, qui possèdent eux aussi un support pour ces scripts. Si vous ne savez pas ce que sont ces “scripts Nautilus”, il s’agit de scripts que l’on peut appliquer sur un ou plusieurs fichiers et dossiers afin d’effectuer des actions prédéfinies.

Les scripts Nautilus sont des programmes exécutables placés dans le répertoire $HOME/.local/share/nautilus/scripts et ses sous-dossiers. Nautilus détectera tous les fichiers exécutables dans cette arborescence et proposera de les invoquer via le menu contextuel, dans le sous-menu “Scripts”. Pour désactiver un script, il n’est donc pas nécessaire de le supprimer du dossier, il suffit de le rendre non exécutable.

Ces scripts peuvent être développés dans n’importe quel langage de programmation. Il en existe en Python et en Perl, mais s’agissant de petits scripts dont le but est de manipuler des fichiers ou d’interagir avec un système Linux, le langage Bash est utilisé la plupart du temps.

Lorsqu’on donne des fichiers et dossiers classiques aux scripts Nautilus, tout fonctionne comme prévu. Mais par “classique”, entendez “sur un système de fichier local” et “avec un nom de fichier sans caractère problématique”.

Nous allons voir que des problèmes se posent dans deux situations :

Quand, depuis Nautilus, on accède à des systèmes de fichier distants montés par GIO/GVFS (partages Samba, Webdav, SFTP, etc.) ;
Quand les fichiers ont un retour à la ligne dans leur nom.

Afin de prévoir d’éventuelles spécificités liées aux versions des logiciels utilisés, je précise que je travaille sur un système GNU/Linux Ubuntu 20.04 LTS avec Nautilus version 3.36.3.

Les variables spécifiques

Nautilus va fournir au script invoqué plusieurs informations relatives aux éléments sélectionnés. Le script pourra ensuite en faire usage si besoin.

Au delà des variables habituelles ($@, $*, $1, $2, etc.), nous avons à disposition les variables spécifiques suivantes :

NAUTILUS_SCRIPT_SELECTED_FILE_PATHS
NAUTILUS_SCRIPT_SELECTED_URIS
NAUTILUS_SCRIPT_CURRENT_URI
NAUTILUS_SCRIPT_WINDOW_GEOMETRY

D’autre part la variable $PWD, moins connue mais toujours disponible en Bash, va nous être utile car elle indique le répertoire de travail courant (celui visible dans Nautilus).

Testons un script basique

Pour les besoin de ce tutoriel, on va créer un script tout simple qui affiche le contenu des variables mentionnées ci-dessus. Le script n’étant pas exécuté dans un shell interactif, il est nécessaire de créer un fichier de log dans lequel on pourra suivre son déroulement (par exemple avec tail -f)

#!/bin/bash
exec &>> "$HOME/nautilus-script-$(basename "$0").log"

echo "\$@=$@"
echo "\$1=$1"
echo "\$2=$2"
echo "\$3=$3"
echo "\$4=$4"
echo
echo "PWD=$PWD"
echo
echo "NAUTILUS_SCRIPT_SELECTED_FILE_PATHS='${NAUTILUS_SCRIPT_SELECTED_FILE_PATHS}'"
echo "NAUTILUS_SCRIPT_SELECTED_URIS='${NAUTILUS_SCRIPT_SELECTED_URIS}'"
echo "NAUTILUS_SCRIPT_CURRENT_URI='${NAUTILUS_SCRIPT_CURRENT_URI}'"
echo "NAUTILUS_SCRIPT_WINDOW_GEOMETRY='${NAUTILUS_SCRIPT_WINDOW_GEOMETRY}'"

Créons une arborescence de fichiers de test en insérant volontairement des espaces dans les noms des éléments, ainsi qu’un retour à la ligne dans un nom de fichier :

vetetix@ordi:~$ mkdir -p "$HOME/demo/sous dossier"
vetetix@ordi:~$ touch "$HOME/demo/fichier 1.txt"
vetetix@ordi:~$ touch "$HOME/demo/fichier 2
> avec newline.txt"
vetetix@ordi:~$ touch "$HOME/demo/sous dossier/fichier 3.txt"

Sélectionnons ces trois fichiers et invoquons le script. Voici ce que ça donne :

$@=sous dossier/fichier 3.txt fichier 1.txt fichier 2
avec newline.txt
$1=sous dossier/fichier 3.txt
$2=fichier 1.txt
$3=fichier 2
avec newline.txt
$4=

PWD=/home/vetetix/demo

NAUTILUS_SCRIPT_SELECTED_FILE_PATHS='/home/vetetix/demo/sous dossier/fichier 3.txt
/home/vetetix/demo/fichier 1.txt
/home/vetetix/demo/fichier 2
avec newline.txt
'
NAUTILUS_SCRIPT_SELECTED_URIS='file:///home/vetetix/demo/sous%20dossier/fichier%203.txt
file:///home/vetetix/demo/fichier%201.txt
file:///home/vetetix/demo/fichier%202%0Aavec%20newline.txt
'
NAUTILUS_SCRIPT_CURRENT_URI='file:///home/vetetix/demo'
NAUTILUS_SCRIPT_WINDOW_GEOMETRY='1310x694+56+27'

On remarque que :

les variables NAUTILUS_SCRIPT_SELECTED_FILE_PATHS (ligne 11) et NAUTILUS_SCRIPT_SELECTED_URIS (ligne 16) contiennent la liste des fichiers séparés par des retours à la ligne ;
Ces variables ont un retour à la ligne comme dernier caractère.
Il pourrait être nécessaire de le retirer manuellement pour pouvoir itérer proprement sur leur contenu. Sans cela, on générerait une itération supplémentaire sur une ligne vide avec un while read.
Ça peut se faire simplement avec l’expansion de paramètres Bash (en) ${var%$'\n'} qui retire un éventuel retour à la ligne en fin de chaîne ;
La variable NAUTILUS_SCRIPT_SELECTED_FILE_PATHS gère mal les retours à la ligne dans les noms de fichiers (cf lignes 13 et 14).
On ne peut donc pas l’utiliser pour itérer sur les noms de fichier.

On pourrait donc soit itérer sur la variable $@ (for fichier in "$@"; do…), soit sur la variable $NAUTILUS_SCRIPT_SELECTED_URIS (après suppression du dernier retour à la ligne).

Testons ce même script basique sur un répertoire monté par gvfs

Dans l’étape précédente, on a utilisé le script sur le système de fichier local. Mais si on l’utilise sur un système de fichier virtuel monté par gvfs, en l’occurrence le partage webdav d’un compte Nextcloud, regardons ce que ça donne :

$@=
$1=
$2=
$3=
$4=

PWD=/run/user/1000/gvfs/dav:host=monserveur.net,ssl=true,user=vetetix,prefix=%2Fremote.php%2Fwebdav

NAUTILUS_SCRIPT_SELECTED_FILE_PATHS=''
NAUTILUS_SCRIPT_SELECTED_URIS='davs://vetetix@monserveur.net/remote.php/webdav/sous%20dossier/Nouveau%20fichier.txt
davs://vetetix@monserveur.net/remote.php/webdav/monfichier.txt
'
NAUTILUS_SCRIPT_CURRENT_URI='davs://vetetix@monserveur.net/remote.php/webdav'
NAUTILUS_SCRIPT_WINDOW_GEOMETRY='1310x694+56+27'

On constate que les variables classiques ($@, $1 et suivantes), ainsi que NAUTILUS_SCRIPT_SELECTED_FILE_PATHS sont vides, et donc non disponibles. Un script nautilus à vocation généraliste, que l’on pourrait partager sur internet, ne doit donc pas se baser sur ces variables puisqu’il ne fonctionnerait pas dans toutes les conditions.

On ne peut donc plus se baser que sur la variable $NAUTILUS_SCRIPT_SELECTED_URIS, qui est la seule qui est disponible dans toutes les conditions, en gérant correctement les retours à la ligne.

Comment itérer sur NAUTILUS_SCRIPT_SELECTED_URIS

On a vu que la variable $NAUTILUS_SCRIPT_SELECTED_URIS contient chaque URI suivie d’un retour à la ligne.

De plus, chaque URI présente ses caractères spéciaux encodés, en particulier les espaces, retours à la ligne et autres “whitespaces” de IFS.

On a donc deux possibilité : une boucle for et une boucle while read.

Avec une boucle for

On peut simplement itérer sur la variable non quotée :

for selected_uri in $NAUTILUS_SCRIPT_SELECTED_URIS; do
    do_something "$selected_uri"
done

Pour éviter d’itérer sur une variable non quotée, on peut préfèrer la transformer en array, puis itérer sur celui-ci :

read -a selected_uris <<< "$NAUTILUS_SCRIPT_SELECTED_URIS"
for selected_uri in "${selected_uris[@]}"; do
    do_something "$selected_uri"
done

Avec une boucle while

Ici aussi, on va itérer sur chaque ligne de la variable, dont supprime le retour à la ligne final :

while read -r selected_uri; do
    do_something "$selected_uri"
done <<< "${NAUTILUS_SCRIPT_SELECTED_URIS%$'\n'}"

Comme les espaces contenues dans les URI sont encodées, il n’est pas nécessaire de modifier l’IFS, contrairement à ce qui se fait habituellement avec ce type de boucle.

La première solution est néanmoins la plus simple, tout en restant sûre.

Transformer une URI en chemin local

On a vu qu’on devait boucler sur les URIs contenues dans $NAUTILUS_SCRIPT_SELECTED_URIS, mais on ne peut pas fournir directement une URI à un programme :

vetetix@ordi:~$ ls file:///home/vetetix/demo/fichier%201.txt
ls: impossible d'accéder à 'file:///home/vetetix/demo/fichier%201.txt': Aucun fichier ou dossier de ce type

Il faut donc transformer ces URI en chemins locaux. On a pour cela deux options : l’utilisation de gio, ou une solution “à la main”.

Utiliser GIO pour transformer une URI en chemin local

Les systèmes de fichiers virtuels étant créés par GVFS, on peut utiliser gio pour traduire les URIs en chemins locaux, car celui-ci sait par définition quel est le point de montage local d’un système de fichier virtuel GVFS :

vetetix@ordi:~$ gio info file:///home/vetetix/demo/fichier%201.txt | grep "local path" | cut -d ' ' -f 3-
/home/vetetix/demo/fichier 1.txt

vetetix@ordi:~$ gio info davs://vetetix@monserveur.net/remote.php/webdav/sous%20dossier/Nouveau%20fichier.txt | grep "local path" | cut -d ' ' -f 3-
/run/user/1000/gvfs/dav:host=monserveur.net,ssl=true,user=vetetix,prefix=%2Fremote.php%2Fwebdav/sous dossier/Nouveau fichier.txt

Ça a l’air de bien fonctionner. Par contre, la solution ci-dessus pose problème avec des retours à la ligne, puisque le nom du fichier se retrouve affichée sur plusieurs lignes, alors qu’on ne récupère que la première :

vetetix@ordi:~$ gio info file:///home/vetetix/demo/fichier%202%0Aavec%20newline.txt | grep "local path" | cut -d ' ' -f 3-
/home/vetetix/demo/fichier 2

On doit donc utiliser plus finement grep pour récupérer tout le chemin local, sur plusieurs lignes, avec l’option “-A 1” (s’il y a un seul retour à la ligne) :

vetetix@ordi:~$ gio info file:///home/vetetix/demo/fichier%202%0Aavec%20newline.txt | grep -A 1 '^local path: '
local path: /home/vetetix/demo/fichier 2
avec newline.txt

S’il y a plus d’un retour à la ligne dans le chemin complet (dans le nom du fichier ou dans ses répertoires parents), il faut les compter, puis prendre ce nombre en compte :

vetetix@ordi:~$ N=$(echo -n "file:///home/vetetix/demo/fichier%202%0Aavec%20newline.txt" | grep -Fo '%0A' | wc -l)
vetetix@ordi:~$ gio info file:///home/vetetix/demo/fichier%202%0Aavec%20newline.txt | grep -A "$N" '^local path: '
local path: /home/vetetix/demo/fichier 2
avec newline.txt

Maintenant, il faut juste retirer le début de ligne (“local path: “) pour obtenir le chemin local complet :

vetetix@ordi:~$ N=$(echo -n "file:///home/vetetix/demo/fichier%202%0Aavec%20newline.txt" | grep -Fo '%0A' | wc -l)
vetetix@ordi:~$ var=$(gio info file:///home/vetetix/demo/fichier%202%0Aavec%20newline.txt | grep -A "$N" '^local path: ')
vetetix@ordi:~$ printf '%s' "${var#local path: }"
/home/vetetix/demo/fichier 2
avec newline.txt

Dans une fonction, cela donne ceci :

get_path_from_uri() {
    local newlines path_lines
    newlines=$(echo -n "$1" | grep -Fo '%0A' | wc -l)
    path_lines=$(gio info "$uri" | grep -m 1 -A "$newlines" '^local path: ')
    echo -n "${path_lines#local path: }"
}

Mais… il y a un “mais” : cette solution utilisant la sortie de gio impose l’utilisation de command substitution dont la sortie est assignée à une variable (var=$(command)). Cela fait que si notre nom de fichier se termine par un ou plusieurs retours à la ligne, ceux-ci seront supprimés et le script plantera.

D’autre part, on utilise aussi la fonction grep, qui a la fâcheuse caractéristique de renvoyer un code de sortie non nul lorsqu’elle ne trouve aucune des chaines recherchées. Les gens qui utilisent le unofficial bash strict mode (set -euo pipefail ou mieux, set -eEuo pipefail) préfèreront s’en passer.

On doit donc abattre notre dernière carte, la solution “a la mano”.

Transformer manuellement une URI en chemin local

Il est possible de transformer une URI en chemin local à la main, avec les élements dont on dispose déjà, et sans utiliser de substitution de commande.

On constatera que la valeur initiale de $PWD représente le chemin local de $NAUTILUS_SCRIPT_CURRENT_URI, et qu’il contient donc le point de montage d’un éventuel système de fichier virtuel :

# Sur un système de fichier local :
PWD=/home/vetetix/demo
NAUTILUS_SCRIPT_CURRENT_URI='file:///home/vetetix/demo'

# Sur un système de fichier virtuel :
PWD=/run/user/1000/gvfs/dav:host=monserveur.net,ssl=true,user=vetetix,prefix=%2Fremote.php%2Fwebdav
NAUTILUS_SCRIPT_CURRENT_URI='davs://vetetix@monserveur.net/remote.php/webdav'

On va donc utiliser la valeur initiale de $PWD associée à l’URI dont on aura retiré le préfixe correspondant à $NAUTILUS_SCRIPT_CURRENT_URI.

Attention, la valeur de $PWD peut changer si une commande (par exemple un cd) change le répertoire actuel. Il faut donc très tôt en récupérer la valeur dans une autre variable, pour la sanctuariser (je l’appellerai $IWD pour Initial Working Directory).

Récupérer la partie finale du chemin

Pour enlever la première partie de l’URI, on va à nouveau utiliser une expansion de paramètre de Bash : ${MON_URI#"$NAUTILUS_SCRIPT_CURRENT_URI"} (ici, MON_URI est la variable à traiter).

vetetix@ordi:~$ MON_URI='file:///home/vetetix/demo/sous%20dossier/fichier%203.txt'
vetetix@ordi:~$ NAUTILUS_SCRIPT_CURRENT_URI='file:///home/vetetix/demo'
vetetix@ordi:~$ echo "${MON_URI#"$NAUTILUS_SCRIPT_CURRENT_URI"}"
/sous%20dossier/fichier%203.txt

Décoder les caractères encodés de l’URI

Il faut aussi décoder les caractères spéciaux de l’URI qui font l’objet d’un encodage-pourcent, ce que l’on va faire en les convertissant en encodage hexadécimal (il suffit de remplacer “%” par “\x”), puis en interprétant ceux-ci avec la commande printf et le format de sortie'%b' en lieu et place de l’habituel '%s' :

vetetix@ordi:~$ percent_var="/sous%20dossier/fichier%203.txt"
vetetix@ordi:~$ hex_var=${percent_var//%/\\x}
vetetix@ordi:~$ echo "$hex_var"
/sous\x20dossier/fichier\x203.txt
vetetix@ordi:~$ printf '%b' "$hex_var"
/sous dossier/fichier 3.txt

La partie de lego pour tout mettre ensemble

On retrouve alors le chemin “local” en concaténant la valeur de $PWD ($IWD) avec la fin de l’URI décodée :

vetetix@ordi:~$ IWD=/home/vetetix/demo
vetetix@ordi:~$ NAUTILUS_SCRIPT_CURRENT_URI="file:///home/vetetix/demo"
vetetix@ordi:~$ MON_URI="file:///home/vetetix/demo/fichier%202%0Aavec%20newline.txt"
vetetix@ordi:~$ FIN_URI=${MON_URI#"$NAUTILUS_SCRIPT_CURRENT_URI"}
vetetix@ordi:~$ printf -v CHEMIN '%s%b' "${IWD}" "${FIN_URI//%/\\x}"
vetetix@ordi:~$ echo "$CHEMIN"
/home/vetetix/demo/fichier 2
avec newline.txt

Dans une fonction, cela pourrait donner ceci :

readonly IWD=$PWD
set_path_from_uri() {
    uri_end=${1#"$NAUTILUS_SCRIPT_CURRENT_URI"}
    printf -v selected_path '%s%b' "${IWD}" "${uri_end//%/\\x}"
}

Vous aurez remarqué que cette fonction ne renvoit rien, mais définit la valeur de la variable (globale) selected_path. À l’utilisateur de faire ce qui est nécessaire pour ne pas casser le contenu de cette variable par la suite.

Conclusion : un script moins simple, mais plus sain

Maintenant qu’on a trouvé toutes les briques nécessaires pour invoquer un script Nautilus sans se prendre les pieds dans le tapis que sont retours à la ligne et les systèmes de fichier virtuels, mettons le tout dans un script basique qui va simplement faire un ls -ld sur chaque fichier ou dossier sélectionné.

J’ai une préférence pour la conversion directe de l’URI en chemin sans passer par une fonction ni une variable globale :

#!/bin/bash
readonly IWD=$PWD
for selected_uri in $NAUTILUS_SCRIPT_SELECTED_URIS; do
    uri_end=${selected_uri#"$NAUTILUS_SCRIPT_CURRENT_URI"}
    printf -v selected_path '%s%b' "${IWD}" "${uri_end//%/\\x}"
    # Do something here:
    ls -ld "$selected_path"
done

Ce code devrait servir de base pour toute création de script Nautilus en Bash, car il n’est finalement pas très compliqué et permet d’éviter bien des écueils.

J’ai testé ce code, qui fonction avec tous les fichiers que je leur ai soumis :

avec des espaces (heureusement) ;
avec des retours à la ligne, y compris en fin de nom ;
avec des astérisques ou des points d’interrogation ;
avec des backslash (bien que ls affiche mal le résultat dans ce cas, mais ce n’est pas la faute des scripts Nautilus).

Pour rappel, la méthode la plus courante pour itérer sur les fichiers fait trois lignes de moins, mais nous avons vu qu’elle n’est pas universelle :

#!/bin/bash
for arg; do
    # Do something here:
    ls -ld "$arg"
done

Si vous avez une solution plus claire, plus concise, ou plus générale, n’hésitez pas à me la soumettre afin que je mette à jour mon billet.

Ressources supplémentaires

Quelques ressources si vous voulez explorer un peu plus ces scripts Nautilus :

Sur le wiki de la communauté Ubuntu anglophone (en)
Sur le wiki de la communauté Ubuntu francophone
Sur le wiki Archlinux (en)
Ou encore, la très classique recherche sur les interwebs…

La vanlife est-elle écologique ?

2020-12-10T00:00:00+01:00

Ah, qu’ils sont enviables ces vanlifers, avec leur liberté. Ces nouveaux hippies #flowerpower qui nous font rêver avec leurs pages Instagram et leurs photos, planches de surf à la main, chaussures de randonnée aux pieds, dans des lieux tous plus magnifiques les uns que les autres. Ils exhibent une vie simple, minimaliste, proche de la nature, respectueuse de l’environnement. Écolo et durable.

Et ces youtubers exceptionnels, partis vivre le nomadisme en famille, faisant le tour du monde de pays en pays, offrants à leurs enfants une expérience unique à bord d’un camping car ou, mieux, d’un véritable poids lourd aménagé ? Le rêve, tout quitter, avec ceux qu’on aime, se mettre freelance pour gagner sa croûte et faire l’éducation des enfants “à la maison” avec le CNED. Pas d’attache, pas de contrainte (sauf en temps de pandémie virale, mais là c’est exceptionnel).

Il y a aussi les camping caristes plus classiques, ceux qu’on connaît dans la vraie vie, qu’on croise tous les jours sur les routes. Vous savez, ceux qui, retraités, sont en vacances toute l’année et parcourent l’Europe et le Maghreb six mois durant. Le véhicule en hivernage de novembre à avril, la maison en OTV de mai à octobre, le mois de juillet au bord des routes pour suivre une étape du tour de France sur deux. L’aboutissement d’une vie, le camping car acheté une fois le crédit de la maison remboursé, une retraite bien méritée après une vie à trimer.

Enfin, il y a moi, qui me suis laissé tenter par l’achat d’un fourgon aménagé, pour les vacances et les weekends, après avoir validé le concept en van aménagé pour mon voyage de noces. C’est un gros investissement financier, mais à moi la vie simple, les week-ends au grand air loin du quotidien, le minimalisme d’un petit espace de vie, l’économie des ressources rares que sont l’eau, l’électricité ou le gaz dans ces véhicules.

La comparaison avec notre mode de vie polluant

C’est pourtant vrai, quand on y pense, on a des vies de dingues au quotidien dans nos vastes logements. On pollue, on laisse les lumières allumées, on prend de longues douches chaudes, on jette des kilos de plastiques et autres déchets tous les jours, on a largement la place pour stocker tous les gadgets inutiles que les marketeux nous ont persuadé d’acheter (parce qu’au fond de nous, on ne savait pas que c’était indispensable jusqu’à ce qu’on en voit la pub au milieu de Koh Lanta) et on prend cette saleté de bagnole dès qu’on peut. Bref, on détruit notre planète, inconséquents que nous sommes (#nofutur #yolo pour que les plus jeunes comprennent), et par dessus tout on se prive des bienfaits de la nature.

Mais la vanlife, qu’elle soit permanente ou occasionnelle, seul, en couple ou en famille, est-elle écolo ? Est-elle vraiment un mode de vie responsable ? Est-elle compatible avec le respect de la nature que le réveil écologique ambiant de ces dernières années édicte ? Personnellement je n’en suis pas bien certain, et je ne suis pas le seul à me poser des questions.

La vanlife éco-responsable

Alors oui, il y a ces initiatives, ici ou là, pour construire un projet éco-responsable, une itinérance sociale basée sur le troc et l’entraide, avec des toilettes sèches installées dans un fourgon de 25 ans d’âge aménagé avec du bois de récupération. Le camping car électrique n’est pourtant que chimère (allez mettre 600kg de batteries dans un véhicule qui fait déjà 3 tonnes), et la version à pile à combustible, carburant à l’hydrogène, n’existe qu’à l’état de prototype. Certains vanlifers argueront qu’ils économisent des dizaines de milliers de litres d’eau et des centaines de kilowattheures d’électricité par an. Certes. Mais pas besoin d’une maison sur roues pour cela. Une vie simple et éco-responsable, emprunte de minimalisme, zéro déchet, cuisine maison, vegan locale, sans achat compulsif, ça peut se mettre en place dans un appartement ou une maison, pour peu que cette dernière ne soit pas une passoire thermique chauffée au fioul.

Le critère qui met tout le monde au tapis : les émissions de CO₂

Parce qu’il est là, le critère numéro un, celui qui met tous les autres au tapis : les émissions de CO₂. Peu importe que tu aies consommé peu d’eau dans l’année ou que tu aies mangé vegan sans exploiter la souffrance animale. Si tu balances plus de deux tonnes de CO₂ par an et par personne, tu diriges le monde lentement vers un écocide qui sera gravement préjudiciable à l’espèce humaine.

Et combien ça émet de CO₂ un vanlifer, juste pour bouger son véhicule ? Un fourgon aménagé récent sur Fiat Ducato, ça annonce une conso moyenne de 8 litres aux 100 kilomètres. C’est souvent optimiste ces annonces, je m’attends plus à du 10L/100km en conditions réelles avec famille et bagages, PTAC de 3T5 atteint. De même, un gros integral et sa prise au vent, ça doit consommer du 12L/100. Pour ce qui est des véritables vans de vanlifers nord-américains qui nous font rêver, un Mercedes Sprinter 4x4, c’est du 17L/100. Et on en parle, du poids lourd de 5 ou 6 tonnes pour déplacer une famille de 5 personnes ? 25 litres aux cent ?

Mais d’ailleurs, combien de kilomètres on fait en simple fourgon à 10L/100, pour atteindre les 2 tonnes de CO₂ émises ? Rapide calcul :

1 litre de gasoil pur et parfaitement brulé émet 2,6 kg de CO₂ ;
10 litres génèrent donc 26 kg (pour 100 km) ;
En 1 km on génère donc 0.26kg de CO₂ (260 grammes — vous l’aviez vue venir, la petite règle de trois ?).
Pour générer 2 tonnes (2000 kg) de CO₂, il suffit donc de parcourir 2000/0,26=7692km

Arrondissons à 8000 km (c’est l’ordre de grandeur qui est important, pas le chiffre exact).

Un vanlifer, camping cariste ou autre touriste qui se déplace seul, une fois qu’il a parcouru 8000 km, il doit arrêter de vivre, consommer, manger, boire ou faire l’entretien de son van s’il ne veut pas participer à la destruction du climat, puisque toute activité supplémentaire générerait des grammes de CO₂ que la planète n’est pas en mesure d’assimiler.

Avec une famille de 4 personnes ça fait théoriquement le quadruple, soit environ 32 000 km (donc pas encore assez pour faire le tour du monde) et toujours en supposant qu’à coté de ça le chef de famille assume d’allouer la totalité du “crédit carbone” de son foyer au réservoir de son véhicule et laisse tout le monde crever de faim et de soif (vous le saviez, qu’un simple café représente environ 50 grammes de CO₂ ?).

Un vanlifer américain avec un véhicule 4x4 à 17L/100 atteint les 2 tonnes en 4500 km. Vous vous voyez traverser le Canada et les grandes plaines américaines en vous limitant à la moitié de ça (pour garder de la marge pour s’habiller, boire, manger… Survivre) ? À mes yeux, ça n’est pas compatible avec la “grande vie vanlife”, qui nécessite d’être totalement libre pour pouvoir s’épanouir.

Alors, on fait quoi ?

La vérité c’est qu’on nous vend du rêve, celui de la liberté absolue tant qu’on en a les moyens financiers, celui de la vie d’avant, celui pour lequel nos parents se sont battus, mais qui se révèle aujourd’hui être une détestable illusion générant frustration et colère quand on en prend conscience : consommer rendrait heureux. Ce n’est pas le cas. Tout n’est pourtant pas interdit, mais ça doit se faire à petites doses, avec mesure, avec prudence.

Un kilogramme de CO₂ émis aujourd’hui aura le même effet qu’un autre émis en 2050 (date à laquelle l’ensemble des pays signataires des accord de Paris se sont engagés à être neutres en carbone pour limiter le réchauffement climatique à 2°C). Se dire qu’on peut sans conséquence émettre autant qu’on veut aujourd’hui et réduire lentement ses émissions jusqu’à la neutralité en 2050, ça n’est pas une gestion responsable, “en bon père de famille”. C’est de l’égoïsme.

Dans ce cas, que pouvons nous faire ? Faisons des petits trajets, des petits week-end de 150 ou 200km pour trouver un coin de nature près de chez soi. Oublions les road trip à travers l’Europe. Limitons-nous à 2000, 3000 ou 4000 km par an et par famille, ça ne fera que 500 kg ou 1 tonne de CO₂. C’est déjà beaucoup (peut-être trop ?), mais c’est suffisant pour profiter tout en commençant à faire la différence à long terme si c’est associé à de sérieux efforts au quotidien pour atteindre un mode de vie durable.

En 2050, théoriquement, si la France respecte ses engagements et qu’à titre individuel on doit se restreindre pour être dans la limite de 2 tonnes de CO₂, ce qu’on n’atteindra qu’avec difficulté en respectant nos besoin vitaux de base (manger, s’abriter, se chauffer et se soigner), la question de dépenser ne serait-ce que 25% de cette quantité d’émission pour un seul loisir ne se posera plus : on ne le fera pas.

De toute façon et avant cette échéance, quand le gazole sera à 5€ le litre, voire plus (à cause des taxes carbone ou de l’augmentation du prix du baril), on ne pourra plus se permettre, financièrement cette fois, d’être inconséquent. On se souviendra avec nostalgie de la liberté des vanlifer d’antan et on acceptera nos nouvelles contraintes, de gré ou de force.

Filtrer les messages d’erreur de zenity au sujet d’un “transient parent”

2020-06-13T00:00:00+02:00

Lorsqu’on développe un “petit” script bash, on peut parfois vouloir y ajouter une interface graphique basique. Le plus simple pour cela est d’utiliser zenity. Cet utilitaire fournit des boites de dialogue en Gtk pour différents usages.

Zenity est très pratique, mais souffre d’un bug horripilant. Regardez plutôt :

$ zenity --info
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

En fonction de la version de zenity, ce message d’erreur est systématique et s’affiche à chaque appel du programme. Il gêne beaucoup de monde car bien qu’envoyé sur STDERR donc ne bloquant pas le fonctionnement normal de zenity (dont on exploite uniquement la sortie standard STDOUT et les statuts de sortie $?), mais pollue visuellement la console si vous suivez ce qu’il s’y passe pendant l’exécution de votre script.

La solution qui est proposée à chaque fois est de se débarrasser de STDERR, de cette manière : zenity --info 2>/dev/null. Hop, plus de message d’erreur, et on peut même rendre cette solution plus “permanente”.

Sauf que… on n’a plus de message d’erreur du tout, pas uniquement celle qui nous gêne.

J’ai donc recherché une solution plus élégante et moins radicale et j’ai trouvé mon bonheur sur ce billet de blog (en) qui explique comment bidouiller avec les fichiers de sortie pour filtrer STDOUT avec grep, puis j’ai complété la solution avec cette réponse sur Stackoverflow (en) pour pouvoir continuer à exploiter le statut de sortie de zenity.

On en arrive à la solution ci-dessous :

zenity() { command zenity "$@" 3>&1 1>&2 2>&3 | grep -v "transient"; exit ${PIPESTATUS[0]} ) 3>&1 1>&2 2>&3

La même, mieux formatée sur plusieurs lignes :

zenity() {
  ( command zenity "$@" 3>&1 1>&2 2>&3 | grep -v "transient"
    exit ${PIPESTATUS[0]}
  ) 3>&1 1>&2 2>&3
}

Insérez ce code au début de votre script, ou dans votre bashrc, et utilisez zenity comme avant, sans être pollué par ce message, tout en conservant les autres éventuels messages d’erreur.

Installer Aurora Services avec adb

2020-06-12T00:00:00+02:00

Aurora est un magasin d’applications alternatif permettant d’accéder au catalogue du Google Play Store. Il est utile quand on a choisi d’utiliser une ROM Android alternative sans les services Google Play. Par défaut, il ne permet néanmoins pas d’installer automatiquement les applications et leurs mises à jour. Afin d’éviter de pénibles actions manuelles, nous allons voir comment installer les Services Aurora.

La procédure à suivre est vaguement indiquée sur le README officiel. Ce n’est pas assez détaillé pour qu’un non initié y comprenne quoi que ce soit, donc je détaille ici la marche à suivre.

Installation sur un téléphone non rooté

Le postulat de départ est qu’on a affaire à un téléphone avec une ROM alternative, non rooté mais avec un recovery custom (par exemple TWRP).

Prérequis

Un ordinateur avec adb ;
Un téléphone Android ;
Un câble USB.

Téléchargez les fichiers nécessaires (consultez la page de téléchargement pour vous assurer de récupérer la dernière version disponible − 1.0.6 lors de la rédaction de ce billet) :

wget https://gitlab.com/AuroraOSS/AuroraServices/uploads/c80bee54c1dc782df78a31065c710e59/AuroraServices-v1.0.6.apk
wget https://gitlab.com/AuroraOSS/AuroraServices/raw/master/app/src/main/assets/permissions_com.aurora.services.xml

Redémarrez le téléphone

Redémarrez en mode recovery (la manipulation dépend du modèle de téléphone que vous avez) ;
Dans le recovery, montez la partition System (Ne cochez bien évidemment pas la case “Mount system partition read-only”) ;
Branchez le téléphone à l’ordinateur avec un câble USB.

Assurez-vous que votre téléphone est bien reconnu. adb devices devrait vous lister un périphérique “recovery”. Si la liste est vide, c’est que vous avez loupé quelque chose.

Utilisez ADB

Assurez-vous que vous avez accès à /system. La commande adb shell ls /system doit vous retourner une liste non vide :

$ adb shell ls /system
addon.d
app
bin
build.prop
compatibility_matrix.xml
etc
fake-libs
fake-libs64
fonts
framework
lib
lib64
lost+found
media
priv-app
product
recovery-from-boot.bak
usr
vendor
xbin

Si c’est tout bon, installez les deux fichiers téléchargés à leur emplacement. On les renomme au passage pour respecter la cohérence avec leurs voisins :

adb push AuroraServices-v1.0.6.apk /system/priv-app/AuroraServices/AuroraServices.apk
adb push permissions_com.aurora.services.xml /system/etc/permissions/com.aurora.services.xml

Si vous obtenez le message d’erreur suivant, c’est que la partition system est montée en lecture seule :

adb: error: failed to copy 'AuroraServices-v1.0.6.apk' to '/system/priv-app/AuroraServices/AuroraServices.apk': remote couldn't create file: Read-only file system

Sur un téléphone rooté avec Magisk

Installez le module Magisk officiel. Je n’en sais pas plus, je n’utilise pas cette méthode.

Sur un téléphone rooté sans Magisk

Avec un téléphone rooté, il n’est pas nécessaire de passer par le recovery. Il est possible d’accorder à adb les droits root (et donc la possibilité d’écrire dans la partition system).

Activer le mode développeur ;
Dans les “Options pour les développeurs” nouvellement apparues, activer le “Dégage Android” (activer l’interface Android Debug Bridge) ;
Accorder l’accès root à ADB.
Brancher le téléphone à l’ordinateur avec un câble USB. Lorsque le téléphone vous le demandera, indiquez-lui de faire confiance à l’ordinateur (Note : il est possible d’utiliser ADB en Wi-Fi après avoir activé l’option idoine sur le téléphone puis avoir couplé les deux appareils avec la commande adb connect IP_DU_TÉLÉPHONE:PORT).

Assurez-vous que votre téléphone est bien reconnu. adb devices devrait vous lister un périphérique “device”. Si la liste est vide ou que le périphérique est indiqué comme étant “unauthorized”, c’est que vous avez loupé quelque chose.

Utilisez maintenant ADB comme décrit plus haut.

À la fin de vos manipulations, pensez à désactiver le “mode débogage USB”.

Utilisation des fonctionnalités

Redémarrez le téléphone et lancez l’application Aurora Services.

Acceptez les permissions demandées par l’application, puis accordez les privilèges nécessaires à l’application Aurora.

Dans les “Réglages” de l’application Aurora, dans la section “Installations”, choisissez la méthode d’installation “Services Aurora”.

Profitez désormais des installations et mises à jour ne nécessitant plus d’interventions manuelles.

Aparté

La méthode détaillée dans ce billet est aussi applicable à l’installation de l’extension F-Droid Privileged Extension, lorsque celle-ci n’est pas installée par défaut par le mainteneur de votre ROM. Le fichier privapp-permissions-org.fdroid.fdroid.privileged.xml doit alors contenir :

<?xml version="1.0" encoding="utf-8"?>
<permissions>
    <privapp-permissions package="org.fdroid.fdroid.privileged">
        <permission name="android.permission.DELETE_PACKAGES"/>
        <permission name="android.permission.INSTALL_PACKAGES"/>
    </privapp-permissions>
</permissions>

Nextcloud - Please update your PHP version

2020-05-31T00:00:00+02:00

Depuis la mise à jour de Nextcloud en version 18 sur Yunohost, je rencontre une erreur assez pénible liée à la version de PHP exécutée par défaut.

On va s’attacher à décrire puis à corriger ce problème.

Description du problème

Nextcloud 18 nécessite un environnement PHP en version 7.2 minimum. Sur Yunohost les version 5, 7.0 et 7.3 sont disponibles. Pour une raison que j’ignore Yunohost force la version par défaut à 7.0, ce qui engendre un “léger” contretemps. Lorsque le cron de Nextcloud est lancé toutes les 15 minutes avec l’exécutable php, l’exécution échoue :

Cron nextcloud@cloud php -f /var/www/nextcloud/cron.php 2>&1

This version of Nextcloud requires at least PHP 7.2
You are currently running 7.0.33-29+0~20200514.36+debian9~1.gbp126f6f. Please update your PHP version.

Je reçois donc cet e-mail toutes les 15 minutes, soit 96 fois par jour… C’est plutôt pénible.

Comment corriger ce problème

Il existe deux moyens de corriger ce problème.

Solution 1 : Rétablir la version par défaut de PHP du système

Il suffit de lancer (en root ou sudo) : update-alternatives --config php :

Il existe 3 choix pour l'alternative php (qui fournit /usr/bin/php).

  Sélection   Chemin           Priorité  État
------------------------------------------------------------
  0            /usr/bin/php7.3   73        mode automatique
  1            /usr/bin/php5     50        mode manuel
* 2            /usr/bin/php7.0   70        mode manuel
  3            /usr/bin/php7.3   73        mode manuel

Appuyez sur <Entrée> pour conserver la valeur par défaut[*] ou choisissez le numéro sélectionné :0
update-alternatives: utilisation de « /usr/bin/php7.3 » pour fournir « /usr/bin/php » (php) en mode automatique

C’est une solution que j’avais déjà mise en place. Elle est simple et rapide, mais elle n’a pas survécu à une mise à jour de Yunohost.

Solution 2 : Spécifier manuellement la version de PHP de cron

On peut tout simplement éditer le fichier cron (crontab -u nextcloud -e) et modifier la dernière ligne :

*/15 * * * * php -f /var/www/nextcloud/cron.php 2>&1

qui doit devenir :

*/15 * * * * /usr/bin/php7.3 -f /var/www/nextcloud/cron.php 2>&1

Il n’y a plus qu’à espérer que cette modification soit plus pérène, avant que le bug ne soit définitivement corrigé dans Yunohost.

Installer Tribal Trouble sur Ubuntu 18.10

2019-03-11T00:00:00+01:00

Il y a cinq ans, j’avais publié un billet sur mon ancien blog afin de ne pas oublier comment faire fonctionner le jeu Tribal Trouble sur une version “récente” de Ubuntu (en effet, c’est un jeu sorti en 2005, qui a été prévu pour fonctionner sur un système 32 bits. Je suis étonné qu’il soit encore possible de le lancer). Je mets ici à jour le tutoriel en question, car il n’est plus d’actualité.

Table des matières

Installation du jeu
Bidouilles pour que tout fonctionne
- Activer le son
- Avoir accès au clavier pendant le jeu
Jouer !
Intégration au système
Autres astuces

Le jeu est désormais open-source et gratuit, libéré sur Github. Une reprise du code avait été entreprise par un groupe de développeurs, sous le nom de Tribal Trouble Remastered, mais le projet a rapidement été abandonné.

Je vais donc m’atteler à expliquer en détail les étapes nécessaires à une installation complète de la version originale de Tribal Trouble sur Ubuntu 18.10 (version actuelle).

Installation du jeu

Il faut télécharger le binaire d’installation sur github et l’exécuter :

mkdir ~/Jeux/
cd ~/Jeux/
wget https://github.com/sunenielsen/tribaltrouble/raw/master/binaries/TribalTroubleSetup.sh
sh TribalTroubleSetup.sh
cd tribaltrouble

Il est nécessaire d’installer quelques dépendances pour que tout fonctionne :

sudo apt install libgl1:i386 libxrandr2:i386 libxcursor1:i386 libopenal1:i386

Bidouilles pour que tout fonctionne

Il reste quelques manipulations à effectuer pour corriger quelques problèmes.

Activer le son

Par défaut, le son ne fonctionne pas, il faut remplacer une bibliothèque fournie avec le jeu par celle que nous venons d’installer avec apt :

mv gamedata/data-1/native/.svn/text-base/libopenal.so.svn-base{,.bak}
ln -s /usr/lib/i386-linux-gnu/libopenal.so.1 gamedata/data-1/native/.svn/text-base/libopenal.so.svn-base

Avoir accès au clavier pendant le jeu

Pour rendre le clavier accessible (ne serait-ce que pour pouvoir mettre en pause ou quitter une partie avant la fin), il faut appliquer une modification trouvée sur ce tutoriel relatif à Minecraft (lui aussi développé en Java) :

Il faut lancer Tribal Trouble en utilisant l’option XMODIFIERS. Éditez le fichier tribaltrouble et modifiez la dernière ligne comme ceci :

XMODIFIERS= $JAVA -Xmx80000000 -cp loader.jar com.oddlabs.loader.Loader $JAVA loader.jar com.oddlabs.tt.Main --silent

Jouer !

Testez donc le jeu en le lançant avec la commande ./tribaltrouble dans un terminal. Cela permettra de vérifier que tout fonctionne sans erreur, et ça créera le dossier de configuration (~/.TribalTrouble).

Intégration au système

Quelques manipulations sont nécessaires pour intégrer le jeu au système et pouvoir le lancer comme toute autre application.

Créer un fichier .desktop

Afin de pouvoir lancer le jeu depuis les menus du système, on va créer le fichier .desktop approprié. Éditez le fichier ~/.local/share/application/tribaltrouble.desktop et mettez ceci dedans :

[Desktop Entry]
Type=Application
Name=TribalTrouble
Categories=Game;StrategyGame;
Comment=”Jeu libre de stratégie en temps réel”
Exec=/home/”VOTRE_USER”/Jeux/tribaltrouble/tribaltrouble
Icon=/home/”VOTRE_USER”/Jeux/tribaltrouble/tribaltrouble.png
Terminal=false

Remplacer l’icône du jeu

Pour une raison que j’ignore, l’icone du jeu semble corrompue, et ne s’affiche donc pas dans le menu système, on va donc la remplacer par un autre, trouvée sur internet :

mv tribaltrouble.png{,.bak}
wget https://dl2.macupdate.com/images/icons128/18613.png?d=1331563899 -O tribaltrouble.png

Activer la version complète du jeu

Le jeu a été libéré tel quel, sans modification de la part de ses créateurs. Ainsi, bien que désormais gratuit, il demande toujours une activation pour avoir accès à toutes les fonctionnalités. Ses créateurs fournissent donc un fichier d’activation à placer dans le dossier des paramètres :

Téléchargez le fichier registration et placez-le dans ~/.TribalTrouble/registration.

Autres astuces

J’ajoute ici quelques éléments supplémentaires, qui étaient disponibles sur feu le site officiel.

Avoir accès à la deuxième campagne

Pour avoir accès à la deuxième campagne sans avoir terminé la première, il suffit d’ajouter cette ligne au fichier ~/.TribalTrouble/settings :

has_native_campaign=true

Avoir accès aux codes de triche

Au cours d’une partie en solo (le seul mode de jeu encore disponible), il est possible d’activer les codes de triche en ouvrant une invite de dialogue (touche Entrer), et de taper /iamacheater.

On a alors accès aux codes suivants :

F1: Insert peon
F2: Insert rock warrior
F3: Insert iron warrior
F4: Insert chicken warrior
F5: Insert chieftain
F6: Kill selected unit/building
F7: Toggle tree visibility
F8: Toggle wireframe mode

Remarques diverses

Il n’y a désormais plus de bug concernant le passage du jeu en plein écran, ça semble être un progrès par rapport au dernier tutoriel. Par contre, je note aussi qu’il m’a été impossible de lancer le jeu lorsque j’étais sous Ubuntu 17.10, utilisant Wayland en lieu et place de X11. Ce dernier étant voué à disparaitre au profit du premier, je crains qu’un jour il ne soit plus possible de jouer à Tribal Trouble.

Bon jeu !

Héberger son propre serveur de calendrier et de contacts

2015-08-12T00:00:00+02:00

Un des services indispensables pour s’affranchir de Google en s’auto-hébergeant est le serveur de calendrier et de contacts. On va ici installer le logiciel Radicale, serveur calDAV et cardDAV simple.

Il existe plusieurs alternatives (DAVical, Baïkal, OwnCloud, etc.), mais Radicale est l’un des plus simples à mettre en œuvre pour un serveur auto-hébergé familial. Il ne demande aucune base de donnée, et n’ayant pas d’interface d’administration il se personnalise facilement via des fichiers de configuration.

Table des matières

Installation
Configuration
Création des collections
Étapes supplémentaires
- Intégration à fail2ban
- Suivi du projet

Installation

La version présente dans les dépôts de Ubuntu 14.04 LTS est assez ancienne (0.8, au lieu de 0.10 à l’heure où je rédige ce tutoriel), il vaut donc mieux l’installer par une méthode alternative. Il est possible de l’installer par un sudo pip install radicale, de créer un utilisateur dédié, de mettre en place un script init, etc. mais j’ai trouvé mieux.

Ce logiciel étant très simple, sans dépendances particulières (python et adduser, autant dire rien du tout), est possible d’aller chercher les packages .deb de la version 0.10 sur les dépôts d’Ubuntu 15.10 et de les installer manuellement :

wget http://fr.archive.ubuntu.com/ubuntu/pool/universe/r/radicale/radicale_0.10-2_all.deb
wget http://fr.archive.ubuntu.com/ubuntu/pool/universe/r/radicale/python-radicale_0.10-2_all.deb
sudo dpkg -i python-radicale_0.10-2_all.deb
sudo dpkg -i radicale_0.10-2_all.deb

Radicale est désormais installée proprement, avec son utilisateur, ses dossiers de travail, son script init, etc.

Comme j’utiliserai l’authentification via LDAP, je dois installer le paquet python-ldap :

sudo aptitude install python-ldap

Configuration

Dans un premier temps, il faut activer le daemon via un sudo vim /etc/default/radicale et décommenter la ligne ENABLE_RADICALE=yes

Le service peut désormais se lancer avec un :

sudo service radicale start

Configuration de Radicale

La configuration se fait dans le dossier /etc/radicale/, dans le fichier config. Pour exemple, voici le mien, sans les commentaires et nettoyé des informations personnelles :

[server]
hosts = 0.0.0.0:5232, [::]:5232
base_prefix = /radicale/
realm = Radicale - Mot de passe necessaire

[encoding]
request = utf-8
stock = utf-8

[well-known]
caldav = '/%(user)s/caldav/'
carddav = '/%(user)s/carddav/'

[auth]
type = LDAP
ldap_url = ldap://localhost:389/
ldap_base = ou=user,dc=exemple,dc=fr
ldap_attribute = mail
ldap_filter = (objectClass=posixAccount)
ldap_scope = OneLevel

[git]

[rights]
type = from_file
file = /etc/radicale/rights

[storage]
type = filesystem
filesystem_folder = /var/lib/radicale/collections

[logging]
config = /etc/radicale/logging
#debug = True
#full_environment = False

[headers]
#Access-Control-Allow-Origin = *

Une fois le fichier modifié, un sudo service radicale restart est requis.

Pour information, vous pouvez trouver l’ensemble des options par défaut (qui n’ont donc pas besoin d’être inscrites explicitement dans le fichier config, sauf en cas de modification) directement dans la source du logiciel.

Vous remarquerez que je n’active pas le chiffrement de la communication, car c’est le serveur web (Nginx) qui s’en chargera avant de “proxifier” les requêtes.

En cas de souci, vous pouvez procéder par étapes (utiliser l’authentification locale avec un fichier htpasswd, ou bien les droits “None”, etc.), tout en activant les logs Debug (attention, c’est très, très, verbeux).

Configuration du fichier “rights”

Comme nous avons choisi de gérer des droits manuellement, il faut créer le fichier /etc/radicale/rights. Voici le mien :

## Configurations par défaut ##
# Ce sont les options par défaut proposées pour l'authentification.
# Voici ce à quoi elles correspondent exactement.

# "authenticated" #
#[authenticated-rw]
#user:.+
#collection:.*
#permission:rw

# "owner_write" #
#[authenticated-r]
#user:.+
#collection:.*
#permission:r

#[owner-write-w]
#user:.+
#collection:^%(login)s(/.*)?$
#permission:w

# "owner_only" #
[owner-only]
user:.+
collection:^%(login)s(/.*)?$
permission:rw

## Ajouts personnels ##
# Collections publiquement lisibles si elles sont nommées public-abc123
[anon-read-public]
user: .*
collection: ^.+/public-.+$
permission: r

# Collections accessibles en lecture et écriture par les autres utilisateurs
# authentifiés, nommées shared-rw-abc123
[users-read-write-shared]
user: .+
collection: ^.+/shared-rw-.+$
permission: rw

# Collections accessibles en lecture par les autres utilisateurs authenifiés,
# nommées shared-r-abc123
[users-read-shared]
user: .+
collection: ^.+/shared-r-.+$
permission: r

# On peut créer un dossier complet dans lequel toutes les collections seront
# accessibles en lecture, ici le dossier /public/
#[public]
#user: .*
#collection: ^public(/.+)?$
#permission: r

# On peut utiliseur le nom de domaine des utilisateurs pour leur donner des
# accès particuliers
#[domain-wide-access]
#user: ^.+@(.+)\..+$
#collection: ^{0}/.+$
#permission: r

On peut ensuite ajouter des règles spécifiques à un utilisateur ou une collection précis. De plus, l’ordre dans lequel les règles sont créées importe peu.

Personnellement, je me méfie grandement de la possibilité qui serait donnée à un utilisateur anonyme (“.*”) d’écrire quoi que ce soit sur mon serveur, donc je n’active pas cette options.

Configuration du serveur web

Maintenant que Radicale est configuré et lancé, il faut configurer le serveur web, Nginx dans mon cas.

Créons (ou complétons) le fichier /etc/nginx/sites-available/machin.exemple.fr et mettons ceci dedans :

# Dans un premier temps, on redirige tout vers le port 443 sécurisé
server {
    listen  80;
    listen  [::]:80;

    server_name machin.exemple.fr;

    rewrite ^   https://$server_name$request_uri? permanent;
}

# Ensuite, on configure le tout dans la section dédiée au https
server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name machin.exemple.fr;

    root   /var/www/machin.exemple.fr;
    index  index.html index.htm index.php;

    access_log  /var/log/nginx/cloud.arnoux.lu.access.log;  
    error_log /var/log/nginx/cloud.arnoux.lu.error.log;

    ssl_certificate /chemin/vers/certificat-ssl.pem;
    ssl_certificate_key /chemin/vers/cle-privee-ssl.key;

    # On gère les redirections utiles
    location / {
        rewrite ^/.well-known/carddav /radicale/$remote_user/carddav/ redirect;
        rewrite ^/.well-known/caldav /radicale/$remote_user/caldav/ redirect;
    }

    # On "proxifie" les requêtes à destination de /radicale/
    # On ajoute quelques entêtes utiles pour que Radicale ait accès à l'adresse IP réelle du client
    location /radicale {
        proxy_pass http://localhost:5232;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
    }

}

Configuration des DNS

Dans la configuration du serveur web, on a défini les URI “.well-known”, qui facilitent l’auto-configuration de certains clients, et la découverte des collections (calendriers ou carnets d’adresses) existantes.

Dans le cas où le nom d’utilisateur que nous utilisons est une adresse email, il est possible d’activer une étape supplémentaire d’auto-configuration, [grâce à un enregistrement SRV](https://tools.ietf.org/html/rfc6764#section-3].

Pour des adresse email de la forme utilisateur@domaine.com, et un serveur Radical qui se trouve sur l’ordi machin.exemple.fr, ajoutons ces enregistrements dans la zone DNS de domaine.com :

\_caldavs.\_tcp 10800   IN  SRV 0 1 443 machin.exemple.fr.
\_carddavs.\_tcp 10800  IN  SRV 0 1 443 machin.exemple.fr.

Je n’ai volontairement pas mis les enregistrements non sécurisés (_caldav._tcp et _carddav._tcp), puisque je ne veux que des accès sécurisés à mon serveur.

Création des collections

Certains clients, tel que DAVdroid, nécessitent que les collections existent déjà pour pouvoir les utiliser. Il faut donc les créer préalablement à toute utilisation. Comme l’explique ce billet similaire au mien(en), il est possible d’utiliser le programme cadaver, mais dans le cas de Radicale, il y a plus simple : simplement en accédant au calendrier à l’aide d’un navigateur internet.

Dans notre navigateur favori (Firefox, bien évidemment), il suffit d’accéder à la ressource “https://machin.exemple.fr/radicale/user@domaine.com/calendrier.ics/”. Entrez un nom d’utilisateur qui a un droit d’écriture sur cette ressource (user@domaine.com dans notre cas) ainsi que son mot de passe, et vous récupérerez un calendrier vide, qui aura été créé à la volée par Radicale.

Terminez bien l’URL par un “/”. Vous pouvez nommez les calendriers et listes de tâche avec ou sans extension “.ics” (“calendrier.ics”, “todo.ics”, ou bien simplement “calendrier”), mais les carnets d’adresse doivent avoir l’extension “.vcf” (“adressbook.vcf”) afin de ne pas être identifiés comme des calendriers. Cela créera un fichier du même nom dans l’arborescence des collections de Radicale.

Étapes supplémentaires

Intégration à fail2ban

Par sécurité, comme pour tout service ouvert sur l’extérieur et offrant un système d’authentification, il faut surveiller les tentatives ratées d’authentification.

Cela se fait avec fail2ban, mais il faut avoir accès à un fichier de log dans lequel apparait l’adresse IP du client. Par défaut, ce n’est pas possible dans Radicale, mais j’ai trouvé une astuce nécessitant de modifier le logiciel lui-même.

C’est d’ailleurs pour cela que j’ai ajouté l’entête X_Forwarded_For dans la configuration de Nginx. Il faut désormais accéder à cet entête.

Cela se passe dans le fichier /usr/lib/python2.7/dist-packages/radicale/__init__.py. Éditez-le en root, et modifiez la ligne suivante (qui devrait se trouver à la ligne 339) :

log.LOGGER.info("%s refused" % (user or "Anonymous user")

Afin qu’elle ressemble à cela :

log.LOGGER.info("%s refused from host %s" % (user or "Anonymous user", environ.get("HTTP_X_FORWARDED_FOR").split(", ")[0]))

fail2ban pourra désormais accéder à l’adresse IP du client dont l’authentification a échoué, ou auquel un accès a été refusé, via le fichier de log /var/log/radicale/radicale.log. La configuration de fail2ban fera l’objet d’un autre billet.

Suivi du projet

Afin de suivre les évolutions du projet, et de rester vigilant quant aux possibles découvertes de failles de sécurité, abonnez-vous au flux RSS de Radicale, et à la mailing list du projet (envoyez un mail, peu importe son contenu, à cette adresse. Ce premier mail sera supprimé après avoir lancé la procédure d’inscription).

Sources :

https://blogobramje.nl/posts/How_to_run_radicale_behind_nginx/
http://www.rezine.org/documentation/auto-hebergement/services/agenda-contact/serveurs-cal-card/#index3h1
http://www.pihomeserver.fr/2013/08/17/raspberry-pi-home-server-installer-radicale-pour-gerer-vos-contacts-et-calendriers/

Contrôler OpenELEC via HDMI-CEC avec une télécommande Samsung

2015-05-12T00:00:00+02:00

Je possède un media-center sous OpenELEC 5 (Kodi 14), que je viens d’équiper d’un “récepteur” HDMI-CEC de Pulse-Eight. Cela permet beaucoup de souplesse et d’automatisation quant au contrôle, allumage et extinction des appareils, le tout avec une seule télécommande (celle de la télévision). Malgré tout, il y a quelques réglages à faire pour que tout fonctionne comme je veux. Je vais donc détailler tout cela.

Dans un premier temps, je vais rapidement détailler les réglages de contrôle mutuel de mes appareils (allumage et extinction) qui me conviennent. Dans un second temps, je vais configurer OpenELEC pour qu’il exploite au maximum les commandes provenant de la télécommande Samsung.

Articulation de ce billet :

Configuration d’allumage et d’extinction
- Expression des besoins
- Réglages à modifier
Réglage de la télécommande
- Identifier les codes
- Associer chaque touche à une action appropriée

Configuration d’allumage et d’extinction

Selon les équipements, la norme HDMI-CEC (en) permet d’allumer et d’éteindre les différents appareils indépendamment ou automatiquement.

J’ai donc une télévision Samsung UE46ES6710 connecté via un port HDMI (CEC et ARC) à un ampli Marantz NR1403. À cet ampli est aussi connecté, en HDMI, mon media-center OpenELEC.

Premier constat : pour une raison inconnue, ma télévision, ne permet pas d’allumer tous les appareils à partir de sa télécommande (le réglage en question se réinitialise à chaque extinction de la tv). Tant mieux, ce n’est pas ce que je veux faire.

Expression des besoins

Je présente ici mes besoins personnels. Les vôtres peuvent différer. Voici ce que je veux faire :

La télévision est indépendante. Elle s’allume sans allumer le reste des éléments, et elle s’éteint sans les éteindre ;
Par contre, elle est en retour contrôlée par les autres éléments. Quand j’allume le media-center, il allume l’ampli et sélectionne le media-center comme source, puis il allume la télévision (si elle est éteinte), et sélectionne la sortie HDMI vers l’ampli comme source vidéo.
Lorsque je veux écouter de la musique, je peux lancer une playlist, puis éteindre la télévision. La musique continuera d’être jouée sur l’ampli.
Lorsque j’éteins le media-center, cela éteint l’ampli, mais pas la tv. En effet, il m’arrive souvent de couper le media-center et de regarder les infos à la télé, par exemple.

Tout ceci est possible en personnalisant quelques réglages sur chacun des appareils concernés.

Réglages à modifier

Sur la télévision

Dans le Menu>Système>Anynet+ (HDMI-CEC), je met les réglages suivants :

Anynet+ (HDMI-CEC) : Activé (Pour activer la prise en charge générale des contrôles par HDMI-CEC) ;
Arrêt automatique : Non (Pour désactiver l’extinction des autres appareils à l’arrêt de la télévision) ;
Récepteur : Activé (je n’ai pas vu de différence en le désactivant).

Sur l’amplificateur

Dans le SETUP>Vidéo>Config. HDMI, je mets les réglages suivants :

HDMI Contrôle : Marche (Activation générale);
Désactiver cmde : Tous (pour que l’ampli puisse quand même être éteint par le média-center).

Laissez les autres paramètres par défaut.

Sur le media-center

Il faut aller dans le menu Système (Paramètres)>Système>Périphériques>Périphériques. Sélectionnez alors le périphérique nous intéressant. Pour moi il s’appelle “CEC Adapter”. Modifiez alors les options suivantes :

Dispositifs à démarrer au démarrage de Kodi : TV et ampli ;
Éteindre les dispositifs à l’arrêt de Kodi : Ampli ;
Quand la TV est éteinte : Ignorer.

Et voilà, mon système réagit désormais comme je l’entends.

Réglage de la télécommande

On va maintenant chercher à lier chaque pression de bouton sur la télécommande de la télévision à une action précise dans OpenELEC. Pour savoir de quoi on parle, j’ai mis une photo de ma télécommande.

Il existe de nombreux billets et autres discussions qui traitent de ce sujet. Le présent billet ne fait que reprendre toutes ces informations en les réorganisant.

Les concepts sont les suivants :

Quand un récepteur HDMI-CEC est connecté à la TV, celle-ci lui envoie des codes à chaque pression de certains boutons sur la télécommande ;
Certains boutons ne génèrent aucun code HDMI-CEC, ils ne sont gérés que par la TV sans être transmis aux autres appareils ;
Pour chaque télécommande, de chaque marque, il faut déterminer quels sont ces codes, et à quel bouton ils correspondent ;
Une fois que l’on connaît tous les codes de notre télécommande, il faut éditer un fichier de configuration dans Kodi ;
Ce fichier de configuration permet de corriger certaines comportements par défaut qui sont erronés, et d’ajouter des actions, en fonction du contexte. Il existe un fichier de configuration par défaut, mais on en crée un deuxième qui prend le dessus pour les quelques touches que l’on modifie.

On va voir tout ça, étape par étape.

Identifier les codes

Dans un premier temps, il faut identifier les codes qui sont reçus par le media-center à chaque appui de touche. Pour ce faire, on va activer les logs de Kodi, et surveiller les événements à chaque appui de touche.

Activer les logs de Kodi

La gestion des logs de Kodi est expliquée en détail sur le wiki officiel.

On peut les activer dans l’interface (menu SYSTÈME (Paramètres)>Système>Debogage) : activer le mode debug, activer le journal spécifique aux composants, et sélectionner le composant CEC uniquement, pour avoir des logs très détaillés.

On peut aussi les activer dans la console, en se connectant en ssh au media-center, et en éditant un fichier :

vetetix@localhost:~$ ssh root@ip-du-mediacenter
kodi-salon:~ # nano /storage/.kodi/userdata/advancedsettings.xml

Dans ce fichier, ajoutez le loglevel et le debug, entre les balises globales :

<advancedsettings>
  <loglevel>1</loglevel>
  <debug>
    <extralogging>true</extralogging>
    <setextraloglevel>64,2048,32768</setextraloglevel>
    </debug>
</advancedsettings>

Enregistrez le fichier (Ctrl+x), puis redémarrez le media-center.

Lire les codes

Maintenant, reconnectez-vous au media-center, surveillez le fichier de log, et appuyez sur les touches de votre télécommandes :

XBMC-salon:~ # tail -f /storage/.kodi/temp/kodi.log

Voici ce que ça donne pour un appui sur la touche “Exit” :

12:12:24 T:140479907747584   DEBUG: CecLogMessage - >> 01:44:0d
12:12:24 T:140479907747584   DEBUG: CecLogMessage - >> TV (0) -> Recorder 1 (1): user control pressed (44)
12:12:24 T:140479907747584   DEBUG: CecLogMessage - key pressed: exit (d)
12:12:24 T:140479907747584   DEBUG: PushCecKeypress - received key d8 duration 0
12:12:24 T:140480410220416   DEBUG: OnKey: menu (0xd8) pressed, action is Back
12:12:24 T:140480410220416   DEBUG: CGUIWindowManager::PreviousWindow: Deactivate
12:12:24 T:140479907747584   DEBUG: CecLogMessage - >> 01:45
12:12:24 T:140479907747584   DEBUG: CecLogMessage - >> TV (0) -> Recorder 1 (1): user control release (45)
12:12:24 T:140479907747584   DEBUG: CecLogMessage - key released: exit (d)
12:12:24 T:140479907747584   DEBUG: PushCecKeypress - received key d8 duration 344

À la ligne 3, on voit bien que c’est la touche “exit” qui a été utilisée, et à la ligne 5 que ça a engendré l’action “Back”.

À partir de là, une recherche dans le fichier /usr/share/kodi/system/keymaps/remote.xml nous indique que c’est le code bouton “back” qui génère l’action.

On en déduit donc que la touche “Exit” de la télécommande correspond au code bouton “back” de Kodi.

Notons que chaque bouton n’a pas le même comportement (la même “action”) dans tous les contextes. En testant dans un menu, et pendant la lecture d’un film, on aura un résultat différent. Cela permet de différencier certains boutons ayant le même comportement dans un contexte précis.

De cette manière, et en me basant sur le travail de ce blogueur, j’ai édité ce tableau qui correspond à ma télécommande (boutons de gauche à droite, de haut en bas) :

Touche	Transmis	Code
Alim	Non	—
Source	Non	—
HDMI	Non	—
1	Oui	one
2	Oui	two
3	Oui	three
4	Oui	four
5	Oui	five
6	Oui	six
7	Oui	seven
8	Oui	eight
9	Oui	nine
TTX/MIX	Non	—
0	Oui	zero
PRE-CH	Oui	teletext
Vol+	Oui	Non exploitable
MUTE	Oui	Non exploitable
Prog+	Oui	pageplus
Vol-	Oui	Non exploitable
CH LIST	Oui	livetv
Prog-	Oui	pageminus
MENU	Non	—
SMART	Non	—
GUIDE	Oui	guide
TOOLS	Non	—
UP	Oui	up
INFO	Non	—
LEFT	Oui	left
ENTER	Oui	select
RIGHT	Oui	right
RETURN	Oui	title
DOWN	Oui	down
EXIT	Oui	back
A	Oui	red
B	Oui	green
C	Oui	yellow
D	Oui	blue
Family Story	Non	—
SEARCH	Non	—
3D	Non	—
SUPPORT	Non	—
P.SIZE	Non	—
AD/SUBT	Non	—
RW	Oui	reverse
PAUSE	Oui	pause
FF	Oui	forward
REC	Oui	record
PLAY	Oui	play
STOP	Oui	stop

S’il manque une touche

J’ai fait ce travail avec une TV Samsung, mais les TV d’autres constructeurs peuvent envoyer des codes différents. Il faut parfois faire quelques essais pour trouver la correspondance touche/code.

Par exemple, la touche CH LIST pouvait correspondre à livetv ou mytv. J’ai dû modifier l’action liée à ces deux codes pour les différencier et trouver le bon (voir section suivante).

Ce post dans le forum de Kodi explique comment on peut retrouver le code d’à peu près toutes les touches (il mentionne le fichier ButtonTranslator.cpp.

Associer chaque touche à une action appropriée

On va désormais modifier le fichier remote.xml pour le corriger et le personnaliser. Il ne faut pas toucher au fichier initial, mais en créer un second dans le dossier .kodi/userdata/keymaps/, dont le contenu complétera celui du premier, tout en ayant priorité dessus.

On peut en créer un vierge, mais je préfère partir d’un fichier complet et virer ce qui ne m’est pas utile. Cela permet de voir ce qui est configuré par défaut, de le corriger, et de découvrir certaines actions utiles mais liées à un bouton non exploité.

XBMC-salon:~ # cp /usr/share/kodi/system/keymaps/remote.xml /storage/.kodi/userdata/keymaps/remote.xml

Maintenant, il ne reste plus qu’à éditer le fichier, soit en ligne de commande avec nano, soit avec un éditeur “graphique” en allant le chercher via l’accès samba (chez moi ça se trouve à l’adresse “smb://kodi-salon/userdata/keymaps”).

La chose la plus problématique est le fait que le bouton “Exit” (code “back”) joue le rôle du bouton “Back” (code “title”), et que celui-ci ouvre un menu contextuel. Dans un premier temps, je dois donc systématiquement commenter les actions de “title” et remplacer <back>Action</back> par <title>Action</title>.

Ensuite, il ne reste plus qu’à étudier la configuration existante, et à modifier ou ajouter des règles. On connait les codes, et les actions disponibles sont listées ici.

Personnellement, j’ai voulu configurer les actions suivantes :

Un lien pour montrer le panneau des favoris (ActivateWindow(Favourites)) ;
Un lien vers la sélection (grâce à une playlist) des films et séries en français (ActivateWindow(VideoLibrary,special://profile/playlists/video/FR.xsp)) ;
Un lien pour lancer le “Party Mode” (PlayerControl(PartyMode))
En lecture, des liens rapides pour chercher les sous-titres (ActivateWindow(SubtitleSearch)), passer de l’un à l’autre (NextSubtitle), ou la même chose pour la langue de l’audio (AudioNextLanguage).

Le fichier complet est disponible ici. Regardez-le pour le comprendre en détails. Pour chaque section du fichier, qui correspond à un environnement dans l’interface de Kodi, il faut configurer chaque touche (ou les laisser par défaut, ce qui est souvent suffisant). Internet regorge d’autres exemples, je vous laisse les trouver (le canard est ton ami).

Redémarrez, et profitez de votre télécommande, confortablement installés dans votre canapé.

Ressources :

Acheter le récepteur HDMI-CEC sur mediahd.fr (c’est le moins cher que j’ai trouvé).

Sécuriser l’accès SSH d’OpenELEC

2015-05-02T00:00:00+02:00

Si comme moi vous êtes l’heureux possesseur d’un media center sous OpenELEC, vous êtes peut-être restés perplexes devant le fait que le mot de passe root du système ne peut pas être modifié. Ainsi, toute personne ayant accès à votre réseau local et connaissant l’adresse IP de votre media center peut s’y connecter en root.

Voyons ensemble comment sécuriser cela au mieux : Comme on ne peut pas modifier le mot de passe, on va activer l’authenification par clé SSH puis désactiver l’authentification par mot de passe.

Les premières étapes sont expliquées en détail sur ce billet de blog (en)

Créer une clé d’authentification

Si on n’a pas encore de clé SSH, il faut utiliser la commande ssh-keygen, pour en générer une :

vetetix@localhost:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/vetetix/.ssh/id_rsa): [Entrer]
Created directory '/home/vetetix/.ssh'.
Enter passphrase (empty for no passphrase): "password" [Entrer]
Enter same passphrase again: "password" [Entrer]
Your identification has been saved in /home/vetetix/.ssh/id_rsa.
Your public key has been saved in /home/vetetix/.ssh/id_rsa.pub.
The key fingerprint is:
a8:27:5f:26:60:45:aa:8a:93:55:dd:6e:9a:89:34:d5 vetetix@localhost
The key's randomart image is:
+---[RSA 2048]----+
|      .          |
|     + o         |
|    o + E        |
|   o o o         |
|  o = . S        |
|.+ o = =         |
|=   + * o        |
| .   + +         |
|      .          |
+-----------------+

Copier cette clé sur le media center

On copie ensuite cette clé sur le serveur, à l’aide de l’utilitaire ssh-copy-id. Elle va se mettre dans le fichier .ssh/authorized_keys d’OpenELEC.

Récupérons l’adresse IP du media center (Dans SYSTÈME>Informations système par exemple). Dans la commande ci-dessous, il faut remplacer ip-du-mediacenter par cette adresse IP.

vetetix@localhost:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub root@ip-du-mediacenter
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@kodi-salon's password: [Openelec - Entrer]

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'root@id-du-mediacenter'"
and check to make sure that only the key(s) you wanted were added.

Vérifions que la clé a bien été activée :

vetetix@localhost:~$ ssh root@ip-du-mediacenter

Le shell devrait nous connecter sans demander de mot de passe (ou éventuellement celui de la clé SSH qu’on vient de créer.

Désactiver l’accès SSH par mot de passe

Une fois toutes les étapes précédentes réalisées, on peut sereinement désactiver l’accès SSH par mot de passe, dans l’interface de OpenELEC.

Cela se passe dans le menu SYSTÈME (OpenELEC)>Services. Il faut cocher l’option “Désactiver le mot de passe SSH”.

L’accès au media center est désormais sécurisé. On ne peut s’y connecter que si l’on possède la partie privée de la clé SSH configurée dans le fichier authorized_keys.

Renouvellement de ma clé PGP

2015-04-28T00:00:00+02:00

J’ai décidé de renouveller ma clé pgp, qui commence à être un peu ancienne. En effet, ma toute première clé PGP date de 2007, et je l’ai remplacée en 2008. Ma clé PGP actuelle a donc 6 ans, et les algorithmes qu’elle utilise sont vieillissants (avec par exemple l’utilisation de clés 1024 bits alors qu’aujourd’hui on conseille l’utilisation de 4096 bits).

Je me suis un peu documenté, et j’écris désormais ce billet pour me souvenir de mes recherches. Je me suis basé sur un tutoriel de Stéphane Bortzmeyer, qui se base lui-même sur un article de référence d’Alex Cabal (en) et le guide du projet Debian (en), ainsi qu’une section sur les sous-clés.

Je vais essayer de faire un guide complet. Voici les différentes étapes que je vais détailler :

Création d’une clé PGP
Remplacement des anciennes clés par la nouvelle
Bonnes pratiques de sécurité et de sauvegarde
Usage et exemples particuliers

Création d’une clé PGP

Configuration des options par défaut de gnupg

Dans un premier temps, on va lancer gpg une première fois, afin d’initialiser les fichiers de configuration :

gpg --list-key

Ensuite, on modifie le fichier ~/.gnupg/gpg.conf et on rajoute ceci à la fin :

### Modifications personnelles ###
# Crypto preferences
personal-digest-preferences SHA256

# For the keys we create
cert-digest-algo SHA256

# For the signatures and other things we generate
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES ZLIB BZIP2 ZIP Uncompressed

Création d’une nouvelle clé PGP

On peut désormais passer à la génération de la nouvelle clé PGP, qui aura les bonnes options par défaut :

$ gpg --gen-key
[…]
Sélectionnez le type de clef désiré :
   (1) RSA et RSA (par défaut)
   (2) DSA et Elgamal
   (3) DSA (signature seule)
   (4) RSA (signature seule)
Quel est votre choix ? 1
les clefs RSA peuvent faire entre 1024 et 4096 bits de longueur.
Quelle taille de clef désirez-vous ? (2048) 4096
La taille demandée est 4096 bits
Veuillez indiquer le temps pendant lequel cette clef devrait être valable.
         0 = la clef n'expire pas
      <n>  = la clef expire dans n jours
      <n>w = la clef expire dans n semaines
      <n>m = la clef expire dans n mois
      <n>y = la clef expire dans n ans
Pendant combien de temps la clef est-elle valable ? (0) 2y
La clef expire le sam. 09 septembre 2016 21:36:51 CEST
Est-ce correct ? (o/N) o

Une identité est nécessaire à la clef ; le programme la construit à partir
du nom réel, d'un commentaire et d'une adresse électronique de cette façon :
   « Heinrich Heine (le poète) <heinrichh@duesseldorf.de> »

Nom réel : Jean Dupont
Adresse électronique : thomas@exemple.net
Commentaire : Main ID
Vous avez sélectionné cette identité :
    « Jean Dupont (Main ID) <thomas@exemple.net> »

Faut-il modifier le (N)om, le (C)ommentaire, l'(A)dresse électronique
ou (O)ui/(Q)uitter ? O
Une phrase de passe est nécessaire pour protéger votre clef secrète.

[…]

gpg: clef 4EA58FE3 marquée de confiance ultime.
les clefs publique et secrète ont été créées et signées.

gpg: vérification de la base de confiance
gpg: 3 marginale(s) nécessaire(s), 1 complète(s) nécessaire(s),
     modèle de confiance PGP
gpg: profondeur : 0  valables :   1  signées :   0
     confiance : 0 i., 0 n.d., 0 j., 0 m., 0 t., 1 u.
gpg: la prochaine vérification de la base de confiance aura lieu le 2016-09-09
pub   4096R/4EA58FE3 2014-09-10 [expire : 2016-09-09]
      Empreinte de la clef = AE08 AB5C D9E8 4C9D 1D8C  E78D 4FE7 0F12 4EA5 8FE3
uid                  Jean Dupont (Main ID) <thomas@exemple.net>
sub   4096R/87EAB420 2014-09-10 [expire : 2016-09-09]

Notre clé PGP est désormais utilisable, mais on va paufiner quelques détails qui n’en sont pas.

Création d’une sous-clé de signature supplémentaire

On va créer une sous-clé de signature, qui sera utilisée au quotidien, sur l’ordinateur portable, voire sur le téléphone portable, pendant que la clé de signature initiale sera bien en sécurité.

$ gpg --edit-key 4EA58FE3 
gpg (GnuPG) 1.4.16; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

La clef secrète est disponible.

pub  4096R/4EA58FE3  créé : 2014-09-10  expire : 2016-09-09  utilisation : SC  
                     confiance : ultime        validité : ultime
sub  4096R/87EAB420  créé : 2014-09-10  expire : 2016-09-09  utilisation : E   
[  ultime ] (1). Jean Dupont (Main ID) <thomas@exemple.net>

gpg> addkey 
La clef est protégée.

Une phrase de passe est nécessaire pour déverrouiller la clef secrète de
l'utilisateur : « Jean Dupont (Main ID) <thomas@exemple.net> »
clef RSA de 4096 bits, identifiant 4EA58FE3, créée le 2014-09-10

Sélectionnez le type de clef désiré :
   (3) DSA (signature seule)
   (4) RSA (signature seule)
   (5) Elgamal (chiffrement seul)
   (6) RSA (chiffrement seul)
Quel est votre choix ? 4
les clefs RSA peuvent faire entre 1024 et 4096 bits de longueur.
Quelle taille de clef désirez-vous ? (2048) 4096
La taille demandée est 4096 bits
Veuillez indiquer le temps pendant lequel cette clef devrait être valable.
         0 = la clef n'expire pas
      <n>  = la clef expire dans n jours
      <n>w = la clef expire dans n semaines
      <n>m = la clef expire dans n mois
      <n>y = la clef expire dans n ans
Pendant combien de temps la clef est-elle valable ? (0) 2y
La clef expire le dim. 07 août 2016 13:44:34 CEST
Est-ce correct ? (o/N) o
Faut-il vraiment la créer ? (o/N) o

[…]

pub  4096R/4EA58FE3  créé : 2014-09-10  expire : 2016-09-09  utilisation : SC  
                     confiance : ultime        validité : ultime
sub  4096R/87EAB420  créé : 2014-09-10  expire : 2016-09-09  utilisation : E   
sub  4096R/E8DC29F1  créé : 2014-09-11  expire : 2016-09-10  utilisation : S   
[  ultime ] (1). Jean Dupont (Main ID) <thomas@exemple.net>

Ajout d’autres UID (adresses courriel et identité)

On peut désormais ajouter d’autres uid (User ID), correspondant à d’autres adresses email, xmpp ou autres. Toujours dans la même “session” gpg :

gpg> adduid
Nom réel : Jean Dupont
Adresse électronique : vetetix@domaine.fr
Commentaire : 
Vous avez sélectionné cette identité :
    « Jean Dupont <vetetix@domaine.fr> »

Faut-il modifier le (N)om, le (C)ommentaire, l'(A)dresse électronique
ou (O)ui/(Q)uitter ? o

Une phrase de passe est nécessaire pour déverrouiller la clef secrète de
l'utilisateur : « Jean Dupont (Main ID) <thomas@exemple.net> »
clef RSA de 4096 bits, identifiant 4EA58FE3, créée le 2014-09-10


pub  4096R/4EA58FE3  créé : 2014-09-10  expire : 2016-09-09  utilisation : SC  
                     confiance : ultime        validité : ultime
sub  4096R/87EAB420  créé : 2014-09-10  expire : 2016-09-09  utilisation : E   
sub  4096R/E8DC29F1  créé : 2014-09-11  expire : 2016-09-10  utilisation : S   
[  ultime ] (1)  Jean Dupont (Main ID) <thomas@exemple.net>
[ inconnue] (2). Jean Dupont <vetetix@domaine.fr>

Et n’oublions pas, pour quitter la “session” gpg, de sauvegarder proprement nos changements :

gpg> save

Remplacement des anciennes clés par la nouvelle

Maintenant qu’on a une clé PGP définitivement fonctionnelle, occupons-nous de remplacer l’ancienne clé par cette dernière.

Signature de la nouvelle clé par l’ancienne clé

Si comme moi vous avez déjà une clé PGP, la première étape est d’officialiser la nouvelle clé en la signant avec l’ancienne (mon ancienne clé a pour empreinte 078AF6AD, et la nouvelle 4EA58FE3) :

$ gpg --default-key 078AF6AD --sign-key 4EA58FE3

pub  4096R/4EA58FE3  créé : 2014-09-10  expire : 2016-09-09  utilisation : SC  
                     confiance : ultime        validité : ultime
sub  4096R/87EAB420  créé : 2014-09-10  expire : 2016-09-09  utilisation : E   
sub  4096R/E8DC29F1  créé : 2014-09-11  expire : 2016-09-10  utilisation : S   
[  ultime ] (1). Jean Dupont <vetetix@domaine.fr>
[  ultime ] (2)  Jean Dupont (Main ID) <thomas@exemple.net>

Voulez-vous vraiment signer toutes les identités ? (o/N) o

pub  4096R/4EA58FE3  créé : 2014-09-10  expire : 2016-09-09  utilisation : SC  
                     confiance : ultime        validité : ultime
 Empreinte clef princip. : AE08 AB5C D9E8 4C9D 1D8C  E78D 4FE7 0F12 4EA5 8FE3

     Jean Dupont <vetetix@domaine.fr>
     Jean Dupont (Main ID) <thomas@exemple.net>

Cette clef va expirer le 2016-09-09.
Voulez-vous vraiment signer cette clef avec votre
clef « Jean Dupont <thomas@exemple.net> » (078AF6AD)

Voulez-vous vraiment signer ? (o/N) o
[…]

Publication de la nouvelle clé

Votre nouvelle clé est désormais prête à être publiée sur un serveur de clés :

$ gpg --send-keys 4EA58FE3
gpg: envoi de la clef 4EA58FE3 au serveur hkp keys.gnupg.net

Les différents serveurs de clés se synchronisent entre eux automatiquement et assez rapidement, donc il n’est pas nécessaire d’envoyer votre clé sur d’autres serveurs (pgp.mit.edu, keyserver.ubuntu.com, etc.)

Révocation de l’ancienne clé

On n’a désormais plus besoin de l’ancienne clé, qui est devenue obsolète. On va donc la révoquer, en choisissant l’option 2 (clé remplacée), et en indiquant dans le commentaire l’ID de la nouvelle clé :

$ gpg --gen-revoke 078AF6AD > revcert.txt

sec  1024D/078AF6AD 2008-11-20 Jean Dupont <thomas@exemple.net>

Faut-il créer un certificat de révocation pour cette clef ? (o/N) o
choisissez la cause de la révocation :
  0 = Aucune raison indiquée
  1 = La clef a été compromise
  2 = La clef a été remplacée
  3 = La clef n'est plus utilisée
  Q = Annuler
(Vous devriez sûrement sélectionner 1 ici)
Quelle est votre décision ? 2
Entrez une description facultative, en terminant par une ligne vide :
> New key ID 4EA58FE3 thomas@exemple.net
> 
Cause de révocation : La clef a été remplacée
New key ID 4EA58FE3 thomas@exemple.net
Est-ce d'accord ? (o/N) o
[…]

$ gpg --import revcert.txt 
[…]

$ gpg --send-keys 078AF6AD
[…]

Bonnes pratiques de sécurité et de sauvegarde

On a créé une nouvelle clé PGP, et on a révoqué l’ancienne clé, mais il reste quelques petites choses à faire.

Création du certificat de révocation de la nouvelle clé

Dans un premier temps, on va créer un certificat de révocation pour la nouvelle clé, que l’on stockera par la suite sur un support sécurisé. Il sera utile si on se fait voler la clé privée, ou si on la perd.

Ce certificat, publié sur un serveur de clés, permettra à lui-seul d’annoncer à tous nos contacts que la clé ne doit plus être utilisée.

En premier lieu, on modifie le umask pour éviter que les fichiers générés soient lisibles par un autre utilisateur :

$ umask 177
$ gpg --gen-revoke 4EA58FE3 > 4EA58FE3.revocation.asc

Export, stockage et sauvegarde de la clé complète (avec une version papier)

On va désormais “archiver” notre clé complète, et la stocker en un lieu sûr.

Sauvegarde sur une clé USB

Dans un premier temps, on va sauvegarder la clé complète, en exportant d’abord sa partie privée, puis sa partie publique :

$ umask 177
$ gpg --export-secret-keys --armor 4EA58FE3 > 4EA58FE3.private.asc
$ gpg --export --armor 4EA58FE3 > 4EA58FE3.public.asc

La clé “privée” ainsi créée est la plus importante. Elle contient la totalité de votre clé GPG. Elle peut être ré-importée dans un système vierge si vous avez perdu l’originale.

La clé “publique” est celle que vous donnez à vos correspondants. Elle peut être recréée à partir de la clé “privée”.

Le certificat de révocation peut aussi être recréé à partir de la clé “privée”. Il ne doit absolument pas être publié. Toute personne mettant la main dessus peut révoquer définitivement votre clé GPG sans votre consentement.

Il ne vous reste plus qu’à stocker ces trois fichiers, sur une clé USB ou un disque dur chiffré (je conseille l’utilisation de cryptsetup/LUKS, le plus simplement du monde en utilisant l’outil graphique “Disques” sous Ubuntu)

Sauvegarde sur un support papier

Il est possible de créer une sauvegarde de dernier recours, en version papier, de votre clé PGP. Le détail des opérations se trouve sur ce billet de Schnouki.

Le principe est simple :

Vous utilisez un utilitaire pour réduire la taille de la clé en en supprimant les informations inutiles ;
Le fichier résultant étant toujours trop volumineux, vous le découpez en plusieurs fichiers plus petits ;
Vous encodez ces fichiers pour créer des codes barre 2D imprimables ;
Vous imprimez ces codes 2D, chacun sur une feuille A4.

Et voilà, vous avez une copie de sauvegarde sur papier de votre clé. Pour la récupérer en cas de besoin :

Vous scannez chacun des codes 2D à partir de la version imprimée ;
Vous décodez ces codes scannés, ce qui vous donne les bouts de fichiers initiaux ;
Vous recollez les bouts ensemble, pour recréer la clé PGP complète.

Ce n’est pas plus compliqué que cela.

Installation du dossier de travail .gnupg

Sous Linux l’ensemble des données se trouvent par défaut dans le dossier .gnupg qui se trouve à la racine de votre répertoire personnel.

Sur clé USB (différente de la clé de sauvegarde mentionnée précédemment), dont on se servira à chaque fois qu’on aura besoin de la clé PGP complète (avec sa partie privée), on va placer une copie de ce répertoire .gnupg. Vous pouvez suivre ce tutoriel un peu complexe utilisant cryptsetup et dm-crypt (en), mais personnellement je ne m’embarrasse pas de cela. Je copie juste mon dossier .gnupg à la racine de la clé USB, que j’ai préalablement chiffrée avec LUKS :

$ cp -r $HOME/.gnupg/ /media/vetetix/cle-usb/gnupg

Ce dossier gnupg contient donc votre clé PGP complète.

Un dernier rappel avant de passer à la suite :

Vous ne devez pas perdre votre clé privée (toujours en avoir une copie quelque part) ;
Même si elle n’est utilisable qu’avec un mot de passe, personne d’autre que vous ne doit y avoir accès ;
Absolument personne ne doit avoir accès à votre certificat de révocation.

Création d’une version partielle de la nouvelle clé

Souvenez-vous, on a ajouté une sous-clé de signature supplémentaire. On va maintenant garder une clé amputée de sa principale sous-clé privée de signature pour notre usage quotidien, en supprimant cette dernière (dont on a fait une sauvegarde sur une clé USB).

Dans un premier temps, exportez les sous-clés privées :

$ umask 177
$ gpg --export-secret-subkeys 4EA58FE3 > subkeys

Ensuite, on supprime la clé privée principale (répondez par l’affirmative aux questions et avertissements) :

$ gpg --delete-secret-key 4EA58FE3
[…]
sec  4096R/4EA58FE3 2014-09-10 Jean Dupont (Main ID) <thomas@exemple.net>

Faut-il supprimer cette clef du porte-clefs ? (o/N) o
C'est une clef secrète — faut-il vraiment la supprimer ? (o/N) o

Réimportez maintenant les sous-clés, et supprimez le fichier temporaire :
```
$ gpg --import subkeys
$ shred --remove subkeys
```

Vérifiez que tout s’est bien passé (votre clé est listée avec un # devant sa clé secrète, indiquant qu’elle est absente) :

$ gpg -K
/home/vetetix/.gnupg/secring.gpg

sec#  4096R/4EA58FE3 2014-09-10 [expire : 2016-09-09]
uid                  Jean Dupont (Main ID) <thomas@exemple.net>
uid                  Jean Dupont <vetetix@domaine.fr>
ssb   4096R/87EAB420 2014-09-10
ssb   4096R/E8DC29F1 2014-09-11

Précisons que l’option “-K” est un raccourcis pour “—list-secret-keys”.

« Et voilà ! », comme diraient nos amis anglophones. La clé que vous utilisez au quotidien, sur votre ordinateur portable, ne dispose plus de votre clé privée, celle-ci étant en sécurité sur une clé USB.

Usage et exemples particuliers

Maintenant qu’on a placé la partie privée de la clé PGP sur une clé USB, il faut savoir comment l’utiliser concrètement.

Montage de la clé

Commençons par monter la clé USB contenant notre clé GPG complète. Dans notre exemple elle se monte dans /media/vetetix/usb-key.

On peut alors travailler avec en utilisant l’option --home de gnupg, que l’on pointe sur le répertoire de travail contenu sur la clé :

$  gpg --home=/media/vetetix/usb-key/gnupg -K
/media/vetetix/usb-key/gnupg/secring.gpg
---------------------------------------
sec   4096R/4EA58FE3 2014-09-10 [expire : 2016-09-09]
uid                  Jean Dupont (Main ID) <thomas@exemple.net>
uid                  Jean Dupont <vetetix@domaine.fr>
ssb   4096R/87EAB420 2014-09-10
ssb   4096R/E8DC29F1 2014-09-11

On constate que la clé secrète n’est pas suivie d’un #. Elle est donc présente.

Prolongation de la validité de la clé

En créant ma clé, j’ai mis une durée de validité de deux ans. Pour prolonger cette validité, il suffit d’utiliser la commande expire de gpg, et à nouveau de choisir “2y”, ou toute autre durée :

$ gpg --home=/media/vetetix/usb-key/gnupg --edit-key 4EA58FE3
[…]
gpg> expire
[…]
gpg> save
$ gpg --home=/media/vetetix/usb-key/gnupg --send-keys 4EA58FE3

Signatures d’autres clés

Pour signer une autre clé, on va récupérer la clé en question (à partir de son ID dans notre exemple) :

$ gpg --home=/media/vetetix/usb-key/gnupg --recv-keys ABCD1234

Ensuite on la signe, et on exporte la signature dans un format lisible (option --armor) :

$ gpg --home=/media/vetetix/usb-key/gnupg --sign-key ABCD1234
$ gpg --home=/media/vetetix/usb-key/gnupg --armor --output ABCD1234.signed-by.4EA58FE3.asc --export ABCD1234

Maintenant qu’on a signé la clé publique de la personne, on n’uploade pas la signature soi-même. La personne dont on a vérifié l’identité peut très bien avoir menti sur l’adresse email ou xmpp qu’il a montrée. Pour éviter tout problème, on envoie la signature par email ou xmpp au titulaire de l’adresse, en chiffrant le message avec la clé publique qu’on vient de signer.

Le récipiendaire du message sera ainsi le titulaire de l’adresse email, et de la clé qu’on vient de signer. Il déchiffrera le message, importera la signature dans son trousseau GnuPG, et l’uploadera lui-même sur un serveur de clé.

Révocation d’une sous-clé

En cas de souci (vol de la clé, ou autre désastre), on peut avoir besoin de révoquer la sous-clé de signature de notre clé. Avantage de notre système de sous-clé additionnelle : la clé principale n’a pas à être révoquée, elle reste donc en service et on ne perd pas le bénéfice du Web of Trust existant.

Pour générer le certificat de révocation de la sous-clé, il faut avoir accès à la clé de signature principale, donc il faut utiliser la clé USB :

$ gpg --home=/media/vetetix/usb-key/gnupg --edit-key 4EA58FE3
gpg> list # Pour voir le détail des sous-clés et identités
[…]
gpg> key 2 # Pour sélectionner la deuxième sous-clé, compromise
[…]
gpg> revkey # Pour générer le certificat de révocation de la sous-clé sélectionnée
gpg> save

Il faut désormais recréer une sous-clé de signature, tel qu’expliqué précédemment, et republier notre clé modifiée avec la commande gpg --send-keys ID (puis recréer une version amputée de la clé en vue de son utilisation quotidienne).

Il ne reste plus qu’à vos correspondants de mettre à jour leur version de votre clé publique via gpg --recv-keys ID

Note : Il semble déconseillé de supprimer les sous-clés et identités corrompues, car de toute façon, elles ne disparaitraient pas sur les serveurs de clé, ou dans notre clé publique chez nos correspondants.

Révocation définitive de la clé

Si la clé a été définitivement compromise, ou qu’après plusieurs années de bons et loyaux service on la remplace pour utiliser des algorithmes plus robustes, on peut la révoquer.

Cela peut se faire à partir du certificat de révocation créé préalablement :

$ gpg --import 4EA58FE3.revocation.asc
$ gpg --send-keys 4EA58FE3

La clé est désormais inutilisable :-( Paix à son âme.

Si on n’a pas prévu de certificat de révocation, on peut en créez un à partir de la clé privée complète. Si en plus on a perdu la clé privée complète, on ne pourra jamais la révoquer.

Autres ressources

Installer Gajim sur Ubuntu

2015-04-27T00:00:00+02:00

Quand on veut exploiter à fond son serveur XMPP, en particulier ses fonctionnalités avancées, il faut installer un “vrai” client. On ne peut pas se contenter d’Empathy, il faut passer à Gajim.

L’installation propre et complète de Gajim sur Ubuntu n’est malheureusement pas complètement triviale. Voici ce que j’ai fait pour avoir un logiciel complet.

Installation de Gajim

Tout d’abord, on va installer la version présente dans les dépôts officiels d’Ubuntu (le ppa n’a pas été mis à jour depuis des années, tout comme la version pip, et je n’ai pas envie de l’installer via les sources) :

sudo apt-get install gajim

Activation des fonctionnalités supplémentaires

Ensuite, on va installer les paquets suivants, pour activer certaines fonctionnalités supplémentaires. Toutes ces fonctionnalités sont détaillées, ainsi que les paquets nécessaires, dans le menu ‘Aide>Fonctionnalités’ :

Regardez quelles fonctionnalités non activées vous intéressent, et installez leurs dépendances. Pour moi ça donne ça :

sudo aptitude install python-farstream libgstreamer-plugins-bad1.0-0 python-avahi gnome-keyring python-gnomekeyring python-gnome2 python-gupnp-igd libgtkspell0 python-docutils

Installation de plugins

Depuis quelques temps, Gajim supporte les plugins, qui peuvent être installés via l’interface dédiée. Certains plugins ont des dépendances à satisfaire avant de fonctionner.

Par exemple, pour intégrer Gajim à l’App Indicator d’Ubuntu, il faut activer le plugin Appindicator integration, puis installer le paquet python-appindicator par aptitude. Je n’ai pas encore trouvé comment intégrer proprement Gajim au menu “messaging”, ça nécessitera peut-être de développer un autre plugin…

Intégration au navigateur

Il peut être utile que les URI XMPP cliquables du type xmpp:gajim@conference.gajim.org?join s’ouvrent dans Gajim.

Pour ce faire, dans un premier temps ouvrez le about:config de Firefox, et créez une nouvelle entrée booléenne nommée “network.protocol-handler.expose.xmpp” avec pour valeur “false”.

Ensuite ouvrez “l’éditeur de configuration avancée” dans les préferences de Gajim (onglet “Avancées”). Cherchez le paramètre “remote_control” et activez-le. Cela permettra le contrôle de Gajim par l’utilitaire gajim-remote.

Cliquez maintenant sur une URI XMPP (par exemple dans la doc de Gajim, et associez ce type d’URI à gajim-remote (que l’on trouve dans /usr/bin/gajim-remote).

Plus de documentation :

Le wiki officiel de gajim

Qu’y a-t-il derrière les noms de domaine de premier niveau ?

2015-02-07T00:00:00+01:00

En faisant quelques essais avec YUNohost, j’ai trouvé dans la documentation du projet un lien vers une conférence par Stéphane Bortzmeyer expliquant le fonctionnement global du DNS.

On sait tous que “wikipedia.org” renvoit vers la page d’accueil de l’encyclopédie, et “fr.wikipedia.org” renvoit vers sa version française. Je me suis alors demandé vers quoi renvoyaient les noms de domaine de premier niveau : si on veut aller sur “org”, ou sur “com”, que va-t-il se passer ?

Premier constat : si on rentre simplement “org” dans la barre d’URL de notre navigateur (Firefox dans mon cas), ça fait une recherche du mot clé “org” sur le moteur de recherche par défaut. J’ai alors tenté “org.”, en incluant donc le point final, représentant la racine de l’arborescence DNS. Ça ne fonctionne pas non plus, ça recherche “org.” sur DuckDuckGo.

J’ai alors pensé à inclure le protocole dans la barre d’url : “http://org”. Ça ne fonctionne toujours pas Firefox me renvoyant vers le site “http://www.org.com”. C’est encore pire, parce que les sites renvoyés de cette manière ont visiblement mauvaise réputation sur WOT.

La solution : entrer “http://org.”, avec le point final.

Cela nous donne finalement cela, souvent après plusieurs redirections :

org (http://org.) : http://www.w3.org/
fr : https://www.afnic.fr/
com : http://www.www.com/ (visiblement du grand WTF)
net : Ne semble pas fonctionner
lu : http://www.luxembourg.public.lu/fr/index.html
es : Ne semble pas fonctionner
info : http://www.info./ (ou tout simplement http://www.info)
uk : Ne semble pas fonctionner
co.uk : Ne semble pas fonctionner non plus

Enfin, “http://.” n’est pas interprêté correctement par Firefox. C’est normal, “.” n’est pas un nom de domain, c’est juste la racine.

Je vous laisse vous amuser avec d’autres recherches. Si vous trouvez des exemples intéressants, n’hésitez pas à les partager (en commentaire, si j’installe le plugin sur ce blog).

La Quadrature du Net a besoin de nous

2014-12-19T00:00:00+01:00

La Quadrature du Net, association de défense de l’internet libre, qui s’oppose régulièrement aux nombreux projets de loi nationaux ou internationaux s’attaquant à l’internet, a urgemment besoin de fonds.

Elle fait régulièrement des campagnes de dons, mais il semblerait qu’en ce moment, les donateurs sont très peu nombreux. Il se trouve que par hasard, j’ai fait un petit don il y a trois jours, mais c’est une goutte d’eau face à leurs besoins financiers.

Un billet de Korben publié aujourd’hui m’indique que la situation est critique, alors rendez-vous sur la page de soutien de La Quadrature du Net, munissez-vous de votre carte bancaire, et donnez ne serait-ce que 10 ou 20€, soit le prix d’un McDo. Les petits torrents font les grandes rivières, donc tout don compte.

Pour être franc, j’aurais les boules qu’une association comme LQDN ferme se portes quelques semaines seulement après que je leur ai fait un don pour la première fois, mais les enjeux vont au delà de mon amour-propre, alors soyons généreux.

Régler un problème de mise à jour Spamassassin

2014-12-07T00:00:00+01:00

Si comme moi, vous avez installé votre propre serveur mail, et que vous gérez la détection des courriers indésirables avec spamassassin, vous avez peut-être recontré l’erreur suivante dans les logs de votre cron.daily :

/etc/cron.daily/spamassassin:
error: unable to refresh mirrors file for channel updates.spamassassin.org, using old file
channel: could not find working mirror, channel failed
sa-update failed for unknown reasons

J’ai eu cette erreur pendant plusieurs semaines, sans réussir à la corriger, ça me rendait fou (et ça empêchait la base de spamassassin de se mettre à jour, ce qui n’est pas négligeable).

J’ai enfin trouvé le problème : Il faut que la commande sa-update soit lancée avec l’utilisateur auquel appartiennent les fichiers contenus dans /var/lib/spamassassin/.

Le problème apparait donc soit quand vous lancez la commande manuellement (forcément en root, ou avec sudo), les fichiers sont alors attribués à l’utilisateur root, et les mises à jour suivantes échouent, soit parce que le script cron lancé quotidiennement n’est pas configuré correctement.

Selon les tutoriels et documentations que vous aurez lus, l’utilisateur est spamd, debian-spamd, ou spamassassin. Dans mon cas, j’ai décidé de rester avec spamd, le plus simplement du monde. Le script se lançait par contre avec debian-spamd, générant ainsi une erreur. J’ai donc lancé les commandes suivantes :

sudo chown -R spamd:spamd /var/lib/spamassassin
sudo sed -i 's/debian-spamd/spamd/g' /etc/cron.daily/spamassassin

Et voilà, plus d’erreurs, et ma base spamassassin est à jour.

Sécuriser son serveur : le pare-feu

2014-12-07T00:00:00+01:00

Une des premières chose à faire pour sécuriser son serveur est d’empêcher les méchants pirates d’y accéder à distance par des portes grandes ouvertes. On va donc installer un pare-feu.

Par défaut, aucun pare-feu n’est activé sur notre serveur (on peut par exemple vérifier que iptables est désactivé en listant les règles actives : iptables -L pour IPv4, et ip6tables -L pour IPv6). Il est important de fermer tous les ports entrants, et de n’ouvrir que ceux strictement nécessaires.

Le choix du logiciel

Pour mon serveur, j’ai choisi d’utiliser le bien nommé ufw (Uncomplicated FireWall), après avoir eu quelques déconvenues dans l’utilisation de iptables, que je trouve très compliqué à prendre en main. Tout comme ce dernier, ufw est désactivé par défaut, mais Une fois activé, il se lancera à chaque redémarrage du serveur en réactivant les règles existantes. Pas besoin de gérer manuellement des scripts d’activation/désactivation au démarrage des interfaces réseau, ou de maintenir deux versions, pour IPv4 et IPv6. ufw est plus ou moins une surcouche à iptables qui permet d’automatiser tout cela.

De plus, pour une utilisation “simple” du pare-feu (une seule interface réseau, simplement bloquée en INPUT par défaut, etc.), je n’atteindrai jamais les limites de ufw par rapport à iptables.

Comme je me connecte à mon serveur en SSH, la première chose à faire avant d’activer ufw est d’autoriser le protocole en question. La syntaxe est assez souple et complète, et peut se montrer complexe (mais pas autant que celle de iptables), mais dans le cas présent, c’est plutôt simple.

Il est possible d’utiliser au choix une des commandes suivantes :

sudo ufw allow 22/tcp # choix totalement manuel du port 22 et du protocole tcp

sudo ufw allow ssh/tcp # utilisation du fichier /etc/services et du protocole tcp

sudo ufw allow app OpenSSH # utilisation du profil d'application de ufw

Ensuite, il ne reste plus qu’à activer ufw :

sudo ufw enable

La documentation la plus complète que j’ai trouvée en dehors du manuel officiel, est celle du wiki communautaire Ubuntu. Je vous en conseille la lecture.

Introduction aux “applications”

J’ai fait le choix d’utiliser principalement les “app”, parce que celles-ci peuvent configurer plusieurs ports, sur différents protocoles, pour un seul service et que ça ne génère qu’une seule entrée dans la liste de statut de ufw, avec le nom du service, et non le port dont on ne se souvient pas toujours de l’utilité. C’est donc beaucoup plus clair.

Quelques commandes utiles concernant les profils d’applications

Lister les profils disponibles (pour information, il n’y a par défaut quasiment aucun profil, ceux-ci s’ajoutent à l’installation des service concernés via apt) :

sudo ufw app list

Voir les détails d’un profil (ici avec OpenSSH) :

sudo ufw app info OpenSSH

Utiliser le profil dans une règle

sudo ufw allow app OpenSSH # (Autoriser SSH pour tout le monde)
sudo ufw allow app OpenSSH from 192.168.0.0/24 # (Autoriser SSH pour le réseau local)

Il ne vous reste plus qu’à autoriser tous les services qui le nécessitent.

Il faut noter qu’il est possible de créer soi-même de nouveaux profils. C’est ce qu’a fait ce bloggeur par exemple.

Dans le billet qui traitera de fail2ban, on reparlera de ufw.

Quelques conseils complémentaires

L’ordre des règles ufw a son importance. Les règles sont numérotées (utiliser sudo ufw status numbered pour voir ces numéros). Il est possible d’insérer une règle à l’endroit voulu en utilisant l’option insert # au début de la commande : sudo ufw insert 3 allow 44.

ufw étant une surcouche à iptables, il permet de faire tout ce que ce dernier permet, soit avec des commandes, soit en modifiant divers fichiers de configuration.

Hello World!

2014-12-06T00:00:00+01:00

PragmaGeek, le blog d’un geek pragmatique, démarre officiellement aujourd’hui. Vous en lisez le premier billet.

PragmaGeek, c’est une aventure, un voyage plusieurs fois entrepris, maintes fois écourté, celui vers l’auto-hébergement. C’est donc avant tout un recueil de documentations, de tutoriels et de ressources pour m’accompagner dans mon apprentissage du “cloud personnel”, et pour aider ceux qui entameraient eux-mêmes cette aventure formatrice.

PragmaGeek, c’est aussi un blog qui suit mes pérégrinations sur la toile, et qui me permet de partager mes diverses passions, mes trouvailles, ou tout ce qui me semble digne d’intérêt. En cela, il prend le relais de mon ancien blog, qui devrait sommeiller plus encore qu’avant, mais rester en ligne.

PragmaGeek

Ignorez les conseils des automobilistes, faites du vélo

Sélectionner la disposition clavier sur GDM

La bonne manière de faire un script Nautilus en Bash

Les scripts Nautilus, kézako ?

Les variables spécifiques

Testons un script basique

Testons ce même script basique sur un répertoire monté par gvfs

Comment itérer sur NAUTILUS_SCRIPT_SELECTED_URIS

Avec une boucle for

Avec une boucle while

Transformer une URI en chemin local

Utiliser GIO pour transformer une URI en chemin local

Transformer manuellement une URI en chemin local

Récupérer la partie finale du chemin

Décoder les caractères encodés de l’URI

La partie de lego pour tout mettre ensemble

Conclusion : un script moins simple, mais plus sain

Ressources supplémentaires

La vanlife est-elle écologique ?

La comparaison avec notre mode de vie polluant

La vanlife éco-responsable

Le critère qui met tout le monde au tapis : les émissions de CO2

Alors, on fait quoi ?

Filtrer les messages d’erreur de zenity au sujet d’un “transient parent”

Installer Aurora Services avec adb

Installation sur un téléphone non rooté

Prérequis

Redémarrez le téléphone

Utilisez ADB

Sur un téléphone rooté avec Magisk

Sur un téléphone rooté sans Magisk

Utilisation des fonctionnalités

Aparté

Nextcloud - Please update your PHP version

Description du problème

Comment corriger ce problème

Solution 1 : Rétablir la version par défaut de PHP du système

Solution 2 : Spécifier manuellement la version de PHP de cron

Installer Tribal Trouble sur Ubuntu 18.10

Installation du jeu

Bidouilles pour que tout fonctionne

Activer le son

Avoir accès au clavier pendant le jeu

Jouer !

Intégration au système

Créer un fichier .desktop

Remplacer l’icône du jeu

Activer la version complète du jeu

Autres astuces

Avoir accès à la deuxième campagne

Avoir accès aux codes de triche

Remarques diverses

Héberger son propre serveur de calendrier et de contacts

Installation

Configuration

Configuration de Radicale

Configuration du fichier “rights”

Configuration du serveur web

Configuration des DNS

Création des collections

Étapes supplémentaires

Intégration à fail2ban

Suivi du projet

Contrôler OpenELEC via HDMI-CEC avec une télécommande Samsung

Configuration d’allumage et d’extinction

Expression des besoins

Réglages à modifier

Sur la télévision

Sur l’amplificateur

Sur le media-center

Réglage de la télécommande

Identifier les codes

Activer les logs de Kodi

Lire les codes

S’il manque une touche

Associer chaque touche à une action appropriée

Sécuriser l’accès SSH d’OpenELEC

Créer une clé d’authentification

Copier cette clé sur le media center

Le critère qui met tout le monde au tapis : les émissions de CO₂