Linux Attitude

C'est le week-end, je fatigue un peu. Parlons donc de sujets réjouissants : les trolls.

Sur internet on trouve de nombreux forums, des salons de discussions, des sites ou tout le monde peut participer ... Autant d'endroits ayant potentiellement un public nombreux et varié. C'est le terreau idéal pour faire pousser un troll.

Petite recette pour un troll réussi :

• choisissez un site participatif ayant une forte audience pour maximiser la portée et les réactions potentielles (forum ubuntu)
• choisissez un sujet n'ayant pas été universellement détecté comme nid à troll pour lui donner de bonnes racines (faut-il parler de culture pub sur linuxfr)
• mettez bien en évidence qu'il n'y a pas de contradiction possible à vos affirmations (tout le monde est d'accord pour dire que...)
• ne lancez pas votre troll dans le vide, répondez à quelqu'un de façon à ce qu'au moins une personne se sente visée et cherche à y répondre (votre commentaire n'a aucun intérêt)
• utilisez quelques mots agressifs ou dénigrant envers une personne ou une communauté pour augmenter le potentiel de réaction (le niveau des auteurs laisse à désirer)
• posez une question aussi sérieuse que possible pour augmenter encore plus les chances d'obtenir une réponse qui sera nécessairement agrémentée de nourriture pour troll (sait-on à quel point la technique du double nat est utilisée)

Techniques pour agrémenter un troll et allonger sa durée de vie :

• utilisez des questions non techniques sous couvert technique (emacs vs vi Combien de doigts ?)
• une petite dose de mauvaise foi peut être appréciable, mais n'en abusez pas, cela peut arrêter les réponses (vous voulez vraiment tuer tous les bébés phoques ?)
• au delà d'une taille critique, un troll peut être détecté mais continuer à grossir, n'hésitez plus à utiliser de grosses ficelles (... de la part d'un pédo pornographe comme vous ...)

Niveau :      
Résumé : moreutils ; ts ; vidir ; mispipe ; isutf8 ; lckdo ; vipe ; ifdata ; pee

Ces commandes sont dans le paquet moreutils sur debian.

Ajouter un timestamp sur chaque ligne pour lire une commande un peu lente :

$ ./commande | ts | tail

Éditer en masse les entrées d'un répertoire (pour renommer des images par exemple) :

# Tout le répertoire
$ vidir repertoire
# Seulement les images 
$ vidir *.jpg

Retourner le code d'erreur du premier élément d'un pipe et non du dernier (très utile en scripting) :

# Retourne une erreur si $dir n'existe pas
$ mispipe "ls $dir" "tail"

Vérifier qu'un fichier utf8 est valide :

$ isutf8 fichier && echo OK || echo "Not OK" 

Ne pas écraser un fichier de destination avant la fin de la commande :

# Version fonctionnelle de cat a b > a
$ cat a b | sponge a

Créer un script de type cron avec un lock sans effort :

$ lckdo -W 10 /var/lock/mylock /usr/local/bin/myscript

Éditer le contenu d'un pipe (très pratique pour le debug de script) :

$ commande1 | vipe | commande2

Éviter les envois de mail de rapport lorsqu'il n'y a rien à rapporter :

$ /usr/local/bin/rapport.pl | ifne mail -s "Synchro en retard" sysadmins@mynnet.net

Permettre (optionnelle ment) de passer des fichiers compressés en argument à un script (comme pour zless) :

# Recoder zless
$ zrun less $1

Éviter de parser le résultat de ifconfig ou de ip dans un script (nombreuses options, de sortie, lire le man) :

# Afficher le nombre d'octets reçus
$ ifdata -sib eth0

Passer le résultat d'une commande à plusieurs autres

# Attention si commande1 et commande2 produit du texte, rien ne garantit leur ordre
$ commande | pee "commande1" "commande2"

Comparer ligne par ligne deux fichiers avec des opérateurs plus évolués que comm :

$ combine fichier1 xor fichier2

Niveau :      
Résumé : cd && git init ; cd /etc && git init

Maintenant que vous avez étudié git, voyons à quoi il peut servir.

Configuration

Git peut, entre autre, fonctionner en local, comme RCS. Git est plus intéressant que d'autres outils comme svn pour plusieurs raison :

• Il stocke tout en local à la racine du répertoire de travail
• Il n'éparpille pas de fichiers un peu partout
• Il prend 2 à 3 fois moins de place que svn pour des petits fichiers comme les fichiers de configuration
• Il est un ordre de grandeur plus rapide que svn (ce qui importe peu pour /etc)

Notez que mercurial répond aussi à ces besoins.

Git est donc parfaitement adapté à votre configuration qui se trouve dans /etc :

# En root
$ cd /etc
$ git init

J'ai commencé par faire un "git add *" mais en pratique ce n'est pas une très bonne idée car on récupère tout et n'importe quoi et à moins de ne pas avoir de backup, ce n'est pas très utile. En effet cela entre en conflit avec les gestionnaires de paquet et gestionnaire s de configuration et c'est assez gênant lors des migrations. Une bonne utilisation est plutôt de faire un "git add" uniquement pour les logiciels dont on modifie la configuration. Ainsi, vous avez dans votre dépôt toutes vos modifications et uniquement vos modifications. Cela nécessite de s'imposer de faire les "git add" mais c'est plus simple.

D'autre part, rien ne vous empêche d'avoir un cron de commit automatique pour rattraper les cas où vous oubliez de le faire.

# Autocommit une fois par semaine, s'il n'y a rien à commiter, il ne fera rien
0 0 * * 1 cd /etc && git commit -a -m "Autocommit by cron"

Le jour où vous avez un problème de configuration :

# On cherche ce qui a changé depuis le dernier commit (fonctionnel ?)
$ git diff
# On cherche quand ça a changé avant
$ git log
# On cherche ce qui a changé avant
$ git diff ee9eac2a4deb43e7c73b50444fcb7269f172fb69

Niveau :      
Résumé : git

Git est un système de suivi de version. Git est beau, git est simple, git a été fait par Linus Torvalds.

Tout seul

Dans une utilisation de premier niveau, git peut fonctionner comme RCS, c'est-à-dire en local.

Créons un dépôt local dans le répertoire que nous voulons versioniser :

$ git init

Fini !

Ajoutons un fichier au suivi des versions :

# add est récursif par défaut
$ git add monfichier
$ git commit -a

Bon je pense que vous avez compris, donc je vous la fais courte. Pour avoir la documentation d'une commande il suffit d'ajouter un tiret après git. Exemple le manuel de "git add" est dans "man git-add" ou dans "git add --help". Voyons les commandes de base utilisées le plus fréquemment, vous y reconnaîtrez celles qu'on trouve dans la plupart des systèmes de suivi de version (CVS, RCS, SVN ...) :

• git add : Ajouter un fichier au suivi de version
• git commit : Valider les modifications
• git log : Pour voir les modification récentes
• git diff : Voir ce qui a changé pour un fichier depuis une certaine version
• git revert : Annule une unique modification (il est possible d'annuler une modification passée sans annuler tout depuis ce moment)
• git status : Savoir tout ce qui n'a pas encore été validé

Vous remarquerez que git utilise des sommes sha1 pour identifier les différentes versions. Cela permet d'être universel et de ne pas avoir de problème de collision. Il vous faudra juste un peu de temps pour vous adapter à lire les logs avec des numéros aussi longs et non incrémentaux.

Niveau :      
Résumé : ps ; top ; htop ; atop ;

Suite à un article sur les processus, j'ai trouvé une excellente série d'article vous permettant de découvrir le fonctionnement interne du noyau sur les processus et la mémoire :

• memory-translation-and-segmentation
• getting-physical-with-memory
• anatomy-of-a-program-in-memory
• how-the-kernel-manages-your-memory
• page-cache-the-affair-between-memory-and-files

Maintenant, essayons de résumer la gestion des processus d'un point de vue utilisateur et développeur.

Naissance, vie et mort d'un processus

Un processus est créé lorsque l'appel système fork est appelé et seulement dans ce cas. Les autres méthodes possibles se basent toutes sur fork (et clone, mais il ne faut pas le dire). Fork ne fait qu'une chose (et il le fait bien), il duplique un processus existant, entièrement, à l'identique, y compris ses droits.

Ensuite, durant sa vie un processus peut être modifié de nombreuses façons :

• Changement d'utilisateur
• Changement de code
• Changement de père
• Changement de priorité
• etc.

Enfin un processus meurt dans 2 cas :

• Il se termine tout seul comme un grand (appel système exit)
• Il reçoit un signal qui lui est fatal

Informations sur un processus

Informations générales

Pour récupérer des informations sur un processus vous disposez de plusieurs commandes. Ces commandes ou toutes pour source /proc/<pid> qui est un répertoire virtuel peuplé directement par le noyau.

Les commandes les plus courantes sont :

• ps : liste des processus et de leurs caractéristiques
• htop : liste dynamique des processus et de ce qu'ils consomment
• pgrep : récupération d'une liste de processus par expression régulière
• pidof : récupération du pid d'un processus recherché
• fuser : informations sur les file descriptor d'un processus
• lsof : idem
• pmap : afficher le mapping mémoire d'un processus

Niveau :      
Résumé : openssl

Vérification

Maintenant que nous avons des certificats propres et bien signés il va falloir les vérifier. Mais il ne s'agit pas simplement de vérifier que le certificat est valide et signé par une autorité de confiance. Tout d'abord, il fautde vérifier toute sa chaine de confiance. Ensuite il faut vérifier ses extensions, par exemple s'il va être utilisé pour les usages auxquels on l'a prévu.

Openssl permet de faire la vérification de la chaine de certification ainsi que la vérification de l'usage. Pour cela il faut installer l'autorité de confiance :

# On trouve le hash du certificat de l'AC
$ hash=$(openssl x509 -hash -noout -in cacert.pem)
# On installe l'AC en utilisant ce hash (il faut être root ici)
$ cp cacert.pem /etc/ssl/certs/$hash.0

Du coup la vérification d'un certificat se fait simplement :

$ openssl verify -purpose sslclient certificat.crt

Pour la vérification des extensions, il faut voir au cas par cas.

Mais contrairement à ce qu'on pense souvent, ce n'est pas tout. Il faut aussi vérifier que le certificat n'est pas révoqué, c'est-à-dire invalidé avant la date limite.

Révocation

La révocation d'un certificat se fait dans plusieurs cas :

• perte de la clé
• départ du propriétaire de la clé
• renouvellement de la clé
• ...

En gros à chaque fois qu'on veut garantir que la clé ne sera plus utilisée.

Pour révoquer un certificat alors qu'on a installé une AC openssl comme dans l'article précédent :

# On en profite pour indiquer pourquoi on le révoque
# les raisons possibles sont : unspecified, keyCompromise, CACompromise,
#   affiliationChanged, superseded, cessationOfOperation, certificateHold or removeFromCRL
$ openssl ca -config openssl.cnf -revoke client.cert -crl_reason keyCompromise

Il existe 2 mécanismes pour faire savoir au monde qu'on a révoqué un certificat : les CRL et le protocole OCSP.