diffs for chapter 1
David Collier-Brown
David.Collier-Brown at canada.sun.com
Mon Aug 21 19:34:05 GMT 2000
-------------- next part --------------
*** /tmp/T05kaqAU Mon Aug 21 15:20:30 2000
--- ch01_03.html Mon Aug 21 10:35:18 2000
***************
*** 59,65 ****
<a href="ftp://ftp.isi.edu/in-notes/rfc1001.txt" target="new_window">RFC 1001</a>
and
<a href="ftp://ftp.isi.edu/in-notes/rfc1002.txt" target="new_window">1002</a>, that outlined how NetBIOS would work over a TCP/UDP network. This set of documents still governs each of the implementations that exist today, including those provided by Microsoft with their Windows operating systems as well as the Samba suite.</p><P CLASS="para">
! Since then, the standard this document governs has become known as <I CLASS="firstterm">
NetBIOS over TCP/IP</i>, or NBT for short. The NBT standard (<a href="ftp://ftp.isi.edu/in-notes/rfc1001.txt" target="new_window">RFC 1001</a>/<a href="ftp://ftp.isi.edu/in-notes/rfc1002.txt" target="new_window">1002</a>) currently outlines a trio of services on a network:</p><p><UL CLASS="itemizedlist">
<LI CLASS="listitem">
<P CLASS="para">
--- 59,65 ----
<a href="ftp://ftp.isi.edu/in-notes/rfc1001.txt" target="new_window">RFC 1001</a>
and
<a href="ftp://ftp.isi.edu/in-notes/rfc1002.txt" target="new_window">1002</a>, that outlined how NetBIOS would work over a TCP/UDP network. This set of documents still governs each of the implementations that exist today, including those provided by Microsoft with their Windows operating systems as well as the Samba suite.</p><P CLASS="para">
! Since then, the standard these documents govern has become known as <I CLASS="firstterm">
NetBIOS over TCP/IP</i>, or NBT for short. The NBT standard (<a href="ftp://ftp.isi.edu/in-notes/rfc1001.txt" target="new_window">RFC 1001</a>/<a href="ftp://ftp.isi.edu/in-notes/rfc1002.txt" target="new_window">1002</a>) currently outlines a trio of services on a network:</p><p><UL CLASS="itemizedlist">
<LI CLASS="listitem">
<P CLASS="para">
***************
*** 84,94 ****
<LI CLASS="listitem">
<P CLASS="para">
<A CLASS="listitem" NAME="ch01-pgfId-945120">
! </a>Use a <I CLASS="firstterm">
! NetBIOS Name Server</i> (NBNS) to keep track of which hosts have registered a NetBIOS name. </p></li><LI CLASS="listitem">
<P CLASS="para">
<A CLASS="listitem" NAME="ch01-pgfId-945121">
! </a>Allow each machine on the network to defend its name in the event that another machine attempts to use it.</p></li></ul><P CLASS="para">
<A CLASS="xref" HREF="ch01_03.html#ch01-86658">
Figure 1.8</a> illustrates a (failed) name registration, with and without a NetBIOS Name Server. </p><H4 CLASS="figure">
<A CLASS="title" NAME="ch01-86658">
--- 84,94 ----
<LI CLASS="listitem">
<P CLASS="para">
<A CLASS="listitem" NAME="ch01-pgfId-945120">
! </a>Allow each machine on the network to defend its name in the event that another machine attempts to use it. </p></li><LI CLASS="listitem">
<P CLASS="para">
<A CLASS="listitem" NAME="ch01-pgfId-945121">
! </a>Use a <I CLASS="firstterm">
! NetBIOS Name Server</i> (NBNS) to keep track of which hosts have registered a NetBIOS name.</p></li></ul><P CLASS="para">
<A CLASS="xref" HREF="ch01_03.html#ch01-86658">
Figure 1.8</a> illustrates a (failed) name registration, with and without a NetBIOS Name Server. </p><H4 CLASS="figure">
<A CLASS="title" NAME="ch01-86658">
***************
*** 150,158 ****
In the case of Windows clients, you will usually find them listed as <I CLASS="firstterm">
h-nodes</i> or <I CLASS="firstterm">
hybrid nodes</i>. Incidentally, h-nodes were invented later by Microsoft, as a more fault-tolerant route, and do not appear in <a href="ftp://ftp.isi.edu/in-notes/rfc1001.txt" target="new_window">RFC 1001</a>/<a href="ftp://ftp.isi.edu/in-notes/rfc1002.txt" target="new_window">1002</a>.</p><P CLASS="para">
! You can find out the node type of any Windows machine by typing the command <CODE CLASS="literal">
! ipconfig</code> <CODE CLASS="literal">
! /all</code> and searching for the line that says <CODE CLASS="literal">
Node Type</code>.</p>
<p>
--- 150,160 ----
In the case of Windows clients, you will usually find them listed as <I CLASS="firstterm">
h-nodes</i> or <I CLASS="firstterm">
hybrid nodes</i>. Incidentally, h-nodes were invented later by Microsoft, as a more fault-tolerant route, and do not appear in <a href="ftp://ftp.isi.edu/in-notes/rfc1001.txt" target="new_window">RFC 1001</a>/<a href="ftp://ftp.isi.edu/in-notes/rfc1002.txt" target="new_window">1002</a>.</p><P CLASS="para">
!
! You can find out the node type of a Windows 95/98 machine
! with the "More Info" button of the winipcfg command. On
! Windows NT, type <CODE CLASS="literal">ipconfig /all</code> and search for line that says
! <CODE CLASS="literal">
Node Type</code>.</p>
<p>
***************
*** 257,263 ****
workgroup</i>, which is a partition of machines 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 an SMB group are the same thing.</p><P CLASS="para">
Continuing our NBTSTAT example, the <CODE CLASS="literal">
hydra</code> Samba server is also a member of the SIMPLE workgroup (the GROUP attribute hex 00), and will stand for election as a browse master (GROUP attribute 1E). Here is the remainder of the NBTSTAT utility output:</p><p><PRE CLASS="programlisting">
! NetBIOS Remote Machine Name Table, continued
Name Type Status
---------------------------------------------
SIMPLE <00> GROUP Registered
--- 259,265 ----
workgroup</i>, which is a partition of machines 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 an SMB group are the same thing.</p><P CLASS="para">
Continuing our NBTSTAT example, the <CODE CLASS="literal">
hydra</code> Samba server is also a member of the SIMPLE workgroup (the GROUP attribute hex 00), and will stand for election as a browse master (GROUP attribute 1E). Here is the remainder of the NBTSTAT utility output:</p><p><PRE CLASS="programlisting">
! NetBIOS Remote Machine Name Table
Name Type Status
---------------------------------------------
SIMPLE <00> GROUP Registered
***************
*** 348,355 ****
Receive Broadcast Datagram</p></td><TD CLASS="entry" ROWSPAN="1" COLSPAN="1">
<P CLASS="para">
Wait for a broadcast datagram.</p></td></tr></tbody></table><P CLASS="para">
! The session service is more complex. Sessions are a communication method that, in theory, offers the ability to detect problematic or inoperable connections between two NetBIOS applications. It helps to think of an NBT session in terms of a telephone call.[<A CLASS="footnote" HREF="#ch01-pgfId-946249">5</a>] A full-duplex connection is opened between a caller machine and a called machine, and it must remain open throughout the duration of their conversation. Each side knows who the caller and the called machine is, and can communicate with the simple primitives shown in <A CLASS="xref" HREF="ch01_03.html#ch01-pgfId-946256">
! Table 1.5</a>. </p><BLOCKQUOTE CLASS="footnote">
<DIV CLASS="footnote">
<P CLASS="para">
<A CLASS="footnote" NAME="ch01-pgfId-946249">[5]</a> As you can see in <a href = "ftp://ftp.isi.edu/in-notes/rfc1001.txt" target="new_window">RFC 1001</a>, the telephone analogy was strongly evident in the creation of the NBT service.</p></div></blockquote><p>
--- 350,360 ----
Receive Broadcast Datagram</p></td><TD CLASS="entry" ROWSPAN="1" COLSPAN="1">
<P CLASS="para">
Wait for a broadcast datagram.</p></td></tr></tbody></table><P CLASS="para">
! The session service is more complex, but provides a reliable connection and delivers
! the packets in order. An NBT session is best thought of in terms of a telephone
! call.[<A CLASS="footnote" HREF="#ch01-pgfId-946249">5</a>] Each side knows who the caller and the
! called machine are, and each can communicate with the simple primitives shown in
! <A CLASS="xref" HREF="ch01_03.html#ch01-pgfId-946256">Table 1.5</a>. </p><BLOCKQUOTE CLASS="footnote">
<DIV CLASS="footnote">
<P CLASS="para">
<A CLASS="footnote" NAME="ch01-pgfId-946249">[5]</a> As you can see in <a href = "ftp://ftp.isi.edu/in-notes/rfc1001.txt" target="new_window">RFC 1001</a>, the telephone analogy was strongly evident in the creation of the NBT service.</p></div></blockquote><p>
-------------- next part --------------
*** /tmp/T0lvaOAU Mon Aug 21 15:20:31 2000
--- ch01_04.html Fri Aug 18 14:26:12 2000
***************
*** 74,80 ****
1.4.1.2 Primary and backup domain controllers</a></h4><P CLASS="para">Redundancy is a key idea behind a Windows domain. The domain controller that is currently active on a domain is called the <I CLASS="firstterm">
primary domain controller</i> (PDC). There can be one or more <I CLASS="firstterm">
backup domain controllers</i> (BDCs) in the domain as well, which will take over in the event that the primary domain controller fails or becomes inaccessible. BDCs frequently synchronize their SAM data with the primary domain controller so that, if the need arises, any one of them can perform DC services transparently without impacting its clients. Note that BDCs, however, have only read-only copies of the SAM; they can update their data only by synchronizing with a PDC. A server in a Windows domain can use the SAM of any primary or backup domain controller to authenticate a user who attempts to access its resources and logon to the domain.</p><P CLASS="para">
! Note that in many aspects, the behaviors of a Windows workgroup and a Windows domain overlap. This is not accidental since the concept of Windows domains did not evolve until Windows NT 3.5 was introduced, and Windows domains were forced to remain backwards compatible with the workgroups present in Windows for Workgroups 3.1. The key thing to remember here is that a Windows domain is simply a Windows workgroup with one or more domain controllers added.</p><P CLASS="para">
Samba can function as a primary domain controller for Windows 95/98 machines without any problems. However, Samba 2.0 can act as a primary domain controller only for authentication purposes; it currently cannot assume any other PDC responsibilities. (By the time you read this, Samba 2.1 may be available so you can use Samba as a PDC for NT clients.) Also, because of the closed protocol used by Microsoft to synchronize SAM data, Samba currently cannot serve as a backup domain controller. </p></div></div><DIV CLASS="sect2">
<H3 CLASS="sect2">
<A CLASS="title" NAME="ch01-pgfId-951817">
--- 74,80 ----
1.4.1.2 Primary and backup domain controllers</a></h4><P CLASS="para">Redundancy is a key idea behind a Windows domain. The domain controller that is currently active on a domain is called the <I CLASS="firstterm">
primary domain controller</i> (PDC). There can be one or more <I CLASS="firstterm">
backup domain controllers</i> (BDCs) in the domain as well, which will take over in the event that the primary domain controller fails or becomes inaccessible. BDCs frequently synchronize their SAM data with the primary domain controller so that, if the need arises, any one of them can perform DC services transparently without impacting its clients. Note that BDCs, however, have only read-only copies of the SAM; they can update their data only by synchronizing with a PDC. A server in a Windows domain can use the SAM of any primary or backup domain controller to authenticate a user who attempts to access its resources and logon to the domain.</p><P CLASS="para">
! Note that in many aspects, the behaviors of a Windows workgroup and a Windows domain overlap. This is not accidental since the concept of Windows domains did not evolve until Windows NT 3.1 was introduced, and Windows domains were forced to remain backwards compatible with the workgroups present in Windows for Workgroups 3.1. The key thing to remember here is that a Windows domain is simply a Windows workgroup with one or more domain controllers added.</p><P CLASS="para">
Samba can function as a primary domain controller for Windows 95/98 machines without any problems. However, Samba 2.0 can act as a primary domain controller only for authentication purposes; it currently cannot assume any other PDC responsibilities. (By the time you read this, Samba 2.1 may be available so you can use Samba as a PDC for NT clients.) Also, because of the closed protocol used by Microsoft to synchronize SAM data, Samba currently cannot serve as a backup domain controller. </p></div></div><DIV CLASS="sect2">
<H3 CLASS="sect2">
<A CLASS="title" NAME="ch01-pgfId-951817">
***************
*** 92,98 ****
</a>Browsing a list of machines (with shared resources)</p></li><LI CLASS="listitem">
<P CLASS="para">
<A CLASS="listitem" NAME="ch01-pgfId-944662">
! </a>Browsing the shared resources of a specific machine</p></li></ul><P CLASS="para">Let's look at the first one. On each Windows workgroup (or domain) subnet, one computer has the responsibility of maintaining a list of the machines that are currently accessible through the network. This computer is called the <I CLASS="firstterm">
local master browser</i>, and the list that it maintains is called the <I CLASS="firstterm">
browse list</i>. Machines on a subnet use the browse list in order to cut down on the amount of network traffic generated while browsing. Instead of each computer dynamically polling to determine a list of the currently available machines, the computer can simply query the local master browser to obtain a complete, up-to-date list.</p><P CLASS="para">To browse the actual resources on a machine, a user must connect to the specific machine; this information cannot be obtained from the browse list. Browsing the list of resources on a machine can be done by clicking on the machine's icon when it is presented in the Network Neighborhood in Windows 95/98 or NT. As you saw at the opening of the chapter, the machine will respond with a list of shared resources that can be accessed if that user is successfully authenticated.</p><P CLASS="para">
Each of the servers on a Windows workgroup is required to announce its presence to the local master browser after it has registered a NetBIOS name, and (theoretically) announce that it is leaving the workgroup when it is shut down. It is the local master browser's responsibility to record what the servers have announced. Note that the local master browser is not necessarily the same machine as a NetBIOS name server (NBNS), which we discussed earlier. </p><BLOCKQUOTE CLASS="warning">
--- 92,102 ----
</a>Browsing a list of machines (with shared resources)</p></li><LI CLASS="listitem">
<P CLASS="para">
<A CLASS="listitem" NAME="ch01-pgfId-944662">
! </a>Browsing the shared resources of a specific machine</p></li></ul><P CLASS="para">
!
! Let's look at the first one. On each LAN (or subnet) with a Windows workgroup or domain,
!
! one computer has the responsibility of maintaining a list of the machines that are currently accessible through the network. This computer is called the <I CLASS="firstterm">
local master browser</i>, and the list that it maintains is called the <I CLASS="firstterm">
browse list</i>. Machines on a subnet use the browse list in order to cut down on the amount of network traffic generated while browsing. Instead of each computer dynamically polling to determine a list of the currently available machines, the computer can simply query the local master browser to obtain a complete, up-to-date list.</p><P CLASS="para">To browse the actual resources on a machine, a user must connect to the specific machine; this information cannot be obtained from the browse list. Browsing the list of resources on a machine can be done by clicking on the machine's icon when it is presented in the Network Neighborhood in Windows 95/98 or NT. As you saw at the opening of the chapter, the machine will respond with a list of shared resources that can be accessed if that user is successfully authenticated.</p><P CLASS="para">
Each of the servers on a Windows workgroup is required to announce its presence to the local master browser after it has registered a NetBIOS name, and (theoretically) announce that it is leaving the workgroup when it is shut down. It is the local master browser's responsibility to record what the servers have announced. Note that the local master browser is not necessarily the same machine as a NetBIOS name server (NBNS), which we discussed earlier. </p><BLOCKQUOTE CLASS="warning">
***************
*** 160,167 ****
<H3 CLASS="sect2">
<A CLASS="title" NAME="ch01-pgfId-938926">
1.4.4 The Windows Internet Name Service (WINS)</a></h3><P CLASS="para">
! The Windows Internet Name Service (WINS) is Microsoft's implementation of a NetBIOS name server (NBNS). As such, WINS inherits much of NetBIOS's characteristics. First, WINS is flat; you can only have machines named <CODE CLASS="literal">
! fred</code> or workgroups like CANADA or USA. In addition, WINS is dynamic: when a client first comes online, it is required to report its hostname, its address, and its workgroup to the local WINS server. This WINS server will retain the information so long as the client periodically refreshes its WINS registration, which indicates that it's still connected to the network. Note that WINS servers are not domain or workgroup specific; they can appear anywhere and serve anyone.</p><P CLASS="para">
Multiple WINS servers can be set to synchronize with each other after a specified amount of time. This allows entries for machines that come online and offline on the network to propagate from one WINS server to another. While in theory this seems efficient, it can quickly become cumbersome if there are several WINS servers covering a network. Because WINS services can cross multiple subnets (you'll either hardcode the address of a WINS server in each of your clients or obtain it via DHCP), it is often more efficient to have each Windows client, no matter how many Windows domains there are, point themselves to the same WINS server. That way, there will only be one authoritative WINS server with the correct information, instead of several WINS servers continually struggling to synchronize themselves with the most recent changes.</p><P CLASS="para">
The currently active WINS server is known as the <I CLASS="firstterm">
primary WINS server</i>. You can also install a secondary WINS server, which will take over in the event that the primary WINS server fails or becomes inaccessible. Note that there is no election to determine which machine becomes a primary or backup WINS server - the choice of WINS servers is static and must be predetermined by the system administrator. Both the primary and any backup WINS servers will synchronize their address databases on a periodic basis.</p><P CLASS="para">
--- 164,172 ----
<H3 CLASS="sect2">
<A CLASS="title" NAME="ch01-pgfId-938926">
1.4.4 The Windows Internet Name Service (WINS)</a></h3><P CLASS="para">
! The Windows Internet Name Service (WINS) is Microsoft's implementation of a NetBIOS name server (NBNS). As such, WINS inherits much of NetBIOS's characteristics. First, WINS is flat; you can only have machines named
! <CODE CLASS="literal">fred</code> or <CODE CLASS="literal">willy</code>
! or workgroups like <CODE CLASS="literal">CANADA</CODE> or <CODE CLASS="literal">USA</CODE>. In addition, WINS is dynamic: when a client first comes online, it is required to report its hostname, its address, and its workgroup to the local WINS server. This WINS server will retain the information so long as the client periodically refreshes its WINS registration, which indicates that it's still connected to the network. Note that WINS servers are not domain or workgroup specific; they can appear anywhere and serve anyone.</p><P CLASS="para">
Multiple WINS servers can be set to synchronize with each other after a specified amount of time. This allows entries for machines that come online and offline on the network to propagate from one WINS server to another. While in theory this seems efficient, it can quickly become cumbersome if there are several WINS servers covering a network. Because WINS services can cross multiple subnets (you'll either hardcode the address of a WINS server in each of your clients or obtain it via DHCP), it is often more efficient to have each Windows client, no matter how many Windows domains there are, point themselves to the same WINS server. That way, there will only be one authoritative WINS server with the correct information, instead of several WINS servers continually struggling to synchronize themselves with the most recent changes.</p><P CLASS="para">
The currently active WINS server is known as the <I CLASS="firstterm">
primary WINS server</i>. You can also install a secondary WINS server, which will take over in the event that the primary WINS server fails or becomes inaccessible. Note that there is no election to determine which machine becomes a primary or backup WINS server - the choice of WINS servers is static and must be predetermined by the system administrator. Both the primary and any backup WINS servers will synchronize their address databases on a periodic basis.</p><P CLASS="para">
-------------- next part --------------
*** /tmp/T0xyaaBU Mon Aug 21 15:20:31 2000
--- ch01_05.html Mon Aug 21 10:46:34 2000
***************
*** 54,60 ****
The <EM CLASS="emphasis">
smbd</em> daemon is responsible for managing the shared resources between the Samba server machine and its clients. It provides file, print, and browser services to <SPAN CLASS="acronym">
SMB</span> clients across one or more networks. <EM CLASS="emphasis">
! smdb</em> handles all notifications between the Samba server and the network clients. In addition, it is responsible for user authentication, resource locking, and data sharing through the <SPAN CLASS="acronym">
SMB</span> protocol.</p></dd><DT CLASS="term">
<EM CLASS="emphasis">
nmbd</em></dt><DD CLASS="listitem">
--- 54,60 ----
The <EM CLASS="emphasis">
smbd</em> daemon is responsible for managing the shared resources between the Samba server machine and its clients. It provides file, print, and browser services to <SPAN CLASS="acronym">
SMB</span> clients across one or more networks. <EM CLASS="emphasis">
! smbd</em> handles all notifications between the Samba server and the network clients. In addition, it is responsible for user authentication, resource locking, and data sharing through the <SPAN CLASS="acronym">
SMB</span> protocol.</p></dd><DT CLASS="term">
<EM CLASS="emphasis">
nmbd</em></dt><DD CLASS="listitem">
-------------- next part --------------
*** /tmp/T0MXaWBU Mon Aug 21 15:20:33 2000
--- ch01_07.html Mon Aug 21 10:48:52 2000
***************
*** 50,56 ****
<A CLASS="title" NAME="ch01-pgfId-937019">
1.7.1 NT Domains</a></h3><P CLASS="para">
Samba's support for NT Domains (starting with version 2.0.<EM CLASS="emphasis">x</em>) produced a big improvement: it allows SMB servers to use its authentication mechanisms, which is essential for future NT compatibility, and to support <I CLASS="firstterm">
! NT domain logons</i>. Domain logons allow a user to log in to a Windows NT domain and use all the computers in the domain without logging into them individually. Previous to version 2.0.0, Samba supported Windows 95/98 logon services, but not NT domain logons. Although domain logons support is not complete is Samba 2.0, it is partially implemented.</p></div><DIV CLASS="sect2">
<H3 CLASS="sect2">
<A CLASS="title" NAME="ch01-pgfId-937021">
1.7.2 Ease of Administration</a></h3><P CLASS="para">SWAT, the Samba Web Administration Tool, makes it easy to set up a server and change its configuration, without giving up the simple text-based configuration file. SWAT provides a graphical interface to the resources that Samba shares with its clients. In addition, SWAT saves considerable experimentation and memory work in setting up or changing configurations across the network. You can even create an initial setup with SWAT and then modify the file later by hand, or vice versa. Samba will not complain.</p><P CLASS="para">
--- 50,56 ----
<A CLASS="title" NAME="ch01-pgfId-937019">
1.7.1 NT Domains</a></h3><P CLASS="para">
Samba's support for NT Domains (starting with version 2.0.<EM CLASS="emphasis">x</em>) produced a big improvement: it allows SMB servers to use its authentication mechanisms, which is essential for future NT compatibility, and to support <I CLASS="firstterm">
! NT domain logons</i>. Domain logons allow a user to log in to a Windows NT domain and use all the computers in the domain without logging into them individually. Previous to version 2.0.0, Samba supported Windows 95/98 logon services, but not NT domain logons. Although domain logons support is not complete in Samba 2.0, it is partially implemented.</p></div><DIV CLASS="sect2">
<H3 CLASS="sect2">
<A CLASS="title" NAME="ch01-pgfId-937021">
1.7.2 Ease of Administration</a></h3><P CLASS="para">SWAT, the Samba Web Administration Tool, makes it easy to set up a server and change its configuration, without giving up the simple text-based configuration file. SWAT provides a graphical interface to the resources that Samba shares with its clients. In addition, SWAT saves considerable experimentation and memory work in setting up or changing configurations across the network. You can even create an initial setup with SWAT and then modify the file later by hand, or vice versa. Samba will not complain.</p><P CLASS="para">
More information about the samba-technical
mailing list