Linux Network Administratoramp;#039;s Guide (3rd Edition) [Electronic resources] نسخه متنی

16.1. SambaAn Introduction

Samba, still
actively developed in order to maintain feature compatibility with
the ever-changing Microsoft software, provides a framework to allow
Linux machines to access Windows network resources, such as shared
drives and printers. Samba not only lets Linux machines access these
services, but also allows Linux to offer these same services to
Windows machines. With Samba, it's possible to
completely replace a Windows-based file server, a Windows print
server, and even, with advanced options, replace the Primary Domain
Controller (PDC). Recent versions of Samba even allow Active
Directory compatibility. The open-source flexibility of Samba means
that development will be able to continue, and new features will be
introduced when the Windows architecture changes. More information on
Samba can be found in Using Samba, Second
Edition (O'Reilly), by Jay Ts, Robert Eckstein, and
David Collier-Brown.

16.1.1. SMB, CIFS, and Samba

The underlying technology used in Samba is
based on Server Message Blocks (SMB), which was
originally developed in the early 80s by Dr. Barry Feigenbaum while
he was working at IBM. Initially, IBM was actively involved with the
development, but Microsoft soon took charge and heavily continued the
development work. In later years, Microsoft renamed the SMB protocol
to Common Internet File System (CIFS), by which
it is now known. One sees the terms used interchangeably.

There is little accurate and
official documentation about how CIFS functions. Unlike most other
network protocols, there is no official RFC documentation, though
Microsoft did submit specifications to the IETF in the 1990s that
expired due to numerous inaccuracies and inconsistencies. Newer
documentation attempts by Microsoft have not been as helpful to the
Samba development group, due to the licensing restrictions place upon
it as well as a general lack of new
information.

16.1.2. Obtaining Samba

There
are a number of options available for obtaining Samba. Many
distributions now come with Samba as a part of their default
installation. If this is the case with your distribution, you will
not necessarily need to build from source. Red Hat, Mandrake, and
SuSE users may install the package from RPM, available via a number
of Samba mirrors. Gentoo users need only use emerge
samba to install the package, and Debian users do the same
with apt-get. Other users, or those who prefer
to do so, can install the Samba package from source. Often this
provides the greatest amount of flexibility because of the options
available at compile time.

16.1.2.1 Building from source

In order to build from source, you will need to obtain the latest
source tarball, found at any of the Samba mirrors listed on the main
http://www.samba.org site. Once
the tarball has downloaded, extract it to a directory and build the
binaries using the provided configuration file.

vlager#  tar xzvf samba-current.tgz
vlager#  cd samba-3.0.0
vlager#  cd source
vlager# ./configure
. . . 
. . . 
vlager# make
. . . 
vlager# make install

Once the
software has compiled and installed, you will need to choose how you
wish to have it run at startup. It can be run as an
inetd service or as a daemon. Either way is
acceptable, but running Samba from inetd may
require the update of your /etc/services file.
You will need to make sure that the following lines, which define the
Samba protocol, are inserted:

netbios-ns      137/tcp                         # NETBIOS Name Service
netbios-ns      137/udp
netbios-dgm     138/tcp                         # NETBIOS Datagram Service
netbios-dgm     138/udp
netbios-ssn     139/tcp                         # NETBIOS session service
netbios-ssn     139/udp
microsoft-ds    445/tcp         Microsoft-DS
microsoft-ds    445/udp         Microsoft-DS

After this
has been added or confirmed, you are should add Samba to your
inetd.conf file, or to your
xinetd configuration. You should also check to
verify that your firewall is configured to allow the necessary ports.

Alternately,
if you're planning to have Samba run as a daemon
process, you will need to add it to your rc
startup scripts. This is different for each of the various Linux
distributions, so if you're unsure of how to do
this, check your distribution's documentation.

16.1.3. Getting Started with Samba

Once
you've compiled or installed Samba, you now have the
potentially lengthy task of configuration ahead of you. The enormous
flexibility offered by Samba means that there are a number of
configuration options. Fortunately, for file server functionality,
the configuration is fairly straightforward. In this section,
we'll cover some of the basic options and discuss
how to create shared file directories. For additional information,
refer to Using Samba
(O'Reilly).

16.1.3.1 Basic configuration options

The easiest way to get started configuring Samba is to start with the
minimal configuration and add to it. So, to start,
we'll just create a workgroup, name our server, and
add a simple file share.

{global}
workgroup = Brewery
netbios name = vlager
[share]
path = /home/files
comment = Some HomeBrew recipes

You can
test your Samba configurations with testparm. It
will parse your configuration files and point out any typos or
incorrect options you've entered. At this point,
it's not too likely that you'll
have any mistakes, but it's still good to get to
know how to use the tool.

If
everything works, you can start or restart your Samba server and
attempt to view your new file share. The
smbclient program, which is a part of the Samba
package, can be used to view file shares. In this example,
we're going to look at the file shares
we've just created on vlager (10.10.0.5)

client#  smbclient -L 10.10.0.5
Password:
Sharename      Type      Comment
---------      ----      -------
share          Disk    Some HomeBrew recipes
client#

After the successful completion of this step, we're
now ready to tackle some more sophisticated configuration options,
which will make Samba much more useful.

16.1.3.2 Configuring Samba user accounts

The
above configuration is great if you're only
interested in having an open file share, but you may have been
wondering about access control. In the above example configuration,
anyone can connect to the file share. This is generally not a
desirable configuration on a network. It is for that reason that
Samba does, in fact, have user authorization functionality.

Staring
with the previous configuration file, authentication can be added by
adding the following lines:

security = user
encrypt passwords = yes
smb passwd file = /etc/samba/private/smbpasswd
username map = /etc/samba/smbusers

The first line enables user security. This
means that you will need to manage the users file on the Samba
server. The second line establishes that the Samba password file will
be encrypted. The third and fourth lines provide the path locations
for the password and user files. It isn't necessary
to have a separate users file, but it is possible with Linux.

When this
has been configured, you will now be required to create users on your
system. The Samba suite provides smbpasswd to
manage user accounts. This isn't required, because
Samba can reference the users in your
/etc/passwd file. However, if there are users
from Microsoft environments accessing files on your new Samba server,
you will need to have this file.

Creating users is pretty straightforward and is done with
the smbpasswd utility.

vlager# smbpasswd -a larry
New SMB password:
Retype new SMB password:
vlager#

Once the
user has been created, it can be tested with either a Windows machine
or a Linux machine using smbmount. After
entering \\<server.ip> into the Explorer
address bar, the Windows user will be presented with a dialog box, as
shown in Figure 16-1.

Figure 16-1. Windows network login request

For Linux, and other Unixes, smbmount is invoked
as follows:

vlager#  mount -t smbfs -o username=larry //server.ip /mnt/samba

If everything has been successful, you will now be able to access the
shared directory at /mnt/samba.

16.1.4. Additional Samba Options

So far, we've
discussed the bare minimum configuration of a Samba server. This is
great for those who just want to quickly get something on the
network. In order to get a little bit more out of Samba,
we'll now take a look at some additional options.

16.1.4.1 Access control

The Samba server offers some additional
security, which can prove very useful in large networks. IP-based
access control is available with what are likely very familiar
commands:

hosts allow = 10.10.
hosts.deny = any

This will allow
connections only from the 10.10
network. The Samba IP access control follows the same logic used by
tcpwrappers. You can either explicitly allow or
deny IP addresses or ranges. This option is really convenient because
it can be used at the global or the share level, meaning that you can
have a list of IP addresses that are either allowed or banned from
all of your server's file shares, or you can break
it down so that only certain IP addresses have access to certain
shared directories. This type of granular access is not even offered
by Windows itself!

The
Samba server is also flexible as to which interface it will bind to.
By default, it will bind to all available interfaces, including
loopback. To remove any unwanted access, such as binding Samba to the
external interface of a dual-homed machine, the bind interface can be
specified.

bind interfaces only = True
interfaces = eth1 10.10.0.4

This will make
sure that Samba listens only on the specified interface on the
provided IP address. If you are concerned about security, it is best
to restrict access at the application level, rather than rely on a
firewall to protect you.

Another type of access control
offered by Samba is the ability to mark a shared directory as
browsable. If it is browsable, it will be immediately visible and
users will be able to peruse its contents. The command to manipulate
this feature is:

browsable = yes|no

If you would like to be
able to give people access to certain files, perhaps by sending them
a URI pointing to a specific file, while not wanting them to be able
to see all the files in the directory, this option should be set to
no. A URI of this kind should look familiar; for
example, \\vlager.vbrew.com\recipe\secret.txt
would work for Windows users, while for Unix users, one might use
smb://vlager.vbrew.com/recipe/secret.txt. In
either case, the user would be allowed access to just the
secret.txt file only. For most purposes it is
set to yes, as the Samba server tends to be more
functional when users can browse the filesystem.

Along
the same lines, shared directories can be marked as to whether or not
they're publicly available. If a folder is not
public, even with a specific URI a user cannot access a file. It is
important to note, though, that anyone with a Samba account will be
able to view folders that are labeled public.

public = yes|no

Having granted viewing rights to a user,
the Samba administrator can also choose whether or not shared
directories are writable. This is done with the writable command:

writable = yes|no

When this option is set to no, nothing can be
written to the directory.

Should you wish to have a fairly open
Samba server for something like an open, browsable documentation
server, you might wish to enable the Samba guest account. This is
easily done with the guest directive:

guest ok = yes|no

Finally, one of the most useful features
of Samba is that it allows access to shared directories to be
controlled with user access lists. The easiest way to accomplish this
is by using the valid users option.

valid users = sharon paul charlie pat

You can also simplify this by using an already defined group from
your /etc/group file:

valid users = @brewers

The at sign
(@) tells Samba that the
brewers value is the group name. Having
controlled access to the point where you're
comfortable, you're probably interested in making
sure that your configuration is working. One of the best ways to see
what's happening with Samba is through its excellent
logging capabilities.

16.1.4.2 Logging with Samba

Using the log functions with Samba is
quite simple. There are a number of additional modifiers that can be
added to expand on the logging capabilities. The most basic logging
can be accomplished with the following command:

log file = /var/log/samba.log

This will provide basic logging of all Samba transactions to the file
specified. However, in some instances, these logfiles can be a bit
unwieldy if many machines are accessing the Samba server. To make the
logging easier to sift through, Samba offers the ability to log by
each host that connects. Enabling this functionality requires only
the following addition:

log file = /var/log/samba.log.%m

As
with most logging functions on Linux, the administrator has the
ability to configure how much logging occurs. In Samba, these log
levels follow a 0 to 10 scale, starting from light to intensive
logging. For most uses, the Samba documentation suggests using log
level 2, which provides a good amount of information for debugging,
without overdoing it. Levels 3 and higher are designed for Samba
programmers and aren't for normal usage. To specify
the log level in your Samba configuration file, add this line:

log level = 2

If you have a fairly busy server, it is
likely that your logfiles will grow very quickly. For this reason,
Samba offers a maximum size logfile directive.

max log size = 75

This example sets the maximum logfile size to 75 KB. When the logfile
reaches this size, it is automatically renamed by adding
.old to the file, and a new logfile is created.
When the new logfile reaches 75 KB, the previous .old
file is overwritten. If you have logfile retention
requirements in your environment, make sure that you have a script
that automatically archives your Samba logs.

16.1.4.3 Logging with syslog

In
addition to its own logging capabilities, Samba, when compiled with
the --with-syslog option, will also use the system
logger. In situations when administrators have automated log-watching
tools, like swatch, this can be more useful. To
have Samba use syslog, just add the following line to your Samba
configuration file:

syslog = 2

This will send all of
Samba's Level 2 logging detail to the syslogfile. If
you're happy with this, and would like to use the
syslog exclusively, specify the following in your
smb.conf:

syslog only = yes

16.1.5. Printing with Samba

Samba is fully functional as a Windows print
server, enabling users to connect and print, and even download
relevant print drivers. According to the Samba team, this was one of
the biggest interoperability issues they faced because of
complexities with the Windows print job queuing system. There are a
number of ways to configure Samba for printing, but the two most
common are the traditional BSD printing, and more recent CUPS.

16.1.5.1 BSD Printing

The older, traditional method of printing
is the BSD print system which is based around the RFC 1179 framework.
It uses commands such as lpr that most Unix
administrators are familiar with. Samba works well with this
environment, and it is easily configured. The basic configuration to
enable BSD printing looks like this:

[global]
printing = bsd
load printers = yes
[printers]
path = /var/spool/samba
printable = yes
public = yes
writable = no

At this
point, if you're thinking that this seems really
simplistic, it is! This is thanks to the fact that Samba makes a
great number of assumptions with its default configuration. To see
what the configuration really looks like, you
can use the testparm program:

ticktock samba # testparm -s -v |egrep "(lp|print|port|driver|spool|\[)"
Processing section "[printers]"
[global]
smb ports = 445 139
nt pipe support = Yes
nt status support = Yes
lpq cache time = 10
load printers = Yes
printcap name = /etc/printcap
disable spoolss = No
enumports command =
addprinter command =
deleteprinter command =
show add printer wizard = Yes
os2 driver map =
wins support = No
printer admin =
nt acl support = Yes
min print space = 0
max reported print jobs = 0
max print jobs = 1000
printable = No
printing = bsd
print command = lpr -r -P'%p' %s
lpq command = lpq -P'%p'
lprm command = lprm -P'%p' %j
lppause command =
lpresume command =
printer name =
use client driver = No
[printers]
path = /var/spool/samba
printable = Yes

This is the point at which you can readjust some of the default
options that might not be right for your system. One item to consider
is whether the lp commands are in your default
path. You can also add anything to the lp
command lines that you see fit.

A
sample /etc/printcap file is also included here.
As all systems are different, this configuration file may not work
properly for you, but it is provided to give you an idea of the
configuration format. For more detailed information, check the
printcap manpages.

# /etc/printcap: printer capability database.
/lp|Generic dot-matrix printer entry
:lp=/dev/lp1
:sd=/var/spool/lpd/lp
:af=/var/log/lp-acct
:lf=/var/log/lp-errs
:pl#66
:pw#80
:pc#150
:mx#0
:sh

16.1.5.2 Printing with CUPS

The Common Unix
Printing System (CUPS) is quickly replacing BSD-style
printing in most Linux distributions. There are numerous reasons why
CUPS is displacing the status quo, which we will leave for another
discussion. However, no discussion of printing in the Samba
environment would be complete without now including a section on CUPS
printing.

To introduce
printing with CUPS, let's have a look at a simple
CUPS configured smb.conf file:

[global]
load printers = yes
printing = cups
printcap name = cups
[printers]
comment = Brewery Printers
path = /var/spool/samba
browsable = no
public = yes
guest ok = yes
writable = no
printable = yes
printer admin = root, @wheel

This is all that is required for basic configuration to make Samba
work with CUPS, provided that CUPS itself is functional on your
system.

The
global section establishes that the
/etc/printcap file is enumerated with the
load printers option, which
automatically parses the printcap and enables the printers configured
within. This feature can be both really helpful and a bit frightening
for some system administrators. While it makes configuration much
easier, it does somewhat reduce the administrators ability to control
what is visible to users. If this option turned off, you must
individually create each printer share in the Samba configuration
files.

The printing option, which we had previously set to
bsd, has been changed to cups.
We've also named the printcap
cups for clarity.

The next section, printers, is also very similar to the previous
example; however, we've now configured a printer
administration group. This is a basic option that will allow the
group specified to have administrative access to the CUPS aspects of
the printing.

While not necessary, there are
a number of additional options that can be added to a cups-based
printer configuration to customize it based on need. For more detail
and advanced configuration with CUPS and Samba, check the Samba web
site at http://www.samba.org and
the CUPS web site at http://www.cups.org.

16.1.6. Using SWAT

Samba Web
Administration Tool (SWAT) is used to simplify
administration and configuration of Samba. For those who like to use
a GUI, this is one of the best options because it is written by the
Samba team and contains all possible configuration options. Other GUI
frontend programs will work, but may not be as current.

16.1.6.1 Enabling SWAT

SWAT
is basically a web server as well as an administration tool. In order
to get it working, you will need to add it to your
inetd.conf or xinetd
configurations. With xinetd, your configuration
for swat should look something like this:

service swat
{
port            = 901
socket_type     = stream
wait            = no
user            = root
server          = /usr/sbin/swat
log_on_failure += USERID
disable         = no
}

You will also
need to add the SWAT port to your /etc/services
file, if it's not already there.

swat            901/tcp                         # Samba configuration tool

After you restart your
xinetd process, you are ready to use the
service, which you would do by pointing your web browser at your
Samba server's IP address on port 901.

16.1.6.2 SWAT and SSL

You may have noticed that SWAT
doesn't use SSL, which is probably OK if you are
using it from only localhost. If you are
interested in using it over the network, however, encryption is a
good idea. Though SWAT doesn't support encryption,
it can be added using the popular SSL tunneling tool called
stunnel.

The easiest method
to configure this was developed by Markus Krieger. In order to use
this method, you will need to have both OpenSSL and
stunnel installed. Documentation and source code
for stunnel can be found at http://www.stunnel.org. Once both are
installed and operational, you will need to generate a private key,
which can be done like this:

vlager# /usr/bin/openssl req -new -x509 -days 730 -nodes -config /path/to/stunnel/stunnel.cnf -out /etc/stunnel/stunnel.pem -keyout /etc/stunnel/stunnel.pem

Once you have
created your keys, you need to make sure that you remove the original
SWAT from your inetd.conf file and send a SIGHUP
signal to the daemon, if necessary. You will no longer be calling the
standard SWAT daemon through inetd, so be sure
that it has been removed.

stunnel can now be started. You can launch it
from the command line or create a small script to launch it
automatically. To start stunnel, as
root, type:

vlager# stunnel -p /etc/stunnel/stunnel.pem -d 901 -l /path/to/samba/bin/swat swat

16.1.7. Troubleshooting Samba

If
you've built your Samba server and everything has
worked perfectly the first time, consider yourself a part of the
lucky minority. For everyone else, we'll now discuss
a few tips on how to track down and fix some common problems.

16.1.7.1 Configuration file woes

When troubleshooting Samba, one important
issue to keep in mind is that the default options always take
priority. This means that if a default configuration option is set,
simply commenting it out does not change its value. For example, you
can try to disable the load printers option by
simply commenting it out.

[printers]
path = /var/spool/samba
#load printers = yes

However,
using testparm, you will see that the option is
still set to yes.

ticktock samba # testparm -s -v |grep "load printers"
load printers = Yes

With Samba, you must always explicitly
define the options you wish to have; commenting out will not
necessarily guarantee success. If something isn't
working as expected, check this first.

As basic as it
sounds, you should also check to see whether the
smbd and nmbd processes
exist. It is not uncommon for something to cause them to fail
silently, and you will not realize they are not running.

16.1.7.2 Account problems

One
of the more common login problems with Samba occurs with the root,
but can happen with any user on the system. For each Samba user, it
is important to remember that a separate Samba password must be
created because Samba does not use the Linux /etc/shadow
hash. For example, if you try to access a Samba file share
as root, the system root
password will fail, unless you've already created a
Samba password for the root account using the
same root password (which is definitely not
advised). To correct this issue, a separate account must be created
as follows:

vlager# smbpasswd -a root
New SMB password:
Retype new SMB password:
Added user root.