Pour vérifier le bon fonctionnement de votre démon ntp, vous êtes amené à taper la commande suivante qui liste les source de temps utilisées :

$ ntpdc -p

Cette commande met une étoile face à la source de référence utilisée pour la synchronisation. Le choix se fait entre autre en fonction du stratum de la source. Je rappelle que les serveurs NTP disposant d'une source de temps matérielle fiable (horloge atomique) ont pour stratum 1. Ceux qui se synchronisent sur eux, 2, et ainsi de suite.

Étant donné qu'il y a un grand nombre de serveurs publics de strate 2 et 3, vous devriez avoir accès à des serveurs de strate 4, ou au pire 5. Mais si le serveur a une strate plus élevée, il se peut que l'horloge choisie ne soit plus le serveur, mais l'horloge locale qui a une strate définie par défaut à 5 sur certaine distributions.

Et là c'est le drame, vous n'êtes plus synchronisés !

Pour résoudre ce problème, il y a plusieurs méthodes, se résumant toutes en la configuration des serveurs de temps :

# ntp.conf

# mettre l'option prefer sur le serveur voulu
serveur xxx.com prefer
# réduire la strate du serveur
fudge xxx.com stratum 4

# augmenter la strate de l'horloge locale
# 127.127 pour les horloges non réseau
# 1.0 pour l'horloge système
fudge 127.127.1.0 stratum 10

Si vous avez aimé, il y a aussi :

1. Il faut laisser le temps au temps
2. Verrou virtuel

Je suis sûr qu'un certain nombre d'entre vous ont plusieurs machines en production. Et je suis certain que vous les gérez toutes à distance (merci ssh).

Le risque est grand lorsqu'on a des machines distantes de confondre un terminal avec un autre. Vous pouvez bien sûr personnaliser un prompt différent pour chaque machine, mais je vous propose aujourd'hui une autre solution.

$ apt-get install molly-guard

Et voilà !

Maintenant les commandes shutdown, halt et reboot vous demanderont de taper le nom de la machine que vous voulez vraiment éteindre avant de le faire. Ouf, le serveur mail/dns/web de l'entreprise ne sera pas éteint par erreur à la place de votre serveur de base de données de test.

Cerise sur le gateau, ceci n'arrive pas si vous êtes sur un terminal local sur la machine, puisque vous êtes sensés savoir où vous êtes.

Exercice pratique, faites de même pour les quelques (elles doivent rester rares) commandes critiques sur vos machines.

Si vous avez aimé, il y a aussi :

1. Présentation, cours
2. Partage de souris/clavier entre deux machines
3. Multi-écran sur plusieurs machines

Que se passe-t-il lorsqu'apache reçoit une requête ?

La question peut paraître anodine jusqu'à ce qu'on ait à écrire un fichier de configuration un peu complexe. Il faut alors avoir une idée de l'ordre dans lequel les opérations sont effectuées.

Commençons par un aperçu rapide :
-> récupération du virtualhost concerné
-> récupération de la partie requête
-> rewrite rules et redirect
-> alias et réécriture de la requête nom de fichier
-> traitement par <Directory>, <DirectoryMatch>, .htaccess, <Files>, <FilesMatch>, <Location> et <LocationMatch>
-> droits d'accès
-> traitement du fichier en fonction de son type.

Ouf c'est long ! Comme cet article, alors prenez votre temps ...

Traitement de l'URL

Pour chaque requête, apache relit sa configuration (en fait il récupère la version parsée en mémoire). Ensuite il parcourt les éléments dans l'ordre, les compile en une seule conf puis la utilise cette conf spécifiquement pour cette requête.

Virtualhost

Bon ca c'est facile, on se base sur les ServerName définis dans les <Virtualhost>. Si on n'en trouve pas, on cherche dans les ServerAlias, si on n'en trouve pas on cherche encore, mais cette fois avec les wildcard (*.mondomaine.com), si on ne trouve toujours pas, on prend le premier <Virtualhost> qui a été dacléré. Et enfin s'il n'y a pas de virtualhost, on prend le DocumentRoot défini à la racine du serveur apache lui-même.

Voilà on a trouvé le virtualhost, maintenant on prend la requête, qui est la partie située à droite de l'URL après l'hôte et le port.

Transformation de l'URL

Contrairement à ce qu'on pourrait penser, lorsqu'il y a modification de l'url, il n'y a pas de gestion de droits d'accès sur la requête originale, seulement sur l'url modifiée (par rewriterule en général).

On traite d'abord les RewriteRule, dans l'ordre de leur priorités.

Si aucune ne correspond, on traite ensuite les Redirect et les RedirectMatch dans l'ordre de leur écriture. Attention on prend aussi en compte ceux qui sont dans les <Location> qui correspondent, mais on fait comme s'ils avaient été écrits à la racine. C'est-à-dire qu'on n'enlève pas le préfixe du location pour les traiter.

On traite ensuite les Alias, AliasMatch, ScriptAlias et ScriptAliasMatch dans l'ordre de leur apparition. Ce traitement fournit le nom de fichier réel à utiliser pour une URL donnée.

Si on ne trouve pas d'alias on ajoute le DocumentRoot à la requête pour obtenir le chemin complet du fichier.

Configuration et droits d'accès

A partir de maintenant on repart de la configuration du virtualhost et pour chaque section on prend la configuration qui correspond à la requête en cours. Et à la fin on fusionne les configurations récupérées selon une règle de fusion dépendant de chaque module.

C'est complexe et chiant à retenir, donc pour simplifier retenez que les configurations spécifiques aux droits d'accès sont en mode remplacement, c'est-à-dire que la dernière configuration remplace toutes les autres.

Directory et DirectoryMatch

On sait maintenant quel chemin doit être lu, on parcourt l'arborescence pour savoir si c'est un fichier et si on peu le lire s'il a un vrai chemin sur le système ...

On part de / et au fur et a mesure qu'on descend dans le système de fichier on vérifie les <Directory>, puis les .htaccess, puis les <DirectoryMatch> dans l'ordre pour chacun des répertoires. On a donc séquentiellement pour par exemple /var/www :

• <Directory />
• /.htaccess
• <DirectoryMatch />
• <Directory /var>
• /var/.htaccess
• <DirectoryMatch /var>
• <Directory /var/www>
• /var/www/.htaccess
• <DirectoryMatch /var/www>

Toutes les sections qui correspondent sont accumulées dans la configuration en cours.

Attention ! Si l'option FollowSymLinks est activée, on fait la correspondance sur les liens symboliques avant de les déréférencer. Si l'option est désactivée, on la fait sur les liens après les avoir déréférencés. C'est assez contre intuitif !

Files et FilesMatch

Une fois arrivé au bout, on a un fichier, on lit alors les sections <Files> et <FilesMatch> dans l'ordre de leur apparition, y compris celles qu'on a trouvé dans les .htaccess ou les <Directory>.

Notez que ces sections ne prennent en compte que le nom de fichier, sans chemin.

Attention, même remarque que précédemment sur les liens symboliques : "Si l'option FollowSymLinks est activée, on matche sur les liens symboliques avant de les déréférencer. Si l'option est désactivée, on matche sur les liens après les avoir déréférencés."

Location et LocationMatch

Maintenant il nous reste à prendre en compte tous les <Location> et <LocationMatch> de la configuration qui correspondent à notre URL. Cette fois on les prend séquentiellement et uniquement en fonction de l'url.

Attention les étapes de réécriture de règle sont passées, on matche donc sur l'url réécrite.

Configuration des droits

Dans le cas des droits d'accès, les blocs de directives se remplacent. C'est-à-dire que si vous avez une série de "order / allow / deny" dans une section, elle remplace intégralement toute autre série de "order / allow / deny" que vous pourriez trouver dans une section précédente.

Attention ceci est valable pour chacun des modules séparément.

Un exemple pour être plus clair :

<Location />
    order allow,deny
</Location>
<Directory /html>
    deny from all
    AuthUserFile users.txt
</Directory>
<DirectoryMatch />
    AuthUserFile web.txt
</DirectoryMatch>
<Directory />
    order deny,allow
    allow from all
    AuthUserFile admins.txt
</Directory>

Le premier <Directory> est lu, puis il est remplacé par le 2e <Directory>, puis il est remplacé par le <DirectoryMatch> puis par le <Location> intégralement, mais séparément pour le module authz_host (order, allow, deny) et le module authnz_user (AuthUserFile). On a donc pour une requête qui matcherait les 3 sections la configuration suivante :

order allow,deny
AuthUserFile web.txt

Pas évident hein :-) Surtout que cette règle n'est pas la même pour d'autres modules comme mod_rewrite.

Traitement des droits

Le traitement des droits lui-même est particulier.

Si on est en satisfy all (par défaut) :

• On prend tous les modules de traitement des droits d'accès et si l'un d'entre eux interdit l'accès, on interdit l'accès.
  
• Puis on prend tous les modules d'authentification utilisateur et si l'un d'entre eux autorise l'accès ou s'il n'y en a pas, on autorise l'accès.

Si on est en satisfy any :

• On prend tous les modules de traitement des droits d'accès et si l'un d'entre eux interdit l'accès :
  • On demande son avis aux modules d'authentification, si l'un d'entre eux autorise l'accès ou s'il n'y en a pas, on autorise.

Rewrite (again)

Arrivé ici, on repasse dans les RewriteRules Mais cette fois on ne traite que le cas particulier des rewrite dans les sections <Location>, <Directory>, <Files> et .htaccess

Ces rewrite se cumulent cette fois (contrairement aux module d'accès, mais toujours selon le même parsing vu précédemment).

Ces rewrites sont cette fois relatifs, contrairement aux rewrite globaux. Ce qui veut dire qu'on les écrit par rapport à une racine qui est l'endroit où la règle est écrite.

Réponse

Cool maintenant on a notre requête nettoyée et on sait vers quelle fichier elle pointe.

Reste à la traiter.

Filter

On cherche tous les filtres (input et output) associés à cette url. Par exemple il y a mod_include, vous savez, pour les fichier .shtml qui contiennent des truc genre :

<!--#echo var="DATE_LOCAL" --> 

Il y a aussi les filtres pour compresser (oui pas besoin de zipper en php, apache peut le faire tout seul).

Tout ceci avec SetInputFilter et SetOutputFilter.

Handler

Ensuite on cherche le handler associé à ce type de fichier. Il y a bien sur le handler fichier (incroyable), mais aussi le handler php, le handler perl (sisi), le handler cgi, mais aussi le handler proxy, et tous ceux que vous pourriez définir avec SetHandler .

On et hop lance le tout : inputfilter -> handler -> outputfilter.

Conclusion

En résumé c'est le bordel ! Celui qui a écrit ça devait en avoir pris une sacrée dose et pas que de la farine. Probablement un pote de celui qui a fait X11 ...

Ne supposez jamais que ça marche comme vous le pensez, testez à chaque modification de votre conf.

Espérons que le prochain apache en développement tiendra ses promesses et nettoiera un peu la gestion de la configuration et surtout des droits d'accès. Sinon je prédis un avenir merveilleux pour toutes les alternatives soit disant "légères" comme lighthttpd ou nginx.

Si vous avez aimé, il y a aussi :

1. Hébergement de fichiers avec WebDAV
2. Filtrage de fichiers sur apache

Supposons que vous administriez une machine distante. Vous n'avez pas d'accès physique à cette machine. C'est ennuyant puisque vous venez de changer la configuration de votre bootloader.

Comment faire pour rebooter tout en garantissant que ca va marcher ?

Hé bien j'ai la solution qui vous permettra de tester ce boot avant de rebooter : qemu.

Préparer les disques

Il nous faut des disques en lecture seule pour éviter que le boot de la machine virtuelle n'écrive sur un disque en cours d'utilisation. Donc pour chacun de vos disques physique :

$ cp -a /dev/sda /root/sda
$ chmod 440 /root/sda

Ainsi nous avons des disques garantis en lecture seule.

Préparer son terminal

Nous allons enregistrer ce qui se passe sur le terminal, lequel va tourner en ncurses, il est donc important pour la lisibilité des logs de le dimensionner à la même taille que l'écran de boot, c'est-à-dire 80x25.

Modifiez la taille de votre fenêtre de terminal jusqu'à ce que les variables $COLUMNS et $LINES vaillent respectivement 80 et 25.

Préparer son bootloader

Quel que soit votre bootloader configurez le de façon à ce qu'il ne lance pas de mode graphique, sinon vous ne pourrez pas stocker les logs de ce qui se passe.

Choisit son qemu

Installez qemu. Puis en fonction du matériel à émuler choisissez qemu-system-i386 ou qemu-system-x86_64 ou une autre architecture si vous travaillez sur d'autres machines.

Lancer le tout

Préparez un 2e terminal pour tuer qemu , ca sera plus simple que d'attendre qu'il se termine proprement (killall qemu pour les impatients).

$ sync
$ ssh -t localhost "qemu-system-x86_64 -m 512 -curses -hda /root/sda" | tee logs

Pourquoi sync ? au cas où vous auriez fait des modification impactant le boot, on force l'écriture de celles-ci sur le disque.

Pourquoi ssh ? Pour profiter de l'option -t qui crée un terminal virtuel même lorsqu'on travaille dans un pipe.

Pourquoi tee ? Pour stocker les logs de ce qui se passe tout en gardant la main sur le clavier. Tout est tellement rapide qu'il peut y avoir des erreurs invisibles.

Pourquoi -m 512 (512Mo de ram): prenez une valeur inférieure à votre matériel mais malgré tout proche pour éviter les effets de bord.

Pensez à ajouter les disques dont vous pourriez avoir besoin selon le niveau de boot que vous voudriez tester.

Lire les logs

Bon, qemu s'est lancé, le boot a planté, mais vous n'avez pas eu le temps de voit l'erreur.

Commencez par tuer le qemu s'il vous gêne. Puis lisez les logs :

$ less -R logs

Pourquoi -R ? parce que cette option vous permet de ne pas traduire les caractères spéciaux que qemu écrit à travers ncurses et vous permet de voir le contenu des logs tels qu'ils sont apparus à l'écran.

Mode graphique

Si vous ne voulez pas de logs ou que vous ne pouvez pas empêcher le mode graphique de se lancer, vous pouvez faire sans. Dans ce cas, à vous de vous connecter à la machine de façon à ce qu'un serveur X soit accessible (par exemple avec ssh -X).

La commande devient alors :

$ sync
$ qemu-system-x86_64 -m 512 -hda /root/sda

PS : Et ça marche avec les outils de virtualisation comme xen.

Si vous avez aimé, il y a aussi :

1. Chargeeeez !
2. Sécurité du processus de boot
3. Présentation, cours

Linux est un système très stable. Tellement stable que certaines personnes font une gloire personnelle de la durée d'allumage de leurs machines.

Pour pouvoir vous vanter vous aussi auprès de vos collègues et briller dans les soirées, voici le moyen de savoir quelles ont été les différentes durées d'uptime de votre machine.

Uptimed est un simple démon disponible dans le paquet éponyme. Il suffit de l'installer. Ce démon ne fait qu'une chose et il le fait bien, il enregistre la durée depuis laquelle le système est lancé dans un fichier de logs et rend ces informations disponibles aux utilisateurs. Il est même capable de vous envoyer un mail pour vous avertir de l'atteinte d'un record.

Les utilisateurs ont accès aux meilleurs temps avec la commande uprecords :

$ uprecords

Tout ceci est bien joli et il est vrai que c'est très gratifiant d'avoir réussi à maintenir un système en fonctionnement pendant plusieurs années, voir une dizaine d'années pour certains. Mais il ne faut pas oublier une chose, la sécurité. Un noyau qui n'est jamais rebooté, ce n'est pas seulement un noyau stable, mais c'est aussi un noyau vulnérable car non mis à jour.

Alors bien sur certains argueront qu'il existe maintenant ksplice. Mais je pense que son usage reste marginal. C'est pourquoi, n'oubliez pas de mettre une sonde sur vos serveur pour surveiller les machines qui n'ont pas été rebootées depuis longtemps, c'est en fait un signe de faiblesse.

Si vous avez aimé, il y a aussi :

1. Récupération de données
2. Lenny barr
3. Filtrage avec sshd

Aujourd'hui la suite tant attendue d'une série sur lvm.

Figurez-vous qu'il est possible de faire du raid avec LVM. Hé oui, vous avez déjà remarqué que vous pouviez mettre plusieurs disque dans un vg. Pour l'instant lvm se contente de les mettre bout à bout, comme le ferait un raid de type linear.

Striping

Le raid0 aussi appelé striping découpe un disque en petits morceaux et les alterne pour en faire un disque plus gros. Le but est d'avoir un disque plus gros, mais aussi d'augmenter les performances. En effet, dès qu'on va lire ou écrire un fichier un peu plus gros que ces morceaux, on va le faire sur 2 disques simultanément et donc augmenter la bande passante.

Lorsqu'on répartit les données linéairement sur le disque on ne gagne pas en performances, par contre en cas de crash d'un des deux disques, il y a moyen de récupérer presque la moitié des données, alors que dans le cas du striping, vous êtes sur de ne rien pouvoir récupérer.

Pour faire du striping avec lvm, rien de plus simple. Lors de la création de votre LV, il suffit de préciser le nombre de "stripes" qu'on désire :

# 2 etant le nombre de partition sur lesquels découper le volume
$ lvcreate -L 1G -i 2 lv0 vg0

Notez que si vous voulez forcer le striping sur certaines partitions, il est possible de donner en paramètre à lvcreate la liste des pv sur lesquels vous voulez qu'il soit.

Et pour vérifier que c'est bien ce que vous vouliez :

$ lvdisplay -m /dev/vg0/lv0

Miroir

Le raid1 aussi appelé "mirroring" recopie intégralement un disque sur un autre pour permettre une récupération sans soucis lorsqu'un des deux disques grille, au coût d'un disque supplémentaire.

Alors lvm permet aussi de faire ce genre de chose tout aussi simplement :

# 1 correspond au nombre de copies du volume
$ lvcreate -m 1 -L 1G lv0 vg0

Les miroirs lvm diffèrent du raid1 du fait que lvm demande un périphérique supplémentaire pour stocker les logs du miroir. C'est grâce à ces logs qu'il sait quel est l'endroit qui pose problème lorsqu'il y en a un. C'est donc un peu plus exigeant qu'un raid1.

Et pour vérifier que c'est bien ce que vous vouliez :

$ lvdisplay -m /dev/vg0/lv0

Si vous avez aimé, il y a aussi :

1. Raid 10 ou raid 0+1 ?
2. Que faire et ne pas faire en raid
3. La Vraie Magie

Avançons encore un peu dans notre exploration de lvm. LVM permet beaucoup de choses, et entre autre la création de snapshots. Un snapshot c'est une prise de vue instantanée, qui dans le cas de lvm se fait au niveau du disque. Ce qui veut dire que le contenu du snapshot peut ne pas être cohérent, par exemple si le système est en train d'écrire sur le disque en plein milieu du snapshot.

On peut utiliser les snapshot pour beaucoup de choses, par exemple, Apple l'utilise pour faire sa machine à remonter dans le temps, on peut l'utiliser pour faire des backup cohérents mais aussi pour faire des expérimentations avec des retours arrière rapide.

Un snapshot

Partons d'un lv existant avec un vg sur lequel il reste de la place (hé oui, il faudra bien stocker nos snapshots. Faisons un snapshot de notre lv :

$ lvcreate -L 50M -s -n snap /dev/vg0/original

Et voila, c'est tout, fin de l'article !

Bon, pas encore. Déjà, pourquoi donner une taille au snapshot ? Tout simplement parce que celui-ci est intelligent, donc il ne va pas copier l'intégralité du lv original. Au contraire, il ne va stocker que les différences. C'est pourquoi il est instantané et commence avec une occupation taille nulle. Par contre, il faut lui allouer une taille dans le vg, donc 50Mo sera la quantité maximum de différence qu'il pourra stocker. Au delà de cette taille, le snapshot sera cassé et il ne pourra plus fonctionner correctement (les données ne sont plus valides, laissez tomber).

C'est pourquoi il faut faire attention à bien dimensionner ses snapshots et les gérer correctement. Après quelque quelque temps, vous verrez l'occupation du lv augmenter avec la commande lvdisplay :

$ lvdisplay /dev/vg0/snap
...
  Allocated to snapshot  26,27% 
...

Votre snapshot est occupé à 26%, vous avez encore un peu de marge. C'est à vous de monitorer cette valeur et de prendre une décision, soit supprimer le snapshot (lvremove) ou d'augmenter la place allouée au snapshot (lvextend).

Une fois le snapshot cassé, vous avez ce genre d'information :

$ lvdisplay /dev/vg0/snap
...
  LV snapshot status     source of
                         /dev/vg0/original [INACTIVE]
...

Backup

Donc la technique pour faire un backup est simple, seul problème, si la machine a besoin du système de fichier pendant le snapshot. La meilleure méthode serait de faire "umount;lvcreate -s;mount", mais on ne peut pas. On va donc avoir de préférence un système de fichier qui résiste au crash (ext3 par exemple) et limiter la casse avec sync :

$ sync
# on espère qu'il y aura le moins d'écriture possible entre ces 2 commandes
$ lvcreate -s -L 500M -s -n backup /dev/vg0/original

# et maintenant on a une durée de 500Mo d'écriture pour faire tranquillement notre backup
$ mount /dev/vg0/backup /mnt
$ tar cfz /backups/today.tgz /mnt # c'est vous qui voyez
$ umount /mnt
$ lvremove /dev/vg0/backup

Annulation

Maintenant supposons que nous voulions nous amuser avec notre système de fichier (par exemple pour tester un passage à la prochaine debian sans pour autant avoir peur de tout perdre. Sur / ça risque d'être un peu difficile. Pour ne pas vous perturber nous allons simplifier en utilisant le / d'une machine virtuelle (ou d'un chroot).

$ sync
# choisissez une grande taille, voire la même taille que la partition originale pour éviter tout problème
$ lvcreate -L 5G -s -n backup /dev/vg0/root
# pas besoin de monter le backup
# on bidouille
$ vi /etc/apt/sources.list && apt-get update && apt-get dist-upgrade

Et là paf c'est cassé, réparons (avec un noyau <= 2.6.27):

# on va le casser
$ umount /dev/vg0/root

# on récupère le backup dans un espace temporaire
$ dd if=/dev/vg0/bakup of=/srv/temp.dd

# et on le restaure sur le lv d'origine
$ lvremove /dev/vg0/bakup
$ dd if=/srv/temp.dd of=/dev/vg0/root

# fin
$ rm /srv/temp.dd
$ mount /dev/vg0/root

Le problème de cette technique est qu'elle nécessite un espace aussi gros que la partition disponible pour la restauration. Un petit gzip bien placé peut vous faire gagner en place, mais c'est pas top. Mais ... un patch est en cours pour permettre de faire tout ça en une seule commande et sans nécessiter d'espace intermédiaire. Il ne devrait malheureusement pas être disponible dans le noyau avant la version 2.6.28

# noyau > 2.6.27
$ lvconvert -M bakcup --nameorigin

Lire l'annonce pour plus de détails.

Deux snapshots

Remarquez que de même, il n'est pas possible de faire le snapshot d'un snapshot. C'est bien dommage car cela empêche de faire des tests sur un arbre de test et de revenir à l'endroit ou l'on veut. Ce genre de fonctionnalité n'est pas encore prévue. Il va donc falloir le faire soi-même, ou alors atendre la sortie de btrfs qui devrait permettre ce genre de chose directement sur le système de fichiers..

Donc en attendant, les commandes qui permettent de faire ça en utilisant des copies complètes :

# on snapshotte l'original
$ lvcreate -L 50M -s -n v1x /dev/vg0/v0

# on copie le snapshot (vérifier la taille)
$ lvcreate -L 5G -n v1 vg0
$ dd if=/dev/vg0/v1x of=/dev/vg0/v1
$ lvremove /dev/vg0/v1x

# et on peut resnapshotter
$ vcreate -L 500M -s -n v2 /dev/vg0/v1

Si vous avez aimé, il y a aussi :

1. Snapshot de snapshot
2. LaVoMatic
3. La Vraie Magie