fatmawati achmad zaenuri/Shutterstock.com
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 script local sur un ordinateur distant ? 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, garder à jour et à jour la copie de chaque script sur chaque serveur est pénible et fastidieux. 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
Sur notre machine locale, nous allons lancer le script comme ceci :
ssh dave@fedora-36.local 'bash -s' < local.sh
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"
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
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’une é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 sont envoyées 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
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.