Mises à jour de Drupal impossible

Voici https://ftp-origin.drupal.org/files/projects/le lien (attention la liste est longue, cela risque de faire ramer votre navigateur).

Je viens de télécharger sur mon PC le fichier "abc-7.x-4.x-dev.zip" de 884 Ko en quelques instants

Oui, mais quand on le télécharge à la main, ça marche, c'est quand on essaie de le faire à partir du panel admin de Drupal que cela ne marche pas. Normal: ces modules (panels et ctools, dernières versions) ne sont pas présents sur le dépôt. Et je ne comprends pas pourquoi on arrive à les télécharger à la main :tired_face:
Et donc , à la réflexion, ce ne serait pas une histoire de black-listage par OVH, ce serait par hasard que les seules personnes qui ont ce problème soient chez OVH? Bizarre.

Je confirme l'impossibilité soudaine de mettre à jour les modules via l'admin de Drupal 7.51.
Message d'erreur avec ctools (c'est vrai aussi avec les autres modules) :
`L'erreur HTTP 0 s'est produite lors de la tentative de récupération de https://ftp.drupal.org/files/projects/ctools-7.x-1.11.tar.gz.
Le téléchargement des mises à jour a échoué :
Echec du téléchargement de ctools depuis https://ftp.drupal.org/files/projects/ctools-7.x-1.11.tar.gz`

Bonjour,

Est-ce que cela arrive aussi sur un site drupal hébergé chez un autre hébergeur? J'en ai un mais malheureusement je ne peux plus faire l'essai, je l'ai mis à jour par clonage du site chez OVH.

Bonjour,

Comment effectuez vous la mise à jour ? Depuis une connexion SSH ou depuis la page web de l'administration de drupal ?

Cordialement,
Vincent

Depuis la page web de l'administration Drupal.
D'après le message d'erreur, ce qui ne réussi pas c'est bien le téléchargement de l'archive du module, et non son installation.

Ce que je ne comprends pas c'est que si on regarde dans le répertoire ftp.drupal.org/files/projects/ on voit que l'archive ctools-7.x-1.11.tar.gz ne s'y trouve pas, mais si on tape ftp.drupal.org/files/projects/ctools-7.x-1.11.tar.gz dans la barre d'adresse du navigateur, il le trouve! L'archive se télécharge!

L'erreur renvoyée en log est "Erreur lors de l'ouverture de la socket ssl://ftp.drupal.org:443"
Mais le problème ne vient pas de Drupal je pense car sur d'autres sites non OVH il n'y a pas de problèmes.

Comment se fait-il qu'on ne voit pas l'archive dans le répertoire sous navigateur? Alors qu'on arrive à la télécharger à la main, par le même navigateur, et dans le même répertoire :flushed: ?

Même problème mais aussi pour d'autres modules qui se sont ajoutés ajourd'hui : i18n, panels, language fields ...

Aïe !! même souci sur plusieurs sites avec différents modules.. le tout chez OVH

Bonjour,

J'ai créé un https://www.drupal.org/node/2820590 fil sur le forum de la communauté de Drupal, il est notoire que ceux qui y ont répondu sont tous hébergés chez OVH, et qu'il y a relativement peu de réponse, c'est-à-dire que les gens qui ne sont pas chez OVH n'ont pas rencontré le problème.

Si on est obligé de faire les MAJ à la main, c'est un peu moyen :weary:

J'ai souscrit à l'offre PRO2014.
Un confrère qui a souscrit à l'offre PERFORMANCE me dit n'avoir aucun problème avec ses différentes occurences de Drupal.
Hasard ?

Ca ressemble à des connexions sortantes bloquées chez OVH, tout comme les les connexions sortantes SMTP, Submission, mysql ont tendance à échouer dans la grande majorité de cas (mais pas 100% ?)

Connexions sortantes bloquées possible...

Pour info :
Je viens de faire un tour vite fait sur les sites que j'ai fait qui vont des vieilles offres 90plan aux nouvelles offres pro.. Ils ont en commun la version 7.50 drupal et le module Ctools à mettre à jour (je ne compte les autres modules divers et variés à mettre à jour mais pas forcément présents sur tous les sites..(+ de 10)

et donc ? tu as le bug sur tous les sites ?

Yes .. ;(

meme probleme sur mon site drupal depuis quelques jours impossible de mettre a jour ou installer des modules par url via la page d'administration. par contre si l'on telecharge le fichier manuellement et qu'on l'upload via cette meme page de soucis.

Bienvenue au club. Sur la discussion sur le forum de Drupal, il n'y a toujours que des gens hébergés chez OVH qui ont ce problème.

Au vu du nombre de personnes signalant de problème, celui-ci semble bien venir de OVH.

Messieurs les "Helpers" vous avez du travail.

> par contre si l'on telecharge le fichier manuellement et qu'on l'upload via cette meme page de soucis.

Ok mais quand il y en a plein c'est plus possible la bricole...

Alors tous avec Gaston ! Messieurs d'OVH faites qqchose Merci ! :smirk:

Voici la réponse d'OVH pour contourner le problème !!

"_Merci de noter qu'il n'est pas conseillé de faire des mises à jour automatique_
_des modules drupal, Prestashop et autres directement au niveau de vos_
_interfaces administrateurs sous risque de voir vos sites générés des erreurs_
_que vous serez obligés de corriger à votre niveau._
_En cas de dernière version stable de votre module drupal, la solution qui_
_s'offre à vous est de la télécharger puis l'installer manuellement via votre_
_serveur FTP ._ "

Et la mienne

"_Je n'utilise pas un pack pré-déployé par ovh mais une version de drupal que j'ai envoyée par ftp moi-même._

_Votre réponse, ne répond pas à mon problème. Libre à moi de choisir ma méthode d'update qui fonctionnait jusqu'à récemment._
_Envoyer manuellement les fichiers est risque d'erreur._

_Merci de me dire pourquoi cela ne fonctionne plus et pourquoi d'autres utilisateurs ovh rencontre le même problème._"

Grr !!

LOL cette réponse d'OVH...

bonjour,

merci de passer en environnement **stable** via le guide ci dessous, cela a régler le problème de mon coté.

https://docs.ovh.com/fr/fr/web/hosting/modifier-lenvironnement-dexecution-de-mon-hebergement-web/

Bonjour,
Je viens d'avoir OVH au téléphone , il faut modifier le fichier .ovhconfig sur le ftp et rajouter la ligne :

container.image=stable

Un technicien me l'a fait en direct et j'ai pu tester le téléchargement ça marche :)
maintenant le pourquoi du comment... l'explication d'OVH va être remontée sur ce fil.
Bonne journée

Bonjour Boulvard,

Tu as totalement raison. La configuration HTTPS des sites de drupal semble s'être renforcée récemment, ce qui rend la configuration **legacy** obsoléte. Un passage en configuration **stable**, contenant un openssl bien plus récent, devrait régler vos soucis.

(Pour info, jusque maintenant, l'environnement **stable** était simplement nécessaire pour Drupal 8 qui a besoin d'un drivers php-mysql récent. Maintenant, c'est obligatoire pour drupal 7 aussi)

Cordialement,
Vincent

En effet ça fonctionne avec Stable.

Et quel est la différence entre toutes versions, stable, testing, legacy, jessie ?

au temps pour moi, c'est expliqué ici : https://docs.ovh.com/fr/fr/web/hosting/modifier-lenvironnement-dexecution-de-mon-hebergement-web/

Eh bien voilà !
Merci aux contributeurs.

Bonjour,

Merci de votre aide, je vais retransmettre cela sur le forum de la communauté Drupal. Personnellement je verrai si ça marche lors de la prochaine mise à jour de modules, je ne vais pas simuler un retour en arrière.

Cela dit, je ne comprends toujours pas pourquoi:
- les archives des modules concernés n’apparaissent pas dans la liste du contenu du dépôt sous navigateur (là on ne passe pas du tout par OVH),
- alors qu'on arrive quand même à les télécharger à la main

Mais bon.

Et sans commentaire sur le fait que:
- la réponse officielle de OVH soit une réponse de bouffon : "merci de pendre en compte que vous ne pourrez plus utiliser votre admin panel pour faire les maj..."
- et que la réponse officielle ne nous ait pas été communiquée officiellement par OVH mais officieusement , grâce à un utilisateur, merci à lui, qui nous a fait part de sa communication téléphonique avec le support.

Merci à vous.

PS : je ne coche pas encore dans "résolu", j'attends un peu, si des fois il y aurait une autre mise à jour de module sous peu.

"legacy" signifie "héritage" c'est-à-dire en gros, c'est la config où on fait en sorte que les "vieux logiciels" marchent encore. "stable" signifie que le site est au point, "testing" qu'on est en train de bricoler dessus et donc notamment qu'il va envoyer pas mal de messages d'erreur qu'il n'enverrait pas en "stable".
Jusqu'à présent pour Drupal 7, qui était réputé être du "legacy" puisqu'il y a Drupal 8, on nous disait de mettre "legacy" dans le .ovhconfig, mais maintenant, donc, suite aux problèmes observés, on va mettre "stable".
Le fait est que Drupal 7 n'est pas si "legacy" que ça, on continue à le maintenir voire à y développer, et personnellement je ne sais pas si je passerai en Drupal 8 de mon vivant.

PS : "jessie", je ne sais pas ce que c'est.

PS : à oui, autant pour moi, je n'ai pas vu que tu avais vu où c'était expliqué :blush:
Jessie est le nom d'une version de Debian, qu'ainsi on demande sur notre serveur.

> - et que la réponse officielle ne nous ait pas été communiquée officiellement par OVH mais officieusement , grâce à un utilisateur, merci à lui, qui nous a fait part de sa communication téléphonique avec le support.

C'est un peu dur à entendre. Il me semble qu'on est assez réactif. Moins d'une journée pour investiguer un soucis dans des codes que nous ne maitrisons pas, c'est pas mal non ?

Bref, soucis résolu :)

Comment procéder alors pour la configuration STABLE de PHP 3.5 ?

Je pense que **_PHP 3.5_** n'est plus proposé sur les mutualisés.

c'est justement pour cela que je parle de "dédié"

Ici tu es dans la section :

Pour ton cas ce serait ;

Bonjour

Je fais face au même souci de mise à jour des modules drupal sur un des mutualisés que je gère.
Lorsque j'essaye de passer en mode 'stable' ou 'jessie' (ce qui a l'heure actuelle est la même image mais bon j'ai quand même essayé), voici ce que me répond drupal

PDOException: SQLSTATE[HY000] [2000] mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication. Please use an administration tool to reset your password with the command SET PASSWORD = PASSWORD('your_existing_password'). This will store a new, and more secure, hash value in mysql.user. If this user is used in other scripts executed by PHP 5.2 or earlier you might need to remove the old-passwords flag from your my.cnf file in lock_may_be_available() (line 167 of /home/odelicesa/www/includes/lock.inc).

j'avoue être un peu perdu, drupal ayant été installé en v6 via l'interface OVH, puis migré en v7 à la main, la base de donnée liée au module n'apparait pas dans mon gestionnaire...

Merci d'avance

(je retourne en legacy en attendant :) )

Bonjour,

c'est tout simplement car drupal avait été installé avec le "1clic" OVH, là vous devez transférer la BDD du SQL module a un SQL "normale" que vous devez créer dans le manager.

Cordialement, janus57

Pour les serveurs web mutualisés perso et pro version 2010, on a pas accès aux versions php via l'espace client.
Et pour changer les versions php il n'y a pas de fichier .ovhconfig qui remplace le fichier .htaccess à la racine avec les fichiers .bash_logout, .bash_profil etc...

Il faut donc le créer à la main
pour plus d'informations sur ce fichier:
https://docs.ovh.com/fr/fr/web/hosting/activer-loptimisation-php-sur-son-hebergement-mutualise-ovh/
avec ces infos :
app.engine=php
app.engine.version=(5.6 ou 7.0 etc comme tu veux)
http.firewall=none
environment=production
container.image=stable

cette modif a résolu le problème pour moi

Chez moi c'est juste la partie
**container.image=stable**
qui manquait.
Et là ça marche et c'est cool :-)