darkBlog

Il y a quelques temps, nous avons entrepris d'upgrader nos serveurs Domino en 7.0.2 FP1 (Windows 2003 R2), ce qui impliquait également de passer notre serveur Sametime de 6.5.1 à 7.0 (ou 7.5, mais avons choisi la 7.0 pour privilégier une migration en douceur - comme c'est drôle d'écrire ça rétrospectivement).

La migration des serveurs Domino en tant que telle n'a posé aucun problème : installation de la version 7.0.2, puis du fix pack 1, redémarrage du serveur, on enchaine derrière avec quelques manipulations administratives (MAJ du design des bases système, recréation des index full-text, etc), et hop, emballé c'est pesé. Je ne peux pas en dire autant de Sametime, puisqu'à ce jour nous n'avons pas encore réussi à le refaire marcher (ça fait maintenant un peu plus de 15 jours). Petit résumé très coloré.

Cela a démarré en beauté, puisqu'une fois Sametime 7.0 installé par dessus la 6.5.1, le premier redémarrage du serveur Domino s'est solvé par un crash de la tâche HTTP (une belle boite de dialogue fermer/détail des familles). Quelques renseignements pris et gouttes de sueur plus tard, il s'avère que la tâche HTTP crashe quand Sametime 7 tourne sur Domino 7.0.2. Joli. La solution ? Revenir à une version antérieure de Domino, ou du moins de la JVM.

Appréciant moyennement la blague, j'installe sur mon poste un Domino 7.0.1 en catastrophe afin d'en récupérer le contenu du répertoire jvm/. Une fois celui-ci copié sur le serveur, hop, second démarrage. Super, pas de plantage de la tâche HTTP. Par contre, la moitié des services de Sametime ne se lance pas. On a beau attendre, ça ne décolle pas. Pourtant, pas d'erreur particulière dans les logs. Et forcément - vous vous en doutez - impossible de se connecter au serveur. On a passé le reste de la journée à tweaker les notes.ini et sametime.ini, à redémarrer le serveur, rien à faire, Sametime n'a jamais voulu repartir. Une installation toute neuve sur un Domino 7.0.1 vierge n'a pas donné de meilleur résultat. Et pire que tout : nos backups ne marchaient même plus. Dire que l'atmosphère était plutôt pesante en fin de journée serait un bel euphémisme.

Le lendemain matin, particulièrement frustré, je me lance de bonne heure à l'assaut des forums à la recherche du moindre indice. Je tombe alors par hasard sur la technote suivante : Issues starting a Sametime server using Terminal Services or Microsoft Remote Desktop. J'en aurais laissé tomber mon bol de chocapic. Dans cette technote, il est expliqué noir sur blanc et sans honte que les services de meeting et certains services du serveur de communauté ne démarrent pas si Sametime est lancé depuis Microsoft Remote Desktop. Forcément, pour la migration, nous avions désactivé les services et n'utilisions que Remote Desktop pour prendre la main sur les machines. Vous conviendrez que la relation entre les deux était difficile à établir.

Arrivé au bureau, j'installe RealVNC sur le serveur et relance le tout. Comme par magie, l'ensemble des services démarre correctement. Déception, mais pas vraiment surprise non plus - je commençais à être habitué - : Sametime ne marche pas beaucoup mieux. Et une étrange ligne d'erreur est apparue à intervalle régulier dans les logs :

Process e:\Lotus\Domino\STT120MCU.exe (4884/0x1314) has terminated abnormally

Quelques recherches sur les forums plus tard (c'est un réflexe qu'on adopte vite quand on a un problème avec Sametime), il apparaît que l'origine de l'erreur est - attention, respirez un bon coup car c'est énorme - la suivante : Les meetings ne peuvent fonctionner si le serveur utilise l'Hyperthreading. Un problème encore plus improbable que le précédent, qui l'aurait crû ? Je vous laisse imaginer la tête de notre client (et du responsable du parc informatique) quand on lui a annoncé qu'il fallait aller en salle machine pour éteindre le serveur et bidouiller dans le BIOS. Mais on l'a fait. Et on n'a plus revu cette erreur.

Là, à ce moment de la lecture du billet, vous devez probablement vous dire qu'avec tout ce qu'on a subi, on mériterait d'avoir un serveur Sametime qui marche. Je le pense aussi. Néanmoins, ce n'est toujours pas le cas ; j'ai un PMR d'ouvert depuis peu chez IBM et pour le moment je dialogue avec les techos et hasarde quelques commandes et vérifications sur la machine. Il y a quelques pistes prometteuses, toutefois, et le support d'IBM est plutôt réactif, ce qui est bien.

Le plus drôle dans l'histoire, c'est que vous devez vous dire que ce mec n'a pas de bol et que c'est fini, mais en fait non, sachez que j'ai plein d'autres anecdotes du même acabit sur Sametime. Tenez, par exemple, j'ai voulu l'installer sur un vieux serveur Windows 2000 à titre expérimental. Outre le fait qu'il se soit plaint que l'écran soit en 16 couleurs (voir capture d'écran plus bas), j'ai aussi eu le droit à l'erreur du tu as un répertoire qui commence par un 'u' dans ton chemin, et c'est mal. Je pourrais encore continuer pendant quelques temps.

Pourquoi vous dire tout ceci ? Ce n'est pas pour cracher mon venin ni pour le plaisir de faire du FUD (pour rappel, c'est plus ou moins mon métier, et aussi mon gagne-pain), mais honnêtement, je trouve ça inacceptable de proposer sur le marché un produit aussi capricieux et bancal et qui laisse la sérieuse impression d'avoir été codé par des stagiaires, surtout quand on est habitué à la robustesse et flexibilité de Domino. Alors certes, IBM continue de lui ajouter des fonctionnalités, le client Lotus Sametime Connect 7.5 est vraiment très agréable à utiliser et le 7.5.1 présenté à la Lotusphere apporte des nouveautés sympathiques (chats par onglets, support de la vidéo, etc), mais le hic, c'est qu'il faudrait déjà arriver à faire marcher correctement le serveur. Car si vous regardez bien, la majorité des technotes citées ci-dessus sont également valables pour la 7.5.

Pour ma part, j'arrête là les frais avec Sametime. A moins de trouver une solution avec le support IBM ou de mettre la main sur un admin averti (et si vous en êtes un, n'hésitez pas à me contacter), je vais éviter au possible d'y toucher. C'est bien dommage, car Sametime est un beau produit quand il marche. C'est bien dommage.

Comme vous le savez, en web il est possible d'accéder à un document directement par son UNID, mais aussi par l'intermédiaire d'une clé, clé qui doit correspondre au contenu de la première colonne triée de la vue en question. C'est un moyen très commode de mettre en place des URL significatives dans les applis web Domino, et c'est bien plus sexy et parlant qu'une suite de 32 chiffres hexadécimaux, comme le démontre sans ambiguïté possible l'exemple fictif suivant :

http://host/darkblog.nsf/billets/faites-un-geste-pour-la-france?opendocument

Seulement voilà, quand les documents en question sont protégés par des champs lecteur, ça peut vite tourner au drame. En effet, que se passe-t-il lorsqu'on tente d'accéder anonymement à un document protégé via son UNID ? Domino détermine qu'Anonymous n'a pas accès au document et retourne une demande d'authentification. Jusque là, tout va bien. Maintenant, que se passe-t-il lorsqu'on réitère la même procédure mais en ouvrant le document protégé via sa clé ? Et bien c'est facile : comme on n'a pas accès au document, il n'est pas listé dans la vue, du coup la clé n'est pas retrouvée, et là je vous le donne en mille : une belle erreur 404 des familles.

Ce genre de situation n'est pas censé se produire dans un cadre de navigation classique dans une appli, mais dès lors que les utilisateurs commencent à bookmarker des pages et/ou à se les refiler par mail ou par Sametime (et on saurait difficilement leur reprocher), c'est là que les ennuis commencent.

Si l'appli requiert nécessairement l'authentification des utilisateurs, cela peut se régler aisément en paramétrant correctement l'ACL ou en rajoutant systématiquement &login aux URLs des liens. Dans le cas contraire, je ne vois malheureusement pas de solution vraiment efficace, ni même triviale.
La solution que j'ai mise en place de mon coté - puisque j'ai été confronté à cette deuxième situation vendredi dernier - a consisté à capturer l'erreur 404 avec un masque spécial $$ReturnGeneralError, à extraire de l'URL la clé du document, puis à rechercher l'UNID du document par rapport à sa clé avec un agent (l'agent s'exécutant en tant que signataire, il voit tous les documents, lui), et enfin à rediriger l'utilisateur vers le document via la syntaxe UNID?opendocument. Et cela fonctionne plutôt pas mal. Cela aurait même pu être propre s'il avait été possible d'exécuter des agents au WQO dans le masque $$ReturnGeneralError, malheureusement, comme il s'agit d'un masque spécial, ce n'est pas le cas (pff) et mon implémentation passe par une redirection javascript (oui, c'est mal, mais je n'ai pas trouvé mieux).

Tout ça pour rebondir avec grâce et élégance sur le titre du billet : si vous utilisez l'ouverture de document par clé, faites attention aux restrictions en lecture.

Et votez pour que les Fatals Picards nous représentent à l'Eurovision 2007 (inscription requise). Pour une fois qu'on nous propose de vrais artistes et pas une énième ressucée de Céline Dion, c'est le moment où jamais de faire entendre sa voix. Pour ceux qui ne connaissent pas, petite sélection : Dors mon fils, Bernard Lavilliers, Goldorak est mort et bien entendu leur titre pour l'Eurovision : l'amour à la française.

Hasard du calendrier ou pas, ils sont de passage la semaine prochaine au Café de la danse (XIe), et j'y serai !

Une nouvelle fournée de groupes viennent d'être confirmée pour le Hellfest 2007, dont... Emperor et Moonspell ! Et ce, à coté des groupes déjà confirmés tels que Immortal, Mayhem, Napalm Death ou encore Behemoth. Et il en reste encore pas mal à être annoncés. Du jamais vu en France ; ça va tout simplement être une tuerie. Je ne sais pas pour vous, mais de mon coté le pass 3 jours est imprimé, sur la table et prêt à être dégainé.

La Lotusphere 2007 s'est terminée il y a maintenant 3 semaines, et bien que vous ayez déjà dû en lire l'essentiel ailleurs, j'ai quand même fortement envie de revenir dessus. Car il y a beaucoup de choses à en dire. Dans ce premier billet, je vais revenir sur l'événement en tant que tel et vous dire ce que j'en pense, sachant que c'était ma première Lotusphere, que c'était tout nouveau pour moi et que je ne savais pas à quoi m'attendre. Dans un second billet (qui viendra je ne sais pas quand, la Wii présentement à 30cm de ce PC influant beaucoup sur ma motivation), je reviendrai sur les nouveaux produits présentés (car il y en a eu beaucoup) comme sur les nouveautés des produits existants.

L'événement

Je n'apprends rien à personne, la Lotusphere est l'événement annuel majeur dans le monde Lotus, la grande messe lors de laquelle les gourous d'IBM et autres partenaires prêchent la bonne parole à des hordes tantôt passionnées, tantôt sceptiques - mais jamais indifférentes - à l'univers des produits Lotus et plus globalement de la collaboration en général (notons la présense d'un certain nombre de SharePointiens curieux). Cette édition 2007 s'est déroulée à Orlando, Floride, dans les deux hotels les plus prestigieux du parc DisneyWorld (Le Swan et le Dolphin -- on me souffle d'ailleurs dans mon oreillette qu'il s'agit d'un lieu récurrent), et autant le dire de suite, tout est fait dans la démesure et prévu pour en mettre plein les yeux. Un vrai show à l'américaine, à des années lumières des bien plus modestes Lotusphere comes to you. On comprend mieux les 2500$ de frais d'inscription devant un tel étalage de fric. Mais qu'importe, on est là pour célébrer notre métier voire notre passion, alors autant profiter un maximum de ce qui nous est proposé. Car des choses passionnantes à faire et à voir, il y en a bien plus que de temps imparti.

Ohhh, comme ils sont mignons chez Mickey...

Je ne savais pas vraiment à quoi m'attendre, ni si cela valait le coup/coût, mais disons le clairement : j'ai été très largement conquis par cet événement, et ceux qui me connaissent savent que je taris bien plus facilement d'éloge que de critique.

La Lotusphere est un événement exceptionnel car c'est l'occasion unique de rencontrer des tas de gens qui gravitent autour du même métier et qui rencontrent les mêmes problématiques que soit. Entre 6000 et 7000 personnes étaient présentes, de toutes les nationalités imaginables, et même de pays dont je n'avais jamais soupçonné l'existence auparavant (bon ok, je suis particulièrement mauvais en géo). Ca a été notamment pour moi l'occasion de rencontrer (non sans peine) les camarades Smicky et Olivier de Dominux (dont j'ai plein de photos sympathiques -- faire offre en commentaire), mais aussi d'autres personnes avec qui j'ai pu tenir des échanges franchement intéressants, dans la mesure de mon piètre anglais.

La horde barbare des geeks au sac à dos jaune

C'est aussi l'occasion de rencontrer des tas d'éditeurs via le Product Showcase - sorte de salon en marge de l'événement - qui proposent des produits et/ou des services liés de près ou de loin au secteur des produits Lotus et Websphere. Et vous savez quoi ? Aussi pompeux que cela puisse paraître, c'est un aspect vraiment intéressant de la Lotusphere, car il y a de bons produits à découvrir. Vraiment. Red Hat y etait. OpenNTF aussi. Même Google était là. Mention spéciale pour la très sympathique équipe d'Ytria (majoritairement francophone), qui édite l'excellent ScanEZ (vous ne connaissez pas ? Essayez le, c'est du bonheur en barre).

La Lotusphere, c'est l'occasion de participer à des sessions de qualité (la plupart du temps, car il y a eu d'énormes blagues aussi) élaborées par les gens d'IBM ou par des partenaires qui connaissent (la plupart du temps) leur sujet. Et il y en a pour tout les goûts : du développement avancé à la stratégie business en passant par l'administration ou encore la découverte des nouveaux produits. Le planning est suffisamment bien pensé pour que deux sessions d'un thème identique ne se chevauchent pas sur un même créneau horaire (à de rares exceptions près). Et les sessions majeures sont répétées une voire deux fois, de sorte qu'il est quasi impossible de louper une session que l'on souhaite vraiment voir. Il s'agit là de l'attraction principale de la Lotusphere, et même si on a la tête comme une citrouille à l'issue de 6 ou 7 heures de sessions en anglais, ça vaut largement les heures qu'on aurait pû perdre passer à éplucher des PDF à droite et à gauche.

Manifestement mes 2500$ sont aussi partis dans de la coke

L'un des aspects qui m'a semblé le moins mis en avant, et qui pourtant s'est avéré des plus intéressants, ce sont les labs dans lesquels on peut notamment rencontrer directement les développeurs des produits. Pour vous donner une idée du truc, imaginez un open-space énorme dans lequel on a sorti les développeurs barbus et quarantenaires de leur cave pour les exposer aux innombrables questions et remarques impitoyables de gens comme moi. C'est une expérience fondamentalement formidable. Les développeurs du moteur HTTP de Domino doivent désormais me détester tant je les ai harcelé. Tenez, par exemple, vous vous souvenez mes galères avec le webdav ? Très loin des call-center en Ecosse ou en Irlande et des échanges sans fin via les PMR, j'ai pu directement exposer le problème aux gars qui passent leurs journées à coder le moteur web. Et là, 2 ou 3 minutes de réflexion, une question à son collègue par Sametime, et hop, la solution est sur la table. Bon, en l'occurence pour ce problème, c'est une limitation de Lotus Designer et du format NSF, et il n'y a pas vraiment de solution, mais vous n'imaginez pas le nombre de problèmes que j'ai pu résoudre sur place, ou encore d'astuces-non-documentées-mais-pourtant-tout-à-fait-fonctionnelles que j'ai pu récupérer. Notre éternel problème de timeout dans WPS 5.1 ? Hop, réglé avec une instruction à rajouter dans un fichier de conf. Mon problème d'upload de fichiers volumineux via les File upload control qui plante ? Réglé avec une variable peu orthodoxe dans le notes.ini. Et c'est valable pour les problèmes actuels, mais aussi à venir. Car j'ai leur carte de visite maintenant, à ces gens là, et je sais qui contacter en cas de soucis. Inestimable.
Mais les labs, ce n'est pas que ça, c'est aussi l'occasion de découvrir les travaux expérimentaux d'IBM qui peut-être déboucheront sur de vrais produits, comme cette démonstration de mashup de Sametime et de Google maps tout en Javascript qui m'a franchement laissé sur le cul (en remplacement du vil toolkit STLinks et de son hideuse applet Java), ou encore de prendre en main les nouveaux produits accompagné des développeurs qui vous guident au travers d'exemples simples. C'est ainsi que j'ai pû découvrir de mes propres mains Lotus Expeditor ainsi que Websphere Portlet Factory. Je me répète peut-être, mais ça, ça vaut tous les PDF du monde. Inestimable, je vous dis.

On est à chier, on est pas digne...

Conséquence de tout ceci, la Lotusphere, c'est la possibilité de cerner la tendance qui se dégage pour les mois/années à venir chez IBM, et dans une moindre mesure chez les concurrents. Bien sûr, la bonne volonté d'IBM ne crée pas toujours un marché (cf l'expérience désastreuse de Workplace, en parallèle de la croissance inattendue des produits de la gamme Lotus -- +30% en 2006 !), néanmoins, savoir vers où Big Blue va mener sa barque, en qualité de consultant (oui, bon, ok, c'est un titre pompeux, mais bon, nos clients nous consultent pour notre expertise, non ?), c'est, il me semble, un atout indéniable pour établir, ou du moins suggérer, la stratégie future des systèmes d'information de nos clients (ouais je me la pète un peu, mais réfléchissez-y, et quelle que soit votre échelle de décision et/ou d'influence, ne sommes-nous pas tous influenceurs quelque part ?). Vous pouvez en penser ce que vous voulez, mais je pense que cela fait parti intégrante de notre valeur, et plus encore, de notre devoir.

Voyez, je vous ai pas menti, +30%, c'est marqué à droite sur le slide

Comme a pu le dire Smicky chez Julien (commentaire #4 -- Julien, à quand des permalinks sur tes commentaires ?), la Lotusphere, ça rebooste la motivation. Sortez un peu le nez de vos lignes de code LotusScript qui n'en finissent pas, et regardez un peu ce qui se profile autour de vous. L'avenir de la gamme Lotus n'est pas terne, loin de là. Les produits Lotus ne sont pas morts, comme on peut lire fréquemment dans les magazines de "décideurs". Le tour de force qu'est en train de réaliser IBM est magistral ; réussir à ramener sa gamme de produits existants du siècle dernier au siècle courant, tout en proposant en parallèle des produits réellement innovants (Lotus Connections, Lotus Quickr), c'est tout simplement énorme. Même Fred Cavazza en parle, c'est vous dire. Sincèrement, à l'issue de cette Lotusphere 2007, il n'y a aucune raison d'être pessimiste. J'espère que l'avenir des produits Lotus sera radieux, car ils le méritent. Je laisse la place aux marketeux d'IBM pour concrétiser cela (encore que, je ne suis pas tout à fait sûr que ce soit une bonne idée. J'ai comme un goût amer en bouche, un goût qui étrangement me rappelle Workplace).

Enfin, la Lotusphere, c'est aussi l'occasion d'aller s'éclater une soirée durant dans un des parcs DisneyWorld (où la témérité des français à l'Expedition Everest n'est désormais plus à prouver), et aussi de boire plein de bières -- le seul alcool proposé en flot continu durant ces 5 jours. De la bud light. De la Heineken Light. De la Corona. La quintessence de la bière excécrable, en somme. (Si quelqu'un d'IBM me lit, sachez qu'il y a un message subliminal dans cette phrase).

Conclusion sur l'événement

Il y a pas mal de choses que j'ai passé sous silence, comme les Hands-on sessions au cours desquelles on a la possibilité de s'exercer sur un logiciel via un cas d'école, ou encore la possibilité de préparer et passer ses certifications sur place. Comme je l'ai dit en guise d'introduction, il y a bien plus de choses à faire à la Lotusphere que de temps accordé. J'espère vous avoir donné un aperçu objectif de ce qu'est la Lotusphere pour vous permettre de mesurer la portée cette phrase. Et pour faire écho aux propos de Julien (commentaire #6), non, bien sûr, le passage par la Lotusphere n'est pas obligatoire pour mener correctement sa boutique dans le monde IBM. N'empêche, si on en a la possibilité, ça serait vraiment dommage de s'en priver. Bien que ce soit peu probable, j'espère pour ma part avoir l'occasion d'y retourner l'année prochaine. Le détail des nouveautés annoncées dans le prochain billet.

Je ne sais pas si ce problème est particulièrement connu, n'empêche, il vient de me faire perdre pas mal de temps : à partir du moment où l'on pose un champ partagé sur un masque public, ce dernier se comporte comme un masque tout à fait classique classique (comprendre : non public). La solution ? bidouiller pour ajouter des champs $PublicAccess aux champs partagés, ou.. ne pas en utiliser, à défaut d'une meilleure idée ?

PS : A noter que dans un contexte similaire, les sous-masques ne posent aucun problème.

Vu à l'aéroport d'Indianapolis:

Ils sont quand même forts les américains.