Linux Attitude

Niveau :      
Résumé : ~/.gnome2/nautilus-scripts

Aujourd'hui parlons un peu d'interface utilisateur. Vous arrive-t-il souvent de lancer la même commande sur plein de fichiers ? Avez-vous une personne de votre famille qui perd son temps à ouvrir des fichiers un par un pour faire une modification dans chaque ?

Si ces opérations sont automatisables (calculs openoffice, modification d'image, ajout d'une ligne de texte ...) alors il y a un moyen pour les rendre accessible directement depuis le navigateur de fichier. Pour cela, il suffit d'écrire un script et de le placer dans ~/.gnome2/nautilus-scripts. Essayer de bien le nommer car il apparaîtra tel quel dans le menu contextuel "Scripts" de nautilus.

Pour parler concrètement, nous allons faire un outil de réduction d'image disponible directement depuis le navigateur de fichier. Nous allons donc éditer le fichier ~/.gnome2/nautilus-scripts/ReductionPhotos qui nous permettra d'appeler imagemagick pour réduire la taille des photos sélectionnées (en ajoutant un préfixe pour ne rien perdre). Nous feront notre démo sur tous les fichiers sélectionnés à la souris pour bien montrer qu'on automatise un comportement d'utilisateur "normal".

Le script reçoit ses informations dans des variables d'environnement. La plus importante dans notre cas est NAUTILUS_SCRIPT_SELECTED_FILE_PATHS qui contient la liste des fichiers sélectionnés séparés par des retours à la ligne. Donc une petite boucle pour les traiter tous d'un coup :

echo -n "$NAUTILUS_SCRIPT_SELECTED_FILE_PATHS" | while read in_file
do
        process_file $in_file
done

Alors il se peut que le script ait des questions à poser à l'utilisateur. C'est le moment d'utiliser zenity. Un petit outil sympa, équivalent de dialog, mais bien mieux intégré dans gnome. Petite exemple avec la sélection d'un nombre dans une intervalle de 0 à 100 :

$ percent=$(zenity --scale --title="Choix du pourcentage" --text "Pourcents : " --value="50" --min-value="0" --max-value="100" --step="1")

Simple non ?

Pour traiter les images en ligne de commande, vous connaissez imagemagick. Voici la commande à utiliser dans mon cas :

convert image1.jpg -quality 80 -resize 1200 image2.jpg

Voila, on a toutes les briques pour faire le script.

Niveau :      
Résumé : pam_faildelay.so ; tail -F * ; dusort ;

Réduire le délai en cas d'erreur du mot de passe (très chiant pour su par exemple). Simple calcul, le délai par défaut de 2s donne 13243 ans pour bruteforcer un mot de passe de 8 lettres (26 possibilités). On peut donc se permettre de diviser ce délai par 4 pour apporter un peu de confort à l'usage :

$ vi /etc/pam.d/common-auth
# on annule le délay ajouté par pam_unix
auth    required        pam_unix.so nullok_secure nodelay
# on ajoute un délai en microsecondes
auth  optional  pam_faildelay.so  delay=500000

Attention, login vient avec son propre délai supplémentaire de 3 secondes chez debian (dans /etc/pam.d/login).

Il est possible de regarder les nouvelles lignes sur plusieurs fichiers en même temps :

$ tail -F /var/log/*

Alias pour connaître rapidement les 10 plus gros répertoire du répertoire en cours :

$ alias dusort='du --max-depth=1 | sort -rn | head -n 10'

Appeler une commande en évitant tous les alias possible (par exemple rm qui est aliasé rm -i):

# bash uniquement
$ \commande

Avancer / reculer d'un mot lors de l'édition de ligne (bash ou tout outil readline) Esc-fleche droite ou gauche.

Effacer les fichiers de plus de XX jours :

$ find . -not -ctime -XX -name "*.ncap" -exec rm {} ;

Niveau :      
Résumé : Xvnc

Supposons une machine sur laquelle vous n'avez pas d'écran. Vous voudriez tout de même pouvoir y accéder en mode graphique. Pour ma part, il s'agit de mettre en place une machine autonome, qui servirait à diffuser la musique sur mon ampli. Pas de place pour l'écran, le problème, il faut bien la commander un peu de temps en temps.

Pour cela il y a plusieurs solutions

Solution A

Dans le cas de diffusion de musique, il est possible de trouver un système purement serveur permettant d'être commandé par une interface web ou un client en ligne de commande. Je pense à des plugins spécifiques à des client habituels ou à des serveurs comme mpd sans interface graphique.

Inconvénient, l'interface est assez peu intuitive et nécessite une certaine bidouille pour être accessible par tous. De plus on passe du temps pour finalement ne faire que de la musique (si on veut que la machine fasse aussi alarme, il faut repartir dans la bidouille.

Solution B

Un solution très unixienne avec interface graphique serait de mettre en place XDMCP sur le service de connexion (gdm, kdm ...). Bonne solution, même pour les clients windows puisque xming permet de faire serveur X sous windows.

Cette solution nous permettrait de disposer de tous les avantages d'un bureau intégré, par exemple, régler le son, configurer une radio ... Par contre, cette solution a l'inconvénient de rendre la machine concernée non autonome. A la moindre déconnexion, pof, plus de musique. Mais expliquons quand même la solution brièvement.

• Activez XDMCP sur votre *dm
  • gdm : dans /etc/gdm/gdm.conf
  • kdm : dans /etc/kde*/kdm/kdmrc

[xdmcp]
Enable=true

• Connectez vous avec votre serveur X
  • X86 ou Xorg :

$ X -query machine.distante.net

• • Xming : xlaunch / "One WIndow" / "Open session via XDMCP" / "Connect to Host"

Niveau :      
Résumé : perlconsole

Vous développez régulièrement vos scripts en perl ? Si oui : lisez ceci ou cela ou encore d'autres choses plus ou moins utiles.

Si oui vous devez faire des tests de temps en temps. Je me suis habitué à faire des perl -e ou perl -pe pour des petites choses. Mais il existe un outil bien plus pratique : perlconsole.

Son usage est simple :

$ perlconsole

Pour le debug, cet outil est sympa puisqu'il permet de taper les commandes une par une et d'en avoir la valeur de retour.

Pour le développement cet outil est parfois un peu lourd puisqu'il renvoie la valeur de retour de toutes les commandes tapées, même si cela ne nous intéresse pas vraiment.

Autre fonctionnalité qui ravira certains, les valeurs de retours peuvent être affichées sous différentes formes. Ce qui veut dire qu'il est possible d'avoir un dump complet du résultat de chaque commande. Il suffit pour cela d'entrer la commande suivante pour les habitués de Data::Dumper :

:set output=dumper

Mais il existe aussi une sortie yaml, que je trouve personnellement plus lisible pour des structures ne dépassant pas une page.

:set output=yaml

Niveau :      
Résumé : ngrep ; netsed ; tcpdump | strings

Grep

Pour lire ce qui passe en TCP en filtrer des mots clés vous avez plusieurs techniques.

Commençons par la technique bourrin, mais qui marche :

# on dumpe en gardant les data, dont on extrait les chaines de caractère
$ tcpdump -s0 -w - port 80 | strings | egrep "html|head"

Pratique et facile à mémoriser. Cette technique permet pas mal de choses, mais est à considérer pour des serveur peu chargés.

Ngrep

Ngrep lui, est capable de vous sortir uniquement les paquets dont les données matchent une expression. L'usage n'est pas forcément le même que le précédent, ici on a un paquet complet :

$ ngrep "html|head" "port 80"

Pratique quand on est à la recherche d'un paquet foireux, ou qu'on veut loguer ce qui ce passe pendant un problème.

Sed

Un autre outil pour tester une application réseau, c'est netsed (du paquet bien nommé). Une commande bien utile qui crée un proxy tcp ou udp capable de modifier les paquets en direct.

Il ne fait ça qu'avec des expressions basiques :

# Attention pas de résolution de nom
$ netsed tcp 1080 1.2.3.4 80 's/Developpement/Production'
# Test 
$ telnet localhost 1080

Attention, contrairement à ce qu'on pourrait croire, ce ne sont pas des vraies expression sed, on est assez limité. D'autre part netsed fonctionne sur des paquets, ce qui veut dire que dans un petit nombre de cas, il ne fait pas ce qu'on veut (données à matcher répartie sur 2 paquets).

En fait, il faut prendre cet outil pour ce qu'il est, un outil de test et de debug. D'autant plus qu'il faut toucher au client pour le rediriger vers le port d'écoute de netsed.

Niveau :      
Résumé : wireshark ; tcpdump

Face à un problème de communication, on en est souvent réduit aux outils de base : un sniffer.

tcpdump

Le sniffer le plus connu est tcpdump. Si vous ne l'avez pas encore utilisé, man est votre ami. Mais il est très simple. Petit exemple en root :

$ tcpdump host 1.2.3.4 and port 80

Le langage de filtrage de tcpdump est assez simple, pour l'apprendre, chercher la section "expression" dans le manuel de tcpdump. Mais finalement, la sortie de cet outil n'est pas très passionnante, et à moins de savoir décoder le tcp/ip à la vitesse de la lumière ou d'avoir besoin juste d'une petite information (les paquets passent ? combien ? ...), il est un peu ardu à utiliser.

Tout de même, les quelques options à connaître :

• -e : pour des problèmes au niveau ethernet
• -i : pour écouter sur une interface (attention le any par défaut n'inclue pas le loopback)
• -s 0 : pour stocker l'intégralité des paquets capturés (à utiliser de préférence avec -w)
• -w fichier : stocke les données dans un fichier pour analyse ultérieure

wireshark

De son ancien nom ethereal, wireshask est l'équivalent graphique de tcpdump. On ne se rend pas compte sans l'avoir testé de tout ce qu'apporte la version graphique. L'analyse de paquet est plus détaillée qu'avec tcpdump, on peut demander des infos a posteriori à coup de clic ou filtrer une unique communication.

Utilisez par exemple sudo (ou xauth) pour lancer facilement wireshark en tant que root. Wireshark utilise les mêmes filtres que tcpdump. Pratique, votre apprentissage n'est pas perdu.

Voici ce que donne une capture.

Niveau :      
Résumé : conntrack

I'm back !
Désolé de vous avoir fait attendre, j'étais en quelque sorte en vacances.

Firewall

Cette fois nous allons parler de firewall. Comme vous le savez, netfilter, le firewall intégré à linux, est statefull par défaut. Ce qui veut dire que si on ne lui dit pas de ne pas le faire, il trace l'état de toutes les connexions qui le traversent. C'est grâce à cela qu'il sait filtrer les connexions avec des règles "simples" ou qu'il est capable de filtrer proprement le ftp.

Pour cela il garde en mémoire une table des connexions établies, qu'il peut communiquer au reste du monde, autrement appelé espace utilisateur. Il expose ces infos dans /proc/net/ip_conntrack* (entre autre, mais n'hésitez pas à regarder le contenu de ce répertoire pour plein de choses intéressantes).

La commande conntrack, du paquet éponyme sert à manipuler la table en question. Toute machine ayant un firewall, ou presque, on peut s'amuser à l'utiliser sur son PC. Mais c'est bien plus rigolo de faire ça sur un routeur ;->

D'ailleurs, si vous avez un serveur qui ne fait pas firewall et qui gère beaucoup de connexions (un serveur de twitter par exemple), vous pouvez désactiver le "connection tracking" pour soulager le noyau de cette tâche. Mais il faut entièrement désactiver le module, ce qui n'est pas des plus simple.

Conntrack

D'abord, commençons par lister les connexions connues :

$ conntrack -L

Pour une machine qui ne fait pas routeur, la liste est similaire à celle obtenue par netstat -atu. Notez les informations intéressantes : état de la connexion, détail de la connexion (remarquez la répétition nécessaire pour le NAT), et surtout nombre de paquets et d'octets passés par cette connexion. Ce compteur peut être réinitialisé avec l'option -z de conntrack :

$ conntrack -L -z

Pratique quand on veut détecter les changements.

Vous pouvez aussi regarder ce qui se passe en direct sur votre routeur :

$ conntrack -E

Mais lisez bien le manuel, pour limiter la sortie, car sur un vrai routeur, il faut filtrer. Man conntrack contient toutes les explications.

Et le plus rigolo sur un routeur partagé, on enlève l'entrée :

# Attention, il faut tout spécifier pour être sûr qu'on parle de la bonne connexion
$ conntrack -D -s 1.2.3.4 -d 4.3.2.1 -p tcp --orig-port-src 5678 --orig-port-dst 22

Cela devrait couper la connexion si le firewall est bien configuré (et probablement aussi s'il est mal configuré). C'est tout de même moins artisanal que l'ancienne technique.