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 »

Ma configuration Nginx

Les pages de ce site sont désormais servies par Nginx depuis quelques semaines, et j’en suis totalement ravi. Au début il y a eu une période d’incertitude et de petite frayeur du au fait de basculer d’Apache que je maitrise relativement bien, vers une plateforme toute nouvelle avec d’autres habitudes à prendre, d’autres conventions, un style différent (mais pas tant que ça). D’ailleurs en parlant de petite frayeur, avant-hier les sites hébergés sur le Kimsufi ont été indisponibles durant environ 4 heures, j’ai bataillé et sué fort pour trouver mon erreur, ma foi comme souvent, un peu bête (*).

Ce billet fait un peu le point sur ma configuration actuelle de Nginx. J’ai essayé de la faire le plus modulaire possible en créant des blocs relatifs à certains environnements qui sont ou non inclus dans les server blocks (le nom des virtual hosts chez Nginx). Par exemple, j’ai un morceau de code pour les spécificités de WordPress, de Koken ou pour ajouter la gestion HTTPS (SSL).

Configuration

Avec Fedora, la configuration de Nginx se situe sous /etc/nginx, j’y ai créé 2 autres répertoires /etc/nginx/global et /etc/nginx/vhosts. Dans le premier je place tous les blocs de code possiblement redondants – ceux cités plus haut – et dans le second sont placés tous les server blocks, personnellement je crée un fichier par domaine, par exemple j’ai /etc/nginx/vhosts/feub.net.conf pour feub.net.
Le fichier lu par Nginx est /etc/nginx/nginx.conf, je ne l’ai pour ainsi dire pas touché, j’ai juste ajouté un include vers mon répertoire de vhosts, prenant en compte les fichiers se terminant par .conf uniquement :

include /etc/nginx/vhosts/*.conf;

Et voici un exemple de fichier de configuration pour le domaine feub.net :

server {
	listen          80;
	server_name     www.feub.net;
	
	rewrite ^(.*) 	http://feub.net$1 permanent;
}

server {
	listen          80;
	server_name     feub.net;

	root            /var/www/websites_root/feub.net/www/html;
	index           index.php index.html index.htm;

	access_log      /var/log/nginx/feub.net.access.log;
	error_log       /var/log/nginx/feub.net.error.log;

	location / {
		try_files 	$uri $uri/ /index.php?$args;
	}

	include global/php.conf;
	include global/wordpress.conf;
	include global/things_not_logged.conf;
}

Continuer la lecture de « Ma configuration Nginx »

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.

Munin, l’outil de surveillance (monitoring) se serveurs simple

Dans cet article nous parlons de Munin un outil de surveillance (monitoring) simple qui permet de surveiller ses serveurs et stations de travail.

Munin est un outil de surveillance système et réseau qui donne un aperçu de l’état d’une ou des machine(s) au moyen de graphiques RRDTool consultables via un navigateur web. A mon goût, Munin se veut plus simple et rapide dans sa mise en place que des solutions de type Cacti. La procédure d’installation qui suit se fait sur une Fedora 15 et va ne surveiller que la machine elle-même.

Continuer la lecture de « Munin, l’outil de surveillance (monitoring) se serveurs simple »