Taille: 10439
Commentaire: typos
|
Taille: 10163
Commentaire: les sections les plus importantes vers le haut
|
Texte supprimé. | Texte ajouté. |
Ligne 1: | Ligne 1: |
Git est un système de gestion de versions. Voir sa [http://fr.wikipedia.org/wiki/Git_(logiciel) page wikipédia] = Suivre la config' d'une machine avec git = On veut pouvoir documenter les modifications faites dans `/etc` et dans `/usr/local`, qui sont grosso modo les deux répertoires permettant de décrire comment fonctionne un serveur. Cette documentation est indispensable en cas d'administration à plusieurs, mais elle est également très utile quand on est seul à gérer : c'est un aide-mémoire indispensable vu la vitesse à laquelle évoluent les technologies et donc les configurations. |
||<#FFFF50> '''APPEL A PARTICIPATION AUX TESTS DE DÉPLOIEMENT''' : Mettez ce système en place en suivant simplement les sections « Installation automatisée » et « Utilisation ». S'il restait encore un problème, signalez-le immédiatement via la liste de discussion technique de l'AUF. Aidez à tester le déploiement de ce système : c'est quasiment sans risque, et ce sera bientôt la façon '''officielle''' de faire à l'AuF. Affaire à suivre très prochainement. || == Introduction == On veut pouvoir documenter les modifications faites dans `/etc` et dans `/usr/local`, qui sont ''grosso modo'' les deux répertoires permettant de décrire comment fonctionne un serveur. Cette documentation est indispensable en cas d'administration à plusieurs, mais elle est également très utile quand on est seul à gérer : c'est un aide-mémoire indispensable vu la vitesse à laquelle évoluent les technologies et donc les configurations. |
Ligne 9: | Ligne 9: |
Il existe différents logiciels de ce type, parmis lesquels on peut citer l'ancètre CVS, son fils Subversion (`svn`), et dans une famille différente `git`. C'est ce dernier logiciel que nous avons choisi car il est moins bavard, moins intrusif dans le code à surveiller, et surtout très bien documenté. ''A écrire : petites explications sur la notion de dépôt, orientée git et surveillance de /etc'' |
Il existe différents logiciels de ce type, parmis lesquels on peut citer l'ancètre RCS, son fils CVS, son petit-fils Subversion (`svn`) et dans la génération qui vient d'arriver : `git`. C'est ce dernier logiciel que nous avons choisi car il est moins bavard, moins intrusif dans le code à surveiller, et surtout très bien documenté. /* ''A écrire : petites explications sur la notion de dépôt, orientée git et surveillance de /etc'' */ |
Ligne 16: | Ligne 15: |
== Installation == | == Installation automatisée (recommandée) == Vous avez maintenant à votre disposition un paquet Debian [[http://git.auf.org/?p=auf-git-etc.git|réalisé en interne à l'AuF]]. Pour profiter de ce paquet il vous suffit de créer un fichier `/etc/apt/sources.list.d/auf.list` avec le contenu suivant : {{{ deb http://apt.auf.org/ etch auf }}} Puis de lancer les commandes suivantes : {{{ $ sudo aptitude update # ignorer le message d'avertissement $ sudo aptitude install auf-keyring $ sudo aptitude update $ sudo aptitude install auf-git-etc }}} == Utilisation == * '''Préliminaire''' : ajouter les lignes suivantes dans son `~/.bash_profile`, puis faire un `source ~/.bash_profile` (ou se reloguer) pour activation : {{{ # à ajouter à la fin de son fichier ~/.bash_profile : export GIT_AUTHOR_NAME="Prénom NOM" export GIT_AUTHOR_EMAIL="prenom.nom@auf.org" }}} * Pour voir les modifications avant de les envoyer dans le dépôt : {{{ $ sudo git status -a # affiche la ligne des fichiers modifiés, supprimés, nouveaux... $ sudo git diff # affiche les différences entre la version stockée dans git et la version actuelle }}} * Pour envoyer les modifications dans le dépôt, on lance un ''commit''. Il y a plusieurs façons de faire, parmis lesquelles : {{{ $ sudo git commit un/seul/fichier/modifié # pour un fichier : toujours en notation relative $ sudo git commit -a # on enregistre *toutes* les modifications }}} * Pour suivre un nouveau fichier ou tous les nouveaux fichiers d'un répertoire, par exemple suite à l'installation de nouveaux fichier de configuration : {{{ $ cd / $ sudo git add le/chemin/relatif/vers/le/fichier/ou/repertoire <-- il faut indiquer le chemin en "relatif" (sans / au début) $ sudo git commit }}} Attention : il faut éventuellement modifier le fichier `/.git/info/exclude` * Pour ne plus suivre un fichier ou un répertoire : {{{ $ sudo vi /.git/info/exclude <-- on ajoute le nom du fichier dans les excludes (exemple : /etc/ldap.secret) $ cd / $ sudo git rm le/chemin/du/fichier/a/ne/plus/suivre <-- on le retire du dépôt (nb : le chemin est relatif, sans / au début) }}} * Pour revoir les modifications, plusieurs techniques en ligne de commande : {{{ $ sudo tig <-- petit logiciel très sympa, à installer avec aptitude install tig $ sudo git whatchanged $ sudo git log -10 $ sudo git show ...(le code du commit)... }}} * Note : la plupart du temps, il est plus simple de prendre l'habitude de se placer à la racine pour faire les manipulations `git`. Un exemple typique : {{{ $ cd /etc | $ sudo vi profile <-----| ici on travaille $ sudo vi postfix/main.cf | $ cd / $ sudo git status -a | on fait un cd / $ sudo git diff | less <-----| puis on documente $ sudo git commit -a | son travail ... }}} == Installation manuelle (déconseillée) == |
Ligne 26: | Ligne 97: |
# git init (ou "git init-db" sur une Debian Etch, git version 1.4) # chmod u=rwx,go= /.git }}} 3. Pour éviter d'avoir des "saletés" directement à la racine (`/`), on déplace le dépôt. Le répertoire `/.git` à la racine ne sera en fait qu'un lien symbolique vers le véritable emplacement du dépôt : |
# git init-db <--- Ou "git init" sur Git 1.5 (Debian Lenny, Ubuntu Gutsy) # chmod u=rwx,go= /.git <--- important ! Seul "root" doit pouvoir accéder au dépôt }}} 3. Pour éviter d'avoir des "saletés" directement à la racine (`/`), on déplace le dépôt vers `/var/lib/git`. Le répertoire `/.git` à la racine ne sera en fait qu'un lien symbolique vers le véritable emplacement du dépôt : |
Ligne 39: | Ligne 110: |
# Le fichier /var/lib/git/root/info/exclude : # Par défaut, on exclut tout, sauf /etc |
# Le fichier /var/lib/git/root/info/exclude à modifier ou créer # Par défaut, on exclut tout sauf /etc |
Ligne 44: | Ligne 115: |
# cf "find /etc -not -perm /004 -ls" | |
Ligne 63: | Ligne 133: |
5. On fait les premiers ajouts et le premier ''commit'' : | 5. On fait le premier ajout de tous les fichiers à suivre (sauf les exclus indiqués ci-dessus), puis le premier ''commit'' : |
Ligne 67: | Ligne 137: |
# git commit -m "mise en route du suivi : /etc et /usr/local" --author "moi <email@auf.org>" }}} 6. On configure `sudo` pour qu'il ne supprime pas les variables d'environnement de `git` : {{{ |
# git commit -m "mise en route du suivi : /etc et /usr/local" --author "Prenom NOM <prenom.nom@auf.org>" }}} 6. On utilisera surtout `git` avec `sudo`. Il faut donc dire à `sudo` de ne pas supprimer les variables d'environnement utiles à `git` : {{{ # (... extrait de /etc/sudoers ...) |
Ligne 76: | Ligne 147: |
== Utilisation == * A ajouter dans son `~/.bash_profile` (puis le « sourcer » ou se reloger pour activation) : {{{ # à ajouter à la fin de son fichier ~/.bash_profile : export GIT_AUTHOR_NAME="Prenom NOM" export GIT_AUTHOR_EMAIL="prenom.nom@auf.org"}}} * Pour voir les modifications : {{{ $ sudo git status -a # affiche la ligne des fichiers modifiés, supprimés, nouveaux... $ sudo git diff # affiche les différences entre la version stockée dans git et la version actuelle }}} * Pour enregistrer les modifications : {{{ $ sudo git commit un/seul/fichier/modifié # pour un fichier : toujours en notation relative $ sudo git commit -a # on enregistre *toutes* les modifications}}} * Pour suivre un nouveau fichier : {{{ $ sudo git add le/chemin/relatif/vers/le/fichier/ou/repertoire $ sudo git commit }}} Attention : il faut éventuellement modifier le fichier `/.git/info/exclude` * Pour ne plus suivre un fichier : {{{ $ sudo vi /.git/info/exclude <--- on ajoute dans les excludes (exemple : /etc/ldap.secret) $ sudo git rm le/chemin/relatif/du/fichier/a/ne/plus/suivre }}} * Pour revoir les modifications, plusieurs techniques en ligne de commande : {{{ $ sudo tig <-- à installer avec aptitude install tig $ sudo git whatchanged $ sudo git log -10 $ sudo git show ...(le code du commit)... }}} * Note : la plupart du temps, il est plus simple de prendre l'habitude de se placer à la racine pour faire les manipulations `git`. Un exemple typique : {{{ $ cd /etc | $ sudo vi profile <-----| ici on travaille $ sudo vi postfix/main.cf | $ cd / $ sudo git status -a | on fait un cd / $ sudo git diff | less <-----| puis on documente $ sudo git commit -a | son travail ... }}} |
|
Ligne 129: | Ligne 149: |
* Pour lancer un "status" à chaque connexion sur le serveur (très très utile) : 1. Permettre aux gens du groupe "admin" de lancer git status sans mot de passe : |
''Note : ces automatisations sont déjà mise en place par notre paquet Debian.'' Pour lancer un "status" à chaque connexion sur le serveur (très très utile) : 1. Permettre aux gens du groupe "admin" de lancer git status sans mot de passe : |
Ligne 134: | Ligne 156: |
%admin ALL=(ALL) /usr/bin/git status -a }}} 1. Lancer le `git status` (via `sudo`) dans le `/etc/profile`, et configurer un peu les variables GIT : |
%admin ALL=(ALL) NOPASSWD: /usr/bin/git status -a }}} 1. Lancer le `git status` (via `sudo`) dans le `/etc/profile`, et configurer un peu les variables GIT : |
Ligne 157: | Ligne 179: |
* Pour envoyer un mail à chaque commit : 1. Créer un script `/.git/hooks/post-commit` : |
Pour envoyer un mail à chaque commit : 1. Créer un script `/.git/hooks/post-commit` : |
Ligne 174: | Ligne 196: |
1. Activer le script : |
1. Activer le script : |
Ligne 179: | Ligne 200: |
1. Eventuellement faire un commit de test afin de vérifier ça marche, notamment que `sendmail` (Postfix, Exim, ...) envoie bien le message. == Un serveur gitweb central (idée pour plus tard...) == ''brouillon (manip testées, ça marche, mais j'ai peut-être oublié quelques détails)'' 1. Installation de gitweb sur un serveur du RPV. Attention, puisqu'il permettra d'accéder à des fichiers du type `shadow` : accès restreint par mot de passe, éventuellement à certaines IP, voir certificat ssl si on passe en mode parano. 2. Dans /var/lib/git on créée des dépôts (un par serveur à suivre). Ces dépots appartiennent à un utilisateur "gitweb" (pas à root) qui n'a aucun autre droit. {{{ gitweb@serveur-git$ GIT_DIR=/var/lib/git/apollon git init-db gitweb@serveur-git$ ln -s /var/lib/git/apollon /var/cache/git/apollon # prise en compte par gitweb }}} 3. On met les clés publiques des comptes root des serveurs dans `/home/gitweb/.ssh/authorized_keys` 4. Pour synchroniser le dépôt local d'un serveur avec le dépôt sur le serveur gitweb : {{{ # git push --all ssh://gitweb@serveur-gitweb/var/lib/git/apollon }}} 5. C'est tout. ''Idée'' pour simplifier et un peu sécuriser : procéder comme pour les backups, c-à-d par ''git-pull'' depuis le serveur. Si on installe ça sur la même machine que backuppc (ce n'est pas illogique) c'est simple, vu que backuppc a déjà un accès root aux machines. Question pour Tini : backuppc accepte-t-il les "hooks" dans son système de backup ? Ca serait sympa de pouvoir lancer le ''git-pull'' en même temps que la sauvegarde par backuppc. * ouiiiiiiiii : {{{$Conf{DumpPreUserCmd}}}}. Sur le principe, ouip, ça serait beaucoup beaucoup plus simple à mettre en oeuvre ainsi. mais, heu... pas sûr d'être trés chaud (pas d'autre argument pour le moment que "j'ai le nez qui coule", toutefois) -- J. * c'est juste comme ça pour le fun... il faut protéger derrière (protéger comme l'est bppc, avec un bon gros login/passwd sur une machine tout au fond du réseau...?). Enfin bref, pas très très important/nécessaire pour l'instant, on va déjà essayer de se discipliner sur les commit, on verra ensuite ! -- Thomas |
1. Faire un petit commit de test afin de vérifier ça marche, notamment que `sendmail` (Postfix, Exim, ...) envoie bien le message. == Ca ressemble à quoi ? == Juste pour donner une idée, voici ce que donne le petit programme `tig` lorsqu'on le lance sur une machine bien suivie : {{attachment:ce-que-montre-tig.png}} |
Ligne 206: | Ligne 211: |
Pour plus tard (Lenny) : * [http://kerneltrap.org/mailarchive/git/2007/10/11/335112 RCS keyword expansion] pour les $Id$ et compagnies |
Pour plus tard (Lenny) : * correction du bogue quand on joue avec un "/.git" (y a-t-il un bogue, d'ailleurs ? ) |
Ligne 209: | Ligne 214: |
* [:Tini:] n'ose pas le dire, mais il a fait un paquet Debian `git-etc-auf` qui fait tout le boulot d'installation. Un jour il osera. * RHHHAAAAAA !!!! Ça urge la mise en place du dépôt APT AuF... On fait de plus en plus de paquets Debian et personne n'en profite car on a pas de lieu commun pour les déposer, grmph... Bon, Moussa, tu le fais quand le serveur virtual apt.auf.org (je ferai la suite) ? Ou sinon je peux le faire où ?? -- ProgFou "Je vous ai compris" :-), le serveur apt.auf.org vient d'être mise en place sur vz-www.ca.auf avec l'IP 199.84.140.13. La balle est dans ton camp JC ;-) |
* [[Tini]] n'ose pas le dire, mais il a fait un paquet Debian `git-etc-auf` qui fait tout le boulot d'installation. Un jour il osera. * il n'a pas vraiment osé, mais ProgFou a repris le flambeau et ne s'est pas encore brulé les doigts avec * Chouette ! Maintenant qu'on a notre [[DépôtAPT|dépôt APT AuF]], on va pouvoir FOOONNNCCCEEEEEEERRRR (dans le mur ?) |
APPEL A PARTICIPATION AUX TESTS DE DÉPLOIEMENT : Mettez ce système en place en suivant simplement les sections « Installation automatisée » et « Utilisation ». S'il restait encore un problème, signalez-le immédiatement via la liste de discussion technique de l'AUF. Aidez à tester le déploiement de ce système : c'est quasiment sans risque, et ce sera bientôt la façon officielle de faire à l'AuF. Affaire à suivre très prochainement. |
Introduction
On veut pouvoir documenter les modifications faites dans /etc et dans /usr/local, qui sont grosso modo les deux répertoires permettant de décrire comment fonctionne un serveur. Cette documentation est indispensable en cas d'administration à plusieurs, mais elle est également très utile quand on est seul à gérer : c'est un aide-mémoire indispensable vu la vitesse à laquelle évoluent les technologies et donc les configurations.
Pour cela, on utilise un logiciel de gestion de version. Ce logiciel va nous permettre de documenter chaque modification effectuée sur un fichier ou un ensemble de fichier. On pourra ensuite retrouver à quel moment à été faite une modification, par qui et pour quelle raison.
Il existe différents logiciels de ce type, parmis lesquels on peut citer l'ancètre RCS, son fils CVS, son petit-fils Subversion (svn) et dans la génération qui vient d'arriver : git. C'est ce dernier logiciel que nous avons choisi car il est moins bavard, moins intrusif dans le code à surveiller, et surtout très bien documenté.
Notre objectif ici est d'installer git sur un serveur pour que son ou ses administrateurs, et uniquement eux, puissent aisément faire le suivi de sa configuration.
Installation automatisée (recommandée)
Vous avez maintenant à votre disposition un paquet Debian réalisé en interne à l'AuF.
Pour profiter de ce paquet il vous suffit de créer un fichier /etc/apt/sources.list.d/auf.list avec le contenu suivant :
deb http://apt.auf.org/ etch auf
Puis de lancer les commandes suivantes :
$ sudo aptitude update # ignorer le message d'avertissement $ sudo aptitude install auf-keyring $ sudo aptitude update $ sudo aptitude install auf-git-etc
Utilisation
Préliminaire : ajouter les lignes suivantes dans son ~/.bash_profile, puis faire un source ~/.bash_profile (ou se reloguer) pour activation :
# à ajouter à la fin de son fichier ~/.bash_profile : export GIT_AUTHOR_NAME="Prénom NOM" export GIT_AUTHOR_EMAIL="prenom.nom@auf.org"
- Pour voir les modifications avant de les envoyer dans le dépôt :
$ sudo git status -a # affiche la ligne des fichiers modifiés, supprimés, nouveaux... $ sudo git diff # affiche les différences entre la version stockée dans git et la version actuelle
Pour envoyer les modifications dans le dépôt, on lance un commit. Il y a plusieurs façons de faire, parmis lesquelles :
$ sudo git commit un/seul/fichier/modifié # pour un fichier : toujours en notation relative $ sudo git commit -a # on enregistre *toutes* les modifications
- Pour suivre un nouveau fichier ou tous les nouveaux fichiers d'un répertoire, par exemple suite à l'installation de nouveaux fichier de configuration :
$ cd / $ sudo git add le/chemin/relatif/vers/le/fichier/ou/repertoire <-- il faut indiquer le chemin en "relatif" (sans / au début) $ sudo git commit
Attention : il faut éventuellement modifier le fichier /.git/info/exclude
- Pour ne plus suivre un fichier ou un répertoire :
$ sudo vi /.git/info/exclude <-- on ajoute le nom du fichier dans les excludes (exemple : /etc/ldap.secret) $ cd / $ sudo git rm le/chemin/du/fichier/a/ne/plus/suivre <-- on le retire du dépôt (nb : le chemin est relatif, sans / au début)
- Pour revoir les modifications, plusieurs techniques en ligne de commande :
$ sudo tig <-- petit logiciel très sympa, à installer avec aptitude install tig $ sudo git whatchanged $ sudo git log -10 $ sudo git show ...(le code du commit)...
Note : la plupart du temps, il est plus simple de prendre l'habitude de se placer à la racine pour faire les manipulations git. Un exemple typique :
$ cd /etc | $ sudo vi profile <-----| ici on travaille $ sudo vi postfix/main.cf | $ cd / $ sudo git status -a | on fait un cd / $ sudo git diff | less <-----| puis on documente $ sudo git commit -a | son travail ...
Installation manuelle (déconseillée)
On installe git :
# aptitude install git-core
On créée un dépôt général pour toute la machine. Attention à bien régler les droits : seul root doit pouvoir accéder au dépôt, sinon les fichiers du genre shadow seraient accessibles à tous.
# cd / # git init-db <--- Ou "git init" sur Git 1.5 (Debian Lenny, Ubuntu Gutsy) # chmod u=rwx,go= /.git <--- important ! Seul "root" doit pouvoir accéder au dépôt
Pour éviter d'avoir des "saletés" directement à la racine (/), on déplace le dépôt vers /var/lib/git. Le répertoire /.git à la racine ne sera en fait qu'un lien symbolique vers le véritable emplacement du dépôt :
# mkdir /var/lib/git # mv /.git /var/lib/git/root # ln -s /var/lib/git/root /.git
On veut suivre /etc et /usr/local seulement, pour cela on modifie les exclusions au niveau du dépôt, dans le fichier /var/lib/git/root/info/exclude :
# Le fichier /var/lib/git/root/info/exclude à modifier ou créer # Par défaut, on exclut tout sauf /etc /* !/etc # ... mais dans /etc on interdit certains fichiers : /etc/*shadow* /etc/ssh/ssh_host_*_key /etc/mtab /etc/adjtime /etc/ld.so.cache # On n'interdit pas non plus le parcours de /usr. Mais dans ce parcours, # on interdit tout sauf /usr/local. C'est la technique pour inclure /usr/local... !/usr /usr/* !/usr/local # quelques type fichiers à ne pas jamais considérer, globalement : *.dpkg-old *.dpkg-new .*.swp *~ *#
On fait le premier ajout de tous les fichiers à suivre (sauf les exclus indiqués ci-dessus), puis le premier commit :
# cd / # git add etc usr/local # git commit -m "mise en route du suivi : /etc et /usr/local" --author "Prenom NOM <prenom.nom@auf.org>"
On utilisera surtout git avec sudo. Il faut donc dire à sudo de ne pas supprimer les variables d'environnement utiles à git :
# (... extrait de /etc/sudoers ...) # une ligne à ajouter au début de /etc/sudoers : Defaults env_keep += "GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL"
Quelques automatisations quasi indispensables
Note : ces automatisations sont déjà mise en place par notre paquet Debian.
Pour lancer un "status" à chaque connexion sur le serveur (très très utile) :
- Permettre aux gens du groupe "admin" de lancer git status sans mot de passe :
# et à ajouter vers la fin de /etc/sudoers : %admin ALL=(ALL) NOPASSWD: /usr/bin/git status -a
Lancer le git status (via sudo) dans le /etc/profile, et configurer un peu les variables GIT :
# A ajouter à la fin de /etc/profile : if [ "$PS1" ]; then # on lance un git status sur l'utilisateur est dans le groupe # admin ou bien si c'est root if $(id -Gn | grep -qw admin) || [ $(id -u) -eq 0 ]; then [ -x /usr/bin/git -a -e /.git ] && (cd / && sudo /usr/bin/git status -a) fi # les lignes suivantes tentent de configurer les variables GIT_* # si les résultats ne sont pas bien "devinés", définir les bonnes valeurs dans .bashrc GIT_AUTHOR_NAME=${GIT_AUTHOR_NAME:=$(getent passwd $(id -un)|cut -d: -f5|cut -d, -f1)} GIT_AUTHOR_EMAIL=${GIT_AUTHOR_EMAIL:=$(id -un)@$(hostname -f)} GIT_COMMITTER_NAME=${GIT_COMMITTER_NAME:=$GIT_AUTHOR_NAME} GIT_COMMITTER_EMAIL=${GIT_COMMITTER_EMAIL:=$GIT_AUTHOR_EMAIL} export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL fi
Pour envoyer un mail à chaque commit :
Créer un script /.git/hooks/post-commit :
recipients="admins@XX.auf.org" # adresse pour l'envoi du mail # On modifie un peu la sortie de git show : # 1) on ajoute "From git hostname" devant le nom en From # 2) on retire le [PATCH] dans le sujet, replacé par git-commit: # 3) on ajoute un champ To: # et on maile le tout via sendmail PATH=/usr/sbin:/usr/bin:/sbin:/bin git show --pretty=email | sed '1,6s/^From: /From: git '`hostname -f`' - /;1,6s/^Subject: \[PATCH\]/Subject: git-commit:/;2iTo: '"${recipients}" | head -c 16k | /usr/lib/sendmail ${recipients} exit 0
- Activer le script :
# chmod +x /.git/hooks/post-commit
Faire un petit commit de test afin de vérifier ça marche, notamment que sendmail (Postfix, Exim, ...) envoie bien le message.
Ca ressemble à quoi ?
Juste pour donner une idée, voici ce que donne le petit programme tig lorsqu'on le lance sur une machine bien suivie :
Améliorations à trouver
Pour plus tard (Lenny) :
- correction du bogue quand on joue avec un "/.git" (y a-t-il un bogue, d'ailleurs ? )
git-stash pour relier apt et git correctement
Tini n'ose pas le dire, mais il a fait un paquet Debian git-etc-auf qui fait tout le boulot d'installation. Un jour il osera.
il n'a pas vraiment osé, mais ProgFou a repris le flambeau et ne s'est pas encore brulé les doigts avec
Chouette ! Maintenant qu'on a notre dépôt APT AuF, on va pouvoir FOOONNNCCCEEEEEEERRRR (dans le mur ?)