Ce chapitre répertorie les nouvelles fonctions de la version Solaris 10 8/07.
Les améliorations et fonctionnalités d'administration système suivantes ont été ajoutées à la version Solaris 10 8/07.
Pour vous faire bénéficier de nouvelles fonctionnalités, le commutateur du service de noms (nss) et le démon de mise en cache correspondant (nscd(1M)) ont fait l'objet d'améliorations. Ces améliorations sont les suivantes :
Meilleure mise en cache dans nscd(1M) et meilleure gestion des connexions au sein de la structure mise à jour.
Les recherches font l'objet d'un contrôle d'accès au niveau du service de noms pour chaque utilisateur. La structure de commutation mise à jour permet de prendre en charge ce type de recherche à l'aide de SASL/GSS/ Kerberos sous une forme compatible avec le modèle d'authentification utilisé dans Microsoft Active Directory.
Une structure a été prévue pour la future intégration des interfaces putXbyY.
Pour plus d'informations sur la recherche par utilisateur, reportez-vous au System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) .
L'option -Y de la commande iostat fournit de nouvelles informations relatives aux performances pour les machines utilisant le multiacheminent E/S Solaris.
Pour de plus amples informations, consultez la page de manuel iostat(1M).
À partir de cette version, pour enregistrer le SE Solaris, vous avez le choix entre les méthodes ci-dessous :
Basic Registration 1.1 : choisissez cette méthode si vous souhaitez utiliser l'architecture de déploiement hébergée de Sun Connection ou Update Manager.
Enregistrement Solaris : choisissez cette méthode si vous souhaitez utiliser Sun Connection pour effectuer la maintenance d'un inventaire des systèmes que vous avez enregistrés.
La fonctionnalité d'administration système Basic Registration 1.1 a été introduite dans la version Solaris 10 6/06. Elle permet de créer un profil d'enregistrement et un ID afin d'automatiser les enregistrements du logiciel Solaris 10 pour Update Manager. Update Manager est le client de mise à jour système unique utilisé par Sun Connection. Auparavant, Sun Connection était appelé Sun Update Connection System Edition. L'assistant Basic Registration s'affiche à l'initialisation du système. Pour de plus amples informations sur la fonctionnalité Basic Registration 1.1, reportez-vous à la section Basic Registration 1.1. Pour de plus amples informations sur le portefeuille de produits de Sun Connection et sur l'enregistrement à l'aide de l'assistant, reportez-vous au centre d'informations dédié à Sun Connection, à la page http://www.sun.com/bigadmin/hubs/connection/.
L'enregistrement Solaris permet d'enregistrer une ou plusieurs instances de votre logiciel Solaris simultanément en spécifiant un nom d'utilisateur Sun Online Account et son mot de passe. Pour vous enregistrer, accédez au site Web https://sunconnection.sun.com.
Une balise de service Sun est un identificateur de produit qui permet de la détection automatique des systèmes, logiciels et services Sun afin de les enregistrer facilement et rapidement. Les balises de service identifient de manière unique le matériel marqué et permettent le partage des informations relatives au matériel sur un réseau local dans un format XML standard.
Les balises de service sont activées en tant qu'éléments de l'utilitaire de gestion des services Solaris (SMF, Service Management Facility) et du profil SMF generic_open.xml. Si vous sélectionnez le profil SMF generic_limited_net.xml, les balises de service ne sont pas activées.
Pour de plus amples informations sur SMF, consultez le System Administration Guide: Basic Administration . Pour de plus amples informations sur les balises de service, les types d'informations collectées et l'enregistrement automatique, reportez-vous à Sun Connection sur BigAdmin, à l'adresse http://www.sun.com/bigadmin/hubs/connection/tasks/register.jsp.
Cette fonction offre un mécanisme permettant d'envoyer des commandes SCSI à une unité logique MPxIO en suivant le cheminement spécifié jusqu'à l'unité logique (LU). Pour vous permettre de bénéficier de cette fonctionnalité, une nouvelle commande IOCTL, MP_SEND_SCSI_CMD, est ajoutée et référencée via l'interface scsi_vhci IOCTL existante. Une extension à la bibliothèque de gestion de multiacheminement (MP-API) a été prévue pour donner accès à cette nouvelle commande IOCTL. Les administrateurs ont ainsi la possibilité d'exécuter des commandes de diagnostic depuis un chemin donné.
raidctl est un utilitaire de configuration RAID fonctionnant avec plusieurs contrôleurs RAID. La fonction raidctl contient des informations plus détaillées sur les composants RAID, et notamment sur le contrôleur, le volume et les disques physiques. L'utilitaire raidctl permet d'effectuer un suivi plus précis du système RAID et de simplifier l'apprentissage de divers contrôleurs RAID.
Pour plus d'informations, consultez les références suivantes :
Page de manuel raidctl(1M)
http://www.lsi.com/storage_home/products_home/host_bus_adapters/index.html
La commande zoneadm(1M) a été modifiée afin de faire appel à un programme externe pour vérifier la validité d'une opération zoneadm donnée dans une zone marquée. Les vérifications sont effectuées avant l'exécution de la sous-commande zoneadm indiquée. Il est impératif, cependant, que le fichier de configuration de la marque, /usr/lib/brand/<brand_name>/config.xml, désigne le gestionnaire externe spécifique à la marque pour la commande zoneadm(1M). Pour ce faire, il convient d'utiliser la balise <verify_adm>.
Pour introduire un nouveau type de zone marquée et répertorier les gestionnaires spécifiques à la marque pour la sous-commande zoneadm(1M), ajoutez la ligne suivante au fichier config.xml de la marque :
<verify_adm><absolute path to external program> %z %* %*</verify_adm> |
Dans cette ligne %z correspond au nom de la zone, la première %* correspond à la sous-commande zoneadm et le second %* correspond aux arguments de la sous-commande.
Cette fonction est pratique lorsqu'une zone marquée donnée risque de ne pas prendre en charge toutes les opérations zoneadm(1M) possibles. Les gestionnaires spécifiques à la marque constituent un moyen original de faire échouer les commandes zoneadm non compatibles.
Assurez-vous que le gestionnaire indiqué reconnaît toutes les sous-commandes zoneadm (1M).
La fonction de gestion des défaillances assure la prise en charge du traitement des erreurs et des pannes pour les CPU et la mémoire dans les systèmes fonctionnant avec des processeurs AMD (TM) Opteron et Athlon 64 Rev F. Ces processeurs sont utilisés dans les produits M2 de Sun (Sun Fire X2200 M2 et Ultra 20 M2, par exemple). Les versions antérieures à Solaris 10 8/07 prenaient en charge la gestion des défaillances pour les processeurs Opteron et Athlon 64 révisions B à E.
La prise en charge de la gestion des défaillances est activée par défaut. Le service de gestion des défaillances détecte les erreurs de CPU et de mémoire qu'il est possible de résoudre. La télémétrie correspondante est analysée par des moteurs de diagnostic et les erreurs et défaillances sont corrigées chaque fois que cela est possible. Lorsque le système ne parvient pas à corriger les problèmes, la télémétrie étendue offre une assistance de premier choix à l'administrateur système.
Pour plus d'informations, visitez le site Web http://www.opensolaris.org/os/community/fm/.
Dans la présente version, le système d'exploitation Solaris comprend un ensemble de fonctionnalités d'autorétablissement prédictif pour capturer et diagnostiquer automatiquement des erreurs matérielles détectées sur le système.
Le gestionnaire d'erreurs Solaris diagnostique automatiquement les pannes de matériel x64. Les messages de diagnostic sont consignés par le démon fmd.
Pour plus d'informations sur la gestion des erreurs dans Solaris, consultez les références suivantes :
Page de manuel fmd(1M)
L'utilitaire stmsboot est transposé aux systèmes x86 dans cette version. stmsboot est un utilitaire prévu spécialement pour activer ou désactiver MPxIO pour les périphériques Fibre Channel. stmsboot existe déjà sur les systèmes SPARC.
Les utilisateurs peuvent tirer parti de cet utilitaire pour activer ou désactiver MPxIO de façon automatique. Auparavant, ils devaient le faire manuellement, ce qui était relativement complexe, notamment dans le cas d'une initialisation système SAN.
Pour plus d'informations, consultez les références suivantes :
Page de manuel stmsboot(1M)
Section Enabling or Disabling Multipathing on x86 Based Systems du Solaris Fibre Channel Storage Configuration and Multipathing Support Guide, disponible à l'adresse suivante : http://docs.sun.com.
Les commandes simultanées READ/WRITE FPDMA QUEUED sont désormais prises en charge. Le gain de performance est considérable pour les opérations d'E/S ayant recours au pilote Solaris marvell88sx dans des conditions de travail spécifiques. Les autres charges de travail en profitent également dans une moindre mesure. On constate également une amélioration significative des performances lors du traitement de nombreuses charges de travail pour les unités compatibles avec cette portion facultative de la spécification SATA.
La mise en file d'attente étiquetée permet aux disques SATA d'optimiser le mouvement des têtes et les performances.
Les améliorations et fonctionnalités d'installation suivantes ont été ajoutées à la version Solaris 10 8/07.
Il est désormais possible de définir le domaine NFS version 4 au cours de l'installation du SE Solaris. Dans les versions antérieures à Solaris 10 8/07, le nom de domaine NFS était défini au premier redémarrage suivant l'installation.
La fonction de nom de domaine NFSv4 affecte l'installation du SE de la manière suivante :
La commande sysidtool intègre un programme sysidnfs4évolué. Le programme sysidnfs4 est maintenant exécuté pendant la phase d'installation afin de déterminer si un domaine NFSv4 a été configuré pour le réseau.
Lors d'une installation interactive, le nom de domaine NFSv4 par défaut dérivé automatiquement du système d'exploitation est communiqué à l'utilisateur. Celui-ci peut accepter la valeur par défaut ou spécifier un autre nom de domaine NFSv4.
Pour plus d'informations, reportez-vous aux pages de manuel sysidtool(1M) et sysidnfs4(1M).
Dans le cadre d'une installation Solaris JumpStartTM, un nouveau mot-clé est disponible dans le fichier sysidcfg. L'utilisateur peut donc attribuer une valeur au domaine NFSv4 à l'aide de ce nouveau mot-clé, nfs4_domain.
Pour plus d'informations sur ce nouveau mot-clé, reportez-vous à la page de manuel sysidcfg(4) Cette page de manuel fournit également un exemple d'utilisation du nouveau mot-clé nfs4_domain.
Pour plus d'informations sur la configuration du nom de domaine NFSv4, reportez-vous au System Administration Guide: Network Services .
Solaris Live Upgrade a subi les évolutions suivantes dans la version actuelle :
Vous pouvez désormais mettre à niveau le système d'exploitation Solaris lorsque des zones non globales sont installées sur un système à l'aide de Solaris Live Upgrade.
Vous devez installer le nouveau package SUNWlucfg avec les autres packages Solaris Live Upgrade, SUNWlur et SUNWluu.
Ces trois packages font partie des composants logiciels nécessaires à la mise à niveau à l'aide de Solaris Live Upgrade. Outre les fonctionnalités existantes, ils intègrent de nouvelles fonctions ainsi que des correctifs de bogues. Pour exécuter la mise à niveau, vous devez impérativement installer ces packages sur le système avant d'exécuter Solaris Live Upgrade.
Pour plus d'informations sur la mise à niveau en cas d'installation de zones non globales sur un système, reportez-vous au Solaris 10 Installation Guide: Solaris Live Upgrade and Upgrade Planning.
À partir de la version Solaris 10 8/07, vous pouvez mettre à niveau le SE Solaris lorsque des zones non globales sont installées, sans la plupart des limitations que présentaient les versions antérieures à Solaris 10 8/07.
La seule limitation liée à l'opération de mise à niveau concerne l'archive Solaris Flash. En cas d'installation à l'aide d'une archive Solaris Flash, celle-ci ne sera pas installée correctement sur votre système si elle contient des zones non globales.
La liste suivante récapitule les changements nécessaires à la mise à niveau de systèmes comportant des zones non globales.
Avec le programme d'installation interactif Solaris, il est possible d'effectuer une mise à niveau ou d'appliquer un patch au système lorsque des zones non globales sont installées, à l'aide de CD ou DVD. Vous pouvez également utiliser une image d'installation réseau pour les CD ou pour les DVD. Auparavant, seuls les DVD permettaient la mise à niveau. L'opération peut prendre un certain temps en fonction du nombre de zones non globales installées.
Lors d'une installation JumpStart automatisée, il est possible d'effectuer une mise à niveau ou d'appliquer un patch en utilisant les mots-clés appropriés. Dans les versions antérieures à Solaris 10 8/07, vous ne pouviez utiliser qu'un nombre limité de mots-clés. L'opération peut prendre un certain temps en fonction du nombre de zones non globales installées.
Avec Solaris Live Upgrade, vous pouvez procéder à une mise à niveau ou appliquer un patch au système comportant des zones non globales. Si vous utilisez un système comportant des zones non globales, Solaris Live Upgrade est le programme recommandé pour la mise à niveau ou l'ajout de patchs. La durée de mise à niveau risque d'être beaucoup plus longue avec d'autres programmes de mise à niveau, car celle-ci augmente de façon linéaire en fonction du nombre de zones non globales installées. Si vous appliquez un patch au système à l'aide de Solaris Live Upgrade, il est inutile de mettre le système en mode mono-utilisateur. Solaris Live Upgrade permet également d'optimiser la disponibilité du système pendant l'opération.
La liste suivante récapitule les changements nécessaires à la mise à niveau de systèmes comportant des zones non globales.
Vous devez installer le nouveau package SUNWlucfg avec les autres packages Solaris Live Upgrade, SUNWlur et SUNWluu. Ce package est obligatoire pour les systèmes comportant des zones non globales, mais également pour tous les types de système.
Ces trois packages font partie des composants logiciels nécessaires à la mise à niveau à l'aide de Solaris Live Upgrade. Outre les fonctionnalités existantes, ils intègrent de nouvelles fonctions ainsi que des correctifs de bogues. Pour exécuter la mise à niveau, vous devez impérativement installer ces packages sur le système avant d'exécuter Solaris Live Upgrade.
La création d'un environnement d'initialisation à partir de l'environnement en cours d'exécution est essentiellement la même que dans les versions précédentes à une exception près. Vous pouvez spécifier une tranche de destination pour un système de fichiers partagé au sein d'une zone non globale.
L'argument de l'option -m dispose d'un nouveau champ facultatif, nom de zone. Ce nouveau champ permet de définir le nouvel environnement d'initialisation et de spécifier les zones contenant des systèmes de fichiers indépendants. Cet argument place le système de fichiers indépendant de la zone sur une tranche distincte dans le nouvel environnement d'initialisation.
La commande lumount permet aux zones non globales d'accéder aux systèmes de fichiers correspondants présents sur les environnements d'initialisation inactifs. Lorsque l'administrateur de la zone globale se sert de la commande lumount pour monter un environnement d'initialisation inactif, celui-ci s'applique également aux zones non globales.
L'inventaire des systèmes de fichiers à l'aide de la commande lufslist permet d'obtenir la liste des systèmes de fichiers correspondant à la zone globale et aux zones non globales.
Sur un système Solaris configuré avec Trusted Extensions, vous devez réaliser des étapes supplémentaires afin de mettre à niveau les zones étiquetées. Pour de plus amples informations sur cette procédure, reportez-vous à la section Upgrading a Trusted Extensions System That is Configured with Labeled Zones, sous Installation Enhancements , dans les Solaris 10 8/07 Release Notes.
À partir de cette version, l'outil sysidkdb permet de paramétrer la langue USB et la configuration de clavier correspondante.
Voici comment ce nouvel outil procède :
Si le clavier prend en charge l'identification automatique, la langue et la configuration du clavier sont détectées automatiquement au cours de l'installation.
Dans le cas contraire, l'outil sysidkdb affiche la liste des configurations de clavier prises en charge lors de l'installation. Sélectionnez dans la liste la configuration de clavier de votre choix.
Auparavant, la valeur d'identification automatique du clavier USB était définie sur 1 au cours de l'installation. Par conséquent, tous les claviers non auto-identifiables étaient considérés comme des claviers de type anglais américain (U.S. English) au cours de l'installation sur SPARC.
Les claviers PS/2 ne prennent pas en charge l'identification automatique. Vous devez sélectionner la configuration du clavier pendant l'installation.
Spécifications JumpStart : si le clavier utilisé ne prend pas en charge l'identification automatique et si vous souhaitez désactiver l'affichage des invites au cours de l'installation JumpStart, sélectionnez la langue du clavier dans le fichier sysidkdb. Dans le cas d'une installation JumpStart, la langue par défaut est l'anglais américain (U.S. English). Pour choisir une autre langue et sélectionner la configuration de clavier correspondante, définissez le mot-clé du clavier dans le fichier sysidkdb.
Pour plus d'informations sur cette fonction, reportez-vous au manuel Guide d’installation de Solaris 10 : Installations basées sur les réseaux.
À partir des patchs 119254-42 et 119255-42, les utilitaires d'installation de patch, patchadd et patchrm, ont été modifiés afin de changer le mode de gestion de certaines fonctions de distribution de patch. Cette modification affecte l'installation de ces patchs sur toutes les versions de Solaris 10. Ces patchs "à application différée" gèrent mieux les multiples modifications distribuées à l'aide de patchs de fonction.
Seuls certains patchs sont conçus comme des patchs à activation différée. Ainsi, un patch de noyau associé à une version de Solaris 10 supérieure à Solaris 10 3/05, par exemple la version Solaris 10 8/07 constitue un patch à activation différée typique. Un patch est considéré comme patch à activation différée si la variable SUNW_PATCH_SAFEMODE est définie dans le fichier pkginfo. Les patchs non conçus en tant que patchs à activation différée sont installés comme auparavant. Par exemple, l'installation des patchs distribués auparavant, tels que les patchs de noyau 118833-36 (SPARC) et 118855-36 (x86), ne fait pas appel aux utilitaires d'application de patch à activation différée.
Auparavant, des scripts de patch complexes étaient requis pour ces patchs de noyau. Ces scripts étaient nécessaires pour éviter tout problème lors de l'installation de patch sur une partition active, en raison des incohérences entre les objets fournis par le patch et le système en cours d'exécution (partition active). Dorénavant, les patchs à activation différée utilisent le système de fichiers loopback (lofs) pour garantir la stabilité du système en cours d'exécution. Lorsqu'un patch est appliqué au système en cours d'exécution, le lofs reste stable pendant la mise à jour. Ces grands patchs de noyau ont toujours demandé une réinitialisation. Cette réinitialisation active désormais les changements effectués par les lofs. Le patch README contient des instructions sur les patchs nécessitant une réinitialisation.
Si vous exécutez des zones non globales ou si les lofs sont désactivés, tenez compte des indications ci-dessous lors de l'installation et de la suppression de patchs à activation différée.
Toutes les zones non globales doivent être arrêtées pour que vous puissiez réaliser cette opération. Vous devez arrêter la zone non globale avant d'appliquer le patch.
Par soucis de sécurité, l'application de patchs à activation différée requiert le système de fichiers loopback (lofs). Les lofs des systèmes équipés de Sun Cluster 3.1 ou de Sun Cluster 3.2 sont généralement désactivés, car ils limitent les fonctionnalités HA-NFS lorsqu'ils sont activés. Par conséquent, avant d'installer un patch à activation différée, il faut réactiver le système de fichiers loopback en exécutant les étapes ci-dessous :
Supprimez ou mettez en commentaire la ligne suivante du fichier /etc/system :
exclude:lofs. |
Redémarrez le système.
Installez le patch.
L'installation du patch étant terminée, restaurez ou annulez le commentaire de la même ligne dans le fichier /etc/system.
Réinitialisez le système pour reprendre les opérations normales.
Sun recommande de gérer l'application de patchs à l'aide de Solaris Live Upgrade. Solaris Live Upgrade évite les problèmes d'application de patch sur un système en cours d'exécution. Solaris Live Upgrade réduit la période d'indisponibilité due à l'application des patchs et diminue les risques en offrant la possibilité de poursuivre les opérations en cas de problème. Reportez-vous au Solaris 10 Installation Guide: Solaris Live Upgrade and Upgrade Planning.
Les améliorations et fonctionnalités de mise en réseau suivantes ont été ajoutées à la version Solaris 10 8/07.
Solaris implémente à présent le mode Tunnel IPSec par RFC 2401. Les sélecteurs de paquets internes peuvent être spécifiés par interface de tunnel à l'aide du nouveau mot-clé "tunnel" de ipsecconf(1M). IKE et PF_KEY gèrent les identités du mode Tunnel pour le mode Phase 2/Quick. L'interopérabilité avec les autres implémentations IPsec a été considérablement améliorée.
Pour plus d'informations, reportez-vous à la section Modes Transport et Tunnel dans IPsec du Guide d’administration système : services IP.
Cette fonction présente les avantages suivants :
Meilleures performances par rapport à l'approche basée sur les modules STREAMS
Possibilité d'intercepter des paquets transitant entre les zones
La fonction de crochet de filtre de paquets fait partie d'une nouvelle API intégrée au noyau. Les développeurs peuvent exploiter l'API dans le but de travailler avec le protocole IP à l'intérieur du noyau ou d'intercepter des paquets.
À partir de cette version, routeadm(1M) est optimisé pour gérer les services du démon de routage basés sur SMF. Les conversions de services sont également assurées pour les commandes suivantes :
Il est possible, par conséquent, de gérer ces services par le biais de commandes SMF standard telles que svcadm et svccfg. Ces services peuvent tirer parti des fonctions de redémarrage fournies par SMF.
La suite de routage Quagga propose un ensemble de protocoles de routage IETF pour Solaris, dont OSPF et BGP, dans le but d'autoriser un déploiement à haute disponibilité de Solaris via un routage dynamique et gérable par SMF 'routeadm'.
Quagga est un dérivé du logiciel GNU Zebra qui figurait auparavant dans Solaris. Il fournit de nombreuses mises à jour et plusieurs nouvelles fonctions. Pour plus d'informations, voir /etc/quagga/README.Solaris.
À partir de cette version, le système d'exploitation Solaris prend en charge le protocole de configuration hôte dynamique pour IPv6 (DHCPv6, Dynamic Host Configuration Protocol for IPv6), tel que décrit dans RFC 3315. Le protocole DHCPv6 permet à Solaris d'acquérir automatiquement les adresses IPv6 à partir des serveurs DHCP locaux sans configuration manuelle.
Pour plus d'informations, reportez-vous aux pages de manuel suivantes :
À partir de cette version, le système d'exploitation Solaris ne propose plus deux fichiers d'hôtes indépendants. /etc/inet/hosts est le seul fichier d'hôte. Il regroupe l'ensemble des entrées IPv4 et IPv6. Les administrateurs du système Solaris n'ont pas besoin de gérer les entrées IPv4 dans deux fichiers d'hôtes toujours synchronisés. Pour des raisons de compatibilité ascendante, le fichier /etc/inet/ipnodes est remplacé par un lien symbolique du même nom (/etc/inet/hosts).
Pour plus d'informations, reportez-vous aux pages de manuel hosts(4) et ipnodes(4).
Large Send Offload (LSO) est une technologie de déchargement matériel. LSO décharge la segmentation TCP vers le matériel NIC afin d'améliorer les performances du réseau en réduisant la charge du travail qui s'exerce sur les CPU. LSO permet l'adoption du réseau 10Gb sur des systèmes qui manquent de ressources CPU ou pour lesquels les threads de CPU sont relativement lents. Cette fonction intègre une infrastructure LSO de base dans la pile TCP/IP Solaris, de façon à ce que tout centre d'information sur le réseau (NIC) reconnaissant la technologie LSO puisse être activé en mode LSO.
L'intérêt de la mise à jour du pilote nge dans cette version est de permettre la prise en charge de la structure Jumbo. Le MTU par défaut du pilote nge a été porté à 9 Ko, ce qui a pour effet d'améliorer les performances du système et de limiter considérablement l'utilisation de la CPU.
Pour plus d'informations, reportez-vous à la page de manuel nge(7D).
Pour plus d'informations sur cette fonction, reportez-vous à la section Définition du nom de domaine NFSv4 lors de l'installation .
Les améliorations et fonctionnalités de sécurité suivantes ont été ajoutées à la version Solaris 10 8/07.
La structure de gestion clé de Solaris (KMF, Key Management Framework) fournit des outils et interfaces de programmation pour gérer les objets de clé publique (PKI). Grâce à la commande pktool, l'administrateur peut gérer les objets PKI dans nss, pkcs11 et les keystores basés sur des fichiers à l'aide d'un utilitaire unique.
La couche API permet au développeur de désigner le type de keystore à utiliser. KMF fournit également des modules de plug-in pour ces technologies PKI. Grâce à ces modules, les développeurs ont la possibilité d'écrire de nouvelles applications pour les keystores pris en charge.
KMF propose une fonction unique reposant sur une base de données de stratégies à l'échelle du système susceptible d'être utilisée par les applications KMF, quel que soit le type de keystore. À l'aide de la commande kmfcfg, l'administrateur a la possibilité de créer des définitions de stratégie au sein d'une base de données globale. Les applications KMF peuvent alors choisir la stratégie à appliquer de façon à ce que toutes les opérations KMF suivantes soient liées par cette stratégie. Les définitions de stratégie sont régies par les règles suivantes :
Stratégie d'exécution des validations
Conditions normales et conditions étendues d'utilisation des clés
Définitions des appels de confiance
Paramètres OCSP
Paramètres de base de données CRL (emplacement, par exemple)
Pour plus d'informations, consultez les références suivantes :
Page de manuel pktool(1)
Page de manuel kmfcfg(1)
Chapitre 15, Solaris Key Management Framework du System Administration Guide: Security Services
À partir de cette version, la bibliothèque libmd assure l'implémentation des algorithmes de hachage cryptographiques MD4, MD5, SHA1 et SHA2, y compris SHA256, SHA384, SHA512, à l'aide d'API légères. Pour plus d'informations sur les API et les fonctionnalités offertes par libmd, reportez-vous aux pages de manuel suivantes :
La fonction de structure cryptographique Solaris assure la protection des clés de signature dans un périphérique à jeton. En outre, la commande elfsign affiche des informations supplémentaires sur les signatures et les certificats.
Pour de plus amples informations, consultez la page de manuel elfsign(1).
Les packages Encryption Kit, SUNWcry et SUNWcryr sont inclus par défaut au logiciel Solaris 10 8/07. La cryptographie complète pour la structure cryptographique Solaris, pour Kerberos et pour OpenSSL est dorénavant installée par défaut.
Les améliorations et fonctionnalités de système de fichiers suivantes ont été ajoutées à la version Solaris 10 8/07.
La version Solaris assure la prise en charge des périphériques cibles SCSI (il peut s'agir de disques ou de lecteurs de bande). Les versions antérieures à Solaris 10 8/07 prennent en charge les initiateurs iSCSI. La configuration de cibles iSCSI Solaris permet de connecter certains périphériques Fibre Channel existants aux clients sans requérir l'investissement dans des HBA Fibre Channel. De plus, les systèmes disposant de baies dédiées peuvent désormais exporter un stockage répliqué avec des systèmes de fichiers ZFS ou UFS.
Pour configurer et gérer vos périphériques iSCSI cibles, vous pouvez vous servir de la commande iscsitadm. Pour le périphérique de disque que vous sélectionnez comme cible iSCSI, il conviendra d'indiquer un système de fichiers ZFS ou UFS de taille équivalente en guise de magasin de stockage pour le démon iSCSI.
Une fois le périphérique cible configuré, servez-vous de la commande iscsiadm pour identifier vos cibles iSCSI, lesquelles se chargeront de découvrir et d'utiliser le périphérique iSCSI cible.
Page de manuel iscsiadm(1M)
Page de manuel iscsitadm(1M)
La fonction d'espace FILE étendu prend en charge un nouveau mode de la commande de bibliothèque fopen, F. Le mode F active l'ouverture des fichiers au-delà de la limite de 255. Cette fonction permet aux développeurs d'utiliser la commande fopen pour gérer les descripteurs de fichier jusqu'aux limites définies à l'aide de la commande limit ou ulimit.
Les améliorations et fonctionnalités de ressources système suivantes ont été ajoutées à la version Solaris 10 8/07.
La technologie BrandZ de Sun offre la structure nécessaire pour créer des zones marquées non globales contenant des environnements d'exploitation non natifs. En tant que simple extension des zones non globales, les zones marquées offrent le même environnement isolé et sécurisé. La gestion des marques s'effectue via les extensions à la structure des zones actuelles.
La marque actuellement disponible est la marque lx, conteneurs Solaris pour applications Linux. Ces zones non globales permettent de bénéficier d'un environnement applicatif Linux sur une machine x86 ou x64 fonctionnant sous Solaris.
La marque lx inclut les outils dont vous avez besoin pour installer une version CentOS 3.5 à 3.8 ou Red Hat Enterprise Linux 3.5 à 3.8 à l'intérieur d'une zone non globale. Les machines fonctionnant sous le système d'exploitation Solaris en mode 32 ou 64 bits peuvent exécuter des applications Linux 32 bits.
Pour plus d'informations, reportez-vous à la troisième partie, Zones marquées, du Guide d’administration système : Gestion des ressources conteneurs Solaris et des zones Solaris.
Consultez également les pages de manuel suivantes :
brands(5)
lx(5)
Grâce au plus grand nombre de fonctions de gestion de ressources et de zones intégrées, il est désormais plus facile d'exploiter les capacités du système dans ce domaine au moyen de la commande zonecfg. La configuration des ressources que vous spécifiez est définie automatiquement au moment de l'initialisation de la zone. Vous n'avez plus besoin d'effectuer les étapes manuelles auparavant nécessaires.
Vous pouvez vous servir de la commande zonecfg pour définir les paramètres de gestion des ressources pour la zone globale.
Les contrôles de ressource à l'échelle d'une zone peuvent être définis à l'aide de la méthode de noms de propriété globale de votre choix. De nouveaux contrôles de ressource de zone et de projet sont également disponibles :
zone.max-locked-memory
zone.max-msg-ids
zone.max-sem-ids
zone.max-shm-ids
zone.max-shm-memory
zone.max-swap : permet de limiter l'utilisation du swap pour les zones par le biais de la ressource à allocation restrictive.
project.max-locked-memory : remplace project.max-device-locked-memory.
Des méthodes ont été ajoutées pour définir l'ordonnanceur par défaut dans une zone (la nouvelle propriété de classe de planification, par exemple).
Les pools de ressources ont été améliorés. Il est possible d'ajouter un pool temporaire créé de façon dynamique lors de l'initialisation d'une zone. Le pool est configuré via la ressource CPU dédiée.
Une sous-commande clear a été prévue pour effacer la valeur des paramètres facultatifs.
Les améliorations apportées à rcapd(1M) permettent d'optimiser l'allocation restrictive de la mémoire physique à partir de la zone globale. Les limites sont fixées au moyen de la ressource d'allocation restrictive de la mémoire.
Vous pouvez tirer parti de cette fonctionnalité pour limiter la mémoire physique allouée aux zones marquées lx et aux zones natives. Pour plus d'informations, reportez-vous à la section zones marquées lx : conteneurs Solaris pour applications Linux.
La prise en compte de la taille résidente (RSS, Resident Set Size) définie a été améliorée. Le démon d'allocation restrictive, rcapd et la commande prstat ont bénéficié de plusieurs améliorations.
Pour plus d'informations, consultez les références suivantes :
Page de manuel prstat(1M)
Page de manuel rcapd(1M)
Page de manuel zonecfg(1M)
Page de manuel resource_controls(5)
Guide d’administration système : Gestion des ressources conteneurs Solaris et des zones Solaris
À présent, il est possible de configurer l'environnement de réseau IP de deux façons différentes, selon que la zone est dotée d'une instance IP exclusive ou qu'elle partage la configuration et l'état de couche IP avec la zone globale. Les types IP sont configurés à l'aide de la commande zonecfg.
Le type IP partagé est le type par défaut. Ces zones se connectent aux mêmes VLAN ou LAN en tant que zone globale et partagent la couche IP. Les zones marquées lx sont configurées en tant que zones IP partagées. Pour plus d'informations, reportez-vous à la section zones marquées lx : conteneurs Solaris pour applications Linux.
La fonctionnalité complète de niveau IP est disponible dans une zone IP exclusive. Lorsqu'une zone doit être isolée au niveau de la couche IP sur le réseau, elle peut être affectée à une instance IP exclusive. La zone en mode IP exclusif peut être utilisée pour consolider les applications devant communiquer sur divers sous-réseaux sous différents VLAN ou LAN.
Pour plus d'informations, consultez les références suivantes :
Page de manuel zonecfg(1M)
Page de manuel zones(5)
Guide d’administration système : Gestion des ressources conteneurs Solaris et des zones Solaris
Pour en savoir plus sur la configuration, reportez-vous au Chapitre 17, Configuration des zones non globales (présentation) du Guide d’administration système : Gestion des ressources conteneurs Solaris et des zones Solaris et au Chapitre 18, Planification et configuration de zones non globales (tâches) du Guide d’administration système : Gestion des ressources conteneurs Solaris et des zones Solaris.
Pour plus d'informations sur les composants, reportez-vous au Chapitre 26, Administration de zones Solaris (présentation) du Guide d’administration système : Gestion des ressources conteneurs Solaris et des zones Solaris et au Chapitre 27, Administration de zones Solaris (tâches) du Guide d’administration système : Gestion des ressources conteneurs Solaris et des zones Solaris.
Les arguments d'initialisation sont désormais pris en charge dans le cadre des commandes boot et reboot. Voici les arguments qu'il est possible d'utiliser pour l'instant :
-m <smf_options>
-i </path/to/init/>
-s
Les arguments d'initialisation peuvent être transmis des façons suivantes :
global# zoneadm -z myzone boot -- -m verbose
global# zoneadm -z myzone reboot -- -m verbose
myzone# reboot -- -m verbose
Ils peuvent également être spécifiés de manière persistante en utilisant la nouvelle propriété bootargs de la commande zonecfg :
zonecfg:myzone> set bootargs="-m verbose"
Ce paramètre est appliqué sauf en cas de remplacement par les commandes reboot, zoneadm boot ou zoneadm reboot.
Pour plus d'informations sur les arguments d'initialisation et sur la propriété bootargs, consultez les références suivantes :
Page de manuel zoneadm(1M)
Page de manuel zonecfg(1M)
Guide d’administration système : Gestion des ressources conteneurs Solaris et des zones Solaris
Pour limiter la quantité totale de ressources System V utilisées par les processus à l'intérieur d'une zone non globale, vous disposez désormais des contrôles de ressources suivants à l'échelle de la zone :
zone.max-shm-memory
zone.max-shm-ids
zone.max-msg-ids
zone.max-sem-ids
Les contrôles de ressources sont définis par le biais de la propriété de ressource add rctl dans la commande zonecfg pour les zones non globales.
Pour restreindre la consommation de la zone globale, il est possible de configurer les contrôles de ressources via la commande prctl.
Pour plus d'informations, consultez les références suivantes :
Page de manuel prctl(1)
Page de manuel zonecfg(1M)
Page de manuel resource_controls(5)
Guide d’administration système : Gestion des ressources conteneurs Solaris et des zones Solaris
Le système Solaris associe automatiquement un identificateur unique global à chaque zone non globale au moment de l'installation de la zone. Il est possible de récupérer cet identificateur à la fois dans la zone globale et dans la zone non globale à l'aide de la commande zoneadm list -p. Il permet aux utilisateurs de faire un suivi des ressources en considérant la zone comme une ressource à part entière. Il est également pratique pour l'identification des zones lors des actions suivantes :
Déplacement de zones
Modification du nom des zones
Ensemble des événements n'impliquant pas une destruction du contenu d'une zone
Pour plus d'informations, reportez-vous à la page de manuel zoneadm(1M).
Désormais, les utilisateurs ont la possibilité de signaler des zones comme incomplètes au moyen d'une nouvelle fonction zoneadm. Cette nouvelle fonction zoneadm permet l'enregistrement d'un état d'échec de zone fatal ou permanent par le biais d'un logiciel administratif qui met à jour le contenu de la zone.
Pour plus d'informations, reportez-vous à la page de manuel zoneadm(1M).
DTrace peut maintenant être utilisé dans une zone non globale lorsque les privilèges dtrace_proc et dtrace_user sont affectés à la zone. Certaines limites s'appliquent aux fournisseurs et actions DTrace dans la zone. Avec le privilège dtrace_proc, il est possible de tirer parti des fournisseurs fasttrap et pid. Avec le privilège dtrace_user, seuls les fournisseurs 'profile' et 'syscall' sont exploitables.
Vous pouvez ajouter ces privilèges au jeu de privilèges disponible dans la zone non globale en utilisant la propriété limitpriv de la commande zonecfg.
La section Privilèges configurables pour les zones non globales présente un aperçu des privilèges dans une zone non globale.
Pour plus d'informations au sujet de la configuration de zone, de la spécification de privilèges de zone et de l'exécution de l'utilitaire DTrace, consultez les références suivantes :
Guide d’administration système : Gestion des ressources conteneurs Solaris et des zones Solaris
Page de manuel zonecfg(1M)
Page de manuel dtrace(1M)
Les améliorations et fonctionnalités d'outils de bureau suivantes ont été ajoutées à la version Solaris 10 8/07.
Thunderbird 2.0 est un client de messagerie, de RSS et de groupe de nouvelles (Newsgroup) développé par la communauté Mozilla. Il offre des fonctionnalités équivalentes aux fonctions de messagerie et de groupe de nouvelles de Mozilla.
L'interface utilisateur de Firefox 2.0 bénéficie de plusieurs innovations qui rendent plus conviviales les opérations de navigation et les interactions avec les fonctions de recherche, de création de signet et de gestion d'historique. Les principales améliorations ont porté sur la consultation par onglet, le traitement RSS, la gestion des extensions, la sécurité et les performances.
À partir de cette version, un nouveau plug-in, OTR (Off-the-Record, hors enregistrement), a été ajouté à GAIM.
La messagerie OTR permet aux utilisateurs de mener des conversations privées sur GAIM et d'accéder à tous ses services de messagerie, à l'aide des fonctionnalités suivantes :
Codage
Authentification
Possibilité de refus
PFS (Perfect Forward Secrecy, confidentialité parfaite de transfert)
Pour plus d'informations, reportez-vous à la page http://www.cypherpunks.ca/otr/.
À partir de cette version, la prise en charge XVideo sur RealPlayer améliore significativement les performances de lecture vidéo sur les systèmes x86.
Les améliorations et fonctionnalités de multifenêtrage X11 suivantes ont été ajoutées à la version Solaris 10 8/07.
CDE présente actuellement la liste des noms de langue cryptés sous la forme d'un menu en cascade dans l'écran de connexion. La fonction de révision de la sélection de la langue dtlogin propose une liste de connexion orientée langue plus conviviale. CDE offre une fonction permettant de mémoriser le nom de langue de connexion par défaut par affichage. Dans les environnements SunRay, il est possible d'utiliser une ressource X pour éviter que les affichages se souviennent de la langue de connexion.
Pour plus d'informations, reportez-vous à la page de manuel dtlogin.
À partir de cette version, les serveurs X Window System comprennent un fournisseur DTrace USDT (User-land Statically Defined Tracing, suivi des utilisateurs définis de façon statistique) pour mettre en place les connexions client X11. Les serveurs X Window System contiennent les composants suivants :
Xorg
Xsun
Xprt
Xnest
Xvfb
Pour plus d'informations sur les sondes disponibles et leurs arguments et pour savoir comment utiliser les scripts DTrace, visitez le site Web http://people.freedesktop.org/~alanc/dtrace/.
Le serveur Xorg du système de multifenêtrage X11, les graphiques qui s'y rapportent et les pilotes de périphériques d'entrée ont été mis à niveau vers la version X11R7.2. La version X11R7.2 intègre la version 1.2 du serveur Xorg. Cette version ajoute, en outre, les versions 64 bits du serveur Xorg aux plates-formes x64 et SPARC, bien que les pilotes des périphériques graphiques SPARC communs ne soient pas encore disponibles pour Xorg.
Cette version permet également de disposer du serveur X imbriqué Xephyr et de la version Xorg de Xvfb, qui figurent tous les deux dans le répertoire /usr/X11/bin. Cette version de Xorg ne prend plus en charge l'extension LBX (Low Bandwidth X, X à connexion faible débit) . L'utilisation des fonctions de tunnel X et de compression de ssh(1) est suggérée pour les sites nécessitant un affichage X sur des liaisons de réseau à débit très limité.
Les améliorations et fonctionnalités de prise en charge linguistique suivantes ont été ajoutées à la version Solaris 10 8/07.
Les données localisées pour l'Europe, le Moyen-Orient et l'Afrique (zone EMEA), pour l'Amérique centrale et du sud et pour l'Océanie ont été migrées vers le référentiel CLDR 1.3 (Common Locale Data Repository, référentiel de données localisées communes). Cette migration permet d'améliorer la qualité des données localisées et d'assurer leur cohérence entre les jeux de codes.
Pour de plus amples informations sur le référentiel CDLR, reportez-vous à l'adresse http://www.unicode.org/cldr.
À partir de cette version, la police HG japonaise est conforme à la spécification JISX0213: 2004.
Les deux types suivants de conversion de jeux de codes entre les caractères Unicode et japonais sont maintenant autorisés :
Dans le cadre de la conversion depuis/vers eucJP, PCK (SJIS) et ms932, iconv prend désormais en charge UTF-16, UCS-2, UTF-32, UCS-4 et les variantes endian fixes correspondantes, telles que UTF-16BE et UTF-16LE, ainsi que UTF-8.
iconv gère le nom de jeu de codes eucJP-ms, ce qui permet d'effectuer la conversion entre les caractères japonais EUC et Unicode comme sous Windows. Toutes les variantes de codage Unicode mentionnées précédemment sont également prises en charge avec eucJP-ms.
Pour plus d'informations, reportez-vous à la page de manuel iconv_ja(5).
Le programme de sélection de méthode de saisie, gnome-im-switcher-applet, est remplacé par une application GTK+ autonome, iiim-panel. iiim-panel démarre et réside automatiquement sur le panneau GNOME lors de la connexion à Java Desktop System (Java DS) dans les langues UTF-8 ou asiatiques. iiim-panel peut également être exécuté dans l'environnement CDE (Common Desktop Environment, environnement de bureau commun).
IIIMF prend en charge les moteurs de langue qui émulent la configuration de clavier EMEA (tels que le français, le polonais ou le néerlandais).
Pour plus d'informations, reportez-vous à l'aide en ligne de l'éditeur de méthode de saisie (iiim-properties).
Cette fonction offre une nouvelle option de commande kbd -s langue. Cette option permet aux utilisateurs de paramétrer les configurations de clavier dans le noyau. La configuration de clavier Zero-CountryCode est particulièrement utile sur les systèmes SPARC. Dans les versions précédentes, tous les claviers non auto-identifiables étaient systématiquement considérés comme des claviers de type américain sur les systèmes SPARC.
Pour plus d'informations, reportez-vous à la page de manuel kbd(1).
Les améliorations et fonctionnalités de développement suivantes ont été ajoutées à la version Solaris 10 8/07.
SunVTSTM (Sun Validation Test Suite) est un package de diagnostic logiciel complet qui teste et valide Sun SPARC et le matériel x86. Il vérifie la configuration et le bon fonctionnement des contrôleurs, périphériques et plates-formes.
Les modifications suivantes ont été apportées au SE Solaris pour SunVTS :
nouveaux tests, xnetlbtest et iobustest. Dans les versions antérieures à Solaris 10 8/07, ces deux tests n'étaient disponibles qu'au sein du package de fabrication interne ;
tests de mémoire SunVTS intégrés à la bibliothèque THM (Test Hang Mitigation, réduction des blocages de test) ;
améliorations de nettest avec une nouvelle option pour l'acceptation de taille de paquet ;
améliorations du test bmcenvironment pour la prise en charge des tests de DEL ;
modification de netlbtest pour stocker les octets CRC sur le pilote nxge ;
améliorations de disktest ;
test générique de bande avec des paramètres d'options améliorés ;
améliorations de iobustest : prise en charge de disque EFI, compteurs de performances liées aux bus, SIU/NCU d'effort, meilleure couverture du niveau d'effort, capacité de balayage PCI-E.
Pour de plus amples informations sur ces fonctions et ces tests, reportez-vous à la documentation SunVTS 6.4 à l'adresse http://www.sun.com/documentation.
Les améliorations et pilotes suivants ont été ajoutés à la version Solaris 10 8/07.
À partir de cette version, grâce à une nouvelle famille de protocoles, RDS (Reliable Datagram Sockets, sockets de datagramme fiables), un socket peut envoyer des messages vers plusieurs destinations, via l'interconnexion InfiniBand.
RDS est fourni via un nouveau package, SUNWrds. Le package SUNWrds est constitué des pilotes rds et rdsib qui assurent respectivement l'interface de socket et de transport.
Le pilote de contrôleur hôte USB EHCI évolué gère le transfert isochrone du port USB 2.0 ou des périphériques isochrones à haut débit.
Pour plus d'informations, reportez-vous à la page de manuel usb_isoc_request(9S).
Cette fonction assure la prise en charge de la réinitialisation des unités logiques (LUN) par les commandes uscsi. Les utilisateurs peuvent tirer parti des commandes de réinitialisation des unités logiques avec uscsi_flags configurée en tant que USCSI_RESET_LUN avec cette fonction.
Les commandes READ/WRITE FPDMA QUEUED sont désormais prises en charge. Le gain de performance est considérable pour les opérations d'E/S ayant recours au pilote Solaris Marvell dans des conditions de travail spécifiques. Les autres charges de travail en profitent également dans une moindre mesure. Grâce à cette fonction, les performances et les capacités d'écriture des pilotes Hitachi 250GB HDS7225SBSUN250G de Sun augmentent considérablement.
On constate également une amélioration significative des performances lors du traitement de nombreuses charges de travail pour les unités compatibles avec cette portion facultative de la spécification SATA.
La fonction de prise en charge de Compact Flash (CF) permet d'utiliser une carte CF en tant que disque ATA à l'aide d'un adaptateur CF-ATA. Cette fonction facilite le démarrage du système à partir d'une carte CF et le stockage des données sur une carte CF.
Pour plus d'informations sur la prise en charge de Compact Flash, reportez-vous à la page de manuel ata(7D).
À partir de cette version, le pilote usbsacm prend en charge les modems USB conformes à la spécification USB CDC ACM (Universal Serial Bus Communication Device Class Abstract Control Model). Les clients peuvent associer le pilote usbsacm à leurs téléphones portables, à des cartes PCMCIA ou à tout autre périphérique de type modem. Le pilote usbsacm génère des nœuds terminaux sous /dev/term/. Les clients peuvent dès lors se servir de la commande pppd(1M) pour transmettre des datagrammes via ces ports série.
La fonction de prise en charge CardBus permet la prise en charge de cartes PC 32 bits dans Solaris. Dorénavant, les cartes PC 16 bits et 32 bits sont reconnues par Solaris. Pour de plus amples informations, reportez-vous aux pages de manuel pcic(7D)pcic(7D) et cardbus(4).
À partir de cette version, le système d'exploitation Solaris prend en charge le lecteur de bande IBM LTO-4.
À partir de cette version, le système d'exploitation Solaris prend en charge le lecteur de bande HP LTO-4.
Vous pouvez désormais profiter des pilotes d'accélération graphique Xorg et OpenGL pour les cartes NVIDIA Quadro et GeForce. Les outils de configuration nvidia-settings et nvidia-xconfig de ces pilotes sont également fournis.
À partir de cette version, vous disposez d'une horloge chien de garde programmable par l'utilisateur sur des plates-formes sun4v gérant la compatibilité ascendante. L'utilisateur peut manipuler cette horloge via les IOCTL fournis par le pseudo-pilote ntwdt à compatibilité ascendante.
Le pseudopilote de moniteur de zone thermique ACPI minimal pour le SE Solaris contrôle les événements de zones thermiques à partir de l'ACPI. Les événements de zones thermiques sont essentiellement liés à des températures critiques. Si, dans un système particulier, le BIOS implémente des méthodes ACPI spécifiques, ce pseudopilote contrôle les événements de zones thermiques.
Le pilote aac mis à jour prend en charge la nouvelle génération de cartes RAID Adaptec de type Rocket Chip. Il est également compatible avec l'utilitaire ASM (Adaptec Storage Management, gestion du stockage Adaptec) lequel a pour fonction de configurer et de surveiller le contrôleur et les disques durs reliés.
Pour plus d'informations, visitez le site Web d'Adaptec à l'adresse suivante : http://www.adaptec.com/en-US/products/adps/.
Le pilote audioixp est le pilote audio Solaris conçu pour la puce ATI IXP400 Southbridge fabriquée par ATI Corporation. La puce ATI IXP400 intègre un contrôleur audio AC97. Cette puce est adoptée par de nombreux fabricants de cartes mères. C'est le cas, par exemple, du modèle Ferrari4000. Le pilote audioixp est conforme à l'architecture de pilote audio de Solaris (SADA, Solaris Audio Driver Architecture).
Le pilote audio haute définition, audiohd(7d), a été amélioré : il prend en charge plus de CODEC audio et assure des fonctionnalités d'enregistrement et de lecture audio de base. Les CODEC audio haute définition suivants sont pris en charge :
Realtek ALC260/262/880/882/883/885/888 ;
IDT/Sigmatel STAC9200(D) ;
périphériques analogiques AD1986/1988.
AHCI est un pilote SATA HBA à capacité d'enfichage à chaud pour contrôleurs SATA compatibles avec la spécification AHCI. Le pilote AHCI prend en charge les contrôleurs INTEL ICH6 et VIA vt8251. Toutefois, d'autres contrôleurs conformes à AHCI peuvent également fonctionner.
Pour plus d'informations, reportez-vous à la page de manuel ahci(7D).
Les améliorations et fonctionnalités de performances système suivantes ont été ajoutées à la version Solaris 10 8/07.
Les unités d'interface PCI (PIU, PCI Express Interface Units) des systèmes UltraSPARC T2 présentent des compteurs de performances intégrés qui peuvent être vidés à l'aide de busstat. La sortie de la commande busstat -l affiche les périphériques suivants pour de tels systèmes :
imu#
mmu#
peu#
bterr#
où # correspond à un numéro d'instance.
Ce compteur de performances intégré est conçu essentiellement à l'intention du personnel de service clientèle de Sun.
Le mode Hashed Cache Index est une nouvelle fonctionnalité matérielle disponible dans les processeurs UltraSPARC T2. Le matériel utilise de nombreuses autres bits d'adresse pour calculer un index de cache L2. Par conséquent, il existe plus de couleurs de page pour les grandes pages.
Pour optimiser les performances, le noyau Solaris peut maximiser le nombre de couleurs de page utilisées par tous les threads partageant un cache. Le sous-système de mémoire virtuelle Solaris a été étendu pour prendre en charge cette nouvelle fonctionnalité matérielle. Le calcul des couleurs adéquates améliore les performances et la cohérence du traitement des programmes d'application sur systèmes UltraSPARC T2.
La fonction d'optimisations de programmation CMT (Chip Multithreading Technology, technologie de multithreading à puce) multiniveau fournit au noyau Solaris un mécanisme de plate-forme indépendant. Ce mécanisme permet la détection et l'optimisation de diverses relations de partage matériel adéquates pour les performances, qui existent entre les CPU sur les architectures de processeur CMT nouvelles et existantes, notamment Niagara II.
Cette fonction améliore également le dispatcheur ou l'ordonnanceur de thread du noyau à l'aide d'une politique d'équilibrage de charge CMT multiniveau qui exploite les performances système sur divers systèmes processeur à unités d'exécution multiples, à plusieurs noyaux ou à plusieurs sockets.
Pour de plus amples informations sur cette fonction, reportez-vous au site Web de la communauté de performances OpenSolaris à l'adresse http://www.opensolaris.org/os/community/performance.
Cette fonction améliore l'évolutivité du comptage des processus du SE Solaris. Actuellement, tous les systèmes UltraSPARC gèrent un maximum de 8 192 contextes. Lorsque le nombre de processus dépasse 8 192, le noyau s'approprie le contexte pour maintenir les processus en service. L'appropriation d'un contexte à partir d'un processus implique les tâches suivantes :
inter-appel de toutes les CPU sur lesquelles le processus s'est exécuté ;
invalidation du contexte pour les CPU exécutant des threads du processus ;
vidage du contexte à partir des TLB de toutes les CPU exécutant des threads du processus.
Cette procédure est d'autant plus coûteuse que le nombre de processus est élevé (notamment lorsqu'il dépasse 8 Ko). L'évolutivité du comptage de processus a permis de redéfinir complètement la gestion du contexte. Les contextes sont gérés non pas de façon globale, mais par MMU. Le vidage TLB est ainsi plus efficace et la gestion du contexte offre des possibilités d'évolution beaucoup plus intéressantes.
L'évolutivité du comptage de processus améliore également le rendement des charges de travail constituées de processus actifs dépassant 8 Ko ou ayant pour effet de créer et de détruire des processus à haut débit. Elle est plus avantageuse pour les systèmes dotés de nombreuses CPU.
Grâce à la fonction MPSS (Multiple Page Size Support, prise en charge de plusieurs tailles de page) pour mémoire partagée, les grandes pages sont prises en charge pour le mappage de mémoire partagée et une politique OOB (Out-Of-Box, prêt à l'emploi) est à votre disposition afin d'utiliser de grandes pages pour la mémoire partagée. La prise en charge MPSS est destinée aux mémoires partagées créées à l'aide de la commande mmap(1) de /dev/zero ou à l'aide de l'indicateur MAP_ANON, ainsi qu'aux mémoires partagées System V. Grâce à cette fonction, il est également possible de modifier la taille de page de ces segments de mémoire partagée à l'aide de la commande memcntl(2).
En outre, la prise en charge MPSS a été étendue afin de permettre l'utilisation de grandes pages lorsque la mémoire est créée à l'aide de commande mmap(1), mmap(MAP_PRIVATE) de /dev/zero.
Les fonctionnalités et améliorations de gestion des périphériques suivantes ont été ajoutées à la version Solaris 10 8/07.
Depuis cette version, il existe un nouveau mécanisme de réservation dans le pilote st. Ce nouveau mécanisme permet au pilote st de réserver le lecteur de bande uniquement en cas d'envoi d'une commande de réservation. Il permet également au pilote st de traiter les commandes de demande de processus émises par d'autres hôtes alors que le lecteur est réservé par un hôte différent.
Certains outils de gestion de médias et logiciels de sauvegarde des éditeurs de logiciels indépendants tirent profit de la fonction de réservation SCSI st évoluée. Grâce à elle, les outils de gestion sont en mesure d'interroger et de consulter les bibliothèques de bandes lorsque l'outil de sauvegarde lit ou écrit des données sur bande.
Cette fonctionnalité introduit deux nouveaux mots-clés power.conf afin de gérer l'énergie des périphériques CPU de façon individuelle. Voici les nouveaux mots-clés power.conf :
cpupm
Utilisation :
cpupm <behavior> |
Le comportement est soit enable (activer), soit disable (désactiver).
Pour la compatibilité ascendante, si le mot-clé cpupm ne se trouve pas dans le fichier /etc/power.conf, les CPU sont alimentées si et seulement si autopm est activé. enable ou disable sont indépendants du paramètre autopm.
cpu-threshold
Utilisation :
cpu-threshold <threshold> |
Ce mot-clé permet à l'utilisateur de définir un seuil qui s'appliquera à toutes les CPU à gestion d'énergie, indépendamment de la valeur de seuil système.
Si la fonction de gestion d'énergie des CPU est activée, le niveau d'alimentation des CPU inactives pour le seuil spécifié passe au niveau inférieur le plus proche.
En cas d'omission de cpu-threshold, c'est le seuil système qui prend effet.
Pour plus d'informations, reportez-vous à la page de manuel power.conf(4).
Les amélioration de sous-système de console suivantes ont été ajoutées à la version Solaris 10 8/07.
Elle implémente une portion du sous-système de console de noyau afin de faciliter la sortie sur la console de rendu. La console cohérente fait appel aux mécanismes de noyau Solaris pour le rendu de la sortie de la console au lieu des interfaces de mémoire morte programmable PROM (Programmable Read-Only Memory). La dépendance du rendu de console par rapport à la mémoire morte programmable OnBoot PROM (OBP) est donc d'autant moins grande.
La console cohérente utilise un pilote framebuffer résidant dans le noyau pour générer la sortie de la console. Ce type de sortie est plus efficace que le rendu OBP. La console cohérente évite les temps d'inactivité de la CPU pendant la sortie de la console SPARC, avantage non négligeable pour l'utilisateur.
Elle augmente, par exemple, la vitesse de défilement et la capacité de traitement du texte de la console SPARC et offre des couleurs ANSI.