Skip to content

Instantly share code, notes, and snippets.

@stephdl

stephdl/maintenance-linux-mises-a-jour.md

Last active March 2, 2026 18:41
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save stephdl/78c1eddec0da16126fb4bb85d8fd4a11 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save stephdl/78c1eddec0da16126fb4bb85d8fd4a11 to your computer and use it in GitHub Desktop.
Download ZIP
Maintenance Linux — Mises à jour système : Debian 13 vs Rocky Linux 10
Raw
maintenance-linux-mises-a-jour.md

🐧 Maintenance Linux — Mises à jour système : Debian 13 vs Rocky Linux 10

Thèmes : philosophies de distribution, mises à jour système, supervision des logs avec journalctl, authentification SSH par clé, automatisation avec Ansible.

1. Debian vs Rocky Linux : deux philosophies profondes

Avant de lancer la moindre commande, il est essentiel de comprendre pourquoi ces deux distributions existent et ce qui les différencie fondamentalement.

1.1 Debian 13 "Trixie"

Debian est la distribution communautaire par excellence. Elle n'appartient à aucune entreprise — elle est gérée par le Debian Project, une organisation de développeurs bénévoles fondée en 1993 par Ian Murdock.

📥 Téléchargement ISO :

Image Taille Usage Lien
netinst (recommandé) ~754 Mo Installation minimale réseau debian-13.3.0-amd64-netinst.iso
DVD ~4,7 Go Installation hors ligne complète debian.org/distrib

💡 Le netinst est l'équivalent Debian d'une image minimale : il télécharge uniquement les paquets nécessaires pendant l'installation. Choisir "Minimal" (sans environnement graphique) lors de l'installation pour un serveur.

Cycle de vie :

  • Une nouvelle version majeure sort environ tous les 2 ans.
  • Chaque version bénéficie de 5 ans de support (3 ans de support standard + 2 ans de Long Term Support via LTS).
  • Le support étendu Extended LTS (ELTS) peut pousser jusqu'à 10 ans pour certains paquets (service payant via Freexian).
  • La philosophie est "ready when it's ready" : pas de date de sortie figée, la qualité prime sur le calendrier.

Modèle de paquets :

  • Gestionnaire : apt / dpkg
  • Format : .deb
  • Les paquets sont gelés à la sortie de la version stable → stabilité maximale, mais parfois versions un peu datées.

Avantages clés :

  • Indépendance totale vis-à-vis du monde commercial.
  • Énorme dépôt de paquets (>59 000 paquets).
  • Réputation légendaire de stabilité sur les serveurs.
  • Fonctionnement sur une multitude d'architectures (amd64, arm64, riscv64, etc.).

1.2 Rocky Linux 10

Rocky Linux est né en 2020 suite à l'annonce par Red Hat de la fin de CentOS Linux comme "clone RHEL". Gregory Kurtzer, cofondateur original de CentOS, a lancé Rocky pour prendre la relève.

Rocky Linux est un clone 1:1 de RHEL (Red Hat Enterprise Linux), compilé depuis les sources publiées par Red Hat.

📥 Téléchargement ISO :

Image Taille Usage Lien
boot (recommandé) ~920 Mo Net install — télécharge les paquets pendant l'installation Rocky-10.1-x86_64-boot.iso
minimal ~1,5 Go Installation minimale autonome (sans internet) Rocky-10.1-x86_64-minimal.iso

💡 boot vs minimal : Le boot nécessite une connexion internet pendant l'installation (télécharge les paquets depuis les miroirs Rocky). Le minimal contient les paquets de base et s'installe sans internet — pratique en lab ou en réseau isolé. Les deux donnent un système identique à l'arrivée.

⚠️ Contexte important : En 2023, Red Hat a décidé de ne plus publier les sources de RHEL sur git.centos.org, les rendant uniquement accessibles aux abonnés RHEL. Rocky Linux (et AlmaLinux) ont dû adapter leur stratégie de reconstruction. Ce conflit illustre la tension entre open source et modèles commerciaux.

Cycle de vie :

  • Calqué sur RHEL : 10 ans de support par version majeure (5 ans "Full Support" + 5 ans "Maintenance Support").
  • Les mises à jour de sécurité sont garanties sur cette durée — c'est l'argument numéro 1 pour les environnements d'entreprise.
  • Rocky 10 suit donc le cycle de RHEL 10.

Modèle de paquets :

  • Gestionnaire : dnf (successeur de yum)
  • Format : .rpm
  • Modules DNF pour gérer plusieurs versions d'un même logiciel (ex : PHP 7.4 et PHP 8.2 en parallèle).

Avantages clés :

  • Compatibilité binaire totale avec RHEL → les logiciels certifiés RHEL fonctionnent sur Rocky.
  • 10 ans de mises à jour de sécurité sans frais de licence.
  • Écosystème Red Hat : SELinux intégré et activé par défaut, firewalld, cockpit.
  • Référence dans les environnements d'entreprise, industrie, finance, santé.

1.3 Tableau comparatif rapide

Critère Debian 13 Rocky Linux 10
Origine Communauté indépendante Clone RHEL (Red Hat)
Gestionnaire de paquets apt / .deb dnf / .rpm
Cycle de release ~2 ans, "ready when ready" Aligné sur RHEL
Support sécurité ~5 ans (+ ELTS 10 ans payant) 10 ans gratuits
SELinux Optionnel (AppArmor par défaut) Activé par défaut
Cible principale Serveurs polyvalents, hébergement Entreprises, workloads critiques
Philosophie Liberté & communauté Stabilité & compatibilité entreprise

2. Mise à jour système

2.1 Sur Debian 13

# Mettre à jour la liste des paquets disponibles
sudo apt update

# Mettre à jour tous les paquets installés
sudo apt upgrade

# Mise à jour complète (gère aussi les changements de dépendances)
sudo apt full-upgrade

# Nettoyage des paquets obsolètes
sudo apt autoremove --purge

Concept — apt update vs apt upgrade :
apt update ne met rien à jour ! Il rafraîchit uniquement l'index local des paquets disponibles dans les dépôts. C'est seulement apt upgrade qui télécharge et installe les nouvelles versions. Ces deux étapes sont volontairement séparées pour vous laisser vérifier ce qui va être modifié.

# Voir ce qui sera mis à jour avant de le faire
apt list --upgradable

# Simuler une mise à jour sans rien installer
sudo apt upgrade --dry-run

Installer/desinstaller un programme :

Action Commande
Installer un paquet apt install vim
Installer sans confirmation apt install -y vim
Installer plusieurs paquets apt install vim curl git
Supprimer un paquet apt remove vim
Supprimer + fichiers de config apt purge vim
Supprimer + dépendances orphelines apt autoremove vim
Réinstaller un paquet apt install --reinstall vim
Mettre à jour un paquet seul apt install --only-upgrade vim

2.2 Sur Rocky Linux 10

# Mettre à jour tous les paquets
sudo dnf update

# Ou de façon équivalente
sudo dnf upgrade

# Vérifier les mises à jour disponibles sans installer
sudo dnf check-update

# Mettre à jour uniquement les correctifs de sécurité
sudo dnf update --security

# Nettoyage du cache DNF
sudo dnf clean all

Concept — dnf update vs dnf upgrade :
Sur DNF, les deux commandes sont équivalentes depuis DNF 1.0 — elles font toutes deux des mises à jour et gèrent les suppressions de paquets obsolètes. C'est différent d'APT où upgrade et full-upgrade ont des comportements distincts.

# Voir l'historique des transactions DNF (très pratique !)
sudo dnf history

# Annuler une transaction précédente (ex : numéro 42)
sudo dnf history undo 42

# Lister les dépôts actifs
sudo dnf repolist

# Informations de sécurité sur les mises à jour disponibles
sudo dnf updateinfo list security

Concept — dnf history :
DNF conserve un journal complet de toutes les opérations (installations, suppressions, mises à jour). Vous pouvez annuler n'importe quelle transaction, ce qui est extrêmement utile lors d'une mise à jour qui casse quelque chose. APT ne dispose pas de cette fonctionnalité native.

Installer/desinstaller un programme :

Action Commande
Installer un paquet dnf install vim
Installer sans confirmation dnf install -y vim
Installer plusieurs paquets dnf install vim curl git
Supprimer un paquet dnf remove vim
Supprimer + dépendances orphelines dnf remove vim (automatique)
Réinstaller un paquet dnf reinstall vim
Mettre à jour un paquet seul dnf update vim

3. Supervision des logs avec journalctl

journalctl est l'outil de lecture du journal systemd, disponible sur les deux distributions. Il centralise tous les logs système, kernel, services, et applications qui utilisent systemd-journald.

Concept — systemd journal vs fichiers /var/log :
Avant systemd, les logs étaient de simples fichiers texte dans /var/log/. Le journal systemd stocke les logs dans un format binaire structuré qui permet des filtres puissants, une indexation rapide, et la conservation des métadonnées (priorité, PID, UID, etc.). Les deux coexistent souvent : le journal peut être configuré pour transmettre à rsyslog.

3.1 Commandes essentielles

# Voir tous les logs (du plus ancien au plus récent)
journalctl

# Suivre les logs en temps réel (comme tail -f)
journalctl -f

# Voir les logs depuis le dernier démarrage
journalctl -b

# Voir les logs du démarrage précédent (-1 = avant-dernier, etc.)
journalctl -b -1

# Afficher les N dernières lignes
journalctl -n 50

3.2 Filtres par service

# Logs d'un service systemd spécifique
journalctl -u nginx.service
journalctl -u sshd.service

# Suivre en temps réel les logs d'un service
journalctl -u postgresql.service -f

# Logs de plusieurs services simultanément
journalctl -u nginx.service -u php-fpm.service

3.3 Filtres par priorité (niveau de gravité)

Les niveaux de priorité suivent la norme syslog (RFC 5424) :

# Niveaux disponibles : emerg, alert, crit, err, warning, notice, info, debug

# Afficher uniquement les erreurs et niveaux plus critiques
journalctl -p err

# Afficher les erreurs et warnings
journalctl -p warning

# Afficher uniquement les messages critiques du démarrage actuel
journalctl -b -p crit

Concept — niveaux de priorité syslog :
emerg(0) > alert(1) > crit(2) > err(3) > warning(4) > notice(5) > info(6) > debug(7).
Spécifier un niveau avec -p affiche ce niveau et tous les niveaux plus critiques.

3.4 Filtres temporels

# Logs depuis une date/heure précise
journalctl --since "2025-01-15 10:00:00"

# Logs entre deux dates
journalctl --since "2025-01-15 00:00:00" --until "2025-01-15 23:59:59"

# Syntaxe relative (très pratique)
journalctl --since "1 hour ago"
journalctl --since "yesterday"
journalctl --since "today"

3.5 Options d'affichage avancées

# Format JSON (une entrée par ligne, idéal pour parsing)
journalctl -o json

# Format JSON pretty-print (lisible)
journalctl -o json-pretty | head -50

# Afficher sans troncature des lignes longues
journalctl --no-pager

# Afficher le catalogue d'explications des messages (si disponible)
journalctl -x

# Combiner : erreurs récentes avec explications, sans pagination
journalctl -b -p err -x --no-pager

3.6 Gestion de l'espace disque du journal

# Voir l'espace occupé par le journal
journalctl --disk-usage

# Purger les entrées de plus de 2 semaines
sudo journalctl --vacuum-time=2weeks

# Limiter la taille du journal à 500 Mo
sudo journalctl --vacuum-size=500M

Concept — persistance du journal :
Par défaut sur certaines distributions, le journal est stocké en RAM (/run/log/journal/) et perdu au redémarrage. Pour le rendre persistant sur disque, il faut créer le répertoire /var/log/journal/ et relancer systemd-journald. La configuration se fait dans /etc/systemd/journald.conf avec Storage=persistent.

4. Authentification SSH par clé — prérequis pour Ansible

Ansible se connecte via SSH. Pour éviter de saisir un mot de passe à chaque connexion — et pour permettre l'automatisation — on utilise une paire de clés SSH (clé privée + clé publique).

Concept — cryptographie asymétrique SSH :
Une paire de clés SSH fonctionne comme un cadenas et sa clé. La clé publique (.pub) est déposée sur les serveurs distants — c'est le cadenas, on peut la distribuer librement. La clé privée reste sur votre machine locale et ne doit jamais être partagée — c'est la clé qui ouvre le cadenas. Lors de la connexion, le serveur chiffre un challenge avec la clé publique ; seul le détenteur de la clé privée peut le déchiffrer. Aucun mot de passe ne transite sur le réseau.

4.1 Générer une paire de clés SSH

# Générer une clé ED25519 (algorithme moderne, recommandé)
ssh-keygen -t ed25519 -C "votre-commentaire@hostname"

# Ou RSA 4096 bits (plus compatible avec les vieux systèmes)
ssh-keygen -t rsa -b 4096 -C "votre-commentaire@hostname"

L'assistant interactif vous demande :

  • Emplacement : par défaut ~/.ssh/id_ed25519 (privée) et ~/.ssh/id_ed25519.pub (publique). Accepter le défaut sauf si vous gérez plusieurs clés.
  • Passphrase : une phrase de passe optionnelle qui chiffre la clé privée sur disque. Recommandée pour la sécurité, mais nécessite ssh-agent pour l'automatisation.
# Résultat : deux fichiers créés
ls -la ~/.ssh/
# -rw-------  id_ed25519        ← clé PRIVÉE (600, jamais partagée)
# -rw-r--r--  id_ed25519.pub    ← clé PUBLIQUE (644, à distribuer)

# Afficher la clé publique
cat ~/.ssh/id_ed25519.pub
# ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... votre-commentaire@hostname

Concept — permissions SSH strictes :
SSH est très strict sur les permissions des fichiers. Si ~/.ssh/ ou la clé privée sont lisibles par d'autres utilisateurs, SSH refusera de les utiliser (WARNING: UNPROTECTED PRIVATE KEY FILE!). Les permissions correctes sont 700 pour ~/.ssh/ et 600 pour la clé privée.

# Corriger les permissions si nécessaire
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

4.2 Déployer la clé publique sur les serveurs distants

# Copier la clé publique sur un serveur distant
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@192.168.1.10

# Sur un port SSH non-standard
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 admin@192.168.1.10

Concept — ce que fait ssh-copy-id :
La commande se connecte au serveur (avec mot de passe pour cette première fois), puis ajoute votre clé publique dans le fichier ~/.ssh/authorized_keys de l'utilisateur distant. Ce fichier liste toutes les clés publiques autorisées à se connecter sans mot de passe. Après cette opération, les connexions suivantes n'ont plus besoin de mot de passe.

4.3 Vérifier la connexion sans mot de passe

# Test de connexion (ne doit plus demander de mot de passe)
ssh admin@192.168.1.10

# Test non-interactif
ssh admin@192.168.1.10 "hostname && uptime"

# Connexion verbose pour déboguer un problème d'authentification
ssh -v admin@192.168.1.10
ssh -vvv admin@192.168.1.10  # très verbose

4.4 Vérification côté serveur

Sur le serveur distant, vérifiez que la configuration SSH autorise bien l'authentification par clé :

# Vérifier les entrées dans authorized_keys
cat ~/.ssh/authorized_keys

# Vérifier la configuration du daemon SSH
grep -E "PubkeyAuthentication|AuthorizedKeysFile|PasswordAuthentication" /etc/ssh/sshd_config

La configuration minimale requise dans /etc/ssh/sshd_config :

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# Optionnel mais recommandé en production : désactiver les mots de passe
# PasswordAuthentication no   ← À activer APRÈS avoir vérifié que la clé fonctionne !
# Recharger la configuration SSH après modification
sudo systemctl reload sshd

⚠️ Ne jamais désactiver PasswordAuthentication avant d'avoir vérifié que la connexion par clé fonctionne depuis un autre terminal. Vous risqueriez de vous enfermer hors du serveur.

5. Automatisation avec Ansible

Ansible est un outil d'automatisation et de gestion de configuration sans agent (agentless). Il se connecte en SSH aux serveurs distants et exécute des tâches décrites en YAML.

Concept — Infrastructure as Code (IaC) :
Ansible appartient à la famille des outils IaC : l'infrastructure est décrite sous forme de code versionnable. Les avantages sont la reproductibilité, la traçabilité (Git), et l'idempotence — exécuter le même playbook plusieurs fois donne toujours le même résultat.

4.1 Installation d'Ansible

# Sur Debian/Ubuntu
sudo apt update && sudo apt install ansible -y

# Sur Rocky/RHEL (via EPEL)
sudo dnf install epel-release -y
sudo dnf install ansible -y

# Via pip (version la plus récente)
pip install ansible --user

4.2 Fichier d'inventaire

L'inventaire définit les serveurs cibles. Fichier inventory.ini :

[debian_servers]
debian13-prod ansible_host=192.168.1.10 ansible_user=admin

[rocky_servers]
rocky10-prod ansible_host=192.168.1.20 ansible_user=rocky

[all_servers:children]
debian_servers
rocky_servers

Concept — groupes d'inventaire :
Les groupes permettent de cibler des sous-ensembles de serveurs. [all_servers:children] crée un groupe parent qui contient les deux groupes enfants. Ansible dispose aussi d'un groupe implicite all qui contient tous les hôtes.

4.3 Test de connectivité

# Tester la connexion SSH sur tous les serveurs
ansible all -i inventory.ini -m ping

# Tester uniquement les serveurs Debian
ansible debian_servers -i inventory.ini -m ping

# Exécuter une commande ad-hoc
ansible all -i inventory.ini -m command -a "uptime"

4.4 Playbook de mise à jour — Debian et Rocky

Fichier update_servers.yml :

---
- name: Mise à jour des serveurs Debian
  hosts: debian_servers
  become: true  # Équivalent de sudo
  tasks:

    - name: Mise à jour de la liste des paquets
      ansible.builtin.apt:
        update_cache: yes
        cache_valid_time: 3600  # Ne rafraîchit pas si < 1h

    - name: Mise à jour de tous les paquets
      ansible.builtin.apt:
        upgrade: full  # Équivalent de apt full-upgrade
      register: apt_result  # Stocker le résultat

    - name: Supprimer les paquets inutiles
      ansible.builtin.apt:
        autoremove: yes
        purge: yes

    - name: Afficher le résultat de la mise à jour
      ansible.builtin.debug:
        msg: "Paquets mis à jour : {{ apt_result.changed }}"

    - name: Redémarrer si nécessaire (fichier /var/run/reboot-required)
      ansible.builtin.reboot:
        msg: "Redémarrage post-mise à jour"
        reboot_timeout: 300
      when: ansible_facts['os_family'] == 'Debian' and
            (ansible_facts['packages'] is defined) and
            ('/var/run/reboot-required' is file)


- name: Mise à jour des serveurs Rocky Linux
  hosts: rocky_servers
  become: true
  tasks:

    - name: Mise à jour de tous les paquets
      ansible.builtin.dnf:
        name: "*"
        state: latest
        update_cache: yes
      register: dnf_result

    - name: Afficher le résultat de la mise à jour
      ansible.builtin.debug:
        msg: "Changements : {{ dnf_result.changed }}"

    - name: Nettoyer le cache DNF
      ansible.builtin.dnf:
        autoremove: yes

    - name: Vérifier si un redémarrage est nécessaire (needs-restarting)
      ansible.builtin.command: needs-restarting -r
      register: reboot_required
      failed_when: false  # La commande retourne 1 si reboot nécessaire
      changed_when: false

    - name: Redémarrer si nécessaire
      ansible.builtin.reboot:
        msg: "Redémarrage post-mise à jour"
        reboot_timeout: 300
      when: reboot_required.rc == 1

Concept — idempotence et register :
Le mot-clé register stocke la sortie d'une tâche dans une variable. changed indique si quelque chose a réellement été modifié. L'idempotence garantit qu'une tâche déjà effectuée ne sera pas ré-exécutée inutilement — c'est fondamental pour Ansible.

Concept — become: true :
Ansible se connecte en tant qu'utilisateur non-root et élève les privilèges via sudo grâce à become: true. Il est déconseillé de se connecter directement en root via SSH.

4.5 Exécution du playbook

# Exécution normale
ansible-playbook -i inventory.ini update_servers.yml

# Mode "check" (dry-run) : voir ce qui serait fait sans rien modifier
ansible-playbook -i inventory.ini update_servers.yml --check

# Mode verbose pour le débogage
ansible-playbook -i inventory.ini update_servers.yml -v   # verbose
ansible-playbook -i inventory.ini update_servers.yml -vvv # très verbose

# Cibler uniquement un groupe
ansible-playbook -i inventory.ini update_servers.yml --limit debian_servers

# Demander le mot de passe SSH (connexion par mot de passe, sans clé déployée)
ansible-playbook -i inventory.ini update_servers.yml --ask-pass

# Demander le mot de passe sudo (élévation de privilèges via become: true)
ansible-playbook -i inventory.ini update_servers.yml --ask-become-pass

# Combiner les deux (connexion par mot de passe + sudo)
ansible-playbook -i inventory.ini update_servers.yml --ask-pass --ask-become-pass

Concept — --ask-pass vs --ask-become-pass : Ces deux options couvrent deux étapes distinctes et indépendantes :

--ask-pass concerne l'authentification SSH — le mot de passe pour se connecter au serveur distant. Nécessaire si aucune clé SSH n'a été déployée (ssh-copy-id). Une fois les clés en place, cette option devient inutile.

--ask-become-pass concerne l'élévation de privilèges — le mot de passe sudo utilisé quand become: true est présent dans le playbook. Inutile si l'utilisateur a NOPASSWD dans /etc/sudoers, ou si on se connecte directement en root.

En production, l'objectif est de n'avoir besoin d'aucune des deux : les clés SSH éliminent --ask-pass, et NOPASSWD ou une connexion root directe éliminent --ask-become-pass.

4.6 Playbook optimisé — gestion unifiée avec when

Pour un playbook plus élégant gérant les deux distributions en un seul play :

---
- name: Mise à jour unifiée de tous les serveurs
  hosts: all_servers
  become: true
  tasks:

    - name: Mise à jour via APT (Debian/Ubuntu)
      ansible.builtin.apt:
        update_cache: yes
        upgrade: full
        autoremove: yes
      when: ansible_facts['os_family'] == 'Debian'

    - name: Mise à jour via DNF (RHEL/Rocky/Fedora)
      ansible.builtin.dnf:
        name: "*"
        state: latest
        autoremove: yes
      when: ansible_facts['os_family'] == 'RedHat'

    - name: Récupérer les facts système
      ansible.builtin.setup:
        gather_subset:
          - distribution

Concept — ansible_facts et when :
Ansible collecte automatiquement des facts (informations) sur chaque serveur au début d'un play : OS, distribution, version, interfaces réseau, mémoire, etc. La directive when permet d'exécuter une tâche de façon conditionnelle. ansible_facts['os_family'] vaut 'Debian' pour Debian/Ubuntu et 'RedHat' pour Rocky/RHEL/CentOS/Fedora.

6. Récapitulatif des commandes clés

Action Debian Rocky Linux
Rafraîchir les dépôts apt update dnf check-update
Mettre à jour apt full-upgrade dnf upgrade
Historique dpkg --get-selections dnf history
Logs système journalctl -b -p err journalctl -b -p err
Logs service journalctl -u service -f journalctl -u service -f
Espace journal journalctl --disk-usage journalctl --disk-usage
Action Debian (apt) Rocky Linux (dnf)
Installer un paquet apt install vim dnf install vim
Supprimer un paquet apt remove vim dnf remove vim
Supprimer + config apt purge vim dnf remove vim (pas d'équivalent purge)
Rechercher un paquet apt search vim dnf search vim
Infos sur un paquet apt show vim dnf info vim
Lister les installés apt list --installed dnf list installed
Nettoyer les orphelins apt autoremove --purge dnf autoremove
Vider le cache apt clean dnf clean all
Action SSH Commande
Générer une clé ssh-keygen -t ed25519 -C "commentaire"
Déployer la clé ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host
Tester sans mdp ssh user@host "uptime"
Déboguer SSH ssh -vvv user@host
Clés chargées ssh-add -l
Action Ansible Commande
Tester la connectivité ansible all -i inventory.ini -m ping
Cibler un groupe ansible debian_servers -i inventory.ini -m ping
Commande ad-hoc ansible all -i inventory.ini -m command -a "uptime"
Lancer un playbook ansible-playbook -i inventory.ini update_servers.yml
Dry-run (simulation) ansible-playbook -i inventory.ini update_servers.yml --check
Cibler un hôte/groupe ansible-playbook -i inventory.ini update_servers.yml --limit debian_servers
Mot de passe SSH ansible-playbook -i inventory.ini update_servers.yml --ask-pass
Mot de passe sudo ansible-playbook -i inventory.ini update_servers.yml --ask-become-pass
Verbose ansible-playbook -i inventory.ini update_servers.yml -v
Très verbose (debug) ansible-playbook -i inventory.ini update_servers.yml -vvv
Reprendre après échec ansible-playbook -i inventory.ini update_servers.yml --start-at-task "nom"
Vérifier la syntaxe ansible-playbook -i inventory.ini update_servers.yml --syntax-check

7. Ressources

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment