Feeds:
Articles
Commentaires

En jetant un œil aux stats de notre catalogue, un chose m’a frappé :

Recherches Résultats Moyenne
Octobre 2009 84293 86 988 631 1 032
Novembre 2009 66374 77 517 430 1 168
Décembre 2009 48293 11 565 086 239
janvier 2010 58770 5 978 708 102
Février 2010 62946 5 862 575 93

Le nombre moyen de résultats s’est fortement réduit.  Notamment à partir de décembre.

A part l’effet bénéfique des formations à la méthodologie documentaire, je ne vois pas d’autres explications.

Enfin quelques chose de positif, ne boudons pas notre plaisir.

Publicités

Le paramétrage des sources est relativement simple, pourvu que :

  • La base soit répertoriée dans la liste présente sur le site d’OCLC. C’est le cas le plus simple, il suffit de relever le paramétrage et de l’insérer dans votre fichier. Seul hic, la dominante est anglo-saxonne, ce qui signifie que vous ne trouverez pas les paramétrages pour les bases « françaises », et que même si vous les trouvez, il faudra vérifier que l’URL est bien la bonne. Exemple : le paramétrage de Lexisnexis pointe vers la bas anglo-saxonne, vous devrez remplacer l’URL par celle que vous utilisez couramment.
  • La base ne soit pas trop tordue dans son mode de fonctionnement. C’est heureusement le cas la plupart du temps.

Les liens vers les bases auront comme URL : http://ezproxy.votresite.fr/login?url=http://www.mabase.com

Après le processus d’authentification, l’URL deviendra : http://www.mabase.com.ezproxy.monsite.fr/

On configure l’accès aux bases dans le fichier config.txt après l’entrée ## Databases begin. Le paramétrage le plus simple contient :

  • L’intitulé de la base précédé par Title. Il est purement informatif. On évitera d’utiliser deux fois le même. Rien n’est précisé à ce sujet mais de manière générale, j’éviterai d’utiliser guillemets et autres accents.
  • Une URL précédée par URL. On indiquera l’URL qui correspond à la page sur laquelle vous souhaitez pointer. Si vous souhaitez pointer vers un formulaire de recherche au lieu de la page d’accueil, il suffit de récupérer l’URL correspondante et de l’indiquer ici.

C’est tout. Au revoir et à bientôt et n’oubliez pas le guide

Bon…presque…ça serait trop beau. Dans la plupart des cas, ça suffit. Faut tester. On n’oubliera pas de redémarrer le service pour que les modifications soient prises en compte. On testera non seulement l’accès mais aussi la recherche et tous les services proposés par la base (sauvegarde, veille, impression, envoi par mail, flux rss, export PDF…). En effet, le fait d’accéder à la base ne garantit pas le fonctionnement de tous les services.

Si par exemple, vous voulez insérer un lien vers un formulaire de recherche dont l’URL est http://formulaire.mabase.com et que dans votre paramétrage vous avez indiqué comme URL http://www.mabase.com, vous aurez soit un message d’erreur, soit le lien non « proxyfié ». En effet, Ezproxy considèrera les URL du type http://www.mabase.com et http://www.mabase.com/etc mais pas http://formulaire.mabase.com. Il faut donc ajouter une ligne du type Host formulaire.mabase.com

Autre rigolade, vous accédez à votre base, et même au formulaire de recherche. Par contre, rien ne se passe quand vous validez votre formulaire. C’est encore un coup de ce blagueur de Javascript qui n’est pas proxyfié. Faut tout lui dire à ce Ezproxy ! On va donc ajouter une ligne DJ mabase.com (DJ, c’est pour Domain Javascript) qui indiquera que le javascript doit être proxyfié aussi. Logiquement, ça devrait suffire. Si vous avez utilisé Host comme indiqué ci-dessus, ça devrait suffire aussi. Toutefois, la documentation n’étant pas très explicite à ce sujet, et si vous n’arrivez toujours pas à valider votre formulaire, ajoutez donc HJ mabase.com (HJ pour Host Javacscript) et vous m’en direz des nouvelles.

Vu comme ça, c’est du bricolage. Rassurez vous, ça l’est ! Et ça ne prétend pas être autre chose ! Mais ça marche, ça marche même très bien. Dans 95 % des cas, vous repiquerez le paramétrage sur le site d’OCLC, ou alors deux lignes vous suffiront pour paramétrer correctement l’accès à vos base.

Passons au cas Elnet.fr, la base Net Permanent des Editions Législatives.  On prend les choses dans l’ordre :

Seul hic, il faut cliquer sur le bouton identification en haut à gauche pour accéder à la base proprement dite. Et là, c’est le drame. Plus rien ne marche, l’URL n’est plus proxyfiée et on vous demande des codes d’accès. J’ai l’impression que le mécanisme utilisé est Shibboleth. Deux choses à remarquer:

  • le bouton identification utilise du javascript (regardez dans la barre d’état du navigateur). On va ajouter DJ editions-legislatives.fr
  • l’URL devient https://secure.editions-legislatives, on va donc ajouter Host secure.editions-legislatives.fr (pour être propre, il faut l’ajouter avant le DJ précedent)

Enfin, on remarquera que ce n’est plus une connexion http qui est utilisée mais https, autrement dit une connexion sécurisée. Et là, Ezproxy n’est plus d’accord. Pour proxyfier ce type de connexion, il va falloir utiliser un certificat SSL, qui authentifie cette connexion sécurisée. Petit hic, ces connexions utilisent le port 443. Il va donc falloir être très mais alors très gentil avec votre CRI et leur demander d’ouvrir ce port à l’humble vermiceau que vous êtes. Ensuite dans le fichier config.txt, on va indiquer le port à utiliser en ajoutant LoginPortSSL 443 avant la définition des bases. On va pouvoir passer à la gestion du certificat. Ezproxy vous permet de créer un certificat « maison » qui va vous permettre de tester votre connexion. On verra ensuite comment obtenir un vrai certificat en bonne et due forme. On va ouvrir la page d’administration d’ezproxy, qui doit se trouver du côté de http://ezproxy.monsite.fr/admin. Ensuite on va accéder à page de gestion des certificats en cliquant sur Manage SSL (https) certificates, puis Create New SSL Certificate pour créer un certificat. Remplir ensuite le formulaire et cliquer sur self-signed certificates pour valider votre formulaire. Ensuite in faudra taper ACTIVE dans la case prévue à cet effet pour activer pour certificat. Redémarrer ensuite le service, et le tour est joué. Quand vous cliquez sur identification lorsque vous accéder à ELnet, l’URL suivante est proxyfiée et vous voilà authentifié sur votre base.

A partir de là, on peut mettre le champ’ au frais. Seul petit problème, votre certificat est reconnu comme un certificat pas vraiment conforme par les navigateurs qui vont produire une alerte de sécurité lors de cette connexion https. Soit, il suffit d’autoriser la navigation malgré tout, mais ça risque de freiner quelques utilisateurs. I l faudra être de nouveau très très gentil auprès de votre CRI et lui demander si par hasard, l’université n’aurait pas au fin fond d’un tiroir un certificat valide qui ne fait que vous attendre. On reprendra alors la manip précédente non pas en créant un certificat mais en important un certificat. Et, là, vous pouvez déboucher la bouteille, sortir les petits fours et boire un coup à man santé !

Ajout du 04/02/2010

A la demande des Editions Législatives, je précise que le processus d’accès distant décrit ci-dessus entre dans le cadre d’un licence autorisant cet accès distant et liée à un abonnement à la base Elnet.fr. L’accès distant se fait via une authentification, et n’est aucunement une tentative de piratage de la base Elnet.fr.

Résumé de l’épisode précèdent : dans un élan de générosité, Davidolib a décidé d’offrir à ces usagers des accès distants aux bases de données pour lesquelles son établissement claque des sommes folles . Comme Archimed s’occupait de son portail, il leur a demandé de mettre ça en place. Mal lui en pris, car Archimed n’en fait qu’à sa tête et a mis en place un mécanisme où tout le monde doit s’authentifier, même si on est dans la BU, ce qui exclut les extérieurs qui ne sont pas dans l’annuaire LDAP. N’écoutant que son courage, Davidolib décrypte les scripts et dévore la documentation d’Ezproxy. Au bord de la crise de nerf,  il parvient à comprendre l’affreux piège mis en place par le funeste prestataire. Il décide alors de zapper la méthode Archimed pour arriver à ses fins et vous fait part aujourd’hui de ses trouvailles.

Avertissement : ce que je vais décrire ci-après est basé sur ma propre expérience d’Ezproxy. Il se peut que les choses soient différentes chez vous.

Configurer Ezproxy se fait essentiellement en modifiant deux petits fichiers sur votre serveur dans le dossier  Ezproxy :

  • user.txt qui va contenir les données propres au mécanisme d’authentification. Le logiciel permet  des filtrages assez poussé à base de groupes, que je n’ai pas eu besoin d’utiliser. Je vous renvoie donc à la documentation en ligne à ce sujet.
  • config.txt qui va contenir la description technique de chaque base dont a besoin le logiciel pour fonctionner. C’est aussi ici qu’on va exclure, inclure ou auto-authentifier des tranches d’IP.

Archimed utilise un système de ticket qui reprend les mécanismes d’authentification d’Incipio sur le LDAP.  Vous avez dans ce cas des URL du type :

http://votreportail/incipio/ezp/getTicket.asp?URL=http://www.doctrinal.fr

Si on essaie maintenant d’appeler directement Ezproxy SANS passer par ce système de ticket à la noix de coco, on utilisera l’URL suivante :

http://ezproxy.votreportail/login?url=http://www.doctrinal.fr/

Vous risquez alors d’arriver non pas sur votre système d’authentification mais sur l’authentification native d’ezproxy. Il va falloir modifier le fichier user.txt : on va désactiver les informations qui indique une connexion LDAP  en collant un # devant chaque ligne et on va indiquer à ezproxy qu’il faut utiliser CAS en ajoutant l’entrée :

::CAS
LoginURL https://l’url du formulaire d’authentification cas
ServiceValidateURL https://l’url du service de validation de cas
/CAS

Il faut ensuite enregistrer votre fichier et redémarrer le service pour que les modifications soient prises en compte. Pour cela, Démarrer – Outil d’administration – Services puis cliquez sur l’onglet Standard, trouvez le service Ezproxy, clic droit et enfin redémarrer. Rééssayer maintenant l’URL modifiée et vous devriez arriver sur votre formulaire CAS habituel.

Jusque là, pour vos usagers,  concrètement, ça ne change rien. Pour nous, ça change TOUT. Maintenant, les modifications que vous allez apporter, par exemple au paramétrage des tranches IP sera pris en compte. Exit les tickets d’Archimed, on reprend la barre !

J’ai pour ma part paramétré les IP ainsi :

  • IP de la BU : on squeeze Ezproxy
  • IP de l’université : on passe par Ezproxy SANS authentification
  • Tout les reste de l’univers passera par Ezproxy AVEC authentification

Cette fois, c’est le fichier config.txt qu’il va falloir modifier. On va ajouter ce paramétrage au début du fichier entre les indications du genre Name, Option, LoginPort, etc et la partie qui débute par ## Databases begin où seront indiquées les descriptions techniques des bases proxyfiées. La syntaxe est la suivante :

  • ExcludeIP xxx.xxx.xxx.xxx-yyy.yyy.yyy.yyy : toutes les IP comprises entre ces deux IP ne passeront pas par ezproxy
  • AutoLoginIP xxxx.xxx.xxx.xxx-yyy.yyy.yyy.yyy : toutes les IP comprises entre ces deux IP passeront par le proxy sans authentification (en fait, avec une identification automatique)

Ces deux lignes peuvent être utilisées plusieurs fois.

J’ai utilisé ce paramétrage car historiquement seules les IP de la BU étaient déclarées auprès des éditeurs. On a rectifié le tir mais ainsi je suis sur que toutes les IP de l’université auront bien accès à nos ressources.

Lors du prochain épisode, Davidolib plongera dans la jungle du paramétrage des bases et affrontera le « cas » Net permanent des Editions Legislatives

Les vidéos Vodpod ne sont plus disponibles.

posted with vodpod

Fredo Viola a signé un des plus bels albums de 2009. Mariage des voix, pure émotion, superbes mélodies. Un artiste à suivre sans aucun doute.

Elvis Presley & Muhammad Ali, 1973

Ezproxy est une solution proposée par OCLC qui permet de proposer des accès distants via un service d’authentification. Il est dans l’ensemble assez simple à configurer, bien que la documentation soit famélique. J’ai été confronté à plusieurs problèmes, d’où l’idée de cette série de billets, qui je l’espère, pourra aider les personnes qui sont dans la même situation.

Je n’ai pas installé Ezproxy personnellement, c’est Archimed qui s’en est chargé. En effet, c’est la solution retenue par Archimed pour gérer les accès distants sur sa solution Incipio. A titre d’information, Ezproxy est installé sur un serveur dédié afin de ne pas surcharger le serveur web. A part ça, la documentation (en ligne sur le site d’OCLC) même si elle est maigre, me semble claire; l’installation ne devrait pas poser de problème.

Archimed a ensuite  créé un encart avec des liens pour que nous puissions tester les accès distants aux bases auxquelles nous sommes abonnés. Il ont fourni (après demande insistante) une documentation…de 4 pages qui vous indique comment déclarer une nouvelle base. Soit 4 pages, c’est pas terrible, mais dans la mesure où ce n’est pas un logiciel Archimed d’une part, et où d’autre part la documentation est éparse et peu fournie sur le site d’OCLC, on ne peut pas leur en vouloir, enfin pas pour ça (bon, attendez la suite ;-))

On modifie donc toutes les URLs de nos bases pour proposer ces accès distants. Tout baigne, quand on veut accéder à une base de données, on est redirigé vers l’écran d’authentification de l’université (ici, c’est CAS qui gère l’authentification sur le LDAP), puis on est redirigé vers la base de données en passant par ezproxy… Et on s’aperçoit avec effroi que ce mécanisme s’applique aussi aux postes de l’université et donc de la BU aussi. Résultats des courses : il faut s’authentifier même si vous utilisez un poste de la BU ou un poste de l’université, et bien sur le public « extérieur », qui n’est pas dans le LDAP, se voit privé de toute consultation de base de données.

On jette un oeil à la doc, on s’aperçoit qu’on peut exclure des tranches IP, on envoie donc nos remarques et désidératas à Archimed. Sans réponse (mince, on a déjà payé la facture !), on se dit qu’on va se débrouiller tout seul, on parcourt en long, en large et en travers la documentation pour comprendre comment exclure des tranches d’IP de ce mécanisme. On modifie donc le paramétrage…et on s’aperçoit que ça ne marche toujours pas. On s’arrache les cheveux, on remarque que l’url fournie par Archimed pour accéder aux bases ne ressemble en rien à l’URL dont parle la doc d’ezproxy, on remarque aussi qu’Archimed nous parle d’un accès par ticket. Dans la doc, on regarde comment fonctionne ce type d’accès : un ticket est délivré par un mécanisme extérieur à Ezproxy, qui peut être du code ASP. On compare le script fourni par ezproxy au script utilisé par Archimed, et là on s’aperçoit que ça n’a rien à voir, qu’Archimed a tout réécrit pour l’interfacer à sa solution, et que donc le mécanisme d’authentification est le même que celui utilisé pour s’authentifier sur le portail, et que c’est lui qui délivre le ticket. Vous pouvez toujours modifier votre paramétrage d’Ezproxy, de toutes façons l’authentification a lieu AVANT de parvenir à Ezproxy…Il va donc falloir zapper le mécanisme Archimed et revoir tout ça au calme. La suite au prochain épisode

Évidemment, arriver à cette conclusion m’a pris des semaines, à décrypter des scripts, à parcourir la documentation dans tous les sens, à frôler la crise de nerfs. Ce n’est pas de l’atermoiement, simplement une chronique de ce que peut être une partie de mes tâches, chronophage et stressante par manque d’information (et clairement par manque de pression sur un fournisseur que l’on qualifiera pudiquement d’indélicat).

Le bilan

D’abord le volume de question est assez faible. En moyenne, un à deux messages par jour avec tout de même un pic d’utilisation lors des formations à la méthodologie documentaire du début d’année universitaire. Un questionnaire étant à remplir à la suite de ces séances, de nombreux étudiants ont eu recours au chat pour qu’on les aide à remplir ce questionnaire, ce qui constitue une façon intéressante de créer du lien. Concernant la volumétrie, je ne suis pas surpris de la faible ampleur du service, je pense que ça correspond à usage normal. Après tout, vous n’avez pas un appel téléphonique toutes les 10 minutes d’un étudiant avec une question ou un problème à soumettre. Par contre je pense qu’on peut travailler pour mieux faire connaître le service,   notamment lors des séances de formation des usagers.

Deuxième constat : les questions portent le plus souvent sur la marche à suivre pour renouveler un prêt, et surtout sur la façon de s’identifier sur le portail. La aussi, rien d’étonnant : pouvoir renouveler un prêt est le service le plus utilisé, et l’authentification nécessite que les étudiants aient activé leur accès aux ressources numériques de l’université (conséquence : la plupart ne savent pas quels identifiants utiliser).  On peut donc considérer ce service comme un moyen de palier aux manques du portail et donc de pouvoir rectifier le tir. D’ailleurs, suite à la mise en ligne d’un petit tuto sur l’authentification, le nombre de message a chuté.

A partir de cette expérience, on va pouvoir maintenant passer à la vitesse supérieure, c’est à dire élargir l’amplitude horaire pour égaler l’amplitude horaire d’ouverture des bâtiments.

Projections : les moyens humains

Le service s’apparente beaucoup à de l’accueil téléphonique. Vous répondez au téléphone quand il sonne et toute affaire cessante. C’est la même chose pour le chat, vous laissez votre client de messagerie ouvert, et vous vous en occupez quand il y a un message. En gros, ça n’est pas accaparant, on peut bosser à côté. Par contre, le service me paraît incompatible avec une plage de service public. On peut donc envisager qu’une personne puisse prendre en charge un quinzaine d’heures par semaine sans trop de problème, et que donc on peut faire tourner le service avec 4 ou 5 personnes, tout dépendra de la complémentarité de leur emploi du temps.

Projections : les moyens logistiques

Gérer un planning avec des personnes éloignées de 80 kms comme chez nous nécessite une application d’agenda partagé. Je suppose que Google Agenda ferra parfaitement l’affaire

Il me paraît indispensable d’avoir un stock de phrases tout faites et déjà rédigées dans lesquelles on pourrait piocher. Ça permettrait d’être très réactif. Ça peut passer par la construction d’un wiki. A creuser

On a profité de la mise en place de notre nouveau portail pour mettre en place un service de chat . J’aborderai dans ce post les aspects techniques et les modalités de mise en place du service. Dans le prochain post, on verra quel bilan on peut dresser après deux mois et demi de service et quelles conséquences on peut en tirer au niveau organisationnel.

  • Les outils
    Nous avons testé deux outils de chat :

    • Meebome le widget proposé par Meebo, qu’on ne présente plus, et qui marche très bien. Point négatif : l’interface est anglais, ce qui a choqué pas mal de collègues – on a presque enterré le projet pour cette raison –  et par effet de domino a provoqué une réaction étrange : j’étais choqué qu’ils soient choqués, car cet aspect ne m’avait pas du tout frappé ! Autre point négatif, l’utilisateur est condamné à rester sur la même page pour suivre la conversation.
    • Plugoo : fonctionne aussi bien que Meebo. Point positif par rapport à Meebo : l’interface bénéficie d’une personnalisation accrue, notamment aux niveaux des libellés, ce qui résout le problème de la langue. Autre point positif : on peut détacher le widget dans un autre fenêtre, ce qui garantit le suivi de la discussion. Point négatif : une seule conversation à la fois (et on est considéré comme ‘busy’ pour les autres usagers).  Pour passer en mode multi-conversation (et encore, limité à 5 conversation à la fois), il faudra débourser un peu d’argent (5,99 € par mois pour la formule Basic, 8,99 € par mois pour la formule Pro)
    • reste à tester l’outil d’Archimed.
  • Côté bibliothécaire, l’installation des widgets est ultra-simple : on définit les paramètres du widget (taille, couleur, texte…) sur le site de meebo ou de Plugoo, qui nous fournit les quelques lignes de codes à insérer sur son site/blog. Pour recevoir les messages via Meebo, il faut se rendre sur le site Meebo. Pour Pluggo, les conversation se déroulent sur un client de messagerie instantanée à choisir parmi MSN Messenger, GoogleTalk, Yahoo! Messenger, AOL AIM, ICQ, Jabber…

    Côté client, rien à installer, pas d’inscription préalable, le widget est là, on discute point barre.

  • Les modalités
  • Le chat a été ouvert à « titre expérimental ». J’étais le seul à assurer les « permanences » d’une durée de 36 h par semaine. Il manque donc 23 h par semaine pour couvrir l’amplitude horaire correspondante aux heures d’ouverture.  Cette méthode de travail peut paraître bizarre. Je n’en disconviendrais pas. On dira pudiquement que le manque de fondement organisationnel a été déterminant pour le choix d’une approche pragmatique. Dans le même ordre d’idée, enfin si on peut dire, aucune politique n’a été définie. Donc dans l’absolu, on répond à toutes les questions qu’on voudra bien nous poser.

    Le widget a été placé sur la page d’accueil du portail ainsi que sur le bulcoblog.