Retours sur Cloud Web

Bonjour @janus57,

Merci pour ces feedbacks.

Quelques réponses point par point :

* On a bien pris note pour le délai de livraison. On va voir comment on peut accélérer cela.
* Le changement de version de PHP n'est pas encore disponible. On devrait le rendre disponible durant la béta. On va vérifier les informations pour que l'espace client soit à jour.
* Sur le SSH, ce n'est pas normal le fingerprint. Tu peux nous donner des détails s'il te plait ?
* Pour les modules en 1 clic, ce n'est pas spécifique à Cloud web. Nous avons fait le choix de ne pas les remonter lorsque la base de données est créé par le système. Le module en 1 clic avec création de base de donnée automatique est conçue pour enlever toute la technicité pour les clients n'ayant pas connaissance du fonctionnement des wordpress / prestashop ... Lorsque l'on ajoute cette information, nous avons plus de questions concernant ces identifants. Tu peux bien sur les retrouver dans le code de ton module.
* Oui, nous allons varier les plaisirs en terme de bases de données :)
* La base de donnée est bien locale. Mais elle bénéficie quand même d'un nom de domaine permettant son administration depuis le phpmyadmin.

Bonne journée et merci pour ces feedbacks.
Vincent

Sur le SSH, ce n'est pas normal le fingerprint.

C'est quoi le fingerprint?

https://fr.wikipedia.org/wiki/Empreinte_de_cl%C3%A9_publique

Bonjour,

On a bien pris note pour le délai de livraison. On va voir comment on peut accélérer cela.

Par contre c'est pas le temps de livraison pour que cela apparait dans le manager, mais bien le temps que le VPS comprenne que le NDD qui pointe vers lui à bien un VHost sur le VPS pour l'accueillir plutôt que d'envoyer un 404 à la tête du visiteur. Car vu le comportement j'avais l'impression que le VHost était configuré pour le NDD, mais que le ‎DocumentRoot pointé au mauvais endroit vu qu'il ne trouvé pas le dossier/fichié.

Sur le SSH, ce n'est pas normal le fingerprint. Tu peux nous donner des détails s'il te plait ?

j'ai pas vraiment de détails mise à part qu'a un moment FileZilla et KiTTY (fork de putty) m'ont indiqué une potentiel brèche de sécurité car le fingerprint avait changé et sur les 2 logiciels au même moment alors que j'explorer le manager OVH

La base de donnée est bien locale. Mais elle bénéficie quand même d'un nom de domaine permettant son administration depuis le phpmyadmin.

bah il y a clairement un problème alors, vu que l'adresse localhost ne fonctionne pas du tout (erreur de connexion) et que si je ping l'adresse de la BDD depuis le SSH sa tombe sur une IP en 10.24.144.38.

Note : le ping sur l'adresse est visiblement plus constant qu'en local d'ailleurs ce qui est très bizarre.
[code]
iczxxxx@bf06859bxxxx:~$ ping -c4 iczxxxxxxxx.mysql.db
PING iczkjhd699.mysql.db.gra.hosting.ovh.net (10.24.144.38): 56 data bytes
64 bytes from 10.24.144.38: icmp_seq=0 ttl=64 time=0.079 ms
64 bytes from 10.24.144.38: icmp_seq=1 ttl=64 time=0.121 ms
64 bytes from 10.24.144.38: icmp_seq=2 ttl=64 time=0.161 ms
64 bytes from 10.24.144.38: icmp_seq=3 ttl=64 time=0.189 ms
--- iczkjhd699.mysql.db.gra.hosting.ovh.net ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.079/0.138/0.189/0.042 ms

iczxxxx@bf06859bxxxx:~$ ping -c4 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.153 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.120 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.108 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.071 ms
--- 127.0.0.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.071/0.113/0.153/0.029 ms
[/code]
[code]
iczkjhd@bf06859b3380:~$ mysql -u iczxxxxxxx -p
Enter password:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
iczkjhd@bf06859b3380:~$ mysql -h iczxxxxxxxx.mysql.db -u iczxxxxxxx -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 47
Server version: 5.6.36-log MySQL Community Server (GPL)

Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> exit
Bye
[/code]

Cordialement, janus57

Oui, nous fournissons une IP qui est celle du VPS lui même. C'est voulu pour permettre, plus tard, la migration de base de donnée locale à distante si des gens en ont besoin.

En réalité, comme il s'agit de l'IP de ton propre VPS, le paquet ne va pas plus loin que le noyau linux :)

Bonjour,

du coup pourquoi refuser d'utiliser localhost et/ou la connexion en local échoue ?
Car c'est un comble d'avoir un serveur mysql en local mais de passer par la pile TCP/IP plutôt que les sockets (de mémoire PHP fait une connexion socket plutôt que TCP/IP quand on tape sur du localhost, et oui c'est de la micro-optimisation, mais vu le public visé par ces offres c'est dommage).

Note : 0.2ms pour du local, sa fait un poil beaucoup je trouve$

Cordialement, janus57

Les stacks PHP et Mysql sont dans des containers séparés, ce qui nous permettra à terme de changer de technologie trés facilement (MariaDB ou Node par exemple). On ne pourra donc pas faire de localhost.

Par contre, on peut travailler sur les temps réseau pour améliorer tout cela. On regarde ce que l'on peut faire.

Cordialement,
Vincent

Bonjour,

Merci pour les explications du pourquoi du comment.

Sinon autre problème : l'heure du VPS, car je pense qu'il y a un décalage :
[code]
iczxxxx@b6f8a7e6xxxx:~$ date
Sat Oct 14 10:00:24 UTC 2017
[/code]
[quote]
Hello World
We are the 14/10/2017 at 12:00:58

Europe/Paris
[/quote]
[code]
Hello World


We are the
date_default_timezone_set('Europe/Paris');
echo date('d/m/Y').' at '.date('H:i:s');
?>



echo date_default_timezone_get();
?>
[/code]

Il est 12H42 au moment ou je poste.

Cordialement, janus57

Bonjour,

autre petit retour, la suppression du module en 1clic est en erreur de mon côté alors que niveau fichiers il a bien été supprimé, idem pour la BDD (sauf si c'est moi qui l'avais supprimé manuellement, mais je sais plus…).

Aussi il manque unzip, mais il me semble que cela avait déjà été dit (une date de quand il sera en place ?).

**EDIT :**
Aussi y a t'il une date de prévu pour la modification de PHP (au moins la version et quelques paramètres du php.ini comme l'affichage des erreurs ?)

Cordialement, janus57

Bonjour,

petit up pour avoir un retour sur les problèmes remontés au niveau du décalage de l'heure (car ça c'est réellement problématique) + info sur les versions de PHP.

Cordialement, janus57

Bonjour,

nouveau problème : suppression d'un multisite en erreur.

Cordialement, janus57

PHP et Mysql sont dans des containers séparés

et en créant un volume partagé pour la socket mysql, ça doit pouvoir le faire non ?
A+