Fwd: [sist] Geonetwork 4.4.5 - Authentification en Multi Instance - Kubernetes

[Mathias Rouan]

Bonjour,

Comme je sais qu'il y a des experts, je me permet de transférer sur cette liste une question GN un peu "touchy" de mon collègue Nicolas Coquillas de l'OSU-Réunion. Si vous avez des pistes n'hésitez pas à lui répondre.

Merci
Mathias

Mathias ROUAN

Ingénieur de Recherche CNRS
EMR 9001 SantEco - UMR 250 ENTROPIE
https://umr-entropie.ird.nc
Faculté des Sciences et Technologies
Université de la Réunion
15, avenue René Cassin - CS 92003
97744 Saint Denis Cédex 9
La Réunion, France

Bur : Bât. S4a N+1.09 (Nosy Tanikely)
mel : mathia...@cnrs.fr
web : https://letg.cnrs.fr/author/mathias-rouan/ 
(ancienne affectation, en cours de migration)

-------- Message transféré --------

Sujet :	[sist] Geonetwork 4.4.5 - Authentification en Multi Instance - Kubernetes
Date :	Mon, 28 Apr 2025 09:34:15 +0400
De :	Nicolas Coquillas (via sist Mailing List) <si...@services.cnrs.fr>
Répondre à :	Nicolas Coquillas <nicolas....@univ-reunion.fr>
Pour :	si...@services.cnrs.fr

Bonjour à tous,

J'ai déployé Geonetwork 4.4.5 avec ses petits copains Elasticsearch et Postgis dans un cluster Kubernetes.
Elasticsearch a deux instances, Postgis a deux instances.
Geonetwork avec une instance, je me connecte en admin, c'est parfait ça fonctionne.
Quand Geonetwork a deux instances, l'authentification fonctionne mal (souvent non, parfois oui).

C'est un problème de session sauvegardée côté serveur.
Sachant que les requêtes aboutissent à tantôt instance 1, tantôt instance 2 et qu'une seule des instances a reçu la requête 1(authentification), l'instance "l'autre" ne reconnaît pas l'utilisateur, l'utilisateur est déconnecté.

Pour régler ce souci, il faut mettre en place une troisième base de données, Redis, qui aura pour rôle de centraliser les sessions de Geonetwork.
Il faut donc dire à Geonetwork de ne plus sauvegarder les sessions en local mais les transmettre à Redis.

C'est ici que commence mon souci pour faire comprendre à Geonetwork que le "store" n'est plus "local" mais "Redis".(store=magasin de stockage)
Je suis passé par les variables d'environnement JAVA.
-Dredis.host=redis-service
-Dredis.port=6379
-Dredis.password=redispassword

Je suis passé par les variables d'environnement.
- name: SESSION_STORE_TYPE
  value: redis
- name: REDIS_HOST
  value: redis-service
- name: REDIS_PORT
  value: "6379"
- name: REDIS_PASSWORD
  value: redispassword
             
Je suis passé par le fichier "application.properties"

Rien n'y fait, Geonetwork continue de se servir du "store" local.
Chaque pod de Geonetwork voit très bien Redis qui répond dans ses logs toutes les tentatives manuelles avec "curl" mais aucune depuis Geonetwork.

Est-ce quelqu'un a déjà mis en place Geonetwork 4.4.5 sous K8S et/ou s'est confronté à ce problème?
Est-ce quelqu'un a déjà connecté Redis avec Geonetwork?

Merci.

----------------------------------------------------------------------

Nicolas COQUILLAS

Observatoire des Sciences de l'Univers de la Réunion

Université de La Réunion

(service informatique - gestion des données du projet BRIDGES)

https://www.osureunion.fr/

---------------------------------------------------------------------------

   "L'informatique, ça fait gagner beaucoup de temps...
   à condition d'en avoir beaucoup devant soi !"

--------------------------------------------------------------------------

Quelle que soit l'heure à laquelle vous parvient ce message, vous n'êtes pas tenu(e) d'y répondre en dehors de vos heures habituelles de travail.

[Jean Pommier]

Bonjour

Je ne crois pas Geonetwork 4 capable de fonctionner avec Redis.

Il y a qq chose qui n'est pas clair pour moi :

- Elasticsearch est fait pour fonctionner en HA, donc plusieurs instances en HA, pas de souci.

- La BD, déjà, c'est moins clair. Si c'est du HA, pareil. Si c'est deux bases différentes, je n'en vois pas l'intérêt / comment utiliser les deux

- Et si j'ai bien suivi, l'idée est surtout d'avoir 2 instances de GN. Je vois dans les compos docker des dernières versions de GN que c'est possible (https://github.com/geonetwork/docker-geonetwork/tree/main/4.4.6#clustering-experimental) mais je ne l'ai jamais testé. L'idée est dans ce cas de configurer des sticky sessions pour que, justement, un utilisateur connecté sur l'instance 1 ne bascule pas à un moment donné sur l'instance 2 (il reste "collé" à l'instance qui le connait)

J'espère que ça sera utile

Bonne soirée

Jean

Jean Pommier -- pi-Geosolutions

Ingénieur, consultant indépendant

Tél. : (+33) 6 09 23 21 36
E-mail : j...@pi-geosolutions.fr
Web : www.pi-geosolutions.fr
linkedin : jean-pommier

--
--
Vous avez reçu ce message, car vous êtes abonné au groupe
Groupe "georchestra" georc...@googlegroups.com
voir http://groups.google.fr/group/georchestra
 
Site web : http://www.georchestra.org

---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "georchestra".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse georchestra...@googlegroups.com.
Pour afficher cette discussion, accédez à https://groups.google.com/d/msgid/georchestra/fe1121cb-3f4c-41ea-94aa-d045e476947b%40univ-brest.fr.

[Nicolas Coquillas]

Bonjour Jean,

J'ai effectivement vu de la doc qui permettait à une IP client de rester "collé" à une instance, mais que ce soit un "user" peut être une petite avancée.
Je vais investiguer sur le lien transmis des compos docker (Experimental, les limitations sont de taille).

Il semble qu'il soit trop tôt pour clusteriser (2+ instances) GeoNetwork.

Merci Jean pour le retour,

merci Mathias pour le "forward".

[Landry Breuil]

On 29/04/2025 08:18, Nicolas Coquillas wrote:
> Bonjour Jean,
> J'ai effectivement vu de la doc qui permettait à une IP client de rester
> "collé" à une instance, mais que ce soit un "user" peut être une petite
> avancée.
> Je vais investiguer sur le lien transmis des compos docker
> (Experimental, les limitations sont de taille).
>
> Il semble qu'il soit trop tôt pour clusteriser (2+ instances) GeoNetwork.

je le fais depuis longtemps, mais au niveau du reverse-proxy (nginx pour
mon cas) avec ip_hash pour que ce soit sticky par ip, et un mapping pour
que les utilisateurs authentifiés (eg header sec-username non vide)
aillent sur le 'primaire'. pas 100% certain que ça vaille la complexité...

upstream geonetwork_backend {
ip_hash;
server localhost:8380;
server 10.0.7.8:8380;
}
upstream geonetwork_master_backend {
server 10.0.7.8:8380;
}

map $http_sec_username $geonetwork_backend {
default "geonetwork_backend";
~* "geonetwork_master_backend";
}

server {
listen 9380;
location / {
proxy_set_header Host $http_host;
proxy_pass http://$geonetwork_backend;
}
}
--
Landry Breuil