Livre blanc Windows Services for UNIX 3.5Dernière mise à jour le 22 avril 2004
Télécharger la version SFU 3.5Charlie Russel Microsoft MVP pour l’interopérabilité Windows Server 2003 Résumé Microsoft® Windows® Services for UNIX (SFU) 3.5 offre un large éventail de services réseau inter-plate-forme pris en charge et totalement intégrés, destinés aux clients professionnels qui doivent intégrer des environnements Windows et UNIX. Il permet à ces clients d’accéder de manière transparente aux informations stockées dans plusieurs plates-formes, consolide la gestion réseau entre plates-formes et réutilise les applications et scripts UNIX sous Windows. Ce livre blanc étudie les fonctionnalités de SFU 3.5 et s’adresse à l’administrateur système, au développeur ou à l’intégrateur d’un réseau mixte UNIX et Windows. Sur cette page
IntroductionDepuis son introduction en 1999, Microsoft® Windows® Services for UNIX (SFU) a joué un rôle majeur pour ceux qui souhaitent faire cohabiter le mieux possible les réseaux Windows et UNIX. Lorsque Windows Services for UNIX 3.0 a été publié en 2002, Microsoft a ajouté de nouvelles fonctionnalités significatives via l’ajout de la technologie Interix, un environnement complet d’application et de script UNIX qui s’exécute en tant que sous-système Windows natif. Avec la publication de Windows Services for UNIX 3.5 en 2004, Microsoft améliore son ensemble d’outils d’interopérabilité en ajoutant à Interix la prise en charge de l’internationalisation et un ensemble d’API de pthread, afin d’étendre sa suite d’interopérabilité. Avec SFU 3.5, Microsoft a étendu le kit SDK Interix afin de prendre en charge les applications à threads tout en mettant à jour les utilitaires et les API afin de prendre en charge l’internationalisation. La prise en charge du système de fichiers réseau (NFS) a également été étendue afin d’améliorer l’authentification dans les environnements Microsoft Windows Server™ 2003 Active Directory® natifs. Nouvelles fonctionnalités SFU 3.5Microsoft a beaucoup investi pour améliorer les performances de SFU. Par exemple, le sous-système Interix comporte des améliorations dans tous les aspects des performances, allant d’améliorations de 30 % des performances fork et exec, à des améliorations de 75 % en termes de bande passante de canaux, en passant par des améliorations plus de 100 % dans les E/S de fichiers et plus de 150 % en termes de latence fstat. L’écart entre les performances des E/S de fichiers et celles du sous-système Win32 ne dépasse plus 10 %. D’autres améliorations ont également été apportées en termes d’évolutivité multiprocesseur. Des améliorations substantielles des performances ont également été apportées dans les composants Serveur pour NFS et Serveur pour NIS de SFU. Windows Services for UNIX 3.5 fonctionne avec un large éventail de plates-formes UNIX et Linux, via des protocoles et utilitaires standard. Il a été testé explicitement pour l’interopérabilité avec Solaris 7, Solaris 8, HP-UX 11, AIX 5L 5.2 et Red Hat Linux 8.0. Windows Services for UNIX 3.5 fonctionne sous Microsoft® Windows 2000 (versions Professionnel et Server), Microsoft® Windows XP Professionnel et Windows Server 2003. Windows Services for UNIX 3.5 ajoute des fonctionnalités et améliorations significatives à la gamme des produits Windows Serveur et représente une avancée majeure en termes d’interopérabilité des scripts et des programmes. Le tableau 1 récapitule les principales nouvelles fonctionnalités de Windows SFU 3.5 depuis la version SFU 2.0. Tableau 1. Fonctionnalités nouvelles et améliorées de SFU 3.5
Nous allons examiner chacun des domaines et améliorations ajoutés depuis la version SFU 2.0, puis nous allons nous concentrer sur l’intégration du sous-système Interix. Pourquoi Services for UNIX ?Avec l’adoption croissante du système d'exploitation Windows dans les environnements UNIX existants, la nécessité de l’interopérabilité des deux plates-formes augmente. Windows Services for UNIX 3.5 offre un ensemble de fonctionnalités complémentaires à Windows 2000, Windows XP et Windows Server 2003, permettant une plus grande interopérabilité avec les systèmes basés sur UNIX tout en permettant la migration sous Windows des applications écrites à l’origine pour fonctionner sous UNIX et Linux. Windows Services for UNIX 3.5 offre un éventail complet de composants d’interopérabilité pris en charge et totalement intégrés, ainsi qu’un kit SDK complet prenant en charge plus de 2 000 API UNIX. Windows Services for UNIX 3.5 offre :
Windows Services for UNIX offre quatre scénarios pour le réseau hétérogène UNIX et Windows, qui vous permet de tirer le meilleur parti des deux environnements afin de simplifier et de gérer votre entreprise. Les quatre scénarios sont les suivants :
Dans cette section, nous allons examiner plus en détail les trois premiers scénarios. Dans la section suivante, nous allons examiner comment Windows Services for UNIX peut apporter une valeur ajoutée et améliorer la gestion informatique entre divers environnements en vous permettant d’utiliser sous Windows votre expertise et vos applications UNIX. Utilisation des ressources réseau UNIXWindows Services for UNIX offre quatre outils importants qui vous permettent d’utiliser les ressources réseau UNIX pour vos clients et serveurs Windows tout en permettant à vos clients UNIX d’utiliser les ressources des serveurs Windows. Ces quatre outils sont les suivants :
Gestion et configurationLa console MMC (Microsoft Management Console) Administration de Services for UNIX permet d’administrer les services Client for NFS et Server for NFS, mais pas le service Gateway for NFS. Pour ouvrir la console, vous pouvez soit la lancer à partir du menu Démarrer, soit ouvrir le composant logiciel enfichable Sfumgmt.msc à partir d’une console MMC. Vous pouvez également administrer la plupart des options NFS à partir de la ligne de commande. La syntaxe de ligne de commande complète est disponible en tapant ce qui suit sur la ligne de commande : nfsadmin [client | server | gw] /? Client for NFSLes propriétés que vous pouvez modifier pour Client for NFS sont les suivantes :
Connexion à un export NFSVous pouvez vous connecter à un export NFS de différentes façons en utilisant la syntaxe Windows standard (\\serveur\partage) ou la syntaxe UNIX standard (serveur:/partage). À partir de la ligne de commande, vous pouvez utiliser les commandes réseau Windows standard ou la commande de montage de type UNIX avec l’une ou l’autre de ces syntaxes. Vous pouvez également parcourir le Voisinage réseau dans l’Explorateur. À partir de la ligne de commande, les commandes suivantes sont équivalentes : net use * server1:/home net use * \\server1\home mount server1:/home * mount \\server1\home * Conseil : lorsque vous êtes certain que vous vous connectez à un export NFS, utilisez la syntaxe UNIX serveur:/partage pour une configuration plus rapide de la connexion. Server for NFSWindows Services for UNIX offre un outil Server for NFS robuste offrant les ressources de disque de vos systèmes Windows 2000, Windows XP et Windows Server 2003 à n'importe quel ordinateur du réseau prenant en charge NFS. Pour administrer Server for NFS, utilisez la console MMC Windows Services for UNIX, ou utilisez nfsadmin à partir de la ligne de commande. À partir de la console MMC Windows Services for UNIX, vous pouvez configurer les options suivantes : Tableau 3. Options de la console
PartagesVous créez les partages via l’Explorateur Windows en sélectionnant l’onglet Partage NFS dans la page Propriétés. Vous pouvez partager des dossiers individuels ou des lecteurs entiers. Pour partager un dossier à partir de l’invite de commande, tapez : nfsshare sharename=lecteur:chemin Où lecteur:chemin est l’emplacement du dossier que vous souhaitez partager. Comme dans UNIX, vous ne pouvez pas partager un sous-dossier d’un partage existant. Pour cette raison, chaque lettre d’unité est traitée comme un répertoire racine distinct. La syntaxe de ligne de commande complète est disponible en tapant ce qui suit sur la ligne de commande : nfsshare /? Permissions de partageLes permissions de partage sont définies par ordinateur client ou par groupe d’ordinateurs. Pour définir les permissions des partages, ouvrez la boîte de dialogue des propriétés du dossier que vous partagez, sélectionnez l'onglet Partage NFS, puis cliquez sur le bouton Permissions. La valeur par défaut est l’accès en lecture seule pour tous les ordinateurs sans accès racine et sans accès anonyme. Permissions de fichiersServer for NFS utilise les droits d’accès Windows des listes de contrôle d’accès discrétionnaires (DACL, Discretionary Access Control Lists) pour simuler les permissions typiques dans les environnements UNIX et NFS. Les permissions par défaut sont lecture/écriture pour tous les utilisateurs. Attention : Il est important de comprendre qu’il existe des ensembles de permissions différents dans les modèles de sécurité UNIX et Windows et que dans certains cas, l’alignement est purement une approximation. Gateway for NFSGateway for NFS peut être installé sur les produits serveur uniquement, c'est-à-dire Windows 2000 Server et Windows Server 2003. Après l’installation, vous pouvez utiliser l’application Partage Gateway for NFS (Gwconfig.exe) pour créer des partages de passerelle. Un partage de passerelle prend une ressource de système de fichiers NFS d’un ordinateur UNIX ou d’un autre serveur NFS et met en correspondance ce système de fichiers NFS avec une lettre d’unité sur un serveur Gateway. La lettre d’unité est ensuite partagée avec les clients Windows partout sur un réseau, via les protocoles SMB (Server Message Block) standard. Les ordinateurs Windows clients n’ont pas besoin de logiciels supplémentaires et voient les partages de passerelles comme s’ils résidaient localement sur le serveur de passerelle. Démarrez l’application Partages Gateway for NFS à partir du groupe de programmes Windows Services for UNIX ou via la ligne de commande. À partir de là, vous pouvez créer un partage de passerelle qui sera disponible pour tous les clients Windows comme s’il s’agissait d’un partage local de l’ordinateur de passerelle. Chaque partage de passerelle utilise une lettre d’unité de l’ordinateur de passerelle, ce qui a pour effet de limiter le nombre de partages au nombre maximum de lettres d’unité disponibles sur l’ordinateur de passerelle. À partir de la ligne de commande, les partages Gateway for NFS sont gérés par l'intermédiaire de l’utilitaire Gwshare.exe. Pour plus d’informations sur l’utilisation de cet utilitaire, consultez l’aide de Windows ou tapez : gwshare /? Conseil : les partages Gateway for NFS sont limités par le nombre de lettres d’unité disponibles sur un serveur Gateway. Cependant, si vous avez besoin de partages supplémentaires au-delà de ce nombre, vous pouvez (et devez) utiliser plusieurs serveurs Gateway pour fournir les partages supplémentaires afin de répartir la charge. Server for PCNFSServer for PCNFS offre la prise en charge PCNFSD. Vous pouvez entrer les informations nécessaires afin de créer des utilisateurs et des groupes en utilisant la console MMC Windows Services for UNIX qui permet à Server for PCNFS de gérer l’authentification des ressources de fichiers NFS pour tous les clients NFS. Remarque : Windows Services for UNIX n’utilise pas PCNFS pour l’authentification et l’utilisation de Server for PCNFS est destinée exclusivement à la prise en charge d’autres clients PCNFS qui nécessitent un serveur PCNFS. Simplification de l’administration réseauWindows Services for UNIX offre des outils Windows importants afin d’améliorer et de simplifier l’administration de votre réseau. Ces outils sont les suivants :
Client TelnetWindows Services for UNIX offre un client Telnet en mode caractère qui va au-delà de celui inclus dans Windows 2000 afin de prendre en charge le mode flux et le mode console. Il offre également la journalisation ainsi que des paramètres (voir la commande set du tableau suivant) et commandes (voir la commande send du tableau suivant) de configuration supplémentaires qui le rendent plus robuste dans un environnement mixte. La configuration Telnet est gérée à partir d’une session Telnet par échappement vers l’invite Telnet. Appuyez sur CTRL + ] (crochet droit) afin d’afficher l’invite Telnet lorsque vous avez démarré une session Telnet. À partir de la, vous pouvez taper ce qui suit. Tableau 4. Commandes Telnet
Conseil : Si vous utilisez le client Telnet essentiellement pour vous connecter à des systèmes UNIX, définissez term sur ANSI et désactivez NTLM. Si vous vous connectez fréquemment à des systèmes Windows et UNIX, ou essentiellement à des systèmes Windows, l’émulation VTNT constitue le meilleur choix et vous pouvez utiliser ANSI lors de la connexion à un système ne prenant pas en charge VTNT. Serveurs TelnetWindows Services for UNIX inclut deux serveurs Telnet, à savoir le serveur Telnet par défaut, basé sur Windows et dont le fonctionnement est similaire à celui inclus avec toutes les versions de Windows depuis Windows 2000, et le démon Interix telnetd, contrôlé par inetd. Un seul de ces serveurs Telnet peut être activé à la fois. Par défaut, aucun serveur Telnet n’est activé, pour des raisons de sécurité. Tel qu’il est installé, le serveur Telnet basé sur Windows fonctionne de manière optimale pour la plupart des installations. Il accepte les ouvertures de session à partir d’un large éventail de clients, y compris les clients Telnet fournis avec Windows 2000, Microsoft Windows NT® et Microsoft Windows 95/98, ainsi qu’un large éventail de clients terminal en mode caractère, de presque n'importe quel système d'exploitation. En outre, il peut être configuré pour satisfaire aux exigences de sites spécifiques afin d’améliorer la sécurité, de simplifier les ouvertures de session, de prendre en charge le mode stream ou console, etc. DifférencesLe serveur Telnet par défaut, basé sur Windows, doit être familier pour les utilisateurs de Windows 2000, Windows XP et Windows Server 2003. Il est pour l’essentiel identique au serveur inclus dans Windows XP Professionnel et Windows Server 2003 et est proche de celui inclus dans les versions Windows 2000. Il utilise le shell de commande Windows (Cmd.exe) comme shell par défaut. Ce serveur peut être démarré et arrêté à partir de la console MMC Services ou via la console MMC Administration Windows Services for UNIX (Sfumgmt.msc). Consultez les paramètres du serveur Telnet ci-dessous afin d’en savoir plus sur les paramètres et leur signification. Le démon Telnet Interix, telnetd, est normalement exécuté sous le contrôle de inetd. Il utilise le shell Interix comme shell d’ouverture de session. Consultez la page du manuel telnetd pour plus d’informations sur toutes les options du démon Telnet Interix. Activation d’Interix telnetdPour activer le serveur Telnet Interix, commencez par arrêter le serveur Telnet Windows en utilisant la console MMC Services for UNIX afin de le configurer pour un démarrage manuel ou de le désactiver. Ensuite, à partir d’un shell Windows Services for UNIX (tel que ksh), modifiez le fichier /etc/inetd.conf en utilisant un éditeur Windows Services for UNIX (tel que vi) afin de supprimer la marque de commentaire de la ligne suivante : #telnet stream tcp nowait NULL /usr/sbin/in.telnetd in.telnetd –i Ensuite, à partir du shell Korn Interix avec un compte doté de privilèges suffisants, exécutez la commande suivante : $ kill -1 $(ps –ef | grep inetd | grep –v grep | tr –s " " \ | cut –f2 –d " ") Pour ceux que les détails intéressent, ce script d’une ligne recherche l’ID du processus inetd, puis exécute la commande kill -1 (NOHUP) sur ce processus, ce qui entraîne la relecture du fichier de configuration par inetd. AuthentificationLe serveur Telnet Windows prend en charge Windows NT LAN Manager (NTLM) pour l’authentification des ouvertures de session clients Telnet Windows. L’utilisation de NTLM permet aux utilisateurs d’être authentifiés automatiquement auprès du serveur Telnet sur la base de leur ouverture de session Windows. Cette fonctionnalité rend l’utilisation de Telnet totalement transparente pour les utilisateurs, tout en garantissant que les mots de passe en texte clair ne transitent pas via un réseau. NTLM doit être pris en charge du côté client d’une ouverture de session, comme avec le client Telnet Windows. Remarque : L’utilisation de NTLM uniquement dans un environnement mixte UNIX et Windows empêche les utilisateurs UNIX d’accéder aux serveurs Windows, car les utilisateurs UNIX ne possèdent pas de client prenant en charge l’authentification NTLM. Les serveurs Interix telnet et telnetd ne prennent pas en charge l’authentification NTLM. Lors de l’utilisation de l’ouverture de session NTLM, les utilisateurs sont limités aux lecteurs locaux de l’ordinateur sur lequel ils ont ouvert une session. S’ils doivent mettre en correspondance des ressources réseau, ils peuvent le faire via une mise en correspondance explicite avec des informations d’identification complètes. Par exemple : net use g: \\server\share /user:domain\username AdministrationLe serveur Telnet Windows est administré via le composant logiciel enfichable MMC Windows Services for UNIX ou le programme tnadmin. Pour voir les options pour tnadmin.exe, tapez : tnadmin /? Le tableau suivant affiche les options disponibles pouvant être définies. Tableau 5. Options d’administration Telnet
Le serveur Interix telnetd est basé sur le démon Telnet BSD (Berkeley Software Distribution). Pour plus d’informations sur les options de configuration, reportez-vous aux pages du manuel concernant telnetd. Console MMC Services For UNIXWindows Services for UNIX inclut une console MMC unique pour la gestion de tout à l’exception de Gateway for NFS. La console MMC offre une interface de gestion cohérente et facile à utiliser qui vous permet d’administrer tous les ordinateurs Windows Services for UNIX d’un réseau à partir de n'importe quelle console. Ensuite, étant donné que Windows Services for UNIX prend en charge WMI, la gestion peut être intégralement contrôlée par l'intermédiaire de scripts à partir de la ligne de commande. ActiveState ActivePerl 5.8Windows Services for UNIX inclut ActiveState ActivePerl 5.8 pour Windows, une version complète de Perl 5.8 et Perl Script qui fonctionne sous Windows 2000, Windows XP et Windows Server 2003. Parmi les nombreuses améliorations, ActivePerl 5.8 inclut la prise en charge complète de la commande fork(), ce qui améliore grandement la portabilité des scripts et des modules à partir de la distribution Perl générale. ActivePerl prend en outre totalement en charge Windows Scripting Host, ce qui en fait un excellent outil pour les tâches d’administration système. Simplification de la gestion des comptesWindows Services for UNIX offre des outils importants pour simplifier la gestion des comptes dans un réseau mixte Windows et UNIX. Ces outils sont les suivants :
Assistant Migration NIS vers Active DirectoryL’Assistant Migration NIS offre un outil simple à utiliser qui permet la migration d’un environnement NIS existant vers Server for NIS. Il prend les fichiers source NIS UNIX et les migre vers Active Directory. Vous pouvez soit rendre les fichiers source disponibles pour le serveur Windows qui exécutera l’Assistant Migration NIS en utilisant NFS, soit les envoyer via ftp vers un répertoire local sur le serveur. Tous vos fichiers source doivent résider dans le même répertoire. Vous pouvez exécuter l’Assistant Migration plusieurs fois afin de migrer les fichiers par étape, ou exécuter toutes les migrations en une seule étape. Si vous migrez les fichiers par étapes, vous devez migrer le fichier passwd avant de tenter de migrer le groupe ou les fichiers instantanés qui en dépendent. Server for NISServer for NIS permet à un contrôleur de domaine Windows 2000 ou Windows Server 2003 d’être un serveur maître NIS ou un serveur subordonné NIS (esclave) en intégrant NIS dans Active Directory. Si Server for NIS est utilisé comme serveur subordonné, le serveur maître doit être un contrôleur de domaine Windows 2000 Server ou Windows Server 2003. Un serveur maître Server for NIS peut prendre en charge à la fois les serveurs subordonnés NIS UNIX et Windows. Synchronisation de mot de passeL’outil de synchronisation de mot de passe inclus dans SFU 3.5 est un utilitaire de synchronisation bidirectionnel qui vous permet de synchroniser les changements de mot de passe entre Windows et UNIX. Les changements de mot de passe peuvent commencer dans Windows ou UNIX pour les systèmes d'exploitation suivants :
La synchronisation de mot de passe bidirectionnelle utilise un démon de connexion unique (SSOD) qui s’exécute sur le serveur UNIX afin d’accepter les changements de mot de passe de Windows. Il utilise un PAM (Password Authentication Mapper), qui s’exécute également sur le serveur UNIX, afin de transmettre les changements de mot de passe UNIX à l’environnement Windows. Notes de déploiementSi vous prévoyez d’utiliser la fonctionnalité de synchronisation de mot de passe de Services for UNIX, tenez compte des informations suivantes :
Pour synchroniser correctement les mots de passe entre les systèmes Windows et les systèmes UNIX, les noms des comptes utilisateur doivent être exactement les mêmes sur tous les ordinateurs Windows et UNIX qui utilisent le service. Soyez conscients que contrairement aux comptes Windows, les noms des comptes UNIX distinguent les majuscules des minuscules. En outre, tous les ordinateurs UNIX doivent être configurés correctement avec le SSOD fourni sur le CD Services for UNIX. Si vous souhaitez utiliser Synchronisation de mot de passe pour synchroniser un domaine Windows avec un domaine NIS, vous devez inclure les serveurs maîtres NIS dans la liste des ordinateurs pouvant recevoir des changements de mot de passe. Vous devrez également configurer votre démon sur le serveur UNIX en apportant les modifications appropriées à la configuration et aux fichiers make afin d’utiliser NIS. Mise en correspondance des noms d’utilisateurLa fonctionnalité Mise en correspondance des noms d’utilisateur offre un mécanisme permettant de mettre en correspondance les noms différents pouvant exister entre les environnements UNIX et Windows. La mise en correspondance des noms d’utilisateurs est utilisée lorsque les noms sont les mêmes dans les deux environnements, mais sa force réelle consiste à vous permettre de mettre en correspondance les utilisateurs dont les noms ne sont pas les mêmes dans les deux environnements. Étant donné que les noms d’utilisateur UNIX distinguent les majuscules des minuscules, contrairement aux noms d’utilisateur Windows, cette fonctionnalité peut simplifier considérablement la gestion et la maintenance des comptes dans les deux environnements. Un serveur de mise en correspondance de noms d’utilisateur est un service hautement disponible, qui prend en charge les clusters et un pool redondant de serveurs de mise en correspondance des noms d’utilisateur. Grâce à la mise en correspondance des noms d’utilisateur, vous pouvez créer des correspondances simples entre les comptes d’utilisateur Windows et les comptes UNIX correspondants, et utiliser la fonctionnalité de mise en correspondance avancée afin de mettre en correspondance les comptes présentant des noms différents. En outre, la mise en correspondance des noms d’utilisateurs prend en charge la correspondance un à plusieurs entre les comptes UNIX et Windows, ce qui vous permet de mettre en correspondance un compte UNIX unique avec plusieurs comptes Windows. Cela vous permet par exemple de mettre en correspondance plusieurs comptes administratifs Windows avec le compte UNIX racine. La mise en correspondance des noms d’utilisateur utilise NIS pour authentifier les utilisateurs, ou des fichiers locaux mot de passe/groupe. Ces fichiers peuvent avoir leur origine dans l’environnement UNIX mais doivent résider localement, normalement dans le répertoire /etc (%SFUDIR%\etc). En outre, le serveur de mise en correspondance des noms d’utilisateur utilise désormais un fichier spécial appelé .maphosts, situé dans le répertoire /Mapper (%SFUDIR%\Mapper) afin d’implémenter la sécurité des hôtes sécurisés. Utilisation de l’expertise UNIXGrâce à une gestion réseau et une connectivité UNIX familières, ainsi qu’à l’intégration totale du sous-système Interix, des shells, des utilitaires et du kit SDK (étudié dans la section suivante), Windows Services for UNIX 3.5 permet aux entreprises d’utiliser leurs investissements dans l’expertise et les scripts UNIX lors de l’intégration de Windows dans leurs environnements. InterixWindows Services for UNIX 3.5 inclut la technologie de sous-système Interix, un environnement de script et d’application UNIX robuste et complet qui s’exécute en tant que sous-système natif sur le noyau Windows. Un sous-système natif, pas une émulationL’environnement d’exécution d’applications Interix, contrairement au Korn shell et aux utilitaires Windows des versions antérieures à SFU 3.0, est un sous-système entièrement intégré et un kit SDK qui s’exécute de manière native sous Windows 2000, Windows XP et Windows Server 2003. Interix offre une prise en charge complète de la compilation puis de l’exécution des applications UNIX dans Windows, ce qui permet aux entreprises d’utiliser et de migrer facilement leurs applications personnalisées existantes. Il offre également aux développeurs UNIX la prise en charge complète de plus de 2 000 API UNIX, ce qui permet aux scripts et aux applications écrits pour s’exécuter sous UNIX d’être transférés facilement et naturellement vers Windows. ScriptsWindows Services for UNIX 3.5 inclut les environnements Korn Shell et C Shell, plus de 350 utilitaires UNIX, ainsi que Perl 5.6.1 compilé sous Interix. Cela confère aux développeurs et administrateurs UNIX l’environnement de script le plus large, le plus familier et le plus compatible possible. Les utilitaires sont awk, grep, sed, tr, cut, tar, cpio et beaucoup d’autres, tous fonctionnant conformément aux attentes de l’utilisateur, de l’administrateur ou du programmeur UNIX. Sont également inclus plus de 40 utilitaires et compilateurs GNU, tels que gawk, gcc, g++ et g77. Système de fichiers à racine uniqueWindows Services for UNIX 3.5 implémente un système de fichiers à racine unique dans l’environnement Interix, permettant aux utilitaires, scripts et applications de fonctionner comme prévu avec une racine unique pour tous les systèmes de fichiers. Cette possibilité simplifie de façon notoire les problèmes de portabilité, car les fichiers résident dans leur emplacement traditionnel. Les lettres d’unité individuelles sont accessibles via /dev/fs/C, /dev/fs/D, etc., tandis que les partages de fichiers réseau sont accessibles via /net/<NETNAME>/<nom_partage> (par exemple "/net/SERVER1/Users"). ShellsLe Korn Shell et le C Shell sont tous deux inclus dans Windows Services for UNIX, et tous deux se comportent comme dans un environnement UNIX. Contrairement au Korn shell des versions antérieures à SFU 3.0, ces shells utilisent un système de fichiers à racine unique. La nécessité de convertir les scripts pour prendre en charge la syntaxe de lettre d’unité a disparu, de même que les problèmes concernant la signification particulière du caractère deux-points (":"). Par exemple, dans les versions antérieures de SFU, le chemin entièrement qualifié du script « build.ksh » des utilisateurs dans leur répertoire bin personnel serait : U:/bin/build.ksh Dans Windows Services for UNIX 3.5, ce script se trouverait dans l’emplacement suivant : /dev/fs/U/bin/build.ksh Ou : ~/bin/build.ksh Ajoutez un lien symbolique : Dans –s /net/SERVER1/UserHome /home Et vous obtenez : /home/$USERNAME/bin/build.ksh Les scripts et programmes courants peuvent résider là où la plupart des utilisateurs UNIX et Linux s’attendent à les trouver. Par exemple, vim/gvim est installé dans le répertoire suivant : /usr/local/bin/vim /usr/local/bin/gvim -> /usr/local/bin/vim Ce listing illustre une deuxième nouvelle fonctionnalité importante fournie dans le cadre du sous-système Interix ; les liens symboliques sont désormais totalement pris en charge dans les systèmes de fichiers NTFS, ainsi que dans NFS. La prise en charge d’un système de fichiers à racine unique facilite le portage des scripts d’UNIX vers Windows pour deux raisons importantes. Non seulement les applications, programmes et fichiers système se trouvent là où les programmes et utilisateurs UNIX s’attendent à les trouver, mais le caractère deux-points conserve sa signification normale de séparateur de champ dans les variables PATH, etc. Une autre différence importante est que les fichiers spéciaux qui contrôlent le comportement du shell portent les mêmes noms dans l’environnement Interix que dans UNIX. Cela facilite la maintenance d’un fichier « .profile » et « .kshrc » unique (ou .login et .environ pour les utilisateurs du C Shell) dans plusieurs environnements. Cela permet également aux utilisateurs d’utiliser Client for NIS ou Server for NFS afin d’offrir une structure de répertoires de départ partagée et unique dans les environnements Windows et UNIX. LangagesLe sous-système Interix offre un environnement de script et de programmation familier et compatible, avec prise en charge de plusieurs langages et bibliothèques de script et de programmation, tels que Perl, C, fortran77 et C++. Il inclut la prise en charge des compilateurs GNU gcc, g77 et g++, ainsi que du compilateur Microsoft Visual C/C++ en tant que cc et c89. Outils et utilitairesTous les outils et utilitaires UNIX standard font partie de SFU ; il n’est pas nécessaire d’acquérir de package tiers supplémentaire pour disposer des outils dont vous avez besoin pour votre travail. Tous les outils familiers sont disponibles et fonctionnent comme l’administrateur UNIX l’attend. Les utilitaires incluent des outils de traitement de texte familiers, tels que grep, less, awk, sed, pr, tr, etc., des outils de traitement par lot tels que at, cron et batch, des outils de contrôle de tâche, tels que ps, nice et kill, des utilitaires graphiques, tels que xterm, xrdb, xset et xclock, des outils de développement, tels que gcc, gdb, make, ainsi que des outils de connectivité, tels que bind, sendmail et ftp. Ils sont tous présents et fonctionnent comme prévu. Même la commande man est la même. ProgrammationNon seulement Windows Services for UNIX fournit un ensemble complet d’API, de compilateurs et d’utilitaires pour la création et la migration d’applications UNIX, notamment les applications basées sur XWindows(X11R6.6) et Curses, mais il fournit également un environnement complet d’exécution d’application qui se comporte comme les applications UNIX le prévoient. Aucune considération spéciale concernant les emplacements des fichiers ou la syntaxe n’est requise. Les liens symboliques sont également totalement pris en charge, offrant ainsi une flexibilité maximale de l’emplacement. Il est alors non seulement possible, mais également relativement simple, de convertir une application UNIX existante afin qu’elle fonctionne sur le sous-système Interix. Windows Services for UNIX 3.5 comporte plus d’une centaine de nouvelles API introduites récemment pour prendre en charge les applications pthread et les chaînes de caractères élargies. Remarque : les applications UNIX doivent être recompilées pour s’exécuter sur Interix. Différences avec les versions antérieures d’InterixInterix a toujours présenté un aspect familier pour les utilisateurs UNIX, mais il était moins tolérant par rapport aux attentes des utilisateurs Windows natifs. Dans les versions plus récentes d’Interix, des améliorations ont été apportées afin d’offrir un environnement plus intégré à Windows. L’utilitaire ksh d’Interix utilise désormais la variable d’environnement PATH_WINDOWS qui recherche et trouve les programmes Windows dans des répertoires spécifiques sans qu’il soit nécessaire de spécifier la casse ou le suffixe exacts du nom des fichiers. Par exemple, la recherche sur « winword » trouve le programme WINWORD.exe si PATH et PATH_WINDOWS sont configurés correctement. Pour des questions de sécurité, depuis la version Windows XP, le système Windows est configuré par défaut pour désactiver la distinction majuscules/minuscules dans tous les sous-systèmes d’environnement, notamment Interix. Cela signifie que Interix peut être installé avec la distinction majuscules/minuscules désactivée. La distinction majuscules/minuscules est requise dans un environnement UNIX réel. Lorsque vous installez Interix sur un système Windows XP ou Windows Server 2003, vous pouvez choisir de conserver la distinction majuscules/minuscules désactivée ou de l’activer explicitement. Le sous-système Interix est également totalement compatible avec les systèmes de fichiers NFS et il utilise le serveur de mise en correspondance de nom d’utilisateur lors de la résolution des noms de comptes sur les systèmes de fichiers NFS. Choix d’installation personnalisésWindows Services for UNIX 3.5 utilise l’installeur Microsoft familier illustré dans la figure 1. Cet installeur prend en charge l’installation à la demande, la suppression de Windows Services for UNIX avec contrôle complet par script, ainsi que la maintenance. Lorsque vous choisissez une installation personnalisée, vous pouvez choisir les options qui sont installées.
Windows Services for UNIX offre un certain nombre de choix différents pour l’installation. Les choix que vous faites dépendent en grande partie du type de réseau hétérogène pris en charge. Bien que de nombreuses options et combinaisons d’installation soient possibles, les combinaisons élémentaires suivantes sont utiles dans différents scénarios. Les trois scénarios élémentaires et les combinaisons prises en charge sont les suivantes :
L’installation doit inclure Interix et le kit SDK Interix pour les scripts inter-plate-forme et la migration des applications, ainsi que NFS pour le partage des ressources de fichiers inter-plate-forme et la synchronisation des mots de passe. Prenez soin de créer vos noms d’utilisateur Windows avec la casse correspondant à votre environnement UNIX. Chacun de ces types d’installation installe la combinaison des options appropriées pour l’environnement qu’il est conçu pour prendre en charge. Dans tous ces scénarios, vous souhaiterez probablement installer Interix. Il offre un ensemble complet d’utilitaires et shells UNIX, ainsi qu’un environnement complet et robuste d’interopérabilité et de migration. Examinons les différents types d’installation et dans quels cas les utiliser. Installation complète avec Server for NISDans un environnement d’entreprise dans lequel il existe des ressources UNIX substantielles et un environnement de domaine NIS existant qui implémente également Windows 2000 Server ou Windows Server 2003 et Active Directory, il peut être utile d’installer le package Server for NIS complet sur le contrôleur de domaine. Avec l’Assistant Migration NIS, vous pouvez migrer vos domaines NIS existants vers Active Directory et offrir un Server for NIS maître, répliqué et totalement redondant dans le cadre d’Active Directory. N'importe quel contrôleur de domaine Windows peut être un Server for NIS. Il ne peut y avoir qu’un seul Server for NIS maître, mais les autres contrôleurs de domaine de votre domaine Windows peuvent être des serveurs subordonnés à un serveur maître NIS basé sur Active Directory. Remarque : Un Server for NIS SFU ne peut pas être un serveur subordonné à un serveur maître NIS UNIX, mais seulement à un Server for NIS SFU maître. NFS et la mise en correspondance des noms d’utilisateurDans les environnements dans lesquels il existe des ressources de système de fichiers NFS substantielles et des clients NFS UNIX qui n’exécutent pas NIS ou dans lesquels le serveur maître NIS réside sur UNIX, vous devez envisager l’installation de Server for NFS, Client for NFS ou Gateway for NFS, ainsi que de la mise en correspondance des noms d’utilisateur. Vous devez installer un seul service de mise en correspondance des noms d’utilisateur, mais vous pouvez en installer davantage si vous êtes sur un sous-réseau ou que vous disposez d’un grand nombre de clients NFS Windows et que vous souhaitez répartir la charge de manière appropriée. Conseils Gateway for NFSVous pouvez installer Client for NFS ou Gateway for NFS sur un serveur Windows 2000 ou Windows Server 2003, mais pas les deux. Si votre utilisation de NFS est relativement élevée, vous constaterez peut-être que Gateway for NFS est un choix rentable. Il offre un moyen permettant aux clients Windows de se connecter aux ressources existantes du système de fichiers NFS sans avoir à charger un Client for NFS sur leur ordinateur. Cependant, n’oubliez pas qu’une utilisation intensive de NFS peut surcharger le serveur de passerelle, créant ainsi un goulet d'étranglement dans le système. Conseils Client for NFSVous devez installer Client for NFS sur n'importe quel serveur ou ordinateur Windows XP Professionnel ou Windows 2000 Professionnel qui utilisera de manière intensive les ressources du système de fichiers NFS. Si vous avez au moins un serveur qui exécute Gateway for NFS, vous pouvez utiliser ce serveur pour rendre les ressources NFS disponibles pour les clients moins exigeants et les clients Windows 9x. Cependant, vous devez installer Client for NFS sur tous les ordinateurs qui nécessiteront une utilisation importante et régulière des fichiers stockés sur les serveurs NFS. Conseils pour l’authentification Server for NFSSi vous partagez des ressources de système de fichiers avec des clients UNIX qui utilisent Server for NFS, installez l’authentification Server for NFS sur tous les ordinateurs qui exécutent Server for NFS et sur tous les contrôleurs de domaine de tous les domaines dans lesquels des comptes utilisateur seront authentifiés pour l’accès aux partages NFS. La seule exception concerne les domaines Windows Server 2003 dans lesquels la forêt se trouve au niveau de fonctionnalité Windows Server 2003. Conseils pour la mise en correspondance des noms d’utilisateurInstallez la mise en correspondance des noms d’utilisateur sur un ou plusieurs serveurs, de préférence un contrôleur de domaine. Cela vous permet de mettre en correspondance les noms d’utilisateur dans chaque environnement, d’une façon globalement transparente pour les utilisateurs. Si vous disposez d’un cluster disponible, le serveur de mise en correspondance des noms d’utilisateur peut y être installé, ce qui permet d’augmenter la disponibilité. Synchronisation (bidirectionnelle) des mots de passeDans un environnement dans lequel se trouve un grand nombre d’utilisateurs Windows et UNIX, et où un nombre important de ces utilisateurs travaillent avec les deux systèmes d'exploitation, vous devez installer la synchronisation des mots de passe si vos systèmes UNIX se trouvent sur une plate-forme prise en charge. Si vos systèmes UNIX n’exécutent pas l’une des plates-formes prises en charge, vous pouvez quand même exécuter la synchronisation des mots de passe en compilant les démons fournis (SSOD et PAM) pour votre plate-forme, à l’aide du fichier make fourni. Conseil : la synchronisation des mots de passe ne prend pas en charge les noms différents, pas plus qu’elle n’utilise la mise en correspondance des noms d’utilisateur. Dans un environnement dans lequel vous souhaitez utiliser la synchronisation des mots de passe, vous devez faire l’effort d’aligner vos noms d’utilisateur (notamment la casse, puisque UNIX distingue les majuscules des minuscules) sur les deux plates-formes afin de faciliter la gestion centrale des mots de passe. Scénarios d’utilisationAdministration centrale des mots de passeL’une des sources de frustration les plus importantes pour les utilisateurs et administrateurs d’un environnement mixte UNIX et Windows est la gestion et la maintenance des différents comptes dans les deux domaines. Cela s’avère particulièrement vrai dans les environnements étendus dans lesquels la sécurité est importante et où des changements de mots de passe réguliers sont imposés. Windows Services for UNIX 3.5 offre les outils permettant de simplifier ce processus. Il existe plusieurs moyens de gérer la maintenance centrale des mots de passe, en fonction de la façon dont votre environnement est configuré et de vos besoins spécifiques. Les trois mécanismes élémentaires sont les suivants :
Chacun de ces mécanismes aborde différemment le problème de l’administration centralisée des mots de passe, mais chacun a sa place et peut être complémentaire des autres. Dans un environnement d’entreprise étendu comporte une base bien établie d’utilisateurs et d’administrateurs UNIX, il n’est pas toujours possible d’implémenter NIS dans le cadre d’Active Directory. Dans ces environnements, vous pouvez utiliser une combinaison de synchronisation des mots de passe et de mise en correspondance des noms d’utilisateur afin d’obtenir un résultat similaire. La mise en correspondance des noms d’utilisateur vous aidera à exploiter vos ressources UNIX existantes en permettant aux utilisateurs de se connecter aux systèmes de fichiers NFS même s’ils possèdent des noms de compte différents dans les deux environnements. La synchronisation des mots de passe fonctionnera avec les comptes qui portent le même nom dans les deux environnements pour préserver la synchronisation des mots de passe, que l’environnement UNIX utilise NIS ou /etc/passwd comme mécanisme d’authentification principal. Dans les environnements qui adoptent Windows 2000 ou Windows Server 2003 et Active Directory, il existe une opportunité majeure de simplifier et de consolider la maintenance des comptes dans un emplacement unique, facile à gérer, à savoir Active Directory. Grâce à l’Assistant Migration NIS, vous pouvez migrer votre domaine NIS existant vers Active Directory, en convertissant votre serveur NIS maître en serveur NIS subordonné qui pointe vers le nouveau serveur NIS maître basé sur Active Directory. Lorsqu’il existe des comptes différents dans les deux environnements, le service de mise en correspondance des noms d’utilisateur offre un mécanisme simple pour mettre en correspondance les comptes entre les deux. Conseil : Server for PCNFS offre la prise en charge complète de PCNFSD et de l’authentification utilisateur pour l’accès aux ressources de fichiers NFS à tous les clients NFS qui ne peuvent pas utiliser la mise en correspondance des noms d’utilisateur (tels que les clients SFU 1.0). Vous devez installer Server for PCNFS sur le même serveur que la mise en correspondance des noms d’utilisateur, pour des questions de simplicité et de facilité de maintenance. Systèmes de fichiers communsDe nombreuses entreprises possèdent des ressources de stockage déjà utilisées dans l’environnement UNIX et le coût associé au déplacement de ces ressources vers Windows ou, pire encore, à leur réplication dans les deux environnements serait important. Windows Services for UNIX fournit le mécanisme permettant d’unifier les systèmes de fichiers entre les deux environnements, ce qui vous donne un système de fichiers commun unique dont les deux côtés peuvent tirer parti. Utilisez Server for NFS sur vos serveurs Windows afin de permettre un accès facile aux systèmes de fichiers Windows pour vos serveurs et clients UNIX, et utilisez une combinaison de Gateway for NFS et Client for NFS pour offrir un accès transparent aux ressources de stockage UNIX existantes à vos serveurs et clients Windows. Une considération importante lors de l’implémentation de Client for NFS ou Gateway for NFS dans l’entreprise consiste à décider lequel est adapté à chaque situation. Gateway for NFS est approprié lorsque vous devez prendre en charge une utilisation occasionnelle et relativement limitée des ressources de stockage NFS pour les clients Windows de façon totalement transparente pour les utilisateurs. Elle n’est en revanche pas adaptée à une utilisation intensive ou fréquente si un utilisateur exécute des programmes à partir de Server for NFS ou stocke des fichiers de données ou documents volumineux sur le serveur. Dans ce cas, la version complète de Client for NFS est plus appropriée, évitant à Gateway for NFS de devenir un goulet d'étranglement. Dans la plupart des environnements, un mélange de Gateway for NFS et de Client for NFS constitue le meilleur choix et le choix le plus rentable. Vous devez utiliser la version complète de Client for NFS sur les ordinateurs dont les utilisateurs ont besoin de bande passante supplémentaire, et utiliser Gateway for NFS pour prendre en charge les utilisateurs occasionnels d’une façon offrant un système de fichiers communs transparent et facile à gérer entre les deux environnements. Migration des applications et des scriptsLa technologie du sous-système Interix dans Windows Services for UNIX 3.5 en fait un excellent moyen de migrer les applications et scripts UNIX vers la plate-forme Windows. Avec le kit SDK Interix complet, ainsi que le kit SDK et les compilateurs GNU largement pris en charge dans Windows Services for UNIX 3.5, les entreprises peuvent réorienter leurs applications UNIX afin qu’elles s’exécutent de façon native sous Windows. Interix utilise un système de fichiers à racine unique, ce qui offre aux applications et scripts UNIX l’environnement attendu, avec des fichiers et structures de répertoires familiers, nécessitant peu ou pas de modifications du code source pour la compilation et l’exécution. RésuméWindows Services for UNIX 3.5 est un ensemble d’outils d’interopérabilité complet pour l’intégration des environnements Windows et UNIX. Windows Services for UNIX 3.5 inclut des composants d’interopérabilité de plate-forme, des composants de gestion communs et des composants de migration d’applications dans un même produit Microsoft totalement intégré et pris en charge. Il comprend également des outils offrant une valeur ajoutée tout en améliorant la gestion informatique dans l’entreprise. Windows Services for UNIX 3.5 offre une prise en charge robuste et inter-plate-forme des systèmes de fichiers, l’administration centralisée des utilisateurs, ainsi qu’un environnement d’exécution d’applications UNIX qui s’exécute sur le noyau Windows, ce qui permet aux applications et scripts UNIX de s’exécuter de manière native sur la plate-forme Windows côté à côte avec les applications Windows. Liens connexesPour les informations les plus récentes sur Windows Services for UNIX, consultez le site Web Services for UNIX à l’adresse http://www.microsoft.com/windows/sfu.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
Updated 14 février 2006 Hervé Chaudret |