Browse Source

Corrections de mise en forme

master
Jérémy Lecour 4 years ago
committed by Jérémy Lecour
parent
commit
ffc33f1d7f
  1. 2
      CarteAPU.md
  2. 11
      HowtoACL.md
  3. 1
      HowtoAlfresco.md
  4. 48
      HowtoAnsible.md
  5. 1
      HowtoApache.md
  6. 1
      HowtoBNX2.md
  7. 8
      HowtoBTRFS.md
  8. 5
      HowtoBind.md
  9. 3
      HowtoCUPS.md
  10. 30
      HowtoChiffrementData.md
  11. 11
      HowtoDiscourse.md
  12. 9
      HowtoDovecot.md
  13. 8
      HowtoEjabberd.md
  14. 43
      HowtoFail2Ban.md
  15. 15
      HowtoGitDaemon.md
  16. 16
      HowtoGitWeb.md
  17. 17
      HowtoHG.md
  18. 3
      HowtoHTTP.md
  19. 30
      HowtoHearthbeat.md
  20. 9
      HowtoHtop.md
  21. 9
      HowtoISAKMPD.md
  22. 33
      HowtoISCSI.md
  23. 11
      HowtoInitramfsDebug.md
  24. 2
      HowtoIrssi.md
  25. 8
      HowtoJava.md
  26. 4
      HowtoKVM.md
  27. 2
      HowtoLAMP.md
  28. 25
      HowtoLXC.md
  29. 9
      HowtoLetsEncrypt.md
  30. 4
      HowtoLiveCD.md
  31. 37
      HowtoMemcached.md
  32. 1
      HowtoNBD.md
  33. 3
      HowtoNFS.md
  34. 1
      HowtoNetflow.md
  35. 4
      HowtoNginx.md
  36. 5
      HowtoOpenLDAP.md
  37. 21
      HowtoOpenVZ.md
  38. 5
      HowtoOracleDB.md
  39. 2
      HowtoOwncloud.md
  40. 7
      HowtoPXE.md
  41. 1
      HowtoPgBouncer.md
  42. 2
      HowtoPortKnocking.md
  43. 7
      HowtoPostfix.md
  44. 29
      HowtoPostgreSQL.md
  45. 56
      HowtoPostgreSQLReplication.md
  46. 35
      HowtoPostgreSQLStreamingReplication.md
  47. 10
      HowtoPrestashop.md
  48. 2
      HowtoProFTPD.md
  49. 11
      HowtoPuppet.md
  50. 44
      HowtoRails.md
  51. 20
      HowtoRaspberryPi.md
  52. 16
      HowtoRedis.md
  53. 49
      HowtoRedmine-Source.md
  54. 8
      HowtoSNMP.md
  55. 4
      HowtoSSH.md
  56. 19
      HowtoSVN.md
  57. 11
      HowtoSamba.md
  58. 9
      HowtoShareDance.md
  59. 2
      HowtoSmokeping.md
  60. 5
      HowtoStrongSwan.md
  61. 1
      HowtoSudo.md
  62. 33
      HowtoTomcat.md
  63. 8
      HowtoUnicorn.md
  64. 2
      HowtoVRRP.md
  65. 14
      HowtoVagrant.md
  66. 4
      HowtoWkhtmltopdf.md
  67. 14
      HowtoWordpress.md
  68. 1
      HowtoXen.md
  69. 1
      HowtoZimbra.md
  70. 5
      Howtonfdump.md
  71. 2
      InfosMegaCLI.md
  72. 2
      LSI-SAS1068E.md
  73. 1
      LSI.md
  74. 29
      NetApp.md
  75. 16
      ServeurAmazonEC2.md
  76. 3
      ServeurDedibox.md
  77. 1
      ServeurGANDI.md
  78. 1
      ServeurGoogleCloud.md
  79. 1
      ServeurOVH.md
  80. 1
      Solaris.md
  81. 20
      SwitchCisco.md
  82. 1
      TipsAndroid.md
  83. 2
      TipsExtfs.md

2
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

11
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

1
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)
~~~

48
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') }}"
~~~

1
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 :

1
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)
~~~

8
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
~~~

5
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";

3
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
~~~

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

11
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
~~~

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

8
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,[],<<>>,[]}.
[...]
~~~
~~~

43
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
~~~
~~~

15
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
~~~
~~~

16
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
~~~
~~~

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

3
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é

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

9
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/>

9
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
~~~

33
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
~~~

11
HowtoInitramfsDebug.md

@ -13,7 +13,7 @@ Reading all physical volumes. This may take a while ...
No volume groups found
~~~
On obtient souvent avant l'invit initramfs et busybox une note du type
On obtient souvent avant l'invit initramfs et busybox une note du type
~~~
Alert ! /dev/disk/by-uuid/dc0e0033-1e4c-41f9-8ebb-e3d3f8e03459 does not exist. Dropping to a shell!
@ -23,10 +23,13 @@ C'est souvent lié à un changement mal géré de UUID sur l'une des partitions
Il faut avoir en tête que la syntaxe de /etc/crypttab (fichier listant les partitions qui seront déchiffrés au démarrage [[<http://trac.evolix.net/infogerance/wiki/HowtoChiffrementData>]])