The Network Neighborhood

The native mechanism for Windows folk to share disks on servers or with each other is through the Network Neighborhood. In a typical scenario, users attach to a share and have the system assign it a drive letter. As a result, the separation between client and server is clear. The only problem is that this method of sharing data is more people-oriented than technologyoriented: People have to know which servers contain which data.

Windows 2000 introduced a feature long available on UNIX systems: mounting. By mounting a share, Windows makes the share look as if it were just another directory located on the user’s local disk. This gives the illusion that a single unified directory structure exists, completely local to the machine. Microsoft’s Distributed File System (Dfs) allows a networkwide amalgamation of directories that can be configured and accessed as a directory tree. Windows .NET Server improves Dfs management features and allows a single server to host multiple Dfs trees.

Linux, using the Network File System (NFS), has supported the concept of mounting since its inception. This allows any directory to be “exported” for mounting on other systems. The mounted directory can be placed anywhere in the remote system’s directory tree. A common example of mounting partitions under Linux is with mounted home directories: The user’s home directories reside on a server, and the client mounts the directories at boot time (automatically). So /home exists on the client, but the contents of /home/username exist on the server.

Under Linux NFS, users never have to know server names or directory paths, and their ignorance is your bliss! As with Dfs, there are no more questions about which server to connect to. Users need not know when the need arises to change the server configuration.

Under Linux, you can change the names of servers and adjust this information on client-side systems without making any announcements or having to reeducate users. Anyone who has ever had to reorient users to new server arrangements is aware of the repercussions that may occur. Module 8 discusses the Linux Automounter, which dynamically mounts and unmounts partitions on an as-needed basis.

Printing works in much the same way. Under Linux, printers receive names that are independent of the printer’s actual host name. (This is especially important if the printer doesn’t speak TCP/IP.) Clients point to a print server whose name cannot be changed without administrative authorization. Settings don’t get changed without your knowing it. The print server can then redirect all print requests as needed. The Linux uniform interface will go a long way toward improving what may be a chaotic printer arrangement in your installation.
It also means you don’t have to install print drivers in several locations.

NOTE
If you intend to use Linux to serve Windows clients via the Samba package, you’ll still
have to deal with notifying users about server shares and printer assignments. You can
read more about Samba in Module 18.