C'est Noël ! Dommage que mes congés soient terminés...

Exploiter les résultats de l'audit

Dans le premier article j'ai mentionné très succinctement une commande qui permet de lire les logs d'audit en temps réel. Et finalement la consultation de ces logs est sans doute la chose la plus intéressante. Personne n'a envie d'activer l'audit sur une machine pour le simple plaisir de remplir son disque dur. Tout ceci doit avoir une raison d'être : pouvoir ensuite (ou en temps réel) exploiter les logs d'auditd.
Comme précisé par défaut dans le fichier audit_control, la taille maximale d'un fichier de log d'audit est 2Mo, et les anciens fichiers sont supprimés pour que le volume total ne dépasse pas 10 Mo :

filesz:2M
expire-after:10M

Il existe plusieurs options intéressantes pour expire-after que je vous laisse découvrir dans le man audit_control. Sachez seulement qu'en fonction de ce que vous choisirez de surveiller, vous allez devoir modifier ces paramètres. Sur une machine assez sollicitée, 10 Mo de log peuvent représenter moins d'une heure d'audit. Si vous avez besoin d'enquêter sur un événement de la veille, il vous sera alors impossible d'en retrouver la trace.

Il y a deux moyens immédiats d'exploiter les logs d'audit. Vous pouvez soit les suivre en direct comme je l'ai montré dans le premier article via la commande praudit /dev/auditpipe, soit les étudier a posteriori. C'est sans doute cette option qui sera le plus souvent utilisée. Vous pouvez ainsi utiliser praudit pour lire les fichiers de logs enregistrés dans /var/audit/.
Comme les logs d'audit peuvent grossir très vite, et qu'on cherche souvent l'aiguille dans la meule de foin, il est bon de pouvoir réduire les logs à ce que l'on cherche avant de les afficher. C'est le rôle de la commande auditreduce. Cette commande permet de filtrer les logs selon une série de critères tels que la date, le ou les flags d'évènement (fc, ex, ...), l'UID, le ou les évènements précis (tels qu'ils sont répertoriés dans le fichier audit_event), et d'autres encore.
auditreduce s'utilise sous la forme générale suivante :

auditreduce paramètres fichiers_de_log | praudit

Comme les logs sont binaires, il est impératif de les traduire via praudit.
Sur Mac OS X, voici un exemple de ce que l'on peut obtenir avec la configuration par défaut d'auditd. Je cherche ici tous les événements pour l'UID réelle patpro ayant eu lieu après le 5 juin 2011 à 12h. Je fais cette recherche dans le fichier de log ouvert par auditd.

# auditreduce -a 2011060512 -r patpro /var/audit/current | praudit
header,68,11,logout - local,0,Sun Jun  5 15:47:35 2011, + 877 msec
subject,patpro,root,patpro,patpro,patpro,10485,10485,0,0.0.0.0
return,success,0
trailer,68
header,68,11,logout - local,0,Sun Jun  5 15:57:05 2011, + 718 msec
subject,patpro,root,patpro,patpro,patpro,10948,10948,0,0.0.0.0
return,success,0
trailer,68

Ces deux évènements correspondent à la fermeture d'une fenêtre de terminal. On voit que chacun d'eux commence par "header" et termine par "trailer". Je ne vais pas couvrir l'intégralité des champs d'un enregistrement de log d'audit, il y a beaucoup trop de possibilités. Reportez-vous au man audit.log pour le détail. Ceux qui ont un intérêt sinon universel, au moins relativement général, sont subject qui décrit le sujet qui a généré les évènements, path qui décrit le chemin du fichier concerné, et return qui indique si l'opération a réussi ou non.
Le champ subject contient les UID et GID (audit UID, effective UID et GID, real UID et GID), le PID, et le port et l'IP de la machine connectée.
Le champ path donne par exemple le chemin d'un exécutable lancé, ou le chemin d'un fichier créé/modifié/détruit.
Le champ return indique success ou failure.

Voici un second exemple, pour un serveur Apache sur Mac OS X, lancé via l'utilitaire setaudit :

header,127,11,execve(2),0,Wed Jun  1 14:50:44 2011, + 667 msec
exec arg,ls
path,/bin/ls
path,/bin/ls
attribute,100555,root,wheel,234881026,24767,0
subject,_www,_www,_www,_www,_www,26696,100031,0,0.0.0.0
return,success,0
trailer,127
header,131,11,open(2) - write,creat,trunc,0,Wed Jun  1 14:50:44 2011, + 735 msec
argument,3,0x1a4,mode
argument,2,0x601,flags
path,/Users/patpro/Sites/testFile.txt
subject,_www,_www,_www,_www,_www,26694,100031,0,0.0.0.0
return,failure : Permission denied,4294967295
trailer,131

La requête http s'est faite sur la machine locale (http://localhost/...) vers un fichier PHP dont le code exécute la commande system("ls"); puis tente d'écrire un fichier testFile.txt.
Le premier évènement enregistré montre le lancement de la commande ls, avec succès. Le second évènement montre la tentative d'écriture du fichier testFile.txt qui échoue.
Cet exemple montre donc clairement comment les logs d'audit peuvent permettre, par exemple, de remonter la trace d'une compromission d'un serveur web. Notez que si j'avais lancé le serveur web normalement, sans utiliser setaudit, la ligne subject aurait indiqué subject,patpro,_www,_www,_www,_www..., patpro étant l'UID suivi par auditd. Il aurait donc fallu que le fichier audit_user indique les flags ex et fc pour le login patpro, sans quoi les évènements pour le serveur web n'auraient pas été enregistrés.

auditreduce permet de filtrer les évènements selon un critère beaucoup plus fin que le simple flag (fc, fd, ex, ...). Il vous autorise à différencier chaque évènement avec la granularité du fichier audit_event. Si vous avez eu la curiosité d'ouvrir ce fichier, vous savez qu'il contient plus de 600 lignes de ce genre :

0:AUE_NULL:indir system call:no
1:AUE_EXIT:exit(2):pc
2:AUE_FORK:fork(2):pc
3:AUE_OPEN:open(2) - attr only:fa
4:AUE_CREAT:creat(2):fc
5:AUE_LINK:link(2):fc
6:AUE_UNLINK:unlink(2):fd
7:AUE_EXEC:exec(2):pc,ex
8:AUE_CHDIR:chdir(2):pc
9:AUE_MKNOD:mknod(2):fc

La nomenclature est simple. Chaque colonne est séparée des autres par ":". La première donne le numéro de référence d'un événement, la seconde donne son nom, la troisième le nom de la fonction correspondante, avec éventuellement un complément d'information, et la dernière indique le ou les flags correspondants.
Sur les 10 lignes citées au dessus, vous notez qu'il y a déjà 4 évènements correspondants au flag pc, et 3 au flag fc. Donc si on se contente de faire un filtrage sur pc ou fc, on peut remontrer beaucoup trop d'évènements par rapport à ce que l'on cherche vraiment. Par ailleurs, dans certains cas, un même évènement peut correspondre à plusieurs flags contradictoires. Par exemple :

75:AUE_OPEN_RTC:open(2) - read,creat,trunc:fc,fd,fr,fa,fm

Cet évènement peut être détecté si on souhaite suivre les flags fc, fd, fr, fa ou fm !
C'est ici qu'intervient le contenu de la ligne header des logs d'audit. En effet, l'entête indique clairement l'évènement qui est capturé. Par exemple open(2) - write,creat,trunc. Il suffit alors de chercher son nom dans le fichier audit_event pour pouvoir s'en servir de clé de filtrage :

grep 'open(2) - write,creat,trunc' /etc/security/audit_event
79:AUE_OPEN_WTC:open(2) - write,creat,trunc:fc,fd,fw,fa,fm

Il est alors possible d'utiliser AUE_OPEN_WTC comme ceci pour obtenir en sortie une sélection parfaite des évènements qu'on recherche :

auditreduce -m AUE_OPEN_WTC -r www -o file=".*/bd/.*" /var/audit/current | praudit

Cette commande permet de trouver tous les évènements AUE_OPEN_WTC pour l'utilisateur www qui ont eu pour cible des fichiers dont le chemin contient la chaîne "/bd/" dans le fichier de log d'audit courant.
Il ne vous reste plus qu'à essayer par vous même !

Bibliographie sommaire

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit-config.html
https://ssl.apple.com/support/security/commoncriteria/CommonCriteriaAdminGuide.pdf
man auditreduce
man auditd
man audit_user
man audit_control
man audit_event
man audit.log
http://forums.freebsd.org/showthread.php?t=23716

Configuration : quid des utilisateurs comme www ?

J'expliquais précédemment que le système d'audit ne peut suivre un utilisateur que si ce dernier se connecte à la machine (par ssh par exemple), et que quelques soient les ruses utilisées (su, sudo...) c'est toujours l'UID réelle de l'utilisateur qui est suivie.

À cause de cela, il est totalement impossible de traquer des évènements appartenant à des utilisateurs qui ne peuvent pas se connecter au système. Ainsi, une ligne comme celle-ci dans audit_user ne permettra de traquer aucun évènement :

# pour freebsd remplacer _www par www
_www:fc,fd,ex:

Il serait pourtant très intéressant de savoir ce que fait Apache dans votre dos, parfois sous la direction de méchants pirates.
De nos jours, La plupart des serveurs utilisent des protocoles comme l'HTTP qui permettent aux utilisateurs d'accéder aux ressources sans être authentifiés au niveau du système. Les utilisateurs en question n'existent d'ailleurs pas au niveau du système. Néanmoins, les applications web permettent de faire énormément de choses via les langages comme le PHP, y compris d'interagir avec le système, en lançant des commandes, en créant des fichiers, etc.

Si on souhaite qu'auditd puisse contrôler les actions de www, il faut recourir à un artifice. Attention tout de même, ce qui suit est plus proche d'un hack que d'une méthode vraiment propre, et je ne peux pas garantir son fonctionnement correct dans un environnement de production.

En premier lieu il faut installer un programme spécifique, qui va permettre de forcer auditd à suivre les actions pour une UID donnée, sans que l'utilisateur correspondant ait besoin de se connecter à la machine.

curl -LO http://www.freebsd.org/~csjp/setaudit.c
cc -o setaudit -lbsm setaudit.c 

Cela vous donne, si tout se passe bien, le binaire setaudit, que l'on va utiliser sous cette forme :

setaudit -a UID_WWW -m FLAGS /programme/de/lancement/d/apache

Pour suivre les évènements d'exécution de commande sous respectivement FreeBSD et Mac OS X, cela donnera :

setaudit -a www -m ex /usr/local/etc/rc.d/apache22 restart
setaudit -a _www -m ex /usr/sbin/apachectl restart

Ainsi, toutes les commandes lancées par Apache (donc sous l'UID www) sont enregistrées par auditd.
Comme le masque des évènements (les flags de l'argument -m) décrit ce que l'on doit suivre, il est même inutile de renseigner le fichier audit_user.

Pour résumer :

• Si vous souhaitez que l'audit suive les utilisateurs qui se connectent à la machine, vous pouvez régler les classes d'évènements qui seront soumises à l'audit pour l'ensemble des utilisateurs dans le fichier audit_control, et gérer les cas particuliers dans audit_user.
• Si vous souhaitez que l'audit suive des UID "interne", pour traquer tout signe de compromission sur un serveur web, un serveur de mail, etc. il faudra recourir à setaudit pour activer l'audit au moment du lancement du service correspondant.
• Faites attention à la liste de flags que vous choisissez. Le volume des logs d'audit peut grossir très rapidement.

Troisième partie de l'article ->

Activation du système d'audit
Configuration
Configuration : quid des utilisateurs comme www ?
Exploiter les résultats de l'audit

Activation du système d'audit

Sous FreeBSD 7 et 8, le noyau est déjà compilé avec options AUDIT, il ne reste donc qu'à lancer le démon auditd en ajoutant la ligne suivante au fichier /etc/rc.conf :

auditd_enable="YES"

puis en lançant le démon à la main :

sudo /etc/rc.d/auditd start

Sous Mac OS X 10.6, auditd est lancé d'office par launchd, il n'y a rien à faire.

Configuration

Une fois lancé, le système d'audit va enregistrer très peu d'évènements par défaut. Il convient donc de faire quelques réglages en fonction de ce que l'on cherche à accomplir.
Les fichiers de configuration d'auditd se trouvent dans le répertoire /etc/security où seul root peut écrire.

• audit_class : décrit les différentes classes d'évènements qu'il est possible de surveiller. Il est sage de ne pas éditer ce fichier.
• audit_control : lisible seulement par root, ce fichier défini la politique d'audit par défaut.
• audit_event : le grand frère de audit_class, on ne le modifie pas.
• audit_user : le fichier de réglages par utilisateur. Il complète audit_control et n'est lisible que par root.
• audit_warn : un fichier exécutable qui est lancé quand auditd manque de place sur le disque pour écrire les logs.

Pour un usage courant, seuls les fichiers audit_control et audit_user sont intéressants. La première chose à faire est d'aller lire leur page man respective.

Par défaut, le contenu du fichier audit_control est le suivant :

dir:/var/audit
flags:lo,aa
minfree:5
naflags:lo,aa
policy:cnt,argv
filesz:2M
expire-after:10M

Avec ces valeurs, auditd ne va répertorier que les évènements des classes "lo" (login/logout) et "aa" (authentification/autorisation). Et il va le faire pour l'ensemble des utilisateurs.
Attention : après avoir lu le man audit_control, vous serez peut être tenté d'ajouter le champs "host" pour compléter la configuration. N'en faites rien. Cela peut perturber les outils utilisateur et rendre l'exploitation des résultats hasardeuse, voire impossible.
Le contenu de audit_user quant à lui nous permet de préciser des flags en se basant sur le login des utilisateurs. Par défaut, le fichier audit_user contient :

root:lo:no

C'est à dire que, quelque soit la liste des flags audit_control, les évènements de la classe "lo" seront suivis pour l'utilisateur root, et les évènements de la classe "no" (invalides) ne seront jamais suivis.
Vous pouvez immédiatement vérifier que votre système d'audit fonctionne en lisant en direct les évènements qu'il enregistre. Il suffit pour cela de taper la commande suivante en root (ou via sudo) :

# praudit /dev/auditpipe

Utilisez alors une autre fenêtre de terminal pour gérer des traces. Sous Mac OS X vous pouvez faire un sudo, ou simplement fermer la fenêtre de terminal, par exemple. Vous pourrez alors lire des choses comme cela :

header,104,11,user authentication,0,Wed Jun  1 14:53:39 2011, + 965 msec
subject,root,root,wheel,root,wheel,26712,0,0,0.0.0.0
text,Authentication for user <patpro>
return,success,0
trailer,104
header,68,11,logout - local,0,Wed Jun  1 15:36:12 2011, + 554 msec
subject,patpro,root,patpro,patpro,patpro,28079,28079,0,0.0.0.0
return,success,0
trailer,68

Nous en reparlerons dans le dernier article de la série.

Faites bien attention aux flags que vous allez régler. Dans certains cas, le nombre d'évènements enregistrés par le système d'audit peut être extrêmement élevé. Par défaut peu de choses sont soumises à l'audit, si bien qu'en 18 mois sur une station de travail, le contenu de /var/audit représente moins de 10 Mo. A contrario, sur un serveur web assez actif, où les classes d'audit sont "fd,^fc,ex:no,fc", on dépasse les 43 Mo en a peine 4 heures d'audit.

Il faut bien comprendre que l'activation de l'audit pour un utilisateur ne se produit qu'au moment de la première connexion de l'utilisateur au système. Prenons un exemple. Le fichier audit_user contient :

root:lo:no
patpro:fc,fd,ex:

Donc pour l'utilisateur patpro, les créations, ouvertures, suppression de fichier, ou exécutions de programmes doivent être suivis. Cet utilisateur a une crontab qui tourne toutes les nuits et télécharge un fichier. Pourtant, auditd ne capturera aucun de ces évènements tant que l'utilisateur patpro ne se sera pas connecté à la machine, alors même que de nombreux évènements correspondants aux critères de l'audit se produisent.
Dès que l'utilisateur patpro se sera connecté à la machine, auditd se mettra à enregistrer toutes les actions correspondant aux classes fc, fd et ex exécutées sous l'UID patpro. Cet audit se poursuivra même après la déconnexion de l'utilisateur.
Par ailleurs, l'UID qui est traquée par auditd n'est pas l'UID apparente, mais l'UID d'origine de l'utilisateur. Si je me connecte en tant que patpro, et que je fais un su - ou un sudo -Es, je deviens root dans le shell (UID apparente), mais je reste patpro aux yeux d'auditd.
Nous verrons dans un second article pourquoi ces deux contraintes sont importantes. D'ici là, vous pouvez approfondir les aspects simples de la configuration en lisant ces différents documents :

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit-config.html
https://ssl.apple.com/support/security/commoncriteria/CommonCriteriaAdminGuide.pdf

Deuxième partie ->

Quand vous avez un millier de chaînes de caractères, dont vous souhaitez retrouver toutes les occurrences dans un gros fichier de 685000 lignes, vous pouvez utiliser grep de deux manières :

1. vous dites à votre ami grep de chercher toutes les chaînes en même temps dans le gros fichier,
2. vous utilisez une boucle pour dire à grep de chercher une chaîne dans le fichier, puis de passer à la chaîne suivante, …

La solution 1 semble la plus intéressante. Une seule commande, pas de boucle, on se dit naturellement que c'est plus économique, et donc plus rapide. La solution 2, on se dit qu'elle est moche, complexe, et que les performances vont être mauvaises.

Petit test grandeur nature sur un serveur FreeBSD 7.x virtualisé, 2 CPU, 2Go de RAM :

Méthode 1 :
grep -i -f liste_emails maillog
opération terminée en 370 min environ.
Méthode 2 :
while read email; do grep -i $email maillog ; done<liste_emails
opération terminée en 1 min 32 s.

Bien sûr, le résultat est le même en terme de contenu, la seule différence est l'ordre des lignes. La méthode moche et supposée lente est juste 240 fois plus rapide que la méthode académique. Shame on you grep. Shame on you.

L'environnement est aussi important. On pourrait se dire qu'avec plus de CPU (en puissance, pas en nombre), plus de RAM, tout irait tellement plus vite. Essayons la même chose sur un Mac Pro Xeon quad-core, avec 12 Go de RAM, sous Mac OS X 10.6.

Méthode 1 : 223 min.
Méthode 2 : 35 min 45 s.

Ce qui prouve une fois de plus que Mac OS X est un gros tromblon quand il s'agit de fork. Comprendre que le coût du lancement d'un programme, en terme de ressources système, est beaucoup plus fort que sur d'autres OS, comme FreeBSD par exemple. Ce qui fait de Mac OS X un très mauvais candidat pour les scripts shell utilisant des boucles de manière très intensive.
On voit aussi que la vitesse d'exécution de la méthode 1 est essentiellement liée à la puissance de calcul du CPU, alors que la vitesse de la méthode 2 est essentiellement liée à la capacité du système d'exploitation de créer des process rapidement.

Pour conclure, j'ai fait un petit test avec awk, sur les mêmes fichiers. Moyennant quelques aménagements triviaux pour transformer le fichier liste_emails en programme awk, j'ai pu lancer la commande awk -f liste_emails maillog qui est l'équivalent de la méthode 1 pour grep. Le temps d'exécution est tombé à moins de 15 minutes sur Mac OS X, et moins de 30 minutes sur le FreeBSD.

* ceux qui ont fait 5 ans d'études dans une autre branche, avant de passer à l'informatique, par exemple.

 1: #!/bin/bash
 2: case $1 in
 3: 	[1-9])
 4: 		find_args="-mtime -$1"
 5: 		;;
 6: 	*)
 7: 		find_args=""
 8: 		;;
 9: esac
10:
11: for XML in $(find . $find_args -name "IMG_*xmp"); do
12: 	rating=$(awk '/xap:Rating/ {gsub(/ *<[^>]*>/,"",$0); print $0}' "$XML")
13: 	[ -f "${XML/xmp/CR2}" ] && \
14: 	xattr -w "com.apple.metadata:kMDItemStarRating" $rating "${XML/xmp/CR2}"
15: done

Téléchargez le script push_img_ratings.sh (Mac OS X uniquement).

Lignes 2 à 9, on teste le premier argument du script, si c'est un chiffre entre 1 et 9 il sera utilisé pour limiter la plage de recherche. Le seul but de cette première partie, est de pouvoir limiter l'impact du script aux photos récemment notées. Cela permet de ne pas re-noter l'intégralité de sa collection de photos, ce qui peut être assez long si vous avez des disques durs lents et de très nombreux fichiers.
À la ligne 11, on crée une boucle qui utilisera comme argument la liste des fichiers retournée par la commande find. Il s'agit ici de trouver tous les fichiers du répertoire courant et des répertoires inclus, dont le nom commence par "IMG_" et termine par "xmp", et dont la date de modification est dans les $1 dernières 24 heures si $1 est entre 1 et 9.
Pour chaque fichier trouvé, on extrait la note de la photo (ligne 12), et si le fichier RAW correspondant au fichier XMP existe, alors on écrit dans ses métadonnées la note extraite (lignes 13 et 14).
Ce script est aisément modifiable pour fonctionner avec des fichiers RAW d'autres appareils (NEF pour Nikon par exemple). Il nécessite par contre que Bridge soit configuré pour stocker les métadonnées dans un fichier indépendant, et non dans le fichier RAW lui-même.

Il vous suffit ensuite de lancer ce script sur l'ensemble de votre photothèque pour propager votre notation "Bridge" dans les métadonnées Spotlight. Si vous souhaitez recopier les notes attribuées dans les dernières 24h uniquement, lancez le script avec comme seul argument le chiffre 1 :

$ cd Pictures/2011_03_16
$ push_img_rating.sh 1

Vous pouvez aussi bien lancer push_img_rating.sh 1 tous les jours automatiquement grâce à launchd, sous réserve de préciser le chemin de recherche pour la commande find (ligne 11).

1. Connectez-vous à la machine en SSH, via un compte admin (ben oui, il y a quand même quelques pré-requis)
2. Tapez les commandes suivantes : sudo -s puis echo "enabled">/etc/ScreenSharing.launchd

C'est fini. Le partage d'écran est activé sur ce Mac.

Pour faire un benchmark L4D2 sur PC ou Mac, il faut procéder à plusieurs manipulations que je ne vais pas détailler. Sachez juste qu'il faut activer la console développeur dans les préférences du jeu. Grace à cette console, vous allez pouvoir enregistrer une "demo", c'est à dire le script d'une partie. Ensuite il faut rejouer ce script avec différents réglages vidéo, et enregistrer le nombre d'images par seconde que votre machine génère pendant le rendu vidéo de cette "demo". C'est long et fastidieux, et il est impossible (et stupide) de tester tous les réglages vidéo. Si j'avais voulu faire une mesure pour chaque combinaison de réglages, sans changer la résolution, il aurait fallu que je fasse 2700 rendus de ma partie enregistrée.

J'ai donc pris le parti de lancer 5 fois la partie enregistrée, toujours dans la même résolution (1920x1200), et toujours avec les paramètres "effects" et "model" au maximum.

Voici le résultat sous la forme d'un graphique :

En rouge, est représenté le pourcentage d'images qui sont calculées à la vitesse de 60 images par seconde ou plus. Donc plus la proportion de rouge est grande, plus la carte video calcule vite le rendu de la partie. Et plus la proportion de vert et de bleu est faible, moins vous avez de ralentissements perceptibles dans le rafraîchissement de l'image. Ici le bleu (moins de 20 fps) est totalement absent.
Le jeu est capable d'afficher des chiffres de FPS ("frame per second") supérieurs à 60, mais le système intégré qui enregistre la répartition des FPS considère qu'à partir de 60 images par seconde il n'est plus utile de donner la répartition des FPS.
Ce n'est pas gênant, car in fine, les écrans actuels sont assez limités en terme de rafraîchissement, et que 60 images par seconde, c'est suffisant pour un affichage stéréoscopique à 30 images par seconde pour chaque œil. Donc à partir de 60 FPS, même un joueur exigeant pourrait jouer avec des lunettes 3D confortablement.

On voit sur ce graphique qu'un réglage a énormément d'impact sur le nombre de FPS : la synchronisation verticale. Si la synchronisation verticale est activée, le jeu ne peut pas dépasser 60 images par secondes, et le nombre global de FPS est sensiblement réduit. Mais ce réglage garanti une certaine cohérence de l'affichage et prévient l'apparition d'artefacts graphiques qui peuvent dénaturer l'expérience du joueur. Si votre machine le permet, laissez la synchronisation verticale activée. Les réglages 3 et 4 montrent l'impact de la désactivation de cette synchronisation sur la répartition des FPS.

Je ne vais pas plus loin dans l'analyse, il est aisé de comparer chaque jeu de réglages en utilisant le graphique. Si vous souhaitez faire le même benchmark que moi exactement, il vous faut le script de la partie que j'ai enregistré (ZIP 3,6Mo). La partie dure environ 10 minutes. L'archive contient un fichier parish000.dem qui est le script de la partie, et un fichier parish000.vdm qui est un fichier texte contenant les commandes qui lancent l'enregistrement des FPS au début du rendu, et qui arrêtent l'enregistrement à la fin du rendu. Il faut placer ces deux fichiers dans /left 4 dead 2/left4dead2 (je ne donne pas le chemin complet il est différent sur Mac OS X et Windows).
Après avoir joué la partie sur votre machine, vous obtiendrez un fichier prof_c5m4_quarter.csv situé dans /left 4 dead 2/update/. Attention, ce fichier est écrasé à chaque lancement de la "demo".
Je vous renvoie vers les forums et les aides en ligne pour tous les détails techniques (comment lancer une "demo", etc.).

Addendum

À titre de comparaison, voici le même benchmark effectué sur un MacBook Pro (un portable donc), doté d'un Core Duo 2,8 GHz, de 8 Go de RAM DDR3, et d'une carte vidéo GeForce 9600M GT. La résolution est native : 1440x900. J'ai tenté de faire le test avec les réglages vidéo "recommandés" par le jeu, l'écriture du fichier de log des FPS a échoué, mais les résultats étaient de toute manière catastrophiques.

À gauche, un jeu de réglages "tout medium" avec antialiasing et filtering au minimum. Au centre, les mêmes réglages mais avec la synchronisation verticale désactivée. Enfin à droite le jeu de réglages "recommandés" par L4D2, mais avec la synchronisation verticale désactivée. Le résultat reste injouable, avec presque 75% des frames générées à moins de 20 fps.

Dans mon PowerMac G5, j'ai deux disques durs de 640 Go. Un pour travailler, et un pour les sauvegardes. Dans mon Mac Pro, j'ai un disque dur de 1 To, et trois emplacements libres.

J'ai décidé de :

• réinstaller un système personnalisé sur le Mac Pro (donc de reformater le disque fourni)
• monter les deux disques du G5 dans le Mac Pro, pour en récupérer les données
• poursuivre les sauvegardes Time Machine sur le Mac Pro, sans perdre l'historique du G5 (c'est le point le plus délicat)

Au cours de ce processus, l'ancien disque système du G5 va devenir le nouveau disque Time Machine du Mac Pro, et l'ancien disque Time Machine du G5 va devenir un disque de stockage de l'ancien système, le temps de terminer la migration.
Attention, si comme moi vous possédez une licence Adobe (genre CS3/4/5) n'oubliez pas au préalable de la désactiver sur votre ancienne machine, avant de démarrer votre migration.

Voici comment j'ai procédé :

1. Démontage des disques du G5, et remontage dans le Mac Pro
2. Démarrage du Mac Pro sur le DVD d'installation, formatage du disque système, installation personnalisée du système
3. Récupération des données de mon compte utilisateur (et uniquement celles là) via l'assistant de migration. Ici, il est très important de savoir que les dossiers que vous aviez exclus de la sauvegarde Time Machine ne sont pas récupérés par l'assistant de migration, alors même qu'on les récupère à partir de l'ancien disque système, et pas de l'ancien disque Time Machine !
4. À ce stade, vous pouvez lancer les mises à jour de votre système, et désactiver Spotlight pour les deux disques provenant du G5
5. Création d'une image disque compressée de mon ancien disque système (prévoir plus d'une heure), montage de l'image disque pour vérifier qu'elle est utilisable (la première que j'ai faite n'était pas fonctionnelle)
6. Formatage de ce disque avec une table de partition GUID
7. Restauration de l'ancien disque Time Machine, vers le disque fraîchement formaté (compter aussi plus d'une heure) en utilisant l'utilitaire de disque
8. Formatage de l'ancien disque Time Machine avec une table de partition GUID
9. Comme l'adresse MAC de la machine a changé, il faut bricoler un peu la sauvegarde Time Machine pour pouvoir continuer à utiliser l'ancien historique. Cela nécessite d'utiliser une commande UNIX qui était fournie avec Mac OS X 10.5, mais qui n'est plus fournie avec Mac OS X 10.6. Cela tombe bien, car nous avons toujours l'ancien disque système (sous forme d'image disque)
10. Montage de l'image de l'ancien disque système
11. Lancement de l'utilitaire Terminal, et application de la méthode suivante ; Attention, fsaclctl n'existe pas en 10.6, il faut indiquer le chemin dans votre image disque (par exemple /Volumes/image_ancien_os/usr/sbin/fsaclctl )
12. Restauration de l'image disque de l'ancien système vers l'ancien disque Time Machine
13. À ce stade, j'ai un disque système à jour dans mon Mac Pro, un disque Time Machine opérationnel, formaté en GUID, et contenant l'historique du G5 et dans la continuité, l'historique du Mac Pro. J'ai un troisième disque dur, contenant mon ancien système, pour récupérer des documents et applications manuellement en cas de besoin
14. Édition des options de Time Machine, pour ne pas sauvegarder n'importe quoi
15. Réinstallation des applications tierces

Si vous suivez cette méthode, il vous appartient ensuite de faire le ménage dans votre ancien système pour gagner un peu de place, d'y récupérer ce que vous souhaitez et qui n'aurait pas été restauré, etc. Gardez à l'esprit que ce n'est pas une méthode universelle. C'est plus un canevas sur le quel vous pouvez broder votre propre migration, en retenant ce qui vous intéresse, en écartant ce qui ne vous convient pas, et en découvrant des choses aux quelles vous n'aviez pas pensé !

Notez que les manipulations interactives ne sont pas longues, mais des volumes importants de données peuvent amener l'ensemble de l'opération à durer une bonne demi-journée.
La méthode de récupération de l'ancienne sauvegarde Time Machine pour ne pas perdre l'historique peut sembler absconse, mais en réalité elle est logique et simple.

La sauvegarde est une des briques de la sécurité informatique. En tant que telle, elle en hérite deux caractéristiques élémentaires : c'est un compromis, et c'est indispensable.

Les seules variables réelles pour l'utilisateur se trouvent donc au niveau de ce compromis. Sauvegarder des données, cela prend du temps, de la place, éventuellement de la bande passante, c'est contraignant, cela requière de l'attention. Il faut donc faire un compromis entre ce que l'on veut sauvegarder et les moyens qu'on est prêt à mettre en œuvre.

Par exemple, il est très facile de faire une sauvegarde de toutes ses données, mise à jour toutes les heures, avec possibilité de remonter dans le temps sur un an d'historique ou plus. Vous branchez un disque dur sur votre machine, et vous configurez Time Machine (si vous êtes sur Mac, pour les autres plateformes charge à vous de trouver le logiciel équivalent). Les sauvegardes sont alors totalement automatiques.
L'accès aux données est rapide, et très simple. Mais si votre logement est cambriolé, incendié, innondé, ou que votre machine est victime d'un pirate ou d'un gros virus, vous avez toutes les chances de perdre à la fois les données de votre machine et leurs sauvegardes.
Il faut donc éloigner la sauvegarde de l'ordinateur pour assurer la sécurité de vos données. Cela se complique. On peut mettre le disque externe en lieu sûr, mais alors cela oblige à des manipulations entre chaque sauvegarde : sortir le disque de sa cachette, le brancher, sauvegarder, le débrancher, le remettre en lieu sûr... Pénible !
La solution simple est alors de passer par internet, mais c'est lent. Allez donc sauvegarder 200 Go de données via votre ligne ADSL. Et puis d'abord, où allez vous trouver autant de place ? Il faut payer un hébergement spécialisé. On en trouve des pas trop chers, mais contrairement à un disque dur, la dépense est mensuelle.
Tel que je vois les choses, il faut utiliser la sauvegarde locale cumulée à la sauvegarde distante. Plus la sauvegarde est éloignée (et donc pénible d'accès), moins je sauvegarde de données. C'est aussi simple que ça.
La seule réflexion que doit mener l'utilisateur dans ce cas de figure, est la hiérarchisation de ses données. Il doit décider parmi ses données les quelles il est inutile de sauvegarder, les quelles il est utile de sauvegarder, les quelles il est important de sauvegarder, etc.
Pour la sauvegarde locale, on est sur du disque dur. L'accès est performant, c'est de la sauvegarde de confort. On peut y placer toutes les données, même les données peu importantes.
Pour une sauvegarde intermédiaire (sur une autre machine du réseau par exemple), on est en accès relativement rapide, mais moins que le disque local, et on a aussi sans doute un peu moins de place. On va donc omettre les données peu importantes (les gros logiciels installés dont on a le CDROM dans l'étagère, les fichiers volumineux qu'on peut retrouver facilement ailleurs...).
Pour la sauvegarde hors-site (sur un serveur accessible via internet), on sait que l'accès est lent, que l'espace est compté et facturé, on doit donc se limiter à l'essentiel (emails, documents personnels, photos de famille irremplaçables, factures électroniques...).

C'est un fonctionnement en entonoir. Plus la sauvegarde est contraignante (distance, temps d'accès, coût), plus vous la limitez en volume.

À titre d'illustration, voici comment mes sauvegardes "ceinture et bretelles" fonctionnent :

- Dans mon Mac, j'ai un second disque dur qui sert pour Time Machine, j'ai donc une sauvegarde incrémentale sur plus de 2 ans de toutes mes données. Toutes les heures, Time Machine fait une sauvegarde sur ce disque. L'accès est rapide, mais le disque de sauvegarde est dans la même machine que le disque sauvegardé. Le risque de perdre les deux en même temps est maximal.

- Sur mon réseau local, j'ai une seconde machine, avec un disque dur dédié aux sauvegardes. J'ai sur le Mac un script qui se lance tous les deux jours, et qui envoie sur cette seconde machine une partie de ma dernière sauvegarde Time Machine. Cette machine a peu à craindre d'un cambrioleur ou d'un pirate, rien à craindre des virus, mais un sinistre pourrait lui être fatal. L'accès est plus lent qu'un disque local, mais plus rapide que via internet.

- Ensuite, le même script envoie sur un serveur distant, au travers de ma liaison ADSL, un sous-ensemble encore plus petit de ces données. Et ce serveur distant garde l'historique des données une fois par semaine pendant 20 semaines. Je peux donc revenir en arrière de 5 mois sur les données sauvegardées.
Ce serveur est à 400 km, dans un datacenter sécurisé. La probabilité pour que mes deux sauvegardes "maison" et cette sauvegarde distante disparaissent en même temps est nulle.

L'intégralité des trois étapes est bien sûr entièrement automatisée, et tout fonctionne sans intervention humaine. C'est primordial. Si vous utilisez un système de sauvegarde manuelle, vous pouvez être sûr qu'un jour vous oublierez, ou vous vous lasserez.

Pour résumer tout ceci en une ligne : ayez toujours une sauvegarde locale pour votre confort, et une sauvegarde distante pour les données vraiment importantes. Si vous réfléchissez à cela sérieusement, cela vous forcera aussi à considérer l'ensemble de vos habitudes de stockage : qu'est ce que je stocke sur ma machine ? Est-ce vraiment utile de garder tout ça ? Qu'est ce que je peux supprimer ou perdre sans états d'âme ? etc.