erreur spip_loader 6.0.2 ?

Général
#1

L’installation de SPIP via l’auto-installation de mon hébergeur s’est déroulée sans problème. SPIP 4.1.5 s’est installé automatiquement. Ensuite, j’ai essayé de faire un update vers 4.1.9 comme suggéré sur la page d’accueil via spip loader. Après avoir entré les informations d’identification, j’ai reçu le message d’erreur suivant : « Cette page ne fonctionne pas … actuellement incapable de gérer cette demande. ERREUR HTTP 500 ».
Mon hébergeur m’écrit: "Après vérification, je visualise actuellement l’erreur suivante en testant :

" phar:///htdocs/ca-…/spip_loader.php/index.php’ (include_path=’.:/usr/share/php’) et /htdocs/…/spip_loader .php:32Stack trace :#0 /htdocs/…/spip_loader.php(32): Phar::webPhar(‹ spip_loader.pha… ›, NULL, NULL, Array, Object(Closure))#1 {main} lance dans / htdocs/…/spip_loader.php à la ligne 32’, référence : https://…/spip_loader .php/ index.php

???Votre fichier spip_loader.php semble actuellement poser problème, ligne 32. ???

Je vous invite à prendre contact avec SPIP afin d’en savoir plus sur cette erreur, le codage de ce fichier n’étant pas visible. Vous pouvez les contacter en vous rendant sur la page suivante : https://discuter.spip.net/"

Est-ce que vous pouvez m’aider?
Merci d’avance.
Leo

#2

Bonjour LeoH,

L’erreur indiquée n’est pas très limpide pour comprendre, sachant que le Loader 6.0.2 fonctionne chez d’autres hébergeurs. Quelle est la version de PHP utilisée sur ton hébergement ?

#3

Merci Matthieu,
SPIP 4.1.5.
L’hébergeur est LWS.
En bas le message:
"La mise à jour 4.1.9 de SPIP est disponible | Une nouvelle version SPIP 4.2.0 est disponible
SPIP 4.1.5 is vrije software onder GPL licentie distributie.

  • beveiligingsscherm 1.4.2"
#4

La version de PHP (tu peux la trouver par exemple dans ecrire/?exec=info)

#5

Oeps, sorry.
PHP Version 8.0.28

#6

Bonjour,
J’ai également un problème avec la version de PHP 8.0.28 mais chez o2switch. J’avais un message d’erreur d’impossibilité d’utiliser le loader ; j’ai activé l’extension sodium et maintenant j’ai une page blanche en lançant le loader. Dans le log j’ai :

"Stack trace:
#0 /home/public_html/site.com/spip_loader.php(32): Phar::webPhar()
#1 {main}
  thrown in /home/public_html/site.com/spip_loader.php on line 32
[27-Mar-2023 22:03:08 UTC] PHP Fatal error:  Uncaught PharException: phar "/home/public_html/site.com/spip_loader.php" SHA512 signature could not be verified: broken signature in /home/public_html/site.com/spip_loader.php:32

J’ai aussi relancé le transfert du fichier loader en forçant « binaire » (ce qui d’habitude n’est pas nécessaire) et étrangement maintenant j’arrive à la page : https://site.com/spip_loader.php/index.php, mais toujours une page blanche

Sur un SPIP 4.0.11 avec le loader 6.0.2

dd

#7

J’ai exactement le même problème chez O2S mais je n’avais pas réussi à trouver ce log donc je me suis contenté de récupérer un spip_loader.php en v5 (avant que ça passe en phar) et là ça marche à tous les coups. J’ai seulement un ou deux spip chez O2S et je n’ai pas ce pbm sur mes serveurs Debian.

Question à @_dd: ou trouvez-vous ces logs chez O2S ? dans l’interface C-Panel ou dans l’installation Spip ? Merci !
Pierre.

#8

Bonjour @Pierr0t ,
Le log est le fichier à la racine du site SPIP :
.o2switch.net/public_html/monsite/error_log

A mon tour de te questionner : avec quelle version du spip_loader as-tu réussi ?
J’ai essayé avec sans succès avec :

Le chargement a échoué. Veuillez réessayer, ou utiliser l'installation manuelle.
spip_loader 5.1.1

Merci

#9

Bonjour,

Ok merci !

Je me suis repassé le film de cette grosse séquence de mises à jour et je me rends compte qu’en fait la fois précédente j’avais réussi à récupérer une version qui fonctionnait (entre tous les sites qu’on mets à jour j’en ai trouvé un qui avait un spip_loader.php plus ancien) mais que cette fois ci impossible de récupérer un spip_loader.php qui fonctionne (je pense de mémoire qu’il faut un spip_loader en 5.0.X avant le passage en phar) et j’ai donc, cette fois-ci, mis à jour en téléchargeant Spip et en écrasant via SFTP pour ce site rebelle.
Et d’ailleurs à ce propos j’arrive à trouver sans problèmes les archives des versions précédentes de spip mais impossible de trouver l’équivalent pour les spip_loader.php.

Note: après recherche je viens de retrouver un spip_loader.php en v5.0.1 si tu veux tester …

Pierre

#10

On ne maintiendra pas ad vitam le fonctionnement de ces vieux loaders…
Ça serait mieux de nous aider à identifier et résoudre les problèmes rencontrés avec le nouveau !

Pour

SHA512 signature could not be verified

Ça ressemble quand même à un mauvais transfert du contenu du fichier spip_loader.php à la base.

Une autre piste : pouvez vous regarder si vous avez l’extension « suhosin » d’activée ?

Sur un vieille doc de PhpUnit on peut lire :

If the Suhosin extension is enabled, you need to allow execution of PHARs in your php.ini:

suhosin.executor.include.whitelist = phar

A priori on peut trouver cette extension active jusqu’en PHP 8.0 ? (même si j’avais l’impression que ce n’était plus l’utilisé)

#11

Alors j’ai re-transféré le dernier spip_loader.php en binaire : pas mieux. Sur mon hébergement il n’y a pas l’extension suhosin activable (PHP Version 8.0.28)

Par contre dans le log_error de la racine du site j’ai un nouveau message :
[28-Mar-2023 17:08:00 Europe/Paris] PHP Warning: Undefined array key "titre_maj" in /home/public_html/site.com/spip_loader.php on line 386

C’est pas hyper urgent pour l’instant.

merci
dd

#12

Ça ne ressemble pas à une erreur d’un SPIP Loader v6 cela… ou qqc m’échappe.

#13

Super cool ça : Comment créer un site web Spip ? - Divers CMS - LWS

Le truc, c’est qu’on ne sait pas ce qui ce passe derrière cette auto-installation maison … peut-être qu’il change le chmod, peut-être autre chose … peut-être que leur système rend l’utiilisation de spip_loader impossible. Peut-être que leur système devrait aussi prendre en compte l’update des sites ?

#14

Chez O2Switch aussi, php 8.0, spip_loader 5.3.0 se lance bien et fonctionne, si j’accepte la mise à jour vers 6.0.2 j’obtiens une page avec :
La page n’est pas redirigée correctement
Une erreur est survenue pendant une connexion à www.site.org.
La cause de ce problème peut être la désactivation ou le refus des cookies.
Mais rien n’apparait dans le fichier error.log

Si je transfére le 6.0.2 par FTP en mode binaire, j’obtiens une page blanche à l’adresse site.tld/spip_loader.php/index.php et rien non plus dans le error.log

#15

Sans vouloir polémiquer j’ai fait plusieurs messages sur ce sujet depuis que spip_loader.php est devenu « phar », en gros on m’a dit que je ne savais pas envoyer un fichier en binaire (en particulier quand j’ai signalé qu’un logiciel comme Transmit ne rend pas la chose facile car le type de transfert dépends de l’extension, il faut donc renommer le fichier pour qu’il parte en binaire, on m’a conseillé de passer sur Filezilla ce dont il n’est pas question pour moi, j’ai plusieurs 100aine de signets dans Transmit et je travaille avec depuis 20 ans sans pbm depuis une époque ou Filezilla stockait les mots de passe en clair dans un fichier texte), sans parler du fait que 99% du temps je n’ai pas transféré le fichier j’ai juste utilisé la mise à jour intégrée à spip_loader.php,.
Donc étant donné que j’ai des 10aines de sites à mettre à jour à chaque alerte, je fais au plus efficace et je me garde une ancienne version pour les cas à problème, encore une fois effectivement assez souvent chez O2S (qui est un hébergeur spécial, serveur web LiteSpeed, … c pas cher et efficace, mais j’ai rencontré quelques incompatibilités au cours de ma longue carrière, j’ai une 30aine de sites divers chez eux) et une fois ou 2 sur des Debian 11 classiques.
Bref je suis tout ces sujets avec attention et je suis toujours prêt à aider si on me le demande, mais encore une fois (et on le voit avec cette fois-ci quelques sites qui se font hacker) quand il y a une mise à jour de sécurité on n’a pas trop le temps de diagnostiquer, il faut mettre à jour urgemment.
Pierre

1 « J'aime »
#16

Tu fais donc référence à juin 2022 spip_loader page blanche - #7 par JLuc

C’est du logiciel libre, et le Loader est essentiellement géré sur du temps libre, dont les tickets et les sources sont là Issues - spip_loader - SPIP on GIT ; Personnellement je n’en ai aucune utilité de ce Loader : as-tu pu aider depuis juin sur ses tickets et faire avancer le schmilblik ? Pourquoi est-ce nous qui devons faire l’effort et prendre le temps de traiter les problèmes des hébergements spécifiques ? C’est pas comme si on avait des tonnes d’autres choses à faire… On essaie d’y mettre de la bonne volonté pourtant…

L’ancien Loader, avant qu’il ne soit un .phar implique qu’il faut laisser sur Spip.net des vieux fichiers que celui-ci télécharge (pclzip, les traductions, …). On ne laissera pas ces fichiers éternellement sur Spip.net.

On a cherché à rendre le processus de distribution du loader, plus facile, et surtout, surtout, sa maintenance de notre côté. Parce que le fichier unique était imbitable ; son code a été complètement redécoupé (mais une partie du code reste ancienne pour le moment).

Pour distribuer ce loader, un phar a moult avantages ; le contenu du phar est signé et compressé : il sait si son contenu est intègre et complet, il permet de regrouper tous les fichiers sans se prendre la tête, etc…

Mais les webPhar, ça ne court pas les rues effectivement, du coup on découvre des problèmes au fur et à mesure. Et en quoi c’est notre problème que Transmit ne permette l’envoi en binaire que pour certaines extensions ? Quelle solution proposes-tu ? Sachant que la plupart des hébergements n’acceptent pas d’exécuter des extensions .phar depuis le web (ce qui serait bien plus simple pourtant)

Notons qu’en terme de sécurité informatique, faire des mises à jour via le web, ce n’est déjà pas génial. Une de nos envies serait que ce phar puisse servir aussi en CLI pour faire ces mises à jour (mais il faut alors un accès ssh par exemple).

Il y a toujours la branche 5.1 du loader là spip-contrib-outils/spip_loader - spip_loader - SPIP on GIT hein si quelqu’un·e veut s’en occuper, le forker, gérer PHP 8.2 dessus… etc…

Je m’excuse, je suis désolé de m’agacer en lisant cela… ça me fatigue ces problèmes de Loader, de Phar, et d’hébergements exotiques… ou du moins dont on ne comprends pas encore ce qui cloche.

#17

Bonjour :slight_smile:

Merci pour ta fidélité. 20 ans déjà …

On a commencé le développement du mode phar pour le loader en janvier 2022 et on a pris la peine de faire une phase de test d’environ 1 mois. et publié la 5.2.0 fin mars. 1 an tout pile.

Si tu es prêt à aider, tu seras là pour les tests de la V7 du loader ?

#18

Y a t il un ticket Transmit pour régler ce problème de ton logiciel de FTP ?
Sinon il faudrait en créer un.

Ou exporter les signets pour les importer dans filezilla.
Et faire un ticket Transmit pour demandar la possibilité d’exporter les signets, si ça ne le permet pas déjà. En attendant, je comprend que c’est difficilement supportable d’être enfermé avec Transmit (« walled garden » comme avec Adobe par exemple)… mais c’est donc un problème Transmit.

#19

En résumé, il y a des soucis chez LWS et O2Switch au moins.
Qqn·e pourra-t-il nous fournir un accès à un compte cPanel sur l’un des deux peut-être ?

#20

Je ne sais pas s’il y a véritablement un problème sur Transmit en regardant la doc

Vu que FTP peut être configuré en Binary (j’imagine que c’est le mode ‹ Auto › qui pose problème. sFTP envoie toujours en Binary.