From 0e8fd3398771da2f016d72830179507f3edda51b Mon Sep 17 00:00:00 2001 From: Samba Release Account Date: Sat, 4 May 1996 07:50:46 +0000 Subject: Initial version imported to CVS (This used to be commit 291551d80711daab7b7581720bcd9a08d6096517) --- docs/textdocs/BROWSING.txt | 145 ++++++++++++++++ docs/textdocs/BUGS.txt | 123 ++++++++++++++ docs/textdocs/DIAGNOSIS.txt | 237 ++++++++++++++++++++++++++ docs/textdocs/DNIX.txt | 69 ++++++++ docs/textdocs/DOMAIN.txt | 68 ++++++++ docs/textdocs/ENCRYPTION.txt | 333 ++++++++++++++++++++++++++++++++++++ docs/textdocs/HINTS.txt | 202 ++++++++++++++++++++++ docs/textdocs/INSTALL.sambatar | 27 +++ docs/textdocs/PROJECTS | 96 +++++++++++ docs/textdocs/Passwords.txt | 42 +++++ docs/textdocs/README.DCEDFS | 79 +++++++++ docs/textdocs/README.jis | 124 ++++++++++++++ docs/textdocs/README.sambatar | 15 ++ docs/textdocs/SCO.txt | 12 ++ docs/textdocs/SMBTAR.notes | 40 +++++ docs/textdocs/Speed.txt | 272 +++++++++++++++++++++++++++++ docs/textdocs/Support.txt | 376 +++++++++++++++++++++++++++++++++++++++++ docs/textdocs/UNIX-SMB.txt | 220 ++++++++++++++++++++++++ docs/textdocs/WinNT.txt | 56 ++++++ 19 files changed, 2536 insertions(+) create mode 100644 docs/textdocs/BROWSING.txt create mode 100644 docs/textdocs/BUGS.txt create mode 100644 docs/textdocs/DIAGNOSIS.txt create mode 100644 docs/textdocs/DNIX.txt create mode 100644 docs/textdocs/DOMAIN.txt create mode 100644 docs/textdocs/ENCRYPTION.txt create mode 100644 docs/textdocs/HINTS.txt create mode 100644 docs/textdocs/INSTALL.sambatar create mode 100644 docs/textdocs/PROJECTS create mode 100644 docs/textdocs/Passwords.txt create mode 100644 docs/textdocs/README.DCEDFS create mode 100644 docs/textdocs/README.jis create mode 100644 docs/textdocs/README.sambatar create mode 100644 docs/textdocs/SCO.txt create mode 100644 docs/textdocs/SMBTAR.notes create mode 100644 docs/textdocs/Speed.txt create mode 100644 docs/textdocs/Support.txt create mode 100644 docs/textdocs/UNIX-SMB.txt create mode 100644 docs/textdocs/WinNT.txt (limited to 'docs/textdocs') diff --git a/docs/textdocs/BROWSING.txt b/docs/textdocs/BROWSING.txt new file mode 100644 index 0000000000..8a09d2274f --- /dev/null +++ b/docs/textdocs/BROWSING.txt @@ -0,0 +1,145 @@ +BROWSING +======== + +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)). + +Samba can act as a browse master for a workgroup, but currently cannot +act as a domain controller. The ability to be a domain controller will +be added in a later version. + +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. + +The -G option is most useful for simple setups where Samba is browsable +in only one workgroup. In more complex cases the lmhosts file is +better. + +Be very careful setting up your lmhosts file. An incorrectly setup +lmhosts file can have disasterous results for your net! + +A simple lmhosts file might be: + +# This is a simple lmhosts file +# +# This is a host alias. Anyone querying this name +# will get the specified IP +192.0.2.17 SMBDATA +# +# first put ourselves in workgroup MYGROUP using +# our own net address +0.0.0.0 MYGROUP G + +Note in the above that I overrode what workgroup Samba is in using the +G flag. Also note that the 0.0.0.0 address is used, which will be +automatically replaced with the broadcast address for groups, and with +the local IP address for other entries. + +Samba also has a useful option for a Samba server to offer itself for +browsing on another subnet. + +This works by the lmhosts file specifying a broadcast address on the +other network to use to find a browse master for the workgroup. + +For example if you wanted yourself to appear in the workgroup STAFF on +the network which has a broadcast of 192.0.3.255 then this entry would +do the trick: + +# put ourselves in the STAFF workgroup on the other subnet +192.0.3.255 STAFF G + +Notice the G at the end! It is very important you include this as this +entry without the G could cause a broadcast storm! + +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. + +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. + +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. + +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 +addess, so in most cases these aren't needed. + +The other big problem people have is that their broadcast address, +netmask or IP address is wrong (specified with the -B, -N and -I +options to nmbd). + +FORCING SAMBA TO BE THE MASTER +============================== + +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. + +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 33 +would make it win all elections over every other system (except other +samba systems!) + +A "os level" of 2 would make it beat WfWg and Win95, but not NTAS. A +NTAS domain controller uses level 32. + +The maximum os level is 255 + +MAKING SAMBA THE DOMAIN MASTER +============================== + +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. + +When samba is the domain master and the master browser it will listen +for master announcements from other subnets and then contact them to +synchronise browse lists. + +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. + +NOTIFYING THE DOMAIN CONTROLLER +=============================== + +If you have a domain controller for the domain which Samba is a part +of then you should add the line "domain controller = address" to +smb.conf. "address" can either be a name available via DNS or a IP +address or a broadcast address. If it is a broadcast address then +Samba will look for a domain controller on that network. + +When Samba is the master browser it will regularly contact the domain +controller to synchronise browse lists. + + +NOTE ABOUT BROADCAST ADDRESSES +============================== + +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. + +You have a few options: + +1) change to a 1's broadcast on your unix server. These often end in +.255 (check with your local network guru for details) + +2) set the nmbd broadcast to a 1's based address on the command line using +the -B option. This only works if your network setup listens on both +0s and 1s based broadcasts. The -B option can only control what +address it sends to, not what it listens on. + + diff --git a/docs/textdocs/BUGS.txt b/docs/textdocs/BUGS.txt new file mode 100644 index 0000000000..e0fd695147 --- /dev/null +++ b/docs/textdocs/BUGS.txt @@ -0,0 +1,123 @@ +This file describes how to report Samba bugs. + +>> The email address for bug reports is samba-bugs@anu.edu.au << + +(NOTE: This mail may not be in place yet. If you have troubles with it +then use samba-bugs@arvidsjaur.anu.edu.au) + + +Please take the time to read this file before you submit a bug +report. Also, please see if it has changed between releases, as I +may be changing the bug reporting mechanism sometime soon. + +Please also do as much as you can yourself to help track down the +bug. I only develop Samba in my spare time and I receive far more mail +about it than I can possibly answer, so you have a much higher chance +of an answer and a fix if you send me a "developer friendly" bug +report that lets me fix it fast. + +Do not assume that if you post the bug to the comp.protocols.smb +newsgroup that I will read it. I do read all postings to the samba +mailing list (see the README). If you suspect that your problem is not +a bug but a configuration problem then it is better to send it to the +Samba mailing list, as there are (at last count) 1900 other users on +that list that may be able to help you. + +You may also like to look though the recent mailing list archives, +which are conveniently accessible on the Samba web pages +at http://lake.canberra.edu.au/pub/samba/ + + +GENERAL INFO +------------ + +Before submitting a bug report check your config for silly +errors. Look in your log files for obvious messages that tell you that +you've misconfigured something and run testparm to test your config +file for correct syntax. + +If you include part of a log file with your bug report then be sure to +annotate it with exactly what you were doing on the client at the +time, and exactly what the results were. + + +DEBUG LEVELS +------------ + +If the bug has anything to do with Samba behaving incorrectly as a +server (like refusing to open a file) then the log files will probably +be very useful. Depending on the problem a log level of between 3 and +10 showing the problem may be appropriate. A higher level givesmore +detail, but may use too much disk space. + +To set the debug level use "log level =" in your smb.conf. You may +also find it useful to set the log level higher for just one machine +and keep separate logs for each machine. To do this use: + +log file = /usr/local/samba/lib/log.%m +include = /usr/local/samba/lib/smb.conf.%m + +then create a file "/usr/local/samba/lib/smb.conf.machine" where +"machine" is the name of the client you wish to debug. In that file +put any smb.conf commands you want, for example "log level=" may be +useful. This also allows you to experiment with different security +systems, protocol levels etc on just one machine. + + +INTERNAL ERRORs +--------------- + +If you get a "INTERNAL ERROR" message in your log files it means that +Samba got an unexpected signal while running. It is probably a +segmentation fault and almost certainly means a bug in Samba (unless +you have faulty hardware or system software) + +If the message came from smbd then it will probably be accompanied by +a message which details the last SMB message received by smbd. This +info is often very useful in tracking down the problem so please +include it in your bug report. + +You should also detail how to reproduce the problem, if +possible. Please make this reasonably detailed. + +You may also find that a core file appeared in a "corefiles" +subdirectory of the directory where you keep your samba log +files. This file is the most useful tool for tracking down the bug. To +use it you do this: + +gdb smbd core + +adding appropriate paths to smbd and core so gdb can find them. If you +don't have gdb then try "dbx". Then within the debugger use the +command "where" to give a stack trace of where the problem +occurred. Include this in your mail. + +If you known any assembly language then do a "disass" of the routine +where the problem occurred (if its in a library routine then +disassemble the routine that called it) and try to work out exactly +where the problem is by looking at the surrounding code. Even if you +don't know assembly then incuding this info in the bug report can be +useful. + + +ATTACHING TO A RUNNING PROCESS +------------------------------ + +Unfortunately some unixes (in particular some recent linux kernels) +refuse to dump a core file if the task has changed uid (which smbd +does often). To debug with this sort of system you could try to attach +to the running process using "gdb smbd PID" where you get PID from +smbstatus. Then use "c" to continue and try to cause the core dump +using the client. The debugger should catch the fault and tell you +where it occurred. + + +PATCHES +------- + +The best sort of bug report is one that includes a fix! If you send me +patches please use "diff -u" format if your version of diff supports +it, otherwise use "diff -c4". Make sure your do the diff against a +clean version of the source and let me know exactly what version you +used. + diff --git a/docs/textdocs/DIAGNOSIS.txt b/docs/textdocs/DIAGNOSIS.txt new file mode 100644 index 0000000000..6681bdc4bc --- /dev/null +++ b/docs/textdocs/DIAGNOSIS.txt @@ -0,0 +1,237 @@ +DIAGNOSING YOUR SAMBA SERVER +============================ + +This file contains a list of tests you can perform to validate your +Samba server. It also tells you what the likely cause of the problem +is if it fails any one of these steps. If it passes all these tests +then it is probably working fine. + +You should do ALL the tests, in the order shown. I have tried to +carefully choose them so later tests only use capabilities verified in +the earlier tests. + +I would welcome additions to this set of tests. Please mail them to +samba-bugs@anu.edu.au + +If you send me an email saying "it doesn't work" and you have not +followed this test procedure then you should not be surprised if I +ignore your email. + + +ASSUMPTIONS +----------- + +In all of the tests I assume you have a Samba server called BIGSERVER +and a PC called ACLIENT. I also assume the PC is running windows for +workgroups with a recent copy of the microsoft tcp/ip stack. The +procedure is similar for other types of clients. + +I also assume you know the name of a available share in your +smb.conf. I will assume this share is called "tmp". You can add a +"tmp" share like by adding the following to smb.conf: + +[tmp] + comment = temporary files + path = /tmp + read only = yes + + +THESE TESTS ASSUME VERSION 1.9.15 OR LATER OF THE SAMBA SUITE. SOME +COMMANDS SHOWN DID NOT EXIST IN EARLIER VERSIONS + + +TEST 1: +------- + +run the command "testparm". If it reports any errors then your +smb.conf configuration file is faulty. + + +TEST 2: +------- + +run the command "ping BIGSERVER" from the PC and "ping ACLIENT" from +the unix box. If you don't get a valid response then your TCP/IP +software is not correctly installed. + +Note that you will need to start a "dos prompt" window on the PC to +run ping. + +If you get a message saying "host not found" or similar then your DNS +software or /etc/hosts file is not correctly setup. It is possible to +run samba without DNS entries for the server and client, but I assume +you do have correct entries for the remainder of these tests. + + +TEST 3: +------- + +run the command "smbclient -L BIGSERVER -U%" on the unix box. You +should get a list of available shares back. + +If you get a error message containing the string "Bad password" then +you probably have either an incorrect "hosts allow", "hosts deny" or +"valid users" line in your smb.conf, or your guest account is not +valid. Check what your guest account is using "testparm" and +temporarily remove any "hosts allow", "hosts deny", "valid users" or +"invalid users" lines. + +If you get a "connection refused" response then the smbd server could +not be run. If you installed it in inetd.conf then you probably edited +that file incorrectly. If you installed it as a daemon then check that +it is running, and check that the netbios-ssn port is in a LISTEN +state using "netstat -a". + +If you get a "session request failed" then the server refused the +connection. If it says "your server software is being unfriendly" then +its probably because you have invalid command line parameters to smbd, +or a similar fatal problem with the initial startup of smbd. Also +check your config file for syntax errors with "testparm". + +TEST 4: +------- + +run the command "nmblookup -B BIGSERVER __SAMBA__". You should get the +IP address of your Samba server back. + +If you don't then nmbd is incorrectly installed. Check your inetd.conf +if yu run it from there, or that the daemon is running and listening +to udp port 137. + +One common problem is that many inetd implementations can't take many +parameters on the command line. If this is the case then create a +one-line script that contains the right parameters and run that from +inetd. + +TEST 5: +------- + +run the command "nmblookup -B ACLIENT '*'" + +You should get the PCs IP address back. If you don't then the client +software on the PC isn't installed correctly, or isn't started, or you +got the name of the PC wrong. Note that you probably won't get a "node +status response" from the PC due to a bug in the microsoft netbios +nameserver implementation (it responds to the wrong port number). + +TEST 6: +------- + +run the command "nmblookup -d 2 '*'" + +This time we are trying the same as the previous test but are trying +it via a broadcast to the default broadcast address. A number of +Netbios/TCPIP hosts on the network should respond, although Samba may +not catch all of the responses in the short time it listens. You +should see "got a positive name query response" messages from several +hosts. + +If this doesn't give a similar result to the previous test then +nmblookup isn't correctly getting your broadcast address through its +automatic mechanism. In this case you should experiment with the -B +option which allows you to manually specify the broadcast address, +overriding the automatic detection. You should try different broadcast +addresses until your find the one that works. It will most likely be +something like a.b.c.255 as microsoft tcpip stacks only listen on 1's +based broadcast addresses. If you get stuck then ask your local +networking guru for help (and show them this paragraph). + +If you find you do need the -B option (ie. the automatic detection +doesn't work) then you should add the -B option with the right +broadcast address for your network to the command line of nmbd in +inetd.conf or in the script you use to start nmbd as a daemon. Once +you do this go back to the "nmblookup __SAMBA__ -B BIGSERVER" test to +make sure you have it running properly. + +If your PC and server aren't on the same subnet then you will need to +use the -B option to set the broadcast address to the that of the PCs +subnet. + +TEST 7: +------- + +run the command "smbclient '\\BIGSERVER\TMP'". You should then be +prompted for a password. You should use the password of the account +you are logged into the unix box with. If you want to test with +another account then add the -U option to the command +line. + +Once you enter the password you should get the "smb>" prompt. If you +don't then look at the error message. If it says "invalid network +name" then the service "tmp" is not correctly setup in your smb.conf. + +If it says "bad password" then the likely causes are: + +- you have shadow passords (or some other password system) but didn't +compile in support for them in smbd +- your "valid users" configuration is incorrect +- you have a mixed case password and you haven't enabled the "password +level" option at a high enough level +- the "path =" line in smb.conf is incorrect. Check it with testparm + +Once connected you should be able to use the commands "dir" "get" +"put" etc. Type "help " for instructions. You should +especially check that the amount of free disk space shown is correct +when you type "dir". + + +TEST 8: +------- + +On the PC type the command "net view \\BIGSERVER". You will need to do +this from within a "dos prompt" window. You should get back a list of +available shares on the server. + +If you get a "network name not found" or similar error then netbios +name resolution is not working. This is usually caused by a problem in +nmbd. To overcome it you could do one of the following (you only need +to choose one of them): + +- fixup the nmbd installation +- add the IP address of BIGSERVER to the "wins server" box in the +advanced tcp/ip setup on the PC. +- enable windows name resolution via DNS in the advanced section of +the tcp/ip setup +- add BIGSERVER to your lmhosts file on the PC. + +If you get a "invalid network name" or "bad password error" then the +same fixes apply as they did for the "smbclient -L" test above. In +particular, make sure your "hosts allow" line is correct (see the man +pages) + + +TEST 9: +-------- + +run the command "net use x: \\BIGSERVER\TMP". You should be prompted +for a password then you should get a "command completed successfully" +message. If not then your PC software is incorrectly installed or your +smb.conf is incorrect. make sure your "hosts allow" and other config +lines in smb.conf are correct. + +It's also possible that the server can't work out what user name to +connect you as. To see if this is the problem add the line "user = +USERNAME" to the [tmp] section of smb.conf where "USERNAME" is the +username corresponding to the password you typed. If you find this +fixes things you may need the username mapping option. + + +TEST 10: +-------- + +From file manager try to browse the server. Your samba server should +appear in the browse list of your local workgroup (or the one you +specified in the Makefile). You should be able to double click on the +name of the server and get a list of shares. If you get a "invalid +password" error when you do then you are probably running WinNT and it +is refusing to browse a server that has no encrypted password +capability and is in user level security mode. + + +Still having troubles? +---------------------- + +Try the mailing list or newsgroup, or use the tcpdump-smb utility to +sniff the problem. + + diff --git a/docs/textdocs/DNIX.txt b/docs/textdocs/DNIX.txt new file mode 100644 index 0000000000..51005e6ec8 --- /dev/null +++ b/docs/textdocs/DNIX.txt @@ -0,0 +1,69 @@ +DNIX has a problem with seteuid() and setegid(). These routines are +needed for Samba to work correctly, but they were left out of the DNIX +C library for some reason. + +For this reason Samba by default defines the macro NO_EID in the DNIX +section of includes.h. This works around the problem in a limited way, +but it is far from ideal, some things still won't work right. + +To fix the problem properly you need to assemble the following two +functions and then either add them to your C library or link them into +Samba. + +put this in the file setegid.s: + + .globl _setegid +_setegid: + moveq #47,d0 + movl #100,a0 + moveq #1,d1 + movl 4(sp),a1 + trap #9 + bccs 1$ + jmp cerror +1$: + clrl d0 + rts + + +put this in the file seteuid.s: + + .globl _seteuid +_seteuid: + moveq #47,d0 + movl #100,a0 + moveq #0,d1 + movl 4(sp),a1 + trap #9 + bccs 1$ + jmp cerror +1$: + clrl d0 + rts + +after creating the above files you then assemble them using + +as seteuid.s +as setegid.s + +that should produce the files seteuid.o and setegid.o + +then you need to add these to the LIBSM line in the DNIX section of +the Samba Makefile. Your LIBSM line will then look something like this: + +LIBSM = setegid.o seteuid.o -ln + +You should then remove the line: + +#define NO_EID + +from the DNIX section of includes.h + +Then recompile and try it out! + +Note that this file was derived from an email from Peter Olsson +. I don't have DNIX myself, so you're probably better +off contacting Peter if you have problems. + +Andrew + diff --git a/docs/textdocs/DOMAIN.txt b/docs/textdocs/DOMAIN.txt new file mode 100644 index 0000000000..31e19675fa --- /dev/null +++ b/docs/textdocs/DOMAIN.txt @@ -0,0 +1,68 @@ +Samba now supports domain logons and network logon scripts. The +support is still experimental, but it seems to work. + +The support is also not complete. Samba does not yet support the +sharing of the SAM database with other systems yet, or remote +administration. Support for these kind of things should be added +sometime in the future. + +The domain support only works for WfWg and Win95 clients. Support for +NT and OS/2 clients is still being worked on. + +Using these features you can make your clients verify their logon via +the Samba server and make clients run a batch file when they logon to +the network. The latter is particularly useful. + +To use domain logons you need to do the following: + +1) Setup nmbd and smbd and configure the smb.conf so that Samba is +acting as the master browser. See INSTALL.txt and BROWSING.txt for +details. + +2) create a share called [netlogon] in your smb.conf. This share should +be readable by all users, and probably should not be writeable. This +share will hold your network logon scripts. + +For example I have used: + + [netlogon] + path = /data/dos/netlogon + writeable = no + guest ok = yes + + +3) in the [global] section of smb.conf set the following: + + domain logons = yes + logon script = %U.bat + +the choice of batch file is, of course, up to you. The above would +give each user a separate batch file as the %U will be changed to +their username automatically. The other standard % macros may also be +used. You can make the btch files come from a subdirectory by using +soemthing like: + + logon script = scripts\%U.bat + +4) create the batch files to be run when the user logs in. If the batch +file doesn't exist then no batch file will be run. + +In the batch files you need to be careful to use DOS style cr/lf line +endings. If you don't then DOS may get confused. I suggest you use a +DOS editor to remotely edit the files if you don't know how to produce +DOS style files under unix. + +5) Use smbclient with the -U option for some users to make sure that +the \\server\NETLOGON share is available, the batch files are visible +and they are readable by the users. + +6) you will probabaly find that your clients automatically mount the +\\SERVER\NETLOGON share as drive z: while logging in. You can put some +useful programs there to execute from the batch files. + + +NOTE: You must be using "security = user" or "security = server" for +domain logons to work correctly. Share level security won't work +correctly. + + diff --git a/docs/textdocs/ENCRYPTION.txt b/docs/textdocs/ENCRYPTION.txt new file mode 100644 index 0000000000..046b473e9a --- /dev/null +++ b/docs/textdocs/ENCRYPTION.txt @@ -0,0 +1,333 @@ + LanManager / Samba Password Encryption. + --------------------------------------- + +With the development of LanManager compatible password encryption for +Samba, it is now able to validate user connections in exactly the same +way as a LanManager or Windows NT server. + +This document describes how the SMB password encryption algorithm +works and what issues there are in choosing whether you want to use +it. You should read it carefully, especially the part about security +and the "PROS and CONS" section. + +How does it work ? +------------------ + + LanManager encryption is somewhat similar to UNIX password +encryption. The server uses a file containing a hashed value of a +users password. This is created by taking the users paintext +password, capitalising it, and either truncating to 14 bytes (or +padding to 14 bytes with null bytes). This 14 byte value is used as +two 56 bit DES keys to encrypt a 'magic' eight byte value, forming a +16 byte value which is stored by the server and client. Let this value +be known as the *hashed password*. + +When a client (LanManager, Windows for WorkGroups, Windows 95 or +Windows NT) wishes to mount a Samba drive (or use a Samba resource) it +first requests a connection and negotiates the protocol that the client +and server will use. In the reply to this request the Samba server +generates and appends an 8 byte, random value - this is stored in the +Samba server after the reply is sent and is known as the *challenge*. + +The challenge is different for every client connection. + +The client then uses the hashed password (16 byte value described +above), appended with 5 null bytes, as three 56 bit DES keys, each of +which is used to encrypt the challenge 8 byte value, forming a 24 byte +value known as the *response*. + +In the SMB call SMBsessionsetupX (when user level security is +selected) or the call SMBtconX (when share level security is selected) +the 24 byte response is returned by the client to the Samba server. + +The Samba server then reproduces the above calculation, using it's own +stored value of the 16 byte hashed password (read from the smbpasswd +file - described later) and the challenge value that it kept from the +negotiate protocol reply. It then checks to see if the 24 byte value it +calculates matches the 24 byte value returned to it from the client. + +If these values match exactly, then the client knew the correct +password (or the 16 byte hashed value - see security note below) and +is this allowed access. If not then the client did not know the +correct password and is denied access. + +Note that the Samba server never knows or stores the cleartext of the +users password - just the 16 byte hashed function derived from it. Also +note that the cleartext password or 16 byte hashed value are never +transmitted over the network - thus increasing security. + +IMPORTANT NOTE ABOUT SECURITY +----------------------------- + +The unix and SMB password encryption techniques seem similar on the +surface. This similarity is, however, only skin deep. The unix scheme +typically sends clear text passwords over the nextwork when logging +in. This is bad. The SMB encryption scheme never sends the cleartext +password over the network but it does store the 16 byte hashed value +on disk. This is also bad. Why? Because the 16 byte hashed value is a +"password equivalent". You cannot derive the users password from it, +but it could potentially be used in a modified client to gain access +to a server. This would require considerable technical knowledge on +behalf of the attacker but is perfectly possible. You should thus +treat the smbpasswd file as though it contained the cleartext +passwords of all your users. Its contents must be kept secret, and the +file should be protected accordingly. + +Ideally we would like a password scheme which neither requires plain +text passwords on the net or on disk. Unfortunately this is not +available as Samba is stuck with being compatible with other SMB +systems (WinNT, WfWg, Win95 etc). + + +PROS AND CONS +------------- + +There are advantages and disadvantages to both schemes. + +Advantages of SMB Encryption: +----------------------------- + +- plain text passwords are not passed across the network. Someone using +a network sniffer cannot just record passwords going to the SMB server. + +- WinNT doesn't like talking to a server that isn't using SMB +encrypted passwords. It will refuse to browse the server if the server +is also in user level security mode. It will insist on promting the +user for the password on each connection, which is very annoying. The +only things you can do to stop this is to use SMB encryption. + +Advantages of non-encrypted passwords: +-------------------------------------- + +- plain text passwords are not kept on disk. + +- uses same password file as other unix services such as login and +ftp + +- you are probably already using other services (such as telnet and +ftp) which send plain text passwords over the net, so not sending them +for SMB isn't such a big deal. + +- the SMB encryption code in Samba is new and has only had limited +testing. We have tried hard to make it secure but in any new +implementation of a password scheme there is the possability of an +error. + + +The smbpasswd file. +------------------- + + In order for Samba to participate in the above protocol it must +be able to look up the 16 byte hashed value given a user name. +Unfortunately, as the UNIX password value is also a one way hash +function (ie. it is impossible to retrieve the cleartext of the users +password given the UNIX hash of it) then a separate password file +containing this 16 byte value must be kept. To minimise problems with +these two password files, getting out of sync, the UNIX /etc/passwd and +the smbpasswd file, a utility, mksmbpasswd.sh, is provided to generate +a smbpasswd file from a UNIX /etc/passwd file. + +To generate the smbpasswd file from your /etc/passwd file use the +following command :- + +cat /etc/passwd | mksmbpasswd.sh >/usr/local/samba/private/smbpasswd + +If you are running on a system that uses NIS, use + +ypcat passwd | mksmbpasswd.sh >/usr/local/samba/private/smbpasswd + +The mksmbpasswd.sh program is found in the Samba source directory. By +default, the smbpasswd file is stored in :- + +/usr/local/samba/private/smbpasswd + +The owner of the /usr/local/samba/private directory should be set to +root, and the permissions on it should be set to :- + +r-x------ + +The command + +chmod 500 /usr/local/samba/private + +will do the trick. Likewise, the smbpasswd file inside the private +directory should be owned by root and the permissions on is should be +set to + +rw------- + +by the command :- + +chmod 600 smbpasswd. + +The format of the smbpasswd file is + +username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:Long name:user home dir:user shell + +Although only the username, uid, and XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +sections are significant and are looked at in the Samba code. + +It is *VITALLY* important that there by 32 'X' characters between the +two ':' characters - the smbpasswd and Samba code will fail to validate +any entries that do not have 32 characters between ':' characters. + +When the password file is created all users have password entries +consisting of 32 'X' characters. By default this disallows any access +as this user. When a user has a password set, the 'X' characters change +to 32 ascii hexadecimal digits (0-9, A-F). These are an ascii +representation of the 16 byte hashed value of a users password. + +To set a user to have no password (not recommended), edit the file +using vi, and replace the first 11 characters with the asci text + +NO PASSWORD + +Eg. To clear the password for user bob, his smbpasswd file entry would +look like : + +bob:100:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:Bob's full name:/bobhome:/bobshell + +If you are allowing users to use the smbpasswd command to set their own +passwords, you may want to give users NO PASSWORD initially so they do +not have to enter a previous password when changing to their new +password (not recommended). + +Note : This file should be protected very carefully. Anyone with +access to this file can (with enough knowledge of the protocols) gain +access to your SMB server. The file is thus more sensitive than a +normal unix /etc/passwd file. + +The smbpasswd Command. +---------------------- + + The smbpasswd command maintains the 32 byte password field in +the smbpasswd file. If you wish to make it similar to the unix passwd +or yppasswd programs, install it in /usr/local/samba/bin (or your main +Samba binary directory) and make it setuid root. + +Note that if you do not do this then the root user will have to set all +users passwords. + +To set up smbpasswd as setuid root, change to the Samba binary install +directory and then type (as root) : + +chown root smbpasswd +chmod 4555 smbpasswd + +If smbpasswd is installed as setuid root then you would use it as +follows. + +smbpasswd +Old SMB password: +New SMB Password: < type new value > +Repeat New SMB Password: < re-type new value > + +If the old value does not match the current value stored for that user, +or the two new values do not match each other, then the password will +not be changed. + +If invoked by an ordinary user it will only allow the user to change +his or her own Samba password. + +If run by the root user smbpasswd may take an optional argument, +specifying the user name whose SMB password you wish to change. Note +that when run as root smbpasswd does not prompt for or check the old +password value, thus allowing root to set passwords for users who have +forgotten their passwords. + +smbpasswd is designed to work in the same way and be familiar to UNIX +users who use the passwd or yppasswd commands. + +NOTE. As smbpasswd is designed to be installed as setuid root I would +appreciate it if everyone examined the source code to look for +potential security flaws. A setuid program, if not written properly can +be an open door to a system cracker. Please help make this program +secure by reporting all problems to me (the author, Jeremy Allison). + +My email address is :- + +jra@vantive.com + +Setting up Samba to support LanManager Encryption. +-------------------------------------------------- + +This is a very brief description on how to setup samba to support +password encryption. More complete instructions will probably be added +later. + +1) get and compile the libdes libraries. the source is available from +nimbus.anu.edu.au in pub/tridge/libdes/libdes.tar.92-10-13.gz + +2) enable the encryption stuff in the Samba makefile, making sure you +point it to the libdes library and include file (it needs des.h) +The entries you need to uncomment are the four lines after the comment :- + +# This is for SMB encrypted (lanman) passwords. + +Note that you may have to change the variable DES_BASE to +point at the place where you installed the DES library. + +3) compile and install samba as usual + +4) f your system can't compile the module getsmbpass.c then remove the +-DSMBGETPASS define from the Makefile. + +5) enable encrypted passwords in smb.conf by adding the line +"encrypt passwords = yes" in the [global] section + +6) create the initial smbpasswd password file in the place you +specified in the Makefile. A simple way to do this based on your +existing Makefile (assuming it is in a reasonably standard format) is +like this: + +cat /etc/passwd | mksmbpasswd.sh > /usr/local/samba/private/smbpasswd + +Change ownership of private and smbpasswd to root. + +chown -R root /usr/local/samba/private + +Set the correct permissions on /usr/local/samba/private + +chmod 500 /usr/local/samba/private + +Set the correct permissions on /usr/local/samba/private/smbpasswd + +chmod 600 /usr/local/samba/private/smbpasswd + +note that the mksmbpasswd.sh script is in the samba source directory. + +If this fails then you will find that you will need entries that look +like this: + +# SMB password file. +tridge:148:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:Andrew Tridgell:/home/tridge:/bin/tcsh + +note that the uid and username fields must be right. Also, you must get +the number of X's right (there should be 32). + +If you wish, install the smbpasswd program as suid root. + +chown root /usr/local/samba/bin/smbpasswd +chmod 4555 /usr/local/samba/bin/smbpasswd + +7) set the passwords for users using the smbpasswd command. For +example, as root you could do "smbpasswd tridge" + +8) try it out! + +Note that you can test things using smbclient, as it also now supports +encryption. + +NOTE TO USA Sites that Mirror Samba +----------------------------------- + +The DES library is considered a munition in the USA. Under US Law it is +illegal to export this software, or to put it in a freely available ftp +site. + +Please do not mirror the DES directory from the site on nimbus.anu.edu.au + +Thank you, + +Jeremy Allison. + diff --git a/docs/textdocs/HINTS.txt b/docs/textdocs/HINTS.txt new file mode 100644 index 0000000000..953650bdd3 --- /dev/null +++ b/docs/textdocs/HINTS.txt @@ -0,0 +1,202 @@ +Here are some random hints that you may find useful. These really +should be incorporated in the main docs someday. + + +---------------------- +HINT: Always test your smb.conf with testparm before using it + +If your smb.conf file is invalid then samba will fail to load. Run +testparm over it before you install it just to make sure there aren't +any basic syntax or logical errors. + + +---------------------- +HINT: Try printing with smbclient first + +If you have problems printing, test with smbclient first. Just connect using +"smbclient '\\server\printer' -P" and use the "print" command. + +Once this works, you know that Samba is setup correctly for printing, +and you should be able to get it to work from your PCs. + +This particularly helps in getting the "print command" right. + + +---------------------- +HINT: Mount cdroms with conv=binary + +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. + +To overcome this problem use conv=binary when mounting the cdrom +before exporting it with Samba. + + +---------------------- +HINT: Convert between unix and dos text formats + +Jim barry has written an excellent drag-and-drop cr/lf converter for +windows. Just drag your file onto the icon and it converts the file. + +Get it from +ftp://nimbus.anu.edu.au/pub/tridge/samba/contributed/fixcrlf.zip + +---------------------- +HINT: Use the "username map" option + +If the usernames used on your PCs don't match those used on the unix +server then you will find the "username map" option useful. + +----------------------- +HINT: Use "security = user" in [global] + +If you have the same usernames on the unix box and the PCs or have +mapped them with the "username map" option then choose "security = +user" in the [global] section of smb.conf. + +This will mean your password is checked only when you first connect, +and subsequent connections to printers, disks etc will go more +smoothly and much faster. + +The main problem with "security = user" if you use WfWg is that you +will ONLY be able to connect as the username that you log into WfWg +with. This is because WfWg silently ignores the password field in the +connect drive dialog box if the server is in user security mode. + +------------------------ +HINT: Make your printers not "guest ok" + +If your printers are not "guest ok" and you are using "security = +user" and have matching unix and PC usernames then you will attach to +the printer without trouble as your own username. This will mean you +will be able to delete print jobs (in 1.8.06 and above) and printer +accounting will be possible. + + +----------------------- +HINT: Use a sensible "guest" account + +Even if all your services are not available to "guest" you will need a +guest account. This is because the browsing is done as guest. In many +cases setting "guest account = ftp" will do the trick. Using the +default guest account or "guest account = nobody" will give problems on +many unixes. If in doubt create another account with minimal +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 + +Here are some notes on running MS-Access on a Samba drive from Stefan +Kjellberg + +1. Opening a database in 'exclusive' mode does NOT work. Samba ignores + r/w/share modes on file open. + +2. Make sure that you open the database as 'shared' and to 'lock modified + 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/INSTALL.sambatar b/docs/textdocs/INSTALL.sambatar new file mode 100644 index 0000000000..388e2a3eb6 --- /dev/null +++ b/docs/textdocs/INSTALL.sambatar @@ -0,0 +1,27 @@ + +Please see the readme and the man page for general info. + +1) Follow the samba installation instructions. + +2) If all goes well, test it out by creating a share on your PC (called +backup for example) then doing something like, + + ./smbtar -s mypc -t /dev/rmt/0ubn -x backup + +substituting whatever your tape drive is for the -t option, or set your +tape environmental variable. + +If all does not go well, feel free to mail the author (poultenr@logica.co.uk) +about bug reports / help / money / pizza / etc. + +3) Read the man page and the NOTES file for more information + +4) Work smbtar into your usual nightly backup scheme (presuming you +have one :-}). + + +NOTE: + +If you have problems with smbtar then it's probably best to contact the +author Ricky Poulten (poultenr@logica.co.uk). + diff --git a/docs/textdocs/PROJECTS b/docs/textdocs/PROJECTS new file mode 100644 index 0000000000..cf903f2c6d --- /dev/null +++ b/docs/textdocs/PROJECTS @@ -0,0 +1,96 @@ + Samba Projects Directory + ======================== + + +>>>>> NOTE: THIS FILE IS NOW VERY OUT OF DATE <<<<< + + +This is a list of who's working on what in Samba. It's not guaranteed +to be uptodate or accurate but I hope it will help us getting +coordinated. + +If you are working on something to do with Samba and you aren't here +then please let me know! Also, if you are listed below and you have +any corrections or updates then please let me know. + +Email contact: +samba-bugs@anu.edu.au + +======================================================================== +Documentation and FAQ + +Docs and FAQ files for the Samba suite of software. + +Contact Karl.Auer@anu.edu.au + +Mark Preston is now working on a set of formatted docs for Samba. +Contact mpreston@sghms.ac.uk + +Docs are currently up to date with version, 1.7.07. FAQ being added to +as questions arise. + +Status last updated 27th September 1994 +======================================================================== + +======================================================================== +Netbeui support + +This aims to produce patches so that Samba can be used with clients +that do not have TCP/IP. It will try to remain as portable as possible. + +Contact Brian.Onn@Canada.Sun.COM (Brian Onn) + +The project is just startup up. + +Status last updated 4th October 1994 +======================================================================== + +======================================================================== +Smbfs + +A mountable smb filesystem for Linux using the userfs userspace filesystem + +Contact lendecke@namu01.gwdg.de (Volker Lendecke) + +Currently this is at version 0.2. It works but is really only for +people with some knowledge and experience of Linux kernel hacking. + +Status last updated 23rd August 1994 +======================================================================== + +======================================================================== +Nmbd + +Aims to produce a complete rfc1001/1002 implementation. The current +nmbd is a partial implementation. + +Contact Fabrice Cetre (cetre@ifhpserv.insa-lyon.fr) + +Status last updated 23rd August 1994 +======================================================================== + +======================================================================== +Admin Tool + +Aims to produce a nice smb.conf editor and other useful tools for +administering a Samba system. + +Contact: Steve Brown (steve@unicorn.dungeon.com) + +In the design phase. + +Status last updated 4th September 1994 +======================================================================== + + +======================================================================== +Lanman Client. + +Contact: john@amanda.xs4all.nl (John Stewart) + +Aims to produce a reliable LANMAN Client implementation for LINUX, +and possibly other variations of UNIX. Project ably started by +Tor Lillqvist; tml@hemuli.tte.vtt.fi + +Status last updated 17th January 1995 +======================================================================== diff --git a/docs/textdocs/Passwords.txt b/docs/textdocs/Passwords.txt new file mode 100644 index 0000000000..e06876feca --- /dev/null +++ b/docs/textdocs/Passwords.txt @@ -0,0 +1,42 @@ +NOTE ABOUT PASSWORDS +==================== + +Unix systems use a wide variety of methods for checking the validity +of a password. This is primarily controlled with the Makefile defines +mentioned in the Makefile. + +Also note that some clients (notably WfWg) uppercase the password +before sending it. The server tries the password as it receives it and +also after lowercasing it. + +The Samba server can also be configured to try different +upper/lowercase combinations. This is controlled by the [global] +parameter "password level". A level of N means to try all combinations +up to N uppercase characters in the password. A high value can chew a +fair bit of CPU time and can lower the security of your system. Do not +use this options unless you really need it - the time taken for +password checking can become so high that clients time out. + +If you do use the "password level" option then you might like to use +-DUFC_CRYPT in your Makefile. On some machine this makes password +checking _much_ faster. This is also useful if you use the @group +syntax in the user= option. + +If your site uses AFS (the Andrew File System), you can use the AFS section +in the Makefile. This will first attempt to authenticate a username and +password to AFS. If that succeeds, then the associated AFS rights will be +granted. Otherwise, the password checking routine falls back to whatever +Unix password checking method you are using. Note that the AFS code is +only written and tested for AFS 3.3 and later. + + +SECURITY = SERVER +================= + +Samba can use a remote server to do it's username/password +validation. This allows you to have one central machine (for example a +NT box) control the passwords for the Unix box. + +See the section on "security =" in smb.conf(5) for details. + + diff --git a/docs/textdocs/README.DCEDFS b/docs/textdocs/README.DCEDFS new file mode 100644 index 0000000000..f84b84bb68 --- /dev/null +++ b/docs/textdocs/README.DCEDFS @@ -0,0 +1,79 @@ +============================================================================= + + Basic DCE/DFS Support for SAMBA 1.9.13 + + Jim Doyle 06-02-95 + +============================================================================= + +Functionality: +-------------- + + Per-instance authentication for DCE/DFS. + +Missing Functionality in this Implementation: +--------------------------------------------- + + * No automatic refresh of credentials + + To do so would not be that hard.. One could simply + stash the clear-text key in memory, spawn a key management + thread to wake up right before credentials expire and + refresh the login context. + + * No UNIX Signals support (SIGCLD, SIGPIPE, SIGHUP, SIGBUS, SIGSEGV) + + + There is no support for signal processing in Samba daemons + that need to authenticate with DCE. The explanation for this + is that the smbd is linked against thread-safe libraries in + order to be able to use DCE authentication mechanisms. + Because smbd uses signal() and fork(), it represents the + worst case scenario for DCE portability. In order + to properly support signals in a forked server environment, + some rework of smbd is needed in order to properly + construct, shutdown and reconstruct asynchronous signal + handling threads and synchronous signal traps across the + parent and child. I have not had contiguous time to work + on it, I expect it to be a weeks worth of work to cleanly + integrate thread-safe signal handing into the code and + test it. Until I can get to this task, I will leave it up + to someone adventurous enough to engineer it and negotiate + with Andrew to integrate the changes into the mainline branch. + + The lack of full signal support means that you cannot + rely upon SIGHUP-ing the parent daemon to refresh + the configuration data. Likewise, you cannot take advantage + of the builtin SIGBUS/SIGSEGV traps to diagnose failures. + You will have to halt Samba in order to make changes + and then have them take effect. + + The SMBD server as it stands is suitable to use if you + already have experience with configuring and running + SAMBA. + +Tested Platforms: +----------------- + + HP-UX 9.05 / HP-UX DCE 1.2.1 + AIX 3.2.5 / AIX DCE/6000 1.3 + DEC OSF-1 3.0 / DEC DCE 1.3 + +Building: +--------- + + - Uncomment the the appropriate block in the Makefile + for the platform you wish to build on. + + - Samples of Samba server configuration files for our + DFS environment are included in samples.dcedfs/ + + + +Bugs, Suggestions, etc.. +-------------------------- + + Please post them to the mailing list. + That way I will see them and they will become part of + the archives so others can share the knowledge. + diff --git a/docs/textdocs/README.jis b/docs/textdocs/README.jis new file mode 100644 index 0000000000..2ac6716a6f --- /dev/null +++ b/docs/textdocs/README.jis @@ -0,0 +1,124 @@ +● samba 日本語対応について + +1. 目的 + + 日本語対応は、 + + (1) MS-Windows 上で、漢字ファイル名をどうしても扱う必要のあるアプリケーションがちゃ + んと動作する。例えば、MS-WORD 5 などは、インストール時に漢字のファイル名を勝手 + につけてしまいます。こういった場合にちゃんと対応できるようにする。 + + (2) UNIX は、最近ではほとんどのものが 8 bits のファイル名をサポートしていますが、 + 中には、これをサポートしていないものもあります。このような場合でも、(1)の目的 + が満足できるようにする。 + + を目的としています。そのため、日本語対応は、必要最小限しか行なっておりません。 + +2. 利用方法 + +(1) 追加したパラメータ + + smb.conf ファイルの global セクションに以下のパラメータを設定できるようにしました。 + + [global] + .... + coding system = <コード系> + + ここで指定されたコード系が UNIX 上のファイルシステムのファイル名のコードになります。 + 設定できるものは、次のようになっています。 + + sjis: SHIFT JIS (MS 漢字コード) + euc: EUC コード + hex: 7 bits の ASCII コード以外のコードを以下の形式で表す方式です。例えば、 + 'オフィス' という名前は、':83:49:83:74:83:42:83:58' のように、':' の後に２桁 + の16進数を続ける形式になります。 + ここで、':' を他の文字に変更したい場合は、hex の後ろにその文字を指定します。 + 例えば、@を変わりに使いたい場合は、'hex@'のように指定します。 + JIS コードについては、以下の表を参照して下さい。 + ┌───┬────┬────┬────┬────┬────┬─────────┐ + │指定 │漢字開始│漢字終了│カナ開始│カナ終了│英数開始│備考 │ + ├───┼────┼────┼────┼────┼────┼─────────┤ + │jis7 │\E$B │\E(J │0x0e │0x0f │\E(J │jis 7単位符号 │ + │junet │\E$B │\E(J │\E(I │\E(J │\E(J │7bits コード │ + │jis8 │\E$B │\E(J │-- │-- │\E(J │jis 8単位符号 │ + │j7bb │\E$B │\E(B │0x0e │0x0f │\E(B │ │ + │j7bj │\E$B │\E(J │0x0e │0x0f │\E(J │jis7と同じ │ + │j7bh │\E$B │\E(H │0x0e │0x0f │\E(H │ │ + │j7@b │\E$@ │\E(B │0x0e │0x0f │\E(B │ │ + │j7@j │\E$@ │\E(J │0x0e │0x0f │\E(J │ │ + │j7@h │\E$@ │\E(H │0x0e │0x0f │\E(H │ │ + │j8bb │\E$B │\E(B │-- │-- │\E(B │ │ + │j8bj │\E$B │\E(J │-- │-- │\E(J │jis8と同じ │ + │j8bh │\E$B │\E(H │-- │-- │\E(H │ │ + │j8@b │\E@@ │\E(B │-- │-- │\E(B │ │ + │j8@j │\E$@ │\E(J │-- │-- │\E(J │ │ + │j8@h │\E$@ │\E(H │-- │-- │\E(H │ │ + │jubb │\E$B │\E(B │\E(I │\E(B │\E(B │ │ + │jubj │\E$B │\E(J │\E(I │\E(J │\E(J │junetと同じ │ + │jubh │\E$B │\E(H │\E(I │\E(H │\E(H │ │ + │ju@b │\E$@ │\E(B │\E(I │\E(B │\E(B │ │ + │ju@j │\E$@ │\E(J │\E(I │\E(J │\E(J │ │ + │ju@h │\E$@ │\E(H │\E(I │\E(H │\E(H │ │ + └───┴────┴────┴────┴────┴────┴─────────┘ + + いずれの場合も、すでに存在している名前に対しては、漢字の開始終了シーケンスは、以下 + のものを認識します。 + 漢字の始まり: \E$B か \E$@ + 漢字の終り: \E(J か \E(B か \E(H + +(2) smbclient のオプション + + クライアントプログラムでも、漢字や仮名を含んだファイルを扱えるように、次のオプション + を追加しました。 + + -t <ターミナルコード系> + + ここで、<ターミナルコード系>に指定できるものは、上の<コード系>と同じものです。 + +(3) デフォルト + + デフォルトのコード系は、コンパイル時に決まります。 + +3. コンパイル時の設定 + + Makefile に設定する項目を以下に示します。 + +(1) KANJI フラグ + + コンパイルオプションに -DKANJI=\"コード系\" を指定します。このコード系は 2. で指 + 定するものと同じです。例えば、-DKANJI=\"euc\" をFLAGSM に設定すると UNIX 上のファ + イル名は、EUC コードになります。ここで指定したコード系は、サーバ及びクライアント + プログラムのデフォルトに値なります。 + +3. 制限事項 + +(1) 漢字コード + smbd を動作させるホストの UNIX がサポートしていない漢字コードは、利用できないことが + あります。変な動作をするようなら hex の指定をするのが良いでしょう。 + +(2) smbclient コマンド + シフトコードなどの関係で、漢字や仮名を含んだファイル名の ls の表示が乱れることがあり + ます。 + +(3) ワイルドカードについて + ちゃんとしたスペックがよくわからなかったのですが、一応、DOS/V の動作と同じ動作を行な + うようになっています。 + +4. 障害等のレポートについて + + 日本語のファイル名に関して、文字化け等の障害があれば、私にレポートして頂ければ幸いで +す。ただし、オリジナルからの問題点や質問については、オリジナルの作者へ直接問い合わせる +か、もしくはメーリングリストなどへレポートするようにして下さい。 + +5. その他 + + hex 形式の変換方法は、 + + 大木＠大塚・筑波 氏 + + が作られたコードを利用しています。 + +1994年10月28日 第１版 +1995年 8月16日 第２版 +藤田 崇 fujita@ainix.isac.co.jp + diff --git a/docs/textdocs/README.sambatar b/docs/textdocs/README.sambatar new file mode 100644 index 0000000000..26829952eb --- /dev/null +++ b/docs/textdocs/README.sambatar @@ -0,0 +1,15 @@ + +This is version 1.4 of my small extension to samba that allows PC shares +to be backed up directly to a UNIX tape. It only has been tested under +Solaris 2.3, Linux 1.1.59 and DG/UX 5.4r3.10 with version 1.9.13 of samba. + +See the file INSTALL for installation instructions, and +the man page and NOTES file for some basic usage. Please let me know if you +have any problems getting it to work under your flavour of Unix. + +This is only (yet another) intermediate version of sambatar. +This version also comes with an extra gift, zen.bas, written in +microsoft qbasic by a colleague. It is (apparently) based on a 70s +British sci-fi series known as Blake's 7. If you have any questions +about this program, or any suggestions (e.g. what about servillan.bas +?), feel free to mail the author (of zen.bas) greenm@lilhd.logica.com. diff --git a/docs/textdocs/SCO.txt b/docs/textdocs/SCO.txt new file mode 100644 index 0000000000..1b3801471f --- /dev/null +++ b/docs/textdocs/SCO.txt @@ -0,0 +1,12 @@ +There is an annoying TCPIP bug in SCO Unix. This causes orruption when +transferring files with Samba. + +Geza Makay (makayg@math.u-szeged.hu) sends this information: + +The patch you need is UOD385 Connection Drivers SLS. It is available from +SCO (ftp.sco.com, directory SLS, files uod385a.Z and uod385a.ltr.Z). + +You do not need anything else but the above patch. It installs in seconds, +and corrected the Excel problem. We also had some other minor problems (not +only with Samba) that disappeared by installing this patch. + diff --git a/docs/textdocs/SMBTAR.notes b/docs/textdocs/SMBTAR.notes new file mode 100644 index 0000000000..a23cbf2b32 --- /dev/null +++ b/docs/textdocs/SMBTAR.notes @@ -0,0 +1,40 @@ + +Intro +----- + +sambatar is just a small extension to the smbclient program distributed with +samba. A basic front end shell script, smbtar, is provided as an interface +to the smbclient extensions. + +Extensions +---------- + +This release adds the following extensions to smbclient, + +tar [c|x] filename + creates or restores from a tar file. The tar file may be a tape +or a unix tar file. tar's behaviour is modified with the newer and tarmode +commands. + +tarmode [full|inc|reset|noreset] + With no arguments, tarmode prints the current tar mode (by default full, +noreset). In full mode, every file is backed up during a tar command. +In incremental, only files with the dos archive bit set are backed up. +The archive bit is reset if in reset mode, or left untouched if in noreset. +In reset mode, the share has to be writable, which makes sambatar even +less secure. An alternative might be to use tarmode inc noreset which +would implement an "expanding incremental" backup (which some may prefer +anyway). + +setmode filename + This is a "freebie" - nothing really to do with sambatar. This +is a crude attrib like command (only the other way around). Setmode string +is a combination of +-rhsa. So for example -rh would reset the read only +bit on filename. + +newer filename + This is in fact part of the 1.9.13 samba distribution, but comes +into its own with sambatar. This causes tar (or get, mget, etc) to +only copy files newer than the specified file name. Could be used +against the previous nights (or whatever) log file to implement incremental +backups. \ No newline at end of file diff --git a/docs/textdocs/Speed.txt b/docs/textdocs/Speed.txt new file mode 100644 index 0000000000..5dfd70323b --- /dev/null +++ b/docs/textdocs/Speed.txt @@ -0,0 +1,272 @@ +This file tries to outline the ways to improve the speed of a Samba server. + +Andrew Tridgell +January 1995 + + +COMPARISONS +----------- + +The Samba server uses TCP to talk to the client. Thus if you are +trying to see if it performs well you should really compare it to +programs that use the same protocol. The most readily available +programs for file transfer that use TCP are ftp or another TCP based +SMB server. + +If you want to test against something like a NT or WfWg server then +you will have to disable all but TCP on either the client or +server. Otherwise you may well be using a totally different protocol +(such as Netbeui) and comparisons may not be valid. + +Generally you should find that Samba performs similarly to ftp at raw +transfer speed. It should perform quite a bit faster than NFS, +although this very much depends on your system. + +Several people have done comparisons between Samba and Novell, NFS or +WinNT. In some cases Samba performed the best, in others the worst. I +suspect the biggest factor is not Samba vs some other system but the +hardware and drivers used on the various systems. Given similar +hardware Samba should certainly be competitive in speed with other +systems. + + +SOCKET OPTIONS +-------------- + +There are a number of socket options that can greatly affect the +performance of a TCP based server like Samba. + +The socket options that Samba uses are settable both on the command +line with the -O option, or in the smb.conf file. + +The "socket options" section of the smb.conf manual page describes how +to set these and gives recommendations. + +Getting the socket options right can make a big difference to your +performance, but getting them wrong can degrade it by just as +much. The correct settings are very dependent on your local network. + +The socket option TCP_NODELAY is the one that seems to make the +biggest single difference for most networks. Many people report that +adding "socket options = TCP_NODELAY" doubles the read performance of +a Samba drive. The best explanation I have seen for this is that the +Microsoft TCP/IP stack is slow in sending tcp ACKs. + + +READ SIZE +--------- + +The option "read size" affects the overlap of disk reads/writes with +network reads/writes. If the amount of data being transferred in +several of the SMB commands (currently SMBwrite, SMBwriteX and +SMBreadbraw) is larger than this value then the server begins writing +the data before it has received the whole packet from the network, or +in the case of SMBreadbraw, it begins writing to the network before +all the data has been read from disk. + +This overlapping works best when the speeds of disk and network access +are similar, having very little effect when the speed of one is much +greater than the other. + +The default value is 16384, but very little experimentation has been +done yet to determine the optimal value, and it is likely that the best +value will vary greatly between systems anyway. A value over 65536 is +pointless and will cause you to allocate memory unnecessarily. + + +MAX XMIT +-------- + +At startup the client and server negotiate a "maximum transmit" size, +which limits the size of nearly all SMB commands. You can set the +maximum size that Samba will negotiate using the "max xmit = " option +in smb.conf. + +It defaults to 65536 bytes (the maximum), but it is possible that some +clients may perform better with a smaller transmit unit. Trying values +of less than 2048 is likely to cause severe problems. + +In most cases the default is the best option. + + +LOCKING +------- + +By default Samba does not implement strict locking on each read/write +call (although it did in previous versions). If you enable strict +locking (using "strict locking = yes") then you may find that you +suffer a severe performance hit on some systems. + +The performance hit will probably be greater on NFS mounted +filesystems, but could be quite high even on local disks. + + +SHARE MODES +----------- + +Some people find that opening files is very slow. This is often +because of the "share modes" code needed to fully implement the dos +share modes stuff. You can disable this code using "share modes = +no". This will gain you a lot in opening and closing files but will +mean that (in some cases) the system won't force a second user of a +file to open the file read-only if the first has it open +read-write. For many applications that do their own locking this +doesn't matter, but for some it may. + +LOG LEVEL +--------- + +If you set the log level (also known as "debug level") higher than 2 +then you may suffer a large drop in performance. This is because the +server flushes the log file after each operation, which can be very +expensive. + + +WIDE LINKS +---------- + +The "wide links" option is now enabled by default, but if you disable +it (for better security) then you may suffer a performance hit in +resolving filenames. The performance loss is lessened if you have +"getwd cache = yes", which is now the default. + + +READ RAW +-------- + +The "read raw" operation is designed to be an optimised, low-latency +file read operation. A server may choose to not support it, +however. and Samba makes support for "read raw" optional, with it +being enabled by default. + +In some cases clients don't handle "read raw" very well and actually +get lower performance using it than they get using the conventional +read operations. + +So you might like to try "read raw = no" and see what happens on your +network. It might lower, raise or not affect your performance. Only +testing can really tell. + + +WRITE RAW +--------- + +The "write raw" operation is designed to be an optimised, low-latency +file write operation. A server may choose to not support it, +however. and Samba makes support for "write raw" optional, with it +being enabled by default. + +Some machines may find "write raw" slower than normal write, in which +case you may wish to change this option. + +READ PREDICTION +--------------- + +Samba can do read prediction on some of the SMB commands. Read +prediction means that Samba reads some extra data on the last file it +read while waiting for the next SMB command to arrive. It can then +respond more quickly when the next read request arrives. + +This is disabled by default. You can enable it by using "read +prediction = yes". + +Note that read prediction is only used on files that were opened read +only. + +Read prediction should particularly help for those silly clients (such +as "Write" under NT) which do lots of very small reads on a file. + +Samba will not read ahead more data than the amount specified in the +"read size" option. It always reads ahead on 1k block boundaries. + + +MEMORY MAPPING +-------------- + +Samba supports reading files via memory mapping them. One some +machines this can give a large boost to performance, on others it +makes not difference at all, and on some it may reduce performance. + +To enable you you have to recompile Samba with the -DUSE_MMAP=1 option +on the FLAGS line of the Makefile. + +Note that memory mapping is only used on files opened read only, and +is not used by the "read raw" operation. Thus you may find memory +mapping is more effective if you disable "read raw" using "read raw = +no". + + +SLOW CLIENTS +------------ + +One person has reported that setting the protocol to COREPLUS rather +than LANMAN2 gave a dramatic speed improvement (from 10k/s to 150k/s). + +I suspect that his PC's (386sx16 based) were asking for more data than +they could chew. I suspect a similar speed could be had by setting +"read raw = no" and "max xmit = 2048", instead of changing the +protocol. Lowering the "read size" might also help. + + +SLOW LOGINS +----------- + +Slow logins are almost always due to the password checking time. Using +the lowest practical "password level" will improve things a lot. You +could also enable the "UFC crypt" option in the Makefile. + +CLIENT TUNING +------------- + +Often a speed problem can be traced to the client. The client (for +example Windows for Workgroups) can often be tuned for better TCP +performance. + +See your client docs for details. In particular, I have heard rumours +that the WfWg options TCPWINDOWSIZE and TCPSEGMENTSIZE can have a +large impact on performance. + +Also note that some people have found that setting DefaultRcvWindow in +the [MSTCP] section of the SYSTEM.INI file under WfWg to 3072 gives a +big improvement. I don't know why. + +My own experience wth DefaultRcvWindow is that I get much better +performance with a large value (16384 or larger). Other people have +reported that anything over 3072 slows things down enourmously. One +person even reported a speed drop of a factor of 30 when he went from +3072 to 8192. I don't know why. + +It probably depends a lot on your hardware, and the type of unix box +you have at the other end of the link. + +MY RESULTS +---------- + +Some people want to see real numbers in a document like this, so here +they are. I have a 486sx33 client running WfWg 3.11 with the 3.11b +tcp/ip stack. It has a slow IDE drive and 20Mb of ram. It has a SMC +Elite-16 ISA bus ethernet card. The only WfWg tuning I've done is to +set DefaultRcvWindow in the [MSTCP] section of system.ini to 16384. My +server is a 486dx3-66 running Linux. It also has 20Mb of ram and a SMC +Elite-16 card. You can see my server config in the examples/tridge/ +subdirectory of the distribution. + +I get 490k/s on reading a 8Mb file with copy. +I get 441k/s writing the same file to the samba server. + +Of course, there's a lot more to benchmarks than 2 raw throughput +figures, but it gives you a ballpark figure. + +I've also tested Win95 and WinNT, and found WinNT gave me the best +speed as a samba client. The fastest client of all (for me) is +smbclient running on another linux box. Maybe I'll add those results +here someday ... + + +COMMENTS +-------- + +If you've read this far then please give me some feedback! Which of +the above suggestions worked for you? + +Mail the samba mailing list or samba-bugs@anu.edu.au diff --git a/docs/textdocs/Support.txt b/docs/textdocs/Support.txt new file mode 100644 index 0000000000..d71bdaf7b3 --- /dev/null +++ b/docs/textdocs/Support.txt @@ -0,0 +1,376 @@ +The Samba Consultants List +========================== + +This is a list of people who are prepared to install and support Samba. +Note that in most countries nobody should admit to "supplying" Samba, since +there is then an implied warranty with possibly onerous legal obligations. +Just downloading and installing it isn't supply in this sense, but advertising +"run our Samba for best results" may be so. + +Being on this list does not imply any sort of endorsement by anyone, it is just +provided in the hope that it will be useful. + +If you want to be added to the list, or want your entry modified then +contact the address below. They are currently listed in the +order that they were received. If it gets too big we may organise it +by region. Please make sure to include a header line giving the region +and country, eg CANBERRA - AUSTRALIA. + +You can contact the maintainers at samba-bugs@anu.edu.au + + +------------------------------------------------------------------------------ +BRISBANE - AUSTRALIA + +Brett Worth +Select Computer Technology - Brisbane +431 Logan Road +Stones Corner QLD 4120 +E-Mail: brett@sct.com.au +------------------------------------------------------------------------------ + +------------------------------------------------------------------------------ +CANBERRA - AUSTRALIA + +Paul Blackman (ictinus@lake.canberra.edu.au, Ph. 06 2012518) is +available for consultation. Paul's Samba background is with +Solaris 2.3/4 and WFWG/Win95 machines. Paul is also the maintainer +of the SAMBA Web Pages. +------------------------------------------------------------------------------ + +------------------------------------------------------------------------------ +READING - ENGLAND + +Philip Hands | E-Mail: info@hands.com +Philip Hands Computing Ltd. | Tel: +44 1734 476287 Fax: 1734 474655 +Unit 1, Cherry Close, Caversham, Reading RG4 8UP UK + +Samba experience: SVR4,SVR3.2 & Linux <--> WfWg, W3.1, OS2 and MS-LanMan +------------------------------------------------------------------------------ + +------------------------------------------------------------------------------ +ILLONOIS - USA + +Information One, Inc. +736 Hinman Ave, Suite 2W +Evanston, IL 60202 +708-328-9137 708-328-0117 FAX +info@info1.com + +Providing custom Internet and networking solutions. +------------------------------------------------------------------------------ + +------------------------------------------------------------------------------ +Olympic Peninsula Consulting; 1241 Lansing Ave W., Bremerton, WA 98312-4343 +telephone 1+ 360 792 6938; mailto:opc@aa.net; http://www.aa.net/~opc; +Unix Systems and TCP/IP Network design, programming, and administration. +------------------------------------------------------------------------------ + +------------------------------------------------------------------------------ +SolutionS R Us has been in business for 3+ years providing viable 3rd +party support in system/network administration. With our own Linux +distribution which we're constantly improving to make it the best and +using it to provide total solutions for companies which are open to +using Linux. + +Mauro DePalma +------------------------------------------------------------------------------ + +------------------------------------------------------------------------------ +BIELEFELD - GERMANY + +I am located in Bielefeld/Germany and have been doing Unix consultancy +work for the past 8 years throughout Germany and the rest of Europe. I +can be contacted by email at or via phone at +49 521 +9225922 or telefax at +49 521 9225924. +------------------------------------------------------------------------------ + +------------------------------------------------------------------------------ +CANBERRA - AUSTRALIA + +Ben Elliston +Faculty of Information Sciences and Engineering +University of Canberra AUSTRALIA +E-mail: ben@ise.canberra.edu.au (Uni) +------------------------------------------------------------------------------ + +------------------------------------------------------------------------------ +PALERMO - ITALY + +Francesco Cardinale +E-Mail: cardinal@palermo.italtel.it +Samba experience: SVR3.2, SOLARIS, ULTRIX, LINUX <--> DOS LAN-MAN, WFW +------------------------------------------------------------------------------ + +------------------------------------------------------------------------------ +SYDNEY - AUSTRALIA + +John Terpstra - Aquasoft (jht@aquasoft.com.au) +Business: +612 524 4040 +Home: +612 540 3154 +Shoephone: +612 414 334422 (aka 0414 334422) +------------------------------------------------------------------------------ + +------------------------------------------------------------------------------ +ONTARIO - CANADA + +Strata Software Limited, Kanata Ontario CANADA +Tel: +1 (613) 591-1922 Fax: +1 (613) 591-3485 +Email: sales@strataware.com WWW: http://www.strataware.com/ + +Strata Software Limited is a software development and consulting group +specializing in data communications (TCP/IP and OSI), X.400, X.500 and +LDAP, and X.509-based security. We have Samba experience with Windows NT, +Windows 95, and Windows for Workgroups clients with Linux, Unixware +(SVR4), and HP-UX servers. +------------------------------------------------------------------------------ + +----------------------------------------------------------------------- +SYDNEY - AUSTRALIA + +We are a Unix & Windows developer with a consulting & support component. +In business since 1981 with experience on Sun, hp, sgi, IBM rs6000 plus +Windows, NT and Win95, Using Samba since September 94. +CodeSmiths, 22 Darley Road, MANLY 2095 NSW; 977 1979; fax: 977 2116 +philm@esi.com.au (Australia; New South Wales; SYDNEY; North East) +----------------------------------------------------------------------- + +------------------------------------------------------------------------------ +EDINBUGH - SCOTLAND + +Charlie Hussey email charlie@edina.demon.co.uk +Edina Software Limited tel 0131 657 1129 +4 James Street fax 0131 669 9092 +Edinburgh EH15 2DS + +SAMBA experience: SCO UNIX <=> WfWg +------------------------------------------------------------------------------ + +------------------------------------------------------------------------------ +LONDON - ENGLAND + +Mark H. Preston, +Network Analyst, | Email : mpreston@sghms.ac.uk +Computer Unit, | Tel : +44 (0)181 725-5434 +St. George's Hospital Med School, | Fax : +44 (0)181 725-3583 +London SW17 ORE. | WWW : http://www.sghms.ac.uk + +Samba Experience: +Server: Solaris 2.3 & 2.4, Irix 5.2 & 5.3 +Client: WinNT, Win95, WfWg, Win3.1, Ms-LanMan, DHCP support +------------------------------------------------------------------------------ + +------------------------------------------------------------------------------ +SYDNEY - AUSTRALIA + +Pacific ESI has used and installed Samba since 1.6 on a range +of machines running SunOS, BSD/OS, SCO/UNIX, HP/UX, and Solaris, +and WfWG and Windows95. The largest system worked on to date +involved an Australia wide network of machines with PCs and SUNs +at the various nodes. The in-house testing site is a wide area +network with three sites, remotely connected with PPP and with +SUN servers at each site to all of which are connected several +PCs running mainly WfWG. + +Stefan Kjellberg Pacific Engineering Systems +International +info@eram.esi.com.au Voice:+61-2-9063377 +... Fax:+61-2-9063468 +------------------------------------------------------------------------------ + +------------------------------------------------------------------------------ +CHANTILLY - USA + +Intelligent Decisions, Inc. +ATTN: Richard Bullington +14121 Parke Long Ct. #104 +Chantilly, VA 22021 +U.S.A. +(703) 803-8070 +rbullington@intdec.com + +Samba experience: Linux, DEC ULTRIX <=> WFWG 3.11, Windows NT 3.5 +Specializing in World Wide Web related UNIX-to-PC connectivity. +------------------------------------------------------------------------------ + +------------------------------------------------------------------------------ +FORT COLLINS, CO - USA + +Granite Computing Solutions +ATTN: Brian Grossman +Box 270103 +Fort Collins, CO 80527-0103 +U.S.A. +(970) 225-2370 +granite@fortnet.org + +Information services, including WfWG, NT, Apple <=> Unix interoperability. + +Our standard advertisement says: + +> Unix workstations, servers and custom systems < +>> WWW and Unix education << +>>> Enterprise and departmental computing solutions <<< +>>> Backup & restore <<< +>> Software forensics << +> Data translation < +------------------------------------------------------------------------------ + +---------------------------------------------------------- +Adelaide, Australia + +NS Computer Software and Services P/L +PO Box 86 +Ingle Farm +SA 5098 + +Contact: Richard Sharpe + Ph: +61-8-281-0063 (08-281-0063) AH + FAX:+61-8-250-2080 (08-250-2080) + +Experience with: ULTRIX, Digital UNIX, SunOS, WfW 3.11, Win95, WNT 3.51 + +---------------------------------------------------------- + +---------------------------------------------------------- +TECTONIC LIMITED +WESTWOOD +78 LOUGHBOROUGH ROAD +QUORN +LEICESTERSHIRE +LE12 8DX + +TELEPHONE 01509-620922 +FAX 01509-620933 + +CONTACT DAVID ROBINSON + +WE ARE UNIX ORIENTATED BUT ALSO SPECIALISE IN PC TO UNIX COMMUNICATIONS, WE +KNOW AND UNDERSTAND PC-NFS, (HENCE OUR INTEREST IN SAMBA). +WE SUPPORT SUNOS, SOLARIS 1.X AND 2.X, HP-UX 9.0 AND 10.0, OSF (or DEC UNIX, +whichever you prefer), WinNT, WfWG and Win95. + +WE ARE ALREADY TALKING TO A COUPLE OF VERY LARGE SAMBA USERS HERE IN THE UK. +WE WOULD LIKE TO SUPPORT THEM (AND MANY MORE), WOULD YOU PLEASE CONTACT ME ON: +david@tectonic.demon.co.uk +---------------------------------------------------------- + +---------------------------------------------------------- +MIAMI, FL - USA + +Swaney & Associates, Inc. +ATTN: Stephen Swaney + 2543 Lincoln Avenue + Miami, Florida 33133 + U.S.A + (305) 860-0570 + +Specializing in: + High Availability system & networks + UNIX to PC connectivity + Market Data systems + Messaging Systems (Sendmail & Microsoft Exchange) +---------------------------------------------------------- + +------------------------------------------------------------------------------ +NEW JERSEY - USA + +William J. Maggio +LAN & Computer Integrators, Inc. +242 Old New Brunswick Road Email: bmaggio@lci.com +Suite 440 Voice: 908-981-1991 +Piscataway, NJ 08855 Fax : 908-981-1858 + + Specializing in Internet connectivity and security, Sun integration and + high speed, enterprise network design and deployment. +------------------------------------------------------------------------------ + +FAREHAM - ENGLAND + +High Field Technology Ltd +Little Park Farm Road, Segensworth West, +Fareham, Hants PO15 5SJ, UK. +sales@hft.co.uk tel +44 148 957 0111 fax +44 148 957 0555 + +Company skills: Real time hardware and software systems + +Samba experience: BSD/OS, Linux, LynxOS <==> WFWG, NT + +------------------------------------------------------------------------------ + +----------------------------------------------------------------------- +QUEBEC - CANADA + +Dataden Computer Systems +Attn: Danny Arseneau +arseneau@parkmed.com +895 2nd Avenue +Ile Bizard, Quebec +Canada, H9C 1K3 +Tel: (514)891-2293 +Fax: (514)696-0848 + +Dataden is company that specializes in Unix--TCP/IP networking. +We have over 15 years of experience. We have been installing, +configuring and maintaining Samba for clients for 1-1/2 years now. We +have samba installations on Linx, SunOS and DEC OSF. Our biggest site +has 4 Suns and 3 Linux servers running Samba which are serving a network +of about 50 PC's running WFWg and Win95. +----------------------------------------------------------------------- + +----------------------------------------------------------------------- +CALIFORNIA - USA + +Ron Halstead +Open Systems Consulting +3098-4 Lakemont Drive +San Ramon, CA 94583 (San Francisco Bay Area) +(510) 735-7529 +halstead@ix.netcom.com +----------------------------------------------------------------------- + + +----------------------------------------------------------------------- +MELBOURNE - AUSTRALIA + +Michael Ciavarella +Cybersoruce Pty Ltd. +8/140 Queen Street +Melbourne VIC 3000 +Phone: +61-3-9642-5997 +Fax: +61-3-9642-5998 +Email: mikec@cyber.com.au +WWW: http://www.cyber.com.au + +Cybersource specialises in TCP/IP network integration and Open Systems +administration. Cybersource is an Australian-owned and operated +company, with clients including some of Australia's largest financial, +petrochemical and state government organisations. +----------------------------------------------------------------------- + +----------------------------------------------------------------------- +SOUTHERN CALIFORNIA - USA + +Michael St. Laurent +Serving Los Angeles and Orange Counties. Please contact via email. +rowl@earthlink.net +Michael St. Laurent +Hartwell Corporation +------------------------------------------------------------------------------ +WASHINGTON DC METRO - USA + +Asset Software, Inc. has been running Samba since the 1.6 release on various +platforms, including SunOS 4.x, Solaris 2.x, IRIX 4.x and 5.x, Linux 1.1x, +1.2x, and 1.3x, and BSD UNIX 4.3 and above. We specialize in small office +network solutions and provide services to enhance a small office's +operations. Primarily a custom software operation, our vast knowledge of +Windows, DOS, Unix, Windows NT, MacOS, and OS/2 enable us to provide quality +technical assistance to the small office environment at a reasonable price. +Our upcoming multi-mailbox mail client, IQ Mail, enables users with more +than one mailbox to send and retrieve their mail from a single, consistent +mail client running in Windows. + +David J. Fenwick Asset Software, Inc. +President djf@assetsw.com +------------------------------------------------------------------------------ + diff --git a/docs/textdocs/UNIX-SMB.txt b/docs/textdocs/UNIX-SMB.txt new file mode 100644 index 0000000000..b2c064215c --- /dev/null +++ b/docs/textdocs/UNIX-SMB.txt @@ -0,0 +1,220 @@ +This is a short document that describes some of the issues that +confront a SMB implementation on unix, and how Samba copes with +them. They may help people who are looking at unix<->PC +interoperability. + +It was written to help out a person who was writing a paper on unix to +PC connectivity. + +Andrew Tridgell +April 1995 + + +Usernames +========= + +The SMB protocol has only a loose username concept. Early SMB +protocols (such as CORE and COREPLUS) have no username concept at +all. Even in later protocols clients often attempt operations +(particularly printer operations) without first validating a username +on the server. + +Unix security is based around username/password pairs. A unix box +should not allow clients to do any substantive operation without some +sort of validation. + +The problem mostly manifests itself when the unix server is in "share +level" security mode. This is the default mode as the alternative +"user level" security mode usually forces a client to connect to the +server as the same user for each connected share, which is +inconvenient in many sites. + +In "share level" security the client normally gives a username in the +"session setup" protocol, but does not supply an accompanying +password. The client then connects to resources using the "tree +connect" protocol, and supplies a password. The problem is that the +user on the PC types the username and the password in different +contexts, unaware that they need to go together to give access to the +server. The username is normally the one the user typed in when they +"logged onto" the PC (this assumes Windows for Workgroups). The +password is the one they chose when connecting to the disk or printer. + +The user often chooses a totally different username for their login as +for the drive connection. Often they also want to access different +drives as different usernames. The unix server needs some way of +divining the correct username to combine with each password. + +Samba tries to avoid this problem using several methods. These succeed +in the vast majority of cases. The methods include username maps, the +service%user syntax, the saving of session setup usernames for later +validation and the derivation of the username from the service name +(either directly or via the user= option). + +File Ownership +============== + +The commonly used SMB protocols have no way of saying "you can't do +that because you don't own the file". They have, in fact, no concept +of file ownership at all. + +This brings up all sorts of interesting problems. For example, when +you copy a file to a unix drive, and the file is world writeable but +owned by another user the file will transfer correctly but will +receive the wrong date. This is because the utime() call under unix +only succeeds for the owner of the file, or root, even if the file is +world writeable. For security reasons Samba does all file operations +as the validated user, not root, so the utime() fails. This can stuff +up shared development diectories as programs like "make" will not get +file time comparisons right. + +There are several possible solutions to this problem, including +username mapping, and forcing a specific username for particular +shares. + +Passwords +========= + +Many SMB clients uppercase passwords before sending them. I have no +idea why they do this. Interestingly WfWg uppercases the password only +if the server is running a protocol greater than COREPLUS, so +obviously it isn't just the data entry routines that are to blame. + +Unix passwords are case sensitive. So if users use mixed case +passwords they are in trouble. + +Samba can try to cope with this by either using the "password level" +option which causes Samba to try the offered password with up to the +specified number of case changes, or by using the "password server" +option which allows Samba to do it's validation via another machine +(typically a WinNT server). + +Samba also doesn't support the password encryption method used by SMB +clients. This is because the spec isn't sufficiently detailed for an +implementation (although Jeremy Allison is working on it, to try and +work it out). Also, there is a fundamental problem with what we +understand so far in the algorithm, as it seems that the server would +need to store somewhere on disk a reversibly encrypted (effectively +plaintext) copy of the users password in order to use the +algorithm. This goes against the unix policy that "even the super-user +doesn't know your password" which comes from the use of a one-way hash +function. + +Locking +======= + +The locking calls available under a DOS/Windows environment are much +richer than those available in unix. This means a unix server (like +Samba) choosing to use the standard fcntl() based unix locking calls +to implement SMB locking has to improvise a bit. + +One major problem is that dos locks can be in a 32 bit (unsigned) +range. Unix locking calls are 32 bits, but are signed, giving only a 31 +bit range. Unfortunately OLE2 clients use the top bit to select a +locking range used for OLE semaphores. + +To work around this problem Samba compresses the 32 bit range into 31 +bits by appropriate bit shifting. This seems to work but is not +ideal. In a future version a separate SMB lockd may be added to cope +with the problem. + +It also doesn't help that many unix lockd daemons are very buggy and +crash at the slightest provocation. They normally go mostly unused in +a unix environment because few unix programs use byte range +locking. The stress of huge numbers of lock requests from dos/windows +clients can kill the daemon on some systems. + +The second major problem is the "opportunistic locking" requested by +some clients. If a client requests opportunistic locking then it is +asking the server to notify it if anyone else tries to do something on +the same file, at which time the client will say if it is willing to +give up it's lock. Unix has no simple way of implementing +opportunistic locking, and currently Samba has no support for it. + +Deny Modes +========== + +When a SMB client opens a file it asks for a particular "deny mode" to +be placed on the file. These modes (DENY_NONE, DENY_READ, DENY_WRITE, +DENY_ALL, DENY_FCB and DENY_DOS) specify what actions should be +allowed by anyone else who tries to use the file at the same time. If +DENY_READ is placed on the file, for example, then any attempt to open +the file for reading should fail. + +Unix has no equivalent notion. To implement these Samba uses lock +files based on the files inode and placed in a separate lock +directory. These are clumsy and consume processing and file resources, +so they are optional and off by default. + +Trapdoor UIDs +============= + +A SMB session can run with several uids on the one socket. This +happens when a user connects to two shares with different +usernames. To cope with this the unix server needs to switch uids +within the one process. On some unixes (such as SCO) this is not +possible. This means that on those unixes the client is restricted to +a single uid. + +Port numbers +============ + +There is a convention that clients on sockets use high "unprivilaged" +port numbers (>1000) and connect to servers on low "privilaged" port +numbers. This is enforced in Unix as non-root users can't open a +socket for listening on port numbers less than 1000. + +Most PC based SMB clients (such as WfWg and WinNT) don't follow this +convention completely. The main culprit is the netbios nameserving on +udp port 137. Name query requests come from a source port of 137. This +is a problem when you combine it with the common firewalling technique +of not allowing incoming packets on low port numbers. This means that +these clients can't query a netbios nameserver on the other side of a +low port based firewall. + +The problem is more severe with netbios node status queries. I've +found that WfWg, Win95 and WinNT3.5 all respond to netbios node status +queries on port 137 no matter what the source port was in the +request. This works between machines that are both using port 137, but +it means it's not possible for a unix user to do a node status request +to any of these OSes unless they are running as root. The answer comes +back, but it goes to port 137 which the unix user can't listen +on. Interestingly WinNT3.1 got this right - it sends node status +responses back to the source port in the request. + + +Protocol Complexity +=================== + +There are many "protocol levels" in the SMB protocol. It seems that +each time new functionality was added to a Microsoft operating system, +they added the equivalent functions in a new protocol level of the SMB +protocol to "externalise" the new capabilities. + +This means the protocol is very "rich", offering many ways of doing +each file operation. This means SMB servers need to be complex and +large. It also means it is very difficult to make them bug free. It is +not just Samba that suffers from this problem, other servers such as +WinNT don't support every variation of every call and it has almost +certainly been a headache for MS developers to support the myriad of +SMB calls that are available. + +There are about 65 "top level" operations in the SMB protocol (things +like SMBread and SMBwrite). Some of these include hundreds of +sub-functions (SMBtrans has at least 120 sub-functions, like +DosPrintQAdd and NetSessionEnum). All of them take several options +that can change the way they work. Many take dozens of possible +"information levels" that change the structures that need to be +returned. Samba supports all but 2 of the "top level" functions. It +supports only 8 (so far) of the SMBtrans sub-functions. Even NT +doesn't support them all. + +Samba currently supports up to the "NT LM 0.12" protocol, which is the +one preferred by Win95 and WinNT3.5. Luckily this protocol level has a +"capabilities" field which specifies which super-duper new-fangled +options the server suports. This helps to make the implementation of +this protocol level much easier. + +There is also a problem with the SMB specications. SMB is a X/Open +spec, but the X/Open book is far from ideal, and fails to cover many +important issues, leaving much to the imagination. + diff --git a/docs/textdocs/WinNT.txt b/docs/textdocs/WinNT.txt new file mode 100644 index 0000000000..b57abb7742 --- /dev/null +++ b/docs/textdocs/WinNT.txt @@ -0,0 +1,56 @@ +There are some particular issues with Samba and Windows NT + +===================================================================== +One of the most annoying problems with WinNT is that NT refuses to +connect to a server that is in user level security mode and that +doesn't support password encryption unless it first prompts the user +for a password. + +This means even if you have the same password on the NT box and the +Samba server you will get prompted for a password. Entering the +correct password will get you connected. + +The other major ramification of this feature of NT is that it can't +browse a user level non-encrypted server unless it already has a +connection open. This is because there is no spot for a password +prompt in the browser window. It works fine if you already have a +drive mounted (for example, one auto mounted on startup). + +Samba should support encrypted passwords soon, which will solve this +problem. +===================================================================== + + + +===================================================================== +When you mount a printer using the print manager in NT you may find +the following info from Matthew Harrell +useful: + +------------ + I noticed in your change-log you noted that some people were +still unable to use print manager under NT. If this is the same problem +that I encountered, it's caused by the length of time it takes NT to +determine if the printer is ready. + +The problem occurs when you double-click on a printer to connect it to +the NT machine. Because it's unable to determine if the printer is ready +in the short span of time it has, it assumes it isn't and gives some +strange error about not having enough resources (I forget what the error +is). A solution to this that seems to work fine for us is to click +once on the printer, look at the bottom of the window and wait until +it says it's ready, then clilck on "OK". + +By the way, this problem probably occurs in our group because the +Samba server doesn't actually have the printers - it queues them to +remote printers either on other machines or using their own network +cards. Because of this "middle layer", it takes an extra amount of +time for the NT machine to get verification that the printer queue +actually exists. + +I hope this helped in some way... +----------- +===================================================================== + + + -- cgit