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 :
AF_INET6-only, et
ce qui doit arriver dans le futur proche dans un FreeBSD près de
chez vous ;
À noter également les slides de quelques développeurs OpenBSD :
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 :
cp de notre
/ UFS vers ce volume ZFS, pointer le chargeur de
boot vers ce volume ;
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.
Cette partie est largement une reprise du wiki de FreeBSD sur l'installation d'un système en ZFS.
Cependant :
Il va donc falloir ruser (un peu) pour récupérer les paquets d'installation.
On boote alors sur le rescue-pro, on a bien sûr pris soin de donner sa clef publique SSH pour ne pas avoir à attendre le mail avec les identifiants.
Je n'ai pas réussi à installer ZFS en utilisant une table de partition MBR, alors que ça a marché du premier coup avec du GPT. Il paraît que GPT est la voie du futur, alors hop.
On détruit avec
gpart destroy le partitionnement en place, et
on recrée un nouveau schéma :
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
Autre possibilité : ne pas faire de partition de swap, mais créer un volume ZFS de swap. D'après la page du Wiki FreeBSD citée plus haut, ça empêche de créer des dumps lors d'un crash. En l'absence d'autres arguments, je suis parti sur une partition de swap à part.
Récupérer les fichiers d'installation. On crée un volume en
tmpfs, et
on ignore couragement l'avertissement qui apparaît dans le
dmesg :
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/*
Dans mon cas, j'installe juste un hôte minimal pour des jails. Pour un serveur traditionnel, vous voudrez certainement installer les autres sets, mais au pire cela se fait très bien une fois l'installation terminée.
On crée le volume ZFS :
mkdir /root/newinstall zpool create -m /root/newinstall zroot /dev/gpt/data zpool set bootfs=zroot zroot
On crée les sous-volumes ZFS :
zfs create zroot/usr zfs create zroot/var zfs list
On devrait voir
zroot monté dans
/root/newinstall,
zroot/var
dans
/root/newinstall, etc.
Encore une fois, pour un serveur complet on voudra peut-être créer
d'autres volumes ZFS pour une séparation plus fine, peut-être un
/var/log compressé ou un
/var/empty en RO… Voir l'article du
wiki de FreeBSD pour une idée de partitionnement possible.
/home
avec des quotas (voire un volume par luser) est une très bonne idée de
chose à ajouter si on prévoit d'avoir d'autres utilisateurs.
Par contre, mettre la racine (de notre serveur) dans la racine (de notre pool ZFS) n'est pas forcément une très bonne idée. Heureusement, on peut corriger cela plus tard.
On installe le monde de base plus le noyau GENERIC :
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"
Mettre un mot de passe pour root (
passwd), et se créer un
utilisateur (
adduser et répondre aux questions). Noter que par
défaut
sshd refuse les connexions en tant que root, donc créer un
utilisateur mortel et le placer dans le groupe
wheel est
certainement une bonne idée.
Quitter le chroot.
On va installer le bootloader ZFS-capable. Là j'ai eu une surprise :
ZFS s'est mis à utiliser toute la RAM, ce qui est normal vue
l'installation qu'on vient de réaliser, mais au détriment de notre
partition
tmpfs, ce qui est étonnant étant donné qu'on a donné une
réservation. Donc, j'ai démonté / remonté mon pool ZFS, mon
tmpfs a
retrouvé une taille normale, et j'ai pu récupérer le bootloader pour
l'installer :
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
Il est peut-être possible d'installer le bootloader sans démonter le
pool, je n'ai pas essayé. Il doit aussi certainement être possible
d'utiliser celui est dans le
/boot de l'environnement fourni par
OVH, je n'y ai pas pensé sur le moment…
Il semble que ZFS ait besoin d'un cache pour booter correctement. Je n'ai pas trouvé d'articles expliquant quelle est l'utilité du cache et ce qui se passe s'il n'est pas disponible au boot.
zpool set cachefile=/root/newinstall/boot/zfs/zpool.cache
On remet les points de montage au bon endroit :
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
Et là on croise les doigts et on reboote.
Ceci permet de faire plusieurs choses :
Let's roll.
On copie notre racine actuelle dans un autre volume :
zfs snapshot zroot@1 zfs send zroot@1 | zfs receive zroot/slash zfs destroy zroot@1
Même chose pour
/usr :
zfs snapshot zroot/usr@1 zfs send zroot/usr@1 | zfs receive zroot/slash/usr zfs destroy zroot/usr@1
Bien sûr, même chose pour les autres FS si vous avez partagé votre
/usr en morceaux.
Il m'a été indiqué que renommer
zroot/usr dans
zroot/slash/usr
(avec
zfs rename) est plus rapide, et surtout évite d'oublier un
volume si
/usr a été fractionné.
On indique qu'on veut booter sur
zroot/slash :
zpool set bootfs=zroot/slash vi /slash/etc/loader.conf
Et on ajuste la valeur de
vfs.root.mountfrom.
On veut aussi changer notre
/usr :
zfs set canmount=noauto zroot/usr zfs set mountpoint=/usr zroot/slash/usr
À ce moment, on a
deux volumes montés sur
/usr. Ça marche, mais
c'est un peu bancal ; on va donc rebooter de suite. Quand la machine
revient, on vérifie avec
zfs list et
mount que tout est bien
monter là où on l'attend (l'un montre la configuration des points de
montage, et l'autre montre les vrais montages). On voit que
zroot/slash a un
mountpoint qui vaut
/slash, mais est monté à
/ en vrai. Je ne sais pas à quel point ça peut être gênant.
Pour vérifier que le volume
zroot n'est plus directement utilisé, on
va le vider puis vérifier que la machine revient au reboot :
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
(Attention si vous avez d'autres volumes qui héritent leur point de
montage depuis
zroot !)
Notez que je n'ai pas déplacé
/var, qui ne sera pas concerné par les
mises à jours. C'est peut-être un choix discutable.
Ensuite, il nous reste toutes les actions habituelles d'une installation FreeBSD :
/etc/rc.conf pour activer les services que l'on veut ;
Et moultes autres activités :)
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à.
Il y a quelques cas où on n'a presque rien à faire pour bénéficier de
la complétion sur un nouvel outil. Par exemple, si un outil utilise
les conventions GNU, zsh peut parser la sortie de
--help pour
obtenir la liste des options existantes. Il suffit pour cela d'ajouter
quelque chose comme :
compdef _gnu_generic foo
dans un fichier lu par zsh (
.zshrc conviendra), et de relancer son
shell pour pouvoir compléter les options de
foo. On a même le droit
à la documentation des options.
Un autre cas où l'on n'a presque rien à faire est lorsqu'on peut réutiliser une complétion existante. Si un outil attend comme argument uniquement des noms d'hôtes, on utilisera :
compdef _hosts foo
Maintenant, en tapant
foo <TAB>, zsh proposera des complétions
basées sur les noms d'hôtes, trouvés par
`getent hosts` ou qui sont
dans l'une des bases
ssh_known_hosts entre autres.
Dans l'exemple au-dessus,
_hosts est le nom d'une fonction zsh, dont
la définition est (sur mon système) dans
/usr/local/share/zsh/4.3.11/functions/Completion/Unix.
La documentation de zsh donne un autre exemple assez courant : le cas d'une commande qui accepte tous les fichiers qui ont une certaine extension.
compdef '_files -g "*.h"' foo
Ici,
_files est encore une fonction, définie au même endroit que
_hosts (et bon courage à celui qui voudra se plonger dans le code de
cette fonction…). La documentation de cette fonction est visible
dans le manuel de zsh, au nœud «
Completion Functions >
Utility Functions ».
Lorsqu'on a des besoins plus poussés, au hasard pour un outil tel
qu'ezjail, on va devoir coder sa propre complétion. Une complétion
n'est en soi qu'une fonction zsh qui est appelée par le shell lorsque
l'utilisateur appuie sur
TAB (ou
C-d pour afficher les
complétions).
Les fonctions de complétions sont installées par défaut dans
/usr/local/share/zsh/site-functions/ (l'emplacement exact peut
dépendre de votre OS). Par convention, le fichier dans lequel vous
allez écrire votre fonction de complétion a le même nom que la
commande concerné, avec un
_ ajouté au début.
Lors du développement d'un fichier de complétion, il sera peut-être
plus pratique de pouvoir éditer le fichier sans être
root. Dans ce
cas, il suffit de choisir un dossier local, par exemple
~/zsh. On
placera le fichier de complétion dedans, et on l'ajoute au tableau
$fpath (bien sûr, à placer avant l'appel à
compinit) :
fpath=(~/zsh $fpath)
Notons que zsh refusera de charger des fonctions (donc des définitions de complétion) si le fichier appartient à un utilisateur autre que root ou l'utilisateur courant, ou s'il est modifiable par un autre utilisateur.
Le fichier de complétion commence avec un tag spécial sur la première ligne :
#compdef ezjail-admin
C'est un commentaire, qui indique à zsh que le fichier contient une complétion, et bien sûr quelle commande est concernée.
Ensuite, on définit une fonction de complétion, et on l'appelle :
_ezjail () {
# code de complétion
}
_ezjail "$@"
Notre code, ici la fonction
_ezjail, sera appelée avec quelques
informations sur la ligne de commande qui a déjà été saisie par
l'utilisateur.
Les informations qui sont accessibles depuis le code de complétion seront les suivantes :
| Variable | Description |
|---|---|
$words
|
Les mots déjà entrés par l'utilisateur |
$CURRENT
|
L'index, dans
$words, du mot que l'utilisateur essaie de compléter (c'est
$#words sauf si l'utilisateur est revenu en arrière)
|
$curcontext
|
Une chaîne de caractères, décrivant le contexte courant |
Le contexte courant est utilisé en interne à zsh pour savoir comment
interpréter les demandes de complétions. Depuis le code de complétion,
on passera aussi
$curcontext à
zstyle pour récupérer les styles de
complétion voulus par l'utilisateur. Comme je n'utilise pas
zstyle,
je ne me suis pas beaucoup avancé dans cette direction.
Si vous avez sous les yeux le
fichier de complétion d'ezjail, vous
verrez que la fonction principale,
_ezjail, fait un petit tour de
passe-passe sur ces variables pour sauter sur la fonction
correspondant à la sous-commande déjà entrée. La plupart des outils
pourront certainement se passer d'une telle manipulation.
Pour renvoyer à zsh les complétions elles-mêmes, on va utiliser l'une
des
fonctions de complétion. La fonction
_arguments sera notre outil
principal, en particulier pour les outils qui ont des options
standards.
Si l'on prend comme exemple la complétion (un peu réorganisée) pour
ezjail-admin create:
_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:"
}
Le
-s donné à
_arguments permet de dire que pour cette commande,
les options courtes peuvent être combinées, i.e.
-ix est équivalent
à
-i -x. Le texte entre crochets est affiché à côté de la
complétion, sauf si l'utilisateur a désactivé cela.
Dans l'exemple au-dessus,
-i et
-x sont des options qui
n'attendent pas d'arguments. Les autres options attendent des
arguments : on les distingue parce qu'une description de l'argument et
une méthode pour compléter cet argument sont données, avec des
:
pour séparer les champs. Dans le cas de
-a, l'argument sera complété
par la fonction
_files, qui propose des noms de fichiers comme
choix. Dans le cas de
-c, la completion se fait sur un petit nombre
de choix possibles, qui sont donnés entre parenthèses. Pour
-C, on
indique qu'on attend un mot donné par l'utilisateur, mais le shell
n'aidera pas à le compléter.
Enfin, la commande prend encore deux arguments, mais on ne sait pas
offrir d'aide pour les compléter (il n'y a rien avant le premier
:).
Il peut y avoir des cas où des options sont mutuellement exclusives.
C'est le cas pour
ezjail-admin archive : ou bien l'on archive toutes
les jails avec
-A, ou alors on donne une liste de jails.
_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"
}
On sépare les groupes d'options qui s'excluent avec un tag (je ne sais pas si le nom est réutilisé pour être montré à l'utilisateur dans certaines circonstances). Les options qui peuvent toujours être utilisées sont données en premier. Remarquez au passage l'astérisque pour la dernière ligne : cela permet d'indiquer qu'on peut avoir des répétitions.
_values: plus simple
Lorsqu'on a juste une liste de mots à proposer, surtout si cette liste
est générée dynamiquement, les arguments pour
_arguments ne sont pas
faciles à manipuler. Dans ce cas,
_values, qui permet de simplement
donner la liste des mots candidats à la complétion, est plus facile à
manipuler. En prenant comme exemple
_ezjail, dans le cas où on
propose les sous-commandes, on a :
_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
}
compadd: pour construire les complétions au fur et à mesure
compadd est le
builtin utilisé par
_arguments,
_values et les
autres fonctions pour ajouter les candidats à la complétion. Il y a
certains cas où il est plus facile d'ajouter un à un les candidats.
C'est le cas pour lister les jails : une première version utilisait
quelque chose de la forme :
_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
}
Le problème est que lorsque la sortie de
_ezjail_list_jails est
vide,
_values remonte un message d'erreur parce qu'on ne lui a donné
aucun argument. Pour corriger cela, une première solution pourrait
être de capturer la sortie de
_ezjail_list_jails dans une variable,
tester si cette variable est vide ou non, et agir en conséquence. La
deuxième solution, qui est celle que j'ai retenu, est de faire ajouter
à
_ezjail_list_jails les complétions elles-mêmes. Il faut encore
gérer à part le cas où il n'y a pas de candidats à la complétion, en
revoyant 1 dans ce cas ; mais c'est plus facile à gérer. Au passage,
la première version ne renvoyait pas 1 en l'absence de candidates…
L'implémentation ressemble à ceci :
_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
}
compadd, en tant que brique de base, permet bien plus que de
simplement ajouter un candidat. Encore une fois, allez voir la
documentation pour tous les détails.
Le code de complétion est lancé à chaque fois que l'utilisateur
tapotte sa touche
TAB ou
C-d. Le code doit donc être
raisonnablement rapide.
Par ailleurs, le code de complétion s'exécute dans le shell courant de l'utilisateur. En particulier :
exit ;
std{out,err} sans faire une
horrible mixture entre le prompt, les propositions de complétion et
ce qui est affiché ;
local,
pour éviter d'écraser ou de polluer les variables du shell courant
de l'utilisateur ;
Il y a également
completion-style-guide, qui est chez moi dans
/usr/local/share/doc/zsh (
copie en ligne), qui donne des conseils.
J'ai découvert ce fichier un peu tard, et la complétion pour ezjail
ne suit pas toujours à la lettre les conseils donnés.
Bien sûr, lorsqu'on a quelque chose qui marche, on le propose au
projet en question, ou alors directement sur la liste
zsh-workers@,
pour en faire profiter les petits copains.
A User's Guide to the Z-Shell, Peter Stephenson, Chapter 6: Completion, old and new. Il y a en particulier un tutorial bien fait.
The Z Shell Manual,
20. Completion System, et en particulier
20.6 Utility Functions. Vous en avez certainement une version accessible en
local avec
info zsh (ou
C-h i m zsh depuis
emacs). Le manuel est
assez aride, je ne l'ai utilisé que comme référence.
zsh completion support for ezjail , de votre serviteur.
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.
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.
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.
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.
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
Tags:planet-libre, planete-libre, Savoir-faireNiveau :
Résumé : debootstrap --foreign ; debian.apk
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 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 :
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.
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 !
Tags:android, Debian, i, planet-libre, planete-libreCorrection : 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 ...
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) :
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.
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 :
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 !
Maintenant installons un environnement un peu plus user-friendly :
$ ./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.
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 ?
Tags:android, Commande, SystèmeNiveau :
Résumé : tcpdump, wireshark
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.*
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 :
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).
Tags:android, planet-libre, planete-libre, RéseauNiveau :
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
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.
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
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.
Tags:Interface graphique, planet-libre, planete-libre, SystèmeRé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.
Quelques petits rappels pour les malheureux Linuxiens qui ne
connaîtraient pas les
jails de FreeBSD. Les
jails de FreeBSD sont
parfois comparées à des
chroot sur stéroïdes ; maintenant que Linux
a des choses telles qu'OpenVZ ou LXC, il faudrait plutôt utiliser cela
comme comparaison.
Les
jails pour FreeBSD ont été introduites dans FreeBSD 4.0
(mars 2000) par Poul-Henning Kamp (le développeur derrière UFS2 et pas
mal de code tournant autour du stockage disque, l'auteur du
malloc(3) de FreeBSD, du cache Varnish, et l'inventeur de
l'expression
bikeshedding
). Une
jail est définie par :
/etc/rc pour lancer un FreeBSD
complet.
Depuis l'intérieur de la
jail, il est impossible de sortir du
dossier racine, contrairement à un
chroot(2). Les processus tournant
à l'intérieur de la
jail ne peuvent utiliser que les adresses IP
attribuées par l'administrateur pour se connecter ou accepter des
connexions externes.
Le dossier attribué à une jail peut être tout petit (une dizaine de fichiers, comme le décrit Bapt dans ses NANO Jails), ou contenir un système FreeBSD complet (voire un système CentOS, en utilisant la couche d'émulation de Linux).
Pour des jails contenant un système FreeBSD complet, on voit qu'il peut rapidement y avoir quelques difficultés d'administration :
ezjail propose une solution à tout cela, et notamment aux deux
premiers points en utilisant
mount_nullfs(4) (l'équivalent du
mount -o bind de Linux) pour fournir à toutes les
jails une unique
installation de FreeBSD en lecture seule ; cette installation est
appelée la
basejail. ezjail a un certain nombre d'autres
fonctionnalités, que je ne déveloperai pas ici.
Depuis l'introduction de FreeBSD Update, il est possible de mettre à jour son OS diabolique, y compris d'une version à l'autre. La procédure est décrite à chaque fois dans l'annonce de sortie, mais se résume à :
freebsd-update -r 8.2-RELEASE ;
freebsd-update install, et
rebooter sur le nouveau noyau ;
freebsd-update install ;
Comme nous l'avons dit au début, ezjail dans sa version CVS permet de mettre à jour la basejail à partir de FreeBSD Update. Le port ezjail n'a pas encore été mis à jour. J'ai un port local d'ezjail, qui installe directement à partir du CVS.
Une fois la version CVS d'ezjail installée, la mise à jour se fait tout simplement :
# ezjail-admin update -s 8.1-RELEASE -U
On notera qu'il est nécessaire de donner la version actuelle de la
basejail : FreeBSD Update utilise en temps normal
uname -r pour
connaître la version actuelle de la machine, ce qui n'est bien sûr pas
possible dans une
jail, puisque
uname va renvoyer la version
du noyau de l'hôte, et non de l'espace utilisateur de la
basejail.
Un problème :
freebsd-update(8) détecte les composants installés à
partir de deux choses : la ligne
Components dans
/etc/freebsd-update.conf, et ce qui est réellement sur le disque.
Cependant, le noyau est géré un petit peu à part, et est ajouté aux
composants à mettre à jour si
Components liste
kernel et si la
nouvelle version vient avec un nouveau noyau, même si le noyau n'est
pas installé sur la cible. Bien sûr, vouloir mettre à jour le noyau
dans une
jail ne va pas donner grand'chose… Ma solution a été de
supprimer
kernel des composants potentiellement installés. À terme,
il faudra probablement qu'ezjail lance
freebsd-update avec un
fichier de configuration à lui.
ezjail a depuis longtemps la possibilité, avec
update -p, de mettre
à jour l'arbre des
ports ; mais pour mettre à jour les
ports
eux-mêmes, rien de spécial n'est prévu. La technique habituelle,
lorsqu'on a beaucoup de machines, est de consacrer une
jail à la
compilation de
ports, et d'utiliser
pkg_create -b pour créer des
packages qu'on distribue ensuite aux autres
jails.
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.

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.
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.
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.
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.
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