bconsole can't connect to director, using mariadb

[altiris]

Whenever I run "

Code: Select all

/usr/sbin/bconsole

" I get the message "Connecting to Director localhost:9101" for a few seconds and then the terminal goes back to allow me to enter another command. My config files for bacula are correct and the issue seems to be that Bacula is trying to connect to a Postgresql database, but I use maraidb/mysql for the database.

bacula log output

Code: Select all

06-Aug 01:38 bacula-dir JobId 0: Fatal error: Could not open Catalog "MyCatalog", database "bacula".
06-Aug 01:38 bacula-dir JobId 0: Fatal error: postgresql.c:248 Unable to connect to PostgreSQL server. Database=bacula User=bacula
Possible causes: SQL server not running; password incorrect; max_connections exceeded.

As you can see it is using postgresql rather than mysql/mariadb. I ran into an issue similar to this when trying to set up the permissions for bacula user on bacula. I was to use the command "/usr/libexec/bacula/grant_bacula_privileges -u root -p" (which worked with mysql on centos 6) however I kept getting "Granting postgresql privileges
/usr/libexec/bacula/grant_postgresql_privileges: line 14: /usr/bin/psql: No such file or directory
Error creating privileges.:
I instead just granted all permissions to user bacula on database bacula manually with the mysql -u root -p command. There seem to be a lot of bugs that need squashing in CentOS 7, it is new after all but still...

[altiris]

I am bumping this sorry but only because I can't seem to find help elsewhere. Error still persists, I really think this is a bug with mariadb or something but I dont know for sure. Can anyone offer me insight? I have checked to make sure the bconsole password is the same throughout.

[altiris]

So uh, can anyone offer me some solutions or ways to troubleshoot? Thanks.

[millisa]

Stop your bacula services (systemctl stop bacula-dir and systemctl stop bacula-sd should be enough)
Change the bacula catalogue lib to use the mysql shared object:

Code: Select all

su -c 'alternatives --config libbaccats.so'

It'll show:

Code: Select all

There are 3 programs which provide 'libbaccats.so'.

  Selection    Command
-----------------------------------------------
   1           /usr/lib64/libbaccats-mysql.so
   2           /usr/lib64/libbaccats-sqlite3.so
*+ 3           /usr/lib64/libbaccats-postgresql.so

Enter to keep the current selection[+], or type selection number:

(hey look! postgresql is selected by default)

Input '1' and hit enter. Start the storage daemon and then the director back up.
You'll likely need to modify a few of the assorted scripts in /usr/libexec/bacula to account for it being mysql. (they don't appear to be uniformly modified at this point, some will take 'mysql' as an argument, some don't).

[altiris]

Stop your bacula services (systemctl stop bacula-dir and systemctl stop bacula-sd should be enough)
Change the bacula catalogue lib to use the mysql shared object:

Code: Select all

su -c 'alternatives --config libbaccats.so'

It'll show:

Code: Select all

There are 3 programs which provide 'libbaccats.so'.

  Selection    Command
-----------------------------------------------
   1           /usr/lib64/libbaccats-mysql.so
   2           /usr/lib64/libbaccats-sqlite3.so
*+ 3           /usr/lib64/libbaccats-postgresql.so

Enter to keep the current selection[+], or type selection number:

(hey look! postgresql is selected by default)

Input '1' and hit enter. Start the storage daemon and then the director back up.
You'll likely need to modify a few of the assorted scripts in /usr/libexec/bacula to account for it being mysql. (they don't appear to be uniformly modified at this point, some will take 'mysql' as an argument, some don't).

Thank you so much for helping me! I've stopped messing with CentOS 7 for a little while now but I will try this tomorrow and see if it works. As for a question, do you know why postgresql is selected by default over mysql/mariadb? Was this a mistake or a decision by bacula?

[millisa]

Bacula has leaned towards postgresql for a while now. When you get to particularly big backup sets, that have millions and millions of files, the one 'File' table get pretty cumbersome. Even with some good indexes, building the tree for selecting of files/dirs during a restore job can take a very long time. postgresql apparently handles that and the cleanup tasks more efficiently in those situations (I know I saw a good analysis someone did comparing the two somewhere around the 5.0 release, but I can't seem to find the URL). I am pretty sure this was an intentional change by the bacula folks.