diff options
Diffstat (limited to 'docs/docbook')
| -rw-r--r-- | docs/docbook/faq/config.sgml | 11 | ||||
| -rw-r--r-- | docs/docbook/faq/errors.sgml | 170 | ||||
| -rw-r--r-- | docs/docbook/faq/features.sgml | 376 | ||||
| -rw-r--r-- | docs/docbook/faq/sambafaq.sgml | 37 | ||||
| -rw-r--r-- | docs/docbook/projdoc/Browsing-Quickguide.sgml | 280 |
5 files changed, 874 insertions, 0 deletions
diff --git a/docs/docbook/faq/config.sgml b/docs/docbook/faq/config.sgml new file mode 100644 index 0000000000..78f73252a2 --- /dev/null +++ b/docs/docbook/faq/config.sgml @@ -0,0 +1,11 @@ +<chapter id="Config"> +<title>Configuration problems</title> + +<sect1> +<title>I have set 'force user' and samba still makes 'root' the owner of all the files I touch!</title> +<para> +When you have a user in 'admin users', samba will always do file operations for +this user as 'root', even if 'force user' has been set. +</para> +</sect1> +</chapter> diff --git a/docs/docbook/faq/errors.sgml b/docs/docbook/faq/errors.sgml new file mode 100644 index 0000000000..2f378a3688 --- /dev/null +++ b/docs/docbook/faq/errors.sgml @@ -0,0 +1,170 @@ +<chapter id="errors"> + +<title>Common errors</title> + +<sect1> +<title>Not listening for calling name</title> + +<para> +<programlisting> +Session request failed (131,129) with myname=HOBBES destname=CALVIN +Not listening for calling name +</programlisting> +</para> + +<para> +If you get this when talking to a Samba box then it means that your +global "hosts allow" or "hosts deny" settings are causing the Samba +server to refuse the connection. +</para> + +<para> +Look carefully at your "hosts allow" and "hosts deny" lines in the +global section of smb.conf. +</para> + +<para> +It can also be a problem with reverse DNS lookups not functioning +correctly, leading to the remote host identity not being able to +be confirmed, but that is less likely. +</para> +</sect1> + +<sect1> +<title>System Error 1240</title> + +<para> +System error 1240 means that the client is refusing to talk +to a non-encrypting server. Microsoft changed WinNT in service +pack 3 to refuse to connect to servers that do not support +SMB password encryption. +</para> + +<para>There are two main solutions: +<simplelist> +<member>enable SMB password encryption in Samba. See the encryption part of +the samba HOWTO Collection</member> + +<member>disable this new behaviour in NT. See the section about +Windows NT in the chapter "Portability" of the samba HOWTO collection +</member> +</simplelist> + +</sect1> + +<sect1> +<title>smbclient ignores -N !</title> + +<para> +<quote>When getting the list of shares available on a host using the command +<command>smbclient -N -L</command> +the program always prompts for the password if the server is a Samba server. +It also ignores the "-N" argument when querying some (but not all) of our +NT servers. +</quote> + +<para> +No, it does not ignore -N, it is just that your server rejected the +null password in the connection, so smbclient prompts for a password +to try again. +</para> + +<para> +To get the behaviour that you probably want use <command>smbclient -L host -U%</command> +</para> + +<para> +This will set both the username and password to null, which is +an anonymous login for SMB. Using -N would only set the password +to null, and this is not accepted as an anonymous login for most +SMB servers. +</para> + +</sect1> + +<sect1> +<title>The data on the CD-Drive I've shared seems to be corrupted!</title> + +<para> +Some OSes (notably Linux) default to auto detection of file type on +cdroms and do cr/lf translation. This is a very bad idea when use with +Samba. It causes all sorts of stuff ups. +</para> + +<para> +To overcome this problem use conv=binary when mounting the cdrom +before exporting it with Samba. +</para> + +</sect1> + +<sect1> +<title>Why can users access home directories of other users?</title> + +<para> +<quote> +We are unable to keep individual users from mapping to any other user's +home directory once they have supplied a valid password! They only need +to enter their own password. I have not found *any* method that I can +use to configure samba to enforce that only a user may map their own +home directory. +</quote> +</para> + +<para><quote> +User xyzzy can map his home directory. Once mapped user xyzzy can also map +*anyone* elses home directory! +</quote></para> + +<para> +This is not a security flaw, it is by design. Samba allows +users to have *exactly* the same access to the UNIX filesystem +as they would if they were logged onto the UNIX box, except +that it only allows such views onto the file system as are +allowed by the defined shares. +</para> + +<para> +This means that if your UNIX home directories are set up +such that one user can happily cd into another users +directory and do an ls, the UNIX security solution is to +change the UNIX file permissions on the users home directories +such that the cd and ls would be denied. +</para> + +<para> +Samba tries very hard not to second guess the UNIX administrators +security policies, and trusts the UNIX admin to set +the policies and permissions he or she desires. +</para> + +<para> +Samba does allow the setup you require when you have set the +"only user = yes" option on the share, is that you have not set the +valid users list for the share. +</para> + +<para> +Note that only user works in conjunction with the users= list, +so to get the behavior you require, add the line : +<programlisting> +users = %S +</programlisting> +this is equivalent to: +<programlisting> +valid users = %S +</programlisting> +to the definition of the [homes] share, as recommended in +the smb.conf man page. +</para> + +</sect1> + +<sect1> +<title>Until a few minutes after samba has started, clients get the error "Domain Controller Unavailable"</title> +<para> +A domain controller has to announce on the network who it is. This usually takes a while. +</para> +</sect1> + +</chapter> diff --git a/docs/docbook/faq/features.sgml b/docs/docbook/faq/features.sgml new file mode 100644 index 0000000000..d464885f9e --- /dev/null +++ b/docs/docbook/faq/features.sgml @@ -0,0 +1,376 @@ +<chapter id="features"> + +<title>Features</title> + +<sect1> +<title>How can I prevent my samba server from being used to distribute the Nimda worm?</title> + +<para>Author: HASEGAWA Yosuke (translated by <ulink url="monyo@samba.gr.jp">TAKAHASHI Motonobu</ulink>)</para> + +<para> +Nimba Worm is infected through shared disks on a network, as well as through +Microsoft IIS, Internet Explorer and mailer of Outlook series. +</para> + +<para> +At this time, the worm copies itself by the name *.nws and *.eml on +the shared disk, moreover, by the name of Riched20.dll in the folder +where *.doc file is included. +</para> + +<para> +To prevent infection through the shared disk offered by Samba, set +up as follows: +</para> + +<para> +<programlisting> +[global] + ... + # This can break Administration installations of Office2k. + # in that case, don't veto the riched20.dll + veto files = /*.eml/*.nws/riched20.dll/ +</programlisting> +</para> + +<para> +By setting the "veto files" parameter, matched files on the Samba +server are completely hidden from the clients and making it impossible +to access them at all. +</para> + +<para> +In addition to it, the following setting is also pointed out by the +samba-jp:09448 thread: when the +"readme.txt.{3050F4D8-98B5-11CF-BB82-00AA00BDCE0B}" file exists on +a Samba server, it is visible only as "readme.txt" and dangerous +code may be executed if this file is double-clicked. +</para> + +<para> +Setting the following, +<programlisting> + veto files = /*.{*}/ +</programlisting> +any files having CLSID in its file extension will be inaccessible from any +clients. +</para> + +<para> +This technical article is created based on the discussion of +samba-jp:09448 and samba-jp:10900 threads. +</para> +</sect1> + +<sect1> +<title>How can I use samba as a fax server?</title> + +<para>Contributor: <ulink url="mailto:zuber@berlin.snafu.de">Gerhard Zuber</ulink></para> + +<para>Requirements: +<simplelist> +<member>UNIX box (Linux preferred) with SAMBA and a faxmodem</member> +<member>ghostscript package</member> +<member>mgetty+sendfax package</member> +<member>pbm package (portable bitmap tools)</member> +</simplelist> +</para> + +<para>First, install and configure the required packages. Be sure to read the mgetty+sendfax +manual carefully.</para> + +<sect2> +<title>Tools for printing faxes</title> + +<para>Your incomed faxes are in: +<filename>/var/spool/fax/incoming</filename> + +<para>print it with:</para> + +<para><programlisting> +for i in * +do +g3cat $i | g3tolj | lpr -P hp +done +</programlisting> +</para> + +<para> +g3cat is in the tools-section, g3tolj is in the contrib-section +for printing to HP lasers. +</para> + +<para> +If you want to produce files for displaying and printing with Windows, use +some tools from the pbm-package like the following command: <command>g3cat $i | g3topbm - | ppmtopcx - >$i.pcx</command> +and view it with your favourite Windows tool (maybe paintbrush) +</para> + +</sect2> + +<sect2> +<title>Making the fax-server</title> + +<para>fetch the file <filename>mgetty+sendfax/frontends/winword/faxfilter</filename> and place it in <filename>/usr/local/etc/mgetty+sendfax/</filename>(replace /usr/local/ with whatever place you installed mgetty+sendfax)</para> + +<para>prepare your faxspool file as mentioned in this file +edit fax/faxspool.in and reinstall or change the final +/usr/local/bin/faxspool too. +</para> + +<para><programlisting> +if [ "$user" = "root" -o "$user" = "fax" -o \ + "$user" = "lp" -o "$user" = "daemon" -o "$user" = "bin" ] +</programlisting></para> + +<para>find the first line and change it to the second.</para> + +<para> +make sure you have pbmtext (from the pbm-package). This is +needed for creating the small header line on each page. +</para> + +<para>Prepare your faxheader <filename>/usr/local/etc/mgetty+sendfax/faxheader</filename></para> + +<para> +Edit your /etc/printcap file: +<programlisting> +# FAX +lp3|fax:\ + :lp=/dev/null:\ + :sd=/usr/spool/lp3:\ + :if=/usr/local/etc/mgetty+sendfax/faxfilter:sh:sf:mx#0:\ + :lf=/usr/spool/lp3/fax-log: +</programlisting> + +<para>Now, edit your <filename>smb.conf</filename> so you have a smb based printer named "fax"</para> + +</sect2> + +<sect2> +<title>Installing the client drivers</title> + +<para> +Now you have a printer called "fax" which can be used via +TCP/IP-printing (lpd-system) or via SAMBA (windows printing). +</para> + +<para> +On every system you are able to produce postscript-files you +are ready to fax. +</para> + +<para> +On Windows 3.1 95 and NT: +</para> + +<para> +Install a printer wich produces postscript output, + e.g. apple laserwriter +</para> + +<para>Connect the "fax" to your printer.</para> + +<para> +Now write your first fax. Use your favourite wordprocessor, +write, winword, notepad or whatever you want, and start +with the headerpage. +</para> + +<para> +Usually each fax has a header page. It carries your name, +your address, your phone/fax-number. +</para> + +<para> +It carries also the recipient, his address and his *** fax +number ***. Now here is the trick: +</para> + +<para> +Use the text: +<programlisting> +Fax-Nr: 123456789 +</programlisting> +as the recipients fax-number. Make sure this text does not +occur in regular text ! Make sure this text is not broken +by formatting information, e.g. format it as a single entity. +(Windows Write and Win95 Wordpad are functional, maybe newer + versions of Winword are breaking formatting information). +</para> + +<para> +The trick is that postscript output is human readable and +the faxfilter program scans the text for this pattern and +uses the found number as the fax-destination-number. +</para> + +<para> +Now print your fax through the fax-printer and it will be +queued for later transmission. Use faxrunq for sending the +queue out. +</para> + +</sect2> + +<sect2> +<title>Example smb.conf</title> + +<para><programlisting> +[global] + printcap name = /etc/printcap + print command = /usr/bin/lpr -r -P %p %s + lpq command = /usr/bin/lpq -P %p + lprm command = /usr/bin/lprm -P %p %j + +[fax] + comment = FAX (mgetty+sendfax) + path = /tmp + printable = yes + public = yes + writable = no + create mode = 0700 + browseable = yes + guest ok = no +</programlisting></para> + +</sect2> +</sect1> + +<sect1> +<title>Samba doesn't work well together with DHCP!</title> + +<para> +We wish to help those folks who wish to use the ISC DHCP Server and provide +sample configuration settings. Most operating systems today come ship with +the ISC DHCP Server. ISC DHCP is available from: +<ulink url="ftp://ftp.isc.org/isc/dhcp">ftp://ftp.isc.org/isc/dhcp</ulink> +</para> + +<para> +Incorrect configuration of MS Windows clients (Windows9X, Windows ME, Windows +NT/2000) will lead to problems with browsing and with general network +operation. Windows 9X/ME users often report problems where the TCP/IP and related +network settings will inadvertantly become reset at machine start-up resulting +in loss of configuration settings. This results in increased maintenance +overheads as well as serious user frustration. +</para> + +<para> +In recent times users on one mailing list incorrectly attributed the cause of +network operating problems to incorrect configuration of Samba. +</para> + +<para> +One user insisted that the only way to provent Windows95 from periodically +performing a full system reset and hardware detection process on start-up was +to install the NetBEUI protocol in addition to TCP/IP. This assertion is not +correct. +</para> + +<para> +In the first place, there is NO need for NetBEUI. All Microsoft Windows clients +natively run NetBIOS over TCP/IP, and that is the only protocol that is +recognised by Samba. Installation of NetBEUI and/or NetBIOS over IPX will +cause problems with browse list operation on most networks. Even Windows NT +networks experience these problems when incorrectly configured Windows95 +systems share the same name space. It is important that only those protocols +that are strictly needed for site specific reasons should EVER be installed. +</para> + +<para> +Secondly, and totally against common opinion, DHCP is NOT an evil design but is +an extension of the BOOTP protocol that has been in use in Unix environments +for many years without any of the melt-down problems that some sensationalists +would have us believe can be experienced with DHCP. In fact, DHCP in covered by +rfc1541 and is a very safe method of keeping an MS Windows desktop environment +under control and for ensuring stable network operation. +</para> + +<para> +Please note that MS Windows systems as of MS Windows NT 3.1 and MS Windows 95 +store all network configuration settings a registry. There are a few reports +from MS Windows network administrators that warrant mention here. It would appear +that when one sets certain MS TCP/IP protocol settings (either directly or via +DHCP) that these do get written to the registry. Even though a subsequent +change of setting may occur the old value may persist in the registry. This +has been known to create serious networking problems. +</para> + +<para> +An example of this occurs when a manual TCP/IP environment is configured to +include a NetBIOS Scope. In this event, when the administrator then changes the +configuration of the MS TCP/IP protocol stack, without first deleting the +current settings, by simply checking the box to configure the MS TCP/IP stack +via DHCP then the NetBIOS Scope that is still persistent in the registry WILL be +applied to the resulting DHCP offered settings UNLESS the DHCP server also sets +a NetBIOS Scope. It may therefore be prudent to forcibly apply a NULL NetBIOS +Scope from your DHCP server. The can be done in the dhcpd.conf file with the +parameter: +<command>option netbios-scope "";</command> +</para> + +<para> +While it is true that the Microsoft DHCP server that comes with Windows NT +Server provides only a sub-set of rfc1533 functionality this is hardly an issue +in those sites that already have a large investment and commitment to Unix +systems and technologies. The current state of the art of the DHCP Server +specification in covered in rfc2132. +</para> + +</sect1> + +<sect1> +<title>How can I assign NetBIOS names to clients with DHCP?</title> + +<para> +SMB network clients need to be configured so that all standard TCP/IP name to +address resolution works correctly. Once this has been achieved the SMB +environment provides additional tools and services that act as helper agents in +the translation of SMB (NetBIOS) names to their appropriate IP Addresses. One +such helper agent is the NetBIOS Name Server (NBNS) or as Microsoft called it +in their Windows NT Server implementation WINS (Windows Internet Name Server). +</para> + +<para> +A client needs to be configured so that it has a unique Machine (Computer) +Name. +</para> + +<para> +This can be done, but needs a few NT registry hacks and you need to be able to +speak UNICODE, which is of course no problem for a True Wizzard(tm) :) +Instructions on how to do this (including a small util for less capable +Wizzards) can be found at +</para> + +<para><ulink url="http://www.unixtools.org/~nneul/sw/nt/dhcp-netbios-hostname.html">http://www.unixtools.org/~nneul/sw/nt/dhcp-netbios-hostname.html</ulink></para> + +</sect1> + +<sect1> +<title>How do I convert between unix and dos text formats?</title> + +<para> +Jim barry has written an <ulink url="ftp://samba.org/pub/samba/contributed/fixcrlf.zip"> +excellent drag-and-drop cr/lf converter for +windows</ulink>. Just drag your file onto the icon and it converts the file. +</para> + +<para> +The utilities unix2dos and dos2unix(in the mtools package) should do +the job under unix. +</para> + +</sect1> + +<sect1> +<title>Does samba have wins replication support?</title> + +<para> +At the time of writing there is currently being worked on a wins replication implementation(wrepld). +</para> + +</sect1> + +</chapter> diff --git a/docs/docbook/faq/sambafaq.sgml b/docs/docbook/faq/sambafaq.sgml new file mode 100644 index 0000000000..e9e5ed7a3c --- /dev/null +++ b/docs/docbook/faq/sambafaq.sgml @@ -0,0 +1,37 @@ +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN" [ +<!ENTITY general SYSTEM "general.sgml"> +<!ENTITY install SYSTEM "install.sgml"> +<!ENTITY errors SYSTEM "errors.sgml"> +<!ENTITY clientapp SYSTEM "clientapp.sgml"> +<!ENTITY features SYSTEM "features.sgml"> +<!ENTITY config SYSTEM "config.sgml"> +]> + +<book id="Samba-FAQ"> +<title>Samba FAQ</title> + +<bookinfo> + <author><surname>Samba Team</surname></author> + <pubdate>October 2002</pubdate> +</bookinfo> + +<dedication> +<para> +This is the Frequently Asked Questions (FAQ) document for +Samba, the free and very popular SMB server product. An SMB server +allows file and printer connections from clients such as Windows, +OS/2, Linux and others. Current to version 3.0. Please send any +corrections to the samba documentation mailinglist at +<ulink url="mailto:samba-doc@samba.org">samba-doc@samba.org</ulink>. +This FAQ was based on the old Samba FAQ by Dan Shearer and Paul Blackman, +and the old samba text documents which were mostly written by John Terpstra. +</para> +</dedication> + +&general; +&install; +&config; +&clientapp; +&errors; +&features; +</book> diff --git a/docs/docbook/projdoc/Browsing-Quickguide.sgml b/docs/docbook/projdoc/Browsing-Quickguide.sgml new file mode 100644 index 0000000000..deb431020d --- /dev/null +++ b/docs/docbook/projdoc/Browsing-Quickguide.sgml @@ -0,0 +1,280 @@ +<chapter id="Browsing-Quick"> +<chapterinfo> + <author> + <firstname>John</firstname><surname>Terpstra</surname> + </author> + <pubdate>July 5, 1998</pubdate> +</chapterinfo> + +<title>Quick Cross Subnet Browsing / Cross Workgroup Browsing guide</title> + +<para> +This document should be read in conjunction with Browsing and may +be taken as the fast track guide to implementing browsing across subnets +and / or across workgroups (or domains). WINS is the best tool for resolution +of NetBIOS names to IP addesses. WINS is NOT involved in browse list handling +except by way of name to address mapping. +</para> + +<sect1> +<title>Discussion</title> + +<para> +Firstly, all MS Windows networking is based on SMB (Server Message +Block) based messaging. SMB messaging is implemented using NetBIOS. Samba +implements NetBIOS by encapsulating it over TCP/IP. MS Windows products can +do likewise. NetBIOS based networking uses broadcast messaging to affect +browse list management. When running NetBIOS over TCP/IP this uses UDP +based messaging. UDP messages can be broadcast or unicast. +</para> + +<para> +Normally, only unicast UDP messaging can be forwarded by routers. The +"remote announce" parameter to smb.conf helps to project browse announcements +to remote network segments via unicast UDP. Similarly, the "remote browse sync" +parameter of smb.conf implements browse list collation using unicast UDP. +</para> + +<para> +Secondly, in those networks where Samba is the only SMB server technology +wherever possible nmbd should be configured on one (1) machine as the WINS +server. This makes it easy to manage the browsing environment. If each network +segment is configured with it's own Samba WINS server, then the only way to +get cross segment browsing to work is by using the "remote announce" and +the "remote browse sync" parameters to your smb.conf file. +</para> + +<para> +If only one WINS server is used then the use of the "remote announce" and the +"remote browse sync" parameters should NOT be necessary. +</para> + +<para> +Samba WINS does not support MS-WINS replication. This means that when setting up +Samba as a WINS server there must only be one nmbd configured as a WINS server +on the network. Some sites have used multiple Samba WINS servers for redundancy +(one server per subnet) and then used "remote browse sync" and "remote announce" +to affect browse list collation across all segments. Note that this means +clients will only resolve local names, and must be configured to use DNS to +resolve names on other subnets in order to resolve the IP addresses of the +servers they can see on other subnets. This setup is not recommended, but is +mentioned as a practical consideration (ie: an 'if all else fails' scenario). +</para> + +<para> +Lastly, take note that browse lists are a collection of unreliable broadcast +messages that are repeated at intervals of not more than 15 minutes. This means +that it will take time to establish a browse list and it can take up to 45 +minutes to stabilise, particularly across network segments. +</para> + +</sect1> + +<sect1> +<title>Use of the "Remote Announce" parameter</title> +<para> +The "remote announce" parameter of smb.conf can be used to forcibly ensure +that all the NetBIOS names on a network get announced to a remote network. +The syntax of the "remote announce" parameter is: +<programlisting> + remote announce = a.b.c.d [e.f.g.h] ... +</programlisting> +_or_ +<programlisting> + remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ... +</programlisting> + +where: +<variablelist> +<varlistentry><term>a.b.c.d and e.f.g.h</term> +<listitem><para>is either the LMB (Local Master Browser) IP address +or the broadcst address of the remote network. +ie: the LMB is at 192.168.1.10, or the address +could be given as 192.168.1.255 where the netmask +is assumed to be 24 bits (255.255.255.0). +When the remote announcement is made to the broadcast +address of the remote network every host will receive +our announcements. This is noisy and therefore +undesirable but may be necessary if we do NOT know +the IP address of the remote LMB.</para></listitem> +</varlistentry> + +<varlistentry> +<term>WORKGROUP</term> +<listitem><para>is optional and can be either our own workgroup +or that of the remote network. If you use the +workgroup name of the remote network then our +NetBIOS machine names will end up looking like +they belong to that workgroup, this may cause +name resolution problems and should be avoided. +</para></listitem> + +</variablelist> + +</sect1> + +<sect1> +<title>Use of the "Remote Browse Sync" parameter</title> + +<para> +The "remote browse sync" parameter of smb.conf is used to announce to +another LMB that it must synchronise it's NetBIOS name list with our +Samba LMB. It works ONLY if the Samba server that has this option is +simultaneously the LMB on it's network segment. +</para> + +<para> +The syntax of the "remote browse sync" parameter is: +<programlisting> + remote browse sync = a.b.c.d +</programlisting> + +where a.b.c.d is either the IP address of the remote LMB or else is the network broadcast address of the remote segment. +</para> + +</sect1> + +<sect1> +<title>Use of WINS</title> + +<para> +Use of WINS (either Samba WINS _or_ MS Windows NT Server WINS) is highly +recommended. Every NetBIOS machine registers it's name together with a +name_type value for each of of several types of service it has available. +eg: It registers it's name directly as a unique (the type 0x03) name. +It also registers it's name if it is running the lanmanager compatible +server service (used to make shares and printers available to other users) +by registering the server (the type 0x20) name. +</para> + +<para> +All NetBIOS names are up to 15 characters in length. The name_type variable +is added to the end of the name - thus creating a 16 character name. Any +name that is shorter than 15 characters is padded with spaces to the 15th +character. ie: All NetBIOS names are 16 characters long (including the +name_type information). +</para> + +<para> +WINS can store these 16 character names as they get registered. A client +that wants to log onto the network can ask the WINS server for a list +of all names that have registered the NetLogon service name_type. This saves +broadcast traffic and greatly expedites logon processing. Since broadcast +name resolution can not be used across network segments this type of +information can only be provided via WINS _or_ via statically configured +"lmhosts" files that must reside on all clients in the absence of WINS. +</para> + +<para> +WINS also serves the purpose of forcing browse list synchronisation by all +LMB's. LMB's must synchronise their browse list with the DMB (domain master +browser) and WINS helps the LMB to identify it's DMB. By definition this +will work only within a single workgroup. Note that the domain master browser +has NOTHING to do with what is referred to as an MS Windows NT Domain. The +later is a reference to a security environment while the DMB refers to the +master controller for browse list information only. +</para> + +<para> +Use of WINS will work correctly only if EVERY client TCP/IP protocol stack +has been configured to use the WINS server/s. Any client that has not been +configured to use the WINS server will continue to use only broadcast based +name registration so that WINS may NEVER get to know about it. In any case, +machines that have not registered with a WINS server will fail name to address +lookup attempts by other clients and will therefore cause workstation access +errors. +</para> + +<para> +To configure Samba as a WINS server just add "wins support = yes" to the +smb.conf file [globals] section. +</para> + +<para> +To configure Samba to register with a WINS server just add +"wins server = a.b.c.d" to your smb.conf file [globals] section. +</para> + +<para> +<emphasis>DO NOT EVER</emphasis> use both "wins support = yes" together with "wins server = a.b.c.d" +particularly not using it's own IP address. +</para> + +</sect1> + +<sect1> +<title>Do NOT use more than one (1) protocol on MS Windows machines</title> + +<para> +A very common cause of browsing problems results from installing more than +one protocol on an MS Windows machine. +</para> + +<para> +Every NetBIOS machine take part in a process of electing the LMB (and DMB) +every 15 minutes. A set of election criteria is used to determine the order +of precidence for winning this election process. A machine running Samba or +Windows NT will be biased so that the most suitable machine will predictably +win and thus retain it's role. +</para> + +<para> +The election process is "fought out" so to speak over every NetBIOS network +interface. In the case of a Windows 9x machine that has both TCP/IP and IPX +installed and has NetBIOS enabled over both protocols the election will be +decided over both protocols. As often happens, if the Windows 9x machine is +the only one with both protocols then the LMB may be won on the NetBIOS +interface over the IPX protocol. Samba will then lose the LMB role as Windows +9x will insist it knows who the LMB is. Samba will then cease to function +as an LMB and thus browse list operation on all TCP/IP only machines will +fail. +</para> + +<para> +The safest rule of all to follow it this - USE ONLY ONE PROTOCOL! +</para> + +</sect1> + +<sect1> +<title>Name Resolution Order</title> + +<para> +Resolution of NetBIOS names to IP addresses can take place using a number +of methods. The only ones that can provide NetBIOS name_type information +are: +<simplelist> +<member>WINS: the best tool!</member> +<member>LMHOSTS: is static and hard to maintain.</member> +<member>Broadcast: uses UDP and can not resolve names across remote segments.</member> +</simplelist> +</para> + +<para> +Alternative means of name resolution includes: +<simplelist> +<member>/etc/hosts: is static, hard to maintain, and lacks name_type info</member> +<member>DNS: is a good choice but lacks essential name_type info.</member> +</simplelist> +</para> + +<para> +Many sites want to restrict DNS lookups and want to avoid broadcast name +resolution traffic. The "name resolve order" parameter is of great help here. +The syntax of the "name resolve order" parameter is: +<programlisting> + name resolve order = wins lmhosts bcast host +</programlisting> +_or_ +<programlisting> + name resolve order = wins lmhosts (eliminates bcast and host) +</programlisting> +The default is: +<programlisting> + name resolve order = host lmhost wins bcast +</programlisting>. +where "host" refers the the native methods used by the Unix system +to implement the gethostbyname() function call. This is normally +controlled by <filename>/etc/host.conf</filename>, <filename>/etc/nsswitch.conf</filename> and <filename>/etc/resolv.conf</filename>. +</sect1> +</chapter> |