Forum Programmation.shell execution d'un script local sur des machines distantes

Posté par linux35400 le 29 juin 2017 à 08:16. Licence CC By‑SA.

Étiquettes :

juin

2017

Bonjour,

Je viens vers vous pour un peu d'aide, j'ai développé un script pour une société qui permet d'avoir une météo du parc serveurs (états fs, verif des process principaux…)mon problème est que je ne trouve pas la solution pour l'executer depuis mon serveur de test sur les autres environnements, j'ai mis des clés ssh depuis mon serveur vers les serveurs clients mais à moins de déposer le script sur les serveurs et de les executer depuis mon serveur, je ne vois pas de solutions.

#!/bin/ksh
#
#--------------------------------------------------------------------------------------------
#
# Control_Matinal.sh : Verification FS/Process
#
# Usage     : Control_Matinal.sh
#
# Auteur: EF pour OAB
# 28 juin 2017
#--------------------------------------------------------------------------------------------
#Chemins
WAY=/home/SCRIPTS/control
hosts=`cat $WAY/hosts.conf`

#Mailing list
Email=""

#Rep log
log_date=`date +%Y%m%d`
host=`echo $HOSTNAME |sed -e "s/.INFRACMPPP.LOCAL//"`
fs_log=/tmp/fs.$host.log
FIC_LOG=$WAY/log_fin.$log_date.txt


fonction1 ()
{
        FS_BAD=0
        echo $host                                                                                              > $fs_log
        touch $fs_log
        for i in `df -k |awk '{print $4";"$NF}'| grep "%" | grep -v Used`
        do
        # Définition des variables internes et on attribue le bon format en supprimant le %
        taille=`echo $i | cut -d';' -f1 | sed -e "s/%//g"`
        nomfs=`echo $i | cut -d';' -f2`
        if [[  $taille -gt 30 ]]
                then
                        echo "ALERTE - Le Fs $nomfs est rempli à $taille %\n"                                   >> $fs_log
                      ((FS_BAD = $FS_BAD + 1))
                elif [[  $taille -gt 20 ]]
                then
                        echo "ATTENTION - Le Fs $nomfs est rempli à $taille %\n"                                >> $fs_log
                       ((FS_BAD = $FS_BAD + 1))
        fi
        done
        if [[ $FS_BAD -lt 1 ]]
        then
                echo " Les FileSystems ne posent pas de problemes "                                             >> $fs_log
        fi
}



fonction2 ()
{
        MSBAD=0
        REP=/etc/init.d
        STT=0
        echo "Liste des microservices sur $host\n"                                                              >> $fs_log
        echo "***************************************"                                                          >> $fs_log
        for i in `ls $REP/cloud*|sed -e "s/\/etc\/init.d\///g`
        do
        echo -n "$i: "                                                                                          >> $fs_log
        service $i status                                                                                       >> $fs_log
        STT=$?
                if [[ $STT -eq 3 ]]
                        then
                        echo "Le service $i ne tourne pas, veuillez le relancer" >> $fs_log
                        ((MS_BAD = $MS_BAD + 1))
                fi
        done
                 if [[ $MS_BAD -eq 0 ]]
                        then    echo "Les services sont fonctionnels"                                            >> $fs_log
                fi

}


func_mail ()
{
cat ${FIC_LOG} | mailx -s "Rapport Controle Matinal" $EmailOrange
}


Menu ()
{
echo "choix 1 ou 2:\n"
read reponse
case $reponse in
1)fonction1;;
2)fonction2;;
*)echo "fonction a mettre en place";;
esac
}



#Main


Menu

#for host in $hosts
#do
ssh root@$host 'bash -s'< df -k |awk '{print $4";"$NF}'| grep "%" | grep -v Used
#ssh root@$host < fonction2
#scp root@$host:$fs_log $fs_log
#done

cat $fs_log >> $FIC_LOG
rm -f $fs_log
func_mail
exit 0

# Possible

Posté par ʭ ☯ le 29 juin 2017 à 11:53. Évalué à 2.

Il te faut lancer un wget qui va chercher le script et l'exécute à la volée, mais je ne vois pas bien l'intérêt de ne pas déposer le script sur les serveurs où tu veux le lancer.

⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# 2 possibilités

Posté par NeoX le 29 juin 2017 à 13:02. Évalué à 3.
Solution A :
envoyer le fichier avant son execution :
scp tonscript user@serversuivi d'un ssh user@server tonscript

Solution B :
reecrire le script pour changer tous tes appels ls $DOSSIER
command X
command Y

par
```
ssh user@server ls $DOSSIER
ssh user@server command X
ssh user@server command Y
```
note que du coup ton script pourrait prendre 2 variables :
- METHOD
- DEST

et devenir
```
$METHOD $DEST ls $DOSSIER
$METHOD $DEST command X
$METHOD $DEST command Y
```
ainsi si tu l'appelles avec des options, tu peux definir s'il doit s'executer en local ou à distance

tonscript.sh fera une exuction local
tonscript.sh ssh use@server pour une execution distante
- [^] # Re: 2 possibilités
  
  Posté par Jehan (site web personnel, Mastodon) le 29 juin 2017 à 14:08. Évalué à 3.
  
  ssh user@server ls $DOSSIER
  ssh user@server command X
  ssh user@server command Y
  
  À chaque commande, il va recréer une connexion, j'imagine (à moins qu'il y ait une logique dans ssh pour ne pas fermer une connexion immédiatement à la fin de la commande, mais après un timeout, pour pouvoir la réutiliser; mais j'en doute fortement; pour cela d'une il faudrait un daemon côté client aussi, de deux, ce serait une faille de sécurité potentielle donc ne devrait être accessible que par option). Donc déjà ça va rallonger la durée du script (pour un script court et des machines dans un réseau local, pas forcément de beaucoup, certes).
  
  Mais surtout cela veut dire que ça recrée un nouvel environnement à chaque commande, donc toutes les variables d'environnement créées précédemment seront perdues.
  Alors ça reste faisable en mettant toutes les variables d'environnement au début de chaque commande (et non d'en faire des commandes elle-même).
  
  PLOP=value PLIP=value2 command
  
  Sauf que ça ne marchera pas lorsque tu utilises les variables directement dans la ligne de commande (car le shell les transforme sans prendre en compte la ligne de commande), ex:
  
  PLOP=value echo $PLOP
  
  Ne marchera pas. Tu voudras faire à la place (par exemple si ton shell est bash):
  
  PLOP=value bash -c 'echo $PLOP'
  
  Pareil lorsqu'il y a des pipes, etc.
  Mais franchement, je trouve que c'est se compliquer la vie pour pas grand chose. En gros, je prendrais la solution A: envoie le script sur le serveur juste avant l'exécution et exécute le en local.
  
  Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
  - [^] # Re: 2 possibilités
    
    Posté par linux35400 le 29 juin 2017 à 16:57. Évalué à 1.
    
    merci, effectivement, je ne trouve pas de solutions sur le net, déployer le script sur l'ensemble du parc et de l’exécuter à distance semble être la seule solution, plutôt galère pour un script qui est censé évoluer assez souvent et qui doit être amené à faire le boulot sur un parc info
    - [^] # Re: 2 possibilités
      
      Posté par kna le 30 juin 2017 à 11:24. Évalué à 2.
      
      Ben il faudra juste repousser ton script si tu le modifies. Tu peux faire ça avec un autre script (qui pousse le script sur les machines et l'exécute) ou avec un outil de déploiement type ansible.
    - [^] # Re: 2 possibilités
      
      Posté par ckiller le 30 juin 2017 à 13:18. Évalué à 1.
      
      ou sinon, on arrête le bricolage et tu déploie un truc genre ocs inventory
      - [^] # Re: 2 possibilités
        
        Posté par ComputingFroggy (site web personnel) le 01 juillet 2017 à 15:39. Évalué à 2.
        
        Je plussois !
        J'aime bien aussi écrire des scripts, mais là, il y a des outils qui existent dont OCS inventory : pourquoi ne pas l'utiliser sans avoir à ré-inventer la roue ?
      - [^] # Re: 2 possibilités
        
        Posté par Michaël (site web personnel) le 24 août 2017 à 11:36. Évalué à 2.
        
        Ou on utilise ssh parce que c';est à ça que ça sert. :) Qu'est-ce qui ne va pas avec la solution
        
        ssh monhost < monscript.sh
        
        On peut difficilement faire plus simple, non?
  - [^] # Re: 2 possibilités
    
    Posté par Prosper le 29 juin 2017 à 18:03. Évalué à 3.
    
    À chaque commande, il va recréer une connexion, j'imagine (à moins qu'il y ait une logique dans ssh pour ne pas fermer une connexion immédiatement à la fin de la commande, mais après un timeout, pour pouvoir la réutiliser; mais j'en doute fortement; pour cela d'une il faudrait un daemon côté client aussi, de deux, ce serait une faille de sécurité potentielle donc ne devrait être accessible que par option). Donc déjà ça va rallonger la durée du script (pour un script court et des machines dans un réseau local, pas forcément de beaucoup, certes).
    
    https://developer.rackspace.com/blog/speeding-up-ssh-session-creation/
    https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing
    - [^] # Re: 2 possibilités
      
      Posté par Jehan (site web personnel, Mastodon) le 30 juin 2017 à 13:17. Évalué à 2.
      
      Comme je m'imaginais, ça existe donc sous forme d'option explicite, avec des limites, et surtout ils ont remplacé mon hypothèse d'un daemon par une autre connexion ssh normale, préexistante (celle-ci joue donc le rôle d'un daemon).
      Cela m'a donc l'air peu pratique. :-/
      
      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# envoyer le script sur l'entrée standard de /bin/sh via ssh ?

Posté par nullard3d le 29 juin 2017 à 15:25. Évalué à 4.
```
cat script.sh | ssh remote.host.com /bin/sh
```
Peut-être impossible avec ksh, je n'ai pas d'environnement sous la main pour tester.
- [^] # Re: envoyer le script sur l'entrée standard de /bin/sh via ssh ?
  
  Posté par freem le 30 juin 2017 à 13:33. Évalué à 2.
  
  Je plussoie, sauf pour le cat, une redir avec < me semble plus appropriee. Sinon au pire, un appel inverse:
  
  ssh foo "ssh orig mon_script.sh"
  
  devrait rouler aussi.
- [^] # Re: envoyer le script sur l'entrée standard de /bin/sh via ssh ?
  
  Posté par Michaël (site web personnel) le 24 août 2017 à 11:10. Évalué à 2.
  Useless use of cat detected! :)
```
ssh remote.host.com /bin/sh < script.sh
```
# sinon, eviter de reinventer la poudre

Posté par NeoX le 29 juin 2017 à 17:11. Évalué à 5.

il y a SNMP qui permet de remonter un certain nombre d'indicateur de tes machines distantes, sans te connecter dessus pour executer des scripts,

ainsi tu scriptes sur ton serveur principal l'interrogation SNMP, le control des valeurs et l'alerting,
il te faut juste installer et configurer le service net-snmp sur tes machines distantes (wmi-snmp pour les windows)

et si tu veux vraiment executer des scripts, regarde du coté de NRPE, qui permet l'envoie d'un script, son execution et la recuperation des resultats.
- [^] # Re: sinon, eviter de reinventer la poudre
  
  Posté par linux35400 le 29 juin 2017 à 20:04. Évalué à 1.
  
  j'irai voir du coté SNMP
# Données privées

Posté par Marotte ⛧ le 29 juin 2017 à 18:26. Évalué à 2.

Je serais toi j’aurais anonymisé le script en retirant l’email (peut-être l’as tu modifié ?) et « OAB »… Orange Business Service ou bien Observatoire Agricole de la Biodiversité ? Je penche bien sûr pour le premier, au vue de l’adresse mail.

Ne travaillerais-tu pas dans la galerie marchande du Carrouf de St-Malo ? ;)
- [^] # Re: Données privées
  
  Posté par linux35400 le 29 juin 2017 à 20:01. Évalué à 2.
  
  lol bien vu pour orange mais non, je ne suis pas vendeur, je suis intégrateur applicatif
# .

Posté par ohm le 29 juin 2017 à 23:47. Évalué à 3.
Je ne sais pas si j'ai bien compris la question, mais tu peux exécuter un script local sur une machine distante avec bash ainsi (doit être similaire avec ksh) :
```
ssh serveur_distant "bash -s" < ./script_local
```
- [^] # Re: .
  
  Posté par Kangs le 30 juin 2017 à 16:50. Évalué à 1.
  
  Violent ton truc !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.