Working with Microsoft's Services for Unix, Part 1

In this first installment of a two-part series, Emmett explains how this free tool is essential for any integrator's toolbox.

• By Emmett Dulaney
• 07/31/2006

Because this product is so significant and sizable (12,313 files unzip from the download), this is the first in a two part series exploring the product. This month, we will look at the basics of it and why it is needed. Next month, the focus will be on some of the more advanced uses and features of the tool.

How Do You Get SFU?
SFU is available as a download from http://www.microsoft.com/downloads. As with many of the offerings there, you must register before you can download, but there is no charge to do so. Depending upon the speed of your connection, it could take some time (it is a substantial file). Once it completes, you simply unzip and install. Based upon what you choose to install, you need between 20 and 360 MB of disk space (the high number is the one you want to focus on).

SFU runs on Windows XP Professional, as well as Windows 2000 (Professional and Server) and Windows Server 2003 (all versions).

The installation instructions included with the product all talk about a CD-based installation, but this is no longer applicable. To install, simply run the setup.exe file, which starts the installation wizard shown in Figure 1.

[Click on image for larger view.]

Figure 1: The installation wizard walks you through the installation of Services for UNIX.

Accept the license agreement and choose your type of installation. A Standard installation includes the most common components, while a Custom installation lets you pick and choose what you want. Regardless of the type chosen, it is important to know that after the installation almost everything you installed is disabled by default (there are just a few exceptions) -- this is done for security reasons and you should not be alarmed when the components aren't enabled upon completion. While it can be irritating, you can understand why such things as cron are disabled until enabled by the administrator.

As you walk through a few other dialog screens, you choose, among other things, if you want to use remote user name mapping or local user name mapping, as shown in Figure 2, below. This is a crucial item in the synchronization of user accounts: By using user name mapping, it is possible to access files on other computers without always needing to provide the authentication information manually -- the infamous single sing-on that every administrator pursues.

[Click on image for larger view.]

Figure 2: Choose the user name mapping configuration during installation.

Whether you choose to use NIS or password and group files at this point, you must supply the Windows domain name. The files will then copy to their correct directory location (which will take a while). When the process completes, SFU is added to the programs menu, as shown in Figure 3.

[Click on image for larger view.]

Figure 3: After the Standard installation, SFU appears in the All Programs menu on a Windows XP workstation.

What Is It?
Simply put, SFU is a toolkit that lets you have a great deal of interoperability between Windows and Linux/Unix. It includes the C and Korn shells, cron, perl, Telnet and the Interix GNU components including the Software Development Kit (SDK). NFS support is included as a client, server and gateway. Server for NIS, for NFS authentication and for PCNFS is included, as well. SFU adheres to the POSIX standards and has 350 of the most common 'nix utilities (almost all that you would expect to find).

A mix of utilities and configuration can be done at the command line and through the Windows interface. For example, to configure the most common elements, you can choose Services for UNIX Administration from the menu. This opens the familiar Microsoft Management Console (MMC) interface. Clicking on Performance, in this case, allows you to also configure the transport protocol to use, mount type, retry and buffer size settings.

NOTE: Using SFU can require a bit of system tweaking. For example, it is not uncommon for a Windows Security Alert to appear while you are working in the MMC telling you that Windows Firewall has blocked some features of the program. At this point, you can choose to keep blocking, unblock or ignore (Ask Me Later).

When you choose to open a shell, a command line interface appears and you can work interactively, run scripts and basically convince yourself that you are working on a 'nix system instead of Windows system. Figure 4, for example, shows a Korn shell session.

[Click on image for larger view.]

Figure 4: Working in the Korn shell.

Let's go through some of options:

• Client for NFS is used to allow mapping to NFS shares and those shares to appear as drive letters in the Windows system. This can be done independently of user name mapping (requiring the user to authenticate when they access) or in conjunction with it.
• Server for NFS is used to share directories as NFS file systems so that the 'nix users can access them and mount them just as they would any other share. Server for NFS uses user level security (UID and GID) and can also work in conjunction with user name mapping for simplification.
• Gateway for NFS enables a Windows server to allow 'nix users to access shared (exported) filesystems on NFS as simply as possible. It is often used when transparency is important.
• Server for PCNFS simply allows Windows users running PCNFS to access shares by giving their authentication information. It does not work with user name mapping and is typically reserved for special circumstances.
• Server for NIS integrates the NIS (Network Information System) with Active Directory. The Active Directory server becomes the master server for the NIS domain and keeps the entries updated.
• Telnet allows command line access incorporated with Windows-based authentication. This is more secure than most default Telnet implementations in that passwords are not sent in their unencrypted state across the network.

Why Would You Use It?
There are so many components to SFU that just listing them one by one would probably serve as a great laundry list of good reasons; however, the two best answers are one, that it's free, and two, that it provides in one concise package a collection of utilities that you could expect to pay a considerable amount for if purchased from another source.

SFU is useful for interoperability at a number of different levels. If you just want to dabble around, you can open the C or Korn shells and play with scripts at the command line. If you want integration between different hosts that will be running side by side for quite a while, you can benefit from the features that SFU includes. If you are considering migrating from one operating system to another, the Interix porting tools and SDK are just what you are looking for.

Regardless of your reason, you will not find another integration product on the market that should be in every toolkit the way SFU should.

Next Month
Now that SFU has been installed and you are familiar with the tools, next month the Integration Station column will put the product through some of its more useful paces, including password synchronization and telnet. If you have any questions or comments in the meantime, please post them below or visit our Integration forum.