Corrections de mise en forme
This commit is contained in:
parent
7ce3e83c12
commit
ffc33f1d7f
|
@ -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 :
|
||||
|
||||
~~~
|
||||
# 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
|
||||
~~~
|
||||
|
|
|
@ -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>]])
|
||||
peut être soit :
|
||||
|
||||
~~~
|
||||
sda7_crypt UUID=459a6a8b-0e49-4ba2-b436-6b97400bf761 none luks
|
||||
~~~
|
||||
|
||||
ou
|
||||
|
||||
~~~
|
||||
sda7_crypt /dev/sda7 none luks
|
||||
~~~
|
||||
|
@ -39,14 +42,12 @@ L'autre conseil est de ne pas utiliser l'utilitaire update-initramfs pour regén
|
|||
update-initramfs -k -all -u
|
||||
~~~
|
||||
|
||||
## Préférer la méthode suivante
|
||||
## Préférer la méthode suivante
|
||||
(en ayant fait un backup de votre /boot/initrd.img-${uname -r} (ex : /boot/initrd.img-3.16.0-4-amd64 )) :
|
||||
|
||||
~~~
|
||||
cd /boot/initramfs
|
||||
find . | cpio -H newc --create --verbose | gzip -9 > ../initrd.img-${uname -r}
|
||||
find . | cpio -H newc --create --verbose | gzip -9 > ../initrd.img-${uname -r}
|
||||
~~~
|
||||
|
||||
Puis réinstallez grub
|
||||
|
||||
|
||||
|
|
|
@ -30,6 +30,7 @@ vim 2016-08.log
|
|||
~~~
|
||||
|
||||
Ne pas hésiter à sauvegarder sa session actuelle (thème)
|
||||
|
||||
~~~
|
||||
/SAVE
|
||||
~~~
|
||||
|
@ -51,6 +52,7 @@ Ne pas hésiter à sauvegarder sa session actuelle (thème)
|
|||
## Scripts sur irssi
|
||||
|
||||
Créer ou copier les scripts dans ~/.irssi/scripts/
|
||||
|
||||
~~~
|
||||
/SCRIPT load <chemin>
|
||||
/SCRIPT unload <nom script>
|
||||
|
|
|
@ -28,11 +28,13 @@ La procédure à suivre est ici : <https://wiki.debian.org/JavaPackage>
|
|||
Java stocke ces certificats dans un fichier, situé dans _/usr/lib/jvm/java-6-sun/jre/lib/security/cacerts_ (sous Debian).
|
||||
|
||||
Pour lister les certificats :
|
||||
|
||||
~~~
|
||||
$ keytool -list -v -keystore /usr/lib/jvm/java-6-sun/jre/lib/security/cacerts
|
||||
~~~
|
||||
|
||||
Pour importer un nouveau certificat, on peut utiliser la commande keytool :
|
||||
|
||||
~~~
|
||||
$ keytool -import -v -file certificat.cer -alias <mykey> -keystore /usr/lib/jvm/java-6-sun/jre/lib/security/cacerts
|
||||
~~~
|
||||
|
@ -42,6 +44,7 @@ $ keytool -import -v -file certificat.cer -alias <mykey> -keystore /usr/lib/jvm/
|
|||
Il est ensuite demandé un mot de passe pour ouvrir la base de données des certificats. Par défaut, il s'agit de _changeit_.
|
||||
|
||||
Si vous ne précisez pas d'alias vous pourriez rencontrer l'erreur suivante :
|
||||
|
||||
~~~
|
||||
keytool error: java.lang.Exception: Certificate not imported, alias <mykey> already exists
|
||||
~~~
|
||||
|
@ -49,6 +52,7 @@ keytool error: java.lang.Exception: Certificate not imported, alias <mykey> alre
|
|||
Basiquement, cela peut vouloir dire que le certificat a déjà été importé avec l'alias par défaut: mykey, il faudra donc trouver un autre nom pour importer le certificat.
|
||||
|
||||
Pour supprimer un certificat (parce qu'il est expiré par exemple) :
|
||||
|
||||
~~~
|
||||
$ keytool -delete -keystore /usr/lib/jvm/java-6-sun/jre/lib/security/cacerts -alias <mykey>
|
||||
~~~
|
||||
|
@ -86,7 +90,7 @@ security.provider.8=sun.security.smartcardio.SunPCSC
|
|||
security.provider.9=sun.security.provider.Sun
|
||||
~~~
|
||||
|
||||
Sous Wheezy avec JRE Oracle (pas OpenJDK) :
|
||||
Sous Wheezy avec JRE Oracle (pas OpenJDK) :
|
||||
|
||||
Télécharger le fichier ici : <http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html>
|
||||
|
||||
|
@ -110,4 +114,4 @@ security.provider.6=com.sun.security.sasl.Provider
|
|||
security.provider.7=org.jcp.xml.dsig.internal.dom.XMLDSigRI
|
||||
security.provider.8=sun.security.smartcardio.SunPCSC
|
||||
security.provider.9=sun.security.provider.Sun
|
||||
~~~
|
||||
~~~
|
||||
|
|
|
@ -52,6 +52,7 @@ Pour un accès « graphique », installer sur le poste client :
|
|||
~~~
|
||||
# apt install virt-manager netcat-openbsd
|
||||
~~~
|
||||
|
||||
puis ajouter une clé SSH permettant de se connecter au serveur avec l'utilisateur **root**
|
||||
puis démarrer `virt-manager` et ajouter une _connexion à un hôte distant_ via SSH.
|
||||
|
||||
|
@ -167,7 +168,7 @@ $ vncviewer -via kvm.example.com 127.0.0.1:5900
|
|||
**Nous déconseillons l'installation via _virt-manager_ !!**
|
||||
Certes, l'installation est plus conviviale (car graphique) mais :
|
||||
|
||||
* les options disponibles à la création sont très limitées (aucun choix pour CPU,
|
||||
* les options disponibles à la création sont très limitées (aucun choix pour CPU,
|
||||
* les options disponibles sont limitées (impossible de sélectionner un volume DRBD par exemple)
|
||||
* les choix réalisés par défaut sont incorrects (ajout de périphériques Tablette, Video QXL, USB etc.)
|
||||
|
||||
|
@ -348,6 +349,7 @@ Convertir ume image RAW en QCOW2 :
|
|||
# qemu-img resize host.img +50G
|
||||
Image resized.
|
||||
~~~
|
||||
|
||||
ou on peut utiliser `dd`, exemple pour une taille finale de 80G :
|
||||
|
||||
~~~
|
||||
|
|
|
@ -6,12 +6,14 @@
|
|||
Le dépôt [DotDeb](http://www.dotdeb.org/) contient des versions plus à jour des paquets apache2, mysql… pour la version stable de Debian. Il peut être intéressant de l'ajouter sur un serveur LAMP.
|
||||
|
||||
Pour l'utiliser, on ajoute simplement les lignes suivantes dans les sources d'apt :
|
||||
|
||||
~~~
|
||||
deb <http://packages.dotdeb.org> stable all
|
||||
deb-src <http://packages.dotdeb.org> stable all
|
||||
~~~
|
||||
|
||||
Ensuite, on ajoute la clé publique du dépôt comme ceci :
|
||||
|
||||
~~~
|
||||
gpg --keyserver keys.gnupg.net --recv-key 89DF5277
|
||||
gpg -a --export 89DF5277 | sudo apt-key add -
|
||||
|
|
25
HowtoLXC.md
25
HowtoLXC.md
|
@ -11,6 +11,7 @@
|
|||
~~~
|
||||
|
||||
## Modifications réseau
|
||||
|
||||
~~~
|
||||
# cat /etc/network/interfaces
|
||||
[...]
|
||||
|
@ -33,10 +34,12 @@ iface br1 inet static
|
|||
~~~
|
||||
|
||||
~~~
|
||||
/sbin/iptables -A INPUT -p tcp --sport 11371 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
|
||||
/sbin/iptables -t nat -A POSTROUTING -s 10.1.0.254/24 -o br0 -j SNAT --to *IP de l'hyperviseur*
|
||||
# /sbin/iptables -A INPUT -p tcp --sport 11371 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
|
||||
# /sbin/iptables -t nat -A POSTROUTING -s 10.1.0.254/24 -o br0 -j SNAT --to *IP de l'hyperviseur*
|
||||
~~~
|
||||
Activation du forwarding
|
||||
|
||||
Activation du forwarding
|
||||
|
||||
~~~
|
||||
# echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
|
||||
# echo "net.ipv4.conf.all.arp_announce=2" >> /etc/sysctl.conf
|
||||
|
@ -55,7 +58,7 @@ iface br1 inet static
|
|||
# lxc-create -t download -n test
|
||||
~~~
|
||||
|
||||
Avant de démarrer la VM mettre ces lignes dans le fichier de conf du conteneur : /var/lib/lxc/test/config
|
||||
Avant de démarrer la VM mettre ces lignes dans le fichier de conf du conteneur : ``/var/lib/lxc/test/config`
|
||||
|
||||
~~~
|
||||
lxc.network.type = veth
|
||||
|
@ -67,27 +70,37 @@ lxc.network.flags = up
|
|||
~~~
|
||||
|
||||
(Il est conseillé de supprimer systemd du container car ce dernier est mal géré pour le moment)
|
||||
|
||||
~~~
|
||||
# apt install sysvinit-core
|
||||
~~~
|
||||
|
||||
## Utilisation
|
||||
|
||||
~~~
|
||||
Démarrer un conteneur :
|
||||
|
||||
~~~
|
||||
# lxc-start -n test -d
|
||||
~~~
|
||||
|
||||
Entrer dans un conteneur :
|
||||
|
||||
~~~
|
||||
# lxc-attach -n test
|
||||
~~~
|
||||
|
||||
Arreter un conteneur :
|
||||
|
||||
~~~
|
||||
# lxc-stop -n test
|
||||
~~~
|
||||
|
||||
Autres commandes utiles :
|
||||
|
||||
~~~
|
||||
# lxc-info -n test-container
|
||||
# lxc-console -n test-container
|
||||
# lxc-halt -n test-container
|
||||
# lxc-info -n test-container
|
||||
# lxc-destroy -n test-container
|
||||
~~~
|
||||
~~~
|
||||
|
|
|
@ -11,6 +11,7 @@ Dans tout les cas, il faut un client pour communiquer avec les serveurs de Let's
|
|||
Certbot est disponible en paquet sous Debian à partir des backports de Jessie.
|
||||
|
||||
Pour l'installer, il faut donc être en Debian Jessie avec les backports de configurés, puis :
|
||||
|
||||
~~~
|
||||
apt install certbot -t jessie-backports
|
||||
~~~
|
||||
|
@ -20,11 +21,13 @@ apt install certbot -t jessie-backports
|
|||
Afin de ne pas faire tourner certbot avec l'utilisateur root et de ne pas lui donner accès aux clés SSL, nous allons faire tourner certbot avec un utilisateur dédié.
|
||||
|
||||
Premièrement, penser à supprimer la tâche cron par défaut de certbot qui est lancé en root :
|
||||
|
||||
~~~
|
||||
rm /etc/cron.d/certbot
|
||||
~~~
|
||||
|
||||
Ensuite créer l'utilisateur dédié à certbot (ici "acme") et corriger les droits en consequences :
|
||||
|
||||
~~~
|
||||
useradd acme -d /etc/letsencrypt
|
||||
mkdir /etc/letsencrypt /var/log/letsencrypt /var/lib/letsencrypt
|
||||
|
@ -33,6 +36,7 @@ chown acme: /etc/letsencrypt /var/log/letsencrypt /var/lib/letsencrypt
|
|||
~~~
|
||||
|
||||
Puis ajouter la commande de renouvellement dans la crontab de l'utilisateur acme :
|
||||
|
||||
~~~
|
||||
# On ouvre la crontab de acme
|
||||
crontab -u acme -e
|
||||
|
@ -45,6 +49,7 @@ crontab -u acme -e
|
|||
#### Apache
|
||||
|
||||
Créer le fichier dans /etc/apache2/conf-available/letsencrypt.conf avec :
|
||||
|
||||
~~~
|
||||
SetEnvIf Request_URI "/.well-known/acme-challenge/*" no-jk
|
||||
Alias /.well-known/acme-challenge /var/lib/letsencrypt/.well-known/acme-challenge
|
||||
|
@ -53,8 +58,10 @@ Alias /.well-known/acme-challenge /var/lib/letsencrypt/.well-known/acme-challeng
|
|||
AllowOverride all
|
||||
Require all granted
|
||||
</Directory>
|
||||
|
||||
~~~
|
||||
Puis activer ce fichier :
|
||||
|
||||
~~~
|
||||
ln -s /etc/apache2/conf-available/letsencrypt.conf /etc/apache2/conf-enabled/letsencrypt.conf
|
||||
apache2ctl -t
|
||||
|
@ -64,11 +71,13 @@ service apache2 reload
|
|||
### Génération du certificat
|
||||
|
||||
Générér une clé SSL dans /etc/ssl/private et un CSR (voir [HowtoSSL](http://trac.evolix.net/infogerance/wiki/HowtoSSL)) :
|
||||
|
||||
~~~
|
||||
openssl req -newkey rsa:2048 -sha256 -nodes -keyout /etc/ssl/private/ma-cle.ssl -out mon-csr.csr
|
||||
~~~
|
||||
|
||||
Faire la demande de certificat (avec l'utilisateur acme, le csr doit être accesible en lecture à cet utilisateur) :
|
||||
|
||||
~~~
|
||||
sudo -u acme certbot certonly --webroot --csr mon-csr.csr --webroot-path /var/lib/letsencrypt -n --agree-tos --cert-path=/etc/letsencrypt/mon-cert.crt --fullchain-path=/etc/letsencrypt/mon-cert-fullchain.pem --chain-path=/etc/letsencrypt/mon-cert-chain.pem email@example.com
|
||||
~~~
|
||||
|
|
|
@ -83,10 +83,13 @@ Vous devez vous "chrooter" sur le système de base (changer les noms de partitio
|
|||
~~~
|
||||
|
||||
Remarque : à noter la variante en cas de partition chiffrée ([<http://trac.evolix.net/infogerance/wiki/HowtoChiffrementData>])
|
||||
|
||||
~~~
|
||||
# mount /dev/sda2 /chroot/
|
||||
~~~
|
||||
|
||||
devient
|
||||
|
||||
~~~
|
||||
# cryptsetup luksOpen /dev/sda2 sda2crypt
|
||||
# mount /dev/mapper/sda2crypt /chroot/
|
||||
|
@ -107,7 +110,6 @@ ou
|
|||
# update-grub2
|
||||
~~~
|
||||
|
||||
|
||||
## FAQ
|
||||
|
||||
### J'ai un multiboot UEFI et je veux restaurer GRUB car je n'arrive plus à démarrer sous Linux
|
||||
|
|
|
@ -98,7 +98,8 @@ Il est nécessaire de dupliquer le fichier de configuration _/etc/memcached.conf
|
|||
### Instances Jessie
|
||||
|
||||
Sous Debian Jessie, si on utilise systemd, pour pouvoir bénéficier des instances jessie, il faut créer un template _/etc/systemd/system/memcached@.service_ :
|
||||
~~~
|
||||
|
||||
~~~{.ini}
|
||||
[Unit]
|
||||
Description=memcached daemon
|
||||
After=network.target
|
||||
|
@ -111,24 +112,28 @@ WantedBy=multi-user.target
|
|||
~~~
|
||||
|
||||
Ne plus démarrer le service memcached par defaut dans le target multi-user (~ runlevel 3) :
|
||||
|
||||
~~~
|
||||
rm /etc/systemd/system/multi-user.target.wants/memcached.service
|
||||
# rm /etc/systemd/system/multi-user.target.wants/memcached.service
|
||||
~~~
|
||||
|
||||
Ensuite pour chaque instance avec un fichier de configuration _/etc/memcached_$nominstance.conf_, créer un lien symbolique vers le template dans le target multi-user :
|
||||
|
||||
~~~
|
||||
cd /etc/systemd/system/multi-user.target.wants/
|
||||
ln -s /etc/systemd/system/memcached@.service memcached@$nominstance.service
|
||||
# cd /etc/systemd/system/multi-user.target.wants/
|
||||
# ln -s /etc/systemd/system/memcached@.service memcached@$nominstance.service
|
||||
~~~
|
||||
|
||||
Puis
|
||||
|
||||
~~~
|
||||
systemctl daemon-reload
|
||||
# systemctl daemon-reload
|
||||
~~~
|
||||
|
||||
On peut ensuite manipuler chaque instance avec systemctl, par exemple :
|
||||
|
||||
~~~
|
||||
systemctl <start|stop|restart> memcached@$nominstance
|
||||
# systemctl <start|stop|restart> memcached@$nominstance
|
||||
~~~
|
||||
|
||||
## Réplication
|
||||
|
@ -178,20 +183,20 @@ TODO
|
|||
Voilà comment activer le plugin munin memcached :
|
||||
|
||||
~~~
|
||||
cd /etc/munin/plugins
|
||||
ln -snf /usr/share/munin/plugins/memcached_ memcached_bytes
|
||||
ln -snf /usr/share/munin/plugins/memcached_ memcached_counters
|
||||
ln -snf /usr/share/munin/plugins/memcached_ memcached_rates
|
||||
aptitude install libcache-memcached-perl
|
||||
/etc/init.d/munin-node restart
|
||||
# cd /etc/munin/plugins
|
||||
# ln -snf /usr/share/munin/plugins/memcached_ memcached_bytes
|
||||
# ln -snf /usr/share/munin/plugins/memcached_ memcached_counters
|
||||
# ln -snf /usr/share/munin/plugins/memcached_ memcached_rates
|
||||
# aptitude install libcache-memcached-perl
|
||||
# /etc/init.d/munin-node restart
|
||||
~~~
|
||||
|
||||
On peu ensuite tester le plugin :
|
||||
On peut ensuite tester le plugin :
|
||||
|
||||
~~~
|
||||
munin-run memcached_bytes
|
||||
munin-run memcached_counters
|
||||
munin-run memcached_rates
|
||||
# munin-run memcached_bytes
|
||||
# munin-run memcached_counters
|
||||
# munin-run memcached_rates
|
||||
~~~
|
||||
|
||||
Des plugins pour Munin existent pour relever diverses informations sur l'utilisation de memcache, comme la mémoire utilisée, le nombre et type de requêtes faites, le nombre de clés dans la base, etc…
|
||||
|
|
|
@ -18,6 +18,7 @@ authfile = /etc/nbd-server/allow.pi01
|
|||
~~~
|
||||
|
||||
/etc/nbd-server/allow.pi00
|
||||
|
||||
~~~
|
||||
192.168.42.42
|
||||
~~~
|
||||
|
|
|
@ -5,6 +5,7 @@
|
|||
|
||||
* Installez le paquet _nfs-kernel-server_
|
||||
* Les partages se configurent dans le fichier _/etc/exports_ :
|
||||
|
||||
~~~
|
||||
/srv/nfs 192.0.2.4(rw,root_squash,sync,no_subtree_check)
|
||||
~~~
|
||||
|
@ -26,6 +27,7 @@ En Wheezy pour conserver les UID/GID il faut spécifier un domaine similaire sur
|
|||
## Montage du partage
|
||||
|
||||
* Dans le fichier _/etc/fstab_ :
|
||||
|
||||
~~~
|
||||
192.0.2.10:/srv/nfs /srv/nfs nfs rw 0 0
|
||||
~~~
|
||||
|
@ -39,6 +41,7 @@ En Wheezy pour conserver les UID/GID il faut spécifier un domaine similaire sur
|
|||
## Forcer le NFS v3
|
||||
|
||||
Sur le client :
|
||||
|
||||
~~~
|
||||
192.0.2.10:/srv/nfs /srv/nfs nfs rw,nfsvers=3 0 0
|
||||
~~~
|
|
@ -15,6 +15,7 @@ On peut par exemple installer ce serveur sous Linux.
|
|||
~~~
|
||||
|
||||
On peut ainsi lancer le démon *nfcapd* en le configurant via _/etc/default/ndump_ :
|
||||
|
||||
~~~
|
||||
nfcapd_start=yes
|
||||
~~~
|
||||
|
|
|
@ -147,6 +147,7 @@ Une requête sur /i/image.png, nginx renverra le contenu de /spool/w3/images/ima
|
|||
|
||||
Les restrictions d'IPs ne peuvent pas se baser sur le contenu des headers, il faut passer par un module tiers (fourni avec la version nginx-extras) "Real IP".
|
||||
Il permet de substituer l'adresse IPs d'origine par celle notre choix, et notamment celle contenu dans le header "X-Forwarded-for" :
|
||||
|
||||
~~~
|
||||
set_real_ip_from 127.0.0.1; # À remplacer par l'IP du proxy
|
||||
real_ip_recursive on;
|
||||
|
@ -271,16 +272,19 @@ server {
|
|||
Contrairement à apache, on ne pourra indiquer une conf général à inclure qui s'appliquera pour tout les vhosts, mais il faudra ajouter l'include sur tout les fichier de confs des vhosts.
|
||||
|
||||
Fichier de conf général */etc/nginx/error.conf*
|
||||
|
||||
~~~
|
||||
location /YYYYYY/ {
|
||||
alias /var/www/;
|
||||
index page.html;
|
||||
}
|
||||
error_page XXX /YYYYYY/;
|
||||
|
||||
~~~
|
||||
_Remplacer XXX par le code erreur HTTP souhaité et YYYYY par le nom de Location souhaité (URL) - vu que global à tout les vhosts, prendre une chaîne aléatoire._
|
||||
|
||||
Et pour chaque conf des vhosts */etc/nginx/sites-enabled/*.conf* :
|
||||
|
||||
~~~
|
||||
include /etc/nginx/error.conf;
|
||||
~~~
|
||||
|
|
|
@ -148,11 +148,13 @@ by users read by anonymous auth
|
|||
*Sur le master :*
|
||||
|
||||
* Ajouter le module syncprov (dans l'objet cn=module{0},cn=config) :
|
||||
|
||||
~~~
|
||||
olcModuleLoad: {1}syncprov
|
||||
~~~
|
||||
|
||||
* Ajouter l'objet suivant :
|
||||
|
||||
~~~
|
||||
dn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config
|
||||
objectClass: olcOverlayConfig
|
||||
|
@ -175,11 +177,13 @@ olcSpCheckpoint: 100 10
|
|||
|
||||
* S'assurer que le schéma LDAP soit le même que sur le master
|
||||
* Ajouter le module syncprov (dans l'objet cn=module{0},cn=config) :
|
||||
|
||||
~~~
|
||||
olcModuleLoad: {1}syncprov
|
||||
~~~
|
||||
|
||||
* Ajouter les attributs suivants à l'objet "dn: olcDatabase={1}hdb,cn=config" :
|
||||
|
||||
~~~
|
||||
olcDbIndex: entryUUID eq
|
||||
olcSyncrepl: {0}rid=124 provider=ldap://ldap.example.com bindmethod=simple binddn="cn=repl,ou=ldapuser,dc=example,dc=com" credentials=XXX searchbase="dc=example,dc=com" retry="60 +" type=refreshAndPersist
|
||||
|
@ -208,6 +212,7 @@ Attention, si l'on modifie les index, il faut absolument les regénérer avec la
|
|||
### Activer SSL (LDAPS)
|
||||
|
||||
Rajouter dans _cn=config_ :
|
||||
|
||||
~~~
|
||||
olcTLSCertificateFile: /etc/ssl/certs/ssl-cert-snakeoil.pem
|
||||
olcTLSCertificateKeyFile: /etc/ssl/private/ssl-cert-snakeoil.key
|
||||
|
|
|
@ -16,6 +16,7 @@ Il ne peut donc y avoir un système Debian et un FreeBSD sur la même machine ph
|
|||
Au niveau du partitionement, il peut être utile de créer une partition contenant tous les VE, à monter dans _/var/lib/vz/_, étant donné que les fichiers des VE sont des _vrais fichiers_ pour le système de fichiers hôte (contrairement à d'autres solutions de virtualisation où les fichiers sont dans une image).
|
||||
|
||||
Ensuite, on installe le noyau Linux avec le support d'OpenVZ (ne pas oublier de rebooter dessus après l'install avant de continuer) :
|
||||
|
||||
~~~
|
||||
# aptitude install linux-image-2.6-openvz-amd64
|
||||
~~~
|
||||
|
@ -23,6 +24,7 @@ Ensuite, on installe le noyau Linux avec le support d'OpenVZ (ne pas oublier de
|
|||
Configuration du réseau : il faut activer le forwarding des paquets :
|
||||
|
||||
/etc/sysctl.conf
|
||||
|
||||
~~~
|
||||
net.ipv4.conf.default.forwarding=1
|
||||
net.ipv4.conf.default.proxy_arp = 0
|
||||
|
@ -30,6 +32,7 @@ net.ipv4.ip_forward=1
|
|||
~~~
|
||||
|
||||
Prise en compte de la configuration :
|
||||
|
||||
~~~
|
||||
sysctl -p
|
||||
~~~
|
||||
|
@ -43,12 +46,15 @@ echo 1 > /proc/sys/net/ipv4/ip_forward
|
|||
Il faut avant tous posséder un template du système à installer. On peut les trouver [ici](http://download.openvz.org/contrib/template/precreated/). Un template se présente sous la forme d'une archive contenant le système de fichier du système à installer. Elle doit être placée (non décompressée) dans _/var/lib/vz/template/cache/_.
|
||||
|
||||
Ensuite on peut créer un nouveau VE en utilisant ce template :
|
||||
|
||||
~~~
|
||||
vzctl create 1 --ostemplate debian-5.0-amd64-minimal --hostname --ipadd x.x.x.x --hostname foo
|
||||
|
||||
~~~
|
||||
_1_ représente l'id du VE. l'id 0 est réservé au système hôte. l'ostemplate doit correspondre au nom du template sans l'extension. ipadd permet de spécifier l'adresse IP du VE.
|
||||
|
||||
On peut également définir une configuration à l'aide de `vzctl set`, par exemple :
|
||||
|
||||
~~~
|
||||
vzctl set 1 --nameserver x.x.x.x
|
||||
~~~
|
||||
|
@ -56,21 +62,25 @@ vzctl set 1 --nameserver x.x.x.x
|
|||
## Gestion des VE
|
||||
|
||||
Démarrer, arréter un VE :
|
||||
|
||||
~~~
|
||||
vzctl (start|stop|restart) VEID
|
||||
~~~
|
||||
|
||||
Se connecter à un VE :
|
||||
|
||||
~~~
|
||||
vzctl enter VEID
|
||||
~~~
|
||||
|
||||
Exécuter une commande sur un VE (depuis l'hôte) :
|
||||
|
||||
~~~
|
||||
vzctl exec VEID COMMAND
|
||||
~~~
|
||||
|
||||
Lister les VE actifs :
|
||||
|
||||
~~~
|
||||
# vzlist
|
||||
VEID NPROC STATUS IP_ADDR HOSTNAME
|
||||
|
@ -84,17 +94,20 @@ Lister les VE actifs *et* éteints :
|
|||
~~~
|
||||
|
||||
Modifier le hostname :
|
||||
|
||||
~~~
|
||||
# vzctl set VMID --hostname foo.evolix.net --save
|
||||
~~~
|
||||
|
||||
Modifier l'IP :
|
||||
|
||||
~~~
|
||||
# vzctl set VMID --ipdel 1.2.3.4 --save
|
||||
# vzctl set VMID --ipadd 4.3.2.1 --save
|
||||
~~~
|
||||
|
||||
Ajouter de la RAM :
|
||||
|
||||
~~~
|
||||
vzctl set VMID --ram 3072M --save
|
||||
~~~
|
||||
|
@ -105,6 +118,7 @@ Il est possible de migrer un VE d'une machine physique à une autre en utilisant
|
|||
Avant tout, il faut s'assurer d'avoir le _PermitRootLogin yes_ et une clé SSH autorisée sur la machine cible.
|
||||
|
||||
Ensuite, on peut démarrer la migration :
|
||||
|
||||
~~~
|
||||
vzmigrate -v --online TARGET_HOST VEID
|
||||
~~~
|
||||
|
@ -124,6 +138,7 @@ Un snapshot consister à freeze tous les processus et sauvegarder toutes les inf
|
|||
L'image pourra ensuite être restaurer pour que tous les processus se retrouvent exactement dans le même état au moment du freeze.
|
||||
|
||||
Freezer le VE :
|
||||
|
||||
~~~
|
||||
# vzctl chkpnt VEID --suspend
|
||||
~~~
|
||||
|
@ -135,16 +150,19 @@ Freezer le VE :
|
|||
~~~
|
||||
|
||||
Enfin, on peut réveiller le VE :
|
||||
|
||||
~~~
|
||||
# vzctl chkpnt VEID --resume
|
||||
~~~
|
||||
|
||||
Pour ce qui est de la réstauration, il faut avant tout stopper le VE si il est actif :
|
||||
|
||||
~~~
|
||||
# vzctl stop VEID
|
||||
~~~
|
||||
|
||||
Ensuite, on peut restaurer le snapshot :
|
||||
|
||||
~~~
|
||||
# vzctl restore VEID --dumpfile /path/foo
|
||||
~~~
|
||||
|
@ -167,14 +185,17 @@ De la même manière que pour les quotas Linux, on peut définir une limite soft
|
|||
On peut partager le temps CPU de 2 manière différenetes :
|
||||
|
||||
* soit on limite un VE à un certain pourcentage d'utilisation du processeur :
|
||||
|
||||
~~~
|
||||
vzctl set VEID --cpulimit POURCENTAGE --save
|
||||
~~~
|
||||
|
||||
* soit on indique une proportion d'utilisation du CPU en fonction des autres VE :
|
||||
|
||||
~~~
|
||||
vzctl set 1 --cpuunits 10 --save
|
||||
vzctl set 2 --cpuunits 20 --save
|
||||
|
||||
~~~
|
||||
Dans cet exemple, si tous les VE ont besoins du CPU en même temps, OpenVZ accordera 2 fois plus de temps CPU au VE 2. L'avantage de cette méthode est que si le VE 2 n'utilise pas le CPU, le VE 1 peut prendre jusqu'à 100% du temps CPU. Ainsi, il n'y a pas de ressources inutilisées inutilement.
|
||||
}}}
|
||||
|
|
|
@ -132,6 +132,7 @@ Et voilà !
|
|||
Vous pouvez ensuite vous connectez en xxx ou avec la magnifique interface web du type : <https://mysuperserver:1158/em.> Pour se connecter en admin le login est SYS, le mot de passe est celui que vous avez renseigné pendant l'installation et il faut cliquer sur, « connect as SYSDBA ».
|
||||
|
||||
Rajouter cette ligne dans le .profile de l'utilisateur oracle :
|
||||
|
||||
~~~
|
||||
ORACLE_HOME=/opt/oracle/app/oracle/product/11.2.0/dbhome_1
|
||||
ORACLE_HOME_LISTNER=$ORACLE_HOME
|
||||
|
@ -146,17 +147,21 @@ export ORACLE_SID=oracle
|
|||
## Gestion
|
||||
|
||||
Lancement de ??? :
|
||||
|
||||
~~~
|
||||
sudo -u oracle lsnrctl start
|
||||
~~~
|
||||
|
||||
Lancement du serveur d'application et de l'interface web :
|
||||
|
||||
~~~
|
||||
sudo -u oracle emctl start dbconsole
|
||||
|
||||
~~~
|
||||
Note : N'est plus dispo en Oracle 12. C'est EM Express à la placé, lancé par défaut sur le port 5500. <https://localhost:5500/em/login>
|
||||
|
||||
Lancement du SGBD :
|
||||
|
||||
~~~
|
||||
sudo -u oracle dbstart
|
||||
~~~
|
||||
|
|
|
@ -64,12 +64,14 @@ The following extensions are built in: bcmath bz2 calendar Core ctype date dba d
|
|||
* Appliquer un patch pour le .htaccess dans le répertoire principal car sinon erreur 503 pour directives non autorisés
|
||||
* Créer un répertoire data (0770)
|
||||
* Lancer la commande `occ` se trouvant dans le repertoire principal
|
||||
|
||||
~~~
|
||||
php occ maintenance:install --no-interaction --database '{{ db }}' --database-name '{{ db_name }}' --database-host '{{ db_host }}' \
|
||||
--database-user '{{ db_user }}' --database-pass "{{ db_pwd }}" --admin-user 'admin' --admin-pass '{{ admin_pwd }}' --data-dir '{{ dir_www }}/data'
|
||||
~~~
|
||||
|
||||
* Si déjà installé, on peut éventuellement penser à une mise à jour ou upgrade :
|
||||
|
||||
~~~
|
||||
php occ upgrade --skip-migration-test
|
||||
~~~
|
||||
|
|
|
@ -9,6 +9,7 @@ Nous allons installer 3 serveurs :
|
|||
* et bien sûr, le serveur PXE en lui même.
|
||||
|
||||
Packets nécessaires :
|
||||
|
||||
~~~
|
||||
aptitude install dhcp3-server pxe atftpd
|
||||
~~~
|
||||
|
@ -20,6 +21,7 @@ aptitude install dhcp3-server pxe atftpd
|
|||
### Attribution d'une IP à la carte réseau
|
||||
|
||||
On fixe l'adresse IP du serveur PXE :
|
||||
|
||||
~~~
|
||||
ifconfig eth0 192.168.0.254
|
||||
~~~
|
||||
|
@ -27,11 +29,13 @@ ifconfig eth0 192.168.0.254
|
|||
### Configuration du serveur DHCP
|
||||
|
||||
Premièrement, il faut renseigner les interfaces gérées dans le fichier _/etc/default/dhcp3-serveur_
|
||||
|
||||
~~~
|
||||
INTERFACES="eth0"
|
||||
~~~
|
||||
|
||||
Ensuite, nous décrivons la configuration réseau dans le fichier _/etc/dhcp3/dhcpd.conf_
|
||||
|
||||
~~~
|
||||
subnet 192.168.0.0 netmask 255.255.255.0
|
||||
{
|
||||
|
@ -42,6 +46,7 @@ subnet 192.168.0.0 netmask 255.255.255.0
|
|||
filename "/debian-5.0-amd64/pxelinux.0";
|
||||
}
|
||||
~~~
|
||||
|
||||
L'option filename indique le chemin (à partir du chroot du serveur TFTP) du fichier image à booter.
|
||||
|
||||
## Configuration du serveur TFTP
|
||||
|
@ -56,4 +61,4 @@ Suivant si inetd est utilisé ou pas, il est possible de modifier les options de
|
|||
|
||||
La configuration se fait dans le fichier _/etc/pxe.conf_
|
||||
|
||||
TODO rdessort : à terminer suivant la conf de l'eeepc
|
||||
TODO rdessort : à terminer suivant la conf de l'eeepc
|
||||
|
|
|
@ -23,6 +23,7 @@ La configuration se fait dans le fichier _/etc/pgbouncer/pgbouncer.ini_.
|
|||
valide.
|
||||
|
||||
Par exemple :
|
||||
|
||||
~~~
|
||||
[databases]
|
||||
remotedb = dbname=db host=192.0.2.42 port=5433
|
||||
|
|
|
@ -105,6 +105,7 @@ Voir <http://www.zeroflux.org/projects/knock.>
|
|||
### Installation
|
||||
|
||||
knockd est présent dans les paquets Debian :
|
||||
|
||||
~~~
|
||||
# aptitude install knockd
|
||||
~~~
|
||||
|
@ -112,6 +113,7 @@ knockd est présent dans les paquets Debian :
|
|||
### Configuration
|
||||
|
||||
Exemple de configuration pour ouvrir le port SSH :
|
||||
|
||||
~~~
|
||||
[opencloseSSH]
|
||||
sequence = 2222:tcp,3333:tcp,4444:tcp
|
||||
|
|
|
@ -53,7 +53,7 @@ alias_maps = hash:/etc/aliases
|
|||
alias_database = hash:/etc/aliases
|
||||
myorigin = $myhostname
|
||||
mydestination = $myhostname localhost.localdomain localhost
|
||||
relayhost =
|
||||
relayhost =
|
||||
mynetworks = 127.0.0.0/8
|
||||
mailbox_size_limit = 0
|
||||
recipient_delimiter = +
|
||||
|
@ -209,6 +209,7 @@ On pourra utiliser ces commandes sur des ensembles de messages via des scripts d
|
|||
# mailq | tail -n +2 | awk 'BEGIN { RS = "" } /example\.com$/ { print $1 }' | tr -d '*!' | postsuper -d -
|
||||
# mailq > mailq.log ; for var in $(grep <jdoe@example.com> mailq.log | cut -b '1-12'); do postsuper -d $var; done
|
||||
~~~
|
||||
|
||||
*Note* : le `BEGIN { RS = "" }` est nécessaire car la sortie de mailq peut être sur plusieurs lignes, et le `tr -d '*!'` permet de ne pas prendre les messages en « hold ».
|
||||
|
||||
*À savoir* : la commande `postsuper -r` est pratique dans les cas où l'on a modifié des alias ou des ré-écritures, elle va déposer les messages concerné dans la queue _maildrop_ et lui attribué un nouveau <queue_id>. Attention, cela ne va pas provoquer un envoi immédiat car le traitement des files d'attente est différé. Si l'on veut un ré-envoi immédiat d'un message :
|
||||
|
@ -217,6 +218,7 @@ On pourra utiliser ces commandes sur des ensembles de messages via des scripts d
|
|||
# postsuper -r <queue_id>
|
||||
# mailq -q
|
||||
~~~
|
||||
|
||||
/!\\ Attention, `mailq -q` (ou `sendmail -q`) réactive immédiatemment l'ensemble des messages en file d'attente, il faut donc l'utiliser avec modération, surtout sur les serveurs avec des files d'attentes chargées.
|
||||
|
||||
La commande **shape** permettant par exemple de lister les messages dans la file d'attente _deffered_ :
|
||||
|
@ -414,7 +416,7 @@ En pratique pour les principaux fournisseurs d'emails, voici comment les contact
|
|||
|
||||
* Free : <http://postmaster.free.fr/>
|
||||
* Orange : <http://assistance.orange.fr/la-cellule-abuse-1260.php>
|
||||
* Hotmail/Outlook/Microsoft : <https://support.live.com/eform.aspx?productKey=edfsmsbl3&ct=eformts>
|
||||
* Hotmail/Outlook/Microsoft : <https://support.live.com/eform.aspx?productKey=edfsmsbl3&ct=eformts>
|
||||
* Yahoo : <http://help.yahoo.com/l/us/yahoo/mail/postmaster/postmaster-15.html> ... plus récemment : <http://help.yahoo.com/l/qe/snova/mail/postmaster/defer.html>
|
||||
* La Poste : <https://m.laposte.net/wapme/Help_CGU/CGU_chap_304.php>
|
||||
* GMAIL : <http://support.google.com/mail/bin/request.py?contact_type=bulk_send&&hl=en> (NE REPONDENT JAMAIS !!!)
|
||||
|
@ -431,4 +433,3 @@ Pour récupérer à la fois l'adresse expéditeur et destinataire dans les logs
|
|||
| while read msgid; do grep $msgid /var/log/mail.log |grep " postfix/" \
|
||||
| grep -E '(from|to)=<'|awk -F ' ' '{ print $1,$2,$3,$7 }' |tr -d ','; echo; done
|
||||
~~~
|
||||
|
||||
|
|
|
@ -26,7 +26,7 @@ Le *PostgreSQL Global Development Group (PGDG)* maintient un dépôt Debian qui
|
|||
|
||||
Ajouter le dépôt un fichier sources.list `/etc/apt/sources.list.d/jessie-pgdg.list` :
|
||||
|
||||
~~~
|
||||
~~~
|
||||
deb http://apt.postgresql.org/pub/repos/apt/ jessie-pgdg main
|
||||
~~~
|
||||
|
||||
|
@ -57,7 +57,7 @@ Par défaut le script d'init contrôle tous les instances actives. Pour contrôl
|
|||
Pour lister les instances existantes :
|
||||
|
||||
~~~
|
||||
# pg_lsclusters
|
||||
# pg_lsclusters
|
||||
Ver Cluster Port Status Owner Data directory Log file
|
||||
9.4 main 5432 online postgres /var/lib/postgresql/9.4/main /var/log/postgresql/postgresql-9.4-main.log
|
||||
~~~
|
||||
|
@ -103,6 +103,7 @@ Si on préfère passer par un mot de passe pour s'authentifier, il faut changer
|
|||
- local all all peer
|
||||
+ local all all password
|
||||
~~~
|
||||
|
||||
Bien s'assurer que les utilisateurs PostgreSQL ont un mot de passe de définit avant !
|
||||
|
||||
## Configuration
|
||||
|
@ -170,7 +171,7 @@ ou encore :
|
|||
=# SELECT * FROM pg_database;
|
||||
~~~
|
||||
|
||||
* Lister les utilisateurs (aussi appelés rôles) :
|
||||
* Lister les utilisateurs (aussi appelés rôles) :
|
||||
|
||||
~~~
|
||||
=# SELECT * FROM pg_user;
|
||||
|
@ -220,7 +221,7 @@ ou :
|
|||
|
||||
~~~
|
||||
=# SELECT pg_size_pretty(pg_database_size('DB'));
|
||||
=# SELECT pg_size_pretty(pg_relation_size('TABLE'));
|
||||
=# SELECT pg_size_pretty(pg_relation_size('TABLE'));
|
||||
=# SELECT pg_size_pretty(pg_total_relation_size('TABLE')); // taille avec les indexes
|
||||
=# SELECT relname, relpages FROM pg_class ORDER BY relpages DESC
|
||||
~~~
|
||||
|
@ -348,14 +349,14 @@ On peut voir tous les langages disponibles via :
|
|||
|
||||
~~~
|
||||
postgres=# select * from pg_pltemplate;
|
||||
tmplname | tmpltrusted | tmpldbacreate | tmplhandler | tmplvalidator | tmpllibrary | tmplacl
|
||||
tmplname | tmpltrusted | tmpldbacreate | tmplhandler | tmplvalidator | tmpllibrary | tmplacl
|
||||
-----------+-------------+---------------+-----------------------+-------------------+------------------+---------
|
||||
plpgsql | t | t | plpgsql_call_handler | plpgsql_validator | $libdir/plpgsql |
|
||||
pltcl | t | t | pltcl_call_handler | | $libdir/pltcl |
|
||||
pltclu | f | f | pltclu_call_handler | | $libdir/pltcl |
|
||||
plperl | t | t | plperl_call_handler | plperl_validator | $libdir/plperl |
|
||||
plperlu | f | f | plperl_call_handler | plperl_validator | $libdir/plperl |
|
||||
plpythonu | f | f | plpython_call_handler | | $libdir/plpython |
|
||||
plpgsql | t | t | plpgsql_call_handler | plpgsql_validator | $libdir/plpgsql |
|
||||
pltcl | t | t | pltcl_call_handler | | $libdir/pltcl |
|
||||
pltclu | f | f | pltclu_call_handler | | $libdir/pltcl |
|
||||
plperl | t | t | plperl_call_handler | plperl_validator | $libdir/plperl |
|
||||
plperlu | f | f | plperl_call_handler | plperl_validator | $libdir/plperl |
|
||||
plpythonu | f | f | plpython_call_handler | | $libdir/plpython |
|
||||
(6 rows)
|
||||
~~~
|
||||
|
||||
|
@ -523,7 +524,7 @@ Pour envoyer le résultat dans un fichier :
|
|||
=> SELECT * FROM weather WHERE temp_lo=10 \g '/tmp/output'
|
||||
~~~
|
||||
|
||||
### Mise à jour des données
|
||||
### Mise à jour des données
|
||||
|
||||
Toujours avec un exemple :
|
||||
|
||||
|
@ -531,7 +532,7 @@ Toujours avec un exemple :
|
|||
=> UPDATE weather SET temp_hi = temp_hi - 2, temp_lo = temp_lo - 2 WHERE date > '1994-11-28';
|
||||
~~~
|
||||
|
||||
### Suppression des données
|
||||
### Suppression des données
|
||||
|
||||
Encore avec un exemple :
|
||||
|
||||
|
@ -671,7 +672,7 @@ $ /usr/lib/postgresql/8.4/bin/pgbench -i pgbench -s 50
|
|||
### Exemple avant optimisation
|
||||
|
||||
~~~
|
||||
$ php -f script.php
|
||||
$ php -f script.php
|
||||
Shared Memory Max is 3,072.00Mb
|
||||
PostgreSQL is using 10.57Mb
|
||||
Testing: 5 clients with 5 transactions (5 samples)
|
||||
|
|
|
@ -34,11 +34,13 @@ aptitude install postgresql-8.4 postgresql-8.4-slony1-2 slony1-2-bin
|
|||
Soit deux machines, test1 et test2.
|
||||
|
||||
* Configurer PostgreSQL pour écouter en réseau (_listen_addresses = '*' _) et autoriser les connexions de l'autre machine (fichier _pg_hba.conf_) :
|
||||
|
||||
~~~
|
||||
host dbrepl slony 192.0.2.1/32 md5
|
||||
~~~
|
||||
|
||||
* Sur chaque machine, avec le compte postgres :
|
||||
|
||||
~~~
|
||||
# compte propriétaire de la base de test qui sera répliquée
|
||||
createuser -D -R -A dbrepl
|
||||
|
@ -59,6 +61,7 @@ Slonik (_petit éléphant_ en russe) est un langage de script permettant de cont
|
|||
#### Première méthode : édition manuelle des scripts Slonik
|
||||
|
||||
* Sur test1 :
|
||||
|
||||
~~~
|
||||
# On charge le script slonik qui va servir à préparer le namespace slony dans les bases dbrepl de chaque machine
|
||||
slonik <<EOT
|
||||
|
@ -107,11 +110,13 @@ store path (server # 2, client 1, conninfo='dbname=dbrepl host=test2 user=slony'
|
|||
~~~
|
||||
|
||||
* Sur chaque machine, lancer "slon", le démon qui se charge de transmettre les requêtes de machine en machine :
|
||||
|
||||
~~~
|
||||
slon slony_namespace "dbname=dbrepl user=slony host=HOSTNAME"
|
||||
~~~
|
||||
|
||||
* Puis exécuter le script slonik suivant sur test1, pour déclencher la réplication du replica set défini précédemment :
|
||||
|
||||
~~~
|
||||
slonik <<EOT
|
||||
|
||||
|
@ -133,9 +138,11 @@ On utilise ici les fichiers de configuration et outils Perl pour générer autom
|
|||
Cela permet également d'utiliser le script d'init fourni par Debian, pour démarrer automatiquement la réplication.
|
||||
|
||||
* Sur les 2 machines, copier le fichier d'exemple fourni puis configurer les hosts et sets de la même façon que dans la méthode manuelle :
|
||||
|
||||
~~~
|
||||
zcat /usr/share/doc/slony1-2-bin/examples/slon_tools.conf-sample.gz >/etc/slony1/slon_tools.conf
|
||||
~~~
|
||||
|
||||
~~~
|
||||
# $Id: slon_tools.conf-sample,v 1.8.2.4 2009-08-17 22:21:38 devrim Exp $
|
||||
# Author: Christopher Browne
|
||||
|
@ -237,6 +244,7 @@ if ($ENV{"SLONYSET"}) {
|
|||
* _add_node()_ : cette fonction permet d'ajouter une base de données dans le cluster, en indiquant ses paramètres de connexion classique ;
|
||||
* _$SLONY_SETS_ : ce tableau contient une liste de sets décrivant les tables à répliquer. Pour chaque set, on peut redéfinir quel node est le master avec la clé _origin_. Autrement, c'est $MASTERNODE qui est utilisé. La clé _pkeyedtables_ contient la liste des tables à répliquer.
|
||||
* On peut maintenant faire appel aux scripts Perl pour mettre en place la réplication. Les scripts Perl ne font que générer le code slonik, il est nécessaire de les piper dans ~~~slonik}} (l'interpréteur) pour qu'il l'exécute. Sur une des deux machines :
|
||||
|
||||
~~~
|
||||
# Initialise le cluster Slony
|
||||
slonik_init_cluster | slonik
|
||||
|
@ -252,6 +260,7 @@ slonik_create_set set1 | slonik
|
|||
~~~
|
||||
|
||||
* Enfin, abonner la machine test2 aux modifications faite sur le set1 :
|
||||
|
||||
~~~
|
||||
$ slonik_subscribe_set set1 node2 | slonik
|
||||
~~~
|
||||
|
@ -265,10 +274,13 @@ slonik_move_set <set_id> <node_id ancien master> <node_id nouveau master> | slon
|
|||
~~~
|
||||
|
||||
Note : ça ne marche pas terrible pour l'instant, si lors d'une écriture sur une table répliquée cette erreur apparait :
|
||||
|
||||
~~~
|
||||
ERREUR: Slony-I: Table table1 is currently locked against updates because of MOVE_SET operation in progress
|
||||
~~~
|
||||
|
||||
Il faut délocker manuellement le set :
|
||||
|
||||
~~~
|
||||
(slonik_print_preamble; echo "unlock set(ID=<set_id>, ORIGIN=<node_id du master>);") |slonik
|
||||
~~~
|
||||
|
@ -276,6 +288,7 @@ Il faut délocker manuellement le set :
|
|||
#### Autoriser les écritures sur le slave
|
||||
|
||||
Dans le cas où le master est down, et donc que le `slonik_move_set` ne marche pas (il a besoin de se connecter au futur slave pour le passer en slave) :
|
||||
|
||||
~~~
|
||||
slonik_failover <node_id du master> <node_id du slave> | slonik
|
||||
~~~
|
||||
|
@ -283,6 +296,7 @@ slonik_failover <node_id du master> <node_id du slave> | slonik
|
|||
#### Modifier de la structure d'une table répliquée
|
||||
|
||||
Slony ne répliquant que les données, en cas de modification de la structure d'une table sur un node, il faut la répercuter manuellement sur tous les autres. Un script Perl existe pour le faire sur tout les nodes à la fois :
|
||||
|
||||
~~~
|
||||
slonik_execute_script <set_id> script.sql |slonik
|
||||
~~~
|
||||
|
@ -290,6 +304,7 @@ slonik_execute_script <set_id> script.sql |slonik
|
|||
#### Ajouter une nouvelle table
|
||||
|
||||
* Dans le cas où elles ne sont présentes uniquement sur le master :
|
||||
|
||||
~~~
|
||||
postgres@master$ pg_dump --schema-only -t table1 -t table2 [...] base >new-tables.sql
|
||||
postgres@slave$ psql base <new-tables.sql
|
||||
|
@ -308,22 +323,28 @@ postgres@slave$ psql base <new-tables.sql
|
|||
],
|
||||
},
|
||||
~~~
|
||||
|
||||
_table_id_ et _sequence_id_ indiquent à partir de quel ID Slony peut commencer à numéroter les nouvelles tables/sequences à ajouter. Ils doivents être uniques dans tout le cluster. Pour les déterminer :
|
||||
|
||||
~~~
|
||||
SELECT tab_id FROM _replication.sl_table ORDER BY tab_id DESC LIMIT 1; -- +1
|
||||
select seq_id from _replication.sl_sequence order by seq_id desc limit 1; -- +1
|
||||
~~~
|
||||
|
||||
puis :
|
||||
|
||||
~~~
|
||||
slonik_create_set <nouveau set> | slonik
|
||||
~~~
|
||||
|
||||
* Abonner le nouveau set au slave :
|
||||
|
||||
~~~
|
||||
slonik_subscribe_set <nouveau set> <node slave> |slonik
|
||||
~~~
|
||||
|
||||
* Un fois que la synchro est terminée (TODO), on peut merger le nouveau set avec l'actuel :
|
||||
|
||||
~~~
|
||||
slonik_merge_sets <node master> <set actuel> <nouveau set> |slonik
|
||||
~~~
|
||||
|
@ -332,17 +353,20 @@ slonik_merge_sets <node master> <set actuel> <nouveau set> |slonik
|
|||
|
||||
#### Pour désinstaller un node/set/toute la conf Slony
|
||||
|
||||
* Désactiver un set. Cela va supprimer les trigger positionnés sur toutes les tables du set, sur tous les nodes. Le schéma __replication_ est laissé intact :
|
||||
* Désactiver un set. Cela va supprimer les trigger positionnés sur toutes les tables du set, sur tous les nodes. Le schéma _replication_ est laissé intact :
|
||||
|
||||
~~~
|
||||
$ slonik_drop_set set1 | slonik
|
||||
~~~
|
||||
|
||||
* Désactiver un node. Cela va supprimer les triggers de tous les sets du node, et supprimer le schéma __replication_. La commande échoue si des nodes sont encore abonnés au node à supprimer :
|
||||
* Désactiver un node. Cela va supprimer les triggers de tous les sets du node, et supprimer le schéma _replication_. La commande échoue si des nodes sont encore abonnés au node à supprimer :
|
||||
|
||||
~~~
|
||||
$ slonik_drop_node node2 | slonik
|
||||
~~~
|
||||
|
||||
* Désinstaller Slony. Cela va supprimer entièrement tous les triggers et le schéma Slony sur tous les nodes :
|
||||
|
||||
~~~
|
||||
$ slonik_uninstall_nodes set1 node1 | slonik
|
||||
~~~
|
||||
|
@ -357,7 +381,7 @@ Afficher l'état de la réplication :
|
|||
~~~
|
||||
=# select ev_origin,ev_seqno,"pg_catalog".txid_snapshot_xmin(ev_snapshot) from _replication.sl_event where
|
||||
(ev_origin, ev_seqno) in (select ev_origin, min(ev_seqno) from _replication.sl_event where ev_type = 'SYNC' group by ev_origin);
|
||||
ev_origin | ev_seqno | txid_snapshot_xmin
|
||||
ev_origin | ev_seqno | txid_snapshot_xmin
|
||||
-----------+------------+--------------------
|
||||
1 | 5000179913 | 13214118
|
||||
2 | 5000000016 | 163352
|
||||
|
@ -393,6 +417,7 @@ Voir <http://venublog.com/tag/how-to-purge-slony-log-tables/>
|
|||
Note : théoriquement, cela devrait se produire très rarement.
|
||||
|
||||
Dans les logs du slave, si un message de ce type aparrait :
|
||||
|
||||
~~~
|
||||
insert into "public"."nom_de_la_table" (...) values (...);
|
||||
" ERROR: duplicate key value violates unique constraint "..."
|
||||
|
@ -418,6 +443,7 @@ On peut faire simplement un `TRUNCATE table` sur le slave à chaud, sans arrête
|
|||
#### En cas de transaction bloquée
|
||||
|
||||
Message d'erreur dans les logs :
|
||||
|
||||
~~~
|
||||
transactions earlier than XID 12806955 are still in progress
|
||||
data copy for set 1 failed 11 times - sleep 60 seconds
|
||||
|
@ -434,6 +460,7 @@ Rien de particulier à faire, si ce n'est d'attendre que la requête ayant posé
|
|||
* ajouter les autorisations firewall/PostgreSQL nécessaire depuis/vers toutes les machines du cluster ;
|
||||
* réinjecter la structure de la base de données à répliquer, à l'exception du schéma Slony ;
|
||||
* sur la nouvelle machine, exécuter les commandes suivantes :
|
||||
|
||||
~~~
|
||||
# slonik_store_node node3 |slonik
|
||||
# slonik_subscribe_set set1 node3 | slonik
|
||||
|
@ -444,6 +471,7 @@ La nouvelle machine se voit attribuer le numéro « node3 » et est abonnée a
|
|||
#### set mal supprimé
|
||||
|
||||
Si un set est toujours présent dans la table sl_set :
|
||||
|
||||
~~~
|
||||
=# select * from _replication.sl_set;
|
||||
set_id | set_origin | set_locked | set_comment
|
||||
|
@ -453,21 +481,23 @@ Si un set est toujours présent dans la table sl_set :
|
|||
~~~
|
||||
|
||||
Et que Slony ne le voit plus :
|
||||
|
||||
~~~
|
||||
# slonik_drop_set 2
|
||||
Non-existent set specified.
|
||||
~~~
|
||||
|
||||
Il faut alors le supprimer à la main :
|
||||
|
||||
~~~
|
||||
=# delete from _replication.sl_set where set_id=2;
|
||||
~~~
|
||||
|
||||
### Fonctionnement des tables sl_log_{1,2}
|
||||
|
||||
1. Opération d'écriture sur le nœud maître -> les données modifiées vont être insérées dans la table _sl_log_1_, grace au trigger __replication_logtrigger_ positionné sur la table ayant subie les modifications.
|
||||
2. Sur le nœud esclave, le démon _slon_ lit à intervalles réguliers la table de log active, ici _sl_log_1_. Il va alors récupérer les nouvelles entrées pour les copier dans sa propre table de log. À noter qu'avant de se connecter à la base PostgreSQL sur le nœud maître, il « pingue » le démon slon sur le master, et si il ne répond pas, ne fait rien. Par conséquent, si un des deux démon _slon_ ne tourne pas, la réplication ne se fait pas.
|
||||
3. Les nouvelles modifications sont alors rejouer sur le slave.
|
||||
1. Opération d'écriture sur le nœud maître -> les données modifiées vont être insérées dans la table _sl_log_1_, grace au trigger __replication_logtrigger_ positionné sur la table ayant subie les modifications.
|
||||
2. Sur le nœud esclave, le démon _slon_ lit à intervalles réguliers la table de log active, ici _sl_log_1_. Il va alors récupérer les nouvelles entrées pour les copier dans sa propre table de log. À noter qu'avant de se connecter à la base PostgreSQL sur le nœud maître, il « pingue » le démon slon sur le master, et si il ne répond pas, ne fait rien. Par conséquent, si un des deux démon _slon_ ne tourne pas, la réplication ne se fait pas.
|
||||
3. Les nouvelles modifications sont alors rejouer sur le slave.
|
||||
|
||||
Par défaut (option _cleanup_deletelogs=false_), les entrées dans les tables de logs ne sont pas supprimées, étant donné qu'un _DELETE_ à chaque fois peut être assez coûteux en terme de ressources pour la base de données. Un basculement de tables est alors opéré (par défaut toutes les 10 minutes, modifiable par l'option _cleanup_interval_), de _sl_log_1_ vers _sl_log_2_ ou inversement, ce qui permet de repartir sur une table vide. Un _TRUNCATE_ est alors exécuté sur l'ancienne table de log pour la nettoyer. Tous les 3 cycles de basculement, un _VACUUM_ est exécuté sur la table de log (définit par la variable _vac_frequency_).
|
||||
|
||||
|
@ -478,7 +508,8 @@ Pour connaître la table de log active :
|
|||
Des informations sur la réplication en temps réel sont disponibles dans les tables _sl_*_ du schéma __CLUSTERNAME_ (par défaut __slony_namespace_). Le détail de ces tables est disponible ici : <http://slony.info/documentation/monitoring.html>
|
||||
|
||||
Un script fournit avec Slony, _check_slony_cluster.sh_peut être utilisé comme check Nagios pour vérifier que la réplication est ok. Pour qu'il puisse être utilisé en tant que postgres sans demander de mot de passe, il est nécessaire de l'adapter un peu :
|
||||
~~~
|
||||
|
||||
~~~{.diff}
|
||||
--- /usr/share/doc/slony1-2-bin/examples/check_slony_cluster.sh.orig 2012-03-27 15:57:45.000000000 +0200
|
||||
+++ /usr/share/doc/slony1-2-bin/examples/check_slony_cluster.sh 2012-03-27 15:57:47.000000000 +0200
|
||||
@@ -11,7 +11,6 @@
|
||||
|
@ -497,24 +528,25 @@ Un script fournit avec Slony, _check_slony_cluster.sh_peut être utilisé comme
|
|||
+ echo "Invalid parameters need CLUSTERNAME DBNAME"
|
||||
exit 2
|
||||
fi
|
||||
|
||||
|
||||
# assign parameters
|
||||
CLUSTERNAME=$1
|
||||
DBNAME=$2
|
||||
-DBHOST=$3
|
||||
|
||||
|
||||
# setup the query to check the replication status
|
||||
SQL="select case
|
||||
@@ -56,7 +54,7 @@
|
||||
) as t2"
|
||||
|
||||
|
||||
# query the master database
|
||||
-CHECK=`psql -c "$SQL" --tuples-only -U postgres -h $DBHOST $DBNAME`
|
||||
+CHECK=`psql -c "$SQL" --tuples-only $DBNAME`
|
||||
|
||||
|
||||
if [ ! -n "$CHECK" ]
|
||||
then
|
||||
~~~
|
||||
|
||||
~~~
|
||||
/usr/share/doc/slony1-2-bin/examples/check_slony_cluster.sh slony_namespace dbrepl2 localhost
|
||||
~~~
|
||||
~~~
|
||||
|
|
|
@ -27,6 +27,7 @@ Pré-requis pour pouvoir mettre en place une infra avec 1 maître et 1 esclave
|
|||
### Installation de PostgreSQL 9.2
|
||||
|
||||
Sous Debian Wheezy, installation depuis le dépôt Debian de PostgreSQL :
|
||||
|
||||
~~~
|
||||
# echo "deb <http://apt.postgresql.org/pub/repos/apt/> wheezy-pgdg main" >/etc/apt/sources.list.d/wheezy-pgdg.list
|
||||
# echo "Package: postgresql-9.2 postgresql-client-common postgresql-common libpq5
|
||||
|
@ -44,6 +45,7 @@ Les paquets sont maintenus par les mêmes développeurs que sur Debian et Ubuntu
|
|||
_Cette configuration est relative au serveur maître, mais elle doit également être reprise à l'identique sur le serveur esclave, dans le cas où les rôles doivent être échangés (suite à un failover/switchover)._
|
||||
|
||||
Décommenter ou ajouter les directives suivantes dans le fichier _/etc/postgresql/9.2/main/postgresql.conf_ :
|
||||
|
||||
~~~
|
||||
# Nécessaire pour que l'esclave puisse se connecter.
|
||||
listen_addresses = '*'
|
||||
|
@ -65,11 +67,13 @@ archive_command = 'rsync %p 192.0.2.2:/srv/pg-archives/%f'
|
|||
~~~
|
||||
|
||||
Créer un utilisateur dédié pour la réplication :
|
||||
|
||||
~~~
|
||||
postgres=# CREATE ROLE repl WITH LOGIN REPLICATION PASSWORD 'xxxxxxxx';
|
||||
~~~
|
||||
|
||||
Autoriser le serveur esclave à se connecter au maître :
|
||||
|
||||
~~~
|
||||
hostssl replication repl 192.0.2.2/32 md5
|
||||
~~~
|
||||
|
@ -79,12 +83,14 @@ hostssl replication repl 192.0.2.2/32 md5
|
|||
_Cette configuration est relative au serveur esclave, mais elle doit également être reprise à l'identique sur le serveur maître, en renommant le fichier _recovery.conf_ pour qu'il ne soit pas pris en compte._
|
||||
|
||||
Décommenter ou ajouter les directives suivantes dans le fichier _/etc/postgresql/9.2/main/postgresql.conf_ :
|
||||
|
||||
~~~
|
||||
# Le serveur est en mode esclave en lecture seule
|
||||
hot_standby = on
|
||||
~~~
|
||||
|
||||
Créer un fichier _recovery.conf_ avec les info suivantes :
|
||||
|
||||
~~~
|
||||
# echo "standby_mode = 'on'
|
||||
> primary_conninfo = 'host=192.0.2.1 user=repl password=xxxxxxxx application_name=foo'
|
||||
|
@ -93,6 +99,7 @@ Créer un fichier _recovery.conf_ avec les info suivantes :
|
|||
~~~
|
||||
|
||||
Il est nécessaire que ce fichier appartiennent à l'utilisateur _postgres_, notamment pour le [#Passerunserveuresclaveenmaître failover] :
|
||||
|
||||
~~~
|
||||
# chown postgres:postgres ~postgres/9.2/main/recovery.conf
|
||||
~~~
|
||||
|
@ -101,17 +108,23 @@ Il est nécessaire que ce fichier appartiennent à l'utilisateur _postgres_, not
|
|||
|
||||
* Arrêter PostgreSQL sur l'esclave ;
|
||||
* sur le maître, indiquer à PostgreSQL qu'on commence une sauvegarde. Il va notamment faire un checkpoint dans son WAL courant et retourner sa position :
|
||||
|
||||
~~~
|
||||
postgres$ psql -c "SELECT pg_start_backup('synchro initiale')"
|
||||
~~~
|
||||
|
||||
* lancer le rsync du datadir vers l'esclave :
|
||||
|
||||
~~~
|
||||
# rsync -avz --delete --exclude /pg_xlog/* --exclude /postmaster.* --exclude /recovery.* ~postgres/9.2/main/ 192.0.2.2:~postgres/9.2/main/
|
||||
~~~
|
||||
|
||||
* indiquer à PostgreSQL que le backup est terminé :
|
||||
|
||||
~~~
|
||||
postgres$ psql -c "SELECT pg_stop_backup()"
|
||||
~~~
|
||||
|
||||
* redémarrer PostgreSQL sur l'esclave.
|
||||
|
||||
### Administration
|
||||
|
@ -121,11 +134,14 @@ postgres$ psql -c "SELECT pg_stop_backup()"
|
|||
Plusieurs possibilité pour surveiller la réplication :
|
||||
|
||||
* Voir la position courante dans les logs sur le maître et l'esclave (on peut en déduire si ils sont synchro ou pas) :
|
||||
|
||||
~~~
|
||||
# pgrep -lf "wal (sender|receiver) process"
|
||||
6891 postgres: wal receiver process streaming 0/C085240
|
||||
~~~
|
||||
|
||||
* PostgreSQL fournit la vue `pg_stat_replication()` qui permet de lister les connexions aux processus walsender, avec différentes informations utiles :
|
||||
|
||||
~~~
|
||||
postgres=# SELECT * from pg_stat_replication;
|
||||
-[ RECORD 1 ]----+------------------------------
|
||||
|
@ -134,7 +150,7 @@ usesysid | 16387
|
|||
usename | repl
|
||||
application_name | foo
|
||||
client_addr | 192.0.2.2
|
||||
client_hostname |
|
||||
client_hostname |
|
||||
client_port | 46581
|
||||
backend_start | 2013-04-30 10:39:43.230287-04
|
||||
state | streaming
|
||||
|
@ -149,20 +165,24 @@ sync_state | async
|
|||
Les données à surveiller sont notamment les _*_location_, qui indique la position courante dans les WAL à différentes étapes de la réplication.
|
||||
Voir <http://www.postgresql.org/docs/9.2/static/monitoring-stats.html#PG-STAT-REPLICATION-VIEW> pour le détails des champs.
|
||||
* Pour pouvoir quantifié le retard de réplication, on peut utiliser la commande [check_postgres](http://bucardo.org/check_postgres/check_postgres.pl.html) avec l'option _hot_standby_delay_ :
|
||||
|
||||
~~~
|
||||
$ check_postgres --action=hot_standby_delay --dbhost=localhost --dbport=5432 --dbname=template1 --dbuser=nrpe --dbpass=xxxxxx --dbhost=192.0.2.2 --dbport=5432 --warning=500000 --critical=1000000
|
||||
POSTGRES_HOT_STANDBY_DELAY OK: DB "template1" (host:192.0.2.2) 0 | time=0.09s replay_delay=12568;500000;1000000 receive-delay=8192;500000;1000000
|
||||
POSTGRES_HOT_STANDBY_DELAY OK: DB "template1" (host:192.0.2.2) 0 | time=0.09s replay_delay=12568;500000;1000000 receive-delay=8192;500000;1000000
|
||||
~~~
|
||||
Où localhost est le maître et 192.0.2.2 l'esclave. Les valeurs de _replay_delay_ et _receive-delay_ sont *à priori* exprimées en octets de WAL à rejouer.
|
||||
|
||||
Où localhost est le maître et 192.0.2.2 l'esclave. Les valeurs de _replay_delay_ et _receive-delay_ sont *à priori* exprimées en octets de WAL à rejouer.
|
||||
|
||||
#### Passer un serveur esclave en maître
|
||||
|
||||
Si le maître est toujours joignable, éteindre PostgreSQL en forçant la déconnexion des clients :
|
||||
|
||||
~~~
|
||||
# pg_ctlcluster 9.2 main stop -- -m fast
|
||||
~~~
|
||||
|
||||
Sur l'esclave, faire en sorte que PostgreSQL accepte les connexions en écriture :
|
||||
|
||||
~~~
|
||||
# pg_ctlcluster 9.2 main promote
|
||||
~~~
|
||||
|
@ -172,6 +192,7 @@ L'esclave va d'abord rattraper son éventuel retard dans le traitement des logs
|
|||
Le fichier _recovery.conf_ est renommé en _recovery.done_ pour qu'il ne soit pas lu en cas de redémarrage de PostgreSQL.
|
||||
|
||||
Messages de PostgreSQL lors du passage en maître :
|
||||
|
||||
~~~
|
||||
2013-04-23 05:54:15 EDT LOG: received promote request
|
||||
2013-04-23 05:54:15 EDT LOG: redo done at 0/6000020
|
||||
|
@ -191,12 +212,16 @@ Messages de PostgreSQL lors du passage en maître :
|
|||
Il faut alors mettre en place le _recovery.conf_ sur l'ancien master et démarrer PostgreSQL. Il va alors rejouer les WAL pour rattraper le retard accumulé, puis se mettre en mettre en mode _streaming replication_.
|
||||
|
||||
#### Arrêter la réplication
|
||||
*Arrêter/reprendre le "replay" des WAL sur l'esclave :
|
||||
|
||||
* Arrêter/reprendre le "replay" des WAL sur l'esclave :
|
||||
|
||||
~~~
|
||||
postgres=# SELECT pg_xlog_replay_pause();
|
||||
postgres=# SELECT pg_xlog_replay_resume();
|
||||
~~~
|
||||
|
||||
* Arrêter/reprendre le flux des WAL depuis le maître. Il ne semble pas y avoir de solution autre que de couper le flux au niveau réseau. Sur le maître :
|
||||
|
||||
~~~
|
||||
# iptables -I INPUT -s 192.0.2.2 -p tcp --dport 5432 -j REJECT
|
||||
# iptables -D INPUT 1
|
||||
|
@ -206,4 +231,4 @@ postgres=# SELECT pg_xlog_replay_resume();
|
|||
|
||||
* Si une requête sur le serveur esclave bloque la réplication (par exemple un `SELECT` qui bloque un `DROP TABLE`) pendant un temps trop long, la requête sur l'esclave sera tuée (ici le SELECT). Ce temps est définit par la directive `max_standby_streaming_delay` sur la configuration de l'esclave.
|
||||
|
||||
Ce comportement peut-être désactivé grâce à la directive `hot_standby_feedback`, qui fait en sorte que l'esclave communique l'état des requêtes au maître, mais cela à un impact sur le maître.
|
||||
Ce comportement peut-être désactivé grâce à la directive `hot_standby_feedback`, qui fait en sorte que l'esclave communique l'état des requêtes au maître, mais cela à un impact sur le maître.
|
||||
|
|
|
@ -6,6 +6,7 @@
|
|||
|
||||
* PHP 5.2 ou plus.
|
||||
* php.ini:
|
||||
|
||||
~~~
|
||||
allow_url_fopen on
|
||||
register_globals off
|
||||
|
@ -13,6 +14,7 @@ magic_quotes_* off
|
|||
safe_mode off
|
||||
upload_max_filesize > "16M" ou plus.
|
||||
~~~
|
||||
|
||||
Extensions PHP utiles : PDO_MySQL, cURL, SimpleXML, mcrypt, GD, OpenSSL, DOM, SOAP.
|
||||
|
||||
* MySQL 5.0 ou plus
|
||||
|
@ -21,6 +23,7 @@ Les + :
|
|||
|
||||
* Serveur web Apache 1.3 ou plus, ou serveur nginx.
|
||||
* apache
|
||||
|
||||
~~~
|
||||
mod_rewrite, mod_security, mod_auth_basic
|
||||
~~~
|
||||
|
@ -32,6 +35,7 @@ Télécharger la dernière version _stable_ de prestashop par archive ou par dé
|
|||
Selon la version, peut avoir un problème dans le fichier `config/autoload.php` : commenter la ligne qui gène si optionnel.
|
||||
|
||||
* Utiliser la ligne de commande pour installer prestashop:
|
||||
|
||||
~~~
|
||||
php './install-dev/index_cli.php' --language=fr --timezone='localhost' --base_uri='/' --domain='{{ host }}' \
|
||||
--db_server='{{ db_host }}' --db_user='{{ db_user }}' --db_password='{{ db_pwd }}' --db_name='{{ db_name }}' \
|
||||
|
@ -41,15 +45,13 @@ php './install-dev/index_cli.php' --language=fr --timezone='localhost' --base_ur
|
|||
|
||||
* supprimer le repertoire `install-dev`
|
||||
* S'assurer des droits pour le groupe <user> afin que l'instance du serveur web lancé en tant que www-<user> puisse écrire dans les répertoires.
|
||||
|
||||
~~~
|
||||
$ chmod -R g+w config/ cache/ log/ img/ mails/ modules/ themes/ translations/ upload/ download/
|
||||
~~~
|
||||
|
||||
* Après installation :
|
||||
|
||||
~~~
|
||||
$ mv admin/ admin$RANDOM/
|
||||
~~~
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -38,7 +38,6 @@ AllowStoreRestart on
|
|||
AllowGroup ftpusers
|
||||
DenyAll
|
||||
</Limit>
|
||||
|
||||
~~~
|
||||
|
||||
Les utilisateurs pouvant utilisant le FTP doivent être dans le groupe _ftpusers_ (à créer !).
|
||||
|
@ -46,6 +45,7 @@ Les utilisateurs pouvant utilisant le FTP doivent être dans le groupe _ftpusers
|
|||
## Création de comptes virtuels
|
||||
|
||||
À ajouter dans _/etc/proftpd/proftpd.conf_ :
|
||||
|
||||
~~~
|
||||
AuthOrder mod_auth_file.c
|
||||
AuthUserFile /etc/proftpd/vpasswd
|
||||
|
|
|
@ -119,15 +119,15 @@ Créer le manifest suivant, test.pp
|
|||
Pour vérifier, on peut l'appliquer directement sur le serveur par exemple, avec la commande suivante :
|
||||
|
||||
~~~
|
||||
puppet apply test.pp
|
||||
puppet apply test.pp
|
||||
notice: /Stage[main]//File[testfile]/ensure: created
|
||||
~~~
|
||||
|
||||
Modifier les droits du fichiers, puis re-faites un `apply` :
|
||||
Modifier les droits du fichiers, puis re-faites un `apply` :
|
||||
|
||||
~~~
|
||||
chmod 777 /tmp/testfile
|
||||
puppet apply test.pp
|
||||
chmod 777 /tmp/testfile
|
||||
puppet apply test.pp
|
||||
notice: /Stage[main]//File[testfile]/mode: mode changed '777' to '640'
|
||||
~~~
|
||||
|
||||
|
@ -136,6 +136,7 @@ notice: /Stage[main]//File[testfile]/mode: mode changed '777' to '640'
|
|||
Sur le serveur il faut faire une liste des nœuds (clients) et quels manifests leur affecter.
|
||||
|
||||
/etc/puppet/manifests/site.pp
|
||||
|
||||
~~~
|
||||
class test{
|
||||
file {'testfile':
|
||||
|
@ -169,4 +170,4 @@ class test{
|
|||
source => "puppet://master.mondomaine.com/files/apps/sudo/sudoers"
|
||||
}
|
||||
}
|
||||
~~~
|
||||
~~~
|
||||
|
|
|
@ -33,7 +33,7 @@ Installer les bindings MySQL et OpenSSL (voir [#les-gems Les gems]) :
|
|||
Les gems sont des paquets contentant des librairies et/ou des applications écrites en Ruby. Elles sont énormément utilisées, notamment dans Rails.
|
||||
|
||||
Par défaut, aucune librairie n'est installée sous forme de gem à part les bindings MySQL et Rack (qui est une dépendance de Passenger)
|
||||
Il est préférable d'installer les bindings MySQL à la main (`libmysql-ruby`) car ils nécessitent la compilation d'extensions en C et
|
||||
Il est préférable d'installer les bindings MySQL à la main (`libmysql-ruby`) car ils nécessitent la compilation d'extensions en C et
|
||||
risquent d'être utilisés par tous les utilisateurs.
|
||||
|
||||
OpenSSL fait normalement partie de la librairie standard Ruby, mais n'est pas inclus dans Debian. Rails en a besoin pour fonctionner, il convient
|
||||
|
@ -41,14 +41,14 @@ donc d'installer `libopenssl-ruby` manuellement.
|
|||
|
||||
### Ruby Enterprise Edition (REE)
|
||||
|
||||
REE est une version patchée de Ruby optimisée pour les applications Web et créée par les mêmes développeurs que Passenger.
|
||||
REE est une version patchée de Ruby optimisée pour les applications Web et créée par les mêmes développeurs que Passenger.
|
||||
REE est donc censé s'intégrer parfaitement avec Passenger.
|
||||
|
||||
Des paquets (ubuntu) existent pour REE, mais le plus simple est de le compiler à la main.
|
||||
Des paquets (ubuntu) existent pour REE, mais le plus simple est de le compiler à la main.
|
||||
Par défaut il s'installera dans le dossier `/opt`, en totale isolation du reste du système.
|
||||
Rubygems est livré avec REE, et est placé dans le dossier de ce dernier.
|
||||
|
||||
Il suffit de récupérer une [archive des sources sur le site de REE](http://rubyenterpriseedition.com),
|
||||
Il suffit de récupérer une [archive des sources sur le site de REE](http://rubyenterpriseedition.com),
|
||||
de la décompresser et de lancer le script `./installer --no-dev-docs` en tant que root. Le reste de la procédure est indiqué
|
||||
par l'installateur.
|
||||
|
||||
|
@ -73,7 +73,7 @@ On installe ensuite REE selon la procédure définie ci-dessus, et une fois cett
|
|||
|
||||
L'installateur nous guide dans la procédure. Dans le cas ou le MPM d'Apache est ITK, il préviendra :
|
||||
|
||||
~~~
|
||||
~~~
|
||||
WARNING: Apache doesn't seem to be compiled with the 'prefork' or 'worker' MPM
|
||||
~~~
|
||||
|
||||
|
@ -113,8 +113,8 @@ Pour la deuxième solution, le script suivant permet d'automatiser la tâche :
|
|||
~~~
|
||||
#!/bin/bash
|
||||
cd /usr/bin
|
||||
for i in `ls -1d /opt/ruby-enterprise-*/bin/*`; do
|
||||
ln -s $i
|
||||
for i in `ls -1d /opt/ruby-enterprise-*/bin/*`; do
|
||||
ln -s $i
|
||||
done
|
||||
~~~
|
||||
|
||||
|
@ -129,7 +129,7 @@ on commence par désactiver ce comportement dans `/etc/apache2/mods-available/pa
|
|||
PassengerRoot /usr
|
||||
PassengerRuby /usr/bin/ruby1.8
|
||||
|
||||
# On ajoute les lignes suivantes:
|
||||
# On ajoute les lignes suivantes:
|
||||
PassengerEnabled off
|
||||
RailsAutoDetect off
|
||||
RackAutoDetect off
|
||||
|
@ -182,7 +182,7 @@ Chacun a un but précis facilement devinable depuis son nom.
|
|||
Par défaut, Passenger fait tourner l'application en mode production. On peut forcer un certain environnement
|
||||
en plaçant la directive `RailsEnv <env>` dans le fichier de configuration du VHost.
|
||||
|
||||
Pour lancer dans un certain environnement les commandes qui agissent avec l'application (par exemple les
|
||||
Pour lancer dans un certain environnement les commandes qui agissent avec l'application (par exemple les
|
||||
tâches [Rake](http://guides.rubyonrails.org/command_line.html#rake-is-ruby-make)), il suffit de définir la
|
||||
variable d'environnement RAILS_ENV, par exemple :
|
||||
|
||||
|
@ -193,7 +193,7 @@ $ RAILS_ENV=production rake db:migrate
|
|||
#### Redémarrage de l'application
|
||||
|
||||
Pour redémarrer une application Rails, il suffit de créer ou de mettre à jour le timestamp du fichier
|
||||
`tmp/restart.txt` (avec la commande `touch` par exemple). À la prochaîne requête, l'application sera
|
||||
`tmp/restart.txt` (avec la commande `touch` par exemple). À la prochaîne requête, l'application sera
|
||||
redémarrée et tout l'environement chargé de nouveau.
|
||||
|
||||
Pour que l'application redémarre à chaque requête on peut aussi créer un fichier `tmp/always_restart.txt`
|
||||
|
@ -202,7 +202,7 @@ et le supprimer une fois qu'on ne souhaite plus ce comportement.
|
|||
#### `umask`s spéciaux
|
||||
|
||||
Sur certains système, l'umask par défaut rend les fichiers installés par root non lisibles par le commun des utilisateurs.
|
||||
Si celà est une bonne idée, combinée avec Rubygems et Apache ITK, celà devient moins évident, et il faut veiller
|
||||
Si celà est une bonne idée, combinée avec Rubygems et Apache ITK, celà devient moins évident, et il faut veiller
|
||||
à `chmod`er correctement le dossier de Ruby pour que tous les utilisateurs puissent l'utiliser.
|
||||
|
||||
Un exemple avec REE :
|
||||
|
@ -214,8 +214,8 @@ Un exemple avec REE :
|
|||
#### Priorités de chargement
|
||||
|
||||
Par défaut, même lorsque `rubygems` est activé, Ruby utilisera en priorité les librairies système
|
||||
(celles installées par les paquets) plutôt que les gems. On peut cependant forcer l'utilisation d'une gem,
|
||||
et même fixer la version désirée (sinon c'est la plus récente qui est automatiquement utilisée).
|
||||
(celles installées par les paquets) plutôt que les gems. On peut cependant forcer l'utilisation d'une gem,
|
||||
et même fixer la version désirée (sinon c'est la plus récente qui est automatiquement utilisée).
|
||||
|
||||
Cette gestion des versions doit être faite par le développeur, qui peut installer les librairies qu'il souhaite indépendamment du système.
|
||||
L'important est de savoir qu'il y a trois endroits ou on peut trouver une librairie Ruby :
|
||||
|
@ -226,17 +226,17 @@ L'important est de savoir qu'il y a trois endroits ou on peut trouver une librai
|
|||
|
||||
#### Lister les gems
|
||||
|
||||
Il n'existe pas de moyen de lister les gems installées uniquement sur le système, la commande `gem` cherche
|
||||
à la fois dans le dossier `.gem` de l'utilisateur et le dossier système. La solution est d'utiliser un script
|
||||
Il n'existe pas de moyen de lister les gems installées uniquement sur le système, la commande `gem` cherche
|
||||
à la fois dans le dossier `.gem` de l'utilisateur et le dossier système. La solution est d'utiliser un script
|
||||
spécialisé qui fait cette recherche.
|
||||
|
||||
Le script est disponible dans le dépôt Subversion du Pack Web Evolix, dans
|
||||
Le script est disponible dans le dépôt Subversion du Pack Web Evolix, dans
|
||||
[trunk/scripts/list_gems](http://forge.evolix.org/scm/viewvc.php/trunk/scripts/list_gems?view=markup&root=packweb).
|
||||
|
||||
#### Économiser un peu d'espace
|
||||
|
||||
Par défaut, `gem` installe la documentation aux formats RDoc (documentation html) et RI (documentation console)
|
||||
pour les gems installées. Pour éviter celà, créer un fichier `.gemrc` dans la `$HOME` de l'utilisateur avec le
|
||||
Par défaut, `gem` installe la documentation aux formats RDoc (documentation html) et RI (documentation console)
|
||||
pour les gems installées. Pour éviter celà, créer un fichier `.gemrc` dans la `$HOME` de l'utilisateur avec le
|
||||
contenu suivant :
|
||||
|
||||
~~~
|
||||
|
@ -248,13 +248,14 @@ gem: --no-rdoc --no-ri
|
|||
#### Rails 2.3.2->2.3.5 & Passenger & les logs
|
||||
|
||||
Une petite erreur en environnement de production affecte les versions 2.3.2 à 2.3.5 (incluse) de Rails. Les logs
|
||||
de l'application ne sont pas écrits dans le fichier `log/production.log`. Pour pallier cette erreur, il faut appliquer
|
||||
de l'application ne sont pas écrits dans le fichier `log/production.log`. Pour pallier cette erreur, il faut appliquer
|
||||
le patch qu'on trouve [ici](https://rails.lighthouseapp.com/projects/8994/tickets/3577-failsafe-middleware-should-flush-the-logger)
|
||||
(deuxième fichier).
|
||||
|
||||
#### Répertoire temporaire de Passenger
|
||||
|
||||
Passenger stocke tous ses fichiers temporaires dans le répertoire /tmp/ par défaut. Pour diverses raisons (de place, de droits voire de performance), il peut être intéressant d'en définir un autre. Cela ce fait via la directive Apache du module Passenger _PassengerTempDir_. Par exemple, nous mettons :
|
||||
|
||||
~~~
|
||||
PassengerTempDir /var/tmp/
|
||||
~~~
|
||||
|
@ -263,11 +264,14 @@ PassengerTempDir /var/tmp/
|
|||
|
||||
Passenger est installé en tant que gem dans _/opt/ruby-enterprise-<version-ree>/lib/ruby/gems/1.8/gems/_.
|
||||
Voici la procédure pour le mettre à jour :
|
||||
|
||||
~~~
|
||||
gem update passenger
|
||||
~~~
|
||||
|
||||
~~~
|
||||
/opt/ruby-enterprise-<version-ree>/lib/ruby/gems/1.8/gems/passenger-<nouvelle-version-passenger>/bin/passenger-install-apache2-module
|
||||
|
||||
~~~
|
||||
Puis modifier les chemins vers mod_passenger dans la conf d'Apache _/etc/apache2/mod-available/passenger_.{conf,load} pour pointer vers la nouvelle version (notamment les directives _LoadModule_ et _PassengerRoot_).
|
||||
Enfin, redémarrer Apache pour prendre en compte le nouveau module.
|
||||
|
@ -279,9 +283,11 @@ Pour mettre à jour REE, il suffit de recommencer la procédure d'installation,
|
|||
Pour prendre en compte la nouvelle installation de REE, il faut modifier les chemins vers REE dans la configuration d'Apache.
|
||||
|
||||
*Important :* pour la migration de REE 1.8.7-2010.02 vers 1.8.7-2011.01, il faut ajouter cette directive dans la configuration d'Apache :
|
||||
|
||||
~~~
|
||||
RackBaseURI /
|
||||
~~~
|
||||
|
||||
Et enlever les éventuelles directives `RailkBaseURI`.
|
||||
|
||||
|
||||
|
|
|
@ -21,21 +21,24 @@ Procédure à suivre :
|
|||
|
||||
* Télécharger le .zip de l'image système Lakka sur le site officiel Lakka.tv
|
||||
* Utiliser la ligne de commande gunzip pour extraire le .img depuis le .zip ou utiliser un outil graphique dedié
|
||||
|
||||
~~~
|
||||
$ ls -l /dev/sd*
|
||||
$ ls -l /dev/sd*
|
||||
~~~
|
||||
|
||||
* La commande ci-dessus va montrer les partitions accessibles ainsi que leur numéro. sda peut par exemple être le disque dur
|
||||
* Monter la carte SD sur un ordinateur sous linux (possible sous autre OS mais non expliqué ici)
|
||||
~~~
|
||||
Executer à nouveau
|
||||
$ ls -l /dev/sd*
|
||||
Cela devrait afficher les mêmes partitions que précédemment avec la carte SD en plus
|
||||
|
||||
$ sudo dd if=Lakka-*.img of=/dev/sdX
|
||||
Où Lakka-*.img est le chemin vers le .img extrait précedemment et sdX la carte SD (remplacer X par la lettre trouvée précedemment
|
||||
~~~
|
||||
*L'étape devrait prendre quelques petites minutes (même moins)
|
||||
Executer à nouveau
|
||||
$ ls -l /dev/sd*
|
||||
Cela devrait afficher les mêmes partitions que précédemment avec la carte SD en plus
|
||||
|
||||
$ sudo dd if=Lakka-*.img of=/dev/sdX
|
||||
Où Lakka-*.img est le chemin vers le .img extrait précedemment et sdX la carte SD (remplacer X par la lettre trouvée précedemment
|
||||
~~~
|
||||
|
||||
* L'étape devrait prendre quelques petites minutes (même moins)
|
||||
* Retirer en toute sécurité la carte SD et la placer dans le RaspberryPi
|
||||
* Brancher le HDMI entre le Raspberry et l'écran
|
||||
* Allumer l'écran
|
||||
|
@ -45,7 +48,8 @@ Procédure à suivre :
|
|||
|
||||
L'icône Lakka devrait apparaitre.
|
||||
Après quelques configurations automatiques, le menu Lakka devrait apparaitre.
|
||||
|
||||
* Si vous avez branché le cable ethernet, le Raspberry apparaitra sur vos autres ordinateurs dans le réseau local. Il est ensuite possible de remplir la carte SD de jeu dans le dossier ROMs s'y trouvant. Les images des jeux sont à placer, pas les .zip ou autre formats compressés.
|
||||
* Aller dans "Load Content (Detect Core) afin d'avoir la liste des jeux envoyés par ethernet
|
||||
|
||||
Bon jeu!
|
||||
Bon jeu!
|
||||
|
|
|
@ -24,7 +24,7 @@ Pin: release a=squeeze-backports
|
|||
Pin-Priority: 999
|
||||
~~~
|
||||
|
||||
*Sous Debian Jessie*, on installe Redis de la même manière (version 2.8.1). Si on utilise systemd, on surcharge l'unit redis.service en spécifiant le RuntimeDirectory (voir la note
|
||||
*Sous Debian Jessie*, on installe Redis de la même manière (version 2.8.1). Si on utilise systemd, on surcharge l'unit redis.service en spécifiant le RuntimeDirectory (voir la note
|
||||
[wiki:HowtoDebian/MigrationWheezyJessie#Redis ici]).
|
||||
|
||||
## Configuration
|
||||
|
@ -196,23 +196,18 @@ redis [master] 127.0.0.1:6379> set key value
|
|||
redis [slave] 127.0.0.1:6379> get key
|
||||
~~~
|
||||
|
||||
On devrait avoir « value ». Par ailleurs on pourra lire dans les logs du slave (/var/log/redis/redis-server.log) :
|
||||
|
||||
On devrait avoir « value ». Par ailleurs on pourra lire dans les logs du slave (/var/log/redis/redis-server.log) :
|
||||
|
||||
~~~
|
||||
[26287] 06 Sep 15:04:04 * MASTER <-> SLAVE sync: receiving 34 bytes from master
|
||||
~~~
|
||||
|
||||
|
||||
|
||||
Depuis redis 2.6 (2.4 en Wheezy), par défaut, le slave est en read-only, on peut le passer en read & write, en mettant ceci dans la configuration du slave :
|
||||
|
||||
|
||||
~~~
|
||||
slave-read-only off
|
||||
~~~
|
||||
|
||||
|
||||
### Sentinel
|
||||
|
||||
Sentinel permet de faire du failover avec des slaves Redis.
|
||||
|
@ -328,6 +323,7 @@ redis-benchmark -n 100000
|
|||
### Nagios
|
||||
|
||||
Un check Nagios « basique » consiste à initier une connexion TCP sur le socket unix du serveur Redis, et s'assurer qu'il répond bien :
|
||||
|
||||
~~~
|
||||
command[check_redis]=/usr/lib/nagios/plugins/check_tcp -H /var/run/redis.pid
|
||||
~~~
|
||||
|
@ -349,8 +345,8 @@ Vous devez renseigner la variable _env.path_ avec le chemin vers le socket unix
|
|||
|
||||
* Un autre plugin, fonctionnel sous Jessie est disponible ici : <https://github.com/bpineau/redis-munin>
|
||||
|
||||
Pour l'installer, spécifier env.password si nécessaire dans une section [redis_*] et :
|
||||
~~~
|
||||
Pour l'installer, spécifier env.password si nécessaire dans une section [redis_*] et :
|
||||
~~~
|
||||
# ln -s '/usr/share/munin/plugins/redis_' '/etc/munin/plugins/redis_127.0.0.1_6379'
|
||||
# /etc/init.d/munin-node restart
|
||||
~~~
|
||||
~~~
|
||||
|
|
|
@ -22,32 +22,43 @@ Informations supplémentaires :
|
|||
### 0. Prérequis (User = root)
|
||||
|
||||
Installations des dépendances :
|
||||
|
||||
~~~
|
||||
aptitude install ruby ruby-dev imagemagick git-core git-svn gcc build-essential libxml2-dev libxslt1-dev libssl-dev
|
||||
~~~
|
||||
|
||||
Installation des dépendances 2 (L'installation en une fois crée des conflits !) :
|
||||
|
||||
~~~
|
||||
aptitude install libmagickwand-dev libmagickcore-dev
|
||||
~~~
|
||||
|
||||
Si Squid est présent vous devez rajouter les sites github et rubygems dans sa liste blanche !
|
||||
|
||||
~~~
|
||||
echo "<https://github.com/.*"> >> /etc/squid3/whitelist.conf
|
||||
echo "<http://rubygems.org/.*"> >> /etc/squid3/whitelist.conf
|
||||
echo "<http://.*.rubygems.org/.*"> >> /etc/squid3/whitelist.conf
|
||||
~~~
|
||||
|
||||
#### /home ne doit pas avoir l'attribut noexec !!!
|
||||
|
||||
### I. Création du compte Unix (User = root)
|
||||
|
||||
Choix de l'utilisateur $REDMINE propriétaire de l'application
|
||||
|
||||
~~~
|
||||
REDMINE='redmine'
|
||||
~~~
|
||||
|
||||
Création de l'utilisateur $REDMINE :
|
||||
|
||||
~~~
|
||||
useradd $REDMINE -d "/home/$REDMINE" -c "Redmine $REDMINE" -s "/bin/bash" -m
|
||||
~~~
|
||||
|
||||
Ajout de l'utilisateur www-data au groupe $REDMINE :
|
||||
|
||||
~~~
|
||||
adduser www-data $REDMINE
|
||||
~~~
|
||||
|
@ -73,6 +84,7 @@ Au choix :
|
|||
### V. Finalisation (User = $REDMINE)
|
||||
|
||||
Se connecter avec l'utilisateur $REDMINE :
|
||||
|
||||
~~~
|
||||
su - $REDMINE
|
||||
~~~
|
||||
|
@ -87,6 +99,7 @@ BRANCHE=3.3-stable
|
|||
~~~
|
||||
|
||||
Ajout des gems locales dans le $PATH :
|
||||
|
||||
~~~
|
||||
cat >> ~/.profile <<EOF
|
||||
if [ -d "\$HOME/.gem/ruby/2.1.0/bin" ] ; then
|
||||
|
@ -94,15 +107,21 @@ if [ -d "\$HOME/.gem/ruby/2.1.0/bin" ] ; then
|
|||
fi
|
||||
EOF
|
||||
~~~
|
||||
|
||||
Clonage du dépôt Git du projet Redmine :
|
||||
|
||||
~~~
|
||||
git clone <https://github.com/redmine/redmine.git> -b $BRANCHE ~/www
|
||||
~~~
|
||||
|
||||
Création des dossiers nécessaires :
|
||||
|
||||
~~~
|
||||
mkdir ~/files
|
||||
~~~
|
||||
|
||||
Copie de la configration de Redmine :
|
||||
|
||||
~~~
|
||||
cat > ~/www/config/configuration.yml <<EOF
|
||||
production:
|
||||
|
@ -117,12 +136,16 @@ production:
|
|||
attachments_storage_path: /home/$USER/files
|
||||
autologin_cookie_secure: true
|
||||
EOF
|
||||
|
||||
~~~
|
||||
Récupération du mot de passe Mysql :
|
||||
|
||||
~~~
|
||||
MYSQLPASS=`grep password ~/.my.cnf|cut -d'=' -f2|tr -d ' '`
|
||||
~~~
|
||||
|
||||
Configuraion de la base de donnée :
|
||||
|
||||
~~~
|
||||
cat > ~/www/config/database.yml <<EOF
|
||||
production:
|
||||
|
@ -134,31 +157,45 @@ production:
|
|||
encoding: utf8
|
||||
EOF
|
||||
~~~
|
||||
|
||||
Correction des droits :
|
||||
|
||||
~~~
|
||||
chmod u=rwX,g=rX,o= ~/www ~/www/public ~/files ~/ -R
|
||||
~~~
|
||||
|
||||
Installation des dépendances Gem avec bundle (cela peut durer plusieurs minutes) :
|
||||
|
||||
~~~
|
||||
bundle install --gemfile=~/www/Gemfile --path=~/.gem
|
||||
|
||||
~~~
|
||||
Puis prise en compte du .profile :
|
||||
|
||||
~~~
|
||||
source .profile
|
||||
~~~
|
||||
|
||||
Génération d'un clé aléatoire utilisé pour encoder les cookies de session :
|
||||
|
||||
~~~
|
||||
rake -qf ~/www/Rakefile generate_secret_token
|
||||
~~~
|
||||
|
||||
Création des schémas de la base de données redmine :
|
||||
|
||||
~~~
|
||||
rake -qf ~/www/Rakefile db:migrate RAILS_ENV=production
|
||||
~~~
|
||||
|
||||
Chargement des données par défaut :
|
||||
|
||||
~~~
|
||||
rake -qf ~/www/Rakefile redmine:load_default_data RAILS_ENV=production REDMINE_LANG=fr
|
||||
~~~
|
||||
|
||||
Migration de la base pour les plugins :
|
||||
|
||||
~~~
|
||||
rake -qf ~/www/Rakefile redmine:plugins:migrate RAILS_ENV=production
|
||||
~~~
|
||||
|
@ -166,18 +203,25 @@ rake -qf ~/www/Rakefile redmine:plugins:migrate RAILS_ENV=production
|
|||
### Lancement de l'application (User = root)
|
||||
|
||||
Démarrer/éteindre l'application :
|
||||
|
||||
~~~
|
||||
systemctl start/stop puma@$REDMINE
|
||||
~~~
|
||||
|
||||
Recharger la configuration après avoir modifier /etc/puma/$REDMINE/ (pas de coupure) :
|
||||
|
||||
~~~
|
||||
systemctl reload puma@$REDMINE
|
||||
~~~
|
||||
|
||||
Redémarrer l'application :
|
||||
|
||||
~~~
|
||||
systemctl restart puma@$REDMINE
|
||||
~~~
|
||||
|
||||
Activer/désactiver l'application au démarrage :
|
||||
|
||||
~~~
|
||||
systemctl enable/disable puma@$REDMINE
|
||||
~~~
|
||||
|
@ -185,13 +229,14 @@ systemctl enable/disable puma@$REDMINE
|
|||
### Taches d'administration
|
||||
|
||||
Lancer un shell ruby dans l'environnement de production :
|
||||
|
||||
~~~
|
||||
su - $REDMINE
|
||||
cd ~/www
|
||||
RAILS_ENV=production bundle exec rails console
|
||||
~~~
|
||||
|
||||
#### Creer un compte admin / mot de passe admin
|
||||
#### Creer un compte admin / mot de passe admin
|
||||
~~~
|
||||
user # User.new :firstname> "Admin", :lastname => "Admin", :mail => "admin@example.com", :mail_notification => "none", :status => 1
|
||||
user.login = 'admin'
|
||||
|
@ -199,4 +244,4 @@ user.hashed_password = "4af53bd5aff3b4b8ac275cfc918244f7e61aa4cb"
|
|||
user.salt = "270d36d363b07abc40245d02348a53a8"
|
||||
user.admin = true
|
||||
user.save
|
||||
~~~
|
||||
~~~
|
||||
|
|
|
@ -50,6 +50,7 @@ Client/manager <---- (SNMP) ---> Agent 2
|
|||
### Configuration de l'agent
|
||||
|
||||
Par défault, snmpd n'écoute que sur 127.0.0.1. Cela peut se changer dans le fichier /etc/default/snmpd :
|
||||
|
||||
~~~
|
||||
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid IP'
|
||||
~~~
|
||||
|
@ -57,6 +58,7 @@ SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid IP'
|
|||
IP peut même être omis pour écouter sur toutes les interfaces.
|
||||
|
||||
Fichier snmpd.conf :
|
||||
|
||||
~~~
|
||||
# read-only de tout sur le reseau local
|
||||
com2sec local 192.168.0.0/16 public
|
||||
|
@ -95,21 +97,25 @@ DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (107510) 0:17:55.10
|
|||
~~~
|
||||
|
||||
Affichage des OID system :
|
||||
|
||||
~~~
|
||||
$ snmptranslate -Tp -IR system
|
||||
~~~
|
||||
|
||||
Lister les interfaces :
|
||||
|
||||
~~~
|
||||
8:~$ snmpwalk -OX -c public -v 1 routeur .1.3.6.1.2.1.2
|
||||
~~~
|
||||
|
||||
Lister les variables system :
|
||||
|
||||
~~~
|
||||
8:~$ snmpwalk -v 1 -c public routeur system
|
||||
~~~
|
||||
|
||||
Lister les disques :
|
||||
|
||||
~~~
|
||||
snmpwalk -v 1 -c public routeur .1.3.6.1.4.1.2021.9
|
||||
~~~
|
||||
|
@ -124,6 +130,7 @@ SNMPv2-SMI::enterprises = .1.3.6.1.4.1
|
|||
|
||||
|
||||
Lister toutes les variables :
|
||||
|
||||
~~~
|
||||
8:~$ snmpwalk -v 1 -c public <IP> .1
|
||||
~~~
|
||||
|
@ -147,6 +154,7 @@ Définitions des seuils :
|
|||
* `-c` : idem, mais pour le _Critical_ ;
|
||||
|
||||
Exemple :
|
||||
|
||||
~~~
|
||||
/usr/lib/nagios/plugins/check_snmp -H san -P 2c -o 1.3.6.1.4.1.1714.1.2.1.11.1 -u "failed hard drive" -w "0:0" -c"0:1"
|
||||
~~~
|
||||
|
|
|
@ -5,16 +5,19 @@
|
|||
## Administration SSH
|
||||
|
||||
Obtenir l'empreinte de la clé publique (RSA) du serveur :
|
||||
|
||||
~~~
|
||||
$ ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
|
||||
~~~
|
||||
|
||||
De même pour la clé DSA :
|
||||
|
||||
~~~
|
||||
$ ssh-keygen -lf /etc/ssh/ssh_host_dsa_key.pub
|
||||
~~~
|
||||
|
||||
Regénérer les clés RSA/DSA du serveur (exemple sous Debian) :
|
||||
|
||||
~~~
|
||||
# mv /etc/ssh/{moduli,*key*} /tmp/ssh/
|
||||
# dpkg-reconfigure openssh-server
|
||||
|
@ -82,6 +85,7 @@ no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa XXXXX co
|
|||
## SFTP Only
|
||||
|
||||
Mettre shell /usr/lib/sftp-server pour l'utilisateur et s'assurer que ce shell est bien présent dans /etc/shells
|
||||
|
||||
~~~
|
||||
# usermod -s /usr/lib/sftp-server userna
|
||||
# echo '/usr/lib/stfp-server' >> /etc/shells
|
||||
|
|
19
HowtoSVN.md
19
HowtoSVN.md
|
@ -5,21 +5,25 @@
|
|||
## Procédure de mise en place d'un dépôt
|
||||
|
||||
On crée le répertoire qui contiendra les dépôts SVN :
|
||||
|
||||
~~~
|
||||
mkdir /home/svn/
|
||||
~~~
|
||||
|
||||
On crée également un groupe _svn_ qui contiendra les utilisateurs qui auront le droits d'accéder au dépôt :
|
||||
|
||||
~~~
|
||||
addgroup -q svn
|
||||
~~~
|
||||
|
||||
On peut ensuite créer un premier dépôt nommé _foo_ :
|
||||
|
||||
~~~
|
||||
svnadmin create /home/svn/foo
|
||||
~~~
|
||||
|
||||
Il est maintenant nécessaire d'adapter les droits :
|
||||
|
||||
~~~
|
||||
chgrp -R svn /home/svn/
|
||||
chmod 750 /home/svn/
|
||||
|
@ -29,11 +33,13 @@ chmod -R g+s /home/svn/foo/db/
|
|||
~~~
|
||||
|
||||
Enfin, on peut ajouter les utilisateurs ayant accès au svn dans le groupe svn :
|
||||
|
||||
~~~
|
||||
adduser -q jdoe svn
|
||||
~~~
|
||||
|
||||
Il est nécessaire que leur umask soit positionné à la valeur 007, on l'indiquant par exemple dans leur ~/.profile.
|
||||
|
||||
~~~
|
||||
echo umask 007 >> ~jdoe/.profile
|
||||
~~~
|
||||
|
@ -44,13 +50,13 @@ echo umask 007 >> ~jdoe/.profile
|
|||
|
||||
~~~
|
||||
[general]
|
||||
anon-access = none
|
||||
anon-access = none
|
||||
auth-access = write
|
||||
password-db = passwd
|
||||
realm = Nom du repo
|
||||
~~~
|
||||
|
||||
Ajouter les utilisateurs et leur mot de passes dans le fichier conf/passwd :
|
||||
Ajouter les utilisateurs et leur mot de passes dans le fichier conf/passwd :
|
||||
~~~
|
||||
|
||||
[users]
|
||||
|
@ -62,6 +68,7 @@ toto = tata
|
|||
## SVN+HTTP
|
||||
|
||||
Installation et activation des modules requis :
|
||||
|
||||
~~~
|
||||
# aptitude install libapache2-svn
|
||||
# a2enmod dav_svn
|
||||
|
@ -81,12 +88,13 @@ Configuration du VHost :
|
|||
</Location>
|
||||
~~~
|
||||
|
||||
Dans le cas de plusieurs dépôts, on vérifiera de bien utiliser la directive "SVNParentPath".
|
||||
Dans le cas de plusieurs dépôts, on vérifiera de bien utiliser la directive "SVNParentPath".
|
||||
Pour un seul dépôt, la directive "SVNPath" peut être utilisée, et dans ce cas doit pointer directement sur le dépôt en question.
|
||||
|
||||
## SVN+HTTP et authentification LDAP
|
||||
|
||||
Même pré-requis que précédemment, avec en plus :
|
||||
|
||||
~~~
|
||||
# a2enmod authnz_ldap
|
||||
~~~
|
||||
|
@ -111,6 +119,7 @@ Et la configuration suivante :
|
|||
## FAQ
|
||||
|
||||
Lorsque l'on obtient un message du type :
|
||||
|
||||
~~~
|
||||
$ svn checkout svn+ssh://SERVEUR/svn/sendsms2mobyt
|
||||
svn: Erreur de base Berkeley pour le système de fichiers '/svn/sendsms2mobyt/db' en ouvrant l'environnement :
|
||||
|
@ -118,7 +127,9 @@ svn: Erreur de base Berkeley pour le système de fichiers '/svn/sendsms2mobyt/db
|
|||
svn: DB_VERSION_MISMATCH: Database environment version mismatch
|
||||
svn: bdb: Program version 4.6 doesn't match environment version 4.4
|
||||
~~~
|
||||
|
||||
... c'est que la version du dépôt est obsolète. Il faut la mettre à jour sur le serveur SVN :
|
||||
|
||||
~~~
|
||||
$ svnadmin recover sendsms2mobyt/
|
||||
Verrou du dépôt acquis.
|
||||
|
@ -131,8 +142,8 @@ La dernière révision du dépôt est 12
|
|||
Si l'on veut commiter en svn+ssh:// avec un login différent du checkout :
|
||||
|
||||
On peut forcer l'utiliser via le $HOME/subversion/config
|
||||
|
||||
~~~
|
||||
[tunnels]
|
||||
ssh = $SVN_SSH ssh -l <user>
|
||||
~~~
|
||||
|
||||
|
|
|
@ -73,16 +73,19 @@ Procédure dispo ici : <https://wiki.samba.org/index.php/Windows7>
|
|||
## Tester la conexion
|
||||
|
||||
Les test vont se faire avec la commande smbclient :
|
||||
|
||||
~~~
|
||||
apt install smbclient
|
||||
~~~
|
||||
|
||||
Lister les partages :
|
||||
|
||||
~~~
|
||||
smbclient -L localhost -U username
|
||||
~~~
|
||||
|
||||
Se connecter a un partage :
|
||||
|
||||
~~~
|
||||
smbclient //localhost/partage -U username
|
||||
~~~
|
||||
|
@ -140,6 +143,7 @@ Si le fichier existe déjà, une copie est fait en _Copy #x of filename_ (grâce
|
|||
Pour plus d'informations sur les options possible : <http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/VFS.html#id2651247>
|
||||
|
||||
Les fichiers conservés ne sont pas limités dans le temps. Pour cela on pourra mettre un cron qui nettoiera le répertoire concerné :
|
||||
|
||||
~~~
|
||||
32 4 * * * find /home/samba/foo/.trash/ -type f -atime +7 -delete
|
||||
~~~
|
||||
|
@ -151,21 +155,26 @@ Bien s'assurer dans ce cas que l'option _recycle:touch_ est active pour que la d
|
|||
Le but ici est de faire en sorte que lors d'un changement de mot de passe avec la commande `passwd`, le changement soit aussi appliqué sur le mot de passe Samba.
|
||||
|
||||
* Installation du module PAM nécessaire :
|
||||
|
||||
~~~
|
||||
# aptitude install libpam-smbpass
|
||||
~~~
|
||||
|
||||
* Ajout du module dans le fichier _/etc/pam.d/common-password_ :
|
||||
|
||||
~~~
|
||||
password required pam_smbpass.so nullok use_authtok try_first_pass
|
||||
|
||||
~~~
|
||||
Il faut aussi modifier dans le même fichier la ligne concernant le module pam_ldap (ou pam_unix si LDAP n'est pas utilisé) pour passer _required_ à _requisite_ (force à se terminer à la première erreur, pour éviter que les 2 mots de passe ne soient désynchronisés) :
|
||||
|
||||
~~~
|
||||
#password required pam_ldap.so use_first_pass
|
||||
password requisite pam_ldap.so use_first_pass
|
||||
~~~
|
||||
|
||||
* Ajout du module dans le fichier _/etc/pam.d/common-auth_ :
|
||||
|
||||
~~~
|
||||
auth optional pam_smbpass.so migrate
|
||||
~~~
|
||||
|
@ -186,6 +195,7 @@ L'utilisateur serra averti par un message Windows comme quoi son mot de passe ex
|
|||
Pour éviter cela, il faut retirer le flag _X_ du champs _sambaAcctFlags_, pour réellement faire expirer le mot de passe.
|
||||
|
||||
Au final, ça donne :
|
||||
|
||||
~~~
|
||||
sambaPwdLastSet: 0
|
||||
sambaPwdMustChange: 0
|
||||
|
@ -203,6 +213,7 @@ Deux possibilités :
|
|||
- sortir la machine du domaine, effacer l'entrée LDAP associée à la machine, et rentrer à nouveau la machine dans le domaine
|
||||
|
||||
Note : si besoin (mais c'est moins sécurisé...), il est possible de désactiver ce renouvellement de mot de passe machine via une clé de registre :
|
||||
|
||||
~~~
|
||||
Client-Registry: [HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters] "DisablePasswordChange"=dword:00000001
|
||||
~~~
|
||||
|
|
|
@ -12,9 +12,9 @@ Il n'est plus maintenu depuis 2006 mais vu sa simplicité, son utilisation peut
|
|||
|
||||
~~~
|
||||
$ wget <http://download.pureftpd.org/pub/sharedance/sharedance-0.6.tar.gz>
|
||||
$ tar xvf sharedance-0.6.tar.gz
|
||||
$ tar xvf sharedance-0.6.tar.gz
|
||||
$ cd sharedance-0.6
|
||||
$ ./configure
|
||||
$ ./configure
|
||||
$ make
|
||||
# make install
|
||||
~~~
|
||||
|
@ -26,6 +26,7 @@ Il peut être lancé ainsi :
|
|||
~~~
|
||||
|
||||
Son utilisation avec PHP se fait ainsi dans le fichier _php.ini_ :
|
||||
|
||||
~~~
|
||||
auto_prepend_file = /usr/local/etc/sharedance.php
|
||||
;session.save_handler = user
|
||||
|
@ -34,7 +35,7 @@ auto_prepend_file = /usr/local/etc/sharedance.php
|
|||
|
||||
avec un fichier _sharedance.php_ du type :
|
||||
|
||||
~~~
|
||||
~~~{.php}
|
||||
<?php
|
||||
|
||||
define('SESSION_HANDLER_HOST', '127.0.0.1');
|
||||
|
@ -209,4 +210,4 @@ session_set_save_handler('session_handler_open', 'session_handler_close',
|
|||
'session_handler_delete', 'session_handler_gc');
|
||||
|
||||
?>
|
||||
~~~
|
||||
~~~
|
||||
|
|
|
@ -6,6 +6,7 @@
|
|||
|
||||
~~~
|
||||
# aptitude install smokeping
|
||||
|
||||
~~~
|
||||
Normalement il est aussi installé _speedy-cgi-perl_ pour la gestion des cgi par apache.
|
||||
À partir de maintenant smokeping est accessible sur <http://localhost/cgi-bin/smokeping.cgi>
|
||||
|
@ -44,6 +45,7 @@ comment = host not responding
|
|||
Permet de détecter quand un hôte ne ping plus du tout.
|
||||
|
||||
Vous pouvez ensuite dire à Smokeping d'envoyer une alerte en ajoutant l'alerte dans la liste des _Targets_ voulus.
|
||||
|
||||
~~~
|
||||
# vim /etc/smokeping/config.d/Targets
|
||||
+ EvolixLAN
|
||||
|
|
|
@ -19,6 +19,7 @@ La configuration se fait dans le fichier _/etc/ipsec.conf_. Les clés privées o
|
|||
### Example de configuration
|
||||
|
||||
Fichier _/etc/ipsec.conf_ :
|
||||
|
||||
~~~
|
||||
config setup
|
||||
interfaces=%defaultroute
|
||||
|
@ -40,11 +41,13 @@ conn myvpn
|
|||
~~~
|
||||
|
||||
Fichier _/etc/ipsec.secrets_ :
|
||||
|
||||
~~~
|
||||
192.0.2.18 198.51.100.56 : PSK "mypassphrase"
|
||||
~~~
|
||||
|
||||
Pour pouvoir joindre le réseau privé distant, il faut ajouter une route comme suit :
|
||||
|
||||
~~~
|
||||
route add -net 10.0.1.0/24 gw 10.0.0.1
|
||||
~~~
|
||||
|
@ -68,6 +71,7 @@ ou
|
|||
### Gérer les démons pluto et charon
|
||||
|
||||
En cas de changement dans la conf :
|
||||
|
||||
~~~
|
||||
ipsec start|stop|restart|reload
|
||||
~~~
|
||||
|
@ -75,6 +79,7 @@ ipsec start|stop|restart|reload
|
|||
### Gérer les VPN
|
||||
|
||||
En cas de perte de connexion/problème de lifetime...
|
||||
|
||||
~~~
|
||||
# ipsec down|up <connection name>
|
||||
~~~
|
|
@ -10,6 +10,7 @@ La configuration de sudo se passe dans le fichier _/etc/sudoers_ qu'il est conse
|
|||
### Exemples d'autorisations particulières
|
||||
|
||||
Autoriser l'édition d'un fichier de manière sécurisée et autoriser l'accès à un script d'init :
|
||||
|
||||
~~~
|
||||
jdoe ALL = (ALL) sudoedit /path/file
|
||||
alice ALL = (root) /etc/init.d/apache2
|
||||
|
|
|
@ -49,6 +49,7 @@ WebappX/WEB-INF/lib/ : classes spécifiques à la webapp WebappX
|
|||
~~~
|
||||
|
||||
Pour désactiver le déploiement automatique (à chaud), on modifie le fichier /etc/tomcat6/server.xml :
|
||||
|
||||
~~~
|
||||
<Host name="localhost" ... autoDeploy="false" ... />
|
||||
~~~
|
||||
|
@ -249,9 +250,10 @@ update-alternatives --set wsimport /usr/local/opt/jdk1.7.0_45/bin/wsimport
|
|||
### Activation du « access_log » de Tomcat
|
||||
|
||||
Pour loguer tous les accès, il suffit de décommenter cette partie dans le server.xml :
|
||||
~~~
|
||||
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
|
||||
prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false"/>
|
||||
|
||||
~~~{.xml}
|
||||
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
|
||||
prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false"/>
|
||||
~~~
|
||||
|
||||
### Reverse proxy avec Apache
|
||||
|
@ -262,7 +264,7 @@ Le but est de se passer du mod_jk est de faire un reverse proxy.
|
|||
|
||||
Activez le mod proxy et proxy_<http,> puis modifier la configuration du module `mods-enabled/proxy.conf`.
|
||||
|
||||
~~~
|
||||
~~~{.apache}
|
||||
<IfModule mod_proxy.c>
|
||||
|
||||
ProxyRequests Off
|
||||
|
@ -280,9 +282,9 @@ ProxyVia On
|
|||
</IfModule>
|
||||
~~~
|
||||
|
||||
Puis dans le vhost concerné :
|
||||
Puis dans le vhost concerné :
|
||||
|
||||
~~~
|
||||
~~~{.apache}
|
||||
<VirtualHost *:80>
|
||||
|
||||
# FQDN principal
|
||||
|
@ -295,7 +297,7 @@ Puis dans le vhost concerné :
|
|||
Order allow,deny
|
||||
Allow from all
|
||||
</Directory>
|
||||
|
||||
|
||||
</VirtualHost>
|
||||
~~~
|
||||
|
||||
|
@ -306,11 +308,13 @@ Note : attention à bien mettre le '/' final sous peine de s'arracher les cheveu
|
|||
le mod-jk d'Apache permet de gérer la communication entre le serveur web Apache et le conteneur de servlets Tomcat.
|
||||
|
||||
Pour l'installer :
|
||||
|
||||
~~~
|
||||
# aptitude install libapache2-mod-jk
|
||||
~~~
|
||||
|
||||
Éditez le fichier _/etc/libapache2-mod-jk/workers.properties_ :
|
||||
|
||||
~~~
|
||||
# On utilise tomcat en version 6
|
||||
workers.tomcat_home=/usr/share/tomcat6
|
||||
|
@ -328,6 +332,7 @@ worker.app1_worker.type=ajp13
|
|||
~~~
|
||||
|
||||
Ensuite, il faut créer le fichier de configuration Apache pour mod_jk, dans _/etc/apache2/conf.d/_ :
|
||||
|
||||
~~~
|
||||
JkWorkersFile /etc/libapache2-mod-jk/workers.properties
|
||||
JkLogFile /var/log/apache2/mod_jk.log
|
||||
|
@ -337,7 +342,8 @@ JkRequestLogFormat "%w %V %T
|
|||
~~~
|
||||
|
||||
Pour chaque application java, on crée un vhost Apache, en prenant le modèle suivant :
|
||||
~~~
|
||||
|
||||
~~~{.apache}
|
||||
<VirtualHost *:80>
|
||||
ServerName app1.evolix.net
|
||||
ServerAlias www.app1.evolix.net
|
||||
|
@ -348,11 +354,13 @@ Pour chaque application java, on crée un vhost Apache, en prenant le modèle su
|
|||
~~~
|
||||
|
||||
Enfin, on s'assure que le tomcat écoute bien sur le port donné dans la configuration du worker (8009 dans l'exemple). Le fichier _/etc/tomcat6/server.xml_ doit contenir la ligne :
|
||||
~~~
|
||||
|
||||
~~~{.xml}
|
||||
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
|
||||
~~~
|
||||
|
||||
Ne pas oublier de charger le module mod_jk et d'activer le nouveau vhost :
|
||||
|
||||
~~~
|
||||
# a2enmod jk
|
||||
# a2ensite app1
|
||||
|
@ -363,11 +371,13 @@ Ne pas oublier de charger le module mod_jk et d'activer le nouveau vhost :
|
|||
Une des méthodes possibles pour le déployment d'applications java est de le faire via une interface web, le manager Tomcat.
|
||||
|
||||
Installation :
|
||||
|
||||
~~~
|
||||
aptitude install tomcat6-admin
|
||||
# aptitude install tomcat6-admin
|
||||
~~~
|
||||
|
||||
Il faut ensuite ajouter un utilisateur au role _manager_, dans le fichier _/etc/tomcat6/tomcat-users.xml_ (équivalent d'un fichier htpasswd d'Apache) :
|
||||
|
||||
~~~
|
||||
<tomcat-users>
|
||||
[...]
|
||||
|
@ -383,6 +393,7 @@ Une fois Tomcat redémarré, l'accès au manager ce fait sur l'URI : <http://exa
|
|||
Activer la compression gzip de certains types de fichiers :
|
||||
|
||||
Dans le fichier _/etc/tomcat6/server.xml_, rajouter ceci dans le connecteur HTTP :
|
||||
|
||||
~~~
|
||||
compression="on" compressionMinSize="2048" compressableMimeType="text/html,text/xml,text/plain,text/javascript,application/javascript"
|
||||
~~~
|
||||
|
@ -399,7 +410,7 @@ Tomcat n'écoute pas en IPv4, pourquoi ? Comment le corriger ?
|
|||
|
||||
Les versions récentes de Java préfèrent l'IPv6 si elle est présente. Le problème c'est que dans ce cas, il peut arriver que tomcat n'écoute pas en IPv4.
|
||||
Il faut alors modifier les propriétés par défaut en ajoutant ceci aux JAVA_OPTS :
|
||||
|
||||
~~~
|
||||
-Djava.net.preferIPv4Stack=true
|
||||
~~~
|
||||
|
||||
|
|
|
@ -7,6 +7,7 @@ Unicorn est un serveur HTTP spécifiquement fait pour des application RoR. Il se
|
|||
### Installation
|
||||
|
||||
Unicorn se présente comme une gem qui peut être installé classiquement :
|
||||
|
||||
~~~
|
||||
# gem install unicorn
|
||||
~~~
|
||||
|
@ -14,7 +15,8 @@ Unicorn se présente comme une gem qui peut être installé classiquement :
|
|||
### Script d'init Debian
|
||||
|
||||
Voici un script d'init Debian permettant de lancer plusieurs instance de Unicorn dans /home :
|
||||
~~~
|
||||
|
||||
~~~{.bash}
|
||||
#!/bin/sh
|
||||
|
||||
### BEGIN INIT INFO
|
||||
|
@ -24,7 +26,7 @@ Voici un script d'init Debian permettant de lancer plusieurs instance de Unicorn
|
|||
# Default-Start: 2 3 4 5
|
||||
# Default-Stop: 0 1 6
|
||||
### END INIT INFO
|
||||
|
||||
|
||||
set -e
|
||||
. /lib/lsb/init-functions
|
||||
|
||||
|
@ -109,4 +111,4 @@ case "$1" in
|
|||
esac
|
||||
~~~
|
||||
|
||||
Puis mettre la liste des instances à lancer dans le fichier _/etc/default/unicorn_.
|
||||
Puis mettre la liste des instances à lancer dans le fichier _/etc/default/unicorn_.
|
||||
|
|
|
@ -7,6 +7,7 @@ Utiliser le demon vrrp [uvrrpd](https://forge.evolix.org/projects/uvrrpd)
|
|||
# Paquet debian wheezy vrrpd
|
||||
|
||||
Utiliser le paquet evolix vrrpd wheezy avec différents patches ainsi qu'un script permettant d'utiliser les *macvlan* :
|
||||
|
||||
~~~
|
||||
- debian/patches/010-vrrpd-1.0_to_1.0-1exp1
|
||||
- debian/patches/120-orig_prio.patch
|
||||
|
@ -54,6 +55,7 @@ Dans l'état master, l'interface vrrp_${vrid}_${interface} est crée avec la VIP
|
|||
## Sysctls
|
||||
|
||||
Voir /usr/share/doc/vrrpd/sysctl.vrrpd
|
||||
|
||||
~~~
|
||||
net.ipv4.conf.default.rp_filter=0
|
||||
net.ipv4.conf.all.rp_filter=0
|
||||
|
|
|
@ -10,33 +10,38 @@ Vagrant est un logiciel qui permet de configurer des environnements de développ
|
|||
|
||||
Des paquets Debian officiels sont disponibles, mais l'équipe de Hashicorp maintient également un paquet plus récent (sans répository) : <https://www.vagrantup.com/downloads.html>
|
||||
|
||||
## Providers
|
||||
## Providers
|
||||
|
||||
Vagrant permet de lancer et configurer des environnements basés sur VirtualBox, VMware, Docker, Amazon EC2 et plusieurs autres.
|
||||
|
||||
## Commandes de base
|
||||
|
||||
1. Lancer l'environnement:
|
||||
|
||||
~~~
|
||||
vagrant up
|
||||
~~~
|
||||
|
||||
2. Provisionner l'environnement:
|
||||
|
||||
~~~
|
||||
vagrant provision
|
||||
~~~
|
||||
|
||||
3. Stopper l'exécution de l'environnement:
|
||||
|
||||
~~~
|
||||
vagrant halt
|
||||
~~~
|
||||
|
||||
4. Supprimer l'environnement:
|
||||
|
||||
~~~
|
||||
vagrant destroy
|
||||
~~~
|
||||
|
||||
5. Accéder à la machine virtuelle par SSH
|
||||
|
||||
~~~
|
||||
vagrant ssh
|
||||
~~~
|
||||
|
@ -48,7 +53,8 @@ Le Vagrantfile un fichier en Ruby qui décrit le type de machine à démarrer, l
|
|||
Ce fichier est unique à un projet et doit être situé à la racine de ce dernier.
|
||||
|
||||
Exemple:
|
||||
~~~
|
||||
|
||||
~~~{.ruby}
|
||||
# -*- mode: ruby -*-
|
||||
# vi: set ft=ruby :
|
||||
|
||||
|
@ -79,7 +85,7 @@ Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
|
|||
ansible.raw_arguments = ["-b"]
|
||||
end
|
||||
end
|
||||
|
||||
|
||||
#Configuration permettant de distribuer l'image dans le Vagrant Atlas
|
||||
config.push.define "atlas" do |push|
|
||||
push.app = "evolix/evolinux"
|
||||
|
@ -87,4 +93,4 @@ Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
|
|||
end
|
||||
|
||||
end
|
||||
~~~
|
||||
~~~
|
||||
|
|
|
@ -13,16 +13,18 @@ Pour l'installer sans serveur X, sur un serveur par exemple, il faut utiliser le
|
|||
Ce paquet est fournit avec des librairies statiques et ne nécessite pas le lancement d'un serveur X.
|
||||
|
||||
Télécharger le paquet sur <http://wkhtmltopdf.org/downloads.html,> puis :
|
||||
|
||||
~~~
|
||||
dpkg -i paquet.deb
|
||||
~~~
|
||||
|
||||
Résoudre les dépendances avec aptitude ou apt puis installer le paquet "libicu48". (aptitude ne l'installe pas par les dépendances du .deb)
|
||||
|
||||
## Pixelization
|
||||
|
||||
Si rendu devient pixelizé (en général sur la font par défaut), remplir le fichier de conf "no-bitmaps" correspondant à celui pointé par "/etc/fonts/conf.avail/70-no-bitmaps.conf".
|
||||
|
||||
~~~
|
||||
~~~{.xml}
|
||||
<?xml version="1.0"?>
|
||||
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
|
||||
<fontconfig>
|
||||
|
|
|
@ -40,9 +40,11 @@ Attention en wordpress 4.3, la mise à jour via ssh est cassée, il faut appliqu
|
|||
# Mise à jour Wordpress [plugins] depuis l'interface web (éviter)
|
||||
|
||||
Revoir les droits du groupe pour permettre l'écriture ($HOME/www = où le wp est installé) :
|
||||
|
||||
~~~
|
||||
$ chmod g+w $HOME/www/ $HOME/www/wp-includes/version.php
|
||||
$ chmod g+w -R $HOME/www/wp-admin/includes/ $HOME/www/wp-content/ [$HOME/www/wp-content/upgrade/ $HOME/www/wp-content/languages/]
|
||||
|
||||
~~~
|
||||
Si vous avez des retours de type : 'Operation not permitted', il y a de bonne chance que le propriétaire du fichier soit déjà l'utilisateur utilisé par l'instance du serveur web (et donc les droits sont déjà suffisant).
|
||||
|
||||
|
@ -51,6 +53,7 @@ Si vous avez des retours de type : 'Operation not permitted', il y a de bonne ch
|
|||
Wordpress surcharge l'umask définie par Apache/PHP et écrit par défaut les fichiers et dossiers en 750.
|
||||
|
||||
Il faut rajouter ces 2 lignes dans wp-config.php pour avoir des droits corrects :
|
||||
|
||||
~~~
|
||||
define( 'FS_CHMOD_DIR', ( 0770 & ~ umask() ) );
|
||||
define( 'FS_CHMOD_FILE', ( 0660 & ~ umask() ) );
|
||||
|
@ -61,6 +64,7 @@ define( 'FS_CHMOD_FILE', ( 0660 & ~ umask() ) );
|
|||
Sur les Wordpress pas à jour, l'API xmlrpc.php est sensible à une attaque par rebond, un attaquant réalise plein de requêtes sur xmlrpc.php et votre serveur fait des requêtes vers la/les cibles de l'attaquant.
|
||||
|
||||
S'il ne vous est pas possible de mettre à jour Wordpress, une solution est de bloquer les requêtes vers xmlrpc.php dans Apache :
|
||||
|
||||
~~~
|
||||
<Files "xmlrpc.php">
|
||||
Deny from all
|
||||
|
@ -74,6 +78,7 @@ Deny from all
|
|||
## core
|
||||
|
||||
Vérifier que le répertoire en question correspond bien à un wordpress :
|
||||
|
||||
~~~
|
||||
php wp-cli.phar core is-installed --path=$HOME/www
|
||||
~~~
|
||||
|
@ -81,11 +86,14 @@ php wp-cli.phar core is-installed --path=$HOME/www
|
|||
### Installation
|
||||
|
||||
Configuration des différentes directives à compléter (pour la base de donnée) :
|
||||
|
||||
~~~
|
||||
php wp-cli.phar core config --dbname=nombase --dbuser=nomutilisateur --dbpass=motdepasse \
|
||||
--dbhost=hostnamedb --path=$HOME/www
|
||||
|
||||
~~~
|
||||
Procéder à l'installation :
|
||||
|
||||
~~~
|
||||
php wp-cli.phar core install --url="ServerName" --title="TITRE_WP" --admin_user="admin" --admin_password="motdepasseadmin" \
|
||||
--admin_email="emailadmin" --skip-email --path="$HOME/www"
|
||||
|
@ -94,16 +102,19 @@ php wp-cli.phar core install --url="ServerName" --title="TITRE_WP" --admin_user=
|
|||
### Mise à jour
|
||||
|
||||
Se placer dans le répertoire où est installé wp :
|
||||
|
||||
~~~
|
||||
$ cd $HOME/www
|
||||
~~~
|
||||
|
||||
Forcer le téléchargement de la dernière version (US) - non recommandé:
|
||||
|
||||
~~~
|
||||
$ php $HOME/wp-cli/wp-cli.phar core download --force
|
||||
~~~
|
||||
|
||||
Vérifier si maj disponible :
|
||||
|
||||
~~~
|
||||
$ php $HOME/wp-cli/wp-cli.phar core check-update
|
||||
+---------+-------------+-------------------------------------------------------------+
|
||||
|
@ -114,6 +125,7 @@ $ php $HOME/wp-cli/wp-cli.phar core check-update
|
|||
~~~
|
||||
|
||||
Mettre à jour wordpress et la bd
|
||||
|
||||
~~~
|
||||
$ php $HOME/wp-cli/wp-cli.phar core update
|
||||
Updating to version 4.6.1 (en_US)...
|
||||
|
@ -129,6 +141,7 @@ Success: WordPress database upgraded successfully from db version 36686 to 37965
|
|||
### Utilisateurs
|
||||
|
||||
Créer un utilisateur admin :
|
||||
|
||||
~~~
|
||||
$ php $HOME/wp-cli/wp-cli.phar user create admintest john@example.com --role=administrator
|
||||
Success: Created user 3.
|
||||
|
@ -136,6 +149,7 @@ Password: XXXXXXX
|
|||
~~~
|
||||
|
||||
Si temporaire, ne pas oublier de le supprimer :
|
||||
|
||||
~~~
|
||||
$ php $HOME/wp-cli/wp-cli.phar user list
|
||||
+----+------------+---------------+----------------------+----------------------+---------------+
|
||||
|
|
|
@ -124,6 +124,7 @@ S'attacher à un terminal :
|
|||
~~~
|
||||
|
||||
Sortir :
|
||||
|
||||
~~~
|
||||
Ctrl+AltGr+]
|
||||
~~~
|
||||
|
|
|
@ -27,6 +27,7 @@ Prérequis :
|
|||
|
||||
* Avoir au moins 2 Go de RAM.
|
||||
* Avoir un _/etc/hosts_ propre, contenant par exemple (avec zimbra.example.com résolvant vraiment vers 192.0.32.10) :
|
||||
|
||||
~~~
|
||||
127.0.0.1 localhost.localdomain localhost
|
||||
192.0.32.10 zimbra.example.com zimbra
|
||||
|
|
|
@ -15,6 +15,7 @@ apt install nfdump
|
|||
Il faut au préalable avoir configuré l'export des flows sur vos routeurs et avoir un collecteur de flow en place.
|
||||
|
||||
Un collecteur (nfcapd) est fourni avec nfdump. On peut le faire écouter de la façon suivante :
|
||||
|
||||
~~~
|
||||
nfcapd -w -D -p 9996 -B 200000 -S 1 -z -I routeur -l /opt/nflow/routeur
|
||||
~~~
|
||||
|
@ -23,22 +24,26 @@ nfcapd -w -D -p 9996 -B 200000 -S 1 -z -I routeur -l /opt/nflow/routeur
|
|||
## Analyser les flows
|
||||
|
||||
Lister toutes les connexions vers le port 80 :
|
||||
|
||||
~~~
|
||||
nfdump -M /opt/nflow/routeur -T -R 2016/09/07/nfcapd.201609070315:2016/09/07/nfcapd.201609070320 -o extended 'proto tcp and ( src port > 1024 and dst port 80 )'
|
||||
~~~
|
||||
|
||||
|
||||
Lister toutes les connexions vers le port 80 de l'IP 1.2.3.4 :
|
||||
|
||||
~~~
|
||||
nfdump -M /opt/nflow/routeur -T -R 2016/09/07/nfcapd.201609070315:2016/09/07/nfcapd.201609070320 -o extended 'proto tcp and host 1.2.3.4 and ( src port > 1024 and dst port 80 )'
|
||||
~~~
|
||||
|
||||
Lister toutes les connexions vers le port 80 de l'IP 1.2.3.4 et aggréger sur l'IP source :
|
||||
|
||||
~~~
|
||||
nfdump -M /opt/nflow/routeur -T -R 2016/09/07/nfcapd.201609070315:2016/09/07/nfcapd.201609070320 'proto tcp and host 1.2.3.4 and ( src port > 1024 and dst port 80 )' -A srcip
|
||||
~~~
|
||||
|
||||
Lister toutes les connexions vers le port 80 de l'IP 1.2.3.4 et faire une somme :
|
||||
|
||||
~~~
|
||||
nfdump -M /opt/nflow/routeur -T -R 2016/09/07/nfcapd.201609070315:2016/09/07/nfcapd.201609070320 'proto tcp and host 1.2.3.4 and ( src port > 1024 and dst port 80 )' -s srcip
|
||||
~~~
|
|
@ -71,6 +71,7 @@ megacli -PDOffline -PhysDrv \[E:S\] -a0
|
|||
## Passer un disque en missing
|
||||
|
||||
Ça le sort du RAID.
|
||||
|
||||
~~~
|
||||
megacli -PDMarkMissing -PhysDrv \[E:S\] -a0
|
||||
~~~
|
||||
|
@ -125,6 +126,7 @@ Vérifier que les disques ne sont pas déjà dans un volume RAID :
|
|||
~~~
|
||||
|
||||
Créer le volume :
|
||||
|
||||
~~~
|
||||
# megacli -CfgLdAdd -r1[E:S1,E:S2] -a0
|
||||
~~~
|
||||
|
|
|
@ -3,6 +3,7 @@
|
|||
# RAID LSI-SAS1068E
|
||||
|
||||
Cartes compatibles :
|
||||
|
||||
~~~
|
||||
04:01.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 08)
|
||||
~~~
|
||||
|
@ -19,6 +20,7 @@ Charger le module noyau :
|
|||
|
||||
~~~
|
||||
modprobe mptctl
|
||||
|
||||
~~~
|
||||
Ajouter aussi cette ligne dans le fichier `/etc/rc.local`, de façon à le charger à chaque démarrage de la machine.
|
||||
(Note de Romain : pas sûr que ce soit nécessaire.)
|
||||
|
|
1
LSI.md
1
LSI.md
|
@ -3,6 +3,7 @@
|
|||
Télécharger le binaire 32bits suivant (on prendra soin d'installer les ia32-libs avant) : [<http://www.tomasek.cz/software/dellstuff/lsiutil-1.38.tar.bz2>]
|
||||
|
||||
Lancer le binaire et suivez ce qui suit :
|
||||
|
||||
~~~
|
||||
machine:~> ./lsiutil
|
||||
|
||||
|
|
29
NetApp.md
29
NetApp.md
|
@ -82,12 +82,14 @@ Une solution est d'avoir un montage en écriture NFS du vol0...
|
|||
<http://datadisk.co.uk/html_docs/netapp/netapp_network.htm>
|
||||
|
||||
* Lister les interfaces réseau / routes :
|
||||
|
||||
~~~
|
||||
netapp> ifconfig -a
|
||||
netapp> route -s
|
||||
~~~
|
||||
|
||||
* Configuration IP "temporaire" :
|
||||
|
||||
~~~
|
||||
netapp> ifconfig bond0 192.0.2.3 netmask 255.255.255.128
|
||||
netapp> route add default 192.0.2.127 1
|
||||
|
@ -124,6 +126,7 @@ netapp> rdfile /etc/hosts
|
|||
~~~
|
||||
|
||||
* Configuration DNS
|
||||
|
||||
~~~
|
||||
netapp> rdfile /etc/resolv.conf
|
||||
netapp> options dns.enable on
|
||||
|
@ -133,6 +136,7 @@ netapp> dns info
|
|||
~~~
|
||||
|
||||
* Stats réseau :
|
||||
|
||||
~~~
|
||||
netapp> ifstat bond0
|
||||
|
||||
|
@ -147,6 +151,7 @@ TRANSMIT
|
|||
~~~
|
||||
|
||||
* Création d'un bonding (aggrégat d'interface réseau) simple :
|
||||
|
||||
~~~
|
||||
netapp> ifgrp create bond0 single e0a e0c
|
||||
netapp> ifconfig bond0 192.0.2.3 netmask 255.255.255.128 mtusize 1500
|
||||
|
@ -155,6 +160,7 @@ netapp> ifconfig bond0 192.0.2.3 netmask 255.255.255.128 mtusize 1500
|
|||
Note : à positionner dans le fichier `/etc/rc`.
|
||||
|
||||
* Création d'un bonding LACP :
|
||||
|
||||
~~~
|
||||
netapp> ifgrp create bond0 lacp e0a e0c
|
||||
~~~
|
||||
|
@ -169,6 +175,7 @@ netapp> ifgrp favor bond-foo
|
|||
~~~
|
||||
|
||||
* Diagnostics divers :
|
||||
|
||||
~~~
|
||||
netapp> ping <IP>
|
||||
netapp> traceroute <IP>
|
||||
|
@ -180,30 +187,35 @@ netapp> arp -a
|
|||
## Administration système
|
||||
|
||||
* Version de l'OS (Data ONTAP) :
|
||||
|
||||
~~~
|
||||
netapp> version
|
||||
NetApp Release 8.1 7-Mode: Thu Mar 29 13:56:17 PDT 2012
|
||||
~~~
|
||||
|
||||
* Uptime:
|
||||
|
||||
~~~
|
||||
netapp> uptime
|
||||
9:01pm up 5:09 88 NFS ops, 53 CIFS ops, 0 HTTP ops, 0 FCP ops, 0 iSCSI ops
|
||||
~~~
|
||||
|
||||
* Aide :
|
||||
|
||||
~~~
|
||||
netapp> help
|
||||
netapp> <COMMAND> help
|
||||
~~~
|
||||
|
||||
* Date :
|
||||
|
||||
~~~
|
||||
netapp> date
|
||||
Mon Sep 3 20:53:39 CEST 2012
|
||||
~~~
|
||||
|
||||
* Activer/changer le(s) serveur(s) NTP :
|
||||
|
||||
~~~
|
||||
netapp> options timed.enable on
|
||||
netapp> options timed.servers 192.0.2.1
|
||||
|
@ -211,22 +223,26 @@ netapp> options timed.servers 192.0.2.1
|
|||
|
||||
* Accès à l'admin HTTP FilerView via : <http://filer/na_admin/>
|
||||
* Afficher le contenu d'un fichier (équivalent de `cat`) :
|
||||
|
||||
~~~
|
||||
netapp> rdfile <filename>
|
||||
~~~
|
||||
|
||||
* Écrire un fichier (ATTENTION CELA EFFACE LE CONTENU EXISTANT) :
|
||||
|
||||
~~~
|
||||
netapp> wrfile <filename>
|
||||
~~~
|
||||
|
||||
* Lister le contenu d'un répertoire (attention, plus compliqué !) :
|
||||
|
||||
~~~
|
||||
netapp> priv set advanced
|
||||
netapp> ls <directory>
|
||||
~~~
|
||||
|
||||
* Paramètres pour l'autosupport (envoi d'emails hebdomadaires récpitulatifs) :
|
||||
|
||||
~~~
|
||||
netapp> options autosupport.enable on
|
||||
netapp> options autosupport.cifs.verbose on
|
||||
|
@ -236,11 +252,13 @@ netapp> options autosupport.support.transport smtp
|
|||
~~~
|
||||
|
||||
* Forcer l'envoi d'un email récapitulatif :
|
||||
|
||||
~~~
|
||||
netapp> options autosupport.doit test
|
||||
~~~
|
||||
|
||||
* Statistiques diverses :
|
||||
|
||||
~~~
|
||||
netapp> stats show
|
||||
netapp> cifs stat
|
||||
|
@ -250,6 +268,7 @@ netapp> nfs stat
|
|||
## Administration des storages
|
||||
|
||||
* Lister la taille des volumes existants (dont snapshot) :
|
||||
|
||||
~~~
|
||||
netapp> df -h
|
||||
Filesystem total used avail capacity Mounted on
|
||||
|
@ -260,6 +279,7 @@ Filesystem total used avail capacity Mounted on
|
|||
~~~
|
||||
|
||||
* Lister les options des volumes existants :
|
||||
|
||||
~~~
|
||||
netapp> vol status
|
||||
Volume State Status Options
|
||||
|
@ -270,6 +290,7 @@ netapp> vol status
|
|||
~~~
|
||||
|
||||
* Lister les QTREE existants :
|
||||
|
||||
~~~
|
||||
netapp> qtree status
|
||||
Volume Tree Style Oplocks Status
|
||||
|
@ -283,6 +304,7 @@ foo users unix enabled normal
|
|||
~~~
|
||||
|
||||
* Lister les exports NFS :
|
||||
|
||||
~~~
|
||||
netapp> exportfs
|
||||
/vol/foo/bar -sec=sys,rw,root=192.0.2.1:192.0.2.2,nosuid
|
||||
|
@ -290,6 +312,7 @@ netapp> exportfs
|
|||
~~~
|
||||
|
||||
* Stats NFS :
|
||||
|
||||
~~~
|
||||
netapp> nfsstat
|
||||
~~~
|
||||
|
@ -297,11 +320,13 @@ netapp> nfsstat
|
|||
* Modifier les exports NFS :
|
||||
|
||||
Éditer le fichier `/etc/exports` puis :
|
||||
|
||||
~~~
|
||||
netapp> exportfs -a
|
||||
~~~
|
||||
|
||||
* Lister les exports CIFS :
|
||||
|
||||
~~~
|
||||
netapp> cifs shares
|
||||
Name Mount Point Description
|
||||
|
@ -314,12 +339,14 @@ C$ / Remote Administration
|
|||
~~~
|
||||
|
||||
* Lister les sessions CIFS ouvertes :
|
||||
|
||||
~~~
|
||||
netapp> cifs sessions
|
||||
[...]
|
||||
~~~
|
||||
|
||||
* Créer un partage CIFS :
|
||||
|
||||
~~~
|
||||
netapp> cifs shares -add test /vol/foo/bar
|
||||
netapp> cifs access -delete test everyone
|
||||
|
@ -331,6 +358,7 @@ netapp> cifs access test -g DOMAIN\wingroup "Full Control"
|
|||
~~~
|
||||
|
||||
* Lister les snapshots d'un volume :
|
||||
|
||||
~~~
|
||||
netapp> snap list vol0
|
||||
Volume vol0
|
||||
|
@ -486,6 +514,7 @@ netapp> fsecurity show -v vol <path>
|
|||
## FAQ
|
||||
|
||||
J'essaye de me connecter en SSH au NetApp et j'obtiens :
|
||||
|
||||
~~~
|
||||
debug1: Authentication succeeded (password)
|
||||
Connection to 1.2.3.4 closed.
|
||||
|
|
|
@ -18,6 +18,7 @@ Voici la procédure à appliquer pour l'installation des outils :
|
|||
"Account" > "Identifiants de sécurité" > Onglet "Certificats X.509" > "Créer un nouveau certificat" et télécharger le certificat et la clé publique
|
||||
* Placer le certificat et la clé privée à la racine du répertoire de l'API, une fois celui-ci décompressé
|
||||
* Indiquer ensuite diverses informations dans les variables d'environnement, qu'on pourra placer dans son _.profile_ :
|
||||
|
||||
~~~
|
||||
export EC2_HOME=~/ec2
|
||||
export EC2_PRIVATE_KEY=pk-YOURKEYNAME.pem
|
||||
|
@ -28,8 +29,10 @@ export EC2_URL=<https://ec2.eu-west-1.amazonaws.com>
|
|||
~~~
|
||||
|
||||
* On peut tester que l'installation de l'API est correcte en listant par exemple les AMI disponible :
|
||||
|
||||
~~~
|
||||
bin/ec2-describe-images -a
|
||||
|
||||
~~~
|
||||
NOTE : pour exécuter les commandes EC2, il faut se trouver à la racine du répertoire d'installation.
|
||||
|
||||
|
@ -38,17 +41,20 @@ NOTE : pour exécuter les commandes EC2, il faut se trouver à la racine du rép
|
|||
Voici la procédure à suivre :
|
||||
|
||||
* Démarrer une instance de l'AMI :
|
||||
|
||||
~~~
|
||||
ec2-run-instances --instance-type m1.large --kernel aki-9800e5f1 ami-xxxxxx
|
||||
~~~
|
||||
|
||||
* Créer un nouveau volume, de même taille que l'AMI, puis l'attacher à l'instance :
|
||||
|
||||
~~~
|
||||
ec2-create-volume --size 10
|
||||
ec2-attach-volume vol-xxxxxx --instance i-xxxxxx --device /dev/sdf
|
||||
~~~
|
||||
|
||||
* Depuis l'instance, copier l'intégralité de l'AMI sur le volume :
|
||||
|
||||
~~~
|
||||
# Un peu violent mais ça semble marcher.
|
||||
# Un meilleure méthode serait peut-être de faire un « unbundle » de l'AMI et de la copier sur /dev/sdf.
|
||||
|
@ -59,22 +65,26 @@ fsck /dev/sdf
|
|||
~~~
|
||||
|
||||
* Détacher le volume le volume, et terminer l'instance :
|
||||
|
||||
~~~
|
||||
ec2-detach-volume vol-xxxxxx --instance i-xxxxxx
|
||||
ec2-terminate-instances i-xxxxxx
|
||||
~~~
|
||||
|
||||
* Faire une snapshot du volume :
|
||||
|
||||
~~~
|
||||
ec2-create-snapshot vol-xxxxxx
|
||||
~~~
|
||||
|
||||
* Enregistrer le snapshot en tant qu'AMI :
|
||||
|
||||
~~~
|
||||
ec2-register --name <name> -a x86_64 --root-device-name /dev/sda1 --block-device-mapping /dev/sda1=snap-xxxxxx
|
||||
~~~
|
||||
|
||||
* Démarrer enfin une instance de cette nouvelle AMI :
|
||||
|
||||
~~~
|
||||
ec2-run-instances --instance-type m1.large --kernel aki-9800e5f1 ami-xxxxxx
|
||||
ec2-associate-address <IP> -i i-xxxxxx
|
||||
|
@ -112,17 +122,20 @@ Vous devez au préalable snapshoter le volume de l'instance, et partager cette s
|
|||
Voici la procédure à suivre, avec $EC2_CERT et $EC2_PRIVATE_KEY contenant les clés du nouveau compte :
|
||||
|
||||
* Tout d'abord on ne peux pas avoir une instance qui utilise une snapshot partagée, il faut donc créer un volume à partir de cette snapshot, puis snapshoter ce volume :
|
||||
|
||||
~~~
|
||||
bin/ec2-create-volume --size 10 --availability-zone us-east-1b --snapshot snap-xxxxxxxx
|
||||
bin/ec2-create-snapshot vol-xxxxxxxx
|
||||
~~~
|
||||
|
||||
* Créez ensuite l'instance à partir de la snapshot :
|
||||
|
||||
~~~
|
||||
bin/ec2-register --name <NAME> -a x86_64 --root-device-name /dev/sda1 --block-device-mapping /dev/sda1=snap-xxxxxxxx
|
||||
~~~
|
||||
|
||||
* Démarrez la nouvelle instance et assignez lui une nouvelle IP :
|
||||
|
||||
~~~
|
||||
bin/ec2-run-instances --instance-type m1.large --kernel aki-9800e5f1 ami-xxxxxxxx
|
||||
bin/ec2-associate-address <IP> -i i-xxxxxxxx
|
||||
|
@ -135,11 +148,13 @@ bin/ec2-associate-address <IP> -i i-xxxxxxxx
|
|||
#### Installation des modules noyau
|
||||
|
||||
* Récupérez les modules pour votre noyau :
|
||||
|
||||
~~~
|
||||
wget <http://ec2-downloads.s3.amazonaws.com/ec2-modules-2.6.18-xenU-ec2-v1.0-x86_64.tgz>
|
||||
~~~
|
||||
|
||||
* Décompressez l'archive à la racine du système :
|
||||
|
||||
~~~
|
||||
tar xzf /tmp/ec2-modules-2.6.18-xenU-ec2-v1.0-x86_64.tgz -C /
|
||||
~~~
|
||||
|
@ -197,6 +212,7 @@ dpkg-reconfigure linux-image-3.2.0-4-amd64
|
|||
* !!!!!! ATTENTION !!!!! *
|
||||
|
||||
Par défaut, le serveur SSH est configuré globalement avec le paramètre:
|
||||
|
||||
~~~
|
||||
PasswordAuthentication no
|
||||
~~~
|
||||
|
|
|
@ -127,6 +127,7 @@ Le binaire fonctionne indifféremment en 32 ou 64 bits.
|
|||
### Interrogation de la carte RAID
|
||||
|
||||
Lancer sas2ircu sans argument(s) affiche la liste des options :
|
||||
|
||||
~~~
|
||||
LSI Corporation SAS2 IR Configuration Utility.
|
||||
Version 4.00.00.00 (2009.10.12)
|
||||
|
@ -156,9 +157,11 @@ SAS2IRCU: No command specified.
|
|||
~~~
|
||||
|
||||
Pour afficher l'état du premier volume RAID :
|
||||
|
||||
~~~
|
||||
# ./sas2ircu 0 DISPLAY
|
||||
~~~
|
||||
|
||||
~~~
|
||||
LSI Corporation SAS2 IR Configuration Utility.
|
||||
Version 4.00.00.00 (2009.10.12)
|
||||
|
|
|
@ -85,6 +85,7 @@ Pour le désactiver, l'une des méthodes est de lancer ces commandes :
|
|||
~~~
|
||||
|
||||
Pour que cela reste en place, on ajoutera dans le fichier */etc/sysctl.conf* :
|
||||
|
||||
~~~
|
||||
net.ipv6.conf.all.autoconf = 0
|
||||
net.ipv6.conf.all.disable_ipv6 = 1
|
||||
|
|
|
@ -55,6 +55,7 @@ UDP buffer size: 208 KByte (default)
|
|||
[ 3] Server Report:
|
||||
[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec 0.036 ms 0/ 893 (0%)
|
||||
~~~
|
||||
|
||||
~~~
|
||||
root@evolinux:~# iperf -t60 -c ping.online.net
|
||||
------------------------------------------------------------
|
||||
|
|
|
@ -126,6 +126,7 @@ No Errors Logged
|
|||
~~~
|
||||
|
||||
### CPU/RAM
|
||||
|
||||
~~~
|
||||
# grep -ri Oops /var/log/
|
||||
# grep -ri threshold /var/log/
|
||||
|
|
|
@ -142,6 +142,7 @@ Le rendre visible :
|
|||
~~~
|
||||
|
||||
Tout de même s'assurer que le service _target_ iSCSI est actif :
|
||||
|
||||
~~~
|
||||
svcs -a | grep -i iscsi
|
||||
disabled 14:24:59 svc:/network/iscsi/target:default
|
||||
|
|
|
@ -37,6 +37,7 @@ pu bits 8
|
|||
pu parity N
|
||||
pu stopbits 1
|
||||
pu rtscts No
|
||||
|
||||
~~~
|
||||
_Note : Avec un adaptateur USB, le device est /dev/ttyUSB0 (ou autre numéro)._
|
||||
|
||||
|
@ -183,22 +184,26 @@ Switch# show ntp associations
|
|||
|
||||
|
||||
Voir l'état et la vitesse de tous les ports :
|
||||
|
||||
~~~
|
||||
Switch# show interfaces status
|
||||
~~~
|
||||
|
||||
Statut d'une interface :
|
||||
|
||||
~~~
|
||||
Switch# show interfaces GigabitEthernet1/0/48
|
||||
~~~
|
||||
|
||||
|
||||
Infos détaillées sur la config d'un port :
|
||||
|
||||
~~~
|
||||
Switch# show interfaces GigabitEthernet1/0/48 switchport
|
||||
~~~
|
||||
|
||||
Désactiver/activer une interface :
|
||||
|
||||
~~~
|
||||
Switch# conf t
|
||||
Switch# interface GigabitEthernet1/0/48
|
||||
|
@ -208,6 +213,7 @@ Switch# exit
|
|||
~~~
|
||||
|
||||
Forcer la vitesse du port :
|
||||
|
||||
~~~
|
||||
Switch# conf t
|
||||
Switch# interface GigabitEthernet1/0/48
|
||||
|
@ -216,6 +222,7 @@ Switch# exit
|
|||
~~~
|
||||
|
||||
Affecter un nom / une description à l'interface :
|
||||
|
||||
~~~
|
||||
Switch# conf t
|
||||
Switch# interface GigabitEthernet1/0/48
|
||||
|
@ -223,6 +230,7 @@ Switch# description Machine XYZ
|
|||
~~~
|
||||
|
||||
Gestion du MTU pour toutes les interfaces Gigabits :
|
||||
|
||||
~~~
|
||||
system mtu jumbo 9000
|
||||
~~~
|
||||
|
@ -382,6 +390,7 @@ Switch# copy flash:/vlan.dat ftp://<IP>/rep/sauvegarde_vlan.dat
|
|||
|
||||
Si il y a assez de place sur la mémoire flash (`dir flash:`), copier le nouveau firmware dessus (`copy ftp://<IP>/fichier.bin flash:`), sinon effacer le contenu de la flash (`erase flash:`), puis placer le nouveau firmware.
|
||||
Ensuite, il suffit de spécifier de charger le nouveau firmware.
|
||||
|
||||
~~~
|
||||
enable
|
||||
conf t
|
||||
|
@ -453,11 +462,13 @@ Switch# show interfaces vlan <ID>
|
|||
##### De tous les VLAN
|
||||
|
||||
Voir un résumé de la configuration :
|
||||
|
||||
~~~
|
||||
Switch# show vlan brief
|
||||
~~~
|
||||
|
||||
Voir la configuration de tous les VLAN :
|
||||
|
||||
~~~
|
||||
Switch# show vlan
|
||||
~~~
|
||||
|
@ -476,16 +487,19 @@ Switch(config-if)# end
|
|||
~~~
|
||||
|
||||
Sur les 2960, le switch ne supporte que le dot1q. On aura juste à basculer le port en mode trunk :
|
||||
|
||||
~~~
|
||||
# switchport mode trunk
|
||||
~~~
|
||||
|
||||
Il est possible de spécifier le ou les vlans transportés par le trunk :
|
||||
|
||||
~~~
|
||||
# switchport trunk allowed vlan 11,13
|
||||
~~~
|
||||
|
||||
Astuce : pour ajouter un VLAN sur un trunk sans reprendre toute la liste de ceux déjà autorisés on peut utiliser la syntaxe :
|
||||
|
||||
~~~
|
||||
# switchport trunk allowed vlan add 42
|
||||
~~~
|
||||
|
@ -493,6 +507,7 @@ Astuce : pour ajouter un VLAN sur un trunk sans reprendre toute la liste de ceux
|
|||
Une façon de contrôler si le trunk est bien mis en place des 2 côté est de consulter la sortie de la commande "show vlan brief". Si le port est toujours dans le vlan 1, c'est que le trunk n'est pas opérationnel (interface non montée, ou port distant non configuré en trunk). Si tout fonctionne bien, on ne doit le voir dans aucun vlan, mais on le verra en trunk dans un "show interfaces status".
|
||||
|
||||
Pour afficher les VLAN autorisés sur un trunk :
|
||||
|
||||
~~~
|
||||
# show interfaces Gi1/0/50 trunk
|
||||
~~~
|
||||
|
@ -515,6 +530,7 @@ Switch(config)# no ip http server
|
|||
#### Par SSH
|
||||
|
||||
Activation et ajout d'un utilisateur local :
|
||||
|
||||
~~~
|
||||
configure terminal
|
||||
aaa new-model
|
||||
|
@ -641,6 +657,7 @@ Transmit hold count: 6 BPDUs
|
|||
Il faut avoir les mêmes valeurs si d'autres équipements interviennent sur le réseau, comme des machines OpenBSD ou Linux.
|
||||
|
||||
Voir les informations du STP sur le switch :
|
||||
|
||||
~~~
|
||||
#show spanning-tree summary
|
||||
#show spanning-tree
|
||||
|
@ -729,6 +746,7 @@ On répètera cette manipulation pour chaque VLANs et chaque subnet déclaré su
|
|||
#### Routage Inter-VLANs
|
||||
|
||||
L'activation du routage inter-VLANs se fait de la manière suivante :
|
||||
|
||||
~~~
|
||||
(config)# ip routing
|
||||
~~~
|
||||
|
@ -763,6 +781,7 @@ Par défaut, CISCO n'autorise pas les modules GBIC non agréés, il faut donc d
|
|||
~~~
|
||||
|
||||
On peut ensuite les lister via :
|
||||
|
||||
~~~
|
||||
#show inventory
|
||||
~~~
|
||||
|
@ -806,6 +825,7 @@ On utilisera cette commande uniquement si l'on est sûr de ne pas avoir besoin d
|
|||
(serveur non virtuel connecté directement au port, etc.).
|
||||
|
||||
##### Activer
|
||||
|
||||
~~~
|
||||
(config)#interface GigabitEthernet0/28
|
||||
(config-if)#spanning-tree portfast
|
||||
|
|
|
@ -168,6 +168,7 @@ Voir :
|
|||
* Telecharger le SDK
|
||||
* Installer "ant", "java-jdk" (javac)
|
||||
* Créer l'application :
|
||||
|
||||
~~~
|
||||
$ ./tools/android create project -t 1 -n test -p /tmp/test -a A9 -k com.example.myandroid
|
||||
$ cd /tmp/test
|
||||
|
|
|
@ -137,11 +137,13 @@ Cela signifie que vous avez plus de 2^15^ (~= 32k) répertoires dans un réperto
|
|||
Il faut envisager de structurer le répertoire différemment pour obtenir une hiérarchie plus profonde, avec moins d'éléments dans chaque répertoire.
|
||||
|
||||
Chercher le répertoire contenant le plus de répertoires = + de inodes :
|
||||
|
||||
~~~
|
||||
for i in $(find . -type d); do echo $(ls -a $i | wc -l) $i; done | sort -n
|
||||
~~~
|
||||
|
||||
Supprimer des vieux fichiers (+ vieux de 30 jours en modification) :
|
||||
|
||||
~~~
|
||||
find . -type f -mtime +30 -exec rm '{}' \;
|
||||
~~~
|
||||
|
|
Loading…
Reference in New Issue