Système UNIX et Langages de scripts

Transcription

1 Système UNIX et Langages de scripts Projet Les deux sujets sont à faire, en binôme! 1 Bash : Gestion d une bibliothèque numérique L objectif est de gérer une bibliothèque numérique (un ensemble de livres au format numérique). Pour cela, vous disposez (initialement) d un unique répertoire contenant un ensemble de fichiers sous différents formats (.pdf,.jpg,.desc) tels que : les fichiers.pdf correspondent à un livre les fichiers.jpg correspondent à une image de la couverture d un livre les fichiers.desc correspondent à la fiche descriptive d un livre Actuellement, ces fichiers sont nommés d après le titre du livre correspondant tels que chaque espace dans le titre est remplacé par un underscore. Par exemple, pour le livre Le petit prince, on retouve un fichier Le_petit_prince.pdf correspondant au livre et un fichier Le_petit_prince.desc qui contient la fiche descriptive du livre. Pour chaque livre, on doit au moins avoir un fichier.pdf et un fichier.desc correspondants, l image de la couverture étant facultative. Plusieurs livres pouvant avoir le même titre, un identifiant unique est associé à chacun et indiqué dans chaque fiche descriptive. Format d une fiche descriptive Chaque fiche contient (au moins) les champs suivants (1 par ligne) : Identifiant : initialesdunomdupremierauteur-unnombre Titre : (espaces et valeurs numériques autorisés) Auteurs : (séparés par une virgule, initiale du prénom suivi d'un point autorisés) Éditeur : Genre : Roman, Biographie, Conte, Nouvelle, Témoignage, Théâtre, BD,... Année : YYYY Couverture : oui / non Statut : lu / en cours de lecture / non lu (par défaut) Prêt : disponible / en prêt Suppression : oui / non Des champs supplémentaires tels que Collection, Pages, Langue, Résumé,... peuvent être présents mais restent facultatifs. Si le livre est en prêt, on doit retrouver les champs supplémentaires : Emprunteur : Nom Prénom Date d'emprunt : JJ/MM/YY L ordre des champs n est pas fixe. Exemple : Le_petit_prince.desc Identifiant : dse-1 Titre : Le Petit Prince Auteurs : Antoine de Saint-Exupéry Éditeur : Gallimard Collection : Folio Année : 1943

2 Genre : Roman Langue : Français Statut : lu Prêt : disponible Couverture : non Suppression : non 1.1 Travail à réaliser Objectif 1 : nouvelle charte de nommage Actuellement, il n y a pas de livres ayant le même titre donc la charte de nommage s applique correctement. Toutefois, avec l évolution de la bibliothèque, on risque d écraser des anciens livres avec une nouvelle entrée ayant le même titre. Le premier objectif est donc d écrire un script qui permet de renommer l ensemble des fichiers associés à un livre en utilisant l identifiant indiqué dans la fiche descriptive correspondante. Ainsi, l ensemble des fichiers associés au livre Le Petit Prince seront : dse-1.pdf et dse-1.desc. Les erreurs rencontrées au cours du renommage (absence de fiche descriptive, fichier en double,... ) seront reportées pendant l exécution. Des statistiques seront fournies à la fin de l exécution du script sous la forme suivante : Erreurs rencontrées : Nombre total de fichiers : Nombre de fichiers renommés : Nombre de livres : Nombre de livres sans images : Nombre de livres sans fiche descriptive : Objectif 2 : statut global de la bibliothèque On souhaite créer un fichier global permettant de connaître l état de la bibliothèque à un instant donné. Ce fichier contiendra une ligne d entrée pour chaque livre indiquant l identifiant, la date d ajout dans la bibliothèque au format JJ/MM/YY, la date et l heure de la dernière modification de la fiche descriptive au format mm :hh - JJ/MM/YY, le chemin d accès au pdf et un indicateur si le livre est en prêt. Chaque champ est séparé par un point virgule (;). Le second objectif est donc d écrire un script permettant soit de créer, soit de mettre à jour (s il existe déjà) ce fichier global. Si le fichier existe déjà, le script devra vérifier que les informations présentes sont cohérentes avec l état de la bibliothèque (les fichiers présents sont répertoriés, correctement nommés,... ). Des statistiques seront fournies à la fin de l exécution du script sous la forme suivante : Nombre total de livres : Nombre de livres ajoutés : Nombre de livres supprimés : Objectif 3 : ajout, modification et suppression d un livre La bibiothèque doit pouvoir évoluer : ajout, modification et suppression d un livre. Cette évolution devra également mettre à jour le fichier global présenté dans l Objectif 2. L ajout d un livre consiste à créer une fiche descriptive correspondante et à copier/déplacer (l utilisateur devra avoir le choix) le pdf correspondant dans le répertoire principal de la bibliothèque. Pour cela, l identifiant du nouveau livre sera déterminé automatiquement selon la charte précédemment définie tandis que les autres champs seront saisis par l utilisateur. Votre script sera donc interactif.

3 La modification affecte uniquement la fiche descriptive associée à un livre. On doit pouvoir ajouter, modifier, supprimer un champ. Attention, il faudra gérer le cas où l utilisateur édite directement la fiche et ne passe pas par votre script. L utilisateur pourra choisir de modifier un champ existant ou bien d en ajouter un nouveau. Tout comme pour l ajout, la modification d un livre se fera de façon interactive avec l utilisateur (quel livre souhaite-il modifier, quel champ veut-il modifier, quel champ veut-il ajouter,... ). La suppression consiste à supprimer de la bibliothèque un livre et l ensemble des fichiers/informations associés à celui-ci. La suppression peut être temporaire (pas du suppression physique, mise à oui du champ Suppression dans la fiche descriptive et suppression de l entrée correspondante dans le fcihier global) ou définitive (suppression physique des fichiers). La suppression sera interactive tout comme l ajout et la modification d un livre. Le troisième objectif est donc d écrire un ou plusieurs scripts permettant d ajouter, modifier ou supprimer un livre. En dehors de l obligation d interactivité avec l utilisateur, à vous de choisir le découpage ou non en plusieurs scripts permettant l implémentation de ces fonctionnalités. Vous justifierez votre choix dans le compte-rendu. Il est important de vous mettre à la place de l utilisateur concernant l intéractivité, de déterminer quelle est l approche la plus simple pour l utilisateur pour réaliser ces actions Objectif 4 : Recherche L utilisateur devra avoir la posssibilité de faire des recherches dans la bibliothèque. Celle-ci pourra être multi-critères, basée sur les différentes informations associées à chaque livre (ex : année, genre, auteur, langue,... ). Il lui sera proposé avant chaque recherche de stocker le résultat dans un fichier ou non. Le quatrième objectif est donc d écrire un script permettant à un utilisateur de faire une recherche interactive dans la bibliothèque. Il devra pouvoir chercher selon un ou plusieurs critères Objectif 5 : Statistiques En plus de la possibilité de rechercher un ou plusieurs livres, l utilisateur devra pouvoir récupérer des statistiques telles que : Nombre total de livres Nombre total de livres en prêt Nombre total de livres lus / en cours de lecture / non lus Nombre total de livres pour un auteur / une année / un genre donné... Le cinquième objectif est donc d écrire un script qui propose à l utilisateur (à travers un menu par exemple) d extraire différentes statistiques. Des exemples ont été donné précédemment mais c est également à vous d en proposer des supplémentaires. 1.2 Évaluation Les objectifs ne sont pas présentés par ordre de difficultés mais plutôt par ordre d intérêt. Si on ne peut pas modifier la bibliothèque mais uniquement rechercher des informations dessus, l intérêt est forcément moindre. Il est donc fortement conseillé de prendre les objectifs dans l ordre lors de la réalisation de votre projet. Nous évaluerons les choix d implémentation effectués mais également la robustesse de vos scripts sous certaines conditions particulières. Il est donc indispensable de solidifier vos scripts avec des tests au début, pendant voire à la fin de leur exécution. N oubliez pas de commenter au maximum votre code!

4 2 Perl : Serveur Web 2.1 Objectif Un serveur web est un logiciel servant des requêtes au format HTTP envoyées par des navigateurs souhaitant obtenir des documents. Dans le cadre de la partie Perl de votre projet de scripts, on vous demande de programmer un serveur Web en n utilisant que les modules de la bibliothèque standard de Perl (les modules «Core»). En plus de vous offrir une occasion d acquérir plus d expérience en développement en Perl, ceci vous permettra de vous frotter plus sérieusement à certains aspects majeurs de la programmation système, comme les sockets et la fonction fork du standard POSIX. 2.2 Travail à réaliser Afin de ne pas vous compliquer inutilement le travail, on ne vous demande de mettre en œuvre que les fonctionnalités de base d un serveur Web : Lit sa configuration dans un fichier texte Écoute sur une socket Réponse aux requêtes HTTP GET portant sur : Des documents statiques, qui seront alors simplement envoyés au client Des documents HTML dynamiques spécifiés au format SSI, défini ci-après, qui devront être générés par votre serveur après que celui-ci ait exécuté un fork Des répertoires, auquel cas le fichier index.html ou index.shtml est renvoyé s il existe, sans quoi un index des fichiers et sous-répertoires au format HTML est créé et renvoyé. Envoi d un message d erreur de type 501 (Not Implemented ) pour tout autre type de requête Maintien d un journal des accès et des erreurs Bonus : génèration des statistiques d accès à partir de ces journaux 2.3 Spécifications techniques Fichier de configuration Votre fichier de configuration peut être au format INI, XML ou tout autre format de votre choix. La seule contrainte est qu il doit s agir d un fichier texte, facile à comprendre et à modifier sans avoir besoin de lire une documentation. Ce fichier doit permettre, au minimum, de paramétrer le port sur lequel le serveur écoute, l emplacement des fichiers journaux, et l emplacement du répertoire contenant les documents à servir appelé la racine du serveur, car c est ce que le serveur affiche quand le navigateur demande «/» HTTP HTTP (Hypertext Transfer Protocol) est le protocole réseau, c est-à-dire en quelque sorte le langage, qu utilisent un client Web (navigateur) et un serveur Web pour communiquer. Il existe deux types de messages HTTP. Requête HTTP. Les messages transmis par un client à un serveur ont la forme suivante : méthode URI protocole en-têtes ligne vide corps La seule méthode que vous devez implémenter est GET, qui est utilisée par le client pour récupérer un document, dont l URI est spécifiée sous forme d un chemin qui doit être interprété relativement à la racine du serveur.

5 Le protocole est une chaîne de caractère du type «HTTP/1.1», mais vous pouvez l ignorer en toute tranquillité. Les en-têtes ont la forme «Nom : valeur», mais vous pouvez les ignorer également, de même que le corps. Réponse HTTP. Les réponses renvoyées au client par le serveur ont la forme suivante : protocole code de statut phrase d explication en-têtes ligne vide corps Dans votre cas, le protocole doit être «HTTP/1.0». Le code de statut est un code à trois chiffres qui représente le résultat de la requête. À chaque code correspond exactement une phrase d explication. Voici les codes que vous devez implémenter : 200. OK (tout va bien, le document suit) 400. Bad Request (erreur HTTP du navigateur) 403. Forbidden (le serveur n a pas le droit de renvoyer le document) 404. Not Found (le document n existe pas) 500. Internal Server Error (tout autre problème) 501. Not Implemented (pour toute méthode autre que GET) Certaines en-têtes sont absolument indispensables, venant du serveur. Ce sont : Content-Length. La longueur du document renvoyé, en octets. Content-Type. Le type MIME et l encodage du document renvoyé. Consultez la page man de file. Date. La date et l heure universelle (UTC), dans ce format précis : Fri, 15 Nov :34 :16 GMT Server. Le nom de votre serveur (c.-à-d. ce que vous voulez) Finalement, le corps de la réponse contient le document demandé par le navigateur. Exemple : HTTP/ OK Date: Tue, 17 Sep :51:05 GMT Server: Apache Last-Modified: Sat, 31 Aug :45:33 GMT Content-Length: 112 Content-Type: text/html; charset=iso <!DOCTYPE html> <html> <head> <title> Exemple </title> </head> <body> </body> </html>

6 2.3.3 SSI Les SSI (Server-Side Includes) étaient une façon populaire de générer des documents dynamiques avant la création du standard CGI. On en rencontre encore aujourd hui, mais moins fréquemment. Les fichiers SSI sont des fichiers HTML valides, dans lesquels certains commentaires ont un format particulier indiquant qu ils doivent être remplacés par un autre contenu. Ces fichiers portent l extension.shtml, On vous demande d implémenter au minimum ces deux formats : Inclusion. Le commentaire <!--#include file=" fichier "--> est remplacé par le contenu de fichier. Exécution. Le commentaire <!--#exec cmd=" commande "--> est remplacé par la sortie de commande. Lorsqu on implémente un serveur dans les règles de l art, on distingue généralement deux grands types de requêtes : les requêtes simples, pour lesquelles le temps d exécution peut être estimé, et est probablement inférieur au temps perdu pour faire un fork, et les requêtes plus complexes ou plus longues, pour lesquelles il peut valoir la peine de faire un fork. Les requêtes liées aux SSI appartiennent clairement à cette seconde catégorie. Vous devez en tenir compte Journaux Les serveurs Web stockent habituellement une ligne dans un fichier texte pour chaque connexion. On s attend, au minimum, à ce que cette ligne indique la date et l heure de la connexion, l adresse IP du client, l URI demandé et le résultat (code de statut) de la requête. On trouve toujours aussi un journal d erreurs plus détaillé, qui devrait contenir des informations sur les erreurs «non triviales», par exemple, dans le cas de votre serveur, les erreurs 400, 403 et Bonus : Statistiques Les journaux d accès générés par les serveurs sont fréquemment utilisés pour générés des rapports sur les statistiques de fréquentation des sites. Perl, qui est après tout le langage d extraction et de rapport, est le langage le plus couramment utilisé pour développer ce genre d application. Si vous désirez aller plus loin dans votre prise en main de Perl, développez un tel analyseur de journal. Vous pouvez vous inspirer d AWStats, (awstats.sourceforge.net), l analyseur le plus connu et le plus utilisé. Des exemples de rapports AWStats sont disponibles sur le site. Cette partie du projet étant optionnelle, vous n êtes pas obligés de générer des rapports aussi détaillés. Cependant, plus vous nous en mettez plein la vue, plus vous pourrez amasser de points bonus. 2.4 Évaluation Pour obtenir la meilleure note possible, votre application devra respecter plusieurs critères : Être entièrement fonctionnelle : nous devons pouvoir copier des fichiers à la racine de votre serveur, lancer celui-ci et, à l aide du navigateur de notre choix dirigé sur visualiser correctement ces fichiers. Être correct : même avec use strict et use warnings, votre serveur ne doit générer aucun message d erreur sur la console, ni aucun message dans le journal d erreur, sauf les messages qui sont générés par votre code. Être robuste : votre serveur ne doit jamais planter, sauf quand on le lui demande en tapant C, même en cas de mauvaise requête d un client, ou en cas de défaillance d une connexion. Être écrite avec du code de bonne qualité : outre les critères habituels indentation systématique, noms de variables et de fonctions bien choisis, utilisations de nombreuses sous-routines courtes, commentaires là où c est nécessaire, etc. vous devez respecter les bases du «style Perl» 1 1. Testez régulièrement vos fichiers sur le site perlcritic.com. Vous pouvez le configurer pour être doux (gentle), sévère (stern), dur (harsh), cruel ou brutal. Idéalement, tous vos fichiers devraient passer le niveau harsh (cela ne signifie pas que vos fichiers ne reçoivent aucune critique, mais que vous soyiez capable de justifier vos choix s ils sont criticables).

7 3 Consignes pour le rendu Date de dépôt : 13 Janvier 2014, 8h (pénalité de retard ensuite) Lieu de dépôt : sur la plateforme Arche, dans la section Projet du module L3 SIO Shell Format de dépôt : une archive zip nommée NOM1-NOM2.zip contenant : Un petit compte-rendu (8 pages maximum) indiquant le travail réalisé, la répartition des tâches, les difficultés rencontrées et les choix effectués dans l implémentation (utilisation de commandes non vues en cours, découpage du code,... ). Une archive nommée NOM1-NOM2-Bash.zip contenant le(s) script(s) et les données pour la partie Bash. Une archive nommée NOM1-NOM2-Perl.zip contenant le(s) script(s) et les données pour la partie Perl.