rapport stage d'été

Stage d’Eté

Ecole Nationale des Sciences de l’Informatique GL Trade

Introduction

Ces dernières années, les entreprises transnationales n’ont cessé de réaliser une montée

en puissance et en nombre. Pour les transnationales se spécialisant dans le développement et

la production de logiciels informatique, la synchronisation entre les différentes équipes des

différentes filiales devient une tâche primordiale pour le bon avancement du travail.

C’est dans ce contexte que se situe ce travail qui consiste à la réalisation d’une

application qui assure la synchronisation entre deux environnements distants, dans ce cas les

deux environnements de deux filiales distantes, pour le compte de l’entreprise transnationale

GLTRADE.

Ce rapport se compose de quatre chapitres. Le premier chapitre est consacré à la

présentation de l’organisme d’accueil. Le deuxième chapitre est relatif à l’analyse et à la

spécification des besoins, il contient une explication détaillée des exigences auxquelles l’outil

doit répondre. Le chapitre suivant développe la conception de l’application et le dernier

chapitre, réalisation, décrit l’environnement de développement et les différentes techniques

utilisées lors du développement de l’application.

1

Stage d’Eté


Chapitre 1 : Présentation générale

I- Introduction

Dans le cadre de notre formation d’ingénieurs informaticiens à l’Ecole Nationale des

Sciences de l’Informatique, nous avons eu l’occasion d’effectuer notre projet d’été au sein de

la société GL Trade. Le projet consiste en la synchronisation d’environnements de

développement distants.

Dans ce chapitre, nous présentons le cadre général de notre projet. En effet, nous

commençons par la présentation de l’organisme d’accueil GL Trade. Ensuite, nous décrivons

le sujet du projet.

II- Présentation de l’organisme d’accueil

1. GL Trade

Le groupe GL Trade a été créé en 1987 par Pierre GATIGNOL et Louis Christophe

LAURENT. Il offre à la communauté financière une large gamme de solutions logicielles

pour couvrir le processus complet d’un ordre de bourse, du donneur d’ordre au trader :

logiciels de négociations et de gestion des ordres, réseau, informations de marchés, logiciels

de gestion de risques et services associés du Front au Back Office. Tous ces services sont

accessibles à travers son réseau propriétaire GLNET connecté à plus de 500 institutions en la

matière et plus de 80 marchés à travers le monde.

GL Trade est une société anonyme dont le capital social dépasse les 300 millions

d’Euros.

C’est un groupe international de 1100 collaborateurs, répartis sur 26 filiales dans 23

pays comme l’indique la figure 1. Elle est au service de plus de 3500 clients à qui elle

s’engage à fournir des solutions de capture d’ordres basées sur des technologies ouvertes et

2

Stage d’Eté


100% compatibles avec des applications tierces, des logiciels intégrés en temps réel pour la

meilleure exécution possible et des modules de gestion des ordres compétitifs pour le respect

des marges. Le Groupe GL Trade s’est développé au fil des années et aujourd’hui il est

devenu l’un des acteurs incontournables sur son marché.

Figure 1: Implantations géographiques de GL Trade dans le monde

2. GL Trade MENA

GL Trade Tunis est l’un des trois centres de développement de la société à travers le

monde. C’était au début une filiale de l’Ubitrade. Dirigée par Yassine BRAHIM (the chief

executive officer d’Ubitrade ), GL Trade Tunis ou GL Trade MENA (Middle East and North

Africa) fournit les supports techniques de développement aux clients de la région. GL Trade

MENA engage 136 personnes dont 85% sont des ingénieurs de recherche et développement.

Le centre de Tunis couvre toute la région de l’Afrique du Nord et du Moyen Orient et en

particulier Dubaï où GL Trade a signé un accord de partenariat avec une bourse de la place.

3

Stage d’Eté


III-Présentation du sujet

L’objectif de notre sujet au sein de GL Trade est la synchronisation d’environnements

de développements distants. En d’autres termes, c’est la synchronisation des versions (code

source) entre deux environnements de travail partagés : un premier à Tunis et un deuxième à

Londres.

IV- Conclusion

Ce chapitre nous a servi à mettre le projet dans son cadre. En effet, ce projet d’été est

effectué dans GL Trade et consiste à la synchronisation d’environnements de développement

distants. Le chapitre suivant permettra d’introduire plusieurs concepts nécessaires à la

compréhension de ce chapitre à savoir : le Shell Unix, les fichiers cron et crontab, etc.

4

Stage d’Eté


Chapitre 2 : Analyse et spécification des besoins

Dans ce chapitre, nous allons énumérer les différents besoins fonctionnels et non

fonctionnels de notre application, lesquels besoins vont éclaircir mieux son fonctionnement.

I- Etude de l’existant et solution retenue

1. Etude de l’existant

GL Trade Tunis est l’un des trois centres de développement de la société à travers le

monde. Vu l’importance de son rôle dans le cursus de développement, les codes sources se

trouvant sur le serveur GL Trade MENA doivent toujours être mis à jour par rapport au

serveur central se trouvant à Londres. Ce contrôle se base sur les dates de modification de ces

codes (versions). C'est-à-dire, chaque version du serveur de Londres plus récente que celle se

trouvant sur le serveur de Tunis doit être téléchargée pour remplacer l’ancienne version.

Le répertoire de travail concerné par ces modifications est le répertoire dev32. Il

contient toutes les versions en cours de création ou de modification. Ces versions sont

regroupées par type dans des sous-répertoires, donc on trouve un répertoire « java » qui

contient les codes java, un répertoire « inc » qui contient les .h et .ph, etc. Donc la

synchronisation se limitera seulement à ce répertoire seulement au niveau des deux serveurs.

Le répertoire dev32 existe sur les deux serveurs et donc la même arborescence aussi et les

mêmes sous-répertoires.

2. Solutions envisagées

Une première alternative est de se connecter manuellement au serveur distant (Londres),

lister les codes sources existants et dégager les fichiers récents, les télécharger pour enfin

remplacer les anciens codes. Dans le cas où une version existe sur le serveur distant et ne

figure pas sur le serveur local, là aussi elle doit être téléchargée. Il faut mentionner qu’il existe

5

Stage d’Eté


un système de gestion de contenu (Content Management System ou CMS) qui permet de

récupérer une ancienne version s’il y avait une erreur dans la nouvelle et donc le responsable

sur cette opération n’a pas à se soucier du fonctionnement de cette version. Bien que cette

tâche peut sembler simple, un administrateur aura une grande difficulté à localiser toutes les

nouvelles versions en les comparant avec les versions existantes, sans qu’une ou plusieurs

versions ne passent inaperçues ou sans se tromper sur l’une d’elles, sans oublier la perte de

temps qui accompagne cette tâche.

Une autre alternative sera d’automatiser ce traitement, à savoir la connexion au serveur

distant, la comparaison des fichiers, le transfert de fichiers, etc. Ainsi, l’administrateur aura

seulement la tâche de configurer l’application effectuant ce traitement en lui passant par

exemple l’adresse du serveur distant, le mot de passe, le moment de l’exécution, etc. De cette

manière, la synchronisation entre les deux environnements de développement (serveurs

distants) devient facile, sans risque d’erreurs et beaucoup plus rapide par rapport à la

procédure habituelle.

3. Solution retenue

Donc le travail demandé sera de développer une application qui automatise la

synchronisation entre deux environnements de développement distants (Tunis/Londres) pour

pallier aux problèmes de la synchronisation manuelle.

II- Besoins fonctionnels

Cette application doit donc fournir plusieurs fonctionnalités telles que :

synchroniser les codes sources : un code source doit être téléchargé dans deux

cas possible : si sa date de modification dans le serveur principal (Londres) est

plus récente que sa date de modification sur le serveur local (Tunis) ou s’il existe

sur le serveur distant et il n’a pas de version antérieure sur le serveur local,

respecter l’arborescence des codes sources : tout fichier téléchargé à partir du

serveur distant doit garder le même emplacement sur le serveur local (la même

arborescence sur les deux serveurs),

garder la trace des opérations effectuées dans un fichier journal,

6

Stage d’Eté


assurer le lancement automatique de la synchronisation a un moment précis.

III-Besoins non fonctionnels

Pour le bon fonctionnement de cette application, plusieurs contraintes doivent être

respectées. Parmi ces contraintes, on trouve :

l’optimisation du temps d’exécution qui peut être long vu l’importance du

nombre de versions existantes,

la réutilisabilité de l’application pour d’éventuelle amélioration.

IV- Conclusion

Une fois la solution à développer est fixée et les besoins fonctionnels et non fonctionnels

énumérés, il est possible maintenant de concevoir clairement l’architecture de notre système ce qui

sera le sujet du chapitre suivant.

7

Stage d’Eté


Chapitre 3 : Conception du logiciel

Ce chapitre comporte une première section relative à la conception générale de cette

application et qui décrit le comportement global de l’application. La deuxième section décrit

sa conception détaillée et les solutions choisies concernant la connexion et le transfert de

fichiers.

I- Conception générale

Notre conception doit prévoir toutes les communications et les échanges entre les deux

serveurs. Pour y parvenir, il faut mettre en place un scénario de synchronisation possible.

Cette application reçoit en entrée un fichier main_directories.txt à partir duquel, on peut lire

les emplacements des répertoires concernés par la synchronisation. Premièrement, le serveur

local se connecte au serveur distant. Sur ce dernier, il y a génération d’un fichier

all_files_list_dist qui contient la liste des fichiers se trouvant dans les répertoires mentionnés

dans le fichier main_directories.txt sur le serveur distant. Ce fichier sera téléchargé par la

suite à partir du serveur distant. De nouveau sur le serveur local, il y a génération d’un fichier

all_files_list_loc qui contient la liste des fichiers se trouvant dans les mêmes emplacements

mais sur le serveur local. Une fois les deux fichiers générés, leur comparaison devient

possible et il y aura comme résultat un fichier maj_output qui contient la liste des fichiers à

télécharger du serveur distant. A partir de cette liste, le téléchargement des mises à jour est

effectué et le travail est terminé.

Un premier point à remarquer est que pour envoyer et recevoir des fichiers et ensuite

faire des traitements là-dessus, il faudrait soit avoir une reproduction exacte du répertoire de

travail, soit avoir une connaissance parfaite des chemins des fichiers et des répertoires. Pour

pallier à ce problème, nous allons utiliser les variables d’environnements qui doivent exister

sur les deux serveurs sans se soucier de leurs contenus.

8

Stage d’Eté


Les variables d’environnements utilisées jusqu’ici sont :

RIMS_DIR : Cette variable contient le chemin du répertoire principal de travail. A la

suite nous allons trouver la liste des répertoires à considérer et contenus dans ce

dernier.

RIMS_COM : Elle contient le chemin du répertoire « com » contenant les fichiers

.com,

RIMS_INC : Elle contient le chemin du répertoire « inc » contenant les fichiers .h et

.ph,

RIMS_PC : Contient le chemin du répertoire « pc » contenant les fichiers pc_sub,

RIMS_PC3 : Contient le chemin du répertoire « pc3 » contenant les fichiers

pc_main,

RIMS_JAVA : Contient le chemin du répertoire « java » contenant les fichiers .java,

RIMS_SQL : Contient le chemin du répertoire « sql » contenant les fichiers .sql,

RIMS_DATA : Contient le chemin du répertoire « data » contenant les fichiers data.

Nous trouvons encore d’autres variables d’environnements telles que :

DIR_UPDATE : C’est le chemin du fichier qui contient la liste des répertoires

(variables d’environnements) à prendre en considération pour effectuer les mises à

jour,

LOG_FILE : C’est le chemin du fichier journal qui gardera la trace du

fonctionnement du programme,

ALL_FILES_OUTPUT : C’est le chemin du fichier que le programme génèrera et

qui contient la liste des fichiers présents dans notre répertoire de travail (RIMS_DIR).

On aura deux exemplaires de ce fichiers : l’un issu du serveur local et l’autre issu du

serveur distant.

MAJ_OUTPUT_FILE : C’est le chemin du fichier qui contiendra les mises à jour à

télécharger.

USER_DIST : C’est le compte utilisateur avec lequel on se connecte sur le serveur

distant.

IP_DIST : C’est l’adresse du serveur distant.

PASS : C’est le mort de passe du compte utilisateur utilisé.

9

Stage d’Eté


Ainsi en définissant ces variables, les entrées du fichier main_directories.txt ne sont

pas des emplacements de répertoires, mais des variables d’environnement contenant ces

valeurs.

Il reste à mentionner que le choix de ces variables d’environnements n’est pas définitif

et on peut selon les besoins leur apporter des modifications, soit en ajoutant de nouvelles

variables, soit en modifiant les valeurs de celles existantes.

Maintenant, revenons au fonctionnement de l’application. D’après la figure 1, on peut

distinguer cinq grandes étapes :

Connexion et génération de la liste des fichiers (all_files_list_dist) sur le serveur

distant. Cette étape est gérée par le module list_dist.

Transfert de all_files_list_dist du serveur distant vers le serveur local. Cette étape est

gérée par le module dist_to_loc.

Génération de la liste des fichiers sur le serveur local (all_files_list_loc). C’est le

module gen_all_file_list qui gère cette étape.

Comparaison de all_files_list_dist et all_files_list_loc et génération de la liste des

mises à jour (maj_output). C’est le module compare_files qui assure cette opération.

Téléchargement des mises à jour si elles existent. Ce traitement est assuré par le

module maj_download.

Autre que ces modules, on trouve d’autres modules supplémentaires qui son très

importants pour le bon fonctionnement de l’application :

Le module var_dist, qui permet de récupérer la valeur d’une variable

d’environnement du serveur distant.

Le module loc_to_dist, qui permet de placer le fichier main_directories.txt

(DIR_UPDATE) sur le serveur distant pour s’en servir lors de la génération de la liste

des fichiers sur le serveur distant.

Le module convert_time qui prend en entrée le fichier all_files_list_dist pour

convertir les dates et heures de modification des fichiers distants aux dates et heures

de modification des fichiers locaux. Ce traitement est nécessaire lorsque les deux

serveurs, local et distant, n’appartiennent pas au même fuseau horaire, ce qui est le cas

pour nous, pour pouvoir ensuite effectuer la comparaison correctement.

10

Stage d’Eté


Les modules clean et clean_dist qui ont pour rôle d’effacer tout fichier tampon utilisé

au cours de l’exécution de l’application.

II- Conception détaillée

Une fois tous les modules et les étapes définis, il est temps de se concentrer maintenant

sur chaque module indépendamment.

Au début, ce sont les modules principaux qui seront décrits c'est-à-dire ceux qui

correspondent aux cinq étapes décrites auparavant.

Le premier module à décrire est le module gen_all_files_list. Il est très important vu

que ce traitement sera exécuté sur les deux serveurs pour pouvoir générer pour l’un et l’autre

la liste des fichiers contenus dans le répertoire RIMS_DIR. Ce module lit à partir du fichier

DIR_UPDATE les répertoires à mettre à jour, puis pour chaque répertoire, il invoque un

autre module, gen_files_list, qui génère la liste des fichiers contenus dans l’arborescence du

répertoire lu. A la fin de ce traitement, on obtient le fichier ALL_FILES_OUTPUT. Ceci

implique que les deux modules gen_all_files_list et gen_files_list doivent être présents aussi

bien sur le serveur distant que sur le serveur local, ce qui nous amène au deuxième module

qui est list_dist.

Ce module, list_dist, prend comme paramètre la valeur de la variable d’environnement

RIMS_DIR du serveur distant. C’est le répertoire où se trouvent les deux modules

gen_all_files_list et gen_files_list sur le serveur distant. Le rôle de ce module est de se

connecter au serveur distant et ensuite générer la liste des fichiers distants via

gen_all_files_list.

Une fois la liste distante est générée, le module dist_to_loc se charge de son transfert du

serveur distant vers le serveur local en prenant comme paramètres l’emplacement de ce fichier

sur le serveur distant et l’emplacement où il doit être stocké sur le serveur local.

11

Stage d’Eté


Jusqu’ici les étapes terminées sont les deux premières. Celle qui vient juste après est la

génération de la liste des fichiers sur le serveur local et c’est le module gen_all_files_list qui

assure cette tâche comme mentionné auparavant.

Maintenant que les deux fichiers, la liste des fichiers sur le serveur local et la liste des

fichiers sur le serveur distant, sont à notre disposition, la comparaison peut être effectuée via

le module compare_files qui prend comme paramètres les deux listes : le premier paramètre

est le fichier local, le deuxième est le fichier distant (l’ordre est très important pour la fiabilité

des résultats). La comparaison entre les fichiers se base sur leurs dates de modification. Le

test se fait tout d'abord sur les années, les mois, puis les jours, ensuite les heures et enfin les

minutes pour déterminer si un fichier du serveur distant est plus récent que son homologue sur

le serveur local. Le produit de ce module est le fichier MAJ_OUTPUT_FILE qui contient

les fichiers existants sur le serveur distant et qui sont plus récents que ceux existants sur le

serveur local ou encore les fichiers qui existent sur le serveur distant et non sur le serveur

local.

La dernière étape est donc le téléchargement des mises à jour. C’est le module

maj_download qui assure ce traitement. Ceci consiste à télécharger chaque fichier présent

dans le fichier MAJ_OUTOUT_FILE et le placer dans le répertoire équivalent du serveur

local à celui où il était placé sur le serveur distant, par exemple si un fichier était placé dans le

répertoire RIMS_COM sur le serveur distant, il doit aussi être placé dans le répertoire

RIMS_COM sur le serveur local. Ce module fait appelle à un autre, dist_to_loc, qui assure le

transfert d’un fichier du serveur distant vers le serveur local. Ce module prend comme

paramètres la source du fichier à télécharger et la destination où il doit être stocké.

Ainsi les grandes lignes sont tracées et reste à décrire les autres modules

supplémentaires.

Comme mentionné auparavant, l’entrée de cette application est le fichier

DIR_UPDATE qui contient la liste des répertoires à mettre à jour. Ce fichier doit être

éditable par l’administrateur selon ces besoins et puisque ce fichier doit être présent sur le

serveur distant pour la génération de la liste des fichiers, on doit donc en créer une copie sur le

12

Stage d’Eté


serveur distant. C’est au module loc_to_dist d’assurer cette opération. Il a deux paramètres :

la source (serveur local) et la destination (serveur distant).

Lors du déroulement de l’application, plusieurs situations nécessitent la connaissance

des valeurs des variables d’environnements du serveur disant. Le module var_dist assure

cette fonction en se connectant au serveur distant et récupérant la valeur de cette variable. Il

prend donc comme paramètre le nom de la variable d’environnement nécessaire pour

renvoyer sa valeur.

Un autre module important pour le bon déroulement de notre application est

convert_time. Ce module est nécessaire vu que les deux serveurs n’appartiennent pas au

même fuseau horaire : l’un à Tunis, l’autre à Londres. Deux paramètres sont passés à ce

module : le fichier à convertir (celui téléchargé du serveur distant) et le fichier avec les dates

convertit dans l’heure du serveur local.

Enfin, les deux modules clean et clean_dist sont responsable d’enlever tous les fichiers

qui ont servi lors de la synchronisation : clean pour le nettoyage au niveau du serveur local,

clean_dist au niveau du serveur distant.

Bien qu’une description détaillée de tous les modules soit fournie, il reste encore à fixer

quelques choix concernant le protocole de connexion, la méthode d’authentification et le

protocole de transfert de fichiers qui sont primordiaux pour le développement de l’application.

Concernant le protocole de connexion, il y a deux solutions possibles : soit utiliser le

protocole Telnet, soit utiliser SSH (Secure SHell). Cependant, nous avons penché pour la

connexion via SSH pour des raisons de sécurité. L'échange de clé de chiffrement en début de

connexion permet d'échanger des trames chiffrées durant la connexion, empêchant ainsi

l'utilisation d'un sniffer permettant de voir en clair ce que fait l'utilisateur. L'utilisation de SSH

permet ainsi d'éviter la compromission des mots de passe, qui circulent en «clair» sur le

réseau. En outre, cela oblige à disposer d'une authentification renforcée des machines, pas

seulement basée sur le nom ou l'adresse IP (qui peuvent être falsifiés) [Net1].

13

Stage d’Eté


Pour SSH, il existe deux méthodes d’authentification : authentification par mot de passe

ou authentification par clés symétriques.

Pour la première méthode, lors de la connexion, l’utilisateur est invité à entrer un mot

de passe qui est transmis au serveur, qui le compare à une empreinte du mot de passe associé

à l'utilisateur. Le mot de passe en clair est encapsulé dans une communication secrète, et

devient «inviolable» sur le réseau.

Pour l’authentification par clés symétriques, il y a trois étapes principales pour établir

une connexion et qui sont [Net1]:

Génération de «bi-clé asymétrique» (c'est à dire un couple clé-privée/clé-publique)

sur une machine, en général la machine cliente. Cette bi-clé est stockée dans un sous-

répertoire (par exemple ~/.ssh avec OpenSSH) de l'utilisateur.

Copie de la clé publique sur la machine serveur sur laquelle on souhaite pouvoir

utiliser cette authentification. Cela consiste à ajouter la ligne correspondant à la clé

publique présente dans le répertoire où elle a été générée (par exemple, le contenu du

fichier ~/.ssh/id_dsa.pub) dans un fichier du serveur situé dans le répertoire de

l'utilisateur (par exemple ~/.ssh avec OpenSSH). Le nom de ce fichier dépend de la

version de SSH mais se nomme souvent authorized_keys ou authorization.

Entrée de la «passphrase» au moment de la séquence de connexion. Afin

d'automatiser l'entrée de la «passphrase», il est possible d'utiliser un utilitaire

permettant de ne la rentrer qu'une seule fois par session locale : ssh-agent.

En utilisant cette méthode d’authentification, il suffit d’effectuer les trois étapes

précédentes une seule fois pour permettre à cet utilisateur de toujours se connecter au serveur,

sauf que ceci implique d’effectuer des changements dans l’un des fichiers du serveur distant.

C’est pourquoi cette solution a été rejetée suite aux exigences de l’entreprise et nous avons

opté donc pour l’authentification par mot de passe.

En ce qui concerne le transfert de fichiers, il existe trois protocoles de transfert de

fichiers : FTP, SFTP ou SCP.

14

Stage d’Eté


FTP ou File Transfer Protocol a été utilisé pendant de nombreuses années en tant que

principale méthode pour transférer des fichiers d'un ordinateur à un autre. Les clients FTP et

les serveurs sont très largement disponibles. Toutefois, il existe des problèmes de sécurité

avec FTP. Quand vous établissez une connexion FTP, votre mot de passe sur le système

distant est transmis sans aucune forme de cryptage. FTP n’est donc généralement pas

recommandé.

L’alternative sécurisée de FTP est SFTP (un peu comme FTP, avec un peu moins de

fonctionnalités mais encore plus sécurisé) et SCP (Secure Copy), sauf que ces deux protocoles

offrent différents avantages.

Suite à l’établissement d’une connexion via SFTP, l’utilisateur peut effectuer une série

d’opération (y compris plusieurs qui ne sont pas réellement des transferts, tels que lister le

contenu d’un répertoire ou même la suppression de fichiers sur le système distant). Avec SCP,

une seule commande permet de transférer un fichier ou un groupe de fichiers, mais pour lister

par exemple les fichiers d’un répertoire sur le système distant, il faudrait y procéder en

utilisant une session SSH indépendante [Net2].

Or, selon les étapes décrites auparavant, le transfert de fichiers est indépendant de tout

autre traitement, et toute opération autre que le transfert de fichiers sur le serveur distant est

assurée par SSH, ce qui nous mène à choisir SCP qui a l’avantage de transférer un groupe de

fichier ce qui n’est pas le cas avec SFTP.

III-Conclusion

Dans ce chapitre nous avons détaillé la conception de notre application et des différents

modules qui la forment. Et maintenant, après avoir détaillé la conception, fixé le protocole et

la méthode de connexion ainsi que le protocole de transfert, nous allons passer au chapitre

suivant qui traite la phase de réalisation.

15

Stage d’Eté


Chapitre4: Réalisation

Dans ce chapitre, nous présentons le travail réalisé, le choix de la plateforme utilisé ainsi que

l’environnement de développement et les différentes techniques utilisées pour le codage de la

solution.

I- L’environnement de développement

1. Environnement matériel :

La mise en place de mon application est faite sur une machine qui a les caractéristiques

suivantes :

Processeur Intel Pentium 4 avec une fréquence d’horloge de 3.06GHz.

Mémoire vive de taille 1 Go.

Disque dur de capacité 80Go.

Ecran 17 pouces.

2. Environnement logiciel

1.1. Red Hat Entreprise Linux

Le système d’exploitation utilisé pour le développement de l’application est Red Hat

Enterprise Linux (souvent abrégé RHEL). C’est une distribution Linux produite par Red Hat et

orientée vers le marché commercial et les serveurs d'entreprise. Red Hat prend en charge chaque

version du logiciel pour une durée de 7 ans après sa sortie. Tout l'appui officiel, toutes les

formations et certifications de Red Hat — RHCT, RHCE, RHCSS et RHCA — pour le déploiement

de matériel et de logiciel portent sur la plateforme Red Hat Enterprise Linux.

De nouvelles versions de RHEL sont livrées tous les 18 à 24 mois. Quand Red Hat fournit une

nouvelle version de RHEL, les clients peuvent mettre à jour leur version gratuitement à condition

d'avoir un abonnement en cours.

16

Stage d’Eté


Toutefois, les restrictions sur la marque déposée ne permettent pas la copie et la redistribution

de la distribution complète [Net3].

1.2. Shell Unix

Pour parvenir à bien développer cette application, c’est le Shell Unix qui sera utilisé vu la

variété des commandes qu’il offre.

[http://www.commentcamarche.net/linux/linshell.php3]

L'interpréteur de commandes est l'interface entre l'utilisateur et le système d'exploitation, d'où

son nom anglais «shell», qui signifie «coquille».

Le shell est ainsi chargé de faire l'intermédiaire entre le système d'exploitation et l'utilisateur

grâce aux lignes de commandes saisies par ce dernier. Son rôle consiste ainsi à lire la ligne de

commande, interpréter sa signification, exécuter la commande, puis retourner le résultat sur les

sorties.

Le shell est ainsi un fichier exécutable chargé d'interpréter les commandes, de les transmettre

au système et de retourner le résultat. Il existe plusieurs shells, les plus courants étant sh (appelé

«Bourne shell»), bash («Bourne again shell»), csh («C Shell»), Tcsh («Tenex C shell»), ksh

(«Korn shell») et zsh («Zero shell»). Leur nom correspond généralement au nom de l'exécutable.

Chaque utilisateur possède un shell par défaut, qui sera lancé à l'ouverture d'une invite de

commande. Le shell par défaut est précisé dans le fichier de configuration /etc/passwd dans le

dernier champ de la ligne correspondant à l'utilisateur. Il est possible de changer de shell dans une

session en exécutant tout simplement le fichier exécutable correspondant, par exemple : /bin/bash

[Net4].

1.3. Shell utilisant Expect

Un autre type de scripts Shell a été utilisé lors de la phase de développement : ce sont les

scripts utilisant Expect.

17

Stage d’Eté


[Translation basée sur le man de linux (man expect)]

Expect est un programme qui "parle" à d'autres programmes interactifs selon un script.

Suivant ce dernier, Expect sait à quoi s'attendre d'un programme et ce que la bonne réponse devrait

être. Un langage interprété prévoit des structures de branchement et de contrôle de haut niveau

pour diriger le dialogue. En outre, l'utilisateur peut prendre le contrôle et interagir directement à la

demande, et après, rendre le contrôle au script. Expect est basée sur TCL.

Le nom «Expect» provient de l'idée d'envoyer ou de s'attendre à (send/expect) des séquences,

popularisée par uucp, kermit et d'autres programmes de contrôle du modem. Mais contrairement à

uucp, Expect est généralisé afin qu'il puisse être exécuté avec n'importe quel programme et

n'importe quelle tâche. Expect peut en fait parler à plusieurs programmes en même temps.

En général, Expect est utile pour faire fonctionner n'importe quel programme qui requiert une

interaction entre le programme et l'utilisateur. Ce qui est important est que l'interaction peut être

caractérisée par programmation. Expect peut également rendre le contrôle à l'utilisateur (sans

arrêter le programme étant contrôlé) s'il le souhaite. De même, l'utilisateur peut redonner le contrôle

au script à tout moment (Cette partie est à la base une traduction du manuel de expect sous Linux).

Trois commandes sont au cœur de la puissance de expect : send, expect et spawn. La

commande send prend une chaîne comme argument et l’envoie à un processus. Par exemple :

send "hello world"

Cette commande envoie la chaîne hello world. Si expect est déjà en interaction avec un logiciel, la

chaîne sera envoyée à ce programme. Mais initialement, send l’envoie à la sortie standard.

La commande expect est l’opposé de send. Elle attend une réponse qui provient

habituellement d’un processus. La commande expect peut s’attendre à une chaîne bien spécifique,

mais plus souvent expect est utilisée pour s’attendre à toute chaîne qui correspond à un motif donné.

La commande spawn lance un autre programme. Un programme en cours d’exécution est

connu comme un processus. Expect est flexible et reconnait les humains comme des processus ce

qui nous permet d’utiliser les mêmes commandes pour les humains et les processus. La seule

différence est que les processus doivent d’abord être lancés et c’est ce que fait la commande spawn.

18

Stage d’Eté


Le premier argument de la commande spawn est le nom du programme a lancé. Les autres

arguments sont passés à ce dernier [Net5].

Ci-dessous un exemple utilisant le programme Expect :

Figure 2 : Exemple de script utilisant le programme Expect

Dans cet exemple, la commande scp est lancée. Le système renvoie une chaîne se terminant

par « password : ». Ensuite, il y a envoie du mot de passe au système qui après vérification, renvoie

le prompt.

1.4. Cron et Crontab

Cron et Crontab jouent un rôle primordial dans l’automatisation de la synchronisation des

environnements distants.

Cron

Cron est le nom d'un programme qui permet aux utilisateurs des systèmes Unix d'exécuter

automatiquement des scripts, des commandes ou des logiciels à une date et une heure spécifiées à

19

Stage d’Eté


l'avance, ou selon un cycle défini à l'avance. Le nom est dérivé du grec chronos (χρόνος), signifiant

le temps.

Il s'agit d'une fonctionnalité très utile pour des tâches routinières d'administration système,

mais elle peut très bien être exploitée pour tout autre chose. Par exemple, on peut demander à cron

de jouer tel fichier mp3 tous les jours à sept heures sauf le samedi et le dimanche afin de se réveiller

en musique.

Cron est un démon (daemon), ce qui ─ dans le jargon Unix ─ désigne un programme qu'on ne

lance qu'une seule fois après le démarrage de l'ordinateur et qui reste en tâche de fond en attendant

qu'on ait besoin de lui. Le démon cron (crond) attend ainsi jusqu'au moment spécifié dans le fichier

de configuration (que l'on appelle la crontab) puis effectue l'action correspondante et se rendort

jusqu'à l'événement suivant.

Le démon cron est lancé par le compte root. Si on le tue (par la commande kill), il est

automatiquement relancé par le système [Net6].

Crontab

Crontab est le nom du programme sous Unix (ou Linux) qui permet d'éditer des tables de

configuration du programme cron. La commande crontab édite en fait un fichier relatif à

l'utilisateur qui l'exécute, et en vérifie la syntaxe. Ce fichier se situe dans l'arborescence /var, par

exemple :

/var/spool/cron/crontabs/utilisateur (AIX, HP-UX, Debian GNU/Linux et Ubuntu)

/var/spool/cron/tabs/utilisateur (SuSE GNU/Linux)

/var/cron/tabs/utilisateur (FreeBSD et OpenBSD)

Ainsi pour l'utilisateur root sur une machine Debian, la table cron sera stockée dans :

/var/spool/cron/crontabs/root

Certains systèmes Linux (SuSE, Debian, RedHat) disposent en plus d'une crontab centralisée

dans /etc/crontab. Sur SuSE, on trouve également /etc/cron.d, /etc/cron.hourly, /etc/cron.daily,

/etc/cron.weekly et /etc/cron.monthly [Net7].

20

Stage d’Eté


Pour lancer crontab et configurer crond, il suffit de taper : crontab -e et on tombe sur un écran

vi. Les paramètres sont pris en compte dès que l'on quitte vi. Les lignes de crontab sont de deux

genres : des commandes cron qui sont les commandes système à exécuter et à quel moment, et des

(re)définitions de variables d'environnement. On donne ligne par ligne les commandes à exécuter.

Les lignes ont le format suivant :

moment commande

Les commandes sont tout simplement celle que l'utilisateur taperait s'il les exécutait lui-même.

Un moment se décompose en 5 champs :

Minute : 0 – 59

Heure : 0 -23

Jour du mois : 1 – 31

Mois : 1 – 12

Jour de la semaine : 0 – 7 (0 et 7 pour dimanche)

Pour chaque unité de temps (minute/heure/...) les notations possibles sont :

* : a chaque unité de temps

2-5 : les unités de temps (2,3,4,5)

*/3 : toutes les 3 unités de temps (0,3,6,...)

5,8 : les unités de temps 5 et 8

Chaque champ est séparé par un espace et plusieurs éléments du même type sont séparés par

des virgules (sans espace). Exemple sous Linux :

0,10,20,30,40,50 * 1 * 7 /usr/bin/test

Cette ligne signifie : "exécute /usr/bin/test toutes les 0, 10, 20... minutes de toutes les heures du

premier jour de chaque mois qui doit être un lundi (tous les ans)...". La combinaison est assez

étrange de par son sens, mais c'est relativement puissant. Le principe en gros est de ne paramétrer

que les éléments qui sont intéressants et de mettre une * pour les autres. Pour lancer test toutes les

minutes, il suffit de taper :

* * * * * /usr/bin/test

La plus petite fréquence avec laquelle on exécute une commande est donc de 1 minute.

21

Stage d’Eté


Les lignes de crontab permettent aussi de (re)définir des variables d'environnement pour

l'exécution des commandes cron. Cela se fait très simplement :

VARIABLE=VALEUR

Cela va attribuer la valeur VALEUR à la variable d'environnement VARIABLE.

Le shell utilisé sous Red Hat Entreprise Linux est bash (Bourne Again Shell). Pour que les

variables d’environnement définies dans le chapitre précédent soient prises en compte à chaque fois

qu’on lance le terminal ou qu’on exécute un script, elles ont été définies dans le fichier

$HOME/.bashrc, sauf que ce fichier n’est pas lu avant l'exécution des commandes par cron. Cela

peut entraîner des comportements étranges des scripts et difficiles à comprendre. Pour résoudre le

problème, il faut sourcer ce fichier avant de lancer la commande. Par exemple [Net8]:

* * * * * . $HOME/.bashrc; /usr/bin/test

II- Tests et validation

Plusieurs tests ont été effectués pour vérifier le bon fonctionnement de notre application en ce

qui concerne la génération des listes de fichiers, ainsi qu’à la connexion au serveur distant et le

transfert de fichiers entre les deux serveurs. D’autres tests ont porté aussi sur le lancement

automatique et le bon fonctionnement du programme cron.

III-Chronogramme du projet

La figure ci-dessous représente les durées des différentes tâches effectuées pendant ce projet

durant la période de sept semaines.

N°Semaine 1 2 3 4 5 6 7

Documentation

Spécification

conception

réalisation

Test et validation

Rédaction du rapport

Figure 3 : Le chronogramme du projet

22

Stage d’Eté


23

Stage d’Eté


IV- Conclusion

Suite à la présentation de ces outils et ces notions qui permettrons de mieux comprendre le

fonctionnement de l’application, nous allons maintenant entamer la phase d’analyse et spécification.

24

Stage d’Eté


Conclusion générale

Ce projet d’été s’est déroulé au sein de la société GL Trade. Il a pour objectif la

synchronisation d’environnements de développement distants (Londres/Tunis).

Ce projet a été une bonne occasion pour approfondir pour mettre en pratique mes

connaissances concernant le système d’exploitation Linux et de les approfondir encore plus en

exploitant d’autres techniques et outils de développement tels que la manipulation des crontab et

l’utilisation du programme expect.

D’autre part, ce projet a constitué une bonne occasion d’intégrer le milieu professionnel

puisqu’il représente ma première expérience au sein d’un établissement professionnel autre que

l’ENSI ce qui m’a fait découvrir davantage le travail au sein d’un groupe.

Enfin, l’application réalisée reste un point de départ qui laisse des grandes possibilités

d’extension et d’amélioration surtout pour généraliser son fonctionnement aux serveurs de toutes les

filiales de GL Trade et ne plus se contenter de l’employer entre le serveur de Londres et celui de

Tunis seulement.

25

Stage d’Eté


Neto graphie

[Net1] http://virologie.free.fr/documents/openSSH/ssh_introduction.html

[Net2] http://www.cam.ac.uk/cs/filetransfer/compare.html

[Net3] http://fr.wikipedia.org/wiki/Red_Hat_Enterprise_Linux

[Net4] http://www.commentcamarche.net/linux/linshell.php3

[Net5] http://oreilly.com/catalog/expect/chapter/ch03.html

[Net6] http://fr.wikipedia.org/wiki/Cron

[Net7] http://fr.wikipedia.org/wiki/Crontab

[Net8] http://www.themanualpage.org/unix/cron.php

26

Stage d’Eté


TABLE DES MATIERES

INTRODUCTION............................................................................................................................... 1

CHAPITRE 1 : PRÉSENTATION GÉNÉRALE..............................................................................2

I- Introduction.......................................................................................................................................... 2

II- Présentation de l’organisme d’accueil....................................................................................................21. GL Trade....................................................................................................................................................22. GL Trade MENA.........................................................................................................................................3

III- Présentation du sujet........................................................................................................................ 4

IV- Conclusion........................................................................................................................................ 4

CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS.................................................5

I- Etude de l’existant et solution retenue..................................................................................................51. Etude de l’existant.....................................................................................................................................52. Solutions envisagées.................................................................................................................................53. Solution retenue........................................................................................................................................6

II- Besoins fonctionnels.............................................................................................................................. 6

III- Besoins non fonctionnels................................................................................................................... 7

IV- Conclusion........................................................................................................................................ 7

CHAPITRE 3 : CONCEPTION DU LOGICIEL...............................................................................8

I- Conception générale.............................................................................................................................. 8

II- Conception détaillée............................................................................................................................ 11

III- Conclusion....................................................................................................................................... 15

CHAPITRE4: RÉALISATION........................................................................................................ 16

I- L’environnement de développement...................................................................................................161. Environnement matériel :.......................................................................................................................162. Environnement logiciel............................................................................................................................16

2.1. Red Hat Entreprise Linux................................................................................................................162.2. Shell Unix........................................................................................................................................17

27

Stage d’Eté


2.3. Shell utilisant Expect.......................................................................................................................172.4. Cron et Crontab..............................................................................................................................19

II- Tests et validation............................................................................................................................... 22

III- Chronogramme du projet................................................................................................................ 22

IV- Conclusion....................................................................................................................................... 23

CONCLUSION GÉNÉRALE............................................................................................................. 24

NETO GRAPHIE.............................................................................................................................. 25

28

Stage d’Eté


TABLE DES FIGURES

Figure 1: Implantations géographiques de GL Trade dans le monde......................................................3Figure 2 : Exemple de script utilisant le programme Expect.................................................................19Figure 3 : Le chronogramme du projet.................................................................................................22

29

rapport stage d'été

Documents

Transcript of rapport stage d'été