Archive for 12 novembre 2010

Mac OS X : comment sélectionner automatiquement le PPD d’un copieur multi-fonction ?

Je déteste les copieurs multi-fonctions. Au moins, vous êtes prévenu : si vous lisez des gros mots, ça ne sera pas ma faute.

Je viens de me battre pendant quelques jours à essayer de faire fonctionner correctement un copieur BizHub 350 de Konica Minolta avec Mac OS X 10.6. Car, voyez-vous, le constructeur n’a pas encore eu l’heurt de proposer un pilote à jour pour ce système sorti depuis maintenant 14 mois… Pas grave, hein, on va se débrouiller, comme d’habitude !

Donc, après avoir trouvé avec le (très gentil) technicien de Konica le bon driver (C-401, parce qu’il y a un Fiery derrière, amusant non ?), puis sélectionné la bonne file d’attente (« print », là c’est facile, mais attention, ça dépend du copieur), il restait à trouver comment sélectionner automatiquement le bon driver. Car Mac OS X dispose d’une petite subtilité pour choisir automatiquement le driver. Il faut, dans l’ordre :

– que le copieur renvoie son nom de modèle (ModelName) à la connexion avec le Mac ;

– Qu’il existe dans un dossier PPDs (principalement dans /Library/Printers/) un PPD compressé au format .gzip et intitulé avec le ModelName du copieur.

Dans l’ensemble, ce mécanisme marche… pas trop mal. Mais que se passe-t-il si le développeur, particulièrement incompétent, fait n’importe quoi ?

Et ben on se prend bien le chou. Car il faut alors trouver le modèle renvoyé par le copieur, ce qui n’est pas totalement évident… Dans mon cas, j’avais un PPD qui s’appelait Fiery X3e 22C-KM PS v2.0 eu. Pratique non ? Le ModelName dans le PPD indiquait quand à lui Fiery X3e 22C-KM PS Color Server v2.0 eu. Problème : quelque soit le nom utilisé, impossible d’avoir le PPD sélectionné automatiquement. Ce qui veut dire que le copieur ne se présente pas comme indiqué dans le PPD.

Et bien, soit ! Analysons un peu le traffic IP entre le Mac et l’imprimante au moment de la connexion. Tapons donc dans le Terminal :

sudo tcpdump -nnnvi en0 host IP_Copieur

Ici, en0 désigne le nom BSD de votre connexion Ethernet. La plupart du temps, c’est en0 si vous êtes en Ethernet ou en1 si vous utilisez Airport. En cas de doute, vérifiez ce nom dans Informations Système > Réseau. Et vous remplacez évidemment IP_Copieur par l’adresse IP ou le nom DNS de votre copieur.

Maintenant, ouvrez la préférence Système Imprimantes et Fax, appuyez sur le bouton +, puis sur le bouton IP pour faire une configuration via IP, et tapez l’adresse du copieur, ici 192.168.1.51.

Aie… « Imprimante PostScript générique » ! Pas vraiment ce qu’on veut… Il est temps maintenant de regarder ce que ça donne du côté de tcpdump Beaucoup de bla-bla, mais une ligne qui m’intéresse :

23:15:06.354258 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 92)    192.168.1.51.161 > 192.168.1.2.59013:  { SNMPv1 { GetResponse(49) R=1536459456  .1.3.6.1.2.1.25.3.2.1.3.1= »C350″ .1.3.6.1.2.1.1.6.0= » » } }
Ne voyez-vous donc pas ? « C350 », qu’elle dit, la dame ! Il faut donc :
– Décompresser le PPD ;
– Remplacer à l’aide d’un éditeur de texte le ModelName dans le PPD par C350 ;
– Renommer ce fichier PPD décompressé en C350 ;
– Recompresser le PPD au format Gzip (avec la commande gzip, par exemple) ;
– Replacer le PPD C350.gzip dans le dossier /Bibliothèque/Printers/PPDs/Contents/Resources/
Saisissons  à nouveau l’adresse du copieur…
Victoire !!! Attention cependant à bien mettre le bon nom de file d’attente avant d’enregistrer : par exemple, pour ce modèle de copieur, c’est « print », mais sur d’autres, ça peut être « lp », ou rien, ou autre chose…
Et au passage, petite info : si vous utilisez les préférences gérées (MCX) pour appliquer des imprimantes par défaut à vos postes, méfiez-vous de ne pas laisser de caractère spécial ou accentué dans le nom de l’imprimante : vous risqueriez alors de rajouter des nouveaux doublons à chaque ouverture de session !

The day the Xserve died

Ce vendredi, la nouvelle est tombée sur les téléscripteurs, non pas par un communiqué de presse, mais par une petite bande jaune en haut de la page des Xserve.

Apple a donc décidé d’arrêter le Xserve, son serveur 1U à destination des professionnels. Immédiatement, le web et Twitter se sont enflammés, étant donné l’aspect critique que Xserve avait dans certains cœurs de métier. Et on m’a du coup demandé mon avis, et ça tombe bien puisque j’avais l’intention de toute façon de le donner (d’autant plus que la veille, lors de la fermeture de l’Apple Store, j’avais évoqué l’arrivée d’un nouvel Xserve. Boule de Cristal #FAIL !).

Il faut dire que des Xserve, j’en ai installé, géré et dépanné quelques-uns, puisque c’est une des plate-formes proposées par Apple pour faire fonctionner Mac OS X Server. Le Xserve, si vous ne connaissiez pas, c’est le serveur rackable qui tient dans un 1U, ce qui permet d’en mettre beaucoup dans une seule armoire informatique. Sa taille, ainsi que le fait qu’une partie de ses composants sont redondants (comme l’alim) en ont fait une solution de choix pour de nombreux administrateurs informatiques. Alors, évidemment, l’annonce de son abandon apparaît comme une demi-surprise.

Comment ça, demi-surprise ?

L’annonce d’Apple ne pouvait en fait que surprendre ceux qui suivent l’actu serveur d’Apple de loin. Cela fait longtemps que le Xserve n’a pas été mis à jour, et ses mises à jour depuis le passage à Intel ont été plutôt modérées. De plus, une rumeur circulait depuis pas mal de temps selon quoi l’équipe du Xserve avait été démantelée. Il n’en faudrait pas plus pour penser que l’abandon du Xserve est la preuve qu’Apple se retire du marché de l’entreprise.

Sauf qu’en fait, la situation est un peu plus compliquée que ça.

« We are not an Enterprise company. » ©Steve Jobs

Tout d’abord, une petite vidéo qui circule depuis vendredi et qui expliquerait pourquoi Apple arrête le Xserve :

Donc, Apple serait une compagnie de périphériques mobiles, et Steve Jobs n’aime pas le marché des entreprises, ce qui ferait donc deux bonnes raisons pour arrêter le Xserve. Certes, mais à mon avis, il faut chercher une explication ailleurs :

Car le Mac mini Server semble bien être le succès que j’avais prédit il y a quelques mois de cela. La demande semble très forte, et parmi mes clients, nombreux sont ceux qui préfèrent le Mac mini Server au Xserve, souvent sur-dimensionné pour eux. Et il s’agit d’un ordinateur souvent très largement suffisant par rapport aux besoins des PME/PMI :tout le monde n’a pas besoin d’avoir un monstre de puissance faisant un boucan d’enfer dans son bureau.

Malheureusement, Apple pense que le Xserve marche sur les pieds du Mac Pro, puisque son principal argument pour l’abandon du Xserve est que le Mac pro peut parfaitement remplacer le Xserve, et propose même à ce titre une version serveur du Mac Pro. C’est malheureusement faux, puisqu’outre la place qu’ils occupent, les Mac Pro ne bénéficient pas de certains avantages d’un Xserve, comme la double alimentation redondante, le contrôle du serveur via IPMI, une consommation électrique réduite [1]. Le Mac Pro représente une solution qui pourrait satisfaire certains clients… Mais certainement pas tous, hélas. Et à ce titre, la documentation de migration proposée par Apple fait curieusement l’impasse sur certains de ces points.

XsanCar il existe de nombreux marchés qui ont besoin de serveurs 1U, pour des raisons pratiques et techniques. En particulier, on penser au marché de la vidéo où Apple fait la promotion depuis quelques années de ses solutions Final Cut Server et Xsan. Quand on pense que de nombreuses écoles ou universités se sont par exemple équipées de solutions à base de Podcast Producer, logiciel qui permet de créer des contenus et les mettre à disposition sur différents médias dont, entre autres, iTunes U, la décision d’Apple a de quoi laisser perplexe, et là, je pense qu’Apple va avoir beaucoup de mal à se justifier de cet abandon[2].

Mais plus encore que l’abandon du Xserve, il y a une autre question sous-jacente qui inquiète…

Du futur de Mac OS X Server

Le Xserve était équipé de Mac OS X Server, et comme mon estimable confrère Yoann Gini l’a expliqué, il était à ce titre le fer de lance de l’équipe de Mac OS X Server. Et du coup, la disparition du Xserve peut fortement faire douter du futur de Mac OS X Server.

Pourtant, là dessus, je suis plus optimiste que Yoann. Même si un petit message d’Eric Zelenka (responsable chez Apple des produit serveurs, entre autres) a ce sujet a disparu du forum d’Xsanity, le fait qu’Apple pousse Mac OS X Server sur le Mac mini Server semble indiquer que le système aura un futur, sinon à quoi bon continuer de vendre du Mac mini Server ? Ce n’est pas toute la gamme qui a été arrêtée vendredi, mais un modèle de la gamme serveur. Et comme l’a fait remarquer un membre du forum d’Xsanity, si Apple avait voulu tuer Mac OS X Server, elle l’aurait fait en même temps.

De même, le fait qu’Apple n’ait pas présenté les fonctions de Mac OS X Server dans sa présentation de Lion n’est pas une preuve de l’inexistence de Mac OS X Server. J’ai considéré cette présentation comme un « teaser », pas comme un « trailer » de toutes les fonctions du futur Mac OS X, dont beaucoup de choses restent à montrer.

Par ailleurs, il y a une autre piste qu’Apple pourrait explorer, et cela a d’ailleurs déjà été fait : la virtualisation. Là, Apple pourrait avoir une carte à jouer, puisque Parallels et VMWare proposent des solutions pour virtualiser Mac OS X Server (avec un net avantage pour Parallels, qui dispose de pas une mais deux versions de son logiciel Parallels Server).  Pourquoi ne pas imaginer qu’Apple propose Mac OS X Server en virtualisation, par exemple sur des serveurs HP certifiés ? Complètement idiot ? Mais pourquoi pas ? Après tout, il y a bien eu des iPod HP ! Bon OK, ça n’a pas donné grand chose, mais cela pourrait être une piste : après tout, le Xserve n’avait rien de très différent au niveau matériel d’un serveur prévu pour faire tourner Windows Server 2008. Et il suffirait essentiellement qu’Apple libère un peu plus sa licence d’exploitation de Mac OS X Server pour ne pas la restreindre uniquement aux Mac pour se lancer sur ce créneau [3]. Mais dans ce cas, il serait dommage qu’Apple n’évoque pas dès aujourd’hui cette piste…

Ce qui nous emmène directement au dernier point.

L’échec de la communication vers l’entreprise

Apple ne sait pas bien communiquer avec le monde de l’Entreprise avec un grand E. Là où les entreprises souhaiteraient de la transparence et des roadmaps [4], Apple garde toujours son éternel couplet : « Nous ne communiquons pas sur les produits à venir ». Le risque est grand que l’abandon du Xserve soit une vraie douche froide pour l’entreprise et ralentisse l’intégration du Mac sur ces marchés. Malheureusement, dans un monde où iOS est désormais responsable de la majorité des bénéfices d’Apple, il n’est pas évident que cette dernière ait envie de faire des efforts particuliers à ce niveau, et c’est vraiment dommage.

La route du futur

Que conclure de cet abandon ? Difficile à dire, mais comme d’habitude, je dirais de ne pas trop s’exciter trop vite. Certes, il y a des zones d’ombres désagréables, mais avant d’aller hurler l’abandon de Mac OS X Server, j’inviterai chacun qui doit gérer ce système d’attendre le 31 janvier, au cas où Apple changerait certains de ses plans (par exemple avec la virtualisation). Ensuite, attendons les annonces officielles concernant Mac OS X Server 10.7. D’ici l’été prochain, nous aurons une vision un peu plus claire du futur qu’Apple prévoit pour sa plate-forme serveur, et nous pourrons décider s’il est alors temps ou non de changer de plate-forme (voire de métier).

Dans tous les cas, le Xserve aura été une belle aventure pour Apple. Espérons donc que la situation rebondisse d’ici quelques mois.

PS : à titre personnel, l’abandon du Xserve m’impacte peu, car je vends très peu de matériel, et ma clientèle reste orientée PME/PMI avec un net attrait pour le Mac mini Server. Mais si vous êtes administrateur dans un environnement majoritairement équipé en Xserve : courage, je suis avec vous !

  1. Même si la consommation du Xserve restait supérieure à celle de la plupart des serveurs du marché…
  2. Si elle estime d’ailleurs le besoin de se justifier, mais j’ai comme un doute, là.
  3. Voire que Larry Ellison et Steve discutent un peu pour proposer des solutions à base de serveur Sun Oracle, comme évoqué sur Xsanity…
  4. Encore que les roadmaps ne font jamais figure de vérité absolue, cf Windows depuis 1995… Mais elles ont le mérite de rassurer les DSI et les directeurs financiers.