Ce guide détaille la procédure de mise à jour de Debian 12 (Bookworm) vers Debian 13 (Trixie), sortie officiellement le 9 août 2025. Après une sauvegarde complète du système, il faut mettre à jour les paquets actuels, remplacer « bookworm » par « trixie » dans le fichier /etc/apt/sources.list, puis lancer apt update et apt full-upgrade. La migration inclut une revue des changements de configuration et un redémarrage. Trixie apporte des améliorations de sécurité (Intel CET, ARM PAC/BTI), des environnements de bureau mis à jour (GNOME 48, KDE Plasma 6.3) et l’abandon progressif du support 32 bits. Après la mise à jour, il est conseillé de moderniser les sources avec apt modernize-sources et de purger les paquets obsolètes. La documentation officielle et la communauté peuvent aider en cas de problème.
L’auteur raconte sa migration de services auto-hébergés depuis un VPS vers un mini-PC à domicile (un Minisforum UM880 Plus), en profitant de l’occasion pour mettre en place une infrastructure plus flexible et robuste avec Proxmox VE. L’objectif est de pouvoir expérimenter (notamment avec Kubernetes) sans risquer de casser sa production, tout en sécurisant ses données via le chiffrement disque et des sauvegardes solides. Après avoir installé Debian avec chiffrement LUKS, il automatise la configuration de Proxmox et du réseau (pont bridge) via Ansible, afin de pouvoir recréer rapidement son infrastructure en cas de vol ou de panne matérielle. Il prévoit d’utiliser OpenTofu et cloud-init pour déployer et configurer des machines virtuelles de manière reproductible, et Ansible pour gérer la configuration des services. Le billet détaille aussi les écueils rencontrés (comme le blocage au démarrage après l’installation de Proxmox, résolu en configurant une IP statique) et explique comment son playbook Ansible permet de tout réinstaller automatiquement. Une suite est annoncée pour aborder le déploiement de VM et la gestion des services avec Kubernetes.
Un mémo des actions à faire pour passer de Debian 12 à 13
Cet article explique comment configurer un "git credential helper" OAuth sur Debian et Microsoft WSL pour se connecter à GitLab, évitant ainsi de stocker des mots de passe ou des jetons d'accès personnels. Pour Debian, il utilise git-credential-oauth, tandis que pour WSL, il utilise le "Git Credential Manager" inclus avec "Git for Windows". Des instructions détaillées sont fournies pour chaque environnement, y compris la configuration pour des instances GitLab auto-hébergées.
L'article explique comment filtrer les conteneurs Docker en entrée et en sortie sur une machine Debian utilisant Firewalld et Salt. Voici un résumé succinct :
-
Objectif : Filtrer l'accès aux conteneurs Docker en utilisant les "zones" et "policies" de Firewalld.
-
Problématique : L'intégration de Firewalld avec Docker ne permet pas un filtrage granulaire des conteneurs. La solution proposée est de désactiver l'intégration iptables dans Docker et de configurer Firewalld pour gérer la publication des conteneurs.
-
Prérequis : Un serveur Salt avec les formules
docker-formulaetfirewalld-formula. -
Configuration :
- Exemple de configuration Salt pour déployer une image Docker de Shaarli et filtrer les accès.
- Configuration de Firewalld pour gérer les zones et les politiques de filtrage.
-
Commandes Utiles :
- Commandes pour lister les zones et politiques Firewalld, ainsi que pour vérifier les configurations de nftables et iptables.
L'article fournit des exemples de configurations et des commandes pour mettre en place ce filtrage.
C'est surtout la démarche pour résoudre ce problème qui est intéressante... et la conclusion de l'article :)
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre (sauf que l'installation se fait sous Debian / Proxmox)
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Le tuto marche aussi pour Debian "tout court"