[Bacula-commits] [bacula.org] Bacula Community manual branch Branch-5.2 updated. 95ad07a6a2cdc3e1a7cc63b20f635aac581b0eda

[<gi...@ba...>]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Bacula Community manual".

The branch, Branch-5.2 has been updated
       via  95ad07a6a2cdc3e1a7cc63b20f635aac581b0eda (commit)
       via  9044bfff1a29e54894e26de1e09a78ae1842ae23 (commit)
      from  182394fc88890668c2c5ac76798f4bd2cdef3e30 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 95ad07a6a2cdc3e1a7cc63b20f635aac581b0eda
Author: Kern Sibbald <ke...@si...>
Date:   Sat Nov 26 15:17:21 2011 +0100

    Fix new features links

commit 9044bfff1a29e54894e26de1e09a78ae1842ae23
Author: Kern Sibbald <ke...@si...>
Date:   Sat Nov 26 12:09:59 2011 +0100

    Fix error in developers pluginAPI chapter

-----------------------------------------------------------------------

Summary of changes:
diff --git a/docs/manuals/en/developers/pluginAPI.tex b/docs/manuals/en/developers/pluginAPI.tex
index 42103f2..2a36b7a 100644
--- a/docs/manuals/en/developers/pluginAPI.tex
+++ b/docs/manuals/en/developers/pluginAPI.tex
@@ -491,13 +491,13 @@ Most of the above are self-explanatory.
 \item [bEventVssBackupAddComponents] 
 
 \item [bEventPluginCommand] is called for each PluginCommand present in the
-  current FileSet. The event will be sent only on plugin specifed in the
-  command. The argument is the PluginCommand (not valid after the call). 
+  current FileSet.  The event will be sent only on plugin specifed in the
+  command.  The argument is the PluginCommand (not valid after the call).
 
 \item [bEventHandleBackupFile] is called for each file of a FileSet when
-  using a Options Plugin. If the plugin returns CF_OK, it will be used for the
-  backup, if it returns CF_SKIP, the file will be skipped. Anything else will
-  backup the file with Bacula core functions.
+  using a Options Plugin.  If the plugin returns CF\_OK, it will be used
+  for the backup, if it returns CF\_SKIP, the file will be skipped.
+  Anything else will backup the file with Bacula core functions.
 \end{description}
 
 During each of the above calls, the plugin receives either no specific value or
diff --git a/docs/manuals/en/main/newfeatures.tex b/docs/manuals/en/main/newfeatures.tex
index 456696e..069679a 100644
--- a/docs/manuals/en/main/newfeatures.tex
+++ b/docs/manuals/en/main/newfeatures.tex
@@ -1,7 +1,11 @@
-\chapter{New Features in 5.2.2}
+\chapter{New Features in 5.2.x}
 This chapter presents the new features that have been added to the next
 Community version of Bacula that is not yet released.
 
+\chapter{New Features in 5.2.2}
+This chapter presents the new features that have been added to the current
+Community version of Bacula that is now released.
+
 \section{Additions to RunScript variables}
 You can have access to Director name using \%D in your runscript
 command.
@@ -11,8 +15,8 @@ RunAfterJob = "/bin/echo Director=%D
 \end{verbatim}
 
 \chapter{New Features in 5.2.1}
-This chapter presents the new features that have been added to the current
-Community version of Bacula that is now released.
+This chapter presents the new features were added in the
+Community release version 5.2.1.
 
 There are additional features (plugins) available in the Enterprise version
 that are described in another chapter. A subscription to Bacula Systems
@@ -615,26 +619,88 @@ and is available with Bacula Enterprise Edition and Community Edition.
 
 \section{Class Based Database Backend Drivers}
 
+The main Bacula Director code is independent of the SQL backend
+in version 2.5.0 and greater.  This means that the Bacula Director can be
+packaged by itself, then each of the different SQL backends supported can
+be packaged separately.  It is possible to build all the DB backends at the
+same time by including multiple database options at the same time.
+
+./configure can be run with multiple database configure options.
+\begin{verbatim}
+   --with-sqlite3
+   --with-mysql
+   --with-postgresql
+\end{verbatim}
+
+Order of testing for databases is:
+\begin{itemize}
+\item postgresql
+\item mysql
+\item sqlite3
+\end{itemize}
+
+Each configured backend generates a file named:
+\verb+libbaccats-<sql_backend_name>-<version>.so+ 
+A dummy catalog library is created named libbaccats-version.so
+
+At configure time the first detected backend is used as the so called
+default backend and at install time the dummy 
+\verb+libbaccats-<version>.so+ is replaced with the default backend type.
+
+If you configure all three backends you get three backend libraries and the
+postgresql gets installed as the default.  
+
+When you want to switch to another database, first save any old catalog you
+may have then you can copy one of the three backend libraries over the
+\verb+libbaccats-<version>.so+ e.g.
+
+An actual command, depending on your Bacula version might be:
+\begin{verbatim}
+   cp libbaccats-postgresql-5.2.2.so libbaccats-5.2.2.so
+\end{verbatim}
+
+where the \verb+5.2.2+ must be replaced by the Bacula release
+version number.
+
+Then you must update the default backend in the following files:
+
+\begin{verbatim}
+  create_bacula_database
+  drop_bacula_database
+  drop_bacula_tables
+  grant_bacula_privileges
+  make_bacula_tables
+  make_catalog_backup
+  update_bacula_tables 
+\end{verbatim}
+
+And re-run all the above scripts.  Please note, this means
+you will have a new empty database and if you had a previous
+one it will be lost.
+
 All current database backend drivers for catalog information are rewritten
 to use a set of multi inherited C++ classes which abstract the specific
 database specific internals and make sure we have a more stable generic
-interface with the rest of sql code. From now on there is a strict boundery
-between the SQL code and the low-level database functions. This new interface
-should also make it easier to add a new backend for a currently unsupported
-database. As part of the rewrite the SQLite 2 code was removed (e.g. only
-SQLite 3 is now supported). An extra bonus of the new code is that you can
-configure multiple backends in the configure and build all backends in one
-compile session and select the correct database backend at install time.
-This should make it a lot easier for packages maintainers.
+interface with the rest of sql code.  From now on there is a strict
+boundery between the SQL code and the low-level database functions.  This
+new interface should also make it easier to add a new backend for a
+currently unsupported database.  As part of the rewrite the SQLite 2 code
+was removed (e.g.  only SQLite 3 is now supported).  An extra bonus of the
+new code is that you can configure multiple backends in the configure and
+build all backends in one compile session and select the correct database
+backend at install time.  This should make it a lot easier for packages
+maintainers.
+
+
 
 \medskip
-We also added cursor support for PostgreSQL backend, this improves memory usage
-for large installation.
+We also added cursor support for PostgreSQL backend, this improves memory
+usage for large installation.
 
 \medskip
-This project was implemented by Planets Communications B.V. and ELM Consultancy B.V.
-and Bacula Systems and is available with both the Bacula Enterprise Edition and
-the Community Edition.
+This project was implemented by Planets Communications B.V. and ELM
+Consultancy B.V. and Bacula Systems and is available with both the Bacula
+Enterprise Edition and the Community Edition.
 
 \section{Hash List Enhancements}
 


hooks/post-receive
-- 
Bacula Community manual