Section 1.3. The Common Internet File System
1.3. The Common Internet File SystemModern Microsoft operating systems rely upon a resource-sharing protocol known as CIFS. CIFS provides APIs for manipulating files and for implementing remote administration functionality such as user password changes and printing services. Microsoft would have you think that this is a new protocol unrelated to its predecessor, the SMB protocol, but CIFS is really just the latest variant in a long line of SMB protocol dialects. It could be argued that it is even just a new name for the latest revision of SMB. Frequently, you will see the terms SMB and CIFS used interchangably or perhaps as a combination (e.g., SMB/CIFS). In other contexts, people use CIFS to refer to the NetBIOS-less incarnation of SMB over TCP/445 implemented by Windows 2000 and later operating systems and SMB to refer to Windows 9x/ME and NT systems. The line is never really clear from the perspective of a developer or a network administrator. For simplicity, this book uses CIFS to refer to the combination of SMB and CIFS operations.
CIFS is a connection-oriented, stateful protocol that relies upon three supporting network services:
Both Samba 3.0 and Windows 2000/XP/2003 support using standard IP services to meet these requirements. For example, the Domain Name Service (DNS) translates names to addresses, UDP packets provide the datagram service, and the TCP protocol provides the support needed for CIFS sessions. More on TCP/IP and DNS can be found in TCP/IP Network Administration, by Craig Hunt, and DNS and BIND, by Paul Albitz and Cricket Liu, both published by O'Reilly. Prior to Windows 2000, Microsoft clients relied upon a layer called NetBIOS to provide this supporting infrastructure. Although modern CIFS clients and servers, including Samba, can function without utilizing NetBIOS services, most usually provide a legacy mode of operation for communicating with older CIFS implementations. Figure 1-6 illustrates the relationship between CIFS, hosts on a network, and core network services. The NetBIOS protocol is generally unfamiliar to Unix sysadmins and therefore deserves a little more attention. Figure 1-6. CIFS and its required support services 1.3.1. Understanding NetBIOSTo begin, let's step back in time. In 1984, IBM authored a simple application programming interface (API) for networking its computers, called the Network Basic Input/Output System (NetBIOS). The NetBIOS API provided a rudimentary design for an application to connect and share data with other computers. It's helpful to think of the NetBIOS API as networking extensions to the standard BIOS API calls. The BIOS contains low-level code for performing filesystem operations on the local computer. NetBIOS originally had to exchange instructions with computers across IBM PC or Token Ring networks. It therefore required a low-level transport protocol to carry its requests from one computer to the next. In late 1985, IBM released one such protocol, which it merged with the NetBIOS API to become the NetBIOS Extended User Interface (NetBEUI). NetBEUI was designed for small LANs, and let each computer claim a name (up to 15 characters in length) that wasn't already in use on the network. By "small LANs," we mean those with fewer than 255 nodes on the networkwhich was considered a generous number in 1985! The NetBEUI protocol was very popular with networking applications, including those running under Windows for Workgroups. Later, implementations of NetBIOS over Novell's IPX networking protocols also emerged and competed with NetBEUI. However, the network stack of choice for the burgeoning Internet community was TCP/IP, and implementing the NetBIOS APIs over this protocol suite soon became a necessity. Recall that TCP/IP uses numbers to represent computer addresses (192.168.220.100, for instance), and that NetBIOS uses only names. This difference was a point of contention when trying to integrate the two protocols together. In 1987, the IETF published standardization documents, titled RFC 1001 and 1002, that outlined how NetBIOS would work over a TCP/IP network. This set of documents still governs each implementation that exists today, including those provided by Microsoft with its Windows operating systems, as well as the Samba suite. Since then, the standard that this document governs has become known as NetBIOS over TCP/IP, or NBT for short. The NetBIOS name service solves the name-to-address problem mentioned earlier by allowing each computer to declare a specific name on the network that can be translated to a machine-readable IP address. With the current pervasiveness of TCP/IP networks and DNS, which performs a function identical to the three NetBIOS services, it is understandable why Microsoft choose to migrate away from NetBIOS in newer OS releases. 1.3.2. Getting a NameIn the NetBIOS world, when each computer comes online, it attempts to claim a name for itself; this process is called name registration. However, no two computers in the same namespace should be able to claim the same name; this state would cause endless confusion for any computer that wanted to communicate with either of them. There are two different approaches to ensure that this doesn't happen:
Figure 1-7 illustrates a (failed) name registration, with and without WINS. Figure 1-7. Broadcast versus WINS name registration As mentioned earlier, there must be a way to resolve a NetBIOS name to a specific IP address; this process is known as name resolution . There are two different approaches with NBT here as well:
Figure 1-8 illustrates the two types of name resolution. Figure 1-8. Broadcast versus WINS name resolution As you might expect, having a WINS server on your network can help out tremendously. To see exactly why, let's look at the broadcast method. When a client computer boots, it broadcasts a message declaring that it wishes to register a specified NetBIOS name as its own. If nobody objects to the use of the name, it keeps the name. On the other hand, if another computer on the local subnet is currently using the requested name, it sends a message back to the requesting client that the name is already taken. This is known as defending the name. This type of system comes in handy when one client has unexpectedly dropped off the networkanother can take its name unchallengedbut it does incur an inordinate amount of traffic on the network for something as simple as name registration. With WINS, the same thing occurs, except that the communication is confined to the requesting computer, the defending host, and the WINS server. No broadcasting occurs when the computer wishes to register the name; the registration message is simply sent directly from the client to the WINS server, which asks the defending host whether it wishes to continue to use the name. The WINS server reply to the name registration request is determined by the defending host's reply. This system is known as point-to-point communication , and it is often beneficial on networks with more than one subnet, because routers are generally configured to block incoming packets that are broadcast to all computers in the subnet. The same principles apply to name resolution. Without WINS, NetBIOS name resolution would also be done with a broadcast mechanism. All request packets would be sent to each computer in the network, with the hope that one computer that might be affected will respond directly back to the computer that asked. Using WINS and point-to-point communication for this purpose is far less taxing on the network than flooding the network with broadcasts for every name-resolution request. It can be argued that broadcast packets do not cause significant problems in modern, high-bandwidth networks of hosts with fast CPUs, if only a small number of hosts are on the network, or if the demand for bandwidth is low. There are certainly cases where this argument is correct; however, the assumption does not hold in environments that support more than one broadcast segment connected together by routers. Therefore, the advice throughout this book is to avoid relying on broadcasts as much as possible. This rule is good for large, busy networks, and if you follow this advice when configuring a small network, your network will be able to grow without encountering problems later on that might be difficult to diagnose. 1.3.3. Node TypesEach computer on an NBT network earns one of the following designations, depending on how it handles name registration and resolution: b-node, p-node, m-node, and h-node. The behaviors of each type of node are summarized in Table 1-1.
Windows clients are usually h-nodes. The first three node types appear in RFC 1001/1002. H-nodes were invented later by Microsoft, as a more fault-tolerant method. You can find the node type of a Windows 95/98/Me computer by running the winipcfg.exe command from the Start C:\> ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : lettuce Primary Dns Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : localdomain Ethernet adapter Local Area Connection 2: Connection-specific DNS Suffix . : localdomain Description . . . . . . . . . . . : AMD PCNET Family PCI Ethernet Adapter #2 Physical Address. . . . . . . . . : 00-0C-29-82-92-98 Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.56.129 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : DHCP Server . . . . . . . . . . . : 192.168.56.254 DNS Servers . . . . . . . . . . . : 192.168.56.1 Lease Obtained. . . . . . . . . . : Tuesday, June 07, 2005 10:36:24 AM Lease Expires . . . . . . . . . . : Tuesday, June 07, 2005 11:06:24 AM 1.3.4. What's in a Name?The names that NetBIOS uses are quite different from the DNS hostnames with which you might be familiar. First, NetBIOS names exist in a flat namespace. In other words, there are no hierarchical levels, such as in oreilly.com (two levels) or ftp.samba.org (three levels). NetBIOS names consist of a single unique string such as RAIN or SLEET within each WINS server or broadcast segment. Second, NetBIOS names may be no longer than 15 characters in length and can consist only of standard alphanumeric characters (az, AZ, 09) plus the following: ! @ # $ % ^ & ( ) - ' { } . ~ Any name with fewer than 15 characters is padded with spaces at the end to reach the 15-character length. Although you are allowed to use a period (.) in a NetBIOS name, it is a very bad idea. A NetBIOS name containing a period is very hard to distinguish from a valid DNS name. Even worse is something like the valid NetBIOS name 192.168.1.100. It's not a coincidence that all valid hostnames are also valid NetBIOS names. In fact, the hostname for a Samba server is often reused as its NetBIOS name. For example, if you had a system with a fully qualified DNS name of sleet.plainjoe.org, its NetBIOS name would default to SLEET (followed by 9 spaces). 1.3.4.1. Resource names and typesWith NetBIOS, a computer not only advertises its presence, but also tells others what types of services it offers. For example, SLEET can indicate that it's not just a workstation, but that it's also a file server and can receive Windows Messenger messages. This is done by adding a sixteenth byte to the end of the machine name, called the resource type (or resource byte), and registering the name multiple times, once for each service that it offers. See Figure 1-9. Figure 1-9. The structure of a NetBIOS name The one-byte resource type indicates a unique service that the named computer provides. In this book, you will often see the resource type shown in angle brackets (<>) after the NetBIOS name, such as SLEET<0x00> or SLEET<00>. Note that Samba documentation and tools often use the hash mark in place of angle brackets (SLEET#00). It is possible to see which names are registered for a particular NBT computer using the Windows command-line nbtstat utility. Because these services are unique (i.e., there cannot be more than one registered), you will see them listed as type UNIQUE in the output. For example, the following partial output describes the SLEET server: C:\> nbtstat -a sleet NetBIOS Remote Machine Name Table Name Type Status --------------------------------------------- SLEET <00> UNIQUE Registered SLEET <03> UNIQUE Registered SLEET <20> UNIQUE Registered ... This output indicates that the server has registered the NetBIOS name SLEET as a machine (computer) name, as a recipient of messages from the Windows Messenger service, and as a file server. Some of the attributes a name can have are listed in Table 1-2.
1.3.4.2. Group names and typesNetBIOS also uses the concept of groups with which computers can register themselves. Earlier, we mentioned that the computers in our example belonged to a workgroup, which is a partition of computers on the same network. For example, a business might very easily have an ACCOUNTING and a SALES workgroup, each with different servers and printers. In the Windows world, a workgroup and a NetBIOS group are the same thing. Continuing our nbtstat example, the SLEET Samba server is also a member of the GARDEN workgroup (the GROUP attribute hex 00) and will participate in elections for the browse master (GROUP attribute 1E). Here is the remainder of the nbtstat output: NetBIOS Remote Machine Name Table Name Type Status --------------------------------------------- GARDEN <00> GROUP Registered GARDEN <1E> GROUP Registered .._ _MSBROWSE_ _.<01> GROUP Registered The possible group attributes a computer can have are listed in Table 1-3. An excellent reference to the internals of NetBIOS names and services can be found in Chris Hertel's book, Implementing CIFS: The Common Internet File System (Prentice Hall), available online at http://www.ubiqx.org/cifs.
The final entry, _ _MSBROWSE_ _, is used to announce a group to other master browsers. The nonprinting characters in the name show up as dots in an nbtstat printout. Don't worry if you don't understand all of the resource or group types. Some of them you will not need with Samba, and others you will pick up as you move through the rest of the chapter. The important thing to remember here is the logistics of the naming mechanism.
1.3.5. Datagrams and SessionsNBT offers two transport services: the session service and the datagram service. Understanding how these two services work is not essential to using Samba, but it does give you an idea of how NBT works and how to troubleshoot Samba when it doesn't work. The datagram service has no stable connection between computers. Packets of data are simply sent or broadcast from one computer to another, without regard to the order in which they arrive at the destination, or even if they arrive at all. The use of datagrams requires less processing overhead than sessions, although the reliability of the connection can suffer. Datagrams, therefore, are used for quickly sending nonvital blocks of data to one or more computers. The datagram service communicates using the simple primitives shown in Table 1-4.
The session service is more complex. Sessions are a communication method that can, in theory, detect problematic or inoperable connections between two NetBIOS applications. It helps to think of an NBT session as being similar to a telephone call. Once a connection is made on a session, it remains open throughout the duration of the conversation; each side knows who the caller and the called computer are; and each can communicate using the simple primitives shown in Table 1-5.
Sessions are the backbone of resource sharing on an NBT network. They are typically used for establishing stable connections from client computers to disk or printer shares on a server. The client "calls" the server and starts trading information such as which files it wishes to open, which data it wishes to exchange, and so on. These calls can last a long timehours, even daysand all of this occurs within the context of a single connection. If there is an error, the session software (TCP) retransmits until the data is received properly, unlike the "punt-and-pray" approach of the datagram service (UDP). In truth, although sessions are supposed to handle problematic communications, they sometimes don't. If the connection is interrupted, session information that is open between the two computers becomes invalid. If this happens, the only way to regain the session information is for the same two computers to call each other again and start over. If you want more information on each service, the best place to look is RFC 1001/1002. Just make sure to keep these two points in mind:
|
Run dialog box (or from an MS-DOS prompt) and clicking the More Info button. On operating systems based on Windows NT, such as Windows 2000, Windows XP, and Windows 2003, you can use the ipconfig /all command in a command-prompt window, as shown in the next example. In either case, search for the line that says Node Type.
EAN: 2147483647
Pages: 135