18
0
Fork 0

Corrections de mise en forme

This commit is contained in:
Jérémy Lecour 2017-01-03 11:20:35 +01:00 committed by Jérémy Lecour
parent 7ce3e83c12
commit ffc33f1d7f
83 changed files with 739 additions and 230 deletions

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

@ -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 dintérêt sont twofish et serpent, deux compétiteurs de l'AES face à Rijndael.
Les autres algorithmes dignes dintérêt sont twofish et serpent, deux compétiteurs de l'AES face à Rijndael.

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

@ -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 :
~~~

View File

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

View File

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

View File

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

View File

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

View File

@ -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…

View File

@ -18,6 +18,7 @@ authfile = /etc/nbd-server/allow.pi01
~~~
/etc/nbd-server/allow.pi00
~~~
192.168.42.42
~~~

View File

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

View File

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

View File

@ -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;
~~~

View File

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

View File

@ -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.
}}}

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

@ -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)

View File

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

View File

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

View File

@ -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/
~~~

View File

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

View File

@ -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"
}
}
~~~
~~~

View File

@ -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`.

View File

@ -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!

View File

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

View File

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

View File

@ -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"
~~~

View File

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

View File

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

View File

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

View File

@ -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');
?>
~~~
~~~

View File

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

View File

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

View File

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

View File

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

View File

@ -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_.

View File

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

View File

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

View File

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

View File

@ -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
+----+------------+---------------+----------------------+----------------------+---------------+

View File

@ -124,6 +124,7 @@ S'attacher à un terminal :
~~~
Sortir :
~~~
Ctrl+AltGr+]
~~~

View File

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

View File

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

View File

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

View File

@ -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
View File

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

View File

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

View File

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

View File

@ -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)

View File

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

View File

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

View File

@ -126,6 +126,7 @@ No Errors Logged
~~~
### CPU/RAM
~~~
# grep -ri Oops /var/log/
# grep -ri threshold /var/log/

View File

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

View File

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

View File

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

View File

@ -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 '{}' \;
~~~