Section 2.2. Compiling from Source
2.2. Compiling from SourceA 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:
2.2.1. Downloading the Source DistributionIf 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 pgp keyring by executing: $ gpg --import samba-pubkey.asc gpg: key F17F9772: public key "Samba Distribution Verification Key <samba-bugs@samba.org>" imported gpg: Total number processed: 1 gpg: imported: 1 ...
Now you can verify the integrity of the source tarball by uncompressing it and asking gpg to verify the signature file (samba-latest.tar.asc). $ gunzip samba-latest.tar.gz $ gpg --verify samba-latest.tar.asc gpg: Signature made Thu 14 Apr 2005 01:23:58 AM CDT using DSA key ID F17F9772 gpg: Good signature from "Samba Distribution Verification Key <samba-bugs@samba.org>" Now you are ready to extract the files from the tar archive. While the following tar command runs, it prints out a list of the files it installs: $ tar xvf samba-latest.tar The archive creates a single directory named samba-VERSION (where VERSION is the current release number, such as 3.0.22). This directory contains all of the source files, documentation, packaging files, and examples included in the distribution. 2.2.2. Read the DocumentationIn the top-level directory that you just created, a file named WHATSNEW.txt contains the latest news about the release. If you are upgrading, you can find important information in this file about bug fixes or configuration parameters that have been added or are no longer supported. With both source and binary packages, you'll find a large number of documents in the docs directory, in a variety of formats. Samba documentation has improved substancially over the years. There are currently three full-length books, one of which is the one you are currently reading, included in this directory. You'll have plenty of time to browse this collection while Samba is compiling. 2.2.3. Configuring SambaThe source distribution of Samba 3.0 doesn't initially have a makefile. Instead, one is generated through a GNU Autoconf script, which is located in the samba-3.0.x/source/ directory. The configure script takes care of the machine-specific issues of building Samba, such as which libraries are needed, what's the maximum value that can be stored in a integer, and how to automatically determine the available network interfaces on a system. The configure script also allows you to enable or disable specific features in Samba (more on this task shortly). When configure runs, it prints messages telling what it is doing, and error messages might be mixed in. To make sure that you see those very important error messages, it is helpful to run configure with its standard output passed through some filter to capture the output and keep it from scrolling out of sight. For example: $ ./configure | more Although executing configure with no options generates a working set of binaries, you might want to add support for extra features by passing options on the command line. Each option enables or disables various features. You typically enable a feature by specifying the --with-feature option, which causes the feature to be compiled and installed. Likewise, if you specify a --without-feature option, the feature will be disabled. Note that options to the configure script start with two hyphens. The following command instructs configure to test for Pluggable Authentication Module (PAM) support on the build host: $ ./configure --with-pam We'll discuss Samba PAM integration when we examine users and passwords in Chapter 5. If you would like a complete list of options, type the following: $ ./configure --help The full list of configuration options is reproduced in Appendix C. Here is a brief list of some of the most popular features, which are covered later in this book:
Each option is set to a default that is appropriate for most systems, and none of the features are essential to basic Samba installations. However, you may want to include them in your configuration (as we will in our example) at least to be able to try out the options in later chapters. In addition, Table 2-1 shows some other parameters that you can give the configure script if you wish to store parts of the Samba distribution in different places, perhaps to make use of multiple disks or partitions. Note that the defaults sometimes refer to a prefix specified earlier in the table. In other words, if you set the --prefix option to /opt/samba, the default bindir becomes /opt/samb/bin.
Here is one example of a possible directory layout when building Samba from scratch: $ ./configure --prefix=/opt/samba \ --localstatedir=/var/lib/samba \ --with-piddir=/var/run \ --with-logfilebase=/var/log/samba \ --with-privatedir=/etc/samba/private \ --with-configdir=/etc/samba \ --with-lockdir=/var/lib/samba This layout results in the following set of directories after installing the binaries and files created from the compilation process:
This type of installation makes it easy to share a build via NFS while storing the local configuration information on a local filesystem. Feel free to add on any additional feature flags (e.g., --with-acl-support) that you think would be useful.
Here is a sample execution of the configure script, which creates a Samba 3.0.22 makefile for the Linux platform: $ cd samba-3.0.22/source/ $ ./configure --prefix=/usr/samba --with-smbmount \ --with-syslog 2>&1 | more SAMBA VERSION: 3.0.22 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes ...(content omitted)... Using libraries: LIBS = -lcrypt -lresolv -lnsl -ldl KRB5_LIBS = -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err LDAP_LIBS = -lldap -llber AUTH_LIBS = -lcrypt In general, any message from configure that doesn't begin with the words checking or creating is an error. If there was an error during configuration, more detailed information about it can be found in the config.log file, which is written to the local directory by the configure script. If the configuration works, you'll see a checking configure summary message in the output on the screen followed by a yes message and four or five file-creation messages: checking configure summary... yes configure: creating ./config.status config.status: creating include/stamp-h config.status: creating Makefile config.status: creating script/findsmb config.status: creating smbadduser config.status: creating script/gen-8bit-gap.sh config.status: creating include/config.h So far, so good. 2.2.4. Kerberos and LDAPIn order to integrate with Active Directory using the Kerberos and LDAP protocols, Samba relies upon third-party libraries such as those provided by MIT, Heimdal, and OpenLDAP. However, the introduction of these build dependencies can complicate the previous simple ./configure && make && make install steps. Microsoft introduced a new Kerberos encryption type when initially creating Active Directory. The reason for this new algorithm (RC4-HMAC-MD5) was to enable smooth upgrades from Windows NT 4.0 domains by using existing account passwords as the basis for generating the new long-term secrets keys in the AD Kerberos realm. However, earlier versions of both the MIT and Heimdal Kerberos libraries did not support this new encryption type (type 23) and were forced to rely on DES keys. Things have since improved, and both the major open source Kerberos players have RC4-HMAC (sometimes called ARCFOUR-HMAC) support now. Samba's configure script will attempt to locate a working set of Kerberos client libraries. Be aware that just because Kerberos is included with the operating system (e.g., Solaris) does not necessarily mean it is a usable installation. The script will ignore any unusable Kerberos libraries. Thus, unless you are paying attention, it is quite possible to end up with a set of binaries that don't allow you to run the Samba's newer ADS security mode. To decide whether you have to install a Kerberos client distribution, consider the following to be the bare minimum for interoperating with Active Directory:
It is possible to use releases older than these, but things get slightly more complicated when it comes time to configure Samba (as you will see in Chapter 10). A good source of information (compilation, installation, and management) covering both Kerberos distributions as well as Active Directory is Kerberos: The Definitive Guide, by Jason Garman (O'Reilly). Once the Kerberos piece is set, we have to deal with the LDAP dependency as well. Currently, Samba supports only the OpenLDAP distribution for AD integration. Any OpenLDAP 2.x release should work, but experience has shown that the latest stable release is generally best. Note that Samba requires only the client libraries, so there is no need to compile or install the OpenLDAP server or server related tools. More information on OpenLDAP can be found at http://www.openldap.org or in LDAP System Administration, by Gerald Carter (O'Reilly). One final note is that when using third-party libraries such as the Kerberos or LDAP ones mentioned here, you should also ensure that once installed, the libraries can be located by dependent applications such as Samba. There are two primary means of achieving this. One method is to add the directory (e.g., /opt/openldap/lib) to the global library search path. On some platforms, this can be done at run time by appending the new directory to the LD_LIBRARY_PATH search list. # export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/openldap/lib Other, more permanent solutions, differ from platform to platform. For example, Linux's /etc/ld.so.conf file and Solaris' crle tool have already been mentioned. The other solution is to encode the library search path in the binary itself during the compilation process, usually done by instructing the compiler to pass additional flags onto the linker. The following script shows how this would be done if Heimdal Kerberos were installed in /opt/heimdal and OpenLDAP were installed in /opt/openldap: #!/bin/sh CC="gcc" CFLAGS="" CPPFLAGS="" LDFLAGS="" DIRPATH="/opt/heimdal /opt/openldap" for dir in $DIRPATH ; do CPPFLAGS="$CPPFLAGS -I$dir/include" CFLAGS="$CFLAGS -Wl,-rpath,$dir/lib" LDFLAGS="$LDFLAGS -L$dir/lib" done export CPPFLAGS CFLAGS LDFLAGS CC The resulting $CPPFLAGS variable (used by the C preprocessor) would be: -I/opt/heimdal/include -I/opt/openldap/include The $CFLAGS variable (used by the compiler) would appear as: -Wl,-rpath,/opt/heimdal/lib -Wl,-rpath,/opt/openldap/lib and the linker flags ($LDFLAGS) would be: -L/opt/heimdal/lib -L/opt/openldap/lib Other compilers and linkers besides gcc (e.g., the Sun C compiler), may use the -Rdir flag for encoding library search paths rather than -Wl,-rpath,dir. Check the compiler documention to be sure. Once these variables are set, we can run configure followed by make and we should end up with an AD-enabled version of Samba. If you want to verify that the resulting smbd binary does in fact include AD support, use the -b flag again and this time grep for WITH_ADS : $ smbd -b | grep ADS WITH_ADS 2.2.5. Unicode and the iconv LibraryInternally, Samba uses Unicode when communicating with Unicode-aware clients such as Windows NT and later clients. There are times when these Unicode strings must be converted to a locale encoding (a non-Unicode collection of language, country, and cultural information), such as when writing a filename to disk or displaying a username. When possible, Samba utilizes the GNU iconv library, available from http://www.gnu.org/software/libiconv, to handle these translations. Some Unix variants, such as FreeBSD and Linux, come with a suitable iconv library installed. But some variantsSolaris being the most notabledo not have sufficient support in the included iconv implementation for Samba's purposes. There are two codepages that can be handled independently of iconv: the European CP850 and CP437 character sets. Therefore, these character sets work on systems that lack the necessary iconv. However, if your server will be supporting characters outside the standard English ASCII character set, it is best to verify that your server has a working iconv installation. |
EAN: 2147483647
Pages: 135