Corrections de mise en forme

5 years ago · ffc33f1d7f
83 changed files with 738 additions and 229 deletions
--- a/CarteAPU.md
+++ b/CarteAPU.md
@ -37,6 +37,7 @@ sync
 ## Persistance de /var et /home

 Dans /etc/rc.flashrd.sub vérifier que les lignes suivantes sont présentes et décommentées :
+
 ~~~
 tardirs="var"
 set -A tarsize 64M                      # tmpfs sizes for tar dirs
@ -54,6 +55,7 @@ tar cf /flash/var.tar -C /var .
 ~~~

 Pour /home :
+
 ~~~
 mkdir /flash/home/
 rmdir /home
--- a/HowtoACL.md
+++ b/HowtoACL.md
@ -2,7 +2,8 @@

 # Howto ACL

-Savoir que le fichier a un ACL configuré (+) :
+Savoir que le fichier a un ACL configuré (`+`) :
+
 ~~~
 $ ls -dl foo/
 drwxr-x---+ ...
@ -13,6 +14,7 @@ drwxr-x---+ ...
 ~~~
 # getfacl foo/
 ~~~
+
 récupérer le statut ACL sur le fichier.


@ -21,12 +23,11 @@ récupérer le statut ACL sur le fichier.
 ~~~
 # setfacl -R -m group:example:rwx foo/
 ~~~
-R : récursif, -m : pour modifier.
+
+`-R` : récursif, `-m` : pour modifier.

 ~~~
 # setfacl -d -R -m group:example:rwx foo/
 ~~~
-d : défaut
-
-

+`-d` : défaut
--- a/HowtoAlfresco.md
+++ b/HowtoAlfresco.md
@ -17,6 +17,7 @@ Installer JDBC :
 ~~~

 Si cela n'est pas fait, vous aurez les erreurs très explicites :
+
 ~~~
 Caused by: org.hibernate.HibernateException: Hibernate Dialect must be explicitly set)
 ~~~
--- a/HowtoAnsible.md
+++ b/HowtoAnsible.md
@ -69,9 +69,10 @@ Options utiles pour [ansible-playbook](https://manpages.debian.org/cgi-bin/man.c

 ## Howto Playbook

-~~~
-$ vim hello_World.yml
+Exemple de playbook `hello_world.yml` :

+~~~{.yaml}
+---
 - hosts: all

  tasks:
@ -94,7 +95,8 @@ Pour avoir la liste des modules utilisables dans *tasks* : `ansible-doc -l`

 Voici quelques exemples :

-~~~
+~~~{.yaml}
+---
 - name : exemple avec le module COMMAND
  command: date

@ -182,7 +184,6 @@ Voici quelques exemples :

 - name: exemple
  mount:
-
 ~~~

 #### replace: vs lineinfile:
@ -250,11 +251,13 @@ Hormis le fait de ranger/trier chaque tâche dans une catégorie, permet de limi
 ~~~

 Pour ne pas afficher les messages :
+
 ~~~
 $ ansible-playbook ... --skip-tags "message"
 ~~~

 On peut appliquer des tags à des rôles, ou voir directement n'éxecuter que certains tags :
+
 ~~~
 $ ansible-playbook ... --tags "configuration,packages"
 ~~~
@ -301,6 +304,7 @@ La configuration est lue dans l'ordre suivant :
 Permet d'indiquer la liste des machines concernées par Ansible (peut être limité lors de l'exécution de la commande par l'option `-l`) et de pouvoir les regrouper dans des groupes.

 Exemple:
+
 ~~~
 hostname.internal

@ -377,6 +381,7 @@ fatal: [test.evolix.net]: UNREACHABLE! => {"changed": false, "msg": "SSH encount
 Malheureusement, cela arrive souvent sur certaines machines (une?), mais pas de solutions pour le moment -> boire du café - beaucoup de café.

 Du côté de la machine distante, dans le fichier `/var/log/auth.log`:
+
 ~~~
 14:56:29 localhost sshd[19915]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=dual.evolix.net  user=service
 14:56:31 localhost sshd[19915]: Accepted password for service from 192.168.4.137 port 42502 ssh2
@ -387,6 +392,7 @@ Du côté de la machine distante, dans le fichier `/var/log/auth.log`:
 ~~~

 Et quand ça marche - la session ne se referme pas, et est réutilisé par les exécutions playbook suivantes:
+
 ~~~
 14:58:57 localhost sshd[20339]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=dual.evolix.net  user=service
 14:59:00 localhost sshd[20339]: Accepted password for service from 192.168.4.137 port 42511 ssh2
@ -423,6 +429,7 @@ fatal: [lenny.evolix.net]: FAILED! => {"changed": false, "failed": true, "msg":
 ### Vérifier un playbook

 * Vérifier la syntaxe :
+
 ~~~
 $ ansible-playbook --syntax-check my-experimental-playbook.yml
 ~~~
@ -430,11 +437,13 @@ $ ansible-playbook --syntax-check my-experimental-playbook.yml
 <http://www.yamllint.com/>

 * vérifier les action qui vont être faite (mode _dry-run_) sans rien exécuter :
+
 ~~~
 $ ansible-playbook --check my-experimental-playbook.yml
 ~~~

 * avoir le diff des fichiers modifiés (ne marche pas avec les modules replace/lineinfile à priori) :
+
 ~~~
 $ ansible-playbook --check --diff my-experimental-playbook.yml
 ~~~
@ -442,11 +451,13 @@ $ ansible-playbook --check --diff my-experimental-playbook.yml
 ### Plus d'infos sur module

 Lister les modules:
+
 ~~~
 # ansible-doc -l
 ~~~

 Avoir des infos sur un module:
+
 ~~~
 # ansible-doc shell
 > SHELL
@ -486,11 +497,13 @@ ou
 [<https://docs.ansible.com/ansible/raw_module.html>]

 (bzip2, php, ... selon services à installer)
+
 ~~~
 - raw: apt-get -y install python-simplejson [bzip2 php5-cli]
 ~~~

 * Si pas encore fait, donner droit mysql à l'utilisateur
+
 ~~~
 > GRANT ALL ON db.* TO 'user'@'localhost';
 ~~~
@ -498,21 +511,25 @@ ou
 ### Limiter l'exécution à certaines machines

 * Limiter aux groupes www et sql (www et sql peuvent en fait être indifféremment des groupes ou des serveurs) :
+
 ~~~
 $ ansible-playbook -l "www:sql" playbook.yml
 ~~~

 * limiter aux serveurs foo-www01, foo-lb01, foo-filer, etc… :
+
 ~~~
 $ ansible-playbook -l "foo-*" playbook.yml
 ~~~

 * limiter aux 10 premiers serveurs de l'inventaire (utile pour faire par paquets) :
+
 ~~~
 $ ansible-playbook -l "*[0:9]" playbook.yml
 ~~~

 * puis à ceux restant :
+
 ~~~
 $ ansible-playbook -l "*[10:]" playbook.yml
 ~~~
@ -573,6 +590,7 @@ Disponible aussi dans la conf du fichier `/etc/ansible/ansible.cfg`
 {% if python_is_installed is defined %}
 Ansible devrait marcher -pardi!
 {% endif %}
+
 ~~~
 <http://jinja.pocoo.org/docs/dev/templates/#builtin-tests>

@ -591,9 +609,11 @@ vars_prompt:
 tasks:
 - debug: var=prenom
 ~~~
+
 Malheureusement pour le moment, doit se situer avant `tasks`.

 Si on veut utiliser cette variable dans une tâche, il faut simplement utiliser le nom de la variable, et si on veut l'utiliser (explicitement) pour un play ne se trouvant pas dans le même fichier (donc ici la variable dans autre.yml s'appelera _prenom_de_autre_ et non prenom) :
+
 ~~~
 - include: './tasks/autre.yml'
  vars:
@ -660,18 +680,22 @@ Si ajouter avec `delegate_to`, seule cette machine executera cette tâche, sinon
 ~~~

 Par exemple pour l'installation de plusieurs nouveaux packages :
-~~~
+
+~~~{.yaml}
 ---
 - hosts: localhost

  tasks:
    - apt: name='{{ item }}' state=present
      with_items: [ 'cmatrix', 'tetrinet-server', 'tetrinet-client', 'xtel', 'xtell' ]
+
 ~~~
+
 Même si il y aura plusieurs packages installés, cela ne comptera que pour *un* changement (changed=1).
 Cette tâche appellera un par un les éléments de la liste (présent dans with_items) pour le module.

 En l'appelant :
+
 ~~~
 ansible-playbook -b --ask-become-pass --become-method='su' --become-user='root' apt.yml
 ~~~
@ -679,6 +703,7 @@ ansible-playbook -b --ask-become-pass --become-method='su' --become-user='root'
 #### with_nested

 Pour croiser les éléments des items -> *"with_nested"*.
+
 ~~~
  tasks:
    - include: "./ajout_utilisateur_sur_machine.yml"
@ -689,11 +714,13 @@ Pour croiser les éléments des items -> *"with_nested"*.
      - [ 'alice', 'bob' ]
      - [ 'machine1', 'machine2', 'machine-backup' ]
 ~~~
+
 Qui aura pour effet d'appeler le include avec comme argument : item[0]=alice, item[1]=machine1; puis item[0]=alice, item[0]=machine2; ... puis item[0]=bob, item[1]=machine1, ...

 #### with_dict

 Avec hash ...
+
 ~~~
 users:
  bob:
@ -713,6 +740,7 @@ users:
 ### Se connecter sous un autre utilisateur UNIX

 Par défaut, l'utilisateur se connectant sur le serveur distant est {{ ansible_user_id }} (càd uid courant UNIX). On peut soit le préciser dans le fichier de conf principal de ansible avec `remote_user : michu` ou en l'indiquant en argument lors de l'éxecution du playbook.
+
 ~~~
 ansible-playbook -u michu -k play.yml
 ~~~
@ -727,12 +755,14 @@ Sur tout les modules, chaque taches retourne un statut sur son résultat :

 Le soucis est qu'il parrait bien difficile pour le module shell de connaître après execution de la commande s'il y a eu modification. Par défaut, il y a changement - quand bien même l'utilisation du shell se fait pour afficher un résultat (id, date, ...).
 Pour éviter cela on peut mettre :
+
 ~~~
 - shell: date
  changed_when: false
 ~~~

 Ou donner une condition
+
 ~~~
 - shell: cat > {{ fichier }} </dev/null
  changed_when: {{ fichier.stats.exist }}
@ -764,7 +794,6 @@ service.evolix.net | SUCCESS => {
        "ansible_default_ipv4": {
 ...
 }
-
 ~~~

 ~~~
@ -772,7 +801,8 @@ $ ansible -m debug -a "var=hostvars['hostname']" localhost
 ~~~

 Pour récupérer toutes les adresses MAC des machines :
-~~~
+
+~~~{.yaml}
 ---
 - hosts: all
  gather_facts: true
@ -782,11 +812,13 @@ Pour récupérer toutes les adresses MAC des machines :
 ~~~

 que l'on pourra combiner par exemple avec un pipe en ligne de commande :
+
 ~~~
-ansible-playbook mac_address.yml | grep ansible_eth0.macaddress | sed 's/^\s*"ansible_eth0.macaddress": "\(.*\)"/\1/'
+$ ansible-playbook mac_address.yml | grep ansible_eth0.macaddress | sed 's/^\s*"ansible_eth0.macaddress": "\(.*\)"/\1/'
 ~~~

 Il est possible aussi d'accéder aux variables d'environnement shell :
+
 ~~~
 "{{ lookup('env','HOME') }}"
 ~~~
--- a/HowtoApache.md
+++ b/HowtoApache.md
@ -620,6 +620,7 @@ Alias /YYYYYY /var/www/
        DirectoryIndex page.html
 </Directory>
 ~~~
+
 *Remplacer XXX par le code erreur HTTP souhaité et YYYYY par le nom de Location souhaité (URL) - vu que global à tous les vhosts, prendre une chaîne aléatoire.*

 Ensuite, il suffit simplement d'ajouter le fichier dans la configuration générale d'Apache :
--- a/HowtoBNX2.md
+++ b/HowtoBNX2.md
@ -1,6 +1,7 @@
 **Cette page a été importée automatiquement de notre ancien wiki mais n'a pas encore été révisée.**

 bnx2 et bnx2x sont des firmwares utilisés (entre autres ?) par les cartes Broadcom NetXtreme II :
+
 ~~~
 0b:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)
 ~~~
--- a/HowtoBTRFS.md
+++ b/HowtoBTRFS.md
@ -20,33 +20,39 @@ apt install btrfs-tools
 ~~~

 On formate la partition
+
 ~~~
 mkfs.btrfs /dev/sda9
 ~~~

 Montage
+
 ~~~
 echo "/dev/sda9 /backup         btrfs    defaults        0       0" >> /etc/fstab
 mount /backup
 ~~~

 On créé des subvolume
+
 ~~~
 btrfs subvolume create /backup/aaa
 btrfs subvolume create /backup/bbb
 ~~~

 Lister les subvolumes
+
 ~~~
 btrfs subvolume list /backup/
 ~~~

 On peut faire des snapshots
+
 ~~~
 btrfs subvolume snapshot /backup/aaa /backup/bbb/snapshot1
 ~~~

 On peut supprimer des subvolumes (et snapshots)
+
 ~~~
 btrfs subvolume delete /bbb/bbb/snapshot1
 ~~~
@ -58,11 +64,13 @@ btrfs scrub status /backup/
 ~~~

 Check plus poussé sur une partition non montée
+
 ~~~
 btrfs check -p /dev/sda9
 ~~~

 Voir si la partition a présenté des erreurs
+
 ~~~
 btrfs dev stats /backup
 ~~~
--- a/HowtoBind.md
+++ b/HowtoBind.md
@ -339,6 +339,7 @@ template = /etc/log2mail/template.bind
 ~~~

 Et le contenu de _/etc/log2mail/template.bind_ :
+
 ~~~
 From: %f
 To: %t
@ -364,21 +365,25 @@ On peut faire du GeoDNS de 2 façons avec Bind :
 ### À l'aide de vues/acl

 * Récupérer le script :
+
 ~~~
 $ wget <http://phix.me/geodns/GeoIP.py>
 ~~~

 * installer les dépendances nécessaires :
+
 ~~~
 # apt install python-mpmath
 ~~~

 * exécuter le script. Il génèrera un fichier un fichier GeoIP.acl, avec une ACL par pays. Il est conseillé de l'exécuter avec un utilisateur Unix spécifique :
+
 ~~~
 $ ./GeoIP.py MaxMind
 ~~~

 * Configurer Bind pour servir une zone différente en fonction des pays :
+
 ~~~
 include "/etc/bind/GeoIP.acl";

--- a/HowtoCUPS.md
+++ b/HowtoCUPS.md
@ -23,11 +23,13 @@ Pour activer le backend smb:// il faut installer *smbclient* qui contient notamm
 L'interface web d'administration de CUPS est accessible sur le port 631 : <http://192.0.32.10:631>

 * Autoriser l'utilisateur _foo_ à accéder aux tâches d'administration sur l'interface web :
+
 ~~~
 adduser foo lpadmin
 ~~~

 * Par défaut, les tâches d'administrations ne sont autorisées que depuis _localhost_. Pour autoriser une IP ou réseau en plus :
+
 ~~~
 # Fichier /etc/cups/cupsd.conf

@ -40,6 +42,7 @@ adduser foo lpadmin
 ### Détection automatique d'imprimantes partagées

 Par défaut CUPS tente de découvrir les imprimantes partagées par d'autres systèmes sur le réseau, et les affiche dans sa liste, avec une URI=/dev/null. Pour ne pas avoir ce comportement, décocher la case « Afficher les imprimantes partagées par d'autres systèmes » dans « Administration du serveur » dans l'interface d'admin, puis supprimer le cache :
+
 ~~~
 # /etc/init.d/cups stop && rm /var/cache/cups/remote.cache && /etc/init.d/cups start
 ~~~
--- a/HowtoChiffrementData.md
+++ b/HowtoChiffrementData.md
@ -13,6 +13,7 @@ Inspiré de <http://www.debian-administration.org/articles/469>
 ### Creation

 En renseignant un mot de passe manuellement :
+
 ~~~
 # cryptsetup --verbose --verify-passphrase luksFormat /dev/md7

@ -21,17 +22,18 @@ WARNING!
 This will overwrite data on /dev/md7 irrevocably.

 Are you sure? (Type uppercase yes): YES
-Enter LUKS passphrase: 
-Verify passphrase: 
+Enter LUKS passphrase:
+Verify passphrase:
 Command successful.
 # cryptsetup luksOpen /dev/md7 crypt_md7
-Enter LUKS passphrase: 
+Enter LUKS passphrase:
 key slot 0 unlocked.
 Command successful.
 # mkfs.ext3 /dev/mapper/crypt_md7
 ~~~

 En utilisant un fichier comme clef de chiffrement :
+
 ~~~
 # dd if=/dev/random of=/root/.keyfile bs=1 count=256
 # cryptsetup --verbose --key-size=256 luksFormat /dev/md7 /root/.keyfile
@ -40,12 +42,14 @@ En utilisant un fichier comme clef de chiffrement :
 ### Utilisation

 Voir si une partition est de type LUKS :
+
 ~~~
 # cryptsetup isLuks /dev/hda7
 # cryptsetup luksDump /dev/hda7
 ~~~

 Ouvrir une partition chiffrée :
+
 ~~~
 # cryptsetup luksOpen /dev/mapper/vol1-crypto_test crypto_test
 # cryptsetup luksOpen /dev/hda7 hda7_crypt
@ -53,16 +57,19 @@ Ouvrir une partition chiffrée :


 Ouvrir une partition chiffrée avec un fichier de clef :
+
 ~~~
 # cryptsetup luksOpen --key-file /root/.keyfile /dev/md7 supersecretdata
 ~~~

 Info sur la partition chiffrée :
+
 ~~~
 # cryptsetup status crypto_test
 ~~~

 Fermer une partition chiffrée :
+
 ~~~
 # cryptsetup luksClose crypto_test
 ~~~
@ -70,24 +77,27 @@ Fermer une partition chiffrée :
 ### Gestion des mots de passe

 Ajouter un mot de passe :
+
 ~~~
 # cryptsetup luksAddKey /dev/hda7
-Enter any LUKS passphrase: 
+Enter any LUKS passphrase:
 key slot 1 unlocked.
-Enter new passphrase for key slot: 
-Verify passphrase: 
+Enter new passphrase for key slot:
+Verify passphrase:
 Command successful.
 ~~~

-Rem : 
+Rem :
 Sur des vieilles versions, il fallait avoir la partition non dechiffrée : <http://bugs.debian.org/460409>

 Pour supprimer un mot de passe, on regarde le n° du mot de passe avec :
+
 ~~~
 # cryptsetup luksDump /dev/hda7
 ~~~

 Puis on le supprime avec la commande :
+
 ~~~
 # cryptsetup luksKillSlot /dev/hda7 <n°>
 ~~~
@ -111,11 +121,14 @@ Pour Restaurer l'entête :
 ## FAQ

 Si vous obtnez un message de ce type :
+
 ~~~
 Command failed: Failed to setup dm-crypt key mapping.
 Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/md1 contains at least 133 sectors
 ~~~
+
 La solution est :
+
 ~~~
 # modprobe dm-mod
 ~~~
@ -123,6 +136,7 @@ La solution est :
 ## Notes sur les algorithmes de chiffrement

 Pour utiliser un algorithme de chiffrement spécifique, il faut le préciser au moment de la création de la partition :
+
 ~~~
 #  cryptsetup --verbose --cipher=aes-cbc-essiv:sha256 --verify-passphrase luksFormat /dev/md7
 ~~~
@ -130,4 +144,4 @@ Pour utiliser un algorithme de chiffrement spécifique, il faut le préciser au
 Le chiffrement aes-cbc-essiv est le chiffrement par défaut de cryptsetup pour les noyaux supérieurs au 2.6.10, car il corrige une vulnérabilité potentielle du chiffrement aes-cbc-plain.
 Une autre méthode de chiffrement utilisée avec l'algorithme AES (Rijndael) est le mode XTS, qui est réputé plus résistants aux attaques par watermarking, mais nécessite un module spécifique (judicieusement nommé xts.ko) et une clef d'initialisation du double de la taille de la clef finale (voir <http://en.wikipedia.org/wiki/Disk_encryption_theory#XEX-based_tweaked-codebook_mode_with_ciphertext_stealing_.28XTS.29)>

-Les autres algorithmes dignes d’intérêt sont twofish et serpent, deux compétiteurs de l'AES face à Rijndael.
+Les autres algorithmes dignes d’intérêt sont twofish et serpent, deux compétiteurs de l'AES face à Rijndael.
--- a/HowtoDiscourse.md
+++ b/HowtoDiscourse.md
@ -7,21 +7,27 @@ La methode d'installation officielle de Discourse se fait avec docker. Voici les
 ~~~
 # ln -s /usr/bin/aptitude /usr/bin/apt-get
 ~~~
+
 ~~~
 # wget -qO- <https://get.docker.io/> | sh
 ~~~
+
 ~~~
 # mkdir /var/discourse
 ~~~
+
 ~~~
 # git clone <https://github.com/discourse/discourse_docker.git> /var/discourse
 ~~~
+
 ~~~
 # cd /var/discourse
 ~~~
+
 ~~~
 # cp samples/standalone.yml containers/app.yml
 ~~~
+
 ~~~
 # vim containers/app.yml
 ~~~
@ -62,12 +68,15 @@ On peut ensuite faire tourner Discourse avec un utilisateur simple
 ~~~
 # chown -R foo:foo /var/discourse/
 ~~~
+
 ~~~
 # usermod -aG docker foo
 ~~~
+
 ~~~
 $ ./launcher bootstrap app
 ~~~
+
 ~~~
 $ ./launcher start app
 ~~~
@ -77,11 +86,13 @@ Modifier la conf postfix en ajoutant 172.16.0.0/12 à la variable mynetworks afi
 Maintenance : 

 Lors de certaines MAJ via discourse il peut être necessaire une fois la MAJ terminée de reconstruire le conteneur (au cours de cette opération le conteneur sera stoppé et relancé)
+
 ~~~
 $ ./launcher rebuild app
 ~~~

 En cas d'erreur sur l'application il est possible de rentrer dans le conteneur pour debug
+
 ~~~
 $ ./launcher ssh app
 ~~~
--- a/HowtoDovecot.md
+++ b/HowtoDovecot.md
@ -33,7 +33,6 @@ disable_plaintext_auth = no

 Il faut patcher le master.cf de postfix ainsi :

-
 ~~~
 -  flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${recipient}                      
 +  flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -a ${recipient} -d ${user}@${nexthop}
@ -65,7 +64,6 @@ namespace inbox {
  }
  prefix =
 }
-
 ~~~

 ### SSL/TLS
@ -169,7 +167,7 @@ require ["fileinto", "copy", "vacation", "variables"];
 # Exemple d'une règle de filtrage
 if header :contains ["Subject"] ["testsieve"] {
  fileinto "Test";
-} 
+}

 # Exemple de message "vacation"
 if header :matches "subject" "*" {
@ -192,6 +190,7 @@ On peut aussi utiliser des outils pour générer les règles comme Roundcube, Ho
 ### Déduplication des mails entrants

 Pour réaliser un équivalent de la règle procmail suivante :
+
 ~~~
 :0 Wh: msgid.lock
 | formail -D 8192 $HOME/.msgid.lock
@ -235,7 +234,7 @@ protocol imap {

 Ensuite, il suffit de créer un répertoire _dovecot.rawlog_ dans le $HOME
 de l'utilisateur (accessible en écriture évidemment), et toutes les commandes
-IMAP passées seront stockées dans des fichiers : <annee><mois><jour>-.*.{in,out}
+IMAP passées seront stockées dans des fichiers : `<annee><mois><jour>-.*.{in,out}`

 ### Debug pour l'authentification

@ -256,6 +255,7 @@ login_max_processes_count = 256
 ~~~

 Il faut en parallèle augmenter la limite sur le nombre de fichiers ouverts, dans _/etc/default/dovecot_ :
+
 ~~~
 ulimit -n 5696
 ~~~
@ -335,4 +335,3 @@ dovecot: imap(foo): Fatal: master: service(imap): child 666 returned error 83 (O
 ~~~

 Vous pouvez augmenter la mémoire _vsz_limit = 512M_ dans le service imap.
-
--- a/HowtoEjabberd.md
+++ b/HowtoEjabberd.md
@ -29,7 +29,7 @@ _xmpp-server._tcp       IN      SRV 0 0 5269 im
 im                      IN      A   192.0.2.42
 ~~~

-Note : __xmpp-server_ est facultatif, mais recommandé pour communiquer avec d'autres serveurs XMPP.
+Note : _xmpp-server_ est facultatif, mais recommandé pour communiquer avec d'autres serveurs XMPP.

 ## Configuration

@ -50,11 +50,13 @@ Ejabberd supporte plusieurs backends externes pour l'authentification (MySQL, LD
 Pour utiliser un annuaire LDAP :

 * commenter `{auth_method, internal}.` pour ne faire _que_ de l'authentification sur LDAP. Pour utiliser plusieurs méthodes d'authentification, il est possible de passer une liste comme ceci :
+
 ~~~
 {auth_method, [ldap, internal]}.
 ~~~

 * Décommenter/modifier les directives suivantes :
+
 ~~~
 %%
 %% Authentication using LDAP
@ -91,6 +93,7 @@ Pour utiliser un annuaire LDAP :
 ### Optimisation

 Par défaut, le support du multi-cœur n'est pas forcément désactivé. Pour l'activer si le processeur le supporte, éditer le fichier _/etc/default/ejabberd_ :
+
 ~~~
 SMP=auto
 ~~~
@ -112,7 +115,6 @@ jdoe

 # ejabberdctl kick jdoe im.example.com
 # ejabberdctl unregister jdoe im.example.com
-
 ~~~

 ## Sauvegarde / migration
@ -136,4 +138,4 @@ Par exemple pour migrer le répertoire des utilisateurs (roster) :
        {"bob","gmail.com",[]},
        [],both,none,[],<<>>,[]}.
 [...]
-~~~
+~~~
--- a/HowtoFail2Ban.md
+++ b/HowtoFail2Ban.md
@ -25,13 +25,12 @@ jail.conf est le fichier principal activant (ou pas) les règles avec différent

 ~~~
 [ssh]                        
-                             
+
 enabled = true               
 port    = ssh                
 filter  = sshd               
-logpath  = /var/log/auth.log 
+logpath  = /var/log/auth.log
 maxretry = 6                 
-
 ~~~

 On peut régler plusieurs paramètres, comme le maxretry (nombres d'échecs) dans la section [DEFAULT] ou pour chaque applicatif.
@ -82,14 +81,14 @@ Filtre dovecot, filter.d/dovecot-pop3imap.conf
 ~~~
 [Definition]                                                                                                           
 failregex = (?: pop3-login|imap-login): .*(?:Authentication failure|Aborted login \(auth failed|Aborted login \(tried to use disabled|Disconnected \(auth failed|Aborted login \(\d+ authentication attempts).*rip=(?P<host>\S*),.*
-ignoreregex =                                                                                                          
+ignoreregex =
 ~~~

 ## Courier

 Il suffit d'activer la règle courierlogin prédéfinie :

-~~~
+~~~{.ini}
 [courierauth]

 enabled  = true
@ -102,7 +101,7 @@ logpath  = /var/log/mail.log

 Il faut modifier la règle SASL prédéfinie :

-~~~
+~~~{.ini}
 [sasl]

 enabled  = true
@ -141,7 +140,7 @@ failregex = ^ -.*GET

 Finalement, on modifie `/etc/fail2ban/jail.local` pour ajouter une des deux règles suivantes. Avec cette règle, une personne qui accède plus de 300 fois à une page web sur notre serveur web en 5 minutes va être bannie pendant la période de temps par défaut:

-~~~
+~~~{.ini}
 [ddos-<http-apache>]
 enabled = true
 port = <http,https>
@ -150,7 +149,8 @@ logpath = /var/log/apache2/access.log
 maxretry = 300
 findtime = 300
 ~~~
-~~~
+
+~~~{.ini}
 [ddos-<http-nginx>]
 enabled = true
 port = <http,https>
@ -178,7 +178,7 @@ failregex = <HOST> -.*"POST.*/wp-login.php HTTP.* 200

 Finalement, on modifie `/etc/fail2ban/jail.local` pour ajouter une règle. Avec cette règle, une personne qui accède plus de 5 fois à la page `/wp-login.php` ou à `/xmlrpc.php` dans une période d'une minute va être bannie pendant la période de temps par défaut:

-~~~
+~~~{.ini}
 [apache-wp]
 enabled  = true
 port     = <http,https>
@ -196,7 +196,7 @@ Elle est cependant peu invasive car elle fait installe le plugin dans [wp-conten

 Il faut tout d'abord s'assurer que notre serveur web enregistre des logs d'accès. Par la suite, on installe le plugin dans `wp-content/mu-plugins/401-on-login-fail.php`:

-~~~
+~~~{.php}
 <?php
 function my_login_failed_401() {
    status_header( 401 );
@ -213,7 +213,7 @@ On ajoute ensuite un filtre à `fail2ban` dans `/etc/fail2ban/filter.d/apache-wp

 Finalement, on modifie `/etc/fail2ban/jail.local` pour ajouter une règle. Avec cette règle, une personne qui accède plus de 5 fois à la page `/wp-login.php` ou à `/xmlrpc.php` dans une période d'une minute va être bannie pendant la période de temps par défaut:

-~~~
+~~~{.ini}
 [apache-wp]
 enabled  = true
 port     = <http,https>
@ -232,7 +232,7 @@ Parce qu'elle nécessite l'installation et la mise à jour régulière d'un plug

 On commence tout d'abord par [installer le plugin](https://wordpress.org/plugins/wp-fail2ban/). Une fois que cela est fait, on ajoute les deux filtres suivants, respectivement dans `etc/fail2ban/filter.d/wordpress-hard` et `etc/fail2ban/filter.d/wordpress-soft`:

-~~~
+~~~{.ini}
 # Fail2Ban configuration file hard
 #
 # Author: Charles Lecklider
@ -267,7 +267,8 @@ failregex = ^%(__prefix_line)sAuthentication attempt for unknown user .* from <H
 #
 ignoreregex =
 ~~~
-~~~
+
+~~~{.ini}
 # Fail2Ban configuration file soft
 #
 # Author: Charles Lecklider
@ -303,7 +304,7 @@ ignoreregex =

 Finalement, on modifie `/etc/fail2ban/jail.local` pour ajouter les règles suivantes. Avec cette règle, une personne qui tente de se connecter avec un compte inexistant ou qui n'arrive pas à se connecter 5 fois sera bannie pendant la période de temps par défaut:

-~~~
+~~~{.ini}
 [wordpress-hard]
  enabled = true
  filter = wordpress-hard
@ -338,9 +339,9 @@ On ajoute ensuite un filtre à `fail2ban` dans `/etc/fail2ban/filter.d/owncloud.

 Finalement, on modifie `/etc/fail2ban/jail.local` pour ajouter une règle. Avec cette règle, une personne qui n'arrive pas à se connecter 5 fois dans une période de 10 minutes sera bannie pendant la période de temps par défaut:

-~~~
+~~~{.ini}
 [owncloud]
-  enabled = true 
+  enabled = true
  filter  = owncloud  
  port    = <http,https>
  logpath = /var/log/owncloud.log
@ -352,14 +353,14 @@ Finalement, on modifie `/etc/fail2ban/jail.local` pour ajouter une règle. Avec

 Il faut tout d'abord s'assurer que notre serveur web enregistre des logs d'accès. On ajoute ensuite un filtre à `fail2ban` dans `/etc/fail2ban/filter.d/apache-joomla.conf`:

-~~~
+~~~{.ini}
 [Definition]
  failregex = <HOST> -.*"POST.*/administrator/index.php.*
 ~~~

 Finalement, on modifie `/etc/fail2ban/jail.local` pour ajouter une règle. Avec cette règle, une personne qui accède plus de 5 fois à la page `/administrator/index.php` dans une période d'une minute va être bannie pendant la période de temps par défaut:

-~~~
+~~~{.ini}
 [apache-joomla]
  enabled  = true
  port     = <http,https>
@ -373,14 +374,14 @@ Finalement, on modifie `/etc/fail2ban/jail.local` pour ajouter une règle. Avec

 Il faut tout d'abord s'assurer que notre serveur web enregistre des logs d'accès. On ajoute ensuite un filtre à `fail2ban` dans `/etc/fail2ban/filter.d/apache-prestashop.conf`:

-~~~
+~~~{.ini}
 [Definition]
  failregex = <HOST> -.*"POST.*/login.*
 ~~~

 Finalement, on modifie `/etc/fail2ban/jail.local` pour ajouter une règle. Avec cette règle, une personne qui accède plus de 10 fois à la page de connexion pour un compte utilisateur dans une période d'une minute va être bannie pendant la période de temps par défaut:

-~~~
+~~~{.ini}
 [apache-prestashop]
  enabled  = true
  port     = <http,https>
@ -388,4 +389,4 @@ Finalement, on modifie `/etc/fail2ban/jail.local` pour ajouter une règle. Avec
  logpath  = /var/log/apache2/access.log
  maxretry = 10
  findtime = 60
-~~~
+~~~
--- a/HowtoGitDaemon.md
+++ b/HowtoGitDaemon.md
@ -5,10 +5,13 @@
 ## Prérequis

 Installation du service git-daemon :
+
 ~~~
-aptitude install git-daemon-sysvinit 
+aptitude install git-daemon-sysvinit
 ~~~
+
 Configuration du démon Git /etc/default/git-daemon :
+
 ~~~
 cat > /etc/default/git-daemon <<GD
 GIT_DAEMON_ENABLE=true
@ -16,7 +19,9 @@ GIT_DAEMON_USER=gitdaemon
 GIT_DAEMON_OPTIONS="--interpolated-path=/home/%H/repositories/%D"
 GD
 ~~~
+
 Éditer le fichier /etc/init.d/git-daemon et commenter la ligne suivante (34) :
+
 ~~~
 #DAEMON_ARGS="$DAEMON_ARGS --base-path=$GIT_DAEMON_BASE_PATH $GIT_DAEMON_DIRECTORY"
 ~~~
@ -34,15 +39,21 @@ Choix de l'utilisateur $GIT :
 ~~~
 GIT='git'
 ~~~
+
 Crée un lien symbolique car git-daemon accède aux dépôts via $GIT.votre-domaine.tld  :
+
 ~~~
 ln -s /home/$GIT/ /home/$GIT.$(hostname -d)
 ~~~
+
 Donne l'accès en lecture au dépôts à l'utilisateur gitdaemon :
+
 ~~~
 addgroup gitdaemon $GIT
 ~~~
+
 Redémarrage du démon git :
+
 ~~~
 service git-daemon restart
-~~~
+~~~
--- a/HowtoGitWeb.md
+++ b/HowtoGitWeb.md
@ -5,6 +5,7 @@
 ## Prérequis

 Installation de gitweb et highlight :
+
 ~~~
 aptitude install gitweb highlight
 ~~~
@ -12,15 +13,20 @@ aptitude install gitweb highlight
 ### Configuration Nginx

 Installation de fcgiwrapper :
+
 ~~~
 aptitude install fcgiwrap
 ~~~
+
 Modifier /etc/gitweb.conf et remplacer les lignes suivantes :
+
 ~~~
 $projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/pub/git";
 $projects_list = $ENV{'GITWEB_PROJECTLIST'} || $projectroot;
 ~~~
+
 Rajout de la conf highlight :
+
 ~~~
 cat >> /etc/gitweb.conf <<CONF
 \$feature{'highlight'}{'default'} = [1];
@ -38,7 +44,9 @@ Choix de l'utilisateur $GIT :
 ~~~
 GIT='git'
 ~~~
+
 Configuration du vhost :
+
 ~~~
 cat > /etc/nginx/sites-available/gitweb_$GIT <<VHOST
 server {
@ -62,15 +70,21 @@ server {
 }
 VHOST
 ~~~
+
 Activation du vhost :
+
 ~~~
 ln -s /etc/nginx/sites-available/gitweb_$GIT /etc/nginx/sites-enabled/gitweb_$GIT
 ~~~
+
 Donne l'accès en lecture au dépôts à l'utilisateur www-data :
+
 ~~~
 addgroup www-data $GIT
 ~~~
+
 Redémarre le démon fcgiwrap :
+
 ~~~
 service fcgiwrap restart
-~~~
+~~~
--- a/HowtoHG.md
+++ b/HowtoHG.md
@ -15,7 +15,7 @@ Sous Debian, pour installer Mercurial :
 Configurer son client :

 ~~~
-$ cat ~/.hgrc 
+$ cat ~/.hgrc
 [ui]
 username = John Doe <jdoe@example.com>
 verbose = True
@ -42,7 +42,6 @@ updating working directory
 15 files updated, 0 files merged, 0 files removed, 0 files unresolved
 ~~~

-
 Ajouter un nouveau fichier au dépôt :

 ~~~
@ -50,6 +49,7 @@ $ hg add monfichier
 ~~~

 Valider les modifications apportées au dépôt :
+
 ~~~
 $ hg commit
 Mon message de commit
@ -61,13 +61,14 @@ HG: changed monfichier
 ~~~

 Envoyer les modifications sur le dépôt :
+
 ~~~
 $ hg push
 pushing to <http://hg.example.com/repo1>
 http authorization required
 realm: Password protected
 user: user@host
-password: 
+password:
 searching for changes
 adding changesets
 adding manifests
@ -76,6 +77,7 @@ added 1 changesets with 1 changes to 1 files
 ~~~

 Récupérer la dernière version d'un dépôt :
+
 ~~~
 $ hg pull
 searching for changes
@ -99,7 +101,8 @@ HGWEB sert à naviguer dans les dépôts par une interface web, mais surtout
 # mkdir /home/hg
 # cp /usr/share/doc/mercurial-common/examples/hgweb.wsgi /home/hg/
 # sed -i 's@/path/to/repo/or/config@/home/hg/hgweb.config@' /home/hg/hgweb.wsgi
-# cat /home/hg/hgweb.config 
+
+# cat /home/hg/hgweb.config
 [paths]
 test = /home/hg/test
 coin = /home/hg/coin
@ -114,7 +117,7 @@ push_ssl = false
 Il reste maintenant à activer un VirtualHost.
 Par exemple avec un authentification LDAP :

-~~~
+~~~{.apache}
 <VirtualHost *:80>

  ServerName hg.example.com
@ -149,6 +152,7 @@ Il reste à gérer les droits du répertoire /home/hg devant appartenir à l'uti
 ## FAQ

 * Lorsque je push en SSH, j'obtiens :
+
 ~~~
 remote: abandon : There is no Mercurial repository here (.hg not found) !
 abandon : no suitable response from remote hg !
@ -157,9 +161,10 @@ abandon : no suitable response from remote hg !
 Il faut mettre un double slash (//) après le hostname. Voir notamment <http://jehaisleprintemps.net/blog/fr/2009/05/10/mercurial-et-ssh-le-piege-eviter/>

 * Lorsque je push en HTTP, j'obtiens :
+
 ~~~
 ssl required
 ~~~

 Il faut passer en HTTPS. Si vraiment, on veut le faire en HTTP non sécurisé, il faut le forcer au niveau du serveur via _push_ssl = false_
-Voir <http://mercurial.selenic.com/wiki/FAQ#FAQ.2FCommonProblems.I_get_an_.22ssl_required.22_error_message_when_trying_to_push_changes>
+Voir <http://mercurial.selenic.com/wiki/FAQ#FAQ.2FCommonProblems.I_get_an_.22ssl_required.22_error_message_when_trying_to_push_changes>
--- a/HowtoHTTP.md
+++ b/HowtoHTTP.md
@ -112,7 +112,7 @@ Server: Apache

 ~~~
 # apt install libwww-perl
-~~~~
+~~~

 Voir <http://gcolpart.evolix.net/blog21/faire-du-postgethead-en-ligne-de-commande/>

@ -130,6 +130,7 @@ Exemples d'utilisation :
 $ wget --limit-rate=100K -A *.mpeg -r http://dc5video.debian.net/2005-07-09/
 $ http_proxy=http://192.168.14.4:3128 wget -p -H www.thomascook.fr
 ~~~
+
 Voici les différentes options possibles :

 * `-c` : pour reprendre un téléchargement déjà commencé
--- a/HowtoHearthbeat.md
+++ b/HowtoHearthbeat.md
@ -7,6 +7,7 @@ Documentation officielle : <http://linux-ha.org/wiki/Heartbeat>
 ## Tuer un Hearthbeat planté

 Pour tuer un heathbeat planté, il faut
+
 ~~~
 root@> ps aux |grep hearthbeat
 root@> kill -9 #pid
@ -24,20 +25,24 @@ Installation : `aptitude install heartbeat cluster-glue`
 [[Image(heartbeat_simple.png, 33%)]]

 Dans un premier temps il faut définir les nom d'hôtes dans /etc/hosts ou avoir un serveur DNS qui les résoud.
+
 ~~~
 192.168.0.1 ha-1
 192.168.0.2 ha-2
 ~~~

 Il faut ensuite authentifier les nœuds, en placant un md5 commun aux 2 dans /etc/ha.d/authkeys. Par exemple avec ` md5sum <<< 'un_mot_de_passe'`
+
 ~~~
 auth 1
 1 md5 12499c1b5fdbf25aa4abc05176904ca7
 ~~~
+
 Ensuite il faut s'assurer que ce fichier ne soit lisible que par le root, pour cela on fait un chmod 600 sur le fichier authkeys.

 Puis, le fichier de configuration, le plus simple possible :
 Ici celui de ha-1.
+
 ~~~
 #
 #       keepalive: how many seconds between heartbeats
@ -62,11 +67,14 @@ udp     eth0
 node    ha-1
 node    ha-2
 ~~~
+
 Sur ha-2 il faut faire le même fichier de configuration mais remplacer la ligne `ucast eth0 192.168.0.2` par `ucast eth0 192.168.0.1`
 Enfin, il faut indiquer le maître et l'adresse IP virtuelle que l'on veut utiliser, ainsi éventuellement qu'un service tel que apache2 dans le fichier `/etc/ha.d/haresources`
+
 ~~~
 ha-1 192.168.0.10 apache2
 ~~~
+
 Puis démarrer le service sur les 2 machines `/etc/init.d/heartbeat start`[[BR]]

 On peut ensuite vérifier le bon fonctionnement avec juste un `ifconfig`[[BR]]
@ -79,7 +87,7 @@ Si l'on souhaite que le master ne reprenne pas la main s'il est à nouveau up ap
 Pour utiliser _crm_ il faut l'activer dans le `ha.cf` en mettant ` crm yes `[[BR]]


-Il y a plusieurs façon de configurer crm : 
+Il y a plusieurs façon de configurer crm :

 * Le shell crm, un outil en ligne de commande puissant, cachant la configuration de type xml, avec une aide en ligne et la complétion ;
 * High availability web konsole, un interface web en AJAX. Encore en développement ;
@ -95,6 +103,7 @@ configure
 template
 list templates
 ~~~
+
 Les templates par défaut sont les suivants :

 ~~~
@ -103,7 +112,7 @@ virtual-ip   ocfs2        gfs2         filesystem   apache       clvm
 gfs2-base
 ~~~

-On veut utiliser le template apache : 
+On veut utiliser le template apache :
 ~~~
 new web apache
 edit
@ -150,11 +159,11 @@ Le fichier de template apache ressemble à ceci :
 # specify it here either in CIDR format or as a dotted quad
 # (for example: 24 or 255.255.255.0)

-%% netmask 
+%% netmask

 # Need LVS support? Set this to true then.

-%% lvs_support 
+%% lvs_support

 %name apache

@ -180,7 +189,7 @@ Le fichier de template apache ressemble à ceci :
 # Name the apache resource
 # (for example: web-1)

-%% id web-1 
+%% id web-1

 # The full pathname of the Apache configuration file

@ -190,12 +199,12 @@ Le fichier de template apache ressemble à ceci :

 # Extra options to apply when starting apache. See man <httpd(8).>

-%% options 
+%% options

 # Files (one or more) which contain extra environment variables,
 # such as /etc/apache2/envvars

-%% envfiles 
+%% envfiles

 # Don't edit anything below this line.

@ -216,7 +225,6 @@ monitor apache 120s:60s

 group %apache:id
 	apache virtual-ip
-
 ~~~

 ~~~
@ -232,15 +240,17 @@ location web-1-pref web-1 100: ha-1
 property stonith-enabled=false
 commit
 ^d
+
 ~~~
 Il faut ensuite attendre que la configuration se propage sur le deuxième nœud.
 ### Divers

 En clonant des machines virtuelles, Heartbeat garde le même uuid qu'il a généré auparavant, ce qui pose quelques soucis, car il ne sait plus qui est qui ... et dans le doute il reboot !
 Pour re-générer les uuid, il faut supprimer le fichier /var/lib/heartbeat/hb_uuid
-Logs : 
+Logs :
+
 ~~~
-root@ha-2:~# grep -B 10 Reboot /var/log/syslog 
+root@ha-2:~# grep -B 10 Reboot /var/log/syslog
 May  9 11:24:18 client cib: [1923]: info: register_heartbeat_conn: Hostname: ha-2
 May  9 11:24:18 client cib: [1923]: info: register_heartbeat_conn: UUID: 66a8d84d-3fc6-402e-aa46-d433a1d5281b
 May  9 11:24:18 client cib: [1923]: info: ccm_connect: Registering with CCM...
--- a/HowtoHtop.md
+++ b/HowtoHtop.md
@ -6,7 +6,7 @@

 Htop depuis la version fourni dans squeeze dispose de sondes permettant d'identifier les écriture, lecture et performance sur les I/O.

-On peut l'activer via le menu : 
+On peut l'activer via le menu :

 F2-->Columns-->Available Columns --> Ajouter les IO_* (F5, attention ils sont tout en bas de la liste !)

@ -15,4 +15,9 @@ Sinon voici un .htoprc qui contient les colonnes avec les sondes d'I/O
 ~~~
 fields=0 48 17 18 38 39 40 2 46 47 62 63 64 49 1
 ~~~
-62 63 64 concernent les colonnes pour les sondes d'I/O.
+
+62 63 64 concernent les colonnes pour les sondes d'I/O.
+
+## Exploration avancée
+
+Cet article explique en détail toutes les fonctionnalités de Htop et les outils sur lesquels il se base pour obtenir les informations : <https://peteris.rocks/blog/htop/>
--- a/HowtoISAKMPD.md
+++ b/HowtoISAKMPD.md
@ -216,16 +216,19 @@ Pour relancer un VPN il suffit de récupérer le nom des variables isakmpd gén
 ### Debug IPsec

 Eteindre isakmpd :
+
 ~~~
 # /etc/rc.d/isakmpd stop
 ~~~
-Dans une console : 
+
+Dans une console :
+
 ~~~
 # isakmpd -d -DA=90 -K
 ~~~
+
 Dans une autre console :
+
 ~~~
 # ipsecctl -f /etc/ipsec.conf
 ~~~
-
-
--- a/HowtoISCSI.md
+++ b/HowtoISCSI.md
@ -20,7 +20,7 @@ S'assurer que _iscsid_ est bien démarré :
 # /etc/init.d/open-iscsi start
 ~~~

-Scanner les devices disponibles : 
+Scanner les devices disponibles :

 ~~~
 # iscsiadm -m discovery -t sendtargets -p IP_ADDRESS
@ -30,7 +30,7 @@ Scanner les devices disponibles :

 Une configuration simple est lorsque vous avez une liaison iSCSI via une seule interface Ethernet.

-Exemple pour attacher le device iSCSI : 
+Exemple pour attacher le device iSCSI :

 ~~~
 # iscsiadm --mode node --targetname qn.2002-10.com.infortrend:raid.sn8128457.001 --portal IP_ADDRESS:3260 --login
@ -38,7 +38,7 @@ Logging in to [iface: default, target: iqn.2002-10.com.infortrend:raid.sn8128457
 Login to [iface: default, target: iqn.2002-10.com.infortrend:raid.sn8128457.001, portal: IP_ADDRESS,3260]: successful
 ~~~

-Un dmesg nous confirme que le device iSCSI est attaché : 
+Un dmesg nous confirme que le device iSCSI est attaché :

 ~~~
 [589633.268035] Loading iSCSI transport class v2.0-870.
@ -52,8 +52,7 @@ Un dmesg nous confirme que le device iSCSI est attaché :
 [590318.568943] sd 2:0:0:0: [sda] 19528073216 512-byte logical blocks: (9.99 TB/9.09 TiB)
 [590318.598211] sd 2:0:0:0: [sda] Write Protect is off
 [590318.598214] sd 2:0:0:0: [sda] Mode Sense: 83 00 00 08
-[590318.599120] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or
- FUA
+[590318.599120] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 [590318.664632]  sda: unknown partition table
 [590318.703094] sd 2:0:0:0: [sda] Attached SCSI disk
 [590318.725349] ses 2:0:0:1: Attached Enclosure device
@ -62,18 +61,21 @@ Un dmesg nous confirme que le device iSCSI est attaché :
 ### Gestion des volumes

 Pour lister les sessions iSCSI ouvertes :
+
 ~~~
 # iscsiadm -m session
 ~~~

 Pour se déconnecter proprement d'un target (après avoir démonté les disques) :
+
 ~~~
 # iscsiadm -m node -u
 ~~~

 Pour déconnecter un seul LUN d'un target :
+
 ~~~
-# iscsiadm -m node –op=delete -T 
+# iscsiadm -m node –op=delete -T
 # iscsiadm -m node –login -T [iqn du LUN]
 ~~~

@ -87,11 +89,13 @@ Lorsqu'on lance la détection des volumes d'un target, ou que l'on se connecte
 Ces fichiers sont relativement simples à comprendre, mais une option nous intéresse plus particulièrement :

 Dans le répertoire /etc/iscsi/nodes sont stockés les nodes auxquels nous nous sommes déjà connecté sous la forme :
+
 ~~~
 [iqn]/[ip],[port],1/default
 ~~~

 Par exemple, pour un SAN MD3600i en multipath nous avons :
+
 ~~~
 # ls -l /etc/iscsi/nodes/iqn.1984-05.com.dell\:powervault.md3600i.36782bcb00050034200000xxxxxxxxxx/
 drw------- 2 root root 4096 Oct 26  2011 192.168.130.101,3260,1
@ -99,6 +103,7 @@ drw------- 2 root root 4096 Oct 26  2011 192.168.131.101,3260,1
 ~~~

 Pour se connecter automatiquement aux LUNs au démarrage du serveur, il faut modifier la directive "node.startup" en la passant de "manual" à "automatic" :
+
 ~~~
 # cat /etc/iscsi/nodes/iqn.1984-05.com.dell\:powervault.md3600i.36782bcb00050034200000xxxxxxxxxx/192.168.130.101\,3260\,1
 node.name = iqn.1984-05.com.dell:powervault.md3600i.36782bcb00050034200000xxxxxxxxxx
@ -114,7 +119,7 @@ node.discovery_type = send_targets

 ### /etc/fstab

-Lorsque les partition d'un device iSCSI sont ajoutées au fichier fstab, ne pas oublier l'option "_netdev": elle permet non seulement d'attendre que le réseau soit actif avant de chercher à monter la partition (pour ne pas bloquer le démarrage du serveur, ce serait dommage...) mais aussi de démonter la/les partitions à l'extinction de la machine avant de couper le réseau afin d'éviter toute corruption du filesystem (encore une fois, ce serait dommage).
+Lorsque les partition d'un device iSCSI sont ajoutées au fichier fstab, ne pas oublier l'option "netdev": elle permet non seulement d'attendre que le réseau soit actif avant de chercher à monter la partition (pour ne pas bloquer le démarrage du serveur, ce serait dommage...) mais aussi de démonter la/les partitions à l'extinction de la machine avant de couper le réseau afin d'éviter toute corruption du filesystem (encore une fois, ce serait dommage).

 ~~~
 /dev/mapper/data /home                                    ext3    _netdev,defaults,noexec,nosuid,nodev  0       0
@ -203,7 +208,7 @@ ATTENTION, HOWTO EN COURS DE CONSTRUCTION...
 Lorsque l'on a plusieurs paths vers un device (voir ci-dessus), l'idée est de
 profiter de cela pour avoir une tolérance de panne et une agrégation des débits.

-### Utilisation du multipath 
+### Utilisation du multipath

 ~~~
 aptitude install multipath-tools
@ -261,15 +266,15 @@ devices {
                product                 "MD36xxi"
                path_selector           "round-robin 0"
                # Agrège les débits
-                path_grouping_policy    multibus 
+                path_grouping_policy    multibus
                # Utilise le(s) lien(s) restant(s) au premier échec
-                failback                immediate 
+                failback                immediate
                no_path_retry           fail
                features                "1 queue_if_no_path"
        }
 }

-# Identifie par son WWID le(s) disque(s) à utiliser en multipath 
+# Identifie par son WWID le(s) disque(s) à utiliser en multipath
 # Le disque sera disponible dans /dev/mapper/data
 multipaths {
        multipath {
@ -301,6 +306,7 @@ La politique multibus semble la plus intéressante car elle permet de gérer aus
 L'option "failback immediate" indique de basculer sur le ou les lien(s) restant(s) dès qu'une erreur apparait, mais la bascule met 130s dans la configuration précédente, car c'est la couche SCSI qui remonte l'erreur à multipathd et le timeout par défaut d'open-iscsi est de 120 secondes. On peut régler la valeur de ce timeout dans le fichier /etc/iscsi/iscsid.conf pour les nouveaux targets, mais il ne faut pas oublier que les targets déjà configurés (même après déconnexion/reconnexion) conservent leurs paramètres dans /etc/iscsi/send_targets/[...], on modifiera donc également ces fichiers.

 Exemple avec notre baie Dell :
+
 ~~~
 # cat /etc/iscsi/nodes/iqn.1984-05.com.dell\:powervault.md3600i.36782bcb00050034200000xxxxxxxxxx/192.168.130.101\,3260\,1
 node.name = iqn.1984-05.com.dell:powervault.md3600i.36782bcb00050034200000xxxxxxxxxx
@ -319,6 +325,7 @@ node.session.timeo.replacement_timeout = 10
 ### Pour ne plus utiliser multipathd

 Commencer par démonter les partitions :
+
 ~~~
 # umount /dev/mapper/data
 ~~~
@ -330,17 +337,19 @@ Stopper les utilitaires multipath :
 ~~~

 Et purger la liste des différents paths pour la/les ressource(s) :
+
 ~~~
 # multipath -F
 ~~~

 On peut vérifier :
+
 ~~~
 # multipath -ll
-#
 ~~~

 Éventuellement, on peut retirer les modules à présent inutilisés :
+
 ~~~
 # rmmod dm_round_robin dm_multipath
 ~~~
--- a/HowtoInitramfsDebug.md
+++ b/HowtoInitramfsDebug.md
@ -13,7 +13,7 @@ Reading all physical volumes. This may take a while ...
 No volume groups found
 ~~~