-- Leo's gemini proxy
-- Connecting to gemini.ctrl-c.club:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
| | |
/ \ | |
|--o|===|-|
|---| |g|
/ \ |e|
| | |m|
| |=|i|
| | |n|
|_______| |i|
|@| |@| | |
___________|_|_
Après avoir découvert Gemini, j'ai installé assez rapidement une capsule - après tout, j'utilise Markdown depuis des années, donc c'était assez simple.
J'avais du contenu de mon site internet, donc là encore, pas de réel défi.
Créer mon propre CGI était un peu plus amusant.
Tout d'abord, les CGI gemini ne sont pas bien documentés.
J'ai lu toutes les spécifications que j'ai pu trouver, mais en vain.
J'ai regardé le code source de différentes pages, mais là encore, pas d'éblouissement.
J'ai installé un serveur (https://github.com/a-h/gemini/releases) sur un raspberry3 sur mon réseau local pour pouvoir bidouiller, mais en vain.
Puis j'ai découvert une page :
et j'ai contacté l'auteur (Karl) pour lui demander de l'aide.
Karl a été très gentil et serviable et a déclenché mon premier moment "a ha!".
J'ai réalisé (et lui aussi) que la raison pour laquelle ma configuration ne fonctionnait pas était probablement très simplement parce que mon serveur ne prenait pas en charge les CGI.
J'ai lu la documentation qu'il a écrite sur sa configuration (https://www.karl.berlin/gemini-blog.html) et j'ai décidé d'utiliser le même serveur : gmnisrv (https://git.sr.ht/~sircmpwn/gmnisrv/).
La compilation a été simple - juste besoin d'installer libssl-dev qui n'était pas sur le raspberry.
Mes recherches m'ont amené aussi sur une autre page, également très utile:
https://noulin.net/blog/gemini/2021/02/14/about-gemini-markup-and-gmnisrv.html
Pas trop compliqué en regardant la page de Karl et celle ci-dessus.
J'ai modifié le script de démarrage automatique du raspberry pour pointer dessus, et j'ai testé avec amfora: ok.
mon fichier de configuration:
# Space-separated list of hosts listen=0.0.0.0:1965 [::]:1965 [:tls] # Path to store certificates on disk store=/usr/local/gem/certs # Optional details for new certificates organization=gmnisrv user [localhost] root=/usr/local/gem/files [localhost:/cgi] root=/usr/local/gem/files cgi=on [raspi31] root=/usr/local/gem/files [raspi31:/cgi] root=/usr/local/gem/files cgi=on
C'est évidemment cette dernière partie avec le cgi qui est primordiale.
les scripts cgi se trouvent en fait obligatoirement dans /usr/local/gem/files/cgi.
Des différentes pages et documentation lues, (et entre autre le script python de Karl utilisé dans wikdict, dispo sur son git), je savais que le système disposait en fait de 4 variables, dont la plus utilisée était $QUERY_STRING.
ces 4 variables sont:
$QUERY_STRING
$PATH_INFO
$SERVER_NAME
$REMOTE_USER
# Page Test du script => cgi/test.sh Test here
if [ $QUERY_STRING"X" = "X" ] ; then echo "10 Enter something \r" else echo "20 text/gemini\r" echo " " echo "l'argument passé est $QUERY_STRING" echo "PATH_INFO = " $PATH_INFO echo "QUERY_STRING = " $QUERY_STRING echo "SERVER_NAME = " $SERVER_NAME echo "REMOTE_USER = " $REMOTE_USER echo " " echo " " echo " " echo " " echo "=> ../test.gmi Back" echo " " echo " " echo " " echo " " fi
et oui, il n'y a pas d'appel au shell bash sur la première ligne.
Quand je le mets, cela ne marche pas alors que l'interpréteur python était sur les pages de Karl.
Je ne comprends pas non plus :-)
Voilà la boîte de dialogue sous Lagrange et sous amfora:
et le résultat:
On constate que $QUERY_STRING contient bien ce qui a été entré dans la boîte de dialogue.
$SERVER_NAME contient également le nom du serveur.
Par contre les deux autres variables restent vides.
Soit j'ai mal compris, soit elles ne sont pas remplies par ce serveur-ci.
Ce n'est pas très grave, vu que tant qu'on a ce qu'on demandait, on peut écrire n'importe quel script.
(a suivre)
-- Response ended
-- Page fetched on Sun May 19 03:18:52 2024
