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

[Emmanuel Thierry]

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)
* www-data appartenant à chaque groupe "user"
C'est beaucoup plus light que apache, et au minimum aussi sécurisé.

> 
> Pour ceux qui ont un accès ssh nous avons fait aussi une prison chroot, de la sorte ils ne peuvent pas se balader sur toute la machine. Cela leur permet des mises à jour plus simples de leur site (par l'utilisation d'outils du genre drush ou git).
> 
> Je pense que ça pourrait aussi être fait avec des conteneurs lxc, sans doute de manière plus simple et plus propre (pour ce qui est de la prison chroot en particulier), mais peut-être plus gaspilleuse de mémoire (à voir).

Ça dépend :
* Soit tu lances un environnement LXC par user avec un démon SSH à l'intérieur, et auquel cas ça consomme la mémoire d'un démon SSH pour chaque user
* Soit tu lances le démon SSH sur le système hôte, et que tu exécutes une console LXC à la connexion de l'utilisateur (moyennant un peu de script) et ça ne change pas grand chose en mémoire
Ceci dit, l'avantage de la première technique est que quitte à faire du LXC, autant mettre le process php-fpm dedans, auquel cas tu obtiens une excellente isolation de tes sites

> 
> En tous cas je t'encourage vivement à séparer la VM associative et les VM persos, ne serait-ce que par rapport à l'association: si un jour tu en as marre et quittes l'association, il faut que l'infrastructure puisse être reprise simplement, et pour ça éviter de tout mélanger. D'ailleurs sans faire une pub éhontée pour ma paroisse, le PIC pourrait peut-être héberger ton site associatif ? Si tu veux on en parle en privé, ou encore mieux sur picca at le-pic.org


Je plussoie totalement, surtout que ça va être dur de caser dans une seule VM tetaneutral du mail, des ML, un owncloud et des sites web.

Manu