Inulogic (free-h.org)

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.

• Site officiel : inulogic.fr
• Actualités – Page officielle Facebook : facebook.com/inulogic
• Actualités – Page officielle Twitter : twitter.com/Inulogic_Free (obsolète)
• Suivi d'incidents : travaux.inulogic.fr (sans oublier Twitter > AlertePelleteuse)

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 :

• Tarifs abordables et concurrentiels vis-à-vis des offres low-coast américaines
• Hébergement en France dans un datacenter de Free en région parisienne, mais pas sur le stockage d'infogérance de Free : l'infrastructure est 100% indépendante car elle utilise ses propres disques durs et son propre raccordement au réseau Internet
• Support client très réactif et à l'écoute, dont la devise est d'accompagner le client en personnalisant le service rendu plutôt que de le renvoyer à des réponses générales (forum ou wiki)
• Communication régulière sur la maintenance curative et préventive au travers de la liste des tâches en temps réel

À 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
  (l'option -PN considère l'hôte comme étant connecté, elle saute l'étape de découverte de l'hôte)
• tcptraceroute mon_domaine.tld
  (équivalent à un traceroute de niveau 4, la couche transport du modèle OSI)

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.

1. Sites Web & Domaines > Sous-domaine > x.domain.tld > paramètres d'hébergement : changer le répertoire
2. Vérifier dans un navigateur qu'une page générique "votre hebergement fonctionne" apparaît à l'adresse http://x.domain.tld/. Cela peut prendre jusqu'à 30 minutes (changement de configuration du serveur DNS)
3. Gestionnaire de fichiers > sous-répertoire :
   Déplacer le sous-répertoire vers le nouvel emplacement en cochant "Remplacer les fichiers existant".
   Si message d'erreur, déplacer le contenu du sous-répertoire vers le nom du sous-répertoire créé par l'étape n°1.
   Vérifier le sous-répertoire au nouvel emplacement :
   Si le sous-répertoire x est déplacé dans son propre sous-répertoire x/x, redéplacer son contenu vers son répertoire parent ./.. puis supprimer le sous-répertoire x vide
4. Vérifier dans un navigateur que la page normale apparaît à l'adresse http://x.domain.tld/. En cas d'erreur, patienter éventuellement quelques minutes
5. Sites Web & Domaines > Comptes FTP :
   En théorie : Modifier le répertoire principal des utilisateurs FTP associés à l'ancien répertoire
   En pratique : Un bug de Plesk 11.5 et 12.0 impose que le répertoire d'accueil des utilisateurs FTP soit le répertoire racine

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 :

1. Avoir enregistré autredomaine.tld auprès d'un registrar avec les mêmes valeurs de champs DNS NS que celles utilisées pour accéder au site mondomain.tld (Les valeurs NS de Inulogic/free-h.org sont indiquées sur le wiki officiel et peuvent être retrouvés par une requête dig ou nslookup)
2. Déclarer dans Plesk ce sous-domaine virtuel :
   Sites Web & Domaines > Ajouter un nouvel alias de domaine :
   Il est conseillé de laissé coché "Synchroniser la zone DNS avec le domaine primaire", "Service Web" et "Utiliser la redirection permanente avec le code HTTP 301"

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 :

1. Avoir créé dans Plesk un sous-domaine réel x.domain.tld
2. Dans le fichier .htaccess du répertoire /httpdocs cité ci-dessus, remplacer la dernière ligne par :
   RewriteRule ^.*$ http://x.domain.tld/%1

• La variable d'environnement %{HTTPS} contient toujours "off" tandis que %{HTTP:X-Forwarded-Proto} contient soit du vide, soit "https"
  (voir ci-dessous Forcer le HTTPS)
• La variable d'environnement %{SERVER_PORT} contient toujours "80"
• La variable d'environnement %{SCRIPT_URI} est toujours vide
• La variable d'environnement %{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();
?>

• La variable d'environnement $_SERVER['REMOTE_ADDR'] contient l'adresse IP du client sous HTTP, mais elle contient l'adresse IP du serveur sous HTTPS !!
• La variable d'environnement $_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).

• Répertoire d'accueil des utilisateurs FTP :
  Il est actuellement (Plesk 12.0) impossible de choisir le répertoire d'accueil des utilisateurs FTP. Celui-ci est obligatoirement le répertoire racine (ce qui rend caduque l'intérêt d'avoir des utilisateurs FTP différents)
• Accès aux logs du serveur web :
  L'icône / bouton "Logs" de l'interface Plesk 12.0 n'affiche que les fichiers vides qui sont contenus dans le répertoire /logs.
  Pour accéder aux véritables fichiers logs du serveur il faut se connecter à l'aide des identifiants du compte FTP principal à l'URL suivante : http://stats.mondomaine.tld/logs
• La variable d'environnement Apache %{HTTP_REFERER} contient soit "http" soit une chaîne vide tandis que la variable d'environnement PHP $_SERVER['HTTP_REFERER'] est correctement renseignée

Pour 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 clients¹⁾. 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.

• Inulogic :
  • Page d'accueil du site : inulogic.fr
  • Page Notre Infrastructure d'Inulogic
  • Base de connaissance Inulogic pour les serveurs web
  • Blog Inulogic
  • Forum Inulogic
  • Liste des tâches en temps réel (maintenance curative et préventive)
  • Page Inulogic de Twitter
  • Page Inulogic de Facebook
• Manuel en ligne en français du panneau Plesk 12.0