Un réseau Debian GNU/Linux pour un centre de formation

Transcription

Un réseau Debian GNU/Linux
pour un centre de formation
Yves Potin
10 juin 2005
Résumé
Le logiciel libre, aujourd’hui au cœur de l’actualité de l’informatique, ne peut plus être ignoré des administrateurs
de réseau, en particulier dans des établissements d’enseignement ou de formation d’où sortiront les utilisateurs de
demain, du simple utilisateur à l’ingénieur système. Il incombe en effet aux responsables informatiques de mettre à
disposition des systèmes d’exploitation libres par respect du pluralisme de l’enseignement comme pour tenir compte
des évolutions à terme du monde de l’entreprise qu’ils peuvent ainsi anticiper et encourager.
Les documentations sur les divers services et systèmes sous GNU/Linux abondent, mais il manque peut être un
résumé de l’ensemble de la mise en place d’un réseau informatique libre dans le cadre d’une structure de formation.
Ce document résume l’installation d’un réseau Debian GNU/Linux complet, des serveurs aux machines clientes,
de l’achat du matériel aux derniers ajustements de l’interface graphique et des usages du multimédia. Il ne prétend
pas détailler tous les services réseau, mais servir de mémorandum et fournir des fichiers de configuration pour la
plupart d’entre eux. La majeure partie des services d’Internet est présentée sous l’angle d’un réseau local : DNS,
courriel, Web, ftp... Certains services sont présentés sous forme de didacticiels progressifs : Amanda, pour les sauvegardes sur bande, Nut, logiciel de surveillance des onduleurs, et l’utilisation avancée du chiffrage de l’authentification
par ssh.
Un script permet la réplication de contenus sur toutes les machines clientes en une seule ligne de commande,
simplifiant grandement les tâches d’installation et d’administration.
Si cette longue étude de cas est artificielle en ce qu’elle commence par les murs d’un local vide et l’argent pour
acheter le matériel, et s’achève par un réseau entier de machines homogènes, nous espérons néanmoins qu’elle sera
utile comme aide mémoire à ceux qui désirent offrir à leurs étudiants la pratique d’une informatique libérée du
carcan propriétaire qu’ils peuvent ainsi, chacun selon sa mesure, contribuer à faire reculer.
Cette documentation est placée sous Licence Documentaire libre (GNU/FDL)1
1 http
://www.gnu.org/copyleft/fdl.html
1
Table des matières
1 L’équipement matériel
1.1 Les serveurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Les machines clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Matériel complémentaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
4
4
5
2 L’installation des systèmes d’exploitation
2.1 Partitionnement des serveurs . . . . . . .
2.2 Partitionnement d’une station de travail .
2.3 Conseils généraux pour l’installation . . .
2.4 Les sources des packages Debian . . . . .
2.5 Logiciels complémentaires . . . . . . . . .
.
.
.
.
.
6
6
7
7
8
9
3 Une session de travail d’un administrateur réseau
3.1 Conseils généraux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Un interpréteur de commandes confortable : zsh, le Z Shell . . . . . . . . . . . . . . . . . . . . . . . .
9
9
10
4 Sécuriser une machine Debian : les bases
11
5 Configuration et sécurité du routeur
5.1 Sécurité sur le routeur : première étape .
5.2 Sécurité sur le routeur : seconde étape . .
5.3 Fonctionnalités additionnelles du script de
5.4 Simulation d’intrusions : Nessus . . . . . .
5.5 Logiciels complémentaires de sécurité . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . .
. . . . .
firewall
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Premier serveur : les services réseau non authentifiés
6.1 Le DNS : Bind . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Le DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Limiter les téléchargemets de logiciels : un miroir Debian ou
6.3.1 Un miroir Debian partiel sur le réseau . . . . . . . .
6.3.2 Apt-proxy, proxy de packages Debian pour apt . . .
6.4 Squid, Proxy http et ftp . . . . . . . . . . . . . . . . . . . .
6.4.1 Squid . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.2 SquidGuard . . . . . . . . . . . . . . . . . . . . . . .
6.4.3 En conclusion . . . . . . . . . . . . . . . . . . . . . .
6.5 Xntpd, serveur de temps . . . . . . . . . . . . . . . . . . . .
6.6 CUPS, serveur d’impression . . . . . . . . . . . . . . . . . .
7 Second serveur : l’authentification
7.1 Courrier : SMTP et Pop3 . . . . . . . . . . . . . . .
7.1.1 Postfix : installation et configuration simple .
7.1.2 Sécuriser Postfix . . . . . . . . . . . . . . . .
7.1.3 Un serveur de messagerie sur le réseau : envoi
7.2 NIS . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 NFS . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4 Samba . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5 Web et FTP . . . . . . . . . . . . . . . . . . . . . . .
7.5.1 Apache . . . . . . . . . . . . . . . . . . . . .
7.5.2 ProFTPd . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
un
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
13
13
13
14
. . . . . . . . . . .
. . . . . . . . . . .
proxy de packages
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
16
17
17
18
19
19
21
22
22
22
.
.
.
.
.
. . . . . . .
. . . . . . .
. . . . . . .
et réception
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
8 Services réseau complémentaires
8.1 Nut : gestion des onduleurs . . . . . . . . . . . . . . . . . . . .
8.1.1 Configuration de nut en mode maître . . . . . . . . . .
8.1.2 Démarrage du service et test de son bon fonctionnement
8.1.3 Configuration d’un client sur le réseau . . . . . . . . . .
8.2 Amanda : sauvegarde en réseau sur bande . . . . . . . . . . . .
8.2.1 Configuration d’une sauvegarde : le serveur . . . . . . .
8.2.2 Configuration d’une sauvegarde : les clients . . . . . . .
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
24
25
27
27
28
29
30
30
30
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
30
31
32
33
34
34
37
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
39
40
41
42
9 L’installation de la première station de travail
9.1 Rappels sur l’installation d’une machine cliente . . . . . . . . .
9.1.1 Debian Sid . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.2 Paramétrage d’un environnement français . . . . . . . .
9.2 Un kernel linux pour machines multimédia . . . . . . . . . . . .
9.3 Intégration de la machine au réseau . . . . . . . . . . . . . . .
9.3.1 Clients NIS et NFS . . . . . . . . . . . . . . . . . . . . .
9.3.2 Clients LDAP . . . . . . . . . . . . . . . . . . . . . . . .
9.4 Installation d’un environnement graphique et de logiciels divers
9.5 Les droits sur les périphériques : carte son, webcam, etc... . . .
9.6 Le problème des logiciels et composants propriétaires . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
43
43
44
44
44
44
45
47
47
10 Installation automatisée de toutes les autres machines
10.1 Le principe de la réplication de fichiers . . . . . . . . . . . . . .
10.2 Ssh en mode agent . . . . . . . . . . . . . . . . . . . . . . . . .
10.3 Dupliquer la première machine : adapter le script de réplication
10.4 Extraire la liste des logiciels installés et la reproduire . . . . . .
. . . . . .
. . . . . .
- premiers
. . . . . .
. . .
. . .
tests
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
48
48
48
50
52
11 Jouer avec le réseau
11.1 Déporter l’affichage . . .
11.2 Déporter le son . . . . .
11.3 Wims . . . . . . . . . .
11.4 La diffusion vidéo : vlc .
11.5 Partager un scanner . .
11.6 Un cluster de calcul . .
11.7 Quelques jeux en réseau
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
52
53
53
53
53
54
55
8.3
8.4
8.5
8.2.3 La première sauvegarde et restauration . . . . . .
8.2.4 Paramétrage de la sauvegarde hebdomadaire . . .
Partimage : sauvegarde des machines . . . . . . . . . . . .
Webmin, administration simplifiée et création de comptes
Les statistiques d’usage du réseau et des serveurs . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12 Remerciements
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
56
3
1
1.1
L’équipement matériel
Les serveurs
Au moins deux ordinateurs serveurs vont faire fonctionner notre centre de formation :
Un petit ordinateur servant de pare-feu / routeur pour la gestion de la connexion ADSL de notre centre. Un
Pentium 75 muni de 16 ou mieux 32 Mo de mémoire vive et au moins 600 Mo de disque dur IDE suffit amplement
pour du matériel fiable, encore en bon état de fonctionnement. On lui adjoindra deux cartes réseau, de préférence PCI
et non ISA par souci de simplicité, et un onduleur.
Les « vrais » serveurs seront convenablement dimensionnés tant en mémoire qu’en capacité de disque SCSI. Si le
budget le permet, on choisira deux serveurs en configuration en RAID 5, au moins pour le serveur qui va héberger les
données. Les serveurs récents sont souvent munis d’un Gigaoctet de mémoire vive, et de disques de large capacité.
Un serveur hébergera les données de chacun et les services demandant authentification : NIS (ou LDAP), NFS,
Samba, serveur SMTP, serveur POP, ainsi qu’un serveur Web et un serveur FTP. Dans notre cas, deux disques de
70 Go, un pour les formateurs, un pour les données des stagiaires, suffisent amplement. L’autre serveur hébergera un
certain nombre de services réseau sans authentification : DHCP, DNS, Proxy (Web et apt), impression (via CUPS et
Samba), serveur de temps, sauvegardes (Amanda et partimage).
Pour les sauvegardes, on prévoira beaucoup d’espace disque pour les images des stations. Pour les données, on
adjoindra un lecteur DAT externe qui pourra servir ainsi à d’autres usages comme l’enregistrement numérique de
productions multimédia.
Ce matériel sera placé dans un local séparé des salles de formation, fermant à clef et normalement aéré. Tous les
éléments actifs (switchs, routeurs, modems mais aussi les écrans et le commutateur écran /clavier partagé entre les
serveurs) seront ondulés au moyen d’une prise en kit fournie. Il s’agit d’une prise à l’apparence peu habituelle livrée
avec chaque onduleur du marché. Pour l’utiliser, on coupera la prise mâle d’une multiprise ordinaire dont on reliera
les fils à la prise en kit ; on peut alors brancher cette multiprise sur l’onduleur. Ceci est essentiel dès lors que :
– Tout le matériel du local serveur doit être ondulé pour ne pas lui faire subir de violentes coupures de courant et
maintenir la disponibilité de fonctionnement.
– S’il y a coupure de courant, le switch qui relie plusieurs ordinateurs partageant le même onduleur doit continuer
à être alimenté, sinon le contrôle par réseau ne fonctionnera plus, occasionnant la chute des serveurs esclaves qui
auraient pu continuer à fonctionner pendant une coupure courte.
La configuration du logiciel de surveillance d’onduleur Nut est décrite dans la section 8.1. De nombreux tests
aboutiront à un fonctionnement normal en cas de coupure courte ; on obtiendra une chute et remontée normale des
serveurs en cas de coupure longue et rétablissement du courant. Fréquemment, il faudra déclarer dans le BIOS des
ordinateurs le comportement à adopter en cas de retour du secteur, qui n’est souvent pas par défaut le redémarrage
pourtant requis. On doit pouvoir l’âme tranquille débrancher l’alimentation générale du secteur et observer tout
l’équipement continuer à fonctionner normalement avec un message d’alerte dans les logs de chaque serveur (et sur les
consoles ouvertes) avertissant que l’onduleur est sur batterie.
Dans la mesure du possible, compte tenu de l’évolution du matériel dont seront équipés demain par défaut les
ordinateurs, on choisira des switchs embarquant au minimum un port au Gigabit. Les usages d’applications multimédia
modernes, en particulier en vidéo, rendront bientôt un tel débit non plus confortable, mais nécessaire.
Règles élémentaires de sécurité : tous les ordinateurs du centre de formation, à commencer par les serveurs, seront
verouillés par mot de passe dans le BIOS et il ne sera pas possible d’amorcer les ordinateurs sur autre chose que
le disque dur une fois le système installé. Les cassettes DAT des sauvegardes seront rangées dans un autre local en
prévision d’une détérioration des serveurs (incendie, inondation...). La sécurité informatique comporte une limite : elle
est inexistante dès lors qu’il y a accès physique au matériel, mais on peut tout de même prendre quelques précautions.
1.2
Les machines clientes
L’idéal pour la maintenance est de disposer de machines strictement homogènes, mais il est clair que cette homogénéité n’est simple ni à obtenir ni à conserver dans le temps.
Quand à l’achat de matériel, une règle simple s’impose qui doit guider tout choix : se renseigner au préalable sur
la compatibilité Linux de tout composant en identifiant très précisément celui ci. Un devis très détaillé demandé
au fournisseur doit permettre de taper le nom de chaque composant et périphérique, à commencer par la carte mère,
dans un moteur de recherche pour étudier les problèmes qu’ont pu rencontrer les utilisateurs. Moins on parle d’un
certain matériel, mieux il est supporté... Le matériel de marque SiS pose les plus grands problèmes de compatibilité,
outre ses performances relativement douteuses quel que soit le système d’exploitation.
Une station de travail aujourd’hui requiert le plus de mémoire vive possible, 512 Mo ne coutant pas beaucoup
plus cher que 256 Mo. Pour des applications particulièrement gourmandes en ressources, en particulier l’usage de
synthétiseurs virtuels ou de logiciels de montage vidéo (comme Cinelerra, les auteurs recommandant une machine
4
bi processeur), on prévoira 1 Go de RAM. Il est faux de croire que les environnements graphiques modernes sous
GNU/Linux sont moins gourmands en ressource que les environnements propriétaires. Un système rapide, agréable à
utiliser, qui fasse fonctionner en même temps de nombreux logiciels et environnements de bureau récents requiert une
machine puissante.
Les cartes vidéo sont quelque peu difficiles à choisir puisque les principaux constructeurs ne livrent plus entièrement
les spécifications de leur matériel : il est donc impossible de les exploiter entièrement avec des pilotes libres. Toutefois,
le problème ne se pose qu’avec les applications 3D, principalement les jeux, encore relativement rares et peu pertinents
dans un contexte éducatif ou de formation, à l’exception notable du logiciel Celestia2 . Les cartes graphiques du
constructeur ATI, modèles Radeon jusque 9300, fonctionnent très bien, y compris en 3D, avec les pilotes libres standard
sans téléchargement de driver, compilation de modules, etc... Il n’en va pas de même des cartes de type GForce de
Nvidia. Enfin pour le pur travail en 2D, les cartes du constructeur Matrox restent une référence de qualité, en particulier
pour travailler sur plusieurs écrans.
L’environnement graphique X Window est d’autant plus confortable et agréable à l’usage que la résolution de
l’écran est grande, 1280x1024 constituant un strict minimum. On appréciera de travailler en 1600x1200 avec de nombreuses applications ouvertes à l’écran, ce qui est normal avec un système d’exploitation de type Unix pleinement
multitâches. Aussi, des écrans CRT de grandes dimensions (19 pouces ou plus) seront préférés à des écrans TFT dans
la limite du même budget. Ceci sera encore plus vrai pour les postes des formateurs dont l’affichage sera redirigé sur
vidéoprojecteur : si l’on doit montrer des manipulations en ligne de commande avec des stagiaires assis un peu loin
de l’écran, grossir considérablement la police de caractères, et donc la taille du terminal, peut rendre une résolution
1280x1024 difficilement utilisable.
1.3
Matériel complémentaire
Pour se connecter à Internet par l’ADSL, tout modem Ethernet est parfait, aucun modem USB ne convient. Le
firewall / routeur que nous préconisons permet de se passer de routeur dédié, intégré ou non au modem.
Les imprimantes seront simples à choisir : un modèle PostScript réseau ne demandera aucun pilote d’impression
particulier, fonctionnera dans tous les cas de figure avec n’importe quel système d’exploitation et donnera toute
satisfaction pendant de longues années. Une imprimante jet d’encre couleur de bonne qualité sera plus difficile à
choisir, on se demandera en premier lieu si les stagiaires ont réellement besoin de ce type d’impression, eu égard
au coût des consommables. Le site linuxprinting.org3 recense tous les problèmes de compatibilité matérielle (très
importante base de données d’imprimantes).
Les scanners peuvent poser bien plus de problèmes de compatibilité que les imprimantes, on identifiera très
exactement le matériel avant tout achat. Le logiciel standard s’appelle Sane4 , et dispose d’une interface graphique
uniforme pour tous les scanners, un avantage par rapport à la diversité de logiciels de pilotage propriétaires qui
imposent d’utiliser une interface différente par type de scanner. Le site mentionné ci dessus intègre une très importante
base de données qui expose le degré de compatibilité de la plupart des matériels connus, classés par fabricants ou par
pilote. D’une manière générale, un scanner véritablement SCSI (c’est à dire sans carte propriétaire mal identifiable)
fonctionnera partout sans problème, mais ce type de matériel devient rare. Un très grand nombre de scanners USB sont
compatibles, on sera donc très circonspect quand au matériel imposant des manipulations complexes et hasardeuses
dont on peut se dispenser aujourd’hui.
Les cartes sons s’organisent autour de « standards » industriels qui correspondent dans la réalité à des chipsets
fort différents. Néanmoins les cartes normalisés AC 97 sont aujourd’hui les plus répandues et fonctionnent en général
de manière satisfaisante, mais on ne cherchera pas autre chose avec ce type de matériel que l’écoute de CDs audio
ou fichiers OGG Vorbis ou mp3 sur des enceintes bas de gamme. Pour un véritable travail multimédia, on s’orientera
vers un matériel de bonne qualité voire professionnel, la marque RME constituant une référence. Cette fois, le projet
ALSA5 (Advanced Linux Sound Architecture) fait autorité ; le site intègre une base de données des cartes son qui tend
à l’exhaustivité. Une section entière6 de notre site est consacrée aux logiciels de musique et audio sous GNU/Linux,
qui sont pléthoriques.
Les appareils photos numériques sont, eux, encore loin de présenter tous le même degré de compatibilité, en
particulier ceux de marque Canon qui, quelles que soient les qualités de leurs optiques et boîtiers, embarquent un
matériel aux spécifications très peu ouvertes. Les appareils récents fonctionnent toutefois souvent selon le protocole
PTP qui permet une détection et une communication aisée avec un ordinateur. La base de données du matériel supporté
2 http
://logiciels-libres-cndp.ac-versailles.fr/article.php3 ?id_article=7
://www.linuxprinting.org/
4 http ://www.sane-project.org/
5 http ://www.alsa-project.org/
6 http ://logiciels-libres-cndp.ac-versailles.fr/rubrique.php3 ?id_rubrique=16
3 http
5
se trouve sur le site du logiciel standard de pilotage de ce type de matériel : Gphoto7 . Un article8 du présent site expose
l’interface graphique la plus courante pour communiquer avec un appareil photo numérique sous GNU/linux et traiter
les images obtenues.
Le matériel d’acquisition vidéo numérique est le terrain ou GNU/Linux possède le plus de retard par rapport
aux offres propriétaires. Le site Funix.org9 donne des informations complètes à propos des configurations matérielles
et logicielles pour l’acquisition et le montage.
Enfin, le noyau Linux 2.6 sera systématiquement préféré à la version 2.4 dès qu’on se proposera de travailler le
multimédia, d’utiliser des périphériques USB ou Firewire, de toucher à la gestion avancée de l’énergie (ACPI)... Un
article10 sur le présent site expose en détail la procédure de compilation d’un noyau 2.6 avec toutes les options et
pilotes.
2
L’installation des systèmes d’exploitation
Note préliminaire Cet article concerne particulièrement un centre de formation, mais pourquoi pas d’autres structures (établissement scolaire, espace public numérique, etc...). Il présuppose des connaissances en réseau relativement
solides. Cependant, des solutions packagées libres existent qui simplifient grandement l’installation des serveurs et des
services réseau et offrent des interfaces graphiques simplifiées d’administration qui ne requièrent pas de compétences
Unix particulières, au premier rang desquelles Slis et Sambaedu. Une liste des solutions serveurs pour l’Éducation
Nationale est en ligne sur le présent site11 .
De manière générale, le choix Debian, systématique dans cette étude, ne doit pas faire oublier que la plupart des
conseils et fichiers de configuration seront identiques dans d’autres distributions puisque les logiciels sont les mêmes.
Pour les machines clientes, si nous préconisons Debian Sid, mentionnons tout de même la distribution Ubuntu12 , très
simple d’installation, particulièrement bien finie et basée sur Sid. Quelques manipulations sont cependant nécessaires
pour disposer vraiment de tous les logiciels de Debian, qui ne sont pas supportés de la même manière.
Nous ne détaillerons pas outre mesure l’installation de Debian GNU/Linux sur un ordinateur, serveur ou non, dans
la mesure où celle ci est aujourd’hui tellement simplifiée, décrite et documentée qu’elle ne pose pas de problème en
dehors de l’étape toujours délicate du partitionnement des disques.
Debian comprend aujourd’hui trois distributions principales :
– Woody, ancienne distribution stable. Elle n’est aujourd’hui plus actualisée que pour des mises à jour de sécurité
et peut maintenant être abandonnée ; toutefois, une mise à jour d’une machine Woody vers Sarge doit être bien
préparée et vérifiée à l’avance. 13 .
– Sarge est la version stable, sortie le 6 Juin 2005 après une longue attente. Elle convient pour tout usage, station
de travail comme serveur, et dispose d’un installeur très confortable.
– Sid (Still in developpement) est la version unstable. Recommandée si l’on désire les dernières versions des logiciels
au fur et à mesure de leur sortie, elle présente le risque relativement mineur de rencontrer parfois un certain
nombre de choses qui ne fonctionnent pas, ou mal, en particulier le système de dépendances qui empêche parfois
l’installation ou la mise à jour d’un plus ou moins grand nombre de choses à cause d’un seul package. Néanmoins,
l’utilisation de Sid au quotidien depuis plusieurs années est tout à fait confortable. On prendra simplement garde
de ne pas se ruer immédiatement sur les tous derniers packages disponibles dès leur sortie, et d’installer l’utilitaire
apt-listbugs qui prévient des problèmes avant installation ou mise à jour effective de tel ou tel logiciel.
2.1
Partitionnement des serveurs
Le principe de tout partitionnement est simple : séparer rigoureusement le système des données. Le reste peut
donner lieu à de nombreux débats confinant à la théologie :), concernant en particulier les partitions pour /var et
/tmp.
Nous avons retenu le partage des services réseau sur deux serveurs (outre le petit routeur) et avons donné dans
la section précédente leur répartition sur chaque ordinateur, mais on peut très bien concevoir de tout placer sur un
seul serveur si on n’a pas de problème de charge ou de débit sur le réseau local. Nous conseillons le partitionnement
suivant pour le serveur devant héberger les données et les comptes :
7 http
://www.gphoto.org/
9 http ://www.funix.org/
10 http ://logiciels-libres-cndp.ac-versailles.fr/article.php3 ?id_article=180
12 http ://www.ubuntulinux.org/
13 Par souci de compatibilité, de nombreux services sont décrits dans cet article pour leurs anciennes versions pour Woody comme pour
les versions récentes disponibles en Sarge.
8 http
6
sda1 : /boot : 15 Mo 14
sda2 : Swap : 1,2 Go pour 1 Go de Ram.
sda3 : / : 5 Go (si l’on prévoit vraiment l’installation de très nombreux logiciels)
sda4 : /home : le reste du disque
sdb1 : /data : le second disque du serveur, que l’on pourra affecter à autant de partages réseau que de besoin pour
le stockage de données, exportées ou non sur le réseau.
Le second serveur n’héberge pas à proprement parler de données mais plutôt des sauvegardes (on y place donc le
lecteur DAT), ainsi que divers spools de proxy et d’impression.
sda1 : /boot : 15 Mo (avec la réserve ci dessus)
sda2 : Swap : 1,2 Go pour 1 Go de Ram.
sda3 : / : 5 Go (si l’on prévoit vraiment l’installation de très nombreux logiciels)
sda4 : partition étendue
sda5 : /var/spool : au moins 6 Go, pour les spools de squid, d’apt-proxy, de l’impression et d’Amanda.
sda6 : /data : le reste du disque, environ 50 Go, pour les images des disques des stations générées avec le logiciel
partimage 15 .
Ces partitions seront formatées avec le système de fichiers ext3 si l’on désire une sauvegarde simple avec Amanda.
Reiserfs ne peut pas être sauvegardé ni surtout partiellement restauré simplement et XFS demande un
logiciel spécifique de backup, outre la complexité de sauvegarde des ACLs. Normalement, un centre de formation avec
des utilisateurs occasionnels n’a pas besoin d’un système de fichiers aussi complexe que XFS. Si l’on envisage la mise
en place d’un serveur de news avec un feed extérieur, cela se traduira par la prolifération de petits fichiers extrêmement
nombreux dans le spool, il sera donc recommandé d’augmenter la densité des inodes de la partition /var/spool au
formatage (voir man mke2fs, option -i. Cette option est à fixer au formatage, il n’est plus possible de la modifier par
la suite).
Par contre il est possible d’ajouter la journalisation à un système ext2, donc passer en ext3, de manière très simple :
« tune2fs -j /dev/sdax », en rajoutant bien sur dans le fichier /etc/fstab que la partition est maintenant en ext3. La page
de man de tune2fs donne toutes les précisions voulues, également pour modifier le pourcentage d’espace disque alloué
au super utilisateur par partition. Cela sera utile après redimensionnement d’une partition avec le logiciel parted 16 ,
qui fonctionne très bien, dans la mesure où l’usage peut révéler une partition chroniquement sur dimensionnée au
détriment d’une autre.
2.2
Partitionnement d’une station de travail
Le partitionnement d’une station de travail est beaucoup plus simple et beaucoup moins sensible que celui d’un
serveur, dans la mesure où les stations n’hébergent absolument aucune donnée ; la partition /home est montée au
boot par NFS et n’occupe donc aucun espace sur le disque local. On pourra faire une petite partition /boot, puis une
partition de swap plus large que la RAM dont on prévoit de doter a terme la machine, le reste du disque contenant
la partition racine /. Une installation complète de Gnome 2.8, KDE 3.3, Enlightenment, Windowmaker, Mozilla,
Firefox, Thunderbird, Gimp 2.2, LATEX, OOo 1.1, Gcompris et la majeure partie des logiciels éducatifs ou transversaux
référencés sur le présent site17 occupe moins de 3 Go sur le disque. En comptant large, une partition de 6 Go est donc
amplement suffisante.
2.3
Conseils généraux pour l’installation
Qu’il s’agisse d’un serveur ou d’une station de travail, l’installation de Debian demeure simple mis à part le moment
du partitionnement qui requiert une grande attention. Les machines clientes et l’environnement français sont détaillées
dans la section 9. Voici quelques conseils complémentaires :
– le mot de passe root des stations ne doit pas être le même que celui des serveurs et autres machines
« sensibles ». Par simple bon sens, mais aussi parce qu’on fera parfois installer des logiciels par les stagiaires.
– l’installeur Sarge sera démarré avec l’option linux26 pour le kernel 2.6.8.
– Le gestionnaire d’amorçage (lilo ou GRUB) doit toujours être installé dans le MBR (master boot record) du
disque principal. L’installer ailleurs, sur une partition du disque ou sur une disquette, est le meilleur moyen
d’avoir des problèmes par la suite.
14 Taille conseillée si l’on ne recourt pas aux images de kernel officielles qui intègrent un initrd de large taille, avec tous les modules de
gestion du SCSI, RAID, IDE, file systems, etc... En ce cas, prévoir une petite centaine de Mo par sécurité.
15 A l’usage, il s’avère que seuls les systèmes MS-Windows ont vraiment besoin de ce genre de sauvegarde
16 http ://www.gnu.org/software/parted/parted.html
17 http ://logiciels-libres-cndp.ac-versailles.fr/
7
– Dans le cas de machines en double amorçage avec un système d’exploitation MS-Windows, toujours commencer
par installer ce dernier et installer GNU/Linux ensuite.
– La configuration de Debian s’achève par la configuration du serveur SMTP qui permet au système de prévenir
son administrateur de tel ou tel problème en lui envoyant un mail. Root n’a aucune raison de lire, et encore
moins de rédiger, du courrier. On redirigera donc tout le courrier de toutes les machines vers un utilisateur du
réseau, typiquement le compte de la personne en train de lire ce document :-). Ceci se corrige en éditant le fichier
/etc/aliases pour placer un alias ainsi : « root : [email protected] » (où cette adresse est celle de l’administrateur
du réseau), puis en mettant a jour la base d’alias au moyen de la commande newaliases et en relançant le serveur
SMTP (dans le cas de Postfix, régénérer la base d’alias au moyen de la commande « postmap /etc/aliases »). On
vérifiera au moyen de la commande « echo coucou|mail root » que l’utilisateur « yves » reçoit bien les messages
de root sur son compte, sur l’ordinateur qui centralise les messages du domaine (voir plus loin, section 7.1.3).
– Le serveur SMTP exim, choix par défaut de Debian, convient bien pour une machine qui ne fait qu’envoyer les
mails du système vers un compte du réseau. Pour le serveur SMTP principal, qui doit traiter tout le courrier des
utilisateurs, on préférera Postfix dont la configuration est détaillée dans la section 7.1.
2.4
Les sources des packages Debian
Un principe de Debian est que tous les logiciels reposent sur des packages qui définissent leurs dépendances : ainsi,
on ne va jamais à la pêche à telle ou telle version d’une librairie très précise qui elle même en demande une autre qu’il
faudra laborieusement compiler, cette « aventure » s’achevant par une réinstallation et mise à jour à la main de la
moitié du système. Au contraire, l’installation d’un package conditionne la mise en place de tout ce qui est nécessaire
pour qu’il fonctionne, en passant par internet pour obtenir les dernières versions des logiciels
Tout passe ainsi par l’utilitaire apt-get dont on trouvera sur ce même site18 une description sommaire. le HOWTO
d’apt19 exposant beaucoup plus complètement ce logiciel qui fait une grande partie du confort, comme du succès, de
Debian.
Apt possède son fichier de configuration : /etc/apt/sources.list qui décrit les serveurs et sources sur lesquels il
va aller chercher ses packages. Un proxy de packages permettant d’économiser de la bande passante et du temps de
téléchargement pour tous les ordinateurs de notre réseau sera installé plus tard (section 6.3), mais dans un premier
temps, pour partir de quelque chose, nous retiendrons cette configuration :
– Pour un serveur :
#Securite
deb http://security.debian.org/ stable/updates main
#Serveur principal
deb ftp://ftp.fr.debian.org/debian stable main contrib
– Pour une station de travail, on prendra les mêmes sources mais avec la section unstable ou sid au lieu de stable
ou woody , en rajoutant certains serveurs qui proposent des logiciels en plus, selon les besoins (voir par exemple
apt-get.org20 , les serveurs proposés ne sont en rien officiels) :
#Securite
deb http://security.debian.org/ testing/updates main
#Source principale
deb ftp://ftp.fr.debian.org/debian sid main contrib
#Agnula, logiciels de création musicale et multimedia
deb http://apt.agnula.org/demudi/ unstable main local extra
#Acrobat Reader, Mplayer, logiciels non libres
deb ftp://ftp.nerim.net/debian-marillat unstable main
##Cinelerra, logiciel de montage video professionnel
deb http://www.kiberpipa.org/~minmax/cinelerra/builds/sid/ ./
18 http
://www.debian.org/doc/manuals/apt-howto/index.en.html
20 http ://www.apt-get.org/
19 http
8
2.5
Logiciels complémentaires
Au sortir de l’installation de Debian, on dispose d’un système fonctionnel mais tellement minimal qu’on ne peut
presque rien faire avec. Même pour une telle installation, il manque un certain nombre de logiciels qu’on installera de
suite, généralement parce qu’ils seront nécessaires pour identifier certains problèmes dans des situations où il ne sera
plus possible d’installer quoique ce soit :
– lsof, List Open Files, permet de savoir quels sont les fichiers ouverts et quel process les ouvre 21 .
– less affiche les pages de man de manière beaucoup plus confortable que le pager par défaut, more.
– manpages-fr, pour disposer de ce qui est traduit
– tcpdump, capteur de trames réseau.
– nmap, scanner de ports pour s’assurer de ce qui est ouvert localement ou sur une autre machine .
– ssh, permettant de prendre a distance le contrôle de la machine en mode texte. Il y a peu de raisons de ne pas
installer ssh sur une machine. On prendra les choix par défaut lors de la configuration sous peine d’introduire
une faille de sécurité.
– rsync, dont nous ferons un usage intensif pour distribuer des fichiers sur tout le réseau à la fin de cet article.
– ntpdate, pour mettre les machines à l’heure sur le serveur de temps du réseau (voir section 6.5).
– localepurge (voir 9.1.2).
Bien entendu, apt-get installera tout cela en quelques instants.
3
Une session de travail d’un administrateur réseau
3.1
Conseils généraux
Pour organiser son travail de manière efficace, ne pas répéter toujours les mêmes taches et conserver une visibilité
maximale de ce qui se passe sur un ordinateur au fur et à mesure que l’on installe des logiciels et qu’on modifie leur
configuration, un certain nombre d’habitudes de travail, de simple bon sens, sont à prendre. Trois points essentiels :
Comprendre ce que l’on est en train de faire en consultant systématiquement les pages de man et la
documentation présente dans /usr/share/doc/<nom du package>, en particulier les fichiers README.Debian 22 . Un
service réseau ne démarrera pas ou ne fonctionnera pas correctement si l’on ne fait pas ce qui est indiqué dans ces
fichiers rédigés très clairement, hélas en anglais.
Se familiariser avec un éditeur en mode texte qui permet d’ouvrir simplement plusieurs fichiers en même
temps, et se familiariser pendant une ou deux heures avec ses raccourcis clavier.
– Jed constitue de notre point de vue un excellent choix : cet éditeur, léger, n’impose pas de manipulation particulière pour saisir du texte ou en modifier, ni pour revenir à un mode permettant de sauvegarder son travail,
ce qu’attend a priori un être humain normalement constitué. Il présente des menus qui rappellent les raccourcis
clavier les plus usuels, offre une coloration syntaxique par défaut et peut être utilisé à de nombreuses autres
fins, introduisant ainsi à un environnement complet de programmation, de courrier, de lecture de forums et
bien d’autres choses, connu sous le nom d’Emacs. Un didacticiel en français est proposé avec Emacs, lancé avec
le raccourci clavier C-h t 23 . Une heure passée avec ce didacticiel permet de bien comprendre la logique très
claire des raccourcis clavier et de commencer à être opérationnel. On trouve facilement sur le Web des tableaux
récapitulatifs24 des raccourcis d’emacs.
– Mc est un gestionnaire de fichiers en mode texte très apprécié, qui propose un éditeur plus sommaire que jed
mais qui reste de manipulaton aisée.
– Vi, ou ses clones, sont présents par défaut sous tout système Unix comme un mal nécessaire. On se doit de
connaître un minimum ses raccourcis clavier, en particulier ceux permettant d’en sortir rapidement ( :q !) :-).
Un appui sur la touche escape permet en principe de saisir cette commande si les lettres :q ! apparaissent encore
dans le corps du texte. La fonction M-x doctor d’emacs offre secours et compassion après une session, même
brève, de « travail » dans vi.
Organiser sa session de travail en ouvrant quatre consoles textes (ou quatre xterm si l’on travaille sous X à
travers ssh). Sur ces 4 consoles, on maintiendra :
1. Un éditeur ouvert, qui permet d’ouvrir plusieurs fichiers en même temps25
21 en
particulier lsof -i :<n◦ _de_port>
commande zless permet de visualiser un fichier sans le décompresser
23 Control h suivi de t
24 http ://asi.insa-rouen.fr/˜lfallet/informatique/emacs.php
25 Raccourcis claviers utiles pour travailler sur plusieurs fichiers en même temps :
– C-x C-f pour ouvrir un nouveau fichier
– C-x b pour naviguer entre les fichiers ou tampons déjà ouverts, la complétion fonctionne classiquement au moyen de la touche de
tabulation
22 la
9
2. Un simple shell pour taper des commandes, en particulier redémarrer le service réseau dont on vient de modifier
la configuration (/etc/init.d/nom_du_service start|stop|restart).
3. Le contenu d’un fichier de log qui consigne l’activité du système en temps réel (/var/log/syslog) ou l’activité
plus spécifique d’un service (par exemple /var/spool/squid/access.log) et par là ce que signale le service réseau
lors de son redémarrage et pendant son fonctionnement (commande tail -f <nom du fichier de logs>).
4. La documentation de ce qu’on est en train de faire.
Quelqu’un cherchant de l’aide sur les newsgroups ou les listes de diffusion se voit souvent répondre : « que disent
les logs ? », et ensuite RTFM26 ou man. Avoir donc la doc et les logs présents à l’écran permet de gagner du temps et
surtout de l’autonomie.
3.2
Un interpréteur de commandes confortable : zsh, le Z Shell
La plupart des manipulations décrites dans ce document se font en mode texte, en dehors de toute interface graphique qui a très fortement tendance à diminuer la compréhension des choses et réduire l’autonomie de l’administrateur
système. Cependant, le shell (ou interpréteur de commandes) standard Bash présente de nombreuses limitations, même
dans ses dernières versions. Nous préconisons ainsi l’usage de Zsh en version 4, shell très évolué permettant divers
modes de complétion27 programmable et fonctionnalités très étendues parmi lesquelles on notera :
– Complétion pour ssh tenant compte des machines connues ( /.ssh/known_hosts). Il devient superflu de taper le
nom entier des machines qu’on désire joindre, les premières lettres suffisent.
– Complétion distante pour scp permettant de naviguer à la complétion dans le système de fichiers d’une
machine distante, ce qui permet aux clefs et agents ssh de présenter un intérêt encore accru (voire section
10.2).
– Complétion sur les options des commandes et non plus seulement sur les commandes elles mêmes, ce qui
facilite la découverte de logiciels mal connus. Par exemple, la commande gphoto2 suivie de deux appuis sur la
touche de tabulation montrera clairement comment piloter un appareil photo en mode texte.
– Complétion sur les cibles des commandes, particulièrement pratique avec apt-get install et apt-cache show puisque
la complétion proposera les packages disponibles. Un système de cache permet d’optimiser les performances de cette fonctionnalité.
– Navigation dans le système de fichiers, dans des archives (tar, zip...) et plus généralement dans tous les choix de
complétion au moyen d’un menu dans lequel les touches fléchées du clavier permettent de naviguer. Ce menu est
colorisé de la même manière que la commande ls.
– Prompt grandement personnalisable, la configuration ici proposée teste la charge machine et colorise le prompt
en fonction de celle ci, ce qui permet de remarquer tout de suite un problème éventuel au login.
– Navigation dans un historique partagé entre les divers shells ouverts, permettant d’obtenir des informations sur
la date et la durée d’exécution d’une commande. Pour retrouver une commande, Esc-p permet une navigation
standard et Ctrl-r une recherche incrémentale (comme bash).
Zsh est lancé temporairement en l’appelant par son nom, mais le changement de shell définitif s’effectue dans le
système au moyen de la commande chsh. On prendra garde au bon fonctionnement de la configuration avant de changer
le shell de root, mais même en ce cas la commande su - -s /bin/bash permet de récupérer un shell fonctionnel.
Le Z Shell demande un travail de configuration afin de disposer de tous ces avantages, nous proposons une configuration complète28 dont la mise en place est détaillée dans le fichier README. L’installation des logiciels complémentaires
indiqués, totalement indispensables (en particulier cowsay), offrira un plaisir animalier toujours renouvelé à chaque
ouverture de session :).
Il existe assez peu de sites en français concernant Zsh, et la version 4 diffère très sensiblement de la version 3.
Signalons, en anglais, parmi des ressources très nombreuses :
– Un bref didacticiel29 chez IBM.
– Zsh-lovers30 , nombreux trucs et astuces.
–
–
–
–
C-x
C-x
C-x
C-x
5
o
k
1
2 pour scinder la fenêtre d’édition en deux
pour naviguer d’une fenêtre à l’autre (par exemple pour faire des copier-coller)
pour tuer le tampon courant
pour n’afficher qu’une seule fenêtre
26 http
://www.catb.org/˜esr/jargon/html/R/RTFM.html
appelle complétion l’utilisation d’une touche, généralement la tabulation, pour compléter ce qui est saisi sur la ligne de commande
au lieu de tout saisir manuellement. Ceci offre un confort certain, mais surtout évite de taper des erreurs, aussi faut-il utiliser cette
complétion systématiquement.
28 http ://logiciels-libresècndp.ac-versailles.fr/debianinstall/fichiers/zsh
29 http ://www-106.ibm.com/developerworks/linux/library/l-z.html ?dwzone=linux
30 http ://grml.org/zsh/zsh-lovers.html
27 On
10
– Un guide de l’utilisateur31 sur le site officiel.
4
Sécuriser une machine Debian : les bases
Chacun mesurera, en fonction du public auquel est destiné son réseau, quels sont ses besoins en matière de sécurité,
en dehors du routeur / Firewall que nous exposons dans la section suivante. Il y a un monde entre une salle où ne
passent que des enseignants qui, dans le cadre d’un plan académique de formation, viennent apprendre le traitement
de textes et les rudiments d’internet sous la responsabilité d’un formateur, et un local qui accueille des élèves sans
contrôle pendant leurs heures de permanence. Mais la première priorité d’un administrateur réseau doit être la sécurité,
condition première de la haute disponibilité des machines.
Au sortir de l’installation, une machine GNU/Linux n’est pas nécessairement aussi sécurisée qu’elle peut l’être, si
l’on part de ce principe : d’abord, on ferme tout et on ouvre ensuite selon des besoins mûrement réfléchis.
1. Commenter toutes les entrées du fichier /etc/inetd.conf, sauf celles qui servent explicitement à un usage réel
(normalement il n’y en a aucun, lorsque l’installation de notre réseau sera complète il y aura pop et ftp sur le
serveur principal, et Amanda sur toutes les machines sauvegardées). Inetd est ce « super daemon » qui lance des
services à la demande, leur évitant ainsi de tourner en permanence pour ne pas surcharger la machine. Certaines
entrées comme time, discard, parfois finger, etc... sont actives par défaut.
2. Placer la directive ALL : ALL dans le fichier /etc/hosts.deny et redémarrer inetd. Man 5 hosts_access indique
des exemples très clairs de configuration des tcp wrappers qui autorisent ou non certains services à telle ou telle
machine.
3. Le fichier /etc/lilo.conf contient une ligne commentée « password=tatacounter » qui permet de démarrer la
machine en mode « single user » et d’avoir ainsi un accès root sans authentification. On évitera cela en décommentant cette ligne, en changeant le mot de passe, en sécurisant ce fichier 32 et enfin en réinstallant lilo
(commande lilo).
Il est indispensable de s’abonner à la liste de diffusion d’alertes de sécurité de Debian dès lors que l’on administre une
machine, a fortiori un serveur connecté jour et nuit à Internet. Il suffit de cliquer ici : http ://lists.debian.org/debiansecurity-announce/33 et d’entrer son adresse.
5
Configuration et sécurité du routeur
Cet ordinateur n’a pas besoin de beaucoup de puissance ou ressources matérielles, par contre il doit faire l’objet de
l’attention la plus grande en matière de sécurité car il est relié en permanence par une IP publique au monde extérieur
et va donc subir des tentatives d’intrusion et attaques diverses venues de pirates qu’il sera toujours difficile d’identifier.
Insistons : il est très maladroit de se demander « vais-je subir des attaques ? ». La question pertinente est : « comment
mes services réseau ont-ils réagi aux tentatives d’intrusion qui ont eu lieu depuis que je les ai mis en place il y a une
demi heure ?».
Pour cette raison, on suivra le principe suivant : le pare feu ne doit héberger aucun service réseau en plus de lui
même et du moyen éventuel d’entrer depuis l’extérieur (ssh). On sera particulièrement attentif à la consultation de ses
journaux (logs).
Note importante Les services réseau présentés dans ce document ne sont pas considérés comme ouverts sur
Internet mais réservés à un usage interne ; aucune translation de port n’est active par défaut dans la configuration de
firewall proposée. On ne redirigera surtout aucun port vers le serveur hébergeant les données des utilisateurs, même
pour le courrier ou le Web. Pour ouvrir certains services au monde extérieur, on se renseignera sur la notion de DMZ
où l’on placera un serveur dédié.
Une installation minimale de Debian stable suffira pour le routeur ; un partitionnement très simple conviendra
puisqu’il n’y aura ni compte ni donnée sur cet ordinateur.
5.1
Sécurité sur le routeur : première étape
Aucun ordinateur ne doit être connecté à Internet sans être protégé par Firewall, qu’il n’y a aucune raison de
désactiver, même pour un instant.
31 http
://zsh.sunsite.dk/Guide/zshguide.html
moyen de la commande chmod 600 /etc/lilo.conf
33 http ://lists.debian.org/debian-security-announce/
33 il va de soi qu’aucun client NIS ou LDAP ne sera installé.
32 au
11
Ce script de firewall34 est à placer dans le répertoire /etc/init.d. Le rendre exécutable (chmod 700 iptables.sh) et
exécuté au boot du routeur par la commande update-rc.d iptables.sh start 15 2 3 4 5 . (attention au . final, voir man
update-rc.d ). Redémarrer l’ordinateur pour vérifier que les règles iptables sont bien appliquées au boot, la commande
iptables -L -v devant montrer que les tables INPUT et FORWARD ont une policy de DROP, et que n’est accepté en
entrée sur ppp0 que ce qui est ESTABLISHED ou RELATED (une chaîne supplémentaire est affichée pour les logs).
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target
prot opt in
out
source
\destination
287 16748 ACCEPT
tcp -- any
any
localnet/24
\anywhere
tcp dpt:ssh
2
168 ACCEPT
icmp -- any
any
anywhere
\
anywhere
144 12183 ACCEPT
all -- any
any
anywhere
\
anywhere
state RELATED,ESTABLISHED
3
483 ACCEPT
all -- eth0
any
anywhere
\
anywhere
state NEW
0
0 ACCEPT
all -- lo
any
anywhere
\
anywhere
state NEW
8
400 LOG_AND_DROP all -- any
any
anywhere
\
anywhere
Chain
pkts
\
207
\
176
\
FORWARD (policy DROP 0 packets, 0 bytes)
bytes target
prot opt in
out
source
destination
14731 ACCEPT
all -- eth0
any
anywhere
anywhere
23867 ACCEPT
all -- any
any
anywhere
anywhere
state RELATED,ESTABLISHED
Chain OUTPUT (policy ACCEPT 4200K packets, 327M bytes)
pkts bytes target
prot opt in
out
source
\
destination
Quelques observations sur cette configuration :
– Tout est ouvert en sortie puisque nous n’avons pas de raison particulière d’interdire tel ou tel usage à l’intérieur
du centre de formation. On réfléchira soigneusement, dans un établissement à vocation éducative, à mettre
en place un tel filtrage, comme toute forme de censure qui est vite contre-productive sans un accompagnement
pédagogique consistant déjà en la mise au point d’une charte des usages, adjointe au règlement intérieur, adoptée
en conseil d’administration et signée par les élèves.
– Filtrer ICMP en entrée de manière brutale doit être proscrit, mais un filtrage réfléchi permet d’éviter d’être
visible aux scans les plus grossiers. Aucun filtrage d’ICMP ne protège réellement contre un pirate compétent et
décidé.
– Les logs de Netfilter sont fastidieux et guère passionnants à lire. Le logiciel fwlogwatch, disponible dans Debian,
permet entre autres d’auditer les logs du Firewall et propose des rapports au format HTML35 ; il dépasse le cadre
de cet article.
Nous pouvons maintenant ouvrir la connexion ADSL ; elle se paramètre avec la commande pppoeconfig, les fichiers
de configuration se trouvant dans le repertoire /etc/ppp. La ligne est ouverte avec « pon dsl-provider », fermée par «
poff » et une option à la configuration permet de la rendre persistante, ce qui est recommandé.
Ce script36 permet de tester basiquement la ligne et de la remonter, on pourra le placer en crontab pour l’éxécuter
tous les quarts d’heure.
34 http
://logiciels-libres-cndp.ac-versailles.fr/debianinstall/fichiers/iptables.sh
://logiciels-libres-cndp.ac-versailles.fr/debianinstall/fichiers/report.html
36 http ://logiciels-libres-cndp.ac-versailles.fr/debianinstall/fichiers/internet.sh
35 http
12
5.2
Sécurité sur le routeur : seconde étape
Mettons tout de suite à jour la machine pour installer les derniers correctifs de sécurité : « apt-get update ; apt-get
dist-upgrade ». Installer la dernière version du kernel, ou mieux le compiler soi même37 pour l’optimiser et n’y mettre
que ce qui est nécessaire, reste une excellente idée.
Cette mise à jour sera suivie de l’installation des packages Logcheck et ssh.
Logcheck audite tous les journaux, ou logs, du système et envoie son audit par mail à l’administrateur (voir ci
dessus comment déporter ces messages vers un compte effectivement lu), ceci selon une périodicité définie dans le
fichier /etc/cron.d/logcheck. Le niveau de sécurité « server » permet un audit suffisant, mais le niveau « paranoid »
est disponible :-).
le démon sshd permet de prendre la main à distance sur le routeur, mais surtout de parcourir le réseau et de se
logguer sur les machines depuis l’extérieur : très commode, ceci permet à l’administrateur du réseau de continuer à
travailler chez lui, le soir ou le week end :-).
Réalisons mantenant un premier et très sommaire audit de sécurité. Depuis l’extérieur du réseau, sur une
machine disposant de Nmap38 (le standard en matière de scanner de ports), la commande « nmap -O ip_du_routeur
» permet de s’assurer que seul le port 22 (ssh) est ouvert39 . En cas contraire, reprendre depuis le départ la sécurisation
de cette machine et la mise en place du pare-feu. Voici le résultat d’un scan de port satisfaisant :
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-03-16 16:47 CET
Warning: OS detection will be MUCH less reliable because we did not find
at least 1 open and 1 closed TCP port
Interesting ports on mpsoa.net4.nerim.net (62.212.122.37):
(The 1662 ports scanned but not shown below are in state: filtered)
PORT
STATE SERVICE
22/tcp open ssh
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux 2.4.0 - 2.5.20, Linux 2.4.10 - 2.4.18, Linux 2.4.19 (x86)
Uptime 66.351 days (since Sun Jan 9 08:23:22 2005)
Nmap finished: 1 IP address (1 host up) scanned in 30.075 seconds
5.3
Fonctionnalités additionnelles du script de firewall
Notre script permet de facilement ouvrir et translater des ports, les lignes permettant de le faire étant commentées.
Il suffira donc, par exemple pour que la machine 192.168.28.50 sur lequel on a placé un serveur Web soit consultable
de l’extérieur sur le port 80, de commencer par ouvrir ce port sur le firewall :
$IPTABLES -A INPUT -p TCP -s 0/0 --dport 80 -j ACCEPT
Puis de faire en sorte que toutes les requêtes arrivant sur l’ip publique du firewall à destination du port 80 soient
redirigées sur le port 80 de cette machine :
$IPTABLES -t nat -A PREROUTING -p tcp -i ppp0 -d 62.212.122.37
\ --dport 80 -j DNAT --to 192.168.28.50:80
$IPTABLES -A FORWARD -d 192.168.28.0/24 -p tcp --dport 80-j ACCEPT
Bien évidemment, on se sera soigneusement renseigné sur la sécurité du service réseau que l’on met ainsi à disposition
de manière à ne pas se le faire pirater ! La même procédure pourra ainsi être utilisée pour tester la sécurité du serveur
SMTP Postfix lorsque nous procéderons à sa configuration (section 7.1).
5.4
Simulation d’intrusions : Nessus
Nessus40 est un simulateur d’intrusions et scanner de vulnérabilités avec lequel auditer la sécurité de manière poussée
à partir d’une machine cliente, sur le réseau ou à l’extérieur. Il est toujours bon d’auditer plus finement qu’avec un
scan de ports grossier la sécurité de ses serveurs, aussi devrait-on considérer Nessus avec beaucoup d’attention. Voici
quelques liens :
37 http
://www.insecure.org/nmap/
39 avec ICMP non filtré, sinon ajouter l’option -P0. Ce type de scan est très long.
40 http ://www.nessus.org/
38 http
13
– Un didacticiel rapide d’installation et de configuration41 sur Trustonme.net.
– Une description plus élaborée42 exposant les options de scan, sur linuxfrench.net.
– Un autre article similaire très détaillé43 offert par linuxfocus.org.
Notons enfin que Nessus est tout sauf discret lors de ses scans, il faut être aveugle pour ne pas voir ses traces dans
les logs des machines scannées...
5.5
Logiciels complémentaires de sécurité
Ces logiciels dépassent le cadre de cette étude et ne sont pas strictement indispensables, en particulier si le seul
port ouvert est ssh. Ils complètent toutefois utilement l’installation d’un lien permanent à Internet, même si l’on n’est
pas spécialement paranoïaque :).
Tripwire44 permet de prendre l’empreinte d’une machine juste après son installation et de contrôler périodiquement
son intégrité.
Snort45 , classique IDS (système de détection d’intrusion), permet d’auditer très finement ce qui se passe sur le
réseau. Il existe un outil similaire mais beaucoup plus avancé, prelude-ids46 .
Chkrootkit47 permet de tenter de détecter la présence d’un rootkit48 sur la machine, trace indubitable d’un piratage.
Une machine piratée ne peut être fiablement auditée à partir d’elle même, ce qui restreint la pertinence
des mails que chkrootkit propose d’envoyer quotidiennement, et a fortiori un audit réalisé post mortem.
Pour de plus amples détails, de nombreux sites sur la sécurité informatique et l’excellente revue MISC49 peuvent
servir de référence.
Tous les logiciels ci dessus sont disponibles dans Debian et installables via APT. Il est bien entendu tout à fait
superflu d’installer un antivirus sur notre routeur.
Enfin, il est très fortement déconseillé de réagir automatiquement à un scan de ports ou une tentative
d’intrusion par une action (de filtrage ou bannissement en particulier) sur l’IP présumée de l’attaquant. Outre que le
pirate ne provient pas necessairement de l’IP que l’on croit avoir identifiée, il sera toujours tentant, pour la personne
se rendant compte qu’elle est victime d’une action de ce genre, de spoofer son attaque en se faisant passer pour un
serveur DNS, racine ou faisant autorité pour notre classe d’adresses IP, ce qui coupera notre réseau du reste du monde.
Nous serons ainsi responsables d’un joli déni de service dont nous serons nous mêmes victimes. C’est ce que propose
le logiciel Portsentry dont nous déconseillons absolument l’usage.
6
Premier serveur : les services réseau non authentifiés
Nous allons mettre en place dans cette section le premier serveur, dont la tâche sera essentiellement de nous relier à
internet, en plus de ce que fait le Firewall. Nous étudierons les services suivants : DNS, DHCP, proxy http et ftp, proxy
apt, miroir Debian, serveur de temps, serveur d’impression. D’une manière générale, nous configurerons les services
réseau de manière autonome, sans dépendre en rien du fournisseur d’accès (DNS, SMTP, etc..), pour nous affranchir
de tout dysfonctionnement de ce dernier et être certains que si quelque chose ne marche pas, nous avons la main sur
ce dysfonctionnement, mis à part les tuyaux, la connexion, qui est en fin de compte la seule chose à demander au
fournisseur d’accès.
6.1
Le DNS : Bind
Packages requis : bind, dnsutils, et leurs dépendances.
Le DNS établit un lien entre noms et adresses d’ordinateurs et constitue le coeur d’Internet. De fait, bind devient
vite le cœur d’un intranet et la première chose à installer dès que l’on sait s’en servir. Nous démontrerons sa puissance
lors de l’installation des stations de travail, où la distribution de fichiers à l’identique sur toutes les machines en une
seule ligne de commande reposera sur un DNS fonctionnel.
Lire et mettre en pratique le DNS HOWTO50 permet d’acquérir les bases du DNS et surtout de beaucoup mieux
comprendre Internet. Cette section présente un récapitulatif des fichiers de configuration d’une zone et d’un reverse,
elle ne remplace pas cette introduction au DNS, présupposée connue.
41 http
42 http
43 http
44 http
45 http
46 http
47 http
48 http
49 http
50 http
://www.trustonme.net/didactels/201.html
://www.linuxfrench.net/article.php3 ?id_article=938
://www.linuxfocus.org/Francais/November2001/article217.shtml
://www.tripwire.org/
://www.snort.org/
://www.prelude-ids.org/
://www.chkrootkit.org/
://en.wikipedia.org/wiki/Rootkit
://www.miscmag.com/sommaire.php
://www.freenix.fr/unix/linux/HOWTO/DNS-HOWTO.html
14
Avant de présenter la configuration détaillée, précisons que le serveur DNS maître a pour adresse 192.168.28.2 et
l’esclave 192.168.28.1.
Le fichier de configuration de bind est /etc/bind/named.conf. Commentons ce qui se trouve dans la section forwarders, pour résoudre nous mêmes les noms sur internet sans passer par le serveur du fournisseur d’accès, en interrogeant
directement les serveurs racines. 51
Ensuite, notre zone, qui va définir les noms de nos machines, s’appelle mp-soa.net ; nous allons donc y déclarer
notre zone et son reverse :
// add entries for other zones below here
zone "mp-soa.net" in {
type master;
file "db.mp-soa";
allow-transfer {192.168.28.1;};
};
zone "28.168.192.in-addr.arpa" in {
type master;
file "db.28.168.192";
allow-transfer {192.168.28.1;};
};
La section « allow-transfer » interdit à toute autre machine que 192.168.28.1 de faire un transfert de zone qui révélerait une bonne part de la structure de notre réseau, tout en déclarant une seconde machine comme DNS secondaire.
Nous avons déclaré deux fichiers dans /var/cache/bind qu’il va falloir créer et renseigner :
– db.mp-soa52 qui contient les machines de la zone mp-soa.net : tous les ordinateurs de notre réseau.
– db.28.168.19253 : la zone inversée ou reverse, associant des adresses à des noms. Cette zone est indispensable au
fonctionnement normal du DNS et par là de la majeure partie des services réseau. En particulier, le montage
NFS de la section suivante ne peut se faire que si la requête sur le reverse de la machine cliente qui opère le
montage réussit. Il en va de même pour nombres d’autres services (FTP, SMTP...) qui ne fonctionneront pas
normalement sans cette zone inversée.
Le DNS HOWTO mentionné ci dessus permet de comprendre la signification du caractère @ en début de fichier,
ainsi que la présence de points qui terminent les noms de machines dans le fichier de reverse, alors qu’il n’en va pas de
même dans la zone « droite ».
Lorsque les fichiers seront remplis correctement, on redémarrera bind en observant soigneusement les modifications
du fichier /var/log/syslog : toute erreur apparaît très clairement avec le nom du fichier et le numéro de la ligne qui
contient un bug. Bind indique explicitement que les zones sont chargées et qu’il est prêt à répondre aux requêtes
lorsque tout est correct. Pour rajouter, enlever ou modifier des machines du DNS, on incrémentera le serial number
après modification du fichier, puis on rechargera la zone au moyen de la commande ndc reload <nom de la zone>. Il
est en effet absurde de redémarrer bind si on a simplement modifié une zone, ce redémarrage vidant le cache mémoire
de bind qui contient toutes les requêtes DNS déjà effectuées sur Internet. Elles seront donc refaites, occasionnant trafic
réseau, délai d’attente pour les utilisateurs, etc...
On pourra dans la suite de ce document ajouter un alias portant le nom de chaque service du réseau dès que celui ci
fonctionne. Par exemple, lorsque la messagerie sera en place, il sera élégant de rajouter deux entrées de type « smtp IN
CNAME abraracourcix » et « pop IN CNAME abraracourcix », comme chez le fournisseur d’accès :), ce qui simplifie
la vie des utilisateurs et surtout permet de déplacer un service d’une machine à l’autre sans que rien ne change sur le
reste du réseau. C’est un plaisir de voir ces alias répondre au ping dès que la zone est rechargée.
Le serveur DNS secondaire, ou esclave, sera configuré très simplement ainsi (fichier /etc/bind/named.conf auquel
on enlèvera les éventuels forwarders) :
zone "mp-soa.net" in {
type slave;
file "slave/db.mp-soa";
masters {192.168.28.2; };
};
51 Si le fournisseur d’accès est Wanadoo, il est hélas requis d’utiliser ses DNS comme forwarders pour pouvoir envoyer du courrier, sauf à
installer soi même un serveur SMTP autonome comme expliqué ci après, section 7.1.
52 http ://logiciels-libres-cndp.ac-versailles.fr/debianinstall/fichiers/db.mp-soa
53 http ://logiciels-libres-cndp.ac-versailles.fr/debianinstall/fichiers/db.28.168.192
15
zone "28.168.192.in-addr.arpa" in {
type slave;
file "slave/db.28.168.192";
masters {192.168.28.2; };
};
Au redémarrage de l’esclave, le fichier de zone arrive depuis le maître dans le répertoire /var/cache/bind/slave. Des
tests avec nslookup (ou mieux dig) vérifieront que tout notre DNS est bien correct. A la fin de ce document, chaque
machine du réseau sera jointe par son nom, en particulier les machines clientes.
On donnera à chaque machine, y compris les serveurs, cette configuration dès l’installation (/etc/resolv.conf ) :
search mp-soa.net
nameserver 192.168.28.2
nameserver 192.168.28.1
6.2
Le DHCP
Packages requis : dhcp
Le Dynamic Host Configuration Protocol distribue automatiquement des adresses ip, ou plus exactement une
configuration réseau complète avec DNS et passerelle, à des machines dont la configuration est automatique. Service
extrêmement commode, DHCP évite de déclarer sur chaque machine une configuration qui peut changer : si l’adresse
du serveur DNS change, il suffit de modifier un fichier sur un serveur plutôt que devoir passer sur toutes les machines
qui peuvent être très éloignées les unes des autres, voire difficilement accessibles. La configuration de dhcpd est très
simple, ceci suffit amplement :
authoritative;
# Importante durée des baux
default-lease-time
259200;
max-lease-time
2592000;
# Nom de domaine, qui complète le DNS (directive search de /etc/resolv.conf
option domain-name
"mp-soa.net";
# Passerelle
option routers
192.168.28.254;
option domain-name-servers
192.168.28.2,192.168.28.1;
# Plage d’adresses distribuées par le serveur,
# ne pas empiéter sur les adresses fixes du DNS
subnet 192.168.28.0 netmask 255.255.255.0 {
range 192.168.28.80 192.168.28.150;
}
Le protocole DHCP ne prévoyant pas de bail d’adresses illimité dans le temps (selon la rfc213254 ), les adresses
des machines risquent donc de changer de manière inopinée, or nous avons déclaré des adresses fixes pour les stations
clientes, de manière à les retrouver facilement avec ssh et à distribuer des fichiers de manière automatisée sur tout ou
partie d’entre elles. La solution, si on ne souhaite pas renseigner fastidieusement chaque adresse sur chaque station, est
de déclarer les machines selon l’adresse matérielle (MAC) de leur carte réseau dans la configuration du serveur DHCP
de cette manière :
host majipoor { hardware ethernet 00:0F:1F:C2:BD:4B; fixed-address 192.168.28.50; }
La commande ifconfig donne l’adresse MAC d’une carte réseau. Il suffit de ne placer que ce type de déclaration dans
la configuration de dhcpd (donc omettre la section subnet ci dessus) pour que seules les machines déclarées selon leur
adresse MAC puissent obtenir une adresse ip (et ainsi introduire un début de sécurité dans les montages NFS). Cette
déclaration des adresses physiques est aussi pratique pour les ordinateurs portables dont les propriétaires souhaitent
rarement déclarer une configuration ip statique mais qui apprécieront de pouvoir retrouver leur laptop en l’appelant
par son nom, pour y copier des fichiers par scp, etc...
Enfin, il est très peu recommandé de faire tourner plus d’un serveur DHCP sur un même réseau, ce qui n’est pas
sans poser problème lors de stages où l’on enseigne le DHCP.
54 http
://www.faqs.org/rfcs/rfc2132.html
16
6.3
Limiter les téléchargemets de logiciels : un miroir Debian ou un proxy de packages
Nous sommes en train d’installer tout un réseau de machines clientes sous Debian à travers Internet au moyen de
packages mis à disposition sur des serveurs publics. Cette mise à disposition présente une limite, qui est celle de la
courtoisie : une, voire deux machines peuvent solliciter le serveur en même temps, mais pas une vingtaine provenant du
même réseau. Il faudrait donc installer les machines les unes à la suite des autres, ce qui est d’autant moins élégant qu’il
faudra à chaque fois télécharger rigoureusement les mêmes centaines de logiciels, outre que l’on triche avec l’occupation
des miroirs Debian qu’on solliciterait ainsi beaucoup plus qu’il n’est correct de le faire.
6.3.1
Un miroir Debian partiel sur le réseau
Packages requis : debmirror, rsync, apache, un DNS fonctionnel pour le virtualhost.
La première solution est de construire un miroir Debian au moins partiel. C’est la solution la plus élégante,
puisqu’elle rend le réseau presque entièrement autonome, les stations clientes n’ayant pas besoin de connexion extérieure
pour installer des logiciels ou les mettre à jour 55 . La première contrainte est de disposer d’un espace disque suffisant : il
faut prévoir une partition d’au moins 15 Go pour un miroir de Sid et Sarge (Mai 2005) ne comprenant pas les sources
des logiciels, avec en plus les packages mis à disposition par Christian Marillat (mplayer notamment). La seconde
contrainte consiste à télécharger environ 13 Go de fichiers qui seront très partiellement utilisés, ce qui se fera aisément
en moins de 24 heures à travers une connexion ADSL ; si l’on met à jour le miroir toutes les nuits, la ligne sera occupée
le temps de télécharger quelques centaines de Mo de données (quantité évidement constamment variable), soit moins
d’une demi heure sur une ligne à 2 Mbits. La dernière contrainte est de pouvoir mettre les packages à disposition des
stations du réseau au moyen d’un serveur Web ou FTP qu’il sera élégant d’appeler par un virtualhost dans le fichier
sources.list de chaque machine.
La mise en place du miroir peut se faire, dans le répertoire /var/spool/mirror, au moyen de l’utilitaire debmirror
de la manière suivante :
/usr/bin/debmirror /var/spool/mirror/debian --nosource --passive
\ -d sarge -d sid --getcontents -e rsync -r :debian/
\--host=ftp.fr.debian.org -v --ignore-release-gpg
\ --ignore-small-errors
– /var/spool/mirror/debian indique le répertoire ou se trouvera le miroir, on pourra ensuite utiliser par exemple
/var/spool/mirror/marillat pour une autre source
– –nosource indique de ne pas rapatrier les sources des logiciels
– –passive permet l’accès à un serveur FTP alors que nous sommes derrière un firewall (même si nous utilisons
rsync).
– –getcontents rapatrie la description du contenu des archives (fichiers contents.arch.gz ).
– -e rsync -r :debian/ permet de mirrorer avec rsync 56 , qui vérifie ce qui manque et ne rapatrie que les différences,
compressées, entre fichiers au lieu de tout télécharger, ce qui est infiniment plus élégant qu’un brut téléchargement
par ftp. L’option "–bwlimit=x" permet de limiter l’occupation de la ligne. -r :debian précise le répertoire racine
du serveur distant, option requise pour la méthode rsync.
– –host=ftp.debian.org indique la source du miroir.
– -v indique le mode explicite ou verbeux.
– –ignore-releases-gpg permet de poursuivre le téléchargement si la vérification des paquets par clefs GPG n’a pas
pu avoir lieu, ce qui est fréquent mais ne pose pas de problème sur un site de confiance.
– –ignore-small-errors poursuit le téléchargement si quelques fichiers sont manquants.
Pour initialiser le miroir, la commande ci dessus peut être lancée manuellement, mais la mise à jour quotidienne se
fera bien entendu avec une entrée crontab. Il faut ensuite mettre à disposition les packages du miroir sur le réseau local,
la solution la plus élégante consistant à utiliser les logiciels standard pour télécharger un fichier en http ou ftp. Nous
avons retenu Apache, et pouvons noter que les téléchargements locaux de fichiers se font très sensiblement
plus rapidement lorsque Apache sert les fichiers que lorsque apt-proxy le fait.
Il faut bien entendu une entrée DNS pour le miroir, ainsi qu’un virtual host pour le serveur web qui précisera quelle
est la racine du répertoire où trouver les packages. On ajoutera une entrée de ce type dans /etc/apache/httpd.conf :
<VirtualHost debian.mp-soa.net>
ServerAdmin [email protected]
55 Il va de soi qu’on ne mettra ce miroir à disposition du monde extérieur que si l’on a la chance de disposer d’une bande passante
en émission tout à fait considérable. La documentation pour mettre en place un miroir complet est disponible sur le site officiel :
http ://www.debian.org/mirror/ftpmirror.fr.html
56 A propos de rsync, on consultera la section 10.
17
DocumentRoot /var/spool/mirror/
ServerName debian.mp-soa.net
</VirtualHost>
Où debian.mp-soa.net constitue un alias DNS du serveur qui héberge le miroir, et où /var/spool/mirror est le
répertoire où nous téléchargeons depuis les serveurs dont nous faisons un miroir (sous répertoires debian et marillat).
On indiquera ensuite dans le sources.list des stations ces deux simples entrées :
deb http://debian.mp-soa.net/debian sid main
deb http://debian.mp-soa.net/marillat unstable main
6.3.2
Apt-proxy, proxy de packages Debian pour apt
Packages requis : apt-proxy
L’autre solution consiste en un proxy de packages. Ainsi, comme avec tout proxy, seule la première machine qui
installe un package donné provoque un téléchargement sur Internet, le proxy fournissant lui même ensuite ce dont il
dipose déjà aux autres machines qui le demandent. Ainsi, on verra les ordinateurs télécharger l’ensemble de la suite
Open Office.org en quelques secondes, le débit étant de 100 Mbits... Le logiciel permettant de faire cela s’appelle aptproxy, il est disponible sous forme de package installable par apt-get. Notons que les packages stockés dans le proxy
n’ont absolument pas besoin d’être installés sur la machine qui le fait tourner, ce même proxy pouvant héberger des
packages de différentes versions de Debian. Installons donc tout de suite ce proxy, qui sera défini comme source Debian
pour toute machine que l’on installera par la suite si l’on ne retient pas la solution du miroir Debian. Répétons que
cette solution représente à tous les niveaux un important gain de preformances (plus aucune connexion extérieure
provoquée par les stations, rapidité bien supérieure d’Apache pour les téléchargements locaux) par rapport à un proxy.
Sans surprise, le fichier /etc/apt-proxy/apt-proxy.conf contient la configuration d’apt-proxy. Deux options importantes :
– La variable APT_PROXY_CACHE détermine le répertoire de stockage des packages, pour nous /var/spool/aptproxy en raison de la partition réservée pour /var/spool. Ce répertoire, crée à la main, a besoin des permissions
suivantes :
drwxr-xr-x
8 aptproxy root
4096 Mar 9 13:53 /var/spool/apt-proxy
– La variable WGET="wget –passive-ftp", est essentielle puisque nous nous trouvons derrière un firewall ; aucun
téléchargement par ftp n’est possible sans ce classique mode passif.
On définit ensuite des backends, ou serveurs, où notre proxy s’alimentera automatiquement selon les requêtes que les
machines vont lui soumettre :
add_backend /debian/
$APT_PROXY_CACHE/debian/
http://ftp.fr.debian.org/debian/
+ftp.fr.debian.org::debian/
add_backend /marillat/
$APT_PROXY_CACHE/marillat/
ftp://ftp.nerim.net/debian-marillat/
add_backend /agnula/
$APT_PROXY_CACHE/agnula/
http://apt.agnula.org/demudi/
\
\
\
\
\
\
\
Il est très important, dans les versions 1 d’apt-proxy, de déclarer un backend sur une seule ligne. Par souci de clarté,
les divers composants d’un backend sont ici mis sur plusieurs lignes terminées par un \ qui, selon la syntaxe Unix,
indique que la ligne suivante est en fait la continuité de la première. Si cette syntaxe n’est pas respectée, le backend
ne fonctionnera pas et le proxy non plus.
Dans ses versions 2, la syntaxe de ce fichier, qui s’appelle apt-proxy-v2.conf est devenue considérablement plus
claire. Les backends se déclarent maintenant de la manière suivante :
[debian]
backends =
http://ftp.fr.debian.org/debian
[marillat]
18
backends =
ftp://ftp.nerim.net/debian-marillat/
En version 1, apt-proxy est un service d’inetd lancé à la demande, en version 2 il fonctionne de manière autonome.
Mais les deux cas, la syntaxe des sources Debian sur les clients est la même, dans le fichier /etc/apt/sources.list :
deb http://apt-proxy.mp-soa.net:9999/debian sid main
deb http://apt-proxy.mp-soa.net:9999/marillat unstable main
–
–
–
–
apt-proxy.mp-soa.net est une entrée de notre DNS
le port 9999 est le port d’apt-proxy, que personne ne change par fainéantise :)
debian et marillat sont le nom des backends déclarés dans le fichier de configuration du proxy
sid, main, unstable sont les noms des répertoires disponibles sur le serveur distant qu’il ne faut pas déclarer sur
le proxy lui même : il gérera très bien tout seul la multiplicité des répertoires sur une même source.
On pourra être amené à utiliser l’une ou l’autre de ces versions dans la mesure où la version 1 est présente en
woody, et la version 2 en sid. Si, pour une raison ou une autre, on souhaite se servir d’une station de travail allumée
en permanence comme proxy de packages, apt-get installera la version 2.
La gestion de l’occupation disque se fait de manière très transparente, apt-proxy s’occupant seul de nettoyer les
packages obsolètes (seul semble influer le paramètre spécifiant le nombre de versions concurrentes à conserver). Un
maximum de deux Go d’espace disque suffit pour de très nombreux packages sur les machines clientes.
L’utilitaire, apt-proxy-import permet de copier dans le cache du proxy l’ensemble des packages déjà téléchargés par
la même machine auparavant avec apt-get, ce qui peut représenter une taille considérable. Il faut initialiser le proxy
avant cette importation avec un simple apt-get update, le fichier sources.list pointant bien évidemment maintenant sur
le proxy.
Restent à installer quelques logiciels sur une station pour observer notre proxy initialiser son cache et se remplir,
en indiquant ce qui se passe dans son fichier de logs /var/log/apt-proxy.log. On y verra bien sûr tous les problèmes de
configuration éventuels qui expliqueront pourquoi quelque chose ne marche pas.
6.4
Squid, Proxy http et ftp
Packages requis : squid, squidguard (nombreuses dépendances)
Une implémentation complète de Squid et SquidGuard ne demandant aucune compétence Unix particulière, développée pour les établissements scolaires et mise à jour très régulièrement est disponible sous le nom de Slis 57 , « Serveur
Linux pour l’Internet Scolaire », installée dans des milliers de sites en France. Le développement est réalisé par une
communauté interne à l’Éducation Nationale et piloté par le CARMI Internet de Grenoble. Slis demande un serveur
dédié et s’insère en principe dans une politique académique : chaque Slis est relié à une base centrale de supervision
et mise à jour. Ainsi, l’administrateur local d’un Slis est rarement root sur son serveur. Cette section s’adresse aux
administrateurs de réseau qui souhaitent contrôler entièrement leur proxy http.
6.4.1
Squid
Un proxy http et ftp sert à économiser la bande passante et à fluidifier la consultation du Web ; il devrait être
installé systématiquement, même avec une bande passante importante. D’autre part, ce proxy permet de filtrer, on
pourra aussi dire censurer, un certain nombre de contenus jugés indésirables selon tel ou tel critère. Comme nous
l’avons dit à propos de la fermeture de certains ports en sortie du firewall, il ne peut être pertinent de procéder à une
telle censure sur un réseau, en particulier dans un établissement scolaire, que dans le cadre d’une charte des usages
dont les utilisateurs ont pris connaissance.
Squid58 constitue le standard quasiment absolu en matière de cache proxy. Il est livré avec un fichier de configuration
qui le fait fonctionner de manière tout à fait satisfaisante ; il est déconseillé de toucher à ce fichier (clairement
autodocumenté) sans réellement comprendre ce que l’on fait. Les risques d’altérer voire casser le disque dur du serveur
sont réels si l’on modifie inconsidérément certaines options.
Il est bon de savoir que toute modification de la configuration de Squid demande, comme tout autre service,
redémarrage, mais Squid peut être particulièrement long à s’arrêter (quelques minutes dans le pire des cas). Ceci est
« normal », ne doit pas donner lieu à inquiétude et permet d’aller consommer une boisson en attendant :).
Il y a simplement deux options à modifier :
– Dans la section ACLs (access control list), placer en haut de la liste une règle autorisant le réseau local à utiliser
le proxy :
57 http
58 http
://slis.ac-grenoble.fr/
://www.squid-cache.org/
19
acl localnet src 192.168.28.0/255.255.255.0
http_access allow localnet
– L’espace disque occupé est déclaré de la manière suivante :
cache_dir ufs /var/spool/squid/cache 1500 16 256
Seul le premier chiffre est à modifier, il précise ici une taille de 1,5 Go d’occupation disque dans /var/spool/squid
(le défaut est de 100 Mo). Les deux autres chiffres sont relatifs à l’arborescence des sous répertoires du cache,
les valeurs par défaut convenant complètement.
Un proxy possède trois modes de fonctionnement : le mode standard, sans configuration additionnelle particulière,
le mode transparent qui est une règle de firewall redirigeant tous les accès sur un port vers un autre port, rendant
superflu de déclarer le proxy dans les navigateurs mais le rendant ainsi incontournable, et le mode authentifié qui
impose aux utilisateurs de saisir leurs nom et mot de passe pour utiliser squid, permettant ainsi de consigner tous les
accès dans des journaux. Ces deux derniers modes sont exclusifs l’un de l’autre : un proxy est soit transparent, soit
authentifié.
1. Le mode « standard » : Il suffit de déclarer dans un navigateur que le proxy utilisé est proxy.mp-soa.net sur le
port 3128 et le fichier /var/spool/squid/logs/access.log indiquera toutes les requêtes http et ftp traitées.
2. Le proxy transparent : solution confortable puisqu’aucun paramétrage n’est requis sur les stations clientes. Il
suffit de faire en sorte, dans le câblage du réseau, que le routeur qui redirige vers Squid soit incontournable pour
qu’il soit matériellement impossible d’éviter le proxy et son éventuel filtrage59 .
La configuration d’un Squid transparent :
http_port 8080
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
Et la configuration du firewall :
$IPTABLES -t nat -A PREROUTING -i eth0 -s ! 192.168.28.2 -p tcp --dport 80
\ -j DNAT --to 192.168.28.2:8080
$IPTABLES -t nat -A POSTROUTING -o eth0 -s 192.168.28.0/24 -d 192.168.28.2
\-j SNAT --to 192.168.28.254
$IPTABLES -A FORWARD -s 192.168.28.0/24 -d 192.168.28.2 -p tcp
\ --dport 8080 -j ACCEPT
Le réseau local a ici pour adresse 192.168.28.0/24, le Squid tournant sur 192.168.28.2 et le routeur / Firewall
ayant l’adresse 192.168.28.254.
3. Le proxy authentifié : la solution la plus lourde, qui impose à chaque utilisateur une nouvelle saisie de son nom
et de son mot de passe, déjà saisis à l’ouverture de session, pour chaque utilisation du proxy, donc d’internet,
et à chaque lancement d’un navigateur. Cette solution est très discutable d’un point de vue juridique car elle
consigne toutes les traces et tous les accès de tout le monde de manière extrêmement précise et surtout nominale. Pour bien faire les choses, on branchera Squid sur le serveur d’authentification de cette manière (ici LDAP) :
Squid sur woody :
authenticate_program /usr/lib/squid/ldap_auth -b <base_dn>
authenticate_children 50
Squid version 2.5 (Sarge) :
auth_param basic program /usr/lib/squid/ldap_auth -b <base_dn>
auth_param basic children 50
Et ajouter dans les ACLs :
acl identification proxy_auth REQUIRED
http_access allow identification
59 une
règle de firewall pourra autoriser certaines adresses IPs à contourner Squid, pour le proxy apt par exemple
20
Le logiciel Sarg permet de générer des rapports complets indiquant qui est allé sur quel site avec quelle machine, à
quelle heure, pendant combien de temps et pour faire transiter quel volume de données. Un proxy authentifié n’a
de sens que pour exploiter de tels rapports afin de « fliquer » les utilisateurs, ce que certains peuvent souhaiter
et qu’un cadre juridique permet dans certaines limites, à propos desquelles il serait judicieux de s’informer au
préalable.
Les rapports de Sarg peuvent très vite occuper un espace disque extrèmement important, plusieurs dizaines de
Go par mois ( !), avec certaines options comme l’enregistrement d’URL longues pour suivre très précisément
toutes les connexions. Sarg crée des dizaines de milliers de petits fichiers, ce qui justifie un formatage de la
partition /var/spool avec une haute densité d’inodes (voir section 2.1).
6.4.2
SquidGuard
SquidGuard est un plugin pour Squid, qui permet de filtrer des URLs de manière extrêmement puissante à partir
de bases de données que l’on trouve facilement sur Internet, constituant autant de politiques de censure établies selon
des critères toujours discutables. L’Éducation Nationale préconise les bases de données de l’Université de Toulouse60 ,
qui sont aussi utilisées par Slis 61 .
La configuration de Squid doit être modifiée pour indiquer la présence d’un programme de redirection. Comme
précédemment avec l’authentification LDAP, on affinera le nombre de process redirecteurs lancés simultanément en
fonction du nombre de clients sur le réseau de manière à ne pas trop surcharger le serveur :
redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf
60 http
61 http
://cri.univ-tlse1.fr/documentations/cache/squidguard.html
://slis.ac-grenoble.fr/
21
redirect_children 50
Nous proposons une configuration on ne peut plus simple de SquidGuard, qui permet un filtrage très efficace d’un
type de données omniprésent sur le Web et dont les gens acceptent souvent avec plaisir de se passer : la publicité.
Outre les a priori légèrement publiphobes qui animent ce type de démarche :-), filtrer la publicité représente encore
une économie certaine de bande passante et se justifie complètement en milieu scolaire.
Notre fichier de configuration est disponible en téléchargement62 ainsi que les expressions régulières63 permettant
le filtrage de publicités. Pour activer ce filtrage, on placera le fichier regexps dans le répertoire /var/squidGuard/db
auquel on donnera les permissions suivantes :
drwxrwx---
4 root
proxy
4096 Oct
2
2003 /var/squidGuard
On redirigera enfin les requêtes filtrées vers une image quelconque disponible sur un serveur Web installé sur le
réseau.
Le site officiel64 de SquidGuard détaille de manière poussée et progressive, à la manière d’un didacticiel, la configuration de filtrages extrêmement complexes selon les heures, les utilisateurs, les machines, etc etc...
Les paramètres authenticate_children redirect-chidren demandent un ajustement en fonction du nombre de clients
susceptibles de faire des requetes simultanées et selon les capacités du serveur. Tous ces paramètres seront affinés à
l’usage, une configuration réellement optimisée de Squid permettant une économie substantielle de bande passante.
6.4.3
En conclusion
En imposant un filtrage tellement draconien et une surveillance nominale de tous les instants, on peut réellement
arriver à dissuader les gens d’utiliser ce fabuleux outil qu’est Internet. Cette possibilité existe et comble peut être
certains egos, avec de jolis graphiques générés sans effort pour parfaire cette activité de « surveillance ». Chacun étant
maître de ce qu’il fait sur un réseau dont il est responsable, insistons au moins sur l’existence d’une législation qui
encadre ce qui ressemble quelque peu à une dérive à forte connotation totalitaire...
6.5
Xntpd, serveur de temps
Packages requis : ntp, ntp-simple, ntpdate pour les clients
Un serveur de temps est indispensable sur un réseau car il fournit une source locale unique de synchronisation
horaire pour toutes les machines. Si celles ci sont à l’heure, on peut être assuré que ce qui est consigné dans les logs
de n’importe quel ordinateur se produit exactement au même moment que sur n’importe quel autre, ce qui permet
une analyse précise de tout dysfonctionnement ou incident. D’autre part, la synchronisation avec une source extérieure
de temps sera la première chose demandée en cas de problème venant de l’extérieur (spam, intrusion, etc...) par le
responsable du site distant.
Nous avons donc besoin d’un serveur de temps sur notre réseau. Il s’appelle Xntpd, son installation et sa configuration sont extrêmement simples pour l’usage basique auquel nous le destinons : dans son fichier de configuration
/etc/ntp.conf, on indiquera simplement l’adresse ip (pas le nom) du serveur distant sur lequel nous allons nous synchroniser. Des listes de serveurs Ntp publics65 sont disponibles sur le Web.
Il est à noter que Ntpd se synchronise sur sa source de temps en continu, il est impossible de lui préciser à quelle
heure il doit le faire. Une liaison permanente est donc nécessaire. Il faudra à chaque démarrage du serveur une durée
assez longue avant qu’il s’estime capable de fournir l’heure aux clients (compter une petite heure), délai avant lequel
ceux ci répondront qu’aucun serveur de temps n’a pu être trouvé. Ce délai est tout à fait normal.
Tous les clients vont venir se synchroniser au boot et au début de chaque heure sur notre serveur (alias DNS
chronos), sans connexion à l’extérieur, au moyen de cette entrée dans leur crontab :
0 * * * * /usr/sbin/ntpdate chronos > /dev/null
6.6
CUPS, serveur d’impression
Packages requis : cupsys (nombreuses dépendances), gs en cas d’absence d’imprimante PostScript.
Le Common Unix Printing System constitue aujourd’hui un standard dans le monde de l’impression sous Unix. Son
installation dans Debian est aussi simple que le reste, et il s’administre au moyen d’une interface Web très conviviale
que nous ne commentons pas. Elle écoute sur le port 631.
62 http
://logiciels-libres-cndp.ac-versailles.fr/debianinstall/fichiers/squid/squidGuard.conf
://logiciels-libres-cndp.ac-versailles.fr/debianinstall/fichiers/squid/regexps
64 http ://www.squidguard.org/
65 http ://ntp.isc.org/bin/view/Servers/WebHome
63 http
22
Ghostscript consiste en une suite d’outils et de filtres qui permettent de transformer du PostScript en langage
compréhensible par une imprimante non PostScript. Son installation n’est requise que si on ne dispose pas d’une telle
imprimante, le package Debian gs-gpl étant bien adapté. Le serveur d’impression appellera automatiquement le bon
filtre de Ghostscript selon la configuration de l’imprimante.
Les clients pourront venir s’accrocher sur le serveur CUPS au moyen des utilitaires variés de configuration des
imprimantes tels qu’ils existent aujourd’hui dans Gnome ou KDE. On veillera à ce que les fichiers temporaires soient
bien effacés du spool après traitement des tâches d’impression pour ne pas encombrer le disque, mais CUPS gère en
principe cela très bien.
7
Second serveur : l’authentification
Notre second serveur va héberger les comptes des utilisateurs et donc permettre de les authentifier lorsqu’ils veulent
utiliser un ordinateur ou une ressource du réseau. Nous étudierons la mise en place des fonctionnalités suivantes :
courriel (SMTP et pop), authentification proprement dite (NIS), partage de répertoires du serveur (NFS), mise à
disposition de documents et consultation de ceux ci dans un espace personnel (Web et FTP).
La gestion des utilisateurs, leur création, suppression et définition de leurs droits sera succintement abordée dans
la section 8.4 traitant de Webmin.
7.1
Courrier : SMTP et Pop3
Packages requis : postfix, qpopper
Le SMTP n’est pas à proprement parler un service authentifié (bien que Postfix supporte cela), mais il est plus
simple de placer ce service sur le même serveur que la base de comptes. D’autre part, pour éviter les mauvaises surprises
comme la désinstallation de la moitié des logiciels qu’on a passé du temps à configurer, il est préférable de changer le
serveur SMTP immédiatement après installation de Debian. Le serveur SMTP constitue en effet un composant central
du système d’exploitation qui peut ainsi envoyer des mails à son administrateur pour le prévenir ou l’alerter à propos
de telle ou telle chose. Il est impossible de désinstaller cette fonctionnalité, et changer ce serveur suppose de toucher
au cœur d’un système équilibré.
23
Exim, le serveur SMTP par défaut de Debian, fonctionne bien pour des besoins extrêmement modestes. Postfix
donnera satisfaction pour des besoins plus évolués et n’est pas complexe à mettre en place, au contraire de sendmail
qu’il a de plus en plus tendance à remplacer partout. Quelle que soit la solution retenue, il faut tout de même se
montrer vigilant en mettant en place ce type de service :
– Soit le serveur n’est là que pour des besoins strictement internes de formation et d’acheminement de messages
entre utilisateurs locaux, et en aucun cas il n’est ouvert sur Internet. Auquel cas on peut supposer que personne
ne va spammer...
– Soit le serveur est ouvert sur Internet. Un serveur SMTP mal configuré, qu’on appelle relai ouvert, va servir très
rapidement pour spammer, de la part de nuisibles qui recherchent activement aux quatre coins d’internet ce type
de « service ». Il faut être bien conscient que c’est l’administrateur de ce serveur qui sera tenu pour responsable
de la dizaine de milliers de messages acheminés, pourtant à son insu, en quelques instants par un inconnu ayant
utilisé le Postfix pour répandre ses nuisances. Il importe donc, par défaut, de sécuriser le plus possible un serveur
SMTP.
– Dans tous les cas de figure, root ne doit pas faire de courrier pour des raisons de sécurité. La procédure pour
rediriger ses messages figure dans les conseils généraux d’installation d’un système d’exploitation (section 2.3).
7.1.1
Postfix : installation et configuration simple
Postfix s’installe par apt-get en l’appelant tout simplement par son nom. L’interface debconf propose une pré configuration qui conviendra pour un usage basique et strictement interne. L’unique fichier /etc/postfix/main.cf renferme
l’essentiel de la configuration.
Voici un fichier simple généré par debconf :
# appending .domain is the MUA’s job.
append_dot_mydomain = no
myhostname = abraracourcix
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mp-soa.net, abraracourcix.mp-soa.net,
\abraracourcix, localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8
mailbox_command =
mailbox_size_limit = 0
recipient_delimiter = +
Deux paramètres fondamentaux sur lesquels repose Postfix :
– mynetworks : définit ce que Postfix considère comme réseaux dont il a la charge.
– mydestination : définit les domaines pour lesquels Postfix s’estime serveur de courrier (suppose une entrée MX
dans le DNS, voir 7.1.3), et pour lesquels il va accepter les messages à destination de ses utilisateurs.
Relayhost définit un serveur intermédiaire se chargeant de router les messages à notre place ; il est ici volontairement
laissé vide pour router nous mêmes nos messages sur internet, afin d’avoir la trace dans /var/log/mail.info. On peut
ainsi savoir si le serveur SMTP distant du destinataire a accepté ou non le message, et donc avoir la preuve de son
bon acheminement. Ceci est impossible avec un relai.
Vérifions tout de suite ce qui se passe lorsque quelqu’un tente d’utiliser notre serveur de courriel de l’extérieur, puis
de l’intérieur du réseau ; nous l’utilisons en ligne de commande au moyen des commandes SMTP66 . Le lecteur non
familier avec celles-ci pourra les reproduire sur le serveur SMTP de son fournisseur d’accès en attendant de s’installer
son propre serveur. Commençons par une connexion telnet depuis l’extérieur :
[yves@shalmaneser[ttypts/2]~]$ telnet mpsoa.net4.nerim.net 25
Trying 62.212.122.37...
Connected to mpsoa.net4.nerim.net.
Escape character is ’^]’.
220 abraracourcix ESMTP Postfix (Debian/GNU)
helo abraracourcix
250 abraracourcix
mail from:<[email protected]>
66 http
://www.commentcamarche.net/internet/smtp.php3
24
250 Ok
rcpt to:<[email protected]>
554 <[email protected]>:
\ Recipient address rejected: Relay access denied
quit
221 Bye
Connection closed by foreign host.
Il ne se passe pas du tout la même chose depuis la machine « arrakis » qui se trouve à l’intérieur du réseau :
arrakis% telnet abraracourcix smtp
Trying 192.168.28.6...
Connected to abraracourcix.mp-soa.net.
Escape character is ’^]’.
220 abraracourcix ESMTP Postfix (Debian/GNU)
helo abraracourcix
250 abraracourcix
mail from:[email protected]
250 Ok
rcpt to:[email protected]
250 Ok
data
354 End data with <CR><LF>.<CR><LF>
grouik
.
250 Ok: queued as 4A69A63920
quit
221 Bye
Connection closed by foreign host.
Nous avons dans les deux cas tapé exactement les mêmes commandes, ce qui prouve deux choses :
1. Par défaut, Postfix livré avec Debian est sécurisé et interdit de relayer quoi que ce soit depuis l’extérieur dans la
mesure où seule une machine locale est autorisée à poster hors de notre domaine (on vérifiera que n’importe qui
peut poster à destination d’un de nos utilisateurs locaux).
2. La ligne mynetworks contenant uniquement notre adresse de loopback, les machines du réseau local sur lequel le
serveur dispose d’une adresse ip sont considérées comme faisant implicitement partie de mynetworks puisqu’une
machine du LAN a le droit de poster. Ceci est pratique si notre serveur se trouve sur un sous réseau en adressage
privé (ici 192.168.28.0/24). Cependant, si notre routeur est serveur SMTP, comme il dispose d’une adresse ip
publique sur le réseau de notre fournisseur d’accès, nous relayons donc toute la classe d’adresses dans laquelle
nous avons obtenu une adresse à la connexion. On interdira alors toute autre machine à utiliser le serveur avec
cette ligne :
mynetworks_style = host
7.1.2
Sécuriser Postfix
Nous disposons d’un serveur SMTP qui offre le minimum vital de sécurité, nous pouvons maintenant le « blinder
» davantage puisque nous avons vu que depuis l’extérieur, n’importe qui peut adresser un message à nos utilisateurs
locaux. On ne peut interdire cela si nous souhaitons recevoir du courrier, le problème majeur du spam est là. Il est
cependant possible de prendre certaines précautions dans le fichier main.cf. Toute modification de la configuration
du serveur implique un redémarrage au moyen du script idoine de /etc/init.d, tandis qu’une simple modification des
bases de données (fichiers access, canonical, aliases, etc...) ne demande qu’une relecture par Postfix au moyen de la
commande postfix reload.
Voici les directives à placer dans le fichier main.cf :
smtpd_client_restrictions = permit_mynetworks, reject_unknown_client,
hash:/etc/postfix/Access
Cette ligne permet de « jeter » à la connexion les machines sans DNS inverse (voir section 6.1) de même que ce
qui vient des domaines définis dans le fichier /etc/postfix/access dont voici un petit exemple :
25
aol.com REJECT
hotmail.com REJECT
msn.com
REJECT 550 MSN c’est MAL
cloudyweather.net DISCARD
emailisfun.com DISCARD
std-up.com
DISCARD
L’action REJECT provoquera un bounce (renvoi à l’expéditeur par rebondissement) avec un message d’erreur plus
explicite éventuel (ici pour les utilisateurs de MSN), tandis que l’action DISCARD fera partir le message dans le trou
noir sans qu’il en reste la moindre trace ailleurs que dans les logs du serveur.
Ce fichier complété, on reconstruira la table access.db au moyen de la commande postmap /etc/postfix/access et on
fera relire cette base à Postfix par la commande postfix reload. Ce simple script67 permet de « discarder » simplement
un nouveau domaine que l’on considère comme ne produisant que du spam et dont on ne veut absolument plus lire
aucun message ni en informer l’expéditeur.
smtpd_sender_restrictions = reject_non_fqdn_sender,
reject_unknown_sender_domain, reject_maps_rbl
Nous nous occupons ici du champ From : du mail, qui permet de rejeter les expéditeurs présentant des noms de
domaines incomplets ou inconnus, ou encore inscrits dans les listes noires RBL68 . On évitera de multiplier ce type de
listes noires, en particulier la DUL qui cherche de manière un peu vaine voire stupide à stopper les messages émanant
directement d’abonnés de fournisseurs d’accès ne passant pas par les serveurs SMTP de ceux ci.
smtpd_recipient_restrictions = permit_mynetworks, check_relay_domains
N’autorise à personne d’envoyer des mails à l’extérieur hors des domaines que nous relayons, sauf nos utilisateurs
qui, eux, peuvent écrire à qui ils veulent.
smtpd_helo_required = yes
Impose la commande SMTP HELO pour initier une session.
disable_vrfy_command = yes
Inactive la commande vrfy permettant de vérifier qu’un utilisateur existe. Il est superflu de faire la même chose
pour les commandes expn (vérification de l’existence de listes) qui ne sont pas implémentées dans Postfix.
mailbox_command = /usr/bin/procmail
Il est toujours pertinent de prévoir l’utilisation de procmail, par exemple pour Spamassassin.
Il manque la réécriture de l’adresse de certains expéditeurs dans le cas ou notre domaine est strictement local, ou si
nous avons besoin de transformer « [email protected] » en « [email protected] ». C’est la fonction du fichier
/etc/postfix/canonical à déclarer ainsi dans le main.cf :
canonical_maps = hash:/etc/postfix/canonical
Ce fichier contient ce type d’entrées :
yves [email protected]
On reconstruira la base de données avec « postmap /etc/postfix/canonical » et on fera relire cette base au serveur
par la commande habituelle « postfix reload ».
67 http
://logiciels-libres-cndp.ac-versailles.fr/debianinstall/fichiers/spam
est préférable de ne jamais signaler à un spammer qu’une adresse existe d’une manière ou d’une autre, car cela valide notre existence
de son coté et fait prendre de la valeur à nos coordonnées qu’il revendra ensuite. Chacun choisira entre REJECT et DISCARD, cette
dernière réduisant les erreurs et la charge réseau.
68 http ://www.mail-abuse.com/
67 il
26
7.1.3
Un serveur de messagerie sur le réseau : envoi et réception
Envoyer des messages
La dernière manipulation permet de disposer vraiment d’un serveur de mail sur le réseau que les utilisateurs peuvent
déclarer dans un client classique de messagerie (Thunderbird, Evolution, Sylpheed, Kmail, etc...). Pour le moment,
toute tentative en ce sens se traduit par un message d’erreur, puisque notre serveur Postfix n’est déclaré nulle part
ailleurs que dans sa propre configuration (ligne mydestination), que personne ne peut deviner tant que cela ne figure
pas dans le bon service réseau : le DNS. C’est le sens de l’entrée MX à placer de cette manière dans le fichier de la
zone mp-soa.net 69 :
localhost
IN
IN
IN
NS
MX
A
andromede
10 abraracourcix
127.0.0.1
Dès que la zone est actualisée dans bind, la commande dig mx mp-soa.net renvoie enfin quelque chose de satisfaisant :
;; ANSWER SECTION:
mp-soa.net.
86400
IN
MX
10 abraracourcix.mp-soa.net.
Important : Une entrée MX ne doit jamais pointer sur une entrée CNAME, c’est à dire un alias, mais toujours
sur une entrée A. Ce n’est pas le cas, par contre, d’entrées comme smtp, pop, imap, alias qui simplifient et stabilisent
la configuration des logiciels clients.
En incrémentant le numéro de série de la zone et en la rechargeant dans Bind, nous aurons l’agréable surprise de
voir le répertoire /var/mail du serveur se remplir de fichiers au nom du login des utilisateurs vers lesquels nous faisons
des tests. Mais ces utilisateurs ne peuvent toujours pas aller chercher les messages en attente....
Recevoir des messages
Un serveur SMTP sert à transporter des messages sur un réseau, y compris internet. A ce titre, il assure deux
fonctions :
1. Envoyer un message à un MX distant
2. Jouer à son tour le rôle de MX et accepter des messages en les plaçant là où les utilisateurs peuvent venir les
chercher.
Mais en aucun cas le serveur SMTP n’est là pour servir de boite à lettres aux utilisateurs : son rôle se limite à faire
le facteur. La boîte à lettres est assurée par un serveur pop, dans notre cas le classique qpopper. Ce service, installé
par apt-get, ne demande pas de configuration particulière en raison du caractère extrêmement déterminé du protocole
pop. Il s’agit généralement d’un service d’inetd, sauf charge particulière, qui se met à fonctionner immédiatement dès
qu’un client l’interroge et s’authentifie. Mais il nous faut mettre en place un vrai serveur d’authentification, c’est la
fonction majeure du serveur que nous sommes en train de configurer.
7.2
NIS
Packages requis : Nis (le même package pour le serveur comme les clients), portmapper.
Les services principaux de notre second serveur vont permettre l’authentification et le partage de répertoires sur le
réseau. Nous utilisons le couple NIS / NFS, standard on ne peut plus classique même si les administrateurs de réseau
r n’en ont guère entendu parler.
familiers des environnements Microsoft °
NIS et NFS reposent sur le portmapper, démon qui leur attribue dynamiquement un numéro de port car ils
n’écoutent pas sur un port dédié. Son installation est automatique par le jeu des dépendances de NIS et NFS. La
commande rpcinfo permet d’obtenir les informations concernant les services du portmapper disponibles.
Network Information Service est un service d’annuaire, aussi appelé yellow pages, développé à l’origine par Sun
Microsystems ; c’est le standard historique dans le monde des stations de travail Unix. Aujourd’hui, il a tendance à
être supplanté de plus en plus par LDAP, mais demeure relativement simple et léger à mettre en place et remplit
parfaitement sa tâche d’authentification dans le cadre d’une petite structure qui, avec relativement peu d’utilisateurs,
n’a pas besoin de brancher sur un annuaire des applications complexes. Si l’authentification se fait à travers plusieurs
applications (clients Unix, Samba, un logiciel de publication de type spip, un serveur de mail, etc etc...), on considérera
69 Il est possible de déclarer un MX secondaire, recommandé en cas de coupures fréquentes ou de charge importante, avec la ligne « IN
MX 20 mail.toto.com ». Avec l’accord de son administrateur, ce serveur pourra prendre le relai en cas d’indisponibilité du MX principal.
Les chiffres n’ont pas d’importance en eux mêmes mais indiquent simplement un ordre de priorité (on aurait tout aussi bien pu indiquer
1000, 1001 et 3000 pour un éventuel autre MX).
27
LDAP avec plus d’intérêt mais nos besoins excèdent ici très peu la synchronisation d’un fichier de mots de passe Unix
avec une application réseau d’authentification pour l’ouverture de session sur les machines clientes.
Un serveur NIS maître est relativement simple à configurer si l’on suit bien rigoureusement la procédure indiquée
dans le NIS HOWTO Debian70 dont nous donnons une traduction française. Pour mémoire :
1. Déclarer dans /etc/hosts le FQDN du serveur de cette manière :
192.168.28.6
abraracourcix.mp-soa.net
abraracourcix
2. Placer le nom du domaine NIS dans /etc/defaultdomain (pour nous mp-soa.net).
3. Déclarer le serveur comme maître (master) dans /etc/default/nis
4. Déclarer le couple netmask/network dans /etc/ypserv.securenets
5. Préciser dans /var/yp/Makefile que nous fonctionnons en shadow passwords71 en dé-commentant les lignes
appropriées :
MERGE_PASSWD=true
MERGE_GROUP=true
Consulter le HOWTO à propos des différentes options, de sécurité en particulier.
6. Démarrer nis : /etc/init.d/nis start
7. Initialiser le serveur : /usr/lib/yp/ypinit -m
Après l’ajout d’un utilisateur, la commande make (invoquée dans le répertoire /var/yp où se trouve le Makefile)
permet de compiler la base de comptes et permettre à l’utilisateur de s’authentifier sur une station configurée comme
cliente NIS 72 .
On pourra vérifier le fonctionnement du serveur NIS (ici abraracourcix) depuis un ordinateur quelconque de cette
manière :
[yves@ash[ttypts/6]~/temp/tex]$ rpcinfo -p abraracourcix
program no_version protocole no_port
100000
2
tcp
111 portmapper
100000
2
udp
111 portmapper
100009
1
udp
805 yppasswdd
100004
2
udp
803 ypserv
100004
1
udp
803 ypserv
100004
2
tcp
807 ypserv
100004
1
tcp
807 ypserv
600100069
1
udp
808 ypxfrd
600100069
1
tcp
810 ypxfrd
100024
1
udp 32768 status
100024
1
tcp 32768 status
100007
2
udp
817 ypbind
100007
1
udp
817 ypbind
100007
2
tcp
820 ypbind
100007
1
tcp
820 ypbind
On consultera le NIS HOWTO73 en complément de ce HOWTO Debian.
7.3
NFS
Packages requis : nfs-kernel-server (support du serveur NFS compilé dans le kernel, sinon nfs-user-server). Le
package nfs-common, indispensable, sera installé par dépendances.
Network File System partage des répertoires sur un réseau. Il est très facile à configurer, on peut mettre en service
des failles de sécurité béantes en quelques instants avec ce protocole. Il est donc recommandé de se documenter
soigneusement à son sujet, à commencer par le NFS HOWTO74 (en français). NFS n’est de toute manière pas un
70 http
://logiciels-libres-cndp.ac-versailles.fr/debianinstall/nis.debian.howto.fr
mots de passe contenus dans le fichier /etc/password posent un gros problème : ce fichier est lisible par tout le monde même si les
mots de passe sont cryptés. La solution, assez ancienne, consiste donc à placer le mot de passe dans un fichier lisible uniquement par root,
/etc/shadow. Quasiment toutes les distributions modernes fonctionnent ainsi.
72 la section 9.2 montrera que cette configuration est tout à fait triviale par rapport à un client LDAP
73 http ://www.freenix.fr/unix/linux/HOWTO/NIS-HOWTO.html
74 http ://www.freenix.fr/unix/linux/HOWTO/NFS-HOWTO.html
71 les
28
protocole sécurisé, il suppose un minimum de confiance entre les utilisateurs qui accèdent aux données partagées.
N’importe qui pouvant être root sur une machine Unix peut opérer le montage NFS si cette machine y est autorisée
(par son adresse ip), puis prendre l’uid de n’importe quel utilisateur et ainsi s’approprier toutes ses données si /home
est exporté via NFS. Ceci, dans un centre de formation où ne viennent que des utilisateurs passagers, ne pose pas de
problème majeur. Il en ira de même dans un établissement où les utilisateurs pouvant être root sous GNU/Linux sur
leur portable sont encore relativement rares (comme dans un collège). On observe de vastes sites où les risques sont
potentiellement plus importants, comme des universités, recourir à NFS pour le home des utilisateurs, l’administrateur
réseau étant conscient de ce risque.
Précisons tout de même qu’une installation de NFS où l’on prend les précautions indiquées dans ce document et
surtout dans le HOWTO NFS ne met absolument pas en péril la sécurité du serveur lui même, mais, répétons le, la
confidentialité des données des utilisateurs.
L’exportation classique de /home permettra à chacun de retrouver l’intégralité de ses données, son courrier, les
préférences de ses logiciels, etc etc... à l’identique quelque soit l’ordinateur utilisé. Ceci est particulièrement bien adapté
au contexte de l’Éducation Nationale où les utilisateurs sont par défaut mobiles et ne possèdent pas un poste de travail
dédié : si un utilisateur bouge une icône sur son bureau de quelques centimètres, il la retrouvera à cette nouvelle
position sur un autre ordinateur, ceci n’ayant rien à voir avec des « profils errants ». Cette déportation d’un répertoire
est tout à fait transparente pour l’utilisateur, qui ne se rend pas compte que ses données ne se trouvent pas sur la
machine locale.
La configuration de NFS est très simple. On commencera par définir ce que nous exportons dans le fichier
/etc/exports :
/home
192.168.28.0/255.255.255.0(rw, root_squash)
/data/stagiaires 192.168.28.0/255.255.255.0(rw, root_squash)
On autorisera ensuite les machines du réseau local à opérer le montage dans la configuration des tcp wrappers :
/etc/hosts.deny : portmap : ALL
/etc/hosts.allow : portmap : 192.168.28.0/255.255.255.0
Redémarrer le serveur NFS, puis vérifier son fonctionnement au moyen de la commande déjà utilisée avec NIS
rpcinfo -p abraracourcix :
program vers proto
port
100000
2
tcp
111
100000
2
udp
111
100024
1
udp
964
100024
1
tcp
966
100003
2
udp
2049
100003
3
udp
2049
100021
1
udp 32768
100021
3
udp 32768
100021
4
udp 32768
100005
1
udp 32770
portmapper
portmapper
status
status
nfs
nfs
nlockmgr
nlockmgr
nlockmgr
mountd
Le montage se fait avec la comande mount abraracourcix :/data/stagiaires /mnt sur une machine cliente ; la commande showmount, sur le serveur cette fois, affichant la liste des machines ayant réalisé des montages. La section 9.2
consacrée au paramétrage des stations expliquera quelle ligne rajouter dans /etc/fstab pour automatiser le montage
du répertoire personnel importé au boot.
7.4
Samba
Packages requis : samba (nombreuses dépendances et outils conseillés).
Par hypothèse, nous exposons ici l’installation d’un réseau complet de machines clientes sous environnement Unix.
r même dans un contexte de double
Il n’est donc pas question d’envisager le cas de clients Microsoft Windows °,
amorçage des stations où deux systèmes d”exploitation seraient présents.
La documentation sur Samba, qui permet à un serveur Unix d’émuler le protocole SMB d’ouverture de session,
r NT/2000 est très
de partage de fichiers et d’imprimantes, et ainsi de se faire passer pour un serveur MS-Windows °
abondante sur Internet. D’autre part, le logiciel libre SambaEdu 375 développé par et pour l’Éducation Nationale sans
r
compétence Unix particulière de disposer d’un serveur Samba pour gérer ses clients MS-Windows °.
75 http
://www.crdp.ac-caen.fr/se3/
29
7.5
Web et FTP
Packages requis : apache, proftpd, puis php4, mysql-server et phpmyadmin selon les besoins
7.5.1
Apache
L’intérêt d’un serveur Web couplé à un serveur FTP accroché à la base de comptes du serveur est évident. L’installation d’Apache, PHP et MySQL pour mettre en place des sites dynamiques est documentée un peu partout, nous
y renvoyons 76 . Insistons simplement sur quelques fonctionnalités confortables pour les utilisateurs.
On placera dans /etc/skel un répertoire public_html avec les permissions 755 et on donnera aux répertoires personnels eux mêmes les permissions 711, de manière à ce que ce public_html puisse être consulté par tout le monde avec un
navigateur Web à l’intérieur du réseau. Chacun peut ainsi déposer des pages Web ou des documents aisés à consulter,
en particulier si l’on forme à la réalisation de contenus pour le Web. Apache intègre dans sa configuration par défaut
le répertoire ˜/public_html comme chemin du répertoire des utilisateurs. On consultera simplement ce répertoire à
l’adresse http ://serveurweb.domaine/˜utilisateur, non seulement pour voir les pages de chacun mais également en
tant que moyen simple d’accéder à un fichier partagé (cours, devoir, corrigé...).
7.5.2
ProFTPd
Nous présentons le protocole FTP dans le contexte un peu particulier d’un serveur auquel les utilisateurs accèdent
de toute manière en écriture par le biais de leur compte personnel en ouvrant une session. L’intérêt est de pouvoir
montrer, voire apprendre ce protocole comme un des modes les plus courants de mise en ligne de contenus sur un
serveur distant, que l’on retrouve ensuite sur une machine qui ne porte pas forcément le même nom par la magie des
alias DNS.
Avant de bien connaître ce protocole qui donne accès en écriture sur le disque, on prendra garde à :
– ne pas ouvrir le FTP sur le routeur, évidemment, mais à laisser ce serveur FTP en usage privé à l’intérieur du
réseau
– ne pas permettre l’usage du FTP anonyme, dont l’accès est désactivé par défaut dans la version Debian de
Proftpd (il suffit de décommenter les lignes ad-hoc du fichier de configuration).
– ne pas utiliser wu-ftpd, souvent proposé comme serveur FTP par défaut. Proftpd est un logiciel très sécurisé
au vu de son nombre quasiment nul d’alertes de sécurité depuis plusieurs années.
– Pour un usage très ponctuel, on en fera un service d’inetd plutôt que de le laisser tourner en permanence (option
claire du fichier de configuration).
Le serveur Proftpd est un logiciel très évolué, qui peut intégrer sa propre base d’utilisateurs ainsi inconnus du système
lui même. Il propose un chroot très simple à mettre en place. Le principe du chroot est de modifier la racine du système
de fichiers de manière à « emprisonner » l’utilisateur dans une « cage » qui l’empêche de se promener librement dans
le reste du disque. Si seuls les formateurs appartiennent au groupe du même nom, le chroot se met en place ainsi :
DefaultRoot ~/public_html
users,!formateurs
On pourra vérifier avec un client ftp que chaque utilisateur n’appartenant pas au groupe des formateurs se retrouve
dans le public_html de son répertoire personnel sans pouvoir remonter au dessus.
8
Services réseau complémentaires
Ces services contribuent à sécuriser le réseau, non plus comme nous l’avons vu à de nombreuses reprises contre
des intrusions extérieures, mais cette fois contre des dysfonctionnements matériels, voire des malveillances internes au
réseau. La sécurité, c’est aussi celle des données de tout un chacun et l’intégrité des systèmes comme des disques durs.
Pour les sauvegardes comme pour les onduleurs, ces logiciels demandent d’amples tests, y compris lorsque ces
services semblent fonctionner convenablement. Par exemple, il ne faudra pas craindre de couper le secteur pour vérifier
la réaction des serveurs, ou détruire un répertoire personnel pour en vérifier la bonne restauration. Le véritable premier
test se produira lorsqu’il y aura un réel « pépin » sur le réseau...
8.1
Nut : gestion des onduleurs
Packages requis : nut, nut-cgi pour obtenir de jolis graphiques.
Site officiel : http ://www.networkupstools.org/77
76 backport de PHP4 pour Woody : « deb http ://packages.dotdeb.org/ ./ ». Packet yaz (support z39.50 pour PHP), juste
pour les bibliothèques, le paquet deb est disponible sur http ://perso.dotdeb.org/misc/php4-yaz_4.3.8-8.dotdeb.1_i386.deb « deb
http ://www.indexdata.dk/debian indexdata/woody released »
77 http ://www.networkupstools.org/
30
Network UPS tool permet de surveiller l’alimentation électrique d’un onduleur par le port série de l’ordinateur
; il provoque l’extinction propre du système lorsque la panne de courant a été assez longue pour faire descendre la
charge des batteries à un état critique ; ainsi les partitions des disques durs sont démontées normalement et l’ensemble
de leur contenu, système comme données, ne court aucun risque. En effet, une rupture brutale d’alimentation d’un
ordinateur peut avoir des conséquences catastrophiques sur le contenu des disques : onduler un serveur ne suffit pas,
encore faut-il surveiller cet onduleur avec un logiciel qui sait ce qu’est une rupture d’alimentation et comment y faire
face.
Nut comporte également une partie cliente qui lui permet de fonctionner en réseau, c’est à dire interroger par
TCP/IP un autre serveur qui surveille par sa liaison série l’onduleur, qui ne dispose que d’un seul port pour cela. Ce
ou ces serveurs esclaves tomberont les premiers, avant le maître, en cas de baisse critique de l’alimentation, le maître
attendant la chute des esclaves avant de s’éteindre. La richesse fonctionnelle de Nut en fait un des logiciels les plus
puissants pour ce type d’usage.
On respectera trois démarches de bon sens lors de l’installation d’onduleurs et de leur surveillance :
78
1. Tout le matériel actif doit être ondulé, en particulier les switchs qui relient les serveurs partageant le même
onduleur. Comme l’esclave surveille l’onduleur du maître par réseau, cette surveillance marchera moins bien lors
d’une panne si le switch n’est pas ondulé :). Si l’esclave surveille le maître en l’appelant par son nom et non par
son adresse, on veillera à la disponibilité du service DNS en cas de coupure, et donc faire tourner celui ci sur le
serveur maître.
2. Dans la configuration du logiciel de surveillance, on laissera les batteries de l’onduleur se vider jusqu’à une charge
critique avant de faire tomber le serveur, au lieu de le faire à la moindre coupure : c’est la fonction même d’un
onduleur.
3. De nombreux tests seront nécessaires pour vérifier que tout fonctionne bien, en particulier le retour des serveurs
en fonction suite au rétablissement de l’alimentation.
8.1.1
Configuration de nut en mode maître
Nut se comporte en mode client / serveur même sur un seul ordinateur : le serveur s’appelle upsd, c’est lui qui
obtient les informations sur l’état des batteries par le port série. Le client, lui, s’appelle upsmon, il s’authentifie auprès
d’upsd, surveille l’onduleur et provoque l’arrêt du serveur, puis de l’onduleur lui même.
La version 0.47 de Debian Woody est maintenant obsolète et ne permet pas de communiquer avec les versions
ultérieures, 1.4 et 2.0 (qui sont par contre compatibles entre elles). Pour un serveur en Woody, on préférera la version
mise à disposition par MGE79 , en ajoutant dans le fichier /etc/apt/sources.list, pour PC i386 :
deb http://www.logic.at/debian/ i386/
« Apt-get install nut » doit ainsi installer une version 1.4 ou supérieure. Pour Sarge ou Sid, la version présente dans
Debian convient, mais on pourra se référer au site officiel80 qui propose des packages à travers une source spécifique.
Voici la configuration de Nut dans sa version 1.4. On considère que sur le système maître, un câble série relie le
serveur, port ttyS0 ou COM1, à un onduleur de marque APC, modèle Smart UPS 700.
En principe, un répertoire /etc/nut a été crée vide de toute contenu. On copiera l’ensemble des fichiers de
/usr/share/doc/nut/exemples dans /etc/nut en décompressant ceux qui en ont besoin, typiquement upsmon.conf.
On dispose ainsi de quatre fichiers :
– ups.conf : l’onduleur lui même
– upsd.conf : le démon qui surveille l’onduleur par le câble
– upsd.users : les utilisateurs du démon et leur authentification
– upsmon.conf : le client qui, une fois authentifié, provoquera les actions sur le serveur et l’onduleur en fonction
des informations que lui communique le démon
Le fichier README.Debian fourni avec le documentation explique très clairement, en anglais, la configuration
complète de tout le système. En voici un résumé.
1. Tester, sous root, le bon fonctionnement du pilote de l’onduleur à travers le câble série. Les pilotes se trouvent
dans /lib/nut, on pourra faire le test de cette manière :
[root@andromede[ttypts/1]# /lib/nut/apcsmart /dev/ttyS0
Network UPS Tools - APC Smart protocol driver 0.60 (0.45.5)
Detected SMART-UPS 700 [QS0237332128] on /dev/ttyS0 (level 3)
78 l’USB
est implémenté dans les dernières versions mais risque de poser des problèmes de compatibilité.
://eu1.networkupstools.org/packages.html
80 http ://eu1.networkupstools.org/
79 http
31
2. L’onduleur répond parfaitement, nous pouvons donc donner les droits au groupe nut sur le port série de cette
manière :
crw-rw----
1 root
nut
4,
64 Mar 28 20:01 /dev/ttyS0
3. Commençons par déclarer notre onduleur dans ups.conf avec cette section :
[myups]
driver = apcsmart
port = /dev/ttyS0
4. Le fichier /etc/nut/upsd.conf permet de définir les listes de contrôle d’accès (ACLs). Nous commençons donc
par les définir, en leur donnant un nom : localhost pour le loopback, seul pour le moment.
ACL all 0.0.0.0/0
ACL localhost 127.0.0.1/32
Puis nous allons autoriser un accès complet pour la machine locale :
ACCESS grant monitor localhost
ACCESS deny all all
Dans nut version 2, upsd.conf demande ceci, nettement plus simple :
ACCEPT localhost
REJECT all
5. Il faut maintenant déclarer des utilisateurs du daemon upsd dans le fichier upsd.users, et leur donner des permissions. Nous allons créer l’utilisateur admin :
[admin]
password = monpassword
allowfrom = localhost
actions = SET FSD
instcmds = ALL
upsmon master
Cet utilisateur a le droit de tout faire sur l’onduleur, y compris lui envoyer des commandes. On notera la ligne
upsmon master qui est très mal indiquée dans la documentation du logiciel, bien qu’elle soit absolument requise
pour que le système fonctionne. La ligne allowfrom n’indique pas le nom des machines autorisées pour
admin, mais celui des ACLs du fichier upsd.conf.
6. Nous pouvons maintenant configurer le logiciel client qui va interroger le démon et déclencher des actions sur le
serveur en cas de panne de courant. On indiquera dans upsmon.conf ceci :
MONITOR myups@localhost 1 admin monpassword master
7. Tous les fichiers de configuration doivent avoir les permissions 600 et appartenir à nut, groupe root.
8. On s’assurera enfin de la présence d’un fichier /etc/default/nut, où déclarer le démarrage du client et du serveur.
On peut passer très longtemps à essayer de démarrer le service s’il est déclaré off dans ce fichier :).
8.1.2
Démarrage du service et test de son bon fonctionnement
On peut maintenant démarrer nut et observer dans les logs le démarrage du serveur et l’authentification immédiate
du client :
May
May
May
May
May
May
31
31
31
31
31
31
12:56:11
12:56:11
12:56:12
12:56:12
12:56:12
12:56:12
andromede
andromede
andromede
andromede
andromede
andromede
apcsmart[31071]: Startup successful
upsd[31072]: Connected to UPS [myups]: apcsmart-ttyS0
upsd[31073]: Startup successful
upsmon[31075]: Startup successful
upsd[31073]: Connection from 127.0.0.1
upsd[31073]: Client [email protected] logged into UPS [myups]
Puis on obtiendra au moyen de la commande upsc localhost des informations sur l’état de l’onduleur, qui est ici à
100 % de sa charge et dont les batteries datent du 14 Septembre 2002 :
32
[root@andromede[ttypts/1]# upsc localhost
host: localhost
MODEL: SMART-UPS 700
SERIAL: QS0237332128
STATUS: OL
UTILITY: 237.9
BATTPCT: 100.0
ACFREQ: 50.00
LOADPCT: 031.2
BATTVOLT: 27.74
OUTVOLT: 237.9
UPSTEMP: 041.8
UPSIDENT: UPS_IDEN
LOWXFER: 196
HIGHXFER: 253
WAKEDELAY: 000
LINESENS: H
GRACEDELAY: 020
RTHRESH: 00
ALRMDEL: 0
BATTDATE: 09/14/02
MFR: APC
8.1.3
Configuration d’un client sur le réseau
Nous désirons maintenant faire en sorte qu’un second ordinateur branché sur le même onduleur en surveille également l’état des batteries de manière à pouvoir s’éteindre lui aussi proprement en cas de coupure, bien que ne pouvant
surveiller l’état de son alimentation par le port série. Il s’agit donc d’un ordinateur esclave du premier, le maître.
Sur le maître, commençons par ajouter une ACL autorisant l’adresse IP de notre esclave dans le fichier upsd.conf :
ACL esclave 192.168.28.1/32
ACCESS grant monitor esclave
( « ACCEPT localhost esclave », toutes les ACLs sur la même ligne, dans Nut version 2).
Nous ajoutons ensuite un utilisateur d’upsd dans le fichier upsd.users, à la suite d’admin :
[kirk]
password = spock
allowfrom = esclave
upsmon slave
(répétons que allowfrom pointe sur les ACLs ci dessus et non sur un nom de machine).
Sur l’esclave :
– Copier et décompresser le fichier de configuration d’upsmon, qui se trouve dans /usr/share/doc/nut/exemples,
dans /etc/nut.
– Déclarer dans ce fichier le nom de l’onduleur (myups), la machine sur laquelle upsd l’observe (andromede), le
nombre d’onduleurs à surveiller (1), le nom d’utilisateur (kirk), le mot de passe permettant de s’authentifier
auprès de cet upsd (spock) et le statut (slave) de notre client :
MONITOR myups@andromede 1 kirk spock slave
– Ne pas oublier dans /etc/default/nut de bien démarrer upsmon, et de ne pas démarrer upsd ; donner les permissions 600 au fichier de configuration d’upsmon, qui doit appartenir à nut, groupe root.
Redémarrer nut sur le maître et sur l’eslave ; les logs du maître doivent indiquer une connexion réussie depuis
l’adresse IP de l’esclave, depuis lequel il est possible de consulter l’état des batteries par la commande « upsc
myups@andromede ».
Des configurations plus évoluées sont documentées (on consultera en particulier la FAQ), des tests s’imposent
afin de s’assurer que tout se passe normalement et que les serveurs tombent, puis remontent en cas de coupure
prolongée et retour du courant. L’arrêt du serveur est assuré par le script /etc/init.d/halt qui contient la commande
33
« ups-monitor poweroff» ; cette commande provoque une extinction de l’onduleur lui même, temporisée après l’arrêt
du serveur 81 .
En effet, le moment le plus critique est celui ou les serveurs sont tombés mais non éteints électriquement, et
l’onduleur toujours allumé puisqu’il reste un peu de courant dans les batteries. Si à ce moment précis, où l’onduleur
fonctionne encore, le courant revient, les serveurs ne redémarreront jamais tout seuls puisqu’aucun évènement électrique
ne se sera produit. Ils resteront allumés en position d’arrêt. Il faut donc que l’onduleur lui même s’éteigne, même et
surtout s’il est de nouveau alimenté avant vidage complet des batteries, de manière à ce que le retour du
secteur provoque un redémarrage de tout le système, y compris si ce retour a précédé l’arrêt de l’onduleur 82 .
Enfin, dans la plupart des cas, un paramètre du BIOS des ordinateurs détermine ce que doit faire la carte mère lors
du retour de l’alimentation : laisser l’ordinateur éteint, le rallumer ou le remettre dans le dernier état où il se trouvait
avant la coupure ; on mettra un serveur sur la position « always on » sauf cas très particulier.
Les fichiers de configuration de nut v1.483 sont joints à cet article.
8.2
Amanda : sauvegarde en réseau sur bande
Packages requis : dump, amanda-server (sur le serveur), amanda-client (sur toute machine faisant l’objet d’une
sauvegarde)
Au contraire du RAID qui assure une redondance et synchronise immédiatement toute modification d’un fichier
sur plusieurs disques, un système de sauvegarde permet en plus de retrouver certaines données ayant été effacées ou
modifiées par erreur. Sauvegarder, c’est ainsi conserver les états antérieurs d’un travail en plusieurs versions. Restaurer,
c’est se livrer à une sorte de « voyage dans le temps » avec les bandes magnétiques 84 . On disposera au mieux d’un
jeu de bandes pour chaque jour de la semaine, puis d’un jeu de bandes pour chaque semaine, ensuite pour chaque
mois, etc etc... Le volume de sauvegarde devenant vite important, les logiciels évolués procèdent à une sauvegarde dite
incrémentale où seules les modifications des fichiers sont sauvegardées par rapport à une certaine date et un certain
volume.
Un placard blindé :) pour ranger les (nombreuses) bandes, situé loin du local serveur en cas de cambriolage,
incendie, inondation... dépasse largement nos besoins ; mais on déterminera soigneusement le rythme des sauvegardes
et le nombre de bandes en fonction de cette exigence : offrir à nos utilisateurs la possibilité de retrouver leurs données,
altérées ou effacées par maladresse. Nous avons retenu 4 bandes avec une fréquence de sauvegarde hebdomadaire.
Automatic Maryland Advanced Network Disk Archiver est un logiciel libre, serveur de sauvegarde de partitions
de disques durs sur bande magnétique (de type DAT) fonctionnant en réseau, supportant un robot de manipulation
automatique des bandes et un nombre très important de systèmes de fichiers. Amanda ne requiert pas un espace disque
important, mais deux ou trois Go seront bienvenus comme zone de stockage temporaire. Enfin, la précaution la plus
élémentaire pour une sauvegarde consiste à ne jamais sauvegarder des données sur le serveur qui les abrite,
d’où la sauvegarde en réseau.
La configuration d’Amanda n’est pas cauchemardesque :). Schématiquement, elle comprend :
– un fichier par type de sauvegarde (un seul dans notre cas) : amanda.conf
– un fichier très bref définissant les disques à sauvegarder sur le réseau : disklist
– un jeu de fichiers autorisant les diverses machines, clientes et serveurs, à se connecter entre elles pour échanger
leurs données : .amandahosts
Il n’existe à notre connaissance aucune interface graphique à Amanda.
8.2.1
Configuration d’une sauvegarde : le serveur
Sur le serveur, on installe les packages dump et amanda-server qui descend le package amanda-common. Un
utilisateur backup est ajouté au système, propriétaire des fichiers de configuration et du périphérique lecteur de bandes ;
backup lancera les taches de sauvegarde via cron. Attention, ce sera root qui procédera aux restaurations, lancées depuis
les clients avec amrecover, et non backup dont ce n’est pas le travail et qui n’aura pas les droits pour le faire. Toutefois,
on fera toutes les manipulations de cette section sous l’utilisateur backup et non root. Comme le répertoire /usr/sbin,
qui n’est pas dans le PATH de backup, contient toutes les commandes d’Amanda (amcheck, amdump, amlabel, etc..),
il est impossible que backup trouve les commandes qu’il est appelé à utiliser constamment. Pour y remédier, on placera
la ligne « export PATH=$PATH :/usr/sbin » dans le fichier .profile du home de backup (/var/backups) .
81 La documentation du driver, pour notre exemple apcsmart, précise les options des commandes que l’on peut envoyer à l’onduleur, dont
le délai de temporisation de sa propre extinction puisqu’il faut laisser au serveur le temps de s’éteindre proprement ! Cette documentation
est accessible sous forme de page de man, mais normalement la configuration par défaut dispense de rentrer dans de tels détails.
82 Quelques tests peuvent être nécessaires pour bien comprendre le problème, ils auront généralement lieu en temps réel, lors de la première
panne, un dimanche matin la plupart du temps :).
83 http ://logiciels-libres-cndp.ac-versailles.fr/debianinstall/fichiers/nut
84 Ce n’est pas un hasard si une des solutions propriétaires les plus connues de sauvegarde s’appelle time navigator.
34
Commençons par vérifier le fonctionnement du matériel et les droits de l’utilisateur backup Celui ci doit faire partie
des groupes disk, tape et backup. Le périphérique de sauvagarde (logiquement un DAT SCSI) s’appelle dev/st0, mais
le périphérique /dev/nst0 sera impérativement utilisé par défaut dans les sauvegardes d’Amanda (il ne rembobine pas
la bande). Ces deux périphériques doivent avoir les permissions suivantes :
crw-rw---crw-rw----
1 root
1 root
tape
tape
9,
0 Mar 14
9, 128 Mar 14
2002 /dev/st0
2002 /dev/nst0
Deux commandes simples permettent de vérifier que backup peut faire fonctionner le lecteur DAT : « mt -f /dev/st0
rewind » et « mt -f /dev/st0 eject ».
Nous allons mettre en place une sauvegarde incrémentale hebdomadaire qui tourne sur 4 bandes, nous offrant
une antériorité d’un mois ; nous l’appellerons config, et la placerons sur le premier serveur où nous avons réservé une
partition pour /var/spool. Nous sauvegarderons les données présentes sur deux machines du réseau, le serveur de
fichiers (pour les données des utilisateurs) et la machine du bureau (pour la gestion du centre de formation), tous les
Vendredis soirs.
Les fichiers définissant la sauvegarde se trouvent dans /etc/amanda/config (où le répertoire config désigne le nom
de notre sauvegarde, que nous allons utiliser en permanence). Créons dans /etc/amanda un répertoire config à coté
de celui qui a été crée à l’installation, dont les permissions sont les suivantes :
drwxr-xr-x
2 backup
backup
4096 Mar 18 20:30 config
Copions dans ce répertoire le contenu du répertoire DailySet1, configuration de sauvegarde par défaut :
– amanda.conf, la quasi totalité de la configuration de la sauvegarde
– disklist, la liste des disques des machines à sauvegarder.
Le fichier /etc/amanda/config/amanda.conf , clairement autodocumenté en anglais, définit notre sauvegarde : il faut en renseigner bien rigoureusement chaque ligne. Nous indiquerons à chaque fois qu’un certain nombre
de répertoires sont à créer manuellement ; il sera judicieux de créer ces répertoires au moment où on les déclare dans
le fichier de manière à ne pas les oublier par la suite.
org "Sauvegardes"
mailto "root"
# your organization name for reports
# space separated list of operators at your site
Pour les rapports envoyés par mail à l’issue de chaque sauvegarde.
dumpuser "backup"
# the user to run dumps under
Clair de soi.
inparallel 4
netusage 95000
# maximum dumpers that will run in parallel
# maximum net bandwidth for Amanda, in KB per sec
A ajuster selon la puissance du serveur et la bande passante du réseau en tenant compte de son occupation à
l’heure où les sauvegardes sont réalisées, d’où l’intérêt de les faire la nuit en utilisant la totalité des 100 Mbits permis
par le switch.
dumpcycle 4 weeks
# the number of days in the normal dump cycle
Durée d’un cycle de sauvegarde
tapecycle 4 tapes
# the number of tapes in rotation
Nombre de bandes en rotation pendant ce cycle.
bumpsize 20 MB
bumpdays
1
bumpmult
4
# minimum savings (threshold) to bump level 1 -> 2
# minimum days at each level
# threshold = bumpsize * (level-1)**bumpmult
L’incrémentalité de la sauvegarde, à affiner à l’usage selon le volume de données sauvegardées et la capacité des
bandes.
#tpchanger "no-changer" # the tape-changer glue script, see TAPE.CHANGERS
35
Tout ce qui parle de « tape changer » concerne un système de robot qui change automatiquement les bandes, qui
peuvent être plusieurs pour une même sauvegarde. Ce sont des systèmes très haut de gamme, nous n’avons qu’un bête
lecteur DAT SCSI.
tapedev "/dev/nst0"
# Linux @ tuck, important: norewinding
Le périphérique de sauvegarde, il est essentiel de ne pas rembobiner la bande. Le périphérique /dev/st0 ne convient
donc pas.
tapetype HP-DDS-4
# what kind of tape it is (see tapetypes below)
Le type de bande utilisée, tel que nous le définirons ci dessous (type HP-DDS-4).
labelstr "^config[0-9][0-9]*$"
# label constraint regex: all tapes must match
Le nom que nous donnerons à nos bandes, qui s’appelleront impérativement config01, config02, etc...
diskdir "/var/spool/backup"
# where the holding disk is
Le répertoire du disque dur que nous utiliserons comme zone de stockage temporaire pendant la sauvegarde, avant
l’écriture proprement dite sur la bande. Deux lignes plus bas, on remarque que plusieurs disques de ce type peuvent
être définis.
disksize 2000 MB
# how much space can we use on it
La quantité d’espace disque utilisable pour ce répertoire qui n’est pas nécessairement une partition, on peut le
partager avec d’autres spools. Ce répertoire devra être crée à la main avec les permissions suivantes :
drwxr-xr-x
3 backup
backup
4096 Mar 25 20:30 /var/spool/backup
infofile "/data/amanda/curinfo" # database filename
logfile "/data/amanda/config/log"
# log filename
L’emplacement de la base de données des fichiers sauvegardés, leur historique, etc.
indexdir "/data/amanda/config/index"
L’emplacement des fichiers d’index (la liste de ce qui est sauvegardé).
Quelques Mo sont nécessaires pour cette base de données, il n’est pas pertinent en cas d’occupation disque importante de placer cela à coté des fichiers de configuration. Ce répertoire, crée à la main, a ces permissions :
drwxrwx---
5 backup
backup
4096 May 13
2004 /data/amanda
On créera ensuite, dans ce répertoire, un sous répertoire qui portera le nom de notre sauvegarde (config). L’arborescence de ce sous répertoire sera, elle, créée automatiquement lors de la première sauvegarde, avec un message
d’avertissement lors de la vérification de la configuration (commande amcheck ).
Cette base de données est essentielle au fonctionnement d’Amanda, puisqu’elle contient l’index des fichiers qui
ont été sauvegardés et la bande où ils se trouvent. C’est la raison pour laquelle il ne faut jamais sauvegarder un
disque sur lui même, de manière à préserver cette base de données en cas de crash disque. La documentation
indique toutefois une procédure de restauration, indiquée comme particulièrement chaude :), même en ce cas (cf.
/usr/share/doc/packages/amanda-common/RESTORE.gz ).
Vient ensuite une longue liste de définitions de types de bandes magnétiques, il est fort probable que cette liste ne
comprendra pas celles qui ont été achetées avec le lecteur DAT :). La commande tapetype, au traitement extrèmement
long, permet de générer une description de bande pour Amanda. On trouve facilement avec Google une définition
des caractéristiques de nos bandes fournie par d’autres utilisateurs. Le rapport reçu par mail à l’issue de la première
sauvegarde permettra de vérifier la conformité de la définition des bandes dans Amanda avec leur capacité réelle.
Voici une entrée pour les bandes de notre lecteur DAT trouvée en quelques instants sur Internet :
define tapetype HP-DDS-4 {
length 17021 mbytes
filemark 403 kbytes
speed 1578 kps
}
36
Vient enfin la définition proprement dite de la sauvegarde que nous allons réaliser. L’auto documentation du
fichier expose les différentes options avec un nombre conséquent d’exemples. Nous allons définir un nouveau type de
sauvegarde que nous appellerons « hebdo » :
define dumptype hebdo {
compress-best
priority high
index
}
Nous compressons le mieux possible puisque nous disposons du temps pour le faire (il y a peu de stagiaires ou
d’élèves la nuit :) ) ; l’option index précise que nous voulons que la liste des fichiers sauvegardés soit indexée. Enfin
la priorité est définie comme haute, elle pourrait être mise à « low » ou « medium » par rapport à d’autres disques
que nous sauvegarderions en même temps, mais avec un autre type de sauvegarde car ces disques seraient jugés plus
importants. La différence est que plus une sauvegarde est importante, plus elle sera prioritaire dans l’occupation de
l’espace disque temporaire, ce qui est très utile en mode dégradé, lorsque le lecteur n’est pas disponible (vraisemblablement parce qu’on a oublié de changer la bande) et que tout va rester sur le disque en attendant un dump définitif
(commande amflush).
Le fichier /etc/amanda/config/disklist contient la liste des disques85 que nous désirons sauvegarder, le fichier
documente lui même abondamment le type de partitions prises en charge, y compris vfat. La syntaxe est simple : on
indique sur une ligne le nom de la machine, la partition à sauvegarder et le type de sauvegarde tel que défini en dernier
dans le fichier amanda.conf. Pour nous :
abraracourcix
abraracourcix
ash
hda5
sda4
sdb1
hebdo
hebdo
hebdo
C’est tout ! :)
Les fichiers de configuration peuvent être consultés à cette adresse86 .
8.2.2
Configuration d’une sauvegarde : les clients
Amandad, logiciel client du serveur Amanda, est lancé automatiquement sur chaque machine cliente (celles dont on
désire sauvegarder une partition) par le serveur en tant que service d’inetd dès que démarre la sauvegarde. L’installation
du package amanda-client a placé cette ligne dans le fichier etc/inetd.conf :
amanda dgram udp wait backup /usr/sbin/tcpd /usr/lib/amanda/amandad
Il faut cependant que chaque machine, serveur comme cliente, soit autorisée à communiquer avec les autres pendant
la sauvegarde mais également pendant la restauration. Ces autorisations sont définies dans les fichiers .amandahosts situés dans le répertoire personnel de l’utilisateur backup (/var/backups) sur chaque machine. La syntaxe de
ces fichiers peut donner lieu à un certain énervement :), et requiert de bien comprendre qui accède à quelle machine,
en tant que root ou en tant que backup (rappellons que root seul peut restaurer mais ne doit pas sauvegarder).
Sur le serveur de sauvegarde andromede, cette configuration est requise si nous sauvegardons les machines abraracourcix et ash, puisque backup réalise la sauvegarde et root assure la restauration :
localhost backup
abraracourcix.mp-soa.net root
abraracourcix.mp-soa.net backup
ash.mp-soa.net root
ash.mp-soa.net backup
Sur une machine cliente, il suffira d’indiquer :
localhost backup
andromede.mp-soa.net backup
85 plus
86 http
exactement des partitions
://logiciels-libres-cndp.ac-versailles.fr/debianinstall/fichiers/amanda
37
8.2.3
La première sauvegarde et restauration
Nous pouvons formater une bande qui va nous servir de test pour la sauvegarde « config », que nous allons appeler
« config01 », au moyen de la commande amlabel config config01. Si cette bande a déjà été utilisée dans la même
sauvegarde, on pourra forcer son effacement au moyen de l’option -f.
La commande amcheck config, lancée en tant que backup sur le serveur, nous permet de tester la validité de la
sauvegarde que nous avons appelée « config ». En voici une sortie correcte :
andromede:~$ amcheck config
Amanda Tape Server Host Check
----------------------------Holding disk /data/backup: 2963940 KB disk space available, that’s plenty
NOTE: skipping tape-writable test
Tape config01 label ok
Server check took 8.637 seconds
Amanda Backup Client Hosts Check
-------------------------------Client check: 2 hosts checked in 0.101 seconds, 0 problems found
Tous les problèmes seront indiqués très clairement : bande absente, non valide, machine indisponible ou avec laquelle
il est impossible de communiquer, etc etc... La documentation du package amanda-common contient une FAQ qui
détaille les problèmes les plus courants (en particulier une entrée d’inetd.conf incorrecte ou un fichier .amandahosts
mal renseigné). Les logiciels composant Amanda créent des fichiers temporaires portant leurs noms dans /tmp, ils
apportent une aide majeure pour debugguer.
Lorsque tout est correct, il suffit de lancer une sauvegarde de test avec la commande « amdump config ». On voit le
système rendre tout de suite la main, les démons amandad se lancer sur les machines clientes et appeler les utilitaires
de backup, de compression et d’envoi par réseau de la sauvegarde. Sur le serveur, le répertoire /var/spool/backup
se remplit de fichiers temporaires qui grossisent en taille, puis vont être écrits sur la bande. Lorsque tout est fini,
l’utilisateur défini dans la sauvegarde reçoit un mail qui l’informe du déroulement des opérations et des statistiques de
la sauvegarde, en particulier les pourcentages d’occupation des bandes et les taux de compression. Le message précise
en premier lieu le nom de la prochaine bande qu’attend Amanda.
Nous pouvons donc tester le fonctionnement de la restauration avec l’utilitaire amrecover.
Il y a deux utilitaires de restauration : amrestore permet de restaurer l’ensemble d’une partition qui a été détruite ou
altérée, ce que le RAID est là pour éviter. D’autre part l’utilitaire amrecover permet de restaurer simplement certains
fichiers qui ont été perdus ou altérés par maladresse. C’est la raison pour laquelle nous faisons des sauvegardes.
Amrecover sera lancé en tant que root (et non backup) sur la machine cliente, à la racine du système de
fichiers où se trouve ce que l’on veut restaurer. Imaginons que nous fassions un test sur le fichier galantine.sxi,
effacé par mégarde du répertoire « /home/formateurs » sur la machine abraracourcix. Nous nous loggons donc en root
sur notre serveur de fichiers et nous nous plaçons dans le répertoire /home, puisque c’est cette partition que nous
avons sauvegardée (voir les définitions placées dans le fichier disklist). Si on lançait amrecover dans le home de root
pour restaurer des fichiers de /home, les fichiers restaurés apparaîtraient dans le home de root où serait recréée toute
l’arborescence des fichiers restaurés. Amrecover prévient tout de suite très clairement de ce genre d’erreur :
WARNING: not on root of selected filesystem, check man-page!
La documentation d’amrecover précise comment le lancer, il vaut mieux lui préciser, en plus du nom de la sauvegarde, comment s’appellent le serveur, le serveur de bandes et le périphérique DAT :
[root@abraracourcix[ttypts/0]/home]# amrecover -C config
\ -s andromede -t andromede -d /dev/nst0
AMRECOVER Version 2.4.2p2. Contacting server on andromede ...
220 andromede AMANDA index server (2.4.2p2) ready.
200 Access OK
Setting restore date to today (2005-03-28)
200 Working date set to 2005-03-28.
200 Config set to config.
200 Dump host set to abraracourcix.
$CWD ’/home’ is on disk ’sda4’ mounted at ’/home’.
38
200 Disk set to sda4.
/home
amrecover>
Le prompt amrecover> offre un certain nombre de commandes listées par help. L’équivalent des classiques pwd, ls
et cd nous permettent de nous déplacer et de localiser le fichier que nous cherchons de cette manière :
amrecover> pwd
/home
amrecover> cd formateurs
/home/formateurs
amrecover> ls
2005-03-18 .
2005-03-18 galantine.sxi
2005-03-18 savNT/
2005-03-18 softs/
Nous retrouvons l’arborescence familière de notre système de fichiers, « galantine.sxi » est bien présent. Nous allons
l’ajouter, pour extraction de la bande et restauration sur le disque :
amrecover> add galantine.sxi
Added /formateurs/galantine.sxi
Il est alors possible de parcourir encore le système de fichiers, voire d’en changer, et d’ajouter avec add d’autres
contenus à restaurer. La commande extract permet de commencer à restaurer :
amrecover> extract
Extracting files using tape drive /dev/nst0 on host andromede.
The following tapes are needed: config03
Restoring files into directory /home
Continue? [Y/n]:
La ou les bandes nécessaires sont indiquées clairement, il faudra les introduire successivement dans le lecteur. La
restauration démarre, elle n’est pas spécialement rapide car le DAT va devoir relire les bandes. Cela peut prendre
largement plus d’une demi heure pour une restauration importante.
8.2.4
Paramétrage de la sauvegarde hebdomadaire
Dès que les tests ont été concluants, on peut mettre en place la procédure hebdomadaire définitive, c’est le dernier
point de la FAQ. Il faut effacer à la main le contenu du répertoire « holding disk » (normalement, il est vidé automatiquement) et surtout la base de données des fichiers sauvegardées (/data/amanda). Reste à formater les bandes au
moyen de amlabel, que nous appellerons config01, config02, config03 et config04. Deux entrées de crontab suffiront à
prévenir l’administrateur d’une erreur le Vendredi à midi, puis à démarrer la sauvegarde le Vendredi soir à 20 heures
30 :
0 12 * * 5 /usr/sbin/amcheck -m config > /dev/null
30 20 * * 5 /usr/sbin/amdump config > /dev/null
Amanda propose d’autres utilitaires, par exemple amrmtape qui efface tout le contenu d’une bande de la base de
données ; toutes ces commandes sont trouvées par complétion sur les lettres am, tout simplement. Leur documentation,
très simple, brève et intelligible, est en anglais.
Mentionnons la commande amflush : elle poursuit une sauvegarde inachevée car la bande requise n’était pas dans
le lecteur, surement parce qu’on avait oublié de la changer. L’administrateur aura été prévenu par mail de cet échec.
L’appel d’amflush vide le répertoire de stockage temporaire en le passant sur la bande, puis un mail est envoyé à
l’administrateur.
39
8.3
Partimage : sauvegarde des machines
Packages requis : partimage-server, partimage (installation très particulière).
Le logiciel de sauvegarde Partimage permet de sauvegarder des partitions de disques durs, localement sur une
machine, ou en envoyant la sauvegarde sur un serveur. Son intérêt est de restaurer rapidement un système d’exploitation
et l’ensemble des logiciels installés lorsque ce système a été altéré par de mauvaises manipulations, ce qui demeure
assez rare dans le cas de stations Unix.
Notons cependant que sur les machines clientes, il n’y a en principe que le système Debian et que toutes les
données des utilisateurs, c’est à dire tout ce qu’ils peuvent modifier, se trouve sur un serveur, exporté par NFS. On
observera que Debian ne présente pas de problème d’altération et de dégradation avec le temps, outre qu’il n’y a pas de
virus. Partimage sera donc pertinent pour sauvegarder un OS propriétaire qui cohabiterait avec Debian GNU/Linux,
comme si on faisait une photo à un instant t d’un état sain de ces systèmes fragiles, peu adaptés au fonctionnement
multi utilisateurs, qui demandent des droits exorbitants pour faire fonctionner des logiciels triviaux ou se servir d’un
périphérique aussi commun qu’un scanner ou une imprimante, et qui se dégradent avec le temps.
Le problème de Partimage est que ses diverses versions communiquent mal entre elles, en particulier la version
woody sur nos serveurs et la version plus récente en Sarge ou mieux Sid. Le chiffrement SSL des données n’est pas
implémenté, ou pas de la même manière, et le client partimage de sid, au mieux refuse de communiquer avec le serveur
en woody, au pire le fait planter. Il est particulièrement lourd (en raison de très nombreuses librairies de développement
à installer) et surtout pas forcément possible de compiler pour le serveur la dernière version disponible à partir des
sources. La solution la plus simple, certes peu élégante, consiste à installer partimaged (le package serveur) sur un
ordinateur en sid et de copier le binaire /usr/sbin/partimaged sur l’ordinateur qui sera serveur partimage à la place
du binaire original.
D’autre part, le démarrage de partimaged pose problème puisqu’il semble qu’il sauvegarde les images qu’il reçoit
du réseau non pas dans le répertoire spécifié dans son fichier de configuration mais à l’endroit du système où on l’a
invoqué depuis la ligne de commande. Il vaut mieux donc le lancer à la main dans le répertoire où sont stockées les
images des disques.
Pour récapituler :
1. Installer le package partimage-server sur le serveur (woody) et un client (sid).
2. Copier le binaire /usr/sbin/partimaged de la station sur le serveur
3. Créer sur le serveur un répertoire pour les images des disques (par exemple /data/images)
4. Indiquer sur le serveur, dans le fichier /etc/partimaged/partimagedusers (qui n’existe peut être pas), le nom de
l’utilisateur qui va envoyer les images depuis les clients (pour nous root). Cet utilisateur devra disposer du droit
d’écrire dans le répertoire qu’on vient de créer.
5. Se placer dans ce répertoire de sauvegarde, lancer le démon au moyen de la commande /usr/sbin/partimaged -d.
Vérifier qu’il tourne au moyen de la commande ps aux |grep partimage.
6. Sur une station, sous root, lancer le client avec la commande partimage qui appelle l’interface ci dessous, et
tester l’envoi d’une sauvegarde sur le serveur. De nombreuses options sont disponibles, la principale étant la
compression de l’image. Le meilleur choix pour un rapport optimal temps / occupation disque est gzip. L’image
doit arriver progressivement dans le bon répertoire sur le serveur à la vitesse du réseau
7. Tester une restauration, en lançant l’utilitaire partimage sur le client et en se laissant guider par l’interface très
intuitive. L’image de la machine asterix s’appelle asterix.000, on vérifiera le nom du fichier sur le serveur en cas
de doute.
Sur un réseau switché à 100 Mbits, la sauvegarde comme la restauration d’une partition d’environ 3 Go compressée
avec gzip demande très approximativement une vingtaine de minutes.
40
Notons enfin qu’existent des CDs bootables qui intègrent un client partimage permettant de faire une sauvegarde
complète de la machine en réseau mais également sur le disque local. C’est le cas de CDRescue87 .
8.4
Webmin, administration simplifiée et création de comptes
Packages requis : webmin, libnet-ssleay-perl pour l’authentification SSL, plus un package par service réseau à
intégrer en tant que module (« apt-cache search webmin »). La dernière version contenant l’intégralité du logiciel et
tous les modules est disponible sur le site officiel88 , elle ne dispense pas de l’installation des librairies Perl SSL.
L’installation de la version complète est très simple : on détarre l’archive téléchargée dans un répertoire, typiquement
usr/local/, puis le script setup.sh s’occupe de détecter lui même le système Unix installé (une énorme variété d’entre
eux sont supportés, pas seulement les diverses versions de GNU/Linux) ; il pose ensuite un certain nombre de questions
très claires comme son activation au boot ou le login et password de son administrateur. On accède à l’interface de
webmin au moyen d’un navigateur quelconque à l’URL https ://nom-de-machine :10000
Note importante : nous nous inscrivons absolument contre l’opinion qui voudrait que webmin puisse
constituer une sorte d’interface graphique à l’administration d’un serveur, qui dispenserait d’une certaine maîtrise de l’administration système et réseau. Cliquer partout dans un navigateur en espérant obtenir
des résultats satisfaisants alors qu’on ne connaît quasiment rien au logiciel serveur qu’on est en train de massacrer
conduira au mieux à des dysfonctionnements sérieux, au pire à la réinstallation complète du serveur.
Les avantages de webmin sont tout de même indéniables, spécifiquement pour un centre de formation où des droits
sont à déléguer à des formateurs qui disposent de compétences limitées dans l’administration Unix. Webmin permet
en effet de
– Créer ses propres utilisateurs seulement pour certains modules : on permettra à certains formateurs de créer des
comptes pour leurs stagiaires.
– Synchroniser très simplement les utilisateurs Unix et les éventuels utilisateurs Samba (ajout automatique d’une
entrée dans le fichier /etc/samba/smbpasswd, effacement du répertoire de profil lorsque le compte est supprimé...).
– Créer et supprimer des utilisateurs par lots au moyen de fichiers batch, extrêmement pratique pour les utilisateurs
occasionnels d’un centre de formation : en quelques secondes, on efface les utilisateurs de la veille qui ont modifié
leur répertoire personnel pour régénérer ces mêmes comptes le matin... On trouvera à cette adresse89 un batch
de création de 13 comptes et un autre batch permettant de les effacer.
Nous plaçons volontairement tous les utilisateurs dans le groupe primaire « users » et non dans un groupe à leur
nom pour simplifier le paramétrage des droits sur les périphériques des stations de travail, en particulier la carte son.
L’utilisateur « basique » de notre réseau étant par définition un stagiaire, il n’est pas necessaire de créer un groupe
spécifique. On pourra faire cela pour un utilisateur dont on désirerait restreindre encore les droits ; par contre nous
placerons les formateurs dans un groupe supplémentaire et nous leur réserverons certains partages réseau.
87 http
://www.sysresccd.org/index.fr.php
://www.webmin.com/
89 http ://logiciels-libres-cndp.ac-versailles.fr/debianinstall/fichiers/webmin/
88 http
41
8.5
Les statistiques d’usage du réseau et des serveurs
Cet article ne développe pas un point pourtant important : comment obtenir des statistiques d’utilisation des
serveurs, du réseau et de la ligne ADSL qui permettent également d’etre averti par simple consultation d’une page
web d’un éventuel problème, comme un disque presque plein ou un CPU trop occupé ?
Il existe deux logiciels principaux pour cet usage, qui s’appuient tous deux sur une installation de SNMP sur les
ordinateurs (ou routeurs) que l’on désire surveiller à distance.
Le premier est le classique MRTG90 . Le site linux-sottises.net propose une description complète de l’installation
et de la configuration91 et propose des scripts et exemples permettant de concevoir à son tour de simples scripts pour
surveiller à peu près n’importe quoi tant est grande la versatilité de MRTG.
Cacti92 est d’apparition plus récente, et constitue une bonne solution de surveillance du réseau. Il sera apprécié
par ceux qui manquent de goût ou de temps pour la conception de scripts MRTG puisqu’il est possible de définir ce
que l’on désire surveiller dans l’interface web de pilotage elle même. Ce didacticiel93 présente une installation rapide
de Cacti, tandis que cet article94 détaille un peu plus la configuration, en particulier concernant net-SNMP (sous Free
90 http
://people.ee.ethz.ch/ oetiker/webtools/mrtg/
://www.linux-sottises.net/mrtg.php
92 http ://www.cacti.net/
93 http ://www.trustonme.net/didactels/191.html
94 http ://www.alphacore.net/spip/article.php3 ?id_article=47
91 http
42
BSD).
9
L’installation de la première station de travail
Nous pouvons finalement passer au cœur du problème, l’installation de stations de travail sous système d’exploitation libre.
Un serveur doit être tout à fait transparent pour l’utilisateur qui n’en entend même jamais parler. Par contre, une
pénétration efficace du logiciel libre dans les pratiques les plus courantes des gens passe nécessairement par l’ordinateur
que l’on utilise au quotidien. La mise en place de systèmes d’exploitation libres sur ces machines clientes montrera une
alternative complète aux environnements propriétaires (et pas seulement à quelques logiciels dont la bureautique),
outre un fonctionnement en réseau bien supérieur à ce que connaissent les administrateurs de parcs entiers de machines
dans les établissements scolaires :
– Strict respect de la loi en matière de piratage de logiciels, exigé en tout premier lieu des enseignants dont le
premier devoir est de se montrer exemplaires
– Systèmes stables dans la durée qui ne se dégradent pas au cours d’installations et de désintallations multiples de
logiciels
– Absence de virus
– Impossibilité pour un utilisateur d’installer des logiciels souvent indésirables, que ces utilisateurs soient des
formateurs ou des stagiaires, des élèves ou leurs professeurs
– L’environnement complet de l’utilisateur le suit partout : il retrouve son courrier à l’identique sur n’importe
quelle machine avec toutes ses données, les préférences qu’il a définies pour ses logiciels, etc...
– Système conçu depuis le départ pour des utilisateurs multiples, pas de droits exorbitants pour utiliser telle ou
telle fonctionnalité (composant matériel, logiciel, etc...)
– Installation et mise à jour extrêmement simple de centaines de logiciels et du système lui même à travers Internet
– Pas de gestion, quasiment impossible à faire en pratique, des licences installées
– Possibilité de s’insérer et de participer, à la mesure de chacun, aux communautés de développement de ce que
l’on utilise, à commencer par la demande de fonctionnalités et le rapport de bugs
– Gratuité.
9.1
9.1.1
Rappels sur l’installation d’une machine cliente
Debian Sid
Nous conseillons la distribution Debian Sid, ou instable, qui fonctionne très bien malgré cette dénomination et
intègre dans un délai raisonnable les dernières versions des logiciels95 .
Pour disposer de Sid, après une installation basique de Debian, il suffit d’éditer le fichier /etc/apt/sources.list pour
y déclarer la distribution sid dans toutes les lignes, en accrochant la machine sur le proxy de packages ou le miroir
Debian dont le réseau dispose maintenant (il faudra lui adjoindre quelques backends, pour Agnula, mplayer, etc...)
Nous fournissons un fichier sources.list complet en section 2.4, et la section 2.2 précise comment partitionner le disque
d’une station.
L’installeur Sarge permet d’avoir tout de suite un kernel 2.6 et paramètre correctement les locales françaises par
défaut. On laissera de côté Tasksel et Dselect pour maitriser ce qui va effectivement être installé par les dépendances
d’apt-get.
Il est inutile de créer un utilisateur sur la machine puisque nous allons immédiatement l’intégrer au réseau et ainsi
utiliser les comptes du serveur. Mais avant tout déploiement, le plus important est de bien vérifier l’environnement
francais dans tous les logiciels et environnements graphiques.
9.1.2
Paramétrage d’un environnement français
Normalement, le système parle en français : la commande printenv LANG doit renvoyer fr_FR@euro au moins
aux utilisateurs si ce n’est à root. Si tel n’est pas le cas avec l’installeur Sarge, cela vient d’une mauvaise manipulation
pendant l’installation. Voici la procédure de configuration des locales françaises :
– apt-get install locales language-env
– prendre au minimum fr_FR ISO-8859-1 et fr_FR@euro ISO-8859-15 ( conseillé par défaut) dans l’interface
debconf.
– sous root, « set-language-env -E -l fr et répondre oui à toutes les questions
95 Attention, Sid fonctionne bien mais bouge très rapidement, des mises à jour sont disponibles quotidiennement. Il arrive donc que
certaines choses ne fonctionnent pas ou que certaines dépendances soient brisées. Le package apt-listbugs prévient de cela avant installation
ou mise à jour.
43
Pour configurer les locales à la main, après installation du package locales :
– echo fr_FR ISO-8859-1 » /etc/locale.gen
– echo fr_FR.UTF-8 UTF-8 » /etc/locale.gen
– echo fr_FR@euro ISO-8859-15 » /etc/locale.gen
– locale-gen
– set-language-env -E -l fr
– echo "LANG=fr_FR@euro" » /etc/environment (il est bon de vérifier le contenu de ce fichier après paramétrage
automatique des locales).
Le package « localepurge » permet d’effacer automatiquement les fichiers de localisation non utilisés à la fin de
l’installation d’un logiciel. L’espace disque libéré est considérable, de l’ordre de plusieurs dizaines de Mo voire nettement
plus.
Les logiciels s’afficheront dans la langue de Molière, s’ils sont traduits bien entendu, à l’exception notable des plus
gros d’entre eux qui demandent d’un package séparé : KDE, Mozilla (Firefox) et Open Office.org.
Les pages de man s’affichent en français si elles sont traduites et que le package manpages-fr est installé.
KDE parle français avec le package kde-i18n-fr.
Open Office.org en français demande le package openoffice.org-help-fr openoffice.org-l10n-fr. Pour l’intégration à
gnome : openoffice.org-gnomevfs et pour l’intégration à KDE : openoffice.org-kde.
Dictionnaire francais : myspell-fr-gut.
Enfin, Mozilla Firefox est localisé par le package mozilla-firefox-locale-fr-fr.
9.2
Un kernel linux pour machines multimédia
Il est souhaitable d’installer une version récente du kernel linux, si possible optimisée pour la machine et le matériel
qu’elle est appellée à faire fonctionner. Compiler un kernel soi même n’est pas absolument nécessaire, mais cela fait
partie des choses qu’il est bon de savoir faire soi même.
Ce document96 expose dans le détail la procédure de compilation d’un kernel 2.6 optimisé « temps réel » pour le
multimédia, en particulier pour la Musique Assistée par Ordinateur. La compilation avec les outils Debian procure un
package installable sur d’autres machines (en tenant compte de l’hétérogénéité du parc), qu’on pourra diffuser sur le
réseau au moyen du script exposé en section 10.3 et installer en une seule ligne de commande sur chaque ordinateur.
9.3
Intégration de la machine au réseau
9.3.1
Clients NIS et NFS
L’intégration d’une machine cliente aux services NIS et NFS est extrêmement simple.
Pour NFS, installer nfs-common, qui installera le portmapper et les logiciels complémentaires (le démon lockd en
particulier). Le montage du home au boot de la station se fait en ajoutant cette ligne dans etc/fstab :
abraracourcix:/home
/home
nfs
nosuid,intr,hard
0
0
Pour NIS, debconf demande à l’installation quel est le nom du domaine nis et prévient que la machine a besoin
de davantage de configuration. Les détails sont expliqués dans le fichier README.Debian, mais il suffit de rajouter «
+ : : : : : : » en bas du fichier /etc/passwd et « + : : : » en bas de /etc/group pour que la machine soit cliente NIS.
Bien entendu, de nombreuses options à propos de ces deux lignes sont documentées.
Il suffit de faire le montage NFS à la main et de redémarrer NIS pour vérifier qu’un utilisateur crée sur le serveur peut
s’authentifier sur la machine et disposer de ses fichiers. On vérifiera bien entendu que tout fonctionne normalement
au boot de la machine ; un problème fréquent est de voir le montage NFS ne pas se faire à cause d’un délai trop
important : cela provient très probablement d’un reverse DNS mal configuré. Ce problème est extrêmement
fréquent et classique.
On pourra se référer à la section 2.5, « logiciels complémentaires », pour affiner l’installation basique à laquelle
nous venons de procéder avant de passer à l’installation des composants d’une véritable station de travail.
9.3.2
Clients LDAP
Rappelons que la solution la plus simple pour disposer d’un annuaire LDAP pour établissement scolaire demeure
SambaEdu 397 . Le paramétrage d’un client LDAP qui permet de s’authentifier sur un annuaire n’est pas aussi trivial
qu’un client NIS, mais il demeure très accessible.
96 http
97 http
://www.crdp.ac-caen.fr/se3/
44
Deux librairies doivent être installées avec apt-get : libnss-ldap, lippam-ldap (le cache nscd est optionnel). Debconf
pose de nombreuses questions pendant leur configuration, on prendra les choix par défaut, à l’exception de ce qui
concerne le base DN de l’annuaire (dans SambaEdu : configuration générale, paramètres LDAP, Dn de base de l’annuaire) et l’adresse IP, qui est celle du serveur LDAP et non 127.0.0.1. Les fichiers de configuration de ces librairies
sont /etc/libnss-ldap.conf et /etc/pam_ldap.conf.
Ensuite, deux fichiers doivent être modifiés :
/etc/nsswitch.conf :
Remplacer les entrées par défaut :
passwd:
group:
shadow:
compat
compat
compat
par :
passwd:
group:
shadow:
files ldap
files ldap
files ldap
/etc/pam.d/login
Attention, pam constitue le mécanisme d’authentification sous linux. Il n’y a rien à redémarrer après une
modification dans pam, il devient donc impossible de s’authentifier sur la machine après une mauvaise manipulation.
Il est très vivement conseillé d’ouvrir aux moins deux consoles root de manière à être certain de pouvoir conserver
la main sur la station et replacer les fichiers originaux dont on aura fait une sauvegarde (si on a installé nscd, il peut
être nécessaire de le redémarrer).
Voici le contenu correct de ce fichier :
auth
auth
auth
required
pam_env.so
sufficient
pam_unix.so nullok
required
pam_ldap.so use_first_pass
account
account
session
session
session
session
password
sufficient
required
required
optional
optional
optional
required
pam_ldap.so use_first_pass
pam_unix.so
pam_unix.so
pam_lastlog.so
pam_motd.so
pam_mail.so standard noenv
pam_unix.so nullok obscure min=4 max=8
Un listing des fichiers dans /etc/pam.d montre qu’il y a un fichier par service d’authentification, on copiera donc
le fichier login dans le fichier xdm (ou kdm, etc..) pour que l’ouverture de session en mode graphique puisse se faire.
9.4
Installation d’un environnement graphique et de logiciels divers
Packages requis : x-window-system, gnome, kde
Nous allons installer des « meta-packages », qui en eux mêmes ne contiennent pas grand chose mais en appellent de
nombreux autres et permettent ainsi une installation complète de composants pour une machine de bureau. Ainsi le
système X Window sera installé dans son intégralité pour éviter tout dysfonctionnement qui ne sera souvent constaté
que plus tard, par quelqu’un d’autre, lorsque tout sera en place.
La commande « apt-get install x-window-system » provoque une grosse installation, dont le package x-serverxfree86 : le serveur X à proprement parler. C’est le package le plus délicat puisqu’il conditionne tout l’affichage en
mode graphique et pose de nombreuses questions auxquelles il faut répondre de manière très rigoureuse, les choix
par défaut n’étant pas toujours les plus pertinents. Avant de le configurer, on vérifiera le modèle exact de carte vidéo
de l’ordinateur au moyen de la commande lspci et on se munira de la documentation du moniteur qui en précise les
fréquences horizontales et verticales (ces caractéristiques techniques se trouvent en quelques instants sur Internet).
On pourra rappeler la configuration du serveur X au moyen de la commande « dpkg-reconfigure xserver-xfree86 »,
que nous détaillons ci dessous pour les options ambiguës ou délicates :
– Pilote de serveur X que vous souhaitez utiliser :
Il n’est pas forcément toujours parfaitement détecté, dans notre cas ati. Surtout pas Vesa qui est proposé par
défaut si la carte est mal reconnue.
45
Ne pas prendre le pilote « frame buffer » qui rajoute une couche d’abstraction logicielle au dessus du
matériel et dégrade sensiblement les performances, à moins d’être certain que la carte soit mal supportée, ce qui
est très rare aujourd’hui.
– Identifiant de votre carte vidéo : Generic Video Card
Le nom n’a aucune importance
– Identifiant du bus de la carte vidéo :
– Quantité de mémoire (en ko) utilisée par votre carte vidéo :
On peut laisser en blanc ces deux options
– Jeu de règles XKB à utiliser :
Laisser le choix xfree86
– Type de clavier :
Pc105 (sauf pour un portable), le choix pc104 provoque souvent un dysfonctionnement des touches < et >.
– Disposition de votre clavier :
« fr » conseillé, le chois « us » étant proposé par défaut.
– Variante de votre clavier :
– Options de votre clavier :
Laisser en blanc ces deux options, pour reconfigurer éventuellement ensuite
– Port de branchement de votre souris :
/dev/psaux pour une souris PS/2, ttyS0 pour COM 1. Les souris USB se font passer pour des souris PS/2.
– Veuillez choisir ce qui correspond le mieux à votre souris.
ImPS/2 pour une souris à roulette.
– Faut-il émuler une souris à 3 boutons ?
Pour une souris deux Répondre oui pour que la fonction « coller » sous X Window (usage normal et quasi exclusif
du bouton central), soit obtenue par une pression simultanée des deux boutons.
– Veuillez choisir une méthode de sélection des caractéristiques de votre écran
Cette question indique le niveau de complexité des questions qui seront posées par la suite. Le choix le plus pertinent sauf configuration vraiment exotique et connaissance poussée du matériel demeure, pour nous, « Medium
».
– Veuillez choisir le meilleur mode supporté par votre écran
La fréquence est le paramètre le plus important, ce choix ne concerne pas encore les résolutions qui seront
affichées. Pour un 17 pouces standard on peut normalement choisir 1280x1024 @ 60Hz voire au dela. Il faudra
probablement repasser dans le fichier de configuration pour affiner ces valeurs à l’aide de la documentation de
l’écran 98 .
– Modes vidéo utilisés par le serveur X :
Indiquer la résolution maximale supportée par le moniteur, puis les résolutions inférieures désirées. Pour nous,
1280x1024, 1024x768, 800x600.
– Veuillez choisir la profondeur de couleur par défaut (en bits)
24 bits si la carte vidéo dispose d’assez de mémoire
– Modules du serveur XFree86 qui seront chargés par défaut :
Cocher tous les modules. Le plus important concerne le module DRI pour la 3D, si la carte vidéo le supporte. On
pourra toujours commenter cette ligne dans le fichier par la suite, ainsi que sa toute dernière section qui définit
les paramètres du DRI.
– Faut-il mettre une section « Files » de référence dans la configuration ?
– Faut-il mettre une section « DRI » de référence dans la configuration ?
Répondre Oui.
Le message d’erreur le plus fréquent si X ne démarre pas est « no screens found », qui ne signifie pas qu’aucun écran
n’est trouvé, mais que le système ne parvient pas à demander à la carte vidéo d’envoyer un mode (une résolution)
qui soit acceptée par l’écran. Auquel cas on reprendra la configuration du serveur X (dpkg-reconfigure xserver-xfree86 )
pour rentrer de nouvelles valeurs.
On ajustera au besoin les paramètres de fréquence de l’écran en éditant le fichier /etc/X11/XF86Config-4 à l’aide
de la documentation du moniteur qui précise toujours les bons paramètres, par exemple de cette manière 99 :
Section "Monitor"
Identifier
HorizSync
VertRefresh
Option
98 si
"Generic Monitor"
30-72
50-120
"DPMS"
l’on donne absolument n’importe quoi comme valeur à ces paramètres il est possible de sérieusement détériorer l’écran.
DPMS permet l’économie d’énergie
99 l’option
46
EndSection
Un problème récurrent concerne certaines polices de caractères, dans xterm en particulier : elles sont tellement laides
qu’elles en sont illisibles. Cela provient des polices par défaut qui ne sont pas optimisées pour une locale européenne. On
y remédiera par l’installation de trois packages trouvés par apt-cache search transcoded : xfonts-base-transcoded, xfonts75dpi-transcoded et xfonts-100dpi-transcoded. Si la police de l’utilisateur est toujours aussi laide après redémarrage du
serveur X, on supprimera le fichier .Xressources qui se trouve dans son répertoire personnel.
Enfin, il sera possible d’agrémenter l’écran de login graphique en installant celui de KDE (KDM) ou celui de
Gnome (GDM) avec apt-get. Nous recommandons KDM qui se paramètre plus aisément depuis les préférences de
KDE, sans toucher à aucun fichier de configuration, et qui présente les avantages de trouver automatiquement tous
les gestionnaires de fenêtres installés et de permettre à tout le monde d’éteindre l’ordinateur sans ouvrir de session.
Le choix et l’apparence de ce gestionnaire de connexion sont importants car ils donnent à la salle informatique son «
look » tel que le percevront les visiteurs avant d’utiliser les machines.
On peut forcer la taille des polices dans les paramètres passés au lancement de X par le gestionnaire de connexion.
Le fichier impliqué s’appelle Xservers, son emplacement dépend de Xdm, GDM ou KDM. Pour KDM, il s’agit de
/etc/kde3/kdm/Xservers, la ligne est :
:0 local@tty1 /usr/X11R6/bin/X -nolisten tcp vt7
On rajoutera -dpi 100 pour forcer cette taille si le défaut ne convient pas, par exemple pour une résolution un peu
élevée. Cet ajustement a parfois tendance à harmoniser les polices, leur taille et leur apparence dans l’ensemble de X.
D’autre part, l’option -nolisten tcp explique que dans Debian, il soit par défaut impossible de déporter son affichage
sur le réseau, puisque X n’écoute pas sur celui ci. Si l’on veut permettre cela, ce qui est une faille de sécurité potentielle,
il faudra retirer cette option.
Vient ensuite l’installation des environnements de bureau Gnome et KDE, qui peuvent être appelés par leur nom
avec apt-get install et provoquent le téléchargement de quelques centaines de Mo de logiciels. Il est préférable de les
installer complètement à l’aide de leurs « méta packages » pour offrir aux utilisateurs le plus large choix logiciel possible,
ce que permet la taille des disques durs modernes. Pour cette raison, il semble également inutile de choisir entre l’un ou
l’autre, il est préférable d’installer les deux car, outre le plus grand choix, les librairies des deux environnements seront
de toute manière nécessaires pour faire tourner tous les logiciels. Les dépendances des «meta packages » installeront
de nombreux composants nécessaires pour des usages très variés, comme hotplug, sane, LATEX, Gimp, un système
d’impression, etc...
9.5
Les droits sur les périphériques : carte son, webcam, etc...
Si les utilisateurs appartiennent tous au même groupe primaire sur le serveur, ces groupes se retrouvent localement
dans NIS. Ainsi, pour que tous les utilisateurs puissent avoir du son, il suffit de placer les bons périphériques dans le
groupe « users », à savoir /dev/audio0, /dev/mixer0 et /dev/dsp0 100 .
La carte son demeure probablement toujours muette, même pour root. Le package alsa-utils (avec un kernel 2.6)
intègre alsamixer : sous root, dans une console, il permet d’affecter un volume aux différentes sorties de la carte et
surtout dé-muter les pistes (touche M) puisque tout est muet par défaut dans Alsa.
On placera d’autres périphériques dans le même groupe, comme /dev/video0 pour une webcam ou le groupe défini
dans le script /etc/hotplug/usb/libgphoto2 (par défaut video) pour faire fonctionner un appareil photo numérique USB.
9.6
Le problème des logiciels et composants propriétaires
Il existe un certain nombre de logiciels propriétaires auxquels les gens sont très habitués voire dépendants, et dont
ils oublient l’usage d’autant plus facilement que ces logiciels sont gratuits. Chacun se déterminera en fonction de ses
convictions et des demandes de ses utilisateurs pour les installer, ils sont disponibles avec un peu de recherche dans
Debian et peuvent aider à convaincre des personnes réticentes à propos de la viabilité de notre solution informatique ;
une tel choix fait qu’on ne peut hélas plus qualifier celle ci de totalement libre.
Parmi ces logiciels, on trouvera en particulier :
– Les polices True Type.
– Acrobat Reader
– Les codecs vidéo propriétaires du package w32codecs, qui accompagnent mplayer
– Flash
– Real audio
– Java
Ces trois derniers composants sont hélas nécessaires pour afficher tel ou tel site Web...
100 Ce
choix du groupe primaire des utilisateurs est exposé dans la section 8.4
47
10
Installation automatisée de toutes les autres machines
La première machine doit servir de modèle pour toutes les autres. Dès que l’on a déterminé une liste complète de
logiciels pour les usages proposés aux futurs utilisateurs et que les divers détails de configuration sont réglés, quand à
l’affichage, au son, à la vidéo, etc etc... il est possible de reproduire l’installation de cette machine sur le réseau quand
tous les tests sont concluants.
10.1
Le principe de la réplication de fichiers
Le principe est le suivant :
1. On commence par une installation basique de Sarge sur toutes les machines clientes, qu’on termine par les
packages ssh et rsync.
2. Nous utilisons ensuite un script qui interroge le serveur DNS pour connaître la liste des machines présentes sur
le réseau, et propose de choisir les machines cibles d’une synchronisation d’un ensemble de contenus envoyés à
destination à travers ssh automatiquement, sans qu’aucun mot de passe ne soit à saisir.
3. Comme nous allons déployer un script d’installation, il faudra tout de même exécuter ce script sur chaque
machine, mais nous contrôlerons alors tout le réseau depuis une station unique sans authentification, puisqu’il
suffira de s’authentifier une seule fois sur le réseau en ouvrant sa session de travail le matin.
4. Cette procédure pourra être réutilisée pour mettre à jour les machines ou répliquer certains fichiers (paramétrage
de l’imprimante, logiciel installé à part, etc...).
10.2
Ssh en mode agent
Comment fonctionne donc ce système d’authentification unique sur tout le réseau ? Voici un login ssh classique sur
une machine :
prof@hyperion:~$ ssh weatherwax
The authenticity of host ’weatherwax (192.168.28.48)’ can’t be established.
RSA key fingerprint is 04:59:cc:56:73:c8:57:47:19:d2:c7:1b:12:9f:2d:91.
Are you sure you want to continue connecting (yes/no)?
Le système prévient que la machine à laquelle nous tentons d’accéder est inconnue, souhaitons nous continuer ?
En lui répondant oui, l’identité chiffrée de la machine, fournie par son démon sshd, sera stockée dans le fichier
˜/.ssh/known_hosts et la question ne nous sera plus posée (c’est le sens du « Warning » suivant). Par contre si
jamais cette identité numérique change, nous en serons prévenus car cela signifiera que la machine n’est plus la même,
ce qui est extrêmement suspect. Répondons oui :
Warning: Permanently added ’weatherwax,192.168.28.48’ (RSA) to the list of
known hosts.
Password:
Et nous sommes loggués sur la machine distante avec notre mot de passe validé par NIS. Nous voulons renforcer
cette authentification et faire en sorte, en même temps, de ne s’authentifier qu’une seule fois sur une seule machine
quel que soit le nombre de connexions que nous pouvons opérer ensuite jusqu’à la fermeture de notre session. Plus
clairement, pouvoir se logguer sur toutes les machines du réseau, en tant que root, sans mot de passe, de manière
sécurisée.
La première chose à faire est d’utiliser un agent ssh qui va mémoriser notre authentification et chiffrer les données
transférées sur le réseau. Pour générer cette clef, on procède de cette manière :
prof@hyperion:~$ ssh-keygen -t dsa
Ssh-keygen va générer notre clef, l’option « -t dsa » génère un chiffrement fort compatible avec ssh version 2 qu’il
est impératif d’utiliser pour des raisons de sécurité. La machine génère la paire de clefs (publique et privée), et nous
demande dans quel fichier sauvegarder cela :
Generating public/private dsa key pair.
Enter file in which to save the key (/home/prof/.ssh/id_dsa):
Nous ne changeons pas le choix par défaut qui est de placer cela dans le fichier id_dsa, dans le répertoire .ssh du
répertoire personnel. Validons, voici le moment le plus important.
48
Enter passphrase (empty for no passphrase):
C’est un gouffre de sécurité que de créer une passphrase vide ! C’est donc le moment de saisir une
passphrase la plus longue et complexe possible, avec autant qu’on le souhaite d’espaces et de caractères spéciaux, puis
valider. Cette chaîne de caractères nous servira par la suite quotidiennement pour administrer l’ensemble du réseau, il
importe donc de choisir quelque chose d’à la fois non trivial à deviner mais que l’on soit certain de retenir.
Enter same passphrase again:
Il est demandé très logiquement de confirmer cette passphrase. Le système l’enregistre :
Your identification has been saved in /home/prof/.ssh/id_dsa.
Your public key has been saved in /home/prof/.ssh/id_dsa.pub.
The key fingerprint is:
46:58:2f:97:98:61:4c:3e:9b:94:0a:8a:3d:d1:1c:0b prof@hyperion
Et nous pouvons vérifier le contenu du répertoire .ssh de notre répertoire personnel :
prof@hyperion:~$ ls
total 20
drwx-----2 prof
drwxr-xr-x 14 prof
-rw------1 prof
-rw-r--r-1 prof
-rw-r--r-1 prof
-al .ssh
users 4096 2005-03-31 11:09 .
users 4096 2005-03-22 17:12 ..
users 744 2005-03-31 11:09 id_dsa
users 603 2005-03-31 11:09 id_dsa.pub
users 224 2005-03-18 12:53 known_hosts
Testons de suite cette clef, nous allons transformer notre clef publique en clef autorisée sur la machine distante.
Pour ce faire, il suffit de copier un fichier :
prof@hyperion:~$ cd .ssh
prof@hyperion:~/.ssh$ cp id_dsa.pub authorized_keys
prof@hyperion:~/.ssh$ ls -al
total 24
drwx-----2 prof users 4096 2005-03-31 11:33 .
drwxr-xr-x 14 prof users 4096 2005-03-22 17:12 ..
-rw-r--r-1 prof users 603 2005-03-31 11:33 authorized_keys
-rw------1 prof users 744 2005-03-31 11:09 id_dsa
-rw-r--r-1 prof users 603 2005-03-31 11:09 id_dsa.pub
-rw-r--r-1 prof users 458 2005-03-31 11:15 known_hosts
Il se trouve maintenant un fichier authorized_keys dans notre dossier personnel et donc, grâce au montage NFS,
sur l’ensemble du réseau (ce ne sera pas le cas pour le root de chaque machine).
prof@hyperion:~/.ssh$ ssh weatherwax
Enter passphrase for key ’/home/prof/.ssh/id\_dsa’:
La même machine que précédemment ne nous demande plus de mot de passe, mais notre passphrase. Il suffit de la
rentrer pour s’authentifier sur la machine. Nous avons introduit un niveau de sécurité supérieur à celui du simple mot
de passe, mais il nous est toujours demandé une authentification. Utilisons donc un « agent ssh ». Délogguons nous de
la machine distante et introduisons toutes les variables d’environnement dans l’agent :
prof@hyperion:~/.ssh$ eval ‘ssh-agent‘
Agent pid 3523
Voila qui est fait101 . Nous pouvons maintenant nous authentifier auprès de cet agent ssh :
prof@hyperion:~/.ssh$ ssh-add
Enter passphrase for /home/prof/.ssh/id_dsa:
Identity added: /home/prof/.ssh/id_dsa (/home/prof/.ssh/id_dsa)
prof@hyperion:~/.ssh$
101 Il
s’agit d’apostrophes inversées obtenues avec Alt Gr-7
49
Et s’ensuit une agréable surprise :
prof@hyperion:~/.ssh$ ssh weatherwax
Linux weatherwax 2.6.10 #1 Tue Jan 18 15:51:30 CET 2005 i686 GNU/Linux
Last login: Thu Mar 31 11:36:33 2005 from hyperion.mp-soa.net
prof@weatherwax:~$
Plus aucun mot de passe n’est demandé, nous sommes authentifiés sur toutes les machines qui connaissent notre
clef jusqu’à la fin de notre session. Comme le fichier authorized_keys est « présent » sur chaque machine dans notre
répertoire personnel à cause du montage NFS, on remarquera que nous pouvons ainsi rentrer sur une machine, en
sortir et rentrer sur une autre toujours sans mot de passe.
Le problème est que le compte root de chaque machine ne nous connaît pas, car ce compte n’est pas connu de NIS
mais demeure, heureusement d’ailleurs, local à chaque machine. Par mesure de sécurité, nous n’allons pas copier notre
clef privée ni la liste des machines connues sur tout le réseau, mais simplement la clef publique qui se trouve dans le
fichier authorized_keys. Nous allons donc nous authentifier pour la dernière fois sur la machine distante en apprenant
à utiliser rsync102 :
prof@hyperion:~$ rsync -avzR .ssh/authorized_keys root@weatherwax:~
Password:
building file list ... done
.ssh/
.ssh/authorized_keys
sent 627 bytes received 40 bytes 148.22 bytes/sec
total size is 603 speedup is 0.90
Il ne nous reste plus qu’à rentrer en root sur la machine distante sans mot de passe :
prof@hyperion:~/.ssh$ ssh weatherwax -l root
Last login: Thu Mar 31 11:55:05 2005 from hyperion.mp-soa.net
weatherwax:~#
La contrainte est de reproduire cette copie de fichier / répertoire dans /root sur chaque machine du réseau. D’autre
part, si plusieurs administrateurs procèdent à cette manipulation, on veillera à ne pas écraser la clef du collègue en
copiant brutalement le fichier, mais en y insérant notre clef à la suite de la sienne en éditant le fichier.
Sur notre station de travail, il suffit maintenant de rajouter une ligne dans le fichier .xinitrc (ou .xsession), qui
contient le fameux « eval ‘ssh-agent‘ » et de s’authentifier auprès de l’agent avec ssh-add dans le premier terminal
graphique ouvert au début de notre session de travail sous X, c’est la toute première chose à faire le matin en se
logguant :). On constatera ainsi que cela fonctionne pour les autres xterms ouverts par la suite, et qu’on a plus ainsi
qu’à saisir une seule fois sa passphrase en début de journée pour administrer toutes les machines. Le revers de la
médaille consiste bien entendu à bloquer son écran dès qu’on s’éloigne de l’ordinateur pour empêcher quiconque de
passer root à notre place sur toutes les machines qui connaissent notre clef.
Le lecteur attentif et exigeant aura remarqué qu’il est impossible de passer de machine en machine en conservant
l’agent, il faut toujours se delogguer puis se relogguer pour que cela fonctionne. De manière à se promener sur le
réseau en emportant son agent avec soi, il suffit de déclarer cette ligne dans /etc/ssh/ssh_config (attention, fichier de
configuration du client, ssh_config, et non du serveur, sshd_config) :
ForwardAgent yes
10.3
Dupliquer la première machine : adapter le script de réplication - premiers tests
Rsync est un logiciel très puissant qui synchronise des fichiers ou répertoires de la machine locale sur une machine
distante, en envoyant uniquement les différences. Typiquement, si on a rajouté une virgule dans un fichier, rsync est
capable d’envoyer uniquement la virgule, compressée et chiffrée. On trouvera des détails dans la documentation de
rsync ainsi que sur cette page103 .
101 pour
se promener de machine en machine en emportant l’agent avec soi, voir la fin de cette section
peut le faire également avec scp, mais il faut s’authentifier une fois pour créer le répertoire, une autre fois pour copier le fichier si
on ne veut pas copier tout le répertoire
102 on
50
Nous allons utiliser rsync pour déployer un ensemble de fichiers sur l’ensemble du réseau au moyen d’un script,
pour répliquer l’installation de la première station de travail que nous avons passé tant de temps à fignoler. Notre
script va interroger le serveur DNS par ssh pour rapatrier le fichier de zone et proposer la liste des machines connues.
On saisit le numéro de chaque machine dans la liste, pour l’ajouter ou la retirer si elle a été sélectionnée par erreur. Le
résultat est affiché, on sort de cette interface avec Control-D, et rsync commence son travail : synchroniser le contenu
de ce qu’on lui a passé en paramètre en l’invoquant.
Le script de réplication104 105 demande une adaptation à la structure du réseau. Il suppose également que les
fichiers de zone aient une certaine structure en colonnes que va aller lire awk. Si le nombre de colonnes n’est pas le
même, le script ne peut pas fonctionner.
#Paramètres réseau et serveur
RESEAU="192.168.28"
SERVEUR="andromede"
REP_DNS="/var/named"
DNS="db.mp-soa"
Les paramètres concernent ici le serveur DNS du réseau, en particulier le répertoire où se trouvent les fichiers de
zone et le nom du fichier lui même.
#Paramètres machine locale
REP_COPIE="/tmp"
COPIE_DNS="db.mp-soa"
IP_LOCALE="192.168.28.7"
\#contiendra l’adresse IP de la machine source
Le répertoire de la copie locale du fichier de zone et l’adresse ip de la machine source où nous nous trouvons, qui
sera exclue de la liste des cibles.
#Trois groupes de destinations...laisser un espace à la fin
ENS_POSTES="Tous Packards Zéniths "
#Caractéristiques des groupes
FIRST_PACKARD="11"
LAST_PACKARD="21"
FIRST_ZENITH="30"
LAST_ZENITH="42"
On dispose de deux groupes de machines, par exemple pour deux salles ; on précise le début et la fin de chaque
plage d’adresses ip de ces deux groupes, « Packard » et « Zenith ». La contrainte est que ces postes soient situés sur
de telles plages et disposent évidemment d’une adresse fixe.
#Les postes à exclure de la liste de choix
SAUF_POSTES="remote soleil stargate HP4050 HP4200 andromede
\abraracourcix detritus rincewind weatherwax arrakis arcturus"
On pourra éditer cette liste de manière à rajouter ou exclure certains ordinateurs de la liste proposée, dans un
premier temps les serveurs et les imprimantes constituent un choix évident des noms à exclure.
#C’est clair :)
OPTION_RSYNC="-e ssh -avzR"
Les options passées à la commande rsync qui va diffuser les fichiers :
– -e ssh pour authentifier à travers ssh et utiliser l’agent dans lequel nous rentrons notre clef.
– -avzR pour compresser (z), expliquer ce qui se passe de manière détaillée (v) et synchroniser en mode archive
a et R), en préservant les permissions sur les fichiers et l’arborescence. On ajoutera un « n » pour simplement
tester sans que rien ne soit effectué.
Quelques précautions à prendre avec ce script :
1. Indiquer toujours le chemin entier des fichiers sinon ils seront placés à la racine du disque distant
104 http
105 Ce
://logiciels-libres-cndp.ac-versailles.fr/debianinstall/fichiers/rsync_mediapole
script a été écrit par Serge Sauton que nous tenons à remercier particulièrement.
51
2. « ./rsync_mediapole bidule » synchronisera le répertoire bidule tandis que « ./rsync_mediapole bidule/ » synchronisera le contenu de ce répertoire.
3. Ce script cherchera une authentification root sur les machines indiquées, potentiellement sur tout le réseau. Si
on s’y prend bien :), en particulier en modifiant les options de rsync pour effacer les fichiers figurant sur la cible
et pas sur la source, il est tout à fait possible de casser très rapidement toutes les machines sans aucun mot de
passe ni demande de confirmation.
4. Avec rsync comme avec scp, il faut faire attention à ne pas se tromper de sens dans la syntaxe de la commande
pour ne pas effacer tout le travail de la journée en pensant en faire une sauvegarde sur le serveur : rsync <source>
<destination> et non le contraire :).
On pourra commencer à faire quelques tests avec ce script, pour ensuite déployer simplement quelques fichiers
pertinents, par exemple /etc/apt/sources.list. L’avantage est tout de suite évident : une nouvelle source de packages
se retrouve instantanément sur tout le réseau sans passer sur chaque ordinateur pour le déclarer puisque le script le
fait pour nous (outre le confort du proxy de packages).
10.4
Extraire la liste des logiciels installés et la reproduire
Nous voulons des machines identiques, possédant toutes rigoureusement les mêmes logiciels installés. Le principe
est extrêmement simple :
1. Extraire la liste des packages installés sur la machine « modèle » :
dpkg --get-selections > packages.sel
2. Copier le fichier packages.sel (le nom n’a aucune importance) sur les machines « cibles » avec le script.
3. Déclarer, sur ces machines, la liste des packages devant être installés :
dpkg --set-selections < packages.sel
4. Procéder à un dist-upgrade de cette manière :
apt-get --yes dselect-upgrade
(par sécurité, on passera deux fois cette commande).
Et voila ! :)
Mais comme les machines « cibles » sont par hypothèse « brutes d’installation », on doit les intégrer au réseau
(configuration cliente de NIS et NFS), paramétrer leur carte son, régler éventuellement la locale, etc..., le plus simple
est de mettre l’ensemble des taches à exécuter dans un script qu’on déploiera sur le réseau avec la procédure que nous
connaissons maintenant.
Voici un script de ce type106 . Attention, il ajoute des lignes dans des fichiers du système et n’est à utiliser qu’une
seule fois en l’état.
11
Jouer avec le réseau
En conclusion, voici quelques applications qui permettent de découvrir de manière amusante les fonctionnalités de
notre réseau.
11.1
Déporter l’affichage
Le protocole X Window est d’emblée conçu pour fonctionner en réseau. On peut alors totalement distinguer la
machine sur laquelle on tape des commandes, celle sur laquelle elles sont exécutées et enfin l’écran où s’affiche le
résultat.
Déporter l’affichage est amusant, pratique dans certains contextes mais aussi peu souhaitable dans d’autres car
ouvrir son écran permet à d’autres d’afficher des fenêtres dessus, mais aussi de capturer ce qu’on est en train de faire.
On en usera donc avec discernement.
Il faut commencer par lancer X Window de manière à ce qu’il écoute sur le réseau, ce qui n’est pas le cas par
défaut sous Debian (voir fin de la section 9.4). Un utilisateur peut alors ouvrir son affichage à une machine donnée
par la commande « xhost +hostname » (ou xhost + pour l’ouvrir à tous). Sur une autre machine, dans un xterm, la
commande « export DISPLAY=hostname :0.0 » permet de déporter l’affichage graphique sur le premier ordinateur.
La commande « xcalc » affichera alors la calculatrice sur l’écran distant, et la commande « xmessage » remplit la
fonction que son nom indique :).
106 http
://logiciels-libres-cndp.ac-versailles.fr/debianinstall/fichiers/installpc.sh
52
11.2
Déporter le son
Pourquoi ne pas écouter de la musique sur la machine pourvue des meilleures enceintes ? Déporter le son d’une
application est très simple, et de nombreux logiciels multimédia permettent de le faire (mplayer, xine, xmms, etc...). Il
faut commencer, sur la machine hôte (qui reçoit le son), par lancer un daemon qui écoute sur le réseau ; Enlightenment
Sound Daemon est installé avec Gnome et permet de tester rapidement cette possibilité, en le lançant de cette manière :
« esd -tcp -public ». Esd émet alors un son sur les enceintes.
Mpg321 fonctionne en mode texte ; malgré son absence d’interface utilisateur, il est doté de très nombreuses
fonctionnalités et nous permet de tester facilement l’écoute d’un fichier sur un autre ordinateur, au moyen de cette
simple commande : « mpg321 -o esd -a nom_de_la_machine Mon_fichier.mp3.
11.3
Wims
WWW Interactive Mathemactics server est un serveur d’applications pédagogiques fonctionnant dans une interface
web en mode client / serveur, le client consiste donc en un simple navigateur et un paquet Debian existe pour
l’installation du serveur. Une base conséquente d’exercices est disponible, à laquelle on peut contribuer.
Wims s’interface sur un certain nombre de logiciels scientifiques pour le calcul, le tracé, le rendu, etc... : pari-GP,
Gnuplot, Octave, LATEXet bien d’autres, tous présentés ici même. Une section spéciale107 de ce site est consacrée
entièrement à Wims.
11.4
La diffusion vidéo : vlc
VideoLAN108 constitue un vaste projet de diffusion vidéo sur réseau. Le client vlc sait lire nombre de codecs vidéo
et des DVDs, mais il est également capable de diffuser un film en broadcast sur un réseau local, ce qui permet d’égayer
sensiblement nos salles multimédia :).
Un certain nombre d’adresses sont réservées pour ce type d’usage que vlc sait exploiter : Fichier -> Ouvrir un
fichier (avancé), après avoir choisi un fichier cliquer sur le bouton « flux de sortie » dans l’onglet « réseau », une
fenêtre s’ouvre avec le bouton « paramètres ». Cliquer sur le bouton « UDP », entrer une de ces adresses spéciales,
comprises entre 224.0.0.0 et 239.255.255.255, par exemple 224.42.42.42. Il suffit alors de valider pour voir le switch se
mettre à clignoter de manière assez intensive :).
On accède au film depuis une machine quelconque en ouvrant simplement un flux réseau (menu « fichier ») et en
indiquant l’adresse de broadcast sur laquelle le film est diffusé.
Vlc intègre des paramètres indispensables, par exemple la possibilité de diffuser sur un mur d’écrans :). Ouvrir les
préférences (menu « paramètres »), puis Vidéo - Filters - Image Wall pour définir le nombre de rangées et de colonnes
d’écrans.
Ces manipulations sont décrites sur le site de vlc, en particulier la procédure de diffusion sur le réseau local109
(format PDF, en anglais).
11.5
Partager un scanner
Un scanner partagé sur un réseau permettant de numériser depuis n’importe quel ordinateur reste un matériel
rare et coûteux dans le monde de l’informatique propriétaire. On peut cependant faire cela avec n’importe quel
scanner au moyen d’un composant de Sane fonctionnant en mode client serveur, sans aucune dépense ni installation
supplémentaire.
Sur le poste « serveur » où est connecté le scanner, on placera la liste des machines autorisées à numériser dans le
fichier /etc/sane.d/saned.conf :
# saned.conf
localhost
luna
hyperion
mercure
neptune
Et sur ces machines autorisées, on indiquera tout simplement la ou les machines faisant fonction de « serveur de
scanner » dans le fichier /etc/sane.d/net.conf :
107 http
://logiciels-libres-cndp.ac-versailles.fr/rubrique.php3 ?id_rubrique=24
://www.videolan.org/
109 http ://www.videolan.org/doc/misc/VLC Streaming.pdf
108 http
53
# This is the net config file.
mars.mp-soa.net
luna.mp-soa.net
Each line names a host to attach to.
Le démon saned se mettra en fonction en tant que service d’inetd
/etc/inetd.conf :
dès son appel, si cette ligne figure dans
sane stream tcp nowait saned.saned /usr/sbin/saned saned
Et on aura le plaisir d’avoir le choix du scanner à utiliser au lancement de xsane sur n’importe quelle machine :
Il faudra tout de même encore se déplacer pour mettre le document à numériser dans le scanner :).
11.6
Un cluster de calcul
Une des applications les plus fascinantes d’un réseau de machines Unix est la construction d’un calculateur permettant d’additionner la puissance de tous ces microprocesseurs qui la plupart du temps ne font finalement pas grand
chose.
Une application amusante permet déjà de tester le débit et la solidité du réseau avec la connectivité au serveur
NFS : l’encodage de vidéo depuis un DVD. Transcode est un peu le couteau suisse en matière de codage vidéo ; le
logiciel DVD Rip est bien plus qu’une simple interface graphique à transcode, car il intègre un mode « cluster »
permettant de découper de gros fichiers vidéo, de coder chaque morceau sur une machine et de rassembler le tout au
fur et à mesure de l’avancement du travail au moyen d’un serveur NFS.
Il suffit d’installer transcode et les librairies appropriées sur chaque ordinateur, et DVD Rip sur la machine qui
pilotera le « cluster ». La limite de cette application est qu’il ne s’agit pas de véritable clustering puisqu’il n’y a pas de
parallélisation des taches entre microprocesseurs : ainsi, les pistes audio ne pouvant être découpées comme la vidéo, on
regardera une seule machine encoder laborieusement le son alors que toutes les autres sont inutilisées puisque la vidéo
54
est encodée depuis longtemps. L’idée serait alors de leur faire encoder d’autres vidéos, et de les faire toutes travailler
en même temps sur de nombreux projets.
C’est là un excellent moyen de totalement surcharger le réseau mais aussi de tester la solidité de l’interconnexion
des machines entre elles. NFS. A partir de là, on pourra s’intéresser à de véritables applications de calcul distribué si le
câblage et les éléments actifs le permettent. Une des solutions les plus adaptées pour cela semble être Open Mosix110 ,
à propos duquel on lira un très bon article111 sur LinuxFrench.net.
11.7
Quelques jeux en réseau
Devant un réseau sous Linux, on se demandera probablement tout de suite s’il est possible de jouer à Quake :).
La réponse est oui, mais on trouve un certain nombre de jeux que les mordus de l’informatique connaissent depuis
belle lurette, à commencer par Civilisation. Ce jeu légendaire est activement développé dans une version libre qui
permet d’y jouer en réseau, cela s’appelle Freeciv, fonctionne en mode client / serveur sur un réseau local mais aussi
sur Internet et s’installe tout aussi simplement que le reste avec apt-get.
r bataille navale... c’est le cas de nombre de ceux
D’autres jeux en réseau sont disponibles : échecs, Monopoly °,
fournis avec Gnome et KDE. Mentionnons encore quelque chose de simple et rapide à prendre en main ; il n’y a pas de
3D ni d’armes sophistiquées (quoique...) mais l’intérêt ludique demeure majeur pour tous les âges : le célèbre XBlast112 .
Enfin, un des jeux les plus amusants demeure le réseau lui même :). On ne manquera pas de l’indiquer à chaque
utilisateur lors de son login, en plaçant cette simple phrase dans le fichier /etc/motd de chaque machine :
110 http
://openmosix.sourceforge.net/
://www.linuxfrench.net/article.php3 ?id_article=1177
112 http ://xblast.sourceforge.net/
111 http
55
Amusez vous bien, et soyez libres ! :)
[email protected]
12
Remerciements
Je tiens particulièrement à remercier pour leur aide :
– Stéphane Marzloff, qui m’a appris ce que sont Internet et le logiciel libre
– Stéphane Marchau, qui m’a appris comment faire marcher un réseau
– L’école ouverte de l’Internet et l’AFUL, pour leur motivation et leur aide au moment de véritablement démarrer,
en 1998.
– Fabrice Lemoine et Éric Mercier pour la relecture de ce document
56

Un réseau Debian GNU/Linux pour un centre de formation

Transcription

Documents pareils

Curriculum Vitae - Julien BLACHE

Trucs et astuces Debian

Debian

Création de fichiers MP3 par extraction des pistes d`un CD audio

TP 01 : Installation Serveurs

Comparatif Debian compilÃ© contre Debian gÃ©nÃ©rique

installation reseau Linux

Lettre de motivation exemple gratuit

Ecran d`accueil du CD d`installation Debian

Le LOGICIEL LIBRE à Billy-Berclau - Club LinuX Nord