MacOSX

1 juin 2011

Utiliser auditd sur Mac OS X et FreeBSD – 2

Cet article est la suite de Utiliser auditd sur Mac OS X et FreeBSD - 1

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

31 mai 2011

Utiliser auditd sur Mac OS X et FreeBSD – 1

FreeBSD et les versions récentes de Mac OS X sont livrées avec un système d'audit intégré, dérivé du Basic Security Module de SUN, et disponible en logiciel libre sous le nom d'OpenBSM. Ce système d'audit se décompose en deux parties : un ensemble d'appels systèmes dédiés et de librairies d'un côté, et des logiciels "utilisateur" de l'autre. Sauf précision contraire, les explications présentées ici sont valables à la fois pour FreeBSD 7 et 8, et Mac OS X 10.6. Dans cette série d'articles je ne vais aborder que l'aspect "utilisateur" du système d'audit : comment l'activer, comment le configurer, comment exploiter les résultats.
Le système d'audit fourni par OpenBSM a pour but la surveillante des actions des utilisateurs. Un certain nombre d'évènements peuvent être mis sous surveillance, pour tout ou partie des utilisateurs. Quand le système d'exploitation détecte qu'un utilisateur sous surveillance génère un des évènements à surveiller, il averti le démon auditd qui se charge de reporter cet évènement dans un fichier de log. Continue reading →

13 mai 2011

Mon ami grep

grep, c'est mon ami. C'est d'ailleurs probablement l'ami de pas mal d'administrateurs système (enfin, les vrais quoi*). De temps en temps, il faut quand même bien vérifier que son ami est au mieux de sa forme, s'enquérir de ses performances, évaluer d'un œil critique si son environnement lui convient bien.

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 :

vous dites à votre ami grep de chercher toutes les chaînes en même temps dans le gros fichier,
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.

16 mars 2011

Noter ses photos, de Bridge à Spotlight

De nombreux photographes utilisent à un moment donné de leur flux de traitement un outil de notation pour trier leurs photos. En général, c'est au moment de l'editing que l'on donne une note à ses dernières photos : on rejette les ratées, on note de 0 à 5 les autres pour ne garder que les meilleurs clichés. Avec un logiciel comme Bridge (ou Photoshop LightRoom), c'est très facile. Néanmoins, la note ainsi attribuée ne remonte pas dans les métadonnées Spotlight (Mac OS X). Il est par exemple impossible dans le Finder de créer un dossier intelligent qui regrouperait toutes les photos notées avec 4 ou 5 étoiles.
Pour remédier à cela on peut utiliser un script shell qui recopie la note assignée par Bridge dans les métadonnées du fichier photographique. En partant du principe que Bridge stocke ses propres métadonnées dans un fichier XMP à côté du fichier RAW, voici un exemple de script qui fait ce travail pour vous :

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

31 janvier 2011

Activer le partage d’écran sur un Mac, à distance

Parfois, on est bêtement coincé par un tout petit problème. Mon dernier problème en date était de pouvoir interagir avec une application graphique, sur un Mac à plusieurs kilomètres de distance. Et bien sûr, je n'avais pas activé au préalable le partage d'écran sur cette machine. Rassurez-vous, ça se fini bien, et ça se règle en quelques secondes. Voici comment faire pour un Mac en 10.5 ou 10.6 :

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

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

30 janvier 2011

Benchmark Left 4 Dead 2, sur Mac Pro

La plupart des "gamers" vous le diront, la bonne machine pour les jeux, c'est celle qui fait tourner Windows. Si on met de coté les consoles de jeux dédiées, ils n'ont pas tort. Comparés à ceux de Mac OS X, les pilotes vidéo Windows sont plus performants, voire dans certains cas vraiment beaucoup plus performants. Les cartes vidéo disponibles sont aussi plus récentes, et les jeux programmés en DirectX sont bien sûr nativement privilégiés, puisque DirectX n'est pas disponible sur Mac OS X.
Ceci posé, j'ai décidé de faire des tests pour déterminer quels réglages vidéo sont les meilleurs pour jouer confortablement à Left 4 Dead 2 sur (mon) Mac. À titre indicatif, il s'agit d'un Mac Pro mono Xeon quad-core 2,8GHz, 3Go de RAM (DDR3), ATI Radeon HD 5770, sous Mac OS X 10.6.6.

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 :
bench_l4d2_macpro PNG 24bit

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.
bench_l4d2_macbookpro PNG 24bit
À 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.

24 janvier 2011

Bien migrer son PowerMac G5 vers un Mac Pro

L'achat d'une nouvelle machine nécessite dans la majorité des cas de pouvoir migrer ses données de l'ancien système vers le nouveau. Apple met des outils à disposition des utilisateurs pour remplir cette mission, et globalement ça marche plutôt bien. Cependant, quand l'ancienne machine et la nouvelle n'ont ni la même version du système, ni la même architecture processeur, et qu'on parle de plusieurs centaines de Go de données, tout devient un peu plus compliqué.

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)

Continue reading →

7 janvier 2011

Sauvegarde : ceinture et bretelles

Les recommandations sur le thème des sauvegardes foisonnent sur internet et dans la presse informatique. Chacun y vante sa méthode, ses logiciels, etc. Pour ne pas être en reste, et parce que je pense que la manière dont je procède à mes sauvegardes personnelles est intéressante, je vais présenter ci-dessous les quelques principes sur les quels je m'appuie. Continue reading →

Cognitive Overhead

Archives