Meilleures pratiques lors de l'installation de logiciels

Introduction

L'installation de logiciels fait partie des tâches d'administration système courantes. Elle est fondamentale pour maintenir son système dans un état qui permette, à terme, les mises à jour, la performance, la qualité et la maintenance à long terme.

Malheureusement, souvent les méthodes les plus simples d'installation logicielle sont celles qui créent le plus de problèmes. De plus, des décisions prises en amont de l'installation d'un logiciel sont souvent la cause du problème (la racine du mal).

Ce document a pour but de donner quelques bonnes pratiques dans le domaine, sans prétendre à l'exhaustivité ou l'adéquation dans tous les cas

Installer un nouveau logiciel.

Première étape: évaluation de la nécessité

Le logiciel à installer est-il réellement nécessaire ?

• n'existe-t-il pas un logiciel similaire ou équivalent dans les logiciels déjà installés, ou les logiciels potentiellement installables directement de la distribution (évt. aussi des backports)

• le langage dans lequel le logiciel est écrit est-il justifiable ?
  • motivation: installer tout l'environnement propriétaire binaire Java ou dotnet pour juste un petit programme particulier se justifie-t-il ?
  • avoir du Perl, du PHP, du Ruby et du Python pour des scripts Web n'est-il pas un peu trop se diversifier ? ne pourrait-on pas se standardiser sur un seul langage ?

• les dépendances du logiciel sont-elles soutenables ? (une étude récursive est nécessaire ici pour chaque logiciel dépendant)

Dans cette étape, ne pas hésiter à évaluer toutes les autres solutions possibles (réimplémentation dans d'autres langages, se passer du composant logiciel en compilant conditionnellement un logiciel qui en dépend, etc)

Deuxième étape: évaluation de l'impact

Quel impact aura le logiciel une fois installé, notamment:

• peut-il être installé dans un répertoire totalement indépendant du système (~/bin, /usr/local/APPLICATION/bin, /usr/local/bin) ?
  • nécessite-t-il de modifier le système (init-scripts, configurations, ou pire le système directement)
  • nécessite-t-il des préconfigurations de bibliothèques, également confinables via un "wrapper" script ?

• qui se chargera de sa mise à jour (sécurité, maintenance, migration, compatibilité) ?

• le projet est-il viable (communauté autour du logiciel, qualité du code, principe KISS, modularité, isolation, ...) ?

Dans cette étape, des solutions de virtualisations simples (--prefix, chroot, openvz) ou complexes (virtualbox, kvm, xen, vmware) sont évaluables pour confiner le logiciel pour des raisons de maintenance, sécurité ou fiabilité.

Il faut aussi évaluer, si des modification au système doivent être effectuées, si celles-ci peuvent être faites via dpkg-divert ou des liens symboliques. Dans tous les cas une documentation extensive devrait être maintenue.

Troisième étape: génération du logiciel

Si le logiciel est à compiler:

• de préférence effectuer la compilation dans un répertoire utilisateur (pas sous root), p.ex. dans ~user/PORTED/nom-du-programme-VERSION
• éventuellement modifier le --prefix du configure (p.ex /usr/local/APPLICATION)

Quatrième étape: installation du logiciel

En règle générale et pour la plupart des logiciels, le make install peut également être fait pas sous root. Il suffit de créer le répertoire de l'application sous root, de corriger le propriétaire, puis de lancer le make install sous l'utilisateur.

A cette étape, quelques choix techniques peuvent être faits:

• installer sous /usr/local/APPLICATION-VERSION, ajouter un lien symbolique vers /usr/local/APPLICATION de la version en production
• installer d'éventuels scripts wrapper dans /usr/local/bin (permet d'éviter de modifier le PATH et de préconfigurer le chargement de bibliothèques éventuelles)

Dernière étape: veille logicielle

S'abonner aux listes générales d'annonces de sécurité (debian-security, bug-traq) et celles concernant les annonces de sécurité et de maintenance (nouvelles versions) de tous les logiciels installés localement, de manière à assurer la sécurité et planifier les migrations.

Considérations finales

Il n'est pas toujours possible de suivre pas à pas ces meilleures pratiques. Notamment certains logiciels -- même totalement non système -- ont besoin de l'accès root par exemple pour configurer des droits d'accès, des bases de données ou autres durant l'installation. Dans ce cas il est recommandé de soit faire une installation de test dans une machine virtuelle, puis comparer les changements, d'utiliser fakeroot, ou de prier que le script d'installation ne fait pas de bricolages dangereux.

Comme exemple de programmes courants violant ces règles de base, notons les packages Java de Sun. Heureusement, ils sont packageables et installables via l'excellent make-jpkg de Debian, qui s'arrange pour intercepter des modifications incontrôlées du système.

Références

• cours CRIL LPI-101 pages 35 et suivantes.
• Cours ESNIG/Linux administration, pages 67 et suivantes

-- MarcSCHAEFER - 30 May 2010