Archive for 29 septembre 2008

Quelques critiques de Leopard Efficace

Si vous n’avez pas encore acheté mon dernier livre (mais qu’attendez-vous donc ?), vous en trouverez quelques critiques (très positives, ouf !) sur les sites de MacBuro, sur Urbanbike, le toujours excellent blog de Jean-Christophe Courtes, et l’incontournable Cuk.

Si après tout ça vous n’êtes pas convaincu, je ne sais plus quoi faire :)

DXM Expo, les 8 et 9 octobre, à Cesson-Sévigné… I’ll be there for youuuuuu

DXM, Apple Premium Reseller à Cesson-Sévigné (juste à côté de Rennes) organise sa DXM Expo les 8 et 9 octobre. Au programme, présentation des produits, technologies et logiciels Apple et formations gratuites durant deux jours !

J’aurai donc le plaisir d’assurer la présentation Mac@Work le 8 octobre à 16h, durant laquelle je vous démontrerai la puissance des technologies de Mac OS X et des logiciels iLife et iWork en entreprise, avec une partie sur Mac OS X Server et les outils de virtualisation. J’assurerai aussi des formations sur l’utilisation de Leopard, iLife et iWork les mercredi et jeudi à 11h. Et le reste du temps, je serai dans la boutique si vous avez des questions à poser, ou des exemplaires de Leopard Efficace à faire dédicacer :-)

Amis du Mac et de la Bretagne, soyez donc au rendez-vous la semaine prochaine… Et n’oubliez pas de vous inscrire sur le site de DXM au préalable !

Apple Expo 08 : qu’en penser ?

Apple Expo est donc terminée, et de nombreuses questions se posent : quel a été le succès du salon, est-ce qu’il continuera l’année prochaine, est-ce que ça valait le coup de venir, etc.

À mon avis, la réponse n’est pas évidente à donner. Ce que je peux dire, c’est qu’en tant que responsable de plot, j’ai pu constater que les journées se sont suivies et ne se sont pas ressemblées. Grosso-modo, après un bon départ mercredi avec une fréquentation que je qualifierai de correcte sans être délirante, la situation s’est pas mal corsée jeudi et vendredi, puisqu’on a bien constaté une chute de présence du public. Et comme prévu, le samedi a fait la part belle au grand public (le stand Mac OS X Server n’a alors pas eu beaucoup de succès ce jour-là… ;-) ).

Cependant, il est aussi clair que les visiteurs présents durant les premiers jours étaient essentiellement des professionnels, et que les questions étaient assez précises. C’est d’ailleurs le sentiment qui a souvent émergé chez les différents exposants avec qui j’ai pu discuter. Et l’expo est également le lieu où on peut communiquer avec ses clients, discuter du futur, des problèmes, des solutions… ce qui n’est pas négligeable dans une société où de plus en plus les relations se font uniquement par Internet.

De plus, de mon point de vue, j’ai pu constater que les différentes présentations et les nombreux débats sur l’Agora des Talents Numériques ont eu beaucoup de succès, le théâtre étant régulièrement plein… et les switchers étaient particulièrement nombreux.

Alors, quelle solution pour Apple Expo sans Apple ? Probablement s’orienter vers un salon faisant plus la part belle aux démonstrations, aux solutions, et peut-être aussi l’axer plus en direction des professionnels, en séparant plus clairement ce qui est grand public du professionnel. Le raccourcir, également : sans Apple, pas besoin de le conserver sur quatre jours, trois pourraient être suffisants et éviteraient la sensation de « flottement » durant jeudi et vendredi.

Enfin, tout ceci n’est que mon avis d’intervenant, je ne suis sûrement pas un professionnel des salons. Il serait triste de voir Apple Expo disparaître, mais il est clair que ce salon devra évoluer, changer de forme dès lors qu’il sera en concurrence directe avec la présence des Apple Store l’année prochaine.

Je profite de ce billet pour remercier les personnes qui ont participé à ce salon, en particulier :
– l’équipe de Avance Rapide, Virginie et Stéphan en tête, qui m’ont fait confiance pour l’installation des systèmes de l’Agora et m’ont confié la conférence Mac OS X Server (ainsi qu’une conf’ Mac OS X pas prévue au programme !) ;
– les étudiants de Supinfo, qui ont du me supporter durant quatre jours sur le stand Univers Apple dont j’avais la charge, ceci sans jamais se démarquer de leur bonne humeur et de leur professionnalisme ;
– Et évidemment, l’inusable Antoine Latour, désormais migré chez SOS Mac à Toulouse avec son compère Philippe, avec qui c’est toujours un bonheur de travailler et causer Apple jusqu’au bout de la nuit, et à qui je souhaite une loooooooooooooooongue carrière de consultant indépendant, comme moi !

Alors, rendez-vous en 2009… Peut-être… ?

10.5.5 dispo

Ben tout est dans le titre hein.

Les infos sur le client , et sur le serveur ici.

Et oooooooooh, surprise, on peut activer Kerberos pour le protocole PPTP désormais. C’est beau.

Apple Expo, ça se prépare

Cette semaine, opération préparation d’Apple Expo : une trentaine de Mac à préparer qui occuperont l’espace de l’Agora des Talents Numériques où auront lieu de multiples démonstrations et conférences.

Une petite partie des Mac déployés pour Apple Expo 2008

Normalement, ça ne me fait pas particulièrement peur, vu que je déploie du Mac OS X et Mac OS X Server à tire-larigot, et que j’ai commis ce petit livre blanc sur le sujet (1,2 Mo) il y a quelques mois de cela.

Pour le fun, quelques chiffres :

– Temps d’installation de Final Cut Studio et Logic Audio à partir des DVD : 6 heures (sur un Mac mini de test) ;
– Nombre de DVD pour ces deux logiciels : 17 (double couche…)
– Temps d’installation des mêmes logiciels à partir d’un disque dur FireWire 800 : environ une heure ;
– Taille de l’image-disque finale : 92 Go (!) ;
– Temps de création de l’image : 3 heures ;
– Temps de préparation de l’image pour restauration : à peu près autant ;
– Temps de déploiement par machine : environ une heure par poste (j’en ai déployé plusieurs simultanément) ;
– Durée complète de la préparation des 30 postes : environ 15 heures.

Le plus pénible à installer, ce sont évidemment les Mac Pro, puisque l’écran est séparé et que ces Apple Cinema Display sont assez pénibles à connecter à la chaîne en raison du bloc d’alim séparé (de ce point de vue, je regrette le connecteur ADC…).

Pour le déploiement proprement dit, je me suis une fois de plus appuyé sur l’excellentissime Deploy Studio combiné à Mac OS X Server pour permettre le boot sur le réseau. En fait, le déploiement aurait pu être bien plus rapide si je n’avais pas essayé de faire mon malin en créant l’image-disque à la main, alors que Deploy Studio aurait pu la faire tout aussi bien tout seul… et je n’aurais pas perdu du temps durant le contrôle de l’image pour restauration le lendemain.

Ça se prépare et ça restaure

Et pour voir tout ça, ben il suffit de venir à Apple Expo, sur l’ATN, où j’officierai avec un fauteur de troubles toulousain… :)

Disk

RingIl y a quelques années est sorti un film d’horreur intitulé très sobrement Ring, ou The Ring dans sa version américanisée, une histoire d’épouvante où sévissait une cassette vidéo maléfique. Quiconque regardait cette cassette était certain de périr dans la semaine qui suit.

Et bien vous savez quoi ? Il semble que j’ai réussi à faire un article qui est à peu près l’équivalent de cette cassette : quiconque le lit verra son disque dur d’un de ses Mac périr dans la semaine qui suit. La preuve se trouve dans les commentaires dudit article, où plusieurs lecteurs ont subi une défaillance fatale de disque quelque jours après l’avoir lu.

Mouah ah ah, je suis la Sadako du Mac !!! Alors, oserez-vous aussi consulter ce billet maudit ? :-)

Régler les problèmes de permission avec AFP sous Leopard Server

Pour la rentrée, je vous propose un article plus long que la moyenne, et qui aborde les problématiques de gestion des permissions sous AFP. Car sous Mac OS X Server 10.5, j’ai constaté que de nombreux administrateurs (moi y compris, avant de me pencher vraiment sur le sujet il y a quelques mois de cela) ont eu du mal avec le fonctionnement des permissions. Cas classique :

      • Un utilisateur A appartenant à un groupe (appelons-le Travail) crée un fichier Toto.doc.
      • Un administrateur a créé un point de partage « Boulot » sur un serveur AFP sous 10.5. Il lui a attribué les autorisations POSIX suivantes :

    1. Possesseur : lui-même, en lecture/écriture ;
    2. Groupe : Travail, en lecture et écriture ;
    3. Autres : lecture seule
      • L’utilisateur A copie son fichier toto.doc sur le point de partage, via AFP ;
      • L’utilisateur B, appartenant aussi au groupe Travail, essaie de modifier le fichier toto.doc.

Et là… impossible ! Le système lui indique qu’il n’a pas les autorisations suffisantes pour modifier le fichier. Pourtant, en toute logique, le fichier devrait avoir des permissions en lecture/écriture pour les membres du groupe travail… sauf que ce n’est pas le cas, le groupe attribué au fichier ne disposant que de la lecture seule. Comment est-ce possible ? Pourquoi les autorisations sont attribuées de façon incorrecte au fichier ?

On pourrait croire qu’il s’agit d’un bug. Pourtant, le comportement est exactement celui attendu. Le problème est plus insidieux, et la faute en incombe aux… ACLs. Mais l’explication est particulièrement tordue, et pour la comprendre, il faut remonter de quelques années en arrière…

Avant Mac OS X Server 10.2.4

Avant l’arrivée de Jaguar Server dans sa version 10.2.4, le comportement du partage de fichier respectait les autorisations Posix. Cela signifie que les autorisations d’un fichier copié sur un serveur étaient les mêmes que celles du fichier source, c’est à dire que le masque appliqué est identique entre le fichier source et la copie sur le serveur. En pratique, un fichier dont le groupe est en lecture seule sur la machine cliente restera en lecture seule s’il est copié sur le serveur.

Mais cela posait de nombreux problèmes pour les utilisateurs et les administrateurs informatiques, car cela empêchait le transfert des informations entre utilisateurs. Pourquoi ? Parce que le masque appliqué par défaut à tous les fichiers créés sur Mac OS X est 022, ce qui fait qu’un fichier est toujours en lecture/écriture pour son possesseur, mais en lecture seule pour son groupe.

Quand on copie un fichier sur le serveur, c’est ce masque qui est conservé. Si chaque fichier généré sous Mac OS X se voyait attribué un masque en lecture/écriture pour le groupe (002), il n’y aurait aucun souci, le masque étant transféré sur le serveur, et les autorisations seraient alors correctes.

De Mac OS X 10.2.4 à 10.4 : l’héritage des permissions

Comme modifier le comportement de Mac OS X impliquait des soucis de sécurité un peu plus larges, Apple a donc modifié le client et le service AFP en 10.2.4 pour permettre l’héritage des permissions, comme expliqué dans l’article 107623 de la Knowledge Base. Ainsi, un fichier récupère les permissions d’accès du groupe associé au dossier où il est placé. Il suffit de cocher la case Recevoir les autorisations des parents, et hop, on est tranquille.

Autorisations des parents

C’est ce que l’on attend en fait la plupart du temps, et c’était d’ailleurs le comportement de ce bon vieil AppleShare IP ou du partage de fichiers personnel sous Mac OS 9. Et finalement, ça marchait très bien. Sauf qu’une des grosses nouveautés de Mac OS X Server 10.4 allait imposer un nouveau changement, très attendu mais assez pernicieux.

Mac OS X Server 10.4 : bienvenue aux ACL !
Les ACL (Access Control Lists, appelées aussi listes de contrôle d’accès ou LCA) ont apporté une grande souplesse d’utilisation dans la gestion des permissions. Cependant, sous Mac OS X Server 10.4, il faut explicitement activer les ACL pour chaque volume.

Si les ACL ne sont pas actives, les permissions d’un partage peuvent toujours être attribuées façon POSIX ou via l’héritage des permissions. Mais si elles sont actives, l’héritage ne fonctionne plus, d’ailleurs la case ad hoc est désactivée. Et devinez quoi ? Dans ce cas, c’est l’attribution des autorisations façon POSIX qui prend le relais par défaut ! Il faut alors éventuellement rajouter des autorisations via des ACL pour que les différents utilisateurs puissent modifier le fichier.

Mac OS X Server 10.5 : ACL obligatoires

Après toute cette description, vous comprendrez peut-être ce qui se passe sous Mac OS X Server 10.5 : les ACL sont systématiquement actives par défaut et ne peuvent pas être désactivées (il n’y a aucune case qui le permette dans Server Admin ou ailleurs). Ce qui implique que par défaut, c’est toujours le comportement POSIX qui prime. Et du coup, il est relativement simple de corriger le souci et permettre à nos deux utilisateurs de s’échanger leurs fichiers : il suffit de rajouter le groupe en lecture/écriture… sous forme d’entrée dans les ACL. C’est à dire, dans Server Admin, de glisser le groupe Travail dans la ligne LCA, et non pas la ligne Groupe en POSIX, et lui attribuer les autorisations en lecture/écriture.

Autorisations sous 10.5

Mais pourquoi tant de confusion ? D’abord, l’interface de Server Admin a souffert durant quelques versions d’un oubli gênant : jusqu’à Mac OS X Server 10.5.2 inclus, la case d’héritage des permissions du parent était toujours visible dans l’interface graphique, quand bien même elle n’avait aucun effet. Cela a été corrigé en 10.5.3, les options d’héritage ayant disparu :

Depuis Mac OS X Server 10.5.3, l\'option d\'héritage des permissions a disparu
La faute aussi à la documentation de Mac OS X Server, qui manque probablement de clarté quand à la différence entre la gestion POSIX et les ACL, et leur influence sur un modèle de partage de fichiers assez courant. Une grande partie des problèmes vient également du masque par défaut appliqué aux fichiers sous Mac OS X : si chaque groupe avait par défaut l’accès en lecture et écriture sur tout nouveau fichier généré, on aurait beaucoup moins de soucis…

Enfin, une partie de ce comportement vient de la difficulté à concevoir un modèle où la sécurité, les origines UNIX de Mac OS X et les besoins des utilisateurs d’un système graphique puissent coexister paisiblement. Et finalement, quand on comprend le fonctionnement de Mac OS X, on comprend aussi que l’héritage des permissions était un patch qu’il était nécessaire de supprimer, les ACL étant gérées au niveau du noyau de Mac OS X et non pas du seul client AFP.

Vous savez donc désormais comment agir : ne vous occupez plus spécialement des autorisations POSIX, et concentrez-vous sur les ACL. Vous pourrez ainsi gérer vos autorisations du partage de fichiers plus efficacement et de façon bien plus souple. Au passage, lisez la documentation de Mac OS X Server 10.5, en particulier celle-ci (PDF, 1,4 Mo).

N.B. : ceux qui ont installé leur serveur 10.5 en mode standard (et non pas avancé) n’ont même pas souffert de ce problème. Pourquoi ? Parce que dans l’interface des Préférences Serveur, la notion de POSIX n’est pas représentée : en réalité, tout est géré via les ACL…

N.B.2 : une autre solution aurait pu consister à modifier le masque global appliqué aux fichiers, mais il faut le faire aussi sur chaque poste client… Voir ce document pour la méthode.