Corrections de mise en forme
This commit is contained in:
parent
7ce3e83c12
commit
ffc33f1d7f
83 changed files with 739 additions and 230 deletions
|
|
@ -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
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
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
~~~
|
||||
|
|
|
|||
|
|
@ -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') }}"
|
||||
~~~
|
||||
|
|
|
|||
|
|
@ -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,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)
|
||||
~~~
|
||||
|
|
|
|||
|
|
@ -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
|
||||
~~~
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
~~~
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
~~~
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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,[],<<>>,[]}.
|
||||
[...]
|
||||
~~~
|
||||
~~~
|
||||
|
|
|
|||
|
|
@ -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
|
||||
~~~
|
||||
~~~
|
||||
|
|
|
|||
|
|
@ -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
|
||||
~~~
|
||||
~~~
|
||||
|
|
|
|||
|
|
@ -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
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>
|
||||
|
|
|
|||
|
|
@ -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é
|
||||
|
|
|
|||
|
|
@ -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...
|
||||
|
|
|
|||
|
|
@ -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/>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
~~~
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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 :
|
||||
|
||||