Permissions des fichiers et répertoires d’un serveur web

Cet article établit une base de travail au niveau des permissions lors de la mise en place d’un serveur web hébergeant plusieurs sites pour plusieurs clients.

Un serveur HTTP peut contenir plusieurs sites, les fichiers de ceux-ci peuvent être gérés par plusieurs utilisateurs, un utilisateur A ayant accès aux fichiers du site A, mais pas à ceux du site B, alors qu’un utilisateur C, aura accès aux fichiers des site A, B et C par exemple.

Ce qui suit ne s’adresse pas à un type de serveur particulier, mais suppose une machine GNU/Linux et un serveur Nginx ou Apache.

Les permissions

Normalement sous Linux, lorsqu’un fichier est créé, il hérite du groupe de l’utilisateur qui l’a créé. Dans le cas de fichiers et répertoires relatifs à un serveur web, il est préférable que lorsqu’un fichier est créé il hérite du groupe du répertoire parent (en général /var/www), pour faire ceci il faut activer le bit SGID (Set Group ID) du répertoire parent.
Pour se rafraichir un peu les neurones au niveau du concept de permissions sous Linux, voir ce billet.

D’un autre coté, pour travailler convenablement avec ses collaborateurs, il faut prendre soin de modifier le umask, le masque de création de fichier par l’utilisateur, qui est général placé à 022 par défaut, c’est-à-dire que lorsqu’un fichier est créé il aura comme permissions 755, ce fichier n’étant pas éditable par le groupe. Changer le umask en 002 va placer les permissions d’un nouveau fichier en 775.

Continuer la lecture de « Permissions des fichiers et répertoires d’un serveur web »

Apache passe la main à Nginx

Depuis un petit moment déjà je lorgnais du coté du serveur Nginx (prononcer Engine X) réputé plus rapide que Apache, surtout pour le contenu statique, ainsi que sa gestion de PHP avec l’interface PHP-FPM (FastCGI Process Manager). Ce qui me freinait était la migration de 7 domaines avec pour certains autant de sous-domaines sur mon Kimsufi. Lorsque l’on parle de serveur HTTP, il n’est pas simple de migrer petit à petit, c’est une bascule directe de l’un à l’autre si l’on veut continuer de servir les pages sans interruption de service.

Le pas est maintenant franchi et ces pages sont désormais le fruit d’une réponse de Nginx. Les performances d’affichage sont indéniables, le moteur de galerie photo Koken sur fabienamann.photography par exemple a pris un bon coup de boost, les photos apparaissent plus rapidement qu’avec Apache. WordPress et Roundcube me semblent également plus véloce. Je ne suis pas un fana du benchmark, donc je ne me suis pas amusé à faire des tests, ce n’est que du ressenti. Je suis globalement content de la migration.

La tête avant les doigts, pas l’inverse

Crédit : http://www.fotopedia.com/items/jeans-Y-cdLxGnotQ

Hier soir a été un de ces moments où les doigts fonctionnent plus vite que le cerveau pour moi. J’ai mis à genoux le serveur qui héberge feub.net, bon nombre d’autres domaines et un serveur de messagerie pour ne citer que les services les plus importants, juste parce que je n’ai pas réfléchi avant d’agir et il m’a fallu trois bonnes heures pour corriger mes dégats.
N’ayant jamais eu à gérer un nombre dingue de domaines et d’hébergements, je fais tout à la main (DNS, httpd/vhost, etc), mais j’ai voulu essayer un panneau de gestion d’hébergements open source, en l’occurence ZPanel et ça a été le début de la fin.

Continuer la lecture de « La tête avant les doigts, pas l’inverse »

Serveur mandataire inverse avec Apache

Note rapide pour la mise en place d’un serveur mandataire inverse – reverse proxy – avec Apache. Le but est d’avoir un serveur web frontal – le serveur mandataire – qui reçoit les requêtes et va en rediriger certaines vers un ou plusieurs autres serveurs web, par soucis de sécurité notament. Dans mon cas, j’ai une application web PHP/DB2 utilisée par certaines personnes uniquement sur le réseau local, et mon chef me demande de l’installer sur une de nos machines en DMZ pour les agents extérieurs. Il me semblait plus judicieux de s’affranchir d’ajouter une autre instance de cette application qui devrait être maintenue, sauvegardée, etc.

Continuer la lecture de « Serveur mandataire inverse avec Apache »