Samba Workshop
January 15, 2001
By Tim Orbaker
Introduction
Today's networks are more heterogeneous than ever. Gone are the days when one platform was enough to do all the work that users required. Often, multiple operating systems are required for differing business solutions, and Windows NT and UNIX are almost always among the mix. For administrators given the task of making everything work together, fortunately, there is SAMBA.
SAMBA is an implementation of the Server Message Block (SMB) protocol, which is the heart of Windows Networking. Any computer capable of exchanging SMBs with other computers can participate in a Windows network.
Before We Begin
Before we begin, you will need the following:
- Samba 2.0.7. You can try other versions or precompiled binary packages, but the version used herein is built from this source tarball.
- You will need at least one Windows PC and at least one UNIX system. Which UNIX version you choose shouldn't matter. The examples herein were all tested on SCO Open Server 5.0.5 and RedHat Linux (Kernel version 2.2).
Some Windows Network Basics
Before we get started, a primer on Windows networking is in order for those who aren't familiar with it. If you feel comfortable with Windows network internals, you may skip this section.
Windows networking is based on RPC and NetBIOS. Without these services working in the manner that Windows expects, nothing else will work. All computers that participate in Windows networking have a unique NetBIOS name. Windows networking allows this potentially unmanageable list to be broken down into groups of related computers called workgroups or domains. Windows computer names are not case sensitive and must be less than 14 characters (NOTE: While spaces are allowed in names, some versions of Windows 9x and SAMBA will not be able to use these properly. Try to avoid them.)
Windows uses a computer called a Master Browser to maintain the list of all computers in a workgroup. By default, each time a computer starts, it forces a process called an election to happen. An election attempts to determine who is most fit to handle the maintenance of the browser list. The winner of the election handles the list management. Lots of factors determine who wins the election, including: Newest operating system; which has been up the longest; NT wins over 98, which wins over 95; etc. An election can be an expensive process--in terms of network bandwidth--when there are a lot of computers in a workgroup or domain. In general, we'll try to avoid causing these by telling SAMBA to try never to be the election winner.
In addition to a Master Browser, Windows uses one or more WINS (Windows Internet Name Service) servers to manage the mapping of NetBIOS names to IP addresses. If there is no WINS server on your network, it will still work, but names will be resolved using broadcasts similar to the way ARP resolves Ethernet addresses from IP addresses. Our examples assume that you have a Windows machine running a WINS server that we can use. For performance reasons, all NT networks should always have at least one WINS server.
Windows networking operates in several different security modes. It can operate in the style of Windows for Workgroups (SHARE security), as Windows NT workstation peer workgroups (USER security) or as Windows NT server domains (DOMAIN security). When SHARE security is used, an item is either shared or it is not. There is no differentiation between users when access is determined. It is the easiest to configure and the hardest to secure. USER and DOMAIN security require security databases. Without going into great detail on Windows NT security models, we'll leave this at: DOMAIN security requires only a central user database to manage, whereas USER security can require multiple user databases. Because of the security concerns associated with SHARE security (not to mention that it's far easier to configure), we'll not cover it in this workshop.
The Windows NT DOMAIN security model requires a single PDC (Primary Domain Controller) and zero or more BDCs (Backup Domain Controllers) to authenticate logins, as well as zero or more Member Servers that simply share resources. The PDC stores the master copy of the user database and all changes are made here, while the BDCs can authenticate users when they login but cannot modify the Security and Accounts database. Member servers cannot allow users access to the network, but once a Domain Controller has allowed a user access, he or she can access files on Member Servers.
Compile SAMBA
Download the SAMBA sources if you haven't already. Change to the directory where the tar file is and run:
uncompress samba-2.0.7.tar.gz
tar xf samba-2.0.7.tar
rm -f samba-2.0.7.tar
cd ./samba-2.0.7/source
./configure
make
make install
SAMBA should properly configure itself for your system automatically. This will compile and install the programs under /usr/local/samba. If you would prefer them to be installed under /opt, change:
./configure to
./configure ęprefix=/opt
Of all the systems that I've tried SAMBA on, only Mac OS X (a beta) didn't compile cleanly on the first pass. If you don't wish to compile SAMBA yourself, there are binary distributions for almost every conceivable UNIX under /pub/samba/Binary_Packages, which is available from any SAMBA FTP mirror.
SAMBA as a Server
SAMBA can join your current Windows NT domain as a Member Server. Recall that under Windows NT, a member server does not authenticate logins to the network but allows the PDC and/or BDCs to perform this function. The administrator of the Member Server can then grant access to the users in the rest of the domain. Member Servers are used to add resources (applications, storage, printers, etc) to the network without increasing the number of copies of the Security and Accounts Database.
In order for this setup to work, the Member Server must be able to log in and get account information to compare against user requests for access. This is done with a computer account (yes, computers have accounts in NT, too).
To create a computer account in Windows NT, we'll use the Server Manager.
- Log in as an Administrator, preferably at one of the Domain Controllers. (Users who have installed the 'Windows NT Server Tools' on their workstations can do this remotely.)
- Click 'Start' | 'Programs' | 'Administrative Tools' | 'Server Manager.'
- From the menu bar here, select 'Computer' | 'Add to Domain.'
- Chose 'Windows NT Workstation or Server' as the 'Computer Type.'
- Enter the computer name. We'll be using SAMBA in this article. Any name you choose to use is fine, just be consistent and select carefully.
- Click 'Add' then click 'Cancel' as we won't be adding another name now.
- You should see SAMBA in the list of computers on the network. It will probably be 'grayed out,' which means only that the network can't talk to it right now (since SAMBA isn't running yet, this is not surprising).
The configuration file that we will use to start SAMBA follows. It belongs in /usr/local/samba/lib/smb.conf:
[global]
#
# Set this to your domain name:
workgroup = DOMAIN
#
# This is only a comment; treat it, however, like you would:
server string = Samba Server v2.0.7
#
# The following line, if uncommented, would restrict access
# to the machines on a private class C network:
# hosts allow = 127. 192.168.10.
#
# Maintain a separate log file for each client that
# connects (by computer name). If you want a single
# log file, remove the '.%m' from the end.
log file = /usr/local/samba/var/log.%m
#
# How large can a log get (in kB)?
max log size = 50
#
# Computer Name:
netbios name = SAMBA
#
# Who are the domain controllers? List the PDC, followed
# by all the BDCs, separated by spaces. Alternatively,
# this could be left set as is and SAMBA will determine
# who the Domain Controllers are, like Windows NT does.
password server = *
#
# What type of security are we using?
security = DOMAIN
#
# ALWAYS, ALWAYS encrypt passwords. No clear-text
# passwords should ever even see the light of day.
encrypt passwords = yes
#
# Makes the speed better on some computers. If you have
# trouble, remove this line first:
socket options = TCP_NODELAY
#
# Try to avoid an election by refusing to start one, or
# to ever participate in one.
local master = no
preferred master = no
#
# Who is your WINS server? You should already have a WINS
# server in place (either that or you are wasting too
# much bandwidth on broadcasts).
wins server = 192.168.10.10
#
# If DNS cannot find a name, should WINS try?
dns proxy = no
#================== Share Definitions ===================
# Homes is a special share that shares out the home
# directory for each valid user and also creates a
# share named 'HOMES' that automatically maps to the
# correct home directory for the current user.
[homes]
comment = Home Directories # Commentary only
browseable = yes # Seen in explorer?
writable = yes # Read/Write?
#
# Another share. This one is not magical like HOMES. This
# illustrates how to share something without advertising
# that it is shared. You can still connect to \\SAMBA\LOCAL, but
# you can't browse to find it. This is similar to appending a $ to a Windows
# share name.
[local]
comment = useless # Comment is useless here
browseable = no # Do not show in browser
writeable = no # Allow no changes
path = /usr/local # Share this path
Before we can start SAMBA, we need to join the domain. This entails logging into the domain as the computer account and setting a password that will be used later. Thankfully, SAMBA can do this for us with:
/usr/local/samba/bin/smbpasswd -j DOMAIN -r <PDC>
(Replace <PDC> with the name of your Primary Domain Controller).
Once this configuration file has been created and the domain has been joined, we only one step remains. SAMBA requires each user who will be accessing the computer remotely to have a user ID on the SAMBA server. The reason for this is that when the NT user 'orbaker' connects, SAMBA forks for the connection and sets its user ID to 'orbaker' to create an equivalency. Be certain that you have the same username for both Windows NT and your SAMBA server (NOTE: The passwords need not be identical).
Now, run the commands:
/usr/local/samba/bin/smbd -D
/usr/local/samba/bin/nmbd -D
You should be able to browse your SAMBA server from the Windows explorer interface. When you connect to the server, you should see the shares 'HOMES' and one for your username. Everyone sees his or her home directory and HOMES. The share LOCAL shouldn't be listed here, but if you right-click on 'Network Neighborhood' and select 'Map Network Drive' you should be able to map a drive to '\\SAMBA\LOCAL'.
To experiment a bit more with shares, try some of the following:
- Add the line 'hide dot files = yes' to one of the share definitions. This should make hidden files hidden (if your workstation has the 'Show All Files' option set, you will still see them, although their properties will show that they are hidden).
- Your samba/private directory has some sensitive information in it. Try adding the line: 'veto files = /private/' to the definition for the LOCAL share. This should keep /usr/local/samba/private from being accessed from Windows stations. Try creating the directory: /usr/local/private. This directory should also be inaccessible.
SAMBA as a Client
SAMBA can also be used as a client to make Windows files available to UNIX workstations. The 'smbclient' program can be used to perform functions similar to the 'net' command in Windows. Some examples include the following:
To obtain a list of shares on a specific PC (in this case SERVER1):
/usr/local/samba/bin/smbclient -L SERVER1 -U orbaker \
-W DOMAIN
This should prompt for a password and generate a list similar to the following (for an NT server. Windows 9x machines normally have blank SERVER and WORKGROUP lists), unless they are a Master Browser:
Added interface ip=192.168.10.165 bcast=192.168.10.255 nmask=255.255.255.0
Got a positive name query response from 192.168.10.134 ( 192.168.10.134 )
Domain=[SAMBADOM] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0]
Sharename Type Comment
--------- ---- -------
NETLOGON Disk Logon server share
pay Disk
HPLJ3 Printer HP LaserJet III
ADMIN$ Disk Remote Admin
IPC$ IPC Remote IPC
apps Disk
C$ Disk Default share
D$ Disk Default share
Orbaker Disk
print$ Disk Printer Drivers
Server Comment
--------- -------
DSWEET Don Sweet
MERLE Merle Owdom
ORBAKER Tim Orbaker
SAMBA Samba Server v2.0.7
SERVER1
Workgroup Master
--------- -------
BHEPC BHSV51
DOMAIN SERVER1
E2DOMAIN STORE1
If you want to get files from \\SERVER1\PAY, use the following:
/usr/local/samba/bin/smbclient //SERVER1/PAY -U orbaker \
-W DOMAIN
This will provide you with an interface that is a cross between FTP and a command prompt that allows you to manage the files on this share. Use 'help' to get a list of commands that can be used.
Linux users have an added option in the 'smbmount' command from the smbfs package. This command allows Windows shares to be mounted as part of the UNIX file system hierarchy. Users beware: This caches and can cause the directory listing to get out of sync with the actual Windows directory contents if changes to the filesystem are made at the Windows end and not at the UNIX end. This appears to be just directory entries and doesnęt appear to cause data corruption, but play it safe. If you are going to use it, use it like you might use FTP, in short quick sessions.
There is also an 'smbsh' command in development that can be built--if you have one of the few supported systems--using the command 'make smbwrapper'. None of the systems that I had available for testing would build this without modification.
Printing with SAMBA
SAMBA is capable of sharing printers as well as files. All printers that you have configured in your /etc/printcap file can be made available for Windows clients by adding the following to your smb.conf file and restarting SAMBA:
[printers]
path = /var/spool/lpd
writeable = no
guest ok = no # or yes, your choice
printable = yes
With this section in your smb.conf file, if you restart SAMBA, you should be able, from your Windows PC, to see and use the printers on the UNIX system.
Printing to SMB printers can be accomplished via the print command in the smbclient utility. An example of this might be (boldfaced text is typed by the user):
smbclient //SERVER1/HPLJ3 -P -U orbaker -W DOMAIN -I 192.168.10.10
Added interface ip=192.168.10.11 bcase=192.168.10.255 nmask=255.255.255.0
Password: *******
Domain=[DOMAIN] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0]
smb :\> print file.txt
putting file file.txt as file.txt (231.925 kb/s) (average 230.988 kb/s)
smb :\> quit
To script this session you must place the password, in clear text, on the command line. I strongly recommend against doing so unless the printer is globally available and your UNIX users can connect as a user with no privileges. For those that insist upon doing so, this script ought to be useful:
#!/bin/sh
################################################
# printto - A Script to print a single file to a specific SMB #
# printer. This script is freely given. Use it as you like #
################################################
SMBserver=SERVER1 # NetBIOS Name of the SMB Print Server #
SMBprinter=HPLJ3 # NetBIOS Name of the SMB Printer Share #
SMBdomain=DOMAIN # Name of the Domain or Workgroup #
SMBaddress=192.168.10.5 # IP Address of ${SMBserver} #
SMBusername=orbaker # SMB user name #
SMBpassword='p$98q,g' # Password (or blank for none). #
if [ -z "$1" ]; then
echo "usage: $0 <file>"
exit 1
elif [ ! -z "$2" ]; then
echo "error: only one file at a time"
exit 1
else
echo "Printing $1..."
fi
if [ -z "${SMBusername}" ]; then # Fill in a user name if needed
SMBusername="${USER}"
fi
if [ -z "${SMBpassword}" ]; then
smbclient //${SMBserver}/${SMBprinter} \
-N \
-P \
-W ${SMBdomain} \
-I ${SMBaddress} \
-U ${SMBusername} \
-c "print $1"
else
smbclient //${SMBserver}/${SMBprinter} \
${SMBpassword} \
-P \
-W ${SMBdomain} \
-I ${SMBaddress} \
-U ${SMBusername} \
-c "print $1"
fi
This script only works for a single specific printer. You would need multiple scripts for multiple printers, but it does make life easier for your users.
From Here
In the source directory, docs/textdocs has information on many different configurations as well as password encryption issues that you might run into for different versions of Windows.
It is, in theory, possible to share the same directories using NFS, SAMBA, NCPFS (NetWare) and AFP (AppleTalk Filing Protocol), thus making the same files available to almost every conceivable platform. Check the NT4-Locking and Win9x-CacheHandling files in the docs subdirectory of your SAMBA distribution for information about Windows file locking and caching that might prove problematic in situations like this.
While we have covered text-file configuration in this article, there is also a Web-based tool called Swat that comes with Samba. Using this tool allows an administrator to manage Samba from a Web interface. Instructions for setting it up to run under inetd are in the source package in swat/README.
References
Send your comments on this article to Tim Orbaker at orbaker@data.assist.com.
|
REPORTS
ANALYTICS
Follow 
