A caption from http://www.samba.org/samba/docs/SambaIntro.html
What Samba Does
Samba consists of two key programs, plus a bunch of other stuff that we'll
get to later. The two key programs are
smbd and
nmbd. Their job is to implement the four basic modern-day
CIFS services, which are:
- File & print services
- Authentication and Authorization
- Name resolution
- Service announcement (browsing)
File and print services are, of course, the cornerstone of the CIFS suite.
These are provided by
smbd, the SMB Daemon.
Smbd
also handles "share mode" and "user mode" authentication
and authorization. That is, you can protect shared file and print
services by requiring passwords. In share mode, the simplest and least
recommended scheme, a password can be assigned to a shared directory or
printer (simply called a "share"). This single password is then
given to everyone who is allowed to use the share. With user mode
authentication, each user has their own username and password and the
System Administrator can grant or deny access on an individual basis.
The Windows NT Domain system provides a further level of authentication
refinement for CIFS. The basic idea is that a user should only have to
log in once to have access to all of the authorized services on the
network. The NT Domain system handles this with an authentication server,
called a Domain Controller. An NT Domain (which should
not be
confused with a
Domain Name System (DNS)
Domain) is basically a group of machines which share the same Domain
Controller.
The NT Domain system deserves special mention because, until the
release of Samba version 2, only Microsoft owned code to implement the
NT Domain authentication protocols. With version 2, Samba introduced
the first non-Microsoft-derived NT Domain authentication code. The
eventual goal, of course, it to completely mimic a Windows NT Domain
Controller.
The other two CIFS pieces, name resolution and browsing, are handled
by
nmbd. These two services basically involve the
management and distribution of lists of NetBIOS names.
Name resolution takes two forms: broadcast and point-to-point. A
machine may use either or both of these methods, depending upon its
configuration. Broadcast resolution is the closest to the original
NetBIOS mechanism. Basically, a client looking for a service named
Trillian will call out
"Yo! Trillian! Where are
you?", and wait for the machine with that name to answer with
an IP address. This can generate a bit of broadcast traffic (a lot of
shouting in the streets), but it is restricted to the local LAN so it
doesn't cause too much trouble.
The other type of name resolution involves the use of an NBNS
(
NetBIOS Name Service) server.
(Microsoft called their NBNS implementation WINS, for
Windows
Internet Name Service, and that acronym is more
commonly used today.) The NBNS works something like the wall of an old
fashioned telephone booth. (Remember those?) Machines can leave their
name and number (IP address) for others to see.
Hi, I'm node Voomba. Call me for a good time! 192.168.100.101
It works like this: The clients send their NetBIOS names & IP
addresses to the NBNS server, which keeps the information in a simple
database. When a client wants to talk to another client, it sends the
other client's name to the NBNS server. If the name is on the list, the
NBNS hands back an IP address. You've got the name, look up the number.
Clients on different subnets can all share the same NBNS server so,
unlike broadcast, the point-to-point mechanism is not limited to the local
LAN. In many ways the NBNS is similar to the DNS, but the NBNS name list
is almost completely dynamic and there are few controls to ensure that
only authorized clients can register names. Conflicts can, and do, occur
fairly easily.
Finally, there's browsing. This is a whole 'nother kettle of worms,
but Samba's
nmbd handles it anyway. This is not the web
browsing we know and love, but a browsable list of services (file and
print shares) offered by the computers on a network.
On a LAN, the participating computers hold an election to decide which
of them will become the Local Master Browser (LMB). The "winner"
then identifies itself by claiming a special NetBIOS name (in addition to
any other names it may have). The LMBs job is to keep a list of available
services, and it is this list that appears when you click on the Windows
"Network Neighborhood" icon.
In addition to LMBs, there are
Domain Master Browsers
(DMBs). DMBs coordinate browse lists across NT Domains, even on routed
networks. Using the NBNS, an LMB will locate its DMB to exchange and
combine browse lists. Thus, the browse list is propagated to all hosts
in the NT Domain. Unfortunately, the synchronization times are spread
apart a bit. It can take more than an hour for a change on a remote
subnet to appear in the Network Neighborhood.
Other Stuff
Samba comes with a variety of utilities. The most commonly used are:
- smbclient
- A simple SMB client, with an interface similar to that of the
FTP utility. It can be used from a Unix system to connect to a
remote SMB share, transfer files, and send files to remote print
shares (printers).
- nmblookup
- A NetBIOS name service client.
Nmblookup can be used
to find NetBIOS names on a network, lookup their IP addresses, and
query a remote machine for the list of names the machine believes
it ownes.
- swat
- The Samba Web Administration
Tool.
Swat allows you to configure Samba
remotely, using a web browser.
There are more, of course, but describing them would require explaining
even more bits and pieces of CIFS, SMB, and Samba. That's where things
really get tedious, so we'll leave it alone for now.
SMB Filesystems for Linux
One of the cool things that you can do with a Windows box is use an SMB
file share as if it were a hard disk on your own machine. The
N: drive can look, smell, feel, and act like your own disk
space, but it's really disk space on some other computer somewhere else on
the network.
Linux systems can do this too, using the
smbfs filesystem.
Built from Samba code,
smbfs (which stands for
SMB
Filesystem) allows Linux to map a remote SMB share into
its directory structure. So, for example, the
/mnt/zarquon
directory might actually be an SMB share, yet you can read, write, edit,
delete, and copy the files in that directory just as you would local
files.
The
smbfs is nifty, but it only works with Linux. In
fact, it's not even part of the Samba suite. It is distributed with Samba
as a courtesy and convenience. A more general solution is the new
smbsh (
SMB shell, which is still under
development at the time of this writing). This is a cool gadget. It is
run like a Unix shell, but it does some funky fiddling with calls to Unix
libraries. By intercepting these calls,
smbsh can make it
look as though SMB shares are mounted. All of the read, write, etc.
operations are available to the
smbsh user. Another feature
of
smbsh is that it works on a per-user, per shell basis,
while mounting a filesystem is a system-wide operation. This allows for
much finer-grained access controls.
Setup and Management
Samba is configured using the
smb.conf file. This is a
simple text file designed to look a lot like those *.ini files used in
Windows. The goal, of course, is to give network administrators familiar
with Windows something comfortable to play with. Over time, though, the
number of things that can be configured in Samba has grown, and the
percentage of Network Admins willing to edit a Windows *.ini file has
shrunk. For some people, that makes managing the
smb.conf
file a bit daunting.
Still, learning the ins and outs of
smb.conf is a
worth-while penance. Each of the
smb.conf variables has a
purpose, and a lot of fine tuning can be accomplished. The file structure
contents are fully documented, so as to give administrators a running head
start, and
smb.conf can be manipulated using
swat, which at least makes it nicer to look at.
