-
-
-
-
-
- Tools
- Dev
- Bash
- Recherche web
-
Cette page rassemble quelques données techniques spécifiques aux serveurs mutualisés de l'hébergeur Inulogic.
Les informations techniques que je partage ici sont peu ou pas documentées, et proviennent de mes différentes communications avec le support client et de ma propre expérience du serveur web mutualisé d'Inulogic. Certaines informations de cette page peuvent contredire le wiki officiel Inulogic dont les pages ne sont pas toujours à jour.
Avant l'hébergeur Inulogic, j'avais précédemment expérimenté la PME ultra low-coast AgsaHosting (alias Agsatech alias Agence Savès Technologies) qui a cessé de fonctionner sans préavis au grand dam de centaines d'usagers). Cette société avait loué des serveurs auprès de différents fournisseurs clouds dans le monde de part et d'autre de l'Atlantique, et donnait ainsi l'impression d'être une société solide alors qu'il s'agissait d'une micro-société à la gestion aventureuse. En janvier 2012, AgsaHosting a cessé son activité sans avertir personne et je ne m'en suis pas aperçu tout de suite. En effet, mon serveur web mutualisé localisé en Hollande a continué de fonctionner en toute autonomie jusqu'au moment où le datacenter hollandais sans nouvelle d'AgsaHosting a du fermer le service en avril 2012.
À contrario d'AgsaHosting et d'autres sociétés low-coast, la société Inulogic possède et gère elle-même ses propres disques durs physiques, possède et gère elle-même son propre réseau dont le numéro de routage BGP est AS198375 (bgp.he.net, robtex.com, radar.qrator.net). Parmi ses différentes offres de service, Inulogic propose des serveurs web mutualisés (suffisants pour la majorité des sites web), des VPS et des serveurs dédiés.
D'après mon expérience, les avantages des serveurs de la société Inulogic sont :
À ma connaissance, très peu d'autres hébergeurs français concurrencent Inulogic en rapport qualité / prix. Selon moi, les associations ou coopératives d'hébergement (Ouvaton, Lautre.net, liste complète ici) offrent des solutions très éthiques (logiciels 100% libres, indépendance, refus de la publicité, etc.) mais pas assez professionnelles : elles reposent en effet sur des bénévoles passionnés qui travaillent avec très peu de moyens pendant leurs temps libres, ce qui est incompatible avec la garantie de continuité de service et de pérennité des données qui est nécessaire à toute activité informatique professionnelle (cf. fermeture inopinée de l'hébergeur Altern en avril 2015).
Quant-aux grandes sociétés concurrentes comme OVH ou Gandi, elles coûtent plus cher et la relation avec les petits clients pâtit forcément des dimensions d'un service de masse : manque de réponse technique précise et personnalisée.
Créée en 2010, Inulogic est une petite société constituée de professionnels compétents et passionnés. Ils ont le contact facile sur tous les sujets techniques dans une démarche personnalisée et s'adaptent aux besoins du client même s'il a souscrit un petit contrat. Au fil des échanges, la communication cordiale aux travers des tickets du support client donne l'impression d'un service de proximité comme si nous étions en discussion en face à face.
L'hébergement et la gestion de plusieurs sites web pour des clients nécessite l'utilisation d'un logiciel interface de gestion de contrôle (Web hosting control panel), écrit en PHP, afin d'automatiser la création, la gestion et la destruction de serveurs web – qui impliquent différentes séries de modifications système des serveurs de l'infrastructure sous GNU/Linux – en un minimum de temps. Ces logiciels sont assez lourds à installer et à post-installer, même quand ils sont légers et open source. Il en existent un certain nombre (liste comparative en anglais). Les plus connus et sans-doute les plus performants sont les logiciels privateurs cPanel et Plesk.
À la date de septembre 2015, Inulogic utilise la version 12.0 du logiciel Plesk pour allouer des ressources et pré-configurer les serveurs mutualisés au niveau des services DNS, Apache, PHP, SQL, FTP et de messagerie électronique.
Le guide du client Plesk 12.0 est accessible en ligne ici.
Les serveurs web d'Inulogic ne répondent pas aux requêtes ICMP de l'utilitaire ping. Comme contournement du blocage des requêtes de niveau 3 (couche réseau du Modèle OSI), on peut utiliser une des commandes suivantes :
nmap -PN -p 80 mon_domaine.tld
tcptraceroute mon_domaine.tld
Note : sous Windows traceroute s'appelle tracert et nmap n'étant pas fourni, il faut préalablement le télécharger et l'installer.
La table d'adressage DNS des sous-domaines est gérée directement par le serveur de noms primaire pour la zone DNS du domaine principal. Il est conseillé d'éviter de changer ce fonctionnement (serveur esclave, etc.).
À la création d'un nouveau sous-domaine (tutoriel), Plesk crée automatiquement un nouvel enregistrement DNS A dans la table du serveur de noms primaire du domaine principal.
Les versions précédentes du panel de gestion Plesk rangeait les sous-domaines dans le dossier /subdomains. Depuis les versions récentes de Plesk, ceci a changé au profit d'une totale liberté de rangement et d'un bug : dans l'espace de stockage le répertoire /subdomains est désormais en lecture seule vis-à-vis de l'administrateur du site.
Cependant, l'idée originelle de regrouper tous les sous-domaines dans un seul répertoire est une bonne pratique.
Aussi, je recommande le regroupement des sous-domaines dans un répertoire /httpsubdomains qui a l'avantage d'être listé juste au dessous du répertoire de base du domaine principal /httpdocs.
Il est possible de déclarer des sous-domaines virtuels dans Plesk par la création d'alias de sous-domaine. Ceci permet à un navigateur d'accéder par exemple au site http://mondomain.tld par une autre adresse http://autredomaine.tld. Pour cela il faut :
Une requête internet sur un sous domaine virtuel renvoie obligatoirement sur le répertoire principal /httpdocs. Il est possible de faire rediriger de façon transparente les requêtes http vers un sous-répertoire /httpdocs/autre-site en ajoutant les directives suivantes dans le fichier .htaccess du répertoire /httpdocs :
<IfModule mod_rewrite.c> RewriteBase / RewriteCond %{HTTP_HOST} ^autredomaine.tld$ RewriteCond %{REQUEST_URI} !/autredomaine\.tld/ RewriteCond %{REQUEST_URI} /(.*)$ RewriteRule ^.*$ autre-site/%1 </IfModule>
Il est théoriquement possible de ranger les fichiers d'un alias de sous-domaine en dehors du répertoire /httpdocs, mais de façon non transparente pour le navigateur et l'internaute. Concrètement, il s'agit de forcer le serveur web à effectuer une redirection externe (plus lente) qui remplace dans le navigateur l'URL http://autredomaine.tld par http://x.domain.tld. Cela revient à "dé-virtualiser" l'alias de sous-domaine.
Pour cela, il faut en plus des configurations précédentes :
RewriteRule ^.*$ http://x.domain.tld/%1
%{HTTPS}
contient toujours "off" tandis que %{HTTP:X-Forwarded-Proto} contient soit du vide, soit "https"%{SERVER_PORT}
contient toujours "80"%{SCRIPT_URI}
est toujours vide%{HTTP_REFERER}
contient soit "http" soit une chaîne vide tandis que la variable d'environnement PHP $_SERVER['HTTP_REFERER']
est correctement renseignée
Dans certains cas très particuliers, un contournement de la lacune Apache %{HTTP_REFERER}
à partir de la deuxième requête pourra répondre au problème : la première requête doit exécuter un code PHP stockant la valeur chaîne de la variable d'environnement $_SERVER['HTTP_REFERER']
dans un cookie temporaire :
<?php // ... $http_referer = (isset($_SERVER['HTTP_REFERER'])) ? $_SERVER['HTTP_REFERER'] : ""; if (! empty($http_referer) ) { setrawcookie( "HTTP_REFERER", $http_referer, time()+3600, "/", $_SERVER['HTTP_HOST'] ); } // ... ?>
Dans le fichier .htaccess, il suffira d'ajouter un test du cookie au format mod_rewrite d'Apache :
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / ## ... ## Tester un cookie RewriteCond %{HTTP_COOKIE} (^|;\s*)nom_cookie=([^;]+) RewriteCond %2 ^valeur_cookie$ RewriteRule ... ## Tester un cookie dont la valeur peut contenir des caractères spéciaux (encodage URL) RewriteCond %{HTTP_COOKIE} (^|;\s*)nom_cookie=([^;]+) RewriteCond %{unescape:%2} ^valeur_cookie$ RewriteRule ... ## ... </IfModule>
La variable %{HTTPS} contient toujours "off". À la place dans le fichier .htaccess, il faut utiliser la variable d'environnement %{HTTP:X-Forwarded-Proto} :
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / ## ... RewriteCond ... RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^.*$ https://%{HTTP_HOST}%{REQUEST_URI}?%{QUERY_STRING} [R,L] ## ... </IfModule>
Note : sous PHP, cette variable s'appelle _SERVER["HTTP_X_FORWARDED_PROTO"]
.
Le 03/09/2015, la version PHP était : 5.3.
Pour connaître la configuration complète de compilation du serveur PHP, il suffit d'exécuter la fonction suivante :
<?php phpinfo(); ?>
$_SERVER['REMOTE_ADDR']
contient l'adresse IP du client sous HTTP, mais elle contient l'adresse IP du serveur sous HTTPS !!$_SERVER['SCRIPT_URI']
est vide
Prérequis :
Par défaut, la zone DNS primaire contient un enregistrement A pour stats.mondomaine.tld vers une adresse IP qui n'est pas forcément la même que celle du serveur web public. Si ce champs DNS n'existe plus ou est erroné, il faut contacter le support Inulogic pour corriger ce problème.
Par défaut, le quota SMTP est fixé à 20 emails par heure. En cas de besoin, le support Inulogic peut l'augmenter.
Les statistiques du serveur web sont accessibles en se connectant à l'aide des identifiants du compte FTP principal à l'URL suivante : http://stats.mondomaine.tld/awstats.pl
Depuis la modernisation de l'infrastructure mutualisée Inulogic, les logs du serveur web ne sont plus accessible via FTP ni dans l'interface de gestion Plesk (icône "Logs"). Le répertoire /logs contient des fichiers par forcément mis à jour, et surtout de longueur nulle !
Pour accéder aux véritables fichiers logs du serveur il faut désormais se connecter à l'aide des identifiants du compte FTP principal à l'URL suivante : http://stats.mondomaine.tld/logs
Cette URL affiche une liste de fichiers logs PHP (access.log, error.log et leurs archives respectives) et FTP (xferlog et ses archives).
http://stats.mondomaine.tld/logs
%{HTTP_REFERER}
contient soit "http" soit une chaîne vide tandis que la variable d'environnement PHP $_SERVER['HTTP_REFERER']
est correctement renseignéePour se connecter et effectuer les tâches d'administration DokuWiki, il est préférable d'utiliser une connexion chiffrée HTTPS.
Ceci modifie parfois les liens hypertextes des pages web DokuWiki mises en cache par le serveur en transformant leur début en https://
. Or le certificat de sécurité des serveurs web Inologic ne dépendent pas d'une autorité de certification dont le certificat racine est nativement validé par les navigateurs clients1). L'internaute non expérimenté risque donc de "tomber" sur une page web HTTPS sans l'avoir sciemment demandé.
Pour éviter ce cas de figure, on veillera à purger le cache systématiquement après déconnexion d'une session DokuWiki par la commande suivante : http://…?do=purge
Les règles Apaches suivantes réalisent toutes ces tâches (adaptez monserveur\.local au nom de domaine de votre propre serveur local de développement) :
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / ## ... ## _____ Début des redirections externes _____ ## Sauter les 4 règles suivantes s'il s'agit du serveur local de développement RewriteCond %{HTTP_HOST} monserveur\.local$ RewriteRule "." - [skip=4] ## Redirriger vers la même page en https si la requête contient ## do=login ou do=resendpwd ou do=admin ou do=profile ou do=media ou do=logout RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteCond %{QUERY_STRING} (^|&)do=(login|resendpwd|admin|profile|logout|media)&?.*$ RewriteRule ^.*$ https://%{HTTP_HOST}%{REQUEST_URI}?%{QUERY_STRING} [R,L] ## Forçage de connexion en http avec purge du cache si déconnexion : ## 1. Si la requête contient do=logout, alors ## inclure un cookie LOGOUT de valeur "done" durant 1 mois ## et sauter les deux règles suivantes RewriteCond %{QUERY_STRING} (^|&)do=logout&?.*$ RewriteRule "." - [CO=LOGOUT:done:%{HTTP_HOST}:2592000,skip=2] ## 2. Si la requête contient un cookie LOGOUT de valeur "done" ## et est en https, alors ## redirriger vers la même page en http ## en ajoutant ?purge=true, ## en supprimant le cookie, ## et sauter la règle suivante RewriteCond %{HTTP:X-Forwarded-Proto} https RewriteCond %{HTTP_COOKIE} ^.*LOGOUT=done.*$ RewriteRule ^.*$ http://%{HTTP_HOST}%{REQUEST_URI}?%{QUERY_STRING}&purge=true [R,L,CO=LOGOUT:INVALID:%{HTTP_HOST}:-1,skip=1] ## 3. Si la requête contient un cookie LOGOUT de valeur "done" ## et est en http, alors ## ajouter ?purge=true ## en supprimant le cookie RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteCond %{HTTP_COOKIE} ^.*LOGOUT=done.*$ RewriteRule ^.*$ http://%{HTTP_HOST}%{REQUEST_URI}?%{QUERY_STRING}&purge=true [R,L,CO=LOGOUT:INVALID:%{HTTP_HOST}:-1] ## ... </IfModule>
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / ## Sauter la règle suivante s'il s'agit du serveur local de développement RewriteCond %{HTTP_HOST} monserveur\.local$ RewriteRule "." - [skip=1] ## Redirriger vers la même page en https si la requête contient ## /ecrire/, page=login ou page=spip_pass RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteCond %{QUERY_STRING} (^|&)page=(login|spip_pass)&?.*$ [OR] RewriteCond %{REQUEST_URI} /ecrire/ RewriteRule ^.*$ https://%{HTTP_HOST}%{REQUEST_URI}?%{QUERY_STRING} [R,L] ## ... </IfModule>
Lorsque mon site était sous SPIP 3.0, les boutons de l'espace privé qui étaient censés déclencher une requête AJAX n'avaient aucune action sous connexion HTTPS.
La cause probable devait être le mécanisme de sécurité renforcée des navigateurs à propos des contenus web partiellement chiffrée.
Pour contourner ce problème, il me suffisait selon les cas, de désactiver javascript (extension Noscript) ou bien de faire un clic droit et d'ouvrir le lien dans un nouvel onglet.