Hosting linux ssh unix

When Microsoft announced plans to build interoperability bridges from its Windows 2000 operating system to heterogeneous operating system platforms, some industry watchers were skeptical. After all, when had Microsoft ever concerned itself with interoperability?

As it turns out, Microsoft has made good on its promise. Not only did the company release its long-awaited Windows 2000 Services for Unix in early April, but it also took the wraps off its much anticipated Windows 2000 Services for NetWare in July. Not bad, eh?

How, then, does Windows 2000 Services for Unix -- renamed Windows Services for Unix 2.0 -- measure up? Does it provide IT managers with the tools they need to effectively manage Unix environments from Windows 2000 and -- more importantly -- to manage their Windows 2000 environments from Unix? How does it compare with other freely available open source software (OSS) tools from both the open source community and established vendors?

To answer these and other questions, we put Windows Services for Unix 2.0 through its paces.

Installation

We installed Windows Services for Unix 2.0, MKS Toolkit, and Cygnus Solutions' Cygwin on an AMD Athlon 600-MHz system with 256 MB of RAM running Windows 2000 Advanced Server with Service Pack 1 (SP1) installed. Our lab environment consisted of a hodgepodge of Windows NT 4.0 client machines; a Windows NT 4.0 Server with SP5 running Oracle8; a Sun Solaris box running Netscape Enterprise Server 3.0; and a variety of Debian Linux servers -- six in all -- that handled tasks ranging in scope from simple Web serving with Apache, to firewall and IP masquerading, to DNS.

Windows Services for Unix 2.0 does not install remote shell (rsh) by default. This is good because rsh is generally considered less secure than the legacy Telnet protocol.

On the other hand, it doesn't install the Unix cron scheduling utility by default either. This means administrators will have to use cron on Unix systems and AT.EXE on Windows NT/2000 systems to schedule tasks. We installed cron after installation was complete, which allowed us to manage scheduling on our Windows 2000 and Windows NT systems from our Solaris and Linux servers. Very nice. Perl fans out there will also want to note the fact that Windows Services for Unix 2.0 doesn't install Microsoft's ActivePerl implementation by default. We like Perl, so we installed ActivePerl during our post-install configuration of Windows Services for Unix.

On the Treadmill

Two stars of the Windows Services for Unix's portfolio are its support for Network File System (NFS) -- the Unix standard for network file sharing -- and its integration, by way of Active Directory, with NIS, a pseudo-directory naming service first developed by Sun Microsystems that has become a de facto Unix standard.

We didn't have a chance to put MS through its paces -- we don't use it internally, and we weren't too keen on rolling out Active Directory to test the integration and interoperability between the two -- but we did take advantage of Windows Services for Unix's NFS gateway support. In all, we found that administrators and users who would rather mouse in a GUI than cat from a Unix command line will love the integration of NFS with the now-familiar Network Neighborhood. NFS shares are easily mapped just like SMB shares, and the NFS Gateway translates NES shares to Windows-native SME shares, for easy exporting to 9x clients.

We also found Windows Services for Unix's new Telnet client to be a godsend: We would have much rather instructed a monkey to carry index cards to a terminal and enter commands manually than use the old Windows Telnet client. But the client shipping with Windows Services for Unix 2.0 is as close to a standard RFC-compliant implementation as Microsoft will probably ever get. For anyone who is not interested in preserving network security by encrypting terminal emulation settings -- using secure shell (ssh), for example -- the new Telnet client is a huge improvement over what was previously available.

Microsoft's ActivePerl implementation seems to be the real deal, as well. Although we didn't get to play around with it extensively, it seemed to offer a fundamental reduplication of the feature set found on Unix platforms. More importantly, our noses could barely detect a whiff of the proprietary embrace-and-extend odor that hovers around many of Microsoft's other adoptions of OSS technologies, such as Kerberos.

As far as overall manageability is concerned, we found the management tools included with Windows Services for Unix to be exactly what we expected: simple yet powerful, and requiring a minimum of interaction with the command line. This has always been Windows' strong suit We do have more than our fair share of gripes about Windows Services for Unix 2.0, however. Although the Telnet daemon that it ships with provides enhanced support for more simultaneous multiuser sessions -- up to 50 -- it still supports only the legacy Telnet protocol. With this in mind, we have to wonder to what extent enterprise IT organizations are still using vanilla Telnet. It sends passwords in clear-text over the wire and consequently poses a significant security risk. Why, then, couldn't Microsoft have provided an ssh daemon for Windows Services for Unix 2.0? This would have been of real value to mixed Windows and Unix shops alike -- and it alone could have justified the deployment of Windows Services for Unix 2.0 in many enterpris e IT organizations.

Then there is the issue of Windows Services for Unix only providing support for the sh shell, which lacks Unix essentials such as tab completion and is suitable primarily as a scripting environment. As it is, we wonder why Microsoft couldn't have included support for a shell such as bash, which has gotten pretty popular. It's even included with Solaris. And if not bash, why couldn't Redmond at least have provided support for ksh or csh? As it stands, if you want a functional Unix shell in a Windows environment, you'll have to pay for the MKS Toolkit, which ships with both ksh and csh.

The prospect of using Windows Services for Unix's Password Synchronization component to simultaneously manage passwords on Windows and on Unix boxes excited us, so we were destined to be disappointed in this regard. Indeed, while Windows Services for Unix 2.0 does perform secure password propagation, it only leverages the deprecated Unix crypt encryption scheme and does not support the modem MD5 algorithms that any sensible administrator would use. We did find Windows Services for Unix 2.0's User Name Mapping feature to be a joy. It allowed us to map the Windows 2000 group privileges to equivalent Unix group privileges. Thus, we could map our Windows 2000 "Administrator" group to our Unix "root" group -- which means that we could access NFS shares and perform other administrative tasks with less acrobatics. Finally -- and this is nothing more than a quibble -- while putting Windows Services for Unix through its paces we discovered that its "find" command causes a conflict with Windows 2000's own FIND.EXE com mand. This occurs because when Windows Services for Unix 2.0 is installed, Windows 2000's command path is modified to place the %SFUDIR%\ common directory before other directories. As a result, the Windows Services for Unix find command will run instead of the Windows find command, unless the path to the Windows find command is specified on the command line.

Conclusions

We're not quite sure what to make of Windows Services for Unix 2.0. On the one hand, we believe that both its native support for NFS and its integration with NIS are powerful features that many IT organizations will welcome. And we think that it will make it much easier for Windows administrators to manage Unix systems from Windows environments.

However, we suspect that most Unix administrators will be dissatisfied with Windows Services for Unix. First of all, many of the features that it purports to provide -- a Unix shell environment, enhanced support for multiuser terminal hosting, and a Perl implementation, among others -- are usually available separately, and free of charge, from open source software development projects. Secondly, its support for necessities such as multiuser terminal hosting -- Telnet only -- and a Unix shell environment -- sh only -- is bare bones, at best, and is of dubious value. On the plus side, its cron utility did let us schedule Windows 2000 events from our Unix platforms, which was a welcome touch. And we were able to establish password synchronization and user name mapping between our Unix and Windows 2000 systems, which also was welcome.

In summary, Windows Services for Unix 2.0 seems to have stacked the deck, so to speak, in favor of managing Unix systems from Windows -- rather than the other way around.

Windows Services for Unix 2.0

Microsoft Corp., Redmond, Wash.

www.microsoft.com

Price: $149

Pros/Cons: