%%
%%
-\section*{Installing Bacula}
-\label{_ChapterStart17}
-\index[general]{Bacula!Installing }
-\index[general]{Installing Bacula }
-\addcontentsline{toc}{section}{Installing Bacula}
-
-\subsection*{General}
-\index[general]{General }
-\addcontentsline{toc}{subsection}{General}
-
-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 SQLite}, {\bf MySQL}, or
-{\bf PostgreSQL}
-to build properly depending on the options you specify. To simplify your task,
-we have combined a number of these packages into two {\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.
-
-\subsection*{Source Release Files}
+\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 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 two {\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}
-\addcontentsline{toc}{subsection}{Source Release File}
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 CVS. The released files are:
+the Bacula SVN. The released files are:
\begin{description}
-\item [bacula-1.38.0.tar.gz]
+\item [bacula-2.0.3.tar.gz]
This is the primary source code release for Bacula. On each
- release the version number (1.38.0) will be updated.
+ release the version number (2.0.3) will be updated.
-\item [bacula-docs-1.38.0.tar.gz]
+\item [bacula-docs-2.0.3.tar.gz]
This file contains a copy of the docs directory with the
- documents prebuild. English html directory, single html
+ documents prebuild. English HTML directory, single HTML
file, and pdf file. The French and German translations
are in progress, but are not built.
-\item [bacula-gui-1.38.0.tar.gz]
+\item [bacula-gui-2.0.3.tar.gz]
This file contains the non-core GUI programs. Currently,
it contains bacula-web, a PHP program for producing management
viewing of your Bacula job status in a browser; and bimagemgr
a browser program for burning CDROM images with Bacula Volumes.
-\item [bacula-rescue-1.8.1.tar.gz]
+\item [bacula-rescue-2.0.0.tar.gz]
This is the Bacula Rescue CDROM code. Note, the version number
of this package is not tied to the Bacula release version, so
it will be different. Using this code, you can burn a CDROM
repartition and reformat your hard disks and reload your
system with Bacula in the case of a hard disk failure.
-\item [winbacula-1.38.0.exe]
+ Note, this package evolves slower than the Bacula source code,
+ so there may not always be a new release of the rescue package when
+ making minor updates to the Bacula code. For example, when releasing
+ Bacula version 2.0.3, the rescue package may still be at version
+ 2.0.0 if there were no updates.
+
+\item [winbacula-2.0.3.exe]
This file is the 32 bit Windows installer for installing
the Windows client (File daemon) on a Windows machine.
+ This client will also run on 64 bit Windows machines.
+ Beginning with Bacula version 1.39.20, this executable will
+ also optionally load the Win32 Director and the Win32
+ Storage daemon.
\end{description}
\label{upgrading1}
-\subsection*{Upgrading Bacula}
-\index[general]{Bacula!Upgrading }
-\index[general]{Upgrading Bacula }
-\addcontentsline{toc}{subsection}{Upgrading Bacula}
+\section{Upgrading Bacula}
+\index[general]{Bacula!Upgrading}
+\index[general]{Upgrading Bacula}
+\index[general]{Upgrading}
If you are upgrading from one Bacula version to another, you should first
-carefully read the ReleaseNotes of all versions between your current version
-and the version to which you are upgrading. If the Bacula catalog database has
-been upgraded, you will either need to reinitialize your database starting
-from scratch, or save an ASCII copy of your database, then proceed to upgrade
-it. This is normally done after Bacula is build and installed by:
+carefully read the ReleaseNotes of all major versions between your current
+version and the version to which you are upgrading. If the Bacula catalog
+database has been upgraded (as it is almost every major release), you will
+either need to reinitialize your database starting from scratch (not
+normally a good idea), or save an ASCII copy of your database, then proceed
+to upgrade it. If you are upgrading two major versions (e.g. 1.36 to 2.0)
+then life will be more complicated because you must do two database
+upgrades. See below for more on this.
+
+Upgrading the catalog is normally done after Bacula is build and installed
+by:
\begin{verbatim}
cd <installed-scripts-dir> (default /etc/bacula)
they will note if all daemons must be upgraded at the same time.
Finally, please note that in general it is not necessary to do a
-{\bf make uninstall} before doing an upgrade. In fact, if you do so, you will
+{\bf make uninstall} before doing an upgrade providing you are careful
+not to change the installation directories. In fact, if you do so, you will
most likely delete all your conf files, which could be disastrous.
The normal procedure during an upgrade is simply:
+
\begin{verbatim}
./configure (your options)
make
make install
\end{verbatim}
-In general none of your existing .conf or .sql files will be overwritten.
-
+In general none of your existing .conf or .sql files will be overwritten,
+and you must do both the {\bf make} and {\bf make install} commands, a
+{\bf make install} without the preceding {\bf make} will not work.
+
For additional information on upgrading, please see the \ilink{Upgrading Bacula
Versions}{upgrading} in the Tips chapter of this manual.
+\section{Releases Numbering}
+\index[general]{Release Numbering}
+\index[general]{Version Numbering}
+Every Bacula release whether beta or production has a different number
+as well as the date of the release build. The numbering system follows
+traditional Open Source conventions in that it is of the form.
+
+\begin{verbatim}
+major.minor.release
+\end{verbatim}
+
+For example:
+\begin{verbatim}
+1.38.11
+\end{verbatim}
+
+where each component (major, minor, patch) is a number.
+The major number is currently 1 and normally does not change
+very frequently. The minor number starts at 0 and increases
+each for each production release by 2 (i.e. it is always an
+even number for a production release), and the patch number is
+starts at zero each time the minor number changes. The patch
+number is increased each time a bug fix (or fixes) is released
+to production.
+
+So, as of this date (10 September 2006), the current production Bacula
+release is version 1.38.11. If there are bug fixes, the next release
+will be 1.38.12 (i.e. the patch number has increased by one).
+
+For all patch releases where the minor version number does not change,
+the database and all the daemons will be compatible. That means that
+you can safely run a 1.38.0 Director with a 1.38.11 Client. Of course,
+in this case, the Director may have bugs that are not fixed. Generally,
+within a minor release (some minor releases are not so minor), all
+patch numbers are officially released to production. This means that while
+the current Bacula version is 1.38.11, versions 1.38.0, 1.38.1, ... 1.38.10
+have all been previously released.
+
+When the minor number is odd, it indicates that the package is under
+development and thus may not be stable. For example, while the current
+production release of Bacula is currently 1.38.11, the current development
+version is 1.39.22. All patch versions of the development code are
+available in the CVS (source repository). However, not all patch versions
+of the development code (odd minor version) are officially released. When
+they are released, they are released as beta versions (see below for a
+definition of what beta means for Bacula releases).
+
+In general when the minor number increases from one production release
+to the next (i.e. 1.38.x to 1.40.0), the catalog database must be upgraded,
+the Director and Storage daemon must always be on the same minor release
+number, and often (not always), the Clients must also be on the same minor
+release. As often as possible, we attempt to make new releases that are
+downwards compatible with prior clients, but this is not always possible.
+You must check the release notes. In general, you will have fewer problems
+if you always run all the components on the same minor version number (i.e.
+all either 1.38.x or 1.40.x but not mixed).
+
+
+\label{BetaReleases}
+\section*{Beta Releases}
+\index[general]{Beta Releases}
+Towards the end of the development cycle, which typically runs
+one year from a major release to another, there will be several beta
+releases of the development code prior to a production release.
+As noted above, beta versions always have odd minor version numbers
+(e.g 1.37.x or 1.39.x).
+The purpose of the beta releases is to allow early adopter users to test
+the new code. Beta releases are made with the following considerations:
+
+\begin{itemize}
+\item The code passes the regression testing on Linux and
+ FreeBSD machines. Including tape drive testing
+ on Linux and FreeBSD.
+
+\item There are no known major bugs, or on the rare occasion that
+ there are, they will be documented or already in the bugs database.
+
+\item Some of the new code/features may not yet be tested.
+
+\item Bugs are expected to be found, especially in the new
+ code before the final production release.
+
+\item The code will have been run in production in at least one small
+ site (mine).
+
+\item The Win32 client will have been run in production at least
+ one night at that small site.
+
+\item The documentation in the manual is unlikely to be complete especially
+ for the new features, and the Release Notes may not be fully
+ organized.
+
+\item Beta code is not generally recommended for everyone, but
+ rather for early adopters.
+\end{itemize}
+
-\subsection*{Dependency Packages}
\label{Dependency}
-\index[general]{Dependency Packages }
-\index[general]{Packages!Dependency }
-\addcontentsline{toc}{subsection}{Dependency Packages}
+\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} and {\bf depkgs1} releases. You can,
-of course, get the latest packages from the original authors. The locations of
+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} and
-{\bf depkgs1-ddMMyy.tar.gz} where {\bf dd} is the day we release it, {\bf MMM}
+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-07Apr02.tar.gz}. To install and build this package (if
needed), you do the following:
to time, the current makeup is the following:
\addcontentsline{lot}{table}{Dependency Packages}
-\begin{longtable}{|l|l|l|l|}
+\begin{longtable}{|l|l|}
+ \hline
+\multicolumn{1}{|c| }{\bf 3rd Party Package} & \multicolumn{1}{c| }{\bf depkgs} \\
+ \hline {SQLite } & \multicolumn{1}{c| }{X } \\
+ \hline {SQLite3 } & \multicolumn{1}{c| }{X } \\
+ \hline {mtx } & \multicolumn{1}{c| }{X } \\
\hline
-\multicolumn{1}{|c| }{\bf 3rd Party Package } & \multicolumn{1}{c| }{\bf
-depkgs } & \multicolumn{1}{c| }{\bf depkgs1 } & \multicolumn{1}{c| }{\bf
-depkgs-win32 } \\
- \hline {SQLite } & \multicolumn{1}{c| }{X } & \multicolumn{1}{c| }{- } &
-\multicolumn{1}{c| }{- } \\
- \hline {mtx } & \multicolumn{1}{c| }{X } & \multicolumn{1}{c| }{- } &
-\multicolumn{1}{c| }{- } \\
- \hline {readline } & \multicolumn{1}{c| }{- } & \multicolumn{1}{c| }{X } &
-\multicolumn{1}{c| }{- } \\
- \hline {pthreads } & \multicolumn{1}{c| }{- } & \multicolumn{1}{c| }{- } &
-\multicolumn{1}{c| }{X } \\
- \hline {zlib } & \multicolumn{1}{c| }{- } & \multicolumn{1}{c| }{- } &
-\multicolumn{1}{c| }{X } \\
- \hline {wxWidgets } & \multicolumn{1}{c| }{- } & \multicolumn{1}{c| }{- } &
-\multicolumn{1}{c| }{X }
-\\ \hline
-
\end{longtable}
Note, some of these packages are quite large, so that building them can be a
will configure and build only the SQLite package.
-You should build the packages that you will require in {\bf depkgs} and/or
-{\bf depkgs1} prior to configuring and building Bacula, since Bacula will need
+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.
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, ...).
+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 contains the source code for the pthreads,
-zlib, and wxWidgets libraries used by the native Win32 client program. It
-will only be needed if you intend to build the Win32 client from source.
+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.
-\subsection*{Supported Operating Systems}
+\section{Supported Operating Systems}
\label{Systems}
-\index[general]{Systems!Supported Operating }
-\index[general]{Supported Operating Systems }
-\addcontentsline{toc}{subsection}{Supported Operating 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.
-\subsection*{Building Bacula from Source}
+\section{Building Bacula from Source}
\label{Building}
-\index[general]{Source!Building Bacula from }
-\index[general]{Building Bacula from Source }
-\addcontentsline{toc}{subsection}{Building Bacula from Source}
+\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.
+\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}{_ChapterStart} or
+ \ilink{Installing and Configuring MySQL Phase I}{MySqlChapter} or
\ilink{Installing and Configuring PostgreSQL Phase
- I}{_ChapterStart10}. If you are installing from rpms, and are
+ 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
can skip this phase provided that you have built the thread safe libraries.
And you have already installed the additional rpms noted above.
-\item As an alternative to MySQL and PostgreSQL, configure and install SQLite,
- which is part of the {\bf depkgs}.
- \ilink{Installing and Configuring SQLite}{_ChapterStart33}. SQLite is
- probably not suited to a fair size production environment because it
- tends to be slow compared to MySQL and it has few or poor tools for
- repairing database damage.
-
+ SQLite is not supported on Solaris. This is because it
+ frequently fails with bus errors.
\item Detar the Bacula source code preferably into the {\bf bacula} directory
discussed above.
continue on.
\item make
-\begin{verbatim}
-
-\end{verbatim}
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.
\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}{_ChapterStart16} in the Configuration chapter of this manual. We
+ 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
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{Installing and Configuring PostgreSQL Phase
- II}{PostgreSQL_phase2} or alternatively if you are using
- SQLite
- \ilink{Installing and Configuring SQLite Phase II}{phase2}.
+ \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}{_ChapterStart1} chapter of this manual,
+ \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
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 (RedHat), and Solaris are supported. MacOS X 10.3 is
-reported to work with the Client only as long as readline support is disabled.
-
+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
configure} statement to ensure that the modules you want are built and that
everything is placed into the correct directories.
-For example, on RedHat, one could use the following:
+For example, on Fedora, Red Hat, or SuSE one could use the following:
\footnotesize
\begin{verbatim}
--sysconfdir=$HOME/bacula/bin \
--with-pid-dir=$HOME/bacula/bin/working \
--with-subsys-dir=$HOME/bacula/bin/working \
- --with-mysql=$HOME/mysql \
+ --with-mysql \
--with-working-dir=$HOME/bacula/bin/working \
--with-dump-email=$USER
\end{verbatim}
The {\bf \verb:--:enable-conio} or {\bf \verb:--:enable-readline} options are useful because
they provide a command line history and editing capability for the Console
program. If you have included either option in the build, either the {\bf
-termcap} or the {\bf ncurses} package will be needed to link. 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:
+termcap} or the {\bf ncurses} package will be needed to link. On most
+systems, including Red Hat and SuSE, you should include the ncurses package.
+If Bacula's configure process finds the ncurses libraries, it will use
+those rather than the termcap library.
+On some systems, such as SuSE, the termcap library is not in the standard
+library directory. As a consequence, the option may be disabled or you may
+get an error message such as:
\footnotesize
\begin{verbatim}
\footnotesize
\begin{verbatim}
LDFLAGS="-lssl -lcyrpto" \
- ./configure \
- <your-options>
+ ./configure <your-options>
\end{verbatim}
\normalsize
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, I will
+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, I can no longer afford to
+are significant differences between systems, we can no longer afford to
support it.
-\subsection*{What Database to Use?}
+\section{What Database to Use?}
\label{DB}
-\index[general]{What Database to Use? }
-\index[general]{Use!What Database to }
-\addcontentsline{toc}{subsection}{What Database to Use?}
+\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. This will greatly simplify the setup for you
+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
work.
If you wish to use MySQL as the Bacula catalog, please see the
-\ilink{Installing and Configuring MySQL}{_ChapterStart} chapter of
+\ilink{Installing and Configuring MySQL}{MySqlChapter} chapter of
this manual. You will need to install MySQL prior to continuing with the
configuration of Bacula. MySQL is a high quality database that is very
efficient and is suitable for any sized installation. It is slightly more
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}{_ChapterStart10}
+\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
requires a certain knowledge to install and maintain.
If you wish to use SQLite as the Bacula catalog, please see
-\ilink{Installing and Configuring SQLite}{_ChapterStart33} chapter of
-this manual.
+\ilink{Installing and Configuring SQLite}{SqlLiteChapter} chapter of
+this manual. SQLite is not supported on Solaris.
-\subsection*{Quick Start}
-\index[general]{Quick Start }
-\index[general]{Start!Quick }
-\addcontentsline{toc}{subsection}{Quick Start}
+\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
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.
-\subsection*{Configure Options}
+\section{Configure Options}
\label{Options}
-\index[general]{Options!Configure }
-\index[general]{Configure Options }
-\addcontentsline{toc}{subsection}{Configure 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 [ {-}{-}sysbindir=\lt{}binary-path\gt{}]
- \index[general]{{-}{-}sysbindir }
+\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 }
+ \index[general]{{-}{-}sysconfdir}
Defines where the Bacula configuration files should be placed during a
{\bf make install} command.
\item [ {-}{-}mandir=\lt{}path\gt{}]
\index[general]{{-}{-}mandir}
Note, as of Bacula version 1.39.14, the meaning of any path
- specified is now changed to mean the top level man directory.
+ 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
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{}]
+\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 }
+ \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.
keeping this option enabled as it helps detect memory leaks. This
configuration parameter is used while building Bacula
+\item [ {-}{-}enable-bat ]
+ \index[general]{{-}{-}enable-bat}
+ If you have Qt4 >= 4.2 installed on your computer including the
+ libqt4 and libqt4-devel 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. In addition to the Qt4 libraries, bat
+ needs the qwt package installed on your system. Please see the
+ next configure item for the details.
+
+\item [ {-}{-}with-qwt=\lt{}path\gt{} ]
+ \index[general]{{-}{-}with-qwt}
+ To build bat, you need the qwt graphics package installed on
+ your system. The qwt package is available for download from
+ the qwt project on Source Forge. If you wish, you may build and
+ install it on your system (by default in /usr/lib). If you have
+ done so, you would specify:
+
+\begin{verbose}
+ --with-qwt=/usr/lib/qwt-5.0.2
+\end{verbose}
+
+ Alternatively, you can download the Bacula depkgs package (currently
+ version 11Jul07) and build it, then assuming that you have put it
+ into a directory named bacula, you would specify:
+
+\begin{verbose}
+ --with-qwt=$HOME/bacula/depkgs/qwt
+\end{verbose}
+
+
+\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. SQLite2 is not thread safe, so this option cannot
+ be enabled when using it. However, on most systems, PostgreSQL,
+ and SQLite3 are thread safe. Bacula always links to the thread safe
+ MySQL libraries.
+
+ As far as we can determine SQLite2 is not thread safe and so should
+ not be used if you have enabled batch insert in Bacula.
+
+ As a default, Bacula runs SQLite3 with {\bf PRAGMA synchronous=OFF}
+ because it improves performance by more than 30 times. However, it
+ increases the possibility of a corrupted database. If you want more
+ security, please modify src/version.h appropriately (it should be
+ obvious when you look at the file).
+
\item [ {-}{-}enable-gnome ]
- \index[general]{{-}{-}enable-gnome }
+ \index[general]{{-}{-}enable-gnome}
If you have GNOME installed on your computer including the
- gnome development libraries, and you want to use the
+ GNOME development libraries, and you want to use the
GNOME GUI Console interface to Bacula, you must specify this option.
- Doing so will build everything in the {\bf src/gnome-console} directory.
+ Doing so will build everything in the {\bf src/gnome2-console} directory.
-\item [ {-}{-}enable-wx-console ]
- \index[general]{{-}{-}enable-wx-console }
+\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 Gnome, as wxWidgets can work with GTK+, Motif or even X11
+ to install GNOME, as wxWidgets can work with GTK+, Motif or even X11
libraries.
-
\item [ {-}{-}enable-tray-monitor ]
- \index[general]{{-}{-}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
everything in the {\bf src/tray-monitor} directory.
\item [ {-}{-}enable-static-tools]
- \index[general]{{-}{-}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
not enabled this option, or explicitly disable static linking by adding
{\bf \verb:--:disable-static-tools}.
-
\item [ {-}{-}enable-static-fd]
- \index[general]{{-}{-}enable-static-fd }
+ \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.
\item [ {-}{-}enable-static-sd]
- \index[general]{{-}{-}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
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 }
+ \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
\item [ {-}{-}enable-static-cons]
- \index[general]{{-}{-}enable-static-cons }
+ \index[general]{{-}{-}enable-static-cons}
This option causes the make process to build a {\bf static-console} and
a {\bf static-gnome-console} in addition to the standard console. This
static version will include statically linked libraries and could be
\item [ {-}{-}enable-client-only]
- \index[general]{{-}{-}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
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 }
+ \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
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-sqlite=\lt{}sqlite-path\gt{}]
- \index[general]{{-}{-}with-sqlite }
- This enables use of the SQLite version 2.8.x database. The {\bf sqlite-path} is not
- normally specified as Bacula looks for the necessary components in a
- standard location ({\bf depkgs/sqlite}). See
- \ilink{Installing and Configuring SQLite}{_ChapterStart33} chapter of
- this manual for more details.
+ \index[general]{{-}{-}with-sqlite}
+ This enables use of the SQLite version 2.8.x database. The {\bf
+ sqlite-path} is not normally specified as Bacula looks for the necessary
+ components in a standard location ({\bf depkgs/sqlite}). See
+ \ilink{Installing and Configuring SQLite}{SqlLiteChapter} chapter of
+ this manual for more details. SQLite is not supported on Solaris.
See the note below under the {-}{-}with-postgresql item.
\item [ {-}{-}with-sqlite3=\lt{}sqlite3-path\gt{}]
- \index[general]{{-}{-}with-sqlite3 }
+ \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}{_ChapterStart33} chapter of
- this manual for more details.
+ \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 }
+ \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}{_ChapterStart} chapter before proceeding with the configuration.
+ 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 }
+ \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}.
{-}{-}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)
- in Bacula. Normally, the {\bf path} specification is not necessary since
+ This configuration option is necessary if you want to enable TLS (ssl),
+ which encrypts the communications within
+ Bacula or if you want to use File Daemon PKI data encryption.
+ Normally, the {\bf path} specification is not necessary since
the configuration searches for the OpenSSL libraries in standard system
locations. Enabling OpenSSL in Bacula permits secure communications
- between the daemons. For more information on using TLS, please see the
- \ilink{Bacula TLS}{_ChapterStart61} chapter of this manual.
-
+ between the daemons and/or data encryption in the File daemon.
+ For more information on using TLS, please see the
+ \ilink{Bacula TLS -- Communications Encryption}{CommEncryption} chapter
+ of this manual.
+ For more information on using PKI data encryption, please see the
+ \ilink{Bacula PKI -- Data Encryption}{DataEncryption}
+ chapter of this manual.
\item [ {-}{-}with-python=\lt{}path\gt{}]
- \index[general]{{-}{-}with-python }
- This option enables Bacula support for Python. If no path is
- supplied, configure will search the
- standard library locations for Python 2.2, 2.3, or 2.4. If it cannot
- find the library, you will need to supply a path to your Python
- library directory. Please see the
- \ilink{Python chapter}{_ChapterStart60} for the details of using
- Python scripting.
+ \index[general]{{-}{-}with-python}
+ This option enables Bacula support for Python. If no path is supplied,
+ configure will search the standard library locations for Python 2.2,
+ 2.3, 2.4, or 2.5. If it cannot find the library, you will need to
+ supply a path to your Python library directory. Please see the
+ \ilink{Python chapter}{PythonChapter} for the details of using Python
+ scripting.
\item [ {-}{-}with-libintl-prefix=\lt{}DIR\gt{}]
\index[general]{{-}{-}with-libintl-prefix}
Language Support (NLS).
\item [ {-}{-}enable-conio]
- \index[general]{{-}{-}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 }
+ \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
supported, so you are on your own if you have problems.
\item [ {-}{-}enable-readline]
- \index[general]{{-}{-}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]{{-}{-}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
\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-working-dir=\lt{}working-directory-path\gt{} ]
- \index[general]{{-}{-}with-working-dir }
+ \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
you must ensure that it exists before using Bacula for the first time.
\item [ {-}{-}with-base-port=\lt{}port=number\gt{}]
- \index[general]{{-}{-}with-base-port }
+ \index[general]{{-}{-}with-base-port}
In order to run, Bacula needs three TCP/IP ports (one for the Bacula
Console, one for the Storage daemon, and one for the File daemon). The {\bf
\verb:--:with-baseport} option will automatically assign three ports beginning at
may also accomplish the same thing by directly editing them later.
\item [ {-}{-}with-dump-email=\lt{}email-address\gt{}]
- \index[general]{{-}{-}with-dump-email }
+ \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 }
+ \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 }
+ \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}
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 Directory
+ \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 }
+ \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 Directory
+ \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 }
+ \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
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 }
+ \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
working directory group will be set to {\bf Group}.
\item [ {-}{-}with-sd-user=\lt{}User\gt{} ]
- \index[general]{{-}{-}with-sd-user }
+ \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
it needs.
\item [ {-}{-}with-sd-group=\lt{}Group\gt{} ]
- \index[general]{{-}{-}with-sd-group }
+ \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 }
+ \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
option.
\item [ {-}{-}with-fd-group=\lt{}Group\gt{} ]
- \index[general]{{-}{-}with-fd-group }
+ \index[general]{{-}{-}with-fd-group}
This option allows you to specify the GroupId used to run the File daemon.
The File daemon must be started as root, and in most cases, it must be run as
root, however, after doing preliminary initializations, it can "drop" to
the GroupId specified on this option.
+\item [ {-}{-}with-mon-dir-password=\lt{}Password\gt{}]
+ \index[general]{{-}{-}with-mon-dir-password}
+ This option allows you to specify the password used to access the Directory
+ from the monitor. If it is not specified, configure will
+ automatically create a random password.
+
+\item [ {-}{-}with-mon-fd-password=\lt{}Password\gt{} ]
+ \index[general]{{-}{-}with-mon-fd-password}
+ This option allows you to specify the password used to access the File daemon
+ from the Monitor. If it is not specified, configure will
+ automatically create a random password.
+
+\item [ {-}{-}with-mon-sd-password=\lt{}Password\gt{} ]
+ \index[general]{{-}{-}with-mon-sd-password}
+ This option allows you to specify the password used to access the
+ Storage daemon from the Monitor. If it is not specified, configure will
+ automatically create a random password.
+
+\item [ {-}{-}with-db-name=\lt{}database-name\gt{} ]
+ \index[general]{{-}{-}with-db-name}
+ This option allows you to specify the database name to be used in
+ the conf files. The default is bacula.
+
+\item [ {-}{-}with-db-user=\lt{}database-user\gt{} ]
+ \index[general]{{-}{-}with-db-user}
+ This option allows you to specify the database user name to be used in
+ the conf files. The default is bacula.
+
\end{description}
Note, many other options are presented when you do a {\bf ./configure
\verb:--:help}, but they are not implemented.
-\subsection*{Recommended Options for most Systems}
-\index[general]{Systems!Recommended Options for most }
-\index[general]{Recommended Options for most Systems }
-\addcontentsline{toc}{subsection}{Recommended Options for most Systems}
+\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:
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. See below for an example of how Kern does
-it.
+running Bacula for the first time.
-\subsection*{RedHat}
-\index[general]{RedHat }
-\addcontentsline{toc}{subsection}{RedHat}
+\section{Red Hat}
+\index[general]{Red Hat}
Using SQLite:
--with-working-dir=$HOME/bacula/working \
--with-pid-dir=$HOME/bacula/bin/working \
--with-subsys-dir=$HOME/bacula/bin/working \
- --enable-gnome \
+ --enable-bat \
+ --with-qwt=$HOME/bacula/depkgs/qwt \
--enable-conio
\end{verbatim}
\normalsize
\end{verbatim}
\normalsize
-or finally, a completely traditional RedHat Linux install:
+or finally, a completely traditional Red Hat Linux install:
\footnotesize
\begin{verbatim}
--sysconfdir=/etc/bacula \
--with-scriptdir=/etc/bacula \
--enable-smartalloc \
- --enable-gnome \
+ --enable-bat \
+ --with-qwt=$HOME/bacula/depkgs/qwt \
--with-mysql \
--with-working-dir=/var/bacula \
--with-pid-dir=/var/run \
- --with-subsys-dir=/var/lock/subsys \
--enable-conio
\end{verbatim}
\normalsize
-Note, Bacula assumes that /var/bacula, /var/run, and /var/loc/subsys exist so
+Note, Bacula assumes that /var/bacula, /var/run, and /var/lock/subsys exist so
it will not automatically create them during the install process.
-Note, with gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) on
-an AMD64 CPU running 64 bit CentOS4, there is a compiler bug that generates
-bad code that causes Bacula to segment fault. Typically you will see this
-in the Storage daemon first. The solution is to compile Bacula ensuring
-that no optimization is turned on (normally it is -O2).
-
-\subsection*{Solaris}
-\index[general]{Solaris }
-\addcontentsline{toc}{subsection}{Solaris}
+\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
You will probably also need to: Add /usr/local/bin to PATH and Add
/usr/ccs/bin to PATH for ar.
+It is possible to build Bacula on Solaris with the Solaris compiler, but
+we recommend using GNU C++ if possible.
+
+A typical configuration command might look like:
+
\footnotesize
\begin{verbatim}
#!/bin/sh
\end{verbatim}
\normalsize
-\subsection*{FreeBSD}
-\index[general]{FreeBSD }
-\addcontentsline{toc}{subsection}{FreeBSD}
+If you have installed special software not normally in the Solaris
+libraries, such as OpenSSL, or the packages shown above, then you may need
+to add {\bf /usr/sfw/lib} to the library search path. Probably the
+simplest way to do so is to run:
+
+\footnotesize
+\begin{verbatim}
+setenv LDFLAGS "-L/usr/sfw/lib -R/usr/sfw/lib"
+\end{verbatim}
+\normalsize
+
+Prior to running the ./configure command.
+
+Alternatively, you can set the LD\_LIBARY\_PATH and/or the LD\_RUN\_PATH
+environment variables appropriately.
+
+It is also possible to use the {\bf crle} program to set the library
+search path. However, this should be used with caution.
+
+\section{FreeBSD}
+\index[general]{FreeBSD}
Please see:
\elink{The FreeBSD Diary}{http://www.freebsddiary.org/bacula.php} for a
with FreeBSD native threads rather than LinuxTreads. Mixing the two will
probably not work.
-\subsection*{Win32}
-\index[general]{Win32 }
-\addcontentsline{toc}{subsection}{Win32}
+\section{Win32}
+\index[general]{Win32}
To install the binary Win32 version of the File daemon please see the
-\ilink{Win32 Installation Chapter}{_ChapterStart7} in this document.
-
-\subsection*{Windows Systems with CYGWIN Installed}
-\label{Win32}
-\index[general]{Windows Systems with CYGWIN Installed }
-\index[general]{Installed!Windows Systems with CYGWIN }
-\addcontentsline{toc}{subsection}{Windows Systems with CYGWIN Installed}
-
-As of version 1.34, Bacula no longer uses CYGWIN for the Win32 File daemon.
-However, it is still built under a CYGWIN build environment -- though you
-can probably do it with VC Studio only. If you wish to build the Win32
-File daemon from the source, you will need Microsoft C++ version 7.1.
-Details for building the Win32 FD are in the README.win32 file of the
-src/win32 directory.
+\ilink{Win32 Installation Chapter}{Win32Chapter} in this document.
-Note, although most parts of Bacula build on Windows systems, the only part
-that we have tested and used is the File daemon.
+\section{One File Configure Script}
+\index[general]{Script!One File Configure}
+\index[general]{One Files Configure Script}
-Finally, you should follow the installation instructions in the
-\ilink{Win32 Installation}{_ChapterStart7} section of this document.
-
-\subsection*{Kern's Configure Script}
-\index[general]{Script!Kern's Configure }
-\index[general]{Kern's Configure Script }
-\addcontentsline{toc}{subsection}{Kern's Configure Script}
-
-The script that I use for building on my "production" Linux machines is:
+The following script could be used if you want to put everything
+in a single file:
\footnotesize
\begin{verbatim}
#!/bin/sh
-# This is Kern's configure script for Bacula
CFLAGS="-g -Wall" \
./configure \
--sbindir=$HOME/bacula/bin \
--sysconfdir=$HOME/bacula/bin \
+ --mandir=$HOME/bacula/bin \
--enable-smartalloc \
--enable-gnome \
+ --enable-bat \
+ --with-qwt=$HOME/bacula/depkgs/qwt \
+ --enable-bwx-console \
+ --enable-tray-monitor \
--with-pid-dir=$HOME/bacula/bin/working \
--with-subsys-dir=$HOME/bacula/bin/working \
- --with-mysql=$HOME/mysql \
+ --with-mysql \
--with-working-dir=$HOME/bacula/bin/working \
- --with-dump-email=$USER \
- --with-smtp-host=mail.your-site.com \
- --with-baseport=9101
+ --with-dump-email=$USER@your-site.com \
+ --with-job-email=$USER@your-site.com \
+ --with-smtp-host=mail.your-site.com
exit 0
\end{verbatim}
\normalsize
-Note that I define the base port as 9101, which means that Bacula will use
-port 9101 for the Director console, port 9102 for the File daemons, and port
-9103 for the Storage daemons. These ports should be available on all systems
-because they have been officially assigned to Bacula by IANA (Internet
-Assigned Numbers Authority). We strongly recommend that you use only these
-ports to prevent any conflicts with other programs. This is in fact the
-default if you do not specify a {\bf \verb:--:with-baseport} option.
-
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):
\end{verbatim}
\normalsize
-\subsection*{Installing Bacula}
-\index[general]{Bacula!Installing }
-\index[general]{Installing Bacula }
-\addcontentsline{toc}{subsection}{Installing Bacula}
+\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:
previously installed and run Bacula you will want to discard or ignore the
configuration files with the appended {\bf .new}.
-\subsection*{Building a File Daemon or Client}
-\index[general]{Client!Building a File Daemon or }
-\index[general]{Building a File Daemon or Client }
-\addcontentsline{toc}{subsection}{Building a File Daemon or Client}
+\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
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 O/S level are different, you will need to build a
+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
client will be built.
\label{autostart}
-\subsection*{Auto Starting the Daemons}
-\index[general]{Daemons!Auto Starting the }
-\index[general]{Auto Starting the Daemons }
-\addcontentsline{toc}{subsection}{Auto Starting the Daemons}
+\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
\normalsize
Please note, that the auto-start feature is implemented only on systems
-that we officially support (currently, FreeBSD, RedHat/Fedora Linux, and
+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 RedHat/Fedora Linux
+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.
\end{verbatim}
\normalsize
-\subsection*{Other Make Notes}
-\index[general]{Notes!Other Make }
-\index[general]{Other Make Notes }
-\addcontentsline{toc}{subsection}{Other Make Notes}
+\section{Other Make Notes}
+\index[general]{Notes!Other Make}
+\index[general]{Other Make Notes}
To simply build a new executable in any directory, enter:
\normalsize
To clean out all the objects and binaries (including the files named 1, 2, or
-3, which Kern uses as temporary files), enter:
+3, which are development temporary files), enter:
\footnotesize
\begin{verbatim}
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. gnome-console and
-gnome-console.conf are not installed if you do not configure GNOME. Also, if
-you are using SQLite instead of mysql, some of the files will be different).
+depends on your {\bf ./configure} command (e.g. bgnome-console and
+bgnome-console.conf are not installed if you do not configure GNOME. Also, if
+you are using SQLite instead of MySQL, some of the files will be different).
\footnotesize
\begin{verbatim}
drop_bacula_tables
drop_mysql_tables
fd
-gnome-console
-gnome-console.conf
+bgnome-console
+bgnome-console.conf
make_bacula_tables
make_catalog_backup
make_mysql_tables
bsmtp
startmysql
stopmysql
-wx-console
-wx-console.conf
+bwx-console
+bwx-console.conf
+9 man pages
\end{verbatim}
\normalsize
\label{monitor}
-\subsection*{Installing Tray Monitor}
-\index[general]{Monitor!Installing Tray }
-\index[general]{Installing Tray Monitor }
-\addcontentsline{toc}{subsection}{Installing Tray Monitor}
+\section{Installing Tray Monitor}
+\index[general]{Monitor!Installing Tray}
+\index[general]{Installing Tray Monitor}
The Tray Monitor is already installed if you used the {\bf
\verb:--:enable-tray-monitor} configure option and ran {\bf make install}.
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
+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.
-\subsubsection*{GNOME}
-\index[general]{GNOME }
-\addcontentsline{toc}{subsubsection}{GNOME}
+\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}.
-\subsubsection*{KDE}
-\index[general]{KDE }
-\addcontentsline{toc}{subsubsection}{KDE}
+\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}.
-\subsubsection*{Other window managers}
-\index[general]{Managers!Other window }
-\index[general]{Other window managers }
-\addcontentsline{toc}{subsubsection}{Other window managers}
+\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.
-\subsection*{Modifying the Bacula Configuration Files}
-\index[general]{Modifying the Bacula Configuration Files }
-\index[general]{Files!Modifying the Bacula Configuration }
-\addcontentsline{toc}{subsection}{Modifying the Bacula Configuration Files}
+\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}{_ChapterStart16} in this manual for
+\ilink{Configuring Bacula}{ConfigureChapter} in this manual for
instructions on how to set Bacula configuration files.
projects / bacula / docs / blobdiff