[mir linux] - jerome.teneur.free.frjerome.teneur.free.fr/ressources/mir/mir_4_linux.pdf · delahaie...
TRANSCRIPT
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
[MIR LINUX] MediaNetWork
Introduction (Jérôme TENEUR) 3
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
1. Rappel des besoins ................................................................................................................ 25
2. Solution que nous proposons ................................................................................................ 25
[MIR LINUX] MediaNetWork
Introduction (Jérôme TENEUR) 4
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
1. Rappel des besoins ................................................................................................................ 35
2. Comparatif ............................................................................................................................ 35
3. Solution retenue ................................................................................................................... 36
1. Architecture de fonctionnement ........................................................................................ 36
[MIR LINUX] MediaNetWork
Introduction (Jérôme TENEUR) 5
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. Rappel des besoins ................................................................................................................ 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
[MIR LINUX] MediaNetWork
Introduction (Jérôme TENEUR) 6
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
[MIR LINUX] MediaNetWork
Introduction (Jérôme TENEUR) 7
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
[MIR LINUX] MediaNetWork
Introduction (Jérôme TENEUR) 8
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.
[MIR LINUX] MediaNetWork
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.
[MIR LINUX] MediaNetWork
Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 10
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).
[MIR LINUX] MediaNetWork
Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 11
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
[MIR LINUX] MediaNetWork
Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 12
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
[MIR LINUX] MediaNetWork
Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 13
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------- 1 openldap openldap 2629632 jan 9 03:16 __db.002
-rw------- 1 openldap openldap 98304 jan 9 03:16 __db.003
-rw-r--r-- 1 openldap openldap 96 jan 3 18:47 DB_CONFIG
[…]
# LDAP
slapd_enable="YES"
slapd_flags="-h ldap:///"
[MIR LINUX] MediaNetWork
Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 14
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.
[MIR LINUX] MediaNetWork
Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 15
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.
[MIR LINUX] MediaNetWork
Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 16
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.
[MIR LINUX] MediaNetWork
Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 17
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.
[MIR LINUX] MediaNetWork
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.
[MIR LINUX] MediaNetWork
Le serveur de configuration IP (Vincent Desseaux) 19
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
[MIR LINUX] MediaNetWork
Le serveur de configuration IP (Vincent Desseaux) 20
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.
[MIR LINUX] MediaNetWork
Le serveur de configuration IP (Vincent Desseaux) 21
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.
[MIR LINUX] MediaNetWork
Le serveur de configuration IP (Vincent Desseaux) 22
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
[MIR LINUX] MediaNetWork
Le serveur de configuration IP (Vincent Desseaux) 23
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.
[MIR LINUX] MediaNetWork
Le serveur de configuration IP (Vincent Desseaux) 24
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.
[MIR LINUX] MediaNetWork
Résolution de noms IP (Rudy Promé) 25
4. Résolution de noms IP (Rudy Promé)
1. Rappel des besoins
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.
[MIR LINUX] MediaNetWork
Résolution de noms IP (Rudy Promé) 26
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
[MIR LINUX] MediaNetWork
Résolution de noms IP (Rudy Promé) 27
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.
[MIR LINUX] MediaNetWork
Résolution de noms IP (Rudy Promé) 28
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
[MIR LINUX] MediaNetWork
Résolution de noms IP (Rudy Promé) 29
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.
[MIR LINUX] MediaNetWork
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.
[MIR LINUX] MediaNetWork
Le serveur de ressources (Jérôme Delahaie) 31
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
[MIR LINUX] MediaNetWork
Le serveur de ressources (Jérôme Delahaie) 32
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.
[MIR LINUX] MediaNetWork
Le serveur de ressources (Jérôme Delahaie) 33
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.
[MIR LINUX] MediaNetWork
Le serveur de ressources (Jérôme Delahaie) 34
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
[MIR LINUX] MediaNetWork
Système de sauvegarde (Arnaud Hamon) 35
6. Système de sauvegarde (Arnaud Hamon)
1. Rappel des besoins
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
[MIR LINUX] MediaNetWork
Système de sauvegarde (Arnaud Hamon) 36
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.
[MIR LINUX] MediaNetWork
Système de sauvegarde (Arnaud Hamon) 37
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.
[MIR LINUX] MediaNetWork
Système de sauvegarde (Arnaud Hamon) 38
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.
[MIR LINUX] MediaNetWork
Système de sauvegarde (Arnaud Hamon) 39
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
SauvegardeIncrémentielle
SauvegardeIncrémentielle
SauvegardeIncrémentielle
SauvegardeIncrémentielle
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
[MIR LINUX] MediaNetWork
Système de sauvegarde (Arnaud Hamon) 40
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.
[MIR LINUX] MediaNetWork
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. Rappel des besoins
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é
[MIR LINUX] MediaNetWork
Le serveur web et l'accès internet sécurisé (Bastien Gayral) 42
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
[MIR LINUX] MediaNetWork
Le serveur web et l'accès internet sécurisé (Bastien Gayral) 43
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).
[MIR LINUX] MediaNetWork
Le serveur web et l'accès internet sécurisé (Bastien Gayral) 44
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.
[MIR LINUX] MediaNetWork
Le serveur web et l'accès internet sécurisé (Bastien Gayral) 45
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.
[MIR LINUX] MediaNetWork
Le serveur web et l'accès internet sécurisé (Bastien Gayral) 46
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.
[MIR LINUX] MediaNetWork
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.
[MIR LINUX] MediaNetWork
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.
[MIR LINUX] MediaNetWork
Serveur VPN (Bastien Gayral) 49
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.
[MIR LINUX] MediaNetWork
Serveur VPN (Bastien Gayral) 50
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.
[MIR LINUX] MediaNetWork
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.
[MIR LINUX] MediaNetWork
Infrastructure global (Jérôme TENEUR) 52
11. Infrastructure global (Jérôme TENEUR)
[MIR LINUX] MediaNetWork
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
[MIR LINUX] MediaNetWork
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://datatracker.ietf.org/doc/rfc2131/
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://datatracker.ietf.org/doc/rfc2132/
http://www.delafond.org/traducmanfr/man/man5/dhcp-options.5.html
Relai DHCP
http://datatracker.ietf.org/doc/rfc3046/
http://www.linux-france.org/prj/edu/archinet/systeme/ch27s06.html
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://datatracker.ietf.org/doc/rfc3074/
http://www.lithodyne.net/docs/dhcp/dhcp.html
[MIR LINUX] MediaNetWork
Bibliographie 55
DNS
http://www.zimbrafr.org/forum/topic/1464-tutoriel-installationconfiguration-bind-et-zimbra/
http://www.coagul.org/spip.php?article185
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
[MIR LINUX] MediaNetWork
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://uid.free.fr/Ldap/ldap.html
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
[MIR LINUX] MediaNetWork
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.
[MIR LINUX] MediaNetWork
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.
[MIR LINUX] MediaNetWork
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.
[MIR LINUX] MediaNetWork
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.
[MIR LINUX] MediaNetWork
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=*)"
[MIR LINUX] MediaNetWork
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
[MIR LINUX] MediaNetWork
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
[MIR LINUX] MediaNetWork
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
RI Format E 123 (cf Références)
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
RI Format E 123 (cf Références)
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 ?
[MIR LINUX] MediaNetWork
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"
;;
[MIR LINUX] MediaNetWork
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
[MIR LINUX] MediaNetWork
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
[MIR LINUX] MediaNetWork
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
[MIR LINUX] MediaNetWork
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)
[MIR LINUX] MediaNetWork
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;
}
}
}
[MIR LINUX] MediaNetWork
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 {
option broadcast-address 172.16.1.255;
option routers 172.16.1.254;
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";
ddns-rev-domainname "1.16.172.in-addr.arpa";
ddns-rev-domainname "2.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;
[MIR LINUX] MediaNetWork
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>;
};
[MIR LINUX] MediaNetWork
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
[MIR LINUX] MediaNetWork
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=""
[MIR LINUX] MediaNetWork
Annexes 75
6. Fichiers de configuration
dhcpd.conf
Orsay [ORS-SRV-DHCP1]
Orsay [ORS-SRV-DHCP2]
#sample dhcpd.conf file
# ======== Option Generales du dhcp ========
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 configuration ========
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
# ======== Option Generales du dhcp ========
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 address 172.17.0.3;
peer port 647;
max-response-delay 30;
max-unacked-updates 10;
}
include "/etc/dhcp3/dhcpd.master.orsay";
include
"/etc/dhcp3/dhcpd.master.bayonne";
# ======== Failover configuration ========
failover peer "dhcp-failover-orsay" {
secondary; # declare this to be the
primary server
address 172.16.0.4;
port 647;
peer address 172.16.0.3;
peer port 647;
max-response-delay 30;
max-unacked-updates 10;
}
include "/etc/dhcp3/dhcpd.master.orsay";
[MIR LINUX] MediaNetWork
Annexes 76
7. dhcpd.master.orsay
# ======== Mise a jour DDNS ========
ddns-domainname "vsn-aristote.lan";
ddns-rev-domainname "0.16.172.in-addr.arpa";
ddns-rev-domainname "1.16.172.in-addr.arpa";
ddns-rev-domainname "2.16.172.in-addr.arpa";
ddns-rev-domainname "3.16.172.in-addr.arpa";
ddns-rev-domainname "4.16.172.in-addr.arpa";
ddns-rev-domainname "5.16.172.in-addr.arpa";
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;
}
zone 1.16.172.in-addr.arpa. {
primary 172.16.0.5;
key dhcpupdate;
}
…
zone 5.16.172.in-addr.arpa. {
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 {
option broadcast-address 172.16.0.255;
option routers 172.16.0.254;
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 {
option broadcast-address 172.16.1.255;
option routers 172.16.1.254;
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 {
option broadcast-address 172.16.5.255;
option routers 172.16.5.254;
pool {
range 172.16.5.50 172.16.5.200;
failover peer "dhcp-failover-
orsay";
}
}
}
[MIR LINUX] MediaNetWork
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.
[MIR LINUX] MediaNetWork
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.
[MIR LINUX] MediaNetWork
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 €
[MIR LINUX] MediaNetWork
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 €
[MIR LINUX] MediaNetWork
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
[MIR LINUX] MediaNetWork
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' } ];
[MIR LINUX] MediaNetWork
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
[MIR LINUX] MediaNetWork
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
[MIR LINUX] MediaNetWork
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.
[MIR LINUX] MediaNetWork
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
80 (http) 443 (https)
20 (ftp-data) 21 (ftp-control)
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
80 (http) 443 (https)
20 (ftp-data) 21 (ftp-control)
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
80 (http) 443 (https)
20 (ftp-data) 21 (ftp-control)
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
20 (ftp-data) 21 (ftp-control)
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
[MIR LINUX] MediaNetWork
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
20 (ftp-data) 21 (ftp-control)
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
[MIR LINUX] MediaNetWork
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
[MIR LINUX] MediaNetWork
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).