lundi 24 mai 2004

Partie Routeur linux

Nous allons étudier la mise en place d’un service routage sous linux.

Tout d’abord, nous allons représenter le réseau local dans lequel le routeur linux devra être implanté :

On vois donc que le routeur linux va permettre l’accès a Internet via le routeur en 10.10.1.250.

On dispose donc de 2 cartes réseau :

Ø      Une que l’on configure sur le réseau local 31.64.0.0/11

Ø      Une autre que l’on configure sur le réseau 10.10.1.124/16

On va donc configurer les différentes routes sur ce serveur.

Les route présente par défauts sur le serveur :

Pour intégrer le routeur dans le réseau local, on va donc devoir rajouter quelque route.

Ø      Une route pour le réseau 31.32.0.0

Ø      Une route pour le réseau 31.96.0.0

On passera par le second routeur Windows dont l’adresse est 31.64.0.1

On va également rajouter une route sur le routeur Windows pour aller sur le réseau 10.10.0.0 avec comme passerelle le routeur linux.

Pour faire ceci on utilise la commande route.

route add -net 31.32.0.0 netmask 255.224.0.0 gw 31.64.0.1

et

route add -net 31.32.0.0 netmask 255.224.0.0 gw 31.64.0.1

add: on ajoute une route.

-net : le réseau de destination

netmask : le masque appliqué

gw :  la passerelle à utiliser

on réaffiche maintenant la table de routage pour vérifié que les nouvelles routes on été prise en compte :

partage de la connexion Internet :

les routes étant maintenant parfaitement réglé, on a maintenant accès de n’importe ou sur le réseau vers le réseau 10.10.0.0.

pour pouvoir partager la connexion Internet, on va rajouter une route par défaut vers le routeur 10.10.1.250 :

route add default gw 10.10.1.250

défaut: précise que la route, est une route par défaut.

On affiche la table de routage :

On dispose bien maintenant d’une route par défaut sur le routeur Internet, ce qui va nous permettre de réexpédier tout les trames qui ne sont pas accessible par notre réseau local (Internet).

On va de plus devoir rajouter une route par sur le routeur Windows : si il ne peut pas atteindre le réseau de destination, alors il réexpédiera le paquets vers le routeur Windows

 Problème rencontré : impossibilité d’avoir l’accès a Internet sur les autres machines.

En effet il y a un problème de connexion du a la configuration du réseau.

Suivons la connexion par étape

1ere étape : le client envoie une donnée sur Internet, et étant donnée que la destination n’est pas dans son réseau local, il l’envoi sur la passerelle 31 96.0.1.

2éme étape : le routeur Windows ne pouvant pas atteindre le réseau de destination du paquet, il réexpédie le paquet vers sa passerelle par défaut

3éme étape : le routeur linux ne pouvant accéder au réseau de destination du paquet, il va renvoyer sur sa passerelle par défaut, c’est a dire le routeur en 10.10.1.250

A présent le routeur va s’occuper de l’envoyer sur Internet, Le problème est que lorsque le routeur va vouloir retourné la réponse, il ne va pas savoir par ou passer pour atteindre le réseau du poste émetteur et donc le paquet ne reviendras jamais à l’émetteur.

Solution du problème : le Masquage des adresses, ou la NAT

Un solution consiste a utiliser la NAT pour masquer les adresses du sous réseau local.

Le procéder consiste lors de l’envoi du routeur linux au routeur Internet (10.10.1.250) de remplacer l’adresse d’émetteur par l’adresse du routeur, ainsi le routeur Internet saura ou renvoyer le paquet, et il suffira au routeur linux de remplacer son adresse par l’adresse de l’émetteur qu’il avais préalablement supprimé.

On va donc utiliser la commande iptables.

Iptables –A POSTROUTING –o eth1 –j MASQUERADE

Cela signifie que l’on va masqué (natter) tout les paquets passant sur l’interface eth1, l’interface menant au routeur Internet

On peut vérifier cette règle en tapant : iptables –t nat –L

Ainsi tout les postes de nos sous réseau pourrons accéder directement a internet.

Partie samba

Présentation

samba est une application serveur qui va permettre une implémentation libre du protocole SMB (Server message Block) pour Unix.

Le protocole SMB est le coeur de NetBIOS qui est le protocole utilisé par les machines windows.

Il va donc nous autoriser à partager les fichiers et les imprimantes entre Unix/linux et windows.

Le serveur SAMBA est en mesure de se conduire comme un serveur de fichiers capable d'offrir les services habituels sur un réseau :

Le serveur partage ses ressources (système de fichiers, imprimantes ...) aux clients Windows qui s'y connecteront sous un compte créé par root, après une authentification par mot de passe.

On va régler le serveur samba pour que chaque utilisateur puisse accéder à :

Les utilisateurs devront pouvoir se connecter via leur compte Windows ce qui nous forcera à synchroniser les comptes linux/windows.

Les imprimantes devront gérer la tolérance de panne.

Le fichier de configuration smb.conf

Le fichier de configuration principal de samba est stocké dans le fichier /etc/samba/smb.conf

nous allons le configurer pour une utilisation de base.

Configuration générale :

On définie les paramètres globaux de samba

[global]

nom netbios de la machine, c’est avec ce nom qu’il sera vu dans les partages

netbios name = picsou

nom du domaine ou du groupe de travail auquel fait parti le serveur

workgroup = carbonne

nom “affiché” de la machine

server string = serveur Picsou %v

nom des fichiers log. La variable %m récupère le nom de la machine.

ceci permet de crée un fichier de log par machine.

log file = /var/log/samba/%m.log

max log size = 100

niveau de sécurité appliqué. Avec le mode utilisateur, le serveur va tenter d’authentifier les utilisateurs avec son fichier contenant les comptes et les mots de passe, dans notre cas le fichier /etc/samba/smbpasswd.

security = user

cette expression va nous permettre de crypter les mots de passe pour l’authentification

ceci est utile pour les windows supérieur à la version 98

encrypt passwords = yes

le fichier ou l’on stocke les logins et mots de passe des utilisateurs.

smb passwd file = /etc/samba/smbpasswd

on déclare que l’on ne veut pas être un explorateur du réseau local

local master = no

os level = 33

on déclare également que l’on ne veut pas devenir explorateur de tout le domaine.

domain master = no

on déclare que l’on ne veut pas être l’explorateur préféré.

preferred master = no

option par défaut de connexion

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

On peut maintenant tester la configuration.

Pour ceci on va devoir, avec le compte root ajouter un nouveau utilisateur :

Adduser toto

Puis on ajoute le compte samba pour cet utilisateur :

Smbpasswd –a toto

On saisira donc le mot de passe pour cet utilisateur.

On va donc allez accéder au serveur samba, on lui précisera le login toto et le mot de passe toto.

On aura donc ceci :

On voit bien notre serveur linux, son nom est bien picsou, et on voit qu’il peut partager des ressources, seulement nous n’en avons pas fait.

Il nous faut donc créer des partages.

Configuration des partages :

On va donc créer 2 partages :

·        un répertoire personnel

·        un répertoire commun à tout le monde.

Le partage HOMES est en fait un partage de base de samba, il permet de partager le répertoire de base des utilisateurs.

Cela revient à peut près au même que si l’on avait crée tous les comptes utilisateur dans le répertoire /home et que l’on avait rajouté le paramètre :

Path = /home/%u

La variable %u récupère le nom de l’utilisateur.

[homes]

      le commentaire du partage

comment = Répertoire personnel

le propriétaire est le seul à pouvoir voir ce partage

browseable = no

les utilisateurs ont le droit d’écriture dans leur dossier

writable = yes

les seuls utilisateurs valide sont ceux de la session

valid users = %S

droit à appliquer lorsque l’on créer un fichier

create mode = 0740

droit à appliquer lorsque l’on créer un répertoire

directory mode = 0740

On créer maintenant un répertoire public accessible en lecture/écriture pour tous

[public]

      Commentaire du répertoire

comment = Répertoire public

on spécifie le nom du répertoire

path = /public

on autorise le répertoire en écriture.

writeable = yes

On peut vérifier les paramètres grâce à la commande testparm

ATTENTION!!:

Le répertoire public (dans notre cas /public) doit avoir les droits suffisant pour que les utilisateurs puissent écrire dans le répertoire.

Ceci fait, en retournant sur le partage on va voir les 2 répertoires partagés :

Partie winbind

Le problème de l’intégration de serveur LINUX / samba avec les contrôleurs de domaine est la différence dans la gestion des utilisateurs et donc une grande difficulté sera rencontrée lorsque l’on voudra intégrer un serveur Samba dans un réseau windows.

En réalité nous voulons créer sur le serveur samba tous les comptes systèmes correspondant aux comptes des utilisateurs du domaine.

Ce mode de fonctionnement, bien que fonctionnel, est laborieux à mettre en place :

La bonne solution consiste en fait à utiliser une seule base de compte, et c’est à cela que winbind va nous être utile.

En effet winbind est un système client serveur qui va nous permettre d’introduire aisément les serveurs Samba dans un domaine où se trouve déjà les contrôleurs CPD.

En fait, il va se charger de récupérer la base des utilisateurs sur le CPD et va l’utiliser pour procéder à l’authentification de ceux-ci.

Pour implanter WinBind il va falloir modifier le fichier de configuration de samba dans /etc/samba/smb.conf

niveau de sécurité appliqué. En utilisant ce mode, samba va utiliser le contrôleur de domaine pour authentifier tous les logins/mots de passe des utilisateurs au lieu du fichier /etc/smbpasswd

security = domain

Attention ! ce paramètre est indispensable pour le mode de sécurité « domain ».

encrypt passwords = yes

On attaque maintenant la partie de winbind proprement dite :

on synchronise les mots de passe système avec les mots de passe samba si ceux ci sont changé.

unix password sync = yes

spécifie à samba d’essayer de synchroniser les droits unix avec les ACL Windows

nt acl support = yes

permet d’utiliser le système “pam” pour authentifier et autoriser les utilisateurs.

obey pam restrictions = yes

Les paramètres suivants vont permettre de savoir quoi lancer lorsque l’utilisateur veut changer de mot de passe ou lorsque samba veut rajouter un compte, etc…

passwd program = /usr/bin/passwd %u

passwd chat = *New*password* %n\n *Retype*new*password* %n\n *passwd:*all*authentification*tokens*updated*successfully*

add user script = /usr/sbin/useradd %U -d /home/%u -m -s /bin/false

delete user script = /usr/sbin/userdel -r %U

allow trusted domains = yes

on précise au serveur quel est l’hôte qui servira de serveur wins pour résoudre les noms

wins server = 31.32.0.2

on lui précise également l’ordre de consultation des services de noms

name resolve order = wins host

Ici on précise quel serveur on va utiliser pour authentifier les différents utilisateurs.

ATTENTION!! Ce paramètre doit être complété car si on laisse la valeur standard, (*) le serveur va essayer de trouver le CPD grâce à une diffusion, et comme ce dernier n’est pas dans le même réseau, on va être obligé de préciser le nom, ainsi que le serveur WINS.

Dans notre cas le CPD sera donc Mickey

password server = MICKEY

le caractère qui permet de séparer le nom du domaine, et le nom d’utilisateur

winbind separator = /

le nombre de secondes pendant lequel winbind va stocker dans un cache les utilisateurs et les groupes avant de réinterroger le CPD

winbind cache time = 10

ce paramètre va nous permettre de ne pas récupérer le nom de domaine, ce qui nous est très peu utile étant donné que nous n’avons qu’un seul domaine.

winbind use default domain = yes

shell par défaut des utilisateurs du domaine que l’on va récupérer.

template shell = /bin/false

répertoire personnel des utilisateurs du domaine que l’on va récupérer.

template homedir = /home/%U

plage des uid pour les utilisateurs du domaine

winbind uid = 10000-20000

plage des gid pour les groupes du domaine

winbind gid = 10000-20000

maintenant que tout est configuré, on va relancer le service samba ainsi que le service winbind.

Apres ceci on va faire rejoindre le serveur samba au domaine.

Pour ceci on va utiliser la commande smbpasswd :

smbpasswd -j nom_du_domaine -r nom_cpd -U administrateur%motdepasse

Donc dans notre cas on va lancer la commande :

smbpasswd -j Carbonne -r mickey -U administrateur%motdepasse

Ce qui aura pour effet de renvoyer la ligne suivante :

ce qui nous confirme que le serveur à bien rejoint le domaine.

Maintenant que WINBIND est lancé, on va utiliser la commande wbinfo pour tester la récupération de la liste des utilisateurs et des groupes.

ATTENTION !! : lors de la première utilisation de la commande, elle risque de renvoyer un simple pointeur. Le problème est que l’on n’a pas donné à WinBind le compte avec lequel se connecter au PDC.

Pour corriger ceci on lance la commande :

wbinfo –A administrateur%motdepasse

on relance alors la commande :

wbinfo –u

et on obtient ceci:

Nous pouvons également utiliser la commande

getent passwd

qui va nous régénérer un fichier passwd incluant les comptes locaux puis les comptes récupérés.

On constate bien que des comptes ont été crées avec des sid et des gid entre 10000 et 20000 provenant du contrôleur de domaine.

Fonctionnement :

On placera donc « winbind » dans les lignes  suivantes :

passwd:     files nisplus nis winbind

shadow:     files nisplus nis

group:      files nisplus nis winbind

ce qui lui permettra de passer par winbind lors de l’autentification.

Winbind apporte en réalité un module d’authentification pour linux.

On utilisera ce module dans PAM (Pluggable Authentication Modules).

C’est ici que l’on dira à samba d’utiliser winbind pour authentifier les utilisateurs du contrôleur de domaine.

3 fichiers dans le répertoire /etc/pam.d/ vont nous être utile :

Le fichier login va être utiliser lorsque quelqu’un va se connecter au linux directement sur la machine.

Dans ce fichier on va rajouter les lignes suivantes :

Ø      la première ligne va nous permettre d’utiliser le plugin winbind de pam pour faire l’authentification.

Ø      La seconde ligne permet de lancer l’authentification par winbind.

Ø      La dernière ligne permet de créer automatiquement le répertoire personnel lors de sa première connexion.

Ensuite le fichier system-auth-winbind

Ce fichier permet de généraliser les authentifications, il nous suffira juste de l’appeler dans d’autres modules de pam, dans notre cas le module samba.

Ce fichier est légèrement différent du fichier system-auth dans le sens ou il va permettre de créer directement le répertoire de l’utilisateur lors de son premier accès au partage samba.

ATTENTION : un problème rencontré lors du fonctionnement de ce module est que le paramètre obey pam restrictions = yes doit impérativement être present dans le fichier smb.conf, si celui n’est pas present alors le répertoire des utilisateurs ne sera pas crée car une authentification n’est pas traitée de la même façon qu’une ouverture de session.

Dernièrement le fichier samba va donc nous permettre d’authentifier les utilisateurs du domaine :

En fait dans ce fichier il suffit juste de remplacer les lignes qui font appel au fichier

system-auth par system-auth-winbind ce qui va permettre d’utiliser le système d’authentification de winbind au lieu de celui par défaut.

A présent nous pouvons accéder à nos partages linux avec des comptes provenant de notre contrôleur de domaine windows.

Pour créer les imprimantes, on utilisera le système de gestion des imprimantes CUPS.

Routage Windows:

Pour permettre à nos différents segments réseau de pouvoir communiquer entre eux, il faut installer un routeur (routeur agissant au niveau de la couche 3 réseau du modèle OSI contrairement à un pont couche 2 liaison) disposant d’une adresse sur chaque segment utiliser.

Note : contrairement a un pont, pour un routeur les protocoles des différents segments peuvent être différent

Serveur GEO :

Matériel :

-         3 cartes réseaux

Rôle :

-         Routeur : 

Il faut pour que chaque sous-réseau puisse communiquer avec les autres il faut rajouter des routes statiques sur le serveur.

Dans le détail, disposant de 3 sous réseau, chaque paquet arrivant d’un réseau doit pouvoir communiquer avec les 2 autres donc 2 routes par sous réseau.

Au total il nous faut donc 3 réseaux * 2 routes = 6 routes a définir comme ci-dessous.

Ainsi toutes les routes ajoutées on obtient une table de routage complète.

Pour mieux comprendre le fonctionnement du routeur voici un schéma expliquant le déroulement de la commande ping a travers différent segment du réseau.

A l’aide du moniteur réseau on peut voir les trames du ping.

Sur la carte réseau du routeur à l’adresse 31.96.0.1

Sur la carte réseau du routeur à l’adresse 31.64.0.1

Le déroulement de commandes réseau à travers le routeur se déroule donc sans encombre comme l’indique les trames capturées.

Partie CUPS:

Nous allons déjà présenter l’implémentation des imprimantes dans le réseau :

nous avons donc 2 imprimantes installées sur 2 serveurs différents.

On va donc installer un serveur cups sur chacun des serveurs en installant une imprimante sur chaque, et grâce au fonctionnement de cups, celui-ci va diffuser ces imprimantes sur le réseau à la recherche d’autres serveurs cups.

On voit bien que le service cups à :

Ø      Une imprimante locale « jetdencre »

Ø      Une imprimante sur une autre machine « laser » présent sur picsou

Au lieu de l’interface web, on peut également utiliser les commande fournie par cups :

Pour ajouter une imprimante :

On va utiliser la commande lpadmin pour ajouter une imprimante à cups

Lpadmin –p laser –E –v parallel:/dev/lp0

Cette ligne va rajouter l’imprimante « laser » au serveur cups, va l’activer (-E) et va définir l’accès (-v parallel:/dev/lp0).

On peut maintenant vérifier l’état de l’imprimante avec la commande

Lpstat –a

Ce paramètre va permettre de récupérer l’état de l’imprimante (activée, file d’attente, etc…)

On peut également voir les paramètres de l’imprimante en se rendant sur l’interface web de

Cups.

Le serveur cups se servant de ipp pour les impressions, on va pouvoir ajouter une imprimante avec l’adresse :

            http://<nomduserveur>:<port>/printers/<nomdelimprimante>

donc dans notre cas on utilisera

http://picsou.carbonne.fr:631/printers/ laser

On dit à l’assistant que l’on veut installer une imprimante réseau.

puis on donne l’adresse de l’imprimante.

on verra donc l’imprimante avec l’adresse pour y accéder.

Nous avons vu dans cette partie comment installer le serveur cups, son fonctionnement et comment imprimer à partir du serveur.

Seulement dans l’utilisation de notre réseau, nous devons pouvoir avoir accès à ces imprimantes par samba, nous allons donc maintenant presser l’interaction entre samba et cups.

Partie Interaction Samba / Cups

Pour faire interagir samba et cups, nous allons devoir rajouter des déclarations au fichier smb.conf :

On précise le type de serveur d’impression que l’on va utiliser

printcap name = cups

On charge toutes les imprimantes que l’on peut à partir du serveur

load printers = yes

c’est le style d’impression :  par quel programme on passe pour lancer les impressions

printing = cups

On ajoutera de plus un nouveau partage.

Ce partage est un partage spécial de samba, il permet juste de partager les imprimantes.

[printers]

les commentaires à afficher

comment = all printers

accessible à tout le monde

public = yes

le répertoire de spool des impressions

path = /var/spool/samba

browseable = yes

writable = no

on peut imprimer.

printable = yes

create mode = 0700

la commande que l’on utilise pour imprimer.

print command = lpr-cups -P %p %s –r

Après ceci on redémarre le serveur Samba et on peux voir les imprimantes :

Problème : si on essai d’installer les imprimantes avec un client, il va devoir installer les pilotes pour l’impression.

Il existe une solution pour fournir directement au client les drivers.

On utilisera donc les drivers génériques postscript car cela va nous permettre de compter le nombre de page imprimer.

On récupère le paquetage nommé cups-samba-drivers-1.1.18-1.noarch.rpm qui aura pour but d’installer les drivers dans le répertoire /usr/share/cups/drivers

On ajoute ensuite un partage à smb.conf :

            Partage spécial contenant les drivers

[print$]

            commentaire pour le partage

comment = drivers pour imprimantes

répertoire où seront stockés les pilotes

path = /etc/samba/printer_drivers

on n’autorise pas l’utilisateur par défaut à se connecter

guest ok = no

on peut seulement lire les données

read only = yes

seul root

write list = root

Ensuite on peut exécuter le script automatique :

Cupsaddsmb –v –a

Celui-ci va créer les répertoires des imprimantes et associer directement ceux-ci avec les drivers, ainsi lorsque les clients vont installer l’imprimante, le serveur samba va lui envoyer les drivers instantanément.

Répartition de charge

Il est possible de gérer la répartition de charge entre les imprimantes linux,

Pour faire ceci, il suffit de créer une classe et de paramétrer les 2 imprimantes :

Ainsi lorsque l’on explorera, on verra une nouvelle imprimante.

Droits sur les imprimantes

Dans le fichier smb.conf, on a déclaré un partage appelé [printer]. 

Ce partage créer un accès à toutes les imprimantes, et ce n’est pas ce que l’on veut.

On va donc créer un partage spécifique par imprimante.

[laser]

        comment = imprimante laser

        public = yes

        path = /var/spool/samba

        browseable = yes

        writable = no

        valid users = @MAIRE, @ADJOINTS, @SECRETAIRES, @SGENERAUX, @SGASS, Administrateur

        printable = yes

        create mode = 0700

        print command = lpr-cups -P laser %s -r

[jetdencre]

        comment = imprimante jetdencre

        public = yes

        path = /var/spool/samba

        browseable = yes

       valid users = @ADJOINTS, @CONSEIL, @SGASS, Administrateur

       writable = no

        printable = yes

        create mode = 0700

        print command = lpr-cups -P jetdencre %s -r

 Les seules différences avec la déclaration générale [printers] est que l’on peut mettre des droits individuels à chaque imprimante, et surtout la dernière ligne, qui définie directement l’imprimante sur laquelle on écrit au lieu de la récupérer avec une variable.

Combinaison : droits et tolérance de pannes.

Pour faire en sorte que les droits soient conservés et que la tolérance de pannes soit activée, un bon moyen est de modifier le paramètre print command et de faire un script qui permettrait de tester si l’imprimante peut imprimer et dans le cas contraire d’imprimer sur l’autre imprimante.

Print command = /usr/local/samba/bin/monscript  %p %s

Les valeurs %p et %s sont des variables qui corresponde a l’imprimante, et de spool.

Postfix

Principe

PostFix est un MTA (Message Transfert Agent).

Le MTA, Message Transfert Agent est composé de deux agents. Un agent de routage (sendmail, MS eXchange...) et un agent de transport (SMTP).

L'agent de routage a pour but d'acheminer le message, en fonction de l'adresse vers son destinataire. L'agent de transport (smtp) un message et une direction. Il ne prend aucune décision sur la route à utiliser. Le logiciel Postfix assure les deux fonctions de transport et de routage.

L'UA ou MUA, Message User Agent, est le programme utilisé par le client pour composer, envoyer et recevoir les messages. Pour la composition et l'envoi des messages,il existe des programmes comme mail sous Linux. D'autres programmes sont utilisés comme Eudora, Netscape... On appelle souvent l'UA un "mailer local" (si on utilise des outils comme Eudora ou Oulook) ou un "webmail" si on utilise un navigateur comme Mozilla, ou Internet explorer pour consulter sa messagerie. Ces outils utilisent des protocoles différents. Les protocoles utilisés sont SMTP pour envoyer, et POP3 ou IMAP pour recevoir.

Architecture

Postfix est basé sur des programmes semi-résidents, coopérant, assurant chacun une tâche précise, sans relation de père-fils entre eux. L'un des avantages est de rendre chaque service, comme la réécriture des adresses par exemple, disponible à tous les processus sans augmenter le nombre de processus.

Un démon-maître résident se charge de lancer les différents programmes en fonction des besoins. Ces processus peuvent être dupliqués plusieurs fois, sont réutilisables plusieurs fois et s'arrêteront au bout d'un certain temps (tous ces éléments sont configurables.

L'intérêt est de pouvoir facilement réduire l'architecture au strict minimum.

Le fichier /etc/postfix/master.cf

Les démons sont réutilisés et contrôlés par un super démon "master" qui les crée à la demande. Le fichier /etc/postfix/master.cf définit les démons à lancer, leur nombre et les "transports".

Le fichier de configuration /etc/postfix/main.cf

Le fichier main.cf contient tous les paramètres de Postfix.

Pour une configuration minimum il faut renseigner les champs myhostname, mydomain, myorigin, mydestination, inet_interfaces.

Mon nom de machine

Le paramètre myhostname décrit le nom de domaine propre de la machine exploitant le système Postfix. $myhostname apparaît comme valeur par défaut dans beaucoup d'autres paramètres de configuration de Postfix.

Par défaut, myhostname contient le nom de la machine. Si le nom de machine n'a pas la forme d'un nom de domaine, ou si on veut utilisez Postfix sur une interface virtuelle, on doit indiquer le nom de domaine que le système de courrier devrait employer.

Mon nom de domaine

Le paramètre de mydomain indique le domaine de rattachement de $myhostname. Généralement, il est dérivé de $myhostname ôté de la première partie.

Quel domaine afficher dans le courrier sortant

Le paramètre myorigin indique le domaine qui apparaît dans le courrier envoyé sur cette machine.

De quels domaines recevoir le courrier

Le paramètre mydestination indique les domaines pour lesquels cette machine délivrera le courrier localement, au lieu de le transmettre à une autre machine. La valeur par défaut est de recevoir le courrier à destination de la machine elle-même.

Puisque la machine est un serveur de mail pour le domaine, on doit ajouter $mydomain.

Mes adresses de réseau

Le paramètre inet_interfaces indique toutes les adresses d'interface réseau sur lesquelles le système Postfix doit écouter; le courrier adressé à l’[utilisateur]@[adresse de réseau] sera délivré localement, comme s'il était adressé à un domaine énuméré dans $mydestination.

Par défaut Postfix écoute sur toutes les interfaces actives.

Postconf

postconf permet de visualiser rapidement l'ensemble de la configuration, y compris les paramètres par défaut et les changements.

Lancement de Postfix

On active le service avec la commande /etc/rc.d/init.d/postfix stop | star | restart ou service postfix stop | start | restart.

On vérifie le bon démarrage du serveur dans le fichier de log (/var/log/mail/info):

et dans la table des processus (ps axf) :

Test en local

Pour envoyer un mail il suffit d’utiliser la commande mail :

La réception des messages (entrées)

Quand un message doit être traité par un système Postfix, le passage obligé est la file incoming (qui contient les messages en cours de réécriture et de nettoyage).

Si le message est posté localement, il est déposé dans un répertoire en accès "écriture possible pour tout le monde". Le démon pickup le traitera à partir de là. Ce démon procède à une première phase d'analyse des couriers (headers).

Si le message provient d'un réseau, le message est traité par un serveur SMTP. Certaines règles de sécurité et de contrôles sont déjà effectuées.

Les messages peuvent être générés par Postfix lui même ou par un robot afin de prévénir l'administrateur des erreurs, adresses introuvables, tentatives de violations des règles, problèmes de protocoles...

Les messages peuvent être redistribués par des entrées dans les fichiers d'alias.

Le démon cleanup représente la période finale de traitement d'un message, notamment la vérification de l'entête du message (user@fqdn), la réécriture d'adresse, le dépôt du message dans la file incoming, l'avertissement du gestionnaire de liste.

Délivrer les messages

Quand un message est arrivé dans la file incoming, l'étape suivante consiste à le délivrer. Ceci est pris en charge par le gestionnaire de file qui est le coeur du système de Postfix. Il contacte un agent (smtp) chargé de délivrer les messages en lui communiquant des paramètres (localisation du message, nom/adresse de l'émetteur, nom(s)/adresse(s) du/des destinataires, machine hôte de destination...).

L'agent de traitement pour l'acheminement distant des messages s'appuie sur le protocole SMTP et utilise le port 25.

Les différents démons sont activés "à la demande" par un super serveur (master daemon) un peu à la façon d'inetd.

On vérifie que le message a bien été réceptionné

Le message est alors supprimer du serveur (à mois que l’on utilise le protocole imap pour récupérer ses mails ou bien le protocole pop en ayant précisé notre souhait de garder les mails en copie sur le serveur pendant un temps).

Le dialogue entre le client et le serveur

Le dialogue est défini par le protocole SMTP selon un schéma client/serveur. Sur le client, un démon (smtpd par exemple) attend les requêtes TCP sur le port 25 d'un client (le programme mail par exemple).Le dialogue est en ASCII. Pour tester, on utilise la commande :

telnet serveur_SMTP 25

Les flèches rouges correspondent aux commandes client

PostOFFICE Protocole

Le service POP - Postoffice Protocole est utilisé par les logiciels clients (Outlook, Eudora...) pour relever le courrier sur les serveurs de messagerie. Le client pop utilise un couple Nom d'utilisateur/mot de passe pour la phase identification/authentification par le serveur. Le service pop3d reste en écoute sur le port 110. Il est lancé par le démon xinetd.

Remarque : pour pouvoir l’utiliser, il faut installer le package imap Madrake).

Client pop3

Il faut configurer un compte courrier avec un logiciel client (Outlook Express) sur une machine distante.

Avec un client pop, les messages sont, par défaut, téléchargés depuis le serveur sur le client. La procédure supprime les fichiers téléchargés sur le serveur. Cette option est configurable sur la majorité des clients.

IMAP (Internet Message Access Protocol)

Pop a été conçu pour la consultation hors ligne. Imap permet la consultation hors ligne, mais également en ligne, selon un processus interactif entre le client et le serveur. Les messages ne sont plus rapatriés sur le client. Ils restent en dépôt sur le serveur jusqu'à ce que l'utilisateur demande explicitement la suppression ou le transfert.

Ce procédé est particulièrement intéressant pour les utilisateurs mobiles. Ils peuvent consulter leurs messages à partir de machines ou de lieux non définis à l'avance.

Ces services utilisent des protocoles/ports différents. Ils peuvent cohabiter simultanément sur le même serveur. Un utilisateur peut utiliser selon ses besoins l'un ou l'autre des services POP ou IMAP.

Des logiciels d'interface sur le serveur comme SquirrelMail ou IMP permettent de transformer le serveur IMAP en serveur "webmail". Les clients pourront alors utiliser n'importe quel navigateur pour consulter leur boîte aux lettres.

Test IMAP sur le serveur

Testons le bon fonctionnement du serveur : la commande ps aux | grep imap ne donne rien car le serveur imap est lancé à la demande par le démon xinetd.

Par contre la commande netstat -a | grep LISTEN | grep imap montre bien qu'un port est bien ouvert en écoute.

On tape la commande telnet localhost 143 pour activer le service imap. Le serveur doit répondre :

Dans une autre session, la commande ps aux | grep imap montre maintenant que le service est maintenant bien dans la liste des processus:

et la commande ps axf montre bien que le processus imapd dépend (est fils de ) xinetd

Client imap

La configuration du compte courrier imap avec Outlook Express est très similaire à celle avec pop.

Les alias

Le fichier de configuration chargé de définir des alias est /etc/postfix/aliases.

Quand le courrier doit être délivré localement, l'agent de livraison local passe chaque destinataire local par la base de données d'alias. Ces translations n'affectent pas des adresses dans des en-têtes de message. Les alias locaux sont typiquement employés pour les listes de distribution, ou pour rediriger le courrier des alias standards tels postmaster vers de vraies personnes. La table peut également être employée pour transformer des adresses prenom.nom en nom de login.

Après chaque modification du fichier source utiliser la commande postalias hash:/etc/postfix/aliases qui met à jour le fichier de bases de données /etc/postfix/aliases.db

Pour automatiser la création des alias on crée un script perl qui va permettre de créer des alias à partir d’un fichier exporté d’active directory, ListeUtilisateurs.csv. Cette exportation se fait grâce à la console utilisateurs active directory sur le contrôleur de domaine. Le script ne crée des alias que pour les comptes utilisateur disposant d’un nom et d’un prénom nécessaire pour la syntaxe de l’alias : prénom.nom@carbonne.fr.

Test

sabine.minighetti sera l'alias du compte système sabine. Le courrier sera adressé à sabine.minighetti@carbonne.fr, mais sera délivré dans la boîte du compte sabine, c'est à dire physiquement dans /var/spool/mail/sabine.

Maintenant on souhaite pouvoir envoyer un même message à plusieurs utilisateurs en une seule fois, pour cela on va créer une liste dans le fichier /etc/postfix/aliases

On régénère le fichier aliases.db puis on envoie un message à courrier@carbonne.fr

ANNEXE : Squirrelmail

Squirrelmail est un webmail (c'est-à-dire une interface web pour consulter son courrier électronique), écrit en PHP4. La volonté originelle était de pouvoir accéder à son courrier électronique depuis n'importe où dans le monde. Pour cela, une interface web est idéale, étant donné que l'utilisateur a accès à internet.
Il supporte les protocoles IMAP et SMTP, et toutes les pages générées le sont en pur HTML (sans aucun Javascript), ceci afin d'être compatible avec le maximum de navigateurs.

Squirrelmail inclut de base toutes les options que l’on est en droit d'attendre d'un logiciel de messagerie, y compris le support MIME, un carnet d'adresses, et la création de dossiers pour trier les e-mails.

Installation de Squirrelmail

Prérequis

Sont nécessaires à l'installation de SquirrelMail :

Installation

Il faut se placer dans le répertoire souhaité, par exemple /usr/local, ou /www/, détarez le fichier tarball et éventuellement renommer le répertoire squirrelmail-1.4.x obtenu (webmail, mail, ...).

Les répertoires essentiels :

Taper en ligne de commande (dans le répertoire de Squirrelmail) : ./configure

On a alors un menu avec 9 commandes de base :

A chaque modification, il faudra sauvegarder la configuration en tapant 'S' puis revenir au menu principal en tapant 'R'.

1. Organization Preferences : Ici on rentre des informations sur le domaine, logiquement la seule information à changer est la langue (option 6. 'Default Language') que vous devrez passer à fr_FR.

2. Server Settings : C'est une partie primordiale : elle permet de configurer les serveurs SMTP et IMAP, ainsi que le domaine. A remplir avec soin.

Il faut laisser les ports SMTP et IMAP à leurs valeurs par défaut (25 et 143), et indiquer le type de serveur qu’on utilise.

3. Folder Defaults : Toute la configuration des dossiers IMAP.

4. General Options : options générales.

Là encore on peut laisser les valeurs par défaut, ces options sont intéressantes pour avoir une configuration un peu plus fine de Squirrelmail.

5. Themes : vous permet de changer le thème / la CSS par défaut.

6. Address Books (LDAP) : option utile si on utilise un annuaire LDAP pour stocker les adresses mails.
 

7. MOTD : 'Message Of The Day' : c'est le message affiché en haut de votre Boîte de réception lorsque vous vous connectez à Squirrelmail.

8. Plugins : Cette partie permet de sélectionner les plugins à activer/désactiver.

Pensez à bien mettre les plugins récupérés dans le répertoire 'plugins' de Squirrelmail.

9. Database : utile si on utilise une base de données. Cette fonctionnalité permet de stocker les préférences utilisateurs ainsi que le carnet d'adresses dans une base de données.

Utilisation

Ca y est ! Squirrelmail est installé et configuré.

Il faut maintenant créer un lien symbolique qui constituera un simple pointeur dans l’arborescence du serveur apache vers le répertoire SquirrelMail :

ln -s /usr/local/squirrelmail-1.4.2/ squirrel

/usr/local/squirrelmail-1.4.2/ correspond au répertoire dans lequel est installé SquirrelMail

Pour accéder à l’interface de SquirrelMail, il suffit de se connecter au serveur via son navigateur internet : https://31.64.0.3/squirrel/

Test

Pour tester martin va envoyer un message à chii avec une pièce jointe de type Excel :

Une fois dans la boite de réception de l’utilisateur de chii, on constate bien la présence d’un mail émis par martin.