[AlternC-dev] LDAP / Postgres, le retour

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

The Anarcat anarcat at anarcat.ath.cx
Mar 26 Avr 16:57:45 CEST 2005


On Tue Apr 26, 2005 at 02:30:04PM +0200, Patrick Vander Linden wrote:
> Le mardi 26 avril 2005 à 11:48 +0200, Benjamin Sonntag a écrit :
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Patrick Vander Linden wrote:
> > 
> > | Hello,

[...]
 
> > Pour postgresql, je pense que c'est une excellente idée, tout d'abord
> > de faire un module alternc-postgresql qui proposerait aux hébergés de
> > disposer de bases de données postgres, de la même manière que le
> > module m_mysql.php pour mysql actuellement. Tout en laissant le coeur
> > d'AlternC sur une base mysql.
> 
> Si personne n'y voit d'objection, je vais m'atteler à créer ce module.
> ceci me permettra de me familiariser vraiment avec l'api d'alternc.

Aucune objection bien sûr...

Comment je vois ceci, par contre, est qu'il faudrait dégager la logique
de "gestion de base" (ie. créer des bases/usagers/backups) de la logique
"utiliser les bases" (ie. la création des users mail, la liste des
usagers AlternC, qui sont stockés dans MySQL). Ceci sont deux choses
différentes, et on pourrait, par exemple, avoir:

| utilisation des bases | gestion des bases  |
| MySQL / PostgreSQL    | MySQL / PostgreSQL |
| MySQL / PostgreSQL    | MySQL + PostgreSQL |

Ce qui est impossible, évidemment, c'est:

| utilisation des bases | gestion des bases  |
| MySQL + PostgreSQL    | n'importe quoi     |

car à un moment donné, les données doivent usagers (adresses emails,
listes, alias, membres, etc) ne peuvent être stockées à deux endroits en
même temps!

La partie "utiliser les bases" a déjà un niveau d'abstraction, qui est
DB_Sql, qui est pour l'instant seulement sous-classé en DB_Mysql. Pour
cette partie du "port", il suffirait d'écrire une classe DB_Postgresql
et dès lors, AlternC pourrait utiliser une base postgres pour la gestion
des courriels et cie. Idéalement, le package debian (postinst et
alternc.install) configureraient automatiquement le schema AlternC
(qu'il faudra aussi porter) pour Postgres, mais ce n'est pas nécessaire,
a priori...

Je crois qu'il serait peut-être une bonne idée ici de porter AlternC à
un truc comme le module DB de PEAR, car DB_MySQL est un truc assez vieux
qui a un overhead considérable, sans apporter de portabilité et qui
n'est pas aussi bien maintenu que PEAR::DB. PEAR::DB a aussi des modules
connexes très intéressants comme DB_Object...

Et il y a même une autre alternative ici: on pourrait avoir un niveau
d'abstraction supplémentaire entre les différentes classes permettant
de conserver LDAP pour l'utilisation des bases d'AlternC. C'est
évidemment un problème énorme car LDAP ne parle pas SQL, mais c'est
probablement possible de faire ceci...

Pour la partie "gestion des bases", il faut vérifier que m_mysql est
relativement autonome et peut être dupliqué sans trop de pépins... Il
faut aussi s'assurer que les bases postgres passent par le système de
quota (donc se retrouve sur la bonne partition, lors de l'install).
Peut-être que des simples symlinks pourraient faire le travail.

Je pense aussi que le système de config de MySQL devra être séparé en
deux parties: le load de la base de données (qui est nécessaire pour la
bonne utilisation des bases par alternc), ce qui inclus:

- configuration du schema
- initialisation de l'usager "alternc"

et l'installation/déplacement de la base pour le respect des quotas (qui
est nécessaire pour une bonne *gestion des bases* pour les usagers).
Présentement, ces deux étapes sont fusionnées dans un seul script,
mysql.sh, qui en passant, ignore totalement le paramètre "mysql_host"
qui est passé par debconf: il va joyeusement recréer (et repartir!) une
base de données en local, même si on dit que la BD est sur un host
différent...

Donc, en bref, gros ménage à faire là-dedans. Un de mes dadas personels,
avant le port postgres, est la gestion des usagers pour les usagers
alternc. Présentement, il est impossible pour un utilisateur AlternC de
gérer les droits de ses utilisateurs MySQL, et c'est un peu embêtant...

[snip débat postgres/mysql]

Pour moi, c'est la solidité de postgres qui est le "killer". Je ne sais
pas si le problème est réglé dans 4.0, mais mysql 3.23 corrompt les
tables quand l'usager arrive à son quota disque!!! Et on a régulièrement
des problèmes de tables corrompues sur notre serveur, même avec 4.0. 

J'ai beaucoup plus confiance en postgres pour ce genre de choses.

Maintenant, pour ce qui est de smarty....

> Ok pour l'effort au niveau des css, mais l'avantage de smarty est de
> séparer la logique du contenu.

Pas besoin de smarty pour ça. Il suffit d'écrire son code correctement.
AlternC fait ceci relativement bien: il y a un répertoire class/ qui
contient les implantations de base et un répertoire admin/ qui
s'occuppe de la présentation. Ce n'est pas tout à fait MVC encore (il
faudrait avoir class/, admin/ et view/, mettons), mais c'est déjà
beaucoup de fait...

> Pas besoin d'éditer le code php pour changer la logique de
> présentation.

Soit, mais alors on doit éditer du code Smarty, que la plupart d'entre
nous ne connaissent pas, pour changer la logique de présentation.

> Quant à la difficulté de prise en main du metalanguage, pour un
> graphiste ne connaissant pas php, la difficulté d'apprentissage des
> bases de smarty est équivalente à celle d'apprentissage de php.

Pourquoi, alors, un nouveau language, si la difficulté d'apprentissage
est équivalente?

> Envisager smarty se met dans le cadre ou ceux qui codent et ceux qui
> font le design peuvent être des personnes différentes. Mais bon,
> c'était juste une suggestion que je botte aussi en touche alors.

Je suis généralement contre: c'est un overhead supplémentaire qui
distancie les gens qui font le design du code, ce que l'on ne veut pas
nécessairement: tant qu'à les faire apprendre un nouveau language, aussi
bien leur faire apprendre le PHP, ça pourra leur servir... :)

Aussi, il y a d'autre systèmes de templates, assez intéressants, qui ne
réinventent pas la roue et utilisent... PHP comme language de template!
:) Savant en est un exemple. 

> Pour résumer, je vais m'atteler, si cela vous van aux tâches suivantes:
> 	1. création d'un module postgresql à l'instar de m_mysql.php.
> 	2. possibilité d'utiliser postgresql comme coeur d'alternc

C'est évidemment les bonnes tâches, dans le bon ordre. ;)

> 	3. Démontrer que ldap reste utile à alternc :-)

Ceci est déjà démontré. On sait tous qu LDAP est plus interopérable que
mysql, dans certains milieux, et a ses propres vertus. Le problème est
au niveau du code lui-même: comment faire un système qui peut parler
aussi bien à LDAP qu'à une base SQL? C'est pas évident, quoique on a
déjà une base historique... Je voudrais pas voir les scripts d'install,
par contre. ;)

> PS: suis aussi un fan d'xfs :-D

Bof... On a installé en XFS au départ aussi, et on réalise que le load
est énorme lorsque le disque se fait cogner dur... Peut-être pas
seulement dû au XFS, mais je suis inquiet. xfsdump, aussi, prend une
longue éternité[1] à restaurer des fichiers[2], ce que je trouve
vraiment pas rassurant...

A.

[1] "L'éternité, c'est long, surtout vers la fin" -- Woody Allen
[2] http://koumbit.net/wiki/Proc%c3%a9dures/Backups#head-2003c15f74e34c3c72271c7812f1583107e83156
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: non disponible
Type: application/pgp-signature
Taille: 189 octets
Desc: non disponible
URL: <http://lists.alternc.org/arch/dev/attachments/20050426/044f48c9/attachment.pgp>


Plus d'informations sur la liste de diffusion Dev