Linux Attitude

Niveau :      
Résumé : /dev/random /dev/urandom

Quelle différence y a-t-il entre /dev/random et /dev/urandom ? Et d'abord à quoi servent-il ?

Aléatoire

Qu'est-ce qu'un nombre aléatoire ? C'est un nombre faisant partie d'une série dont on ne peut pas prédire le prochain à partir des nombres précédents de la série.

Il existe de nombreuses méthodes pour créer des nombres aléatoires. Je vous donne la plus mauvaise : rand : i -> 0

Mais il existe aussi des suites moins prévisibles, par exemple prendre le dernier chiffre d'une opération récursive produisant de grands nombres. Voire complètement imprévisible comme utiliser la mesure d'un bruit blanc.

Il existe donc plusieurs niveaux d'"aléatoirité" ou de "prévisibilité". Un bon générateur qui peut par exemple être utilisé en cryptographie est en pratique soit un générateur matériel, soit un générateur basé sur un état interne et une fonction de hachage forte.

Les générateurs logiciels sont appelés PRNG (pseudo random number generator). Puisqu'un tel algorithme est déterministe, il faut l'initialiser avec des valeurs vraiment aléatoires pour éviter qu'on puis en deviner la sortie en devinant comment il a été initialisé.

Entropie

Sous linux il y a deux sources de nombres aléatoires, /dev/random et /dev/urandom.

La première utilise uniquement l'entropie disponible pour fournir des nombres aléatoires et le second est un générateur pseudo aléatoire initialisé avec cette entropie.

Mais qu'est-ce que l'entropie ?

Niveau :      
Résumé : pam_exec

Vous souvenez-vous de PAM (Pluggable Authentication Modules) ? En plus des nombreux modules déjà présentés, on trouve pam_exec qui permet d'exécuter une commande arbitraire. A partir de là on peut faire pas mal de choses, comme par exemple une notification à chaque session ouverte par un utilisateur (connexion ssh, su, sudo, etc.).

Notification de connexion

Nous allons créer une règle utilisant le module pam_exec pour exécuter un script de notification à l'ouverture d'une nouvelle session.

Script de notification

D'après le manuel de pam_exec, les informations PAM sont passées au script à l'aide des variables d'environnement : PAM_RHOST, PAM_RUSER, PAM_SERVICE, PAM_TTY, PAM_USER et PAM_TYPE. Concevons donc un script simple qui :

• ne s'intéresse qu'au cas de l'ouverture d'une nouvelle session, soit le type PAM open_session
• récupère les informations et les envoie par mail à l'administrateur

Niveau :      
Résumé : /proc/<pid>

Les processus comme je l'ai déjà décrit, forment une grande famille.

La famille processus

Dans la famille processus je voudrais le père

Les processus se reproduisent par fork (Mitose en français). Ce qui veut dire qu'à la genèse il n'y avait qu'un processus que nous ne nommerons pas Adam mais init.

Tous les processus possèdent un identifiant (pid) ainsi qu'un identifiant de processus parent (ppid) permettant de les repérer dans un arbre généalogique (pstree).

Comment reconnait-on le père du fils lors du fork d'un processus ? Uniquement par le code de retour de la méthode fork qui vaut 0 pour le fils et donne le pid du fils au père. En dehors de cela les 2 processus sont rigoureusement identiques.

Dans la famille processus je voudrais la mère

Désolé, il n'y a pas de femme chez les processus, la reproduction est asexuée, mais c'est une idée à creuser ...

Dans la famille processus je voudrais le fils

Lorsqu'un processus forke, en général le père poursuit sa vie comme si de rien n'était, par contre le fils va muter. La mutation génétique chez les processus est bien plus violente que chez les êtres vivants. En effet, le code (l'ADN en français) est intégralement relu et remplacé depuis un nouveau fichier sur le disque. C'est ce qu'on appelle un exec.

Il existe quelques cas de processus qui ne fonctionnent pas comme ceci, mais qui laissent leur père mourir (ingrats !) et qui prennent leur place. C'est le cas des démons (un parricide est-il un démon ?) dont le but est de devenir indépendants (émancipés) et ne plus avoir de problèmes d'adolescence (le tty du père) ou de famille (le groupe de processus).

Dans la famille processus je voudrais le grand-père

Lorsqu'un processus meurt, sa dépouille est remise à son père. Elle est essentiellement constituée de son code de retour.

Lorsque le père est déjà mort, c'est le doyen qui a la charge de récupérer le code de retour, par exemple avec la méthode wait.

Niveau :      
Résumé : ferm

Ferm

Vous battez-vous toujours avec vos scripts shell pour configurer les firewall de vos serveurs ? Ne ramez plus, j'ai la solution : Ferm.

Pourquoi ferm ? Ben pourquoi pas ?

Je l'ai choisi car il ne fait qu'une chose (et le fait bien), il remplace vos scripts shell de lancement de firewall. Et c'est tout ! Pas d'interface graphique, pas d'assistance à création de règle, pas de gestion de votre serveur DHCP ...

Donc si votre machine de bureau sert de passerelle vers internet, ou si vous ne connaissez pas bien iptables, ce n'est probablement pas le meilleur outil. Par contre si vous avez l'habitude d'écrire des scripts shell pour gérer votre firewall, ferm est là pour vous simplifier la vie.

Configuration

Ferm génère des règles iptables à partir de son fichier de configuration. Il n'invente rien, il ne fait qu'écrire sous forme hiérarchique les règles iptables et vous permet d'utiliser des variable et des listes. Il faut donc les connaître un peu.

Petit exemple pour vous montrer comment gagner du temps (il se comprend tout seul) :

Niveau :      
Résumé : lvm snapshot

J'ai déjà fait des articles sur LVM. Aujourd'hui parlons de snapshot en ram et d'une nouveauté du noyau 2.6.33, le snapshot-merge.

Snapshot en RAM

Tout comme il est possible de faire un LV en RAM, il est possible de faire un snapshot en RAM.

Pour faire un LV (Logical Volume) en RAM : il suffit d'utiliser un ramdisk comme PV(Physical Volume).

$ pvcreate /dev/rd0
$ vgcreate myvg /dev/rd0
$ lvcreate -l 100%FREE -n mylv myvg

Pour faire un snapshot en RAM :

$ pvcreate /dev/rd0
$ vgextend myvg /dev/rd0
$ lvcreate -L 100M -s -n mysnapshot /dev/myvg/mylv

Mais pour quoi faire ? Pour la même chose qu'un livecd : transformer un périphérique en lecture seule en périphérique lecture-écriture qui perdra toutes ses modifications au prochain reboot.

Seul inconvénient, les ramdisk ont une taille prédéfinie au démarrage du noyau (ramdisk_size=).

Mais j'ai gardé le meilleur pour la suite.

Niveau :      
Résumé : bios, bootloader, noyau, init, rc

Je ne me souviens pas avoir fait un article complet sur le processus de boot. Il y en avait un partiel ici. En voici un !

BIOS

Le bios est le premier élément à être lancé, si on excepte l'appui sur le bouton ON et quelques autres détails. Celui-ci initialise le processeur ainsi qu'une partie du matériel, comme la carte vidéo ou le clavier.

Le bios est constitué d'une mémoire (rom ou flash) placée sur la carte mère.

Notez que quasiment tous les bios étant maintenant des flash il est possible de les mettre à jour, voire de les remplacer. Et justement un projet existe pour remplacer les bios propriétaires par des bios libres (comme Max): coreboot de son ancien nom linuxbios.

Le bios est configuré pour choisir un périphérique sur lequel booter. En général c'est le premier disque dur, mais cela peut aussi être une clé usb ou un lecteur disquette. Il est même possible de choisir au moment du boot.

Sur le périphérique en question, et à l'exception du lecteur CD qui a son protocole (el torito), le bios charge le premier secteur (512 octets), le met en RAM, et le lance.

Notez que le "BIOS" est spécifique aux PC, d'autres architectures ont des firmware EFI (Apple) ou des OpenBoot (Sun).

Bootloader

Dans ce premier secteur se trouve le bootloader (grub, lilo, silo, syslinux, mbr dos ...).

Le bootloader est découpé en plusieurs morceaux à cause de la limite des 512 octets. Sa première activité est de réussir à se charger complètement.

Celui de windows est assez simpliste, mais sous linux on en trouve avec plein de fonctionnalités sympa.

Une fois qu'il est prêt, il lit sa configuration puis choisit un périphérique et une partition où lire le noyau et éventuellement un initrd. Et enfin il passe la main au noyau en lui donnant quelques paramètres.

Niveau :      
Résumé :accton ; ac ; sa ; lastcomm

Le noyau linux fournit une fonctionnalité ancienne, mais parfois bien utile nommée process accounting. Pour ceux qui compilent leur noyau elle est disponible dans les options générales sous le nom "BSD process accounting".

Pour pouvoir en profiter sur votre système, il faut aussi disposer des commandes disponibles dans le paquet acct. Ces commandes sont peu nombreuses. La première est accton qui active ou désactive l'accounting sur le système. La plupart des distributions incluent un fichier dans init.d appelant cette commande au démarrage.

Une fois l'accounting activé, les données liées aux processus sont stockées dans /var/log/account/pacct (ou équivalent). Les autres commandes du paquets servent à lire ces données.

Les plus importantes sont sa et lastcomm. Notons tout de même ac qui donne le temps de connexion total des utilisateurs et last (en provenance d'un autre paquet) indiquant les dates de connexion des utilisateurs. Un système non GNU vous proposerait des commandes supplémentaires.

sa permet d'obtenir des statistiques sur le lancement des processus.

lastcomm permet d'obtenir une liste de commandes lancées par utilisateur.

Usage

lastcomm permet de surveiller l'activité utilisateur sur le système. On peut ainsi retrouver qui a fait quoi en cas de problème (si vous pouvez garantir le fichier de log bien sûr :-). Un BOFH peut même s'amuser à espionner en temps réel ses utilisateurs avec un watch -d.