4 \chapter{Installing Bacula}
6 \index[general]{Bacula!Installing}
7 \index[general]{Installing Bacula}
9 In general, you will need the Bacula source release, and if you want to run
10 a Windows client, you will need the Bacula Windows binary release.
11 However, Bacula needs certain third party packages (such as {\bf MySQL},
12 {\bf PostgreSQL}, or {\bf SQLite} to build properly depending on the
13 options you specify. Normally, {\bf MySQL} and {\bf PostgreSQL} are
14 packages that can be installed on your distribution. However, if you do
15 not have them, to simplify your task, we have combined a number of these
16 packages into two {\bf depkgs} releases (Dependency Packages). This can
17 vastly simplify your life by providing you with all the necessary packages
18 rather than requiring you to find them on the Web, load them, and install
21 \section{Source Release Files}
22 \index[general]{Source Files}
23 \index[general]{Release Files}
24 Beginning with Bacula 1.38.0, the source code has been broken into
25 four separate tar files each corresponding to a different module in
26 the Bacula SVN. The released files are:
29 \item [bacula-2.0.3.tar.gz]
30 This is the primary source code release for Bacula. On each
31 release the version number (2.0.3) will be updated.
33 \item [bacula-docs-2.0.3.tar.gz]
34 This file contains a copy of the docs directory with the
35 documents prebuild. English HTML directory, single HTML
36 file, and pdf file. The French and German translations
37 are in progress, but are not built.
39 \item [bacula-gui-2.0.3.tar.gz]
40 This file contains the non-core GUI programs. Currently,
41 it contains bacula-web, a PHP program for producing management
42 viewing of your Bacula job status in a browser; and bimagemgr
43 a browser program for burning CDROM images with Bacula Volumes.
45 \item [bacula-rescue-2.0.0.tar.gz]
46 This is the Bacula Rescue CDROM code. Note, the version number
47 of this package is not tied to the Bacula release version, so
48 it will be different. Using this code, you can burn a CDROM
49 with your system configuration and containing a statically
50 linked version of the File daemon. This can permit you to easily
51 repartition and reformat your hard disks and reload your
52 system with Bacula in the case of a hard disk failure.
54 Note, this package evolves slower than the Bacula source code,
55 so there may not always be a new release of the rescue package when
56 making minor updates to the Bacula code. For example, when releasing
57 Bacula version 2.0.3, the rescue package may still be at version
58 2.0.0 if there were no updates.
60 \item [winbacula-2.0.3.exe]
61 This file is the 32 bit Windows installer for installing
62 the Windows client (File daemon) on a Windows machine.
63 This client will also run on 64 bit Windows machines.
64 Beginning with Bacula version 1.39.20, this executable will
65 also optionally load the Win32 Director and the Win32
71 \section{Upgrading Bacula}
72 \index[general]{Bacula!Upgrading}
73 \index[general]{Upgrading Bacula}
74 \index[general]{Upgrading}
76 If you are upgrading from one Bacula version to another, you should first
77 carefully read the ReleaseNotes of all major versions between your current
78 version and the version to which you are upgrading. If the Bacula catalog
79 database has been upgraded (as it is almost every major release), you will
80 either need to reinitialize your database starting from scratch (not
81 normally a good idea), or save an ASCII copy of your database, then proceed
82 to upgrade it. If you are upgrading two major versions (e.g. 1.36 to 2.0)
83 then life will be more complicated because you must do two database
84 upgrades. See below for more on this.
86 Upgrading the catalog is normally done after Bacula is build and installed
90 cd <installed-scripts-dir> (default /etc/bacula)
91 ./update_bacula_tables
94 This update script can also be find in the Bacula source src/cats
97 If there are several database upgrades between your version and the
98 version to which you are upgrading, you will need to apply each database
99 upgrade script. For your convenience, you can find all the old upgrade scripts
100 in the {\bf upgradedb} directory of the source code. You will need to edit the
101 scripts to correspond to your system configuration. The final upgrade script,
102 if any, can be applied as noted above.
104 If you are upgrading from one major version to another, you will need to
105 replace all your components at the same time as generally the inter-daemon
106 protocol will change. However, within any particular release (e.g. version
107 1.32.x) unless there is an oversight or bug, the daemon protocol will not
108 change. If this is confusing, simply read the ReleaseNotes very carefully as
109 they will note if all daemons must be upgraded at the same time.
111 Finally, please note that in general it is not necessary to do a
112 {\bf make uninstall} before doing an upgrade providing you are careful
113 not to change the installation directories. In fact, if you do so, you will
114 most likely delete all your conf files, which could be disastrous.
115 The normal procedure during an upgrade is simply:
118 ./configure (your options)
123 In general none of your existing .conf or .sql files will be overwritten,
124 and you must do both the {\bf make} and {\bf make install} commands, a
125 {\bf make install} without the preceding {\bf make} will not work.
127 For additional information on upgrading, please see the \ilink{Upgrading Bacula
128 Versions}{upgrading} in the Tips chapter of this manual.
130 \section{Releases Numbering}
131 \index[general]{Release Numbering}
132 \index[general]{Version Numbering}
133 Every Bacula release whether beta or production has a different number
134 as well as the date of the release build. The numbering system follows
135 traditional Open Source conventions in that it is of the form.
146 where each component (major, minor, patch) is a number.
147 The major number is currently 1 and normally does not change
148 very frequently. The minor number starts at 0 and increases
149 each for each production release by 2 (i.e. it is always an
150 even number for a production release), and the patch number is
151 starts at zero each time the minor number changes. The patch
152 number is increased each time a bug fix (or fixes) is released
155 So, as of this date (10 September 2006), the current production Bacula
156 release is version 1.38.11. If there are bug fixes, the next release
157 will be 1.38.12 (i.e. the patch number has increased by one).
159 For all patch releases where the minor version number does not change,
160 the database and all the daemons will be compatible. That means that
161 you can safely run a 1.38.0 Director with a 1.38.11 Client. Of course,
162 in this case, the Director may have bugs that are not fixed. Generally,
163 within a minor release (some minor releases are not so minor), all
164 patch numbers are officially released to production. This means that while
165 the current Bacula version is 1.38.11, versions 1.38.0, 1.38.1, ... 1.38.10
166 have all been previously released.
168 When the minor number is odd, it indicates that the package is under
169 development and thus may not be stable. For example, while the current
170 production release of Bacula is currently 1.38.11, the current development
171 version is 1.39.22. All patch versions of the development code are
172 available in the CVS (source repository). However, not all patch versions
173 of the development code (odd minor version) are officially released. When
174 they are released, they are released as beta versions (see below for a
175 definition of what beta means for Bacula releases).
177 In general when the minor number increases from one production release
178 to the next (i.e. 1.38.x to 1.40.0), the catalog database must be upgraded,
179 the Director and Storage daemon must always be on the same minor release
180 number, and often (not always), the Clients must also be on the same minor
181 release. As often as possible, we attempt to make new releases that are
182 downwards compatible with prior clients, but this is not always possible.
183 You must check the release notes. In general, you will have fewer problems
184 if you always run all the components on the same minor version number (i.e.
185 all either 1.38.x or 1.40.x but not mixed).
189 \section*{Beta Releases}
190 \index[general]{Beta Releases}
191 Towards the end of the development cycle, which typically runs
192 one year from a major release to another, there will be several beta
193 releases of the development code prior to a production release.
194 As noted above, beta versions always have odd minor version numbers
195 (e.g 1.37.x or 1.39.x).
196 The purpose of the beta releases is to allow early adopter users to test
197 the new code. Beta releases are made with the following considerations:
200 \item The code passes the regression testing on Linux and
201 FreeBSD machines. Including tape drive testing
202 on Linux and FreeBSD.
204 \item There are no known major bugs, or on the rare occasion that
205 there are, they will be documented or already in the bugs database.
207 \item Some of the new code/features may not yet be tested.
209 \item Bugs are expected to be found, especially in the new
210 code before the final production release.
212 \item The code will have been run in production in at least one small
215 \item The Win32 client will have been run in production at least
216 one night at that small site.
218 \item The documentation in the manual is unlikely to be complete especially
219 for the new features, and the Release Notes may not be fully
222 \item Beta code is not generally recommended for everyone, but
223 rather for early adopters.
228 \section{Dependency Packages}
229 \index[general]{Dependency Packages}
230 \index[general]{Packages!Dependency}
232 As discussed above, we have combined a number of third party packages that
233 Bacula might need into the {\bf depkgs} release. You can,
234 of course, get the latest packages from the original authors or
235 from your operating system supplier. The locations of
236 where we obtained the packages are in the README file in each package.
237 However, be aware that the packages in the depkgs files have been tested by us
238 for compatibility with Bacula.
240 Typically, a dependency package will be named {\bf depkgs-ddMMMyy.tar.gz}
241 where {\bf dd} is the day we release it, {\bf MMM}
242 is the abbreviated month (e.g. Jan), and {\bf yy} is the year. An actual
243 example is: {\bf depkgs-07Apr02.tar.gz}. To install and build this package (if
244 needed), you do the following:
247 \item Create a {\bf bacula} directory, into which you will place both the
248 Bacula source as well as the dependency package.
249 \item Detar the {\bf depkg} into the {\bf bacula} directory.
250 \item cd bacula/depkgs
254 Although the exact composition of the dependency packages may change from time
255 to time, the current makeup is the following:
257 \addcontentsline{lot}{table}{Dependency Packages}
258 \begin{longtable}{|l|l|}
260 \multicolumn{1}{|c| }{\bf 3rd Party Package} & \multicolumn{1}{c| }{\bf depkgs} \\
261 \hline {SQLite } & \multicolumn{1}{c| }{X } \\
262 \hline {SQLite3 } & \multicolumn{1}{c| }{X } \\
263 \hline {mtx } & \multicolumn{1}{c| }{X } \\
267 Note, some of these packages are quite large, so that building them can be a
268 bit time consuming. The above instructions will build all the packages
269 contained in the directory. However, when building Bacula, it will take only
270 those pieces that it actually needs.
272 Alternatively, you can make just the packages that are needed. For example,
281 will configure and build only the SQLite package.
283 You should build the packages that you will require in {\bf depkgs} a
284 prior to configuring and building Bacula, since Bacula will need
285 them during the build process.
287 Even if you do not use SQLite, you might find it worthwhile to build {\bf mtx}
288 because the {\bf tapeinfo} program that comes with it can often provide you
289 with valuable information about your SCSI tape drive (e.g. compression,
290 min/max block sizes, ...). Note, most distros provide {\bf mtx} as part of
293 The {\bf depkgs1} package is depreciated and previously contained
294 readline, which should be available on all operating systems.
296 The {\bf depkgs-win32} package is deprecated and no longer used in
297 Bacula version 1.39.x and later. It was previously used to build
298 the native Win32 client program, but this program is now built on Linux
299 systems using cross-compiling. All the tools and third party libraries
300 are automatically downloaded by executing the appropriate scripts. See
301 src/win32/README.mingw32 for more details.
303 \section{Supported Operating Systems}
305 \index[general]{Systems!Supported Operating}
306 \index[general]{Supported Operating Systems}
309 \ilink{ Supported Operating Systems}{SupportedOSes} section
310 of the QuickStart chapter of this manual.
312 \section{Building Bacula from Source}
314 \index[general]{Source!Building Bacula from}
315 \index[general]{Building Bacula from Source}
317 The basic installation is rather simple.
320 \item Install and build any {\bf depkgs} as noted above. This
321 should be unnecessary on most modern Operating Systems.
323 \item Configure and install MySQL or PostgreSQL (if desired).
324 \ilink{Installing and Configuring MySQL Phase I}{MySqlChapter} or
325 \ilink{Installing and Configuring PostgreSQL Phase
326 I}{PostgreSqlChapter}. If you are installing from rpms, and are
327 using MySQL, please be sure to install {\bf mysql-devel}, so that the MySQL
328 header files are available while compiling Bacula. In addition, the MySQL
329 client library {\bf mysqlclient} requires the gzip compression library {\bf
330 libz.a} or {\bf libz.so}. If you are using rpm packages, these libraries are
331 in the {\bf libz-devel} package. On Debian systems, you will need to load the
332 {\bf zlib1g-dev} package. If you are not using rpms or debs, you will need to
333 find the appropriate package for your system.
335 Note, if you already have a running MySQL or PostgreSQL on your system, you
336 can skip this phase provided that you have built the thread safe libraries.
337 And you have already installed the additional rpms noted above.
339 SQLite is not supported on Solaris. This is because it
340 frequently fails with bus errors.
342 \item Detar the Bacula source code preferably into the {\bf bacula} directory
345 \item {\bf cd} to the directory containing the source code.
347 \item ./configure (with appropriate options as described below)
349 \item Check the output of ./configure very carefully, especially the Install
350 binaries and Install config directories. If they are not correct,
351 please rerun ./configure until they are. The output from ./configure is
352 stored in {\bf config.out} and can be re-displayed at any time without
353 rerunning the ./configure by doing {\bf cat config.out}.
355 \item If after running ./configure once, you decide to change options and
356 re-run it, that is perfectly fine, but before re-running it, you should run:
365 so that you are sure to start from scratch and not have a mixture of the two
366 options. This is because ./configure caches much of the information. The {\bf
367 make distclean} is also critical if you move the source directory from one
368 machine to another. If the {\bf make distclean} fails, just ignore it and
372 If you get errors while linking in the Storage daemon directory
373 (src/stored), it is probably because you have not loaded the static
374 libraries on your system. I noticed this problem on a Solaris system.
375 To correct it, make sure that you have not added {\bf
376 {-}{-}enable-static-tools} to the {\bf ./configure} command.
378 If you skip this step ({\bf make}) and proceed immediately to the {\bf
379 make install} you are making two serious errors: 1. your install will
380 fail because Bacula requires a {\bf make} before a {\bf make install}.
381 2. you are depriving yourself of the chance to make sure there are no
382 errors before beginning to write files to your system directories.
386 Please be sure you have done a {\bf make} before entering this command,
387 and that everything has properly compiled and linked without errors.
390 \item If you are new to Bacula, we {\bf strongly} recommend that you skip
391 the next step and use the default configuration files, then run the
392 example program in the next chapter, then come back and modify your
393 configuration files to suit your particular needs.
395 \item Customize the configuration files for each of the three daemons
396 (Directory, File, Storage) and for the Console program. For the details
397 of how to do this, please see \ilink{Setting Up Bacula Configuration
398 Files}{ConfigureChapter} in the Configuration chapter of this manual. We
399 recommend that you start by modifying the default configuration files
400 supplied, making the minimum changes necessary. Complete customization
401 can be done after you have Bacula up and running. Please take care when
402 modifying passwords, which were randomly generated, and the {\bf Name}s
403 as the passwords and names must agree between the configuration files
404 for security reasons.
406 \label{CreateDatabase}
407 \item Create the Bacula MySQL database and tables
409 \ilink{Installing and Configuring MySQL Phase II}{mysql_phase2} or
410 create the Bacula PostgreSQL database and tables
411 \ilink{Configuring PostgreSQL
412 II}{PostgreSQL_configure} or alternatively if you are using
413 SQLite \ilink{Installing and Configuring SQLite Phase II}{phase2}.
415 \item Start Bacula ({\bf ./bacula start}) Note. the next chapter shows you
416 how to do this in detail.
418 \item Interface with Bacula using the Console program
420 \item For the previous two items, please follow the instructions in the
421 \ilink{Running Bacula}{TutorialChapter} chapter of this manual,
422 where you will run a simple backup and do a restore. Do this before you make
423 heavy modifications to the configuration files so that you are sure that
424 Bacula works and are familiar with it. After that changing the conf files
427 \item If after installing Bacula, you decide to "move it", that is to
428 install it in a different set of directories, proceed as follows:
434 ./configure (your-new-options)
443 If all goes well, the {\bf ./configure} will correctly determine which
444 operating system you are running and configure the source code appropriately.
445 Currently, FreeBSD, Linux (Red Hat), and Solaris are supported. The Bacula
446 client (File daemon) is reported to work with MacOS X 10.3 is if
447 readline support is not enabled (default) when building the client.
449 If you install Bacula on more than one system, and they are identical, you can
450 simply transfer the source tree to that other system and do a "make
451 install". However, if there are differences in the libraries or OS versions,
452 or you wish to install on a different OS, you should start from the original
453 compress tar file. If you do transfer the source tree, and you have previously
454 done a ./configure command, you MUST do:
462 prior to doing your new ./configure. This is because the GNU autoconf tools
463 cache the configuration, and if you re-use a configuration for a Linux machine
464 on a Solaris, you can be sure your build will fail. To avoid this, as
465 mentioned above, either start from the tar file, or do a "make distclean".
467 In general, you will probably want to supply a more complicated {\bf
468 configure} statement to ensure that the modules you want are built and that
469 everything is placed into the correct directories.
471 For example, on Fedora, Red Hat, or SuSE one could use the following:
477 --sbindir=$HOME/bacula/bin \
478 --sysconfdir=$HOME/bacula/bin \
479 --with-pid-dir=$HOME/bacula/bin/working \
480 --with-subsys-dir=$HOME/bacula/bin/working \
482 --with-working-dir=$HOME/bacula/bin/working \
483 --with-dump-email=$USER
487 Note, the advantage of using the above configuration to start is that
488 everything will be put into a single directory, which you can later delete
489 once you have run the examples in the next chapter and learned how Bacula
490 works. In addition, the above can be installed and run as non-root.
492 For the developer's convenience, I have added a {\bf defaultconfig} script to
493 the {\bf examples} directory. This script contains the statements that you
494 would normally use, and each developer/user may modify them to suit his needs.
495 You should find additional useful examples in this directory as well.
497 The {\bf \verb:--:enable-conio} or {\bf \verb:--:enable-readline} options are useful because
498 they provide a command line history and editing capability for the Console
499 program. If you have included either option in the build, either the {\bf
500 termcap} or the {\bf ncurses} package will be needed to link. On most
501 systems, including Red Hat and SuSE, you should include the ncurses package.
502 If Bacula's configure process finds the ncurses libraries, it will use
503 those rather than the termcap library.
504 On some systems, such as SuSE, the termcap library is not in the standard
505 library directory. As a consequence, the option may be disabled or you may
506 get an error message such as:
510 /usr/lib/gcc-lib/i586-suse-linux/3.3.1/.../ld:
511 cannot find -ltermcap
512 collect2: ld returned 1 exit status
516 while building the Bacula Console. In that case, you will need to set the {\bf
517 LDFLAGS} environment variable prior to building.
521 export LDFLAGS="-L/usr/lib/termcap"
525 The same library requirements apply if you wish to use the readline
526 subroutines for command line editing and history or
527 if you are using a MySQL library that requires encryption. If you need encryption,
528 you can either export the appropriate additional library options as shown
529 above or, alternatively, you can include them directly on the ./configure line
534 LDFLAGS="-lssl -lcyrpto" \
535 ./configure <your-options>
539 On some systems such as Mandriva, readline tends to
540 gobble up prompts, which makes it totally useless. If this happens to you, use
541 the disable option, or if you are using version 1.33 and above try using {\bf
542 \verb:--:enable-conio} to use a built-in readline replacement. You will still need
543 either the termcap or the ncurses library, but it is unlikely that the {\bf conio}
544 package will gobble up prompts.
546 readline is no longer supported after version 1.34. The code within Bacula
547 remains, so it should be usable, and if users submit patches for it, we will
548 be happy to apply them. However, due to the fact that each version of
549 readline seems to be incompatible with previous versions, and that there
550 are significant differences between systems, we can no longer afford to
553 \section{What Database to Use?}
555 \index[general]{What Database to Use?}
556 \index[general]{Use!What Database to}
558 Before building Bacula you need to decide if you want to use SQLite, MySQL, or
559 PostgreSQL. If you are not already running MySQL or PostgreSQL, you might
560 want to start by testing with SQLite (not supported on Solaris).
561 This will greatly simplify the setup for you
562 because SQLite is compiled into Bacula an requires no administration. It
563 performs well and is suitable for small to medium sized installations (maximum
564 10-20 machines). However, we should note that a number of users have
565 had unexplained database corruption with SQLite. For that reason, we
566 recommend that you install either MySQL or PostgreSQL for production
569 If you wish to use MySQL as the Bacula catalog, please see the
570 \ilink{Installing and Configuring MySQL}{MySqlChapter} chapter of
571 this manual. You will need to install MySQL prior to continuing with the
572 configuration of Bacula. MySQL is a high quality database that is very
573 efficient and is suitable for any sized installation. It is slightly more
574 complicated than SQLite to setup and administer because it has a number of
575 sophisticated features such as userids and passwords. It runs as a separate
576 process, is truly professional and can manage a database of any size.
578 If you wish to use PostgreSQL as the Bacula catalog, please see the
579 \ilink{Installing and Configuring PostgreSQL}{PostgreSqlChapter}
580 chapter of this manual. You will need to install PostgreSQL prior to
581 continuing with the configuration of Bacula. PostgreSQL is very similar to
582 MySQL, though it tends to be slightly more SQL92 compliant and has many more
583 advanced features such as transactions, stored procedures, and the such. It
584 requires a certain knowledge to install and maintain.
586 If you wish to use SQLite as the Bacula catalog, please see
587 \ilink{Installing and Configuring SQLite}{SqlLiteChapter} chapter of
588 this manual. SQLite is not supported on Solaris.
590 \section{Quick Start}
591 \index[general]{Quick Start}
592 \index[general]{Start!Quick}
594 There are a number of options and important considerations given below
595 that you can skip for the moment if you have not had any problems building
596 Bacula with a simplified configuration as shown above.
598 If the ./configure process is unable to find specific libraries (e.g.
599 libintl, you should ensure that the appropriate package is installed on
600 your system. Alternatively, if the package is installed in a non-standard
601 location (as far as Bacula is concerned), then there is generally an
602 option listed below (or listed with "./configure {-}{-}help" that will
603 permit you to specify the directory that should be searched. In other
604 cases, there are options that will permit you to disable to feature
605 (e.g. {-}{-}disable-nls).
607 If you want to dive right into it, we recommend you skip to the next chapter,
608 and run the example program. It will teach you a lot about Bacula and as an
609 example can be installed into a single directory (for easy removal) and run as
610 non-root. If you have any problems or when you want to do a real installation,
611 come back to this chapter and read the details presented below.
613 \section{Configure Options}
615 \index[general]{Options!Configure}
616 \index[general]{Configure Options}
618 The following command line options are available for {\bf configure} to
619 customize your installation.
622 \item [ {-}{-}sbindir=\lt{}binary-path\gt{}]
623 \index[general]{{-}{-}sbindir}
624 Defines where the Bacula binary (executable) files will be placed during a
625 {\bf make install} command.
627 \item [ {-}{-}sysconfdir=\lt{}config-path\gt{}]
628 \index[general]{{-}{-}sysconfdir}
629 Defines where the Bacula configuration files should be placed during a
630 {\bf make install} command.
632 \item [ {-}{-}mandir=\lt{}path\gt{}]
633 \index[general]{{-}{-}mandir}
634 Note, as of Bacula version 1.39.14, the meaning of any path
635 specified on this option is change from prior versions. It
636 now specifies the top level man directory.
637 Previously the mandir specified the full path to where you
638 wanted the man files installed.
639 The man files will be installed in gzip'ed format under
640 mandir/man1 and mandir/man8 as appropriate.
641 For the install to succeed you must have {\bf gzip} installed
644 By default, Bacula will install the Unix man pages in
645 /usr/share/man/man1 and /usr/share/man/man8.
646 If you wish the man page to be installed in
647 a different location, use this option to specify the path.
648 Note, the main HTML and PDF Bacula documents are in a separate
649 tar file that is not part of the source distribution.
651 \item [ {-}{-}datadir=\lt{}path\gt{} ]
652 \index[general]{{-}{-}datadir}
653 If you translate Bacula or parts of Bacula into a different language
654 you may specify the location of the po files using the {\bf
655 {-}{-}datadir} option. You must manually install any po files as
656 Bacula does not (yet) automatically do so.
658 \item [ {-}{-}disable-ipv6 ]
659 \index[general]{{-}{-}disable-ipv6}
661 \item [ {-}{-}enable-smartalloc ]
662 \index[general]{{-}{-}enable-smartalloc}
663 This enables the inclusion of the Smartalloc orphaned buffer detection
664 code. This option is highly recommended. Because we never build
665 without this option, you may experience problems if it is not enabled.
666 In this case, simply re-enable the option. We strongly recommend
667 keeping this option enabled as it helps detect memory leaks. This
668 configuration parameter is used while building Bacula
670 \item [ {-}{-}enable-bat ]
671 \index[general]{{-}{-}enable-bat}
672 If you have Qt4 >= 4.2 installed on your computer including the
673 libqt4 and libqt4-devel libraries, and you want to use the
674 Bacula Administration Tool (bat) GUI Console interface to Bacula, you
675 must specify this option. Doing so will build everything in the {\bf
676 src/qt-console} directory. In addition to the Qt4 libraries, bat
677 needs the qwt package installed on your system. Please see the
678 next configure item for the details.
680 \item [ {-}{-}with-qwt=\lt{}path\gt{} ]
681 \index[general]{{-}{-}with-qwt}
682 To build bat, you need the qwt graphics package installed on
683 your system. The qwt package is available for download from
684 the qwt project on Source Forge. If you wish, you may build and
685 install it on your system (by default in /usr/lib). If you have
686 done so, you would specify:
689 --with-qwt=/usr/lib/qwt-5.0.2
692 Alternatively, you can download the Bacula depkgs package (currently
693 version 11Jul07) and build it, then assuming that you have put it
694 into a directory named bacula, you would specify:
697 --with-qwt=$HOME/bacula/depkgs/qwt
701 \item [ {-}{-}enable-batch-insert ]
702 \index[general]{{-}{-}enable-batch-insert}
703 This option enables batch inserts of the attribute records (default) in
704 the catalog database, which is much faster (10 times or more) than
705 without this option for large numbers of files. However, this option
706 will automatically be disabled if your SQL libraries are not
707 thread safe. SQLite2 is not thread safe, so this option cannot
708 be enabled when using it. However, on most systems, PostgreSQL,
709 and SQLite3 are thread safe. Bacula always links to the thread safe
712 As far as we can determine SQLite2 is not thread safe and so should
713 not be used if you have enabled batch insert in Bacula.
715 As a default, Bacula runs SQLite3 with {\bf PRAGMA synchronous=OFF}
716 because it improves performance by more than 30 times. However, it
717 increases the possibility of a corrupted database. If you want more
718 security, please modify src/version.h appropriately (it should be
719 obvious when you look at the file).
721 \item [ {-}{-}enable-gnome ]
722 \index[general]{{-}{-}enable-gnome}
723 If you have GNOME installed on your computer including the
724 GNOME development libraries, and you want to use the
725 GNOME GUI Console interface to Bacula, you must specify this option.
726 Doing so will build everything in the {\bf src/gnome2-console} directory.
728 \item [ {-}{-}enable-bwx-console ]
729 \index[general]{{-}{-}enable-bwx-console}
730 If you have wxWidgets installed on your computer and you want to use the
731 wxWidgets GUI Console interface to Bacula, you must specify this option.
732 Doing so will build everything in the {\bf src/wx-console} directory.
733 This could also be useful to users who want a GUI Console and don't want
734 to install GNOME, as wxWidgets can work with GTK+, Motif or even X11
737 \item [ {-}{-}enable-tray-monitor ]
738 \index[general]{{-}{-}enable-tray-monitor}
739 If you have GTK installed on your computer, you run a graphical
740 environment or a window manager compatible with the FreeDesktop system
741 tray standard (like KDE and GNOME) and you want to use a GUI to monitor
742 Bacula daemons, you must specify this option. Doing so will build
743 everything in the {\bf src/tray-monitor} directory.
745 \item [ {-}{-}enable-static-tools]
746 \index[general]{{-}{-}enable-static-tools}
747 This option causes the linker to link the Storage daemon utility tools
748 ({\bf bls}, {\bf bextract}, and {\bf bscan}) statically. This permits
749 using them without having the shared libraries loaded. If you have
750 problems linking in the {\bf src/stored} directory, make sure you have
751 not enabled this option, or explicitly disable static linking by adding
752 {\bf \verb:--:disable-static-tools}.
754 \item [ {-}{-}enable-static-fd]
755 \index[general]{{-}{-}enable-static-fd}
756 This option causes the make process to build a {\bf static-bacula-fd} in
757 addition to the standard File daemon. This static version will include
758 statically linked libraries and is required for the Bare Metal recovery.
759 This option is largely superseded by using {\bf make static-bacula-fd}
760 from with in the {\bf src/filed} directory. Also, the {\bf
761 \verb:--:enable-client-only} option described below is useful for just
762 building a client so that all the other parts of the program are not
765 When linking a static binary, the linker needs the static versions
766 of all the libraries that are used, so frequently users will
767 experience linking errors when this option is used. The first
768 thing to do is to make sure you have the static glibc library
769 installed on your system. The second thing to do is the make sure
770 you do not specify {\bf {-}{-}openssl} or {\bf {-}{-}with-python}
771 on your ./configure statement as these options require additional
772 libraries. You may be able to enable those options, but you will
773 need to load additional static libraries.
776 \item [ {-}{-}enable-static-sd]
777 \index[general]{{-}{-}enable-static-sd}
778 This option causes the make process to build a {\bf static-bacula-sd} in
779 addition to the standard Storage daemon. This static version will
780 include statically linked libraries and could be useful during a Bare
783 When linking a static binary, the linker needs the static versions
784 of all the libraries that are used, so frequently users will
785 experience linking errors when this option is used. The first
786 thing to do is to make sure you have the static glibc library
787 installed on your system. The second thing to do is the make sure
788 you do not specify {\bf {-}{-}openssl} or {\bf {-}{-}with-python}
789 on your ./configure statement as these options require additional
790 libraries. You may be able to enable those options, but you will
791 need to load additional static libraries.
794 \item [ {-}{-}enable-static-dir]
795 \index[general]{{-}{-}enable-static-dir}
796 This option causes the make process to build a {\bf static-bacula-dir}
797 in addition to the standard Director. This static version will include
798 statically linked libraries and could be useful during a Bare Metal
801 When linking a static binary, the linker needs the static versions
802 of all the libraries that are used, so frequently users will
803 experience linking errors when this option is used. The first
804 thing to do is to make sure you have the static glibc library
805 installed on your system. The second thing to do is the make sure
806 you do not specify {\bf {-}{-}openssl} or {\bf {-}{-}with-python}
807 on your ./configure statement as these options require additional
808 libraries. You may be able to enable those options, but you will
809 need to load additional static libraries.
812 \item [ {-}{-}enable-static-cons]
813 \index[general]{{-}{-}enable-static-cons}
814 This option causes the make process to build a {\bf static-console} and
815 a {\bf static-gnome-console} in addition to the standard console. This
816 static version will include statically linked libraries and could be
817 useful during a Bare Metal recovery.
819 When linking a static binary, the linker needs the static versions
820 of all the libraries that are used, so frequently users will
821 experience linking errors when this option is used. The first
822 thing to do is to make sure you have the static glibc library
823 installed on your system. The second thing to do is the make sure
824 you do not specify {\bf {-}{-}openssl} or {\bf {-}{-}with-python}
825 on your ./configure statement as these options require additional
826 libraries. You may be able to enable those options, but you will
827 need to load additional static libraries.
830 \item [ {-}{-}enable-client-only]
831 \index[general]{{-}{-}enable-client-only}
832 This option causes the make process to build only the File daemon and
833 the libraries that it needs. None of the other daemons, storage tools,
834 nor the console will be built. Likewise a {\bf make install} will then
835 only install the File daemon. To cause all daemons to be built, you
836 will need to do a configuration without this option. This option
837 greatly facilitates building a Client on a client only machine.
839 When linking a static binary, the linker needs the static versions
840 of all the libraries that are used, so frequently users will
841 experience linking errors when this option is used. The first
842 thing to do is to make sure you have the static glibc library
843 installed on your system. The second thing to do is the make sure
844 you do not specify {\bf {-}{-}openssl} or {\bf {-}{-}with-python}
845 on your ./configure statement as these options require additional
846 libraries. You may be able to enable those options, but you will
847 need to load additional static libraries.
849 \item [ {-}{-}enable-build-dird]
850 \index[general]{{-}{-}enable-build-dird}
851 This option causes the make process to build the Director and the
852 Director's tools. By default, this option is on, but you may turn
853 it off by using {\bf {-}{-}disable-build-dird} to prevent the
854 Director from being built.
856 \item [ {-}{-}enable-build-stored]
857 \index[general]{{-}{-}enable-build-stored}
858 This option causes the make process to build the Storage daemon.
859 By default, this option is on, but you may turn
860 it off by using {\bf {-}{-}disable-build-stored} to prevent the
861 Storage daemon from being built.
864 \item [ {-}{-}enable-largefile]
865 \index[general]{{-}{-}enable-largefile}
866 This option (default) causes Bacula to be built with 64 bit file address
867 support if it is available on your system. This permits Bacula to read and
868 write files greater than 2 GBytes in size. You may disable this feature and
869 revert to 32 bit file addresses by using {\bf \verb:--:disable-largefile}.
871 \item [ {-}{-}disable-nls]
872 \index[general]{{-}{-}disable-nls}
873 By default, Bacula uses the GNU Native Language Support (NLS) libraries. On
874 some machines, these libraries may not be present or may not function
875 correctly (especially on non-Linux implementations). In such cases, you
876 may specify {\bf {-}{-}disable-nls} to disable use of those libraries.
877 In such a case, Bacula will revert to using English.
879 \item [ {-}{-}disable-ipv6 ]
880 \index[general]{{-}{-}disable-ipv6}
881 By default, Bacula enables IPv6 protocol. On some systems, the files
882 for IPv6 may exist, but the functionality could be turned off in the
883 kernel. In that case, in order to correctly build Bacula, you will
884 explicitly need to use this option so that Bacula does not attempt
885 to reference OS function calls that do not exist.
887 \item [ {-}{-}with-sqlite=\lt{}sqlite-path\gt{}]
888 \index[general]{{-}{-}with-sqlite}
889 This enables use of the SQLite version 2.8.x database. The {\bf
890 sqlite-path} is not normally specified as Bacula looks for the necessary
891 components in a standard location ({\bf depkgs/sqlite}). See
892 \ilink{Installing and Configuring SQLite}{SqlLiteChapter} chapter of
893 this manual for more details. SQLite is not supported on Solaris.
895 See the note below under the {-}{-}with-postgresql item.
897 \item [ {-}{-}with-sqlite3=\lt{}sqlite3-path\gt{}]
898 \index[general]{{-}{-}with-sqlite3}
899 This enables use of the SQLite version 3.x database. The {\bf
900 sqlite3-path} is not normally specified as Bacula looks for the
901 necessary components in a standard location ({\bf depkgs/sqlite3}). See
902 \ilink{Installing and Configuring SQLite}{SqlLiteChapter} chapter of
903 this manual for more details. SQLite3 is not supported on Solaris.
905 \item [ {-}{-}with-mysql=\lt{}mysql-path\gt{}]
906 \index[general]{{-}{-}with-mysql}
907 This enables building of the Catalog services for Bacula. It assumes
908 that MySQL is running on your system, and expects it to be installed in
909 the {\bf mysql-path} that you specify. Normally, if MySQL is installed
910 in a standard system location, you can simply use {\bf {-}{-}with-mysql}
911 with no path specification. If you do use this option, please proceed
912 to installing MySQL in the \ilink{Installing and Configuring
913 MySQL}{MySqlChapter} chapter before proceeding with the configuration.
915 See the note below under the {-}{-}with-postgresql item.
917 \item [ {-}{-}with-postgresql=\lt{}path\gt{}]
918 \index[general]{{-}{-}with-postgresql}
919 This provides an explicit path to the PostgreSQL libraries if Bacula
920 cannot find it by default. Normally to build with PostgreSQL, you would
921 simply use {\bf {-}{-}with-postgresql}.
923 Note, for Bacula to be configured properly, you must specify one
924 of the four database options supported. That is:
925 {-}{-}with-sqlite, {-}{-}with-sqlite3, {-}{-}with-mysql, or
926 {-}{-}with-postgresql, otherwise the ./configure will fail.
928 \item [ {-}{-}with-openssl=\lt{}path\gt{}]
929 This configuration option is necessary if you want to enable TLS (ssl),
930 which encrypts the communications within
931 Bacula or if you want to use File Daemon PKI data encryption.
932 Normally, the {\bf path} specification is not necessary since
933 the configuration searches for the OpenSSL libraries in standard system
934 locations. Enabling OpenSSL in Bacula permits secure communications
935 between the daemons and/or data encryption in the File daemon.
936 For more information on using TLS, please see the
937 \ilink{Bacula TLS -- Communications Encryption}{CommEncryption} chapter
939 For more information on using PKI data encryption, please see the
940 \ilink{Bacula PKI -- Data Encryption}{DataEncryption}
941 chapter of this manual.
943 \item [ {-}{-}with-python=\lt{}path\gt{}]
944 \index[general]{{-}{-}with-python}
945 This option enables Bacula support for Python. If no path is supplied,
946 configure will search the standard library locations for Python 2.2,
947 2.3, 2.4, or 2.5. If it cannot find the library, you will need to
948 supply a path to your Python library directory. Please see the
949 \ilink{Python chapter}{PythonChapter} for the details of using Python
952 \item [ {-}{-}with-libintl-prefix=\lt{}DIR\gt{}]
953 \index[general]{{-}{-}with-libintl-prefix}
954 This option may be used to tell Bacula to search DIR/include and
955 DIR/lib for the libintl headers and libraries needed for Native
956 Language Support (NLS).
958 \item [ {-}{-}enable-conio]
959 \index[general]{{-}{-}enable-conio}
960 Tells Bacula to enable building the small, light weight readline
961 replacement routine. It is generally much easier to configure than
962 readline, although, like readline, it needs either the termcap or
965 \item [ {-}{-}with-readline=\lt{}readline-path\gt{}]
966 \index[general]{{-}{-}with-readline}
967 Tells Bacula where {\bf readline} is installed. Normally, Bacula will
968 find readline if it is in a standard library. If it is not found and no
969 {-}{-}with-readline is specified, readline will be disabled. This
970 option affects the Bacula build. Readline provides the Console program
971 with a command line history and editing capability and is no longer
972 supported, so you are on your own if you have problems.
974 \item [ {-}{-}enable-readline]
975 \index[general]{{-}{-}enable-readline}
976 Tells Bacula to enable readline support. It is normally disabled due to the
977 large number of configuration problems and the fact that the package seems to
978 change in incompatible ways from version to version.
980 \item [ {-}{-}with-tcp-wrappers=\lt{}path\gt{}]
981 \index[general]{{-}{-}with-tcp-wrappers}
982 \index[general]{TCP Wrappers}
983 \index[general]{Wrappers!TCP}
984 \index[general]{libwrappers}
985 This specifies that you want TCP wrappers (man hosts\_access(5)) compiled in.
986 The path is optional since Bacula will normally find the libraries in the
987 standard locations. This option affects the Bacula build. In specifying your
988 restrictions in the {\bf /etc/hosts.allow} or {\bf /etc/hosts.deny} files, do
989 not use the {\bf twist} option (hosts\_options(5)) or the Bacula process will
990 be terminated. Note, when setting up your {\bf /etc/hosts.allow}
991 or {\bf /etc/hosts.deny}, you must identify the Bacula daemon in
992 question with the name you give it in your conf file rather than the
993 name of the executable.
995 For more information on configuring and testing TCP wrappers, please see the
996 \ilink{Configuring and Testing TCP Wrappers}{wrappers} section
997 in the Security Chapter.
999 On SuSE, the libwrappers libraries needed to link Bacula are
1000 contained in the tcpd-devel package. On Red Hat, the package is named
1003 \item [ {-}{-}with-working-dir=\lt{}working-directory-path\gt{} ]
1004 \index[general]{{-}{-}with-working-dir}
1005 This option is mandatory and specifies a directory into which Bacula may
1006 safely place files that will remain between Bacula executions. For example,
1007 if the internal database is used, Bacula will keep those files in this
1008 directory. This option is only used to modify the daemon configuration
1009 files. You may also accomplish the same thing by directly editing them later.
1010 The working directory is not automatically created by the install process, so
1011 you must ensure that it exists before using Bacula for the first time.
1013 \item [ {-}{-}with-base-port=\lt{}port=number\gt{}]
1014 \index[general]{{-}{-}with-base-port}
1015 In order to run, Bacula needs three TCP/IP ports (one for the Bacula
1016 Console, one for the Storage daemon, and one for the File daemon). The {\bf
1017 \verb:--:with-baseport} option will automatically assign three ports beginning at
1018 the base port address specified. You may also change the port number in the
1019 resulting configuration files. However, you need to take care that the
1020 numbers correspond correctly in each of the three daemon configuration
1021 files. The default base port is 9101, which assigns ports 9101 through 9103.
1022 These ports (9101, 9102, and 9103) have been officially assigned to Bacula by
1023 IANA. This option is only used to modify the daemon configuration files. You
1024 may also accomplish the same thing by directly editing them later.
1026 \item [ {-}{-}with-dump-email=\lt{}email-address\gt{}]
1027 \index[general]{{-}{-}with-dump-email}
1028 This option specifies the email address where any core dumps should be set.
1029 This option is normally only used by developers.
1031 \item [ {-}{-}with-pid-dir=\lt{}PATH\gt{} ]
1032 \index[general]{{-}{-}with-pid-dir}
1033 This specifies where Bacula should place the process id file during
1034 execution. The default is: {\bf /var/run}. This directory is not created by
1035 the install process, so you must ensure that it exists before using Bacula
1038 \item [ {-}{-}with-subsys-dir=\lt{}PATH\gt{}]
1039 \index[general]{{-}{-}with-subsys-dir}
1040 This specifies where Bacula should place the subsystem lock file during
1041 execution. The default is {\bf /var/run/subsys}. Please make sure that you do
1042 not specify the same directory for this directory and for the {\bf sbindir}
1043 directory. This directory is used only within the autostart scripts. The
1044 subsys directory is not created by the Bacula install, so you must be sure to
1045 create it before using Bacula.
1047 \item [ {-}{-}with-dir-password=\lt{}Password\gt{}]
1048 \index[general]{{-}{-}with-dir-password}
1049 This option allows you to specify the password used to access the Director
1050 (normally from the Console program). If it is not specified, configure will
1051 automatically create a random password.
1053 \item [ {-}{-}with-fd-password=\lt{}Password\gt{} ]
1054 \index[general]{{-}{-}with-fd-password}
1055 This option allows you to specify the password used to access the File daemon
1056 (normally called from the Director). If it is not specified, configure will
1057 automatically create a random password.
1059 \item [ {-}{-}with-sd-password=\lt{}Password\gt{} ]
1060 \index[general]{{-}{-}with-sd-password}
1061 This option allows you to specify the password used to access the Storage daemon
1062 (normally called from the Director). If it is not specified, configure will
1063 automatically create a random password.
1065 \item [ {-}{-}with-dir-user=\lt{}User\gt{} ]
1066 \index[general]{{-}{-}with-dir-user}
1067 This option allows you to specify the Userid used to run the Director. The
1068 Director must be started as root, but doesn't need to run as root, and
1069 after doing preliminary initializations, it can "drop" to the UserId
1070 specified on this option.
1071 If you specify this option, you must
1072 create the User prior to running {\bf make install}, because the
1073 working directory owner will be set to {\bf User}.
1075 \item [ {-}{-}with-dir-group=\lt{}Group\gt{} ]
1076 \index[general]{{-}{-}with-dir-group}
1077 This option allows you to specify the GroupId used to run the Director. The
1078 Director must be started as root, but doesn't need to run as root, and after
1079 doing preliminary initializations, it can "drop" to the GroupId specified
1081 If you specify this option, you must
1082 create the Group prior to running {\bf make install}, because the
1083 working directory group will be set to {\bf Group}.
1085 \item [ {-}{-}with-sd-user=\lt{}User\gt{} ]
1086 \index[general]{{-}{-}with-sd-user}
1087 This option allows you to specify the Userid used to run the Storage daemon.
1088 The Storage daemon must be started as root, but doesn't need to run as root,
1089 and after doing preliminary initializations, it can "drop" to the UserId
1090 specified on this option. If you use this option, you will need to take care
1091 that the Storage daemon has access to all the devices (tape drives, ...) that
1094 \item [ {-}{-}with-sd-group=\lt{}Group\gt{} ]
1095 \index[general]{{-}{-}with-sd-group}
1096 This option allows you to specify the GroupId used to run the Storage daemon.
1097 The Storage daemon must be started as root, but doesn't need to run as root,
1098 and after doing preliminary initializations, it can "drop" to the GroupId
1099 specified on this option.
1101 \item [ {-}{-}with-fd-user=\lt{}User\gt{} ]
1102 \index[general]{{-}{-}with-fd-user}
1103 This option allows you to specify the Userid used to run the File daemon. The
1104 File daemon must be started as root, and in most cases, it needs to run as
1105 root, so this option is used only in very special cases, after doing
1106 preliminary initializations, it can "drop" to the UserId specified on this
1109 \item [ {-}{-}with-fd-group=\lt{}Group\gt{} ]
1110 \index[general]{{-}{-}with-fd-group}
1111 This option allows you to specify the GroupId used to run the File daemon.
1112 The File daemon must be started as root, and in most cases, it must be run as
1113 root, however, after doing preliminary initializations, it can "drop" to
1114 the GroupId specified on this option.
1116 \item [ {-}{-}with-mon-dir-password=\lt{}Password\gt{}]
1117 \index[general]{{-}{-}with-mon-dir-password}
1118 This option allows you to specify the password used to access the Directory
1119 from the monitor. If it is not specified, configure will
1120 automatically create a random password.
1122 \item [ {-}{-}with-mon-fd-password=\lt{}Password\gt{} ]
1123 \index[general]{{-}{-}with-mon-fd-password}
1124 This option allows you to specify the password used to access the File daemon
1125 from the Monitor. If it is not specified, configure will
1126 automatically create a random password.
1128 \item [ {-}{-}with-mon-sd-password=\lt{}Password\gt{} ]
1129 \index[general]{{-}{-}with-mon-sd-password}
1130 This option allows you to specify the password used to access the
1131 Storage daemon from the Monitor. If it is not specified, configure will
1132 automatically create a random password.
1134 \item [ {-}{-}with-db-name=\lt{}database-name\gt{} ]
1135 \index[general]{{-}{-}with-db-name}
1136 This option allows you to specify the database name to be used in
1137 the conf files. The default is bacula.
1139 \item [ {-}{-}with-db-user=\lt{}database-user\gt{} ]
1140 \index[general]{{-}{-}with-db-user}
1141 This option allows you to specify the database user name to be used in
1142 the conf files. The default is bacula.
1146 Note, many other options are presented when you do a {\bf ./configure
1147 \verb:--:help}, but they are not implemented.
1149 \section{Recommended Options for Most Systems}
1150 \index[general]{Systems!Recommended Options for Most}
1151 \index[general]{Recommended Options for Most Systems}
1153 For most systems, we recommend starting with the following options:
1158 --enable-smartalloc \
1159 --sbindir=$HOME/bacula/bin \
1160 --sysconfdir=$HOME/bacula/bin \
1161 --with-pid-dir=$HOME/bacula/bin/working \
1162 --with-subsys-dir=$HOME/bacula/bin/working \
1163 --with-mysql=$HOME/mysql \
1164 --with-working-dir=$HOME/bacula/working
1168 If you want to install Bacula in an installation directory rather than run it
1169 out of the build directory (as developers will do most of the time), you
1170 should also include the \verb:--:sbindir and \verb:--:sysconfdir options with appropriate
1171 paths. Neither are necessary if you do not use "make install" as is the case
1172 for most development work. The install process will create the sbindir and
1173 sysconfdir if they do not exist, but it will not automatically create the
1174 pid-dir, subsys-dir, or working-dir, so you must ensure that they exist before
1175 running Bacula for the first time.
1178 \index[general]{Red Hat}
1185 CFLAGS="-g -Wall" ./configure \
1186 --sbindir=$HOME/bacula/bin \
1187 --sysconfdir=$HOME/bacula/bin \
1188 --enable-smartalloc \
1189 --with-sqlite=$HOME/bacula/depkgs/sqlite \
1190 --with-working-dir=$HOME/bacula/working \
1191 --with-pid-dir=$HOME/bacula/bin/working \
1192 --with-subsys-dir=$HOME/bacula/bin/working \
1194 --with-qwt=$HOME/bacula/depkgs/qwt \
1204 CFLAGS="-g -Wall" ./configure \
1205 --sbindir=$HOME/bacula/bin \
1206 --sysconfdir=$HOME/bacula/bin \
1207 --enable-smartalloc \
1208 --with-mysql=$HOME/mysql \
1209 --with-working-dir=$HOME/bacula/working
1210 --with-pid-dir=$HOME/bacula/bin/working \
1211 --with-subsys-dir=$HOME/bacula/bin/working
1217 or finally, a completely traditional Red Hat Linux install:
1221 CFLAGS="-g -Wall" ./configure \
1223 --sbindir=/usr/sbin \
1224 --sysconfdir=/etc/bacula \
1225 --with-scriptdir=/etc/bacula \
1226 --enable-smartalloc \
1228 --with-qwt=$HOME/bacula/depkgs/qwt \
1230 --with-working-dir=/var/bacula \
1231 --with-pid-dir=/var/run \
1236 Note, Bacula assumes that /var/bacula, /var/run, and /var/lock/subsys exist so
1237 it will not automatically create them during the install process.
1240 \index[general]{Solaris}
1242 To build Bacula from source, you will need the following installed on your
1243 system (they are not by default): libiconv, gcc 3.3.2, stdc++, libgcc (for
1244 stdc++ and gcc\_s libraries), make 3.8 or later.
1246 You will probably also need to: Add /usr/local/bin to PATH and Add
1247 /usr/ccs/bin to PATH for ar.
1249 It is possible to build Bacula on Solaris with the Solaris compiler, but
1250 we recommend using GNU C++ if possible.
1252 A typical configuration command might look like:
1257 CFLAGS="-g" ./configure \
1258 --sbindir=$HOME/bacula/bin \
1259 --sysconfdir=$HOME/bacula/bin \
1260 --with-mysql=$HOME/mysql \
1261 --enable-smartalloc \
1262 --with-pid-dir=$HOME/bacula/bin/working \
1263 --with-subsys-dir=$HOME/bacula/bin/working \
1264 --with-working-dir=$HOME/bacula/working
1268 As mentioned above, the install process will create the sbindir and sysconfdir
1269 if they do not exist, but it will not automatically create the pid-dir,
1270 subsys-dir, or working-dir, so you must ensure that they exist before running
1271 Bacula for the first time.
1273 Note, you may need to install the following packages to build Bacula
1293 PATH=/usr/bin::/usr/ccs/bin:/etc:/usr/openwin/bin:/usr/local/bin:/usr/sfw/bin:/opt/sfw/bin:/usr/ucb:/usr/sbin
1297 If you have installed special software not normally in the Solaris
1298 libraries, such as OpenSSL, or the packages shown above, then you may need
1299 to add {\bf /usr/sfw/lib} to the library search path. Probably the
1300 simplest way to do so is to run:
1304 setenv LDFLAGS "-L/usr/sfw/lib -R/usr/sfw/lib"
1308 Prior to running the ./configure command.
1310 Alternatively, you can set the LD\_LIBARY\_PATH and/or the LD\_RUN\_PATH
1311 environment variables appropriately.
1313 It is also possible to use the {\bf crle} program to set the library
1314 search path. However, this should be used with caution.
1317 \index[general]{FreeBSD}
1320 \elink{The FreeBSD Diary}{http://www.freebsddiary.org/bacula.php} for a
1321 detailed description on how to make Bacula work on your system. In addition,
1322 users of FreeBSD prior to 4.9-STABLE dated Mon Dec 29 15:18:01 2003 UTC who
1323 plan to use tape devices, please see the
1324 \ilink{Tape Testing Chapter}{FreeBSDTapes} of this manual for
1325 {\bf important} information on how to configure your tape drive for
1326 compatibility with Bacula.
1328 If you are using Bacula with MySQL, you should take care to compile MySQL with
1329 FreeBSD native threads rather than LinuxThreads, since Bacula is normally built
1330 with FreeBSD native threads rather than LinuxTreads. Mixing the two will
1334 \index[general]{Win32}
1336 To install the binary Win32 version of the File daemon please see the
1337 \ilink{Win32 Installation Chapter}{Win32Chapter} in this document.
1339 \section{One File Configure Script}
1340 \index[general]{Script!One File Configure}
1341 \index[general]{One Files Configure Script}
1343 The following script could be used if you want to put everything
1351 --sbindir=$HOME/bacula/bin \
1352 --sysconfdir=$HOME/bacula/bin \
1353 --mandir=$HOME/bacula/bin \
1354 --enable-smartalloc \
1357 --with-qwt=$HOME/bacula/depkgs/qwt \
1358 --enable-bwx-console \
1359 --enable-tray-monitor \
1360 --with-pid-dir=$HOME/bacula/bin/working \
1361 --with-subsys-dir=$HOME/bacula/bin/working \
1363 --with-working-dir=$HOME/bacula/bin/working \
1364 --with-dump-email=$USER@your-site.com \
1365 --with-job-email=$USER@your-site.com \
1366 --with-smtp-host=mail.your-site.com
1371 You may also want to put the following entries in your {\bf /etc/services}
1372 file as it will make viewing the connections made by Bacula easier to
1373 recognize (i.e. netstat -a):
1383 \section{Installing Bacula}
1384 \index[general]{Bacula!Installing}
1385 \index[general]{Installing Bacula}
1387 Before setting up your configuration files, you will want to install Bacula in
1388 its final location. Simply enter:
1396 If you have previously installed Bacula, the old binaries will be overwritten,
1397 but the old configuration files will remain unchanged, and the "new"
1398 configuration files will be appended with a {\bf .new}. Generally if you have
1399 previously installed and run Bacula you will want to discard or ignore the
1400 configuration files with the appended {\bf .new}.
1402 \section{Building a File Daemon or Client}
1403 \index[general]{Client!Building a File Daemon or}
1404 \index[general]{Building a File Daemon or Client}
1406 If you run the Director and the Storage daemon on one machine and you wish to
1407 back up another machine, you must have a copy of the File daemon for that
1408 machine. If the machine and the Operating System are identical, you can simply
1409 copy the Bacula File daemon binary file {\bf bacula-fd} as well as its
1410 configuration file {\bf bacula-fd.conf} then modify the name and password in
1411 the conf file to be unique. Be sure to make corresponding additions to the
1412 Director's configuration file ({\bf bacula-dir.conf}).
1414 If the architecture or the OS level are different, you will need to build a
1415 File daemon on the Client machine. To do so, you can use the same {\bf
1416 ./configure} command as you did for your main program, starting either from a
1417 fresh copy of the source tree, or using {\bf make\ distclean} before the {\bf
1420 Since the File daemon does not access the Catalog database, you can remove
1421 the {\bf \verb:--:with-mysql} or {\bf \verb:--:with-sqlite} options, then
1422 add {\bf \verb:--:enable-client-only}. This will compile only the
1423 necessary libraries and the client programs and thus avoids the necessity
1424 of installing one or another of those database programs to build the File
1425 daemon. With the above option, you simply enter {\bf make} and just the
1426 client will be built.
1429 \section{Auto Starting the Daemons}
1430 \index[general]{Daemons!Auto Starting the}
1431 \index[general]{Auto Starting the Daemons}
1433 If you wish the daemons to be automatically started and stopped when your
1434 system is booted (a good idea), one more step is necessary. First, the
1435 ./configure process must recognize your system -- that is it must be a
1436 supported platform and not {\bf unknown}, then you must install the platform
1437 dependent files by doing:
1442 make install-autostart
1446 Please note, that the auto-start feature is implemented only on systems
1447 that we officially support (currently, FreeBSD, Red Hat/Fedora Linux, and
1448 Solaris), and has only been fully tested on Fedora Linux.
1450 The {\bf make install-autostart} will cause the appropriate startup scripts
1451 to be installed with the necessary symbolic links. On Red Hat/Fedora Linux
1452 systems, these scripts reside in {\bf /etc/rc.d/init.d/bacula-dir} {\bf
1453 /etc/rc.d/init.d/bacula-fd}, and {\bf /etc/rc.d/init.d/bacula-sd}. However
1454 the exact location depends on what operating system you are using.
1456 If you only wish to install the File daemon, you may do so with:
1460 make install-autostart-fd
1464 \section{Other Make Notes}
1465 \index[general]{Notes!Other Make}
1466 \index[general]{Other Make Notes}
1468 To simply build a new executable in any directory, enter:
1476 To clean out all the objects and binaries (including the files named 1, 2, or
1477 3, which are development temporary files), enter:
1485 To really clean out everything for distribution, enter:
1493 note, this cleans out the Makefiles and is normally done from the top level
1494 directory to prepare for distribution of the source. To recover from this
1495 state, you must redo the {\bf ./configure} in the top level directory, since
1496 all the Makefiles will be deleted.
1498 To add a new file in a subdirectory, edit the Makefile.in in that directory,
1499 then simply do a {\bf make}. In most cases, the make will rebuild the Makefile
1500 from the new Makefile.in. In some case, you may need to issue the {\bf make} a
1501 second time. In extreme cases, cd to the top level directory and enter: {\bf
1504 To add dependencies:
1512 The {\bf make depend} appends the header file dependencies for each of the
1513 object files to Makefile and Makefile.in. This command should be done in each
1514 directory where you change the dependencies. Normally, it only needs to be run
1515 when you add or delete source or header files. {\bf make depend} is normally
1516 automatically invoked during the configuration process.
1526 This not normally done if you are developing Bacula, but is used if you are
1527 going to run it to backup your system.
1529 After doing a {\bf make install} the following files will be installed on your
1530 system (more or less). The exact files and location (directory) for each file
1531 depends on your {\bf ./configure} command (e.g. bgnome-console and
1532 bgnome-console.conf are not installed if you do not configure GNOME. Also, if
1533 you are using SQLite instead of MySQL, some of the files will be different).
1554 create_mysql_database
1556 delete_catalog_backup
1578 \section{Installing Tray Monitor}
1579 \index[general]{Monitor!Installing Tray}
1580 \index[general]{Installing Tray Monitor}
1582 The Tray Monitor is already installed if you used the {\bf
1583 \verb:--:enable-tray-monitor} configure option and ran {\bf make install}.
1585 As you don't run your graphical environment as root (if you do, you should
1586 change that bad habit), don't forget to allow your user to read {\bf
1587 tray-monitor.conf}, and to execute {\bf bacula-tray-monitor} (this is not a
1590 Then log into your graphical environment (KDE, GNOME or something else), run
1591 {\bf bacula-tray-monitor} as your user, and see if a cassette icon appears
1592 somewhere on the screen, usually on the task bar.
1593 If it doesn't, follow the instructions below related to your environment or
1597 \index[general]{GNOME}
1599 System tray, or notification area if you use the GNOME terminology, has been
1600 supported in GNOME since version 2.2. To activate it, right-click on one of
1601 your panels, open the menu {\bf Add to this Panel}, then {\bf Utility} and
1602 finally click on {\bf Notification Area}.
1605 \index[general]{KDE}
1607 System tray has been supported in KDE since version 3.1. To activate it,
1608 right-click on one of your panels, open the menu {\bf Add}, then {\bf Applet}
1609 and finally click on {\bf System Tray}.
1611 \subsection{Other window managers}
1612 \index[general]{Managers!Other window}
1613 \index[general]{Other window managers}
1615 Read the documentation to know if the Freedesktop system tray standard is
1616 supported by your window manager, and if applicable, how to activate it.
1618 \section{Modifying the Bacula Configuration Files}
1619 \index[general]{Modifying the Bacula Configuration Files}
1620 \index[general]{Files!Modifying the Bacula Configuration}
1623 \ilink{Configuring Bacula}{ConfigureChapter} in this manual for
1624 instructions on how to set Bacula configuration files.