Installation d’openSUSE Leap 15.6 : une configuration Linux stable à conserver pendant des années

Pourquoi Leap 15.6 est la distribution « à garder pendant des années »

Leap est le choix à faire quand vous tenez à vos week-ends. Il ne cherche pas à être le plus récent. Il vise à être correct, cohérent et maintenable. Idée clé : vous obtenez une distribution qui suit une base stable de SUSE Linux Enterprise, avec une surcouche communautaire qui la rend accessible.

Pour des charges proches de la production — services de lab à domicile, serveurs de petites entreprises, postes de développement qui doivent aussi lancer Zoom sans fondre — Leap se comporte comme un locataire de longue durée. Il paie son loyer à temps. Il ne fait pas la fête.

Ce qui rend Leap particulièrement install-and-forget, c’est la combinaison de :

• YaST pour la configuration système lisible des années plus tard, y compris stockage et réseau.
• Btrfs + Snapper intégrés qui transforment de nombreux incidents « je crois qu’on réinstalle » en « restauration et on continue ».
• zypper et ses workflows de correctifs qui s’alignent bien avec la gestion de changement contrôlée.
• AppArmor comme couche de durcissement pragmatique réellement utilisée et maintenue.

Une opinion d’entrée de jeu : si vous voulez « tout le plus récent », ce n’est pas votre distro. Si vous voulez « je peux expliquer chaque changement à un auditeur », vous êtes chez vous.

Faits et contexte intéressants (ce qui explique la culture)

1. openSUSE a deux personnalités par conception : Tumbleweed (rolling) et Leap (stable). Cette séparation est intentionnelle, pas un compromis.
2. YaST précède la plupart des installateurs Linux modernes : c’est un trait distinctif de SUSE depuis des décennies, et le module de stockage reste un des meilleurs outils « voir tout en un seul endroit ».
3. La base de Leap est liée au travail entreprise de SUSE : le conservatisme est hérité. C’est pourquoi il semble plus lent — et pourquoi il casse moins.
4. Btrfs est devenu un défaut sur openSUSE plus tôt que sur la plupart des distributions : pas parce que c’était tendance, mais parce que snapshots et rollbacks réduisent la charge du support.
5. Le modèle « pré/post » de Snapper encode la gestion du changement dans les outils : il transforme les opérations de paquets en états système auditable.
6. Le concept de correctif de zypper est un workflow à part entière : ce n’est pas juste « tout mettre à jour » ; c’est « appliquer un ensemble de correctifs validés ».
7. AppArmor est historiquement une force chez SUSE : philosophie différente de SELinux, centré sur les profils, généralement plus simple à opérationnaliser pour des équipes mixtes.
8. Wicked existe parce que le réseau en entreprise est compliqué : NetworkManager est excellent pour les portables ; les serveurs veulent souvent un comportement déclaratif et ennuyeux.
9. openSUSE a longtemps considéré le packaging et les pipelines de build comme une compétence centrale : la culture attend de la reproductibilité, pas de l’improvisation.

Décisions importantes avant de démarrer l’installateur

Choisir la cible d’installation : poste, serveur ou « une machine qui fait tout »

Soyez honnête. Si cette machine est un serveur, n’installez pas un environnement de bureau « au cas où ». Les interfaces graphiques sont acceptables, mais les piles GUI augmentent la rotation : plus de paquets, plus de mises à jour, plus d’éléments mobiles.

• Serveur : système minimal, SSH, firewalld, NTP, vos services.
• Poste de travail : KDE Plasma est un bon choix par défaut sur Leap. GNOME fonctionne aussi. Choisissez-en un.
• Machine de laboratoire unique : installez quand même minimal + une UI légère si nécessaire. Évitez d’installer « tous les environnements de bureau ». C’est comme ça qu’on se retrouve à déboguer deux piles audio sur un serveur.

Choix du système de fichiers : Btrfs quand c’est utile, XFS quand c’est ennuyeux

Le root par défaut sur Btrfs de Leap est une fonctionnalité, pas une mise en scène. Les snapshots et rollbacks vous sauvent quand les mises à jour tournent mal. Mais ne mettez pas tout sur Btrfs simplement parce que c’est là.

Mon choix par défaut :

• / sur Btrfs avec Snapper activé.
• /home sur XFS pour un poste de travail (simple, rapide, peu de drame) ou sur Btrfs si vous tenez aux snapshots des données utilisateur et acceptez la complexité opérationnelle.
• /var/lib pour les bases de données sur XFS (ou ext4) sauf si vous avez une raison claire d’utiliser Btrfs et que vous comprenez le comportement copy-on-write et le tuning.

Blague n°1 : Les snapshots Btrfs sont comme les ceintures de sécurité — vous ne les remarquez que quand quelque chose essaie de gâcher votre journée.

Partitionnement et démarrage : UEFI, GPT et « ne soyez pas créatif »

Utilisez UEFI si votre matériel le supporte. Utilisez GPT. Créez une partition système EFI (ESP) d’au moins 512 MiB. Ne partagez pas les ESP entre trop d’installations OS à moins d’aimer l’archéologie.

Si vous prévoyez le chiffrement disque, décidez maintenant : chiffrement complet pour les portables, chiffrement sélectif pour les serveurs (souvent juste les volumes de données). Si vous avez besoin d’un redémarrage sans intervention après une panne de courant, laissez root non chiffré ou utilisez un déverrouillage basé sur TPM avec un plan testé.

Pile réseau : Wicked pour les serveurs, NetworkManager pour les portables

Wicked est excellent quand vous voulez « l’interface monte de la même façon à chaque fois ». NetworkManager est idéal quand vous vous déplacez entre des réseaux Wi‑Fi. Ne les mélangez pas sans raison.

Discipline des dépôts : moins de dépôts, moins de mystères

La façon la plus rapide de transformer une distro stable en une distro fragile est d’ajouter des dépôts au hasard parce qu’un blog l’a dit. Commencez par les dépôts officiels. Ajoutez-en un seul supplémentaire seulement si vous pouvez expliquer pourquoi il existe et comment vous le supprimerez plus tard.

Guide d’installation avec paramètres par défaut argumentés

1) Support d’amorçage et paramètres du firmware

Utilisez l’ISO d’installation officielle (l’installateur hors-ligne convient aux serveurs ; l’installateur réseau si votre réseau est fiable). Dans les paramètres du firmware :

• Activez le mode UEFI.
• Désactivez le mode « RAID » s’il s’agit en réalité d’un fake RAID et que vous préférez mdadm.
• Laissez Secure Boot activé sauf si vous avez une raison concrète de le désactiver (modules noyau personnalisés, pilotes niche).

2) Sélection du pattern d’installation : rester minimal

Sur les serveurs : commencez par une installation minimale et ajoutez des paquets de façon intentionnelle. Sur les postes de travail : KDE Plasma est un choix pratique par défaut sur Leap. Il tend à bien se comporter et est bien intégré.

3) Proposition de stockage : acceptez l’esprit, modifiez les détails

YaST proposera un agencement. Il est souvent correct, mais ne l’acceptez pas aveuglément. Votre travail est de simplifier les opérations futures :

• ESP : 512 MiB–1 GiB (FAT32, monté sur /boot/efi).
• Root : Btrfs, avec snapshots activés.
• Swap : taille selon le besoin d’hibernation et la RAM. Pour les serveurs, un petit swap suffit ; pour les portables qui hibernent, égaler la RAM.
• Données : partition/LV séparé pour /var/lib (containers, bases de données) si vous allez les exécuter.

4) Utilisateurs et SSH : définir la politique maintenant

Créez un utilisateur normal. Si c’est un serveur, évitez d’activer les connexions SSH par mot de passe. Prévoyez l’authentification par clés. Si vous devez utiliser des mots de passe temporairement, fixez une date pour les supprimer.

5) Synchronisation temporelle et nom d’hôte : détails ennuyeux qui piquent plus tard

Réglez le bon fuseau horaire. Activez NTP. Choisissez un nom d’hôte qui ne vous embarrassera pas dans les logs. « server2-final » n’est pas un plan.

6) Premier redémarrage : vérifier le démarrage et l’outil de snapshots

Après la fin de l’installation, ne vous précipitez pas pour personnaliser. Confirmez d’abord que le démarrage est propre, que le réseau est stable et que les snapshots fonctionnent. Ensuite, poursuivez.

Plan de stockage : Btrfs, XFS, LVM, RAID et ce que je déploierais

Btrfs sur / : considérez-le comme un système de sécurité pour l’OS

Le root Btrfs de Leap avec Snapper est conçu autour d’une idée : la plupart des pannes surviennent pendant un changement. Si vous pouvez revenir rapidement à un état précédent de l’OS, vous réduisez le temps d’arrêt et la panique.

Ce pour quoi le root Btrfs est bon :

• Snapshots avant/après les opérations de paquets.
• Restauration rapide après une mauvaise mise à jour ou une mauvaise configuration.
• Performances raisonnables pour les fichiers système.

Ce pour quoi le root Btrfs n’est pas automatiquement idéal :

• Bases de données à fortes écritures sans tuning et compréhension du copy-on-write.
• « Installer et oublier » quand vous ne vérifiez jamais la rétention des snapshots et l’espace libre.

XFS pour les données à forte écriture

XFS est le système de fichiers adulte ennuyeux : évolutif, mature, prévisible sous de lourdes charges d’écriture. Si vous hébergez des bases de données, images de VM ou couches de conteneurs avec beaucoup de churn, XFS est généralement le défaut le plus sûr.

LVM : optionnel, mais utile pour les humains

LVM n’est pas nécessaire, mais il vaut souvent la peine sur les serveurs car il permet une croissance flexible et une séparation claire entre OS et données. YaST le rend gérable, et c’est un outil que votre futur vous reconnaîtra.

RAID logiciel : mdadm pour RAID natif Linux

Si vous avez besoin de RAID1/10 pour la disponibilité, mdadm est solide et transparent. Évitez le « fake RAID » sauf pour une raison très précise, car il complique souvent la récupération.

Si vous envisagez ZFS : c’est un excellent système de fichiers, mais il n’est pas intégré au chemin d’installation par défaut de Leap comme Btrfs. Si vous voulez « garder ça pendant des années » et minimiser les bizarreries, restez sur les valeurs par défaut sauf si vous êtes prêt à prendre en charge l’intégration.

Rétention des snapshots : ne laissez pas les sauvegardes remplir le disque

Les snapshots ne sont pas des sauvegardes. Ils vivent sur le même disque. Ils vous protègent contre les mauvais changements, pas contre un matériel mort. Pourtant, ils peuvent vous sauver — à condition de gérer la rétention et de surveiller l’espace libre.

Tâches au premier démarrage pour éviter les regrets futurs (commandes incluses)

Ci-dessous des tâches pratiques à exécuter juste après l’installation. Chacune inclut : une commande, ce que signifie la sortie, et la décision à prendre.

Tâche 1 : Confirmer la version de l’OS et du noyau

cr0x@server:~$ cat /etc/os-release
NAME="openSUSE Leap"
VERSION="15.6"
ID="opensuse-leap"
PRETTY_NAME="openSUSE Leap 15.6"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.6"

Ce que cela signifie : Vous êtes bien sur Leap 15.6, pas sur le mauvais ISO ou un système partiellement mis à niveau.

Décision : Si ce n’est pas 15.6, arrêtez-vous et corrigez votre base avant de faire quoi que ce soit d’autre. « Je mettrai à niveau plus tard » est la façon d’hériter du chaos.

Tâche 2 : Vérifier le mode de démarrage (UEFI vs legacy)

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo BIOS
UEFI

Ce que cela signifie : UEFI est utilisé. Bon pour les systèmes modernes et une gestion du démarrage prévisible.

Décision : Si vous attendiez UEFI et voyez BIOS, revenez aux paramètres du firmware avant de poursuivre l’installation.

Tâche 3 : Vérifier les systèmes de fichiers et les options de montage

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /
/dev/nvme0n1p3 btrfs rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/@/.snapshots/1/snapshot

Ce que cela signifie : Le root est en Btrfs et vous êtes sur un sous-volume snapshot (commun avec l’intégration Snapper).

Décision : Si root n’est pas Btrfs et que vous vouliez pouvoir rollback avec Snapper, corrigez cela maintenant plutôt qu’après avoir installé la moitié du monde.

Tâche 4 : Confirmer que Snapper fonctionne et a un snapshot de base

cr0x@server:~$ sudo snapper list
 # | Type   | Pre # | Date                     | User | Cleanup | Description | Userdata
---+--------+-------+--------------------------+------+---------+-------------+---------
0  | single |       |                          | root |         | current     | 
1  | single |       | 2026-02-05 09:18:24      | root |         | first root filesystem | 

Ce que cela signifie : Snapper voit au moins un snapshot. Le système peut restaurer l’état de l’OS si nécessaire.

Décision : Si Snapper n’est pas configuré, décidez si vous le voulez. Sur Leap, je le recommande généralement pour /.

Tâche 5 : Inspecter les périphériques bloc et confirmer que vous êtes sur le disque attendu

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
NAME        SIZE TYPE FSTYPE MOUNTPOINTS
nvme0n1   953.9G disk        
├─nvme0n1p1   1G part vfat   /boot/efi
├─nvme0n1p2  32G part swap   [SWAP]
└─nvme0n1p3 920G part btrfs  / /.snapshots

Ce que cela signifie : Le partitionnement correspond aux attentes : ESP, swap et root Btrfs.

Décision : Si vous voyez votre disque de données utilisé accidentellement pour root, arrêtez-vous et corrigez cela avant d’y stocker quelque chose de précieux.

Tâche 6 : Vérifier l’espace libre comme Btrfs le voit

cr0x@server:~$ sudo btrfs filesystem usage /
Overall:
    Device size:                 920.00GiB
    Device allocated:             60.00GiB
    Device unallocated:          860.00GiB
    Used:                         18.50GiB
    Free (estimated):            900.00GiB      (min: 900.00GiB)
    Data ratio:                       1.00
    Metadata ratio:                   1.00

Ce que cela signifie : Beaucoup de marge ; les allocations sont saines.

Décision : Si les métadonnées sont presque pleines alors que l’espace libre semble correct, vous devez rééquilibrer ou ajuster la rétention des snapshots. Btrfs peut échouer de manière surprenante quand les métadonnées se remplissent.

Tâche 7 : Valider les dépôts (et attraper tôt la dérive « dépôt aléatoire »)

cr0x@server:~$ sudo zypper lr -u
#  | Alias                       | Name                        | Enabled | GPG Check | Refresh | URI
---+-----------------------------+-----------------------------+---------+-----------+---------+---------------------------
1  | repo-oss                    | Main Repository (OSS)       | Yes     | (r ) Yes  | Yes     | https://download...
2  | repo-non-oss                | Main Repository (NON-OSS)   | Yes     | (r ) Yes  | Yes     | https://download...
3  | repo-update                 | Update Repository (OSS)     | Yes     | (r ) Yes  | Yes     | https://download...

Ce que cela signifie : Vous avez une base propre : dépôts principaux plus updates.

Décision : Si vous voyez une pile de dépôts tiers dès le premier jour, demandez qui les a ajoutés et pourquoi. Réduisez-les maintenant. La stabilité est un régime, pas une vitamine.

Tâche 8 : Appliquer les correctifs de sécurité (axé sur les patches, pas « mise à jour totale »)

cr0x@server:~$ sudo zypper patch
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 3 patches are going to be installed:
  openSUSE-SLE-15.6-2026-1234 security  openssl security update
  openSUSE-SLE-15.6-2026-2345 security  openssh security update
  openSUSE-SLE-15.6-2026-3456 recommended  systemd bugfix update

3 patches to install.
Overall download size: 4.2 MiB. Already cached: 0 B. After the operation, additional 12.0 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): y

Ce que cela signifie : Vous appliquez des correctifs triés sur le volet. C’est généralement plus sûr qu’une mise à jour complète quand vous voulez un changement contrôlé.

Décision : Sur les serveurs, privilégiez zypper patch de façon routinière ; planifiez les mises à jour complètes quand vous pouvez tester et redémarrer.

Tâche 9 : Confirmer les services et la santé du démarrage

cr0x@server:~$ systemctl --failed
0 loaded units listed.

Ce que cela signifie : Aucune unité systemd n’est actuellement en échec.

Décision : Si vous avez des unités en échec, corrigez-les maintenant pendant que le système est frais et que l’écart avec l’état « fonctionnel » est petit.

Tâche 10 : Vérifier les derniers logs de démarrage pour les avertissements importants

cr0x@server:~$ sudo journalctl -b -p warning --no-pager | tail -n 8
Feb 05 09:22:11 server kernel: ACPI: \_SB.PCI0... AE_NOT_FOUND
Feb 05 09:22:12 server systemd[1]: Found device /dev/disk/by-uuid/...
Feb 05 09:22:14 server wicked[915]: eth0: link detected
Feb 05 09:22:15 server chronyd[1022]: System clock was stepped by 0.423 seconds

Ce que cela signifie : Les avertissements peuvent être du bruit firmware ou des problèmes réels. Le pas de temps de chrony au premier démarrage est normal.

Décision : Si vous voyez des erreurs d’E/S disque répétées, des fluctuations réseau ou des avertissements de système de fichiers, enquêtez avant de déployer des services.

Tâche 11 : Confirmer la synchronisation temporelle (parce que les certificats et clusters détestent le voyage dans le temps)

cr0x@server:~$ timedatectl status
               Local time: Thu 2026-02-05 09:25:21 UTC
           Universal time: Thu 2026-02-05 09:25:21 UTC
                 RTC time: Thu 2026-02-05 09:25:21
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Ce que cela signifie : L’horloge est synchronisée et NTP est actif.

Décision : Si elle n’est pas synchronisée, corrigez l’heure avant de déboguer TLS, Kerberos ou des échecs d’auth « aléatoires ».

Tâche 12 : Confirmer la pile de gestion réseau (Wicked vs NetworkManager)

cr0x@server:~$ systemctl is-active wicked NetworkManager
active
inactive

Ce que cela signifie : Wicked gère le réseau, NetworkManager n’est pas actif. C’est une posture serveur sensée.

Décision : Si les deux sont actifs, choisissez-en un. Le double contrôle conduit à « ça marche jusqu’au redémarrage ».

Tâche 13 : Confirmer l’état du pare-feu et la zone par défaut

cr0x@server:~$ sudo firewall-cmd --state
running

cr0x@server:~$ sudo firewall-cmd --get-default-zone
public

Ce que cela signifie : firewalld est actif ; la zone par défaut est public (typiquement restrictive).

Décision : Gardez-le actif. N’ouvrez que ce dont vous avez besoin. « Je vais désactiver le pare-feu pendant les tests » a un long palmarès de regrets.

Tâche 14 : Vérifier CPU, pression mémoire et posture du swap

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi       1.2Gi        27Gi       120Mi       2.8Gi        29Gi
Swap:           32Gi          0B        32Gi

Ce que cela signifie : Beaucoup de RAM libre ; swap inutilisé (normal sur un système au repos).

Décision : Si le swap est fortement utilisé en charge normale, vous avez probablement une pression mémoire ou une charge mal dimensionnée.

Tâche 15 : Vérifier rapidement la santé du disque (exemple NVMe)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | sed -n '1,18p'
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.14.21-lp156.12-default] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       ACME NVMe 1TB
Serial Number:                      ABCD123456
Firmware Version:                   1.0.3
PCI Vendor/Subsystem ID:            0x1234
IEEE OUI Identifier:                0xdeadbe
Total NVM Capacity:                 1,000,204,886,016 [1.00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      0
NVMe Version:                       1.4
Number of Namespaces:               1
Namespace 1 Size/Capacity:          1,000,204,886,016 [1.00 TB]
Namespace 1 Utilization:            54,321,098,752 [54.3 GB]

Ce que cela signifie : Les données SMART sont lisibles ; le modèle et le firmware sont identifiés.

Décision : Si SMART ne peut pas lire ou affiche des avertissements critiques, ne faites pas confiance au disque pour des données importantes.

Tâche 16 : Confirmer qu’AppArmor est activé

cr0x@server:~$ sudo aa-status | sed -n '1,10p'
apparmor module is loaded.
30 profiles are loaded.
28 profiles are in enforce mode.
2 profiles are in complain mode.
0 profiles are in kill mode.

Ce que cela signifie : AppArmor est actif, la plupart des profils sont en mode enforce.

Décision : Gardez-le en enforce sauf si vous avez un problème précis de compatibilité. Si vous devez l’assouplir, faites-le par service, pas globalement.

Tâche 17 : Vérifier les bases de la politique SSH

cr0x@server:~$ sudo sshd -T | egrep '^(permitrootlogin|passwordauthentication|pubkeyauthentication)'
permitrootlogin no
passwordauthentication no
pubkeyauthentication yes

Ce que cela signifie : La connexion root est bloquée ; l’authentification par mot de passe SSH est désactivée ; les clés sont activées.

Décision : C’est le minimum souhaitable pour des serveurs. Si vous avez besoin d’un accès par mot de passe temporaire, mettez un rappel pour le supprimer le jour même.

Stratégie de mises à jour : zypper, correctifs et quand être prudent

Leap récompense les fenêtres de changement prévisibles. N’adoptez pas le « tout mettre à jour en continu » si vous voulez de la stabilité. Au lieu de cela :

• Cadence routinière : appliquez les correctifs de sécurité et recommandés avec zypper patch.
• Mises à jour contrôlées : planifiez zypper update ou zypper dup seulement lorsque vous souhaitez un changement plus large (et quand vous pouvez redémarrer).
• Workflow conscient des snapshots : assurez-vous que Snapper crée des snapshots pré/post pour les opérations de paquets. Si quelque chose casse, le rollback est un plan, pas une prière.

Revenir en arrière après un mauvais changement

Quand une mise à jour casse le démarrage ou un service, la voie de récupération doit être procédurale. Sur un root Btrfs+Snapper, vous pouvez souvent revenir en arrière.

cr0x@server:~$ sudo snapper list | tail -n 5
98  | pre    |       | 2026-02-05 10:12:01 | root | number | zypp(zypper patch) | 
99  | post   | 98    | 2026-02-05 10:13:12 | root | number | zypp(zypper patch) | 
100 | single |       | 2026-02-05 10:20:44 | root | number | before-nginx-config | 

Ce que cela signifie : Vous avez une paire pré/post autour du patching et un snapshot manuel « before config ».

Décision : Si le système a planté après le patch n°99, vous savez quoi tester ou sur quel snapshot revenir. Vous ne devinez pas.

Un principe directeur, issu de l’ingénierie de la fiabilité : « L’espoir n’est pas une stratégie. » — Gene Kranz

Base de sécurité : pare-feu, SSH, AppArmor et journalisation

Pare-feu : n’ouvrez des ports que lorsque le service est prêt

Sur les serveurs, gardez la zone par défaut restrictive. Ajoutez des services explicitement. Exemple : autoriser SSH et (uniquement si nécessaire) HTTP/HTTPS.

cr0x@server:~$ sudo firewall-cmd --permanent --add-service=ssh
success

cr0x@server:~$ sudo firewall-cmd --reload
success

cr0x@server:~$ sudo firewall-cmd --list-services
ssh

Ce que cela signifie : SSH est autorisé ; rien d’autre n’est implicitement exposé.

Décision : N’ouvrez pas de ports pour des « services futurs ». Ouvrez-les quand le service est installé, configuré et supervisé.

SSH : clés, pas de root, surface d’attaque minimale

Définissez PasswordAuthentication no, PermitRootLogin no. Gardez une voie de secours : accès console ou gestion hors bande si c’est de la vraie production.

Journalisation : on ne peut pas déboguer ce qu’on n’a pas enregistré

Le journal systemd est puissant, mais ne le traitez pas comme un stockage infini. Si c’est un serveur, décidez où vivent les logs et combien de temps vous les conservez. Si vous expédiez les logs de façon centrale, commencez tôt — la collecte de logs rétroactive est un mythe.

AppArmor : appliquer, ne pas désactiver

AppArmor n’est pas juste du « théâtre de sécurité » sur Leap ; il est intégré à la façon dont les services sont supposés fonctionner. Si vous rencontrez une violation de profil, mettez ce profil en complain mode tactiquement pour ce service, apprenez ce dont il a besoin, puis réappliquez-enforce.

Trois mini-histoires d’entreprise (ce qui tourne réellement mal)

Incident : la mauvaise hypothèse (« les snapshots sont des sauvegardes »)

Une société de taille moyenne faisait tourner quelques services internes sur un hôte VM basé sur Leap. Ils aimaient les snapshots Btrfs. Ils avaient des snapshots hebdomadaires et se sentaient en sécurité. L’équipe admin avait même pratiqué le rollback après une mauvaise mise à jour de paquet une fois. La confiance augmenta.

Puis un array de stockage eut un problème de contrôleur. Pas une panne totale — juste assez de corruption et de timeouts pour que l’hyperviseur marque le datastore comme non sain. Les VM furent mises en pause, puis certains disques revinrent, puis repartirent. C’était le pire type de panne : intermittente et bruyante.

L’instinct de l’équipe fut « restaurer les snapshots ». Cela fonctionna pour une VM… brièvement. Puis les défauts de stockage sous-jacents réapparurent. Les snapshots, bien sûr, résident sur le même stockage. Ils protègent contre les mauvais changements, pas contre un matériel défaillant ou une mauvaise journée dans le SAN.

La longue nuit fut passée à restaurer depuis un système de sauvegarde réel qu’ils avaient — simplement pas testé aussi récemment qu’il le fallait. Leur post-mortem fut franc : l’hypothèse n’était pas malveillante, elle était juste paresseuse sur le plan sémantique. Snapshot n’est pas sauvegarde. Même disque = même domaine de défaillance.

Ce qui changea ensuite était ennuyeux et correct : tests de restauration mensuels, et un widget de tableau de bord qui montre la fraîcheur des sauvegardes à côté du nombre de snapshots. L’équipe arrêta de se disputer sur les mots et commença à mesurer la récupération.

Optimisation qui a mal tourné : « on va tuner pour la vitesse »

Une autre organisation avait une flotte Leap 15.x exécutant des services conteneurisés. Quelqu’un remarqua des pics d’utilisation disque et d’E/S pendant les heures de pointe et décida que le système « gaspillait du temps » sur le comportement copy-on-write pour les couches de conteneur.

Ils firent un changement rapide : ils déplacèrent le stockage des conteneurs sur le root Btrfs et commencèrent à expérimenter des options de montage et des politiques de nettoyage agressives. Le système sembla plus rapide sous des tests synthétiques. Tout le monde fut content. Un ticket fut clos avec le mot « optimisé ».

Deux semaines plus tard, le premier incident réel : un nœud redémarra après un patch et remonta avec des plaintes de système de fichiers et des couches de conteneurs manquantes. Pas toujours — juste parfois. Il s’avéra que la politique de nettoyage, combinée à la rétention des snapshots et au churn, créait une pression sur les métadonnées et des schémas de fragmentation qui rendaient la récupération imprévisible.

Ils revinrent à une conception plus simple : garder Btrfs pour l’OS, mettre les chemins d’écriture intense des conteneurs et bases de données sur XFS, et conserver une rétention de snapshots raisonnable. Les performances revinrent à « un peu moins excitantes », et la disponibilité redevint « ennuyeusement cohérente ». L’équipe apprit aussi une leçon qu’on devrait broder sur un coussin : l’optimisation sans stratégie de sortie n’est qu’une expérimentation en production.

Pratique ennuyeuse qui a sauvé la mise : fenêtres de changement + vérifications préalables

Une petite entreprise du secteur financier utilisait des serveurs Leap pour des applications internes. Ils n’étaient pas flashy. Ils avaient une fenêtre de patch mensuelle, une checklist, et l’habitude de prendre un snapshot manuel avec un label lisible par un humain avant tout changement important.

Un mois, un patch de routine introduisit une régression subtile pour un pilote niche utilisé par leur workflow de numérisation. Le service ne planta pas brutalement. Il ralentit, puis se figea sous charge. Les utilisateurs signalèrent « c’est buggé » plutôt que « c’est en panne ». Ce sont les tickets qui pourrissent vos journées.

Parce qu’ils avaient une checklist, l’astreint ne commença pas à déboguer l’application du fournisseur de scanner. Il suivit le script : confirmer que la régression coïncide avec le patch, comparer les logs entre les snapshots pré/post, et rollbacker le snapshot OS sur un serveur canari.

Le canari redevint instantanément sain. Ils rollbackèrent les autres serveurs, figèrent la version du paquet fautif, et ouvrirent un ticket fournisseur avec logs et versions exactes des paquets. Pas de drame. Pas d’héroïsme. Juste une équipe qui traitait l’exploitation comme un processus, pas comme une vibe.

Playbook de diagnostic rapide (trouver le goulot d’étranglement vite)

Quand un système Leap semble lent ou « cassé », vous ne commencez pas par réinstaller des paquets. Vous commencez par localiser la contrainte. Voici l’ordre qui permet de trouver la vérité rapidement et de manière constante.

Premier point : s’agit-il d’une panne systémique ou d’un seul service ?

cr0x@server:~$ uptime
 09:41:03 up  1:12,  2 users,  load average: 6.21, 5.98, 5.10

Interprétation : Une charge élevée peut signifier saturation CPU, accumulation de tâches prêtes à tourner, ou I/O bloquées (la charge inclut le sommeil ininterruptible).

Décision : Si la charge est élevée, passez au triage CPU/mémoire/I/O. Si la charge est normale, concentrez-vous sur le service spécifique et ses dépendances.

Deuxième point : CPU vs mémoire vs I/O (choisir le bon combat)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 2780000  42000 820000    0    0    12    25  220  410 8  2 89  1  0
 7  3      0  120000  43000 790000    0    0  8800  9200 1200 3500 10  5 40 45  0

Interprétation : La colonne b (processus bloqués) et un wa élevé (attente I/O) indiquent un goulet d’étranglement stockage.

Décision : Si wa est élevé, arrêtez d’accuser l’application. Regardez la latence disque, le système de fichiers et le matériel sous-jacent.

Troisième point : trouver le processus le plus chaud, puis vérifier qu’il est la cause

cr0x@server:~$ top -b -n 1 | head -n 15
top - 09:42:55 up  1:14,  2 users,  load average: 6.80, 6.05, 5.20
Tasks: 214 total,   3 running, 211 sleeping,   0 stopped,   0 zombie
%Cpu(s): 11.0 us,  4.0 sy,  0.0 ni, 40.0 id, 45.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  32000.0 total,   118.0 free,  1250.0 used,  30632.0 buff/cache
MiB Swap:  32768.0 total, 32768.0 free,     0.0 used.  30100.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 3221 postgres  20   0 3248000 220000  12000 D  12.0   0.7   0:34.11 postgres

Interprétation : Un processus en état D (sommeil ininterruptible) couplé à un wa élevé suggère fortement des blocages de stockage.

Décision : Passez aux vérifications du stockage. Ne redémarrez pas les services à l’aveugle ; vous ajouteriez juste une charge de récupération à un disque déjà en difficulté.

Quatrième point : latence et erreurs de stockage (les tueurs silencieux)

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
         10.70    0.00    4.10   44.90    0.00   40.30

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  r_await  w_await
nvme0n1          85.0   120.0  9800.0 11000.0     0.0     5.0   98.0    12.4    35.8

Interprétation : %util proche de 100 et un await élevé indiquent que le disque est saturé ou en mauvais état, ou que vous atteignez un problème de file d’attente.

Décision : Si la latence est élevée, vérifiez SMART, dmesg/journal pour des erreurs I/O, et les patterns de charge. Envisagez de déplacer les chemins très écrivants hors du root Btrfs.

Cinquième point : réseau, mais seulement après avoir innocenté disque et CPU

cr0x@server:~$ ss -s
Total: 278
TCP:   41 (estab 25, closed 8, orphaned 0, timewait 6)

Transport Total     IP        IPv6
RAW       0         0         0
UDP       7         5         2
TCP       33        22        11
INET      40        27        13
FRAG      0         0         0

Interprétation : Donne une vue rapide de la charge des sockets ; ce n’est pas une analyse profonde mais utile pour « sommes-nous noyés sous les connexions ? »

Décision : Si le nombre de connexions semble anormal, examinez le service et les load balancers en amont, puis vérifiez les erreurs NIC et DNS.

Erreurs courantes : symptômes → cause racine → correctif

1) « Après les mises à jour, le système ne démarre plus »

Symptômes : Le démarrage bascule sur un shell d’urgence, ou la pile de services ne démarre plus après le patch.

Cause racine : Mismatch kernel/initramfs, mauvais pilote mis à jour, ou montage de système de fichiers mal configuré introduit lors du changement.

Correctif : Utilisez le rollback Snapper (si root en Btrfs) pour revenir au snapshot pré-update ; puis réappliquez les correctifs en mode canari.

2) « Le disque est plein mais df montre de l’espace » (édition Btrfs)

Symptômes : Les écritures échouent ; les services plantent ; df -h semble correct.

Cause racine : Exhaustion des métadonnées Btrfs ou rétention de snapshots consommant l’espace alloué.

Correctif : Vérifiez btrfs filesystem usage /, taillez les snapshots Snapper et envisagez un rebalance. Mettez en place des politiques de nettoyage de snapshots sensées.

3) « Le réseau fonctionne jusqu’au redémarrage »

Symptômes : ip addr add fonctionne manuellement ; après reboot c’est disparu ; parfois le Wi‑Fi disparaît.

Cause racine : Gestionnaires réseau concurrents (Wicked et NetworkManager), ou configuration éditée dans un outil mais gérée par l’autre.

Correctif : Choisissez un gestionnaire. Sur les serveurs : désactivez NetworkManager. Sur les portables : désactivez Wicked. Conservez les configurations dans l’outil approprié.

4) « SSH refuse soudainement les connexions »

Symptômes : Des clés qui marchaient cessent de fonctionner après durcissement ou mises à jour.

Cause racine : Permissions/ownership de ~/.ssh ou authorized_keys trop permissives ; ou le home de l’utilisateur sur un système de fichiers monté avec des options inattendues.

Correctif : Corrigez les permissions et confirmez la configuration sshd. Validez avec sshd -T et les logs du journal.

5) « AppArmor a cassé mon service »

Symptômes : Le service démarre puis échoue, avec des opérations refusées dans les logs.

Cause racine : Le profil AppArmor bloque un nouveau chemin, socket ou capability introduit par des changements de configuration.

Correctif : Mettez ce profil en complain mode temporairement, ajustez le profil, puis revenez en enforce. Ne désactivez pas AppArmor globalement.

6) « zypper affiche des conflits et un enfer de dépendances »

Symptômes : zypper veut changer de vendor des paquets ou supprimer la moitié du système.

Cause racine : Trop de dépôts, priorités mismatch, ou mélange de Leap et de dépôts tiers incompatibles.

Correctif : Supprimez ou désactivez les dépôts non essentiels, alignez les vendors, et gardez l’ensemble des dépôts minimal. Si vous devez utiliser des extras, documentez la propriété et le plan de rollback.

Listes de vérification / plan étape par étape

Checklist d’installation (30 minutes, sans héros)

1. Firmware : UEFI activé, mode disque correct sélectionné, politique Secure Boot décidée.
2. Cible d’installation : serveur minimal vs poste de travail choisi consciemment.
3. Stockage : ESP ≥ 512 MiB, root sur Btrfs, décider de l’emplacement de /home et /var/lib.
4. Gestionnaire réseau : Wicked pour serveur, NetworkManager pour portable.
5. Utilisateurs : créer un administrateur non-root ; planifier les clés SSH.
6. Temps : activer NTP, définir le fuseau horaire.
7. Redémarrer et vérifier : démarrage propre, dépôts sains, Snapper opérationnel.

Checklist de durcissement post-install (premier jour)

1. Patch : exécuter zypper patch ; redémarrer si noyau/systemd ont été mis à jour.
2. SSH : désactiver l’auth par mot de passe ; désactiver login root ; vérifier avec sshd -T.
3. Pare-feu : n’autoriser que les services requis ; confirmer la zone et les règles actives.
4. Supervision : collecter au minimum journalctl, santé SMART disque, et utilisation des systèmes de fichiers.
5. Snapshots : confirmer la politique de rétention et assurer une marge d’espace libre.
6. Sauvegardes : implémenter de vraies sauvegardes ; tester la restauration.

Checklist de sanity stockage (avant de lancer bases/containers)

1. Confirmer où vivront les données à forte écriture (préférer XFS pour les chemins à churn élevé).
2. S’assurer d’avoir des systèmes de fichiers/volumes séparés pour contrôler le rayon d’impact.
3. Valider la santé des disques avec SMART et passer en revue les logs du noyau pour erreurs I/O.
4. Décider du niveau RAID et du domaine de défaillance ; tester un scénario dégradé si possible.

Blague n°2 : Si vous ne testez pas vos restaurations, votre système de sauvegarde n’est qu’un endroit très coûteux pour stocker de l’optimisme.

FAQ

Dois-je choisir Leap 15.6 ou Tumbleweed ?

Si la machine doit être prévisible et peu gourmande en maintenance, choisissez Leap. Si vous avez besoin des noyaux, pilotes et stacks développeur les plus récents et pouvez tolérer l’instabilité, choisissez Tumbleweed.

Btrfs est-il sûr comme système de fichiers root ?

Oui, particulièrement sur Leap où c’est le défaut et intégré avec Snapper. Utilisez-le comme filet de sécurité pour l’OS. Pour les données à fortes écritures, envisagez XFS sur des volumes dédiés.

Les snapshots sont-ils équivalents à des sauvegardes ?

Non. Les snapshots sont des vues point-in-time sur le même disque. Les sauvegardes doivent résider sur un stockage séparé (idéalement un domaine de défaillance distinct) et être testées en restauration.

Dois-je utiliser Wicked ou NetworkManager ?

Serveurs : Wicked. Portables/bureaux avec roaming Wi‑Fi : NetworkManager. Choisissez-en un pour éviter les comportements conflictuels.

Quelle est la commande de mise à jour la plus sûre sur Leap ?

zypper patch pour les correctifs de sécurité/recommandés. Planifiez les mises à jour plus larges délibérément, et redémarrez quand les composants critiques changent.

Comment revenir en arrière après une mauvaise mise à jour ?

Si root est en Btrfs avec Snapper, utilisez les snapshots : identifiez le snapshot pré-change et restaurez. Si vous n’utilisez pas Snapper, votre rollback est « restaurer depuis la sauvegarde ou reconstruire », ce qui est plus lent et risqué.

Dois-je désactiver AppArmor pour exécuter des conteneurs ou services web ?

Généralement non. Si un profil bloque votre service, ajustez ce profil ou mettez-le en complain pendant le diagnostic. Désactiver AppArmor globalement est un instrument trop brutal.

Quel est le meilleur système de fichiers pour une base de données sur Leap ?

Souvent XFS (ou ext4) sur un volume dédié. Si vous utilisez Btrfs, faites-le en connaissance de cause et testez les performances et le comportement en cas de panne sous votre charge.

Comment maintenir stable ma configuration de dépôts ?

Gardez les dépôts minimaux, privilégiez les sources officielles, et évitez de mélanger des dépôts incompatibles. Si vous ajoutez un dépôt, documentez pourquoi, ce qu’il fournit et comment le retirer proprement.

Quelle est la manière la plus rapide de diagnostiquer « le serveur est lent » ?

Vérifiez la charge et l’I/O wait, puis la latence disque et SMART, ensuite la pression mémoire, puis le réseau. La plupart des lenteurs « mystérieuses » sont liées au stockage ou à un service qui se comporte mal.

Conclusion : prochaines étapes pratiques

Si vous voulez une installation Linux que vous pouvez garder pendant des années, construisez-la comme si vous deviez l’expliquer plus tard — parce que vous le ferez. Utilisez les forces de Leap 15.6 : YaST pour la clarté, les snapshots Btrfs pour le rollback, les correctifs zypper pour le changement contrôlé, et AppArmor pour un durcissement pragmatique.

Prochaines étapes qui rapportent immédiatement :

1. Parcourez les tâches post-install ci-dessus et corrigez les surprises pendant que le système est encore « neuf ».
2. Décidez où vivent les données à forte écriture, et déplacez-les hors du système de fichiers OS si nécessaire.
3. Définissez une cadence de patch et effectuez le premier redémarrage selon votre planning, pas en pleine panne.
4. Implémentez de vraies sauvegardes et réalisez un test de restauration cette semaine. Pas plus tard.
5. Notez votre liste de dépôts, l’agencement de stockage et le choix du gestionnaire réseau dans une note d’exploitation unique que vous retrouverez dans un an.

C’est la configuration stable : pas parfaite, pas flashy, simplement survivable de façon fiable.