Forums d'entraide informatique - Astuces - Conseils

Avant toute chose, précisons le sujet de ce numéro ou, plus exactement, ce qui n'en fera pas partie. Il ne s'agit pas d'une collection d'articles d'introduction GNU/Linux. Vous ne trouverez donc pas dans les pages qui suivent de guide d'installation ou de cours d'utilisation d'un système GNU/Linux. Ce hors-série s'adresse à des utilisateurs UNIX et GNU/Linux souhaitant en savoir plus sur le projet Debian et l'administration d'un système Debian GNU/Linux. Les utilisateurs déjà accoutumés aux systèmes issus du projet Debian ne devraient pas être en reste, puisque nous tenterons de couvrir un large panel de sujets, allant de l'utilisation du système de gestion de paquet à l'administration système en passant par les procédures d'installation alternatives.
Debian GNU/Linux est un système largement utilisé en production, mais également pour des systèmes desktop personnels. Ainsi, qu'il s'agisse d'un serveur dédié loué, d'une machine personnelle, d'un poste de travail ou d'une machine de développement, ce sont toujours les mêmes outils spécifiques qui sont utilisés et les mêmes règles qui s'appliquent.
Comment parler de Debian sans au moins citer ses dérivés dont le plus connu est, sans doute, la distribution Ubuntu ? Bien que les distributions soient différentes sur bien des points, une large masse de fonctionnalités et de spécifications sont identiques. Si vous êtes utilisateur d'une distribution Ubuntu, vous devrez trouver dans les pages qui vont suivre de quoi vous occuper sur votre système.
(D UN PEU D'HISTOIRE
Le nom Debian est la fusion des prénoms des créateurs du projet : lan & Debra Murdock (mari et femme). Les toutes premières versions de Debian GNU/Linux furent diffusées en 1993. De 1994 à 1995, le projet fut soutenu directement par la FSF comme partie intégrante du projet GNU. Le projet a rapidement gagné en popularité et, en novembre 1995, il y avait déjà plus de 60 développeurs pour maintenir les paquets qui composaient alors la distribution.
Dès le départ, l'accent fut mis sur la nécessité de disposer d'un outil d'installation et de désinstallation des composants du système. dsel ect (ou l'horrible dsel ect, pour certains) fit son apparition cette année-là et marqua le début officiel de la mise en oeuvre d'un système de gestion de paquets
à ce jour inégalé (c'est un avis tout personnel), dans le monde des distributions GNU/Linux.
lan Murdock arrêta de travailler activement sur le projet en mars 1996, un peu avant l'arrivée de la version 1.0. Cette version fut d'ailleurs renommée 1.1, suite à une erreur commise par un producteur de CD-Rom qui avait libellé 1.0 une version non stable.
La version 2.0 marqua le départ d'un autre point caractéristique du projet : le fait de produire une seule distribution avec un seul numéro de version pour une masse importante d'architectures différentes. Ceci peut sembler anodin, mais il faut bien comprendre que c'est tout le système de développement et de maintenance des paquets qui supporte, encore aujourd'hui, toutes les architectures. Un seul paquet source permet de produire les paquets binaires pour n'importe quelle architecture supportée. La version 2.0 de Debian (Hamm) sortit en juillet 1998 pour les architectures de processeurs Intel i386 et Motorola 68000. Cette version stable contenait plus de 1500 paquets maintenus par plus de 400 développeurs. La version 2.1 (Slink) ajouta le support officiel pour l'Alpha et le Sparc. Cette version intègre égalementAPT (Advanced Packaging Tool), la nouvelle génération de l'interface de gestion de paquets.
La Debian 2.2 (Potato) est sortie le 15 août 2000, et, elle aussi, ajouta le support pour deux nouvelles architectures PowerPC etARM. La version 3.0 (Woody) ajouta1A-64, HP PA-RISC, MIPS et S/390. A ce moment, le projet compte 900 développeurs et 8 000 paquets.
La version 3.1 (Sarge) est l'actuelle distribution stable (au moment ou ce texte est rédigé) et la prochain mouture, 4.0 (Etch) est prévue pour le mois de décembre 2006. Peut-être l'annonce de sa disponibilité en tant que nouvelle version stable aura-t-elle été faite au moment où vous lirez ceci.
Au fil des versions et révisions, c'est non seulement le nombre d'architectures qui augmente (officiellement ou non officiellement supportées), mais également la stabilité et la maturité du système de gestion des paquets. Debian GNU/Linux est développé à la fois dans le but de fournir une distribution pour particuliers et pour professionnels. Les besoins en termes de stabilité et d'intégrité de la distribution sont, en effet, identiques.

LA GESTION DE PAQUETS
Le projet Debian fut sans doute le premier à proposer une distribution capable de se mettre à jour intégralement jour après jour, mois après mois et même année après année. Les machines initialement installées avec une version 2.0 et régulièrement mises à jour sont légion. Le fait de pouvoir changer de matériel sans réinstallation (propre aux systèmes d'exploitation de bonne facture) couplé à un excellent système de gestion des paquets et des mises à jour permet cet état de fait. Réinstaller une distribution Debian ne doit pas arriver. Exactement de la même manière que le redémarrage d'un serveur ou d'un poste GNU/Linux n'est conditionné que par deux choses : un problème ou une mise à jour matériels ou un changement de noyau.
Le principal problème à résoudre dans une gestion de paquets se résume en un seul terme : dépendances. En effet, une application nécessite souvent, pour fonctionner, la présence de bibliothèques dans le système. La tâche du système de gestion de paquets est de proposer l'installation des paquets nécessaires au fonctionnement de l'application (ou directement résoudre les problèmes). Le paquet gimp, par exemple, contient l'application de retouche d'image The Gimp. Celle-ci nécessite la présence, entre autres, du paquet 1 i bgtk2 .0 - common, lui-même nécessitant la présence du paquet 1 i bgtk2.0-0, etc. La tâche de la gestion de paquets est de déterminer les dépendances, mais également les dépendances inverses. Si on désinstalle 1 i bgtk2 .0-0, cela doit provoquer un avertissement suivi de la désinstallation de li bgtk2.0-common et donc de gimp, car l'application ne peut fonctionner dans le cas contraire. Debian GNU/Linux est réputé pour la qualité de cette gestion. Il est très difficile de se retrouver avec un système « bancal » ou « cassé ».
La gestion des paquets d'une distribution Debian GNU/ Linux repose sur le programme dpkg. Celui-ci est appelé par des outils APT ou des interfaces comme Aptitude (mode console) ou Synaptic (GUI). Si vous êtes utilisateur d'une distribution RedHat, ex-Fedora ou Mandriva par exemple, considérez que dpkg correspond à RPM.
Le format des paquets, le .deb est une archive a r standard contenant trois fichiers
•    control .tar.gz qui contient les méta-informations du paquet (sommes de contrôle, description du paquet, liste des dépendances, scripts d'installation/ désinstallation, etc.).
•    data . tar . gz qui contient les données de l'application ou de la bibliothèque à installer. Il s'agit d'une archive TAR compressée avec gzi p contenant, tout simplement, l'arborescence complète et les fichiers du paquet tels qu'ils seront copiés sur le système.
•    debi an-binarj qui est un simple fichier texte contenant le numéro de version du format. Actuellement, nous en sommes à la version 2.0 du format de paquet.
LES VERSIONS ET RÉVISIONS
Voici un point de confusion courant pour les utilisateurs débutants avec une distribution Debian. Le système de développement et de stabilisation d'une distribution se résume (grossièrement) au chemin suivi par un paquet dans le flux de stabilisation.
Trois « branches » (plus exactement des distributions, voir plus bas) majeures existent
•    Stable : là se trouvent les paquets maintenus pour l'actuelle distribution officielle.Au moment où ce texte est rédigé, l'actuelle distribution stable est la version 3.1, nom de code Sarge (voir tableau sur les versions et les noms de code).
•    Testing :comprend les paquets non encore stabilisés et en cours de tests. Ils ne sont pas considérés comme utilisables sur un serveur en production ou une machine en laquelle on peut faire à 100% confiance. Gardez à l'esprit la définition d'un paquet dansTesting :« contient les paquets qui n'ont pas encore été acceptés dans la distribution stable, mais qui sont en attente de l'être ». Voilà pourquoi un certain nombre d'utilisateurs préfèrent la distribution Testing, les paquets sont presque stables, mais plus récents.
•    Unstable :contient les paquets en développement. Le nom parle de lui-même (instable) et ces paquets sont à considérer comme absolument inappropriés pour une utilisation sûre du système. Il existe également une branche Experimental qu'on peut légitimement considérer comme la version « bricolo » d'un paquet. Utiliser une version d'Unstable n'est pas sûr, utiliser une version provenant d'Experimental est complètement stupide, sauf si vous êtes développeur Debian ou participez de près ou de loin au projet.
Les trois branches sont également les distributions (c'est là qu'on risque de perdre le fil) et donc des dépôts pour les paquets. Stable est la distribution officielle. Testing est la prochaine distribution en cours de finalisation. Testing devient Stable au moment où le processus de développement est terminé et qu'une distribution est officiellement produite.
If NOTE
Un paquet est ici défini comme le nom du paquet + sa version. Un paquet vim peut être présent dans Stable, Testing et Unstable, mais vim:6.3-07 I+ I sargel est le paquet dans Stable, vim:7.0- I 22+ I le paquet dansTesting et vim:7.0- 164+ I le paquet dans Unstable. Ce ne sont pas les mêmes paquets.

LE PROJET ET LES DISTRIBUTIONS DEBIAN
INTRODUCTION
Le changement deTesting en Stable est transparent pour l'utilisateur d'une version Stable.Actuellement, Sarge est Stable, lorsque Etch (actuel Testing) deviendra Stable, la seule chose que vous verrez, c'est un gros lot de mises à jour-Notre distribution se transformera de Sarge en Etch, mais vous serez toujours utilisateur de Debian GNU/Linux en version Stable.
Le processus Debian pour que la distribution Testing devienne Stable est la suivante :
•    Lorsque Testing devient suffisamment mature, le gel de la distribution commence. Il n'est pas possible d'arbitrairement dire « Stop, maintenantTesting devient Stable »,car des paquets fonctionnels d'Unstable migrent en permanence vers Testing au fur et à mesure de leur stabilisation. Le début du gel deTesting commence par un allongement des délais de propagation (de sauts) d'Unstable vers Testing. Les paquets en provenance d'Unstable contiennent toujours des bogues. En allongeant le délai, on s'assure de limiter l'arrivée de nouveaux bogues dans Testing.
•    On gèle Testing complètement. A ce moment, les paquets qui devaient encore arriver dans Testing sont bloqués (on ferme les vannes à bogues). Toute l'énergie des développeurs est alors concentrée sur la stabilisation de Testing et la correction des bogues. Une seule exception permet à un paquet d'Unstable d'arriver dansTesting à ce moment :le fait qu'il corrige un bogue critique pouvant empêcher la création d'une nouvelle distribution.Actuellement, le paquet medi awi ki 1.7 par exemple, empêche la sortie d'Etch en tant que Stable. Il provoque une erreur de segmentation avec php 5 .2.0-5. Dans ce cas précis, si la version du paquet actuellement dans Unstable corrige le problème, elle pourra passer dans Testing, même après le début du gel de la distribution. Une autre solution peut être de simplement éliminer medi awi ki 1. 7 de la distribution. Il faut savoir sacrifier (rétrograder) un paquet pour permettre la sortie d'une distribution.
•    Une fois que le nombre de bogues non corrigés passe en deçà d'un certain niveau, Testing est prête pour publication. Une nouvelle distribution Debian GNU/Linux est officiellement annoncée et Testing devient Stable. La distribution se voit alors attribuée son numéro de version. L'ancienne distribution Stable devient obsolète,elle est retirée des dépôts et archivée. Les utilisateurs voient alors une grosse mise à jour de leur système arriver. Parallèlement, des images de CD-Rom et de DVD sont créées en guise de version stable de la distribution pour les nouveaux utilisateurs ou les nouvelles installations.
Stable est également mise à jour régulièrement, mais il ne s'agit que de corrections de bogues. Lorsque Testing devient Stable, la distribution n'est pas totalement exempte de bogues et même une fois la distribution
publiée officiellement, de nouveaux bogues peuvent être signalés.A intervalles plus ou moins réguliers, une mise à jour mineure est publiée sous la forme d'images de CD ou DVD. L'actuelle version Stable est la 3.Ir4. Nous en sommes donc à la 5ème série d'images officielles des versions d'installation de la distribution. Ceci permet aux nouvelles installations d'être directement à jour et ne pas voir l'utilisateur obligé de récupérer (via le Net) une quantité trop importante de paquets mis à jour post-installation.
En parallèle à la stabilisation de la distribution, le développement et l'amélioration de l'installeur suit son cours. Pour qu'une nouvelle distribution soit publiée, il faut donc également que l'installeur soit stabilisé. L'installeur assure la procédure de création d'un système Debian GNU/Linux sur les disques d'une machine. Il fournit également une interface conviviale à l'utilisateur afin de faciliter l'installation. Il doit suivre l'évolution des technologies et les fonctionnalités offertes par les systèmes GNU/Linux récents (LVM, RAID logiciel, etc.).Tout comme la distribution elle-même, l'installeur doit pouvoir gérer toutes les architectures officiellement supportées par le projet. On notera au passage qu'il n'y a pas si longtemps une décision importante a été prise : celle de réduite le nombre d'architectures supportées officiellement aux architectures récentes et encore « vivantes ».
Le support d'un trop grand nombre d'architectures est un réel problème. Un paquet peut parfaitement fonctionner sur x86, mais pas sur-Alpha et donc bloquer la stabilisation de Testing. Le délai entre la version 3.0 (juillet 2002) et 3.1 (juin 2005) a provoqué bien des « râlements ». La stabilisation après le gel complet de la future 3.1 était bien trop longue et la version stable, 3.0, était presque devenue obsolète.Voilà pourquoi des décisions radicales ont dû être prises (même si une partie des développeurs Debian, les DD, a estimé que le problème provenait plus d'un manque de réactivité que du nombre trop important d'architectures supportées).
CONTRAT SOCIAL DEBIAN
Le projet Debian se distingue non seulement par divers choix techniques, mais également par des principes qu'on pourrait qualifier de philosophiques. Ces principes ont été détaillés de longue date (1997) dans un document appelé « contrat social Debian » et mis à jour en avril 2004. On peut voir ce contrat comme le « contrat de confiance » d'un certain détaillant de matériels électroménagers.Comme le précise le contrat social lui-même, il s'agit d'un ensemble de principes auxquels le projet tient fermement.
Le contrat se compose de cinq points : I
. Debian demeurera totalement libre. C'est la base du contrat. Les distributions Debian sont composées d'éléments libres selon les « Principes du Logiciel libre selon Debian » (voir plus loin). Point important, il est clairement spécifié :« Nous ne rendrons pas le système

dépendant d'un composant non libre. », ce qui ne va pas sans créer un certain nombre de problèmes, dont ceux posés par les pilotes de périphériques intégrant des éléments propriétaires ou non libres selon les principes du Logiciel libre selon Debian.
2. Nous donnerons nos travaux à la communauté des Logiciels libres. C'est une conséquence directe des principes du Logiciel libre. Les travaux en question sont l'ensemble des développements nécessaires pour construire et maintenir les distributions. Ceci inclut les utilitaires et applications de gestion de paquets, mais également les éléments satellites et l'information elle- même (corrections de bogues, améliorations, requêtes des utilisateurs, etc.).
3. Nous ne dissimulerons pas les problèmes. C'est le principe de « Full disclosure » qui s'oppose à la sécurité par obscurantisme (qui n'est pas vraiment possible avec le Logiciel libre). Ceci signifie la conservation de l'intégralité de la base de données concernant la gestion des bogues et sa mise à disposition publique. C'est la transparence qui garantit la qualité, aussi bien en termes de sécurité que de qualité de code.
4. Nos priorités sont nos utilisateurs et les Logiciels libres. Encore un principe important qui guide le développement et l'évolution des distributions. Ceux-ci sont dirigés par les besoins des utilisateurs (au sens large du terme). Ceci inclut le fait que Debian ne s'oppose ni aux travaux dérivés du projet, ni aux travaux non libres prévus pour fonctionner avec les systèmes Debian.Cette clause affirme donc le non-totalitarisme de Debian, puisqu'il n'y a clairement pas de restriction imposée (autre que celles des licences des Logiciels libres) concernant la réutilisation de tous les travaux du projet.
•    le téléchargement d'un firmware propriétaire dans le
périphérique nécessitant son fonctionnement ;
•    la mise en oeuvre de wrappers permettant d'utiliser un pilote propriétaire Windows avec Linux
•    les licences incomplètes, restrictives ou non libres utilisées par les constructeurs sur les sources de leurs pilotes.
Le problème se pose déjà au niveau du développement du noyau Linux et une certaine tolérance existe. Malheureusement, il faudra clarifier les choses de manière définitive à un moment ou un autre. Il en va de même pour le projet Debian, qui devra prendre position et donc faire une mise à jour du contrat social en prenant compte des nouvelles réalités. Pour l'heure, rien n'est vraiment tranché.
ÇcJ LES PRINCIPES DU LOGICIEL LIBRE SELON DEBIAN
Pourquoi les documentations sous licence GNU FDL ne sont-elles pas systématiquement libres selon Debian ? La réponse se trouve dans la vision du Logiciel libre selon Debian. Cette vision est à la fois plus large, mais aussi plus précise que les simples quatre types de libertés qui caractérisent habituellement un Logiciel libre. Les principes du Logiciel libre selon Debian (DFSG : Debian Free Software Guidelines) sont les suivants
•    Redistribution libre et gratuite. C'est un composant de base qu'on retrouve dans les licences comme la GNU GPL.
5. Travaux non conformes à nos standards sur les Logiciels libres. Cette dernière clause ou principe permet de prendre en compte la réalité de la vie. En s'en tenant uniquement aux quatre principes précédents et en ignorant le fait que des applications propriétaires (ou semi-propriétaires) existent et qu'un certain nombre d'utilisateurs en ont besoin, le projet Debian ne serait pas viable. Les distributions Debian rendent possible la prise en charge de ces applications par le système de paquet et leur intégration via deux sections spécifiques nommées contri b et non-free. Les paquets présents dans ces sections ne font pas partie du système Debian, mais sont configurés de manière à pouvoir être utilisés dans une distribution du projet.
Le contrat social Debian a aujourd'hui le même problème que bien des contrats : il ne pouvait pas, au moment de sa création, tenir compte de cas précis qui n'existaient pas encore ou qui ne pouvaient être envisagés. Qui aurait pu penser, il y a quelques année, que la prise en charge de périphériques sous Linux via des morceaux de code binaires et propriétaires aurait tendance à se généraliser ? Plusieurs cas se distinguent
•    Code source. Encore une des quatre libertés de base.
*Applications dérivées : la licence doit autoriser les modifications et les applications dérivées, ainsi que leur distribution sous les mêmes termes que ceux de la licence du logiciel original. On retrouve également ce principe dans la GPI_ mais pas nécessairement dans d'autres licences.
•    Intégrité du code source de l'auteur. Debian prend en compte le fait que l'auteur ne souhaite pas que des modifications sur son oeuvre existent, mais uniquement s'il est tout de même possible de créer des travaux dérivés.Ainsi, ma licence peut interdire la distribution de versions dérivées de mon code source, mais pas la distribution de mon code avec des patchs. De la même manière, je peux exiger que les versions dérivées portent un autre nom ou un autre numéro de version que mon original. Mon travail reste du Logiciel libre selon Debian.