@ -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.
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 :
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, ...).
*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 :
@ -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:
@ -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 :
@ -130,4 +144,4 @@ Pour utiliser un algorithme de chiffrement spécifique, il faut le préciser au
Le chiffrement aes-cbc-essiv est le chiffrement par défaut de cryptsetup pour les noyaux supérieurs au 2.6.10, car il corrige une vulnérabilité potentielle du chiffrement aes-cbc-plain.
Une autre méthode de chiffrement utilisée avec l'algorithme AES (Rijndael) est le mode XTS, qui est réputé plus résistants aux attaques par watermarking, mais nécessite un module spécifique (judicieusement nommé xts.ko) et une clef d'initialisation du double de la taille de la clef finale (voir <http://en.wikipedia.org/wiki/Disk_encryption_theory#XEX-based_tweaked-codebook_mode_with_ciphertext_stealing_.28XTS.29)>
Les autres algorithmes dignes d’intérêt sont twofish et serpent, deux compétiteurs de l'AES face à Rijndael.
Les autres algorithmes dignes d’intérêt sont twofish et serpent, deux compétiteurs de l'AES face à Rijndael.
@ -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
@ -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) :
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:
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`:
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
# 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_
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 ;
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...
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/>