Hello,
This is to let you know that we will be releasing Bacula 5.0.3 this week, so
for packagers, it would be a good time to take a look at the SF repository to
see if there are any changes need to make packages. It is always good to
have the "final" package source in the final release we make.
Best regards,
Kern

Hello,
Bacula version 5.0.1 source code and Windows (32/64 bit) binaries have been
released to Source Forge (thanks Eric).
This is a major bug fix release including a few directives that have been
rewritten, one new directive, and some different directive behavior (see the
release notes below). As is usual for a patch release (last digit changes by
one), this version is compatible with the 5.0.0 database and with prior
clients. However, you *must* upgrade all components that are on any one
machine (that is you must upgrade your Director, Storage daemon, and File
daemon at the same time, if they reside on the same machine).
Note, Bacula does not normally uninstall previous versions, and we have
changed the shared object naming convention, so you might want to first save
your configuration files then uninstall the old Bacula using the old Bacula
uninstall prior to installing the new one. If you do not, it should not be
serious, but you may be left with some older Bacula shared objects that are
not used and hence wasting a small amount of disk space.
If you are upgrading from version 3.0.x or prior, please see the full release
notes as you must do a database upgrade. When updating from 5.0.0 to this
release there is no database upgrade needed.
Scott has made a number of changes and improvements in the rpm packaging over
the past few weeks since version 5.0.0 was released, so he will probably be
releasing the 5.0.1 rpms quite soon.
Thanks for using Bacula :-)
Best regards,
Kern
============= Performance Note ==================
Some of you have encountered performance problems with your
database (mainly with MySQL) with Bacula version 5.0.0. This is
mainly because we've changed the SQL query used for restore,
accurate jobs and base jobs. We have extensively tested this
change, and though it should be a little bit slower than the previous
versions, on a well configured database it should run
extremely well.
We strongly recommend to avoid the temptation to add new indexes.
In general, these will cause very significant performance
problems in other areas. A better approch is to carefully check
that all your MySQL memory configuation parameters are are
suitable for the size of your installation. If you backup
millions of files, you need to adapt the database memory
configuration parameters concerning sorting, joining and global
memory. By default, sort and join parameters are very small
(sometimes 8Kb), and having sufficient memory specified by those
parameters is extremely important to run fast.
If adjusting your MySQL memory configuration values does not
solve your problem, you can also consider switching to
PostgreSQL, which performs much better with Bacula on big
installations (many millions of files per Job). However for
large installations, you will also need to adjust the default
PostgreSQL memory configuration parameters.
==========================================
Release Notes for Bacula 5.0.1
Bacula code: Total files = 1,081 Total lines = 217,272 (Using SLOCCount)
!!!!!!!!!!!!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
The Allow Duplicate Jobs directive has been significantly
reworked, and the default value has changed. See below.
Truncate On Purge has been totally rewritten. See the new
features section of the manual.
When Volume Poll Interval is set in the SD DEVICE configuration,
(default 5 mins), after a certain number of polling tries (approx
10) polling will stop and the operator will be asked to
resolve the problem. Previously there was no limit, and an
error message could be produced at each poll attempt.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Changes since 5.0.0
-------------------
- We believe that we have resolved most of the problems
concerning canceled or failed jobs being "stuck" in the
Director. There is one outstanding problem in the SD when
canceling jobs that we will fix in the next major release.
If you see jobs that seem to be stuck, in general issuing
a cancel command in bconsole should now make them go away.
Directives:
- The default for "Allow Duplicate Jobs" has been changed from
no to yes. If you use this directive, please check your
conf file, and note the next two items !!!!!!!!!!!!!!!!!!!
- AllowHigherDuplicates disabled. It did not work as documented
and was confusing.
- New directive "CancelLowerLevelDuplicates" See New Features
section in the manual.
- Truncate on Purge rewritten. See New Features section in the manual.
Bug fixes:
1448 1466 1467 1468 1476 1481 1486 1488 1494 1497
1499 1501 1505 1509 1513
- Ensure SD asks for help when looping even if poll set. Fixes bug #1513.
- Fix three-pool regress bug
- Modify bacula.spec fixes bug #1505
- This version fixes an issue where the console window would start out
docked. It is fixed by initiating the variables in the Pages class wi
constructor.
- Fix make_catalog_backup.pl fails when catalog db is on other host
- Apply MacOSX installer patch from bug #1509
- Apply fix to previous fix of Copy problem. Fix proposed by reporter o
#1476
- Fix bug #1501 -t does not print errors
- Apply SQLite3 update fix from bug #1497
- Apply bashism fix for diskchanger.in script from bug #1499
- Apply rpm fix for Sci Linux from bug #1494
- Take most recent Ukranian po from bug #1448
- Probable fix for Copy/Migration bug #1476
- Fix bug #1488 -- avoid recursion and race conditions in messages.c
- Upgrade cats library also to 5.0.0
- Fix missing console page in bat
- Add bat help files to Window install
- Improve Windows upgrade to ensure old FD is shutdown
- Fix bug #1481 -- bat consumes all console file descriptors
- Backport truncate on purge from 5.1.x
- Fix bug #1486 -- bat doesn't show any errors on command-line
- Update the bsock error URL
- Correct .my.cnf umask in make_catalog_backup.pl
- Apply fix for dbcheck use by make_catalog_backup.pl
- Fix seg fault in bscan from new comment field
- Allow multiple CNs when using TLS
- Fix seg fault in SQlite driver
- Make shared libs version the same as the Bacula release version
- Remove file_index sequential check
- Fix #1466 about Bogus pruning message
For Packagers:
1. The default query.sql file is now, except for some comments, empty.
The old file, which we no longer support (it is impossible or difficult to
make it work on every backend, and the queries are mostly contributed) can
be found in <bacula-source>/examples/sample-query.sql. The sample file is
not installed by the Makefiles
2. When you install the mtx-changer script, you must also install
mtx-changer.conf if it does not exist. This new file (mtx-changer.conf) is
required for mtx-changer to work, but it is a user configurable file, so on
any update, any existing file should not be overwritten.
3. Bat should be built on every platform that is capabable of running Qt.
However, the Qt code is changing rather quickly and is not always
compatible from version to version. We have built and verified bat on Qt
4.3.4. We strongly recommend that you do not build and distribute bat with
any other version of Qt unless you personally test it. To build against Qt
4.3.4, download the depkgs-qt package from the Bacula Source Forge download
location, read the README file and follow the instructions.
If you are building for Bacula version 5.0.0, please ensure that you do not
have qmake-qt4 loaded on your system. If you do, either remove it or
rename it before trying to build bat. If you do not, bat will probably be
built using the shared objects on your system. For Bacula 5.0.1 and later,
this problem (bug) does not exist.
depkgs-qt does not install Qt on your system, nor does it interfere with
you having any other version of Qt installed on your system. Once you
build bat with depkgs-qt, it should *not* use the Qt shared objects, but
rather they will be linked into the program. After fully installing bat
(make install), you can run "ldd bat" to see what shared objects it will
use. If any Qt shared objects are referenced, something has gone wrong.
4. Unless absolutely necessary, we recommend that you do not define any
special library environment variables that apply to the ./configure -- for
example: LIBDIR=/... ./configure <your-options> is strongly discouraged.
Doing so, could potentially cause Bacula to be linked against the wrong
shared objects.
5. The Bacula project strongly recommends that you install Bacula into a
single directory, with a few minor exceptions such as the MySQL or
PostgreSQL databases. Preferrably this should be /opt/bacula. The full
recommendation is:
#!/bin/sh
# Recommended configure script for Bacula
prefix=/opt/bacula
email=xxx@...
CFLAGS="-g -O2 -Wall" \
./configure \
--sbindir=${prefix}/bin \
--sysconfdir=${prefix}/etc \
--docdir=${prefix}/html \
--htmldir=${prefix}/html \
--with-working-dir=${prefix}/working \
--with-pid-dir=${prefix}/working \
--with-subsys-dir=${prefix}/working \
--with-scriptdir=${prefix}/scripts \
--with-plugindir=${prefix}/plugins \
--libdir=${prefix}/lib \
--enable-smartalloc \
--enable-tray-monitor \
--enable-bat \
--with-mysql \
--with-dump-email=${email} \
--with-job-email=${email} \
--with-smtp-host=localhost \
--with-baseport=9101
Obviously, the email, and some of the minor options (mysql, postgresql,
...) can be changed to suit your distribution, but the directory names
defined above are strongly recommended, and over time the default values in
the bacula-dir.conf and bacula-sd.conf will reflect these choices.
If you have any questions about this or would like a detailed document
describing our recommendations including packaging requirements, please
send an email to the bacula-devel list.
6. Starting with Bacula version 3.0.0 up to Bacula 5.0.0, the shared
libraries that Bacula uses by default are named xxx-1.0.0. Starting with
Bacula 5.0.1, we are going to name the libraries using the Bacula version.
So in Bacula 5.0.1, the libraries will be named xxx-5.0.1. With future
versions, the last digit may or may not change when we distribute patch
updates (i.e. the last digit of the version changes). This will depend on
whether or not we have changed something in the library. Hopefully this
new procedure will resolve some of the incompatibility problems between
different versions of the shared objects.
7. The default build option for bconsole is conio (my own little console
routines). I did this because some years ago, readline was very difficult
to maintain -- it and where it was found seemed to change on every release.
This generated at the time a number of support problems. It seems to me
that since then there have been very few problems with readline. As a
consequence, I have no problem if you want to make bconsole with readline
enabled. It will actually give some very nice new bconsole command
completion functionality that Eric has written. Bottom line: feel free to
use readline or not as you please.
==========================================================

Hello,
I have switched the regression scripts to that they will do the testing
against Branch-5.0 rather than master. This will be done automatically the
next time you do a "git pull" or during the next nightly-disk regression you
use.
After version 5.0.1 is released, I will switch it back to doing regressions
against our development master branch.
Many thanks for your testing.
Best regards,
Kern

Hello,
This is to let you know that if all goes well, we will be releasing Bacula
version 5.0.1 this weekend, or perhaps early next week. It is principally a
bug fix to Bacula 5.0.0, but also consists of a redesign of the Truncate on
purge feature that did not work correctly.
For packagers, there are a few things to note for Bacula version 5.0.0 and
later.
1. The default query.sql file is now, except for some comments, empty. The
old file, which we no longer support (it is impossible or difficult to make
it work on every backend, and the queries are mostly contributed) can be
found in <bacula-source>/examples/sample-query.sql. The sample file is not
installed by the Makefiles
2. When you install the mtx-changer script, you must also install
mtx-changer.conf if it does not exist. This new file (mtx-changer.conf) is
required for mtx-changer to work, but it is a user configurable file, so on
any update, any existing file should not be overwritten.
3. Bat should be built on every platform that is capabable of running Qt.
However, the Qt code is changing rather quickly and is not always compatible
from version to version. We have built and verified bat on Qt 4.3.4. We
strongly recommend that you do not build and distribute bat with any other
version of Qt unless you personally test it. To build against Qt 4.3.4,
download the depkgs-qt package from the Bacula Source Forge download
location, read the README file and follow the instructions.
If you are building for Bacula version 5.0.0, please ensure that you do not
have qmake-qt4 loaded on your system. If you do, either remove it or rename
it before trying to build bat. If you do not, bat will probably be built
using the shared objects on your system. For Bacula 5.0.1 and later, this
problem (bug) does not exist.
depkgs-qt does not install Qt on your system, nor does it interfere with you
having any other version of Qt installed on your system. Once you build bat
with depkgs-qt, it should *not* use the Qt shared objects, but rather they
will be linked into the program. After fully installing bat (make install),
you can run "ldd bat" to see what shared objects it will use. If any Qt
shared objects are referenced, something has gone wrong.
4. Unless absolutely necessary, we recommend that you do not define any
special library environment variables that apply to the ./configure -- for
example: LIBDIR=/... ./configure <your-options> is strongly discouraged.
Doing so, could potentially cause Bacula to be linked against the wrong
shared objects.
5. The Bacula project *strongly* recommends that you install Bacula into a
single directory, with a few minor exceptions such as the MySQL or PostgreSQL
databases. Preferrably this should be /opt/bacula.
The full recommendation is:
#!/bin/sh
# Recommended configure script for Bacula
prefix=/opt/bacula
email=xxx@...
CFLAGS="-g -O2 -Wall" \
./configure \
--sbindir=${prefix}/bin \
--sysconfdir=${prefix}/etc \
--docdir=${prefix}/html \
--htmldir=${prefix}/html \
--with-working-dir=${prefix}/working \
--with-pid-dir=${prefix}/working \
--with-subsys-dir=${prefix}/working \
--with-scriptdir=${prefix}/scripts \
--with-plugindir=${prefix}/plugins \
--libdir=${prefix}/lib \
--enable-smartalloc \
--enable-tray-monitor \
--enable-bat \
--with-mysql \
--with-dump-email=${email} \
--with-job-email=${email} \
--with-smtp-host=localhost \
--with-baseport=9101
Obviously, the email, and some of the minor options (mysql, postgresql, ...)
can be changed to suit your distribution, but the directory names defined
above are strongly recommended, and over time the default values in the
bacula-dir.conf and bacula-sd.conf will reflect these choices.
If you have any questions about this or would like a detailed document
describing our recommendations including packaging requirements, please send
an email to the bacula-devel list.
6. Starting with Bacula version 3.0.0 up to Bacula 5.0.0, the shared libraries
that Bacula uses by default are named xxx-1.0.0. Starting with Bacula 5.0.1,
we are going to name the libraries using the Bacula version. So in Bacula
5.0.1, the libraries will be named xxx-5.0.1. With future versions, the last
digit may or may not change when we distribute patch updates (i.e. the last
digit of the version changes). This will depend on whether or not we have
changed something in the library. Hopefully this new procedure will resolve
some of the incompatibility problems between different versions of the shared
objects.
7. The default build option for bconsole is conio (my own little
console routines). I did this because some years ago, readline was very
difficult to maintain -- it and where it was found seemed to change on every
release. This generated at the time a number of support problems.
It seems to me that since then there have been very few problems with
readline.
As a consequence, I have no problem if you want to make bconsole with readline
enabled. It will actually give some very nice new bconsole command
completion functionality that Eric has written.
Bottom line: feel free to use readline or not as you please.
Best regards,
Kern
-------------------------------------------------------

Hello,
Bat:
We have received a number of problem reports and bugs about building and
running bat, and unfortunately our documentation was insufficient, which is
hopefully now corrected.
Bat is built with the Qt packages for doing the GUI. I have worked with a lot
of different GUI packages (Sun/Solaris, Mac, Windows, OS/2, wxWidgits, X,
Qt3, Qt4, ...) and I prefer Qt4 over all the other ones. However, it is very
version dependent, which is a bit of a pain. As a consequence, the only way
to get a stable working version of Bat is to build it on the version of Qt
where we have built and tested it. That version is Qt 4.3.4 (default on
Ubuntu 8.04).
So to get bat to build correctly, we have released a depkgs-qt that contains
the source code for Qt 4.3.4, and if you are trying to build Bat, either you
should load the Qt 4.3.4 binaries on your system, or download our depkgs-qt
release from Source Forge and built Qt 4.3.4 there. Building from depkgs-qt
does not install Qt on your system, it is just used in the Bat build.
We have updated the manuals (5.0.0 and 5.1.x-development) on the web site to
have more detailed instructions on building Bat. Hopefully this will resolve
any and all problems you may be having.
Sorry for the inconvenience.
Please see:
http://www.bacula.org/5.0.x-manuals/en/main/main/Installing_Bacula.html#SECTION001250000000000000000
for details.
==============================
ActionOnPurge: --- Please do not use!!!
Action on purge is a new directive in 5.0.0, which permits automatically
truncating your volumes with the volume is purged. Unfortunately, this new
code is not very robust and in some cases can lead to problems. We strongly
recommend that you avoid using this directive.
We are rewriting the implementation for version 5.0.1 where it will be a very
useful feature.
Best regards,
Kern

Hello,
Bacula version 5.0.0 will be released today. For those of you who are
packagers, I strongly encourage you to use the .spec files that are in
platforms/redhat for making your .rpm releases. As usual, they will very
likely need a bit of work, but they do have quite a few bug fixes that I have
added over the past months, and in addition, I have separated bat, mtx, and
the docs from the main bacula.spec, which simplifies things quite a bit. In
fact, the bat build uses depkgs-qt, which *should* build on any machine, in
particular RedHat and CentOS where we should be releasing bat.
Best regards,
Kern

Hello,
In principle, Bacula version 3.0.3 is now ready release. We will run a few
addition overnight tests with the code as it is, then release it -- probably
Sunday or more likely Monday. In case of any serious problems, it can still
be updated.
There still remain a few bugs to fix, but since 3.0.3 already has a good
number of bug fixes, we would like to get it out rather than waiting any
longer.
If you want a copy before the release, you can get it with the following
commands:
git clone git://bacula.git.sourceforge.net/gitroot/bacula/bacula xxx
cd xxx
git checkout -b 3.0.3
you will then have a 3.0.3 branch defined and the code that we plan to release
will be in xxx, which can be any directory name you want.
Best regards,
Kern

Hello,
We would like to release a bug fix version 3.0.3 in the near future (before
mid-October), and this is just to let you know that if you want to experiment
with it, it is in branch "3.0.3" in the Git repository.
If you are running nightly regression tests using the nightly-disk script, we
are going to temporarily force your regression tests to run on the 3.0.3
branch. Once the release is made, we will switch you back to the master
branch. As with all scripts and multiple OSes, there is always a possibility
something goes wrong so don't worry too much :-)
Best regards,
Kern

Hello,
Some of you who are running regression tests have upgraded the tests to run
with GIT -- many thanks.
However, our GIT repo has been moved, and your tests are still running old
Bacula code. Please make the following modification to your GIT repo where
you are running the regression tests:
cd <Bacula-git-main-directory>
edit .git/config
(change the following line ...
url = git://bacula.git.sourceforge.net/gitroot/bacula
to
url = git://bacula.git.sourceforge.net/gitroot/bacula/bacula
That should do it. You can test if it is working by doing:
git pull
Many thanks,
Kern

Hello,
This is to inform you that yesterday, Source Forge changed the URL of our
Bacula source GIT repository. They did so to permit projects to have multiple
GIT repositories -- (very good!).
Those of you, especially those running nightly regression testing, who have
cloned the GIT repository will need to make a minor modification to the config
file or to delete the old repository and clone a new one.
The simplest solution is to:
cd <your-repo-directory>/.git
(edit the file "config")
and change the line that reads:
url = git://bacula.git.sourceforge.net/gitroot/bacula
to
url = git://bacula.git.sourceforge.net/gitroot/bacula/bacula
That is just append a /bacula to the end of the URL.
If you do not feel at ease directly editing the git config file, then:
rm -rf <your-repo-directory>
git clone git://bacula.git.sourceforge.net/gitroot/bacula/bacula <your-repo-directory>
Sorry for the inconvenience ...
Regression testing:
Since we have switched to git, a number of you who were previously doing nightly
testing have not yet moved to git. It takes a bit of work, especially if you are
running on a system like CentOS or RedHat where there is no git package,
but we would really appreciate the effort to put in place nightly regressions.
Running regression tests helps you ensure that when we release a new version,
it will work on your system without unpleasant surprises!
If you have not done regression testing, and you have a few extra cycles to spare
every night (or when you want), it is not very hard to set up Bacula regression testing
on a machine. It is reasonably well documented in the Developer's guide, and
if you have any questions or problems, you can feel free to email us on
the bacula-devel email list. Anyone can do regression testing and post it
to the Bacula regression dash board:
http://regress.bacula.org/index.php?project=bacula
If you do decide to do regression testing, it can be helpful for us if you send
the "name" you use to identify your regression tests with your email address.
That way, if we detect any problems and need to understand what your environment
is, we can more easily contact you.
For those of you who have been testing (Frank and DassIT): many thanks.
Best regards,
Kern

Hello,
If you are currently running nightly regression scripts for Bacula, I thank
you very much because your test results help us find subtle OS dependent
bugs.
Due to the change from SVN to git, you will need to make some minor
modifications to get the regression scripts running again. (Thanks to Frank
Sweetser for making the svn to git regress patch).
First ensure that git is installed on your machine.
If you currently have the following directory structure for running the
regression scripts:
xxxx
xxxx/bacula
xxxx/regress
Then please copy "xxxx/regress/config" to some temporary location,
e.g.
cp xxxx/regress/config /tmp/config
then do the following, which will delete and replace your xxxx directory by
the git version.
rm -rf xxxx
git clone git://bacula.git.sourceforge.net/gitroot/bacula xxxx
cp /tmp/config xxxx/regress/config
where in each case, replace xxxx by the full path to directory containing
bacula and regress.
Once you have done the above, the regression scripts can be run exactly as
they were before. In fact, if you have a cron job that does it, it should
continue to work as before.
Thanks for testing and sorry for the inconvenience.
Best regards,
Kern

Hello,
If you are a packager or a translator, please be aware that I have now tagged
version 3.0.2 in the SVN. If there are no problems, it will probably be
released on Tuesday. There there are problems, I may add a few fixes prior
to the final release (unlikely).
The release is marked with a tag Release-3.0.2 and is revision 9066.
For packagers, you can start working on packaging with what is currently in
the SVN.
For documentors, please be aware that the docs files have been updated to have
the new date and version number, and the po translation files have been
updated to match the current source code, so please do "svn update" before
continuing your work. I have posted the most recent Spanish and German
translation of the manual to the web site (the French manual is not currently
under active development).
For regression testers, many thanks for testing so many different platforms.
It really helps us. If you are not aware, the results of regression testing
are displayed in our CDash dashboard at:
http://regress.bacula.org/index.php?project=bacula
Thanks for all your help.
Best regards,
Kern

Hello,
This Bacula status report will discuss the following items:
- Up coming Release 3.0.2
- Discontinuing version 2.4.x
- Bacula Enterprise Edition
- Foundation Course
- Email problems
- New development strategy
Up coming Release 3.0.2:
We have been working on bug fixes and a few minor new features that are going
into version 3.0.1, and if all goes well, we will release version 3.0.2
sometime shortly after mid-July. In the mean time, the SVN seems quite
stable. There are still a number of bugs outstanding, and we hope to fix
most of them in the next two weeks.
Discontinuing version 2.4.x:
As I previously discussed, we are discontinuing version 2.4.x. This is because
we are focusing all our Bacula project effort on the current trunk (3.0.x).
As a consequence version 2.4.4 will no longer be supported; we will no longer
produce pataches for it; and bugs will only be considered if they seem to be
relevant to the current development version (3.0.x). This doesn't mean we
will have extra time on our hands, because we are effectively replacing the
old 2.4.x branch by the Bacula Enterprise Edition (see the next item).
Bacula Enterprise Edition:
As I noted in a previous email (quite a while ago), Bacula Systems will be
releasing a version of Bacula that will be targeted for the enterprise
market -- in fact, high end enterprises. It will be announced shortly and
will be called the Bacula Enterprise Edition. This version of Bacula will
effectively replace the old 2.4.x branch. As you probably know,
many "commercial" branches of Open Software projects add additional features
to their enterprise editions and do not release the source code -- they
effectively take a major portion of the project proprietary. This will not
be the case with the Bacula project and Bacula Systems -- all the code we
develop will be released. In fact, the Enterprise Edition will have fewer
features than the "community" version. So, if you want to use the enterprise
edition, you will be able to, but the Bacula project already has its hands
full with the development stream, so we will not be supporting it. The
closest analogy to Bacula - Bacula Systems is Fedora - Red Hat, where you can
get the source code for both, but if you want support for the Red Hat
Enterprise Linux version, you must have a subscription.
Some of you may not want to hear about enterprise stuff, and I can understand
that. I will try to avoid "commercial" messages as much as possible on these
lists, but Bacula Systems and the enterprise market are very important to me
for two main reasons:
1. I am spending a lot of time on enterprise stuff
2. I believe the enterprise market (with their financial weight) is the key to
getting a host of new and interesting features into Bacula. If you read my
3.0.0 release message, you should have gotten a good appreciation for the
number of new features that were sponsored by enterprises for that version.
Foundation course:
Over the past 6 months I have been devoting a large fraction of my time to
develop Bacula training, which is critical for the enterprise market. The
first part -- a Bacula Foundation Course is now ready, and the next course
will be given by me in Yverdon-les-Bains, Switzerland, the 7th, 8th, and 9th
of July. This course if for people who do not yet know Bacula (if you have
built and installed it, this is not a course for you). If you are
interested, please see the Bacula web site (www.bacula.org) or the Bacula
Systems web site (www.baculasystems.com).
I am now beginning work on the Advanced Course, which should interest many of
you, but I expect that it will take 4-6 months before this course will be
ready.
Email problems:
I've been having serious problems with email lately for two reasons:
1. I have not received a good number of emails sent to me.
2. The emails are coming into my inbox faster than I can deal with them.
Problem 1 seems to be due to the fact that my backup relay server stopped
relaying email. Thanks to Marco for figuring this out -- it was very
annoying and should now be fixed.
Problem 2 isn't getting much better, but hopefull will over the next month or
two.
Bottom line: I am sorry if you sent me email and I have not reponded. If this
is the case please ping me as I may have never received your email.
New development strategy:
One part of development that has always bothered me was when we get close to a
release, we must slow down, and finally "freeze" the development SVN to
ensure that the new release is stable. I've taken a good look at Open Source
tools that can alleviate a lot of these problems -- in particular Bazaar and
Git, and after a lot of thought, we will be converting the base part of the
Bacula source repository from Subversion to Git. If all goes well this will
happen around mid-July. If you currently use our SVN repository to pull
versions of Bacula, you should have absolutely no problem switching to git.
However, if you are a developer and do commits, using git is a whole
different story -- it is much more powerful, and thus different from
Subversion and consequently more complicated. I would recommend to all
developers to start learning git.
Best regards,
Kern

Hello,
This is to let you know that you should turn off your 2.4 branch testing as
the branch is now no longer in need of testing -- it will not be maintained
any further.
I have modified the normal nightly-* scripts in the branch simply to exit, so
in any case, even if you do not turn it off, it should just stop immediately.
Some of you are running tests with broken configurations: this typically shows
up by huge numbers of "false" failures -- i.e. more than half the tests fail.
Please periodically check the ouput, and if your tests are failing in large
numbers and other peoples tests are not, please examine the output.
Typical reasons for "false" failures:
1. You are running with a host name other than "localhost" and you have not
defined that host in your /etc/hosts file (i.e. using the host name as an
address causes the DNS lookup to fail).
2. Improper setup of PostgreSQL -- typically this is because you have not
defined the proper character encoding format. It should be SQL_ASCII (if I
remember right).
...
Many thanks for all your help testing. It really has helped me enormously to
have testing on so many different machines -- often there are subtle
differences, and most regressions run fine, but on some version of some OS on
some hardware the regress fails. Because of your testing, I have resolved a
good number of such timing/OS/hardware dependent problems.
Best regards,
Kern

On Tuesday 07 April 2009 02:51:01 Dan Langille wrote:
> Kern Sibbald wrote:
> > Hello packagers,
> >
> > We will be releasing Bacula version 3.0.0 shortly (within a week or two),
> > so it might be a good time to look at packaging it. There are a number
> > of new challenges:
>
> One thing I was pleased to see:
>
> 06-Apr 20:48 ducky-dir JobId 0: Warning: Encoding error for database
> "bacula". Wanted SQL_ASCII, got UTF8
Yes, you can than Eric Bollengier for that -- a nice touch to reduce user pain
and support requests for our PostgreSQL users :-)
>
> This will help quite a bit.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kern Sibbald wrote:
> On Sunday 29 March 2009 21:30:14 Dan Langille wrote:
>> Phil Stracchino wrote:
>>> Scott Barninger wrote:
>>>> Kern and I have had some offline discussion previously on this subject.
>>>> The current RPM build offers 2 options, one to place files with LSB
>>>> compliance and a second to place files as Kern has advocated and which
>>>> is how Bacula Systems is delivering binaries.
>>>>
>>>> My 2 cents worth is that packages published by the project on
>>>> sourceforge should respect LSB and distribution (linux or BSD)
>>>> guidelines. The advantages of this approach are:
>>>>
>>>> 1. we don't get emails from people complaining about file placement
>>>> 2. we don't suffer hesitation from people who are strongly in favor of
>>>> LSB 3. it creates a differentiator for Bacula Systems.
>>>>
>>>> On Sunday 29 March 2009 11:03:32 am Dan Langille wrote:
>>>>> Discussion trimed to devel & beta
>>> FWIW, I have *always* used the /opt/bacula layout. It puts the entire
>>> Bacula installation in one place separate from everything else on the
>>> machine, and makes it trivial to (for example) install Bacula on an
>>> otherwise bare disk booted from a CD, then do a full system restore
>>> without overwriting any active files. One could, for instance, boot
>>> from a Knoppix CD and copy /opt/bacula from an NFS share, or mount it
>>> from a USB stick (as we were discussing recently).
>>>
>>> The problem with slavish adherence to things like the LSB is that it
>>> isn't always the best solution for everything.
>>>
>>> "Our corporate policy says we always do this."
>>> "That's fine, but this won't work if you do that."
>>> "But corporate policy says..."
>>>
>>> One size does not fit all. Standards are great, but sometimes you have
>>> to recognize that there are special cases for which the standard is not
>>> the best solution, and that sometimes trying to make them conform to
>>> "the standard" is actively harmful. The trick is to recognize the
>>> occasions upon which applying "the standard" is not appropriate.
>> When it comes to the official port/package/whatever of a given OS, it
>> must adhere to the standards set by that OS. Hence, I can't see the
>> FreeBSD port doing anything other than what it's doing now.
>>
>> I don't think anyone is suggesting otherwise.
>
> Yes, I am suggesting that all distros should use the Bacula recommended
> configuration. We can then automate a lot of nice stuff.
>
>> I do see the benefits in providing a solution which contains a
>> completely self-contained installation of Bacula. I'd welcome someone
>> working on that for FreeBSD.
>>
>> FWIW, in case, if I were recovering a failed box on new hardware, my
>> first step would be installing the OS, then Bacula, and going from there.
>
> Unfortunately, life is generally much more complicated than that -- first, how
> do you recover Bacula? Without your bacula-dir.conf, bacula-sd.conf,
> bacula-fd.conf files, plugins, modifications to scripts such as the
> autochanger, ... you will have problems. The new Bacula proposed
> installation permits very easy restoration of all that.
>
> On my system, the backup of the catalog, *all* bacula files, and a snapshot of
> my hard disk configuration are all done in one simple script -- I don't have
> to worry about missing a file because the install has put files all over the
> place. As I say, it is for each to choose ...
If said scripts use variables for the directories, customizing these to
suit is easier. It is also good practice. If we do that, then the
particular OS can adhere both their users expectations and those of Bacula.
- --
Dan Langille
BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon - The PostgreSQL Conference: http://www.pgcon.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknP5zQACgkQCgsXFM/7nTwOIACg/13QWp+ymjHu+O7FIjw+A1Jd
K0wAnRsQd8CR1/viemj/jXfRbl35id7w
=gfYe
-----END PGP SIGNATURE-----

On Sunday 29 March 2009 21:30:14 Dan Langille wrote:
> Phil Stracchino wrote:
> > Scott Barninger wrote:
> >> Kern and I have had some offline discussion previously on this subject.
> >> The current RPM build offers 2 options, one to place files with LSB
> >> compliance and a second to place files as Kern has advocated and which
> >> is how Bacula Systems is delivering binaries.
> >>
> >> My 2 cents worth is that packages published by the project on
> >> sourceforge should respect LSB and distribution (linux or BSD)
> >> guidelines. The advantages of this approach are:
> >>
> >> 1. we don't get emails from people complaining about file placement
> >> 2. we don't suffer hesitation from people who are strongly in favor of
> >> LSB 3. it creates a differentiator for Bacula Systems.
> >>
> >> On Sunday 29 March 2009 11:03:32 am Dan Langille wrote:
> >>> Discussion trimed to devel & beta
> >
> > FWIW, I have *always* used the /opt/bacula layout. It puts the entire
> > Bacula installation in one place separate from everything else on the
> > machine, and makes it trivial to (for example) install Bacula on an
> > otherwise bare disk booted from a CD, then do a full system restore
> > without overwriting any active files. One could, for instance, boot
> > from a Knoppix CD and copy /opt/bacula from an NFS share, or mount it
> > from a USB stick (as we were discussing recently).
> >
> > The problem with slavish adherence to things like the LSB is that it
> > isn't always the best solution for everything.
> >
> > "Our corporate policy says we always do this."
> > "That's fine, but this won't work if you do that."
> > "But corporate policy says..."
> >
> > One size does not fit all. Standards are great, but sometimes you have
> > to recognize that there are special cases for which the standard is not
> > the best solution, and that sometimes trying to make them conform to
> > "the standard" is actively harmful. The trick is to recognize the
> > occasions upon which applying "the standard" is not appropriate.
>
> When it comes to the official port/package/whatever of a given OS, it
> must adhere to the standards set by that OS. Hence, I can't see the
> FreeBSD port doing anything other than what it's doing now.
>
> I don't think anyone is suggesting otherwise.
Yes, I am suggesting that all distros should use the Bacula recommended
configuration. We can then automate a lot of nice stuff.
>
> I do see the benefits in providing a solution which contains a
> completely self-contained installation of Bacula. I'd welcome someone
> working on that for FreeBSD.
>
> FWIW, in case, if I were recovering a failed box on new hardware, my
> first step would be installing the OS, then Bacula, and going from there.
Unfortunately, life is generally much more complicated than that -- first, how
do you recover Bacula? Without your bacula-dir.conf, bacula-sd.conf,
bacula-fd.conf files, plugins, modifications to scripts such as the
autochanger, ... you will have problems. The new Bacula proposed
installation permits very easy restoration of all that.
On my system, the backup of the catalog, *all* bacula files, and a snapshot of
my hard disk configuration are all done in one simple script -- I don't have
to worry about missing a file because the install has put files all over the
place. As I say, it is for each to choose ...
Regards,
Kern

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Phil Stracchino wrote:
> Scott Barninger wrote:
>> Kern and I have had some offline discussion previously on this subject. The
>> current RPM build offers 2 options, one to place files with LSB compliance
>> and a second to place files as Kern has advocated and which is how Bacula
>> Systems is delivering binaries.
>>
>> My 2 cents worth is that packages published by the project on sourceforge
>> should respect LSB and distribution (linux or BSD) guidelines. The advantages
>> of this approach are:
>>
>> 1. we don't get emails from people complaining about file placement
>> 2. we don't suffer hesitation from people who are strongly in favor of LSB
>> 3. it creates a differentiator for Bacula Systems.
>>
>> On Sunday 29 March 2009 11:03:32 am Dan Langille wrote:
>>> Discussion trimed to devel & beta
>
>
> FWIW, I have *always* used the /opt/bacula layout. It puts the entire
> Bacula installation in one place separate from everything else on the
> machine, and makes it trivial to (for example) install Bacula on an
> otherwise bare disk booted from a CD, then do a full system restore
> without overwriting any active files. One could, for instance, boot
> from a Knoppix CD and copy /opt/bacula from an NFS share, or mount it
> from a USB stick (as we were discussing recently).
>
> The problem with slavish adherence to things like the LSB is that it
> isn't always the best solution for everything.
>
> "Our corporate policy says we always do this."
> "That's fine, but this won't work if you do that."
> "But corporate policy says..."
>
> One size does not fit all. Standards are great, but sometimes you have
> to recognize that there are special cases for which the standard is not
> the best solution, and that sometimes trying to make them conform to
> "the standard" is actively harmful. The trick is to recognize the
> occasions upon which applying "the standard" is not appropriate.
When it comes to the official port/package/whatever of a given OS, it
must adhere to the standards set by that OS. Hence, I can't see the
FreeBSD port doing anything other than what it's doing now.
I don't think anyone is suggesting otherwise.
I do see the benefits in providing a solution which contains a
completely self-contained installation of Bacula. I'd welcome someone
working on that for FreeBSD.
FWIW, in case, if I were recovering a failed box on new hardware, my
first step would be installing the OS, then Bacula, and going from there.
- --
Dan Langille
BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon - The PostgreSQL Conference: http://www.pgcon.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknPzEYACgkQCgsXFM/7nTzXSACgtEDvU0WHEPx1xCUbhvHoESZL
JwgAoO2DrPkVhBtTXkX+LITdaf37yxGu
=fqob
-----END PGP SIGNATURE-----

On Sunday 29 March 2009 19:16:56 Phil Stracchino wrote:
> Scott Barninger wrote:
> > Kern and I have had some offline discussion previously on this subject.
> > The current RPM build offers 2 options, one to place files with LSB
> > compliance and a second to place files as Kern has advocated and which is
> > how Bacula Systems is delivering binaries.
> >
> > My 2 cents worth is that packages published by the project on sourceforge
> > should respect LSB and distribution (linux or BSD) guidelines. The
> > advantages of this approach are:
> >
> > 1. we don't get emails from people complaining about file placement
> > 2. we don't suffer hesitation from people who are strongly in favor of
> > LSB 3. it creates a differentiator for Bacula Systems.
> >
> > On Sunday 29 March 2009 11:03:32 am Dan Langille wrote:
> >> Discussion trimed to devel & beta
>
> FWIW, I have *always* used the /opt/bacula layout. It puts the entire
> Bacula installation in one place separate from everything else on the
> machine, and makes it trivial to (for example) install Bacula on an
> otherwise bare disk booted from a CD, then do a full system restore
> without overwriting any active files. One could, for instance, boot
> from a Knoppix CD and copy /opt/bacula from an NFS share, or mount it
> from a USB stick (as we were discussing recently).
>
> The problem with slavish adherence to things like the LSB is that it
> isn't always the best solution for everything.
>
> "Our corporate policy says we always do this."
> "That's fine, but this won't work if you do that."
> "But corporate policy says..."
>
> One size does not fit all. Standards are great, but sometimes you have
> to recognize that there are special cases for which the standard is not
> the best solution, and that sometimes trying to make them conform to
> "the standard" is actively harmful. The trick is to recognize the
> occasions upon which applying "the standard" is not appropriate.
Yes, I completely agree with you. If you ever have a disaster (I hope not), I
think you will be better prepared to cope with it.
Packages that spray Bacula files all over the system (IMO) do a disservice to
the users. I pointed this out to the Ubuntu gurus, and their response was
that /opt was for optional packages and since Bacula is part of our "system"
that we ship, it is not appropriate to put it there.
I think it is a mistake (possibly a big one) to spray the files of a system
backup program all over your system, but then I'm not going to dictate to
anyone ...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Discussion trimed to devel & beta
One purpose of this email is to document how the FreeBSD port differs
and where work is required.
Kern Sibbald wrote:
> 7. I *strongly* recommend that you use the following file placement. This
> does not agree with the LSB, but it does make it possible for the user to
> much easier do a disaster recovery. This kind of configuration is commonly
> used on Solaris and is also used on Linux. This is now the official Bacula
> recommendation -- it may take a bit more time to update our documentation.
FreeBSD has a well defined layout which tells us where particular types
of files should go:
http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sektion=0&manpath=FreeBSD+7.1-RELEASE&format=html
or http://tinyurl.com/manhier
I imagine other OS may have their own constraints.
Below, I have tried to highlight the FreeBSD directories.
>
>
> ./configure \
> --sbindir=/opt/bacula \
/usr/local/sbin
> --sysconfdir=/opt/bacula \
/usr/local/etc
> --libdir=/opt/bacula \
I think that's /usr/lib
> --docdir=/opt/bacula/doc \
> --htmldir=/opt/bacula/html \
Pretty sure both would be:
/usr/local/share/doc/bacula
FreeBSD installs the docs via sysutils/bacula-docs
man pages go to /usr/local/man
> --with-pid-dir=/opt/bacula/working \
/var/run/bacula*.pid
> --with-subsys-dir=/opt/bacula/working \
> --with-working-dir=/opt/bacula/working \
both /var/db/bacula I think
> --with-scriptdir=/opt/bacula/scripts \
/usr/local/share/bacula
> --with-plugindir=/opt/bacula/plugins \
I don't know.
> --enable-smartalloc \
we set this
> --enable-bat \
And we have sysutils/bacula-bat to install this
> --without-qwt \
At present, if bat is enabled, we set --with-qwt
> --enable-batch-insert \
set
> --with-openssl \
That is an option which can be set at install time.
> --with-dump-email=root@... \
> --with-job-email=root@... \
The FreeBSD port sets neither of those. Work is required.
> --with-tcp-wrappers \
set
> --with-db-name=bacula \
> --with-db-user=bacula \
The FreeBSD port sets neither of those. Work is required.
> --with-baseport=9101 \
Not set.
> # --with-mysql
> # or
> # --with-postgresql
FreeBSD offers SQLite2/3, MySQL, and PostgreSQL.
- --
Dan Langille
BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon - The PostgreSQL Conference: http://www.pgcon.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknPjcQACgkQCgsXFM/7nTxuhwCg3iE2e9EaqZNbNbI9x5igakDK
4J4An1mLN9+OoiDV8DE63z3L2fgQ2wg1
=gSLa
-----END PGP SIGNATURE-----

Hello packagers,
We will be releasing Bacula version 3.0.0 shortly (within a week or two), so
it might be a good time to look at packaging it. There are a number of new
challenges:
1. Lots of new files added to the "make install"
- bat help files
- typical doc type release files (technotes, release notes, License, ...)
- shared object files
- the bacula script that is installed in the scripts dir is now also
installed in the sysbindir
- plugins are installed in the plugins directory
2. There are a number of new ./configure options:
. --docdir (default=/usr/share/doc/bacula-VERSION)
where VERSION is something like 3.0.0 the release
technotes, LICENSE, ... go here.
. --htmldir (default=/usr/share/doc/bacula-VERSION/html)
the bat .html help files go here
. --disable-libtool if you do not want shared objects
. --libdir= where shared objects go (default=/usr/lib)
. --with-plugindir=xxx
3. There are most likely (unfortunately) other packaging considerations that I
have not thought of ...
4. The LICENSE file has been changed.
5. The code in this version of Bacula is now license clean, which means that
there should no longer be any license incompatibilities between the Bacula
code and OpenSSL.
6. The following components will still build but they are deprecated:
- the gnome console (use bat instead)
- sqlite version 2
- bwx-console (it is still used on Win32, but will be removed when we have
bat working there).
7. I *strongly* recommend that you use the following file placement. This
does not agree with the LSB, but it does make it possible for the user to
much easier do a disaster recovery. This kind of configuration is commonly
used on Solaris and is also used on Linux. This is now the official Bacula
recommendation -- it may take a bit more time to update our documentation.
./configure \
--sbindir=/opt/bacula \
--sysconfdir=/opt/bacula \
--libdir=/opt/bacula \
--docdir=/opt/bacula/doc \
--htmldir=/opt/bacula/html \
--with-pid-dir=/opt/bacula/working \
--with-subsys-dir=/opt/bacula/working \
--with-working-dir=/opt/bacula/working \
--with-scriptdir=/opt/bacula/scripts \
--with-plugindir=/opt/bacula/plugins \
--enable-smartalloc \
--enable-bat \
--without-qwt \
--enable-batch-insert \
--with-openssl \
--with-dump-email=root@... \
--with-job-email=root@... \
--with-tcp-wrappers \
--with-db-name=bacula \
--with-db-user=bacula \
--with-baseport=9101 \
# --with-mysql
# or
# --with-postgresql
Best regards,
Kern

Hello,
The code for the database format change, which I mentioned in my previous
email today, is now committed to the SVN.
Bacula can now (by default) keep track of more than 4 billion File
records! :-)
Best regards,
Kern