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 main- tenir 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’ad- ministration 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 envi- ronnement 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 loca- lement. 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 majeu- re 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 gra- phique et la gestion de l’interactivité avec les utilisateurs, ce qui oblige à avoir une machine d’adminis- tration 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 tou- jours triviaux, ni compatibles avec l’existant (langage de développement et API imposés, contraintes de conformité à l’interface utilisateur) [3].
Session Administration 5
ADMINISTRATION
Administration réseaux et systèmes
Administration système à partir d’un navigateur Web
Stéphane Billiart, [email protected] Christine Morin, [email protected] Akhil Sahai, [email protected]
BULL IRISA/INRIA, Rennes
L’action Astrolog étudie l’apport des technologies de l’Internet au domaine de l’administra- tion 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.
En définitive, de telles configurations ne se justifient que pour de grands réseaux d’entreprise, d’enver- gure 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 uti- lisé et pour toutes les fonctions disponibles.
– L’ajout de nouvelles fonctionnalités comme la surveillance de nouveaux matériels ou l’administra- tion 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’ad- ministration 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 nom- breux 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épa- ration 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éve- loppeurs 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 ser- veur. 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’ad- ministration 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 com- posé 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’ad- ministration est laissé à l’administrateur, ceux-ci sont directement interfacés avec les scripts CGI de l’en-
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 uti- lise 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 inter- face les commandes adéquates selon l’environnement d’exécution. Enfin, un mécanisme de filtre analy- se 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éa- liser 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’envi- ronnement. 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.
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
Figure 1 : page principale d'AstroWeb.
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.
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 dia- gnostics 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 uti- lisé pour des commandes avec peu de sortie texte ou pour minimiser l’intrusion des tâches d’adminis- tration sur des machines de production critiques. Le filtrage distant répartit plus uniformément la char- ge 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 retour- ne 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 Figure 2 : rapports d'exécution
d'une session.
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 uti- lisant 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 ser- veur 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 jour- nalisation.
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 res- sources. Lorsqu’un accès administrateur est nécessaire (modification de paramètres système, création/des- truction 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 ser- veur 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 dif- fé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 confi- guration des serveurs Web sur les machines administrées est optimisée pour réduire l’utilisation des res- sources.
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
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 gran- dement les choses.
Performances
On dénonce fréquemment la lenteur du mécanisme CGI qui impose très rapidement une charge impor- tante au serveur Web, celui-ci ayant à créer un nouveau processus et lancer un programme pour récu- pé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é.
AstroWeb est par ailleurs en cours d’évaluation pour opérer sur un plus grand nombre de machines de notre Intranet.
Figure 3 : temps de réponse d'AstroWeb.
Discussion
L’architecture d’AstroWeb, imposée par l’utilisation de scripts CGI et le souci de portabilité est compo- sé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, librai- ries 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 lui- mê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 pra- tique 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’uti- lisateurs 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 effi- cacement 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 concep- tion 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 possibi- lité 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
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éa- liser certaines sessions et nous travaillons à l’étendre de manière à pouvoir prendre en compte des don- né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 rom- pant 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 docu- ments 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 uti- lise 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’admi- nistration malgré la défaillance d’une machine nécessiterait de regrouper sur une même station le ser- veur 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 plate- forme 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éca- nismes 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.
Session Administration 5
Administration réseaux et systèmes
