On va bientôt avoir des macro M4 qui via autoconf génèrent des fichiers XML avec du script LUA qui connecte des bases de données...
Ce que veut faire Marc est de proposer des modules permettant de contrôler la configuration du base system NetBSD via des modules Lua.
Les objectifs sont, entre autres:
1 - les API C actuellement présentes sont déjà très exhaustives en elles mêmes, et fournissent la majorité des fonctionnalités. Ce qu'il manque, ce sont des wrappers qui permettent de les exploiter dans des programmes avec des langages plus haut niveau.
Pour quelle raison? Une toute bête: scripter de la conf, sous Unix, ca se fait en shell/perl/python/ruby (suivant les affinités des individus...) à grands coups de pipes, popen(), execution de sed/awk/sh/grep/cat qui font que ca en devient bordélique, en plus de pousser à l'erreur. Qui ici vérifie proprement les codes d'erreurs retournés par system() quand il fait ces scripts? En toute honnêteté? Et qui ne se plaint pas quand la regexp de pexpect pète parce que dans la dernière version, "P" est devenu "p"?
Cela permet de pouvoir toucher à des configs clients et d'en déployer/rapporter/modifier facilement, à l'instar de WMI de Windows ou des plist MacOSX.
2 - pour Lunatik (un interpréteur Lua in kernel), et de façon plus générale, Lua+C, cela permet de fournir un environnement plus sûr que ce que donne le C et ses pointeurs. C'est pas comme si le jeu de ces dernières années était de retourner un kernel X ou Y en jouant sur des assignations à NULL ou des débordements de toute sorte, ou d'avoir un parsing de chaînes/octets moisi qui finit avec un exploit.
Il souhaite aussi voir ce que ça donne pour kauth(9), ce qui permettrait (pour l'instant, en théorie) de fournir un environnement pour construire ses propres modèles de sécu avec une vision développeur, plutôt qu'intégrateur (comme SELinux par exemple). Aujourd'hui, c'est C ou rien, ce qui pose un problème quand on développe des moniteurs de référence [1]...
J'attends avec impatience le moment ou je devrait mettre à jour MySQL-Client pour pouvoir recevoir mes mails...
C'est une vision de Linuxien ça. Le basesys d'un BSD forme un tout cohérent. Quand tu utilises le MDA du basesys, il n'est pas question de mettre à jour mysql-client-lib-2.6.7-1294.debian54.libc6.2 pour que ca marche/marche pas. Quand on met à jour, on met à jour l'ensemble du basesys, pas le MDA d'un coté et les "modules" d'un autre, avec une surprise au prochain redémarrage du service.
Quant au reste, le principe d'une interface bien conçue, c'est justement d'éviter cela. C'est pas comme si NetBSD avait accumulé une grosse expérience la dedans avec ses couches d'émulation et de compatibilité binaire depuis 15 ans.
j'aimerais bien savoir comment la sql query est secured aussi. Relation de confiance sur l'utilisateur/machhine ou bien il y a un autre fichier avec un mot de passe quelque part ?
C'est un exemple pour montrer un concept... La chose en est à peine à la conception qu'il faudrait déjà se taper les discussions sur la sémantique et l'implémentation détaillée.
[^] # Re: Génial !
Posté par helkyn . En réponse au journal L'homme qui voulait scripter les fichiers de configuration. Évalué à 10.
Ce que veut faire Marc est de proposer des modules permettant de contrôler la configuration du base system NetBSD via des modules Lua.
Les objectifs sont, entre autres:
1 - les API C actuellement présentes sont déjà très exhaustives en elles mêmes, et fournissent la majorité des fonctionnalités. Ce qu'il manque, ce sont des wrappers qui permettent de les exploiter dans des programmes avec des langages plus haut niveau.
Pour quelle raison? Une toute bête: scripter de la conf, sous Unix, ca se fait en shell/perl/python/ruby (suivant les affinités des individus...) à grands coups de pipes, popen(), execution de sed/awk/sh/grep/cat qui font que ca en devient bordélique, en plus de pousser à l'erreur. Qui ici vérifie proprement les codes d'erreurs retournés par system() quand il fait ces scripts? En toute honnêteté? Et qui ne se plaint pas quand la regexp de pexpect pète parce que dans la dernière version, "P" est devenu "p"?
Cela permet de pouvoir toucher à des configs clients et d'en déployer/rapporter/modifier facilement, à l'instar de WMI de Windows ou des plist MacOSX.
2 - pour Lunatik (un interpréteur Lua in kernel), et de façon plus générale, Lua+C, cela permet de fournir un environnement plus sûr que ce que donne le C et ses pointeurs. C'est pas comme si le jeu de ces dernières années était de retourner un kernel X ou Y en jouant sur des assignations à NULL ou des débordements de toute sorte, ou d'avoir un parsing de chaînes/octets moisi qui finit avec un exploit.
Il souhaite aussi voir ce que ça donne pour kauth(9), ce qui permettrait (pour l'instant, en théorie) de fournir un environnement pour construire ses propres modèles de sécu avec une vision développeur, plutôt qu'intégrateur (comme SELinux par exemple). Aujourd'hui, c'est C ou rien, ce qui pose un problème quand on développe des moniteurs de référence [1]...
J'attends avec impatience le moment ou je devrait mettre à jour MySQL-Client pour pouvoir recevoir mes mails...
C'est une vision de Linuxien ça. Le basesys d'un BSD forme un tout cohérent. Quand tu utilises le MDA du basesys, il n'est pas question de mettre à jour mysql-client-lib-2.6.7-1294.debian54.libc6.2 pour que ca marche/marche pas. Quand on met à jour, on met à jour l'ensemble du basesys, pas le MDA d'un coté et les "modules" d'un autre, avec une surprise au prochain redémarrage du service.
Quant au reste, le principe d'une interface bien conçue, c'est justement d'éviter cela. C'est pas comme si NetBSD avait accumulé une grosse expérience la dedans avec ses couches d'émulation et de compatibilité binaire depuis 15 ans.
j'aimerais bien savoir comment la sql query est secured aussi. Relation de confiance sur l'utilisateur/machhine ou bien il y a un autre fichier avec un mot de passe quelque part ?
C'est un exemple pour montrer un concept... La chose en est à peine à la conception qu'il faudrait déjà se taper les discussions sur la sémantique et l'implémentation détaillée.
[1] http://en.wikipedia.org/wiki/Reference_monitor