Page suivante Page précédente Table des matières 5. Débogage de programmes CGI sur des sockets TCP Par Kevin O'Malley omalley@umich.edu 5.1 Historique Cet article est le fruit de ma frustation en développement et correction de programmes (débogage) CGI écrit pour AuctionBot http://auction.eecs.umich.edu, un serveur de vente aux enchères multi-fonctions. J'ai trouvé que les librairies C disponibles, les librairies de classe C++ et les extensions de serveurs web ne répondaient pas à mes besoins, aussi ai-je décidé d'implémenter une approche différente basée sur le débogage de programmes sur des sockets TCP. En utilisant cette approche, j'ai implémenté avec succés et corrigé la plupart des CGI de ce projet. Ma machine de développement au travail est une Sun Ultra 1 utilisant Solaris 2.5. Chez moi j'ai une station Linux utilisant la RedHat 5.0. J'ai développé tout mon code de débogage sous Linux. Linux fournit un environnement de développement trés stable qui m'a permis de développer, tester et expérimenter localement, sans avoir besoin de me connecter à distance sur le Sun. Une fois que le code a fonctionné, je l'ai simplement mis sur le Sun, recompilé et ai commencé à l'utiliser. 5.2 Vue d'ensemble Corriger (déboguer) des programmes CGI (Common Gateway Interface : Interface Passerelle Unifiée) présente un défi unique que l'on ne trouve pas lorsqu'on débogue des programmes dans des environnements plus traditionnels. Les CGI sont exécutés par le serveur web et tournent dans l'environnement créé par le serveur web. Cela rend le temps d'exécution du CGI fortement lié au paramétrage d'environnement du serveur web. Un développeur ne peut pas simplement exécuter un CGI à partir d'un shell, ou sous un correcteur de programme (debogueur), et s'attendre à ce qu'il se comporte de la même manière que lorsqu'il s'exécute dans un environnement de serveur web. Une technique commune pour déboguer les CGI implique de capturer l'environnement sous lequel le CGI est exécuté (habituellement dans un fichier disque), restaurer l'environnement sur une machine locale et exécuter le CGI localement dans cet environnement restauré. Utilisant cette technique, les CGI peuvent être exécuté à partir de la ligne de commande, ou à partir d'un débogueur (gdb par exemple) et déboguer en utilisant des techniques classiques de correction. Cette technique est directe, mais demande au développeur de fournir le travail supplémentaire de capture et de restauration de l'environnement d'exécution du CGI. Un autre problème dans la correction des CGI est d'observer l'affichage d'un CGI qui ne fonctionne pas correctement. Si vous utilisez Apache 1.2 ou suivant, cela peut être redirigé, par configuration du serveur web, vers un fichier de trace des messages d'erreurs. Cette approche fonctionne pour quelques classes de problèmes, mais ne fourni pas la granularité que je voulais. On pourrait écrire des informations de débogage/états dans des fichiers de trace et utiliser tail -f fichierdetraces pour voir le fichier. Cela fonctionne, mais peut produire des conditions de blocage définitif si plusieurs copies de votre CGI sont en cours et qu'ils essayent d'accéder aux mêmes ressources partagées (le fichier de trace) et n'utilisent pas le verrouillage de fichier. Les développeurs doivent fournir le code de verrouillage de fichier et prendre en charge les conditions éventuelles de blocage, en incluant les cas où le CGI plante avant qu'il libère son fichier de verrou (1). De plus, toutes les écritures doivent être atomique pour s'assurer d'un affichage correct. Idéalement, on aimerait corriger les CGI dans leur milieu naturel, c'est-à-dire dans l'environnement créé par le serveur web, sans travail d'installation supplémentaire. 5.3 Ma solution basée sur les sockets Une technique différente est d'utiliser les sockets réseaux pour écrire des informations de trace en utilisant des fontions style printf vers une application serveur de trace tournant sur la machine locale des développeurs, ou n'importe quelle machine sur le réseau. En utilisant cette technique, les CGI's peuvent être tracés et surveillés rapidement et facilement dans l'environnement serveur. La classe SocketDB fournie le comportement requis pour tracer les CGI sur des sockets TCP. La classe fournit des méthodes pour se connecter au serveur et écrire des chaînes au travers de sockets TCP. class SocketDB { private: int mSD; ErrorTypes mErrorType; int mConnected; public: SocketDB(); SocketDB(char *name, int port); ~SocketDB(); int Connected() { return mConnected; } int ErrorType() { return mErrorType; } int Connect(char *name, int port); int Print(char *format,...); int Println(char *format,...); }; Pour vous connecter au serveur, utilisez le constructeur SocketDB en passant le nom du serveur et le port, ou utilisez la méthode Connect. Chacune essaiera de se connecter au serveur sur le port indiqué. Utilisez la méthode Connected pour déterminer si la connexion est réussie ou utilisez la valeur de retour de Connect. La méthode Connect retourne 1 si c'est connecté, 0 sinon. Si une erreur de connexion apparait, utilisez la méthode ErrorType pour obtenir les informations d'erreur. Le fichier Socket.C énumère les type d'erreurs. 5.4 Le client Le programme DebugClient (voir DebugClient.C) montre comment utiliser la classe. Pour simplifier, j'ai conçu ce programme pour qu'il soit exécuté depuis la ligne de commande, plutôt que de vous montrer un programme CGI exécuté par un serveur web. J'ai choisi cette approche pour que les utilisateurs puissent rapidement exécuter le programme et voir comment la classe socket de débogage fonctionne. Intégrer la classe dans un CGI est aussi simple. 5.5 Un serveur de débogage Le programme DebugServer (voir DebugServer.C) implémente un exemple de serveur de débogage (2). Ce programme est un simple serveur d'écho qui crée une socket, s'y attache et accepte les connexions des clients. Lorsqu'il reçoit une connexion, il crée un processus fils qui prend en charge cette connexion. Dans ce cas précis il lit simplement une chaîne de caractère et la renvoie en écho. 5.6 Utiliser le programme Pour utiliser le client et le serveur de débogage, cd vers le répertoire contenant les programmes d'exemple et tapez DebugServer [port] où le port est celui que vous voulez que le serveur écoute. Par exemple, pour exécuter le programme sur le port 4000, tapez DebugServer 4000. Dans un autre shell, cd vers le répertoire contenant les programmes d'exemple et tapez DebugClient [host] [port] où l'hôte est le nom d'hôte de la machine sur laquelle tourne le serveur (vous pouvez l'obtenir en tapant hostname au prompt de l'interpréteur) et le port est celui où le serveur écoute (4000 dans l'exemple). 5.7 Conclusion Utiliser les sockets réseau pour écrire des informations d'état et de debug à un serveur d'application est une technique efficace et souple pour surveiller et déboguer les programmes CGI. En utilisant cette méthode, les développeurs peuvent rapidement déboguer les CGI alors qu'ils s'exécutent dans l'environnement du serveur. 5.8 Références (1). W. R. Steven, 1990, UNIX Network Programming. New Jersey: Prentice-Hall, Inc, pp. 88-101. (2). W. R. Steven, 1990, UNIX Network Programming, Network APIs: Sockets and XTI Volume 1. New Jersey: Prentice-Hall, Inc. Code : http://groucho.eecs.umich.edu/~omalley/software/socket_debug-1.0.tar.gz Copyright 1998, Kevin O'Malley - Publié dans le numéro 34 de la Linux Gazette, novembre 1998 Adaptation française : Frédéric Gacquer (Neuronnexion) Page suivante Page précédente Table des matières