OVH Community, votre nouvel espace communautaire.

Erreur étrange derrière Ip Load Balancing


janus57
21/04/2015, 20h24
Citation Envoyé par buddy
Bonsoir,

le SSL qu'il a pris est associé / un service avec l'ip load balancing .. tu ne peux pas les dissocier. ou alors il faut prendre un certificat SSL ici : https://www.startssl.com/ et pour le tuto : https://lafibre.info/cryptographie/tuto-https/
Bonjour,

hum je vois pas le rapport avec ce que je dit et oui je sais que le SSL OVH est lié a un service OVH (soit IP LB soit mutualisé), et cela n'empêche en rien d'avoir du SSL sur l'IP LB (comme il a actuellement) ET que l'IP LB forward le tout sur le port 443 du serveur, en tout cas l'API me laisse supposé que cela est possible:
Ports éligibles
HTTP : 80
HTTPS : 443
MySQL : 3306
PostGreSQL : 5432
Cf : https://www.ovh.com/fr/solutions/ip-load-balancing/

Après à voir c'est lequel des 2 SSL qui prend le dessus, celui de l'IP LB ou du serveur.

Sinon pour info :
Vous avez la possibilité d’utiliser, en option, un certificat SSL OVH ou même directement le votre si obtenu auprès d’une entité de certification valide.
Cf : https://www.ovh.com/fr/solutions/ip-...e-optimale.xml

Donc on peu se passer du SSL OVH à 60€/ans et se prendre un simple SSL à 10€/an ou un gratuit StartSSL selon sa propre politique SSL.

Après je dirais qu'il manque une doc un peu plus simpliste pour cette fonction car là pour un amateur/néophyte c'est dur.

Cordialement, janus57

buddy
21/04/2015, 19h31
Bonsoir,

le SSL qu'il a pris est associé / un service avec l'ip load balancing .. tu ne peux pas les dissocier. ou alors il faut prendre un certificat SSL ici : https://www.startssl.com/ et pour le tuto : https://lafibre.info/cryptographie/tuto-https/

janus57
21/04/2015, 18h34
Bonjour,

J'avais un bon d'achat chez OVH parce que j'ai souscris à une offre ADSL chez eux, ce qui m'a permis d'avoir le certificat SSL gratuitement, et comme il n'est pas exclu que j'utilise l'IP load balancing je l'ai prise.
bah pour le moment avec 1seule VPS concrètement elle (IP LB) sert strictement à rien à part balancer 9,99€/mois dans le vent (on oublie le SSL vu que tu l'a eu "gratuit" grâce au bon d'achat).

Les liens sont tous écrits en https dans Wordpress, mais rien n'empêche le client de consulter une page en http, c'est ce qui m'ennuie :-\

Enfin je vais regarder quand même si il n'est pas possible de forcer la redirection via Wordpress.
Sinon comme dit plus haut faut faire du HTTPS de bout en bout (client -> IP LB -> VPS) et comme ça le .htaccess avec la redirection ne fera plus de boucle de redirection, après faut surement re-config l'IP LB pour faire ça et le guide de OVH n'évoque pas cette solution et je connais pas d'autre doc sur l'IP LB.

Cordialement, janus57

Nexnivis
21/04/2015, 16h48
J'avais un bon d'achat chez OVH parce que j'ai souscris à une offre ADSL chez eux, ce qui m'a permis d'avoir le certificat SSL gratuitement, et comme il n'est pas exclu que j'utilise l'IP load balancing je l'ai prise.

Les liens sont tous écrits en https dans Wordpress, mais rien n'empêche le client de consulter une page en http, c'est ce qui m'ennuie :-\

Enfin je vais regarder quand même si il n'est pas possible de forcer la redirection via Wordpress.

janus57
21/04/2015, 15h14
Bonjour,

comme ça en vrac et sans test un truc du genre :
Code:
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R,L]
Dans la théorie ce code renvois toute les demandes de example.com sur https://example.com, mais là aussi cela risque de poser problème avec l'ip LB qui communique en HTTP avec le serveur.

Sinon faut forcer les liens en HTTPS au niveau de wordpress ou encore activer SSL sur le serveur et demande à l'IP LB de "parler" sur le port 443 du début à la fin (du visiteur au serveur) en forçant le tout avec un .htaccess.

P.S. ici l'ip LB est inutile dans le sens ou y a un seule serveur et si c'est juste pour avoir du HTTPS, le plus simple ici aurait été de directement activer le SSL au niveau du serveur et de prendre un certificat à part chez une société qui vend ce genre de certificats (https://www.gandi.net/ssl/standard#single | https://www.gogetssl.com/ | https://www.namecheap.com/security/s...tificates.aspx).
De plus directement le SSL sur le serveur c'est moins cher : 10 à 250€ TTC/ans (selon certificat choisit)
IP LB + SSL = 203,9 € TTC/ans

l'IP LB est très bien pour faire ce qu'elle promet, donc de la répartition de charge, si le but était simplement de faire du HTTPS "simplement" c'est clairement raté en plus de l'ajout de coups supplémentaire injustifié dans ce cas précis (1 seule et unique VPS).

Cordialement, janus57

Nexnivis
21/04/2015, 14h04
Oui effectivement il faudrait que je me plonge dans l'optimisation !

Là je rencontre un soucis avec la redirection en https. Vu que l'encryptage se fait au niveau de l'IP load balancing le serveur est toujours sur un port 80, alors quand je crée une règle de redirection ça fait une boucle de redirection.

OVH suggère d'utiliser :
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.domaine.com/$1 [R,L]
Mais comme je l'ai dit toutes les requêtes sont envoyées depuis le port 80, donc ça crée une boucle de redirection.

Les règles qui se basent sur la condition "RewriteCond %{HTTPS} off" créent également des boucles de redirection puisque le serveur est constamment en http.

Une idée sur comment forcer le https ?

Merci

janus57
20/04/2015, 20h39
Citation Envoyé par Nexnivis
Oui tu as visé juste Merci infiniment ! Je ne pensais vraiment pas que le problème pouvait se situer là.
Bonjour,

entre temps j'ai fait un EDIT après une analyse un peu plus poussé.

En gros c'est juste que ton serveur/site est très mal optimisé du coup l'IP LB tombe en timeout et cherche à envoyer le traffic sur un autre backend, mais vu que tu en a qu'un seul bah *pouf* dans le vide.

Un coup d'optimisation du côté wordpress + serveur et ton site sera plus fluide (tu aura pas besoin de toucher la sonde, tu peu la laisser en ICMP), par contre il sera plus fluide pour les visiteurs également, donc il risque d'être très heureux (perso la console de dev de firefox me dit qu'il faut 60 (avec cache) à 480 (sans cache) secondes pour charger l'intégralité des ressources de ton sites avec 1,2 à 2,4 secondes d'attente que le serveur répond).

Cordialement, janus57

Nexnivis
20/04/2015, 20h24
Oui tu as visé juste Merci infiniment ! Je ne pensais vraiment pas que le problème pouvait se situer là.

janus57
20/04/2015, 19h46
Citation Envoyé par Nexnivis
Janus, je t'aime.
Bonjour,

tiens quelque chose me dit que j'ai tapé juste et que tu t'auto-bloqué avec la sonde de l'ip LB.

D'ailleurs pour confirmer ça tu aurait pu prendre un VPS Bêta (gratuit), ajouté son IP au backend et normalement cela aurait envoyé le trafic sur le VPS Bêta.

EDIT :
rectification de mes dires, c'est pas un problème de sonde renvoyé vers le port 443 (ssl).
C'est juste que le serveur est très long à répondre aux requêtes HTTP, par exemple si je demande directement à google (https://developers.google.com/speed/pagespeed/insights/) de taper sur l'ip du serveur 151.80.151.xxx (j'ai volontairement masqué au cas où).
Réduire le temps de réponse du serveur
Lors de notre test, votre serveur a répondu en 1,7 seconde. De nombreux facteurs peuvent augmenter le délai de réponse d'un serveur. Veuillez consulter nos recommandations pour savoir comment contrôler et mesurer les opérations qui prennent le plus de temps.
Hors la sonde HTTP doit avoir un timeout relativement faible du coup (genre 1secondes pour bien déclencher et pas ralentir le visiteur).

Donc si le serveur met entre 1,2 et 2,2 secondes c'est mort.
Va falloir optimiser tout ça avec des plugins de cache sous wordpress et côté serveur êut être se séparer de mod_php qui analyse TOUT (html/css/js/php) pour savoir quelle fichiers PHP il doit traiter (en comparaison PHP-FPM bien config regarde uniquement les fichiers .php ou ceux dont on lui donne l'extension à "manger").

Cordialement, janus57

Nexnivis
20/04/2015, 19h42
Janus, je t'aime.

janus57
20/04/2015, 19h05
Bonjour,

Oui dans l'API lorsque j'ai défini l'IP en backend j'ai bien choisi http
à ta place je basculerais le check en ICMP (si tu l'a pas coupé), comme ça 0 risque que un apache mal config arrive à faire croire à l'ip LB que le serveur est HS.

Car si ton IP de serveur renvois sur du HTTPS pour le monitoring de l'ip LB cela va être du timeout (0 réponse sur le port 80) et donc l'ip LB va router les requêtes dans le vide (tu t'auto blackhole), et idem si un jour pour une raison X ou Y ton VPS est indisponible, tout sera routé dans le vide (comme si le VPS était HS, donc normale dans ce cas).

Après c'est peut être pas du tout ça le problème et je dit de la merde...

D’ailleurs ton IP LB fonctionne : http://blizzheart.com/index.php (37.187.86.36)
0 redirection vers HTTPS, les lien appelé en HTTPS://blizzheart.com fonctionne et on a la page

Cordialement, janus57

Nexnivis
20/04/2015, 17h02
Oui dans l'API lorsque j'ai défini l'IP en backend j'ai bien choisi http
HTTP/1.1 200 OK
Access-control-allow-origin:
*
Cache-control:
no-cache
Content-type:
application/json; charset=utf-8
Date:
Mon, 20 Apr 2015 16:03:31 GMT
X-ovh-queryid:
FR.ws-3.55352353.4842.6789
[
"151.80.151.242"
]
Concernant Wordpress et l'utilisation du port 80 malgré le protocole https il y a déjà plein d'instructions sur le net pour régler ça (même fournies par Wordpress eux même) et j'ai fait tout ce qu'il fallait faire. Je ne vois plus quoi faire d'autre.

En tout cas merci infiniment pour ton aide et ta volonté de trouver une solution, on aura essayé

janus57
20/04/2015, 15h52
Bonjour,

Au final tout ce que je suis sensé faire c'est simplement déclarer l'IP de mon VPS en backend via l'API
sans oublier de config le bon check (port 80, icmp etc.).

Mais d'un point de vue logique je constate simplement que seule l'IP load balancing cause ces erreurs, et tout semble indiquer que l'IP load balancing n'arrive à joindre le serveur qu'au travers du fichier index.html
ou alors que quand elle tape sur le .php cela redirige la sonde de check sur le port 443 qui doit surement ne pas répondre.

Cordialement, janus57

Nexnivis
20/04/2015, 15h31
Oui je lis ce guide en long en large et en travers depuis 3 jours Au final tout ce que je suis sensé faire c'est simplement déclarer l'IP de mon VPS en backend via l'API, et pointer mon domaine en A vers l'IP LB. Le reste concerne la répartition des tâches entre les serveurs, mais je n'ai qu'un serveur ! L'IP LB ne me sert qu'à l'encryptage SSL.

Je ne suis pas sûr à 100% de ma config, il y a une semaine je ne savais même pas ce qu'était le SSH et je n'avais jamais touché à Putty, j'ai tout appris en quelques jours en suivant des tuto à droite et à gauche. Mais d'un point de vue logique je constate simplement que seule l'IP load balancing cause ces erreurs, et tout semble indiquer que l'IP load balancing n'arrive à joindre le serveur qu'au travers du fichier index.html

Le technicien ne fait que me répéter que ça semble être un problème de configuration, mais en même temps il ne semble toujours pas avoir compris que le site fonctionne si je ne passe pas par l'IP LB du coup ça ne m'encourage pas vraiment à tenter le coût d'un ticket d'incident...

Dans mon dernier mail j'ai bien réexpliqué le problème de la manière la plus précise et concise possible, je vais attendre sa réponse pour prendre une décision.

janus57
20/04/2015, 15h07
Bonjour,

et au niveau du manager/API l'ip LB est bien config ?

EDIT :
petit guide : http://guide.ovh.com/IpLoadbalancing

EDIT 2 :
Sinon tu ouvre un ticket incident si tu es sûr à 100% de ta config et prépare 20€ (24€ TTC) au cas où.

Cordialement, janus57

Nexnivis
20/04/2015, 14h56
Lorsque j'enlève le .html le serveur n'enregistre aucun log. Comme si l'IP Load Balancing n'arrivait plus à atteindre le VPS lorsqu'il n'y avait pas de .html

De toutes façons c'est ce qui ressort selon moi. Toutes les URLs passent en time out même celles qui n'ont strictement rien à voir avec Wordpress, vraisemblablement à partir du moment où il n'y a pas d'index.html l'IP Load Balancing perd totalement la connexion avec le VPS.

De même lorsque j'enlève le .html la console du navigateur ne renvoie strictement rien (aussi bien celle de Chrome que celle de Firefox), c'est tout blanc, pas une seule ligne.

Vraiment, sans index.html l'IP load balancing est incapable de contacter le VPS.

janus57
20/04/2015, 14h46
Bonjour,

donc enlève le .html et fait des tests et surtout regarde absolument tout les logs apache : /var/log/apache2/ <== tous les logs, du access au other_vhost
Et en plus regarde avec la console de dev de ton navigateur ce que font les requêtes HTTP.

Perso je suis prêt a regarder les requêtes HTTP pour voir si y a une anomalie.

Cordialement, janus57

Nexnivis
20/04/2015, 14h40
Oui j'ai essayé le DirectoryIndex hier. Je me suis dit que si le serveur ne fonctionne correctement que lorsqu'il y a le fichier Index.html alors je vais le laisser et simplement le contourner. Mais faire passer le .php en priorité a eu exactement le même effet que de simplement supprimer l'index.html

À l'heure actuelle si je supprime le fichier index.html le domaine fonctionne à peu près 30 sec puis toutes les url en blizzheart.com renvoient un time out. En revanche je peux continuer à consulter mon VPS en passant par l'adresse http://vpsXXXXX.ovh.net, c'est bien la preuve que le serveur fonctionne très bien, avec ou sans index.html, c'est juste le domaine qui foire et uniquement lorsqu'il pointe sur l'IP load balancing qui plus est.

janus57
20/04/2015, 14h31
Bonjour,

Il m'a dit que si j'étais sûr que le problème venait de l'IP load balancing je pouvais ouvrir un ticket d'incident, mais ça me coûterai 20€ si jamais le problème vient de ma configuration.
oui c'est ça chez OVH, si tu as raison c'est gratuit, sinon c'est 20€ HT pour toi car problème de ton côté.

L'index.php de wordpress a toujours redirigé vers le / du domaine sur lequel est paramétré la page d'accueil de Wordpress.
Effectivement après test c'est bien son comportement (perso j'utilise pas souvent wordpress).

Sinon en virant le .html temporairement là qu'est-ce que sa donne au niveau des requêtes HTTP (vu que le .htaccess empêche une bonne visibilité) ?

EDIT :
Code:
Je ne comprends pas. C'est exactement ce qui se passe sur mon serveur, en ce moment j'ai un index.html et c'est ce dernier qui est affiché lorsque l'on va sur https://blizzheart.com
Perso c'est une config voulu, moi je VEUX que le .html prenne le dessus sur le .php
Si je voudrais l'inverse j'aurais juste à changer la directive "DirectoryIndex" par
Code:
DirectoryIndex index.php index.html index.htm
Et hop index.php prend le dessus sur index.html (je viens de le mettre en place juste pour le fun).

Cordialement, janus57

Nexnivis
20/04/2015, 14h29
Citation Envoyé par janus57
En tout cas de mon côté que ce soit sur mutualisé ou VPS monté main ou avec un panel (ISPConfig) apache a toujoursréagit de cette façons, je ne s ais pas si c'est "mal" ou "bien" mais cela me permet de coller un index.html en attendant un upload complet des fichiers derrière vu que par défaut dans mon cas si on appel http://janus57-beta.ga ce sera forcément la page HTML que apache retournera à cause de la config du VHost.
Je ne comprends pas. C'est exactement ce qui se passe sur mon serveur, en ce moment j'ai un index.html et c'est ce dernier qui est affiché lorsque l'on va sur https://blizzheart.com

Par défaut wordpress redirige index.php vers la base du domaine, c'est comme ça qu'il fonctionne. D'ailleurs si je remplace le index.php de wordpress par un index.php que je crée moi-même avec une phrase simple dedans, ça fonctionne, je peux accéder à blizzheart.com/index.php et voir la phrase en question sans être redirigé.

Nexnivis
20/04/2015, 14h15
Bon j'ai eu une nouvelle réponse du support technique, le technicien m'indique la marche à suivre pour passer outre l'IP load balancing et ainsi pouvoir observer si le site fonctionne en accès direct. Dans nos échanges j'ai dû lui préciser au moins 2 ou 3 fois que j'ai déjà essayé de pointer directement sur l'IP de mon VPS sans passer par l'IP load balancing et que ça marche parfaitement, j'ai l'impression qu'il lit à la verticale...

Il m'a dit que si j'étais sûr que le problème venait de l'IP load balancing je pouvais ouvrir un ticket d'incident, mais ça me coûterai 20€ si jamais le problème vient de ma configuration.

EDIT : merci pour les éclaircissements supplémentaire janus, mais je n'ai aucun problème non plus avec les index tant que je n'utilise pas cette IP load balancing. La redirection n'est pas plutôt utilisée par Wordpress tout simplement ? L'index.php de wordpress a toujours redirigé vers le / du domaine sur lequel est paramétré la page d'accueil de Wordpress.

janus57
20/04/2015, 14h12
Bonjour,

Perso moi j'ai une redirection de type HTTP 301 (donc permanente) sur le fichier index.php, et comme l'ip LB fait uniquement une simple redirection IP LB -> IP VPS, pour moi c'est une mauvaise config VPS.

Perso les install Apache à la main je met pas de suexec, du coup j'ai tout /var/www qui appartient à www-data:www-data et je combine le tout avec du Apache en mode worker + PHP-FPM et pas de problème de redirection (bon par contre il est vrai que j'utilise pas d'ip LB).

Exemple : http://www.janus57-beta.ga/
Code:
root@janus57-beta:~# ll /var/www/
total 28K
-rw-r--r--  1 www-data www-data  178 avril 14 21:21 index.html
drwxr-xr-x  3 www-data www-data 4,0K avril 19 15:08 janus57-beta
drwxr-xr-x 33 www-data www-data 4,0K avril 16 19:28 phpboost3
drwxr-xr-x 40 www-data www-data 4,0K avril 14 20:26 phpboost4_0
drwxr-xr-x 42 www-data www-data 4,0K avril 14 20:34 phpboost4_1
root@janus57-beta:~# cat /etc/apache2/sites-enabled/janus57-beta.ga.vhost

        ServerAdmin webmaster@janus57-beta.ga
        ServerName janus57-beta.ga
        ServerAlias www.janus57-beta.ga

        DocumentRoot /var/www/janus57-beta
        DirectoryIndex index.html index.htm index.php

        
                Options -Indexes
                AllowOverride None
        

        ErrorLog ${APACHE_LOG_DIR}/janus57-beta/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/janus57-beta/access.log combined

root@janus57-beta:~# cat /etc/apache2/sites-enabled/phpboost3.janus57-beta.ga.vhost

        ServerAdmin webmaster@janus57-beta.ga
        ServerName phpboost3.janus57-beta.ga

        DocumentRoot /var/www/phpboost3
        DirectoryIndex index.html index.htm index.php

        
                Options -Indexes
                AllowOverride ALL
                #TOR
                Order allow,deny
                Include tor-ip.conf
                Allow from all
        

        ErrorLog ${APACHE_LOG_DIR}/phpboost3/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel notice

        CustomLog ${APACHE_LOG_DIR}/phpboost3/access.log combined

root@janus57-beta:~# apache2ctl -M && apache2ctl -S && apache2ctl -V
Loaded Modules:
 core_module (static)
 log_config_module (static)
 logio_module (static)
 version_module (static)
 mpm_worker_module (static)
 http_module (static)
 so_module (static)
 actions_module (shared)
 alias_module (shared)
 auth_basic_module (shared)
 authn_file_module (shared)
 authz_default_module (shared)
 authz_groupfile_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 cgi_module (shared)
 cgid_module (shared)
 deflate_module (shared)
 dir_module (shared)
 env_module (shared)
 expires_module (shared)
 fastcgi_module (shared)
 headers_module (shared)
 mime_module (shared)
 negotiation_module (shared)
 reqtimeout_module (shared)
 rewrite_module (shared)
 setenvif_module (shared)
 ssl_module (shared)
 status_module (shared)
Syntax OK
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
_default_:443          janus57-beta.ga (/etc/apache2/sites-enabled/default-ssl:2)
*:80                   is a NameVirtualHost
         default server 176.31.161.206 (/etc/apache2/sites-enabled/000-default:1)
         port 80 namevhost 176.31.161.206 (/etc/apache2/sites-enabled/000-default:1)
         port 80 namevhost janus57-beta.ga (/etc/apache2/sites-enabled/janus57-beta.ga.vhost:1)
         port 80 namevhost phpboost3.janus57-beta.ga (/etc/apache2/sites-enabled/phpboost3.janus57-beta.ga.vhost:1)
         port 80 namevhost phpboost4_0.janus57-beta.ga (/etc/apache2/sites-enabled/phpboost4_0.janus57-beta.ga.vhost:1)
         port 80 namevhost phpboost4_1.janus57-beta.ga (/etc/apache2/sites-enabled/phpboost4_1.janus57-beta.ga.vhost:1)
Syntax OK
Server version: Apache/2.2.22 (Debian)
Server built:   Dec 23 2014 22:48:32
Server's Module Magic Number: 20051115:30
Server loaded:  APR 1.4.6, APR-Util 1.4.1
Compiled using: APR 1.4.6, APR-Util 1.4.1
Architecture:   64-bit
Server MPM:     Worker
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/worker"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=128
 -D HTTPD_ROOT="/etc/apache2"
 -D SUEXEC_BIN="/usr/lib/apache2/suexec"
 -D DEFAULT_PIDLOG="/var/run/apache2.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="mime.types"
 -D SERVER_CONFIG_FILE="apache2.conf"
Voilà a peu prêt ce que cela donne (jamais eu de problème jusqu'à maintenant avec ce genre de config.

Je n'est jamais eu de problème avec les index.html/.php
Pour preuve je viens de m'amuser à mettre un index.php (http://janus57-beta.ga/index.php)

Donc après à voir avec le support si la redirection de type 301 viens de chez eux ou du VPS, mais perso je dirais que cela viens du VPS.

EDIT :
00:34:27.618 3.755 404 369 GET 301 Redirect to: https://blizzheart.com/ https://blizzheart.com/index.php
00:34:31.437 * 395 315/315 GET 200 text/html https://blizzheart.com/
REQUEST :
(Status-Line) HTTP/1.1 301 Moved Permanently
Date Mon, 20 Apr 2015 13:14:25 GMT
Server Apache/2.2.22 (Debian)
X-Powered-By PHP/5.4.39-0+deb7u2
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma no-cache
X-Pingback https://blizzheart.com/xmlrpc.php
Location https://blizzheart.com/
Vary Accept-Encoding
Content-Encoding gzip
Content-Length 20
Keep-Alive timeout=5, max=100
Connection Keep-Alive
Content-Type text/html; charset=UTF-8

RESPONSE :
(Status-Line) HTTP/1.1 301 Moved Permanently
Date Mon, 20 Apr 2015 13:14:25 GMT
Server Apache/2.2.22 (Debian)
X-Powered-By PHP/5.4.39-0+deb7u2
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma no-cache
X-Pingback https://blizzheart.com/xmlrpc.php
Location https://blizzheart.com/
Vary Accept-Encoding
Content-Encoding gzip
Content-Length 20
Keep-Alive timeout=5, max=100
Connection Keep-Alive
Content-Type text/html; charset=UTF-8

root@janus57-beta:~# wget -O /dev/null https://blizzheart.com/index.php
--2015-04-20 14:46:09-- https://blizzheart.com/index.php
Résolution de blizzheart.com (blizzheart.com)... 37.187.86.36
Connexion vers blizzheart.com (blizzheart.com)|37.187.86.36|:443...connecté.
requête HTTP transmise, en attente de la réponse...301 Moved Permanently
Emplacement: https://blizzheart.com/ [suivant]
--2015-04-20 14:46:11-- https://blizzheart.com/
Réutilisation de la connexion existante vers blizzheart.com:443.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 588 [text/html]
Sauvegarde en : «/dev/null»

100%[================================================== ================================================== ================================================== =============================================>] 588 --.-K/s ds 0s

2015-04-20 14:46:12 (21,0 MB/s) - «/dev/null» sauvegardé [588/588]
Pour moi le VPS boucle sur https://blizzheart.com/

Car là si la config était bonne à 100% normalement le VPS devrait retourner soit le contenu du index.html soit le contenu du index.php selon la page qui est appelé (comme : http://janus57-beta.ga/index.html vs http://janus57-beta.ga/index.php).
En tout cas de mon côté que ce soit sur mutualisé ou VPS monté main ou avec un panel (ISPConfig) apache a toujoursréagit de cette façons, je ne s ais pas si c'est "mal" ou "bien" mais cela me permet de coller un index.html en attendant un upload complet des fichiers derrière vu que par défaut dans mon cas si on appel http://janus57-beta.ga ce sera forcément la page HTML que apache retournera à cause de la config du VHost.

Cordialement, janus57

Nexnivis
20/04/2015, 13h51
Non ce n'est pas un clé en main, c'est un VPS normal sur lequel j'ai dû installer Apache et le configurer moi même.

La commande "chown -v www-data:xxx /var/www/index.html" n'a rien changé au problème malheureusement, tout comme le VHost que tu suggères. En ce qui concerne le htaccess j'utilise déjà celui par défaut de Wordpress, celui que tu as trouvé est différent parce qu'il concerne les installation multisites qui fonctionnent en sous-dossiers, la mienne est en sous-domaines.

Concernant le règle de réécriture pour le https j'utilise la mienne parce qu'elle ne redirige que le domaine principal, pas les sous-domaines. Et par ailleurs elle fonctionnait très bien depuis un an sur mon ancien serveur !

Merci en tout cas de m'aider à trouver une solution, même si je n'arrive toujours pas à mettre le doigt sur ce qui ne va pas Est-il véritablement exclu qu'OVH ait fait une erreur de configuration sur l'IP Load Balancing ? Parce qu'à mon niveau je ne vois vraiment pas ce qui cloche.

janus57
20/04/2015, 13h37
Bonjour,

le VPS c'est une install clé en main OVH c'est ça ?

Après un
Code:
chown -v www-data:xxx /var/www/index.html
(remplacer xxx par ce qui a été masqué) la page d'accueil HTML continue de fonctionner ?

Perso en config VHost je verrais bien ceci :
Code:

ServerAdmin kearsan@blizzheart.com
ServerName blizzheart.com
# pas de sous domaine, donc on prend que les requêtes de (www.)blizzheart.com
ServerAlias www.blizzheart.com

DocumentRoot /var/www
#Apache cherche d'abord index.html puis .htm et enfin .php rien d'autre comme fichier d’Indexe.
DirectoryIndex index.html index.htm index.php

#-Indexes empêche le listing de répertoire

Options -Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all


# si besoin d'utiliser des script CGI on décommente le code, en attendant pas besoin et cela fait un vecteur d'attaque en moins
#ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
#
#AllowOverride None
#Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
#Order allow,deny
#Allow from all
#

ErrorLog ${APACHE_LOG_DIR}/blizzheart.com_error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog ${APACHE_LOG_DIR}/blizzheart.com_access.log combined
Voilà un VHost un peu "nettoyé" (de mon point de vue).

Ensuite pour écarter définitivement le .htaccess je remettrai celui par défaut de wordpress que voici (d'après leur doc) :
Code:
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
Si cela fonctionne (avec VHost modifié + restart apache + htaccess de base), je modifie le .htaccess pour forcer le SSL en ajoutant :
Code:
RewriteCond %{HTTPS} !=on
# This checks to make sure the connection is not already HTTPS

RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
# This rule will redirect users from their original location, to the same location but using HTTPS.
# i.e.  http://www.example.com/foo/ to https://www.example.com/foo/
# The leading slash is made optional so that this will work either in httpd.conf
# or .htaccess context

#NOTE : on peu très bien utiliser : RewriteRule ^/?(.*) https://www.example.org/$1 [R,L]
# à la place de la variable %{SERVER_NAME}
Cf : https://wiki.apache.org/httpd/RewriteHTTPToHTTPS

Cordialement, janus57

Nexnivis
20/04/2015, 13h03
Merci pour les réponses janus,

Voici ce que donne le ls -alh /var/www (j'ai volontairement remplacé les logins par xxx) :
drwxrwxr-x 6 www-data xxx 4,0K avril 20 10:43 .
drwxr-xr-x 12 root xxx 4,0K avril 18 11:12 ..
-rw-rw-r-- 1 www-data xxx 268 avril 18 11:42 8OddYP-O6309iv6tRwdcl2sTVUM.html
-rw-rw-r-- 1 www-data xxx 53 avril 18 11:42 google885a1b1fc3c8df84.html
-rw-r--r-- 1 www-data xxx 1,2K avril 20 12:19 .htaccess
drwxrwxr-x 3 www-data xxx 4,0K avril 18 11:42 images
-rw-r--r-- 1 root xxx 588 avril 20 10:43 index.html
-rw-rw-r-- 1 www-data xxx 418 avril 18 20:47 index.php
-rw-rw-r-- 1 www-data xxx 20K avril 18 11:42 license.txt
-rw-rw-r-- 1 www-data xxx 1,1K avril 18 11:42 media.php
-rw-rw-r-- 1 www-data xxx 8,6K avril 18 11:42 readme.html
-rw-rw-r-- 1 www-data xxx 51 avril 18 11:42 robots.txt
-rw-rw-r-- 1 www-data xxx 736 avril 18 11:42 script.php
-rw-rw-r-- 1 www-data xxx 4,9K avril 18 20:47 wp-activate.php
drwxrwxr-x 11 www-data xxx 4,0K avril 18 11:44 wp-admin
-rw-rw-r-- 1 www-data xxx 271 avril 18 20:47 wp-blog-header.php
-rw-rw-r-- 1 www-data xxx 4,9K avril 18 20:47 wp-comments-post.php
-rw-rw-r-- 1 www-data xxx 4,9K avril 19 13:51 wp-config.php
-rw-rw-r-- 1 www-data xxx 3,4K avril 18 20:47 wp-config-sample.php
drwxrwxrwx 14 www-data xxx 4,0K avril 18 20:46 wp-content
-rw-rw-r-- 1 www-data xxx 2,9K avril 18 20:47 wp-cron.php
drwxrwxr-x 12 www-data xxx 4,0K avril 18 19:33 wp-includes
-rw-rw-r-- 1 www-data xxx 2,4K avril 18 20:47 wp-links-opml.php
-rw-rw-r-- 1 www-data xxx 2,7K avril 18 20:47 wp-load.php
-rw-rw-r-- 1 www-data xxx 33K avril 18 20:47 wp-login.php
-rw-rw-r-- 1 www-data xxx 8,1K avril 18 20:47 wp-mail.php
-rw-rw-r-- 1 www-data xxx 11K avril 18 20:47 wp-settings.php
-rw-rw-r-- 1 www-data xxx 25K avril 18 20:47 wp-signup.php
-rw-rw-r-- 1 www-data xxx 4,0K avril 18 20:47 wp-trackback.php
-rw-rw-r-- 1 www-data xxx 3,0K avril 18 20:47 xmlrpc.php
Et un apache2ctl -M && apache2ctl -S && apache2ctl -V :
Loaded Modules:
core_module (static)
log_config_module (static)
logio_module (static)
version_module (static)
mpm_prefork_module (static)
http_module (static)
so_module (static)
actions_module (shared)
alias_module (shared)
auth_basic_module (shared)
authn_file_module (shared)
authz_default_module (shared)
authz_groupfile_module (shared)
authz_host_module (shared)
authz_user_module (shared)
autoindex_module (shared)
cgi_module (shared)
deflate_module (shared)
dir_module (shared)
env_module (shared)
expires_module (shared)
headers_module (shared)
include_module (shared)
mime_module (shared)
negotiation_module (shared)
php5_module (shared)
reqtimeout_module (shared)
rewrite_module (shared)
setenvif_module (shared)
status_module (shared)
suexec_module (shared)
Syntax OK
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:80 is a NameVirtualHost
default server vps158945.ovh.net (/etc/apache2/sites-enabled/000-defaul t:1)
port 80 namevhost vps158945.ovh.net (/etc/apache2/sites-enabled/000-def ault:1)
port 80 namevhost blizzheart.com (/etc/apache2/sites-enabled/blizzheart :1)
Syntax OK
Server version: Apache/2.2.22 (Debian)
Server built: Dec 23 2014 22:48:29
Server's Module Magic Number: 20051115:30
Server loaded: APR 1.4.6, APR-Util 1.4.1
Compiled using: APR 1.4.6, APR-Util 1.4.1
Architecture: 64-bit
Server MPM: Prefork
threaded: no
forked: yes (variable process count)
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT="/etc/apache2"
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="/var/run/apache2/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="mime.types"
-D SERVER_CONFIG_FILE="apache2.conf"
Enfin voici le contenu de mon htaccess :
## WORDPRESS ##
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
## WORDPRESS ##

## FORCE HTTPS ##
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_HOST} ^(?:www\.)(blizzheart\.com)$ [NC]
RewriteRule ^ https://www.%1%{REQUEST_URI} [R=301,L]
## FORCE HTTPS##

## EXPIRES CACHING ##

ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 2 days"

## EXPIRES CACHING ##
A noter concernant le htaccess que le dysfonctionnement se présente également si je vide complètement le fichier.

janus57
20/04/2015, 12h49
Bonjour,

déjà petite chose :
Code:
ServerAlias *.blizzheart.com
si tu couple ça a un wildcard DNS tu va te choper plein de requêtes de robots qui vont tester des sous-domaine, donc pas forcément une bonne idée, je te conseil de config ton VHost pour seulement répondre à ce que tu as configuré et surtout pas lui dire de répondre à TOUTES les demanades même si il demande choseinconnu.blizzheart.com

De mon côté là à l'heure ou j'écrit ces ligne je vois une redirection de https://blizzheart.com/index.php sur https://blizzheart.com avec du HTTP 302.

Que donne un
Code:
ls -alh /var/www
Que donne également un
Code:
apache2ctl -M && apache2ctl -S && apache2ctl -V
Que contient le .htaccess au passage ?

Cordialement, janus57

Nexnivis
20/04/2015, 11h46
Bonjour janus,

Mon log d'erreurs enregistre bien des entrées. Tant que je laisse le fichier index.html sur le serveur tout fonctionne et le log d'erreurs enregistre les éventuelles erreurs. C'est lorsque je retire le fichier index.html que tout semble "figé". Je ne peux accéder à AUCUNE url du VPS, que ce soit celles de mon CMS (Wordpress), que ce soit un lien direct vers une image ou mon phpmyadmin. En gros pour résumer : la simple absence d'un fichier index.html empêche le VPS de fonctionner.

Oui j'utilise apache 2, j'avais oublié de le préciser, sous Debian 7 sur un VPS Cloud 2. Voici mon VHost :


ServerAdmin kearsan@blizzheart.com
ServerName blizzheart.com
ServerAlias *.blizzheart.com

DocumentRoot /var/www

Options FollowSymLinks
AllowOverride All


Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all


ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all


ErrorLog ${APACHE_LOG_DIR}/error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog ${APACHE_LOG_DIR}/access.log combined

janus57
20/04/2015, 11h28
Bonjour,

Donc j'imagine que si mon VPS avait un soucis de configuration je rencontrerai le même problème sans passer par l'IP load balancing ?
Pas forcément, cela dépend de la configuration faite derrière.

Montre la config VHost de ton apache (je suppose que tu utilise apache).

Pendant la mise sous l'ip LB rien de remonté dans les erreur/accès à apache (je suppose que tu utilise apache) ?

Si rien dans les erreurs mais on vois bien les accès sa sent la mauvaise config.
Tu as quoi comme VPS et quoi comme config (OS & soft) ?

Cordialement, janus57

Nexnivis
20/04/2015, 11h10
Je viens d'avoir une réponse du service client OVH, le technicien m'indique que l'IP load balancing n'est qu'un pointage vers l'IP du VPS et qu'il n'y a par conséquent aucune raison qu'elle crée des problèmes. Il m'encourage donc à revoir ma configuration et à consulter mon log d'erreurs.

Je suis d'accord, l'IP load balancing n'est qu'un pointage, mais le fait est que tout fonctionne très bien quand je pointe directement le domaine vers l'IP de mon VPS sans passer par l'IP load balacing. Donc j'imagine que si mon VPS avait un soucis de configuration je rencontrerai le même problème sans passer par l'IP load balancing ?

De plus j'ai recréé le problème et laissé tel quel pendant 5 mn, aucune erreur n'a été enregistrée dans les logs pendant ces 5 mn.

J'attends une nouvelle réponse du technicien, en attendant si vous avez des pistes pour résoudre le problème je suis preneur Merci à tous !

Nexnivis
19/04/2015, 17h55
Bonjour à tous,

J'ai migré mon site récemment sur un VPS OVH, tout fonctionne parfaitement lorsque je pointe le A du nom de domaine vers l'IP de mon VPS.

Seulement voilà, pour un certain nombre de raisons j'ai opté pour une IP Load Balancing (notamment parce que le certificat SSL OVH opère au niveau de l'IP Load Balancing et pas directement sur le VPS), je pointe donc mon domaine vers l'IP Load Balancing et c'est là que ça foire.

Je vous explique :
Mon site est sous Wordpress, l'index est donc index.php, actuellement à la racine de mon nom de domaine j'ai un index.html qui était présent le temps que je migre le site (un index avec juste une phrase dedans du style "on arrive bientôt").

Tant que le fichier index.html est présent TOUT FONCTIONNE. Je peux me rendre à n'importe quelle url de mon site, accéder à mon phpmyadmin, etc... Sauf que bien entendu, dès que les gens veulent revenir à la page d'accueil ça affiche le index.html au lieu de l'accueil du site.

Lorsque je supprime le fichier index.html de mon serveur, le serveur perd les pédales. Plus aucune url ne devient disponible, pas même mon phpmyadmin (qui n'a donc rien à voir avec Wordpress).

Donc pour résumer, lorsque mon domaine pointe sur mon IP load balancing :
- ça ne fonctionne qu'en présence d'un fichier index.html à la racine, mais évidemment ça me prive de l'accueil de mon site
- ça cesse de fonctionner à tous les niveaux dès que je retire le fichier index.html (l'erreur en question est un time out)

Lorsque mon domaine pointe sur l'IP de mon VPS tout fonctionne parfaitement bien, donc il semblerait que ce problème soit causé par l'IP load balancing.

J'ai tenté différentes choses comme rediriger via htaccess index.html vers index.php ou encore de modifier l'ordre de priorité (faire passer index.php avant index.html) mais ces "systèmes D" ont pour conséquences de rendre tout le serveur indisponible, exactement comme si j'avais supprimé le index.html !

J'ai beau retourner le problème dans tous les sens je ne comprends pas, je ne sais pas quoi faire, en plus l'IP load balancing est quelque chose d'externe à mon serveur alors je ne peux rien faire dessus. Je ne comprends pas pourquoi l'absence d'un index.html ou même le simple fait de contourner le fichier index.html fasse dérailler l'IP load balancing.

Des idées ? Merci par avance pour vos réponses !

Nex