Linux Attitude

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é : 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é : PKI ; IGC

Une PKI (Public Key Infrastructure), en français IGC (Infrastructure de Gestion des Clés) est un système permettant de gérer des clés publiques. Il s'agit en général de gérer des certificats x509. Elle établit un réseau de confiance entre utilisateurs, lequel passe nécessairement par l'autorité de certification.

Ces certificats peuvent servir selon leur contenu à :

• Chiffrer (des communications)
• Signer (des documents)
• S'authentifier (sur des applications)
• Certifier d'autres clés

Disposer d'une PKI signifie qu'on est capable de créer, pour chacun de ses utilisateurs, des certificats qui nous permettront par la suite de lui faire confiance. Pour cela une PKI offre plusieurs services :

• Un service d'enregistrement qui vérifie l'identité des "utilisateurs"
• Un service de signature de demande de certificats
• Un service de renouvellement de certificats
• Un service de publication des certificats
• Un service de révocation des certificats
• Un service de publication des révocations
• Parfois un service de création de clés

Ces fonctionnalités sont généralement regroupées dans des entités séparées pour des raisons de sécurité. En effet, une PKI une fois en place devient rapidement un élément critique puisqu'elle permet de se faire passer pour une entité digne de confiance (pensez social engineering mais sans le social) . C'est pourquoi un certain nombre de fonctionnalités peuvent être installés dans un équipement dédié (un HSM, hardware security module). Du coté utilisateur, on peut faire pareil, sauf qu'on appel cet appareil dédié une carte à puce.

Mettre en place une PKI est une chose assez lourde. Mais elle devient intéressante à partir du moment où on se retrouve à gérer un grand nombre de certificats (beaucoup de serveurs ou beaucoup d'utilisateurs). Vous n'avez pas envie d'installer une PKI pour vous authentifier sur un seul serveur. Mais si vous avez 200 000 employés et que vous voulez que tout le monde signe ses mail en x509, il est temps d'en installer une.

Je voudrais attirer votre attention sur le fait qu'il ne s'agit pas seulement de créer des certificats et de les signer. La confiance se fait sur toute une chaîne, et il faut pouvoir garantir que l'autorité n'a pas été compromise (AC séparée). Il faut pouvoir garantir cette confiance dans le temps (renouvellement), il faut pouvoir se prémunir des erreurs, des vols ou des changements d'organisation (révocation). C'est pourquoi il est nécessaire de prendre son temps avant de l'installer pour bien comprendre le fonctionnement de chaque élément.

Il existe plusieurs PKI open source dont EJBCA ou NewPKI. Je parlerai d'OpenSSL, la PKI du pauvre, dans mes prochains articles. Principalement pour pouvoir mettre les mains dans le cambouis, ne pensez pas à l'utiliser tel quel comme PKI.

Niveau :      
Résumé : perl -pe 's///'

Il arrive régulièrement d'avoir à développer des expressions régulières. Si on excepte grep et sed, la plupart des outils utilisant des expressions régulières sont compatibles perl (en utilisant PCRE). C'est donc un bon point. Apprendre les expression régulières (qu'on peut considérer comme un langage à part entière) ne sera pas perdu même si on change d'outil ou de langage.

Tests

Avant de développer une expression régulière, je vous propose de vous familiariser avec le test de ces expressions. Si vous avec une ligne de commande c'est tout simple, hop un test ligne par ligne :

$ perl -pe 's/expression/########/'
données
a matcher, 
autant que vous voulez
<ctrl -d>

Mais si vous préférez un interface plus évoluée : voici un des nombreux qui permettent de tester vos expressions en direct http://myregexp.com/ et avec coloration des éléments matchés.

Syntaxe de base

Une expression régulière, c'est une chaîne de caractère qui a pour but de repérer des informations dans un texte. Elles sont en général implémentées sous forme d'automates à état finis. Cette méthode est extrêmement efficace et dans la plupart des cas il est très difficile de faire plus rapide.

Cette chaîne peut être utilisée pour chercher des informations dans un texte, mais aussi pour faire des remplacements automatisés. Perl utilise une syntaxe autour des expressions régulières pour préciser comment les utiliser. Celle-ci est souvent reprise par les utilisateurs des PCRE mais ca n'a rien d'obligatoire :

• /expression/ : pour faire des recherches
• s/expression/remplacement/ pour faire du recherche/remplacer
• y/expression/remplacement/ pour faire des substitutions de caractères

y/// est un cas particulier que nous ignorerons.

Niveau :      
Résumé :

La gestion des langues sur les unix c'est pas le paradis. Il est possible de configurer finement les choses, mais ce n'est pas des plus adapté.

Terminal

Prenons le cas d'un terminal. La gestion doit se faire en plusieurs endroits. Tout d'abord le terminal virtuel est lui-même un processus (sauf la console linux qui se configure différemment) qui peut avoir des langues différentes. Il doit en plus être configuré pour communiquer avec la même langue que le processus qu'il fait tourner. En effet cette communication n'inclut pas explicitement la langue, il faut donc qu'elle soit définie implicitement de la même façon de chaque côté.

En supposant que le terminal soit déjà lancé avec une langue donnée (disons le français). Celui-ci vous propose encore à travers son menu (mais chaque terminal est spécifique) de configurer la façon dont il communique avec le client (bash le plus souvent).
Cette configuration gère deux choses simultanément : le format des codes de caractère venant du clavier et envoyés à l'application et le format des caractères envoyés par l'application au terminal et qui seront affichés.

L'application lancée à travers ce terminal doit parler la même langue que celui-ci (à moins qu'elle ne soit graphique auquel cas on se fout de la configuration du terminal). Les applications sont configurées au travers des variables d'environnement LANG et LC_* (ce qui explique qu'à part bash, les application supportent rarement le changement de langue en cours de route. Cela explique aussi que tous les processus fils d'une application tournent avec la même localisation (gnome et les applications graphiques par exemple).

Variables

Ces variables configurent l'entrée et la sortie des applications lancées :

• LANG définit d'un coup la langue, l'encodage et le pays utilisés par l'application c'est une valeur par défaut qui peut être surchargées par les variables suivantes.
• LC_* sont des variables permettant de redéfinir plus finement les valeurs de LANG. Par exemple on peut choisir une langue française mais afficher les nombre avec des points à la place des virgules. Les valeurs de * sont CTYPE, NUMERIC, TIME, COLLATE, MONETARY et MESSAGES. Chacune de ces variables correspond en réalité à une fonction de la libc.
• LC_ALL est une variable qui surcharge tous les autres LC_* d'un coup, les mettant à la même valeur.
• LANGUAGE est une variable qui ne définit QUE la langue utilisée pour les messages (la partie codage ne sert pas), mais permet d'en spécifier plusieurs par ordre de préférence (séparées par des ':' ).

Niveau :      
Résumé : tail -F ; ls | wc ; xmodmap ; bell-style ; /proc/sys/kernel/core_pattern

Lire un fichier au fur et a mesure qu'il est complété (par exemple un fichier de log) :

# -F bon réflexe pour les fichier qui peuvent être rotatés
$ tail -F fichier

Compter les entrées d'un répertoire sans se planter avec les noms spéciaux (espace ...) Perdre son temps

$ find . -maxdepth 1 -mindepth 1 -printf a | wc -c

Transformer votre souris en souris pour gaucher :

$ xmodmap -e "pointer = 3 2 1"

Supprimer les bips en bash :

$ set bell-style none

Transformer les bips en flash écran en bash :

$ set bell-style visible

Retour au comportement par défaut :

$ set bell-style audible

Faire apparaitre tous les core dump dans /tmp et non dans le cwd du processus :

# on en profite pour lui donner un nom unique <binaire>-<date>-<pid>.core
$ echo /tmp/%e-%t-%p.core > /proc/sys/kernel/core_pattern

Pour rendre cela persistant au reboot, écrire la ligne suivante dans /etc/sysctl.conf :

kernel.core_pattern=/tmp/%e-%t-%p.core

Niveau :      
Résumé : la vie avec unix

Unix, ce n'est pas seulement un système, ce n'est pas seulement une marque, c'est aussi une façon de voir les choses, une façon de concevoir des programmes qui feront ce dont vous avez vraiment besoin. Nous allons parler des principes fondamentaux d'unix.

Tout est fichier

On commence à le savoir, les périphériques sont des fichiers qui se trouvent dans /dev, les processus sont des fichiers qui se trouvent dans /proc, les paramètres et données du noyau sont des fichiers qui se trouvent dans /sys et accessoirement /proc, les exécutables sont des fichiers normaux. Seule la carte réseau n'est pas un fichier, pour des raisons de performances paraît-il. Mais les connexions sont tout de même vues à travers des descripteurs de fichier dans les processus.

Les données sont du texte

Dans la philosophie unix, toutes les données doivent être stockées et transmises sous forme de texte. Cela peut coûter légèrement plus de place qu'un format binaire. Mais on y gagne beaucoup.

• Un fichier texte peut être lu par les autres outils unix, et donc respecte de principe faire une chose et le faire bien
• Un fichier texte peut être lu par un être humain et donc respecte le principe kiss
• Un fichier texte permet une interopérabilité avec d'autres systèmes (pas de problèmes d'indiens en iso par exemple)
• Un fichier texte facilite le débugage

On retrouve donc le texte partout :

• Dans les scripts
• Les fichiers de configuration
• Des formats de données d'application
• Dans les protocoles réseau de haut niveau
• La sortie d'informations se vos programmes

On ne le retrouve pas dans les cas où l'espace ou le temps de parsing sont primordiaux, par exemple dans les formats d'image ou de son.

Et la tendance va en s'accentuant puisqu'on utilise de plus en plus un format texte structuré un peu partout et à toutes les sauces : le xml.

KISS

Keep it simple, stupid !