Linux Attitude

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.

Bookmarks:

Niveau :
Résumé : slirp

Si vous n'êtes pas admin de la machine sur laquelle vous êtes (université ?), mais que vous voudriez partager votre connexion, par exemple pour une machine virtuelle ou pour des amis qui voudraient emprunter votre IP ... Il vous faut du NAT (a moins que vous vous contentiez d'un simple tunnel).

Problème : vous ne pouvez pas le mettre en place puisque vous n'êtes pas admin sur la machine qui partage la connexion.
Solution : slirp.

Hé oui c'est tout simple, slirp décapsule du PPP pour l'injecter dans de une socket normale et donc fait l'équivalent du NAT. Mais avec quelques limitations, on ne peut pas faire passer n'importe quel paquet (genre ping) depuis l'espace utilisateur, malgré tout c'est largement suffisant.

Le serveur de NAT (enfin le routeur quoi)

Bon c'est pas si simple mais presque.

Slirp est une commande qui utilise le l'entrée et sortie standard pour communiquer ce qui fait que si on veut l'utiliser à distance il faut le connecter à un "listener", ici nous allons utiliser socat, mais si vous voulez un tunnel chiffré, utilisez stunnel.

Donc vous avez besoin de socat et slirp sur la machine où vous êtes simple utilisateur. Si vous ne les avez pas recompilez les vous avez le droit. Si vous n'avez pas de compilateur copiez-lez depuis une autre machine, si cela ne fonctionne pas, recompilez les chez-vous en statique ... enfin vous êtes grands que diable, ne me posez pas cette question !

Il vous faut un fichier de configuration minimaliste pour slirp (à mettre dans ~/.sliprc) :

ppp
asyncmap 0

Puis lancez le service genre sur le port 2000 (fullbolt = pas de limitation de vitesse) :

$ socat -s tcp4-listen:2000,fork system:/usr/bin/slirp-fullbolt

Bookmarks:

Niveau :
Résumé : script, scriptreplay

Vous voulez préparer un cours ou une présentation à base de ligne de commande, espionner quelqu'un ... ?

Ça vous ennuie de taper les commandes en direct ?

J'ai la solution : script.

Script

Script est une commande qui crée un faux terminal virtuel et duplique tout ce qui s'y passe dans un fichier typescript.

Exemple :

$ script
# on est ici dans un terminal
$ echo coucou
> coucou
$ exit
# on est sorti du terminal
$ cat typescript
> $ echo coucou
> coucou
> $ exit

Dit comme ça, ça ne semble pas très utiles mais 2 choses vont tout changer. La première c'est que script fait un vrai terminal virtuel et pas seulement une redirection, ce qui veut dire que contrairement aux pipe (|) et autres redirections (>), il est capable d'enregistrer ce qui va sur le terminal (Il est important de savoir faire la différence entre le terminal et stdout).

Exemple : la commande time. Cette commande écrit le temps d'exécution directement sur le terminal et pas dans la sortie standard, on ne peut donc pas la récupérer facilement, script le peut.

Bookmarks:

Niveau :
Résumé : apache, virtualhost, configuration

Que se passe-t-il lorsqu'apache reçoit une requête ?

La question peut paraître anodine jusqu'à ce qu'on ait à écrire un fichier de configuration un peu complexe. Il faut alors avoir une idée de l'ordre dans lequel les opérations sont effectuées.

Commençons par un aperçu rapide :
-> récupération du virtualhost concerné
-> récupération de la partie requête
-> rewrite rules et redirect
-> alias et réécriture de la requête nom de fichier
-> traitement par <directory>, <directorymatch>, .htaccess, <files>, <filesmatch>, <location> et <locationmatch>
-> droits d'accès
-> traitement du fichier en fonction de son type.

Ouf c'est long ! Comme cet article, alors prenez votre temps ...

Traitement de l'URL

Pour chaque requête, apache relit sa configuration (en fait il récupère la version parsée en mémoire). Ensuite il parcourt les éléments dans l'ordre, les compile en une seule conf puis la utilise cette conf spécifiquement pour cette requête.

Virtualhost

Bon ca c'est facile, on se base sur les ServerName définis dans les <virtualhost>. Si on n'en trouve pas, on cherche dans les ServerAlias, si on n'en trouve pas on cherche encore, mais cette fois avec les wildcard (*.mondomaine.com), si on ne trouve toujours pas, on prend le premier </virtualhost><virtualhost> qui a été dacléré. Et enfin s'il n'y a pas de virtualhost, on prend le DocumentRoot défini à la racine du serveur apache lui-même.

Voilà on a trouvé le virtualhost, maintenant on prend la requête, qui est la partie située à droite de l'URL après l'hôte et le port.

Bookmarks:

Niveau :
Résumé : TCP + RTT + window size = debit

Si je me connecte au réseau local gigabit, que je fais un transfert de fichier ... je n'arrive pas à dépasser 200Mb/s ! Vous rendez-vous compte que c'est normal ?

Vous allez me dire que je ne suis pas doué, mais ce n'est pas moi, ce sont les lois de la physique.

Bon puisque nous somme dans un cas particulier je m'explique.

Temps de réponse

Le débit a beau toujours augmenter, il y a quelque chose qui s'améliore beaucoup moins vite : le temps de réponse. Pour une bonne raison, l'information a une vitesse limite, celle de la lumière. La limite est un peu inférieure sur une fibre optique et encore inférieure sur un câble cuivre.

De plus il faut une certaine électronique pour traiter tous ces paquets et ce débit. Du coup la traversée de switchs et de firewall en fout un coup à la latence. Et pourtant le débit ne change quasiment pas.

Tout ceci se voit avec la commande ping. Si vous lancez un ping sur la machine d'à coté, vous constatez un temps de réponse de l'ordre de la milliseconde.

Par exemple :

PING mamachine (10.0.0.0.1) 56(84) bytes of data.
64 bytes from mamachine (10.0.0.0.1): icmp_seq=1 ttl=61 time=1.16 ms

C'est le temps qu'il a fallu pour créer le paquet ping, l'envoyer à travers le switch, le réceptionner, répondre, repasser dans le switch, lire la réponse. Donc il faut la diviser par deux pour avoir un ordre de grandeur du temps de transfert du paquet.

Pour une machine sur un autre réseau c'est plus dans les 20ms voire 100ms.

Dans cette histoire les plus gros temps de latence dépendent de votre infrastructure, si vous êtes sur une fibre de 100km c'est elle qui contribuera à la latence, si vous êtes sur un réseau local c'est plus le temps de traitement par la carte réseau et le noyau, et s'il y a plusieurs switchs ou un routeurs c'est l'électronique des ces appareils.

Bookmarks:

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) :

Bookmarks:

Niveau :
Résumé : ssh qemu-system -hda /dev/sda

Supposons que vous administriez une machine distante. Vous n'avez pas d'accès physique à cette machine. C'est ennuyant puisque vous venez de changer la configuration de votre bootloader.

Comment faire pour rebooter tout en garantissant que ca va marcher ?

Hé bien j'ai la solution qui vous permettra de tester ce boot avant de rebooter : qemu.

Préparer les disques

Il nous faut des disques en lecture seule pour éviter que le boot de la machine virtuelle n'écrive sur un disque en cours d'utilisation. Donc pour chacun de vos disques physique :

$ cp -a /dev/sda /root/sda
$ chmod 440 /root/sda

Ainsi nous avons des disques garantis en lecture seule.

Bookmarks: