Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Archive for October, 2008

Bonjour,

Ce site avance bien, je compte le faire évoluer un peu et pour cela je voudrais faire un petit sondage. Et ne je sais que vous pouvez participer puisque vous êtes venus nombreux pour Paul et Mickey.

Tout d'abord les titres, à 5 voix contre une (pour l'instant) je vais me résigner à mettre des titres plus conventionnels et donc plus facile à chercher. Je tenterai de mettre les jeux de mot débiles ailleurs. Êtes-vous d'accord ?

Je compte revoir un peu le design du site, si quelqu'un veut m'aider, qu'il n'hésite pas. Si vous avez des suggestions, c'est le moment, levez la main. Dans le même temps, je compte relire les articles et les trier, il se peut donc qu'il y ait une baisse d'activité visible pendant quelque temps.

C'est aussi le moment de se poser la question du contenu. On me reproche de faire assez peu d'articles pour les débutants (c'est aussi pour eux que j'ai commencé), mes deux prochains articles les cibleront donc un peu plus. Voulez-vous des articles plus simples, plus compliqués ? plutôt réseau, sysadmin, développement, hardware, sécurité ?

Autre question pour ceux qui suivent. Que pensez-vous de la notation des lignes de commande ? Actuellement j'utilise '#' pour les commentaires, '$' pour une ligne de commande et '>' pour les sorties. On me fait remarquer plusieurs choses, tout d'abord que ce n'est pas copier/collable, ensuite que sur les systèmes si '$' est dans le prompt utilisateur '#' est dans le prompt root. Il faudrait donc que je rende ma notation plus cohérente. Avez-vous une suggestion ?

Niveau :      
Résumé : ip_forward ; iptables -j MASQUERADE ; iptables -j DROP ; brctl ; ip

Routeur

Un routeur, c'est une machine qui renvoie les paquets qui ne lui sont pas destinés vers d'autres machines qui les accepteront. Faisons-en un sous linux :

$ echo 1 > /proc/sys/net/ipv4/all/ip_forward

Facile hein ! Maintenant linux (le noyau) renverra tous les paquets qu'il reçoit (au niveau ethernet) mais qui ne lui sont pas destinés (au niveau IP). Reste plus qu'à maintenir une table de routage (avec la commande "route", "ip route" ou avec un démon dédié comme quagga qui le gère dynamiquement).

NAT

Parfois la machine de départ utilise des IP qui n'ont pas le droit d'aller sur internet (c'est pratique pour communiquer en interne, mais c'est tout). Le routeur (la passerelle) doit donc traduire ces IP privées en IP publiques (en général il utilise la sienne). C'est le NAT. Les réseaux ip privées sont : 10.0.0.0/8 172.16.0.0/12 et 192.168.0.0/16

Pour activer le nat sur un linux, il faut déjà qu'il fasse routeur (voir ci dessus), puis on transforme les paquets avec netfilter (netfilter est le fltre du noyau, iptables est la commande pour le piloter) :

$ iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE

Firewall

Un firewall va examiner la couche IP et la couche TCP pour filtrer ce qui se passe. Il peut tout faire, couper, changer le paquet ... Tout ceci se fait avec iptables sous linux. C'est un peu complexe, donc voici simplement un exemple qui coupe un utilisateur :

$ iptables -A FORWARD -s 10.0.0.12 -j DROP

Pont

Un pont (bridge) relie 2 (ou plus) réseaux ethernet comme le ferait un switch. Pour faire un bridge sous linux on utilise la commande brctl.

# on crée un nouveau bridge nommé bridge0
$ brctl addbr bridge0
# on ajoute les cartes réseau au bridge (le bridge prend l'adresse mac de la première carte ajoutée)
$ brctl addif bridge0 eth0
$ brctl addif bridge0 eth1

Et voila, à partir de ce moment, les paquets sont bien retransmis sur le réseau, si un paquet arrive sur une interface, il est retransmis sur l'autre s'il y a lieu. Mais si on veut que l'ordinateur qui fait bridge soit aussi sur le réseau en question, il faut y ajouter quelques modifications :

# on désactive la pile ip sur les cartes du bridge
$ ip addr del 10.0.0.1/24 dev eth0
$ ip addr del 10.0.1.1/24 dev eth1
# et on l'active sur le bridge lui-même (représenté pare une carte réseau virtuelle)
$ ip addr add 10.0.0.1/24 dev bridge0

Réseaux multiples

La notion de réseau IP est décorrélé de la notion de réseau ethernet. Il est donc parfaitement possible d'avoir plusieurs réseaux IP sur le même réseau ethernet. Et cela se fait très simplement :

$ ip addr add 10.0.0.1/24 dev eth0
$ ip addr add 192.168.0.1/24 dev eth0

Tunnel

Un tunnel permet d'encapsuler un flux entre 2 machines dans un autre flux. Par exemple le tunnel ssh encapsule un flux tcp dans un flux ssh.

Faisons tunnel ip, avec le module gre du noyau :

# on crée un tunnel nommé tunnel0 
$ ip tunnel add tunnel0 mode gre remote 1.2.3.4
# ce tunnel est en fait une interface virtuelle qu'on configure
$ ip link set tunnel0 up
$ ip addr add 10.0.1.1 dev tunnel0
# un tunnel n'a que 2 bouts, on choisit de gérer le sous-réseau à la main
$ ip route add 10.0.1.2 dev tunnel0

N'oubliez pas qu'il faut faire la même chose à l'autre bout du tunnel (avec des ip inversée bien sûr) et vous avez maintenant une carte réseau sur chaque machine reliées par un câble virtuel.

Niveau :      
Résumé : linux

Imaginez que vous soyez un simple utilisateur (un compte dans une université par exemple), alors les joies de l'administration système vous sont interdites. Heureusement une bande de jeunes hippies a décidé de faire quelque chose contre nature, essayer de transformer le noyau en simple application qui tournerait dans l'espace utilisateur. Et ça a marché, le noyau est maintenant un processus comme les autres.

On peut donc faire tourner linux sur un système existant, théoriquement un bsd ou un solaris peut même faire l'affaire, on a même trouvé des fous pour porter linux sous windows (cherchez colinux, vous trouverez).

Le noyau

Si vous êtes sous debian prenez le paquet user-mode-linux, et si vous êtes fans de la compilation de noyau :

$ make menuconfig ARCH=um
$ make ARCH=um

Et voila, il suffit de lancer linux :

$ linux

Le système

Bon, tout n'est pas si simple, il faudra bien que vous ayez un système de fichier pour ce linux. Si vous n'êtes pas root, vous devrez le préparer sur une autre machine. Il vous faut faire une image disque, soit à partir d'une installation existante, soit une nouvelle installation (par exemple avec debootstrap) :

# récupérer un disque existant
$ dd if=/dev/sda1 of=/data/image.dd

# créer un nouveau disque
$ dd if=/dev/zero of=/data/image.dd bs=1M count=512
$ mke2fs -j /data/image.dd
$ mount -o loop /data/image.dd /mnt
$ debootstrap etch /mnt
$ umount /mnt

Maintenant que nous avons notre image, c'est parti :

$ linux ubd0=/data/image.dd

continue reading...

Niveau :      
Résumé : mysnapshot

Maintenant que vous savez comment fonctionne device-mapper, il est possible de compenser un certain manque de lvm à la main. Nous allons faire des snapshot de snapshot (merci à glandium pour la suggestion).

Voici 2 scripts permettant de faire cela. Ils s'utilisent de la manière suivante :

# En supposant que vous ayez déjà fait un premier snapshot avec lvm
# snapshot2 sera un snapshot de snapshot1
$ mysnapshot '-L 1G' vg0 snapshot1 snapshot2

# Pour supprimer le snapshot précédemment créé
$ mysnapshotrm vg0 snapshot2

Prenez ces scripts avec quelques pincettes puisque bien que testés sur mes machines, ils n'est pas garanti qu'ils fassent tout ce que vous vouliez. Par exemple, il permet d'enchaîner les snapshot, mais tel quel il va vous poser quelques problèmes pour faire des arbres de snapshot (plusieurs fois un snapshot d'un même snapshot), dans ce cas ... à vous de bosser.

Attention : contrairement à lvm, ces snapshots ne sont pas automatiquement mis en place au boot.

Un petit schéma du principe de fonctionnement des snapshots, peut-être un peu plus clair que le précédent pour ceux qui connaissent device-mapper (attention, les noms ne correspondent pas totalement à ceux du script).

lvm_snapshot2.png

Ce schéma permet aussi d'expliquer quelque chose que j'ai oublié de dire lors de l'article précédent : bien qu'il n'y ait pas de différence fondamentale entre l'orginal et le snapshot, le snapshot est le périphérique qui aura les meilleures performances en écriture.


continue reading...

Niveau :      
Résumé : urlencode ; punycode ; htmlencode ; quoted-printable

Comme je vous l'ai déjà dit, l'utf8 est un encodage utilisé pour la table de caractère unicode.

Il existe un certain nombre d'autres encodages écrits pour répondre à des contraintes particulières, la plupart du temps, il s'agit d'éviter certains codes déjà utilisés dans une application. Après le base 64 nous allons voir des encodages pour les url, pour le html et pour les emails.

Remarquez que chacun de ces encodages peut encoder plusieurs tables de caractère et que celle-ci n'est pas toujours spécifiée.

Url encode

L'encodage pour les urls a pour but d'éviter un certains nombre de caractères qui posent problème dans la manipulation et le parsing d'url , c'est à dire entre autre : l'espace, /, :, ?, # et les caractères non ascii

Cet encodage concerne toute l'url à l'exception du nom de domaine qui lui utilise le punycode lorsque c'est un idn (com pliqué hein !).

L'encodage d'url ne précise pas la table encodée, ce qui veut dire que cela peut aussi bien être de l'unicode que de l'iso8859-1 ou une autre table (elle doit être compatible ascii puisque certains caractères ascii sont définis dans la norme). Le type est souvent implicite et dépend de la table utilisée dans les pages précédant ou contenant le lien.

La méthode est assez simple, on remplace tous les caractères qu'on veut transformer en %XX où XX est le code hexadécimal du caractère. On est autorisé à encoder n'importe quel caractère de cette façon. Les caractères suivants devraient être encodés uniquement dans le cas où ne servent pas de séparateur :

!  *  '  (  )  ;  :  @  &  =  +  $  ,  /  ?  %  #  [  ]

.. ainsi que les caractères non alphanumériques (à quelques exceptions près).

Pour les détails, suivez la RFC, cette dernière spécifie (c'est récent) que la table utilisée devrait être utf8 (et non pas unicode).


continue reading...

Aujourd'hui j'inaugure une nouvelle catégorie : "polémique".

En effet, on va parler de sujets qui fâchent et non il ne s'agit pas de emacs ni de vi. Il s'agit de Linux avec un grand L comme dans Torvalds.

Mon OS c'est Linux, arrêtez de l'appeler GNU/Linux, ça fait bien longtemps que l'os n'est plus vraiment gnu. Voyons rapidement ce qui est installé sur mon poste :

$ dpkg -l
> xorg
> kde
> firefox
> openoffice
> apache, bind, postfix
> zsh, ksh, vim, irssi, ssh
> perl, python, ruby, php
> bsd{utils,mainutils} openntp openinetd

> gcc
> bash
> libc
> emacs

Alors oui il y a des outils GNU, mais devrais-je appeler mon OS GNU/Linux/KDE/firefox/bsd/OOo ? Non, arrêtons tout de suite le délire, mon os s'appelle Debian.

Mais alors pourquoi l'appeler linux ? Tout simplement pour des facilités de communication. Tout comme avant on disait "j'utilise unix". Linux est plus qu'un noyau, Linux est une marque. Derrière cette marque, il y a beaucoup plus qu'une technologie, il y a un marketing, il y a un moyen de communication, il y a un vocabulaire.

Tout comme on dit du nutella pour de la pâte à tartiner, un frigidaire pour un réfrigérateur, un kleenex pour un mouchoir en papier, un coca cola pour une boisson carbonatée gazeuse, on dit linux pour un os compatible posix utilisant le noyau linux et de nombreux outils plus ou moins standard autour.

Je revendique l'utilisation du terme linux car il est simple à lire, à orthographier et à prononcer (dictée : demandez à votre mère d'orthographier gnoulinuxkadéheux). Oui, nous avons besoin d'un terme unique qui représente ce que nous voulons dire et il existe déjà, il est déjà utilisé et des personnes ne connaissant pas la technique le comprennent.

On voudrait donc ajouter un terme illisible représentant moins de 20% du système dans un nom qui ne représente déjà pas l'os en entier, tout ça pour une satisfaire l'ego d'un hackeur malgré tout infiniment respectable pour son activité.

Longue vie à linux le système polymorphe que vous cuisinerez à votre sauce.

Niveau :      
Résumé : make menuconfig ; make ; make-kpkg

Un bon sysadmin doit savoir recompiler son noyau, et ce pour plusieurs raisons. Tout d'abord, c'est l'occasion de passer en revue les nouveautés (support d'un nouveau driver, changement d'architecture ...), c'est aussi comme ça qu'on peut ajouter les patchs dont on a besoin. Ensuite cela peut permettre de se passer de l'initrd (et donc de gagner une étape au boot) et enfin cela permet de faire des noyaux purement monolithiques si l'on veut renforcer la sécurité d'équipements critiques.

Avant de compiler un noyau, il faut le configurer. Cette étape est longue, très longue, surtout pour une première fois. Mais c'est aussi la plus intéressante. Je vais donc vous la présenter en long, en large, et surtout en travers. Si cela vous parait lourd, ne partez pas, sautez quelques étapes et revenez-y plus tard.

La base

Commençons par récupérer les sources du noyau. Personnellement je prends les sources officielles de Linus, simples à trouver :

# usuellement on se met dans /usr/src, mais ça n'a rien d'obligatoire
$ lftp ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.XXX.tar.bz2
# qu'on va décompresser
$ tar xfj linux-2.6.XXX.tar.bz2
$ cd linux-2.6.XXX

# les debianeux peuvent aussi avoir les sources patchés debian
$ apt-get install linux-source-2.6.XX

Nous allons récupérer la configuration actuelle du noyau pour partir sur des bases saines et ne pas avoir peur de tout casser si on saute une étape. Le fichier de configuration s'appelle .config

# la meilleur méthode si disponible : lire la configuration en live
$ zcat/proc/config.gz > .config
# sinon récupérer un ancien fichier
$ cp ../linux-2.6.XX-1/.config .
# ou celui fourni par la distrib
$ cp /boot/config-2.6.XX-1 .config

Lançons la configuration :

# en mode texte (il vous faut libncurses5-dev)
$ make menuconfig
# en mode graphique (qvec qt depuis quelque temps)
$ make xconfig 
# ou avec gtk
$ make gconfig

continue reading...