Savoir programmer son serveur Linux avec PostFix, DNS, Samba et Amanda

CHAPITRE 1 POSTER ET RECEVOIR DU COURRIER AVEC POSTFIX ......................................... 4

INTRODUCTION .................................................................................................................................................. 4 INSTALLATION DE POSTFIX ............................................................................................................................... 5 PREMIERE CONFIGURATION............................................................................................................................... 7 POUR ALLER UN PEU PLUS LOIN....................................................................................................................... 12 LA REECRITURE DE L'ADRESSE DE L'EXPEDITEUR ........................................................................................... 15 GESTION DES ADRESSES LOCALES................................................................................................................... 16 CONCLUSION ET REMERCIEMENTS .................................................................................................................. 17

CHAPITRE 2 POSTFIX............................................................................................................................... 18

POSTFIX ........................................................................................................................................................... 18 SPAMASSASSIN................................................................................................................................................ 19 ANOMY SANITIZER .......................................................................................................................................... 20 FILTRAGE AVEC POSTFIX :............................................................................................................................... 20 CLAMAV ......................................................................................................................................................... 21 OPTIMISATION DES PERFORMANCES (FACULTATIF) ........................................................................................ 22 UW-IMAP (POP3 ET IMAP AVEC SSL).............................................................................................................. 22

CHAPITRE 3 DNS BIND 1ERE PARTIE : SERVEUR "CACHE DNS"............................................... 24

INTRODUCTION ................................................................................................................................................ 24 THEORIE : FONCTIONNEMENT DU SERVICE DNS. ............................................................................................ 24 UN SERVEUR DNS QUI FAIT CACHE................................................................................................................. 25 LES FICHIERS DE ZONES................................................................................................................................... 27 CONFIGURATION DE L'UTILITAIRE DE CONTROLE RNDC.................................................................................. 28 CONFIGURATION DES FICHIERS SYSTEMES...................................................................................................... 28 TEST DE LA CONFIGURATION........................................................................................................................... 29 CA MARCHE PAS! ............................................................................................................................................. 29 REMARQUES SUR UN SERVEUR DNS CACHE ................................................................................................... 29

CHAPITRE 4 DNS BIND 2EME PARTIE : SERVEUR DE ZONE........................................................ 30

UN SERVEUR DNS POUR MON DOMAINE. ........................................................................................................ 30 LE FICHIER /ETC/NAMED.................................................................................................................................. 31 LE FICHIER DE ZONE DE MON DOMAINE........................................................................................................... 32 DETAIL DE L'EN-TETE. ..................................................................................................................................... 33 ENREGISTREMENT DE LA ZONE........................................................................................................................ 34 SERVEUR SECONDAIRE. ................................................................................................................................... 35 ET SI ÇA MARCHE PAS? .................................................................................................................................... 35

CHAPITRE 5 LE PROJET SAMBA........................................................................................................... 36

INSTALLER SAMBA......................................................................................................................................... 36 RECUPERATION ET INSTALLATION DES PAQUETAGES SAMBA. ....................................................................... 36 PREMIER TEST DE VOTRE INSTALLATION ........................................................................................................ 37 AUTOMATISER LE LANCEMENT DE SAMBA ..................................................................................................... 37 INSTALLATION DU SERVEUR D'IMPRESSION..................................................................................................... 38 LE FICHIER DE CONFIGURATION PRINCIPAL................................................................................................ 38 SECTION DE CONFIGURATION GENERALE ........................................................................................................ 39 SECTION DE CONFIGURATION DES PARTAGES DE FICHIERS............................................................................. 39 CONFIGURATION DES PARTAGES D'IMPRIMANTES........................................................................................... 40 COMMANDES UTILES...................................................................................................................................... 42 MONTER DES RESSOURCES DU SERVEUR DANS UN SYSTEME DE FICHIERS LINUX .......................................... 42 TESTER LA SYNTAXE DE SMB.CONF : TESTPARM ............................................................................................. 42 PARCOURIR LE RESEAU : SMBCLIENT .............................................................................................................. 42 MACHINES VISIBLES SUR LE RESEAU NETBIOS : FINDSMB............................................................................... 42 RESOUDRE LES NOMS NETBIOS : NMBLOOKUP ................................................................................................ 43 LISTER LES CONNEXIONS AU SERVEUR : SMBSTATUS...................................................................................... 43 EXEMPLE DE CONFIGURATION...................................................................................................................... 43 TEST DE VOTRE INSTALLATION DEPUIS WINDOWS© .................................................................................. 44 GESTION DES UTILISATEURS ET DES GROUPES ............................................................................................ 44 LES DIFFERENTS TYPES D'UTILISATEURS SAMBA ............................................................................................ 45 SYNCHRONISER LES UTILISATEURS ................................................................................................................. 45 GESTION DES GROUPES.................................................................................................................................... 45 OUTILS GRAPHIQUES DE CONFIGURATION D'UN SERVEUR SAMBA ............................................................ 45 KSAMBAPLUGIN.............................................................................................................................................. 46 MODULE SAMBA POUR WEBMIN..................................................................................................................... 47 OUTIL GRAPHIQUE DE PARCOURS DES RESSOURCES SAMBA........................................................................... 49 CONCLUSION .................................................................................................................................................. 49 QUELQUES ADRESSES UTILES .......................................................................................................................... 49 LE SITE OFFICIEL DE CUPS............................................................................................................................. 49

CHAPITRE 6 AMANDA.............................................................................................................................. 50

ERIC DOUTRELEAU, ERIC.DOUTRELEAU@INT-EVRY.FR............................................................................... 50 1. AVERTISSEMENT.......................................................................................................................................... 50 2. INTRODUCTION ............................................................................................................................................ 50 3. POURQUOI UNE SAUVEGARDE EN RESEAU................................................................................................... 50 3.1 NECESSITE DE LA SAUVEGARDE. ............................................................................................................... 50 3.2 L'ORGANISATION DES ORDINATEURS......................................................................................................... 50 3.3 L'UTILISATEUR DE LA MACHINE. ............................................................................................................... 50 3.4 LA SAUVEGARDE INCREMENTALE. ............................................................................................................ 50 3.5 CONCLUSION.............................................................................................................................................. 50 4. STRUCTURE D'AMANDA ........................................................................................................................... 51 4.1 PRESENTATION........................................................................................................................................... 51 4.2 LES POINTS FORTS D'AMANDA................................................................................................................ 51 4.3 STRATEGIE MAITRE-ESCLAVE.................................................................................................................... 51 5. LE MECANISME. ........................................................................................................................................... 52 5.1 SUR LE SERVEUR. ....................................................................................................................................... 52 5.2 SUR LES CLIENTS........................................................................................................................................ 52 5.3 L'ORDONNANCEMENT. ............................................................................................................................... 52 6. QUELQUES REMARQUES SUR L'INSTALLATION. ........................................................................................... 53 6.1 DEPARTEMENTS CONCERNES..................................................................................................................... 53 6.2 GENERALITES............................................................................................................................................. 53 6.3 COMMENT INSTALLER AMANDA............................................................................................................. 54 6.4 CONFIGURATION DU CHANGEUR DE BANDE. ............................................................................................. 56 7. LA CONFIGURATION D'AMANDA............................................................................................................... 57 7.1 AMANDA.CONF........................................................................................................................................... 57 7.2 DISKLIST..................................................................................................................................................... 58 8. COMMENT SAUVEGARDER. .......................................................................................................................... 58 8.1 CHOISIR LA BANDE. ................................................................................................................................... 58 8.2 VERIFICATIONS .......................................................................................................................................... 58 8.3 LANCEMENT DE LA SAUVEGARDE. ............................................................................................................ 58 8.4 REPRISE APRES INCIDENT. ......................................................................................................................... 58 9. COMMENT RECUPERER SES FICHIERS DANS UNE SAUVEGARDE. ................................................................. 59 9.1 PROBLEMATIQUE. ...................................................................................................................................... 59 9.2 PROCEDURE RETENUE................................................................................................................................ 59 9.3 DESCRIPTION. ............................................................................................................................................ 59 9.4 EXEMPLE.................................................................................................................................................... 59 10. LISTE DES COMMANDES DISPONIBLES. ...................................................................................................... 62 11. CONCLUSION.............................................................................................................................................. 63

Chapitre 2 Poster et recevoir du courrier avec Postfix Version 0.7 -- 29 octobre 2000d

Éric Jacoboni <jaco@linux-france.org> Copyright © 2000 par Éric Jacoboni

Introduction À propos de ce document Ce document, comme d'habitude, ne se veut pas être un guide de référence ou une adaptation française de la documentation de postfix, très bien faite au demeurant. Il se borne à relater les manipulations que j'ai été amené à faire pour configurer le logiciel afin que je puisse recevoir et poster du courrier avec lui. Toutes critiques, positives ou négatives sont évidemment les bienvenues. Le site de référence de cette documentation est Linux-France qui contiendra toujours la version la plus récente. À partir de cette page, vous pouvez télécharger les sources DocBook/XML, la version au format PostScript et la version au format PDF de ce document.

Présentation La configuration décrite ici a été testée avec les systèmes d'exploitation Debian GNU/Linux, et FreeBSD. En fait, le système utilisé a peu d'importance du moment qu'il est reconnu par Postfix. Ce qui est décrit ci-après devrait donc s'appliquer dans tous les cas, le cas échéant à quelques modifications mineures près. Notons que, pour Linux, des paquetages précompilés existent : la Debian, notamment, permet d'installer directement le programme via dpkg ou apt-get et j'imagine qu'il existe également des paquetages rpm. Le problème, avec ces paquetages binaires, est qu'ils ne permettent pas de suivre les fréquents changements du logiciel ; or, celui-ci étant en phase de développement, les nouvelles versions ajoutent de nouvelles fonctionnalités souvent fort intéressantes... Concernant les autres Unix, il n'y a aucune raison pour que le fonctionnement soit différent : la documentation cite d'ailleurs une liste de tous les systèmes pris en charge. Je n'ai personnellement vu aucune différence entre l'installation sous Linux et sous FreeBSD (dont les scripts d'initialisation sont bien distincts). La distribution officielle de Postfix peut être récupérée sur son site officiel, ou sur l'un des sites miroirs français. La distribution actuelle est postfix-19991231.08. Il ne sera pas traité ici de la récupération du courrier venant de l'extérieur (du serveur de courrier de son fournisseur d'accès si l'on est, comme moi, relié via une connexion téléphonique). Pour cela, d'autres documentations existent, consultez notamment le site Linux-France.

Installation de Postfix Installation à partir de la distribution source

Compilation Le logiciel se récupère sous la forme d'un fichier .tar.gz que l'on décompresse dans un répertoire d'installation :

# tar xvzf postfix-19991231-pl08.tar.gz -C /tmp # cd /tmp/postfix-19991231-pl08/

Dans ce répertoire se trouve un fichier INSTALL fort clair (mais en anglais) qu'il suffit de suivre pas à pas pour installer et configurer postfix. La première étape consiste à générer les exécutables :

# make

Il faut ensuite déplacer les fichiers binaires, de configuration et les pages de manuel dans les répertoires adéquats de votre système. Sous le répertoire d'installation, vous devez normalement avoir les répertoires conf, bin, libexec, html et man (les autres répertoires sont ceux contenant les sources, des exemples et les fichiers objets générés par la compilation).

Installation de la documentation Pour installer les pages de manuel, il suffit de déplacer le contenu des répertoires /tmp/postfix-19991231-pl08/man/man* dans les répertoires correspondants sur votre système (/usr/man/man* sur une machine Linux, /usr/local/man/man*) sur une machine FreeBSD). Puis, vous pouvez installer le reste de la documentation. Pour rester compatible avec les documentations des autres logiciels de mon système Linux, vous pouvez créer un répertoire /usr/doc/postfix dans lequel vous déplacerez tous les fichiers de documentation du répertoire d'installation (leurs noms sont en majuscules). Créez également le répertoire /usr/doc/postfix/html et déplacez-y le contenu du répertoire html de l'installation (pour FreeBSD, on fait de même et on crée l'arborescence /usr/local/share/doc/postfix).

Installation des fichiers de configuration Sous Linux, tous ces fichiers vont dans un seul emplacement : /etc/postfix, sous FreeBSD, ils iront dans /usr/local/etc/postfix. Je me bornerai ici à suivre ce qui est indiqué dans INSTALL (adaptez le chemin des fichiers de configuration à votre système) :

# mkdir /etc/postfix # chmod 0755 /etc/postfix # mv /tmp/postfix-19991231-pl08/conf/* /etc/postfix # chmod 0644 /etc/postfix/* # chmod 0755 /etc/postfix/postfix-script*

Création des files d'attente Postfix utilise une arborescence beaucoup plus élaborée que celle de ses prédécesseurs pour placer les messages en attente de délivrance. Il suffit ici d'en indiquer la racine (/var/spool/postfix/, généralement) car tous les autres sous-répertoires y seront créés lors du premier démarrage de postfix :

# mkdir /var/spool/postfix # chmod 0755 /var/spool/postfix

Vous pouvez choisir un autre emplacement : celui-ci devra être indiqué lors de la configuration que nous étudions plus loin.

Installation des exécutables Là encore, vous êtes libres de choisir l'emplacement qui vous convient car il suffira ensuite de l'indiquer lors de la configuration. La méthode généralement pratiquée consiste à séparer les commandes des démons : les premières sont initialement dans le répertoire bin et iront dans /usr/local/sbin avec des liens de /usr/sbin vers eux), les seconds sont initialement dans libexec et iront dans /usr/local/libexec/postfix) :

# cd /tmp/postfix-19991231-pl08/bin # cp post* sendmail /usr/local/sbin # mkdir /usr/local/libexec/postfix # cp `ls | egrep -v 'post|fsstone|smtp-|sendmail'`/usr/local/libexec/postfix

Droits d'accès à la file d'attente Il s'agit ici de permettre l'accès des utilisateurs locaux au répertoire /var/spool/postfix/maildrop. Par défaut, tous les sous-répertoires de /var/spool/postfix appartiennent au groupe root. Or, lorsque les utilisateurs postent un courrier, celui-ci transite d'abord par le répertoire maildrop. Avec les droits actuels, ces courriers seraient donc refusés. Plusieurs possibilités, décrites dans le fichier INSTALL, sont possibles : rendre le répertoire maildrop accessible à tout le monde, ou utiliser la commande postdrop en sgid. Nous avons retenu la première solution. Pour ce faire, il suffit de modifier les droits d'accès du répertoire maildrop :

# chmod 1733 /var/spool/postfix/maildrop

Cette solution suppose que vous ayez confiance en vos utilisateurs locaux... Si ce n'est pas le cas, préférez-lui la solution du postdrop en sgid (décrite dans le fichier INSTALL). L'invocation de la commande postdrop lors de l'envoi d'un message est réalisée automatiquement via l'appel du script postfix-script qu'il s'agit donc de rendre accessible à tout le monde :

# cp /etc/postfix/postfix-script-nosgid /etc/postfix/postfix-script

Utilisation de paquetages pré-compilés Si vous préférez utiliser des paquetages rpm ou deb, vérifiez les emplacements des différents fichiers et adaptez les chemins utilisés ici à votre configuration.

Première configuration Oublier sendmail ! Pour que postfix devienne votre agent de transport de courrier, vous devrez probablement désactiver sendmail. Même si vous ne l'avez jamais activé ou configuré, il y a fort à parier que ce dernier ait été installé par votre distribution Linux ! Pour cela, il suffit, encore une fois, de suivre ce que propose le fichier INSTALL :

# cd /usr/sbin # mv sendmail sendmail.OFF # ./sendmail.OFF -q # mv /usr/bin/newaliases /usr/bin/newaliases.OFF # mv /usr/bin/mailq /usr/bin/mailq.OFF # chmod 0 /usr/sbin/sendmail.OFF /usr/bin/newaliases.OFF \ /usr/bin/mailq.OFF # ln -s /usr/local/sbin/sendmail /usr/sbin/sendmail # ln -s /usr/local/sbin/sendmail /usr/bin/mailq # ln -s /usr/local/sbin/sendmail /usr/bin/newaliases

Et c'est fini... Ces quelques lignes sauvegardent les exécutables originaux de sendmail, vident sa file d'attente, ôtent toutes les permissions pour les protéger, et créent des liens symboliques ayant les mêmes noms que les originaux vers la commande sendmail de postfix.

Small is beautiful... La première chose qui frappe, quand on se plonge dans la documentation fournie avec postfix est son apparente simplicité... Finie la syntaxe ésotérique du sendmail.cf, finie la nécessité de passer par un ensemble de macros pour oser espérer comprendre un tant soit peu ce que l'on est en train de configurer : avec postfix tout se passe par l'adaptation d'un seul fichier, main.cf, normalement placé, comme tous ses autres fichiers de configuration, dans le répertoire /etc/postfix/ (ou /usr/local/etc/postfix/). Enfin, presque... nous verrons plus tard que d'autres fichiers doivent être adaptés, mais tous sont humainement lisibles et richement commentés. À la différence de sendmail, programme monolithique par excellence, postfix est composé de nombreux petits programmes réalisant chacun une tâche bien définie. Pour la plupart, ces programmes ne sont pas vus de l'utilisateur mais appelés directement par le programme serveur /usr/sbin/postfix. Le lancement de celui-ci au démarrage du système dépend de l'Unix utilisé : avec un System V (Linux en fait partie, sauf la distribution Slackware), il est lancé via le script /etc/init.d/postfix selon la méthode habituelle des runlevels ; sur FreeBSD, il est lancé via la ligne sendmail_enable="YES" dans le fichier /etc/rc.conf (vous comprendrez plus loin ce que sendmail vient faire ici...). Sur les systèmes BSD, on peut également utiliser le fichier /etc/rc.local :

% cat /etc/rc.local postfix start

Démarrage de postfix Ainsi que nous venons de le dire, quel que soit le système utilisé, c'est un script qui lance le serveur /usr/sbin/postfix en lui passant le paramètre start. Celui-ci lance à son tour le serveur principal, /usr/libexec/postfix/master qui prend alors les choses en main et lancera les autres démons lorsque cela sera nécessaire. Ces derniers se termineront après avoir accompli leurs tâches ou après une certaine période d'inactivité. Seul, le démon de gestion de la file d'attente, /usr/libexec/postfix/qmgr reste en permanence en activité. Tout ceci peut se vérifier par une simple commande ps (ici sous FreeBSD, d'où la présence de ces serveurs sous /usr/local/) :

% ps axf ... 583 ? S 0:00 /usr/local/libexec/postfix/master 584 ? S 0:00 \_ pickup -t fifo -c 585 ? S 0:00 \_ qmgr -t fifo -u -c ...

qui met en évidence la présence du démon master et le fait qu'il a lui-même lancé les démons pickup et qmgr (la commande ps utilisée ici est celle de GNU, l'option -f n'a pas la même signification avec un ps BSD). pickup est responsable de la récupération des courriers locaux : comme nous l'écrivions plus haut, pour des raisons de compatibilité, postfix utilise un programme nommé /usr/sbin/sendmail (qui n'est pas le programme sendmail bien connu, mais un homonyme). Ce programme est utilisé pour déposer les courriers locaux dans la file d'attente maildrop : tous les courriers qui sont postés par tous les utilisateurs sont déposés dans cette file. pickup les récupère alors et les passe au démon cleanup qui remplira les en-têtes manquants, gérera les enveloppes des messages et les déposera enfin dans une autre file d'attente, nommée incoming. Puis cleanup avertira le gestionnaire de file d'attente, qmgr, qu'un nouveau courrier est arrivé. qmgr s'occupera alors de délivrer le courrier dans les boîtes aux lettres de leurs destinataires et de gérer les erreurs. Nous verrons plus loin les autres démons entrant en jeu dans la délivrance du courrier. Passons maintenant à une configuration minimum pour tester localement postfix.

Configuration minimale Notre but, ici, est d'arriver à poster et recevoir du courrier en local : par exemple, root doit pouvoir poster un message à l'utilisateur babe. Ce dernier doit pouvoir récupérer le message, le lire et répondre à root. Pour simplifier, nous utiliserons le programme canonique mail. Nous supposerons que notre machine s'appelle alex et que notre domaine s'appelle linux-france.org. Vérifions tout de suite que c'est le cas :

% hostname alex.linux-france.org

Ainsi que nous l'avons déjà dit, la majeure partie du travail de configuration consiste à adapter le fichier /etc/postfix/main.cf (ou /usr/local/etc/postfix/main.cf) à nos besoins. Bien entendu, tout cela doit se faire sous le compte root. La première chose à faire est de sauvegarder le fichier original :

# cp /etc/postfix/main.cf /etc/postfix/main.cf.0

Puis, chargez main.cf dans votre éditeur de texte favori. Normalement, un certain nombre d'options sont déjà en place. Certaines conviennent, d'autres non. Voici les lignes qui nous intéressent (les commentaires et les lignes non modifiées ont été supprimés) :

# INFORMATIONS SUR LES REPERTOIRES LOCAUX queue_directory = /var/spool/postfix command_directory = /usr/local/sbin daemon_directory = /usr/local/libexec/postfix # POSSESSION DES FILES D'ATTENTE ET DES PROCESSUS mail_owner = postfix # NOMS DE LA MACHINE ET DU DOMAINE myhostname = alex.linux-france.org # POUR L'ENVOI DU COURRIER myorigin = $myhostname # MODE DE TRANSPORT default_transport = smtp # GESTION DES ALIAS alias_maps = hash:/etc/postfix/aliases alias_database = hash:/etc/postfix/aliases # DELIVRANCE DU COURRIER mailbox_command = /usr/local/bin/procmail

Assurez-vous que toutes les autres possibilités pour ces lignes soient considérées comme des commentaires en les faisant précéder du caractère dièse (#) et ne modifiez pas les autres. Avant de tester tout cela, détaillons rapidement les options choisies (pour des renseignements plus précis, reportez-vous aux pages de manuel et à la documentation fournie avec le programme). La première section sert à spécifier les emplacements :

/var/spool/postfix

est le répertoire de base pour toutes les files d'attente de postfix, Lors de son premier lancement, postfix créera tous les sous-répertoires pour ses files sous ce répertoire ;

/usr/local/sbin

est le répertoire où se trouvent les commandes de postfix (les exécutables dont le nom commence par post, et sa version de sendmail) ;

/usr/local/libexec/postfix

est le répertoire contenant les démons de postfix : c'est là que se trouvent tous les programmes serveurs qu'il utilise.

La deuxième section précise qui est le propriétaire de la file d'attente et de la plupart des processus serveurs de postfix. Ici, nous avons conservé la proposition, après avoir créé l'utilisateur postfix. Voici son entrée dans notre fichier /etc/passwd :

postfix:x:101:101::/var/spool/postfix:/bin/false Le 'x' dans la partie mot de passe vient du fait que nous utilisons les « shadow passwords ». Le groupe 101 correspond au groupe postfix, lui aussi créé pour l'occasion :

# grep 101 /etc/group postfix:x:101:

La troisième section sert à indiquer le nom complet de notre machine. La section suivante concerne l'envoi du courrier : elle permet de renseigner postfix sur la machine qui a posté. Pour le moment, nous considérerons que c'est ce que contient la variable $myhostname. Nous précisons ensuite le protocole utilisé pour l'acheminement du courrier. Pour l'instant, postfix ne reconnaît que smtp et uucp (en réalité, on peut créer des transports dans /etc/postfix/master.cf, ce qui permet de changer des paramètres en fonction de multiples critères. On peut ainsi dupliquer le transport smtp et en changer les caractéristiques en fonction des courriers entrants ou sortants ce qui est très souple. Toutefois, ne l'ayant pas pratiqué, je n'en dirais pas plus... ). La gestion des alias peut faire appel au fichier /etc/aliases utilisé par ses prédécesseurs mais nous préférons en utiliser un autre : /etc/postfix/aliases (ou /usr/local/etc/postfix/aliases). La commande man aliases vous renseignera en détail sur le format de ce fichier. Disons simplement que, comme son nom l'indique, il permet de définir des alias entre des noms de destinataires. Ainsi, par exemple, un serveur de news poste quotidiennement un rapport sur ses activités à l'utilisateur news (ou usenet). Supposons que babe soit l'administrateur des news sur alex : pour qu'il puisse recevoir ces messages, et si root est d'accord, bien entendu, il suffit d'indiquer que les destinataires news et usenet ont pour alias babe. Ceci est réalisé par l'ajout de la ligne suivante dans /etc/postfix/aliases :

news: babe usenet: babe

Pour des raisons d'optimisation, postfix, comme ses prédécesseurs, demande à ce que ce fichier soit traité comme une base de données au format DBM ou DB. Pour générer ces formats, on utilise l'utilitaire /usr/sbin/postalias (qui, rappelons-le, est un lien vers /usr/local/sbin/postalias). Ma machine ne reconnaissant pas le format DBM, j'ai donc opté pour le second et produit la base à l'aide de la commande :

# postalias hash:/etc/postfix/aliases

qui a engendré le fichier /etc/postfix/aliases.db. La section concernant la délivrance du courrier local indique ici que nous souhaitons utiliser procmail pour cette tâche. Tout autre programme ayant la même fonction peut convenir (deliver, par exemple), mais procmail est le plus connu dans le monde Linux et FreeBSD. Cette section ne concerne que l'acheminement local du courrier, ie. son écriture dans les boîtes aux lettres des destinataires.

Test de la configuration locale Après toute modification de l'un des fichiers que nous venons d'étudier, il faut demander à postfix de relire sa configuration :

# postfix reload

À l'aide de la commande ps ax, vérifiez la présence des démons master, pickup et qmgr. Si vous ne les voyez pas, c'est qu'il y a eu un problème : consultez les fichiers /var/log/mail.* pour tenter d'en rechercher la cause. Si tout s'est bien passé, root va pouvoir envoyer un courrier à babe :

# mail babe -s test premier test local . Cc: #

Immédiatement, babe a dû recevoir ce courrier :

% mail Mail version 8.1 6/6/93. Type ? for help. "/var/spool/mail/babe": 1 message 1 new >N 1 root@alex.linux-france.org. Wed Jan 20 01:46 12/424 "test" & 1 Message 1: From root@alex.linux-france.org Wed Jan 20 01:46:10 1999 Delivered-To: babe@alex.linux-france.org To: babe@alex.linux-france.org Subject: test Date: Wed, 20 Jan 1999 01:46:10 +0100 (CET) From: root@alex.linux-france.org premier test local & d & q

On notera la présence d'un champ Delivered-To: : il est ajouté par postfix afin d'éviter les boucles dans la délivrance du courrier et ne sera pas affiché par défaut avec la plupart des logiciels de lecture du courrier (en tous cas, avec Gnus et Netscape...). Essayons encore : maintenant postez sous le compte babe un message à root et vite, très vite, faites ps axf. Sous Linux, vous devriez voir les lignes suivantes :

1271 ? S 0:00 /usr/local/libexec/postfix/master 1272 ? S 0:00 \_ pickup -t fifo -c 1273 ? S 0:00 \_ qmgr -t fifo -u -c 1286 ? S 0:00 \_ cleanup -t unix -u -c 1287 ? S 0:00 \_ trivial-rewrite -n rewrite -t unix -u -c 1288 ? S 0:00 \_ local -t unix

Assez rapidement, vous remarquerez, si vous faites la même commande, que cleanup et local se sont terminés, tandis que trivial-rewrite survit plus longtemps, puis se termine. Tout ceci correspond ce que nous disions plus haut : pickup a récupéré le message et l'a passé à cleanup. trivial-rewrite s'est chargé de réécrire l'adresse en rajoutant le nom de la machine locale derrière le nom de l'utilisateur. local est le démon responsable de la délivrance locale du message dans la boîte aux lettres du destinataire. C'est à ce moment que le fichier des alias est pris en compte et, si le destinataire utilise un fichier ~/.forward, local le fait suivre à l'adresse indiquée. C'est local qui ajoute le champ Delivered-To: pour éviter un bouclage intempestif et c'est lui qui remplit le champ From de l'enveloppe (à ne pas confondre avec le champ From:...). Pour finir cette partie, il ne vous reste plus qu'à essayer de faire la même chose avec vos logiciels de lecture de courrier favoris : cela ne devrait pas poser de problème puisque local délivre les messages à l'endroit où la plupart des logiciels s'attendent à les trouver.

Pour aller un peu plus loin... Les files d'attente Lorsqu'on a l'habitude d'utiliser sendmail, la multiplicité des files d'attente de postfix a tendance à dérouter. En effet, en lieu et place du classique et unique /var/spool/mqueue/ on se retrouve avec l'arborescence suivante :

# tree /var/spool/postfix/ /var/spool/postfix/ |-- active ... |-- deferred | |-- 048ED779D1 | |-- 09085779E0 | |-- 17101779D6 | |-- 31DE0779DA | |-- 3D15D779D4 | |-- 4D2BD779D7 | |-- 7BFA6779D3 | |-- 7C65D779CF | |-- B10C3779D0 | `-- C3272779D2 ... |-- incoming ... |-- maildrop ...

Nous avons abrégé la sortie de cette commande pour ne retenir que les noms de répertoires qui nous intéressent ici. postfix utilise quatre files d'attentes : maildrop

contient les messages locaux ;

incoming

contient les messages qui ont été prélevés dans maildrop par le démon pickup, puis qui ont été traités par le démon cleanup. Cette file contient aussi les messages venant de l'extérieur. En bref, elle contient les messages qui n'ont pas encore été traités par le gestionnaire de file d'attente qmgr ;

active

est une file contenant les messages en cours de délivrance par qmgr ;

deferred

contient les messages qui n'ont pas pu être délivrés (il y en a 10 dans notre exemple). De plus, le répertoire /var/spool/postfix/defer contient les mails en attente plus longue et des répertoires qui sont « hachés » afin de ne pas avoir des répertoires contenant trop de fichiers : ainsi, le fichier 7B345AC0B1, par exemple, sera dans defer/7/B/7B345AC0B1. La documentation HTML de la distribution postfix dispose d'un schéma présentant clairement les interactions entre les différentes files d'attente et les différents démons. C'est d'ailleurs de lui que je me suis inspiré... Le contenu de la file d'attente peut être consulté avec la commande mailq (les habitués de sendmail ne seront pas dépaysés...) : normalement celle-ci ne doit produire que les messages dont la délivrance n'a pas encore eu lieu (dans notre cas, les 10 messages contenus dans la file deferred).

Les commandes de postfix Nous avons déjà vu que postfix s'invoquait en lui passant un paramètre qui précisait l'action à entreprendre. Ainsi, les paramètres stop et start arrêtent et démarrent le serveur, respectivement. D'autres commandes existent :

reload

force postfix à relire ses fichiers de configuration (en fait, il s'agit de deux appels consécutifs à postfix : l'un avec le paramètre stop, l'autre avec le paramètre start) : cette commande s'avère donc nécessaire après la modification du fichier main.cf, par exemple ;

check

permet de vérifier la configuration du système de courrier. Ce paramètre permet aussi de surveiller les différentes permissions des répertoires utilisés par postfix, et de créer ces répertoires s'ils n'existent pas. Si la configuration est correcte, et si l'option -v n'a pas été utilisée, cette commande ne produit aucune sortie ;

flush

force postfix à tenter de vider la file deferred, donc à envoyer les messages en attente de délivrance.

Enfin, last but not least, la distribution postfix fournit le programme postconf pour afficher les paramètres modifiés par notre configuration (postconf -n), les valeurs par défaut du logiciel (postconf -d) et l'ensemble des valeurs courantes des paramètres (postconf). Voici, à titre d'exemple, ce que donne la première commande sur ma configuration personnelle actuelle :

# postconf -n alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases command_directory = /usr/local/sbin daemon_directory = /usr/local/libexec/postfix debug_peer_level = 2 default_destination_concurrency_limit = 10 default_transport = smtp defer_transports = smtp local_destination_concurrency_limit = 2 mail_owner = postfix mailbox_command = /usr/local/bin/procmail myhostname = alex.linux-france.org myorigin = $myhostname program_directory = /usr/local/libexec/postfix queue_directory = /var/spool/postfix relayhost = [smtp.mon.fai] sender_canonical_maps = hash:/etc/postfix/canonical

Nous n'avons pas encore vu certains de ces paramètres ? C'est normal. Nous allons maintenant nous en occuper...

Envoyer du courrier non local Bien, nous savons maintenant que postfix fonctionne correctement avec les adresses locales à notre machine (si ce n'est pas le cas, n'allez pas plus loin et revenez ici lorsque le problème sera réglé...). Allons maintenant à la conquête du monde... La meilleure chose à faire, tant que tous nos tests n'ont pas donné satisfaction, est d'utiliser un « écho » : ie. une adresse où nous pourrons envoyer un courrier qui nous sera retourné tel qu'il a été reçu. Ceci nous permettra de vérifier au moins deux choses :

• que notre message a bien été acheminé à cette adresse ;

• que les entêtes de notre message sont corrects (c'est important car certains sites refusent les messages provenant de sites non connus : voir la section sur le « masquage » des adresses).

<echo@cnam.fr> est une adresse de ce type, et nous l'utiliserons ici. Tout le courrier sortant de notre machine est d'abord envoyé au serveur de courrier de notre fournisseur d'accès qui se chargera ensuite de l'envoyer sur l'Internet. Dans la terminologie classique, cela s'appelle un hôte relais (ou relayhost, en anglais). Il faut donc indiquer à postfix le nom de cet hôte relais. Si l'on suppose que nous sommes abonnés au fournisseur d'accès bien connu mon.fai et que la machine s'occupant du courrier chez ce fournisseur s'appelle smtp.mon.fai, il faut modifier le fichier main.cf, rechercher les lignes contenant relayhost, en décommenter une et mettre :

relayhost = [smtp.mon.fai] Le format indiqué ici suppose que nous utilisons SMTP (spécifié par la variable default_transport) pour transporter notre courrier. En réalité, le format de relayhost permet aussi d'indiquer une machine UUCP bien que le transport par défaut reste SMTP pour un intranet local, par exemple (voir les commentaires associés à cette variable dans main.cf pour connaître toutes les possibilités). Puis, comme à chaque modification de ce fichier, il faut faire postfix reload. Essayons maintenant la commande suivante :

% mail echo@cnam.fr -s test essai d'envoi de courrier via postfix . Cc: %

Puis, examinons la file d'attente :

% mailq -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- 9C26D779D0 351 Wed Jan 20 21:23:55 babe@alex.linux-france.org (Name service error for domain cnam.fr: Host not found, try again)

N'étant relié à l'Internet qu'épisodiquement, via une connexion PPP à un fournisseur d'accès (F.A.I.), le domaine cnam.fr ne pourra être connu que lorsque nous serons connectés, par consultation du serveur de noms de notre F.A.I. Ce n'était pas le cas ici, et ce ne le sera pas souvent : pour économiser sur la facture téléphonique, on a tout intérêt à composer son courrier en étant déconnecté et à tout expédier d'un seul coup lors de la connexion suivante. postfix nous prévient de cet état de fait grâce au message Name service error for domain cnam.fr de la commande mailq. Lors de notre prochaine connexion, il suffira simplement d'appeler la commande postfix flush (ou sendmail -q pour les nostalgiques...) pour que le courrier en attente soit à nouveau délivré.

Attention

sur ma machine, par exemple, seul root a le droit de faire postfix flush, un utilisateur normal devra utiliser /usr/sbin/sendmail -q pour envoyer les messages. La documentation de postfix vous expliquera pourquoi.

Lorsque l'on est, comme moi, connecté épisodiquement, le mieux est donc d'indiquer à postfix de déférer la délivrance des courriers. Ceux-ci seront alors placés dans la file d'attente et il ne tentera plus de les envoyer sauf si on le lui demande explicitement via un sendmail -q. Ce type de fonctionnement est tout à fait adapté aux connexions épisodiques (on peut mettre le sendmail -q dans un script de post-connexion) et est piloté par la variable defer_transports du fichier main.cf :

defer_transports = smtp Ceux qui se sont longtemps battu pour contourner ce problème avec sendmail, le vrai, apprécieront cette simplicité...

Nous pouvons aussi aller directement inspecter le contenu des files d'attente de postfix : vous noterez alors que le numéro 9C26D779D0 apparaît en deux endroits :

• dans le répertoire /var/spool/postfix/defer/9/C/ : si vous regardez le contenu de ce fichier, vous noterez qu'il contient simplement le message indiquant le problème de résolution de l'adresse de destination.

• dans le répertoire /var/spool/postix/deferred : l'édition du contenu du fichier vous permettra de constater que toutes les informations y sont, mais formatées d'une façon peu lisible...

Il existe une commande, assez primitive pour l'instant, appelée postcat qui permet d'afficher sous une forme plus lisible les messages dans les files de postfix.

La réécriture de l'adresse de l'expéditeur Énoncé du problème Vous avez passez probablement passé beaucoup de temps à trouver un nom pour votre chère machine, et vous êtes sûr d'avoir fait preuve d'imagination en l'ayant appelé warlordz.kill.windows : je doute que ce soit original, mais cela change de localhost.localdomain... Quoi qu'il en soit, un problème va maintenant se poser : avec cette configuration, et un tel nom de machine, le champ From: de vos courriers sera, par exemple bugs@warlordz.kill.windows, ou lamer@warlordz.kill.windows. Cela ne posera pas de problème quand l'utilisateur bugs postera un courrier à lamer puisqu'il s'agira d'une délivrance locale, mais cela risque d'en poser lorsque bugs enverra un courrier à postmaster@site.serieux... En effet, pour éviter les courriers indésirables (aka SPAM ou UCE) postés par de tristes sires, le système de courrier de site.serieux a sûrement mis en place une protection toute simple : tout message dont l'adresse d'expéditeur n'appartient pas à un domaine connu sera directement mis au panier (il y a même des sites qui vont plus loin en bannissant les messages venant de domaines connus... pour être assez laxistes quant à l'émission de ces fameux SPAMs). Qu'est-ce qu'un « domaine connu » ? Un domaine dûment enregistré auprès des instances de l'Internet et je suppose que vous n'avez pas payé le NIC pour déposer le domaine warlordz.kill.windows, non ? En conséquence, site.serieux, lorsqu'il recevra un message venant de votre domaine, recherchera dans ses tablettes s'il connaît ce nom et, comme ce ne sera pas le cas, votre précieuse missive ira se perdre dans les oubliettes de l'histoire, sans même que vous en soyez averti.. Un autre problème est que, même si le message n'était pas rejeté et que postmaster@site.serieux lui répondait, le message de réponse serait donc envoyé à bugs@warlordz.kill.windows. Là encore, le site n'étant pas connu, pas même de votre fournisseur d'accès, la réponse se perdra dans la nature (ou plutôt non, elle reviendra à postmaster@site.serieux, ce qui ne manquera pas de l'agacer...). Pour corriger ces deux problèmes, il faut donc faire en sorte que l'adresse bugs@warlordz.kill.windows soit remplacée, lors de l'expédition du message par une adresse valide au sens de l'Internet, donc dûment déclarée. Pour ce faire, nous supposerons que vous êtes abonné au fournisseur d'accès fai.fr (qui, lui, est enregistré et donc connu de tous les sites Internet). Lorsque vous vous êtes abonné, le fournisseur vous a octroyé un nom pour votre boîte aux lettres (selon les cas, c'est vous qui proposez le nom, ou bien lui qui vous l'impose). Admettons que cette adresse soit jdupont@fai.fr (ce qui, je vous l'accorde, est bien moins fun que bugs@warlordz.kill.windows... que les Dupont me pardonnent, mais ce n'est qu'un exemple). Nous avons trois méthodes pour régler le problème :

• la première consiste à se plier aux exigences et, la mort dans l'âme, à rebaptiser sa machine fai.fr et à renommer l'utilisateur bugs en jdupont : ainsi, l'adresse d'expédition sera correcte. Pas terrible... et adieu la rebellion against ze oueurlde ! (il manque des fautes d'orthographe pour faire vrai...) ;

• la deuxième consiste tout simplement à faire enregistrer son domaine auprès d'un organisme dûment accrédité, et donc à dépenser les économies que l'on réservait à l'achat de la prochaine cartouche pour sa Gomme Baille Color (il existe également des possibilités pour enregistrer gratuitement un nom de domaine, si l'on dispose des ressources matérielles et des compétences nécessaires : voir le site www.eu.org). Cette solution implique également d'autres contraintes purement techniques et nous ne la détaillerons donc pas ici.

• la troisième, celle qui sera étudiée ici, consiste à configurer postfix pour qu'il réécrive l'adresse de l'expéditeur, qu'il « maquille » l'adresse bugs@warlordz.kill.windows en jdupont@fai.fr.

La réécriture et le masquage du champ From: postfix, comme son prédecesseur, permet de modifier le champ From:, qui contient l'adresse de l'expéditeur. Par défaut, cette option n'est pas active et il va donc falloir modifier notre configuration pour l'utiliser. Le principe est très simple :

• on indique à postfix qu'il doit utiliser une table de réécriture des adresses des expéditeurs. Cette table s'appelle canonical et sera placée dans /etc/postfix/ (ou /usr/local/etc/postfix/), son format est décrit par la commande man 5 canonical. Dans notre cas, le fichier canonical devrait donc contenir :

bugs jdupont@fai.fr

• à partir de ce fichier, on génère un fichier au format DB avec la commande postmap /etc/postfix/canonical, comme on l'a fait pour le fichier des alias ;

• dans la section ADDRESS REWRITING (Réécriture des adresses), prévue à cet effet dans main.cf (et initialement vide), on ajoute la ligne suivante :

sender_canonical_maps = hash:/etc/postfix/canonical

• on force postfix à relire ce fichier en faisant postfix reload.

Et c'est tout... Il reste à notre ami Jean Dupont, euh... pardon, à bugs à envoyer un message de test (local ou à une adresse écho) afin de vérifier si la réécriture s'est bien effectuée.

Gestion des adresses locales La gestion des adresses locales s'effectue très simplement par postfix. Dans la plupart des cas, vous n'aurez rien à faire. Ce qui suit ne doit donc être fait que dans certains cas bien précis. Supposons que votre machine reçoive des courriers à destination de gus@machin.uucp.fr (ce qui peut être le cas si vous utilisez également UUCP pour recevoir du courrier). Le problème consiste maintenant à faire comprendre à postfix que les messages à destination des adresses machin.uucp.fr doivent être considérées comme locales à votre machine, sinon il essaiera de les renvoyer... Pour ce faire, on utilisera un autre fichier de configuration : transport un peu comme on l'a fait pour aliases. La syntaxe de ce fichier est très simple et décrite par sa page de manuel (man transport). Dans notre cas, voici quel serait son contenu :

alex.linux-france.org local: localhost local: machin.uucp.fr local:

Toutes les adresses à destination de alex.linux-france.org, de machin.uucp.fr, ainsi, bien sûr, que les adresses locales seront alors considérées comme du courrier local à la machine. Comme aliases, le fichier transport doit être traité pour produire un fichier au format db :

# postmap /usr/local/etc/postfix/transport Il reste maintenant à indiquer à postfix qu'il doit utiliser cette table pour acheminer le courrier. Pour cela, on rajoute dans main.cf la ligne suivante :

transport_maps = hash:/usr/local/etc/postfix/transport qui aura priorité sur le contenu de la variable $mydestination (c'est pour ça que le contenu de celle-ci doit apparaître dans le fichier décrivant les adresses locales). La lecture de la page de manuel vous donnera toutes les autres informations nécessaires pour, par exemple, préciser pour une entrée donnée un type de transport particulier : si, par exemple, vous désirez utiliser UUCP pour expédier vos courriers à destination de truc.uucp.fr, il suffira d'ajouter l'entrée

truc.uucp.fr uucp:

Conclusion et remerciements Ceux que sendmail rebutait peuvent essayer postfix pour le transport de leur courrier : sa syntaxe est claire et l'ensemble est richement commenté. De plus, ses concepteurs ont pris soin de garder une compatibilité avec son géant de prédécesseur : sur ma machine, tous les programmes qui utilisaient sendmail pour lire et envoyer le courrier n'ont eu besoin d'aucune modification pour continuer à fonctionner, car cette compatibilité est un critère important pour les concepteurs de postfix (et essentielle pour espérer le remplacer). Je ne suis pas suffisamment expert pour comparer les fonctionnalités avancées des deux programmes mais, dans le cadre d'une utilisation personnelle, en machine isolée, aucune fonctionnalité de sendmail ne m'a manqué. Il faudrait voir ce que cela donne sur une configuration lourde (gestion du courrier sur un réseau découpé en sous-réseaux, gestion des listes de diffusion, etc.). La lecture du forum de discussion fr.comp.mail vous en apprendra plus sur ce sujet. Parmi ce qui manque -- bien que peu de particuliers en aient besoin -- ce sont les réécritures via des expressions rationnelles, par exemple. Ce sera probablement implanté dans une future version. Cet article est évidemment incomplet, imprécis et contient probablement des erreurs grossières... Je remercie donc d'avance tous ceux et celles qui prendront la peine de lire ce document, de le corriger et de l'annoter. J'essaierai de faire en sorte qu'il suive les évolutions futures de postfix (et celle de ma connaissance du transport de courrier) et toute aide est la bienvenue dans le contexte de cet article qui se veut simplement un guide d'initiation. La version actuelle de ce document à été soumise à la sagacité d'Ollivier Robert, de Nat Makarévitch et d' Olivier Tharan. Je les remercie particulièrement de leur aide en n'oubliant pas les contributeurs zélés de fr.comp.mail.

Chapitre 3 Postfix par Nicolas Agius Ce document va vous permettre d'installer un serveur mail complet (smtp, pop3, imap) avec filtrage anti-spams et anti-virus. Vous pourrez ensuite y ajouter apache avec Squirrelmail, par exemple, pour un accès webmail. Pour réaliser ceci, vous aurez besoin des logiciels suivants :

• Postfix (serveur smtp) • SpamAssassin (filtrage spam) • Anomy Sanitizer (filtrage mails erronés et douteux) • ClamAV (antivirus) • UW-IMAP (serveur pop3 et imap)

Ainsi que l'ensemble des scripts et fichiers que j'ai utilisés pour cette configuration : fichiers.tgz Cette documentation a été écrite avec les versions suivantes (du 04/2004) :

• postfix-2.0.19.tar.gz • Mail-SpamAssassin-2.63.tar.gz • anomy-sanitizer-1.66.tar.gz • clamav-0.65.tar.gz • imap-2004.RC7.tar.Z

Copiez ces fichiers dans /usr/src/ par exemple, vous en aurez besoins par la suite.

Postfix Postfix est un serveur smtp performant, simple à configurer et sécurisé. C'est un équivalent à Qmail, mais il est plus facile à mettre en place.

Installation Exécutez les commandes suivantes : # tar -xvzf postfix-2.0.19.tar.gz # cd postfix-2.0.19/ # make # groupadd postdrop # useradd postfix -d /dev/null -s /bin/false -c postfix # echo "postfix: root" >>/etc/aliases # make install Cette dernière commande va vous demander des informations : donnez les réponses par défaut. Si vous utilisez Mandrake, tapez simplement : # urpmi postfix Postfix est installé et les alias sont créés par défaut dans /etc/postfix/aliases. Éditer le fichier /etc/postfix/main.cf et modifier les lignes suivantes afin de mettre des paramètres adaptés : myhostname = mail.chezmoi.fr mydomain = chezmoi.fr myorigin = $mydomain mynetworks = 192.168.1.0/24, 127.0.0.0/8 #inet_interfaces = 192.168.1.1 mydestination = $myhostname, localhost.$mydomain, $mydomain Rq: le serveur DNS de votre domaine devra contenir l'enregistrement de mail.chezmoi.frPour définir des alias, ajouter à la fin du fichier /etc/aliases des lignes de la forme : nom_alias: destinataire Exemple : operateur: root N'oubliez pas de faire postalias /etc/aliases pour mettre à jour les modifications.

Lancement Copier ce script postfix dans /etc/rc.d/init.d (sans l'extension .txt) Lancement : /etc/rc.d/init.d/postfix start Pour lancer Postfix à chaque démarrage faites : # chkconfig --add postfix # chkconfig --level 345 postfix on Quelques commandes d'administration :

• Rechargement de la config : postfix reload • Forcer l'envoi des messages en attente : sendmail -q • Supprimer tous les messages en attente : postsuper -d aLL

Plus d'info : man postfix

SpamAssassin SpamAssassin est un filtre anti-spam performant avec des fonctionnalités d'auto-apprentissage.

Installation SpamAssassin a besoin d'un certain nombre de modules Perl (certains sont sans doute déjà installés sur votre machine) que l'on peut récupérer en utilisant la mise à jour par Internet CPAN (résolution des dépendances entre les modules). Si vous ne disposez pas de la mise à jour par internet, vous pouvez télécharger les modules manuellement sur http://www.cpan.org/ . # perl -MCPAN -e shell o conf prerequisites_policy ask install MIME::Base64 install MIME::QuotedPrint install HTML::Parser install Net::DNS install DB_File install Digest::SHA1 install Mail::SpamAssassin quit Vous pouvez aussi installer SpamAssassin à partir du tarball (Mail-SpamAssassin-2.63.tar.gz) , mais les modules perl devront être installés auparavant. Ensuite, copiez ce script de démarrage (sans l'extension .txt) spamd (présent dans les sources) dans le répertoire /etc/rc.d/init.d

Configuration La configuration se fait dans le fichier /etc/mail/spamassassin/local.cf, ajoutez-y les lignes suivantes : rewrite_subject 1 subject_tag [***SPAM***] Avec cette configuration, les messages détectés comme spam (avec un score supérieur à 5) auront leur champ Subject commençant par [***SPAM***] et un tag X-Spam-Level indiquant le score du message. Pour ne pas filter les messages des personnes que vous savez sûres, vous pouvez constituer une "liste blanche" en ajoutant à la fin de ce fichier (local.cf) des lignes de la forme : whitelist_from monpote@chezlui.fr Plus d'infos : perldoc Mail::SpamAssassin::Conf

Lancement La commande classique : /etc/rc.d/init.d/spamd start Pour lancer spamassassin à chaque démarrage : # chkconfig --add spamd # chkconfig --level 345 spamd on

Anomy Sanitizer Anomy Sanitizer est un filtre mail qui corrige les messages défectueux et bloque les pièces jointes suspectes. Il se charge aussi d'appeler l'antivirus. Copiez le tarball dans /usr/local # cd /usr/local/ # tar -xzvf anomy-sanitizer-1.66.tar.gz # chown -R root:filter /usr/local/anomy # chmod 0750 /usr/local/anomy La configuration se fait dans le fichier /etc/sanitizer.cfg Voici un exemple de configuration : sanitizer.cfg à copier dans /etc. Pour tester si cela fonctionne bien, faites : # cd /usr/local/anomy/testcases/ # ./testall.sh Plus d'informations : /usr/local/anomy/sanitizer.html

Filtrage avec Postfix : La technique de filtrage utilisée ici est celle proposée par la documentation de Postfix. Nous aurions pu utiliser maildrop, qui permet de mettre des règles de filtrages différentes pour chaque utilisateur mais la "méthode postfix" est plus simple et plus flexible. La méthode choisie ici est le filtrage par script, idéale pour les petits et moyens serveurs. Si vous avez besoin de plus de performances, vous pouvez utiliser un filtrage par daemon, avec amavisd-new (http://www.ijs.si/software/amavisd/) . # groupadd filter # useradd filter -s /bin/false -d /var/spool/filter -g filter # rm -f /var/spool/filter/.* Voici le script dont a besoin Postfix pour effectuer le filtrage : filter.sh Cette méthode offre aussi la possibilité de filtrer les mails en émission ( cela peut être intéressant si vous ne voulez pas qu'un de vos utilisateurs envoie des spams ou des virus ... ) Copier le script dans /usr/local/anomy/ et ensuite : # cd /usr/local/anomy/ # chown root:filter filter.sh # chmod 750 filter.sh ajoutez à la fin de /etc/postfix/master.cf : filter unix - n n - - pipe flags=Rq user=filter argv=/usr/local/anomy/filter.sh -f ${sender} -- ${recipient}

• Pour un filtrage entrant et sortant : toujours dans master.cf, après la ligne : smtp inet n - n - - smtpd ajouter : -o content_filter=filter:dummy

• Pour filtrage entrant seulement : il faut spécifier une liste d'adresses de destination à filtrer. Créez le fichier /etc/postfix/filtered_domains contenant : chezmoi.fr FILTER filter:dummy (évidemment, remplacer chezmoi.fr par votre nom de domaine) Faites : postmap filtered_domains pour générer la map correspondante. Ensuite, ajoutez à la fin de /etc/postfix/main.cf : smtpd_recipient_restrictions = permit_mynetworks check_recipient_access hash:/etc/postfix/filtered_domains reject_unauth_destination Rq : remplacer hash si besoin par la valeur donnée par la commande : postconf default_database_type

Pour prendre en compte les modifications : postfix reload Plus d'info : postfix-2.0.19/README_FILES/FILTER_README (dans les sources)

ClamAV ClamAV est un antivirus Unix sous licence GPL basé sur le projet OpenAntivirus.

Installation Exécutez les commandes suivantes : # tar -xzvf clamav-0.65.tar.gz # cd clamav-0.65 # groupadd clamav # useradd -g clamav -s /bin/false -c "Clam AntiVirus" -d /dev/null clamav # ./configure --sysconfdir=/etc # make # make install # cp contrib/init/RedHat/clamd /etc/rc.d/init.d La configuration du daemon clamd se fait dans le fichier /etc/clamav.conf Editez-le et supprimez la ligne "Example", enlevez aussi le # devant la ligne ScanMail Plus d'informations : man clamav.conf

Lancement Pour démarrer le daemon, faites : /etc/rc.d/init.d/clamd start Et pour le lancer à chaque démarrage : # chkconfig --add clamd # chkconfig --level 345 clamd on Rq: La vérification manuelle d'un ficher se fait avec la commande clamdscan

Configuration de la mise à jour automatique : La mise à jour automatique permet de télécharger les dernières définitions de virus. # touch /var/log/clam-update # chmod 600 /var/log/clam-update # chown clamav /var/log/clam-update Ajoutez la ligne suivante dans /etc/crontab pour télécharger la mise à jour tous les jours à 12h00 : 00 12 * * * root /usr/local/bin/freshclam --quiet -l /var/log/clam-update Plus d'informations : man freshclam

Intégration de l'antivirus dans Anomy Sanitizer Voici un patch qui permet d'intégrer ClamAV dans anomy : anomy-clamav.patch Copiez le dans /usr/local/anomy/contrib : # cd /usr/local/anomy/contrib # patch <anomy-clamav.patch # cp check_for_virus ../chk_virus.sh # cd .. # chown root:filter chk_virus.sh # chmod 750 chk_virus.sh Il faut ensuite modifier la configuration dans le fichier /etc/sanitizer.cfg : Modifier les lignes : file_list_1_policy = drop file_list_1_scanner = 0 en : file_list_1_policy = accept:accept:drop:save file_list_1_scanner = 0:1:3:/usr/local/anomy/chk_virus.sh %FILENAME %REPLY_TO Avec cette configuration, les pièces jointes susceptibles de contenir des virus seront scannées. Plus d'informations sur les actions et les stratégies de sécurité à mener avec l'antivirus : /usr/local/anomy/sanitizer.html

Optimisation des performances (facultatif) Les fichiers temporaires utilisés par ce filtrage sont créés dans le répertoire /var/spool/filter. En montant ce répertoire en mémoire vive (grâce à tmpfs), nous gagnons du temps sur les opérations de création/lecture/écriture. Rq : en cas de traitement de mail très volumineux, tmpfs n'utilisera au maximum que la moitié de la ram de la machine. Pour ceci faites : mount -t tmpfs tmpfs /var/spool/filter/ -o mode=700,gid=filter,uid=filter,noexec Pour que le montage s'effectue à chaque démarage, ajoutez la ligne suivante dans le fichier /etc/fstab : tmpfs /var/spool/filter tmpfs mode=700,gid=filter,uid=filter,noexec 0 0 Les fichiers de ce répertoire étant stockés dans la ram, il sont perdus à chaque arrêt de la machine. Pour ne pas recréer les préférences utilisateurs de Spamassassin à chaque démarrage (enregistrées dans ce répertoire) , il faut modifier les paramètre du daemon spamd : Créez le fichier /etc/sysconfig/spamassassin contenant : SPAMDOPTIONS="-d -m5 -H" Plus d'informations : man spamd Faites /etc/rc.d/init.d/spamd restart pour prendre en compte les modifications.

UW-IMAP (pop3 et imap avec ssl) UW-IMAP est le serveur imap/pop3 de l'Université de Washington, plus facile à mettre en place que Courrier-Imap. Il utilise le super daemon xinetd.

Installation Pour bénéficier des fonctionnalités de chiffrement, OpenSSL doit être déjà installé. Vous pouvez modifier ci-dessous les valeurs de SSLINCLUDE, SSLLIB et SSLDIR pour correspondre à votre installation. (les chemins utilisés ici sont ceux d'une RedHat 7.3) # tar -xzvf imap-2004.RC7.tar.Z # cd imap-2004.RC7 # make slx SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib SSLDIR=/usr/share/ssl EXtraDRIVERS= SSLTYPE=unix # cp ipopd/ipop3d /usr/sbin # cp imapd/imapd /usr/sbin # chmod 1777 /var/spool/mail Avec cette configuration, à la fois les connections normales (pop3) et les connecions sécurisées (pop3s) sont possibles.

Création des certificats Ces certificats sont nécéssaires à l'authentification SSL. # cd /usr/share/ssl/certs # openssl req -new -x509 -nodes -out imapd.pem -keyout imapd.pem -days 365 # openssl req -new -x509 -nodes -out ipop3d.pem -keyout ipop3d.pem -days 365 # chmod 600 ipop3d.pem # chmod 600 imapd.pem Plus d'informations : man openssl

Configuration UW-IMAP utilise le super-daemon xinetd, qui doit être configuré pour faire appel à ipop3d et imapd. Vérifiez que les entrées suivantes sont présentes dans /etc/services (si besoin est, ajoutez-les) : pop3 110/tcp imap 143/tcp imaps 993/tcp pop3s 995/tcp Créez les 4 fichiers suivants dans /etc/xinetd.d (supprimez l'extension .txt) : pop3, pop3s, imap, imaps . Ajouter ensuite dans le fichier /etc/hosts.allow les lignes (en adaptant à votre réseau) : ipop3d : 192.168.1.0/255.255.255.0 imapd : 192.168.1.0/255.255.255.0 Ces deux lignes permettent de définir les permissions d'accès réseaux aux services fournis par xinetd. Plus d'informations : man hosts.allow Faites /etc/rc.d/init.d/xinetd restart pour prendre en compte les modifications. Voila, c'est terminé. Si tout s'est bien passé, votre serveur mail fonctionne. N'oubliez pas de vérifier que votre firewall et votre service DNS sont bien configurés (notamment l'enregistrement MX de votre nom de domaine, pour que votre serveur smtp soit connu du monde extérieur) . Voir les commentaires de cette page

Chapitre 4 DNS BIND 1ère partie : serveur "cache DNS" Par Serge Pour cette rubrique, des connaissances sur TCP/IP sont nécessaires, ainsi qu'un minimum de savoir-faire sur la configuration des paramètres TCP/IP d'une machine Linux/Unix (bien que j'essaye d'expliquer au maximum toutes les étapes).

Introduction Qu'est-ce donc qu'un serveur DNS? C'est tout simplement ce qui sert à convertir des adresses noms en adresses IP. Par exemple, quand vous tapez dans votre navigateur préféré l'adresse : http://lea-linux.org celui-ci va tout d'abord faire une requête à un serveur DNS (généralement le serveur DNS que vous avez configuré pour votre connexion à l'Internet, donc les serveurs DNS de votre fournisseur d'accès) en lui demandant : C'est quoi l'adresse IP de lea-linux.org ? Et le serveur DNS lui donne l'adresse IP et le navigateur va alors se connecter à cette adresse IP et afficher le site. Ceci est valable pour toute autre application qui manipule des noms DNS (ftp, telnet, mail, ....).

Dans quel cas installer un serveur DNS qui fait cache? Tout d'abord, il faut savoir que l'on peut remplir à la main un fichier, qui s'appelle /etc/host, avec les correspondances "adresse IP et nom DNS des machines". Donc si l'on a un petit réseau local de quelques machines, on peut remplir ce fichier à la main. Mais dans le cas d'un réseau beaucoup plus conséquent, il vaut mieux installer un serveur DNS. Là où un serveur DNS peut être utile aussi, c'est si vous partagez une connexion internet sur votre réseau local. Vous installez sur la machine qui partage la connexion internet un serveur DNS qui fait cache. De ce fait, toutes les machines qui vont se connecter via ce serveur à l'internet vont demander la résolution d'adresse à votre serveur en interne plutôt qu'aux serveurs DNS externes, ce qui va permettre de réduire le traffic réseau sortant. Bon, en fait pour les premières connexions cela ne va servir à rien, car comme votre serveur DNS sera presque vide, celui-ci va demander aux serveurs externes les réponses afin de remplir sa base DNS. Mais comme votre serveur va stocker les réponses, au bout d'un moment, cela va accélérer les réponses DNS, car c'est votre serveur local et non pas les serveurs externes qui vont répondre à ces requêtes DNS. Même dans le cas où vous n'avez qu'une machine "poste de travail" sous linux et que vous vous connectez très souvent à l'internet, le fait d'installer là aussi un serveur DNS sur votre poste va accélérer votre connexion, ce qui est assez agréable, surtout si vous êtes en RTC (connexion via le téléphone). De plus, mon FAI avait fréquemment des problèmes de serveurs DNS, ce qui m'empêchait régulièrement d'atteindre certains sites, alors je me suis décidé à installer un serveur DNS qui fait cache des serveurs DNS de référence de l'internet. Depuis je n'ai plus aucun probléme.

Pré-requis Bon, avant de configurer le tout, il faut vérifier que vous avez sur votre machine ce qu'il faut pour faire votre serveur DNS, c'est-à-dire le package bind. Vérifiez donc que ce package est installé sur la machine qui va faire serveur DNS, dans le cas d'une Mandrake ou Red Hat, vérifiez avec un utilitaire pour les RPM, dans le cas d'une Slackware, vérifiez avec pkgtool, ou dans tous les cas rechercher un fichier nommer "named" qui se trouve dans la plupart des cas dans /usr/sbin/named. Si vous ne trouvez pas de package "Bind...." ou si vous ne trouvez aucun fichier "named", installez alors le package "Bind....", qui doit sûrement se trouver sur le CD d'install de votre distribution.

Théorie : fonctionnement du service DNS. Pour comprendre la configuration d'un serveur DNS, un minimum de théorie sur le fonctionnement de celui-ci est nécessaire. Tout d'abord, il faut savoir que les noms DNS sont organisés de façon hiérarchique. Le haut de la hiérarchie est le root (la racine), désigné par ".", puis viennent les "Top Level Domains" (TLD) que vous connaissez : .com, .net, .fr, .org, .... En fait, quand un nom est recherché, par exemple lea-linux.org, la "question" est posé dans l'ordre hiérarchique, tout d'abord on demande à un serveur racine (un serveur connu sur internet et déclaré comme étant un serveur racine) la liste des serveurs pouvant répondre au TLD ".org", puis on descend d'une hiérarchie et on recommence. Donc à partir de la liste de serveurs obtenue, on demande ceux qui répondent à "lea-linux.org", puis de même pour lea-linux.org. C'est en gros le fonctionnement du service DNS.

Un serveur DNS qui fait cache Le fichier /etc/named On va voir ici une première configuration possible, un serveur DNS qui fait cache. Vous avez besoin de ce type de serveur si votre serveur DNS ne vous sert que pour accélérer votre connexion internet (très utile si vous étes connecté via un modem RTC), ou si vous partagez une connexion internet via votre machine. Tout d'abord, éditons le fichier /etc/named.conf (créez ce fichier s'il n'existe pas) : // Fichier /etc/named.conf // pour serveur DNS cache options { // Répertoire des fichiers de configuration directory "/var/named"; // Si vous traversez un firewall // et que vous avez des problèmes DNS // décommentez la ligne ci-dessous // query-source port 53; version "SECRET"; //permet de masquer la version de Bind - voir précisions ci-dessous }; controls { inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; }; key "rndc_key" { algorithm hmac-md5; secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; }; //Zone racine (root) zone "." { type hint; file "root"; }; //Zone locale zone "0.0.127.in-adr.arpa" { type master; file "zone/127.0.0"; };

Explication de ce fichier : Toutes les lignes qui débutent par "//" sont des lignes de commentaires, elles ne sont là que pour documenter le fichier. La ligne "directory" indique à named où il doit trouver tous ses fichiers de configurations. Tous les autres fichiers auront donc un chemin relatif à celui-ci. On a ensuite la déclaration de la zone ".", la zone racine (root en anglais), avec son fichier de description que l'on va voir plus bas. Ensuite, on a la zone qui peut vous paraître bizarre, la zone "0.0.127.in-adr.arpa". En fait la zone "in.adr.arpa" est une zone "spéciale" qui nous permet de faire des recherches inverses, c'est-à-dire trouver le nom d'une machine à partir de son adresse IP cette fois-ci. Ce fonctionnement est identique à celui qui permet de trouver les noms. Pour trouver une machine d'adresse IP 192.168.1.1 par exemple, la requête va être de trouver en premier in-adr.arpa (en quelque sorte le root) , puis 192.in-adr.arpa, puis 168.192.in-adr.arpa, etc... En fait, dans notre fichier, on déclare ici la zone de recherche inverse sur le domaine 127.0.0 qui est la zone de notre domaine local (rappelez-vous que les adresses IP 127.0.0.x sont des adresses IP spéciales, 127.0.0.1 est l'adresse de loopback d'une machine), ce fichier est détaillé aussi plus bas. version "SECRET" : permet de masquer la version de Bind utilisée et de limiter ainsi l'exploitation de failles e sécurité. Exemple : [root admin]# dig @digital-connexion.info version.bind txt chaos ; <<>> DiG X.x <<>> @digital-connexion.info version.bind txt chaos ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; version.bind, type = TXT, class = CHAOS ;; ANSWER SECTION: VERSION.BIND. 0S CHAOS TXT "SECURED" ;; Total query time: 1 msec ;; FROM: ns1.cfdpublications.com to SERVER: digital-connexion.info 213.186.35.124 ;; WHEN: Sun Mar 2 20:12:56 2003 ;; MSG SIZE sent: 30 rcvd: 62

Les fichiers de zones Comme nous avons vu au-dessus, il nous faut d'autres fichiers, qui sont /var/named/root et /var/named/zone/127.0.0 /var/named/root : ; Fichier de zone des serveurs root ; A vérifier et à maintenir réguliérement . 6D IN NS A.ROOT-SERVERS.NET. . 6D IN NS B.ROOT-SERVERS.NET. . 6D IN NS C.ROOT.SERVERS.NET. . 6D IN NS D.ROOT-SERVERS.NET. . 6D IN NS E.ROOT-SERVERS.NET. . 6D IN NS F.ROOT.SERVERS.NET. . 6D IN NS G.ROOT-SERVERS.NET. . 6D IN NS H.ROOT-SERVERS.NET. . 6D IN NS I.ROOT.SERVERS.NET. . 6D IN NS J.ROOT-SERVERS.NET. . 6D IN NS K.ROOT-SERVERS.NET. . 6D IN NS L.ROOT.SERVERS.NET. . 6D IN NS M.ROOT.SERVERS.NET. A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4 B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107 C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12 D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90 E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10 F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53 I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17 J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10 K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129 L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12 M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33 Comme décrit précédemment, ce fichier contient la liste des serveurs DNS root (racine). /var/named/zone/127.0.0: $TTL 3D @ IN SOA nom_machine.votre_domaine.votre_TLD. ( 1 ; Serial 8H ; Refresh 2H ; Retry 1W ; Expire 1D) ; Minimum TTL NS nom_machine.votre_domaine.votre_TLD. 1 PTR localhost. Remplacez bien sur "nom_machine.votre_domaine.votre_TLD" par les valeurs réélles de votre machine (par exemple azizlinux.icebox.org). Les "." après les noms de domaines ne sont pas une erreur et doivent être présents. J'insiste bien sur ce fait, car l'erreur typique du débutant et de ne pas mettre le "." (j'avoue que ca m'arrive encore parfois).

Configuration de l'utilitaire de controle rndc Si vous regardez a nouveau le fichier named.conf que l'on a fait précédement, vous avez vu deux sections appelées "controls" et "key". Ces deux directives permettent le controlle de votre serveur de nom via le programme "rndc". La ligne "controls" définit les adresses IP des machines autorisées à contrôler le serveur de nom (dans notre exemple il s'agit de la machine 127.0.0.1), et la ligne "keys" définit un couple algorythme/clef qui est en fait une sorte de mot de passe pour autorisé là aussi le contrôle à distance. Pour que la machine puisse alors s'identifier, il faut qu'elle envoie ce mot de passe. Pour cela, il faut créer un fichier /etc/rndc.conf contenant la clef : /etc/rndc.conf: key rndc_key { algorithm "hmac-md5"; secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; }; options { default-server localhost; default-key rndc_key; }; Faite bien attention à ce que les informations entres les fichiers named.conf et rncd.conf soient cohérents, c'est à dire que "algorithm", "secret", "default-key" aient exactement les même valeurs, autrement l'identification entre le serveur et rndc echouera. Pour la valeur de "default-server" dans le fichier rndc.conf, vous mettez là l'adresse ou le nom de la machine que vous voulez controler à distance (dans notre exemple c'est la même machine). Changez au moins la valeur de la key que je donne ici, elle est issue du fichier exemple de BIND, c'est à dire que tout le monde possède cette clef par défaut, donc si vous ne voulez pas que quelqu'un contrôle votre serveur à votre insu, modifiez la! rndc permet de stopper, démarrer, recharger la configuration du serveur BIND à distance. Voir la documentation de rndc, ou les autres parties de ce document.

Configuration des fichiers systèmes Bon maintenant que votre DNS est configuré en tant que serveur cache, il reste encore deux fichiers systèmes à configurer pour indiquer à notre machine que nous avons un serveur DNS et que nous pouvons nous en servir. Commençons par /etc/resolv.conf : search votre_domaine.votre_TLD nameserver 127.0.0.1 Remplacez votre_domaine.votre_TLD par les valeurs de votre machine bien sûr (par exemple icebox.org). Ne pas mettre que votre TLD sans spécifier le domaine. En fait, à quoi sert ce fichier ? Lorsqu'une application va lancer une requête DNS, elle ne fait pas appel directement à votre serveur DNS mais au "résolveur". Celui-ci lit ce fichier et regarde la ligne search pour savoir dans quel domaine chercher en premier. Cela peut paraître stupide, mais quand vous lancez une requête sur "www.netscape.com", via le résolveur vous allez chercher en premier "www.netscape.com.votre_domaine.votre_TLD". Pourquoi ? me demanderez-vous. Tout simplement parce que les personnes qui ont inventé cela pensaient que la plupart des requêtes de noms seraient en interne sur un réseau et rarement vers l'extérieur, donc par défaut, il cherche en premier dans votre nom de domaine. La ligne nameserver indique l'adresse à laquelle on peut contacter un serveur de nom. Aussi bien pour search que pour nameserver, on peut spécifier plusieurs entrées de cette façon : search domaine1.tld1 domaine2.tld2 .... nameserver adresse1 nameserver adresse 2 nameserver adresse 3 ... Attention tout de même à ne pas surcharger en nombre d'entrées dans la ligne search car ca va prendre du temps à chercher dans tous les domaines spécifiés. Différentes entrées sur cette ligne ne servent que si vous êtes sur un réseau local avec plusieurs noms de domaines et que vous avez l'habitude d'appeler les machines juste par leurs noms d'hôte. Dans le cas d'une machine reliée au net, mettre juste le nom de domaine de votre machine et rien de plus. Il reste encore un fichier à configurer, le fichier /etc/host.conf, éditez ce fichier et vérifiez que la première ligne de ce fichier comporte : order hosts,bind Cette ligne oblige le résolveur à regarder en premier les entrées du fichier /etc/hosts puis de faire appel au serveur de nom qui est spécifié dans /etc/resolv.conf.

Test de la configuration Nous allons tester maintenant que la configuration fonctionne. Lancez votre connexion à l'internet. Vérifiez que le serveur DNS n'est pas déjà démarré par un : ps -aux | grep named Si la seule ligne que vous renvoie cette commande est "grep named", c'est que named n'est pas lancé. Sinon relevez le numéro de PID de named et killez-le (kill numéro_du_PID). Relancez ou lancez named par la commande : /usr/sbin/ndc start (remplacez /usr/sbin par le répertoire ou ndc est installé, si vous ne le trouvez pas, lancez alors named la commande "named&" ). Exécutez alors la commande "nslookup" et vous devriez voir apparaître: olio@azizlinux:~$ nslookup Default Server: localhost Address: 127.0.0.1 Ca veut dire que tout marche bien, du moins que le serveur named est lancé et est prêt à répondre aux requêtes DNS (allez voir plus bas si ce que vous obtenez n'est pas la même chose que ce qui est affiché ci-dessus). On va tester que le cache marche vraiment en tapant maintenant: > lea-linux.org et vous devez voir apparaîitre quelque chose comme: Server: localhost Address: 127.0.0.1 Name: lea-linux.org Address: 212.73.209.252 Puis retapez exactement la même commande et cette fois ci, le résultat devrait être : > lea-linux.org Server: localhost Address: 127.0.0.1 Non-authoritative answer: Name: lea-linux.org Address: 212.73.209.252 > La ligne "Non-authoritative answer" signale justement que l'information a été récupérée via le cache du serveur DNS, et nous avertit donc que cette adresse peut être fausse si l'adresse a changé depuis, ce qui est très improbable. Quittez alors l'utilitaire nslookup par "exit". Voilà, votre serveur "DNS cache" est opérationnel. Il ne vous reste qu'à ajouter le "/usr/sbin/ndc start" dans un script de démarrage (par exemple /etc/rc.local).

Ca marche pas! Bon, soit c'est votre serveur DNS qui n'est pas lancé, soit vos fichiers systèmes sont mal configurés. Pour le savoir, lancez la commande suivant pour voir si named tourne en tâche de fond : ps -aux | grep named Si named ne tourne pas en tâche de fond, éditez alors le fichier /var/log/messages et repérez les lignes qui comporte named[xxxx]: ...... , elles devraient vous indiquez les erreurs de configuration que vous avez faites (fichier de zone non trouvé, etc...). Si named tourne, vérifiez alors que le résolveur se connecte bien à votre serveur DNS et pas sur un autre. Pour cela, quand vous lancez nslookup, celui-ci doit vous répondre que le serveur par défaut est bien localhost, avec comme adresse "127.0.0.1". Si ce n'est pas le cas, revérifiez les fichiers /etc/resolv.conf et /etc/host.conf. Vérifiez aussi le fichier de zone 127.0.0.

Remarques sur un serveur DNS cache • Un serveur DNS cache n'écrit pas dans un fichier les différentes adresses qu'il récupère, il les stocke en

mémoire, ce qui veut dire qu'à partir du moment où vous éteignez votre machine (ou que vous stoppez le service named), vous perdez toutes les adresses en mémoire. Donc si vous utilisez votre serveur DNS juste pour accélérer votre connexion internet, ne stoppez pas votre serveur DNS et ne rebootez pas votre machine, où vous n'utiliserez en fait jamais votre cache. Le seul bénéfice dans ce cas est que vous utilisez votre serveur DNS qui fait cache avec les serveurs "root" d'internet, ce qui vous garantit des réponses fiables.

• Dans le cas où vous partagez votre connexion internet (modem cable, adsl, ou même simple modem) il est très utile d'utiliser un serveur DNS cache. Par contre, pour que vos stations qui utilisent cette connexion partagée se servent de ce serveur cache DNS, n'oubliez surtout pas de configurer toutes les stations pour qu'elles utilisent comme serveur DNS votre serveur et pas un autre. Pour cela, donnez comme adresse de serveur DNS l'adresse interne (côté LAN donc) de votre serveur.

Chapitre 5 DNS BIND 2ème partie : serveur de Zone Par Serge Pour cet article, je considère que vous avez lu la 1ère partie, sur les serveurs DNS “cache”, qui permet déjà de comprendre les fichiers de zones et donne la configuration minimale d'un serveur DNS. Sans cette configuration minimale votre serveur DNS ne fonctionnera pas. J'explique dans cet article comment configurer une zone personnelle pour un serveur primaire et secondaire. Je n'explique pas les zones inverses ni la sécurité que l'on peut ajouter sur les zones que notre serveur va contenir. Ces parties seront vu dans un 3ème article “configuration avancée”.

Un serveur DNS pour mon domaine. Nous prenons ici un exemple de configuration pour le domaine “.org”. Remplacez bien sûr avec votre propre domaine. Attention: Votre serveur DNS doit, pour pouvoir fonctionner, avoir une adresse IP fixe sur l'Internet. De plus votre domaine doit être enregistré chez un registar (Gandi, Namebay, ou tout autre registar) et lors de l'enregistrement du domaine vous devez fournir l'IP du serveur de nom en serveur “primaire” et l'IP du serveur secondaire. Nous détaillons en 1er la configuration du serveur primaire, celle du secondaire étant triviale (voir plus bas dans l'article).

Le fichier /etc/named On reprend le fichier déjà créé dans l'article “dns cache”. Pour rappel, voici ce qu'il doit donc déjà contenir: // Fichier /etc/named.conf // pour serveur DNS cache options { // Répertoire des fichiers de configuration directory "/var/named"; // Si vous traversez un firewall // et que vous avez des problèmes DNS // décommentez la ligne ci-dessous // query-source port 53; version "SECRET"; //permet de masquer la version de Bind - voir précisions ci-dessous }; controls { inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; }; key "rndc_key" { algorithm hmac-md5; secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; }; //Zone racine (root) zone "." { type hint; file "root"; }; //Zone locale zone "0.0.127.in-adr.arpa" { type master; file "zone/127.0.0"; }; On ajoute alors dans ce fichier l'entrée pour notre fichier de zone “lea-linux.org: zone “lea-linux.org” { type master file “zone/lea-linux.org” } L'ajout de zone est très simple comme vous pouvez le voir. Il suffit de dire quelle zone ce serveur va “servir”, mot clef zone , d'indiquer si nous si sommes le serveur d'autorité pour cette zone, mot clef type master et d'indiquer le fichier contenant les informations de la zone, mot clef file. Voyons maintenant ce que doit contenir ce fichier de zone.

Le fichier de zone de mon domaine. Nous devons donc créer le fichier de zone de notre domaine “lea-linux.org”. Voyons le fichier, puis expliquons le: $TTL 3D @ IN SOA ns1.kilio.com. serge.kilio.net. ( 2003091801; serial 86400 ; refresh 3600 ; retry 3600000 ; expire 604800 ; default_ttl ) @ IN NS ns1.kilio.com. @ IN NS ns2.kilio.com. @ IN MX 50 ns1.kilio.net. @ IN MX 10 nice.kilio.net. IN A 80.245.32.131 irc IN A 80.245.32.129 www IN CNAME linuxmutuel.kilio.fr. wiki IN A 80.67.179.10 vizu IN A 195.202.0.21 devel IN A 80.67.179.10 sniper IN A 62.212.100.216 ftp IN A 80.245.32.131 beta IN CNAME linuxmutuel.kilio.fr Cela peut vous paraître très “barbare” mais en fait rien n'est très compliqué. On peut découper ce fichier en deux parties:

• L'en-tête: qui commence au début du fichier $TTL et se finit à la “)” • Les enregistrements de la zone: le reste du fichier.

Détail de l'en-tête. Nous l'avons déjà vu dans l'article précédent mais voici ce qu'elle doit contenir obligatoirement: $TTL : l'indication du TTL (Time To Live) ou la durée de vie de la zone, exprimée en secondes par défaut, ou dans une autre unité si on la spécifie comme dans l'exemple, ici le D spécifiant que l'unité est en jours, donc 3 jours pour notre exemple. Le bloc suivant défini tous les autres paramètres “techniques et administratifs” de la zone de la forme: @ IN SOA dns_primaire. adresse_mail. ( xxxxxxxx; serial xxxxx; refresh xxxxx; retry xxxxx; expire xxxxx; default_ttl ) dns_primaire: mettre ici le nom du serveur faisant autorité pour la zone adresse email: email du responsable technique de la zone en remplaçant le “@” de l'email par un “.” Le reste, encadré par des parenthèses renseigne les données techniques de la zone avec: serial: le numéro de version de la zone. Ce chiffre est particulièrement important. A chaque fois que vous modifiez quoi que ce soit dans un fichier de zone, vous devez impérativement incrémenter ce numéro, autrement les changements ne seront pas pris en compte par le reste du monde et particulièrement par le serveur secondaire. C'est ce numéro, s'il est incrémenté, qui indique au reste du monde que votre zone a subit un changement et que donc les autres serveurs DNS doivent redemander la zone à votre serveur pour prendre en compte ces changements. On a l'habitude de suivre une règle simple pour être sûr d'incrémenter ce numéro de version, on le compose par la suite des chiffres de l'année en cours, mois, jour et le nombre de changements effectués ce jour là: AAAAMMJJNN Donc par exemple si je modifie la zone le 10 juillet 2003 , je vais mettre 2003071001, puis je m'aperçois que je me suis trompé donc je la modifie à nouveau le même jour, donc ce serial devient 2003071002, et si je la modifie ensuite le 15 août de la même année le serial devient alors 2003081501. Cette règle n'est pas du tout obligatoire, vous pouvez utiliser votre propre règle du moment que le nombre soit incrémenté et que ce nombre ne comporte pas plus de 10 chiffres. Refresh: Temps en secondes d'attente du serveur secondaire avant de contrôler si le serveur primaire a subi une modification au niveau de sa zone. Sur 8 chiffres max. Retry: Temps d'attente du serveur secondaire avant de faire à nouveau une demande si le serveur primaire n'a pas répondu à une requête. Sur 8 chiffres max. Expire: Temps pendant lequel le serveur secondaire va conserver les données en cache. Si ce délai est dépasse et que le serveur secondaire n'a pas pu contacter le serveur primaire, il va alors considérer que les données qu'il a en cache ne sont plus fiable et ne pourra plus servir de serveur secondaire pour la zone tant qu'il n'aura pas réussi à contacter le serveur primaire. Sur 8 chiffres max. Ttl: Valeur par défaut de ttl des enregistrements. On peut spécifier les ttls au niveau de chaque enregistrement, mais d'une manière générale on défini ici un ttl qui vaut pour tous les enregistrements.

Enregistrement de la zone. Tout les enregistrements d'une zone suivent cette syntaxe: hôte_ou_wildcard (ttl) classe type (priorité_si_besoin) valeur Voici les explications de ces champs, puis en dessous quelques exemples pour mieux comprendre. Par défaut nous n'utilisons pas de ttl pour les enregistrements (voir la remarque au dessus pour le ttl dans l'en-tête de zone). Hôte ou wildcard: indique si on défini une machine ou un ensemble de machine. Classe: type de classe, a comme valeur IN pour l'Internet. Nous ne détaillerons pas ce champ, vous utiliserez toujours la classe IN pour vos besoins. Type: Indique quel type d'enregistrement nous sommes en train de définir. Les types les plus utilisés sont A pour une adresse, CNAME pour un alias de nom, NS pour un serveur de nom, MX pour un serveur de Mail, TXT pour des commentaires. Priorité: Si le type à besoin d'une priorité, nous l'indiquons ici. Valeur: la valeur ou la donnée de l'enregistrement que nous définissons. Détaillons alors les exemples de notre zone pour mieux comprendre: @ IN NS ns1.kilio.com. @ IN NS ns2.kilio.com. Nous indiquons ici que les deux serveurs DNS (type NS) de la zone (wildcard @) lea-linux.org sont ns1.kilio.com et ns2.kilio.com @ IN MX 50 ns1.kilio.net. @ IN MX 10 nice.kilio.net. Nous indiquons ici que les deux serveurs de Mail (type MX) de la zone (wildcard @) lea-linux.org sont : nice.kilio.net avec la priorité 10 ns1.kilio.net avec la priorité 50. Cela veut dire que tout mail du type xxxxxx@lea-linux.org doit être envoyé en priorité sur nice.kilio.net et que si ce serveur ne répond pas on l'envoie alors sur le serveur ns1.kilio.net. Faites attention, c'est la priorité la plus basse qui indique le premier serveur à contacter. irc IN A 80.245.32.129 Nous indiquons ici que l'hôte irc.lea-linux.org correspond à l'adresse 80.245.32.129 www IN CNAME linuxmutuel.kilio.fr. Nous indiquons ici que l'hôte lea-linux.org correspond à l'hôte linuxmutuel.kilio.fr . On aurait pu aussi le définir en type A et mettre l'adresse ip correspond à linuxmutuel.kilio.fr comme valeur. Mais dans ce cas, si la machine linuxmutuel.kilio.fr change d'adresse IP on doit modifier la valeur de www pour la zone lea-linux.org. De plus, comme cette machine héberge environ 200 sites web différents, il y aurait 200 fichiers de zones à modifier avec la nouvelle IP. Pour éviter cela, on définit alors lea-linux.org comme CNAME de linuxmutuel.kilio.fr. IN A 80.245.32.131 Vous remarquerez que le 1er champ est vide. Cela indique tout simplement que si l'on demande lea-linux.org directement (sans spécifier d'hôte) on aura l'IP 80.245.32.131. Ce qui permet de taper dans votre navigateur http://lea-linux.org sans le "www".. Voici un autre exemple qui n'est pas dans notre zone mais qui définit le type TXT: info IN TXT Zone du fabuleux site linux entre amis Indique que info à comme valeur “Zone du fabuleux site Linux entre amis”. Aucune application n'a besoin de ce type d'enregistrement, mais il peut être utile pour donner des infos sur une zone, etc.. Il existe d'autres types d'enregistrements que ceux vu ci-dessus, mais ils sont très rarement utilisés sur l'Internet. Consultez les RFC sur les DNS si vous souhaitez les connaître.

Serveur secondaire. Tout ce que nous avons vu au dessus concerne la configuration du serveur primaire de votre zone. Il faut généralement déclarer lors de l'enregistrement de votre domaine chez un registar un serveur secondaire (et parfois des tertiaires etc.. mais la configuration est exactement identique à celle d'un serveur secondaire, et seul le secondaire et obligatoire). Il faut donc, vous vous en doutez, le configurer lui aussi. Le serveur secondaire sert tout simplement à répondre aux requêtes à la place du primaire pour ne pas surcharger le serveur primaire ou si le serveur primaire est hors service temporairement. Il doit contenir tout d'abord la configuration de base vue dans l'article “serveur cache” comme n'importe quel serveur DNS qu'il soit primaire ou secondaire. Et il doit aussi contenir dans son fichier named.conf les zones pour lesquelles il est serveur secondaire sous la forme: zone “lea-linux.org” { type slave file “zone/lea-linux.org” masters {ip_serveur_primaire;} } et rien d'autre. Pas de fichier de zone ni rien. Les fichiers de zones seront créés automatiquement en interrogeant le serveur primaire directement via la directive masters.

Et si ça marche pas? Vous pouvez alors faire exactement les mêmes vérifications que celles données dans l'article serveur cache. La seule différence est que si vous faites les tests nslookup sur le serveur primaire vous ne devez pas avoir de réponse “Non-authoritative”.

Chapitre 6 Le projet Samba Partager ses fichiers et imprimantes avec Samba Par Anne Vous disposez à la maison ou dans votre entreprise de machines sous Linux et d'autres sous Windows. Comment faire en sorte de faire communiquer tout ce petit monde ? Samba va vous permettre de centraliser et rendre accessibles vos fichiers et imprimantes à partir de toutes ces machines. L'article se propose de donner les éléments nécessaires pour configurer ce partage dans un contexte de groupe de travail (le plus simple) mais en sécurisant un minimum l'accès à ces ressources, et donc une authentification des utilisateurs. Nous verrons dans un premier temps la configuration en mode texte, qui a l'avantage de vous expliquer les arcanes du fonctionnement du serveur. Vous pourrez également utiliser les interfaces graphiques, ce qui vous permettra d'obtenir le même résultat. Le projet démarre en 1992, grâce à Andrew TRIDGELL. Etudiant en physique, il développe un protocole de partage de fichiers qui émulait les systèmes Digital. 18 mois plus tard, il apprendra que ce protocole fonctionne également avec Windows. Depuis le projet compte des développeurs dans le monde entier et bénéficie également de financements d'entreprise pour l'implémentation de fonctionnalités compatibles Windows.

Installer Samba Nous allons travailler à partir d'une distribution Mandrake 10.0. Les postes clients peuvent être indifféremment sous Windows 95/98 et/ou Windows 2000/XP/2003.

Récupération et installation des paquetages Samba. Lors de l'installation de votre distribution, vous avez pu choisir d'installer un certain nombre de serveurs, dont Samba. Nous allons donc commencer par véfifier la présence des paquetages nécessaires. # rpm -qa | grep samba samba-server-3.0.2a-3mdk samba-common-3.0.2a-3mdk samba-client-3.0.2a-3mdk Si vous obtenez quelque chose de similaire, c'est que tout est déjà prêt. Vous pouvez alors passer à la section suivante. Dans le cas contraire, nous allons installer les paquetages depuis le CD de votre distribution (ou tout autre support contenant votre distribution) : # urpmi samba Un des paquetages suivants est nécessaire : 1- samba-server-3.0.2a-3mdk.i586 2- samba2-server-2.2.8a-14mdk.i586 Que choisissez-vous ? (1-2)1 Pour satisfaire les dépendances, les paquetages suivants vont être installés (14 Mo): samba-common-3.0.2a-3mdk.i586 samba-server-3.0.2a-3mdk.i586 Est-ce correct ? (O/n) o Préparation... ################################################## 1:samba-common ################################################## 2:samba-server ################################################## L'installation propose un choix entre Samba2 et Samba3. La dernière version apporte des améliorations considérables et des fonctionnalités supplémentaires, comme la gestion des groupes. Ces fonctionnalités sont surtout utilisées dans une configuration orientée entreprise mais après tout, ne nous refusons rien ! Nous allons également installer la partie cliente. Elle contient tous les outils qui permettent notamment le montage et le parcours des ressources Samba. # urpmi samba-client Préparation... ################################################## 1:samba-client ##################################################

Premier test de votre installation Maintenant que Samba est installé, démarrons le serveur : # /etc/rc.d/init.d/smb start Lancement du service SaMBa : [ OK ] Lancement du service NMB : [ OK ] Deux démons sont lancés, nécessaires au fonctionnement du serveur Samba : smbd et nmbd.

• smbd permet le partage des fichiers et imprimantes • nmbd permet quant à lui le parcours du réseau et la résolution de noms Netbios...

# /etc/rc.d/init.d/smb status smbd (pid 970) is running... nmbd (pid 972) is running... La commande ci-dessus permet de vérifier que Samba fonctionne correctement. Vous devez voir apparaitre les deux dernières lignes.

Automatiser le lancement de Samba La dernière phase de l'installation consiste pour nous à vérifier que Samba sera bien lancé automatiquement à chaque démarrage de la machine (ce qui évite bien des surprises !). Pour le vérifier, exécutons la commande ci-dessous : # chkconfig --list smb smb 0:Arrêt 1:Arrêt 2:Arrêt 3:Arrêt 4:Arrêt 5:Arrêt 6:Arrêt Elle indique les niveaux de fonctionnement auxquels le serveur est démarré. Dans le cas où Samba n'est pas démarré aux niveaux souhaités, ici il n'est jamais démarré, il suffit de reconfigurer l'initialisation du serveur : # chkconfig --level 345 smb on Dans ce cas, Samba est démarré aux niveaux 3, 4 et 5, ce qui correspond aux niveaux standards de fonctionnement des services réseau. Si la ligne de commande vous insupporte, vous pouvez utiliser, en root, la commande drakxservices :

Schema1 : configurer le démarrage de Samba Cliquez sur la case à cocher "Au démarrage" sur la ligne smb pour démarrer le service dès le démarrage.

Installation du serveur d'impression Pour terminer la phase d'installation, nous allons voir comment installer et configurer rapidement le serveur d'impression cups. Encore une fois, l'installation des paquetages est réalisée grâce à la commande urpmi, suivie du démarrage du serveur : # urpmi cups cups-drivers installation de /var/cache/urpmi/rpms/cups-1.1.20-5mdk.i586.rpm /var/cache/urpmi/rpms/cups-drivers-1.1-133mdk.i586.rpm Préparation... ################################################## 1:cups ################################################## 2:cups-drivers ################################################## # service cups start Lancement du service d'impression CUPS : [ OK ] Ci-dessous la configuration et la gestion d'une imprimante : Schema2 : interface d'administration de cups

La configuration est relativement simple. Sur votre machine, tapez l'url : http://localhost:631. Cliquez sur "Administrer les imprimantes" et laissez-vous guider pour ajouter votre ou vos imprimantes :).

Le fichier de configuration principal Le fichier de configuration à connaitre pour Samba est /etc/samba/smb.conf. Nous allons en détailler les grandes rubriques. Celui-ci, on le verra, est modifiable soit à l'aide d'un éditeur de texte soit d'une interface graphique. Le fichier est découpé en grandes sections indiquées de cette manière : [section]. Les différents paramètres sont ensuite inscrits de la manière suivante : paramètre = valeur. Toute ligne commencée par un "#" ou ";" est considérée comme un commentaire. Par convention, le ";" est utilisé pour commenter les lignes de configuration. Nous allons passer en revue les différentes sections en énonçant les paramètres les plus courants. Les outils graphiques proposés pour paramétrer Samba que nous verrons par la suite, ne font que mettre à jour ce fichier de configuration.

Section de configuration générale La première section est annoncée par [global]. Elle contient les éléments généraux de la configuration du serveur Samba : nom du groupe de travail, réseaux autorisés, utilisateurs administrateurs...

• workgroup : nom du groupe de travail ou du domaine • netbios name : nom netbios du serveur Samba, par défaut égal au nom de la machine (hostname) • server string : description affichée lors du parcours réseau, il s'agit d'un commentaire. • printing : système d'impression utilisé pour le serveur d'impression : sous Linux on trouvera lprng et de plus

en plus, cups (le choix réalisé dans cet article). • log file / max log size / log level : configuration des logs du serveur : respectivement le nom du fichier de log,

sa taille maximum et le niveau des logs (plus le niveau est élevé, plus la quantité d'informations est importante) • hosts allow (deny) : entrer ici la liste des adresses IP des machines (ex : 192.168.0.3) ou réseaux ( ex :

192.168.0.) autorisés à se connecter au serveur Samba (et inversement si on utilise le paramètre hosts deny). Le paramètre est important surtout si votre machine est accessible de l'extérieur. Le protocole Netbios fait l'objet de nombreuses attaques. Pensez également à configurer votre firewall pour bloquer les ports 137, 138 et 139 de l'extérieur.

• security : c'est une des options les plus importantes du fichier, qui pourra être bloquante si elle est mal renseignée. Elle indique le mode de discussion du client Windows avec le serveur Samba. Dans les versions 3.x de Samba, le défaut est user, et share pour Samba 2.x. Dans la version qui nous intéresse, on utilisera le mode user si les noms de comptes utilisés pour se connecter au serveur ont un compte équivalent sur la machine Linux (existence d'une entrée dans /etc/passwd). Dans le cas contraire, on préférera share. Il existe également 2 autres types possibles : domain et server que nous n'aborderons pas ici et qui sont réservés dans un fonctionnement de Samba en tant que contrôleur de domaine. Ci-dessous quelques explications sur les implications de ce choix :

• share : ce mode ne nécessite pas d'authentification par un compte valide. Si le paramètre guest only est renseigné, alors tout nouvel utilisateur sera identifié par le biais de cet utilisateur invité.

• user : dans ce cas de figure, l'utilisateur doit s'authentifier systématiquement. Son compte windows devra disposer d'un compte correspondant sur le serveur (on parle aussi en bon français de mapping)

• encrypt passwords / unix password sync / passwd program / passwd chat : configuration des mots de passe. On aura recours aux mots de passes encryptés. La synchronisation des mots de passe permet la synchronisation entre le mot de passe de l'utilisateur Samba et son compte sur le système Linux. En l'autorisant, on permet à l'utilisateur de modifier son mot de passe à partir de la machine cliente et donc d'un poste client sous Windows. Enfin passwd program et passwd chat indiquent le programme utilisé pour réaliser cette modification ainsi que le dialogue qui s'établira avec le serveur. Les paramètres par défaut conviennent parfaitement.

• character set / client code page : permettent de faire correspondre un code page Windows avec un character set UNIX, pour utiliser notamment les caractères accentués. Par défaut, on utilisera : client code page = 850 character set = ISO8859-1

Section de configuration des partages de fichiers Nous allons maintenant passer aux sections de partages de fichiers. Nous aurons une section par partage défini. A l'intérieur de chacune de ces sections, nous trouverons les options qui définissent le dit partage. Nous allons donner un nom à chaque partage. Attention il existe un nom de partage de fichiers spécifique : [homes]. Il définit le partage des répertoires personnels des utilisateurs, sans avoir à spécifier le chemin dans les options. De manière générale, on aura donc [monpartage]. Ci-dessous le détail des options les plus courantes utilisées :

• path : chemin d'accès du partage - il n'est pas à spécifier pour le partage [homes] • comment : commentaire décrivant le partage qui apparait lors du parcours du réseau Samba (voisinage réseau

sous Windows), il s'agit uniquement d'un commentaire • browseable : le partage sera visible lors du parcours du réseau • read only : limite l'accès en lecture uniquement • write list : limite l'accès en écriture aux données du partage aux utilisateurs et/ou groupes d'utilisateurs

spécifiés. Un groupe sera mentionné de cette façon : @nom_du_groupe.

Configuration des partages d'imprimantes Votre serveur Samba peut également vous servir à partager des imprimantes. Nous traiterons ici du cas où ces imprimantes sont gérées par cups. Le partage d'imprimante peut se faire à plusieurs niveaux :

• partage de la ressource (partage intitulé [printers]), mais qui nécessite d'avoir installé les drivers sur le poste client,

• partage des drivers, dans ce dernier cas vous n'avez plus besoin d'installer de driver sur le client Windows, le partage est intitulé [print$].

Vous pouvez décider de partager uniquement la ressource ou bien les drivers et la ressource. [global] ... # système d'impression utilisé printing = cups # administrateur des imprimantes printer admin = root ... # partage des ressources d'impression [printers] comment = All Printers path = /var/spool/samba create mask = 0700 guest ok = Yes printable = Yes browseable = Yes # partage des drivers des imprimantes [print$] path = /var/lib/samba/printers browseable = yes read only = yes write list = root Pour mettre les drivers à disposition sur le serveur Samba, il vous faut vous procurer les drivers Postcript Adobe. Pour les télécharger : http://www.adobe.com/support/downloads. Une fois extraits, nous allons les copier dans /usr/share/cups/drivers. Nous allons ensuite procéder à la création effective du partage des imprimantes cups par Samba grâce à la commande cupsaddsmb : # cupsaddsmb -a ... passwd: ... # Pour vérifier que le lien a bien été réalisé, vous avez plusieurs possibilités.

• la commande smbclient va vous lister, entre autres, les imprimantes partagées :

# smbclient -L localhost Password: Anonymous login successful Domain=[MONGROUPE] OS=[Unix] Server=[Samba 3.0.2a] Sharename Type Comment --------- ---- ------- print$ Disk public Disk Public Stuff IPC$ IPC IPC Service (Samba Server 3.0.2a) ADMIN$ IPC IPC Service (Samba Server 3.0.2a) hp4050n Printer hplaser4000 Printer hplaser4000 Anonymous login successful Domain=[MONGROUPE] OS=[Unix] Server=[Samba 3.0.2a] ...

• la commande rpcclient permet, selon l'option choisie, d'énumérer les imprimantes et drivers partagés : # rpcclient -d=0 -U root -c 'enumprinters' localhost Password: flags:[0x800000] name:[\\pingu\hp4050n]

description:[\\pingu\hp4050n,hp4050n,] comment:[] flags:[0x800000] name:[\\pingu\hplaser4000] description:[\\pingu\hplaser4000,hplaser4000,hplaser4000] comment:[hplaser4000] # rpcclient -d=0 -U root -c 'enumdrivers' localhost Password: [Windows 4.0] Printer Driver Info 1: Driver Name: [hplaser4000] Printer Driver Info 1: Driver Name: [hp4050n] [Windows NT x86] Printer Driver Info 1: Driver Name: [hplaser4000] Printer Driver Info 1: Driver Name: [hp4050n] [Windows NT x86] Printer Driver Info 1: Driver Name: [hplaser4000] Printer Driver Info 1: Driver Name: [hp4050n]

• enfin la commande testprns permet de vérifier qu'un nom d'imprimante est valide c'est-à-dire utilisable car correctement reconnu sur le système. # testprns hp4050n Looking for printer hp4050n in printcap file /etc/printcap Printer name hp4050n is valid. # testprns bidule Looking for printer bidule in printcap file /etc/printcap Printer name bidule is not valid.

Commandes utiles Monter des ressources du serveur dans un système de fichiers Linux Il est possible d'utiliser une un partage de fichiers smb (Samba, Windows©) comme faisant partie du système de fichiers Linux local : il suffit de monter la ressource. Pour que cela fonctionne, il faut que le noyau de Linux ainsi que Samba aient été compilés avec le support du système de fichiers smbfs (ce qui est le cas du noyau et des paquetages Samba de Mandrake ainsi que de nombreuses autres distributions). L'opération peut être réalisée avec la commande classique mount mais uniquement en tant que root. Exemple : # mount -t smbfs \\\\pingu\\homes /mnt/samba -o username=anne Cet exemple permet de monter le répertoire personnel de l'utilisateur anne partagé par le serveur samba sur le répertoire /mnt/samba. Le montage nécessite de spécifier le type de système de fichiers (-t smbfs) et l'identité utilisée pour accéder au partage (-o username=anne). Ce système de fichiers peut être démonté grâce à la commande umount. # umount /mnt/samba Ce montage peut être effectué en "non root" grâce à la commande smbmount, à condition que le répertoire de montage soit accessible en écriture pour l'utilisateur, ainsi que le partage lui-même.. Exemple : $ smbmount \\\\pingu\\homes /home/anne/samba Le système de fichiers sera démonté toujours en utilisateur grâce à la commande smbumount. $ smbumount home/anne/samba

Tester la syntaxe de smb.conf : testparm La commande testparm permet de tester les options utilisées dans le fichier ainsi que la syntaxe. Elle spécifie également, après parcours du fichier, les partages effectifs, le status du serveur. Testons la validité de notre fichier de configuration : # testparm Load smb config files from /etc/samba/smb.conf Processing section "[homes]" Processing section "[printers]" Processing section "[public]" Loaded services file OK. Server role: ROLE_STANDALONE Press enter to see a dump of your service definitions

Parcourir le réseau : smbclient smbclient est une commande qui permet d'accéder aux ressources partagées par le serveur. Elle est notamment très utile pour tester le bon fonctionnement des partages avec votre serveur Samba. # smbclient \\\\pingu\\homes -U anne Password: Domain=[PINGU] OS=[Unix] Server=[Samba 3.0.2a] smb: \> La commande ci-dessus est un accès au répertoire personnel sur le serveur en tant qu'utilisateur anne.

Machines visibles sur le réseau netbios : findsmb La commande findsmb va vous permettre de lister les machines visibles grâce aux requêtes smb de votre serveur (script effectuant une combinaison de commandes nmblookup et smbclient). Exemple : # findsmb IP ADDR NETBIOS NAME WORKGROUP/OS/VERSION --------------------------------------------------------------------- Domain=[LINUXERIES] OS=[Unix] Server=[Samba 3.0.2a] Domain=[LINUXERIES] OS=[Unix] Server=[Samba 3.0.2a] 192.168.0.3 PINGU +[ LINUXERIES ] Domain=[WORKGROUP] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager] Domain=[WORKGROUP] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager] 192.168.0.100 PLOPLAND-OAAHXLR+[ WORKGROUP ] Nous pouvons voir ci-dessus 2 machines : PINGU et PLOPLAND-OAAHXLR.

Résoudre les noms netbios : nmblookup La commande nmblookup permet de résoudre les noms netbios en IP. La commande peut permettre de vérifier le bon fonctionnement de la configuration de votre serveur ou de vos machines clientes. Exemple : # nmblookup pingu 192.168.10.52 pingu<00> Au nom netbios pingu correspond l'adresse IP 192.168.10.52. indique que la machine est simple station de travail.

Lister les connexions au serveur : smbstatus La commande smbstatus permet de générer une liste des connexions au serveur au moment précis où vous tapez la commande. # smbstatus Samba version 3.0.2a PID Username Group Machine ------------------------------------------------------------------- 6909 lealinux lealinux pingu (192.168.0.3) 6916 bidule bidule pingu (192.168.0.3) Service pid machine Connected at ------------------------------------------------------- lealinux 6909 pingu Sun Jun 27 16:50:06 2004 bidule 6916 pingu Sun Jun 27 16:50:20 2004 No locked files Ci-dessus, on peut voir 2 connexions actives au serveur Samba provenant des utilisateurs lealinux et bidule, effectuées en local.

Exemple de configuration Pour terminer sur la configuration texte de votre serveur Samba, ci-dessous un exemple type de fichier /etc/samba/smb.conf pour une utilisation courante :

• authentification par utilisateur • utilisation de cups en tant que serveur d'impression, root étant administrateur • partage des imprimantes et de leurs drivers • partage des répertoires maison dont l'accès est réservé à leur propriétaire • partage public accessible à tous

[global] # nom de l'espace de travail workgroup = LINUXERIES # commentaire sur l'espace de travail server string = Samba Server %v # Configuration du partage des ressources d'impression printcap name = cups load printers = yes printing = cups printer admin = root # Configuration des logs du serveur log file = /var/log/samba/log.%m max log size = 50 # Configuration de l'authentification # type utilisé security = user # mots de passe encryptés - pour permettre de modifier le mot de passe à partir de la machine cliente encrypt passwords = yes smb passwd file = /etc/samba/smbpasswd unix password sync = Yes pam password change = yes socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 # Partage des repertoires personnels [homes] comment = Home Directories browseable = no writable = yes # Partage des ressources d'impression [printers] comment = All Printers path = /var/spool/samba browseable = no

# to allow user 'guest account' to print. guest ok = yes writable = no printable = yes create mode = 0700 # Partage des drivers d'impression [print$] path = /var/lib/samba/printers browseable = yes write list = @adm root guest ok = yes inherit permissions = yes # Partage accessible à tous [public] path = /home/public public = yes only guest = yes writable = yes printable = no

Test de votre installation depuis Windows© Passons maintenant à la phase de test à partir d'un de vos clients Windows. Cliquez sur le voisinage réseau de votre poste Windows. Schema3 : visualisation des partages sur un poste client Windows

Cliquez ensuite sur le nom du workgroup correspondant au nom de votre serveur Samba. Vous allez alors pouvoir visualiser l'ensemble des partages configurés, à condition que ces ressources soient "browseable" et que vous ayez les droits nécessaires. Attention tout changement intervenant sur ces ressources peut mettre un certain temps avant mise à jour de l'affichage. Netbios est en effet un protocole extremement bavard et basé sur ce qu'on appelle le broadcast. Il interpelle tout le reseau à des moments déterminés pour la mise à jour des ressources.

Gestion des utilisateurs et des groupes Cette notion va permettre de sécuriser l'accès aux données. Toute la problématique repose sur la nécessité de disposer de comptes sur le système Linux qui vont correspondre aux utilisateurs sur les machines Windows. On parle aussi de synchronisationde ces deux types de comptes. Il en s era de même pour les groupes.

Les différents types d'utilisateurs Samba Il existe plusieurs types d'utilisateurs et donc de droits. Nous distinguerons l'administrateur, les utilisateurs et les invités (guest) :

l'administrateur dispose de tous les droits et notamment celui de gérer les imprimantes. l'utilisateur classique dispose des droits qui lui sont attribués par l'administrateur et les caractéristiques mêmes des ressources. l'utilisateur guest qui correspond à un utilisateur décidé par l'administrateur sur le système Linux (souvent nobody, utilisateur disposant de très peu d'accès sur le système et donc limitant les risques). Il peut accéder aux ressources définies là aussi par l'administrateur, sans entrer de mot de passe. Ce cas de figure nécessite de spécifier dans le partage concerné, l'option guest ok. L'utilisateur invité sera spécifié dans la section globale par l'option guest account.

Exemple : [global] ... guest account = nobody ... [monpartage] comment = mon joli partage path = /home/public guest ok = yes

Synchroniser les utilisateurs Pour synchroniser les utilisateurs Windows / Linux, on utilisera la commande smbpasswd. Dans un premier temps, on ajoute l'utilisateur au fichier /etc/samba/smbpasswd ainsi que son mot de passe qui sera le même pour Linux et Windows. Pour ce faire, utilisez l'option -a. Exemple : # smbpasswd-a anne New SMB password: Retype new SMB password: Added user anne. Vous pouvez vérifier le contenu de /etc/samba/smbpasswd : # cat /etc/samba/smbpasswd anne:500:C4315DF197EED860C2265B23734E0DAC:9C08AB50A2F8864881B0418E3A63B77B:[U ]:LCT-40DC451B: Renouvelez l'opération pour chaque utilisateur devant accéder au serveur Samba. Dans le cas de figure ci-dessus, la méthode utilisée implique que l'utilisateur porte le même nom sur les 2 systèmes, anne dans notre cas. Il est toutefois possible de conserver un nom d'utilisateur sur Windows différent. On aura alors recours à un fichier supplémentaire : /etc/samba/smbusers. Exemple : # cat /etc/samba/smbusers # Unix_name = SMB_name1 SMB_name2 ... root = administrator admin anne = leanne Il est ensuite possible de changer le mot de passe de l'utilisateur, à partir de Windows ou bien du serveur Samba grâce à la commande smbpasswd : # smbpasswd anne New SMB password: Retype new SMB password: #

Gestion des groupes Depuis la version 3.x de Samba, les groupes sont maintenant entièrement gérés. Là encore nous allons devoir synchroniser les groupes UNIX et Windows grâce à la commande net : # net groupmap add unixgroup=nom_unix ntgroup=nom_windows Ainsi si je dispose d'un groupe utilisateurs sur Linux, et que ce groupe se nomme utilisateurs ordinaires sur Windows, on procédera de la manière suivante : # net groupmap add unixgroup=utilisateurs ntgroup='utilisateurs ordinaires' No rid or sid specified, choosing algorithmic mapping Successully added group utilisateurs ordinaires to the mapping db Pour lister les correspondances existantes : # net groupmap list utilisateurs ordinaires (S-1-5-21-567158280-4275195276-2466317430-2001) -> utilisateurs Pour supprimer une correspondance : # net groupmap delete ntgroup='utilisateurs ordinaires' Sucessfully removed utilisateurs ordinaires from the mapping db

Outils graphiques de configuration d'un serveur Samba Il existe de nombreux outils graphiques qui vont vous permettre de procéder aux mêmes manipulations mais sans utiliser d'éditeur de texte. Les intitulés des actions à réaliser reprennent généralement les mêmes dénominations que les paramètres utilisés dans le fichier smb.conf décrit ci-dessus.

KSambaPlugin KsambaPlugin est un outil graphique écrit en GTK pour KDE. Il permet de configurer entièrement un serveur Samba. Il s'agit d'un module supplémentaire pour le centre de contrôle de KDE. Il procure également des propriétés supplémentaires à Konqueror, qui lui permettent d'en faire un outil de parcours réseau Samba (voir section suivante de l'article). Pour l'installer : # urpmi ksambaplugin Préparation... ################################################## 1:ksambaplugin ################################################## Pour l'utiliser, allez dans le menu KDE "Système >> Configuration >> Configurez votre bureau". Cliquez alors sur le menu "Réseau >> Configuration de Samba". Passez ensuite en mode superutilisateur. Vous avez alors accès à la configuration de votre serveur Samba sous forme de 5 onglets : Schema4 : Ksamba - interface de configuration

• configuration de base : c'est la section [global] • configuration des partages de fichiers : nous retrouvons la section [homes] et tout autre partage de fichiers • configuration des imprimantes partagées : cet onglet permet la configuration des partages [print$] et [printers] • configuration des comptes utilisateurs : créer, modifier supprimer des utilisateurs et des groupes tout en

assurant la synchronisation • paramètres de configuration avancée : paramétrage avancé du serveur

Schema5 : Ksamba - configuration des utilisateurs

Module Samba pour Webmin Webmin est un utilitaire accessible par interface web qui va vous permettre de configurer l'ensemble de votre machine (système et réseau). Il est constitué d'un ensemble de modules dont celui consacré au serveur Samba. Pour installer Webmin, réutilisons urpmi puis démarrons webmin : # urpmi webmin Préparation... ################################################## 1:webmin ################################################## # service webmin start Lancement de Webmin [ OK ] Pour accéder à webmin, tapez dans la barre d'URL de votre navigateur : https://localhost:10000 Authentifiez-vous alors en tant que root avec votre mot de passe. Cliquez sur l'onglet "serveurs" puis "Samba Windows File Sharing"

Schema6 : Webmin - liste des partages du serveur

Vous avez alors décrit rapidement l'ensemble des ressources partagées, avec la possibilité de modifier cette configuration. Comme pour KsambaPlugin, l'ensemble du serveur est paramétrable. Schema7 : Webmin - menu principal de configuration de samba

Remarque : l'idée n'est pas ici de décourager l'utilisation de tels outils. Mais ceux-ci proposent l'accès relativement simple à des paramétrages avancés de Samba. Mal maîtrisés, vous pouvez rapidement mettre votre serveur hors d'usage. Alors attention aux clics intempestifs et gardez un oeil sur la configuration texte.

Outil graphique de parcours des ressources Samba Konqueror est maintenant un bon moyen d'accéder à un serveur Samba, il suffit pour cela de taper dans la zone URL smb://user@serveur/ ou smb://user:password@serveur/ pour accéder au serveur "serveur" en tant que "user". Schema8 : parcours des ressources Samba avec Konqueror

L'utilisation est relativement aisée, il vous suffit de cliquer sur les fichiers et/ou répertoires, comme pour un système de fichiers local.

Conclusion Voilà donc votre serveur Samba fonctionnel. Nous n'avons abordé ici qu'une infime partie des possibilités offertes. Sachez que les dernières versions permettent d'apporter les mêmes fonctionnalités qu'un serveur NT, voire 2000 : contrôleur de domaine (PDC, BDC), serveur de netlogon (authentification centralisée), serveur de résolution de noms netbios (WINS)... Bref de quoi passer de votre configuration personnelle à une véritable architecture d'entreprise !

Quelques adresses utiles • Le site officiel de Samba • La documentation officielle de Samba (une mine d'or !) : Samba-HOWTO-Collection sur la section

documentation du site

Le site officiel de cups

Chapitre 7 AMANDA Eric Doutreleau, Eric.Doutreleau@int-evry.fr v0.95, 05/08/1998 AMANDA ou "Advanced Maryland Automated Network Disk Archiver" est un logiciel de sauvegarde utilisé dans un certain de nombre de sites dans le monde qui permet de faire des "sauvegardes en réseau".

1. Avertissement Ce document décrit le logiciel AMANDA. Même si la présentation est générale, elle est plus spécialement orientée sur les plate formes installées à l'INT.

2. Introduction Comme tout le monde le sait, ou devrait le savoir, l'erreur est humaine. Donc toutes constructions humaines peut être victime d'une erreur. Les ordinateurs et l'informatique en général n'échappent pas à cette règle. Il convient donc de gérer la "possibilité" d'erreurs humaines ou de défaillances techniques. En ce qui concerne l'intégrité des données informatiques, la sauvegarde est une réponse adéquate. AMANDA ou "Advanced Maryland Automated Network Disk Archiver" est un logiciel de sauvegarde utilisé dans un certain de nombre de sites dans le monde qui permet de faire des "sauvegardes en réseau". Une machine avec un périphérique de sauvegarde attaché peut sauvegarder plus d'une centaine de machines. Cela est obtenu en utilisant le mécanisme de sauvegarde incrémentale.

3. Pourquoi une sauvegarde en réseau La sauvegarde en réseau est rendue nécessaire par différents facteurs que nous allons détailler ci-après.

3.1 Nécessité de la sauvegarde. Les machines informatiques traitent des données. Il leur faut donc stocker ces données d'entrée et les résultats produits. De plus on doit également veiller à l'intégrité de ces données pour éviter d'obtenir des résultats erronées. On se trouve alors confronté a deux menaces:

• La défaillance du matériel (disque dur, disquette,etc..) • l'erreur humaine (effacement intempestif d'un fichier)

3.2 L'organisation des ordinateurs. En quelques dizaines d'années seulement l'informatique a subi beaucoup de bouleversements. Nous sommes passés d'une architecture de "mainframe" à une architecture distribuée. Un des résultats de cette évolution est que les "données" à sauvegarder se sont trouvées disséminées sur une multitude de postes multipliant ainsi le nombre de postes à sauvegarder.

3.3 L'utilisateur de la machine. Une réponse a cette dissémination des données a été dans un premier temps de demander á chaque utilisateur de faire lui même ses sauvegardes des données "importantes". Ainsi non seulement il faut multiplier les périphériques de sauvegarde mais de plus l'utilisateur doit s'astreindre á une discipline très rigoureuse. Dans les faits ces sauvegardes ne sont jamais faites régulièrement car il y a toujours quelque chose de plus important à faire. Le recours à des personnes dédiées à cette tache devient obligatoire. La sauvegarde en réseau permet d'avoir une personne qui effectue les sauvegardes pour tous les utilisateurs.

3.4 La sauvegarde incrémentale. La quantité de données qu'on peut stocker sur une bande a beaucoup évolué ces dernières années. Ainsi on est passé typiquement de bandes de 150 Mo à des bandes de 5 Go ou plus. Néanmoins si on sauvegarde un certain nombres de machines on constate que tout ne peut pas tenir sur une seule bande. De plus une journée ne suffit pas à sauvegarder toutes les machines. Pour pallier à ces difficultés on va utiliser le fait que les données varient en fait très peu sur les machines informatiques. Ainsi à la première sauvegarde on sauvegarde la totalité des données (on l'appelle le niveau 0) et à la sauvegarde suivante on ne sauvegarde que les modifications par rapport à ce niveau 0 (le niveau 1) et ainsi de suite. Cela permet donc de réduire le volume des données sauvegardées.

3.5 Conclusion La sauvegarde en réseau est donc la solution idéale pour satisfaire les besoins suivants:

• Rationalisation et économie sur les périphériques • Garantie que la sauvegarde est effectivement faite.

4. Structure D'AMANDA

4.1 Présentation. AMANDA ( ou Advanced etc.. ) est un outil de sauvegarde développé par l'université du Maryland. Jaime Da Silva, le concepteur originel d'AMANDA, avait comme tout bon administrateur système qui se respecte une collection de script pour faire des sauvegardes des machines qu'il administrait. Devant le nombre croissant de machines à sauvegarder il décida de créer AMANDA.

4.2 Les points forts d'AMANDA • en C, distribuable gratuitement. • Est basé sur les standards de logiciels de sauvegarde.

• Unix dump et restore • Gnu tar • Possibilité d'intégrer d'autres logiciels.

• Sauvegarde plusieurs machines en parallèle sur un disque tampon, écrit les sauvegardes terminées une par une sur la bande aussi rapidement que l'on puisse écrire un fichier sur une bande. Par exemple, une bande DAT de 12 Go avec une vitesse d'écriture de 1Mo/s pour le lecteur sera remplie en 3 heures.

• Implémente une gestion de bande simple: On ne risque pas d'effacer une mauvaise bande par erreur. • Supporte des "tape changer" au travers d'une interface générique. ainsi on peut très facilement adapter

l'interface à tous type de "stackers" changeur ou caroussel. • Inclue le support pour une sécurité Kerberos 4 ainsi que des sauvegardes encryptées. • Pour récupérer les fichiers, indique les bandes dont vous avez besoin, et trouve la bonne image de sauvegarde

sur la bande pour vous. • Inclue une reprise sur incident performante. • Produit un rapport incluant toutes les erreurs et l'envoit aux opérateurs de la sauvegarde. • Ajuste automatiquement l'ordonnancement des sauvegardes et le niveau des sauvegardes tout en restant dans le

cadre prédéfini. Il n'est plus nécessaire de jongler avec l'organisation des sauvegardes lorsque l'on rajoute de nouveaux disques.

• Inclue un programme de vérification de la configuration sur le serveur ainsi que sur les clients et envoie éventuellement les résultats par courrier électronique.

• Utilise la compression sur les clients ou sur le serveur. • Possèdes beaucoup d'autres options.

> Nous allons maintenant détailler la structure d'AMANDA et en expliciter certains points forts.

4.3 Stratégie maître-esclave AMANDA est basé sur une logique maître-esclave. Le maître possède le périphérique de sauvegarde et donne des ordres aux esclaves pour qu'ils sauvegardent les disques. Il récupère ces sauvegardes et les copie sur le périphérique de sauvegarde.

Le serveur (ou maître) Le serveur doit posséder un gros disque et un lecteur de bande ainsi qu'une bonne connectivité réseau. Le disque sert de disque tampon durant la sauvegarde et stocke également des index des différentes sauvegardes.

Les clients (ou esclaves). Les esclaves sont une variétés de machine UNIX sur lesquelles on peut compiler la partie client d'AMANDA. Actuellement seules les machines UNIX sont "nativement" supportées. Des possibilités d'utiliser Samba pour sauvegarder des machines "Windosiennes" sont possibles.

Le serveur d'index. Pour chaque partition UNIX sauvegardé AMANDA offre la possibilité de générer un index des fichiers sauvegardés. Ainsi la récupération des fichiers sur les bandes en est grandement simplifié. Le mécanisme permettant de récupérer les fichiers sera étudié ultérieurement.

Les serveurs de bande annexes. On peut également installer des serveurs de bande annexe qui seront utilisé lors de la récupération des fichiers. Ainsi on peut récupérer en parallèle des fichiers de différentes sauvegardes.

5. Le mécanisme. Nous allons maintenant décrire les mécanismes et l'ordonnancement du processus de sauvegarde.

5.1 Sur le serveur. Le serveur lance cinq groupes de processus.

Le planner.

Ce programme "demande" des estimations de la taille de la sauvegarde pour les différents niveaux nécessaires aux différents clients. Avec ces informations il génère un ordonnancement de la sauvegarde.

Le driver.

Ce programme récupère l'ordonnancement produits par le planner et lance effectivement la sauvegarde en lançant les deux programmes dumper et taper et en les contrôlant tout au long de la sauvegarde.

Le dumper.

Ce programme gère l'interaction avec un client pour une partition. Un certain nombre de dumper sont lances en parallèle.

Le taper.

le taper est le programme qui contrôle le lecteur de bande.

L'indexeur.

L'indexeur est chargé de récupérer les tables d'index des sauvegardes si celles-ci ont été demandées.

5.2 Sur les clients. Sur le client il y a également plusieurs programmes qui sont installés. Le plus important est amandad qui se comporte comme un super serveur à l'instar de l'inetd. En effet c'est lui qui récupère tous les ordres du serveur et lance les programmes appropriés.

5.3 L'ordonnancement. L'ordonnancement des tâches est donc le suivant.

• Sur le serveur le planner est lancé. Celui contacte les amandad qui tournent sur chaque client. Une fois qu'il a récupéré toutes les estimations (réussies ou non) il génère un ordonnancement de sauvegarde qu'il transmet au driver. La phase d'estimation de la sauvegarde est terminée et on peut passer aux choses sérieuses.

• Le driver récupère l'ordonnancement et lance un certains nombres de dumpers et un taper. Il affecte à chaque dumper une partition sur une machine à sauvegarder. Le dumper va donc contacter l'amandad qui se trouve sur la machine cliente. Il lui ordonne de commencer la sauvegarde et de lui envoyer le résultat. En même temps que la sauvegarde est effectuée sur le client une liste des fichiers qui sont sauvegardés est générée sur le client. Le dumper recopie la sauvegarde dans le disque tampon au fur et à mesure qu'elle est effectuée. La sauvegarde de la partition terminée le dumper va s'occuper éventuellement de récupérer l'index de la sauvegarde et il se suicide le sentiment du devoir accompli. Le driver donne alors l'ordre au taper de copier sur bande la sauvegarde. Si le taper est déjà occupé la sauvegarde est placée dans une file d'attente. Et tout ce petit monde effectue son travail jusqu'à ce que toutes les sauvegardes soient sur bande.

• L'indexeur intervient alors pour récupérer sur les clients les indexs c'est à dire la liste des fichiers qui ont été sauvegardés. Pour cela il contacte le démon amandad de chaque client qui lui envoie les indexs. Cette opération est effectuée pour plus de sûreté. En effet si tout fonctionne bien il n'y a plus d'index à récupérer à ce moment là.

6. Quelques remarques sur l'installation. Je décris ici quelques remarques sur l'installation. Il est clair qu'il faut d'abord consulter la documentation d'AMANDA avant de pouvoir tirer parti de ces remarques. Un serveur Web concernant AMANDA se trouve à cette adresse: http://www.amanda.org Actuellement les versions installées sont les versions 2.4.0 et 2.3.0.4.

6.1 Départements concernés. Il existe actuellement une configuration.

La configuration INT. Cette configuration regroupe huit entités.

• SIM • Quinze Sun sous Solaris2.X • Deux SGI sous IRIX 6.X

• EPH • Six SUN sous solaris2.X • Un PC sous Linux • Une HP sous HP/UX 10.X

• MCI • sept SUN sous solaris2.x. • Trois Alpha sous OSF1. • Cinq PC sous Linux.

• LOR • Vingt cinq SUN sous Solaris2.X • Neuf SUN sous SUNOS. • 3 PC sous Linux. • 1 HP sous HP-UX/10.X • 1 PC sous Solaris.

• RST • Quatorze Sun sous SUNOS. • Douze Sun sous solaris.

• INF • Une SUN sous Solaris.

• INT-DIPLOMES • Un PC sous Linux.

• Atelier d'édition. • Une Sun sous solaris.

Voici un classement des systèmes sauvegardées. • Soixante sept clients SUN sous Solaris2.X. • Vingt trois SUN sous Sunos4.1.x • Dix clients PC Linux. • Trois clients ALPHA sous OSF • Deux clients HP sous HP/UX 10.x • Deux clients SGI sous IRIX 6.X. • Un client PC Solaris.

Ces statistiques sont réalisées avec le programme remotesysteme qui se trouve dans le répertoire /usr/local/bin/ de backup. Les chiffres que l'on doit donc retenir sur cette configuration sont les suivants:

• 108 machines sauvegardées. • 401 systèmes de fichiers. • 108 Go de disque.

Département LOR/RST.

6.2 Généralités. Le logiciel AMANDA possède les caractéristiques suivantes à l'INT par rapport à une installation que l'on pourrait qualifier de standard.

• l'utilisateur pour les sauvegardes est dumpy. • le port pour le programme amandad utilisé est le port 10080. • le port pour le programme amandaidx utilisé est le port 10082. • le port pour le programme amidxtape utilisé est le port 10083.

Pour le reste il faut se reporter aux documentations d'installation d'AMANDA.

6.3 Comment installer AMANDA Avertissement. Tous les chemins qui sont donnés dans ce chapitre sont donnés par défaut. Si vous installez amanda dans d'autre répertoires il vous faudra modifiez les chemins de façons adéquates.

Tâches communes sur le client et le serveur. • Créer le compte dumpy. Ce compte doit avoir accès aux raw devices des disques en lecture. Voici quelques

exemples de groupes sur différentes plates-formes.

Solaris.

sys.

SunOS.

operator.

Linux.

disk.

IRIX.

sys.

HP-UX.

sys. Il faut néanmoins remarquer qu'on doit changer les droits sur le raw device pour les machines Silicon et donner le droit de lecture au groupe sys.

• Mettre à jour le fichier /etc/services si celui-ci n'est pas géré par les NIS. Il faut ajouter les lignes suivantes. amidxtape 10083/tcp amandaidx 10082/tcp amanda 10080/udp

Sur les clients

Compiler le source d'AMANDA. La compilation D'AMANDA est grandement favorisée par un script d'auto-configuration. Celui ci génère automatiquement les Makefiles correspondant à votre système. Voici la ligne de commande du configure.

./configure --with-amandahosts --with-user=dumpy --with-group=disk --with-gnutar-listdir=/var/adm/amanda --with-index-server=backup --with-config=mci --with-tape-server=backup --with-tape-device=/dev/rmt/0n --with-gnutar=/usr/local/bin/tar --with-smbclient=/usr/local/samba/bin/smbclient --without-server

Il convient d'adapter les paramètres suivants dans la ligne de commande précédente:

--with-group

Il faut mettre le groupe correspondant ayant le droit de lire les raw devices pour chaque système.

--with-gnutar-listdir

Il faut indiquer dans quels répertoires le client AMANDA va stocker des données pour pouvoir gérer des sauvegardes incrémentales avec la commande tar.

--with-gnutar

Il faut indiquer le chemin de la commande gnu tar. Il est possible de ne pas renseigner ce paramètre si l'on ne souhaite pas utiliser la commande GNU tar pour faire les sauvegardes.

--with-smbclient

Il faut indiquer le chemin de la commande smbclient. Il est recommandé de ne pas renseigner ce paramètre si l'on ne fait pas de sauvegarde de partages SAMBA sur cette machine.

Cas particuliers

SunOS

On doit rajouter le paramètre --with-shared=no.

Autres manipulations • Créer le fichier .amandahosts dans le répertoire racine du compte dumpy avec comme valeur le nom du serveur

de sauvegarde correspondant. Suivant les machines on doit mettre le nom qualifié ou pas. On peut donc mettre les deux pour être plus tranquille.

backup dumpy backup.int-evry.fr dumpy

• Créer le répertoire /var/adm/amanda et transférer la propriété du répertoire à dumpy. • Créer le fichier /etc/amandates et veiller à ce que l'utilisateur dumpy puisse écrire dans ces fichiers. Cela se fait

généralement en donnant des droits d'écriture au groupe auquel appartient dumpy. • La dernière version de GNU tar est le version 1.1.12. Néanmoins il subsiste quelques petits problèmes quand

tar essaye de sauvegarder des fichiers avec pleins de zéro à l'intérieur. Un patch est fourni avec la distribution d'AMANDA.

• Modifier le ficher inetd.conf. Il faut ajouter la ligne suivante.

amanda dgram udp wait dumpy /usr/local/libexec/amandad amandad

Manipulation spécifique pour chaque système.

Linux Pour Linux il faut installer AVANT de compiler les sources les packages suivant:

• dump-0.3-10.i386.rpm • rmt-0.3-10.i386.rpm

De plus il faut veiller à ce que les droits sur l'exécutable dump soit 755. En effet La Redhat met par défaut ce fichier dans un mode différent.

Silicon IRIX. Il faut donner au groupe de dumpy un droit en lecture sur les raw devices des disques.

Sur le serveur de sauvegarde. En général le serveur est aussi un client. Je ne traiterai que la partie spécifique du serveur

Compilation. Voici la ligne de commande du configure.

./configure --with-amandahosts --with-user=dumpy --with-gnutar-listdir=/var/adm /amanda --with-group=disk --sysconfdir=/amanda/etc --localstatedir=/amanda/var

Quelques commentaires. • Le paramètre --with-group varie de la même façon que pour les clients. • Le paramètre --sysconfdir définie le répertoire où la configuration 'AMANDA est stockée. Cela concerne

les fichiers de configuration amanda.conf , disklist et tapelist. • Le paramètre --localstatedir définit l'endroit où AMANDA stocke ses fichiers générés par son

fonctionnement en particulier sa base de données ou ses fichiers de log.

Modification de l inetd.conf Il faut donc configurer le serveur pour autoriser les connexions au serveur d'index. Il suffit de rajouter la ligne suivante dans l inetd.conf amandaidx stream tcp nowait dumpy /usr/local/etc/tcpd amindexd On remarque qu'on contrôle l'accès au serveur d'index par tcp-wrapper. Le mécanisme de "restoration" sera amplement explicité plus loin.

Sur les serveur de bande annexes Il est possible de configurer d'autres machines n'intervenant pas dans la sauvegarde mais qui possèdent des lecteurs de bandes compatibles pour en faire des serveurs de lecteurs de bande. Ainsi elles pourront intervenir dans le processus de récupération des fichiers.

Compilation. Voici la ligne de commande du configure.

./configure --with-amandahosts --with-user=dumpy --without-server --without-client --without-amrecover

Le paramètre with-group varie de la même façon que pour les clients.

Modification de l inetd.conf Il faut donc configurer le serveur pour autoriser les connexions au serveur d'index. Il suffit de rajouter la ligne suivante dans l inetd.conf amidxtape stream tcp nowait dumpy /usr/local/etc/tcpd amidxtaped On remarque qu'on contrôle également l'accès au serveur de bandes par tcp-wrapper. Évidement tout ceci s'applique aussi au serveur de sauvegarde qui sert de serveur de "restoration".

6.4 Configuration du changeur de bande. Matériel. L'INT a acheté dans le courant du mois de juillet 1998 un "Autoloader" DDS3 de marque HP. Le modèle est le C1557A. Il gère un magasin de 6 cartouches de 12 Go chacune. Nous avons donc en ligne une capacité de 72 Go. Sa vitesse d'écriture annoncée est de 1Mo par seconde. A l'heure actuelle ces valeurs n'ont pas été vérifiées mais des tests sont en cours.

Logiciels utilisées.

mtx Ce matériel n'est pas livré avec des logiciels capable de le piloter. Ainsi on dit en théorie l'utiliser en "gravity stacker". On ne peut que passer à la bande suivante dans ce mode. Heureusement il existe sur Internet des programmes pour piloter ces chargeurs. Ainsi avec ces programmes on peut charger et décharger n'importe quelle bande du changeur. Pour ce modèle il en existe deux avec le même nom mtx.

• Une version qui était fourni par HP • Une version de Zubkoff/Dandelion qu'on peut trouver à l'url suivante: ftp://ftp.dandelion.com/mtx-1.0.tar.gz.

Il semblerait qu'HP ait interrompu la mise à la disposition de mtx au public. Néanmoins comme la version de zubkoff/Dandelion fonctionne bien mieux cela n'est pas très grave. Celui se trouve donc à l'emplacement suivant: /usr/local/bin/mtx/

chg-mtx. Installer le logiciel mtx ne suffit pas. En effet mtx ne répond pas à l'API des changeurs de bande pour AMANDA. Il faut donc écrire un script pour obéir à cette API. . Il y a plusieurs scripts "installés". On les trouve dans le répertoire /usr/local/libexec/.

chg-mtx.oldest

Le script fourni dans la distribution d'AMANDA chg-mtx correspond au mtx de HP. Il ne convient donc pas.

chg-mtx.old

C'est une version patchée de ce même script pour utiliser avec la version de Zubkoff/Dandelion. Hélas ce script a un bug mineur qui ne lui fait pas adhérer pleinement à l'API.

chg-mtx

C'est la version utilisée. Elle a été modestement patchée par mes soins.

Problèmes rencontrés.

Compression hardware et software. AMANDA, lors des sauvegardes, comprime les données sur les clients. C'est tout du moins la majorité des configurations à l'INT. De ce fait il est inutile voire nuisible de comprimer les données sur le lecteur de bande. En principe on peut contrôler le type de compression en sélectionnant les devices utilisés sur les machines SUN. Hélas l'expérience démontre que cela ne fonctionne pas très bien. Le fait le plus grave est que la compression hardware est activée par défaut. Heureusement le programme /usr/local/bin/setcompression nous tire d'affaire en désactivant la compression hardware.

Quelques recommandations. l'API d'AMANDA étant un peu "spéciale" l'état du changeur et ce que doit en percevoir AMANDA n'est pas forcement la même chose. Ainsi lorsque l'on charge une bande il vaut mieux resetter l'état du changeur avec la commande amtape. La commande exacte est amtape mci reset

7. La configuration d'AMANDA Je serai volontairement succinct sur la configuration d'AMANDA. En effet ce logiciel offre tellement de possibilité qu'il est difficile de les décrire exhaustivement sans écrire un roman. Je me limiterai donc aux considération les plus générales. On trouvera les fichier de configuration dans le répertoire amandaetc/amanda/conf/ où conf est le nom de la configuration.

7.1 amanda.conf C'est le fichier le plus important. Je vais détailler ci dessous les principaux paramètres.

org

Le nom de la configuration

mailto

Le compte qui reçoit le courrier életronique concernant la sauvegarde.

dumpuser

L'identité du compte de sauvegarde.

inparallel

Le nombre maximum de sauvegardes en parallèle.

netusage

La bande passante maximale allouée à la sauvegarde.

dumpcycle

La durée d'un cycle de sauvegarde.

tapecycle

Le nombre de bandes dans la rotation.

tapetype

Définit le type de lecteur de bande utilisée. Il faut que ce type soit défini plus loin dans le fichier.

runtapes

Le nombre de bande utilisée pendant une sauvegarde.

holdingdisk

Décrit le disque tampon. Puis vient une partie descriptive dans le fichier. On y décrit:

• Le type de lecteurs de bande. • Les différentes types de sauvegarde possible. Ces types seront utilisés dans le fichier disklist.

7.2 disklist Le fichier disklist indique quel disque de quelle machine on sauvegarde. Chaque ligne est constituée du triplé: machine disque type où

machine

est le nom de la machine

disque

est le nom d'une partition ou d'un répertoire.

type

est le type de sauvegarde à effectuer.

8. Comment sauvegarder. Toutes les opérations décrites ci dessous doivent être effectuées sous le compte dumpy.

8.1 Choisir la bande. Le choix de la bande sa fait avec la commande amadmin. Voici un exemple. amadmin conf tape où conf est le nom de la configuration que l'on sauvegarde. En l'occurence cela est soit sim ou eph. amadmin eph tape The next Amanda run should go onto tape EPH05 or a new tape.

8.2 Vérifications Une commande existe afin de vérifier que tout est prêt pour effectuer la sauvegarde. Cette commande est amcheck. Voici un exemple amcheck eph Amanda Tape Server Host Check ----------------------------- /holddisk: 806385 KB disk space available, that's plenty. NOTE: skipping tape-writable test. Tape EPH05 label ok. Server check took 6.858 seconds. Amanda Backup Client Hosts Check -------------------------------- WARNING: berlioz: selfcheck request timed out. Host down? Client check: 9 hosts checked in 29.558 seconds, 1 problems found. (brought to you by Amanda 2.4.0b6p3) On voit dans l'exemple précédent que la bande est OK mais qu'il y a un problème avec la machine berlioz.

8.3 Lancement de la sauvegarde. Le lancement de la sauvegarde se fait avec la commande amdump. Voici un exemple. /usr/local/sbin/amdump conf Cette commande est en pratique placée dans la crontab de dumpy.

8.4 Reprise après incident. Si un problème survient lors de la sauvegarde il peut subsister des sauvegardes sur le disque tampon. L'opérateur de la sauvegarde peut donc les sauvegarder sur bande. La commande à utiliser est amflush. Voici un exemple amflush conf

9. Comment récupérer ses fichiers dans une sauvegarde.

9.1 Problématique. Nous avons décrit pour l'instant le mécanisme de la sauvegarde. Mais pour que celle-ci soit utile il faut être capable de pouvoir récupérer facilement des fichiers qui ont été sauvegardés. On se heurte alors à plusieurs problèmes.

• Il y a un problème d'authentification. En effet il faut être sûr que la personne qui demande à récupérer un fichier ait le droit de le faire.

• Il y a également un problème d'accès physique à la bande qui contient le fichier que l'on souhaite récupérer. • L'utilisateur sait en général quand il a effacé son fichier mais il sait rarement quand il a travaillé pour la

dernière fois sur son fichiers. La recherche de la bande contenant ce fichier peut s'avérer fastidieuse.

9.2 Procédure retenue AMANDA répond partiellement à ces problèmes. En effet l'accès au serveur d'index et au serveur de sauvegarde se fait sur un port privilégié ce qui impose d'être super utilisateur sur les clients. En combinant cette protection avec tcp-wrapper on peut limiter de façon satisfaisante l'accès aux sauvegardes. Enfin la recherche de la "bonne" bande est grandement facilitée grâce au serveur d'index.

9.3 Description. On lance la commande amrecover. On se trouve alors dans un sorte de système de fichier virtuel dans lequel on va sélectionner les fichiers à récupérer. Trois paramètres définissent de manière unique ce système de fichier.

• La machine • La partition • La date de sauvegarde.

Par défaut ces paramètres sont • La machine est la machine locale • La partition est calculée avec le répertoire local • la date est celle d'aujourd'hui.

Un bon exemple valant tous les grands discours, voici un exemple.

9.4 Exemple /usr/local/sbin/amrecove 220 poseidon AMANDA index server (1.1) ready. 200 Access OK Setting restore date to today (1998-02-14) 200 Working date set to 1998-02-14. 200 Config set to eph. 200 Dump host set to poseidon. Can't determine disk and mount point from $CWD amrecover> On voit donc que le répertoire ne peut être déterminé. En effet on ne se met pas nécessairement à l'endroit exact on l'on veut récupérer les fichiers. Nous allons donc maintenant rentrer ces valeurs. amrecover>sethost olympe 200 Dump host set to olympe. amrecover>200 Dump host set to olympe. amrecover>setdisk / 200 Disk set to /. amrecover> On possède alors un certain nombre de commandes. En particulier les commandes cd et ls. amrecover> ls 1998-02-13 . 1998-02-13 TT_DB/ 1998-02-13 cdrom/ 1998-02-13 devices/ 1998-02-13 etc/ 1998-02-13 var/ 1998-02-12 . 1998-02-12 .OWdefaults 1998-02-12 .Toolboxes 1998-02-12 .Xauthority 1998-02-12 .ab_library 1998-02-12 .cshrc 1998-02-12 .cshrc~ 1998-02-12 .desksetdefaults 1998-02-12 .doomrc 1998-02-12 .dt/

1998-02-12 .dtprofile 1998-02-12 .exrc 1998-02-12 .fm/ 1998-02-12 .khoros1998-02-12 .mosaicpid 1998-02-12 .netscape/ 1998-02-12 .news_time 1998-02-12 .newsrc 1998-02-12 .openwin-init 1998-02-12 .pine-debug1 1998-02-12 .pinerc 1998-02-12 .profile 1998-02-12 .rhosts 1998-02-12 .sh_history 1998-02-12 .sunsolverc 1998-02-12 .wastebasket/ 1998-02-12 .xsun.olympe:0 1998-02-12 Mail/ 1998-02-12 TT_DB/ 1998-02-12 amandaconf/ 1998-02-12 bin 1998-02-12 cdrom/ 1998-02-12 cdrom2/ 1998-02-12 core 1998-02-12 data/ 1998-02-12 dead_letter/ 1998-02-12 dev/ 1998-02-12 devices/ 1998-02-12 eph/ 1998-02-12 essai 1998-02-12 essai.ps 1998-02-12 etc/ 1998-02-12 export/ 1998-02-12 home/ 1998-02-12 home2/ 1998-02-12 lost+found/ 1998-02-12 sbin/ 1998-02-12 sim/ 1998-02-12 svg_data 1998-02-12 tftpboot/ 1998-02-12 tmp/ 1998-02-12 usr/ 1998-02-12 var/ 1998-02-12 vol/ 1998-02-12 xfn/ 1998-02-12 net/ 1998-02-12 nsmail/ 1998-02-12 opt/ 1998-02-12 platform/ 1998-02-12 proc/ On voit que le résultat de la commande ls est divisé en deux parties.

• La première est la date de la dernière sauvegarde du fichier ou du répertoire. • La deuxième est le nom de ce fichier ou de ce répertoire.

Il est à remarquer que compte tenu des sauvegardes incrémentales le fichier n'a pas été modifié entre la date indiquée et la date que l'on a éventuellement rentré avec le commande setdate ou la date d'aujourd'hui. Déplaçons nous dans le système de fichiers pour aller sélectionner les fichiers qui nous intéressent. amrecover> cd /var/adm amrecover> ls1998-02-13 . 1998-02-13 lastlog 1998-02-13 messages 1998-02-13 sulog 1998-02-13 utmp 1998-02-13 utmpx 1998-02-13 wtmp 1998-02-13 wtmpx 1998-02-12 . 1998-02-12 acct/ 1998-02-12 aculog 1998-02-12 amanda/ 1998-02-12 lastlog 1998-02-12 log/ 1998-02-12 messages

1998-02-12 messages.0 1998-02-12 messages.1 1998-02-12 messages.2 1998-02-12 messages.3 1998-02-12 passwd/ 1998-02-12 sa/ 1998-02-12 spellhist 1998-02-12 sulog 1998-02-12 utmp 1998-02-12 utmpx 1998-02-12 vold.log 1998-02-12 wtmp 1998-02-12 wtmpx amrecover> Choisissons maintenant nos fichiers. amrecover> add messages Added /var/adm/messages amrecover> add sulog Added /var/adm/sulog amrecover> Passons maintenant à la phase d'extraction des fichiers. amrecover> extract Extracting files using tape drive /dev/rmt/0bn on host poseidon. The following tapes are needed: EPH04 Restoring files into directory /tmp Continue? [Y/n]: Y Load tape EPH04 now Continue? [Y/n]: Y set owner/mode for '.'? [yn]y amrecover> la commande extract permet de lancer l'extraction des fichiers. Le programme nous indique alors le répertoire où l'on va placer les fichiers et le numéro de bande que l'on doit placer dans le lecteur. Après une demande de confirmation l'opération d'extraction est effectuée. Enfin le programme demande si l'on veut récupérer également les droits initiaux sur les fichiers. Et voila nous avons récupéré deux fichiers /var/adm/messages et /var/adm/sulog.

10. Liste des commandes disponibles. Voici une liste des commandes disponibles. Pour des renseignement plus approfondis on se reportera avantageusement aux pages de manuel correspondantes.

amadmin

C'est la commande d'administration pour contrôler les sauvegardes.

amcheck

Lance la procédure de vérification.

amcheckdb

Vérifie la consistance de la base de données.

amcleanup

Effectue du "nettoyage" après un "plantage" du serveur de sauvegarde.

amdump

Lance la sauvegarde.

amflush

Sauvegarde les fichiers laissés sur le disque tampon après un problème sur la bande de sauvegarde.

amlabel

Formatte la bande.

amoverview

Produit une vue synthétique des machines sauvegardées au cours du temps.

amplot

Visualise le comportement d'AMANDA lors d'une sauvegarde.

amrecover

Butineur de la base d'index produit par AMANDA.

amrestore

Extrait des fichiers des bandes de sauvegarde AMANDA.

amrmtape

Efface une bande de la base de données d'AMANDA.

amtape

Interface utilisateur pour piloter les changeurs de bande.

amtoc

Génère une table des matières pour une sauvegarde AMANDA.

amverify

Vérifie une bande AMANDA.

11. Conclusion AMANDA est donc un logiciel de sauvegarde très performant pour effectuer la sauvegarde en réseau d'un parc de station de travail UNIX. Il n'a pas à rougir de la comparaison avec d'autres logiciels de sauvegarde beaucoup plus onéreux.