t&t

jeudi 17 juin 2010

Indexer proprement un serveur Confluence avec GSA

Ceux qui ont déjà essayé le savent : indexer un wiki Confluence avec la Google Search Appliance n'est pas une sinécure. Il y a quelques jours, je me suis retrouvé devant un serveur Confluence totalement à genoux devant la GSA et voici comment j'ai résolu le problème.

GSA 6.2

Le serveur indiquait un nombre absolument terrifiant de sockets dans l'état TIME_WAIT. Evidemment le processeur était full (et les utilisateurs du wiki, furieux). Le premier réflexe que j'ai eu, vu que je ne connais pas la machine sur lequel tourne ce wiki et que je n'y ai pas accès, a été de régler le plus light possible les paramètres de charge d'hôte. Premier constat, ça ne change rien. Après avoir tourné la doc dans tous les sens, un détail m'a sauté aux yeux : il s'agit bien d'une charge d'hôte et non de machine. Ainsi si le serveur fait tourner plusieurs services ou si ces services sont accessibles via des aliases ou des adresses IP, il faut toutes les déclarer. Et oui... Ceci dit, déclarer tous les aliases du wiki n'a pas eu un impact phénoménal : le serveur était toujours (presque) autant surchargé. Il fallait donc trouver une autre solution...
Je suis alors allé faire un tour approfondi dans les journaux et rapports et il est vite devenu évident que le problème venait de Confluence. J'ai d'ailleurs trouvé à ce sujet une issue intéressante (et non résolue) sur le tracker d'Atlassian. Confluence n'est pas un foudre de guerre en ce qui concerne la gestion du cache. Il est même plutôt mauvais. Et pour contourner le problème, une seule solution : le robots.txt. Comme vous le savez sans doute, ce fichier, situé à la racine d'un site, sert à indiquer aux crawler comment se comporter. Bien évidemment l'exploitation de ce fichier est laissé à la charge du crawler, et nombre d'entre eux ne le respecte pas ; mais avec Google - standards obligent - c'est assez redoutable. Je me suis donc inspiré du fichier cité dans le tracker d'Atlassian et l'ai retravaillé aux vues de mes logs. Le voici : 
	
  1. # Confluence 2.X ROBOTS.TXT
  2.  
  3. User-agent: *
  4.  
  5. Disallow: /*decorator=printable
  6. Disallow: /*javascript*
  7. Disallow: /administrators.action?
  8. Disallow: /createrssfeed.action?
  9. Disallow: /dashboard.action?
  10. Disallow: /labels-javascript
  11. Disallow: /doexportpage.action?
  12. Disallow: /dopeopledirectorysearch.action
  13. Disallow: /dosearchsite.action
  14. Disallow: /dosearchsite.action?
  15. Disallow: /exportword?
  16. Disallow: /login.action
  17. Disallow: /login.action?
  18. Disallow: /searchsite.action?
  19.  
  20. Disallow: /admin/
  21.  
  22. Disallow: /display/~*
  23. Disallow: /display/*tasklist.complete=
  24. Disallow: /display/*tasklist.uncomplete=
  25. Disallow: /display/*decorator=normal
  26. Disallow: /display/*decorator=printable
  27. Disallow: /display/*focusedCommentId=
  28. Disallow: /display/*refresh=
  29. Disallow: /display/*replyToComment=
  30. Disallow: /display/*rootCommentId=
  31. Disallow: /display/*showChildren=
  32. Disallow: /display/*sortBy=
  33. Disallow: /display/*showComments=
  34.  
  35. Disallow: /download/attachments/*version= 
  36. Disallow: /download/userResources/ 
  37. Disallow: /download/resources/ 
  38.  
  39. Disallow: /label/
  40.  
  41. Disallow: /labels/
  42.  
  43. Disallow: /pages/*showComments=
  44. Disallow: /pages/*tasklist.complete=
  45. Disallow: /pages/*tasklist.uncomplete=
  46. Disallow: /pages/*decorator=normal
  47. Disallow: /pages/*decorator=printable
  48. Disallow: /pages/*focusedCommentId=
  49. Disallow: /pages/*refresh=
  50. Disallow: /pages/*replyToComment=
  51. Disallow: /pages/*rootCommentId=
  52. Disallow: /pages/*showChildren=false
  53. Disallow: /pages/*sortBy=
  54. Disallow: /pages/copypage.action?
  55. Disallow: /pages/createblogpost.action?
  56. Disallow: /pages/createpage.action?
  57. Disallow: /pages/diffpages.action?
  58. Disallow: /pages/diffpagesbyversion.action?
  59. Disallow: /pages/editblogpost.action?
  60. Disallow: /pages/editpage.action?
  61. Disallow: /pages/removepage.action?
  62. Disallow: /pages/revertpagebacktoversion.action?
  63. Disallow: /pages/templates
  64. Disallow: /pages/templates/
  65. Disallow: /pages/viewchangessincelastlogin.action?
  66. Disallow: /pages/viewpage.action?*showComments
  67. Disallow: /pages/viewpage.action?spaceKey=
  68. Disallow: /pages/viewpagesrc.action?
  69. Disallow: /pages/viewpreviouspageversions.action?
  70.  
  71. Disallow: /plugins/
  72.  
  73. Disallow: /spaces/*decorator=printable
  74. Disallow: /spaces/*decorator=normal
  75. Disallow: /spaces/blogrss.action?
  76. Disallow: /spaces/listrssfeeds.action?
  77. Disallow: /spaces/viewmail.action?
  78. Disallow: /spaces/viewmailarchive.action?
  79. Disallow: /spaces/viewthread.action?
  80.  
  81. Disallow: /themes/
  82.  
  83. Disallow: /users/ 
  84.  
  85. # End file
 
La mise en place de ce fichier robots.txt a eu l'effet escompté et les utilisateurs du wiki sont désormais satisfaits. Il a en outre l'avantage de ne faire aucune hypothèse quant aux spécifités éventuelles du crawler qui le visite et il est donc possible de gérer la charge d'hôte directement dans l'interface de la Google Search Appliance. Ce qui n'est pas le cas du fichier qui m'a servi d'inspiration...
mercredi 27 janvier 2010

Indexer un serveur sans IP connue avec GSA 6.2

J'ai eu l'occasion, aujourd'hui, de finaliser une configuration de la Google Search Appliance pour un client. Après plusieurs heures à tourner le problème dans tous les sens, j'ai réussi à faire indexer par le boîtier jaune des serveurs dont il était impossible d'obtenir l'adresse IP. Et tout ça sans avoir accès à un DNS. Voici comment.

GSA 6.2L'environnement technique de ce client est assez spécifique en raison de la configuration de ses réseaux et de l'hétérogénéité des plateformes supportant le contenu de son intranet. Lorsque j'ai dû mettre en place une solution de recherche j'ai été amené, pour simplifier le débat technique, à envisager cela en "full web". Comprenez par là en utilisant un moteur de recherche capable de travailler par crawling (et non à l'aide de connecteurs spécifiques). Le choix de GSA - validé en terme de pertinence par un groupe de key-users - m'a permis d'indexer rapidement 95% de cet intranet. Seulement voilà, quelques serveurs me résistaient pour une raison que je n'arrivait pas à comprendre : la GSA n'arrivait pas à obtenir l'adresse IP de ces machines. Normalement pour résoudre un nom, une seule solution : utiliser les DNS présents sur le réseau... Seulement voilà, un "petit" truc tout bête bloquait :

  • le DNS chargé de résoudre ces noms n'était pas un des deux DNS principaux ;
  • il n'y avait pas de récursivité vers le DNS faisant autorité pour cette zone et/ou pas de transfert de zone (le DNS tertiaire étant alors plus à jour que le principal) ;
  • le DNS tertiaire n'était pas accessible depuis le data-center ou sont hébergées les GSA...

Pour résoudre ce problème, il fallait effectuer une modification de la topologie DNS... Et vu le temps que j'avais mis à obtenir un accès de quelques heures dans le data-center (deux bonnes semaines), une telle modification, je n'ose même pas imaginer !

Heureusement, la nouvelle mouture (6.2) de GSA intègre une fonctionnalité bien intéressante ici : le remplacement DNS. Cette fonctionnalité - déjà courante dans des outils réseau grand public - fait enfin son apparition officielle chez Google et permet de forcer certaines entrées à la place du DNS faisant autorité...ou non. Je ne suis pas sur que que ce soit très respectueux des RFC, mais cela m'a permis de résoudre assez facilement ce serpent qui se mordait la queue :

DNS override sous GSA 6.2 

Alors, pour ceux qui hésiteraient encore, je n'aurais qu'un mot : surchargez les DNS...Ça permet de se sortir de problème de conversion de nom de domaine sans obliger à modifier la topologie de résolution de noms !

Site propulsé par Drupal !    Contenu mis à diposition sous un contrat Creative Commons