
#include "bacula_template.inc" title="Installing Bacula" num=4

<h1>Installing Bacula</h1>
<h2>General</h2>
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 
<b>SQLite</b>, <b>MySQL</b> to build properly depending on
the options you specify. To simplify your task, we have combined
a number of these packages into two <b>depkgs</b> 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.

<a name="upgrading"></a>
<h2>Upgrading Bacula</h2>
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. If there are several database
upgrades between your version and the version to which you
are upgradding, you will need to apply each database upgrade
script. For your convenience, you can find all the old
upgrade scripts in the <b>upgradedb</b> directory of the source
code. You will need to edit the scripts to correspond to
your system configuration. The final upgrade script, if any,
will be in the <b>src/cats</b> directory as described in the
ReleaseNotes.
<p>
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.

<h2><a name="Dependency">Dependency Packages</a></h2>
As discussed above, we have combined a number of third party
packages that Bacula might need into the <b>depkgs</b>
and <b>depkgs1</b> releases. 
You can, of course, get the latest packages from the 
original authors. 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.  
<p>
Typically, a dependency package will be named <b>depkgs-ddMMMyy.tar.gz</b>
and <b>depkgs1-ddMMyy.tar.gz</b>
where <b>dd</b> is the day we release it, <b>MMM</b> is the abbreviated
month (e.g. Jan), and <b>yy</b> is the year. 
An actual example is:
<b>depkgs-07Apr02.tar.gz</b>. To install and build
this package (if needed), you do the following:
<ol>
  <li>Create a <b>bacula</b> directory, into which you will place
      both the Bacula source as well as the dependency package.</li>
  <li>Detar the <b>depkg</b> into the <b>bacula</b> directory.</li>
  <li>cd bacula/depkgs</li>
  <li>make</li>
</ol>
Although the exact composition of the dependency packages may
change from time to time, the current makeup is the following:
<p>
<table cellspacing="4" cellpadding="4" border="5">
<tr> <th>3rd Party Package</th> <th>depkgs</th> <th>depkgs1</th> <th>depkgs-win32</th></tr>
<tr> <td>SQLite</td> <td align="center">X</td> <td align="center">-</td> <td align="center">-</td>
<tr> <td>mtx</td> <td align="center">X</td> <td align="center">-</td> <td align="center">-</td>
<tr> <td>readline</td> <td align="center">-</td> <td align="center">X</td> <td align="center">-</td>
<tr> <td>pthreads</td> <td align="center">-</td> <td align="center">-</td> <td align="center">X</td> 
<tr> <td>zlib</td> <td align="center">-</td> <td align="center">-</td> <td align="center">X</td> 
<tr> <td>wxWidgits</td> <td align="center">-</td> <td align="center">-</td> <td align="center">X</td> 
</table>
<p>

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.
<p>
Alternatively, you can make just the packages that are needed.
For example,
<pre>
cd bacula/depkgs
make sqlite
</pre>
will configure and build only the SQLite package.
<p>
You should build the packages that you will require in <b>depkgs</b> 
and/or <b>depkgs1</b> prior to configuring and building Bacula,
since Bacula will need them during the build process.
<p>
Even if you do not use SQLite, you might find it worthwhile to 
build <b>mtx</b> because the <b>tapeinfo</b> program that comes
with it can often provide you with valuable information about
your SCSI tape drive (e.g. compression, min/max block sizes, ...).
<p>The <b>depkgs-win32</b> package contains the source code for
the pthreads and zlib libraries used by the native Win32 client
program. It will only be needed if you intend to build the Win32
client from source.

<h2><a name="Systems">Supported Operating Systems</a></h2>
Please see the <a href="supported.html#SupportedOSes">
Supported Operating Systems</a> section of the QuickStart 
chapter of this manual.

<h2><a name="Building">Building Bacula from Source</a></h2>
<p>The basic installation is rather simple. 
</p>
<ol>
  <li>Install and build any <b>depkgs</b> as noted above.</li>
  <li>Configure and install MySQL or PostgreSQL (if desired).  <a
      href="mysql.html">Installing and Configuring MySQL Phase I</a> or
      <a href="postgresql.html">Installing and Configuring PostgreSQL Phase I</a>.
      If you are installing from rpms, and are using MySQL, please be sure to install
      <b>mysql-devel</b>, so that the MySQL header files are available
      while compiling Bacula.  In addition, the MySQL client
      library <b>mysqlclient</b> requires the gzip compression library
      <b>libz.a</b> or <b>libz.so</b>.  If you are using rpm packages,
      these libraries are in the <b>libz-devel</b> package.  On Debian
      systems, you will need to load the <b>zlib1g-dev</b> package.  If
      you are not using rpms or debs, you will need to find the
      appropriate package for your system.
      <br>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.</li>
  <li>As an alternative to MySQL and PostgreSQL, configure and install SQLite,
      which is part of the <b>depkgs</b>.
      <a href="sqlite.html">Installing and Configuring SQLite</a>.</li>
  <li>Detar the Bacula source code preferably into the <b>bacula</b>
      directory discussed above.</li>
  <li><B>cd</B> to the directory containing the source code.</li>
  <li>./configure (with appropriate options as described below)</li>
  <li>Check the output of ./configure very carefully, especially
      the Install binaries and Install config files directories.
      If they are not correct, please rerun ./configure until they
      are. The output from ./configure is stored in <b>config.out</b>
      and can be re-displayed at any time without rerunning the 
      ./configure by doing <b>cat config.out</b>.</li>
  <li>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:
      <pre>
      make distclean
      </pre>
      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 <b>make distclean</b>
      is also critical if you move the source file from one
      machine to another. If the <b>make distclean</b> fails,   
      just ignore it and continue on.</li>
  <li>make
      <p>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 <b>--enable-static-tools</b> to the
       <b>./configure</b> command.  </li>
  <li>make install</li>
  <li>If you are new to Bacula, we <b>strongly</b> 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.</li>
  <li>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 <a
      href="configure.html">Setting Up Bacula Configuration
      Files</a> 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 <b>Name</b>s as the
      passwords and names must agree between the configuration files
      for security reasons. </li>
  <li>Create the Bacula MySQL database and tables (if using MySQL)
      <a href="mysql.html#mysql_phase2">Installing and 
      Configuring MySQL Phase II</a> or
      create the Bacula PostgreSQL database and tables 
      <a href="postgresql.html#postgreql_phase2">Installing and
      Configuring PostgreSQL Phase II</a> or alternatively
      if you are using SQLite 
      <a href="sqlite.html#phase2">Installing and Configuring
      SQLite Phase II</a>.
  <li>Start Bacula (<b>./bacula start</b>) Note. the next chapter
      shows you how to do this in detail.</li>
  <li>Interface with Bacula using the Console program</li>
  <li>For the previous two items, please follow the instructions
      in the <a href="running.html">Running Bacula</a> 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.</li>
  <li>If after installing Bacula, you decide to "move it", that is
      to install it in a different set of directories, proceed
      as follows:
      <pre>
      make uninstall
      make distclean
      ./configure (your-new-options)
      make
      make install
      </pre>
      </li>
</ol>

<p>If all goes well, the <B>./configure</B> 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.
<p>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 &quot;make install&quot;.  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:
<pre>
make distclean
</pre>
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 &quot;make distclean&quot;.
<p>In general, you will probably want to supply a more complicated
<b>configure</b> statement to ensure that the modules you want are
built and that everything is placed into the correct directories. 
<p> For example, on RedHat, one could use the following:
<pre>
CFLAGS="-g -Wall" \\
  ./configure \\
    --sbindir=$HOME/bacula/bin \\
    --sysconfdir=$HOME/bacula/bin \\
    --with-pid-dir=$HOME/bacula/bin/working \\
    --with-subsys-dir=$HOME/bacula/bin/working \\
    --with-mysql=$HOME/mysql \\
    --with-working-dir=$HOME/bacula/bin/working \\
    --with-dump-email=$USER
</pre>
Note, 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.
<p>For the developer's convenience, I have added a <b>defaultconfig</b>
script to the <b>examples</b> 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.
<p>
The <b>--enable-conio</b> or <b>--enable-readline</b> 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 <b>termcap</b> or the <b>ncurses</b> 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:
<pre>
/usr/lib/gcc-lib/i586-suse-linux/3.3.1/.../ld: 
cannot find -ltermcap
collect2: ld returned 1 exit status
</pre>
while building the Bacula Console. In that case,
you will need
to set the <b>LDFLAGS</b> environment variable prior to building.
<pre>
export LDFLAGS="-L/usr/lib/termcap"
</pre>
The same library requirements apply if you wish to use
the readline subroutines for command line editing and
history. 
<p>
Please be aware that on some
systems such as Mandrake, 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 <b>--enable-conio</b> to use a built-in
readline replacement.  You will still need the either termcap or ncurses
library, but it is unlikely that the <b>conio</b> package will gobble up
prompts.
<p>
readline is no longer supported after version 1.34.     
The code is still available and if users submit patches for it, I 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
support it. 
      

<h2><a name="DB">What Database to Use?</a></h2>
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, we recommend that
you start by using SQLite.  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).
<p>If you wish to use MySQL as the Bacula catalog, please see the 
<a href="mysql.html">Installing and Configuring MySQL</a> chapter of this
manual. You will need to install MySQL prior to continuing with
the configuration of Bacula. MySQL is a high quality database that
is very efficient and is suitable for any sized installation. It is
slightly more complicated than SQLite to setup and administer because
it has a number of sophisticated features such as userids and 
passwords. It runs as a separate process, is truly professional
and can manage a database of any size.

<p>If you wish to use PostgreSQL as the Bacula catalog, please see the 
<a href="postgresql.html">Installing and Configuring PostgreSQL</a> 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.  There
are some important performance problems with PostgreSQL in Bacula
versions prior to 1.35.5.

<p></p>If you wish to use SQLite as the Bacula catalog, please
see <a href="sqlite.html">Installing and Configuring SQLite</a> chapter
of this manual. 

<h2>Quick Start</h2>
There are a good 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. 
<p>
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.


<h2><a name="Options">Configure Options</a></h2>
<p>The following command line options are available for <b>configure</b> to customize your
installation. 
</p>
<DL>
   <dt>--sysbindir=&lt;binary-path&gt;</dt><dd>Defines where the Bacula
       binary (executable) files will be placed during a <b>make 
       install</b> command.</dd>
   <dt>--sysconfdir=&lt;config-path&gt;</dt><dd>Defines where the
       Bacula configuration files should be placed during a <b>make
       install</b> command.</dd>
   <DT>--enable-smartalloc </DT><DD> 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</dd>
   <dt>--enable-gnome </dt><dd>If you have GNOME installed on your
       computer and you want to use the GNOME GUI Console interface
       to Bacula, you must specify this option. Doing so
       will build everything in the <b>src/gnome-console</b> directory.</dd>
   <dt>--enable-wx-console </dt><dd>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 <b>src/wx-console</b> 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
       libraries.</dd>
   <dt>--enable-tray-monitor </dt><dd>If you have GTK installed on your
       computer, you run an 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 
       <b>src/tray-monitor</b> directory.</dd>
   <dt>--enable-static-tools</dt><dd>This option causes the linker
       to link the Storage daemon utility tools (<b>bls</b>, 
       <b>bextract</b>, and <b>bscan</b>) statically. This permits using
       them without having the shared libraries loaded.  If you have
       problems linking in the <b>src/stored</b> directory, make sure
       you have not enabled this option, or explicitly
       disable static linking by adding <b>--disable-static-tools</b>.</dd>
   <dt>--enable-static-fd</dt><dd>This option causes the make process
       to build a <b>static-bacula-fd</b> 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 <b>make static-bacula-fd</b> from with
       in the <b>src/filed</b> directory. Also, the <b>--enable-client-only</b>
       option described below is useful for just building a client so that
       all the other parts of the program are not compiled.</dd>
   <dt>--enable-static-sd</dt><dd>This option causes the make process
       to build a <b>static-bacula-sd</b> in addition to the standard
       Storage daemon. This static version will include statically linked
       libraries and could be useful during a Bare Metal recovery.</dd>
   <dt>--enable-static-dir</dt><dd>This option causes the make process
       to build a <b>static-bacula-dir</b> in addition to the standard
       Director. This static version will include statically linked
       libraries and could be useful during a Bare Metal recovery.</dd>
   <dt>--enable-static-cons</dt><dd>This option causes the make process
       to build a <b>static-console</b> and a <b>static-gnome-console</b>
       in addition to the standard console.
       This static version will include statically linked
       libraries and could be useful during a Bare Metal recovery.</dd>
   <dt>--enable-client-only</dt><dd>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 <b>make install</b> 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.</dd>
   <dt>--enable-largefile</dt><dd>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 
       <b>--disable-largefile</b>.</dd>
   <dt>--with-sqlite=&lt;sqlite-path&gt;</dt><dd> This enables use of
       the SQLite database.  The <b>sqlite-path</b> is not normally
       specified as Bacula looks for the necessary components in
       a standard location (<b>depkgs/sqlite</b>).  See <a
       href="sqlite.html">Installing and Configuring SQLite</a> chapter of
       this manual for more details.</dt>
   <dt>--with-mysql=&lt;mysql-path&gt;</DT><DD STYLE="margin-bottom: 0.2in">
       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 <b>mysql-path</b> that you
       specify.  If this option is not present, the build will
       automatically include the internal Bacula database
       code. We recommend that you use this option if possible.
       If you do use this option, please proceed to installing
       MySQL in the <a href="mysql.html">Installing and Configuring
       MySQL</a> chapter before proceeding with the configuration.
    <dt>--with-postgresql=&lt;path&gt;</dt><dd>This provides an explicit
        path to the PostgreSQL libraries if Bacula cannot find it by
        default.</dd>
    <dt>--enable-conio</dt><dd>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.</dd>
    <dt>--with-readline=&lt;readline-path&gt;</dt><dd>Tells Bacula
        where <b>readline</b> 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 supports, so you are on your own
        if you have problems. </dd>
    <dt>--enable-readline</dt><dd>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.</dd>
    <dt>--with-tcp-wrappers=&lt;path&gt;</dt><dd>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 <b>/etc/hosts.allow</b>
        or <b>/etc/hosts.deny</b> files, do not use the <b>twist</b>
        option (hosts_options(5)) or the Bacula process will be terminated.
        <p>For more information on configuring and testing TCP wrappers, please 
        see the <a href="security.html#wrappers">Configuring and Testing TCP Wrappers</a> 
        section in the Security Capter.</dd>

    <dt>--with-working-dir=&lt;working-directory-path&gt;</dt>
        <dd>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. </dd>
    <dt>--with-base-port=&lt;port=number&gt;</dt><dd> 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 <b>--with-baseport</b> 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. </dd>
    <dt>--with-dump-email=&lt;email-address&gt;</dt><dd>This option specifies
        the email address where any core dumps should be set. This option
        is normally only used by developers.</dd>
    <dt>--with-pid-dir=&lt;PATH&gt;</dt>
        <dd>This specifies where Bacula should place the process id
            file during execution. The default is: <b>/var/run</b>.
            This directory is not created by the install process, so
            you must ensure that it exists before using Bacula the
            first time.</dd>
    <dt>--with-subsys-dir=&lt;PATH&gt;</dt>
        <dd>This specifies where Bacula should place the subsystem lock
            file during execution. The default is <b>/var/run/subsys</b>.
            Please make sure that you do not specify the same directory
            for this directory and for the <b>sbindir</b> 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. </dd>
    <dt>--with-dir-password=&lt;Password&gt;</dt>
        <dd>This option allows you to specify the password used to 
            access the Directory (normally from the Console program).
            If it is not specified, configure will automatically create a random
            password.</dd>
    <dt>--with-fd-password=&lt;Password&gt;</dt>
        <dd>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.</dd>
    <dt>--with-sd-password=&lt;Password&gt;</dt>
        <dd>This option allows you to specify the password used to 
            access the Directory (normally called from the Director).
            If it is not specified, configure will automatically create a random
            password.</dd>
    <dt>--with-dir-user=&lt;User&gt;</dt>
        <dd>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 &quot;drop&quot;
            to the UserId specified on this option. </dd>
    <dt>--with-dir-group=&lt;Group&gt;</dt>
        <dd>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 &quot;drop&quot;
            to the GroupId specified on this option. </dd>
    <dt>--with-sd-user=&lt;User&gt;</dt>
        <dd>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 &quot;drop&quot;
            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. </dd>
    <dt>--with-sd-group=&lt;Group&gt;</dt>
        <dd>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 &quot;drop&quot;
            to the GroupId specified on this option. </dd>
    <dt>--with-fd-user=&lt;User&gt;</dt>
        <dd>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 &quot;drop&quot;
            to the UserId specified on this option. </dd>
    <dt>--with-fd-group=&lt;Group&gt;</dt>
        <dd>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 &quot;drop&quot;
            to the GroupId specified on this option. </dd>
</dl>


Note, many other options are presented when you do a <b>./configure
--help</b>, but they are not implemented.

<H2>Recommended Options for most Systems</H2>
<p>For most systems, we recommend starting with the following options: 
</p>
<pre>
./configure \\
  --enable-smartalloc \\
  --sbindir=$HOME/bacula/bin \\
  --sysconfdir=$HOME/bacula/bin \\
  --with-pid-dir=$HOME/bacula/bin/working \\
  --with-subsys-dir=$HOME/bacula/bin/working \\
  --with-mysql=$HOME/mysql \\
  --with-working-dir=$HOME/bacula/working
</pre>
<p>
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 --sbindir and --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.
See below for an
example of how Kern does it. 
<h2>RedHat</h2> 
Using SQLite:
<pre> 
CFLAGS=&quot;-g -Wall&quot; ./configure \\
  --sbindir=$HOME/bacula/bin \\
  --sysconfdir=$HOME/bacula/bin \\
  --enable-smartalloc \\
  --with-sqlite=$HOME/bacula/depkgs/sqlite \\
  --with-working-dir=$HOME/bacula/working \\
  --with-pid-dir=$HOME/bacula/bin/working \\
  --with-subsys-dir=$HOME/bacula/bin/working \\
  --enable-gnome \\
  --enable-conio
</pre>

or
<pre> 
CFLAGS=&quot;-g -Wall&quot; ./configure \\
  --sbindir=$HOME/bacula/bin \\
  --sysconfdir=$HOME/bacula/bin \\
  --enable-smartalloc \\
  --with-mysql=$HOME/mysql \\
  --with-working-dir=$HOME/bacula/working
  --with-pid-dir=$HOME/bacula/bin/working \\
  --with-subsys-dir=$HOME/bacula/bin/working
  --enable-gnome \\
  --enable-conio
</pre>

or finally, a completely traditional RedHat Linux install:
<pre>
CFLAGS=&quot;-g -Wall&quot; ./configure \\
  --prefix=/usr \\
  --sbindir=/usr/sbin \\
  --sysconfdir=/etc/bacula \\
  --with-scriptdir=/etc/bacula \\
  --enable-smartalloc \\
  --enable-gnome \\
  --with-mysql \\
  --with-working-dir=/var/bacula \\
  --with-pid-dir=/var/run \\
  --with-subsys-dir=/var/lock/subsys \\
  --enable-conio
</pre>
Note, Bacula assumes that /var/bacula, /var/run, and /var/loc/subsys
exist so it will not automatically create them during the install
process.


<h2>Solaris</h2>
<pre>
\#!/bin/sh
CFLAGS=&quot;-g&quot; ./configure \\
  --sbindir=$HOME/bacula/bin \\
  --sysconfdir=$HOME/bacula/bin \\
  --with-mysql=$HOME/mysql \\
  --enable-smartalloc \\
  --with-pid-dir=$HOME/bacula/bin/working \\
  --with-subsys-dir=$HOME/bacula/bin/working \\
  --with-working-dir=$HOME/bacula/working
</pre>
As mentioned above,
the install process
will create the sbindir and sysconfdir if they do not exist, but it
will not automatically create the pid-dir, subsys-dir, or working-dir,
so you must ensure that they exist before running Bacula for the first

<h2>FreeBSD</h2>
Please see:
<a href="http://www.freebsddiary.org/bacula.php">The FreeBSD
Diary</a> 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 <a href="tapetesting.html#FreeBSDTapes">Tape Testing
Chapter</a> of this manual for <b>important</b> information on
how to configure your tape drive for compatibility with Bacula.
<p>
If you are using Bacula with MySQL, you should take care to compile
MySQL with FreeBSD native threads rather than LinuxThreads, since Bacula
is normal built with FreeBSD native threads rather than LinuxTreads. Mixing
the two will probably not work.

<h2>Win32</h2>
To install the binary Win32 version of the File daemon please see the
<a href="win32.html">Win32 Installation Chapter</a> in this
document.                                  

<h2><a name="Win32"></a>Windows Systems with CYGWIN Installed</h2>
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 6.0 or greater. In Bacula prior to version
1.33, CYGWIN was used. Details for building it are in the
README file of the src/win32 directory.
<p>   
Note, although most parts of Bacula build on Windows
systems, the only part that we have tested and used is the
File daemon. 
<p>
Finally, you should follow the installation instructions in
the <a href="win32.html">Win32 Installation</a> section of
this document, skipping the part that describes unZipping
the binary release.


<h2>Kern's Configure Script</h2>
The script that I use for building on my &quot;production&quot;
Linux machines is:
<pre>
\#!/bin/sh
\# This is Kern's configure script for Bacula
CFLAGS="-g -Wall" \\
  ./configure \\
    --sbindir=$HOME/bacula/bin \\
    --sysconfdir=$HOME/bacula/bin \\
    --enable-smartalloc \\
    --enable-gnome \\
    --with-pid-dir=$HOME/bacula/bin/working \\
    --with-subsys-dir=$HOME/bacula/bin/working \\
    --with-mysql=$HOME/mysql \\
    --with-working-dir=$HOME/bacula/bin/working \\
    --with-dump-email=$USER \\
    --with-smtp-host=mail.your-site.com \\
    --with-baseport=9101
exit 0
</pre>


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 <b>--with-baseport</b> option.
<p>
You may also want to put the following entries in your
<b>/etc/services</b> file as it will make viewing the
connections made by Bacula easier to recognize
(i.e. netstat -a):
<pre>
bacula-dir      9101/tcp
bacula-fd       9102/tcp
bacula-sd       9103/tcp
</pre>

<h2>Installing Bacula</h2>
Before setting up your configuration files, you will want to install
Bacula in its final location. Simply enter:
<pre>
make install
</pre>
If you have previously installed Bacula, the old binaries
will be overwritten, but the old configuration files will remain
unchanged, and the &quot;new&quot; configuration files will be
appended with a <b>.new</b>. Generally if you have previously
installed and run Bacula you will want to discard or 
ignore the configuration files with the appended <b>.new</b>.

<h2>Building a File Daemon or Client</h2>
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 <b>bacula-fd</b> as well as its configuration
file <b>bacula-fd.conf</b> 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 (<b>bacula-dir.conf</b>).
<p>If the architecture or the O/S level are different,
you will need to build a File daemon on the Client 
machine. To do so,
you can use the same <b>./configure</b> command as
you did for your main program, starting either from
a fresh copy of the source tree, or using   
<b>make&nbsp;distclean</b> before the <b>./configure</b>.
<p>
Since the File 
daemon does not access the Catalog database, you can
remove the <b>--with-mysql</b> or <b>--with-sqlite</b>
options, then add <b>--enable-client-only</b>. 
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
<b>make</b> and just the client will be built.

<a name="autostart"></a>
<h2>Auto Starting the Daemons</h2>
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 <b>unknown</b>, then
you must install the platform dependent files by doing:
<pre>
(become root)
make install-autostart
</pre>
Please note, that the auto-start feature is implemented
only on systems that we officially support (currently,
FreeBSD, RedHat Linux, and Solaris), and has only been
fully tested on RedHat Linux.
<p>The <b>make install-autostart</b> will cause the appropriate startup
scripts to be installed with the necessary symbolic links.
On RedHat Linux systems,
these scripts reside in <b>/etc/rc.d/init.d/bacula-dir</b>
<b>/etc/rc.d/init.d/bacula-fd</b>, and
<b>/etc/rc.d/init.d/bacula-sd</b>. However the exact location
depends on what operating system you are using.
<p>
If you only wish to install the File daemon, you may do
so with:
<pre>
make install-autostart-fd
</pre>



<h2>Other Make Notes</h2>
To simply build a new executable in any directory, enter:
<pre>make</pre>
To clean out all the objects and binaries (including the
files named 1, 2, or 3, which Kern uses as temporary files), enter:
<pre>make clean</pre>
To really clean out everything for distribution, enter:
<pre>make distclean</pre>
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 <b>./configure</b> in the top level directory,
since all the Makefiles will be deleted.
<p>To add a new file in a subdirectory, edit the Makefile.in
in that directory, then simply do a <b>make</b>. In most
cases, the make will rebuild the Makefile from the new Makefile.in.
In some case, you may need to issue the <b>make</b> a second time.
In extreme cases, cd to the top level directory and enter:
<b>make Makefiles</b>.
<p>To add dependencies:
<pre>make depend</pre>
The <b>make depend</b> 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.
<b>make depend</b> is normally automatically invoked during the
configuration process.
<p>To install:</p>
<pre>make install</pre>
This not normally done if you are developing Bacula, but
is used if you are going to run it to backup your system.

<p>
After doing a <b>make install</b> the following files will
be installed on your system (more or less). The exact files
and location (directory) for each file depends on your <b>./configure</b>
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).
<pre>
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
fd
gnome-console
gnome-console.conf
make_bacula_tables
make_catalog_backup
make_mysql_tables
mtx-changer
query.sql
bsmtp
startmysql
stopmysql
wx-console
wx-console.conf
</pre>

<a name="monitor"></a>
<h2>Installing Tray Monitor</h2>
The Tray Monitor is already installed if you used the <b>--enable-tray-monitor</b>
configure option and ran <b>make install</b>.<p>
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 <b>tray-monitor.conf</b>,
and to execute <b>bacula-tray-monitor</b> (this is not a security issue).<p>
Then log into your graphical environment (KDE, Gnome or something else), run
<b>bacula-tray-monitor</b> as your user, and see if a cassette icon appear somewhere
on the screen, usually on the task bar.<br>If it doesn't, follow the instructions below
related to your environment or window manager.

<h3>GNOME</h3>
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 <b>Add to this Panel</b>, then <b>Utility</b> and finally click on 
<b>Notification Area</b>.

<h3>KDE</h3>
System tray has been supported in KDE since version 3.1.
To activate it, right-click on one of your panels, open the menu <b>Add</b>,
then <b>Applet</b> and finally click on <b>System Tray</b>.

<h3>Other window managers</h3>
Read the documentation to know if the Freedesktop system tray standard is supported by
your window manager, and if applicable, how to activate it.

<h1>Modifying the Bacula Configuration Files</h1>
See the chapter <a href="configure.html">Configuring Bacula</a> 
in this manual for instructions on how to set Bacula configuration
files.

<page_prev name="Getting Started" url="quickstart.html">
<page_next name="Running Bacula" url="running.html">
