[MIR LINUX] - jerome.teneur.free.frjerome.teneur.free.fr/ressources/mir/MIR_4_linux.pdf · Delahaie...

10/01/2011 ERE P43

Teneur Jérôme Gayral Bastien Promé Rudy Desseaux Vincent Hamon Arnaud Delahaie Jérôme Groupe MediaNetWork

[MIR LINUX] Ce rapport portera sur l’infrastructure du système d’information d’Aristote dans une configuration Linux. L’étude. L’étude détaillera les choix et préconisations technologiques ainsi que la configuration des éléments afin de répondre aux besoins exprimés.

[MIR LINUX] MediaNetWork

Introduction (Jérôme TENEUR) 2

Version du document

Version Modifications apportées Date

1.0 Première version du document 20/12/2010

1.1 Ajustement entre partie pour cohérence 28/12/2010

1.2 Correction orthographe 3/01/2011

1.3 Refonte de la mise en page 8/01/2011

Equipe MediaNetwork

- Teneur Jérôme (Chef de projet)

- Gayral Bastien

- Promé Rudy

- Desseaux Vincent

- Hamon Arnaud

- Delahaie Jérôme



Sommaire 1. Introduction (Jérôme TENEUR) ....................................................................................................8

2. Organisation et gestion des comptes utilisateurs (Jérôme Teneur) ..............................................9

1. Rappel du cahier des charges ..................................................................................................9

2. Choix d’une solution ................................................................................................................9

1. Comparatif des solutions existantes.....................................................................................9

2. Solution retenue ................................................................................................................ 10

3. Implémentation de LDAP dans l’architecture d’Aristote ......................................................... 11

1. DIT LDAP............................................................................................................................ 11

2. Besoins et ressources ........................................................................................................ 12

3. Configuration des serveurs ................................................................................................ 13

4. Administration de l’annuaire LDAP .................................................................................... 15

5. Configuration des clients ................................................................................................... 16

4. Conclusion............................................................................................................................. 17

3. Le serveur de configuration IP (Vincent Desseaux) .................................................................... 18

1. Rappel des besoins ................................................................................................................ 18

2. Introductions......................................................................................................................... 18

3. Présentation du plan d’adressage employé ........................................................................... 19

4. Présentation du service DHCP ............................................................................................... 19

5. Autres fonctionnalités lié à DHCP .......................................................................................... 20

1. Le relai DHCP ..................................................................................................................... 20

2. La haute disponibilité et la répartition de charge ............................................................... 20

3. La mise à jour dynamique des entrées DNS ........................................................................ 21

6. Intégration du service dans le système d’information ............................................................ 22

1. Définition des paramètres communs à mettre en place pour Aristote................................ 23

2. Relais DHCP ....................................................................................................................... 23

3. Schéma de l’architecture DHCP à mettre en place ............................................................. 24

7. Les pré-requis et coûts de la solution .................................................................................... 24

1. Les pré-requis .................................................................................................................... 24

2. Coûts de déploiement ....................................................................................................... 24

3. Coûts lié à l’administration ................................................................................................ 24

4. Résolution de noms IP (Rudy Promé) ......................................................................................... 25


2. Solution que nous proposons ................................................................................................ 25



1. Bind9 ................................................................................................................................. 25

2. Le nom de domaine ........................................................................................................... 25

3. Implémentation de Bind9 (Serveur Maître) ........................................................................... 26

1. Installation ........................................................................................................................ 26

2. Configuration .................................................................................................................... 26

3. Les enregistrements dynamiques....................................................................................... 26

4. Implémentation des serveurs Esclaves .................................................................................. 27

1. Haute disponibilité pour le siège ........................................................................................ 27

2. Les sites distants ................................................................................................................ 27

3. Les postes clients ............................................................................................................... 27

5. Supervision des serveurs ....................................................................................................... 28

6. Schéma physique de l’architecture DNS................................................................................. 28

7. Coûts ..................................................................................................................................... 29

1. Coûts matériels ................................................................................................................. 29

2. Coûts humains ................................................................................................................... 29

3. Conclusion ......................................................................................................................... 29

8. Maquette .............................................................................................................................. 29

5. Le serveur de ressources (Jérôme Delahaie) .............................................................................. 30

1. Rappel du besoin : ................................................................................................................. 30

2. Solutions existantes : ............................................................................................................. 30

1. L’appliance matérielle : ...................................................................................................... 30

2. L’appliance logicielle : ........................................................................................................ 30

3. Serveur Linux ou Unix ........................................................................................................ 30

4. Solution retenue ................................................................................................................ 31

3. Architecture proposée........................................................................................................... 31

1. Besoins par sites ................................................................................................................ 31

2. Analyse de l’usage ............................................................................................................. 31

3. Solutions face aux contraintes : ......................................................................................... 33

4. Coûts ..................................................................................................................................... 34

6. Système de sauvegarde (Arnaud Hamon) .................................................................................. 35


2. Comparatif ............................................................................................................................ 35

3. Solution retenue ................................................................................................................... 36

1. Architecture de fonctionnement ........................................................................................ 36



2. Backkuppc ......................................................................................................................... 37

3. Gestion de la taille du lieu de sauvegarde .......................................................................... 38

4. Gestion du temps de restauration des fichiers ................................................................... 40

4. Coûts ..................................................................................................................................... 40

7. Le serveur web et l'accès internet sécurisé (Bastien Gayral) ...................................................... 41


1. Objectif ............................................................................................................................. 41

2. Exigences et option ........................................................................................................... 41

2. Serveur Web ......................................................................................................................... 42

1. Présentation ...................................................................................................................... 42

2. Les logiciels de serveur HTTP ............................................................................................. 42

3. Architecture du serveur web ............................................................................................. 43

4. Accès public ....................................................................................................................... 43

5. Accès privé (Intranet) ........................................................................................................ 43

3. Accès internet sécurisé .......................................................................................................... 44

1. Introduction ...................................................................................................................... 44

2. Présentation ...................................................................................................................... 44

3. Fonctionnement ................................................................................................................ 44

4. Proxy cache ....................................................................................................................... 44

5. Implémentation du proxy .................................................................................................. 45

6. Installation et configuration ............................................................................................... 45

7. Conclusion ......................................................................................................................... 46

8. Mise en place d’un Firewall avec Netfilter/Iptables (Vincent Desseaux) ..................................... 47

9. Serveur VPN (Bastien Gayral) .................................................................................................... 48

1. Introduction .......................................................................................................................... 48

2. Présentation.......................................................................................................................... 48

3. Solutions VPN existantes ....................................................................................................... 48

4. Implémentation de VPN dans l’architecture d’Aristote .......................................................... 49

Création des certificats et des clés ............................................................................................ 49

5. Configuration du serveur VPN ............................................................................................... 50

6. Conclusion............................................................................................................................. 50

10. Outil de monitoring système et réseau (Arnaud Hamon) ....................................................... 51

11. Infrastructure global (Jérôme TENEUR) .................................................................................. 52

12. Conclusion (Jérôme TENEUR) ................................................................................................ 53



13. Bibliographie ......................................................................................................................... 54

7. Lexique.................................................................................................................................. 57

14. Annexes ................................................................................................................................ 59

1. Organisation et gestion des comptes utilisateurs (Jérôme Teneur) ........................................ 59

1. Choix de l’environnement graphique ................................................................................. 59

2. Mise à jour de l’annuaire ................................................................................................... 60

3. Tests de l’annuaire ............................................................................................................ 61

4. Kerberos ............................................................................................................................ 62

5. Liste partielle des attributs LDAP de la classe « organization » ........................................... 63

6. Liste partielle des attributs LDAP de la classe « inetOrgPerson » ........................................ 64

7. Script création utilisateurs ................................................................................................. 65

8. Configuration des clients LDAP .......................................................................................... 67

9. Configuration pour le montage des répertoires personnels................................................ 67

2. Récapitulatif des réseaux de chaque site à mettre en place (Vincent Desseaux)..................... 69

1. Plan d’adressage des sous réseaux par site ........................................................................ 69

3. Configuration d’un serveur DHCP (Vincent Desseaux) ............................................................ 69

1. Configuration du canal failover du site d’Orsay : ................................................................ 71

2. Mise en place de la fonctionnalité de mise à jour du DNS .................................................. 71

3. Les aspects sur la sécurité .................................................................................................. 72

4. Déroulement du service DHCP ........................................................................................... 73

5. Relais DHCP ....................................................................................................................... 74

6. Fichiers de configuration ................................................................................................... 75

7. dhcpd.master.orsay ........................................................................................................... 76

4. Configuration du DNS BIND9 (Rudy Promé) ........................................................................... 77

1. Configuration serveur Maître............................................................................................. 77

2. Configuration serveur Esclave ............................................................................................ 78

3. Phases de tests DNS........................................................................................................... 78

5. Configuration matérielle des serveurs de fichiers (Jérôme Delahaie) ..................................... 79

6. Serveur de sauvegarde (Arnaud Hamon) ............................................................................... 81

7. Configuration du serveur Squid (fichier server.conf) (Bastien Gayral)..................................... 83

8. Commande Iptables (Vincent Desseaux) ................................................................................ 85

9. Règle de filtrage (Vincent Desseaux) ...................................................................................... 86

10. Mise en place d’un serveur Nagios sur une Debian (Arnaud Hamon).................................. 88

4. Mise ne place de PnP4Nagios ............................................................................................ 88



Table des figures

Figure 1 - Carte géographique ................................................................................................8

Figure 2 - DIT LDAP ...............................................................................................................11

Figure 3 - Besoins Aristote ....................................................................................................12

Figure 4 - Réplication et cluster LDAP ...................................................................................17

Figure 5 - Architecture DHCP ................................................................................................24

Figure 6 : Schéma infrastructure DNS ...................................................................................28

Figure 7 - Schéma de synthèse LVM ......................................................................................33

Figure 8 - Implémentation serveur de backup.......................................................................36

Figure 9 - fonctionnement des sauvegardes .........................................................................39

Figure 10 : Source Netcraft 2010 ..........................................................................................42

Figure 11: Implémentation du serveur web ..........................................................................43

Figure 12 : Implémentation des proxys Squid .......................................................................45

Figure 13 : Implémentation du serveur VPN .........................................................................49

Figure 14 - Graphique NAgios ...............................................................................................51



1. Introduction (Jérôme TENEUR) MediaNetwork a en charge la mise en place d’un système d’information complet sous

environnement Linux/Unix pour le groupe Aristote. Le but de ce projet (dont le chef est Jérôme

Teneur) est de disposer, à terme, d’une infrastructure cohérente, en environnement linux, couvrant

l’ensemble des besoins exprimés par le groupe Aristote :

- L’organisation et la gestion des comptes utilisateurs (Jérôme T.) - Le serveur de configuration IP. (Vincent) - La résolution de noms IP (Rudy) - Le serveur de ressources (Jérôme D.) - Le serveur de sauvegarde (Arnaud) - Le serveur web et l'accès internet sécurisé (Bastien et Rudy)

Aussi, au travers de notre expertise, nous préconiserons l’intégration de nouveaux éléments dans le

système d’information d’écoulant des besoins exprimés :

- Firewall (Vincent) - Serveur VPN (Bastien et Rudy) - Monitoring et gestion des incidents (Arnaud) - Présentation de l’infrastructure globale (Jérôme T.) - Virtualisation sous ESX (Arnaud & Jérôme D.)

L’étude recouvrira les sites d’Orsay, Bayonne, Bruxelles et Sophia Antipolis ayant respectivement

400, 180, 160 et 80 postes clients (820 en tout).

Figure 1 - Carte géographique

Enfin, notons que nous utiliserons la distribution Ubuntu 10.10 pour les utilisateurs et une

distribution Debian 5.0.7 pour les serveurs.


Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 9

2. Organisation et gestion des comptes utilisateurs (Jérôme

Teneur)

1. Rappel du cahier des charges

Le cahier des charges exprime les besoins suivants : L’architecture de l’annuaire doit s’articuler

autour d’unités organisationnelle par service. Il nous est demandé dans un second temps de mettre

en place un outil facilitant la gestion des utilisateurs en s’appuyant sur une interface graphique. De

plus l’importation des utilisateurs et des groupes devra pouvoir se faire via un fichier texte associé à

un script automatisé pour inclure de nouveaux utilisateurs. Enfin les utilisateurs devront pouvoir

changer de mot de passe aisément.

2. Choix d’une solution

1. Comparatif des solutions existantes

Dans le monde du libre, deux grandes solutions sont mises en avant : NIS et OpenLDAP. Toutes les

deux sont des annuaires permettant de gérer les utilisateurs de manière centralisée. Une autre

solution consiste à s’appuyer sur une base de données pour gérer les utilisateurs.

NIS

Network Information Service (NIS) (anciennement Yellow Pages) est un système client-serveur

permettant de centraliser les principaux fichiers d’administration situés dans le répertoire /etc/ tels

que passwd (utilisateurs), group (groupes), host (résolution noms d’hôtes/adresse IP), shadow (mots

de passe cryptés), etc. Son but est de distribuer les informations contenues dans ces fichiers afin de

gérer de façon cohérente, centralisée et automatisée la configuration des postes de travail au sein

d’un domaine NIS.

LDAP

Aujourd’hui, le format d’annuaire LDAP est largement utilisé dans les entreprises notamment de par

sa compatibilité multi-plateformes avec des applications web et bureautiques. Il a pris le dessus sur

NIS et constitue désormais la meilleure technologie de gestion des utilisateurs et d’authentification

centralisées. OpenLDAP est la solution d’annuaire LDAP de référence car elle offre un bon compromis

entre robustesse (montée en charge de la base de données) et facilité d’intégration (richesse

documentaire) et d’administration (possibilité de scripts et interface graphique).

Base de données

Une base de données peut par définition être utilisée pour stocker les utilisateurs et les groupes

associés de l’entreprise. Cependant il faut garder à l’esprit que la l’architecture même de la base de

données n’est pas optimisée pour répondre à ce type de besoins. En effet dans le cadre d’une

infrastructure de cette ampleur, les coûts en termes de ressources seront plus importants pour une

base de données que pour un annuaire car ce dernier est optimisé pour la lecture.



Tableau comparatif LDAP / Base de Données

Critère LDAP Base de données

Rapport Lecture/Ecriture Optimisé en lecture Lecture/Ecriture

Extensibilité Facile (Schéma LDAP) Difficile (via schéma entité-association)

Distribution des tables Inhérentes Rare

Réplication Possible Possible

Modèle transactionnel Simple Avancé

Standard Oui Non (spécifique à un SGBD)

Tableau comparatif LDAP / NIS (Network Information Services)

Critères LDAP NIS

Port 389/636 par défaut Arbitraire

Chiffrement des données Possible Impossible

Mécanismes de contrôle d’accès

Oui Non

Distribution des tables Oui Non

Réplication Oui (partielle possible) Oui (uniquement totale)

Sémantique des recherches Avancée simple

2. Solution retenue

Nous avons présenté deux solutions qui couvrent aussi bien l’une que l’autre l’ensemble des

exigences d’Aristote en termes d’organisation et de gestion des utilisateurs.

Toutefois, même si NIS est réputé performant, il présente des lacunes côté sécurité, contrairement à

OpenLDAP qui, couplé à Kerberos, permet d’authentifier le client et le serveur et de crypter les

échanges.

Concrètement, cela signifie que, à la différence de NIS, la solution OpenLDAP + Kerberos permet de

ne pas diffuser les mots de passe sur le réseau et de garantir que c’est le bon serveur qui répond aux

requêtes clientes et que ce sont les bons clients qui reçoivent les informations.

Etant donné que les deux solutions présentent la même architecture avec des besoins similaires en

termes de ressources matérielles, l’aspect sécurité constitue, de notre point de vue, un argument

déterminant pour une entreprise de l’envergure d’Aristote.

De plus, bon nombre d’applications et de matériels réseaux s’appuient aujourd’hui sur un annuaire

LDAP pour la gestion des utilisateurs et même parfois sur kerberos pour offrir l’authentification

unique (SSO).



3. Implémentation de LDAP dans l’architecture d’Aristote

1. DIT LDAP

Une base LDAP est une base de données où les informations sont enregistrées de manière

hiérarchique sous forme d’arbre et non sous forme tabulaire. Cette arbre LDAP permet d’avoir une

vue globale de l’architecture organisationnelle de l’annuaire d’entreprise. Ainsi l’arbre sera organisé

en trois grandes OU, à savoir « People » (regroupera tous les utilisateurs d’Aristote), « machines »

(listera toutes les stations et serveurs), et enfin « group ». Ce dernier servira d’attribue permettant

de spécifier la direction d’appartenance de chaque utilisateur. Cela aura un rôle primordial dans la

gestion des accès aux ressources de l’entreprise.

De plus les OU « People » et « group » seront divisés en quatre sous OU représentatives des sites

d’Aristote. Enfin, chaque sites de l’OU « machines » sera encore subdivisé afin de séparer les

machines serveurs des stations utilisateurs.

L’ensemble des attribues utilisés dans le cadre de l’implémentation de cet arbre sont décrit en

annexe 1.5 et 1.6

Figure 2 - DIT LDAP



2. Besoins et ressources

Le nombre de machines offrant le service LDAP est directement lié au nombre d’utilisateurs accédant

à la ressource. Mais d’autres facteurs doivent également être pris en compte. On notera par exemple

la nécessité d’avoir une tolérance aux pannes, des besoins en haute disponibilité (notamment lors

des pics I/O le matin à 9h, le midi, et le soir à 18h).

Pour toutes ces raisons nous préconisons l’installation d’un serveur LDAP par site. Ainsi aucun

d’entre eux ne sera tributaire de la liaison MPLS en cas de dysfonctionnement de cette dernière. Un

système de réplication inter-site sera donc mit en place afin de garder une synchronisation

permanente et en temps réel des quatre sites (CF : chapitre -> Réplication). De plus, sur le siège

d’Orsay nous devrons faire face à de très nombreuses requêtes dû au grands nombre d’utilisateur.

Pour cette raison, il est préférable de mettre en place un cluster LDAP.

Ce dernier fonctionnera d’une manière bien spécifique afin d’optimisé au maximum les flux et les

délais de réponse notamment lors des pics I/O. Pour cela nous préconisons la mise en place d’un

LoadBalancer en amont des deux serveurs LDAP (s’appuyant sur l’utilisation d’une Virtual IP). Ces

derniers seront synchronisés en temps réel via un lien dédié leur permettant également de vérifier

en permanence l’état de leur voisin. Cette partie sera plus largement développée dans le chapitre

« Partage de charge (LoadBalancer) ».

Figure 3 - Besoins Aristote



3. Configuration des serveurs

1. Configuration de LDAP

Après installation des paquets slapd et ldap-utils sont demandé les paramètres de bases du

serveur :

nom de domaine DNS Vsn-aristote.lan

Password de l'admin LDAP Password

Format de la base LDBM

Autoriser le protocole v2 non

La configuration du serveur se fera au travers de plusieurs fichiers. Le répertoire ldap se décompose

de la façon suivante :

On notera la présence d’un répertoire « schema » permettant de décrire les attributs de la base

LDAP, ainsi que du fichier slapd.conf. Ce fichier contient l’ensemble des paramètres

indispensables au fonctionnement de l’annuaire dont voici un extrait :

A noté que chaque modification du fichier de configuration /etc/ldap/slapd.conf il est

nécessaire de redémarrer le service slapd :

# /etc/init.d/slapd restart

Enfin, la base de données en elle-même sera située par défaut dans le répertoire suivant :

Pour plus de commodités, nous allons démarrer le serveur LDAP au démarrage de la machine. Pour

cela on rajoute au fichier /etc/rc.conf :

LDAP1:~# ls -l /etc/ldap/

total 28

-rw-r--r-- 1 root root 245 jui 24 10:47 ldap.conf

drwxr-xr-x 2 root root 4096 jui 24 10:48 sasl2

drwxr-xr-x 2 root root 4096 jan 3 18:44 schema

-rw-r----- 1 root openldap 5399 jan 5 23:50 slapd.conf

LDAP1:~#

suffix "dc=vsn-aristote,dc=lan"

rootdn "cn=admin,dc=vsn-aristote,dc=lan"

rootpw password loglevel 256

LDAP1:~# ls -l /var/lib/ldap/

total 932

-rw-r--r-- 1 openldap openldap 2048 jan 9 03:16 alock

-rw------- 1 openldap openldap 8192 jan 9 03:16 __db.001



-rw-r--r-- 1 openldap openldap 96 jan 3 18:47 DB_CONFIG

[…]

# LDAP

slapd_enable="YES"

slapd_flags="-h ldap:///"



Réplication

La réplication consiste à mettre en œuvre un serveur primaire, des serveurs secondaires qui seront

l'exacte réplique du serveur primaire.

Plusieurs méthodes de réplication existent (tel que slurpd), mais nous ne nous attarderons que sur

syncrepl qui est la directive la plus flexible et la plus simple à mettre en œuvre.

Syncrepl spécifie la base de données comme étant un réplicat dont le contenu est maintenu à jour

avec celui du maître en déclarant que le processus courant serveur est un site client de réplication

fonctionnant grâce au moteur de réplication dénommé syncrepl.

Le contenu du réplicat est maintenu synchronisé avec celui du maître en utilisant le protocole de

synchronisation de contenu. Le serveur maître peut envoyer ses mises à jour à intervalles régulières

ou dès qu’une modification est effectuée.

La configuration des serveurs maitre et esclave est détaillé en annexe

De plus, il est possible de vérifier en temps réel le bon déroulement des réplications grâce à

l’application syweno. Cette dernière, s’appuie sur le libraire LDAP et deux APIs Java pour remonter

les informations de synchronisation, et ainsi garder une parfaite maitrise du bon déroulement des

réplications.

Partage de charge (LoadBalancer)

Le site d’Orsay doit être en mesure de répondre à un nombre de requête beaucoup plus important

du fait de son nombre d’utilisateurs. Pour cela il nous parait primordial de mettre en place un

système de partage de charge permettant à deux serveurs de répondre à tour de rôle. Ainsi nous

préconisons l’implémentation d’un LoadBalencer.

Une autre solution peut être envisagée, il s’agit d’utiliser une VIP (Virtual IP). Plusieurs méthodes

permettent de définir lequel des deux serveurs doit répondre. Ceci n’étant pas le sujet de cette MIR,

nous ne développerons pas plus cet aspect.

Notons que dans les deux cas la réplication entre ces deux serveur sera géré de manière

bidirectionnelle grâce à syncrepl.



Kerberos

Les mots de passe des usagers doivent impérativement être acheminés en clair depuis les postes de

travail qui hébergent des services jusqu'aux serveurs LDAP chargés des opérations de contrôles.

L'utilisation du protocole sécurisé LDAPS (LDAP sur TLS) permet de contourner ce problème puisqu'il

impose une session TLS avant tout dialogue LDAP. L'utilisation de services de fichiers mutualisés

contrôlés par LDAP accentue ce problème car les mots de passe doivent circuler en clair jusqu'aux

services avant d'être acheminés ensuite (éventuellement en LDAPS) jusqu'aux serveurs LDAP.

Kerberos fonctionne en environnement hétérogène, assurant la sécurité des échanges sur un réseau

non sûr et permettant la mise en place d'un véritable service d'authentification unique.

Kerberos utilise un système de chiffrement symétrique pour assurer un dialogue sécurisé entre deux

protagonistes. Les dialogues s'opèrent en utilisant une clef secrète et partagée. Les algorithmes de

chiffrement sont publics (AES, DES, 3DES, ...), toute la sécurité du système repose sur la

confidentialité de la clef de chiffrement. Pour faciliter la gestion d'un tel système, Kerberos repose

sur l'utilisation d'un tiers de confiance qui distribue les clefs aux utilisateurs et services abonnés. Un

serveur Kerberos est appelé KDC (Key Distribution Center). Le service d'authentification assure

l'identification unique du client et lui procure un ticket de session qu'il pourra utiliser pour demander

des tickets d'utilisation des services kerbérisés. Un ticket de session chiffré avec la clef d'un service

kerbérisé constitue un ticket de service.

La configuration du serveur KDC ainsi que des clients Kerberos est détaillé en annexe 1.4

4. Administration de l’annuaire LDAP

L’administration d’un annuaire LDAP, c’est-à-dire la création/suppression d’utilisateurs, la gestion du

parc informatique, etc… peut se faire en ligne de commande ou de manière graphique. Cela suppose

l’ajout d’une application tierce qui peut être situé sur le serveur ou sur le client. Plusieurs solutions

sont disponibles sur le marché. Notre choix se porte sur l’application web ldap-account-manager

(présentation et comparaison de différentes solutions en annexe 1.1)

On notera la possibilité de réaliser des scripts afin de faciliter cette tâche souvent fastidieuse. Un

exemple de script (annexe 1.7) vous permettra d’ajouter de nouveaux utilisateur à partir d’un fichier

prérempli et respectant un formatage défini.



5. Configuration des clients

Configuration LDAP

L’identification des clients auprès de l’annuaire LDAP suppose une configuration préalable de ces

derniers. Nous allons pour cela nous appuyer sur les deux modules linux PAM et NSS :

Nous devons donc configuré PAM afin de permettre l’indentification depuis le serveur LDAP. Cela se

fera au travers de quatre fichiers décrit en annexe 1.8.

Configuration pour monter les répertoires personnels

La gestion des répertoires personnels et leur emplacement est défini dans l’annuaire LDAP. Nous

allons nous appuyer sur le serveur de fichier NFS pour monter automatiquement les répertoires des

utilisateurs. Ainsi nous choisissons que toutes les données personnelles des utilisateurs soient

directement enregistrées sur le serveur de fichier NFS et ce de manière transparentes pour les

utilisateurs.

L’implémentation de cette stratégie de gestion des /home nécessite des modifications de

configuration au préalable :

- du serveur NFS

- modification du schéma LDAP

- modification de l’arbre LDAP

L’ensemble de ces modifications est plus largement décrit en annexe 1.9

PAM : Pluggable Authentication Modules (en français : modules d'authentification

enfichables) est un mécanisme d'authentification flexible, permettant par le biais de

modules, de définir des stratégies et de proposer différents médias comme sources

pour l'identification des utilisateurs (bases de données, annuaire, clé USB, …).

L'administrateur système n'est plus ainsi limité aux fichiers /etc/passwd et

/etc/shadow. L'authentification via PAM ne concerne pas seulement l'accès au système

mais tout service que la machine héberge.

NSS : Name Service Switch (en français : commutateur de services de nommages),

permet de fournir à Linux/Unix non pas des services d'authentification, mais des

services de correspondances entre noms, de toutes sortes (noms de machines,

utilisateurs, groupes, …), et les identifiants de ces mêmes objets pour la machine

(respectivement adresses IP, uid, gid dans l'exemple précédent). NSS, fonctionne de

manière similaire à PAM, c'est-à-dire sur la base de modules.



4. Conclusion

Figure 4 - Réplication et cluster LDAP

Ce schéma résume bien l’idée que le cœur de l’infrastructure LDAP se situera au niveau du cluster

LoadBalancer d’Orsay. La réplication y sera bidirectionnelle et en temps réel. Enfin tous les sites

viendront répliquer l’ensemble des bases annuaires d’Orsay, et notons que les conditions de

réplication pourrons être ajustées en fonction de leur impact réseau.


Le serveur de configuration IP (Vincent Desseaux) 18

3. Le serveur de configuration IP (Vincent Desseaux)

1. Rappel des besoins

Dans le cadre de notre étude, il nous est demandé de mettre en place une solution

permettant aux stations Linux du site d’obtenir via un serveur DHCP, leur configuration IP.

Conformément aux besoins énoncés par Aristote, il convient de rappeler les différents points

que nous devons prendre en comptes pour cette partie d’étude, afin bien évidement d’être

cohérents et au plus près de ses attentes.

Il nous est donc demandé :

- D’attribuer via un serveur DHCP les adresses IP des stations Linux du site - De définir un plan d’adressage pour les permanents ainsi que pour le personnel itinérant. - De mettre en place une mise à jour automatique de(s) serveur(s) ayant attrait aux noms IP et

à leur résolution.

De plus, il nous est demandé d’intégrer une procédure de mise à jour de l'OS et des applications principales du serveur.

2. Introductions

Le protocole IP suppose la pré-configuration de chaque ordinateur connecté au réseau avec

les paramètres TCP/IP adéquats, ce qu’on appelle plus communément l’adressage statique. Sur des

réseaux de grandes dimensions ou étendues, où des modifications interviennent souvent, l’adressage

statique engendre une lourde charge de maintenance et de nombreux risques d’erreurs, notamment

des conflits d’adressage.

DHCP (Dynamic Host Configuration Protocol) est un protocole réseau dont le rôle est

d’assurer la configuration automatique des paramètres IP d’une station, notamment en lui affectant

automatiquement une adresse IP et un masque de sous-réseau, il est l’extension même du protocole

BOOTP. Mais DHCP ne s’arrête pas là, il peut aussi configurer bon nombre d’option tel que l’adresse

de la passerelle par défaut, ou bien encore des serveurs de noms DNS. Les spécifications de ce

protocole sont définies par les RFC 2131 (Dynamic Host Configuration Protocol) et RFC 2132 (DHCP

Options and BOOTP Vendor Extensions).

Dès lors qu’on met en place une infrastructure réseau de moyenne ou grande taille tel qu’un

réseau local d’entreprise, il est indispensable de s’appuyer sur DHCP pour attribuer les configurations

IP des stations. Elle permet une plus grande souplesse lors de la modification d’un paramètre

commun à toute les stations tel que l’adresse IP de la passerelle ou bien encore l’adresse IP d’un

serveur de nom DNS.

Dans un environnement Linux, cette fonction est réalisée dans une très majeure partie au

moyen du daemon dhcpd. Développé par l’ISC (Internet Systems Consortium), il est la version la plus

largement utilisé et est fiable et robuste. Nous ne reviendrons donc pas sur le choix de ce produit.



3. Présentation du plan d’adressage employé

Notre plan d’adressage IP a pour base les adresses privées de classe B (172.16.0.0/16 à

172.31.255.255/16). Afin que la solution reste évolutive, on se verra attribuer une adresse réseau de

classe B en utilisant le 2ème octet pour différencier chaque site. Seul la DMZ se verra attribuer d’un

espace d’adressage privé de classe A, à savoir le réseau 10.0.0.0/8. Ci joins en annexe un récapitulatif

des réseaux de chaque site à mettre en place.

Afin de dissocier au mieux le flux de chaque service et d’organiser l’espace d’adressage, il est

décidé de créer des sous réseaux pour chaque site en fonction des directions. Nous utiliserons

intégralement le 3ème octet pour cet usage, ainsi le masque de sous réseau sera de 255.255.255.0

pour chaque direction de chaque site.

Sachant également que les sous réseaux mis en place pour un site sont sur le même réseau

physique, il convient de mettre en place une politique de VLAN, celui-ci permettra notamment au

relai DHCP, dont nous verrons son utilité, de dissocier les flux DHCP des sous réseaux qu’il dessert.

Ci-joint en annexe l’ensemble des sous réseaux que nous allons déployer et l’affectation des N°

de Vlan pour chaque site.

4. Présentation du service DHCP

DHCP fonctionne sur le modèle client-serveur : un serveur, qui détient la politique d'attribution

des configurations IP, envoie une configuration donnée pour une durée donnée, à un client donné.

Lorsqu'un client DHCP initialise un accès à un réseau TCP/IP, le processus d'obtention du bail IP se

déroule en 4 requêtes, à savoir les requêtes DHCP Discover, DHCP Offer, DHCP Request et DHCP ACK.

Pour qu’un client récupère d’un serveur DHCP une adresse IP, il doit utiliser le daemon

dhclient, le client DHCP de l’ISC qui est installé par défaut dans la majeure partie des cas sur les

systèmes Linux.

Ci-joint en annexe de plus amples sur le Déroulement d’attribution d’une adresse par DHCP

ainsi que la configuration du serveur DHCP



5. Autres fonctionnalités lié à DHCP

1. Le relai DHCP

Nous avons précédemment vu que les clients contactent les serveurs DHCP à l'aide d'une

diffusion. Or dans une architecture inter-réseau, nous devrions théoriquement installer un serveur

DHCP par sous-réseau, ce qui induit la multiplication d’un même service et par la même, du risque

d’erreurs liés aux configurations à mettre en place.

La RFC 3046 (DHCP Relay Agent Information Option) pallie à ce problème en intégrant une

spécification concernant la redirection des paquets DHCP vers un serveur se situant sur un réseau

logique distant. Cette fonction est de nos jours, et dans la majeure partie des cas, pris en charge par

les routeurs, mais une machine serveur peut être cependant configurée comme agent relai DHCP.

Dans les deux types de cas, il suffira de lui spécifier l'adresse du/des serveurs DHCP pour lequel les

demandes des clients DHCP seront relayées. Sous Linux, le daemon prenant en charge cette

fonctionnalité est « dhcp3-relay ».

Pour notre client Aristote, nous utiliserons la fonctionnalité relai DHCP des routeurs qui de nos

jours, intègrent dans la majorité des cas la fonction de relai DHCP. Nous utiliserons cette

fonctionnalité sur chaque site afin de relayer les requêtes clientes qui n’appartiennent pas au même

Vlan que celui affecté au(x) serveur(s). Malgré la non utilisation d’une solution Linux pour cette

fonctionnalité, une procédure de mise en place d’un relai DHCP sous ce système est proposé en

annexe.

2. La haute disponibilité et la répartition de charge

Depuis la version 3, le service dhcpd de l’ISC supporte l'algorithme de partage de charge

conformément à la RFC 3074 (DHC Load Balancing Algorithm). Cet algorithme permet :

à plusieurs serveurs DHCP de répartir les adresses IP en fonction d'une stratégie de

distribution

de mettre en place une stratégie de haute disponibilité

Par défaut, la technique pour assurer un partage de charge équitable repose sur un algorithme

permettant aux serveurs DHCP d'allouer une adresse en fonction de la parité de l'adresse MAC du

client. En effet, le premier serveur allouera une adresse IP si le résultat du hashing de l'adresse est

pair, l'autre le fera si le résultat est impair. Les deux serveurs communiquent entre eux par le biais

d’un canal nommé « failover channel ». Ces échanges servent principalement à :

informer des octrois de bail

s’assurer du bon fonctionnement de chaque serveur

se répartir les plages d’adresses pouvant être alloués

Si un serveur DHCP est en panne, le serveur qui reste opérationnel est averti de la défection de

son pair et stoppe l'algorithme de partage de charge, il répondra donc à toutes les requêtes clientes.

Une fois le serveur DHCP de nouveau disponible, le canal de communication entre les deux serveurs

est rétablit, chacun active son algorithme de répartition et le partage de charge des adresses reprend

son court.



1. Mise en place de la haute disponibilité et de la répartition de charge

Le déploiement de cette fonctionnalité s’effectue au niveau des fichiers dhcpd.conf en

déclarant l’affectation du serveur maître et esclave, avec leurs adresses IP ainsi que leurs ports

d’écoute pour le canal failover (port N° 647 par défaut). Ci-joint en annexe la configuration du canal

failover du site d’Orsay :

3. La mise à jour dynamique des entrées DNS

Cette fonctionnalité permet aux ordinateurs clients DNS d'enregistrer et de mettre à jour

dynamiquement leurs enregistrements de ressource sur un serveur DNS chaque fois qu'un

changement se produit. Ainsi dès qu’une machine obtient une adresse IP via DHCP, un nom d’hôte lui

est automatiquement attribué en fonction de son nom de machine. Les mises à jour dynamiques du

DNS peuvent servir en de nombreuses occasions. Par exemple lors d’un premier adressage sur le

réseau, ou bien encore lors d’un changement d’adresse IP après une demande de renouvellement de

bail ayant échoué, et encore même si l’hôte change de sous réseau (s’il passe d’un réseau filaire à un

réseau wifi).

Les détails de mise en place de cette fonctionnalité sont détaillés en annexe.



6. Intégration du service dans le système d’information

La distribution qui est imposée aux serveurs sera basée sur un noyau de type Debian, il aurait

été possible d’intégrer un seul serveur. Mais en prenant en compte des facteurs essentiels tel que la

disponibilité et en prenant en compte l’impact de la perte de ce service, nous proposons de mettre

en place au moins un serveur DHCP par site. Seul le site d’Orsay aura deux serveurs DHCP parce qu’il

contient une quantité d’utilisateur relativement importante et que par conséquent, il est le point

névralgique de notre infrastructure. Il sera donc question de mettre en place un canal failover pour

chaque site.

Sachant qu’un serveur DHCP peut être composé de plusieurs canaux failover, nous proposons

également de mettre en place une solution qui, pour un serveur DHCP donné, intégrera des

inclusions de configurations DHCP qui correspondra à chaque site. Typiquement, le fichier

dhcpd.conf comportera tout les paramètres concernant son serveur, ensuite nous inclurons les

configurations DHCP spécifiques à chaque site dans celui-ci.

Le tableau ci-dessous présente la configuration des canaux failover pour chaque site :

Site Nom du canal failover Serveur composant le canal Nom du fichier d’inclusion

Orsay dhcp-failover-orsay ORS-SRV-DHCP1 ORS-SRV-DHCP2

dhcpd.master.orsay

Bayonne dhcp-failover-bayonne BAY-SRV-DHCP ORS-SRV-DHCP1

dhcpd.master.bayonne

Sophia Antipolis

dhcp-failover-sophia SOP-SRV-DHCP ORS-SRV-DHCP2

dhcpd.master.sophia

Bruxelles dhcp-failover-bruxelles BRU-SRV-DHCP ORS-SRV-DHCP1

dhcpd.master.bruxelles

Dans une configuration de haute disponibilité, il faut que la paire de serveur DHCP qui compose le

canal failover ait les mêmes configurations au niveau des déclarations qu’ils ont en commun. Si ce

n’est pas le cas, le canal failover ne sera pas actif.

Afin de pallier à ce problème, nous pouvons mettre en place un script qui automatisera le

déploiement du fichier de configuration propre à un site sur l’hôte distant qui compose la paire.

if /etc/init.d/dhcp3-server restart #si le redémarrage du daemon où l’on a effectué les

modifications c’est bien déroulé, alors on peu déployer le fichier sur l’autre serveur

then

scp /etc/dhcp3/dhcpd.master.orsay [email protected]:/etc/dhcp3/ #on copie via la commande scp

vers le serveur distant

ssh [email protected] '/etc/init.d/dhcp3-server restart' #on redémarre le serveur distant

else #si le redémarrage du daemon où l’on a effectué les modifications a échoué, alors on

affiche une erreur

echo "Erreur!!! Le fichier de configuration comporte des erreurs. Veuillez regarder le

fichier dhcpd.log"

fi

mailto:[email protected]:/etc/dhcp3/



En ce qui concerne les options de configuration, il convient de mettre en place les informations

de base et nécessaire à tout bon fonctionnement dans une architecture informatique d’entreprise. Le

tableau ci-dessous récapitule tout les paramètres que l’on a besoin pour le bon fonctionnement de

chaque site, à savoir les paramètres du routeur et des serveurs DNS employés.

Site Passerelle (X pour chaque sous-réseau)

DNS (par ordre de préférence) Plage d’adressage dynamique

Orsay 172.16.X.254 172.16.0.5 ; 172.16.0.6 ; 172.17.0.5 ; 172.18.0.5 ; 172.19.0.5 ;

172.16.X.50 à 172.16.X.200

Orsay : Réseau Itinérant

172.20.X.254 172.20.X.50 à 172.20.X.200

Bayonne 172.17.X.254 172.17.0.5 ; 172.16.0.5 ; 172.16.0.6 ; 172.18.0.5 ; 172.19.0.5 ;

172.17.X.50 à 172.17.X.200

Sophia Antipolis

172.18.X.254 172.18.0.5 ; 172.16.0.5 ; 172.16.0.6 ; 172.17.0.5 ; 172.19.0.5 ;

172.18.X.50 à 172.18.X.200

Bruxelles 172.19.X.254 172.19.0.5 ; 172.16.0.5 ; 172.16.0.6 ; 172.17.0.5 ; 172.18.0.5 ;

172.19.X.50 à 172.19.X.200

1. Définition des paramètres communs à mettre en place pour Aristote

Ces paramètres seront mis en place dans les fichiers dhcpd.conf de tous les serveurs.

Paramètre Valeur Commentaire

option domain-name "vsn-aristote.lan" Définit le suffixe DNS à utiliser ping-check 1 Permet d’éviter des conflits d’adressage

default-lease-time 86400 Définition du temps d’un bail par défaut à 1 journée

max-lease-time 432000 Définition du temps d’un bail par défaut à 5 journées

authoritative Serveur faisant autorité sur le segment log-facility local7 indique un fichier de log de niveau debug

ddns-domainname "vsn-aristote.lan" zone de nom sur lequel DHCP effectuera les mises à jour

ddns-update-style interim Choix de l’algorithme de mise à jour du DNS ddns-updates on Mise à jour autorisée

ignore client-updates MAJ par le dhcp et non par le client update-static-leases on on MAJ des statiques DHCP allow-unknow-clients Autoriser les clients inconnus au niveau de

l'adresse MAC

2. Relais DHCP

Comme mentionné dans l’étude des fonctionnalités avancée de DHPC, il est bon de rappeler

que le relai DHCP est intégré sur les routeurs de chaque site. Chaque relai fera suivre les requêtes

DHCP aux serveurs composant la grappe failover d’un site.



3. Schéma de l’architecture DHCP à mettre en place

Figure 5 - Architecture DHCP

7. Les pré-requis et coûts de la solution

1. Les pré-requis

DHCPd ne requiert seulement comme pré-requis :

- Un noyau linux intégrant le module prenant en charge le protocole 802.1q pour les relais DHCP

- Disposer des droits d'administration sur le serveur

- Connaître les bases fondamentales de TCP/IP (adressage, sous-réseaux, etc.)

2. Coûts de déploiement

La mise en place de la solution, l’application d’une batterie de tests ainsi que sa validation

représente un coût humain de 10 heures/homme par serveur DHCP, 4 heures/homme par serveur

relai DHCP soit un total de 66 heures/homme que nous allons arrondir à 68, soit 8,5 jours ouvrés.

Les serveurs, au nombre de 5, peuvent parfaitement être virtualisé par site, ce que nous

conseillons bien évidement pour des raisons de coûts matériel.

3. Coûts lié à l’administration

L’intégration des postes clients Linux représentera un coût d’administration, tout comme la

gestion des serveurs DHCP où les fichiers de configurations peuvent être modifiés. Nous estimons

cette charge de travail à 1 jour ouvré par semaine.


Résolution de noms IP (Rudy Promé) 25

4. Résolution de noms IP (Rudy Promé)


Avant de démarrer l’étude, il est nécessaire de rappeler les besoins de notre client Aristote afin que

les propositions des outils et logiciels à mettre en œuvre soient cohérentes.

Dans cette partie, il s’agit donc de prévoir une organisation centralisée de la résolution des noms de

machines du site. Il faudra être en mesure d’assurer une haute disponibilité à ce rôle car, sans lui, la

communication entre les machines clientes et serveurs de l’infrastructure serait impossible.

2. Solution que nous proposons

Dans le monde Unix, on distingue plusieurs solutions libres et gratuites pour tout type de services

réseaux. Dans notre étude, nous nous intéressons plus particulièrement à ces solutions gratuites afin

de réduire les coûts de la mise en place de l’infrastructure de notre client.

1. Bind9

Concernant le service de résolution de noms IP, nous retiendrons Bind9 permettant une multitude de

fonctions qui une fois bien configurée, allège considérablement le travail de l’administrateur dans le

temps :

Il est capable de fonctionner de façon autonome et dynamique, ce qui permettra d’ajouter automatiquement les clients utilisant ce serveur dans la base DNS, au lieu d’ajouter les 800 clients (1000 à venir) d’Aristote manuellement

Afin d’assurer une continuité d’activité, les serveurs Bind9 peuvent communiquer entre eux pour mettre à jour leur base DNS dynamiquement et fonctionner par principe de « Maître-Esclave ». En cas de crash du serveur Maître, les serveurs Esclaves sont alors présents pour prendre le relais, il n’y a donc ainsi aucune interruption d’activité et tout est entièrement transparent pour les utilisateurs

Suite à notre expérience lors de la précédente étude (concernant l’infrastructure de messagerie), nous avons utilisé le service DNS Bind9 qui était largement à la hauteur de nos espérances en matière de montée en charge. Les différents serveurs que nous allons implémenter pourront gérer sans peine les requêtes de tous les utilisateurs d’Aristote

2. Le nom de domaine

Comme indiqué dans le cahier des charges, la nom de domaine de notre client devra correspondre à

« vsn-aristote ». Pour se faire, nous utiliserons deux suffixes :

.lan : pour tout le réseau interne d’Aristote

.eu : pour sa visibilité depuis l’extérieur

L’utilisation de ces deux suffixes nous permettra de dissocier très simplement ce qui sera donc

accessible depuis l’extérieur et l’intérieur.



3. Implémentation de Bind9 (Serveur Maître)

1. Installation

Son installation est relativement simple en recourant aux binaires (à l’aide de la commande apt-get

install). Mais on peut également procéder à une installation par compilation qui pourra correspondre

plus spécifiquement à la machine afin de rendre le serveur plus performant. Mais ceci nécessite des

connaissances en Linux un peu plus expérimentées.

2. Configuration

Une fois le serveur installé, il faut le configurer en créant son fichier de zone et en lui indiquant qu’il

est le serveur Maître. Pour voir la procédure plus en détails, référez-vous à l’annexe Configuration

Bind9 serveur Maître.

3. Les enregistrements dynamiques

Il faut ensuite le rendre dynamique pour que les postes clients d’Aristote s’enregistrent

automatiquement dans la base DNS. Il y a deux méthodes pour les enregistrer automatiquement :

la première consiste à effectuer l’enregistrement lorsque les postes eux-mêmes interrogent le serveur DNS

la seconde consiste à effectuer les enregistrements par le serveur DHCP au moment où celui-ci distribue les adresses IP des postes clients

C’est la seconde méthode que nous utiliserons car l’inconvénient principal de la première méthode

est que si un poste A tente de communiquer avec un poste B alors que le B n’a pas interroger le

serveur DNS (et n’est donc pas enregistré), il sera impossible d’effectuer un échange quelconque

entre les deux postes.

Pour paramétrer cette fonction, il est nécessaire d’indiquer dans un premier temps au serveur DHCP

qu’il doit envoyer aux serveurs DNS. Dans le fichier /etc/dhcp3/dhcpd.conf, il faut préciser le nom de

domaine utilisé et qui est le serveur DNS de la zone. Lors de la distribution des adresses, après avoir

reçu le paquet DHCPREQUEST du poste client et avant de lui transmettre le DHCPACK, il met à jour le

serveur DNS en ajoutant un enregistrement A (hôte). Enfin, si le poste client demande une

réattribution de son adresse IP avec un message DHCPRELEASE pour annuler le bail de son adresse, le

serveur DHCP supprime de la base DNS les enregistrements concernés.

Dans un second temps, il faut informer le serveur Bind9 qu’il doit autoriser le serveur DHCP à

effectuer des mises à jour dans sa base DNS. Pour ceci, il faut ajouter la variable « allow-update {

172.16.0.3 ; } ; »1 dans le fichier /etc/bind/named.conf dans l’arborescence créée pour le domaine

« vsn-aristote.lan ».

Après redémarrage des services DHCP et DNS, la mise à jour dynamique est fonctionnelle.

1 Commande pour autoriser les mises à jours de la base DNS depuis 172.16.0.3 qui est le serveur DHCP 1 d’Orsay



4. Implémentation des serveurs Esclaves

1. Haute disponibilité pour le siège

Le site d’Orsay étant le siège de notre client, il est nécessaire d’assurer de la haute disponibilité pour

le service de résolution de noms IP. C’est pourquoi sur ce site, nous allons mettre en place un

deuxième serveur Bind9, mais celui-ci sera configuré en Esclave.

Pour voir la procédure de configuration en détails, référez-vous à l’annexe Configuration Bind9

serveur Esclave.

2. Les sites distants

Les trois serveurs distants sont un peu particuliers. Ils seront serveurs Esclaves tout comme le

serveur secondaire situé à Orsay. Mais ils assureront les requêtes de leur site respectif. Pour ceci, le

serveur DHCP de chaque site distant devra se référer au bon serveur DNS. Ainsi, les postes clients de

chaque site utiliseront leur serveur DNS attitré pour résoudre les requêtes. Ces serveurs seront donc

Esclaves d’Orsay mais « Maîtres » de leur site.

Nous ne reviendrons pas en détails sur leur configuration car elle est exactement la même que celle

du serveur Esclave d’Orsay. Pour rappel, il faudra donc leur renseigner leur rôle d’Esclave, leur

serveur Maître, la zone vsn-aristote.lan et la fonction de notifications.

Du côté du Maître, on ajoute les trois serveurs dans les enregistrements de vsn-aristote.lan.hosts et

d’ajouter leur adresse IP à l’option d’autorisation de transfert de zone.

3. Les postes clients

Les configurations DNS des clients délivrées par le serveur DHCP sera différente selon le site où ils

situent. Voici un tableau récapitulatif :

Clients des sites Orsay Bayonne Sophia Antipolis Bruxelles

DNS Primaire 172.16.0.5 172.17.0.5 172.18.0.5 172.19.0.5

DNS Secondaire 172.16.0.6 172.16.0.5 172.16.0.5 172.16.0.5

Sur le site d’Orsay, en cas de non réponse du serveur Maître, les clients seront donc aptes à

interroger le serveur secondaire d’Orsay.

Sur les sites distants, en cas d’impossibilité de résoudre les requêtes qui leurs sont attribuées, elles

seront automatiquement renvoyées vers le serveur Maître via le réseau MPLS.



5. Supervision des serveurs

A l’aide d’un serveur de supervision tel que Nagios (que nous implémentons également dans

l’infrastructure de notre client), nous pouvons surveiller en temps réel l’état de nos serveurs DNS. En

cas de détection d’anomalies de l’un de nos serveurs, nous pouvons être automatique averti par

mails afin de procéder au plus vite à la résolution de celles-ci.

La supervision via Nagios est plus détaillée dans la suite de notre étude, dans la partie qui lui est

concernée.

De plus, nous pouvons consulter l’historique des évènements des serveurs en se référant à leur

fichier de journalisation, situé dans /var/log/syslog. Je recommande d’utiliser les commandes

suivantes afin de filtrer les informations qui nous intéressent dans le fichier de journalisation :

- more /var/log/syslog | grep bind -> afin d’afficher toutes les informations sur Bind9 - tail -50 /var/log/syslog -> afin d’afficher les 50 dernières lignes du fichier « syslog »

Vous pouvez également vous référez à l’annexe « Phases de tests DNS » pour une liste de

commandes permettant de tester le bon fonctionnement des serveurs Bind9.

6. Schéma physique de l’architecture DNS

Comme cité précédemment,

Aristote comptera donc 5

serveurs DNS :

1 serveur Maître situé sur le site

d’Orsay qui se chargera de

résoudre toutes les requêtes à

Orsay

4 serveurs Esclaves, soit un sur

chaque site. Le serveur Esclave

d’Orsay qui aura pour tâche de

prendre le relais du serveur

Maître en cas d’incident ou de

surcharge de travail et les 3

serveurs Esclaves des sites

distants qui résoudront les

requêtes de leur site

correspondant

Figure 6 : Schéma infrastructure DNS



7. Coûts

Etant donné qu’il s’agit d’une solution entièrement gratuite sur le plan logiciel, il s’agira alors

uniquement de coûts matériels et humains.

1. Coûts matériels

Il est fortement recommandé de mettre le serveur Maître d’Orsay sur une machine physique car

c’est le serveur qui traitera le plus de requêtes DNS. Il est donc impératif que ses cartes réseaux ne

soient pas également utilisées par un autre serveur afin de pouvoir assurer les charges réseaux les

plus élevées possibles.

Quant à tous les autres serveurs, les serveurs dits Esclaves, ils seront installés sur des plateformes de

virtualisation avec d’autres serveurs afin de minimiser les coûts matériels..

Nous aurons donc besoin d’un serveur HP ProLiant DL120 à 1350 € hors taxes.

2. Coûts humains

Le site d’Orsay disposant du serveur DNS Maître devra-être administré par au minimum deux

administrateurs Linux. Les trois sites distants quant à eux pourront être assuré par un seul

administrateur Linux par site.

Orsay Bayonne Sophia Antipolis

Bruxelles Total

Nombre d’utilisateurs (avant l’évolution de 20 %)

400 180 80 160 820

Nombre de serveurs DNS 2 1 1 1 5

Nombre d’administrateurs 2 1 1 1 6

Le coût d’un administrateur est évalué à 2000 € brut mensuel. Le total des coûts humains s’élève

donc à 12 000 € brut mensuel. Donc 144 000 € par an.

3. Conclusion

L’infrastructure DNS en environnement Linux de notre client Aristote reviendra donc à un coût total

d’environ 145 000 € hors taxes par an. Pour rappel, le coût inclut la mise en place de l’infrastructure

ainsi que son administration.

8. Maquette

A contrario de ce que nous avons cité dans l’étude de l’architecture DNS, pour des raisons

matérielles, les serveurs DNS seront installés sur les mêmes machines que les serveurs DHCP lors de

la phase de maquettage et de la rédaction de notre cahier de recette.

De plus, étant donné que nous ne maquettons pas le site d’Orsay, nous ne pourrons vous présenter

le Cluster DNS d’Orsay. Il sera donc présenté d’une façon similaire mais entre les deux sites distants,

à savoir Bayonne et Bruxelles. Bayonne aura pour rôle serveur Maître et Bruxelles, serveur Esclave.


Le serveur de ressources (Jérôme Delahaie) 30

5. Le serveur de ressources (Jérôme Delahaie)

1. Rappel du besoin :

Mettre à disposition de chaque service un espace partagé. Cet espace doit permettre aux utilisateurs

de ces services d’accéder à trois espaces :

Informations modifiables que par les rédacteurs

Travail collaboratif

Logiciels partagés

Deux fonctionnalités peuvent-être implémentées :

Interopérabilité avec le système Windows, sans utiliser le logiciel Samba

Une gestion dynamique du service afin d’optimiser la bande passante

2. Solutions existantes :

Pour répondre à ce besoin, plusieurs solutions peuvent être envisagées.

1. L’appliance matérielle :

Cette solution peut nous être fournie par beaucoup de sociétés, les meilleures sur le marché sont

NetApp (leader mondial) et EMC². Le principal avantage de cette solution est qu’elle comprend un

support complet (matériel/logiciel) et garanti par contrat. Elle permet de réaliser tous les besoins du

client.

2. L’appliance logicielle :

Cette solution permet d’avoir un système clé en main et facilement administrable. Les solutions

présentes sur le marché sont OpenFilter, FreeNAS et CryptoNAS. OpenFilter permet de profiter d’un

support garanti par contrat mais qui se limite à la partie logiciel et sans prendre en charge la partie

matérielle. FreeNAS et CryptoNAS sont des distributions orientées NAS. La première est basée sur

FreeBSD et la deuxième sur Debian. Ces distributions permettent de profiter d’une interface

spécialisée afin de gérer le NAS, aussi bien la gestion des filesystems que des droits. Le principal point

noir concernant ces distributions réside dans le fait qu’elles utilisent toutes le logiciel Samba. On peut

donc se poser des questions sur la pérennité de telles solutions.

De plus, la mutualisation des serveurs est difficile avec ces distributions, l’ajout de services étant

périlleux.

3. Serveur Linux ou Unix

Cette solution est en fait l’ajout du service « serveur NFS » sur un serveur Linux ou Unix. Tout comme

la solution précédente, cette solution nécessite l’achat d’un serveur, l’installation du système, la mise

en place du service et son intégration dans l’environnement. Cette solution permet de pouvoir

répondre au cahier des charges avec un partage de type NFS et de se libérer de la contrainte Samba.

Le système permet de pouvoir mutualiser d’autres services.



4. Solution retenue

Nous allons retenir la troisième solution, c’est la solution qui nous donne le plus de flexibilité par

rapport aux différents besoins de notre client. Toutefois, si le besoin en volumétrie est supérieur à

20Tio, nous vous recommandons l’utilisation d’une appliance matérielle.

3. Architecture proposée

1. Besoins par sites

Aristote dispose de quatre sites distants, où quasiment toutes les directions sont représentées. Le

tableau suivant récapitule les données dont nous disposons sur les machines présentes.

Orsay effectif %age/site %age global Bayonne effectif %age/site %age global

générale 40 10,00% 66,67% 4 2,22% 6,67%

administrative 30 7,50% 66,67% 10 5,56% 22,22%

commerciale 70 17,50% 60,87% 16 8,89% 13,91%

études 255 63,75% 78,46% 20 11,11% 6,15%

production 5 1,25% 1,89% 120 66,67% 45,28%

total 400

180

Sophia-Antipolis Bruxelles

générale 1 1,25% 1,67% 15 9,38% 25,00%

administrative 0 0,00% 0,00% 5 3,13% 11,11%

commerciale 4 5,00% 3,48% 25 15,63% 21,74%

études 10 12,50% 3,08% 40 25,00% 12,31%

production 65 81,25% 24,53% 75 46,88% 28,30%

total 80

160

On constate que la moitié des utilisateurs se trouve sur le site d’Orsay. C’est donc le lieu sur lequel le

besoin doit être le plus grand.

Nous ne disposons d’aucune donnée sur la volumétrie existante, le profil I/O ou les systèmes de

fichier à supporter. Afin de palier à ce manque d’information, cette étude se basera sur un profil I/O

standard : 1 000% de charge à 9h et 18h à la (dé)connexion de tout le monde 30% en journée et 0%

la nuit.

2. Analyse de l’usage

Avant toute chose, il faut savoir que les performances d’un serveur de fichier sont principalement

impactées par :

Le réseau

Les I/O que peuvent fournir les disques



Charge serveur

Sur ce serveur de fichier, nous ciblons principalement deux usages :

Espace partagé par direction (besoin du client)

Stockage des répertoires personnels des utilisateurs

Le premier usage est un usage régulier sur toute la journée, les utilisateurs consultant et utilisant les

documents de manière aléatoire.

Le deuxième usage est un peu plus complexe. Il y a en effet deux grosses périodes de très forte

charge, qui sont :

le matin à la connexion des utilisateurs

le soir lorsqu’ils partent.

Il faut donc prévoir ces montées en charge dans le design de notre solution.

Trafic réseau et optimisation

La manipulation de fichiers sur le serveur génère un trafic réseau important en nombre de paquets.

La MTU d’un réseau Ethernet étant de 1500 octets, le transfert d’un fichier de 1Mo sur le serveur va

générer un trafic de l’ordre de 700 paquets.

Lors de la partie MIR Réseau, nous avions une contrainte qui était d’avoir un réseau Ethernet gigabit.

Le réseau Ethernet gigabits ne peut pas être exploité pleinement avec un MTU de 1500 octets.

L’utilisation de jumbo frames autorise un MTU de 9000 octets, et permet d’exploiter pleinement un

réseau Ethernet gigabit. En reprenant le même exemple, notre fichier de 1Mo ne générera plus qu’un

trafic de l’ordre de 120 paquets. Le bémol de cette solution réside dans l’obligation d’avoir

l’intégralité de l’équipement réseau en Ethernet gigabit.

Charge disque

Un disque SCSI standard fournit une performance de l’ordre de 120 IOPS. Pour simplifier le

dimensionnement du serveur, on calcule le nombre d’IOPS en prenant pour base un IOPS par

utilisateur. Sur Orsay, qui est le site où l’on compte le plus d’utilisateurs, on a actuellement 400

utilisateurs, il faut donc au minimum un RAID composé de 5 disques. En prévoyant l’augmentation de

20% sur 5 ans, il nous faut au minimum 6 disques. Si on opte pour du RAID 5, il faut compter un

disque de plus pour la parité. Si on veut une tolérance de panne de 2 disques, on peut ajouter un

disque spare, qui sera utilisé automatiquement en cas de défaillance d’un disque.



3. Solutions face aux contraintes :

Solution pour la contrainte réseau

L’utilisation des jumbos frames est une solution qui est envisageable car le réseau est en Ethernet

gigabit. Nous ne la retenons pas car l’utilisation du serveur ne le justifie pas, mais c’est une évolution

qui pourrait être mise en place si le besoin s’en fait sentir.

L’autre solution pour améliorer la partie réseau est l’adoption d’un cluster NFS. Ce mode pourrait

permettre de répartir la charge lors des pics d’utilisation, et ainsi doubler la bande passante. Et lors

du fonctionnement normal, un seul serveur serait sollicité. Cette solution permet donc de fournir le

service même lors de montée en charge et d’offrir une gestion dynamique de la bande passante.

Le cluster sera assuré par le logiciel Heartbeat et la répartition de charge par le load balancer utilisé

par le cluster LDAP.

Solution pour la contrainte disque

La solution consiste à utiliser plusieurs disques, afin de combiner leurs capacités pour atteindre le

seuil d’I/O nécessaire. Le serveur va pour ce faire bénéficier de disques utilisés en RAID par un

contrôleur matériel.

D’un point de vue logiciel, les disques seront gérés par la couche LVM. Cette solution permet de

pouvoir ajouter très simplement de la volumétrie. LVM organise les disques (PV : physical Volume) en

Volume Group (VG). Ce VG s’utilise avec des LV (Logical Volume).

Figure 7 - Schéma de synthèse LVM

Ces LV sont redimensionnables et il n’y a pas les limitations dû aux types de partition. Ici le VG ne

contiendra que le volume RAID. LVM permet également de faire des snapshots, une fonction

intéressante pour la sauvegarde.



Les différents partages seront regroupés par direction au sein d’un lv. Cette solution permet de

pouvoir étendre à chaud la volumétrie allouée à une direction.

Nous proposons d’utiliser le système de fichier GFS2, car il prend en charge correctement la

problématique de l’accès concurrent.

Gestion des droits et client

Les droits d’accès seront gérés par le biais du service NSS et de son module LDAP.

Le client nfs sera le paquet Debian standard, et afin d’avoir plus de transparence pour l’utilisateur, les

répertoires seront montés par le biais de l’outils autofs dès le login et démontés après la

déconnexion. (cf annexes Répertoires utilisateurs)

Solution pour l’interopérabilité avec Windows

La version 4 du service NFS permet l’interopérabilité des droits POSIX avec les droits Windows. Cela

va permettre de simplifier la traduction des droits en l’un ou l’autre des systèmes.

Aristote nous fait part de ses réserves quant à la pérennité du logiciel Samba, nous devons donc nous

tourner vers d’autres solutions. La solution que nous avons retenue est l’installation de Microsoft

Subsystem for Unix-based Applications (SUA). Cette solution, dont les premières versions datent de

1999, permet à Windows d’être client NFS. Actuellement, SUA supporte NFS version 4.

Répartition des serveurs

Nous proposons de mettre en place un serveur de fichier par site à l’exception du le site d’Orsay où

nous proposons un cluster de serveur de fichier. Toutes les données seront répliquées sur Orsay afin

de permettre aux personnes de continuer à travailler si l’un des serveurs vient à tomber en panne. Le

cluster sur le site d’Orsay permet de grandement réduire les risques de dysfonctionnement du

service.

4. Coûts

Nous proposons la configuration présentée en annexe pour tous les sites. Sur Orsay, cette

configuration sera doublée, pour chacun des nœuds du cluster. Avec cette configuration, le volume

maximal de donnée utile pouvant être stocké est 3,6Tio.

Item quantité prix unitaire prix total

M610 6 1 494,00 € 8 964,00 €

MD1220 6 9 175,00 € 55 050,00 €

Total 64 014,00 €

Tableau récapitulatif des coûts


Système de sauvegarde (Arnaud Hamon) 35

6. Système de sauvegarde (Arnaud Hamon)


L’objectif de cette partie consiste à prévoir une sauvegarde des répertoires /home des

utilisateurs des 3 sites. Chaque service doit disposer sur le serveur de sauvegarde d’un espace par

service et par machine. LA sauvegarde doit être automatisée pour chaque soir à partir de 1h du

matin.

- Option 1 : Gestion de l taille et dulieu de stockage sur une année d’exercice.

- Option 2 : Gestion de l’archivage et du temps de restauration sur une année d’exercice.

2. Comparatif

L’objectif est de déterminer la solution qui répond le mieux aux besoins du client. Le choix de

cette solution est basé sur des solutions reconnus par leur utilisation.

Les solutions proposées :

- Rsync

- Backup-manager

- Backuppc

Un tableau comparatif a été mis en place pour recouper les besoins client avec les fonctionnalités

des solutions.

Tableau comparatif

Besoins du client Rdiff-backup Backup-manager Backuppc

Sauvegardes de répertoires

OUI OUI OUI

Sauvegardes multi-sites

OUI OUI OUI

Sauvegardes automatisées

NON OUI OUI

Différents types de sauvegardes

NON OUI OUI

Restauration OUI OUI OUI Multiples OS NON NON OUI



3. Solution retenue

Dans l’étude du système de sauvegarde, Backuppc est la solution qui a été conseillée. Cette

solution est la plus complète et ouvre des possibilités sur la mise en place de sauvegardes des

configurations de chaque serveur, de données autres que les /home des utilisateurs.

1. Architecture de fonctionnement

Voici le schéma de fonctionnement de la solution.

VPN-MPLS Internet

LAN

use

rs

LAN server

Backup

Serv

eur

de

bac

kup

OR

S-SR

V-B

AC

KU

P -

17

2.1

6.0

.9/2

4NAS Netgear

Cluster Files

Clu

ster

de

serv

eurs

de

fich

iers

- L

oad

Bal

ance

rO

RS-

SRV

-FIL

ES1

- 1

72

.16

.0.7

/24

OR

S-SR

V-F

ILES

2 -

17

2.1

6.0

.8/2

4V

IP -

17

2.1

6.0

.10

2/2

4H

A –

19

2.1

68

.0.1

,2/2

4

Figure 8 - Implémentation serveur de backup

Rappelons que l’objectif est de sauvegarder des répertoires /home des utilisateurs.



Tout d’abord, le serveur de sauvegarde n’a aucun impact sur le bon fonctionnement de la

production du client, c’est pourquoi un cluster de serveur de sauvegarde ne sera pas utile dans cette

optique de sauvegarde de données en cas de pertes de celles-ci. En cas de perte du serveur de

sauvegarde, il n’y aura aucun impact sur la production du client Aristote. Un seul serveur sera mis en

place afin de gérer les sauvegardes qui sera situé sur le site de Orsay.

Caractéristique technique du serveur mis en place

CPU Mémoire Physique Mémoire Virtuelle (SWAP)

Espace disque

Core 2 Duo 2Ghz 4Go 2Go 50Go

Ceci est la configuration recommandée pour le fonctionnement du serveur de sauvegarde.

Ensuite, afin d’assurer la remise en fonctionnement en cas de crash du serveur, un ghost sera

réalisé afin de rétablir la machine. Seulement, il faut penser aux différentes mises à jour des

configurations de sauvegarde, d’où l’importance de mettre en place une sauvegarde de celle-ci.

Finissons avec l’élément important de cette infrastructure, le NAS. Le choix de stockage sur

un NAS est stratégique. Premièrement, une amélioration à la tolérance de panne grâce à 4 disques

utilisés en RAID5 et donc un intégrité des données en cas de perte d’un des disques. Deuxièmement,

les performances d’un NAS en RAID5 sont bien adaptées aux besoins en termes de vitesse

d’écriture/lecture par la répartition de charges. (Voir le chapitre Espace de stockage pour les

informations concernant l’espace disque du NAS). Grâce à l’outil de supervision qui sera mis en place

(Voir partie 8 option 1), une supervision de services de sauvegarde et de l’état des disques du NAS

pourra être mis en place.

2. Backkuppc

Backuppc est un logiciel permettant de sauvegarder un parc de serveurs ou de postes client.

Il est muni d’une interface web afin de faciliter son utilisation et de paramétrer les différents

sauvegardes et faire des restaurations en cas de besoin. Il permet principalement de mettre en place

des sauvegardes automatisées de répertoires de serveurs ou poste client de manière régulière.

Backuppc peut utiliser différents protocole:

- Samba - rSync - rSyncd - Tar

Les répertoires étant centralisés sur un serveur Linux, on utilisera rSync afin de les sauvegarder.



3. Gestion de la taille du lieu de sauvegarde

Type de sauvegarde

La taille des sauvegardes varie en fonction du type de sauvegarde réalisé. Backuppc utilise 2

types de sauvegardes :

- Les sauvegardes complètes : Elle permet de sauvegarder l’intégralité des données. C’est

la sauvegarde la plus simple et la plus rapide à restaurer. Seulement, elle est très

gourmande en ressource (réseaux), et demande énormément d’espace de stockage.

- Les sauvegardes incrémentielles : Elle permet de sauvegarder uniquement les données

modifiées depuis la dernière sauvegarde incrémentielle ou complète. Moins gourmande

en ressources et espace disque, il est par contre moins facile de réaliser une restauration

d’un sauvegarde incrémentielle car il faut pour cela, restaurer la dernière sauvegarde

complète et toute les incrémentielle depuis celle que l’on veut restaurer.

Pour répondre aux besoins de sauvegarde journalière, nous allons utiliser les 2 types de

sauvegardes afin de réaliser toutes les sauvegardes en réduisant au maximum l’utilisation d’espace

disque. De plus, Backuppc gère très bien la restauration des sauvegardes incrémentielles et cela est

totalement transparent.

Espace de stockage

Afin de répondre aux besoins de sauvegarde des /home de différents utilisateurs, il va falloir

étudier la quantité d’espace nécessaire afin de pouvoir stocker l’ensemble des données et prévoir

une augmentation du nombre d’utilisateur de 20% en 5 ans.

Nous allouerons 500 Mo par utilisateur. Nous prendrons comme référence 820

collaborateurs. Sachant que pour la plupart des utilisateurs, ils n’utiliserons pas la totalité des 500

Mo et qu’ils ne modifieront pas la totalité des 500Mo de fichiers sur leur répertoire, on allouera 1Go

par personne de sauvegarde.

Nombre d’utilisateurs Espace alloué Espace alloué pour la sauvegarde

820 410Go 820Go 820 +20%=984 On arrondit à 1000

500Go 1000Go

On aura donc besoin de mettre en place un serveur NAS de 1 To afin de réaliser les

sauvegardes. On utilisera le modèle suivant : Netgear ReadyNas3100 8TB Network Storage System. Il

peut lui mettre jusqu’à 8 TB d’espace disques. Pour des questions technologique, on mettra en place

4TB d’espace de disques. Cela permettra de mettre en place d’autres sauvegardes mais aussi que

l’utilisation du RAID5 réduit de manière assez significative l’espace disque utilisable.

Backuppc ne sauvegarde qu’à un seul endroit /var/lib/backuppc. C’est pourquoi le NAS sera

monté sur la Debian et un lien symbolique sera mis en place pour rediriger les sauvegardes

directement sur le NAS.



Méthode de sauvegarde

Comme vu précédemment, Backuppc utilise 2 méthodes de sauvegarde. L’objectif va être

ainsi d’optimiser l’efficacité des sauvegardes tout en réduisant au maximum l’espace utilisé pour les

sauvegardes.

Samedi Dimanche Lundi Mardi Mercredi Jeudi Vendredi

SauvegardeComplète

SauvegardeIncrémentielle






Figure 9 - fonctionnement des sauvegardes

Rappelons que dans le cahier des charges, il est précisé que la sauvegarde doit être automatisée pour

chaque soir à partir de 1H du matin. Nous allons ainsi voir les variables à implémenter dans Backuppc

afin d’y répondre.

Tout d’abord, nous allons réaliser une sauvegarde complète hebdomadaire durant le

weekend. Techniquement, cette sauvegarde peut être réalisé à n’importe quel moment de la

semaine, or les ressources en bande passante sont limités et la volumétrie à sauvegarde peut varier

de quelques giga-octets de données à à des centaines de giga-octets de données ce que pourrait

provoquer des saturations sur le réseau et ainsi des latences sur le réseau. Durant le weekend, il y

aura beaucoup moins de personnes qui risquent d’être perturbés par les sauvegardes et vers 1H du

matin.

$Conf{FullPeriod} = 6.97; Variable configurée afin de réaliser un backup toute les semaines

Ensuite, il faut trouver un compromis entre le temps d’archivage des données et l’espace

nécessaire pour stocker les informations. C’est pourquoi nous recommandons de conserver les

sauvegardes que sur une durée hebdomadaire. Ainsi, l’espace disque nécessaire sera réduit et la

sauvegarde sur une semaine semble correcte face aux besoins des sauvegardes.

$Conf{FullAgeMax} = 9; // Age maxi d’une sauvegarde complète, supprimé au-delà de 9

jours.

$Conf{FullKeepCntMin} = 1; // Garder au minimum une sauvegarde complète, même si elle a

plus de 9 jours. En cas de problème et de non sauvegarde du serveur, il n’y aurait plus de

sauvegardes car elles auraient toutes passées le cap des 9 jours, donc le serveur n’aurait plus du tout

de sauvegarde. Ce qui aurait un impact critique.

Maintenant, nous allons mettre en avant l’efficacité des sauvegardes à partir des

sauvegardes incrémentielles. Pour cela, une sauvegarde incrémentielle journalière sera mise en

place. Cependant, il faut aussi prendre en compte l’archivage des sauvegardes incrémentielles. Vu

que l’archivage se fera sur une semaine, il faut prendre en compte le nombre de sauvegardes

incrémentielles entre chaque sauvegarde complète, qui est de 6 sauvegardes incrémentielles. Pour



garder une marge de manœuvre pour les sauvegardes manuelles, on gardera en archivage les 8

dernières sauvegardes incrémentielles.

$Conf{IncrKeepCnt} = 8; // Garder au minimum 8 sauvegardes incrémentielles

$Conf{IncrKeepCntMin} = 3; // Garder au minimum 8 sauvegardes incrémentielles quelques

soit la date d’archivage pour les mêmes raisons que le paramètre $Conf{FullKeepCntMin}.

.Pour finir, on va programmer le serveur afin qu’il démarre ses actions de sauvegardes à

partir de 1H, grâce au paramètre $Conf{WakeupSchedule}. Ce paramètre permet de renseigner à

quel moment le serveur doit faire ses vérifications pour savoir si il a une action à réaliser ou non.

$Conf{WakeupSchedule} = [1];

4. Gestion du temps de restauration des fichiers

Il est vrai que sauvegarder ses données être très important. Seulement sans restauration les

sauvegardes sont inutiles.

Backuppc proposer 2 méthodes de restauration :

- la restauration directe: à partir de l’interface WEB, on peut directement sélectionner les

données à restaurer et le serveur se charger de les pousser la machine sur lequel il faut

restaurer les données.

- La restauration manuelle : à partir de l’interface WEB, il est possible de télécharger les

données que l’on veut restaurer.

4. Coûts

Software/Hardware Coût

Backuppc Gratuit Serveur 1000€ Netgear ReadyNas3100 8TB Network Storage System

4500€

En ce qui concerne l’intégration, nous estimons à 5 jours/homme la mise solution. Pour l’ensemble des tâches, nous estimons le coût d’administration à 1heure /homme par semaine.


Le serveur web et l'accès internet sécurisé (Bastien Gayral) 41

7. Le serveur web et l'accès internet sécurisé (Bastien

Gayral)


1. Objectif

L’objectif est la mise en place d’un serveur Web et d'un accès Internet sécurisé dans l’entreprise.

Le serveur Web doit offrir :

· un accès public.

· un accès privé réservé au personnel.

L’accès doit autoriser :

· la navigation et la consultation sur le Web,

· les connexions sur le site web de l’entreprise depuis un poste itinérant.

2. Exigences et option

Définir une politique d’accès sécurisé sur Internet.

Etudier et mettre en place les fonctions associées à la politique définie.

Option1: Un outil de statistiques réseaux est consultable en intranet. Il s'agit d'analyser en autre la

charge de bande passante à l'aide de simulations et de mesures.

Option2: L'authentification est homogénéisée à celle d'Unix ou est centralisée par un annuaire.

Option3: Un proxy-cache annexe est envisagé.

Option4: Un firewall autorisant uniquement les ports ftp(gestion du mode passif), ssh, http, https est

envisagé



2. Serveur Web

1. Présentation

Un serveur Web, est un logiciel servant des requêtes respectant le protocole de communication client-

serveur Hypertext Transfer Protocol (HTTP), qui a été développé pour le World Wide Web. Un

ordinateur sur lequel fonctionne un serveur HTTP est appelé serveur Web. Le terme « serveur Web »

peut aussi désigner le serveur HTTP (le logiciel) lui-même. Les deux termes sont utilisés pour le logiciel

car le protocole HTTP a été développé pour le Web et les pages Web sont en pratique toujours servies

avec ce protocole. D'autres ressources du Web comme les fichiers à télécharger ou les flux sont en

revanche fréquemment servies avec d'autres protocoles.

Source : Wikipédia

2. Les logiciels de serveur HTTP

Lighttpd

Lighttpd est un serveur Web léger sécurité et rapide. Son avantage est qu’il consomme peu de

ressource. Mais il ne supporte les fichiers .htaccess et htpasswd, fichiers permettant de définir des

règles dans un répertoire.

Nginx

Nginx est un serveur HTTP léger, performant et sécurisé. Depuis sa création sa popularité n'a cessé

de croître. Ce serveur Web est réputé pour ses performances et sa faible consommation mémoire. Il

est facile à mettre en œuvre et contient de nombreuses fonctionnalités. Nous ne conseillons pas ce

produit car il manque de maturité et sa documentation n’existe qu’en anglais et en russe.

Apache

Le serveur HTTP Apache est très largement diffusé dans les distributions Linux. C’est ce qui explique

sa popularité dans le monde car c’est le serveur web le plus fréquemment utilisé avec environ 60%

des sites Web (source Netcraft voir figure 1). Il est intéressant de le choisir pour ses multiples

fonctionnalités grâce à des modules. C’est également un projet qui possède une communauté

extrêmement nombreuse. Apache dispose de nombreuses fonctionnalités, il permet l'utilisation de

modules, la possibilité de définir une configuration spécifique pour chaque répertoire partagé, des

restrictions. Il est souvent utilisé avec des modules comme Perl et/ou PHP afin de rendre le contenu

des pages dynamiques.

Figure 10 : Source Netcraft 2010

http://www.techno-science.net/?onglet=glossaire&definition=701










L’Apache http serveur est une application complète et gratuite. Apache a mis en œuvre différents

modules gérant chaque fonctionnalité afin de facilité la gestion et l’administration. De plus, il existe

une grande quantité de documentations et de mise à jour sur Internet. Nos administrateurs ont

choisi le serveur Web d’Apache car c’est un produit mature et stable.

3. Architecture du serveur web

Figure 11: Implémentation du serveur web

Nous vous proposons de mettre en œuvre deux serveurs web, un dans la DMZ qui sera configuré

pour le site public et un dans le réseau LAN pour le site intranet. En effet, pour sécuriser l’accès et

mieux répartir la charge nous avons choisi de séparer les deux accès.

4. Accès public

Il s’agit de votre site internet qui sera visible par tous les internautes aucune authentification ne sera

nécessaire.

5. Accès privé (Intranet)

Ce site sera uniquement accessible aux personnels de l’entreprise qui devront être authentifié par

l’annuaire LDAP. Cet accès privé sera disponible sur le réseau interne ou depuis un poste itinérant

possédant un accès VPN que nous expliquerons dans le prochain chapitre.

Cet accès permettra à vos utilisateurs d’accéder à diverses ressources comme par exemple leur

répertoire utilisateur afin de pouvoir télécharger leurs documents ou des pages HTML donnant des

informations privées ou des formulaires (note de frais).



3. Accès internet sécurisé

1. Introduction

Internet est un outil indispensable dans le milieu professionnel, il est devenu également un moteur

de partage de connaissances. Les entreprises sont de plus en plus axées sur l'aspect social,

collaboratif et ouvert à tous d’Internet ce qui engendre l’obtention de données inadéquates, non

vérifiées, voire même de contenus malveillants. Par conséquent, les entreprises se trouvent face à la

problématique de devoir concilier les exigences d’un accès à l’information disponible sur Internet

tout en assurant la sécurité de leurs données et de leurs réseaux.

Nous vous proposons de mettre en place une politique d’accès à Internet. C’est la stratégie qui

protègera votre réseau afin de ne pas être attaqué aussi bien depuis l’extérieur que depuis

l’intérieur. Chaque donnée émise sera analysée et traiter selon les règles en vigueur. Afin de

répondre au cahier des charges, notre choix s’est porté sur l’utilisation d’un serveur proxy. Un tel

système réduit de façon considérable le risque d’attaque, à condition d’avoir fournit des règles de

sécurité.

2. Présentation

Le rôle premier d’un serveur proxy est de servir de relais entre deux réseaux. Dans certain cas, les

proxys peuvent être "anonymisant" c'est-à-dire qu'il ne reste pas de traces de l'émetteur de la

requête lorsque le service distant est contacté. Il peut également être utilisé pour de filtrage les

données, c'est-à-dire assurer un suivi des requêtes vers Internet effectuées par les utilisateurs et

filtrer les sites de destination par URL ou par contenu (les vidéos par exemple).

3. Fonctionnement

Le principe de fonctionnement d'un serveur proxy est très simple : il s'agit d'un serveur "mandaté"

par une application pour effectuer une requête sur Internet à sa place. Ainsi, lorsqu'un utilisateur se

connecte à internet à l'aide d'une application cliente configurée pour utiliser un serveur proxy, celle-

ci va se connecter en premier lieu au serveur proxy et lui donner sa requête. Le serveur proxy va

alors se connecter au serveur que l'application cliente cherche à joindre et lui transmettre la requête.

Le serveur va ensuite donner sa réponse au proxy, qui va à son tour la transmettre à l'application

cliente.

4. Proxy cache

Une autre des fonctions de Squid, est de servir de "cache" (proxy-cache). C'est-à-dire de stocker

localement les contenus ou les URL les plus souvent demandés pour les restituer quasi

immédiatement. Pour optimiser le gain de temps et de bande passante, nous vous conseillons de

mettre un serveur Proxy Squid sur chaque site.



5. Implémentation du proxy

Comme nous l’avons vu dans la partie précédente, nous vous proposons l’installation de quatre

serveurs proxys.

Figure 12 : Implémentation des proxys Squid

6. Installation et configuration

Installation

L’administration des solutions Linux est assez complexe ainsi que leur configuration. Afin, d’optimiser

les ressources systèmes, et éviter les problèmes de plantage, nous avons choisis d’installer les

serveurs proxys en mode script.

Sur debian, il suffit d’utiliser la commande suivante pour l’installation de Squid :

apt-get install squid.

Contrôler les accès

Pour contrôler tout ce qui passe par votre serveur proxy, vous pouvez utiliser ce que l'on appelle les

ACL (Access Control List). Les ACL sont des règles que le serveur applique. Cela permet par exemple

d'autoriser ou d'interdire certaines transactions.

On peut autoriser ou interdire en fonction du domaine, du protocole, de l'adresse IP, du numéro de

port, d'un mot, on peut aussi limiter sur des plages horaires.



Authentification

Nous avons choisis de contrôler vos utilisateurs en fonction de l’annuaire OpenLDAP.

Voici les ajouts à réaliser dans le fichier squid.conf :

acl identification proxy_auth REQUIRED

http_access allow identification

authentificate_program /usr/lib/squid/squid_ldap_auth \

-b $LDAP_USER -u uid ldap.vsn-

aristote.lan

7. Conclusion

Squid est un logiciel proposant des fonctionnalités nombreuses et configurables. Il permettra une

meilleure gestion de vos utilisateurs ainsi qu’une sécurité supplémentaire de votre réseau.


Mise en place d’un Firewall avec Netfilter/Iptables (Vincent Desseaux) 47

8. Mise en place d’un Firewall avec Netfilter/Iptables

(Vincent Desseaux) IPtables et Netfilter fournissent les fonctionnalités de filtrage disponibles sous Linux à partir du

noyau 2.4. Netfilter effectue le filtrage proprement dit, tandis qu’IPtables fournit les commandes

nécessaires à la programmation des filtres. IPtables fournit trois types de fonctionnalités :

Filtrage : statique (stateless) ou dynamique (stateful) et connection tracking

NAT: traduction d’adresses IP, source NAT, destination NAT, masquerade, redirection de port

(il faut noter que IPtables ne permet pas d’effectuer du NAT statique) ;

Marquage et manipulation de paquets.

Ce firewall se situera à la frontière du réseau LAN d’Orsay, des sites annexes, de la DMZ et du réseau

Internet. Il sera donc nécessaire de disposer d’au minimum 4 interfaces réseau sur la machine

enrobant cette fonctionnalité. Ci-joint en annexe un récapitulatif de la commande iptables ainsi que

le tableau recensant l’ensemble des règles à appliquer sur le firewall.

Il convient également de mettre en place le routage par forwarding et que la machine prenne en

charge le support du NAT/PAT.

La configuration d’IPtables se fait initialement en script de commande, c’est pourquoi son

administration peut être fastidieuse et nécessite de l’expérience et des connaissances techniques

appropriées. Afin de rendre cette tâche d’administration plus conventionnelle, nous proposons

d’intégrer le composant webmin qui permet d'administrer un serveur UNIX ou Linux à distance via

une interface graphique web.


Serveur VPN (Bastien Gayral) 48

9. Serveur VPN (Bastien Gayral)

1. Introduction

Il est demandé dans le cahier des charges, un accès au site intranet de votre entreprise accessible par

votre personnel itinérant. Ces clients nomades « roadwarrior » utilisent des adresses IP inconnues

attribuée dynamiquement pour se connecter à votre réseau. Il est pour cela nécessaire de mettre en

place une autorité de certification ainsi qu’un serveur VPN.

2. Présentation

Un VPN (Virtual Private Network ou Réseau Privé Virtuel en français) permet de relier deux réseaux

distants à travers Internet. Il est possible de faire communiquer ces deux réseaux comme s’ils étaient

connectés directement ensemble. Un cryptage est rajouté entre les deux connectiques qui vont

initier la VPN à l’aide d’un procédé de tunnelisation

3. Solutions VPN existantes

Sur les systèmes Linux, plusieurs initiatives ont été créées pour répondre au besoin de VPN. Il existe

plusieurs types de VPN fonctionnant sur différentes couches réseau, voici les VPN que nous pouvons

mettre en place sur un serveur dédié :

- une solution Open Source IPSec comme OpenS/WAN

- une solution Open Source qui utilise la technologie SSL comme OpenVPN.

- une solution Open Souce qui utilise du SSH encapsulé par le protocole PPP comme OpenSSh

Openswan

Le projet Openswan qui propose une implémentation des protocoles IPSec et IKE pour les noyaux

Linux. Adapté à des configurations fixes, la technologie IPSec s'avère efficace pour des connexions

entre sites ou avec des PC distants gérés par l'entreprise. Il convient moins aux nomades car les pare-

feu risquent de bloquer le trafic.

OpenVPN

Le projet OpenVPN, il s’agit d’un VPN reposant sur la couche de sécurisation SSL très facile à

déployer. Ses principaux atouts sont de passer au-dessus des pare-feu et d’avoir un client

(navigateur) présent sur tous les PC. Il fonctionne derrière du NAT et gère les changements

d'adresses pour les clients connectés en DHCP. C’est solution que nous avons retenu car elle répond

pleinement au cahier des charges.

OpenSSH

Depuis sa version 4.3, le logiciel OpenSSH permet de créer des tunnels entre deux interfaces réseau

virtuelles. Toutefois, OpenSSH ne gère que la création de ces tunnels, la gestion (routage, adressage,

pontage, etc ...), c'est-à-dire la création du VPN utilisant ces tunnels, restant à la charge de

l'utilisateur.

http://fr.wikipedia.org/wiki/OpenSSH

http://fr.wikipedia.org/wiki/OpenSSH



4. Implémentation de VPN dans l’architecture d’Aristote

OpenVPN est un système permettant de relier des postes distants sur un réseau informatique en

passant par Internet mais de manière sécurisée (Tunnel VPN).

Figure 13 : Implémentation du serveur VPN

Le schéma ci-dessus représente votre architecture réseau. Le but est donc de créer un tunnel entre

vos utilisateurs nomades et le serveur pour que le client situé à l’extérieur accède à votre réseau

local. Pour communiquer avec un poste du réseau LAN (172.16.0.0), le client (10.15.0.6) passera donc

par le tunnel jusqu'au serveur OpenVPN (10.0.0.20) et sera ensuite routé sur votre LAN.

Création des certificats et des clés

La première étape dans la construction d’une configuration OpenVPN est d’établir une Infrastructure

de Clés Publiques (PKI en anglais). Une ICP fonctionne grâce à :

Une clé publique pour le serveur et une clé privée pour chacun des clients

Un certificat de l’Autorité de Certification maître et des clés qui sont utilisées pour identifier

(signer, identifier…) chaque certificat serveur et client.

OpenVPN est livré avec plusieurs scripts permettant de générer plus facilement les clés et les

certificats pour OpenSSL. Ces scripts sont enregistrés dans le dossier « easy-rsa ».

Nous allons générer un certificat et une clé privée pour le serveur et les clients nomades à l’aide des

commandes :

/build-key-server VPN-SERVER # clé pour le serveur

/build-key-server Nomade1 # clé pour le client dont le Cn est Nomade1

Pour chaque client, le champ Common Name doit être renseigné et unique.



5. Configuration du serveur VPN

Premièrement, pour limiter les risques d’attaques sur OpenVPN, il est important que le processus

d’OpenVPN fonctionne sur un utilisateur n’ayant aucun droit sur le système. C’est pourquoi nous

allons créer un nouvel utilisateur.

Pour télécharger et installer OpenVPN : #apt-get install openvpn

La configuration ci-dessous est stockée dans le fichier "/etc/openvpn/server.conf" :

Comme annoncé précédemment, les postes client utiliseront la distribution ubuntu. Il est nécessaire

d’installer openvpn et le pluging network-manager-openvpn. Ce dernier sert pour le gestionnaire

réseau, vous permettant de configurer facilement un client, et ensuite pouvoir le démarrer

6. Conclusion

Cette solution est assez simple à mettre en place. Elle est particulièrement intéressante pour les

clients nomades. Ils peuvent, quelque soit l'endroit où ils se trouvent, mettre en place un VPN entre

le client et un serveur, sans avoir à se soucier de l'état du réseau sur lequel ils se trouvent, et peuvent

utiliser quasiment tous les services réseau sans se préoccuper des règles installées sur les pare-feux,

puisque tous les services sont routés dans le même tunnel.

apt://openvpn/

apt://network-manager-openvpn/


Outil de monitoring système et réseau (Arnaud Hamon) 51

10. Outil de monitoring système et réseau (Arnaud

Hamon) Rappel : Un outil de statistiques réseaux est consultable en intranet. Il s’agit d’analyser en

autre la charge de bande passante à l’aide de simulations et de mesures.

Dans le monde open source, on retrouve une multitude de solutions de monitoring systèmes et/ou

réseaux tel que :

- Cacti : repose principalement sur le protocole SNMP. C’est principalement utilisé pour la métrologie réseau.

- OpenNMS : Outil de supervision SNMP mais limité dans ses foinctionnalités. - Nagios : Outil de supervision (Ordonnaceur).

Afin de répondre aux besoins, une solution Nagios et pnp4nagios est la solution la plus adaptée.

Nagios peut superviser les équipements réseaux ainsi que les équipements système tel que AIX, Linux

ou bien encore Windows. La grande force de Nagios est une supervision basée sur des plug-ins. Ses

plug-ins permettent de superviser la grande majorité des métriques nécessaires et la grande facilité

de conception et/ou optimisation de ses plug-ins en fond l’outil de supervision open source le plus

utilisé.

Nagios ne gère pas les données métrologiques, c’est pourquoi pnp4nagios sera ajout à nagios afin de

produire des graphiques de performances pour certaines métriques comme la charge CPU, les

espaces disques.

Nagios propose une interface WEB afin de visualiser les métriques remontées. Grâce à la mise en

place de seuil sur les métriques remontées, on peut générer des alertes sur l’interface afin de

prévenir de possibles latences, saturation de disques ou la perte de services comme messagerie ou

bien antivirus. De plus, pnp4nagios s’appuie sur cette même interface. On met en place des liens sur

l’interface WEB (aussi appelé console de supervision) afin de rediriger vers les graphes de

performances.

Voici un exemple de graphe généré à partir de PnP4Nagios :

Figure 14 - Graphique NAgios

Ce graphe représente les temps de réponse au ping en précisant la valeur minimum, maximum et

moyenne sur une journée.


Infrastructure global (Jérôme TENEUR) 52

11. Infrastructure global (Jérôme TENEUR)


Conclusion (Jérôme TENEUR) 53

12. Conclusion (Jérôme TENEUR)

Après cette étude, nous avons arrêté nos choix sur les différents éléments nécessaires pour la

réalisation de l’intranet en environnement Linux. Voici le résumé de nos différents choix dans les

solutions Linux :

- L’organisation et la gestion des utilisateurs : OpenLDAP

- Le serveur de configuration IP : DHCP ISC

- La résolution des noms IP : BIND 9

- Le serveur de ressources : NFS 4

- Le serveur de sauvegarde : BackupPC

- Le serveur web et l’accès internet sécurisé : Apache et IpCop + Squid

- Firewall : IPtable + NetFilter - Serveur VPN : OpenVPN - Monitoring et gestion des incidents : Nagios

L’ensemble de ces solutions seront implémentées dans les environnements suivants :

- L’environnement réel soit les 4 sites qui furent décrit dans le chapeau du projet MIR

- L’environnement lors de la maquette soit le site d’Bayonne et de Bruxelles avec le matériel

disponible pour les serveurs et/ou les postes clients


Bibliographie 54

13. Bibliographie

Installation du serveur LDAP

http://www.coagul.org/spip.php?article172

http://uid.free.fr/Ldap/ldap.html

http://www.openldap.org/doc/admin23/

http://www.linux-france.org/prj/edu/archinet/systeme/ch51s05.html

http://www.vogelweith.com/debian_server/050_openldap.php#x1-210005

http://julp.developpez.com/freebsd/authentification-ldap/#L2.2.1

Kerberos

http://wiki.debian.org/LDAP/Kerberos

http://www.esup-portail.org/pages/viewpage.action?pageId=88244245

http://www.tylerlesmann.com/2008/oct/06/kerberos-client-configuration-debian-derivatives/

DHCP

http://datatracker.ietf.org/doc/rfc1541/


http://www.delafond.org/traducmanfr/man/man8/dhcpd.8.html

http://www.delafond.org/traducmanfr/man/man5/dhcpd.conf.5.html

http://www.delafond.org/traducmanfr/man/man5/dhcpd.leases.5.html

http://www.frameip.com/dhcp/#1_-_D%C3%A9finition

http://www.linux-kheops.com/doc/redhat73/rhl-cg-fr-7.3/s1-dhcp-configuring-server.html

Options DHCP


http://www.delafond.org/traducmanfr/man/man5/dhcp-options.5.html

Relai DHCP



MAJ Dynamique DNS

http://www.chiroux.com/installation-dun-couple-de-serveurs-dhcp-et-dns-redondants/

http://arnofear.free.fr/linux/template.php?tuto=1&page=1

Répartition de charge DHCP :


http://www.lithodyne.net/docs/dhcp/dhcp.html



http://www.openldap.org/doc/admin23/


http://www.vogelweith.com/debian_server/050_openldap.php#x1-210005

http://julp.developpez.com/freebsd/authentification-ldap/#L2.2.1

http://wiki.debian.org/LDAP/Kerberos

http://www.esup-portail.org/pages/viewpage.action?pageId=88244245

http://www.tylerlesmann.com/2008/oct/06/kerberos-client-configuration-debian-derivatives/



http://www.delafond.org/traducmanfr/man/man8/dhcpd.8.html

http://www.delafond.org/traducmanfr/man/man5/dhcpd.conf.5.html

http://www.delafond.org/traducmanfr/man/man5/dhcpd.leases.5.html

http://www.frameip.com/dhcp/#1_-_D%C3%A9finition

http://www.linux-kheops.com/doc/redhat73/rhl-cg-fr-7.3/s1-dhcp-configuring-server.html


http://www.delafond.org/traducmanfr/man/man5/dhcp-options.5.html



http://www.chiroux.com/installation-dun-couple-de-serveurs-dhcp-et-dns-redondants/

http://arnofear.free.fr/linux/template.php?tuto=1&page=1


http://www.lithodyne.net/docs/dhcp/dhcp.html


Bibliographie 55

DNS

http://www.zimbrafr.org/forum/topic/1464-tutoriel-installationconfiguration-bind-et-zimbra/


http://www.linux-kheops.com/doc/redhat72/rhl-rg-fr-7.2/s1-bind-configuration.html

http://blog.info16.fr/?p=9

http://www.bind9.net/

http://fr.wikipedia.org/wiki/BIND

http://forum.webrankinfo.com/configuration-serveur-dns-societe-connue-t97150.html

http://www.pubbs.net/200904/bind/21735-bind9-unknown-rr-type-unknown-classtype-errors.html

http://linuxmanpages.com/man5/dhcpd.conf.5.php

Serveur de Backup

http://doc.ubuntu-fr.org/serveur

http://IPduserveurdesauvegarde/backuppc/index.cgi?action=view&type=docs

Supervision Nagios

http://www.nagios.org/

http://www.pnp4nagios.org/

Ouvrage « Nagios 3 pour la supervision et la métrologie » de Jean Gabès

Partage de ressources :

http://sourceware.org/cluster/doc/nfscookbook.pdf

http://wiki.goldzoneweb.info/cluster_nfs

http://gfs.wikidev.net/DRBD_Cookbook

http://wiki.ncl.cs.columbia.edu/wiki/GFS_Installation_in_Debian

http://www.techforce.com.br/news/linux_blog/red_hat_cluster_suite_debian_etch

http://publications.jbfavre.org/system/drbd_installation_debian_lenny_backports_module_assistant

http://www.howtoforge.com/highly-available-nfs-server-using-drbd-and-heartbeat-on-debian-5.0-

lenny

http://docs.redhat.com/docs/fr-

FR/Red_Hat_Enterprise_Linux/5/pdf/Cluster_Suite_Overview/Red_Hat_Enterprise_Linux-5-

Cluster_Suite_Overview-fr-FR.pdf

http://www.drbd.org/users-guide/users-guide.html

http://www.admin-debian.com/les-systemes-de-fichiers-linux/les-systemes-de-fichiers-linux-ext3-

reiserfs-xfs-nfs/

http://www.admin-debian.com/les-systemes-de-fichiers-linux/lvm-2-logical-volume-management/

http://www.queret.net/blog/post/2007/05/17/87-linux-debian-lvm-vgscan-pvcreate-vgcreate-

lvcreate

http://nfs.sourceforge.net/nfs-howto/ar01s05.html

https://wiki.linux-nfs.org/wiki/index.php/Cluster_Coherent_NFSv4_and_Share_Reservations

http://nfs.sourceforge.net/

http://sources.redhat.com/cluster/doc/cluster_schema.html

http://www.zimbrafr.org/forum/topic/1464-tutoriel-installationconfiguration-bind-et-zimbra/


http://www.linux-kheops.com/doc/redhat72/rhl-rg-fr-7.2/s1-bind-configuration.html

http://blog.info16.fr/?p=9

http://www.bind9.net/

http://fr.wikipedia.org/wiki/BIND

http://forum.webrankinfo.com/configuration-serveur-dns-societe-connue-t97150.html

http://www.pubbs.net/200904/bind/21735-bind9-unknown-rr-type-unknown-classtype-errors.html

http://linuxmanpages.com/man5/dhcpd.conf.5.php

http://doc.ubuntu-fr.org/serveur

http://ipduserveurdesauvegarde/backuppc/index.cgi?action=view&type=docs

http://www.nagios.org/

http://www.pnp4nagios.org/

http://sourceware.org/cluster/doc/nfscookbook.pdf

http://wiki.goldzoneweb.info/cluster_nfs

http://gfs.wikidev.net/DRBD_Cookbook

http://wiki.ncl.cs.columbia.edu/wiki/GFS_Installation_in_Debian

http://www.techforce.com.br/news/linux_blog/red_hat_cluster_suite_debian_etch

http://publications.jbfavre.org/system/drbd_installation_debian_lenny_backports_module_assistant

http://www.howtoforge.com/highly-available-nfs-server-using-drbd-and-heartbeat-on-debian-5.0-lenny

http://www.howtoforge.com/highly-available-nfs-server-using-drbd-and-heartbeat-on-debian-5.0-lenny

http://docs.redhat.com/docs/fr-FR/Red_Hat_Enterprise_Linux/5/pdf/Cluster_Suite_Overview/Red_Hat_Enterprise_Linux-5-Cluster_Suite_Overview-fr-FR.pdf



http://www.drbd.org/users-guide/users-guide.html

http://www.admin-debian.com/les-systemes-de-fichiers-linux/les-systemes-de-fichiers-linux-ext3-reiserfs-xfs-nfs/

http://www.admin-debian.com/les-systemes-de-fichiers-linux/les-systemes-de-fichiers-linux-ext3-reiserfs-xfs-nfs/

http://www.admin-debian.com/les-systemes-de-fichiers-linux/lvm-2-logical-volume-management/

http://www.queret.net/blog/post/2007/05/17/87-linux-debian-lvm-vgscan-pvcreate-vgcreate-lvcreate

http://www.queret.net/blog/post/2007/05/17/87-linux-debian-lvm-vgscan-pvcreate-vgcreate-lvcreate

http://nfs.sourceforge.net/nfs-howto/ar01s05.html

https://wiki.linux-nfs.org/wiki/index.php/Cluster_Coherent_NFSv4_and_Share_Reservations

http://nfs.sourceforge.net/

http://sources.redhat.com/cluster/doc/cluster_schema.html


Bibliographie 56

http://linux.die.net/man/5/cluster.conf

http://www.smop.co.uk/blog/index.php/2008/02/11/gfs-goodgrief-wheres-the-documentation-file-

system/

http://gcharriere.com/blog/?p=73

http://www.slimejuggernaut.org/bloggernaut/?p=164

http://tethealla.blogspot.com/2007/10/stonith-with-drbd-and-heartbeat.html

http://www.slideshare.net/cb1kenobi/high-availability-with-drbd-heartbeat

http://www-igm.univ-mlv.fr/~dr/XPOSE2006/JEREMIE_LEGRAND_HAUTE_DOSPO/pratique2.htm


http://www.linux-france.org/prj/inetdoc/cours/admin.reseau.synthese-nfs4-ldap/

Serveur Web

http://doc.ubuntu-fr.org/apache2

http://doc.ubuntu-fr.org/lamp

http://www.papygeek.com/software/optimiser-son-serveur-web-avec-nginx/

http://aternatik.org/articles-et-ressources/ldap-17/Authentification-Apache-avec-LDAP,064

VPN

https://help.ubuntu.com/community/VPNClient

http://www.opendoc.net/comment-installer-configurer-serveur-vpn-openvpn

http://www.nemako.net/dc2/?post/openvpn

http://www.coagul.org/article.php3?id_article=422

http://linux.die.net/man/5/cluster.conf

http://www.smop.co.uk/blog/index.php/2008/02/11/gfs-goodgrief-wheres-the-documentation-file-system/

http://www.smop.co.uk/blog/index.php/2008/02/11/gfs-goodgrief-wheres-the-documentation-file-system/

http://gcharriere.com/blog/?p=73

http://www.slimejuggernaut.org/bloggernaut/?p=164

http://tethealla.blogspot.com/2007/10/stonith-with-drbd-and-heartbeat.html

http://www.slideshare.net/cb1kenobi/high-availability-with-drbd-heartbeat

http://www-igm.univ-mlv.fr/~dr/XPOSE2006/JEREMIE_LEGRAND_HAUTE_DOSPO/pratique2.htm


http://www.linux-france.org/prj/inetdoc/cours/admin.reseau.synthese-nfs4-ldap/

http://doc.ubuntu-fr.org/apache2

http://doc.ubuntu-fr.org/lamp

http://www.papygeek.com/software/optimiser-son-serveur-web-avec-nginx/

http://aternatik.org/articles-et-ressources/ldap-17/Authentification-Apache-avec-LDAP,064

https://help.ubuntu.com/community/VPNClient

http://www.opendoc.net/comment-installer-configurer-serveur-vpn-openvpn

http://www.nemako.net/dc2/?post/openvpn

http://www.coagul.org/article.php3?id_article=422


Bibliographie 57

7. Lexique

802.1q : Standard de l’IEEE qui fournit un mécanisme d'encapsulation des VLAN’s, permettant ainsi

du trunk de VLAN’s sur une même interface.

DHCPREQUEST : message client aux serveurs qui confirme la validité des adresses précédemment

allouées ou qui demande les paramètres à un serveur

DHCPRELEASE : client qui demande au serveur de libérer son adresse, d’annuler le bail

DHCPACK : le serveur envoie au client les paramètres de configuration

Enregistrement A : enregistrement d’hôtes

Enregistrement NS : enregistrement des serveurs DNS

Enregistrement SOA : enregistrement du serveur d’autorité de la zone

Samba : Utilise le logiciel SmbClient pour le transfert des données. C'est un bon choix pour

sauvegarder des machines sous Windows.

rSync : Utilise le logiciel RSync pour le transfert des données (via SSH). C'est un bon choix pour

sauvegarder des machines sous Linux et sous windows.

rSyncd : Utilise le daemon « rsyncd » installé sur chaque client. C'est un bon choix pour sauvegarder

des machines sous Linux et sous Windows.

Tar : Utilise le logiciel Tar. C'est un bon choix pour sauvegarder des machines sous Linux.

Ssh : Secure Shell est à la fois un programme informatique et un protocole de communication

sécurisé.

Nas : Network Attached Storage

Certificat électronique : Un certificat contient, tel un passeport ou une carte d’identité, un ensemble

d’informations administratives sur son propriétaire (nom, prénom, adresse électronique, etc.), sur sa

validité, et sur l’organisme d’émission. Il contient également la clé publique de l’utilisateur et un

sceau (la signature électronique de l’autorité de certification) nécessaire à la vérification de son

authenticité. Il permet de garantir l’identité du possesseur de la clé privée associée.

Client/Serveur :L'architecture client/serveur désigne un mode de communication entre plusieurs

ordinateurs d'un réseau qui distingue un...)

Protocole http : Le Hypertext Transfer Protocol, plus connu sous l'abréviation HTTP, littéralement le

« protocole de transfert...)

Le World Wide Web : littéralement la « toile d'araignée mondiale », est communément appelé le

Web.


Bibliographie 58

RPV (réseau privé virtuel) ou VPN (Virtual Private Network) : Le RPV consiste à utiliser un réseau

public (Internet). Les infrastructures, mutualisées, se révèlent meilleur marché, mais la

confidentialité n'est plus garantie. D'où la nécessité de crypter les informations.

SSL (Secure Socket Layer) : Méthode d'authentification et de cryptage utilisée par les premiers

navigateurs Netscape. La version SSL 3.0 a constitué la base lors de la création du protocole TLS

(Transport Layer Security), défini par l'IETF (Internet Engineering Task Force), l'organisme de

normalisation du monde IP.

Tunnel (ou tunneling) : Technique qui consiste à placer les trames d'un protocole dans un autre, de

niveau équivalent ou inférieur selon la nomenclature du modèle OSI. Elle est utilisée pour

transporter les trames d'un réseau d'entreprise à travers un réseau public. Les routeurs de ce dernier

ne voient que les entêtes propres au réseau public.


Annexes 59

14. Annexes

1. Organisation et gestion des comptes utilisateurs (Jérôme

Teneur)

1. Choix de l’environnement graphique

L’administration et la consultation au quotidien de l’annuaire OpenLDAP peut se faire au travers de

plusieurs interphases graphiques. Tous les produits de qualité professionnelle que l’on peut

retrouver offre des fonctions d’ajout/suppression d’utilisateurs et de machines, la répartition de ces

derniers dans différentes unité organisationnelle, etc…

Les plus répandus étant :

JXplorer phpLDAPadmin ldap-account-manager

JXplorer est un client LDAP développé en Java sous une licence opensource de type OSI. Il permet de lire ou modifier le contenu de tout annuaire LDAP ou annuaire X500.

phpLDAPadmin est une interface écrite en php qui permet de modifier facilement et via une interface conviviale un annuaire LDAP.

LAM est basé sur phpLDAPadmin et viens rajouter des scripts et améliorations. Il s’utilise donc au travers d’un navigateur web.

Le choix de l’outil d’administration est souvent très personnel car fonction d’habitudes et de goût. En

effet, dans leurs fonctions de base ces différents produits se valent. Cependant les communautés

permettant l’évolution de ces produits ne sont pas toutes équivalentes, de plus tous ne sont pas

aussi aisément modifiables pour parfaire aux besoins qui de ses utilisateurs.

Pour ces raisons nous préconisons l’utilisation de LDAP Account Manager. Cependant le choix final

incombera toujours à l’utilisateur si ce dernier préfèrerait s’orienter vers un autre produit.


Annexes 60

2. Mise à jour de l’annuaire

Manuelle

La mise à jour de l’annuaire ldap se fait au travers de fichier LDIF (LDAP Data Interchange Format).

Ces fichiers contiennent des entrées de la forme suivante :

Création d’une nouvelle OU

dn: ou=People,dc=example,dc=com

ou: People

objectclass: top

objectclass: organizationalUnit

Création d’un utilisateur

# jerome, Bayonne, People, vsn-aristote.lan

dn: uid=jerome,ou=Bayonne,ou=People,dc=vsn-

aristote,dc=lan

objectClass: shadowAccount

objectClass: posixAccount

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: person

homeDirectory: /home/jerome

loginShell: /bin/bash

uid: jerome

cn: Jerome Teneur

uidNumber: 10001

sn: Teneur

givenName: Jerome

gidNumber: 10003

Enfin, le fichier LDIF doit être intégré à la base de l’annuaire. Cela se fait au travers de la commande :

# ldapadd -x -f fichier.ldif -W -D cn=admin,dc=vsn-aristote,dc=lan

Graphique

La création de nouveaux utilisateurs peut également être entreprise via LDAP Account Manager. Un

menu de configuration assisté permet de définir tous les attribues de l’utilisateur. Seul regret, il n’est

passible de créer qu’un utilisateur à la fois ce qui peut s’avérer lourd en terme de charge

administrative.


Annexes 61

Automatique

La création automatique d’utilisateur se fera au travers d’un script spécialement développé qui :

1- lit le nom du fichier contenant les utilisateurs (un utilisateur par ligne et les attribues séparés par « ; »)

2- lit le nom du groupe auquel appartiendront les utilisateurs, 3- lit de façon récursive le fichier en entrée et extrait pour chaque ligne le nom et le prénom

de l’utilisateur, 4- génère un fichier LDIF temporaire contenant les comptes utilisateurs à ajouter dans la

base OpenLDAP, 5- arrête le démon OpenLDAP, 6- appelle la commande d’ajout d’objet dans la base OpenLDAP avec le fichier LDIF

temporaire, 7- démarre le démon OpenLDAP, 8- supprime le fichier LDIF temporaire.

3. Tests de l’annuaire

L’annuaire est maintenant disponible sut le port 389 en TCP et de manière chiffrée sur le port 636 en

TCP. Pour valider le bon fonctionnement du service, on peut interroger l’annuaire avec la commande

ldapsearch fournie par le paquet ldap-utils installé précédemment. Par exemple, pour faire une

requête LDAP :

# ldapsearch -x -H ldap://127.0.0.1 -b "ou=People,dc=vsn-

aristote,dc=lan" "(objectclass=*)"

Pour utiliser le mode SSL avec ldapsearch, il faut dans un premier temps ajouter la ligne suivante

dans le fichier /etc/ldap/ldap.conf pour ignorer la vérification du certificat :

TLS_REQCERT allow

Il suffit maintenant de reprendre la même requête en modifiant l’URI et en ajoutant l’option -Z :

# ldapsearch -x -H ldaps://127.0.0.1:636 -Z -b "ou=People,dc=vsn-

aristote,dc=lan" "(objectclass=*)"


Annexes 62

4. Kerberos

1. Serveur

[kdcdefaults]

kdc_ports = 750,88

[realms]

VSN-ARISTOTE.LAN = {

database_name = /var/lib/krb5kdc/principal

admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab

acl_file = /etc/krb5kdc/kadm5.acl

key_stash_file = /etc/krb5kdc/stash

kdc_ports = 750,88

max_life = 10h 0m 0s

max_renewable_life = 7d 0h 0m 0s

master_key_type = des3-hmac-sha1

supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-

hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm

des:onlyrealm des:afs3

default_principal_flags = +preauth

}

[logging]

kdc = FILE:/var/log/krb5kdc.log

admin_server = FILE:/var/log/kadmin.log

default = FILE:/var/log/krb5lib.log

Client

L’utilisation de Kerberos se fera au travers des modules linux krb5-user et libpam-krb5.

Une modification de /etc/krb5.conf permettra de spécifier le server KDC :

S’en suit une modification de PAM afin qu’il prenne en compte Kerberos :

# /etc/pam.d/common-account - authorization settings common to all services

account sufficient pam_unix.so

account sufficient pam_krb5.so

account required pam_deny.so

# /etc/pam.d/common-auth - authentication settings common to all services

auth sufficient pam_unix.so nullok_secure

auth sufficient pam_krb5.so use_first_pass

auth required pam_deny.so

# /etc/pam.d/common-password - password-related modules common to all services

password sufficient pam_unix.so nullok obscure min=4 max=8 md5

password sufficient pam_krb5.so use_first_pass

password required pam_deny.so

# /etc/pam.d/common-session - session-related modules common to all services

session optional pam_unix.so

session optional pam_krb5.so


Annexes 63

5. Liste partielle des attributs LDAP de la classe « organization »

Attribut Description businessCategory Activité professionnelle d’une entreprise ou d’une personne c Code du pays en deux lettres (respectant le standard ISO 3166) cn Nom de l’objet (common name) description Description de l’objet distinguishedName Nom distingué (utilisé par d’autres attributs par héritage) facsimileTelephoneNumber Numéro de fax givenName Prénom de la personne houseIdentifier Identifiant d’un batiment initials Initiales d’une personne internationalSDNNumber Numéro ISDN l localité de l’objet (géographique) member Distinguished Name des membres name Nom (utilisé par d’autres attributs par héritage) o Nom de l’organisation objectClass Classe d’objets ou Unité organisationnelle (branche de l’organisation) owner Nom du propriétaire de l’objet postalAddress Adresse postale (sans le code postal) postalCode Code postal postalOfficeBox Boîte aux lettres (postale) presentationAddress Adresse réseau de la présentation de l’objet (généralement une URL

vers la présentation en ligne) protocolInformation Attribut complémentaire à presentationAddress pour définir le

protocole à utiliser registeredAddress Adresse postale pour des envois de courriers recommandés et de colis seeAlso DN d’objets complémentaires serialNumber Numéro de série de l’objet sn Nom de famille de la personne (surname) st Etat ou région (state) streetAddress Nom de la rue et assimiilé (boulevard, ...) telephoneNumber Numéro de téléphone title Titre de la personne (différent de fonction) uid Identifiant unique de l’objet userPassword Mot de passe de l’utilisateur


Annexes 64

6. Liste partielle des attributs LDAP de la classe « inetOrgPerson »

Nom Sémantique Mono Obl Lecture Utilisation cn nom(s)

complet(s) (d’usage) sans accent

O RI Ordre : Nom, Prénom. Attention : pas d’accent pour simplifier les recherches. Voir aussi displayName. Exemple : "Bugale Jerome"

displayName nom complet avec accents

Version accentuée de la valeur principale de cn. Exemple : "Bugalé Jérôme"

employeeType type de personnel

D ? RI ? Définir les grandes familles ?

facsimileTelephoneNumber Numéro de fax

RI Format E 123 (cf Références)

givenName Prénom M D RI idem sn. Exemple : "Jérôme" labeledURI Page

personnelle RI

mail adresse mel canonique

M RI ?

mobile numéro de téléphone mobile


o Nom de l’organisation ou Unité organisationnelle (branche de

l’organisation) postalAddress Adresse

postale RI Adresse complète. Attention au format

("$" séparateur, voir RFC2256) postalCode Code postal preferredLanguage langue

préférée M RI cf RFC2068

sn Nom O RI Contient le nom d’usage. Il est possible d’ajouter le nom de famille (nom patronymique) en seconde valeur. Tout caractère diacritique. Première lettre en majuscule. Voir aussi cn. Exemple : "Bugalé".

st Etat ou région (state) telephoneNumber numéro de

téléphone fixe


title titre RI Responsabilité ; président, directeur, ... (cf Harpège ?). Code ou intitulé complet ?

uid identifiant unique

M D R utilisé comme rdn, contenu indifférent mais aussi court que possible

userCertificate certificat X509

A ?


Annexes 65

7. Script création utilisateurs

#! /bin/sh

#On affiche un avertissement à destination de l'administrateur :

echo "-----------------------------------------------------------------"

echo " VOUS ETES SUR POINT D'AJOUTER DES UTILISATEURS A LA BASE LDAP ! "

echo "-----------------------------------------------------------------"

echo ""

#On demande à l'administrateur de saisir le chemin complet du fichier contenant les

utilisateur et on récupère ce chemin dans la variable "fichier" :

echo "Veuillez saisir le chemin complet du fichier contenant les utilisateurs : "

read fichier

echo ""

#On affiche la liste de groupes et on demande à l'administrateur d'indiquer le

numero du groupe pour lui éviter la saisie :

echo "Liste des groupes :"

echo "__________________________________________"

echo "[1] Direction Generale"

echo "[2] Direction Administrative et Financiere"

echo "[3] Direction Commerciale et Marketing"

echo "[4] Direction des Etudes"

echo "[5] Direction Production"

echo ""

echo "Veuillez saisir le numero correspondant au groupe auquel appartiendront les

utilisateurs :"

#On récupère le numero saisi par l'administrateur dans la variable "numGroupe" :

read numGroupe

echo ""

#On retranscrit le numero saisi par l'administrateur en nom d'unité

organisationnelle et gid de groupe au sens annuaire LDAP et on les affecte

respectivement aux variables "nomGroupe" et "idGroupe" :

case $numGroupe in

1)

nomGroupe="direction generale"

idGroupe="1001"

;;

2)

nomGroupe="direction administrative et financiere"

idGroupe="1002"

;;

3)

nomGroupe="direction commerciale et marketing"

idGroupe="1003"

;;

4)

nomGroupe="direction des etudes"

idGroupe="1004"

;;

5)

nomGroupe="direction production"

idGroupe="1005"

;;


Annexes 66

esac

#On détruit le fichier "/tmp/slapaddTemp.ldif" qui aurait pu ne pas etre effacé

lors d'un précédent appel du script :

rm /tmp/slapaddTemp.ldif

#On lit ligne par ligne le fichier "fichier" jusqu'au bout et on affecte

respectivement aux variables "nomPersonne" "prenomPersonne" chaque champ délimité

par le caractère ":"

#On utilise ces variables ainsi que "idGroupe" et "nomGroupe" pour construire un

fichier LDIF temporaire "/tmp/slapaddTemp.ldif"

#On génère aléatoirement un uid pour chaque utilisateur avec la commande RANDOM :

while IFS=: read nomPersonne prenomPersonne

do

ID=$RANDOM

echo "dn: uid=$prenomPersonne $nomPersonne,ou=$nomGroupe,dc=aristote,dc=mir"

>> /tmp/slapaddTemp.ldif

echo "uid: $prenomPersonne $nomPersonne" >> /tmp/slapaddTemp.ldif

echo "cn: $prenomPersonne $nomPersonne" >> /tmp/slapaddTemp.ldif

echo "objectClass: account" >> /tmp/slapaddTemp.ldif

echo "objectClass: posixAccount" >> /tmp/slapaddTemp.ldif

echo "objectClass: top" >> /tmp/slapaddTemp.ldif

echo "objectClass: shadowAccount" >> /tmp/slapaddTemp.ldif

echo "userPassword: password" >> /tmp/slapaddTemp.ldif

echo "shadowLastChange: 14909" >> /tmp/slapaddTemp.ldif

echo "shadowMax: 99999" >> /tmp/slapaddTemp.ldif

echo "shadowWarning: 7" >> /tmp/slapaddTemp.ldif

echo "loginShell: /bin/bash" >> /tmp/slapaddTemp.ldif

echo "uidNumber: $ID" >> /tmp/slapaddTemp.ldif

echo "gidNumber: $idGroupe" >> /tmp/slapaddTemp.ldif

echo -e "homeDirectory: /home/$prenomPersonne $nomPersonne\n" >>

/tmp/slapaddTemp.ldif

done < $fichier

#On arrête le démon du serveur OpenLDAP :

/etc/init.d/slapd stop

#On ajoute les objets utilisateurs à partir du fichier LDIF temporaire avec la

commande slapadd :

slapadd -l /tmp/slapaddTemp.ldif

#On démarre le démon du serveur OpenLDAP :

/etc/init.d/slapd start

#On supprime le fichier LDIF temporaire :

rm /tmp/slapaddTemp.ldif


Annexes 67

8. Configuration des clients LDAP

/etc/pam.d/common-account account required pam_unix.so

account sufficient pam_ldap.so

/etc/pam.d/common-auth auth required pam_env.so

auth sufficient pam_unix.so likeauth nullok

auth sufficient pam_ldap.so use_first_pass

auth required pam_deny.so

/etc/pam.d/common-passwor

password required pam_cracklib.so retry=3

minlen=2 dcredit=0 ucredit=0

password sufficient pam_unix.so nullok

use_authtok md5 shadow

password sufficient pam_ldap.so use_authtok

password required pam_deny.so

/etc/pam.d/common-session session required pam_limits.so

session required pam_unix.so

session optional pam_ldap.so

Et enfin, on modifie le fichier de configuration de NSS :

/etc/nsswitch.conf

passwd: ldap compat

group: ldap compat

shadow: ldap compat

9. Configuration pour le montage des répertoires personnels

Modification du serveur NFS

Créer le répertoire de l'utilisateur et donner les autorisations pour modifier ses données sur le

serveur (o+rwx)

Modification du schéma LDAP

Il est nécessaire d’ajouter dans le fichier nis.schema le schema "automount.schema" pour

automount

Le schéma définit un attribut automountInformation et deux classes d'objet. De plus une instance de

classe automount contient au moins deux attributs : cn et automountInformation.

user@serveur:~$

sudo mkdir /home/serveur

sudo mkdir /home/serveur/dupont

sudo chmod go+rwx /home/serveur/dupont


Annexes 68

Modification de l’arbre LDAP

Nous pouvons indiquer l'emplacement du homedir sur le serveur avec les options de montage

Automount recherche un objet LDAP automount dont l'attribut cn correspond au login.

Enfin nous pouvons modifier l’arbre LDAP manuellement via un fichier LDIF :

~ fichier automount.schema ~

attributetype ( 1.3.6.1.1.1.1.25 NAME 'automountInformation'

DESC 'Information used by the autofs automounter'

EQUALITY caseExactIA5Match

SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

objectclass ( 1.3.6.1.1.1.1.13 NAME 'automount' SUP top

STRUCTURAL

DESC 'An entry in an automounter map'

MUST ( cn $ automountInformation )

MAY ( description ) )

objectclass ( 1.3.6.1.4.1.2312.4.2.2 NAME 'automountMap' SUP top

STRUCTURAL

DESC 'An group of related automount objects'

MUST ( ou ) )

~ fichier au.ldif ~

dn: cn=dupont,ou=People,dc=vsn-aristote,dc=lan

objectClass: top

objectClass: automount

cn: dupont

automountInformation: fstype=nfs,hard,intr,nodev,nosuid,rw 192.168.0.1:/home/serveur/dupont


Annexes 69

2. Récapitulatif des réseaux de chaque site à mettre en place

(Vincent Desseaux)

Site Adresse Réseau Masque de sous réseau

Orsay 172.16.0.0 255.255.0.0 Bayonne 172.17.0.0 255.255.0.0

Sophia Antipolis 172.18.0.0 255.255.0.0 Bruxelles 172.19.0.0 255.255.0.0 Itinérant 172.20.0.0 255.255.0.0

DMZ d’Orsay 10.0.0.0 255.0.0.0

1. Plan d’adressage des sous réseaux par site

Type de direction

Adresse de sous réseau

Vlan ID Orsay

Vlan ID Bayonne

Vlan ID Sophia Antipolis

Vlan ID Bruxelles

Serveurs 172.X.0.0/24 Vlan 2 Vlan 102 Vlan 202 Vlan 302 Générale 172.X.1.0/24 Vlan 3 Vlan 103 Vlan 203 Vlan 303 Administrative et Financière

172.X.2.0/24 Vlan 4 Vlan 104 Vlan 204 Vlan 304

Commerciale et Marketing

172.X.3.0/24 Vlan 5 Vlan 105 Vlan 205 Vlan 305

Etudes 172.X.4.0/24 Vlan 6 Vlan 106 Vlan 206 Vlan 306 Production 172.X.5.0/24 Vlan 7 Vlan 107 Vlan 207 Vlan 307

(X varie en fonction du site)

3. Configuration d’un serveur DHCP (Vincent Desseaux)

La configuration d’un serveur DHCP est renseignée dans le fichier dhcpd.conf. Dans cette

partie, nous étudierons les différents paramètres et déclarations courants au bon fonctionnement de

ce service par le biais d’extraits de la configuration DHCP du site d’Orsay. Avant d’entamer l’étude de

ces extraits, quelques généralités sur ces deux points :

Les déclarations sont utilisées pour décrire la topologie du réseau, les clients et les

adresses attribuables, ou encore pour appliquer un groupe de paramètres à un groupe

de déclarations. Dans tout groupe de paramètres et de déclarations, les paramètres

doivent être spécifiés avant les déclarations qui en dépendent.

Les paramètres déterminent les valeurs internes du serveur (par exemple la durée

d’un bail), définissent son comportement (ce que dhcpd doit attribuer des adresses

aux clients inconnus) et spécifient les informations qu'il doit fournir aux clients (tel que

la passerelle). La RFC 2132 (DHCP Options and BOOTP Vendor Extensions) définit les

options standards et donc les plus couramment utilisé.

Les paramètres débutant avec le mot-clé option sont réellement optionnels pour

DHCP. Les autres paramètres contrôlent soit le comportement du serveur DHCP, soit

spécifient des paramètres obligatoires des clients DHCP (par exemple le nom du

serveur)


Annexes 70

Les baux alloués sont renseignés dans le fichier dhcpd.leases (peut être dans

/var/lib/dhcpd.leases ou /etc/dhcpd/dhcpd/leases en fonction des versions). Nous

pourrons trouver en autre dans ce fichier pour chaque adresse allouée :

La date de début et de fin du bail

L’adresse MAC de l’hôte

L’adresse IP allouée

Des options propres aux clients (nom d’hôte par exemple)

# ======== Option Generales du dhcp ========

server-name "ors-srv-dhcp1.vsn-aristote.lan"; #Nom du serveur DHCP employé

option domain-name "vsn-aristote.lan"; #Option définissant le suffixe DNS employé

(optionnel)

option domain-name-servers 172.16.0.5, 172.16.0.6; #Option définissant les adresses IP des

serveurs DNS

ping-check = 1; #Evalue si l'adresse est déjà attribuée en effectuant un ping de celle-ci

default-lease-time 3600; #Durée par défaut du bail (en secondes)

max-lease-time 7200 ; #Durée max du bail (en secondes)

authoritative; #Définit le serveur comme faisant autorité sur le segment auquel il est

connecté

log-facility local7; #Définit la redirection des messages de log

# ======== Déclaration Des Reseaux ========

#Déclaration du réseau partagé Orsay pour informer le serveur DHCP que certains sous-réseau

IP partagent en réalité le même réseau physique

shared-network Orsay {

#Déclaration sous réseau 172.16.0.0/24

subnet 172.16.0.0 netmask 255.255.255.0 {

#Nous pourrions définir pour un réseau spécifique une option différente que celle

employée dans la partie générale

#option domain-name "mon_domaine.qqc";

option broadcast-address 172.16.0.255; #Définition de l’adresse de diffusion

option routers 172.16.0.254; #Définition de la passerelle par défaut

pool { # Déclaration d'une plage d'attribution d'adresse

range 172.16.0.50 172.16.0.200; #Définition de l’étendue de la plage, ici l’attribution

commencera à partir de l’adresse 172.16.0.50/24 pour finir à l’adresse 172.16.0.200/24,

soit 151 adresses.

}

}

subnet 172.16.1.0 netmask 255.255.255.0 {

option broadcast-address 172.16.1.255;

option routers 172.16.1.254;

pool {

range 172.16.1.50 172.16.1.200;

}

}

}


Annexes 71

1. Configuration du canal failover du site d’Orsay :

# ======== Failover configuration ========

failover peer "dhcp-failover" { #Déclaration du canal failover ayant pour nom "dhcp-failover"

primary; #Spécifie pour le fichier de configuration qu’il est maître (secondary pour

secondaire)

address 172.16.0.3; #L’adresse d’écoute de l’hôte locale

port 647; #Port d’écoute de l’hôte locale

peer address 172.16.0.4; #L’adresse d’écoute de l’hôte distant

peer port 647; #Port d’écoute de l’hôte distant

max-response-delay 30; #Temps maximum de non-réponse d’une des paires avant rupture du

canal

max-unacked-updates 10; #Nombre maximum de mise à jour d’une paire sans avoir reçu

d’acquittement

load balance max seconds 3; #Temps maximum avant lequel l’une des paires répond à une

requête prévu à l’autre si aucune réponse n’a été envoyé (Seulement sur le maître)

mclt 1800; #Définit le temps maximum pour lequel un bail peut être renouvelé sans en

informer la paire (Seulement sur le maître)

split 128; #Définit la proportion de répartition entre les deux serveurs (128 équivaut à

50%) (Seulement sur le maître)

}

Ensuite lors de la configuration des sous-réseaux et des plages, il faudra spécifier le nom du

canal failover à utiliser :

subnet 172.16.1.0 netmask 255.255.255.0 {



pool {

failover peer "dhcp-failover"; #Définit que ce canal failover gère la

répartition de charge pour la plage donnée

range 172.16.1.50 172.16.1.200;

}

ping-check = 1;

}

2. Mise en place de la fonctionnalité de mise à jour du DNS

La mise en place de cette fonctionnalité se fait en renseignant dans le fichier dhcpd.conf les

parties suivantes :

# Spécifie la zone de nom sur lequel DHCP effectuera les mises à jours

ddns-domainname "vsn-aristote.lan";

# Spécifie la zone reverse sur lequel DHCP effectuera les mises à jours pour chaque

réseaux/sous-réseaux.

ddns-rev-domainname "0.16.172.in-addr.arpa";



…

#Méthode de mise à jour du DNS : soit ad-hoc (Obsolète car supporte pas le failover), soit

interim

ddns-update-style interim;

#Mise à jour autorisée

ddns-updates on;

#on force la maj par le dhcp et non par le client

ignore client-updates;

#on force la maj des statiques DHCP

update-static-leases on;

# Autoriser les clients inconnus au niveau de l'adresse MAC

allow-unknow-clients;


Annexes 72

3. Les aspects sur la sécurité

Le serveur DNS doit être configuré pour pouvoir être mis à jour par le serveur DHCP. La méthode la plus sûre utilise les signatures TSIG, basées sur une clé comme pour le programme d'administration des serveurs de nom rndc.. Nous devrons en créer pour effectuer les mises à jour DNS depuis le(s) serveur(s) DHCP via la commande « dnssec-keygen -a hmac-md5 -b <bit-length> -n HOST <key-file-name> ». Cette commande va générer deux fichiers nommés K<hostname>.xxxxxxxx.key et K<hostname>.xxxxxxxx.private, le fichier .key va devenir notre clef rndc.

Dans le fichier de configuration named.conf et dhcpd.conf, il faudra renseigner la/les clé(s) TSIG à utiliser.

Pour mettre à jour la/les zone(s) directe et reverse(s) par DHCP, il convient de renseigner dans le fichier named.conf (donc bind) la déclaration allow-update { key <Nom de la clé>; } pour chacune des zones concernées.

# Clef partagee dhcpd et bind9

key <nom de la clé> {

algorithm hmac-md5;

secret <ICICOLLERLACLEFSECRETEGENEREE>;

};


Annexes 73

4. Déroulement du service DHCP

DHCP Discover : Demande du client d’une

découverte des serveurs DHCP disponible par

celui-ci et demande une première

configuration IP. Le client émet un message de

demande de bail IP (paquet DHCP Discover)

qui est envoyé sur le réseau avec adresse IP

source 0.0.0.0 et adresse IP destination

255.255.255.255.

DHCP Offer : Réponse du/des serveur(s) au

message DHCP Discover du client qui contient

les premiers paramètres de configuration IP.

Le(s) serveur(s) DHCP réponde(nt) en

proposant une adresse IP en fonction des

paramètres renseignés dans le fichier

« dhcpd.conf », avec une durée de bail et

l'adresse IP du serveur DHCP par le paquet

DHCP Offer.

DHCP Request : Requête du client afin de demander/renouveler son bail pour la configuration IP. Le

client sélectionne le premier paquet DHCP Offer (s'il y a plusieurs serveurs DHCP) reçue et envoie une

demande d'utilisation de cette adresse au serveur DHCP par la trame DHCP Request. Son message

comporte l'identification du serveur sélectionné, qui permet d’informer au serveur DHCP concerné

que son offre a été retenue. Tous les autres serveurs DHCP reçoivent également ce paquet et retirent

donc leurs offres.

DHCP ACK : Réponse du serveur qui valide le bail et lui transmet l’intégralité de sa configuration IP.

Le serveur DHCP sélectionné accuse la réception de la demande précédente et accorde l'adresse en

bail via le paquet DHCP ACK, celui-ci contient également des informations supplémentaires comme le

serveur DNS par défaut ou le nom du domaine par exemple. Ce bail est ensuite enregistré par le

serveur DHCP dans le fichier « dhcdp.leases » qui regroupe l’ensemble des baux affectés par celui-ci.

*Notons que l’ensemble des messages DHCP évoqués sont tous diffusés.

D’autres requêtes DHCP existent également, dont une présentation succincte est faite ci dessous :

Nom Description

DHCP Decline Le client annonce au serveur que l’adresse proposée par le DHCP Offer est déjà utilisée

DHCP NAK Réponse du serveur pour signaler au client que son bail est échu, ou si le client annonce une mauvaise configuration.

DHCP Release Le client libère son adresse IP

DHCP Inform Le client demande des paramètres locaux, il a déjà son adresse IP


Annexes 74

5. Relais DHCP

No Source Destination Protocol Info 1 0.0.0.0 255.255.255.255 DHCP DHCP Discover 2 172.16.1.253 255.255.255.255 DHCP DHCP Offer 3 0.0.0.0 255.255.255.255 DHCP DHCP Request 4 172.16.1.253 255.255.255.255 DHCP DHCP ACK

Capture sur 172.16.1.0 /24

Capture sur 172.16.0.0 /24

1. Mise en place d’un relai DHCP

Avant de mettre en place le relai DHCP sur un serveur, il convient de vérifier que celui-ci

supporte bien le protocole 802.1q et que les sous interfaces soient bien configurés pour chaque sous

réseau.

Une fois les sous interfaces créées et affectées au bon Vlan, nous pouvons entamer

l’installation et la configuration du relai DHCP. Ce dernier point s’établit via le fichier dhcp3-relay

comme suit :

No Source Destination Protocol Info

1 172.16.1.253 172.16.0.3 DHCP DHCP Discover 2 172.16.0.3 172.16.1.253 DHCP DHCP Offer 3 172.16.1.253 172.16.0.3 DHCP DHCP Request 4 172.16.0.3 172.16.1.253 DHCP DHCP ACK

# find /lib/modules/`uname -r` -name 8021q //Vérifie que le module 8021q est bien

présent dans le noyau de la distribution Linux

# modprobe 8021q //charge le module permettant la prise en charge des trames

taggés

# aptitude install vlan //installation de l’outil de configuration de VLAN

# vconfig add <interface> <N° Vlan> //permet d’ajouter une sous interface prenant

en charge le N° de VLAN donné pour une interface donnée

# ifconfig eth0.<N° Vlan> <172.X.Y.Z/24> //configuration IP de la sous interface

# Adresses des serveurs DHCP auquel seront transféré les requêtes

SERVERS="172.16.0.3 172.16.0.4"

# Définit les interfaces d’écoute (Si aucune interface renseignée, alors toute les

interfaces sont utilisés)

INTERFACES=""

# Définit les options additionnelles (se référer au manuel de dhcp3-relay)

OPTIONS=""


Annexes 75

6. Fichiers de configuration

dhcpd.conf

Orsay [ORS-SRV-DHCP1]

Orsay [ORS-SRV-DHCP2]

#sample dhcpd.conf file


server-name "ors-srv-dhcp1.vsn-aristote.lan";

option domain-name "vsn-aristote.lan";

option domain-name-servers 172.16.0.5,

172.16.0.6;

ping-check = 1;

default-lease-time 3600;

max-lease-time 7200;

authoritative;

log-facility local7;


failover peer "dhcp-failover-orsay" {

primary; # declare this to be the primary

server

address 172.16.0.3;

port 647;

peer address 172.16.0.4;

peer port 647;

max-response-delay 30;

max-unacked-updates 10;

load balance max seconds 3;

mclt 1800;

split 128;

}

#sample dhcpd.conf file


server-name "ors-srv-dhcp2.vsn-aristote.lan";

option domain-name "vsn-aristote.lan";

option domain-name-servers 172.16.0.5,

172.16.0.6;

default-lease-time 3600;

max-lease-time 7200;

ping-check = 1;

authoritative;

log-facility local7;

failover peer "dhcp-failover-bayonne" {

secondary; # declare this to be the

primary server

address 172.16.0.3;

port 647;


peer port 647;



}

include "/etc/dhcp3/dhcpd.master.orsay";

include

"/etc/dhcp3/dhcpd.master.bayonne";


failover peer "dhcp-failover-orsay" {

secondary; # declare this to be the

primary server

address 172.16.0.4;

port 647;


peer port 647;



}

include "/etc/dhcp3/dhcpd.master.orsay";


Annexes 76

7. dhcpd.master.orsay

# ======== Mise a jour DDNS ========

ddns-domainname "vsn-aristote.lan";







ddns-update-style interim;

ddns-updates on;

ignore client-updates;

update-static-leases on;

key dhcpupdate {

algorithm hmac-md5;

# secret ICICOLLERLACLEFSECRETEGENEREE;

};

zone 0.16.172.in-addr.arpa. {

primary 172.16.0.5;

key dhcpupdate;

}


primary 172.16.0.5;

key dhcpupdate;

}

…


primary 172.16.0.5;

key dhcpupdate;

}

zone vsn-aristote.lan. {

primary 172.16.0.5;

key dhcpupdate;

}

# ======== Reseaux ========

shared-network Orsay {

subnet 172.16.0.0 netmask 255.255.255.0 {



pool {

range 172.16.0.50 172.16.0.200;

failover peer "dhcp-failover-orsay";

}

}

subnet 172.16.1.0 netmask 255.255.255.0 {



pool {

range 172.16.1.50 172.16.1.200;

failover peer "dhcp-failover-

orsay";

}

}

…

subnet 172.16.5.0 netmask 255.255.255.0 {



pool {

range 172.16.5.50 172.16.5.200;

failover peer "dhcp-failover-

orsay";

}

}

}


Annexes 77

4. Configuration du DNS BIND9 (Rudy Promé)

1. Configuration serveur Maître

Fichier name.conf

On y spécifie le nom de domaine de notre client et le fichier contenant les enregistrements de la

zone, ainsi que quelques options.

Fichier de zone vsn-aristote.lan.hosts

Voici donc le fichier de zone créé manuellement. Dans les hôtes enregistrés manuellement, on y

ajoutera les quatre serveurs DNS Esclaves via un enregistrement NS comme pour l’enregistrement du

serveur Maître ci-dessus. On peut également ajouter des Alias via un enregistrement CNAME.


Annexes 78

2. Configuration serveur Esclave

On retrouve la même méthode pour l’installation. La configuration quant à elle s’avère quelque peu

différente puisqu’il faut lui indiquer qu’il dépend du serveur Maître. Sur le serveur Esclave, dans le

fichier /etc/bind/named.conf.local, on lui indique qu’il est donc Esclave et qu’il doit importer les

zones du serveur Maître comme suit :

Zone « vsn-aristote.lan » { // Nom de la zone

Type slave ; // On lui indique qu’il est Esclave

File « vsn-aristote.lan.hosts ; // Quel est le fichier de zone

Masters { 172.16.0.5 ; } ; // Il importe les zones du serveur Maître

} ;

On l’autorise ensuite à renvoyer des notifications vers le serveur Maître en ajoutant la ligne suivante

dans le fichier /etc/bind/named.conf.options : allow-notify { 172.16.0.5 ; } ;

Côté Maître, il y a également des modifications à effectuer pour lui informer qu’il doit mettre à jour

son serveur Esclave dynamiquement. Lors de l’étape précédente, nous avons autoriser l’envoie de

notifications depuis le serveur Esclave, il faut donc sur le serveur Maître autoriser les notifications.

Dans /etc/bind/named.conf, dans la zone correspondante on ajoute la fonction « notify yes ; ».

Dans le fichier de zone vsn-aristote.lan.hosts, on ajoute l’enregistrement du serveur DNS Esclave.

Enfin, on ajoute une ligne dans le fichier /etc/bind/named.conf.options qui permet d’autoriser le

transfert de zone : allow-transfer { 172.16.0.6 ; } ; (adresse IP du serveur Esclave d’Orsay).

3. Phases de tests DNS

Après la configuration des serveurs et des postes clients, pour s’assurer du bon fonctionnement des

serveurs Bind9, nous avons à notre disposition plusieurs commandes Unix.

La commande Ping : ping nomdelamachine. Permet de tester la résolution du nom.

La commande Nslookup : nslookup nomdelamachine. Permet également de test la résolution du nom

et renseigne quel serveur DNS a été utilisé.

La commande Dig : dig nomduserveur. Permet d’interroger les serveurs Bind et obtenir des

informations.


Annexes 79

5. Configuration matérielle des serveurs de fichiers (Jérôme

Delahaie)

Serveur :

Base PowerEdge M610 Blade Server, Intel 55xx/56xx Processors Support

Processeur supplémentaire

No Additional Processor

Mémoire 4GB Memory for 1 CPU, DDR3, 1333MHz (2x2GB Single Ranked UDIMMs)

Documents de livraison

Info: Shipping Material, Individual Blade, PowerEdge M610

Garantie de base 3Yr Basic Warranty - Next Business Day - Minimum Warranty

Services de support technique

3 ans de garantie de base - Intervention le jour ouvrable suivant incluse - Aucune extension de garantie sélectionnée

Installation professionnelle

Installation de serveur en option - non sélectionnée (contacter un ingénieur commercial pour tout complément d‘information)

Gestion des systèmes Dell OpenManage Kit for PowerEdge M610 Blade Server

Documentation M610 EMEA1 Shipping Documentation (English/French/German/Spanish/Russian/Hebrew)

Informations sur la commande

PowerEdge Order - France

Documentation en option

Edocs OEM

Processeur Intel Xeon L5609, 4C, 1.86Ghz, 12M Cache, 4.80GT/s, 40W TDP, Memory runs at 800MHz Max

Système d‘exploitation installé en usine

No Operating System

Type de carte réseau intégrée (Structure A)

Onboard Broadcom 5709 Dual Port 1GbE NIC with TOE

Extensions des services de support technique

Extension à 5 ans de la garantie disque dur SATA

Connectivité Raid C2 - No RAID using SAS 6/iR, 1-2 SAS or SATA HDDs

1er disque dur 250GB, SATA, 2.5-in, 7.2K RPM Hard Drive (Hot Plug)

TOTAL ( ) :1 494,00 €


Annexes 80

Baie :

Base PowerVault MD1220 SAS

Documents de livraison MD1220 EMEA1 Ship and Docs No Cord

Garantie de base 3Yr Basic Warranty - Next Business Day - Minimum Warranty

Services de support technique

3 ans de garantie de base - Intervention le jour ouvrable suivant incluse - Aucune extension de garantie sélectionnée

Installation professionnelle

Aucun service d‘installation

Gestion de systèmes OpenManage Factory Install and DVD

Rails de montage de rack Rapid Rack Rails for Dell or other Square Hole Rack

Informations sur la commande

Power Vault Order - France

Cordon d‘alimentation Spare Power Cord 2F

1ère carte contrôleur RAID ou SCSI

PERC H800A Controller Card

Module de gestion du boîtier (EMM)

PV MD12XX Additional Enclosure Management Module

Cadre avant MD1220 Bezel

Bloc d‘alimentation Redundant Power Supply (2 PSU) 600W

Eerste harde schijf (7) 600GB SAS 6Gbps 10k 2.5" HD

Eerste harde schijf (17) Blank HD Filler

TOTAL ( ) :9 175,00 €


Annexes 81

6. Serveur de sauvegarde (Arnaud Hamon)

Installation du serveur :

Pré-requis : Debian 64Bits

srv-backup# apt-get install backuppc

Accès à l’interface WEB du serveur :

Au préalable, il faut configurer l’authenfication au serveur WEB.

srv-backup# htpasswd –c /etc/backuppc/htpasswd backuppc

Ici, l’utilisateur est appelé « backuppc ». Un mot de passe sera à configurer.

http://ipduserveur/backuppc

Configuration ssh entre client/serveur

On va utiliser le même utilisateur pour effectuer les sauvegardes qui sera backuppc. On va générer

les clés publiques privées de type rsa avec cette utilisateur.

srv-backup# ssh-keygen –t rsa

Pour ne pas rencontrer de problèmes de droits lors des sauvegardes, copié la clé publique dans le

fichier authorized_keys dans le dossier /root/.ssh du compte root.

srv-backup# scp /var/lib/backuppc/.ssh/id_rsa.pub root@IPclient:/tmp

Puis il faut rajout le contenu de ce fichier au authorized_keys.

srv-backup# cat /tmp/id_rsa.pub >> /root/.ssh/authorized_keys

Toute fois, au connexion ssh est nécessaire une fois du serveur de sauvegarde vers le client.

Configuration d’une machine client sous linux

La commande rsync étant passée par le client, il faut installer le packages sur le client.

srv-backup# apt-get install rsync

Une fois le serveur de sauvegarde et le client prés à communiquer, il faut maintenant configurer le

serveur de sauvegarde afin de configurer le client et les options de sauvegarde via l’interface WEB.

Configuration d’un client sur backuppc

Par défaut, chaque client pointe sur la même configuration /etc/backuppc/config.pl. C’est lorsque

l’on apporte des modifications au configuration de base qu’un script perl est généré (nomduclient.pl)

et ne contient que les modifications.

Exemple de fichier de modification

http://ipduserveur/backuppc


Annexes 82

$Conf{RsyncShareName} = [ #Répertoire à sauvegarder '/etc/nagios3' ]; #Méthode de sauvegarde $Conf{XferMethod} = 'rsync'; #Intervalle entre 2 sauvegarde complète $Conf{FullPeriod} = '6.97'; #Période Durant lequel les sauvegardes ne peuvent avoir lieu. $Conf{BlackoutPeriods} = [ { 'hourEnd' => '18', 'weekDays' => [ '1', '2', '3', '4', '5' ], 'hourBegin' => '7' } ];


Annexes 83

7. Configuration du serveur Squid (fichier server.conf)

(Bastien Gayral)

# Ports en écoute

port 443

# TCP or UDP server?

proto udp

# Type d'interface réseau virtuelle créée

dev tun

# Nom des fichiers servant à l'authentification des clients via OpenSSL

ca ca.crt

cert VPN-SERVER.crt

key VPN-SERVER.key # This file should be kept secret

dh dh1024.pem

tls-auth ta.key 0

# Adresse du réseau virtuel (Le serveur aura l'adresse 10.0.0.2)

server 10.0.0.0 255.255.255.0

# Maintain a record of client <-> virtual IP address

# associations in this file. If OpenVPN goes down or

# is restarted, reconnecting clients can be assigned

# the same virtual IP address from the pool that was

# previously assigned.

ifconfig-pool-persist ipp.txt

# Push routes to the client to allow it

# to reach other private subnets behind

# the server. Remember that these

# private subnets will also need

# to know to route the OpenVPN client

# address pool (10.8.0.0/255.255.255.0)

# back to the OpenVPN server.

push "route 192.168.1.0 255.255.255.0"

# Les clients peuvent se voir

client-to-client

keepalive 10 120

# Activation de la compression

comp-lzo

# uset et group pour le processus

user openvpn

group openvpn

# Ces lignes permettent de rendre persistante la connexion

persist-key

persist-tun

# Output a short status file showing

# current connections, truncated

# and rewritten every minute.

status openvpn-status.log


Annexes 84

# Niveau de log

verb 1

Configuration des clients nomades :

client

nobind

tls-client

cipher DES-CBC

dev tun

float

pull

comp-lzo

verb 4

#http-proxy X.X.X.X 8080

#http-proxy Y.Y.Y.Y 3128 /etc/openvpn/pwd basic

status /var/state/openvpn.status

#remote Z.Z.Z.Z

remote votre-domaine.com

dev tun0

proto tcp

port 443

ca /etc/openvpn/keys/ca.crt

key /etc/openvpn/keys/client1.key

cert /etc/openvpn/keys/client1.crt


Annexes 85

8. Commande Iptables (Vincent Desseaux)

iptables <-t table> commande <correspondance> <cible/saut>

Option Explication

-A, --append Cette commande ajoute une règle à la fin d'une chaîne. La règle sera donc placée en dernière position dans la table de règles, et par conséquent vérifiée en dernier.

-D, --delete Cette commande supprime une règle dans une chaîne.

-R, --replace Cette commande remplace la règle présente à la ligne indiquée.

-I, --insert Cette commande insère une règle quelque-part dans une chaîne. La règle est insérée à l'emplacement donné par le numéro spécifié.

-L, --list Cette commande dresse la liste des entrées de la chaîne donnée.

-F, --flush Cette commande vide la chaîne donnée de toutes ses règles.

-Z, --zero Cette commande permet de mettre à zéro tous les compteurs dans une chaîne spécifique ou dans toutes les chaînes.

-N, --new-chain Cette commande permet de créer une nouvelle chaîne avec le nom indiqué dans la table spécifiée.

-X, --delete-chain Cette commande efface de la table la chaîne spécifiée.

-P, --policy Cette commande indique au noyau de configurer une cible par défaut - ou une stratégie - sur une chaîne. Ceci conditionne le comportement par défaut de la chaîne. Les paquets qui n'établissent de correspondance avec aucune règle sont contraintes de suivre la stratégie de la chaîne (DROP ACCEPT)

-E, --rename-chain La commande -E stipule à iptables de modifier le nom d'une chaîne du premier nom vers le second.


Annexes 86

9. Règle de filtrage (Vincent Desseaux)

Règle Action IP source IP dest Protocole Port source Port dest

1 2 3 4 5 6

Accept Any 10.0.0.0/8

(DMZ) udp/tcp Any

80 (http) 443 (https)

20 (ftp-data) 21 (ftp-control)

22 (ssh) 1194 (vpn)

7 8 9

10 11 12

Accept 10.0.0.0/8

(DMZ) Any udp/tcp



22 (ssh)

1194 (vpn)

Any

13 14 15 16 17 18

Accept 172.16.0.0/16 172.20.0.0/16 (LAN-Orsay)

Any udp/tcp Any



22 (ssh) 53(DNS)

19 20 21 22 23 24

Accept Any 172.16.0.0/16 172.20.0.0/16 (LAN-Orsay)

udp/tcp



22 (ssh) 53(DNS)

Any

25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

Accept 172.16.0.0/16 172.20.0.0/16 (LAN-Orsay)

172.17.0.0/16 172.18.0.0/16 172.19.0.0/16 (LAN-Sites

Annexe)

udp/tcp


22 (ssh) 53(DNS)

67 (DHCP-Server)

80 (http) 88 (Kerberos) 161 (SNMP) 443 (https)

647 (Failover DHCP)

749 (Kerberos administration) 750 (Kerberos

Authentification) 873 (rsync)

5666 (Nagios)

12486 (Nagios)

Any


Annexes 87

Règle Action IP source IP dest Protocole Port source Port dest

41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

Accept

172.17.0.0/16 172.18.0.0/16 172.19.0.0/16 (LAN-Sites

Annexe)

172.16.0.0/16 172.20.0.0/16 (LAN-Orsay)

udp/tcp Any


22 (ssh) 53(DNS)

67 (DHCP-Server)

80 (http) 88 (Kerberos) 161 (SNMP) 443 (https)

647 (Failover DHCP)

749 (Kerberos administration) 750 (Kerberos

Authentification) 873 (rsync)

5666 (Nagios)

12486 (Nagios) 56 Deny Any Any Any Any Any


Annexes 88

10. Mise en place d’un serveur Nagios sur une Debian

(Arnaud Hamon)

Installation solution Nagios:

srv-nagios# apt-get install nagios3 srv-nagios# htpasswd –c /etc/nagios3/htpasswd.users nagiosadmin

Une fois cette opération faite, le serveur de monitoring est opérationnel. Il faudra maintenant

réaliser les configurations des équipements à superviser.

4. Mise ne place de PnP4Nagios

Installation de la solution PnP4Nagios:

PnP4Nagios utilise les bases de données rrd, certains pré-requis sont à installer sur le serveur afin de

permettre l’installation de la solution.

Prérequis

srv-nagios# apt-get install gcc make srv-nagios# apt-get -y install librrds-perl php5-gd rrdtool

Installation

srv-nagios# wget http://downloads.sourceforge.net/project/pnp4nagios/PNP-0.6/pnp4nagios-0.6.10.tar.gz?r=http%3A%2F%2Fdocs.pnp4nagios.org%2Ffr%2Fpnp-0.6%2Fdoc_complete&ts=1294504162&use_mirror=freefr srv-nagios# tar –xzvf pnp4nagios-0.6.7 srv-nagios# cd pnp4nagios-0.6.7 srv-nagios#./configure srv-nagios# make all srv-nagios# make fullinstall

Paramètres de nagios pour pnp4nagios en mode synchronisé

Le mode synchronisé permet de réaliser jusqu’à 1000 services avec un intervalle de check toutes les

5 minutes. Sachant que on contrôle 10 métriques par serveur, et que notre volumétrie ne dépassera

pas 100 serveurs, ce mode de fonctionnement est adapté aux besoins.

Voici les modifications à apporter au fichier nagios.cfg

process_performance_data=1 service_perfdata_command=process-service-perfdata host_perfdata_command=process-host-perfdata


Annexes 89

Modifications apportées au fichier commands.cfg

define command { command_name process-service-perfdata command_line /usr/bin/perl /usr/local/pnp4nagios/libexec/process_perfdata.pl } define command { command_name process-host-perfdata command_line /usr/bin/perl /usr/local/pnp4nagios/libexec/process_perfdata.pl -d HOSTPERFDATA }

Mise en place des redirections sur l’interface WEB

define host { name host-pnp register 0 action_url /pnp4nagios/graph?host=$HOSTNAME$ } define service { name srv-pnp register 0 action_url /pnp4nagios/graph?host=$HOSTNAME$&srv=$SERVICEDESC$ }

Modification htpasswd.users du fichier conf apache pnp4nagios.conf

Spécificités de configuration

Il se peut que certaines options soit à modifier afin que les graphes de performances fonctionnent tel

que

- Dans php.ini, magic_quotes_gpc en mode Off.

- Ou bien certains commandes à passer

srv-nagios# a2enmod rewrite

Afin d’optimiser notre serveur, les équipements réseau seront supervisés avec du SNMP et les

serveurs seront supervisés à l’aide d’agent (Permet de réduire la charge du serveur Nagios et limiter

au maximum l’utilisation de bande passante).

[MIR LINUX] - jerome.teneur.free.frjerome.teneur.free.fr/ressources/mir/MIR_4_linux.pdf · Delahaie...

Documents

Transcript of [MIR LINUX] - jerome.teneur.free.frjerome.teneur.free.fr/ressources/mir/MIR_4_linux.pdf · Delahaie...