retour d'expérience migration geonetwork 3.8.2 -> 4.0.6
41 views
Skip to first unread message
Landry Breuil
Aug 5, 2022, 8:17:12 AM8/5/22
to georche...@googlegroups.com
Hello,
attention long mail.. en cours de migration 20.0.x vers 22.0.x, instance
de dev avec ~1.5k users/1k orgs, ~600MD, rien de spécial à part qu'on
utilise la géopublication de shp zippés de geonetwork vers geoserver (et
on doit être parmi les rares).
Petit retour d'expérience sur les différentes embûches lors de l'upgrade
majeure GN4, et comment je les ai contourné (si qqn veut compléter les
notes de migration avec mes notes, il est le bienvenu!!):
- question infrastructure, faut commencer par installer elasticsearch,
et passer a java11, rajouter les bonnes classes/attributes dans le LDAP
- tout ça est déjà couvert par les notes de migration.
- j'ai commencé par chercher a faire passer les migrations automatiques
de base de données, lancées automatiquement par geonetwork au démarrage.
Attention, les migrations se font avant que log4j.xml soit lu, donc les
logs d'upgrades sont par défaut dans le rept des logs de tomcat
(logs/geonetwork.log) a moins que vous ayez mis -Dlog_dir dans l'env
java qui pointera vers un autre rept, eg -Dlog_dir=/tmp ->
/tmp/logs/geonetwork.log. Pareil si vous voulez ajouter du debug, faut
modifier WEB-INF/classes/log4j.xml.
- en préliminaire, ne pas oublier de supprimer wro4j-cache.* dans le
datadir GN, même plusieurs fois si on change des bouts de javascript.
- il y'a des migrations SQL, et des bouts de migration en java:
plusieurs erreurs, donc certaines listées sur
https://github.com/georchestra/geonetwork/issues/205 (je vous fait une
synthèse):
- une erreur sur le champ 'editable' de la table settings, sensé être
ajouté par hibernate mais en fait non ? Je ne sais pas si il serait
ajouté en faisait l'étape intermédiaire via GN 3.10, mais pour moi le
champ n'était pas la.
------
SQL migration
file:/data/tomcat/geonetwork/webapps/geocat/WEB-INF/classes/setup/sql/migrate/v3110
prefix:migrate- ...
Errors occurs during SQL migration file: ERROR: column "editable" of
relation "settings" does not exist
------
et ca fait foirer/annule les maj suivantes.
cf https://github.com/geonetwork/core-geonetwork/issues/6054, pour ma
part j'ai fait:
------
ALTER TABLE Settings ADD COLUMN editable VARCHAR(1) DEFAULT 'y';
------
- une erreur lors du lancement de v3110:UpdateMetadataStatus qui ajoute
des champs uuid et title a la table metadatastatus et les remplit,
quelques enregistrements sont mis a jour mais après qquns ça plante avec:
------
Errors occurs during Java migration file:
org.hibernate.TransientPropertyValueException: object references an
unsaved transient instance - save the transient instance before
flushing : org.fao.geonet.domain.MetadataStatus.statusValue ->
org.fao.geonet.domain.StatusValue; nested exception is
java.lang.IllegalStateException
------
pour ça j'ai manuellement updaté le champ uuid avec
------
update metadatastatus as ms set uuid=m.uuid from metadata m where
m.id=ms.metadataid;
------
- erreur suivante sur le job v400:UpdateAllSequenceValueToMax - enfin il
n'explose pas, mais il tourne "sans fin". Petit peu de contexte, dans
GN3 il y'avait une seule séquence SQL pour toutes les tables
(hibernate_sequence) utilisée pour les clefs d'une trentaine de tables,
dans GN4 on passe a une trentaine de séquences, et le job est sensé les
mettre a jour pour utiliser la valeur maximale de l'id pour chacune des
tables correspondantes, mais c'est fait en java et peu efficace (plutôt
qu'en SQL mais on ne sait pas à l'avance le "dialecte SQL" utilisé par
la bdd en dessous) donc ça tourne des heures dans le vide si on a une
séquence hibernate "un peu utilisée" (ce qui était le cas en GN3 quand
toutes les requêtes étaient logguées en base pour les statistiques de
recherche... ma séquence hibernate est a 185369021).
Par chance, y'a la version SQL sur github:
https://github.com/geonetwork/core-geonetwork/pull/5003#issuecomment-690188130
- donc je vous conseille de désactiver/supprimer
java:v400.UpdateAllSequenceValueToMax dans
webapps/geonetwork/WEB-INF/config-db/database_migration.xml si vous ne
voulez pas attendre des heures, et lancer le SQL qui se fait instantanément.
a ce stade la, GN4 démarre, mais dans les logs j'ai des insultes a
propos de cryptage de mdp (qui sont vides en bdd):
------
Exception executing gui service :
org.jasypt.exceptions.EncryptionOperationNotPossibleException
------
la je n'ai pas cherché a comprendre, je n'ai pas prévu de mettre de mdp
en base donc j'ai fait le cochon pour les 3 settings concernés:
------
update settings set encrypted='n' where encrypted='y';
------
blague suivante, je peux aller voir la homepage de GN4, mais pas aller
sur la console d'admin GN4, je suis redirigé vers la recherche.. pierre
mauduit avait trouvé un workaround, cf
https://github.com/georchestra/georchestra/issues/3545 et
https://github.com/georchestra/georchestra/tree/master/migrations/22.0#authtype,
donc:
------
update users set authtype=NULL where authtype='LDAP';
------
A ce stade, j'accède a l'interface d'admin de GN4. Reste a lancer
l'indexation dans elasticsearch, qui explose un peu en vol avec des
insultes du genre
------
type=mapper_parsing_exception, reason=object mapping for [contact] tried
to parse field [null] as object, but found a concrete value]]
------
pour corriger celle la, j'ai fait qqch que j'aurais du faire dès le
début - supprimer tous les schémas dans le datadir, et copier ceux
fournis avec la webapp:
------
sudo rm -Rf /path/to/datadir/config/schema_plugins/*
sudo -u tomcat cp -r
/path/to/tomcat/geonetwork/webapps/geocat/WEB-INF/data/config/schema_plugins/*
/path/to/datadir/config/schema_plugins/
------
+ restart. Dans l'interface d'admin je peux lancer l'indexation, et je
retrouve bien toutes mes ~600MD.
A ce stade, j'avais quasi tout, sauf les 'facettes' de recherche sur la
homepage et la page des résultats de recherche - pour une raison
inconnue, elles étaient vides dans la "configuration de l'interface
utilisateur" (cf
https://geonetwork-opensource.org/manuals/4.0.x/en/administrator-guide/configuring-the-catalog/user-interface-configuration.html)
et en plus j'avais des vieux réglages de tris a fournir/purger...
bref je conseille d'écraser l'entrée dans la table settings_ui (ou de
merger ses propres changements) avec celle fournie dans la webapp cf
https://github.com/georchestra/geonetwork/blob/georchestra-gn4-4.0.6/web/src/main/webapp/WEB-INF/classes/setup/sql/data/data-db-default.sql#L744
- c'est du json, donc on peut utiliser les fonctions de psql pour
accéder a des sous-ensembles des settings, et ça inclut d'ailleurs le
lien GN4->mapstore décrit sur
https://github.com/georchestra/georchestra/tree/master/migrations/22.0#link-to-external-viewer
------
[localhost:5432] geonetwork@georchestra=> select configuration::json->
'mods'->'map'->'externalViewer'->'urlTemplate' from settings_ui;
"mapstore/#?actions=[{\"type\":\"CATALOG:ADD_LAYERS_FROM_CATALOGS\",\"layers\":[${service.name}],\"sources\":[${service.url}]}]"
------
bref ne pas hésiter a revoir/mettre a jour ces settings si on a des
comportements chelou.
Autre problème rencontré, et spécifique a georchestra - un composant a
été codé pour GN4 pour faire la synchro des users/orgs depuis le ldap,
par défaut il va interroger une API interne de la console toutes les
10s, si on a un peu d'utilisateurs ça va rapidement saturer l'annuaire
LDAP et la console avec des requêtes, et les requêtes ont un timeout par
défaut a 6s, ce qui est largement insuffisant. Pour ma part j'ai changé
le timeout pour 60s (cf
https://github.com/georchestra/georchestra/pull/3780) et je ne lance la
sync qu'une fois par heure.
Bref, avec toutes ces horreurs (j'y ai passé 3/4j facile), sur mon
instance georchestra de dev en 22.0 j'ai un GN4 fonctionnel avec l'index
dans ES. Et au passage fait qqs tickets/PR dans GN et geor... et
beaucoup ralé intérieurement et sur IRC, comme a chaque maj GN :)
Si après avoir lu tout ça jusqu'au bout vous comptez encore mettre à
jour l'instance de votre structure, je vous souhaite bon courage,
persévérez, et si jamais vous bloquez allez demander de l'aide sur IRC :)
Au passage si ça peut en faire utiliser la fonctionnalité de
geopublication, j'ai implémenté la géopublication de geopackage de GN
vers GS en addition du shape zippé, cf
https://github.com/georchestra/geonetwork/pull/212.
--
Landry Breuil
Responsable Informatique
04 44 05 12 42
----------------------------------------------------------------------------
Centre Régional Auvergne-Rhône-Alpes de l'Information Géographique
Hôtel de région
59 Boulevard Léon Jouhaux - CS 90706
63050 Clermont-Ferrand Cedex 2
https://www.craig.fr <https://www.craig.fr> - @GipCraig
----------------------------------------------------------------------------
> Support utilisateurs (tous les jours ouvrés de 8H30 à 12H30) : 09 72
62 25 31
attention long mail.. en cours de migration 20.0.x vers 22.0.x, instance
de dev avec ~1.5k users/1k orgs, ~600MD, rien de spécial à part qu'on
utilise la géopublication de shp zippés de geonetwork vers geoserver (et
on doit être parmi les rares).
Petit retour d'expérience sur les différentes embûches lors de l'upgrade
majeure GN4, et comment je les ai contourné (si qqn veut compléter les
notes de migration avec mes notes, il est le bienvenu!!):
- question infrastructure, faut commencer par installer elasticsearch,
et passer a java11, rajouter les bonnes classes/attributes dans le LDAP
- tout ça est déjà couvert par les notes de migration.
- j'ai commencé par chercher a faire passer les migrations automatiques
de base de données, lancées automatiquement par geonetwork au démarrage.
Attention, les migrations se font avant que log4j.xml soit lu, donc les
logs d'upgrades sont par défaut dans le rept des logs de tomcat
(logs/geonetwork.log) a moins que vous ayez mis -Dlog_dir dans l'env
java qui pointera vers un autre rept, eg -Dlog_dir=/tmp ->
/tmp/logs/geonetwork.log. Pareil si vous voulez ajouter du debug, faut
modifier WEB-INF/classes/log4j.xml.
- en préliminaire, ne pas oublier de supprimer wro4j-cache.* dans le
datadir GN, même plusieurs fois si on change des bouts de javascript.
- il y'a des migrations SQL, et des bouts de migration en java:
plusieurs erreurs, donc certaines listées sur
https://github.com/georchestra/geonetwork/issues/205 (je vous fait une
synthèse):
- une erreur sur le champ 'editable' de la table settings, sensé être
ajouté par hibernate mais en fait non ? Je ne sais pas si il serait
ajouté en faisait l'étape intermédiaire via GN 3.10, mais pour moi le
champ n'était pas la.
------
SQL migration
file:/data/tomcat/geonetwork/webapps/geocat/WEB-INF/classes/setup/sql/migrate/v3110
prefix:migrate- ...
Errors occurs during SQL migration file: ERROR: column "editable" of
relation "settings" does not exist
------
et ca fait foirer/annule les maj suivantes.
cf https://github.com/geonetwork/core-geonetwork/issues/6054, pour ma
part j'ai fait:
------
ALTER TABLE Settings ADD COLUMN editable VARCHAR(1) DEFAULT 'y';
------
- une erreur lors du lancement de v3110:UpdateMetadataStatus qui ajoute
des champs uuid et title a la table metadatastatus et les remplit,
quelques enregistrements sont mis a jour mais après qquns ça plante avec:
------
Errors occurs during Java migration file:
org.hibernate.TransientPropertyValueException: object references an
unsaved transient instance - save the transient instance before
flushing : org.fao.geonet.domain.MetadataStatus.statusValue ->
org.fao.geonet.domain.StatusValue; nested exception is
java.lang.IllegalStateException
------
pour ça j'ai manuellement updaté le champ uuid avec
------
update metadatastatus as ms set uuid=m.uuid from metadata m where
m.id=ms.metadataid;
------
- erreur suivante sur le job v400:UpdateAllSequenceValueToMax - enfin il
n'explose pas, mais il tourne "sans fin". Petit peu de contexte, dans
GN3 il y'avait une seule séquence SQL pour toutes les tables
(hibernate_sequence) utilisée pour les clefs d'une trentaine de tables,
dans GN4 on passe a une trentaine de séquences, et le job est sensé les
mettre a jour pour utiliser la valeur maximale de l'id pour chacune des
tables correspondantes, mais c'est fait en java et peu efficace (plutôt
qu'en SQL mais on ne sait pas à l'avance le "dialecte SQL" utilisé par
la bdd en dessous) donc ça tourne des heures dans le vide si on a une
séquence hibernate "un peu utilisée" (ce qui était le cas en GN3 quand
toutes les requêtes étaient logguées en base pour les statistiques de
recherche... ma séquence hibernate est a 185369021).
Par chance, y'a la version SQL sur github:
https://github.com/geonetwork/core-geonetwork/pull/5003#issuecomment-690188130
- donc je vous conseille de désactiver/supprimer
java:v400.UpdateAllSequenceValueToMax dans
webapps/geonetwork/WEB-INF/config-db/database_migration.xml si vous ne
voulez pas attendre des heures, et lancer le SQL qui se fait instantanément.
a ce stade la, GN4 démarre, mais dans les logs j'ai des insultes a
propos de cryptage de mdp (qui sont vides en bdd):
------
Exception executing gui service :
org.jasypt.exceptions.EncryptionOperationNotPossibleException
------
la je n'ai pas cherché a comprendre, je n'ai pas prévu de mettre de mdp
en base donc j'ai fait le cochon pour les 3 settings concernés:
------
update settings set encrypted='n' where encrypted='y';
------
blague suivante, je peux aller voir la homepage de GN4, mais pas aller
sur la console d'admin GN4, je suis redirigé vers la recherche.. pierre
mauduit avait trouvé un workaround, cf
https://github.com/georchestra/georchestra/issues/3545 et
https://github.com/georchestra/georchestra/tree/master/migrations/22.0#authtype,
donc:
------
update users set authtype=NULL where authtype='LDAP';
------
A ce stade, j'accède a l'interface d'admin de GN4. Reste a lancer
l'indexation dans elasticsearch, qui explose un peu en vol avec des
insultes du genre
------
type=mapper_parsing_exception, reason=object mapping for [contact] tried
to parse field [null] as object, but found a concrete value]]
------
pour corriger celle la, j'ai fait qqch que j'aurais du faire dès le
début - supprimer tous les schémas dans le datadir, et copier ceux
fournis avec la webapp:
------
sudo rm -Rf /path/to/datadir/config/schema_plugins/*
sudo -u tomcat cp -r
/path/to/tomcat/geonetwork/webapps/geocat/WEB-INF/data/config/schema_plugins/*
/path/to/datadir/config/schema_plugins/
------
+ restart. Dans l'interface d'admin je peux lancer l'indexation, et je
retrouve bien toutes mes ~600MD.
A ce stade, j'avais quasi tout, sauf les 'facettes' de recherche sur la
homepage et la page des résultats de recherche - pour une raison
inconnue, elles étaient vides dans la "configuration de l'interface
utilisateur" (cf
https://geonetwork-opensource.org/manuals/4.0.x/en/administrator-guide/configuring-the-catalog/user-interface-configuration.html)
et en plus j'avais des vieux réglages de tris a fournir/purger...
bref je conseille d'écraser l'entrée dans la table settings_ui (ou de
merger ses propres changements) avec celle fournie dans la webapp cf
https://github.com/georchestra/geonetwork/blob/georchestra-gn4-4.0.6/web/src/main/webapp/WEB-INF/classes/setup/sql/data/data-db-default.sql#L744
- c'est du json, donc on peut utiliser les fonctions de psql pour
accéder a des sous-ensembles des settings, et ça inclut d'ailleurs le
lien GN4->mapstore décrit sur
https://github.com/georchestra/georchestra/tree/master/migrations/22.0#link-to-external-viewer
------
[localhost:5432] geonetwork@georchestra=> select configuration::json->
'mods'->'map'->'externalViewer'->'urlTemplate' from settings_ui;
"mapstore/#?actions=[{\"type\":\"CATALOG:ADD_LAYERS_FROM_CATALOGS\",\"layers\":[${service.name}],\"sources\":[${service.url}]}]"
------
bref ne pas hésiter a revoir/mettre a jour ces settings si on a des
comportements chelou.
Autre problème rencontré, et spécifique a georchestra - un composant a
été codé pour GN4 pour faire la synchro des users/orgs depuis le ldap,
par défaut il va interroger une API interne de la console toutes les
10s, si on a un peu d'utilisateurs ça va rapidement saturer l'annuaire
LDAP et la console avec des requêtes, et les requêtes ont un timeout par
défaut a 6s, ce qui est largement insuffisant. Pour ma part j'ai changé
le timeout pour 60s (cf
https://github.com/georchestra/georchestra/pull/3780) et je ne lance la
sync qu'une fois par heure.
Bref, avec toutes ces horreurs (j'y ai passé 3/4j facile), sur mon
instance georchestra de dev en 22.0 j'ai un GN4 fonctionnel avec l'index
dans ES. Et au passage fait qqs tickets/PR dans GN et geor... et
beaucoup ralé intérieurement et sur IRC, comme a chaque maj GN :)
Si après avoir lu tout ça jusqu'au bout vous comptez encore mettre à
jour l'instance de votre structure, je vous souhaite bon courage,
persévérez, et si jamais vous bloquez allez demander de l'aide sur IRC :)
Au passage si ça peut en faire utiliser la fonctionnalité de
geopublication, j'ai implémenté la géopublication de geopackage de GN
vers GS en addition du shape zippé, cf
https://github.com/georchestra/geonetwork/pull/212.
--
Landry Breuil
Responsable Informatique
04 44 05 12 42
----------------------------------------------------------------------------
Centre Régional Auvergne-Rhône-Alpes de l'Information Géographique
Hôtel de région
59 Boulevard Léon Jouhaux - CS 90706
63050 Clermont-Ferrand Cedex 2
https://www.craig.fr <https://www.craig.fr> - @GipCraig
----------------------------------------------------------------------------
> Support utilisateurs (tous les jours ouvrés de 8H30 à 12H30) : 09 72
62 25 31
Reply all
Reply to author
Forward
0 new messages