+++ /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-5.0.0.tar.gz]
- This is the primary source code release for Bacula. On each
- release the version number (5.0.0) will be updated.
-
-\item [bacula-docs-5.0.0.tar.bz2]
- This file contains a copy of the docs directory with the
- documents prebuild. English HTML directory, single HTML
- file, and pdf file. The French, German, Spanish translations
- are in progress, but are not built.
-
-\item [bacula-gui-5.0.0.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-5.0.0.tar.gz]
- This is the Bacula Rescue USB key code. Note, the version number
- of this package is not always tied to the Bacula release version, so
- it may be different. Using this code, you can create a USB key
- 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.
-
-\item [win32bacula-5.0.0.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, but
- VSS support is not available if you are running a 64 bit
- version of Windows. This installer installs only the FD,
- the Director and Storage daemon are not included.
-
-
-\item [win64bacula-5.0.0.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}
-
-
-\section{Upgrading Bacula}\label{upgrading1}
-\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{lstlisting}
-cd <installed-scripts-dir> (default /etc/bacula)
-./update_bacula_tables
-\end{lstlisting}
-
-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{lstlisting}
-./configure (your options)
-make
-make install
-\end{lstlisting}
-
-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 \bsysxrlink{Upgrading Bacula Versions}{upgrading}{problems}{section} of the \problemsman{}.
-
-\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{lstlisting}
-major.minor.release
-\end{lstlisting}
-
-For example:
-\begin{lstlisting}
-1.38.11
-\end{lstlisting}
-
-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{bsysitemize}
-\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{bsysitemize}
-
-
-\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-18Dec.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:
-
-\LTXtable{0.95\linewidth}{table_dependencies}
-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{lstlisting}
-cd bacula/depkgs
-make sqlite
-\end{lstlisting}
-\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.
-
-Note, the {\bf depkgs-qt} package is required for building bat, because
-bat is currently built with Qt version 4.3.4. It can be built with other
-Qt versions, but that almost always creates problems or introduces
-instabilities.
-
-You can build the depkgs-qt with the following:
-
-\footnotesize
-\begin{lstlisting}
-cd bacula
-tar xfvz depkgs-qt-28Jul09.tar.gz
-cd depkgs-qt
-make qt4
-source qt4-path
-\end{lstlisting}
-\normalsize
-
-Doing the {\bf source qt4-path} defines the following environment
-variables:
-
-\footnotesize
-\begin{lstlisting}
-QTDIR
-QTLIB
-QTINC
-\end{lstlisting}
-\normalsize
-
-Each one should point to a specific location in the depkgs-qt package
-that you loaded. It also puts the depkgs-qt/qt4/bin directory
-on your path before all other directories. This ensures that
-the bat build will use your Qt 4.3.4 library rather than any that
-might be on your system.
-
-Before running your Bacula build, please make sure that
-{\bf qmake-qt4} is not on your path. If it is please rename it. If
-you don't do this, Bacula will attempt to build with any Qt4 package
-installed on your system rather than the one you just built.
-If you logoff and log back in, you must re-source the depkgs-qt/qt4-patch
-file before attempting to rebuild the bat part of Bacula.
-
-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{lstlisting}
- make distclean
-\end{lstlisting}
-\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{lstlisting}
- make uninstall
- make distclean
- ./configure (your-new-options)
- make
- make install
-
-\end{lstlisting}
-\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{lstlisting}
-make distclean
-\end{lstlisting}
-\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{lstlisting}
-CFLAGS="-g -Wall" \
- ./configure \
- --sbindir=/opt/bacula/bin \
- --sysconfdir=/opt/bacula/etc \
- --with-pid-dir=/var/run \
- --with-subsys-dir=/var/run \
- --with-mysql \
- --with-working-dir=/opt/bacula/working \
- --with-dump-email=$USER
-\end{lstlisting}
-\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 \lstinline:--:enable-conio} or {\bf \lstinline:--: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{lstlisting}
-/usr/lib/gcc-lib/i586-suse-linux/3.3.1/.../ld:
-cannot find -ltermcap
-collect2: ld returned 1 exit status
-\end{lstlisting}
-\normalsize
-
-while building the Bacula Console. In that case, you will need to set the {\bf
-LDFLAGS} environment variable prior to building.
-
-\footnotesize
-\begin{lstlisting}
-export LDFLAGS="-L/usr/lib/termcap"
-\end{lstlisting}
-\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{lstlisting}
-LDFLAGS="-lssl -lcyrpto" \
- ./configure <your-options>
-\end{lstlisting}
-\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
-\lstinline:--: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 PostgreSQL or MySQL 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 small and medium sized installation (up to
-2,000,000 files per job). 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. PostgreSQL is suitable for any sized installation
-(some sites have much more than 1 billion objects in the Catalog). Bacula uses
-many optimized PostgreSQL functions, and can run more than 10 time faster on
-jobs having millions of files than MySQL (Specially in during restore, accurate
-mode, bvfs queries and when the database server is not on the same host than
-the Director). It's possible to switch from MySQL/SQLite to PostgreSQL, but it
-requires some DBA knowledge.
-
-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
- to use any explicit prefix that you may define. If you do not
- explicitly specify a prefix, Bacula's configure routine will not use
- the default value that ./configure --help prints.
- 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. Note, for security reasons,
- this directory should be unique to Bacula and not read/writable by
- any other user/group than Bacula is running under.
-
-\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{lstlisting}
-$ 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{lstlisting}
-
- 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 \lstinline:--: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
- \lstinline:--: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 \lstinline:--: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. However, you must ensure that all the libraries are
- loaded including {\bf libssl-dev} or the equivalent on your
- system. 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.
-
- If you get errors linking, you need to load the development libraries,
- or you need to disable SSL by setting without-openssl.
-
-
-\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
- \bsysxrlink{Python Scripting}
- {PythonChapter}{misc}{chapter} of the \miscman{} 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-baseport=\lt{}port=number\gt{}]
- \index[general]{{-}{\-}with-baseport}
- 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
- \lstinline:--: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
-\lstinline:--: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{lstlisting}
-./configure \
- --enable-smartalloc \
- --sbindir=/opt/bacula/bin \
- --sysconfdir=/opt/bacula/etc \
- --with-pid-dir=/opt/bacula/working \
- --with-subsys-dir=/opt/bacula/working \
- --with-working-dir=/opt/bacula/working
-\end{lstlisting}
-\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 \lstinline:--:sbindir and \lstinline:--: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{lstlisting}
-
-CFLAGS="-g -Wall" ./configure \
- --sbindir=/opt/bacula/bin \
- --sysconfdir=/opt/bacula/etc \
- --enable-smartalloc \
- --with-sqlite=$HOME/bacula/depkgs/sqlite \
- --with-working-dir=/opt/bacula/working \
- --with-pid-dir=/opt/bacula/working \
- --with-subsys-dir=/opt/bacula/working \
- --enable-bat \
- --enable-readline
-\end{lstlisting}
-\normalsize
-
-or
-
-\footnotesize
-\begin{lstlisting}
-
-CFLAGS="-g -Wall" ./configure \
- --sbindir=/opt/bacula/bin \
- --sysconfdir=/opt/bacula/etc \
- --enable-smartalloc \
- --with-mysql \
- --with-working-dir=/opt/bacula/working
- --with-pid-dir=/opt/bacula/working \
- --with-subsys-dir=/opt/bacula/working
- --enable-readline
-\end{lstlisting}
-\normalsize
-
-or finally, a completely traditional Red Hat Linux install,
-which we do not recommend, because it make it harder to
-backup Bacula for disaster recovery purposes:
-
-\footnotesize
-\begin{lstlisting}
-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-readline
-\end{lstlisting}
-\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{lstlisting}
-#!/bin/sh
-CFLAGS="-g" ./configure \
- --sbindir=/opt/bacula/bin \
- --sysconfdir=/opt/bacula/etc \
- --with-mysql \
- --enable-smartalloc \
- --with-pid-dir=/opt/bacula/working \
- --with-subsys-dir=/opt/bacula/working \
- --with-working-dir=/opt/bacula/working
-\end{lstlisting}
-\normalsize
-
-Note, you may need to install the following packages to build Bacula
-from source:
-\footnotesize
-\begin{lstlisting}
-SUNWbinutils,
-SUNWarc,
-SUNWhea,
-SUNWGcc,
-SUNWGnutls
-SUNWGnutls-devel
-SUNWGmake
-SUNWgccruntime
-SUNWlibgcrypt
-SUNWzlib
-SUNWzlibs
-SUNWreadline
-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{lstlisting}
-\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{lstlisting}
-setenv LDFLAGS "-L/usr/sfw/lib -R/usr/sfw/lib"
-\end{lstlisting}
-\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
-\bsysxrlink{Tape Testing}{FreeBSDTapes}{problems}{section} of \problemsman{} for
-{\bf important} information on how to configure your tape drive for
-compatibility with \mbacula{}.
-
-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 directory (except for the working directory):
-
-\footnotesize
-\begin{lstlisting}
-#!/bin/sh
-CFLAGS="-g -Wall" \
- ./configure \
- --sbindir=$HOME/bacula/bin \
- --sysconfdir=$HOME/bacula/bin \
- --mandir=$HOME/bacula/bin \
- --enable-smartalloc \
- --enable-bat \
- --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{lstlisting}
-\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{lstlisting}
-bacula-dir 9101/tcp
-bacula-fd 9102/tcp
-bacula-sd 9103/tcp
-\end{lstlisting}
-\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{lstlisting}
-make install
-\end{lstlisting}
-\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 \lstinline:--:with-mysql} or {\bf \lstinline:--:with-sqlite} options, then
-add {\bf \lstinline:--: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{lstlisting}
-(become root)
-make install-autostart
-\end{lstlisting}
-\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{lstlisting}
-make install-autostart-fd
-\end{lstlisting}
-\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{lstlisting}
-make
-\end{lstlisting}
-\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{lstlisting}
-make clean
-\end{lstlisting}
-\normalsize
-
-To really clean out everything for distribution, enter:
-
-\footnotesize
-\begin{lstlisting}
-make distclean
-\end{lstlisting}
-\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{lstlisting}
-make depend
-\end{lstlisting}
-\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{lstlisting}
-make install
-\end{lstlisting}
-\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{lstlisting}
-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{lstlisting}
-\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
-\lstinline:--: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.
--- /dev/null
+%%
+%%
+
+\chapter{Manually Installing Bacula}
+\label{InstallChapter}
+\index[general]{Bacula!Installing Manually}
+\index[general]{Manually 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}
+ The Bacula 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-5.2.0.tar.gz]
+ This is the primary source code release for Bacula. On each
+ release the version number (5.2.0) will be updated.
+
+\item [bacula-docs-5.2.0.tar.bz2]
+ This file contains a copy of the docs directory with the
+ documents prebuild. English HTML directory, single HTML
+ file, and pdf file. The French, German, Spanish translations
+ are in progress, but are not built.
+
+\item [bacula-gui-5.2.0.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-5.2.0.tar.gz]
+ This is the Bacula Rescue USB key code. Note, the version number
+ of this package is not always tied to the Bacula release version, so
+ it may be different. Using this code, you can create a USB key
+ 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.
+
+\item [win32bacula-5.2.0.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, but
+ VSS support is not available if you are running a 64 bit
+ version of Windows. This installer installs only the FD,
+ the Director and Storage daemon are not included.
+
+
+\item [win64bacula-5.2.0.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}
+
+
+
+\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{lstlisting}
+ make distclean
+\end{lstlisting}
+\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{lstlisting}
+ make uninstall
+ make distclean
+ ./configure (your-new-options)
+ make
+ make install
+
+\end{lstlisting}
+\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{lstlisting}
+make distclean
+\end{lstlisting}
+\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{lstlisting}
+CFLAGS="-g -Wall" \
+ ./configure \
+ --sbindir=/opt/bacula/bin \
+ --sysconfdir=/opt/bacula/etc \
+ --with-pid-dir=/var/run \
+ --with-subsys-dir=/var/run \
+ --with-mysql \
+ --with-working-dir=/opt/bacula/working \
+ --with-dump-email=$USER
+\end{lstlisting}
+\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 \lstinline:--:enable-conio} or {\bf \lstinline:--: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{lstlisting}
+/usr/lib/gcc-lib/i586-suse-linux/3.3.1/.../ld:
+cannot find -ltermcap
+collect2: ld returned 1 exit status
+\end{lstlisting}
+\normalsize
+
+while building the Bacula Console. In that case, you will need to set the {\bf
+LDFLAGS} environment variable prior to building.
+
+\footnotesize
+\begin{lstlisting}
+export LDFLAGS="-L/usr/lib/termcap"
+\end{lstlisting}
+\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{lstlisting}
+LDFLAGS="-lssl -lcyrpto" \
+ ./configure <your-options>
+\end{lstlisting}
+\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
+\lstinline:--: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{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
+ to use any explicit prefix that you may define. If you do not
+ explicitly specify a prefix, Bacula's configure routine will not use
+ the default value that ./configure --help prints.
+ 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. Note, for security reasons,
+ this directory should be unique to Bacula and not read/writable by
+ any other user/group than Bacula is running under.
+
+\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{lstlisting}
+$ 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{lstlisting}
+
+ 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 \lstinline:--: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
+ \lstinline:--: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 \lstinline:--: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. However, you must ensure that all the libraries are
+ loaded including {\bf libssl-dev} or the equivalent on your
+ system. 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.
+
+ If you get errors linking, you need to load the development libraries,
+ or you need to disable SSL by setting without-openssl.
+
+
+\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
+ \bsysxrlink{Python Scripting}
+ {PythonChapter}{misc}{chapter} of the \miscman{} 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-baseport=\lt{}port=number\gt{}]
+ \index[general]{{-}{\-}with-baseport}
+ 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
+ \lstinline:--: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
+\lstinline:--: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{lstlisting}
+./configure \
+ --enable-smartalloc \
+ --sbindir=/opt/bacula/bin \
+ --sysconfdir=/opt/bacula/etc \
+ --with-pid-dir=/opt/bacula/working \
+ --with-subsys-dir=/opt/bacula/working \
+ --with-working-dir=/opt/bacula/working
+\end{lstlisting}
+\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 \lstinline:--:sbindir and \lstinline:--: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{lstlisting}
+
+CFLAGS="-g -Wall" ./configure \
+ --sbindir=/opt/bacula/bin \
+ --sysconfdir=/opt/bacula/etc \
+ --enable-smartalloc \
+ --with-sqlite=$HOME/bacula/depkgs/sqlite \
+ --with-working-dir=/opt/bacula/working \
+ --with-pid-dir=/opt/bacula/working \
+ --with-subsys-dir=/opt/bacula/working \
+ --enable-bat \
+ --enable-readline
+\end{lstlisting}
+\normalsize
+
+or
+
+\footnotesize
+\begin{lstlisting}
+
+CFLAGS="-g -Wall" ./configure \
+ --sbindir=/opt/bacula/bin \
+ --sysconfdir=/opt/bacula/etc \
+ --enable-smartalloc \
+ --with-mysql \
+ --with-working-dir=/opt/bacula/working
+ --with-pid-dir=/opt/bacula/working \
+ --with-subsys-dir=/opt/bacula/working
+ --enable-readline
+\end{lstlisting}
+\normalsize
+
+or finally, a completely traditional Red Hat Linux install,
+which we do not recommend, because it make it harder to
+backup Bacula for disaster recovery purposes:
+
+\footnotesize
+\begin{lstlisting}
+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-readline
+\end{lstlisting}
+\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{lstlisting}
+#!/bin/sh
+CFLAGS="-g" ./configure \
+ --sbindir=/opt/bacula/bin \
+ --sysconfdir=/opt/bacula/etc \
+ --with-mysql \
+ --enable-smartalloc \
+ --with-pid-dir=/opt/bacula/working \
+ --with-subsys-dir=/opt/bacula/working \
+ --with-working-dir=/opt/bacula/working
+\end{lstlisting}
+\normalsize
+
+Note, you may need to install the following packages to build Bacula
+from source:
+\footnotesize
+\begin{lstlisting}
+SUNWbinutils,
+SUNWarc,
+SUNWhea,
+SUNWGcc,
+SUNWGnutls
+SUNWGnutls-devel
+SUNWGmake
+SUNWgccruntime
+SUNWlibgcrypt
+SUNWzlib
+SUNWzlibs
+SUNWreadline
+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{lstlisting}
+\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{lstlisting}
+setenv LDFLAGS "-L/usr/sfw/lib -R/usr/sfw/lib"
+\end{lstlisting}
+\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
+\bsysxrlink{Tape Testing}{FreeBSDTapes}{problems}{section} of \problemsman{} for
+{\bf important} information on how to configure your tape drive for
+compatibility with \mbacula{}.
+
+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 directory (except for the working directory):
+
+\footnotesize
+\begin{lstlisting}
+#!/bin/sh
+CFLAGS="-g -Wall" \
+ ./configure \
+ --sbindir=$HOME/bacula/bin \
+ --sysconfdir=$HOME/bacula/bin \
+ --mandir=$HOME/bacula/bin \
+ --enable-smartalloc \
+ --enable-bat \
+ --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{lstlisting}
+\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{lstlisting}
+bacula-dir 9101/tcp
+bacula-fd 9102/tcp
+bacula-sd 9103/tcp
+\end{lstlisting}
+\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{lstlisting}
+make install
+\end{lstlisting}
+\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 \lstinline:--:with-mysql} or {\bf \lstinline:--:with-sqlite} options, then
+add {\bf \lstinline:--: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{lstlisting}
+(become root)
+make install-autostart
+\end{lstlisting}
+\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{lstlisting}
+make install-autostart-fd
+\end{lstlisting}
+\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{lstlisting}
+make
+\end{lstlisting}
+\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{lstlisting}
+make clean
+\end{lstlisting}
+\normalsize
+
+To really clean out everything for distribution, enter:
+
+\footnotesize
+\begin{lstlisting}
+make distclean
+\end{lstlisting}
+\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{lstlisting}
+make depend
+\end{lstlisting}
+\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{lstlisting}
+make install
+\end{lstlisting}
+\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{lstlisting}
+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{lstlisting}
+\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
+\lstinline:--: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 / commitdiff