franGiPane - vue de loin (discussion)

Cette page contient les discussions/réflexions ayant mené à OverView.

franGiPane - vue de loin (discussion)

Prendre un logiciel d'hébergement existant, ou en écrire un nous-même ?

Ce qui existe en "tout fait"

Une liste plus complète et plus à jour se trouve sur http://deb.riseup.net/web-server/control-panels/.

ravencore

http://www.ravencore.com/

AlternC

un UID unique pour tous les comptes, argh
bousille le système sur lequel on l'installe, c'est-à-dire qu'il le rend quasiment inutilisable pour autre chose... rend nécessaire l'utilisation d'une UML spécifique
le code est crade
PHP + LDAP + MySQL

En gros, c'est mort.

VHFFS

En fait, bad@boum a fait des recherches, et ça semble ne pas correspondre à nos besoins, mais à la fois Ouvaton l'utilise, alors faudrait approfondir. -- intri., 2004 08 01

ISPWorks

homepage : http://www.marlow.dk/site.php/tech/ispworks
pas maintenu depuis fin 2003
utilise grosso modo les mêmes serveurs que nous... une bonne base ?
écrit en PHP + shell script

VHCS - Virtual Hosting Control System

homepage : http://www.vhcs.net/
PHP + C
à regarder, Micah l'a conseillé sur debian-isp

SysCP^?

homepage : http://www.syscp.de/wiki/EnAboutSysCP

mailadmin

subversion: http://www.kallisti.net.nz/websvn/listing.php?repname=mailadmin
jeu de scripts PHP
setup très très proche du notre

Base de données

Choix du moteur de BDD

Dans cette optique, PostgreSQL offre depuis longtemps, alors que ça commence seulement à apparaître dans MySQL 5.0, diverses possibilités dont nous avons besoin :

views
gestion stricte des contraintes
procédures côté serveur dans des langages genre Python et Perl
gestion évoluée des schémas
système de règles de réécriture dynamique des requêtes
héritage

Certaines de ces fonctionnalités font partie du standard SQL, d'autres sont des extensions spécifiques à PostgreSQL... mais, en vrai, chaque moteur de BDD a les siennes.

Où gérer les contraintes ?

On veut gérer le plus possible au niveau BDD la consistence des données qui y sont stockées, plutôt que de mettre (et d'oublier) les checks nécessaires dans le code de franGiPane. Autant penser les contraintes une bonne fois, les forcer, puis ne plus (trop) y penser. Et comme on peut donner à toutes ces contraintes des noms relativement explicites, les messages d'erreur qui nous remonteront devraient nous suffire pour comprendre le paramètre qui merde, sans avoir besoin de se plonger ds le schéma de la base.

Délégation, non non non

Déléguer (comme AlternC, par exemple) la gestion de (sous-)domaines a plusieurs problèmes :

introduire un échelon "hiérarchique" intermédiaire entre les administrateurices de la machine et ses utilisateurices crée une distance entre elleux, distance que nous souhaitons éviter : nous voulons que "nos" utilisateurices soient bien conscient-e-s d'être hébergé-e-s sur boum.org, et non l'impression d'être hébergé-e-s par leur pote qui s'occuperait d'un quelconque domaine qu'on héberge ;
ça implique de développer une webapp d'administration, c'est pénible, difficile à sécuriser ;
ça complique énormément le design de la base de données relationnelle.

Héberger des noms de domaines, un peu, beaucoup ?

Au départ, nous pensions être obligé.e.s de n'héberger qu'un strict minimum de noms de domaines, pour des histoires de certificats : il n'était possible, jusqu'à y'a pas si longtemps, d'avoir qu'un certificat par IP sous Apache, par exemple.

Ce n'est plus vraiment le cas, depuis que CAcert peut fournir des certificats correspondant chacun à plusieurs noms de domaines.

Par contre, pour ce qui est de Postfix, je ne sais pas ce qu'il en est, et le plus simple est encore de mettre boum.org comme MX pour tout domaine hébergé, et hop.