Automatisation de commandes courantes

Hello tout le monde,
Petit à petit je commence à administrer quelques serveurs Yunohost ({raspberry,orange}-pi et vps notamment). Donc déjà un grand merci à toute l’équipe des devs/admins pour rendre tout ça aussi accessible! :tada: :partying_face:

Ensuite, je réfléchis donc à un moyen d’automatiser des commandes courantes (typiquement apt -y update && apt -y upgrade ou màj yunohost…). J’ai l’impression d’avoir trouvé une solution à peu près potable en bash, mais je ne suis pas sysadmin donc j’en appelle à la communauté pour savoir si ce que je fais pose des problèmes de sécu, notamment car je cherche lancer les mises à jour sans mot de passe, ou autre.

Pour résumer, je suis parti dans l’idée d’utiliser un script “update.sh” et un utilisateur “updator” sur chaque serveur et lancer les màj via ssh. Les étapes principales sont les suivantes:

Sur mes machines distantes

  1. Créer un fichier “update.sh” dans /usr/local/bin/scripts/
  2. Créer l’utilisateur “updator” disposant du droit d’exécuter “update.sh”
  3. Ajouter une clef ssh “id_rsa_update” dédiée à updator sans phrase de passe
  4. Autoriser “updator” à lancer les commandes prévues dans update.sh sans mot de passe en éditant /etc/sudoers avec par exemple updater ALL=(ALL) NOPASSWD: /usr/bin/apt -y update

Sur ma machine locale

Créer un alias du type ssh updator@domaine.de.mon.serveur -i .ssh/id_rsa_update '/usr/local/bin/scripts/update.sh >> ~/update.log pour chacune des machines distantes et donc également regrouper toutes ces commandes un un seul script.

Qu’en pensez-vous?

Bonjour,

Je ne suis pas sysadmin non plus mais tout ceci me parait un poil compliqué.
Tu parles d’automatisation et de ce que je vois, tu cherches à lancer les mises à jours à partir de ta machine locale, donc je ne vois pas en quoi c’est une automatisation.
Il existe déjà des outils intégrés à Debian comme Unattended-upgrades par exemple pour mettre à jour.
Si le but est de lancer automatiquement les commandes de mises à jour comme tu le cites en exemple, une simple tâche cron sur le serveur ferait la même chose je suppose mais je ne l’ai jamais fait préférant utiliser les outils disponibles. Perso j’utilise apticron qui m’envoie un mail de notification lorsqu’il y a des mises à jour de disponible. Ça n’a rien d’automatique par contre, ça notifie simplement. J’ai utilisé pendant quelques années Unattended-upgrades pour mettre à jour des PC desktop/laptop, ça fonctionne bien.

Merci pour ton retour.

Effectivement, par “automatisation” j’entendais simplement pouvoir lancer une commande en local qui lancerait les mises à jours simultanément sur plusieurs serveurs distants (et qui centraliserait aussi les logs au même endroit en local tant qu’à faire).

Je n’avais pas pensé à cron non plus, je vais me pencher dessus. Seul problème que ça pourrait me poser c’est que j’aime bien faire mes mises à jour manuellement aussi parfois pour pouvoir intervenir plus rapidement en cas de pépin. Même soucis avec unattended-upgrade si je le laisse tourner seul?

Je ne connaissais pas apticron par contre. J’aime beaucoup l’idée. Par contre ça ne règle pas mon problème initial: si apticron me notifie 10 serveurs à mettre à jour ça me fait me connecter à chaque machine et lancer mes mises à jour à chaque fois non?

Il existe cron-apt également.

Unattended-upgrades garde une trace des mises à jour dans des fichiers logs. Ça permet aussi d’envoyer un rapport par mail.

Merci, ça a l’air intéressant aussi.

Exactement :smiley:

Je pense qu’il doit y en avoir un certain nombre. Ainsi que des “vrais” logiciels d’automatisation comme Ansible/Chef/Puppet mais comme je n’ai pas beaucoup d’expérience non-plus, je préfère tenter de réinventer la roue pour apprendre comment tout ça fonctionne.

J’ai édité mon message précédent. Certes, ça mettrait à jour automatiquement mais tu aurais quand même une trace centralisée des logs avec un filtre sur les mails.

J’ai bien pensé aux logiciels que tu cites et que je ne connais que de nom, mais n’ayant aucune expérience, je ne te les ai pas conseillés.

Il existe le logiciel apticron (paquet Debian), qui a une app apticron_ynh de mémoire, qui sert justement à proposer des mises à jour automatiques ! :smiley:
Avec en option: information par mail en cas de succès, alterte en cas d’échec, simple information par mail de mises à jour en attente sans les faire…

C’est beaucoup plus simple et il gère plus de choses pour toi :slight_smile:


edit: ah, j’ai lu trop vite, c’est déjà cité plus haut :laughing:

Ça peut le faire tout seul, mais a priori ce n’est pas ce que tu préfères.
Personnellement ma technique c’est un groupe de marques-pages à l’adresse de la webadmin des différents Yunohost, je fais “Tout ouvrir dans les onglets” dans une nouvelle fenêtre, je laisse tourner 30s et après je clique sur mettre à jour sur chaque onglet :slight_smile:

1 Like

Ah c’est pas mal ces différentes options, vous m’avez convaincu! Je testerai ne serait-ce que pour l’option info par mail.

Webadmin de l’app apticron_ynh ou de l’espace admin du serveur? Parce que j’ai oublier de préciser mais pour pimenter le tout certains serveurs ont l’API webadmin désactivée (donc je n’ai accès aux tâches de maintenance qu’en CLI et aux apps via le portail SSO). :exploding_head:

Pour le mot de la fin, j’ai finalement regroupé toutes mes commandes de maintenance sans préfixe sudo dans les scripts distants (e.g., yunohost tools update ou apt update),

je les appelle avec des ssh updator@domaine.de.mon.serveur -i .ssh/id_rsa_update 'sudo /usr/local/bin/scripts/update.sh pour chaque serveur

et je restreins les droitsde l’utilisateur updator en ne l’autorisant à lancer que le script en mode sudo avec une règle updator ALL=(ALL) NOPASSWD: /usr/local/bin/scripts/update.sh dans le fichier /etc/sudoers.d/updator.

Ça tourne tip top, c’est flexible et ça semble sécure :slight_smile:

Merci pour les tuyaux d’autres logiciels en tout cas, j’y reviendrai par la suite.

P.S: Attention aux upgrades automatiques via unattendedupgrades tout de même :3 Debian -- News -- Debian 12.3 image release delayed

Personnellement j’évite d’automatiser les mises à jour. Je préfère mettre à jour une chose à la fois pour vérifier que tout est bon et en cas de pépin j’agis dans l’immédiat.
Je ne savais pas qu’il y avait un package pour apticron, je l’ai installé à la main il y a longtemps. Par contre, j’ai un script en cours d’élaboration pour nettoyer le serveur, effacer le cache apt. J’ai vu un post sur le forum à propos des versions node qui occupaient de la place malgré qu’ils ne sont plus utilisés. J’ignore si ce n’est plus nécessaire avec la version 11 de yunohost.

Il s’agit de Debian 12.3 et Yunohost est basé sur Debian 11, donc l’avertissement ne concerne pas yunohost.
D’ailleurs l’avertissement concerne également les mises à jour manuelles. La mise en garde concernant Unattended-upgrades est que cet outil est justement fait pour mettre à jour automatiquement et qu’il faut ne faut surtout pas l’oublier dans ce type de cas , et le désactiver temporairement.

Oui on est pas sur les mêmes versions, mais je trouvais que c’était quand-même quelque-chose d’intéressant à garder en tête, surtout si on part sur une solution vraiment automatisée (mais ça n’était pas l’objectif initial).

@jarod5001 pour le coup l’objectif du script était juste d’éviter la répétition des commandes pour se connecter aux serveurs. Mis à part cela, tout fonctionne comme une mise à jour à la main.

Et c’est là que c’est bien fait : on a l’option d’être prévenu.e en cas de mise à jour disponible, sans que ça soit réalisé automatiquement.
C’est un bon entre-deux entre mettre à jour régulièrement (notamment pour les correctifs de sécurité), et le risque que le serveur tombe sans le savoir ou alors qu’il y a une mise à jour problématique connue (parce que si on ne le sait pas, dans les deux cas ça casse).

Juste une petite remarque, même si j’imagine que tu l’as déjà fait.
Tu as bien donné des permissions hyper-restrictives à ton script: /usr/local/bin/scripts/update.sh ?
Je pense que si tu autorise l’exécution d’un script sans devoir entrer le mot de passe, il faut qu’aucun utilisateur de ton serveur (updator inclu) ne puisse modifier ce script sans être root. Sinon potentiellement n’importe quel utilisateur qui peut modifier le script peut exécuter n’importe quelle commande comme root.

1 Like

chmod --changes 100 file_name ?

Ouip, je ferais quelque chose comme ça.

Merci beaucoup pour la réponse (et désolé pour le délais de la mienne), c’était exactement ce genre de remarque dont j’avais besoin!

J’ai passé les droits en 100 et RAS :smiley: