--- /dev/null
+Subject: DHCP Server Configuration for SMB Clients
+Date: March 1, 1998
+Contributor: John H Terpstra <jht@samba.anu.edu.au>
+Support: This is an unsupported document. Refer to documentation that is
+ supplied with the ISC DHCP Server. Do NOT email the contributor
+ for ANY assistance.
+===============================================================================
+
+Background:
+===========
+
+We wish to help those folks who wish to use the ISC DHCP Server and provide
+sample configuration settings. Red Hat Linux 5.0 is one operating system that
+comes supplied with the ISC DHCP Server.
+
+Incorrect configuration of MS Windows clients (Windows95, Windows NT Server and
+Workstation) will lead to problems with browsing and with general network
+operation. Windows95 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.
+
+In recent times users on one mailing list oncorrectly attributed the cause of
+network operating problems to incorrect configuration of Samba.
+
+One userinsisted 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.
+
+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.
+
+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.
+
+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.
+
+This document aims to provide enough background information so that the
+majority of site can without too much hardship get the Internet Software
+Consortium's (ISC) DHCP Server into operation. The key benefits of using DHCP
+includes:
+
+1) Automated IP Address space management and maximised re-use of available IP
+Addresses,
+
+2) Automated control of MS Windows client TCP/IP network configuration,
+
+3) Automatic recovery from start-up and run-time problems with Windows95.
+
+
+
+Client Configuration for SMB Networking:
+========================================
+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).
+
+A client needs to be configured so that it has a unique Machine (Computer)
+Name. This can NOT be done via DHCP and must be assigned when MS Windows
+networking is first installed. All remaining TCP/IP networking parameters can
+be assigned via DHCP. These include:
+
+a) IP Address,
+b) Netmask,
+c) Gateway (Router) Address,
+d) DNS Domain Name,
+e) DNS Server addresses,
+f) WINS (NBNS) Server addresses,
+g) IP Forwarding,
+h) Timezone offset,
+i) Node Type,
+
+Other assignments can be made from a DHCP server too, but the above cover the
+major needs.
+
+
+DHCP Server Installation:
+=========================
+It is assumed that you will have obtained a copy of the GPL'd ISC DHCP server
+source files from ftp://ftp.isc.org/pub/dhcp, it is also assumed that you have
+compiled the sources and have installed the binary files.
+
+The following simply serves to provide sample configuration files to enable
+dhcpd to operate. The sample files assume that your site is configured to use
+private IP network address space using the Class B range of 172.16.1.0 -
+172.16.1.255 and is using a netmask of 255.255.255.0 (ie:24 bits). It is
+assumed that you router to the outside world is at 172.16.1.254 and that your
+Internet Domain Name is bestnet.com.au. The IP Address range 172.16.1.100 to
+172.16.1.240 has been set aside as your dynamically allocated range. In
+addition, bestnet.com.au have two print servers that need to obtain settings
+via BOOTP. The machine linux.bestnet.com.au has IP address 172.16.1.1 and is
+you primary Samba server with WINS support enabled by adding the parameter to
+the /etc/smb.conf file: [globals] wins support = yes. The dhcp lease time will
+be set to 20 hours.
+
+Configuration Files:
+====================
+Before dhcpd will run you need to install a file that speifies the
+configuration settings, and another that holds the database of issued IP
+addresses. On many systems these are stored in the /etc directory on the Unix
+system.
+
+Example /etc/dhcpd.conf:
+========================
+server-identifier linux.bestnet.com.au;
+
+subnet 172.16.1.0 netmask 255.255.255.0 {
+ range 172.16.1.100 172.16.1.240;
+ default-lease-time 72000;
+ max-lease-time 144000;
+ option subnet-mask 255.255.255.0;
+ option broadcast-address 172.16.1.255;
+ option routers 172.16.1.254;
+ option domain-name-servers 172.16.1.1, 172.16.1.2;
+ option domain-name "bestnet.com.au";
+ option time-offset 39600;
+ option ip-forwarding off;
+ option netbios-name-servers 172.16.0.1;
+ option netbios-dd-server 172.16.0.1;
+ option netbios-node-type 8;
+}
+
+group {
+ next-server 172.16.1.10;
+ option subnet-mask 255.255.255.0;
+ option domain-name "bestnet.com.au";
+ option domain-name-servers 172.16.1.1, 172.16.0.2;
+ option netbios-name-servers 172.16.0.1;
+ option netbios-dd-server 172.16.0.1;
+ option netbios-node-type 8;
+ option routers 172.16.1.240;
+ option time-offset 39600;
+ host lexmark1 {
+ hardware ethernet 06:07:08:09:0a:0b;
+ fixed-address 172.16.1.245;
+ }
+ host epson4 {
+ hardware ethernet 01:02:03:04:05:06;
+ fixed-address 172.16.1.242;
+ }
+}
+
+
+Creating the /etc/dhcpd.leases file:
+====================================
+At a Unix shell create an empty dhcpd.leases file in the /etc directory.
+You can do this by typing: cp /dev/null /etc/dhcpd.leases
+
+
+Setting up a route table for all-ones addresses:
+================================================
+Quoting from the README file that comes with th eISC DHCPD Server:
+
+ BROADCAST
+
+In order for dhcpd to work correctly with picky DHCP clients (e.g.,
+Windows 95), it must be able to send packets with an IP destination
+address of 255.255.255.255. Unfortunately, Linux insists on changing
+255.255.255.255 into the local subnet broadcast address (here, that's
+192.5.5.223). This results in a DHCP protocol violation, and while
+many DHCP clients don't notice the problem, some (e.g., all Microsoft
+DHCP clients) do. Clients that have this problem will appear not to
+see DHCPOFFER messages from the server.
+
+It is possible to work around this problem on some versions of Linux
+by creating a host route from your network interface address to
+255.255.255.255. The command you need to use to do this on Linux
+varies from version to version. The easiest version is:
+
+ route add -host 255.255.255.255 dev eth0
+
+On some older Linux systems, you will get an error if you try to do
+this. On those systems, try adding the following entry to your
+/etc/hosts file:
+
+255.255.255.255 all-ones
+
+Then, try:
+
+ route add -host all-ones dev eth0
+
+
+For more information please refer to the ISC DHCPD Server documentation.
!==
-!== Printing.txt for Samba release 1.9.18 08 Jan 1998
+!== Printing.txt for Samba release 1.9.18p3 19 Feb 1998
!==
Contributor: Unknown <samba-bugs@samba.anu.edu.au>
Date: Unknown
If the above debug tips don't help, then maybe you need to bring in
the bug gun, system tracing. See Tracing.txt in this directory.
+=====================================================================
+From Caldera Inc., the following documentation has been contributed:
+
+
+8.6 Setting up a raw SAMBA printer.
+
+Note: this is not a guide on setting up SAMBA. It merely addresses creating a printer configuration that will allow the output of regular (i.e. not PostScript) Windows printer drivers to print through SAMBA.
+
+Regular Windows printer drivers can be used to print via SAMBA, but you must set up a raw printer entry in "/etc/printcap" to accomplish this. Also, a print command will need to be specified in "/etc/smb.conf" that forces binary printing.
+
+The best way to start is to use printtool under X to create a new entry specifically for this printer. All you really need for it to do is create the necessary directories and set the permissions correctly, so don't worry about setting up a filter for a specific printer. Filters are not going to be used at all for this entry.
+
+Next, go into "/etc" and edit the printcap entry you just created, changing it to look like this (if you named it something other than raw, the entry name and spool directory should be changed here to match):
+
+raw:\
+:rw:sh:
+:lp=/dev/lp1
+:sd=/var/spool/lpd/raw
+:fx=flp
+
+When this is done and saved, edit the section of the smb.conf file that applies to the printer. Make sure the name of the section (enclosed in brackets) matches the name of the raw printer you just set up, then go down a line or two and add this line:
+
+print command = lpr -b -P%p %s
+
+Save the file, change to "/etc/rc.d/init.d", and type the following commands
+to restart the necessary daemons:
+
+./lpd stop
+./lpd start
+./smb stop
+./smb start
+
+At this point you should be ready to use the various printer drivers on
+your Windows clients for printing.
+=============================================================================
+
--- /dev/null
+#NOFNR Flag in LMHosts to Communicate Across Routers\r
+\r
+ Last reviewed: May 5, 1997 \r
+ Article ID: Q103765 \r
+ The information in this article applies to: \r
+\r
+ Microsoft Windows NT operating system version 3.1 \r
+ Microsoft Windows NT Advanced Server version 3.1 \r
+\r
+ SUMMARY\r
+\r
+ Some of the LAN Manager for UNIX and Pathworks servers may have\r
+problems in communicating across routers with\r
+ Windows NT workstations. The use of #NOFNR flag in the LMHosts\r
+file solves the problem. \r
+\r
+ MORE INFORMATION\r
+\r
+ When you are communicating with a server across a router in a IP\r
+routed environment, the LMHosts file is used to\r
+ resolve Workstation name-to-IP address mapping. The LMHosts\r
+entry for a remote machine name provides the IP\r
+ address for the remote machine. In Lan Manager 2.x, providing\r
+the LMHosts entry eliminates the need to do a Name\r
+ Query broadcast to the local domain and instead a TCP session is\r
+established with the remote machine. Windows NT\r
+ performs the same function in a different way. \r
+\r
+ When an LMHosts entry exists for a remote server, Windows NT\r
+will not send a Name Query broadcast to the local\r
+ subnet and instead send a directed Name Query to the remote\r
+server. If the remote server does not respond to the Name\r
+ Query, further communications (TCP SYN, and so on) will not take\r
+place. This was done to eliminate the performance\r
+ issues when trying to connect to a remote machine when it was\r
+not available (down). \r
+\r
+ Some of the older LAN Manager for UNIX and DEC Pathworks servers\r
+do not respond to directed Name Queries sent\r
+ by Windows NT. In that case, the users will see an error 53\r
+(Path not found), even though they have specified the\r
+ LMHosts entries correctly. A new LMHosts flag #NOFNR was added\r
+to solve this problem. By specifying the\r
+ #NOFNR flag on the same line where the name resolution\r
+information for the server is provided, the directed Name\r
+ Query can be avoided. For example: \r
+\r
+ 130.20.1.1 mylmxserver #PRE #NOFNR\r
+\r
+\r
+ Note that this will only apply to mylmxserver and not to any\r
+other entries in the LMHosts file. To set\r
+ a global flag, an entry could be added in the registry. To\r
+completely remove any directed Name\r
+ Queries sent from a Windows NT machine, create the following\r
+value in\r
+ \r
+HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Nbt\Parameters: \r
+\r
+ NoDirectedFNR REG_DWORD 1\r
+\r
+\r
+ This will cause the directed Name Queries to not go out for any\r
+remote machines.
\ No newline at end of file
git.samba.org / samba.git / commitdiff