Encore une fois, un des objectifs est d'avoir une abstraction dans un langage qui permet d'exploiter des bibliothèques en C nombreuses et variées pour pouvoir les exposer plus facilement à des langages plus haut niveau.
Il n'est pas question d'avoir un fourre tout pour que Mr X, qui préfère exim, ait un module Lua qui lui permettra de configurer Postfix avec la magie LDAP. Non.
Vois ca comme ça: pour créer un utilisateur sous Unix, il est quasiment obligatoire de repasser par useradd(8). Si derrière, l'objectif est de faire un script python, qui au final, va appeler une pelle de commandes shell, le python n'a aucun d'intérêt, à part faire de la glue. Et quand il ne sait pas faire, on est coincé.
J'ai connu le temps ou pour exploiter des comptes avec un contexte Kerberos, il fallait jouer avec des variables d'environnement et des fichiers temporaires pour que ca marche, parce que la GSSAPI n'était pas exploitable dans Python... et quand on voit la gueule de l'API, on comprend pourquoi.
Autre exemple: éditer un fichier. Tu souhaites modifier /etc/motd en fonction de la journée. Aujourd'hui: tâche cron obligatoire, qui va appeler un script Perl (parce que le gars préférait Perl), qui va jouer au cat/grep/sed/ ~= <> FILE dedans.
Si tu veux te convaincre de l'utilité de la chose: je t'invite à lire le code source de net-snmp. Quand tu en auras marre de vomir à chaque ligne (entre les #ifdef__LINUX_VERSION_2.6__ && !__LINUX_VERSION_2.4__, les strncmp() dans TOUS les sens pour afficher les points de montage, les options de compil qui ont été activées on ne sait trop comment (merci les autodaubes!), j'espère que tu verras.
Donc oui, chat échaudé craint l'eau froide, le script qui configure automagiquement mes serveurs/params kernel j'en veux pas.
Personne n'obligera à les utiliser.
Il faut bien admettre que la tendance va vers cela, et qu'il n'y a pas beaucoup d'alternatives quand on veut passer à l'échelle (sauf à faire du cfengine/puppet, ce qui revient, au final, à créer des scripts de configuration automagiques... ou jouer avec kickstart -- aïe -- , même joueur joue encore).
PS: que je sache, l'outil omniprésent par excellence sous Unix, le shell, a son comportement contrôlé par un script shell lui même, non (.profile, .*rc, ...)? Ca n'a pas l'air d'avoir dérangé plus que ça ces 30 dernières années.
[^] # Re: Génial !
Posté par helkyn . En réponse au journal L'homme qui voulait scripter les fichiers de configuration. Évalué à 4.
Il n'est pas question d'avoir un fourre tout pour que Mr X, qui préfère exim, ait un module Lua qui lui permettra de configurer Postfix avec la magie LDAP. Non.
Vois ca comme ça: pour créer un utilisateur sous Unix, il est quasiment obligatoire de repasser par useradd(8). Si derrière, l'objectif est de faire un script python, qui au final, va appeler une pelle de commandes shell, le python n'a aucun d'intérêt, à part faire de la glue. Et quand il ne sait pas faire, on est coincé.
J'ai connu le temps ou pour exploiter des comptes avec un contexte Kerberos, il fallait jouer avec des variables d'environnement et des fichiers temporaires pour que ca marche, parce que la GSSAPI n'était pas exploitable dans Python... et quand on voit la gueule de l'API, on comprend pourquoi.
Autre exemple: éditer un fichier. Tu souhaites modifier /etc/motd en fonction de la journée. Aujourd'hui: tâche cron obligatoire, qui va appeler un script Perl (parce que le gars préférait Perl), qui va jouer au cat/grep/sed/ ~= <> FILE dedans.
Si tu veux te convaincre de l'utilité de la chose: je t'invite à lire le code source de net-snmp. Quand tu en auras marre de vomir à chaque ligne (entre les #ifdef__LINUX_VERSION_2.6__ && !__LINUX_VERSION_2.4__, les strncmp() dans TOUS les sens pour afficher les points de montage, les options de compil qui ont été activées on ne sait trop comment (merci les autodaubes!), j'espère que tu verras.
Donc oui, chat échaudé craint l'eau froide, le script qui configure automagiquement mes serveurs/params kernel j'en veux pas.
Personne n'obligera à les utiliser.
Il faut bien admettre que la tendance va vers cela, et qu'il n'y a pas beaucoup d'alternatives quand on veut passer à l'échelle (sauf à faire du cfengine/puppet, ce qui revient, au final, à créer des scripts de configuration automagiques... ou jouer avec kickstart -- aïe -- , même joueur joue encore).
PS: que je sache, l'outil omniprésent par excellence sous Unix, le shell, a son comportement contrôlé par un script shell lui même, non (.profile, .*rc, ...)? Ca n'a pas l'air d'avoir dérangé plus que ça ces 30 dernières années.