bconsole to Bacula Director fails with authorization problem message

The only (debug) message I got from the Director upon an unsuccessful bconsole connection was the one produced in lib/bnet.c:566. So I debugged it and got this backtrace:

#0 init_bsock (jcr=jcr@entry=0x0, sockfd=sockfd@entry=7, who=who@entry=0x7efce66e958b "client",
    host=host@entry=0x7efce32b1320 "127.0.0.1", port=9101, client_addr=client_addr@entry=0x7efce32b0eb0) at bnet.c:565
#1 0x00007efce66b605e in bnet_thread_server (addr_list=addr_list@entry=0x20a65d8, max_clients=0,
    client_wq=client_wq@entry=0x688960 <ua_workq>,
    handle_client_request=handle_client_request@entry=0x4534b0 <handle_UA_client_request(void*)>) at bnet_server.c:222
#2 0x000000000045312c in connect_thread (arg=arg@entry=0x20a65d8) at ua_server.c:69
#3 0x00007efce66e6bdf in lmgr_thread_launcher (x=0x2108498) at lockmgr.c:1091
#4 0x00007efce648966a in start_thread (arg=0x7efce32b2700) at pthread_create.c:333
#5 0x00007efce5e3d01d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

It is strange, that bnet_thread_server() had been called with max_clients=0. In the calling location in dird/ua_server.c:69 "director->MaxConsoleConnect" is used as a parameter. "MaximumConsoleConnections" seems to be the according Director resource configuration variable (bacula-dir.conf) and it was not present in my configuration. While the documentation at http://www.bacula.org/7.0.x-manuals/en/main/Configuring_Director.html#SECTION001520000000000000000 clearly states a default value of 20, bconsole connections suddenly worked after explicitly setting it.

Further problems were an empty scheduled job list and manually started backup jobs just "waiting on max Client jobs". To get Bacula basically working on Xenial it seems, that at least the following configuration variables of bacula-dir.conf need explicit statements:

- In the Director resource:
  MaximumConsoleConnections
- In the Job resources:
  Enabled
- In the Client resources:
  Maximum Concurrent Jobs

Addition:
- In the Job resources:
  Maximum Concurrent Jobs

I spent hours trying to troubleshoot the exact same issue, it wasn't until I found this bug report that everything started working like a charm again.

Thanks Patrick!

Hopefully to help save someone else a bunch of time, I also had to put "Enabled = Yes" in all my jobs, otherwise they wouldn't run on schedule.

Has Ubuntu compiled Bacula in some strange way to cause default values to be incorrect?

Status changed to 'Confirmed' because the bug affects multiple users.

There is some more analysis of this issue in https://bugs.launchpad.net/ubuntu/+source/bacula/+bug/1570923/comments/13 which I think may be helpful.

Thanks guys the change worked for me also.

All that was needed was to add in a line in the "bacula-dir.conf" config file
MaximumConsoleConnections=20

Perhaps the base config file has been upset a little as there is a line which has changed ion previous versions being...
Maximum Concurrent Jobs = 20

This line is stated as having a default of 1 but for some reason its now 20. Perhaps the base updated file should have had two lines...
Maximum Concurrent Jobs = 1
MaximumConsoleConnections = 20

Anyway hope this makes sense as I am new to this sort of thing.

Configurations using these handler, the default value is not correct.(Group A)
store_alist_res
store_bit
store_bool
store_dir
store_int32
store_pint32
store_res
store_size64
store_str
store_time

However , Another configuration using following handlers has correct default value.(Group B)
store_addresses
store_addresses_address
store_addresses_port
store_alist_str
store_label
store_name
store_password
store_speed
store_strname

What's different?
Group A is referenced from dird.c and dird_conf.c.
Group B is referenced from only dird_conf.c.
In dird.c, symbol address is written in the .text segment.
In dird_conf.c, symbol addres is written in the .data segment.

What's problem?
In "/usr/sbin/bacula-dir", Group A are resolved to PLT stub code's address.
In "libbaccfg.so", these address are resolved to true function address.
So, symbol address is different between "bacula-dir" and "libbaccfg.so".

Why some configuration has correct default value?
Group B are placed on relocation table, it will be resolved to true function address at time of dynamic link.
So, these symbol address is same in "bacula-dir" and "libbaccfg.so".

I forget wrote my test environment.
amd64(x86_64)

You might get a different result with other CPU/architecture.

I think, this problem has been appeared by change of compiler or linker.

I trying to work by changing compiler and linker options.
But do not success yet.

After fixing the aforementioned problems I also ran into the problem that if I run backups, bacula refuses to write file-information to the databases. Tested with sqlite and mysql. After running backups, the correct number of files is reported, but only full backups are available due to no files being in the database. The job-information is fine in the database. Running bacula-dir in verbose mode did not throw any noticeable error regarding writing to the db.

Anyone else having similar problems/have a fix?

I found a solution in amd64.

First, add following line into debian/rules.
export DEB_LDFLAGS_MAINT_STRIP = -Wl,-Bsymbolic -Wl,-Bsymbolic-functions

Next, build packages using debuild.

A result binaries work fine and that have correct default values.

I am not yet running Xenial because every machine I tried to update from 14.04 to 16.04 ended up being non-bootable, and on machine, I loaded 16.04 and it destroyed all my Windows partitions :-(

However, the problems you are experiencing seem to be related to some new linking parameters that are not used in upstream development. From the comments from Hiroaki Hashi, it would appear that they are related to stripping the binaries. I recommend trying building Bacula without stripping and without the changed DEB_LDFLAGS_MAINT_STRIP and see if it works. If it does work, then the problem is only happening during stripping, which means that either the stripping is broken, or Bacula code is not compatible with stripping.

The default value of Maximum Connections is 20 and is maintained in the same table that contain the "handler" addresses you mention above.

The comments above at: "Hiroaki Hashi (hashiz) wrote on 2016-05-11:" are very interesting because the configuration tables in the Director are all in <bacula>/src/dir/dird_conf.c. The ones that seem not to work correctly for the default values are in tables that are defined as "static" while the default values that are in non-"static" (referenced in more than one source file) tables seem to work.

Perhaps something that is happening during stripping either .text or .data that is breaking the code. Perhaps stripping does not by default permit addresses that are in the .data section.

Question: If the problem is related to addresses in the .data section, will adding the "const" attribute to the table definitions force them to all be in the .text section?

Hiroaki Hashi's workaround in #11 seems to do the trick, at least for the bconsole authorization problem.

I have the same database problem of Tobias in #10, but with PostgreSQL. It was fixed by the solution in #11.

The symptoms of the problem appeared to me when all my incremental backups started using the same amount of space as my full backups. When using the bconsole 'query' command to list files for a completed job, the results were blank. Attempting to restore failed as well.

I have installed a 16.04 system and built Bacula using the project compile and link options. Everything works perfectly both with and without binary stripping. I conclude from this that the Ubuntu packaging is using different options on the compiles and/or links and/or stripping which prohibit Bacula from directly testing the equality of external subroutine addresses (probably by adding some thunking or other indirect addressing).

Conclusion: eliminate all the non-Bacula compile and/or link options. If you really want to use esoteric options, I recommend running the regression tests on the packaged binaries prior to releasing. Successfully running the regression tests virtually guarantee a good build/package.

Second conclusion: in a future version of Bacula, I will eliminate all code that tests equality of subroutine addresses.

Bacula Project Manager

Kern,

Thank you for chiming in. Your input is very useful.

On Wed, Jun 08, 2016 at 08:12:16AM -0000, Kern Sibbald wrote:
> I have installed a 16.04 system and built Bacula using the project
> compile and link options. Everything works perfectly both with and
> without binary stripping. I conclude from this that the Ubuntu
> packaging is using different options on the compiles and/or links and/or
> stripping which prohibit Bacula from directly testing the equality of
> external subroutine addresses (probably by adding some thunking or other
> indirect addressing).

I wonder if this is related to ASLR, building as PIE or similar?
https://wiki.ubuntu.com/Security/Features has more details. I don't see
anything there that would explain this change in behaviour, but it feels
like it could to me.

> Conclusion: eliminate all the non-Bacula compile and/or link options.
> If you really want to use esoteric options, I recommend running the
> regression tests on the packaged binaries prior to releasing.
> Successfully running the regression tests virtually guarantee a good
> build/package.

We have processes and infrastructure to run tests provided by upstreams.
If the regression tests aren't currently being run, we should fix that.

> Second conclusion: in a future version of Bacula, I will eliminate all
> code that tests equality of subroutine addresses.

Thanks.

Robie

I am happy to pipe in as I would like to see Bacula working reliably everywhere. The regression testing is documented in the Developer's manual if I am not mistaken and is not hard to setup. The tests want to build from source, link, install then run the tests so if you want to run from pre-built binaries (i.e. a deb) please let me know and I will look for the Bacula Systems scripts that do this.

Concerning the current problem: what seems clear to me is that the packaging has added additional build flags that either were not in the previous version 14.04 or what those flags do has changed (e.g. more randomization). ASLR and PIC sound like things that could cause problems. Bacula does not explicitly set either in our binary builds.

Note for packaging: it is better to install all of Bacula in /opt/bacula, which I think is permitted by the LSB. This is because by having it all installed in one directory, it is *far* easier for Bacula to properly back itself up. All distributions that I have looked at spread Bacula components all over the directory structure, which prevents Bacula from easily backing up itself when doing a backup of the catalog. From prior experience with distro packagers, who have rather strict rules to follow, I doubt I will get very far with this, but I wanted you to know.
For example, here is the FileSet that I use for my catalog backup:

# Backup the copy of the catalog
FileSet {
  Name = "CatalogFile"
  Include {
    Options {
       signature=MD5
    }
    File = /opt/bacula/working/bacula.sql # get catalog
    File = /opt/bacula # get Bacula + conf
  }
  Exclude {
     File = /opt/bacula/working # ignore temp files
  }
}

Notice how easy it is to backup all of Bacula. For a disaster recovery, it is *really* nice to have everything all in one backup -- all the Bacula conf files, scripts, binaries, and the catalog backup as well. Not also, the .bsr file is emailed to me every night, so that makes it trivial to find and restore Bacula as it was at any particular backup point.

@eduardotv: why is this Fix Released? As far as I'm aware, it is still a valid and open bug and has not yet been addressed. Please can you explain why you're changing the bug status?

Hello, I have done some backporting and integrating of the suggestion in LP# 1553563 c11.

Please test the 'fixed' version at: https://launchpad.net/~nacc/+archive/ubuntu/bacula, specifically 7.4.1~dfsg-1.1~ppa7 and report back if it resolves the issue in this bug for you.

@Kern,

To clarify, this change:

export DEB_LDFLAGS_MAINT_STRIP = -Wl,-Bsymbolic-functions

  [-Bsymbolic is not passed to the build currently, so omitted in my changes]

has nothing to do with stripping of binaries. It 'strips' the requested LDFLAGS out of the DEBUILD_LDFLAGS (aiui, not much documentation of it). So it seems that the Bacula build can't handle this option to ld:

       -Bsymbolic-functions
           When creating a shared library, bind references to global function
           symbols to the definition within the shared library, if any. This
           option can also be used with the --export-dynamic option, when
           creating a position independent executable, to bind references to
           global function symbols to the definition within the executable.
           This option is only meaningful on ELF platforms which support
           shared libraries and position independent executables.

Given Hiroaki's excellent analysis here and in Bug 1570923, I think this relates to the use of a same-named function in a library that is linked to? Maybe if we also passed --export-dynamic, it would also work, I'm not 100%. I'd like to understand the exact issue better before suggesting we SRU that change.

-Nish

Hello Nish,

Thanks for taking the time to send me a personal note. After more
research, I agree 100% with you that it is not related to stripping the
binaries. I deduce from Hiroaki's analysis that the problem is that the
addresses in the shared object that are exported are modified with the
-Bsymbolic-functions from what Bacula expects. While setting the
default values of directives, Bacula compares addresses of function
pointers. If these function pointers are changed from what Bacula
expects, setting the default value fails. Bacula does not use position
independent executables (at least we do not set it in our LDFLAGS).

In a future version (hopefully the next one), I will identify the
function pointers with a unique index for each function, then instead of
comparing function pointers, I will compare indexes. This will
definitively avoid the problem. Thanks for making the Ubuntu build work
again.

On a different issue:
If you would like, I will be happy to look at your patch for [Bug
1570923] Re: bacula-dir won't start with "undefined symbol: mysql_init",
however, I don't know where to find it.

Best regards,
Kern

On 06/24/2016 03:50 AM, Nish Aravamudan wrote:
> @Kern,
>
> To clarify, this change:
>
> export DEB_LDFLAGS_MAINT_STRIP = -Wl,-Bsymbolic-functions
>
> [-Bsymbolic is not passed to the build currently, so omitted in my
> changes]
>
> has nothing to do with stripping of binaries. It 'strips' the requested
> LDFLAGS out of the DEBUILD_LDFLAGS (aiui, not much documentation of it).
> So it seems that the Bacula build can't handle this option to ld:
>
> -Bsymbolic-functions
> When creating a shared library, bind references to global function
> symbols to the definition within the shared library, if any. This
> option can also be used with the --export-dynamic option, when
> creating a position independent executable, to bind references to
> global function symbols to the definition within the executable.
> This option is only meaningful on ELF platforms which support
> shared libraries and position independent executables.
>
> Given Hiroaki's excellent analysis here and in Bug 1570923, I think this
> relates to the use of a same-named function in a library that is linked
> to? Maybe if we also passed --export-dynamic, it would also work, I'm
> not 100%. I'd like to understand the exact issue better before
> suggesting we SRU that change.
>
> -Nish
>

On 24.06.2016 [06:07:06 -0000], Kern Sibbald wrote:
> Hello Nish,
>
> Thanks for taking the time to send me a personal note. After more
> research, I agree 100% with you that it is not related to stripping the
> binaries. I deduce from Hiroaki's analysis that the problem is that the
> addresses in the shared object that are exported are modified with the
> -Bsymbolic-functions from what Bacula expects. While setting the
> default values of directives, Bacula compares addresses of function
> pointers. If these function pointers are changed from what Bacula
> expects, setting the default value fails. Bacula does not use position
> independent executables (at least we do not set it in our LDFLAGS).

Yep, and Ubuntu uses PIE by default in 16.10 (on some archs), but I'm
not sure it's set in 16.04 based upon the buildlog at
https://launchpadlibrarian.net/267315679/buildlog_ubuntu-xenial-amd64.bacula_7.4.1~dfsg-1.1~ppa7_BUILDING.txt.gz. More details on
PIE in Ubuntu: https://wiki.ubuntu.com/Security/Features#pie.

> In a future version (hopefully the next one), I will identify the
> function pointers with a unique index for each function, then instead of
> comparing function pointers, I will compare indexes. This will
> definitively avoid the problem. Thanks for making the Ubuntu build work
> again.

Yep, that makes sense!

> On a different issue:
> If you would like, I will be happy to look at your patch for [Bug
> 1570923] Re: bacula-dir won't start with "undefined symbol: mysql_init",
> however, I don't know where to find it.

So the PPA build has the following changes, with my commentary in []:

bacula (7.4.1~dfsg-1.1~ppa7) xenial; urgency=medium

  * debian/patches/libmysqlclient_r.patch: Fix bug where MySQL 5.7 is
    improperly linked on Ubuntu 16.04. Closes LP: #1570923.
    [ backport of
http://www.bacula.org/git/cgit.cgi/bacula/commit/?h=Branch-7.4&id=d3196af3e6c9f65b9f0790625a2e844dcb5fd190 ]
  * debian/patches/mysql_install_update.patch: mysql database
    install/update scripts patch. Fixes bug #1901.
    [ backport of
http://www.bacula.org/git/cgit.cgi/bacula/commit/?h=Branch-7.4&id=074419ac0c9dbbde2e4d2f5ccb6d4ca85c6ec8a9 ]
  * debian/patches/disable_mysql_NO_ZERO_DATE.patch: Disable
    NO_ZERO_DATE mode for MySQL table creation.
    [ Without this, I get an error from MySQL 5.7 (strict mode) about
      the CleaningDate field having an invalid default.
--- bacula-7.4.1~dfsg.orig/src/cats/make_mysql_tables.in
+++ bacula-7.4.1~dfsg/src/cats/make_mysql_tables.in
@@ -14,6 +14,8 @@ PATH="$bindir:$PATH"
 db_name=${db_name:-@db_name@}

 if mysql -D ${db_name} $* -f <<END-OF-DATA
+SET SESSION sql_mode = (SELECT REPLACE(@@sql_mode,'NO_ZERO_DATE', ''));
+
 --
 -- Note, we use BLOB rather than TEXT because in MySQL,
 -- BLOBs are identical to TEXT except that BLOB is case
     ]
  * d/rules: do not use -Bsymoblic-functions when linking.
    [ The result from this bug and Hiroaki's analysis ]

 -- Nishanth Aravamudan <email address hidden> Thu, 23 Jun 2016 12:35:56 -0700

I'll clean-up the changelog to ensure the bugs get auto-tagged
appropriately and submit it for SRU.

Many thanks. I will look in detail at the links to the PIE links you
provided to see if anything jumps out at me.

One possible concern in your patch for make_mysql_tables.in:
If the line:

SET SESSION sql_mode = (SELECT REPLACE(@@sql_mode,'NO_ZERO_DATE', ''));

simply sets the NO_ZERO_DATE to NULL rather than 1, all is OK and you
can skip the rest of this paragraph. However, on the off chance that it
tells MySQL not to permit any zero value for a date, then Bacula will
fail. Bacula does not need the default value to be zero, but Bacula
does set a zero value (a valid Unix/Linux value) in a number of the
DATETIME fields. If MySQL either changes the value or fails the SQL
command, Bacula will fail.

In the community version 7.4.1, I edited the make_mysql_tables.in to
remove all the DATETIME default values of 0 which were the cause the
incompatibility. Consequently, if you include my new
make_mysql_tables.in you should not need for the above SET SESSION line.

I'll leave it to you to decide what to do, if anything.

Best regards,
Kern

On 06/24/2016 05:54 PM, Nish Aravamudan wrote:
> On 24.06.2016 [06:07:06 -0000], Kern Sibbald wrote:
>> Hello Nish,
>>
>> Thanks for taking the time to send me a personal note. After more
>> research, I agree 100% with you that it is not related to stripping the
>> binaries. I deduce from Hiroaki's analysis that the problem is that the
>> addresses in the shared object that are exported are modified with the
>> -Bsymbolic-functions from what Bacula expects. While setting the
>> default values of directives, Bacula compares addresses of function
>> pointers. If these function pointers are changed from what Bacula
>> expects, setting the default value fails. Bacula does not use position
>> independent executables (at least we do not set it in our LDFLAGS).
> Yep, and Ubuntu uses PIE by default in 16.10 (on some archs), but I'm
> not sure it's set in 16.04 based upon the buildlog at
> https://launchpadlibrarian.net/267315679/buildlog_ubuntu-xenial-amd64.bacula_7.4.1~dfsg-1.1~ppa7_BUILDING.txt.gz. More details on
> PIE in Ubuntu: https://wiki.ubuntu.com/Security/Features#pie.
>
>> In a future version (hopefully the next one), I will identify the
>> function pointers with a unique index for each function, then instead of
>> comparing function pointers, I will compare indexes. This will
>> definitively avoid the problem. Thanks for making the Ubuntu build work
>> again.
> Yep, that makes sense!
>
>> On a different issue:
>> If you would like, I will be happy to look at your patch for [Bug
>> 1570923] Re: bacula-dir won't start with "undefined symbol: mysql_init",
>> however, I don't know where to find it.
> So the PPA build has the following changes, with my commentary in []:
>
> bacula (7.4.1~dfsg-1.1~ppa7) xenial; urgency=medium
>
> * debian/patches/libmysqlclient_r.patch: Fix bug where MySQL 5.7 is
> improperly linked on Ubuntu 16.04. Closes LP: #1570923.
> [ backport of
> http://www.bacula.org/git/cgit.cgi/bacula/commit/?h=Branch-7.4&id=d3196af3e6c9f65b9f0790625a2e844dcb5fd190 ]
> * debian/patches/mysql_install_update.patch: mysql database
> install/update scripts patch. Fi...

On 24.06.2016 [19:07:53 -0000], Kern Sibbald wrote:
> Many thanks. I will look in detail at the links to the PIE links you
> provided to see if anything jumps out at me.
>
> One possible concern in your patch for make_mysql_tables.in:
> If the line:
>
> SET SESSION sql_mode = (SELECT REPLACE(@@sql_mode,'NO_ZERO_DATE', ''));
>
> simply sets the NO_ZERO_DATE to NULL rather than 1, all is OK and you
> can skip the rest of this paragraph.

My understanding is that it will simply elide "NO_ZERO_DATE" from the
current sql_mode in the session if it is set. That, in turn, in my
reading of the SQL Manual, since strict mode is on, just tells MySQL to
not enforce that DATETIME fields cannot have 0 as a value, which in turn
means it should be allowed, default or otherwise.

> However, on the off chance that it tells MySQL not to permit any zero
> value for a date, then Bacula will fail. Bacula does not need the
> default value to be zero, but Bacula does set a zero value (a valid
> Unix/Linux value) in a number of the DATETIME fields. If MySQL either
> changes the value or fails the SQL command, Bacula will fail.
>
> In the community version 7.4.1, I edited the make_mysql_tables.in to
> remove all the DATETIME default values of 0 which were the cause the
> incompatibility. Consequently, if you include my new
> make_mysql_tables.in you should not need for the above SET SESSION line.

Yep, I saw this. I tested in Yakkety, actually (and made a mistake in my
requests to test so far, folks ended up testing my Yakkety version,
which is still a valid test and needed before we can fix Xenial). In
Yakkety (and Xenial), bacula-director-mysql ends up failing to install
(fresh install):
https://bugs.launchpad.net/ubuntu/+source/bacula/+bug/1591397
https://bugs.launchpad.net/ubuntu/+source/bacula/+bug/1596034

The Yakkety version has your fix included (7.4.1 base), but still
trips the DATETIME issue in my testing.

Please test the potential fix version at:

https://launchpad.net/~nacc/+archive/ubuntu/bacula

Which results in 7.4.1~dfsg-1ubuntu1~ppa1 on yakkety or 7.4.1~dfsg-1.1~ppa8.is.actually.7.0.5+dfsg-4.1~ppa2 on xenial.

Fix is confirmed to work for i386, too. (Tested using a custom PPA build from https://launchpad.net/~markusj/+archive/ubuntu/ppa/)

Hi. I can confirm that the version from ppa:nacc/bacula works correcly on my bacula configuration at Xenial amd64. I've migrated manually my bacula from Debian Wheezy i386 (bacula version 5.2.6).

Hello all,

After reviewing the other open Bacula bugs, I've set up a new PPA with a more normal versioning and (hopefully) fixes to all the issues I know about on 16.04 and 16.10 (and I think handles upgrading from 14.04 to 16.04)

https://launchpad.net/~nacc/+archive/ubuntu/bacula3

16.04: 7.0.5+dfsg-4ubuntu0.1~ppa1
16.10: 7.4.2+dfsg-1ubuntu1~ppa1

Please test these versions and report back, I'd like to see if we can these both sponsored quickly.

7.4.3+dfsg-1 is in 16.10 and does not have this issue.

Hello Patrick, or anyone else affected,

Accepted bacula into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/bacula/7.0.5+dfsg-4ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Tried in the same basic setup as the description (sqlite3). With 7.0.5+dfsg-4build1, bconsole fails to connect with the reported message. With 7.0.5+dfsg-4ubuntu0.1:

# bconsole
Connecting to Director localhost:9101
1000 OK: 1 inspired-eft-dir Version: 7.0.5 (28 July 2014)
Enter a period to cancel a command.
*

Marking v-d.

Version 7.0.5+dfsg-4ubuntu0.1 from -proposed solves the issues of local bacula-console failing to connect to Director for me. It also solves remote bacula-console-qt failing to connect to the same director (without upgrading bacula-console-qt, only the director host has -proposed package).

7.0.5+dfsg-4ubuntu0.1 is working properly for me (using PostgreSQL for the database).

It's October, 16.04 is a LTS, I updated and goodbye backups...
Thanks to the people reporting, analyzing and fixing this, but I wonder: are there still critical bugs that make releasing a working bacula version worse than keeping a non-functioning package in a LTS release?

Yes Roberto, as the Bacula project manager, I find this Ubuntu "bug" quite frustrating. The problem is three fold:

1. Ubuntu builds Bacula with flags that are not recommended by the Bacula project.

2. Ubuntu (at least for Bacula) does not (or did not) test the packages that are build.

3. Once the LTS is made, Ubuntu, at least to me, seems *very* slow at fixing problems and releasing the fixes to the LTS.

The Bacula project will, in the next few months, distribute its own binaries, which are tested prior to release. For those of you who decide to switch to using the project binaries, this kind of problem will then be resolved. The main issue in that case will be for the Bacula project to provide packages for new distro releases in a reasonable time. Maybe the solution is to go back to the good old days of building with static libraries -- i.e. to build binaries that are self contained and will thus run on virtually all versions of a give distro (or even multiple distros).

7.0.5+dfsg-4ubuntu0.1 solves the problem in 16.04 (I've even tested same binaries on 14.04)

@Kern,

I fully understand your frustration. The delay here is that there are multiple bugs, all of which needed verification. The original submitter(s) did not necessarily respond in a timely fashion in those bugs to the -proposed version and this slid down my plate. I went through and verified them myself (not ideal, IMO, but sufficient). So the SRU team should be able to move bacula through now.

It does dawn on me based upon your comments that you might want to consider snap'ing bacula -- then you would control the releases, etc.

Thanks,
Nish

Hello Nish,

As long as you can reproduce the problem yourself, I see no problem with you (or anyone else) finding a fix and when the problem is fixed to release a new version.

I am a bit uncertain what snap'ing bacula means, how to do it, or what the responsibilities are. I assume you mean take the responsibility for Ubuntu Bacula releases. Please clarify what you are suggesting, and I will give you a full response. If you want to do it in this bug report of offline, either are find with me.

Hello,

after the two confirmations of the potential fix to work in i386 and amd64

and the status change to "fix released" I thought, that my feedback would no longer be required. I am sorry, if lack of it delayed this. I can confirm, that it works for me as well. Thanks for the effort of all people involved!!!

Patrick

This bug was fixed in the package bacula - 7.0.5+dfsg-4ubuntu0.1

---------------
bacula (7.0.5+dfsg-4ubuntu0.1) xenial; urgency=medium

  * debian/patches/libmysqlclient_r.patch: Fix bug where MySQL 5.7 is
    improperly linked on Ubuntu 16.04. Closes LP: #1570923.
  * debian/patches/disable_mysql_NO_ZERO_DATE.patch: Disable
    NO_ZERO_DATE mode for MySQL table creation. Closes LP: #1591397,
    LP: #1577858.
  * d/rules: do not use -Bsymoblic-functions when linking. Closes
    LP: #1553563, LP: #1567824.
  * debian/patches/fix_batch_mode.patch: Detect that MySQL 5.7 is thread
    safe and enable batch mode. Closes LP: #1592749.

 -- Nishanth Aravamudan <email address hidden> Fri, 15 Jul 2016 14:34:59 -0700

The verification of the Stable Release Update for bacula has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.