Linux Attitude

Niveau :      
Résumé : lvreduce ; vgreduce ; lvextend ; vgextend

Après l'immense succès du premier article, voici sous vos applaudissements le deuxième article.

Ajout d'un nouveau disque

Maintenant que vous savez utiliser LVM vous voudriez aller un peu plus loin. Mise en situation : vous avez un disque de 50To, un vg déjà en place et sur sur ce VG un LV de 30To dédié à votre médiathèque. Or vous venez de découvrir (et donc d'acheter) un nouveau disque de 1Po (Péta Octet pour ceux qui ne suivent pas, hé oui, c'est fou comme ça avance vite la technologie).

$ lvdisplay /dev/vg0/mediatheque
  --- Logical volume ---
  LV Name                /dev/vg0/mediatheque
  VG Name                vg0
  LV UUID                AN0y7h-1cIF-cPmC-vE9E-JnKG-worn-dWeQ8D
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                31,82 TB
  Current LE             81459200
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

Commençons donc par ajouter notre nouveau disque au vg :

# partitionnement
$ cfdisk /dev/sdc
# formatage
$ pvcreate /dev/sdc1
# ajout au vg
$ vgextend vg0 /dev/sdc1

Et voila nous avons de la place disponible. Maintenant agrandissons notre LV. Remarquez qu'il faut le faire avant d'agrandir le système de fichier puisqu'il se trouve au dessous. Au contraire en cas de réduction, il faut commencer par le système de fichier qui se trouve au dessus.

Niveau :      
Résumé : postfix ; catch all

Supposons que vous ayez une application qui envoie régulièrement des mails. Vous voulez tester cette application en conditions réelles, mais sans envoyer ces mails (par exemple un logiciel de spam :-)

Pour ne pas tout casser, nous allons juste changer la configuration du serveur utilisé pour envoyer les mails. Tous les mails, tous domaines et tous destinataires confondus seront acceptés.

Étape 1 : tout rediriger vers le compte de quelqu'un

Prenons un postfix. Ajoutons une ligne dans main.cf :

# on matche les mails qu'on va accepter avec des expression régulières
virtual_alias_maps = regexp:/etc/postfix/virtual

Créons notre fichier /etc/postfix/virtual :

# on redigige tout vers quelqu'un qui va pouvoir lire les mails
/@/	peck@ditoto.com

C'est bien mais on voudrait pouvoir centraliser ce serveur de test et trier les mails envoyés en fonction des serveurs d'origine (développement, recette, qualification ...).

Étape 2 : filtrer

On va donc rediriger vers un compte local créé pour l'occasion (si vous avez des comptes virtuel, il faut faire différemment, vous saurez faire) :

$ adduser genericmail

On adapte /etc/postfix/virtual et on n'oublie pas de laisser passer les destinataires finaux sous peine de boucles :

# on redirige tout vers notre filtre
if !/@ditoto.com$/
/@/	genericmail
endif

On relaie les mails de ces mêmes destinataires finau[xd] vers leur vrai serveur dans main.cf et on se prépare à utiliser procmail :

relay_domains = ditoto.com
mailbox_command = /usr/bin/procmail -Y -a $DOMAIN

Et enfin, le plus important, nous allons filtrer avec un procmail (au passage vérifiez qu'il est installé :-p) :

# on redirige en fonction du destinataire
:0
* ^TO.*@gnagna.fr.*
! peck@ditoto.com

# plus important, on peut le faire en fonction de la source
:0
* ^Received:.*from mamachine.dev.ditoto.com
! pock@ditoto.com

# et une petite règle par défaut pour ne pas être surchargé
:0
* ^.*
/dev/null

La fin

Voilà, vous avez un serveur mail paramétrable qui vous permet de faire ce que vous voulez des mails qu'il reçoit, quels que soient leurs destinataires. Rien de bien compliqué, mais bien pratique en environnement de test.

Niveau :      
Résumé : memcached (bis)

Dans un précédent article j'expliquais ce qu'était memcached et comment l'utiliser. Nous allons maintenant nous enfoncer un peu plus dans les détails.

Performances

Tout d'abord parlons performances. Commençons par utiliser les bonnes options :

• utilisez autant de thread que votre machine a de coeurs (option -c)
• utilisez autant de ram que possible en n'oubliant pas d'en laisser aux autres applications s'il y en a (option -m)

Si vous utilisez memcached localement sur une seule machine, utilisez l'option -s pour sauter toute la pile tcp/ip et gagner un peu en performances.

Ensuite vous devez modifier votre code pour cacher un maximum de choses, encore faut-il que cela vaille le coup. Heureusement mettre en place le cache et le désactiver est très rapide, vous pouvez donc mesurer facilement vos gains. Sur un site web chargé, il est conseillé de cacher en premier les résultats des requêtes SQL. Mais il peut aussi être judicieux de cacher un tableau, voire toute une page, car elle est probablement une agrégation de plusieurs requêtes SQL (et rien ne vous empêche de faire les 2, voire de mettre des cache partout où vous pouvez). Mais n'oubliez pas, faites des mesures, c'est le meilleur moyen de savoir si votre cache sert à quelque chose.

Choisir quoi cacher est finalement assez simple : la partie la plus grosse possible de la page pouvant être partagé par le plus de monde possible. Donc choisir des éléments ne dépendant pas de l'instant présent. Par exemple ce n'est peut-être pas une bonne idée de cacher une page dépendant d'une session, sauf si votre utilisateur est sensé rester longtemps sur votre site. Contre exemple, quelque chose qui vu par tout le monde mais qui dépend de l'heure qu'il est (le dessin de votre horloge analogique par exemple).

Si votre cache est uniquement local, il peut être plus intéressant d'utiliser une bibliothèque dans votre processus que memcached. Comme le mesure ce site : http://www.mysqlperformanceblog.com... l'api cache interne de php serait 30 fois plus rapide que memcached.

Si votre cache n'est pas uniquement local mais que vous avez toujours des problèmes de performances, il peut être utile d'empiler plusieurs niveaux de cache (local puis distribué).

Et enfin optimisez l'usage de votre cache pour faire en sorte que le maximum de choses demandées au cache s'y trouve déjà. Pour cela faut mesurer son utilisation. Memcached enregistre déjà les mesures et propose une commande pour retourner les résultats.

Niveau :      
Résumé : memcached

Memcached, cékoidonc ? Tout d'abord c'est un mot, contrairement aux rigolos (comme moi) qui croient savoir parler anglais, on ne dit pas "memcachde" ou "mèmecachède" mais "mèmecachdi". Cette prononciation explique ce qu'est memcached : memory cache daemon, un processus qui utilise une partie de votre RAM pour en faire un cache. Le but est d'accélérer vos applications quasiment gratuitement.

Sur un site web

Ce démon a été créé pour servir de cache réparti entre plusieurs machines pour accélérer des calculs fréquents et répétitifs, comme par exemple récupérer la liste des défaites du PSG sur le site de l'Équipe. Il permet donc sur les très gros sites de réduire la charge des serveurs de base de données en mettant en RAM une bonne partie des informations.

Au lieu d'interroger directement la base de données, le site va commencer par interroger le cache et seulement ensuite la base si les informations ne se trouvent pas dans le cache (et bien sûr remplir le cache suite à ça). Ce cache fonctionne de manière distribuée, ce qui veut dire que l'information ne se trouve pas nécessairement sur la machine qui sert la page web. Plusieurs machines partagent leur mémoire et contiennent chacune une partie du cache.

Le démon

Le fonctionnement du démon est très simple : au lancement il s'alloue de la mémoire et ensuite écoute sur un port tcp les commandes qui lui sont envoyées. Celles-ci sont d'une simplicité extrême, pour simplifier, disons qu'il y en a 2 : get et set. Set permet de stocker dans la mémoire une valeur associée à une clé (exemple 199$ associé à prix_baril), get permet vous l'aurez compris de récupérer la valeur associée à une clé. L'intérêt de ces fonctions est qu'elles sont très rapides. Ajoutons pour faire plus complet une dose de timeout sur les valeurs (oui ce n'est qu'un cache), et la possibilité de supprimer ou de mettre à jour une valeur.

Cette simplicité implique qu'une certaine logique doit être implémentée au niveau du client. La bibliothèque que vous utiliserez pour communiquer avec memcached doit gérer elle même la distribution des données. La solution communément retenue est de faire un hash sur la clé et de choisir le serveur à interroger en fonction de ce hash. Le fait d'avoir le même algorithme sur tous les clients permet de garantir un fonctionnement cohérent.

Cette solution a l'avantage d'être très rapide puisque nécessitant un minimum de logique.

Niveau :      
Résumé : tcpwrappers ; hosts.allow ; hosts.deny

Le contrôle d'accès est généralement fourni par l'application qui fournit un service. Pour le contrôle de l'identité cette application utilise en général pam, mais de nombreuses applications effectuent des contrôles sur d'autres éléments que l'identité de la personne et en particulier le réseau. Tout comme pam il existe une bibliothèque qui s'occupe de ceci pour éviter au développeur de mal faire plusieurs choses. Parlons de tcpwrappers.

Les bases

La bibliothèque tcpwrappers permet à une application de disposer d'un contrôle du client à moindre frais. Ses deux fichiers de configuration sont /etc/hosts.allow et /etc/hosts.deny. Sa méthode de fonctionnement est très simple. Si un client a une correspondance dans hosts.allow, il est autorisé à entrer, sinon s'il a une correspondance dans hosts.deny, il est refusé, et enfin s'il ne matche aucune règle, il est accepté.

Le format de ces fichiers est assez simple :

# service : client 
sshd : 127.0.0.1

Vous pouvez remplacer le nom du service (du démon) par ALL, qui matche tous les services utilisant tcpwrappers, ou par un numéro de port (22).

Pour le nom du client, le système de matching est assez évolué. Vous pouvez donner un nom de machine (machine.toto.fr), un nom de domaine (.toto.fr), un réseau (10.0.0.0/24), un netgroup NIS (@groupe), une IPv6 (1:2:3:4:5:6:7:8/64) ou même une liste en provenance d'un fichier un peu plus complet (/etc/deny). Les wildcards shell fonctionnent aussi dans ces règles (*.toto.fr). Notez que si le serveur dns est indisponible, les règles basées sur les noms ne matchent pas, donc en l'absence de règles sur l'ip, l'accès sera au final autorisé.

Des alias existent aussi pour les clients, les plus importants sont ALL (tout le monde), LOCAL (attention, il ne fait pas exactement ce à quoi on s'attend, il matche les machines dont le nom n'a pas de domaine), et PARANOID (on vérifie que le dns direct et reverse correspondent).

Niveau :      
Résumé : chroot bind

Suite à l'article précédent, je vous suggérais de faire un chroot facilement sous debian. Oui, mais pour bind, pas besoin de se créer un chroot complet. Avec debian comme avec les autres, les options de chroot propres à named existent (je détaille le cas debian, mais les autres sont similaires). La méthode est simple, il suffit de modifier /etc/default/bind9 :

OPTIONS="-u bind -t /var/lib/named"

Puis de créer la base du chroot

$ mkdir -p /var/lib/named/etc
$ mkdir -p /var/lib/named/dev
$ mkdir -p /var/lib/named/var/cache/bind
$ mkdir -p /var/lib/named/var/run/bind/run

De copier la conf de bind dans le chroot

mv /etc/bind /var/lib/named/etc
ln -s /var/lib/named/etc/bind /etc/bind

Bind a aussi besoin de quelques fichiers device

$ mknod /var/lib/named/dev/null c 1 3
$ mknod /var/lib/named/dev/random c 1 8
$ chmod 666 /var/lib/named/dev/null /var/lib/named/dev/random

Et des droits :

$ chown -R bind: /var/lib/named/var/*
$ chown -R bind: /var/lib/named/etc/bind

Et voilà, tranquilou (enfin presque).

La prochaine fois : apache

Niveau :      
Résumé : apachetop ; mytop

Vous connaissiez xrestop, iftop, top, htop, ntop voici maintenant deux nouveaux, apachetop et mytop.

Apachetop

Comme vous vous en doutez, apachetop permet de monitorer l'activité d'apache. Il le fait en lisant ses fichiers de log, donc attention, si vous logguez des choses dans des fichiers inhabituels, c'est à vous de préciser quels fichiers lire. Apachetop vous affiche :

• les statistiques depuis le début de la session, en requête, en octets, ...
• la proportion de chacun des codes de retour (200,300,...) correspondante
• les statistiques depuis les 30 dernières secondes, en requête, en octets, ...
• la proportion de chacun des codes de retour (200,300,...) correspondante
• la liste des url les plus appelées

$ apachetop -l -f /var/log/apache2/virtual1.access.log -f /var/log/apache2/virtual2.access.log

Mytop

Comme vous vous en doutez, mytop permet de monitorer l'activité de mysql. Il le fait en appelant régulièrement show processlist et en vous formatant la sortie.

• Attention, parfois ce processus consomme beaucoup.
• Attention, il ne lit pas le fichier .my.cnf donc les valeurs par défaut ne sont pas bonnes.
• Attention, s'il y a une erreur de config mytop affiche sa config, y compris le mot de passe, ce qui est pas top.
• Mytop demande une base de données valide, mais ne s'en sert pas vraiment, -> --db mysql
• La connexion se fait par défaut en tcp -> option -S pour spécifier la socket
• Après un changement de mode d'affichage, on est obligé de quitter (touche q)

$ mytop --db mysql --user toto --prompt

Il vous affichera les connexions avec leur thread id, leur machine, leur user et leur commande. Notez que le manuel vous indiquera quelques touches permettant d'afficher diverses informations.