You are not logged in.
Bonjour,
Je prends quelques infos avant mise à jour vers GLPI 9.5.5.
Etant donné que je pars de versions antiques, est-ce qu'il y a un chemin préférable ?
Actuellement, GLPI 9.3.2 (aucun plugin) est sur une instance PHP 5.6.
J'ai une instance PHP 7.3 de dispo et bientôt une instance PHP 8.0.
Le tout en Apache 2.4.
Je pense faire ainsi :
- Déplacer GLPI 9.3.2 sur l'instance PHP 7.3
- Mettre à jour vers GLPI 9.5.5 (sur l'instance PHP 7.3)
- Déplacer GLPI 9.5.5 sur l'instance PHP 8.0
Est-ce que c'est la bonne manière de faire ?
Last edited by letamaxime (2021-04-26 12:36:00)
Offline
Bonsoir,
J'ai pu migrer directement une "vieille" prod en version 9.1.3 de 2017 qui tournait sur un MS-2012 Server / Wamp (Apache 2.4.23 / PHP 5.6.25 / MySQL 5.4.14), directement sur une instance Linux (Apache 2.4.37 / PHP 8.0.3 fpm / MariaDB 10.3.27) avec une version de 9.5.4 de GLPI.
Le GLPI doit détecter correctement le delta de version en base et le schéma de la version installée.
Les montées de schémas doivent s'enchaîner les unes après les autres, puis il faut intervenir avec la console GLPI pour le changement de moteur MyISAM vers InnoDB, la reconstruction des horodatages manquants, la conversion de tous les champs DATETIME de toute la db vers le format TIMESTAMP (plus facile si je puis dire... à gérer sous *nix que sous MS, avis personnel qui n'engage que moi).
En résumé, si la base de la version existante est saine, les montées de version se déroulent bien.
Globalement PHP ne " casse " pas grand chose en terme de rétro-compatibilité sur le code, mais la c'est le GLPI qui fait tout le boulot, autant attaquer directement par PHP 8.x sur la version en cours la 9.5.5.
En espérant éclairer "un peu " ;-)
Cordialement,
Last edited by homebrewtainy (2021-04-26 19:45:25)
Creuser, creuser... creuser.
GLPI 10.0.16 [ Linux el 9.4 | Apache/2.4.xx | mysql 15.1 MariaDB 10.5.xx | PHP 8.3.x ] - Apache HTTPS r-proxy [ Linux el 9.4 | Apache/2.4.xx ]
GLPI Inventory 1.3.5 | Data Injection 2.13.5 | Treeview (Arborescence) 1.10.2 | Behaviors (Comportements) 2.7.3
-- Any exchange not written in French comes from an automatic translation. --
Offline
Merci pour ta réponse.
Du coup tu penses que je peux dupliquer directement sur PHP 8 et faire la maj ?
Il y a des trucs à faire en plus ? Je n'avais pas pensé à ça, je pensais qu'on écrasait certains fichiers, qu'on accédait à un update.php et que le CMS faisait le reste, un peu comme WP.
Il faut que j'aille lire un peu de doc au sujet des mises à jour je crois.
Offline
Bonsoir,
Les processus d'update sont bien maîtriser par l'appli ( plébiscités soient les développeurs et contributeurs ).
PHP peut être upgradé, mais il ne faut surtout pas oublier MySQL / MariaDB. Ce duo doit être cohérent avec les préconisations de la version cible, celle sur laquelle la montée de version va se faire.
Tente, en ayant sereinement " TOUT " (conf, db et files) sauvegarder sur l’actuelle instance en production, ou encore mieux, en installant une instance de type POC (Proof Of Concept) dans une VM (ESXi, VMw. WorkStation, V.Box ou Hyper V) et en y transférant les bouts de ton actuel GLPI.
Mais le Maitre-Mot, c'est sauvegarde, sauvegarde et sauvegarde ou mieux donc : évaluer " Hors Prod "
Bonne Cuisine ;-) ..
Creuser, creuser... creuser.
GLPI 10.0.16 [ Linux el 9.4 | Apache/2.4.xx | mysql 15.1 MariaDB 10.5.xx | PHP 8.3.x ] - Apache HTTPS r-proxy [ Linux el 9.4 | Apache/2.4.xx ]
GLPI Inventory 1.3.5 | Data Injection 2.13.5 | Treeview (Arborescence) 1.10.2 | Behaviors (Comportements) 2.7.3
-- Any exchange not written in French comes from an automatic translation. --
Offline
OK merci bien.
Oui pas de soucis pour les sauvegardes, généralement j'en fais une à chaque étape pour éviter de perdre mon temps.
C'est en prod, mais en interne, donc je peux monter/remonter ça sans soucis.
Offline