[technique] Quelle infra pour un hébergement associatif ou familial ?

[Emmanuel Thierry]

Le 23 févr. 2015 à 21:43, Emmanuel Courcelle a écrit :

> Le 22/02/2015 16:15, Emmanuel Thierry a écrit :
>> Le 22 févr. 2015 à 11:52, Emmanuel Courcelle a écrit :
>> 
>>> Le 21/02/2015 18:40, numahell a écrit :
>>>> Bonjour,
>>>> 
>>>> J'ai le projet de faire de l'hébergement associatif et également pour ma famille (étendue) de services tels que mail, listes de mail, serveur de fichier, et sites web notamment.
>>>> Pour le moment on a une VM pour notre mail perso, un owncloud et nos 3 ou 4 sites web, mais je n'avais pas envie de "polluer" cette VM avec d'autres services, si le nombre de connexions simultannées est trop important.
>>>> J'ai un nom de domaine pour l'associatif (qui sera plutôt orienté sur mon quartier) et un pour ma famille.
>>>> 
>>>> Du coup je me pose quelques questions techniques, d'autant que l'admin sys est loin d'être ma spécialité (je fais plutôt de l'habillage de sites internet :))
>>>> Est-ce que je fais une VM pour l'hébergement associatif, et une pour la famille ? Une VM pour tout ? Une VM par service (genre une VM pour les mails, une pour le web ?)
>>>> Est-ce que lorsque vous gérez plusieurs VM vous les gérez avec Openstack aussi ?
>>>> Et pour cloisonner un peu les services, qu'est-ce que vous utilisez quoi ? lxc ? docker ? Vous ne cloisonnez rien du tout ?
>>>> 
>>>> Merci d'avance de vos réponses,
>>>> 
>>> Bonjour
>>> 
>>> Au pic (où nous hébergeons des associations: sites web + listes de mail), nous n'avons qu'un seul serveur de production.
>>> Chaque asso a un compte, avec accès uniquement via ftp (sauf une ou deux qui ont un accès ssh).
>>> 
>>> Nous utilisons apache et nous séparons les assos avec le module apache2-mpm-itk, qui permet de faire en sorte qu'apache tourne sous un user unix différent dans chaque virtualhost: de la sorte chaque asso a son user différent, et si un site a un pb de sécurité (défiguration par exemple) la vulnérabilité ne peut pas mettre en danger les autres sites.
>>> 
>>> Plus précisément, du point-de-vue unix, chaque asso a un groupe + deux users (qui sont dans le même groupe):
>>> - Un user pour l'accès sftp (ou ssh voir plus loin)
>>> - Un user pour apache
>>> 
>>> apache peut tout lire (les permissions recommandées sont rwXr-X---) et écrire là où on lui met rwXrwX---
>> Ou bien :
>> * nginx (www-data:www-data) + php-fpm (user:user)
>> * Avec les dossiers utilisateurs rwXr-X--- (comme dans ta technique)
> Je vais peut-être dire une bêtise, mais si le multiuser est pris en charge par php-fpm ça ne marche que pour des sites en php ? Alors que la solution qui repose sur apache est indépendante du site lui-même

L'isolation n'est utile que pour les scripts, pour éviter qu'un script d'un site ne puisse accéder aux fichiers d'un autre site.
Pour les fichiers statiques je ne vois pas l'intérêt de l'isolation ! ;)

Et du coup si on fait du fastcgi :
* Pour la majorité des sites (en php) : php-fpm
* Pour les autres (python, perl, ruby, etc) : uwsgi

> 
>> * www-data appartenant à chaque groupe "user"
>> C'est beaucoup plus light que apache, et au minimum aussi sécurisé.
> Sauf que si www-data appartient à chaque groupe, il n'y a plus vraiment d'isolation !

Bah si, c'est à dire que tes users sont incapables d'accéder aux fichiers des autres users.
Par contre le serveur est capable d'accéder aux fichiers de tous les users.

Manu