Réseaux

Cette section décrit toutes les nouvelles fonctions et les améliorations de Solaris 10 3/05 en matière de mise en réseau, par rapport à la première distribution du système d'exploitation Solaris 9 en mai 2002.

Sélection de l'adresse source IP virtuelle

Cette fonction a été introduite dans la version 3/05 de Solaris 10.

La sélection de l'adresse source IP virtuelle permet à un administrateur système d'indiquer l'adresse source IP à utiliser pour les paquets qui sont acheminés par le biais d'une interface réseau particulière. Il est possible d'héberger cette adresse source sur l'interface réseau virtuelle (vni) qui vient d'être introduite et qui s'avère être immunisée contre des pannes matérielles. Ou alors, il est possible d'héberger l'adresse source sur l'interface de bouclage.

La sélection d'adresse source IP virtuelle peut être utilisée conjointement avec les protocoles de routage IP afin de fournir un multiacheminement (c'est-à-dire, la redondance) au niveau de la couche réseau au-delà du premier routeur. Actuellement, ce type de multiacheminement fonctionne conjointement avec le protocole de routage RIPv2 disponible dans le démon in.routed.

Pour plus d'informations sur la fonction de sélection d'adresse source IP virtuelle, reportez-vous aux pages de manuel ifconfig(1M) et vni(7d).

Protocole de la transmission du contrôle des flux

Ces améliorations ont été introduites dans Solaris Express 8/04.

Le protocole SCTP (Stream Control Transmission Protocol) est un protocole de transport fiable qui est désormais intégré à la pile de protocole TCP/IP du système d'exploitation Solaris. Le protocole SCTP propose des services semblables à ceux du protocole TCP. Toutefois, il prend en charge les connexions entre des points de terminaison multiconnexion, c'est-à-dire comportant plusieurs adresses IP. Grâce à la prise en charge multiconnexion, le protocole SCTP devient un protocole de transport fréquemment utilisé pour les applications de téléphonie. Le protocole SCTP prend également en charge les flux multiples et une fiabilité partielle.

Le protocole SCTP ne nécessite aucune configuration supplémentaire après l'installation du système d'exploitation Solaris 10. Toutefois, il est possible que des définitions de service supplémentaires soient nécessaires afin que des applications particulières puissent être exécutées avec le protocole SCTP.

Pour plus d'informations sur la configuration du protocole SCTP, reportez-vous au Guide d’administration système : services IP.

Suite de routage multiprotocole Zebra

Ces améliorations ont été introduites dans Solaris Express 8/04.

Le système d'exploitation Solaris 10 inclut désormais la suite de routage multiprocole Zebra. Cette suite inclut le logiciel de routage Open Source Zebra 0.92a avec des correctifs pour les plates-formes Sun. Désormais, les administrateurs système peuvent utiliser les protocoles de routage libres et fréquemment utilisés RIP, BGP et OSPF pour la gestion de leurs réseaux Solaris. De plus, le démon OSPF peut être utilisé afin d'offrir une disponibilité de réseau maximale sur les serveurs multiconnexion. Les packages Zebra contiennent ces protocoles ainsi que l'outil d'administration zebraadm.

Reportez-vous au fichier /etc/sfw/zebra/README.Solaris pour plus d'informations, notamment sur la configuration.

Passage de la translation d'adresses et IPsec

Ces améliorations ont été introduites dans Solaris Express 8/04.

Le protocole IKE peut désormais initier des associations de sécurité IPsec à partir d'une zone de translation d'adresses. Seul le protocole ESP sur un réseau IPv4 est autorisé. De plus, les associations de sécurité IPsec pour le trafic qui traverse une translation d'adresses ne peuvent pas être accélérées avec la carte Solaris Crypto Accelerator 4000. Cela n'affecte pas l'accélération du protocole IKE.

Pour plus d'informations, reportez-vous à la page de manuel ipseckey(1M).

Améliorations apportées au Démon nfsmapid

Cette fonction a été introduite dans la version 8/04 de Solaris Express et mise à jour dans la version 3/05 de Solaris 10.

Dans la version 4 de NFS, le démon nfsmapid fournit un mappage à partir d'un ID utilisateur ou d'un identificateur de groupe numérique vers une chaîne, et inversement. La chaîne est utilisée par la version 4 du protocole NFS pour représenter owner ou owner_group.

Par exemple, l'ID 123456 de l'utilisateur, known_user, qui fonctionne sur un client appelé system.anydomain.com, serait mappé vers known_user@anydomain.com. Le client NFS envoie la chaîne known_user@anydomain.com au serveur NFS. Le serveur NFS mappe la chaîne, known_user@anydomain.com, à l'ID unique 123456 de l'utilisateur. nfsmapid utilise les entrées passwd et group dans le fichier /etc/nsswitch.conf de manière à déterminer la base de données à consulter pour les mappages.

Pour le bon fonctionnement du démon nfsmapid, les clients et les serveurs de la version 4 de NFS doivent avoir le même domaine. Pour s'assurer que les clients et les serveurs possèdent le même domaine, le démonnfsmapid configure le domaine en suivant uniquement ces règles de priorité :

• Il vérifie d'abord le fichier /etc/default/nfs pour une valeur attribuée au mot-clé NFSMAPID_DOMAIN. Si une valeur est trouvée, celle attribuée est prioritaire sur tous les autres paramètres. La valeur attribuée est ajoutée aux chaînes des attributs sortants et est comparée aux chaînes des attributs entrants.

• Si aucune valeur n'a été attribuée au mot-clé NFSMAPID_DOMAIN, le démon recherche un nom de domaine dans l'enregistrement DNS TXT sur un serveur de noms DNS. Pour rechercher un enregistrement DNS spécifique, le démon nfsmapid se base sur le fichier de configuration resolv.conf(4).

• Si aucun enregistrement DNS TXT ne comporte de nom de domaine, le démon nfsmapid utilise alors par défaut le domaine DNS local.

Il est préférable d'utiliser des enregistrements DNS TXT. Configurez l'enregistrement TXT _nfsv4idmapdomain sur les serveurs fournissant des domaines pour les clients et les serveurs de la version 4 de NFS. Les enregistrements TXT offrent une meilleure assistance pour les problèmes relatifs à la mise à l'échelle et fournissent un point de contrôle unique.

Si le réseau comprend plusieurs domaines DNS mais dispose d'un seul espace de noms pour l'ID utilisateur et l'ID de groupe, tous les clients doivent utiliser une seule valeur pour NFSMAPID_DOMAIN. Pour les sites utilisant DNS, nfsmapid résout ce problème en obtenant le nom de domaine à partir de la valeur attribuée à _nfsv4idmapdomain. Si le réseau n'est pas configuré pour utiliser DNS, lors de la première initialisation du système, le SE Solaris utilise l'utilitaire sysidconfig(1M) afin de générer des invites pour le nom de domaine de NFS version 4.

Pour plus d'informations, reportez-vous aux pages de manuel nfsmapid(1M) et sysidtool(1M). Consultez également le System Administration Guide: Network Services .

sendmail version 8.13

Intégrée dans Solaris Express 8/04, la fonctionnalité sendmail version 8.13 est utilisée par défaut dans le système d'exploitation Solaris 10. Bien que cette nouvelle version de sendmail propose de nombreuses nouveautés, l'option FallBackSmartHost constitue le nouvel élément le plus important.

Grâce à l'option FallBackSmartHost, il n'est plus nécessaire d'utiliser les fichiers main.cf et subsidiary.cf. Le fichier main.cf était utilisé dans des environnements qui prenaient en charge les enregistrements MX. Le fichier subsidiary.cf, quant à lui, était employé dans des environnements sans DNS entièrement opérationnel. Dans ce type d'environnement, un hôte intelligent était utilisé à la place des enregistrements MX.

L'option FallBackSmartHost propose une configuration unifiée. Elle agit comme un enregistrement MX de la dernière préférence possible pour tous les environnements. Pour s'assurer que les messages ont été envoyés aux clients, cette option, lorsqu'elle est activée, fournit un hôte connecté de façon appropriée, ou “intelligent”, qui est utilisé en tant que sauvegarde ou reprise après incident en cas de problème avec les enregistrements.

sendmail version 8.13 comporte également les nouveautés suivantes :

• options de ligne de commande supplémentaires ;

• options de fichier de configuration supplémentaires et révisées ;

• déclarations d'OPTIONS supplémentaires et révisées.

Pour plus d'informations, reportez-vous au System Administration Guide: Network Services .

sendmail version 8.12 utilise des wrappers TCP.

Cette fonction a été introduite dans la version 9/03 de Solaris Express.

Dans Solaris Express 8/04, sendmail version 8.13 est la version par défaut. Reportez-vous à la rubrique sendmail version 8.13.

Les wrappers TCP permettent d'implémenter des contrôles d'accès en vérifiant à l'aide d'une liste de contrôles d'accès les adresses d'un hôte demandant un service réseau particulier. Les demandes sont accordées ou refusées en conséquence. Non seulement les wrappers TCP fournissent ce système de contrôle des accès mais ils consignent également les demandes hôte de services réseau, offrant ainsi une fonction de surveillance utile. Les services réseau pouvant être soumis à un contrôle des accès incluent par exemple rlogind, telnetd et ftpd.

Dans cette version de Solaris, la version 8.12 de sendmail permet désormais l'utilisation des wrappers TCP. Cette vérification n'élimine pas les autres mesures de sécurité. Avec l'activation des wrappers TCP dans sendmail, une nouvelle vérification permettant de valider la source d'une demande de service réseau avant tout accord à la demande a été ajoutée. Reportez-vous à la page de manuel hosts_access(4).

Solaris 9 a inclus la prise en charge des wrappers TCP dans inetd(1M) et sshd(1M).

Sun Java System Message Queue

Solaris Express 6/04 a introduit Sun Java System Message Queue 3.5 SP1 Platform Edition. Cette fonction est incluse dans la version 3/05 de Solaris 10. Cette version remplace Sun Java System Message Queue (MQ) 3.0.1, qui avait été précédemment introduit dans le programme pilote Software Express.

Pour les utilisateurs de Solaris 9, Message Queue 3.0.1 a été introduit pour la plate-forme SPARC dans Solaris 9 version 12/02. Dans Solaris 9 8/03, cette fonction était disponible pour la plate-forme x86.

Sun Java System Message Queue 3.5 SP1 Platform Edition est un système de messagerie économique, haute performance, basé sur les standards du marché, qui permet d'intégrer des systèmes informatiques hétérogènes. Ce programme Message Queue (MQ) est compatible avec Java Messaging Services (JMS) 1.1 et prend en charge la gestion des messages de services Web via JAXM (SOAP 1.1 with Attachments).

Par rapport à la version 3.0.1 précédente, la nouvelle version 3.5 offre les nouvelles fonctions suivantes :

• API C de messagerie – API C native-câble pour la connectivité avec les applications C/C++ existantes. Les transports TCP et SSL sont pris en charge.

• Bascule de la connexion du client – En cas de perte de la connexion, le client se reconnecte automatiquement à un autre courtier de la grappe.

• Fonctions avancées de surveillance à distance – L'API basée sur JMS permet la surveillance des statistiques relatives aux courtiers, aux destinations et à VM.

• Prise en charge de Sun Cluster dans Java Enterprise System – Sun Cluster Agent pour MQ, disponible dans Java Enterprise System, utilise un magasin de données haute disponibilité à base de fichiers qui fournit à MQ des fonctionnalités de haute disponibilité.

• Compatibilité J2EE 1.4 – La prise en charge de J2EE Connector Architecture 1.5 permet d'associer MQ 3.5 à tout serveur d'application compatible J2EE 1.4 via l'adaptateur de ressources MQ.

• Contrôle dynamique de flux de messages – Le contrôle de flux permet de gérer la capacité de traitement et la charge du système. Les options de contrôle comprennent : Refus du plus ancien, Refus du plus récent, Refus de la priorité basse et Contrôle du flux.

• Destinations locales et règles de distribution de cluster – La configuration des règles permet d'optimiser la capacité de traitement pour la livraison des messages aux courtiers dans un cluster.

Pour plus d'informations sur les nouvelles fonctions, reportez-vous au Notes de version de Sun Java System Message Queue sur le site http://docs.sun.com.

Sun Java System Application Server

Sun Java System Application Server Platform Edition 8 a été introduit dans Solaris Express version 6/04. Cette fonction est incluse dans la version 3/05 de Solaris 10.

Auparavant, Sun Java System Application Server 7 avait été intégré dans le programme pilote de Software Express pour les plates-formes SPARC et dans Solaris Express version 9/03 pour les plates-formes x86. Sun Java System Application Server Platform Edition 8 remplace Edition 7 dans Solaris Express 6/04.

Pour les utilisateurs de Solaris 9, la version 7 d'Application Server a été intégrée pour les plates-formes SPARC dans Solaris 9 version 12/02 et pour les plates-formes x86 dans Solaris 9 version 12/03. .

Sun Java System Application Server Platform Edition 8 est le conteneur d'applications compatibles J2EE 1.4 de Sun Microsystems qui est conçu pour les développeurs et les déploiements par divisions.

Cette édition fournit les fonctions suivantes :

• Compatibilité J2EE 1.4 – Prend en charge les normes les plus récentes de la technologie J2EE et garantit la portabilité des applications.

• Prise en charge intégrée de JavaServer Faces – Permet aux développeurs d'utiliser la toute dernière technologie de couche présentation, JavaServer ^TM Faces.

• Interface graphique de l'administrateur et visionneuse du journal – Fournit un système d'affichage et de recherche pour la visionneuse du journal, améliorant ainsi la productivité de l'administrateur.

• Deploytool – Cet outil basé sur l'interface graphique fournit des éditeurs de texte permettant aux développeurs d'assembler des composants J2EE et de déployer des applications J2EE.

• Amélioration de la productivité des développeurs – Ces améliorations destinées à accroître la productivité des développeurs comprennent la réduction du nombre de processus, de l'encombrement de mémoire, l'augmentation de la vitesse de démarrage du serveur et du déploiement.

Pour consulter les informations importantes sur ce produit, reportez-vous aux informations produit de Sun Java System Application Server, à l'adresse http://www.sun.com/software/. Pour plus de détails sur les nouvelles fonctions, reportez-vous aux Sun Java System Application Server Platform Edition 8 Release Notes, sur le site http://docs.sun.com.

Utilisation de CacheFS avec NFS version 4

Cette fonction est toute nouvelle dans Solaris Express version 6/04.

Le système de fichiers cache, CacheFS^TM, est un système de mise en cache générique non volatile. CacheFS améliore la performance de certains systèmes de fichiers par l'utilisation d'un petit disque local rapide. Vous pouvez améliorer la performance de l'environnement NFS en utilisant CacheFS.

CacheFS fonctionne différemment selon les versions de NFS. Par exemple, si le client et le système de fichiers d'arrière-plan exécutent la version 2 ou la version 3 de NFS, les fichiers sont mis en cache dans le système de fichiers de premier plan auquel le client peut accéder. Toutefois, si le client et le serveur exécutent NFS version 4, cette fonction est la suivante. Lorsque le client effectue la demande initiale d'accès à un fichier à partir d'un système de fichiers CacheFS, la demande n'est pas adressée au système de fichiers de premier plan (ou mis en cache) et accède directement au système de fichiers d'arrière-plan. Avec NFS version 4, les fichiers ne sont plus mis en cache dans le système de fichiers de premier plan. Tous les accès aux fichiers sont fournis par le système de fichiers d'arrière-plan. De même, aucun fichier n'étant mis en cache dans le système de fichiers de premier plan, les options de montage spécifiques de CacheFS, qui doivent normalement s'appliquer au système de fichiers de premier plan, ne sont pas prises en compte. Les options de montage spécifiques de CacheFS ne s'appliquent pas au système de fichiers d'arrière-plan.

La première fois que vous configurez votre système pour NFS version 4, un message d'avertissement apparaît sur la console vous indiquant que la mise en cache n'est plus effectuée.

Pour plus d'informations sur NFS version 4, reportez-vous au System Administration Guide: Network Services .

Amélioration de l'utilitaire vacation

Cette fonction a été introduite dans la version 5/04 de Solaris Express.

L'utilitaire vacation a été amélioré pour permettre à un utilisateur de spécifier les messages entrants qui reçoivent des réponses générées automatiquement. Grâce à cette amélioration, l'utilisateur peut éviter de partager des informations confidentielles ou de contact avec des personnes inconnues. Les messages provenant d'“expéditeurs de courriers indésirables” ou de personnes inconnues ne reçoivent pas de réponse.

Le principe consiste à comparer l'adresse e-mail d'un émetteur de message entrant avec une liste de domaines ou d'adresses e-mail dans un fichier .vacation.filter. Ce fichier est créé par l'utilisateur et situé dans le répertoire personnel de l'utilisateur. Si une correspondance de domaine ou d'adresse est trouvée, une réponse est envoyée. Dans le cas contraire, aucune réponse n'est envoyée.

Pour plus d'informations, reportez-vous à la page de manuel vacation(1).

MILTER, nouvelle API de filtre de courrier de sendmail

Cette fonction a été introduite dans la version 4/04 de Solaris Express.

MILTER, nouvelle API de filtre de courrier de sendmail, permet à des programmes tiers d'accéder aux messages en cours de traitement pour le filtrage des méta-informations et du contenu. Cette fonctionnalité, introduite dans la version 3/05 de Solaris 10, requiert les éléments suivants :

• sendmail binaire à compiler avec -DMILTER, qui est disponible depuis Solaris 9 ;

• le fichier /usr/lib/libmilter.so présent dans le système Solaris 10 ;

• les fichiers /usr/include/libmilter/mfapi.h et /usr/include/libmilter/mfdef.h.

  Ces deux fichiers sont inclus dans le système Solaris 10.

Ainsi, avec Solaris 10 version 3/05, l'utilisateur peut créer le filtre et configurer la commande sendmail pour l'utiliser.

Pour de plus amples informations sur la commande sendmail, reportez-vous au System Administration Guide: Network Services .

API sockets avancée IPv6

Cette fonction a été introduite dans la version 1/04 de Solaris Express.

L'API Advanced Sockets met à jour l'API Solaris Sockets de sorte qu'elle soit en conformité avec la version actuelle du document RFC 2292. L'API avancée fournit la fonction nécessaire à la manipulation des paquets ICMP, à l'obtention des informations de l'interface et à la manipulation des en-têtes IPv6.

Pour de plus amples informations, reportez-vous au Programming Interfaces Guide .

Le contenu de /usr/lib/mail a été transféré vers /etc/mail/cf

Cette fonction a été introduite dans la version 1/04 de Solaris Express.

Le contenu du répertoire /usr/lib/mail, qui peut être un système de fichiers en lecture seule, se trouve maintenant dans le répertoire /etc/mail/cf, qui est accessible en écriture. Cette modification permet une meilleure prise en charge de m4. Notez, toutefois, les exceptions suivantes : Les scripts de shell /usr/lib/mail/sh/check-hostname et /usr/lib/mail/sh/check-permissions se trouvent désormais dans le répertoire /usr/sbin. Pour garantir la compatibilité ascendante, des liens symboliques pointent vers le nouvel emplacement de chaque fichier.

Pour de plus amples informations, reportez-vous au System Administration Guide: Network Services .

Fonctionnalité IPv6 ajoutée lors de l'installation de Solaris

Cette fonction a été introduite dans la version 11/03 de Solaris Express.

Plusieurs nouvelles fonctions IPv6 sont démarrées lorsque vous sélectionnez Activer IPv6 lors de l'installation de Solaris.

• Les règles du fichier /etc/nsswitch.conf pour la base de donnée des hôtes et les référentiels des ipnodes sont synchronisées de manière que la recherche des ipnodes et des hôtes s'effectue dans les mêmes référentiels d'attribution de noms. Désormais, les hôtes peuvent résoudre les adresses IPv6 situées dans n'importe quel référentiel d'ipnodes.

• La sélection de l'adresse de destination a été modifiée pour éviter l'utilisation d'une adresse IPv6 pour un hôte distant si cet hôte n'est desservi par aucune route IPv6. Une adresse IPv4 est utilisée à la place pour éviter tout délai lors de la connexion à des hôtes distants.

  Par exemple, prenons le cas d'un hôte compatible sur un réseau ne disposant pas de routeur IPv6. Sans routeur, un hôte n'a pas connaissance des routes IPv6 présentes au-delà de la liaison locale. Auparavant, l'hôte rencontrait des problèmes de délai d'attente lors des tentatives de connexion à une adresse IPv6 préférée. Avec la nouvelle fonction de sélection de l'adresse de destination, l'hôte utilise de préférence une adresse de destination IPv4. Cette fonction élimine les problèmes de délai d'attente.

Pour de plus amples informations, reportez-vous au Guide d’administration système : services IP.

Adresses temporaires IPv6

Cette fonction a été introduite dans la version 11/03 de Solaris Express.

Par défaut, l'ID d'interface d'une adresse IPv6 est configurée automatiquement avec l'adresse spécifique du matériel de l'interface. Par exemple, si l'interface est une carte Ethernet, son ID d'interface est configurée automatiquement à partir de l'adresse MAC de l'interface. Toutefois, certains administrateurs système peuvent avoir besoin de conserver la confidentialité des adresses spécifiques du matériel d'une ou plusieurs interfaces d'un nœud.

La fonction d'adresses temporaires IPv6 met en œuvre la norme d'extensions de confidentialité définie dans RFC 3041, "Privacy Extensions for Stateless Autoconfiguration in IPv6". Les adresses temporaires permettent aux administrateurs d'assigner aux interfaces d'un nœud IPv6 des ID d'interface au format EUI--64 modifiés et générés aléatoirement. De plus, les administrateurs peuvent spécifier une limite de durée de vie pour une adresse temporaire. Après la configuration, le démon IPv6 in.ndpd génère automatiquement l'ID temporaire pour cette interface, en plus de l'ID d'interface basée sur l'adresse MAC générée automatiquement.

Pour de plus amples informations, reportez-vous au Guide d’administration système : services IP.

Commande routeadm

Cette fonction a été introduite dans la version 9/03 de Solaris Express.

La nouvelle commande routeadm permet aux administrateurs système de configurer le transfert et le routage IP sur toutes les interfaces d'un système. Tout paramètre défini par l'intermédiaire de la commande routeadm remplace les valeurs par défaut du système lues dans les fichiers de configuration pendant l'initialisation.

La commande routeadm fournit des options pour l'activation et la désactivation de la fonction globale de transfert de paquets sur toutes les interfaces IPv4 ou IPv6 d'un système. La commande routeadm peut également être utilisée pour configurer un système en tant que routeur, en activant les démons de routage pour toutes les interfaces système. Dans un environnement IPv6, la commande routeadm peut également être utilisée pour activer ou désactiver le routage dynamique pour un hôte.

Pour de plus amples informations, reportez-vous à la page de manuel routeadm(1M) et au Guide d’administration système : services IP.

transmission de données multiples via TCP

La transmission de données multiples (MDT, Multidata transmit) n'est disponible que pour les systèmes possédant un noyau de 64 bits. Cette fonction a été introduite dans le programme pilote de Software Express et dans la version 8/03 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.

La transmission de données multiples permet à la pile du réseau d'envoyer plusieurs paquets à la fois au pilote du périphérique réseau pendant la transmission. L'utilisation de cette fonction réduit les coûts de traitement par paquet en améliorant l'utilisation de l'unité centrale hôte ou le débit du réseau.

La fonction MDT n'est effective que pour les pilotes de périphériques qui la prennent en charge.

MDT est activée par défaut. MDT peut être désactivée en incluant la ligne suivante dans le fichier /etc/system :

# ndd -set /dev/ip ip_multidata_outbound 0

Pour plus d'informations, reportez-vous aux pages de manuelip(7P) et ndd(1M).

Consultez également le STREAMS Programming Guide .

Option ifconfig router

Cette fonction est nouvelle dans le programme pilote de Software Express. Cette fonction est incluse dans la version 3/05 de Solaris 10.

La nouvelle option de routeur ifconfig vous permet de configurer le transfert de paquets IP sur des interfaces particulières. Les commandes ifconfig router et ifconfig -router activent ou désactivent le transfert de paquets IP, pour respectivement les interfaces IPv4 et IPv6. Cette option de routeur définit l'indicateur d'interface IFF_ROUTER.

Ces nouvelles options remplacent les variables ndd interface-name :ip_forwarding et interface-name:ip6_forwarding pour configurer le transfert IP sur toutes les interfaces d'un système. Bien qu'elles soient devenues obsolètes, les variables ndd ont été conservées dans cette version de Solaris pour des raisons de compatibilité ascendante. Vous pouvez continuer à utiliser les commandes ip_forwarding et ip6_forwarding sans le préfixe nom-interface pour configurer le transfert IP sur toutes les interfaces d'un système.

Pour des informations détaillées, reportez-vous aux pages de manuel ifconfig(1M), ip(7P) et ip6(7P).

Sélection des adresses par défaut IPv6 (Internet Protocol Version 6)

Cette fonction est nouvelle dans le programme pilote de Software Express. Cette fonction est incluse dans la version 3/05 de Solaris 10.

Le système d'exploitation Solaris 10 fournit un algorithme documenté et déterminant pour la sélection des adresses source et de destination par défaut IPv6. Cette fonction offre aux administrateurs système la possibilité limitée de modifier la priorité de sélection des adresses grâce à l'utilisation d'une table de règles.

La fonction de sélection des adresses IPv6 par défaut est une méthode standardisée de sélection des adresses source et de destination IPv6.

Les mécanismes de sélection peuvent être configurés à l'aide d'une table de règles. Par exemple, vous pouvez modifier la table de règle pour donner une priorité supérieure à un préfixe d'adresse déterminé. Par la suite, les adresses situées dans ce préfixe seront triées avant les autres adresses par API de recherche de nom. Vous pouvez également affecter des étiquettes aux préfixes de destination et de source dans la table des règles. L'affectation de ces étiquettes garantit que des adresses source déterminées sont utilisées uniquement avec des adresses de destination déterminées.

Pour permettre l'implémentation de la sélection des adresses par défaut IPv6, le système d'exploitation Solaris comprend désormais le fichier /etc/inet/ipaddrsel.conf et la commande /usr/sbin/ipaddrsel. La commande ipaddrsel.conf permet de modifier la table des règles d'adresses par défaut IPv6. Ensuite, la commande ipaddrsel permet de valider les modifications apportées à la table des règles.

De plus, la commande ifconfig inclut désormais l'option “préférée”. Cette option vous permet de désigner une adresse déterminée comme adresse source pour toutes les communications IPv6.

Pour des informations détaillées, reportez-vous aux pages de manuel ipaddrsel.conf(4), ipaddrsel(1M) et ifconfig(1M).

Pour de plus amples informations, reportez-vous au Guide d’administration système : services IP.

Désactivation des services NFS et de montage automatique

Cette fonction est nouvelle dans le programme pilote de Software Express. Cette fonction est incluse dans la version 3/05 de Solaris 10.

Les démons NFS suivants sont généralement démarrés par défaut lors de l'initialisation par les scripts rc : nfsd, mountd, statd, lockd et le démon de montage automatique, automountd. Désormais, si une machine ne requiert pas les services NFS et de montage automatique, les scripts ne démarrent pas les démons NFS ni le démon de montage automatique.

Le nouveau comportement à l'initialisation est décrit ci-dessous :

• L'utilitaire automount, qui est appelé par /etc/init.d/autofs, démarre désormais automountd lors de l'initialisation uniquement si les tables de montage automatique comportent une entrée valide.

• /etc/init.d/nfs.server démarre mountd, nfsd, statd et lockd lors de l'initialisation uniquement si la machine comporte des exportations NFS.

• /etc/init.d/nfs.client démarre statd et lockd uniquement si /etc/vfstab contient des systèmes de fichiers NFS.

Les services NFS et de montage automatique ne sont pas nécessairement démarrés lors de l'initialisation. Les commandes suivantes permettent de démarrer ces services lorsque ceux-ci sont requis par une machine :

• L'utilitaire automount permet de démarrer le démon automountd.

• La commande mount avec l'option -F nfs permet de démarrer les démons lockd et statd. Le démon automountd permet également de démarrer lockd et statd.

• La commande share avec l'option -F nfs peut démarrer les démons nfsd, mountd, lockd et statd.

Ce mécanisme de désactivation des services NFS et de montage automatique offre les avantages suivants :

• une sécurité accrue car l'exécution superflue de démons sur une machine peut être ainsi évitée ;

• une procédure simplifiée pour l'exportation de systèmes de fichiers. Les démons nfsd et mountd, et si nécessaire, lockd et statd, sont démarrés par la commande share avec l'option -nfs. Ainsi, il n'est plus nécessaire de modifier le fichier /etc/dfs/dfstab puis d'appeler le programme /etc/init.d/nfs.server . Ce nouveau comportement permet de configurer une exportation NFS à l'aide d'une seule commande, sans modifier de fichiers de configuration. Toutefois, en cas de redémarrage du système, ces exportations ne sont pas reprises automatiquement, sauf si elles sont incluses dans le fichier /etc/dfs/dfstab.

Pour de plus amples informations, reportez-vous aux pages de manuel mountd(1M), lockd(1M), statd(1M) et nfsd(1M).

Pour de plus amples informations, reportez-vous également au System Administration Guide: Network Services .

IPv 6 : routeurs 6to4

Cette fonction est nouvelle dans le programme pilote de Software Express et dans la version 4/03 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.

Les réseaux IPv6 (Internet Protocol Version 6) peuvent désormais transférer des paquets via les réseaux IPv4 (Internet Protocol Version 4) grâce à la configuration d'un ou de plusieurs routeurs capables de prendre en charge un tunnel 6to4. Les administrateurs système peuvent utiliser des tunnels 6to4 pour assurer la migration de leurs réseaux de IPv4 vers IPv6. Cette fonction met en oeuvre les RFC 3056 et 3068.

Pour de plus amples informations sur IPv6, reportez-vous au Guide d’administration système : services IP.

Mise sous tunnel de paquets via IPv6

Cette fonction est nouvelle dans le programme pilote de Software Express et dans la version 9/02 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.

Cette fonction active la mise sous tunnel de paquets IPv4 et IPv6 via IPv6. Les paquets IPv4 et IPv6 peuvent être encapsulés dans des paquets IPv6.

Pour de plus amples informations, reportez-vous au Guide d’administration système : services IP.

Hébergement de plusieurs sites Web sur une même machine Solaris

Cette fonction est nouvelle dans le programme pilote de Software Express et dans la version 12/02 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.

Le module du noyau NCA (Network Cache and Accelerator) de Solaris prend désormais en charge les instances multiples d'un serveur Web. Cela permet d'utiliser une machine Solaris dans le cadre de l'hébergement virtuel de sites Web basé sur une adresse IP. Solaris utilise un seul fichier de configuration, /etc/nca/ncaport.conf pour mapper les sockets NCA vers des adresses IP.

Pour plus d'informations, reportez-vous à la page de manuel ncaport.conf(4).

IP Quality of Service (qualité de service IP)

Cette fonction est nouvelle dans le programme pilote de Software Express et dans la version 9/02 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.

IPQoS (Qualité de service IP) est une nouvelle fonction du système d'exploitation Solaris qui permet aux administrateurs système de fournir différents niveaux de service réseau tant aux clients qu'aux applications stratégiques. Grâce à l'IPQoS, l'administrateur peut mettre en place des accords de niveau de service qui proposent aux clients d'un ISP différents niveaux de service en fonction d'une échelle de prix. Une entreprise peut ainsi utiliser la fonction IPQoS pour classer les applications par ordre de priorité de sorte que les applications stratégiques bénéficient d'un service d'une qualité supérieure à celui dont disposent les applications de moindre importance.

Pour de plus amples informations, reportez-vous au Guide d’administration système : services IP.

Sélecteur utilisateur pour IPQoS

Cette fonction a été introduite dans le programme pilote de Software Express et dans la version 8/03 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.

La fonction IPQoS de Solaris inclut désormais le sélecteur utilisateur, qui complète le sélecteur uid existant. Il permet de spécifier un nom d'utilisateur ou une ID utilisateur comme critère de filtre dans le fichier ipqosconf. Auparavant, le sélecteur uid n'acceptait qu'une valeur pour l' ID utilisateur. La clause de filtrage ci-dessous d'un fichier ipqosconf affiche le sélecteur utilisateur :

filter {
        name myhost;
        user root;
}

Pour de plus amples informations sur les filtres et les sélecteurs, reportez-vous à la page de manuel ipqosconf(1M).

Voir aussi le Guide d’administration système : services IP.

RIPv2 (Routing Information Protocol Version 2)

Cette fonction est nouvelle dans le programme pilote de Software Express et dans la version 9/02 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.

Le logiciel système Solaris prend désormais en charge le protocole RIPv2.

Ce protocole ajoute les extensions CIDR (Classless Inter-Domain Routing) et VLMS (Variable-Length Subnet Mask) au protocole RIPv1. Les extensions MD5 protègent les routeurs des erreurs d'acheminement volontaires d'utilisateurs mal intentionnés. La nouvelle implémentation in.routed contient également un mécanisme ICMP Router Discovery (RFC 1256) intégré.

RIPv2 prend en charge la multidiffusion, si cette dernière est activée au niveau des liaisons point-à-point, ainsi que la diffusion individuelle. Si vous configurez une adresse de diffusion à l'aide du fichier /etc/gateways , RIPv2 prend en charge la diffusion.

Pour de plus amples informations sur la procédure de configuration de RIPv2, consultez les pages de manuel in.rdisc(1M), in.routed(1M) et gateways(4).