Linux - Compilation versus RPM

Stéphane RAULT -

Version 1.0 - Dernière mise à jour le 2 Février 2004

Version originale http://www.espace-groupware.com/linux/compilation-versus-rpm.html

Table des matières

Introduction :

Essayons de sortir de tous débats passionnés pour aborder ce sujet que je considère comme extrèmement important dans l'intégration de Linux au sein d'une architecture informatique.

J'ai écris cet article dans le but de vous aider à prendre une décision parmis les trois possibilités suivantes :

Il existe une quatrième possibilité mais cette dernière n'est pas vraiment un choix, c'est le cas où il n'existe pas de RPM pour l'application dont vous avez besoin.

Précision : Cette analyse de RPM, est surtout valable dans le cas de serveurs Linux Mandrake et Redhat, pour des machines exposées sur internet. Des reflections différentes peuvent être menées pour les stations de travail ou les serveurs internes.

Qu'est qu'un RPM ? :

Tous d'abord, il faut savoir que les RPM sont principalement utilisés sur des plateformes de type Redhat et Mandrake. Les systèmes de type BSD utilisent une technique similaire mais incompatible.

RPM = Redhat Package Manager. Cette application a été mise au point et est distribuée sous licence GPL par la société Redhat.

N'importe quelle éditeur a la possibilité d'implémenter RPM dans sa distribution.

La comparaison la plus simpliste que l'on peut faire des RPM est l'installShield sous Windows et l'ajout/suppression de programmes

Que vous apportes l'utilisation de RPM ? :

Qui construit les RPM ? :

Le plus souvent, les RPM sont construit par les éditeurs de distributions mais en principe n'importe qui peut construire des RPM et les mettres à dispositions sur Internet.

Comment assurer le suivi de la mise à jour des RPM ? :

Redhat, fournit un outil (up2date) associé à des services payants vous permettant de gérer par internet, la mise à jour des RPM sur vos machines. A condition bien sûr d'utiliser une distribution Redhat (bien que ce point reste à vérifier).

Mandrake, fournit un utilitaire très sympathique nommé URPMI. Ce outil vous permet de centraliser facilement toutes vos mise à jour sur un serveur de fichier, puis de demander à vos machines d'aller chercher ces dernières, pour les installer.

Vous pouvez également télécharger manuellement les packages chez les éditeurs de distributions, qui mettent à votre disposition des serveurs FTP en mirroir et une arborescence de répertoires dédiés aux mises à jour. Mises à jour Redhat - Mises à jour Mandrake

Le site RPM FIND fournit un moteur de recherche dédié aux RPM pour tous les éditeurs de distributions Linux. Il est très utile, car il fournit en plus des liens vers l'éditeur original de l'application et des liens vers les dépendances.

Dans la pratique, une fois que vous disposez du fichier RPM sur votre machine, il suffit de taper la commande suivante pour l'installer ou mettre à jour une installation existante.

# Syntaxe valable autant pour l'installation que la mise à jour - Ne pas utiliser pour le kernel :
[root@linux /]$ rpm -Uvh fichier.rpm

# Un conseil, simulez toujours l'installation ou la mise à jour d'un RPM avec :
[root@linux /]$ rpm -Uvh --test fichier.rpm

Inconvénients des RPM :

Je crois qu'il est possible de dire que RPM a l'inconvénient de ses avantages :

Remarque : Ces inconvénients peuvent ne pas être considérés comme tels si pour vous, la facilité d'exploitation est plus importante que la sécurité ou que ces machines ne sont pas exposées sur internet

Comment est construit un RPM ? :

Il y a deux choses importantes à savoir sur la méthode de construction d'un RPM :

Pour plus de détails sur cette question, je vous renvois à la version Française du HOWTO sur RPM

RPM Sources, une alternative ? :

Pour chaque RPM téléchargé, vous devriez pouvoir trouver et utiliser, le fichier RPM Source correspondant.

La recompilation du package source pourrait être une solution pour l'ajout d'options qui n'ont pas été activés dans votre package d'origine.

Mais attention, l'apprentissage et l'industrialisation de la compilation et l'utilisation des RPM sources est beaucoup plus difficile de la compilation des sources standards et de plus vous ne pourrez pas capitaliser ce savoir sur d'autres plateformes et dans d'autres situations où il n'existe pas de RPM.

Exemple de compilation d'un serveur Bind :

Pour commencer à comparer, le travail que représente la compilation des sources par rapport à l'utilisation des RPM, je vous proposes un exemple avec le serveur DNS Bind 9.2.3 :

# Pré-requis : OpenSSL doit déja être installé sur le système

# Un compte applicatif optionnel peut être créé pour faire tourner Bind sous privilèges non-root
[root@linux /]$ groupadd -g 25 named
[root@linux /]$ useradd -u 25 -g 25 -s /bin/false -M -r -d /var/named named

# Téléchargement et décompression de Bind 9.2.3
[root@linux /]$ cd /usr/local/src
[root@linux /]$ wget ftp://ftp.isc.org/isc/bind9/9.2.3/bind-9.2.3.tar.gz
[root@linux /]$ tar -xzvf bind-9.2.3.tar.gz
[root@linux /]$ cd bind-9.2.3

# Compilation basique avec les paramètres par défaut en fournissant un répertoire d'installation :
[root@linux /]$ ./configure --prefix=/usr/local/bind
[root@linux /]$ make
[root@linux /]$ make depend
[root@linux /]$ make install

# Ce qu'il reste à faire après la compilation et qui est déja prêt dans une version RPM :
- Création de répertoires et changement de droits
- Mise en place du fichier de démarrage (services)
- Création du fichier de configuration principal (named.conf)
- Création des fichiers de zones

Au premier abord, la compilation semble beaucoup plus compliquée que l'installation d'un RPM !.

En vérité, il ne faut pas oublier que cette procédure ne varient quasiment pas d'une compilation à l'autre pour le même produit dans des versions différentes.

Donc il est tout à fait possible et même conseillé, d'en automatiser une bonne partie dans un fichier de script. Pour construire ce fichier, il suffirait de copier/coller le code précédent et d'ajouter quelques variables.

Dans le cas, d'une mise à jour, seuls quelques commandes sont nécessaires car le compte applicatif, les répertoires d'installations, les fichiers de configuration et le script de lancement sont déja créés. Il se peut que vous deviez modifier vos fichiers de configuration, mais c'est également le cas avec les RPM, quand une nouvelle version fournie des paramètres supplémentaire ou rend obsolète leur utilisation.

Délai de disponibilité entre la sortie des sources et du RPM correspondant :

Il faut différencier les différents types de mise à jour d'une application :


Pour ce qui concerne, les versions majeures, les nouvelles fonctionnalités qu'elles apportent ne vous ont pas empêcher de vivre jusque là, donc inutile de s'affoler.


Par contre, les correctifs, sont le plus souvent développés, à la suite de la découvertes d'une faille de sécurité ou d'un dysfonctionnement de l'application.

La démarche doit rester la même, qu'il s'agissent de RPM ou de sources compilées, le mieux est de suivre les règles suivantes :


Je vous proposes de détailler dans la suite de ce document, les conséquences de l'utilisation des RPM dans le cas d'une application critique, accessible depuis internet comme le serveur DNS Bind.

Version en cours de Bind sur Redhat 9

Version en cours des sources disponibles chez l'éditeur de Bind

La 9.2.3 est une version de maintenance qui inclue les correctifs des versions 9.2.0, 9.2.1 ainsi que des nouvelles fonctionnalités.

Correctifs de la 9.2.3 (par rapport à la 9.2.1)

Conséquence principale du délai de disponibilité de la nouvelle version au format RPM

Les serveurs DNS en production sur Redhat 9 présentent des failles de sécurités et des dysfonctionnements depuis le mois de Janvier 2003.

Evaluation des risques

Ces failles sont dangereuses principalement, pour les serveurs DNS Bind accessibles depuis internet.

Vous pensez peut t'être qu'il faudrait jouer de malchance pour qu'un pirate s'interresse spécifiquement à votre serveur DNS ?.

Le piratage, pourquoi m'en soucier ?

Petit rappel sur les firewall

Attention, les firewall ne vous protègent pas des failles applicatives. Seuls la mise à jour des produits et éventuellement l'utilisation d'un detecteur d'intrusion peuvent remplir ce rôle. Notez que certains firewall fournissent une protection dans les couches applicatives, mais il s'agit en général de produits auquels l'on a associé un IDS.

Industrialisation du piratage

Le pirate se doit d'automatiser le plus possible les processus lui permettant de découvrir des serveurs défaillants. Pour cela il peut procéder dans l'ordre suivant :

Il ne lui reste plus qu'à attendre la découverte d'une faille de sécurité et à se connecter à votre serveur DNS pour en profiter dans les meilleures délais.

Autres conséquences dans l'utilisation des RPM

Conclusions

Comme souvent dans l'informatique, il faut éviter de se trouver à l'opposé des différentes solutions qui s'ouvrent à vous.

Il est tout à fait possible et maintenable, de mixer dans le même environnement, des applications compilés avec d'autres installées en version RPM.

Ci-dessous, une liste des applications pour lesquelles, je préconise en particulier, l'utilisation de sources compilés :

Une petite remarque importante : Certaines applications qui resteront installées sous la forme de RPM, ont besoin de trouver sur votre système, les packages que vous aurez peut être décidé de désinstaller pour mettre en place des versions compilées.

Normalement, vous devriez être obligé de compilés également tous les produits dépendants, ce qui dans le cas d'OpenSSL, vous conduirait à recompiler la moitié des applications de votre distribution.

Pour éviter, ce genre de désastre, je vous proposes de travailler avec 2 versions; celle installée sous la forme de RPM et celle que vous avez compilé.