Export (0) Print
Expand All
20 out of 32 rated this helpful - Rate this topic

Windows Services for UNIX 3.5 White Paper

Updated: April 22, 2004

Charlie Russel

Microsoft MVP for Server 2003 Interoperability

Abstract

Microsoft® Windows® Services for UNIX (SFU) 3.5 provides a full range of supported and fully integrated cross-platform network services geared toward enterprise customers needing to integrate Windows® and UNIX-based environments. It allows these customers seamless access to information stored in multiple platforms, consolidates network management across platforms, and reuses UNIX applications and scripts on Windows. This white paper discusses the features and functionality of SFU 3.5 and is targeted at the system administrator, developer, or integrator of a mixed UNIX and Windows network.

*
On This Page

Introduction Introduction
New SFU 3.5 Features New SFU 3.5 Features
Why Services for UNIX? Why Services for UNIX?
Interix Interix
Custom Installation Choices Custom Installation Choices
Use Scenarios Use Scenarios
Summary Summary
Related Links Related Links

Introduction

Since its introduction in 1999, Microsoft® Windows® Services for UNIX (SFU) has played a major role for those of us trying to make Windows and UNIX networks coexist peacefully. When Windows Services for UNIX 3.0 was released in 2002, Microsoft added significant new functionality with the addition of Interix technology—a full UNIX script and application execution environment that runs as a native Windows subsystem. With the release of Windows Services for UNIX 3.5 in 2004, Microsoft improves its industry-leading interoperability toolset by adding additional internationalization support and a full set of pthread APIs within Interix to broaden its award-winning interoperability suite.

With SFU 3.5, Microsoft has extended the Interix SDK to support threaded applications while updating both the utilities and APIs to improve support for internationalization. Network File System (NFS) support has been extended as well to improve authentication in native Microsoft Windows Server™ 2003 Active Directory® environments.

New SFU 3.5 Features

Microsoft has made a substantial investment in improving SFU’s performance. For example, the Interix subsystem shows improvements in all aspects of performance—ranging from 30 percent improvements in fork and exec performance, to 75 percent improvements in pipe bandwidth, to more than 100 percent improvements in file I/O and more than 150 percent in fstat latency. File I/O is now within 10 percent of the Win32 subsystem. Additional improvements in multiprocessor scalability have also been realized. There have been substantial performance improvements in the Server for NFS and Server for NIS components of SFU as well.

Windows Services for UNIX 3.5 works with a broad range of UNIX and Linux platforms, using industry standard protocols and utilities. It has been explicitly tested for interoperability with Solaris 7, Solaris 8, HP-UX 11, AIX 5L 5.2, and Red Hat Linux 8.0. Windows Services for UNIX 3.5 runs on Microsoft® Windows 2000 (Professional and Server versions), Microsoft® Windows XP Professional, and Windows Server 2003.

Windows Services for UNIX 3.5 adds significant new features and enhancements to the Windows Server product family and represents a major shift in how interoperability of scripts and programs is accomplished. Table 1 summarizes the major new features in Windows SFU 3.5 since SFU 2.0.

Table 1. New and Enhanced SFU 3.5 Features

Feature

Description

NFS Client

Supports setuid, setgid and sticky bits

 

Support for symbolic links

 

Performance improvements

 

Internationalization: additional language options

NFS Server

Significant performance enhancements

 

Support for active-active clustering of NFS shares

 

Support for setuid, setgid, and sticky bits

 

Per-share handing of root and anonymous access

 

Improved model for mapping permissions between Windows and UNIX

 

Internationalization improvements

SFU 3.5

Support for Windows Server 2003 Volume Shadow Copy Service

SFU 3.5

Simplified and enhanced authentication in Windows Server 2003 Active Directory environments

NFS Gateway

Internationalization improvements

Mapping Server

Cluster-enabled mapping server

 

Performance, security, and scalability improvements

 

Support for redundant mapping servers

 

Internationalization improvements

Server for NIS

Support for MD5 encryption

 

Scalability and performance improvements

 

Numerous usability and administration improvements

Password Sync

New support for setting passwords using Pluggable Authentication Model on UNIX

Telnet Server

Security and scalability improvements

 

Internet Protocol version 6 (Ipv6) support

 

Dumb terminal support (handhelds)

Telnet Client

IPv6 support

 

Internationalization

Interix and the Interix SDK

All new to SFU 3.0

 

Improved throughput and stability

 

Single rooted file system

SFU 3.5

Utility updates for Internationalization

SFU 3.5

pthreads support in SDK

SFU 3.5

API support for Internationalization

We’ll take a look at each of the major areas and the enhancements added since SFU 2.0, and then focus on the integration of the Interix subsystem.

Why Services for UNIX?

With the growing adoption of the Windows operating system in established UNIX environments, the need for the two platforms to interoperate has increased. Windows Services for UNIX 3.5 provides a set of additional features to Windows 2000, Windows XP, and Windows Server 2003 that allow for greater interoperability with UNIX–based systems while enabling the migration of applications originally written for UNIX and Linux to run on Windows.

Windows Services for UNIX 3.5 provides a full range of supported and fully integrated interoperability components and a complete SDK that supports more than 2,000 UNIX APIs. Windows Services for UNIX 3.5 provides:

  • Interoperability components that allow seamless integration of Windows and UNIX systems.

  • Manageability components that enable organizations to simplify network administration and account management across both platforms.

  • Development components that provide a full-featured development environment that takes advantage of UNIX-centric developmental expertise.

  • Migration components that enable organizations to retarget UNIX applications and scripts to Windows using the Interix technology of Windows Services for UNIX, providing a robust and resource-sparing home for UNIX applications while providing a clear path forward to the features of .NET.

Windows Services for UNIX provides four compelling scenarios for the heterogeneous UNIX and Windows network that enable you to take the best advantage of both environments to simplify and manage your enterprise. The four scenarios are:

  • Using UNIX network resources.

  • Simplifying network administration.

  • Simplifying account management.

  • Taking advantage of UNIX expertise.

In this section, we’ll look at the first three scenarios in greater detail. In the next section, we’ll examine Windows Services for UNIX and how it can provide better business value and better IT management across diverse environments by letting you use your UNIX-centric expertise and applications on Windows.

Use UNIX Network Resources

Windows Services for UNIX gives you four important tools that enable you to use UNIX network resources for your Windows clients and servers while also enabling your UNIX clients utilize the resources of Windows servers. These four tools are:

  • Client for NFS. This tool enables Windows 2000, Windows XP, and Windows Server 2003 to access the resources of NFS servers on a network.

  • Server for NFS. This tool enables NFS clients on a network to access Windows resources through NFS. The NFS Server service is now fully cluster-aware, supporting active-active clusters.

  • Gateway for NFS. This tool enables Windows 2000 Server or Windows Server 2003 to provide seamless access to the NFS resources on a network to downstream Windows computers without any additional software installed on the Windows computers.

  • Server for PCNFS. This tool enables Windows to act as a PCNFSD server, providing user authentication for file access to NFS servers.

Management and Configuration

The Services for UNIX Administration Microsoft Management Console (MMC) console is used to administer the Client for NFS and Server for NFS services but not the Gateway for NFS service. To open the console, you can either launch it from the Start menu or open the Sfumgmt.msc snap-in from within an MMC console. Alternately, you can administer most NFS options from the command line. Complete command-line syntax is available from the command line by typing:

nfsadmin [client | server | gw] /?

Client for NFS

The properties you can modify for the Client for NFS are:

  • Authentication. The mapping server to use for authentication.

  • File permissions. The default file access permissions. Defaults are:

    rwxr-xr-x

  • Performance. The settings for the following performance related factors (and their default values):

    Table 2. Performance Settings

    Setting

    Default Value

    Transport Protocol

    UDP

    Mount Type

    Soft

    Retries

    1

    Timeout

    0.8 seconds

    Read Buffer Size

    32 Kb

    Write Buffer Size

    2 Kb

Connecting to an NFS Export

You can connect to an NFS export in a variety of ways by using either standard Windows syntax (\\server\share) or standard UNIX syntax (server:/share). From the command line you can use the standard Windows net commands or the more UNIX-like mount command with either syntax. Or simply browse your Network Neighborhood in Explorer. From the command line, the following are equivalent:

net use * server1:/home

net use * \\server1\home

mount server1:/home *

mount \\server1\home *

Tip: When you are sure you are connecting to an NFS export, use the UNIX server:/share syntax for a faster setup of the connection.

Server for NFS

Windows Services for UNIX provides a robust Server for NFS tool that provides disk resources from your Windows 2000, Windows XP, and Windows Server 2003 systems to any machine on your network that supports NFS. To administer the Server for NFS, use the Windows Services for UNIX MMC console, or from the command line use nfsadmin.

From the Windows Services for UNIX MMC console, you can set the following options:

Table 3. Console Options

Option

Description

Logging

Sets she size and location of the logging file and the operations to audit.

Locking

Sets the grace period for locks and a list of current locks.

Client Groups

Groups client machines for easier setting of permissions.

Server Settings

Affects performance, authentication, and file name handling.

Shares

You create shares using Windows Explorer by selecting the NFS Sharing tab from the Properties page. You can share either individual folders or entire drives. To share a folder from the command prompt, type:

nfsshare sharename=drive:path

Where drive:path is the location of the folder you want to share. As in UNIX, you can’t share a subfolder of an existing share. For this purpose, each drive letter is treated as a separate root directory. Complete command-line syntax is available from the command line by typing:

nfsshare /?

Share Permissions

Share permissions are set per client machine or group of machines. To set the share permissions, open the properties dialog box for the folder you are sharing, click the NFS Sharing tab, and then click the Permissions button. The default is read only for all machines with no root access and no anonymous access.

File Permissions

Server for NFS uses the Windows access rights in Discretionary Access Control Lists (DACLs) to simulate the permissions that are typical in the UNIX and NFS world. The default permissions are read/write for all users.

Caution: It is important to understand that there are inherently different permissions sets in the UNIX and Windows security models and that in some cases, the alignment is merely an approximation.

Gateway for NFS

Gateway for NFS is installable on server-level products only—Windows 2000 Server and Windows Server 2003. After it is installed, you use the Gateway for NFS Sharing application (Gwconfig.exe) to create gateway shares. A gateway share takes an NFS file system resource from a UNIX machine or other NFS server and maps that NFS file system to a drive letter on a Gateway server. The drive letter is then shared out to Windows clients anywhere on a network using standard Server Message Block (SMB) protocols. Client Windows computers do not require any additional software and see the gateway shares as if they reside locally on the gateway server.

Start the Gateway for NFS Shares application from the Windows Services for UNIX program group or the command line. From here you can create a gateway share that will be available to all Windows clients as if it were a local share from the gateway computer. Each gateway share uses a drive letter from the gateway computer, limiting the number of shares to the maximum number of free drive letters available on the gateway computer.

From the command line, Gateway for NFS shares are managed by using the Gwshare.exe utility. For details about using this utility, see Windows Help or type:

gwshare /?

Tip: Gateway for NFS shares are limited by the number of available drive letters on a Gateway server. However, if you need additional shares beyond this number, you can (and should) use more than one Gateway server to provide the additional shares in order to distribute the load.

Server for PCNFS

Server for PCNFS provides PCNFSD support. You can enter the necessary information to create users and groups by using the Windows Services for UNIX MMC that will allow Server for PCNFS to handle the authentication of NFS file resources for all NFS clients.

Note: Windows Services for UNIX does not use PCNFS for authentication, and the use of Server for PCNFS is strictly to support other PCNFS clients that require a PCNFS server be available.

Simplify Network Administration

Windows Services for UNIX provides important Windows tools to enhance and simplify the administration of your network. These tools include:

  • Telnet Client. This tool enables character and script-based remote access and administration across a variety of platforms.

  • Telnet Server. This tool enables character and script-based remote administration of Windows from a variety of clients.

  • MMC Snap-in. This snap-in enables a consistent and central management point for all Windows Services for UNIX functionality.

  • ActivePerl. This tool enables existing and new scripts to take advantage of the Windows Management Interface (WMI) to automate network administration tasks.

Telnet Client

Windows Services for UNIX provides a character-mode Telnet client that goes beyond the one included in Windows 2000 to support both stream mode and console mode. It also provides for logging and additional configuration settings (see the set command in the following table) and commands (see the send command in the following table) that make it more robust in a mixed environment.

The Telnet configuration is handled from within a Telnet session by escaping to the Telnet prompt. Press ctrl + ] (right bracket) to bring up the Telnet prompt when you’ve started a Telnet session. From here you can type the following.

Table 4. Telnet Commands

Key

Function

?

To get help

close

To close the current connection

display

To show the current operating parameters

open <machinename>

To open a connection to a machine (you can use an IP address here as well)

send

To send strings to the Telnet server. The strings are sent as is, except for the following special strings:

ao    Send the Telnet command Abort Output to the server

ayt    Send the Telnet command Are You There to the server

brk    Send the Telnet command brk to the server

esc    Send the Telnet escape character to the server

ip    Send the Telnet command Interrupt Process to the server

synch    Send the Telnet command synch to the server

status

To print basic status information about the current session

quit

To exit the Telnet client completely

set

To set an operating parameter. Takes the following parameters:

?    Get help on other set options

bsasdel    Set Backspace key to be sent as the Delete key

delasbs    Set Delete key to be sent as the Backspace key

crlf    Set Return key to send both a carriage return and a linefeed (0x0D,0x0A)

esc x    Use x as the escape character to enter Telnet client prompt (default is ctrl + ])

localecho    Turn on local echo of characters typed

logging    Enable logging

logfile filename    Set file name to be the current logfile

mode x    Where x is console or stream

ntlm    Turn on NTLM authentication

term <value>    Set the requested terminal emulation: ANSI, VT52, VT100, VTNT

unset

To unset the options set with the set command

Tip: If you use the Telnet client primarily to connect to UNIX systems, set term to ANSI and NTLM off. If you frequently connect to both Windows–based and UNIX–based systems, or primarily to Windows systems, the VTNT emulation is the preferred choice, and you can use ANSI when connecting to a system that does not support VTNT.

Telnet Servers

Windows Services for UNIX includes two Telnet servers—the default, Windows–based Telnet server that is functionally similar to the one included with all versions of Windows since Windows 2000, and the Interix telnetd daemon, which is controlled by inetd. Only one of these Telnet servers can be enabled at a time. By default, neither Telnet server is enabled for security reasons.

As installed, the Windows–based Telnet server works optimally for most installations. It accepts logons from a variety of clients, including the Telnet clients shipped with Windows 2000, Microsoft Windows NT®, and Microsoft Windows 95/98, as well as a variety of character-mode terminal clients from virtually any operating system. Additionally, it can be configured to meet specific site requirements to improve security, simplify logons, support stream or console mode, and so forth.

Differences

The default Windows-based Telnet server should be familiar to users of Windows 2000, Windows XP, and Windows Server 2003. It is essentially the same as the server included in Windows XP Professional and Windows Server 2003 and a close relative of the one included in Windows 2000 editions. It uses the Windows Command Shell (Cmd.exe) as the default shell. This server can be started and stopped from either the Services MMC or from the Windows Services for UNIX Administration MMC (Sfumgmt.msc). See Telnet server settings below for details about the server settings and what they mean.

The Interix Telnet daemon, telnetd, is normally run under the control of inetd. It uses the Interix shell as the logon shell. See the telnetd man page for information on all the options of the Interix Telnet daemon.

Enabling Interix telnetd

To enable the Interix Telnet server, first stop the Windows Telnet server by using the Services for UNIX MMC to set it to manual startup or disabled. Next, from a Windows Services for UNIX shell (such as ksh), edit the /etc/inetd.conf file using a Windows Services for UNIX editor (such as vi) to uncomment the following line:

#telnet stream tcp nowait NULL /usr/sbin/in.telnetd in.telnetd –i

Then, from the Interix Korn shell with an account having sufficient privileges, issue the command:

$ kill -1 $(ps –ef | grep inetd | grep –v grep | tr –s " " \

| cut –f2 –d " ")

For the detail-oriented, this one-line script finds the process ID for the inetd process, and then issues kill -1 (NOHUP) to that process, causing inetd to reread its configuration file.

Authentication

The Windows Telnet server supports Windows NT LAN Manager (NTLM) for authentication of Windows Telnet client logons. Using NTLM allows users to be automatically authenticated to the Telnet server based on their Windows logon. This functionality makes using Telnet completely transparent to users, while ensuring that clear text passwords don’t pass over a network. NTLM must be supported on the client side of a logon, such as with the Windows Telnet client.

Note: The use of NTLM only in a mixed UNIX and Windows environment effectively locks out UNIX users from the Windows servers, because UNIX users do not have a client that supports NTLM authentication. The Interix telnet and telnetd don’t support NTLM authentication.

When using NTLM logon, users are restricted to local drives on the machine they are logged on to. If they need to map network resources, they can do so by explicitly mapping with full credentials. For example:

net use g: \\server\share /user:domain\username

Administration

The Windows Telnet server is administered by using the Windows Services for UNIX MMC snap-in or the tnadmin program. To see the options for tnadmin.exe type:

tnadmin /?

The following table shows available options that can be set are.

Table 5. Telnet Administration Options

•Option

Description

Authentication

Choices are NTLM and Username/Password.

Auditing

Sets event logging to a separate log file, or the Event Log, and sets the events to log.

Server Settings

Set the following options:

  • Maximum Number of Simultaneous Connections: Default is the number of licensed connections to the server. On Professional, default is 1.

  • Maximum Number of Failed Login Attempts: Default is 3.

  • Map Alt key to ctrl + A: Default is yes.

  • Telnet Port: Default is 23.

  • Mode of Operation: Choose Console or Stream. Default is Console.

  • Default Domain Name: Type in a domain name that is automatically added to the logon user name. Default is “.”, disabling this feature.

  • Idle Session Timeout: Specifies time until an idle session is forcibly disconnected.

  • Terminate All Programs When Disconnecting: Toggles with the next option.

  • Continue To Run Programs Started with bgjob Command: Allows jobs to continue to run after the session has ended. Default is no.

Sessions

Enables you to see data about the currently active sessions (such as user, domain, machine, logon date/time) and either send a message to the session or terminate it.

The Interix telnetd is based on the Berkeley Software Distribution (BSD) Telnet daemon. For details of configuration options, see the man pages for  telnetd.

Services For UNIX MMC Console

Windows Services for UNIX includes a single MMC for managing everything except the Gateway for NFS. This MMC provides an easy-to-use, cohesive management interface that enables you to administer all Windows Services for UNIX machines on a network from any console. Further, because Windows Services for UNIX supports WMI, management can be fully scripted from the command line.

ActiveState ActivePerl 5.8

Windows Services for UNIX includes ActiveState ActivePerl 5.8 for Windows, a full-featured port of Perl 5.8 and Perl Script that runs on Windows 2000, Windows XP, and Windows Server 2003. Among a host of other improvements, ActivePerl 5.8 includes full support for the fork() command, vastly improving the portability of scripts and modules from the general Perl distribution. ActivePerl also provides full support for the Windows Scripting Host, making it an excellent tool for system administration tasks.

Simplify Account Management

Windows Services for UNIX provides important tools to help simplify the account management in a mixed Windows and UNIX network. These tools include:

  • NIS Migration Wizard. This wizard provides the ability to move UNIX NIS source files from the NIS domain into Active Directory to consolidate account management.

  • Server for NIS. This tool enables a Windows 2000 or Windows Server 2003 domain controller to act as the primary Server for NIS, integrating NIS domains with Windows domains and enabling administrators to manage both domains using Active Directory.

  • Password Synchronization (two-way). This feature provides the ability to synchronize passwords for both platforms, making it easier for users to maintain one password for both Windows and UNIX.

  • User Name Mapping. This feature associates Windows and UNIX user names, enabling users to connect to NFS resources without having to log on to UNIX systems separately.

NIS to Active Directory Migration Wizard

The NIS Migration Wizard provides a simple-to-use tool that helps you to easily migrate an existing NIS environment to Server for NIS. It takes your UNIX NIS source files and migrates them into the Active Directory.

You can either make the source files available to the Windows server that will be running the NIS Migration Wizard by using NFS, or you can ftp them to a local directory on the server. All your map source files should reside in the same directory. You can run the Migration Wizard more than once to migrate the files in steps, or run all your migrations as a single step. If you migrate files in steps, however, you must migrate your passwd file before you attempt to migrate either the group or shadow files that depend on it.

Server for NIS

Server for NIS enables a Windows 2000 or Windows Server 2003 domain controller to be an NIS master server or an NIS subordinate (slave) server by integrating NIS into Active Directory. If Server for NIS is used as a subordinate server, the master server must be a Windows 2000 Server or Windows Server 2003 domain controller. A Server for NIS master server can support both Windows and UNIX NIS subordinate servers.

Password Synchronization

The password synchronization tool included with SFU 3.5 is a two-way synchronization utility that enables you to synchronize password changes between Windows and UNIX. Password changes can begin in either Windows or UNIX for the following:

  • HP-UX 11i

  • Sun Solaris 7, Solaris 8

  • IBM AIX 5L 5.2

  • Red Hat Linux 8.0

    Tip: If your UNIX platform is not on this list, you can still use two-way password synchronization by compiling on your platform. Windows Services for UNIX includes both source code and make files to facilitate the compilation.

Two-way password synchronization uses a single sign on daemon (SSOD) that runs on the UNIX server to accept password changes from Windows. It further uses a Password Authentication Mapper (PAM), also running on the UNIX server, to pass UNIX password changes to the Windows environment.

Deployment Notes

If you’re going to use the password synchronization feature of Services for UNIX, take note of the following information:

  • Windows 2000 and Windows Server 2003 domains. When synchronizing Windows 2000 and Windows Server 2003 domains with UNIX computers, the Password Synchronization service must be installed and running on all domain controllers in the domain, as well as on all UNIX computers where the desired users can change their password. If you uninstall the service from one of the domain controllers, you may run into problems with the other servers.

  • Standalone servers or workgroups. When using the Password Synchronization service to synchronize passwords between standalone or workgroup Windows computers and UNIX computers, you must install the service on all Windows computers. In this case, the password synchronization service synchronizes only the local accounts on each Windows computer with UNIX.

To properly synchronize passwords between Windows systems and UNIX systems, user account names need to be exactly the same on all Windows and UNIX computers using the service. Keep in mind that unlike Windows accounts, UNIX account names are case-sensitive. In addition, all UNIX computers must be set up properly with the SSOD provided on the Services for UNIX CD. If you want to use Password Synchronization to synchronize a Windows domain with an NIS domain, you need to include the NIS master servers in the list of computers that may receive password changes. You will also need to configure your daemon on the UNIX server by making the appropriate changes to the configuration and make files to use NIS.

User Name Mapping

The User Name Mapping feature provides a mechanism to map the dissimilar names that can exist between the UNIX and Windows environments. User Name Mapping is used even when the names are the same in both environments, but its real strength is to enable you to map users whose names are not the same in the two environments. Given that UNIX user names are case sensitive, while Windows user names are not, this feature can greatly simplify maintaining and managing accounts in the two environments.

A User Name Mapping server is a highly available, cluster-enabled service that supports a redundant pool of User Name Mapping servers. Utilizing User Name Mapping, you can create simple maps between Windows user accounts and the corresponding UNIX accounts and use the Advanced Map feature to map accounts with dissimilar names. Further, User Name Mapping supports one-to-many mapping of UNIX to Windows accounts, enabling you to map a single UNIX account to multiple accounts in Windows—which, for example, gives you the ability to map more than one administrative Windows account to the UNIX root account.

User Name Mapping uses either NIS to authenticate users or local passwd/group files. These files can originate in the UNIX environment but must reside locally, normally in the /etc directory (%SFUDIR%\etc). Additionally, User Name Mapping Server now uses a special file called .maphosts located in the /Mapper (%SFUDIR%\Mapper) directory to implement trusted hosts security.

Take Advantage of UNIX Expertise

By providing familiar UNIX networking and connectivity, along with the fully integrated Interix subsystem, shells, utilities, and SDK (covered in the next section), Windows Services for UNIX 3.5 enables enterprises to use their considerable investments in UNIX expertise and scripts as they integrate Windows into their environments.

Interix

Windows Services for UNIX 3.5 includes the Interix subsystem technology, a full-featured, robust, UNIX application and scripting environment that runs as a native subsystem on top of the Windows kernel.

A Native Subsystem, Not an Emulation

The Interix application execution environment, unlike the Windows-based Korn shell and utilities provided in versions earlier than SFU 3.0, is a fully integrated subsystem and SDK that runs natively under Windows 2000, Windows XP, and Windows Server 2003. Interix provides complete support for compiling and then running UNIX applications in Windows, enabling enterprises to easily use and migrate their existing custom applications. It also provides UNIX developers with full support for more than 2,000 UNIX APIs, enabling scripts and applications written to run under UNIX to transfer to Windows easily and naturally.

Scripting

Windows Services for UNIX  3.5 includes both Korn Shell and C Shell environments, more than 350 UNIX utilities, and Perl 5.6.1 compiled under Interix. These give UNIX developers and administrators the broadest, most familiar, and most compatible scripting environment possible. The utilities include awk, grep, sed, tr, cut, tar, cpio, and a host of others, all of which work as a UNIX user, administrator, or programmer expects. Also included are more than 40 GNU utilities and compilers, including gawk, gcc, g++, and g77.

Single Rooted File System

Windows Services for UNIX 3.5 implements a single rooted file system in the Interix environment, making utilities, scripts, and applications that expect to operate with a single / root for all file systems work as intended. This ability also greatly simplifies any porting issues because files are located in their traditional locations. Individual drive letters can be accessed as /dev/fs/C, /dev/fs/D, and so on, and network file shares are accessed by /net/<NETNAME>/<sharename> (for example, "/net/SERVER1/Users").

Shells

Both Korn Shell and C Shell are included with Windows Services for UNIX, and both behave as they do in a UNIX environment. Unlike the Korn shell provided in versions earlier than SFU 3.0, these shells use a single rooted file system. The need to convert scripts to support drive letter syntax is gone as are any problems with the special meaning of the colon character (":"). For example, in previous versions of SFU, the fully qualified path to users’ “build.ksh” script in their personal bin directory would be:

U:/bin/build.ksh

In Windows Services for UNIX 3.5, that script would be located at:

/dev/fs/U/bin/build.ksh

Or:

~/bin/build.ksh

Add a symbolic link :

ln –s /net/SERVER1/UserHome  /home

And you get:

/home/$USERNAME/bin/build.ksh

Common scripts and programs can be located where most UNIX and Linux users would expect to see them. For example, vim/gvim installs to:

/usr/local/bin/vim

/usr/local/bin/gvim -> /usr/local/bin/vim

This listing shows a second important new feature provided as part of the Interix subsystem—symbolic links are now fully supported on NTFS file systems, as well as for NFS.

Support for a single rooted file system alone makes it far easier to port scripts from UNIX to Windows for two important reasons. Not only are applications, programs, and system files located where UNIX programs and users would expect them to be, but also the colon character retains its normal meaning as a field separator in PATH variables, etc.

Another important difference is that the special files that control the shells’ behavior are the same names in the Interix environment as they are in UNIX. This makes it easy for users to maintain a single “.profile” and “.kshrc” (or .login and .environ for C Shell users) across multiple environments. It also allows users to use Client for NIS or Server for NFS to provide for a single, shared home directory structure across both Windows and UNIX environments.

Languages

The Interix subsystem provides a familiar and compatible scripting and programming environment with support for multiple scripting, programming languages, and libraries, including Perl, C, fortran77, and C++. It includes support for the GNU compilers gcc, g77, and g++ and the Microsoft Visual C/C++ compiler as cc and c89.

Tools and Utilities

All the standard UNIX tools and utilities are part of SFU–there’s no need to purchase an add-on package from a third party to get the tools you expect and need to get your work done. All the familiar tools are available and work as a UNIX administrator would expect. The utilities include familiar text processing tools, such as grep, less, awk, sed, pr, tr, and so on; batch processing tools, such as at, cron, and batch; as well as job control tools, such as ps, nice, and kill; graphic utilities, such as xterm, xrdb, xset and xclock; development tools, such gcc, gdb, make; and connectivity tools, such as bind, sendmail and ftp. They’re all there, and they work as you would expect. Even man is the same as it’s always been.

Programming

Windows Services for UNIX not only provides a full set of APIs, compilers, and utilities for creating and migrating UNIX applications, including both XWindows(X11R6.6) and Curses-based applications, but it also provides a complete application execution environment that behaves as UNIX applications expect. No special considerations for file locations or syntax are required. Symbolic links are fully supported as well, providing maximum location flexibility. This makes it not only possible but also relatively easy to port an existing UNIX application to run on the Interix subsystem. New to Windows Services for UNIX 3.5 are more than a hundred new APIs recently introduced to support pthreaded applications and wide character strings.

Note: UNIX applications must be recompiled to run on Interix.

Differences with Earlier Versions of Interix

Interix has always provided a familiar look and feel to the UNIX user but was traditionally less forgiving to the expectations of a native Windows user. In more recent versions of Interix, enhancements have been made to provide a more integrated environment with Windows. The ksh utility in Interix now uses the PATH_WINDOWS environment variable that searches for and finds Windows programs in specific directories without having to explicitly specify the exact file name case or suffix. For example, typing "winword" could find the program WINWORD.exe if PATH and PATH_WINDOWS is configured properly.

Because of security concerns in Windows, beginning with Windows XP, the Windows system is configured by default to disable case sensitivity in all envionrmental subsystems including Interix. This means that Interix can be installed with case sensitivity disabled. Full case sensitivity is required for a true UNIX environment. When installing Interix on a Windows XP or Windows Server 2003 system, you are given the choice of leaving case sensitivity disabled or explicitly enabling it.

The Interix subsystem is also fully aware of NFS file systems and it will use the User Name Mapping Server when resolving account names on NFS file systems.

Custom Installation Choices

Windows Services for UNIX 3.5 uses the familiar Microsoft Installer shown in Figure 1. This installer supports installation on demand, removal of Windows Services for UNIX under fully scriptable control, and maintenance. When you choose a custom installation, you can choose which options are installed.

Figure 1. Windows Services for UNIX Installation

Figure 1. Windows Services for UNIX Installation

Windows Services for UNIX provides a number of different choices for installation. The choices you make are in large part dependent on the type of heterogeneous network you are supporting. Although there are many possible installation options and combinations you can make, the following basic combinations make sense in different scenarios. The three basic scenarios and the combinations they support are:

  • Primarily Windows with some UNIX servers and clients. Install the full Windows Services for UNIX. Gateway for NFS can be installed on a server-class machine to support clients where use of the NFS resources will be relatively limited. For those Windows machines that need substantial access to UNIX NFS shares, Client for NFS should be installed locally.

  • Substantial existing mixed UNIX and Windows. Install NFS (Server and Client/Gateway as appropriate) on your Windows servers and clients along with at least one User Name Mapping Server to provide full access to the existing UNIX file system resources. Install NIS on your domain controllers if you want to consolidate your directories and have a single point of administration. Install the Interix utilities (and GNU utilities if they are used by your staff) to support cross-platform scripting and give UNIX users and administrators a familiar working environment.

  • Existing UNIX with new Windows. In environments that are introducing Windows for the first time, install the full Windows Services for UNIX product. This will enable you to simplify account maintenance, use your UNIX-centric expertise, and migrate UNIX scripts and applications to Windows.

The installation should include Interix and the Interix SDK for cross-platform scripting and application migration and NFS to provide cross-platform file resource sharing and Password Synchronization. Make sure you create your Windows user names with the case that matches your UNIX environment.

Each of these types of installations installs the combination of options appropriate to the environment it’s designed to support. In all of these scenarios, you will probably want to install Interix. It provides a full set of UNIX utilities and shells, as well as a rich and robust interoperability and migration environment. Let’s look at the different types of installations and when you would choose them.

Full Installation Including Server for NIS

In an  enterprise environment in which there are substantial UNIX resources and an existing NIS domain environment that is also implementing Windows 2000 Server or Windows Server 2003 and Active Directory, it may make sense to install the full Server for NIS package on the domain controller. Using the NIS Migration Wizard, you can migrate your existing NIS domains to Active Directory and provide a fully redundant, replicated, master Server for NIS as part of Active Directory. Any Windows domain controller can be a Server for NIS. There can be only a single master Server for NIS, but the other domain controllers in your Windows domain can be subordinate servers to an Active Directory–based NIS master server.

Note: An SFU Server for NIS can’t be a subordinate server to a UNIX NIS master server—only to an SFU Server for NIS master.

NFS and User Name Mapping

In environments in which there are substantial NFS file system resources and UNIX NFS clients but that are not running NIS or where the NIS Master Server will reside on UNIX, you should consider installing Server for NFS, Client for NFS or Gateway for NFS, and User Name Mapping. You need to install only a single User Name Mapping service, but you can install more if you are on a subnetted network or you have a large number of Windows NFS clients and want to distribute the load appropriately.

Gateway for NFS Tips

You can install either Client for NFS or Gateway for NFS on a Windows 2000 or Windows Server 2003 server but not both. If your use of NFS is relatively light, you may find that Gateway for NFS is a cost-effective choice. It provides a way for Windows clients to connect to the existing NFS file system resources without having to have a Client for NFS loaded on their machines. However, keep in mind that heavy NFS use could overload the gateway server, creating a bottleneck in the system.

Client for NFS Tips

You should install the Client for NFS on any server or Windows XP Professional or Windows 2000 Professional machine that will make heavy use of NFS file system resources. If you have at least one server that is running Gateway for NFS, you can use that server to make NFS resources available to less demanding clients and Windows 9x clients. However, you should install Client for NFS on all machines that will require substantial and regular use of files stored on NFS servers.

Server for NFS Authentication Tips

If you're sharing file system resources to UNIX clients using Server for NFS, install Server for NFS Authentication on all machines running Server for NFS and on all domain controllers in all domains where user accounts will be authenticated against for access to the NFS shares. The sole exception to this are Windows Server 2003 domains in which the forest is at the Windows Server 2003 functionality level.

User Name Mapping Tips

Install User Name Mapping on one or more servers, preferably a domain controller if possible. Doing so enables you to map user names in each environment in a way that is essentially transparent to the users. If you have a cluster available, User Name Mapping Server can be installed on it, providing for increased availability.

Password Synchronization (Two-Way)

In an environment in which you have a large number of both Windows and UNIX users, and where a substantial number of those users work in both operating systems, you should install password synchronization if your UNIX systems are on a supported platform.

If your UNIX systems are not running one of the supported platforms, you may still be able to run Password Synchronization by compiling the supplied daemons (SSOD and PAM) for your platform using the supplied make file.

Tip: Password Synchronization does not support dissimilar names, nor does it use User Name Mapping. In any environment in which you want to use password synchronization, you should make every effort to align your user names (including case, as UNIX is case-sensitive) on the two platforms to facilitate central management of passwords.

Use Scenarios

Central Password Administration

One of the largest sources of frustration for users and administrators in a mixed UNIX and Windows environments is managing and maintaining the different accounts in the two domains. This is especially true in large, security conscious environments in which regular password changes are required and enforced. Windows Services for UNIX 3.5 gives you the tools to simplify this process.

There are several ways to handle central password maintenance, depending on how your environment is configured and what your specific needs are. The three basic mechanisms are:

  • Active Directory–based NIS master server.

  • User name mapping.

  • Password synchronization (two-way).

Each of these mechanisms approaches the problem of central password administration from a slightly different perspective, but they each have their place and can complement each other.

In a large enterprise environment in which there is a well-established base of UNIX users and administrators, it might not be possible to implement NIS as part of Active Directory. In these environments, you can use a combination of password synchronization and the User Name Mapping servoce to achieve much the same result. User name mapping will help you leverage your existing UNIX resources by making it easier for users to connect to the NFS file systems even when they have different account names in the two environments. Password synchronization will work with those accounts that have the same name in both environments to keep the passwords synchronized—regardless of whether the UNIX environment is using NIS or /etc/passwd as its primary authentication mechanism.

In environments that are adopting Windows 2000 or Windows Server 2003 and Active Directory, there is a major opportunity to simplify and consolidate all account maintenance into a single, easy-to-manage and maintain location—Active Directory. Using the NIS Migration Wizard, you can migrate your existing NIS domain to Active Directory, converting your existing NIS master server into an NIS subordinate server that points to the new Active Directory–based NIS master server. For cases in which dissimilar accounts exist in the two environments, the User Name Mapping service provides a simple mechanism to map accounts between the two.

Tip: Server for PCNFS provides full support for PCNFSD and user authentication for accessing NFS file resources to all NFS clients that can’t use User Name Mapping (such as SFU 1.0 clients). You should install Server for PCNFS on the same server as User Name Mapping for simplicity and ease of maintenance.

Common File Systems

Many enterprises have significant storage resources already committed in the UNIX environment and would have a substantial cost associated with either moving those resources to Windows or worse, having to replicate them in both environments. Windows Services for UNIX provides the mechanism to unify the file systems between the two environments, giving you a single, common file system that both sides can take advantage of. Use Server for NFS on your Windows servers to provide easy access to the Windows file systems for your UNIX servers and clients, and use a combination of Gateway for NFS and Client for NFS to provide transparent access to existing UNIX storage resources to your Windows servers and clients.

One important consideration when implementing Client for NFS or Gateway for NFS in the enterprise is deciding which one is appropriate for each situation. Gateway for NFS is appropriate when you need to support occasional and relatively light use of the NFS storage resources to Windows clients in a completely transparent way to users. It is not, however, appropriate for heavy or frequent use if a user either runs programs from the Server for NFS or stores large data files or documents on the server. In these cases, the full Client for NFS is more appropriate, preventing the Gateway for NFS from becoming a bottleneck. In most environments, a mixture of Gateway for NFS and the Client for NFS is the best and most cost-effective choice. You should use the full Client for NFS on those machines for which users require the extra bandwidth, and use Gateway for NFS to support occasional or light duty users in a way that provides a seamless and easy-to-support common file system between the two environments.

Application and Script Migration

The Interix subsystem technology in Windows Services for UNIX 3.5 makes it an excellent way to migrate UNIX applications and scripts to bring them to the Windows platform. With the full Interix SDK and the popular and widely supported GNU SDK and compilers in Windows Services for UNIX 3.5, enterprises can re-target their UNIX applications to run natively under Windows.

Interix uses a single rooted file system, giving UNIX applications and scripts the environment they expect, with files and directory structures that are familiar and require little or no change to source code to compile and run successfully.

Summary

Windows Services for UNIX 3.5 is a full interoperability toolset for integrating Windows and UNIX environments. Windows Services for UNIX 3.5 includes platform interoperability components, joint management components, and application migration components in one fully integrated and supported product from Microsoft. It also includes the tools to give you better business value while implementing better IT management across an enterprise. Windows Services for UNIX 3.5 offers robust cross-platform file system support, central user administration, and a UNIX application execution environment that runs on top of the Windows kernel, enabling UNIX applications and scripts to run natively on the Windows platform side by side with Windows applications.

Related Links

For the latest information about Windows Services for UNIX, see the Services for UNIX website at http://www.microsoft.com/windows/sfu.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.