Différences entre les pages « SPAM » et « UserModeLinux »

De Cliss XXI
(Différence entre les pages)
Sauter à la navigation Sauter à la recherche
imported>SylvainBeucler
m (Spam: diverses précisions et nouveaux problèmes)
 
imported>SylvainBeucler
 
Ligne 1 : Ligne 1 :
==Principes et problèmes du SPAM==
+
== Compilation du noyau utilisateur ==
  
Le mail circule via Internet via le protocole protocole SMTP et en se basant sur IP et DNS.
+
C'est très simple: on compile le noyau Linux avec le paramètre <code>ARCH=um</code> ''pour chaque commande''.
  
Le problème: il n'y a aucune identification, et envoyer du courriel et pour ainsi dire ''gratuit'', par conséquent toute boîte au lettre peut être remplie de spam par n'importe qui, sans la contrainte de coût du courrier postal.
+
wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.13.tar.bz2
 +
tar xjf linux-2.6.17.13.tar.bz2
 +
cd linux-2.6.17.13
  
Depuis plusieurs années, à mesure que ce phénomène gagne en puissance, diverses solutions ont été mises en oeuvre. Pour résumé aucune ne fonctionne vraiment bien, et aucune n'est réellement sans douleur.
+
make defconfig ARCH=um
 +
make xconfig ARCH=um # facultatif; pensez à activer HOSTFS si besoin
 +
make ARCH=um
 +
strip linux
  
On cherchera, au passage, des solutions qui permettront de filtrer à cause quasi-sûr un spam, de manière à réaliser ce filtrage en amont, épargnant cette peine à l'utilisateur de notre service de courriel, et d'autre part afin d'éviter de devoir vérifier ce filtrage manuellement, au cas où le filtre aurait filtré un bon message ("false-positive").
+
Cf. [http://user-mode-linux.sourceforge.net/new/source.html Building from source] chez UML.
  
On gardera enfin à l'esprit tous les types d'utilisation de SMTP, notamment les listes de diffusion qui sont parfois jugées incompatibles avec les solutions proposées.
+
== Construction du système de base ==
  
 +
On se propose de construire et de lancer un système UML sans aucun accès root.
  
==Principes de combat==
+
Vraisemblablement, ce n'est pas possible facilement. Cela est dû au manque d'outil en mode utilisateur pour travailler directement sur des systèmes de fichiers ext3.
  
L'évolution du spam au cours des dernières année fait penser à la lutte contre les parasites: chaque année on crée de nouveau pesticide pour l'éradiquer, et chaque année une nouvelle forme plus résistante fait son apparition. Plus on la combat sévèrement, plus la forme suivante sera résistante.
+
=== Tentative 1 ===
  
Dans ces conditions deux solutions sont envisigeables:
+
Essayons de créer un système complet, sans faire d'image, et en possédant tous les fichiers:
* accepter la fatalité de l'existence du problème, et ne lutter qu'à un niveau minimum
 
* être sûr de détruire complètement toute souche de l'espèce (si tant est qu'il n'y a pas de réservoir)
 
  
Individuellement les solutions contre le spam tendent à vouloir définitement régler le problème du spam. Soit elles n'y parviennent que partiellement (et les spammers d'adaptent), soit elles filtrent des courriels légitimes en quantité non-négligeable, soit elles proposent des solutions qui à long terme éradiquent non seulement les spammeurs mais également un certains nombre de libertés aux particuliers et/ou aux PME/PMI - sans nécessairement garantir la fin de la publicité dite "légale".
+
La dernière version de debootstrap propose une variante ''fakechroot'' qui permet de l'utiliser sans accès root:
 +
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:$PATH # pour trouver la commande 'chroot'
 +
fakechroot /usr/sbin/debootstrap --variant=fakechroot sarge sarge-uml/ http://localhost/mirrors/debian
 +
/usr/src/linux-2.6.17.13/linux  root=/dev/root rootflags=/home/sylvain/tests/uml/debian/sarge-uml/ rootfstype=hostfs
  
Cependant certaines solutions peuvent être intégrées à un système de "score" tel que SpamAssassin. À la place d'éradiquer de nombreux messages légitimes, la solution fournit une heuristique qui combinées avec d'autres méthodes tendent à cerner relativement précisemment le SPAM, sans garantie toutefois.
+
Résultat: cela ne fonctionne pas, à mon avis parce que dans ce cas précis sarge-uml/dev est un lien symbolique vers /dev.
  
 +
=== Tentative 2 ===
  
==Les bases==
+
Essayons à partir d'une image UML déjà opérationnelle.
  
La [http://www.hashcash.org/faq/index.fr.php FAQ] de Hashcash est bien faite et aborde les points du point de vue d'un utilisateur soucieux de sa boîte aux lettres mais aussi de ses libertés.
+
[http://packages.debian.org/unstable/utils/rootstrap rootstrap] fonctionne apparemment sur ce principe.
 +
Je n'ai pas réussi mais je n'ai pas beaucoup cherché.
  
[http://en.wikipedia.org/wiki/Stopping_e-mail_abuse Wikipedia] décrit (en anglais) de manière générale un certain nombre de solution.
+
=== En mode root ===
  
 +
Faute de mieux, utilisons sudo:
  
==Listes noires==
+
mkdir loop/
 +
# image de 1Go, à trous (espace disque progressif)
 +
dd if=/dev/null of=image count=0 bs=1G seek=1
 +
# on formatte en ext3
 +
/sbin/mkfs.ext3 -F image
 +
 +
sudo mount image loop/ -o loop
 +
sudo debootstrap sarge loop/ http://192.168.1.60/mirrors/debian
 +
 +
# configuration de la console:
 +
sudo grep -v tty loop/etc/inittab > inittab.work
 +
sudo echo "1:2345:respawn:/sbin/getty 38400 console linux" >> inittab.work
 +
sudo mv inittab.work loop/etc/inittab
 +
 +
# configuration réseau:
 +
cat <<'EOF' > interfaces.work
 +
auto lo
 +
iface lo inet loopback
 +
EOF
 +
sudo mv interfaces.work loop/etc/network/interfaces
 +
 +
# fake mtab and fstab
 +
cat <<'EOF' > fstab.work
 +
proc            /proc          proc    defaults        0 0
 +
/dev/ubda      /              auto    defaults,errors=remount-ro 0 1
 +
EOF
 +
sudo mv fstab.work loop/etc/fstab
 +
 +
sudo umount loop/
  
La solution qui vient rapidement à l'esprit est de mettre des IPs sur liste noire. Le principal défaut de cette solution est de se baser sur l'IP - utiliser une adresse IP de cette manière est une erreur qu'on ne fait logiquement plus depuis les klines IRC:
+
=== Optimiser la taille de l'image pour la distribuer ===
  
* Cela estime que toutes les IPs sont fixes. Je ne serais pas surpris si la majorité des IPs étaient plutôt dynamiques. Le listage d'adresses IP dynamiques, donc un emplacement plutôt que l'expéditeur à proprement parler, interdit aux particuliers d'utiliser leur propre serveur SMTP. Le fait qu'il s'agisse d'une pratique effectivement peu répandue 1) n'en est pas moins intéressant 2) contribue de manière importante à la rareté de cette pratique.
+
Une image UML contient souvent des zones vides, il n'y a pas encore de fichiers.  
* Une adresse IP peut représenter plusieurs personnes (adresse IP dynamique), mais une personne peut également être représentée par plusieurs adresses IP: répartition de charge.
 
* Le listage d'adresses IP est souvent erroné et long à rectifier.
 
  
L'utilisation de l'IP reste une solution qui fonctionne raisonnablement en pratique, donc intégrable dans un système de score, pourvu que le poids qui est donné à cette méthode ne soit pas immédiatement déterminant.
+
L'image ci-dessus réserve 1Go mais n'en occupe que 230Mo grâce à la création d'image "à trous" (''sparse'' en anglais).
  
L'attrait d'utiliser directement des listes noires au moment de la connexion est le gain en temps processeur pour traiter chaque message. Le fort taux d'erreur devrait cependant encourager à éviter cette solution, et préférer l'ajout de nouvelles machines pour traiter le courriel.
+
$ ls -lh image
 +
-rw-r--r--  1 sylvain sylvain 1,0G 2006-09-18 15:55 image
 +
$ du -sh image
 +
234M    image
  
 +
<code>df -h</code> dans UML indique une utilisation de 178Mo, donc on doit pouvoir encore améliorer (comment?). Éviter <code>e2defrag</code>, qui non content d'augmenter globalement l'espace disque utilisé peut également introduire des erreurs dans l'image.
  
==RFC-compliance==
+
D'autres méthodes (dd sur /dev/zero par exemple) n'en tiennent pas compte.
  
D'autres solutions confondent envoi de spam et non-respect des RFC décrivant SMTP. La plupart du temps le respect de SMTP ne présume en rien de l'origine du message (voir plutôt graylisting), mais a eu un certain succès du temps où les logiciels utilisés par les spammeurs étaient rudimentaires.
 
  
Aujourd'hui on peut se demander si spammeurs n'ont pas des systèmes plus proche des RFCs que ceux des expéditeurs légitimes. L'application aveugle des RFCs n'est pas nécessairement une bonne chose, soit dit en passant. (TODO: un lien sur la citation décrivant un système DNS parfaitement aux normes mais par conséquent non distribué)
+
Pour optimiser une image "pleine":
 +
cp --sparse=always image image.sparse
  
 +
Pour envoyer une image par le réseau en respectant les trous:
 +
tar cSf image.tar image # S pour "sparse"
  
==Authentification==
+
== Réseau ==
  
SMTP est un protocole sans authentification - une approche est donc de corriger ce "défaut". Le courriel peut donc être identifié à l'aide des solutions suivantes, mais l'identification d'une base d'utilisateur de potentiellement 8 milliards d'individus * une infinité de boîtes aux lettres par personnes ne permet pas directement d'affirmer quoi que ce soit sur le contenu du message. On notera enfin qu'une entreprise utilisera en général la même adresse pour communiquer à ses clients à la fois des informations cruciales (notification d'un service arrivant à expiration, mots de passe...) et du spam (publicités en tout genre).
+
Imaginez un câble virtuel qui relie la machine hôte et la machine UML, une carte carte réseau virtuelle à chaque bout. Chaque carte a une adresse IP, mais comme sur un réseau classique, les deux cartes ne doivent pas avoir la même adresse.
  
Ces méthodes sont appuyées par de grande entreprise qui cherchent plus à éradiquer le spam illégal que le spam tout court. Il n'y a pas, à proprement parler, de spam légal: aucune personne sensée ne souhaite recevoir du spam (ou de la publicité, ou de l'information client, qu'importe le nom que l'on lui donne), et un spam reste un spam quels que soient son origine et son mode de transmission.
+
=== Mode root avec tuntap ===
  
===SPF===
+
host# sudo /usr/src/linux ubda=sarge-debootstrap eth0=tuntap,,,192.168.1.101
  
SPF propose une idée intéressante d'authentifier toujours au niveau IP mais en passant par un champ DNS qui indique quels noms de machine peuvent envoyer le courriel d'un domaine donné. Cela permet a priori les serveurs SMTP des particuliers, pourvu d'utiliser un service de DNS dynamiques.
+
Notez les messages d'UML indiquant la mise en place d'une interface tuntap <code>tap0</code>, une route pour accéder à la machine virtuelle, et un partage de connexion pour que la machine virtuelle puisse accéder au réseau extérieur.
  
Ceci permet dans un premier temps non pas de savoir si un message est ou non du spam, mais de détecter s'il a été envoyé par le possesseur du domaine. On peut donc automatiquement, avec un faible temps de traitement, éliminer tous les messages ''forged'' / falsifié d'un domaine utilisant SPF.
+
Puis dans UML:
  
Les spammers peuvent eux aussi utiliser SPF. Si tout le monde est sous SPF, alors on est logiquement sûr de la provenance de chaque message, mais en aucun cas de sa teneur spam/non-spam. Les ennuis commencent ici: la base SPF donnerait naissance à un groupe de domaines "reconnus", et les nouveaux arrivants seraient suspectés d'être des spammeurs par défaut, devant alors négocier l'acceptation de leur courrier soit par l'age de leur domaine, soit en payant un des membres du groupe qu'il lui apporte son soutien.
+
uml# ifconfig eth0 192.168.1.201
 +
 +
=== Mode semi-root avec tuntap ===
  
La composition de ce groupe initial est critique; les [http://www.openspf.org/aspen.html suggestions] incluent par exemple les entreprise Fortune 2000, et les exemples données impliquent souvent amazon.com ou aol.com - ce qui est discutable, ces entreprises envoyant certainement plus de messages de publicité que l'ensemble des sites persos de l'Internet.
+
Pour utiliser tuntap, il faut créer à l'avance (et en mode root) une interface tap0 et lui assigner une adresse IP.  
  
Cette organisation élèverait également la barrière d'entrée pour les entreprises nouvelles sur Internet.
+
# tunctl -u sylvain
 +
Set 'tap0' persistent and owned by uid 1000
  
La [http://www.openspf.org/faq.html#churn FAQ] du site mentionne fièrement que le système de mail passe d'une présomption d'innocence à une présomption de culpabilité, ce qui devrait suffire pour rendre l'approche discutable.
+
Puis il faut donner des droits aux utilisateurs non-privilégiés d'utiliser tuntap (en mode root aussi):
  
 +
chmod 666 /dev/net/tun
  
SPF n'est pas nécessairement mauvais en soi (mettre fin aux courriels anonymes), mais le futur qu'il nous laisse entrevoir n'est pas nécessairement enviable au présent.
+
C'est une solution efficace mais qui nécessite plusieurs étapes de préconfiguration en mode root, accompagné de permissions lâches sur tuntap.
  
  
==Graylisting==
+
=== Mode utilisateur avec tuntap (2) ===
  
(littéralement: liste grise)
+
Mettre l'utilisateur concerné dans le groupe <code>uml-net</code>. Ce groupe a accès au programme setuid <code>/usr/lib/uml/uml_net</code>, qui peut lancer et configurer des interfaces tuntap. La sécurité du procédé n'est pas grande (l'utilisateur peut créer de nouvelles interfaces réseau et perturber iptables par exemple), mais est facile à mettre en place.
  
Il s'agit apparemment d'un [http://projects.puremagic.com/greylisting/ principe] général étudiant les différence entre les méthodes d'envoi des spammeurs et celles des utilisateurs légitimes.
+
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=tuntap,,,10.10.10.10
 +
uml# ifconfig eth0 10.10.10.11
 +
uml# route add default gw 10.10.10.10
  
Une [http://greylisting.org/ proposition] en particulier semble attirer l'attention et s'appuie sur le fait que les spammeurs n'envoie souvent un courriel qu'une seule fois, même si le serveur distant demande de réessayer plus tard. La technique est donc de mémoriser (adresse IP + adresse d'envoi (à vérifier)) et de n'accepter un envoi qu'au bout de N connexions ou N secondes/minutes/heures.
+
Note: la configuration automatique côté hôte nécessite [http://packages.debian.org/unstable/otherosfs/uml-utilities uml_net] (partage de connexion, route vers la machine UML...).
  
Et si les spammeurs s'adaptent? Cela leur coûtera plus cher, d'une part, et surtout on disposera d'un délai appréciable avant l'acceptation du mail, permettant de mettre
+
=== Mode utilisateur avec slirp ===
  
 +
Lancer UML avec une interface slirp, en utilisant le binaire 'fullbolt' (qui s'affranchit de la limitation débit de 10ko/s dans slirp 'classique'):
  
Des personnes enthousiasmes parlent de résultats miraculeux. Cependant ce filtrage s'effectue avant le transfert du message proprement dit. Il n'est pas possible de tester son efficacité. Le système peut être tourné en dérision: rejeter tous les mails sans exception sera également miraculeux, car aucun spam ne sera délivré - mais on ne sait effectivement pas combien de mails légitimes ont été ainsi manqués.
+
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=slirp,,/usr/bin/slirp-fullbolt
  
D'autres personnes critiquent l'utilisation d'un code d'erreur (demandant de réessayer plus tard) pour un autre but que celui spécifié dans le protocole.
+
Dans UML, quelques étapes spécifiques à slirp sont nécessaires:
  
 +
# Configurer l'interface sur 10.2.0.15 (IP de choix pour slirp)
 +
ifconfig eth0 10.2.0.15
 +
# Utiliser la redirection DNS 10.0.2.3
 +
echo "nameserver 10.0.2.3" > /etc/resolv.conf
 +
# Ajouter une route par défaut vers eth0:
 +
route add default dev eth0
  
En pratique, on lit que certains logiciels (certaines version de Lotus Notes par exemple) ne gère par ce code correctement et considère l'échec d'envoi comme définitif. D'autres services utilisent de la répartition de charge et ne présentent pas toujours la même adresse IP d'origine, même s'il s'agit qu'envoyer le même e-mail.
+
Note: <code>ping</code> ne fonctionne pas, car il nécessite un accès root (sur l'hôte, ping est d'ailleurs souvent setuid).
  
La solution présentée pour ce 'bug' est nettement plus discutable puisqu'elle fait intervenir une [http://greylisting.org/whitelisting.shtml liste blanche] contenant par exemple les serveur de Yahoo. Il n'y a pas vraiment de raison de faire ainsi confiance aux utilisateurs d'un ISP, ni à l'ISP lui même. D'un autre côté, on peut être à peu près sûr que ces adresses IP ne seront pas utilisées pour envoyer du courriel via mass-mailing - sauf IP spoofing.
+
=== /etc/network/interfaces ===
  
 +
Voici comment configurer automatiquement le réseau au démarrage d'UML, dans son fichier <code>interfaces</code>:
  
L'avis ''en cours'' de Sylvain est que cette technique, un peu trop manichéenne à son goût, pourrait peut-être s'avérer utile à son niveau le plus simple, disons accepter au 2e essai, et sans liste blanche.  
+
auto lo
 +
iface lo inet loopback
 +
 +
auto eth0
 +
iface eth0 inet static
 +
 +
# eth0=tuntap,,,10.10.10.1
 +
#  address 10.10.10.10
 +
#  netmask 255.0.0.0
 +
#  gateway 10.10.10.1
 +
 +
# eth0=slirp,,/usr/bin/slirp-fullbolt
 +
  address 10.2.0.15
 +
  netmask 255.0.0.0
 +
  dns-nameservers 10.0.2.3
 +
  up route add default eth0
  
 +
(dns-nameservers nécessite le paquet ''resolvconf'')
  
==Filtres Bayesien naïfs==
+
Autre solution pour gérer automatiquement les DNS: installez un serveur DNS dans l'UML, et évitez ainsi de vous faire suer à déterminer ceux de l'hôte. In-dé-pen-dan-ce ;) À moins que vous n'ayez besoin du serveur DNS de votre réseau interne.
  
=== Articles explicatifs ===
+
== Liens ==
  
La série d'articles enthousiasmes de Paul Graham sur le sujet est assez intéressante. Ce ne sont pas les premiers sur le sujet, mais il s'agit des plus connus:
+
* [http://user-mode-linux.sourceforge.net/new/ The User-mode Linux Kernel Home Page]: lien direct vers la nouvelle version du site - on s'y retrouve mieux
* http://paulgraham.com/spam.html
+
* [http://eggdrop.ch/texts/uml/ Running Debian inside of Debian with User-Mode Linux]
* http://paulgraham.com/spamfaq.html
+
* [http://www.metz.supelec.fr/metz/personnel/galtier/PagesPerso/TutorielUML/index.html Tutoriel User Mode Linux]: avec introduction à SKAS et réseau
* http://paulgraham.com/better.html
 
* http://paulgraham.com/wfks.html : Will filters kill spam? Questions/réponses sur les limites de l'approche.
 
* http://paulgraham.com/falsepositives.html
 
  
Lire aussi le fonctionnement de la commande [http://spamassassin.apache.org/full/3.0.x/dist/doc/sa-learn.html sa-learn] de SpamAssassin, avec une introduction générale et vaste.
+
* [http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-6.html#ss6.11 Slirp] dans le UML HOWTO.
  
=== Expérience personnelle (incomplète) ===
+
== Dépannage ==
  
J'ai testé cette solution il y a quelques temps avec POPFile et SpamBayes, avec de ennuis techniques (POPFile s'est mis à marquer tous les mails comme spam, et SpamBayes n'arrivait pas en mode proxy à se récupérer plusieurs comptes chez le même ISP, et pas d'aide sur la mailing list). Il faudrait donc mieux réessayer.
+
Kernel panic - not syncing: start_userspace : expected SIGSTOP, got status = 256
  
=== Équilibre des différentes corps de messages ===
+
Cf. http://www.mail-archive.com/user-mode-linux-devel@lists.sourceforge.net/msg03414.html
  
À noter cependant que dans tous ces tests où des résultats encore une fois miraculeux sont présentés, les nombres de messages spam et ham sont équilibrés. En pratique, une nouvelle adresse recevra peu de spam, et pour ma part j'en reçois plus de 75% (j'ai beaucoup de vieilles adresses). D'autres techniques de filtrages pourraient être utilisées pour rétablir l'équilibre (par exemple, les messages auxquels SpamAssassin donne un score très élevé).
+
Votre noyau (hôte) est, si j'ai bien compris, mal configuré. Recompilez-le ou utilisez-en un autre.
 
 
=== Ciblage ===
 
 
 
Les filtres bayesiens naïfs réalisent des statistiques sur le contenu des courriers reçus, et sont donc d'autant plus efficaces que le contenu analysé est ciblé. Réaliser des statistiques avec SpamAssassin::Bayes sur l'ensemble du courriel d'un domaine n'est probablement pas une bonne idée, à moins que l'ensemble des correspondants d'un domaine traitent des courriers très similaires (notamment, uniquement professionnels). Creuser comment fournir un dossier spam par utilisateur.
 
 
 
=== Apprentissage ===
 
 
 
Autre problème: corriger les erreurs.
 
* D'une part il faut vérifier de temps à autre les messages du dossier spam et y récupérer les faux positifs
 
* D'autre part il faut déterminer une stratégie d'apprentissage:
 
** http://radio.weblogs.com/0101454/stories/2002/09/16/spamDetection.html
 
** http://www.bgl.nu/~glouis/bogofilter/
 
 
 
Une fois encore, lancer SpamAssassin::Bayes en mode bayes_auto_learn sans aucun processus de correction risque de mal fonctionner.
 
 
 
==Hashcash==
 
 
 
Ou l'augmentation artificielle du coût d'envoi d'un courriel, en ajoutant à chaque courriel un en-tête très long à calculer (1 ou 2s par courriel) mais rapide à vérifier. Des problèmes avec les listes de diffusions et autres envois en masse légitimes (si, si, il y en a :)).
 
 
 
Le but est d'augmenter le coût en temps processeur d'envoi d'un mail. Noter aussi que de nombreux utilisateurs sont atteints de virus exploités par les spammeurs, qui disposent ainsi d'une force de calcul parallèle et distribuée non-négligeable.
 
 
 
http://www.hashcash.org/faq/index.fr.php
 
 
 
 
 
==Tarpit==
 
 
 
Ralentir le serveur dans certaines conditions (ex: harvest attack).
 
 
 
* http://www.postfix.org/rate.html
 
 
 
 
 
==Liens==
 
 
 
Des systèmes:
 
* http://www.greylisting.org/
 
* http://www.openspf.org/
 
 
 
Des black lists:
 
* http://www.spamhaus.org/
 
* Soumission des spams par les utilisateurs:
 
* http://www.spamcop.net/
 
* http://www.spam-rbl.com/
 
 
 
Des sites à éventuellement regarder:
 
* http://www.cauce.org/ : site d'information
 
* http://www.weird.com/~woods/ :
 
 
 
Masquage minimal de son adresse e-mail:
 
perl -e '$a = "your\@email.tld"; $a =~ s/(.)/"&#".ord($1).";"/eg; print "$a\n";'
 

Version du 20 septembre 2006 à 22:41

Compilation du noyau utilisateur

C'est très simple: on compile le noyau Linux avec le paramètre ARCH=um pour chaque commande.

wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.13.tar.bz2
tar xjf linux-2.6.17.13.tar.bz2
cd linux-2.6.17.13
make defconfig ARCH=um
make xconfig ARCH=um # facultatif; pensez à activer HOSTFS si besoin
make ARCH=um
strip linux

Cf. Building from source chez UML.

Construction du système de base

On se propose de construire et de lancer un système UML sans aucun accès root.

Vraisemblablement, ce n'est pas possible facilement. Cela est dû au manque d'outil en mode utilisateur pour travailler directement sur des systèmes de fichiers ext3.

Tentative 1

Essayons de créer un système complet, sans faire d'image, et en possédant tous les fichiers:

La dernière version de debootstrap propose une variante fakechroot qui permet de l'utiliser sans accès root:

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:$PATH # pour trouver la commande 'chroot'
fakechroot /usr/sbin/debootstrap --variant=fakechroot sarge sarge-uml/ http://localhost/mirrors/debian
/usr/src/linux-2.6.17.13/linux  root=/dev/root rootflags=/home/sylvain/tests/uml/debian/sarge-uml/ rootfstype=hostfs

Résultat: cela ne fonctionne pas, à mon avis parce que dans ce cas précis sarge-uml/dev est un lien symbolique vers /dev.

Tentative 2

Essayons à partir d'une image UML déjà opérationnelle.

rootstrap fonctionne apparemment sur ce principe. Je n'ai pas réussi mais je n'ai pas beaucoup cherché.

En mode root

Faute de mieux, utilisons sudo:

mkdir loop/
# image de 1Go, à trous (espace disque progressif)
dd if=/dev/null of=image count=0 bs=1G seek=1
# on formatte en ext3
/sbin/mkfs.ext3 -F image

sudo mount image loop/ -o loop
sudo debootstrap sarge loop/ http://192.168.1.60/mirrors/debian

# configuration de la console:
sudo grep -v tty loop/etc/inittab > inittab.work
sudo echo "1:2345:respawn:/sbin/getty 38400 console linux" >> inittab.work
sudo mv inittab.work loop/etc/inittab

# configuration réseau:
cat <<'EOF' > interfaces.work
auto lo
iface lo inet loopback
EOF
sudo mv interfaces.work loop/etc/network/interfaces

# fake mtab and fstab
cat <<'EOF' > fstab.work
proc            /proc           proc    defaults        0 0
/dev/ubda       /               auto    defaults,errors=remount-ro 0 1
EOF
sudo mv fstab.work loop/etc/fstab 

sudo umount loop/

Optimiser la taille de l'image pour la distribuer

Une image UML contient souvent des zones vides, où il n'y a pas encore de fichiers.

L'image ci-dessus réserve 1Go mais n'en occupe que 230Mo grâce à la création d'image "à trous" (sparse en anglais).

$ ls -lh image
-rw-r--r--  1 sylvain sylvain 1,0G 2006-09-18 15:55 image
$ du -sh image
234M    image

df -h dans UML indique une utilisation de 178Mo, donc on doit pouvoir encore améliorer (comment?). Éviter e2defrag, qui non content d'augmenter globalement l'espace disque utilisé peut également introduire des erreurs dans l'image.

D'autres méthodes (dd sur /dev/zero par exemple) n'en tiennent pas compte.


Pour optimiser une image "pleine":

cp --sparse=always image image.sparse

Pour envoyer une image par le réseau en respectant les trous:

tar cSf image.tar image # S pour "sparse"

Réseau

Imaginez un câble virtuel qui relie la machine hôte et la machine UML, une carte carte réseau virtuelle à chaque bout. Chaque carte a une adresse IP, mais comme sur un réseau classique, les deux cartes ne doivent pas avoir la même adresse.

Mode root avec tuntap

host# sudo /usr/src/linux ubda=sarge-debootstrap eth0=tuntap,,,192.168.1.101

Notez les messages d'UML indiquant la mise en place d'une interface tuntap tap0, une route pour accéder à la machine virtuelle, et un partage de connexion pour que la machine virtuelle puisse accéder au réseau extérieur.

Puis dans UML:

uml# ifconfig eth0 192.168.1.201

Mode semi-root avec tuntap

Pour utiliser tuntap, il faut créer à l'avance (et en mode root) une interface tap0 et lui assigner une adresse IP.

# tunctl -u sylvain
Set 'tap0' persistent and owned by uid 1000

Puis il faut donner des droits aux utilisateurs non-privilégiés d'utiliser tuntap (en mode root aussi):

chmod 666 /dev/net/tun

C'est une solution efficace mais qui nécessite plusieurs étapes de préconfiguration en mode root, accompagné de permissions lâches sur tuntap.


Mode utilisateur avec tuntap (2)

Mettre l'utilisateur concerné dans le groupe uml-net. Ce groupe a accès au programme setuid /usr/lib/uml/uml_net, qui peut lancer et configurer des interfaces tuntap. La sécurité du procédé n'est pas grande (l'utilisateur peut créer de nouvelles interfaces réseau et perturber iptables par exemple), mais est facile à mettre en place.

host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=tuntap,,,10.10.10.10
uml# ifconfig eth0 10.10.10.11
uml# route add default gw 10.10.10.10

Note: la configuration automatique côté hôte nécessite uml_net (partage de connexion, route vers la machine UML...).

Mode utilisateur avec slirp

Lancer UML avec une interface slirp, en utilisant le binaire 'fullbolt' (qui s'affranchit de la limitation débit de 10ko/s dans slirp 'classique'):

host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=slirp,,/usr/bin/slirp-fullbolt

Dans UML, quelques étapes spécifiques à slirp sont nécessaires:

# Configurer l'interface sur 10.2.0.15 (IP de choix pour slirp)
ifconfig eth0 10.2.0.15
# Utiliser la redirection DNS 10.0.2.3
echo "nameserver 10.0.2.3" > /etc/resolv.conf
# Ajouter une route par défaut vers eth0:
route add default dev eth0

Note: ping ne fonctionne pas, car il nécessite un accès root (sur l'hôte, ping est d'ailleurs souvent setuid).

/etc/network/interfaces

Voici comment configurer automatiquement le réseau au démarrage d'UML, dans son fichier interfaces:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static

# eth0=tuntap,,,10.10.10.1
#  address 10.10.10.10
#  netmask 255.0.0.0
#  gateway 10.10.10.1

# eth0=slirp,,/usr/bin/slirp-fullbolt
  address 10.2.0.15
  netmask 255.0.0.0
  dns-nameservers 10.0.2.3
  up route add default eth0

(dns-nameservers nécessite le paquet resolvconf)

Autre solution pour gérer automatiquement les DNS: installez un serveur DNS dans l'UML, et évitez ainsi de vous faire suer à déterminer ceux de l'hôte. In-dé-pen-dan-ce ;) À moins que vous n'ayez besoin du serveur DNS de votre réseau interne.

Liens

Dépannage

Kernel panic - not syncing: start_userspace : expected SIGSTOP, got status = 256

Cf. http://www.mail-archive.com/user-mode-linux-devel@lists.sourceforge.net/msg03414.html

Votre noyau (hôte) est, si j'ai bien compris, mal configuré. Recompilez-le ou utilisez-en un autre.