diff options
Diffstat (limited to 'docs/htmldocs/improved-browsing.html')
| -rw-r--r-- | docs/htmldocs/improved-browsing.html | 823 |
1 files changed, 823 insertions, 0 deletions
diff --git a/docs/htmldocs/improved-browsing.html b/docs/htmldocs/improved-browsing.html new file mode 100644 index 0000000000..4a483ecdc1 --- /dev/null +++ b/docs/htmldocs/improved-browsing.html @@ -0,0 +1,823 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<HTML +><HEAD +><TITLE +>Improved browsing in samba</TITLE +><META +NAME="GENERATOR" +CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+ +"><LINK +REL="HOME" +TITLE="SAMBA Project Documentation" +HREF="Samba-HOWTO.html"><LINK +REL="PREVIOUS" +TITLE="Storing Samba's User/Machine Account information in an LDAP Directory" +HREF="samba-ldap-howto.html"><LINK +REL="NEXT" +TITLE="Samba performance issues" +HREF="speed.html"></HEAD +><BODY +CLASS="CHAPTER" +BGCOLOR="#FFFFFF" +TEXT="#000000" +LINK="#0000FF" +VLINK="#840084" +ALINK="#0000FF" +><DIV +CLASS="NAVHEADER" +><TABLE +SUMMARY="Header navigation table" +WIDTH="100%" +BORDER="0" +CELLPADDING="0" +CELLSPACING="0" +><TR +><TH +COLSPAN="3" +ALIGN="center" +>SAMBA Project Documentation</TH +></TR +><TR +><TD +WIDTH="10%" +ALIGN="left" +VALIGN="bottom" +><A +HREF="samba-ldap-howto.html" +ACCESSKEY="P" +>Prev</A +></TD +><TD +WIDTH="80%" +ALIGN="center" +VALIGN="bottom" +></TD +><TD +WIDTH="10%" +ALIGN="right" +VALIGN="bottom" +><A +HREF="speed.html" +ACCESSKEY="N" +>Next</A +></TD +></TR +></TABLE +><HR +ALIGN="LEFT" +WIDTH="100%"></DIV +><DIV +CLASS="CHAPTER" +><H1 +><A +NAME="IMPROVED-BROWSING">Chapter 15. Improved browsing in samba</H1 +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2577">15.1. Overview of browsing</H1 +><P +>SMB networking provides a mechanism by which clients can access a list +of machines in a network, a so-called "browse list". This list +contains machines that are ready to offer file and/or print services +to other machines within the network. Thus it does not include +machines which aren't currently able to do server tasks. The browse +list is heavily used by all SMB clients. Configuration of SMB +browsing has been problematic for some Samba users, hence this +document.</P +><P +>Browsing will NOT work if name resolution from NetBIOS names to IP +addresses does not function correctly. Use of a WINS server is highly +recommended to aid the resolution of NetBIOS (SMB) names to IP addresses. +WINS allows remote segment clients to obtain NetBIOS name_type information +that can NOT be provided by any other means of name resolution.</P +></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2581">15.2. Browsing support in samba</H1 +><P +>Samba now fully supports browsing. The browsing is supported by nmbd +and is also controlled by options in the smb.conf file (see smb.conf(5)).</P +><P +>Samba can act as a local browse master for a workgroup and the ability +for samba to support domain logons and scripts is now available. See +DOMAIN.txt for more information on domain logons.</P +><P +>Samba can also act as a domain master browser for a workgroup. This +means that it will collate lists from local browse masters into a +wide area network server list. In order for browse clients to +resolve the names they may find in this list, it is recommended that +both samba and your clients use a WINS server.</P +><P +>Note that you should NOT set Samba to be the domain master for a +workgroup that has the same name as an NT Domain: on each wide area +network, you must only ever have one domain master browser per workgroup, +regardless of whether it is NT, Samba or any other type of domain master +that is providing this service.</P +><P +>[Note that nmbd can be configured as a WINS server, but it is not +necessary to specifically use samba as your WINS server. NTAS can +be configured as your WINS server. In a mixed NT server and +samba environment on a Wide Area Network, it is recommended that +you use the NT server's WINS server capabilities. In a samba-only +environment, it is recommended that you use one and only one nmbd +as your WINS server].</P +><P +>To get browsing to work you need to run nmbd as usual, but will need +to use the "workgroup" option in smb.conf to control what workgroup +Samba becomes a part of.</P +><P +>Samba also has a useful option for a Samba server to offer itself for +browsing on another subnet. It is recommended that this option is only +used for 'unusual' purposes: announcements over the internet, for +example. See "remote announce" in the smb.conf man page. </P +></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2590">15.3. Problem resolution</H1 +><P +>If something doesn't work then hopefully the log.nmb file will help +you track down the problem. Try a debug level of 2 or 3 for finding +problems. Also note that the current browse list usually gets stored +in text form in a file called browse.dat.</P +><P +>Note that if it doesn't work for you, then you should still be able to +type the server name as \\SERVER in filemanager then hit enter and +filemanager should display the list of available shares.</P +><P +>Some people find browsing fails because they don't have the global +"guest account" set to a valid account. Remember that the IPC$ +connection that lists the shares is done as guest, and thus you must +have a valid guest account.</P +><P +>Also, a lot of people are getting bitten by the problem of too many +parameters on the command line of nmbd in inetd.conf. This trick is to +not use spaces between the option and the parameter (eg: -d2 instead +of -d 2), and to not use the -B and -N options. New versions of nmbd +are now far more likely to correctly find your broadcast and network +address, so in most cases these aren't needed.</P +><P +>The other big problem people have is that their broadcast address, +netmask or IP address is wrong (specified with the "interfaces" option +in smb.conf)</P +></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2597">15.4. Browsing across subnets</H1 +><P +>With the release of Samba 1.9.17(alpha1 and above) Samba has been +updated to enable it to support the replication of browse lists +across subnet boundaries. New code and options have been added to +achieve this. This section describes how to set this feature up +in different settings.</P +><P +>To see browse lists that span TCP/IP subnets (ie. networks separated +by routers that don't pass broadcast traffic) you must set up at least +one WINS server. The WINS server acts as a DNS for NetBIOS names, allowing +NetBIOS name to IP address translation to be done by doing a direct +query of the WINS server. This is done via a directed UDP packet on +port 137 to the WINS server machine. The reason for a WINS server is +that by default, all NetBIOS name to IP address translation is done +by broadcasts from the querying machine. This means that machines +on one subnet will not be able to resolve the names of machines on +another subnet without using a WINS server.</P +><P +>Remember, for browsing across subnets to work correctly, all machines, +be they Windows 95, Windows NT, or Samba servers must have the IP address +of a WINS server given to them by a DHCP server, or by manual configuration +(for Win95 and WinNT, this is in the TCP/IP Properties, under Network +settings) for Samba this is in the smb.conf file.</P +><DIV +CLASS="SECT2" +><H2 +CLASS="SECT2" +><A +NAME="AEN2602">15.4.1. How does cross subnet browsing work ?</H2 +><P +>Cross subnet browsing is a complicated dance, containing multiple +moving parts. It has taken Microsoft several years to get the code +that achieves this correct, and Samba lags behind in some areas. +However, with the 1.9.17 release, Samba is capable of cross subnet +browsing when configured correctly.</P +><P +>Consider a network set up as follows :</P +><P +><PRE +CLASS="PROGRAMLISTING" +> (DMB) + N1_A N1_B N1_C N1_D N1_E + | | | | | + ------------------------------------------------------- + | subnet 1 | + +---+ +---+ + |R1 | Router 1 Router 2 |R2 | + +---+ +---+ + | | + | subnet 2 subnet 3 | + -------------------------- ------------------------------------ + | | | | | | | | + N2_A N2_B N2_C N2_D N3_A N3_B N3_C N3_D + (WINS)</PRE +></P +><P +>Consisting of 3 subnets (1, 2, 3) connected by two routers +(R1, R2) - these do not pass broadcasts. Subnet 1 has 5 machines +on it, subnet 2 has 4 machines, subnet 3 has 4 machines. Assume +for the moment that all these machines are configured to be in the +same workgroup (for simplicities sake). Machine N1_C on subnet 1 +is configured as Domain Master Browser (ie. it will collate the +browse lists for the workgroup). Machine N2_D is configured as +WINS server and all the other machines are configured to register +their NetBIOS names with it.</P +><P +>As all these machines are booted up, elections for master browsers +will take place on each of the three subnets. Assume that machine +N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on +subnet 3 - these machines are known as local master browsers for +their particular subnet. N1_C has an advantage in winning as the +local master browser on subnet 1 as it is set up as Domain Master +Browser.</P +><P +>On each of the three networks, machines that are configured to +offer sharing services will broadcast that they are offering +these services. The local master browser on each subnet will +receive these broadcasts and keep a record of the fact that +the machine is offering a service. This list of records is +the basis of the browse list. For this case, assume that +all the machines are configured to offer services so all machines +will be on the browse list.</P +><P +>For each network, the local master browser on that network is +considered 'authoritative' for all the names it receives via +local broadcast. This is because a machine seen by the local +master browser via a local broadcast must be on the same +network as the local master browser and thus is a 'trusted' +and 'verifiable' resource. Machines on other networks that +the local master browsers learn about when collating their +browse lists have not been directly seen - these records are +called 'non-authoritative'.</P +><P +>At this point the browse lists look as follows (these are +the machines you would see in your network neighborhood if +you looked in it on a particular network right now).</P +><P +><PRE +CLASS="PROGRAMLISTING" +>Subnet Browse Master List +------ ------------- ---- +Subnet1 N1_C N1_A, N1_B, N1_C, N1_D, N1_E + +Subnet2 N2_B N2_A, N2_B, N2_C, N2_D + +Subnet3 N3_D N3_A, N3_B, N3_C, N3_D</PRE +></P +><P +>Note that at this point all the subnets are separate, no +machine is seen across any of the subnets.</P +><P +>Now examine subnet 2. As soon as N2_B has become the local +master browser it looks for a Domain master browser to synchronize +its browse list with. It does this by querying the WINS server +(N2_D) for the IP address associated with the NetBIOS name +WORKGROUP>1B<. This name was registerd by the Domain master +browser (N1_C) with the WINS server as soon as it was booted.</P +><P +>Once N2_B knows the address of the Domain master browser it +tells it that is the local master browser for subnet 2 by +sending a MasterAnnouncement packet as a UDP port 138 packet. +It then synchronizes with it by doing a NetServerEnum2 call. This +tells the Domain Master Browser to send it all the server +names it knows about. Once the domain master browser receives +the MasterAnnouncement packet it schedules a synchronization +request to the sender of that packet. After both synchronizations +are done the browse lists look like :</P +><P +><PRE +CLASS="PROGRAMLISTING" +>Subnet Browse Master List +------ ------------- ---- +Subnet1 N1_C N1_A, N1_B, N1_C, N1_D, N1_E, + N2_A(*), N2_B(*), N2_C(*), N2_D(*) + +Subnet2 N2_B N2_A, N2_B, N2_C, N2_D + N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*) + +Subnet3 N3_D N3_A, N3_B, N3_C, N3_D + +Servers with a (*) after them are non-authoritative names.</PRE +></P +><P +>At this point users looking in their network neighborhood on +subnets 1 or 2 will see all the servers on both, users on +subnet 3 will still only see the servers on their own subnet.</P +><P +>The same sequence of events that occured for N2_B now occurs +for the local master browser on subnet 3 (N3_D). When it +synchronizes browse lists with the domain master browser (N1_A) +it gets both the server entries on subnet 1, and those on +subnet 2. After N3_D has synchronized with N1_C and vica-versa +the browse lists look like.</P +><P +><PRE +CLASS="PROGRAMLISTING" +>Subnet Browse Master List +------ ------------- ---- +Subnet1 N1_C N1_A, N1_B, N1_C, N1_D, N1_E, + N2_A(*), N2_B(*), N2_C(*), N2_D(*), + N3_A(*), N3_B(*), N3_C(*), N3_D(*) + +Subnet2 N2_B N2_A, N2_B, N2_C, N2_D + N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*) + +Subnet3 N3_D N3_A, N3_B, N3_C, N3_D + N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), + N2_A(*), N2_B(*), N2_C(*), N2_D(*) + +Servers with a (*) after them are non-authoritative names.</PRE +></P +><P +>At this point users looking in their network neighborhood on +subnets 1 or 3 will see all the servers on all sunbets, users on +subnet 2 will still only see the servers on subnets 1 and 2, but not 3.</P +><P +>Finally, the local master browser for subnet 2 (N2_B) will sync again +with the domain master browser (N1_C) and will recieve the missing +server entries. Finally - and as a steady state (if no machines +are removed or shut off) the browse lists will look like :</P +><P +><PRE +CLASS="PROGRAMLISTING" +>Subnet Browse Master List +------ ------------- ---- +Subnet1 N1_C N1_A, N1_B, N1_C, N1_D, N1_E, + N2_A(*), N2_B(*), N2_C(*), N2_D(*), + N3_A(*), N3_B(*), N3_C(*), N3_D(*) + +Subnet2 N2_B N2_A, N2_B, N2_C, N2_D + N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*) + N3_A(*), N3_B(*), N3_C(*), N3_D(*) + +Subnet3 N3_D N3_A, N3_B, N3_C, N3_D + N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), + N2_A(*), N2_B(*), N2_C(*), N2_D(*) + +Servers with a (*) after them are non-authoritative names.</PRE +></P +><P +>Synchronizations between the domain master browser and local +master browsers will continue to occur, but this should be a +steady state situation.</P +><P +>If either router R1 or R2 fails the following will occur:</P +><P +></P +><OL +TYPE="1" +><LI +><P +> Names of computers on each side of the inaccessible network fragments + will be maintained for as long as 36 minutes, in the network neighbourhood + lists. + </P +></LI +><LI +><P +> Attempts to connect to these inaccessible computers will fail, but the + names will not be removed from the network neighbourhood lists. + </P +></LI +><LI +><P +> If one of the fragments is cut off from the WINS server, it will only + be able to access servers on its local subnet, by using subnet-isolated + broadcast NetBIOS name resolution. The effects are similar to that of + losing access to a DNS server. + </P +></LI +></OL +></DIV +></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2637">15.5. Setting up a WINS server</H1 +><P +>Either a Samba machine or a Windows NT Server machine may be set up +as a WINS server. To set a Samba machine to be a WINS server you must +add the following option to the smb.conf file on the selected machine : +in the [globals] section add the line </P +><P +><B +CLASS="COMMAND" +> wins support = yes</B +></P +><P +>Versions of Samba previous to 1.9.17 had this parameter default to +yes. If you have any older versions of Samba on your network it is +strongly suggested you upgrade to 1.9.17 or above, or at the very +least set the parameter to 'no' on all these machines.</P +><P +>Machines with "<B +CLASS="COMMAND" +>wins support = yes</B +>" will keep a list of +all NetBIOS names registered with them, acting as a DNS for NetBIOS names.</P +><P +>You should set up only ONE wins server. Do NOT set the +"<B +CLASS="COMMAND" +>wins support = yes</B +>" option on more than one Samba +server.</P +><P +>To set up a Windows NT Server as a WINS server you need to set up +the WINS service - see your NT documentation for details. Note that +Windows NT WINS Servers can replicate to each other, allowing more +than one to be set up in a complex subnet environment. As Microsoft +refuse to document these replication protocols Samba cannot currently +participate in these replications. It is possible in the future that +a Samba->Samba WINS replication protocol may be defined, in which +case more than one Samba machine could be set up as a WINS server +but currently only one Samba server should have the "wins support = yes" +parameter set.</P +><P +>After the WINS server has been configured you must ensure that all +machines participating on the network are configured with the address +of this WINS server. If your WINS server is a Samba machine, fill in +the Samba machine IP address in the "Primary WINS Server" field of +the "Control Panel->Network->Protocols->TCP->WINS Server" dialogs +in Windows 95 or Windows NT. To tell a Samba server the IP address +of the WINS server add the following line to the [global] section of +all smb.conf files :</P +><P +><B +CLASS="COMMAND" +> wins server = >name or IP address<</B +></P +><P +>where >name or IP address< is either the DNS name of the WINS server +machine or its IP address.</P +><P +>Note that this line MUST NOT BE SET in the smb.conf file of the Samba +server acting as the WINS server itself. If you set both the +"<B +CLASS="COMMAND" +>wins support = yes</B +>" option and the +"<B +CLASS="COMMAND" +>wins server = >name<</B +>" option then +nmbd will fail to start.</P +><P +>There are two possible scenarios for setting up cross subnet browsing. +The first details setting up cross subnet browsing on a network containing +Windows 95, Samba and Windows NT machines that are not configured as +part of a Windows NT Domain. The second details setting up cross subnet +browsing on networks that contain NT Domains.</P +></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2656">15.6. Setting up Browsing in a WORKGROUP</H1 +><P +>To set up cross subnet browsing on a network containing machines +in up to be in a WORKGROUP, not an NT Domain you need to set up one +Samba server to be the Domain Master Browser (note that this is *NOT* +the same as a Primary Domain Controller, although in an NT Domain the +same machine plays both roles). The role of a Domain master browser is +to collate the browse lists from local master browsers on all the +subnets that have a machine participating in the workgroup. Without +one machine configured as a domain master browser each subnet would +be an isolated workgroup, unable to see any machines on any other +subnet. It is the presense of a domain master browser that makes +cross subnet browsing possible for a workgroup.</P +><P +>In an WORKGROUP environment the domain master browser must be a +Samba server, and there must only be one domain master browser per +workgroup name. To set up a Samba server as a domain master browser, +set the following option in the [global] section of the smb.conf file :</P +><P +><B +CLASS="COMMAND" +> domain master = yes</B +></P +><P +>The domain master browser should also preferrably be the local master +browser for its own subnet. In order to achieve this set the following +options in the [global] section of the smb.conf file :</P +><P +><PRE +CLASS="PROGRAMLISTING" +> domain master = yes + local master = yes + preferred master = yes + os level = 65</PRE +></P +><P +>The domain master browser may be the same machine as the WINS +server, if you require.</P +><P +>Next, you should ensure that each of the subnets contains a +machine that can act as a local master browser for the +workgroup. Any NT machine should be able to do this, as will +Windows 95 machines (although these tend to get rebooted more +often, so it's not such a good idea to use these). To make a +Samba server a local master browser set the following +options in the [global] section of the smb.conf file :</P +><P +><PRE +CLASS="PROGRAMLISTING" +> domain master = no + local master = yes + preferred master = yes + os level = 65</PRE +></P +><P +>Do not do this for more than one Samba server on each subnet, +or they will war with each other over which is to be the local +master browser.</P +><P +>The "local master" parameter allows Samba to act as a local master +browser. The "preferred master" causes nmbd to force a browser +election on startup and the "os level" parameter sets Samba high +enough so that it should win any browser elections.</P +><P +>If you have an NT machine on the subnet that you wish to +be the local master browser then you can disable Samba from +becoming a local master browser by setting the following +options in the [global] section of the smb.conf file :</P +><P +><PRE +CLASS="PROGRAMLISTING" +> domain master = no + local master = no + preferred master = no + os level = 0</PRE +></P +></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2674">15.7. Setting up Browsing in a DOMAIN</H1 +><P +>If you are adding Samba servers to a Windows NT Domain then +you must not set up a Samba server as a domain master browser. +By default, a Windows NT Primary Domain Controller for a Domain +name is also the Domain master browser for that name, and many +things will break if a Samba server registers the Domain master +browser NetBIOS name (DOMAIN>1B<) with WINS instead of the PDC.</P +><P +>For subnets other than the one containing the Windows NT PDC +you may set up Samba servers as local master browsers as +described. To make a Samba server a local master browser set +the following options in the [global] section of the smb.conf +file :</P +><P +><PRE +CLASS="PROGRAMLISTING" +> domain master = no + local master = yes + preferred master = yes + os level = 65</PRE +></P +><P +>If you wish to have a Samba server fight the election with machines +on the same subnet you may set the "os level" parameter to lower +levels. By doing this you can tune the order of machines that +will become local master browsers if they are running. For +more details on this see the section "FORCING SAMBA TO BE THE MASTER" +below.</P +><P +>If you have Windows NT machines that are members of the domain +on all subnets, and you are sure they will always be running then +you can disable Samba from taking part in browser elections and +ever becoming a local master browser by setting following options +in the [global] section of the smb.conf file :</P +><P +><B +CLASS="COMMAND" +> domain master = no + local master = no + preferred master = no + os level = 0</B +></P +></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2684">15.8. Forcing samba to be the master</H1 +><P +>Who becomes the "master browser" is determined by an election process +using broadcasts. Each election packet contains a number of parameters +which determine what precedence (bias) a host should have in the +election. By default Samba uses a very low precedence and thus loses +elections to just about anyone else.</P +><P +>If you want Samba to win elections then just set the "os level" global +option in smb.conf to a higher number. It defaults to 0. Using 34 +would make it win all elections over every other system (except other +samba systems!)</P +><P +>A "os level" of 2 would make it beat WfWg and Win95, but not NTAS. A +NTAS domain controller uses level 32.</P +><P +>The maximum os level is 255</P +><P +>If you want samba to force an election on startup, then set the +"preferred master" global option in smb.conf to "yes". Samba will +then have a slight advantage over other potential master browsers +that are not preferred master browsers. Use this parameter with +care, as if you have two hosts (whether they are windows 95 or NT or +samba) on the same local subnet both set with "preferred master" to +"yes", then periodically and continually they will force an election +in order to become the local master browser.</P +><P +>If you want samba to be a "domain master browser", then it is +recommended that you also set "preferred master" to "yes", because +samba will not become a domain master browser for the whole of your +LAN or WAN if it is not also a local master browser on its own +broadcast isolated subnet.</P +><P +>It is possible to configure two samba servers to attempt to become +the domain master browser for a domain. The first server that comes +up will be the domain master browser. All other samba servers will +attempt to become the domain master browser every 5 minutes. They +will find that another samba server is already the domain master +browser and will fail. This provides automatic redundancy, should +the current domain master browser fail.</P +></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2693">15.9. Making samba the domain master</H1 +><P +>The domain master is responsible for collating the browse lists of +multiple subnets so that browsing can occur between subnets. You can +make samba act as the domain master by setting "domain master = yes" +in smb.conf. By default it will not be a domain master.</P +><P +>Note that you should NOT set Samba to be the domain master for a +workgroup that has the same name as an NT Domain.</P +><P +>When samba is the domain master and the master browser it will listen +for master announcements (made roughly every twelve minutes) from local +master browsers on other subnets and then contact them to synchronise +browse lists.</P +><P +>If you want samba to be the domain master then I suggest you also set +the "os level" high enough to make sure it wins elections, and set +"preferred master" to "yes", to get samba to force an election on +startup.</P +><P +>Note that all your servers (including samba) and clients should be +using a WINS server to resolve NetBIOS names. If your clients are only +using broadcasting to resolve NetBIOS names, then two things will occur:</P +><P +></P +><OL +TYPE="1" +><LI +><P +> your local master browsers will be unable to find a domain master + browser, as it will only be looking on the local subnet. + </P +></LI +><LI +><P +> if a client happens to get hold of a domain-wide browse list, and + a user attempts to access a host in that list, it will be unable to + resolve the NetBIOS name of that host. + </P +></LI +></OL +><P +>If, however, both samba and your clients are using a WINS server, then:</P +><P +></P +><OL +TYPE="1" +><LI +><P +> your local master browsers will contact the WINS server and, as long as + samba has registered that it is a domain master browser with the WINS + server, your local master browser will receive samba's ip address + as its domain master browser. + </P +></LI +><LI +><P +> when a client receives a domain-wide browse list, and a user attempts + to access a host in that list, it will contact the WINS server to + resolve the NetBIOS name of that host. as long as that host has + registered its NetBIOS name with the same WINS server, the user will + be able to see that host. + </P +></LI +></OL +></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2711">15.10. Note about broadcast addresses</H1 +><P +>If your network uses a "0" based broadcast address (for example if it +ends in a 0) then you will strike problems. Windows for Workgroups +does not seem to support a 0's broadcast and you will probably find +that browsing and name lookups won't work.</P +></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN2714">15.11. Multiple interfaces</H1 +><P +>Samba now supports machines with multiple network interfaces. If you +have multiple interfaces then you will need to use the "interfaces" +option in smb.conf to configure them. See smb.conf(5) for details.</P +></DIV +></DIV +><DIV +CLASS="NAVFOOTER" +><HR +ALIGN="LEFT" +WIDTH="100%"><TABLE +SUMMARY="Footer navigation table" +WIDTH="100%" +BORDER="0" +CELLPADDING="0" +CELLSPACING="0" +><TR +><TD +WIDTH="33%" +ALIGN="left" +VALIGN="top" +><A +HREF="samba-ldap-howto.html" +ACCESSKEY="P" +>Prev</A +></TD +><TD +WIDTH="34%" +ALIGN="center" +VALIGN="top" +><A +HREF="Samba-HOWTO.html" +ACCESSKEY="H" +>Home</A +></TD +><TD +WIDTH="33%" +ALIGN="right" +VALIGN="top" +><A +HREF="speed.html" +ACCESSKEY="N" +>Next</A +></TD +></TR +><TR +><TD +WIDTH="33%" +ALIGN="left" +VALIGN="top" +>Storing Samba's User/Machine Account information in an LDAP Directory</TD +><TD +WIDTH="34%" +ALIGN="center" +VALIGN="top" +> </TD +><TD +WIDTH="33%" +ALIGN="right" +VALIGN="top" +>Samba performance issues</TD +></TR +></TABLE +></DIV +></BODY +></HTML +>
\ No newline at end of file |