FR2911203A1 - Procede de gestion de l'environnement d'execution sur des postes clients legers - Google Patents

Abstract

L'invention se rapporte au domaine des clients légers informatiques et plus particulièrement à un procédé de gestion de l'environnement d'exécution de ces clients légers appartenant à un réseau informatique.Selon l'invention, l'environnement d'exécution de chacun desdits clients légers est défini sur un serveur d'application du réseau sur la base d'une copie d'un premier profil enregistré sur ledit serveur d'application, le procédé comprend :- une étape de modification dudit premier profil,- suite à ladite modification, l'initialisation de l'environnement d'exécution des clients légers par un nouvel environnement d'exécution propre à chaque client léger et défini sur le serveur d'application sur la base d'une nouvelle copie du premier profil modifié,- ladite initialisation étant effectuée suite à la détection d'un événement informatique lié à l'insertion ou au retrait d'un média amovible sur l'un des équipements du réseau, les équipements comprenant les clients légers et le serveur d'application.

Description

PROCEDE DE GESTION DE L'ENVIRONNEMENT D'EXECUTION SUR DES POSTES CLIENTS

LEGERS

L'invention se rapporte au domaine des clients légers informatiques et plus particulièrement à un procédé de gestion de l'environnement d'exécution de ces clients légers.

Les clients légers s'inscrivent dans une architecture client-serveur informatique dans laquelle la plupart des ressources logicielles et matérielles de traitement est située sur le serveur central. On utilise ainsi l'architecture clients légers pour sa robustesse due à la complexité réduite des postes clients mais également pour la facilité de gestion qui se résume à une simple intervention sur le serveur qui impacte l'ensemble des postes clients, par exemple pour la mise à disposition d'un nouveau logiciel. Comme décrit dans la demande FR- 2884667 de la présente demanderesse, cette architecture est utilisée dans le cadre d'écoles ou de salles de cours. Dans de tels environnements communautaires, des groupes d'élèves ou de travail se succèdent. Pour simplifier la tâche de l'institutrice ou de l'intervenant, une homogénéité des environnements d'exécution mis à disposition des utilisateurs est recherchée. Il y a donc un besoin d'offrir une gestion aisée des profils d'utilisateurs dans le cadre de clients légers communautaires.

On connaît par la publication US-6,044,465, un système de gestion de profils utilisateur pour un système d'exploitation en utilisation inhabituelle locale (sans connexion) lorsque le profil correspond à l'exécution d'un système d'exploitation sur serveur, par exemple Windows NT (nom commercial). Un profil utilisateur définit l'environnement d'exécution et comprend, en général, les définitions et préférences du bureau de l'utilisateur (les applications disponibles, les raccourcis, les choix esthétiques, ...). Ce système crée automatiquement, à l'authentification de l'utilisateur, un profil de travail reprenant les privilèges d'un groupe d'appartenance de l'utilisateur. En fin de session, le profil est soit conservé et désactivé, soit supprimé. Bien que les profils créés temporairement soient étroitement liés à un groupe d'appartenance de l'utilisateur, la solution décrite dans cette publication traite les profils utilisateur individuellement et ne permet pas d'appréhender la gestion d'un parc de clients légers dans sa globalité. Un premier but de l'invention est de permettre une gestion centralisée des profils utilisateur de clients légers.

En outre, les réseaux de clients légers actuels s'appuient sur l'utilisation de profils individuels peut propice à une gestion aisée de ceux-ci. Chaque utilisateur du réseau s'authentifie par une interface puis son environnement d'exécution particulier, c'est-à-dire sauvegardé des précédentes sessions, est chargé par un serveur d'application pour fournir l'interface de bureau personnalisé à l'utilisateur au travers du client léger. Cette solution apparaît mal adaptée à une gestion de groupe puisque les évolutions ultérieures de profil doivent être répercutées profil par profil. Une gestion groupée des profils est souhaitable pour des applications scolaires ou communautaires dans lesquelles on souhaite proposer à tous les utilisateurs le même environnement informatique de travail prenant en compte les évolutions ultérieures. Un autre but de l'invention est de simplifier, pour l'intervenant ou l'instituteur, la mise à jour ou toute évolution (par exemple une modification de paramètres, un changement de bureau) du bureau informatique (environnement d'exécution) pour un groupe d'utilisateurs prédéfini.

L'invention vise à atteindre ce but en utilisant des profils temporaires établis sur la base d'un profil type (profil groupe) identique pour chacun des clients légers, en permettant la modification de ce profil type (protégé contre une éventuelle corruption de fichier) et en déclenchant la réinitialisation des clients légers par une action volontaire de l'intervenant. De la sorte, on assure un suivi efficace de la gestion des profils. En outre, l'utilisation d'un profil type permet une gestion centralisée et robuste des profils utilisés. L'utilisation de profils temporaires est également avantageuse en ce qu'elle permet aisément de repartir sur une configuration saine lorsque l'intervenant déclenche la réinitialisation de l'environnement d'exploitation des clients légers.

Dans ce dessein, l'invention a tout d'abord pour objet un procédé de gestion de l'environnement d'exécution d'une pluralité de clients légers appartenant à un réseau informatique, l'environnement d'exécution de chacun desdits clients légers étant défini sur un serveur d'application du réseau sur la base d'une copie d'un premier profil enregistré sur ledit serveur d'application, le procédé comprenant : - une étape de modification dudit premier profil, - suite à ladite modification, l'initialisation de l'environnement d'exécution des clients légers par un nouvel environnement d'exécution propre à chaque client léger et défini sur le serveur d'application sur la base d'une nouvelle copie du premier profil modifié, - ladite initialisation étant effectuée suite à la détection d'un événement informatique lié à l'insertion ou au retrait d'un média amovible sur l'un des équipements du réseau, les équipements comprenant les clients légers et le serveur d'application.

L'environnement d'exécution comprend les définitions et préférences du bureau de l'utilisateur, c'est-à-dire les raccourcis aux applications disponibles, des propriétés d'interfaçage (présence ou non d'une barre d'outils, choix esthétiques), l'espace de stockage disponible... Un profil est associé spécifiquement à chacun des clients légers sur la base du profil type/groupe "premier profil". Ce profil évolue avec l'utilisateur pendant une session donnée. L'initialisation du client léger permet de repartir sur un nouveau profil spécifiquement établi sur le profil type modifié. On est ainsi en présence d'un profil temporaire qui est initialement identique (puisque copie du profil type) pour l'ensemble des clients légers et qui évolue avec eux, puis est remplacé par un nouveau profil à l'initialisation suivante des clients légers. L'événement déclencheur de l'initialisation est en pratique effectué par l'intervenant (institutrice, par exemple) au travers de la manipulation physique du média amovible. Un tel média peut être du type clé USB (Universal Serial Bus), carte à puce, module Bluetooth, étiquette d'identification radiofréquence (RFID), ... Dans la pratique, le serveur d'application est parfois distant de l'ensemble des clients légers et donc de l'intervenant. Il est alors prévu que le procédé comprend préalablement à la modification, l'insertion dudit média amovible dans un premier client léger, ladite insertion dans le premier client léger déclenchant le chargement d'une interface logicielle apte à modifier ledit premier profil depuis ledit premier client léger. Par exemple, ce chargement d'interface logicielle peut consister en l'initialisation d'un profil individuel sur ledit premier client léger, ledit profil individuel comprenant une application numérique permettant de modifier ledit premier profil. L'intervenant accède ainsi aisément à la définition (sur le serveur d'application) du profil type qu'il peut modifier.

Une gestion aisée de ce profil est ainsi fournie. Le client léger en question peut être l'un de la pluralité de clients légers présentant l'environnement d'exécution en question, ou peut être un autre client léger, par exemple dédié à cette fonction. Un intervenant peut prévoir à l'avance une pluralité de profils différents qu'il souhaite appliquer successivement dans le temps. On prévoit alors que ledit média amovible comprend des données d'identification personnelle à l'intervenant, ledit serveur d'application comprend une pluralité de profils associés auxdites données d'identification, et ladite modification comprend la sélection d'un desdits profils comme premier profil. Ainsi à la réinitialisation des clients légers, ceux-ci présentent un nouvel environnement d'exploitation basé sur le nouveau profil type choisi par l'intervenant. L'utilisation de données d'identification permet également au serveur d'application de limiter, pour l'intervenant, l'accès aux définitions sur le serveur d'application des profils types qui lui sont associés. Auquel cas, il est prévu que, sur le serveur d'application, les profils types sont associés à des données d'identification de médias amovibles.

En vue d'une gestion facile des données au niveau du serveur, les profils types sont mémorisés sous forme de paramètres dans une base de données. Eventuellement, une version du profil type sous forme de répertoires peut être préparée et être la base des copies ultérieures pour les environnements d'exécution des clients légers.

De ce qui précède, l'intervenant accède à l'application de modification des profils types depuis un client léger par l'insertion de sa clé USB par exemple. Dans un mode de réalisation, on prévoit alors que ledit événement informatique est la détection du retrait dudit média amovible du premier client léger. De ce fait, la modification apportée est directement prise en compte et affecte instantanément (latence de quelques secondes nécessaire au traitement du serveur d'application pour réinitialiser tous les postes) sans que l'intervenant n'ait à agir sur le serveur et ce dès le retrait de la clé USB. Dans ce mode de réalisation dit "automatique", l'initialisation des clients légers comprend les étapes suivantes : - la déconnexion desdits clients légers, - la suppression, notamment par écrasement des fichiers dû à la création d'une nouvelle copie comme ci-dessous, desdites copies de profils associées aux clients légers ; c'est-à-dire la fin de l'ancien profil temporaire associé à chacun des clients légers, - pour chacun desdits clients légers, la création d'une nouvelle copie (nouveau profil temporaire) du premier profil modifié sur le serveur d'application, - le lancement de chaque client léger de ladite pluralité dans un environnement d'exécution défini sur la base de la nouvelle copie de profil associé audit client léger.

Dans un mode de réalisation alternatif, il est prévu que ledit événement informatique est la détection de l'insertion dudit média amovible dans ledit serveur d'application. On peut prévoir, dans ce mode de réalisation, que les étapes de déconnexion et suppression décrites ci-dessus sont réalisées antérieurement à la modification apportée au profil type. Ce mode de réalisation s'applique notamment lorsque l'exécution des environnements d'exécution sur les clients légers est liée à la présence du média amovible sur le serveur. Il convient alors pour apporter des modifications au profil type de retirer le média amovible du serveur et par conséquent, les clients légers sont déconnectés et leurs profils temporaires associés sont effacés, éventuellement par écrasement de fichiers, avant que la modification du profil type ne soit apportée.

L'invention a également pour objet un système pour la gestion de l'environnement d'exécution d'une pluralité de clients légers, comprenant un réseau informatique auquel sont connectés lesdits clients légers et un serveur d'application, l'environnement d'exécution de chacun desdits clients légers étant défini sur le serveur d'application sur la base d'une copie d'un premier profil enregistré sur ledit serveur d'application. Dans ce système, le serveur d'application comprend un contrôleur agencé pour recevoir des instructions de modification et pour modifier en conséquence ledit premier profil, et un gestionnaire de session agencé pour initialiser l'environnement d'exécution des clients légers par un nouvel environnement d'exécution propre à chaque client léger et défini sur le serveur d'application sur la base d'une nouvelle copie du premier profil modifié, et - ledit contrôleur est apte à détecter un événement informatique lié à l'insertion ou au retrait d'un média amovible sur l'un des équipements du réseau, les équipements comprenant les clients légers et le serveur d'application, et à piloter ledit gestionnaire de session suite à ladite détection pour initialiser les clients légers.

Dans un mode de réalisation, le système comprend, en outre, un premier client léger muni d'une interface (par exemple un lecteur de carte, un port USB, ...) apte à accueillir et lire un média amovible, ledit contrôleur étant agencé pour charger, dans l'environnement d'exécution dudit premier client léger, une interface logicielle de modification dudit premier profil lors de la connexion d'un média amovible au travers de l'interface du premier client léger. Par exemple, il peut d'agir de l'initialisation d'un profil individuel sur ledit premier client léger, ledit profil individuel comprenant une application numérique permettant de modifier ledit premier profil. Egalement, on peut prévoir que ledit média amovible comprend des données d'identification et le serveur d'application stocke une pluralité de profils associés auxdites données d'identification, ladite application de modification étant agencée pour modifier au moins un profil parmi ladite pluralité de profils. Particulièrement, un drapeau d'activation est associé à chacun des profils de ladite pluralité de profils, un seul desdits drapeaux étant actif à la fois. De la sorte, le serveur d'application est capable à tout moment de déterminer le profil type actif à partir duquel une réinitialisation doit être effectuée lors de la détection dudit événement déclencheur. L'intervenant modifie les drapeaux des profils afin d'en sélectionner l'un parmi l'ensemble. Selon une première variante, ledit événement informatique est la déconnexion dudit média amovible au travers de ladite interface du premier client léger. Selon une deuxième variante, le serveur d'application comprend une interface apte à accueillir et lire un média amovible et ledit événement informatique est la connexion dudit média amovible au travers de ladite interface du serveur d'application.

Dans un mode de réalisation, ledit gestionnaire de session est agencé pour déconnecter lesdits clients légers suite à une modification dudit premier profil ; ledit contrôleur est, en outre, agencé pour supprimer lesdites copies de profils associées aux clients légers et, pour chacun desdits clients légers, créer une nouvelle copie du premier profil modifié ; et le gestionnaire de session est, en outre, agencé pour relancer chaque client léger dans l'environnement d'exécution défini sur la base de la nouvelle copie de profil associée audit client léger.

Par ailleurs, on peut prévoir un système comprenant au moins une deuxième pluralité de clients légers et le serveur d'application comprenant au moins un deuxième profil sur la base duquel sont définis les environnements d'exécution des clients légers de ladite deuxième pluralité. L'invention s'applique alors à une pluralité de groupes de clients légers. Ces groupes de clients légers sont mémorisés dans le serveur d'application : une base de données référence, pour chaque groupe, les adresses IP et/ou MAC de chacun des clients légers. Il est ainsi aisé d'appliquer l'invention à chaque groupe de clients légers soit selon le même processus soit selon des variantes, par exemple un premier groupe est réinitialisé lorsque l'intervenant retire sa clé USB d'un des clients légers du groupe, alors que le deuxième groupe est initialisé lorsque la clé USB est introduite sur le serveur d'application. On comprendra mieux l'invention à l'aide de la description, faite ci-après à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux figures annexées : û Fig. 1 représente un exemple d'architecture système dans laquelle l'invention est mise en oeuvre ; Fig. 2 représente l'architecture système du serveur mis en oeuvre dans la Fig. 1 ; Fig. 3 est un ordinogramme illustrant la définition du système de profils groupes selon l'invention ; Fig. 4 est un ordinogramme illustrant le déploiement des profils groupes ou individuels sur les postes clients légers de la Fig. 1 ; et Fig. 5 est un ordinogramme illustrant les étapes de réinitialisation des postes clients lors de la mise en oeuvre de la présente invention. En référence à la Fig. 1, le système comprend un réseau informatique 1 auquel est relié un serveur central 2 et une pluralité de postes clients légers 3. Chaque client léger 3 est un ordinateur qui, dans cette architecture client-serveur, n'a presque pas de logique d'application. Il dépend donc surtout du serveur central 2 pour le traitement. Ces terminaux 3 supportent chacun un serveur graphique (XORG) dont les clients X (protocole X11 ou NX) sont soit exécutés sur le serveur d'application 2 soit sur le terminal 3 lui-même. En pratique, et comme décrit dans la demande FR-2884667 précitée, les clients légers 3 disposent d'un système d'exploitation exécuté en local, d'une interface réseau et d'une carte graphique permettant la restitution à l'écran du bureau informatique dans lequel l'utilisateur peut évoluer. Le serveur central 2 ou serveur d'application reçoit des commandes issues des périphériques de saisie (clavier, souris) des postes clients 3 et transmis via le réseau 1. Il traite ces données dans le contexte applicatif (c'est-à-dire l'environnement d'exécution et les applications en cours d'exécution) propre à chaque client léger 3 et renvoie à ce dernier les données de mise à jour de l'affichage graphique. Ainsi, tous les traitements, à l'unique exception de celui de l'affichage graphique, sont effectués sur le serveur d'application 2.

Tout ou partie des postes clients possède comme périphérique une interface USB pour recevoir une clé USB 5. Chaque client léger 3 est identifiable sur le réseau informatique 1 par une adresse informatique unique, soit une adresse IP soit une adresse MAC. Les clients légers sont groupés, par exemple en salle de cours 4a, 4b, 4c, 4d, ... Chaque groupe ainsi constitué comprend une liste d'adresses MAC ou IP.

Comme illustré en partie par la Fig. 2, le serveur d'application 2 comprend : un système de fichiers partagés (UNIONFS par exemple) permettant de partager les fichiers stockés sur le serveur d'application 2 (car les clients légers sont démunis de moyens de stockage de masse) à tous les clients légers 3, un gestionnaire de session 20, un gestionnaire de fenêtre (par exemple kwin) pour gérer les différentes fenêtres (placement, dimensions, autres propriétés) ù un gestionnaire de bureau (par exemple KDE 3.4) qui est une suite de programmes plus ou moins intégrés conçus pour donner une interface commune aux programmes ou applications utilisés par la suite, un contrôleur 21, une interface réseau 22 avec le réseau 1, et éventuellement une interface réseau 22' avec un réseau externe du type Internet (de sorte à fournir un accès Internet à l'ensemble des clients légers 3), une base de données 23 comprenant des données de profil d'environnement d'exécution, une interface USB 24 pour recevoir une clé USB 5, ou toute autre interface équivalente avec un média amovible.

Le gestionnaire de session 20 (par exemple KDM) associé au gestionnaire de bureau permet de lancer le bureau (donc l'environnement d'exécution) pour chacun des clients légers. Cette exécution est réalisée par le serveur 2 ; seules les données d'affichage sont transmises au client léger 3. Dans une utilisation avec profils individuels, le gestionnaire de sessions sauvegarde et restaure automatiquement les paramètres modifiés de cet environnement d'exécution, à chaque fin de session et redémarrage de session.

Le contrôleur 21 se présente sous la forme d'une couche logicielle de technologie java qui grâce à un relais basé sur des technologies SHELL (BASH, SH, ...), et autres outils, est capable de lancer des ordres vers les gestionnaires ci-dessus et autres outils système. Cette couche contrôleur est capable de séquencer ou de paralléliser des opérations systèmes, en maintenant à jour la base de données 23, à laquelle elle donne accès à travers de l'API (Application programming interface) pour des interfaces de contrôle. Le contrôleur 21 est une application système JAVA, contenue dans un serveur JAVA (par exemple TOMCAT), qui écoute des requêtes sur deux canaux : 1) le premier canal de sollicitation du Contrôleur est le conteneur serveur JAVA lui-même (par exemple à travers des servlets). Par exemple, le conteneur serveur JAVA peut transmettre des sollicitations émanant de requête http ; 2) le second canal de sollicitation est direct, à travers et depuis des clients sockets. En d'autres termes, il s'agit d'une connexion directe avec chacun des clients légers 3 du réseau 1 sous sa responsabilité. Le contrôleur 21 est capable, suite à ces sollicitations, de lancer des opérations systèmes. Collecteur de ces opérations, il les séquence, les parallélise (multi-threadées). Les opérations sont définies à partir de fichiers d'initialisation au format XML, qui décrivent les accès base de données, les commandes système à lancer, et les clauses d'échec ou de réussite des opérations. Le contrôleur dispose de différents outils système (existants ou développés essentiellement en SHELL BASH) pour donner des ordres aux différents modules du système, et notamment commander l'envoi des données d'affichage aux clients légers 3 par l'interface réseau 22. Il est capable de gérer la notion de rolback, et de pourcentage de progression dans l'execution des opérations qu'il contrôle.

La base de données 23 (SGBD, par exemple MySQL 4 ou supérieur) contient les informations et références au système qui permettent de définir les environnements de travail des clients légers, et d'écrire des répertoires représentatifs de ces environnements. Pour un profil type d'environnement d'exécution, la base de données contient les informations suivantes : • nom du profil • quotas • affichage de la barre des tâches • logiciels accessibles • droits sur des URL (fichiers, répertoires...) • mot de passe du profil • user linux associé • groupes principal et secondaire linux associés (impacte directement les droits sur le système) En pratique, la base de données 23 stocke plusieurs profils types qui sont associés à différents intervenants. Un exemple simplifié de table est présenté ci-dessous : Identifiant clé Profil Actif Groupe 1234 CP1 0 Salle 1 1234 CP2 0 Salle 1 1234 CE1 1 Salle 1 1234 CE2 0 Salle 1 2468 Accès libre 1 Salle 2 2468 Formation 0 Salle 2 Tableau 1 : table d'association profils û identifiant clé La clé USB 5 de l'intervenant/institutrice stocke un identifiant qui permet à son porteur d'accéder aux profils qui lui sont associés dans la base. Le nom du profil, "CP" par exemple, permet de faire la jonction avec une table annexe contenant les différentes informations mentionnées précédemment (la description effective de ce qui constitue l'environnement d'exécution associé à ce profil). Un indicateur d'activité permet d'identifier l'unique profil groupe actif pour un intervenant : champ "Actif" à 1. A priori, seul un profil est actif à un instant donné, donc pour un identifiant clé, seul un drapeau "Actif" prend la valeur "1".

Les profils peuvent être associés à des groupes 4a à 4d de postes clients 3. Dans ce dessein, le contrôleur dispose d'une collection de profils et de postes, codés en objet. Il associe les uns aux autres en temps réel en fonction des demandes, grâce à des commandes systèmes qu'il séquence et/ou parallélise. Pour tracer ces actions, il dispose de trois moyens alternatifs, qu'il utilise pour se prémunir d'un arrêt inopiné du serveur : • le suivi objet : par exemple un champ com_actual_state de l'objet définissant charge client léger 3 (dans la liste de postes clients instanciés par le contrôleur) contient le profil en cours de connexion sur le dit poste, • le suivi par la base de données : par exemple un champ com_actual_state (de la table des clients légers en base de données) contient le profil en cours de connexion sur ledit poste, • le suivi par des fichiers de verrou : par exemple, un fichier nommé par l'adresse MAC d'un poste contient le profil en cours de connexion sur le dit poste. Ces trois suivis sont stockés dans des espaces non volatiles (partition de disque dur par exemple) pour redémarrer dans le même état après l'arrêt du serveur. Ces moyens de suivi constituent un gage de robustesse, et sont prioritaires dans l'ordre de leur description. Les environnements d'exécution sont gérés au niveau du serveur 25 d'application au travers de répertoires. Les répertoires contiennent les environnements de travail directement exploités par le système en condition d'utilisation. Ils sont fabriqués à partir des informations de la base de données 23 et d'un répertoire initial dit vide . Il existe deux types de répertoires : vide 25 ou 30 profil 26-27. Le type de répertoire profil contient deux sous catégories : • des répertoires d'exploitation 27, • un répertoire de réinitialisation 26 Le répertoire vide 25 est un répertoire statique du système. Il correspond à un répertoire d'un environnement de travail vide . C'est à partir de ce répertoire que l'environnement de travail de tout utilisateur est fabriqué. Il est une souche, destinée à être enrichie. Le répertoire de réinitialisation 26 est fabriqué en copiant le répertoire de l'environnement de travail vide, enrichi par les informations de la base de données. Il est utilisé pour recevoir un environnement de travail figé, jamais utilisé, connecté, ou accédé par les utilisateurs. De sorte que ce répertoire ne sera jamais corrompu par une mauvaise utilisation. De cette façon, il sert de référence pour l'environnement de travail auquel il est associé. Les répertoires d'exploitation 27 sont fabriqués en copiant le répertoire de réinitialisation 26 associé à l'environnement de travail. Il est exploité comme répertoire personnel d'un client léger spécifique 3 au moment de la connexion de celui-ci. Ces répertoires 27 sont stockés sur le serveur d'application 2 et chacun est utilisé dans l'exécution de la session d'un poste client 3 spécifique. De ce fait, ils évoluent indépendamment les uns des autres au gré de l'utilisateur du client léger correspondant.

Le système permet d'accéder à des environnements de travail stockés sous forme de répertoires 27, mais initiés à partir de valeurs en base de données 23, le tout ordonnancé par le contrôleur 21. Les postes 3 du réseau sont identifiés par leurs adresses MAC, enregistrées en base de données la première fois qu'ils se connectent sur le réseau en démarrant sur l'image système réseau envoyée par NETSERV (technologie de BOOT PXE).

La Fig. 3 illustre la création du profil type, notamment en précisant les différentes étapes de définition de ce profil type. Suite à une sollicitation du contrôleur 21 pour la création d'un profil (30), un nouvel "utilisateur système type" est ajouté (31). Cet utilisateur ne sera jamais utilisé ; il permet uniquement la définition du profil type. Le répertoire personnel de cet utilisateur modèle est alors rempli à partir soit d'un modèle par défaut soit d'un autre modèle choisi en base de données sur la base duquel l'intervenant souhaite développer son nouveau profil (étape 32).

A ce stade, des modifications de ce répertoire sont apportées (33) à partir d'informations de modification qu'une interface de contrôle ou IHM fournit au contrôleur pour le compte de l'intervenant souhaitant préciser le profil. Des modifications couramment apportées concernent la présencede la barre des tâches dans un environnement de bureau informatique, la définition du fond d'écran et des logiciels accessibles depuis ce bureau. On obtient le répertoire de réinitialisation 26. Un ensemble de n utilisateurs systèmes qui correspondent à n répertoires d'exploitation destinés à être connectés est ajouté à la définition du profil en base de données (34). 1<=n>=nbr de postes car on peut faire le choix de connecter tous les clients légers ou une partie seulement dans le cas d'un ensemble précis de postes de déploiement (auquel cas, on indiquera les adresses MAC). Dans le cadre de l'élaboration d'un profil individuel, un seul utilisateur système est défini (n=1).

Le système est ainsi capable de stocker plusieurs types d'environnement de travail appelés profils dont la définition est précisée dans base de données (via par exemple l'interface de contrôle). On distingue les profils dits groupes des profils individuels. Les profils groupes (n>1) sont des environnements de travail très sécurisés, qui ne donnent pas le droit à l'utilisateur de les modifier. Seule la personne autorisée peut les modifier. Ce profil peut être utilisé par plusieurs personnes simultanément sur plusieurs clients légers 3. Plusieurs répertoires d'exploitation 27 sont créés au moment de la création de ce type de profil. Ils correspondent à autant d'utilisateurs système capables de se connecter à travers le gestionnaire de sessions, c'est-à-dire à partir des clients légers 3. En revanche, ils sont visuellement identiques. Le contrôleur accepte de connecter visuellement plusieurs fois ce type de profil par le truchement de la connexion simultanée des utilisateurs systéme dont les répertoires personnels sont un des répertoires d'exploitations multiples préparés au moment de sa création. L'utilisation du profil groupe permet de gérer très simplement un contenu applicatif similaire sur plusieurs postes.

Par comparaison, le profil individuel (ou personnel ; n=1) est un environnement de travail personnel qui permet à l'utilisateur de personnaliser son environnement de travail et d'accéder à un répertoire privatif. Ce profil ne peut être utilisé que par une seule personne. Un seul répertoire d'exploitation 27 est prêt à être utilisé comme répertoire personnel par le gestionnaire de session. Le contrôleur n'accepte donc de connecter visuellement et simultanément que sur un seul poste ce type de profil.

Toujours en référence à la Fig. 3, le répertoire d'initialisation 26 alors créé est copié (35) en répertoires d'exploitation 27 personnels pour ces différents utilisateurs système. Le contrôleur 21 associe alors un quota d'espace disque dur pour le stockage aux n utilisateurs si nécessaire en fonction d'informations en base de données (étape 36). Le contrôleur valide la création des profils en enregistrant (37) en base de données 23 les paramètres du profil type nouvellement défini : nom du profil, logiciels associés données systèmes de également enregistrées présence de la barre des tâches, ... Puis, les chacun des n utilisateurs système sont (38) dans la base de données 23 : nom système, mot de passe, fond d'écran, type d'utilisateur, ... Ces données systèmes contiennent notamment le mot de passe de chaque utilisateur et permettent de gérer en autonomie le système d'authentification grâce des requêtes SQL adaptées.

A travers le réseau 1, le système offre le contrôle de chaque terminaux informatiques 3 (PC, terminal, ...) ou groupe de terminaux. C'est-à-dire qu'à distance, on peut les démarrer, les éteindre, les connecter ou choisir les applicatifs auxquels l'utilisateur a accès. Divers modes de connexion sont envisagés.

En référence à la Fig. 4, le déploiement des environnements d'exécution sur les clients légers peut être déclenché par différents mécanismes : -par la connexion d'une clé USB sur un client léger 40, - par la connexion d'une clé USB sur le serveur d'application 41, - de façon automatique au lancement du serveur 42, l'ensemble des terminaux affectés par ce déploiement étant défini en base de données 23 - par une interface logicielle dédiée 43 au travers de laquelle on affecte un profil à un client léger déterminé, - par la déconnexion d'un client léger d'un groupe de clients en demandant la connexion d'un profil sur tout le groupe 44. Dans l'architecture de la Fig. 1, les groupes 4a, 4b et 4c sont déployés automatiquement alors que le groupe 4d requiert l'introduction d'une clé USB dans le serveur d'application 2. Lorsque l'intervenant introduit sa clé USB (41) contenant l'identifiant "2468" dans le port USB du serveur d'application 2, une session est automatiquement ouverte sur les clients légers 3 du groupe 4d sur la base du profil "Accès Libre". Ces clients légers sont ainsi configurés de façon similaire et disposent chacun d'un répertoire spécifique d'environnement d'exécution 27 sur le serveur d'application 2.

Les clients légers 3 du groupe 4a sont automatiquement démarrés avec le serveur 2 sur le profil CE1 puisque ce groupe correspond à la "classe 1". Le serveur d'application est également configuré pour démarrer automatiquement des sessions sur les clients légers 3 des groupes 4b et 4c, par rapport à des profils indiqués dans la base de données 23. Dans ce mode de connexion automatique, l'événement système déclenchant l'ouverture d'une nouvelle session est la déconnexion d'un profil (44). Pour cela, une connexion automatique a été paramétrée en base de données pour un ou plusieurs clients légers spécifiques, typiquement l'ensemble du groupe 4d. La connexion automatique correspond à une connexion par défaut. L'événement de déconnexion d'un profil est envoyé par le client léger 3 au contrôleur 21. Celui-ci vérifie la définition d'un environnement de travail par défaut pour le client léger 3 émetteur. Si cet environnement de travail est défini, le contrôleur déploie systématiquement ce profil vers le poste désigné suite à toute déconnexion. Le processus de réinitialisation par le profil déconnecté est lancé (écrasement du répertoire d'exploitation par le répertoire de réinitialisation) C'est-à-dire que l'ancien répertoire d'exploitation 27 utilisé avant la déconnexion est supprimé et remplacé par un nouveau répertoire d'exploitation 27 copié du répertoire d'initialisation 26 (répertoire modèle).

De retour à la Fig. 4, les événements ci-dessus sont interprétés par le contrôleur comme des requêtes en connexion (50) des profils sur les postes dédiés (ceux qui auront été au préalable associés au profil). Si un lancement d'un nouvel environnement d'exécution sur ces postes est possible selon ce mécanisme (51), le contrôleur lance les commandes système nécessaires (52). En fonction de l'événement initial, le contrôleur lance la ou les connexions sur les postes dont il a reçu les adresses MAC, en vérifiant dans la liste des instances de poste ou en base de données, les groupes de poste ou le seul poste auquel il doit s'adresser. Si quelqu'un est déjà connecté sur le poste (53) une déconnexion est demandée par le contrôleur 21 au gestionnaire de sessions 20 (54). Si personne n'est connecté ou après la déconnexion, le contrôleur effectue si nécessaire la personnalisation (55) du profil demandé (profil modifié ou nouvellement choisi) par rapport au poste où il est déployé : par exemple, il lui affecte une imprimante par défaut. Ensuite la connexion des utilisateurs systèmes dupliqués du profil type est demandée au gestionnaire de sessions pour l'ensemble des clients légers visés (56). Si la connexion est alors opérée (56), on met à jour la base de données avec le nouveau profil connecté sur le poste, on met également à jour les éventuelles instances du contrôleur et on pose un fichier de signalisation de connexion (58).

Dans un mode de connexion par reconnaissance de média amovible (par exemple une clé USB), l'événement système est déclenché par l'insertion du média, détecté par exemple par la technologie UDEV. A partir de la technologie qui détecte l'évènement, on sollicite le contrôleur 21 en lui envoyant des informations sur l'événement qui vient de se produire : par exemple une requête HTTP sur le serveur JAVA sollicite une servlet et déclenche l'ordre d'exécution d'opération. En référence à la Fig. 4, le média est introduit soit sur un terminal 3 (40) soit sur le serveur 2 (41).

Sur le terminal 3 (40), l'événement est déclenché par le système et la technologie UDEV. Ils initient une requête vers le contrôleur 21 (directement par SOCKET ou à travers le serveur d'application en HTTP) en l'informant de l'identifiant de la clé connectée et de l'identité du poste émetteur (adresse IP ou MAC). Le contrôleur 21, en lien avec la base de données 23, retrouve le profil associé à la clé USB, et ordonne l'opération de connexion au gestionnaire de session sur le terminal. Cet ordre parvient au gestionnaire de session localement sur le serveur, puisque le contrôleur et le gestionnaire de session sont hébergés par lui. En revanche, c'est à distance que le client léger 3 est sollicité par le serveur pour recevoir les informations graphiques envoyées par celui-ci (technologie X11 éventuellement couplées aux technologies NX). Le choix du site d'exécution des applications est configuré au niveau base de données pour les logiciels référencés. En condition d'utilisation d'un client léger, les applications peuvent être exécutées soit sur le TX, soit sur le serveur, suivant leur configuration système ou en base de données. Ce choix impacte directement les consommations de ressources (processeur et RAM du poste distant) ou réseau. En pratique, la connexion de la clé USB 5 de l'intervenant sur un client léger 3 est interprété par le serveur comme déclenchant le chargement, sur le poste client léger concerné, du profil individuel associé à la clé USB connectée, lequel profil individuel comprend l'interface de contrôle (IHM) permettant à l'intervenant d'accéder à l'application de modification et à la base de données et, modifier le cas échéant les profils types, par exemple en choisissant un nouveau profil parmi plusieurs, ou en modifiant le profil courant avec de nouveaux paramètres. Cette interface de contrôle accède à la base de données 23 à travers le contrôleur 21 et offre le choix de connexion de profils sur le réseau 1 des postes clients 3 gérés par le serveur 2. . La gestion des profils se fait au travers de l'interface métier (IHM) ; elle permet de créer, modifier ou supprimer des profils de groupe ou individuel. Notamment, l'interface permet : • de sélectionner ou d'enlever les logiciels. • de transformer le poste en Borne applicative (seulement un windows manager et pas de desktop manager) si un seul logiciel est choisi. • de choisir si l'on veut les raccourcis sur le bureau. • de choisir si l'on veut la barre des tâches (avec les menus complétés ou pas). • d'associer une ou plusieurs imprimantes au profil. • de gérer l'espace disque accessible à ce profil. • d'associer le profil à un/des mode(s) de connexion (USB, Automatique, Console) L'interface de contrôle IHM (développée par exemple en technologie XUL, associée à un serveur d'application JAVA) permet de choisir ou modifier les valeurs en base de données 23, et par conséquent de modifier les profils. Ensuite, le contrôleur se sert de ces valeurs pour exécuter la chaîne de fabrication qui mène aux répertoires d'exploitations 27 (voir Fig. 3, étapes 33 et suivantes) (technologies java 5 associées à des technologies SHELL pour utiliser et exécuter des commandes et outils systèmes).

Notamment, après modification du profil général actif par l'intervenant, au retrait de la clé USB (42), un événement similaire de déconnexion est généré par UDEV au contrôleur 21 depuis le client léger. Un tel événement est interprété par le contrôleur, du fait de la modification préalable, comme une requête en connexion (50) des profils sur les postes dédiés (ceux qui auront été au préalable associés au profil). Le déploiement conformément aux étapes 51 et suivantes s'applique. La Fig. 5 illustre également la réinitialisation des profils depuis l'angle de vue du contrôleur 21. Le retrait du média amovible clé USB ou tout événement équivalent (60) est interprété comme une demande de déconnexion (61). Le contrôleur sollicite alors une fin de session sur l'ensemble des postes concernés (62). Une requête en réinitialisation de profil est émise par le contrôleur (63). Ce dernier efface le répertoire personnel de l'utilisateur système précédemment connecté (64) puis copie le répertoire personnel de l'utilisateur système associé comme modèle au profil à la place du répertoire personnel de l'utilisateur qui vient d'être déconnecté et supprimé (65). Il s'en suit une attribution des droits sur ce répertoire copié à l'utilisateur qui vient d'être déconnecté (66).

Sur le serveur (41), le même mécanisme de sollicitation du contrôleur initié par UDEV, puis transmise par le SHELL ou un client JAVA à une de ses socket ou via le serveur d'application en HTTP, permet de lui fournir des informations pour lancer certaines opérations. Dans ce contexte, le contrôleur évalue l'identifiant de la clé USB connectée au serveur en regardant la base de donnée. Si elle est identifiée comme une clé reliée à un profil général, elle déploie (voir étapes 50 à 58) sur tous les terminaux du groupe 4d (ceux qui dépendent de l'identifiant de clé connectée au serveur) le profil général auquel elle est associée.

Pour modifier les environnements d'exécution des postes du groupe 4d, l'intervenant retire la clé USB 5 du serveur d'application 2, ce qui déconnecte l'ensemble des postes. Il insert (40) ensuite la clé USB 5 dans un des clients légers 3 du réseau 1 de sorte à accéder à un profil personnel comprenant l'interface de contrôle (IHM) pour modifier les profils (voir ci-dessus le comportement du terminal 3 et du serveur 2). Une fois les modifications apportées au profil, l'intervenant ré-insert la clé USB 5 dans le serveur d'application 2 (étape 41) déclenchant le redéploiement des environnements d'exécution comme illustré précédemment en relation avec les Fig. 5 et 6.

Les utilisateurs systèmes liés aux profils sont tous recréés au moment du démarrage du serveur, grâces aux valeurs enregistrées en base de données ou dans un système de fichier non volatile. En effet, les mécanismes d'authentification du gestionnaire de session sont basés sur un système réinitialisé au démarrage du serveur (ce qui lui confère son pouvoir de redémarrage en étant configuré comme au précédent démarrage), alors que la base de données ne l'est pas. On reconstruit donc toutes les données du système d'authentification du gestionnaire de session à chaque redémarrage du serveur. Cette fonction est assurée par un script SHELL inséré dans le system V de démarrage du serveur.

Les répertoires personnels des utilisateurs sont stockés sur une partition du disque dur, non réinitialisée par défaut. De ce fait, les profils individuels ou généraux peuvent disposer de leurs données personnelles qui résisteront à un redémarrage du serveur.

Mais le système offre la possibilité (configurée au moment de la création du profil), de réinitialiser les répertoires personnels de certains profils (individuels ou généraux). Cette opération consiste en : a). l'effacement du répertoire d'exploitation b). la copie du répertoire de réinitialisation à sa place c). l'attribution des droits à l'utilisateur linux sur son nouveau répertoire d'exploitation

Claims (14)

REVENDICATIONS

1. Procédé de gestion de l'environnement d'exécution d'une pluralité de clients légers appartenant à un réseau informatique, l'environnement d'exécution de chacun desdits clients légers étant défini sur un serveur d'application du réseau sur la base d'une copie d'un premier profil enregistré sur ledit serveur d'application, le procédé étant caractérisé en ce qu'il comprend - une étape de modification dudit premier profil, -suite à ladite modification, l'initialisation de l'environnement d'exécution des clients légers par un nouvel environnement d'exécution propre à chaque client léger et défini sur le serveur d'application sur la base d'une nouvelle copie du premier profil modifié, - ladite initialisation étant effectuée suite à la détection d'un événement informatique lié à l'insertion ou au retrait d'un média amovible sur l'un des équipements du réseau, les équipements comprenant les clients légers et le serveur d'application.

2. Procédé selon la revendication précédente, comprenant préalablement à la modification, l'insertion dudit média amovible dans un premier client léger, ladite insertion dans le premier client léger déclenchant le chargement d'une interface logicielle apte à modifier ledit premier profil depuis ledit premier client léger.

3. Procédé selon la revendication précédente, dans lequel ledit média amovible comprend des données d'identification, ledit serveur d'application comprend une pluralité de profils associés auxdites données d'identification, et ladite modification comprend la sélection d'un desdits profils comme premier profil.

4. Procédé selon l'une des revendications 2 et 3, dans lequel ledit événement informatique est la détection du retrait dudit média amovible du premier client léger.

5. Procédé selon l'une des revendications 2 à 4, dans lequel l'initialisation des clients légers comprend les étapes suivantes : - la déconnexion desdits clients légers, - la suppression desdites copies de profils associées aux clients légers, - pour chacun desdits clients légers, la création d'une nouvelle copie du premier profil modifié sur le serveur d'application, - le lancement de chaque client léger de ladite pluralité dans un environnement d'exécution défini sur la base de la nouvelle copie de profil associé audit client léger.

6. Procédé selon l'une des revendications 1 à 3, dans lequel ledit événement informatique est la détection de l'insertion dudit média amovible dans ledit serveur d'application.

7. Système pour la gestion de l'environnement d'exécution d'une pluralité de clients légers, comprenant un réseau informatique auquel sont connectés lesdits clients légers et un serveur d'application, l'environnement d'exécution de chacun desdits clients légers étant défini sur le serveur d'application sur la base d'une copie d'un premier profil enregistré sur ledit serveur d'application, caractérisé en ce que : - le serveur d'application comprend un contrôleur agencé pour recevoir des instructions de modification et pour modifier en conséquence ledit premier profil, et un gestionnaire de session agencé pour initialiser l'environnement d'exécution des clients légers par un nouvel environnement d'exécution propre à chaque client léger et défini sur le serveur d'application sur la base d'une nouvelle copie du premier profil modifié, - ledit contrôleur étant apte à détecter un événement informatique lié à l'insertion ou au retrait d'un média amovible sur l'un des équipements du réseau, les équipements comprenant les clientslégers et le serveur d'application, et à piloter ledit gestionnaire de session suite à ladite détection pour initialiser les clients légers.

8. Système selon la revendication précédente, comprenant, en outre, un premier client léger muni d'une interface apte à accueillir et lire un média amovible, ledit contrôleur étant agencé pour charger, dans l'environnement d'exécution dudit premier client léger, une interface logicielle de modification dudit premier profil lors de la connexion d'un média amovible au travers de l'interface du premier client léger.

9. Système selon la revendication précédente, dans lequel ledit média amovible comprend des données d'identification et le serveur d'application stocke une pluralité de profils associés auxdites données d'identification, ladite application de modification étant agencée pour modifier au moins un profil parmi ladite pluralité de profils.

10. Système selon la revendication précédente, dans lequel un drapeau d'activation est associé à chacun des profils de ladite pluralité de profils, un seul desdits drapeaux étant actif à la fois.

11. Système selon l'une des revendications 8 à 10, dans lequel ledit événement informatique est la déconnexion dudit média amovible au travers de ladite interface du premier client léger.

12. Système selon l'une des revendications 7 à 10, dans lequel le serveur d'application comprend une interface apte à accueillir et lire un média amovible et ledit événement informatique est la connexion dudit média amovible au travers de ladite interface du serveur d'application.

13. Système selon l'une quelconque des revendications 7 à 12, dans lequel : - ledit gestionnaire de session est agencé pour déconnecter lesdits clients légers suite à une modification dudit premier profil, 30ledit contrôleur étant, en outre, agencé pour supprimer lesdites copies de profils associées aux clients légers et, pour chacun desdits clients légers, créer une nouvelle copie du premier profil modifié, - le gestionnaire de session étant, en outre, agencé pour relancer chaque client léger dans l'environnement d'exécution défini sur la base de la nouvelle copie de profil associée audit client léger.

14. Système selon l'une quelconque des revendications 7 à 13, comprenant au moins une deuxième pluralité de clients légers et le serveur d'application comprenant au moins un deuxième profil sur la base duquel sont définis les environnements d'exécution des clients légers de ladite deuxième pluralité.