Projet
Administration Réseau :
Parc
informatique
d’une entreprise
SOMMAIRE
I. Introduction... 3
II. Etude preliminaire ... 3
1. Rappel du problème ... 3
2. Tâches à réaliser... 3
3. Organisation du travail, répartition des tâches, planning... 5
III. Mise en oeuvre ... 6
1. Moyens disponibles, moyens employés... 6
2. Démarche ... 6
3. Procédures d’installation... 7
4. Principaux problèmes rencontrés ... 23
IV. Conclusion ... 37
V. Annexes... 38 1. création d'un compte en R&D... ? 2. ajout d'un compte en Commerce... ? 3. ajout d'une machine en R&D ... ? 4. ajout d'une machine en Commerce ... ? 5. restauration d'un poste client unix... ? 6. restauration des données utilisateur R&D... ? 7. restauration des données utilisateur Commerce... ? 8. restauration d'un poste utilisateur Commerce ... ? 9. actions à mener en cas de crash du contrôleur de domaine/passerelle Commerce ... ?
I. I NTRODUCTION
Dans ce projet, il est question de répondre à la demande d’une entreprise concernant la mise en place de son architecture système et réseau. Une telle mise en place ne se prend pas à la légère, et nécessite une certaine rigueur. Nous allons donc tout d’abord mener une étude préalable qui nous conduira à une réflexion plus poussée concernant le déploiement d’une solution au travers d’une maquette. Une fois celle-ci pleinement fonctionnelle, et les procédures correctement rédigées, nous pourrons par la suite envisager de présenter et mettre en œuvre notre solution auprès de cette entreprise.
II. E TUDE PRELIMINAIRE
1. Rappel du problème
Ce projet consiste en la mise en place d’une maquette du parc informatique d’une entreprise.
Celle-ci est divisée en trois services : le service informatique, le service commercial, le service de recherche et développement.
Le service informatique, sous linux, est responsable du serveur d’entrée ainsi que d’un DNS, un proxy web, un serveur postfix, un DHCP, et un firewall.
Le service recherche et développement dispose d’un parc mixte FreeBSD / W2K et dispose de serveur DNS, DHCP, serveur web, NIS, NFS.
Le service commercial, lui, est entièrement sous Windows, dans un domaine Windows à lui.
Il fournit des services DNS, relais DHCP, et contrôleur de domaine.
Tous ces services incluent également un serveur de sauvegardes (celui du service informatique regroupant également les informations des deux autres) et chacun disposent d’un serveur servant de passerelle vers le réseau interne, et, pour le service informatique, vers l’extérieur.
2. Tâches à réaliser
Dans un premier temps il convient d’étudier un plan architectural du futur réseau (cf. page suivante), puis d’en dégager les principales problématiques, à savoir :
la constitution des passerelles, avec l’installation des services adéquats la validation de la communication inter passerelles
la constitution des stations, avec mise en place des différents clients
la validation de la communication avec la passerelle du service, puis l’extérieur
le déploiement du système de sauvegarde
3. Organisation du travail, répartition des tâches, planning
Face à l’ampleur du projet il a été nécessaire de bien s’organiser. Il nous fallait constituer deux ou trois équipes afin de prendre en charge en parallèle les trois services de l’entreprise, en planifiant des phases de test au sein de l’équipe mais également regroupant toutes les parties.
C’est donc naturellement, suivant nos affinités et nos capacités qu’il y eut la répartition suivante : Thibaut et Stéphane s’occupant du service informatique ; Youssef, Philippe et Nicolas sur la partie recherche et développement, et, Nicolas, Stéphane et Thibaut se sont penché sur le service commerce.
Cette répartition a connu quelques évolutions car Stéphane, étant plus au fait de postfix, s’est également chargé de son installation en R&D. De même, le service commerce ne disposait pas d’autant d’attention, mais au fur et à mesure, il a fallut concentrer plus d’effort autour de ce dernier, notamment pour la gestion d’Active Directory.
Nous avons aussi pensé à planifier toutes les différentes tâches que nous devrions faire de manière à tenir nos délais et pour avoir une vision plus globale du projet. De cette idée est née le diagramme de Gantt suivant :
Cependant, au cours de l’évolution de notre projet il a fallut effectuer quelques modifications et effectuer plus de tests que prévu initialement.
III. M ISE EN OEUVRE
1. Moyens disponibles, moyens employés
Concernant certaines parties du projet, nous avons eu à faire face à plusieurs choix dans différentes circonstances.
Pour l’accès de l’utilisateur Jacques Bontemps, du service R&D, aux machines Windows et Linux, nous disposions de moyens comme la mise en place d’un partage Samba, ou bien l’utilisation de Cygwin et autre SFU. Après une rapide étude de ces types de solution, et compte tenu d’une plus grande connaissance de Cygwin, nous avons donc opté pour ce type de solution, toujours dans une optique de réduction des délais (ce que l’on connaît mieux s’installe plus rapidement).
Les délais ont également beaucoup joué quand au choix dans la méthode des sauvegardes.
rsync/robocopy permettait une installation sous Windows, et semblait donc convenir à notre réseau hétérogène. De même les snapshot (par contre limité à un environnement Linux) jouissaient de l’avantage de la simplicité d’utilisation, mais pas de la mise en œuvre. Ce qui nous a amené à envisager un autre type de solution, moins coûteux en temps, mais également moins
« professionnel » : l’archivage des machines, et l’utilisation de scripts Shell pour coordonner le tout.
Concernant les droits de l’utilisateurs Jean Bouty sur les sauvegardes, il aurait pu être question de l’utilisation de SUDO afin de lui donner les permissions nécessaires, mais nous avons trouvé qu’il était plus adapté (pour notre démarche de sauvegarde choisie) de créer un utilisateur spécial sur la machine de sauvegarde, et donc, par SSH et le mécanisme des clés publiques et privées, de donner l’accès à Jean Bouty seulement. De plus, par un simple changement de clés, d’autres utilisateurs peuvent remplacer Jean Bouty sans rien changer de fondamental à notre mécanisme.
2. Démarche
Une fois réunis les moyens et les plans de mise en œuvre, il nous restait à convenir d’une démarche qui devait être la plus rigoureuse possible, mais en même temps efficace et rapide. De par nos différentes expériences de projets antérieurs, nous n’avons pas tardé à adopter une mise en œuvre progressive, avec :
1°) la mise en place d’un service à la fois
2°) une phase de tests (au sein du sous-réseau auquel il appartenait, mais aussi avec l’ensemble de l’environnement de projet) qui, en cas de bug, est suivi d’une phase de correction
3°) sa validation (généralement par un snapshot avec vmware, de manière à toujours retomber sur un environnement le plus stable et le plus récent possible en cas de loupé)
Le tout étant conçu de telle manière à pouvoir « cloisonner » ce qui est en cours de mise en place de ce qui est déjà fait (et donc plus à refaire). Ceci nous as ainsi permit à maintes reprises d’échapper à une réinstallation complète ou partielle de machines, et donc d’avancer plus rapidement tout en nous concentrant totalement sur la problématique en cours.
3. Procédures d’installation
A. Parc du service informatique Serveur DNS
a. Installation du serveur DNS sur pas b. Configuration du serveur DNS Serveur SMTP
La machine pas en relais SMTP
La machine web en serveur SMTP de courrier local Passerelle
Serveur DHCP
a. Installation du serveur DHCP sur pas b. Configuration du serveur DHCP Pare-feux
Sauvegarde Restauration Proxy
B. Parc du service commercial Généralités
Contrôleur de domaine (primaire/secondaire) Serveur DNS
Serveur de fichiers Relais DHCP
Serveur de sauvegarde
C. Parc du service recherche et développement Généralités
Serveur DNS Serveur web
Serveurs SSH NFS
a. Présentation du service
b. Configuration du serveur NFS c. Configuration du client NFS Sauvegarde
NIS
a. Présentation du service « Services d'information réseau » b. Configuration du serveur NIS
c. Configuration du Clients NIS Serveur DHCP
Serveur SMTP
La machine pas en serveur SMTP de courrier local
Test du fonctionnement de POSTFIX dans les différents services
A. Parc du service informatique
Les machines du service informatique sont le domaine DNS g3.test.shayol.org
La machine pas est serveur DNS de l’ensemble de l’entreprise. Ces machines sont toutes sous DEBIAN.
La machine pas est serveur SMTP sortant : elle accepte d’expédier les courriers provenant des ordinateurs de l’entreprise à l’extérieur de l’entreprise. Elle est serveur de courrier entrant : elle accepte les courriers provenant de l’extérieur de l’entreprise et les transmet au serveur interne web.g3.test.shayol.org sauf pour le service recherche qui a son propre serveur.
La machine pas est serveur DHCP pour les machines de l’entreprise. Elles auront des adresses IP fixes.
La machine sav.g3.test.shayol.org servira de serveur de sauvegarde à toute l’entreprise : sur ses disques, on trouvera une sauvegarde de toute les machines du service informatique ainsi qu’une copie des sauvegardes réalisées sur les autres serveurs de sauvegarde. Ces sauvegardes doivent être faites automatiquement sans intervention humaine.
Des procédures de restauration des données et des systèmes depuis ces sauvegardes seront réalisées.
La machine web.g3.test.shayol.org sera le proxy WEB de l’entreprise.
Serveur DNS
La machine pas.g3.test.shayol.org est le serveur DNS pour le domaine g3.test.shayol.org.
a. Installation du serveur DNS sur pas
#apt-get install bind9
#/etc/init.d/bind9 restart: redémarre le service DNS b. Configuration du serveur DNS
Le répertoire contenant les fichiers de configurations est /etc/bind.
Le fichier named.conf contient la déclaration de la zone g3.test.shayol.org (fichier g3.hosts) et de sa zone inverse (fichier named.rev).
La déclaration des sous domaines commerce.g3.test.shayol.org et rd.g3.test.shayol.org s'effectue dans le fichier g3.hosts, il faut rajouter les lignes :
rd IN NS pas.rd.g3.test.shayol.org.
commerce IN NS srv.commerce.g3.test.shayol.org.
pas.rd.g3.test.shayol.org. IN A 192.168.213.2
srv.commerce.g3.test.shayol.org. IN A 192.168.213.3
Les champs NS permettent de savoir les noms des serveurs qui gèrent les sous domaines.
Les champs A permettent de savoir les adresses IP des serveurs.
Pour vérifier la configuration du fichier /etc/bind/named.conf
# named-checkconf
Pour vérifier les fichiers de configuration des zones
# named-checkzone g3.test.shayol.org g3.hosts
Serveur SMTP La machine pas en relais SMTP
La machine pas du service informatique sert de serveur relais SMTP entrant et sortant.
Elle accepte d'expédier les courriers provenant des ordinateurs de l'entreprise à l'extérieur.
Elle accepte les courriers provenant de l'extérieur pour les domaines g3.test.shayol.org, commerce.test.shayol.org et rd.g3.test.shayol.org.
L’installation de POSTFIX se fait avec la commande suivante :
# apt-get install postfix
Les fichiers de configurations se trouvent dans /etc/postfix.
Options importantes du fichier /etc/postfix/main.cf
#fichier de transport
transport_maps=hash:/etc/postfix/transport
#Liste des domaines pour lesquels le serveurs accepte le mail et le relais à d'autres serveurs de mail
relay_domains=g3.test.shayol.org, commerce.g3.shayol.org, rd.g3.test.shayol.org
#Le serveur SMTP auquel il faut transférer les messages non gérés par ce serveur
relayhost=guidoni.sig.univ-evry.fr
#Réseaux pour lesquels mon serveur accepte de relayer le mail mynetworks=192.168.200.0/24, 192.168.199.0/24, 192.168.213.0/24, 192.168.201.0/24, 127.0.0.0/8
Le fichier /etc/postfix/transport
Pour redistribuer les courriers provenant de l'extérieur aux serveurs internes en fonctions de chaque domaine, il faut le spécifier dans ce fichier:
//la machine web.g3.test.shayol.org stocke les mails des domaines suivants.
g3.test.shayol.org smtp:192.168.200.11
commerce.g3.test.shayol.org smtp:192.168.200.11
//la machine pas.rd.g3.test.shayol.org stocke les mails de ce domaine.
rd.g3.test.shayol.org smtp:192.168.213.2
Il faut créer la table à partir du fichier texte:
#postmap /etc/postfix/transport
Il faut dire à postfix de relire sa configuration:
#/etc/init.d/postfix reload
La machine web en serveur SMTP de courrier local
La machine web du service informatique sert de serveur de courrier local.
Elle stocke les mails des personnes appartenant aux domaines g3.test.shayol.org et commerce.g3.test.shayol.org.
Les fichiers de configurations se trouvent dans /etc/postfix.
Options importantes du fichier /etc/postfix/main.cf
#fichier contenant les adresses virtuelles virtual_maps=hash:/etc/postfix/virtual
#nom du fichier d'alias
alias_maps=hash:/etc/postfix/aliases alias_database=hash:/etc/postfix/aliases
#Liste des domaines pour lesquels le serveur accepte le mail et le délivre en local
mydestination=$myhostname,localhost.$mydomain,localhost,$mydomain,commerce.g3.test.shayol.org
#commande à exécuter pour délivrer le mail en local mailbox_command=procmail -a "$EXTENSION"
#taille maximale pour les mailbox (0=pas de limite) mailbox_size_limit=0
Le fichier /etc/postfix/virtual
Pour stocker les courriers des utilisateurs du domaine commerce.g3.test.shayol.org, il faut faire correspondre les adresses mails à des comptes locaux:
#fichier de correspondance pour les adresses virtuelles tibault@commerce.g3.test.shayol.org tibault
Il faut créer la table à partir du fichier texte:
#postmap /etc/postfix/virtual
Il faut dire à postfix de relire sa configuration:
#/etc/init.d/postfix reload
Le fichier /etc/aliases
Les alias permettent de faire la correspondance entre les adresses mails et les comptes locaux.
On utilise un compte local admin pour lire les mails.
# fichier d'alias webmaster: root postfix: root root: admin
postmaster: admin abuse: admin
Il faut générer la base de données d'alias:
# newaliases
Il faut dire à postfix de relire sa configuration:
# /etc/init.d/postfix reload
IMPORTANT:
Pour recevoir du courrier provenant de l’extérieur, il faut ajouter un enregistrement MX dans la configuration du serveur DNS.
Sur la machine pas, dans le fichier /etc/bind/g3.hosts:
g3.test.shayol.org IN MX 10 pas
Ceci permettra de router le courrier venant de l’extérieur vers la machine pas.
Passerelle
La machine pas.g3.test.shayol.org est la passerelle générale de l’entreprise.
Elle a trois cartes réseau :
Eth0 192.168.200/24 Réseau du SI
Eth1 192.168.213/24 Réseau intermédiaire Eth2 192.168.195/24 Réseau externe
La configuration des cartes réseau se fait dans le fichier /etc/network/interfaces
auto eth0
iface eth0 inet static address 192.168.200.249 netmask 255.255.255.0 network 192.168.200.0 broadcast 192.168.200.255 auto eth1
iface eth1 inet static address 192.168.213.1 netmask 255.255.255.0 network 192.168.213.0 broadcast 192.168.213.255 auto eth2
iface eth2 inet static address 192.168.195.203 netmask 255.255.255.0 network 192.168.195.0 broadcast 192.168.195.255 gateway 192.168.195.2
Il faut mettre une passerelle par défaut est sur une seule interface : eth2 en 192.168.195.2 Les trois interfaces sont en statique.
Pour que les réseaux puissent communiquer entre eux, il faut tout d’abord activer l’ip_forwarding, configurer les routes et le NAT pour accéder au web.
Voici le script /etc/passerelle.sh qui sera lancé à chaque démarrage.
#!/bin/bash
# /etc/passerelle.sh
# configuration de pas en passerelle
route add -net 192.168.199.0 netmask 255.255.255.0 gw 192.168.213.2 route add -net 192.168.201.0 netmask 255.255.255.0 gw 192.168.213.3 echo 1 > /proc/sys/net/ipv4/ip_forward.
Le fichier se lit :
La route par défaut pour le réseau 199 est la passerelle en 213.2 La route par défaut pour le réseau 201 est la passerelle en 213.3 Le NAT sera effectué plus tard dans le script du firewall.
Pour créer le lien symbolique, il faut passer par le script Debian update-rc.d :
$ update-rc.d passerelle.sh start 60 S .
Pour retirer le lien symbolique, il faut passer par le même script Debian :
$ update-rc.d -f passerelle.sh remove
Serveur DHCP
Tout d'abord, on a configuré les trois interfaces de pas en statique dans le fichier de configuration : /etc/network/interfaces.
Ensuite sur les clients web et sav, on a configuré les interfaces comme étant en dynamique dans /etc/network/interfaces :
iface eth0 inet dhcp
Pour que le client récupère les informations du serveur, il faut installer dhcp-client.
Sur Debian, il est installé par défaut.
a. Installation du serveur DHCP sur pas
Attention, sur la Debian, si on rajoute des interfaces après l’installation du serveur DHCP, ces nouvelles interfaces ne seront pas sensible aux requêtes DHCP.
Il faudra les rajouter à la main dans le fichier /etc/default/dhcp
# On what interfaces should the DHCP server requests INTERFACES="eth0 eth1"
$ apt-get install dhcp
$ apt-get remove dhcp-client
$ /etc/init.d/dhcp restart : redémarre le service DHCP
Pour vérifier le fonctionnement on a décidé de tout journaliser :
Dans /etc/syslog.conf : rajouter la ligne [*.* /var/log/fulllog]
Pour tester la demande de bail du client, sur le serveur on actualise pendant que le client configure son interface réseau :
$ tail -f /var/log/fulllog.
Le fichier de configuration de DHCP est /etc/dhcpd.conf.
b. Configuration du serveur DHCP
Il a été configuré pour fournir les adresses IP des stations web et sav suivant leurs adresses MAC.
On déclare les trois sous réseaux par subnet. Dans le subnet, on déclare un groupe contenant des noms de machine. Les options données dans le subnet seront appliquées au client déclaré. Pour chaque machine, une adresse IP est donnée en fonction de leur adresse MAC : hardware ethernet Exemple de subnet
subnet 192.168.200.0 netmask 255.255.255.0 {
group {
option routers 192.168.200.249;
option subnet-mask 255.255.255.0;
option domain-name "g3.test.shayol.org";
option domain-name-servers 192.168.200.249;
option broadcast-address 192.168.200.255;
host web {
hardware ethernet 00:0C:29:01:05:48;
fixed-address 192.168.200.11;
option host-name "web";
}
host sav {
hardware ethernet 00:0C:29:1B:1F:2F;
fixed-address 192.168.200.12;
option host-name "sav";
} }
}
Il fournit des informations comme la passerelle (pas), le DNS (pas).
Pour vérifier que ça fonctionne on redémarre le service réseau sur le client web ou sav et on vérifie que l’adresse IP attribué est correcte avec ifconfig. On peut vérifier que dans le fichier
/etc/resolv.conf on a bien récupéré les informations DNS.
Pare-feux
La configuration du pare-feux s’effectue par un script initialiser au démarrage /etc/init.d/firewall.sh
Au départ, tout efface toutes les règles et on bloque tout :
# Tout effacer iptables -F
# Tout bloquer par défaut iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
Ensuite on gère par interface réseau :
eth0 : 192.168.200.249 eth1 : 192.168.213.1 eth2 : 192.168.195.203
Sur les trois interfaces, voici les règles communes fixées : - on autorise tout ce qui est envoyé en entrée : (Exemple pour l’interface eth0)
iptables -A INPUT -i eth0 -p all -j ACCEPT
- on autorise tous ce qui transit d’une interface à une autre (excepté ce qui arrive d’internet)
iptables -A FORWARD -i eth0 -o eth1 -p all -j ACCEPT iptables -A FORWARD -i eth0 -o eth2 -p all -j ACCEPT
- on autorise en sortie l’icmp, tcp et udp sur certains ports (dhcp, smtp, imap, pop, ssh)
iptables -A OUTPUT -o eth0 -p icmp -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -m multiport --dports 22,25,110,220,143 -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp -m multiport --dports 22,25,110,220,143 -j ACCEPT
- l’interface eth2 a des accès spéciaux
# limiter en entrée au protocole courant dns,ssh,pop,imap,smtp iptables -A INPUT -i eth2 -p icmp -j ACCEPT
iptables -A INPUT -i eth2 -p tcp -m multiport --sports 22,25,110,220,143 -j ACCEPT
iptables -A INPUT -i eth2 -p udp -m multiport --sports 22,25,110,220,143 -j ACCEPT
# limiter le forward au protocole courant dns,ssh,pop,imap,smtp iptables -A FORWARD -i eth2 -o eth1 -p icmp -j ACCEPT
iptables -A FORWARD -i eth2 -o eth1 -p tcp -m multiport --sports 22,25,110,220,143 -j ACCEPT
iptables -A FORWARD -i eth2 -o eth1 -p udp -m multiport --sports 22,25,110,220,143 -j ACCEPT
iptables -A FORWARD -i eth2 -o eth0 -p icmp -j ACCEPT
iptables -A FORWARD -i eth2 -o eth0 -p tcp -m multiport --sports 22,25,110,220,143 -j ACCEPT
iptables -A FORWARD -i eth2 -o eth0 -p udp -m multiport --sports 22,25,110,220,143 -j ACCEPT
# Accepter au WEB en gérant les états
iptables -A OUTPUT -o eth2 -p tcp --dport 80 -m state --state NEW,ESTABLISHED - j ACCEPT
iptables -A INPUT -i eth2 -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT
Iptables est un pare-feux gérant les états. Ainsi, il n’acceptera en entrée sur eth2, que les trame TCP : 80 ayant déjà une connexion avec pas. Iptables enregistre les connexions établies pour gérer ce type de connexion et les filtrer.
# gérer le DNS suivant les états
iptables -A INPUT -i eth2 -p udp --sport 53 --dport 1024: -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -p udp --sport 1024: --dport 53 -m state --state ! INVALID -j ACCEPT
iptables -A INPUT -i eth2 -p tcp --sport 53 --dport 1024: -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --sport 1024: --dport 53 -m state --state ! INVALID -j ACCEPT
C’est comme pour l’accès web, iptables n’accepte en entrée ou en forward que les trames venant de connexions déjà ouvertes. Mais nous avons un problème (le pare-feux ne laisse pas passer) de ce côté-là et nous n’avons pu résoudre le problème à temps (pour les tests, nous avons du ré ouvrir TCP et UDP)
- pour permettre aux utilisateurs du réseau local d’accéder au NAT, il faut activer le NAT
iptables -A POSTROUTING -t nat -o eth2 -j SNAT --to 192.168.195.203
Pour faire nos tests, nous avons créé un script qui désactive le pare-feu : /etc/init.d/firewall-deblok.sh
Sauvegarde
La machine sav.g3.test.shayol.org sert de serveur de sauvegarde à toute l'entreprise: sur ces disques, on trouve une sauvegarde de toutes les machines du service informatique ainsi qu'une copie des sauvegardes réalisées sur les autres serveurs de sauvegarde.
Les machines web et pas effectuent leur sauvegarde et les envoi à sav périodiquement grâce à un script. Les données sont transitées avec sécurité du client au serveur grâce à un serveur SSH installé sur la machine sav.
Les sauvegardes se trouvent dans /usr/local/sauv/informatique pour les machines du domaine g3.test.shayol.org.
Les sauvegardes se trouvent dans /usr/local/sauv/commerce pour les machines du domaine commerce.g3.test.shayol.org.
Les sauvegardes se trouvent dans /usr/local/sauv/recherche pour les machines du domaine rd.g3.test.shayol.org.
Script de sauvegarde pour la machine pas.g3.test.shayol.org Le script se trouve dans /etc/sav.sh
#!/bin/sh
//sauvegarde complet du disque avec tar
tar cvfz /usr/local/pas.g3.sav.tar.gz /
//transfert de la sauvegarde sur la machine sav
scp /usr/local/pas.g3.sav.tar.gz
root@sav.g3.test.shayol.org:/usr/local/sauv/informatique
//suppression du fichier en local pour libérer de l’espace disque
rm /usr/local/pas.g3.sav.tar.gz
La crontab pour la machine pas.g3.test.shayol.org
La sauvegarde s’effectue une fois par semaine le dimanche à 19h00
0 19 * * 0 root /etc/sav.sh
Proxy
La machine web.g3.test.shayol.org est le Proxy web de l’entreprise.
Le cache est de type explicite forcé et le pare-feu sur la machine pas.g3.test.shayol.org refuse toutes connexions ne passant pas par le Proxy.
L’installation du Proxy Squid se fait avec la commande: #apt-get install squid Le fichier de configuration est /etc/squid.conf
Les paramètres du proxy:
http_port 3128 cache_mem 8 MB cache_swap_low 90 cache_swap_high 95
cache_log /var/log/squid/cache.log cache_access /var/log/squid/access.log cache_store_log /var/log/squid/store.log connect_timeout 20 seconds
request_timeout 40 seconds read_timeout 3 minutes
//Pour accèder à internet, il nous faut déclarer un cache parent.
//On spécifie aussi un login et mot de passe pour l’authentification cache_peer 192.168.196.1 parent 3128 3130 login=l-asr1:password
B. Parc du service commercial
Généralités
Le service commercial ne possède que des machines sous Windows (2000Pro et
2000Server) et mis à part potentiellement de nombreuses stations de travail on trouve 2 serveurs :
– pas.commerce.g3.test.shayol.org :
- Contrôleur de domaine Active Directory - Serveur de fichiers
- Passerelle - Relais DHCP - Serveur DNS
– sav.commerce.g3.test.shayol.org : - Serveur de sauvegarde
Pour l'attribution des adresses IP, le service commercial dépend du service Informatique, il a donc été nécessaire de mettrais en place un relais DHCP sur la passerelle.
Contrôleur de domaine
(pas.commerce.g3.test.shayol.org)Sur le contrôleur de domaine on retrouve Active Directory qui sert en premier lieu à authentifier les utilisateurs du service commercial. Pour cela un domaine « commerce » a été déclaré et les stations de travail on été intégrées à celui-ci.
Tous les utilisateurs des stations de travails sont regroupés dans une unité d'organisation intitulée « commerciaux », ceci dans le but de faciliter l'administration de tous les commerciaux.
Les profils utilisateur (Contenu du bureau, préférences des utilisateurs, cookies, historique ...) des commerciaux sont stockés sur ce même serveur pour centraliser les données et leur permettre de retrouver leur environnement de travail sur toutes les stations du parc.
Fonctionnement : les informations du profils des utilisateurs sont stockés dans le répertoire : c:/donnees_utilisateurs/<login de lutilisateur>/
Serveur DNS
La machine pas.commerce.g3.test.shayol.org est le serveur DNS pour le domaine commerce.g3.test.shayol.org.
L’installation s’est faite avec Active Directory, en effet le contrôleur de domaine a besoin d’un serveur DNS pour fonctionner.
C’est pourquoi la zone commerce.g3.test.shayol.org est intégrée à Active Directory.
Quand le serveur ne peut pas résoudre certaines requêtes DNS, il faut lui spécifier des re- directeurs.
Dans notre cas, ce sera le serveur DNS pas.g3.test.shayol.org.
Dans la zone de recherche directe, on ajoute des champs A des machines du réseau pour faire la correspondance nom -> @IP.
On créer aussi une zone de recherche inversée 201.168.192.in-addr.arpa pour la résolution de IP vers nom. Dans cette zone, on ajoute les champs PTR pour les différentes machines du réseau.
Serveur de fichiers
(pas.commerce.g3.test.shayol.org)En plus des profils utilisateurs, le serveur stock tous les documents personnels des
utilisateurs. Cela permet de centraliser les documents importants et de permettre à ce qu'ils soient sauvegardés et restaurables en cas de problème sur une station (ainsi le commercial ne perd pas tout sont travail).
Nous avons donc mis en place un serveur de fichier qui met à la disposition des utilisateurs un espace privé qui leur est réservé accessible par le lecteur « U: ». La connexion au lecteur réseau est transparente et se fait lorsque l'utilisateur se logue, ainsi il peut se connecter à n'importe quelle station du parc, il retrouvera dans tout les cas son espace de travail ainsi que ses documents personnels.
Fonctionnement : les données personnelles des utilisateurs sont stockés dans le répertoire : c:/donnees_utilisateurs/<login de lutilisateur>/user_data/
Serveur de sauvegarde
(sav.commerce.g3.test.shayol.org)La machine pas partage le dossier c:/donnees_utilisateurs/ en lecture pour le groupe
« Opérateurs de sauvegarde ». Etant donnée que la machine sav fait parti de ce groupe, elle a accès à toutes les données des utilisateurs ainsi qu'à leurs profils.
Le logiciel de sauvegarde que nous avons utilisé est : ntbackup, c'est un produit Microsoft fournis avec Windows 2003 server.
Le principe de ntbackup est simple, on crée une « tâche » de sauvegarde qui sera exécuté selon une périodicité définie (1fois par semaine, tout les mardis ...).
Nous avons donc crée 2 taches :
La sauvegarde des données des utilisateurs : il s'agit du répertoire c:/donnees_utilisateurs/ sur pas.
La sauvegarde du système : c'est une option par défaut dans le logiciel ntbackup, cela permet de faire à la volée une sauvegarde d'un système complet.
Une fois la périodicité choisie le logiciel se contente d'ajouter des « tâches planifiées » dans le système. Le planificateur de tache est un outils pré installé dans Windows qui permet planifier des exécutions de programmes à l'avance et à une date et une heure précise. Il y a également la
possibilité de définir une période (toutes les semaines, tout les mois ...).
Ntbackup étant capable de se lancer en ligne de commande, il s'agit dans notre cas d'une ligne de commande lancé à une certaine heure et date :
3h du matin tout les jours pour les données et profils utilisateurs
Nous avions décidés auparavant que les sauvegardes seraient envoyées sur la machine pas.g3.test.shayol.org, nous avons donc créé des scripts qui nous permettaient de faire les sauvegardes puis leurs envois.
La ligne de commande pour la sauvegarde a été récupérée dans le « planificateur de taches » (ajouté préalablement par le logiciel ntbackup) et pour l'envoie nous avons récupérer un client scp en ligne de commande pour windows.
L'envoie vers pas.g3.test.shayol.org se fait à l'identique des autres serveurs mis à part
l'authentification qui ne se fait pas à l'aide de clés mais à l'aide d'un mot de passe. Pour garantir un minimum de sécurité, les scripts ne sont accessible que par l'administrateur.
Fonctionnement : Nous disposons donc de deux scripts batch (.bat), un pour la sauvegarde des données et profils des utilisateurs et un autre pour la sauvegarde du système pas (scripts disponible sur le bureau de l’image vmware de la machine sav.commerce.g3.test.shayol.org)
Ils contiennent chacun deux commandes : ntbackup.exe (pour la sauvegarde) et scp.exe (pour la copie vers pas.g3.test.shayol.org)
Enfin des taches planifiées ont été programmées dans le « planificateur de taches » pour l'exécution périodique de ces taches.
Restauration : La restauration se faire interactive ment via le logiciel ntbackup.exe
C. Parc du service recherche et développement
Généralités
Le service recherche et développement est un parc autonome, dans la mesure ou
contrairement au service commercial il administre lui même l'attribution des adresses IP. Le parc est composé en plus des stations de travail (sous Windows 2000 Pro et FreeBSD) de 2 serveurs :
– pas.rd.g3.test.shayol.org : - Serveur DHCP
- Serveur WEB - Serveur DNS - Serveur NIS & NFS - Serveur de fichiers - Serveur SMTP
– sav.rd.g3.test.shayol.org : - Serveur de sauvegarde
Ces 2 machines « pas.rd.g3.test.shayol.org » et « sav.rd.g3.test.shayol.org » tournent sous FreeBSD et hébergent toutes les deux un serveur SSH.
Configuration de la passerelle
(pas.rd.g3.test.shayol.org) :La machine pas du service R&D fait routeur entre le sous réseau recherche et développement, et les autres sous réseaux Commerce et informatique, donc c’est la passerelle par défaut de toutes les machines du sous réseaux,
La configuration en dur de cette passerelle se fait dans le fichier /etc/rc.conf dans lequel il faut ajouter la configuration du nom de la machine, des adresse et masques des deux interfaces de la passerelle ainsi que l’activation de l’ip forwarding pour le routage et enfin la configuration des routes statiques, toutes ces informations seront initialisés au démarrage du service réseau grçce à la commande /etc/netstart. Nous avons commenté le fichier afin d’expliquer l’utilité de chaque ligne de configuration.
#/etc/rc.conf : Fichier de Configuration de base
#donner un nom de la machine à chaque démarrage du service réseau hostname="pas.rd.g3.test.shayol.org"
# Configuration des interfaces réseau en donnant à chacune d’entre
#elles son adresse ip et son masque de sous réseau
ifconfig_lnc0="inet 192.168.213.2 netmask 255.255.255.0"
ifconfig_lnc1="inet 192.168.199.249 netmask 255.255.255.0"
# Pour activer l’ip forwarding et mettre sa valeur à 1 autrement dit
#Notre machinne est passerelle gateway_enable="YES"
#Config du routage: les trois lignes qui suivent se traduisent en français #par : si le paquet à pour destination une machine du service
#commercial la passerelle est la machine 192.168.213.3 du sous réseau
#192.168.201.0 sinon pour toute autre destination envoyer le paquet à
#la passerelle par défaut 192.168.213.1 qui est la passerelle de sortie
#vers internet.
defaultrouter="192.168.213.1"
static_routes="commerce"
route_commerce="192.168.201.0 192.168.213.3"
Serveur DNS
(pas.rd.g3.test.shayol.org) :La machine pas.rd.g3.test.shayol.org est serveur DNS pour le domaine rd.g3.test.shayol.org.
Configuration de l'initialisation du système : afin de lancer le “daemon” named au démarrage du système, l'option suivante doit être présente dans le fichier :
#/etc/rc.conf
named_enable="YES"
Le Fichier principal de configuration est : /etc/namedb/namedb.conf, définit les paramètres généraux de named et pointe vers les sources d'information de la base de données du domaine utilisé par le serveur.
Nous remarquons que notre serveur contient un champ forwarders. Il a comme valeur l’adresse du serveur DNS pas.g3.test.shayol.org du service informatique donc notre serveur pas.rd.g3.test.shayol.org devra systématiquement retransmettre les requêtes, sans lui-même faire de recherche récursive. Si le forwarder ne fournit pas de réponse satisfaisante, notre serveur va alors entamer une phase de récursivité. Les appels à ce serveur de proximité sont faits pour éviter la surcharge de trafic causée par les appels récursifs et diminuer le temps de réponse.
#/etc/namedb/namedb.conf
options {
directory "/etc/namedb";
pid-file "/var/run/named/pid";
forwarders {
192.168.213.1;
};
};
zone "." {
type hint;
file "named.root";
};
La base de données du domaine utilisé par le serveur constituée de:
/etc/namedb /zones/rd.hosts : fichier de zone qui traduit les noms d’hôtes en adresses IP.
/etc/namedb /zones/rd.rev : fichier de zone associé au domaine inverse. Ce fichier permet de traduire les adresses IP en noms d'hôtes.
named.root : pointe vers les serveurs du domaine point ‘.’, c’est le de fichier de cache DNS ce fichier est fournit avec le serveur DNS.
Déclaration de la zone rd.g3.test.shayol.org:
zone "rd.g3.test.shayol.org" { type master;
file "zones/rd.hosts/";
};
zone "199.168.192.IN-ADDR.ARPA" { type master;
file " zones/rd.rev";
};
Nous indiquons que ces deux sections représentent notre domaine : la première est la résolution nom -> Adresse IP, le champ type est MASTER ce qui signifie que le serveur DNS est définit comme ayant autorité sur notre zone, et la deuxième zone est l’inverse de la première elle sert à la résolution adresse IP -> Nom.
Les fichiers de zones :
# zones/rd.hosts :
C’est dans ce fichier que nous avons renseigné les noms de nos différentes machines et leurs adresses IP associé.
# zones/rd.hosts :
@ IN SOA pas.rd.g3.test.shayol.org.
root.rd.g3.test.shayol.org. (
2004122301 ; Serial
8H ; Refresh 8 hours 2H ; Retry 2 hours
7D ; Expire 168 hours - 7 days 900 ) ; Negative cache TTL
IN NS pas.rd.g3.test.shayol.org.
localhost IN A 127.0.0.1
pas IN A 192.168.199.249 station IN A 192.168.199.52 poste01 IN A 192.168.199.51 sav IN A 192.168.199.12
SOA veut dire (Start Of Authority) et signale que l'enregistrement qui suit contient les informations ayant autorité pour ce domaine. Le champ IN signifie qu’il s’agit d’un réseau de type INTERNET ensuite il nous fallu mentionner l’adresse de la personne qui gère la zone :
root.rd.g3.test.shayol.org.
Bien sûr il ne faut pas oublié le point quand il s’agit d’un FQDN du nom de la zone ou de la personne qui gère la zone, car le nom donné dans le fichier sera considéré comme absolu s’il se termine par un point, sinon il sera compris comme relatif à l'origine :
« rd.g3.test.shayol.org » Cette origine est indiquée dans notre fichier par le symbole @.
Le champ NS permet de savoir le nom du serveur qui gère la zone. Les champs A permettent de savoir les adresses IP des serveurs.
# zones/rd.rev :
@ IN SOA pas.rd.g3.test.shayol.org.
root.rd.g3.test.shayol.org. (
2004122302 ; Serial
8H ; Refresh 8 hours 2H ; Retry 2 hours
7D ; Expire 168 hours - 7 days 900 ) ; Negative cache TTL
IN NS pas.rd.g3.test.shayol.org.
249 IN PTR pas.rd.g3.test.shayol.org.
52 IN PTR station.rd.g3.test.shayol.org.
51 IN PTR poste01.rd.g3.test.shayol.org.
12 IN PTR sav.rd.g3.test.shayol.org.
Dans ce fichier le champs PTR: convertit une adresse IP en un nom d'hôte ; ici aussi il ne faut pas oublier qu’il s’agit d’un nom FQDN et donc il faut bien vérifier la présence du «
.
» à la fin du nom de chaque machine.Serveur WEB
(pas.rd.g3.test.shayol.org)Le serveur web est un serveur apache Version 2. Nous avons récupéré les sources sur le site officiel www.apache.org puis dé taré, compilé et installé celles ci grâce aux commandes /configure, make, make install.
La création d'un script pour le lancement automatique du serveur à été nécessaire, nous l'avons placé ici : /usr/local/rc.d/httpd.sh
Il ne contient qu'une ligne qui permet de lancer apache : httpd
Serveurs SSH
Nous avons mis en place des démons SSHD sur les deux serveurs pour permettre un accès limité et authentifié utile pour la sauvegarde à travers scp.
Fonctionnement : L'authentification entre un client SSH et un serveur SSH se fait dans notre cas a l'aide d'une authentification forte. Le client possède une paire de clé publique/privée, la clé publique est comme son nom l'indique publique, et la clé privé n'est connu que par le client et protégée par une « passphrase ». Cette « passphrase » est une sorte de phrase entière qui sert de mot de passe. Le client envoie donc sa clé publique au serveur qui l'ajoute dans la liste des clés autorisées. Ainsi à chaque fois que le client voudra se connecter au serveur, il présentera sa clé publique, et si celle ci est autorisée, le client SSH accédera au serveur sans avoir à saisir un mot de passe.
Fichiers de configuration :
– Sur le serveur :
/etc/ssh/sshd_config permet de configurer le serveur SSH
~/.ssh/authorized_keys ce fichier contient toutes les clés publiques autorisées a se connecter au serveur.
– Sur le client :
/etc/ssh/ssh_config permet de configurer le client SSH
~/.ssh/id-rsa La clé privée du client
~/.ssh/id-rsa.pub La clé privée du client
#/etc/ssh/sshd_config: Fichier de Configuration du serveur SSH
#il s’agit du port qui sera utilisé par ssh Port 22
#indique au serveur d’utiliser le protocole ssh2 d’abord car c’est plus sécurisé puis ssh1 ce dernier à éviter.
Protocol 2,1
#Permet de définir l’emplacement des différents clés de la machines
# HostKey pour protocol version 1 HostKey /etc/ssh/ssh_host_key
# HostKeys pour protocol version 2 HostKey /etc/ssh/ssh_host_dsa_key
# le temps en secondes au bout duquel le serveur régénère sa clé KeyRegenerationInterval 3600
#Définit le nombre de bits de la clé serveur ServerKeyBits 768
# définit le temps laissé à l’utilisateur pour se connecter avant
#déconnexion de la part du serveur : LoginGraceTime 120
#dire si le root à le droit de se connecter ou non pour plus de
#sécurité il mettre ce champs à no PermitRootLogin no
#ce paramètre concerne SSH1 permet l’authentification à l’aide de la
#clé symétrique rsa1 ou par mot de passe RSAAuthentication yes
#Identique au précédent mais pour SSH2 PubkeyAuthentication yes
# rhosts authentication à éviter trop peu sûre RhostsAuthentication no
#nous l’avons mis à no car on se connecte à l’aide des clés : PasswordAuthentication no
#ne pas permettre de se connecter sans mot de passe PermitEmptyPasswords no
#Ne pas Permettre l’exécution puis l’affichage de l’application X
#distante à l’aide de l’option –X de ssh X11Forwarding no
Mise en place :
1) Sur le client générer la paire clé privé/clé publique utilisant l'algorithme RSA (l'encryptions DSA est également disponible) à l'aide de la commande :
« ssh-keygen -t rsa »
2) Envoyer la clé publique sur le serveur dans le fichier authorized_keys a l'aide de la commande scp :
« scp ~/.ssh/id-rsa.pub root@pas.rd.g3.test.shayol.org:~/.ssh/authorized_keys » Cette commande copie la clé publique sur le serveur sur le serveur sous le nom
authorized_keys, il faut penser à concaténer la clé dans ce fichier si plusieurs client s'authentifie de cette manière auprès d'un seul serveur.
Lors de la copie le mot de passe root est demandé pour l'authentification, une fois la copie effectuée vous pouvez vous authentifier sans mot de passe (sous réserve d'une « passphrase » vierge).
Serveur NFS « Système de fichiers réseau »:
a. Présentation du service
NFS permettra à notre serveur NFS pas.rd.g3.test.shayol.org de partager des répertoires et des fichiers avec d'autres systèmes par l'intermédiaire d'un réseau. En utilisant NFS, les utilisateurs et les programmes peuvent accéder aux fichiers à partir de leurs machines clientes sur le serveur distant comme s'ils étaient des fichiers locaux.
Les Avantages que NFS apportera à l’entreprise et spécialement au servi ce R&D sont:
Les utilisateurs n'ont pas besoin d'avoir un répertoire personnel sur chaque machine du réseau. Les répertoires personnels pourront se trouver sur le serveur NFS et seront disponibles par l'intermédiaire du réseau, donc les utilisateurs peuvent se connecter à partir de toute machine cliente et devraient alors toujours avoir le même répertoire utilisateur indépendamment de la station de travail sur laquelle ils ouvrent une session. ce qui facilitera les tâches d’administration -> Administration centralisée.
D’une part les stations de travail utilisent moins d'espace disque en local parce que les données utilisées en commun peuvent être stockées sur le serveur NFS tout en restant accessibles aux autres machines sur le réseau, d’autre part la procédure de sauvegarde des répertoires et des données utilisateurs sera plus facile et plus efficace.
b. Configuration du serveur NFS
La première étape de configuration consiste en le lancement des différents Daemon nécessaire au fonctionnement de NFS :
nfsd est le daemon' NFS qui répond aux requêtes des clients NFS.
mountd est le `daemon' de montage NFS qui traite les requêtes que lui passe nfsd.
rpcbind c’est grâce à ce daemon que les clients NFS trouvent le port utilisé par le serveur NFS.
Pour lancer ces daemons il nous a fallu ajouter les entrées suivantes dans le fichier /etc/rc.conf :
#/etc/rc.conf
rpcbind_enable="YES"
nfs_server_enable="YES"
mountd_flags="-r"
Le fichier/etc/exports indique quels systèmes de fichiers NFS devraient être partagés.
Dans /etc/exports il faut autoriser poste01 à accéder a /usr/home pour monter les répertoires des utilisateurs pour NIS : donc la ligne ajoutée précise un système de fichiers à exporter qui est /usr/home et quelles machines auront accès à ce système de fichiers : c’est le poste01.
#/etc/exports
/usr/home poste01
c. Configuration du client NFS
La configuration d’un client NFS est très simple il suffit d’ajouter la ligne suivante dans le fichier /etc/rc.conf
#/etc/rc.conf
nfs_client_enable=''YES''
Nous avons ajouté la ligne suivante dans le fichier /etc/fstab pour monter automatiquement le système de fichier à chaque démarrage de systèmes, et c’est complètement transparent aux clients.
#/etc/fstab
pas:/usr/home /home nfs rw 0 0
Sauvegarde
Le serveur de sauvegarde a pour rôle :
– Lancer le script de sauvegarde sur la machine contenant les comptes personnels des utilisateurs
– Récupérer cette sauvegarde pour la stocker sur son disque dur
– En faire une copie et l'envoyer sur le serveur de sauvegarde principal qui se trouve dans le service informatique (sav.g3.test.shayol.org)
Pour cela nous avons développé un script dont voici la source :
#! /bin/sh
ssh root@pas "tar cfj - /usr/home" > /usr/local/sauv/pas.rd.sav.tar.bz2
Ce script fait en sorte d’exécuter un tar sur la machine pas dont la sortie est redirigée vers le répertoire /usr/local/sauv/ de la machine de sauvegarde.
Serveur NIS:
a. Présentation du service « Services d'information réseau »
NIS, veut dire``Network Information Services'', c’est le standard industriel pour centraliser l'administration de systèmes UNIX le supportant. Son prédécesseur était appelé ``Yellow Pages’’.
C'est un système client/serveur basé sur les RPCs qui permet à un groupe de machines d'un domaine NIS de partager un ensemble de fichiers de configuration communs.
Les Avantages que NFS apportera à l’entreprise et spécialement au service R&D sont:
NIS permettra à l’administrateur R&D de mettre en place ses clients NIS avec un minimum de configuration et d'ajouter, modifier ou supprimer les informations de configuration à partir de l’unique emplacement: serveur pas.rd.g3.test.shayol.org. Donc il ne sera pas obligé à se déplacer pour des petites interventions telles que l’ajout d’un utilisateur…
Comme pour NFS la première étape de configuration consiste en le lancement des différents daemons nécessaires au fonctionnement de NIS :
portmap : active les RPC, si portmap ne tourne pas il sera impossible de faire fonctionner notre serveur NIS.
ypbind grâce à ce daemon que chacun de nos clients NIS connaîtra notre serveur NIS. Comme ça chaque client récupérera le nom de domaine NIS auprès de notre serveur, et en utilisant les RPC, se connectera au serveur.
ypserv ce daemon ne tourne que sur notre serveur « pas » et ne tourne pas sur les clients, car c'est le processus serveur en lui-même, et donc grâce à lui notre serveur nis pourra répondre aux requêtes NIS de nos clients.
rpc.yppasswdd comme ypserv ne tourne que sur le serveur, il permet aux clients de modifier leur mot de passe NIS. Sans ce daemon l’administrateur R&D doit appeler les utilisateurs des postes client NIS à son bureau, ouvrir une session sur le serveur NIS et y changer leur mot de passe.
b. Configuration du serveur NIS
FreeBSD offre par défaut un support direct du NIS. Notre serveur pas.rd.g3.test.shayol.org doit être configuré comme serveur maître NIS et tous ses clients ont un seul domaine NIS, ce dernier nous l’avons choisi différent du nom domaine DNS pour éviter toute sorte de confusion. Quand un client diffuse des requêtes pour obtenir des informations, il y inclut le nom de domaine NIS auquel il appartient.
Pour lancer daemons serveur nous avons modifié le fichier /etc/rc.conf comme suit :
#/etc/rc.conf
nisdomainname="rc-nisdomain"
nis_server_enable="YES"
nis_yppasswdd_enable="YES"
La première ligne définie notre nom de domaine NIS "rc-nisdomain". Alors que la deuxième demande au système de lancer les processus du serveur NIS dès le démarrage des services réseaux.
Enfin la troisième ligne active rpc.yppasswdd.
Après avoir ajouter ces entrées dans le fichier nous avons redémarré le service réseau /etc/netstart, pour tout reconfigurer en prenant en considération les nouvelles valeurs.
Initialisation des tables NIS :
Afin de ne pas divulguer nos mots de passe du root et des autres comptes d'administration aux autres, nous n’avions pas négliger les étapes suivante avant d'initialiser les tables NIS : d’abord il nous a fallu commencer par copier le fichier des mots de passe master.passwd dans le répertoire des yp : /var/yp/master.passwd
#cp /etc/master.passwd /var/yp/master.passwd
#cd /var/yp
#vi master.passwd
Après nous l’avons éditer dans le but d’effacer toutes les entrées concernant les comptes système (bin, tty...), tout comme les comptes que nous avons jugé sensible et qu’il ne faut pas propager aux clients NIS : le compte du root en est un bon exemple ainsi que tous les autres comptes avec un UID 0 (super-utilisateur). D’autre part, nous avons changer les droits de ce fichier /var/yp/master.passwd afin qu’il ne soit pas lisible ni par son groupe ni par tout le monde
« others ».
# Chmod 600 /var/yp/master.passwd
Puis nous avons initialisé le serveur NIS à l'aide de la commande ypinit comme notre serveur
« pas » est le serveur maître NIS nous avons passé l’option –m à la commande ypinit :
# ypinit -m rd-nisdomain
Les bases de données utilisées pour le stockage des informations ou les tables NIS. Se trouvent maintenat dans /var/yp/rc-nisdomain/
c. Configuration du Clients NIS
Comme nous avons expliqué précédemment nos clients NIS établirent la connexion avec notre serveur NIS « pas » par l'intermédiaire de ypbind qui consulte le nom de domaine par défaut qui a été définit par la commande domainname sur le client, et commence à diffuser des requêtes RPC sur le réseau local. Ces requêtes précisent le nom de domaine rc-nisdomain auquel le client essaye de se rattacher.
Le lancement d’Ethereal sur le serveur «pas » nous montre que ce dernier reçoit les requêtes diffusées et répond à ypbind, qui enregistrera l'adresse de « pas ».Dorénavant le client dirigera toutes ses requêtes NIS vers « pas », et envoie de temps en temps des requêtes ping au serveur pour s'assurer qu'il fonctionne toujours.
Dans le fichier /etc/rc.conf nous avons ajouté les lignes suivantes afin de définir le nom de domaine NIS et de lancer ypbind au démarrage du réseau:
#/etc/rc.conf
nisdomainname="rc-nisdomain"
nis_client_enable="YES"
Après, dans le but d’importer tous les mots de passe disponibles du serveur NIS, nous avons effacé tous les comptes utilisateur du fichier /etc/master.passwd du poste01 et nous avons ajouté la ligne suivante à la fin du fichier:
#/etc/master.passwd +:::::::::
Cette ligne a pour but de permetttre à chaque utilisateur existant dans les tables de mots de passe de
« pas » d'avoir un compte sur le client.
Pour importer tous les groupes disponibles du serveur NIS, on ajouté cette ligne au fichier /etc/group
#/etc/group +:*::
Maintenant que la configuration de notre client NIS est faite il ne nous reste qu’à tester le bon fonctionnement du service
Nous avons exécuté la commande ypcat passwd pour voir la table des mots de passe du serveur NIS.
Serveur DHCP
Afin de gérer les attributions d’adresses ip au sein du service R&D, nous avons mis en place un serveur DHCP.
a. Installation du serveur DHCP sur pas
Tout d’abord, nous avons téléchargé le package dchp (rapatrié par ftp sur le site http://isc.org/) . Puis nous l’avons installé en lançant le script de config avec ./configure, ensuite nous avons
poursuivi l’installation par l’exécution des règles (install et all) du makefile avec make, et, make install.
b. Configuration du serveur DHCP
Nous sommes ensuite passé à la configuration du /etc/dhcpd.conf avec le nom du domaine, le nom du serveur de domaine, l'option ''ddns-update-style ad-hoc'' (à ne pas oublier), une partie définissant les réseaux environnant (pour qu’il « visualise » mieux son environnement) ainsi qu'une autre partie définissant le sous-réseau 192.168.199.0 contenant la plage d'adresses à attribuer à nos machines et l'adresse de la passerelle par défaut. Nous avons également réservé des adresses pour toutes les machines de ce réseau.
# Nom de domaine du reseau
option domain-name "rd.g3.test.shayol.org";
# Nom du serveur DNS
option domain-name-servers pas.rd.g3.test.shayol.org;
#
ddns-update-style ad-hoc;
default-lease-time 600;
max-lease-time 7200;
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;
# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.
# SI
subnet 192.168.200.0 netmask 255.255.255.0 { }
# Commercial
subnet 192.168.201.0 netmask 255.255.255.0 { }
# Sous-reseau RD
subnet 192.168.199.0 netmask 255.255.255.0 { local-address 192.168.199.249;
range 192.168.199.100 192.168.199.254;
# On indique le routeur par default pour les machines cliente de ce dhcp option routers 192.168.199.249;
# Adresses IP reservées host stationW2K {
hardware ethernet 00:0c:29:45:19:1f;
fixed-address 192.168.199.52;
}
host poste01 {
hardware ethernet 00:0c:29:1b:5b:20;
fixed-address 192.168.199.51;
}
host sav {
hardware ethernet 00:0c:29:7a:ad:8c;
fixed-address 192.168.199.12;
}
}
Pour finir, nous avons fait un script (/usr/local/etc/rc.d/dhcpd.sh) pour lancer le service dhcp au démarrage.
Une dernière modification, sur les clients cette fois, a été faite, au niveau du rc.conf : ifconfig_lnc0=''DHCP''
dhcp_program=''/sbin/dhclient'' // dhcp_flags=''''
Serveur SMTP
La machine pas en serveur SMTP de courrier local
La machine pas du service recherche sert de serveur de courrier local.
Elle stocke les mails des personnes appartenant au domaine rd.g3.test.shayol.org.
Options importantes du fichier /etc/postfix/main.cf
#fichier contenant les adresses virtuelles
virtual_maps=hash:/usr/local/etc/postfix/virtual
#nom du fichier d'alias
alias_maps=hash:/usr/local/etc/postfix/aliases alias_database=hash:usr/local/etc/postfix/aliases
#Liste des domaines pour lesquels le serveur accepte le mail et le délivre en local
mydestination=$myhostname,localhost.$mydomain,localhost,$mydomain
#commande à exécuter pour délivrer le mail en local
mailbox_command=procmail -a "$EXTENSION"
#taille maximale pour les mailbox (0=pas de limite)
mailbox_size_limit=0
Le fichier /usr/local/etc/aliases
Les alias permettent de faire la correspondance entre les adresses mails et les comptes locaux.
On utilise un compte local admin pour lire les mails.
# fichier d'alias
webmaster: root postfix: root root: admin
postmaster: admin abuse: admin
Il faut générer la base de données d'alias:#newaliases
Il faut dire à postfix de relire sa configuration:#postfix reload
Après la mise en place des différents serveurs SMTP dans les différents services, on peut tester le fonctionnement de POSTFIX.
Test du fonctionnement de POSTFIX dans les différents services
Pour récupérer facilement les messages à partir du service commerce, on a installé un serveur IMAP sur la machine web:
# apt-get install uw-imapd
On a créer plusieurs comptes : stef appartenant au domaine g3.test.shayol.org.
tibault appartenant au domaine commerce.g3.test.shayol.org nicolas appartenant au domaine rd.g3.test.shayol.org
Ensuite, on a testé l'envoi de mail en local dans l'entreprise avec les différents domaines.
De stef à tibault:
Sur pas.g3.test.shayol.org: stef$mail -s "test" tibault@commerce.g3.test.shayol.org Le mail est stockée sur la machine web dans /var/mail/tibault.
De nicolas à tibault:
Sur poste01.rd.g3.test.shayol.org: nicolas$mail -s "test" tibault@commerce.g3.test.shayol.org Le mail est stockée sur la machine web dans /var/mail/tibault.
Donc la machine pas.g3.test.shayol.org a bien relayé le mail.
Dernier test: l'envoi d'un mail à l'extérieur
On va vérifier que la machine pas.g3.test.shayol.org relaie bien le mail au serveur SMTP guidoni.sig.univ-evry.fr.
Pour cela sur la machine web:
#mail -s "teste" zelouzeur@tiscali.fr
Pour vérifier que ça fonctionne, il suffit de regarder si le mail a été relayé sur la machine pas:
#tail -n 11 /var/log/mail.info.
4. Principaux problèmes rencontrés
Problème lié au firewall :
Pour le firewall, nous avions tous bloqué puis ré activé petit à petit les services nécessaires : icmp, smtp, imap, ssh. Mais pour le DNS le pare-feu ne laisse pas passer les trames et nous n’avons pas eu le temps de trouver le problème.
Problème lié au DHCP :
Nous avions installé le DHCP sur pas tout au début et nous avons ajouté des interfaces réseaux par la suite. Or sous Debian, DHCP n’active pas par défaut les nouvelles interfaces. C’est en lisant le script du lancement du service DHCP que nous avons repéré le fichier /etc/default/dhcp dans lequel il faut rajouter à la main la nouvelle interface.
Problème lié au Proxy :
Pour accéder à Internet, la connexion s’effectuait par le Proxy à partir des postes clients. La mire apparaissait bien et nous pouvions surfer mais au bout de quelques secondes de connexion, le proxy tombait. Après avoir analyser le trafic, les logs, nous n’avons pas réussi à résoudre ce problème.
Problème lié au DNS du parc commercial :
Par manque d’informations sur la configuration d’un serveur DNS Windows, on a perdu beaucoup de temps à configurer le DNS notamment avec les différentes zones (., commerce.g3.test.shayol.org , 201.168.192.in-addr.arpa) et les re-directeurs.
Problème lié au NIS :
Nous avons suivi toutes les étapes que nous avons détaillées, mais NIS n’a pas marché car le fichier /etc/nsswitch.conf n’existait pas sur la machine or ce fichier est nécessaire car il contient l'endroit de la base de donnée à regarder pour se loguer. Donc nous l’avons créer comme suit :
# /etc/nsswitch.conf group: compat group_compat: nis hosts: files dns networks: files passwd: files nis passwd_compat: nis
shells: files
IV. C ONCLUSION
Ce projet nous a permis non seulement de mettre en application ce que nous avions appris durant cette année scolaire, mais surtout de nous mettre en situation proche du réel avec des contraintes que nous n’avions encore jamais rencontrés. Ce projet nous a permis de voir un ensemble d’applications que nous utiliserons couramment dans nos prochains stages et futurs métiers. Ce projet nous a permis aussi d’avoir une certaine autonomie, de se mettre en situation où face à un problème, il faut trouver différentes solutions et prendre la meilleur, par rapport aux remarques de chacun, par rapport aux contraintes, et par rapport aux temps qu’il nous restait.
Même si au départ être cinq pour le projet nous sembler être un obstacle, finalement, vu l’ampleurs du projet, heureusement que les groupes étaient important en effectif. En ce qui concerne notre groupe, tout s’est bien passé et la répartition de tâches s’est faites assez rapidement. Nous n’avons pas perdu de temps au départ en exploitant dès le départ, les heures qui nous étaient réservées. Dommage que nous n’avons pu régler les problèmes liés au proxy et au firewall. Mais avec un peu plus d’expériences, maintenant nous pourrions allé beaucoup plus vite sur certaines parties.
Ce projet nous a vraiment apporté beaucoup personnellement et collectivement et il y a eu une bonne dynamique dans l’ensemble. Maintenant avec un petit plus de recul nous pourrions allé plus vite. Cela nous a donné une bonne expérience technique qui nous servira pour notre stage de cet été.
