--- /dev/null
+
+\section*{Bacula TLS}
+\label{_ChapterStart61}
+\index[general]{Bacula TLS}
+\index[general]{TLS}
+\addcontentsline{toc}{section}{Bacula TLS}
+
+Bacula TLS (Transport Layer Security) is built-in network
+encryption code to provide secure network transport similar to
+that offered by {\bf stunnel} or {\bs ssh}. The Bacula code was
+written by Landon Fuller.
+
+Supported features of this code include:
+\begin{itemize}
+\item Client/Server TLS Requirement Negotiation
+\item TLSv1 Connections with Server and Client Certificate
+Validation
+\item Forward Secrecy Support via Diffie-Hellman Ephemeral Keying
+\end{itemize}
+
+This document will refer to both ``server'' and ``client'' contexts. These
+terms refer to the accepting and initiating peer, respectively.
+
+Diffie-Hellman anonymous ciphers are not supported by this code. The
+use of DH anonymous ciphers increases the code complexity and places
+explicit trust upon the two-way CRAM-MD5 implementation. CRAM-MD5 is
+subject to known plaintext attacks, and it should be considered
+considerably less secure than PKI certificate-based authentication.
+
+Appropriate autoconf macros have been added to detect and use OpenSSL
+if enabled on the {\bf ./configure} line with {\bf \verb?--?enable-openssl}
+
+\subsection*{TLS Configuration Directives}
+\addcontentsline{toc}{section}{TLS Configuration Directives}
+Additional configuration directives have been added to all the daemons
+(Director, File daemon, and Storage daemon) as well as the various
+different Console programs.
+These new directives are defined as follows:
+
+\begin{description}
+\item [TLS Enable = \lt{}yes|no\gt{}]
+Enable TLS support.
+
+\item [TLS Require = \lt{}yes|no\gt{}]
+Require TLS connections.
+
+\item [TLS Certificate = \lt{}Directory\gt{}]
+Path to a PEM encoded TLS certificate. It can be used as either a client
+or server certificate. PEM stands for Privacy Enhanced Mail, but in
+this context refers to how the certificates are encoded. It is used
+because PEM files are base64 encoded and hence ASCII text based
+rather than binary. They may also contain encrypted information.
+
+\item [TLS Key = \lt{}Directory\gt{}]
+Path to a PEM encoded TLS private key. It must correspond to the TLS
+certificate.
+
+\item [TLS Verify Peer = \lt{}yes|no\gt{}]
+Verify peer certificate. Instructs server to request and verify the
+client's x509 certificate. Any client certificate signed by a known-CA
+will be accepted unless the TLS Allowed CN configuration directive is used,
+in which case the client certificate must correspond to the Allowed
+Common Name specified. This directive is valid only for a server
+and not in a client context.
+
+\item [TLS Allowed CN = \lt{}string list\gt{}]
+Common name attribute of allowed peer certificates. If this directive is
+specified, all client certificates will be verified against this list.
+This directive may be specified more than once. It is not valid in a client
+context.
+
+\item [TLS CA Certificate File = \lt{}Filename\gt{}]
+The full path and filename specifying a
+PEM encoded TLS CA certificate(s). Multiple certificates are
+permitted in the file. One of \emph{TLS CA Certificate File} or \emph{TLS
+CA Certificate Dir} are required in a server context if \emph{TLS
+Verify Peer} (see above) is also specified, and are always required in a client
+context.
+
+\item [TLS CA Certificate Dir = \lt{}Directory\gt{}]
+Full path to TLS CA certificate directory. In the current implementation,
+certificates must be stored PEM encoded with OpenSSL-compatible hashes,
+which is the subject name's hash and an extension of {bf .0}.
+One of \emph{TLS CA Certificate File} or \emph{TLS CA Certificate Dir} are
+required in a server context if \emph{TLS Verify Peer} is also specified,
+and are always required in a client context.
+
+\item [TLS DH File = \lt{}Directory\gt{}]
+Path to PEM encoded Diffie-Hellman parameter file. If this directive is
+specified, DH key exchange will be used for the ephemeral keying, allowing
+for forward secrecy of communications. DH key exchange adds an additional
+level of security because the key used for encryption/decryption by the
+server and the client is computed on each end and thus is never passed over
+the network if Diffie-Hellman key exchange is used. Even if DH key
+exchange is not used, the encryption/decryption key is always passed
+encrypted. This directive is only valid within a server context.
+
+To generate the parameter file, you
+may use openssl:
+
+\begin{verbatim}
+ openssl dhparam -out dh1024.pem -5 1024
+\end{verbatim}
+
+\end{itemize}
+
+\subsection*{Creating a Self-signed Certificate}
+\index[general]{Creating a Self-signed Certificate }
+\index[general]{Certificate!Creating a Self-signed }
+\addcontentsline{toc}{subsection}{Creating a Self-signed Certificate}
+
+You may create a self-signed certificate for use with the Bacula TLS that
+will permit you to make it function, but will not allow certificate
+validation. The .pem file containing both the certificate and the key
+valid for 10 years can be made with the following:
+
+\footnotesize
+\begin{verbatim}
+ openssl req -new -x509 -nodes -out bacula.pem -keyout bacula.pem -days 3650
+\end{verbatim}
+\normalsize
+
+The above script will ask you a number of questions. You may simply answer
+each of them by entering a return, or if you wish you may enter your own data.
+
+
+\subsection*{Getting a CA Signed Certificate}
+\index[general]{Certificate!Getting a CA Signed }
+\index[general]{Getting a CA Signed Certificate }
+\addcontentsline{toc}{subsection}{Getting a CA Signed Certificate}
+
+The process of getting a certificate that is signed by a CA is quite a bit
+more complicated. You can purchase one from quite a number of PKI vendors, but
+that is not at all necessary for use with Bacula. To get a CA signed
+certificate, you will either need to find a friend that has setup his own CA
+or to become a CA yourself, and thus you can sign all your own certificates.
+The book OpenSSL by John Viega, Matt Mesier \& Pravir Chandra from O'Reilly
+explains how to do it, or you can read the documentation provided in the
+Open-source PKI Book project at Source Forge:
+\elink{
+http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}
+{http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
+Note, this link may change.
Slot when labeling a Volume.
\item You need to ensure that your Storage daemon (if not running as root)
has access permissions to both the tape drive and the control device.
+\item You need to have {\bf Autochanger = yes} in your Storage resource
+ in your bacula-dir.conf file so that you will be prompted for the
+ slot number when you label Volumes.
\end{itemize}
In version 1.37, there is a new \ilink{Autochanger
%%
\section*{Bacula Console}
-\label{_ChapterStart23}
+\label{_ConsoleChapter}
\index[general]{Console!Bacula }
\index[general]{Bacula Console }
\addcontentsline{toc}{section}{Bacula Console}
\index[dir]{DIRPort }
Specify the port to use to connect to the Director. This value will most
likely already be set to the value you specified on the {\bf
-\verb{--{with-base-port} option of the {\bf ./configure} command. This port must be
+\verb:--:with-base-port} option of the {\bf ./configure} command. This port must be
identical to the {\bf DIRport} specified in the {\bf Director} resource of
the
\ilink{Director's configuration}{_ChapterStart40} file. The
\addcontentsline{toc}{subsection}{Console Commands}
For more details on running the console and its commands, please see the
-\ilink{Bacula Console}{_ChapterStart23} chapter of this manual.
+\ilink{Bacula Console}{_ConsoleChapter} chapter of this manual.
\subsection*{Sample Console Configuration File}
\label{SampleConfiguration2}
not installing Bacula in the system directories, you can use the {\bf Working
Directory} as defined above. This directive is required.
+\item [Scripts Directory = \lt{}Directory\gt{}]
+ \index[dir]{Scripts Directory }
+ This directive is optional and, if defined, specifies a directory in which the Director
+will look for the Python startup script {\bf DirStartup.py}. This directory
+may be shared by other Bacula daemons. Standard shell expansion of the
+directory is done when the configuration file is read so that values such
+as {\bf \$HOME} will be properly expanded.
+
\item [QueryFile = \lt{}Path\gt{}]
\index[dir]{QueryFile }
This directive is mandatory and specifies a directory and file in which the
st\_ctime to change and hence Bacula will backup the file during an
Incremental or Differential backup. In the case of Sophos virus scanning, you
can prevent it from resetting the access time (st\_atime) and hence changing
-st\_ctime by using the {\bf \verb{--{no-reset-atime} option. For other software,
+st\_ctime by using the {\bf \verb:--:no-reset-atime} option. For other software,
please see their manual.
When Bacula does an Incremental backup, all modified files that are still on
\item DVD+RW supports only about 1000 overwrites, so every time you
mount the filesystem read/write will count as one write. This can
add up quickly, so it is best to mount your DVD+RW filesystem read-only.
+ Bacula does not need the DVD to be mounted read-write, since it uses
+ the raw device for writing.
\item Reformating DVD+RW 10-20 time can apparently make the medium
unusable. Normally you should not have to format or reformat
DVD+RW media. If it is necessary, current versions of growisofs will
\begin{verbatim}
growisofs -Z /dev/xxx=/dev/zero
\end{verbatim}
- where you replace xxx with your DVD device name.
+ where you replace xxx with your DVD device name. However, note that this
+ blanks the whole DVD, which takes quite a long time (16 minutes on mine).
\end{itemize}
restore. It also has most of the capabilities of the shell console, allows
command completion with tabulation, and gives you instant help about the
command you are typing. For more details see the
-\ilink{Bacula Console Design Document}{_ChapterStart23}.
+\ilink{Bacula Console Design Document}{_ConsoleChapter}.
\item
\label{FDDef}
{\bf Bacula File} services (or Client program) is the software program that
The licenses for most software are designed to take away your freedom to share
and change it. By contrast, the GNU General Public License is intended to
-guarantee your freedom to share and change free software\verb{--{to make sure the
+guarantee your freedom to share and change free software\verb:--:to make sure the
software is free for all its users. This General Public License applies to
most of the Free Software Foundation's software and to any other program whose
authors commit to using it. (Some other Free Software Foundation software is
The hypothetical commands {\tt `show w'} and {\tt `show c'} should show the
appropriate parts of the General Public License. Of course, the commands you
use may be called something other than {\tt `show w'} and {\tt `show c'}; they
-could even be mouse-clicks or menu items\verb{--{whatever suits your program.
+could even be mouse-clicks or menu items\verb:--:whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a ``copyright disclaimer'' for the program, if
If you get errors while linking in the Storage daemon directory (src/stored),
it is probably because you have not loaded the static libraries on your
system. I noticed this problem on a Solaris system. To correct it, make sure
-that you have not added {\bf \verb{--{enable-static-tools} to the {\bf ./configure}
+that you have not added {\bf \verb:--:enable-static-tools} to the {\bf ./configure}
command.
\item make install
\item If you are new to Bacula, we {\bf strongly} recommend that you skip the
would normally use, and each developer/user may modify them to suit his needs.
You should find additional useful examples in this directory as well.
-The {\bf \verb{--{enable-conio} or {\bf \verb{--{enable-readline} options are useful because
+The {\bf \verb:--:enable-conio} or {\bf \verb:--:enable-readline} options are useful because
they provide a command line history and editing capability for the Console
program. If you have included either option in the build, either the {\bf
termcap} or the {\bf ncurses} package will be needed to link. On some systems,
On some systems such as Mandriva, readline tends to
gobble up prompts, which makes it totally useless. If this happens to you, use
the disable option, or if you are using version 1.33 and above try using {\bf
-\verb{--{enable-conio} to use a built-in readline replacement. You will still need
+\verb:--:enable-conio} to use a built-in readline replacement. You will still need
either the termcap or the ncurses library, but it is unlikely that the {\bf conio}
package will gobble up prompts.
\begin{description}
-\item [ \verb?--?sysbindir=\lt{}binary-path\gt{}]
- \index[dir]{\verb{--{sysbindir }
+\item [ \verb:--:sysbindir=\lt{}binary-path\gt{}]
+ \index[dir]{\verb:--:sysbindir }
Defines where the Bacula binary (executable) files will be placed during a
{\bf make install} command.
-\item [ \verb?--?sysconfdir=\lt{}config-path\gt{}]
- \index[dir]{\verb{--{sysconfdir }
+\item [ \verb:--:sysconfdir=\lt{}config-path\gt{}]
+ \index[dir]{\verb:--:sysconfdir }
Defines where the Bacula configuration files should be placed during a {\bf
make install} command.
-\item [ \verb?--?enable-smartalloc ]
- \index[dir]{\verb{--{enable-smartalloc }
+\item [ \verb:--:enable-smartalloc ]
+ \index[dir]{\verb:--:enable-smartalloc }
This enables the inclusion of the Smartalloc orphaned buffer detection code.
This option is highly recommended. Because we never build without this
option, you may experience problems if it is not enabled. In this case,
enabled as it helps detect memory leaks. This configuration parameter is used
while building Bacula
-\item [ \verb?--?enable-gnome ]
- \index[dir]{\verb{--{enable-gnome }
+\item [ \verb:--:enable-gnome ]
+ \index[dir]{\verb:--:enable-gnome }
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 {\bf src/gnome-console} directory.
-\item [ \verb?--?enable-wx-console ]
- \index[console]{\verb{--{enable-wx-console }
+\item [ \verb:--:enable-wx-console ]
+ \index[console]{\verb:--:enable-wx-console }
If you have wxWidgets installed on your computer and you want to use the
wxWidgets GUI Console interface to Bacula, you must specify this option.
Doing so will build everything in the {\bf src/wx-console} directory. This
install Gnome, as wxWidgets can work with GTK+, Motif or even X11 libraries.
-\item [ \verb?--?enable-tray-monitor ]
- \index[dir]{\verb{--{enable-tray-monitor }
+\item [ \verb:--:enable-tray-monitor ]
+ \index[dir]{\verb:--:enable-tray-monitor }
If you have GTK installed on your computer, you run a graphical environment
or a window manager compatible with the FreeDesktop system tray standard
(like KDE and GNOME) and you want to use a GUI to monitor Bacula daemons, you
must specify this option. Doing so will build everything in the {\bf
src/tray-monitor} directory.
-\item [ \verb?--?enable-static-tools]
- \index[dir]{\verb{--{enable-static-tools }
+\item [ \verb:--:enable-static-tools]
+ \index[dir]{\verb:--:enable-static-tools }
This option causes the linker to link the Storage daemon utility tools ({\bf
bls}, {\bf bextract}, and {\bf bscan}) statically. This permits using them
without having the shared libraries loaded. If you have problems linking in
the {\bf src/stored} directory, make sure you have not enabled this option,
- or explicitly disable static linking by adding {\bf \verb{--{disable-static-tools}.
+ or explicitly disable static linking by adding {\bf \verb:--:disable-static-tools}.
-\item [ \verb?--?enable-static-fd]
- \index[fd]{\verb{--{enable-static-fd }
+\item [ \verb:--:enable-static-fd]
+ \index[fd]{\verb:--:enable-static-fd }
This option causes the make process to build a {\bf static-bacula-fd} in
addition to the standard File daemon. This static version will include
statically linked libraries and is required for the Bare Metal recovery. This
option is largely superseded by using {\bf make static-bacula-fd} from with
- in the {\bf src/filed} directory. Also, the {\bf \verb{--{enable-client-only} option
+ in the {\bf src/filed} directory. Also, the {\bf \verb:--:enable-client-only} option
described below is useful for just building a client so that all the other
parts of the program are not compiled.
-\item [ \verb?--?enable-static-sd]
- \index[sd]{\verb{--{enable-static-sd }
+\item [ \verb:--:enable-static-sd]
+ \index[sd]{\verb:--:enable-static-sd }
This option causes the make process to build a {\bf static-bacula-sd} in
addition to the standard Storage daemon. This static version will include
statically linked libraries and could be useful during a Bare Metal recovery.
-\item [ \verb?--?enable-static-dir]
- \index[dir]{\verb{--{enable-static-dir }
+\item [ \verb:--:enable-static-dir]
+ \index[dir]{\verb:--:enable-static-dir }
This option causes the make process to build a {\bf static-bacula-dir} in
addition to the standard Director. This static version will include
statically linked libraries and could be useful during a Bare Metal recovery.
-\item [ \verb?--?enable-static-cons]
- \index[dir]{\verb{--{enable-static-cons }
+\item [ \verb:--:enable-static-cons]
+ \index[dir]{\verb:--:enable-static-cons }
This option causes the make process to build a {\bf static-console} and a
{\bf static-gnome-console} in addition to the standard console. This static
version will include statically linked libraries and could be useful during a
Bare Metal recovery.
-\item [ \verb?--?enable-client-only]
- \index[console]{\verb{--{enable-client-only }
+\item [ \verb:--:enable-client-only]
+ \index[console]{\verb:--:enable-client-only }
This option causes the make process to build only the File daemon and the
libraries that it needs. None of the other daemons, storage tools, nor the
console will be built. Likewise a {\bf make install} will then only install
configuration without this option. This option greatly facilitates building a
Client on a client only machine.
-\item [ \verb?--?enable-largefile]
- \index[console]{\verb{--{enable-largefile }
+\item [ \verb:--:enable-largefile]
+ \index[console]{\verb:--:enable-largefile }
This option (default) causes Bacula to be built with 64 bit file address
support if it is available on your system. This permits Bacula to read and
write files greater than 2 GBytes in size. You may disable this feature and
- revert to 32 bit file addresses by using {\bf \verb{--{disable-largefile}.
+ revert to 32 bit file addresses by using {\bf \verb:--:disable-largefile}.
-\item [ \verb?--?with-sqlite=\lt{}sqlite-path\gt{}]
- \index[fd]{\verb{--{with-sqlite }
+\item [ \verb:--:with-sqlite=\lt{}sqlite-path\gt{}]
+ \index[fd]{\verb:--:with-sqlite }
This enables use of the SQLite database. The {\bf sqlite-path} is not
normally specified as Bacula looks for the necessary components in a
standard location ({\bf depkgs/sqlite}). See
\ilink{Installing and Configuring SQLite}{_ChapterStart33} chapter of
this manual for more details.
-\item [ \verb?--?with-mysql=\lt{}mysql-path\gt{}]
- \index[fd]{\verb{--{with-mysql }
+\item [ \verb:--:with-mysql=\lt{}mysql-path\gt{}]
+ \index[fd]{\verb:--:with-mysql }
This enables building of the Catalog services for Bacula. It assumes that
MySQL is running on your system, and expects it to be installed in the {\bf
mysql-path} that you specify. If this option is not present, the build will
\ilink{Installing and Configuring MySQL}{_ChapterStart} chapter
before proceeding with the configuration.
-\item [ \verb?--?with-postgresql=\lt{}path\gt{}]
- \index[fd]{\verb{--{with-postgresql }
+\item [ \verb:--:with-postgresql=\lt{}path\gt{}]
+ \index[fd]{\verb:--:with-postgresql }
This provides an explicit path to the PostgreSQL libraries if Bacula cannot
find it by default.
-\item [ \verb?--?with-python=\lt{}path\gt{}]
- \index[fd]{\verb{--{with-python }
+\item [ \verb:--:with-python=\lt{}path\gt{}]
+ \index[fd]{\verb:--:with-python }
This option enables Bacula support for Python. If no path is
supplied, configure will search the
standard library locations for Python 2.2, 2.3, or 2.4. If it cannot
\ilink{Python chapter}{_ChapterStart60} for the details of using
Python scripting.
-\item [ \verb?--?enable-conio]
- \index[fd]{\verb{--{enable-conio }
+\item [ \verb:--:enable-conio]
+ \index[fd]{\verb:--:enable-conio }
Tells Bacula to enable building the small, light weight readline replacement
routine. It is generally much easier to configure than readline, although,
like readline, it needs either the termcap or ncurses library.
-\item [ \verb?--?with-readline=\lt{}readline-path\gt{}]
- \index[fd]{\verb{--{with-readline }
+\item [ \verb:--:with-readline=\lt{}readline-path\gt{}]
+ \index[fd]{\verb:--:with-readline }
Tells Bacula where {\bf readline} is installed. Normally, Bacula will find
readline if it is in a standard library. If it is not found and no
- \verb{--{with-readline is specified, readline will be disabled. This option affects
+ \verb:--:with-readline is specified, readline will be disabled. This option affects
the Bacula build. Readline provides the Console program with a command line
history and editing capability and is no longer supported, so you are on your
own if you have problems.
-\item [ \verb?--?enable-readline]
- \index[fd]{\verb{--{enable-readline }
+\item [ \verb:--:enable-readline]
+ \index[fd]{\verb:--:enable-readline }
Tells Bacula to enable readline support. It is normally disabled due to the
large number of configuration problems and the fact that the package seems to
change in incompatible ways from version to version.
-\item [ \verb?--?with-tcp-wrappers=\lt{}path\gt{}]
- \index[fd]{\verb{--{with-tcp-wrappers }
+\item [ \verb:--:with-tcp-wrappers=\lt{}path\gt{}]
+ \index[fd]{\verb:--:with-tcp-wrappers }
This specifies that you want TCP wrappers (man hosts\_access(5)) compiled in.
The path is optional since Bacula will normally find the libraries in the
standard locations. This option affects the Bacula build. In specifying your
\ilink{Configuring and Testing TCP Wrappers}{wrappers} section
in the Security Chapter.
-\item [ \verb?--?with-working-dir=\lt{}working-directory-path\gt{} ]
- \index[dir]{\verb{--{with-working-dir }
+\item [ \verb:--:with-working-dir=\lt{}working-directory-path\gt{} ]
+ \index[dir]{\verb:--:with-working-dir }
This option is mandatory and specifies a directory into which Bacula may
safely place files that will remain between Bacula executions. For example,
if the internal database is used, Bacula will keep those files in this
The working directory is not automatically created by the install process, so
you must ensure that it exists before using Bacula for the first time.
-\item [ \verb?--?with-base-port=\lt{}port=number\gt{}]
- \index[dir]{\verb{--{with-base-port }
+\item [ \verb:--:with-base-port=\lt{}port=number\gt{}]
+ \index[dir]{\verb:--:with-base-port }
In order to run, Bacula needs three TCP/IP ports (one for the Bacula
Console, one for the Storage daemon, and one for the File daemon). The {\bf
- \verb{--{with-baseport} option will automatically assign three ports beginning at
+ \verb:--:with-baseport} option will automatically assign three ports beginning at
the base port address specified. You may also change the port number in the
resulting configuration files. However, you need to take care that the
numbers correspond correctly in each of the three daemon configuration
IANA. This option is only used to modify the daemon configuration files. You
may also accomplish the same thing by directly editing them later.
-\item [ \verb?--?with-dump-email=\lt{}email-address\gt{}]
- \index[dir]{\verb{--{with-dump-email }
+\item [ \verb:--:with-dump-email=\lt{}email-address\gt{}]
+ \index[dir]{\verb:--:with-dump-email }
This option specifies the email address where any core dumps should be set.
This option is normally only used by developers.
-\item [ \verb?--?with-pid-dir=\lt{}PATH\gt{} ]
- \index[dir]{\verb{--{with-pid-dir }
+\item [ \verb:--:with-pid-dir=\lt{}PATH\gt{} ]
+ \index[dir]{\verb:--:with-pid-dir }
This specifies where Bacula should place the process id file during
execution. The default is: {\bf /var/run}. This directory is not created by
the install process, so you must ensure that it exists before using Bacula
the first time.
-\item [ \verb?--?with-subsys-dir=\lt{}PATH\gt{}]
- \index[dir]{\verb{--{with-subsys-dir }
+\item [ \verb:--:with-subsys-dir=\lt{}PATH\gt{}]
+ \index[dir]{\verb:--:with-subsys-dir }
This specifies where Bacula should place the subsystem lock file during
execution. The default is {\bf /var/run/subsys}. Please make sure that you do
not specify the same directory for this directory and for the {\bf sbindir}
subsys directory is not created by the Bacula install, so you must be sure to
create it before using Bacula.
-\item [ \verb?--?with-dir-password=\lt{}Password\gt{}]
- \index[dir]{\verb{--{with-dir-password }
+\item [ \verb:--:with-dir-password=\lt{}Password\gt{}]
+ \index[dir]{\verb:--:with-dir-password }
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.
-\item [ \verb?--?with-fd-password=\lt{}Password\gt{} ]
- \index[fd]{\verb{--{with-fd-password }
+\item [ \verb:--:with-fd-password=\lt{}Password\gt{} ]
+ \index[fd]{\verb:--:with-fd-password }
This option allows you to specify the password used to access the File daemon
(normally called from the Director). If it is not specified, configure will
automatically create a random password.
-\item [ \verb?--?with-sd-password=\lt{}Password\gt{} ]
- \index[sd]{\verb{--{with-sd-password }
+\item [ \verb:--:with-sd-password=\lt{}Password\gt{} ]
+ \index[sd]{\verb:--:with-sd-password }
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.
-\item [ \verb?--?with-dir-user=\lt{}User\gt{} ]
- \index[dir]{\verb{--{with-dir-user }
+\item [ \verb:--:with-dir-user=\lt{}User\gt{} ]
+ \index[dir]{\verb:--:with-dir-user }
This option allows you to specify the Userid used to run the Director. The
Director must be started as root, but doesn't need to run as root, and after
doing preliminary initializations, it can ``drop'' to the UserId specified on
this option.
-\item [ \verb?--?with-dir-group=\lt{}Group\gt{} ]
- \index[dir]{\verb{--{with-dir-group }
+\item [ \verb:--:with-dir-group=\lt{}Group\gt{} ]
+ \index[dir]{\verb:--:with-dir-group }
This option allows you to specify the GroupId used to run the Director. The
Director must be started as root, but doesn't need to run as root, and after
doing preliminary initializations, it can ``drop'' to the GroupId specified
on this option.
-\item [ \verb?--?with-sd-user=\lt{}User\gt{} ]
- \index[sd]{\verb{--{with-sd-user }
+\item [ \verb:--:with-sd-user=\lt{}User\gt{} ]
+ \index[sd]{\verb:--:with-sd-user }
This option allows you to specify the Userid used to run the Storage daemon.
The Storage daemon must be started as root, but doesn't need to run as root,
and after doing preliminary initializations, it can ``drop'' to the UserId
that the Storage daemon has access to all the devices (tape drives, ...) that
it needs.
-\item [ \verb?--?with-sd-group=\lt{}Group\gt{} ]
- \index[sd]{\verb{--{with-sd-group }
+\item [ \verb:--:with-sd-group=\lt{}Group\gt{} ]
+ \index[sd]{\verb:--:with-sd-group }
This option allows you to specify the GroupId used to run the Storage daemon.
The Storage daemon must be started as root, but doesn't need to run as root,
and after doing preliminary initializations, it can ``drop'' to the GroupId
specified on this option.
-\item [ \verb?--?with-fd-user=\lt{}User\gt{} ]
- \index[fd]{\verb{--{with-fd-user }
+\item [ \verb:--:with-fd-user=\lt{}User\gt{} ]
+ \index[fd]{\verb:--:with-fd-user }
This option allows you to specify the Userid used to run the File daemon. The
File daemon must be started as root, and in most cases, it needs to run as
root, so this option is used only in very special cases, after doing
preliminary initializations, it can ``drop'' to the UserId specified on this
option.
-\item [ \verb?--?with-fd-group=\lt{}Group\gt{} ]
- \index[fd]{\verb{--{with-fd-group }
+\item [ \verb:--:with-fd-group=\lt{}Group\gt{} ]
+ \index[fd]{\verb:--:with-fd-group }
This option allows you to specify the GroupId used to run the File daemon.
The File daemon must be started as root, and in most cases, it must be run as
root, however, after doing preliminary initializations, it can ``drop'' to
\end{description}
-Note, many other options are presented when you do a {\bf ./configure \verb{--{help},
+Note, many other options are presented when you do a {\bf ./configure \verb:--:help},
but they are not implemented.
\subsection*{Recommended Options for most Systems}
If you want to install Bacula in an installation directory rather than run it
out of the build directory (as developers will do most of the time), you
-should also include the \verb{--{sbindir and \verb{--{sysconfdir options with appropriate
+should also include the \verb:--:sbindir and \verb:--:sysconfdir options with appropriate
paths. Neither are necessary if you do not use ``make install'' as is the case
for most development work. The install process will create the sbindir and
sysconfdir if they do not exist, but it will not automatically create the
because they have been officially assigned to Bacula by IANA (Internet
Assigned Numbers Authority). We strongly recommend that you use only these
ports to prevent any conflicts with other programs. This is in fact the
-default if you do not specify a {\bf \verb{--{with-baseport} option.
+default if you do not specify a {\bf \verb:--:with-baseport} option.
You may also want to put the following entries in your {\bf /etc/services}
file as it will make viewing the connections made by Bacula easier to
./configure}.
Since the File daemon does not access the Catalog database, you can remove the
-{\bf \verb{--{with-mysql} or {\bf \verb{--{with-sqlite} options, then add {\bf
-\verb{--{enable-client-only}. This will compile only the necessary libraries and the
+{\bf \verb:--:with-mysql} or {\bf \verb:--:with-sqlite} options, then add {\bf
+\verb:--:enable-client-only}. This will compile only the necessary libraries and the
client programs and thus avoids the necessity of installing one or another of
those database programs to build the File daemon. With the above option, you
simply enter {\bf make} and just the client will be built.
\addcontentsline{toc}{subsection}{Installing Tray Monitor}
The Tray Monitor is already installed if you used the {\bf
-\verb{--{enable-tray-monitor} configure option and ran {\bf make install}.
+\verb:--:enable-tray-monitor} configure option and ran {\bf make install}.
As you don't run your graphical environment as root (if you do, you should
change that bad habit), don't forget to allow your user to read {\bf
The licenses for most software are designed to take away your freedom to share
and change it. By contrast, the GNU General Public Licenses are intended to
-guarantee your freedom to share and change free software\verb{--{to make sure the
+guarantee your freedom to share and change free software\verb:--:to make sure the
software is free for all its users.
This license, the Lesser General Public License, applies to some specially
-designated software packages\verb{--{typically libraries\verb{--{of the Free Software
+designated software packages\verb:--:typically libraries\verb:--:of the Free Software
Foundation and other authors who decide to use it. You can use it too, but we
suggest you first think carefully about whether this license or the ordinary
General Public License is the better strategy to use in any particular case,
%%
\section*{Monitor Configuration}
-\label{_ChapterStart35}
+\label{_MonitorChapter}
\index[general]{Monitor Configuration }
\index[general]{Configuration!Monitor }
\addcontentsline{toc}{section}{Monitor Configuration}
\index[fd]{DIRPort }
Specify the port to use to connect to the Director. This value will most
likely already be set to the value you specified on the {\bf
-\verb{--{with-base-port} option of the {\bf ./configure} command. This port must be
+\verb:--:with-base-port} option of the {\bf ./configure} command. This port must be
identical to the {\bf DIRport} specified in the {\bf Director} resource of
the
\ilink{Director's configuration}{_ChapterStart40} file. The
\index[general]{Phase I!Installing and Configuring MySQL -- }
\addcontentsline{toc}{subsection}{Installing and Configuring MySQL -- Phase I}
-If you use the ./configure \verb{--{with-mysql=mysql-directory statement for
+If you use the ./configure \verb:--:with-mysql=mysql-directory statement for
configuring {\bf Bacula}, you will need MySQL version 3.23.53 or later
installed in the {\bf mysql-directory}.
Bacula has been tested on MySQL version 4.1.12 and works providing
as ANSI/ISO compatibility, you may experience problems.
If MySQL is installed in the standard system location, you need only enter
-{\bf \verb{--{with-mysql} since the configure program will search all the
+{\bf \verb:--:with-mysql} since the configure program will search all the
standard locations. If you install MySQL in your home directory or some
other non-standard directory, you will need to provide the full path to it.
Beginning with Bacula version 1.31, the thread safe version of the
MySQL client library is used, and hence you must add the {\bf
-\verb{--{enable-thread-safe-client} option to the {\bf ./configure} as shown below:
+\verb:--:enable-thread-safe-client} option to the {\bf ./configure} as shown below:
\begin{enumerate}
\item Download MySQL source code from
where you replace {\bf mysql-source-directory} with the directory name where
you put the MySQL source code.
-\item ./configure \verb{--{enable-thread-safe-client \verb{--{prefix=mysql-directory
+\item ./configure \verb:--:enable-thread-safe-client \verb:--:prefix=mysql-directory
where you replace {\bf mysql-directory} with the directory name where you
want to install mysql. Normally for system wide use this is /usr/local/mysql.
Bacula}. If not, please complete these items before proceeding.
Please note that the {\bf ./configure} used to build {\bf Bacula} will need to
-include {\bf \verb{--{with-mysql=mysql-directory}, where {\bf mysql-directory} is the
+include {\bf \verb:--:with-mysql=mysql-directory}, where {\bf mysql-directory} is the
directory name that you specified on the ./configure command for configuring
MySQL. This is needed so that Bacula can find the necessary include headers
and library files for interfacing to MySQL.
This script creates the MySQL {\bf bacula} database. The databases you create
as well as the access databases will be located in \lt{}install-dir\gt{}/var/
in a subdirectory with the name of the database, where \lt{}install-dir\gt{}
-is the directory name that you specified on the {\bf \verb{--{prefix} option. This
+is the directory name that you specified on the {\bf \verb:--:prefix} option. This
can be important to know if you want to make a special backup of the Bacula
database or to check its size.
After configuring Bacula with
-./configure \verb{--{enable-thread-safe-client \verb{--{prefix=\lt{}mysql-directory\gt{}
+./configure \verb:--:enable-thread-safe-client \verb:--:prefix=\lt{}mysql-directory\gt{}
where \lt{}mysql-directory\gt{} is in my case {\bf /home/kern/mysql}, you may
have to configure the loader so that it can find the MySQL shared libraries.
If you have previously followed this procedure and later add the {\bf
-\verb{--{enable-thread-safe-client} options, you will need to rerun the {\bf
+\verb:--:enable-thread-safe-client} options, you will need to rerun the {\bf
ldconfig} program shown below. If you put MySQL in a standard place such as
{\bf /usr/lib} or {\bf /usr/local/lib} this will not be necessary, but in my
case it is. The description that follows is Linux specific. For other
install from rpms and you upgrade MySQL, you must also rebuild Bacula.
You can do so by rebuilding from the source rpm. To do so, you may need
eo modify the bacula.spec file to account for the new MySQL version.
-
\addcontentsline{toc}{subsection}{Installing and Configuring PostgreSQL --
Phase I}
-If you use the {\bf ./configure \verb{--{with-postgresql=PostgreSQL-Directory}
+If you use the {\bf ./configure \verb:--:with-postgresql=PostgreSQL-Directory}
statement for configuring {\bf Bacula}, you will need PostgreSQL version 7.3
or later installed. NOTE! PostgreSQL versions earlier than 7.3 do not work
with Bacula. If PostgreSQL is installed in the standard system location, you
-need only enter {\bf \verb{--{with-postgresql} since the configure program will
+need only enter {\bf \verb:--:with-postgresql} since the configure program will
search all the standard locations. If you install PostgreSQL in your home
directory or some other non-standard directory, you will need to provide the
-full path with the {\bf \verb{--{with-postgresql} option.
+full path with the {\bf \verb:--:with-postgresql} option.
Installing and configuring PostgreSQL is not difficult but can be confusing
the first time. If you prefer, you may want to use a package provided by your
Bacula}. If not, please complete these items before proceeding.
Please note that the {\bf ./configure} used to build {\bf Bacula} will need to
-include {\bf \verb{--{with-postgresql=PostgreSQL-directory}, where {\bf
+include {\bf \verb:--:with-postgresql=PostgreSQL-directory}, where {\bf
PostgreSQL-directory} is the directory name that you specified on the
./configure command for configuring PostgreSQL (if you didn't specify a
directory or PostgreSQL is installed in a default location, you do not need to
that the records on the Volume are no longer in the catalog.
With some care, it can also be used to synchronize your existing catalog with
-a Volume. Since {\bf bscan} modifies your catalog, we strongly recommend that
+a Volume. Although we have never seen a case of bscan damaging a
+catalog, since bscan modifies your catalog, we recommend that
you do a simple ASCII backup of your database before running {\bf bscan} just
to be sure. See
\ilink{Compacting Your Database}{CompactingMySQL}.
database name ({\bf -b} option), the user name ({\bf -u} option), and/or the
password ({\bf -p}) options.
-As an example, let's suppose that you did a backup to Volume ``Vol001'' and
-that sometime later all records of that Volume were pruned or purged from the
-database. By using {\bf bscan} you can recreate the catalog entries for that
-Volume and then use the {\bf restore} command in the Console to restore
+As an example, let's suppose that you did a backup to Volumes ``Vol001''
+and ``Vol002'', then sometime later all records of one or both those
+Volumes
+were pruned or purged from the
+database. By using {\bf bscan} you can recreate the catalog entries for
+those Volumes and then use the {\bf restore} command in the Console to restore
whatever you want. A command something like:
\footnotesize
\begin{verbatim}
-bscan -c bacula-sd.conf -v -V Vol001 /dev/nst0
+bscan -c bacula-sd.conf -v -V Vol001\|Vol002 /dev/nst0
\end{verbatim}
\normalsize
command must read the entire tape, so if it has a lot of data, it may take a
long time, and thus you might want to immediately use the command listed
below. Note, if you are writing to a disk file, replace the device name with
-the path to the directory that contains the Volume. This must correspond to
+the path to the directory that contains the Volumes. This must correspond to
the Archive Device in the conf file.
Then to actually write or store the records in the catalog, add the {\bf -s}
\footnotesize
\begin{verbatim}
- bscan -s -m -c bacula-sd.conf -v -V Vol001 /dev/nst0
+ bscan -s -m -c bacula-sd.conf -v -V Vol001\|Vol002 /dev/nst0
\end{verbatim}
\normalsize
When writing to the database, if bscan finds existing records, it will
generally either update them if something is wrong or leave them alone. Thus
-if the Volume you are scanning is all or partially in the catalog already, no
+if the Volumes you are scanning are all or partially in the catalog already, no
harm will be done to that existing data. Any missing data will simply be
added.
-If you have multiple tapes, you can scan them with:
+If you have multiple tapes, you should scan them with:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-You should, where ever possible try to specify the tapes in the order they are
-written. However, bscan can handle scanning tapes that are not sequential. Any
-incomplete records at the end of the tape will simply be ignored in that case.
+You should, always try to specify the tapes in the order they are written.
+However, bscan can handle scanning tapes that are not sequential. Any
+incomplete records at the end of the tape will simply be ignored in that
+case. If you are simply reparing an existing catalog, this may be OK, but
+if you are creating a new catalog from scratch, it will leave your database
+in an incorrect state. If you do not specify all necessary Volumes on a
+single bscan command, bscan will not be able to correctly restore the
+records that span two volumes. In other words, it is much better to
+specify two or three volumes on a single bscan command rather than run
+bscan two or three times, each with a single volume.
Note, the restoration process using bscan is not identical to the original
the filename and the path to be separated using the same algorithm that is
used when putting filenames into the Catalog database.
-\subsection*{bimagemgr}
-\label{bimagemgr}
-\index[general]{Bimagemgr }
-\addcontentsline{toc}{subsection}{bimagemgr}
-
-{\bf bimagemgr} is a utility for those who backup to disk volumes in order to
-commit them to CDR disk, rather than tapes. It is a web based interface
-written in perl, used to monitor when a volume file needs to be burned to
-disk. It requires:
-
-\begin{itemize}
-\item A web server running on the bacula server
-\item A CD recorder installed and configured on the bacula server
-\item The cdrtools package installed on the bacula server.
-\item perl, perl-DBI module, and either DBD-MySQL or DBD-PostgreSQL modules
- \end{itemize}
-
-SQLite databases and DVD burning are not supported by {\bf bimagemgr} at this
-time, but both are planned for future releases.
-
-\subsubsection*{bimagemgr installation}
-\index[general]{bimagemgr!Installation }
-\index[general]{bimagemgr Installation }
-\addcontentsline{toc}{subsubsection}{bimagemgr Installation}
-
-Please see the README file in the bimagemgr directory of the distribution for
-instructions.
-
-\subsubsection*{bimagemgr usage}
-\index[general]{bimagemgr!Usage }
-\index[general]{bimagemgr Usage }
-\addcontentsline{toc}{subsubsection}{bimagemgr Usage}
-
-Calling the program in your web browser, e.g. {\tt
-http://localhost/cgi-bin/bimagemgr.pl} will produce a display as shown below
-in Figure 1. The program will query the bacula database and display all volume
-files with the date last written and the date last burned to disk. If a volume
-needs to be burned (last written is newer than last burn date) a ``Burn''
-button will be displayed in the rightmost column.
-
-\addcontentsline{lof}{figure}{Bacula CD Image Manager}
-\includegraphics{./bimagemgr1.eps} \\Figure 1
-
-Place a blank CDR disk in your recorder and click the ``Burn'' button. This will
-cause a pop up window as shown in Figure 2 to display the burn progress.
-
-\addcontentsline{lof}{figure}{Bacula CD Image Burn Progress Window}
-\includegraphics{./bimagemgr2.eps} \\Figure 2
-
-When the burn finishes the pop up window will display the results of cdrecord
-as shown in Figure 3. Close the pop up window and refresh the main window. The
-last burn date will be updated and the ``Burn'' button for that volume will
-disappear. Should you have a failed burn you can reset the last burn date of
-that volume by clicking its ``Reset'' link.
-
-\addcontentsline{lof}{figure}{Bacula CD Image Burn Results}
-\includegraphics{./bimagemgr3.eps} \\Figure 3
-
-In the bottom row of the main display window are two more buttons labeled
-``Burn Catalog'' and ``Blank CDRW''. ``Burn Catalog'' will place a copy of
-your bacula catalog on a disk. If you use CDRW disks rather than CDR then
-``Blank CDRW'' allows you to erase the disk before re-burning it. Regularly
-committing your backup volume files and your catalog to disk with {\bf
-bimagemgr} ensures that you can rebuild easily in the event of some disaster
-on the bacula server itself.
\addcontentsline{toc}{subsection}{Python Configuration}
Python must be enabled during the configuration process by adding
-a \verb?--?with-python, and possibly specifying an alternate
+a \verb:--:with-python, and possibly specifying an alternate
directory if your Python is not installed in a standard system
location. If you are using RPMs you will need the python-devel package
installed.
language, it is very efficient.
When the Director starts, it looks to see if you have a {\bf
-Scripts Directory} defined, if so, it looks in that directory for
-a file named {\bf DirStartUp}. If it is found, Bacula will pass this
-file to Python for execution.
+Scripts Directory} Directive defined, if so, it looks in that directory for
+a file named {\bf DirStartUp.py}. If it is found, Bacula will pass this
+file to Python for execution. The {\bf Scripts Directory} is a new
+directive that you add to the Director resource of your bacula-dir.conf
+file.
\subsection*{Bacula Events}
\index[general]{Bacula Events}
\item [The Bacula Object]
The Bacula object is created by the Bacula daemon (the Director
in the present case) when the daemon starts. It is available to
- the Python startup script, {\bf DirStartup}, by importing the
+ the Python startup script, {\bf DirStartup.py}, by importing the
Bacula definitions with {\bf import bacula}. The methods
available with this object are described below.
directory by the {\bf job} object.
\begin{description}
\item [set_events] The set_events takes a single
-argument, which is the instantation of the Job Events class
-that contains the methods that you want called. The method
-names that will be called must correspond to the Bacula
-defined events. You may define additional methods but Bacula
-will not use them.
+ argument, which is the instantation of the Job Events class
+ that contains the methods that you want called. The method
+ names that will be called must correspond to the Bacula
+ defined events. You may define additional methods but Bacula
+ will not use them.
\item [run] The run method takes a single string
-argument, which is the run command (same as in the Console)
-that you want to submit to start a new Job. The value
-returned by the run method is the JobId of the job that
-started, or -1 if there was an error.
+ argument, which is the run command (same as in the Console)
+ that you want to submit to start a new Job. The value
+ returned by the run method is the JobId of the job that
+ started, or -1 if there was an error.
\item [write] The write method is used to be able to send
-print output to the Job Report. This will be described later.
+ print output to the Job Report. This will be described later.
+\item [DoesVolumeExist] The DoesVolumeExist takes a single
+ string argument, which is the Volume name, and returns
+ 1 if the volume exists in the Catalog and 0 if the volume
+ does not exist.
\end{description}
The following attributes are read/write within the Director
\item [WorkingDir]
\item [Version] tuple consisting of (Version, Build-date)
\item [CatalogRes] tuple consisting of (DBName, Address, User,
- Password, Socket, Port) taken from the Catalog resource for
- the Job.
+ Password, Socket, Port, Database Vendor) taken from the Catalog resource
+ for the Job with the exception of Database Vendor, which is
+ one of the following: MySQL, PostgreSQL, SQLite, Internal,
+ depending on what database you configured.
\end{description}
The following write-only attributes are available within the
NewVolume event.
\end{description}
+\subsection*{Python Console Command}
+\index[general]{Python Console Command}
+\index[general]{Console Command!Python}
+\addcontentsline{toc}{subsection}{Python Console Command}
+
+There is a new Console command named {\bf python}. It takes
+a single argument {\bf restart}. Example:
+\begin{verbatim}
+ python restart
+\end{verbatim}
+
+This command restarts the Python interpreter in the Director.
+This can be useful when you are modifying the DirStartUp script,
+because normally Python will cache it, and thus the
+script will be read one time.
+
+
+\subsection*{Python Example}
+\index[general]{Python Example}
+\index[general]{Example!Python}
+\addcontentsline{toc}{subsection}{Python Example}
An example script for the Director startup file is provided in
{\bf examples/python/DirStartup.py} as follows:
daemon, the Storage daemon, and the Console programs. If you have followed our
recommendations, default configuration files as well as the daemon binaries
will be located in your installation directory. In any case, the binaries are
-found in the directory you specified on the {\bf \verb{--{sbindir} option to the {\bf
+found in the directory you specified on the {\bf \verb:--:sbindir} option to the {\bf
./configure} command, and the configuration files are found in the directory
-you specified on the {\bf \verb{--{sysconfdir} option.
+you specified on the {\bf \verb:--:sysconfdir} option.
When initially setting up Bacula you will need to invest a bit of time in
modifying the default configuration files to suit your environment. This may
and to manually start/stop Jobs or to obtain Job status information.
The Console configuration file is found in the directory specified on the {\bf
-\verb{--{sysconfdir} option that you specified on the {\bf ./configure} command and
+\verb:--:sysconfdir} option that you specified on the {\bf ./configure} command and
by default is named {\bf console.conf}.
-If you choose to build the GNOME console with the {\bf \verb{--{enable-gnome} option,
+If you choose to build the GNOME console with the {\bf \verb:--:enable-gnome} option,
you also find a default configuration file for it, named {\bf
gnome-console.conf}.
The same applies to the wxWidgets console, which is build with the {\bf
-\verb{--{enable-wx-console} option, and the name of the default configuration file
+\verb:--:enable-wx-console} option, and the name of the default configuration file
is, in this case, {\bf wx-console.conf}.
Normally, for first time users, no change is needed to these files. Reasonable
defaults are set.
\subsubsection*{
-\ilink{Configuring the Monitor Program}{_ChapterStart35}}
+\ilink{Configuring the Monitor Program}{_MonitorChapter}}
\index[general]{Program!Configuring the Monitor }
\index[general]{Configuring the Monitor Program }
\addcontentsline{toc}{subsubsection}{Configuring the Monitor Program}
daemon (MainSD) that is currently selected.
The Monitor configuration file is found in the directory specified on the {\bf
-\verb{--{sysconfdir} option that you specified on the {\bf ./configure} command and
+\verb:--:sysconfdir} option that you specified on the {\bf ./configure} command and
by default is named {\bf tray-monitor.conf}. Normally, for first time users,
you just need to change the permission of this file to allow non-root users to
run the Monitor, as this application must run as the same user as the
data) to the Storage daemon.
The File daemon configuration file is found in the directory specified on the
-{\bf \verb{--{sysconfdir} option that you specified on the {\bf ./configure} command.
+{\bf \verb:--:sysconfdir} option that you specified on the {\bf ./configure} command.
By default, the File daemon's configuration file is named {\bf
bacula-fd.conf}. Normally, for first time users, no change is needed to this
file. Reasonable defaults are set. However, if you are going to back up more
schedules and monitors all jobs to be backed up.
The Director configuration file is found in the directory specified on the
-{\bf \verb{--{sysconfdir} option that you specified on the {\bf ./configure} command.
+{\bf \verb:--:sysconfdir} option that you specified on the {\bf ./configure} command.
Normally the Director's configuration file is named {\bf bacula-dir.conf}.
In general, the only change you must make is modify the FileSet resource so
restore request, to find the data and send it to the File daemon.
The Storage daemon's configuration file is found in the directory specified on
-the {\bf \verb{--{sysconfdir} option that you specified on the {\bf ./configure}
+the {\bf \verb:--:sysconfdir} option that you specified on the {\bf ./configure}
command. By default, the Storage daemon's file is named {\bf bacula-sd.conf}.
Edit this file to contain the correct Archive device names for any tape
devices that you have. If the configuration process properly detected your
Bacula}
TCP Wrappers are implemented if you turn them on when configuring ({\bf
-./configure \verb{--{with-libwrap}). With this code enabled, you may control who may
+./configure \verb:--:with-libwrap}). With this code enabled, you may control who may
access your daemons. This control is done by modifying the file: {\bf
/etc/hosts.allow}. The program name that {\bf Bacula} uses when applying these
access restrictions is the name you specify in the daemon configuration file.
\addcontentsline{toc}{subsection}{Installing and Configuring SQLite -- Phase
I}
-If you use the {\bf ./configure \verb{--{with-sqlite} statement for configuring {\bf
+If you use the {\bf ./configure \verb:--:with-sqlite} statement for configuring {\bf
Bacula}, you will need SQLite version 2.8.16 or later installed. Our standard
location (for the moment) for SQLite is in the dependency package {\bf
depkgs/sqlite-2.8.16}. Please note that the version will be updated as new
Bacula}.
Please note that the {\bf ./configure} used to build {\bf Bacula} will need to
-include {\bf \verb{--{with-sqlite}.
+include {\bf \verb:--:with-sqlite}.
\subsection*{Installing and Configuring SQLite -- Phase II}
\label{phase2}
You should protect your Catalog database. If you are using SQLite, make sure
that the working directory is readable only by root (or your Bacula userid),
-and ensure that {\bf bacula.db} has permissions {\bf -rw-r\verb{--{r\verb{--{} (i.e. 640) or
+and ensure that {\bf bacula.db} has permissions {\bf -rw-r\verb:--:r\verb:--:} (i.e. 640) or
more strict. If you are using MySQL or PostgreSQL, please note that the Bacula
setup procedure leaves the database open to anyone. At a minimum, you should
assign the user {\bf bacula} a userid and add it to your Director's
running this in production, you will probably want to find some way to
automatically start MySQL or PostgreSQL after each system reboot.
-If you are using SQLite (i.e. you specified the {\bf \verb{--{with-sqlite=xxx} option
+If you are using SQLite (i.e. you specified the {\bf \verb:--:with-sqlite=xxx} option
on the {\bf ./configure} command, you need do nothing. SQLite is automatically
started by {\bf Bacula}.
Note, on 1.32 versions and lower, the command name is {\bf console} rather
than bconsole. Alternatively to running the command line console, if you have
-GNOME installed and used the {\bf \verb{--{enable-gnome} on the configure command,
+GNOME installed and used the {\bf \verb:--:enable-gnome} on the configure command,
you may use the GNOME Console program:
./gnome-console
\normalsize
Details of the console program's commands are explained in the
-\ilink{Console Chapter}{_ChapterStart23} of this manual.
+\ilink{Console Chapter}{_ConsoleChapter} of this manual.
\subsection*{Running a Job}
\label{Running}
At this point, we assume you have done the following:
\begin{itemize}
-\item Configured Bacula with {\bf ./configure \verb{--{your-options}
+\item Configured Bacula with {\bf ./configure \verb:--:your-options}
\item Built Bacula using {\bf make}
\item Installed Bacula using {\bf make install}
\item Have created your database with, for example, {\bf
It is also possible to add media to the pool without physically labeling the
Volumes. This can be done with the {\bf add} command. For more information,
please see the
-\ilink{Console Chapter}{_ChapterStart23} of this manual.
+\ilink{Console Chapter}{_ConsoleChapter} of this manual.
Bacula} to run on Windows and the standard Bacula options, all Windows
specific options are signaled with a forward slash character (/), while as
usual, the standard Bacula options are signaled with a minus (-), or a minus
-minus (\verb{--{). All the standard Bacula options can be used on the Windows
+minus (\verb:--:). All the standard Bacula options can be used on the Windows
version. In addition, the following Windows only options are implemented:
\begin{description}
projects / bacula / docs / commitdiff