Debian on slash-root.fr

Aptly : mirroiter Debian proprement

Fri, 13 Mar 2026 19:05:06 +0100

Quand on gère une flotte de serveurs Debian, on finit toujours par se poser la même question : comment maîtriser ce que mes machines vont installer ? Comment être sûr qu'un apt update ne va pas me ramener une version de paquet qui casse tout ? Et surtout, comment faire pour que mes serveurs de prod ne dépendent pas d'un miroir externe qui peut tomber au pire moment ?

La réponse classique, c'est de monter un miroir local. Sauf que mirrorer Debian avec les outils standards (debmirror, apt-mirror...), c'est lourd, c'est rigide, et ça ne répond qu'à la moitié du problème. On a une copie locale, d'accord, mais on n'a toujours aucun contrôle sur ce qui change d'un jour à l'autre.

C'est là qu'aptly entre en jeu.

Ce qu’aptly fait vraiment

aptly, c'est un gestionnaire de dépôts Debian écrit en Go. Il sait faire trois choses fondamentales :

mirrorer un dépôt distant -- comme apt-mirror, mais en mieux
Figer l'état d'un miroir dans un snapshot immuable -- ça, c'est la vraie valeur ajoutée
Publier ce snapshot pour que vos machines puissent l'utiliser

Le workflow de base, c'est ça :

mirror create → mirror update → snapshot create → publish snapshot

Et quand il faut mettre à jour :

mirror update → snapshot create → publish switch

Le publish switch bascule la publication d'un snapshot à un autre. Vos machines continuent de pointer sur la même URL, mais le contenu change de manière contrôlée. Si ça foire, vous rebasculez sur l'ancien snapshot. Pas de panique, pas de retélécharger quoi que ce soit.

Installation

Via les paquets Debian

C'est la méthode standard, celle qu'on va utiliser ici :

sudo apt update
sudo apt install aptly

Sur Debian Trixie, ça installe la version 1.5.0. C'est pas la toute dernière (la 1.6.2 existe), mais c'est largement suffisant pour ce qu'on va faire.

Vérification :

$ aptly version
aptly version: 1.5.0

L’upstream (optionnel)

Si vous voulez absolument la dernière version upstream, vous pouvez ajouter le dépôt officiel d'aptly. Mais franchement, pour un usage classique, la version Debian fait le job. Je mentionne juste l'option pour ceux qui en ont besoin :

sudo mkdir -p /etc/apt/keyrings
wget -O /etc/apt/keyrings/aptly.asc https://www.aptly.info/pubkey.txt

echo "deb [signed-by=/etc/apt/keyrings/aptly.asc] http://repo.aptly.info/release trixie main" \
 | sudo tee /etc/apt/sources.list.d/aptly.list

sudo apt update
sudo apt install aptly

Mais encore une fois, c'est optionnel. On va continuer avec la version des dépôts Debian.

Configuration de base

aptly stocke tout dans ~/.aptly par défaut. En prod, on va plutôt utiliser /var/aptly. On crée le répertoire et on configure aptly pour l'utiliser :

sudo mkdir -p /var/aptly
sudo chown $USER:$USER /var/aptly

Le fichier de config, c'est ~/.aptly.conf (ou /etc/aptly.conf pour une config globale). On va en créer un minimal :

cat > ~/.aptly.conf << 'EOF'
{
 "rootDir": "/var/aptly",
 "architectures": ["amd64"]
}
EOF

On restreint à amd64 parce que c'est ce qu'on utilise. Pas la peine de télécharger du i386, du arm64 ou du armhf si on n'en a pas besoin.

Le rootDir, c'est la racine de tout. Dedans, aptly va créer :

db/ -- sa base de données interne
pool/ -- les fichiers .deb téléchargés
public/ -- les dépôts publiés, ceux qu'on va exposer

Importer les clés GPG

Avant de créer un miroir, aptly a besoin des clés GPG pour vérifier les signatures des dépôts distants. Sur Debian, les clés d'archive sont déjà présentes dans /usr/share/keyrings/. Il suffit de les importer dans le trousseau d'aptly :

gpg --no-default-keyring \
 --keyring /usr/share/keyrings/debian-archive-keyring.gpg \
 --export | \
 gpg --no-default-keyring \
 --keyring trustedkeys.gpg \
 --import

Ça importe les clés dans ~/.gnupg/trustedkeys.gpg, le trousseau qu'aptly utilise par défaut.

Créer un miroir de Debian Trixie

On va mirrorer le dépôt officiel français (ftp.fr.debian.org), avec les sections main et non-free-firmware. Pourquoi non-free-firmware ? Parce que depuis Debian 12, les firmwares non-libres (wifi, GPU...) sont dans cette section, et on en a souvent besoin.

aptly mirror create \
 -architectures=amd64 \
 debian-trixie \
 http://ftp.fr.debian.org/debian/ \
 trixie main non-free-firmware

Quelques remarques :

Le flag -architectures=amd64 se place avant la sous-commande mirror. C'est un flag global. Si vous le mettez après, aptly va râler.
Le nom du miroir (debian-trixie), c'est vous qui le choisissez. Prenez un nom explicite.
L'URL doit finir par un /.
On spécifie la distribution (trixie) et les composants (main non-free-firmware).

La commande crée la définition du miroir, mais ne télécharge rien encore. Pour ça, il faut lancer un mirror update.

Remplir le miroir

aptly mirror update debian-trixie

Là, ça télécharge. Et ça prend du temps. Un miroir complet de Debian main + non-free-firmware en amd64, c'est plusieurs dizaines de Go. Prévoyez du café.

Vous pouvez suivre la progression dans le terminal. aptly affiche les paquets au fur et à mesure qu'il les télécharge.

Une fois terminé, vous pouvez voir ce que contient le miroir :

aptly mirror show debian-trixie

Ça vous donne le nombre de paquets, la taille totale, la date de dernière mise à jour, etc.

Créer un snapshot

Le miroir est à jour. Maintenant, on va en faire un snapshot. Un snapshot, c'est une copie figée et immuable de l'état du miroir à un instant T. Une fois créé, il ne bouge plus, quoi qu'il arrive au miroir source.

aptly snapshot create trixie-$(date +%Y%m%d) from mirror debian-trixie

J'utilise la date dans le nom du snapshot. C'est une bonne pratique : ça permet de savoir immédiatement à quoi correspond chaque snapshot.

Vous pouvez lister vos snapshots :

aptly snapshot list

Et voir le détail d'un snapshot :

aptly snapshot show trixie-20260313

Publier le snapshot

Un snapshot qui n'est pas publié, ça ne sert à rien. La publication génère l'arborescence standard Debian (dists/, pool/, fichiers Release signés...) dans /var/aptly/public/.

aptly publish snapshot -distribution=trixie trixie-20260313

Le flag -distribution=trixie indique quelle distribution utiliser dans les métadonnées du dépôt publié. C'est ce que vos machines verront dans leur sources.list.

aptly va vous demander la passphrase de votre clé GPG pour signer le fichier Release. Si vous n'avez pas encore de clé GPG, créez-en une :

gpg --full-generate-key

Choisissez RSA 4096 bits, et renseignez un nom et un email.

Une fois la publication terminée, vous avez un dépôt Debian complet dans /var/aptly/public/. Il ne reste plus qu'à l'exposer via un serveur web.

L’impact des hard links

Un détail important : quand aptly publie un snapshot, il ne copie pas les fichiers .deb. Il crée des hard links depuis le pool vers le répertoire public/.

Ça veut dire quoi concrètement ?

Pas de duplication -- un paquet présent dans plusieurs snapshots n'occupe qu'une seule fois la place sur le disque
Publication instantanée -- créer un hard link, c'est quasi gratuit en temps et en espace
Plusieurs snapshots publiés en même temps -- vous pouvez avoir trixie-20260313 et trixie-20260310 publiés simultanément, ils partagent les fichiers communs

C'est pour ça que le publish switch est si rapide. aptly ne déplace rien, il change juste les liens.

Par contre, attention : si vous supprimez un snapshot publié avec snapshot drop, aptly refuse tant que la publication existe. Il faut d'abord dépublier (publish drop) ou basculer vers un autre snapshot (publish switch).

Mettre à jour le miroir et basculer

Quelques jours passent. Le miroir Debian a évolué. Vous voulez mettre à jour votre dépôt local. Voilà le workflow complet :

# 1. Mettre à jour le miroir
aptly mirror update debian-trixie

# 2. Créer un nouveau snapshot
aptly snapshot create trixie-$(date +%Y%m%d) from mirror debian-trixie

# 3. Basculer la publication vers le nouveau snapshot
aptly publish switch trixie trixie-20260315

Le publish switch fait tout le boulot :

Il met à jour les métadonnées (Release, Packages, Contents...)
Il ajuste les hard links dans public/
Il signe le nouveau Release avec GPG
Il nettoie les anciens liens qui ne servent plus

Vos machines qui pointent sur ce dépôt voient le changement au prochain apt update. Pas de coupure, pas de temps d'arrêt.

Si le nouveau snapshot pose problème, vous rebasculez sur l'ancien :

aptly publish switch trixie trixie-20260313

C'est aussi rapide dans un sens que dans l'autre.

Les dépôts locaux (mention rapide)

aptly sait aussi gérer des dépôts locaux, où vous poussez vos propres paquets .deb. Le workflow est similaire :

# Créer un dépôt local
aptly repo create mon-depot

# Ajouter des paquets
aptly repo add mon-depot /chemin/vers/*.deb

# Snapshot
aptly snapshot create mon-depot-v1 from repo mon-depot

# Publier
aptly publish snapshot mon-depot-v1

Je ne développe pas plus ici, parce que le cas d'usage principal d'aptly, c'est quand même le mirroring. Mais sachez que c'est possible.

Exposer le dépôt

Le serveur embarqué (test uniquement)

aptly a un petit serveur HTTP intégré. C'est pratique pour tester, mais la doc officielle est claire : not suitable for real production usage.

aptly serve -listen=:8080

Vous pouvez alors ajouter le dépôt sur une machine de test :

echo "deb http://votre-serveur:8080/ trixie main non-free-firmware" \
 | sudo tee /etc/apt/sources.list.d/aptly-test.list

nginx (production)

En prod, on utilise nginx. Je ne vais pas détailler ici parce que ça fera l'objet d'un second article si besoin, mais l'idée générale :

server {
 listen 80;
 server_name repo.example.com;
 root /var/aptly/public;
 location / {
 autoindex on;
 }
}

Vous activez le vhost, vous rechargez nginx, et c'est bon. Pour HTTPS, ajoutez Let's Encrypt avec certbot.

Côté client, vous ajoutez le dépôt :

echo "deb http://repo.example.com/ trixie main non-free-firmware" \
 | sudo tee /etc/apt/sources.list.d/mon-miroir.list

sudo apt update

Si le dépôt est signé (et il devrait l'être), distribuez votre clé GPG publique aux clients :

gpg --armor --export VOTRE_KEY_ID > /var/aptly/public/repo-key.asc

Sur les clients :

wget -O /etc/apt/keyrings/mon-repo.asc http://repo.example.com/repo-key.asc

echo "deb [signed-by=/etc/apt/keyrings/mon-repo.asc] http://repo.example.com/ trixie main non-free-firmware" \
 | sudo tee /etc/apt/sources.list.d/mon-miroir.list

Automatiser avec cron

Un miroir, ça se met à jour régulièrement. Voici un script cron qui fait le job :

#!/bin/bash
# /etc/cron.daily/aptly-update

set -euo pipefail

MIRROR="debian-trixie"
DATE=$(date +%Y%m%d)

# Mise à jour du miroir
aptly mirror update "$MIRROR"

# Nouveau snapshot
aptly snapshot create "trixie-${DATE}" from mirror "$MIRROR"

# Basculer la publication
aptly publish switch -batch -gpg-key="VOTRE_KEY_ID" trixie "trixie-${DATE}"

# Nettoyer les vieux snapshots (garder les 7 derniers)
aptly snapshot list -raw | grep "^trixie-" | sort | head -n -7 | while read snap; do
 aptly snapshot drop "$snap" 2>/dev/null || true
done

# Nettoyer la base
aptly db cleanup

Le flag -batch est crucial : il permet à GPG de fonctionner sans terminal interactif. Sans ça, le script va bloquer en attendant que vous tapiez la passphrase.

Pour éviter ça, vous pouvez aussi utiliser gpg-agent avec un cache de passphrase, ou stocker la passphrase dans un fichier sécurisé et utiliser -passphrase-file.

Nettoyage et maintenance

aptly conserve tous les paquets téléchargés dans son pool, même ceux qui ne sont plus référencés par aucun snapshot. Pour faire le ménage :

aptly db cleanup

Ça supprime les paquets orphelins. Si vous voulez voir ce qui va être supprimé avant de le faire :

aptly db cleanup -verbose -dry-run

Pour sauvegarder votre installation aptly, c'est simple : sauvegardez /var/aptly en entier. Tout est dedans.

tar -czf aptly-backup-$(date +%Y%m%d).tar.gz /var/aptly

Quelques astuces

Filtrer les paquets lors du mirroring. Si vous ne voulez mirrorer que certains paquets (par exemple, uniquement nginx et ses dépendances), vous pouvez utiliser des filtres :

aptly mirror create -filter='nginx' -filter-with-deps \
 nginx-only \
 http://ftp.fr.debian.org/debian/ \
 trixie main

Le flag -filter-with-deps est important : sans lui, vous récupérez nginx mais pas ses dépendances, et ça ne servira à rien.

Comparer deux snapshots. Pour voir ce qui a changé entre deux snapshots :

aptly snapshot diff trixie-20260313 trixie-20260315

Fusionner des snapshots. Vous pouvez combiner plusieurs snapshots en un seul. Utile si vous avez un miroir Debian et un dépôt local, et que vous voulez les publier ensemble :

aptly snapshot merge trixie-complet trixie-20260315 mon-depot-v1

Conclusion

aptly résout un vrai problème : comment garder le contrôle sur ce que vos machines Debian vont installer. Les miroirs classiques vous donnent une copie locale, d'accord, mais ils ne vous donnent pas la maîtrise des changements. Avec aptly et ses snapshots, vous décidez quand et comment vos serveurs voient les mises à jour.

Le workflow mirror create → mirror update → snapshot create → publish snapshot → publish switch devient vite un réflexe. Et le jour où une mise à jour casse quelque chose, vous serez bien content de pouvoir rebascule sur le snapshot d'hier en une commande.

Les hard links font que tout ça reste léger en espace disque et rapide en exécution. Vous pouvez avoir plusieurs snapshots publiés en parallèle, pour des environnements de test et de prod différents, sans exploser votre stockage.

Bref, si vous gérez des serveurs Debian sérieusement, aptly mérite sa place dans votre boîte à outils.

Debian : Configuration complète d’unattended-upgrades pour une sécurité sans effort

Thu, 08 May 2025 14:03:19 +0200

1. Introduction, ou pourquoi il est temps d’arrêter de faire semblant

Laissez-moi deviner : vous êtes du genre à vous vanter d'être un administrateur système compétent, mais vous ne vous souvenez pas de la dernière fois que vous avez tapé apt update && apt upgrade sur vos serveurs en production ? Pas étonnant que vos systèmes ressemblent à un gruyère numérique avec plus de trous que de fromage. Un bon sysadmin met à jour ses systèmes - un vrai sysadmin automatise ça et passe à autre chose.

Heureusement, les créateurs de Debian n'ont pas supposé que vous étiez tous des héros de la ligne de commande avec une mémoire infaillible et un agenda aussi vide que /dev/null. Ils nous ont gratifiés d'unattended-upgrades, ce petit bijou d'automatisation que seuls les vrais barbus savent configurer correctement. Bien sûr, vous pourriez continuer à mettre à jour manuellement, de la même manière que vous pourriez continuer à croire que vi est plus difficile qu'Emacs.

2. Unattended-upgrades : le sysadmin silencieux qui ne prend jamais de pause café

Contrairement à votre stagiaire qui croit que "mise à jour de sécurité" signifie "changer son mot de passe de 'password123' à 'password1234'", unattended-upgrades est un service qui prend son travail au sérieux. Cette petite merveille d'ingénierie fonctionne pendant que vous dormez profondément, rêvant probablement de clusters Kubernetes parfaitement orchestrés (on sait tous que ça n'arrive que dans les rêves).

Techniquement parlant (et les vrais barbus aiment parler techniquement), c'est un démon qui s'exécute via systemd timers pour :

Chercher les mises à jour que vous auriez dû installer il y a des semaines
Filtrer celles qui empêcheront votre système de se faire pwner par un script kiddie
Les installer sans vous demander votre avis (parce qu'on sait tous que vous diriez "plus tard")
Redémarrer votre serveur au milieu de la nuit quand personne ne regardera vos graphs de monitoring chuter momentanément

Ce paquet fonctionne sur n'importe quelle version de Debian (de l'antique Buster à la fraichement sortie Bookworm) et même sur ces ersatz de Debian comme Ubuntu, si vous vous abaissez à utiliser de telles distributions.

3. Installation pour ceux qui savent encore taper sur un clavier

3.1 Les bases (même votre stagiaire pourrait le faire)

Ouvrez votre terminal noir (parce que bien sûr, vous utilisez un fond noir avec des polices vertes, comme tout vrai barbu qui se respecte) et tapez ces incantations magiques :

sudo apt update
sudo apt install unattended-upgrades apt-listchanges

Ce que vous venez de conjurer :

unattended-upgrades : le véritable héros silencieux qui fera le travail que vous procrastinez habituellement
apt-listchanges : pour recevoir des emails détaillés que vous prétendrez lire avant de les archiver automatiquement

3.2 Activation pour les admins qui ont peur de modifier les fichiers de configuration à la main

Si vous préférez l'approche "clique-bouton" (aucun jugement, enfin peut-être un peu), Debian vous offre un assistant :

sudo dpkg-reconfigure --priority=low unattended-upgrades

💡 Astuce de vrai barbu : L'argument --priority=low force l'affichage de toutes les options possibles, parce que les vrais barbus veulent tout contrôler. Les autres priorités sont pour ceux qui pensent qu'utiliser une souris sous Linux est une bonne idée.

Un menu pseudo-graphique va apparaître dans votre terminal. Sélectionnez "Oui" (comme si vous aviez réellement le choix). Cette étape crée le fichier /etc/apt/apt.conf.d/20auto-upgrades avec une configuration basique pour les âmes simples.

4. Configuration pour les vrais barbus (ceux qui n’utilisent pas de GUI)

La configuration d'unattended-upgrades se fait dans deux fichiers de configuration. Si vous ne savez pas ce qu'est un fichier de configuration, fermez cet article et retournez installer Windows :

/etc/apt/apt.conf.d/50unattended-upgrades - Où la vraie magie se passe
/etc/apt/apt.conf.d/20auto-upgrades - Pour dire à votre système à quelle fréquence il doit se sauver lui-même

4.1 Sélection des dépôts (ou comment distinguer les mises à jour importantes des futilités)

Éditez /etc/apt/apt.conf.d/50unattended-upgrades (avec vi, bien sûr, pas avec cette abomination qu'est nano). La section Origins-Pattern est comme le filtre de Tinder de votre système - elle décide quelles mises à jour méritent son attention :

Unattended-Upgrade::Origins-Pattern {
 "origin=Debian,codename=${distro_codename}-security";

 // "origin=Debian,codename=${distro_codename}-updates";

 // "origin=Debian,codename=${distro_codename}-proposed-updates";

 // "origin=Debian,codename=${distro_codename}-backports";
};

Guide de traduction du jargon Debian pour mortels :

Type de dépôt	Ce que Debian dit	Ce que ça signifie vraiment	À activer si...
-security	"Correctifs de sécurité critiques"	"Colmate les trous que les script kiddies utilisent déjà"	Vous avez un minimum d'instinct de survie
-updates	"Corrections importantes non sécuritaires"	"Bugs suffisamment gênants pour qu'on daigne les corriger"	Vous en avez assez que vos services plantent mystérieusement
-proposed-updates	"Candidats en attente de validation"	"Quelqu'un a bricolé ça, ça semble marcher, mais on n'est pas sûr"	Vous aimez vivre dangereusement (ou avez un environnement de test)
-backports	"Nouvelles versions portées vers stable"	"Du code récent greffé sur un OS dinosaure"	Un fonctionnalité VRAIMENT nécessaire vous manque

🐑 Conseil de troupeau : La plupart des moutons n'activent que -security. Les vrais barbus activent tout puis blâment systemd quand ça casse.

4.2 Planification des mises à jour (ou quand laisser votre système jouer au docteur)

Modifiez /etc/apt/apt.conf.d/20auto-upgrades pour définir quand votre système se soignera tout seul :

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Unattended-Upgrade-Time "3";
APT::Periodic::RandomSleep "60";

Explication pour ceux qui n'ont jamais lu le man :

Update-Package-Lists : À quelle fréquence votre système recherche de nouvelles mises à jour.
- "1" = tous les jours (pour les paranoïaques)
- "7" = une fois par semaine (pour les décontractés)
- "0" = jamais (pour ceux qui aiment jouer à la roulette russe avec les exploits)
Unattended-Upgrade : Quand appliquer réellement ces mises à jour.
- "1" = quotidiennement (recommandé par tous ceux qui ont déjà dû nettoyer un serveur compromis)
- "7" = hebdomadaire (un compromis pour les téméraires)
- "0" = jamais (alors pourquoi lire cet article ?)
Unattended-Upgrade-Time : L'heure à laquelle lancer le processus.
- "3" = 3h du matin, quand même les administrateurs système devraient dormir
RandomSleep : Le délai aléatoire pour éviter d'être comme tout le monde.
- "60" = entre 0 et 60 minutes de décalage (pour ne pas faire tomber les miroirs Debian quand tout le monde se rue dessus à 3h00 pile)

🐔 Pour les insomniaques : Sur Debian 11+, RandomSleep est en minutes. Sur Debian 10 et avant, c'est en secondes. Pourquoi ? Parce que la cohérence, c'est surfait quand on peut introduire des bugs subtils dans votre configuration.

4.3 Gestion du reboot automatique (ou comment faire pleurer vos utilisateurs)

Les mises à jour du noyau sont comme les légumes - elles ne font effet que si vous redémarrez. Configurez le comportement dans /etc/apt/apt.conf.d/50unattended-upgrades :

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";

Ce que ces options signifient vraiment :

Automatic-Reboot : Le grand interrupteur de la terreur nocturne.
- "true" = "J'aime vivre dangereusement et mes backups sont à jour"
- "false" = "Je préfère avoir un noyau vulnérable mais au moins je sais quand mon serveur redémarre"
Automatic-Reboot-Time : L'heure du crime parfait.
- Format : "HH:MM" (choisir une heure où personne ne remarquera que tout est tombé)
- Conseil de barbu : planifiez-le toujours APRÈS les mises à jour, pas pendant
Automatic-Reboot-WithUsers : Le dilemme éthique.
- "true" = "Les sessions des utilisateurs importent moins que la sécurité" (approche soviétique)
- "false" = "Les humains d'abord" (approche diplomatique)

🔥 Histoire vraie : J'ai vu un administrateur configurer un redémarrage automatique à 14h sur un serveur de production. Il a ensuite passé trois semaines à se demander pourquoi les utilisateurs lui envoyaient des messages haineux tous les jours.

4.4 Notifications pour prétendre que vous surveillez vos serveurs

Les emails de notification sont là pour vous donner l'illusion que vous savez ce qui se passe sur vos serveurs. Configurez-les dans /etc/apt/apt.conf.d/50unattended-upgrades :

Unattended-Upgrade::Mail "admin@domaine.fr";
Unattended-Upgrade::MailReport "on-change";

//Unattended-Upgrade::Mail-Server "smtp.example.com";
//Unattended-Upgrade::Mail-Server-Port "587";
//Unattended-Upgrade::Mail-Server-Login "votre_login";
//Unattended-Upgrade::Mail-Server-Password "votre_motdepasse";

Options pour votre spam personnel :

Mail : Qui recevra les rapports que personne ne lit.
- Mettez votre email perso si vous aimez être réveillé à 3h du matin par des notifications
- Ou créez un filtre qui les envoie directement dans un dossier que vous n'ouvrirez jamais
MailReport : La fréquence de spam.
- "always" = pour ceux qui aiment leur boîte mail bien remplie
- "on-change" = le choix des gens raisonnables
- "only-on-error" = pour ceux qui adhèrent à la philosophie "pas de nouvelles, bonnes nouvelles"

📣 Rappel essentiel : Ces mails ne serviront à rien si vous n'avez pas un MTA fonctionnel. Installez-en un ou tous ces paramètres ne seront que des vœux pieux :
sudo apt install postfix
# OU
sudo apt install msmtp msmtp-mta

5. Dompter les mises à jour majeures (ou l’art d’éviter la crise cardiaque à 3h du matin)

Les mises à jour de sécurité, c'est bien, mais les mises à jour majeures, c'est comme laisser un enfant de 5 ans conduire votre voiture - ça peut aller très mal, très vite. Particulièrement avec ces paquets qui utilisent le système d'alternatives de Debian, cette brillante invention qui garantit votre future migraine.

5.1 Le piège des alternatives (ou comment se tirer une balle dans le pied automatiquement)

Les langages comme PHP, Python ou Java utilisent ce merveilleux système d'alternatives, qui permet à plusieurs versions de coexister (comme vos ex, mais en plus utile). Malheureusement, ce système a été conçu par quelqu'un qui n'a manifestement jamais entendu parler de l'automatisation.

Le drame en 4 actes :

Acte	Tragédie	Résultat
1	Votre système découvre PHP 8.3 et pense "oh, quelle belle mise à jour !"	Installation lancée à 3h17 du matin
2	Le script demande poliment : "Voulez-vous faire de cette nouvelle version la version par défaut ?"	Votre serveur fige, attendant une réponse qui ne viendra jamais
3	Vous dormez paisiblement pendant que votre installation reste suspendue	Configuration en état zombie (`sudo dpkg --configure -a` sera votre mantra du matin)
4	Votre système de mise à jour automatique est lui-même bloqué	Félicitations, vous venez de désactiver votre sécurité automatique

5.2 Solutions pour barbus confirmés (et amateurs de nuits tranquilles)

5.2.1 Entraîner debconf à ne pas vous demander votre avis

Ce code est l'équivalent de mettre un bâillon sur debconf pour qu'il arrête de poser des questions stupides :

sudo echo "php8.3 php8.3/common/default_for_install boolean false" | sudo debconf-set-selections
sudo echo "php8.2 php8.2/common/default_for_install boolean true" | sudo debconf-set-selections

Quand l'utiliser : Lorsque vous êtes un admin responsable qui teste d'abord les nouvelles versions avant de les infliger à votre production. Concept alien pour certains, je sais.

5.2.2 Expliquer à Debian ce qu’est une priorité (comme à votre chef de projet)

Le système de priorité d'alternatives est l'équivalent technique d'une hiérarchie féodale - celui avec le plus grand nombre gagne :

sudo update-alternatives --install /usr/bin/php php /usr/bin/php8.2 82 \
 --slave /usr/bin/phar phar /usr/bin/phar8.2 \
 --slave /usr/bin/phpdbg phpdbg /usr/bin/phpdbg8.2

sudo update-alternatives --install /usr/bin/php php /usr/bin/php8.3 80 \
 --slave /usr/bin/phar phar /usr/bin/phar8.3 \
 --slave /usr/bin/phpdbg phpdbg /usr/bin/phpdbg8.3

💡 Astuce de vrai barbu : La valeur numérique est juste une préférence, pas une garantie. Utilisez des nombres significativement différents si vous ne voulez pas être surpris. J'ai déjà vu des administrateurs utiliser 10 et 11, puis se plaindre que leur choix n'était pas respecté - niveau amateur.

5.2.3 Le coup du hook post-installation (ou comment avoir le dernier mot)

Quand vous en avez assez que Debian ignore vos préférences, créez un hook qui aura le dernier mot après chaque mise à jour :

sudo vi /etc/apt/apt.conf.d/99post-upgrade-hook

Ajoutez ce code vindicatif dans le fichier :

DPkg::Post-Invoke {
 "if [ -f /usr/bin/php8.2 ] && [ -f /usr/bin/php8.3 ]; then update-alternatives --set php /usr/bin/php8.2; fi";
};

Pourquoi c'est brillant : Cette approche passive-agressive rétablit votre version préférée après CHAQUE opération APT, même si un paquet tente sournoisement de changer la version par défaut. C'est l'équivalent de dire "Merci pour ton opinion, maintenant on va faire à ma façon quand même".

5.2.4 Mettre un gilet pare-balles contre les versions majeures

Ajoutez à /etc/apt/apt.conf.d/50unattended-upgrades ce code défensif :

Unattended-Upgrade::MinimalSteps "true";
Unattended-Upgrade::Allow-downgrade "false";
Unattended-Upgrade::Allow-APT-Mark-Fallback "false";

Décryptage des incantations de protection :

Option	Ce qu'elle fait vraiment	Traduction en langage barbu
MinimalSteps	Change en mode "un paquet à la fois"	"Je préfère que mon système plante sur UN paquet plutôt que sur TOUS"
Allow-downgrade	Empêche les retours en arrière	"Non, on ne revient pas à PHP 5 juste parce que tu as peur du changement"
Allow-APT-Mark-Fallback	Désactive l'auto-sélection de nouvelles versions	"Touche pas à mes versions majeures, animal ! "

5.2.5 La liste noire de la honte (ou comment bannir les paquets problématiques)

Placez vos paquets critiques sur la liste des indésirables avec cette configuration :

Unattended-Upgrade::Blacklist {
 "php*";
 "mariadb-server";
 "postgresql*";
 "nginx";
 "apache2";
};

5.3 Le plan de bataille pour les vrais professionnels

📌 Stratégie de survie en environnement de production :

Bloquez les versions majeures avec la configuration 5.2.4, à moins que vous n'aimiez les appels nocturnes
Blacklistez impitoyablement tout ce qui fait tourner votre business avec l'option 5.2.5
Construisez un environnement de test identique - les vrais barbus testent AVANT, pas en production
Planifiez vos mises à jour majeures comme des opérations militaires, avec des plans de repli
Faites des backups complets avant toute mise à jour majeure, ou préparez votre CV

⚠️ Alerte rouge : Les mises à jour majeures automatiques sur des composants critiques, c'est comme jouer à la roulette russe avec le serveur de production - vous pourriez vous en sortir, mais est-ce vraiment un risque que vous voulez prendre ? Pour tout ce qui fait tourner votre business (PHP, bases de données, serveurs web), planifiez, testez, puis priez avant de mettre à jour.

6. Entrer dans la matrice : surveillance et déblocage des catastrophes nocturnes

6.1 Les logs que personne ne lit jamais (jusqu’à ce que tout explose)

Même avec l'automatisation, il faut surveiller ce que fait cette bête sauvage qu'est unattended-upgrades. Sinon, c'est comme laisser votre adolescent seul à la maison pendant le week-end - tôt ou tard, vous le regretterez. Voici les fichiers que vous prétendrez consulter régulièrement :

Fichier log	Ce qu'il contient réellement	Quand le lire (soyons honnêtes)
`/var/log/unattended-upgrades/unattended-upgrades.log`	Le journal de bord du capitaine automatique	Quand votre patron demande "que s'est-il passé ?"
`/var/log/unattended-upgrades/unattended-upgrades-dpkg.log`	Ce que dpkg marmonne dans sa barbe	Quand le premier log ne vous dit pas pourquoi tout a explosé
`/var/log/apt/history.log`	La preuve que quelqu'un a fait quelque chose	Pour savoir QUI blâmer (spoiler : c'est toujours systemd)
`/var/log/apt/term.log`	Les mêmes informations qu'avant, mais en plus verbeux	Pour les masochistes qui aiment lire 5000 lignes de texte
`/var/log/dpkg.log`	Chaque respiration de dpkg	Pour les vrais barbus qui lisent les logs comme d'autres lisent Game of Thrones

Les logs sont automagiquement comprimés et rotatés (.1, .2.gz, etc.). Voici comment faire semblant de les surveiller régulièrement :

sudo tail -n 20 /var/log/unattended-upgrades/unattended-upgrades.log

sudo grep -i "error\|fail\|warning" /var/log/unattended-upgrades/unattended-upgrades.log

6.2 Déclencher manuellement les mises à jour (pour le plaisir de voir quelque chose se casser en temps réel)

Pour voir unattended-upgrades en action, comme si vous regardiez un documentaire animalier sur un prédateur dans son habitat naturel :

sudo unattended-upgrade --dry-run --debug
sudo unattended-upgrade --debug
sudo unattended-upgrade -d

🧪 Preuve d'expertise technique : Utilisez --dry-run lors des démos pour vos collègues. Si ça fonctionne, prenez un air suffisant. Si ça plante, dites nonchalamment : "C'est exactement pourquoi j'utilise dry-run, voyez-vous".

6.3 Techniques de réanimation pour système bloqué (ou comment sauver votre journée)

Quand votre système de mise à jour automatique s'arrête en position fœtale, voici la trousse d'urgence du barbu :

sudo dpkg --audit
sudo dpkg --configure --pending
sudo apt-get -f install
sudo apt-mark showhold

Si votre système est bloqué par une question existentielle comme "Voulez-vous que PHP 8.3 devienne le nouveau PHP par défaut ?", il est temps d'intervenir manuellement (comme arracher la manette des mains d'un enfant) :

sudo dpkg --configure -a
sudo dpkg-reconfigure php8.3-common

Libérez votre swap !

Sun, 01 Dec 2024 06:09:15 +0100

Préambule

Envie de libérer Britney ? Ou plutôt... votre swap ? 🎵

Si vous cherchez à optimiser l'utilisation de votre mémoire virtuelle sur une machine Debian, vous êtes au bon endroit !

Le `swappiness`, c’est quoi ?

Le swappiness est un paramètre du kernel Linux qui contrôle la "proportion" du système à utiliser le swap. Une valeur faible favorise l'utilisation de la RAM, tandis qu'une valeur élevée incite à swapper rapidement sur le disque.

Quelques commandes essentielles

1. Vérifier la valeur actuelle du `swappiness`

cat /proc/sys/vm/swappiness

2. Modifier dynamiquement le `swappiness`

sudo sysctl vm.swappiness=20

⚠️ Cette modification n'est pas persistante et sera perdue au redémarrage.

3. Rendre la configuration persistante

Ajoutez ou modifiez la ligne suivante dans /etc/sysctl.conf :

vm.swappiness=20

Appliquez ensuite la configuration :

sudo sysctl -p

4. Comprendre les valeurs du `swappiness`

100 : Le système swap intensément.
0 : Swap uniquement en cas de RAM complètement saturée.
Défaut : Généralement 60 sur Debian.

5. Désactiver et réactiver le swap

sudo swapoff -a && sudo swapon -a

⚠️ Assurez-vous que la RAM disponible est suffisante pour accueillir les données du swap avant de désactiver ce dernier.

6. Identifier les processus utilisant le swap

Pour examiner les processus gourmands en swap, utilisez cette commande :

for file in /proc/*/status ; do \
 awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; \
 done | \
sort -k 2 -n -r | less

Automatisation avec un script Bash

Pour simplifier la gestion du swap, voici un script bash prêt à l'emploi :

Script : `free-swap.sh`

#!/bin/bash

check_command() {
 if [[ $? -ne 0 ]]; then
 echo "Erreur lors de l'exécution de la commande: $1"
 exit 1
 fi
}

free_data=$(free)
check_command "free"
mem_data=$(echo "$free_data" | grep 'Mem:')
free_mem=$(echo "$mem_data" | awk '{print $4}')
buffers=$(echo "$mem_data" | awk '{print $6}')
cache=$(echo "$mem_data" | awk '{print $7}')
total_free=$((free_mem + buffers + cache))

if echo "$free_data" | grep -q 'Échange:'; then
 used_swap=$(echo "$free_data" | grep 'Échange:' | awk '{print $3}')
else
 used_swap=$(echo "$free_data" | grep 'Swap:' | awk '{print $3}')
fi

echo -e "Free memory:\t$total_free kB ($((total_free / 1024)) MB)\nUsed swap:\t$used_swap kB ($((used_swap / 1024)) MB)"

if [[ $used_swap -eq 0 ]]; then
 echo "Félicitations ! Aucun swap n'est utilisé."
elif [[ $used_swap -lt $total_free ]]; then
 echo "Libération du swap..."
 sudo swapoff -a
 check_command "swapoff"
 sudo swapon -a
 check_command "swapon"
else
 echo "Pas assez de mémoire libre pour libérer le swap. Arrêt."
 exit 1
fi

Instructions :

Enregistrez le script dans un fichier, par exemple : free-swap.sh.
Rendez-le exécutable :

chmod u+x free-swap.sh

Exécutez-le :

./free-swap.sh

⚠️ Ne pas utiliser ce script si ZRAM est activé sur votre système, car cela pourrait entraîner des comportements inattendus.

Conclusion

Vous venez de découvrir comment optimiser la gestion du swap sous Debian. Que ce soit via des commandes ou un script Bash, vous êtes désormais armé pour reprendre le contrôle de votre mémoire virtuelle.

Et surtout, souvenez-vous : le swap, c'est bien... mais la RAM, c'est mieux ! 😉

Restic ou l’Importance des Sauvegardes de Données

Mon, 11 Nov 2024 13:55:45 +0100

Dans un monde où les pertes de données peuvent avoir des conséquences catastrophiques, que ce soit pour des entreprises, des gouvernements, ou des individus, il devient impératif de prendre des mesures pour sécuriser ses informations. Une perte de données peut entraîner des interruptions de services, voire des pertes financières importantes.

Face à cette réalité, la mise en place d’une stratégie de sauvegarde robuste devient essentielle. Dans cet article, nous allons explorer une solution pratique et accessible à tous : Restic. Cet outil, à la fois rapide, fiable et facile à configurer, permet de créer des sauvegardes cryptées et décentralisées, tout en offrant la possibilité de gérer facilement les anciennes versions de fichiers et d'automatiser le processus.

Voyons maintenant comment mettre en place un script de sauvegarde avec Restic, en tenant compte de quelques bonnes pratiques essentielles pour une gestion sécurisée et automatisée des données.

Je commence par définir les variables essentielles de son script, qui permettront de personnaliser la sauvegarde en fonction de mes besoins spécifiques.

#!/bin/bash
export RESTIC_PASSWORD='ZZZZZZZZZZZZ'
export RESTIC_REPO='/mnt/restic'
export BACKUP_TARGET='.'
export BACKUP_SOURCE='/mnt/shared/nas'
NUM_KEEP_SNAPSHOTS=15

RESTIC_PASSWORD : Cette variable contient le mot de passe nécessaire à l'accès au dépôt Restic. Ce mot de passe est utilisé pour chiffrer et déchiffrer les données sauvegardées.

RESTIC_REPO : Le répertoire où les sauvegardes seront stockées. Cela peut être un stockage local ou distant (par exemple, un serveur S3 ou un serveur FTP).

BACKUP_TARGET : La destination de la sauvegarde.

BACKUP_SOURCE : La source des fichiers à sauvegarder, ici /mnt/shared/nas, qui est un répertoire contenant des fichiers critiques.

NUM_KEEP_SNAPSHOTS : Le nombre de sauvegardes à conserver. Ce paramètre est essentiel pour éviter l'accumulation excessive de données, ce qui pourrait entraîner un encombrement du système.

L'une des premières étapes de mon script consiste à sauvegarder les bases de données. Étant donné que les bases de données peuvent contenir des informations sensibles et cruciales, il est primordial de m'assurer qu'elles sont bien incluses dans mes sauvegardes.

Cependant, je sais que mes bases de données ne sont enrichies que les jours de semaine, c'est-à-dire du lundi au vendredi. Il n'a donc pas de sens de créer un dump de la base de données pendant le week-end, lorsque les données ne sont pas mises à jour. C'est pourquoi j'ai décidé de ne créer un dump de la base de données que durant les jours ouvrés, afin d'éviter une sauvegarde inutile et de préserver des ressources.

DB_HOST="localhost"
DB_PORT="5432"
DB_USER="estx50"
DB_DUMP_PATH="/mnt/shared/nas/Trading/all_databases_backup.sql"

export PGPASSWORD='XXXXXXXXXXXXXX'

DAY_OF_WEEK=$(date +%u)
if [[ "$DAY_OF_WEEK" -ge 1 && "$DAY_OF_WEEK" -le 5 ]]; then
 echo "Jour de semaine - Création du dump de la base de données."
 pg_dumpall -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" > "$DB_DUMP_PATH" || exit 1
else
 echo "Aujourd'hui est le week-end, aucun dump de la base de données ne sera créé."
fi

sleep 10

Une fois la base de données sauvegardée, je me tourne vers la sauvegarde de mes fichiers. Restic permet de sauvegarder facilement des répertoires et d'exclure certains fichiers ou dossiers.

J'ai décidé d'exclure certains répertoires spécifiques, comme récupération_Oscar et Trading/data, car ils contiennent des données que je ne souhaite pas inclure dans la sauvegarde, parce qu'elles ne sont pas pertinentes pour mes besoins de sauvegarde.

cd "$BACKUP_SOURCE" && restic -r "$RESTIC_REPO" backup --exclude "/mnt/shared/nas/récupération_Oscar" --exclude "/mnt/shared/nas/Trading/data" "$BACKUP_TARGET" --skip-if-unchanged || exit 1

Remarque importante
Vous noterez que les exclude requièrent le chemin absolu.

skip-if-unchanged:

Cette option permet à Restic de vérifier si les fichiers ont changé avant de créer un nouveau snapshot. Si un fichier n'a pas été modifié depuis la dernière sauvegarde, Restic évite de le sauvegarder à nouveau. Cela permet de réduire le volume des données sauvegardées et d'économiser de l'espace disque.

Une fois les sauvegardes effectuées, je dois gérer les anciens snapshots pour éviter que mon dépôt de sauvegarde ne devienne trop encombré. Pour cela, j'utilise la commande forget, qui permet de supprimer les snapshots anciens et inutiles. J'ai choisi de conserver un nombre limité de snapshots récents — ici, 15 — afin de m'assurer que je dispose toujours d'un historique suffisant, sans accumuler trop de données obsolètes.

restic -r "$RESTIC_REPO" forget --keep-last "$NUM_KEEP_SNAPSHOTS" --keep-tag preserve --prune || exit 1

--keep-last $NUM_KEEP_SNAPSHOTS : Cette option permet de définir le nombre de snapshots récents à conserver. Par exemple, si vous gardez 15 snapshots, seuls les 15 derniers seront conservés.

J'utilise également l'option --prune pour nettoyer les points de sauvegarde qui ne sont plus nécessaires, ce qui permet de récupérer de l'espace disque et de garder le dépôt de sauvegarde bien organisé.

Enfin dernier point à noter : j'ai utilisé l'option --keep-tag preserve dans ma commande de nettoyage. En effet, il y a un point de sauvegarde que je ne veux en aucun cas voir supprimé lors des nettoyages. Pour cela, j'ai préalablement tagué ce snapshot avec la commande restic tag, ce qui me permet de l'identifier spécifiquement.

restic -r [RESTIC_REPO] tag [ID_SNAPSHOT] preserve

La commande restic tag permet d'ajouter un tag personnalisé à un snapshot (dans mon cas je l'ai apppelé preserve), ce qui peut être très utile pour marquer des sauvegardes importantes ou spécifiques. Ainsi, le snapshot marqué avec le tag preserve restera dans le dépôt, grâce à --keep-tag preserve même lorsque je lance le nettoyage avec l'option --prune, qui supprimera tout autre snapshot plus ancien.

Conclusion : Un Outil de Sauvegarde Puissant

En appliquant ces pratiques, j'ai réussi à mettre en place une solution de sauvegarde fiable, efficace et parfaitement adaptée à mes besoins. L'automatisation de la sauvegarde de mes fichiers et bases de données, combinée à une gestion rigoureuse des anciens snapshots, me permet de garantir une protection optimale de mes données.

Dans le prochain épisode, je me pencherai sur l'utilisation de Restic pour stocker mes sauvegardes sur un espace S3 Amazon. Ce choix m'offrira encore plus de sécurité et de flexibilité pour mes sauvegardes, tout en ajoutant une couche de fiabilité supplémentaire.

Proxmox : Template Debian12 avec Cloud-Init

Thu, 09 Nov 2023 14:23:19 +0100

Cette procédure va permettre de créer un template de VM Debian 12 pour Proxmox avec Cloud-Init.

L'intérêt sera de cloner ce template, puis de pouvoir se connecter directement en ssh au 1er démarrage de la VM. Le nom d'hôte, l'adressage ip, la(es) clef(s) ssh seront configurés à l'initialisation de la VM grâce à cloud-init.

Ce template pourra éventuellement être utilisé par la suite avec une solution telle que Terraform / OpenTofu.

Création du template

Se connecter sur un shell root de l'hôte Proxmox pvehost :

ssh root@pvehost

Télécharger la dernière image cloud de Debian 12 :

wget https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-generic-amd64.qcow2

Installer libguestfs-tools si nécessaire et ajouter qemu-guest-agent à l'image cloud précédemment téléchargée :

apt install -y libguestfs-tools
virt-customize -a debian-12-generic-amd64.qcow2 --install qemu-guest-agent

Créer une VM avec l'ID 666 qui sera le template :

qm create 666 --name debian12-cloudinit --net0 virtio,bridge=vmbr1 --scsihw virtio-scsi-single

Elle sera nommée debian12-cloudinit et la 1ère carte réseau sera rattachée au vmbr1 du serveur Proxmox.

Ajouter un nouveau disque dur, importé depuis l'image cloud, de 20 G à la VM :

qm set 666 --scsi0 local:0,iothread=1,backup=off,format=qcow2,import-from=/root/debian-12-generic-amd64.qcow2
qm disk resize 666 scsi0 20G

Définir le disque dur en 1er boot sur la VM :

qm set 666 --boot order=scsi0

Définir le nombre de coeurs et la mémoire RAM de la VM :

qm set 666 --cpu host --cores 2 --memory 4096

Attacher un disque Cloud-Init à la VM :

qm set 666 --ide2 local:cloudinit
qm set 666 --agent enabled=1

Ajuster les paramètres dans les options Cloud-Init qui figureront dans le template (si nécessaire) :

Ces options sont disponibles dans la WebUI du serveur Proxmox au niveau de la VM.

Plus de détails ici https://pve.proxmox.com/wiki/Cloud-Init_Support sur les différents paramétrages.

Convertir la VM en template :

qm template 666

Utilisation du template

Cloner entièrement le template en VM.

Ajuster les paramètres Cloud-Init de la VM si nécessaire.
Démarrer la VM et récupérer l'IP (si nécessaire) :

Se connecter en SSH sur la VM avec la clef ssh renseignée dans cloud-init :

julien@mypc:~$ ssh -i .ssh/demo admin@172.16.20.15
...
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '172.16.20.15' (ED25519) to the list of known hosts.
Linux vm-deb12-01 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64
...
admin@vm-deb12-01:~$ sudo -l
...
User admin may run the following commands on vm-deb12-01:
 (ALL : ALL) ALL
 (ALL) NOPASSWD: ALL

Par défaut l'utilisateur définit par cloud-init appartient au groupe sudo et peut exécuter absolument tout sans saisir son mot de passe.

Debian : Optimisez votre distribution avec Tuned

Thu, 07 Sep 2023 00:56:00 +0200

Lorsque vous exécutez des applications exigeantes en termes de performances sur votre serveur Debian, il est essentiel de maximiser l'efficacité de votre matériel pour obtenir les meilleures performances possibles. L'utilitaire Tuned est un outil puissant qui vous permet de personnaliser les réglages du système en fonction de différents profils de performances, ce qui peut vous aider à optimiser votre serveur en fonction de vos besoins spécifiques.

Installation de Tuned

Avant de commencer à utiliser Tuned, vous devez d'abord l'installer sur votre système Debian. Vous pouvez le faire en utilisant la commande suivante :

sudo apt install tuned

Une fois l'installation terminée, vous pouvez activer et configurer Tuned.

Service

Tuned déploie son propre service. Pour en consulter son status, exécutez la commande suivante :

sudo systemctl status tuned.service

Le service est activé par défaut :

● tuned.service - Dynamic System Tuning Daemon
 Loaded: loaded (/lib/systemd/system/tuned.service; enabled; vendor preset: enabled)
 Active: active (running) since Wed 2023-09-06 20:17:21 CEST; 8min ago
 Docs: man:tuned(8)
 man:tuned.conf(5)
 man:tuned-adm(8)
 Main PID: 12013 (tuned)
 Tasks: 4 (limit: 2276)
 Memory: 15.9M
 CPU: 1.202s
 CGroup: /system.slice/tuned.service
 └─12013 /usr/bin/python3 -Es /usr/sbin/tuned -l -P

sept. 06 20:17:21 debian systemd[1]: Starting Dynamic System Tuning Daemon...
sept. 06 20:17:21 debian systemd[1]: Started Dynamic System Tuning Daemon.

Activation de Tuned

Tuned est conçu pour fonctionner avec des profils de performances prédéfinis. Vous pouvez les afficher en exécutant la commande suivante :

sudo tuned-adm list

Les profils disponibles seront :

Available profiles:
- accelerator-performance - Throughput performance based tuning with disabled higher latency STOP states
- atomic-guest - Optimize virtual guests based on the Atomic variant
- atomic-host - Optimize bare metal systems running the Atomic variant
- balanced - General non-specialized tuned profile
- cpu-partitioning - Optimize for CPU partitioning
- default - Legacy default tuned profile
- desktop - Optimize for the desktop use-case
- desktop-powersave - Optmize for the desktop use-case with power saving
- enterprise-storage - Legacy profile for RHEL6, for RHEL7, please use throughput-performance profile
- hpc-compute - Optimize for HPC compute workloads
- intel-sst - Configure for Intel Speed Select Base Frequency
- laptop-ac-powersave - Optimize for laptop with power savings
- laptop-battery-powersave - Optimize laptop profile with more aggressive power saving
- latency-performance - Optimize for deterministic performance at the cost of increased power consumption
- mssql - Optimize for MS SQL Server
- network-latency - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
- network-throughput - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks
- optimize-serial-console - Optimize for serial console use.
- oracle - Optimize for Oracle RDBMS
- postgresql - Optimize for PostgreSQL server
- powersave - Optimize for low power consumption
- realtime - Optimize for realtime workloads
- realtime-virtual-guest - Optimize for realtime workloads running within a KVM guest
- realtime-virtual-host - Optimize for KVM guests running realtime workloads
- sap-hana - Optimize for SAP HANA
- sap-netweaver - Optimize for SAP NetWeaver
- server-powersave - Optimize for server power savings
- spectrumscale-ece - Optimized for Spectrum Scale Erasure Code Edition Servers
- spindown-disk - Optimize for power saving by spinning-down rotational disks
- throughput-performance - Broadly applicable tuning that provides excellent performance across a variety of common server workloads
- virtual-guest - Optimize for running inside a virtual guest
- virtual-host - Optimize for running KVM guests

Vous pouvez ensuite activer le profil de performance de votre choix en utilisant la commande :

sudo tuned-adm profile <nom-du-profil>

Remplacez <nom-du-profil> par le nom du profil que vous souhaitez utiliser. Par exemple, si vous souhaitez activer le profil "throughput-performance", exécutez la commande suivante :

sudo tuned-adm profile throughput-performance

Vous pouvez obtenir le profil recommandé par l'application avec la commande suivante :

sudo tuned-adm recommend

Configuration personnalisée

Tuned permet également la création de profils de performance personnalisés. Pour ce faire, vous devez éditer le fichier de configuration de Tuned. Le fichier de configuration principal est situé dans le répertoire /etc/tuned/. Par exemple, pour créer un profil personnalisé nommé "mon-profil", vous pouvez créer un fichier de configuration /etc/tuned/mon-profil/tuned.conf.

Voici un exemple de fichier de configuration Tuned pour un profil personnalisé :

[main]
include=throughput-performance

[cpu]
governor=performance

[sysctl]
vm.dirty_ratio=10

Ce fichier de configuration active d'abord le profil "throughput-performance" en utilisant l'instruction include. Ensuite, il définit le gouverneur du CPU sur "performance" pour maximiser les performances du processeur. Enfin, il ajuste un paramètre de sysctl pour contrôler la gestion de la mémoire.

Après avoir créé votre profil personnalisé, vous pouvez l'activer de la même manière que les profils prédéfinis à l'aide de tuned-adm.

Conclusion

L'utilitaire Tuned est un outil précieux pour optimiser les performances de votre serveur Debian en fonction de vos besoins spécifiques. En utilisant les profils prédéfinis ou en créant des profils personnalisés, vous pouvez tirer le meilleur parti de votre matériel tout en garantissant une utilisation efficace des ressources système.

N'hésitez pas à explorer davantage les possibilités de Tuned et à l'adapter à vos besoins pour obtenir des performances optimales sur votre serveur Debian.

Network : Désactiver l’IPv6 sur Debian

Fri, 03 Feb 2023 14:40:24 +0100

Non-Persistance

sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1
sysctl -w net.ipv6.conf.lo.disable_ipv6=1
sysctl -w net.ipv6.conf.all.autoconf=0
sysctl -w net.ipv6.conf.default.autoconf=0

Persistance

Dans /etc/sysctl.conf :

net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.default.autoconf=0

Exécuter la commande suivante pour la prise en compte :

sysctl -p

Debian on slash-root.fr

Aptly : mirroiter Debian proprement

Ce qu’aptly fait vraiment

Installation

Via les paquets Debian

L’upstream (optionnel)

Configuration de base

Importer les clés GPG

Créer un miroir de Debian Trixie

Remplir le miroir

Créer un snapshot

Publier le snapshot

L’impact des hard links

Mettre à jour le miroir et basculer

Les dépôts locaux (mention rapide)

Exposer le dépôt

Le serveur embarqué (test uniquement)

nginx (production)

Automatiser avec cron

Nettoyage et maintenance

Quelques astuces

Conclusion

Debian : Configuration complète d’unattended-upgrades pour une sécurité sans effort

1. Introduction, ou pourquoi il est temps d’arrêter de faire semblant

2. Unattended-upgrades : le sysadmin silencieux qui ne prend jamais de pause café

3. Installation pour ceux qui savent encore taper sur un clavier

3.1 Les bases (même votre stagiaire pourrait le faire)

3.2 Activation pour les admins qui ont peur de modifier les fichiers de configuration à la main

4. Configuration pour les vrais barbus (ceux qui n’utilisent pas de GUI)

4.1 Sélection des dépôts (ou comment distinguer les mises à jour importantes des futilités)

4.2 Planification des mises à jour (ou quand laisser votre système jouer au docteur)

4.3 Gestion du reboot automatique (ou comment faire pleurer vos utilisateurs)

4.4 Notifications pour prétendre que vous surveillez vos serveurs

5. Dompter les mises à jour majeures (ou l’art d’éviter la crise cardiaque à 3h du matin)

5.1 Le piège des alternatives (ou comment se tirer une balle dans le pied automatiquement)

5.2 Solutions pour barbus confirmés (et amateurs de nuits tranquilles)

5.2.1 Entraîner debconf à ne pas vous demander votre avis

5.2.2 Expliquer à Debian ce qu’est une priorité (comme à votre chef de projet)

5.2.3 Le coup du hook post-installation (ou comment avoir le dernier mot)

5.2.4 Mettre un gilet pare-balles contre les versions majeures

5.2.5 La liste noire de la honte (ou comment bannir les paquets problématiques)

5.3 Le plan de bataille pour les vrais professionnels

6. Entrer dans la matrice : surveillance et déblocage des catastrophes nocturnes

6.1 Les logs que personne ne lit jamais (jusqu’à ce que tout explose)

6.2 Déclencher manuellement les mises à jour (pour le plaisir de voir quelque chose se casser en temps réel)

6.3 Techniques de réanimation pour système bloqué (ou comment sauver votre journée)

Libérez votre swap !

Préambule

Le swappiness, c’est quoi ?

Quelques commandes essentielles

1. Vérifier la valeur actuelle du swappiness

2. Modifier dynamiquement le swappiness

3. Rendre la configuration persistante

4. Comprendre les valeurs du swappiness

5. Désactiver et réactiver le swap

6. Identifier les processus utilisant le swap

Automatisation avec un script Bash

Script : free-swap.sh

Instructions :

Conclusion

Restic ou l’Importance des Sauvegardes de Données

Proxmox : Template Debian12 avec Cloud-Init

Création du template

Utilisation du template

Debian : Optimisez votre distribution avec Tuned

Installation de Tuned

Service

Activation de Tuned

Configuration personnalisée

Conclusion

Network : Désactiver l’IPv6 sur Debian

Non-Persistance

Persistance

Le `swappiness`, c’est quoi ?

1. Vérifier la valeur actuelle du `swappiness`

2. Modifier dynamiquement le `swappiness`

4. Comprendre les valeurs du `swappiness`

Script : `free-swap.sh`