Ellendhel's Blog

Si d'aventure vous utilisez un appareil photo qui n'a pas la bonne volonté d'être compatible avec Gphoto, vous avez toujours besoin de récupérer vos images et si possible de manière automatisée. Comme bien souvent, il suffit d'écrire un petit script pour cela.

Ce script copie tous les fichiers (photos et vidéos) présents sur une carte mémoire dont vous devrez indiquer le point de montage. Le répertoire de destination sera daté (vous pourrez le renommer et ajouter un nom significatif) et pour chaque photo une miniature sera créée dont les données EXIF seront supprimées.

De plus il est possible de simplifier le lancement de ce script après insertion d'une carte mémoire dans KDE. Un peu de paramétrage est nécessaire pour cela : insérez votre carte et choisissez l'action "Ouvrir dans le gestionnaire de fichiers" dans le menu popup. Saisissez les commandes suivantes dans un terminal :

mount
ls -l /dev/disk/by-uuid

Vous devez retrouver dans les résulats le point de montage de la carte (tel que /dev/sdb1) et l'UUID correspondant (tel que 42ab-ca37). Cet UUID servira comme référence pour exécuter une commande lorsque KDE accède à ce volume.

Via "Configuration du système" lancez l'outil "Actions du périphérique". Cliquez sur le bouton "Ajouter" et appliquez les options ci-dessous :

- nom de l'action : Importation de photos

- cliquez sur l'icône en haut à gauche pour choisir une icône.

- indiquez le chemin d'accès au script "import-photos-KDE-SD".

- pour le paramètre, choisissez le type "Correspondance de la propriété" avec comme type de périphérique "Volume de stockage" et le nom de la valeur "Uuid" et donnez l'UUID récupéré précédemment.

Dans le cas où votre carte mémoire n'ait pas d'UUID vous pouvez éventuellement vous rabattre sur le nom du volume (Label), mais il arrive que cette information soit aussi absente ou que vous ayez plusieurs cartes avec des noms identiques. Reste alors à reformater la carte, après avoir récupéré les éventuels fichiers bien sûr, avec la commande suivante depuis le compte root (la carte ne doit pas être montée) :

mkfs.msdos -i 20120514 -n SD_CARD /dev/sdb1

La première option acceptera toute chaîne hexadécimale de huit caractères, et le nom ne devra pas comporter d'espace. La commande blkid permettra de vérifier le résulat.

Parmi les outils utiles à l'administrateur système et réseau, l'un de ceux qui se retrouve dans les premières places est Wireshark. Si ce nom ne vous évoque rien, il s'agit un logiciel permettant de capturer et analyser du trafic réseau. C'est à dire que lorsque l'on pense avoir tout configuré correctement, ouvert les ports nécessaires de son firewall, suivi toutes les étapes de la documentation et que rien ne fonctionne comme prévu, c'est Wireshark qu'il faut utiliser pour voir ce qui se passe vraiment.

Wireshark n'est pas proposé officiellement sous Slackware. Il existe bien un paquet pour tcpdump, qui se range dans la même catégorie, mais qui ne dispose pas d'interface graphique. Par contre Wireshark requiert la même bibliothèque libpcap pour la capture de paquets, et GTK pour ce qui concerne l'interface graphique, aucun souci donc pour procéder à l'installation.

Téléchargez les sources ainsi que le fichier de signatures. Puis récupérez la clé GPG pour vérifier le fichier de signatures.

gpg --search-key 0x21F2949A

Une seule clé devrait être indiquée en résultat, entrez le chiffre '1' pour l'ajouter à votre trousseau. Contrôlez ensuite le fichier de signatures :

gpg --verify SIGNATURES-1.6.7.txt

Aucune erreur ne devrait empêcher de passer à la vérification des sources :

grep -h --color $(sha1sum wireshark-1.6.7.tar.bz2) SIGNATURES-1.6.7.txt

Vous devez obtenir une ligne avec le nom du fichier et la somme SHA1 correspondante en rouge, signifiant que la signature à bien été trouvée.

L'extraction et l'installation de Wireshark ne diffère pas beaucoup d'autres logiciels, si ce n'est que la phase de compilation est très longue du fait de nombreux dissectors (90 Mo de sources, 450 Mo après compilation) pour analyser finement certains protocoles. Ce sont d'ailleurs ces mêmes dissectors qui soulèvent des problèmes d'utilisation : la capture de paquets réseau demande des privilèges élevés mais l'analyse ne doit pas se faire via le compte root, afin de limiter les risques de sécurité.

Évidemment, il serait possible de se connecter en tant que root pour effectuer une capture, la sauvegarder puis l'analyser avec son compte utilisateur, mais c'est une méthode qui se révèle vite fastidieuse... Comme la capture est déléguée à un binaire particulier, la documentation de Wireshark fournit le moyen de gérer cela de manière élégante en limitant son accès à un groupe spécifique, que l'on crée pour l'occasion :

groupadd -g 1003 wireshark

Ajoutez un utilisateur lambda à ce groupe (attention, cela n'est effectif qu'à la prochaine connexion) :

usermod -G $(echo $(id -G -n lambda | tr ' ' ','), wireshark) lambda

Modifiez les droits sur le programme dumpcap :

chgrp wireshark /usr/local/bin/dumpcap
chmod 754 /usr/local/bin/dumpcap

Et enfin exécutez la commande définissant des capabilities sur ce programme :

setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' /usr/local/bin/dumpcap

Les capabilities permettent une gestion des fonctionnalités du noyau Linux, en attribuant des permissions qui ne sont habituellement que de l'apanage de root. Vous pourrez trouver plus de documentation (toujours en anglais) sur le site officiel du noyau ou dans la page de manuel.

Après reconnexion, il suffit de lancer Wireshark et le trafic réseau ne devrait plus avoir de mystères pour vous !

Sur un ordinateur portable le touchpad est utile mais n'est pas aussi pratique qu'une souris "classique" surtout avec certains logiciels (création ou retouche d'image par exemple). De plus, lors de l'utilisation du clavier il arrive fréquemment que l'on effleure la surface sensitive et que l'on modifie quelque chose accidentellement.

Par défaut, X.org ne gère pas de priorité entre les périphériques, il faut donc utiliser quelques commandes pour désactiver le touchpad si une souris externe est connectée.

La commande qui nous sera utile est xinput, à la fois pour lister notre matériel et pour changer son comportement. Débranchez votre souris externe et lancez la commande suivante dans un terminal :

xinput --list

S'affiche alors la liste des périphériques d'entrée : clavier, webcam, bouton d'alimentation, ... Vous devez trouver quelque chose comme "PS/2 Generic Mouse" ou "SynPS/2 Synaptics TouchPad" dans la section "Virtual core pointer" ; il s'agit de celui qui nous intéresse.

Pour chaque périphérique il est possible de lister ses propriétés, toujours avec la même commande :

xinput --list "PS/2 Generic Mouse"

Attention à bien utiliser des guillemets ou à échapper les espaces (avec le caractère \). Autre possibilité, utiliser l'identifiant numérique, mais celui-ci n'est pas toujours consistant après chaque démarrage, il ne pourra donc pas être utilisé de manière systématique.

Dans les propriétés figure une nommée "Enabled", qui de manière logique permet d'activer (valeur un) ou désactiver (valeur zéro) notre matériel, encore une fois par le biais de xinput. Il faut indiquer l'identifiant numérique pour cette propriété (qui lui demeure stable) et la valeur souhaitée :

xinput --set-prop "PS/2 Generic Mouse" 144 0

Et le touchpad est désactivé. Pour revenir au comportement normal, seul le dernier argument change :

xinput --set-prop "PS/2 Generic Mouse" 144 1

Une fois les commandes de désactivation et d'activation validées il reste à mettre en place le mécanisme lié au branchement d'une souris externe. Cela s'effectue via udev qui permet d'exécuter des scripts lors de la modification de la configuration matérielle. Pour la distribution Slackware ces scripts se trouvent dans /etc/udev/rules.d. Les noms de fichiers doivent être préfixés par un numéro pour indiquer leur niveau de priorité et porter l'extension .rules. Dans notre cas, ce nom sera 99-mouse.rules. L'écriture des règles pour udev se situant entre l'art et la science, à défaut de donner toutes les explications, vous trouverez directement le code utilisable ci-dessous :

ACTION=="add", SUBSYSTEM=="input", ENV{ID_INPUT_MOUSE}=="1", ENV{DISPLAY}=":0.0", ENV{XAUTHORITY}="/home/ellendhel/.Xauthority", RUN+="/bin/sh -c 'DISPLAY=:0 /usr/bin/xinput --set-prop PS/2\ Generic\ Mouse Device\ Enabled 0'"
ACTION=="remove", SUBSYSTEM=="input", ENV{ID_INPUT_MOUSE}=="1", ENV{DISPLAY}=":0.0", ENV{XAUTHORITY}="/home/ellendhel/.Xauthority", RUN+="/bin/sh -c 'DISPLAY=:0 /usr/bin/xinput --set-prop PS/2\ Generic\ Mouse Device\ Enabled 1'"

Pour que le fichier soit pris en compte, vous devrez recharger les règles pour udev : /etc/rc.d/rc.udev reload

Il est nécessaire de déclarer deux variables d'environnement pour le DISPLAY et le fichier XAUTHORITY du fait que ces commandes soient lancées par l'utilisateur root.

Autre particularité, la gestion d'évènement ne prend en compte que la connexion de la souris ; si le système est démarré avec une souris branchée le script ne sera pas exécuté et les deux périphériques (souris et touchpad) seront actifs.

Enfin, ce script sera à adapter dans le cas où plusieurs personnes utilisent la même machine, le chemin vers le fichier XAUTHORITY devant être changé.

Comme on peut le lire sur un blog réputé, l'usage des algorithmes à base de courbes elliptiques pour DNSSEC à été officialisé par le RFC 6605.

Et le RFC correspondant à la création des enregistrements DNS SSHFP, utilisant la même méthode cryptographique (déjà présentée il y a quelques mois) à également été publié, et porte le doux nom de RFC 6594.

Comme pour la signature d'enregistrement DNS, il faudra sûrement attendre un peu pour que les outils soient prêts à utiliser cette nouvelle spécification.

Comme indiqué précedemment, un script permettant de gérer le daemon clamd est maintenant disponible ici même, script que vous pouvez adapter et redistribuer à souhait.

Il pourra être appelé depuis le fichier rc.local ou rc.inet2.