[technique] passage du site en php 7.x et update phpBB

[sly]

(attention technique et pas passionnant, plutôt à destination de dominique, léo et yip)

www.refuges.info tourne sur la version 5.6 de php et ça commence à un peu dater (depuis, il y a eu php 7.0, 7.1 et maintenant 7.3). Il n'y a aucune urgence à le faire mais il faudra le faire un jour, alors vu la météo, je me dis autant avancer ces prochains jours.
Pour éviter de tout casser, je vais dupliquer l'environnement pour tester tranquillement. J'espère me débrouiller sans trop vous embêter, mais peut-être que je vous solliciterais si je coince sur des parties que vous connaissez mieux que moi (api, cartes) et si vous avez un peu de disponiblités.

[Dominique]

Attention : Le phpbb 3.2.0 que nous utilisons n'est compatible que jusqu'à PHP 7.2
J'ai bien peur qu'Il n'existe pas de release de phpbb qui tourne sur PHP 7.3. Il faudrait attendre phpbb 3.3 et on n'a pas de date (on n'en a jamais, ça sort quand ça marche)

Ceci dit, tout à fait en phase avec l'objectif et prêt pour tout support
J'aimerais en profiter pour passer en phpbb 3.2.8 qui vient de sortir. Rien de spectaculaire dans les fonctionnalités mais tant qu'à faire des tests systèmes, autant repartir sur la dernière.

Last but not least : je suis en train de mettre la dernière main au remplacement de leaflet par openlayers,
(quelques petites fonctionnalités assez intéressantes comme la possibilité de superposer 2 fonds de cartes en transparence ou le filtrage aux tuiles swisstopo quand on n'est pas dans la zone qui devrait limiter nos consommations de quotas)
peut être l'occasion de le mettre aussi dans les tests (à moins que tu ne préfères séparer les problèmes ?)

[sly]

Attention : Le phpbb 3.2.0 que nous utilisons n'est compatible que jusqu'à PHP 7.2
J'ai bien peur qu'Il n'existe pas de release de phpbb qui tourne sur PHP 7.3. Il faudrait attendre phpbb 3.3 et on n'a pas de date (on n'en a jamais, ça sort quand ça marche)

C'est noté. Je pense avancer par étape de toute façon, car je profite de l'occasion pour mettre à jour le système, ce qui va m'amener à faire évoluer le postgresql, apache.
Mais je note de m'arrêter avant php 7.3. Pourquoi pas php 7.2 si tout fonctionne avec.

Ceci dit, tout à fait en phase avec l'objectif et prêt pour tout support
J'aimerais en profiter pour passer en phpbb 3.2.8 qui vient de sortir. Rien de spectaculaire dans les fonctionnalités mais tant qu'à faire des tests systèmes, autant repartir sur la dernière.

Excellente idée, d'autant que je suis en train de tester actuellement avec php 7.0 et que le phpBB me renvoi des

PHP Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; p_master has a deprecated constructor in /home/users/sly/www.refuges.info/forum/includes/functions_module.php on line 25, referer: https://sly.refuges.info/wiki/index

Rien de bloquant pour l'instant (c'est juste de l'information) mais j'imagine que dans une version comme peut-être php 7.2 ça va nous poser problèmes.
Et puis, c'est assez logique de faire évoluer les composants que nous utilisons en même temps que les briques systèmes.

Last but not least : je suis en train de mettre la dernière main au remplacement de leaflet par openlayers,
(quelques petites fonctionnalités assez intéressantes comme la possibilité de superposer 2 fonds de cartes en transparence ou le filtrage aux tuiles swisstopo quand on n'est pas dans la zone qui devrait limiter nos consommations de quotas)
peut être l'occasion de le mettre aussi dans les tests (à moins que tu ne préfères séparer les problèmes ?)

Excellent ! Même si je me rends moins compte que toi de ce que l'on gagne vu que j'ai toujours vu les cartes bien fonctionner
"séparer les problèmes ?" => peut m'importe, disons que j'ai un peu de temps de dispo en ce moment donc je préférerais en profiter. Si ton code est prêt, tu peux y mettre, sinon, je ne pense pas que leaflet codé en js ne nous fasse de misères à cause de php 7.2.
A moins que la sortie GeoJSON de postgres 11 (version que je vise) ne soit pas digeste pour leaflet ?

Mais je n'en suis pas là, j'ai commencé et je test (sur un clone) actuellement de passer de php 5.6 à php 7.0 et de postgresql 9.4 à 9.6 : bref, des logiciels par défaut d'une debian 8 (avril 2015) à ceux de debian 9 (juin 2017)
Et je suis agréablement surpris. En a peine 2 heures j'ai mis à jours le système sans trop de problème et je ne rencontre aucun problème de code, de warning ou d'erreur.
Je teste encore un peu et je pense basculer www.refuges.info dessus, s'il reste des trucs, ça doit pas être trop méchant et nos sympathiques utilisateurs nous les indiquerons !

[Dominique]

Excellent ! Même si je me rends moins compte que toi de ce que l'on gagne vu que j'ai toujours vu les cartes bien fonctionner

En fait, j'y gagne surtout en maintenance.

"séparer les problèmes ?" => peut m'importe, disons que j'ai un peu de temps de dispo en ce moment donc je préférerais en profiter. Si ton code est prêt, tu peux y mettre, sinon, je ne pense pas que leaflet codé en js ne nous fasse de misères à cause de php 7.2.

Le problème est en effet bien séparé. Je voulais juste profiter de la phase de tests.
Par contre, le code n'est pas tout a fait prêt. Peut être une semaine ou 2. Tant pis, je ferai pas à pas après, ça ne devrait pas être si dramatique.

Une question juste pour le plaisir de la poser : tu ne voudrais pas profiter repasser en MySql par hasard ?
Parce que phppgadmin
MySQL traite très bien le spacial maintenant, avec du SQL tout à fait identique
Par contre, je ne sais pas pour PDO et on risque de galérer dans la conversion de base
Bon, voilà, c'est posé. J'le r'frai plus Msieur
Quand même : phpmyadmin

Pour phpbb, il semble indispensable de le faire en même temps. ça fait trop longtemps que je tergiverse.
Le message d'erreur sur 7.0 est bizarre : phpbb 3.2.* devrait marcher de PHP 5.5 à 7.2. J'ai plusieurs sites en prod et en tests avec plein de variantes PHP / PHPBB et je n'ai jamais eu de pb.
Par contre, il faut en même temps mettre les nouveaux fichiers et passer une moulinette sur la base. Raison pour laquelle je recule ce moment d’ailleurs.
Faudra voir comment on procède
- pour les tests
- pour le basculement

Je suis en train de faire quelques tests d'upgrade avec la base de test et ça plante complètement. J'investigue et je reviens avec qque chose qui marche.

[sly]

Je voulais juste profiter de la phase de tests.
Par contre, le code n'est pas tout a fait prêt. Peut être une semaine ou 2. Tant pis, je ferai pas à pas après, ça ne devrait pas être si dramatique.

Est-ce que créer une nouvelle base test_ol copiée depuis "test" pourrait plus facilement te permettre de tout casser sereinement sur dom.refuges.info ?
Ou sinon, pas de problème pour laisser plus longtemps le serveur virtuel cloné si tu veux : il est disponible sur l'IP 212.83.143.141 (tous les identifiants sont identiques, c'est juste que aucune url ne pointe dessus, donc dom.refuges.info ne pointe pas dessus, mais ça peut se faire sur une nouvelle url ou en utilisant la manip du fichier hosts : https://www.wistee.fr/configuration-nom ... hosts.html )

Une question juste pour le plaisir de la poser : tu ne voudrais pas profiter repasser en MySql par hasard ?

ça me titille...
un hébergement mutualisé en php/postgresql c'est plutôt assez rare, donc pénible de faire tourner le code de wri ailleurs. Comme on a un serveur spécial pour wri, c'est moins un problème, mais quand même, en terme de maintenance ça sort de mes procédures habituelles, je suis plus habitué à MySQL (ou Mariadb) que postgresql.
Bref, j'y pense...
Mais ça fait un peu avancer et reculer cette histoire. J'ai quelques procédures WRI (pour recharger les départements, les réserves natuelles) qui sont conçues pour postgresql, je ne m'en sers pas souvent mais j'ignore si je vais pouvoir les convertir facilement en MySQL-GIS
Sans compter qu'il faut évidement valider que nos requêtes GIS par PDO actuelles sont compatibles.
Potentiellement un peu de galères quoi...

Parce que phppgadmin

je n'utilise quasiment pas j'utilise lui : https://sly.refuges.info/adminersly/adminer.php
Plus général, mais plus pratique pour faire des requêtes je trouve.

Pour phpbb, il semble indispensable de le faire en même temps. ça fait trop longtemps que je tergiverse.
Le message d'erreur sur 7.0 est bizarre : phpbb 3.2.* devrait marcher de PHP 5.5 à 7.2. J'ai plusieurs sites en prod et en tests avec plein de variantes PHP / PHPBB et je n'ai jamais eu de pb.

C'est un message de NOTICE, donc sans conséquence autre que de s'afficher si on force son affichage, sinon, ça tourne (en apparence) sans problème si on n'active pas les NOTICE, ce qu'aucun hébergeur ne devrait faire par défaut.

Par contre, il faut en même temps mettre les nouveaux fichiers et passer une moulinette sur la base. Raison pour laquelle je recule ce moment d’ailleurs.
Faudra voir comment on procède
- pour les tests
- pour le basculement

Je suis en train de faire quelques tests d'upgrade avec la base de test et ça plante complètement. J'investigue et je reviens avec qque chose qui marche.

On peut passer tout le serveur, donc www.refuges.info autant que dom/sly/.../.refuges.info sur php7.0+postgres 9.6+debian 9 ce week end, d'après les tests que j'ai fais, rien ne semble être cassé. (bien que je n'ai pas de tests unitaires)
De là, tu aura peut-être moins de problème sur une version plus récente de phpBB avec php 7.0 et on aura avancé d'un cran en débugant par étapes.
De là, on pourra ensuite mettre par exemple MySQL pour faire des tests en parallèle ou envisager d'avancer vers une debian 10 avec postgresql 11 et php 7.2

Ou alors on peut rester encore un peu avec le clone que j'ai créé et tester dessus le phpBB récent, mais à terme, ce clone sera détruit (pas les données à jour) donc il faudra refaire sur le serveur de prod, mais en nottant ou en créant une branch sur git, ça peut faire aussi.

Bref, que des solutions, ton avis ?

[Dominique]

J'ai uploade phpBB-3.2.8_FR sur le GIT
==> IL EST PREFERABLE DE NE PAS FAIRE DE PULL GIT SUR LE SITE DE PROD POUR L'INSTANT (mais si on le fait, il n'y aura pas de dégat)
J'ai upgradé la base de test à phpBB 3.2.8 (la base de prod reste à phpBB 3.2.0)

J'ai fait des test avec toutes les combinaisons de PhpBB base sql / fichiers
Fichiers 3.2.0, base 3.2.0 : OK (la prod aujourd'hui)
Fichiers 3.2.8, base 3.2.0 : OK (l'admin de PhpBB râle un peu mais ça marche)
Fichiers 3.2.0, base 3.2.8 : Gros KO. ça sera le cas des dev sly.r.i & leo.r.i : Il suffit d'un pull GIT et on tourne en nominal 3.2.8
Fichiers 3.2.8, base 3.2.8 : Tout OK

Est-ce que créer une nouvelle base test_ol copiée depuis "test"...

C'est pas le serveur de test qui m'intéresse, c'est les testeurs et la batterie de tests intensifs qui va avec.

j'utilise lui : https://sly.refuges.info/adminersly/adminer.php

MERCI ! je vais voir ça.

Bref, que des solutions, ton avis ?

Pour moi, le point de PhpBB 3.2.8 est résolu.
Je propose :
- Repars du GIT actuel (donc en phpBB 3.2.
- Tu auras un message d'erreur sur le tableau de bord de l'admin mais le reste tourne.
- Donne moi accès à ton serveur de test, je ferai l'upgrade de la base en phpBB 3.2.8 (il faut FTP le répertoire /forum/install/... de la distrib PhpBB (non dispo sur le GIT WRI) puis exécuter ce /forum/install et demander l'upgrade de la base seulement. ça prend 10 secondes).
- Pour le reste, je te laisse jouer avec les versions de PHP & pgSQL. Prêt pour tout support que tu me demanderais
- Quand c'est OK, bascule la prod (serveur, fichiers du GIT, PHP & pgSQL) sans upgrader la base de prod en 3.2.8 (je suppose que tu repartira de la base de prod en 3.2.0). ça ne posera aucun problème temporairement.
- Quand tout aura basculé, donne moi le feu vert pour le moulinage de la base de prod en 3.2.8 mais rien ne presse : il faudra le faire à terme mais on peut rester 3 ou 4 jours comme ça. C'est juste important de le faire en dernier.
Les cartes ne devraient pas poser de problème, on verra openlayers plus tard (je ne suis pas vraiment prêt)

[sly]

J'ai uploade phpBB-3.2.8_FR sur le GIT
(...)
Fichiers 3.2.0, base 3.2.8 : Gros KO. ça sera le cas des dev sly.r.i & leo.r.i : Il suffit d'un pull GIT et on tourne en nominal 3.2.8

Un "git pull" et une vidange du /forum/cache/production, et tout semble nikel.

C'est pas le serveur de test qui m'intéresse, c'est les testeurs et la batterie de tests intensifs qui va avec.

Je comprends, hélas on n'a pas de tests unitaires automatiques qui couvrent tout (est-ce de toute façon possible ?)...
Et d'expérience, les utilisateurs habituels, dont moi, je me dénonce !, à part faire clic clic vite fait ici et là qui ne révèle pas de gros bugs, ben, ça reste succinct, forcément, on ne sait pas trop quoi tester !
Je propose de faire un dump SQL (GIT s'occupant du code) et de passer ta modif en prod, rien ne vaut l'utilisation pour repérer des bugs.

Pour moi, le point de PhpBB 3.2.8 est résolu.
Je propose :
- Repars du GIT actuel (donc en phpBB 3.2.
- Tu auras un message d'erreur sur le tableau de bord de l'admin mais le reste tourne.
- Donne moi accès à ton serveur de test, je ferai l'upgrade de la base en phpBB 3.2.8 (il faut FTP le répertoire /forum/install/... de la distrib PhpBB (non dispo sur le GIT WRI) puis exécuter ce /forum/install et demander l'upgrade de la base seulement. ça prend 10 secondes).

J'ai exporté la base "test" actuelle puis ré-importé sur mon serveur de test en php 7.0. Idem, j'ai dû vidé le cache de /forum/cache/production/* sinon j'avais une erreur pas très sympa. Sans doute que l'installeur de phpBB fait plus que juste upgrade la base ?

Toujours est-il que tout semble opérationnel, et la "NOTICE" que j'avais avant concernant la classe machin et son constructeur n'apparaissent plus.

- Pour le reste, je te laisse jouer avec les versions de PHP & pgSQL. Prêt pour tout support que tu me demanderais
- Quand c'est OK, bascule la prod (serveur, fichiers du GIT, PHP & pgSQL) sans upgrader la base de prod en 3.2.8 (je suppose que tu repartira de la base de prod en 3.2.0). ça ne posera aucun problème temporairement.
- Quand tout aura basculé, donne moi le feu vert pour le moulinage de la base de prod en 3.2.8 mais rien ne presse : il faudra le faire à terme mais on peut rester 3 ou 4 jours comme ça. C'est juste important de le faire en dernier.
Les cartes ne devraient pas poser de problème, on verra openlayers plus tard (je ne suis pas vraiment prêt)

Et ça ne te semblerait pas plus pertinent de passer www.refuges.info/forum en phpBB 3.2.8 maintenant, ainsi on laisse passer quelques jours a vraiment l'utiliser, et histoire d'isoler passage à phpBB 3.2.8 de passage à php 7.0 ?

[Dominique]

j'ai dû vidé le cache de /forum/cache/production/* sinon j'avais une erreur pas très sympa.

/forum/cache/... est synchro avec une table cache dans la base.
Si tu importes des fichiers d'une source (avec des fichiers dans le cache) et une base qui a vécu une autre vie, le cache SQL et le cache fichier ne sont pas en phase et ça affiche n'importe quoi.
En général, vider le répertoire cache résout le problème.
La vraie solution consiste à passer par /forum/adm et la commande purge qui fait ça proprement.

Et ça ne te semblerait pas plus pertinent de passer www.refuges.info/forum en phpBB 3.2.8 maintenant, ainsi on laisse passer quelques jours a vraiment l'utiliser, et histoire d'isoler passage à phpBB 3.2.8 de passage à php 7.0 ?

Oui.
Ce que j'ai vu sur la base de test m'a donné confiance.
Demain matin. Je le fais à la première heure (pour pouvoir repartir de la sauvegarde de la nuit si pb).
(je n'aime pas faire ça quand je ne te sais pas à quelques cm pour récupérer... je n'ai jamais pu faire une sauvegarde / restauration de cette pgSQL jusqu'au bout !)

[sly]

La vraie solution consiste à passer par /forum/adm et la commande purge qui fait ça proprement.

Ha ouais, vu ! En page d'accueil : "Purger le cache"
Et en effet, curieusement, j'avais accès à l'admin (sans erreur) mais pas au forum.

Demain matin. Je le fais à la première heure (pour pouvoir repartir de la sauvegarde de la nuit si pb).
(je n'aime pas faire ça quand je ne te sais pas à quelques cm pour récupérer... je n'ai jamais pu faire une sauvegarde / restauration de cette pgSQL jusqu'au bout !)

Ouais bon, faut relativiser, si on perd quelques posts du forum ou qu'il y a quelques heures de coupure, c'est pas un drame non plus, on ne fait pas la mise à jour d'un logiciel qui délivre de la morphine à des patients !
Et pis je serais là demain, mais de toute façon tout va bien se passer...

[Dominique]

Ouais bon, faut relativiser, si on perd quelques posts du forum ou qu'il y a quelques heures de coupure, c'est pas un drame non plus, on ne fait pas la mise à jour d'un logiciel qui délivre de la morphine à des patients !
Et pis je serais là demain, mais de toute façon tout va bien se passer...

Voilà. C'est fait. Nous sommes en 3.2.8 partout

C'est bizarre, il m'a créé un répertoire /forum/cache/installation qui n'est pourtant pas dans le GIT.
Jamais vu ça, et ça bloque tout.
Peut-être une tentative de se récupérer quand il s’emmêle les pinceaux entre les caches 3.2.0 SQL et 3.2.8 fichiers ?
Et en plus, le purge cache ne le supprime pas, il faut le supprimer à la main.

Ha ouais, vu ! En page d'accueil : "Purger le cache"
Et en effet, curieusement, j'avais accès à l'admin (sans erreur) mais pas au forum.

adm est en mode sans échec. Heureusement

j'utilise lui : https://sly.refuges.info/adminersly/adminer.php

What à propos de cPanel ?
Evidement, il faut l'apprendre la première fois mais quel plaisir de retrouver ses marques quand un client te dis "je suis hébergé sur trucmuche" que tu ne connais pas et que tu tombes sur cPanel
Je ne sais pas si c'est confortable pour l'hébergeur et il y a bien quelques variantes d'installations (probablement des versions de cPanel) mais quel gain de temps !
...et il y a même pgSQL

[sly]

Voilà. C'est fait. Nous sommes en 3.2.8 partout

Comme anticipé, je ne remarque aucun problème.

What à propos de cPanel ?

Pour gérer les bases PostgreSQL ? Ou c'est une question plus générale ?
cPanel, est bien plus que ça, c'est un outil web pour piloter des hébergements, des mails, des bases de données et plein d'autres trucs sur un système Linux.
Mais c'est orienté "multi hébergement", pour WRI, on est loin du besoin de cette usine à gaz vu qu'on a que 3 hébergement (sly|www|dom).refuges.info

Pour l'hébergeur c'est beaucoup de travail (en plus d'un coût de licence) pour gérer les mises à jours dans la durée, ça fait beaucoup à gérer je trouve juste pour WRI.
Après, on pourrait choisir d'héberger wri chez un hébergeur en cPanel, mais bon, je ne suis pas sûr qu'on est beaucoup à y gagner tant que j'ai la possibilité de gérer moi le serveur.
être direct sur le système sans intermédiaire, c'est peut-être plus de fichiers de conf à manipuler à la main (donc de travail), mais c'est aussi plus de flexibilité pour créer un environnement de dév, un clone du serveur et un backup bien contrôlé

Ou alors tu voulais ne me parler que du composant "pilotage des bases MySQL" ? cPanel a le sien propre ou il fait usage de phpmyadmin comme tout le monde ?

[sly]

Sinon, pour le passage en php 7.0/ pgsql 9.6 je pense faire ça prochainement (avec un backup au cas où)
Peut-être ce soir, ou dans les 2 prochains jours.

[Dominique]

Sinon, pour le passage en php 7.0/ pgsql 9.6 je pense faire ça prochainement (avec un backup au cas où)
Peut-être ce soir, ou dans les 2 prochains jours.

GO (je ne suis pas chez moi ce dimanche. Dans la semaine oui)

[sly]

Voilà donc qui est fait, vu que j'avais convenablement testé avant, il n'y a pas eu de couacs visibles et ça a été assez rapide.
Le serveur (donc chaque site) tourne avec php 7.0 et PG 9.6 (entre autres logiciels + à jour)

Je ne remarque rien de spécial à première vue.

Je vais attendre quelques jours que des bugs remontent à la surface et si rien, je ferais un nouveau clone du serveur dans le but de tester un passage à php 7.2 + PG11