CHAPITRE 2 |
Ce chapitre décrit les nouvelles fonctions et modifications apportées aux versions 4.40, 4.31 et 4.30 de Secure Global Desktop.
Cette section décrit les nouvelles fonctions intégrées au logiciel Sun Secure Global Desktop version 4.40.
Le gestionnaire d'objets, le gestionnaire de baies, l'assistant de configuration et le gestionnaire de sessions, utilisés par SGD en tant qu'outils d'administration, ont été remplacés par la console d'administration SGD. La console d'administration SGD est une application Web à la disposition des administrateurs SGD pour la configuration de SGD.
La console d'administration est localisée dans les langues prises en charge par SGD : anglais, français, japonais, coréen, chinois simplifié et chinois traditionnel.
Pour utiliser la console d'administration, vous devez avoir activé JavaScript sur votre navigateur.
Dans la mesure du possible, exécutez la console d'administration sur le serveur principal dans la baie SGD. Il est préférable d'exécuter certaines opérations, comme la création d'objets ou la modification d'attributs d'objet, sur le serveur principal. Si vous effectuez ces opérations sur un serveur secondaire lorsque le serveur principal n'est pas en cours d'exécution, les modifications ne seront pas implémentées.
Pour lancer la console d'administration, suivez l'une des méthodes ci-dessous :
Cliquez sur le lien de la console d'administration sur le bureau Web d'un administrateur SGD.
Cliquez sur le lien Lancer la console d'administration Sun Secure Global Desktop sur la page de bienvenue du serveur Web SGD à l'adresse : http://exemple.serveur.com, où exemple.serveur.com correspond au nom d'un serveur SGD.
Allez à l'adresse http://exemple.serveur.com/sgdadmin, où exemple.serveur.com correspond au nom d'un serveur SGD.
Pour plus de détails sur la console d'administration, reportez-vous au Guide d'administration de Sun Secure Global Desktop 4.4 et au Manuel de référence de Sun Secure Global Desktop 4.4.
La terminologie de la console d'administration est différente de celle des versions précédentes de SGD.
Les termes habituels de la version 4.31 sont récapitulés dans le tableau suivant, avec leur équivalent dans la console d'administration.
SGD version 4.31 | Console d'administration |
---|---|
membre de la baie | serveur SGD |
bureau Web du navigateur | bureau Web |
session de l'émulateur | session d'application |
ENS (Enterprise Naming Scheme, schéma d'attribution de nom d'entreprise) | référentiel local |
nom équivalent d'ENS | profil utilisateur |
nom complet | identité de l'utilisateur |
hôte | serveur d'application |
routage des baies intelligent | groupe d'équilibrage de charge |
autorité de connexion | authentification système |
profil de connexion | profil utilisateur |
personne | objet de profil utilisateur |
TFN (Tarantella Federated Naming, attribution de nom Tarantella fédérée) | inutilisé |
session de bureau Web | session utilisateur |
Certains attributs ont été renommés dans la console d'administration. Le Manuel de référence de Secure Global Desktop 4.4 comprend les noms d'attribut utilisés dans la console d'administration, ainsi que leur équivalent dans le gestionnaire d'objets et le gestionnaire de baies.
L'URL (Uniform Resource Locator, localisateur de ressource uniforme) Desktop Direct permet aux utilisateurs de se connecter et d'afficher un bureau plein écran sans afficher un bureau Web.
L'utilisation de l'URL Direct Desktop requiert l'assignation d'un objet d'application appelé Mon bureau (nc=Mon bureau) à l'utilisateur. Cet objet est automatiquement créé lors de l'installation de SGD. L'objet est configuré par défaut pour exécuter l'application de bureau par défaut disponible sur le serveur SGD (Sun Java Desktop System par exemple). Vous avez la possibilité de reconfigurer cet objet pour qu'il exécute toute application ; vous obtiendrez cependant de meilleures performances avec des applications de bureau plein écran. Si les utilisateurs requièrent différentes applications de bureau, vous pouvez créer des objets Mon bureau supplémentaires. Cependant, chaque utilisateur ne peut disposer que d'une seule application Mon bureau.
Remarque - Un nombre illimité d'applications peut être assigné aux utilisateurs, mais l'URL Desktop Direct ne leur donne accès qu'à l'application Mon bureau. |
L'URL Desktop Direct est habituellement http://exemple.serveur.com/sgd/ mydesktop, où exemple.serveur.com correspond au nom d'un serveur SGD. La page de connexion SGD s'affiche aussitôt. Une fois l'utilisateur connecté, la session de bureau s'affiche et il peut fermer le navigateur Web.
Remarque - Il n'existe pas de commande pour suspendre ou reprendre l'application de bureau. Les utilisateurs doivent se déconnecter de l'application de bureau comme d'habitude. |
Les utilisateurs de périphériques client Microsoft Windows peuvent posséder un profil utilisateur itinérant. Grâce à ce profil utilisateur itinérant, ils disposent du même environnement de travail, quel que soit l'ordinateur Microsoft Windows utilisé. Si un utilisateur Microsoft Windows possède un profil utilisateur itinérant, son profil client SGD est automatiquement modifié pour permettre cette fonctionnalité :
Les paramètres spécifiques au périphérique client de l'utilisateur (la configuration de serveur proxy par exemple) sont stockés sur le périphérique.
Par défaut, il s'agit de disque_personnel\Documents and Settings\ nom_utilisateur\Local Settings\Application Data\Sun\SSGD\ profile.xml
Les paramètres spécifiques à l'utilisateur (la langue préférée par exemple) sont stockés dans le répertoire du profil utilisateur itinérant.
Il s'agit habituellement de disque_personnel\Documents and Settings\ nom_utilisateur\Application Data\Sun\SSGD\profile.xml
Remarque - Cet emplacement contient également les fichiers hostsvisited et certstore.pem de l'utilisateur. |
Les paramètres suivants du profil client SGD sont stockés dans le répertoire du profil utilisateur itinérant :
Paramètre de profil client | Entrée de profil itinérant |
---|---|
URL de connexion | <url> |
Ajout d'applications au menu Démarrer | <mode> |
Connexion client automatique | <autologin> |
Connexion en même temps qu'au système | <autostart> |
Échec de la connexion | <reconnect mode> |
Les administrateurs SGD ont à présent la possibilité de configurer un délai d'attente automatique pour les sessions utilisateur inactives.
Ce délai d'attente permet de suspendre les sessions utilisateur si aucune activité dans la session d'application ou sur le bureau Web n'a été relevée pendant un certain laps de temps. Le délai d'attente s'applique à tous les serveurs SGD de la baie.
Le délai d'attente peut être uniquement configuré depuis la ligne de commande. Vous ne pouvez pas le modifier depuis la console d'administration.
Configurez-le à l'aide de la commande suivante :
$ tarantella config edit \ ‐‐tarantella-config-array-webtopsessionidletimeout secondes |
Remplacez secondes par le délai d'attente, en secondes.
Lorsque ce paramètre est défini sur 0, la fonctionnalité de délai d'attente pour les sessions utilisateur inactives est désactivée. Il s'agit de la valeur par défaut.
Dans l'exemple suivant, les sessions utilisateur sont suspendues après 1 800 secondes (30 minutes) d'inactivité.
$ tarantella config edit \ ‐‐tarantella-config-array-webtopsessionidletimeout 1800 |
Vous pouvez à présent spécifier un filtre de masque de réseau lors de la définition des attributs suivants :
Le format du filtre de masque de réseau est le suivant : v.w.x.y/z. Les filtres précédents de type générique sont toujours pris en charge.
L'exemple suivant utilise un filtre de masque de réseau pour spécifier les noms DNS externes.
$ tarantella config edit ‐‐server-dns-external \ "192.168.55.0/24:boston.indigo-insurance.com" |
Un nouvel attribut de touches de gestion des fenêtres (--remotewindowkeys) est disponible pour les types d'objet suivants :
Avec cet attribut, les raccourcis clavier associés à la gestion des fenêtres peuvent être envoyés à la session distante ou utilisés localement. Ce paramètre n'est disponible que pour les applications dont le paramètre Type de fenêtre est défini sur Mode kiosque.
Pour quitter le mode kiosque lorsque cet attribut est activé, utilisez la combinaison de touches ALT+CTRL+MAJ+ESPACE. Cette opération minimise la session kiosque sur le bureau local.
SGD s'exécute sur SE Solaris 10 Trusted Extensions avec les restrictions connues suivantes :
SGD doit être installé sur une zone avec libellé. Reportez-vous au Guide d'installation de Sun Secure Global Desktop 4.4 pour plus de détails sur l'installation de SGD sur SE Solaris 10 Trusted Extensions.
Le disque client n'est pas pris en charge par les périphériques client UNIX [6610354].
L'audio n'est pas pris en charge par les plates-formes UNIX [6610352].
Le mode intégré n'est pas pris en charge par les plates-formes client SE Solaris 10 Trusted Extensions [6610371].
Le mode kiosque ne fournit pas les meilleurs résultats sur les plates-formes client SE Solaris 10 Trusted Extensions [6594795].
La console d'administration sert à la gestion globale des mots de passe et des jetons pour tous les utilisateurs SGD.
Vous pouvez à présent gérer les mots de passe et les jetons selon l'identité de l'utilisateur ou son profil. Auparavant, le gestionnaire d'objets ne pouvait gérer les mots de passe et les jetons que par profil utilisateur.
Si, par exemple, un serveur SGD possède plusieurs noms DNS, il est alors connu sous différents noms à l'intérieur et à l'extérieur d'un pare-feu. Vous pouvez spécifier les noms DNS supplémentaires en tant que noms d'objet alternatifs lors de la génération d'une CSR (Certificate Signing Request, demande de signature de certificat). Cette opération permet d'associer plusieurs noms DNS à un certificat de serveur.
La commande tarantella security certrequest vous invite à saisir les noms d'objet alternatifs lors de la génération d'une CSR.
La commande tarantella security certinfo permet d'afficher les noms d'objet alternatifs associés à un certificat.
Vous disposez d'un nouvel attribut de fichier de mappage des fuseaux horaires (--xpe-tzmapfile).
Cet attribut permet de spécifier un fichier contenant les mappages entre le périphérique client UNIX et les noms de fuseau horaire du serveur de l'application Windows. Il s'applique à tous les serveurs SGD de la baie.
Cette section décrit les nouvelles fonctions du logiciel Sun Secure Global Desktop version 4.31.
Les administrateurs SGD peuvent à présent activer le son dans les applications X dont l'accès s'effectue en utilisant SGD.
L'activation du son dans les applications X requiert les conditions suivantes :
Le périphérique client doit pouvoir effectuer de la lecture audio.
Le module audio UNIX du module d'enrichissement SGD doit être installé et en cours d'exécution sur le serveur d'application.
L'application X doit utiliser OSS (Open Sound System) pour la sortie son. Si votre système utilise ALSA (Advanced Linux Sound Architecture), il est possible que vous deviez activer les modules d'émulation ALSA OSS dans le noyau.
Le service audio SGD UNIX doit être activé dans la console d'administration. Ce service est désactivé par défaut.
Le module audio UNIX contient un émulateur de pilote audio OSS. L'émulateur de pilote audio est installé sur le noyau lors de l'installation du module audio UNIX du module d'enrichissement SGD.
Remarque - Dans la mesure où le module audio UNIX inclut un émulateur de pilote audio, il n'est pas nécessaire que le serveur d'application dispose lui-même d'une carte son. |
Certaines applications X utilisent du code permanent lorsqu'elles font appel à des périphériques /dev/audio ou /dev/dsp pour la sortie son. Un nouvel attribut pour les objets d'application X, la bibliothèque de redirection audio (--unixaudiopreload), permet à une bibliothèque de redirection audio SGD de forcer l'application X à utiliser le périphérique audio SGD.
Le Bureau à distance de Microsoft Windows Vista permet d'accéder à un ordinateur distant à l'aide du protocole Microsoft RDP (Remote Desktop Protocol). Vous pouvez maintenant utiliser cette fonction avec SGD afin de permettre, par exemple, à un utilisateur d'accéder à distance à son PC lorsqu'il est en déplacement. Seules les sessions de bureau Windows complètes sont prises en charge.
Vous pouvez également installer le module d'enrichissement SGD sur les périphériques client Microsoft Windows Vista pour la prise en charge du mappage du disque client. La fonction avancée d'équilibrage de charge et les fenêtres transparentes ne sont pas prises en charge.
Cette section décrit les nouvelles fonctions intégrées au logiciel Sun Secure Global Desktop version 4.30.
Le client SGD peut à présent fonctionner dans l'un des modes suivants :
Mode bureau Web : le bureau Web s'affiche avec le navigateur Web, de la même manière que dans les versions précédentes. C'est le mode par défaut.
Mode intégré : le contenu du bureau Web (les liens pour démarrer les applications) s'affiche dans le menu de démarrage du bureau. Ainsi les utilisateurs peuvent exécuter les applications à distance, tout comme ils exécutent les applications locales. L'utilisation d'un navigateur Web n'est pas toujours nécessaire. Elle dépend du mode de configuration de l'intégration au menu de démarrage.
Remarque - Utilisez le mode intégré si votre entreprise préfère ne pas utiliser la technologie Java sur le périphérique client. |
Pour accéder au mode intégré, vous devez vous connecter à SGD en cliquant sur le lien de connexion du menu de démarrage du bureau. Le mode intégré n'est pas accessible si vous vous connectez à partir d'un navigateur Web.
Le travail en mode intégré simplifie la gestion des sessions. À la différence du bureau Web, ce mode n'offre aucune commande de suspension ou de reprise d'applications. Lorsque vous vous déconnectez, le client suspend ou arrête automatiquement toutes les sessions d'application en cours d'exécution. Après reconnexion, le client reprend automatiquement toutes les sessions suspendues.
L'impression est également simplifiée. Les travaux d'impression peuvent être lancés en permanence et ils sont directement dirigés vers l'imprimante sélectionnée. En revanche, la gestion individuelle des travaux d'impression n'est pas prise en charge.
Si vous souhaitez accéder au bureau Web, par exemple pour relancer une application suspendue ou gérer les impressions, cliquez sur le lien correspondant dans le menu de démarrage. Le bureau Web s'affiche dans le navigateur Web par défaut.
Si vous avez configuré le contenu du bureau Web pour qu'il soit organisé en groupes, ces groupes s'affichent également dans le menu de démarrage. Si vous avez paramétré le masquage du contenu du bureau Web d'un groupe, ces informations ne s'affichent pas dans le menu de démarrage.
Pour vous déconnecter de SGD, cliquez sur le lien correspondant dans le menu de démarrage.
Pour obtenir des informations sur les systèmes de bureau qu'il est possible d'utiliser en mode intégré, consultez la section Configuration requise du client.
Vous pouvez à présent configurer le client SGD pour qu'il démarre automatiquement lorsqu'un utilisateur se connecte au périphérique client. Le client SGD peut également mettre un jeton d'authentification en mémoire cache, ce qui permet d'ouvrir une session utilisateur de manière automatique. Avec ce type de configuration, les utilisateurs bénéficient des avantages d'une connexion unique.
La connexion automatique s'établit par authentification de jeton. Si le client SGD présente un jeton d'authentification valide, SGD authentifie automatiquement l'utilisateur. Pour obtenir un jeton d'authentification, l'utilisateur doit se connecter à l'aide d'un navigateur Web, puis générer le jeton manuellement en modifiant son profil. Chaque serveur de connexion à SGD requiert un jeton différent.
Les fonctions du menu de démarrage du bureau et de connexion unique impliquent de configurer le client SGD en vue d'une connexion à SGD. En outre, la configuration requise peut varier en fonction des situations (travail au bureau ou travail à domicile, par exemple). La version 4.3 permet de gérer plusieurs configurations client par le biais de profils, une méthode de stockage de groupes de paramètres client. Chaque profil client permet de configurer les éléments suivants :
le mode de fonctionnement du client SGD, à savoir le mode bureau Web ou le mode intégré ;
le démarrage automatique du client SGD lorsque l'utilisateur se connecte au périphérique client ;
le type de configuration du serveur proxy, à savoir manuelle, par le biais du profil, ou automatique, d'après les paramètres du navigateur Web ;
les paramètres de reconnexion qui définissent le comportement du client suite à une perte de connexion à SGD ;
les paramètres de connexion qui définissent les données écrites dans le fichier journal client SGD ;
le chemin d'accès au visionneur PDF configuré pour l'impression de fichiers PDF sur les clients SE Solaris, Linux et Mac OS X.
Les administrateurs SGD disposent du contrôle total des profils clients grâce à l'éditeur de profils, nouvel outil d'administration, se trouvant sur leur bureau Web. Ils peuvent créer et modifier les profils clients pour les objets d'une organisation ou d'une unité d'organisation (UO) ainsi que pour les objets de profil de l'organisation d'objets système Tarantella. En définissant des profils clients pour ces objets, les administrateurs peuvent déployer des configurations client SGD par défaut courantes pour les utilisateurs.
Ils peuvent également autoriser les utilisateurs à créer et modifier leurs propres profils clients. La modification du profil utilisateur peut être activée à l'échelle globale, pour une organisation, une UO ou des utilisateurs individuels. Cette fonctionnalité est activée par défaut. Les profils sont créés et modifiés à partir du bouton Éditer du bureau Web.
Le profil par défaut configuré sur le système SGD offre aux utilisateurs le même bureau Web standard que dans les versions précédentes. Les administrateurs peuvent modifier ce profil.
Lorsque le client SGD se connecte à SGD, le profil configuré pour l'utilisateur est copié à partir de SGD vers le périphérique client. Si un utilisateur modifie son profil, les modifications sont stockées uniquement sur le périphérique client.
Le client SGD nécessite différents paramètres de serveur proxy en fonction de l'emplacement à partir duquel s'effectue la connexion à SGD. Il peut donc s'avérer difficile de s'assurer que chaque utilisateur dispose des paramètres de proxy adéquats. La version 4.3 propose la configuration de serveur proxy mobile. Grâce à la configuration de serveur proxy mobile, le client SGD utilise les paramètres dans le profil client pour définir les paramètres de serveur proxy. Les paramètres de serveur proxy peuvent être spécifiés comme suit :
manuellement : les paramètres du proxy sont stockés au sein même du profil client ;
automatiquement : les paramètres du proxy sont obtenus à partir du navigateur Web par défaut de l'utilisateur.
Si le client SGD fonctionne en mode intégré et s'il est configuré pour utiliser les paramètres du navigateur, il obtient les paramètres du proxy en chargeant l'URL spécifié dans le profil utilisateur du navigateur par défaut. Une fois les paramètres obtenus mis en cache, le client SGD peut les utiliser de façon à ce que le navigateur par défaut de l'utilisateur n'ait besoin d'être démarré qu'une fois.
Remarque - Pour déterminer les paramètres du proxy à partir d'un navigateur Web, la technologie Java doit être activée sur ce dernier. |
La ligne de commande du client SGD a été améliorée sur l'ensemble des plates-formes afin d'assurer la prise en charge des profils clients. Vous pouvez utiliser des arguments pour spécifier ce qui suit :
Grâce aux améliorations apportées à la ligne de commande, vous pouvez créer vos propres scripts de démarrage du client SGD et d'exécution d'applications.
Il est à présent possible de charger et d'installer manuellement le client SGD. Ce dernier peut ainsi être exécuté en mode intégré ou dans des environnements dans lesquels les navigateurs Web ne fonctionnent pas avec la technologie Java. Vous pouvez télécharger le client SGD à partir d'un serveur SGD sur le site Web http://exemple.serveur.com, où exemple.serveur.com correspond au nom d'un serveur SGD. Cliquez sur Installer le client Sun SGD pour installer le client SGD.
Cette version comporte un nouveau serveur X basé sur X11R6.8.2. Par rapport à la version 4.2, les performances du nouveau serveur X démontrent des améliorations significatives en matière de vitesse et de bande passante.
Ce nouveau serveur prend en charge les extensions X suivantes :
Le nouveau serveur X prend également en charge d'autres polices X. La police Speedo n'est plus disponible.
Les objets d'application X disposent d'un nouvel attribut de l'extension de sécurité X (--securityextension) qui active l'extension de sécurité X pour une application. Activez cet attribut pour exécuter une application X sur un serveur d'application non sécurisé. Ainsi, vous pourrez exécuter l'application en mode non sécurisé. Ce mode limite les opérations de l'application X dans le serveur X et protège l'affichage. La sécurité X ne fonctionne qu'avec les versions de SSH assurant la prise en charge de l'option -Y. Pour OpenSSH, il s'agit de la version 3.8 et des versions ultérieures.
Le client SGD prend maintenant en charge l'impression de PDF sur les périphériques client UNIX, Linux et Mac OS X. Sur ces clients, le document à imprimer s'affiche dans un visionneur PDF à partir duquel il peut être enregistré et/ou imprimé sur une imprimante PDF SGD. Par défaut, SGD assure la prise en charge des visionneurs PDF suivants.
Plate-forme client | Visionneur PDF par défaut |
---|---|
SE Solaris sur plate-forme SPARC | Adobe Reader (acroread) |
SE Solaris sur plate-forme x86 | Visionneur de PDF GNOME (gpdf) |
Linux | Visionneur de PDF GNOME (gpdf) |
Mac OS X | Preview.app |
Pour utiliser un visionneur par défaut, l'application doit résider dans le CHEMIN utilisateur.
Pour utiliser un autre visionneur PDF, spécifiez le chemin complet de ce dernier dans le profil utilisé par le client SGD.
L'impression de PDF sur les périphériques client Microsoft Windows est inchangée.
Le mappage du disque client (CDM, Client Drive Mapping) est maintenant disponible sous UNIX et pour les applications Linux.
Une fois le mappage du disque client activé dans la console d'administration, il est activé pour les applications UNIX, Linux et Windows.
Les attributs de gestion des droits d'accès aux disques client des organisations, unités d'organisation ou objets de profil utilisateur ne s'appliquent qu'aux périphériques client Windows, qu'ils soient associés à Windows, à la plate-forme UNIX ou à des applications Linux.
Pour gérer les disques mappés pour les périphériques client de la plate-forme UNIX, de Linux ou de Mac OS X il suffit de vérifier les entrées du fichier de configuration de l'utilisateur $HOME/.tarantella/native-cdm-config.
Les conditions suivantes sont nécessaires pour rendre disponible le mappage de disque client aux applications UNIX et Linux :
Le module d'enrichissement SGD doit être installé et en cours d'exécution sur le serveur d'application UNIX ou Linux. Actuellement, le service de mappage du disque client doit être démarré manuellement à l'aide de la commande /opt/tta_tem/bin/tem startcdm.
Un serveur NFS (Network File System) doit être installé et en cours d'exécution sur le serveur d'application. Le serveur NFS doit exporter un répertoire nécessaire au mappage du disque client. Par défaut, il s'agit du répertoire /smb. Il est possible de spécifier un répertoire différent dans le fichier /opt/tta_tem/etc/client.prf. L'entrée de ce fichier doit être au format NFS_server/mount/mountpoint.
Le service de mappage du disque client de SGD doit être démarré dans la baie à l'aide de la commande tarantella start cdm.
Les droits d'accès aux disques client doivent être configurés à l'aide de la console d'administration (pour les clients Windows) et dans le fichier de configuration de l'utilisateur (clients UNIX, Linux et Mac OS X).
Lorsque le mappage du disque client est activé, les disques ou systèmes de fichiers clients de l'utilisateur sont accessibles par défaut dans son répertoire personnel, My SGD drives. Le répertoire My SGD drives est un lien symbolique vers le répertoire NFS partagé nécessaire au mappage du disque client.
Les utilisateurs qui exécutent des applications Windows sur Windows Terminal Server ont maintenant accès aux ports série sur leur périphérique client.
Pour accéder à un port série, les conditions suivantes doivent être remplies :
Le mappage de port COM doit être activé dans la configuration de services de terminal (option par défaut).
Le mappage de port série doit être activé dans le panneau Paramètres globaux ⇒ Périphérique client de la console d'administration (option par défaut).
L'accès aux ports série doit être activé pour les organisations, unités d'organisation ou objets de profil utilisateur. Les droits d'accès doivent être transférables.
Les clients SGD doivent être en mesure d'énumérer les ports série des périphériques client. Pour de plus amples informations sur le mappage des ports série, reportez-vous au Guide d'administration de Sun Secure Global Desktop 4.4.
Les utilisateurs doivent avoir un accès en lecture et en écriture sur les ports série auxquels ils veulent accéder.
Le mappage de port série est accessible au client SGD qui s'exécute sur les périphériques client Windows, plate-forme Solaris et Linux.
Le Bureau à distance de Microsoft Windows XP Professionnel permet d'accéder à un ordinateur distant à l'aide du protocole Microsoft RDP (Remote Desktop Protocol). Vous pouvez maintenant utiliser cette fonction avec SGD afin de permettre, par exemple, à un utilisateur d'accéder à distance à son PC lorsqu'il est en déplacement. Seules les sessions de bureau Windows complètes sont prises en charge.
Vous pouvez également installer le module d'enrichissement SGD sur les périphériques client Microsoft Windows XP Professionnel pour la prise en charge du mappage du disque client. La fonction avancée d'équilibrage de charge et les fenêtres transparentes ne sont pas prises en charge.
Le client des services de terminal SGD (ttatsc) assure désormais la prise en charge d'une option supplémentaire, -console, qui permet la connexion à la session de console avec les services de terminal de Windows Server 2003.
Cette option peut être définie dans l'attribut d'arguments de protocole (--protoargs) de l'objet d'application Windows.
La connexion initiale entre un client SGD et un serveur SGD est sécurisée avec SSL. Toutefois, une fois l'utilisateur connecté, la connexion redevient standard. Si vous souhaitez utiliser SSL de façon permanente pour les connexions à SGD, vous devez activer les services de sécurité SGD.
Les connexions SSL entre les clients SGD et SGD utilisent le port TCP 5307. L'ouverture de ce port pourrait devoir s'effectuer dans votre pare-feu afin de permettre aux clients SGD de se connecter.
SGD dispose d'une fonction de routage des baies permettant de configurer les serveurs proxy SOCKS côté serveur. Les commandes suivantes permettent de configurer le routage des baies :
$ tarantella config edit \ ‐‐--tarantella-config-array-netservice-proxy-routes route... |
Si un routage inclut l'option :ssl, vous devrez configurer le démon SGD SSL pour qu'il accepte les connexions non chiffrées à l'aide de l'attribut Prise en charge de l'accélérateur SSL situé dans l'onglet Paramètres de serveur Secure Global Desktop ⇒ Sécurité de la console d'administration ou à l'aide de la commande suivante :
$ tarantella config edit --security-acceptplaintext 1 |
Avec l'automatisation du démarrage et de la connexion du client SGD, il est essentiel de pouvoir vérifier la fiabilité des connexions. Cette version permet désormais à l'utilisateur d'autoriser explicitement la connexion à SGD.
Lors de sa première connexion à SGD, l'utilisateur reçoit un message de connexion initiale non autorisée qui l'invite à confirmer la connexion au serveur SGD. Ce message affiche le nom d'hôte et l'empreinte du certificat de sécurité du serveur auquel il se connecte. Il est important de vérifier ces informations avant de cliquer sur Oui. Si l'utilisateur accepte la connexion, le message ne s'affichera plus qu'en cas de problème.
Pour assurer la fiabilité des connexions utilisateur aux serveurs SGD, les administrateurs doivent :
fournir aux utilisateurs une liste des noms d'hôtes et empreintes des serveurs de confiance (liste obtenue à l'aide de la commande tarantella security fingerprint sur chaque membre de la baie) ;
expliquer aux utilisateurs les implications de sécurité liées à la connexion au serveur.
Sur une nouvelle installation, chaque serveur SGD possède son propre certificat de sécurité autosigné. Les administrateurs doivent installer un certificat X.509 valide pour chaque serveur SGD.
Les administrateurs SGD peuvent désormais contrôler les opérations de copier-coller dans les sessions d'application Windows et X. Les copier-coller peuvent être configurés de la manière suivante :
La fonction copier-coller peut être activée ou désactivée pour l'ensemble de SGD.
La fonction copier-coller peut être activée ou désactivée pour des organisations, des unités d'organisation ou des objets de profil utilisateur. L'administrateur peut ainsi définir les utilisateurs autorisés à copier-coller.
Un niveau de sécurité peut être assigné au presse-papiers des applications. Les données ne peuvent être copiées que si le presse-papiers de l'application cible (l'application recevant les données) possède un niveau de sécurité identique ou supérieur à celui de l'application source. L'administrateur peut ainsi sécuriser les données accessibles à travers certaines applications.
Vous pouvez assigner un niveau de sécurité au presse-papiers du client SGD. Les données ne peuvent être copiées sur des applications du périphérique client que si le presse-papiers du client SGD possède un niveau de sécurité identique ou supérieur à celui de l'application source. L'administrateur peut ainsi sécuriser le flux de données à l'extérieur de SGD.
Si un utilisateur tente une opération de copier-coller non autorisée (en raison de niveaux de sécurité différents, par exemple), le message suivant est collé à la place des données copiées :
Logiciel Sun SGD : Copied data not available to this application (Données copiées non disponibles pour cette application)
De même que l'on peut utiliser RSA SecurID pour authentifier les utilisateurs de SGD, il est possible d'utiliser SecurID pour authentifier le serveur d'application lors du lancement d'applications X et à traitement de caractères.
Avant d'utiliser l'authentification SecurID sur SGD, assurez-vous que les utilisateurs peuvent se connecter au serveur d'application à l'aide de SecurID. Après cette vérification, configurez l'application de sorte qu'elle utilise le script de connexion securid.exp.
La version 4.3 propose des interfaces utilisateur localisées en :
Les utilisateurs peuvent choisir la langue du bureau Web en visitant une page différente ou en sélectionnant une langue sur la page de bienvenue du serveur SGD (http://exemple.serveur.com, où exemple.serveur.com correspond au nom d'un serveur SGD). Le client SGD peut également être démarré dans la langue de votre choix.
La console d'administration est localisée dans les langues de l'interface utilisateur.
Le tableau suivant répertorie les traductions de la documentation SGD disponibles.
Langue | Notes de version | Guide d'installation | Guide d'administration | Manuel de référence | Guide de l'utilisateur |
---|---|---|---|---|---|
Français | Oui | Oui | Non | Non | Oui |
Japonais | Oui | Oui | Oui | Oui | Oui |
Coréen | Oui | Oui | Non | Non | Oui |
Chinois simplifié | Oui | Oui | Non | Non | Oui |
Chinois traditionnel | Oui | Oui | Non | Non | Oui |
Les scripts Expect servant au démarrage des applications sur les serveurs d'application ont également été améliorés afin d'assurer la prise en charge des invites système en plusieurs langues. Par défaut, ces langues sont celles prises en charge par SGD.
Pour permettre aux scripts Expect de fonctionner avec des invites système en plusieurs langues, les objets de serveur d'application disposent d'un nouvel attribut de demande d'environnement linguistique (--hostlocale) qui permet de spécifier la version localisée du serveur d'application.
Cette section décrit les modifications apportées par rapport au logiciel Sun Secure Global Desktop version 4.31.
Pour cette version, les modifications suivantes ont été apportées aux plates-formes d'installation prises en charge pour SGD :
SE Solaris 10 Trusted Extensions sur les plates-formes SPARC et x86 est dorénavant pris en charge. Reportez-vous à la rubrique Prise en charge de SE Solaris 10 Trusted Extensions pour plus d'informations.
Fedora Linux 7 (Intel x86 32 bits) est dorénavant pris en charge. La plate-forme Fedora Core 6 n'est plus pris en charge.
Reportez-vous à la rubrique Chapitre 1 pour plus d'informations sur les plates-formes prises en charge dans cette version.
SGD version 4.31 était la dernière version contenant les clients Java, les clients natifs SGD et le bureau Web classique. La version 4.40 ne contient pas ces clients.
Par conséquent, pour cette version de SGD, vous ne pouvez plus configurer les applications pour qu'elles s'affichent dans une fenêtre de navigateur Web. Les options webtop et newbrowser de l'attribut Type de fenêtre (--displayusing) ont été supprimées.
Par mesure de sécurité pour éviter les attaques par saturation, la séquence des événements de connexion à SGD a été modifiée de la manière suivante :
Dans SGD version 4.31, le client SGD démarrait avant l'affichage de l'écran de connexion.
Dans SGD version 4.40, le client SGD démarre uniquement après l'authentification réussie de l'utilisateur sur l'écran de connexion.
Une icône sur la barre des tâches du bureau indique le démarrage du client SGD. Reportez-vous au Guide d'installation de Sun Secure Global Desktop 4.4 pour plus de détails sur la connexion à SGD.
À présent, vous ne pouvez plus refuser une connexion à SGD en fonction de l'adresse IP du client.
Dans les versions précédentes, l'attribut --tarantella-config-ssldaemon-certificates servait à associer un certificat X.509 avec un nom DNS externe pour un serveur SGD.
Cet attribut n'est plus pris en charge. Dans cette version, vous pouvez spécifier des noms DNS externes en tant que noms d'objet alternatifs lors de la génération d'une CSR.
Reportez-vous à la rubrique Noms d'objet alternatifs pour les certificats de serveur pour plus d'informations.
Les modifications suivantes ont été apportées aux services Web de cette version :
Dans la version 4.31, les méthodes startSession et authenticateSession servaient à authentifier une session utilisateur.
Dans la version 4.40, la création et l'authentification ont été fusionnées en une seule méthode : authenticate.
Les méthodes startSession et authenticateSession ne sont plus disponibles dans la version 4.40.
La version 4.31 contenait des méthodes surchargées. Celles-ci se distinguaient par la quantité et le type de leurs paramètres. Toutes ces méthodes surchargées ont été renommées dans la version 4.40. De plus, les paramètres obligatoires pour la méthode setSessionIdentity ont été modifiés dans la version 4.40.
Les nouveaux noms de méthode dans cette version sont répertoriés dans le tableau suivant.
Nom de l'interface | Nom de la méthode dans la version 4.31 | Nom de la méthode dans la version 4.40 |
---|---|---|
ITarantellaDatastore | modify(String, String, String[]) | modifyReplace (String, String, String[]) |
ITarantellaEvent | adminSendClientSideMessage (String, String, String, String, String) | adminBroadcastClientSideMessage (String, String, String, String, String) |
ITarantellaExternalAuth | setSessionIdentity (String, String) | setSessionIdentity (String, String, String) |
ITarantellaPrint | printJobs(String) | printAllJobs(String) |
ITarantellaWebtopSession | authenticateSession(String, String, String) | authenticate(String, String, String, String) |
ITarantellaWebtopSession | authenticateSession(String, String, String, Item[], Item[]) | authenticateExt(String, String, String, String, Item[], Item[]) |
ITarantellaWebtopSession | setTCCConfiguration (String, String, String, String, String, Item[]) | setTCCConfigurationOverrides (String, String, String, String, String, Item[]) |
ITarantellaWebtopSession | startSession(*) | Aucun équivalent |
Le tableau suivant récapitule les nouvelles opérations de service Web.
Le format de codage de messages SOAP utilisé pour les services Web SGD a été remplacé par le format RPC/Codage en documents/littéraux.
Pour afficher la liste des services Web SGD, allez à l'adresse http://exemple.serveur.com/axis/services, où exemple.serveur.com correspond au nom d'un serveur SGD. Cliquez sur le lien wsdl pour afficher la liste WSDL (Web Services Description Language, langage de description de services Web) correspondant à un service Web SGD.
Les listes WSDL pour les versions RPC/Codage de services Web sont toujours incluses sur cette page. N'utilisez pas les versions RPC/Codage pour le développement de vos propres applications. Ces versions de services Web seront abandonnées dans les prochaines versions.
L'opération adminLookupSession renvoie à présent des informations sur les périphériques. Cette opération permet de soumettre des requêtes sur les attributs de données de périphérique --scottarawdevicedata et --scottadeviceaccessibledata.
Les informations sur les périphériques renvoyées peuvent servir d'outil de diagnostic.
Un nouveau paramètre pour la commande tarantella cache permet d'actualiser les paramètres de configuration de Kerberos pour un serveur SGD.
Cette nouvelle option, krb5config, s'utilise de la manière suivante :
$ tarantella cache --flush krb5config |
Ce paramètre permet de mettre à jour la configuration de Kerberos pour un serveur SGD sans avoir à le redémarrer. Cette fonctionnalité est uniquement disponible pour l'authentification Active Directory.
Une nouvelle commande est disponible pour les utilisateurs du module d'enrichissement SGD.
La commande tem status fournit des informations d'état sur l'équilibrage de charge, l'audio UNIX et les services de mappage du disque client pour la baie SGD. Cette commande répertorie les modules installés et indique s'ils sont en cours d'exécution ou non.
Vous pouvez démarrer le client SGD à partir de la ligne de commande via la commande tcc sur les plates-formes client Microsoft Windows ou la commande ttatcc sur les plates-formes client UNIX, Linux ou Mac OS X.
Dans cette version, lorsque vous démarrez le client SGD à partir de la ligne de commande ou en mode intégré, le client SGD suppose par défaut que Java n'est pas activé sur le périphérique client. Un nouvel argument -use-java pour les commandes tcc et ttatcc configure le client SGD afin qu'il utilise Java.
Dans les versions précédentes, le client SGD considérait par défaut que Java était activé. L'argument -no-java des commandes tcc et ttatcc permettait d'ignorer ce comportement. Cet argument a été abandonné dans cette version.
Les arguments disponibles pour les commandes tcc et ttatcc sont décrits dans le Guide d'administration de Sun Secure Global Desktop 4.4.
Le client SGD consigne à présent les informations sur les périphériques client. Les données d'accès aux périphériques et les messages d'erreur sont consignés pour l'impression, le port série, le mappage du disque client et les périphériques audio et à cartes à puce.
Les informations sur les périphériques client sont inscrites dans le fichier journal client SGD et sont affichées sur la page Diagnostics détaillés du bureau Web.
Plusieurs attributs ont été renommés pour leur donner des noms plus courts. Cela évite les éventuelles erreurs lors de la saisie du nom de ces attributs dans la ligne de commande.Les attributs modifiés sont récapitulés dans le tableau suivant.
Nom de l'attribut dans la version 4.31 | Nom de l'attribut dans la version 4.40 |
---|---|
--tarantella-config-login-thirdparty-searchens | --login-thirdparty-ens |
--tarantella-config-login-thirdparty-allownonens | --login-thirdparty-nonens |
--tarantella-config-ldap-thirdpartyldapcandidate-useens | --login-ldap-thirdparty-ens |
--tarantella-config-ldap-thirdpartyldapcandidate-useprofile | --login-ldap-thirdparty-profile |
--tarantella-config-xpeconfig-timezonemapfile | --xpe-tzmapfile |
L'attribut Domaine Windows NT a été renommé Nom de domaine. Cet attribut spécifie le domaine à utiliser au cours de la procédure d'authentification du serveur d'application.
Les noms des imprimantes PDF SGD ont été modifiés, comme indiqué dans le tableau suivant.
Nom de l'imprimante dans la version 4.31 | Nom de l'imprimante dans la version 4.4 |
---|---|
PDF universel | Imprimante PDF universel |
Imprimante de fichier PDF locale | Visionneur PDF universel |
Pour les objets d'application dont le paramètre Type de fenêtre est défini sur Fenêtre indépendante, une boîte de dialogue d'avertissement s'affiche lorsque la fenêtre de l'application est fermée. La boîte de dialogue vous permet de confirmer ou d'annuler la fermeture de la session d'application.
Vous ne pouvez plus configurer les serveurs proxy SOCKS via le profil client SGD.
Vous pouvez toujours configurer les serveurs proxy SOCKS via la fonctionnalité de routage des baies. Exécutez la commande ci-dessous :
$ tarantella config edit \ --tarantella-config-array-netservice-proxy-routes \ "192.168.10.*:CTSOCKS:taurus.indigo‐insurance.com:8080" |
Avec cette configuration, les clients dont les adresses IP commencent par 192.168.10 se connectent à l'aide du serveur proxy SOCKS taurus.indigo-insurance.com sur le port TCP 8080.
Le gestionnaire d'objets, le gestionnaire de baies, l'assistant de configuration et le gestionnaire de sessions, auparavant utilisés en tant qu'outils d'administration, ne s'affichent plus sur le bureau Web de l'administrateur. Ils ont été remplacés par un outil d'administration unique basée sur navigateur appelé la console d'administration. Reportez-vous à la rubrique Console d'administration SGD pour plus d'informations.
L'assistant de configuration reste inclus dans la distribution SGD en tant qu'exemple d'application Web. Pour afficher l'assistant de configuration, rendez-vous à l'adresse http://exemple.serveur.com/sgd/admin/configmgr/index.jsp, où exemple.serveur.com correspond au nom d'un serveur SGD.
Le gestionnaire de sessions est toujours inclus dans la distribution SGD en tant qu'exemple d'application Web. Pour afficher le gestionnaire de sessions, allez à l'adresse http://exemple.serveur.com/sgd/admin/sessmgr/index.jsp, où exemple.serveur.com correspond au nom d'un serveur SGD.
Les scripts de connexion dans le répertoire /rép-install/var/serverresources/ expect ont été normalisés. Certains scripts ont été renommés, d'autres ont été fusionnés.
Si vous utilisez SecurID pour l'authentification du serveur d'application, les objets utilisent le script securid.exp plutôt que le script securid/unix.exp. Pour une compatibilité ascendante, un lien existe maintenant entre securid/unix.exp et le nouveau script securid.exp.
Une méthode d'entrée (IM, Input Method) est un composant de programme ou de système d'exploitation qui permet de saisir des caractères et des symboles absents du clavier. Pour les plates-formes Microsoft Windows, une méthode d'entrée s'appelle un éditeur de méthode de saisie (IME, Input Method Editor).
Lors de l'exécution d'une application, SGD active une méthode d'entrée lorsque les variables d'environnement TTA_PreferredLocale, TTA_HostLocale ou LANG (redéfinition de l'environnement de l'application) sont définies sur un environnement linguistique qui en requiert une. Ces environnements linguistiques sont contrôlés par la variable IM_localeList définie dans le script de connexion vars.exp.Une méthode d'entrée est activée par défaut pour les environnements linguistiques japonais, coréen et chinois. Vous pouvez en activer une dans d'autres environnements linguistiques en modifiant la variable vars.exp et en ajoutant l'environnement concerné à la variable IM_localeList.
Cette section décrit les modifications réalisées par rapport au logiciel Sun Secure Global Desktop 4.30.
Dans la version 4.31, vous pouvez utiliser l'authentification SecurID lorsque SGD est installé sur les plates-formes Solaris x86.
Dans la version 4.30, il est possible de se connecter uniquement à un serveur SGD lorsque le client SGD est en mode intégré. Dans la version 4.31, il est possible d'utiliser le mode intégré avec plusieurs serveurs SGD. Un lien de connexion est disponible dans le menu de démarrage du bureau pour chaque serveur SGD.
SGD dispose d'une fonction de routage des baies permettant de configurer les serveurs proxy SOCKS côté serveur. Les commandes suivantes permettent de configurer le routage des baies :
$ tarantella config edit \ --tarantella-config-array-netservice-proxy-routes route... |
Les routages de baie ont été améliorés afin de permettre la configuration d'un type de connexion directe. Utilisez CTDIRECT en tant que type de connexion pour spécifier les clients que vous pourrez connecter sans utiliser un serveur proxy.
Vous trouverez ci-après un exemple de configuration de routage de baie :
$ tarantella config edit \ --tarantella-config-array-netservice-proxy-routes \ "192.168.5.*:CTDIRECT:" \ "192.168.10.*:CTSOCKS:taurus.indigo‐insurance.com:8080" |
Cette configuration permet aux clients dont l'adresse IP commence par 192.168.5 d'avoir une connexion directe. Les clients dont les adresses IP commencent par 192.168.10 se connectent à l'aide du serveur proxy SOCKS taurus.indigo-insurance.com sur le port TCP 8080.
Dans la version 4.31, les scripts de démarrage assurant le démarrage et l'interruption des services SGD lors du redémarrage d'un serveur SGD ont été renommés et restructurés. Les scripts *Tarantella et *TarantellaWebserver ont été remplacés par un script unique nommé *sun.com‐sgd‐base. Le script *tem pour le module d'enrichissement SGD se nomme désormais *sun.com‐sgd‐em.
Le message de connexion initiale non autorisée qui s'affiche lorsque les utilisateurs se connectent initialement à un serveur SGD a été amélioré. Les utilisateurs peuvent désormais visualiser le certificat de sécurité du serveur à partir de ce message.
La touche Windows est désormais désactivée par défaut dans les sessions de services de terminal Windows SGD. La touche Windows est prise en compte uniquement dans les sessions locales Windows. La combinaison de touches Alt+ORIGINE permet d'afficher le menu de démarrage Windows dans une session de services de terminal SGD.
Le client des services de terminal SGD (ttatsc) prend désormais en charge une option supplémentaire, -windowskey on|off, qui permet d'activer la prise en charge de la touche Windows. Cette option peut être définie dans l'attribut d'arguments de protocole (--protoargs) de l'objet d'application Windows.
Cette section décrit les modifications réalisées par rapport au logiciel Sun Secure Global Desktop version 4.20.
La version 4.3 propose un package d'installation unique pour SGD. Il permet d'installer simultanément tous les packages qui devaient auparavant être installés séparément (notamment les packages de polices). Les clés de licence installées dans la baie contrôlent les composants SGD qui peuvent être utilisés.
La connexion initiale à SGD étant désormais sécurisée en permanence, cela signifie que le démon SGD SSL est actif en permanence, même si les services de sécurité ne le sont pas.
Dans les versions précédentes, la configuration du client SGD sur les périphériques client UNIX, Linux et Mac OS X s'effectuait à l'aide d'un fichier de préférences utilisateur. Avec l'introduction des profils, ce fichier n'est plus utilisé.
Dans les versions précédentes, l'attribut de fermeture de fenêtre (--windowclose) n'était accessible qu'aux applications X dont l'affichage dépendait du système de gestion de fenêtres client. L'utilisation de cet attribut a été étendue aux applications X, Windows et à traitement de caractères, configurées pour s'afficher dans une fenêtre indépendante.
Dès lors, l'utilisateur peut arrêter ou suspendre la session de l'application en fermant une fenêtre indépendante. Par défaut, la fermeture d'une fenêtre ferme la session.
SGD prend désormais en charge les PAM (Pluggable Authentication Modules, modules d'authentification enfichables) pour l'authentification des utilisateurs UNIX. Cette modification se répercute sur les mécanismes d'authentification UNIX :
utilisation du profil utilisateur par défaut (utilisateur UNIX) ;
recherche de l'ID du groupe Unix dans le référentiel local (groupe UNIX).
SGD utilise les PAM pour l'authentification des utilisateurs ainsi que pour les opérations de compte et de mot de passe.
Lorsque vous installez SGD sur une plate-forme Linux, le programme d'installation crée automatiquement des entrées de configuration PAM pour SGD en copiant la configuration actuelle pour le programme passwd et en créant le fichier /etc/pam.d/tarantella. Sur les plates-formes SE Solaris, vous pouvez, si nécessaire, ajouter une nouvelle entrée pour SGD (tarantella) dans le fichier /etc/pam.conf.
L'utilisation de PAM offre aux administrateurs SGD davantage de flexibilité et un contrôle accru sur l'authentification des utilisateurs UNIX en leur permettant, par exemple, d'ajouter des tests de connexion, des limites de compte ou des contrôles de mot de passe.
La version actuelle propose une nouvelle prise en charge de l'impression de fichiers PDF sur les périphériques client UNIX, Linux et Mac OS X. De ce fait, l'attribut de la boîte de dialogue d'affichage de l'impression Adobe Reader (--pdfprompt) a été supprimé.
Dorénavant, lorsque l'utilisateur d'un client Windows lance une impression sur l'imprimante de type PDF universel, le travail d'impression est automatiquement envoyé à l'imprimante par défaut du client. Pour envoyer le travail vers une autre imprimante, sélectionnez l'imprimante Visionneur PDF universel.
Lors d'une authentification Active Directory, l'option Certificats client est disponible dans l'assistant d'authentification. Elle évite à l'utilisateur de spécifier un nom d'utilisateur et un mot de passe d'utilisateur privilégié, à condition qu'un certificat client ait été créé et installé pour SGD et qu'Active Directory utilise les certificats client.
Le mot de passe utilisé pour le magasin de certificats de SGD (/rép‐install/var/info/certs/sslkeystore) n'utilise plus le code permanent 123456. Chaque magasin dispose à présent d'un mot de passe aléatoire stocké dans /rép‐install/var/info/key. Utilisez ce mot de passe avec les options -storepass et -keypass lorsque vous utilisez keytool.
Les modifications suivantes ont été apportées au contrat de licence de la version 4.2 :
L'activation des clés de licence n'est plus nécessaire pour activer une baie.
L'octroi d'une licence de manière nominative n'est plus disponible.
Les clés de licence pour la maintenance et le droit de mise à niveau n'existent plus.
La mise à niveau à partir d'une version antérieure entraîne automatiquement la conversion des clés de licence existantes et la suppression des clés de licence obsolètes.
Depuis la version 4.1, SGD ne prend plus en charge les méthodes de connexion rlogin et rcmd pour le démarrage des applications. Pour mettre à niveau à partir d'une version antérieure, vous devez modifier la méthode de connexion de toutes les applications qui utilisent ces méthodes.
Depuis la version 4.1, SGD utilise un attribut différent pour le paramétrage du nombre maximal de sessions utilisateur simultanées (--tuning-maxconnections). La configuration par défaut de cet attribut s'applique au logiciel mis à niveau à partir d'une version antérieure.
Depuis la version 4.0, SGD utilise un émulateur différent pour les applications mainframe (3270). Les objets des applications X 3270 et de celles à traitement de caractères 3270 ne sont plus disponibles et ont été remplacés par un seul objet d'application 3270. Le nouvel objet d'application 3270 ayant plusieurs attributs, il est possible de mettre à niveau les objets d'application 3270 existants. La mise à niveau à partir d'une version antérieure entraîne la suppression automatique des applications X 3270 et à traitement de caractères 3270. Vous devez donc les reconfigurer.
Copyright © 2007, Sun Microsystems, Inc. Tous droits réservés