By Gerald Carter, Jay Ts, Robert Eckstein
Book Price: $44.99 USD
£31.99 GBP
PDF Price: $35.99

Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: An Introduction to Samba

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Samba has been the subject of many cute descriptions in the past, some of which might have included a dancing penguin carrying a Microsoft Windows logo. We have been guilty of these things ourselves at one time or another. Although these pictures and descriptions can make great opening lines for magazine articles, they don't have the substance to sell IT shops on the elegance with which this piece of software can solve the very complex interopability problems faced by environments composed of Macintosh, Microsoft, and Unix (or Unix-like) systems. If we had to come up with a one-line executive summary to justify the existence of Samba, we would say, "Samba is a software suite that allows a Unix-based system to appear and function as a Microsoft Windows server when viewed by other systems on a network."

There are many components to Samba. Each of the pieces operate together to implement both the client and server portion of the Common Internet File System (CIFS) protocol. CIFS is the network protocol used by Microsoft operating systems for remote administration and to access shared resources such as files and printers. Despite the name, CIFS is neither a filesystem nor suitable for the Internet. It is, however, the protocol of choice in Windows networks.

There are several reasons to use Samba instead of Windows Server. As many experienced network administrators can testify, Samba provides day-in and day-out reliability, scalability, and flexibility. In addition, Samba offers freedom in both choice and cost. Samba is freely available from http://www.samba.org under the terms of the GNU General Public License (http://www.fsf.org/licensing/licenses/gpl.html). And because of Samba's portability, you are free to choose which server platform to use, such as FreeBSD, Linux, Solaris, or OS X.

One of the fascinating things about open source software such as Samba is that it creates a community of people surrounding the project, composed of more than just developers. The community of Samba users varies from IT professionals to teachers, consultants, and dentists. Also, many large companies, such as HP, IBM, Sun, Apple, RedHat, and Novell, distribute and commercially support Samba. If a time arises that you need outside support for your Samba servers, you are free to choose any of these providers for your support.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What Is Samba?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Samba is the brainchild of Andrew Tridgell, who started the project in 1991, while working with a Digital Equipment Corporation (DEC) software suite called Pathworks, created for connecting DEC VAX computers to computers made by other companies. Without knowing the significance of what he was doing, Andrew created a fileserver program for an odd protocol that was part of Pathworks. That protocol later turned out to be the Server Message Block (SMB), the predecessor to CIFS. A few years later, he expanded upon his custom-made SMB server and began distributing it as a free product on the Internet under the name "SMB Server." However, Andrew couldn't keep that name—it already belonged to another company's product—so he tried the following Unix renaming approach:

$ grep -i '^s.*m.*b.*' /usr/dict/words

And the response was:

salmonberry
samba
sawtimber
scramble

Thus, the name "Samba" was born. Today Samba is actively developed by a team of programmers distributed around the world.

One of the best ways to describe Samba is to explain some of the things that it can do. As previously mentioned, Samba implements the CIFS network protocol. By supporting this protocol, Samba enables computers running Unix-based operating systems to communicate with Microsoft Windows and other CIFS-enabled clients and servers. Some examples of common services offered by Samba are:

• Share one or more directory trees
• Provide a Distributed Filesystem (MS-DFS) namespace
• Centrally manage printers, print settings, and their associated drivers for access from Windows clients
• Assist clients with network browsing
• Authenticate clients logging onto a Windows domain
• Provide or assist with Windows Internet Name Service (WINS) name-server resolution

The Samba suite also includes client tools that allow users on a Unix system to access folders and printers that Windows systems and Samba servers offer on the network.

Samba's current stable release, version 3.0, revolves around three Unix daemons:

smbd

This daemon handles file and printer sharing and provides authentication and authorization for SMB clients.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What Can Samba Do for Me?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As explained earlier, Samba can help Windows and Unix computers coexist in the same network. However, there are some specific reasons why you might want to set up a Samba server on your network:

• You do not need—or wish to pay for—a full-fledged Windows server, yet you need the file and print functionality that one provides.
• You want to provide a common area for data or user directories to transition from a Windows server to a Unix one, or vice versa.
• You want to share printers among Windows and Unix workstations.
• You are supporting a group of computer users who have a mixture of Windows and Unix computers.
• You want to integrate Unix and Windows authentication, maintaining a single database of user accounts that works with both systems.
• You want to network Unix, Windows, Macintosh (OS X), and other systems using a single protocol.

Let's take a quick tour of Samba in action. Imagine the following basic network configuration: a Samba-enabled Unix system, to which we will assign the name RAIN, and a pair of Windows clients, to which we will assign the names LETTUCE and TOMATO, all connected via a local area network (LAN). The server RAIN has a local inkjet printer connected to it, inkprint, and a disk share named documents—both of which it can offer to the other two computers. A graphic of this network is shown in Figure 1-1.

Figure 1-1: A simple network set up with a Samba server

In this network, each computer listed shares the same workgroup. A workgroup is a group name tag that identifies an arbitrary collection of computers and their resources on an SMB/CIFS network. Several workgroups can be on the network at any time, but for our basic network example, we'll have only one: the GARDEN workgroup.

If everything is properly configured, we should be able to see the Samba server, RAIN, through the My Network Places directory on the Windows desktop, as shown in Figure 1-2. In fact, you should also be able to see each host that belongs to the GARDEN workgroup. Note the Microsoft Windows Network icon in the lefthand toolbar. As we just mentioned, more than one workgroup can exist on a network at any given time. A user who clicks this icon will see a list of all the workgroups that currently exist on the network.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Common Internet File System

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Modern Microsoft operating systems rely upon a resource-sharing protocol known as CIFS. CIFS provides APIs for manipulating files and for implementing remote administration functionality such as user password changes and printing services.

Microsoft would have you think that this is a new protocol unrelated to its predecessor, the SMB protocol, but CIFS is really just the latest variant in a long line of SMB protocol dialects. It could be argued that it is even just a new name for the latest revision of SMB. Frequently, you will see the terms SMB and CIFS used interchangably or perhaps as a combination (e.g., SMB/CIFS). In other contexts, people use CIFS to refer to the NetBIOS-less incarnation of SMB over TCP/445 implemented by Windows 2000 and later operating systems and SMB to refer to Windows 9x/ME and NT systems. The line is never really clear from the perspective of a developer or a network administrator. For simplicity, this book uses CIFS to refer to the combination of SMB and CIFS operations.

Microsoft has introduced a new variant of the CIFS protocol, called SMB2, in Windows Vista. The details of this new protocol are still emerging. As always, Samba developers continue working to ensure compatibility with the most recent OS releases from Redmond.

CIFS is a connection-oriented, stateful protocol that relies upon three supporting network services:

• A name service
• A means of sending datagrams to a single or group of hosts
• A means of establishing a long-term connection between a client and server

Both Samba 3.0 and Windows 2000/XP/2003 support using standard IP services to meet these requirements. For example, the Domain Name Service (DNS) translates names to addresses, UDP packets provide the datagram service, and the TCP protocol provides the support needed for CIFS sessions. More on TCP/IP and DNS can be found in TCP/IP Network Administration, by Craig Hunt, and DNS and BIND, by Paul Albitz and Cricket Liu, both published by O'Reilly.

Prior to Windows 2000, Microsoft clients relied upon a layer called NetBIOS to provide this supporting infrastructure. Although modern CIFS clients and servers, including Samba, can function without utilizing NetBIOS services, most usually provide a legacy mode of operation for communicating with older CIFS implementations. Figure 1-6 illustrates the relationship between CIFS, hosts on a network, and core network services. The NetBIOS protocol is generally unfamiliar to Unix sysadmins and therefore deserves a little more attention.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Connecting to a CIFS File Share

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

So, what happens when a user types net use p: \\rain\documents? To simplify the answer, let's assume the presence of a name service, a datagram service, and a session service, and ignore the details of whether the underlying network uses the NetBIOS interface or TCP/IP. In Chapter 5, we discuss how a CIFS server such as Samba handles operations such as authentication and authorization when connecting to file and printer shares; for now, let's just assume that these things are working.

Figure 1-10 shows the basic steps that a client will go through in order to access a remote share such as \\RAIN\documents. The diagram assumes that the client, named CATHY, has already resolved the server's name, SAM, to an IP address using either DNS or the NetBIOS mechanisms discussed earlier. Be aware that the steps to connect to a file or printer share are not always the same, because CIFS supports multiple authentication types and models. For now however, just focus on the scenario of an individual connecting to a share using a login name and password for the session credentials. This is by far the most common and intuitive case.

Figure 1-10: Examining what happens when a user types net use p: \\server\share

The first step in establishing the CIFS connection is to negotiate the protocol dialect that the client and server will use. The client transmits a list of dialects that it understands and the server selects the one that it prefers (supposedly the one with the most supported features). Table 1-6 lists the CIFS dialects supported by Samba 3.0.

Developers plan to enhance the POSIX 2 dialect in a future version of Samba so that the client can take more advantage of the Unix CIFS Extensions for file operations. More details on these extensions are covered in Chapter 11.

Table 1-6: CIFS protocol dialects

Protocol name	smb.conf name	Example clients

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Browsing

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Browsing is the process of finding the other computers and shared resources in the Windows network. Note that this is unrelated to web browsing on the Internet, apart from the general idea of "discovering what's there." On the other hand, browsing the Windows network is like the Web in one way: what's out there can change without warning. Also be aware that browsing is not the same thing as searching Active Directory (AD) for hosts or resources. Although the NetBIOS browse service and AD are each a type of directory service, the implementation details are completely different. The comments in this section apply to browsing NetBIOS networks, not AD.

Before browsing existed, users had to know the name of the computer they wanted to connect to on the network and then manually enter a UNC such as \\rain\documents to an application or file manager to access resources. Browsing is much more convenient, making it possible to examine the contents of a network by using the point-and-click My Network Places GUI interface on a Windows client.

You will encounter two types of browsing in an SMB network:

• Browsing a list of computers and shared resources
• Browsing the shared resource of a specific computer

Let's look at the first type. On each LAN (or subnet) with a workgroup or domain, one computer has the responsibility of maintaining a list of the computers that are currently accessible through the network. This computer is called the local master browser, and the list it maintains is called the browse list. Computers on a subnet use the browse list to cut down on the amount of network traffic generated while browsing. Instead of each computer dynamically polling to determine a list of the currently available computers, the computer can simply query the local master browser to obtain a complete, up-to-date list.

To browse the resources on a computer, a user must connect to the specific computer; this information cannot be obtained from the browse list. Browsing the list of resources on a computer can be done by double-clicking the computer's icon when it is presented in My Network Places. As you saw at the opening of the chapter, the computer responds with a list of shared resources that can be accessed after the user is successfully authenticated.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Authentication: Peer-to-Peer Versus Domains

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Peer-to-peer networks (not to be confused with P2P file sharing) were originally designed to allow users to share resources from their desktop computer with other users across a network. Network browsing was also originally designed to support this type of ad hoc networking in which no central management of disks or printers was needed. Users could turn their PCs on or off at will without fear of disrupting other users or network services (except those people who were accessing files or printers on the now-offline host).

When a request to access a file share or printer was received, the local computer was responsible for handling the authentication request as part of the connection process. Thus, any user account information or passwords had to be stored on the CIFS "server." If a user required access to shares on six remote machines, the user had to either remember six passwords or keep her account information synchronized across all six servers. Both solutions faced a scalability issue.

The peer-to-peer networking model of local authentication functions fairly well, as long as the number of computers on the network is small and there is a close-knit community of users. However, in larger networks, the simplicity of workgroups becomes a limiting factor. To support the needs of larger networks, such as those found in departmental computing environments, Microsoft introduced domains with Windows NT 3.51. A Windows NT domain is essentially a browsing group of CIFS-enabled computers with one addition: a server acting as a domain controller (see Figure 1-11).

Figure 1-11: A simple Windows domain

A domain controller in a Windows domain performs a role similar to a Network Information Service (NIS) server or LDAP directory service in a Unix network, maintaining a domain-wide database of user and group information, as well as performing related services. The responsibilities of a domain controller are mainly related to security, including verifying user credentials (

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What's in Samba 3.0?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Samba 3.0 includes many features designed at better integration with Active Directory domains. Additionally, Samba's implementation of a Windows NT domain controller has become richer, although it is still missing a few features. Samba developers have also continued to improve functionality introduced in earlier releases, such as printing support for Windows 2000/XP clients, filesystem ACLs, and Winbind.

Samba 3.0 includes support for several newer security additions to the CIFS protocol, such as packet integrity checks known as SMB signing, secure channel communication, and the NTLMv2 authentication algorithm. Thus, it is possible to have a Samba server support domain logons for a network of Windows clients, including the most recent releases from Microsoft. This setup can result in a very stable, high-performance, and more secure network; it also provides the benefit of not having to purchase per-seat Windows Client Acccess Licenses (CALs) from Microsoft. The current release also supports migration of user and group information from a Windows NT 4.0 domain to a Samba domain, so that you are able to continue to upgrade your network without the costs of purchasing Windows 2000 Server or newer in order to use Active Directory.

In addition to the NT4 domain mode security provided by Samba 2.x, 3.0 introduces a new ADS domain mode security that allows a Samba host to join an Active Directory domain and authenticate individual connection requests from clients using Kerberos tickets. The winbindd daemon also supports obtaining user and group information via more effecient LDAP searches instead of Remote Procedure Calls (RPC).

Windows has always supported the concept of adding groups as members of other groups. Current Samba releases also support this capability, by using Winbind to define a group that is local to the server and can contain Windows domain groups. Upon receiving a request for the list of users in the local group, Winbind expands the membership of any nested domain groups that it contains. This feature can be useful, such as when you want to set the group ownership of a file that must be accessible by multiple domain groups. You define on the Samba host a local group that contains all of the appropriate domain groups. Of course, it is possible to perform an equivalent function if the filesystem supports access control lists. However, local groups have the advantage of requiring you to deal with only one group instead of many. More on Winbind's support for local groups is in Chapter 10.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Future Research in Samba 4.0

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Samba 4.0 is an ambitous research project, taken up by Samba developers around the time that Samba 3.0.0 was released (in late 2003), to address a desire for newer features that were believed to be extremely hard to achieve in the Samba 3.0 code base. Examples of these projects of these items include:

• Support for non-POSIX filesystems
• Full NTFS semantics
• Active Directory domain control support

At the time of writing, a proof-of-concept AD implementation has been completed, with the exception of the directory replication protocol.

There has been a great deal of confusion about the relationship between Samba 3.0 and Samba 4. Both source code repositories are part of the Samba project. Samba 3.0 is the current production branch, and Samba 4 is the research branch, which is focused on new functionality that will be integrated into production releases once it has matured.

The current question system administrators ask most often is "When will Samba 4 be released?" In our opinion, it is helpful to view Samba 4 as a blueprint of what project leaders want Samba to be. Of course, blueprints often require a prototype, so developers will release technical previews of the Samba 4 branch from time to time as a way to expose designs to a wider audience. Some prototypes succeed; others are thrown away. At some point, the production releases of Samba will look like the working prototypes. Whether this occurs gradually or all at once is yet to be seen.

Pieces of Samba 4 have already been released as production quality services. For example, the samba4wins project (http://enterprisesamba.org) provides a WINS server that supports the Microsoft WINS replication protocol. Other pieces, such as Samba 4's memory management library, are shipping in Samba 3.0 today. It's likely that Samba 4 in whole or in part will continue to coexist with Samba 3.0 for several years to come. No one can accurately predict which release will contain the combined features of Samba 3.0 and technology of Samba 4.

For the latest in development and release news, check the Samba news site (http://news.samba.org), available mailing lists hosted at

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What Can Samba Do?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We'll wrap up by showing how Samba can currently help out and how it is limited. Table 1-7 summarizes the roles that Samba can and cannot play in a Windows NT or Active Directory domain or a Windows workgroup. The Windows domain protocols are proprietary and have not been documented by Microsoft, and therefore must be analyzed by developers before Samba can support them.

Table 1-7: Samba roles (as of version 3.0.22)

Role	Can perform?
File server	Yes
Printer server	Yes
Microsoft DFS server	Yes
Windows NT 4 domain controller	Yes
Interact with Windows DCs in the same domain	No
Active Directory DC	No
Windows 95/98/Me authentication	Yes
Windows NT/2000/XP/2003 authentication	Yes
Local master browser	Yes
Domain master browser	Yes
Primary WINS server	Yes
Secondary WINS server	No

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

An Overview of the Samba Distribution

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As mentioned earlier, Samba actually contains several programs that serve different but related purposes. Here we introduce each of them briefly and describe how they work together. These programs are documented fully in Appendix A.

The majority of the programs that come with Samba center on its three major daemons and one management service application. Let's take a high-level look at the responsibilities of each:

nmbd

The nmbd daemon is a simple name server that supplies WINS functionality. This daemon listens for name-server requests and provides the appropriate IP addresses when called upon. It also provides browse lists for the My Network Places application and participates in browsing elections.

smbd

The smbd daemon manages the shared resources between the Samba server and its clients. It provides file and print services to SMB/CIFS clients across one or more networks and handles all notifications between the Samba server and the network clients. In addition, it is responsible for user authentication, resource locking, and data sharing through the SMB/CIFS protocol.

swat

The Samba Web Administration Tool (SWAT) is a HTTP-based application for managing Samba. In essence, SWAT offers a graphical interface to functions performed by the included command-line tools.

winbindd

This daemon is used along with the name service switch to get information on users and groups from a Windows domain controller, and allows Samba to authenticate users from a Windows domain.

The Samba distribution also comes with a small set of Unix command-line tools:

findsmb

A program that searches the local network for computers that respond to SMB protocol and prints information on them. It is written in Perl and is a good example of how scripts can utilize Samba command-line tools to extend functionality.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

How Can I Get Samba?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Source and binary distributions of Samba are available from mirror sites across the Internet. The primary web site for Samba is located at http://www.samba.org. From there, you can select a mirror site that is geographically near you. Most Linux and many Unix vendors provide binary packages. These can be more convenient to install and maintain than the Samba team's source or binary packages, due to the vendor's efforts to supply a package that matches its specific products. The next chapter focuses on all the details necessary to get Samba up and running on your server.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: Installing Samba on a Unix System

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

It would be unwise to purchase a car or a house on appearance alone or from a description in a brochure. It is similarly unwise to talk about a piece of software without hands-on experience. Systems administration is a hands-on job. In this chapter, we are dedicated to helping you test drive your own server so that you can see for yourself how Samba behaves. Because open source projects (and software packages in general) evolve over time, the remainder of this book is based on the current production Samba release at the time of writing, version 3.0.22. We start with the necessary steps to install Samba both from the source release available on the official Samba web site and from vendor or community packages. By the end of the chapter, you will have a working server with a simple disk share.

Samba is so popular with Unix/Linux administrators that many vendors include prepackaged versions in their operating system distributions. There are advantages to using software packages, one of which is that you do not have to bother with the details of compiling the software itself. The main drawback is that you are dependent on the options the vendor chose when building Samba. It is also likely that the server will be slightly behind the current production Samba release, because vendors tend to upgrade packages only when there is a strong reason, such as a widely experienced bug or security issue. On the other hand, you can be fairly sure that a bundled version has been installed properly, and perhaps it will take only a few simple modifications to your smb.conf file for you to be up and running. Samba is mature enough that you probably don't need the latest release to meet your basic needs, so you might be perfectly happy running a bundled version.

If you choose this option, be aware that your Samba files, including the very important smb.conf, will likely be stored somewhere other than the default locations used by Samba when it has been built from source. For example, with most Linux distributions, smb.conf and some other Samba-related files are in the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Binary Packages

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Samba is so popular with Unix/Linux administrators that many vendors include prepackaged versions in their operating system distributions. There are advantages to using software packages, one of which is that you do not have to bother with the details of compiling the software itself. The main drawback is that you are dependent on the options the vendor chose when building Samba. It is also likely that the server will be slightly behind the current production Samba release, because vendors tend to upgrade packages only when there is a strong reason, such as a widely experienced bug or security issue. On the other hand, you can be fairly sure that a bundled version has been installed properly, and perhaps it will take only a few simple modifications to your smb.conf file for you to be up and running. Samba is mature enough that you probably don't need the latest release to meet your basic needs, so you might be perfectly happy running a bundled version.

If you choose this option, be aware that your Samba files, including the very important smb.conf, will likely be stored somewhere other than the default locations used by Samba when it has been built from source. For example, with most Linux distributions, smb.conf and some other Samba-related files are in the /etc/samba directory. The default location when building from source is /usr/local/samba/lib.

If Samba is already installed on your system, you can check which version you have by using the command:

$ smbd -V
Version 3.0.12

If you receive a message back similar to "command not found," either Samba is not installed or smbd is not in your shell's search path. In the latter case, use the find command to locate the smbd executable.

$ find / -name smbd -print
/opt/samba/sbin/smbd

You might also be able to use a system-specific tool to query a software-package maintenance utility for the location of the Samba programs. On RPM-based systems such as Red Hat Enterprise Linux and Novell's SUSE Linux, you can use the rpm command to query the installed packages for Samba. In this example, Samba has been split between multiple packages.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Compiling from Source

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A typical Samba installation takes about an hour to complete, including downloading the source files and compiling them, setting up the configuration files, and testing the server. Conventionally installing from source is called the ./configure && make && make install process. Here is a complete list of the individual steps:

1. Download the source or binary files.
2. Read the installation documentation.
3. Run the autoconf script that generates the Makefile appropriate for your system.
4. Compile the server and utility programs.
5. Install the server files.
6. Create a Samba configuration file.
7. Test the configuration file.
8. Start the Samba daemons.
9. Test the Samba daemons.

If you would like to download the latest version of the Samba software, the primary web site is http://www.samba.org. Once you connect to this page, you should see a drop-down list of world-wide mirrors. Choose a site that is closest to your own geographic location. The link to the download area is located on the lefthand tool bar that appears on every page on the Samba web site.

The Samba site includes online documentation, links to mailing list archives, and the latest Samba news, as well as source and binary distributions of Samba. Unless you specifically want an older version of the Samba server or are going to install a binary distribution, download the latest source distribution from the closest mirror site. This distribution is always named samba-latest.tar.gz, which for the 3.0.22 release is a 16 MB file.

It is also a good idea to verify the digital signature on the uncompressed tarball to ensure that the version you are downloading is one actually released by the Samba Team. To do this you will need either GnuPG (http://www.gnupg.org) or some other pgp-compatible utility installed on a system. You can verify the tarball's signature on any machine. It does not have to be done on the server used for compiling Samba.

First, download the current Samba public GPG key. Look for a file named samba-pubkey.asc residing in the same directory as the Samba source release tarball. This key should be imported into your

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Compiling and Installing Samba

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

At this point you should be ready to build the Samba executables. Compiling is even easier than configuration: in the source directory, type make on the command line. The make utility will produce a stream of explanatory and success messages, beginning with:

Using FLAGS = -O -Iinclude ...

This build includes all the mentioned Samba client and server binaries. If you encounter a problem when compiling, first check the Samba documentation to see whether it is easily fixable. Another possibility is to search or post to the Samba mailing lists, links to which are given at the end of Chapter 12 and on the Samba home page. Most compilation issues are system-specific and almost always easy to overcome.

Now that the files have been compiled, you can install them in the directories you identified. Make sure to change to the root user before running the following command:

$ make install

If you configured Samba to use the default locations for files, the new files will be installed in the directories listed in Table 2-2.

Table 2-2: Samba installation directories

Directory	Description
/usr/local/samba	Main tree
/usr/local/samba/bin	Client binaries and administartive tools
/usr/local/samba/sbin	Server binaries
/usr/local/samba/lib	smb.conf,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Enabling the Samba Web Administration Tool (SWAT)

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Samba Web Administration Tool (SWAT) provides a forms-based editor in your web browser for creating and modifying Samba's configuration file. It runs as a daemon under inetd or xinetd. For SWAT to work, entries must be added for it in the /etc/services and /etc/inetd.conf (or /etc/xinetd.d/swat) configuration files. To add the entries, follow these three steps:

1. Check your /etc/services file, and add the following line to the end if a line like it does not already appear.

   swat   901/tcp
   

2. If an entry exists and has assigned port 901 to a service other than SWAT, you can select any unused port. However, you will need to adapt any references to port 901 in our examples to your local configuration.
3. Make sure that an inetd-style daemon is running. inetd and xinetd are "Internet super daemons" that handle starting daemons on demand, instead of letting them sit around in memory consuming system resources. Most Unix systems use inetd, but some utilize the more secure xinetd service. Most Linux distribution now use xinetd by default. You can use the ps command to see which of the two your system is running.

For inetd, add a line to the /etc/inetd.conf file. (Check your inetd.conf manual page to see the exact format of the inetd.conf file whether it differs from the following example.) Don't forget to change the path to the SWAT binary if you installed it in a different location from the default /usr/local/samba:

swat   stream  tcp  nowait  root  /usr/local/samba/sbin/swat  swat

Then force inetd to reread its configuration file by sending it a SIGHUP (hangup) signal:

$ kill -HUP -a inetd

Notice that we are using a version of the kill command that supports the -a option, so as to allow us to specify the process by name. On FreeBSD and Linux (but not Solaris), you can use the killall command as follows:

$ killall -HUP inetd

On Solaris up to and including Solaris 9, use the pkill command.

$ pkill -HUP inetd

On Solaris 10 and later, inetd is not used, but there is an automatic conversion program. Enter the configureation details into

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

A Basic Samba Configuration File

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The key to configuring Samba is its configuration file, smb.conf. This configuration file can be very simple or extremely complex, and the rest of this book is devoted to helping you get deeply personal with this file. For now, however, we'll show you how to set up a single file service, which will allow you to fire up the Samba daemons and see that everything is running as it should be. In later chapters, you will see how to configure Samba for more complicated and interesting tasks.

The installation process does not automatically create an smb.conf configuration file, although several example files are included in the Samba distribution in the samba-3.0.x/examples/ directory. To test the server software, we'll use the following file, which you can create in a text editor of your choosing. It should be named smb.conf and placed in the /usr/local/samba/lib directory:

[global]
    workgroup = GARDEN
[test]
    comment = For testing only, please
    path = /export/tmp
    read only = no

This brief configuration file tells the Samba server to offer the /export/tmp directory on the server as an SMB share called test. Parameters in smb.conf are case-insensitive—path is the same option as PATH. They are also whitespace-insensitive so that read only and ReadOnly are interpreted as the same parameter. Values, however, may or may not be case-insensitive, depending on their use. For example, a username or a directory path should be considered to be case-sensitive, yet Samba interprets Boolean value such as yes or no as case-insensitive strings.

Our server will operate as part of the GARDEN workgroup, of which each client should also be a part. If you have already chosen a name for your own workgroup, use the existing name instead of GARDEN in the previous example. In case you are connecting your server to an existing network and need to know the workgroup name, ask another system administrator or go to a Windows system in the workgroup and follow these instructions for Windows 2000/XP/2003:

• Right click on My Computer icon and select Properties.
• The workgroup or domain name should be listed in the windows after selecting the Network Identification (or Computer Name) tab.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Firewall Configuration

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As with any services that run on TCP/IP, the SMB networking services offered by Samba can be accessed from across the Internet unless your organization's firewall is configured to prevent it.

The following ports are used by Samba for SMB networking and SWAT:

137/udp

Used for NetBIOS network browsing (nmbd).

138/udp

Used for NetBIOS name service (nmbd).

139/tcp

Used for file and printer sharing and other operations (smbd).

445/tcp

The so called NetBIOS-less CIFS port, which is used by Windows 2000 and later clients (smbd).

901/tcp

Used by SWAT. Unless you have configured complementary stunnel support, it is best to limit access to this port to the loopback interface only.

As stated in Chapter 1, SMB/CIFS is really not Internet-ready. There have been many security improvements in CIFS recently, including the use of Kerberos for authentication, packet integrity check (SMB signing), and Secure Channel communication. However, other than passwords, most data in CIFS networks travels in the clear. If your users require external access to Samba or Windows file servers, it is best to use some type of a Virtual Private Network to secure data in transit. See the O'Reilly book Virtual Private Networks, by Charlie Scott et al., for more information on this subject.

Outside of a VPN solution, it is strongly advised that you block the appropriate ports from access by clients external to your network. In addition, you might wish to configure a firewall on the Samba host system to keep SMB packets from traveling further than necessary within your organization's network. For example, port 901 can be shut down for remote accesses so that SWAT can be run only on the Samba host system. If you are using Samba to serve only a fraction of the client systems within your organization, consider allowing SMB packets (i.e., packets on ports 137–139 and 445) to go to or come from only those clients. For more information on configuring firewalls, see

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Starting the Samba Daemons

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Two Samba processes, smbd and nmbd, need to be running for Samba to work correctly. There are three ways to start them:

• Manually
• Automatically, during system boot
• From inetd or xinetd

If you're in a hurry, you can start the Samba daemons by hand. As root, enter the following commands:

$ /usr/local/samba/sbin/smbd -D
$ /usr/local/samba/sbin/nmbd -D

Samba will now be running on your system and is ready to accept connections. However, keep in mind that if either of the daemons exit for any reason (including system reboots), they must be restarted manually.

To have the Samba daemons started automatically when the system boots, add the commands listed in the previous section to your standard Unix startup scripts. The exact method varies depending on the flavor of Unix you're using.

Section 2.7.2.1: BSD Unix

With a BSD-style Unix variant, append the following code to the rc.local file, which is typically found in the /etc or /etc/rc.d directories:

if [ -x /usr/local/samba/bin/smbd]; then
    echo "Starting smbd..."
    /usr/local/samba/bin/smbd -D
    echo "Starting nmbd..."
    /usr/local/samba/bin/nmbd -D
fi

This code is very simple: it checks to see whether the smbd file exists and has execute permissions, and if so, starts up both of the Samba daemons.

Section 2.7.2.2: System V Unix and most Linux distributions

With System V, things can get a little more complex. Depending on your Unix version, you might be able to get away with making a simple change to an rc.local file as with BSD Unix, but System V typically uses directories containing links to scripts that control daemons on the system. Hence, you need to instruct the system how to start and stop the Samba daemons. The first step to implement this is to modify the contents of the /etc/rc.d/init.d directory by adding an init script. The samba-3.0.x/packaging/sysv directory contains an example init script that should work on most System V based hosts. It is at least a place to begin making any local tweaks necessary for your system.

Assuming that we have installed this script using the name

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 3: Configuring Windows Clients

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Samba's main philosophy is that it is better to teach the server to speak the client's language than the other way around. Past experiences with client software such as PC-NFS have led many network administrators to share this belief. SMB/CIFS is the protocol of choice for resource sharing in Windows networks. The advantage of using the Windows' native CIFS support is that it is no longer your responsibility to verify that third-party client networking software is compatible with the latest hotfix or service pack from Microsoft. The CIFS client software updates are included with the OS upgrades.

The dominance of CIFS in Microsoft networks means that the components necessary for connecting to a Samba host are usually present in default Windows installations. There was a time many Windows releases ago (such as with Windows for Workgroups) when TCP/IP network stacks were hard to find and install. Such instances still exist, but are thankfully rare.

This chapter is devoted to helping you understand the pieces necessary for the latest Microsoft operating systems to communicate with Samba servers. Its intent is not to act as a Windows troubleshooting guide or to provide an in-depth look at Windows networking. By the end of our discussion, however, you will be comfortable verifying that the necessary networking protocols and services are installed and functioning properly. If you are already comfortable with configuring Windows clients to access Microsoft servers, it is safe to skim this chapter and move on to the next.

The dialog boxes and screenshots that you will see throughout this chapter are taken from a Windows XP client. All of the concepts and terminology, however, apply to Windows 2000, Windows XP, and Windows Server 2003 hosts. Microsoft has come a long way in consolidating the user interface between releases. but each one does possess a few nuances, which are highlighted as we continue our discussion.

Windows is different from Unix in many ways, including how it supports networking. Before we get into the hands-on task of clicking our way through the configuration dialog boxes, it is best to establish a common foundation of networking technologies and concepts that apply to the entire family of Windows operating systems.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Windows Networking Concepts

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Windows is different from Unix in many ways, including how it supports networking. Before we get into the hands-on task of clicking our way through the configuration dialog boxes, it is best to establish a common foundation of networking technologies and concepts that apply to the entire family of Windows operating systems.

These are the main client issues with which we will be dealing:

• Ensuring that the required networking components are installed and bound to a working network adapter
• Configuring TCP/IP networking with a valid IP address, netmask, and gateway, and with any appropriate WINS and DNS name servers
• Assigning workgroup and computer names
• Creating user accounts

One can spend a lifetime understanding the ways in which Unix is different from Windows (in fact, Samba developers do just this), or the ways in which members of the Windows family are different from each other in underlying technology, behavior, or appearance. For now let's just focus on their similarities and determine any common ground.

Unix systems historically have been monolithic in nature, requiring recompilation or relinking to create a kernel with a customized feature set. Modern versions, however, have the ability to load or unload device drivers or various other operating-system features as modules while the system is running, without requiring a reboot. Windows allows for such configuration by installing or uninstalling components. Networking components can be one of three things:

• Protocols
• Clients
• Services

Figure 3-1 illustrates how these components work in conjunction with each other. The client and server components are distinct pieces that communicate with each other in the same fashion whether both exist on the same machine or reside on different machines in a network. Practically, the distinction is not so clean-cut, but in the abstract, this model still holds.

Figure 3-1: An overview of the Microsoft networking puzzle

Chapter 1 described how SMB/CIFS rests on top of a set of network services and explained that these services have been historically provided by a variety of protocols, such as NetBEUI, IPX/SPX, and NBT. Samba, however, supports only TCP/IP services, even through it does implement a NetBIOS layer internally. Field experience has proven that Windows clients accessing SMB/CIFS servers perform better when only one network protocol is installed.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Windows Setup

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before a Windows client can connect to a Samba server or other any CIFS server, a few network components must be configured. Despite a few cosmetic differences, the Windows networking management interface is much more consistent these days than in times past. The terms and information in the remainder of this chapter apply to Windows 2000 and later. However, the screenshots are taken from a Windows XP client.

Before beginning to configure the Windows system, ensure that you are logged onto the client using an account that has the level of privilege necessary to make any networking changes. The built-in Administrator account will work fine, but any member of the Administrators group should have sufficient authority to update the client's configuration.

First locate the Control Panel. Depending on what version of Windows or what desktop theme is currently selected, this item may or may not be found in the Start menu (or Settings submenu). If you cannot find an icon for the Control Panel, you can start the application b