Bonjour,
C'est certainement un peu hors sujet ici, mais vu le traffic relativement élevé de cette liste, je me permets de poster quand même. J'espère que vous ne m'en tiendrez pas rigueur :-)
Comme pas mal d'entre nous je pense, je suis admin unix. Dans le cadre de mon travail je cherche à simplifier la gestion des serveurs, et pour cela, j'aurais besoin d'executer des commandes à distance, de façon programmée. Mettons un genre de serveur maitre, avec un "logiciel" qui soit capable de gérer des groupes et d'executer sur ces groupes de machines des commandes ou des scripts.
Comme je pense que d'autres ont déjà été confrontés à cette problèmatique, j'aimerais savoir comment vous l'avez résolue ?
Comme cahier des charges : peu ou pas d'installation sur la machine cliente (au pire un agent résident unique), et les normes du lieu nous interdisent les connexions ssh directement en root (on est obligé de passer par l'utilitaire calife).
Connaissez-vous des programmes (propriétaires ou non) qui répondent à cette problèmatique ?
Merci,
Jeremy
$u ?
Le 03/04/07, Jeremy Monnet jmonnet@gmail.com a écrit :
Bonjour,
C'est certainement un peu hors sujet ici, mais vu le traffic relativement élevé de cette liste, je me permets de poster quand même. J'espère que vous ne m'en tiendrez pas rigueur :-)
Comme pas mal d'entre nous je pense, je suis admin unix. Dans le cadre de mon travail je cherche à simplifier la gestion des serveurs, et pour cela, j'aurais besoin d'executer des commandes à distance, de façon programmée. Mettons un genre de serveur maitre, avec un "logiciel" qui soit capable de gérer des groupes et d'executer sur ces groupes de machines des commandes ou des scripts.
Comme je pense que d'autres ont déjà été confrontés à cette problèmatique, j'aimerais savoir comment vous l'avez résolue ?
Comme cahier des charges : peu ou pas d'installation sur la machine cliente (au pire un agent résident unique), et les normes du lieu nous interdisent les connexions ssh directement en root (on est obligé de passer par l'utilitaire calife).
Connaissez-vous des programmes (propriétaires ou non) qui répondent à cette problèmatique ?
Merci,
Jeremy
Linux Registered User #317862 Linux From Scratch Registered User #16571 Please do not send me .doc, .xls, .ppt, as I will *NOT* read them. Please send me only open formats, as OpenDocument or pdf. _______________________________________________ Shell mailing list http://cli.asyd.net/home/ https://lists.asyd.net/mailman/listinfo.cgi/shell
Le 3 avr. 07 à 20:38, Jeremy Monnet a écrit :
Bonjour,
Bonjour,
C'est certainement un peu hors sujet ici, mais vu le traffic relativement élevé de cette liste, je me permets de poster quand même. J'espère que vous ne m'en tiendrez pas rigueur :-)
Comme pas mal d'entre nous je pense, je suis admin unix. Dans le cadre de mon travail je cherche à simplifier la gestion des serveurs, et pour cela, j'aurais besoin d'executer des commandes à distance, de façon programmée.
Tu peux utiliser tentakel qui est un sympathique script en python je crois . Tu peux envoyer simultanément une commande sur plusieurs machine et récupérer leurs sorties standards. http://tentakel.biskalar.de/
Mettons un genre de serveur maitre, avec un "logiciel" qui soit capable de gérer des groupes et d'executer sur ces groupes de machines des commandes ou des scripts.
Tentakel sais gérer les groupes.
Comme je pense que d'autres ont déjà été confrontés à cette problèmatique, j'aimerais savoir comment vous l'avez résolue ?
Comme cahier des charges : peu ou pas d'installation sur la machine cliente (au pire un agent résident unique), et les normes du lieu nous interdisent les connexions ssh directement en root (on est obligé de passer par l'utilitaire calife).
Tentakel passe par ssh, donc pas de conf coté client. SI ce n'est la mise a jour de l'authorized_keys
Connaissez-vous des programmes (propriétaires ou non) qui répondent à cette problèmatique ?
Je n'ai rien entendu.
Merci,
Je t'en prie.
Jeremy
Jérôme Gaulin.
On 2007-04-03 20:38:21 +0200, Jeremy Monnet wrote:
C'est certainement un peu hors sujet ici, mais vu le traffic relativement élevé de cette liste, je me permets de poster quand même. J'espère que vous ne m'en tiendrez pas rigueur :-)
Je ne pense pas que ce soit hors sujet.
Comme pas mal d'entre nous je pense, je suis admin unix. Dans le cadre de mon travail je cherche à simplifier la gestion des serveurs, et pour cela, j'aurais besoin d'executer des commandes à distance, de façon programmée. Mettons un genre de serveur maitre, avec un "logiciel" qui soit capable de gérer des groupes et d'executer sur ces groupes de machines des commandes ou des scripts.
Comme je pense que d'autres ont déjà été confrontés à cette problèmatique, j'aimerais savoir comment vous l'avez résolue ?
SSH + authentification avec clé RSA. Dans le .ssh/authorized_keys, tu peux restreindre à la connexion à une certaine commande: cela améliore grandement la sécurité.
Comme cahier des charges : peu ou pas d'installation sur la machine cliente (au pire un agent résident unique), et les normes du lieu nous interdisent les connexions ssh directement en root (on est obligé de passer par l'utilitaire calife).
De l'autre côté, ça peut être une commande qui fait un sudo.
Merci pour vos réponses !
On 4/3/07, Vincent Lefevre vincent@vinc17.org wrote:
C'est certainement un peu hors sujet ici, mais vu le traffic relativement élevé de cette liste, je me permets de poster quand même. J'espère que vous ne m'en tiendrez pas rigueur :-)
Je ne pense pas que ce soit hors sujet.
Disons qu'on est plus dans le cadre du strict script shell :-)
façon programmée. Mettons un genre de serveur maitre, avec un "logiciel" qui soit capable de gérer des groupes et d'executer sur ces groupes de machines des commandes ou des scripts.
SSH + authentification avec clé RSA. Dans le .ssh/authorized_keys, tu peux restreindre à la connexion à une certaine commande: cela améliore grandement la sécurité.
Ca n'est malheureusement pas possible sur toutes les machines. On a une grande partie de notre parc sur lequel un seul compte utilisateur permet de se connecter, et il est hors de question de modifier quoi que ce soit sur ce compte.
Comme cahier des charges : peu ou pas d'installation sur la machine cliente (au pire un agent résident unique), et les normes du lieu nous interdisent les connexions ssh directement en root (on est obligé de passer par l'utilitaire calife).
De l'autre côté, ça peut être une commande qui fait un sudo.
On ne sait pas aujourd'hui quels seront les besoins demain, or l'intèrêt serait de ne pas avoir de reconfiguration a faire sur les serveurs par la suite (dans ce cas, ajout de scripts, et ajout des paramètres pour sudo sur chaque machine).
Je vais regarer $u, Tentakel, cfengine et ClusterSSH. Comme je pense que la problèmatique intéresse d'autres personnes (ou du moins j'espère ?) quand j'aurais trouvé (ou pas), je vous tiendrai au courant.
Merci encore ! :-)
Jeremy
Jeremy Monnet a écrit :
Je vais regarer $u, Tentakel, cfengine et ClusterSSH. Comme je pense que la problèmatique intéresse d'autres personnes (ou du moins j'espère ?) quand j'aurais trouvé (ou pas), je vous tiendrai au courant.
CFengine peut répondre au besoin pour exécuter des commandes de manière répétitive, par contre il est assez tordu de faire une commande unique planifiée une seule fois (je rêve de quelque chose qui permettrait de faire ça sur un réseau hétérogène et de manière sécurisée, tellement que j'avais commencé à écrire un protocole).
De plus, même si ça n'engage que moi, le modèle client / serveur de cfengine est un peu naze. A router / filtrer c'est chiant (si seulement on pouvait faire ça simplement en soap ou autre over https...)
En contrepartie le modèle de classes et le langage cfengine sont particulièrement géniaux, si quelqu'un connait une méthode pour y rajouter un ordonanceur / récupérateur d'info dessus... je suis preneur :)
On 2007-04-04 09:43:48 +0200, Jeremy Monnet wrote:
On 4/3/07, Vincent Lefevre vincent@vinc17.org wrote:
C'est certainement un peu hors sujet ici, mais vu le traffic relativement élevé de cette liste, je me permets de poster quand même. J'espère que vous ne m'en tiendrez pas rigueur :-)
Je ne pense pas que ce soit hors sujet.
Disons qu'on est plus dans le cadre du strict script shell :-)
Enfin, j'avais écrit quelque chose de ce genre (pour la partie SSH) en Perl. Ça reste assez proche des scripts shell (mais c'est plus puissant).
[...]
foreach my $host (@arg) { # Fix a limit of 16 clients per host. foreach (1..($host =~ s/^:(\d+)://g ? ($1 > 16 ? 16 : $1) : 1)) { print "\rStarting t3-client", (@opt ? " @opt" : ""), " on $host...\n"; my $pid = fork; defined $pid or die "$proc: can't fork\n";
unless ($pid) { exec @ssh, $host, $cmd; die "$proc: exec ssh $host failed\n"; } } }
foreach (0..$#arg) { waitpid -1, 0 }
print "OK, all ssh children exited.\n";
SSH + authentification avec clé RSA. Dans le .ssh/authorized_keys, tu peux restreindre à la connexion à une certaine commande: cela améliore grandement la sécurité.
Ca n'est malheureusement pas possible sur toutes les machines. On a une grande partie de notre parc sur lequel un seul compte utilisateur permet de se connecter, et il est hors de question de modifier quoi que ce soit sur ce compte.
Tu n'as besoin que d'un seul compte utilisateur. Il suffit juste d'ajouter une ligne dans une fichier dans le home de l'utilisateur; s'il est partagé par NFS, c'est probablement encore mieux.
Les autres solutions basées sur SSH auront les mêmes besoins.
On ne sait pas aujourd'hui quels seront les besoins demain, or l'intèrêt serait de ne pas avoir de reconfiguration a faire sur les serveurs par la suite (dans ce cas, ajout de scripts, et ajout des paramètres pour sudo sur chaque machine).
C'est pourtant obligatoire quelle que soit la solution si tu veux un minimum de sécurité.
Je vais regarer $u, Tentakel, cfengine et ClusterSSH.
Aucune idée de ce qu'est $u (c'est con de choisir un nom comme ça, qui ne peut pas être recherché sur Google).
Tentakel est une solution basée sur SSH, du genre de ce que je donne ci-dessus, mais avec une gestion de la sortie en plus. Note que c'est du python, et que python a la facheuse manie d'avoir des problèmes de compatibilité d'une version à l'autre.
Je pense que TakTuk http://taktuk.gforge.inria.fr/ (pas encore cité ici) fait le même genre de choses; apparemment, c'est du C++. C'est aussi une solution basée sur SSH (par défaut, mais il peut utiliser d'autres choses). Je ne sais pas ce que ça vaut, mais ça c'est bien: « autopropagation: the engine can spread its own code to remote nodes in order to deploy itself. »
Pour cfengine, il te faudra au moins installer le logiciel (apparemment c'est un système de configuration centralisé). Et c'est aussi une solution basée sur SSH, avec des choses à configurer sur le serveur et les clients.
ClusterSSH a l'air d'être une solution assez lourde, nécessaitant XWindow. D'après la FAQ: « You run a utility (cssh) giving a couple of server names as parameters, and then xterms opens up to each server with an extra "console" window. »
On 4/4/07, Vincent Lefevre vincent@vinc17.org wrote:
Disons qu'on est plus dans le cadre du strict script shell :-)
Enfin, j'avais écrit quelque chose de ce genre (pour la partie SSH) en Perl. Ça reste assez proche des scripts shell (mais c'est plus puissant).
J'ai aussi commencé à écrire un truc, en ruby et à base de expect. Mais plutot que de réinventer la roue, je préfére en général ré-utiliser l'existant.
Tu n'as besoin que d'un seul compte utilisateur. Il suffit juste d'ajouter une ligne dans une fichier dans le home de l'utilisateur; s'il est partagé par NFS, c'est probablement encore mieux.
Aucune modification tolérée sur ce compte utilisateur. Ceci inclut l'ajout d'une clé ssh ... :-(
Les autres solutions basées sur SSH auront les mêmes besoins.
Sauf à utiliser une base de expect, et à renseigner les mots de passe lors du lancement.
C'est pourtant obligatoire quelle que soit la solution si tu veux un minimum de sécurité.
Il n'y aucun pare-feu sur nos serveurs puisque nous sommes protégés par une boite noire (comprendre une boite pare-feu entre le monde extérieur et nous). Notre client l'a décidé ainsi, je n'ai pas mon mot à dire. re- :-(
Je vais regarer $u, Tentakel, cfengine et ClusterSSH.
Aucune idée de ce qu'est $u (c'est con de choisir un nom comme ça, qui ne peut pas être recherché sur Google).
dollar univers :-)
Tentakel est une solution basée sur SSH, du genre de ce que je donne ci-dessus, mais avec une gestion de la sortie en plus. Note que c'est du python, et que python a la facheuse manie d'avoir des problèmes de compatibilité d'une version à l'autre.
J'ai vu ca. Mais mon plus gros problème avec cette solution-là, c'est qu'elle ne propose pas de solution (a priori) pour passer root a partir d'un compte utilisateur, et sans utiliser "su", ce qui le rend inutile dans mon cas.
ClusterSSH a l'air d'être une solution assez lourde, nécessaitant XWindow. D'après la FAQ: «You run a utility (cssh) giving a couple of server names as parameters, and then xterms opens up to each server with an extra "console" window.»
C'est une solution qui ne répond pas à mon cahier des charges initial (programmation de tâches, executions automatiques etc), et pourtant je l'ai installé, et je trouve vraiment bien. C'est orienté "console interactive sur plusieurs machines en parallèle" et ca peut être pratique (fini les longues heures passées à me connecter sur 40 machines pour mettre à jour un fichier et relancer un service).
Jeremy
On 2007-04-04 17:03:17 +0200, Jeremy Monnet wrote:
Mais plutot que de réinventer la roue, je préfére en général ré-utiliser l'existant.
OK, mais si tu ne peux rien installer, je ne pense pas que tu aies d'autre choix que d'utiliser une solution basée sur SSH. Je pense que n'importe quelle solution sérieuse ne va pas s'occuper de la gestion de l'authentification (éventuellement juste imposer des restrictions supplémentaires): SSH a déjà tout ce qu'il faut avec l'authentification par clé RSA notamment. Mais si tu ne peux pas passer par cela, je pense que tu vas de toute façon devoir réécrire pas mal de choses.
Il n'y aucun pare-feu sur nos serveurs puisque nous sommes protégés par une boite noire (comprendre une boite pare-feu entre le monde extérieur et nous). Notre client l'a décidé ainsi, je n'ai pas mon mot à dire. re- :-(
Le jour où un pirate arrivera à passer la boîte noire, il risque d'avoir accès à tout un peu facilement.
Jeremy Monnet a écrit :
Merci pour vos réponses !
On 4/3/07, Vincent Lefevre vincent@vinc17.org wrote:
C'est certainement un peu hors sujet ici, mais vu le traffic relativement élevé de cette liste, je me permets de poster quand même. J'espère que vous ne m'en tiendrez pas rigueur :-)
Je ne pense pas que ce soit hors sujet.
Disons qu'on est plus dans le cadre du strict script shell :-)
On devrait peut-être migrer sur sysadmin@asyd.net ? :)
Bonjour,
Le 03.04.2007 20:38, Jeremy Monnet a écrit :
Comme pas mal d'entre nous je pense, je suis admin unix. Dans le cadre de mon travail je cherche à simplifier la gestion des serveurs, et pour cela, j'aurais besoin d'executer des commandes à distance, de façon programmée. Mettons un genre de serveur maitre, avec un "logiciel" qui soit capable de gérer des groupes et d'executer sur ces groupes de machines des commandes ou des scripts.
Comme je pense que d'autres ont déjà été confrontés à cette problèmatique, j'aimerais savoir comment vous l'avez résolue ?
Comme cahier des charges : peu ou pas d'installation sur la machine cliente (au pire un agent résident unique), et les normes du lieu nous interdisent les connexions ssh directement en root (on est obligé de passer par l'utilitaire calife).
Du moment que l'agent peut s'exécuter en tant que root, ça ne pose pas de problème, sinon pour le déploiement. Je ne sais pas quelles sont les limitations de calife par rapport à sudo.
Connaissez-vous des programmes (propriétaires ou non) qui répondent à cette problèmatique ?
Tu devrais regarder du côté de cfengine : http://www.cfwiki.org/cfwiki/index.php/Overview Il faut un peu de temps pour le mettre en place et pour prendre la mesure de l'outil, mais ça en vaut la peine.
Sinon, en beaucoup plus simple, il y a ClusterSSH (http://clusterssh.sourceforge.net/index.php/FAQ), mais ce n'est pas vraiment comparable.
On 4/4/07, Laurent Defours laurent.defours@laposte.net wrote:
Comme cahier des charges : peu ou pas d'installation sur la machine cliente (au pire un agent résident unique), et les normes du lieu nous interdisent les connexions ssh directement en root (on est obligé de passer par l'utilitaire calife).
Du moment que l'agent peut s'exécuter en tant que root, ça ne pose pas de problème, sinon pour le déploiement. Je ne sais pas quelles sont les limitations de calife par rapport à sudo.
calife demande le mot de passe de l'utilisateur pour lui permettre de passer root (en vérifiant que l'utilisateur est référencé dans /etc/calife.auth). Il ne source pas l'environnement de root => root par calife garde toute la config de l'utilisateur. Très important, calife est développé par une personne interne du centre (où je suis prestataire) ...
Jeremy
On 2007-04-04 09:47:02 +0200, Jeremy Monnet wrote:
calife demande le mot de passe de l'utilisateur pour lui permettre de passer root (en vérifiant que l'utilisateur est référencé dans /etc/calife.auth). Il ne source pas l'environnement de root => root par calife garde toute la config de l'utilisateur. Très important, calife est développé par une personne interne du centre (où je suis prestataire) ...
Euh... tu es obligé de taper le mot de passe de root sur *chaque* machine (vu que calife doit être exécuté à distance)?
D'autre part, garder la config de l'utilisateur, ce n'est pas terrible question sécurité. Une modif d'il y a un an dans sudo, à ce propos:
* Reworked the former patch to limit environment variables from being passed through, set env_reset as default instead [sudo.c, env.c, sudoers.pod, Bug#342948, CVE-2005-4158] * env_reset is now set by default * env_reset will preserve only HOME, LOGNAME, PATH, SHELL, TERM, DISPLAY, XAUTHORITY, XAUTHORIZATION, LANG, LANGUAGE, LC_*, and USER (in addition to the SUDO_* variables)
-
Clement Hermann -
David LUCAS -
Jeremy Monnet -
Jérôme Gaulin -
Laurent Defours -
Vincent Lefevre