[HS ?] execution programmée de commandes a distance

Vincent Lefevre vincent at vinc17.org
Wed Apr 4 13:55:30 CEST 2007


On 2007-04-04 09:43:48 +0200, Jeremy Monnet wrote:
> On 4/3/07, Vincent Lefevre <vincent at 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. »

-- 
Vincent Lefèvre <vincent at vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


More information about the Shell mailing list