Serveur Z39.50 générique ?

Bonjour,
j'ai vu que dans les fichier de PMB il y a un dossier zserver qui permet de rendre sa base accessible avec le protocole Z39.50.
Il semblerait que ces fichiers soit propre à PMB.

Je me demandais si il existait un serveur Z39.50 "universel", qui soit compatible avec n'importe quel SIGB du moment qu'on lui donne les bons paramètres pour interroger la base de données.
J'ai fais des recherches sur le net sans trouver de réponse.
Cela existe-il ?

Merci de vos lumières.

Réponses

  • Le Z39.50 c'est une norme. N'importe quel SIGB, qui respecte la norme peut intégrer un module pour aller chercher des notices en respectant les normes. Ainsi, on peut ajouter des serveurs à PMB, en leur donnant les bons paramètres.
    Le dossier zserver, que j'aimerais réussir à faire fonctionner un jour doit servir à pouvoir gérer son propre serveur Z39.50, et donc pour que d'autres puissent venir chercher des notices.
    Si quelqu'un a déjà réussi à le faire fonctionner, ça m'intéresse !

  • Ok, merci. Donc, la norme Z39.50 est implémenté par les SIGB pour communiquer, en mode client et/ou en mode serveur.
    Donc, si ce sont les SIGB qui l'implémente, je suppose qu'il n'existe pas de "serveur Z39 générique" qu'on peut rajouter à un SIGB. Ai-je bon ?

    Je suis très intéressé aussi pour avoir mon propre serveur Z39.50.
    Je me lance la dedans, et je te ferai signe si j'avance ;-)
  • octobre 2020 modifié
    Un question : j'ai déjà compilé YAZ pour rajouter la recherche Z39 à PMB (installer par PECL)
    Dois-je recompiler YAZ comme il le mentionne en début de doc ?

    Je ne voudrais pas tout casser ^^
  • octobre 2020 modifié
    J'ai donc installer le serveur Z39.
    Je précise que j'utilise Linux Debian 10 et PMB 7.3
    J'ai deux instance de PMB sur une seule machine : une instance avec PMB + serveur Z3950, une seconde instance de PMB client Z3950. Chaque instance à son propre nom de domaine.

    J'ai bien une connexion entre ma machine cliente et mon serveur. Mais, il le client me répond "not found".

    Sur le serveur, j'ai ces messages :

    19:02:48-13/10 yaz-ztest(5) [request] POST /pmb_lourdes HTTP/1.1
    19:02:48-13/10 yaz-ztest(5) [request] SRWSearch pmb_lourdes ERROR info:http/404 - 1+0 pqf: @attr 1=4 @attr 4=1 "vignemale"
    19:02:48-13/10 yaz-ztest(5) [session] Connection closed by client
    19:02:48-13/10 yaz-ztest(5) [session] Connection closed - end of session

    Donc, il y a bien une connexion, mais il ne trouve pas un truc (404), mais quoi ? C'est ésotérique comme message ^^
    J'ai essayé différentes configuration, mais j'ai toujours les même messages.
    Si je mets localhost partout en partant du principe que tout est sur le même serveur physique, le client Z39 ne trouve pas le serveur.

    Echec lors de la recherche : Connect failed, localhost:210/pmb_lourdes

    SI j'utilise le nom de domaine du serveur il le trouve, mais affiche  :

    Echec lors de la recherche : Not Found,

    Ce qui me surprend, c'est qu'il y a très peu de fichier de config et de paramètre, je ne vois où j'aurai fait une connerie...

    J'ai bien copier le fichier export_z3950.php dans /pmb_lourdes/admin/convert/
    D'ailleurs, il y a un second fichier intitulé export_z3950_new.php
    Faudrait peut être utiliser ce fichier ? (j'ai essayé mais en le renommant export_z3950.php mais sans succès)

    De ton côté, t'en es où ? Même message d'erreur ?










  • Je n'ai jamais été aussi loin : je suis sur un serveur mutualisé, je n'ai donc pas autant de droit, ou d'accès que ce qui est demandé dans la doc. Ou en tout cas je crois. Et je touche là au limite de mes compétences, je ne comprend pas trop ce que je fais quand je suis la doc.
    En tout cas, Yaz est déjà installé sur mon hébergement.
    Il est possible que cette doc ne soit pas à jour d'ailleurs
  • Merci des infos.
    En tout cas, il y a une nouvelle version de export_z3950_new.php dans PMB7 et ce n'est pas mentionné dans la doc. Donc celle-ci à au moins une version de retard ...
  • permet de mieux comprendre un bout du message d'erreur, mais ne fait pas avancé le bouzin ....

  • octobre 2020 modifié
    J'avance un peu dans mes tests.
    J'ai tout sur le même VPS (Virtual Private Server) chez OVH. J'ai 2 clients PMB et d'autres trucs, tout marche avec des noms et sous-noms de domaine différents.

    Du coup, j'ai essayé avec localhost partout. Le 404 à disparu, mais c'est la base déclarée dans le fichier zserver.ini qu'il ne trouve pas. Pourtant, j'ai bien vérifié le nom.

    Donc, voici mon fichier zserver.ini qui est dans mon home :

    #Fichier de configuration pour le serveur z3950

    #Parametres pour la passerelle http PMB
    webpmb_host=localhost
    webpmb_port=80
    webpmb_script=/pmb_lourdes/admin/convert/export_z3950.php

    #Parametres du serveur Z3950
    z3950_database=pmb_lourdes

    Mon paramétrage dans mon client :

    Nom  Lourdes
    Utilisation  CATALOG
    Base  pmb_lourdes
    URL    localhost
    Numéro de port  210
    Format  UNIMARC

    (j'ai essayé avec un nom de base sans _ avec le même résultat)
    Puis ma commande pour lancer le serveur Z3950 :

    /usr/local/bin$ sudo ./yaz-ztest -c ~/zserver.ini tcp:localhost:210
    20:14:58-15/10 [server] Adding dynamic listener on tcp:localhost:210 id=0 PID=11990

    Et quand je lance une recherche depuis mon client, j'ai cette erreur sur le client :

    Echec lors de la recherche : Database unavailable, pmb_lourdes

    et sur le serveur :

    20:16:07-15/10 yaz-ztest(1) [session] Session - OK 1 tcp:::1 PID=12007
    20:16:07-15/10 yaz-ztest(1) [request] Auth none
    20:16:07-15/10 yaz-ztest(1) [request] Init OK - ID:81 Name:PHP/ZOOM-C/YAZ Version:5.30.3 2af59bc45cf4508d5c84f350ee99804c4354b3b3
    20:16:07-15/10 yaz-ztest(1) [request] Search pmb_lourdes ERROR 109 1 1+0 RPN @attrset Bib-1 @attr 4=1 @attr 1=4 vignemale

    Si je regarde dans les log Apache2, je n'ai que 2 fichiers qui sont alimentés :

    Mon client, access.daguerreo.log avec des entrées qui ressemble à ça :

    176.141.234.9 - - [15/Oct/2020:20:16:08 +0000] "GET /javascript/notification.js HTTP/1.1" 404 497 "http://daguerreo.mideel.fr/catalog/z3950/z_progression_cache.php?last_query_id=176&selection_bib=where bib_id in (22)%20&clause=22&crit1=isbn&val1=&bool1=ET&crit2=titre&val2=vignemale&limite_notices=100" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0"

    Et acces.log avec ceci :

    ::1 - - [15/Oct/2020:20:16:13 +0000] "OPTIONS * HTTP/1.0" 200 126 "-" "Apache/2.4.38 (Debian) OpenSSL/1.1.1d (internal dummy connection)"

    Voilà voilà ...

    Ce qui m'aiderait, c'est de savoir si le serveur Zserver log quoi que ce soit en dehors des sorties consoles.
    Autre piste, la "base" qu'on déclare dans le fichier ini, est-ce une base générée à la volé ? Ou est-ce un fichier qui s'alimente et qu'on peut "consulter" ?
    Un problème de droit d'écriture pour la base peut être ?

    Note : résultat identique avec le export_z3950_new.php

    Merci de votre aide.
  • Quelques news : pas de succès, mais des erreurs en moins.
    En faisant un lien symbolique entre le dossier où est l'executable de yaz-ztest et le dossier javascript de pmb :

    ln -s /var/www/pmb_lourdes/javascript/ /usr/local/bin/javascript/

    je ne rencontre plus d'erreur 404 dans les logs du client ... Mais j'ai toujours l'erreur "Echec lors de la recherche : Database unavailable, pmb_lourdes" dans PMB.

    Snif :'-( ...


  • Je progresse !!!! Mon client arrive à communiqué avec le server !

    Extrait de la doc YAZ : "Les bases de données suivantes sont honorées par yaz-ztest : Default, slow et db.* (toutes les bases de données avec le préfixe "db"). Toute autre base de données rendra yaz-ztest retour diagnostic 109 : "Database unavailable"."

    Donc, j'ai modifié le fichie de conf de zserver en :

    #Parametres du serveur Z3950
    z3950_database=db.lourdes

    Mais ... Bah oui, sinon ça ne serait pas drôle ... Mais, soit il ne me renvoie aucun résultat avec une recherche sur le titre, soit un nombre farfelue de résultat sur l'ISBN

    TERMINE : le serveur a retourné 100 notices sur 9782700300581 trouvées.

    Les notices retournées sont vides ...

  • \o/ Je te regarde de loin, mais avec attention hein

    A tout hasard estc e que c'est pas lors de ta recherche que tu as rentré l'ISBN dans le champ de recherche avec titre dans le menu déroulant ? Ca m'arrive des fois et c'est le genre de chose que j'observe quand que je ne fais pas attention.
    Je comprend que tu as changé le nom de ta base aussi ? c'est ça ?
  • En fait, faute de ressources et d'aides en français, j'ai fini par me plonger dans la documentation de la bibliothèque YAZ qui est utilisé pour implémenter le protocole Z39. C'est en principe à destination des programmeur, mais bon ... fallait bien essayer. Vu que les commandes par yaz-* je me suis dit que je finirai pas trouver.
    Sur la doc (en anglais : https://software.indexdata.com/yaz/doc/yaz-ztest.html), j'ai trouvé quelques infos utile.

    yaz-ztest n'est qu'un serveur de test et n'utilise pas de base de données. Il te renvoie des résultats issus de son jeu de test.
    C'est pour ça qu'il me mettait que ma base de données n'était pas disponible. Donc, j'en ai changé pour adopté un formé qu'il accepte : toutes les bdd qui commence par db.*

    Ensuite, je me suis passé de PMB comme client et j'ai utilisé la commande client direct : yaz-client
    J'ai pu constaté que j'arrive à me connecté à mon serveur, faire une requête et avoir une réponse.
    Idem depuis le client PMB.

    Mais, il ignore ma base de données passé en paramètre et configurée dans zserver.ini

    Donc, deux possibilités :
    • soit yaz-ztest ne peut être utilisé qu'à des fins de test et je perds mon temps car c'est une autre commande qui est utilisé pour avoir un VRAI serveur Z39.
    •  soit l'équipe PMB a détourné l'usage de yaz-ztest pour qu'il prenne en compte une BDD et ce n'est qu'une question de paramètres ...

      Éventuellement, la seconde possibilité était vraie par le passé, puis l'évolution de yaz-ztest a bloqué cette possibilité.
    Pour l'ISBN, la doc dit que si tu fait une recherche avec des nombreux (donc un ISBN par exemple), il prendra ce nombre et le placera à la place du nombre de résultat global.
    C'est un comportement normal de yaz-ztest... Vive la doc officielle ! ^^

    En tout cas, j'aimerai bien une petite aide de l'équipe de PMB ... Car je commence à penser que peut être leur serveur Z39 n'est pas encore fonctionnel (car ils ont d'autres priorité de développement, ce qui peut parfaitement ce comprendre) ou qu'il ne l'est plus.
    Si c'est le cas, je perds mon temps.
  • J'ai repris depuis le début. J'ai fais une erreur bête, lors de la compilation, j'avais copier le fichier ztest.c de PMB dans le répertoire yaz et nom yaz/ztest/
    Je n'avais donc pas écrasé le fichier ztest.c d'origine par la version modifié de PMB.
    (note : ça explique le comportement de yaz-ztest d'hier, n'étant pas la version modifié par PMB, il ignorait ma BDD)

    Une fois corrigé, j'ai eu des erreurs de compilation avec la version 5 de YAZ, puis la 3, puis la 2.1. J'ai fini par réussir la compilation avec la version 2.0.9 ... qui date de 2003 ... en même temps, la doc de PMB date de 2004 ... ça reste logique.

    Donc, compilation et installation OK.

    Je peux lancer mon serveur depuis mon home (~) :

    $ sudo /usr/local/bin/yaz-ztest -c ./zserver.ini tcp:localhost:210
    11:23:31-20/11: [log] Adding dynamic Z3950 listener on tcp:localhost:210
    11:23:31-20/11: [log] Starting server /usr/local/bin/yaz-ztest pid=7822
    11:23:31-20/11: [log] Entering event loop.

    Mais quand un client s'y connecte (qu'il soit en ligne de commande avec la commande yaz-client de la V2 que je viens de compiler ou le client de l'interface de gestion de PMB avec la V5) j'ai la même erreur:

    11:24:49-20/11: /usr/local/bin/yaz-ztest(7850) [log] Starting session 1 from tcp:localhost
    11:24:49-20/11: /usr/local/bin/yaz-ztest(7850) [log] Got initRequest
    11:24:49-20/11: /usr/local/bin/yaz-ztest(7850) [log] Id:        81
    11:24:49-20/11: /usr/local/bin/yaz-ztest(7850) [log] Name:      YAZ
    11:24:49-20/11: /usr/local/bin/yaz-ztest(7850) [log] Version:   2.0.9
    11:24:49-20/11: /usr/local/bin/yaz-ztest(7850) [log] param webpmb_host localhost
    11:24:49-20/11: /usr/local/bin/yaz-ztest(7850) [log] param webpmb_port 80
    11:24:49-20/11: /usr/local/bin/yaz-ztest(7850) [log] param webpmb_script /var/www/pmb_lourdes/admin/convert/export_z3950.php
    11:24:49-20/11: /usr/local/bin/yaz-ztest(7850) [log] param z3950_database lourdes
    11:24:49-20/11: /usr/local/bin/yaz-ztest(7850) [log] Can't handle configuration file
    11:24:49-20/11: /usr/local/bin/yaz-ztest(7850) [log] Negotiated to v3: srch prst del extendedServices namedresults scan sort
    11:24:49-20/11: /usr/local/bin/yaz-ztest(7850) [log] Connection rejected by backend.
    11:24:49-20/11: /usr/local/bin/yaz-ztest(7850) [log] [2] Temporary system error
    11:24:49-20/11: /usr/local/bin/yaz-ztest(7850) [log] Final timeout - closing connection.

    Je comprends qu'il but sur le fichier de paramètre ...

    Pour le paramètre webpmb j'ai essayé
    /var/www/pmb_lourdes/admin/convert/export_z3950.php
    et
    /pmb_lourdes/admin/convert/export_z3950.php
    mais ça ne change rien. Idem avec export_z3950_new.php

    Je n'ai pas l'impression que ce soit un problème de version.
    Mon fichier de config correspond à la doc :

    #Fichier de configuration pour le serveur z3950
    #Parametres pour la passerelle http PMB
    webpmb_host=localhost
    webpmb_port=80
    webpmb_script=/pmb_lourdes/admin/convert/export_z3950.php
    #Parametres du serveur Z3950
    z3950_database=lourdes

    Je sens que je ne suis pas loin ... mais ça ne fonctionne pas .... :'-(

  • Pour infos, voici le retour client en console :

    $ sudo /usr/local/bin/yaz-client  tcp:localhost:210/lourdes
    Connecting...OK.
    Sent initrequest.
    Connection rejected by v3 target.
    ID     : 81
    Name   : GFS/YAZ
    Version: 1.13/2.0.9
    Init response contains 1 otherInfo unit:
      1: otherInfo unit contains 1 diagnostic:
        1: code=2 (Temporary system error),
        addinfo=''
    Options: search present delSet scan sort extendedServices namedResultSets
    Elapsed: 0.003658
    Z>

  • Je continuerai sur ce nouveau sujet.
Connectez-vous ou Inscrivez-vous pour répondre.