Obsolète

14 novembre 2009

5 bonnes raisons de ne pas acheter de SSD

Le SSD, solid state disk, c'est la mode, c'est hype, c'est geek, mais c'est l'avenir. Et comme c'est l'avenir, il convient de ne pas trop se précipiter. D'ailleurs, on a souvent tort d'avoir trop tôt raison.
Enfin, quand j'écris que c'est l'avenir, c'est surtout pour le grand public, parce que les gens exigeants, eux, utilisent déjà des SSD depuis plus de 10 ans. Ce qui m'intéresse aujourd'hui, c'est le SSD grand public, car j'en suis sûr, personne ici n'a envie de débourser 8000 € HT pour un SSD "entreprise" de 250 Go, même si les performances explosent littéralement tout ce que vous pouvez trouver dans le commerce. Pour moi, il est clair que le SSD grand public n'est pas prêt. Voici quelques raisons de s'en passer pour le moment :

Le prix au Go est dissuasif. C'est presque la tarte à la crème des arguments, mais c'est partiellement faux. Néanmoins, il paraît que c'est la crise, et si en 1997 on pouvait "facilement" dépenser l'équivalent de 120 € pour 1 Go de disque dur, 3 €/Go semble être actuellement une pilule un peu dure à avaler. Surtout quand on trouve maintenant des disques autour de 0,07 €/Go. À la lumière de ces petites comparaisons, vous comprendrez qu'en attendant un peu on devrait voir les prix s'effondrer assez rapidement.
Les capacités des disques SSD sont relativement faibles. Je vis très bien avec un disque de 160 Go, mais force est de constater que la numérisation de nos loisirs amène les gens à remplir de plus en plus leurs disques durs. Les photos ne sont plus sur papier, les musiques sont de plus en plus rarement sur CD… et leurs équivalents numériques viennent saturer les ordinateurs.
Les SSD sont "biodégradables". J'entends par là que la technologie utilisée dans ces supports ne permet pas de leur garantir une grande durée de vie. Progressivement, les performances se dégradent, les cellules "s'usent", et la capacité du volume diminue. Par ailleurs, un SDD qui resterait débranché pendant trop longtemps (archivé quelque par, par exemple), perdrait progressivement les données qui sont inscrites dessus. Exit la postérité.
Les systèmes d'exploitation ne sont pas encore tout à fait mûrs pour le SSD. Ils doivent savoir faire quelques pirouettes techniques avec les écritures/effacements de données pour ralentir le vieillissement des cellules mémoire. Malheureusement, à l'heure actuelle je crois qu'un seul système grand public peut gérer correctement des SSD.
Pour finir, les SSD eux-mêmes ne sont pas mûrs. Oui, ils ont été démoulés trop chaud. Si vous suivez un peu l'actualité du SSD, vous n'aurez pas manqué de noter le nombre de mise à jour de firmware qui sont proposées pour ces engins. Sans m'avancer trop, je crois pouvoir dire qu'il y a eu plus de mises à jour de firmware sur les SSD depuis 1 an que sur les disques durs lors des 10 dernières années. On vous promet à chaque fois plus de performances, ou des corrections de bugs, et régulièrement des utilisateurs perdent toutes leurs données, voire même, le fabricant retire sa mise à jour car elle s'avère calamiteuse.

Alors un bon conseil : gardez vos gros disques durs !

9 juillet 2009

A script to list service ACLs on Mac OS X 10.5

I personally don't think it's a good thing to blog in english when you're french, unless you are very fluent and your target audience reads english. Today, my audience is the worldwide crowd of Mac OS X Server sysadmin. So, while I'm not fluent, I'm going to write my first post in english.

Background

There is something quite messy in the Service Access Control Lists (SACLs) on Mac OS X 10.5: you just can't display the full users & groups list of a SACL in command line.
Basically, you can do this:

$ dscl . -read /Groups/com.apple.access_ssh
AppleMetaNodeLocation: /Local/Default
GeneratedUID: A7E16606-3C52-42B9-852E-D197C7598EA8
NestedGroups: 955F946A-7C9D-4D3E-B286-E16003380282 ABCDEFAB-CDEF-ABCD-EFAB-CD...
PrimaryGroupID: 101
RealName:
 Remote Login Group
RecordName: com.apple.access_ssh
RecordType: dsRecTypeStandard:Groups

As you can see, this SACL group com.apple.access_ssh has no direct members, only nested groups (NestedGroups key). So, in order to list users, you have to read the content of each nested group. But groups are only available by their name. So the first step is to find out group's names.
At this stage, you have no way to know if the target group is local or if it sits on a remote open directory server, so you must use the /Search path:

$ dscl /Search -search /Groups GeneratedUID 955F946A-7C9D-4D3E-B286-E16003380282
myadmins		GeneratedUID = (
    "955F946A-7C9D-4D3E-B286-E16003380282"
)

The second step is to list users of the group:

$ dscl /Search -read /Groups/myadmins GroupMembership
GroupMembership: admin01 admin02 user01 user02 ldapuser01

But guess what: this group might have more than just users, may be its NestedGroups key is not empty! So at this point, you must also check the NestedGroups value, and recursively follow each group GUID, until you find only users.
Think "huge groups", think "handfulls of nested groups", and watch your fingers as you're going thru dscl torments. You've figured it out: Mac OS X lacks a good command line tool for following a SACL tree of users and groups.

Here come's getsacls.sh

I won't promise you a killer command line tool with foolproof error and recursion handling, but I still believe I've designed a usable piece of shell script. Even if it looks like it's the worst code I've ever wrote (wich is not true, I've made things way uglier).
The source code is too long and messy to be just copy-pasted here, just follow this link to download the getsacls.sh script.

How to get getsacls.sh:
Just download the latest version from here.

How to install getsacls.sh:
Simply copy to your Mac OS X 10.5 server (or managed client). Somewhere in your $PATH should be fine. Then chmod +x the script, so that it can be executed.

How to configure getsacls.sh:
Defaults values should be ok, but if you really want to change something, open the script in your favorite editor, and find the "FEW USER TUNABLE MISCS" section. Edit at your own risks.

How to use getsacls.sh:
It's simple, you just have to launch it. It will then proceed with the parsing of every SACL on your local system.
DO NOT use the sh command to launch this script. getsacls.sh uses special escape sequences and command options that sh will not recognize. Just run:

$ getsacls.sh

If you want to parse only some SACLs, you can provide each SACL name at the command line:

$ getsacls.sh com.apple.access_ssh com.apple.access_loginwindow

Still, you should only use SACL names that exist on your local system.

The default output is "fancy", it uses bold, indentation, and a beach-ball cursor. If you want the "no fancy" mode, you can either edit the corresponding "tunable misc variable" or define FANCY=NO at launch time:

$ FANCY=NO getsacls.sh com.apple.access_ssh

This "no fancy" mode allows for later parsing.

Caveats/bug:
The script will not handle circular references. If your SACL uses nested groups in a circular way (group 1 -> group 2 -> group 1), the script will not stop.
When finding two or more similar users or groups (for example the local admin group and the open directory admin group), it will use only one of them, and that should be the local one.
The script uses SQLite3 as a backend, because bash is not good with arrays, and because I'm not good with PERL/Python/Ruby.

Sample "fancy" output:

com.apple.access_ssh
--------------------------------
   myadmins	/LDAPv3/192.168.128.34	955F946A-7C9D-4D3E-B286-...
     admin01	/Local/Default	9A7917D1-D8E7-49D6-8211-...
     admin02	/Local/Default	40D516A2-4D02-4C92-9505-...
     ldapuser01	/LDAPv3/ldap.example.com	ldapuser01_OUT_OF_OD
     ldapuser02	/LDAPv3/ldap.example.com	ldapuser02_OUT_OF_OD
     ldapuser03	/LDAPv3/ldap.example.com	ldapuser03_OUT_OF_OD
     user01	/LDAPv3/192.168.128.34	49EF9C64-D98B-11D8-BCFA-...
   admin	/Local/Default	ABCDEFAB-CDEF-ABCD-EFAB-...
     root	/Local/Default	FFFFEEEE-DDDD-CCCC-BBBB-...
     admin01	/Local/Default	9A7917D1-D8E7-49D6-8211-...
     admin02	/Local/Default	40D516A2-4D02-4C92-9505-...
     user01	/LDAPv3/192.168.128.34	49EF9C64-D98B-11D8-BCFA-...
================================

Sample "no fancy" output:

com.apple.access_ssh
--------------------------------
g 1 myadmins /LDAPv3/192.168.128.34 955F946A-7C9D-4D3E-B286-...
u 2 admin01 /Local/Default 9A7917D1-D8E7-49D6-8211-...
u 2 admin02 /Local/Default 40D516A2-4D02-4C92-9505-...
u 2 ldapuser01 /LDAPv3/ldap.example.com ldapuser01_OUT_OF_OD
u 2 ldapuser02 /LDAPv3/ldap.example.com ldapuser02_OUT_OF_OD
u 2 ldapuser03 /LDAPv3/ldap.example.com ldapuser03_OUT_OF_OD
u 2 user01 /LDAPv3/192.168.128.34 49EF9C64-D98B-11D8-BCFA-...
g 1 admin /Local/Default ABCDEFAB-CDEF-ABCD-EFAB-...
u 2 root /Local/Default FFFFEEEE-DDDD-CCCC-BBBB-...
u 2 admin01 /Local/Default 9A7917D1-D8E7-49D6-8211-...
u 2 admin02 /Local/Default 40D516A2-4D02-4C92-9505-...
u 2 user01 /LDAPv3/192.168.128.34 49EF9C64-D98B-11D8-BCFA-...
================================

Current version:
As of now, current version of getsacls.sh is 407 ($Id: getsacls.sh 407 2009-07-09 09:36:26Z patpro $). Next revisions will be listed here.

Update: $Id: getsacls.sh 409 2009-07-09 14:30:01Z patpro $
I've added some error handling for a rare case: when a user account lives on a LDAP server distinct from the Open Directory server, the GroupMembership field is not updated on the OD if the user account is destroyed on the LDAP. So according to the GroupMembership the user is still here, but according to the LDAP the user is nowhere to be found.

Update: $Id: getsacls.sh 412 2009-07-23 20:24:54Z patpro $
I'm forcing LC_NUMERIC in the beachball function, so that sleep 0.05 runs as expected even for people not using the dot as a decimal separator. Some cleanup.

Update: $Id: getsacls.sh 414 2009-08-03 10:33:30Z patpro $
Some cleanup and english corrections. Added some delay to the beatchball rotation so it's more enjoyable.

Feel free to comment, and to correct my english ;)

5 septembre 2008

Apache/PHP sur FreeBSD : le truc qui sauve

On a beau vanter la supériorité de tel ou tel OS, une stabilité légendaire ou une performance incomparable du logiciel X ou Y, il arrive toujours que certaines combinaisons fournissent des résultats surprenants. C'est le cas par exemple d'Apache (2) avec mod_php (4 ou 5), sur FreeBSD (6 dans mon cas).

Cette combinaison, et peut être d'autres, a le gros inconvénient d'être sensible à l'ordre de chargement des extensions de PHP. Pour ma part, c'est la seconde fois que je suis confronté à des plantages des démons httpd à cause du simple fait que les extensions PHP ne sont pas chargées dans l'ordre idéal. Sur FreeBSD, le chargement en question est orchestré par le fichier /usr/local/etc/php/extensions.ini. Cela ressemble à ça :

extension=filter.so
extension=hash.so
extension=json.so
extension=gettext.so
extension=pcre.so

Si par malheur vous avez plus d'une poignée de ces extensions, vous risquez un jour de tomber sur un enchaînement problématique. Par chance, mon problème n'était pas dramatique : Apache faisant un segfault uniquement au moment de quitter.

Voilà les traces dans /var/log/messages des process fils httpd quittant sur un signal 11 au moment de se terminer :

kernel: pid 51113 (httpd), uid 80: exited on signal 11
kernel: pid 16830 (httpd), uid 80: exited on signal 11

Et voilà la trace du process parent httpd au moment d'un apachectl restart ou stop :

kernel: pid 57931 (httpd), uid 0: exited on signal 11 (core dumped)

Après une recherche intensive, je suis tombé sur un petit bout de script shell qui rend bien service : fixphpextorder.sh. Ce script écrit par J. Pingle permet de ré-ordonner les extensions PHP dans une configuration supposée non-conflictuelle. En deux mots comme en mille : ça marche !
Vous lancez le script (à partir d'un compte utilisateur ayant les droits d'écriture sur le fichier /usr/local/etc/php/extensions.ini) et vous relancer votre Apache. Normalement, c'est la fin des plantages. Si ils persistent n'hésitez pas à le faire savoir à l'auteur du script, ce genre de choses ne peut s'améliorer qu'avec le retour des utilisateurs.

29 juillet 2008

Recevoir les mails de periodic sous Mac OS X Server 10.5

Les BSDistes de tout poil sont habitués aux emails envoyés chaque nuit, chaque semaine, et chaque mois à l'issue du lancement des scripts periodic. Sous Mac OS X, le résultat de ces scripts en par défaut renvoyé dans les fichiers /var/log/daily.out /var/log/weekly.out et /var/log/monthly.out. Néanmoins, l'administrateur avisé aura tôt fait de les diriger vers son mail en utilisant un fichier /etc/periodic.conf.local comme celui-ci :

daily_output=root
weekly_output=root
monthly_output=root

La formule fonctionne parfaitement pour FreeBSD ou Mac OS X 10.4, mais pas pour Mac OS X Server 10.5.4. Launchd semble présenter un bug qui l'empêche de gérer la création du mail post-periodic. On lit alors cette erreur dans /var/log/system.log :

Jul 29 03:17:42 myserver com.apple.launchd[1] (com.apple.periodic-daily[...]):
  Stray process with PGID equal to this dead job: PID ... PPID 1 sendmail

C'est fâcheux, mais ne nous laissons pas abattre, car il existe une solution. Contrairement à ce qu'on peut lire à droite et à gauche, il ne faut pas modifier la configuration de Postfix, et laisser les références à Cyrus tranquilles. La solution est plutôt du côté de launchd. Certains ont mis en évidence que le mail sera bien généré si au lieu d'exécuter simplement le periodic, on exécute en plus et juste après une petite pause.
Après quelques tests, j'ai trouvé que c'est une solution assez satisfaisante. Sur le plan fonctionnel elle est parfaite, mais elle n'est pas idéale, car elle impose de modifier des fichiers fournis par Apple. Donc cette correction est susceptible d'être perdue au détour d'une mise à jour du système.

~~J'ai choisi de modifier les plist de launchd correspondant aux lancements de periodic :~~

[edit] : En réalité, la modification des plists com.apple.periodic* n'a pas donné le résultat escompté sur le terrain. Sur mon serveur de test, les mails de periodic étaient bien envoyés, mais sur mes serveurs de production, 3 machines sur 4 n'ont pas réussi à envoyer les mails pour le daily. Par ailleurs, le nombre d'erreurs dans les log système a sensiblement augmenté.

J'ai donc décidé de restaurer les fichiers com.apple.periodic* dans leur état d'origine et de modifier à la place la commande periodic. J'ai renommé /usr/sbin/periodic en /usr/sbin/periodic_orig, puis j'ai créé un script shell nommé /usr/sbin/periodic :

#!/bin/bash 
/usr/sbin/periodic_orig $@ 
sleep 1

Ainsi, le lancement par launchd de la commande `periodic daily` va en réalité lancer `/usr/sbin/periodic_orig daily` (donc le script periodic original), puis va lancer `sleep 1`, ce qui suffit à launchd pour pouvoir générer le mail de résultat de periodic.

J'ai comme l'impression qu'avec launchd, on n'a pas fini d'en baver...

24 mai 2008

Macbook Pro volé

Mon frère s'est fait cambrioler vendredi 23, à Paris. Les vilains ont mis l'appartement à sac et ont embarqué son MacBook Pro tout neuf. Il y a assez peu d'espoir de remettre la main sur la machine, mais qui ne tente rien n'a rien. Voici donc les spécifications et numéro de série. Si vous le voyez passer, n'hésitez pas à témoigner ici (ou par email).

MacBook Pro 15"
Intel Core 2 Duo 2.4 GHz
2 Go de RAM
256 Mo de Vram
disque de 200 Go, 5400 rpm
numéro de série : W8810EZSYJX
adresse MAC (ethernet) : 00:1e:c2:1c:e2:42

Faites passer le message !

J'ai bien sûr contacté macbook-fr.com pour que la machine soit inscrite dans la liste de machines volées. Et je vais contacter Apple d'ici lundi.

15 février 2008

MySQL 5 : le checklist en cas de pépin

Comme les commentaires le montrent, si l'installation de MySQL peut prendre 5 minutes et se dérouler comme un charme, le moindre problème peut vite bloquer le débutant pendant des jours. Et plus le débutant se débat, plus il fait des dégâts sur son système.
Je vous propose donc ici une petite checklist des choses à vérifier si votre installation de MySQL sur Mac OS X tourne mal.

1) Si vous avez installé une ou plusieurs autres versions de MySQL et que vous souhaitez repartir de zéro, le plus simple est de localiser tous les éléments liés à MySQL et de les supprimer. On utilise pour cela la base locate, qu'il convient de mettre à jour au préalable :

sudo /usr/libexec/locate.updatedb 
locate -i mysql

ensuite faites le tri dans ce que vous voyez, et supprimez les éléments appartenant aux anciennes installation de MySQL (sans doute dans /usr/local/, /Library/LaunchDaemon/, /Library/StartupItems/, ...)

2) Vérifiez votre PATH : les binaires de MySQL doivent se trouver dans votre PATH pour être exécutables sans indiquer leur chemin complet. Si la commande which mysql ne renvoie rien, ajoutez /usr/local/mysql/bin/ à votre PATH.

3) Vérifiez que le serveur mysqld est lancé (ps auxwww | grep mysqld) ou se lance bien (sudo /usr/local/mysql/bin/mysqld_safe).

4) Vérifiez que le socket du serveur existe quand il est lancé :

netstat -f unix | grep mysql 
ls -l /tmp/mysql.sock

Si l'une de ces deux commandes ne retourne pas le chemin du socket, alors soit le socket est ouvert par le serveur mais supprimé par un autre process, soit le socket n'est pas ouvert par le serveur car il existe déjà.

5) Vérifiez que vous essayez bien d'accéder au serveur MySQL à partir d'un logiciel qui saura s'y connecter (php doit connaître le chemin du socket, le client mysql aussi). Si vous tentez une connexion réseau, vérifier aussi que mysqld ouvre un port réseau (netstat -alnf inet | grep 3306).

6) Jetez un œil aux fichiers de log de MySQL. Si le serveur ne se lance pas du tout, cela ne vous aidera probablement pas, mais si il se lance et quitte inopinément, ou si il se lance dans un état inutilisable, vous trouverez probablement des informations intéressantes dans ces fichiers. Pour l'installation de MySQL via le package officiel, les fichiers de log se trouvent normalement dans /usr/local/mysql/data/, sous le nom de localhost.err ou de votre-machine.err.

Je compléterai cette liste au fil du temps... N'hésitez pas à faire des suggestions !

14 février 2008

MySQL 5 : le plist de démarrage

Dans un précédent article j'ai exposé l'installation triviale d'un MySQL 5 sur une base de Mac OS X 10.5 propre. J'ai aussi mentionné le StartupItem fourni de base avec le package MySQL. Ce StartupItem étant conçu pour Mac OS X 10.4, il est intéressant de voir comment on doit maintenant lancer un serveur MySQL sur Leopard.

Si vous aviez installé le script de démarrage de MySQL 5 mentionné dans le précédent article, il faudra le désactiver ou le supprimer. Pour le supprimer, vous pouvez exécuter les commandes suivantes dans le terminal :

sudo /Library/StartupItems/MySQLCOM/MySQLCOM stop 
sudo rm -r /Library/StartupItems/MySQLCOM 
sudo rm /tmp/mysql.sock

Ensuite, vous pouvez créer le fichier /Library/LaunchDaemons/org.mysql.mysqld.plist avec votre éditeur favori, et coller dedans :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>org.mysql.mysqld</string>
	<key>OnDemand</key>
	<false/>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/local/mysql/bin/mysqld</string>
		<string>--socket=/tmp/mysql.sock</string>
		<string>--user=mysql</string>
		<string>--port=3306</string>
		<string>--datadir=/usr/local/mysql/data</string>
		<string>--pid-file=/usr/local/mysql/data/localhost.pid</string>
		<string>--bind-address=127.0.0.1</string>
	</array>
	<key>ServiceIPC</key>
	<false/>
</dict>
</plist>

Une fois que ce fichier est sauvé, il faut s'assurer qu'il appartient bien à root, sinon launchctl vous envoie sur les roses (cf. les commentaires de Pierre29). Dans le doute, exécutez la commande

sudo chown root /Library/LaunchDaemons/org.mysql.mysqld.plist

Vous pouvez ensuite activer ce plist par la commande

sudo launchctl load /Library/LaunchDaemons/org.mysql.mysqld.plist

MySQL devrait être alors lancé automatiquement pour vous. Il placera son socket dans /tmp/ et autorisera aussi les connexions TCP sur l'interface 127.0.0.1.

Je vous renvoie à la documentation de launchctl pour le reste des options et commandes disponibles et pour les détails sur l'utilisation de launchd. Votre serveur MySQL est désormais géré proprement par launchd, exactement comme sur un Mac OS X Serveur.

edit : ajout du chown root sur le fichier

5 février 2008

Recherchons administratrice système polyvalente

Une fois de plus, nous cherchons une perle rare pour notre service. Voici le texte de l'annonce :

Recherchons administratrice système polyvalente.

Cette administratrice s'intègrera dans une équipe restreinte chargée de l'infrastructure matérielle de l'environnement numérique de travail de l'université Lumière Lyon 2. Cet ENT est utilisé par environ 30 000 personnes. Ces outils regroupent les outils du bureau virtuel (courrier électronique, agenda, carnet d'adresse, documents...), les sites web institutionnels et personnels (plus d'une cinquantaines de sites web), les outils administratifs (gestion de notes pour les enseignants, consultation des notes, emploi du temps pour les étudiants...), la plateforme d'enseignement en ligne…

Elle participera aux activités suivantes :

Administration, surveillance et maintenance d'une quarantaine de serveurs fonctionnant sous Mac OS X et Linux Debian.

Administration d'un réseau privé et d'un commutateur d'applications Nortel utilisé pour de la répartition de charge applicative.

Installation physique et logicielle, câblage de machines fonctionnant sous Mac OS X et Linux Debian à l'intérieur d'une salle serveur.

Installation, création d'outils de surveillance, d'analyse et de maintenance.

Participation à la définition des architectures matérielles et logicielles à mettre en place pour le déploiement d'applications WebObjects ou JEE, Ruby ou PHP.

Mise en place et administration d'applications fonctionnant avec Apache, MySQL et PHP.

Mise en place et administration d'applications de diffusion de fichiers vidéo ou sons.

Mise en place de procédure et solution de sauvegarde.

Administration d'une architecture Xsan.

Participation aux astreintes pour offrir une continuité de service 24h/24h, 7j/7j, 365j/365j.

Cette administratrice doit avoir des connaissances Linux, Mac OSX. Elle doit être capable d'installer un outil à partir de son code source. Elle doit être capable de lire et d'écrire des scripts shell et des scripts dans un langage comme Ruby, PHP ou Perl. Elle doit être avoir des connaissances dans le domaine de la sécurité, des annuaires.

Elle devra être capable de s'adapter à des technologies et des outils en évolution rapide.

Notez que si vous êtes un homme, vous pouvez quand même tenter votre chance ;-)
Par ailleurs, je ne précise pas à qui il faut écrire, on ne serait probablement pas intéressé par quelqu'un qui ne saurait pas retrouver cette information.

Cognitive Overhead

Category Archives: Obsolète