%%
+
%%
-\chapter{New Features}
+\chapter{New Features in 3.0.2}
+
+This chapter presents the new features added to the development 3.0.2
+versions to be released as Bacula version 3.0.2 sometime in 2009.
+
+\section{Source Address}
+\index[general]{Source Address}
+
+A feature has been added which allows the administrator to specify the address
+from which the director and file daemons will attempt connections from. This
+may be used to simplify system configuration overhead when working in complex
+networks utilizing multi-homing and policy-routing.
+
+To accomplish this, two new configuration directives have been implemented:
+\begin{verbatim}
+FileDaemon {
+ FDSourceAddress=10.0.1.20 # Always initiate connections from this address
+}
+
+Director {
+ DirSourceAddress=10.0.1.10 # Always initiate connections from this address
+}
+\end{verbatim}
+
+Simply adding specific host routes would have an undesirable side-effect: any
+application trying to contact the destination host would be forced to use the
+more specific route, possibly diverting management traffic onto a backup VLAN.
+Instead of adding host routes for each client connected to a multi-homed backup
+server (for example where there are management and backup VLANs), one can
+use the new directives to specify a specific source address at the application
+level.
+
+Additionally, this allows the simplification and abstraction of firewall rules
+when dealing with a Hot-Standby director or storage daemon configuration. The
+Hot-standby pair may share a CARP address, which connections must be sourced
+from, while system services listen and act from the unique interface addresses.
+
+This project was funded by Collaborative Fusion, Inc.
+
+\chapter{New Features in 3.0.0}
\label{NewFeaturesChapter}
\index[general]{New Features}
backed up, and the File daemon will use that list to determine if any new files
have been added or or moved and if any files have been deleted. This allows
Bacula to make an accurate backup of your system to that point in time so that
-if you do a restore, it will restore your system exactly. One note of caution
+if you do a restore, it will restore your system exactly.
+
+One note of caution
about using Accurate backup is that it requires more resources (CPU and memory)
on both the Director and the Client machines to create the list of previous
files backed up, to send that list to the File daemon, for the File daemon to
keep the list (possibly very big) in memory, and for the File daemon to do
-comparisons between every file in the FileSet and the list.
+comparisons between every file in the FileSet and the list. In particular,
+if your client has lots of files (more than a few million), you will need
+lots of memory on the client machine.
Accurate must not be enabled when backing up with a plugin that is not
specially designed to work with Accurate. If you enable it, your restores
will probably not work correctly.
+
+This project was funded by Bacula Systems.
\end{verbatim}
\section{ACL Updates}
+\index[general]{ACL Updates}
The whole ACL code had been overhauled and in this version each platforms has
different streams for each type of acl available on such an platform. As ACLs
between platforms tend to be not that portable (most implement POSIX acls but
recognize them will give you a warning.
\section{Extended Attributes}
+\index[general]{Extended Attributes}
Something that was on the project list for some time is now implemented for
platforms that support a similar kind of interface. Its the support for backup
and restore of so called extended attributes. As extended attributes are so
platform specific these attributes are saved in seperate streams for each
-platform. Restores can only be performed on the same platform the backup was
-done. There is support for all types of extended attributes, but restoring from
-one type of filesystem onto an other type of filesystem on the same platform
-may lead to supprises. As extended attributes can contain any type of data they
-are stored as a series of so called value-pairs. This data must be seen as
-mostly binary and is stored as such. As security labels from selinux are also
-extended attributes this option also stores those labels and no specific code
-is enabled for handling selinux security labels.
+platform. Restores of the extended attributes can only be performed on the
+same platform the backup was done. There is support for all types of extended
+attributes, but restoring from one type of filesystem onto an other type of
+filesystem on the same platform may lead to supprises. As extended attributes
+can contain any type of data they are stored as a series of so called
+value-pairs. This data must be seen as mostly binary and is stored as such.
+As security labels from selinux are also extended attributes this option also
+stores those labels and no specific code is enabled for handling selinux
+security labels.
Currently the following platforms support extended attributes:
\begin{itemize}
\end{verbatim}
\section{Shared objects}
+\index[general]{Shared objects}
A default build of Bacula will now create the libraries as shared objects
(.so) rather than static libraries as was previously the case.
The shared libraries are built using {\bf libtool} so it should be quite
the libraries if desired (not normally the case).
If you have problems with libtool or you wish to use the old
-way of building static libraries, you can do so by disabling
+way of building static libraries, or you want to build a static
+version of Bacula you may disable
libtool on the configure command line with:
\begin{verbatim}
\end{verbatim}
+\section{Building Static versions of Bacula}
+\index[general]{Static linking}
+In order to build static versions of Bacula, in addition
+to configuration options that were needed you now must
+also add --disable-libtool. Example
+
+\begin{verbatim}
+ ./configure --enable-static-client-only --disable-libtool
+\end{verbatim}
+
+
\section{Virtual Backup (Vbackup)}
\index[general]{Virtual Backup}
\index[general]{Vbackup}
Bacula's virtual backup feature is often called Synthetic Backup or
-Consolidation in other backup products. It permits you to consolidate
-the previous Full backup plus the most recent Differential backup and any
-subsequent Incremental backups into a new Full backup. This is accomplished
-without contacting the client by reading the previous backup data and
-writing it to a volume in a different pool.
+Consolidation in other backup products. It permits you to consolidate the
+previous Full backup plus the most recent Differential backup and any
+subsequent Incremental backups into a new Full backup. This new Full
+backup will then be considered as the most recent Full for any future
+Incremental or Differential backups. The VirtualFull backup is
+accomplished without contacting the client by reading the previous backup
+data and writing it to a volume in a different pool.
In some respects the Vbackup feature works similar to a Migration job, in
that Bacula normally reads the data from the pool specified in the
move the Virtual Full Volume back to your normal backup pool.
Alternatively, you can set your {\bf Next Pool} to point to the current
pool. This will cause Bacula to read and write to Volumes in the
-current pool. In general, this will work, but doing the Virtual Full
-requires reading more than one Volume, this procedure may cause a
-deadlock where Bacula is writing on a Volume that is later needed
-for reading.
+current pool. In general, this will work, because Bacula will
+not allow reading and writing on the same Volume. In any case, once
+a VirtualFull has been created, and a restore is done involving the
+most current Full, it will read the Volume or Volumes by the VirtualFull
+regardless of in which Pool the Volume is found.
The Vbackup is enabled on a Job by Job in the Job resource by specifying
a level of {\bf VirtualFull}.
\section{Catalog Format}
-Bacula 3.0 comes with some changes on the catalog format. The upgrade
-operation will convert an essential field of the File table that permits to
-handle more than 4 billion objects over the time, and this operation will
-take TIME and will likely DOUBLE THE SIZE of your catalog during the
-conversion. Depending on your catalog backend, you won't be able to run
-jobs during this period. For example, a 3 million files catalog will take
-2 minutes to upgrade on a normal machine. Please don't forget to make a
-valid backup of your database before executing the upgrade script.
+\index[general]{Catalog Format}
+Bacula 3.0 comes with some changes to the catalog format. The upgrade
+operation will convert the FileId field of the File table from 32 bits (max 4
+billion table entries) to 64 bits (very large number of items). The
+conversion process can take a bit of time and will likely DOUBLE THE SIZE of
+your catalog during the conversion. Also you won't be able to run jobs during
+this conversion period. For example, a 3 million file catalog will take 2
+minutes to upgrade on a normal machine. Please don't forget to make a valid
+backup of your database before executing the upgrade script. See the
+ReleaseNotes for additional details.
+
+\section{64 bit Windows Client}
+\index[general]{Win64 Client}
+Unfortunately, Microsoft's implementation of Volume Shadown Copy (VSS) on
+their 64 bit OS versions is not compatible with a 32 bit Bacula Client.
+As a consequence, we are also releasing a 64 bit version of the Bacula
+Windows Client (win64bacula-3.0.0.exe) that does work with VSS.
+These binaries should only be installed on 64 bit Windows operating systems.
+What is important is not your hardware but whether or not you have
+a 64 bit version of the Windows OS.
+
+Compared to the Win32 Bacula Client, the 64 bit release contains a few differences:
+\begin{enumerate}
+\item Before installing the Win64 Bacula Client, you must totally
+ deinstall any prior 2.4.x Client installation using the
+ Bacula deinstallation (see the menu item). You may want
+ to save your .conf files first.
+\item Only the Client (File daemon) is ported to Win64, the Director
+ and the Storage daemon are not in the 64 bit Windows installer.
+\item bwx-console is not yet ported.
+\item bconsole is ported but it has not been tested.
+\item The documentation is not included in the installer.
+\item Due to Vista security restrictions imposed on a default installation
+ of Vista, before upgrading the Client, you must manually stop
+ any prior version of Bacula from running, otherwise the install
+ will fail.
+\item Due to Vista security restrictions imposed on a default installation
+ of Vista, attempting to edit the conf files via the menu items
+ will fail. You must directly edit the files with appropriate
+ permissions. Generally double clicking on the appropriate .conf
+ file will work providing you have sufficient permissions.
+\item All Bacula files are now installed in
+ {\bf C:/Program Files/Bacula} except the main menu items,
+ which are installed as before. This vastly simplifies the installation.
+\item If you are running on a foreign language version of Windows, most
+ likely {\bf C:/Program Files} does not exist, so you should use the
+ Custom installation and enter an appropriate location to install
+ the files.
+\item The 3.0.0 Win32 Client continues to install files in the locations used
+ by prior versions. For the next version we will convert it to use
+ the same installation conventions as the Win64 version.
+\end{enumerate}
+
+This project was funded by Bacula Systems.
+
\section{Duplicate Job Control}
\index[general]{Duplicate Jobs}
They are:
\subsection{Allow Duplicate Jobs = \lt{}yes|no\gt{}}
+\index[general]{Allow Duplicate Jobs}
If this directive is enabled duplicate jobs will be run. If
the directive is set to {\bf no} (default) then only one job of a given name
may run at one time, and the action that Bacula takes to ensure only
one job runs is determined by the other directives (see below).
\subsection{Allow Higher Duplicates = \lt{}yes|no\gt{}}
+\index[general]{Allow Higher Duplicates}
If this directive is set to {\bf yes} (default) the job with a higher
priority (lower priority number) will be permitted to run. If the
priorities of the two jobs are the same, the outcome is determined by
other directives (see below).
\subsection{Cancel Queued Duplicates = \lt{}yes|no\gt{}}
+\index[general]{Cancel Queued Duplicates}
If this directive is set to {\bf yes} (default) any job that is
already queued to run but not yet running will be canceled.
\subsection{Cancel Running Duplicates = \lt{}yes|no\gt{}}
+\index[general]{Cancel Running Duplicates}
If this directive is set to {\bf yes} any job that is already running
will be canceled. The default is {\bf no}.
Client for the File daemon, and Storage for the Storage daemon).
When {\bf TLS Authenticate} is enabled, after doing the CRAM-MD5
-authentication, Bacula will do the normal TLS authentication, then TLS
-encryption will be turned off.
+authentication, Bacula will also do TLS authentication, then TLS
+encryption will be turned off, and the rest of the communication between
+the two Bacula daemons will be done without encryption.
-If you want to encrypt communications data, do not turn on {\bf TLS
-Authenticate}.
+If you want to encrypt communications data, use the normal TLS directives
+but do not turn on {\bf TLS Authenticate}.
\section{bextract non-portable Win32 data}
\index[general]{bextract handles Win32 non-portable data}
The default value is {\bf no}.
-\section{Exclude Dirs Containing = \lt{}filename-string\gt{}}
+\section{Exclude Dir Containing = \lt{}filename-string\gt{}}
\index[general]{IgnoreDir}
-The {\bf ExcludeDirsContaining = \lt{}filename\gt{}} is a new directive that
+The {\bf ExcludeDirContaining = \lt{}filename\gt{}} is a new directive that
can be added to the Include section of the FileSet resource. If the specified
filename ({\bf filename-string}) is found on the Client in any directory to be
backed up, the whole directory will be ignored (not backed up). For example:
signature = MD5
}
File = /home
- Exclude Dirs Containing = .excludeme
+ Exclude Dir Containing = .excludeme
}
}
\end{verbatim}
files, directories, etc).
-
\section{Bacula Plugins}
\index[general]{Plugin}
Support for shared object plugins has been implemented in the Linux, Unix
Storage daemon.
\subsection{Plugin Directory}
+\index[general]{Plugin Directory}
Each daemon (DIR, FD, SD) has a new {\bf Plugin Directory} directive that may
be added to the daemon definition resource. The directory takes a quoted
string argument, which is the name of the directory in which the daemon can
can share the same plugin directory.
\subsection{Plugin Options}
+\index[general]{Plugin Options}
The {\bf Plugin Options} directive takes a quoted string
arguement (after the equal sign) and may be specified in the
Job resource. The options specified will be passed to all plugins
the plugin (i.e. not fully implemented).
\subsection{Plugin Options ACL}
+\index[general]{Plugin Options ACL}
The {\bf Plugin Options ACL} directive may be specified in the
Director's Console resource. It functions as all the other ACL commands
do by permitting users running restricted consoles to specify a
the Plugin Options.
\subsection{Plugin = \lt{}plugin-command-string\gt{}}
+\index[general]{Plugin}
The {\bf Plugin} directive is specified in the Include section of
a FileSet resource where you put your {\bf File = xxx} directives.
For example:
plugin.
\section{The bpipe Plugin}
+\index[general]{The bpipe Plugin}
The {\bf bpipe} plugin is provided in the directory src/plugins/fd/bpipe-fd.c of
the Bacula source distribution. When the plugin is compiled and linking into
the resulting dynamic shared object (DSO), it will have the name {\bf bpipe-fd.so}.
on the program called.
\section{Microsoft Exchange Server 2003/2007 Plugin}
+\index[general]{Microsoft Exchange Server 2003/2007 Plugin}
+\subsection{Background}
+The Exchange plugin was made possible by a funded development project
+between Equiinet Ltd -- www.equiinet.com (many thanks) and Bacula Systems.
+The code for the plugin was written by James Harper, and the Bacula core
+code by Kern Sibbald. All the code for this funded development has become
+part of the Bacula project. Thanks to everyone who made it happen.
\subsection{Concepts}
Although it is possible to backup Exchange using Bacula VSS the Exchange
\subsection{Restoring}
-
The restore operation is much the same as a normal Bacula restore, with
the following provisos:
\end{itemize}
\subsection{Restoring to the Recovery Storage Group}
-
The concept of the Recovery Storage Group is well documented by
Microsoft
\elink{http://support.microsoft.com/kb/824126}{http://support.microsoft.com/kb/824126},
Exchange as soon as the plugin has completed the backup. If the data
never makes it to the backup medium (eg because of spooling) then the
logs will still be truncated, but they will also not have been backed
-up. A solution to this is being worked on.
+up. A solution to this is being worked on. You will have to schedule a
+new Full backup to ensure that your next backups will be usable.
The "Enable Circular Logging" option cannot be enabled or the plugin
will fail.
\section{libdbi Framework}
+\index[general]{libdbi Framework}
As a general guideline, Bacula has support for a few catalog database drivers
(MySQL, PostgreSQL, SQLite)
coded natively by the Bacula team. With the libdbi implementation, which is a
from your OS distribution.
\section{Console Command Additions and Enhancements}
+\index[general]{Console Additions}
\subsection{Display Autochanger Content}
\index[general]{StatusSlots}
catalog.
\subsection{list joblog job=xxx or jobid=nnn}
+\index[general]{list joblog}
A new list command has been added that allows you to list the contents
of the Job Log stored in the catalog for either a Job Name (fully qualified)
or for a particular JobId. The {\bf llist} command will include a line with
In your Director's {\bf Messages} resource.
\subsection{Use separator for multiple commands}
- When using bconsole with readline, you can set the command separator to one
+\index[general]{Command Separator}
+ When using bconsole with readline, you can set the command separator with
+ \textbf{@separator} command to one
of those characters to write commands who require multiple input in one line.
\begin{verbatim}
!$%&'()*+,-/:;<>?[]^`{|}~
\end{verbatim}
+\subsection{Deleting Volumes}
+The delete volume bconsole command has been modified to
+require an asterisk (*) in front of a MediaId otherwise the
+value you enter is a taken to be a Volume name. This is so that
+users may delete numeric Volume names. The previous Bacula versions
+assumed that all input that started with a number was a MediaId.
+
+This new behavior is indicated in the prompt if you read it
+carefully.
+
+\section{Bare Metal Recovery}
+The old bare metal recovery project is essentially dead. One
+of the main features of it was that it would build a recovery
+CD based on the kernel on your system. The problem was that
+every distribution has a different boot procedure and different
+scripts, and worse yet, the boot procedures and scripts change
+from one distribution to another. This meant that maintaining
+(keeping up with the changes) the rescue CD was too much work.
+
+To replace it, a new bare metal recovery USB boot stick has been developed
+by Bacula Systems. This technology involves remastering a Ubuntu LiveCD to
+boot from a USB key.
+
+Advantages:
+\begin{enumerate}
+\item Recovery can be done from within graphical environment.
+\item Recovery can be done in a shell.
+\item Ubuntu boots on a large number of Linux systems.
+\item The process of updating the system and adding new
+ packages is not too difficult.
+\item The USB key can easily be upgraded to newer Ubuntu versions.
+\item The USB key has writable partitions for modifications to
+ the OS and for modification to your home directory.
+\item You can add new files/directories to the USB key very easily.
+\item You can save the environment from multiple machines on
+ one USB key.
+\item Bacula Systems is funding its ongoing development.
+\end{enumerate}
+
+The disadvantages are:
+\begin{enumerate}
+\item The USB key is usable but currently under development.
+\item Not everyone may be familiar with Ubuntu (no worse
+ than using Knoppix)
+\item Some older OSes cannot be booted from USB. This can
+ be resolved by first booting a Ubuntu LiveCD then plugging
+ in the USB key.
+\item Currently the documentation is sketchy and not yet added
+ to the main manual. See below ...
+\end{enumerate}
+
+The documentation and the code can be found in the {\bf rescue} package
+in the directory {\bf linux/usb}.
+
\section{Miscellaneous}
\index[general]{Misc New Features}
\subsection{Allow Mixed Priority = \lt{}yes|no\gt{}}
+\index[general]{Allow Mixed Priority}
This directive is only implemented in version 2.5 and later. When
set to {\bf yes} (default {\bf no}), this job may run even if lower
priority jobs are already running. This means a high priority job
be run until the priority 5 job has finished.
\subsection{Bootstrap File Directive -- FileRegex}
+\index[general]{Bootstrap File Directive}
{\bf FileRegex} is a new command that can be added to the bootstrap
(.bsr) file. The value is a regular expression. When specified, only
matching filenames will be restored.
During a restore, if all File records are pruned from the catalog
for a Job, normally Bacula can restore only all files saved. That
is there is no way using the catalog to select individual files.
- With this new command, Bacula will ask if you want to specify a Regex
+ With this new feature, Bacula will ask if you want to specify a Regex
expression for extracting only a part of the full backup.
+\begin{verbatim}
+ Building directory tree for JobId(s) 1,3 ...
+ There were no files inserted into the tree, so file selection
+ is not possible.Most likely your retention policy pruned the files
+
+ Do you want to restore all the files? (yes|no): no
+
+ Regexp matching files to restore? (empty to abort): /tmp/regress/(bin|tests)/
+ Bootstrap records written to /tmp/regress/working/zog4-dir.restore.1.bsr
+\end{verbatim}
+
\subsection{Bootstrap File Optimization Changes}
In order to permit proper seeking on disk files, we have extended the bootstrap
file format to include a {\bf VolStartAddr} and {\bf VolEndAddr} records. Each
\subsection{Virtual Tape Emulation}
+\index[general]{Virtual Tape Emulation}
We now have a Virtual Tape emulator that allows us to run though 99.9\% of
the tape code but actually reading and writing to a disk file. Used with the
\textbf{disk-changer} script, you can now emulate an autochanger with 10 drives
and 700 slots. This feature is most useful in testing. It is enabled
by using {\bf Device Type = vtape} in the Storage daemon's Device
-directive. This feature is only implemented on Linux machines.
+directive. This feature is only implemented on Linux machines and should not be
+used for production.
\subsection{Bat Enhancements}
+\index[general]{Bat Enhancements}
Bat (the Bacula Administration Tool) GUI program has been significantly
enhanced and stabilized. In particular, there are new table based status
commands; it can now be easily localized using Qt4 Linguist.
work.
\subsection{RunScript Enhancements}
+\index[general]{RunScript Enhancements}
The {\bf RunScript} resource has been enhanced to permit multiple
commands per RunScript. Simply specify multiple {\bf Command} directives
in your RunScript.
may remove it before the final release.
\subsection{Status Enhancements}
+\index[general]{Status Enhancements}
The bconsole {\bf status dir} output has been enhanced to indicate
Storage daemon job spooling and despooling activity.
\subsection{Connect Timeout}
+\index[general]{Connect Timeout}
The default connect timeout to the File
daemon has been set to 3 minutes. Previously it was 30 minutes.
\subsection{ftruncate for NFS Volumes}
+\index[general]{ftruncate for NFS Volumes}
If you write to a Volume mounted by NFS (say on a local file server),
in previous Bacula versions, when the Volume was recycled, it was not
properly truncated because NFS does not implement ftruncate (file
recent release of Bacula from the Ubuntu repositories.
\subsection{Recycle Pool = \lt{}pool-name\gt{}}
+\index[general]{Recycle Pool}
The new \textbf{RecyclePool} directive defines to which pool the Volume will
be placed (moved) when it is recycled. Without this directive, a Volume will
remain in the same pool when it is recycled. With this directive, it can be
be recycled back into the Scratch pool.
\subsection{FD Version}
+\index[general]{FD Version}
The File daemon to Director protocol now includes a version
number, which although there is no visible change for users,
will help us in future versions automatically determine
if a File daemon is not compatible.
\subsection{Max Run Sched Time = \lt{}time-period-in-seconds\gt{}}
+\index[general]{Max Run Sched Time}
The time specifies the maximum allowed time that a job may run, counted from
when the job was scheduled. This can be useful to prevent jobs from running
during working hours. We can see it like \texttt{Max Start Delay + Max Run
Time}.
\subsection{Max Wait Time = \lt{}time-period-in-seconds\gt{}}
-
+\index[general]{Max Wait Time}
Previous \textbf{MaxWaitTime} directives aren't working as expected, instead
of checking the maximum allowed time that a job may block for a resource,
those directives worked like \textbf{MaxRunTime}. Some users are reporting to
directives are now deprecated.
\subsection{Incremental|Differential Max Wait Time = \lt{}time-period-in-seconds\gt{}}
+\index[general]{Incremental Max Wait Time}
+\index[general]{Differential Max Wait Time}
+
These directives have been deprecated in favor of
\texttt{Incremental|Differential Max Run Time}.
\subsection{Max Run Time directives}
+\index[general]{Max Run Time directives}
Using \textbf{Full/Diff/Incr Max Run Time}, it's now possible to specify the
maximum allowed time that a job can run depending on the level.
\includegraphics{\idir different_time.eps}
\subsection{Statistics Enhancements}
+\index[general]{Statistics Enhancements}
If you (or probably your boss) want to have statistics on your backups to
provide some \textit{Service Level Agreement} indicators, you could use a few
SQL queries on the Job table to report how many:
The Bweb interface provides a statistics module that can use this feature. You
can also use tools like Talend or extract information by yourself.
-The {\textbf Statistics Retention = \lt{}time\gt{}} director directive defines
+The \textbf{Statistics Retention = \lt{}time\gt{}} director directive defines
the length of time that Bacula will keep statistics job records in the Catalog
database after the Job End time. (In \texttt{JobHistory} table) When this time
period expires, and if user runs \texttt{prune stats} command, Bacula will
\end{verbatim}
\subsection{ScratchPool = \lt{}pool-resource-name\gt{}}
+\index[general]{ScratchPool}
This directive permits to specify a specific \textsl{Scratch} pool for the
current pool. This is useful when using multiple storage sharing the same
mediatype or when you want to dedicate volumes to a particular set of pool.
\subsection{Enhanced Attribute Despooling}
+\index[general]{Attribute Despooling}
If the storage daemon and the Director are on the same machine, the spool file
that contains attributes is read directly by the Director instead of being
transmitted across the network. That should reduce load and speedup insertion.
\subsection{SpoolSize = \lt{}size-specification-in-bytes\gt{}}
+\index[general]{SpoolSize}
A new Job directive permits to specify the spool size per job. This is used
in advanced job tunning. {\bf SpoolSize={\it bytes}}
\subsection{MaxConsoleConnections = \lt{}number\gt{}}
+\index[general]{MaxConsoleConnections}
A new director directive permits to specify the maximum number of Console
Connections that could run concurrently. The default is set to 20, but you may
set it to a larger number.
+\subsection{VerId = \lt{}string\gt{}}
+\index[general]{VerId}
+A new director directive permits to specify a personnal identifier that will be
+displayed in the \texttt{version} command.
+
\subsection{dbcheck enhancements}
+\index[general]{dbcheck enhancements}
If you are using Mysql, dbcheck will now ask you if you want to create
temporary indexes to speed up orphaned Path and Filename elimination.
You can now specify the database connection port in the command line.
-\section{Building Bacula Plugins}
-There is currently one sample program {\bf example-plugin-fd.c} and
-one working plugin {\bf bpipe-fd.c} that can be found in the Bacula
-{\bf src/plugins/fd} directory. Both are built with the following:
-
-\begin{verbatim}
- cd <bacula-source>
- ./configure <your-options>
- make
- ...
- cd src/plugins/fd
- make
- make test
-\end{verbatim}
-
-After building Bacula and changing into the src/plugins/fd directory,
-the {\bf make} command will build the {\bf bpipe-fd.so} plugin, which
-is a very useful and working program.
-
-The {\bf make test} command will build the {\bf example-plugin-fd.so}
-plugin and a binary named {\bf main}, which is build from the source
-code located in {\bf src/filed/fd\_plugins.c}.
-
-If you execute {\bf ./main}, it will load and run the example-plugin-fd
-plugin simulating a small number of the calling sequences that Bacula uses
-in calling a real plugin. This allows you to do initial testing of
-your plugin prior to trying it with Bacula.
-
-You can get a good idea of how to write your own plugin by first
-studying the example-plugin-fd, and actually running it. Then
-it can also be instructive to read the bpipe-fd.c code as it is
-a real plugin, which is still rather simple and small.
-
-When actually writing your own plugin, you may use the example-plugin-fd.c
-code as a template for your code.
-
-
+\subsection{{-}{-}docdir configure option}
+\index[general]{{-}{-}docdir configure option}
+You can use {-}{-}docdir= on the ./configure command to
+specify the directory where you want Bacula to install the
+LICENSE, ReleaseNotes, ChangeLog, ... files. The default is
+{\bf /usr/share/doc/bacula}.
+
+\subsection{{-}{-}htmldir configure option}
+\index[general]{{-}{-}htmldir configure option}
+You can use {-}{-}htmldir= on the ./configure command to
+specify the directory where you want Bacula to install the bat html help
+files. The default is {\bf /usr/share/doc/bacula/html}
+
+\subsection{{-}{-}with-plugindir configure option}
+\index[general]{{-}{-}plugindir configure option}
+You can use {-}{-}plugindir= on the ./configure command to
+specify the directory where you want Bacula to install
+the plugins (currently only bpipe-fd). The default is
+/usr/lib.
projects / bacula / docs / blobdiff