Déploiement d’applications sur Raspbian

Bonjour la communauté.

Je viens vers vous car je suis face à une problématique.
Dans l’école de mon enfant, la directrice souhaite installer des équipements informatiques.
Afin que la commune puisse assumer cette dépense, j’ai proposé l’installation de Rpi pour leur côté pédagogique, ludique et peu onéreux. Pour ma part, j’aide à l’installation.
Pour l’architecture réseau, 5 Raspberry Pi « élèves » seront raccordées à un switch.
Une 6ème carte servira a faire un « NAS » afin de centraliser le travail des élèves.
Sur cette 6ème carte, sera également installé un VPN, afin que je puisse faire les manipulation en SSH pour les MAJ / Installations/etc.

Existe-il un moyen d’envoyer une commande en SSH à l’ensemble des 5 Raspberry Pi « élèves » afin qu’elles se mettent toutes à jour ou de faire du déploiement en masse ?

Merci d’avance pour vos retours.

Je reste disponible pour plus d’informations.

42

Si le SSH est accessible sur l’ensemble des Framboise avec Ansible il est possible de faire ce que tu cherche (administrer, update, reconfiguration).

L’avantage c’est que ce ne sera pas bloquant si les maj échoue sur l’une des framboises et que tu aura un retour de chaque action si ton Playbook est propre et bien structuré.

1 J'aime

Le désavantage d’ansible étant juste qu’il faut des lustres pour comprendre comment ça marche et faire quelque chose avec.
Personnellement, j’ai abandonné.

Sinon, oui, tu peux lancer les commandes à distance avec la syntaxe ssh <user>@<machine> <commande>

Pour jouer avec il n’est pas utile de dépenser trop de temps …

  • le binaire (apt install ansible)
  • un fichier d’inventaire
  • un dossier avec les éventuels templates
  • un dossier avec d’éventuels fichier
  • un dossier pour la partie tâche (subdiviser par différentes tâches)
  • un dossier pour la partie handle
  • le playbook et le playbook de retry

Franchement quand tu doit lancer régulièrement des actions sur des machines voir déployer des correctifs identiques sur plusieurs machines je ne ferais pas de parallèle ssh ou autre trucs du même accabit.

Merci à vous deux pour vos réponse aussi rapides qu’intéressantes.

mattotop, la commande ssh @ c’est top pour administrer une machine à la fois. Mais si je souhaite administrer l’intégralité des Rpi d’un claquement de doigts (ou presque) c’est pas la solution qui me convient.
Pour Ansible, cela me semble parfait. J’ai également entendu parler de “puppet”.
Clochette, je suis un utilisateur … Ummm, je dirais semi-débutant avec le Rpi et Linux en règle générale. Je l’utilise depuis plusieurs années pour naviguer/traiter - trier mes photos/communiquer et toutes les taches administratives ingrates. Je connais quand même les bases en shell, je peux me débrouiller sur pas mal de choses cependant : “playbook”; “handle”; “templates” sont des mots inconnus pour moi.

Je vais essayer de trouver des tutoriels pour mieux en comprendre le fonctionnement et le paramétrage. Si vous en avez à me conseiller, qui ont pu vous aider, c’est avec plaisir.

Encore une fois merci beaucoup. Très bonne soirée.

42

Pour une demi-douzaine de machines de même type, sortir l’artillerie lourde du genre ansible ou puppetme paraît un peu exagéré. Pour une douzaine de machines et une poignée de conteneurs lxc, j’ai opté pour l’architecture suivante (c’est une petite grappe de serveurs pour des calculs hydrodynamiques et de structure )
les machines font partie d’un domaine NIS : il y a un serveur NIS principal et un serveur secondaire. (tous les systèmes sont clients NIS)
Une machine contient les répertoires utilisateurs (HOME). Plus précisément un système de fichiers monté sur /homex est exporté en NFS vers toutes les machines du domaine
Sur toutes les machines on crée un point de montage /homes et une table NIS /etc/auto.home qui permet un montage automatique de /homes/userdu répertoire /homex/user de la machine sus-dite.
Le répertoire HOME d’un utilisateur toto est défini comme /homes/toto. Cette définition d’un utilisateur doit se faire avec adduser ou useradd sur le serveur principal NIS.
Pour pouvoir gérer NFS et les montages automatiques, le premier utilisateur qui a le numéro uid 1000 a son HOME sur chacune des machines soit /home/nom et fait partie du groupe sudo.
Chaque utilisateur a aussi le droit d’écriture dans un répertoire /bigr/user qui est en fait un montage automatique d’un répertoire /bigl/user d’une des machines du domaine (bigr = réparti, bigl = local).
Une table NIS /etc/auto.big permet d’indiquer pour un utilisateur untel quel est le serveur exportant quel répertoire bigl/untel

Cela paraît compliqué au premier abord, mais dans votre cas vous pourriez
considérer le 6 ième (le NAS) comme point d’entrée pour l’administration (via le VPN) et aussi comme serveur NFS qui exporte les répertoires HOME des élèves (uid élèves >= 1001 ).
Sur cette tête de pont à l’école :

  • se connecter en utilisateur 1000 faisant partie du groupe sudo
  • installer tmux et keychain
  • copier les clés SSH vers ~/.ssh et ajouter dans .bashrc l’appel à keychain.
    Si vous voulez centraliser les HOME installer nfs-kernel-server
    Si vous optez pour la totale installer nis et autofs

Sur chacun des systèmes des élèves :

  • utilisateur 1000 groupe sudo pour l’administration /home/nom en local
  • utilisateurs élèves numéros 1100 1101 … sur pi1 et 1500 … sur pi5 par exemple
  • si vous voulez centraliser les HOME installez autofs ce qui installera nfs-common, et créez /homes répertoire parent des montages automatiques.
    configurez les fichiers /etc/auto.master et /etc/auto.home.
  • si vous optez pour la totale installez le paquet nis et indiquez le nom de domaine NIS et le serveur principal.

Pour bien comprendre comment combiner les outils en mode texte de base tels que ssh, keychain et tmux je vous conseille de vous familiariser avec ces outils et de découvrir comment je peux obtenir la sortie suivante sans taper de mot de passe ni passphrase (une phrase de passe tapée une fois au premier shell ouvert )

fp2@debpacha:~$ ssh-add -l
4096 SHA256:xAc+Q6FXkrPfJRiDo6Hr2foVENpH1Yz81TvtX6TtTPA fp2@debpacha (RSA)
1024 SHA256:jHd3tzORPG/OKoR8bmLcoQJ0HLW8eqFsfxEKvSGVwTM /home/fp2/.ssh/id_rsa_legacy (RSA)
256 SHA256:FFwFONokq5pa97j6o1KW7IU1NIj7eUzfLS1nbLNKkkk fp2@debpacha (ED25519)
fp2@debpacha:~$ SSH_AUTH_SOCK=$SSH_AUTH_SOCK ssh root@localhost id
uid=0(root) gid=0(root) groupes=0(root)
fp2@debpacha:~$ 

Exercez vous à créer plusieurs fenêtres tmux sur votre PC.
Apprenez à vous déconnecter via D
et à rétablir la session avec

tmux attach -t 0

Puis vous vous connectez sur la tête de pont et vous jouez de même avec une session tmux. Par exemple, une première fenêtre pour gérer la tête de pont et une deuxième dans laquelle vous lancez ssh pi1 uptime

Si le NAS n’est éteint que pendant les vacances scolaires, vous pouvez avoir un uptime et une session tmux (avec l’historique des commandes passées) d’environ 6 semaines.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة


F. Petitjean
Ingénieur civil du Génie Maritime.

« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

1 J'aime

Oui, puppet ou ansible dans cette situation, c’est clairement trop lourd. En plus il y a un certain temps d’apprentissage nécessaire, et ansible est très très pratique pour automatiser des déploiements complexes et chronophages, mais pour administrer quelques machines distantes, c’est sous-optimal (la surcouche python rend toute commande affreusement lente).
Personnellement, je ne comprends pas pourquoi on persiste encore à considérer Ansible comme un outil de gestion quotidienne de parc, alors qu’il ne fait rien qui soit impossible à faire en shell, qu’il le fait de façon un peu alambiquée parfois, et toujours très très très lentement.

Le plus simple pour moi c’est d’avoir une variable (dans son fichier ~.profile par exemple) dans laquelle on met les noms d’hôtes des machines à administrer, d’avoir les moyens de se connecter en SSH sans mot de passe (utilisation d’une paire de clés) et d’utiliser une petite boucle shell du style:

Sputnik@NXQLX092:~$ mes_machines=( machine1 machine2 machine3 )
Sputnik@NXQLX092:~$ commande="apt update && apt upgrade -y"
Sputnik@NXQLX092:~$ for machine in ${mes_machines[@]} ; do ssh utilisateur@"$machine" "$commande" ; done

Allez un petit prêche pour Ansible :

  • un dossier file (avec dedans un fichier txt contenant une clé SSH)

  • un fichier host avec dedans une liste de machine (découper par rôle et une liste globale) :

[piall]
nom_de_la_machine-1 IP
nom_de_la_machine-2 IP
nom_de_la_machine-3 IP
nom_de_la_machine-4 IP
nom_de_la_machine-5 IP
[piweb]
nom_de_la_machine-1 IP
nom_de_la_machine-2 IP
[pisql]
nom_de_la_machine-3 IP
nom_de_la_machine-4 IP
[piftp]
nom_de_la_machine-5 IP
  • un playbook pour uploader une clé ssh
---
- hosts: csxenall
  user: root
  tasks:
    - name: "Push SSH KEY to Host list"
      authorized_key:
        user: root
        state: present
        key: "{{ lookup('file', '/path_to_your_id_rsa.pub') }}"
...

En résumé pour pousser une clé ssh sur l’ensemble des PI il vous faut un service ssh fonctionnel, un binaire Ansible et lancer la commande :

# ansible-playbook -i host/piall playbook_uploadsshkey.yml

C’est carrément plus court que ce que vous proposer non ?
Après pour les mises à jour c’est un poil plus compliqué mais c’est de l’apprentissage à faire de l’outil et les recettes une fois développer reste modifiable pour les réutiliser dans d’autres contextes.

Ayant un très très grands nombres de machines à exploiter je ne peux plus me passer d’Ansible, je préfère perdre une demi journée à tester et mettre ne place un nouveau playbook pour ensuite en profiter régulièrement.

Pour ma part je travail avec des playbook qui sont stocker sur un Gitea ce qui me permet de gérer en plus de ça leur maintenance et les mettre à disposition à toutes machines ayant accès à ce git (par exemple depuis un portable ^^).

Ouh là ! Heureusement que cela ne fonctionne pas.
Autant, il m’arrive de faire une vérification simple (pour savoir où j’en suis) du genre

for m in im01 im02 im03 im04 im05 im06 imhs impp
do
   echo "machine" $m
   ssh $m lsb_release -a
   ssh $m uptime
   echo "_____________"
done

autant je ne vai pas mettre dans une variable shell une commande complexe (et donc la nécessité de ne surtout pas oublier de mettre des guillemets chaque fois que je veux référencer “$commande” ) qui en plus réclame des droits étendus (coucou sudo) et qui est susceptible de ne pas faire ce qu’on veut (le “-y” est pour le moins discutable)

Comme je viens tout juste de dépasser en âge les deux tiers de siècle, j’ai plutôt tendance à y aller calmement, détendu. Voir on est pas bien là à la fraîche décontractés du gland
C’est pourquoi, pour cette tâche routinière de mettre à jour les machines d’un parc de taille modeste, je procède ainsi :

  • je me connecte en ssh sur une des machines
    1 si je ne me suis pas connecté depuis le dernier redémarrage, une ligne de .bashrc (keychain) m’invite à taper ma phrase de passe, ce qui charge des clés ssh dans ssh-agent (je mets la même phrase de passe pour toutes les clés)
    2 sinon j’ai un message du genre
 * keychain 2.8.5 ~ http://www.funtoo.org
 * Found existing ssh-agent: 3813
 * Known ssh key: /home/fp2/.ssh/id_rsa
 * Known ssh key: /home/fp2/.ssh/id_rsa_legacy
 * Known ssh key: /home/fp2/.ssh/id_ed25519
  • je tape des commandes anodines du genre uptime et je détermine s’il y a déjà une session tmux en utilisant une des commandes suivantes
who
w
tmux list-sessions
  • si il y a déjà une session tmux
tmux attach

sinon tmux et je crée un certain nombre de fenêtres dans la nouvelle session.

  • Je mets à jour la machine sur laquelle je me suis directement connecté
sudo pwd
sudo apt update
# si besoin
sudo apt upgrade

Un lecteur attentif se demande « pourquoi sudo pwd ? »
C’est psychologique : je vais taper des commandes privilégiées, je ne veux pas être distrait au moment où j’enchaîne ce genre de commandes par des interférences du système qui me demande un mot de passe. (et l’identifiant + mot de passe n’est pas forcément le même sur toutes les machines ). J’ai donc l’habitude de commencer par une commande sudo anodine.

  • pour la mise à jour des autres systèmes c’est
ssh [user@]machine
sudo  pwd
sudo apt update
sudo apt upgrade
exit

le tout dans une des fenêtres tmux (donc possibilité de faire défiler l’affichage)

  • une fois que l’intervention est terminée, fermeture en ordre
# fermeture de la session persistante `tmux`  <prefix> == Ctrl-B par défaut
<prefix> D
# le  message [detached (from session 0)]  s'affiche
# fermeture de la connexion ssh
exit
# on se retrouve sur la machine locale après des messages du genre
# déconnexion
# Connection to drhpcm05 closed.

Pour la problématique de copier un fichier de configuration d’une machine sur l’autre, j’ai utilisé la méthode laborieuse suivante

scp -p /etc/fichier/deconf  machine:/tmp
ssh machine
cd /tmp
sudo cp deconf /etc/fichier/deconf
sudo chown root:root /etc/fichier/deconf
exit

en utilisant moult copier/coller, mais c’est pénible.

Maintenant je combine sudo et scp de cette manière

# vérifier clés OK
sudo  SSH_AUTH_SOCK=$SSH_AUTH_SOCK ssh machine id
# copie
sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK scp -p /etc/fichier/deconf machine:/etc/fichier/deconf

explication

  • sudo on passe root uid=0
  • SSH_AUTH_SOCK=$SSH_AUTH_SOCK ssh machine coommande
    les informations de ssh-agent sont prises en compte pour la commande sshou scp qui suit (et qui est exécutée par root)
    La machine distante reçoit une connexion pour root et donc consulte le fichier /root/.ssh/authorized_keys fichier que j’ai créé précédemment avec les bons droits et le bon contenu.
    résultat : ni vu ni connu, je lance une commande privilégiée sur une machine distante sans même taper de phrase de passe (ssh-agent répond à ma place).

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة


F. Petitjean
Ingénieur civil du Génie Maritime.

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac

Oui vos solutions sont sympa, mais soit vous avez pas le résultat de ce qu’il se passe, soit vous ne pouvez pas parallélisé les actions.

Encore une fois pour une simple mise à jour des systèmes ,testée auparavant, depuis le PI qui servira de passerelle (utilisateur Ansible à prévoir avec droits sudo dans ce cas, ou sinon moyennant quelque ajustement directement avec root) :

---

- hosts: all
  sudo: yes
  tasks:
    - name: Update packages list
      apt: update_cache=yes
      when: ansible_os_family == 'Debian'

    - name: List packages to upgrade (1/2)
      shell: aptitude -q -F%p --disable-columns search "~U"
      register: updates
      changed_when: False
      when: ansible_os_family == 'Debian'

    - name: List packages to upgrade (2/2)
      debug: msg="{{ updates.stdout_lines | count }} packages to upgrade ({{ updates.stdout_lines | join(', ') }})"
      when: (ansible_os_family == 'Debian' and updates.stdout_lines)

    - name: Upgrade packages
      apt: upgrade=safe
      when: ansible_os_family == 'Debian'

    - name: Check what the new version is
      shell:  lsb_release -r | awk '{print $2}'
      changed_when: False
      register: new_release

    - name: Notify distribution version upgrade
      debug: msg="Debian has been upgraded from {{ ansible_lsb.release }} to {{ new_release.stdout }}"
      when: ansible_lsb.release != new_release.stdout

    - name: List services to restart (1/2)
      shell: checkrestart | grep ^service | awk '{print $2}'
      register: services
      changed_when: False
      when: ansible_os_family == 'Debian'

    - name: List services to restart (2/2)
      debug: msg="{{ services.stdout_lines | count }} services to restart ({{ services.stdout_lines | join (', ') }})"
      when: (ansible_os_family == 'Debian' and services.stdout_lines)

Un truc comme ça ou approchant sera suffisant.
Que ce soit pour faire un inventaire des fichiers en attente de mise à jour et/ou leurs applications il suffira d’adapter un fichier.

Je ne vois vraiment pas en quoi Ansible serait plus lent ou moins simple à utiliser.
Certes il y a de l’apprentissage, mais les avantages sont immédiat et la documentation largement disponible.
Le nombre de module spécialisé intégré dans Ansible s’agrandit de jour en jour permettant de façon de plus en plus simple un très grands nombres de tâches avec leur retour :wink:

Sinon principe de recherches … par mots clés et en générale je trouve mon bonheur:

playbook ansible la_tâche_à_faire

Plus lent c’est clairement une contrevérité, et vous avez très justement préciser qu’en fait on peut bénéficier du parallélisme des opérations.

Du méga FUD. Par exemple, la commande lsb_release est affreusement lente car elle est écrite en python. Des déboires avec Ansible sont possibles si vous utilisez des playbooks codés avec les pieds, ce n’est pas la faute d’Ansible ou de python dans ce cas.

Dans une SLES (Süse Linux Enterprise Server) distribution commerciale pour serveur, c’est (ou c’était) puppet qui est fourni par défaut, je n’ai jamais été fan de ruby (un langage qui vient du pays du Soleil Levant). Par contre, python oui, cela me parle beaucoup plus.

J’aurais plutôt écrit

shell: lsb_release -r | cut -f 2

et donc utilisé un binaire de 44Ko au lieu d’un binaire /usr/bin/gawk de 660ko
Mais je ne connais pas la syntaxe de l’extrait ci-dessus pour insérer le code python3 suivant

import lsb_release
distinfo = lsb_release.get_distro_information()
print(distinfo['RELEASE'])

Merci Clochette, j’envisage maintenant d’installer ansible (près de 35Mo) sur la seule machine passée en Debian 10 (problème des noms d’interfaces réseau persistants sur des systèmes à 4 interfaces réseau ).

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة


F. Petitjean
Ingénieur civil du Génie Maritime.

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac

« Je préfère le vin d’ici à l’au-delà »
Pierre Dac

C’est noté, ça allège nettement effectivement.

  • Digression ON -

Depuis quelques temps je me suis suis versé dans Ansible (anciennement Salt ^^) pour systématiser mes actions récurrentes avec des playbook.

Je travaille même actuellement à la mise ne place d’une infrastructure sur une base de AWX couplé à du répertoire Git et un CI afin de permettre de me découper des très nombreuses tâche d’administration que je rencontre sur une grande variété de système.
Il est étrangement plaisant de pouvoir avoir un retour simple sur plus de 100 serveurs à l’aide d’une seule commande sur la présence ou non d’une ligne dans le systcl de chaque système.

Pour le cas puppet, au service de recherche et développement de mon entreprise ils avaient été peu à peu été abandonné pour ne plus être en utilisation au moment de mon arrivée.
Remplacer par des scripts Perl et de l’automatisation à l’aide de Ansible.

L’autre avantage avec Ansible c’est que vous pouvez effectuer du push et du pull comme technique.
Permettant à une machine avec IP publique de récupérer sur un dépôt le playbook adéquats, de l’exécuter, et de nettoyer tout en laissant qu’une machine configurée et propre sans traces.

Et sans utiliser du tout de binaire :wink:

lsb_release -sr
1 J'aime

Bonjour à tous.

Encore merci pour vos réponses. Désole pour ma réponse tardive. J’ai l’impression d’avoir mis le feu à la poudrière et de n’avoir pas été la pour arbitrer le match pro/anti Ansible !
J’ai bien compris que personne n’est bien entendu “anti-ansible” mais que certains le trouvent sur-dimensionné !
Si j’ai compris 10% du contenu de vos réponses c’est un exploit ! Je vous assure que je travaille pour comprendre, de même que vous avez travaillés pour m’expliquer !

Plus concrètement.

J’ai 6 machines : 1 machine qui commande, 5 machines commandées.

La machine qui commande s’appelle

-"00_lune", 192.168.1.100

Les machines commandées sont :

-"01_soleil", 192.168.1.101
-"02_mercure", 192.168.1.102
-"03_venus", 192.168.1.103
-"04_terre", 192.168.1.104
-"05_mars",192.168.1.105

supposons que je souhaite, à partie de “la lune” :slight_smile: , installer vlc sur l’ensemble des “planètes” :smiley:.
Bien entendu je peux me connecter en SSH sur chacune des planètes par

ssh 01_soleil@192.168.1.101
sudo apt-get install vlc
exit
ssh 02_mercure@192.168.1.102
sudo apt-get install vlc
exit
ssh 03_venus@192.168.1.103
sudo apt-get install vlc
exit
.... et ainsi de suite jusqu'a ce que mort s'en suive ...

Mais à ce rythme là, la mort se rapproche à grand pas.
Surtout que là, j’ai simplifier, car en réalité j’ai pas 5 mais 10 planètes ! (C’est pour ça que j’ai mis le soleil avec … et pluton … tant que j’y suis ! Mais c’est pas le débat). Mais quand j’aurais compris pour 5, j’aurais compris pour 10 !

Aussi, je ne souhaite pas "automatiser ces taches, mais simplement, si un jour une enseignante me demande “pouvez-vous installer <mettez ici le nom d’un logiciel quelconque> sur les ordiiiiiii ?”, ou bien si je souhaite faire un upgrade, que je puisse le faire en 2 lignes de commande (ou 3, je suis pas difficile).

Cela s’appelle un (début de) plan d’adressage IP

Erreur de débutant : vous mélangez les utilisateurs et les machines.
La syntaxe est

ssh [user@]host

et si le paramètre user n’est pas donné, c’est une connexion vers le compte de même nom sur la machine distante host.
C’est à dire que si vous êtes sur la machine 00_lune et si vous tapez ces commandes

hostname --fqdn
getent hosts 00_lune
getent hosts 192.168.1.100
whoami
id
id 1000
getent passwd $(whoami)
getent passwd 1000

vous aurez une idée un peu plus précise des choses. En particulier, vous voyez qu’avec la commande getent vous pouvez interroger des tables en donnant le numéro (uid, adresse IP, …) au lieu du nom.
Pensez à d’abord remplir à la main une table de noms de machines qui tienne la route sur 00_lune
Cest le fichier /etc/hosts partiellement rempli à l’installation du système.

127.0.0.1      localhost
127.0.0.1      00_lune.localdomain
192.168.1.100 00_lune
192.168.1.101 01_soleil
192.168.1.102 02_mercure
192.168.1.101 03 03_venus

etc… Mais cette configuration réseau dépend beaucoup que quel gestionnaire de réseau vous utilisez et du type de l’appareil réseau qui permet de connecter ce sous-réseau privé 192.168.1.0/24 à un réseau public, donc à internet 'ce peut être une box, …)

less /etc/resolv.conf
#  en particulier la directive search   devrait vous donner le nom du domaine local

Si vous êtes identifié comme toto sur 00_lune, je vous conseille de créer un compte toto sur chacune des autres planètes. Vous n’êtes pas obligé d’avoir le même numéro partout, mais c’est beaucoup plus simple si toto a le même uid partout.
Première chose à faire : suivre une formation express sur le Secure Shell sans oublier l’agent ssh
Il faut absolument arriver à maîtriser les tenants et aboutissants d’une connexion SSH par clé. Je vous conseille donc d’y aller pas à pas.
S’entraîner à l’utilisation des clés avec l’agent (man ssh-add )
Installer keychain

C’est assez facile si vous prenez les choses par le bin bout.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة


F. Petitjean
Ingénieur civil du Génie Maritime.

« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

Hi :wink:

Tout s’explique … en fait je suis débutant ! Mais le pire c’est encore que je me suis posé la question quand j’ai rédigé … :weary: … Ô, rage … L’user, c’est "pi, bah ouais.
M’occupe au plus vite de la “formation express Secure Shell & Agent SSH”.
Miracle, ce post, bien qu’il ne soit pas limpide non plus, m’est beaucoup plus compréhensible ! Merci LittleJohn !

La, en revanche, je suis dans les choux …
Un switch RJ45 16 ports sera raccordé à une box. C’est quoi la “directive search” ?

Merci et bon dimanche (pluvieux par chez moi).

Clochette, ta solution, bien qu’il s’agisse “d’artillerie lourde”, me semble plutôt adaptée.
Je viens de voir une vidéo qui décrit bien l’utilisation d’Ansible (C’est sous CentOS mais il faut juste adapter yum par apt-get).
Il existe bien d’autres vidéos de cette “usine à gaz” :wink: mais celle ci est plus adaptée au bleu que je suis !

Tu trouvera facilement pas mal de blog traitant de Ansible, c’est le gros avantages :

Bon, observons les faits:

root@test ~# time ansible localhost -m copy -a "src=dump.sql dest=/tmp/dump.sql"
 [WARNING]: Platform linux on host localhost is using the discovered Python interpreter at /usr/bin/python, but future installation of another Python interpreter could change this. See
https://docs.ansible.com/ansible/2.8/reference_appendices/interpreter_discovery.html for more information.

localhost | CHANGED => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": true,
    "checksum": "893ef4c27fee7389bbe31453c55eb0f47475c7dd",
    "dest": "/tmp/dump.sql",
    "gid": 0,
    "group": "root",
    "md5sum": "5de5b46d98d775f95f7fbe36ee7e24a3",
    "mode": "0644",
    "owner": "root",
    "size": 112919,
    "src": "/root/.ansible/tmp/ansible-tmp-1572949142.87-180565429163136/source",
    "state": "file",
    "uid": 0
}

real    0m11.688s
user    0m9.212s
sys     0m1.072s
root@test ~# time cp dump.sql /tmp/dump2.sql

real    0m0.086s
user    0m0.001s
sys     0m0.006s

C’est un exemple qui vaut ce qu’il vaut, mais le même effet recherché (un fichier de quelques centaines de Ko copié dans /tmp) ne prend pas du tout la même durée selon qu’on utilise ansible ou pas. On peut faire le même test autant de fois qu’on veut, on trouvera des résultats sensiblement similaires. Au lieu d’effectuer cette action en local on peut aussi l’appliquer sur une cible distante, c’est pareil, une commande scp prendra énormément moins de temps que le module copy d’Ansible.

Encore une fois, j’aime bien Ansible et je ne cherche pas à jeter du FUD dessus. Je dis simplement que dans un contexte d’environnement simple et pour des actions vraiment simples, Ansible ne me semble pas la solution optimale, de mon point de vue.

Bonjour Tout le monde,

Une solution plus simple est de créer un fonctionnement type “GPO”.
Sur le raspberry “Serveur” tu installes Apaches et tu places un fichier script “GPO.sh” par exemple contenant les instructions suivant.

root@client_Pi_01 cat /var/www/html/gpo.sh
#!/bin/bash
##########################################
date=`date +%Y-%m-%d-%Hh%Mm%Ss`
##########################################
install=MAJ_20191114
file=/var/log/$install.log
if  test -s "$file"
then
	echo $install"_est_deja_installe"
else
	echo $install"_n_est_pas_installe"
	apt-get update -y apt-get upgrade -y
	echo $install"_a_ete_installe_sur_"$(hostname)_"le"_$date >> $file
fi
exit 0
##########################################

et sur les Raspberry client, tu créer un crontab ou un service (wgetgpo.sh) qui va downloald le fichier gpo.sh et l’exécute à chaque démarrage par exemple.

##########################################
root@client_Pi_02:~# cat wgetgpo.sh
#!/bin/bash
wget http://192.168.0.1/gpo.sh -O /root/gpo.sh
sleep 2
chmod +x /root/gpo.sh
/root/gpo.sh &
exit 0
##########################################

============================

Sinon la 1er solution que tu souhaités mettre en place :
“Existe-il un moyen d’envoyer une commande en SSH à l’ensemble des 5 Raspberry Pi « élèves » afin qu’elles se mettent toutes à jour ou de faire du déploiement en masse ?”

La réponse est oui, et c’est l’application “expect” qui le fait extrêmement bien.

Bon courage
A+

Stefviv