Il est des billets qui ne servent pas à grand si ce n’est juste de bloc-note à mon intention. L’autre jour, déçu du mode de facturation des snapshots sur les VPS OVH, je me suis mis à la recherche d’outils plus radicaux qui me permettraient de redémarrer mon serveur Debian depuis n’importe quelle machine. J’ai fini par tomber sur le couple duplicity/backupninja dont la simplicité de mise en oeuvre est telle que ce billet devrait vous paraitre inutile.
Pour ceux qui me lisent régulièrement, je fais du multisite WordPress à ma sauce. Or, une des instances que j’héberge ainsi, a une vocation privée : une sorte d’extranet. Pour y parvenir, j’utilise un dispositif simple et efficace qui repose sur des outils particulièrement éprouvés : SSL et l’authentification HTTP Basic. Seulement voilà, les navigateurs de nos jours, pour des raisons bassement mercantiles font tout pour contraindre les propriétaires de site à acquérir des certificats souvent onéreux sans quoi ils effraieront vos usagers en leur disant que votre site n’est pas protégé. Ils vous préviennent aussi que si vous voulez vraiment y accéder, il va falloir lire plein de messages incompréhensibles et cliquer à droite à gauche.
OVH en son temps, proposait des certificats SSL bon marché opérationnels sur leur serveur mutualisé, mais il semble là aussi que le côté bon marché n’ait pas vraiment séduit. J’y vois 2 raisons selon qu’on se place du côté du développeur ou du décideur (les 2 principaux intéressés) :
Bilan, pour pallier à l’impossibilité d’installer un certificat personnel sur un serveur mutualisé, j’ai été contraint d’utiliser mon serveur VPS comme un simple proxy mais avec un certificat valide. Voici le schéma de fonctionnement :
Internet --- HTTPS ---> family.e-gaulue.com --- HTTPS ---> family-direct.e-gaulue.com
(certificat conforme sur VPS) (certificat non conforme du mutu OVH) |
La suite de cet article décrit cette installation.
…
Je suis chez OVH depuis bientôt 4,5 ans. J’apprécie leur fiabilité, par contre j’ai toujours été un peu déçu par la documentation. En fait, OVH c’est un peu le Free de l’hébergement : c’est top quand ça marche, après c’est un peu plus compliqué… Pour finir sur OVH, car ce n’est pas l’objet de ce billet, j’ai le sentiment d’un changement de stratégie commercial qui me fait douter sur la pérennité de mon abonnement chez eux.
Revenons-en à nos moutons. OVH implémente suEXEC sur ses hébergements mutualisés (sûrement à leur sauce). La documentation de suEXEC n’est pas des plus claire et elle a toujours manqué d’exemple. Enfin, on trouve encore moins d’information sur le site d’OVH.
Ce billet présente divers tests afin de mieux comprendre ce qu’on peut faire et ne pas faire quand suEXEC est activé.
Hébergé chez OVH, je cherchais à mettre en place plusieurs instances WordPress avec différents droits d’accès, mais pointant sur un même moteur pour simplifier les mises à jour. J’ai commencé par regarder du côté de la fonction multisite de WordPress 3 et je dois reconnaitre que j’ai eu un peu peur du côté usine à gaz de la chose en comparaison de la simplicité de ce que je voulais faire, en plus il fallait aller toucher au *.mon-domaine.com et je n’en avais pas trop envie.
Bilan, j’ai utilisé les outils à disposition (réduits au minimum chez OVH : du FTP et le manager qui permet de créer des sous-domaines) et des fonctionnalités historiques et simples de WordPress. Je dispose mainenant de 3 instances selon l’architecture suivante :
Tous partagent un seul et unique moteur WordPress.