https://doc.cliss21.com/api.php?action=feedcontributions&user=82.238.35.175&feedformat=atomCliss XXI - Contributions de l’utilisateur [fr]2024-03-29T00:44:13ZContributions de l’utilisateurMediaWiki 1.35.4https://doc.cliss21.com/index.php?title=KVM&diff=3660KVM2010-09-27T17:28:45Z<p>82.238.35.175 : /* Réseau */ explicite quand ça fonctionne</p>
<hr />
<div>Encore une technique de virtualisation. Elle s'appuie sur une fonctionalité processeur (nom de code VMS chez AMD, VT-X chez Intel). Les tests montre un niveau similaire mais pas nécessairement plus rapide que la para-virtualisation (Xen classique).<br />
<br />
== Installation ==<br />
<br />
On installe libvirt et quelques paquets recommandés:<br />
# KVM<br />
apt-get install qemu-kvm # previously 'kvm'<br />
# libvirt<br />
# - libvirt-bin: base utilities<br />
# - dbus: necessary to run libvirtd<br />
# - bridge-utils: network connection sharing<br />
# - lvm2: we use LVM-based block devices for VMs<br />
# netcat-openbsd: necessary to support 'nc -U', used by qemu+ssh://root@remote/system URIs, itself used by virt-manager<br />
apt-get install libvirt-bin -t lenny-backports<br />
apt-get install dbus bridge-utils lvm2 netcat-openbsd<br />
# Other recommends: dnsmasq-base (used by virt-manager to create new networks, unused if using a bridged setup), libxml2-utils<br />
<br />
=== Réseau ===<br />
<br />
libvirt propose par défaut un réseau interne NATé <code>/etc/libvirt/qemu/networks/default.xml</code>. Cela fonctionne plutôt bien, pour des machines virtuelles qui ne sont pas visibles sur le réseau.<br />
<br />
<interface type='network'><br />
<source network='default'/><br />
...<br />
</interface><br />
<br />
Pour raccorder directement les VMs au réseau physique, je n'ai pas trouvé de solution: virt-manager propose de créer un réseau "routé" avec un nouveau pont (bridge), mais sans moyen d'ajouter automatiquement une interface physique au pont, ce qui ne fonctionne donc pas.<br />
<br />
La seule solution que j'ai trouvée est de créer à l'avance un pont br0, et de demander à lier chaque machine virtuelle à cette interface physique.<br />
<br />
<interface type='bridge'><br />
<source bridge='br0'/><br />
...<br />
</interface><br />
<br />
=== Partitionnement ===<br />
<br />
En l'absence d'outil de (re)composition de disque ou de pygrub (à la xen), l'installation de GRUB pour amorcer sur une partition ext3 nécessite une image disque complète plutôt qu'une image de partition simple.<br />
<br />
(Il est apparemment possible d'installer GRUB Stage 1.5 dans la "boot loader area" d'une partition ReiserFS - je n'ai pas essayé mais je cherche ici une solution générique qui fonctionne avec tout type de partition)<br />
<br />
Une idée est de créer pour chaque VM:<br />
* une petite image disque contenant un MBR, son premier cylindre pour l'installation de GRUB Stage 1.5, et une petite partition <code>/boot</code><br />
* une image disque par partition, montée directement sur l'identifiant disque (ex: <code>/</code> monté sur <code>/dev/sdb</code>, <code>/home</code> monté sur <code>/dev/sdc</code>, etc.)<br />
<br />
Ce qui permet d'accéder directement aux partitions depuis le système hôte.<br />
<br />
Autre solution encore est d'utiliser des fichiers noyaux stockés sur l'hôte, mais ce n'est pas pratique (génération des initrd potentiellement incorrecte, difficulté du suivi de sécurité des noyaux d'autres distributions ou versions de la distribution...).<br />
<br />
=== Accès aux partitions d'une image disque ===<br />
<br />
Pour la gestion d'images disques complètes contenant plusieurs partitions (dans le cas où on a pas réalisé le partitionnement nous-même comme ci-dessus), on pourra regarder de plus près:<br />
* <code>kpartx</code>: pour faire apparaître, dans le <code>/dev/mapper</code> de l'hôte, les partitions de l'image disque - et pouvoir les monter<br />
* <code>parted</code>: pour redimensionner une partition dans l'image disque<br />
* [http://libguestfs.org/ libguesfs]: pour d'autres opérations sur les partitions, y compris un <code>guestmount</code> à base de fuse (non-root)<br />
<br />
=== Déclaration dans libvirt ===<br />
<br />
Vocabulaire:<br />
* create: activation immédiate d'une ressource temporaire<br />
* define: définition permanente d'une ressource, à activer dans un second temps<br />
<br />
Pour définir le pool LVM, le mieux que j'ai trouvé en ligne de commande est:<br />
pool-define-as VG0 logical localhost - none VG0 /dev/VG0<br />
pool-start VG0<br />
pool-autostart VG0<br />
<br />
=== Installation "à la machine physique" ===<br />
<br />
L'installation peut se fait à partir d'un installateur classique (image ISO, lecteur CD-ROm, PXE, etc.).<br />
On utilisera virt-manager ou virt-install,<br />
<br />
Pour virt-manager, suivre l'interface graphique. Je n'ai pas réussi à amorcer depuis le réseau (PXE), QEMU dit qu'il n'y a aucun périphérique bootable.<br />
<br />
Pour virt-install:<br />
<br />
wget http://cdimage.debian.org/debian-cd/5.0.5/amd64/iso-cd/debian-505-amd64-businesscard.iso<br />
kvm -m 256 -cdrom debian-505-amd64-businesscard.iso -boot d /dev/VG0/test1-disk -vnc :0 -k fr<br />
# ou<br />
virt-install -n test1 -r 2048 --disk path=/dev/VG0/test1-disk --cdrom debian-505-amd64-businesscard.iso --network bridge:br0 \<br />
--accelerate --vnc<br />
<br />
Suivre ensuite l'installation via VNC.<br />
<br />
=== Installation automatique ===<br />
<br />
Il s'agit de lancer <code>debootstrap</code> dans un nouveau volume LVM:<br />
<br />
apt-get install debootstrap<br />
lvcreate -n test1-disk -L2G VG0<br />
mkfs.ext3 /dev/VG0/test1-disk<br />
mkdir test1-disk<br />
mount /dev/VG0/test1-disk /mnt/test1-disk<br />
debootstrap --arch=i386 lenny /mnt/test1-disk http://ftp.fr.debian.org/debian<br />
# TODO: post-install, cf. autostrap<br />
umount /mnt/test1-disk<br />
<br />
Alternativement on pourra utiliser des outils existants (cf. [[Xen]] et [[VServer]]):<br />
# Xen (xen-tools)<br />
xen-create-image --hostname test1 --kernel /boot/vmlinuz-2.6.26-2-xen-686 \<br />
--initrd /boot/initrd.img-2.6.26-2-xen-686 \<br />
--dist lenny --mirror http://monmiroir:9999/debian/ \<br />
--dhcp --lvm VG0 --size 4G \<br />
--role udev<br />
# VServer (partie debootstrap uniquement)<br />
vserver monvserver build -m debootstrap -- -d lenny -m http://mirror/debian<br />
<br />
Créer ensuite une configuration XML. Une solution est de convertir les paramètres que l'on aurait passé à QEMU:<br />
# - création de la config XML<br />
echo "/usr/bin/kvm -m 1024 -hda /dev/VG0/test1-disk -nographic -vnc autoport -k fr" \<br />
"-kernel /boot/vmlinuz-2.6.32-bpo.5-amd64 -initrd /boot/initrd.img-2.6.32-bpo.5-amd64" \<br />
"-append root=/dev/sda" > t<br />
virsh domxml-from-native qemu-argv t > test1.xml<br />
# Change to arch='x86_64' in <type> if necessary<br />
# Add keymap='fr' in <vnc> if necessary<br />
# TODO: network<br />
<br />
virsh create test1.xml<br />
<br />
TODO: créer une image disque minimale pour GRUB, comme documenté dans la section Partionnement.<br />
<br />
apt-get install parted<br />
dd if=/dev/zero of=boot.img count=10 bs=1024k<br />
parted boot.img<br />
...<br />
<br />
=== Accès console ===<br />
<br />
Dans le fichier <code>/etc/inittab</code> de l'invité, remplacer ou ajouter un processus de login sur le port série:<br />
0:2345:respawn:/sbin/getty 115200 ttyS0<br />
On peut ensuite accéder en mode texte à la machine (typiquement pour réparer un serveur SSH récalcitrant ou bénéfier du copier/coller):<br />
virsh console test1<br />
<br />
== Comparaison avec Xen ==<br />
<br />
Le principal avantage est de s'appuyer sur un noyau Linux classique: le démarrage du système hôte se fait comment d'habitude, pas de bricolage nécessaire au niveau des options du port série, etc.<br />
<br />
Le principal inconvénient est la nécessité d'utiliser des images disques complètes, contrairement à Xen qui peut assembler un disque virtuel à partir de fichiers de partitions distinctes, et de charger un noyau depuis sa partition d'installation avec pygrub. Les opérations de redimensionnement de partitions nécessitent également une reconfiguration de la table de partitionnement avec éventuellement déplacement des données, ce qui souvent ne peut se faire sans passer par un LiveCD GParted. Une solution est d'utiliser systématiquement une seule partition par disque virtuel, quitte à ajouter plusieurs disques virtuels. Il y a également des gens qui font du LVM sur LVM, mais restons sérieux.<br />
<br />
== VIA Nano / Dedibox V3 ==<br />
<br />
KVM ne fonctionne pas pour l'instant sur ce CPU, malgré l'annonce de support des instructions VT ("processeur Nano U2250, offrant le support du 64Bits et des instructions VT pour la virtualisation").<br />
<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570244<br />
* http://linuxfr.org/~fredix/29788.html<br />
<br />
On récupère des erreurs en boucle continue de type:<br />
Aug 5 17:06:52 sd-22222 kernel: [185363.334294] handle_exception: unexpected, vectoring info 0x8000000d intr info 0x80000b0d<br />
<br />
<br />
== Liens ==<br />
<br />
* [http://wiki.libvirt.org/ Wiki officiel]: c'est la documentation à lire - ne pas regarder l'onglet "Documentation" sur libvirt.org, qui n'est pas prévue pour l'utilisateur final<br />
** [http://wiki.libvirt.org/page/Networking Configuration bridge]<br />
* [http://autonomic.ac.upc.edu/emotive/?p=162 Xen to KVM disk image migration]: construire une image automatiquement avec notamment debootstrap<br />
* [http://www.pither.com/articles/2009/10/09/resize-ext3-in-lvm-in-partition-in-kvm-qemu-virtual-image-file Resize ext3 in LVM in partition in (KVM/QEMU) virtual image file]: contraignant si on utilise des images disque plutôt que des partitions<br />
* [http://www.debian-administration.org/users/johns/weblog/3 Migrating a vserver container to KVM]<br />
* [http://kerneltrap.org/node/8306 Is "Clocksource tsc unstable" kernel msg a problem or not ?]<br />
* [[Xen]] sur doc.cliss21.com<br />
* [[libvirt]] sur doc.cliss21.com</div>82.238.35.175https://doc.cliss21.com/index.php?title=DRBD&diff=3396DRBD2010-09-19T15:43:55Z<p>82.238.35.175 : /* Montage au démarrage */</p>
<hr />
<div>Distributed Replicated Block Device<br />
<br />
apt-get install drbd8-utils drbd8-modules-2.6-686<br />
# ou variante:<br />
apt-get install drbd8-utils drbd8-modules-2.6-vserver-686<br />
<br />
== Configuration simple ==<br />
<br />
Primary/Secondary (il existe aussi Primary/Primary):<br />
<br />
<pre><br />
global { <br />
usage-count yes;<br />
}<br />
common {<br />
protocol C;<br />
syncer { rate 40M; }<br />
disk { on-io-error detach; }<br />
startup {<br />
wfc-timeout 15;<br />
degr-wfc-timeout 15;<br />
#outdated-wfc-timeout 15; # not in DRBD 8.0/Lenny<br />
}<br />
}<br />
resource r0 {<br />
startup { become-primary-on VM1; }<br />
on VM1 {<br />
device /dev/drbd0;<br />
disk /dev/VG0/test;<br />
address 192.168.101.115:7789;<br />
meta-disk /dev/VG0/test-drbdmeta[0];<br />
}<br />
on VM2 {<br />
device /dev/drbd0;<br />
disk /dev/VG0/test;<br />
address 192.168.101.118:7789;<br />
meta-disk /dev/VG0/test-drbdmeta[0];<br />
}<br />
}<br />
</pre><br />
<br />
== Méta-données ==<br />
<br />
Si vous utilisez des méta-données externes, vous aurez [http://www.drbd.org/users-guide/ch-internals.html#s-meta-data-size calculé] que le volume dédié n'a pas besoin d'être bien grand.<br />
<br />
Cependant, il faut noter que le volume doit être au minimum to 128Mo très précisément, même pour le plus petit volume DRBD.<br />
<br />
== DRBD par dessus LVM ==<br />
<br />
Snapshots LVM d'un volume [[DRBD]]:<br />
* http://thread.gmane.org/gmane.comp.linux.drbd/6175 : en 2004<br />
* http://www.mail-archive.com/drbd-user@lists.linbit.com/msg00277.html : en 2009<br />
<br />
Ce que je comprend:<br />
* léger risque d'incohérence du snapshot<br />
* pas de risque d'incohérence des données maîtres<br />
<br />
En pratique, pour avoir un backup cohérent à partir du noeud secondaire:<br />
lvcreate -s VG0/test -n test-snapshot -L 5G<br />
mount /dev/VG0/test-snapshot -o ro /mnt/snapshots/test # ro par parano<br />
# backup avec rsync...<br />
umount /mnt/snapshots/test<br />
lvremove VG0/test-snapshot<br />
<br />
== Recharger la configuration ==<br />
<br />
Utiliser:<br />
drbdadm adjust r0<br />
<br />
Attention: comme indiqué [http://www.drbd.org/users-guide/s-configure-io-error-behavior.html ici], s'il y a un changement ''dans une section <code>disk</code>'', les versions < 8.3.1 lancent une resynchronization complète. Pour éviter cela, passer le primaire en secondaire (donc les deux noeuds en secondaire) avant de lancer <code>adjust</code>; cela implique de démonter toutes les volumes DRBD actifs.<br />
<br />
== Simuler des erreurs d'entrées/sorties ==<br />
<br />
Cf. http://lists.linbit.com/pipermail/drbd-dev/2009-July/001073.html<br />
<br />
<pre><br />
+ The actual simulation of IO errors is done by writing 3 values to<br />
+ /sys/module/drbd/parameters/<br />
+<br />
+ enable_faults: bitmask of...<br />
+ 1 meta data write<br />
+ 2 read<br />
+ 4 resync data write<br />
+ 8 read<br />
+ 16 data write<br />
+ 32 data read<br />
+ 64 read ahead<br />
+ 128 kmalloc of bitmap<br />
+ 256 allocation of EE (epoch_entries)<br />
+<br />
+ fault_devs: bitmask of minor numbers<br />
+ fault_rate: frequency in percent<br />
+<br />
+ Example: Simulate data write errors on /dev/drbd0 with a probability of 5%.<br />
+ echo 16 > /sys/module/drbd/parameters/enable_faults<br />
+ echo 1 > /sys/module/drbd/parameters/fault_devs<br />
+ echo 5 > /sys/module/drbd/parameters/fault_rate<br />
</pre><br />
<br />
L'exemple occasionne une erreur disque au bout de quelques accès disque.<br />
drbd0: Notified peer that my disk is broken<br />
<br />
== Gérer des erreurs d'entrées/sorties ==<br />
<br />
Cas 1 (configuration par défaut, mais n'est plus recommandée):<br />
<br />
disk { on-io-error pass_on; }<br />
<br />
Dans ce cas, les erreurs sont passées au système de fichiers, qui habituellement va se remonter en lecture seule. D'après mes tests, cependant, même avec <code>-o errors=remount-ro</code>, le système de fichiers s'est corrompu avec moult messages de drbd0 mais ''sans'' que le système de fichiers ne passe en lecture seule.<br />
<br />
Cas 2:<br />
<br />
disk { on-io-error detach; }<br />
<br />
Dans ce cas le disque continue de fonctionner de manière transparente sur le secondaire, en passant par le réseau (mode "diskless").<br />
<br />
Cas 3:<br />
<br />
disk { on-io-error call-local-io-error; }<br />
<br />
Dans ce cas DRBD appelle un script spécifié via <code>local-io-error</code>.<br />
<br />
== Montage au démarrage ==<br />
<br />
* Dans <code>/etc/fstab</code> faire attention:<br />
** de bien faire référence au volume DRBD (pas au volume physique)<br />
** de ne pas demander un fsck (mettre les deux derniers champs à <code>0</code>) car drbd n'est pas activé au moment où fstab est utilisé, ce qui va causerait une erreur<br />
* Dans l'ordre de démarrage, positionner les services dépendant de DRBD (ex: vserver) après lui<br />
* Rajouter un script au démarrage pour finir de monter les volumes DRBD, par exemple:<br />
<pre><br />
cat <<'EOF' > /etc/init.d/drbdmount<br />
#!/bin/bash<br />
if [ "$1" = "start" ]; then mount -a; fi<br />
EOF<br />
chmod 755 /etc/init.d/drbdmount<br />
update-rc.d -f vprocunhide remove<br />
update-rc.d -f vservers-default remove<br />
# Put it after the 'drbd' init script<br />
update-rc.d drbdmount defaults 75<br />
update-rc.d vprocunhide defaults 80<br />
update-rc.d vservers-default defaults 80<br />
</pre><br />
<br />
== Supervision ==<br />
<br />
La supervision semble n'être prévue que par le biais de Heartbeat/Pacemaker. Quelques événements peuvent être notifiés par l'intermédiaires des ''handlers'', mais pas tous.<br />
<br />
La commande <code>drbdsetup /dev/drbd0 events</code> permet de récupérer de manière succinte tous les événements qui se produisent.<br />
On peut l'utiliser de manière très rudimentaire dans le script suivant qui tournera en tâche de fond:<br />
<br />
<pre><br />
#!/bin/bash<br />
for drbdX in /dev/drbd*; do<br />
(drbdsetup $drbdX events | while read line; do echo $line | mail -s "$(hostname) $drbdX" you@domain.tld; done)&<br />
sleep 1<br />
done<br />
</pre><br />
<br />
Faire un <code>killall drbdsetup</code> pour l'arrêter.<br />
<br />
== Liens ==<br />
<br />
* [http://www.drbd.org/users-guide/ The DRBD User's Guide]<br />
* [[LVM]]</div>82.238.35.175https://doc.cliss21.com/index.php?title=Xen&diff=2718Xen2010-08-09T22:54:41Z<p>82.238.35.175 : /* VNC */</p>
<hr />
<div>== Vocabulaire ==<br />
<br />
* Hyperviseur: socle d'exécution<br />
** Dom0 = hôte<br />
** DomU = invité = sous-système virtualisé<br />
<br />
Dom0 comme DomU sont des noyaux Linux modifiés pour passer par l'hyperviseur Xen à la place d'accéder directement aux ressources du système. Dom0 et DomU peuvent utiliser la même image noyau - c'est même souvent le cas.<br />
<br />
Avec une installation Debian Etch standard:<br />
* /boot/xen-3.0.3-1-i386-pae.gz : hyperviseur (on ''boot'' dessus)<br />
* /boot/vmlinuz-2.6.18-4-xen-686 : noyau Linux modifié à utiliser pour Dom0 et DomU<br />
** /boot/initrd.img-2.6.18-4-xen-686 : image ramdisk associée au noyau Linux modifié<br />
<br />
<br />
== Survie ==<br />
<br />
man xm<br />
<br />
* Lister les DomU:<br />
xm list<br />
* Lancer un Xen (chemin relatif à <code>/etc/xen/</code>):<br />
xm create auto/egroupware<br />
* Éteindre un Xen (utiliser le nom donné par <code>xm list</code>):<br />
xm shutdown NOM<br />
* Éteindre tous les Xen:<br />
xm shutdown -a<br />
* Redémarrer:<br />
xm reboot NOM<br />
* Entrer dans le Xen en mode console pour débugger (sortie comme dans telnet: <code>Ctrl + ]</code>):<br />
xm console NOM<br />
<br />
== Installation dans le cas où tout va bien ==<br />
<br />
Base:<br />
aptitude install xen-linux-system-2.6.26-2-xen-686 # noyau, hyperviseur, etc.<br />
aptitude install xen-utils # xend, xm...<br />
aptitude install xen-tools # outils pour créer un DomU<br />
<br />
Un test avec xen-create-image 3.2:<br />
xen-create-image --hostname test-drbd --kernel /boot/vmlinuz-2.6.26-2-xen-686 \<br />
--initrd /boot/initrd.img-2.6.26-2-xen-686 \<br />
--dist lenny --mirror http://monmiroir:9999/debian/ \<br />
--dhcp --lvm VG0 --size 4G \<br />
--role udev<br />
En 3.0:<br />
xen-create-image --hostname montest --kernel /boot/vmlinuz-2.6.18-6-xen-686 \<br />
--initrd /boot/initrd.img-2.6.18-6-xen-686 \<br />
--debootstrap --dist etch --mirror monmiroir:9999 \<br />
--dhcp --lvm VG0 --size 4G<br />
<br />
Survival:<br />
xm list # list running Xen instances<br />
xm create yourxen # start an instance<br />
xm console yourxen # enter an instance, type C-] to quit<br />
xm destroy yourxen # force shutdown<br />
<br />
== Post-install ==<br />
<br />
* Désactiver ou définir le mot de passe root<br />
* Copier les clefs SSH<br />
* Vérifier <code>/etc/hosts</code> (<code>127.0.0.1 fqdn host localhost</code>)<br />
* <code>dpkg-reconfigure debconf # priority -> medium, !high</code><br />
* Dans le DomU, dans <code>/etc/inittab</code>:<br />
1:2345:respawn:/sbin/getty 38400 hvc0<br />
* Vérifier la configuration réseau:<br />
vif = [ 'bridge=br-xen, mac=00:16:3E:59:2A:ED' ]<br />
* Activer VNC:<br />
vfb = ['type=vnc, vncunused=1']<br />
* Déplacer la configuration dans /etc/xen/auto/<br />
<br />
En plus, pour Etch:<br />
* À la place de copier /lib/modules/2.6.26-N-xen-686 à chaque mise à jour de sécurité du noyau depuis le Dom0, installez linux-modules-xen-686/amd64 dans le DomU<br />
* Forcer la reconfiguration du fuseau horaire (tzconfig / dpkg-reconfigure tzdata)<br />
* Configurer le sources.list (s/stable/etch/)<br />
<br />
== Le pont / bridge ==<br />
<br />
auto br-xen<br />
iface br-xen inet static<br />
address 192.168.1.145<br />
netmask 255.255.255.0<br />
gateway 192.168.1.1<br />
bridge_ports eth0<br />
# bridge_ports none<br />
# optional<br />
bridge_stp off<br />
bridge_maxwait 0<br />
bridge_fd 0<br />
#bridge_hello 0<br />
<br />
== Les problèmes pénibles de Xen ==<br />
<br />
* Vole/désactive les ports séries par défaut - ce qui est loin d'être pratique sur des serveurs dédiés, ou le port série est l'accès de secours en cas de problème réseau. Solution: ajouter xencons=tty6 dans le grub.conf (pour Xen 3.0 / Etch, apparemment corrigé dans Xen 3.2 / Lenny)<br />
* Les paquets Debian ne fournissent que des binaires avec support [http://en.wikipedia.org/wiki/Physical_Address_Extension PAE] activé. Si vous voulez tester sur votre portable à base de Pentium-M (sans support PAE), vous n'avez plus qu'à installer votre propre noyau, car les paquets Debian ne fonctionneront pas (compilés en mode PAE uniquement; erreurs ''PAE mode mismatch in Xen (xen=no Dom0=yes)'' ou ''Cannot execute a PAE-enabled kernel on a PAE-less CPU'' au boot). Utiliser <code>grep pae /proc/cpuinfo</code> pour voir si votre processeur gère PAE. C'est à se demander pourquoi une version de l'hyperviseur en mode non-PAE est disponible :/<br />
* Des ralentissements et des bugs au niveau du clavier dans certains cas, pas tout le temps, même avec libc6-xen: répétitions aléatoires de touches au moment de la frappe, ralentissement impressionnant de gnome-terminal.<br />
* Des problèmes bizarres avec perte de connexion réseau, des messages <code>xen_net memory squeeze in netback driver</code> sur la console, vraisemblablement dès que l'on utilise trop de mémoire (ici 4G/8G sur 32bit sur une machine 64bit, probablement avec APE. Une solution qui n'explique pas vraiment le problème (et qui apparement ne fonctionne pas pour tout le monde) consiste à limiter la mémoire du dom0 de manière identique en deux endroits (GRUB et config) [http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg360172.html]:<br />
** boot/grub/menu.lst: <code>xenhopt=dom0_mem=256M</code><br />
** /etc/xen/xend-config.sxp: <code>(dom0-min-mem 256)</code><br />
* Des <code>Kernel BUG at drivers/xen/core/evtchn.c:481</code> de temps à autres. Solution de contournement [http://lists.debian.org/debian-kerne/2007/02/msg00291.html]: limiter Dom0 à un processeur via <code>(dom0-cpus 1)</code> dans <code>/etc/xen/xend-config.sxp</code>. Je suis de moins en moins rassuré sur le fiabilité de ce truc.<br />
* Sous Debian, à chaque mise à jour de sécurité noyau avec nouvelle ABI (ex: 2.6.18-5-686 => 2.6.18-6-686), penser à mettre à jour <code>kernel</code> et <code>ramdisk</code> dans <code>/etc/xen/*.cfg</code>, et mettre à jour <code>/lib/modules</code> dans les DomU. Il n'y a pas de paquet générique indépendamment de la version, donc au niveau paquets ça donne:<br />
## Dom0<br />
aptitude install linux-image-xen-686 xen-linux-system-2.6.18-6-xen-686<br />
# fix /etc/xen/*.cfg, install DomU packages below, reboot<br />
aptitude purge linux-image-2.6.18-5-xen-686 linux-modules-2.6.18-5-xen-686 xen-linux-system-2.6.18-5-xen-686<br />
<br />
## DomU<br />
aptitude install linux-modules-2.6.18-6-xen-686<br />
aptitude purge linux-modules-2.6.18-5-xen-686<br />
# 'xm shutdown' (NOT reboot) and 'xm create' in Dom0<br />
<br />
== Migration / relocation ==<br />
<br />
La commande est<br />
xm migrate vm host<br />
xm migrate --live vm host<br />
<br />
Apparemment cela ne concerne que l'état mémoire de la machine virtuelle. Pour le disque, il faut utiliser un disque réseau, ou bien faire le déplacement des données à la main.<br />
<br />
Dans <code>/etc/xen/xend-config.sxp</code>, sur l'hôte distant, pour accepter la migration:<br />
(xend-relocation-server yes)<br />
(xend-relocation-port 8002)<br />
(xend-address '')<br />
(xend-relocation-hosts-allow '^your other host IP$')<br />
<br />
Dans le même ordre d'idée, il est possible de mettre un serveur en pause, par exemple au moment d'un reboot du Dom0. Une fois réactivée, la machine est restaurée à l'identique: l'uptime ne sera pas mis à zéro, les connexions TCP/IP seront même toujours valides!<br />
<br />
== Installation semi-manuelle avec l'image binaire officielle ==<br />
<br />
Le site officiel est xensource.com, mais est bourré de propagande liée à une obscure "vente" de produits "entreprise". Bref allez directement sur http://xen.xensource.com/ , puis sur la page de téléchargement. On prend ici une des tarballs binaires; choisissez 32bit, 32bit+pae ou 64bit en fonction de votre système.<br />
<br />
tar xzf xen-3....tar.gz<br />
cd dist<br />
./install.sh<br />
# Image initrd:<br />
depmod 2.6.16.29-xen<br />
update-initramfs -k 2.6.16.29-xen -ct<br />
update-grub<br />
<br />
Ça fonctionne, mais:<br />
* 2.6.16: carte réseau non gérée (malgré la présence du module concerné)<br />
* 2.6.18: carte réseau OK, mais des ''BUG'' en rafale dans la console à propos de vmalloc, et de notes de evbug.c dès qu'on touche au clavier - pas rassurant..<br />
<br />
== Installation manuelle ==<br />
<br />
Vous récupérez une version de Linux xenifiée, et vous la compilez comme d'habitude, avec un panneau menuconfig en plus pour paramétrer Xen.<br />
<br />
make world<br />
make install<br />
permet de recréer l'image binaire officielle.<br />
<br />
Pour recompiler avec une config perso? TODO. Le README propose:<br />
make linux-2.6-xen-config CONFIGMODE=menuconfig<br />
mais cela installe un .config assez lourd. Je préfèrerais un 'defconfig'.<br />
<br />
=== Quelle version du noyau Linux? ===<br />
<br />
Les tarballs officielles sont basées sur des noyaux relativement vieux (2.6.16 pour Xen 3.0, 2.6.18 pour Xen 3.1). On trouve quelques ''forward-ports'' chez RedHat: http://hg.et.redhat.com/kernel/ (utilisés notamment dans le noyau 2.6.18 de Etch).<br />
<br />
<br />
== Pour faire simple ==<br />
<br />
Vous pouvez toujours installer Xen depuis une instance de QEMU, mais lancée avec <code>-no-kqemu</code>; évidemment ça va ramer, mais tant que c'est le processeur et pas vous... :)<br />
<br />
<br />
== Mise à jour Etch -> Lenny ==<br />
<br />
Configurations mixtes:<br />
* Il est possible de lancer un domU Etch depuis un domU Lenny: conserver les noyaux dans le dom0<br />
* Il est possible de lancer un domU Lenny en kernel Etch: conserver les modules linux-module-xen dans le domU<br />
* Il n'est apparemment pas possible de lancer un domU Lenny en kernel Lenny depuis un dom0 Etch: mais il y avait différentes erreurs liées à Python, au support du nouveau Xen, etc., donc pas sûr à 100%<br />
<br />
Conclusion on peut mettre à jour le dom0 ou bien le domU en premier, c'est comme on veut, juste bien conserver les anciens noyaux (dom0) et les anciens modules (domU).<br />
<br />
=== Dom0 ===<br />
<br />
Après la mise à jour du système:<br />
apt-get install xen-linux-system-2.6.26-2-xen-686<br />
apt-get install xen-utils-3.2-1<br />
<br />
Puis modifier les lignes <code>kernel</code> et <code>ramdisk</code> dans <code>/etc/xen/*</code>:<br />
kernel = '/boot/vmlinuz-2.6.26-2-xen-686'<br />
ramdisk = '/boot/initrd.img-2.6.26-2-xen-686'<br />
<br />
=== DomU ===<br />
<br />
Choses à faire quand on passe du noyau 2.6.18 au noyau 2.6.26.<br />
<br />
Installer les nouveaux modules noyaux (utile pour iptables notamment):<br />
apt-get install linux-modules-xen-686<br />
# ou bien<br />
apt-get install linux-modules-xen-amd64<br />
<br />
Installez udev<br />
apt-get install udev<br />
<br />
Visiblement Xen nettoie <code>/dev</code> sans le repeupler proprement, du coup évidemment c'est le foutoir, avec des erreurs du type "Mount point '/dev/shm' does not exist. Skipping mount. (warning).", et en particulier <code>/dev/pts</code> n'est pas monté ce qui casse la connexion SSH (penser à utiliser la syntaxe <code>ssh you@host command</code> pour dépanner).<br />
<br />
Faites écouter getty sur <code>hvc0</code>, qui est selon toute vraisemblance <code>tty1</code> mais version Xen (histoire de faire simple). Dans votre <code>/etc/inittab</code>:<br />
1:2345:respawn:/sbin/getty 38400 hvc0<br />
<br />
== Afficher les informations de démarrage sur le port série ==<br />
<br />
Notre cible est le port série virtuel du serveur, détecté comme port série numéro 2 (ttyS1).<br />
<br />
Modifier <code>/boot/grub/menu.lst</code> comme suit:<br />
# xenhopt=com2=115200,8n1 console=com2,vga<br />
# xenkopt=console=tty0 console=hvc0<br />
Puis lancez:<br />
update-grub<br />
pour mettre à jour les entrées de noyau automatiques.<br />
<br />
<br />
Faites écouter un getty sur <code>hvc0</code> dans <code>/etc/inittab</code>:<br />
co:2345:respawn:/sbin/getty -h -L hvc0 115200 ansi<br />
<br />
== pygrub ==<br />
<br />
pygrub permet d'amorcer le domU à partir d'un noyau installé dans le domU (et non pas dans le dom0). Cela permet de gérer via APT/yum/etc. des noyaux d'autres distributions, d'autres versions de la distributions, d'autres architectures (32/64bit), etc. que le dom0. Cela permet également de générer des images initrd propres (en fonction du domU et pas du dom0). Les noyaux Xen du Dom0 restent utiles pour l'installation/bootstrap initiale du domU.<br />
<br />
Dans le domU:<br />
* Installer le noyau<br />
* Installer GRUB<br />
* Préparer un <code>/boot/grub/menu.lst</code> valide<br />
** On pourra utiliser <code>update-grub</code><br />
** Pour cela il est nécessaire de créer un faux /dev/sda (en plus des LVM-partitions sda1, sda2, etc):<br />
dd if=/dev/null of=/etc/xen/mbr/$name-sda bs=1M seek=1<br />
disk = [ ... 'file:/etc/xen/mbr/$name-sda,sda,w', ... ]<br />
* Inutile d'installer grub sur le MBR<br />
<br />
Dans le fichier de configuration du domU:<br />
* <code>bootloader='/usr/lib/xen-3.2-1/bin/pygrub'</code><br />
* commenter les lignes "kernel" et "ramdisk".<br />
* dans la section 'disk', positionner la partition contenant le noyau en premier<br />
<br />
== Autres méthodes d'amorçage ==<br />
<br />
* pypxeboot: amorçage par le réseau pour les invités Xen<br />
* cdrom: apparemment par le biais d'une image ISO<br />
<br />
D'après la page [http://wiki.debian.org/DebianInstaller/Xen Xen] du wiki Debian, Xen PV ne gère pas les installateurs des distrubutions directements, à la place celles-ci propose des solutions de contournement pour faire fonctionner l'installateur dans Xen PV. Xen HVM gère l'installateur sans modification.<br />
<br />
Bref, pour les PV on reste sur des méthodes en ligne de commande, sauf gros bricolage du D-I?<br />
<br />
== VNC ==<br />
<br />
* PV: regarder la configuration de <code>vfb</code> (virtualframe buffer)<br />
vfb = ['type=vnc,vncdisplay=2']<br />
vfb = ['type=vnc,vncunused=1']<br />
* HVM: en standard (<code>builder="hvm"</code>, <code>vnc=1</code>) ?<br />
<br />
== Définition dans libvirt ==<br />
<br />
Les DomU en cours d'exécution sont reconnus par défaut.<br />
Pour qu'ils soient persistants (et relançable depuis virt-manager), il faut les convertir:<br />
<br />
mkdir -m 755 /etc/libvirt/xen/<br />
xm create mydomu.cfg<br />
virsh dumpxml mydomu > /etc/libvirt/xen/mydomu.xml<br />
virsh define /etc/libvirt/xen/mydomu.xml<br />
<br />
Pour libérer le slot (par exemple pour le reconfigurer):<br />
virsh undefine mydomu<br />
<br />
== Liens ==<br />
<br />
* [http://wiki.kartbuilding.net/index.php/Debian_Etch_Xen_Install Debian Etch Xen Install]: config de base<br />
* [http://wiki.kartbuilding.net/index.php/Create_DomU Create DomU]: script de base<br />
* [http://wiki.debian.org/Xen Xen@Debian Wiki]: les paquets de base (pour du PAE)<br />
* [http://julien.danjou.info/xen.html Xen 3 for Debian]: une introduction; recommande LVM pour les images disques et le bridging pour le réseau <br />
* [http://free-electrons.com/community/howtos/raid-xen-ubuntu Introduction]: par Free-Electrons, également membres de l'APRIL; ils parlent de RAID mais utilisent des images disques (et non des partitions dédiées) - pas très efficace. Utilisent des adresses locales 10.0.0.X pour les DomU avec un NAT sur le Dom0.<br />
<br />
* [http://tx.downloads.xensource.com/downloads/docs/user Manuel de l'utilisateur]: spartiate<br />
<br />
* [http://phaq.phunsites.net/2007/06/30/xen-console-grabbded-devttys0/ Xen console grabbded /dev/ttyS0]: un truc pour réactiver le port série<br />
<br />
* [http://wiki.xensource.com/xenwiki/XenFaq#head-5f7176b3909cb0382cece43a6a8fc25a3a114e93 32bit and 64bit]: qui peut lancer qui?<br />
<br />
* [http://wiki.debian.org/Xen#Installationonlenny Xen - Debian Wiki]: notamment la section ''Additional note for domU on lenny using xen-tools'' (mais notez qu'elle ne dit pas comment corriger les installations existantes, ce que nous faisons [[#DomU|plus haut]]), et la partie sur le double affichage écran / port série</div>82.238.35.175https://doc.cliss21.com/index.php?title=Xen&diff=2717Xen2010-08-09T22:28:15Z<p>82.238.35.175 : /* Post-install */</p>
<hr />
<div>== Vocabulaire ==<br />
<br />
* Hyperviseur: socle d'exécution<br />
** Dom0 = hôte<br />
** DomU = invité = sous-système virtualisé<br />
<br />
Dom0 comme DomU sont des noyaux Linux modifiés pour passer par l'hyperviseur Xen à la place d'accéder directement aux ressources du système. Dom0 et DomU peuvent utiliser la même image noyau - c'est même souvent le cas.<br />
<br />
Avec une installation Debian Etch standard:<br />
* /boot/xen-3.0.3-1-i386-pae.gz : hyperviseur (on ''boot'' dessus)<br />
* /boot/vmlinuz-2.6.18-4-xen-686 : noyau Linux modifié à utiliser pour Dom0 et DomU<br />
** /boot/initrd.img-2.6.18-4-xen-686 : image ramdisk associée au noyau Linux modifié<br />
<br />
<br />
== Survie ==<br />
<br />
man xm<br />
<br />
* Lister les DomU:<br />
xm list<br />
* Lancer un Xen (chemin relatif à <code>/etc/xen/</code>):<br />
xm create auto/egroupware<br />
* Éteindre un Xen (utiliser le nom donné par <code>xm list</code>):<br />
xm shutdown NOM<br />
* Éteindre tous les Xen:<br />
xm shutdown -a<br />
* Redémarrer:<br />
xm reboot NOM<br />
* Entrer dans le Xen en mode console pour débugger (sortie comme dans telnet: <code>Ctrl + ]</code>):<br />
xm console NOM<br />
<br />
== Installation dans le cas où tout va bien ==<br />
<br />
Base:<br />
aptitude install xen-linux-system-2.6.26-2-xen-686 # noyau, hyperviseur, etc.<br />
aptitude install xen-utils # xend, xm...<br />
aptitude install xen-tools # outils pour créer un DomU<br />
<br />
Un test avec xen-create-image 3.2:<br />
xen-create-image --hostname test-drbd --kernel /boot/vmlinuz-2.6.26-2-xen-686 \<br />
--initrd /boot/initrd.img-2.6.26-2-xen-686 \<br />
--dist lenny --mirror http://monmiroir:9999/debian/ \<br />
--dhcp --lvm VG0 --size 4G \<br />
--role udev<br />
En 3.0:<br />
xen-create-image --hostname montest --kernel /boot/vmlinuz-2.6.18-6-xen-686 \<br />
--initrd /boot/initrd.img-2.6.18-6-xen-686 \<br />
--debootstrap --dist etch --mirror monmiroir:9999 \<br />
--dhcp --lvm VG0 --size 4G<br />
<br />
Survival:<br />
xm list # list running Xen instances<br />
xm create yourxen # start an instance<br />
xm console yourxen # enter an instance, type C-] to quit<br />
xm destroy yourxen # force shutdown<br />
<br />
== Post-install ==<br />
<br />
* Désactiver ou définir le mot de passe root<br />
* Copier les clefs SSH<br />
* Vérifier <code>/etc/hosts</code> (<code>127.0.0.1 fqdn host localhost</code>)<br />
* <code>dpkg-reconfigure debconf # priority -> medium, !high</code><br />
* Dans le DomU, dans <code>/etc/inittab</code>:<br />
1:2345:respawn:/sbin/getty 38400 hvc0<br />
* Vérifier la configuration réseau:<br />
vif = [ 'bridge=br-xen, mac=00:16:3E:59:2A:ED' ]<br />
* Activer VNC:<br />
vfb = ['type=vnc, vncunused=1']<br />
* Déplacer la configuration dans /etc/xen/auto/<br />
<br />
En plus, pour Etch:<br />
* À la place de copier /lib/modules/2.6.26-N-xen-686 à chaque mise à jour de sécurité du noyau depuis le Dom0, installez linux-modules-xen-686/amd64 dans le DomU<br />
* Forcer la reconfiguration du fuseau horaire (tzconfig / dpkg-reconfigure tzdata)<br />
* Configurer le sources.list (s/stable/etch/)<br />
<br />
== Le pont / bridge ==<br />
<br />
auto br-xen<br />
iface br-xen inet static<br />
address 192.168.1.145<br />
netmask 255.255.255.0<br />
gateway 192.168.1.1<br />
bridge_ports eth0<br />
# bridge_ports none<br />
# optional<br />
bridge_stp off<br />
bridge_maxwait 0<br />
bridge_fd 0<br />
#bridge_hello 0<br />
<br />
== Les problèmes pénibles de Xen ==<br />
<br />
* Vole/désactive les ports séries par défaut - ce qui est loin d'être pratique sur des serveurs dédiés, ou le port série est l'accès de secours en cas de problème réseau. Solution: ajouter xencons=tty6 dans le grub.conf (pour Xen 3.0 / Etch, apparemment corrigé dans Xen 3.2 / Lenny)<br />
* Les paquets Debian ne fournissent que des binaires avec support [http://en.wikipedia.org/wiki/Physical_Address_Extension PAE] activé. Si vous voulez tester sur votre portable à base de Pentium-M (sans support PAE), vous n'avez plus qu'à installer votre propre noyau, car les paquets Debian ne fonctionneront pas (compilés en mode PAE uniquement; erreurs ''PAE mode mismatch in Xen (xen=no Dom0=yes)'' ou ''Cannot execute a PAE-enabled kernel on a PAE-less CPU'' au boot). Utiliser <code>grep pae /proc/cpuinfo</code> pour voir si votre processeur gère PAE. C'est à se demander pourquoi une version de l'hyperviseur en mode non-PAE est disponible :/<br />
* Des ralentissements et des bugs au niveau du clavier dans certains cas, pas tout le temps, même avec libc6-xen: répétitions aléatoires de touches au moment de la frappe, ralentissement impressionnant de gnome-terminal.<br />
* Des problèmes bizarres avec perte de connexion réseau, des messages <code>xen_net memory squeeze in netback driver</code> sur la console, vraisemblablement dès que l'on utilise trop de mémoire (ici 4G/8G sur 32bit sur une machine 64bit, probablement avec APE. Une solution qui n'explique pas vraiment le problème (et qui apparement ne fonctionne pas pour tout le monde) consiste à limiter la mémoire du dom0 de manière identique en deux endroits (GRUB et config) [http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg360172.html]:<br />
** boot/grub/menu.lst: <code>xenhopt=dom0_mem=256M</code><br />
** /etc/xen/xend-config.sxp: <code>(dom0-min-mem 256)</code><br />
* Des <code>Kernel BUG at drivers/xen/core/evtchn.c:481</code> de temps à autres. Solution de contournement [http://lists.debian.org/debian-kerne/2007/02/msg00291.html]: limiter Dom0 à un processeur via <code>(dom0-cpus 1)</code> dans <code>/etc/xen/xend-config.sxp</code>. Je suis de moins en moins rassuré sur le fiabilité de ce truc.<br />
* Sous Debian, à chaque mise à jour de sécurité noyau avec nouvelle ABI (ex: 2.6.18-5-686 => 2.6.18-6-686), penser à mettre à jour <code>kernel</code> et <code>ramdisk</code> dans <code>/etc/xen/*.cfg</code>, et mettre à jour <code>/lib/modules</code> dans les DomU. Il n'y a pas de paquet générique indépendamment de la version, donc au niveau paquets ça donne:<br />
## Dom0<br />
aptitude install linux-image-xen-686 xen-linux-system-2.6.18-6-xen-686<br />
# fix /etc/xen/*.cfg, install DomU packages below, reboot<br />
aptitude purge linux-image-2.6.18-5-xen-686 linux-modules-2.6.18-5-xen-686 xen-linux-system-2.6.18-5-xen-686<br />
<br />
## DomU<br />
aptitude install linux-modules-2.6.18-6-xen-686<br />
aptitude purge linux-modules-2.6.18-5-xen-686<br />
# 'xm shutdown' (NOT reboot) and 'xm create' in Dom0<br />
<br />
== Migration / relocation ==<br />
<br />
La commande est<br />
xm migrate vm host<br />
xm migrate --live vm host<br />
<br />
Apparemment cela ne concerne que l'état mémoire de la machine virtuelle. Pour le disque, il faut utiliser un disque réseau, ou bien faire le déplacement des données à la main.<br />
<br />
Dans <code>/etc/xen/xend-config.sxp</code>, sur l'hôte distant, pour accepter la migration:<br />
(xend-relocation-server yes)<br />
(xend-relocation-port 8002)<br />
(xend-address '')<br />
(xend-relocation-hosts-allow '^your other host IP$')<br />
<br />
Dans le même ordre d'idée, il est possible de mettre un serveur en pause, par exemple au moment d'un reboot du Dom0. Une fois réactivée, la machine est restaurée à l'identique: l'uptime ne sera pas mis à zéro, les connexions TCP/IP seront même toujours valides!<br />
<br />
== Installation semi-manuelle avec l'image binaire officielle ==<br />
<br />
Le site officiel est xensource.com, mais est bourré de propagande liée à une obscure "vente" de produits "entreprise". Bref allez directement sur http://xen.xensource.com/ , puis sur la page de téléchargement. On prend ici une des tarballs binaires; choisissez 32bit, 32bit+pae ou 64bit en fonction de votre système.<br />
<br />
tar xzf xen-3....tar.gz<br />
cd dist<br />
./install.sh<br />
# Image initrd:<br />
depmod 2.6.16.29-xen<br />
update-initramfs -k 2.6.16.29-xen -ct<br />
update-grub<br />
<br />
Ça fonctionne, mais:<br />
* 2.6.16: carte réseau non gérée (malgré la présence du module concerné)<br />
* 2.6.18: carte réseau OK, mais des ''BUG'' en rafale dans la console à propos de vmalloc, et de notes de evbug.c dès qu'on touche au clavier - pas rassurant..<br />
<br />
== Installation manuelle ==<br />
<br />
Vous récupérez une version de Linux xenifiée, et vous la compilez comme d'habitude, avec un panneau menuconfig en plus pour paramétrer Xen.<br />
<br />
make world<br />
make install<br />
permet de recréer l'image binaire officielle.<br />
<br />
Pour recompiler avec une config perso? TODO. Le README propose:<br />
make linux-2.6-xen-config CONFIGMODE=menuconfig<br />
mais cela installe un .config assez lourd. Je préfèrerais un 'defconfig'.<br />
<br />
=== Quelle version du noyau Linux? ===<br />
<br />
Les tarballs officielles sont basées sur des noyaux relativement vieux (2.6.16 pour Xen 3.0, 2.6.18 pour Xen 3.1). On trouve quelques ''forward-ports'' chez RedHat: http://hg.et.redhat.com/kernel/ (utilisés notamment dans le noyau 2.6.18 de Etch).<br />
<br />
<br />
== Pour faire simple ==<br />
<br />
Vous pouvez toujours installer Xen depuis une instance de QEMU, mais lancée avec <code>-no-kqemu</code>; évidemment ça va ramer, mais tant que c'est le processeur et pas vous... :)<br />
<br />
<br />
== Mise à jour Etch -> Lenny ==<br />
<br />
Configurations mixtes:<br />
* Il est possible de lancer un domU Etch depuis un domU Lenny: conserver les noyaux dans le dom0<br />
* Il est possible de lancer un domU Lenny en kernel Etch: conserver les modules linux-module-xen dans le domU<br />
* Il n'est apparemment pas possible de lancer un domU Lenny en kernel Lenny depuis un dom0 Etch: mais il y avait différentes erreurs liées à Python, au support du nouveau Xen, etc., donc pas sûr à 100%<br />
<br />
Conclusion on peut mettre à jour le dom0 ou bien le domU en premier, c'est comme on veut, juste bien conserver les anciens noyaux (dom0) et les anciens modules (domU).<br />
<br />
=== Dom0 ===<br />
<br />
Après la mise à jour du système:<br />
apt-get install xen-linux-system-2.6.26-2-xen-686<br />
apt-get install xen-utils-3.2-1<br />
<br />
Puis modifier les lignes <code>kernel</code> et <code>ramdisk</code> dans <code>/etc/xen/*</code>:<br />
kernel = '/boot/vmlinuz-2.6.26-2-xen-686'<br />
ramdisk = '/boot/initrd.img-2.6.26-2-xen-686'<br />
<br />
=== DomU ===<br />
<br />
Choses à faire quand on passe du noyau 2.6.18 au noyau 2.6.26.<br />
<br />
Installer les nouveaux modules noyaux (utile pour iptables notamment):<br />
apt-get install linux-modules-xen-686<br />
# ou bien<br />
apt-get install linux-modules-xen-amd64<br />
<br />
Installez udev<br />
apt-get install udev<br />
<br />
Visiblement Xen nettoie <code>/dev</code> sans le repeupler proprement, du coup évidemment c'est le foutoir, avec des erreurs du type "Mount point '/dev/shm' does not exist. Skipping mount. (warning).", et en particulier <code>/dev/pts</code> n'est pas monté ce qui casse la connexion SSH (penser à utiliser la syntaxe <code>ssh you@host command</code> pour dépanner).<br />
<br />
Faites écouter getty sur <code>hvc0</code>, qui est selon toute vraisemblance <code>tty1</code> mais version Xen (histoire de faire simple). Dans votre <code>/etc/inittab</code>:<br />
1:2345:respawn:/sbin/getty 38400 hvc0<br />
<br />
== Afficher les informations de démarrage sur le port série ==<br />
<br />
Notre cible est le port série virtuel du serveur, détecté comme port série numéro 2 (ttyS1).<br />
<br />
Modifier <code>/boot/grub/menu.lst</code> comme suit:<br />
# xenhopt=com2=115200,8n1 console=com2,vga<br />
# xenkopt=console=tty0 console=hvc0<br />
Puis lancez:<br />
update-grub<br />
pour mettre à jour les entrées de noyau automatiques.<br />
<br />
<br />
Faites écouter un getty sur <code>hvc0</code> dans <code>/etc/inittab</code>:<br />
co:2345:respawn:/sbin/getty -h -L hvc0 115200 ansi<br />
<br />
== pygrub ==<br />
<br />
pygrub permet d'amorcer le domU à partir d'un noyau installé dans le domU (et non pas dans le dom0). Cela permet de gérer via APT/yum/etc. des noyaux d'autres distributions, d'autres versions de la distributions, d'autres architectures (32/64bit), etc. que le dom0. Cela permet également de générer des images initrd propres (en fonction du domU et pas du dom0). Les noyaux Xen du Dom0 restent utiles pour l'installation/bootstrap initiale du domU.<br />
<br />
Dans le domU:<br />
* Installer le noyau<br />
* Installer GRUB<br />
* Préparer un <code>/boot/grub/menu.lst</code> valide<br />
** On pourra utiliser <code>update-grub</code><br />
** Pour cela il est nécessaire de créer un faux /dev/sda (en plus des LVM-partitions sda1, sda2, etc):<br />
dd if=/dev/null of=/etc/xen/mbr/$name-sda bs=1M seek=1<br />
disk = [ ... 'file:/etc/xen/mbr/$name-sda,sda,w', ... ]<br />
* Inutile d'installer grub sur le MBR<br />
<br />
Dans le fichier de configuration du domU:<br />
* <code>bootloader='/usr/lib/xen-3.2-1/bin/pygrub'</code><br />
* commenter les lignes "kernel" et "ramdisk".<br />
* dans la section 'disk', positionner la partition contenant le noyau en premier<br />
<br />
== Autres méthodes d'amorçage ==<br />
<br />
* pypxeboot: amorçage par le réseau pour les invités Xen<br />
* cdrom: apparemment par le biais d'une image ISO<br />
<br />
D'après la page [http://wiki.debian.org/DebianInstaller/Xen Xen] du wiki Debian, Xen PV ne gère pas les installateurs des distrubutions directements, à la place celles-ci propose des solutions de contournement pour faire fonctionner l'installateur dans Xen PV. Xen HVM gère l'installateur sans modification.<br />
<br />
Bref, pour les PV on reste sur des méthodes en ligne de commande, sauf gros bricolage du D-I?<br />
<br />
== VNC ==<br />
<br />
* PV: regarder la configuration de <code>vfb</code> (virtualframe buffer)<br />
vfb = ['type=vnc,vncdisplay=2']<br />
vfb = ['type=vnc,vncunused=1']<br />
* HVM: en standard (<code>builder="hvm"</code>, <code>vnc=1</code>) ?<br />
<br />
== Liens ==<br />
<br />
* [http://wiki.kartbuilding.net/index.php/Debian_Etch_Xen_Install Debian Etch Xen Install]: config de base<br />
* [http://wiki.kartbuilding.net/index.php/Create_DomU Create DomU]: script de base<br />
* [http://wiki.debian.org/Xen Xen@Debian Wiki]: les paquets de base (pour du PAE)<br />
* [http://julien.danjou.info/xen.html Xen 3 for Debian]: une introduction; recommande LVM pour les images disques et le bridging pour le réseau <br />
* [http://free-electrons.com/community/howtos/raid-xen-ubuntu Introduction]: par Free-Electrons, également membres de l'APRIL; ils parlent de RAID mais utilisent des images disques (et non des partitions dédiées) - pas très efficace. Utilisent des adresses locales 10.0.0.X pour les DomU avec un NAT sur le Dom0.<br />
<br />
* [http://tx.downloads.xensource.com/downloads/docs/user Manuel de l'utilisateur]: spartiate<br />
<br />
* [http://phaq.phunsites.net/2007/06/30/xen-console-grabbded-devttys0/ Xen console grabbded /dev/ttyS0]: un truc pour réactiver le port série<br />
<br />
* [http://wiki.xensource.com/xenwiki/XenFaq#head-5f7176b3909cb0382cece43a6a8fc25a3a114e93 32bit and 64bit]: qui peut lancer qui?<br />
<br />
* [http://wiki.debian.org/Xen#Installationonlenny Xen - Debian Wiki]: notamment la section ''Additional note for domU on lenny using xen-tools'' (mais notez qu'elle ne dit pas comment corriger les installations existantes, ce que nous faisons [[#DomU|plus haut]]), et la partie sur le double affichage écran / port série</div>82.238.35.175https://doc.cliss21.com/index.php?title=Xen&diff=2716Xen2010-08-09T17:48:56Z<p>82.238.35.175 : /* Installation dans le cas où tout va bien */</p>
<hr />
<div>== Vocabulaire ==<br />
<br />
* Hyperviseur: socle d'exécution<br />
** Dom0 = hôte<br />
** DomU = invité = sous-système virtualisé<br />
<br />
Dom0 comme DomU sont des noyaux Linux modifiés pour passer par l'hyperviseur Xen à la place d'accéder directement aux ressources du système. Dom0 et DomU peuvent utiliser la même image noyau - c'est même souvent le cas.<br />
<br />
Avec une installation Debian Etch standard:<br />
* /boot/xen-3.0.3-1-i386-pae.gz : hyperviseur (on ''boot'' dessus)<br />
* /boot/vmlinuz-2.6.18-4-xen-686 : noyau Linux modifié à utiliser pour Dom0 et DomU<br />
** /boot/initrd.img-2.6.18-4-xen-686 : image ramdisk associée au noyau Linux modifié<br />
<br />
<br />
== Survie ==<br />
<br />
man xm<br />
<br />
* Lister les DomU:<br />
xm list<br />
* Lancer un Xen (chemin relatif à <code>/etc/xen/</code>):<br />
xm create auto/egroupware<br />
* Éteindre un Xen (utiliser le nom donné par <code>xm list</code>):<br />
xm shutdown NOM<br />
* Éteindre tous les Xen:<br />
xm shutdown -a<br />
* Redémarrer:<br />
xm reboot NOM<br />
* Entrer dans le Xen en mode console pour débugger (sortie comme dans telnet: <code>Ctrl + ]</code>):<br />
xm console NOM<br />
<br />
== Installation dans le cas où tout va bien ==<br />
<br />
Base:<br />
aptitude install xen-linux-system-2.6.26-2-xen-686 # noyau, hyperviseur, etc.<br />
aptitude install xen-utils # xend, xm...<br />
aptitude install xen-tools # outils pour créer un DomU<br />
<br />
Un test avec xen-create-image 3.2:<br />
xen-create-image --hostname test-drbd --kernel /boot/vmlinuz-2.6.26-2-xen-686 \<br />
--initrd /boot/initrd.img-2.6.26-2-xen-686 \<br />
--dist lenny --mirror http://monmiroir:9999/debian/ \<br />
--dhcp --lvm VG0 --size 4G \<br />
--role udev<br />
En 3.0:<br />
xen-create-image --hostname montest --kernel /boot/vmlinuz-2.6.18-6-xen-686 \<br />
--initrd /boot/initrd.img-2.6.18-6-xen-686 \<br />
--debootstrap --dist etch --mirror monmiroir:9999 \<br />
--dhcp --lvm VG0 --size 4G<br />
<br />
Survival:<br />
xm list # list running Xen instances<br />
xm create yourxen # start an instance<br />
xm console yourxen # enter an instance, type C-] to quit<br />
xm destroy yourxen # force shutdown<br />
<br />
== Post-install ==<br />
<br />
* Désactiver ou définir le mot de passe root<br />
* Copier les clefs SSH<br />
* Vérifier <code>/etc/hosts</code> (<code>127.0.0.1 fqdn host localhost</code>)<br />
* <code>dpkg-reconfigure debconf # priority -> medium, !high</code><br />
* Dans le DomU, dans <code>/etc/inittab</code>:<br />
1:2345:respawn:/sbin/getty 38400 hvc0<br />
<br />
En plus, pour Etch:<br />
* À la place de copier /lib/modules/2.6.26-N-xen-686 à chaque mise à jour de sécurité du noyau depuis le Dom0, installez linux-modules-xen-686/amd64 dans le DomU<br />
* Forcer la reconfiguration du fuseau horaire (tzconfig / dpkg-reconfigure tzdata)<br />
* Configurer le sources.list (s/stable/etch/)<br />
<br />
== Le pont / bridge ==<br />
<br />
auto br-xen<br />
iface br-xen inet static<br />
address 192.168.1.145<br />
netmask 255.255.255.0<br />
gateway 192.168.1.1<br />
bridge_ports eth0<br />
# bridge_ports none<br />
# optional<br />
bridge_stp off<br />
bridge_maxwait 0<br />
bridge_fd 0<br />
#bridge_hello 0<br />
<br />
== Les problèmes pénibles de Xen ==<br />
<br />
* Vole/désactive les ports séries par défaut - ce qui est loin d'être pratique sur des serveurs dédiés, ou le port série est l'accès de secours en cas de problème réseau. Solution: ajouter xencons=tty6 dans le grub.conf (pour Xen 3.0 / Etch, apparemment corrigé dans Xen 3.2 / Lenny)<br />
* Les paquets Debian ne fournissent que des binaires avec support [http://en.wikipedia.org/wiki/Physical_Address_Extension PAE] activé. Si vous voulez tester sur votre portable à base de Pentium-M (sans support PAE), vous n'avez plus qu'à installer votre propre noyau, car les paquets Debian ne fonctionneront pas (compilés en mode PAE uniquement; erreurs ''PAE mode mismatch in Xen (xen=no Dom0=yes)'' ou ''Cannot execute a PAE-enabled kernel on a PAE-less CPU'' au boot). Utiliser <code>grep pae /proc/cpuinfo</code> pour voir si votre processeur gère PAE. C'est à se demander pourquoi une version de l'hyperviseur en mode non-PAE est disponible :/<br />
* Des ralentissements et des bugs au niveau du clavier dans certains cas, pas tout le temps, même avec libc6-xen: répétitions aléatoires de touches au moment de la frappe, ralentissement impressionnant de gnome-terminal.<br />
* Des problèmes bizarres avec perte de connexion réseau, des messages <code>xen_net memory squeeze in netback driver</code> sur la console, vraisemblablement dès que l'on utilise trop de mémoire (ici 4G/8G sur 32bit sur une machine 64bit, probablement avec APE. Une solution qui n'explique pas vraiment le problème (et qui apparement ne fonctionne pas pour tout le monde) consiste à limiter la mémoire du dom0 de manière identique en deux endroits (GRUB et config) [http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg360172.html]:<br />
** boot/grub/menu.lst: <code>xenhopt=dom0_mem=256M</code><br />
** /etc/xen/xend-config.sxp: <code>(dom0-min-mem 256)</code><br />
* Des <code>Kernel BUG at drivers/xen/core/evtchn.c:481</code> de temps à autres. Solution de contournement [http://lists.debian.org/debian-kerne/2007/02/msg00291.html]: limiter Dom0 à un processeur via <code>(dom0-cpus 1)</code> dans <code>/etc/xen/xend-config.sxp</code>. Je suis de moins en moins rassuré sur le fiabilité de ce truc.<br />
* Sous Debian, à chaque mise à jour de sécurité noyau avec nouvelle ABI (ex: 2.6.18-5-686 => 2.6.18-6-686), penser à mettre à jour <code>kernel</code> et <code>ramdisk</code> dans <code>/etc/xen/*.cfg</code>, et mettre à jour <code>/lib/modules</code> dans les DomU. Il n'y a pas de paquet générique indépendamment de la version, donc au niveau paquets ça donne:<br />
## Dom0<br />
aptitude install linux-image-xen-686 xen-linux-system-2.6.18-6-xen-686<br />
# fix /etc/xen/*.cfg, install DomU packages below, reboot<br />
aptitude purge linux-image-2.6.18-5-xen-686 linux-modules-2.6.18-5-xen-686 xen-linux-system-2.6.18-5-xen-686<br />
<br />
## DomU<br />
aptitude install linux-modules-2.6.18-6-xen-686<br />
aptitude purge linux-modules-2.6.18-5-xen-686<br />
# 'xm shutdown' (NOT reboot) and 'xm create' in Dom0<br />
<br />
== Migration / relocation ==<br />
<br />
La commande est<br />
xm migrate vm host<br />
xm migrate --live vm host<br />
<br />
Apparemment cela ne concerne que l'état mémoire de la machine virtuelle. Pour le disque, il faut utiliser un disque réseau, ou bien faire le déplacement des données à la main.<br />
<br />
Dans <code>/etc/xen/xend-config.sxp</code>, sur l'hôte distant, pour accepter la migration:<br />
(xend-relocation-server yes)<br />
(xend-relocation-port 8002)<br />
(xend-address '')<br />
(xend-relocation-hosts-allow '^your other host IP$')<br />
<br />
Dans le même ordre d'idée, il est possible de mettre un serveur en pause, par exemple au moment d'un reboot du Dom0. Une fois réactivée, la machine est restaurée à l'identique: l'uptime ne sera pas mis à zéro, les connexions TCP/IP seront même toujours valides!<br />
<br />
== Installation semi-manuelle avec l'image binaire officielle ==<br />
<br />
Le site officiel est xensource.com, mais est bourré de propagande liée à une obscure "vente" de produits "entreprise". Bref allez directement sur http://xen.xensource.com/ , puis sur la page de téléchargement. On prend ici une des tarballs binaires; choisissez 32bit, 32bit+pae ou 64bit en fonction de votre système.<br />
<br />
tar xzf xen-3....tar.gz<br />
cd dist<br />
./install.sh<br />
# Image initrd:<br />
depmod 2.6.16.29-xen<br />
update-initramfs -k 2.6.16.29-xen -ct<br />
update-grub<br />
<br />
Ça fonctionne, mais:<br />
* 2.6.16: carte réseau non gérée (malgré la présence du module concerné)<br />
* 2.6.18: carte réseau OK, mais des ''BUG'' en rafale dans la console à propos de vmalloc, et de notes de evbug.c dès qu'on touche au clavier - pas rassurant..<br />
<br />
== Installation manuelle ==<br />
<br />
Vous récupérez une version de Linux xenifiée, et vous la compilez comme d'habitude, avec un panneau menuconfig en plus pour paramétrer Xen.<br />
<br />
make world<br />
make install<br />
permet de recréer l'image binaire officielle.<br />
<br />
Pour recompiler avec une config perso? TODO. Le README propose:<br />
make linux-2.6-xen-config CONFIGMODE=menuconfig<br />
mais cela installe un .config assez lourd. Je préfèrerais un 'defconfig'.<br />
<br />
=== Quelle version du noyau Linux? ===<br />
<br />
Les tarballs officielles sont basées sur des noyaux relativement vieux (2.6.16 pour Xen 3.0, 2.6.18 pour Xen 3.1). On trouve quelques ''forward-ports'' chez RedHat: http://hg.et.redhat.com/kernel/ (utilisés notamment dans le noyau 2.6.18 de Etch).<br />
<br />
<br />
== Pour faire simple ==<br />
<br />
Vous pouvez toujours installer Xen depuis une instance de QEMU, mais lancée avec <code>-no-kqemu</code>; évidemment ça va ramer, mais tant que c'est le processeur et pas vous... :)<br />
<br />
<br />
== Mise à jour Etch -> Lenny ==<br />
<br />
Configurations mixtes:<br />
* Il est possible de lancer un domU Etch depuis un domU Lenny: conserver les noyaux dans le dom0<br />
* Il est possible de lancer un domU Lenny en kernel Etch: conserver les modules linux-module-xen dans le domU<br />
* Il n'est apparemment pas possible de lancer un domU Lenny en kernel Lenny depuis un dom0 Etch: mais il y avait différentes erreurs liées à Python, au support du nouveau Xen, etc., donc pas sûr à 100%<br />
<br />
Conclusion on peut mettre à jour le dom0 ou bien le domU en premier, c'est comme on veut, juste bien conserver les anciens noyaux (dom0) et les anciens modules (domU).<br />
<br />
=== Dom0 ===<br />
<br />
Après la mise à jour du système:<br />
apt-get install xen-linux-system-2.6.26-2-xen-686<br />
apt-get install xen-utils-3.2-1<br />
<br />
Puis modifier les lignes <code>kernel</code> et <code>ramdisk</code> dans <code>/etc/xen/*</code>:<br />
kernel = '/boot/vmlinuz-2.6.26-2-xen-686'<br />
ramdisk = '/boot/initrd.img-2.6.26-2-xen-686'<br />
<br />
=== DomU ===<br />
<br />
Choses à faire quand on passe du noyau 2.6.18 au noyau 2.6.26.<br />
<br />
Installer les nouveaux modules noyaux (utile pour iptables notamment):<br />
apt-get install linux-modules-xen-686<br />
# ou bien<br />
apt-get install linux-modules-xen-amd64<br />
<br />
Installez udev<br />
apt-get install udev<br />
<br />
Visiblement Xen nettoie <code>/dev</code> sans le repeupler proprement, du coup évidemment c'est le foutoir, avec des erreurs du type "Mount point '/dev/shm' does not exist. Skipping mount. (warning).", et en particulier <code>/dev/pts</code> n'est pas monté ce qui casse la connexion SSH (penser à utiliser la syntaxe <code>ssh you@host command</code> pour dépanner).<br />
<br />
Faites écouter getty sur <code>hvc0</code>, qui est selon toute vraisemblance <code>tty1</code> mais version Xen (histoire de faire simple). Dans votre <code>/etc/inittab</code>:<br />
1:2345:respawn:/sbin/getty 38400 hvc0<br />
<br />
== Afficher les informations de démarrage sur le port série ==<br />
<br />
Notre cible est le port série virtuel du serveur, détecté comme port série numéro 2 (ttyS1).<br />
<br />
Modifier <code>/boot/grub/menu.lst</code> comme suit:<br />
# xenhopt=com2=115200,8n1 console=com2,vga<br />
# xenkopt=console=tty0 console=hvc0<br />
Puis lancez:<br />
update-grub<br />
pour mettre à jour les entrées de noyau automatiques.<br />
<br />
<br />
Faites écouter un getty sur <code>hvc0</code> dans <code>/etc/inittab</code>:<br />
co:2345:respawn:/sbin/getty -h -L hvc0 115200 ansi<br />
<br />
== pygrub ==<br />
<br />
pygrub permet d'amorcer le domU à partir d'un noyau installé dans le domU (et non pas dans le dom0). Cela permet de gérer via APT/yum/etc. des noyaux d'autres distributions, d'autres versions de la distributions, d'autres architectures (32/64bit), etc. que le dom0. Cela permet également de générer des images initrd propres (en fonction du domU et pas du dom0). Les noyaux Xen du Dom0 restent utiles pour l'installation/bootstrap initiale du domU.<br />
<br />
Dans le domU:<br />
* Installer le noyau<br />
* Installer GRUB<br />
* Préparer un <code>/boot/grub/menu.lst</code> valide<br />
** On pourra utiliser <code>update-grub</code><br />
** Pour cela il est nécessaire de créer un faux /dev/sda (en plus des LVM-partitions sda1, sda2, etc):<br />
dd if=/dev/null of=/etc/xen/mbr/$name-sda bs=1M seek=1<br />
disk = [ ... 'file:/etc/xen/mbr/$name-sda,sda,w', ... ]<br />
* Inutile d'installer grub sur le MBR<br />
<br />
Dans le fichier de configuration du domU:<br />
* <code>bootloader='/usr/lib/xen-3.2-1/bin/pygrub'</code><br />
* commenter les lignes "kernel" et "ramdisk".<br />
* dans la section 'disk', positionner la partition contenant le noyau en premier<br />
<br />
== Autres méthodes d'amorçage ==<br />
<br />
* pypxeboot: amorçage par le réseau pour les invités Xen<br />
* cdrom: apparemment par le biais d'une image ISO<br />
<br />
D'après la page [http://wiki.debian.org/DebianInstaller/Xen Xen] du wiki Debian, Xen PV ne gère pas les installateurs des distrubutions directements, à la place celles-ci propose des solutions de contournement pour faire fonctionner l'installateur dans Xen PV. Xen HVM gère l'installateur sans modification.<br />
<br />
Bref, pour les PV on reste sur des méthodes en ligne de commande, sauf gros bricolage du D-I?<br />
<br />
== VNC ==<br />
<br />
* PV: regarder la configuration de <code>vfb</code> (virtualframe buffer)<br />
vfb = ['type=vnc,vncdisplay=2']<br />
vfb = ['type=vnc,vncunused=1']<br />
* HVM: en standard (<code>builder="hvm"</code>, <code>vnc=1</code>) ?<br />
<br />
== Liens ==<br />
<br />
* [http://wiki.kartbuilding.net/index.php/Debian_Etch_Xen_Install Debian Etch Xen Install]: config de base<br />
* [http://wiki.kartbuilding.net/index.php/Create_DomU Create DomU]: script de base<br />
* [http://wiki.debian.org/Xen Xen@Debian Wiki]: les paquets de base (pour du PAE)<br />
* [http://julien.danjou.info/xen.html Xen 3 for Debian]: une introduction; recommande LVM pour les images disques et le bridging pour le réseau <br />
* [http://free-electrons.com/community/howtos/raid-xen-ubuntu Introduction]: par Free-Electrons, également membres de l'APRIL; ils parlent de RAID mais utilisent des images disques (et non des partitions dédiées) - pas très efficace. Utilisent des adresses locales 10.0.0.X pour les DomU avec un NAT sur le Dom0.<br />
<br />
* [http://tx.downloads.xensource.com/downloads/docs/user Manuel de l'utilisateur]: spartiate<br />
<br />
* [http://phaq.phunsites.net/2007/06/30/xen-console-grabbded-devttys0/ Xen console grabbded /dev/ttyS0]: un truc pour réactiver le port série<br />
<br />
* [http://wiki.xensource.com/xenwiki/XenFaq#head-5f7176b3909cb0382cece43a6a8fc25a3a114e93 32bit and 64bit]: qui peut lancer qui?<br />
<br />
* [http://wiki.debian.org/Xen#Installationonlenny Xen - Debian Wiki]: notamment la section ''Additional note for domU on lenny using xen-tools'' (mais notez qu'elle ne dit pas comment corriger les installations existantes, ce que nous faisons [[#DomU|plus haut]]), et la partie sur le double affichage écran / port série</div>82.238.35.175https://doc.cliss21.com/index.php?title=Serveur_de_courriel&diff=404Serveur de courriel2010-08-07T08:19:59Z<p>82.238.35.175 : /* Supprimer les comptes inactifs postfixadmin */</p>
<hr />
<div>Le but de l'article est de mettre en place un serveur de courriel relativement simple, de la manière la plus automatisée possible.<br />
<br />
Scripts à venir.<br />
<br />
On se basera sur Postfixadmin (la version SVN, sous GNU GPL, pas la dernière stable), ainsi que sur l'excellent [http://high5.net/howto/ HOWTO] associé, qui n'a pour défaut que d'être un peu fouillis (gère Debian et FreeBSD suivant plusieurs variantes de configuration), et surtout de ne pas être automatisé! :)<br />
<br />
* [[Postfix]]<br />
* [[Postfix et SASL]]: tentative de compréhension<br />
* [[Postfix et sécurité]]: autre tentative de compréhension<br />
* [[SPAM]]<br />
* [[Cyrus]]: administration manuelle des BALs<br />
<br />
==Liens==<br />
<br />
* http://genco.gen.tc/postfix_sasl_courier_mysql_virtual_maildrop_squirrelmail_quota.php: un autre HOWTO<br />
* http://www.littleboboy.net/?2005/04/15/54-postfix-courier-imap: un autre HOWTO en français cette fois<br />
* http://www.i-boot.net/mailserver/ : installation à base de LDAP liée avec EGroupWare, licence pas claire<br />
<br />
== Supprimer les comptes inactifs postfixadmin ==<br />
<br />
Il y a un script dans <code>ADDITIONS/</code> mais il nécessite une configuration.<br />
cd /var/mail/virtual && ls | while read email; do \<br />
if [ $(mysql postfix -N -B -e "SELECT count(*) FROM mailbox WHERE username='$email';") = 0 ]; then \<br />
echo $email; fi; done<br />
Faites un <code>rm -rf</code> plutôt qu'un <code>echo</code> quand vous avez vérifié :)<br />
<br />
== Occupation disque ==<br />
<br />
cd /var/mail/virtual/ && du -s */ | sort -rn | awk '{ print int($1 / 1024) "M\t"$2 }'<br />
<br />
== Partager le courriel en interne ==<br />
<br />
* Installer courier-imap sur un poste (serveur)<br />
* Utiliser un même compte sur chacun des postes clients<br />
* Dans /etc/courier/imapd : IMAP_ENHANCEDIDLE=1 , pour synchroniser les différents clients immédiatement après chaque opération (ajout, suppression...).<br />
<br />
== Test/debug d'une configuration ==<br />
<br />
* Exim (résultat sur la sortie standard; génial!):<br />
sendmail -bt adresse # -bt == 'back-trace'<br />
sendmail -bt -d adresse # -d == 'debug', more verbose<br />
* Postfix<br />
** Tester l'envoi sur une adresse, résultat par mail [http://www.postfix.org/DEBUG_README.html#trace_mail], nettement moins pratique qu'Exim:<br />
sendmail -bv adresse # sans envoi réel<br />
sendmail -v adresse # avec envoi réel<br />
** Couper l'envoi des e-mails sur une configuration de test:<br />
echo "/.*/ DISCARD" > /etc/postfix/access-regexp<br />
echo "smtpd_client_restrictions = check_recipient_access regexp:/etc/postfix/access-regexp" >> /etc/postfix/main.cf<br />
** Couper les e-mails en sortie sur une configuration de test (sauf relay_domains), dans <code>main.cf</code>:<br />
default_transport = discard:<br />
* Courier, ajouter dans <code>/etc/courier/imapd</code>:<br />
IMAPDEBUGFILE=imapdebug.txt<br />
<br />
En cas de test d'un programme qui envoie des courriels, pour éviter tout débordement, on peut ignorer silencieusement tout les courriels externes. Sous Postfix:<br />
default_transport = discard:<br />
À compléter éventuellement avec un mouchard qui récupère tous les courriels émis:<br />
always_bcc = postfix-trace</div>82.238.35.175https://doc.cliss21.com/index.php?title=Serveur_de_courriel&diff=403Serveur de courriel2010-08-07T08:17:40Z<p>82.238.35.175 : /* Supprimer les comptes inactifs postfixadmin */</p>
<hr />
<div>Le but de l'article est de mettre en place un serveur de courriel relativement simple, de la manière la plus automatisée possible.<br />
<br />
Scripts à venir.<br />
<br />
On se basera sur Postfixadmin (la version SVN, sous GNU GPL, pas la dernière stable), ainsi que sur l'excellent [http://high5.net/howto/ HOWTO] associé, qui n'a pour défaut que d'être un peu fouillis (gère Debian et FreeBSD suivant plusieurs variantes de configuration), et surtout de ne pas être automatisé! :)<br />
<br />
* [[Postfix]]<br />
* [[Postfix et SASL]]: tentative de compréhension<br />
* [[Postfix et sécurité]]: autre tentative de compréhension<br />
* [[SPAM]]<br />
* [[Cyrus]]: administration manuelle des BALs<br />
<br />
==Liens==<br />
<br />
* http://genco.gen.tc/postfix_sasl_courier_mysql_virtual_maildrop_squirrelmail_quota.php: un autre HOWTO<br />
* http://www.littleboboy.net/?2005/04/15/54-postfix-courier-imap: un autre HOWTO en français cette fois<br />
* http://www.i-boot.net/mailserver/ : installation à base de LDAP liée avec EGroupWare, licence pas claire<br />
<br />
== Supprimer les comptes inactifs postfixadmin ==<br />
<br />
Il y a un script dans <code>ADDITIONS/</code> mais il nécessite une configuration.<br />
cd /var/mail/virtual && ls | while read email; do \<br />
if [ $(mysql postfix -N -B -e "SELECT count(*) FROM mailbox WHERE username='$email';") = 0 ]; then \<br />
echo $email; fi; done<br />
Faites un <code>rm -rf</code> plutôt qu'un <code>echo</code> quand vous avez vérifié :)<br />
<br />
== Partager le courriel en interne ==<br />
<br />
* Installer courier-imap sur un poste (serveur)<br />
* Utiliser un même compte sur chacun des postes clients<br />
* Dans /etc/courier/imapd : IMAP_ENHANCEDIDLE=1 , pour synchroniser les différents clients immédiatement après chaque opération (ajout, suppression...).<br />
<br />
== Test/debug d'une configuration ==<br />
<br />
* Exim (résultat sur la sortie standard; génial!):<br />
sendmail -bt adresse # -bt == 'back-trace'<br />
sendmail -bt -d adresse # -d == 'debug', more verbose<br />
* Postfix<br />
** Tester l'envoi sur une adresse, résultat par mail [http://www.postfix.org/DEBUG_README.html#trace_mail], nettement moins pratique qu'Exim:<br />
sendmail -bv adresse # sans envoi réel<br />
sendmail -v adresse # avec envoi réel<br />
** Couper l'envoi des e-mails sur une configuration de test:<br />
echo "/.*/ DISCARD" > /etc/postfix/access-regexp<br />
echo "smtpd_client_restrictions = check_recipient_access regexp:/etc/postfix/access-regexp" >> /etc/postfix/main.cf<br />
** Couper les e-mails en sortie sur une configuration de test (sauf relay_domains), dans <code>main.cf</code>:<br />
default_transport = discard:<br />
* Courier, ajouter dans <code>/etc/courier/imapd</code>:<br />
IMAPDEBUGFILE=imapdebug.txt<br />
<br />
En cas de test d'un programme qui envoie des courriels, pour éviter tout débordement, on peut ignorer silencieusement tout les courriels externes. Sous Postfix:<br />
default_transport = discard:<br />
À compléter éventuellement avec un mouchard qui récupère tous les courriels émis:<br />
always_bcc = postfix-trace</div>82.238.35.175https://doc.cliss21.com/index.php?title=Serveur_de_courriel&diff=402Serveur de courriel2010-08-07T08:17:07Z<p>82.238.35.175 : /* Liens */</p>
<hr />
<div>Le but de l'article est de mettre en place un serveur de courriel relativement simple, de la manière la plus automatisée possible.<br />
<br />
Scripts à venir.<br />
<br />
On se basera sur Postfixadmin (la version SVN, sous GNU GPL, pas la dernière stable), ainsi que sur l'excellent [http://high5.net/howto/ HOWTO] associé, qui n'a pour défaut que d'être un peu fouillis (gère Debian et FreeBSD suivant plusieurs variantes de configuration), et surtout de ne pas être automatisé! :)<br />
<br />
* [[Postfix]]<br />
* [[Postfix et SASL]]: tentative de compréhension<br />
* [[Postfix et sécurité]]: autre tentative de compréhension<br />
* [[SPAM]]<br />
* [[Cyrus]]: administration manuelle des BALs<br />
<br />
==Liens==<br />
<br />
* http://genco.gen.tc/postfix_sasl_courier_mysql_virtual_maildrop_squirrelmail_quota.php: un autre HOWTO<br />
* http://www.littleboboy.net/?2005/04/15/54-postfix-courier-imap: un autre HOWTO en français cette fois<br />
* http://www.i-boot.net/mailserver/ : installation à base de LDAP liée avec EGroupWare, licence pas claire<br />
<br />
== Supprimer les comptes inactifs postfixadmin ==<br />
<br />
Il y a un script dans <code>ADDITIONS/</code> mais il nécessite une configuration.<br />
cd /var/mail/virtual && ls | while read email; do if [ $(mysql postfix -N -B -e "SELECT count(*) FROM mailbox WHERE username='$email';") = 0 ]; then echo $email; fi; done<br />
Faites un <code>rm -rf</code> plutôt qu'un <code>echo</code> quand vous avez vérifié :)<br />
<br />
== Partager le courriel en interne ==<br />
<br />
* Installer courier-imap sur un poste (serveur)<br />
* Utiliser un même compte sur chacun des postes clients<br />
* Dans /etc/courier/imapd : IMAP_ENHANCEDIDLE=1 , pour synchroniser les différents clients immédiatement après chaque opération (ajout, suppression...).<br />
<br />
== Test/debug d'une configuration ==<br />
<br />
* Exim (résultat sur la sortie standard; génial!):<br />
sendmail -bt adresse # -bt == 'back-trace'<br />
sendmail -bt -d adresse # -d == 'debug', more verbose<br />
* Postfix<br />
** Tester l'envoi sur une adresse, résultat par mail [http://www.postfix.org/DEBUG_README.html#trace_mail], nettement moins pratique qu'Exim:<br />
sendmail -bv adresse # sans envoi réel<br />
sendmail -v adresse # avec envoi réel<br />
** Couper l'envoi des e-mails sur une configuration de test:<br />
echo "/.*/ DISCARD" > /etc/postfix/access-regexp<br />
echo "smtpd_client_restrictions = check_recipient_access regexp:/etc/postfix/access-regexp" >> /etc/postfix/main.cf<br />
** Couper les e-mails en sortie sur une configuration de test (sauf relay_domains), dans <code>main.cf</code>:<br />
default_transport = discard:<br />
* Courier, ajouter dans <code>/etc/courier/imapd</code>:<br />
IMAPDEBUGFILE=imapdebug.txt<br />
<br />
En cas de test d'un programme qui envoie des courriels, pour éviter tout débordement, on peut ignorer silencieusement tout les courriels externes. Sous Postfix:<br />
default_transport = discard:<br />
À compléter éventuellement avec un mouchard qui récupère tous les courriels émis:<br />
always_bcc = postfix-trace</div>82.238.35.175https://doc.cliss21.com/index.php?title=DRBD&diff=3395DRBD2010-08-07T06:50:29Z<p>82.238.35.175 : /* Montage au démarrage */</p>
<hr />
<div>Distributed Replicated Block Device<br />
<br />
apt-get install drbd8-utils drbd8-modules-2.6-686<br />
# ou variante:<br />
apt-get install drbd8-utils drbd8-modules-2.6-vserver-686<br />
<br />
== Configuration simple ==<br />
<br />
Primary/Secondary (il existe aussi Primary/Primary):<br />
<br />
<pre><br />
global { <br />
usage-count yes;<br />
}<br />
common {<br />
protocol C;<br />
syncer { rate 40M; }<br />
disk { on-io-error detach; }<br />
startup {<br />
wfc-timeout 15;<br />
degr-wfc-timeout 15;<br />
#outdated-wfc-timeout 15; # not in DRBD 8.0/Lenny<br />
}<br />
}<br />
resource r0 {<br />
startup { become-primary-on VM1; }<br />
on VM1 {<br />
device /dev/drbd0;<br />
disk /dev/VG0/test;<br />
address 192.168.101.115:7789;<br />
meta-disk /dev/VG0/test-drbdmeta[0];<br />
}<br />
on VM2 {<br />
device /dev/drbd0;<br />
disk /dev/VG0/test;<br />
address 192.168.101.118:7789;<br />
meta-disk /dev/VG0/test-drbdmeta[0];<br />
}<br />
}<br />
</pre><br />
<br />
== Méta-données ==<br />
<br />
Si vous utilisez des méta-données externes, vous aurez [http://www.drbd.org/users-guide/ch-internals.html#s-meta-data-size calculé] que le volume dédié n'a pas besoin d'être bien grand.<br />
<br />
Cependant, il faut noter que le volume doit être au minimum to 128Mo très précisément, même pour le plus petit volume DRBD.<br />
<br />
== DRBD par dessus LVM ==<br />
<br />
Snapshots LVM d'un volume [[DRBD]]:<br />
* http://thread.gmane.org/gmane.comp.linux.drbd/6175 : en 2004<br />
* http://www.mail-archive.com/drbd-user@lists.linbit.com/msg00277.html : en 2009<br />
<br />
Ce que je comprend:<br />
* léger risque d'incohérence du snapshot<br />
* pas de risque d'incohérence des données maîtres<br />
<br />
En pratique, pour avoir un backup cohérent à partir du noeud secondaire:<br />
lvcreate -s VG0/test -n test-snapshot -L 5G<br />
mount /dev/VG0/test-snapshot -o ro /mnt/snapshots/test # ro par parano<br />
# backup avec rsync...<br />
umount /mnt/snapshots/test<br />
lvremove VG0/test-snapshot<br />
<br />
== Recharger la configuration ==<br />
<br />
Utiliser:<br />
drbdadm adjust r0<br />
<br />
Attention: comme indiqué [http://www.drbd.org/users-guide/s-configure-io-error-behavior.html ici], s'il y a un changement ''dans une section <code>disk</code>'', les versions < 8.3.1 lancent une resynchronization complète. Pour éviter cela, passer le primaire en secondaire (donc les deux noeuds en secondaire) avant de lancer <code>adjust</code>; cela implique de démonter toutes les volumes DRBD actifs.<br />
<br />
== Simuler des erreurs d'entrées/sorties ==<br />
<br />
Cf. http://lists.linbit.com/pipermail/drbd-dev/2009-July/001073.html<br />
<br />
<pre><br />
+ The actual simulation of IO errors is done by writing 3 values to<br />
+ /sys/module/drbd/parameters/<br />
+<br />
+ enable_faults: bitmask of...<br />
+ 1 meta data write<br />
+ 2 read<br />
+ 4 resync data write<br />
+ 8 read<br />
+ 16 data write<br />
+ 32 data read<br />
+ 64 read ahead<br />
+ 128 kmalloc of bitmap<br />
+ 256 allocation of EE (epoch_entries)<br />
+<br />
+ fault_devs: bitmask of minor numbers<br />
+ fault_rate: frequency in percent<br />
+<br />
+ Example: Simulate data write errors on /dev/drbd0 with a probability of 5%.<br />
+ echo 16 > /sys/module/drbd/parameters/enable_faults<br />
+ echo 1 > /sys/module/drbd/parameters/fault_devs<br />
+ echo 5 > /sys/module/drbd/parameters/fault_rate<br />
</pre><br />
<br />
L'exemple occasionne une erreur disque au bout de quelques accès disque.<br />
drbd0: Notified peer that my disk is broken<br />
<br />
== Gérer des erreurs d'entrées/sorties ==<br />
<br />
Cas 1 (configuration par défaut, mais n'est plus recommandée):<br />
<br />
disk { on-io-error pass_on; }<br />
<br />
Dans ce cas, les erreurs sont passées au système de fichiers, qui habituellement va se remonter en lecture seule. D'après mes tests, cependant, même avec <code>-o errors=remount-ro</code>, le système de fichiers s'est corrompu avec moult messages de drbd0 mais ''sans'' que le système de fichiers ne passe en lecture seule.<br />
<br />
Cas 2:<br />
<br />
disk { on-io-error detach; }<br />
<br />
Dans ce cas le disque continue de fonctionner de manière transparente sur le secondaire, en passant par le réseau (mode "diskless").<br />
<br />
Cas 3:<br />
<br />
disk { on-io-error call-local-io-error; }<br />
<br />
Dans ce cas DRBD appelle un script spécifié via <code>local-io-error</code>.<br />
<br />
== Montage au démarrage ==<br />
<br />
* Dans <code>/etc/fstab</code> faire attention:<br />
** de bien faire référence au volume DRBD (pas au volume physique)<br />
** de ne pas demander un fsck (mettre les deux derniers champs à <code>0</code>) car drbd n'est pas activé au moment où fstab est utilisé, ce qui va causerait une erreur<br />
* Dans l'ordre de démarrage, positionner les services dépendant de DRBD (ex: vserver) après lui<br />
* Rajouter un script au démarrage pour finir de monter les volumes DRBD, par exemple:<br />
<pre><br />
cat <<EOF > /etc/init.d/drbdmount<br />
#!/bin/bash<br />
if [ "$1" = "start" ]; then mount -a; fi<br />
EOF<br />
chmod 755 /etc/init.d/drbdmount<br />
update-rc.d -f vprocunhide remove<br />
update-rc.d -f vservers-default remove<br />
# Put it after the 'drbd' init script<br />
update-rc.d drbdmount defaults 75<br />
update-rc.d vprocunhide defaults 80<br />
update-rc.d vservers-default defaults 80<br />
</pre><br />
<br />
== Supervision ==<br />
<br />
La supervision semble n'être prévue que par le biais de Heartbeat/Pacemaker. Quelques événements peuvent être notifiés par l'intermédiaires des ''handlers'', mais pas tous.<br />
<br />
La commande <code>drbdsetup /dev/drbd0 events</code> permet de récupérer de manière succinte tous les événements qui se produisent.<br />
On peut l'utiliser de manière très rudimentaire dans le script suivant qui tournera en tâche de fond:<br />
<br />
<pre><br />
#!/bin/bash<br />
for drbdX in /dev/drbd*; do<br />
(drbdsetup $drbdX events | while read line; do echo $line | mail -s "$(hostname) $drbdX" you@domain.tld; done)&<br />
sleep 1<br />
done<br />
</pre><br />
<br />
Faire un <code>killall drbdsetup</code> pour l'arrêter.<br />
<br />
== Liens ==<br />
<br />
* [http://www.drbd.org/users-guide/ The DRBD User's Guide]<br />
* [[LVM]]</div>82.238.35.175https://doc.cliss21.com/index.php?title=DRBD&diff=3394DRBD2010-08-07T06:46:01Z<p>82.238.35.175 : /* Configuration simple */</p>
<hr />
<div>Distributed Replicated Block Device<br />
<br />
apt-get install drbd8-utils drbd8-modules-2.6-686<br />
# ou variante:<br />
apt-get install drbd8-utils drbd8-modules-2.6-vserver-686<br />
<br />
== Configuration simple ==<br />
<br />
Primary/Secondary (il existe aussi Primary/Primary):<br />
<br />
<pre><br />
global { <br />
usage-count yes;<br />
}<br />
common {<br />
protocol C;<br />
syncer { rate 40M; }<br />
disk { on-io-error detach; }<br />
startup {<br />
wfc-timeout 15;<br />
degr-wfc-timeout 15;<br />
#outdated-wfc-timeout 15; # not in DRBD 8.0/Lenny<br />
}<br />
}<br />
resource r0 {<br />
startup { become-primary-on VM1; }<br />
on VM1 {<br />
device /dev/drbd0;<br />
disk /dev/VG0/test;<br />
address 192.168.101.115:7789;<br />
meta-disk /dev/VG0/test-drbdmeta[0];<br />
}<br />
on VM2 {<br />
device /dev/drbd0;<br />
disk /dev/VG0/test;<br />
address 192.168.101.118:7789;<br />
meta-disk /dev/VG0/test-drbdmeta[0];<br />
}<br />
}<br />
</pre><br />
<br />
== Méta-données ==<br />
<br />
Si vous utilisez des méta-données externes, vous aurez [http://www.drbd.org/users-guide/ch-internals.html#s-meta-data-size calculé] que le volume dédié n'a pas besoin d'être bien grand.<br />
<br />
Cependant, il faut noter que le volume doit être au minimum to 128Mo très précisément, même pour le plus petit volume DRBD.<br />
<br />
== DRBD par dessus LVM ==<br />
<br />
Snapshots LVM d'un volume [[DRBD]]:<br />
* http://thread.gmane.org/gmane.comp.linux.drbd/6175 : en 2004<br />
* http://www.mail-archive.com/drbd-user@lists.linbit.com/msg00277.html : en 2009<br />
<br />
Ce que je comprend:<br />
* léger risque d'incohérence du snapshot<br />
* pas de risque d'incohérence des données maîtres<br />
<br />
En pratique, pour avoir un backup cohérent à partir du noeud secondaire:<br />
lvcreate -s VG0/test -n test-snapshot -L 5G<br />
mount /dev/VG0/test-snapshot -o ro /mnt/snapshots/test # ro par parano<br />
# backup avec rsync...<br />
umount /mnt/snapshots/test<br />
lvremove VG0/test-snapshot<br />
<br />
== Recharger la configuration ==<br />
<br />
Utiliser:<br />
drbdadm adjust r0<br />
<br />
Attention: comme indiqué [http://www.drbd.org/users-guide/s-configure-io-error-behavior.html ici], s'il y a un changement ''dans une section <code>disk</code>'', les versions < 8.3.1 lancent une resynchronization complète. Pour éviter cela, passer le primaire en secondaire (donc les deux noeuds en secondaire) avant de lancer <code>adjust</code>; cela implique de démonter toutes les volumes DRBD actifs.<br />
<br />
== Simuler des erreurs d'entrées/sorties ==<br />
<br />
Cf. http://lists.linbit.com/pipermail/drbd-dev/2009-July/001073.html<br />
<br />
<pre><br />
+ The actual simulation of IO errors is done by writing 3 values to<br />
+ /sys/module/drbd/parameters/<br />
+<br />
+ enable_faults: bitmask of...<br />
+ 1 meta data write<br />
+ 2 read<br />
+ 4 resync data write<br />
+ 8 read<br />
+ 16 data write<br />
+ 32 data read<br />
+ 64 read ahead<br />
+ 128 kmalloc of bitmap<br />
+ 256 allocation of EE (epoch_entries)<br />
+<br />
+ fault_devs: bitmask of minor numbers<br />
+ fault_rate: frequency in percent<br />
+<br />
+ Example: Simulate data write errors on /dev/drbd0 with a probability of 5%.<br />
+ echo 16 > /sys/module/drbd/parameters/enable_faults<br />
+ echo 1 > /sys/module/drbd/parameters/fault_devs<br />
+ echo 5 > /sys/module/drbd/parameters/fault_rate<br />
</pre><br />
<br />
L'exemple occasionne une erreur disque au bout de quelques accès disque.<br />
drbd0: Notified peer that my disk is broken<br />
<br />
== Gérer des erreurs d'entrées/sorties ==<br />
<br />
Cas 1 (configuration par défaut, mais n'est plus recommandée):<br />
<br />
disk { on-io-error pass_on; }<br />
<br />
Dans ce cas, les erreurs sont passées au système de fichiers, qui habituellement va se remonter en lecture seule. D'après mes tests, cependant, même avec <code>-o errors=remount-ro</code>, le système de fichiers s'est corrompu avec moult messages de drbd0 mais ''sans'' que le système de fichiers ne passe en lecture seule.<br />
<br />
Cas 2:<br />
<br />
disk { on-io-error detach; }<br />
<br />
Dans ce cas le disque continue de fonctionner de manière transparente sur le secondaire, en passant par le réseau (mode "diskless").<br />
<br />
Cas 3:<br />
<br />
disk { on-io-error call-local-io-error; }<br />
<br />
Dans ce cas DRBD appelle un script spécifié via <code>local-io-error</code>.<br />
<br />
== Montage au démarrage ==<br />
<br />
* Dans <code>/etc/fstab</code> faire attention:<br />
** de bien faire référence au volume DRBD (pas au volume physique)<br />
** de ne pas demander un fsck (mettre les deux derniers champs à <code>0</code>) car drbd n'est pas activé au moment où fstab est utilisé, ce qui va causerait une erreur<br />
* Dans l'ordre de démarrage, positionner les services dépendant de DRBD (ex: vserver) après lui<br />
* Rajouter un script au démarrage pour finir de monter les volumes DRBD, par exemple:<br />
<pre><br />
cat <<EOF > /etc/init.d/drbdmount<br />
#!/bin/bash<br />
if [ "$1" = "start" ]; then mount -a; fi<br />
EOF<br />
chmod 755 /etc/init.d/drbdmount<br />
update-rc.d drbdmount defaults 19<br />
</pre><br />
<br />
== Supervision ==<br />
<br />
La supervision semble n'être prévue que par le biais de Heartbeat/Pacemaker. Quelques événements peuvent être notifiés par l'intermédiaires des ''handlers'', mais pas tous.<br />
<br />
La commande <code>drbdsetup /dev/drbd0 events</code> permet de récupérer de manière succinte tous les événements qui se produisent.<br />
On peut l'utiliser de manière très rudimentaire dans le script suivant qui tournera en tâche de fond:<br />
<br />
<pre><br />
#!/bin/bash<br />
for drbdX in /dev/drbd*; do<br />
(drbdsetup $drbdX events | while read line; do echo $line | mail -s "$(hostname) $drbdX" you@domain.tld; done)&<br />
sleep 1<br />
done<br />
</pre><br />
<br />
Faire un <code>killall drbdsetup</code> pour l'arrêter.<br />
<br />
== Liens ==<br />
<br />
* [http://www.drbd.org/users-guide/ The DRBD User's Guide]<br />
* [[LVM]]</div>82.238.35.175https://doc.cliss21.com/index.php?title=DRBD&diff=3393DRBD2010-08-07T06:38:41Z<p>82.238.35.175 : /* Montage au démarrage */</p>
<hr />
<div>Distributed Replicated Block Device<br />
<br />
apt-get install drbd8-utils drbd8-modules-2.6-686<br />
# ou variante:<br />
apt-get install drbd8-utils drbd8-modules-2.6-vserver-686<br />
<br />
== Configuration simple ==<br />
<br />
Primary/Secondary (il existe aussi Primary/Primary):<br />
<br />
<pre><br />
global { <br />
usage-count yes;<br />
}<br />
common {<br />
protocol C;<br />
syncer { rate 40M; }<br />
disk { on-io-error: detach; }<br />
startup {<br />
wfc-timeout 15;<br />
degr-wfc-timeout 15;<br />
#outdated-wfc-timeout 15; # not in DRBD 8.0/Lenny<br />
}<br />
}<br />
resource r0 {<br />
startup { become-primary-on VM1; }<br />
on VM1 {<br />
device /dev/drbd0;<br />
disk /dev/VG0/test;<br />
address 192.168.101.115:7789;<br />
meta-disk /dev/VG0/test-drbdmeta[0];<br />
}<br />
on VM2 {<br />
device /dev/drbd0;<br />
disk /dev/VG0/test;<br />
address 192.168.101.118:7789;<br />
meta-disk /dev/VG0/test-drbdmeta[0];<br />
}<br />
}<br />
</pre><br />
<br />
== Méta-données ==<br />
<br />
Si vous utilisez des méta-données externes, vous aurez [http://www.drbd.org/users-guide/ch-internals.html#s-meta-data-size calculé] que le volume dédié n'a pas besoin d'être bien grand.<br />
<br />
Cependant, il faut noter que le volume doit être au minimum to 128Mo très précisément, même pour le plus petit volume DRBD.<br />
<br />
== DRBD par dessus LVM ==<br />
<br />
Snapshots LVM d'un volume [[DRBD]]:<br />
* http://thread.gmane.org/gmane.comp.linux.drbd/6175 : en 2004<br />
* http://www.mail-archive.com/drbd-user@lists.linbit.com/msg00277.html : en 2009<br />
<br />
Ce que je comprend:<br />
* léger risque d'incohérence du snapshot<br />
* pas de risque d'incohérence des données maîtres<br />
<br />
En pratique, pour avoir un backup cohérent à partir du noeud secondaire:<br />
lvcreate -s VG0/test -n test-snapshot -L 5G<br />
mount /dev/VG0/test-snapshot -o ro /mnt/snapshots/test # ro par parano<br />
# backup avec rsync...<br />
umount /mnt/snapshots/test<br />
lvremove VG0/test-snapshot<br />
<br />
== Recharger la configuration ==<br />
<br />
Utiliser:<br />
drbdadm adjust r0<br />
<br />
Attention: comme indiqué [http://www.drbd.org/users-guide/s-configure-io-error-behavior.html ici], s'il y a un changement ''dans une section <code>disk</code>'', les versions < 8.3.1 lancent une resynchronization complète. Pour éviter cela, passer le primaire en secondaire (donc les deux noeuds en secondaire) avant de lancer <code>adjust</code>; cela implique de démonter toutes les volumes DRBD actifs.<br />
<br />
== Simuler des erreurs d'entrées/sorties ==<br />
<br />
Cf. http://lists.linbit.com/pipermail/drbd-dev/2009-July/001073.html<br />
<br />
<pre><br />
+ The actual simulation of IO errors is done by writing 3 values to<br />
+ /sys/module/drbd/parameters/<br />
+<br />
+ enable_faults: bitmask of...<br />
+ 1 meta data write<br />
+ 2 read<br />
+ 4 resync data write<br />
+ 8 read<br />
+ 16 data write<br />
+ 32 data read<br />
+ 64 read ahead<br />
+ 128 kmalloc of bitmap<br />
+ 256 allocation of EE (epoch_entries)<br />
+<br />
+ fault_devs: bitmask of minor numbers<br />
+ fault_rate: frequency in percent<br />
+<br />
+ Example: Simulate data write errors on /dev/drbd0 with a probability of 5%.<br />
+ echo 16 > /sys/module/drbd/parameters/enable_faults<br />
+ echo 1 > /sys/module/drbd/parameters/fault_devs<br />
+ echo 5 > /sys/module/drbd/parameters/fault_rate<br />
</pre><br />
<br />
L'exemple occasionne une erreur disque au bout de quelques accès disque.<br />
drbd0: Notified peer that my disk is broken<br />
<br />
== Gérer des erreurs d'entrées/sorties ==<br />
<br />
Cas 1 (configuration par défaut, mais n'est plus recommandée):<br />
<br />
disk { on-io-error pass_on; }<br />
<br />
Dans ce cas, les erreurs sont passées au système de fichiers, qui habituellement va se remonter en lecture seule. D'après mes tests, cependant, même avec <code>-o errors=remount-ro</code>, le système de fichiers s'est corrompu avec moult messages de drbd0 mais ''sans'' que le système de fichiers ne passe en lecture seule.<br />
<br />
Cas 2:<br />
<br />
disk { on-io-error detach; }<br />
<br />
Dans ce cas le disque continue de fonctionner de manière transparente sur le secondaire, en passant par le réseau (mode "diskless").<br />
<br />
Cas 3:<br />
<br />
disk { on-io-error call-local-io-error; }<br />
<br />
Dans ce cas DRBD appelle un script spécifié via <code>local-io-error</code>.<br />
<br />
== Montage au démarrage ==<br />
<br />
* Dans <code>/etc/fstab</code> faire attention:<br />
** de bien faire référence au volume DRBD (pas au volume physique)<br />
** de ne pas demander un fsck (mettre les deux derniers champs à <code>0</code>) car drbd n'est pas activé au moment où fstab est utilisé, ce qui va causerait une erreur<br />
* Dans l'ordre de démarrage, positionner les services dépendant de DRBD (ex: vserver) après lui<br />
* Rajouter un script au démarrage pour finir de monter les volumes DRBD, par exemple:<br />
<pre><br />
cat <<EOF > /etc/init.d/drbdmount<br />
#!/bin/bash<br />
if [ "$1" = "start" ]; then mount -a; fi<br />
EOF<br />
chmod 755 /etc/init.d/drbdmount<br />
update-rc.d drbdmount defaults 19<br />
</pre><br />
<br />
== Supervision ==<br />
<br />
La supervision semble n'être prévue que par le biais de Heartbeat/Pacemaker. Quelques événements peuvent être notifiés par l'intermédiaires des ''handlers'', mais pas tous.<br />
<br />
La commande <code>drbdsetup /dev/drbd0 events</code> permet de récupérer de manière succinte tous les événements qui se produisent.<br />
On peut l'utiliser de manière très rudimentaire dans le script suivant qui tournera en tâche de fond:<br />
<br />
<pre><br />
#!/bin/bash<br />
for drbdX in /dev/drbd*; do<br />
(drbdsetup $drbdX events | while read line; do echo $line | mail -s "$(hostname) $drbdX" you@domain.tld; done)&<br />
sleep 1<br />
done<br />
</pre><br />
<br />
Faire un <code>killall drbdsetup</code> pour l'arrêter.<br />
<br />
== Liens ==<br />
<br />
* [http://www.drbd.org/users-guide/ The DRBD User's Guide]<br />
* [[LVM]]</div>82.238.35.175https://doc.cliss21.com/index.php?title=Compatibilit%C3%A9_binaire&diff=1643Compatibilité binaire2010-05-02T09:14:49Z<p>82.238.35.175 : /* Et comment MS Woe évite-t-il ce problème? */</p>
<hr />
<div>Le problème: je ne peux pas prendre un paquet ''testing'' et l'installer sur ''stable'', dans le cas où si la seule dépendance est la libc.<br />
<br />
== Reproduction du problème ==<br />
<br />
Configuration: une Debian PPC (cf. [[Émulation]])<br />
<br />
* libc6 2.3.2.ds1-22sarge3<br />
* libneon24 0.24.7.dfsg-2<br />
<br />
On force l'installation de tla/testing/20060624, ie tla_1.3.3-3_powerpc (Depends: libc6 (>= 2.3.5-1), libneon24 (>= 0.24.7.dfsg), diff (>= 2.8.1), patch (>= 2.5.9), gawk).<br />
dpkg -i --force-all tla_1.3.3-3_powerpc.deb<br />
<br />
$ tla --version<br />
tla-1.3.3-2<br />
[...]<br />
$ tla register-archive http://vcs.patapouf.org/arch/<br />
Registering archive: devel@patapouf.org--patapouf-arch<br />
$ tla get devel@patapouf.org--patapouf-arch/gcourrier--mainline--1.0<br />
tla: relocation error: tla: symbol _setjmp, version GLIBC_2.3.4 not defined in file libc.so.6 with link time reference<br />
<br />
== Questions ==<br />
<br />
=== Comment se fait-il qu'un différence the 4 millièmes de version (2.3.2->2.3.6) puisse occasionner un plantage? ===<br />
<br />
La libc6 powerpc de etch (2.3.6-13) contient un symbole ''GLIBC_2.3.4 setjmp'':<br />
<br />
$ objdump -T /lib/libc.so.6 | grep setjmp<br />
00032f88 g DF .text 00000008 GLIBC_2.3.4 setjmp<br />
00032f90 g DF .text 00000008 (GLIBC_2.0) _setjmp<br />
00032e3c g DF .text 000000a8 (GLIBC_2.0) __sigsetjmp<br />
00032c20 g DF .text 0000021c GLIBC_2.3.4 __sigsetjmp<br />
00032fa0 g DF .text 00000008 GLIBC_2.3.4 _setjmp<br />
00032f80 g DF .text 00000008 (GLIBC_2.0) setjmp<br />
<br />
Mais avec sarge (2.3.2.ds1-22sarge3):<br />
00032780 g DF .text 00000008 GLIBC_2.0 setjmp<br />
00032668 g DF .text 000000a8 GLIBC_2.0 __sigsetjmp<br />
00032788 g DF .text 00000008 GLIBC_2.0 _setjmp<br />
<br />
Donc en compilant sous etch, on utilise le symbole estampillé "2.3.4" - qui n'est malheureusement pas dans la version de sarge.<br />
<br />
C'est expliqué en détail [http://autopackage.org/docs/devguide/ch07.html#id2529304 ici].<br />
<br />
La solution préconisée par autopackage est de recompiler avec une vielle libc - donc avec compatibilité arrière.<br />
<br />
=== Et comment MS Woe évite-t-il ce problème? ===<br />
<br />
J'aimerais bien le savoir...<br />
<br />
Probablement en gelant sa libc et msvcrt.dll.<br />
<br />
Il faut garder à l'esprit que Woe est conçu pour faire tourner de ''vieux'' exécutables dont on a probablement perdu le code source - la compatibilité binaire a donc été prise beaucoup plus au sérieux qu'avec GNU/Linux.<br />
<br />
Ah tiens ben non: [http://bytes.com/topic/python/answers/454315-python-2-4-2-using-msvcrt71-dll-win-compatibility-issues Python 2.4.2 using msvcrt71.dll on Win and compatibility issues] - deux versions de msvcrt ne sont pas compatibles, et si deux bibliothèques de votre projet ont été compilées avec deux versions différentes, vous vous prenez une erreur de segmentation.<br />
<br />
Microsoft [http://support.microsoft.com/kb/326922 recommande] de distribuer une copie distincte de msvcrt avec chaque application, et de l'installer dans le répertoire de l'application plutôt qu'au niveau système. Cette approche ne résoud pas le problème ci-dessus et est inefficace au niveau suivi de sécurité (les bibliothèques peuvent être facilement mises à jour au niveau système, mais pas au niveau application).<br />
<br />
[http://msdn.microsoft.com/en-us/library/abx4dbyh%28VS.71%29.aspx Cette page] indique qu'il est possible d'utilise le switch <code>/MD</code> qui apparemment sélectionne une version précise de la bibliothèque CRT - sans cependant corriger tous les conflicts.<br />
<br />
Bref le problème reste entier.<br />
<br />
=== Pourquoi sur PowerPC? ===<br />
<br />
Sur un AMD32/etch:<br />
$ objdump -T /lib/libc.so.6 | grep setjmp<br />
00029210 g DF .text 00000038 GLIBC_2.0 setjmp<br />
00029170 g DF .text 0000002f GLIBC_2.0 __sigsetjmp<br />
00029250 g DF .text 00000022 GLIBC_2.0 _setjmp<br />
<br />
Il s'agit de la même version, donc pas de problème.<br />
<br />
== Autre problème à élucider ==<br />
<br />
* http://lists.dccalliance.org/pipermail/dcc-devel/2005-October/000280.html: backport OpenOffice2 pour DCC.<br />
<br />
<br />
== Liens ==<br />
<br />
* [http://autopackage.org/docs/devguide/ch07.html Binary portability], from the Autopackage Packagers Guide<br />
* [http://www.trilithium.com/johan/2005/06/static-libstdc/ Linking ilbstdc++ statically]: libstdc++ and cascading loading issues explained<br />
* http://www.kernel.org/pub/software/libs/glibc/hjl/compat/<br />
* [http://people.redhat.com/drepper/symbol-versioning ELF symbol versioning with glibc 2.1 and later]: symbol-level versioning implementation details<br />
* [http://www.gnu.org/software/libc/FAQ.html#s-1.17 What is symbol versioning good for? Do I need it?], from the glibc FAQ<br />
* [http://people.redhat.com/drepper/no_static_linking.html Static Linking Considered Harmful]: static linking is not an option either<br />
* [http://plan99.net/~mike/writing-shared-libraries.html Writing shared libraries]: conseils pour l'écriture de bibliothèques de fonctions respectant la compatibilité arrière</div>82.238.35.175https://doc.cliss21.com/index.php?title=Compatibilit%C3%A9_binaire&diff=1642Compatibilité binaire2010-05-02T09:09:40Z<p>82.238.35.175 : /* Et comment MS Woe évite-t-il ce problème? */</p>
<hr />
<div>Le problème: je ne peux pas prendre un paquet ''testing'' et l'installer sur ''stable'', dans le cas où si la seule dépendance est la libc.<br />
<br />
== Reproduction du problème ==<br />
<br />
Configuration: une Debian PPC (cf. [[Émulation]])<br />
<br />
* libc6 2.3.2.ds1-22sarge3<br />
* libneon24 0.24.7.dfsg-2<br />
<br />
On force l'installation de tla/testing/20060624, ie tla_1.3.3-3_powerpc (Depends: libc6 (>= 2.3.5-1), libneon24 (>= 0.24.7.dfsg), diff (>= 2.8.1), patch (>= 2.5.9), gawk).<br />
dpkg -i --force-all tla_1.3.3-3_powerpc.deb<br />
<br />
$ tla --version<br />
tla-1.3.3-2<br />
[...]<br />
$ tla register-archive http://vcs.patapouf.org/arch/<br />
Registering archive: devel@patapouf.org--patapouf-arch<br />
$ tla get devel@patapouf.org--patapouf-arch/gcourrier--mainline--1.0<br />
tla: relocation error: tla: symbol _setjmp, version GLIBC_2.3.4 not defined in file libc.so.6 with link time reference<br />
<br />
== Questions ==<br />
<br />
=== Comment se fait-il qu'un différence the 4 millièmes de version (2.3.2->2.3.6) puisse occasionner un plantage? ===<br />
<br />
La libc6 powerpc de etch (2.3.6-13) contient un symbole ''GLIBC_2.3.4 setjmp'':<br />
<br />
$ objdump -T /lib/libc.so.6 | grep setjmp<br />
00032f88 g DF .text 00000008 GLIBC_2.3.4 setjmp<br />
00032f90 g DF .text 00000008 (GLIBC_2.0) _setjmp<br />
00032e3c g DF .text 000000a8 (GLIBC_2.0) __sigsetjmp<br />
00032c20 g DF .text 0000021c GLIBC_2.3.4 __sigsetjmp<br />
00032fa0 g DF .text 00000008 GLIBC_2.3.4 _setjmp<br />
00032f80 g DF .text 00000008 (GLIBC_2.0) setjmp<br />
<br />
Mais avec sarge (2.3.2.ds1-22sarge3):<br />
00032780 g DF .text 00000008 GLIBC_2.0 setjmp<br />
00032668 g DF .text 000000a8 GLIBC_2.0 __sigsetjmp<br />
00032788 g DF .text 00000008 GLIBC_2.0 _setjmp<br />
<br />
Donc en compilant sous etch, on utilise le symbole estampillé "2.3.4" - qui n'est malheureusement pas dans la version de sarge.<br />
<br />
C'est expliqué en détail [http://autopackage.org/docs/devguide/ch07.html#id2529304 ici].<br />
<br />
La solution préconisée par autopackage est de recompiler avec une vielle libc - donc avec compatibilité arrière.<br />
<br />
=== Et comment MS Woe évite-t-il ce problème? ===<br />
<br />
J'aimerais bien le savoir...<br />
<br />
Probablement en gelant sa libc et msvcrt.dll.<br />
<br />
Il faut garder à l'esprit que Woe est conçu pour faire tourner de ''vieux'' exécutables dont on a probablement perdu le code source - la compatibilité binaire a donc été prise beaucoup plus au sérieux qu'avec GNU/Linux.<br />
<br />
Ah tiens ben non: [http://bytes.com/topic/python/answers/454315-python-2-4-2-using-msvcrt71-dll-win-compatibility-issues Python 2.4.2 using msvcrt71.dll on Win and compatibility issues] - deux versions de msvcrt ne sont pas compatibles, et si deux bibliothèques de votre projet ont été compilées avec deux versions différentes, vous vous prenez une erreur de segmentation.<br />
<br />
Microsoft [http://support.microsoft.com/kb/326922 recommande] de distribuer une copie distincte de msvcrt avec chaque application, et de l'installer dans le répertoire de l'application plutôt qu'au niveau système. Cette approche ne résoud pas le problème ci-dessus et est inefficace au niveau suivi de sécurité (les bibliothèques peuvent être facilement mises à jour au niveau système, mais pas au niveau application).<br />
<br />
Bref le problème reste entier.<br />
<br />
=== Pourquoi sur PowerPC? ===<br />
<br />
Sur un AMD32/etch:<br />
$ objdump -T /lib/libc.so.6 | grep setjmp<br />
00029210 g DF .text 00000038 GLIBC_2.0 setjmp<br />
00029170 g DF .text 0000002f GLIBC_2.0 __sigsetjmp<br />
00029250 g DF .text 00000022 GLIBC_2.0 _setjmp<br />
<br />
Il s'agit de la même version, donc pas de problème.<br />
<br />
== Autre problème à élucider ==<br />
<br />
* http://lists.dccalliance.org/pipermail/dcc-devel/2005-October/000280.html: backport OpenOffice2 pour DCC.<br />
<br />
<br />
== Liens ==<br />
<br />
* [http://autopackage.org/docs/devguide/ch07.html Binary portability], from the Autopackage Packagers Guide<br />
* [http://www.trilithium.com/johan/2005/06/static-libstdc/ Linking ilbstdc++ statically]: libstdc++ and cascading loading issues explained<br />
* http://www.kernel.org/pub/software/libs/glibc/hjl/compat/<br />
* [http://people.redhat.com/drepper/symbol-versioning ELF symbol versioning with glibc 2.1 and later]: symbol-level versioning implementation details<br />
* [http://www.gnu.org/software/libc/FAQ.html#s-1.17 What is symbol versioning good for? Do I need it?], from the glibc FAQ<br />
* [http://people.redhat.com/drepper/no_static_linking.html Static Linking Considered Harmful]: static linking is not an option either<br />
* [http://plan99.net/~mike/writing-shared-libraries.html Writing shared libraries]: conseils pour l'écriture de bibliothèques de fonctions respectant la compatibilité arrière</div>82.238.35.175https://doc.cliss21.com/index.php?title=Compatibilit%C3%A9_binaire&diff=1641Compatibilité binaire2010-05-02T09:05:50Z<p>82.238.35.175 : /* Et comment MS Woe évite-t-il ce problème? */</p>
<hr />
<div>Le problème: je ne peux pas prendre un paquet ''testing'' et l'installer sur ''stable'', dans le cas où si la seule dépendance est la libc.<br />
<br />
== Reproduction du problème ==<br />
<br />
Configuration: une Debian PPC (cf. [[Émulation]])<br />
<br />
* libc6 2.3.2.ds1-22sarge3<br />
* libneon24 0.24.7.dfsg-2<br />
<br />
On force l'installation de tla/testing/20060624, ie tla_1.3.3-3_powerpc (Depends: libc6 (>= 2.3.5-1), libneon24 (>= 0.24.7.dfsg), diff (>= 2.8.1), patch (>= 2.5.9), gawk).<br />
dpkg -i --force-all tla_1.3.3-3_powerpc.deb<br />
<br />
$ tla --version<br />
tla-1.3.3-2<br />
[...]<br />
$ tla register-archive http://vcs.patapouf.org/arch/<br />
Registering archive: devel@patapouf.org--patapouf-arch<br />
$ tla get devel@patapouf.org--patapouf-arch/gcourrier--mainline--1.0<br />
tla: relocation error: tla: symbol _setjmp, version GLIBC_2.3.4 not defined in file libc.so.6 with link time reference<br />
<br />
== Questions ==<br />
<br />
=== Comment se fait-il qu'un différence the 4 millièmes de version (2.3.2->2.3.6) puisse occasionner un plantage? ===<br />
<br />
La libc6 powerpc de etch (2.3.6-13) contient un symbole ''GLIBC_2.3.4 setjmp'':<br />
<br />
$ objdump -T /lib/libc.so.6 | grep setjmp<br />
00032f88 g DF .text 00000008 GLIBC_2.3.4 setjmp<br />
00032f90 g DF .text 00000008 (GLIBC_2.0) _setjmp<br />
00032e3c g DF .text 000000a8 (GLIBC_2.0) __sigsetjmp<br />
00032c20 g DF .text 0000021c GLIBC_2.3.4 __sigsetjmp<br />
00032fa0 g DF .text 00000008 GLIBC_2.3.4 _setjmp<br />
00032f80 g DF .text 00000008 (GLIBC_2.0) setjmp<br />
<br />
Mais avec sarge (2.3.2.ds1-22sarge3):<br />
00032780 g DF .text 00000008 GLIBC_2.0 setjmp<br />
00032668 g DF .text 000000a8 GLIBC_2.0 __sigsetjmp<br />
00032788 g DF .text 00000008 GLIBC_2.0 _setjmp<br />
<br />
Donc en compilant sous etch, on utilise le symbole estampillé "2.3.4" - qui n'est malheureusement pas dans la version de sarge.<br />
<br />
C'est expliqué en détail [http://autopackage.org/docs/devguide/ch07.html#id2529304 ici].<br />
<br />
La solution préconisée par autopackage est de recompiler avec une vielle libc - donc avec compatibilité arrière.<br />
<br />
=== Et comment MS Woe évite-t-il ce problème? ===<br />
<br />
J'aimerais bien le savoir...<br />
<br />
Probablement en gelant sa libc et msvcrt.dll.<br />
<br />
Il faut garder à l'esprit que Woe est conçu pour faire tourner de ''vieux'' exécutables dont on a probablement perdu le code source - la compatibilité binaire a donc été prise beaucoup plus au sérieux qu'avec GNU/Linux.<br />
<br />
Ah tiens ben non: [http://bytes.com/topic/python/answers/454315-python-2-4-2-using-msvcrt71-dll-win-compatibility-issues Python 2.4.2 using msvcrt71.dll on Win and compatibility issues] - deux versions de msvcrt ne sont pas compatibles, et si deux bibliothèques de votre projet ont été compilées avec deux versions différentes, vous vous prenez une erreur de segmentation.<br />
<br />
Bref le problème reste entier.<br />
<br />
=== Pourquoi sur PowerPC? ===<br />
<br />
Sur un AMD32/etch:<br />
$ objdump -T /lib/libc.so.6 | grep setjmp<br />
00029210 g DF .text 00000038 GLIBC_2.0 setjmp<br />
00029170 g DF .text 0000002f GLIBC_2.0 __sigsetjmp<br />
00029250 g DF .text 00000022 GLIBC_2.0 _setjmp<br />
<br />
Il s'agit de la même version, donc pas de problème.<br />
<br />
== Autre problème à élucider ==<br />
<br />
* http://lists.dccalliance.org/pipermail/dcc-devel/2005-October/000280.html: backport OpenOffice2 pour DCC.<br />
<br />
<br />
== Liens ==<br />
<br />
* [http://autopackage.org/docs/devguide/ch07.html Binary portability], from the Autopackage Packagers Guide<br />
* [http://www.trilithium.com/johan/2005/06/static-libstdc/ Linking ilbstdc++ statically]: libstdc++ and cascading loading issues explained<br />
* http://www.kernel.org/pub/software/libs/glibc/hjl/compat/<br />
* [http://people.redhat.com/drepper/symbol-versioning ELF symbol versioning with glibc 2.1 and later]: symbol-level versioning implementation details<br />
* [http://www.gnu.org/software/libc/FAQ.html#s-1.17 What is symbol versioning good for? Do I need it?], from the glibc FAQ<br />
* [http://people.redhat.com/drepper/no_static_linking.html Static Linking Considered Harmful]: static linking is not an option either<br />
* [http://plan99.net/~mike/writing-shared-libraries.html Writing shared libraries]: conseils pour l'écriture de bibliothèques de fonctions respectant la compatibilité arrière</div>82.238.35.175https://doc.cliss21.com/index.php?title=Contributions_au_libre&diff=2045Contributions au libre2010-05-02T06:31:14Z<p>82.238.35.175 : /* Django */</p>
<hr />
<div>== Contributions ==<br />
<br />
Voir la liste sur Libre-entreprise.org: [http://www.libre-entreprise.org/wiki/Contributions_au_libre#Cliss_XXI Liste sur LE]<br />
<br />
== Contacts ==<br />
<br />
avec les équipes de développement (pour référence):<br />
<br />
=== SPIP ===<br />
<br />
[[SPIP]]<br />
<br />
* [http://trac.rezo.net/trac/spip/ticket/186]: demande d'installation automatisée - incompris<br />
* [http://trac.rezo.net/trac/spip/ticket/227]: demande de squelettes moins redondants - dispo dans la 1.9<br />
* [http://trac.rezo.net/trac/spip/ticket/655]: patch problème cache v1.9.1 + PHP CGI (suPHP); patch non intégré, mais problème caduque dans la version d'après (1.9.2).<br />
* [http://trac.rezo.net/trac/spip-zone/changeset/15763]: patch encodage des accents dans SPIP-Listes 1.9.2<br />
* [http://trac.rezo.net/trac/spip/ticket/1743]: bug de corruption du contexte<br />
<br />
=== osCommerce ===<br />
<br />
[[OsCommerce]]<br />
<br />
* [http://www.oscommerce-fr.info/forum/index.php?showtopic=30500]: Demande de précision sur une faille de sécurité. Envoi d'une version corrigée ignoré. Forum censuré après coup...<br />
<br />
=== Galette ===<br />
<br />
* [https://mail.gna.org/public/galette-discussion/2007-01/msg00024.html]: données de démo<br />
<br />
=== GaseLL ===<br />
<br />
* [http://www.linux-nantes.fr.eu.org/pipermail/atelier-dev/2007-January/002905.html]: données de démo (il n'y en a pas)<br />
<br />
=== PMB ===<br />
<br />
* [http://lists.pmbservices.fr/pipermail/pmb-devel/2007-June/000074.html] Résolution du bug de la recherche z3950 et PHP5<br />
<br />
=== Debian ===<br />
<br />
* [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447766 Kernel panic when rebooting a xen DomU]<br />
<br />
=== PostfixAdmin ===<br />
<br />
* [http://sourceforge.net/tracker/?func=detail&atid=937966&aid=1995119&group_id=191583 Édition des messages d'absence]<br />
* [http://sourceforge.net/tracker/?func=detail&atid=937966&aid=1996052&group_id=191583 Bug dans le changement de mot de passe]<br />
* [http://sourceforge.net/tracker/?func=detail&atid=937966&aid=1996054&group_id=191583 Typo doc]<br />
<br />
=== Dolibarr ===<br />
<br />
* [http://savannah.nongnu.org/bugs/index.php?27469 Des documents ne peuvent plus être téléchargés: urldecode superflu]<br />
* [http://savannah.nongnu.org/bugs/index.php?27607]<br />
<br />
=== EGroupware ===<br />
<br />
(nécessite de se connecter au préalable)<br />
<br />
* [http://www.egroupware.org/egroupware/index.php?menuaction=tracker.tracker_ui.edit&tr_id=2291 Write session before redirect, to avoid session glitches]<br />
<br />
=== Django ===<br />
<br />
* [http://code.djangoproject.com/ticket/11712 First use of reverse() freezes its cache]<br />
* [http://code.djangoproject.com/ticket/12892 UnicodeEncodeError in contrib.admindocs with non-EN locale]<br />
* [http://code.djangoproject.com/ticket/12914 Use yaml faster C implementation when available]<br />
* [http://code.djangoproject.com/ticket/13019 create_update: proxy object displayed instead of model verbose name]<br />
* [http://code.djangoproject.com/ticket/13415 Incorrect SQL boolean expression for multiple aggregate filters] ([http://code.djangoproject.com/ticket/11293 dup])</div>82.238.35.175https://doc.cliss21.com/index.php?title=OpenSSH&diff=3564OpenSSH2010-02-24T08:40:27Z<p>82.238.35.175 : Accès intermédiaires via SSH</p>
<hr />
<div>== Se connecter sur une machine derrière une passerelle ==<br />
<br />
=== Avec des raccourcis ===<br />
<br />
Config client:<br />
<pre><br />
Host monclient-hote1<br />
ProxyCommand ssh root@passerelle.monclient.com $SSH_PROXY_FLAGS nc -w60 hote1 22<br />
Host monclient-hote2<br />
ProxyCommand ssh root@passerelle.monclient.com $SSH_PROXY_FLAGS nc -w60 hote2 22<br />
</pre><br />
<br />
Pour accéder à la machine:<br />
ssh moi@monclient-hote1<br />
<br />
=== En partageant ssh-agent ===<br />
<br />
Autre solution moins sécurisée:<br />
ssh moi@monclient-hote1 -A<br />
ssh moi@hote1<br />
<br />
Moins sécurisée, parce que -A partage le gestionnaire de clefs (ssh-agent) avec hôte distant, et son administrateur peut alors accéder à votre clef. À ne faire que sur des machines que vous administrez seul.<br />
<br />
=== Pour accéder via un navigateur ===<br />
<br />
On peut mettre en place un proxy SOCKS:<br />
ssh moi@monclient-hote1 -D9000<br />
<br />
Configurer ensuite votre navigateur, dans ses propriétés réseau, pour utiliser un proxy SOCKS sur localhost:9000.<br />
Attention: les DNS ne sont pas impactés par ce proxy.<br />
<br />
Vous pouvez ensuite accéder aux services internes de monclient à partir de votre navigateur de manière transparente.</div>82.238.35.175https://doc.cliss21.com/index.php?title=Serveur_GNU/Linux&diff=594Serveur GNU/Linux2010-02-24T08:34:25Z<p>82.238.35.175 : /* Outils */</p>
<hr />
<div>== Outils ==<br />
<br />
* [[Émulation]]: pour tester vos serveurs avant de passer "en prod".<br />
* [[grsecurity]]<br />
* [[DynDNS]]<br />
* [[X sans souris]]<br />
* http://mire.ipadsl.net/speedtest.php: test de bande passante<br />
* [[Supervision]]<br />
* [[Pure-FTPd]]<br />
* [[Webmin]]<br />
* [[OpenSSH]]<br />
<br />
== Conception de sites Internet ==<br />
<br />
* [[Outils Collaboratifs]]<br />
* [[Transfert de nom de domaine]]<br />
* [[HTTP Benchmark]]<br />
* [[CM-CIC]]: kit de paiment en ligne<br />
<br />
== Debian ==<br />
<br />
* [[Installation Automatisée]]<br />
* [[Sous-système Debian]]<br />
* [[Virtualisation]]<br />
* [[Miroir Debian]]<br />
* [[Equivs]]: passer outre les dépendances Debian<br />
* http://www.sfritsch.de/debian/list-bts-security: lister les failles de sécurité en cours de correction pour les paquets stable installés. Debian peut mettre plusieurs semaines à mettre à jour une faille de sécurité, il peut être nécessaire de faire les choses soi-même pour les paquets sensibles.<br />
* [[Backports]]<br />
* [[Mise à jour Debian Etch]]: passer de Sarge à Etch<br />
* Mises à jour de sécurité automatiques: le problème est essentiellement de ne rien afficher histoire de ne pas recevoir 36 mails de cron quotidiennement, et de vérifier la signature des paquets avant de les installer<br />
** [http://clemens.endorphin.org/secpack/ secpack]: cron + apt-check-security-sigs<br />
** [http://packages.debian.org/stable/admin/apticron apticron]: envoi un mail quand un paquet n'est pas à jour (avec [http://packages.debian.org/stable/utils/apt-listchanges apt-listchanges]); pré-télécharge les nouveaux paquets<br />
** [http://packages.debian.org/stable/admin/cron-apt apt-cron]: plutôt fait pour ''update'' que ''upgrade''<br />
*** [http://www.debianadmin.com/automatic-update-of-packages-using-cron-apt.html article]<br />
*** [http://www.mattiaswikstrom.net/linux/20050526-apt-update-script.html cron-apt-update]: pour envoyer une simulation de la mise à jour par e-mail<br />
** [http://packages.debian.org/stable/admin/tiger tiger]: chercher les paquets vulnérables via les DSA<br />
** voir aussi [http://www.debian.org/doc/manuals/securing-debian-howto/ch10.en.html Securing Debian Manual - Before the compromise]<br />
** voir aussi sur debmaintenance<br />
<br />
Le projet [http://savannah.nongnu.org/projects/debmaintenance debmaintenance] sur Savannah héberge des scripts de Cliss XXI à visée d'automatisation.<br />
<br />
== Autres distributions ==<br />
<br />
* [[Gentoo]]<br />
* [[Mandriva]]<br />
<br />
== Concepts ==<br />
<br />
* [[Passerelle Internet]]: partage de connexion<br />
** [[Pare-feu]]<br />
** [[VPN]]: présentation de différents outils<br />
** [[NetBoot]]<br />
** [[MTU]]<br />
** [[DNAT]]<br />
** [[QoS]]: contrôle et modelage de traffic<br />
* [[Redirection de port TCP]]<br />
* [[Bind]]: Domain Name Server<br />
* [[Sauvegarde]]<br />
* [[Samba]]<br />
** [[Samba et accès concurrents]]<br />
* [[OpenLDAP]]<br />
* [[Hébergement Mutualisé]]: comparaison (vhffs, alternc...)<br />
* [[Dupliquer un site]]<br />
* [[Hiérarchie Unix]]<br />
* [[Vérification de matériel]]<br />
* Le hostname: pour avoir <code>hostname -f</code> qui fonctionne, utiliser un <code>/etc/hosts/</code> de la forme:<br />
127.0.0.1 hote.domain.tld hote localhost<br />
* [[Disque crypté]]: protégez une partition par mot de passe<br />
* [[Serveur Dédié]]: check-list à l'installation<br />
* [[AMD64]]: différences et compatibilité avec un processeur 32bit<br />
<br />
== Résolution de problèmes ==<br />
<br />
* [[Serveur web]]: codage par défaut<br />
* [[Format d'impression]]: taille et format de papier<br />
* [[LVM]]: activation manuelle<br />
<br />
== Courriel ==<br />
<br />
* [[Serveur de courriel]]<br />
* Lutte contre le [[SPAM]]<br />
* [[Mailman]]</div>82.238.35.175https://doc.cliss21.com/index.php?title=HP_DeskJet_722C&diff=3560HP DeskJet 722C2010-02-15T07:30:43Z<p>82.238.35.175 : </p>
<hr />
<div>== Liens ==<br />
<br />
* [http://www.openprinting.org/show_printer.cgi?recnum=HP-DeskJet_722C Page OpenPrinting]</div>82.238.35.175https://doc.cliss21.com/index.php?title=HP_DeskJet_722C&diff=3559HP DeskJet 722C2010-02-15T07:30:33Z<p>82.238.35.175 : Nouvelle page : == Liens == * [Page OpenPrinting http://www.openprinting.org/show_printer.cgi?recnum=HP-DeskJet_722C]</p>
<hr />
<div>== Liens ==<br />
<br />
* [Page OpenPrinting http://www.openprinting.org/show_printer.cgi?recnum=HP-DeskJet_722C]</div>82.238.35.175https://doc.cliss21.com/index.php?title=Mat%C3%A9riel&diff=778Matériel2010-02-15T07:30:11Z<p>82.238.35.175 : /* Imprimantes */</p>
<hr />
<div>Matériel informatique utilisé par Cliss XXI, avec de la documentation.<br />
Voir aussi: [[Vérification de matériel]]<br />
<br />
== Ordinateurs ==<br />
<br />
* [[Asus Eee PC 2G Surf]]<br />
* [[EasyNote SL65-U-020FR]]<br />
* [[Lenovo 3000 N200]]<br />
* [[Acer Aspire 7535G]]<br />
* [[Acer Aspire 4810T]]<br />
* [[PowerEdge1950]]<br />
* [[PowerEdge2950]]<br />
* [[FujitsuSiemensAmiloM7440G]]<br />
* [[OpenBrick]]<br />
* [[Mitac8050]]<br />
* [[Acer TravelMate 4100]]<br />
* [[Fujitsu Siemens Amilo M1424]]<br />
<br />
* [[Installer une Debian Sarge PPC]] (càd sur portable Apple iBook G4)<br />
* [http://thesticksplace.chez-alice.fr/ Description de l'installation d'un portable sous Debian]: les principes génériques sont intéressants (notamment la mise en veille prolongée)<br />
* [http://ubuntuforums.org/showpost.php?p=2138671&postcount=7]: utilisation des outils 855resolution et 915resolution pour paramétrer plus finement la resolution des cartes Intel (à tester)<br />
<br />
Achat d'ordinateurs:<br />
* [http://bons-vendeurs-ordinateurs.info/ Liste des bons et mauvais vendeurs d'ordinateur personnel et matériel informatique]: comparatif revendeurs pour achat sans OS, disponibilité de pilotes libres, etc.<br />
<br />
== Modem/Routeurs ==<br />
<br />
* [[Bewan LanBooster 2204]]<br />
* [[Bewan LanBooster 6104W]]<br />
* [[Olitec SX200]]<br />
* [[Linksys WRT54G]]<br />
<br />
== Cartes WiFi ==<br />
<br />
Pilotes libres (état des lieux fin 2008):<br />
* Chipset ath9k de Atheros:<br />
** [http://www.fsf.org/news/ath9k News sur FSF]<br />
** [http://wireless.kernel.org/en/users/Drivers/ath9k Page officielle] (avec noms de produits qui utilisent ce chipset)<br />
* [http://rt2x00.serialmonkey.com/ RT2X00]: pilotes pour chipset Ralink. Les nouveaux pilotes (rt2x00) fonctionnent bien avec un noyau 2.6.26 (inclus noyau officiel depuis janvier 2008). Les pilotes précédents (''Legacy''), à compiler avec <code>module-assistant</code>, fonctionnent sous Debian Etch avec <code>/etc/network/interfaces</code> mais pas avec network-manager (réseaux disponibles affichés mais requêtes DHCP sans suite). Les derniers chipset gérés (> rt26) s'appuient sur du firmware et les développeurs n'ont [http://www.linux.com/feature/132701 aucune intention] de le remplacer :/<br />
** Cartes testées (chipset ralink):<br />
*** [[Hercules Wireless G PCMCIA]]: carte PCMCIA (pour portables) - OK, portée faible<br />
*** [[Asus WL 107G]]: carte PCMCIA (pour ordinateur portable) - OK<br />
*** [[OvisLink Evo-W54USB]]: dongle USB - OK, déconnexion en cas d'inactivité prolongée; faire un <code>ifconfig rausb0 up</code> avant de l'utiliser; des difficultés à se mettre en route, en particulier avec les nouveaux pilotes<br />
* [http://madwifi.org/wiki/About/ath5k ath5k] - devrait remplacer MadWifi à terme<br />
<br />
Vieux pilotes:<br />
* [http://lekernel.net/prism54/freemac.html FreeMAC]: ce n'est pas un pilote, mais un firmware sous GNU GPL (les versions propriétaires sont nommées FullMAC et SoftMAC). Ce firmware libre est malheureusement abandonné à présent. Pour référence, le pilote pour le noyau Linux est "islsm" (pour FreeBSD, "p54u"). Les pilotes peuvent fonctionner avec différents firmwares. Un autre pilote intitulé p54 (issue de la branche wireless-dev) est inclus dans les versions 2.6.22 et plus du noyau Linux, et supplante islsm - mais nécessite toujours le firmware propriétaire.<br />
* Le pilote [http://sourceforge.net/projects/zd1211/ zd1211] ?<br />
* Vieux pilotes (2005) pour [http://rtl8180-sa2400.sourceforge.net/ cartes RealTek]<br />
* Un vieux pilote "prism" (pas prims54, prism tout court) fonctionnait bien sans firmware propriétaire, mais en vitesse 11Mb/s. Par conséquent il n'est plus possible de trouver des cartes neuve intégrant ce chipset depuis plusieurs années.<br />
<br />
En voie de guérison (dépend du code propriétaire):<br />
* MadWifi:<br />
** le composant binaire s'appelle HAL et une version libre (mais différente) a été [http://madwifi.org/wiki/news/20080929/hal-source-code-released publiée] en 09-2008 - cependant il n'est pas dit que madwifi va l'utiliser.<br />
** indépendamment des problèmes de firmware, il faut parfois recompiler des versions patchées<br />
** une version libre nommée ath5k devrait le remplacer<br />
<br />
Liens:<br />
* [http://www.fsf.org/resources/hw/net/wireless/cards.html FSF - Cards]: cartes WiFi utilisables avec des logiciels libres; utilisent:<br />
** Asus WL-107G PCMCIA card (testée à Cliss XXI)<br />
** Linksys WUSB54G USB 2.0 802.11g/b 54Mbps (11 Mbps with b)<br />
* [http://www.april.org/fr/nouveau-portable-pour-lassistante-de-lapril Nouveau portable pour l'assistante de l'April] - et sa carte WiFi libre ExpressCard DLink DWA-643 (Chipset Atheros, 802.11n)<br />
* [http://ralink.rapla.net/ Ralink RT2500 chipsets based wireless devices]: liste de cartes utilisant RT2500<br />
* [http://permalink.gmane.org/gmane.org.user-group.linux.france.nantes/4131 L'état de l'art]: attention, il semble que l'auteur ne parle que du support GNU/Linux, et donc inclus les pilotes qui nécessitent du firmware propriétaire.<br />
* [http://forum.wireless-fr.org/viewtopic.php?pid=22 Dongle Wifi fonctionnant sous Linux avec un pilote libre]<br />
<br />
À creuser:<br />
* [http://www.ldlc.com/fiche/PB00043529.html MSI US54SE - Clef USB Wi-Fi G (54 Mbps)]: dite fonctionner avec Ubuntu version Feisty - à tester avec une distribution plus libre.<br />
* [http://www.prism54.org/misc.html Photos de matériel] tournant avec prism54, dont une Netgear WG111 version 2 - est-ce que ça fonctionne bien?<br />
* On nous a dit du bien de: Carte wifi PCMCIA: Gigamedia - Conectis / Chipset: Marvel Libertas / W54CIAV2 (à tester)<br />
* [http://www.freebsd.org/releases/6.2R/hardware-i386.html#WLAN Drivers libres dans FreeBSD] et les cartes qu'ils font fonctionner<br />
* [[Sécurité WiFi]]<br />
<br />
== Cartes 3D ==<br />
<br />
Pilotes libres - état des lieux:<br />
* Intel: OK (DRI/3D) mais intégrées uniquement (non disponible sans la carte mère).<br />
* VIA/S3: OK (DRI/3D) mais intégrées uniquement (id.), et produits d'entrée de gamme: performances limitées et possibilités limitées (pas de Compiz)<br />
* ATI Radeon: OK (DRI/3D) pour les cartes datant de 3-4 ans; les cartes récentes n'ont en général qu'un support 2D, voire pas de support du tout<br />
** http://dri.freedesktop.org/wiki/ATIRadeon - correspondances cartes <-> chipsets<br />
** http://wiki.x.org/wiki/RadeonFeature - fonctionnalités par chipset<br />
** http://wiki.x.org/wiki/RadeonProgram - tests sur quelques applications 3D connues<br />
** En 10/2008, les modèles à considérer sont plutôt dans l'intervalle 9250 (type R200) -> X850 (type R400)<br />
* nVidia: support 2D très lent (pilote 'nv'), autre pilote 2D pour l'instant expérimental (pilote nouveau - xserver-xorg-video-nouveau), support 3D en chantier. Bref quasiment aucun support libre.<br />
<br />
Donc à l'achat:<br />
* Portable: du Intel, ou de l'ATI (si d'occasion)<br />
* Fixe: du S3 (quitte à rajouter une carte non-intégrée ATI) ou de l'ATI (d'occasion) ou du Intel (plus rare sur les U.C.?)<br />
* Éviter dans tous les cas le dernier cri pour laisser le temps à X.org et aux distributions d'intégrer les derniers modèles<br />
<br />
Modèles testés avec support 3D:<br />
* Intel Mobile 915GM (achat 2005)<br />
* Intel Mobile 855GM (achat ~2003/2004) - pilote xserver-xorg-video-i810 (Debian Etch)<br />
* Intel GMA X3100 (achat 2008): pas bien géré sous Debian Etch, à retester avec Etch'n Half ou Lenny<br />
* ATI Radeon 9600 - pilote xserver-xorg-video-radeon - radeon_dri.so / rv350 (Debian Etch et Lenny) - des soucis de textures non permanents dans slune, quelques problèmes avec Compiz selon les versions, sinon bon support 3D<br />
* ATI Radeon 9700SE (détectée 9600, portable) - pilote xserver-xorg-video-ati (Debian Etch - à confirmer)<br />
* ATI Radeon Mobility M6 LY (portable Dell Latitude C510, achat 2002/2003?) - pilote xorg-x11-video-ati / radeon_dri.so / rv100 (Debian Etch); vieille carte, donc limitations (certains jeux ne fonctionnent pas); des [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504535 soucis] sous Lenny<br />
* ATI Radeon RV100 QY [Radeon 7000/VE] - pilote xserver-xorg-video-ati / radeon_dri.so / rv100 (Debian Etch) - ne pas trop pousser la carte sinon scintillement (préférer 1024x768 16bit)<br />
* S3 UniChrome (carte mère VIA KM400) - pilote xserver-xorg-video-via (Debian Lenny)<br />
* S3 ProSavage8 (carte mère VIA KM266 Pro) - pilote xorg-x11-drv-savage (Fedora 9)<br />
2D uniquement:<br />
* ATI Radeon HD 3430 - xserver-xorg-video-radeon - R620? (2/2009)<br />
Tests:<br />
* pour voir si le mode DRI (3D) est géré: <code>glxinfo | grep render</code><br />
* pour tester sans l'accélération 3D, le plus simple est de lancer un deuxième X: <code>startx /usr/bin/xterm -- :2</code><br />
<br />
Liens:<br />
* http://free3d.org/ - un pseudo-benchmark sur différents modèles de cartes 3D<br />
* http://www.kroah.com/log/linux/stable_api_nonsense.html : solution technique plutôt que légale pour contrer les pilotes propriétaires pour le noyau Linux<br />
* http://www.kroah.com/log/2005/11/21/ : voir la discussion associée sur la liste<br />
* http://lwn.net/Articles/162686/ : scenario apocalyptique<br />
* http://www.atnf.csiro.au/people/rgooch/linux/docs/licensing.txt : le point de vue de Linux Torvalds sur la question des modules propriétaires - il occulte le fait que combiner GPL+propriétaire n'est pas légal, même si le module propriétaire n'est pas dérivé du produit GPL.<br />
* [http://kororaa.org/comments.php?y=06&m=06&entry=entry060614-184527 FSF Chimes In - Part 2]: le point de vue du GPL Compliance Lab: ces modules sont tout à fait illégaux.<br />
<br />
== Cartes réseau récalcitrantes ==<br />
<br />
* [[ATL2]]: pas encore inclus dans le noyau; utilisé dans l'Eee-pc<br />
<br />
== [[Onduleurs]] ==<br />
<br />
* [[APC BackUPS CS500]]<br />
* [[APC_BackUPS_RS500]]<br />
* [[Pulsar Evolution 1100]]<br />
* [[MGE Pulsar Ellipse Premium 500]]<br />
<br />
== Imprimantes ==<br />
<br />
* [[hp color LaserJet 2550L]] - Couleur<br />
* [[Brother HL-1670N]] - N&B<br />
* [[Brother MFC-465-CN]] - Couleur<br />
* [[Epson Stylus C64]] - Couleur<br />
* [[Epson Stylus DX6050]] - Couleur - Imprimante + scanner<br />
* [[Epson Stylus Color 880]] - Couleur<br />
* [[HP DeskJet 722C]] - Couleur<br />
* [[HP DeskJet 895C]] - Couleur<br />
* [[HP DeskJet 1220C]] - Couleur<br />
* [[HP DeskJet D2460]] - Couleur<br />
* [[HP LaserJet 4100n]] - N&B<br />
* [[HP LaserJet 4200n]] - N&B<br />
* [[HP Color LaserJet CM1015 MFP]] - Imprimante OK - Scanner KO<br />
* [[HP Officejet Pro K550]] - Couleur<br />
* [[HP Photosmart 2575]] - Couleur - Imprimante + scanner<br />
* [[Ricoh Aficio SP C410DN]] - Couleur<br />
* [[Ricoh Aficio 1060]] - N&B<br />
* [[TOSHIBA e-STUDIO16/20/25 PCL 6]] - Photocopieur KO + imprimante OK<br />
* [[Canon IR2200]] - Attendre<br />
* [[Konica Minolta Magicolor 2300DL]] - Couleur<br />
* [[Lexmark E320]] - N&B<br />
* [[Lexmark X544]] - Couleur<br />
<br />
== WebCam ==<br />
<br />
* [[Installation logicielle de la caméra|Philips ToUcam 2 PCVC 820K]]<br />
* [[Labtec Webcam]]<br />
* Mose m'a recommandé la Logitech pro 4000 (046d/08b2) + pwc (60€)<br />
<br />
== Liaison Série ==<br />
<br />
* [[Moxa]] : connection RJ45 / DB9<br />
* [[Sunix Multiport]] : connection série RJ45 (avant MoXa)<br />
<br />
== Lecteurs de code barre ==<br />
<br />
* [[Opticon 6125]]<br />
<br />
== Lecteurs DAT ==<br />
<br />
* [[Quantum DAT-72]]</div>82.238.35.175https://doc.cliss21.com/index.php?title=PHP&diff=1962PHP2007-04-28T22:30:12Z<p>82.238.35.175 : /* Accélérateurs PHP */</p>
<hr />
<div>Dernières versions de la documentation officielle de PHP, avant qu'elle ne devienne non-libre:<br />
* [http://packages.debian.org/stable/doc/php3-doc Documentation for PHP3]<br />
* [http://packages.debian.org/oldstable/doc/phpdoc Documentation for PHP4 and PHP3] (snapshot 2002)<br />
<br />
== Dernière version libre de la documentation PHP ==<br />
<br />
Précisons que l'Open Publication License (OPL) est une licence libre uniquement si aucune option n'est utilisée (notamment, l'interdiction des travaux dérivés sans consentement des détenteurs des droits).<br />
<br />
La dernière version date de 2003.<br />
<br />
Avec <code>cvs2cl --utc</code>, j'obtiens le ChangeLog suivant:<br />
2003-05-02 14:12 goba<br />
<br />
* en/bookinfo.xml: And now: upgrading to the new license<br />
<br />
La dernière version libre est donc:<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository login # pass: phpfi<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository checkout -D "2003-05-02 14:12:58Z" phpdocs<br />
<br />
----<br />
<br />
[[Débogage PHP]]<br />
<br />
----<br />
<br />
== PEAR ==<br />
<br />
Problèmes de license:<br />
* [http://thread.gmane.org/gmane.comp.php.pear.devel/40682/focus=40682 Début]<br />
* [http://news.gmane.org/find-root.php?group=gmane.comp.php.pear.devel&article=40787 Conclusion?]<br />
* [http://pear.php.net/bugs/bug.php?id=9630 Bug] à inverser au niveau de la documentation<br />
* [http://pear.php.net/manual/en/faq.devs.php Page de doc] à corriger<br />
<br />
== Tests unitaires avec PHP ==<br />
<br />
* [http://www.simpletest.org/ SimpleTest]<br />
* [http://phpunit.de/ PHPUnit]<br />
* phpt ([http://weierophinney.net/matthew/archives/65-phpt-Tutorial.html tutorial], [http://qa.php.net/write-test.php guide qa.php.net]), apparemment plus simple/rapide. Lancer avec <code>pear run-tests *.phpt</code>.<br />
<br />
Voir également WWW::Mechanize (''Mech'') pour tester le programme de manière externe par son interface web (en Perl). Pour une solution en PHP, voir éventuellement la bibliothèque curl, qui ne sait cependant pas analyser le HTML reçu.<br />
<br />
== Génération de formulaires ==<br />
<br />
* [http://pear.php.net/package/HTML_QuickForm HTML_QuickForm]: one class that contains all form elements and associated info (validation), which can analyse input and render the form in HTML [http://paul-m-jones.com/blog/?p=117 Critic] [http://pear.php.net/package/HTML_QuickForm2 HTML_QuickForm2] [http://quickform.mamasam.com/wiki/ QuickForm2 development Wiki]<br />
* [http://trac.php-tools.net/patForms patForms]<br />
* [http://solarphp.com/ Solar_Form] (à coupler avec un moteur de template pour l'affichage?)<br />
<br />
== Abstraction de la base de données ==<br />
<br />
* [http://pear.php.net/package/MDB2 MDB2]: successeur de PEAR::DB, licence mBSD<br />
* [http://creole.phpdb.org/ Creole]: PHP5 seulement; licence LGPL<br />
* [http://adodb.sourceforge.net/ AdoDB]: utilisé par TikiWiki, Xaraya, eGroupWare; license mBSD<br />
<br />
== Simplification de l'accès à la base ==<br />
<br />
Dépend d'une des abstraction ci-dessus. Mots-clefs à chercher: ORM ([http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping])<br />
* [http://pear.php.net/package/DB_Table DB_Table]: non-object, intégration avec QuickForm et validation des update/insert, description via une classe et des tableaux ($cols, $idx, $sql...); utilise PEAR::DB (licence PHP); LGPL<br />
* [http://propel.phpdb.org/ Propel]: description en XML (lourd?), relations inter-classes, relations N-M possibles mais pas encore propres; possibilité d'utiliser directement SQL si besoin; validation décrite en XML (lourd); utilise Creole<br />
* [http://www.appelsiini.net/~tuupola/php/DB_DataContainer/ DB_DataContainer]: mapping objet simpliste, pas de relation inter-tables; description via la classe PHP; nécessite un champ 'id'.<br />
* [http://pear.php.net/package/DB_DataObject DB_DataObject]: fichier de description .ini; liens entre classes; à essayer; licence PHP<br />
* [http://www.ezpdo.net EZPDO]: description inclue dans des tags @orm style javadoc; validation via des 'Events'/hooks, aucune validation par défaut ''a priori''; mBSD<br />
* [http://cakephp.org/ CakePHP]: framework style Ruby on Rails, inclut un ORM; la [http://manual.cakephp.org/chapter/validation validation], à base de regexp, fait partie du framework et en est vraisemblablement indissociable.<br />
* [http://www.phpdoctrine.com/ Doctrine]: ça a l'air très propre (bonne gestion du model relationel?); description par une classe; discussions en cours pour intégration dans PEAR<br />
* [http://www.meta-language.net/metastorage.html MetaL Metastrorage]: beaucoup de XML<br />
* [http://phplens.com/lens/adodb/docs-active-record.htm ADOdb Active Record]: un ORM qui fait partie d'ADOdb, à voir; réimplémentation de Zend Active Records; c'est apparement le seul outil à utiliser la base de données comme description du modèle - ce qui me semble en fait très pertinent.<br />
* d'autres listés sur [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#PHP Wikipedia].<br />
<br />
== Accélérateurs PHP ==<br />
<br />
* [http://eaccelerator.net/ eAccelerator]: successeur de Turck mmCache, fournit aussi encodeur, optimiseur, système de cache pour développeur?...<br />
* [http://trac.lighttpd.net/xcache/ XCache]: cache, couverture (optionnel), orienté stabilité, interface web de stats<br />
* [http://pecl.php.net/package/APC APC]: cache uniquement (optimiseur obsolète?), plus proche de PHP (participation de Rasmus)<br />
<br />
Comparatifs:<br />
* http://www.ipersec.com/index.php?q=fr/node/2/print (eAccelerator)<br />
* http://www.j2eegeek.com/blog/2007/02/27/php-acceleration-pick-your-poison/ (APC)</div>82.238.35.175https://doc.cliss21.com/index.php?title=UserModeLinux&diff=1895UserModeLinux2007-04-02T18:05:16Z<p>82.238.35.175 : /* Liens */</p>
<hr />
<div>UML ou User-mode Linux est un moyen de lancer un deuxième noyau Linux, utilisable sans être root.<br />
C'est en fait un portage du noyau Linux, non pas pour une architecture matérielle, mais pour lui-même. Un portage de Linux pour Linux!<br />
Cela a des points communs avec l'[[Émulation]].<br />
<br />
UML est intégré dans le noyau officiel (kernel.org) depuis un bon moment.<br />
<br />
== Compilation du noyau utilisateur ==<br />
<br />
C'est très simple: on compile le noyau Linux avec le paramètre <code>ARCH=um</code> ''pour chaque commande''.<br />
<br />
wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.13.tar.bz2<br />
tar xjf linux-2.6.17.13.tar.bz2<br />
cd linux-2.6.17.13<br />
<br />
make defconfig ARCH=um<br />
make xconfig ARCH=um # facultatif; pensez à activer HOSTFS si besoin<br />
make ARCH=um<br />
strip linux<br />
make modules_install ARCH=um INSTALL_MOD_PATH=uml-modules/<br />
<br />
Cf. [http://user-mode-linux.sourceforge.net/new/source.html Building from source] chez UML.<br />
<br />
Des options que j'active:<br />
* MAGIC_SYSRQ: active l'équivalent de Alt+ImprÉcr, utilisable depuis uml_mconsole<br />
* HOST_2G_2G: contourne un problème de certains noyaux hôte (cf. plus bas)<br />
* HOSTFS: possibilité de monter des répertoires de la machine hôte - attention à la sécurité)<br />
* STATIC_LINK: compiler le noyau en statique (pas de dépendance sur des bibliothèques partagées .so)<br />
<br />
Il y a également des patches à essayer [http://www.user-mode-linux.org/~blaisorblade/patches/]:<br />
* hôte/host:<br />
** skas3 - meilleures performances (dossier skas3-2.6)<br />
* invité/guest:<br />
** exec support: permet de lancer des commandes shell avec uml_mconsole (ex: [http://www.user-mode-linux.org/~blaisorblade/patches/guest/uml-2.6.18.1-bb2/broken-out/uml-mconsole-exec.diff]) - Jeff Dike recommande cependant de passer par login ou SSH, ce patch a peu de chance d'être inclus officiellement, voir le bouquin au chapitre 8 (p.181).<br />
<br />
== Construction du système de base ==<br />
<br />
On se propose de construire et de lancer un système UML sans aucun accès root.<br />
<br />
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.<br />
<br />
=== Tentative 1 ===<br />
<br />
Essayons de créer un système complet, sans faire d'image, et en possédant tous les fichiers:<br />
<br />
La dernière version de debootstrap propose une variante ''fakechroot'' qui permet de l'utiliser sans accès root:<br />
export PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH # pour trouver la commande 'chroot'<br />
fakechroot /usr/sbin/debootstrap --variant=fakechroot sarge sarge-uml/ http://localhost/mirrors/debian<br />
/usr/src/linux-2.6.17.13/linux root=/dev/root rootflags=/home/sylvain/tests/uml/debian/sarge-uml/ rootfstype=hostfs<br />
<br />
Résultat: cela ne fonctionne pas, à mon avis parce que dans ce cas précis sarge-uml/dev est un lien symbolique vers /dev.<br />
<br />
=== Tentative 2 ===<br />
<br />
Essayons à partir d'une image UML déjà opérationnelle. Le principe est de monter le système de fichier hôte avec ''hostfs'', puis de faire un <code>mount -o loop</code> depuis le UML sur l'image disque à bootstrap-per. Cela permet de monter l'image sans avoir de privilèges super-utilisateur.<br />
<br />
mount none host/ -t hostfs -o /home/sylvain/tests/uml/debian<br />
cd host/<br />
mkdir loop/<br />
mount image -o loop loop/<br />
ls loop/ # -> bin boot dev etc ...<br />
<br />
D'après le ''Rob's quick and dirty UML howto'', nul besoin d'une image disque pour jouer avec UML. Ni donc pour monter une image:<br />
$ ./linux rootfstype=hostfs rw init=/bin/sh quiet<br />
# insmod /usr/src/linux-2.6.20-um/drivers/block/loop.ko<br />
# mount image -o loop loop/<br />
# ls loop/ # -> bin boot dev etc ...<br />
Excellent!!!<br />
Cela ressemble vaguement à un <code>chcontext</code> de VServer.<br />
<br />
Notez l'option <code>rootfstype</code> [http://user-mode-linux.sourceforge.net/hostfs.html] [http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-9.html#ss9.3]. <code>init</code> pointe sur le chemin complet d'un exécutable (binaire ou même script). <br />
[http://packages.debian.org/unstable/utils/rootstrap rootstrap] et [http://packages.debian.org/unstable/devel/pbuilder-uml pbuilder-uml] fonctionnent sur ce principe.<br />
<br />
=== En mode root ===<br />
<br />
Faute de mieux, utilisons sudo:<br />
<br />
mkdir loop/<br />
# image de 1Go, à trous (espace disque progressif)<br />
dd if=/dev/null of=image count=0 bs=1G seek=1<br />
# on formatte en ext3<br />
/sbin/mkfs.ext3 -F image<br />
<br />
sudo mount image loop/ -o loop<br />
sudo debootstrap sarge loop/ http://192.168.1.60/mirrors/debian<br />
<br />
# configuration de la console:<br />
sudo grep -v tty loop/etc/inittab > inittab.work<br />
sudo echo "1:2345:respawn:/sbin/getty 38400 console linux" >> inittab.work<br />
sudo mv inittab.work loop/etc/inittab<br />
<br />
# configuration réseau:<br />
cat <<'EOF' > interfaces.work<br />
auto lo<br />
iface lo inet loopback<br />
EOF<br />
sudo mv interfaces.work loop/etc/network/interfaces<br />
<br />
# fake mtab and fstab<br />
cat <<'EOF' > fstab.work<br />
proc /proc proc defaults 0 0<br />
/dev/ubda / auto defaults,errors=remount-ro 0 1<br />
EOF<br />
sudo mv fstab.work loop/etc/fstab <br />
<br />
sudo umount loop/<br />
<br />
=== Optimiser la taille de l'image pour la distribuer ===<br />
<br />
Une image UML contient souvent des zones vides, où il n'y a pas encore de fichiers. <br />
<br />
L'image ci-dessus réserve 1Go mais n'en occupe que 230Mo grâce à la création d'image "à trous" (''sparse'' en anglais).<br />
<br />
$ ls -lh image<br />
-rw-r--r-- 1 sylvain sylvain 1,0G 2006-09-18 15:55 image<br />
$ du -sh image<br />
234M image<br />
<br />
D'autres méthodes (dd sur /dev/zero par exemple) n'en tiennent pas compte.<br />
<br />
<code>df -h</code> dans UML indique une utilisation de 178Mo, donc on doit pouvoir encore améliorer (comment?). Éviter <code>e2defrag</code>, qui est obsolète et corrompt les systèmes de fichier. Piste: copier les fichiers dans une nouvelle image et supprimer l'ancienne - défragmentation à la volée; inconvénient: les secteurs d'amorçages dont perdus (si vous les utilisez avec qemu, sinon aucune importance).<br />
<br />
<br />
Pour optimiser une image "pleine":<br />
cp --sparse=always image image.sparse<br />
<br />
Pour envoyer une image par le réseau en respectant les trous:<br />
tar cSf image.tar image # S pour "sparse"<br />
<br />
== Réseau ==<br />
<br />
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.<br />
<br />
=== Mode root avec tuntap ===<br />
<br />
host# sudo /usr/src/linux ubda=sarge-debootstrap eth0=tuntap,,,192.168.1.101<br />
<br />
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.<br />
<br />
Puis dans UML:<br />
<br />
uml# ifconfig eth0 192.168.1.201<br />
<br />
=== Mode semi-root avec tuntap ===<br />
<br />
Pour utiliser tuntap, il faut créer à l'avance (et en mode root) une interface tap0 et lui assigner une adresse IP. <br />
<br />
# tunctl -u sylvain<br />
Set 'tap0' persistent and owned by uid 1000<br />
<br />
Puis il faut donner des droits aux utilisateurs non-privilégiés d'utiliser tuntap (en mode root aussi):<br />
<br />
chmod 666 /dev/net/tun<br />
<br />
ou bien ajouter l'utilisateur au groupe "uml-net" (uniquement sous Debian?)<br />
<br />
$ sudo adduser sylvain uml-net<br />
Adding user `sylvain' to group `uml-net' ...<br />
Done.<br />
<br />
C'est une solution efficace mais qui nécessite plusieurs étapes de préconfiguration en mode root.<br />
<br />
Pour accéder au réseau ''et'' en être accessible, configuration manuelle (cf. uml_net pour l'automatisation):<br />
# Côté invité:<br />
ifconfig eth0 192.168.1.200<br />
# Même config routeur que l'hôte:<br />
route add default 192.168.1.1 eth0<br />
# Même config DNS que l'hôte:<br />
echo "nameserver 192.168.1.1" > /etc/resolv.conf<br />
<br />
# Côté hôte:<br />
/sbin/ifconfig tap0 192.168.1.150 netmask 255.255.255.255<br />
# Autoriser le routage des paquets<br />
echo 1 > /proc/sys/net/ipv4/ip_forward<br />
# Exception: cette adresse ne passe pas par eth0:<br />
route add -host 192.168.1.200 dev tap0<br />
<br />
# Pour être visible du réseau, il faut annoncer cette IP sur la carte physique:<br />
echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp<br />
arp -Ds 192.168.1.200 eth0 pub<br />
<br />
# Au moment de partir, on enlève l'annonce ARP:<br />
arp -d 192.168.1.200 dev eth0<br />
<br />
Cela ne fonctionne que si l'on utilise le même réseau que l'hôte. Dans le cas contraire (ex: 172.20.0.0/16), il faudrait ajouter des routes sur toutes les machines du réseau physique pour savoir comment accéder à ce réseau différent (ou alors utiliser l'hôte comme routeur et (D)NATer le traffic).<br />
<br />
Autre solution similaire: avec un pont (bridge).<br />
brctl addbr br0<br />
ifconfig eth0 0.0.0.0 promisc<br />
brctl addif br0 eth0<br />
dhclient br0<br />
<br />
tunctl -u sylvain<br />
brctl addif br0 tap0<br />
# invité: ifconfig eth0 192.168.1.200<br />
<br />
Le pont se chargera d'écouter les paquets sur le réseau à destination de l'adresse du tap0 côté invité, et de les lui envoyer (pas besoin de <code>ip_forward</code>, ni de <code>arp</code>, ni d'une route spéciale pour contacter l'invité, ni d'une IP côté hôte pour tap0). Un inconvénient: la reconfiguration du réseau de la machine hôte. Le super-avantage étant de pouvoir configurer l'invité via le DHCP du réseau physique!<br />
<br />
=== Mode semi-root avec tuntap (2) ===<br />
<br />
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.<br />
<br />
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=tuntap,,,10.10.10.10<br />
uml# ifconfig eth0 10.10.10.11<br />
uml# route add default gw 10.10.10.10<br />
<br />
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...).<br />
<br />
=== Mode utilisateur avec slirp ===<br />
<br />
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'):<br />
<br />
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=slirp,,/usr/bin/slirp-fullbolt<br />
<br />
Dans UML, quelques étapes spécifiques à slirp sont nécessaires:<br />
<br />
# Configurer l'interface sur 10.2.0.15 (IP de choix pour slirp d'après la doc?)<br />
ifconfig eth0 10.2.0.15<br />
# Utiliser la redirection DNS 10.0.2.3<br />
echo "nameserver 10.0.2.3" > /etc/resolv.conf<br />
# Ajouter une route par défaut vers eth0:<br />
route add default dev eth0<br />
<br />
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).<br />
<br />
Note 2: dans QEMU, l'IP assignée est 10.0.2.15. Le DNS est également 10.0.2.3. La configuration se fait automatiquement via un serveur DHCP intégré.<br />
<br />
* Cf. [http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-6.html#ss6.11 Slirp] dans le UML HOWTO.<br />
<br />
=== /etc/network/interfaces ===<br />
<br />
Voici comment configurer automatiquement le réseau au démarrage d'UML, dans son fichier <code>interfaces</code>:<br />
<br />
auto lo<br />
iface lo inet loopback<br />
<br />
auto eth0<br />
iface eth0 inet static<br />
<br />
# eth0=tuntap,,,10.10.10.1<br />
# address 10.10.10.10<br />
# netmask 255.0.0.0<br />
# gateway 10.10.10.1<br />
<br />
# eth0=slirp,,/usr/bin/slirp-fullbolt<br />
address 10.2.0.15<br />
netmask 255.0.0.0<br />
dns-nameservers 10.0.2.3<br />
up route add default eth0<br />
<br />
(dns-nameservers nécessite le paquet ''resolvconf'')<br />
<br />
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.<br />
<br />
== Lancer un UML en tâche fond ==<br />
<br />
./linux ubda=... con=null &<br />
<br />
<br />
== Versions ==<br />
<br />
La version officielle est vraisemblablement celle intégrée au noyau kernel.org.<br />
<br />
Aucune version de développement n'est vraisemblablement accessible.<br />
<br />
La version kernel.org ne compile pas nécessairement ([http://www.gossamer-threads.com/lists/linux/kernel/706384 ex.]).<br />
<br />
Jeff Dyke publie de temps à autre un combo précompilé noyau + image FC5 sur la page d'accueil du site.<br />
<br />
=== Patches ===<br />
<br />
Cf. http://www.user-mode-linux.org/~blaisorblade/<br />
<br />
Clarifions un peu:<br />
* skas3+sysemu: patch pour le noyau hôte pour gagner en rapidité,<br />
* -bb: patch pour le noyau invité, fonctionnalités supplémentaires en test. À utiliser en bloc, ou en choissant une fonctionnalité en particulier parmi un jeu de patches séparés (''splitout''/''broken-out''). Il y a un jeu de patches correspondants pour les uml-utilities.<br />
<br />
C'est un peu confus sur le site, mais c'est tout.<br />
<br />
TODO: il y a aussi les patches pour uml-utilities mais je ne sais pas à quoi ils servent [http://www.user-mode-linux.org/~blaisorblade/uml-utilities/].<br />
<br />
=== Pre-release ===<br />
<br />
http://user-mode-linux.sourceforge.net/patches.html présente les changements non encore publiés, prévus pour inclusion dans la prochaine version du noyau kernel.org. Il y est clairement fait mention que la version de développement n'est pas directement publique (git), si ce n'est ces patches.<br />
<br />
== Liens ==<br />
<br />
* [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<br />
* [http://uml.jfdi.org/uml/Wiki.jsp Wiki UML]: disparate<br />
* [http://uml.openconsultancy.com/ UML-based pseudo-dedicated hosting service]: UML de l'hébergement mutualisé<br />
* [http://www.gentoo.org/doc/en/uml.xml Gentoo Linux Developer's guide to system testing with User-Mode Linux] avec un trick pour tester l'ISO d'install de Gentoo.<br />
* [http://www.landley.net/code/UML.html Rob's quick and dirty UML howto.]: quelques tricks intéressants, comme charger un UML dans la racine courante<br />
* [http://eggdrop.ch/texts/uml/ Running Debian inside of Debian with User-Mode Linux]<br />
* [http://www.metz.supelec.fr/metz/personnel/galtier/PagesPerso/TutorielUML/index.html Tutoriel User Mode Linux]: avec introduction à SKAS et réseau<br />
* [http://www-static.cc.gatech.edu/~gtg861b/ User-Mode Linux Installation Tutorial]: un tutorial complet chez Georgia Tech<br />
* [http://www.ime.usp.br/~baroni/docs/uml-en.html Configuring User Mode Linux]: encore un autre tutorial avec toutefois une section sur le débogage noyau à l'aide d'UML<br />
* [http://www.phptr.com/bookstore/product.asp?isbn=0131865056&rl=1 Livre] [http://www.eyrolles.com/Informatique/Livre/9780131865051/livre-user-mode-linux.php officiel]: écrit par l'auteur, ce livre est sous licence 'Open Publication' et n'en utilise visiblement aucune des options non-libres. C'est donc un livre libre que l'on peut recommander d'acheter :) La page de présentation indique que les livres de la série "Bruce Perens' Open Source" sont tous sous cette licence et sont publiés au format électronique au bout de 6 mois (il y a retard ici, et l'auteur, contacté via IRC, n'était vraisemblablement pas au courant du caractère libre de la publication - à suivre. Le contenu reste libre quoi qu'il en soit.). J'ai personnellement récupéré un exemplaire au format .chm mais je ne connais pas son origine - je l'ai acheté au format papier aussi. Le livre couvre le réseau, les applications, semble une bonne référence. Il risque cependant de devenir obsolète rapidement. J'ai demandé à l'auteur s'il comptait mettre le livre en ligne par la suite, pour une mise à jour continue: il n'y a pas encore réfléchi.<br />
* [http://testape.com/webtty_sample.php WebTTY]: lancez une instance UML sur le serveur distant et tapez du Bash intéractivement dans un navigateur web :)<br />
* [http://www.ioware.ca/wiki/doku.php/user_mode_linux:testing user_mode_linux:testing]: génération d'image automatisée<br />
* [http://linuxfr.org/2006/08/20/21216.html ShaKe, un défragmenteur pour GNU/Linux] + liens<br />
* [[Émulation]] sur doc.cliss21.com<br />
* Réseau virtuel<br />
** [http://jungla.dit.upm.es/~vnuml/ VNUML]: Virtual Network User Mode Linux, simulation de réseaux complexes<br />
** [http://puzzle.dl.sourceforge.net/sourceforge/vnuml/vnuml-livecd-1.0.iso VIMINAL]: Live-CD alternatif pour VNUML ([http://sourceforge.net/project/showfiles.php?group_id=113582&package_id=203946 download])<br />
** [http://www.strongswan.org/uml/index.htm strongSwan - UML testing]: tests de non-regression de strongSwan avec un réseau virtuel d'UML.<br />
** [http://www.freeswan.org/freeswan_snaps/CURRENT-SNAP/doc/umltesting.html FreeS/WAN User-Mode-Linux Testing guide]: même chose chez FreeS/WAN (projet abandonné), donc plus ancien (noyau 2.4...). Qu'est-ce que uml_netjig??<br />
** [http://www.samag.com/documents/s=8997/sam0401a/0401a.htm Emulating Networks Using User-Mode Linux]: mise en place de IPSec sur une configuration (A<->Routeur)<->Hôte<->(Routeur<->B).<br />
* UML-Utilities: pour changer, le lien est [http://user-mode-linux.sourceforge.net/new/minis.html#utils perdu] au milieu du site. Lien direct: http://user-mode-linux.sourceforge.net/new/uml_utilities_20060622.tar.bz2<br />
<br />
== Dépannage ==<br />
<br />
Kernel panic - not syncing: start_userspace : expected SIGSTOP, got status = 256<br />
<br />
Cf. http://www.mail-archive.com/user-mode-linux-devel@lists.sourceforge.net/msg03414.html<br />
<br />
Votre noyau (hôte) est, si j'ai bien compris, mal configuré. Recompilez-le ou utilisez-en un autre.<br />
<br />
Vous pouvez également activer CONFIG_HOST_2G_2G dans la configuration du noyau UM.</div>82.238.35.175https://doc.cliss21.com/index.php?title=VPN&diff=1786VPN2007-03-10T14:32:12Z<p>82.238.35.175 : </p>
<hr />
<div>== Outils de référence ==<br />
<br />
=== IPSec ===<br />
<br />
* [http://ipsec-howto.org/ IPSec]: utilise de nouveaux protocoles IP (AH/50 et ESP/51). Nécessite un support noyau (natif ou KLIPS(=*swan)) et un démon optionnel pour la gestion de clefs, en principe interopétables.<br />
** [http://www.strongswan.org/ strongSwan]<br />
** [http://www.openswan.org/ Openswan]<br />
** intégré au noyau<br />
** racoon<br />
**... à trier ...<br />
** Utilisé par L2TP/IPSec, inclus dans Woe (2K et + ?)<br />
** Pare-feu: protocoles IP 50/AH et 51/ESP, ports 500/udp (isakmp) et 4500/udp (ipsec-nat-t / NAT traversal); 1701/udp l2tp (?)<br />
<br />
==== L2TP ====<br />
<br />
IPSec est utilisé sous Windows > 2K avec L2TP.<br />
<br />
Une page très (trop) fournie:<br />
http://www.jacco2.dds.nl/networking/openswan-l2tp.html<br />
<br />
Implémentations:<br />
* [http://www.xelerance.com/software/xl2tpd/ xl2tpd]: reprise de l'abandonné [http://l2tpd.sourceforge.net/ l2tpd], [ftp://ftp.xelerance.com/xl2tpd/ releases] récentes (2007). *l2tpd serait le seul à proposer la gestion d'un pool d'IP, les autres solutions déléguant la chose à RADIUS.<br />
* [http://sourceforge.net/projects/l2tpns l2tpns]: ne fait pas client [http://packages.debian.org/unstable/net/l2tpd deb]<br />
* [http://opensource.katalix.com/openl2tp/ OpenL2TP]: nécessite un pilote noyau<br />
* [http://www.jacco2.dds.nl/networking/openswan-l2tp.html#L2TPoverview Autres]<br />
<br />
=== PPTP ===<br />
<br />
==== Client ====<br />
<br />
* [http://pptpclient.sourceforge.net/documentation.phtml pptpclient]: client GNU/Linux [http://guides.ovh.com/OvpnPptp] [http://pptpclient.sourceforge.net/howto-debian.phtml]<br />
* Inclus dans MS Woe depuis 95OSR2. Failles de sécurité dans la conception ainsi que dans l'implémentation, à réserver en solution de secours.<br />
<br />
Support noyau: cf. [[QEMU#VPN]]<br />
<br />
Configuration:<br />
# Installer pptpclient:<br />
aptitude install pptp-linux<br />
<br />
# /etc/ppp/options.pptp est automatiquement créé, sinon cf [http://pptpclient.sourceforge.net/howto-debian.phtml#configure_by_hand]<br />
<br />
# Description du VPN distant:<br />
cat <<EOF > /etc/ppp/peers/cliss21<br />
file /etc/ppp/options.pptp<br />
# Username (1st field in /etc/ppp/chap-secrets)<br />
name 'sylvain'<br />
# Remote name (2nd field in chap-secrets, not needed if there's "*")<br />
remotename 'cliss21'<br />
# Use a command instead of a real tty<br />
pty "pptp i.cliss21.org --nolaunchpppd"<br />
EOF<br />
<br />
# Fichier de mot de passe:<br />
cat <<EOF > /etc/ppp/chap-secrets<br />
"sylvain" "cliss21" "motdepasse"<br />
EOF<br />
<br />
==== Serveur ====<br />
<br />
* Configuration serveur: [http://poptop.sourceforge.net/dox/]<br />
* Pare-feu: protocole IP 47/GRE, 1723/tcp<br />
** Apparemment le traffic GRE est inclus dans RELATED,ESTABLISHED - sauf pour le réseau local?<br />
** Utiliser <code>-i ppp+</code> pour une règle s'appliquant sur toutes les interfaces <code>ppp0</code>, <code>ppp1</code>, <code>ppp2</code>, etc.<br />
* Support MPPE inclus dans le noyau Linux depuis v2.6.15<br />
<br />
Configuration serveur:<br />
# Installer PoPToP:<br />
aptitude install pptpd<br />
<br />
# Authoriser l'accès vers sylvain@cliss21 pour toute adresse IP<br />
# (recopier le chap-secrets du client et ajouter une '*' à la fin)<br />
# Le nom du serveur peut être différent sur le serveur et le client<br />
# mais doit correspondre à /etc/pptpd.conf:name<br />
cat <<EOF >> /etc/ppp/chap-secrets<br />
sylvain pptp motdepasse *<br />
EOF<br />
<br />
# Configurer le nom du serveur distant<br />
sed -i -e 's/^name .*$/name cliss21/' /etc/ppp/pptp-options<br />
<br />
==== Sécurité ====<br />
<br />
Si vous utilisez un mot de passe qui se trouve dans le dictionnaire de l'attaquant, [http://asleap.sourceforge.net/ asleap] le trouve immédiatement:<br />
# ./genkeys -r /etc/dictionaries-common/words -f dict.dat -n dict.idx<br />
genkeys 1.4 - generates lookup file for asleap. <jwright@hasborg.com><br />
Generating hashes for passwords (this may take some time) ...Done.<br />
98570 hashes written in 0.25 seconds: 393931.74 hashes/second<br />
Starting sort (be patient) ...Done.<br />
Completed sort in 724210 compares.<br />
Creating index file (almost finished) ...Done.<br />
# time ./asleap -i eth0 -f dict.dat -n dict.idx<br />
asleap 1.4 - actively recover LEAP/PPTP passwords. <jwright@hasborg.com><br />
Using the passive attack method.<br />
<br />
Captured PPTP exchange information:<br />
username: sylvain<br />
auth challenge: a0aa0d2e0ca2fde8e36d6a6c69002e9e<br />
peer challenge: 5568ef7b804b35ac77e757aaafa64afa<br />
peer response: 06e1349f2a38048f3702a728e46d9c440b0cd67918d697e1<br />
challenge: 8e5fe08c7dcdbb6e<br />
hash bytes: 89f1<br />
NT hash: 5fd76204806b2fffa86f8fbedf9189f1<br />
password: zwieback<br />
Closing pcap ...<br />
<br />
real 0m3.006s<br />
user 0m0.116s<br />
sys 0m0.004s<br />
<br />
Également vulnérable à une attaque de type [http://en.wikipedia.org/wiki/Rainbow_table rainbow] (force brute efficace pour algorithme de cryptage sans perturbation/''salt''), mais je n'ai pas trouvé d'outil tout prêt.<br />
<br />
=== OpenVPN ===<br />
<br />
* [http://openvpn.net/ OpenVPN]: solution basée sur TLS, ne nécessite aucun support noyau. Non intégré à Woe. Clients et GUI dispos pour GNU/Linux et Woe.<br />
** Pare-feu: 1194/udp (+ peut-être tcp pour le transport over TCP introduit dans la 1.5)<br />
<br />
== TCP over TCP ==<br />
<br />
* [http://docs.mandragor.org/files/Misc/GLFM/lm31/TCP_over_TCP_mauvaise_iD.html TCP over TCP ?]: d'après l'auteur, une mauvaise idée, avec dégradation facile du réseau.<br />
* [http://www.lea-linux.org/cached/index/Tunnels_ethernet_avec_openssh.html Tunnels ethernet avec openssh]: OpenSSH 4 intégre TUN/TAP.<br />
<br />
== À creuser ==<br />
<br />
* [http://vtun.sourceforge.net/ VTun]: Tun/Tap apparemment bien exploité. La documentation du noyau Linux dit qu'il peut faire VPN. Je n'ai rien trouvé dans la doc :/<br />
<br />
== Vieux ==<br />
<br />
* [http://www.freeswan.org/ FreeS/WAN]: abandonné et continué via les forks Openswan et strongSwan.<br />
* [http://packages.debian.org/unstable/net/secvpn secvpn]: construit un VPN à base de SSH et ppp, suivant le [http://tldp.org/HOWTO/VPN-HOWTO/ VPN HOWTO]. TCP over TCP. Vieux.<br />
<br />
== Liens ==<br />
<br />
* [http://www.nimlabs.org/~nim/dirtynat.html Dirty NAT tricks to get a VPN to work with clients also numbered in the private address space]: réadressage dynamique du réseau avec <code>iptables -j NETMAP</code>:<br />
iptables -v -t nat -A PREROUTING -i ppp+ -d 10.22.8.0/24 -j NETMAP --to 192.168.1.0/24<br />
iptables -v -t nat -A POSTROUTING -o ppp+ -s 192.168.1.0/24 -j NETMAP --to 10.22.8.0/24<br />
* [http://www.debian-administration.org/articles/245 Creating a radius based VPN with support for Windows clients]: L2TP + RADIUS + MySQL... et tous les petits soucis infâmes de ce type de montage</div>82.238.35.175https://doc.cliss21.com/index.php?title=VPN&diff=1785VPN2007-03-10T09:12:06Z<p>82.238.35.175 : /* L2TP */</p>
<hr />
<div>== Outils de référence ==<br />
<br />
=== IPSec ===<br />
<br />
* [http://ipsec-howto.org/ IPSec]: utilise de nouveaux protocoles IP (AH/50 et ESP/51). Nécessite un support noyau (natif ou KLIPS(=*swan)) et un démon optionnel pour la gestion de clefs, en principe interopétables.<br />
** [http://www.strongswan.org/ strongSwan]<br />
** [http://www.openswan.org/ Openswan]<br />
** intégré au noyau<br />
** racoon<br />
**... à trier ...<br />
** Utilisé par L2TP/IPSec, inclus dans Woe (2K et + ?)<br />
** Pare-feu: protocoles IP 50/AH et 51/ESP, ports 500/udp (isakmp) et 4500/udp (ipsec-nat-t / NAT traversal); 1701/udp l2tp (?)<br />
<br />
==== L2TP ====<br />
<br />
IPSec est utilisé sous Windows > 2K avec L2TP.<br />
<br />
Implémentations:<br />
* [http://sourceforge.net/projects/l2tpns l2tpns]: incomplet? [http://packages.debian.org/unstable/net/l2tpd deb]<br />
* [http://sourceforge.net/projects/rp-l2tp rp-l2tp]: une implémentation, mais dernière [http://sourceforge.net/project/showfiles.php?group_id=63352 release] 0.4 en 2004<br />
* l2tpd: [http://www.marko.net/l2tp/ passe la main] -> domaine l2tpd.org abandonné -> [http://l2tpd.snapgear.org/ changement d'URL] -> [http://l2tpd.sourceforge.net/ remis en ligne, mais inactif] [http://packages.debian.org/unstable/net/l2tpd deb]<br />
* [http://www.xelerance.com/software/xl2tpd/ xl2tpd]: reprise de l2tpd, [ftp://ftp.xelerance.com/xl2tpd/ releases] récentes (2007)<br />
<br />
=== PPTP ===<br />
<br />
==== Client ====<br />
<br />
* [http://pptpclient.sourceforge.net/documentation.phtml pptpclient]: client GNU/Linux [http://guides.ovh.com/OvpnPptp] [http://pptpclient.sourceforge.net/howto-debian.phtml]<br />
* Inclus dans MS Woe depuis 95OSR2. Failles de sécurité dans la conception ainsi que dans l'implémentation, à réserver en solution de secours.<br />
<br />
Support noyau: cf. [[QEMU#VPN]]<br />
<br />
Configuration:<br />
# Installer pptpclient:<br />
aptitude install pptp-linux<br />
<br />
# /etc/ppp/options.pptp est automatiquement créé, sinon cf [http://pptpclient.sourceforge.net/howto-debian.phtml#configure_by_hand]<br />
<br />
# Description du VPN distant:<br />
cat <<EOF > /etc/ppp/peers/cliss21<br />
file /etc/ppp/options.pptp<br />
# Username (1st field in /etc/ppp/chap-secrets)<br />
name 'sylvain'<br />
# Remote name (2nd field in chap-secrets, not needed if there's "*")<br />
remotename 'cliss21'<br />
# Use a command instead of a real tty<br />
pty "pptp i.cliss21.org --nolaunchpppd"<br />
EOF<br />
<br />
# Fichier de mot de passe:<br />
cat <<EOF > /etc/ppp/chap-secrets<br />
"sylvain" "cliss21" "motdepasse"<br />
EOF<br />
<br />
==== Serveur ====<br />
<br />
* Configuration serveur: [http://poptop.sourceforge.net/dox/]<br />
* Pare-feu: protocole IP 47/GRE, 1723/tcp<br />
** Apparemment le traffic GRE est inclus dans RELATED,ESTABLISHED - sauf pour le réseau local?<br />
** Utiliser <code>-i ppp+</code> pour une règle s'appliquant sur toutes les interfaces <code>ppp0</code>, <code>ppp1</code>, <code>ppp2</code>, etc.<br />
* Support MPPE inclus dans le noyau Linux depuis v2.6.15<br />
<br />
Configuration serveur:<br />
# Installer PoPToP:<br />
aptitude install pptpd<br />
<br />
# Authoriser l'accès vers sylvain@cliss21 pour toute adresse IP<br />
# (recopier le chap-secrets du client et ajouter une '*' à la fin)<br />
# Le nom du serveur peut être différent sur le serveur et le client<br />
# mais doit correspondre à /etc/pptpd.conf:name<br />
cat <<EOF >> /etc/ppp/chap-secrets<br />
sylvain pptp motdepasse *<br />
EOF<br />
<br />
# Configurer le nom du serveur distant<br />
sed -i -e 's/^name .*$/name cliss21/' /etc/ppp/pptp-options<br />
<br />
==== Sécurité ====<br />
<br />
Si vous utilisez un mot de passe qui se trouve dans le dictionnaire de l'attaquant, [http://asleap.sourceforge.net/ asleap] le trouve immédiatement:<br />
# ./genkeys -r /etc/dictionaries-common/words -f dict.dat -n dict.idx<br />
genkeys 1.4 - generates lookup file for asleap. <jwright@hasborg.com><br />
Generating hashes for passwords (this may take some time) ...Done.<br />
98570 hashes written in 0.25 seconds: 393931.74 hashes/second<br />
Starting sort (be patient) ...Done.<br />
Completed sort in 724210 compares.<br />
Creating index file (almost finished) ...Done.<br />
# time ./asleap -i eth0 -f dict.dat -n dict.idx<br />
asleap 1.4 - actively recover LEAP/PPTP passwords. <jwright@hasborg.com><br />
Using the passive attack method.<br />
<br />
Captured PPTP exchange information:<br />
username: sylvain<br />
auth challenge: a0aa0d2e0ca2fde8e36d6a6c69002e9e<br />
peer challenge: 5568ef7b804b35ac77e757aaafa64afa<br />
peer response: 06e1349f2a38048f3702a728e46d9c440b0cd67918d697e1<br />
challenge: 8e5fe08c7dcdbb6e<br />
hash bytes: 89f1<br />
NT hash: 5fd76204806b2fffa86f8fbedf9189f1<br />
password: zwieback<br />
Closing pcap ...<br />
<br />
real 0m3.006s<br />
user 0m0.116s<br />
sys 0m0.004s<br />
<br />
Également vulnérable à une attaque de type [http://en.wikipedia.org/wiki/Rainbow_table rainbow] (force brute efficace pour algorithme de cryptage sans perturbation/''salt''), mais je n'ai pas trouvé d'outil tout prêt.<br />
<br />
=== OpenVPN ===<br />
<br />
* [http://openvpn.net/ OpenVPN]: solution basée sur TLS, ne nécessite aucun support noyau. Non intégré à Woe. Clients et GUI dispos pour GNU/Linux et Woe.<br />
** Pare-feu: 1194/udp (+ peut-être tcp pour le transport over TCP introduit dans la 1.5)<br />
<br />
== TCP over TCP ==<br />
<br />
* [http://docs.mandragor.org/files/Misc/GLFM/lm31/TCP_over_TCP_mauvaise_iD.html TCP over TCP ?]: d'après l'auteur, une mauvaise idée, avec dégradation facile du réseau.<br />
* [http://www.lea-linux.org/cached/index/Tunnels_ethernet_avec_openssh.html Tunnels ethernet avec openssh]: OpenSSH 4 intégre TUN/TAP.<br />
<br />
== À creuser ==<br />
<br />
* [http://vtun.sourceforge.net/ VTun]: Tun/Tap apparemment bien exploité. La documentation du noyau Linux dit qu'il peut faire VPN. Je n'ai rien trouvé dans la doc :/<br />
<br />
== Vieux ==<br />
<br />
* [http://www.freeswan.org/ FreeS/WAN]: abandonné et continué via les forks Openswan et strongSwan.<br />
* [http://packages.debian.org/unstable/net/secvpn secvpn]: construit un VPN à base de SSH et ppp, suivant le [http://tldp.org/HOWTO/VPN-HOWTO/ VPN HOWTO]. TCP over TCP. Vieux.<br />
<br />
== Liens ==<br />
<br />
* [http://www.nimlabs.org/~nim/dirtynat.html Dirty NAT tricks to get a VPN to work with clients also numbered in the private address space]: réadressage dynamique du réseau avec <code>iptables -j NETMAP</code>:<br />
iptables -v -t nat -A PREROUTING -i ppp+ -d 10.22.8.0/24 -j NETMAP --to 192.168.1.0/24<br />
iptables -v -t nat -A POSTROUTING -o ppp+ -s 192.168.1.0/24 -j NETMAP --to 10.22.8.0/24<br />
* [http://www.debian-administration.org/articles/245 Creating a radius based VPN with support for Windows clients]: L2TP + RADIUS + MySQL... et tous les petits soucis infâmes de ce type de montage</div>82.238.35.175https://doc.cliss21.com/index.php?title=VPN&diff=1784VPN2007-03-10T08:09:05Z<p>82.238.35.175 : /* L2TP */</p>
<hr />
<div>== Outils de référence ==<br />
<br />
=== IPSec ===<br />
<br />
* [http://ipsec-howto.org/ IPSec]: utilise de nouveaux protocoles IP (AH/50 et ESP/51). Nécessite un support noyau (natif ou KLIPS(=*swan)) et un démon optionnel pour la gestion de clefs, en principe interopétables.<br />
** [http://www.strongswan.org/ strongSwan]<br />
** [http://www.openswan.org/ Openswan]<br />
** intégré au noyau<br />
** racoon<br />
**... à trier ...<br />
** Utilisé par L2TP/IPSec, inclus dans Woe (2K et + ?)<br />
** Pare-feu: protocoles IP 50/AH et 51/ESP, ports 500/udp (isakmp) et 4500/udp (ipsec-nat-t / NAT traversal); 1701/udp l2tp (?)<br />
<br />
==== L2TP ====<br />
<br />
IPSec est utilisé sous Windows > 2K avec L2TP.<br />
<br />
Implémentations:<br />
* [http://sourceforge.net/projects/l2tpns l2tpns]: incomplet? [http://packages.debian.org/unstable/net/l2tpd deb]<br />
* [http://sourceforge.net/projects/rp-l2tp rp-l2tp]: une implémentation, mais dernière [http://sourceforge.net/project/showfiles.php?group_id=63352 release] 0.4 en 2004<br />
* l2tpd: [http://www.marko.net/l2tp/ passe la main] -> [http://l2tpd.org domaine abandonné] -> [http://l2tpd.snapgear.org/ changement d'URL] -> [http://l2tpd.sourceforge.net/ remis en ligne, mais inactif] [http://packages.debian.org/unstable/net/l2tpd deb]<br />
* [http://www.xelerance.com/software/xl2tpd/ xl2tpd]: reprise de l2tpd, [ftp://ftp.xelerance.com/xl2tpd/ releases] récentes (2007)<br />
<br />
=== PPTP ===<br />
<br />
==== Client ====<br />
<br />
* [http://pptpclient.sourceforge.net/documentation.phtml pptpclient]: client GNU/Linux [http://guides.ovh.com/OvpnPptp] [http://pptpclient.sourceforge.net/howto-debian.phtml]<br />
* Inclus dans MS Woe depuis 95OSR2. Failles de sécurité dans la conception ainsi que dans l'implémentation, à réserver en solution de secours.<br />
<br />
Support noyau: cf. [[QEMU#VPN]]<br />
<br />
Configuration:<br />
# Installer pptpclient:<br />
aptitude install pptp-linux<br />
<br />
# /etc/ppp/options.pptp est automatiquement créé, sinon cf [http://pptpclient.sourceforge.net/howto-debian.phtml#configure_by_hand]<br />
<br />
# Description du VPN distant:<br />
cat <<EOF > /etc/ppp/peers/cliss21<br />
file /etc/ppp/options.pptp<br />
# Username (1st field in /etc/ppp/chap-secrets)<br />
name 'sylvain'<br />
# Remote name (2nd field in chap-secrets, not needed if there's "*")<br />
remotename 'cliss21'<br />
# Use a command instead of a real tty<br />
pty "pptp i.cliss21.org --nolaunchpppd"<br />
EOF<br />
<br />
# Fichier de mot de passe:<br />
cat <<EOF > /etc/ppp/chap-secrets<br />
"sylvain" "cliss21" "motdepasse"<br />
EOF<br />
<br />
==== Serveur ====<br />
<br />
* Configuration serveur: [http://poptop.sourceforge.net/dox/]<br />
* Pare-feu: protocole IP 47/GRE, 1723/tcp<br />
** Apparemment le traffic GRE est inclus dans RELATED,ESTABLISHED - sauf pour le réseau local?<br />
** Utiliser <code>-i ppp+</code> pour une règle s'appliquant sur toutes les interfaces <code>ppp0</code>, <code>ppp1</code>, <code>ppp2</code>, etc.<br />
* Support MPPE inclus dans le noyau Linux depuis v2.6.15<br />
<br />
Configuration serveur:<br />
# Installer PoPToP:<br />
aptitude install pptpd<br />
<br />
# Authoriser l'accès vers sylvain@cliss21 pour toute adresse IP<br />
# (recopier le chap-secrets du client et ajouter une '*' à la fin)<br />
# Le nom du serveur peut être différent sur le serveur et le client<br />
# mais doit correspondre à /etc/pptpd.conf:name<br />
cat <<EOF >> /etc/ppp/chap-secrets<br />
sylvain pptp motdepasse *<br />
EOF<br />
<br />
# Configurer le nom du serveur distant<br />
sed -i -e 's/^name .*$/name cliss21/' /etc/ppp/pptp-options<br />
<br />
==== Sécurité ====<br />
<br />
Si vous utilisez un mot de passe qui se trouve dans le dictionnaire de l'attaquant, [http://asleap.sourceforge.net/ asleap] le trouve immédiatement:<br />
# ./genkeys -r /etc/dictionaries-common/words -f dict.dat -n dict.idx<br />
genkeys 1.4 - generates lookup file for asleap. <jwright@hasborg.com><br />
Generating hashes for passwords (this may take some time) ...Done.<br />
98570 hashes written in 0.25 seconds: 393931.74 hashes/second<br />
Starting sort (be patient) ...Done.<br />
Completed sort in 724210 compares.<br />
Creating index file (almost finished) ...Done.<br />
# time ./asleap -i eth0 -f dict.dat -n dict.idx<br />
asleap 1.4 - actively recover LEAP/PPTP passwords. <jwright@hasborg.com><br />
Using the passive attack method.<br />
<br />
Captured PPTP exchange information:<br />
username: sylvain<br />
auth challenge: a0aa0d2e0ca2fde8e36d6a6c69002e9e<br />
peer challenge: 5568ef7b804b35ac77e757aaafa64afa<br />
peer response: 06e1349f2a38048f3702a728e46d9c440b0cd67918d697e1<br />
challenge: 8e5fe08c7dcdbb6e<br />
hash bytes: 89f1<br />
NT hash: 5fd76204806b2fffa86f8fbedf9189f1<br />
password: zwieback<br />
Closing pcap ...<br />
<br />
real 0m3.006s<br />
user 0m0.116s<br />
sys 0m0.004s<br />
<br />
Également vulnérable à une attaque de type [http://en.wikipedia.org/wiki/Rainbow_table rainbow] (force brute efficace pour algorithme de cryptage sans perturbation/''salt''), mais je n'ai pas trouvé d'outil tout prêt.<br />
<br />
=== OpenVPN ===<br />
<br />
* [http://openvpn.net/ OpenVPN]: solution basée sur TLS, ne nécessite aucun support noyau. Non intégré à Woe. Clients et GUI dispos pour GNU/Linux et Woe.<br />
** Pare-feu: 1194/udp (+ peut-être tcp pour le transport over TCP introduit dans la 1.5)<br />
<br />
== TCP over TCP ==<br />
<br />
* [http://docs.mandragor.org/files/Misc/GLFM/lm31/TCP_over_TCP_mauvaise_iD.html TCP over TCP ?]: d'après l'auteur, une mauvaise idée, avec dégradation facile du réseau.<br />
* [http://www.lea-linux.org/cached/index/Tunnels_ethernet_avec_openssh.html Tunnels ethernet avec openssh]: OpenSSH 4 intégre TUN/TAP.<br />
<br />
== À creuser ==<br />
<br />
* [http://vtun.sourceforge.net/ VTun]: Tun/Tap apparemment bien exploité. La documentation du noyau Linux dit qu'il peut faire VPN. Je n'ai rien trouvé dans la doc :/<br />
<br />
== Vieux ==<br />
<br />
* [http://www.freeswan.org/ FreeS/WAN]: abandonné et continué via les forks Openswan et strongSwan.<br />
* [http://packages.debian.org/unstable/net/secvpn secvpn]: construit un VPN à base de SSH et ppp, suivant le [http://tldp.org/HOWTO/VPN-HOWTO/ VPN HOWTO]. TCP over TCP. Vieux.<br />
<br />
== Liens ==<br />
<br />
* [http://www.nimlabs.org/~nim/dirtynat.html Dirty NAT tricks to get a VPN to work with clients also numbered in the private address space]: réadressage dynamique du réseau avec <code>iptables -j NETMAP</code>:<br />
iptables -v -t nat -A PREROUTING -i ppp+ -d 10.22.8.0/24 -j NETMAP --to 192.168.1.0/24<br />
iptables -v -t nat -A POSTROUTING -o ppp+ -s 192.168.1.0/24 -j NETMAP --to 10.22.8.0/24<br />
* [http://www.debian-administration.org/articles/245 Creating a radius based VPN with support for Windows clients]: L2TP + RADIUS + MySQL... et tous les petits soucis infâmes de ce type de montage</div>82.238.35.175https://doc.cliss21.com/index.php?title=VPN&diff=1783VPN2007-03-10T08:06:46Z<p>82.238.35.175 : /* L2TP */</p>
<hr />
<div>== Outils de référence ==<br />
<br />
=== IPSec ===<br />
<br />
* [http://ipsec-howto.org/ IPSec]: utilise de nouveaux protocoles IP (AH/50 et ESP/51). Nécessite un support noyau (natif ou KLIPS(=*swan)) et un démon optionnel pour la gestion de clefs, en principe interopétables.<br />
** [http://www.strongswan.org/ strongSwan]<br />
** [http://www.openswan.org/ Openswan]<br />
** intégré au noyau<br />
** racoon<br />
**... à trier ...<br />
** Utilisé par L2TP/IPSec, inclus dans Woe (2K et + ?)<br />
** Pare-feu: protocoles IP 50/AH et 51/ESP, ports 500/udp (isakmp) et 4500/udp (ipsec-nat-t / NAT traversal); 1701/udp l2tp (?)<br />
<br />
==== L2TP ====<br />
<br />
IPSec est utilisé sous Windows > 2K avec L2TP.<br />
<br />
Implémentations:<br />
* l2tpd: [http://www.marko.net/l2tp/ passe la main] -> [l2tpd.org domaine abandonné] -> [http://l2tpd.snapgear.org/ changement d'URL] -> [http://l2tpd.sourceforge.net/ remis en ligne, mais inactif] [http://packages.debian.org/unstable/net/l2tpd deb]<br />
* [http://sourceforge.net/projects/l2tpns l2tpns]: incomplet? [http://packages.debian.org/unstable/net/l2tpd deb]<br />
* [http://sourceforge.net/projects/rp-l2tp rp-l2tp]: dernière [http://sourceforge.net/project/showfiles.php?group_id=63352 release] en 2004<br />
* [http://www.xelerance.com/software/xl2tpd/ xl2tpd]: reprise de l2tpd, [ftp://ftp.xelerance.com/xl2tpd/ release] récente (2007)<br />
<br />
=== PPTP ===<br />
<br />
==== Client ====<br />
<br />
* [http://pptpclient.sourceforge.net/documentation.phtml pptpclient]: client GNU/Linux [http://guides.ovh.com/OvpnPptp] [http://pptpclient.sourceforge.net/howto-debian.phtml]<br />
* Inclus dans MS Woe depuis 95OSR2. Failles de sécurité dans la conception ainsi que dans l'implémentation, à réserver en solution de secours.<br />
<br />
Support noyau: cf. [[QEMU#VPN]]<br />
<br />
Configuration:<br />
# Installer pptpclient:<br />
aptitude install pptp-linux<br />
<br />
# /etc/ppp/options.pptp est automatiquement créé, sinon cf [http://pptpclient.sourceforge.net/howto-debian.phtml#configure_by_hand]<br />
<br />
# Description du VPN distant:<br />
cat <<EOF > /etc/ppp/peers/cliss21<br />
file /etc/ppp/options.pptp<br />
# Username (1st field in /etc/ppp/chap-secrets)<br />
name 'sylvain'<br />
# Remote name (2nd field in chap-secrets, not needed if there's "*")<br />
remotename 'cliss21'<br />
# Use a command instead of a real tty<br />
pty "pptp i.cliss21.org --nolaunchpppd"<br />
EOF<br />
<br />
# Fichier de mot de passe:<br />
cat <<EOF > /etc/ppp/chap-secrets<br />
"sylvain" "cliss21" "motdepasse"<br />
EOF<br />
<br />
==== Serveur ====<br />
<br />
* Configuration serveur: [http://poptop.sourceforge.net/dox/]<br />
* Pare-feu: protocole IP 47/GRE, 1723/tcp<br />
** Apparemment le traffic GRE est inclus dans RELATED,ESTABLISHED - sauf pour le réseau local?<br />
** Utiliser <code>-i ppp+</code> pour une règle s'appliquant sur toutes les interfaces <code>ppp0</code>, <code>ppp1</code>, <code>ppp2</code>, etc.<br />
* Support MPPE inclus dans le noyau Linux depuis v2.6.15<br />
<br />
Configuration serveur:<br />
# Installer PoPToP:<br />
aptitude install pptpd<br />
<br />
# Authoriser l'accès vers sylvain@cliss21 pour toute adresse IP<br />
# (recopier le chap-secrets du client et ajouter une '*' à la fin)<br />
# Le nom du serveur peut être différent sur le serveur et le client<br />
# mais doit correspondre à /etc/pptpd.conf:name<br />
cat <<EOF >> /etc/ppp/chap-secrets<br />
sylvain pptp motdepasse *<br />
EOF<br />
<br />
# Configurer le nom du serveur distant<br />
sed -i -e 's/^name .*$/name cliss21/' /etc/ppp/pptp-options<br />
<br />
==== Sécurité ====<br />
<br />
Si vous utilisez un mot de passe qui se trouve dans le dictionnaire de l'attaquant, [http://asleap.sourceforge.net/ asleap] le trouve immédiatement:<br />
# ./genkeys -r /etc/dictionaries-common/words -f dict.dat -n dict.idx<br />
genkeys 1.4 - generates lookup file for asleap. <jwright@hasborg.com><br />
Generating hashes for passwords (this may take some time) ...Done.<br />
98570 hashes written in 0.25 seconds: 393931.74 hashes/second<br />
Starting sort (be patient) ...Done.<br />
Completed sort in 724210 compares.<br />
Creating index file (almost finished) ...Done.<br />
# time ./asleap -i eth0 -f dict.dat -n dict.idx<br />
asleap 1.4 - actively recover LEAP/PPTP passwords. <jwright@hasborg.com><br />
Using the passive attack method.<br />
<br />
Captured PPTP exchange information:<br />
username: sylvain<br />
auth challenge: a0aa0d2e0ca2fde8e36d6a6c69002e9e<br />
peer challenge: 5568ef7b804b35ac77e757aaafa64afa<br />
peer response: 06e1349f2a38048f3702a728e46d9c440b0cd67918d697e1<br />
challenge: 8e5fe08c7dcdbb6e<br />
hash bytes: 89f1<br />
NT hash: 5fd76204806b2fffa86f8fbedf9189f1<br />
password: zwieback<br />
Closing pcap ...<br />
<br />
real 0m3.006s<br />
user 0m0.116s<br />
sys 0m0.004s<br />
<br />
Également vulnérable à une attaque de type [http://en.wikipedia.org/wiki/Rainbow_table rainbow] (force brute efficace pour algorithme de cryptage sans perturbation/''salt''), mais je n'ai pas trouvé d'outil tout prêt.<br />
<br />
=== OpenVPN ===<br />
<br />
* [http://openvpn.net/ OpenVPN]: solution basée sur TLS, ne nécessite aucun support noyau. Non intégré à Woe. Clients et GUI dispos pour GNU/Linux et Woe.<br />
** Pare-feu: 1194/udp (+ peut-être tcp pour le transport over TCP introduit dans la 1.5)<br />
<br />
== TCP over TCP ==<br />
<br />
* [http://docs.mandragor.org/files/Misc/GLFM/lm31/TCP_over_TCP_mauvaise_iD.html TCP over TCP ?]: d'après l'auteur, une mauvaise idée, avec dégradation facile du réseau.<br />
* [http://www.lea-linux.org/cached/index/Tunnels_ethernet_avec_openssh.html Tunnels ethernet avec openssh]: OpenSSH 4 intégre TUN/TAP.<br />
<br />
== À creuser ==<br />
<br />
* [http://vtun.sourceforge.net/ VTun]: Tun/Tap apparemment bien exploité. La documentation du noyau Linux dit qu'il peut faire VPN. Je n'ai rien trouvé dans la doc :/<br />
<br />
== Vieux ==<br />
<br />
* [http://www.freeswan.org/ FreeS/WAN]: abandonné et continué via les forks Openswan et strongSwan.<br />
* [http://packages.debian.org/unstable/net/secvpn secvpn]: construit un VPN à base de SSH et ppp, suivant le [http://tldp.org/HOWTO/VPN-HOWTO/ VPN HOWTO]. TCP over TCP. Vieux.<br />
<br />
== Liens ==<br />
<br />
* [http://www.nimlabs.org/~nim/dirtynat.html Dirty NAT tricks to get a VPN to work with clients also numbered in the private address space]: réadressage dynamique du réseau avec <code>iptables -j NETMAP</code>:<br />
iptables -v -t nat -A PREROUTING -i ppp+ -d 10.22.8.0/24 -j NETMAP --to 192.168.1.0/24<br />
iptables -v -t nat -A POSTROUTING -o ppp+ -s 192.168.1.0/24 -j NETMAP --to 10.22.8.0/24<br />
* [http://www.debian-administration.org/articles/245 Creating a radius based VPN with support for Windows clients]: L2TP + RADIUS + MySQL... et tous les petits soucis infâmes de ce type de montage</div>82.238.35.175https://doc.cliss21.com/index.php?title=VPN&diff=1782VPN2007-03-10T08:02:52Z<p>82.238.35.175 : </p>
<hr />
<div>== Outils de référence ==<br />
<br />
=== IPSec ===<br />
<br />
* [http://ipsec-howto.org/ IPSec]: utilise de nouveaux protocoles IP (AH/50 et ESP/51). Nécessite un support noyau (natif ou KLIPS(=*swan)) et un démon optionnel pour la gestion de clefs, en principe interopétables.<br />
** [http://www.strongswan.org/ strongSwan]<br />
** [http://www.openswan.org/ Openswan]<br />
** intégré au noyau<br />
** racoon<br />
**... à trier ...<br />
** Utilisé par L2TP/IPSec, inclus dans Woe (2K et + ?)<br />
** Pare-feu: protocoles IP 50/AH et 51/ESP, ports 500/udp (isakmp) et 4500/udp (ipsec-nat-t / NAT traversal); 1701/udp l2tp (?)<br />
<br />
==== L2TP ====<br />
<br />
IPSec est utilisé sous Windows > 2K avec L2TP.<br />
* l2tpd: [http://www.marko.net/l2tp/ passe la main] -> [l2tpd.org domaine abandonné] -> [http://l2tpd.snapgear.org/ changement d'URL] -> [http://l2tpd.sourceforge.net/ remis en ligne, mais inactif] [http://packages.debian.org/unstable/net/l2tpd deb]<br />
* [http://sourceforge.net/projects/l2tpns l2tpns]: incomplet? [http://packages.debian.org/unstable/net/l2tpd deb]<br />
<br />
<br />
=== PPTP ===<br />
<br />
==== Client ====<br />
<br />
* [http://pptpclient.sourceforge.net/documentation.phtml pptpclient]: client GNU/Linux [http://guides.ovh.com/OvpnPptp] [http://pptpclient.sourceforge.net/howto-debian.phtml]<br />
* Inclus dans MS Woe depuis 95OSR2. Failles de sécurité dans la conception ainsi que dans l'implémentation, à réserver en solution de secours.<br />
<br />
Support noyau: cf. [[QEMU#VPN]]<br />
<br />
Configuration:<br />
# Installer pptpclient:<br />
aptitude install pptp-linux<br />
<br />
# /etc/ppp/options.pptp est automatiquement créé, sinon cf [http://pptpclient.sourceforge.net/howto-debian.phtml#configure_by_hand]<br />
<br />
# Description du VPN distant:<br />
cat <<EOF > /etc/ppp/peers/cliss21<br />
file /etc/ppp/options.pptp<br />
# Username (1st field in /etc/ppp/chap-secrets)<br />
name 'sylvain'<br />
# Remote name (2nd field in chap-secrets, not needed if there's "*")<br />
remotename 'cliss21'<br />
# Use a command instead of a real tty<br />
pty "pptp i.cliss21.org --nolaunchpppd"<br />
EOF<br />
<br />
# Fichier de mot de passe:<br />
cat <<EOF > /etc/ppp/chap-secrets<br />
"sylvain" "cliss21" "motdepasse"<br />
EOF<br />
<br />
==== Serveur ====<br />
<br />
* Configuration serveur: [http://poptop.sourceforge.net/dox/]<br />
* Pare-feu: protocole IP 47/GRE, 1723/tcp<br />
** Apparemment le traffic GRE est inclus dans RELATED,ESTABLISHED - sauf pour le réseau local?<br />
** Utiliser <code>-i ppp+</code> pour une règle s'appliquant sur toutes les interfaces <code>ppp0</code>, <code>ppp1</code>, <code>ppp2</code>, etc.<br />
* Support MPPE inclus dans le noyau Linux depuis v2.6.15<br />
<br />
Configuration serveur:<br />
# Installer PoPToP:<br />
aptitude install pptpd<br />
<br />
# Authoriser l'accès vers sylvain@cliss21 pour toute adresse IP<br />
# (recopier le chap-secrets du client et ajouter une '*' à la fin)<br />
# Le nom du serveur peut être différent sur le serveur et le client<br />
# mais doit correspondre à /etc/pptpd.conf:name<br />
cat <<EOF >> /etc/ppp/chap-secrets<br />
sylvain pptp motdepasse *<br />
EOF<br />
<br />
# Configurer le nom du serveur distant<br />
sed -i -e 's/^name .*$/name cliss21/' /etc/ppp/pptp-options<br />
<br />
==== Sécurité ====<br />
<br />
Si vous utilisez un mot de passe qui se trouve dans le dictionnaire de l'attaquant, [http://asleap.sourceforge.net/ asleap] le trouve immédiatement:<br />
# ./genkeys -r /etc/dictionaries-common/words -f dict.dat -n dict.idx<br />
genkeys 1.4 - generates lookup file for asleap. <jwright@hasborg.com><br />
Generating hashes for passwords (this may take some time) ...Done.<br />
98570 hashes written in 0.25 seconds: 393931.74 hashes/second<br />
Starting sort (be patient) ...Done.<br />
Completed sort in 724210 compares.<br />
Creating index file (almost finished) ...Done.<br />
# time ./asleap -i eth0 -f dict.dat -n dict.idx<br />
asleap 1.4 - actively recover LEAP/PPTP passwords. <jwright@hasborg.com><br />
Using the passive attack method.<br />
<br />
Captured PPTP exchange information:<br />
username: sylvain<br />
auth challenge: a0aa0d2e0ca2fde8e36d6a6c69002e9e<br />
peer challenge: 5568ef7b804b35ac77e757aaafa64afa<br />
peer response: 06e1349f2a38048f3702a728e46d9c440b0cd67918d697e1<br />
challenge: 8e5fe08c7dcdbb6e<br />
hash bytes: 89f1<br />
NT hash: 5fd76204806b2fffa86f8fbedf9189f1<br />
password: zwieback<br />
Closing pcap ...<br />
<br />
real 0m3.006s<br />
user 0m0.116s<br />
sys 0m0.004s<br />
<br />
Également vulnérable à une attaque de type [http://en.wikipedia.org/wiki/Rainbow_table rainbow] (force brute efficace pour algorithme de cryptage sans perturbation/''salt''), mais je n'ai pas trouvé d'outil tout prêt.<br />
<br />
=== OpenVPN ===<br />
<br />
* [http://openvpn.net/ OpenVPN]: solution basée sur TLS, ne nécessite aucun support noyau. Non intégré à Woe. Clients et GUI dispos pour GNU/Linux et Woe.<br />
** Pare-feu: 1194/udp (+ peut-être tcp pour le transport over TCP introduit dans la 1.5)<br />
<br />
== TCP over TCP ==<br />
<br />
* [http://docs.mandragor.org/files/Misc/GLFM/lm31/TCP_over_TCP_mauvaise_iD.html TCP over TCP ?]: d'après l'auteur, une mauvaise idée, avec dégradation facile du réseau.<br />
* [http://www.lea-linux.org/cached/index/Tunnels_ethernet_avec_openssh.html Tunnels ethernet avec openssh]: OpenSSH 4 intégre TUN/TAP.<br />
<br />
== À creuser ==<br />
<br />
* [http://vtun.sourceforge.net/ VTun]: Tun/Tap apparemment bien exploité. La documentation du noyau Linux dit qu'il peut faire VPN. Je n'ai rien trouvé dans la doc :/<br />
<br />
== Vieux ==<br />
<br />
* [http://www.freeswan.org/ FreeS/WAN]: abandonné et continué via les forks Openswan et strongSwan.<br />
* [http://packages.debian.org/unstable/net/secvpn secvpn]: construit un VPN à base de SSH et ppp, suivant le [http://tldp.org/HOWTO/VPN-HOWTO/ VPN HOWTO]. TCP over TCP. Vieux.<br />
<br />
== Liens ==<br />
<br />
* [http://www.nimlabs.org/~nim/dirtynat.html Dirty NAT tricks to get a VPN to work with clients also numbered in the private address space]: réadressage dynamique du réseau avec <code>iptables -j NETMAP</code>:<br />
iptables -v -t nat -A PREROUTING -i ppp+ -d 10.22.8.0/24 -j NETMAP --to 192.168.1.0/24<br />
iptables -v -t nat -A POSTROUTING -o ppp+ -s 192.168.1.0/24 -j NETMAP --to 10.22.8.0/24<br />
* [http://www.debian-administration.org/articles/245 Creating a radius based VPN with support for Windows clients]: L2TP + RADIUS + MySQL... et tous les petits soucis infâmes de ce type de montage</div>82.238.35.175https://doc.cliss21.com/index.php?title=UserModeLinux&diff=1894UserModeLinux2007-03-05T19:22:06Z<p>82.238.35.175 : /* Liens */</p>
<hr />
<div>UML ou User-mode Linux est un moyen de lancer un deuxième noyau Linux, utilisable sans être root.<br />
C'est en fait un portage du noyau Linux, non pas pour une architecture matérielle, mais pour lui-même. Un portage de Linux pour Linux!<br />
Cela a des points communs avec l'[[Émulation]].<br />
<br />
UML est intégré dans le noyau officiel (kernel.org) depuis un bon moment.<br />
<br />
== Compilation du noyau utilisateur ==<br />
<br />
C'est très simple: on compile le noyau Linux avec le paramètre <code>ARCH=um</code> ''pour chaque commande''.<br />
<br />
wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.13.tar.bz2<br />
tar xjf linux-2.6.17.13.tar.bz2<br />
cd linux-2.6.17.13<br />
<br />
make defconfig ARCH=um<br />
make xconfig ARCH=um # facultatif; pensez à activer HOSTFS si besoin<br />
make ARCH=um<br />
strip linux<br />
make modules_install ARCH=um INSTALL_MOD_PATH=uml-modules/<br />
<br />
Cf. [http://user-mode-linux.sourceforge.net/new/source.html Building from source] chez UML.<br />
<br />
Des options que j'active:<br />
* MAGIC_SYSRQ: active l'équivalent de Alt+ImprÉcr, utilisable depuis uml_mconsole<br />
* HOST_2G_2G: contourne un problème de certains noyaux hôte (cf. plus bas)<br />
* HOSTFS: possibilité de monter des répertoires de la machine hôte - attention à la sécurité)<br />
* STATIC_LINK: compiler le noyau en statique (pas de dépendance sur des bibliothèques partagées .so)<br />
<br />
Il y a également des patches à essayer [http://www.user-mode-linux.org/~blaisorblade/patches/]:<br />
* hôte/host:<br />
** skas3 - meilleures performances (dossier skas3-2.6)<br />
* invité/guest:<br />
** exec support: permet de lancer des commandes shell avec uml_mconsole (ex: [http://www.user-mode-linux.org/~blaisorblade/patches/guest/uml-2.6.18.1-bb2/broken-out/uml-mconsole-exec.diff]) - Jeff Dike recommande cependant de passer par login ou SSH, ce patch a peu de chance d'être inclus officiellement, voir le bouquin au chapitre 8 (p.181).<br />
<br />
== Construction du système de base ==<br />
<br />
On se propose de construire et de lancer un système UML sans aucun accès root.<br />
<br />
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.<br />
<br />
=== Tentative 1 ===<br />
<br />
Essayons de créer un système complet, sans faire d'image, et en possédant tous les fichiers:<br />
<br />
La dernière version de debootstrap propose une variante ''fakechroot'' qui permet de l'utiliser sans accès root:<br />
export PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH # pour trouver la commande 'chroot'<br />
fakechroot /usr/sbin/debootstrap --variant=fakechroot sarge sarge-uml/ http://localhost/mirrors/debian<br />
/usr/src/linux-2.6.17.13/linux root=/dev/root rootflags=/home/sylvain/tests/uml/debian/sarge-uml/ rootfstype=hostfs<br />
<br />
Résultat: cela ne fonctionne pas, à mon avis parce que dans ce cas précis sarge-uml/dev est un lien symbolique vers /dev.<br />
<br />
=== Tentative 2 ===<br />
<br />
Essayons à partir d'une image UML déjà opérationnelle. Le principe est de monter le système de fichier hôte avec ''hostfs'', puis de faire un <code>mount -o loop</code> depuis le UML sur l'image disque à bootstrap-per. Cela permet de monter l'image sans avoir de privilèges super-utilisateur.<br />
<br />
mount none host/ -t hostfs -o /home/sylvain/tests/uml/debian<br />
cd host/<br />
mkdir loop/<br />
mount image -o loop loop/<br />
ls loop/ # -> bin boot dev etc ...<br />
<br />
D'après le ''Rob's quick and dirty UML howto'', nul besoin d'une image disque pour jouer avec UML. Ni donc pour monter une image:<br />
$ ./linux rootfstype=hostfs rw init=/bin/sh quiet<br />
# insmod /usr/src/linux-2.6.20-um/drivers/block/loop.ko<br />
# mount image -o loop loop/<br />
# ls loop/ # -> bin boot dev etc ...<br />
Excellent!!!<br />
Cela ressemble vaguement à un <code>chcontext</code> de VServer.<br />
<br />
Notez l'option <code>rootfstype</code> [http://user-mode-linux.sourceforge.net/hostfs.html] [http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-9.html#ss9.3]. <code>init</code> pointe sur le chemin complet d'un exécutable (binaire ou même script). <br />
[http://packages.debian.org/unstable/utils/rootstrap rootstrap] et [http://packages.debian.org/unstable/devel/pbuilder-uml pbuilder-uml] fonctionnent sur ce principe.<br />
<br />
=== En mode root ===<br />
<br />
Faute de mieux, utilisons sudo:<br />
<br />
mkdir loop/<br />
# image de 1Go, à trous (espace disque progressif)<br />
dd if=/dev/null of=image count=0 bs=1G seek=1<br />
# on formatte en ext3<br />
/sbin/mkfs.ext3 -F image<br />
<br />
sudo mount image loop/ -o loop<br />
sudo debootstrap sarge loop/ http://192.168.1.60/mirrors/debian<br />
<br />
# configuration de la console:<br />
sudo grep -v tty loop/etc/inittab > inittab.work<br />
sudo echo "1:2345:respawn:/sbin/getty 38400 console linux" >> inittab.work<br />
sudo mv inittab.work loop/etc/inittab<br />
<br />
# configuration réseau:<br />
cat <<'EOF' > interfaces.work<br />
auto lo<br />
iface lo inet loopback<br />
EOF<br />
sudo mv interfaces.work loop/etc/network/interfaces<br />
<br />
# fake mtab and fstab<br />
cat <<'EOF' > fstab.work<br />
proc /proc proc defaults 0 0<br />
/dev/ubda / auto defaults,errors=remount-ro 0 1<br />
EOF<br />
sudo mv fstab.work loop/etc/fstab <br />
<br />
sudo umount loop/<br />
<br />
=== Optimiser la taille de l'image pour la distribuer ===<br />
<br />
Une image UML contient souvent des zones vides, où il n'y a pas encore de fichiers. <br />
<br />
L'image ci-dessus réserve 1Go mais n'en occupe que 230Mo grâce à la création d'image "à trous" (''sparse'' en anglais).<br />
<br />
$ ls -lh image<br />
-rw-r--r-- 1 sylvain sylvain 1,0G 2006-09-18 15:55 image<br />
$ du -sh image<br />
234M image<br />
<br />
D'autres méthodes (dd sur /dev/zero par exemple) n'en tiennent pas compte.<br />
<br />
<code>df -h</code> dans UML indique une utilisation de 178Mo, donc on doit pouvoir encore améliorer (comment?). Éviter <code>e2defrag</code>, qui est obsolète et corrompt les systèmes de fichier. Piste: copier les fichiers dans une nouvelle image et supprimer l'ancienne - défragmentation à la volée; inconvénient: les secteurs d'amorçages dont perdus (si vous les utilisez avec qemu, sinon aucune importance).<br />
<br />
<br />
Pour optimiser une image "pleine":<br />
cp --sparse=always image image.sparse<br />
<br />
Pour envoyer une image par le réseau en respectant les trous:<br />
tar cSf image.tar image # S pour "sparse"<br />
<br />
== Réseau ==<br />
<br />
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.<br />
<br />
=== Mode root avec tuntap ===<br />
<br />
host# sudo /usr/src/linux ubda=sarge-debootstrap eth0=tuntap,,,192.168.1.101<br />
<br />
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.<br />
<br />
Puis dans UML:<br />
<br />
uml# ifconfig eth0 192.168.1.201<br />
<br />
=== Mode semi-root avec tuntap ===<br />
<br />
Pour utiliser tuntap, il faut créer à l'avance (et en mode root) une interface tap0 et lui assigner une adresse IP. <br />
<br />
# tunctl -u sylvain<br />
Set 'tap0' persistent and owned by uid 1000<br />
<br />
Puis il faut donner des droits aux utilisateurs non-privilégiés d'utiliser tuntap (en mode root aussi):<br />
<br />
chmod 666 /dev/net/tun<br />
<br />
ou bien ajouter l'utilisateur au groupe "uml-net" (uniquement sous Debian?)<br />
<br />
$ sudo adduser sylvain uml-net<br />
Adding user `sylvain' to group `uml-net' ...<br />
Done.<br />
<br />
C'est une solution efficace mais qui nécessite plusieurs étapes de préconfiguration en mode root.<br />
<br />
Pour accéder au réseau ''et'' en être accessible, configuration manuelle (cf. uml_net pour l'automatisation):<br />
# Côté invité:<br />
ifconfig eth0 192.168.1.200<br />
# Même config routeur que l'hôte:<br />
route add default 192.168.1.1 eth0<br />
# Même config DNS que l'hôte:<br />
echo "nameserver 192.168.1.1" > /etc/resolv.conf<br />
<br />
# Côté hôte:<br />
/sbin/ifconfig tap0 192.168.1.150 netmask 255.255.255.255<br />
# Autoriser le routage des paquets<br />
echo 1 > /proc/sys/net/ipv4/ip_forward<br />
# Exception: cette adresse ne passe pas par eth0:<br />
route add -host 192.168.1.200 dev tap0<br />
<br />
# Pour être visible du réseau, il faut annoncer cette IP sur la carte physique:<br />
echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp<br />
arp -Ds 192.168.1.200 eth0 pub<br />
<br />
# Au moment de partir, on enlève l'annonce ARP:<br />
arp -d 192.168.1.200 dev eth0<br />
<br />
Cela ne fonctionne que si l'on utilise le même réseau que l'hôte. Dans le cas contraire (ex: 172.20.0.0/16), il faudrait ajouter des routes sur toutes les machines du réseau physique pour savoir comment accéder à ce réseau différent (ou alors utiliser l'hôte comme routeur et (D)NATer le traffic).<br />
<br />
Autre solution similaire: avec un pont (bridge).<br />
brctl addbr br0<br />
ifconfig eth0 0.0.0.0 promisc<br />
brctl addif br0 eth0<br />
dhclient br0<br />
<br />
tunctl -u sylvain<br />
brctl addif br0 tap0<br />
# invité: ifconfig eth0 192.168.1.200<br />
<br />
Le pont se chargera d'écouter les paquets sur le réseau à destination de l'adresse du tap0 côté invité, et de les lui envoyer (pas besoin de <code>ip_forward</code>, ni de <code>arp</code>, ni d'une route spéciale pour contacter l'invité, ni d'une IP côté hôte pour tap0). Un inconvénient: la reconfiguration du réseau de la machine hôte. Le super-avantage étant de pouvoir configurer l'invité via le DHCP du réseau physique!<br />
<br />
=== Mode semi-root avec tuntap (2) ===<br />
<br />
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.<br />
<br />
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=tuntap,,,10.10.10.10<br />
uml# ifconfig eth0 10.10.10.11<br />
uml# route add default gw 10.10.10.10<br />
<br />
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...).<br />
<br />
=== Mode utilisateur avec slirp ===<br />
<br />
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'):<br />
<br />
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=slirp,,/usr/bin/slirp-fullbolt<br />
<br />
Dans UML, quelques étapes spécifiques à slirp sont nécessaires:<br />
<br />
# Configurer l'interface sur 10.2.0.15 (IP de choix pour slirp d'après la doc?)<br />
ifconfig eth0 10.2.0.15<br />
# Utiliser la redirection DNS 10.0.2.3<br />
echo "nameserver 10.0.2.3" > /etc/resolv.conf<br />
# Ajouter une route par défaut vers eth0:<br />
route add default dev eth0<br />
<br />
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).<br />
<br />
Note 2: dans QEMU, l'IP assignée est 10.0.2.15. Le DNS est également 10.0.2.3. La configuration se fait automatiquement via un serveur DHCP intégré.<br />
<br />
* Cf. [http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-6.html#ss6.11 Slirp] dans le UML HOWTO.<br />
<br />
=== /etc/network/interfaces ===<br />
<br />
Voici comment configurer automatiquement le réseau au démarrage d'UML, dans son fichier <code>interfaces</code>:<br />
<br />
auto lo<br />
iface lo inet loopback<br />
<br />
auto eth0<br />
iface eth0 inet static<br />
<br />
# eth0=tuntap,,,10.10.10.1<br />
# address 10.10.10.10<br />
# netmask 255.0.0.0<br />
# gateway 10.10.10.1<br />
<br />
# eth0=slirp,,/usr/bin/slirp-fullbolt<br />
address 10.2.0.15<br />
netmask 255.0.0.0<br />
dns-nameservers 10.0.2.3<br />
up route add default eth0<br />
<br />
(dns-nameservers nécessite le paquet ''resolvconf'')<br />
<br />
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.<br />
<br />
== Lancer un UML en tâche fond ==<br />
<br />
./linux ubda=... con=null &<br />
<br />
<br />
== Versions ==<br />
<br />
La version officielle est vraisemblablement celle intégrée au noyau kernel.org.<br />
<br />
Aucune version de développement n'est vraisemblablement accessible.<br />
<br />
La version kernel.org ne compile pas nécessairement ([http://www.gossamer-threads.com/lists/linux/kernel/706384 ex.]).<br />
<br />
Jeff Dyke publie de temps à autre un combo précompilé noyau + image FC5 sur la page d'accueil du site.<br />
<br />
=== Patches ===<br />
<br />
Cf. http://www.user-mode-linux.org/~blaisorblade/<br />
<br />
Clarifions un peu:<br />
* skas3+sysemu: patch pour le noyau hôte pour gagner en rapidité,<br />
* -bb: patch pour le noyau invité, fonctionnalités supplémentaires en test. À utiliser en bloc, ou en choissant une fonctionnalité en particulier parmi un jeu de patches séparés (''splitout''/''broken-out''). Il y a un jeu de patches correspondants pour les uml-utilities.<br />
<br />
C'est un peu confus sur le site, mais c'est tout.<br />
<br />
TODO: il y a aussi les patches pour uml-utilities mais je ne sais pas à quoi ils servent [http://www.user-mode-linux.org/~blaisorblade/uml-utilities/].<br />
<br />
=== Pre-release ===<br />
<br />
http://user-mode-linux.sourceforge.net/patches.html présente les changements non encore publiés, prévus pour inclusion dans la prochaine version du noyau kernel.org. Il y est clairement fait mention que la version de développement n'est pas directement publique (git), si ce n'est ces patches.<br />
<br />
== Liens ==<br />
<br />
* [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<br />
* [http://uml.jfdi.org/uml/Wiki.jsp Wiki UML]: disparate<br />
* [http://uml.openconsultancy.com/ UML-based pseudo-dedicated hosting service]: UML de l'hébergement mutualisé<br />
* [http://www.gentoo.org/doc/en/uml.xml Gentoo Linux Developer's guide to system testing with User-Mode Linux] avec un trick pour tester l'ISO d'install de Gentoo.<br />
* [http://www.landley.net/code/UML.html Rob's quick and dirty UML howto.]: quelques tricks intéressants, comme charger un UML dans la racine courante<br />
* [http://eggdrop.ch/texts/uml/ Running Debian inside of Debian with User-Mode Linux]<br />
* [http://www.metz.supelec.fr/metz/personnel/galtier/PagesPerso/TutorielUML/index.html Tutoriel User Mode Linux]: avec introduction à SKAS et réseau<br />
* [http://www-static.cc.gatech.edu/~gtg861b/ User-Mode Linux Installation Tutorial]: un tutorial complet chez Georgia Tech<br />
* [http://www.phptr.com/bookstore/product.asp?isbn=0131865056&rl=1 Livre] [http://www.eyrolles.com/Informatique/Livre/9780131865051/livre-user-mode-linux.php officiel]: écrit par l'auteur, ce livre est sous licence 'Open Publication' et n'en utilise visiblement aucune des options non-libres. C'est donc un livre libre que l'on peut recommander d'acheter :) La page de présentation indique que les livres de la série "Bruce Perens' Open Source" sont tous sous cette licence et sont publiés au format électronique au bout de 6 mois (il y a retard ici, et l'auteur, contacté via IRC, n'était vraisemblablement pas au courant du caractère libre de la publication - à suivre. Le contenu reste libre quoi qu'il en soit.). J'ai personnellement récupéré un exemplaire au format .chm mais je ne connais pas son origine - je l'ai acheté au format papier aussi. Le livre couvre le réseau, les applications, semble une bonne référence. Il risque cependant de devenir obsolète rapidement. J'ai demandé à l'auteur s'il comptait mettre le livre en ligne par la suite, pour une mise à jour continue: il n'y a pas encore réfléchi.<br />
* [http://testape.com/webtty_sample.php WebTTY]: lancez une instance UML sur le serveur distant et tapez du Bash intéractivement dans un navigateur web :)<br />
* [http://www.ioware.ca/wiki/doku.php/user_mode_linux:testing user_mode_linux:testing]: génération d'image automatisée<br />
* [http://linuxfr.org/2006/08/20/21216.html ShaKe, un défragmenteur pour GNU/Linux] + liens<br />
* [[Émulation]] sur doc.cliss21.com<br />
* Réseau virtuel<br />
** [http://jungla.dit.upm.es/~vnuml/ VNUML]: Virtual Network User Mode Linux, simulation de réseaux complexes<br />
** [http://puzzle.dl.sourceforge.net/sourceforge/vnuml/vnuml-livecd-1.0.iso VIMINAL]: Live-CD alternatif pour VNUML ([http://sourceforge.net/project/showfiles.php?group_id=113582&package_id=203946 download])<br />
** [http://www.strongswan.org/uml/index.htm strongSwan - UML testing]: tests de non-regression de strongSwan avec un réseau virtuel d'UML.<br />
** [http://www.freeswan.org/freeswan_snaps/CURRENT-SNAP/doc/umltesting.html FreeS/WAN User-Mode-Linux Testing guide]: même chose chez FreeS/WAN (projet abandonné), donc plus ancien (noyau 2.4...). Qu'est-ce que uml_netjig??<br />
** [http://www.samag.com/documents/s=8997/sam0401a/0401a.htm Emulating Networks Using User-Mode Linux]: mise en place de IPSec sur une configuration (A<->Routeur)<->Hôte<->(Routeur<->B).<br />
* UML-Utilities: pour changer, le lien est [http://user-mode-linux.sourceforge.net/new/minis.html#utils perdu] au milieu du site. Lien direct: http://user-mode-linux.sourceforge.net/new/uml_utilities_20060622.tar.bz2<br />
<br />
== Dépannage ==<br />
<br />
Kernel panic - not syncing: start_userspace : expected SIGSTOP, got status = 256<br />
<br />
Cf. http://www.mail-archive.com/user-mode-linux-devel@lists.sourceforge.net/msg03414.html<br />
<br />
Votre noyau (hôte) est, si j'ai bien compris, mal configuré. Recompilez-le ou utilisez-en un autre.<br />
<br />
Vous pouvez également activer CONFIG_HOST_2G_2G dans la configuration du noyau UM.</div>82.238.35.175https://doc.cliss21.com/index.php?title=UserModeLinux&diff=1893UserModeLinux2007-03-04T16:52:56Z<p>82.238.35.175 : Pre-release</p>
<hr />
<div>UML ou User-mode Linux est un moyen de lancer un deuxième noyau Linux, utilisable sans être root.<br />
C'est en fait un portage du noyau Linux, non pas pour une architecture matérielle, mais pour lui-même. Un portage de Linux pour Linux!<br />
Cela a des points communs avec l'[[Émulation]].<br />
<br />
UML est intégré dans le noyau officiel (kernel.org) depuis un bon moment.<br />
<br />
== Compilation du noyau utilisateur ==<br />
<br />
C'est très simple: on compile le noyau Linux avec le paramètre <code>ARCH=um</code> ''pour chaque commande''.<br />
<br />
wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.13.tar.bz2<br />
tar xjf linux-2.6.17.13.tar.bz2<br />
cd linux-2.6.17.13<br />
<br />
make defconfig ARCH=um<br />
make xconfig ARCH=um # facultatif; pensez à activer HOSTFS si besoin<br />
make ARCH=um<br />
strip linux<br />
make modules_install ARCH=um INSTALL_MOD_PATH=uml-modules/<br />
<br />
Cf. [http://user-mode-linux.sourceforge.net/new/source.html Building from source] chez UML.<br />
<br />
Des options que j'active:<br />
* MAGIC_SYSRQ: active l'équivalent de Alt+ImprÉcr, utilisable depuis uml_mconsole<br />
* HOST_2G_2G: contourne un problème de certains noyaux hôte (cf. plus bas)<br />
* HOSTFS: possibilité de monter des répertoires de la machine hôte - attention à la sécurité)<br />
* STATIC_LINK: compiler le noyau en statique (pas de dépendance sur des bibliothèques partagées .so)<br />
<br />
Il y a également des patches à essayer [http://www.user-mode-linux.org/~blaisorblade/patches/]:<br />
* hôte/host:<br />
** skas3 - meilleures performances (dossier skas3-2.6)<br />
* invité/guest:<br />
** exec support: permet de lancer des commandes shell avec uml_mconsole (ex: [http://www.user-mode-linux.org/~blaisorblade/patches/guest/uml-2.6.18.1-bb2/broken-out/uml-mconsole-exec.diff]) - Jeff Dike recommande cependant de passer par login ou SSH, ce patch a peu de chance d'être inclus officiellement, voir le bouquin au chapitre 8 (p.181).<br />
<br />
== Construction du système de base ==<br />
<br />
On se propose de construire et de lancer un système UML sans aucun accès root.<br />
<br />
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.<br />
<br />
=== Tentative 1 ===<br />
<br />
Essayons de créer un système complet, sans faire d'image, et en possédant tous les fichiers:<br />
<br />
La dernière version de debootstrap propose une variante ''fakechroot'' qui permet de l'utiliser sans accès root:<br />
export PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH # pour trouver la commande 'chroot'<br />
fakechroot /usr/sbin/debootstrap --variant=fakechroot sarge sarge-uml/ http://localhost/mirrors/debian<br />
/usr/src/linux-2.6.17.13/linux root=/dev/root rootflags=/home/sylvain/tests/uml/debian/sarge-uml/ rootfstype=hostfs<br />
<br />
Résultat: cela ne fonctionne pas, à mon avis parce que dans ce cas précis sarge-uml/dev est un lien symbolique vers /dev.<br />
<br />
=== Tentative 2 ===<br />
<br />
Essayons à partir d'une image UML déjà opérationnelle. Le principe est de monter le système de fichier hôte avec ''hostfs'', puis de faire un <code>mount -o loop</code> depuis le UML sur l'image disque à bootstrap-per. Cela permet de monter l'image sans avoir de privilèges super-utilisateur.<br />
<br />
mount none host/ -t hostfs -o /home/sylvain/tests/uml/debian<br />
cd host/<br />
mkdir loop/<br />
mount image -o loop loop/<br />
ls loop/ # -> bin boot dev etc ...<br />
<br />
D'après le ''Rob's quick and dirty UML howto'', nul besoin d'une image disque pour jouer avec UML. Ni donc pour monter une image:<br />
$ ./linux rootfstype=hostfs rw init=/bin/sh quiet<br />
# insmod /usr/src/linux-2.6.20-um/drivers/block/loop.ko<br />
# mount image -o loop loop/<br />
# ls loop/ # -> bin boot dev etc ...<br />
Excellent!!!<br />
Cela ressemble vaguement à un <code>chcontext</code> de VServer.<br />
<br />
Notez l'option <code>rootfstype</code> [http://user-mode-linux.sourceforge.net/hostfs.html] [http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-9.html#ss9.3]. <code>init</code> pointe sur le chemin complet d'un exécutable (binaire ou même script). <br />
[http://packages.debian.org/unstable/utils/rootstrap rootstrap] et [http://packages.debian.org/unstable/devel/pbuilder-uml pbuilder-uml] fonctionnent sur ce principe.<br />
<br />
=== En mode root ===<br />
<br />
Faute de mieux, utilisons sudo:<br />
<br />
mkdir loop/<br />
# image de 1Go, à trous (espace disque progressif)<br />
dd if=/dev/null of=image count=0 bs=1G seek=1<br />
# on formatte en ext3<br />
/sbin/mkfs.ext3 -F image<br />
<br />
sudo mount image loop/ -o loop<br />
sudo debootstrap sarge loop/ http://192.168.1.60/mirrors/debian<br />
<br />
# configuration de la console:<br />
sudo grep -v tty loop/etc/inittab > inittab.work<br />
sudo echo "1:2345:respawn:/sbin/getty 38400 console linux" >> inittab.work<br />
sudo mv inittab.work loop/etc/inittab<br />
<br />
# configuration réseau:<br />
cat <<'EOF' > interfaces.work<br />
auto lo<br />
iface lo inet loopback<br />
EOF<br />
sudo mv interfaces.work loop/etc/network/interfaces<br />
<br />
# fake mtab and fstab<br />
cat <<'EOF' > fstab.work<br />
proc /proc proc defaults 0 0<br />
/dev/ubda / auto defaults,errors=remount-ro 0 1<br />
EOF<br />
sudo mv fstab.work loop/etc/fstab <br />
<br />
sudo umount loop/<br />
<br />
=== Optimiser la taille de l'image pour la distribuer ===<br />
<br />
Une image UML contient souvent des zones vides, où il n'y a pas encore de fichiers. <br />
<br />
L'image ci-dessus réserve 1Go mais n'en occupe que 230Mo grâce à la création d'image "à trous" (''sparse'' en anglais).<br />
<br />
$ ls -lh image<br />
-rw-r--r-- 1 sylvain sylvain 1,0G 2006-09-18 15:55 image<br />
$ du -sh image<br />
234M image<br />
<br />
D'autres méthodes (dd sur /dev/zero par exemple) n'en tiennent pas compte.<br />
<br />
<code>df -h</code> dans UML indique une utilisation de 178Mo, donc on doit pouvoir encore améliorer (comment?). Éviter <code>e2defrag</code>, qui est obsolète et corrompt les systèmes de fichier. Piste: copier les fichiers dans une nouvelle image et supprimer l'ancienne - défragmentation à la volée; inconvénient: les secteurs d'amorçages dont perdus (si vous les utilisez avec qemu, sinon aucune importance).<br />
<br />
<br />
Pour optimiser une image "pleine":<br />
cp --sparse=always image image.sparse<br />
<br />
Pour envoyer une image par le réseau en respectant les trous:<br />
tar cSf image.tar image # S pour "sparse"<br />
<br />
== Réseau ==<br />
<br />
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.<br />
<br />
=== Mode root avec tuntap ===<br />
<br />
host# sudo /usr/src/linux ubda=sarge-debootstrap eth0=tuntap,,,192.168.1.101<br />
<br />
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.<br />
<br />
Puis dans UML:<br />
<br />
uml# ifconfig eth0 192.168.1.201<br />
<br />
=== Mode semi-root avec tuntap ===<br />
<br />
Pour utiliser tuntap, il faut créer à l'avance (et en mode root) une interface tap0 et lui assigner une adresse IP. <br />
<br />
# tunctl -u sylvain<br />
Set 'tap0' persistent and owned by uid 1000<br />
<br />
Puis il faut donner des droits aux utilisateurs non-privilégiés d'utiliser tuntap (en mode root aussi):<br />
<br />
chmod 666 /dev/net/tun<br />
<br />
ou bien ajouter l'utilisateur au groupe "uml-net" (uniquement sous Debian?)<br />
<br />
$ sudo adduser sylvain uml-net<br />
Adding user `sylvain' to group `uml-net' ...<br />
Done.<br />
<br />
C'est une solution efficace mais qui nécessite plusieurs étapes de préconfiguration en mode root.<br />
<br />
Pour accéder au réseau ''et'' en être accessible, configuration manuelle (cf. uml_net pour l'automatisation):<br />
# Côté invité:<br />
ifconfig eth0 192.168.1.200<br />
# Même config routeur que l'hôte:<br />
route add default 192.168.1.1 eth0<br />
# Même config DNS que l'hôte:<br />
echo "nameserver 192.168.1.1" > /etc/resolv.conf<br />
<br />
# Côté hôte:<br />
/sbin/ifconfig tap0 192.168.1.150 netmask 255.255.255.255<br />
# Autoriser le routage des paquets<br />
echo 1 > /proc/sys/net/ipv4/ip_forward<br />
# Exception: cette adresse ne passe pas par eth0:<br />
route add -host 192.168.1.200 dev tap0<br />
<br />
# Pour être visible du réseau, il faut annoncer cette IP sur la carte physique:<br />
echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp<br />
arp -Ds 192.168.1.200 eth0 pub<br />
<br />
# Au moment de partir, on enlève l'annonce ARP:<br />
arp -d 192.168.1.200 dev eth0<br />
<br />
Cela ne fonctionne que si l'on utilise le même réseau que l'hôte. Dans le cas contraire (ex: 172.20.0.0/16), il faudrait ajouter des routes sur toutes les machines du réseau physique pour savoir comment accéder à ce réseau différent (ou alors utiliser l'hôte comme routeur et (D)NATer le traffic).<br />
<br />
Autre solution similaire: avec un pont (bridge).<br />
brctl addbr br0<br />
ifconfig eth0 0.0.0.0 promisc<br />
brctl addif br0 eth0<br />
dhclient br0<br />
<br />
tunctl -u sylvain<br />
brctl addif br0 tap0<br />
# invité: ifconfig eth0 192.168.1.200<br />
<br />
Le pont se chargera d'écouter les paquets sur le réseau à destination de l'adresse du tap0 côté invité, et de les lui envoyer (pas besoin de <code>ip_forward</code>, ni de <code>arp</code>, ni d'une route spéciale pour contacter l'invité, ni d'une IP côté hôte pour tap0). Un inconvénient: la reconfiguration du réseau de la machine hôte. Le super-avantage étant de pouvoir configurer l'invité via le DHCP du réseau physique!<br />
<br />
=== Mode semi-root avec tuntap (2) ===<br />
<br />
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.<br />
<br />
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=tuntap,,,10.10.10.10<br />
uml# ifconfig eth0 10.10.10.11<br />
uml# route add default gw 10.10.10.10<br />
<br />
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...).<br />
<br />
=== Mode utilisateur avec slirp ===<br />
<br />
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'):<br />
<br />
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=slirp,,/usr/bin/slirp-fullbolt<br />
<br />
Dans UML, quelques étapes spécifiques à slirp sont nécessaires:<br />
<br />
# Configurer l'interface sur 10.2.0.15 (IP de choix pour slirp d'après la doc?)<br />
ifconfig eth0 10.2.0.15<br />
# Utiliser la redirection DNS 10.0.2.3<br />
echo "nameserver 10.0.2.3" > /etc/resolv.conf<br />
# Ajouter une route par défaut vers eth0:<br />
route add default dev eth0<br />
<br />
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).<br />
<br />
Note 2: dans QEMU, l'IP assignée est 10.0.2.15. Le DNS est également 10.0.2.3. La configuration se fait automatiquement via un serveur DHCP intégré.<br />
<br />
* Cf. [http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-6.html#ss6.11 Slirp] dans le UML HOWTO.<br />
<br />
=== /etc/network/interfaces ===<br />
<br />
Voici comment configurer automatiquement le réseau au démarrage d'UML, dans son fichier <code>interfaces</code>:<br />
<br />
auto lo<br />
iface lo inet loopback<br />
<br />
auto eth0<br />
iface eth0 inet static<br />
<br />
# eth0=tuntap,,,10.10.10.1<br />
# address 10.10.10.10<br />
# netmask 255.0.0.0<br />
# gateway 10.10.10.1<br />
<br />
# eth0=slirp,,/usr/bin/slirp-fullbolt<br />
address 10.2.0.15<br />
netmask 255.0.0.0<br />
dns-nameservers 10.0.2.3<br />
up route add default eth0<br />
<br />
(dns-nameservers nécessite le paquet ''resolvconf'')<br />
<br />
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.<br />
<br />
== Lancer un UML en tâche fond ==<br />
<br />
./linux ubda=... con=null &<br />
<br />
<br />
== Versions ==<br />
<br />
La version officielle est vraisemblablement celle intégrée au noyau kernel.org.<br />
<br />
Aucune version de développement n'est vraisemblablement accessible.<br />
<br />
La version kernel.org ne compile pas nécessairement ([http://www.gossamer-threads.com/lists/linux/kernel/706384 ex.]).<br />
<br />
Jeff Dyke publie de temps à autre un combo précompilé noyau + image FC5 sur la page d'accueil du site.<br />
<br />
=== Patches ===<br />
<br />
Cf. http://www.user-mode-linux.org/~blaisorblade/<br />
<br />
Clarifions un peu:<br />
* skas3+sysemu: patch pour le noyau hôte pour gagner en rapidité,<br />
* -bb: patch pour le noyau invité, fonctionnalités supplémentaires en test. À utiliser en bloc, ou en choissant une fonctionnalité en particulier parmi un jeu de patches séparés (''splitout''/''broken-out''). Il y a un jeu de patches correspondants pour les uml-utilities.<br />
<br />
C'est un peu confus sur le site, mais c'est tout.<br />
<br />
TODO: il y a aussi les patches pour uml-utilities mais je ne sais pas à quoi ils servent [http://www.user-mode-linux.org/~blaisorblade/uml-utilities/].<br />
<br />
=== Pre-release ===<br />
<br />
http://user-mode-linux.sourceforge.net/patches.html présente les changements non encore publiés, prévus pour inclusion dans la prochaine version du noyau kernel.org. Il y est clairement fait mention que la version de développement n'est pas directement publique (git), si ce n'est ces patches.<br />
<br />
== Liens ==<br />
<br />
* [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<br />
* [http://uml.jfdi.org/uml/Wiki.jsp Wiki UML]: disparate<br />
* [http://uml.openconsultancy.com/ UML-based pseudo-dedicated hosting service]: UML de l'hébergement mutualisé<br />
* [http://www.gentoo.org/doc/en/uml.xml Gentoo Linux Developer's guide to system testing with User-Mode Linux] avec un trick pour tester l'ISO d'install de Gentoo.<br />
* [http://www.landley.net/code/UML.html Rob's quick and dirty UML howto.]: quelques tricks intéressants, comme charger un UML dans la racine courante<br />
* [http://eggdrop.ch/texts/uml/ Running Debian inside of Debian with User-Mode Linux]<br />
* [http://www.metz.supelec.fr/metz/personnel/galtier/PagesPerso/TutorielUML/index.html Tutoriel User Mode Linux]: avec introduction à SKAS et réseau<br />
* [http://www-static.cc.gatech.edu/~gtg861b/ User-Mode Linux Installation Tutorial]: un tutorial complet chez Georgia Tech<br />
* [http://www.phptr.com/bookstore/product.asp?isbn=0131865056&rl=1 Livre] [http://www.eyrolles.com/Informatique/Livre/9780131865051/livre-user-mode-linux.php officiel]: écrit par l'auteur, ce livre est sous licence 'Open Publication' et n'en utilise visiblement aucune des options non-libres. C'est donc un livre libre que l'on peut recommander d'acheter :) La page de présentation indique que les livres de la série "Bruce Perens' Open Source" sont tous sous cette licence et sont publiés au format électronique au bout de 6 mois (il y a retard ici, et l'auteur, contacté via IRC, n'était vraisemblablement pas au courant du caractère libre de la publication - à suivre. Le contenu reste libre quoi qu'il en soit.). J'ai personnellement récupéré un exemplaire au format .chm mais je ne connais pas son origine - je l'ai acheté au format papier aussi. Le livre couvre le réseau, les applications, semble une bonne référence. Il risque cependant de devenir obsolète rapidement. J'ai demandé à l'auteur s'il comptait mettre le livre en ligne par la suite, pour une mise à jour continue: il n'y a pas encore réfléchi.<br />
* [http://testape.com/webtty_sample.php WebTTY]: lancez une instance UML sur le serveur distant et tapez du Bash intéractivement dans un navigateur web :)<br />
* [http://linuxfr.org/2006/08/20/21216.html ShaKe, un défragmenteur pour GNU/Linux] + liens<br />
* [[Émulation]] sur doc.cliss21.com<br />
* Réseau virtuel<br />
** [http://jungla.dit.upm.es/~vnuml/ VNUML]: Virtual Network User Mode Linux, simulation de réseaux complexes<br />
** [http://puzzle.dl.sourceforge.net/sourceforge/vnuml/vnuml-livecd-1.0.iso VIMINAL]: Live-CD alternatif pour VNUML ([http://sourceforge.net/project/showfiles.php?group_id=113582&package_id=203946 download])<br />
** [http://www.strongswan.org/uml/index.htm strongSwan - UML testing]: tests de non-regression de strongSwan avec un réseau virtuel d'UML.<br />
** [http://www.freeswan.org/freeswan_snaps/CURRENT-SNAP/doc/umltesting.html FreeS/WAN User-Mode-Linux Testing guide]: même chose chez FreeS/WAN (projet abandonné), donc plus ancien (noyau 2.4...). Qu'est-ce que uml_netjig??<br />
** [http://www.samag.com/documents/s=8997/sam0401a/0401a.htm Emulating Networks Using User-Mode Linux]: mise en place de IPSec sur une configuration (A<->Routeur)<->Hôte<->(Routeur<->B).<br />
* UML-Utilities: pour changer, le lien est [http://user-mode-linux.sourceforge.net/new/minis.html#utils perdu] au milieu du site. Lien direct: http://user-mode-linux.sourceforge.net/new/uml_utilities_20060622.tar.bz2<br />
<br />
== Dépannage ==<br />
<br />
Kernel panic - not syncing: start_userspace : expected SIGSTOP, got status = 256<br />
<br />
Cf. http://www.mail-archive.com/user-mode-linux-devel@lists.sourceforge.net/msg03414.html<br />
<br />
Votre noyau (hôte) est, si j'ai bien compris, mal configuré. Recompilez-le ou utilisez-en un autre.<br />
<br />
Vous pouvez également activer CONFIG_HOST_2G_2G dans la configuration du noyau UM.</div>82.238.35.175https://doc.cliss21.com/index.php?title=UserModeLinux&diff=1890UserModeLinux2007-03-01T21:36:02Z<p>82.238.35.175 : intro</p>
<hr />
<div>UML ou User-mode Linux est un moyen de lancer un deuxième noyau Linux, utilisable sans être root.<br />
C'est en fait un portage du noyau Linux, non pas pour une architecture matérielle, mais pour lui-même. Un portage de Linux pour Linux!<br />
Cela a des points communs avec l'[[Émulation]].<br />
<br />
UML est intégré dans le noyau officiel (kernel.org) depuis un bon moment.<br />
<br />
== Compilation du noyau utilisateur ==<br />
<br />
C'est très simple: on compile le noyau Linux avec le paramètre <code>ARCH=um</code> ''pour chaque commande''.<br />
<br />
wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.13.tar.bz2<br />
tar xjf linux-2.6.17.13.tar.bz2<br />
cd linux-2.6.17.13<br />
<br />
make defconfig ARCH=um<br />
make xconfig ARCH=um # facultatif; pensez à activer HOSTFS si besoin<br />
make ARCH=um<br />
strip linux<br />
make modules_install ARCH=um INSTALL_MOD_PATH=uml-modules/<br />
<br />
Cf. [http://user-mode-linux.sourceforge.net/new/source.html Building from source] chez UML.<br />
<br />
Des options que j'active:<br />
* MAGIC_SYSRQ: active l'équivalent de Alt+ImprÉcr, utilisable depuis uml_mconsole<br />
* HOST_2G_2G: contourne un problème de certains noyaux hôte (cf. plus bas)<br />
* HOSTFS: possibilité de monter des répertoires de la machine hôte - attention à la sécurité)<br />
* STATIC_LINK: compiler le noyau en statique (pas de dépendance sur des bibliothèques partagées .so)<br />
<br />
Il y a également des patches à essayer [http://www.user-mode-linux.org/~blaisorblade/patches/]:<br />
* hôte/host:<br />
** skas3 - meilleures performances (dossier skas3-2.6)<br />
* invité/guest:<br />
** exec support: permet de lancer des commandes shell avec uml_mconsole (ex: [http://www.user-mode-linux.org/~blaisorblade/patches/guest/uml-2.6.18.1-bb2/broken-out/uml-mconsole-exec.diff]) - Jeff Dike recommande cependant de passer par login ou SSH, ce patch a peu de chance d'être inclus officiellement, voir le bouquin au chapitre 8 (p.181).<br />
<br />
== Construction du système de base ==<br />
<br />
On se propose de construire et de lancer un système UML sans aucun accès root.<br />
<br />
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.<br />
<br />
=== Tentative 1 ===<br />
<br />
Essayons de créer un système complet, sans faire d'image, et en possédant tous les fichiers:<br />
<br />
La dernière version de debootstrap propose une variante ''fakechroot'' qui permet de l'utiliser sans accès root:<br />
export PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH # pour trouver la commande 'chroot'<br />
fakechroot /usr/sbin/debootstrap --variant=fakechroot sarge sarge-uml/ http://localhost/mirrors/debian<br />
/usr/src/linux-2.6.17.13/linux root=/dev/root rootflags=/home/sylvain/tests/uml/debian/sarge-uml/ rootfstype=hostfs<br />
<br />
Résultat: cela ne fonctionne pas, à mon avis parce que dans ce cas précis sarge-uml/dev est un lien symbolique vers /dev.<br />
<br />
=== Tentative 2 ===<br />
<br />
Essayons à partir d'une image UML déjà opérationnelle. Le principe est de monter le système de fichier hôte avec ''hostfs'', puis de faire un <code>mount -o loop</code> depuis le UML sur l'image disque à bootstrap-per. Cela permet de monter l'image sans avoir de privilèges super-utilisateur.<br />
<br />
mount none host/ -t hostfs -o /home/sylvain/tests/uml/debian<br />
cd host/<br />
mkdir loop/<br />
mount image -o loop loop/<br />
ls loop/ # -> bin boot dev etc ...<br />
<br />
D'après le ''Rob's quick and dirty UML howto'', nul besoin d'une image disque pour jouer avec UML. Ni donc pour monter une image:<br />
$ ./linux rootfstype=hostfs rw init=/bin/sh quiet<br />
# insmod /usr/src/linux-2.6.20-um/drivers/block/loop.ko<br />
# mount image -o loop loop/<br />
# ls loop/ # -> bin boot dev etc ...<br />
Excellent!!!<br />
Cela ressemble vaguement à un <code>chcontext</code> de VServer.<br />
<br />
Notez l'option [http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-9.html#ss9.3 peu documentée] <code>rootfstype</code>. <code>init</code> pointe sur le chemin complet d'un exécutable (binaire ou même script). <br />
[http://packages.debian.org/unstable/utils/rootstrap rootstrap] fonctionne sur ce principe.<br />
<br />
=== En mode root ===<br />
<br />
Faute de mieux, utilisons sudo:<br />
<br />
mkdir loop/<br />
# image de 1Go, à trous (espace disque progressif)<br />
dd if=/dev/null of=image count=0 bs=1G seek=1<br />
# on formatte en ext3<br />
/sbin/mkfs.ext3 -F image<br />
<br />
sudo mount image loop/ -o loop<br />
sudo debootstrap sarge loop/ http://192.168.1.60/mirrors/debian<br />
<br />
# configuration de la console:<br />
sudo grep -v tty loop/etc/inittab > inittab.work<br />
sudo echo "1:2345:respawn:/sbin/getty 38400 console linux" >> inittab.work<br />
sudo mv inittab.work loop/etc/inittab<br />
<br />
# configuration réseau:<br />
cat <<'EOF' > interfaces.work<br />
auto lo<br />
iface lo inet loopback<br />
EOF<br />
sudo mv interfaces.work loop/etc/network/interfaces<br />
<br />
# fake mtab and fstab<br />
cat <<'EOF' > fstab.work<br />
proc /proc proc defaults 0 0<br />
/dev/ubda / auto defaults,errors=remount-ro 0 1<br />
EOF<br />
sudo mv fstab.work loop/etc/fstab <br />
<br />
sudo umount loop/<br />
<br />
=== Optimiser la taille de l'image pour la distribuer ===<br />
<br />
Une image UML contient souvent des zones vides, où il n'y a pas encore de fichiers. <br />
<br />
L'image ci-dessus réserve 1Go mais n'en occupe que 230Mo grâce à la création d'image "à trous" (''sparse'' en anglais).<br />
<br />
$ ls -lh image<br />
-rw-r--r-- 1 sylvain sylvain 1,0G 2006-09-18 15:55 image<br />
$ du -sh image<br />
234M image<br />
<br />
D'autres méthodes (dd sur /dev/zero par exemple) n'en tiennent pas compte.<br />
<br />
<code>df -h</code> dans UML indique une utilisation de 178Mo, donc on doit pouvoir encore améliorer (comment?). Éviter <code>e2defrag</code>, qui est obsolète et corrompt les systèmes de fichier. Piste: copier les fichiers dans une nouvelle image et supprimer l'ancienne - défragmentation à la volée; inconvénient: les secteurs d'amorçages dont perdus (si vous les utilisez avec qemu, sinon aucune importance).<br />
<br />
<br />
Pour optimiser une image "pleine":<br />
cp --sparse=always image image.sparse<br />
<br />
Pour envoyer une image par le réseau en respectant les trous:<br />
tar cSf image.tar image # S pour "sparse"<br />
<br />
== Réseau ==<br />
<br />
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.<br />
<br />
=== Mode root avec tuntap ===<br />
<br />
host# sudo /usr/src/linux ubda=sarge-debootstrap eth0=tuntap,,,192.168.1.101<br />
<br />
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.<br />
<br />
Puis dans UML:<br />
<br />
uml# ifconfig eth0 192.168.1.201<br />
<br />
=== Mode semi-root avec tuntap ===<br />
<br />
Pour utiliser tuntap, il faut créer à l'avance (et en mode root) une interface tap0 et lui assigner une adresse IP. <br />
<br />
# tunctl -u sylvain<br />
Set 'tap0' persistent and owned by uid 1000<br />
<br />
Puis il faut donner des droits aux utilisateurs non-privilégiés d'utiliser tuntap (en mode root aussi):<br />
<br />
chmod 666 /dev/net/tun<br />
<br />
ou bien ajouter l'utilisateur au groupe "uml-net" (uniquement sous Debian?)<br />
<br />
$ sudo adduser sylvain uml-net<br />
Adding user `sylvain' to group `uml-net' ...<br />
Done.<br />
<br />
C'est une solution efficace mais qui nécessite plusieurs étapes de préconfiguration en mode root.<br />
<br />
Pour accéder au réseau ''et'' en être accessible, configuration manuelle (cf. uml_net pour l'automatisation):<br />
# Côté invité:<br />
ifconfig eth0 192.168.1.200<br />
# Même config routeur que l'hôte:<br />
route add default 192.168.1.1 eth0<br />
# Même config DNS que l'hôte:<br />
echo "nameserver 192.168.1.1" > /etc/resolv.conf<br />
<br />
# Côté hôte:<br />
/sbin/ifconfig tap0 192.168.1.150 netmask 255.255.255.255<br />
# Autoriser le routage des paquets<br />
echo 1 > /proc/sys/net/ipv4/ip_forward<br />
# Exception: cette adresse ne passe pas par eth0:<br />
route add -host 192.168.1.200 dev tap0<br />
<br />
# Pour être visible du réseau, il faut annoncer cette IP sur la carte physique:<br />
echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp<br />
arp -Ds 192.168.1.200 eth0 pub<br />
<br />
# Au moment de partir, on enlève l'annonce ARP:<br />
arp -d 192.168.1.200 dev eth0<br />
<br />
Cela ne fonctionne que si l'on utilise le même réseau que l'hôte. Dans le cas contraire (ex: 172.20.0.0/16), il faudrait ajouter des routes sur toutes les machines du réseau physique pour savoir comment accéder à ce réseau différent (ou alors utiliser l'hôte comme routeur et (D)NATer le traffic).<br />
<br />
Autre solution similaire: avec un pont (bridge).<br />
brctl addbr br0<br />
ifconfig eth0 0.0.0.0 promisc<br />
brctl addif br0 eth0<br />
dhclient br0<br />
<br />
tunctl -u sylvain<br />
brctl addif br0 tap0<br />
# invité: ifconfig eth0 192.168.1.200<br />
<br />
Le pont se chargera d'écouter les paquets sur le réseau à destination de l'adresse du tap0 côté invité, et de les lui envoyer (pas besoin de <code>ip_forward</code>, ni de <code>arp</code>, ni d'une route spéciale pour contacter l'invité, ni d'une IP côté hôte pour tap0). Un inconvénient: la reconfiguration du réseau de la machine hôte. Le super-avantage étant de pouvoir configurer l'invité via le DHCP du réseau physique!<br />
<br />
=== Mode semi-root avec tuntap (2) ===<br />
<br />
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.<br />
<br />
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=tuntap,,,10.10.10.10<br />
uml# ifconfig eth0 10.10.10.11<br />
uml# route add default gw 10.10.10.10<br />
<br />
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...).<br />
<br />
=== Mode utilisateur avec slirp ===<br />
<br />
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'):<br />
<br />
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=slirp,,/usr/bin/slirp-fullbolt<br />
<br />
Dans UML, quelques étapes spécifiques à slirp sont nécessaires:<br />
<br />
# Configurer l'interface sur 10.2.0.15 (IP de choix pour slirp d'après la doc?)<br />
ifconfig eth0 10.2.0.15<br />
# Utiliser la redirection DNS 10.0.2.3<br />
echo "nameserver 10.0.2.3" > /etc/resolv.conf<br />
# Ajouter une route par défaut vers eth0:<br />
route add default dev eth0<br />
<br />
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).<br />
<br />
Note 2: dans QEMU, l'IP assignée est 10.0.2.15. Le DNS est également 10.0.2.3. La configuration se fait automatiquement via un serveur DHCP intégré.<br />
<br />
* Cf. [http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-6.html#ss6.11 Slirp] dans le UML HOWTO.<br />
<br />
=== /etc/network/interfaces ===<br />
<br />
Voici comment configurer automatiquement le réseau au démarrage d'UML, dans son fichier <code>interfaces</code>:<br />
<br />
auto lo<br />
iface lo inet loopback<br />
<br />
auto eth0<br />
iface eth0 inet static<br />
<br />
# eth0=tuntap,,,10.10.10.1<br />
# address 10.10.10.10<br />
# netmask 255.0.0.0<br />
# gateway 10.10.10.1<br />
<br />
# eth0=slirp,,/usr/bin/slirp-fullbolt<br />
address 10.2.0.15<br />
netmask 255.0.0.0<br />
dns-nameservers 10.0.2.3<br />
up route add default eth0<br />
<br />
(dns-nameservers nécessite le paquet ''resolvconf'')<br />
<br />
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.<br />
<br />
== Lancer un UML en tâche fond ==<br />
<br />
./linux ubda=... con=null &<br />
<br />
<br />
== Versions ==<br />
<br />
La version officielle est vraisemblablement celle intégrée au noyau kernel.org.<br />
<br />
Aucune version de développement n'est vraisemblablement accessible.<br />
<br />
La version kernel.org ne compile pas nécessairement ([http://www.gossamer-threads.com/lists/linux/kernel/706384 ex.]).<br />
<br />
Jeff Dyke publie de temps à autre un combo précompilé noyau + image FC5 sur la page d'accueil du site.<br />
<br />
=== Patches ===<br />
<br />
Cf. http://www.user-mode-linux.org/~blaisorblade/<br />
<br />
Clarifions un peu:<br />
* skas3+sysemu: patch pour le noyau hôte pour gagner en rapidité,<br />
* -bb: patch pour le noyau invité, fonctionnalités supplémentaires en test. À utiliser en bloc, ou en choissant une fonctionnalité en particulier parmi un jeu de patches séparés (''splitout''/''broken-out''). Il y a un jeu de patches correspondants pour les uml-utilities.<br />
<br />
C'est un peu confus sur le site, mais c'est tout.<br />
<br />
TODO: il y a aussi les patches pour uml-utilities mais je ne sais pas à quoi ils servent [http://www.user-mode-linux.org/~blaisorblade/uml-utilities/].<br />
<br />
== Liens ==<br />
<br />
* [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<br />
* [http://uml.jfdi.org/uml/Wiki.jsp Wiki UML]: disparate<br />
* [http://uml.openconsultancy.com/ UML-based pseudo-dedicated hosting service]: UML de l'hébergement mutualisé<br />
* [http://www.gentoo.org/doc/en/uml.xml Gentoo Linux Developer's guide to system testing with User-Mode Linux] avec un trick pour tester l'ISO d'install de Gentoo.<br />
* [http://www.landley.net/code/UML.html Rob's quick and dirty UML howto.]: quelques tricks intéressants, comme charger un UML dans la racine courante<br />
* [http://eggdrop.ch/texts/uml/ Running Debian inside of Debian with User-Mode Linux]<br />
* [http://www.metz.supelec.fr/metz/personnel/galtier/PagesPerso/TutorielUML/index.html Tutoriel User Mode Linux]: avec introduction à SKAS et réseau<br />
* [http://www-static.cc.gatech.edu/~gtg861b/ User-Mode Linux Installation Tutorial]: un tutorial complet chez Georgia Tech<br />
* [http://www.phptr.com/bookstore/product.asp?isbn=0131865056&rl=1 Livre] [http://www.eyrolles.com/Informatique/Livre/9780131865051/livre-user-mode-linux.php officiel]: écrit par l'auteur, ce livre est sous licence 'Open Publication' et n'en utilise visiblement aucune des options non-libres. C'est donc un livre libre que l'on peut recommander d'acheter :) La page de présentation indique que les livres de la série "Bruce Perens' Open Source" sont tous sous cette licence et sont publiés au format électronique au bout de 6 mois (il y a retard ici, et l'auteur, contacté via IRC, n'était vraisemblablement pas au courant du caractère libre de la publication - à suivre. Le contenu reste libre quoi qu'il en soit.). J'ai personnellement récupéré un exemplaire au format .chm mais je ne connais pas son origine - je l'ai acheté au format papier aussi. Le livre couvre le réseau, les applications, semble une bonne référence. Il risque cependant de devenir obsolète rapidement. J'ai demandé à l'auteur s'il comptait mettre le livre en ligne par la suite, pour une mise à jour continue: il n'y a pas encore réfléchi.<br />
* [http://testape.com/webtty_sample.php WebTTY]: lancez une instance UML sur le serveur distant et tapez du Bash intéractivement dans un navigateur web :)<br />
* [http://linuxfr.org/2006/08/20/21216.html ShaKe, un défragmenteur pour GNU/Linux] + liens<br />
* [[Émulation]] sur doc.cliss21.com<br />
* Réseau virtuel<br />
** [http://jungla.dit.upm.es/~vnuml/ VNUML]: Virtual Network User Mode Linux, simulation de réseaux complexes<br />
** [http://puzzle.dl.sourceforge.net/sourceforge/vnuml/vnuml-livecd-1.0.iso VIMINAL]: Live-CD alternatif pour VNUML ([http://sourceforge.net/project/showfiles.php?group_id=113582&package_id=203946 download])<br />
** [http://www.strongswan.org/uml/index.htm strongSwan - UML testing]: tests de non-regression de strongSwan avec un réseau virtuel d'UML.<br />
** [http://www.freeswan.org/freeswan_snaps/CURRENT-SNAP/doc/umltesting.html FreeS/WAN User-Mode-Linux Testing guide]: même chose chez FreeS/WAN (projet abandonné), donc plus ancien (noyau 2.4...). Qu'est-ce que uml_netjig??<br />
** [http://www.samag.com/documents/s=8997/sam0401a/0401a.htm Emulating Networks Using User-Mode Linux]: mise en place de IPSec sur une configuration (A<->Routeur)<->Hôte<->(Routeur<->B).<br />
* UML-Utilities: pour changer, le lien est [http://user-mode-linux.sourceforge.net/new/minis.html#utils perdu] au milieu du site. Lien direct: http://user-mode-linux.sourceforge.net/new/uml_utilities_20060622.tar.bz2<br />
<br />
== Dépannage ==<br />
<br />
Kernel panic - not syncing: start_userspace : expected SIGSTOP, got status = 256<br />
<br />
Cf. http://www.mail-archive.com/user-mode-linux-devel@lists.sourceforge.net/msg03414.html<br />
<br />
Votre noyau (hôte) est, si j'ai bien compris, mal configuré. Recompilez-le ou utilisez-en un autre.<br />
<br />
Vous pouvez également activer CONFIG_HOST_2G_2G dans la configuration du noyau UM.</div>82.238.35.175https://doc.cliss21.com/index.php?title=QEMU&diff=2063QEMU2007-02-04T20:02:51Z<p>82.238.35.175 : /* Liens */</p>
<hr />
<div>* http://fabrice.bellard.free.fr/qemu<br />
* [http://fabrice.bellard.free.fr/qemu/download.html Dernière version précompilée]<br />
aptitude install qemu<br />
<br />
=== Compiler et tester un exécutable de test ===<br />
<br />
Pour obtenir powerpc-linux-gcc: [[Compilation croisée]]<br />
<br />
$ cat <<EOF > hello.c<br />
#include <stdio.h><br />
<br />
int main(void) {<br />
return ! printf("Hello world!\n");<br />
}<br />
EOF<br />
$ powerpc-linux-gcc hello.c -Wall -ansi -pedantic -static<br />
$ qemu-ppc a.out<br />
Hello world!<br />
<br />
Mais:<br />
$ powerpc-linux-gcc hello.c -Wall -ansi -pedantic<br />
$ qemu-ppc ./a.out<br />
/lib/ld.so.1: No such file or directory<br />
Erreur de segmentation<br />
ToDo: trouver une façon de travailler pour gérer les dépendances (chroot recompilé)?<br />
Piste: l'archive [http://fabrice.bellard.free.fr/qemu/download.html gnemul] avec quelques bib systèmes.<br />
<br />
=== Des images de systèmes à télécharger ===<br />
<br />
Sur http://free.oszoo.org/download.html<br />
<br />
Essayer notamment:<br />
btdownloadcurses http://free.oszoo.org/ftp/images/linux-ppc-20040716.tar.bz2.torrent #20M<br />
btdownloadcurses http://free.oszoo.org/ftp/images/debian_sarge_ppc.tar.torrent #1Go!<br />
<br />
Avec l'image de base, en tant que root pour avoir le réseau via <code>/dev/net/tun</code>:<br />
qemu-system-ppc -prep -localtime -kernel zImage.prep linux-ppc.img<br />
<br />
À l'intérieur, vous pouvez [http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC25]:<br />
ifconfig eth0 172.20.0.2 # qemu<br />
scp me@172.20.0.1:fichier # système hôte<br />
<br />
L'image de 1Go est un système Debian sarge PPC pré-installé complet:<br />
qemu-system-ppc -prep -kernel vmlinuz-2.4.27.001 -hda debian_sarge_ppc.img -user-net<br />
<br />
Dans celle-ci le réseau à l'air différent:<br />
* 10.0.2.2: hôte et... serveur DHCP!<br />
* 10.0.2.15: qemu<br />
<br />
* [http://www.overselfresearch.com/kb/qemu.html Installing from Scratch...]: HOWTO pour recréer l'image Debian Sarge<br />
<br />
=== Tester une installation ===<br />
<br />
wget http://cdimage.debian.org/debian-cd/3.1_r2/powerpc/iso-cd/debian-31r2-powerpc-netinst.iso<br />
qemu-img create debian_sarge_ppc.img 500M<br />
qemu-system-ppc -hda debian_sarge_ppc.img -cdrom debian-31r2-powerpc-netinst.iso -boot d<br />
<br />
D'après le HOWTO, le noyau 2.6 ne passe pas - utiliser <code>install-powerpc-2.4 ramdisk_size=10000</code> au boot.<br />
<br />
=== Démarrer sur son propre disque-dur ===<br />
<br />
qemu -snapshot -hda /dev/hda -hdb /dev/hdb<br />
<br />
=== Démarrer sur une image de partition ===<br />
<br />
(et non sur une image de disque complet)<br />
<br />
qemu -hda debian.img -kernel bzImage -append "root=/dev/hda" # ...<br />
<br />
=== VNC ===<br />
<br />
Exemple:<br />
qemu -vnc :0 -k fr os.img<br />
<br />
Pour y accéder:<br />
vncviewer localhost<br />
<br />
Très pratique pour passer une VM en tâche de fond.<br />
<br />
Problème: la souris VNC et la souris système de sont pas synchro :/<br />
<br />
* [http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC10 doc]<br />
<br />
=== Partage Samba avec l'hôte ===<br />
<br />
qemu -smb /path os.img<br />
<br />
ou plutôt, si vous êtes chez Debian:<br />
<br />
sudo qemu -smb /path os.img<br />
<br />
Purée, je vais encore râler contre les distros, mais QUEL BESOIN ONT CES FOUTUS PACKAGEURS de coder en dur <code>secrets.tdb</code> dans <code>/var/lib/</code> alors que c'est sensé être configurable (option <code>private dir</code>)? Cf. <code>debian/patch/fhs.patch</code>. Du coup il n'est plus possible de lancer smbd sans être root, faute de droits >(<br />
<br />
* [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=249873 bug chez Debian]: ça ne fait que 2-3 ans.<br />
<br />
<br />
Dans la VM, au choix:<br />
mount //10.0.2.4/qemu smb/<br />
mount -t cifs //10.0.2.4/qemu smb/<br />
smbclient //10.0.2.4/qemu<br />
<br />
* [http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC10 doc]<br />
<br />
=== Optimisation PC->PC ===<br />
<br />
[http://savannah.nongnu.org/projects/qvm86 qvm86] permettait d'avoir une émulation plus rapide mais le code n'a pas été touché depuis 2005-09-04 (qemu 0.7.2), et l'auteur encourage [http://savannah.nongnu.org/forum/forum.php?forum_id=4748] de passer à VirtualBox à la place. Il y a un [http://lists.gnu.org/archive/html/qvm86-devel/2006-02/msg00000.html patch] plus récent mais je n'arrive pas à savoir sur quelle version de qemu il fonctionne. Apparemment [http://lists.gnu.org/archive/html/qvm86-devel/2006-02/msg00002.html] le patch s'applique sur la v0.8.0 mais ne contient que les changements sur qvm86, pas les changements correspondants sur qvm86 (notamment, il manque une mise à jour de patch.qvm86).<br />
<br />
Remarque: l'équivalent propriétaire de qvm86 ne donne pas nécessairement de bons résultats de toute façon. Win98 fonctionne mieux sans, par exemple. Ce n'est donc pas indispensable. VirtualBox en revanche ne fonctionne apparement pas sans le module noyau - et ne fournit certaines fonctionnalités que dans sa [http://www.virtualbox.org/wiki/Editions version] propriétaire.<br />
<br />
Compilation:<br />
cvs -d:pserver:anonymous@cvs.sv.gnu.org:/sources/qemu co -D 2006-09-05 qemu<br />
cd qemu/<br />
cvs -d:pserver:anonymous@cvs.sv.gnu.org:/sources/qvm86 co qvm86<br />
cat qvm86/patch.qvm86 | patch -p0<br />
./configure --target-list=i386-softmmu --cc=gcc-3.3<br />
make<br />
# sudo make install<br />
# cf. i386-softmmu/qemu et qvm86/qvm86.ko<br />
<br />
Je ne sais pas trop comment tester l'efficacité du module. En tout cas c'est un excellent moyen de reproduire un BSOD W98 ;) (note: cet OS n'est pas sensé fonctionner avec un accélérateur de toute façon)<br />
<br />
=== Désinstallation de la version binaire ===<br />
<br />
tar tzf qemu-0.8.2-i386.tar.gz | (cd / && sudo xargs rm)<br />
<br />
=== QEMU-compatible kernel ===<br />
<br />
==== Configuration rapide ====<br />
<br />
make defconfig ARCH=i386<br />
make xconfig<br />
# Activer: NE2K_PCI=Y (ns2000 PCI network ethernet card)<br />
make<br />
file arch/i386/boot/bzImage<br />
<br />
Ce noyau est malheureusement trop volumineux pour tenir sur une disquette (2.5Mo) - ce qui est nécessaire pour suivre certains HOWTO les séquences d'amorçage ([http://users.rsise.anu.edu.au/~okeefe/p2b/power2bash/power2bash.html][http://www.tldp.org/HOWTO/Bootdisk-HOWTO/]).<br />
<br />
==== Configuration précise ====<br />
<br />
Analyse de la configuration,<br />
<br />
* Depuis une image qemu qui fonctionne:<br />
$ uname --machine<br />
i686<br />
$ cat /proc/cpuinfo<br />
[...]<br />
model name : Pentium II (Klamath)<br />
[...]<br />
# Remarque: il y a une variante x86_64, avec qemu-system-x86_64<br />
$ lspci<br />
0000:00:00.0 Host bridge: Intel Corp. 440FX - 82441FX PMC [Natoma] (rev 02)<br />
0000:00:01.0 ISA bridge: Intel Corp. 82371SB PIIX3 ISA [Natoma/Triton II]<br />
0000:00:01.1 IDE interface: Intel Corp. 82371SB PIIX3 IDE [Natoma/Triton II]<br />
0000:00:01.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI<br />
0000:00:02.0 VGA compatible controller: Cirrus Logic GD 5446<br />
0000:00:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)<br />
<br />
* Sur la console qemu (Ctrl+Alt+2):<br />
(qemu) info network<br />
VLAN 0 devices:<br />
user redirector<br />
ne2000 pci macaddr=...<br />
<br />
Configuration du noyau:<br />
<br />
# noyau minimal<br />
make allnoconfig<br />
<br />
Méthode<br />
=======<br />
<br />
Erreurs au chargement du noyau<br />
File -> Search dans qconf<br />
<br />
<br />
Essentiel<br />
=========<br />
<br />
Kernel support for ELF binaries (BINFMT_ELF)<br />
# Disque-dur<br />
# 0000:00:01.1 IDE interface: Intel Corp. 82371SB PIIX3 IDE [Natoma/Triton II]<br />
ATA/ATAPI/MFM/RLL support (IDE)<br />
Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support (BLK_DEV_IDE)<br />
Include IDE/ATA-2 DISK support (BLK_DEV_IDEDISK)<br />
#?PCI IDE chipset support (BLK_DEV_IDEPCI)<br />
#?Generic PCI bus-master DMA support (BLK_DEV_IDEDMA_PCI)<br />
#?Intel PIIXn chipsets support (BLK_DEV_PIIX)<br />
#?? DMA?<br />
Ext3 journalling file system support (EXT3_FS)<br />
<br />
<br />
La suite<br />
========<br />
<br />
# Précision du type de processeur<br />
Pentium-II/Celeron(pre-Coppermine) (MPENTIUMII)<br />
<br />
# Systèmes de fichiers<br />
Second extended fs support (EXT2_FS)<br />
# /dev/shm<br />
Virtual memory file system support (former shm fs) (TMPFS)<br />
# /dev/log<br />
Unix domain sockets (UNIX)<br />
<br />
?<br />
#Deadline I/O scheduler (IOSCHED_DEADLINE)<br />
#Deadline (DEFAULT_DEADLINE)<br />
<br />
# Floppy<br />
Normal floppy disk support (BLK_DEV_FD)<br />
<br />
# Lecteur CD-ROM<br />
Include IDE/ATAPI CDROM support (BLK_DEV_IDECD)<br />
# ^ À tester! ^<br />
ISO 9660 CDROM file system support (ISO9660_FS)<br />
Microsoft Joliet CDROM extensions (JOLIET)<br />
<br />
# Network<br />
# 0000:00:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)<br />
PCI support (PCI)<br />
<br />
Networking support (NET)<br />
TCP/IP networking (INET)<br />
Packet socket (PACKET)<br />
<br />
Network device support (NETDEVICES)<br />
Ethernet (10 or 100Mbit) (NET_ETHERNET)<br />
EISA, VLB, PCI and on board controllers (NET_PCI)<br />
PCI NE2000 and clones support (see help) (NE2K_PCI)<br />
# TODO: "Qemu can emulate several different models of network card. Valid values for type are ne2k_pci, ne2k_isa, rtl8139, smc91c111 and lance. Not all devices are supported on all targets." [http://qemu.org/qemu-doc.html#SEC10]<br />
<br />
<br />
Misc<br />
====<br />
<br />
Kernel .config support (IKCONFIG)<br />
Enable access to .config through /proc/config.gz (IKCONFIG_PROC)<br />
CIFS support (advanced network filesystem for Samba, Window and other CIFS compliant servers) (CIFS)<br />
<br />
<br />
Virtual FAT disk images<br />
=======================<br />
# ex: qemu debian.img -hdb fat:/tmp<br />
<br />
VFAT (Windows-95) fs support (VFAT_FS)<br />
Codepage 437 (United States, Canada) (NLS_CODEPAGE_437)<br />
NLS ISO 8859-1 (Latin 1; Western European Languages) (NLS_ISO8859_1)<br />
# Pas nécessaire pour fat:, mais indispensable pour monter de vraies<br />
# partitions FAT françaises<br />
# Codepage 850 (Europe) (NLS_CODEPAGE_850)<br />
<br />
<br />
Carte graphique<br />
===============<br />
<br />
0000:00:02.0 VGA compatible controller: Cirrus Logic GD 5446<br />
<br />
<br />
Supprimé pour l'instant<br />
=======================<br />
<br />
ACPI Support (ACPI)<br />
<br />
The IPv6 protocol (IPV6)<br />
<br />
?generic/default IDE chipset support (IDE_GENERIC)<br />
<br />
<br />
Autre matériel<br />
==============<br />
<br />
0000:00:01.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI<br />
?<br />
<br />
0000:00:00.0 Host bridge: Intel Corp. 440FX - 82441FX PMC [Natoma] (rev 02)<br />
?<br />
<br />
0000:00:01.0 ISA bridge: Intel Corp. 82371SB PIIX3 ISA [Natoma/Triton II]<br />
?<br />
<br />
== Liens ==<br />
<br />
* [http://fabrice.bellard.free.fr/qemu/qemu-doc.html Documentation officielle]<br />
* [http://esaracco.free.fr/documentations/qemu/qemu/ Guide simplifié pour QEMU]<br />
* [http://www.kidsquid.com/cgi-bin/moin.cgi/FrontPage Unofficial #qemu Wiki]<br />
* [http://qemu-forum.ipi.fi/ The QEMU forum]<br />
* [http://www.gnome.org/~markmc/qemu-networking.html QEMU Networking]: panorama des différentes solutions de connexion réseau</div>82.238.35.175https://doc.cliss21.com/index.php?title=SPAM&diff=121SPAM2006-12-15T23:13:04Z<p>82.238.35.175 : spf</p>
<hr />
<div>==Principes et problèmes du SPAM==<br />
<br />
Le mail circule via Internet via le protocole protocole SMTP et en se basant sur IP et DNS.<br />
<br />
Le problème: il n'y a aucune identification, et envoyer du courriel est 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.<br />
<br />
Depuis plusieurs années, à mesure que ce phénomène gagne en puissance, diverses solutions ont été mises en oeuvre. Pour résumer, aucune ne fonctionne vraiment bien, et aucune n'est réellement sans douleur.<br />
<br />
On cherchera, au passage, des solutions qui permettront de filtrer à coup 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").<br />
<br />
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.<br />
<br />
==Principes de combat==<br />
<br />
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.<br />
<br />
Dans ces conditions deux solutions sont envisageables:<br />
* accepter la fatalité de l'existence du problème, et ne lutter qu'à un niveau minimum<br />
* ê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)<br />
<br />
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".<br />
<br />
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.<br />
<br />
==Les bases==<br />
<br />
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.<br />
<br />
[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.<br />
<br />
<br />
==Listes noires==<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* Le listage d'adresses IP est souvent erroné et long à rectifier.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==RFC-compliance==<br />
<br />
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.<br />
<br />
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é)<br />
<br />
<br />
==Authentification==<br />
<br />
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).<br />
<br />
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.<br />
<br />
===SPF===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Cette organisation élèverait également la barrière d'entrée pour les entreprises nouvelles sur Internet.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
À remarquer également, le principe de certification proposé nécessite une forme ou l'autre d'authentification, qui pourra sans doute facilement être contournée par les spammeurs. Comment distinguer une jeune entreprise d'un pays exotique voulant lancer un service mail, d'un spammeur?<br />
<br />
<br />
==Graylisting==<br />
<br />
(littéralement: liste grise)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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 <br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
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. <br />
<br />
<br />
==Filtres Bayesien naïfs==<br />
<br />
=== Articles explicatifs ===<br />
<br />
La série d'articles enthousiastes 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:<br />
* http://paulgraham.com/spam.html<br />
* http://paulgraham.com/spamfaq.html<br />
* http://paulgraham.com/better.html<br />
* http://paulgraham.com/wfks.html : Will filters kill spam? Questions/réponses sur les limites de l'approche.<br />
* http://paulgraham.com/falsepositives.html<br />
<br />
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.<br />
<br />
=== Expérience personnelle (incomplète) ===<br />
<br />
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).<br />
<br />
Cette année, je réessaie plus assiduement: La solution offerte par Mozilla Thunderbird fonctionne relativement bien. Je l'essaie depuis quelques semaine, sur une adresse modéremment spammée (disons une petite dizaine par jour) avec un traffic d'environ 15-20 messages par jour. Cela fait bien une semaine que je n'ai eu aucune erreur.<br />
<br />
=== Limites du modèle mathématique ===<br />
<br />
Il est dit que le modèle présenté par PG est loin d'être proprement ''bayesien''. Des améliorations un peu plus "carrées" ont été proposées:<br />
* http://radio.weblogs.com/0101454/stories/2002/09/16/spamDetection.html<br />
<br />
Noter notamment que dans tous ces tests où des résultats 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é, et scores autours de 0).<br />
<br />
=== Ciblage ===<br />
<br />
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.<br />
<br />
=== Apprentissage ===<br />
<br />
Autre problème: corriger les erreurs.<br />
* D'une part il faut vérifier de temps à autre les messages du dossier spam et y récupérer les faux positifs<br />
* D'autre part il faut déterminer une stratégie d'apprentissage:<br />
<br />
Une fois encore, lancer SpamAssassin::Bayes en mode bayes_auto_learn sans aucun processus de correction risque de mal fonctionner.<br />
<br />
http://www.garyrobinson.net/2004/02/spam_filtering_.html: ''Training to exhaustion'', présente dans l'article "apprendre en cas d'erreur" et "apprendre jusqu'à épuisement".<br />
<br />
http://www.bgl.nu/bogofilter/scale.html: Utiliser une même liste de mots pour tous les utilisateurs d'un site (et non une liste par utilisateur) peut peut-être rendre le filtrage moins efficace, mais ce n'est pas obligatoire. L'article pose également un autre problème: si les utilisateurs ne classent pas leur messages en spam/ham, le filtrage risque également de perdre en efficacité.<br />
<br />
=== Invalidité du modèle ===<br />
<br />
Même en admettant une mise en oeuvre parfaite, il est possible aux spammers de s'adapter en utilisant massivement un langage neutre, ce qui confond la limite entre spam et message légitime neutre, faisant globalement baisser la précision des filtres bayésiens:<br />
<br />
* http://jerf.org/iri/2002/11/19.html<br />
* http://homepages.tesco.net./~J.deBoynePollard/FGA/smtp-anti-ubm-dont-work.html#Bayesian<br />
<br />
==Hashcash==<br />
<br />
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 :)).<br />
<br />
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.<br />
<br />
Les listes de diffusion, ou plus généralement les utilisations légitimes de l'envoi de courrier en masse, posent évidemment problème.<br />
<br />
http://www.hashcash.org/faq/index.fr.php<br />
<br />
==Tarpit==<br />
<br />
Ralentir le serveur dans certaines conditions (ex: harvest attack).<br />
<br />
* http://www.postfix.org/rate.html<br />
<br />
Notez que cela ne fonctionne probablement pas dans le cas du relai SMTP d'un ISP (eg. smtp.aol.com) qui envoie continuellement du courriel partout).<br />
<br />
==Liens==<br />
<br />
* [http://homepages.tesco.net./~J.deBoynePollard/FGA/smtp-spf-is-harmful.html SPF is harmful. Adopt it.]: a series of interesting statements and links that criticizes all the current anti-spam measure and propose IM2000 as a solution. IM2000 est analysé sur cette autre page [http://psg.com/~brian/doc/misc/im2000.html].<br />
<br />
* [http://www.cs.ucr.edu/~schhabra/thesis.html Thèse de Shalendra Chhabra]<br />
<br />
Des black lists:<br />
* http://www.spamhaus.org/<br />
* Soumission des spams par les utilisateurs:<br />
** http://www.spamcop.net/<br />
** http://www.spam-rbl.com/<br />
<br />
Des sites à éventuellement regarder:<br />
* http://www.cauce.org/ : site d'information<br />
* http://www.weird.com/~woods/ : <br />
<br />
Masquage minimal de son adresse e-mail:<br />
perl -e '$a = "your\@email.tld"; $a =~ s/(.)/"&#".ord($1).";"/eg; print "$a\n";'</div>82.238.35.175https://doc.cliss21.com/index.php?title=PHP&diff=1951PHP2006-12-09T16:47:43Z<p>82.238.35.175 : /* Simplification de l'accès à la base */</p>
<hr />
<div>Dernières versions de la documentation officielle de PHP, avant qu'elle ne devienne non-libre:<br />
* [http://packages.debian.org/stable/doc/php3-doc Documentation for PHP3]<br />
* [http://packages.debian.org/oldstable/doc/phpdoc Documentation for PHP4 and PHP3] (snapshot 2002)<br />
<br />
== Dernière version libre de la documentation PHP ==<br />
<br />
Précisons que l'Open Publication License (OPL) est une licence libre uniquement si aucune option n'est utilisée (notamment, l'interdiction des travaux dérivés sans consentement des détenteurs des droits).<br />
<br />
La dernière version date de 2003.<br />
<br />
Avec <code>cvs2cl --utc</code>, j'obtiens le ChangeLog suivant:<br />
2003-05-02 14:12 goba<br />
<br />
* en/bookinfo.xml: And now: upgrading to the new license<br />
<br />
La dernière version libre est donc:<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository login # pass: phpfi<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository checkout -D "2003-05-02 14:12:58Z" phpdocs<br />
<br />
----<br />
<br />
[[Débogage PHP]]<br />
<br />
----<br />
<br />
== Tests unitaires avec PHP ==<br />
<br />
* [http://www.simpletest.org/ SimpleTest]<br />
* [http://phpunit.de/ PHPUnit]<br />
* [http://weierophinney.net/matthew/archives/65-phpt-Tutorial.html phpt] (tutorial, apparement l'outil est intégré à pear?) - apparemment plus simple/rapide<br />
<br />
Voir également WWW::Mechanize (''Mech'') pour tester le programme de manière externe par son interface web (en Perl). Pour une solution en PHP, voir éventuellement la bibliothèque curl, qui ne sait cependant pas analyser le HTML reçu.<br />
<br />
== Abstraction de la base de données ==<br />
<br />
* [http://pear.php.net/package/MDB2 MDB2]: successeur de PEAR::DB, licence mBSD<br />
* [http://creole.phpdb.org/ Creole]: PHP5 seulement; licence LGPL<br />
* [http://adodb.sourceforge.net/ AdoDB]: utilisé par TikiWiki, Xaraya, eGroupWare; license mBSD<br />
<br />
== Simplification de l'accès à la base ==<br />
<br />
Dépend d'une des abstraction ci-dessus. Mots-clefs à chercher: ORM ([http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping])<br />
* [http://pear.php.net/package/DB_Table DB_Table]: non-object, intégration avec QuickForm et validation des update/insert, description via une classe et des tableaux ($cols, $idx, $sql...); utilise PEAR::DB (licence PHP); LGPL<br />
* [http://propel.phpdb.org/ Propel]: description en XML (lourd?), relations inter-classes, relations N-M possibles mais pas encore propres; possibilité d'utiliser directement SQL si besoin; validation décrite en XML (lourd); utilise Creole<br />
* [http://www.appelsiini.net/~tuupola/php/DB_DataContainer/ DB_DataContainer]: mapping objet simpliste, pas de relation inter-tables; description via la classe PHP; nécessite un champ 'id'.<br />
* [http://pear.php.net/package/DB_DataObject DB_DataObject]: fichier de description .ini; liens entre classes; à essayer; licence PHP<br />
* [http://www.ezpdo.net EZPDO]: description inclue dans des tags @orm style javadoc; validation via des 'Events'/hooks, aucune validation par défaut ''a priori''; mBSD<br />
* [http://cakephp.org/ CakePHP]: framework style Ruby on Rails, inclut un ORM; la [http://manual.cakephp.org/chapter/validation validation], à base de regexp, fait partie du framework et en est vraisemblablement indissociable.<br />
* [http://www.phpdoctrine.com/ Doctrine]: ça a l'air très propre<br />
* [http://www.meta-language.net/metastorage.html MetaL Metastrorage]: beaucoup de XML<br />
* [http://phplens.com/lens/adodb/docs-active-record.htm ADOdb Active Record]: un ORM qui fait partie d'ADOdb, à voir<br />
* d'autres listés sur [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#PHP Wikipedia].</div>82.238.35.175https://doc.cliss21.com/index.php?title=PHP&diff=1950PHP2006-12-09T16:36:57Z<p>82.238.35.175 : /* Simplification de l'accès à la base */</p>
<hr />
<div>Dernières versions de la documentation officielle de PHP, avant qu'elle ne devienne non-libre:<br />
* [http://packages.debian.org/stable/doc/php3-doc Documentation for PHP3]<br />
* [http://packages.debian.org/oldstable/doc/phpdoc Documentation for PHP4 and PHP3] (snapshot 2002)<br />
<br />
== Dernière version libre de la documentation PHP ==<br />
<br />
Précisons que l'Open Publication License (OPL) est une licence libre uniquement si aucune option n'est utilisée (notamment, l'interdiction des travaux dérivés sans consentement des détenteurs des droits).<br />
<br />
La dernière version date de 2003.<br />
<br />
Avec <code>cvs2cl --utc</code>, j'obtiens le ChangeLog suivant:<br />
2003-05-02 14:12 goba<br />
<br />
* en/bookinfo.xml: And now: upgrading to the new license<br />
<br />
La dernière version libre est donc:<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository login # pass: phpfi<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository checkout -D "2003-05-02 14:12:58Z" phpdocs<br />
<br />
----<br />
<br />
[[Débogage PHP]]<br />
<br />
----<br />
<br />
== Tests unitaires avec PHP ==<br />
<br />
* [http://www.simpletest.org/ SimpleTest]<br />
* [http://phpunit.de/ PHPUnit]<br />
* [http://weierophinney.net/matthew/archives/65-phpt-Tutorial.html phpt] (tutorial, apparement l'outil est intégré à pear?) - apparemment plus simple/rapide<br />
<br />
Voir également WWW::Mechanize (''Mech'') pour tester le programme de manière externe par son interface web (en Perl). Pour une solution en PHP, voir éventuellement la bibliothèque curl, qui ne sait cependant pas analyser le HTML reçu.<br />
<br />
== Abstraction de la base de données ==<br />
<br />
* [http://pear.php.net/package/MDB2 MDB2]: successeur de PEAR::DB, licence mBSD<br />
* [http://creole.phpdb.org/ Creole]: PHP5 seulement; licence LGPL<br />
* [http://adodb.sourceforge.net/ AdoDB]: utilisé par TikiWiki, Xaraya, eGroupWare; license mBSD<br />
<br />
== Simplification de l'accès à la base ==<br />
<br />
Dépend d'une des abstraction ci-dessus. Mots-clefs à chercher: ORM ([http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping])<br />
* [http://pear.php.net/package/DB_Table DB_Table]: non-object, intégration avec QuickForm et validation des update/insert, description via une classe et des tableaux ($cols, $idx, $sql...); utilise PEAR::DB (licence PHP); LGPL<br />
* [http://propel.phpdb.org/ Propel]: description en XML (lourd?), relations inter-classes, relations N-M possibles mais pas encore propres; possibilité d'utiliser directement SQL si besoin; validation décrite en XML (lourd); utilise Creole<br />
* [http://www.appelsiini.net/~tuupola/php/DB_DataContainer/ DB_DataContainer]: mapping objet simpliste, pas de relation inter-tables; description via la classe PHP; nécessite un champ 'id'.<br />
* [http://pear.php.net/package/DB_DataObject DB_DataObject]: fichier de description .ini; liens entre classes; à essayer; licence PHP<br />
* [http://www.ezpdo.net EZPDO]: description inclue dans des tags @orm style javadoc; validation via des 'Events'/hooks, aucune validation par défaut ''a priori''; mBSD<br />
* [http://cakephp.org/ CakePHP]: framework style Ruby on Rails, inclut in ORM<br />
* [http://www.phpdoctrine.com/ Doctrine]: ça a l'air très propre<br />
* [http://www.meta-language.net/metastorage.html MetaL Metastrorage]: beaucoup de XML<br />
* [http://phplens.com/lens/adodb/docs-active-record.htm ADOdb Active Record]: un ORM qui fait partie d'ADOdb, à voir<br />
* d'autres listés sur [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#PHP Wikipedia].</div>82.238.35.175https://doc.cliss21.com/index.php?title=PHP&diff=1949PHP2006-12-09T16:35:27Z<p>82.238.35.175 : /* Simplification de l'accès à la base */</p>
<hr />
<div>Dernières versions de la documentation officielle de PHP, avant qu'elle ne devienne non-libre:<br />
* [http://packages.debian.org/stable/doc/php3-doc Documentation for PHP3]<br />
* [http://packages.debian.org/oldstable/doc/phpdoc Documentation for PHP4 and PHP3] (snapshot 2002)<br />
<br />
== Dernière version libre de la documentation PHP ==<br />
<br />
Précisons que l'Open Publication License (OPL) est une licence libre uniquement si aucune option n'est utilisée (notamment, l'interdiction des travaux dérivés sans consentement des détenteurs des droits).<br />
<br />
La dernière version date de 2003.<br />
<br />
Avec <code>cvs2cl --utc</code>, j'obtiens le ChangeLog suivant:<br />
2003-05-02 14:12 goba<br />
<br />
* en/bookinfo.xml: And now: upgrading to the new license<br />
<br />
La dernière version libre est donc:<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository login # pass: phpfi<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository checkout -D "2003-05-02 14:12:58Z" phpdocs<br />
<br />
----<br />
<br />
[[Débogage PHP]]<br />
<br />
----<br />
<br />
== Tests unitaires avec PHP ==<br />
<br />
* [http://www.simpletest.org/ SimpleTest]<br />
* [http://phpunit.de/ PHPUnit]<br />
* [http://weierophinney.net/matthew/archives/65-phpt-Tutorial.html phpt] (tutorial, apparement l'outil est intégré à pear?) - apparemment plus simple/rapide<br />
<br />
Voir également WWW::Mechanize (''Mech'') pour tester le programme de manière externe par son interface web (en Perl). Pour une solution en PHP, voir éventuellement la bibliothèque curl, qui ne sait cependant pas analyser le HTML reçu.<br />
<br />
== Abstraction de la base de données ==<br />
<br />
* [http://pear.php.net/package/MDB2 MDB2]: successeur de PEAR::DB, licence mBSD<br />
* [http://creole.phpdb.org/ Creole]: PHP5 seulement; licence LGPL<br />
* [http://adodb.sourceforge.net/ AdoDB]: utilisé par TikiWiki, Xaraya, eGroupWare; license mBSD<br />
<br />
== Simplification de l'accès à la base ==<br />
<br />
Dépend d'une des abstraction ci-dessus. Mots-clefs à chercher: ORM ([http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping])<br />
* [http://pear.php.net/package/DB_Table DB_Table]: non-object, intégration avec QuickForm et validation des update/insert, description via une classe et des tableaux ($cols, $idx, $sql...); utilise PEAR::DB (licence PHP); LGPL<br />
* [http://propel.phpdb.org/ Propel]: description en XML (lourd?), relations inter-classes, relations N-M possibles mais pas encore propres; possibilité d'utiliser directement SQL si besoin; validation décrite en XML (lourd); utilise Creole<br />
* [http://www.appelsiini.net/~tuupola/php/DB_DataContainer/ DB_DataContainer]: mapping objet simpliste, pas de relation inter-tables; description via la classe PHP; nécessite un champ 'id'.<br />
* [http://pear.php.net/package/DB_DataObject DB_DataObject]: fichier de description .ini; liens entre classes; à essayer; licence PHP<br />
* [http://www.ezpdo.net EZPDO]: description inclue dans des tags @orm style javadoc; mBSD<br />
* [http://cakephp.org/ CakePHP]: framework style Ruby on Rails, inclut in ORM<br />
* [http://www.phpdoctrine.com/ Doctrine]: ça a l'air très propre<br />
* [http://www.meta-language.net/metastorage.html MetaL Metastrorage]: beaucoup de XML<br />
* [http://phplens.com/lens/adodb/docs-active-record.htm ADOdb Active Record]: un ORM qui fait partie d'ADOdb, à voir<br />
* d'autres listés sur [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#PHP Wikipedia].</div>82.238.35.175https://doc.cliss21.com/index.php?title=PHP&diff=1948PHP2006-12-09T13:17:20Z<p>82.238.35.175 : /* Simplification de l'accès à la base */</p>
<hr />
<div>Dernières versions de la documentation officielle de PHP, avant qu'elle ne devienne non-libre:<br />
* [http://packages.debian.org/stable/doc/php3-doc Documentation for PHP3]<br />
* [http://packages.debian.org/oldstable/doc/phpdoc Documentation for PHP4 and PHP3] (snapshot 2002)<br />
<br />
== Dernière version libre de la documentation PHP ==<br />
<br />
Précisons que l'Open Publication License (OPL) est une licence libre uniquement si aucune option n'est utilisée (notamment, l'interdiction des travaux dérivés sans consentement des détenteurs des droits).<br />
<br />
La dernière version date de 2003.<br />
<br />
Avec <code>cvs2cl --utc</code>, j'obtiens le ChangeLog suivant:<br />
2003-05-02 14:12 goba<br />
<br />
* en/bookinfo.xml: And now: upgrading to the new license<br />
<br />
La dernière version libre est donc:<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository login # pass: phpfi<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository checkout -D "2003-05-02 14:12:58Z" phpdocs<br />
<br />
----<br />
<br />
[[Débogage PHP]]<br />
<br />
----<br />
<br />
== Tests unitaires avec PHP ==<br />
<br />
* [http://www.simpletest.org/ SimpleTest]<br />
* [http://phpunit.de/ PHPUnit]<br />
* [http://weierophinney.net/matthew/archives/65-phpt-Tutorial.html phpt] (tutorial, apparement l'outil est intégré à pear?) - apparemment plus simple/rapide<br />
<br />
Voir également WWW::Mechanize (''Mech'') pour tester le programme de manière externe par son interface web (en Perl). Pour une solution en PHP, voir éventuellement la bibliothèque curl, qui ne sait cependant pas analyser le HTML reçu.<br />
<br />
== Abstraction de la base de données ==<br />
<br />
* [http://pear.php.net/package/MDB2 MDB2]: successeur de PEAR::DB, licence mBSD<br />
* [http://creole.phpdb.org/ Creole]: PHP5 seulement; licence LGPL<br />
* [http://adodb.sourceforge.net/ AdoDB]: utilisé par TikiWiki, Xaraya, eGroupWare; license mBSD<br />
<br />
== Simplification de l'accès à la base ==<br />
<br />
Dépend d'une des abstraction ci-dessus. Mots-clefs à chercher: ORM ([http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping])<br />
* [http://pear.php.net/package/DB_Table DB_Table]: non-object, intégration avec QuickForm et validation des update/insert, description via une classe et des tableaux ($cols, $idx, $sql...); utilise PEAR::DB (licence PHP); LGPL<br />
* [http://propel.phpdb.org/ Propel]: description en XML (lourd?), relations inter-classes, relations N-M possibles mais pas encore propres; possibilité d'utiliser directement SQL si besoin; validation décrite en XML (lourd); utilise Creole<br />
* [http://www.appelsiini.net/~tuupola/php/DB_DataContainer/ DB_DataContainer]: mapping objet simpliste, pas de relation inter-tables; description via la classe PHP; nécessite un champ 'id'.<br />
* [http://pear.php.net/package/DB_DataObject DB_DataObject]: fichier de description .ini; liens entre classes; à essayer; licence PHP<br />
* d'autres listés sur [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#PHP Wikipedia].</div>82.238.35.175https://doc.cliss21.com/index.php?title=PHP&diff=1947PHP2006-12-09T13:14:46Z<p>82.238.35.175 : /* Simplification de l'accès à la base */</p>
<hr />
<div>Dernières versions de la documentation officielle de PHP, avant qu'elle ne devienne non-libre:<br />
* [http://packages.debian.org/stable/doc/php3-doc Documentation for PHP3]<br />
* [http://packages.debian.org/oldstable/doc/phpdoc Documentation for PHP4 and PHP3] (snapshot 2002)<br />
<br />
== Dernière version libre de la documentation PHP ==<br />
<br />
Précisons que l'Open Publication License (OPL) est une licence libre uniquement si aucune option n'est utilisée (notamment, l'interdiction des travaux dérivés sans consentement des détenteurs des droits).<br />
<br />
La dernière version date de 2003.<br />
<br />
Avec <code>cvs2cl --utc</code>, j'obtiens le ChangeLog suivant:<br />
2003-05-02 14:12 goba<br />
<br />
* en/bookinfo.xml: And now: upgrading to the new license<br />
<br />
La dernière version libre est donc:<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository login # pass: phpfi<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository checkout -D "2003-05-02 14:12:58Z" phpdocs<br />
<br />
----<br />
<br />
[[Débogage PHP]]<br />
<br />
----<br />
<br />
== Tests unitaires avec PHP ==<br />
<br />
* [http://www.simpletest.org/ SimpleTest]<br />
* [http://phpunit.de/ PHPUnit]<br />
* [http://weierophinney.net/matthew/archives/65-phpt-Tutorial.html phpt] (tutorial, apparement l'outil est intégré à pear?) - apparemment plus simple/rapide<br />
<br />
Voir également WWW::Mechanize (''Mech'') pour tester le programme de manière externe par son interface web (en Perl). Pour une solution en PHP, voir éventuellement la bibliothèque curl, qui ne sait cependant pas analyser le HTML reçu.<br />
<br />
== Abstraction de la base de données ==<br />
<br />
* [http://pear.php.net/package/MDB2 MDB2]: successeur de PEAR::DB, licence mBSD<br />
* [http://creole.phpdb.org/ Creole]: PHP5 seulement; licence LGPL<br />
* [http://adodb.sourceforge.net/ AdoDB]: utilisé par TikiWiki, Xaraya, eGroupWare; license mBSD<br />
<br />
== Simplification de l'accès à la base ==<br />
<br />
Dépend d'une des abstraction ci-dessus:<br />
* [http://pear.php.net/package/DB_Table DB_Table]: non-object, intégration avec QuickForm et validation des update/insert, description via une classe et des tableaux ($cols, $idx, $sql...); utilise PEAR::DB (licence PHP); LGPL<br />
* [http://propel.phpdb.org/ Propel]: description en XML (lourd?), relations inter-classes, relations N-M possibles mais pas encore propres; possibilité d'utiliser directement SQL si besoin; validation décrite en XML (lourd); utilise Creole<br />
* [http://www.appelsiini.net/~tuupola/php/DB_DataContainer/ DB_DataContainer]: mapping objet simpliste, pas de relation inter-tables; description via la classe PHP; nécessite un champ 'id'.<br />
* [http://pear.php.net/package/DB_DataObject DB_DataObject]: fichier de description .ini; liens entre classes; à essayer; licence PHP</div>82.238.35.175https://doc.cliss21.com/index.php?title=PHP&diff=1946PHP2006-12-09T13:10:01Z<p>82.238.35.175 : /* Simplification de l'accès à la base */</p>
<hr />
<div>Dernières versions de la documentation officielle de PHP, avant qu'elle ne devienne non-libre:<br />
* [http://packages.debian.org/stable/doc/php3-doc Documentation for PHP3]<br />
* [http://packages.debian.org/oldstable/doc/phpdoc Documentation for PHP4 and PHP3] (snapshot 2002)<br />
<br />
== Dernière version libre de la documentation PHP ==<br />
<br />
Précisons que l'Open Publication License (OPL) est une licence libre uniquement si aucune option n'est utilisée (notamment, l'interdiction des travaux dérivés sans consentement des détenteurs des droits).<br />
<br />
La dernière version date de 2003.<br />
<br />
Avec <code>cvs2cl --utc</code>, j'obtiens le ChangeLog suivant:<br />
2003-05-02 14:12 goba<br />
<br />
* en/bookinfo.xml: And now: upgrading to the new license<br />
<br />
La dernière version libre est donc:<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository login # pass: phpfi<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository checkout -D "2003-05-02 14:12:58Z" phpdocs<br />
<br />
----<br />
<br />
[[Débogage PHP]]<br />
<br />
----<br />
<br />
== Tests unitaires avec PHP ==<br />
<br />
* [http://www.simpletest.org/ SimpleTest]<br />
* [http://phpunit.de/ PHPUnit]<br />
* [http://weierophinney.net/matthew/archives/65-phpt-Tutorial.html phpt] (tutorial, apparement l'outil est intégré à pear?) - apparemment plus simple/rapide<br />
<br />
Voir également WWW::Mechanize (''Mech'') pour tester le programme de manière externe par son interface web (en Perl). Pour une solution en PHP, voir éventuellement la bibliothèque curl, qui ne sait cependant pas analyser le HTML reçu.<br />
<br />
== Abstraction de la base de données ==<br />
<br />
* [http://pear.php.net/package/MDB2 MDB2]: successeur de PEAR::DB, licence mBSD<br />
* [http://creole.phpdb.org/ Creole]: PHP5 seulement; licence LGPL<br />
* [http://adodb.sourceforge.net/ AdoDB]: utilisé par TikiWiki, Xaraya, eGroupWare; license mBSD<br />
<br />
== Simplification de l'accès à la base ==<br />
<br />
Dépend d'une des abstraction ci-dessus:<br />
* [http://pear.php.net/package/DB_Table DB_Table]: non-object, intégration avec QuickForm et validation des update/insert, description via une classe et des tableaux ($cols, $idx, $sql...); utilise PEAR::DB (licence PHP); LGPL<br />
* [http://propel.phpdb.org/ Propel]: description en XML, relations inter-classes, relations N-M possibles mais pas encore propres; possibilité d'utiliser directement SQL si besoin; utilise Creole<br />
* [http://www.appelsiini.net/~tuupola/php/DB_DataContainer/ DB_DataContainer]: mapping objet simpliste, pas de relation inter-tables; description via la classe PHP; nécessite un champ 'id'.<br />
* [http://pear.php.net/package/DB_DataObject DB_DataObject]: fichier de description .ini; liens entre classes; à essayer; licence PHP</div>82.238.35.175https://doc.cliss21.com/index.php?title=PHP&diff=1945PHP2006-12-09T13:08:47Z<p>82.238.35.175 : /* Tests unitaires avec PHP */</p>
<hr />
<div>Dernières versions de la documentation officielle de PHP, avant qu'elle ne devienne non-libre:<br />
* [http://packages.debian.org/stable/doc/php3-doc Documentation for PHP3]<br />
* [http://packages.debian.org/oldstable/doc/phpdoc Documentation for PHP4 and PHP3] (snapshot 2002)<br />
<br />
== Dernière version libre de la documentation PHP ==<br />
<br />
Précisons que l'Open Publication License (OPL) est une licence libre uniquement si aucune option n'est utilisée (notamment, l'interdiction des travaux dérivés sans consentement des détenteurs des droits).<br />
<br />
La dernière version date de 2003.<br />
<br />
Avec <code>cvs2cl --utc</code>, j'obtiens le ChangeLog suivant:<br />
2003-05-02 14:12 goba<br />
<br />
* en/bookinfo.xml: And now: upgrading to the new license<br />
<br />
La dernière version libre est donc:<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository login # pass: phpfi<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository checkout -D "2003-05-02 14:12:58Z" phpdocs<br />
<br />
----<br />
<br />
[[Débogage PHP]]<br />
<br />
----<br />
<br />
== Tests unitaires avec PHP ==<br />
<br />
* [http://www.simpletest.org/ SimpleTest]<br />
* [http://phpunit.de/ PHPUnit]<br />
* [http://weierophinney.net/matthew/archives/65-phpt-Tutorial.html phpt] (tutorial, apparement l'outil est intégré à pear?) - apparemment plus simple/rapide<br />
<br />
Voir également WWW::Mechanize (''Mech'') pour tester le programme de manière externe par son interface web (en Perl). Pour une solution en PHP, voir éventuellement la bibliothèque curl, qui ne sait cependant pas analyser le HTML reçu.<br />
<br />
== Abstraction de la base de données ==<br />
<br />
* [http://pear.php.net/package/MDB2 MDB2]: successeur de PEAR::DB, licence mBSD<br />
* [http://creole.phpdb.org/ Creole]: PHP5 seulement; licence LGPL<br />
* [http://adodb.sourceforge.net/ AdoDB]: utilisé par TikiWiki, Xaraya, eGroupWare; license mBSD<br />
<br />
== Simplification de l'accès à la base ==<br />
<br />
Dépend d'une des abstraction ci-dessus:<br />
* [http://pear.php.net/package/DB_Table DB_Table]: non-object, intégration avec QuickForm et validation des update/insert, description via une classe et des tableaux ($cols, $idx, $sql...); utilise PEAR::DB<br />
* [http://propel.phpdb.org/ Propel]: description en XML, relations inter-classes, relations N-M possibles mais pas encore propres; possibilité d'utiliser directement SQL si besoin; utilise Creole<br />
* [http://www.appelsiini.net/~tuupola/php/DB_DataContainer/ DB_DataContainer]: mapping objet simpliste, pas de relation inter-tables; description via la classe PHP; nécessite un champ 'id'.<br />
* [http://pear.php.net/package/DB_DataObject DB_DataObject]: fichier de description .ini; liens entre classes; à essayer; licence PHP</div>82.238.35.175https://doc.cliss21.com/index.php?title=PHP&diff=1944PHP2006-12-09T13:07:38Z<p>82.238.35.175 : Frameworks bases de données</p>
<hr />
<div>Dernières versions de la documentation officielle de PHP, avant qu'elle ne devienne non-libre:<br />
* [http://packages.debian.org/stable/doc/php3-doc Documentation for PHP3]<br />
* [http://packages.debian.org/oldstable/doc/phpdoc Documentation for PHP4 and PHP3] (snapshot 2002)<br />
<br />
== Dernière version libre de la documentation PHP ==<br />
<br />
Précisons que l'Open Publication License (OPL) est une licence libre uniquement si aucune option n'est utilisée (notamment, l'interdiction des travaux dérivés sans consentement des détenteurs des droits).<br />
<br />
La dernière version date de 2003.<br />
<br />
Avec <code>cvs2cl --utc</code>, j'obtiens le ChangeLog suivant:<br />
2003-05-02 14:12 goba<br />
<br />
* en/bookinfo.xml: And now: upgrading to the new license<br />
<br />
La dernière version libre est donc:<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository login # pass: phpfi<br />
cvs -d :pserver:cvsread@cvs.php.net:/repository checkout -D "2003-05-02 14:12:58Z" phpdocs<br />
<br />
----<br />
<br />
[[Débogage PHP]]<br />
<br />
----<br />
<br />
== Tests unitaires avec PHP ==<br />
<br />
* [http://www.simpletest.org/ SimpleTest]<br />
* [http://phpunit.de/ PHPUnit]<br />
* [http://weierophinney.net/matthew/archives/65-phpt-Tutorial.html phpt] (tutorial, apparement l'outil est intégré à pear?) - apparemment plus simple/rapide<br />
<br />
Voir également WWW::Mechanize (''Mech'') pour tester le programme de manière externe par son interface web (en Perl).<br />
<br />
== Abstraction de la base de données ==<br />
<br />
* [http://pear.php.net/package/MDB2 MDB2]: successeur de PEAR::DB, licence mBSD<br />
* [http://creole.phpdb.org/ Creole]: PHP5 seulement; licence LGPL<br />
* [http://adodb.sourceforge.net/ AdoDB]: utilisé par TikiWiki, Xaraya, eGroupWare; license mBSD<br />
<br />
== Simplification de l'accès à la base ==<br />
<br />
Dépend d'une des abstraction ci-dessus:<br />
* [http://pear.php.net/package/DB_Table DB_Table]: non-object, intégration avec QuickForm et validation des update/insert, description via une classe et des tableaux ($cols, $idx, $sql...); utilise PEAR::DB<br />
* [http://propel.phpdb.org/ Propel]: description en XML, relations inter-classes, relations N-M possibles mais pas encore propres; possibilité d'utiliser directement SQL si besoin; utilise Creole<br />
* [http://www.appelsiini.net/~tuupola/php/DB_DataContainer/ DB_DataContainer]: mapping objet simpliste, pas de relation inter-tables; description via la classe PHP; nécessite un champ 'id'.<br />
* [http://pear.php.net/package/DB_DataObject DB_DataObject]: fichier de description .ini; liens entre classes; à essayer; licence PHP</div>82.238.35.175https://doc.cliss21.com/index.php?title=Backports&diff=1496Backports2006-10-28T21:52:38Z<p>82.238.35.175 : /* Workflow */</p>
<hr />
<div>== Definition ==<br />
<br />
A backport is a Debian package that is recompiled for an earlier version of the distribution. For example, there is a backport from the latest version of KDE [http://debian-unofficial.org/backports.html] that was compiled for ''Sarge'', based on packages originally meant for ''Etch''.<br />
<br />
Un ''backport'', c'est un paquet Debian recompilé pour une version précédente de la distribution. Par exemple, il y a un backport de la dernière version de KDE [http://debian-unofficial.org/backports.html] compilé pour ''Sarge'', à partir des paquets initialement prévue pour ''Etch''.<br />
<br />
== Motivations ==<br />
<br />
This recompilation is necessary for several reasons:<br />
* The packages dependencies change so as to take the evolution of the rest of the system into account; in our case, we'll change those dependencies to use earlier versions.<br />
* Binary compatibility issues (French: [[Compatibilité binaire]])<br />
<br />
== Où trouver des backports ==<br />
<br />
[http://backports.org backports.org] est la référence en la matière.<br />
<br />
Il y a également des dépôts de paquets plus spécialisés, mais ceux-ci ne sont pas toujours très attentifs aux licences, et vous pouvez récupérer des composants non-libres :/<br />
<br />
[http://apt-get.org/ apt-get.org] fournit une liste de ces dépôts, à la fois ceux qui contiennent des composants non inclus dans Debian pour diverses raisons, et ceux qui fournissent des backports proprement dit.<br />
<br />
== Using backports.org ==<br />
<br />
Add the following line in your <code>/etc/apt/sources.list</code>:<br />
deb http://www.backports.org/debian sarge-backports main<br />
<br />
Then install backported packages using:<br />
aptitude -t sarge-backports install BackportedPackage<br />
<br />
(Before, you had to configure ''pinning'' (packages priorities), but this is<br />
[http://lists.backports.org/lurker/message/20060814.093117.ab4c6b26.en.html no longer necessary])<br />
<br />
* [http://backports.org/dokuwiki/doku.php?id=instructions Official instructions]<br />
<br />
Note: it is not recommended to install all backports at once. Instead you should select only the packages that you need. Unlike in full, consistent Debian distros, each backport is tested individually against the Debian stable version, so they might conflict with each others - but they still share common backported dependencies.<br />
<br />
== backports.org GPG key ==<br />
<br />
After <code>apt-get update</code>, I get:<br />
W: GPG error: http://localhost sarge-backports Release: Les signatures suivantes<br />
n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKE Y EA8E8B2116BA136C<br />
<br />
So I need to import that key from a keyserver:<br />
$ gpg --recv-keys EA8E8B2116BA136C<br />
gpg: le porte-clés `/root/.gnupg/secring.gpg` a été créé<br />
gpg: requête de la clé 16BA136C du serveur hkp subkeys.pgp.net<br />
gpg: /root/.gnupg/trustdb.gpg: base de confiance créée<br />
gpg: clé 16BA136C: clé publique « Backports.org Archive Key <ftp-master@backport s.org> » importée<br />
gpg: aucune clé de confiance ultime n'a été trouvée<br />
gpg: Quantité totale traitée: 1<br />
gpg: importée: 1<br />
<br />
and tell apt about it:<br />
$ gpg --export EA8E8B2116BA136C | apt-key add -<br />
OK<br />
<br />
== HOWTO backport? ==<br />
<br />
Some general considerations:<br />
<br />
=== Config ===<br />
<br />
* debootstrap<br />
* basic compilation tools: <code>aptitude install build-essential</code><br />
* sources.list:<br />
##<br />
# Stable and backports repositories<br />
##<br />
deb http://ftp.fr.debian.org/debian stable main<br />
deb http://security.debian.org/debian-security stable/updates main<br />
deb http://www.backports.org/debian/ sarge-backports main<br />
deb-src http://ftp.fr.debian.org/debian stable main<br />
deb-src http://security.debian.org/debian-security stable/updates main<br />
deb-src http://backports.org/debian sarge-backports main<br />
<br />
##<br />
# Testing and unstable repositories<br />
##<br />
<br />
# Binaries - uncomment if you need to test 'aptitude install'<br />
#deb http://ftp.fr.debian.org/debian testing main<br />
#deb http://ftp.fr.debian.org/debian unstable main<br />
<br />
# Sources - uncomment the one you're backporting from<br />
#deb-src http://ftp.fr.debian.org/debian testing main<br />
deb-src http://ftp.fr.debian.org/debian unstable main<br />
<br />
##<br />
# backports in progress<br />
##<br />
deb file:///usr/src/repo ./<br />
<br />
* /etc/apt/preferences:<br />
Package: *<br />
Pin: release a=testing<br />
Pin-Priority: -1<br />
<br />
Package: *<br />
Pin: release a=unstable<br />
Pin-Priority: -1<br />
<br />
* Vital packages (apt-src, apt-ftparchive, dch):<br />
aptitude install apt-src apt-utils devscripts<br />
<br />
* Environment variables for Debian tools, in my <code>~/.bash_profile</code> (TODO: not taken into account in my Sarge):<br />
export DEBEMAIL="beuc@beuc.net" <br />
export DEBFULLNAME="Sylvain Beucler"<br />
export EDITOR="emacs"<br />
<br />
* <code>debsign</code> GPG configuration, if signing packages is needed, in my <code>~/.devscripts</code>:<br />
DEBSIGN_KEYID="81704B93"<br />
DEBSIGN_PROGRAM="gpg --use-agent"<br />
DEBSIGN_SIGNLIKE="gpg"<br />
<br />
=== To search for a missing dependency ===<br />
<br />
In a vanilla install, sarge and backports in sources.list:<br />
aptitude search keyword # search package whose name contain 'keyword'<br />
apt-cache policy packagename # check what versions are available<br />
<br />
=== Testing the build-deps ===<br />
<br />
apt-get build-dep packagename<br />
<br />
will download the missing dependencies, if available, and report the first missing one otherwise.<br />
<br />
You can alter the build-dep during the creation of the backport, to test whether a modified dependencies list does the trick. <code>apt-get build-dep</code> uses the plain-text <code>/var/lib/apt/lists/ftp.[mirror].debian.org_debian_dists_[distro]_[component]_source_Sources</code> file. You can go quick&dirty and alter that file :) I do not know about a "clean" solution (like feeding <code>apt-get build-dep</code> directly with a <code>debian/control</code> file). You then can test your backported dependencies with:<br />
apt-get -t sarge-backports build-dep packagename<br />
<br />
You may also be interested in <code>dpkg-checkbuilddeps</code>: it reports packages that are not installed,<br />
though it doesn't tell you whether the build _could_ be installed or not, nor which packages exactly are missing.<br />
<br />
=== Making the newly built dependencies available to apt ===<br />
<br />
cd /usr/src<br />
mkdir repo<br />
\mv *-*~bpo.*.deb *-*~bpo.*.udeb *-*~bpo.*.changes *-*~bpo.*.diff.gz *-*~bpo.*.dsc repo/<br />
ln -f *.orig.tar.gz repo/<br />
cd repo<br />
apt-ftparchive packages . | gzip -c > Packages.gz<br />
apt-ftparchive sources . | gzip -c > Sources.gz<br />
cd ..<br />
#echo "deb file:///usr/src/repo ./" >> /etc/apt/sources.list<br />
<br />
There's probably a cleaner way to do this using [http://wiki.debian.org/HowToSetupADebianRepository more comprehensive tools] but that does the trick for now.<br />
<br />
TODO: this doesn't support native packages (w/o .orig.tar.gz)<br />
<br />
=== Don't's ===<br />
<br />
Don't <code>aptitude -t sarge-backports install debhelper</code> blindly.<br />
This will include new helper scripts that may be copied into your packages' postinst/prerm/etc.<br />
This is being [http://lists.backports.org/lurker/message/20060830.124936.32b7cb6f.en.html discussed].<br />
I had to stick to v4 when backporting evince.<br />
<br />
Don't use <code>apt-src build</code>, since it doesn't care about sources packages, unless you configure <code>APT::Src::BuildCommand</code> accordingly (without the <code>-b</code> option for dpkg-buildpackage). Using <code>debuild -us -uc</code> directly worked well for me.<br />
<br />
=== Upload ===<br />
<br />
http://backports.org/contribute.html<br />
<br />
Most commonly, upload your files (the contents of <code>repo/</code>) somewhere and post about it on backports-users@lists.backports.org. Make sure you included a description of what you did in the <code>debian/changelog</code>.<br />
<br />
The page says: ''Our requirements aren't that high. You need to have a gpg key in the official Debian keyring.'' Don't get mistaken: only "Debian developpers" get their gpg keys in the keyring, and becoming one is a [https://nm.debian.org/ months-long process]. However it is very easy to find somebody on the list who will upload your package.<br />
<br />
== Workflow ==<br />
<br />
* Your package hits ''testing''. backports.org aims at providing a smooth transition between the current Debian ''stable'' release and the next one; they don't consider safe to use an ''unstable'' package because if may not enter the next stable (while a ''testing'' package should) [http://lists.backports.org/lurker/message/20060614.173239.0d83eace.en.html]. Fortunately there has been some [http://lists.backports.org/lurker/message/20060630.114154.8e80d282.en.html exceptions].<br />
* You backport the package.<br />
* You test the package. It takes time to upload a package to backports.org, so you'd better send a perfect package from the start.<br />
* You send the package to an authorized member (who will ''sponsor'' it), or you upload directly at ftp://backports.org if you have the privileges (requires being part of the Debian GPG keyring)<br />
* In any case, a binary package must be signed by a Debian developper. If your package is sponsored, it will probably be rebuilt. This rule is [http://lists.backports.org/lurker/message/20060902.131426.a3bad472.en.html strictly enforced], even if you had your GPG key signed and have been around for months.<br />
* If this is the first time your package is backported (or if your source package introduces new binary packages), it will appear at http://www.backports.org/debian/new.html , and wait for a manual review. Norbert Tretkowski (nobse) or Alexander Wirt (formorer) will do so in a matter of days/weeks. eg: evince was accepted after 1 week, ettercap after 1 day - but I don't know the details.<br />
* An autobuilder builds your package for other architectures if available.<br />
<br />
== Test your backport ==<br />
<br />
First, install and run your backport on a Stable system.<br />
<br />
You can also check what changes you introduced using <code>interdiff</code> (from package <code>patchutils</code>):<br />
gunzip par2cmdline_0.4-8.diff.gz<br />
gunzip par2cmdline_0.4-8~bpo.1.diff.gz<br />
interdiff par2cmdline_0.4-8.diff par2cmdline_0.4-8~bpo.1.diff | less<br />
<br />
<code>debdiff</code> will also show you if you mistakenly introduced new files, and will <code>wdiff</code> <code>debian/control</code> (you need to install the <code>wdiff</code> package for that):<br />
aptitude download par2<br />
debdiff par2_0.4-8_i386.deb par2_0.4-8~bpo.1_i386.deb<br />
<br />
Run <code>lintian</code> and <code>linda</code>, two packages test-suites, on your package. If you get errors, check whether they already existed in the original package, or if you introduced them yourself:<br />
linda par2_0.4-8~bpo.1_i386.deb<br />
linda par2_0.4-8_i386.deb<br />
lintian par2_0.4-8~bpo.1_i386.deb<br />
lintian par2_0.4-8_i386.deb<br />
(if your source packages produces several binary packages, specify the .changes instead)<br />
<br />
<code>piuparts</code> is another test suite that actually installs your packages in various ways (instead of inspecting its content), but I have to figure out how to use it accurately for backports.<br />
<br />
== Track your backported packages ==<br />
<br />
After a while, there will be new versions of your backported package in Debian ''testing''.<br />
In this case, either:<br />
* update your backport<br />
* tell backports-users@list.backports.org that you do not intend to do it (lack of time, not using the package anymore, etc.), but that it would be good if someone did<br />
<br />
To be notified of new versions of the package automatically, the simplest way is to subscribe to the PTS (package tracking system).<br />
You can do so from the package developer package (eg. [http://packages.qa.debian.org/dar]).<br />
<br />
Alternatively, you can send an e-mail to pts@qa.debian.org telling:<br />
<br />
Subject: subscribe your_package your@mail.tld<br />
<br />
keyword your_package your@mail.tld = upload-source<br />
quit<br />
<br />
The <code>keyword</code> line tells the BTS to only notify you about new releases. You can check the [http://www.debian.org/doc/developers-reference/ch-resources.en.html#s-pts-commands documentation] to see what other kinds of notification you can receive (bug reports, etc.).<br />
<br />
<br />
[http://people.debian.org/~kobold/ubuntu-diff/bin/ubuntu-diff This script] was recently advertised as a way to track the differences between Ubuntu and Debian packages.<br />
<br />
[https://wiki.ubuntu.com/MultiDistroTools MultiDistroTools] also contains informations in this regard, generating reports like:<br />
* http://tiber.tauware.de/~lucas/versions/<br />
* http://tiber.tauware.de/~lucas/versions/ruby.html<br />
<br />
Such tools should be adaptable for use with backports<->testing.<br />
<br />
<br />
<br />
== Examples ==<br />
<br />
Here are a few sample backports made by Cliss XXI:<br />
* [[Backport dar]]: simple<br />
* [[Backport ettercap]]: more on decrypting version numbers<br />
* [[Backport wireless-tools]]: debhelper and some tricks<br />
* [[Backport Evince]]: more complicated<br />
* [[Backport hplip]]: dependencies and python policy<br />
* [[Backport GCJ]]: in progress, would be useful for OOo2 Base<br />
<br />
== Links ==<br />
<br />
=== Documentation ===<br />
<br />
* A high-level HOWTO: [http://www.dannf.org/docs/backporting-debs.txt A Heuristic-based Process for Backporting Debs]<br />
* [http://www.inittab.de/slides/backporting.pdf Slides] (in German :/) from backports.org founder. Even if you don't grasp German, have a look at the mentioned commands.<br />
* [http://wiki.debian.org/Backports Backports - Debian Wiki]: some procedures to follow when uploading at backports.org. Policies are not explained, though.<br />
<br />
=== Tools ===<br />
* [http://julien.danjou.info/article-apt-build.html apt-build]: this tool might ease backports. To dig out.<br />
* [http://familiasanchez.net/~roberto/howtos/debcustomize Debian Package Customization HOWTO]: a backports is a form of customization<br />
<br />
=== Packages information ===<br />
<br />
* [http://www.backports.org/~formorer/ Package uploads]: who uploaded what at bpo<br />
* http://backports.buildd.net/: Backport's autobuilder homepage (if I got it right, it's the same than Debian experimental).<br />
<br />
=== Other pages at doc.cliss21.org ===<br />
<br />
(French):<br />
* [[Compatibilité binaire]]: pourquoi les exécutables d'une distribution ne fonctionnent pas sur une autre?<br />
<br />
== Note ==<br />
<br />
I put this documentation here because I'd rather publish it in a wiki where subscription or moderation is not required. Feel free to spread it though :)<br />
<br />
There're some bits of French left on this page, from the early version of the document. Feel free to translate those.<br />
<br />
As the only copyright holder of this documentation, and to avoid any troll, this documentation is dual-licensed GFDL and GNU GPL, current versions or later.</div>82.238.35.175https://doc.cliss21.com/index.php?title=UserModeLinux&diff=1847UserModeLinux2006-10-27T21:14:16Z<p>82.238.35.175 : /* Liens */</p>
<hr />
<div>== Compilation du noyau utilisateur ==<br />
<br />
C'est très simple: on compile le noyau Linux avec le paramètre <code>ARCH=um</code> ''pour chaque commande''.<br />
<br />
wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.13.tar.bz2<br />
tar xjf linux-2.6.17.13.tar.bz2<br />
cd linux-2.6.17.13<br />
<br />
make defconfig ARCH=um<br />
make xconfig ARCH=um # facultatif; pensez à activer HOSTFS si besoin<br />
make ARCH=um<br />
strip linux<br />
make modules_install ARCH=um INSTALL_MOD_PATH=uml-modules/<br />
<br />
Cf. [http://user-mode-linux.sourceforge.net/new/source.html Building from source] chez UML.<br />
<br />
Des options que j'active:<br />
* MAGIC_SYSRQ: active l'équivalent de Alt+ImprÉcr, utilisable depuis uml_mconsole<br />
* HOST_2G_2G: contourne un problème de certains noyaux hôte (cf. plus bas)<br />
* HOSTFS: possibilité de monter des répertoires de la machine hôte - attention à la sécurité)<br />
* STATIC_LINK: compiler le noyau en statique (pas de dépendance sur des bibliothèques partagées .so)<br />
<br />
Il y a également des patches à essayer [http://www.user-mode-linux.org/~blaisorblade/patches/]:<br />
* hôte/host:<br />
** skas3 - meilleures performances (dossier skas3-2.6)<br />
* invité/guest:<br />
** exec support: permet de lancer des commandes shell avec uml_mconsole (ex: [http://www.user-mode-linux.org/~blaisorblade/patches/guest/uml-2.6.18.1-bb2/broken-out/uml-mconsole-exec.diff])<br />
<br />
== Construction du système de base ==<br />
<br />
On se propose de construire et de lancer un système UML sans aucun accès root.<br />
<br />
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.<br />
<br />
=== Tentative 1 ===<br />
<br />
Essayons de créer un système complet, sans faire d'image, et en possédant tous les fichiers:<br />
<br />
La dernière version de debootstrap propose une variante ''fakechroot'' qui permet de l'utiliser sans accès root:<br />
export PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH # pour trouver la commande 'chroot'<br />
fakechroot /usr/sbin/debootstrap --variant=fakechroot sarge sarge-uml/ http://localhost/mirrors/debian<br />
/usr/src/linux-2.6.17.13/linux root=/dev/root rootflags=/home/sylvain/tests/uml/debian/sarge-uml/ rootfstype=hostfs<br />
<br />
Résultat: cela ne fonctionne pas, à mon avis parce que dans ce cas précis sarge-uml/dev est un lien symbolique vers /dev.<br />
<br />
=== Tentative 2 ===<br />
<br />
Essayons à partir d'une image UML déjà opérationnelle. Le principe est de monter le système de fichier hôte avec ''hostfs'', puis de faire un <code>mount -o loop</code> depuis le UML sur l'image disque à bootstrap-per. Cela permet de monter l'image sans avoir de privilèges super-utilisateur.<br />
<br />
mount none host/ -t hostfs -o /home/sylvain/tests/uml/debian<br />
cd host/<br />
mkdir loop/<br />
mount image -o loop loop/<br />
ls loop/ # -> bin boot dev etc ...<br />
<br />
[http://packages.debian.org/unstable/utils/rootstrap rootstrap] fonctionne apparemment sur ce principe.<br />
Je n'ai pas réussi mais je n'ai pas beaucoup cherché.<br />
<br />
=== En mode root ===<br />
<br />
Faute de mieux, utilisons sudo:<br />
<br />
mkdir loop/<br />
# image de 1Go, à trous (espace disque progressif)<br />
dd if=/dev/null of=image count=0 bs=1G seek=1<br />
# on formatte en ext3<br />
/sbin/mkfs.ext3 -F image<br />
<br />
sudo mount image loop/ -o loop<br />
sudo debootstrap sarge loop/ http://192.168.1.60/mirrors/debian<br />
<br />
# configuration de la console:<br />
sudo grep -v tty loop/etc/inittab > inittab.work<br />
sudo echo "1:2345:respawn:/sbin/getty 38400 console linux" >> inittab.work<br />
sudo mv inittab.work loop/etc/inittab<br />
<br />
# configuration réseau:<br />
cat <<'EOF' > interfaces.work<br />
auto lo<br />
iface lo inet loopback<br />
EOF<br />
sudo mv interfaces.work loop/etc/network/interfaces<br />
<br />
# fake mtab and fstab<br />
cat <<'EOF' > fstab.work<br />
proc /proc proc defaults 0 0<br />
/dev/ubda / auto defaults,errors=remount-ro 0 1<br />
EOF<br />
sudo mv fstab.work loop/etc/fstab <br />
<br />
sudo umount loop/<br />
<br />
=== Optimiser la taille de l'image pour la distribuer ===<br />
<br />
Une image UML contient souvent des zones vides, où il n'y a pas encore de fichiers. <br />
<br />
L'image ci-dessus réserve 1Go mais n'en occupe que 230Mo grâce à la création d'image "à trous" (''sparse'' en anglais).<br />
<br />
$ ls -lh image<br />
-rw-r--r-- 1 sylvain sylvain 1,0G 2006-09-18 15:55 image<br />
$ du -sh image<br />
234M image<br />
<br />
<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.<br />
<br />
D'autres méthodes (dd sur /dev/zero par exemple) n'en tiennent pas compte.<br />
<br />
<br />
Pour optimiser une image "pleine":<br />
cp --sparse=always image image.sparse<br />
<br />
Pour envoyer une image par le réseau en respectant les trous:<br />
tar cSf image.tar image # S pour "sparse"<br />
<br />
== Réseau ==<br />
<br />
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.<br />
<br />
=== Mode root avec tuntap ===<br />
<br />
host# sudo /usr/src/linux ubda=sarge-debootstrap eth0=tuntap,,,192.168.1.101<br />
<br />
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.<br />
<br />
Puis dans UML:<br />
<br />
uml# ifconfig eth0 192.168.1.201<br />
<br />
=== Mode semi-root avec tuntap ===<br />
<br />
Pour utiliser tuntap, il faut créer à l'avance (et en mode root) une interface tap0 et lui assigner une adresse IP. <br />
<br />
# tunctl -u sylvain<br />
Set 'tap0' persistent and owned by uid 1000<br />
<br />
Puis il faut donner des droits aux utilisateurs non-privilégiés d'utiliser tuntap (en mode root aussi):<br />
<br />
chmod 666 /dev/net/tun<br />
<br />
C'est une solution efficace mais qui nécessite plusieurs étapes de préconfiguration en mode root, accompagné de permissions lâches sur tuntap.<br />
<br />
<br />
=== Mode semi-root avec tuntap (2) ===<br />
<br />
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.<br />
<br />
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=tuntap,,,10.10.10.10<br />
uml# ifconfig eth0 10.10.10.11<br />
uml# route add default gw 10.10.10.10<br />
<br />
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...).<br />
<br />
=== Mode utilisateur avec slirp ===<br />
<br />
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'):<br />
<br />
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=slirp,,/usr/bin/slirp-fullbolt<br />
<br />
Dans UML, quelques étapes spécifiques à slirp sont nécessaires:<br />
<br />
# Configurer l'interface sur 10.2.0.15 (IP de choix pour slirp)<br />
ifconfig eth0 10.2.0.15<br />
# Utiliser la redirection DNS 10.0.2.3<br />
echo "nameserver 10.0.2.3" > /etc/resolv.conf<br />
# Ajouter une route par défaut vers eth0:<br />
route add default dev eth0<br />
<br />
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).<br />
<br />
=== /etc/network/interfaces ===<br />
<br />
Voici comment configurer automatiquement le réseau au démarrage d'UML, dans son fichier <code>interfaces</code>:<br />
<br />
auto lo<br />
iface lo inet loopback<br />
<br />
auto eth0<br />
iface eth0 inet static<br />
<br />
# eth0=tuntap,,,10.10.10.1<br />
# address 10.10.10.10<br />
# netmask 255.0.0.0<br />
# gateway 10.10.10.1<br />
<br />
# eth0=slirp,,/usr/bin/slirp-fullbolt<br />
address 10.2.0.15<br />
netmask 255.0.0.0<br />
dns-nameservers 10.0.2.3<br />
up route add default eth0<br />
<br />
(dns-nameservers nécessite le paquet ''resolvconf'')<br />
<br />
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.<br />
<br />
== Lancer un UML en tâche fond ==<br />
<br />
./linux ubda=... con=null &<br />
<br />
<br />
== Liens ==<br />
<br />
* [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<br />
* [http://eggdrop.ch/texts/uml/ Running Debian inside of Debian with User-Mode Linux]<br />
* [http://www.metz.supelec.fr/metz/personnel/galtier/PagesPerso/TutorielUML/index.html Tutoriel User Mode Linux]: avec introduction à SKAS et réseau<br />
* [http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-6.html#ss6.11 Slirp] dans le UML HOWTO.<br />
* [http://www.phptr.com/bookstore/product.asp?isbn=0131865056&rl=1 Livre] [http://www.eyrolles.com/Informatique/Livre/9780131865051/livre-user-mode-linux.php officiel]: écrit par l'auteur, ce livre est sous licence 'Open Publication' et n'en utilise visiblement aucune des options non-libres. C'est donc un livre libre que l'on peut recommander d'acheter :) La page de présentation indique que les livres de la série "Bruce Perens' Open Source" sont tous sous cette licence et sont publiés au format électronique au bout de 6 mois. J'ai personnellement récupéré un exemplaire au format .chm mais je ne connais pas son origine. J'en dirai plus sur le contenu quand je l'aurai parcouru ;)<br />
* [http://testape.com/webtty_sample.php WebTTY]: lancez une instance UML sur le serveur distant et tapez du Bash intéractivement dans un navigateur web :)<br />
<br />
== Dépannage ==<br />
<br />
Kernel panic - not syncing: start_userspace : expected SIGSTOP, got status = 256<br />
<br />
Cf. http://www.mail-archive.com/user-mode-linux-devel@lists.sourceforge.net/msg03414.html<br />
<br />
Votre noyau (hôte) est, si j'ai bien compris, mal configuré. Recompilez-le ou utilisez-en un autre.<br />
<br />
Vous pouvez également activer CONFIG_HOST_2G_2G dans la configuration du noyau UM.</div>82.238.35.175https://doc.cliss21.com/index.php?title=UserModeLinux&diff=1846UserModeLinux2006-10-27T20:46:51Z<p>82.238.35.175 : /* Compilation du noyau utilisateur */ liens patches noyau hôte</p>
<hr />
<div>== Compilation du noyau utilisateur ==<br />
<br />
C'est très simple: on compile le noyau Linux avec le paramètre <code>ARCH=um</code> ''pour chaque commande''.<br />
<br />
wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.13.tar.bz2<br />
tar xjf linux-2.6.17.13.tar.bz2<br />
cd linux-2.6.17.13<br />
<br />
make defconfig ARCH=um<br />
make xconfig ARCH=um # facultatif; pensez à activer HOSTFS si besoin<br />
make ARCH=um<br />
strip linux<br />
make modules_install ARCH=um INSTALL_MOD_PATH=uml-modules/<br />
<br />
Cf. [http://user-mode-linux.sourceforge.net/new/source.html Building from source] chez UML.<br />
<br />
Des options que j'active:<br />
* MAGIC_SYSRQ: active l'équivalent de Alt+ImprÉcr, utilisable depuis uml_mconsole<br />
* HOST_2G_2G: contourne un problème de certains noyaux hôte (cf. plus bas)<br />
* HOSTFS: possibilité de monter des répertoires de la machine hôte - attention à la sécurité)<br />
* STATIC_LINK: compiler le noyau en statique (pas de dépendance sur des bibliothèques partagées .so)<br />
<br />
Il y a également des patches à essayer [http://www.user-mode-linux.org/~blaisorblade/patches/]:<br />
* hôte/host:<br />
** skas3 - meilleures performances (dossier skas3-2.6)<br />
* invité/guest:<br />
** exec support: permet de lancer des commandes shell avec uml_mconsole (ex: [http://www.user-mode-linux.org/~blaisorblade/patches/guest/uml-2.6.18.1-bb2/broken-out/uml-mconsole-exec.diff])<br />
<br />
== Construction du système de base ==<br />
<br />
On se propose de construire et de lancer un système UML sans aucun accès root.<br />
<br />
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.<br />
<br />
=== Tentative 1 ===<br />
<br />
Essayons de créer un système complet, sans faire d'image, et en possédant tous les fichiers:<br />
<br />
La dernière version de debootstrap propose une variante ''fakechroot'' qui permet de l'utiliser sans accès root:<br />
export PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH # pour trouver la commande 'chroot'<br />
fakechroot /usr/sbin/debootstrap --variant=fakechroot sarge sarge-uml/ http://localhost/mirrors/debian<br />
/usr/src/linux-2.6.17.13/linux root=/dev/root rootflags=/home/sylvain/tests/uml/debian/sarge-uml/ rootfstype=hostfs<br />
<br />
Résultat: cela ne fonctionne pas, à mon avis parce que dans ce cas précis sarge-uml/dev est un lien symbolique vers /dev.<br />
<br />
=== Tentative 2 ===<br />
<br />
Essayons à partir d'une image UML déjà opérationnelle. Le principe est de monter le système de fichier hôte avec ''hostfs'', puis de faire un <code>mount -o loop</code> depuis le UML sur l'image disque à bootstrap-per. Cela permet de monter l'image sans avoir de privilèges super-utilisateur.<br />
<br />
mount none host/ -t hostfs -o /home/sylvain/tests/uml/debian<br />
cd host/<br />
mkdir loop/<br />
mount image -o loop loop/<br />
ls loop/ # -> bin boot dev etc ...<br />
<br />
[http://packages.debian.org/unstable/utils/rootstrap rootstrap] fonctionne apparemment sur ce principe.<br />
Je n'ai pas réussi mais je n'ai pas beaucoup cherché.<br />
<br />
=== En mode root ===<br />
<br />
Faute de mieux, utilisons sudo:<br />
<br />
mkdir loop/<br />
# image de 1Go, à trous (espace disque progressif)<br />
dd if=/dev/null of=image count=0 bs=1G seek=1<br />
# on formatte en ext3<br />
/sbin/mkfs.ext3 -F image<br />
<br />
sudo mount image loop/ -o loop<br />
sudo debootstrap sarge loop/ http://192.168.1.60/mirrors/debian<br />
<br />
# configuration de la console:<br />
sudo grep -v tty loop/etc/inittab > inittab.work<br />
sudo echo "1:2345:respawn:/sbin/getty 38400 console linux" >> inittab.work<br />
sudo mv inittab.work loop/etc/inittab<br />
<br />
# configuration réseau:<br />
cat <<'EOF' > interfaces.work<br />
auto lo<br />
iface lo inet loopback<br />
EOF<br />
sudo mv interfaces.work loop/etc/network/interfaces<br />
<br />
# fake mtab and fstab<br />
cat <<'EOF' > fstab.work<br />
proc /proc proc defaults 0 0<br />
/dev/ubda / auto defaults,errors=remount-ro 0 1<br />
EOF<br />
sudo mv fstab.work loop/etc/fstab <br />
<br />
sudo umount loop/<br />
<br />
=== Optimiser la taille de l'image pour la distribuer ===<br />
<br />
Une image UML contient souvent des zones vides, où il n'y a pas encore de fichiers. <br />
<br />
L'image ci-dessus réserve 1Go mais n'en occupe que 230Mo grâce à la création d'image "à trous" (''sparse'' en anglais).<br />
<br />
$ ls -lh image<br />
-rw-r--r-- 1 sylvain sylvain 1,0G 2006-09-18 15:55 image<br />
$ du -sh image<br />
234M image<br />
<br />
<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.<br />
<br />
D'autres méthodes (dd sur /dev/zero par exemple) n'en tiennent pas compte.<br />
<br />
<br />
Pour optimiser une image "pleine":<br />
cp --sparse=always image image.sparse<br />
<br />
Pour envoyer une image par le réseau en respectant les trous:<br />
tar cSf image.tar image # S pour "sparse"<br />
<br />
== Réseau ==<br />
<br />
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.<br />
<br />
=== Mode root avec tuntap ===<br />
<br />
host# sudo /usr/src/linux ubda=sarge-debootstrap eth0=tuntap,,,192.168.1.101<br />
<br />
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.<br />
<br />
Puis dans UML:<br />
<br />
uml# ifconfig eth0 192.168.1.201<br />
<br />
=== Mode semi-root avec tuntap ===<br />
<br />
Pour utiliser tuntap, il faut créer à l'avance (et en mode root) une interface tap0 et lui assigner une adresse IP. <br />
<br />
# tunctl -u sylvain<br />
Set 'tap0' persistent and owned by uid 1000<br />
<br />
Puis il faut donner des droits aux utilisateurs non-privilégiés d'utiliser tuntap (en mode root aussi):<br />
<br />
chmod 666 /dev/net/tun<br />
<br />
C'est une solution efficace mais qui nécessite plusieurs étapes de préconfiguration en mode root, accompagné de permissions lâches sur tuntap.<br />
<br />
<br />
=== Mode semi-root avec tuntap (2) ===<br />
<br />
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.<br />
<br />
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=tuntap,,,10.10.10.10<br />
uml# ifconfig eth0 10.10.10.11<br />
uml# route add default gw 10.10.10.10<br />
<br />
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...).<br />
<br />
=== Mode utilisateur avec slirp ===<br />
<br />
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'):<br />
<br />
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=slirp,,/usr/bin/slirp-fullbolt<br />
<br />
Dans UML, quelques étapes spécifiques à slirp sont nécessaires:<br />
<br />
# Configurer l'interface sur 10.2.0.15 (IP de choix pour slirp)<br />
ifconfig eth0 10.2.0.15<br />
# Utiliser la redirection DNS 10.0.2.3<br />
echo "nameserver 10.0.2.3" > /etc/resolv.conf<br />
# Ajouter une route par défaut vers eth0:<br />
route add default dev eth0<br />
<br />
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).<br />
<br />
=== /etc/network/interfaces ===<br />
<br />
Voici comment configurer automatiquement le réseau au démarrage d'UML, dans son fichier <code>interfaces</code>:<br />
<br />
auto lo<br />
iface lo inet loopback<br />
<br />
auto eth0<br />
iface eth0 inet static<br />
<br />
# eth0=tuntap,,,10.10.10.1<br />
# address 10.10.10.10<br />
# netmask 255.0.0.0<br />
# gateway 10.10.10.1<br />
<br />
# eth0=slirp,,/usr/bin/slirp-fullbolt<br />
address 10.2.0.15<br />
netmask 255.0.0.0<br />
dns-nameservers 10.0.2.3<br />
up route add default eth0<br />
<br />
(dns-nameservers nécessite le paquet ''resolvconf'')<br />
<br />
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.<br />
<br />
== Lancer un UML en tâche fond ==<br />
<br />
./linux ubda=... con=null &<br />
<br />
<br />
== Liens ==<br />
<br />
* [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<br />
* [http://eggdrop.ch/texts/uml/ Running Debian inside of Debian with User-Mode Linux]<br />
* [http://www.metz.supelec.fr/metz/personnel/galtier/PagesPerso/TutorielUML/index.html Tutoriel User Mode Linux]: avec introduction à SKAS et réseau<br />
* [http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-6.html#ss6.11 Slirp] dans le UML HOWTO.<br />
* [http://www.phptr.com/bookstore/product.asp?isbn=0131865056&rl=1 Livre] [http://www.eyrolles.com/Informatique/Livre/9780131865051/livre-user-mode-linux.php officiel]: écrit par l'auteur, ce livre est sous licence 'Open Publication' et n'en utilise visiblement aucune des options non-libres. C'est donc un livre libre que l'on peut recommander d'acheter :) La page de présentation indique que les livres de la série "Bruce Perens' Open Source" sont tous sous cette licence et sont publiés au format électronique au bout de 6 mois. J'ai personnellement récupéré un exemplaire au format .chm mais je ne connais pas son origine. J'en dirai plus sur le contenu quand je l'aurai parcouru ;)<br />
<br />
== Dépannage ==<br />
<br />
Kernel panic - not syncing: start_userspace : expected SIGSTOP, got status = 256<br />
<br />
Cf. http://www.mail-archive.com/user-mode-linux-devel@lists.sourceforge.net/msg03414.html<br />
<br />
Votre noyau (hôte) est, si j'ai bien compris, mal configuré. Recompilez-le ou utilisez-en un autre.<br />
<br />
Vous pouvez également activer CONFIG_HOST_2G_2G dans la configuration du noyau UM.</div>82.238.35.175https://doc.cliss21.com/index.php?title=UserModeLinux&diff=1845UserModeLinux2006-10-27T20:44:52Z<p>82.238.35.175 : /* Compilation du noyau utilisateur */ descriptions des options noyaux invité</p>
<hr />
<div>== Compilation du noyau utilisateur ==<br />
<br />
C'est très simple: on compile le noyau Linux avec le paramètre <code>ARCH=um</code> ''pour chaque commande''.<br />
<br />
wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.13.tar.bz2<br />
tar xjf linux-2.6.17.13.tar.bz2<br />
cd linux-2.6.17.13<br />
<br />
make defconfig ARCH=um<br />
make xconfig ARCH=um # facultatif; pensez à activer HOSTFS si besoin<br />
make ARCH=um<br />
strip linux<br />
make modules_install ARCH=um INSTALL_MOD_PATH=uml-modules/<br />
<br />
Cf. [http://user-mode-linux.sourceforge.net/new/source.html Building from source] chez UML.<br />
<br />
Des options que j'active:<br />
* MAGIC_SYSRQ: active l'équivalent de Alt+ImprÉcr, utilisable depuis uml_mconsole<br />
* HOST_2G_2G: contourne un problème de certains noyaux hôte (cf. plus bas)<br />
* HOSTFS: possibilité de monter des répertoires de la machine hôte - attention à la sécurité)<br />
* STATIC_LINK: compiler le noyau en statique (pas de dépendance sur des bibliothèques partagées .so)<br />
<br />
Il y a également des patches à essayer:<br />
* hôte/host:<br />
** skas3 - meilleures performances<br />
* invité/guest:<br />
** exec support: permet de lancer des commandes shell avec uml_mconsole<br />
<br />
== Construction du système de base ==<br />
<br />
On se propose de construire et de lancer un système UML sans aucun accès root.<br />
<br />
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.<br />
<br />
=== Tentative 1 ===<br />
<br />
Essayons de créer un système complet, sans faire d'image, et en possédant tous les fichiers:<br />
<br />
La dernière version de debootstrap propose une variante ''fakechroot'' qui permet de l'utiliser sans accès root:<br />
export PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH # pour trouver la commande 'chroot'<br />
fakechroot /usr/sbin/debootstrap --variant=fakechroot sarge sarge-uml/ http://localhost/mirrors/debian<br />
/usr/src/linux-2.6.17.13/linux root=/dev/root rootflags=/home/sylvain/tests/uml/debian/sarge-uml/ rootfstype=hostfs<br />
<br />
Résultat: cela ne fonctionne pas, à mon avis parce que dans ce cas précis sarge-uml/dev est un lien symbolique vers /dev.<br />
<br />
=== Tentative 2 ===<br />
<br />
Essayons à partir d'une image UML déjà opérationnelle. Le principe est de monter le système de fichier hôte avec ''hostfs'', puis de faire un <code>mount -o loop</code> depuis le UML sur l'image disque à bootstrap-per. Cela permet de monter l'image sans avoir de privilèges super-utilisateur.<br />
<br />
mount none host/ -t hostfs -o /home/sylvain/tests/uml/debian<br />
cd host/<br />
mkdir loop/<br />
mount image -o loop loop/<br />
ls loop/ # -> bin boot dev etc ...<br />
<br />
[http://packages.debian.org/unstable/utils/rootstrap rootstrap] fonctionne apparemment sur ce principe.<br />
Je n'ai pas réussi mais je n'ai pas beaucoup cherché.<br />
<br />
=== En mode root ===<br />
<br />
Faute de mieux, utilisons sudo:<br />
<br />
mkdir loop/<br />
# image de 1Go, à trous (espace disque progressif)<br />
dd if=/dev/null of=image count=0 bs=1G seek=1<br />
# on formatte en ext3<br />
/sbin/mkfs.ext3 -F image<br />
<br />
sudo mount image loop/ -o loop<br />
sudo debootstrap sarge loop/ http://192.168.1.60/mirrors/debian<br />
<br />
# configuration de la console:<br />
sudo grep -v tty loop/etc/inittab > inittab.work<br />
sudo echo "1:2345:respawn:/sbin/getty 38400 console linux" >> inittab.work<br />
sudo mv inittab.work loop/etc/inittab<br />
<br />
# configuration réseau:<br />
cat <<'EOF' > interfaces.work<br />
auto lo<br />
iface lo inet loopback<br />
EOF<br />
sudo mv interfaces.work loop/etc/network/interfaces<br />
<br />
# fake mtab and fstab<br />
cat <<'EOF' > fstab.work<br />
proc /proc proc defaults 0 0<br />
/dev/ubda / auto defaults,errors=remount-ro 0 1<br />
EOF<br />
sudo mv fstab.work loop/etc/fstab <br />
<br />
sudo umount loop/<br />
<br />
=== Optimiser la taille de l'image pour la distribuer ===<br />
<br />
Une image UML contient souvent des zones vides, où il n'y a pas encore de fichiers. <br />
<br />
L'image ci-dessus réserve 1Go mais n'en occupe que 230Mo grâce à la création d'image "à trous" (''sparse'' en anglais).<br />
<br />
$ ls -lh image<br />
-rw-r--r-- 1 sylvain sylvain 1,0G 2006-09-18 15:55 image<br />
$ du -sh image<br />
234M image<br />
<br />
<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.<br />
<br />
D'autres méthodes (dd sur /dev/zero par exemple) n'en tiennent pas compte.<br />
<br />
<br />
Pour optimiser une image "pleine":<br />
cp --sparse=always image image.sparse<br />
<br />
Pour envoyer une image par le réseau en respectant les trous:<br />
tar cSf image.tar image # S pour "sparse"<br />
<br />
== Réseau ==<br />
<br />
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.<br />
<br />
=== Mode root avec tuntap ===<br />
<br />
host# sudo /usr/src/linux ubda=sarge-debootstrap eth0=tuntap,,,192.168.1.101<br />
<br />
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.<br />
<br />
Puis dans UML:<br />
<br />
uml# ifconfig eth0 192.168.1.201<br />
<br />
=== Mode semi-root avec tuntap ===<br />
<br />
Pour utiliser tuntap, il faut créer à l'avance (et en mode root) une interface tap0 et lui assigner une adresse IP. <br />
<br />
# tunctl -u sylvain<br />
Set 'tap0' persistent and owned by uid 1000<br />
<br />
Puis il faut donner des droits aux utilisateurs non-privilégiés d'utiliser tuntap (en mode root aussi):<br />
<br />
chmod 666 /dev/net/tun<br />
<br />
C'est une solution efficace mais qui nécessite plusieurs étapes de préconfiguration en mode root, accompagné de permissions lâches sur tuntap.<br />
<br />
<br />
=== Mode semi-root avec tuntap (2) ===<br />
<br />
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.<br />
<br />
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=tuntap,,,10.10.10.10<br />
uml# ifconfig eth0 10.10.10.11<br />
uml# route add default gw 10.10.10.10<br />
<br />
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...).<br />
<br />
=== Mode utilisateur avec slirp ===<br />
<br />
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'):<br />
<br />
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=slirp,,/usr/bin/slirp-fullbolt<br />
<br />
Dans UML, quelques étapes spécifiques à slirp sont nécessaires:<br />
<br />
# Configurer l'interface sur 10.2.0.15 (IP de choix pour slirp)<br />
ifconfig eth0 10.2.0.15<br />
# Utiliser la redirection DNS 10.0.2.3<br />
echo "nameserver 10.0.2.3" > /etc/resolv.conf<br />
# Ajouter une route par défaut vers eth0:<br />
route add default dev eth0<br />
<br />
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).<br />
<br />
=== /etc/network/interfaces ===<br />
<br />
Voici comment configurer automatiquement le réseau au démarrage d'UML, dans son fichier <code>interfaces</code>:<br />
<br />
auto lo<br />
iface lo inet loopback<br />
<br />
auto eth0<br />
iface eth0 inet static<br />
<br />
# eth0=tuntap,,,10.10.10.1<br />
# address 10.10.10.10<br />
# netmask 255.0.0.0<br />
# gateway 10.10.10.1<br />
<br />
# eth0=slirp,,/usr/bin/slirp-fullbolt<br />
address 10.2.0.15<br />
netmask 255.0.0.0<br />
dns-nameservers 10.0.2.3<br />
up route add default eth0<br />
<br />
(dns-nameservers nécessite le paquet ''resolvconf'')<br />
<br />
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.<br />
<br />
== Lancer un UML en tâche fond ==<br />
<br />
./linux ubda=... con=null &<br />
<br />
<br />
== Liens ==<br />
<br />
* [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<br />
* [http://eggdrop.ch/texts/uml/ Running Debian inside of Debian with User-Mode Linux]<br />
* [http://www.metz.supelec.fr/metz/personnel/galtier/PagesPerso/TutorielUML/index.html Tutoriel User Mode Linux]: avec introduction à SKAS et réseau<br />
* [http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-6.html#ss6.11 Slirp] dans le UML HOWTO.<br />
* [http://www.phptr.com/bookstore/product.asp?isbn=0131865056&rl=1 Livre] [http://www.eyrolles.com/Informatique/Livre/9780131865051/livre-user-mode-linux.php officiel]: écrit par l'auteur, ce livre est sous licence 'Open Publication' et n'en utilise visiblement aucune des options non-libres. C'est donc un livre libre que l'on peut recommander d'acheter :) La page de présentation indique que les livres de la série "Bruce Perens' Open Source" sont tous sous cette licence et sont publiés au format électronique au bout de 6 mois. J'ai personnellement récupéré un exemplaire au format .chm mais je ne connais pas son origine. J'en dirai plus sur le contenu quand je l'aurai parcouru ;)<br />
<br />
== Dépannage ==<br />
<br />
Kernel panic - not syncing: start_userspace : expected SIGSTOP, got status = 256<br />
<br />
Cf. http://www.mail-archive.com/user-mode-linux-devel@lists.sourceforge.net/msg03414.html<br />
<br />
Votre noyau (hôte) est, si j'ai bien compris, mal configuré. Recompilez-le ou utilisez-en un autre.<br />
<br />
Vous pouvez également activer CONFIG_HOST_2G_2G dans la configuration du noyau UM.</div>82.238.35.175https://doc.cliss21.com/index.php?title=UserModeLinux&diff=1844UserModeLinux2006-10-27T20:04:34Z<p>82.238.35.175 : /* Compilation du noyau utilisateur */</p>
<hr />
<div>== Compilation du noyau utilisateur ==<br />
<br />
C'est très simple: on compile le noyau Linux avec le paramètre <code>ARCH=um</code> ''pour chaque commande''.<br />
<br />
wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.13.tar.bz2<br />
tar xjf linux-2.6.17.13.tar.bz2<br />
cd linux-2.6.17.13<br />
<br />
make defconfig ARCH=um<br />
make xconfig ARCH=um # facultatif; pensez à activer HOSTFS si besoin<br />
make ARCH=um<br />
strip linux<br />
make modules_install ARCH=um INSTALL_MOD_PATH=uml-modules/<br />
<br />
Cf. [http://user-mode-linux.sourceforge.net/new/source.html Building from source] chez UML.<br />
<br />
Des options que j'active:<br />
* MAGIC_SYSRQ<br />
* HOST_2G_2G<br />
* HOSTFS<br />
* STATIC_LINK (pas encore essayé)<br />
<br />
Il y a également des patches à essayer:<br />
* hôte/host:<br />
** skas3 - meilleures performances<br />
* invité/guest:<br />
** exec support: permet de lancer des commandes shell avec uml_mconsole<br />
<br />
== Construction du système de base ==<br />
<br />
On se propose de construire et de lancer un système UML sans aucun accès root.<br />
<br />
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.<br />
<br />
=== Tentative 1 ===<br />
<br />
Essayons de créer un système complet, sans faire d'image, et en possédant tous les fichiers:<br />
<br />
La dernière version de debootstrap propose une variante ''fakechroot'' qui permet de l'utiliser sans accès root:<br />
export PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH # pour trouver la commande 'chroot'<br />
fakechroot /usr/sbin/debootstrap --variant=fakechroot sarge sarge-uml/ http://localhost/mirrors/debian<br />
/usr/src/linux-2.6.17.13/linux root=/dev/root rootflags=/home/sylvain/tests/uml/debian/sarge-uml/ rootfstype=hostfs<br />
<br />
Résultat: cela ne fonctionne pas, à mon avis parce que dans ce cas précis sarge-uml/dev est un lien symbolique vers /dev.<br />
<br />
=== Tentative 2 ===<br />
<br />
Essayons à partir d'une image UML déjà opérationnelle. Le principe est de monter le système de fichier hôte avec ''hostfs'', puis de faire un <code>mount -o loop</code> depuis le UML sur l'image disque à bootstrap-per. Cela permet de monter l'image sans avoir de privilèges super-utilisateur.<br />
<br />
mount none host/ -t hostfs -o /home/sylvain/tests/uml/debian<br />
cd host/<br />
mkdir loop/<br />
mount image -o loop loop/<br />
ls loop/ # -> bin boot dev etc ...<br />
<br />
[http://packages.debian.org/unstable/utils/rootstrap rootstrap] fonctionne apparemment sur ce principe.<br />
Je n'ai pas réussi mais je n'ai pas beaucoup cherché.<br />
<br />
=== En mode root ===<br />
<br />
Faute de mieux, utilisons sudo:<br />
<br />
mkdir loop/<br />
# image de 1Go, à trous (espace disque progressif)<br />
dd if=/dev/null of=image count=0 bs=1G seek=1<br />
# on formatte en ext3<br />
/sbin/mkfs.ext3 -F image<br />
<br />
sudo mount image loop/ -o loop<br />
sudo debootstrap sarge loop/ http://192.168.1.60/mirrors/debian<br />
<br />
# configuration de la console:<br />
sudo grep -v tty loop/etc/inittab > inittab.work<br />
sudo echo "1:2345:respawn:/sbin/getty 38400 console linux" >> inittab.work<br />
sudo mv inittab.work loop/etc/inittab<br />
<br />
# configuration réseau:<br />
cat <<'EOF' > interfaces.work<br />
auto lo<br />
iface lo inet loopback<br />
EOF<br />
sudo mv interfaces.work loop/etc/network/interfaces<br />
<br />
# fake mtab and fstab<br />
cat <<'EOF' > fstab.work<br />
proc /proc proc defaults 0 0<br />
/dev/ubda / auto defaults,errors=remount-ro 0 1<br />
EOF<br />
sudo mv fstab.work loop/etc/fstab <br />
<br />
sudo umount loop/<br />
<br />
=== Optimiser la taille de l'image pour la distribuer ===<br />
<br />
Une image UML contient souvent des zones vides, où il n'y a pas encore de fichiers. <br />
<br />
L'image ci-dessus réserve 1Go mais n'en occupe que 230Mo grâce à la création d'image "à trous" (''sparse'' en anglais).<br />
<br />
$ ls -lh image<br />
-rw-r--r-- 1 sylvain sylvain 1,0G 2006-09-18 15:55 image<br />
$ du -sh image<br />
234M image<br />
<br />
<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.<br />
<br />
D'autres méthodes (dd sur /dev/zero par exemple) n'en tiennent pas compte.<br />
<br />
<br />
Pour optimiser une image "pleine":<br />
cp --sparse=always image image.sparse<br />
<br />
Pour envoyer une image par le réseau en respectant les trous:<br />
tar cSf image.tar image # S pour "sparse"<br />
<br />
== Réseau ==<br />
<br />
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.<br />
<br />
=== Mode root avec tuntap ===<br />
<br />
host# sudo /usr/src/linux ubda=sarge-debootstrap eth0=tuntap,,,192.168.1.101<br />
<br />
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.<br />
<br />
Puis dans UML:<br />
<br />
uml# ifconfig eth0 192.168.1.201<br />
<br />
=== Mode semi-root avec tuntap ===<br />
<br />
Pour utiliser tuntap, il faut créer à l'avance (et en mode root) une interface tap0 et lui assigner une adresse IP. <br />
<br />
# tunctl -u sylvain<br />
Set 'tap0' persistent and owned by uid 1000<br />
<br />
Puis il faut donner des droits aux utilisateurs non-privilégiés d'utiliser tuntap (en mode root aussi):<br />
<br />
chmod 666 /dev/net/tun<br />
<br />
C'est une solution efficace mais qui nécessite plusieurs étapes de préconfiguration en mode root, accompagné de permissions lâches sur tuntap.<br />
<br />
<br />
=== Mode semi-root avec tuntap (2) ===<br />
<br />
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.<br />
<br />
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=tuntap,,,10.10.10.10<br />
uml# ifconfig eth0 10.10.10.11<br />
uml# route add default gw 10.10.10.10<br />
<br />
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...).<br />
<br />
=== Mode utilisateur avec slirp ===<br />
<br />
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'):<br />
<br />
host# /usr/src/linux ubda=sarge-debootstrap umid=deb eth0=slirp,,/usr/bin/slirp-fullbolt<br />
<br />
Dans UML, quelques étapes spécifiques à slirp sont nécessaires:<br />
<br />
# Configurer l'interface sur 10.2.0.15 (IP de choix pour slirp)<br />
ifconfig eth0 10.2.0.15<br />
# Utiliser la redirection DNS 10.0.2.3<br />
echo "nameserver 10.0.2.3" > /etc/resolv.conf<br />
# Ajouter une route par défaut vers eth0:<br />
route add default dev eth0<br />
<br />
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).<br />
<br />
=== /etc/network/interfaces ===<br />
<br />
Voici comment configurer automatiquement le réseau au démarrage d'UML, dans son fichier <code>interfaces</code>:<br />
<br />
auto lo<br />
iface lo inet loopback<br />
<br />
auto eth0<br />
iface eth0 inet static<br />
<br />
# eth0=tuntap,,,10.10.10.1<br />
# address 10.10.10.10<br />
# netmask 255.0.0.0<br />
# gateway 10.10.10.1<br />
<br />
# eth0=slirp,,/usr/bin/slirp-fullbolt<br />
address 10.2.0.15<br />
netmask 255.0.0.0<br />
dns-nameservers 10.0.2.3<br />
up route add default eth0<br />
<br />
(dns-nameservers nécessite le paquet ''resolvconf'')<br />
<br />
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.<br />
<br />
== Lancer un UML en tâche fond ==<br />
<br />
./linux ubda=... con=null &<br />
<br />
<br />
== Liens ==<br />
<br />
* [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<br />
* [http://eggdrop.ch/texts/uml/ Running Debian inside of Debian with User-Mode Linux]<br />
* [http://www.metz.supelec.fr/metz/personnel/galtier/PagesPerso/TutorielUML/index.html Tutoriel User Mode Linux]: avec introduction à SKAS et réseau<br />
* [http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-6.html#ss6.11 Slirp] dans le UML HOWTO.<br />
* [http://www.phptr.com/bookstore/product.asp?isbn=0131865056&rl=1 Livre] [http://www.eyrolles.com/Informatique/Livre/9780131865051/livre-user-mode-linux.php officiel]: écrit par l'auteur, ce livre est sous licence 'Open Publication' et n'en utilise visiblement aucune des options non-libres. C'est donc un livre libre que l'on peut recommander d'acheter :) La page de présentation indique que les livres de la série "Bruce Perens' Open Source" sont tous sous cette licence et sont publiés au format électronique au bout de 6 mois. J'ai personnellement récupéré un exemplaire au format .chm mais je ne connais pas son origine. J'en dirai plus sur le contenu quand je l'aurai parcouru ;)<br />
<br />
== Dépannage ==<br />
<br />
Kernel panic - not syncing: start_userspace : expected SIGSTOP, got status = 256<br />
<br />
Cf. http://www.mail-archive.com/user-mode-linux-devel@lists.sourceforge.net/msg03414.html<br />
<br />
Votre noyau (hôte) est, si j'ai bien compris, mal configuré. Recompilez-le ou utilisez-en un autre.<br />
<br />
Vous pouvez également activer CONFIG_HOST_2G_2G dans la configuration du noyau UM.</div>82.238.35.175https://doc.cliss21.com/index.php?title=Miroir_Debian&diff=1079Miroir Debian2006-10-22T12:02:59Z<p>82.238.35.175 : /* Autres solutions à creuser */</p>
<hr />
<div>Si vous allez chez des clients démunis d'un accès haut débit, un miroir Debian partiel doit faire partie de votre kit de survie.<br />
<br />
Tentons donc de créer un miroir:<br />
<br />
* Utilisation de debmirror:<br />
aptitude install debmirror<br />
<br />
* Télécharger les clefs GPG:<br />
gpg --keyserver keyring.debian.org --recv 4F368D5D # 2005<br />
gpg --keyserver keyring.debian.org --recv 2D230C5F # 2006<br />
gpg --keyserver pgpkeys.pca.dfn.de --recv 16BA136C # backports.org<br />
<br />
* Lancer la réplication:<br />
rm /etc/debmirror.conf # it would conflict with our settings<br />
<br />
# Sarge<br />
debmirror --verbose --host=ftp2.fr.debian.org --dist=sarge --dist=stable \<br />
--section=main,main/debian-installer --nosource --getcontents \<br />
/mnt/mirrors/debian<br />
<br />
# Sarge security<br />
debmirror --verbose --host=security.debian.org --dist=sarge/updates \<br />
--root=debian-security --section=main --nosource \<br />
/mnt/mirrors/debian-security<br />
<br />
# Sarge backports<br />
debmirror --verbose --host=www.backports.org --method=http \<br />
--dist=sarge-backports --section=main --nosource --getcontents \<br />
/mnt/mirrors/backports.org<br />
<br />
Il est possible d'interrompre la réplication et de la reprendre plus tard.<br />
<br />
Il est également possible d'utiliser plusieurs fois l'option <code>--dist</code>, par exemple <code>--dist=sarge --dist=etch</code>. Ici on récupère à la fois 'sarge' et 'stable' de sorte que les deux soient disponibles (les logiciels peuvent utiliser alternativement un nom ou l'autre) - bien entendu les paquets eux-mêmes ne seront téléchargés qu'une seule fois, dans <code>pool/</code>.<br />
<br />
<code>--getcontents</code> permet de récupérer le fichier <code>Content-i386.gz</code>, utilisé notamment par [http://packages.debian.org/stable/base/apt-file apt-file]. Il n'est pas fourni par security.debian.org pour le moment, et demander <code>--getcontents</code> est considéré comme une erreur (plus de mise à jour de Packages.gz - à corriger).<br />
<br />
Inconvénients:<br />
* Il y a une perte de place, car les paquets qui ont eu une mise à jour de sécurité sont téléchargés dans mirrors/debian, et redondants par rapport à mirrors/debian-security. Pourrait-il y avoir des problèmes avec l'installateur Debian si la version d'origine de ces paquets manque, cependant?<br />
* Il n'est pas possible de récupérer uniquement les codes source<br />
<br />
Place disque utilisée (2006-03-25):<br />
* mirrors/debian: ~8,6 Go (fixe, + ~9 Go pour les sources)<br />
* mirrors/debian-security: ~1,4 Go (grossit, + ~800 Mo pour les sources)<br />
* mirrors/backports.org: ~2,8 Go (grossit, + ~2Go pour les sources)<br />
<br />
On peut utiliser directement le miroir en local: dans <code>/etc/apt/sources.list</code>:<br />
deb file:///mnt/mirrors/debian sarge main<br />
<br />
== Partager le miroir ==<br />
<br />
Une petite config Apache suffit:<br />
<br />
Alias /mirrors /mnt/mirrors<br />
<Directory "/mnt/mirrors"><br />
Options Indexes<br />
AllowOverride None<br />
</Directory><br />
<br />
Au niveau client, le <code>/etc/apt/sources.list</code> ressemblera à:<br />
deb http://192.168.1.63/mirrors/debian sarge main<br />
deb http://192.168.1.63/mirrors/debian-security sarge/updates main<br />
deb http://192.168.1.63/mirrors/backports.org sarge-backports main<br />
<br />
Pour une installation Debian par le réseau, lorsque l'installateur vous demande le pays de votre miroir, choisissez le paramétrage manuel (tout en haut de la liste), puis:<br />
* Nom d'hôte: ''IP de votre machine''<br />
* Répertoire: <code>/mirrors/debian</code><br />
<br />
== Autres solutions à creuser ==<br />
<br />
* apt-move "can also build a partial or complete local mirror of a Debian binary distribution (including an ``installed-packages only'' mirror)."<br />
<br />
* [http://linux.inet.hr/debian/ debian-mirror] est peut-être intéressant, mais pas de paquet Debian, bouh :p<br />
<br />
* Idem pour [http://apt-mirror.sourceforge.net/ apt-mirror]<br />
<br />
* [http://www.debian.org/mirror/ftpmirror Setting up a Debian archive mirror] recommande d'utiliser [http://www.debian.org/mirror/anonftpsync anonftpsync]. Même remarque :p Qui plus est, il faut sélectionner les architectures qu'on ne souhaite pas télécharger, à la place de ne sélectionner que les architectures dont on a besoin. C'est un script très court qui se base sur rsync, et ne peut pas créer de miroir partiel. debmirror semble plus simple.<br />
<br />
== Autres solutions non retenues ==<br />
<br />
* Il est possible d'utiliser un DVD d'installation, mais ce ne sera pas pratique:<br />
** il vous faudra changer régulièrement entre les deux CDs, voire entre plusieurs postes<br />
** vous n'aurez pas les mises à jour de sécurité (même si votre CD a été créé avec Jigdo)<br />
* Utiliser un apt-proxy sur votre ordinateur portable n'est pas une solution satisfaisante: il vous faudra le paramétrer pour éviter qu'il cherche des mises à jour lors d'un travail hors-ligne, et il vous manquera certainement des paquets.<br />
* debmirror + fichier de configuration (par opposition à ligne de commande): on a besoin d'au moins deux serveurs et donc deux configurations au minimum (stable, stable/security, éventuellement sarge-backports). C'est plus pratique en ligne de commande.</div>82.238.35.175https://doc.cliss21.com/index.php?title=Backports&diff=1495Backports2006-10-21T13:49:39Z<p>82.238.35.175 : /* Note */</p>
<hr />
<div>== Definition ==<br />
<br />
A backport is a Debian package that is recompiled for an earlier version of the distribution. For example, there is a backport from the latest version of KDE [http://debian-unofficial.org/backports.html] that was compiled for ''Sarge'', based on packages originally meant for ''Etch''.<br />
<br />
Un ''backport'', c'est un paquet Debian recompilé pour une version précédente de la distribution. Par exemple, il y a un backport de la dernière version de KDE [http://debian-unofficial.org/backports.html] compilé pour ''Sarge'', à partir des paquets initialement prévue pour ''Etch''.<br />
<br />
== Motivations ==<br />
<br />
This recompilation is necessary for several reasons:<br />
* The packages dependencies change so as to take the evolution of the rest of the system into account; in our case, we'll change those dependencies to use earlier versions.<br />
* Binary compatibility issues (French: [[Compatibilité binaire]])<br />
<br />
== Où trouver des backports ==<br />
<br />
[http://backports.org backports.org] est la référence en la matière.<br />
<br />
Il y a également des dépôts de paquets plus spécialisés, mais ceux-ci ne sont pas toujours très attentifs aux licences, et vous pouvez récupérer des composants non-libres :/<br />
<br />
[http://apt-get.org/ apt-get.org] fournit une liste de ces dépôts, à la fois ceux qui contiennent des composants non inclus dans Debian pour diverses raisons, et ceux qui fournissent des backports proprement dit.<br />
<br />
== Using backports.org ==<br />
<br />
Add the following line in your <code>/etc/apt/sources.list</code>:<br />
deb http://www.backports.org/debian sarge-backports main<br />
<br />
Then install backported packages using:<br />
aptitude -t sarge-backports install BackportedPackage<br />
<br />
(Before, you had to configure ''pinning'' (packages priorities), but this is<br />
[http://lists.backports.org/lurker/message/20060814.093117.ab4c6b26.en.html no longer necessary])<br />
<br />
* [http://backports.org/dokuwiki/doku.php?id=instructions Official instructions]<br />
<br />
Note: it is not recommended to install all backports at once. Instead you should select only the packages that you need. Unlike in full, consistent Debian distros, each backport is tested individually against the Debian stable version, so they might conflict with each others - but they still share common backported dependencies.<br />
<br />
== backports.org GPG key ==<br />
<br />
After <code>apt-get update</code>, I get:<br />
W: GPG error: http://localhost sarge-backports Release: Les signatures suivantes<br />
n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKE Y EA8E8B2116BA136C<br />
<br />
So I need to import that key from a keyserver:<br />
$ gpg --recv-keys EA8E8B2116BA136C<br />
gpg: le porte-clés `/root/.gnupg/secring.gpg` a été créé<br />
gpg: requête de la clé 16BA136C du serveur hkp subkeys.pgp.net<br />
gpg: /root/.gnupg/trustdb.gpg: base de confiance créée<br />
gpg: clé 16BA136C: clé publique « Backports.org Archive Key <ftp-master@backport s.org> » importée<br />
gpg: aucune clé de confiance ultime n'a été trouvée<br />
gpg: Quantité totale traitée: 1<br />
gpg: importée: 1<br />
<br />
and tell apt about it:<br />
$ gpg --export EA8E8B2116BA136C | apt-key add -<br />
OK<br />
<br />
== HOWTO backport? ==<br />
<br />
Some general considerations:<br />
<br />
=== Config ===<br />
<br />
* debootstrap<br />
* basic compilation tools: <code>aptitude install build-essential</code><br />
* sources.list:<br />
##<br />
# Stable and backports repositories<br />
##<br />
deb http://ftp.fr.debian.org/debian stable main<br />
deb http://security.debian.org/debian-security stable/updates main<br />
deb http://www.backports.org/debian/ sarge-backports main<br />
deb-src http://ftp.fr.debian.org/debian stable main<br />
deb-src http://security.debian.org/debian-security stable/updates main<br />
deb-src http://backports.org/debian sarge-backports main<br />
<br />
##<br />
# Testing and unstable repositories<br />
##<br />
<br />
# Binaries - uncomment if you need to test 'aptitude install'<br />
#deb http://ftp.fr.debian.org/debian testing main<br />
#deb http://ftp.fr.debian.org/debian unstable main<br />
<br />
# Sources - uncomment the one you're backporting from<br />
#deb-src http://ftp.fr.debian.org/debian testing main<br />
deb-src http://ftp.fr.debian.org/debian unstable main<br />
<br />
##<br />
# backports in progress<br />
##<br />
deb file:///usr/src/repo ./<br />
<br />
* /etc/apt/preferences:<br />
Package: *<br />
Pin: release a=testing<br />
Pin-Priority: -1<br />
<br />
Package: *<br />
Pin: release a=unstable<br />
Pin-Priority: -1<br />
<br />
* Vital packages (apt-src, apt-ftparchive, dch):<br />
aptitude install apt-src apt-utils devscripts<br />
<br />
* Environment variables for Debian tools, in my <code>~/.bash_profile</code> (TODO: not taken into account in my Sarge):<br />
export DEBEMAIL="beuc@beuc.net" <br />
export DEBFULLNAME="Sylvain Beucler"<br />
export EDITOR="emacs"<br />
<br />
* <code>debsign</code> GPG configuration, if signing packages is needed, in my <code>~/.devscripts</code>:<br />
DEBSIGN_KEYID="81704B93"<br />
DEBSIGN_PROGRAM="gpg --use-agent"<br />
DEBSIGN_SIGNLIKE="gpg"<br />
<br />
=== To search for a missing dependency ===<br />
<br />
In a vanilla install, sarge and backports in sources.list:<br />
aptitude search keyword # search package whose name contain 'keyword'<br />
apt-cache policy packagename # check what versions are available<br />
<br />
=== Testing the build-deps ===<br />
<br />
apt-get build-dep packagename<br />
<br />
will download the missing dependencies, if available, and report the first missing one otherwise.<br />
<br />
You can alter the build-dep during the creation of the backport, to test whether a modified dependencies list does the trick. <code>apt-get build-dep</code> uses the plain-text <code>/var/lib/apt/lists/ftp.[mirror].debian.org_debian_dists_[distro]_[component]_source_Sources</code> file. You can go quick&dirty and alter that file :) I do not know about a "clean" solution (like feeding <code>apt-get build-dep</code> directly with a <code>debian/control</code> file). You then can test your backported dependencies with:<br />
apt-get -t sarge-backports build-dep packagename<br />
<br />
You may also be interested in <code>dpkg-checkbuilddeps</code>: it reports packages that are not installed,<br />
though it doesn't tell you whether the build _could_ be installed or not, nor which packages exactly are missing.<br />
<br />
=== Making the newly built dependencies available to apt ===<br />
<br />
cd /usr/src<br />
mkdir repo<br />
\mv *-*~bpo.*.deb *-*~bpo.*.udeb *-*~bpo.*.changes *-*~bpo.*.diff.gz *-*~bpo.*.dsc repo/<br />
ln -f *.orig.tar.gz repo/<br />
cd repo<br />
apt-ftparchive packages . | gzip -c > Packages.gz<br />
apt-ftparchive sources . | gzip -c > Sources.gz<br />
cd ..<br />
#echo "deb file:///usr/src/repo ./" >> /etc/apt/sources.list<br />
<br />
There's probably a cleaner way to do this using [http://wiki.debian.org/HowToSetupADebianRepository more comprehensive tools] but that does the trick for now.<br />
<br />
TODO: this doesn't support native packages (w/o .orig.tar.gz)<br />
<br />
=== Don't's ===<br />
<br />
Don't <code>aptitude -t sarge-backports install debhelper</code> blindly.<br />
This will include new helper scripts that may be copied into your packages' postinst/prerm/etc.<br />
This is being [http://lists.backports.org/lurker/message/20060830.124936.32b7cb6f.en.html discussed].<br />
I had to stick to v4 when backporting evince.<br />
<br />
Don't use <code>apt-src build</code>, since it doesn't care about sources packages, unless you configure <code>APT::Src::BuildCommand</code> accordingly (without the <code>-b</code> option for dpkg-buildpackage). Using <code>debuild -us -uc</code> directly worked well for me.<br />
<br />
=== Upload ===<br />
<br />
http://backports.org/contribute.html<br />
<br />
Most commonly, upload your files (the contents of <code>repo/</code>) somewhere and post about it on backports-users@lists.backports.org. Make sure you included a description of what you did in the <code>debian/changelog</code>.<br />
<br />
The page says: ''Our requirements aren't that high. You need to have a gpg key in the official Debian keyring.'' Don't get mistaken: only "Debian developpers" get their gpg keys in the keyring, and becoming one is a [https://nm.debian.org/ months-long process]. However it is very easy to find somebody on the list who will upload your package.<br />
<br />
== Workflow ==<br />
<br />
* Your package hits ''testing''. backports.org aims at providing a smooth transition between the current Debian ''stable'' release and the next one; they don't consider safe to use an ''unstable'' package because if may not enter the next stable (while a ''testing'' package should) [http://lists.backports.org/lurker/message/20060614.173239.0d83eace.en.html]. Fortunately there has been some [http://lists.backports.org/lurker/message/20060630.114154.8e80d282.en.html exceptions].<br />
* You backport the package.<br />
* You test the package. It takes time to upload a package to backports.org, so you'd better send a perfect package from the start.<br />
* You send the package to an authorized member (who will ''sponsor'' it), or you upload directly at ftp://backports.org if you have the privileges (requires being part of the Debian GPG keyring)<br />
* In any case, a binary package must be signed by a Debian developper. If your package is sponsored, it will probably be rebuilt. This rule is [http://lists.backports.org/lurker/message/20060902.131426.a3bad472.en.html strictly enforced], even if you had your GPG key signed and have been around for months.<br />
* If this is the first time your package is backported, it will appear at http://www.backports.org/debian/new.html , and wait for a manual review. Norbert Tretkowski (nobse) or Alexander Wirt (formorer) will do so in a matter of days/weeks. eg: evince was accepted after 1 week, ettercap after 1 day - but I don't know the details.<br />
* An autobuilder builds your package for other architectures if available.<br />
<br />
== Test your backport ==<br />
<br />
First, install and run your backport on a Stable system.<br />
<br />
You can also check what changes you introduced using <code>interdiff</code> (from package <code>patchutils</code>):<br />
gunzip par2cmdline_0.4-8.diff.gz<br />
gunzip par2cmdline_0.4-8~bpo.1.diff.gz<br />
interdiff par2cmdline_0.4-8.diff par2cmdline_0.4-8~bpo.1.diff | less<br />
<br />
<code>debdiff</code> will also show you if you mistakenly introduced new files, and will <code>wdiff</code> <code>debian/control</code> (you need to install the <code>wdiff</code> package for that):<br />
aptitude download par2<br />
debdiff par2_0.4-8_i386.deb par2_0.4-8~bpo.1_i386.deb<br />
<br />
Run <code>lintian</code> and <code>linda</code>, two packages test-suites, on your package. If you get errors, check whether they already existed in the original package, or if you introduced them yourself:<br />
linda par2_0.4-8~bpo.1_i386.deb<br />
linda par2_0.4-8_i386.deb<br />
lintian par2_0.4-8~bpo.1_i386.deb<br />
lintian par2_0.4-8_i386.deb<br />
(if your source packages produces several binary packages, specify the .changes instead)<br />
<br />
<code>piuparts</code> is another test suite that actually installs your packages in various ways (instead of inspecting its content), but I have to figure out how to use it accurately for backports.<br />
<br />
== Track your backported packages ==<br />
<br />
After a while, there will be new versions of your backported package in Debian ''testing''.<br />
In this case, either:<br />
* update your backport<br />
* tell backports-users@list.backports.org that you do not intend to do it (lack of time, not using the package anymore, etc.), but that it would be good if someone did<br />
<br />
To be notified of new versions of the package automatically, the simplest way is to subscribe to the PTS (package tracking system).<br />
You can do so from the package developer package (eg. [http://packages.qa.debian.org/dar]).<br />
<br />
Alternatively, you can send an e-mail to pts@qa.debian.org telling:<br />
<br />
Subject: subscribe your_package your@mail.tld<br />
<br />
keyword your_package your@mail.tld = upload-source<br />
quit<br />
<br />
The <code>keyword</code> line tells the BTS to only notify you about new releases. You can check the [http://www.debian.org/doc/developers-reference/ch-resources.en.html#s-pts-commands documentation] to see what other kinds of notification you can receive (bug reports, etc.).<br />
<br />
<br />
[http://people.debian.org/~kobold/ubuntu-diff/bin/ubuntu-diff This script] was recently advertised as a way to track the differences between Ubuntu and Debian packages.<br />
<br />
[https://wiki.ubuntu.com/MultiDistroTools MultiDistroTools] also contains informations in this regard, generating reports like:<br />
* http://tiber.tauware.de/~lucas/versions/<br />
* http://tiber.tauware.de/~lucas/versions/ruby.html<br />
<br />
Such tools should be adaptable for use with backports<->testing.<br />
<br />
<br />
<br />
== Examples ==<br />
<br />
Here are a few sample backports made by Cliss XXI:<br />
* [[Backport dar]]: simple<br />
* [[Backport ettercap]]: more on decrypting version numbers<br />
* [[Backport wireless-tools]]: debhelper and some tricks<br />
* [[Backport Evince]]: more complicated<br />
* [[Backport hplip]]: dependencies and python policy<br />
* [[Backport GCJ]]: in progress, would be useful for OOo2 Base<br />
<br />
== Links ==<br />
<br />
=== Documentation ===<br />
<br />
* A high-level HOWTO: [http://www.dannf.org/docs/backporting-debs.txt A Heuristic-based Process for Backporting Debs]<br />
* [http://www.inittab.de/slides/backporting.pdf Slides] (in German :/) from backports.org founder. Even if you don't grasp German, have a look at the mentioned commands.<br />
* [http://wiki.debian.org/Backports Backports - Debian Wiki]: some procedures to follow when uploading at backports.org. Policies are not explained, though.<br />
<br />
=== Tools ===<br />
* [http://julien.danjou.info/article-apt-build.html apt-build]: this tool might ease backports. To dig out.<br />
* [http://familiasanchez.net/~roberto/howtos/debcustomize Debian Package Customization HOWTO]: a backports is a form of customization<br />
<br />
=== Packages information ===<br />
<br />
* [http://www.backports.org/~formorer/ Package uploads]: who uploaded what at bpo<br />
* http://backports.buildd.net/: Backport's autobuilder homepage (if I got it right, it's the same than Debian experimental).<br />
<br />
=== Other pages at doc.cliss21.org ===<br />
<br />
(French):<br />
* [[Compatibilité binaire]]: pourquoi les exécutables d'une distribution ne fonctionnent pas sur une autre?<br />
<br />
== Note ==<br />
<br />
I put this documentation here because I'd rather publish it in a wiki where subscription or moderation is not required. Feel free to spread it though :)<br />
<br />
There're some bits of French left on this page, from the early version of the document. Feel free to translate those.<br />
<br />
As the only copyright holder of this documentation, and to avoid any troll, this documentation is dual-licensed GFDL and GNU GPL, current versions or later.</div>82.238.35.175https://doc.cliss21.com/index.php?title=Backports&diff=1494Backports2006-10-21T13:47:36Z<p>82.238.35.175 : /* Links */</p>
<hr />
<div>== Definition ==<br />
<br />
A backport is a Debian package that is recompiled for an earlier version of the distribution. For example, there is a backport from the latest version of KDE [http://debian-unofficial.org/backports.html] that was compiled for ''Sarge'', based on packages originally meant for ''Etch''.<br />
<br />
Un ''backport'', c'est un paquet Debian recompilé pour une version précédente de la distribution. Par exemple, il y a un backport de la dernière version de KDE [http://debian-unofficial.org/backports.html] compilé pour ''Sarge'', à partir des paquets initialement prévue pour ''Etch''.<br />
<br />
== Motivations ==<br />
<br />
This recompilation is necessary for several reasons:<br />
* The packages dependencies change so as to take the evolution of the rest of the system into account; in our case, we'll change those dependencies to use earlier versions.<br />
* Binary compatibility issues (French: [[Compatibilité binaire]])<br />
<br />
== Où trouver des backports ==<br />
<br />
[http://backports.org backports.org] est la référence en la matière.<br />
<br />
Il y a également des dépôts de paquets plus spécialisés, mais ceux-ci ne sont pas toujours très attentifs aux licences, et vous pouvez récupérer des composants non-libres :/<br />
<br />
[http://apt-get.org/ apt-get.org] fournit une liste de ces dépôts, à la fois ceux qui contiennent des composants non inclus dans Debian pour diverses raisons, et ceux qui fournissent des backports proprement dit.<br />
<br />
== Using backports.org ==<br />
<br />
Add the following line in your <code>/etc/apt/sources.list</code>:<br />
deb http://www.backports.org/debian sarge-backports main<br />
<br />
Then install backported packages using:<br />
aptitude -t sarge-backports install BackportedPackage<br />
<br />
(Before, you had to configure ''pinning'' (packages priorities), but this is<br />
[http://lists.backports.org/lurker/message/20060814.093117.ab4c6b26.en.html no longer necessary])<br />
<br />
* [http://backports.org/dokuwiki/doku.php?id=instructions Official instructions]<br />
<br />
Note: it is not recommended to install all backports at once. Instead you should select only the packages that you need. Unlike in full, consistent Debian distros, each backport is tested individually against the Debian stable version, so they might conflict with each others - but they still share common backported dependencies.<br />
<br />
== backports.org GPG key ==<br />
<br />
After <code>apt-get update</code>, I get:<br />
W: GPG error: http://localhost sarge-backports Release: Les signatures suivantes<br />
n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKE Y EA8E8B2116BA136C<br />
<br />
So I need to import that key from a keyserver:<br />
$ gpg --recv-keys EA8E8B2116BA136C<br />
gpg: le porte-clés `/root/.gnupg/secring.gpg` a été créé<br />
gpg: requête de la clé 16BA136C du serveur hkp subkeys.pgp.net<br />
gpg: /root/.gnupg/trustdb.gpg: base de confiance créée<br />
gpg: clé 16BA136C: clé publique « Backports.org Archive Key <ftp-master@backport s.org> » importée<br />
gpg: aucune clé de confiance ultime n'a été trouvée<br />
gpg: Quantité totale traitée: 1<br />
gpg: importée: 1<br />
<br />
and tell apt about it:<br />
$ gpg --export EA8E8B2116BA136C | apt-key add -<br />
OK<br />
<br />
== HOWTO backport? ==<br />
<br />
Some general considerations:<br />
<br />
=== Config ===<br />
<br />
* debootstrap<br />
* basic compilation tools: <code>aptitude install build-essential</code><br />
* sources.list:<br />
##<br />
# Stable and backports repositories<br />
##<br />
deb http://ftp.fr.debian.org/debian stable main<br />
deb http://security.debian.org/debian-security stable/updates main<br />
deb http://www.backports.org/debian/ sarge-backports main<br />
deb-src http://ftp.fr.debian.org/debian stable main<br />
deb-src http://security.debian.org/debian-security stable/updates main<br />
deb-src http://backports.org/debian sarge-backports main<br />
<br />
##<br />
# Testing and unstable repositories<br />
##<br />
<br />
# Binaries - uncomment if you need to test 'aptitude install'<br />
#deb http://ftp.fr.debian.org/debian testing main<br />
#deb http://ftp.fr.debian.org/debian unstable main<br />
<br />
# Sources - uncomment the one you're backporting from<br />
#deb-src http://ftp.fr.debian.org/debian testing main<br />
deb-src http://ftp.fr.debian.org/debian unstable main<br />
<br />
##<br />
# backports in progress<br />
##<br />
deb file:///usr/src/repo ./<br />
<br />
* /etc/apt/preferences:<br />
Package: *<br />
Pin: release a=testing<br />
Pin-Priority: -1<br />
<br />
Package: *<br />
Pin: release a=unstable<br />
Pin-Priority: -1<br />
<br />
* Vital packages (apt-src, apt-ftparchive, dch):<br />
aptitude install apt-src apt-utils devscripts<br />
<br />
* Environment variables for Debian tools, in my <code>~/.bash_profile</code> (TODO: not taken into account in my Sarge):<br />
export DEBEMAIL="beuc@beuc.net" <br />
export DEBFULLNAME="Sylvain Beucler"<br />
export EDITOR="emacs"<br />
<br />
* <code>debsign</code> GPG configuration, if signing packages is needed, in my <code>~/.devscripts</code>:<br />
DEBSIGN_KEYID="81704B93"<br />
DEBSIGN_PROGRAM="gpg --use-agent"<br />
DEBSIGN_SIGNLIKE="gpg"<br />
<br />
=== To search for a missing dependency ===<br />
<br />
In a vanilla install, sarge and backports in sources.list:<br />
aptitude search keyword # search package whose name contain 'keyword'<br />
apt-cache policy packagename # check what versions are available<br />
<br />
=== Testing the build-deps ===<br />
<br />
apt-get build-dep packagename<br />
<br />
will download the missing dependencies, if available, and report the first missing one otherwise.<br />
<br />
You can alter the build-dep during the creation of the backport, to test whether a modified dependencies list does the trick. <code>apt-get build-dep</code> uses the plain-text <code>/var/lib/apt/lists/ftp.[mirror].debian.org_debian_dists_[distro]_[component]_source_Sources</code> file. You can go quick&dirty and alter that file :) I do not know about a "clean" solution (like feeding <code>apt-get build-dep</code> directly with a <code>debian/control</code> file). You then can test your backported dependencies with:<br />
apt-get -t sarge-backports build-dep packagename<br />
<br />
You may also be interested in <code>dpkg-checkbuilddeps</code>: it reports packages that are not installed,<br />
though it doesn't tell you whether the build _could_ be installed or not, nor which packages exactly are missing.<br />
<br />
=== Making the newly built dependencies available to apt ===<br />
<br />
cd /usr/src<br />
mkdir repo<br />
\mv *-*~bpo.*.deb *-*~bpo.*.udeb *-*~bpo.*.changes *-*~bpo.*.diff.gz *-*~bpo.*.dsc repo/<br />
ln -f *.orig.tar.gz repo/<br />
cd repo<br />
apt-ftparchive packages . | gzip -c > Packages.gz<br />
apt-ftparchive sources . | gzip -c > Sources.gz<br />
cd ..<br />
#echo "deb file:///usr/src/repo ./" >> /etc/apt/sources.list<br />
<br />
There's probably a cleaner way to do this using [http://wiki.debian.org/HowToSetupADebianRepository more comprehensive tools] but that does the trick for now.<br />
<br />
TODO: this doesn't support native packages (w/o .orig.tar.gz)<br />
<br />
=== Don't's ===<br />
<br />
Don't <code>aptitude -t sarge-backports install debhelper</code> blindly.<br />
This will include new helper scripts that may be copied into your packages' postinst/prerm/etc.<br />
This is being [http://lists.backports.org/lurker/message/20060830.124936.32b7cb6f.en.html discussed].<br />
I had to stick to v4 when backporting evince.<br />
<br />
Don't use <code>apt-src build</code>, since it doesn't care about sources packages, unless you configure <code>APT::Src::BuildCommand</code> accordingly (without the <code>-b</code> option for dpkg-buildpackage). Using <code>debuild -us -uc</code> directly worked well for me.<br />
<br />
=== Upload ===<br />
<br />
http://backports.org/contribute.html<br />
<br />
Most commonly, upload your files (the contents of <code>repo/</code>) somewhere and post about it on backports-users@lists.backports.org. Make sure you included a description of what you did in the <code>debian/changelog</code>.<br />
<br />
The page says: ''Our requirements aren't that high. You need to have a gpg key in the official Debian keyring.'' Don't get mistaken: only "Debian developpers" get their gpg keys in the keyring, and becoming one is a [https://nm.debian.org/ months-long process]. However it is very easy to find somebody on the list who will upload your package.<br />
<br />
== Workflow ==<br />
<br />
* Your package hits ''testing''. backports.org aims at providing a smooth transition between the current Debian ''stable'' release and the next one; they don't consider safe to use an ''unstable'' package because if may not enter the next stable (while a ''testing'' package should) [http://lists.backports.org/lurker/message/20060614.173239.0d83eace.en.html]. Fortunately there has been some [http://lists.backports.org/lurker/message/20060630.114154.8e80d282.en.html exceptions].<br />
* You backport the package.<br />
* You test the package. It takes time to upload a package to backports.org, so you'd better send a perfect package from the start.<br />
* You send the package to an authorized member (who will ''sponsor'' it), or you upload directly at ftp://backports.org if you have the privileges (requires being part of the Debian GPG keyring)<br />
* In any case, a binary package must be signed by a Debian developper. If your package is sponsored, it will probably be rebuilt. This rule is [http://lists.backports.org/lurker/message/20060902.131426.a3bad472.en.html strictly enforced], even if you had your GPG key signed and have been around for months.<br />
* If this is the first time your package is backported, it will appear at http://www.backports.org/debian/new.html , and wait for a manual review. Norbert Tretkowski (nobse) or Alexander Wirt (formorer) will do so in a matter of days/weeks. eg: evince was accepted after 1 week, ettercap after 1 day - but I don't know the details.<br />
* An autobuilder builds your package for other architectures if available.<br />
<br />
== Test your backport ==<br />
<br />
First, install and run your backport on a Stable system.<br />
<br />
You can also check what changes you introduced using <code>interdiff</code> (from package <code>patchutils</code>):<br />
gunzip par2cmdline_0.4-8.diff.gz<br />
gunzip par2cmdline_0.4-8~bpo.1.diff.gz<br />
interdiff par2cmdline_0.4-8.diff par2cmdline_0.4-8~bpo.1.diff | less<br />
<br />
<code>debdiff</code> will also show you if you mistakenly introduced new files, and will <code>wdiff</code> <code>debian/control</code> (you need to install the <code>wdiff</code> package for that):<br />
aptitude download par2<br />
debdiff par2_0.4-8_i386.deb par2_0.4-8~bpo.1_i386.deb<br />
<br />
Run <code>lintian</code> and <code>linda</code>, two packages test-suites, on your package. If you get errors, check whether they already existed in the original package, or if you introduced them yourself:<br />
linda par2_0.4-8~bpo.1_i386.deb<br />
linda par2_0.4-8_i386.deb<br />
lintian par2_0.4-8~bpo.1_i386.deb<br />
lintian par2_0.4-8_i386.deb<br />
(if your source packages produces several binary packages, specify the .changes instead)<br />
<br />
<code>piuparts</code> is another test suite that actually installs your packages in various ways (instead of inspecting its content), but I have to figure out how to use it accurately for backports.<br />
<br />
== Track your backported packages ==<br />
<br />
After a while, there will be new versions of your backported package in Debian ''testing''.<br />
In this case, either:<br />
* update your backport<br />
* tell backports-users@list.backports.org that you do not intend to do it (lack of time, not using the package anymore, etc.), but that it would be good if someone did<br />
<br />
To be notified of new versions of the package automatically, the simplest way is to subscribe to the PTS (package tracking system).<br />
You can do so from the package developer package (eg. [http://packages.qa.debian.org/dar]).<br />
<br />
Alternatively, you can send an e-mail to pts@qa.debian.org telling:<br />
<br />
Subject: subscribe your_package your@mail.tld<br />
<br />
keyword your_package your@mail.tld = upload-source<br />
quit<br />
<br />
The <code>keyword</code> line tells the BTS to only notify you about new releases. You can check the [http://www.debian.org/doc/developers-reference/ch-resources.en.html#s-pts-commands documentation] to see what other kinds of notification you can receive (bug reports, etc.).<br />
<br />
<br />
[http://people.debian.org/~kobold/ubuntu-diff/bin/ubuntu-diff This script] was recently advertised as a way to track the differences between Ubuntu and Debian packages.<br />
<br />
[https://wiki.ubuntu.com/MultiDistroTools MultiDistroTools] also contains informations in this regard, generating reports like:<br />
* http://tiber.tauware.de/~lucas/versions/<br />
* http://tiber.tauware.de/~lucas/versions/ruby.html<br />
<br />
Such tools should be adaptable for use with backports<->testing.<br />
<br />
<br />
<br />
== Examples ==<br />
<br />
Here are a few sample backports made by Cliss XXI:<br />
* [[Backport dar]]: simple<br />
* [[Backport ettercap]]: more on decrypting version numbers<br />
* [[Backport wireless-tools]]: debhelper and some tricks<br />
* [[Backport Evince]]: more complicated<br />
* [[Backport hplip]]: dependencies and python policy<br />
* [[Backport GCJ]]: in progress, would be useful for OOo2 Base<br />
<br />
== Links ==<br />
<br />
=== Documentation ===<br />
<br />
* A high-level HOWTO: [http://www.dannf.org/docs/backporting-debs.txt A Heuristic-based Process for Backporting Debs]<br />
* [http://www.inittab.de/slides/backporting.pdf Slides] (in German :/) from backports.org founder. Even if you don't grasp German, have a look at the mentioned commands.<br />
* [http://wiki.debian.org/Backports Backports - Debian Wiki]: some procedures to follow when uploading at backports.org. Policies are not explained, though.<br />
<br />
=== Tools ===<br />
* [http://julien.danjou.info/article-apt-build.html apt-build]: this tool might ease backports. To dig out.<br />
* [http://familiasanchez.net/~roberto/howtos/debcustomize Debian Package Customization HOWTO]: a backports is a form of customization<br />
<br />
=== Packages information ===<br />
<br />
* [http://www.backports.org/~formorer/ Package uploads]: who uploaded what at bpo<br />
* http://backports.buildd.net/: Backport's autobuilder homepage (if I got it right, it's the same than Debian experimental).<br />
<br />
=== Other pages at doc.cliss21.org ===<br />
<br />
(French):<br />
* [[Compatibilité binaire]]: pourquoi les exécutables d'une distribution ne fonctionnent pas sur une autre?<br />
<br />
== Note ==<br />
<br />
I put this documentation here because I'd rather publish it in a wiki where subscription or moderation is not required. Feel free to spread it though :)<br />
<br />
There're some bits of French left on this page, from the early version of the document. Feel free to translate those.</div>82.238.35.175https://doc.cliss21.com/index.php?title=Backports&diff=1493Backports2006-10-21T13:46:24Z<p>82.238.35.175 : /* Documentation */</p>
<hr />
<div>== Definition ==<br />
<br />
A backport is a Debian package that is recompiled for an earlier version of the distribution. For example, there is a backport from the latest version of KDE [http://debian-unofficial.org/backports.html] that was compiled for ''Sarge'', based on packages originally meant for ''Etch''.<br />
<br />
Un ''backport'', c'est un paquet Debian recompilé pour une version précédente de la distribution. Par exemple, il y a un backport de la dernière version de KDE [http://debian-unofficial.org/backports.html] compilé pour ''Sarge'', à partir des paquets initialement prévue pour ''Etch''.<br />
<br />
== Motivations ==<br />
<br />
This recompilation is necessary for several reasons:<br />
* The packages dependencies change so as to take the evolution of the rest of the system into account; in our case, we'll change those dependencies to use earlier versions.<br />
* Binary compatibility issues (French: [[Compatibilité binaire]])<br />
<br />
== Où trouver des backports ==<br />
<br />
[http://backports.org backports.org] est la référence en la matière.<br />
<br />
Il y a également des dépôts de paquets plus spécialisés, mais ceux-ci ne sont pas toujours très attentifs aux licences, et vous pouvez récupérer des composants non-libres :/<br />
<br />
[http://apt-get.org/ apt-get.org] fournit une liste de ces dépôts, à la fois ceux qui contiennent des composants non inclus dans Debian pour diverses raisons, et ceux qui fournissent des backports proprement dit.<br />
<br />
== Using backports.org ==<br />
<br />
Add the following line in your <code>/etc/apt/sources.list</code>:<br />
deb http://www.backports.org/debian sarge-backports main<br />
<br />
Then install backported packages using:<br />
aptitude -t sarge-backports install BackportedPackage<br />
<br />
(Before, you had to configure ''pinning'' (packages priorities), but this is<br />
[http://lists.backports.org/lurker/message/20060814.093117.ab4c6b26.en.html no longer necessary])<br />
<br />
* [http://backports.org/dokuwiki/doku.php?id=instructions Official instructions]<br />
<br />
Note: it is not recommended to install all backports at once. Instead you should select only the packages that you need. Unlike in full, consistent Debian distros, each backport is tested individually against the Debian stable version, so they might conflict with each others - but they still share common backported dependencies.<br />
<br />
== backports.org GPG key ==<br />
<br />
After <code>apt-get update</code>, I get:<br />
W: GPG error: http://localhost sarge-backports Release: Les signatures suivantes<br />
n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKE Y EA8E8B2116BA136C<br />
<br />
So I need to import that key from a keyserver:<br />
$ gpg --recv-keys EA8E8B2116BA136C<br />
gpg: le porte-clés `/root/.gnupg/secring.gpg` a été créé<br />
gpg: requête de la clé 16BA136C du serveur hkp subkeys.pgp.net<br />
gpg: /root/.gnupg/trustdb.gpg: base de confiance créée<br />
gpg: clé 16BA136C: clé publique « Backports.org Archive Key <ftp-master@backport s.org> » importée<br />
gpg: aucune clé de confiance ultime n'a été trouvée<br />
gpg: Quantité totale traitée: 1<br />
gpg: importée: 1<br />
<br />
and tell apt about it:<br />
$ gpg --export EA8E8B2116BA136C | apt-key add -<br />
OK<br />
<br />
== HOWTO backport? ==<br />
<br />
Some general considerations:<br />
<br />
=== Config ===<br />
<br />
* debootstrap<br />
* basic compilation tools: <code>aptitude install build-essential</code><br />
* sources.list:<br />
##<br />
# Stable and backports repositories<br />
##<br />
deb http://ftp.fr.debian.org/debian stable main<br />
deb http://security.debian.org/debian-security stable/updates main<br />
deb http://www.backports.org/debian/ sarge-backports main<br />
deb-src http://ftp.fr.debian.org/debian stable main<br />
deb-src http://security.debian.org/debian-security stable/updates main<br />
deb-src http://backports.org/debian sarge-backports main<br />
<br />
##<br />
# Testing and unstable repositories<br />
##<br />
<br />
# Binaries - uncomment if you need to test 'aptitude install'<br />
#deb http://ftp.fr.debian.org/debian testing main<br />
#deb http://ftp.fr.debian.org/debian unstable main<br />
<br />
# Sources - uncomment the one you're backporting from<br />
#deb-src http://ftp.fr.debian.org/debian testing main<br />
deb-src http://ftp.fr.debian.org/debian unstable main<br />
<br />
##<br />
# backports in progress<br />
##<br />
deb file:///usr/src/repo ./<br />
<br />
* /etc/apt/preferences:<br />
Package: *<br />
Pin: release a=testing<br />
Pin-Priority: -1<br />
<br />
Package: *<br />
Pin: release a=unstable<br />
Pin-Priority: -1<br />
<br />
* Vital packages (apt-src, apt-ftparchive, dch):<br />
aptitude install apt-src apt-utils devscripts<br />
<br />
* Environment variables for Debian tools, in my <code>~/.bash_profile</code> (TODO: not taken into account in my Sarge):<br />
export DEBEMAIL="beuc@beuc.net" <br />
export DEBFULLNAME="Sylvain Beucler"<br />
export EDITOR="emacs"<br />
<br />
* <code>debsign</code> GPG configuration, if signing packages is needed, in my <code>~/.devscripts</code>:<br />
DEBSIGN_KEYID="81704B93"<br />
DEBSIGN_PROGRAM="gpg --use-agent"<br />
DEBSIGN_SIGNLIKE="gpg"<br />
<br />
=== To search for a missing dependency ===<br />
<br />
In a vanilla install, sarge and backports in sources.list:<br />
aptitude search keyword # search package whose name contain 'keyword'<br />
apt-cache policy packagename # check what versions are available<br />
<br />
=== Testing the build-deps ===<br />
<br />
apt-get build-dep packagename<br />
<br />
will download the missing dependencies, if available, and report the first missing one otherwise.<br />
<br />
You can alter the build-dep during the creation of the backport, to test whether a modified dependencies list does the trick. <code>apt-get build-dep</code> uses the plain-text <code>/var/lib/apt/lists/ftp.[mirror].debian.org_debian_dists_[distro]_[component]_source_Sources</code> file. You can go quick&dirty and alter that file :) I do not know about a "clean" solution (like feeding <code>apt-get build-dep</code> directly with a <code>debian/control</code> file). You then can test your backported dependencies with:<br />
apt-get -t sarge-backports build-dep packagename<br />
<br />
You may also be interested in <code>dpkg-checkbuilddeps</code>: it reports packages that are not installed,<br />
though it doesn't tell you whether the build _could_ be installed or not, nor which packages exactly are missing.<br />
<br />
=== Making the newly built dependencies available to apt ===<br />
<br />
cd /usr/src<br />
mkdir repo<br />
\mv *-*~bpo.*.deb *-*~bpo.*.udeb *-*~bpo.*.changes *-*~bpo.*.diff.gz *-*~bpo.*.dsc repo/<br />
ln -f *.orig.tar.gz repo/<br />
cd repo<br />
apt-ftparchive packages . | gzip -c > Packages.gz<br />
apt-ftparchive sources . | gzip -c > Sources.gz<br />
cd ..<br />
#echo "deb file:///usr/src/repo ./" >> /etc/apt/sources.list<br />
<br />
There's probably a cleaner way to do this using [http://wiki.debian.org/HowToSetupADebianRepository more comprehensive tools] but that does the trick for now.<br />
<br />
TODO: this doesn't support native packages (w/o .orig.tar.gz)<br />
<br />
=== Don't's ===<br />
<br />
Don't <code>aptitude -t sarge-backports install debhelper</code> blindly.<br />
This will include new helper scripts that may be copied into your packages' postinst/prerm/etc.<br />
This is being [http://lists.backports.org/lurker/message/20060830.124936.32b7cb6f.en.html discussed].<br />
I had to stick to v4 when backporting evince.<br />
<br />
Don't use <code>apt-src build</code>, since it doesn't care about sources packages, unless you configure <code>APT::Src::BuildCommand</code> accordingly (without the <code>-b</code> option for dpkg-buildpackage). Using <code>debuild -us -uc</code> directly worked well for me.<br />
<br />
=== Upload ===<br />
<br />
http://backports.org/contribute.html<br />
<br />
Most commonly, upload your files (the contents of <code>repo/</code>) somewhere and post about it on backports-users@lists.backports.org. Make sure you included a description of what you did in the <code>debian/changelog</code>.<br />
<br />
The page says: ''Our requirements aren't that high. You need to have a gpg key in the official Debian keyring.'' Don't get mistaken: only "Debian developpers" get their gpg keys in the keyring, and becoming one is a [https://nm.debian.org/ months-long process]. However it is very easy to find somebody on the list who will upload your package.<br />
<br />
== Workflow ==<br />
<br />
* Your package hits ''testing''. backports.org aims at providing a smooth transition between the current Debian ''stable'' release and the next one; they don't consider safe to use an ''unstable'' package because if may not enter the next stable (while a ''testing'' package should) [http://lists.backports.org/lurker/message/20060614.173239.0d83eace.en.html]. Fortunately there has been some [http://lists.backports.org/lurker/message/20060630.114154.8e80d282.en.html exceptions].<br />
* You backport the package.<br />
* You test the package. It takes time to upload a package to backports.org, so you'd better send a perfect package from the start.<br />
* You send the package to an authorized member (who will ''sponsor'' it), or you upload directly at ftp://backports.org if you have the privileges (requires being part of the Debian GPG keyring)<br />
* In any case, a binary package must be signed by a Debian developper. If your package is sponsored, it will probably be rebuilt. This rule is [http://lists.backports.org/lurker/message/20060902.131426.a3bad472.en.html strictly enforced], even if you had your GPG key signed and have been around for months.<br />
* If this is the first time your package is backported, it will appear at http://www.backports.org/debian/new.html , and wait for a manual review. Norbert Tretkowski (nobse) or Alexander Wirt (formorer) will do so in a matter of days/weeks. eg: evince was accepted after 1 week, ettercap after 1 day - but I don't know the details.<br />
* An autobuilder builds your package for other architectures if available.<br />
<br />
== Test your backport ==<br />
<br />
First, install and run your backport on a Stable system.<br />
<br />
You can also check what changes you introduced using <code>interdiff</code> (from package <code>patchutils</code>):<br />
gunzip par2cmdline_0.4-8.diff.gz<br />
gunzip par2cmdline_0.4-8~bpo.1.diff.gz<br />
interdiff par2cmdline_0.4-8.diff par2cmdline_0.4-8~bpo.1.diff | less<br />
<br />
<code>debdiff</code> will also show you if you mistakenly introduced new files, and will <code>wdiff</code> <code>debian/control</code> (you need to install the <code>wdiff</code> package for that):<br />
aptitude download par2<br />
debdiff par2_0.4-8_i386.deb par2_0.4-8~bpo.1_i386.deb<br />
<br />
Run <code>lintian</code> and <code>linda</code>, two packages test-suites, on your package. If you get errors, check whether they already existed in the original package, or if you introduced them yourself:<br />
linda par2_0.4-8~bpo.1_i386.deb<br />
linda par2_0.4-8_i386.deb<br />
lintian par2_0.4-8~bpo.1_i386.deb<br />
lintian par2_0.4-8_i386.deb<br />
(if your source packages produces several binary packages, specify the .changes instead)<br />
<br />
<code>piuparts</code> is another test suite that actually installs your packages in various ways (instead of inspecting its content), but I have to figure out how to use it accurately for backports.<br />
<br />
== Track your backported packages ==<br />
<br />
After a while, there will be new versions of your backported package in Debian ''testing''.<br />
In this case, either:<br />
* update your backport<br />
* tell backports-users@list.backports.org that you do not intend to do it (lack of time, not using the package anymore, etc.), but that it would be good if someone did<br />
<br />
To be notified of new versions of the package automatically, the simplest way is to subscribe to the PTS (package tracking system).<br />
You can do so from the package developer package (eg. [http://packages.qa.debian.org/dar]).<br />
<br />
Alternatively, you can send an e-mail to pts@qa.debian.org telling:<br />
<br />
Subject: subscribe your_package your@mail.tld<br />
<br />
keyword your_package your@mail.tld = upload-source<br />
quit<br />
<br />
The <code>keyword</code> line tells the BTS to only notify you about new releases. You can check the [http://www.debian.org/doc/developers-reference/ch-resources.en.html#s-pts-commands documentation] to see what other kinds of notification you can receive (bug reports, etc.).<br />
<br />
<br />
[http://people.debian.org/~kobold/ubuntu-diff/bin/ubuntu-diff This script] was recently advertised as a way to track the differences between Ubuntu and Debian packages.<br />
<br />
[https://wiki.ubuntu.com/MultiDistroTools MultiDistroTools] also contains informations in this regard, generating reports like:<br />
* http://tiber.tauware.de/~lucas/versions/<br />
* http://tiber.tauware.de/~lucas/versions/ruby.html<br />
<br />
Such tools should be adaptable for use with backports<->testing.<br />
<br />
<br />
<br />
== Examples ==<br />
<br />
Here are a few sample backports made by Cliss XXI:<br />
* [[Backport dar]]: simple<br />
* [[Backport ettercap]]: more on decrypting version numbers<br />
* [[Backport wireless-tools]]: debhelper and some tricks<br />
* [[Backport Evince]]: more complicated<br />
* [[Backport hplip]]: dependencies and python policy<br />
* [[Backport GCJ]]: in progress, would be useful for OOo2 Base<br />
<br />
== Links ==<br />
<br />
* http://backports.buildd.net/: Backport's autobuilder homepage (if I got it right, it's the same than Debian experimental).<br />
<br />
Other pages at doc.cliss21.org (French):<br />
<br />
* [[Compatibilité binaire]]: pourquoi les exécutables d'une distribution ne fonctionnent pas sur une autre?<br />
<br />
== Note ==<br />
<br />
I put this documentation here because I'd rather publish it in a wiki where subscription or moderation is not required. Feel free to spread it though :)<br />
<br />
There're some bits of French left on this page, from the early version of the document. Feel free to translate those.</div>82.238.35.175https://doc.cliss21.com/index.php?title=Backport_dar&diff=1619Backport dar2006-10-21T13:43:36Z<p>82.238.35.175 : /* Versioning */</p>
<hr />
<div>== Versioning ==<br />
<br />
Backporting dar is quite simple - you just need to recompile the Etch version in a Sarge environment. It's a nice occasion to cover the very basics.<br />
<br />
You need to modify <code>debian/changelog</code> though. Enter the <code>dar-2.3.0</code> directory, and type:<br />
dch -i<br />
<br />
If you want to use another editor, you can also:<br />
EDITOR=emacs dch -i<br />
<br />
madduck suggest to use the following command to generate the initial changelog entry template (didn't try out yet):<br />
dch -D sarge-backports -b -v$(dpkg-parsechangelog | sed -ne 's,^Version: ,,p')~bpo.1 -- Rebuilt for sarge.<br />
<br />
Here's my final changelog entry:<br />
dar (2.3.0-5~bpo.1) sarge-backports; urgency=low<br />
<br />
* Rebuild for Debian Backports <http://www.backports.org/><br />
(new version adds support for extended attributes)<br />
<br />
-- Sylvain Beucler <beuc@beuc.net> Thu, 14 Sep 2006 16:37:59 +0200<br />
<br />
<br />
What did I do?<br />
* Changed version according to bpo convention, <code>-debian_version~bpo.1</code>, so:<br />
** the ''testing'' version was: 0.4-7<br />
** <code>dch</code> proposes by default <code>-debian_version+1</code>: 0.4-8<br />
** I use <code>-debian_version~bpo.1</code>: 0.4-7~bpo.1<br />
* Changed distribution from <code>unstable</code> to <code>sarge-backports</code><br />
* Added a terse explanation<br />
* Replaced <code>root <root@sylvain></code> with a real e-mail address.<br />
<br />
<br />
Then, in the <code>dar-2.3.0</code> directory, start the compilation.<br />
debuild -us -uc<br />
<br />
Using the <code>-sa</code> debuild option: not necessary: by default, if the version ends with '0' or '1' (as 'bpo1' does), dpkg-buildpackage uses the existing source release (the .orig.tar.gz file must be present in the parent directory, though).<br />
<br />
== Installation ==<br />
<br />
Now you can test your dar package:<br />
sudo dpkg -i dar_2.3.0-5~bpo.1_i386.deb libdar64-4_2.3.0-5~bpo.1_i386.deb<br />
<br />
<br />
== Check your changes ==<br />
<br />
Check your changes using <code>interdiff</code>:<br />
mkdir tmp<br />
cd tmp<br />
cp ../dar*.diff.gz .<br />
gunzip *<br />
interdiff dar_2.3.0-5.diff dar_2.3.0-5~bpo.1.diff<br />
<br />
If you see some source changes that you didn't do, then your backport is not clean (probably it's a leftover from an incomplete <code>make clean</code>). Usually, just remove the current directory and extract a new clean one using <code>dpkg-source</code>.</div>82.238.35.175