Procédure de mise à jour

Depuis GTF 2019 ou inférieur

Base de données

  1. Créer une nouvelle base pour GTF 2020 sur le même serveur que GTF 2019 (utiliser u_vitis comme propriétaire).

  2. Récupérer ensuite les informations de la base en version 2019 dans la future base de GTF 2020. Le plus simple est d'utiliser la commande pg_dump :

    pg_dump --username=postgres -W bdd_gtf_2019 > gtf_old.backup
    psql --username=postgres -W bdd_gtf_2020 < gtf_old.backup
    
  3. Connectez-vous ensuite sur la base de GTF 2020 et lancez le script SQL suivant :

    TRUNCATE s_gtf.job, s_gtf.message, s_gtf."order";
    

Note

Il faut modifier les alias Apache avant mise à jour.

Fichier de configuration

  1. Renommer le fichier de configuration l'application vm_app_gtf.conf en vm_app_gtf_old.conf. Si vous être sous Windows il faudra retoucher la ligne include vm_app_gtf.conf pour modifier le nom du fichier. Si votre GTF utilise un environnement, vous pouvez passer cette étape.

  2. Dans le fichier vm_app_gtf.conf, modifier l'alias /gtf en /gtf_old. Dans le fichier vm_vas.conf, remplacer /rest par /rest_old. Le fichier vm_php est à vérifier, mais normalement aucune modification n'est nécéssaire.

  3. Redémarrer le service Apache.

  4. Intégrer les modification au niveau de la configuration :

    • gtf/client/conf/properties.json :

      • modifier la clé service_alias en rest_old

      • modifier la clé environment en old

    • gtf/vas/rest/.htaccess : modifier la clé Rewritebase en rest_old

    • gtf/vas/rest/conf/properties.inc : modifier la clé services_alias en rest_old

    • gtf/vas/rest/conf/properties_server.inc : modifier la clé environment_alias en old

  5. Connecter vous à GTF en utilisant l'alias gtf_old, toute l'application doit fonctionner. Il est maintenant possible de lancer la mise à jour de GTF sur la nouvelle base avec VAI. Modifier le dependencies.json et lancer l'exécutable installé.

Avertissement

N'installez pas la version 2020 de GTF dans le même dossier que GTF 2019.

Récupération des informations u_vitis et u_scheduler

Il faut retoucher la configuration pour récupérer les mots de passe des utilisateurs u_vitis et u_scheduler.

Pour u_vitis, le mot de passe se trouve historiquement dans le fichier gtf/vas/rest/conf/properties_server.inc et il devra être placé dans gtf_2020/vas/src/Module/Vitis/conf/properties.json.

Pour u_scheduler, le mot de passe se trouve historiquement dans le fichier gtf/vas/rest/conf/gtf/properties_server.inc et il devra être placé dans gtf_2020/vas/src/Module/Gtf/conf/properties.json.

Récupération des projets de GTF 2019

  1. Dans le dossier gtf_2020/vas/var/ws_data du nouveau GTF, créer le dossier gtf (créer les parents s'ils n'existent pas).

  2. Copier le dossier de l'ancien GTF gtf/vas/ws_data/gtf/workspace dans le nouveau GTF gtf_2020/vas/var/workspaces.

  3. Copier le dossier Shared de l'ancien GTF gtf/vas/shared s'il existe vers le nouveau GTF gtf_2020/vas/var/shared.

  4. Activer la licence GTF.

  5. Récupérer le mot de passe de u_scheduler dans la configuration de l'application si ce n'est pas déjà fait.

  6. Aller dans le dossier gtf_2020/vas/engine/gtf et lancer la commande engine parseAllFmw --nt pour relancer le parseur sur tous les FMW.

  7. Mettre à jour chaque période via l'application pour mettre à jour le fichier jobs.json.

Avertissement

Remettre les droits sur les dossiers dans GTF 2020 si vous êtes sous Linux (même propriétaire, groupe et autorisations que dans l'ancienne version de GTF).

Pertes et modifications manuelles

Les versions 2020 ou plus sont des mises à jour majeures de l'application, lors d'une mise à jour depuis une version 2019 ou antérieure, certaines données vont être perdues ou devront être modifiées manuellement.

Clés de cryptage

Les clés de cryptage que les utilisateurs auraient saisies ne peuvent servir sur le socle 2020 et sont écrasées à la mise à jour.

Après cette dernière il faut rappeler aux utilisateurs qui auraient activé la fonctionnalité de saisir à nouveau leur clé.

Templates de mail

Sur le socle 2019 les templates de mail étaient au format PHP ors à partir de 2020 ils sont à définir au format HTML. Les templates inclus par défaut le seront lors de la mise à jour mais ceux édités précédemment par les administrateurs seront à re-saisir manuellement.

Périodes

Après avoir effectué la mise à jour, il faudra pour chaque période disponible effectuer une mise à jour (même si aucune donnée n'est modifiée) pour que cette dernière soit fonctionnelle.

Historique

En appliquant la procédure décrite ci-dessus l'historique des demandes GTF n'est pas importé sur la nouvelle base de données et donc ile ne sera pas visible depuis l'application.

Ce dernier reste néanmoins présent sur l'ancienne base de données.

Depuis GTF 2021

Le dossier contenant les traitements FME doit être déplacé, en cas de mise à jour depuis les versions 2020 ou 2021 de GTF.

Il existe plusieurs cas de figure :

  • Vous êtes en train de faire une installation vierge de GTF, vous n'avez rien à faire.

  • Vous faites une mise à jour depuis une version comprise entre 2020.00 et 2021.01.05 :

    • Vous stockez vos fichiers sur le disque dur de la machine, dans ce cas le setup se chargera du déplacement du dossier (cette opération peut prendre quelques minutes).

    • Vous stockez vos fichiers sur S3, dans ce cas vous devez faire une synchro du dossier s3://mon_bucket/mon_prefixe/ws_data/gtf/workspace avec le dossier vas/var/workspaces

  • Vous faites une mise à jour depuis une version antérieur à 2020 :

    • Appliquer la procédure définie précédemment, en copiant les workspaces directement dans le dossier vas/var/workspaces

Depuis GTF 2022.01

Le fichier de configuration de l'engine vitis gtf/vas/engine/vitis/conf/properties.json est à retoucher dans certains cas.

Il est conseillé de modifier la properties vitis_runner_log_path pour utiliser la valeur @prop(log_dir)/@date/engines/runner.log, ce qui améliorera l'arborescence des logs pour la consultation à travers le client web.

Il sera aussi nécessaire d'utiliser un chemin absolu à la place d'un chemin relatif dans la properties vas_dir si ce n'est pas déjà le cas.

Pour les distributions Linux exécuter les commandes suivantes :

sudo apt update
sudo apt install -y gconf-service libasound2 libatk1.0-0 libc6 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgcc1 libgconf-2-4 libgdk-pixbuf2.0-0 libglib2.0-0 libgtk-3-0 libnspr4 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxtst6 ca-certificates fonts-liberation libappindicator1 libnss3 lsb-release xdg-utils wget libgbm-dev

Avertissement

Si un paquet vient à manquer, c'est que la version n'est peut-être pas disponible pour votre distribution. Dans ce cas vous pouvez soit trouver une version compatible, soit retirer le paquet de la commande.

Pour vérifier la présence des librairies vous pouvez lancer l'éxécutable de chromium chrome qui se trouve dans le dossier gtf/src/vitis/engine/vitis/node_modules/puppeteer/.local-chromium/linux-901912/chrome-linux ou lancer la commande ldd dessus.

Pour la distribution Debian, qui bloque certaines fonctionnalités du chromium embarqué pour des raisons de sécurité, il faut ajouter la properties chromium_args comme dans l'exemple suivant :

  "chromium_args" : [
        "--no-sandbox",
        "--disable-setuid-sandbox"
  ]