Installation des logiciels

État :

Retour au document principal

Pré-requis

• La ligne de commande

Objectifs

• Comprendre l'utilisation du fichier Makefile lorsqu'on compile de gros projets à partir des sources
• Manipuler efficacement les sources des programmes et lancer les commandes appropriées leur compilation
• Résolution des problèmes relatifs aux bibliothèques partagées (ou dynamiques)

• Utiliser les gestionnaires de paquets pour rechercher, ajouter, supprimer ou vérifier des logiciels (NdT : RPM et Debian)

Introduction

Commençons par un petit exemple de code. Même si nous n'avons pas besoin d'une compréhension avancée du langage C, ces exemples pourront vous aider à résoudre des situations courantes.

• Le fichier main.c :

  #include<stdlib.h>
  
  int main(){
     Bonjour();
  }

• Le fichier Bonjour.c :

  #include<stdio.h>
  
  void Bonjour(){
          printf(“Salut ! \n”);
  }

  Vous noterez que main.c est incomplet puisque la fonction Bonjour() n'est pas définie. De même, Bonjour.c ne contient pas de déclaration "main". Ces fichiers sont interdépendants. Cependant, on peut compiler des fichiers objets (.o) qui sont comme des fichiers binaires non exécutables et qu'on peut utiliser pour construire une application.

• Compilation des fichiers objets :

  gcc –c main.c
  gcc –c Bonjour.c

  Ceci générera deux fichiers main.o et Bonjour.o qu'on peut désormais utiliser pour construire l'application app.

• Compilation de app :

  gcc –o app main.o Bonjour.o

  L'option -o spécifie simplement un nom pour le code compilé. Si on ne précise pas de nom, le fichier s'appelle par défaut a.out.

  On peut automatiser toutes ces étapes en utilisant un fichier Makefile. Voici un Makefile minimal pour compiler notre programme app.

• Makefile

  SHELL = /bin/sh
  CC = /usr/bin/gcc
  app: main.o Bonjour.o
          $(CC) –o app main.o Bonjour.o
  main.o: main.c
          $(CC) –c main.c
  Bonjour.o: Bonjour.c
          $(CC) –c Bonjour.c

Bibliothèques statiques et partagées

Lorsque des fonctions sont souvent utilisées, elles sont stockées dans des bibliothèques. On peut alors lier du code qui utilise ces fonctions aux bibliothèques qui les contiennent pendant la compilation. Les bibliothèques peuvent être liées statiquement ou dynamiquement au code.

La compilateur gcc a de nombreuses options pour lier les les bibliothèques. Cependant, par défaut gcc lie les fichiers donnés à la ligne de commande qui ne comportent pas l'extension .c (seuls les fichiers .c sont traités comme du code).

Illustration : lien par défaut

gcc main.c Bonjour.o

Cette commande produit un fichier a.out exécutable lié statiquement à l'objet Bonjour.o.

Illustration d'une application liée statiquement (a.out) :

Bibliothèques statiques

Les bibliothèques statiques sont des archives de fichiers .o. Ces archives sont créées avec la commande ar et comportent une extension .a.

Illustration : ajout d'un fichier objet à une archive

ar rcs libfoo.a fichier1.o fichier2.o

Bibliothèques dynamiques / partagées

Une bibliothèque partagée est une bibliothèque qui est chargée par le programme quand celui-ci est exécuté. On dit également que la bibliothèque est chargée dynamiquement.

Illustration : Création d'une bibliothèque partagée :

gcc –c –fPIC Bonjour.c.c     crée le fichier objet
gcc –shared –W1,soname,libfoo.so.1 –o libfoo.so.1.0 Bonjour.o

L'option -fPIC génère du code indépendant de la position (PIC : Position Independent Code).

Illustration : compilation avec une bibliothèque partagée

gcc main.c libfoo.so.1.0

Cette commande produit un fichier exécutable a.out. Cependant, si vous essayez de le lancer, il vous affichera l'erreur suivante :

Illustration : Erreur due à une bibliothèque partagée non trouvée

./a.out: error while loading shared libraries: libfoo.so.1.0: cannot open shared object file: No such file or directory 

Cette erreur illustre ce qui se passe quand l'éditeur de liens n'arrive pas à trouver la bibliothèque dynamique libfoo.so.1.0. Nous verrons comme résoudre ce problème dans la prochaine partie.

Illustration d'une application liée dynamiquement (a.out) :

Le processus chargé d'attacher une bibliothèque dynamique au lancement, appelé la liaison, est géré par l'éditeur de lien (ou linker) ld.so. Comment l'éditeur de liens sait où trouver libfoo.so ? La réponse à cette question se trouve juste en-dessous.

Attribution des noms aux bibliothèques partagées et chargement dynamique

Pour comprendre comment les bibliothèques sont gérées sous Linux, nous allons nous baser sur l'exemple ci-dessous.

• Tout d'abord, la bibliothèque est générée avec la commande suivante :

   gcc -shared -soname,libfoo.1 -o libfoo.1.0 

• Voici à quoi correspondent les noms des fichiers

  Bibliothèque	Fichier	Signification
  libfoo.so.1	/usr/lib/libfoo.so.1.0	nom réel
  	/usr/lib/libfoo.so.1	soname (nom du so)
  	/usr/lib/libfoo.so	nom du lien

• Enfin, on se rappellera que la liste des es bibliothèques est maintenue par la commande ldconfig qui lit le fichier de configuration /etc/ld.so.conf pour générer le cache /etc/ld.so.cache. ld.so est le chargeur et éditeur de liens dynamique sous Linux.

Pour connaître les bibliothèques partagées nécessaires à l'exécution d'un programme, on utilise la commande ldd.

Exemple :

ldd a.out
        libfoo.so.1.0 => not found
        libc.so.6 => /lib/libc.so.6 (0x40028000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Vous noterez que libfoo.so.1.0 est introuvable. En effet, a.out doit charger dynamiquement cette bibliothèque mais l'éditeur de liens ld.so ne la connaît pas.

En fait l'éditeur de liens utilise une base de donnée appelée ldcache dont le contenu est de la forme :

soname =>/chemin/vers/bibliothèqe

La commande ldconfig -p permet d'afficher le contenu du ldcache :

ldconfig -p
        libaudiofile.so.0 (libc6) => /usr/lib/libaudiofile.so.0
        libaudiofile.so (libc6) => /usr/lib/libaudiofile.so
        libaudio.so.2 (libc6) => /usr/X11R6/lib/libaudio.so.2
        libattr.so (libc6) => /usr/lib/libattr.so       ..........

Le ldcache est généré à l'amorçage du système par la commande ldconfig. Par défaut, ldconfig examine les répertoires /lib et /usr/lib pour construire le ldcache.

Si d'autres répertoires contiennent des bibliothèques, comme /usr/local/lib, /opt/lib ou /usr/X11R6/lib, vous devez répertorier ces répertoires dans le fichier /etc/ld.so.conf pour informer ldconfig qu'il doit les prendre en considération lorsqu'il génère le cache.

Que se passe-t-il au lancement d'une application ?

L'application demande les bibliothèques dont il a besoin à l'éditeur de lien en utilisant le soname. Ensuite, l'éditeur de lien interroge le ldcache et associe le soname avec le chemin complet vers la bibliothèque, puis il établit le lien entre la bibliothèque et l'application.

Que se passe-t-il si le ld-cache ne contient pas le chemin complet vers la bibliothèque ?

En général, le programme n'arrive pas à se lancer et affiche un message d'erreur du type "cannot open shared object file: No such file or directory". Cependant, on peut aussi définir la variable globale LD_LIBRARY_PATH et lui assigner le nom du répertoire contenant la bibliothèque.

À partir de ça, nous savons comment résoudre le problème que nous avions rencontré avec notre programme en utilisant l'une des deux méthodes suivantes :

1. Si vous devez tester temporairement le programme, définissez la variable LD_LIBRARY_PATH :

   export LD_LIBRARY_PATH=$(pwd)

2. Si vous êtes administrateur et que vous souhaitez que la bibliothèque soit accessible à tout le monde, copiez le fichier libfoo.so.1.0 puis lancez ldconfig pour mettre à jour le ldcache.

Notes :

• Le spécifications GNU conseillent de placer les bibliothèques dans /usr/local/lib/. Ces recommandations sont généralement suivies par les développeurs et la plupart des sources installent les bibliothèques dans ce répertoire et les binaires dans /usr/local/bin/. On utilise les commandes "make install" et "make uninstall pour installer et supprimer ce code.

• La FHS (norme de la hiérarchie des systèmes de fichiers que nous avons introduit dans les système de fichiers) recommande de placer les bibliothèques dans /usr/lib/ et les binaires associés dans /usr/bin/. Cette convention est suivie par les distributions Linux. Dans les faits, le code mûr et stable est placé dans /usr/ plutôt que dans /usr/local/ et les deux standards ne sont pas en contradiction. L'installation et la suppression de ce code se fait en utilisant les commandes de gestion des paquets rpm ou deb.

Remarque : Sur certaines distributions, ldconfig n'examine pas /usr/local/lib. il suffit d'ajouter le répertoire dans /etc/ld.so.conf et... redémarrer ?

Installation à partir des sources

Les projets open source sont souvent distribués sous forme d'archives tar. De nombreux environnements de développement (glade, kdevelopp, etc.) génèrent les fichiers qui facilitent la compilation et l'installation d'un projet.

Les archives non compressées

Les archives non compressées portent l'extension .tar. Par exemple, si le projet a été développé dans un répertoire appelé mon-projet-v.1/, alors la commande suivante archivera le répertoire avec ses fichiers et sous-répertoires :

tar c mon-projet-v.1/ > mon-projet-v.1.tar

ou

tar cf  mon-projet-v.1.tar mon-projet-v.1/

Comme la plupart des projets sont plutôt gros et téléchargeables sur Internet, on les trouve plus souvent sous une forme compressée.

Compression

Les trois outils utilisés pour la compression sont compress (ancien), gzip et bzip2. Contrairement au zip de windows, ces outils ne permettent de compresser que des fichiers. Cependant, comme une archive est un fichier qui contient toutes les informations pour pouvoir récupérer des répertoires, on peut utiliser ces commandes avec les archives. On appelle souvent les archives compressées "tarball".

Exemples :

compress -v FICHIER1
FICHIER1:  -- replaced with FICHIER1.Z Compression: 40.29%

gzip  -v FICHIER2
FICHIER2:   53.4% -- replaced with FICHIER2.gz

bzip2 -v FICHIER3
FICHIER3:    2.326:1,  3.439 bits/byte, 57.01% saved, 605504 in, 260320 out.

Remarques :

1. Lorsque vous compressez un fichier, l'extension .Z, .gz ou .bz2 est ajoutée au nom du fichier
2. Ces commandes de compression ne fonctionnent qu'avec des fichiers, pas avec des répertoires
3. On ne peut compresser qu'un fichier à la fois (pas de caractère générique !)

On peut également utiliser les commandes zcat et bzcatpour décompresser des fichiers, cependant les fichiers décompressés sont envoyés à STDOUT donc il est nécessaire de faire une redirection :

zcat FICHIER.Z > FICHIER1

Archives et compression

Le tableau précédent présente les options de tar Z,z et j qui font appel aux outils de compression appropriés lorsque c'est nécessaire.

Les deux exemples suivants sont équivalents :

tar cf  mon-projet-v.1.tar mon-projet-v.1/
bzip2  mon-projet-v.1.tar

tar cjf  mon-projet-v.1.tar.bz2 mon-projet-v.1/

Utilisation de tar

Nous savons désormais comment créer des archives. Il nous reste à connaître les options les plus courantes de tar.

Exemples : extractions

tar xvjf monprojet-v.1.tar.bz2
tar xzf autre-projet-v.2.0.tar.gz

Exemples : tests

tar tjf monprojet-v.1.tar.bz2
tar tzf autre-projet-v.2.0.tar.gz

Exemples alternatives utilisant zcat ou bzcat

bzcat monprojet-v.1.tar.bz2 | tar xf -
zcat autre-projet-v.2.0.tar.gz | tar tf -

Fichiers courants dans les sources des projets

Une fois l'archive d'un projet extraite, vous devriez trouver les fichiers suivants :

• configure : c'est un script qui détermine l'architecture système utilisée. Il vérifie également que tout ce qui est nécessaire à la compilation du projet est présent : compilateur, bibliothèques et en-têtes. Ces informations sont ensuite écrites dans des fichiers appelés Makefile. La méthode la plus sûre pour lancer ce script est de taper :

   ./configure’ 

  Vous pouvez également décider où vous installerez le projet avec l'option --prefix. Par défaut, la plupart des projets s'installent dans /usr/local. Si vous souhaitez installer le projet compilé dans votre répertoire personnel, vous devriez taper :

  ./configure –prefix=$HOME

• Makefile : ce fichier agit comme un fichier de configuration pour la commande make. Les principales informations qu'il contient sont :

  • le nom du compilateur et les options de compilation
  • le chemin pour les bibliothèques partagées et les fichiers d'en-tête
  • les liens entre les fichiers source (.c) et les fichiers objets (.o)

Compilation du projet

Si les fichiers que nous venons de voir sont présents, alors vous avez une bonne chance de pouvoir installer le programme sur votre ordinateur en suivant les étapes suivantes :

./configure
make
make install 

Il est très fortement recommandé de lancer ./configure et make en utilisateur normal. make install ne peut être lancé qu'en tant que root pour les répertoires d'installation protégés en écriture (/usr et /usr/local).

Le script ./configure a de nombreuses options. Pour une installation personnalisée, consultez ces options avec :

./configure –-help 

RPM : RedHat Package Manager

La plupart des distributions Linux utilisent un système de gestion de paquets pour installer, mettre à jour ou rechercher des programmes. Les systèmes de gestion de paquets Debian et RPM sont les plus populaires. Nous verrons dpkg et les outils Debian dans la prochaine partie.

Illustration : Fonctions d'un gestionnaire de paquets

Conventions de noms pour les paquets

Il n'y a pas de convention stricte, mais la plupart des paquets rpm sont sous la forme :

nom-version_programme-version_paquet.architecture.rpm 

L'architecture indique au choix le type d'architecture système du binaire (i386, ppc, ia64, noarch,...) ou si le paquet contient les sources du programme (src).

Modes majeurs ou mineurs

Suivant leur place dans la ligne de commande, les options changent de signification. rpm fait la distinction entre la première option et les suivantes.

La première option donnée à rpm est son mode majeur. Par exemple dans la commande rpm -iv A.rpm, l'option "i" est l'option majeure qui entrainera l'installation du paquet A.

De même, une option qui n'est pas en première position est en mode mineur. par exemple dans rpm -qpi, l'option "i" est en mode mineur et récupèrera des informations sur le paquet A comme son auteur et son type de licence.

Voici les modes majeurs pour rpm :

Et voici les modes mineurs pour rpm :

Modes de recherche

Il y a trois types de recherches : les paquets non installés, les paquets installés et les fichiers.

D'autres options vous permettent d'obtenir des information sur tous les fichiers installés -l, la documentation -d, les fichiers de configuration -c, etc.

Considérons par exemple le paquet routed-0.17.i386.rpm. Nous pouvons faire une requête sur le paquet et lister son contenu avant l'installation avec l'option -l :

rpm –qpl routed-0.17.i386.rpm 

Une fois le paquet installé, on peut interroger le paquet avec :

rpm –ql routed-0.17     ou
rpm –ql routed 

Enfin, si nous voulons trouver le nom du paquet qui a installé le fichier /usr/sbin/routed, on interrogera la base de données de rpm avec :

rpm –qf /usr/sbin/routed 

Options spéciales

Signatures des paquets

Vous pouvez vérifier la signature de chaque paquet distribué comme partie d'un projet. Par exemple, pour récupérer les clés de tous les développeurs impliqués dans le projet Fedora, il vous suffit de faire (seulement une fois) :

rpm –-import /usr/share/rhn/RPM-GPG-KEY-fedora

Vous pouvez désormais télécharger n'importe quel paquet à partir d'un mirroir FTP des RPMs du projet. Par exemple nous avons téléchargé zlib-1.2.1.1-2.1.i386.rpm à partir du sous-répertoire Fedora de ftp.mirror.ac.uk. Nous pouvons vérifier l'authenticité du fichier avec :

rpm --checksig /home/adrian/zlib-1.2.1.1-2.1.i386.rpm
/home/adrian/zlib-1.2.1.1-2.1.i386.rpm: (sha1) dsa sha1 md5 gpg OK

Intégrité des paquets

La commande suivante vérifie l'intégrité du paquet bash :

rpm –V bash

Cette commande ne nous retourne rien. Si nous tapons les commandes suivantes en tant que root :

chown bin /bin/bash
chmod 775 /bin/bash

Si nous re-vérifions l'intégrité du paquet bash, cette fois-ci nous avons :

rpm –V bash
.M...U..   /bin/bash

Le gestionnaire de paquet a comparé l'état de chaque fichier du paquet bash avec l'état de ces fichiers stocké dans sa base de données. Les modifications sur /bin/bash ont été identifiés.

Il est possible de faire un contrôle d'intégrité sur tous les paquets installés sur le système en ajoutant l'option "a" (--all) après "V" (--verify).

L'option --verify effectue un certain nombre de tests sur chaque fichier. Les caractères suivants permettent d'identifier les erreurs :

||?||le test n'a pas pu être effectué|

Pour aller plus loin : construire des paquets RPM (n'est pas au programme des LPIs)

: Ce paragraphe ne fait pas partie des objectifs pour l'examen LPI 101. En suivant cette partie, vous rencontrerez peut-être des problèmes avec l'option --rebuild. Ce problème est du au fait que les nouvelles versions de RPM utiliser rpmbuild au lieu de rpm pour reconstruire des paquets.

Le code source de quantité de paquets RPM est également disponible en tant que paquet RPM est peut être utilisé pour construire un paquet binaire. La convention pour l'attribution du nom de fichier est :

nom-version_programme-version_paquet.src.rpm

Ces paquets contiennent au minimum deux fichiers : l'archive tar avec le code source et un fichier spec. Le fichier spec contient les instructions pour les appliquer les rustines (patchs), compiler et construire les paquets RPM. S'il faut appliquer un patch avant de compiler le paquet, alors le patch est inclut dans le paquet source.

Il y a trois méthodes pour construire un paquet RPM. Nous partirons d'un paquet nommé nom-version_programme-version_paquet.src.rpm.

Pour commencer, vous aurez besoin d'installer le paquet rpm-build :

• Méthode 1 : Installer le paquet source avec :

  rpm –ivh nom-version_programme-version_paquet.src.rpm

  Vous retrouverez les fichiers dans les répertoires suivants :
  • /usr/src/redhat/SPECS
  • /usr/src/redhat/SOURCES
  Dans le répertoire /usr/src/redhat/SPECS, vous pouvez désormais voir un fichier appelé nom.spec (où "nom" est le nom du paquet). Pour commencer à construire le paquet name-version-release.i386.rpm, nous tapons la commande suivante :

  rpm –ba nom.spec

  Cette commande lance une série de scripts. L'archive dans /usr/src/redhat/SOURCES est décompressée dans /usr/src/redhat/BUILD. Si la compilation a réussi, le paquet binaire est sauvé dans /usr/src/redhat/RPMS/. Il y a plusieurs sous-répertoires correspondants aux différents processeurs, modèles et générations. Si la compilation n'est pas spécifique à l'architecture, le paquet est placé dans le sous-répertoire noarch.

• Méthode 2 : Cette méthode suit la même chaîne d'évènements que la précédente, mais tout est fait en une seule commande :

  rpm –-rebuild  nom-version_programme-version_paquet.src.rpm

• Méthode 3 : Parfois les développeurs mettent à disposition une archive tar avec un fichier spec. Si l'archive s'appelle nom-version_programme.tar.gz, vous pouvez rechercher le fichier spec avec la commande suivante :

  tar tzvf nom-version_programme.tar.gz | grep .spec

  Si l'archive contient un fichier spec, alors vous pouvez construire le paquet RPM en tapant :

  rpm –bt nom-version_programme.tar.gz

Gestion des paquets Debian

Les systèmes basés sur Debian utilisent le gestionnaire de paquets propre à Debian en lieu et place de la gestion des paquets RPM. Le gestionnaire de paquet Debian est plus rigoureux est plus configurable que les rpm, mais pour des raisons historiques est moins largement utilisé (NdT : peut-être encore vrai au moment de la rédaction du document mais ça me semble beaucoup moins vrai aujourd'hui).

L'approche utilisée pour la gestion de paquets sous Debian est très proche de celle des RPMs. La comande correspondant à "rpm" sur Debian est "dpkg".

Conventions de noms pour les paquets

De même que pour les RPMs, les paquets Debian sont des fichiers appelés comme suit :

nom_version-versionpaquet_architecture.deb

La version du paquet indique la version Debian de la version du logiciel et l'architecture indique l'architecture du système (i386, sparc, all).

dpkg

dpkg est l'outil de base pour installer, construire, supprimer et gérer les paquets Debian. Cependant, on utilise plus souvent d'autres programmes qui contrôlent dpkg pour la gestion des paquets : apt, dselect (NdT : aptitude). dpkg prend plusieurs paramètres dans la ligne de commande : une action et zéro ou plusieurs options. Le paramètre <action> dit ce que dpkg doit faire et les options modifient l’action d’une manière ou d’une autre.

dpkg conserve des renseignements utiles sur les paquets disponibles. Cette information est divisée en trois classes : les états, les états de la sélection et les drapeaux. La modification de ces valeurs est principalement dévolue à dselect.

États des paquets

Drapeaux des paquets

Actions

Le cœur du fonctionnement de dpkg est le paramètre <action>. Le tableau suivant résume les principales actions de base dont vous êtes succeptibles d'avoir besoin.

Options

Toutes les options peuvent être soit précisées à la ligne de commande ou dans le fichier de configuration de dpkg /etc/dpkg/dpkg.cfg. Chaque ligne du fichier de configuration est soit une option (la même que le paramètre de la ligne de commande mais sans les "-"), soit un commentaire (commençant par "#").

Fichiers

dpkg utilise un certain nombre de fichiers pour son fonctionnement, en commençant par son fichier de configuration /etc/dpkg/dpkg.cfg.

La liste des paquets avec leurs statuts est tenue dans les fichiers /var/lib/dpkg/available et /var/lib/dpkg/status.

Un fichier .deb, en plus des fichiers qui forment le paquet (programmes, bibliothèques, fichiers de configuration), inclue également un certain nombre de fichiers de contrôle. Ces fichiers permettent l'exécution de scripts avant et après l'installation ou la suppression du paquet, ainsi que les listes des fichiers et des fichiers de configuration. Une fois le paquet installé, ces fichiers sont placés dans /var/lib/dpkg/info.

Utilisation de dpkg

Pour installer un paquet à partir d'un fichier .deb, vous pouvez utiliser dpkg comme suit :

dpkg –i hello_2.1.1-4_i386.deb 

OU

dpkg --unpack  hello_2.1.1-4_i386.deb
dpkg --configure hello

Pour supprimer le paquet hello ainsi que sa configuration :

dpkg –P hello

Tandis que la commande suivante supprime le paquet en laissant les fichiers de configuration :

dpkg –r hello

Pour obtenir la liste des paquets installés sur le systéme :

dpkg –l

Lorsque vous travaillez avec un fichier .deb, vous devez donner le nom du fichier, mais lorsque vous travaillez sur des paquets installés, vous ne donnez que le nom du paquet.

APT

La commande dpkg est adaptée pour l'installation de paquets individuels sans dépendances, mais lorsqu'il s'agit d'installer un certain nombre de paquets qui risquent d'avoir des dépendances, on préfère la suite de commandes APT.

APT est l'une des forces de dpkg. C'est un moyen simple pour installer et mettre à jour un système. APT utilise deux fichiers de configuration principaux :

En général, on commence par configurer les sources d'APT, ce qui peut être fait avec :

apt-setup

Cette commande demande à l'utilisateur le mirroir à utiliser, et le teste, ou si vous utilisez des cdroms, la commande suivante :

apt-cdrom

Une fois qu'APT sait où il trouve ses paquets, on utilise deux commandes pour la gestion des paquets : apt-cache et apt-get.

apt-cache

apt-cache est utilisé pour accéder aux informations du cache APT (placées dans /var/cache/apt).

Syntaxe :

apt-cache <action> chaîne

Le tableau suivant présente les actions courantes :

apt-get

Tandis qu'apt-cache permet d'accéder aux informations sur les paquets disponibles, apt-get permet de mettre à jour ces informations, la récupération, l'installation et la suppression des paquets, et même de mettre à jour la distribution. Tout comme apt-cache, il faut indiquer à apt-get une action. Le tableau suivant décrit les actions les plus courantes pour apt-get :

Utilisation d'APT

L'une des utilisations d'APT les plus courantes est la mise à jour système (par exemple pour installer les mises à jour de sécurité). On le fait généralement avec ces deux commandes :

apt-get update
apt-get upgrade

Une autre utilisation d'APT est l'installation de paquets, pour laquelle on utilise les commandes suivantes :

apt-get update            #met à jour la liste des paquets

apt-cache search frob      #recherche les paquets relatifs à frob

apt-cache show frobnicate  #affiche les informations sur un paquet en particulier

apt-get install frobnicate #installe le paquet frobnicate  et ses dépendances

La commande alien

La commande alien convertit les paquets Debian en paquets RedHat et vice-versa. Vous pouvez télécharge alien sur http://kitenet.net/programs/ (NdT : aujourd'hui alien est distribué comme paquet sur Debian et autres)

Convertir un paquet Debian en rpm :

alien --to-rpm  paquet.deb

Convertir un rpm en deb :

alien --to-deb paquet.rpm

(NdT) : tâchez de vous rappeler qu'il faut utiliser alien en tant que root pour qu'il traite correctement les propriétaires et groupes des fichiers.

Résumé et exercices

Questions de révision

Oui ou Non

1. Lorsqu'on compile un programme à partir des sources, on doit compiler chaque partie du code dans l'ordre avec gcc : _

2. Le programme make ne peut compiler un programme que s'il est lancé dans un répertoire contenant la Makefile approprié : _

3. Les paquets contenant des binaires et ceux contenant des sources sont deux types de paquets RPM : _

4. Il est recommandé de lancer ldconfig lorsqu'on installe des bibliothèques partagées à partir des source : _

5. La commande ldconfig est utilisée pour mettre à jour le ldcache : _

6. On peut effectuer des recherches en utilisant un gestionnaire de paquets sur les programmes installés à partir des sources : _

7. Les outils APT permettent d'installer des paquets et des résoudre les dépendances : _

Voir les réponses

Glossaire

Fichiers

Commandes

Travaux pratiques

Dans l'exemple suivant, téléchargez un paquet RPM source (bash-2.05-8.src.rpm pour RedHat 7.2) à partir de www.rpmfind.net. (NdT : mettez à jour en fonction de la distribution RPM que vous utilisez)

1. Installation à partir de l'archive tar
   • Installez le contenu du paquet RPM sans compiler quoi que ce soit :

     rpm –ivh bash-2.05-8.src.rpm

   • dans le répertoire /usr/src/redhat/SOURCES, décompressez l'archive avec :

     tar xvzf bash-2.05-8.tar.gz   

   • Facultatif (mais recommandé) : appliquez les correctifs (patchs). La syntaxe dépend du répertoire où vous vous trouvez.

     de /usr/src/redhat/SOURCES :

     patch –p0 –b < fichier.patch

     de /usr/src/redhat/SOURCES/bash-2.05-8

     patch –p1 –b < fichier.patch

   • nous faisons le choix d'installer les fichiers dans un répertoire temporaire, par exemple /tmp/test. Dans un environnement de production, nous placerions les fichiers dans /usr/local. Créons le répertoire :

     mkdir /tmp/test 

   • Enfin, compilons en suivant les étapes habituelles :

     ./configure –prefix=/tmp/test
     make
     make install

     Vous pouvez lister le contenu de /tmp/test/

2. Pour aller plus loin, nous allons reconstruire un paquet RPM binaire (non nécessaire pour l'examen LPI101)

   • rpm –-rebuild  paquet.src.rpm

     Le paquet créé devrait être dans /usr/src/redhat/RPMS

     • Vérifiez le contenu du paquet avec les options -qpl

     • installer le ou les paquets et lancez des requêtes sur le(s) paquet(s) installé(s)
     • désinstaller le(s) paquet(s)

3. Configurez /etc/apt/sources avec apt-setup. Utilisez les commandes APT et dpkg pour lancer des requêtes, installer et mettre à jour les paquets disponibles.

Réponses aux questions

1. non : on utilise make

2. oui : le Makefile est unique pour chaque projet. la commande make ne peut lire le Makefile qu'à partir du répertoire actuel, c'est à dire le répertoire à partir duquel la commande est lancée.

3. oui

4. oui

5. oui

6. non

7. oui

Page consultée 570 fois