Administration système à partir d un navigateur Web

Administration système à partir d un navigateur Web Stéphane Billiart, billiart@irisa.fr Christine Morin, cmorin@irisa.fr Akhil Sahai, asahai@irisa.fr BULL IRISA/INRIA, Rennes L action Astrolog étudie l apport des technologies de l Internet au domaine de l administration système et réseau. Ce document présente les réalisations et travaux en cours autour d AstroWeb, une infrastructure modulaire et extensible pour l administration d un réseau local hétérogène accessible à partir d un navigateur Web. Problématique L administration d un parc informatique est nécessaire pour assurer une utilisation optimale des moyens mis à disposition des utilisateurs ainsi qu une détection efficace des problèmes qui peuvent survenir. Pour cela, divers outils d administration existent qui permettent d observer l état d un réseau, de le maintenir en opération et d être informé rapidement de tout incident. Dans le terme général d administration, on distingue traditionnellement l administration réseau [12] d une part, qui s attache à la gestion plus particulière des matériels et des couches logicielles «bas-niveau» les contrôlant et d autre part l administration système [7] qui s intéresse à la maintenance des systèmes d exploitation et des logiciels utilisateur installés sur les diverses machines. Ce document s intéresse plus particulièrement à ce deuxième aspect de l administration bien que l action Astrolog intègre aussi l administration réseau [11]. On peut distinguer deux types d approche à l administration système. La première utilise de nombreux outils spécialisés pour bâtir une solution d administration cohérente ; cette solution, courante en environnement Unix, utilise de petits outils ayant généralement une interface en ligne de commande. Ces outils sont soit conçus et distribués par les constructeurs de matériels et de logiciels, soit développés localement. L ensemble de ces outils disparates, aux interfaces utilisateurs différentes et aux fonctionnalités se chevauchant parfois, engendre des difficultés d adaptation des administrateurs contraints de passer de l un à l autre et nécessite parfois une duplication d information avec des formats différents. De plus, la spécialisation va souvent à l encontre de la portabilité, ce qui augmente encore le nombre d utilitaires à maîtriser pour gérer des systèmes hétérogènes. La seconde approche, orientée plate-forme d administration intégrée, tente de prendre en charge la majeure partie des aspects de l administration d un réseau de manière unifiée. Cependant, ces environnements comportent de nombreux inconvénients, ils sont développés spécifiquement pour un environnement, une part importante des ressources des machines d administration est monopolisée par l interface graphique et la gestion de l interactivité avec les utilisateurs, ce qui oblige à avoir une machine d administration dédiée et surdimensionnée. L interface est généralement propriétaire et fermée, ce qui empêche l intégration de nouvelles fonctionnalités ou, lorsque c est possible, requiert des développements pas toujours triviaux, ni compatibles avec l existant (langage de développement et API imposés, contraintes de conformité à l interface utilisateur) [3]. ADMINISTRATION 339

En définitive, de telles configurations ne se justifient que pour de grands réseaux d entreprise, d envergure nationale ou ayant des impératifs de disponibilité très importants mais pas pour des petits réseaux de stations de travail bureautique ou de développement. Objectifs d Astrolog L objectif de l action Astrolog est de proposer un environnement intégré pour l administration réseau et système d un réseau local de stations de travail, avec les contraintes suivantes : Les stations administrées exécutent divers systèmes d exploitation et sont elles-mêmes différemment configurées (différents processeurs, cartes matérielles, capacités mémoire ). L administration doit pouvoir se faire depuis n importe quelle station du réseau, c est-à-dire qu un administrateur peut intervenir depuis n importe quel environnement pour modifier à distance la configuration d une autre machine ou d un élément du réseau. L accès à la plate-forme d administration se fait de manière uniforme, quel que soit le système utilisé et pour toutes les fonctions disponibles. L ajout de nouvelles fonctionnalités comme la surveillance de nouveaux matériels ou l administration d un nouveau service doit être le plus aisé possible. En particulier, l intégration de services d administration existants doit être facilitée. Ceci afin de permettre au nouvel environnement d administration d être rapidement adopté par des administrateurs habitués à d autres outils. Pour satisfaire ces contraintes, l utilisation d une interface par HTTP [4] et un navigateur Web apparaît intéressante à plus d un titre. Tout d abord, l interface utilisateur est à la fois simple et riche ; elle s est de plus imposée auprès de nombreux utilisateurs. Des navigateurs existent aujourd hui pour tous les systèmes communément utilisés, on a ainsi une portabilité au moindre coût. De plus l utilisation d un navigateur impose une nette séparation entre la partie interface graphique centrée sur l interaction avec l utilisateur et la partie exécution effective des fonctions d administration, ceci introduit une meilleure répartition des tâches des développeurs tout en étant très modulaire : l ajout de fonctionnalités, le portage sur de nouveaux systèmes peuvent être progressifs. L utilisation du Web introduit par ailleurs de nouvelles contraintes. HTTP est un protocole sans état, ce qui pose des problèmes pour son utilisation dans une application client/serveur où l on a souvent une notion de session avec maintien d un certain état persistant entre deux requêtes sur le client et/ou le serveur. De plus, le modèle d interaction de HTTP est à sens unique (du client vers le serveur) et ne prévoit pas la notification d évènements non sollicités du serveur vers le client, ce qui limite le portage d une interface utilisateur. Un autre problème qui se pose pour les programmes d administration est la notion d équivalence des actions d administration. Sur différents systèmes, différentes commandes système sont nécessaires pour accomplir la même action abstraite (par exemple, effacer un fichier, créer un compte utilisateur). Pour des raisons évidentes de simplicité de déploiement et de maintenance, l ensemble des programmes d administration doit être le plus portable possible, doit donc abstraire les actions d administration pour les traduire localement selon le système d exploitation. AstroWeb AstroWeb est l environnement expérimental pour l administration système de notre réseau local composé de plusieurs stations de travail hétérogènes exécutant plusieurs systèmes d exploitation différents (Aix, Solaris, Linux, NetBSD, Windows NT). L accès aux fonctions d administration se fait de manière uniforme à partir de n importe quel navigateur Web. Le choix de l implémentation des utilitaires d administration est laissé à l administrateur, ceux-ci sont directement interfacés avec les scripts CGI de l en- 340 JRES97 La Rochelle 7-10 octobre 1997

vironnement AstroWeb. Ainsi, l architecture d AstroWeb reste très ouverte et permet l intégration de fonctionnalités existantes ou l ajout de nouvelles relativement aisément. L environnement AstroWeb utilise une machine centrale d administration sur laquelle fonctionne un serveur Web donnant accès aux diverses fonctions et qui centralise toutes les requêtes d administration. Caractéristiques AstroWeb utilise le concept de session, action logique pouvant s exécuter sur toute machine, quelle que soit sa configuration : la vérification de l espace disque disponible, la création d un compte utilisateur, la réinitialisation d une machine sont des exemples de sessions. Ces actions logiques se traduisent par différentes commandes à exécuter selon les divers systèmes. Ces commandes peuvent être soit des binaires exécutables directement ou des scripts interprétés par un autre programme. Afin d offrir une certaine indépendance vis à vis des environnements, il est pratique d écrire un script unique qui interface les commandes adéquates selon l environnement d exécution. Enfin, un mécanisme de filtre analyse les sorties des commandes et détermine ainsi leur état final. L environnement AstroWeb permet de définir et de combiner commandes et filtres en sessions pour réaliser les fonctionnalités d administration souhaitées et les exécute simultanément sur plusieurs stations en prenant en charge les problèmes d exécution distante (diffusion des scripts, problèmes de connections, expiration des délais ). A l issue de l exécution d une session sur l ensemble des machines, un rapport synthétisant les résultats est présenté à l utilisateur. La page principale d AstroWeb, représentée par la figure 1, est un formulaire permettant de sélectionner et modifier les principaux paramètres de l environnement. Ce formulaire est reçu et traité par AstroWeb qui exécute alors les commandes et les filtres sur les diverses machines sélectionnées. Figure 1 : page principale d'astroweb. L utilisation de filtres pour déterminer l état de sortie des commandes est motivée par le fait que les commandes ne suivent pas toujours les mêmes conventions sur les codes de retour ou d erreur ; de plus, seule une partie des sorties des commandes intéresse généralement l administrateur. Ainsi, à l issue de l exécution des commandes, les sorties texte (sortie standard et sortie d erreur) sont analysées par des ADMINISTRATION 341

filtres qui déterminent l état final des commandes. Les résultats sont synthétisés dans un tableau où apparaît, pour chaque machine, un icone coloré indiquant l état de sortie et des liens hypertextes vers les contenus des sorties. La figure 2 présente le rapport généré suite à la session de la figure 1 ; les chiffres constituants les liens hypertextes donnent le nombre de lignes de la sortie correspondante. Figure 2 : rapports d'exécution d'une session. Fonctionnement AstroWeb propose plusieurs modes de lancement des commandes et d analyse des résultats. L exécution à distance peut se faire par rsh ou via un serveur Web. La première solution est simple et rapide à mettre en œuvre en environnement Unix, la seconde peut être intéressante sur d autres plates-formes (sur NT, il est plus facile de trouver un démon httpd qu un démon rshd), de plus l utilisation d un serveur Web offre des possibilités supplémentaires telles que le support des commandes d administration CGI. Les commandes pouvant s interfacer avec AstroWeb peuvent être n importe quel utilitaire d administration ayant une interface en ligne de commande, s exécutant de manière non interactive et générant des diagnostics et messages d erreur en mode texte (sorties standard ou fichiers). Le filtrage des sorties peut se faire soit localement, c est-à-dire sur la plate-forme d administration ou à distance sur les machines administrées. La première solution engendre généralement un trafic réseau plus important et reporte la majorité des traitements sur la machine d administration. Ce mode peut être utilisé pour des commandes avec peu de sortie texte ou pour minimiser l intrusion des tâches d administration sur des machines de production critiques. Le filtrage distant répartit plus uniformément la charge sur les machines et réduit les transferts réseau car seuls les résultats filtrés sont retournés à la plate-forme d administration. L état de sortie déterminé par les filtres peut être OK, WARNING ou ALERT selon les critères définis par l administrateur. Les scripts de commandes peuvent aussi arrêter leur exécution volontairement et retourner un état ABORT. Ceci nous permet, dans notre environnement, de traiter le cas de scripts ne pouvant pas s exécuter car le système d exploitation courant ne correspond pas à celui prévu pour la commande mais peut aussi servir à signaler toute autre situation exceptionnelle. Enfin, AstroWeb retourne l état TIMEOUT lorsqu une station ne répond pas dans les délais et ERROR pour toute autre erreur (permission insuffisante, erreur de syntaxe dans les scripts ). Les sessions n ayant pas pu se terminer (état ABORT ou TIMEOUT) peuvent être stockées pour réexécution ultérieure. Une file d attente est gérée par AstroWeb et permet ainsi de relancer des sessions indépendamment une fois les problèmes résolus. Un outil annexe contrôle la réexécution des sessions en 342 JRES97 La Rochelle 7-10 octobre 1997

attente ; couplé avec un mécanisme de notification de démarrage des stations, ceci permet de relancer de manière transparente la plupart des sessions en attente. D autres fonctionnalités sont accessibles : pour les sessions de surveillance devant être réactualisées, on peut fixer une fréquence de rafraîchissement et recharger ainsi régulièrement des données à jour. Cette méthode utilise le client pull [8] et n est donc utilisable qu avec les navigateurs le supportant. Pour les sessions de longue durée ou s effectuant sur un grand nombre de stations, il est aussi possible d avoir une barre de progression pour suivre «en direct» (intervalle de rafraîchissement configurable) la progression des commandes lancées sur les différentes machines. Ceci est réalisé par le mécanisme de server push [8], différemment supporté selon les serveurs. D autres paramètres permettent encore de modifier le comportement d AstroWeb ; il est ainsi possible de limiter le temps d exécution des commandes ou le nombre de processus lancés simultanément par la plate-forme afin de réduire le temps de réponse et la charge sur la machine d administration. Sécurité AstroWeb a été conçu pour opérer dans un Intranet protégé, la sécurité n était donc pas la principale préoccupation. Il n est cependant pas concevable d offrir un tel outil sans restriction d accès d autant plus que, s agissant d un outil d administration, aucun test ni demande de confirmation n est effectué sur les requêtes et commandes envoyées par l administrateur. Le prototype actuel est protégé de plusieurs manières : le serveur Web de la plate-forme d administration n accepte de connections que du réseau interne et l accès à toutes les ressources, c est-à-dire les pages HTML et les scripts CGI, est protégé par une authentification par mot de passe. Les serveurs Web des machines administrées sont configurés pour n accepter de connections que de la machine d administration. L authentification simple de rcp/rsh utilisant les fichiers.rhosts est utilisée pour les exécutions à distance. Pour réduire les risques d interception des communications et d impersonnification de la plate-forme centrale d administration et comme, de plus, la méthode d authentification actuelle reconnue par tous les serveurs et navigateurs est très simple (simple encodage en base64), il est préférable d utiliser un serveur sécurisé utilisant SSL (Secure Sockets Layer) [9] pour les communications HTTP et ssh pour les exécutions à distance. De plus, on peut utiliser la journalisation du serveur Web de manière à avoir une trace des accès à la plate-forme d administration ; nous envisageons par ailleurs d ajouter à AstroWeb un mécanisme de journalisation. Enfin, l ensemble des scripts, utilitaires et serveurs Web sont exécutés sans privilèges, ce qui convient à la majorité des opérations d administration consistant en l analyse d un état ou la surveillance de ressources. Lorsqu un accès administrateur est nécessaire (modification de paramètres système, création/destruction de comptes utilisateurs), le script de commandes correspondant est exécuté par sudo. Implémentation L environnement AstroWeb est bâti autour d un hôte central de confiance sur lequel est installé un serveur Web Apache [1]. Les scripts d AstroWeb sont écrits en Perl [14] et nécessitent donc la présence d un interpréteur Perl sur chaque machine administrée. AstroWeb peut être installé sur tout environnement Unix (la version de Perl sur NT n implémente pas encore toutes les fonctions nécessaires) et a été testé sur Aix, Solaris et Linux. La diffusion des scripts et commandes sur les machines administrées peut se faire de trois manières différentes : par le montage commun d une même partition réseau (NFS, Samba) sur toutes les machines, par rcp depuis la plate-forme d administration vers les machines administrées ou par transfert HTTP, les machines administrées doivent alors toutes avoir un serveur Web convenablement configuré. La configuration des serveurs Web sur les machines administrées est optimisée pour réduire l utilisation des ressources. Les commandes d administration peuvent être écrites dans n importe quel langage, à condition encore de disposer de l interpréteur correspondant sur chaque machine, voire être des binaires exécutables : l exécution est alors limitée à un groupe de machines homogènes. La plupart des fonctions que nous avons implémenté utilisent Perl ou le Bourne shell. Les filtres peuvent aussi être écrits dans n importe quel langage. Etant donné la spécificité de la tâche, un langage proche de awk et de Perl a par ailleurs été conçu pour simplifier l écriture de petits filtres ou pour les personnes ne connaissant pas Perl. ADMINISTRATION 343

Résultats préliminaires AstroWeb est utilisé de manière régulière dans notre environnement depuis quelques mois. Il nous sert essentiellement pour des tâches de surveillance de notre parc, telles que la vérification de l espace disque, la récupération de l état courant des stations, l analyse et l archivage de fichiers de journalisation. Il nous permet aussi de distribuer des fichiers de configuration des machines, de gérer de manière uniforme les utilisateurs sur Unix et NT. Quelques outils d audit de sécurité Unix ont aussi été adaptés. L écriture de scripts portables ayant un comportement équivalent reste la principale difficulté. L uniformisation relative des environnements de développement sur les différents systèmes facilite grandement les choses. Performances On dénonce fréquemment la lenteur du mécanisme CGI qui impose très rapidement une charge importante au serveur Web, celui-ci ayant à créer un nouveau processus et lancer un programme pour récupérer ses sorties à chaque requête. Dans le domaine de l administration système, le nombre d utilisateurs connectés et la fréquence des requêtes sont généralement peu importants et notre expérience montre que la charge moyenne induite par AstroWeb est facilement supportée par une station classique, tout en offrant un temps de réponse raisonnable. L extensibilité du prototype n a pas encore été entièrement évaluée, AstroWeb ayant été utilisé jusqu à présent sur une quarantaine de machines au maximum. Les premières mesures montrent cependant que le temps de réponse moyen est proportionnel au nombre de machines contactées. De plus, lorsque le nombre de machines augmente, le coût initial du chargement des CGI est proportionnellement moins important. La figure 3 représente le temps de réponse moyen observé lors de sessions de vérification d espace disque en fonction du nombre de machines. L écart-type sur le temps de réponse est très important car un grand nombre de paramètres sont à prendre en compte : délais de transfert réseau, chargement et initialisation des scripts, configuration et charge locale des différentes stations Le mode d exécution et de filtrage influent aussi sur le temps de réponse, ainsi, si les sorties des commandes sont peu importantes, il est généralement plus rapide de faire un filtrage centralisé sur la plate-forme d administration, surtout si les machines administrées sont lentes ou très chargées. On peut encore améliorer les performances très simplement, en utilisant une version de serveur Web ayant un interpréteur Perl intégré. Figure 3 : temps de réponse d'astroweb. AstroWeb est par ailleurs en cours d évaluation pour opérer sur un plus grand nombre de machines de notre Intranet. 344 JRES97 La Rochelle 7-10 octobre 1997

Discussion L architecture d AstroWeb, imposée par l utilisation de scripts CGI et le souci de portabilité est composée d un ensemble de petits scripts spécialisés que nous avons développés et de divers outils et utilitaires extérieurs, largement diffusés et utilisant des mécanismes standards (navigateurs, serveur Apache, librairies Perl, de génération d images, scripts d administration existants ). Cette approche permet de limiter les développements nécessaires tout en assurant une bonne fiabilité des divers composants logiciels et une grande indépendance vis à vis de toute solution propriétaire. L architecture d AstroWeb fixe une nette démarquation entre la gestion de l interface utilisateur, prise en charge par l environnement luimême et la réalisation des fonctions d administration par les divers scripts de commandes et de filtres écrits par les administrateurs. En contrepartie, la configuration des divers composants logiciels sur l ensemble du parc administré doit être soigneusement étudiée pour permettre à l environnement AstroWeb de fonctionner efficacement en toute sécurité. Il est ainsi nécessaire d installer et de configurer divers logiciels selon les besoins projetés (Perl, navigateur, serveur Web, Samba, rshd, sudo ), d installer les scripts d AstroWeb et les configurer pour utiliser le bon mécanisme de diffusion des fichiers, référencer les bonnes URL Néanmoins, AstroWeb reste ouvert et modifiable aisément ; l interface utilisateur en HTML n est pas figée et peut être adaptée aux exigences de chaque utilisateur en fonction de son environnement et de son navigateur Web : on peut envisager plusieurs versions d interfaces : une interface simplifiée pour les utilisateurs, une interface complète pour les administrateurs devant développer des scripts. De même, on peut choisir l apparence de l interface, avec ou sans frames, avec ou sans légende, avec divers niveaux de graphismes D autre part, le recours à l interface Web n est pas impératif ; tous les fichiers créés et manipulés par AstroWeb sont des fichiers texte qui peuvent être modifiés de manière indépendante par les utilisateurs ou d autres programmes. Ainsi, pour les éditions de commandes ou de filtres, il est souvent plus pratique d utiliser un éditeur de texte puis de placer les fichiers où AstroWeb peut les trouver. De même, on peut générer automatiquement des fichiers de session, par exemple pour créer un grand nombre d utilisateurs sur divers serveurs puis les faire exécuter par AstroWeb. Nous avons délibérément décidé de ne pas utiliser Java ; Java autorise le développement d applications portables mais il nécessite de réécrire l ensemble de ces applications et ses besoins actuels en ressources machine sont telles que son utilisation dans le domaine de l administration parait peu réaliste. En revanche, Perl est bien implanté à la fois comme langage de développement de scripts CGI et comme langage de scripts d administration ; il offre des propriétés de portabilité tout aussi intéressantes à moindre coût et de meilleures performances. Notre expérience de développement d AstroWeb a permis d utiliser et de tester de nombreux mécanismes développés autour de HTTP permettant de réaliser efficacement l interfaçage d applications existantes avec des navigateurs Web qui, sans atteindre le niveau de réactivité de Java, conviennent tout à fait à nos besoins. Travaux similaires AstroWeb est fonctionnellement comparable à Igor [10] qui nous a en partie inspiré lors de la conception d AstroWeb. A la différence d Igor qui utilise Perl en interne et Tcl pour l interface utilisateur, AstroWeb ne requiert que Perl et offre de meilleurs possibilités de filtrage des commandes, une possibilité de reprise des commandes et plusieurs modes d exécution distante des commandes. D autres produits d administration accessibles à partir d un navigateur Web commencent à apparaître ; parmi les plus intéressants, citons WatchWare [2] qui visualise individuellement l état d une machine Aix et Big Brother [6] qui permet de surveiller diverses ressources de machines Unix. Ces outils ont été conçus pour la surveillance et ne permettent pas d intervenir à distance. Dans le monde NT, Microsoft propose aussi maintenant un produit pour l administration à distance d un serveur NT depuis le Web et travaille sur une proposition d un standard d administration à partir du Web (Web Based Enterprise Management) [5]. Des efforts similaires, fondés sur Java, sont aussi en cours [13]. ADMINISTRATION 345

Perspectives et conclusion Le développement d AstroWeb se poursuit suivant plusieurs axes ; les principaux étant l extension de l interfaçage avec les commandes et l amélioration de la convivialité. Le modèle initial d interaction d AstroWeb avec les commandes s est en effet avéré insuffisant pour réaliser certaines sessions et nous travaillons à l étendre de manière à pouvoir prendre en compte des données entrées interactivement par l utilisateur à l exécution. De même, les sessions de très longue durée ne sont pas supportées actuellement car le serveur Web limite la durée d exécution des scripts CGI en rompant les connections. Plusieurs solutions sont envisagées dont l utilisation conjointe de clients pull avec un script CGI de notification et le recours à un agent auxiliaire gérant les évènements asynchrones. Ces solutions sont cependant liées à l environnement d exécution et au navigateur utilisés. En ce qui concerne la convivialité, AstroWeb reste encore relativement délicat à installer et configurer ; ainsi la plupart des erreurs de configuration se traduisent par des erreurs du serveur Web ou des documents vides retournés au navigateur ; il est alors nécessaire de vérifier différents journaux pour trouver la cause des problèmes. Par ailleurs, la tolérance aux défaillances n est pas traitée par le prototype actuel ; notre implantation utilise même deux machines critiques : la plate-forme d administration et le serveur de fichier NFS/Samba situé sur une autre station. Pour fiabiliser AstroWeb, c est-à-dire permettre l accès aux fonctions d administration malgré la défaillance d une machine nécessiterait de regrouper sur une même station le serveur Web et le serveur de fichiers et d implanter un protocole de réplication transparente des scripts entre la plate-forme d administration et une plate-forme secondaire. En cas de défaillance de la plateforme d administration principale, l administration pourrait ainsi toujours se faire depuis la machine secondaire ; on peut aussi envisager une redirection transparente par un proxy. AstroWeb se révèle un outil pratique pour réaliser un certain nombre de fonctions d administration en uniformisant l administration de stations de travail. AstroWeb offre aux administrateurs plusieurs mécanismes génériques d exécution à distance de programmes et de diagnostic, facilitant ainsi l intégration et l interopérabilité de programmes d administration extérieurs. Références 1- Apache development team. Apache HTTP Server Project, July 1997. http://www.apache.org/. 2- Bull. Watchware Demo Version, nov. 1996. http://www-frec.bull.com/watchware/demo.htm. 3- L. Deri. Rapid network management application development. Technical Report RZ 2915, IBM Zurich Research Laboratory, Mar. 1997. 4- R. Fielding, U. Irvine, J. Gettys, J. Mogul, DEC, H. Frystyk, T. Berners-Lee, and MIT/LCS. Hypertext Transfer Protocol - HTTP/1.1. RFC 2068, Jan. 1997. 5- HMMP. Web Based Enterprise Management. http://wbem.freerange.com/. 6- S. MacGuire. The big brother unix network monitor, Nov. 1996. http://www.iti.qc.ca/iti/users/sean/bb-dnld/. 7- E. Nemeth, G. Snyder, S. Seebass, and T. R. Hein. Unix System Administration Handbook. Prentice Hall, 1995. 8- Netscape. An exploration of dynamic documents. http://home.mcom.com/assist/net_sites/pushpull.html. 9- Netscape. SSL V3.0 specification, Mar. 1996. http://home.netscape.com/newsref/std/ssl.html. 10- C. Pierce. The igor system administration tool. In Proc. of the Tenth USENIX System Administration Conference (LISA X), pages 9-18, 1996. 11- A. Sahai, S. Billiart, and C. Morin. A portable and mobile manager for network and system management. In Proc. of the Third Joint Conference on Information Sciences, Raleigh, USA, Mar. 1997. 12- W. Stallings. SNMP, SNMPv2 and CMIP : The practical guide to network management standards. Addison-Wesley, 1994. 13- Sun Microsystems. JMAPI Home Page. http://java.sun.com/products/javamanagement/. 14- L. Wall, T. Christiansen, and R. L. Schwartz. Programming Perl. O Reilly and Associates, 2nd edition, 1996. 346 JRES97 La Rochelle 7-10 octobre 1997