mdata

Voilà, ça y'est, le cap est franchi : je quitte Yulpa. Mes sites et domaines sont en cours de déménagement chez mon nouvel hébergeur, et mon abonnement Yulpa prenant fin à la fin du mois il ne sera pas renouvelé. C'est avec une certaine tristesse que j'écris ces mots, je ne ressens pas de colère vis à vis de Yulpa mais plus une immense tristesse doublée d'une grande déception. Je n'ai pas décidé de partir de gaité de coeur, c'est vraiment parce que la situation n'était plus tenable pour tenir les sites sereinement. Client depuis très longtemps, j'avais rejoins Web4all avec enthousiasme en étant séduit par l'esprit de cette association ainsi que par les performances de sa plate-forme. Le passage à Yulpa fut sympa aussi, mais la situation n'a cessé de se dégrader par la suite et le rachat a véritablement marqué la fin d'une époque. Je choisis de garder en tête les bons moments chez Web4All /Yulpa, en souhaitant bonne chance aux clients qui restent et en souhaitant sincèrement bonne continuation à l'équipe en espérant que la situation s'améliorera. End of line.

Pour ma part j'utilise uptimerobot qui me donne 87% sur les dernières 24h. En tout cas ce fut pour moi la goutte d'eau qui a fait déborder le vase : le cahier des charges est en cours de finalisation, différentes offres sont à l'étude chez les autres hébergeurs du marché et je peux le clamer haut et fort : d'ici la fin du mois (et probablement bien avant) je ne serai plus client Yulpa.

Client depuis très longtemps aussi (2011), je partage ce désarroi. D'ailleurs ce matin c'est encore en panne, et pour ma part c'est très dommageable en terme d'image vu que j'ai un concours lancé depuis hier, un forum relancé depuis peu et mes "concurrents" sont hilares à chaque fois que le site tombe. Ce qui est assez pénible, c'est aussi d'être dans le noir complet : on ne sait plus rien sur le statut de Yulpa depuis le rachat, ni qui s'occupe de quoi. Les promesses commerciales semblent difficilement tenues également. Mon abonnement expire à la fin du mois, des réflexions sont en cours pour déterminer si je vais ailleurs dans un avenir très très proche. (pour la restauration d'un backup de bases : j'ai été confronté au problème il y a quelques temps, en fait il ne faut pas utiliser phpmyadmin mais directement faire un mysql < dump avec les options qui vont bien depuis une console SSH et là ça fonctionne sans problème)

C'est revenu !

En tout cas pour moi c'est reparti pour une panne ce matin...

Tout à fait. Le jour où Yulpa va recevoir ma demande de résiliation, faudra pas faire les étonnés !

Juste au moment où je mets un commentaire désagréable, le service revient !

Toujours rien, j'en viens à me demander si quelqu'un est vraiment sur cette panne.

Donc Yulpa version INEONET c'est une absence totale de communication et des pannes à répétition ? Clairement ça devient insupportable !

Je les ai interpellés sur Twitter, sans grand effet.

J'ai eu ça aussi, j'étais en extérieur et le temps de rentrer faire le ticket c'est revenu mais l'absence de communication est inacceptable. Y'a t-il encore un pilote dans l'avion Yulpa ? On se le demande !

Moi aussi ! Justement je venais voir ici à tout hasard, je me sens moins seul. Je trouve tout ceci absolument inacceptable aussi, trois coupures franches sur ces dernières semaines sans la moindre explication à part un message assez laconique en réponse dans un ticket. Je regarde très sérieusement ce qui se passe ailleurs, là j'en ai marre !

J'ai eu une réponse, je vous en fait part : un espace disque saturé (c'est mon cas, je viens de l'apprendre) peut engendrer des erreurs 503. Au cas où cela vous arriverait, autant que vous profitiez de cette expérience

Bonjour, Je ne sais pas si je suis le seul impacté, mais ce matin mes sites (situés sur la nouvelle architecture) sont en 503. Du coup je ne peux absolument pas travailler

Migration de Watchtower Comics vers une nouvelle offre d’hébergement Intéressé par les nouvelles offres d’hébergement, j'ai souhaité migrer mon site (Watchtower Comics) vers cette nouvelle offre. Il consiste en deux noms de domaine (un historique conservé pour le référencement et un utilisé actuellement), un site de test et un site de prod tournant sur Wordpress ainsi que des ressources graphiques (illustrations d’articles hors gestionnaire de média et couvertures d’albums). Préparatifs Tout d’abord, ouvrir un ticket pour demander une migration en précisant une date et une heure pour la réalisation. Le support valide ensuite la demande suivant la faisabilité du créneau demandé. A titre d’info, pour un hébergement start avec un quota disque rempli à 69% et 2 bases de données bien chargées il avait été estimé que la manoeuvre durerait environ une heure. Ensuite, même si on a toute confiance dans l’efficacité de Yulpa il y a un proverbe bien connu en informatique qui dit « better safe than sorry » (vaut mieux être prudent que désolé). Donc pour ma part, j’ai recopié en local une sauvegarde récente de ma base de données ainsi que les données sur les différentes ressources web qui constituent mon site. Etape 1 : Migration par Yulpa A l’heure dite, Yulpa lance la migration : le site devient offline, et bascule sur le nouvel hébergement. Durée de l’opération : un peu moins de quarante minutes Etape 2 : Analyse et estimation des modifications Premier constat : le site est en ligne tout seul ! Pas de panique, c’est parce qu’il peut tourner grâce au cache Second constat : Les systèmes de sécurité intégrés au site (dont Wordfence) n’ont pas aimé la migration, et vu que la base n’est plus au même endroit le back office est totalement inopérant. On va donc devoir opérer manuellement. Donc à priori, ce qu'il faut faire : remise à plat de la configuration des outils, neutralisation des plugins, modification de la configuration globale pour rétablir le lien aux bases de données Etape 3 : Reconfiguration des outils Pour travailler sur l’hébergement, il faut reconfigurer Filezilla (ou autre client FTP) car le serveur et le chemin ne sont plus les mêmes. Les informations se trouvent dans iWAL, rubrique « Fichiers et accès ». Pour le compte SSH, c’est un peu plus compliqué car contrairement aux anciennes offres il est impossible de fixer un mot de passe soi-même. Il faut donc recopier la clef SSH, voici la démarche sur un Mac : Ouvrir un terminal Vérifier l’existence du répertoire .ssh, s’il n’existe pas il faut le créer Taper la commande ssh-keygen -b 4096 Indiquer une passphrase (comme un mot de passe mais plus long) pour sécuriser la clef Recopier le contenu du fichier .ssh/id_rsa.pub dans un fichier authorized_keys Sur l’hébergement (accédé via Filezilla), créer le répertoire .ssh dans /home Déposer authorized_keys dans le .ssh de l’hébergement On peut ensuite se connecter via ssh avec login@serveur (renseignements dans iWal), on nous demande la passhprase et nous voici connectés. Concernant phpmyadmin, un bug empêche d’utiliser directement l’utilisateur « standard » associé au Wordpress. Il faut alors en créer un nouveau, avec les mêmes privilèges, et indiquer « % » comme serveur. Etape 4 : Modification de la configuration de Wordpress On lance Filezilla, on récupère ensuite le fichier wp-config.php et on change les informations suivantes dedans : le serveur et le login du compte associé à la base de données car le préfixe n’est plus le même. NB : on peut aussi opérer en direct via SSH avec un éditeur (par exemple vi) Une fois ceci fait, il faut éditer le fichier .htaccess si des composants l’utilisent pour spécifier des chemins (par exemple Wordfence). On remplace alors l’ancien chemin de l’hébergement par le nouveau (toujours dispo sur iWall). Le site étant en https, il faut aussi regénérer les certificats Let’s encrypt mais c’est très rapide. On s’aperçoit aussi qu’il y a un souci sur une limitation Apache empêchant la mise à jour des menus Wordpress mais après avoir pris contact avec le support c’est arrangé. Une fois tout ceci fait, le site repart, avec effectivement des performances supérieures à l'ancienne offre