Windows 2000 has slowly taken the field to defend Microsofts LAN server dynasty, but Linux is making a series of it. Sooner, rather than later, youre going to run into customers who want both. And it will be up to you to turn a double play. Boot the ball or make an errant recommendation, and you could wind up like the N.Y. Yankees Chuck Knoblauch—an outcast in left field.
Dont think your NetWare and NT customers are ready to send Windows 2000 or Linux up to the plate? Think again. While concerns about Windows 2000 system requirements (and Win2000 Active Directorys (AD) stability and Linuxs perceived immaturity) still exist in CIOs minds, both operating systems are gaining corporate fans.
This is also because both OSes have made major improvements. Windows 2000 was first with its July 2000 release of SP1. Corporate buyers were assured that Win2000 had passed through the infamous version 1.0 teething phase. Toward the end of 2000, the operating system also gained some much needed server-level applications with Exchange andSQL Server 2000 in the fall.
On the Linux side, the long-awaited release of 2.4 in January 2001 gave Linux the journaling file system (JFS), logical volume management (LVM) and large memory-handling abilities that buyers wanted to see from an enterprise-level server.
Together, Windows 2000 and NT commanded 41 percent of all server OS shipments in 2000. Al Gillen, manager of International Data Corp.s system software research, predicts that Windows 2000 will represent almost 71 percent of Microsofts server OS shipments by 2001s end.
Microsoft wont pitch a perfect game, though. In a report, Laura DiDio, an analyst for Giga Information Group, states that, "mainstream corporate [Windows 2000] deployments will begin in earnest in midyear, steadily climbing in the third and fourth quarters." but selling Windows 2000 has its own unique Microsoft-driven problems. "The licensing and complexity issues surrounding Windows 2000 deployments are enough of a challenge to thwart even the staunchest Windows organizations," DiDio says. "The looming ship date of Whistler [Now Windows XP]" is causing customers to ask, "whether or not they should delay deployments to Windows 2000 Professional and Server, and wait until after Whistler ships," she adds.
Linux, of course, faces familiar problems of open source: fear, uncertainty and doubt—problems that are in no small part kept alive by Microsoft. Even so, Linux carries a big bat. The OS now controls 26 percent of the server market, second only to Microsoft, according to IDC. Microsoft operating systems still may be the New York Yankees, but Linux, like the Boston Red Sox, keeps making a game of it.
Theyre Taking the Field So with both operating systems taking the field, what do you need to know to make sure theyll work and play well with each other? The answer: a lot.
For starters, both servers software should be kept up to date. That doesnt, however, mean that you should immediately update to the latest bleeding-edge code. We know that, but we know administrators who think nothing of trying out the latest Linux update or Microsoft Hot Fix on working servers. Thats a mistake. A bad mistake.
Instead, unless you have a concrete reason to make a change—you need a specific driver or bug fix—you never should install the latest and greatest. Hot Fixes are especially dangerous this way.
The same is true for Linux 2.4. While SuSE has a commercial version out of the 2.4 kernel, the other business Linux distributors, Caldera, Red Hat and TurboLinux, have opted to wait until theyve thoroughly tested out the newest and best in spring training before pitching it to the major league. Unless youre a Linux expert yourself, youd be well-advised to follow their lead and wait until their distributions are released before moving to 2.4.
Throwing Internet Heat The foundation for any server in 2001 is the ability to work with the Internet—and that means putting the Domain Name Server (DNS) into play. Fortunately, both Linux and Windows 2000 have excellent DNS servers that are completely compatible with each others clients.
Which should you use? We prefer Linuxs Berkeley Internet Name Daemon (BIND) 8.0, but frankly Windows 2000 DNS service, subsumed within AD, is good and leaves NTs DNS back in the minor league where it belongs. Its really a matter of which system you feel more comfortable with. You could, for that matter, run multiple DNS servers on both Linux and Windows 2000 servers on a single network without a hitch.
If your clients arent using fixed IP addresses, you should look into deploying Dynamic DNS (DDNS). With DDNS, machines with addresses assigned by Dynamic Host Configuration Protocol (DHCP) are much easier for other systems to find. That, in turn, means youll need to edit your DNS configuration far less often. And, by also using the newest DNS option, Service Resource Records, your customers can use DHCP to assign dynamic IP addresses to servers.
Put DDNS together with Microsofts Windows Internet Naming Service (WINS) and Lightweight Directory Access Protocol (LDAP), and youll have a hybrid network that automatically can handle both IP and NetBIOS names. You then can take this one step further with Samba Server Message Block (SMB) file servers on a Unix machine and have them appear on WINS, as well. For the sake of simplicity, though, we recommend giving Samba servers a static IP address. The upshot of all of that is youll have a hybrid server system where your client PCs can access both Unix and Windows file and print and other services, with little administrative time wasted on resolution issues.
Making the Directory Hit In theory, on the Windows side, you dont need to bother with WINS anymore, thanks to AD. That looks great on paper, but implementing AD in the field is still difficult, even when all of the servers are running Windows 2000. On a hybrid network, with NT and Unix servers still using the NT domain style, the complications can get as scary as a Roger Clemens bean ball.
Nevertheless, some customers demand AD. Fortunately, you can get AD- and Unix-style directories to get along. One way to hit this home run is to use Windows Services for Unix (SFU) 2.0, enabling one-way password synchronization. The name of the game here is simply to avoid using Unix directory services entirely. This can actually work quite well in situations where the Linux servers work entirely on the back end, well away from interactive users.
With this one-way synchronization method, all password changes are handled by AD. This doesnt, however, give you a single login to both networks. You still have to log in twice, in many circumstances. A user still can hit a foul using the Linux password utility to change their password. All this method really does is enable you to make it possible for user passwords to be set on the Windows 2K system and then automatically have the Unix systems synchronize them. Its no game-winner, but it does cut down considerably on the constant confusion of unsynchronized user/password systems.
Batting Practice If you want to do more, start taking your LDAP practice swings now. Under the surface, AD uses LDAPv3 as its core protocol. To make AD work with Unix/Linux LDAP servers, you can use the C application programming interface (API) to allow AD to talk with external LDAP servers that also use the C API.
If that sounds like too much work—and we can tell you from personal experience that it is—you can make your life easier by using LDAPv3 compliant servers on both Windows 2000 and Linux. The best of these is Innosofts Distributed Directory Server (IDDS). It runs not only on Windows 2000 and Red Hat Linux, but also on AIX, Compaqs Tru64 Unix, Hewlett-Packards HP-UX and Suns Solaris, making it the most flexible choice. Another alternative is Novells eDirectory, with Linux, Solaris and NetWare (and now, AIX and Tru64 Unix) support. Dont be fooled, though. Getting AD and Unix directories to play as a team is always a custom programming job, even with the best tools.
Tossing Out File Systems You can argue with the CIO umpire all you want about which server file system is best (its FAT32 for Windows 2000 and ReisterFS for Linux, by the way) for networking, but what you really care about is getting clients access to remote file systems. There are two ways, one Unix-based, Network File System (NFS), and the other, Microsofts Server Message Block protocol (SMB).
NFS is an industry standard for users to share files across platforms. But NFS is not an all-star, because of its security problems. Proper network security can prevent those from becoming an issue. SMB doesnt have NFSs security troubles. But, even with its newest version, Common Internet File System (CIFS), its really a solution only for Windows clients requiring access to Windows or Linux servers.
For our purposes, you easily can use both to give your users maximum flexibility. SFU provides NFS server, client and gateway services for W2K. The gateway is used to give Windows PCs access to NFS shared file systems just as if they were SMB shared files. Windows 2000 Professional comes with its own NFS server so it can access Unix NFS files without any additional software or the gateway.
Microsoft is not the only company, however, that enables you to let Windows users access NFS shares. Hummingbirds Maestro Suite has long set the standard for Windows-based NFS services.
On the other side, the open-source Samba is the Sammy Sosa of SMB servers. Almost all Linux distributions include it, and it can be compiled and run on most Unix boxes.
While Sambas advanced functionality—such as being able to run as an NT primary domain controller (PDC)—wont work under AD, its primary file service runs like Ricky Henderson during his base-stealing heyday.
There are, however, two potential trouble points. The first is that the Windows 2000 domain cant be set for Kerberos authentication only. Since ADs default is to allow NT style authentication, that shouldnt be a problem. You also must be sure to be running Samba 2.07 or higher. Earlier versions wont make the Linux/Windows 2000 team.
Playing for the Championship People often talk about Windows 2000 and Linux like theyre in head-to-head competition. But thats not always the case. We expect to see more situations develop where the two operating systems will need to work together as teammates.
Even Microsoft agrees. While the details of bringing .Net to Linux and other operating systems are vague, Microsoft is showing more willingness to work with Linux than ever before. Even if Microsofts promises turn out to be vapor, Ximian (www.ximian.com)—formerly Helix Code, led by the Gnome leader Miguel de Icaza—is porting the Simple Object Access Protocol (SOAP), a core interoperability mechanism in .Net, to Linux.
Even with such efforts, interoperability wont be easy. But integrators who get the pair to work together on an all-star team can expect to see major-league profits. And, yes, we are talking Alex Rodriguez numbers.