Comment utiliser set et pipefail dans les scripts Bash sous Linux
Agence web » Actualités du digital » Comment exécuter un script local sur un serveur Linux distant

Comment exécuter un script local sur un serveur Linux distant

La création de scripts de tâches répétitives améliore l’efficacité de l’administration système. C’est très bien pour les machines locales, mais que se passe-t-il si vous supervisez des serveurs distants ? Pouvez-vous exécuter un local scénario sur un télécommande l’ordinateur? Oui!

Connexions à distance

L’administration du système à distance implique généralement d’établir une connexion à l’ordinateur distant via un ssécurisé shbonne connexion. La connexion SSH vous fournit une invite de commande sur l’ordinateur distant. Vous pouvez ensuite continuer et effectuer la maintenance du système requise.

Les scripts Shell vous aident en vous permettant d’encapsuler une séquence de commandes dans un script qui peut être exécuté comme s’il s’agissait d’un programme, combinant de nombreuses actions en une seule instruction de ligne de commande.

Au fil du temps, vous peaufinerez et améliorerez vos scripts. Si vous avez de nombreuses machines distantes à administrer, la mise à jour et la mise à jour de la copie de chaque script sur chaque serveur est pénible et fastidieuse. Cela devient une tâche administrative en soi et ronge le gain de temps que l’utilisation de scripts est censée apporter.

La solution idéale vous permettrait de conserver vos scripts sur votre ordinateur local et de les exécuter sur les ordinateurs distants via la connexion SSH. Cela vous donnerait une gestion simplifiée avec une collection centralisée de scripts, et le même script à jour s’exécute sur tous les ordinateurs.

Bash et SSH fournissent un moyen de le faire.

Connexions SSH sans mot de passe

La meilleure façon de le faire est d’utiliser des connexions sans mot de passe, en utilisant des clés SSH. En générant des clés SSH sur votre ordinateur local et en les envoyant à chacun des ordinateurs distants, vous pouvez vous connecter aux ordinateurs distants de manière sécurisée et pratique, sans être invité à saisir un mot de passe à chaque fois.

Bien qu’elles puissent être intimidantes pour les nouveaux utilisateurs, les clés SSH ne sont vraiment pas difficiles. Ils sont faciles à générer, simples à installer sur les serveurs distants et sans friction lorsque vous les utilisez avec SSH. Les seuls prérequis sont que les ordinateurs distants disposent du démon SSH sshd en cours d’exécution et que vous disposez d’un compte utilisateur sur l’ordinateur distant.

Si vous effectuez déjà une administration système à distance sur eux, ces deux exigences doivent déjà être satisfaites.

Pour générer une paire de clés SSH, tapez :

ssh-keygen

Si vous avez un compte appelé « dave » sur un ordinateur appelé « fedora-36.local », vous pouvez lui envoyer et installer votre clé publique SSH avec cette commande :

ssh-copy-id dave@fedora-36.local

Maintenant, établir une connexion SSH de la manière habituelle s’authentifiera à l’aide des clés SSH. Vous êtes déposé sur une invite de commande sur le serveur distant sans être invité à entrer un mot de passe.

ssh dave@fedora-36.local

Exécuter un script local à distance

Pour ces tests, notre serveur distant est un ordinateur Linux appelé « fedora-36.local ». Nous avons mis en place des clés SSH et nous avons testé notre connexion sans mot de passe au serveur distant depuis notre ordinateur local.

Notre scénario est très simple. Il écrit un horodatage dans un fichier appelé « timestamp.txt », sur le serveur distant. Notez que le script se termine par la commande exit. Ceci est important, sur certains systèmes plus anciens, il est possible qu’un script s’exécute jusqu’à la fin, mais la connexion SSH est maintenue ouverte.

#!/bin/bash

date >> timestamp.txt

exit 0

Copiez ce texte dans un éditeur, enregistrez-le sous « local.sh », puis utilisez chmod pour le rendre exécutable.

chmod +x local.sh

Utiliser chmod pour rendre un script exécutable

Sur notre machine locale, nous allons lancer le script comme ceci :

ssh dave@fedora-36.local 'bash -s' < local.sh

lancement d'un script local à exécuter sur un serveur distant via SSH

Voici comment cela fonctionne.

  • ssh dave@fedora-36.local: La connexion SSH que nous établissons avec la machine distante. Celui-ci utilise le ssh commande, le compte d’utilisateur préexistant sur le serveur distant et l’adresse du serveur distant.
  • ‘bash -s’: cela amène Bash à lire les commandes à partir du flux d’entrée standard. Il permet à Bash de lire les entrées redirigées ou redirigées.
  • < local.sh: Nous redirigeons le script vers Bash.

Lorsque le script s’exécute, nous sommes renvoyés à l’invite de commande de la machine locale. En sautant sur notre machine distante, nous pouvons utiliser cat pour regarder à l’intérieur du fichier « timestamp.txt ».

cat timestamp.txt

Nous pouvons voir l’horodatage de la dernière (et actuellement unique) connexion. L’exécution du script local plusieurs fois ajoute les horodatages correspondants au fichier distant.

cat timestamp.txt

Bien sûr, dans une situation réelle, votre script ferait quelque chose de plus utile. Mais même notre exemple trivial démontre qu’un script local est exécuté sur un serveur distant.

Passer des arguments au script

Vous pouvez transmettre des arguments de ligne de commande au script. Nous allons modifier notre script pour attendre trois paramètres de ligne de commande. Ceux-ci sont redirigés vers le fichier « timestamp.txt » avec l’horodatage.

Enregistrez ce script sous « local2.sh », et rendez-le exécutable avec chmod.

#!/bin/bash

echo "$1 $2 $3" >> timestamp.txt
date >> timestamp.txt

exit 0

La commande que nous devons utiliser est similaire à l’exemple précédent, avec quelques modifications.

ssh dave@fedora-36.local "bash -s" -- < local2.sh "How-To Geek" "Linux" "Articles"

lancement d'un script local avec des paramètres de ligne de commande à exécuter sur un serveur distant via SSH

Le double trait d’union « -- » indique à Bash que ce qui suit ne doit pas être considéré comme des paramètres de ligne de commande pour le ssh commande. Les trois paramètres du script suivent le nom du script, comme d’habitude. Notez que nous avons utilisé une barre oblique inverse « » pour échapper à l’espace dans le paramètre « How-To Geek ».

Nous pouvons vérifier avec cat que nos paramètres ont été reçus et gérés correctement sur le serveur distant.

cat timestamp.txt

Vérifier que les paramètres du script ont été reçus et traités correctement sur le serveur distant

Exécuter une section d’un script à distance

Si vous avez un script qui doit effectuer un traitement local afin de déterminer quelles actions pourraient être requises sur les serveurs distants, vous pouvez ajouter une section directement dans ce script pour effectuer les actions à distance pour vous.

Nous pouvons y parvenir en utilisant ici des documents. Ici, les documents nous permettent de rediriger les lignes d’une section étiquetée d’un script vers une commande. Le traitement local peut être effectué au-dessus et au-dessous du document ici.

Il s’agit du script « local3.sh », qui contient un document ici.

#!/bin/bash

# local processing can done here

# remote processing is done here
ssh -T dave@fedora-36.local << _remote_commands

# commands to be run remotely would be added here
cd /home/dave/Documents
# etc.

# Finally, update the timestamp file
echo "Script3.sh:" $(date) >> /home/dave/timestamp.txt

# this is the label that marks the end of the redirection
_remote_commands

# more local processing can be done here

exit 0

Nous utilisons le ssh commande avec les mêmes détails de connexion qu’auparavant. Nous nous connectons en tant qu’utilisateur « dave » sur un serveur distant appelé « fedora-36.local ». Nous utilisons également le -T (désactiver l’allocation de pseudo-terminal). Cela empêche le serveur distant de fournir une borne interactive pour cette connexion.

La redirection »<<» est suivi du nom d’un étiquette. Dans cet exemple, nous utilisons « _remote_commands ». Il n’y a rien de spécial dans ce label, c’est simplement un label.

Toutes les commandes qui apparaissent sur les lignes Suivant la redirection est envoyée via la connexion SSH. La redirection s’arrête lorsque l’étiquette est rencontrée. L’exécution du script se poursuit alors avec la ligne suivant le label.

Exécutons notre script de traitement mixte local/distant.

./local3.sh

Lancement de script3.sh avec un mélange de traitement local et distant

Comme prévu, nous voyons une nouvelle entrée dans le fichier « timestamp.txt ».

cat timestamp.txt

Étendez votre portée

La possibilité d’exécuter des scripts à distance, qui sont écrits, stockés et maintenus localement, fournit un outil d’administration pratique. Savoir qu’exactement la même version d’un script s’exécute sur tous vos serveurs distants facilite grandement la gestion.

★★★★★