Chapter 28. Networking - UNIX and Windows Interoperability

CONTENTS

Chapter 28. Networking - UNIX and Windows Interoperability

•  NFS and X Windows
•  TCP/IP Networking Background
•  NFS Background
•  Using Windows and UNIX Networking
•  File Transfer Protocol (FTP)
•  Other Connection Topics

NFS and X Windows

This chapter and Chapter 24 combine to provide background on some useful interoperability. In this chapter, I use a networking product on the Windows system that provides transparent access to the data on the UNIX system using Network File System (NFS). In Chapter 24, I covered Windows and UNIX interoperability by running an X server program on a Windows system, providing graphical access to a UNIX system. Using the X Window System (X Windows), you have a graphical means of connecting a Windows system to a UNIX system, and using NFS, you have a way of easily sharing data between these two systems. These two technologies, X Windows and NFS, provide the foundation for a variety of other useful interoperability techniques between the two operating systems.

Although I provided TCP/IP background earlier in the book, I am going to include it again here so that you don't have to flip back and forth if you have to review TCP/IP.

TCP/IP Networking Background

You can see the seven layers of network functionality in the ISO/OSI model shown in Figure 28-1. I'll cover these layers at a cursory level, so that you have some background into this networking model. The top layers are the ones that you spend time working with, because they are closest to the functionality to which you can relate. The bottom layers are, however, also important to understand at some level, so that you can perform any configuration necessary to improve the network performance of your system and have a major impact on the overall performance of your system.

Figure 28-1. ISO/OSI Network Layer Functions

I'll start reviewing Figure 28-1 at the bottom, with layer 1, and describe each of the four bottom layers. This model is the International Standards Organization Open Systems Interconnection (ISO/ OSI) model. It is helpful to visualize the way in which networking layers interact.

Physical Layer

The beginning is the physical interconnect between the systems on your network. Without the physical layer, you can't communicate between systems, and all the great functionality you would like to implement will not be possible. The physical layer converts the data you would like to transmit to the analog signals that travel along the wire (I'll assume for now that whatever physical layer you have in place uses wires). The information traveling into a network interface is taken off the wire and prepared for use by the next layer.

Link Layer

In order to connect to other systems local to your system, you use the link layer that is able to establish a connection to all the other systems on your local segment. This is the layer where you have either IEEE 802.3 or Ethernet. These are "encapsulation" methods, named so because your data is put in one of these two forms (either IEEE 802.3 or Ethernet). Data is transferred at the link layer in frames (just another name for data), with the source and destination addresses and some other information attached. You might think that because there are two different encapsulation methods they must be much different. This conclusion, however, is not the case. IEEE 802.3 and Ethernet are nearly identical. So, with the bottom two layers, you have a physical connection between your systems and data that is encapsulated into one of two formats with a source and destination address attached. Figure 28-2 lists the components of an Ethernet encapsulation and includes comments about IEEE802.3 encapsulation where appropriate.

Figure 28-2. Ethernet Encapsulation

One interesting item to note is the difference in the maximum data size between IEEE 802.3 and Ethernet of 1492 and 1500 bytes, respectively. This is the Maximum Transfer Unit (MTU). The data in Ethernet is called a frame (the re-encapsulation of data at the next layer up is called a datagram in IP, and encapsulation at two levels up is called a packet for TCP.)

Keep in mind that Ethernet and IEEE 802.3 can run on the same physical connection, but there are indeed differences between the two encapsulation methods.

Network Layer

Next, we work up to the third layer, which is the network layer. This layer is synonymous with the Internet Protocol (IP). Data at this layer is called a datagram. This is the layer that handles the routing of data around the network. Data that gets routed with IP sometimes encounters an error of some type, which is reported back to the source system with an Internet Control Message Protocol (ICMP) message.

Unfortunately, the information that IP uses does not conveniently fit inside an Ethernet frame, so you end up with fragmented data. This is really re-encapsulation of the data, so you end up with a lot of inefficiency as you work your way up the layers.

IP handles routing in a simple fashion. If data is sent to a destination connected directly to your system, then the data is sent directly to that system. If, on the other hand, the destination is not connected directly to your system, the data is sent to the default router. The default router, sometimes called a gateway, then has the responsibility to handle getting the data to its destination.

Transport Layer

This layer can be viewed as one level up from the network layer, because it communicates with ports. TCP is the most common protocol found at this level, and it forms packets that are sent from port to port. These ports are used by network programs such as telnet, rlogin, ftp, and so on. You can see that these programs, associated with ports, are at the highest level I have covered while analyzing the layer diagram.

Internet Protocol (IP) Addressing

The Internet Protocol address (IP address) is a class "A," "B," or "C" address (class "D" and "E" addresses exist that I will not cover). A class "A" network supports many more nodes per network than a class "B" or "C" network. IP addresses consist of four fields. The purpose of breaking down the IP address into four fields is to define a node (or host) address and a network address. Figure 28-3 summarizes the relationships between the classes and addresses.

Figure 28-3. Comparison of Internet Protocol (IP) Addresses

These bit patterns are significant in that the number of bits defines the ranges of networks and nodes in each class. For instance, a class A address uses 8 bits to define networks, and a class C address uses 24 bits to define networks. A class A address therefore supports fewer networks than a class C address. A class A address, however, supports many more nodes per network than a class C address. Taking these relationships one step further, we can now view the specific parameters associated with these address classes in Figure 28-4.

Figure 28-4. Address Classes

Every interface on your network must have a unique IP address. Systems that have two network interfaces must have two unique IP addresses. I will cover some networking commands in Windows in an upcoming chapter.

NFS Background

I am not going to limit the discussion and examples in this chapter to NFS. There are other services used to share files that are also useful, such as File Transfer Protocol (FTP), which I'll show examples of as well. Because NFS is so widely used in the UNIX user community, it is one of my goals to expose you to how NFS can be used in a Windows and UNIX environment.

NFS allows you to mount disks on remote systems so that they appear as though they are local to your system. Similarly, NFS allows remote systems to mount your local disk so that it looks as though it is local to the remote system.

NFS, like X Windows, has a unique set of terminology. Here are definitions of some of the more important NFS terms:

Node	A computer system that is attached to or is part of a computer network.
Client	A node that requests data or services from other nodes (servers).
Server	A node that provides data or services to other nodes (clients) on the network.
File System	A disk partition or logical volume, or in the case of a workstation, this might be the entire disk.
Export	To make a file system available for mounting on remote nodes using NFS.
Mount	To access a remote file system using NFS.
Mount Point	The name of a directory on which the NFS file system is mounted.
Import	To mount a remote file system.

Before any data can be shared using NFS, the UNIX system must be set up with exported file systems. The /etc/exports file is often used on UNIX to define what file systems are exported.

This file has in it the directories exported and options such as "ro" for read-only and "anon," which handles requests from anonymous users. If "anon" is equal to 65535, then anonymous users are denied access.

The following is an example /etc/exports file in which /opt/ app1 is exported to everyone but anonymous users, and /opt/app1 is exported only to the system named system2:

/opt/app1 -anon=65534  /opt/app2 -access=system2 

You may need to run a program such as exportfs -a on your UNIX system if you add a file system to export.

Although we are going to focus on exporting UNIX file systems to be mounted by Windows systems in this chapter, I can think of no reason that we could not do the converse as well. Windows file systems can be mounted on a UNIX system just as UNIX file systems are mounted in Windows. Remote file systems to be mounted locally on a UNIX system are often put in /etc/fstab. Here is an exampleofan entry in /etc/fstab of a remote file system that is mounted locally. The remote directory /opt/app3 on system2 is mounted locally under /opt/ opt3:

system2:/opt/app3 /opt/app3 nfs rw,suid 0 0 

You can use the showmount command available on many UNIX systems to show all remote systems (clients) that have mounted a local file system. showmount is useful for determining the file systems that are most often mounted by clients with NFS. The output of showmount is particularly easy to read because it lists the host name and the directory that was mounted by the client. You have the three following options to the showmount command:

-a	prints output in the format "name:directory," as shown above.
-d	lists all the local directories that have been remotely mounted	by clients.
-e	prints a list of exported file systems.

Using Windows and UNIX Networking

I use the NFS Maestro product from Hummingbird Communications Ltd. on Windows to demonstrate the networking interoperability in this chapter.

You would typically run your NFS client, such as NFS Maestro, on your Windows system in order to mount file systems on a UNIX system. This setup means that all your Windows clients would run NFS Maestro. Depending on the number of Windows systems you have, you may find loading an NFS client on each and every system to be a daunting task. Hummingbird Communications has an alternative. Rather than loading the NFS client on each system, you can use a Windows system to act as a gateway between your Windows systems and your UNIX systems. NFS Maestro Gateway bridges your Windows network to your UNIX network. All Windows clients go through the NFS Maestro Gateway system in order to perform NFS access to the UNIX systems, thereby simplifying the installation and administration of NFS on Windows.

NFS Maestro Gateway bridges your Microsoft Server Message Block (SMB) network to your UNIX network by acting as a proxy. It forwards SMB requests from a Windows client to a UNIX NFS server and vice versa.

The performance of using a dedicated NFS Maestro client is superior to that of using NFS Maestro Gateway. Like many system administration topics, there is a trade-off that takes place between simplicity and performance. In this chapter I'll cover using a dedicated NFS Maestro client to access file systems on a UNIX server.

Figure 28-5 shows the menu for the Maestro product after I installed it.

Figure 28-5. Hummingbird Maestro Menu in Windows

As you can see in Figure 28-5, there is much more than NFS functionality is part of NFS Maestro. I will cover some additional functionality later in this chapter; however, my specific objectives are to cover the most important Windows and UNIX interoperability topics related to networking.

The NFS icons can also be accessed as part of a group from the NFS Maestro icon, as shown in Figure 28-6.

Figure 28-6. NFS Group

Before we use NFS with our Windows and UNIX systems, let's first see what file systems we have available to us.

Using the Common Desktop Environment (CDE) on our Windows system from Chapter 15, we can sit at the Windows system and work on the UNIX system. Figure 28-7 shows the Common Desktop Environment with a Terminal window open:

Figure 28-7. Common Desktop Environment on UNIX with /etc/ exports Shown

There are several file systems exported on this UNIX system. Some, such as/home and /tmp, have no restrictions on them; others do have restrictions. We don't, however, have to open a Terminal window in order to see this file. We can use the NFS Maestro menu pick Exports to bring up the window shown in Figure 28-8:

Figure 28-8. Exports Window Showing Exported File Systems

You can use the IP address, as shown in Figure 28-8, or the host name to specify the host on which you wish to view the exported file systems. You can see that this window takes the /etc/exports file and clarifies some of the entries. The entries that have no restrictions now have an "(everyone)" associated with them, and only system nytc_interop may mount the other file systems.

Now we can specify one or more of these exported file systems on the UNIX system that we wish to mount on the Windows system. Using the NFS Network Access selection from the NFS Maestro menu, we can specify one of these file systems to mount. Figure 28-9 shows mounting /home/hp on the UNIX system on the F: drive of the Windows system. Note that we are UNIX user hp when we mount this file system.

Figure 28-9. NFS Network Access Window Mounting /home/hp as F:

After you click the Connect button on the window, you have /home/hp mounted as F:. The means by which you specify the system and file system you wish to mount with NFS Maestro is two slashes preceding the IP address or system name, another slash following the IP address or system name, and then the name of the file system that you wish to mount. Note that the forward slash is part of the file system name. I used the IP address of the system. To view all the mounted file systems on the Windows system, you can invoke Windows Explorer. Figure 28-10 shows several file systems mounted in an Explorer window, including /home/hp on F:.

Figure 26-10. Windows Explorer Showing /home/hp as F:

This window shows /home/hp on drive F:. On theright side of the window is a listing of files in /home/hp on the UNIX system. These files are now fully accessible on the Windows system (provided that the appropriate access rights have been provided). You may need to adjust the Explorer to Show all files in order to see the hidden UNIX files. You can now manipulate these UNIX files in Explorer on the Windows system just as if they were local to the system. This is a powerful concept - to go beyond the barrier of only the Windows file system to freely manipulate UNIX files.

The permissions of these NFS mounted files are not shown in the Explorer window. We can select specific files and view their properties. Figure 28-11 shows viewing the.cshrc file:

Figure 28-11. Viewing the Properties of.cshrc

The.cshrc file is Hidden and is not Read-only, meaning that we can manipulate this file.

Next let's view the properties of install.vars as shown in Figure 28-12.

Figure 28-12. Viewing the Properties of install.vars

install.vars is Read-only because this file is owned by root on the UNIX system and not by user hp, which is the UNIX user under which we mounted /home/hp.

We are unable to Chmod, or modify the permissions on this file, because it is owned by root and we have mounted /home/hp as the user hp, as shown in Figure 28-13:

Figure 28-13. Failed Attempt to Change Permissions of install.vars

This error indicates that we are prevented from changing the permissions on install.vars.

An example of how you might go about using Explorer is to copy a Windows NT directory to UNIX. Figure 28-14 shows two Explorer windows. The top window has an nfs directory on the Windows system, which is being copied to a directory of the same name on the UNIX system in the bottom window. As the copy from the Windows system to the UNIX system takes place, a status window appears, which shows the name of the file within the nfs directory (exp2.bmp) being copied.

Figure 28-14. Copying a Windows NT Directory to UNIX Using Explorer

This copy from Windows to UNIX using Explorer demonstrates the ease with which files can be shared between these two operating systems.

File Transfer Protocol (FTP)

I started this chapter covering NFS on Windows and UNIX for interoperability, because NFS is the predominant means of sharing files in the UNIX world. NFS is used almost universally to share data among networked UNIX systems. NFS allows you to share data in real time, meaning that you can work on a UNIX file while sitting at your Windows system. This approach is file sharing. You can also copy data between your Windows and UNIX systems using FTP. This approach is not file sharing; however, the FTP functionality of NFS Maestro makes it easy to transfer files between Windows and UNIX.

Figure 28-15 shows the dialog box that you would use to establish a connection to a UNIX system from Windows:

Figure 28-15. Establishing a Connection to UNIX from Windows

After having established the connection, a window appears in which you can traverse the UNIX file systems while working at your Windows system. Figure 28-16 shows viewing the /home/hp directory on a UNIX system through the FTP window.

Figure 28-16. Viewing the /home/hp Directory Using the FTP Window

You can also copy files graphically using FTP. You can open two FTP windows and copy files and directories from one system to the other. Figure 28-17 shows copying the directory c:\temp\x on the Windows system to /home/hp/x on the UNIX system. This was performed using the icons in the two windows. The x directory did not exist on the UNIX system and was created as part of the copy. As the copy from the Windows system to the UNIX system takes place, a status window appears, which shows the name of the file within the x directory (xmenu2.bmp) being copied.

Figure 28-17. Using FTP to Copy a Directory from Windows to UNIX

There are a variety of options you can select when running FTP. Notice in Figure 28-17 that the "Transfer Type:" is binary. This is one of the options that I selected prior to initiating the transfer.

Although this functionality is not as extensive as the file sharing of NFS, it is widely used to copy files from system to system and therefore can play a role in Windows and UNIX interoperability.

I used icons to specify the information to be copied in this example. You could also have used the FTP command. The following is an overview of FTP, including an example of running it from the command line and a command summary.

File Transfer Protocol (FTP) Transfer a file, or multiple files, from one system to another, such as Windows to UNIX. The following example shows copying the file /tmp/krsort.c from system2 (remote host) to the local directory on system1 (local host):

	comments
$ ftp system2	Issue ftp command
Connected to system2.
system2 FTP server (Version 16.2) ready.
Name (system2:root): root	Log in to system2
Password required for root.
Password:	Enter password
User root logged in.
Remote system type is UNIX.
Using binary mode to transferfiles.
ftp> cd /tmp	cd to /tmp on system2
CWD command successful
ftp> get krsort.c	Get krsort.c file
PORT command successful
Opening BINARY mode data connection for krsort.c
Transfer complete.
2896 bytes received in 0.08 seconds
ftp> bye	Exit ftp
Goodbye.
$

In this example, both systems are running UNIX; however, the commands you issue through FTP are operating-system-independent. The cd for change directory and get commands used above work for any operating system on which FTP is running. If you become familiar with just a few FTP commands, you may find that transferring information in a heterogeneous networking environment is not difficult.

Because FTP is so widely used, I describe some of the more commonly used FTP commands:

ftp - File Transfer Protocol for copying files across a network.

The following list includes some commonly used ftp commands. This list is not complete.

ascii	Set the type of file transferred to ASCII. This means that you will be transferring an ASCII file from one system to another. This is the default, so you don't have to set it. Example: ascii
binary	Set the type of file transferred to binary. This means that you'll be transferring a binary file from one system to another. If, for instance, you want to have a directory on your UNIX system that will hold applications that you will copy to non-UNIX systems, then you will want to use binary transfer. Example: binary
cd	Change to the specified directory on the remote host. Example: cd /tmp
dir	List the contents of a directory on the remote system to the screen or to a file on the local system if you specify a local file name.
get	Copy the specified remote file to the specified local file. If you don't specify a local file name, then the remote file name is used.
lcd	Change to the specified directory on the local host. Example: lcd /tmp
ls	List the contents of a directory on the remote system to the screen or to a file on the local system if you specify a local file name.
mget	Copy multiple files from the remote host to the local host. Example: mget *.c
put	Copy the specified local file to the specified remote file. If you don't specify a remote file name, then the local file name is used. Example: put test.c
mput	Copy multiple files from the local host to the remote host. Example: mput *.c
system	Show the type of operating system running on the remote host. Example: system
bye/quit	Close the connection to the remote host. Example: bye

Other FTP commands exist in addition to those I have covered here.

Other Connection Topics

There are other means by which you can connect to a UNIX system. Two popular techniques for connecting to other systems are FTP, which was just covered, and TELNET. NFS Maestro supplies the capability for both of these. I could sit at the Windows system using TELNET with a window open on the UNIX system and issue commands.

Figure 28-18 shows the HostExplorer window, which is used to specify the characteristics of your TELNET session:

Figure 28-18. Specifying Characteristics of a HostExplorer Session

I selected VT in the HostExplorer window and was able to log in to the UNIX system, as shown in Figure 28-19:

Figure 28-19. telnet Window

In this window, we can issue UNIX commands just as if we were sitting at a terminal connected directly to the UNIX system. This window shows /home/hp, including the nfs directory copied earlier, and permissions, owner, and group of all files and directories.

telnet is widely used in heterogenous environments. With X Windows, you get graphical functionality that is not part of telnet.

The protocols running on the UNIX system are assigned to ports. We can view these ports, protocols, and associated information using the rpcinfo command on the UNIX system, as shown in Figure 28-20:

Figure 28-20. rpcinfo Command on UNIX

There is a lot of information in this window in which we are interested related to NFS. We do not, however, have to establish a telnet session with the UNIX system and issue rpcinfo to see this information. The Rpcinfo menu pick under Maestro will query the UNIX host and list the services it is running. Figure 28-21 shows this window:

Figure 28-21. Rpcinfo Window on Windows

RPC stands for Remote Procedure Call. There are a variety of programs for which there is RPC-related information. Several programs are required to achieve Windows and UNIX interoperability.

The first number shown is the program number. There are widely accepted RPC numbers for various programs. For NFS, the program number is 100003. The next number is the version of the protocol. In this case, NFS is version 2. The next number is the port. The port number is used by both the client, which is the Windows system in our case, and the server, which is the UNIX system in our case, to communicate using NFS. The next field is the protocol used, which is usually UDP or TCP. The final field is the program name.

In the case of NFS, I had to ensure that NFS, portmapper, mountd, and pcnfsd were running on my UNIX system before I could use the NFS Maestro NFS product.

Rpcinfo is a useful tool for viewing all the information on the host to which your Windows system will connect.

CONTENTS