frangipane/ OverView/ discussion
  1. Prendre un logiciel d'hébergement existant, ou en écrire un nous-même ?
    1. Ce qui existe en "tout fait"
    2. ravencore
  2. Base de données
    1. Choix du moteur de BDD
    2. Où gérer les contraintes ?
  3. Délégation, non non non
  4. Héberger des noms de domaines, un peu, beaucoup ?

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

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

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

Webmin + Virtualmin

DTC (Domain Technologie Control)

Mandragor (APINC)

ISPWorks

VHCS - Virtual Hosting Control System

SysCP

mailadmin

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.