FLASH INFORMATIQUE FI



MSI en pratique ou l’utilisation d’InstallShield Admin Studio dans l’expérience Laptop




Laurent KLING


Pour un usager, la partie émergée de l’iceberg de l’installation : l’interface utilisateur 

Préambule

Dans l’article paru dans le FI 10/02, JIT, ou l’utilisation de Remote Installation Services pour l’expérience Laptop, j’ai décrit la méthode utilisée pour déployer la configuration système et les applications utilisées pour cette expérience.

Actuellement, les portables sont aux mains des étudiants et le seul moment où nous apercevons physiquement les machines se situe pendant les réinstallations (nombreuses, environ 30%) et les pannes matérielles (heureusement rares, moins de 5%).

La principale cause des réinstallations est une dégradation importante des fonctionnalités due aux interactions des SpyWare, comme ceux inclus dans Kazaa, (voir l’article de peer en peer, de Jacques Virchaux & Philippe Pichon paru dans le numéro de mars 2003.

J’ai proposé le paradigme suivant et réalisé les trois premières étapes :
• mise à disposition du réseau [existant] ;
• installation système automatique [par le réseau] :
• installations logicielles génériques automatisées [par le réseau] ;
• installation logicielle spécialisée manuelle [par le réseau].

Essayons de mettre en pratique la dernière étape de cette démarche.

Principes

Dans le cas de cette expérience, on se retrouve à l’intersection de deux modes de fonctionnement :
• la mise à disposition d’outils clés en main pour les étudiants ;
• la gestion administrative d’un ordinateur.

Ces deux modes sont contradictoires :
• configuration clés en main :
 • contrôle uniforme des accès ;
 • accès aux ressources normalisé ;
 • éviter les installations différentes de celle prévue ;
 • fonctionnement selon une logique de boîte noire.
• gestion autonome de son ordinateur :
 • administration complète de l’ordinateur ;
 • compréhension du mode de fonctionnement interne de la machine.

Pour résoudre cette dualité, une solution simple apparaît immédiatement, définir le mode de gestion en fonction de l’identification (une vérité de La Palice). L’utilisation d’un accès protégé par VPN avec la transmission sans fil engendre également une série de contraintes supplémentaires :
• impossibilité de prévoir quand la machine est connectée ;
• modifications de la configuration au démarrage rendues inopérables, car la machine n’est pas connectée au réseau à ce moment (la connexion VPN s’établit à l’identification de l’usager) ;
• le protocole PXE est inactif.

Seules sont possibles, soit des modifications de la configuration à l’identification, soit des modifications volontaires par l’usager.

Après cette brève introduction, voyons comment a été réalisé le travail.

Mise en oeuvre

Suivant le court délai de la mise en oeuvre de l’installation des portables (un mois) la configuration de logiciels mis en place est :
• bureautique :
 • Office 2000, version française ou anglaise
 • FileMaker 5.5, version française
• communication :
 • Internet Explorer 5.01 SP 3 & Netscape 6.2
 • WsFTP
 • WinZip
 • Acrobat Reader
 • Terminal X 3D, Xceed 6.0
• simulation :
 • Mathematica 4.2
 • MathCad 2000
 • MatLab Student
 • LabView 6
• sécurité :
 • McAffe 4.51.

Le portable est automatiquement membre du domaine Active Directory de la Faculté STI, et dans l’unité d’organisation (OU) appropriée, grâce à la mise en oeuvre de RIS.

Un script réalise la personnalisation de la machine, en particulier la création d’un compte usager local, dont les données (profil) sont redirigées sur la partition de travail, et le changement du mot de passe administratif. Ce script utilise les technologies similaires (VBScript et ADSI) décrites dans mon article Windows 2000, Active Directory et ADSI, une expérience de département paru dans le numéro 8/2001, http://dit-archives.epfl.ch/FI01/fi-8-1/8-1-page1.html.

La deuxième étape fut l’intégration de l’identification du domaine STUDENTS pour bénéficier de ses services. Cette opération engendre un effet de bord, il désactive les comptes locaux non administratifs. Le palliatif est de déplacer ces comptes dans le groupe administratif.

La troisième étape, sujet de cet article, consiste à rendre disponibles les nouvelles applications nécessaires pour le semestre en cours.

MSI dans le détail

Le point focal de cette démarche est l’utilisation de la technologie Windows Installer Package ou MSI, tiré des trois lettres de l’extension du fichier principal.

Dans la jungle du processus d’installation, pratiquement chaque programme possède une méthode spécifique à son installation. Relativement tôt, Microsoft s’est rendu compte de cette limitation et a été encouragé par des demandes internes la mise en place d’une méthode uniforme pour installer, modifier et mettre à jour une application. La première version de cet outil fut utilisée pour la personnalisation de l’installation d’Office 2000 (voir mon article JIT, ou l’utilisation de Remote Installation Services pour l’expérience Laptop, paru dans le FI 10/2002, http://dit-archives.epfl.ch/FI02/fi-10-2/10-2-page3.html).

MSI offre pour une application :
• une interface standard pour les lignes de commandes ;
• une intégration complète du cycle de vie (installation, personnalisation, mise à jour, suppression) ;
• une capacité de résilience qui permet une réparation automatique de l’installation ;
• la capacité d’élever ses privilèges pour installer un logiciel par un usager qui ne possède par des droits administratifs.

Un fichier MSI est en fait une base de données qui identifie tous les composants, leur interrelation et leur mise en oeuvre, un schéma de celle-ci :

Administrator’s Introduction to Application Repackaging and Software Deployment using Windows Installer, p.93 

Actuellement en version 2.0 (intégré avec SP3), cet outil est la base du concept IntelliMirror disponible avec Active Directory.

InstallShield AdminStudio

La technologie MSI n’est pas majoritaire dans les installations actuelles et les outils disponibles avec le kit de développement sont trop spartiates pour intégrer une installation déjà existante. La firme InstallShield qui développe la technologie majoritaire pour les installations sur Windows 2000 a naturellement proposé un environnement intégré.

Pour pleinement utiliser cet outil, je recommande la lecture du livre suivant qui vient de paraître :

Administrator’s Introduction to Application Repackaging and Software Deployment using Windows Installer , Par Bob Baker & Robert Dickau , InstallShield Press , ISBN 0-9715708-1-7 

Ce volumineux ouvrage offre dans sa première partie (300 pages) une analyse exhaustive des technologies employées dans le processus d’installation,... à elle seule cette première partie mérite l’achat du livre. Dans une seconde partie, on procède à une analyse minutieuse du processus de capture d’une installation déjà existante.

Cet environnement est composé des outils suivants :
• OS Snapshot Wizard, pour capturer l’état d’une configuration dans l’objectif de l’utiliser comme base de travail dans l’outil d’analyse de conflits.
• Analysis Options Editor, permet la gestion de fichiers stencil de configuration en offrant une méthode standard dans une entreprise.
• Repackager, pour capturer les modifications, à la suite d’une installation. Il peut réaliser ce travail de trois manières différentes : capture, capture classique, moniteur.
• Legacy Setup Conversion Wizard, permet de convertir différents formats de distribution d’applications dans celui qui permet la création de MSI.
• Developper, pour créer des distributions, il permet une modification intuitive des différents composants et offre toutes les possibilités de personnalisation.
• Conflict Solver, pour analyser les conflits et les interactions des installations entre elles.
• Application Isolation Wizard, pour éviter et résoudre les conflits de DLL (Dynamic Linked Library). Librairie à chargement dynamique réutilisée par les différents logiciels.
• Tuner, pour générer des fichiers de transformation (MST) d’une installation sans modifier physiquement celle-ci.
• Distribution Wizard, pour générer les fichiers nécessaires à un point de distribution d’application.

InstallShield Admin Studio 3.5 

Ces outils sont intégrés avec une interface graphique pilotée par une base de données, Access ou SQL. Cette solution offre une réponse élégante à la demande de disposer d’un groupe de travail. On peut également intégrer n’importe quel autre outil pour bénéficier d’une interface unique.

La version utilisée dans cet article, 3.5, vient d’être remplacée par la version 5.0 qui offre une plus grande intégration.

Pour faciliter la mise en oeuvre du processus, trois outils supplémentaires ont été intégrés dans cette chaîne de développement :
• un point de distribution d’installation ;
• une base de données intégrant les différentes étapes d’intégration d’une installation ;
• l’utilisation d’une machine virtuelle pour l’environnement de test.

Point de distribution

Base physique de ce travail, il a été créé en respectant les critères suivants :
• homogène
• réutilisable
• automatisé.

Dans un premier temps, l’utilisation d’une structure similaire à celle de DISTRILOG a été envisagée. Malheureusement, celle-ci offre deux défauts rédhibitoires, une structure gérée humainement, sans règle précise sur l’organisation des différentes versions et langues utilisées et un accès sans contrôle (le compte Guest est activé).

L’idée principale est que cette structure doit présenter par son organisation une vue précise des fonctionnalités du logiciel, du fabricant, de son nom, de sa version et de sa langue utilisée. En pratique, cette structure est composée de la façon suivante :
 catégorie
 compagnie
 produit
 version
 langue

Les catégories sont les suivantes :
admin tous les outils d’administration,
cad tous les outils de dessin (Computer Aided ...),
db tous les outils de Data Base,
dtp tous les outils de publication (Desktop Publishing)
net tous les outils d’Internet
office toutes les suites bureautiques et similaires
pgm tous les outils de programmation
utilities tous les utilitaires
simul tous les outils de simulation scientifique
virus tous les outils de protection
sys tous les systèmes d’exploitation
update toutes les mises à jour systèmes

Pour éviter de devoir utiliser des chaînes de commandes entre guillemets, l’espace est banni dans les noms, remplacés par le souligné. La version est représentée par un nombre composé au maximum de trois chiffres, respectant la désignation de Microsoft. La langue se décompose dans les options suivantes :
fr français
en anglais
de allemand
mui pour multi-user-interface
engefr pour les installations d’Adobe
autres pour le reste.

Avec cette organisation, le chemin d’accès à une application nous renseigne sur sa qualité, et toutes les versions, ainsi que les mises à jour, sont dans le même dossier.

La même organisation se retrouve dans les dialogues d’installation pour l’usager, ce qui facilite son orientation. Il est facile de sécuriser certaines catégories, comme les outils d’administration par des droits d’accès appliqués à cette hiérarchie.

Pour la mise en oeuvre, les chemins, UNC, étant conservés dans la machine qui a effectué une installation par MSI, il est primordial de garder l’organisation du point de distribution sans modifications le long de la durée de vie de l’application. Pour cela, une solution DFS a été mise en oeuvre pour la Faculté STI, le chemin est : \\sti\net\app.

Une base de données pour le processus

La grande quantité d’informations demandées et engendrées par le processus d’intégration d’installation doit être conservée quelque part.

Comme tout ce processus est souvent récursif, la solution retenue est une base de données réalisée en FileMaker Pro.

Les deux premières étapes dans FileMaker 

FileMaker offre par sa simplicité l’outil idéal pour réaliser cette base de données dans une phase d’élaboration. Dans un second temps, s’il est nécessaire de disposer d’une version plus étendue, sa conversion dans une base de données SQL est possible. La génération complète des chemins de fichier facilite le déroulement du processus dans ces différentes étapes. On peut facilement utiliser les capacités des lignes de commande de chacun des outils d’InstallShield Admin Studio pour automatiser le déroulement des opérations.

 

 

Définition d’une machine de référence

La démarche décrite nécessite une machine de référence. Cette machine doit être la plus neutre possible pour éviter une interaction avec le programme à installer.

En pratique, cette machine ne devrait posséder que le système d’exploitation avec les mises à jour de sécurité similaires au parc informatique utilisé.

Microsoft recommande de séparer les distributions par catégorie physique d’ordinateurs. Sans aller à cette extrémité, il est recommandé de ne pas installer des pilotes qui intègrent une partie applicative (comme souvent les cartes graphiques ou de réseaux).

La possibilité d’utiliser un logiciel pour cloner le disque dur est envisageable, mais reste fastidieuse.

On serait tenté de ne pas tenir compte de ces recommandations, mais cela entraînera des conséquences fâcheuses. Elles seront particulièrement exotiques avec la capacité de résilience du MSI.

 

 

Utilisation de VMware

Comme décrit dans un Livre Blanc d’InstallShield, l’utilisation d’une machine virtuelle offre un gain de temps appréciable dans le processus de capture et de test.

En particulier, il peut être intéressant d’étudier deux caractéristiques de VMware :
• la gestion des disques durs
• la gestion du réseau.

Comme souvent pour les simulateurs de machines virtuelles, le disque dur peut être simulé par un fichier correspondant à un volume. Le point le plus intéressant est la gestion des modifications :
 Non persistent, ne sauvegarde rien physiquement, mais se comporte pendant son fonctionnement comme un disque avec un accès en écriture. L’activation de l’option Repetable resume permet de bénéficier de cette capacité même si la machine est redémarrée, particulièrement intéressant pour la capture de certains programmes qui nécessitent de redémarrer l’ordinateur pour poursuivre l’installation.
 Undoable, permet de sauvegarder les modifications si on le désire à l’extinction de la machine virtuelle. Une astuce dans l’utilisation de ce mode, permet une copie du fichier Undo et offre l’utilisation de variante du même disque où seules les modifications sont réellement sauvegardées offrant une économie de place certaine (10% de 1 Go).

La gestion des ressources réseau est particulièrement riche. Après l’installation de VMware, on bénéficie de 2 réseaux virtuels, plus la possibilité d’utiliser le réseau réel de la machine hôte.
• Le plus intéressant, à mon point de vue, est celui du mode Host Only, il offre un réseau isolé du monde réel où dans une classe IP de type C la moitié des adresses sont accessibles de manière fixe et l’autre moitié avec un serveur DHCP intégré.
• En plus, l’ordinateur hôte peut accéder à ces ressources isolées.

Les deux réseaux virtuels 

Pour ceux qui resteraient sur leur faim, on peut encore activer huit autres réseaux virtuels et simuler ainsi des architectures réseau particulièrement complexes avec une machine possédant la mémoire suffisante.

Dans la pratique, j’ai créé un serveur Active Directory complet et deux postes de travail, un isolé et l’autre membre du domaine AD virtuel. Les deux postes de travail partagent la même infrastructure physique de disque dur et ne sauvegardent que leur différence respective. Cela permet une économie d’espace disque de 1 Go.

Les deux machines virtuelles en fonctionnement :
• le serveur, l’édition d’une GPO sur une OU ;
• le poste de travail dans le domaine virtuel, un test d’installation.

La hiérarchie qui apparaît dans le domaine virtuel est semblable à celle de la Faculté STI, les deux machines, réelle et virtuelle, sont créées avec les mêmes programmes.

Créer un MSI depuis une installation

La procédure pour créer une installation dans le format MSI est la suivante :
• capturer les modifications d’une installation sur une machine de référence ;
• définir les caractéristiques ;
• créer un fichier d’installation ;
• éditer celui-ci pour définir les options ;
• générer une installation ;
• vérifier sa conformité ;
• installer sur une machine de référence ;
• vérifier l’installation avec différents types d’utilisateur.

à l’étape de capture et à celle de génération du fichier d’installation, on peut utiliser un stencil.

Il est important de comprendre l’interaction d’une installation avec les usagers. elle peut être de trois sortes avec les différents profils :
• Installation en mode administrateur local, dans ce cas, c’est le partie All Users qui est mise à jour, cela signifie que chaque usager va bénéficier des nouvelles fonctionnalités.
• Installation en mode utilisateur déterminé : ce mode, est possible uniquement avec un MSI, car il permet une élévation de privilège temporaire, ne concerne que l’usager qui bénéficie de nouvelles fonctionnalités.
• Tentative d’installation par un usager sans droit spécifique, va entraîner une impossibilité de l’installation, car les droits de sécurité des différents composants n’autorisent pas cette pratique.

 

 

HKEY_CURRENT_USER

Sous cette dénomination barbare se cachent les différentes clés de registres spécifiques à l’usager courant. Ces clés peuvent paraître sans importance majeure, mais leur interaction, en particulier avec la notion de résilience peut être particulièrement perverse pour l’usager.

Un exemple pratique de ses effets :
• Le premier programme que j’ai capturé est Acrobat Reader 5.0.5, cette opération a été effectuée avec les maigres connaissances dont je disposais à l’époque.
• Après les différents tests d’usage, le résultat me paraissait digne d’utilisation et je l’ai intégré dans l’image, SysRep, que j’ai créé pour l’expérience Laptop.
• Très rapidement après la distribution des ordinateurs, mes assistants étudiants m’ont fait part d’effets étranges, en particulier des demandes répétées quatre ou cinq fois successivement, de réinstaller un composant d’Acrobat depuis le point de distribution.

La solution a été de copier le MSI d’Acrobat Reader localement, de désinstaller la version installée, puis de réinstaller le composant.

L’explication théorique

J’avais trouvé une solution satisfaisante, mais je restais sur ma faim, quelles étaient les causes exactes de ce comportement ?
• J’ai trouvé l’explication dans le livre cité en page 3, que je vous recommande d’acheter puis de lire jusqu’à plus soif.
• La cause provient de cinq petits fichiers, 4 icônes et un fichier XML installés par utilisateur !
• InstallShield a automatiquement détecté cette modification du profil utilisateur, et pour l’intégrer dans l’installation, a généré une logique permettant d’activer la résilience au changement d’utilisateur

Pour le côté amusant, cette fonctionnalité a disparu de la version suivante 5.1 d’Acrobat Reader.

 

 

La résilience ?

Ce n’est pas celle de la résistance des matériaux ou celle utilisée en psychiatrie (pour celle-ci, je recommande la lecture de l’ouvrage de Boris Cyrulnik, Un merveilleux malheur). Dans la logique d’un MSI, ce serait plutôt la capacité de l’application installée de se réparer par elle-même. Ce concept paraît particulièrement séduisant, mais a un effet de bord parfois désagréable.

Mise en pratique avec la notion de sauvegarde des chemins d’installation, elle entraîne le fonctionnement suivant :
• recherche automatique du chemin UNC mémorisé ;
• utilisation de la ressource si elle est disponible ;
• affichage du dialogue pour proposer un autre cheminement pour accéder à la ressource désirée.

Cela paraît un mode de fonctionnement très sain, sous réserve que si on ne désire pas indiquer un autre cheminement, le dialogue apparaît pour chacun des composants manquants. Ceci explique les 5 fenêtres de dialogue observées précédemment.

En pratique, le processus de création d’un MSI doit être répété le nombre de fois nécessaires à obtenir une installation de qualité.

Le résultat de l’intégration d’une installation est de trois ordres :
1. MSI, le processus de génération a réussi, ou bien la distribution existe déjà sous cette forme.
2. manuel, le processus d’intégration de l’installation a échoué, seul un mode manuel est possible.
3. automatique, l’installation est soumise à des règles propres, elle permet une intégration dans un mode sans intervention.

Un exemple concret : Basilisk II JIT

Pour un enseignement, une série de programmes ont été conçus afin de modéliser le processus de développement des turbos machines.

Une version obsolète de Basic

Malheureusement, la variante du langage utilisé, Future Basic 2.0.2 de 1996, est peu standard et les programmes utilisent une interface graphique d’entrée-sortie propre à ce Basic. En plus, cette variante exotique de Basic est supportée par un unique individu sur la planète et uniquement sur la plate-forme Macintosh OS 8 ou 9.

La transposition automatique du code source dans un Basic plus répandu n’est pas possible, en particulier pour l’interface graphique utilisé en entrée-sortie.

Comme cette interface graphique est au coeur de l’utilisation de ces programmes de simulation, seule restait la solution de l’émulation.

Un environnement d’émulation

Heureusement, la communauté du logiciel libre a développé une version gratuite d’un logiciel d’émulation du Macintosh sous OS 7 ou 8.

Ce logiciel, Basilisk, offre un simulateur de processeur 68’000 et 68’881 qui permet son utilisation avec un système d’exploitation qui n’utilise que ces processeurs.

Comme ce logiciel est destiné à un public d’amateurs avertis, l’installation de base ne concerne que le logiciel en question. On doit prendre son épuisette pour pêcher ici et là sur le réseau les éléments nécessaires à son bon fonctionnement.

Ensuite, on peut créer l’image du disque dur, un fichier, installer les différents systèmes et obtenir finalement un environnement utilisable pour l’élève.

Basilisk II : le résultat de la capture 

La mise en place d’une telle démarche nécessite une bonne expérience de ces genres d’outils, des différents OS utilisés et un peu d’acharnement. Cela semble trop d’efforts à demander à des élèves qui ne désirent qu’exécuter un programme de simulation

La création d’une distribution directement fonctionnelle

L’objectif est d’obtenir une installation qui évite à l’usager la complexité de cette mise en oeuvre et qui lui fournisse une solution directement utilisable. Heureusement, un des modes de capture convient parfaitement à nos besoins. Il offre une capture de l’état du système avant l’installation, permet d’installer le logiciel et d’effectuer les modifications, puis de capturer de nouveau l’état final pour générer la différence entre ces deux états.

Il suffit de considérer l’installation des différents outils complémentaires comme des modifications pour que l’intégration souhaitée soit réalisée. Le résultat du processus de création du fichier MSI est intéressant, car il a permis d’éliminer un certain nombre de scories :
• fichiers temporaires inutilisés ;
• fichiers des systèmes d’exploitation autres que la plateforme cible ;
• élément de l’installateur en conflit avec les règles d’intégrité, car hérité d’une version trop ancienne.

Basilisk II : une partie des paramètres possibles dans Developer 

Basilisk II : le dossier généré avec le MSI 

Le résultat final est obtenu en éliminant successivement les éléments fâcheux dans une application successive du processus capture - génération MSI - installation.

L’impression pose problème, car le réseau (AppleTalk) n’est pas simulé. Une manière élégante de contourner ce problème d’impression est d’utiliser un produit comme PrintToPdf qui génère correctement un PDF de type 1 directement enregistré sur le disque dur local de l’ordinateur hôte.

Pour éviter les questions juridiques liées à l’utilisation d’un composant nécessaire à ce simulateur, il faut une copie de la Rom d’un Macintosh :
• l’installation proposée n’intègre pas de Rom ou de copie de celle-ci ;
• pour la phase de test, j’ai simplement utilisé une copie de la Rom d’un des nombreux Macintosh en ma possessionÉ depuis 1984.

L’utilisation d’un JIT

Un étudiant français, a eu la bonne idée de consacrer son travail de diplôme à l’intégration des techniques récentes de compilation dynamique, JIT, sur ce logiciel. Sur une machine récente, comme celle utilisée pour l’expérience Laptop, la performance obtenue en émulation de 30 à 80 Frames par seconde est particulièrement satisfaisante. Pour l’efficacité. le démarrage prend moins de 11 secondes pour arriver sur le bureau. Pour éviter un effet de traînée induite par le contrôleur vidéo du portable, Basilisk II JIT fonctionne en mode plein écran, ce qui entraîne un effet particulièrement plaisant à observer sur un Macintosh, (pardon une émulation), en fonction sur un PC.

IntelliMirror

Nous voici à la phase finale de notre périple vers une installation automatisée.

La méthode la plus simple est d’utiliser les fonctionnalités intégrées dans le GPO, Group Policy Object. Il existe deux méthodes pour déployer une application dans cet environnement :
1. assignée, avec cette méthode, l’application est automatiquement installée dès la mise en oeuvre de la GPO. Cette méthode nécessite impérativement une application avec un format MSI.
Toutes les modifications des paramètres doivent être encapsulées dans un fichier de transformation MST.
La mise en oeuvre est délicate, les différents fichiers doivent être (MSI, MST) configurés silmutanément lors du paramètrage de la GPO ;
2. publiée, dans ce cas, l’installation n’est pas effectuée automatiquement, elle se réalise par une intervention de l’usager dans le panneau de configuration, Ajout/Supression de programmes, avec la rubrique Ajouter un nouveau programme.

Cette méthode accepte deux types de fichier, MSI ou ZAP, le fichier ZAP est un simple fichier texte contenant les informations nécessaires au lancement de l’installation.

Ces différents modes ont une influence directe sur la disponibilité du programme pour les différents usagers d’un MSI :
• assignée à un ordinateur, dans ce cas, l’application est installée en mode Administrateur de l’ordinateur et elle est disponible pour tous les usagers de l’ordinateur. Elle s’effectue au démarrage de l’ordinateur, quand la GPO est appliquée ;
• assignée à un utilisateur, similaire au cas précédent, mais avec une différence fondamentale, l’installation n’est disponible que pour l’usager qui s’est connecté. Elle s’effectue lors de la connexion de l’usager ;
• publiée à un utilisateur, identique au cas précédent, mais uniquement si l’utilisateur le désire.

Le cas d’un fichier ZAP publié à un usager est paradoxal :
• il n’effectue aucun contrôle de sécurité ou d’élévation de privilège, il se contente d’exécuter le programme d’installation qu’on lui désigne ;
• en pratique, cela signifie que l’usager doit être membre du groupe local de sécurité Administrator ou Power User pour réaliser cette installation ;
• cette contrainte le rend de ce fait peu utile.

Quelles sont les possibilités pour une installation en mode MSI avec l’environnement réel de l’expérience Laptop ?

Je rappelle que les machines ne sont pas connectées au réseau au démarrage, elles utilisent un réseau sans fil où la connexion se fait à l’identification de l’usager :
• en conséquence, pas d’assignation possible pour l’ordinateur.

L’identification dans le réseau Windows utilise le domaine STUDENTS :
• le résultat est que l’installation peut être assignée ou publiée, mais uniquement pour l’usager connecté dans le domaine STUDENTS ;
• celle-ci semble être la solution, mais je rappelle que les machines sont des portables et que par définition ils peuvent travailler sans être connectés à un réseau, donc sans identification à un domaine.

Bref, nous voici en face d’un problème en boucle suivant : sécurité = identification, installation = sécurité, utilisation = pour tous (sans identification).

Après de tels efforts pour mettre en place une logique de distribution, on se retrouve devant une impasse pour la phase de mise en oeuvre, un projet qui échoue à 1 % de l’objectif ?

Non, car il existe une solution, gérer la phase d’élévation de privilège avec une installation publiée utilisant un fichier ZAP !

L’émulateur in situ, sur un portable de l’expérience laptop 

Elévation de privilège avec RunAs Pour élever le privilège d’un processus, opération intégrée avec l’utilisation d’un MSI, on peut simplement utiliser la commande système RunAs :

RUNAS [/profile] [/env] [/netonly] /user:<nomutilisateur> programme
/profile            si le profil de l'utilisateur doit être chargéâ
/env                pour utiliser l'environnement en cours à la place de celui de l'utilisateur.
/netonly            utiliser si les informations d'identification spécifiées sont pour l'accès à distance seulement.
/user                <nomutilisateur> sous la forme UTILISATEUR@DOMAINE ou DOMAINE\UTILISATEUR
program                ligne de commande pour EXE

La logique voudrait que la ligne de commande suivante fonctionne :

runas /user:sgmstud2\administrator Setup.exe

On obtient une erreur, après lecture des notices techniques, où est indiqué que RunAs nécessite le chemin complet de la ressource sous un format UNC :

runas /user:sgmstud2\administrator
\\sti\net\app\manual\simul\rockwell_software\arena\5.0.2\en\Setup.exe

Et malheureusement, une erreur similaire à une erreur de droit d’accès apparaît. Cela semble bizarre, car le chemin UNC est monté localement et on possède les droits de lecture sur cette hiérarchie, mais le plus étrange est que si on exécute à la main le programme, tout fonctionne parfaitement. Après une recherche approfondie sur la toile, ce problème est décrit, la solution préconisée est d’utiliser uniquement des volumes locaux !

Il apparaît incompréhensible qu’une commande intégrée dans le système présente un tel dysfonctionnement.

Après avoir essayé sur une machine virtuelle avec le SP1, la commande fonctionne parfaitement. Il existerait un trou de sécurité que le SP3 aurait comblé rendant cette commande inutilisable ? Une rechercheparticulièrement tortueuse avec comme critère les problèmes de sécurité comblés par SP3 nous renvoie enfin sur une information utilisable :
• les trois trous de sécurité de RunAs sont décrits comme la possibilité d’utiliser la connexion (pipe) entre processus pour introduire une commande pirate, problème sans résolution existante en SP2, mais prévue d’êtrecorrigée dans le prochain SP(3) ;
• ensuite, il suffit de lire la documentation complète de SP3 ou une phrase nous informe que la solution à ce problème est de se ré-identifier pour l’accès à une ressource réseau.

Donc, la commande doit démarrer un processus authentifié qui isole de toutes les ressources réseau auxquelles l’usager était connecté. En conséquence, il faut se ré-identifier, bref un problème quasi récursif.

Runas /profile /user:SGMSTUD2\administrator "cmd /k runas /user:STUDENTS\user_test /netonly \\sti\net\app\manual\simul\rockwell_software\arena\5.0.2\en\Setup.exe"

Pour faciliter le travail des usagers, un script génère automatiquement la commande adaptée à la machine et à l’usager qui exécute l’installation. Pour celui-ci, le résultat se décompose en 4 phases :
1. une fenêtre d’information lui précisant le déroulement des opérations ;
2. une fenêtre (sur fond noir) où il est invité à entrer son mot de passe administrateur local de la machine ;
3. une fenêtre (sur fond turquoise) où il est invité à rentrer le mot de passe de la session courante ;
4. puis les fenêtres (si elles existent) de l’installation proprement dite.

Avec cet artifice, on peut installer de manière simple pour l’usager une application, sans contraindre l’utilisateur à une compréhension complète des problèmes techniques sous-jacents.

L’installation effectuée ! 

Statistique d’installation

Dans le cadre de leur cursus, les é tudiants en génie mécanique ont une proportion très importante de cours à options à partir du 6e semestre. Les logiciels supplémentaires sont rarement destinés à l’ensemble des étudiants de l’expérience Laptop, mais à un groupe restreint. Comme l’installation se fait sur une base volontaire, il est difficile de répondre à la question : Tous mes élèves ont-ils installé le logiciel que je leur ai mis à disposition, car la semaine prochaine, je vais l’utiliser pour un exercice ? La réponse est facile dans une logique de mise à jour automatique, comme dans une salle informatique, mais reste ambigu’ dans la situation actuelle. Pour lever cette ambigu&iulm;té, un processus d’émission de courrier électronique est intégré dans le processus d’installation. La DLL nécessaire à son emploi, utilisable librement, est installée avec un processus similaire. Ainsi, on peut observer l’installation des programmes ou utiliser la fonction de tri du lecteur de courrier par machine ou par logiciel. L’émulateur in situ, sur un portable de l’expérience Laptop

Conclusion

La mise en oeuvre de ce processus est particulièrement astreignante, et comme Pénélope, il ne faut pas hésiter à remettre en cause son travail de la veille. Je remercie particulièrement ma famille, qui m’a autorisé à employer les week-ends pour ce genre d’activité.

Les quatre étapes du processus d’installation avec élévation manuelle de privilège 

Le principal bénéfice reste une interface simplifiée pour l’usager qui masque la complexité du processus. En plus, la compréhension du processus d’installation et sa confrontation avec l’environnement des machines en production permettent de prévenir et d’intégrer les différents problèmes.

Ainsi, on peut réaliser une économie d’échelle en transférant à l’administration système les activités qui lui sont propres et en libérant l’usager qui peut se consacrer à son activité principale, utiliser des applications.

Les applications installées 

La complexité de ce travail et son ampleur ne sont pas uniquement limitées à l’expérience Laptop mais permettent d’imaginer et de tester les méthodologies de services à l’intérieur de la Faculté STI qui m’emploie.

La première réalisation sera la mise à disposition d’un outil permettant l’installation complète sans intervention, des logiciels pour une configuration bureautique, sur un système de base (OS+drivers+SP).

Ceci sera sèrement l’occasion d’un prochain article dans ce journal.



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.