Blogs des ResEleux car les cyborgs sont nos amis.

EuroBSDcon 2011 s'est déroulé au début de ce mois d'octobre. Je viens de finir de mettre en forme mes notes sur les conférences que j'ai suivies.

On y retrouvera en particulier :

• sendmail, history and design, présenté par Eric Allman, dans lequel l'auteur présente l'histoire du MTA qui est encore aujourd'hui le plus utilisé sur Internet, les éléments de design qui ont permis à sendmail de survivre pendant 30 ans, et les élèments malgré lesquels sendmail a survécu pendant 30 ans ;
• Minix 3, ou comment construire un OS fiable, par Herbert Bos : en utilisant des principes systématiques de réduction des privilèges, de séparation des composants, et en acceptant que les composants peuvent crasher mais sont pour la plupart redémarrables ;
• status d'IPv6 dans FreeBSD de Bjoern Zeeb, comment FreeBSD a vécu le World IPv6 Day cette année, les leçons du noyau AF_INET6-only, et ce qui doit arriver dans le futur proche dans un FreeBSD près de chez vous ;
• portage d'OpenBSD vers UltraSPARC T1 et T2 de Mark Kettenis, une session très technique (au cours de laquelle je ne prétendrais pas avoir tout compris), qui décrit dans une première partie les atouts de cette plateforme, et comment OpenBSD est capable de tourner sur cette architecture ;
• NPF, un nouveau pf pour NetBSD 6.0 de Zoltan Arnold Nagy, qui explique pourquoi un nouveau pare-feu est nécessaire et comment NPF a été construit ;
• High Availability STorage in FreeBSD de Pawel Jakub Dawidek, du RAID1 over network, modes de synchronisation, démonstration, performance ;
• testing automatique de NetBSD de Martin Husemann, les composants logiciels mis en œuvre, les bindings dans différents languages, les bugs découverts grâce au testing systématique.

À noter également les slides de quelques développeurs OpenBSD :

• What's new in OpenSSH, de Damien Miller ;
• OpenBSD's New Suspend and Resume Framework ( slides), de Paul Irofti ;
• OpenBSD SCSI Evolution de David Gwynne et Ken Westerback ;
• 10 years of pf, de Ryan McBride et Henning Brauer :
• OpenBSD Update, du même Henning Brauer.

Malheureusement les slides de Claudio Jeker sur MPLS ne sont pas en ligne.

Michael Dexter a parlé de virtualisation dans le monde BSD ( plus de documents). Son exposé avait deux grands axes : une classification des techniques de virtualisation existante, et surtout une présentation de BHyVe, un hyperviseur de type 2 (à la Xen) pour FreeBSD.

Comme ZFS c'est beau, ça rend le poil soyeux et ça permet à l'admin de diminuer sa consommation d'aspirine, j'ai profité de mon changement de Kimsufi pour l'installer en tout ZFS, depuis le boot. Bien sûr, une solution aurait été de laisser l'installation sur / et de ne mettre que les données sur un volume ZFS, mais c'est trop facile, ça. Et puis on garde de l'UFS, c'est so-XX ^ième siècle .

Pour installer en tout ZFS, il doit y avoir au moins trois solutions pour faire cette installation :

• partir du système existant et installé, créer un volume, faire un cp de notre / UFS vers ce volume ZFS, pointer le chargeur de boot vers ce volume ;
• booter depuis le réseau (OVH permet de booter sur un FreeBSD 8.2, yay), et faire l'installation comme cela ;
• booter sur vKVM depuis une ISO.

On est d'accord que le premier, c'est tricher. Chez moi le vKVM perdait régulièrement la connexion, alors j'ai utilisé le boot sur le réseau (le mode rescue-pro).

Let's go.

gpart create -s gpt ad4
gpart add -s 64K -t freebsd-boot ad4
gpart add -s 2G -t freebsd-swap -l swap ad4
glabel label swap ad4p2
gpart add -t freebsd-zfs -l data ad4
glabel label data ad4p3
gpart show

mkdir /root/sets
mount -t tmpfs -o size=300000000 dummy /root/sets
dmesg | tail
=> WARNING: TMPFS is considered to be a highly experimental
   feature in FreeBSD.

cd sets
ftp ftp.fr.freebsd.org
cd pub/FreeBSD/releases/amd64/8.2-RELEASE
!mkdir base kernels
mget base/* kernels/*

mkdir /root/newinstall
zpool create -m /root/newinstall zroot /dev/gpt/data
zpool set bootfs=zroot zroot

zfs create zroot/usr
zfs create zroot/var

zfs list

setenv DESTDIR /root/newinstall
cd /root/sets
cd base ; sh install.sh ; cd ..

cd kernels ; sh install.sh generic ; cd ..
cd /root/newinstall/boot
rm -fr kernel
mv GENERIC kernel

chroot /root/newinstall

echo /dev/label/swap none swap sw 0 0 > /etc/fstab
echo 'zfs_load="YES"' > /boot/loader.conf
echo 'vfs.root.mountfrom="zfs:zroot"' >> /boot/loader.conf

vi /etc/rc.conf

sshd_enable="YES"
ntpdate_enable="YES"
ntpdate_hosts="213.186.33.99"
fsck_y_enable="YES"
named_enable="YES"
ifconfig_nfe0="inet 198.51.100.43/24"
defaultrouter="94.23.42.254"
hostname="foo.example.net"
zfs_enable="YES"

zpool export zroot
zpool import zroot
cp /root/newinstall/boot/pmbr /root/sets
cp /root/newinstall/boot/gptzfsboot /root/sets

zpool export zroot
gpart bootcode -b /root/newinstall/boot/pmbr -p /root/newinstall/boot/gptzfsboot -i 1 ad4
zpool import zroot

zpool set cachefile=/root/newinstall/boot/zfs/zpool.cache

zfs set mountpoint=legacy zroot
zfs set mountpoint=/usr zroot/usr
zfs set mountpoint=/var zroot/var
zpool set bootfs=zroot zroot
zfs unmount -a

zfs snapshot zroot@1 zfs
send zroot@1 | zfs receive zroot/slash
zfs destroy zroot@1

zfs snapshot zroot/usr@1
zfs send zroot/usr@1 | zfs receive zroot/slash/usr
zfs destroy zroot/usr@1

zpool set bootfs=zroot/slash
vi /slash/etc/loader.conf

zfs set canmount=noauto zroot/usr
zfs set mountpoint=/usr zroot/slash/usr

zfs set mountpoint=/whatever zroot
chroot /whatever
rm -fr *
# oups, il y a des fichiers avec l'option schg...
^D
chflags -R noschg /whatever
rm -fr /whatever/*
zfs set mountpoint=none zroot
rmdir /whatever
zfs destroy zroot/usr
reboot

Il arrive d'avoir besoin de se servir de navigateurs avec deux panneaux pour permettre d'y voir plus clair ou de comparer deux folders. Je vais en citer ici 3 différents que j'ai l'habitude d'utiliser, deux graphiques (dont un natif sur l'environnement gnome), et un en console.

Le premier est nautilus, navigateur par défaut sur gnome. On peut ajouter un panneau par affichage > panneau supplémentaire, ou directement par F3.

Le deuxième est emelfm2, qui a la particularité d'intégrer quelques raccourcis pratique en bas (ouvrir un terminal dans le répertoire courant, exécuter en root, ...) et qui intègre également un terminal, parfois bien pratique pour chercher rapidement ce que le navigateur n'affiche pas.

Le dernier, en console, est midnight commander, qui a menu très complet, permettant très simplement de compresser des répertoires et des fichiers, de copier un fichier d'un volet vers l'autre... Attention toutefois, pour quitter, il faut taper sur F10, qui est sur gnome-terminal le raccourci "menu" (il faudra donc penser à désactiver le raccourci F10 via édition > raccourcis clavier.

zsh est très connu pour son système de complétion très poussé. Malheureusement, zsh n'est pas équipé pour gérer les conventions d'appel de tous les outils qu'on peut trouver sur nos babasses. On peut donc être amené à écrire soi-même une méthode de complétion. Ces notes ont été prises à l'occasion de l'écriture d'un fichier de complétion pour ezjail, et les exemples viennent de là.

compdef _gnu_generic foo

compdef _hosts foo

compdef '_files -g "*.h"' foo

fpath=(~/zsh $fpath)

#compdef ezjail-admin

_ezjail () {
    # code de complétion
}

_ezjail "$@"

_ezjail_cmd_create () {
    _arguments -s : \
        "-i[file-based jail]" \
        "-x[jail exists, only update the config]" \
        "-a[restore from archive]:archive:_files" \
        "-c[image type]:imagetype:(bde eli zfs)" \
        "-C[image parameters]:imageparams:" \
        "-s[size of the jail]:jailsize:" \
        ":jail name:" \
        ":comma-separated IP addresses:"
}

_ezjail_cmd_archive () {
    _arguments -s : \
        "-a[archive name]:archive name:" \
        "-d[destination directory]:destination dir:_files -/" \
        "-f[archive the jail even if it is running]" \
        - archiveall \
            "-A[archive all jails]" \
        - somejails \
            "*:jail:_ezjail_stopped_jails"
}

_ezjail () {
    local cmd
    if (( CURRENT > 2)); then
        # déjà un mot complet sur la ligne; sauter à la fonction
        # spécifique à cette sous-commande.
    else
        # on complète la sous-commande
        _values :                                                \
            "archive[create a backup of one or several jails]"   \
            "config[manage specific jails]"                      \
            "console[attach your console to a running jail]"     \
            "create[installs a new jail inside ezjail\'s scope]" \
            "cryptostart[start the encrypted jails]"             \
            "delete[removes a jail from ezjail\'s config]"       \
            "install[create the basejail from binary packages]"  \
            "list[list all jails]"                               \
            "restart[restart a running jail]"                    \
            "restore[create new ezjails from archived versions]" \
            "start[start a jail]"                                \
            "stop[stop a running jail]"                          \
            "update[create or update the basejail from source]"
    fi
}

_ezjail_running_jails () {
    _values : `_ezjail_list_jails running`
}

_ezjail_list_jails () {
    local jailcfgs="/usr/local/etc/ezjail"
    local state=$1
    local j
    ( cd $jailcfgs && echo * ) | while read j; do
        case $state in
        running) [[ -f /var/run/jail_${j}.id ]] && echo $j ;;
        stopped) [[ -f /var/run/jail_${j}.id ]] || echo $j ;;
        *)       echo $j ;;
        esac
    done
}

_ezjail_running_jails () {
    _ezjail_list_jails running
}

_ezjail_list_jails () {
    local jailcfgs="/usr/local/etc/ezjail"
    local state=$1
    local ret=1
    local j
    for j in $jailcfgs/*(:t) ; do
        case $state in
        running) [[ -f /var/run/jail_${j}.id ]] && compadd $j && ret=0 ;;
        stopped) [[ -f /var/run/jail_${j}.id ]] || compadd $j && ret=0 ;;
        *)       compadd $j && ret=0 ;;
        esac
    done
    return $ret
}

Niveau :      
Résumé : tcpdump ssl ; ptrace ; ltrace

Vous attendez la suite de mon article sur ce qui passe par les oreilles d'un android ? Hé bien vous allez attendre encore un peu ...

Lorsque vous récupérez via tcpdump un flux SSL (au hasard du https), il est chiffré et c'est justement l'intérêt du SSL de vous empêcher de lire ce flux.

Mais si si vous maitrisez une des deux extrémités, il devrait être normal que vous puissiez lire ce flux. C'est pourquoi nous allons le faire.

Côté serveur

Dans le cas où vous maitrisez le côté serveur, il suffit d'ouvrir la trace tcpdump (sauvegardée avec l'option -s0 -w file) sous wireshark et de le configurer pour qu'il utilise la clé serveur pour déchiffrer le flux :comme ici et de choisir de suivre le flux ssl au lieu du flux TCP.

C'est simple et efficace.

Côté client

Maintenant si vous êtes côté client sans certificat client, vous êtes coincés. Et c'est là que j'ai une solution à vous proposer.

Il existe plusieurs moyen pour espionner vos processus, tout d'abord vous pouvez créer un wrapper autour de la lib SSL et utiliser LD_PRELOAD pour la charger avant le processus. C'est bien mais difficile à mettre en œuvre, surtout si le processus tourne déjà, je vous laisse explorer cette voie de votre côté.

La deuxième solution est d'utiliser ptrace pour espionner le processus. Techniquement complexe, cette méthode nous est grandement facilitée par l'outil ltrace.

Pour la suite je vais supposer que les services à espionner passent par openssl, mais rien ne vous empêche de faire la même chose avec gnutls.

Espionner un processus

C'est simple :

# vous le lancez directement : 
$  ltrace ma commande
# ou vous espionnez un processus qui tourne déjà 
$ ltrace -p pid

Ça vous montre le fonctionnement, mais c'est aussi illisible qu'un strace.

Espionner le SSL

Ajoutons quelques options pour trier ce fouillis :

$ ltrace -l /usr/lib/libssl.so.0.9.8 -s 20000 -e SSL_read,SSL_write

Et voilà, la liste des appels ! Mais ce n'est pas suffisant.

Ajoutons les lignes suivantes dans /etc/ltrace.conf (ou dans ~/.ltrace.conf) :

int SSL_read(addr,string[retval],int);
int SSL_write(addr,string[arg3],int);

On relance la commande et maintenant nous avons le contenu de la communication en clair.

Mais il y a un petit bug dans ltrace, string[retval] devrait couper les chaines de SSL_read en fonction de la valeur de retour, mails ne le fait pas.

Corrigeons cela avec un petit script de formatage et cette fois nous avons toute la communication en clair !

$ ltrace -l /usr/lib/libssl.so.0.9.8 -s 20000 -e SSL_read,SSL_write -p pid 2> /tmp/trace
$ perl -pe 's/(SSL_read.*?, ")(.*)(".*? )(\d+)$/$1.substr($2,0,$4).$3.$4/e' /tmp/trace | less

Niveau :      
Résumé : debootstrap --foreign ; debian.apk

Android is Not GNU

Maintenant qu'on est root, on peut faire tout ce qu'on veut sur notre android. Mais il faut bien avouer que busybox est assez limitée pour les habitués des systèmes GNU que nous sommes.

C'est pourquoi nous allons mettre un système GNU complet sur notre android. Et de préférence sans influer sur la bonne marche du téléphone.

Pour cela, il faut laisser tourner l'android tel quel, et surtout garder son noyau. Mettre un 2e système sur un noyau qui tourne, on sait faire, dans sa version la plus simple ça s'appelle un chroot, c'est disponible de base et c'est exactement ce dont on a besoin.

Notez que les commandes indiquées ici se basent sur un shell et les commandes fournies par busybox telles qu'installée dans l'article précédent. Vous pouvez vous en passer, mais quelques adaptations seront nécessaires (par exemple -o bind à la place de --bind).

Comment qu'on fait ?

Comment créer un chroot sans se presser ?

Choisissons (au hasard) la distribution debian. Elle nous propose ... wait for it ... un créateur de chroot. Il s'appelle debootstrap.

Seul problème nous ne pouvons pas le lancer directement sur le téléphone. Il faut donc le lancer sur une autre machine. Et à moins d'avoir une machine arm sous le coude, nous ne serons pas sur la bonne architecture.

Heureusement debian est bien structuré et debootstrap a tout prévu. Nous allons le lancer 2 fois. La première fois sur notre machine habituelle :

$  debootstrap --foreign --arch armel wheezy mydebian 

Pour ceux qui n'ont pas debian, sachez qu'il est possible de télécharger et d'exécuter debootstrap sur n'importe quel autre linux.

Et pour ceux qui voudraient essayer une autre méthode, suivez ce lien : http://wiki.debian.org/EmDebian/Cro...

Déplaçons tout ça sur le téléphone :

# toujours sur le pc
$ tar cf debian.tar mydebian 
$ adb push debian.tar /sdcard/debian.tar

Une debian basique est relativement petite, nous devrions pouvoir trouver une place sur le téléphone. Seule contrainte, il faut la déposer sur une partition qui utilise les droits posix (et donc pas sur /sdcard qui est en FAT). J'ai choisi /data/local/tmp

# sur l'android (avec busybox)
$ cd /data/local/tmp
$ tar xf /sdcard/debian.tar 

Profitons-en pour terminer le debootstrap (il faut être root sur l'android et il vaut mieux utiliser les commandes busybox) :

# on prépare le chroot
$ NEW=/data/local/tmp/mydebian
$ mount --bind /dev $NEW/dev
$ mount --bind /proc $NEW/proc
$ mount --bind /sys $NEW/sys
$ mount --bind /dev/pts $NEW/dev/pts
# et on termine debootstrap dedans
export PATH=/bin:/sbin:/usr/bin:/usr/sbin
$ chroot $NEW/debian debootstrap --second-stage

Et voilà !

Vous pouvez compléter par :

• modifier /etc/hostname
• modifier /etc/resolv.conf (nameserver 8.8.8.8 pour utiliser le resolver de google disponible partout)
• ... dites-moi ce que vous avez fait

Comment qu'on l'utilise ?

Maintenant que tout est prêt il faut pouvoir réutiliser ces commandes à tout moment. Pour ma part j'ai fait le petit script suivant qui me permet de rentrer dans le chroot :

ROOT=/data/local/tmp/mydebian
BB=/data/busybox/
if ! ls $ROOT/proc/1 > /dev/null
then
    $BB/mount --bind /dev $ROOT/dev
    $BB/mount --bind /proc $ROOT/proc
    $BB/mount --bind /sys $ROOT/sys
    $BB/mount --bind /dev/pts $ROOT/dev/pts
fi
export PATH=/bin:/sbin:/usr/bin:/usr/sbin
/system/bb/su -c "$BB/chroot $ROOT /bin/bash"

Et pour les gens qui aiment le tout réseau vous pouvez mettre un serveur ssh dans le chroot, ça vous le rendra accessible à distance. Pensez juste à vous connecter au chroot et à le relancer à chaque fois que le téléphone redémarre.

Conclusion

N'oubliez pas, votre téléphone continue de tourner, le chroot n'est qu'un moyen d'avoir accès aux commandes debian (dont apt-get install qui est une commande magnifique pour un android, plus besoin d'installer des machins à la main).

Mais même si votre shell tourne dans un chroot, le noyau reste le même et tous les services en dehors du chroot continuent leur vie comme d'habitude. Cela permet au téléphone de rester un vrai téléphone d'origine. Revenir en arrière consiste à rebooter et à supprimer le répertoire debian.

Amusez-vous bien !

Correction  : j'ai modifié cet article car le système pour rendre le rootage permanent ne fonctionnait pas !

Niveau :      
Résumé : adb shell

Il y a peu je me suis offert un téléphone android. Devinez quoi ... c'est un linux (pas GNU pour une fois, plutôt un dalvik/linux).

Seule ombre au programme, je ne suis pas root dessus. C'est pas très fair play de la part du vendeur sachant que le téléphone m'appartient. Comment faire pour supprimer les applications installées par le fabriquant et qui me cassent les *** à se lancer sans me demander mon avis ?

Ma première mission est donc de devenir root.

Les habitués des OS de bureau auront l'idée de toucher au bootloader pendant qu'il boote. Bonne idée, mais sur une telle machine le bootloader est assez sobre, et plutôt protégé, ne parlons pas du bios. J'ai donc ignoré cette technique pour passer à une méthode plus courantes pour les bidouilleurs de tout poil : exploiter une faille de sécurité.

C'est donc grâce aux failles de sécurité que je vais avoir le droit d'accéder au système de ma propre machine ! Autrement dit, c'est parce que le fabriquant protège mal le système qu'il m'a vendu que mes droits de consommateur sont respectés ...

Les bases

Passons aux bases du téléphone, c'est un linux, mais il ne faut pas s'attendre à avoir tous les outils en ligne de commande auxquels vous êtes habitués. Pour obtenir un shell utilisateur simple (ça vous avez le droit) :

• installer le sdk android (une simple extraction)
• aller dans les paramètres / application / développement et activer le débogage USB
• branchez le câble
• sur le pc dans sdk/platform-tools lancez ./adb devices, votre téléphone doit être listé sinon il y a un problème
• tapez ./adb shell et hop vous êtes sur votre téléphone

Là on est sur un terrain presque connu : un shell, qui tourne avec l'utilisateur shell. Il est limité, mais on s'y fait. Par contre l'arborescence est inhabituelle. Je vous laisse explorer ... Pour mémoire, voici les répertoires à la racine :

/acct        # accounting
/bin         # comme unix
/cache       # contenu temporaire
/config      # vide chez moi
/d           # debug
/data        # /var d'unix
/dev         # comme unix
/etc         # comme unix
/init        # comme unix
/init.rc     # comme unix
/misc        # vide chez moi
/mnt         # comme unix
/proc        # comme unix
/root        # comme unix
/sbin        # comme unix
/sdcard      # partition fat visible aux utilisateurs
/sys         # comme unix
/system      # partition readonly contenant le système android
/usbdisk     # vide chez moi

Les android étant personnalisés par le constructeur, votre version variera nécessairement.

Les failles (pour passer root)

Maintenant on veut passer de shell à root. Il est temps de passer du côté hacking de la force. Ceux qui se sentent l'âme d'un hacker expérimenté peuvent chercher eux-même les failles dans le système. Les autres vont tenter les 2 ou 3 failles connues avec les exploits associés :

• dépôt d'un fichier suid root exécutable, nommé su (il parait que ça marche sur certaines machines, je ne vois pas comment ...)
• exploid
• rageagainstthecage
• psneuter

Le binaire et les source de ces exploits sont disponibles ici.

En général il s'agit de le mettre dans un répertoire inscriptible et permettant les exécutables puis de le lancer. Il semblerait que /data/local/tmp soit disponible un peu partout pour ça.

Dans mon cas (optimus 2X) c'est psneuter qui fonctionne. Pour les autres, dites moi ce qui marche chez vous, je n'ai pas assez d'argent pour tester tous les android :)

$ ./adb push psneuter /data/local/tmp
$ ./adb shell
$ chmod 555 /data/local/tmp/psneuter 
$ /data/local/tmp/psneuter 

On attend, on relance un adb shell et miracle on est root !

Busybox

Maintenant installons un environnement un peu plus user-friendly :

• télécharger busybox
• installer busybox :

$ ./adb push busybox /data/local/tmp
$ ./adb shell
$ chmod 555 /data/local/tmp/busybox
$ mkdir /data/busybox
$ /data/local/tmp/busybox --install
$ export PATH=/data/busybox:$PATH 

Et voila ! Une vraie ligne de commande sur notre petite machine. On peut maintenant découvrir l'os et faire joujou comme on veut.

Rendons tout ça permanent

N'ayant pas trouvé de su compilé qui marche sur mon android et ayant la flemme de compiler moi-même, j'ai fait avec les moyens du bord. Ma méthode d'origine était de mettre en place un shell setuid. Malheureusement, le shell vérifie que sont uid correspond à son euid et si ce n'est pas le cas il revient en arrière. J'ai été abusé par le fait qu'il affiche tout de même un #. Ce comportement, naturel pour un script ne l'est pas nécessairement pour un shell interactif mais c'est un fait.

J'ai donc fait avec les moyens fournis par busybox :

$ mount -o remount,rw /system
$ mkdir /system/bb       # /system/bin/su existe déjà
$ cp /data/busybox/su /system/bb
$ chmod 4550 /system/bb/su
$ echo 'root::0:' > /etc/group # /etc est dans /system
$ echo 'root::0:0:root:/root:/system/bin/sh' > /etc/passwd
$ passwd # si vous voulez un vrai mot de passe
$ mount -o remount,ro  //system # retour à la normale

Après le prochain reboot, pour devenir root (avec un mot de passe) :

$ ./adb shell
$ /system/bin/su

Note : Revenir en arrière est l'affaire de quelques suppression (/data/busybox, /system/bin/su, /etc/passwd et /etc/group). Vous n'avez donc rien fait de violent à votre téléphone, vous avez maitrisé ce que vous avez fait et c'est presque invisible.

Sécurité : A tous ceux qui rootent leur android en passant par une application toute faite, savez-vous ce que fait cette application dans votre dos ? Ne fait-elle pas autre chose que vous faire passer root ? Savez-vous qu'elle installe un binaire su permettant à n'importe quelle application (et pas seulement SuperUser.apk) de passer root si elle connait l'existence de ce binaire ...

On me dit que lors de son premier lancement SuperUser.apk se met lui-même en setuid et enlève le setuid du binaire su. Ce qui du coup vous retire le root avec adb.

PS : Message personnel à Bob Morane, j'ai rien compris à ta suggestion, dans quelle situation y a-t-il des liens qui se chevauchent ?

Niveau :      
Résumé : tcpdump, wireshark

Espionnage

Tout le monde le sait, les téléphones nous espionnent. Mais que communiquent-ils ? A qui communiquent-ils ? Que peut-on y faire ?

Aujourd'hui nous somme armés d'une vraie distribution GNU. Nous pouvons donc utiliser des vrais outils.

# on se connecte sur le téléphone
$ ./adb shell
# mettez votre debian dans ce $ROOT
$ chroot $ROOT
$ apt-get install tcpdump
$ nohup tcpdump -i any -s 0 -w /tmp/dump.`date +"%Y-%d-%m"` &

maintenant déconnectez-vous et laissez tourner toute la journée dans son coin après avoir vérifié qu'il reste de la place sur le disque.

Quelque temps plus tard; :

# sur le téléphone
$ chroot debian
$ pkill tcpdump
# sur le pc
$ ./adb get $ROOT/tmp/dump.*

Analyse

Maintenant revenons à notre poste et regardons ce qui s'est passé. Pour cela on utilise wireshark.

On ouvre le fichier dump et c'est parti :

• on trie par protocole -> LARQ, DNS, ipv6, http, https, ...
• on trie par adresse -> on a la liste de qui communique avec notre machine
• on liste des requêtes dns -> on a les noms des précédents

Ce que j'ai découvert pour l'instant

LARQ (limited automatic repeat request) : protocole utilisé pour la retransmission rapide de frame en cas de perte sur la couche de liaison. Très pratique pour améliorer la qualité des transmissions. On ne trouve quasiment pas d'infos sur le net à ce sujet, à part un brevet.

IPv6 : il est activé par défaut chez moi, ouf

DNS : il semble qu'android utilise le resolver public de google (pratique pour ne pas être embêté par les limitations de l'opérateur et les problèmes de configuration).

Niveau :      
Résumé : /etc/inittab ; /etc/gdm.conf ; /etc/sshd.conf

Pour ceux qui voudraient essayer le parachutisme, je vous le conseille, c'est très fort ! Par contre ça vous empêche d'écrire des articles ...

Vous venez de faire un chroot et vous voulez pouvoir vous connecter dessus comme s'il s'agissait de votre machine locale ?
Pas de panique, c'est tout simple.

Pour cela nous allons regarder 3 méthodes différentes de connexion à votre chroot : le terminal local, ssh et l'environnement graphique. Mais avant tout préparons le chroot à ressembler à une distribution normale.

$ mount --bind /dev $CHROOT_BASE/dev
$ mount --bind /proc $CHROOT_BASE/proc
$ mount --bind /sys $CHROOT_BASE/sys

Terminal local

Pour se connecter en local à votre machine, vous utilisez les consoles disponibles (alt-Fx ou ctrl-alt-Fx si vous êtes en mode graphique). Vous en avez 6 à disposition.

Pour faire simple, nous allons juste faire en sorte que les consoles 4 à 6 redirigent dans le chroot tandis que les 1 à 3 resteront dédiées à la machine principale.

Il suffit de modifier /etc/inittab :

# /etc/inittab
1:2345:respawn:/sbin/getty tty1
2:2345:respawn:/sbin/getty tty2
3:2345:respawn:/sbin/getty tty3
4:2345:respawn:chroot <CHROOT_BASE> /sbin/getty tty4
5:2345:respawn:chroot <CHROOT_BASE> /sbin/getty tty5
6:2345:respawn:chroot <CHROOT_BASE> /sbin/getty tty6

Et là, soit vous redémarrez (bof on n'est pas sous windows) soit vous forcez init à relire sa configuration :

# en root
$ telinit q
$ pkill getty

Et maintenant passez à la console 4 (ctrl-F4) et vous pouvez vous connecter avec votre utilisateur intérieur au chroot.

SSH

Si vous vous connectez à votre machine en ssh, vous pouvez vouloir faire de même pour votre chroot.

Pour ce faire, vous pouvez lancer un service ssh à l'intérieur du chroot. Tout simplement :

$ chroot $CHROOT_BASE
$ apt-get install openssh-server

Par contre vous ne pouvez pas laisser ssh tourner sur le même port que le ssh qui tourne déjà. Utilisez donc un autre port, par exemple le 1022 :

$ vi $CHROOT_BASE/etc/ssh/sshd_config
> Port 1022

Puis lancez ssh dans le chroot :

$ chroot $CHROOT_BASE /etc/init.d/ssh restart

Vous pouvez maintenant vous connecter directement au chroot :

$ ssh -p 1022 user@leserveur.com 

GDM

Maintenant si votre habitude est d'avoir un environnement de bureau comme gnome, il faut faire pareil pour lui.

Tout passe par le login manager. Je prends l'exemple de GDM, mais vous pouvez faire la même chose avec KDM.

Tout d'abord, vous devez avoir un gdm d'installé dans le chroot, donc un environnement graphique minimal.

Une fois installé dans le chroot, par exemple avec :

$ chroot $CHROOT_BASE apt-get install gnome

Éditez le fichier de configuration de gdm $CHROOT_BASE/etc/gdm/gdm.conf :

[daemon]
# ceci devrait être inutile, mais on ne sait jamais
FirstVT=8

[server]
0=Standard device=/dev/console

Relancez gdm dans le chroot :

$ chroot $CHROOT_BASE /etc/init.d/gdm restart

Et voilà, rendez-vous sur la console 8 (ctrl-alt-F8) pour obtenir un login graphique dans le chroot. Sur la console 7 (ctrl-alt-F7) le login original est toujours disponible.

Récemment, j'ai eu à convertir un fichier .wav 32 bits en un fichier mp3. Habituellement j'utilise lame dans une console comme convertisseur mp3, mais avec un wav 32 bits en input ça ne semblait pas marcher :

$ lame file.wav 
Unsupported data format: 0x0003

Allons bon, lame va pas bien, c'est pas grave, on va faire du ogg :

$ oggenc file.wav 
Omition d'un tronçon de type « JUNK » et de longueur 4042
Ouverture avec le module wav : WAV file reader
Encodage de "file.wav" 
         en "file.ogg" 
à la qualité 3,00
        [ 22,7%] [ 0m42s remaining] - ^C

Ça marche avec le ogg, pas la peine d'attendre que ce soit fini. N'empêche que j'ai toujours pas mon mp3 parce que lame ne veut pas traiter du wav 32 bits. Solution de secours : utiliser sox, packagé dans sox :

$ aptitude search sox
(...)
c   sox                             - Swiss army knife of sound processing

Et maintenant passons à la conversion du wav 32 bits en wav 16 bits, à 44,1kHz :

                                              
$ sox file.wav -b 16 ~/tmp/file2.wav rate -I 44100 dither -s
sox WARN dither: dither clipped 23 samples; decrease volume?

Remarquez le dernier message : le fichier son a clippé (saturé) sur 23 échantillons. On va refaire la conversion, mais cette fois-ci en diminuant le gain de 1dB :

$ sox file.wav -b 16 ~/tmp/file2.wav gain -1 rate -I 44100 dither -s
$

Cette fois c'est parfait ! plus qu'à passer une couche de lame et ça marche sans souci.

L'info fait le tour des blogs sur emacs: emacs est utilisé dans Tron 2.0. Plus précisément, eshell est utilisé pour tuer la vidéo que Sam Flynn utilise pour se moquer du conseil d'administration. jtnimoy, derrière les effets spéciaux du film, donne tous les détails.

emacs était déjà visible dans The Social Network, où Big Brother Zuckerberg dit qu'il est « temps de sortir emacs pour modifier un script Perl ».

emacs est une star, vi ne peut vraiment pas en dire autant…

ezjail (sur la documentation duquel votre serviteur a pas mal travaillé ces derniers temps) est un outil d'administration des jails pour FreeBSD. Dirk Engling a ajouté il y a peu la possibilité de mettre à jour le système de base des jails en utilisant FreeBSD Update (c'est dans le CVS, pas encore dans la dernière version d'ezjail). Il est donc possible de passer son serveur FreeBSD avec ses jails d'une version à l'autre sans avoir à compiler quoi que ce soit.

# ezjail-admin update -s 8.1-RELEASE -U

Choisir un projet pour se lancer dans l'agilité peut être un véritable casse-tête. Tous les projets ne sont pas de bons candidats ; il faut trouver un compromis entre taille, durée, criticité et soutien du métier (cf figure ci-dessous). Impossible ? C'est sans doute vrai. Pourtant, un de vos futurs projets peut s'approcher de cet équilibre. Mieux vaut se lancer plutôt que d'attendre éternellement le projet idéal. Voyons comment trouver le barycentre de ces critères.

Durée du projet

Si vous choisissez un projet trop court, les sceptiques vont clamer haut et fort que Scrum ne fonctionne que pour les petits projets. À l'inverse, si vous optez pour un projet trop long, vous risquez de ne pas pouvoir montrer votre succès avant son terme. On compte 9 à 12 mois en moyenne pour un « projet traditionnel » ; où budget et deadline sont souvent dépassés. Il serait dommage de lancer un projet Scrum en annonçant le même timing qu'un projet classique et donc entouré des mêmes doutes. L'idéal est de choisir un projet de moitié plus court qu'un projet classique ; 3 ou 4 mois suffisent généralement à prouver que l'application de Scrum est concluante et le serait pour une plus longue durée.

Taille du projet

Choisissez un projet qu'il est possible de commencer avec une seule équipe dont tous les membres sont colocalisés. Si la taille du projet vous sembler nécessiter plusieurs équipes, débutez tout de même avec une seule et limitez vous dans le nombre d'équipes, même si votre organisation a l'habitude de réaliser des projets de très grande envergure. Les soucis de coordination ne doivent pas être un frein pour ce premier projet agile.

Criticité du projet

Quand on expérimente, on a tendance à le faire sur quelque chose qui n'a pas d'importance et qui comporte peu de risques. Si les choses tournent mal, on aura perdu peu et avec de la chance personne n'aura rien remarqué. Ne cédez pas à cette tentation ! Allez à l'encontre de cela et choisissez un projet important. Si votre projet n'a pas de valeur, personne ne lui accordera d'attention au sein de votre entreprise. Et, comme la transition d'une équipe classique vers une équipe Scrum est exigeante, les protagonistes ne feront pas les efforts nécessaires si le projet n'apporte rien. Jim Highsmith, pionnier de l'agile et inventeur de « l'adaptative software Development process » nous met en garde sur ce sujet :

Ne commencez pas avec un projet pilote qui est marginal. Commencez avec un projet qui est critique pour votre société, sinon il sera trop difficile de faire tous les efforts que l'implémentation de la méthode requiert.

Le soutien du métier pour le projet

L'adoption de Scrum requiert un investissement total du métier. Avoir quelqu'un qui a le temps et l'envie de travailler avec l'équipe est absolument critique. Un sponsor côté métier peut aider à franchir les barrières organisationnelles et humaines inhérentes à toutes les entreprises. En cas de succès, il sera également le mieux placé pour promouvoir l'agilité en interne et pour évangéliser ses collègues, qui à leur tour seront enclins à tester l'agilité dans leurs équipes.

L'équipe

J'aborde ce point en dernier, mais c'est sans doute celui qui me tient le plus à cœur. Le choix de l'équipe est avec le choix du PO un des des facteurs clés de réussite. Et c'est valable pour tous les projets informatiques, agiles ou non. À l'instar d'un film, un scenario magnifique au casting désastreux ne donnera pas grand chose ; un scénario léger porté par des acteurs fabuleux lui donnera une âme. Dans notre cas, le métier va esquisser un scénario puis va l'affiner et l'adapter au fur et à mesure. Les membres de l'équipe, comme des acteurs, vont chercher à bien comprendre le scénario avant de le jouer. Ils vont être capables d'apporter leurs idées pour faire évoluer le projet dans le bon sens. Ils seront les artisans de leur propre succès.

Vous aurez donc compris l'importance du casting de l'équipe pour votre projet pilote. À ce sujet, je vous invite à lire le livre de Guillaume Bodet « Scrum en action » qui explique très bien comment repérer des profils agiles dans une équipe de projet classique.

D'après l'article de Mike Cohn : Four Attribute of the Ideal Pilot Project

La première chose au programme de ce billet, c'est apprendre à lire un log en temps réel (par exemple ici le fichier squid.log, généré par un squid et complété en continu) :

tail -f squid.log

Ça marche, mais compliquons un peu l'hypothèse de départ. On ajoute au système un logrotate qui va faire tourner le log toutes les 5 minutes (et qui va renommer squid.log en squid.log.YYYYMMDD.HHhMMmSSs). Si on continue avec notre tail précédent, toutes les cinq minutes on sera bon pour le relancer (le flux est cassé à la rotation). Heureusement, tail a une autre option, qui est plus robuste face à la suppression du fichier qu'on regarde :

tail -F squid.log

Et là c'est gagné. Maintenant, on va encore compliquer un peu et on va garder uniquement les lignes qui nous intéressent (qui contiennent le mot "motif"). Habituellement, quand on cherche une chaine de caractère dans un fichier de log en temps réel, on a tendance à grepper simplement :

tail -F squid.log | grep motif

Mais si on a face à nous une ligne qui se présente ainsi, on peut matcher des lignes qui ne vont pas forcément nous intéresser :

2011-02-21 15h54h10s motif_qui_nous_intéresse blabla blibli
2011-02-21 15h54h10s blabla motif_qui_ne_nous_intéresse_pas blibli

On a ici des lignes avec 5 colonnes séparées par des espaces, on veut uniquement grepper sur "motif" dans la troisième colonne :

tail -F squid.log | awk '$3 ~ "motif"'

Et éventuellement, si la colonne 4 ne nous intéresse vraiment pas, on peut même profiter du awk pour seulement afficher ce qui est pertinent :

tail -F squid.log | awk '$3 ~ "motif" {print $1,$2,$3,$5}'

J'en profite pour faire passer un rappel sur grep : non, on ne fait pas un cat pipe grep, un grep "motif" "fichier" suffit amplement, vous risquez de vous faire pendre ou brûler si vous osez faire ça.

Et en cadeau, un mémo sur awk : http://www.shellunix.com/awk.html

La première chose au programme de ce billet, c'est apprendre à lire un log en temps réel (par exemple ici le fichier squid.log, généré par un squid et complété en continu) :

tail -f squid.log

Ça marche, mais compliquons un peu l'hypothèse de départ. On ajoute au système un logrotate qui va faire tourner le log toutes les 5 minutes (et qui va renommer squid.log en squid.log.YYYYMMDD.HHhMMmSSs). Si on continue avec notre tail précédent, toutes les cinq minutes on sera bon pour le relancer (le flux est cassé à la rotation). Heureusement, tail a une autre option, qui est plus robuste face à la suppression du fichier qu'on regarde :

tail -F squid.log

Et là c'est gagné. Maintenant, on va encore compliquer un peu et on va garder uniquement les lignes qui nous intéressent (qui contiennent le mot "motif"). Habituellement, quand on cherche une chaine de caractère dans un fichier de log en temps réel, on a tendance à grepper simplement :

tail -F squid.log | grep motif

Mais si on a face à nous une ligne qui se présente ainsi, on peut matcher des lignes qui ne vont pas forcément nous intéresser :

2011-02-21 15h54h10s motif_qui_nous_intéresse blabla blibli
2011-02-21 15h54h10s blabla motif_qui_ne_nous_intéresse_pas blibli

On a ici des lignes avec 5 colonnes séparées par des espaces, on veut uniquement grepper sur "motif" dans la troisième colonne :

tail -F squid.log | awk '$3 ~ "motif"'

Et éventuellement, si la colonne 4 ne nous intéresse vraiment pas, on peut même profiter du awk pour seulement afficher ce qui est pertinent :

tail -F squid.log | awk '$3 ~ "motif" {print $1,$2,$3,$5}'

J'en profite pour faire passer un rappel sur grep : non, on ne fait pas un cat pipe grep, un grep "motif" "fichier" suffit amplement, vous risquez de vous faire pendre ou brûler si vous osez faire ça.

Et en cadeau, un mémo sur awk : http://www.shellunix.com/awk.html

Un petit mot quand même pour décrire la vie ici, d'un point de vue très extérieur...

Déjà, KarmaLing c'est pentu... 40m de dénivelée entre ma voiture et le chalet, et 30m entre le bureau et le chalet, autant dire que ça muscle les jambes et que j'ai fait pas mal de progrès ! Niveau météo, il[...]

Les rituels

Après un peu d'acclimatation, je pense qu'il est temps de décrire un peu ce qu'on voit ici, d'un point de vue extérieur, car je me suis aperçu que je ne l'avais même pas fait... Par contre évidemment tout cela est à prendre avec des pincettes, étant donné que ce n'est pas très[...]

It finally happened!

I would like to thank all my sponsors since my starting contributing to Debian in 2006. Also, cheers to my AM, Adeodato Simó (dato). It has been quite a long NM process due to us both being quite busy with other things but all in all it has been a very pleasant experience.

Cette semaine, un petit compte rendu de la rencontre fort intéressante avec les franc-maçons, vu que la franc-maçonnerie génère quand même beaucoup d'interrogations auxquelles j'ai quelques pistes de réponses... petit aperçu pas très bien écrit :
- la franc-maçonnerie est vue par certains de[...]

With work taking most of our time lately, my girlfriend and I needed to find as many ways as possible to change our minds once we were back home. This is how we found a real enjoyable online RPG called Nodiatis.

The game has reached quite a high level of maturity. There is a large community of players and the game allows a great deal of different characters' builds ranging from the basic but very efficient warrior to the more difficult to play but, in my opinion, more interesting to play spell caster.

With as many as 26 classes and a whole load of different skills, this is one of the richest web-based online RPG we have ever played.

Ok... Even though I am extremely busy and have had very little time to do anything Debian-related lately, I guess I'll have to do this one day or another, so here it is.

I created a new GPG key which I am transitionning to and I have prepared a transition document signed by both keys.

Intel and Nokia announced yesterday their opensource telephony solution, oFono. In addition to that, it looks like Intel is hiring 3G Software Integration Engineers and 3G System Architects in Sophia-Antipolis, France.

It is quite easy to jump to the conclusion that there is something going on there, isn't it?

Update:

Intel and Nokia Announce Strategic Relationship to Shape Next Era of Mobile
Computing Innovation
[...]
The Intel and Nokia effort includes collaboration in several open source
mobile Linux software projects. Intel will also acquire a Nokia HSPA/3G
modem IP license for use in future products.

Source: Intel News Release