On 4/25/2013 9:17 AM, John Drescher wrote:
>> Ping? No suggestions? Should I report this to a different group or
>> submit a bug report?
>>
> I am not sure if what you described was a bug. Did your distro say the
> bacula packages were for mysql but had instead been enabled to use
> postgresql (which should be preferred for larger networks). If it is a
> bug I would discuss that with your distribution.
>
> John
>
Hi John, (I guess you wanted me to reply directly to you also, as well
as the bacula-users newsgroup)
I don't know whether this is a distro bug or a bacula configuration bug
and that is what I am trying to find out. As I said, the bacula packages
I installed were already configured for mysql. I know that when the code
is compiled, and the scripts built, one is suppose to use the .configure
parameters to build bacula to use a particular database type. I presume
the openSuSE distro builders did exactly that, and for the most part
that did apparently work fine. But for JUST the make_catalog_backup
script I encountered a failure because a default database type was HARD
CODED in that script to use postgresql. I know that a lot of times
scripts are built from templates, and if the make_catalog_script is
being built from a template then I would argue that this is more likely
a bacula bug and not a distro bug. I would imagine that the default
database type assignment, INSIDE the make_catalog_script file, should
have been hard coded to set it to 'mysql' since that is what the bacula
files were configured to use when they were built.
However, this is may be more nuanced than a simple change in
make_catalog_backup, for the hardcoded default database type assignment,
should/would fix. The database type is also passed in to the
make_catalog_backup script as a parameter (the 5th parameter). If the
make_catalog_backup script does not recognize the database type passed
in as a parameter, then it defaults to using the database type that is
hardcoded to be used instead. Since the openSuSE distro has switched to
using MariaDB instead of MySQL as the supported database, I am wondering
if that changeover may be breaking the make_catalog_backup script,
PERHAPS (and this is a total but educated guess on my part) by passing
in 'mariadb' instead of 'mysql' as the database type parameter? If so,
then the bug could belong to either bacula or the distro, I simply do
not know since I do not know from where this make_catalog_backup script
is actually called, and therefore I don't know what is being passed in
as the value of this particular parameter.
This problem could be showing that bacula needs to be enhanced to
support MariaDB in general, which puts this problem in a whole new
frame, and if so I will make the request and just live with the hack I
made to make_catalog_backup script to get it working, for now.
I really do not have the time to go dig into the make files, build
scripts, and bacula code to figure out where and how this problem
arises. I figured by asking on a support group for bacula, I stood a
better chance of reaching someone who is familiar with how bacula gets
built, if/when/how scripts are constructed, and could take a deep look
at the internal code to determine how this failure may have occurred.
Please take a look at the script for make_catalog_backup in order to
grok what I am referring to, about how the database type assignment is
being made/used within that script.
Marc...
--
"The Truth is out there" - Spooky
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
