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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users