[AlternC-dev] alternc2.0 : architecture ??

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

Nil nicolist at limare.net
Jeu 7 Déc 20:02:41 CET 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Extrait plus ou moins remis en forme de discussion sur irc, question
d'architecture au-dela ds details de langage (...).
C'est pas de moi, hein :)

Si faire un daemon, c'est juste parce qu'il faut réinventer "crond",
quel en est l'intérêt. Y a un moment, faut poser des contraintes fortes,
typiquement, est-ce que le système fonctionnera en "batch" ou en "live"
? Mélanger les deux, ça marche jamais bien.

Actuellement, AlternC fait un mix des deux, du "batch" pour les
domaines, et du "live" pour les autres fonctionnalites.

"Live", c'est : les actions sont effectués immédiatement. Quand on fait
du "live", si ça foire, on le sait tout de suite donc on n'a pas
d'information erronnées qui trainent.

"Batch", c'est : traiter un lot de commandes qui est stocke quelque part
en attente du cycle suivant. Quand on fait du "batch" il faut gérer la
remontée des erreurs et c'est souvent délicat, vu que c'est là où on
oublie toujours un bout de code

Le "batch" pourrait sembler plus sécure, et réduire les risques
d'injections de codes et autres... Mais un bout de code qui communique
avec un autre avec une interface bien définie, et des privilèges
different, ne pose pas plus de problèmes de sécu.

Après, y a encore un autre paradigme, celui de la "convergence".

On a un modèle qui représente ce que devrait être l'état quelque part,
et on a un programme dont le boulot c'est de faire "converger" l'état
actuel vers celui du modèle. Ca n'est pas forcément si éloigné du
traitement par lot, mais avec une différence fondamentale : la notion de
« requêtes » disparaît parce que tu le programme qui s'occupe de faire
converger le système les génère « à la volée ».

Pour la remonté d'erreurs, on s'assure que le modèle soit _correct_, et
s'il l'est pas, on le détecte, et on hurle qu'on peut pas converger.
Peut-être plus complique, mais ca peut être une solution très fiable..
parce que ça permet de retrouver un état cohérent en cas de problèmes
(et peut-être une des solutions les plus simples pour faire du
multi-serveur)

Un peu de details: le truc qui fait la convergence, c'est un daemon. Au
chargement, il analyse l'état du système. Il pose ensuite des accroches
aux endroits du système dont il a besoin d'être informé quand il y a un
changement (parce qu'on ne peut pas faire confiance aux roots). Il a
donc l'état du système en mémoire.
Ensuite, il se connecte au modèle (typiquement, la base de données), en
vérifie la cohérence,  et calcule les différences existent entre le
modèle et l'état actuel du système. Il va alors s'efforcer de réduire
ces différences (en créant par exemple une boite mail qui est dans la
table des boites mails, et qui existent pas dans /var/lib/mail). Une
fois que l'état a convergé, il s'endort, et se réveille lorsque le
système, ou le modèle change.
L'interface avec le monde extérieur est réduite au minimum : un signal
quand le modèle change, et un acces  au modèle (+ inotify, pour avoir un
filet de sécurité pour les mouvements qui passent pas par lui)

Contrainte: le daemon doit avoir l'exclusivité des changements du
systeme qui entrent dans son champ de compétence; on ne peut pas ou ne
doit pas creer sur ce système une boite mail ou un domaine ou changer la
configuration de ceux-ci sans passer par alternd (le daemon), soit en
passant par une ui web, soit par le shell alternsh. AlternC doit etre
seul maître a bord, dans son contexte. Le (v)server ne sert qu'a
alternc. On ne doit pas faire en-dehors d'AlternC ce que AlternC peut
faire; c'est pas forcement mal, mais ca n'est pas le fonctionnement actuel.

La question du design ou de l'implémentation des interfaces humaines (en
ligne de commande ou par le web) est distincte, et on peut envisager
autant d'interfaces que de goûts et couleurs, du web
php/java/ruby/autres/..., de la ligne de commande classique ou en
curses, un client-server SOAP/XMLRPC/..., selon les usages. Les
interfaces ne communiquent pas avec le daemon, elles modifient le modèle
(la base de données), et le daemon va agir sur le système si le nouveau
modèle est valable. Sinon, le daemon refuse ces modifications, et le
hurle très fort (comment?). Dan ce cas, le système reste dans l'état
stable qu'il avait avant les propositions de modifs, et le modèle reste
sur sa proposition, non appliquée.

C'est a ce moment que des mails **ALERTE** sont envoyés aux admins et
que la sirène USB se déclenche...

- --
Nil

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFeGVQvviFAPpCP08RAi3dAJ9AnHdnqwfGfGYPPq3Bspa2/52zHACfdUIe
4OHQ+gzs7qL//JPowh/6vdY=
=LfQj
-----END PGP SIGNATURE-----



Plus d'informations sur la liste de diffusion Dev