Table des matières
Les paquets
Ne nous mentez pas !
On sait très bien que parmi les lecteurs, certains d’entre-vous gèrent leur système exactement comme l’image du dessus… alors au boulot, et il va falloir commencer par définir ce qu’est un paquet !
C’est quoi un paquet ?
Un paquet c’est une collection de fichiers installés sur un système et distribués sous la forme d’une archive compressé.
Il contient aussi des informations sur les dépendances (donc d’autres fichiers, applications et librairies nécessaires à leur fonctionnement) et les instructions d’installation à destination du gestionnaire de paquet.
Un paquet sera toujours fourni avec un nom, une version et une architecture (x86 ou x86-64 en général).
Ici, on peut voir le paquet openssh-server pour Debian, avec un nom et information de version (9.2p1), mais pas l’architecture…
Source : https://packages.debian.org/bookworm/openssh-server
… qui se trouve en réalité juste un peu plus bas, car nous sommes sur une page de téléchargement et qu’il faut choisir l’architecture qui nous intéresse.
Si on creuse et qu’on affiche la liste des fichiers qui composent le paquet, on retrouve tous les fichiers nécessaires et notre architecture mentionnée (amd64).
Les gestionnaires de paquets
Bon, tu t’imagines bien que dans notre monde si moderne et automatisé, il est hors de question d’aller installer chaque fichier et gérer les versions à la main…
Et c’est là que les gestionnaires de paquets rentrent en scène.
Ces programmes sont responsables de tenir à jour une base de données des paquets installés sur le système ainsi que leur version, et une liste des dépendances entre les paquets, qui permet notamment de les inclure automatiquement lors de l’installation.
Ils peuvent installer des paquets, les mettre à jour, les désinstaller, contrôler leur version, et même vérifier leur intégrité via une somme de contrôle (checksum en anglais).
Le gestionnaire de paquet ne sera pas forcément le même suivant la distribution GNU/Linux utilisée.
On retrouvera par exemple rpm, pour les distributions basées sur Red Hat, et dpkg, pour les distributions basées sur Debian comme Ubuntu ou Kali.
Source : https://www.debian.org/doc/manuals/debian-faq/pkgtools.en.html
Ces gestionnaires de paquets peuvent être utilisés directement pour installer ou vérifier un paquet en le téléchargeant en amont.
Je sais que tu as hâte de corrompre ton système, alors essayons tout de suite nos nouveaux pouvoirs avec dpkg.
Commence par télécharger un paquet, ici on garde openssh-server pour exemple.
Source : https://packages.debian.org/sid/amd64/openssh-server/download
L’option -i suivie du chemin vers le paquet .deb permettra de l’installer, tout en vérifiant la version et les dépendances.
cd /home/user/Downloads
dpkg -i ./paquet.deb
Super ! Rien ne fonctionne !
Bon ok, mais par contre on peut déjà faire deux observations…
- Les droits super-utilisateur sont nécessaires (donc obligation d’utiliser sudo ici)
- Dpkg est verbeux et nous donne accès à toutes les informations suite à cet échec
Dans ce cas précis, il s’agit notamment d’un problème de version du paquet openssh-client, mais les erreurs peuvent varier.
Il est aussi possible de vérifier les informations d’un paquet installé, plutôt utile en cas de diagnostic (pour vérifier la version notamment).
sudo dpkg -p libc6
APT, les fichiers sources.list et les dépôts
Tout ça c’est bien beau, mais tu te doutes qu’on ne va pas installer et gérer tous les paquets uns par uns à la main… encore une fois.
La solution à toute cette gestion, ce sont les méta-gestionnaires de paquets… ou dit plus simplement, des suites d’outils qui vont gérer tout ça pour nous.
Pour les distributions Debian, cet outil s’appelle apt, et il te permettra en une seule commande d’installer n’importe quel paquet désiré… tant que tout est bien configuré.
Pour commencer, fini le téléchargement sauvage de paquets obscurs, ici tout est stocké sur des serveurs gérés par la communauté et on appelle ça des dépôts (repositories en anglais, souvent raccourci en « repo »).
Ces dépôts stockent toutes les applications/paquets qui ont été testés et validés par la communauté, parfois sous plusieurs versions pour garantir la retro-compatibilité, suivant des règles qui varient légèrement.
Pour l’instant, retiens seulement que certains repos mettront l’accent sur la stabilité, la sécurité, ou bien choisiront d’inclure (ou non) des paquets propriétaires.
Localement, ce méta-gestionnaire stocke une liste de tous les paquets disponibles ainsi que leur version, ce qui permet de vérifier rapidement (et sans connectivité) l’état du dépôt et des paquets qui le compose.
Pour mettre à jour cette liste, utilise la commande update et observe que plusieurs URLs différentes sont utilisées par l’outil, permettant de séparer les paquets en différentes catégories.
sudo apt update
Ces URLs sont les adresses des dépôts et il est possible d’aller les consulter ou les modifier via le fichier /etc/apt/sources.list.
La syntaxe est assez simple à comprendre… on retrouve en général l’URL du dépôt, puis le nom de code de la distribution actuelle (dans cet exemple : bookworm), suivie des composants souhaités.
cat /etc/apt/sources.list
Les composants (components en anglais) sont en réalité des catégories de paquets, main indiquant qu’ils ont été validés à 100% comme faisant partie de la distribution Debian, contrib indiquant qu’ils ont été validés mais que certaines librairies incluses ne le sont pas, etc…
Comme dit précédemment, l’outil apt utilisera la liste locale lors de l’installation d’un paquet… ce qui veux dire qu’il est préférable d’utiliser la commande update avant toute installation pour éviter toute erreur liée à une différence entre la liste locale et celle du repo.
Bon… On lance l’installation d’un paquet au hasard pour tester ça ?
sudo apt install openssh-server
Cette fois, on obtient une information supplémentaire… notre paquet est en fait déjà installé et à jour… mais il y a peut être un soucis de dépendances à régler.
Il est aussi possible d’aller chercher directement des infos sur un paquet depuis la ligne de commande, pratique pour éviter une recherche Google et gagner du temps.
sudo apt search openssh-server
Et pour finir, on teste une désinstallation propre et sans fioriture.
sudo apt remove package
Bonus
- Obtenir les informations d’un paquet qui n’est pas installé grâce à la commande dpkg.
- Comment faire pour effacer les fichiers de configuration lors de la désinstallation d’un paquet et quel est l’intérêt ?
- Quel est le danger si on configure notre sources.list pour utiliser un dépôt de paquet non officiel ?
- Qu’est-ce que c’est le Debian Free Software Guidelines ? Quel intérêt ?
- Est-ce que les distributions Red Hat possède le même genre de systèmes ?
- Quelle est la différence entre une release standard et rolling ?
Librairies partagées
Petite devinette avant de passer à la suite…
Beaucoup de programmes partagent des fonctionnalités communes, comme lire des fichiers, formater du texte, ingérer des données, chiffrer des secrets et bien d’autres choses.
A votre avis, est-ce que les développeurs sont :
- A – des abrutis très travailleurs qui ré-écrivent intégralement le code nécessaire à chaque nouvelle application ?
- B – des gens plutôt malins qui ont un moyen de partager du code déjà écrit avec tous les programmes qui en ont besoin ?
Félicitations, tu as compris tout seul l’intérêt des librairies partagées !
En tout cas, c’est leur nom sur Linux, du côté Windows on appellera plutôt ça des DLLs pour Dynamic Link Library.
Elles sont reconnaissables grâce à l’extension .so (pour Shared Object) et sont chargées en mémoire au lancement de l’application qui en fait usage.
L’application principale devra forcément pouvoir localiser la librairie sur le système de fichier et posséder les droits pour la charger, sous peine de planter…
Et c’est plutôt normal d’ailleurs, imagine si on enlève les ailes à un avion… il risque d’avoir du mal à décoller (sauf si le pilote s’appelle Jebediah, mais je m’égare wink wink).
Si ce genre de problème survient, une recherche permettra souvent d’installer la librairie manquante (ou très souvent le paquet la contenant).
Fait aussi attention à ce que le répertoire où se trouve la librairie soit ajoutée à la variable d’environnement $PATH, pour que l’application puisse la trouver si elle y fait référence par son chemin relatif seulement…
Pour vérifier les librairies utilisées par un programme, la commande ldd sera ta meilleure amie.
ldd /bin/ls
Les chemins des librairies partagées sont stockés dans le fichier /etc/ld.so.conf, qui est lu au démarrage du système puis mis en cache.
Si certains chemins ont été ajoutés à ce fichier, il est possible de mettre le cache à jour avec ldconfig…
Rarement utile, mais certaines procédures d’installation un peu crado te le demanderont peut-être.
Liens symboliques et physiques
Lien symbolique
Les liens (symboliques et physiques) sont très utilisés en administration Linux et permettent de relier deux points du système de fichier (oui merci Sherlock, c’est la définition d’un lien).
Pour illustrer, si un programme n’arrive pas à trouver une librairie, par exemple car le nom est modifié par une mise à jour mineure, il est possible de réaliser un lien symbolique entre le fichier attendu et le fichier cible.
Autrement dit, on créé un lien à l’endroit où le programme va chercher sa librairie et celui-ci va pointer vers sa vraie localisation… l’équivalent du raccourci Windows au final.
touch test1.0.so
ln -s /home/user/test1.0.so /home/user/test1.0.1.so
Note que la cible du lien est affichée lorsqu’on affiche les détails avec ls, et que la section des permissions en début de ligne indique le lien avec un l dans le type de fichier.
Dans ce cas précis, l’avantage c’est d’éviter de modifier /etc/ld.so.conf définitivement… et il y a quand même moins de risque d’exploser son système en choisissant cette option.
Bien entendu, effacer la cible d’un lien symbolique (le vrai fichier donc) cassera tous les liens associés et le fichier deviendra inaccessible à tout programme qui les utilisait.
Lien physique
Un lien physique remplit les mêmes fonctions, mais possède des particularités intéressantes… C’est un autre pointeur vers le fichier cible, c’est à dire un moyen alternatif d’y accéder sur le système de fichier.
Effacer la cible d’un lien physique ne fera qu’effacer ce moyen d’y accéder, et tous les autres liens resterons valides, le fichier étant toujours existant sur le disque tant qu’un lien physique existe.
On remarque d’ailleurs que les permissions ne mentionnent plus le l pour signifier un lien, et qu’il s’agit d’un double parfait du fichier original.
ln /home/lib/lib1.0.1.so /home/lib/lib1.0.so
Un fichier dans le système de fichier Linux est en réalité représenté par un identifiant unique appelé inode, qui peut être affiché avec ls.
On remarque que le lien physique porte le même inode que sa cible, mais que ce n’est pas le cas du lien symbolique.
ln -s /home/user/test1.0.so /home/user/test1.0.2.so
ls -il
Bonus
- Comment faire la différence entre un fichier, un lien symbolique et un lien physique ?
- Qu’est-ce qu’un inode ?
La suite c’est par là !