2.2 Gestion des paquets¶
☕ À la machine à café de CorpTech
« D’après le prestataire, tous les logiciels étaient installés. Quand on lui a demandé les numéros de version, il a répondu “les dernières ...” 🧐
Pré-requis
Votre VM doit impérativement accéder à internet pour ce chapitre. Si c'est pas le cas réglez ce problème avant d'aller plus loin.
Observation initiale du système¶
Avant toute explication, observez l’état réel du système.
cat /etc/apk/repositories
apk info busybox musl
apk info | wc -l
Note
La commande apk info | wc -l affiche le nombre de paquets installés. Le mécanisme utilisé pour compter sera étudié plus tard.
Constat :
- les repositories sont définis dans un fichier texte
- chaque paquet installé possède une version précise ;
- aucune information de version « abstraite » n’existe.
2.2.1 Introduction (Alpine Package Keeper)¶
Alpine Linux utilise apk (Alpine Package Keeper) pour installer, mettre à jour et supprimer des logiciels.
Pour fonctionner correctement, apk repose sur trois notions complémentaires :
Concepts essentiels
Mirror : le serveur où sont stockés les paquets. Repository : la catégorie de paquets (main, community, testing). Release : une version stable d’Alpine rassemblant des repositories cohérents.
2.2.2 Mirror: où sont les paquets ?¶
Un mirror (mirr) est un serveur contenant les paquets et leurs index.
apk télécharge tout depuis cette adresse.
Exemples :
https://dl-cdn.alpinelinux.org/
https://mirror.example.org/alpine/
2.2.3 Repository: comment sont organisés les paquets ?¶
Un repository est une catégorie de paquets classée par niveau de stabilité :
- main → paquets officiels, testés, stables
- community → paquets fiables issus de la communauté
- testing → paquets expérimentaux (uniquement sur edge
Note
testing = instable. Pas destiné à la production.
2.2.4 Release : quelle version d’Alpine ?¶
Une release est un ensemble cohérent de packages : noyau, outils système et bibliothèques tous compilés ensemble.
Deux familles de releases :
- stable :
v3.18,v3.19,v3.20
→ versions figées, mises à jour tous les 6 mois - edge : rolling release
→ mise à jour continue, réservée au développement
Warning
Les repositories d’une release ne sont pas compatibles avec ceux d’une autre. Ne jamais mélanger : v3.20/main + edge/main
Source Alpine : “Do not enable Main/Community from stable and edge at the same time. Mixing can break your system.”
Contrainte de version sur un paquet¶
Essayez d’installer une version précise d’un paquet :
apk add nginx=1.22
Résultat:
fetch http://dl-cdn.alpinelinux.org/alpine/v3.22/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.22/community/x86_64/APKINDEX.tar.gz
ERROR: unable to select packages:
nginx-1.28.0-r3:
breaks: world[nginx=1.22]
L’installation échoue; Seule la version nginx-1.28.0-r3 est installable, aucune version antérieure n’est proposée.
Politique Alpine : une seule version par paquet¶
Alpine applique un modèle minimaliste :
- seul le dernier build d’un paquet est conservé (rolling repository)
- les anciennes versions disparaissent
- l'objectif est de simplifier, sécurité, stockage minimal
Conséquence : Impossible de reconstruire à l’identique (en terme de version) une VM plusieurs mois après si un paquet a été mis à jour.
Mélange de repositories (analyse)¶
Sans effectuer de modification sur votre système :
- observez les repositories configurés dans
/etc/apk/repositories - identifiez à quelle release ils appartiennent
À partir de la documentation Alpine, expliquez pourquoi le mélange de releases peut rendre un système instable.
2.2.5 Exercices à rendre¶
Question 1
Que se passe-t-il si apk installe un paquet compilé pour une autre release que celle de votre système ?
Question 2
Que se passe-t-il si vous activez un repository d’une autre release ?
Consigne
Votre réponse doit obligatoirement comporter :
-
URL (documentation Alpine)
-
extrait cité
-
commande exécutée
-
votre explication
Sources officielles :
- Repositories — https://wiki.alpinelinux.org/wiki/Repositories
- apk — https://docs.alpinelinux.org/user-handbook/0.1a/Working/apk.html
- apk-tools — https://gitlab.alpinelinux.org/alpine/apk-tools
Commandes essentielles¶
apk fournit un ensemble de commandes simples pour gérer les paquets.
Voici les opérations indispensables à maîtriser.
Mise à jour de la liste des paquets¶
apk update
Met à jour l’index des paquets présents dans les repositories que vous avez configurés.
Note
À exécuter avant toute installation, surtout après modification de /etc/apk/repositories.
Installer un paquet¶
apk add nginx
apk add nano openssh-server
Télécharge et installe :
- le paquet
- ses dépendances
- les fichiers de configuration par défaut
Warning
apk n’installe que ce qui existe dans les repositories de votre release. Si le paquet n’existe plus → erreur (politique Alpine).
Supprimer un paquet¶
apk del nano
Note
Contrairement aux distributions « Debian like », il n’existe pas d’équivalent à apt purge avec Alpine Linux.
=== Je ne vois pas ce que ça apporte, si pas de démonstration ===
Handbook Alpine Linux
"Désinstalle le paquet sans toucher aux fichiers modifiés dans /etc."
Mettre à jour les paquets installés¶
apk upgrade
Avant exécution :
apk info nginx
Après exécution :
apk info nginx
=== Pourquoi ??? ===
Danger
Sur Alpine stable, un apk upgrade peut :
-
casser la compatibilité d’une VM construite plusieurs mois plus tôt
-
rendre impossible la réinstallation d’un ancien paquet
Aucune procédure de retour arrière n’est fournie par apk.
Vérifier l’intégrité des paquets installés¶
=== A quoi ça sert concrètement ===
apk audit
À utiliser après modification manuelle de fichiers ou incident système.
Nettoyer l’espace disque¶
apk cache clean
À utiliser après plusieurs installations / suppressions pour constater l’impact disque.
A rendre¶
Exercice 1¶
Cherchez quel paquet installe la commande
ssh-keygen.
Exercice 2¶
Installez
nginx, listez ses fichiers, puis supprimez-le proprement.
Exercice 3¶
Expliquez, documentation à l’appui, ce que fait
apk upgrade.
Justifiez dans quel cas un administrateur ne doit pas l’utiliser.