--- /dev/null
+%%
+%%
+
+\chapter{Installing Bacula}
+\label{InstallChapter}
+\index[general]{Bacula!Installing}
+\index[general]{Installing Bacula}
+
+In general, you will need the Bacula source release, and if you want to run
+a Windows client, you will need the Bacula Windows binary release.
+However, Bacula needs certain third party packages (such as {\bf MySQL},
+{\bf PostgreSQL}, or {\bf SQLite} to build and run
+properly depending on the
+options you specify. Normally, {\bf MySQL} and {\bf PostgreSQL} are
+packages that can be installed on your distribution. However, if you do
+not have them, to simplify your task, we have combined a number of these
+packages into three {\bf depkgs} releases (Dependency Packages). This can
+vastly simplify your life by providing you with all the necessary packages
+rather than requiring you to find them on the Web, load them, and install
+them.
+
+\section{Source Release Files}
+\index[general]{Source Files}
+\index[general]{Release Files}
+ Beginning with Bacula 1.38.0, the source code has been broken into
+ four separate tar files each corresponding to a different module in
+ the Bacula SVN. The released files are:
+
+\begin{description}
+\item [bacula-3.0.3.tar.gz]
+ This is the primary source code release for Bacula. On each
+ release the version number (3.0.3) will be updated.
+
+\item [bacula-docs-3.0.3.tar.gz]
+ This file contains a copy of the docs directory with the
+ documents prebuild. English HTML directory, single HTML
+ file, and pdf file. The French and German translations
+ are in progress, but are not built.
+
+\item [bacula-gui-3.0.3.tar.gz]
+ This file contains the non-core GUI programs. Currently,
+ it contains bacula-web, a PHP program for producing management
+ viewing of your Bacula job status in a browser; and bimagemgr
+ a browser program for burning CDROM images with Bacula Volumes.
+
+\item [bacula-rescue-3.0.3.tar.gz]
+ This is the Bacula Rescue CDROM code. Note, the version number
+ of this package is not tied to the Bacula release version, so
+ it will be different. Using this code, you can burn a CDROM
+ with your system configuration and containing a statically
+ linked version of the File daemon. This can permit you to easily
+ repartition and reformat your hard disks and reload your
+ system with Bacula in the case of a hard disk failure.
+ Unfortunately this rescue disk does not properly boot for
+ all Linux distributions. The problem is that the boot procedure
+ can vary significantly between distributions, and even within
+ a distribution, they are a moving target.
+
+ This package evolves slower than the Bacula source code,
+ so there may not always be a new release of the rescue package when
+ making minor updates to the Bacula code. For example, when releasing
+ Bacula version 3.0.3, the rescue package may still be at a prior
+ version if there were no updates.
+
+\item [winbacula-3.0.3.exe]
+ This file is the 32 bit Windows installer for installing
+ the Windows client (File daemon) on a Windows machine.
+ This client will also run on 64 bit Windows machines.
+ Beginning with Bacula version 1.39.20, this executable will
+ also optionally load the Win32 Director and the Win32
+ Storage daemon.
+
+\item [win64bacula-3.0.3.exe]
+ This file is the 64 bit Windows installer for installing
+ the Windows client (File daemon) on a Windows machine.
+ This client will only run on 64 bit Windows OS machines.
+ It will not run on 32 bit machines or 32 bit Windows OSes.
+ The win64bacula release is necessary for Volume Shadow
+ Copy (VSS) to work on Win64 OSes. This installer
+ installs only the FD, the Director and Storage daemon
+ are not included.
+
+\end{description}
+
+\label{upgrading1}
+\section{Upgrading Bacula}
+\index[general]{Bacula!Upgrading}
+\index[general]{Upgrading Bacula}
+\index[general]{Upgrading}
+
+If you are upgrading from one Bacula version to another, you should first
+carefully read the ReleaseNotes of all major versions between your current
+version and the version to which you are upgrading. In many upgrades,
+especially for minor patch upgrades (e.g. between 3.0.0 and 3.0.1) there
+will be no database upgrade, and hence the process is rather simple.
+
+With version 3.0.0 and later, you {\bf must} ensure that on any one
+machine that all components of Bacula are running on exactly the
+same version. Prior to version 3.0.0, it was possible to run a
+lower level FD with a newer Director and SD. This is no longer the
+case.
+
+As always, we attempt to support older File daemons. This avoids the
+need to do a simultaneous upgrade of many machines. For exactly what
+older versions of the FD are supported, please see the ReleaseNotes
+for the new version. In any case, you must always upgrade both the
+Director and the Storage daemon at the same time, and you must also
+upgrade any File daemon that is running on the same machine as a Director
+or a Storage daemon (see the prior paragraph).
+
+If the Bacula catalog
+database has been upgraded (as it is almost every major release), you will
+either need to reinitialize your database starting from scratch (not
+normally a good idea), or save an ASCII copy of your database, then proceed
+to upgrade it. If you are upgrading two major versions (e.g. 1.36 to 2.0)
+then life will be more complicated because you must do two database
+upgrades. See below for more on this.
+
+Upgrading the catalog is normally done after Bacula is build and installed
+by:
+
+\begin{verbatim}
+cd <installed-scripts-dir> (default /etc/bacula)
+./update_bacula_tables
+\end{verbatim}
+
+This update script can also be find in the Bacula source src/cats
+directory.
+
+If there are several database upgrades between your version and the
+version to which you are upgrading, you will need to apply each database
+upgrade script. For your convenience, you can find all the old upgrade scripts
+in the {\bf upgradedb} directory of the source code. You will need to edit the
+scripts to correspond to your system configuration. The final upgrade script,
+if any, can be applied as noted above.
+
+If you are upgrading from one major version to another, you will need to
+replace all your components at the same time as generally the inter-daemon
+protocol will change. However, within any particular release (e.g. version
+1.32.x) unless there is an oversight or bug, the daemon protocol will not
+change. If this is confusing, simply read the ReleaseNotes very carefully as
+they will note if all daemons must be upgraded at the same time.
+
+Finally, please note that in general it is not necessary or desirable
+to do a {\bf make uninstall} before doing an upgrade providing you are careful
+not to change the installation directories. In fact, if you do so, you will
+most likely delete all your conf files, which could be disastrous.
+The normal procedure during an upgrade is simply:
+
+\begin{verbatim}
+./configure (your options)
+make
+make install
+\end{verbatim}
+
+In general none of your existing .conf or .sql files will be overwritten,
+and you must do both the {\bf make} and {\bf make install} commands, a
+{\bf make install} without the preceding {\bf make} will not work.
+
+For additional information on upgrading, please see the \ilink{Upgrading Bacula
+Versions}{upgrading} in the Tips chapter of this manual.
+
+\section{Releases Numbering}
+\index[general]{Release Numbering}
+\index[general]{Version Numbering}
+Every Bacula release whether beta or production has a different number
+as well as the date of the release build. The numbering system follows
+traditional Open Source conventions in that it is of the form.
+
+\begin{verbatim}
+major.minor.release
+\end{verbatim}
+
+For example:
+\begin{verbatim}
+1.38.11
+\end{verbatim}
+
+where each component (major, minor, patch) is a number.
+The major number is currently 1 and normally does not change
+very frequently. The minor number starts at 0 and increases
+each for each production release by 2 (i.e. it is always an
+even number for a production release), and the patch number is
+starts at zero each time the minor number changes. The patch
+number is increased each time a bug fix (or fixes) is released
+to production.
+
+So, as of this date (10 September 2006), the current production Bacula
+release is version 1.38.11. If there are bug fixes, the next release
+will be 1.38.12 (i.e. the patch number has increased by one).
+
+For all patch releases where the minor version number does not change,
+the database and all the daemons will be compatible. That means that
+you can safely run a 1.38.0 Director with a 1.38.11 Client. Of course,
+in this case, the Director may have bugs that are not fixed. Generally,
+within a minor release (some minor releases are not so minor), all
+patch numbers are officially released to production. This means that while
+the current Bacula version is 1.38.11, versions 1.38.0, 1.38.1, ... 1.38.10
+have all been previously released.
+
+When the minor number is odd, it indicates that the package is under
+development and thus may not be stable. For example, while the current
+production release of Bacula is currently 1.38.11, the current development
+version is 1.39.22. All patch versions of the development code are
+available in the SVN (source repository). However, not all patch versions
+of the development code (odd minor version) are officially released. When
+they are released, they are released as beta versions (see below for a
+definition of what beta means for Bacula releases).
+
+In general when the minor number increases from one production release
+to the next (i.e. 1.38.x to 1.40.0), the catalog database must be upgraded,
+the Director and Storage daemon must always be on the same minor release
+number, and often (not always), the Clients must also be on the same minor
+release. As often as possible, we attempt to make new releases that are
+downwards compatible with prior clients, but this is not always possible.
+You must check the release notes. In general, you will have fewer problems
+if you always run all the components on the same minor version number (i.e.
+all either 1.38.x or 1.40.x but not mixed).
+
+
+\label{BetaReleases}
+\section*{Beta Releases}
+\index[general]{Beta Releases}
+Towards the end of the development cycle, which typically runs
+one year from a major release to another, there will be several beta
+releases of the development code prior to a production release.
+As noted above, beta versions always have odd minor version numbers
+(e.g 1.37.x or 1.39.x).
+The purpose of the beta releases is to allow early adopter users to test
+the new code. Beta releases are made with the following considerations:
+
+\begin{itemize}
+\item The code passes the regression testing on FreeBSD, Linux, and Solaris
+ machines.
+
+\item There are no known major bugs, or on the rare occasion that
+ there are, they will be documented or already in the bugs database.
+
+\item Some of the new code/features may not yet be tested.
+
+\item Bugs are expected to be found, especially in the new
+ code before the final production release.
+
+\item The code will have been run in production in at least one small
+ site (mine).
+
+\item The Win32 client will have been run in production at least
+ one night at that small site.
+
+\item The documentation in the manual is unlikely to be complete especially
+ for the new features, and the Release Notes may not be fully
+ organized.
+
+\item Beta code is not generally recommended for everyone, but
+ rather for early adopters.
+\end{itemize}
+
+
+\label{Dependency}
+\section{Dependency Packages}
+\index[general]{Dependency Packages}
+\index[general]{Packages!Dependency}
+
+As discussed above, we have combined a number of third party packages that
+Bacula might need into the {\bf depkgs} release. You can,
+of course, get the latest packages from the original authors or
+from your operating system supplier. The locations of
+where we obtained the packages are in the README file in each package.
+However, be aware that the packages in the depkgs files have been tested by us
+for compatibility with Bacula.
+
+Typically, a dependency package will be named {\bf depkgs-ddMMMyy.tar.gz}
+where {\bf dd} is the day we release it, {\bf MMM}
+is the abbreviated month (e.g. Jan), and {\bf yy} is the year. An actual
+example is: {\bf depkgs-24Jul09.tar.gz}. To install and build this package (if
+needed), you do the following:
+
+\begin{enumerate}
+\item Create a {\bf bacula} directory, into which you will place both the
+ Bacula source as well as the dependency package.
+\item Detar the {\bf depkgs} into the {\bf bacula} directory.
+\item cd bacula/depkgs
+\item make
+\end{enumerate}
+
+Although the exact composition of the dependency packages may change from time
+to time, the current makeup is the following:
+
+\addcontentsline{lot}{table}{Dependency Packages}
+\begin{longtable}{|l|l|l|}
+ \hline
+\multicolumn{1}{|c| }{\bf 3rd Party Package} & \multicolumn{1}{c| }{\bf depkgs}
+ & \multicolumn{1}{c| }{\bf depkgs-qt} \\
+ \hline {SQLite3 } & \multicolumn{1}{c| }{X } & \multicolumn{1}{c| }{ }\\
+ \hline {mtx } & \multicolumn{1}{c| }{X } & \multicolumn{1}{c| }{ } \\
+ \hline {qt4 } & \multicolumn{1}{c| }{ } & \multicolumn{1}{c| }{X } \\
+ \hline
+\end{longtable}
+
+Note, some of these packages are quite large, so that building them can be a
+bit time consuming. The above instructions will build all the packages
+contained in the directory. However, when building Bacula, it will take only
+those pieces that it actually needs.
+
+Alternatively, you can make just the packages that are needed. For example,
+
+\footnotesize
+\begin{verbatim}
+cd bacula/depkgs
+make sqlite
+\end{verbatim}
+\normalsize
+
+will configure and build only the SQLite package.
+
+You should build the packages that you will require in {\bf depkgs} a
+prior to configuring and building Bacula, since Bacula will need
+them during the build process.
+
+For more information on the {\bf depkgs-qt} package, please read the
+INSTALL file in the main directory of that package. If you are going to
+build Qt4 using {\bf depkgs-qt}, you must source the {\bf qt4-paths} file
+included in the package prior to building Bacula. Please read the INSTALL
+file for more details.
+
+Even if you do not use SQLite, you might find it worthwhile to build {\bf mtx}
+because the {\bf tapeinfo} program that comes with it can often provide you
+with valuable information about your SCSI tape drive (e.g. compression,
+min/max block sizes, ...). Note, most distros provide {\bf mtx} as part of
+their release.
+
+The {\bf depkgs1} package is depreciated and previously contained
+readline, which should be available on all operating systems.
+
+The {\bf depkgs-win32} package is deprecated and no longer used in
+Bacula version 1.39.x and later. It was previously used to build
+the native Win32 client program, but this program is now built on Linux
+systems using cross-compiling. All the tools and third party libraries
+are automatically downloaded by executing the appropriate scripts. See
+src/win32/README.mingw32 for more details.
+
+\section{Supported Operating Systems}
+\label{Systems}
+\index[general]{Systems!Supported Operating}
+\index[general]{Supported Operating Systems}
+
+Please see the
+\ilink{ Supported Operating Systems}{SupportedOSes} section
+of the QuickStart chapter of this manual.
+
+\section{Building Bacula from Source}
+\label{Building}
+\index[general]{Source!Building Bacula from}
+\index[general]{Building Bacula from Source}
+
+The basic installation is rather simple.
+
+\begin{enumerate}
+\item Install and build any {\bf depkgs} as noted above. This
+ should be unnecessary on most modern Operating Systems.
+
+\item Configure and install MySQL or PostgreSQL (if desired).
+ \ilink{Installing and Configuring MySQL Phase I}{MySqlChapter} or
+ \ilink{Installing and Configuring PostgreSQL Phase
+ I}{PostgreSqlChapter}. If you are installing from rpms, and are
+ using MySQL, please be sure to install {\bf mysql-devel}, so that the MySQL
+ header files are available while compiling Bacula. In addition, the MySQL
+ client library {\bf mysqlclient} requires the gzip compression library {\bf
+ libz.a} or {\bf libz.so}. If you are using rpm packages, these libraries are
+ in the {\bf libz-devel} package. On Debian systems, you will need to load the
+ {\bf zlib1g-dev} package. If you are not using rpms or debs, you will need to
+ find the appropriate package for your system.
+
+ Note, if you already have a running MySQL or PostgreSQL on your system, you
+ can skip this phase provided that you have built the thread safe libraries.
+ And you have already installed the additional rpms noted above.
+
+ SQLite is not supported on Solaris. This is because it
+ frequently fails with bus errors. However SQLite3 may work.
+
+\item Detar the Bacula source code preferably into the {\bf bacula} directory
+ discussed above.
+
+\item {\bf cd} to the directory containing the source code.
+
+\item ./configure (with appropriate options as described below). Any
+ path names you specify as options on the ./configure command line
+ must be absolute paths and not relative.
+
+\item Check the output of ./configure very carefully, especially the Install
+ binaries and Install config directories. If they are not correct,
+ please rerun ./configure until they are. The output from ./configure is
+ stored in {\bf config.out} and can be re-displayed at any time without
+ rerunning the ./configure by doing {\bf cat config.out}.
+
+\item If after running ./configure once, you decide to change options and
+ re-run it, that is perfectly fine, but before re-running it, you should run:
+
+\footnotesize
+\begin{verbatim}
+ make distclean
+\end{verbatim}
+\normalsize
+
+so that you are sure to start from scratch and not have a mixture of the two
+options. This is because ./configure caches much of the information. The {\bf
+make distclean} is also critical if you move the source directory from one
+machine to another. If the {\bf make distclean} fails, just ignore it and
+continue on.
+
+\item make
+ If you get errors while linking in the Storage daemon directory
+ (src/stored), it is probably because you have not loaded the static
+ libraries on your system. I noticed this problem on a Solaris system.
+ To correct it, make sure that you have not added {\bf
+ {-} {-}enable-static-tools} to the {\bf ./configure} command.
+
+ If you skip this step ({\bf make}) and proceed immediately to the {\bf
+ make install} you are making two serious errors: 1. your install will
+ fail because Bacula requires a {\bf make} before a {\bf make install}.
+ 2. you are depriving yourself of the chance to make sure there are no
+ errors before beginning to write files to your system directories.
+
+
+\item make install
+ Please be sure you have done a {\bf make} before entering this command,
+ and that everything has properly compiled and linked without errors.
+
+
+\item If you are new to Bacula, we {\bf strongly} recommend that you skip
+ the next step and use the default configuration files, then run the
+ example program in the next chapter, then come back and modify your
+ configuration files to suit your particular needs.
+
+\item Customize the configuration files for each of the three daemons
+ (Directory, File, Storage) and for the Console program. For the details
+ of how to do this, please see \ilink{Setting Up Bacula Configuration
+ Files}{ConfigureChapter} in the Configuration chapter of this manual. We
+ recommend that you start by modifying the default configuration files
+ supplied, making the minimum changes necessary. Complete customization
+ can be done after you have Bacula up and running. Please take care when
+ modifying passwords, which were randomly generated, and the {\bf Name}s
+ as the passwords and names must agree between the configuration files
+ for security reasons.
+
+\label{CreateDatabase}
+\item Create the Bacula MySQL database and tables
+ (if using MySQL)
+ \ilink{Installing and Configuring MySQL Phase II}{mysql_phase2} or
+ create the Bacula PostgreSQL database and tables
+ \ilink{Configuring PostgreSQL
+ II}{PostgreSQL_configure} or alternatively if you are using
+ SQLite \ilink{Installing and Configuring SQLite Phase II}{phase2}.
+
+\item Start Bacula ({\bf ./bacula start}) Note. the next chapter shows you
+ how to do this in detail.
+
+\item Interface with Bacula using the Console program
+
+\item For the previous two items, please follow the instructions in the
+ \ilink{Running Bacula}{TutorialChapter} chapter of this manual,
+ where you will run a simple backup and do a restore. Do this before you make
+ heavy modifications to the configuration files so that you are sure that
+ Bacula works and are familiar with it. After that changing the conf files
+ will be easier.
+
+\item If after installing Bacula, you decide to "move it", that is to
+ install it in a different set of directories, proceed as follows:
+
+\footnotesize
+\begin{verbatim}
+ make uninstall
+ make distclean
+ ./configure (your-new-options)
+ make
+ make install
+
+\end{verbatim}
+\normalsize
+
+\end{enumerate}
+
+If all goes well, the {\bf ./configure} will correctly determine which
+operating system you are running and configure the source code appropriately.
+Currently, FreeBSD, Linux (Red Hat), and Solaris are supported. The Bacula
+client (File daemon) is reported to work with MacOS X 10.3 is if
+readline support is not enabled (default) when building the client.
+
+If you install Bacula on more than one system, and they are identical, you can
+simply transfer the source tree to that other system and do a "make
+install". However, if there are differences in the libraries or OS versions,
+or you wish to install on a different OS, you should start from the original
+compress tar file. If you do transfer the source tree, and you have previously
+done a ./configure command, you MUST do:
+
+\footnotesize
+\begin{verbatim}
+make distclean
+\end{verbatim}
+\normalsize
+
+prior to doing your new ./configure. This is because the GNU autoconf tools
+cache the configuration, and if you re-use a configuration for a Linux machine
+on a Solaris, you can be sure your build will fail. To avoid this, as
+mentioned above, either start from the tar file, or do a "make distclean".
+
+In general, you will probably want to supply a more complicated {\bf
+configure} statement to ensure that the modules you want are built and that
+everything is placed into the correct directories.
+
+For example, on Fedora, Red Hat, or SuSE one could use the following:
+
+\footnotesize
+\begin{verbatim}
+CFLAGS="-g -Wall" \
+ ./configure \
+ --sbindir=$HOME/bacula/bin \
+ --sysconfdir=$HOME/bacula/bin \
+ --with-pid-dir=$HOME/bacula/bin/working \
+ --with-subsys-dir=$HOME/bacula/bin/working \
+ --with-mysql \
+ --with-working-dir=$HOME/bacula/bin/working \
+ --with-dump-email=$USER
+\end{verbatim}
+\normalsize
+
+The advantage of using the above configuration to start is that
+everything will be put into a single directory, which you can later delete
+once you have run the examples in the next chapter and learned how Bacula
+works. In addition, the above can be installed and run as non-root.
+
+For the developer's convenience, I have added a {\bf defaultconfig} script to
+the {\bf examples} directory. This script contains the statements that you
+would normally use, and each developer/user may modify them to suit his needs.
+You should find additional useful examples in this directory as well.
+
+The {\bf \verb:--:enable-conio} or {\bf \verb:--:enable-readline} options are
+useful because they provide a command line history, editing capability for the
+Console program and tab completion on various option. If you have included
+either option in the build, either the {\bf termcap} or the {\bf ncurses}
+package will be needed to link. On most systems, including Red Hat and SuSE,
+you should include the ncurses package. If Bacula's configure process finds
+the ncurses libraries, it will use those rather than the termcap library. On
+some systems, such as SuSE, the termcap library is not in the standard library
+directory. As a consequence, the option may be disabled or you may get an
+error message such as:
+
+\footnotesize
+\begin{verbatim}
+/usr/lib/gcc-lib/i586-suse-linux/3.3.1/.../ld:
+cannot find -ltermcap
+collect2: ld returned 1 exit status
+\end{verbatim}
+\normalsize
+
+while building the Bacula Console. In that case, you will need to set the {\bf
+LDFLAGS} environment variable prior to building.
+
+\footnotesize
+\begin{verbatim}
+export LDFLAGS="-L/usr/lib/termcap"
+\end{verbatim}
+\normalsize
+
+The same library requirements apply if you wish to use the readline subroutines
+for command line editing, history and tab completion or if you are using a
+MySQL library that requires encryption. If you need encryption, you can either
+export the appropriate additional library options as shown above or,
+alternatively, you can include them directly on the ./configure line as in:
+
+\footnotesize
+\begin{verbatim}
+LDFLAGS="-lssl -lcyrpto" \
+ ./configure <your-options>
+\end{verbatim}
+\normalsize
+
+On some systems such as Mandriva, readline tends to
+gobble up prompts, which makes it totally useless. If this happens to you, use
+the disable option, or if you are using version 1.33 and above try using {\bf
+\verb:--:enable-conio} to use a built-in readline replacement. You will still need
+either the termcap or the ncurses library, but it is unlikely that the {\bf conio}
+package will gobble up prompts.
+
+readline is no longer supported after version 1.34. The code within Bacula
+remains, so it should be usable, and if users submit patches for it, we will
+be happy to apply them. However, due to the fact that each version of
+readline seems to be incompatible with previous versions, and that there
+are significant differences between systems, we can no longer afford to
+support it.
+
+\section{What Database to Use?}
+\label{DB}
+\index[general]{What Database to Use?}
+\index[general]{Use!What Database to}
+
+Before building Bacula you need to decide if you want to use SQLite, MySQL, or
+PostgreSQL. If you are not already running MySQL or PostgreSQL, you might
+want to start by testing with SQLite (not supported on Solaris).
+This will greatly simplify the setup for you
+because SQLite is compiled into Bacula an requires no administration. It
+performs well and is suitable for small to medium sized installations (maximum
+10-20 machines). However, we should note that a number of users have
+had unexplained database corruption with SQLite. For that reason, we
+recommend that you install either MySQL or PostgreSQL for production
+work.
+
+If you wish to use MySQL as the Bacula catalog, please see the
+\ilink{Installing and Configuring MySQL}{MySqlChapter} chapter of
+this manual. You will need to install MySQL prior to continuing with the
+configuration of Bacula. MySQL is a high quality database that is very
+efficient and is suitable for any sized installation. It is slightly more
+complicated than SQLite to setup and administer because it has a number of
+sophisticated features such as userids and passwords. It runs as a separate
+process, is truly professional and can manage a database of any size.
+
+If you wish to use PostgreSQL as the Bacula catalog, please see the
+\ilink{Installing and Configuring PostgreSQL}{PostgreSqlChapter}
+chapter of this manual. You will need to install PostgreSQL prior to
+continuing with the configuration of Bacula. PostgreSQL is very similar to
+MySQL, though it tends to be slightly more SQL92 compliant and has many more
+advanced features such as transactions, stored procedures, and the such. It
+requires a certain knowledge to install and maintain.
+
+If you wish to use SQLite as the Bacula catalog, please see
+\ilink{Installing and Configuring SQLite}{SqlLiteChapter} chapter of
+this manual. SQLite is not supported on Solaris.
+
+\section{Quick Start}
+\index[general]{Quick Start}
+\index[general]{Start!Quick}
+
+There are a number of options and important considerations given below
+that you can skip for the moment if you have not had any problems building
+Bacula with a simplified configuration as shown above.
+
+If the ./configure process is unable to find specific libraries (e.g.
+libintl, you should ensure that the appropriate package is installed on
+your system. Alternatively, if the package is installed in a non-standard
+location (as far as Bacula is concerned), then there is generally an
+option listed below (or listed with "./configure {-} {-}help" that will
+permit you to specify the directory that should be searched. In other
+cases, there are options that will permit you to disable to feature
+(e.g. {-} {-}disable-nls).
+
+If you want to dive right into it, we recommend you skip to the next chapter,
+and run the example program. It will teach you a lot about Bacula and as an
+example can be installed into a single directory (for easy removal) and run as
+non-root. If you have any problems or when you want to do a real installation,
+come back to this chapter and read the details presented below.
+
+\section{Configure Options}
+\label{Options}
+\index[general]{Options!Configure}
+\index[general]{Configure Options}
+
+The following command line options are available for {\bf configure} to
+customize your installation.
+
+\begin{description}
+\item [ \--prefix=\lt{}patch\gt{}]
+ \index[general]{{-}prefix}
+ This option is meant to allow you to direct where the architecture
+ independent files should be placed. However, we find this a somewhat
+ vague concept, and so we have not implemented this option other than
+ what ./configure does by default. As a consequence, we suggest that
+ you avoid it. We have provided options that allow you to explicitly
+ specify the directories for each of the major categories of installation
+ files.
+\item [ {-}{\-}sbindir=\lt{}binary-path\gt{}]
+ \index[general]{{-}{\-}sbindir}
+ Defines where the Bacula binary (executable) files will be placed during a
+ {\bf make install} command.
+
+\item [ {-}{\-}sysconfdir=\lt{}config-path\gt{}]
+ \index[general]{{-}{\-}sysconfdir}
+ Defines where the Bacula configuration files should be placed during a
+ {\bf make install} command.
+
+\item [ {-}{\-}mandir=\lt{}path\gt{}]
+ \index[general]{{-}{\-}mandir}
+ Note, as of Bacula version 1.39.14, the meaning of any path
+ specified on this option is change from prior versions. It
+ now specifies the top level man directory.
+ Previously the mandir specified the full path to where you
+ wanted the man files installed.
+ The man files will be installed in gzip'ed format under
+ mandir/man1 and mandir/man8 as appropriate.
+ For the install to succeed you must have {\bf gzip} installed
+ on your system.
+
+ By default, Bacula will install the Unix man pages in
+ /usr/share/man/man1 and /usr/share/man/man8.
+ If you wish the man page to be installed in
+ a different location, use this option to specify the path.
+ Note, the main HTML and PDF Bacula documents are in a separate
+ tar file that is not part of the source distribution.
+
+\item [ {-}{\-}datadir=\lt{}path\gt{} ]
+ \index[general]{{-}{\-}datadir}
+ If you translate Bacula or parts of Bacula into a different language
+ you may specify the location of the po files using the {\bf
+ {-}{\-}datadir} option. You must manually install any po files as
+ Bacula does not (yet) automatically do so.
+
+\item [ {-}{\-}disable-ipv6 ]
+ \index[general]{{-}{\-}disable-ipv6}
+
+\item [ {-}{\-}enable-smartalloc ]
+ \index[general]{{-}{\-}enable-smartalloc}
+ This enables the inclusion of the Smartalloc orphaned buffer detection
+ code. This option is highly recommended. Because we never build
+ without this option, you may experience problems if it is not enabled.
+ In this case, simply re-enable the option. We strongly recommend
+ keeping this option enabled as it helps detect memory leaks. This
+ configuration parameter is used while building Bacula
+
+\item [ {-}{\-}enable-bat ]
+ \label{enablebat}
+ \index[general]{{-}{\-}enable-bat}
+ If you have Qt4 >= 4.3.4 installed on your computer including the
+ libqt4 and libqt4-devel (libqt4-dev on Debian) libraries, and you want
+ to use the Bacula Administration Tool (bat) GUI Console interface to
+ Bacula, you must specify this option. Doing so will build everything in
+ the {\bf src/qt-console} directory. The build with enable-bat will work
+ only with a full Bacula build (i.e. it will not work with a client-only
+ build).
+
+ Qt4 is available on OpenSUSE 10.2, CentOS 5, Fedora, and Debian. If it
+ is not available on your system, you can download the {\bf depkgs-qt}
+ package from the Bacula Source Forge download area and build it.
+ See the
+ INSTALL file in that package for more details. In particular to use
+ the Qt4 built by {\bf depkgs-qt} you {\bf must} source the file
+ {\bf qt4-paths}.
+
+\item [ {-}{\-}enable-batch-insert ]
+ \index[general]{{-}{\-}enable-batch-insert}
+ This option enables batch inserts of the attribute records (default) in
+ the catalog database, which is much faster (10 times or more) than
+ without this option for large numbers of files. However, this option
+ will automatically be disabled if your SQL libraries are not
+ thread safe. If you find that batch mode is not enabled on your Bacula
+ installation, then your database most likely does not support threads.
+
+ SQLite2 is not thread safe. Batch insert cannot be enabled when using
+ SQLite2
+
+ On most systems, MySQL, PostgreSQL and SQLite3 are thread safe.
+
+ To verify that your PostgreSQL is thread safe, you can try this
+ (change the path to point to your particular installed libpq.a;
+ these commands were issued on FreeBSD 6.2):
+
+\begin{verbatim}
+$ nm /usr/local/lib/libpq.a | grep PQputCopyData
+00001b08 T PQputCopyData
+$ nm /usr/local/lib/libpq.a | grep mutex
+ U pthread_mutex_lock
+ U pthread_mutex_unlock
+ U pthread_mutex_init
+ U pthread_mutex_lock
+ U pthread_mutex_unlock
+\end{verbatim}
+
+ The above example shows a libpq that contains the required function
+ PQputCopyData and is thread enabled (i.e. the pthread\_mutex* entries).
+ If you do not see PQputCopyData, your version of PostgreSQL is too old
+ to allow batch insert. If you do not see the mutex entries, then thread
+ support has not been enabled. Our tests indicate you usually need to
+ change the configuration options and recompile/reinstall the PostgreSQL
+ client software to get thread support.
+
+ Bacula always links to the thread safe MySQL libraries.
+
+ Running with Batch Insert turned on is recommended because it can
+ significantly improve attribute insertion times. However, it does
+ put a significantly larger part of the work on your SQL engine, so
+ you may need to pay more attention to tuning it. In particular,
+ Batch Insert can require large temporary table space, and consequently,
+ the default location (often /tmp) may run out of space causing errors.
+ For MySQL, the location is set in my.conf with "tmpdir". You may also
+ want to increase the memory available to your SQL engine to further
+ improve performance during Batch Inserts.
+
+\item [ {-}{\-}enable-bwx-console ]
+ \index[general]{{-}{\-}enable-bwx-console}
+ If you have wxWidgets installed on your computer and you want to use the
+ wxWidgets GUI Console interface to Bacula, you must specify this option.
+ Doing so will build everything in the {\bf src/wx-console} directory.
+ This could also be useful to users who want a GUI Console and don't want
+ to install QT, as wxWidgets can work with GTK+, Motif or even X11
+ libraries.
+
+\item [ {-}{\-}enable-tray-monitor ]
+ \index[general]{{-}{\-}enable-tray-monitor}
+ If you have GTK installed on your computer, you run a graphical
+ environment or a window manager compatible with the FreeDesktop system
+ tray standard (like KDE and GNOME) and you want to use a GUI to monitor
+ Bacula daemons, you must specify this option. Doing so will build
+ everything in the {\bf src/tray-monitor} directory. Note, due to
+ restrictions on what can be linked with GPLed code, we were forced to
+ remove the egg code that dealt with the tray icons and replace it by
+ calls to the GTK+ API, and unfortunately, the tray icon API necessary
+ was not implemented until GTK version 2.10 or later.
+
+\item [ {-}{\-}enable-static-tools]
+ \index[general]{{-}{\-}enable-static-tools}
+ This option causes the linker to link the Storage daemon utility tools
+ ({\bf bls}, {\bf bextract}, and {\bf bscan}) statically. This permits
+ using them without having the shared libraries loaded. If you have
+ problems linking in the {\bf src/stored} directory, make sure you have
+ not enabled this option, or explicitly disable static linking by adding
+ {\bf \verb:--:disable-static-tools}.
+
+\item [ {-}{\-}enable-static-fd]
+ \index[general]{{-}{\-}enable-static-fd}
+ This option causes the make process to build a {\bf static-bacula-fd} in
+ addition to the standard File daemon. This static version will include
+ statically linked libraries and is required for the Bare Metal recovery.
+ This option is largely superseded by using {\bf make static-bacula-fd}
+ from with in the {\bf src/filed} directory. Also, the {\bf
+ \verb:--:enable-client-only} option described below is useful for just
+ building a client so that all the other parts of the program are not
+ compiled.
+
+ When linking a static binary, the linker needs the static versions
+ of all the libraries that are used, so frequently users will
+ experience linking errors when this option is used. The first
+ thing to do is to make sure you have the static glibc library
+ installed on your system. The second thing to do is the make sure
+ you do not specify {\bf {-}{\-}openssl} or {\bf {-}{\-}with-python}
+ on your ./configure statement as these options require additional
+ libraries. You may be able to enable those options, but you will
+ need to load additional static libraries.
+
+
+\item [ {-}{\-}enable-static-sd]
+ \index[general]{{-}{\-}enable-static-sd}
+ This option causes the make process to build a {\bf static-bacula-sd} in
+ addition to the standard Storage daemon. This static version will
+ include statically linked libraries and could be useful during a Bare
+ Metal recovery.
+
+ When linking a static binary, the linker needs the static versions
+ of all the libraries that are used, so frequently users will
+ experience linking errors when this option is used. The first
+ thing to do is to make sure you have the static glibc library
+ installed on your system. The second thing to do is the make sure
+ you do not specify {\bf {-}{\-}openssl} or {\bf {-}{\-}with-python}
+ on your ./configure statement as these options require additional
+ libraries. You may be able to enable those options, but you will
+ need to load additional static libraries.
+
+
+\item [ {-}{\-}enable-static-dir]
+ \index[general]{{-}{\-}enable-static-dir}
+ This option causes the make process to build a {\bf static-bacula-dir}
+ in addition to the standard Director. This static version will include
+ statically linked libraries and could be useful during a Bare Metal
+ recovery.
+
+ When linking a static binary, the linker needs the static versions
+ of all the libraries that are used, so frequently users will
+ experience linking errors when this option is used. The first
+ thing to do is to make sure you have the static glibc library
+ installed on your system. The second thing to do is the make sure
+ you do not specify {\bf {-}{\-}openssl} or {\bf {-}{\-}with-python}
+ on your ./configure statement as these options require additional
+ libraries. You may be able to enable those options, but you will
+ need to load additional static libraries.
+
+
+\item [ {-}{\-}enable-static-cons]
+ \index[general]{{-}{\-}enable-static-cons}
+ This option causes the make process to build a {\bf static-console} in
+ addition to the standard console. This static version will include
+ statically linked libraries and could be useful during a Bare Metal
+ recovery.
+
+ When linking a static binary, the linker needs the static versions
+ of all the libraries that are used, so frequently users will
+ experience linking errors when this option is used. The first
+ thing to do is to make sure you have the static glibc library
+ installed on your system. The second thing to do is the make sure
+ you do not specify {\bf {-}{\-}openssl} or {\bf {-}{\-}with-python}
+ on your ./configure statement as these options require additional
+ libraries. You may be able to enable those options, but you will
+ need to load additional static libraries.
+
+
+\item [ {-}{\-}enable-client-only]
+ \index[general]{{-}{\-}enable-client-only}
+ This option causes the make process to build only the File daemon and
+ the libraries that it needs. None of the other daemons, storage tools,
+ nor the console will be built. Likewise a {\bf make install} will then
+ only install the File daemon. To cause all daemons to be built, you
+ will need to do a configuration without this option. This option
+ greatly facilitates building a Client on a client only machine.
+
+ When linking a static binary, the linker needs the static versions
+ of all the libraries that are used, so frequently users will
+ experience linking errors when this option is used. The first
+ thing to do is to make sure you have the static glibc library
+ installed on your system. The second thing to do is the make sure
+ you do not specify {\bf {-}{\-}openssl} or {\bf {-}{\-}with-python}
+ on your ./configure statement as these options require additional
+ libraries. You may be able to enable those options, but you will
+ need to load additional static libraries.
+
+\item [ {-}{\-}enable-build-dird]
+ \index[general]{{-}{\-}enable-build-dird}
+ This option causes the make process to build the Director and the
+ Director's tools. By default, this option is on, but you may turn
+ it off by using {\bf {-}{\-}disable-build-dird} to prevent the
+ Director from being built.
+
+\item [ {-}{\-}enable-build-stored]
+ \index[general]{{-}{\-}enable-build-stored}
+ This option causes the make process to build the Storage daemon.
+ By default, this option is on, but you may turn
+ it off by using {\bf {-}{\-}disable-build-stored} to prevent the
+ Storage daemon from being built.
+
+
+\item [ {-}{\-}enable-largefile]
+ \index[general]{{-}{\-}enable-largefile}
+ This option (default) causes Bacula to be built with 64 bit file address
+ support if it is available on your system. This permits Bacula to read and
+ write files greater than 2 GBytes in size. You may disable this feature and
+ revert to 32 bit file addresses by using {\bf \verb:--:disable-largefile}.
+
+\item [ {-}{\-}disable-nls]
+ \index[general]{{-}{\-}disable-nls}
+ By default, Bacula uses the GNU Native Language Support (NLS) libraries. On
+ some machines, these libraries may not be present or may not function
+ correctly (especially on non-Linux implementations). In such cases, you
+ may specify {\bf {-}{\-}disable-nls} to disable use of those libraries.
+ In such a case, Bacula will revert to using English.
+
+\item [ {-}{\-}disable-ipv6 ]
+ \index[general]{{-}{\-}disable-ipv6}
+ By default, Bacula enables IPv6 protocol. On some systems, the files
+ for IPv6 may exist, but the functionality could be turned off in the
+ kernel. In that case, in order to correctly build Bacula, you will
+ explicitly need to use this option so that Bacula does not attempt
+ to reference OS function calls that do not exist.
+
+\item [ {-}{\-}with-sqlite3=\lt{}sqlite3-path\gt{}]
+ \index[general]{{-}{\-}with-sqlite3}
+ This enables use of the SQLite version 3.x database. The {\bf
+ sqlite3-path} is not normally specified as Bacula looks for the
+ necessary components in a standard location ({\bf depkgs/sqlite3}). See
+ \ilink{Installing and Configuring SQLite}{SqlLiteChapter} chapter of
+ this manual for more details. SQLite3 is not supported on Solaris.
+
+\item [ {-}{\-}with-mysql=\lt{}mysql-path\gt{}]
+ \index[general]{{-}{\-}with-mysql}
+ This enables building of the Catalog services for Bacula. It assumes
+ that MySQL is running on your system, and expects it to be installed in
+ the {\bf mysql-path} that you specify. Normally, if MySQL is installed
+ in a standard system location, you can simply use {\bf {-}{\-}with-mysql}
+ with no path specification. If you do use this option, please proceed
+ to installing MySQL in the \ilink{Installing and Configuring
+ MySQL}{MySqlChapter} chapter before proceeding with the configuration.
+
+ See the note below under the {-}{\-}with-postgresql item.
+
+\item [ {-}{\-}with-postgresql=\lt{}path\gt{}]
+ \index[general]{{-}{\-}with-postgresql}
+ This provides an explicit path to the PostgreSQL libraries if Bacula
+ cannot find it by default. Normally to build with PostgreSQL, you would
+ simply use {\bf {-}{\-}with-postgresql}.
+
+ Note, for Bacula to be configured properly, you must specify one
+ of the four database options supported. That is:
+ {-}{\-}with-sqlite, {-}{\-}with-sqlite3, {-}{\-}with-mysql, or
+ {-}{\-}with-postgresql, otherwise the ./configure will fail.
+
+\item [ {-}{\-}with-openssl=\lt{}path\gt{}]
+ This configuration option is necessary if you want to enable TLS (ssl),
+ which encrypts the communications within
+ Bacula or if you want to use File Daemon PKI data encryption.
+ Normally, the {\bf path} specification is not necessary since
+ the configuration searches for the OpenSSL libraries in standard system
+ locations. Enabling OpenSSL in Bacula permits secure communications
+ between the daemons and/or data encryption in the File daemon.
+ For more information on using TLS, please see the
+ \ilink{Bacula TLS -- Communications Encryption}{CommEncryption} chapter
+ of this manual.
+ For more information on using PKI data encryption, please see the
+ \ilink{Bacula PKI -- Data Encryption}{DataEncryption}
+ chapter of this manual.
+
+\item [ {-}{\-}with-python=\lt{}path\gt{}]
+ \index[general]{{-}{\-}with-python}
+ This option enables Bacula support for Python. If no path is supplied,
+ configure will search the standard library locations for Python 2.2,
+ 2.3, 2.4, or 2.5. If it cannot find the library, you will need to
+ supply a path to your Python library directory. Please see the
+ \ilink{Python chapter}{PythonChapter} for the details of using Python
+ scripting.
+
+\item [ {-}{\-}with-libintl-prefix=\lt{}DIR\gt{}]
+ \index[general]{{-}{\-}with-libintl-prefix}
+ This option may be used to tell Bacula to search DIR/include and
+ DIR/lib for the libintl headers and libraries needed for Native
+ Language Support (NLS).
+
+\item [ {-}{\-}enable-conio]
+ \index[general]{{-}{\-}enable-conio}
+ Tells Bacula to enable building the small, light weight readline
+ replacement routine. It is generally much easier to configure than
+ readline, although, like readline, it needs either the termcap or
+ ncurses library.
+
+\item [ {-}{\-}with-readline=\lt{}readline-path\gt{}]
+ \index[general]{{-}{\-}with-readline}
+ Tells Bacula where {\bf readline} is installed. Normally, Bacula will
+ find readline if it is in a standard library. If it is not found and no
+ {-}{\-}with-readline is specified, readline will be disabled. This
+ option affects the Bacula build. Readline provides the Console program
+ with a command line history and editing capability and is no longer
+ supported, so you are on your own if you have problems.
+
+\item [ {-}{\-}enable-readline]
+ \index[general]{{-}{\-}enable-readline}
+ Tells Bacula to enable readline support. It is normally disabled due to the
+ large number of configuration problems and the fact that the package seems to
+ change in incompatible ways from version to version.
+
+\item [ {-}{\-}with-tcp-wrappers=\lt{}path\gt{}]
+ \index[general]{{-}{\-}with-tcp-wrappers}
+ \index[general]{TCP Wrappers}
+ \index[general]{Wrappers!TCP}
+ \index[general]{libwrappers}
+ This specifies that you want TCP wrappers (man hosts\_access(5)) compiled in.
+ The path is optional since Bacula will normally find the libraries in the
+ standard locations. This option affects the Bacula build. In specifying your
+ restrictions in the {\bf /etc/hosts.allow} or {\bf /etc/hosts.deny} files, do
+ not use the {\bf twist} option (hosts\_options(5)) or the Bacula process will
+ be terminated. Note, when setting up your {\bf /etc/hosts.allow}
+ or {\bf /etc/hosts.deny}, you must identify the Bacula daemon in
+ question with the name you give it in your conf file rather than the
+ name of the executable.
+
+ For more information on configuring and testing TCP wrappers, please see the
+ \ilink{Configuring and Testing TCP Wrappers}{wrappers} section
+ in the Security Chapter.
+
+ On SuSE, the libwrappers libraries needed to link Bacula are
+ contained in the tcpd-devel package. On Red Hat, the package is named
+ tcp\_wrappers.
+
+\item [ {-}{\-}with-archivedir=\lt{}path\gt{} ]
+ \index[general]{{-}{\-}with-archivedir}
+ The directory used for disk-based backups. Default value is /tmp.
+ This parameter sets the default values in the bacula-dir.conf and bacula-sd.conf
+ configuration files. For example, it sets the Where directive for the
+ default restore job and the Archive Device directive for the FileStorage
+ device.
+
+ This option is designed primarily for use in regression testing.
+ Most users can safely ignore this option.
+
+\item [ {-}{\-}with-working-dir=\lt{}working-directory-path\gt{} ]
+ \index[general]{{-}{\-}with-working-dir}
+ This option is mandatory and specifies a directory into which Bacula may
+ safely place files that will remain between Bacula executions. For example,
+ if the internal database is used, Bacula will keep those files in this
+ directory. This option is only used to modify the daemon configuration
+ files. You may also accomplish the same thing by directly editing them later.
+ The working directory is not automatically created by the install process, so
+ you must ensure that it exists before using Bacula for the first time.
+
+\item [ {-}{\-}with-base-port=\lt{}port=number\gt{}]
+ \index[general]{{-}{\-}with-base-port}
+ In order to run, Bacula needs three TCP/IP ports (one for the Bacula
+ Console, one for the Storage daemon, and one for the File daemon). The {\bf
+ \verb:--:with-baseport} option will automatically assign three ports beginning at
+ the base port address specified. You may also change the port number in the
+ resulting configuration files. However, you need to take care that the
+ numbers correspond correctly in each of the three daemon configuration
+ files. The default base port is 9101, which assigns ports 9101 through 9103.
+ These ports (9101, 9102, and 9103) have been officially assigned to Bacula by
+ IANA. This option is only used to modify the daemon configuration files. You
+ may also accomplish the same thing by directly editing them later.
+
+\item [ {-}{\-}with-dump-email=\lt{}email-address\gt{}]
+ \index[general]{{-}{\-}with-dump-email}
+ This option specifies the email address where any core dumps should be set.
+ This option is normally only used by developers.
+
+\item [ {-}{\-}with-pid-dir=\lt{}PATH\gt{} ]
+ \index[general]{{-}{\-}with-pid-dir}
+ This specifies where Bacula should place the process id file during
+ execution. The default is: {\bf /var/run}. This directory is not created by
+ the install process, so you must ensure that it exists before using Bacula
+ the first time.
+
+\item [ {-}{\-}with-subsys-dir=\lt{}PATH\gt{}]
+ \index[general]{{-}{\-}with-subsys-dir}
+ This specifies where Bacula should place the subsystem lock file during
+ execution. The default is {\bf /var/run/subsys}. Please make sure that you do
+ not specify the same directory for this directory and for the {\bf sbindir}
+ directory. This directory is used only within the autostart scripts. The
+ subsys directory is not created by the Bacula install, so you must be sure to
+ create it before using Bacula.
+
+\item [ {-}{\-}with-dir-password=\lt{}Password\gt{}]
+ \index[general]{{-}{\-}with-dir-password}
+ This option allows you to specify the password used to access the Director
+ (normally from the Console program). If it is not specified, configure will
+ automatically create a random password.
+
+\item [ {-}{\-}with-fd-password=\lt{}Password\gt{} ]
+ \index[general]{{-}{\-}with-fd-password}
+ This option allows you to specify the password used to access the File daemon
+ (normally called from the Director). If it is not specified, configure will
+ automatically create a random password.
+
+\item [ {-}{\-}with-sd-password=\lt{}Password\gt{} ]
+ \index[general]{{-}{\-}with-sd-password}
+ This option allows you to specify the password used to access the Storage daemon
+ (normally called from the Director). If it is not specified, configure will
+ automatically create a random password.
+
+\item [ {-}{\-}with-dir-user=\lt{}User\gt{} ]
+ \index[general]{{-}{\-}with-dir-user}
+ This option allows you to specify the Userid used to run the Director. The
+ Director must be started as root, but doesn't need to run as root, and
+ after doing preliminary initializations, it can "drop" to the UserId
+ specified on this option.
+ If you specify this option, you must
+ create the User prior to running {\bf make install}, because the
+ working directory owner will be set to {\bf User}.
+
+\item [ {-}{\-}with-dir-group=\lt{}Group\gt{} ]
+ \index[general]{{-}{\-}with-dir-group}
+ This option allows you to specify the GroupId used to run the Director. The
+ Director must be started as root, but doesn't need to run as root, and after
+ doing preliminary initializations, it can "drop" to the GroupId specified
+ on this option.
+ If you specify this option, you must
+ create the Group prior to running {\bf make install}, because the
+ working directory group will be set to {\bf Group}.
+
+\item [ {-}{\-}with-sd-user=\lt{}User\gt{} ]
+ \index[general]{{-}{\-}with-sd-user}
+ This option allows you to specify the Userid used to run the Storage daemon.
+ The Storage daemon must be started as root, but doesn't need to run as root,
+ and after doing preliminary initializations, it can "drop" to the UserId
+ specified on this option. If you use this option, you will need to take care
+ that the Storage daemon has access to all the devices (tape drives, ...) that
+ it needs.
+
+\item [ {-}{\-}with-sd-group=\lt{}Group\gt{} ]
+ \index[general]{{-}{\-}with-sd-group}
+ This option allows you to specify the GroupId used to run the Storage daemon.
+ The Storage daemon must be started as root, but doesn't need to run as root,
+ and after doing preliminary initializations, it can "drop" to the GroupId
+ specified on this option.
+
+\item [ {-}{\-}with-fd-user=\lt{}User\gt{} ]
+ \index[general]{{-}{\-}with-fd-user}
+ This option allows you to specify the Userid used to run the File daemon. The
+ File daemon must be started as root, and in most cases, it needs to run as
+ root, so this option is used only in very special cases, after doing
+ preliminary initializations, it can "drop" to the UserId specified on this
+ option.
+
+\item [ {-}{\-}with-fd-group=\lt{}Group\gt{} ]
+ \index[general]{{-}{\-}with-fd-group}
+ This option allows you to specify the GroupId used to run the File daemon.
+ The File daemon must be started as root, and in most cases, it must be run as
+ root, however, after doing preliminary initializations, it can "drop" to
+ the GroupId specified on this option.
+
+\item [ {-}{\-}with-mon-dir-password=\lt{}Password\gt{}]
+ \index[general]{{-}{\-}with-mon-dir-password}
+ This option allows you to specify the password used to access the Directory
+ from the monitor. If it is not specified, configure will
+ automatically create a random password.
+
+\item [ {-}{\-}with-mon-fd-password=\lt{}Password\gt{} ]
+ \index[general]{{-}{\-}with-mon-fd-password}
+ This option allows you to specify the password used to access the File daemon
+ from the Monitor. If it is not specified, configure will
+ automatically create a random password.
+
+\item [ {-}{\-}with-mon-sd-password=\lt{}Password\gt{} ]
+ \index[general]{{-}{\-}with-mon-sd-password}
+ This option allows you to specify the password used to access the
+ Storage daemon from the Monitor. If it is not specified, configure will
+ automatically create a random password.
+
+\item [ {-}{\-}with-db-name=\lt{}database-name\gt{} ]
+ \index[general]{{-}{\-}with-db-name}
+ This option allows you to specify the database name to be used in
+ the conf files. The default is bacula.
+
+\item [ {-}{\-}with-db-user=\lt{}database-user\gt{} ]
+ \index[general]{{-}{\-}with-db-user}
+ This option allows you to specify the database user name to be used in
+ the conf files. The default is bacula.
+
+\end{description}
+
+Note, many other options are presented when you do a {\bf ./configure
+\verb:--:help}, but they are not implemented.
+
+\section{Recommended Options for Most Systems}
+\index[general]{Systems!Recommended Options for Most}
+\index[general]{Recommended Options for Most Systems}
+
+For most systems, we recommend starting with the following options:
+
+\footnotesize
+\begin{verbatim}
+./configure \
+ --enable-smartalloc \
+ --sbindir=$HOME/bacula/bin \
+ --sysconfdir=$HOME/bacula/bin \
+ --with-pid-dir=$HOME/bacula/bin/working \
+ --with-subsys-dir=$HOME/bacula/bin/working \
+ --with-mysql=$HOME/mysql \
+ --with-working-dir=$HOME/bacula/working
+\end{verbatim}
+\normalsize
+
+If you want to install Bacula in an installation directory rather than run it
+out of the build directory (as developers will do most of the time), you
+should also include the \verb:--:sbindir and \verb:--:sysconfdir options with appropriate
+paths. Neither are necessary if you do not use "make install" as is the case
+for most development work. The install process will create the sbindir and
+sysconfdir if they do not exist, but it will not automatically create the
+pid-dir, subsys-dir, or working-dir, so you must ensure that they exist before
+running Bacula for the first time.
+
+\section{Red Hat}
+\index[general]{Red Hat}
+
+Using SQLite:
+
+\footnotesize
+\begin{verbatim}
+
+CFLAGS="-g -Wall" ./configure \
+ --sbindir=$HOME/bacula/bin \
+ --sysconfdir=$HOME/bacula/bin \
+ --enable-smartalloc \
+ --with-sqlite=$HOME/bacula/depkgs/sqlite \
+ --with-working-dir=$HOME/bacula/working \
+ --with-pid-dir=$HOME/bacula/bin/working \
+ --with-subsys-dir=$HOME/bacula/bin/working \
+ --enable-bat \
+ --enable-conio
+\end{verbatim}
+\normalsize
+
+or
+
+\footnotesize
+\begin{verbatim}
+
+CFLAGS="-g -Wall" ./configure \
+ --sbindir=$HOME/bacula/bin \
+ --sysconfdir=$HOME/bacula/bin \
+ --enable-smartalloc \
+ --with-mysql=$HOME/mysql \
+ --with-working-dir=$HOME/bacula/working
+ --with-pid-dir=$HOME/bacula/bin/working \
+ --with-subsys-dir=$HOME/bacula/bin/working
+ --enable-conio
+\end{verbatim}
+\normalsize
+
+or finally, a completely traditional Red Hat Linux install:
+
+\footnotesize
+\begin{verbatim}
+CFLAGS="-g -Wall" ./configure \
+ --sbindir=/usr/sbin \
+ --sysconfdir=/etc/bacula \
+ --with-scriptdir=/etc/bacula \
+ --enable-smartalloc \
+ --enable-bat \
+ --with-mysql \
+ --with-working-dir=/var/bacula \
+ --with-pid-dir=/var/run \
+ --enable-conio
+\end{verbatim}
+\normalsize
+
+Note, Bacula assumes that /var/bacula, /var/run, and /var/lock/subsys exist so
+it will not automatically create them during the install process.
+
+\section{Solaris}
+\index[general]{Solaris}
+
+To build Bacula from source, you will need the following installed on your
+system (they are not by default): libiconv, gcc 3.3.2, stdc++, libgcc (for
+stdc++ and gcc\_s libraries), make 3.8 or later.
+
+You will probably also need to: Add /usr/local/bin to PATH and Add
+/usr/ccs/bin to PATH for ar.
+
+It is possible to build Bacula on Solaris with the Solaris compiler, but
+we recommend using GNU C++ if possible.
+
+A typical configuration command might look like:
+
+\footnotesize
+\begin{verbatim}
+#!/bin/sh
+CFLAGS="-g" ./configure \
+ --sbindir=$HOME/bacula/bin \
+ --sysconfdir=$HOME/bacula/bin \
+ --with-mysql=$HOME/mysql \
+ --enable-smartalloc \
+ --with-pid-dir=$HOME/bacula/bin/working \
+ --with-subsys-dir=$HOME/bacula/bin/working \
+ --with-working-dir=$HOME/bacula/working
+\end{verbatim}
+\normalsize
+
+As mentioned above, the install process will create the sbindir and sysconfdir
+if they do not exist, but it will not automatically create the pid-dir,
+subsys-dir, or working-dir, so you must ensure that they exist before running
+Bacula for the first time.
+
+Note, you may need to install the following packages to build Bacula
+from source:
+\footnotesize
+\begin{verbatim}
+SUNWbinutils,
+SUNWarc,
+SUNWhea,
+SUNWGcc,
+SUNWGnutls
+SUNWGnutls-devel
+SUNWGmake
+SUNWgccruntime
+SUNWlibgcrypt
+SUNWzlib
+SUNWzlibs
+SUNWbinutilsS
+SUNWGmakeS
+SUNWlibm
+
+export
+PATH=/usr/bin::/usr/ccs/bin:/etc:/usr/openwin/bin:/usr/local/bin:/usr/sfw/bin:/opt/sfw/bin:/usr/ucb:/usr/sbin
+\end{verbatim}
+\normalsize
+
+If you have installed special software not normally in the Solaris
+libraries, such as OpenSSL, or the packages shown above, then you may need
+to add {\bf /usr/sfw/lib} to the library search path. Probably the
+simplest way to do so is to run:
+
+\footnotesize
+\begin{verbatim}
+setenv LDFLAGS "-L/usr/sfw/lib -R/usr/sfw/lib"
+\end{verbatim}
+\normalsize
+
+Prior to running the ./configure command.
+
+Alternatively, you can set the LD\_LIBARY\_PATH and/or the LD\_RUN\_PATH
+environment variables appropriately.
+
+It is also possible to use the {\bf crle} program to set the library
+search path. However, this should be used with caution.
+
+\section{FreeBSD}
+\index[general]{FreeBSD}
+
+Please see:
+\elink{The FreeBSD Diary}{http://www.freebsddiary.org/bacula.php} for a
+detailed description on how to make Bacula work on your system. In addition,
+users of FreeBSD prior to 4.9-STABLE dated Mon Dec 29 15:18:01 2003 UTC who
+plan to use tape devices, please see the
+\ilink{Tape Testing Chapter}{FreeBSDTapes} of this manual for
+{\bf important} information on how to configure your tape drive for
+compatibility with Bacula.
+
+If you are using Bacula with MySQL, you should take care to compile MySQL with
+FreeBSD native threads rather than LinuxThreads, since Bacula is normally built
+with FreeBSD native threads rather than LinuxTreads. Mixing the two will
+probably not work.
+
+\section{Win32}
+\index[general]{Win32}
+
+To install the binary Win32 version of the File daemon please see the
+\ilink{Win32 Installation Chapter}{Win32Chapter} in this document.
+
+\section{One File Configure Script}
+\index[general]{Script!One File Configure}
+\index[general]{One Files Configure Script}
+
+The following script could be used if you want to put everything
+in a single file:
+
+\footnotesize
+\begin{verbatim}
+#!/bin/sh
+CFLAGS="-g -Wall" \
+ ./configure \
+ --sbindir=$HOME/bacula/bin \
+ --sysconfdir=$HOME/bacula/bin \
+ --mandir=$HOME/bacula/bin \
+ --enable-smartalloc \
+ --enable-bat \
+ --enable-bwx-console \
+ --enable-tray-monitor \
+ --with-pid-dir=$HOME/bacula/bin/working \
+ --with-subsys-dir=$HOME/bacula/bin/working \
+ --with-mysql \
+ --with-working-dir=$HOME/bacula/bin/working \
+ --with-dump-email=$USER@your-site.com \
+ --with-job-email=$USER@your-site.com \
+ --with-smtp-host=mail.your-site.com
+exit 0
+\end{verbatim}
+\normalsize
+
+You may also want to put the following entries in your {\bf /etc/services}
+file as it will make viewing the connections made by Bacula easier to
+recognize (i.e. netstat -a):
+
+\footnotesize
+\begin{verbatim}
+bacula-dir 9101/tcp
+bacula-fd 9102/tcp
+bacula-sd 9103/tcp
+\end{verbatim}
+\normalsize
+
+\section{Installing Bacula}
+\index[general]{Bacula!Installing}
+\index[general]{Installing Bacula}
+
+Before setting up your configuration files, you will want to install Bacula in
+its final location. Simply enter:
+
+\footnotesize
+\begin{verbatim}
+make install
+\end{verbatim}
+\normalsize
+
+If you have previously installed Bacula, the old binaries will be overwritten,
+but the old configuration files will remain unchanged, and the "new"
+configuration files will be appended with a {\bf .new}. Generally if you have
+previously installed and run Bacula you will want to discard or ignore the
+configuration files with the appended {\bf .new}.
+
+\section{Building a File Daemon or Client}
+\index[general]{Client!Building a File Daemon or}
+\index[general]{Building a File Daemon or Client}
+
+If you run the Director and the Storage daemon on one machine and you wish to
+back up another machine, you must have a copy of the File daemon for that
+machine. If the machine and the Operating System are identical, you can simply
+copy the Bacula File daemon binary file {\bf bacula-fd} as well as its
+configuration file {\bf bacula-fd.conf} then modify the name and password in
+the conf file to be unique. Be sure to make corresponding additions to the
+Director's configuration file ({\bf bacula-dir.conf}).
+
+If the architecture or the OS level are different, you will need to build a
+File daemon on the Client machine. To do so, you can use the same {\bf
+./configure} command as you did for your main program, starting either from a
+fresh copy of the source tree, or using {\bf make\ distclean} before the {\bf
+./configure}.
+
+Since the File daemon does not access the Catalog database, you can remove
+the {\bf \verb:--:with-mysql} or {\bf \verb:--:with-sqlite} options, then
+add {\bf \verb:--:enable-client-only}. This will compile only the
+necessary libraries and the client programs and thus avoids the necessity
+of installing one or another of those database programs to build the File
+daemon. With the above option, you simply enter {\bf make} and just the
+client will be built.
+
+\label{autostart}
+\section{Auto Starting the Daemons}
+\index[general]{Daemons!Auto Starting the}
+\index[general]{Auto Starting the Daemons}
+
+If you wish the daemons to be automatically started and stopped when your
+system is booted (a good idea), one more step is necessary. First, the
+./configure process must recognize your system -- that is it must be a
+supported platform and not {\bf unknown}, then you must install the platform
+dependent files by doing:
+
+\footnotesize
+\begin{verbatim}
+(become root)
+make install-autostart
+\end{verbatim}
+\normalsize
+
+Please note, that the auto-start feature is implemented only on systems
+that we officially support (currently, FreeBSD, Red Hat/Fedora Linux, and
+Solaris), and has only been fully tested on Fedora Linux.
+
+The {\bf make install-autostart} will cause the appropriate startup scripts
+to be installed with the necessary symbolic links. On Red Hat/Fedora Linux
+systems, these scripts reside in {\bf /etc/rc.d/init.d/bacula-dir} {\bf
+/etc/rc.d/init.d/bacula-fd}, and {\bf /etc/rc.d/init.d/bacula-sd}. However
+the exact location depends on what operating system you are using.
+
+If you only wish to install the File daemon, you may do so with:
+
+\footnotesize
+\begin{verbatim}
+make install-autostart-fd
+\end{verbatim}
+\normalsize
+
+\section{Other Make Notes}
+\index[general]{Notes!Other Make}
+\index[general]{Other Make Notes}
+
+To simply build a new executable in any directory, enter:
+
+\footnotesize
+\begin{verbatim}
+make
+\end{verbatim}
+\normalsize
+
+To clean out all the objects and binaries (including the files named 1, 2, or
+3, which are development temporary files), enter:
+
+\footnotesize
+\begin{verbatim}
+make clean
+\end{verbatim}
+\normalsize
+
+To really clean out everything for distribution, enter:
+
+\footnotesize
+\begin{verbatim}
+make distclean
+\end{verbatim}
+\normalsize
+
+note, this cleans out the Makefiles and is normally done from the top level
+directory to prepare for distribution of the source. To recover from this
+state, you must redo the {\bf ./configure} in the top level directory, since
+all the Makefiles will be deleted.
+
+To add a new file in a subdirectory, edit the Makefile.in in that directory,
+then simply do a {\bf make}. In most cases, the make will rebuild the Makefile
+from the new Makefile.in. In some case, you may need to issue the {\bf make} a
+second time. In extreme cases, cd to the top level directory and enter: {\bf
+make Makefiles}.
+
+To add dependencies:
+
+\footnotesize
+\begin{verbatim}
+make depend
+\end{verbatim}
+\normalsize
+
+The {\bf make depend} appends the header file dependencies for each of the
+object files to Makefile and Makefile.in. This command should be done in each
+directory where you change the dependencies. Normally, it only needs to be run
+when you add or delete source or header files. {\bf make depend} is normally
+automatically invoked during the configuration process.
+
+To install:
+
+\footnotesize
+\begin{verbatim}
+make install
+\end{verbatim}
+\normalsize
+
+This not normally done if you are developing Bacula, but is used if you are
+going to run it to backup your system.
+
+After doing a {\bf make install} the following files will be installed on your
+system (more or less). The exact files and location (directory) for each file
+depends on your {\bf ./configure} command (e.g. if you are using SQLite instead
+of MySQL, some of the files will be different).
+
+NOTE: it is quite probable that this list is out of date. But it is a
+starting point.
+
+\footnotesize
+\begin{verbatim}
+bacula
+bacula-dir
+bacula-dir.conf
+bacula-fd
+bacula-fd.conf
+bacula-sd
+bacula-sd.conf
+bacula-tray-monitor
+tray-monitor.conf
+bextract
+bls
+bscan
+btape
+btraceback
+btraceback.gdb
+bconsole
+bconsole.conf
+create_mysql_database
+dbcheck
+delete_catalog_backup
+drop_bacula_tables
+drop_mysql_tables
+make_bacula_tables
+make_catalog_backup
+make_mysql_tables
+mtx-changer
+query.sql
+bsmtp
+startmysql
+stopmysql
+bwx-console
+bwx-console.conf
+9 man pages
+\end{verbatim}
+\normalsize
+
+\label{monitor}
+
+\section{Installing Tray Monitor}
+\index[general]{Monitor!Installing Tray}
+\index[general]{Installing Tray Monitor}
+
+The Tray Monitor is already installed if you used the {\bf
+\verb:--:enable-tray-monitor} configure option and ran {\bf make install}.
+
+As you don't run your graphical environment as root (if you do, you should
+change that bad habit), don't forget to allow your user to read {\bf
+tray-monitor.conf}, and to execute {\bf bacula-tray-monitor} (this is not a
+security issue).
+
+Then log into your graphical environment (KDE, GNOME or something else), run
+{\bf bacula-tray-monitor} as your user, and see if a cassette icon appears
+somewhere on the screen, usually on the task bar.
+If it doesn't, follow the instructions below related to your environment or
+window manager.
+
+\subsection{GNOME}
+\index[general]{GNOME}
+
+System tray, or notification area if you use the GNOME terminology, has been
+supported in GNOME since version 2.2. To activate it, right-click on one of
+your panels, open the menu {\bf Add to this Panel}, then {\bf Utility} and
+finally click on {\bf Notification Area}.
+
+\subsection{KDE}
+\index[general]{KDE}
+
+System tray has been supported in KDE since version 3.1. To activate it,
+right-click on one of your panels, open the menu {\bf Add}, then {\bf Applet}
+and finally click on {\bf System Tray}.
+
+\subsection{Other window managers}
+\index[general]{Managers!Other window}
+\index[general]{Other window managers}
+
+Read the documentation to know if the Freedesktop system tray standard is
+supported by your window manager, and if applicable, how to activate it.
+
+\section{Modifying the Bacula Configuration Files}
+\index[general]{Modifying the Bacula Configuration Files}
+\index[general]{Files!Modifying the Bacula Configuration}
+
+See the chapter
+\ilink{Configuring Bacula}{ConfigureChapter} in this manual for
+instructions on how to set Bacula configuration files.
projects / bacula / docs / blobdiff