[résolu] Mise à jour et eteindre postes en ssh

temps · Le 19/05/2015, à 09:25

Bonjour,
J'ai commencé un petit code en bash pour faire la mise à jour et eteindre une série de postes à distance.

#! /usr/bin/expect -f
set timeout 5

# rendre le code executable : chmod +x eteind-18.sh

# le diese est un commentaire

# l'adresse des postes 

set poste1 "p1@172.16.254.1"
set poste2 "p2@172.16.254.2"
set poste3 "p3@172.16.254.3"
set poste4 "p4@172.16.254.4"
set poste5 "p5@172.16.254.5"
set poste6 "p6@172.16.254.6"
set poste7 "p7@172.16.254.7"
set poste8 "p8@172.16.254.8"
set poste9 "p9@172.16.254.9"
set poste10 "p10@172.16.254.10"
set poste11 "p11@172.16.254.11"
set poste12 "p12@172.16.254.12"
set poste13 "p13@172.16.254.13"
set poste14 "p14@172.16.254.14"

#tableau1=( poste1 poste2 poste3 poste4 poste5 poste6 poste7 poste8 poste9 poste10 poste11 poste12 poste13 poste14 )

#ssh <nom_utilisateur>@<ipaddress>

#ssh 1

#for i in `seq 0 23`;
#    ssh $tableau1
#done

set pw "mon_mot_passe"

spawn ssh $poste1
expect "$poste1\'s password:"
send "$pw\r"
expect "#"
send "sudo apt-get update"
send "\n"
send "mon_mot_passe"
send "\n"
expect "#"
send "sudo apt-get upgrade"
send "\n"
expect "#"
send "y"
send "\n"
expect "#"
send "sudo poweroff"
send "\n"
interact

Avant de créer la boucle de manière à éviter les répétitions, j'ai testé.
Et je me suis aperçu, que le code ne fonctionne que si il n'y a pas d'upgrade d'effectués.
Si il y a un upgrade, celui-ci se déroule bien, mais le code reste bloqué après l'upgrade sans fermer le poste.
Est-ce que quelqu'un comprend pourquoi ?
Cordialement

Dernière modification par temps (Le 21/05/2015, à 11:13)

temps · Le 19/05/2015, à 10:21

Bonjour,
Actuellement je vois une solution pour éviter le problème.
C'est tout simplement de créer 2 bash, l'un pour la mise à jour l'autre pour éteindre.
Je pense que le problème est lié au timeout, trop long l'application prendrait des heures selon le nombre de poste, trop court j'obtiens cet effet.
De plus je me suis apperçu que l'initialisation des tableau avec expect, était différente de l'initialisation avec un simple bash,
il faut que je regarde les tableaux d'un peu plus près.

Cordialement

tiramiseb · Le 19/05/2015, à 13:52

Houla, tu te compliques énormément la vie !

Voici ce que je ferais :

1/ définir les hôtes dans le fichier .ssh/config au lieu de faire des variables propres au script

Host poste1
    User p1
    HostName 172.16.254.1

Host poste2
    User p2
    HostName 172.16.254.2
[...]

Déjà, là ça te permettra de faire "ssh poste1" ou "ssh poste2" de n'importe où et pas seulement de ton script

2/ faire une authentification par clé SSH

D'abord tu génères une paire de clés SSH avec la commande :

ssh-keygen

Ensuite tu transfères la clé privée :

ssh-copy-id poste1

À partir de là :
- soit tu as créé une clé avec phrase de passe, auquel cas la phrase de passe n'est demandée qu'une fois (grâce à l'agent SSH qui tourne par défaut sur le système) ;
- soit tu as créé une clé sans phrase de passe (c'est ce que je fais pour les manips automatiques), auquel cas ça se connecte sans rien demander, jamais

3/ ton script devient alors simplement quelque chose comme :

#!/bin/sh
for p in poste1 poste2 poste3 poste4 poste5 poste6 poste7 poste8 poste9 poste10 poste11 poste12 poste13 poste14
do
  ssh $p sudo apt-get update
  ssh $p sudo apt-get upgrade
  ssh $p sudo poweroff
done

Dernière modification par tiramiseb (Le 19/05/2015, à 13:53)

temps · Le 19/05/2015, à 14:12

Bonjour,
merci pour la réponse.
J'ai huit zones de P.C. distants
J'ai déjà équipés les postes d'une clef que j'utilise pour ajouter des documents à distance à l'aide d'un bash que j'appelle grace à un code en langage C

...
scp $1 $poste1:/home/$lieu1/Desktop
scp $1 $poste2:/home/$lieu2/Desktop
scp $1 $poste3:/home/$lieu3/Desktop
scp $1 $poste4:/home/$lieu4/Desktop
#scp $1 $poste5:/home/$lieu5/Desktop
scp $1 $poste6:/home/$lieu6/Desktop
scp $1 $poste7:/home/$lieu7/Desktop
scp $1 $poste8:/home/$lieu8/Desktop
scp $1 $poste9:/home/$lieu9/Desktop
scp $1 $poste10:/home/$lieu10/Desktop
scp $1 $poste11:/home/$lieu11/Desktop
scp $1 $poste12:/home/$lieu12/Desktop
scp $1 $poste13:/home/$lieu13/Desktop
scp $1 $poste14:/home/$lieu14/Desktop
scp $1 $poste15:/home/$lieu15/Desktop
scp $1 $poste16:/home/$lieu16/Desktop
scp $1 $poste17:/home/$lieu17/Desktop
scp $1 $poste18:/home/$lieu18/Desktop
scp $1 $poste19:/home/$lieu19/Desktop
scp $1 $poste20:/home/$lieu20/Desktop
scp $1 $poste21:/home/$lieu21/Desktop
scp $1 $poste22:/home/$lieu22/Desktop
scp $1 $poste23:/home/$lieu23/Desktop
scp $1 $poste24:/home/$lieu24/Desktop

La seule différence avec le dernier code c'est que je n'ai pas besoin d'expect, et que j'ai ajouté le nom dans $lieu et encore $1 récupère la vidéo ou autre placé derrière

J'ai cherché dans cette voie car quand je me connecte en terminal, la clef qui fonctionne bien en scp n'apparait pas, et je suis obligé de m'identifier
Je vais regarder un peu plus dans ce sens.

Je précise que le poste de travaille fonctionne avec openVPN (pour être piloté à distance) et n'est pas celui qui a servit à créer la clé.
Je vais aussi ajouter une deuxième clé générée avec le poste de travail, peut-être que le problème vient de là. De toute façon, il restera le mot de passe de la clé.

Cordialement

Dernière modification par temps (Le 19/05/2015, à 15:42)

temps · Le 19/05/2015, à 15:49

Bonjour,
En retour d'info après un premier test par clé.

J'ai créé une nouvelle clé sur le poste de travail, que j'ai ajouté au serveur
Quand je test le bash, j'obtiens

sudo: no tty present and no askpass program specified

tiramiseb · Le 19/05/2015, à 15:58

Il faut que sudo autorise l'utilisateur à exécuter ces commandes sans taper de mot de passe.

maxire · Le 19/05/2015, à 16:21

Salut,

Il me semble qu'une confirmation est demandée pour exécuter un apt-get upgrade, je me demande si une option -y ne serait pas la bienvenue en plus d'autoriser l'utilisateur distant à exécuter sudo sans mot de passe pour apt-get.

tiramiseb · Le 19/05/2015, à 16:23

Il me semble qu'une confirmation est demandée pour exécuter un apt-get upgrade, je me demande si une option -y ne serait pas la bienvenue

Tu as raison.

tiramiseb · Le 19/05/2015, à 16:35

temps: en fait, je pense que c'est ton approche qu'il faut changer.

ton idée actuellement, c'est « j'automatise ce que je fais habituellement à la main (entrer des commandes, des mots de passe, etc) », donc utilisation d'expect.
une approche plus efficace, que nous on te propose, c'est « je trouve les bonnes commandes et configurations pour que ça ne demande jamais rien », donc utilisation de clés SSH, sudo sans mot de passe, argument "-y", etc.

Dernière modification par tiramiseb (Le 19/05/2015, à 16:36)

temps · Le 19/05/2015, à 17:08

Bonjour,

J'avais compris, en regardant mieux la possibilité des clé que j'avais mis de coté.
Pour l'instant, je suis dans des phases de test.
J'ai mis une première technique au point qui fonctionne. C'est juste pour assurer un résultat.
Une multitude de répertoire contenant un bash pour chaque acte, et ceici encore pour chaque poste. Le tout au final appelé avec un seul bash que je pourrai reprendre en langage C.
Que du copier/coller depuis tout à l'heure. Mais j'ai un secours bien lourd.
Demain, je regarde la technique avec les clé et comment améliorer les codes en cas d'imprévu (poste éteind, ou autre ...)

Cordialement

maxire · Le 19/05/2015, à 17:14

Il peut tout de même parfois, disons très rarement, exister un dialogue initié par debconf lors de la mise à jour de certains paquets (confirmation, comparaison d'un nouveau fichier de configuration avec l'ancien,...).
Et là pas de gestion automatique, il faudrait pouvoir détecter ces cas et les signaler.

Donc les maj auto c'est bien mais il faut être conscient de leurs limites.

tiramiseb · Le 19/05/2015, à 17:16

maxire : dans l'absolu oui, cela étant dit pour les mises à jour "habituelles", sans changement de version de l'OS et uniquement avec les dépôts officiels, cela ne devrait pas arriver.

Quoi qu'il en soit, il est nécessaire de superviser ces mises à jour pour s'assurer que tout se passe bien !

maxire · Le 19/05/2015, à 17:35

tiramiseb, ces dialogues sont effectivement très peu probables, à vrai dire je ne me souviens pas en avoir rencontré en dehors de mise à niveau ou de l'installation de versions de paquets hors dépôts officiels.

C'est juste pour mettre en avant la nécessité d'écrire un outil de supervision des mises à jours et ce n'est pas nécessairement le plus évident à réaliser.
Comme je suppose que temps met en place ce système de mise à jour au sein d'une association ou d'une entreprise, mieux vaut qu'il soit au carré avec ça.

temps · Le 19/05/2015, à 19:20

Bonsoir,
Si la partie allumage ou injection de document est prévue pour plusieurs utilisateurs,
la partie maintenance et mise à jour, m'est réservé.
En d'autres mots, je serai le seul à utiliser l'outil sur le site.
D'expérience j'ai paramétré les mises à jour de sécurité en automatique sur chaque poste il y a plusieurs années, et cela ne m'a jamais induit de bug.
J'allume les postes avec un wakeonlan, et je les éteints le soir avec cron sur chaque poste.
Quand j'aurai fini le déploiement, j'indiquerai les codes et les techniques utilisées sur le fil.
Cordialement

temps · Le 20/05/2015, à 11:24

Bonjour,
En premier je vais déployer la technique qui va éviter la demande de mot de passe pour éteindre ou mettre à jour.
J'ai procèdé avec visudo

sudo visudo

Ensuite dans le fichier qui s'ouvre, pour l'utilisateur nommé P1 , j'ai entré à la fin du fichier cette ligne

%p1 ALL = NOPASSWD: /usr/lib/klibc/bin/poweroff, /usr/bin/apt-get update, /usr/bin/apt-get upgrade

Comme chaque poste possède un utilisateur différent, j'en ai pour un moment pour déployer tout ça.
Je reviendrai après, voir s'il est possible de garder une clé avec un mot de pass

Cordialement

P.S.
Je sais pas si j'ai pris le bon poweroff, parceque là c'est violent, si quelqu'un a une idée sur un emplacement moins brutal je suis preneur.

Dernière modification par temps (Le 20/05/2015, à 11:36)

tiramiseb · Le 20/05/2015, à 12:00

J'ai procèdé avec visudo
[...]

Ton approche me semble tout à fait bonne, modulo le chemin vers "poweroff", cf ci-dessous.

P.S.
Je sais pas si j'ai pris le bon poweroff, parceque là c'est violent, si quelqu'un a une idée sur un emplacement moins brutal je suis preneur.

Pour savoir lequel est utilisé quand tu tapes juste "poweroff", tu peux utiliser la comande "which" :

$ which poweroff
/sbin/poweroff

bruno · Le 20/05/2015, à 13:09

Bonjour,

Je ne critique nullement le travail effectué mais il existe déjà un outil formidable pour automatiser l'administration à distance de postes multiples via ssh : ansible

tiramiseb · Le 20/05/2015, à 13:12

bruno: en effet, il est important de le mentionner.

Disons que s'il s'agit juste de faire un "update+upgrade+poweroff", du script c'est très bien.

Mais si on parle d'administration au sens global, alors il vaut mieux ce genre d'outils, oui.

temps · Le 20/05/2015, à 14:21

Bonjour,
Merci pour le chemin de poweroff, celui là est beaucoup plus doux, l'autre à l'accent d'un coup de marteau.
j'ai trouvé le premier en faisant un find sur la racine sans chercher plus loin.

Au sujet d'ansible, merci, je testerai plus tard mais à priorie je répond depuis des années à l'obligation de résultat, et le terme administrateur n'a pas de sens sortie de cette obligation. Des informations inutiles ne serait qu'une perte de temps (qui fait quoi, ou autre). J'ai créé un petit code qui me dit si les postes sont fonctionnelles, et cela suffit de par leur raison d'être. Je travaille pas dans une banque, ou pour un système parano, j'essaie juste d'apporter le meilleur outil possible. Et meilleur outil possible, c'est celui qu'on utilise sans réfléchir, d'une manière fiable, un qui laisse les utilisateur réaliser leurs besoins sans contrainte, ou croyances.
Cordialement

tiramiseb · Le 20/05/2015, à 15:36

temps: tu as créé des bouts de code, que tu dois maintenir de ton côté. L'intérêt d'Ansible, c'est de n'avoir pas à maintenir le truc toi-même.

Ça semble justement être le genre d'outil dont tu as besoin.
Si tu dois enfoncer des clous, soit tu vas à la fonderie pour fabriquer ton outil perso, soit tu achètes un marteau. La 2nde possibilité est plus simple.
Il ne s'agit ni de contrainte, ni de croyance : il s'agit du choix du bon outil.

j'essaie juste d'apporter le meilleur outil possible

Alors essaie Ansible.

Je travaille pas dans une banque, ou pour un système parano

Quel est le rapport ? On doit travailler pour une banque pour pouvoir utiliser un logiciel efficace ?

temps · Le 20/05/2015, à 16:03

Bonjour,
Je ne voudrai pas que le fil parte hors sujet, mon objectif est d'essayer d'automatiser tout en gardant les outils dans la main.
Si je connais les outils, je pourrai les adapter et aussi être réactif.
Je ne compte plus les outils que j'ai du abandonner ou encore utiliser par période.
Je n'ai rien contre Ansible, j'ai d'ailleur dit que j'allais le tester plus tard.
Actuellement je joue avec les différentes techniques, et si j'ai employé des mots trop fort,
c'est en réaction par rapport à des expériences personnelles (j'ai peur de ceux qui présentent la solution qui fait tout "et qui presque toujours ne fait rien de bien").
J'entends le terme administration bien différement qu'il est souvent présenté.
Actuellement je déploie le visudo, j'ajoute les clés, je teste, je corrige ou améliore mes codes ...
Je ne cherche pas un outil tout fait qui pense comment les choses doit être faite, je cherche à pouvoir créer mon outil, un luxe de tux peut-être, mais ça me plait de ne pas suivre la pensée établit.
Cordialement

temps · Le 21/05/2015, à 11:12

Bonjour,

Merci pour les réponses, je poste en résolu.
Pour les outils fournit aux utilisateurs intermédiares (ceux qui dirigent les utilisateurs derrière les écrans)
Au bilan, des bash pilotés en langage C, pour injecter des documents, pour allumer les postes, pour éteindre les postes
Pour l'administration des mises à jours et autres
Au bilan, ansible est un meilleur choix.
En gardant les taches déjà plainifiées dans cron comme éteindre les postes tous les jours à telle heure.

Cordialement

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 19/05/2015, à 09:25

[résolu] Mise à jour et eteindre postes en ssh

#2 Le 19/05/2015, à 10:21

Re : [résolu] Mise à jour et eteindre postes en ssh

#3 Le 19/05/2015, à 13:52

Re : [résolu] Mise à jour et eteindre postes en ssh

#4 Le 19/05/2015, à 14:12

Re : [résolu] Mise à jour et eteindre postes en ssh

#5 Le 19/05/2015, à 15:49

Re : [résolu] Mise à jour et eteindre postes en ssh

#6 Le 19/05/2015, à 15:58

Re : [résolu] Mise à jour et eteindre postes en ssh

#7 Le 19/05/2015, à 16:21

Re : [résolu] Mise à jour et eteindre postes en ssh

#8 Le 19/05/2015, à 16:23

Re : [résolu] Mise à jour et eteindre postes en ssh

#9 Le 19/05/2015, à 16:35

Re : [résolu] Mise à jour et eteindre postes en ssh

#10 Le 19/05/2015, à 17:08

Re : [résolu] Mise à jour et eteindre postes en ssh

#11 Le 19/05/2015, à 17:14

Re : [résolu] Mise à jour et eteindre postes en ssh

#12 Le 19/05/2015, à 17:16

Re : [résolu] Mise à jour et eteindre postes en ssh

#13 Le 19/05/2015, à 17:35

Re : [résolu] Mise à jour et eteindre postes en ssh

#14 Le 19/05/2015, à 19:20

Re : [résolu] Mise à jour et eteindre postes en ssh

#15 Le 20/05/2015, à 11:24

Re : [résolu] Mise à jour et eteindre postes en ssh

#16 Le 20/05/2015, à 12:00

Re : [résolu] Mise à jour et eteindre postes en ssh

#17 Le 20/05/2015, à 13:09

Re : [résolu] Mise à jour et eteindre postes en ssh

#18 Le 20/05/2015, à 13:12

Re : [résolu] Mise à jour et eteindre postes en ssh

#19 Le 20/05/2015, à 14:21

Re : [résolu] Mise à jour et eteindre postes en ssh

#20 Le 20/05/2015, à 15:36

Re : [résolu] Mise à jour et eteindre postes en ssh

#21 Le 20/05/2015, à 16:03

Re : [résolu] Mise à jour et eteindre postes en ssh

#22 Le 21/05/2015, à 11:12

Re : [résolu] Mise à jour et eteindre postes en ssh

Pied de page des forums