Table of Contents
You can obtain the Samba source from the
Samba is developed in an open environment. Developers use Concurrent Versioning System (CVS) to “checkin” (also known as “commit”) new source code. Samba's various CVS branches can be accessed via anonymous CVS using the instructions detailed in this chapter.
This chapter is a modified version of the instructions found at
The machine samba.org runs a publicly accessible CVS repository for access to the source code of several packages, including Samba, rsync, distcc, ccache, and jitterbug. There are two main ways of accessing the CVS server on this host:
You can access the source code via your favorite WWW browser. This allows you to access the contents of individual files in the repository and also to look at the revision history and commit logs of individual files. You can also ask for a diff listing between any two versions on the repository.
Use the URL:
You can also access the source code via a normal CVS client. This gives you much more control over what you can do with the repository and allows you to checkout whole source trees and keep them up-to-date via normal CVS commands. This is the preferred method of access if you are a developer and not just a casual browser.
To download the latest CVS source code, point your
browser at the URL :
To gain access via anonymous CVS, use the following steps. For this example it is assumed that you want a copy of the Samba source code. For the other source code repositories on this system just substitute the correct package name.
Procedure 36.1. Retrieving Samba using CVS
Install a recent copy of CVS. All you really need is a copy of the CVS client binary.
Run the command:
cvs -d :pserver:cvs@samba.org:/cvsroot login
When it asks you for a password, type cvs.
Run the command
cvs -d :pserver:CVS@samba.org:/cvsroot co samba.
This will create a directory called samba containing the latest Samba source code (i.e., the HEAD tagged CVS branch). This currently corresponds to the 3.0 development tree.
CVS branches other then HEAD can be obtained by using the -r and defining a tag name. A list of branch tag names can be found on the “Development” page of the Samba Web site. A common request is to obtain the latest 3.0 release code. This could be done by using the following command:
cvs -d :pserver:cvs@samba.org:/cvsroot co -r SAMBA_3_0 samba.
Whenever you want to merge in the latest code changes, use the following command from within the Samba directory:
cvs update -d -P
pserver.samba.org also exports unpacked copies of most parts of the CVS
tree at
The disadvantage of the unpacked trees is that they do not support automatic merging of local changes like CVS does. rsync access is most convenient for an initial install.
It is strongly recommended that you verify the PGP signature for any source file before installing it. Even if you're not downloading from a mirror site, verifying PGP signatures should be a standard reflex. Many people today use the GNU GPG toolset in place of PGP. GPG can substitute for PGP.
With that said, go ahead and download the following files:
$ wget http://us1.samba.org/samba/ftp/samba-2.2.8a.tar.asc $ wget http://us1.samba.org/samba/ftp/samba-pubkey.asc
The first file is the PGP signature for the Samba source file; the other is the Samba public PGP key itself. Import the public PGP key with:
$ gpg --import samba-pubkey.asc
and verify the Samba source code integrity with:
$ gzip -d samba-2.2.8a.tar.gz $ gpg --verify samba-2.2.8a.tar.asc
If you receive a message like, “Good signature from Samba Distribution Verification Key...” then all is well. The warnings about trust relationships can be ignored. An example of what you would not want to see would be:
gpg: BAD signature from “Samba Distribution Verification Key”
To build the binaries, first run the program ./configure in the source directory. This should automatically configure Samba for your operating system. If you have unusual needs, then you may wish to run
root# ./configure --help
first to see what special options you can enable. Now execute ./configure with any arguments it might need:
root# ./configure [... arguments ...]
Executing
root# make
will create the binaries. Once it is successfully compiled you can use
root# make install
to install the binaries and manual pages. You can separately install the binaries and/or man pages using
root# make installbin
and
root# make installman
Note that if you are upgrading from a previous version of Samba you might like to know that the old versions of the binaries will be renamed with an “.old” extension. You can go back to the previous version with
root# make revert
if you find this version a disaster!
In order to compile Samba with ADS support, you need to have installed on your system:
The MIT or Heimdal kerberos development libraries (either install from the sources or use a package).
The OpenLDAP development libraries.
If your kerberos libraries are in a non-standard location, then remember to add the configure option --with-krb5=DIR.
After you run configure, make sure that include/config.h it generates contain lines like this:
#define HAVE_KRB5 1 #define HAVE_LDAP 1
If it does not, configure did not find your KRB5 libraries or your LDAP libraries. Look in config.log to figure out why and fix it.
On Debian, you need to install the following packages:
On Red Hat Linux, this means you should have at least:
in addition to the standard development environment.
If these files are not installed on your system, you should check the installation CDs to find which has them and install the files using your tool of choice. If in doubt about what tool to use, refer to the Red Hat Linux documentation.
SuSE Linux installs Heimdal packages that may be required to allow you to build binary packages. You should verify that the development libraries have been installed on your system.
SuSE Linux Samba RPMs support Kerberos. Please refer to the documentation for your SuSE Linux system for information regading SuSE Linux specific configuration. Additionally, SuSE are very active in the maintenance of Samba packages that provide the maximum capabilities that are available. You should consider using SuSE provided packages where they are available.
You must choose to start smbd and nmbd either as daemons or from inetd. Don't try to do both! Either you can put them in inetd.conf and have them started on demand by inetd or xinetd, or you can start them as daemons either from the command line or in /etc/rc.local. See the man pages for details on the command line options. Take particular care to read the bit about what user you need to have to start Samba. In many cases, you must be root.
The main advantage of starting smbd and nmbd using the recommended daemon method is that they will respond slightly more quickly to an initial connection request.
The following will be different if you use NIS, NIS+ or LDAP to distribute services maps.
Look at your /etc/services. What is defined at port 139/tcp? If nothing is defined, then add a line like this:
netbios-ssn 139/tcp
Similarly for 137/udp, you should have an entry like:
netbios-ns 137/udp
Next, edit your /etc/inetd.conf and add two lines like this:
netbios-ssn stream tcp nowait root /usr/local/samba/bin/smbd smbd netbios-ns dgram udp wait root /usr/local/samba/bin/nmbd nmbd
The exact syntax of /etc/inetd.conf varies between UNIXes. Look at the other entries in inetd.conf for a guide.
Some distributions use xinetd instead of inetd. Consult the xinetd manual for configuration information.
Some UNIXes already have entries like netbios_ns (note the underscore) in /etc/services. You must edit /etc/services or /etc/inetd.conf to make them consistent.
On many systems you may need to use the interfaces option in smb.conf to specify the IP address and netmask of your interfaces. Run ifconfig as root if you do not know what the broadcast is for your net. nmbd tries to determine it at run time, but fails on some UNIXes.
Many UNIXes only accept around five parameters on the command line in inetd.conf. This means you shouldn't use spaces between the options and arguments, or you should use a script and start the script from inetd.
Restart inetd, perhaps just send it a HUP.
root# killall -HUP inetd
To start the server as a daemon, you should create a script something like this one, perhaps calling it startsmb.
#!/bin/sh /usr/local/samba/bin/smbd -D /usr/local/samba/bin/nmbd -D
Make it executable with chmod +x startsmb
You can then run startsmb by hand or execute it from /etc/rc.local.
To kill it, send a kill signal to the processes nmbd and smbd.
If you use the SVR4 style init system, you may like to look at the examples/svr4-startup script to make Samba fit into that system.