Microsoft Distributed File System (DFS)

Like NFS, DFS employs a tree structure for file systems. A directory that is being imported by a client is attached at a point somewhere in the local file system, where it is then made available to applications as if the directory and its files were local.

The Windows Server family (both 2000 and 2003 versions) includes DFS as an integral part of the operating system. The interface is written as a snap-in to the Microsoft Management Console (MMC) tool, making administration a simpler process. A wizard prompts you through setting up a DFS root, and from there on out you can add, modify, or remove directory paths from the DFS tree. Paths represented in the DFS tree can come from one or more servers on the network. A tree is not bound by a single host.

In Windows NT 4.0, directory replication allowed you to create copies of directories on multiple systems, keeping them in sync. This functionality was replaced in Windows 2000 Server with Distributed File System (though it is also possible to download DFS for Windows NT 4.0). DFS is now included as a part of modern Windows operating systems. DFS allows you to move away from the \ \server\

sha rename concept to one based on the domain. Instead of having to remember (or browse and find) on which server a particular file share is hosted, you can use DFS to create shares that are global to the domain. That is, if you're a member of the domain, you can specify the share as \ \domainname\ share. DFS also allows for replication. This means that you can have more than one copy of the data being shared, but only have to use the global domain-wide share name to connect. This provides for some fault tolerance. If a server goes down that happens to host a replica of a share, then the other servers that contain copies of the share can be connected to by users. Note that this does not provide any kind of failover if a server crashes. The user can, however, restart her work by reconnecting to the share. The connection will be made to another replica of the file share.

Important terms to understand when dealing with DFS are listed here:

• Root—A server can have only one root installed. It is just about the same thing as a file share, with a few differences, which will become apparent shortly.
• DFS link—Under the root you create DFS links. These are links to file shares that will be available under the root you have created. This means you can create a single root yet place multiple shared directories under the root so that only one file share connection is necessary. If not, users would have to connect to each directory as a separate file share.
• Replica—You can create shares that replicate the data in other shares. This can be done to provide for both load balancing and a degree of fault tolerance.

Network File System

The NFS client allows Windows clients to connect to NFS file systems hosted on Unix servers. The client can connect to the file system exported by a Unix server using several methods. The simplest methodis to use the Windows Explorer Accessory; click on My Network Places, and select the server you want to connect to from the right-side pane. Then use Tools, Map Network Drive to make a drive letter to the NFS file share. You also can use the command line to connect to NFS file systems. To make matters simpler for a network that's composed of both Unix and Windows users, several syntaxes are supported:

net use—The standard Windows net use command can be used to connect just as you can to a normal Windows file share. The specification of the resource to which you want to connect can be expressed as a standard Windows file share (net use * \\server\sharename), or you can use a format that's similar to using the Unix mount command (net use * server/ sharename). Note, however, that the second (Unix) syntax will result in the connection being set up more quickly.

mount—Those of you more familiar with NFS might prefer to use the mount command. Again, you can use either the Windows or Unix format to specify the resource to which you want to connect; for example, mount server/ sharename * or mount \\server\sharename.

In the preceding syntax examples, the asterisk character causes the next available drive letter to be assigned to the resource. You also can specify a particular drive letter. In either case, after the connection has been made to the NFS resource, you can then use Windows applications to access files on the resource just as if they were Windows file shares.

SFU also provides for these:

• Server for NFS—Use this to allow Unix clients to access file shares on Windows NT through Windows 2003 computers using standard Unix NFS commands. After this component is installed, you can offer a Windows directory as a file share by clicking on the NFS Sharing tab that's located on the properties page for a directory using Windows Explorer. Alternatively, you can use the command line to offer a directory on a Windows server to create the NFS share. The syntax for this is nfsshare sharename=drive :path.
• Gateway for NFS—Use this when your Windows clients need to make only moderate use of Unix NFS file systems. By using a gateway, you need to load SFU on only a single server, and it acts as a gateway, making the connections to Unix NFS file systems for Windows clients. The Windows clients connect to a file share offered by the gateway. If your Windows clients will be using NFS resources heavily, load the SFU client software instead so that the gateway does not become a bottleneck in a bandwidth-limited network.
• Server for PCNFS—This component enables a Windows NT or Windows Server to act as a PCNFSD server. This provides for authentication when connecting to NFS resources.

Using these components, you can grant access to both sets of clients—Unix or Windows—to files stored on the other's systems. One limitation you should note for the gateway service is that you're still stuck with the drive letter limitation. Suppose that your network has a large number of Unix servers and each exports an NFS file system. For each connection, the gateway server will use one of its drive letters that could normally be mapped to a regular Windows file share.

Korn Shell

The Korn Shell commands that SFU gives to Windows NT/2000/2003 and Windows XP enable you to use existing script files that run on Unix systems. For users trained on Unix systems, the Korn Shell commands make it much easier to add Windows computers to their flock of computers that must be administered.

Tip

Although SFU 3.5 provides a great deal of functionality to Windows that appeals to Unix/Linux administrators, there are other products that can offer similar functionality. Some are comprehensive, such as SFU, whereas others offer partial solutions.

Some of these commands, such as mkdir and find, are already familiar to Windows NT users. However, their functions in the Korn Shell might differ from those provided by the standard Windows implementation. For Unix administrators, the addition of these commands can make moving into managing Windows NT and Windows Server computers a simpler transition. You can use the Unix commands listed in Table 55.1 and, at the same time, become familiar with the Windows Script Host (WSH). WSH enables you to create scripts using VBScript or JScript so that you aren't stuck using only the familiar MS-DOS commands that have been the mainstay for creating script files on Windows systems for more than 20 years. In addition, SFU provides an implementation of Perl that can be used with WSH.