Services

I. Présentation Dans nos précédents billets sur ce sujet, nous avons vu ce qu’était un serveur web mutualisé, leurs avantages et leurs limites et nous avons également vu leur architecture et fonctionnement général au niveau technique. En fin de la construction de cette architecture, nous avons été confronté à un problème de droit qui nous a forcé à élargir un peu plus les droits par défaut des répertoires web des clients. A travers ce post je vais montrer en quoi cet ajout de droit pose un problème majeur au sein des serveurs web mutualisés utilisant le couple habituel Apache/PHP, ce qui est le cas de la plupart d’entre-eux ! II. États des lieux Nous savons donc que pour fonctionner, les utilisateurs uploads leurs fichiers via un service FTP qui leur est dédié est par lequel ils accèdent à leur espace web qui est chrooté. Pour que ces fichiers soient immédiatement lisibles et traités par Apache via HTTP, nous sommes contraints

I. Présentation Dans de précédents billets (concept et limites), nous avons vu en quoi un serveur web mutualisé consistait et quelles étaient leurs limités générales. Nous allons ici aborder un post un peu plus technique où nous allons, pour mieux les comprendre, monter une architecture système qui nous permettrait de faire tourner un serveur web mutualisé (aussi basique soit il). Je ne prétends pas ici révolutionner le serveur web mutualisé mais au contraire montrer de quoi il est, en théorie, composé et faire en sorte que les services que nous allons installer permettent un fonctionnement global pouvant être assimilé à celui d’un serveur web mutualisé. II. De quoi a t-on besoin ? Comme nous l’avons résumé dans le précédent billet sur le sujet, nous avons vu que le serveur web mutualisé a besoin de plusieurs services basiques pour être considéré en tant que tel : Chaque accès utilisateurs ayant alors besoin d’un accès au FTP, au minimum une base de