Remove obsolete information from textdocs

3 files changed, 2 insertions, 372 deletions

diff --git a/docs/textdocs/GOTCHAS.txt b/docs/textdocs/GOTCHAS.txt
index bc5c6dae853..ca8f86f9e65 100644
--- a/docs/textdocs/GOTCHAS.txt
+++ b/docs/textdocs/GOTCHAS.txt
@@ -20,49 +20,3 @@ Details:
 Corrective Action:	Delete the entry after the word loopback
 	in the line starting 127.0.0.1
 =========================================================================
-Item Number:	2.0
-Description:	Problems with MS Windows NT Server network logon service
-Symptom:	Loss of Domain Logon Services and failed Windows NT / 95
-		logon attempts.
-OS:		All Unix systems with Windows NT Domain Control environments.
-Platform:	All
-Date:		February 1, 1997
-Submitted By:	John H Terpstra 
-Details:
-	Samba is configured for Domain logon control in a network
-	where a Windows NT Domain Primary Controller is running.
-
-	Case 1:
-		The Windows NT Server is shut down, then restarted. Then
-		the Samba server is reconfigured so that it NO LONGER offers
-		Domain logon services. Windows NT and 95 workstations can no
-		longer log onto the domain. Ouch!!!
-
-	Case 2:
-		The Windows NT Server which is running the Network logon
-		Service is shut down and restarted while Samba is a domain
-		controller offering the Domain LogOn service. Windows NT
-		Workstation and Server can no longer log onto the network.
-
-	Cause:
-		Windows NT checks at start up to see if any domain logon
-		controllers are already running within the domain. It finds
-		Samba claiming to offer the service and therefore does NOT
-		start its Network Logon Service.
-
-		Windows NT needs the Windows NT network logon service to gain
-		from its Domain controller's SAM database the security
-		identifier for the user loging on.
-
-Work-around:	Stop the Samba nmbd and smbd processes, then on the Windows
-		NT Primary Domain Controller start the Network Logon Service.
-		Now restart the Samba nmbd and smbd services.
-
-		Better still: DO NOT CONFIGURE SAMBA AS THE NETWORK LOGON
-		SERVER, DO NOT SET SAMBA TO BE THE DOMAIN MASTER, DO NOT
-		SET SAMBA TO OS LEVEL GREATER THAN 0.
-
-		ie: Let Windows NT Server be the Domain Logon server, the
-		domain master browser and do NOT interfere with any aspect
-		of Microsoft Windows NT Domain Control.
-=========================================================================
diff --git a/docs/textdocs/HINTS.txt b/docs/textdocs/HINTS.txt
index 877640108ce..7af39adc9fa 100644
--- a/docs/textdocs/HINTS.txt
+++ b/docs/textdocs/HINTS.txt
@@ -1,5 +1,5 @@
 Contributor:	Many
-Updated:	Not for a long time!
+Updated:	October 2002
 
 Subject:	A collection of hints
 Status:		May be useful information but NOT current
@@ -96,44 +96,6 @@ privilages and use it instead. Your users don't need to know the
 password of the guest account.
 
 
------------------------
-HINT: Use the latest TCP/IP stack from microsoft if you use Windows
-for workgroups.
-
-The early TCP/IP stacks had lots of bugs.
-
-Microsoft has released an incremental upgrade to their TCP/IP 32-Bit
-VxD drivers.  The latest release can be found on their ftp site at
-ftp.microsoft.com, located in /peropsys/windows/public/tcpip/wfwt32.exe.
-There is an update.txt file there that describes the problems that were
-fixed.  New files include WINSOCK.DLL, TELNET.EXE, WSOCK.386, VNBT.386,
-WSTCP.386, TRACERT.EXE, NETSTAT.EXE, and NBTSTAT.EXE.
-
-
------------------------
-HINT: nmbd can act as a "WINS" server
-
-By default SMB clients use broadcasts to find shares. Recent clients
-(such as WfWg) can use a "wins" server instead, whcih reduces your
-broadcast traffic and allows you to find names across routers.
-
-Just point your WfWg, Win95 and NT clients at the Samba box in the WINS option.
-
-Note: nmbd does not support all WINS operations. Anyone out there have
-a spec they could send me?
-
------------------------
-HINT: you may need to delete your .pwl files when you change password.
-
-WfWg does a lousy job with passwords. I find that if I change my
-password on either the unix box or the PC the safest thing to do is to
-delete the .pwl files in the windows directory. The PC will complain about not finding the files, but will soon get over it, allowing you to enter the new password.
-
-If you don't do this you may find that WfWg remembers and uses the old
-password, even if you told it a new one.
-
-Often WfWg will totally ignore a password you give it in a dialog box.
-
 ----------------------
 HINT: Using MS Access
 
@@ -147,66 +109,3 @@ Kjellberg <stefank@esi.com.au>
    records'
 
 3. Of course locking must be enabled for the particular share (smb.conf)
-
-
----------------------
-HINT: password cacheing in WfWg
-
-Here is a hint from michael@ecel.uwa.edu.au (Michael Simmons):
-
-In case people where not aware. There is a program call admincfg.exe
-on the last disk (disk 8) of the WFW 3.11 disk set.  To install it
-type EXPAND A:\ADMINCFG.EX_ C:\WINDOWS\ADMINCFG.EXE Then add an icon
-for it via the "Progam Manager" "New" Menu.  This program allows you
-to control how WFW handles passwords.  ie disable Password Caching etc
-for use with "security = user"
-
-
---------------------
-HINT: file descriptor limits
-
-If you have problems with the limits on the number of open files you
-can edit local.h to fix it.
-
---------------------
-HINT: HPUX initgroups() problem
-
-here is a hint from Frank Wales [frank@arcglade.demon.co.uk]:
-
-HP's implementation of supplementary groups is, er, non-standard (for
-hysterical reasons).  There are two group files, /etc/group and
-/etc/logingroup; the system maps UIDs to numbers using the former, but
-initgroups() reads the latter.  Most system admins who know the ropes
-symlink /etc/group to /etc/logingroup (hard link doesn't work for reasons
-too stupid to go into here).  initgroups() will complain if one of the
-groups you're in in /etc/logingroup has what it considers to be an invalid
-ID, which means outside the range [0..UID_MAX], where UID_MAX is (I think)
-60000 currently on HP-UX.  This precludes -2 and 65534, the usual 'nobody'
-GIDs.
-
-Perhaps you could suggest to users that, if they encounter this problem,
-they make sure that the programs that are failing to initgroups() be
-run as users not in any groups with GIDs outside the allowed range.
-
-This is documented in the HP manual pages under setgroups(2) and passwd(4).
-
-
----------------------
-HINT: Patch your SCO system
-
-If you run SCO Unix then you may need to get important TCP/IP patches
-for Samba to work correctly. Try 
-
-Paul_Davis@mindlink.bc.ca writes:
-
-  I was having problems with Accpac using 1.9.02 on SCO Unix.  One
-  posting function reported corrupted data.  After installing uod385a,
-  the problem went away (a restore from backup and then another
-  run-thru).
-
-  It appears that the uod385a update for SCO may be fairly important for
-  a lot of different DOS and Windows software under Samba.
-
-  uod385a can be found at ftp.sco.com /SLS/uod385a.Z and uod385a.ltr.Z.
-
-
diff --git a/docs/textdocs/Recent-FAQs.txt b/docs/textdocs/Recent-FAQs.txt
index feed1278277..d6f4d6b99fe 100644
--- a/docs/textdocs/Recent-FAQs.txt
+++ b/docs/textdocs/Recent-FAQs.txt
@@ -1,86 +1,10 @@
 Contributor:	Samba-bugs@samba.org
-Date:		July 5, 1998
+Date:		October 2002
 Status:		Current
 
 =============================================================================
 Subject: Recent FAQ answers to common questions / problems
 =============================================================================
-Contents:	NetWkstaUserLogon
-		Not listening for calling name
-		System Error 1240
-		Trapdoor UID
-		User Access Control
-		Using NT to Browse Samba Shares
-		setup.exe and 16 bit programs
-		smbclient -N
-
-NetWkstaUserLogon
-=================
-FAQ answer about the new password server code:
-
-In 1.9.18 you can disable the NetWkstaUserLogon call at compile time
-in local.h and from 1.9.18p3 you can now disable it from an option in
-your smb.conf.
-
-The password server behaviour changed because we discovered that bugs
-in some NT servers allowed anyone to login with no password if they
-chose an account name that did not exist on the password server. The 
-NT password server was saying "yes, it's OK to login" even when the 
-account didn't exist at all! Adding the NetWkstaUserLogon call fixed 
-the problem, and follows the "recommended" method that MS have 
-recently documented for pass through authentication.
-
-The problem now is that some NT servers (in particular NT
-workstation?) don't support the NetWkstaUserLogon call. The call also
-doesn't work for accounts in trust relationships.
-
-The eventual solution for this will be to replace the password server
-code in Samba with NT domain code as that is developed. For now you 
-have the choice of compiling Samba either with or without the 
-NetWkstaUserLogon call in the password server code.
-
-In 1.9.18p3 the following was added (copied from the 1.9.18p3 release
-notes):
-
-In the [global] section of smb.conf :
-
-networkstation user login
-
-This code (submitted by Rob Nielsen) allows the code many people 
-were having problems with that queries an NT password server to 
-be turned off at runtime rather than compile time. Please see the 
-documentation in the smb.conf manual page for details. This is a 
-security option - it must only be turned off after checks have been
-made to ensure that your NT password server does not suffer from the
-bug this code was meant to protect against !
-
-In 1.9.18 you can enable/disable this call in local.h. In 1.9.17p5
-you could apply the following patch. Applying this patch will make
-the password server code behave like the code in earlier versions
-of Samba. If you do this then please ensure that you test to see
-that users are prevented from logging in if they give a bogus 
-username/password. You may have a NT server that is affected by the
-bug that this code is designed to avoid.
-
-
---- password.c	1997/10/21 10:09:28	1.25.2.4
-+++ password.c	1997/12/31 06:43:06
-@@ -1619,6 +1619,7 @@
- 	}
- 
- 
-+#if 0
- 	if (!cli_NetWkstaUserLogon(&cli,user,local_machine)) {
- 		DEBUG(1,("password server %s failed NetWkstaUserLogon\n", cli.desthost));
- 		cli_tdis(&cli);
-@@ -1638,6 +1639,7 @@
- 		cli_tdis(&cli);
- 		return False;
- 	}
-+#endif
- 
- 	DEBUG(3,("password server %s accepted the password\n", cli.desthost));
-===============================================================================
 
 Not listening for calling name
 ==============================
@@ -116,153 +40,6 @@ Samba docs
 Samba docs
 ===============================================================================
 
-Trapdoor UID
-============
-> Log message "you appear to have a trapdoor uid system" 
-
-This can have several causes. It might be because you are using a uid
-or gid of 65535 or -1. This is a VERY bad idea, and is a big security
-hole. Check carefully in your /etc/passwd file and make sure that no
-user has uid 65535 or -1. Especially check the "nobody" user, as many
-broken systems are shipped with nobody setup with a uid of 65535.
-
-It might also mean that your OS has a trapdoor uid/gid system :-)
-
-This means that once a process changes effective uid from root to
-another user it can't go back to root. Unfortunately Samba relies on
-being able to change effective uid from root to non-root and back
-again to implement its security policy. If your OS has a trapdoor uid
-system this won't work, and several things in Samba may break. Less
-things will break if you use user or server level security instead of
-the default share level security, but you may still strike
-problems.
-
-The problems don't give rise to any security holes, so don't panic,
-but it does mean some of Samba's capabilities will be unavailable.
-In particular you will not be able to connect to the Samba server as
-two different uids at once. This may happen if you try to print as a
-"guest" while accessing a share as a normal user. It may also affect
-your ability to list the available shares as this is normally done as
-the guest user.
-
-Complain to your OS vendor and ask them to fix their system.
-
-Note: the reason why 65535 is a VERY bad choice of uid and gid is that
-it casts to -1 as a uid, and the setreuid() system call ignores (with
-no error) uid changes to -1. This means any daemon attempting to run
-as uid 65535 will actually run as root. This is not good!
-===============================================================================
-
-User Access Control
-===================
-> In windows when i set up a share in "user mode" i get the message:
->  "You cannot view the list of users at this time. Please try again later."
-> 
-> I know you have lists of users for access and aliasing purposes, but i
-> have read nothing to support the idea that these lists control the Domain
-> Users List...
-
-Samba does NOT at this time support user mode access control for Window 9x
-of for NT. This is a priority item and requires full implementation of the NT SMB 
-protocol calls. Samba-1.9.19 will go into alpha in about 2 months time and will
-have a more full implementation of the NT SMB protocols to support Domain Client
-interoperability. When we can see that this has been succesful we wil then implement
-the NT SMB Server components. This will probably be released as Samba-2.0
-
-Samba-1.9.18p5 is scheduled to go out within 14 days. This will close off the 1.9.18
-branch and then opens the way to progress 1.9.19.
-
-I hope this answers your concerns adequately.
-===============================================================================
-
-Using NT to Browse Samba Shares
-===============================
-> WIN-NT workstations (nt4.0, service pack 3) 
-> samba with
->   security = user
->   encrypt passwords = yes
->   guest account = guest
-> 
-> start the explorer on a win-nt workstation and select network. I find
-> my unix server running samba, but I can not see the list of shares 
-> unless I am  a user, who is known in the smbpasswd of the unix machine.
-> The guest account "guest" exists on my unix machine. For testing I even
-> made him a regular user with a password.
->
-> With my network monitor I can see, that the win-nt workstation uses the
-> current login, to connect to IPC$ on the samba server 
-> (for example "administrator"), not the guest account.
-
-This is exactly how Windows NT works. You MUST have a valid account on the Windows
-NT box you are trying to see the resource list on. If your currently logged in
-account details do NOT match an account on the NT machine you are trying to access
-then you will be presented with a logon box for that machine. When you enter the
-name of an account on that machine / domain, together with a valid password then
-the resource list is made available. If the account details are not correct then
-no resource list is shown.
-
-Samba follows the behaviour of Windows NT exactly.
-
-Warning:Warning:Warning:
-========================
-Samba can be compiled with the GUEST_SESSION_SETUP option at 0,1 or 2.
-The default is 0. If this is set to 1 or 2 then Windows NT machines that DO NOT
-have an account on the Samba server will see the resource list. The down side of this
-is that legitimate users may then be refused access to their legitimate resources.
-Setting this option creates serious security holes. DO NOT DO IT. Samba has the
-value of this option set at 0 - NOT WITHOUT REASON!!!!
-
-******> Warning:Warning:Warning: ****> Do not tamper with this setting!!!
-===============================================================================
-
-setup.exe and 16 bit programs
-=============================
-Running 16 bit programs from Windows NT on a Samba mapped drive
----------------------------------------------------------------
-
-The Windows NT redirector has a bug when running against a 
-Samba or Windows 95 mapped drive and attempting to run a
-16 bit executable.
-
-The problem occurs when the pathname to a 16 bit executable
-contains a non 8.3 filename complient directory component,
-Windows NT will fail to load the program and complain it
-cannot find the path to the program.
-
-It can be verified that this is a bug in Windows NT and
-not Samba as the same problem can be reproduced exactly
-when attempting to run the same program with the same
-pathname from a Windows 95 server (ie. the problem still
-exists even with no Samba server involved).
-
-Microsoft have been made aware of this problem, it is
-unknown if they regard it as serious enough to provide
-a fix for this.
-
-One of the reasons this problem is reported frequently
-is that InstallShield setup.exe executables are frequently
-written as 16 bit programs, and so hit this problem.
-
-As a workaround, you may create (on a Samba server at
-least) a symbolic link with an 8.3 complient name to 
-the non 8.3 complient directory name, and then the 16
-bit program will run. Alternatively, use the 8.3
-complient mangled name to specify the path to run
-the binary.
-
-This will be fixed when Samba adds the NT-specific
-SMB calls (currently targeted for the next major
-Samba release), as once the NT SMB calls are used
-this problem no longer occurs (which is why the
-problem doesn't occur when running against a drive
-mapped to a Windows NT server).
-
-Regards,
-
-	Jeremy Allison.
-	Samba Team.
-===============================================================================
-
 smbclient -N
 ============
 > When getting the list of shares available on a host using the command