[AlternC-dev] Presentation ( un peu en retard)

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

Alan Garcia a.garcia at nnx.com
Lun 5 Mar 12:18:13 CET 2012


On 05/03/2012 11:42, Remi wrote:
> Salut,
>
> Voici ma liste d'idées à moi (que d'autres ont eu avant...)
>
> * Réunir les données propres à chaque utilisateur
>
> L'arborescence /var/alternc/html, /var/alternc/mail/, /var/alternc/dns,
> ... serait remplacée par une arborescence du type
> /var/alternc/users/0/1/2010/html, /var/alternc/users/0/1/2010/mail
> /var/alternc/users/0/1/2010/dns où 2010 est l'uid de l'utilisateur
(nota : /var/alternc/dns a été dégagé pour notre plus grand bonheur)

>
> Les données de configuration de l'utilisateur seraient synchronisées
> (dupliquées) dans le répertoire /var/alternc/users/0/1/2010/data
>
> Cette arborescence permettrait de rendre trivial l'export/import d'un
> compte (même si cela est déjà bien avancé en non-trivial), de séparer
> totalement la notion de compte et de login, de répartir les données sur
> différents serveurs de fichiers (ou partitions pour les petits hébergeurs)
> de manière "statistiquement" équilibrée, de rendre ainsi immédiat le
> calcul du quota, de faciliter la désactivation d'un compte, la
> mutualisation des comptes de deux hébergeurs (collision de deux logins)

Pas con ça.
Par contre, en gros ça ne concerne quasiment que les mails et l'html et 
les logs apache.
Par contre je comprend pas ton "0/1/2010" ?

> * Une API AlternC
>
> Chaque utilisateur disposerait d'un clé API pour l'utilisation d'AlternC
> disponible dans le fichier
> /var/alternc/users/0/1/2010/data/api_config.php
>
> Cette clé leur permet d'accéder à toutes les fonctionnalités de
> l'interface AlternC depuis les classes AlternC mutualisées sur le serveur
> dans le répertoire /var/lib/alternc/source/
>
> Les utilisateurs avec les droits d'administrateurs accèdent bien entendu à
> des fonctions plus avancées (gestion des utilisateurs, mais aussi
> fonctionnalités plus avancées).

Gros travail qui nécessitera un vrai developpeur PHP.
Mais oui, ça serais bien.

> * Customisation du bureau
>
> Aujourd'hui, malheureusement, la séparation entre le coté serveur
> d'AlternC et le coté end-user n'est pas assez évidente. Le fait d'avoir
> une API permettrait de pallier cette problématique. Je ne pense pas que
> tout le monde soit fan de l'ergonomie d'AlternC (même si on lui reconnait
> nombre de qualités), ni même simplement que tout le monde ait envie
> d'avoir la même interface que l'hébergeur voisin.
>
> Il faudrait donc, tout en continuant à proposer une interface par défaut,
> permettre facilement à chaque hébergeur d'avoir sa propre interface.
>
> J'imagine qu'avec l'API, cela serait déjà plus évident.
>
> Mon avis est que puisque nous aurions compartimenté les données de chaque
> utilisateur, et que nous disposerions d'une API, nous pourrions également
> compartimenter la partie serveur API distante de la partie cliente locale.
>
> Cette partie cliente pourrait être appelée avec les droits de
> l'utilisateur final pour amener plus de sécurité et permettre à
> l'utilisateur final de la personnaliser à son tour (par surcharge de
> classe ou templates par exemple).
>
> On pourrait très bien imaginer stocker le code appelant dans
> /var/alternc/users/0/1/2010/admin/ et enregistrer les identifiants de
> connexion dans un .htaccess/.htpasswd (cela permettrait de n'utiliser au
> sein d'AlternC que l'uid). Les logins utilisés en préfixe seraient
> remplacés par les noms de domaine (login et base SQL, login ftp).
>
> Ainsi un compte qui change d'hébergeur peut garder ses identifiants et ne
> pas modifier le code de ses applications (login sql, ...).

Pas con du tout tout ça.
Par contre, je pense qu'avant d'envisager ça, il faut refaire de gros 
morceau du schema de base alternc (qui est pas cohérent partout), sinon 
on va avoir pas mal de pb.

> * Automotisation de la prise en compte des changements
>
> Il y a bien longtemps qu'un stagiaire avec déjà été mis sur le coup de
> faire gérer les DNS par nsupdate ce qui résoud nombre de problématiques
> comme la mise à jour "en direct" des zones, et la non nécessité d'avoir à
> parser manuellement ces fichiers. Je trouverais vraiment génial que ce
> système soit en place.
(nota : on parse plus les fichiers DNS, ca a été refondu).

>
> Le seul changement qui aujourd'hui n'est pas pris en compte
> automatiquement en dehors des DNS est le redémarrage du serveur Apache
> lors de l'ajout d'un sous-domaine (la faute au open_basedir sinon on
> aurait pu utiliser VirtualDocumentRoot). Il existe bien un patch
> https://bugs.php.net/bug.php?id=34663 mais les développeurs de PHP ont
> décidé que "c'est pas ma faute à moi"
>
> Peut-être qu'avec mpm-itk, ce sera solutionné? Pas eu le temps de voir
> ça... Ou est-il sinon possible de faire un module pour PHP sans patcher
> l'original?

Déjà faut pas oublier que maintenant les gens peuvent définir des 
templates apache pour leurs usagers, ce qui complexifie (on a pas "une 
conf apache", on en a X, et elles sont gérés par les utilisateurs)

Deux solutions je pense :
   - recoder pour gérer les DNS avec powerdns (tape en base de donnée, 
donc instantanné) et utiliser un serveur web capable de lire de la conf 
apache en base de donnée ( "Apache already comes with a module for user 
authentication using SQL: mod_authn_dbd, so there are now three useful 
things you can do with Apache and a database: authentication, virtual 
hosts, and logging. ")
   - modifier update_domains pour qu'il ne soit pas lancé par un cron, 
mais dès qu'une modification est faite et qui le concerne (trigger ?), 
avec une securité qui dis 'tu n'as pas le droit d'etre lancé plus de X 
fois en X minutes'.

> * Ajout d'un module de monétisation
>
> Si AlternC pouvait gérer directement de base un module de monétisation
> (que ce soit des euros ou des grains de SEL), cela serait une grande
> avancée. Prévoir l'intégration de modules de paiement tiers comme Paypal,
> ou d'autres. Prévoir de même les mails de rappels avant l'échéance d'un
> abonnement, la désactivation automatique (avant la suppression) de la
> fonctionnalité concernée, ou encore le prépaiement pour une fonction.
>
> Par exemple, une adresse mail coute chez l'hébergeur X "3 grains de
> sel/an", mais le pack annuel de base à 20 grains de sel comprend déjà "5
> adresses e-mail" et je peux en racheter au maximum 10. 2 moins avant la
> fin de mon abonnement pour un mail supplémentaire je suis averti qu'il
> arrive bientôt à expiration, etc.

Les gens qui vont vouloir de la monétisation ont déjà leur SI, ou vont 
s'en mettre un en place (genre un Dolibarr, ou autre).
Quand je réfléchissait à cette problèmatique, j'avait fini par écrire ça :
http://www.alternc.org/wiki/IntegrationSI
Qui permet, je pense, d'avoir une assez bonne intégration avec n'importe 
quel SI (via les scripts appelé), sans pour autant rajouter trop de 
choses dans AlternC lui-même.

> Voilà, franchement, j'espère que ce ne sera pas le sujet de stage de
> Steven parce que même si ça me parait de bonnes idées, ça m'a l'air
> costaud ;)
Son sujet de stage c'est la roadmap AlternC 1.1 :o)

Après, si on le perverti assez, il continuera p'tet sur son temps libre...

-- 
Alan Garcia
Neuronnexion, Prestataire Internet & Intranet
21 rue Frédéric Petit - 80000 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99
http://www.neuronnexion.coop



Plus d'informations sur la liste de diffusion Dev