Re: [Bacula-users] bconsole can't talk to bacula-dir

[Kern Sibbald]

  
  
I have not heard of this on Debian, but
  it is a problem on Ubuntu and in their bugzilla database.  I
  suspect that even though Ubuntu takes a number of Debian packages,
  they probably add some different linking options.
  
  On 10/02/2016 01:41 AM, Sven Hartge wrote:


  On 01.10.2016 16:51, Hankins, Jonathan wrote:


  
It seems weird that the bacula package in Debian and Ubuntu, et al, is
broken and no one has noticed (checked Debian bug database). I know
Debian has been on 5.x in the stable release for years (still is). It's
possible that 7.0.5 got packaged for their testing release and maybe
Ubuntu xenial picked it up and thus Mint 18. My guess is most folks
using bacula on a Debian distro are on Debian stable, and not Ubuntu or
mint (workstation oriented releases...if anything, may be using
bacula-fd) and thus no one has noticed. I'll do a little digging and
talk to the person who packages bacula for Debian and see if I figure it
out.

  
  
I don't know about Bacula being broken on Debian.

I've been using Bacula at work on Debian since version 1.34 back in 2004
and had it never not work. Right now I am up to 7.4.3 on Jessie from
backports, running backups for about 250 systems.

Privately I run in Debian Unstable, backuping 10 systems to disk and
tape. Again, never experienced the problems you have.

If Bacula was unusable and broken on Debian, there would be bug reports
in the BTS.

Grüße,
Sven.


  
  
  
  --
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
  
  
  
  ___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users




  


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] bconsole can't talk to bacula-dir

[Kern Sibbald]

Hello,

When one uses the  -Bsymbolic_functions link option, the effect on 
Bacula is that the default values will not in all cases be set 
correctly.  The exact mechanism is a bit complicated but I think it 
applies mostly to the Director.  The "workaround" for this problem 
(requiring no rebuilding) is to explicitly set the needed default 
values.  In the case of bconsole, the Director's "Maximum Console 
Connections" is by fault set to 20, but with the silly fiddling that the 
linker does to the source code with that option on, it sets it to zero, 
and you see the results (the error message could probably be improved).

So to make bconsole work in the Director's Director resource set:

  Maximum Console Connections = 20

or what ever value you want (I recommend at least 5 in case you get 
zombies).

Best regards,
Kern


On 10/02/2016 01:06 AM, Jan Martin wrote:
> Thanks to Kern, John, and Josh,
>
> It seems I am not crazy after all :).  So the current release version
> from Mint 18 seems to be compiled with a link switch
> -Bsymbolic_functions, which makes it not work.  The version lines for my
> bacula-dir and bconsole:
>
> trinity% sudo /usr/sbin/bacula-dir -?
> Copyright (C) 2000-2014 Free Software Foundation Europe e.V.
>
> Version: 7.0.5 (28 July 2014)
>
> trinity% bconsole -?
> Copyright (C) 2000-2014 Free Software Foundation Europe e.V.
>
> Version: 7.0.5 (28 July 2014) x86_64-pc-linux-gnu ubuntu 16.04
>
> suggest that they were compiled two years ago, perhaps before Kern
> became involved in the process?  It also suggests that bconsole at
> least, was from the ubuntu distribution 16.04.
>
> I'm a little unclear about how software updates flow between Debian,
> Ubuntu, and Mint - is there a way to get the Mint 18 packager to
> recompile the package, or does he/she need to just get a later 16.04
> update which is correctly compiled?  Is there something I can do to help?
>
> Overall, thanks very much guys!
>
> -Jan
>
>
> On 10/01/2016 08:47 AM, Kern Sibbald wrote:
>> I cannot say for sure about Debian, but for Ubuntu there are/were bug
>> reports open.  All have been
>> resolved by the packagers with my input.  What happened with Ubuntu is
>> that they simply
>> packaged it and released it without testing (surely due to lack of
>> time).  This meant that Bacula
>> failed out of the box -- at least this is the case for their latest
>> release.  I must say that in
>> general Ubuntu keeps up pretty well with the Bacula releases, and now
>> they know how to
>> run the Bacula regression tests, so it is likely that future releases
>> will be better.
>>
>> Best regards,
>> Kern
>>
>> On 10/01/2016 04:51 PM, Hankins, Jonathan wrote:
>>> It seems weird that the bacula package in Debian and Ubuntu, et al, is
>>> broken and no one has noticed (checked Debian bug database). I know
>>> Debian has been on 5.x in the stable release for years (still is).
>>> It's possible that 7.0.5 got packaged for their testing release and
>>> maybe Ubuntu xenial picked it up and thus Mint 18. My guess is most
>>> folks using bacula on a Debian distro are on Debian stable, and not
>>> Ubuntu or mint (workstation oriented releases...if anything, may be
>>> using bacula-fd) and thus no one has noticed. I'll do a little digging
>>> and talk to the person who packages bacula for Debian and see if I
>>> figure it out.
>>>
>>> Thanks for the insight about the known compiler issues!
>>>
>>> -Jonathan Hankins
>>>
>>>
>>> On Sat, Oct 1, 2016, 7:57 AM Kern Sibbald >> > wrote:
>>>
>>>  Hello Josh,
>>>
>>>  Yes, if you build either with -D fortify-source=2 or link with
>>>  -Bsymbolic-functions, Bacula will fail.  It is best
>>>  to stick with the Bacula recommended build options, which is what
>>>  you are using.
>>>
>>>  Also if you have a Bacula version less that 7.4.3 and you build
>>>  with GNU C++ 6.0 or greater,
>>>  Bacula will not work.  This problem is fixed in 7.4.3 and greater,
>>>  but the guys committing to
>>>  C++ have lost all common sense of the basic function of the C++
>>>  compiler that is to correctly
>>>  compile the source code written by the author.  On multiple
>>>  occasions, they now simply elide (drop
>>>  or delete) your source code.  Consequently, it is likely that with
>>>  new C++ compiler we will
>>>  run into additional problems, unless we can find a C++ compiler
>>>  that respects what the programmer
>>>  writes.  It is the user's responsibility (or problem) if he/she
>>>  adds options that the project
>>>  does not use (and often warns against), but when you have rogue
>>>  C++ compiler writers, life
>>>  gets much more complicated.
>>>
>>>  Best regards,
>>>  Kern
>>>
>>>  On 10/01/2016 02:11 PM, Josh Fisher wrote:
  On 10/1/2016 2:44 AM, Hankins, Jonathan wrote:
>  So I've narrowed it down. If I build from Debian's patched
>  source, 

Re: [Bacula-users] bconsole can't talk to bacula-dir

[Sven Hartge]

On 01.10.2016 16:51, Hankins, Jonathan wrote:

> It seems weird that the bacula package in Debian and Ubuntu, et al, is
> broken and no one has noticed (checked Debian bug database). I know
> Debian has been on 5.x in the stable release for years (still is). It's
> possible that 7.0.5 got packaged for their testing release and maybe
> Ubuntu xenial picked it up and thus Mint 18. My guess is most folks
> using bacula on a Debian distro are on Debian stable, and not Ubuntu or
> mint (workstation oriented releases...if anything, may be using
> bacula-fd) and thus no one has noticed. I'll do a little digging and
> talk to the person who packages bacula for Debian and see if I figure it
> out.

I don't know about Bacula being broken on Debian.

I've been using Bacula at work on Debian since version 1.34 back in 2004
and had it never not work. Right now I am up to 7.4.3 on Jessie from
backports, running backups for about 250 systems.

Privately I run in Debian Unstable, backuping 10 systems to disk and
tape. Again, never experienced the problems you have.

If Bacula was unusable and broken on Debian, there would be bug reports
in the BTS.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] bconsole can't talk to bacula-dir

[Jan Martin]

Thanks to Kern, John, and Josh,

It seems I am not crazy after all :).  So the current release version 
from Mint 18 seems to be compiled with a link switch 
-Bsymbolic_functions, which makes it not work.  The version lines for my 
bacula-dir and bconsole:

trinity% sudo /usr/sbin/bacula-dir -?
Copyright (C) 2000-2014 Free Software Foundation Europe e.V.

Version: 7.0.5 (28 July 2014)

trinity% bconsole -?
Copyright (C) 2000-2014 Free Software Foundation Europe e.V.

Version: 7.0.5 (28 July 2014) x86_64-pc-linux-gnu ubuntu 16.04

suggest that they were compiled two years ago, perhaps before Kern 
became involved in the process?  It also suggests that bconsole at 
least, was from the ubuntu distribution 16.04.

I'm a little unclear about how software updates flow between Debian, 
Ubuntu, and Mint - is there a way to get the Mint 18 packager to 
recompile the package, or does he/she need to just get a later 16.04 
update which is correctly compiled?  Is there something I can do to help?

Overall, thanks very much guys!

-Jan


On 10/01/2016 08:47 AM, Kern Sibbald wrote:
> I cannot say for sure about Debian, but for Ubuntu there are/were bug
> reports open.  All have been
> resolved by the packagers with my input.  What happened with Ubuntu is
> that they simply
> packaged it and released it without testing (surely due to lack of
> time).  This meant that Bacula
> failed out of the box -- at least this is the case for their latest
> release.  I must say that in
> general Ubuntu keeps up pretty well with the Bacula releases, and now
> they know how to
> run the Bacula regression tests, so it is likely that future releases
> will be better.
>
> Best regards,
> Kern
>
> On 10/01/2016 04:51 PM, Hankins, Jonathan wrote:
>>
>> It seems weird that the bacula package in Debian and Ubuntu, et al, is
>> broken and no one has noticed (checked Debian bug database). I know
>> Debian has been on 5.x in the stable release for years (still is).
>> It's possible that 7.0.5 got packaged for their testing release and
>> maybe Ubuntu xenial picked it up and thus Mint 18. My guess is most
>> folks using bacula on a Debian distro are on Debian stable, and not
>> Ubuntu or mint (workstation oriented releases...if anything, may be
>> using bacula-fd) and thus no one has noticed. I'll do a little digging
>> and talk to the person who packages bacula for Debian and see if I
>> figure it out.
>>
>> Thanks for the insight about the known compiler issues!
>>
>> -Jonathan Hankins
>>
>>
>> On Sat, Oct 1, 2016, 7:57 AM Kern Sibbald > > wrote:
>>
>> Hello Josh,
>>
>> Yes, if you build either with -D fortify-source=2 or link with
>> -Bsymbolic-functions, Bacula will fail.  It is best
>> to stick with the Bacula recommended build options, which is what
>> you are using.
>>
>> Also if you have a Bacula version less that 7.4.3 and you build
>> with GNU C++ 6.0 or greater,
>> Bacula will not work.  This problem is fixed in 7.4.3 and greater,
>> but the guys committing to
>> C++ have lost all common sense of the basic function of the C++
>> compiler that is to correctly
>> compile the source code written by the author.  On multiple
>> occasions, they now simply elide (drop
>> or delete) your source code.  Consequently, it is likely that with
>> new C++ compiler we will
>> run into additional problems, unless we can find a C++ compiler
>> that respects what the programmer
>> writes.  It is the user's responsibility (or problem) if he/she
>> adds options that the project
>> does not use (and often warns against), but when you have rogue
>> C++ compiler writers, life
>> gets much more complicated.
>>
>> Best regards,
>> Kern
>>
>> On 10/01/2016 02:11 PM, Josh Fisher wrote:
>>>
>>> On 10/1/2016 2:44 AM, Hankins, Jonathan wrote:
 So I've narrowed it down. If I build from Debian's patched
 source, but run ./configure myself, my flags in config.out look
 like:

 Compiler flags:   -g -O2 -Wall -fno-strict-aliasing
 -fno-exceptions -fno-rtti
 Linker flags:

 However, if I build using debian's rules file, my flags in
 config.out look like:

 Compiler flags:   -g -O2 -fstack-protector-strong
 -Wformat -Werror=format-security -fno-strict-aliasing
 -fno-exceptions -fno-rtti -fno-strict-aliasing -fno-exceptions
 -fno-rtti
 Linker flags: -Wl,-Bsymbolic-functions -Wl,-z,relro

>>>
>>> Years ago I ran into a situation with building Bacula RPMS when
>>> RedHat started adding -D fortify-source to CFLAGS by default.
>>> This would cause 'buffer overflow detected' errors even though
>>> what Bacula was doing in the code was perfectly safe. It just
>>> didn't match what GCC's detection code expected. The answer was
>>> to override RedHat's RPM macro 

[Bacula-users] Virtual autochanger

[Timo Neuvonen]

After using Bacula for close to a decade with a tape autochanger, I'm 
slightly lost with ideas related to disk-based backup I'm now trying to 
implement.

Now  I have a fersh test install of Bacula 7.0.5, on CentOS 7. Bacula comes 
from EPEL repo.


The supplied example conf files define a "virtual autochanger", that refers 
to two "storage devices" that both actually write to same directory (/tmp in 
the example).

While wondering the need for this arrangement, I've figured out that this 
may be to help simultaneous backup/restore jobs run smoothly. However, in my 
relatively small environment it makes things look complicated if I define 
every storage this way.

Is the suggested way of using a virtual autochanger a must to make things 
work at all, or is it a way how to avoid problems in a big environment where 
may be a lot of simultaneous backup and restore jobs? I have about 5 servers 
to back up, I'll have the backups running in the nighttime, probably not 
concurrently at all. If and when there will be a need for a restore job, it 
will be a single restore run in the daytime. So no more than a single job at 
a time.

Will there be any problem in this case, if I try to simplify the conf files 
and drop away the "autochanger" and one of the two "storage devices" it 
refers to, and just had a single "storage device" per each media type?


(My goal is to use 2-3 media types, all disks, but disks will be located in 
physically different locations to increase fire/vandalism safety, besides 
disk faults. Since every media type will require a separate storage 
definition, the number of virtual autochanger definitions would multiply 
correspondingly...)


Regards,

Timo 



--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] bconsole can't talk to bacula-dir

[Kern Sibbald]

  
  
I cannot say for sure about Debian, but
  for Ubuntu there are/were bug reports open.  All have been
  resolved by the packagers with my input.  What happened with
  Ubuntu is that they simply
  packaged it and released it without testing (surely due to lack of
  time).  This meant that Bacula
  failed out of the box -- at least this is the case for their
  latest release.  I must say that in
  general Ubuntu keeps up pretty well with the Bacula releases, and
  now they know how to 
  run the Bacula regression tests, so it is likely that future
  releases will be better. 
  
  Best regards,
  Kern
  
  On 10/01/2016 04:51 PM, Hankins, Jonathan wrote:


  It seems weird that the bacula package in Debian and
Ubuntu, et al, is broken and no one has noticed (checked Debian
bug database). I know Debian has been on 5.x in the stable
release for years (still is). It's possible that 7.0.5 got
packaged for their testing release and maybe Ubuntu xenial
picked it up and thus Mint 18. My guess is most folks using
bacula on a Debian distro are on Debian stable, and not Ubuntu
or mint (workstation oriented releases...if anything, may be
using bacula-fd) and thus no one has noticed. I'll do a little
digging and talk to the person who packages bacula for Debian
and see if I figure it out.
  Thanks for the insight about the known compiler
issues!
  -Jonathan Hankins 
  
  
On Sat, Oct 1, 2016, 7:57 AM Kern Sibbald 
  wrote:


  
Hello
  Josh,
  
  Yes, if you build either with -D fortify-source=2 or link
  with -Bsymbolic-functions,
Bacula will fail.  It is best
to stick with the Bacula recommended build options,
which is what you are using.

Also if you have a Bacula version less that 7.4.3 and
you build with GNU C++ 6.0 or greater,
Bacula will not work.  This problem is fixed in 7.4.3
and greater, but the guys committing to
C++ have lost all common sense of the basic function of
the C++ compiler that is to correctly
compile the source code written by the author.  On
multiple occasions, they now simply elide (drop
or delete) your source code.  Consequently, it is likely
that with new C++ compiler we will 
run into additional problems, unless we can find a C++
compiler that respects what the programmer
writes.  It is the user's responsibility (or problem) if
he/she adds options that the project
does not use (and often warns against), but when you
have rogue C++ compiler writers, life 
gets much more complicated.

Best regards,
Kern
  
  
  

  On 10/01/2016 02:11 PM, Josh Fisher wrote:

  
  
 
  On 10/1/2016 2:44 AM, Hankins, Jonathan
wrote:
  
  
So I've narrowed it
  down. If I build from Debian's patched source, but run
  ./configure myself, my flags in config.out look like:
  
  
  
Compiler flags:           -g
-O2 -Wall -fno-strict-aliasing -fno-exceptions
-fno-rtti
Linker flags:
  
  
  
  However, if I build using
debian's rules file, my flags in config.out look
like:
  
  
  Compiler flags:           -g -O2
  -fstack-protector-strong -Wformat
  -Werror=format-security -fno-strict-aliasing
  -fno-exceptions -fno-rtti -fno-strict-aliasing
  -fno-exceptions -fno-rtti

  
Linker flags:            
-Wl,-Bsymbolic-functions -Wl,-z,relro
  
  


  
  
  Years ago I ran into a situation with building Bacula RPMS
  when RedHat started adding -D fortify-source to CFLAGS by
  default. This would cause 'buffer overflow detected'
  errors even though what Bacula was doing in the code was
  perfectly safe. It just didn't match what GCC's detection
  code 

Re: [Bacula-users] bconsole can't talk to bacula-dir

[Hankins, Jonathan]

It seems weird that the bacula package in Debian and Ubuntu, et al, is
broken and no one has noticed (checked Debian bug database). I know Debian
has been on 5.x in the stable release for years (still is). It's possible
that 7.0.5 got packaged for their testing release and maybe Ubuntu xenial
picked it up and thus Mint 18. My guess is most folks using bacula on a
Debian distro are on Debian stable, and not Ubuntu or mint (workstation
oriented releases...if anything, may be using bacula-fd) and thus no one
has noticed. I'll do a little digging and talk to the person who packages
bacula for Debian and see if I figure it out.

Thanks for the insight about the known compiler issues!

-Jonathan Hankins

On Sat, Oct 1, 2016, 7:57 AM Kern Sibbald  wrote:

> Hello Josh,
>
> Yes, if you build either with -D fortify-source=2 or link with 
> -Bsymbolic-functions,
> Bacula will fail.  It is best
> to stick with the Bacula recommended build options, which is what you are
> using.
>
> Also if you have a Bacula version less that 7.4.3 and you build with GNU
> C++ 6.0 or greater,
> Bacula will not work.  This problem is fixed in 7.4.3 and greater, but the
> guys committing to
> C++ have lost all common sense of the basic function of the C++ compiler
> that is to correctly
> compile the source code written by the author.  On multiple occasions,
> they now simply elide (drop
> or delete) your source code.  Consequently, it is likely that with new C++
> compiler we will
> run into additional problems, unless we can find a C++ compiler that
> respects what the programmer
> writes.  It is the user's responsibility (or problem) if he/she adds
> options that the project
> does not use (and often warns against), but when you have rogue C++
> compiler writers, life
> gets much more complicated.
>
> Best regards,
> Kern
>
> On 10/01/2016 02:11 PM, Josh Fisher wrote:
>
>
> On 10/1/2016 2:44 AM, Hankins, Jonathan wrote:
>
> So I've narrowed it down. If I build from Debian's patched source, but run
> ./configure myself, my flags in config.out look like:
>
> Compiler flags:   -g -O2 -Wall -fno-strict-aliasing
> -fno-exceptions -fno-rtti
> Linker flags:
>
> However, if I build using debian's rules file, my flags in config.out look
> like:
>
> Compiler flags:   -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -fno-strict-aliasing -fno-exceptions -fno-rtti
> -fno-strict-aliasing -fno-exceptions -fno-rtti
> Linker flags: -Wl,-Bsymbolic-functions -Wl,-z,relro
>
>
> Years ago I ran into a situation with building Bacula RPMS when RedHat
> started adding -D fortify-source to CFLAGS by default. This would cause
> 'buffer overflow detected' errors even though what Bacula was doing in the
> code was perfectly safe. It just didn't match what GCC's detection code
> expected. The answer was to override RedHat's RPM macro additions with
> user-defined macros and build using the CLFAGS that Bacula's configure
> creates. I'm not so familiar with Debian packaging, but I'm sure there must
> be a way to override the default rules so that Bacula can be built with a
> proper CFLAGS.
>
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
>
> ___
> Bacula-users mailing 
> listBacula-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bacula-users
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>

-- 
This e-mail is intended only for the recipient and may contain confidential 
or proprietary information. If you are not the intended recipient, the 
review, distribution, duplication or retention of this message and its 
attachments is prohibited. Please notify the sender of this error 
immediately by reply e-mail, and permanently delete this message and its 
attachments in any form in which they may have been preserved.
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] bconsole can't talk to bacula-dir

[Kern Sibbald]

  
  
Hello Josh,
  
  Yes, if you build either with -D fortify-source=2 or link with -Bsymbolic-functions, Bacula will
fail.  It is best
to stick with the Bacula recommended build options, which is
what you are using.

Also if you have a Bacula version less that 7.4.3 and you build
with GNU C++ 6.0 or greater,
Bacula will not work.  This problem is fixed in 7.4.3 and
greater, but the guys committing to
C++ have lost all common sense of the basic function of the C++
compiler that is to correctly
compile the source code written by the author.  On multiple
occasions, they now simply elide (drop
or delete) your source code.  Consequently, it is likely that
with new C++ compiler we will 
run into additional problems, unless we can find a C++ compiler
that respects what the programmer
writes.  It is the user's responsibility (or problem) if he/she
adds options that the project
does not use (and often warns against), but when you have rogue
C++ compiler writers, life 
gets much more complicated.

Best regards,
Kern
  
  On 10/01/2016 02:11 PM, Josh Fisher wrote:


  
  
  On 10/1/2016 2:44 AM, Hankins,
Jonathan wrote:
  
  
So I've narrowed it down. If I build from
  Debian's patched source, but run ./configure myself, my flags
  in config.out look like:
  
  
  
Compiler flags:           -g -O2
-Wall -fno-strict-aliasing -fno-exceptions -fno-rtti
Linker flags:
  
  
  
  However, if I build using debian's rules file, my flags
in config.out look like:
  
  
  Compiler flags:           -g -O2
  -fstack-protector-strong -Wformat -Werror=format-security
  -fno-strict-aliasing -fno-exceptions -fno-rtti
  -fno-strict-aliasing -fno-exceptions -fno-rtti

  
Linker flags:            
-Wl,-Bsymbolic-functions -Wl,-z,relro
  
  


  
  
  Years ago I ran into a situation with building Bacula RPMS when
  RedHat started adding -D fortify-source to CFLAGS by default. This
  would cause 'buffer overflow detected' errors even though what
  Bacula was doing in the code was perfectly safe. It just didn't
  match what GCC's detection code expected. The answer was to
  override RedHat's RPM macro additions with user-defined macros and
  build using the CLFAGS that Bacula's configure creates. I'm not so
  familiar with Debian packaging, but I'm sure there must be a way
  to override the default rules so that Bacula can be built with a
  proper CFLAGS.
  
  
  
  
  
  --
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
  
  
  
  ___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users




  


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] bconsole can't talk to bacula-dir

[Josh Fisher]

On 10/1/2016 2:44 AM, Hankins, Jonathan wrote:
So I've narrowed it down. If I build from Debian's patched source, but 
run ./configure myself, my flags in config.out look like:


Compiler flags:   -g -O2 -Wall -fno-strict-aliasing 
-fno-exceptions -fno-rtti

Linker flags:

However, if I build using debian's rules file, my flags in config.out 
look like:


Compiler flags:   -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -fno-strict-aliasing -fno-exceptions -fno-rtti 
-fno-strict-aliasing -fno-exceptions -fno-rtti

Linker flags: -Wl,-Bsymbolic-functions -Wl,-z,relro



Years ago I ran into a situation with building Bacula RPMS when RedHat 
started adding -D fortify-source to CFLAGS by default. This would cause 
'buffer overflow detected' errors even though what Bacula was doing in 
the code was perfectly safe. It just didn't match what GCC's detection 
code expected. The answer was to override RedHat's RPM macro additions 
with user-defined macros and build using the CLFAGS that Bacula's 
configure creates. I'm not so familiar with Debian packaging, but I'm 
sure there must be a way to override the default rules so that Bacula 
can be built with a proper CFLAGS.



--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] bacula does not delete OLD files from disk

[Kern Sibbald]

  
  
This is by design to ensure that Bacula
  never destroys good data.  On the other hand, if you run Bacula in
  the manner it was designed to run, it will reuse old volumes.
  
  In newer versions of Bacula, it is possible to tell Bacula to
  truncate volumes when they are purged.
  
  Best regards,
  Kern
  
  On 09/30/2016 10:27 PM, elm.c...@gmail.com wrote:


  
  
  


I have an issue with bacula version 5.2.6 on Debian.
  bacula
  does not delete the physical files from disk after the
  retention period has expired. I have different paths (
  disks) for different bacula jobs. let's say the backup
  location for client X is under drive 1 and the backup
  location for client Y is under drive 2. when the
  the retention period has expired for one of the
  incremental backup of client 1, bacula  marks it purged
  and uses the lable for creating a new incremental backup
  for client Y under disk 2, but it does not delete the OLD
  file from the disk1. 
  

  part
  of my bacula-dir configuration files related to purge:
  
Pool {
  
  
Name =
IncrementalPool
  Pool
Type = Backup
 
Recycle = yes
 
AutoPrune = yes
 
UseVolumeOnce = yes
  Volume Retention = 1 weeks
  
 
Volume Use Duration = 23h
 
}
  

  
  
  
  
  --
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
  
  
  
  ___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users




  


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] bconsole can't talk to bacula-dir

[Hankins, Jonathan]

So I've narrowed it down. If I build from Debian's patched source, but run
./configure myself, my flags in config.out look like:

Compiler flags:   -g -O2 -Wall -fno-strict-aliasing -fno-exceptions
-fno-rtti
Linker flags:

However, if I build using debian's rules file, my flags in config.out look
like:

Compiler flags:   -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -fno-strict-aliasing -fno-exceptions -fno-rtti
-fno-strict-aliasing -fno-exceptions -fno-rtti
Linker flags: -Wl,-Bsymbolic-functions -Wl,-z,relro



So, I grabbed the *FLAGS variables from debian/rules, exported them
manually, and re-ran ./configure myself, and got a bacula-dir that exhibits
the same behavior we are seeing with the Mint (Debian) package version.

export CFLAGS='-g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -fno-strict-aliasing -fno-exceptions -fno-rtti'
export CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2 -fno-strict-aliasing
-fno-exceptions -fno-rtti' # I don't know if this is used?
export LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro'

This is getting beyond my skills to troubleshoot...I could go through a
process of elimination and narrow it down but I don't know if I'd know why
it was causing the problem, even if I found out which flag it was. Maybe
someone who knows something about those compiler flags can point me in the
right direction?

Also, heading to the beach, so I will be out of pocket for a while.

FWIW, I think if you install the Debian source (you have to enable source
in Mint's package manager), edit your debian/rules file and change the
CFLAGS and LDFLAGS lines, I think you will build a working bacula-dir. But
I still don't know why. FWIW, when I was having an ignorant stab at using
gdb to get a backtrace from the Mint bacula-dir, it noted that some of the
functions on the stack were optimized out. I don't know if that would have
been caused by any of the compiler flags above, or if it has any bearing on
our issue.

-Jonathan Hankins

On Sat, Oct 1, 2016 at 12:50 AM Hankins, Jonathan <
jhank...@homewood.k12.al.us> wrote:

> So I built the source package on Mint 18 (it's from Debian upstream) and
> it is still broken. Then, I extracted the original source from the Debian
> package, and didn't apply the debian patches
> (except switch-nonfree-sha1-to-openssl.patch, which I had to do to get it
> to build). I set prefix to /opt/bacula so I could install it without
> stomping on anything, and ran ./configure --with-sqlite3. Built, installed
> and ran /opt/bacula/sbin/bacula-dir -f -c /etc/bacula/bacula-dir.conf (the
> default file from the Mint/Debian package) and it works correctly. So I
> re-built, but this time let dpkg-source apply all of Debian's patches, but
> then manually built with ./configure --with-sqlite3, etc. and it works. So
> it's not Debian's patched.
>
> I will check how Debian runs configure, and see what piece is breaking it.
>
> FWIW, On the non-working Mint binary, strace and gdb show me that bconsole
> connects, writes the greeting message to the socket and then tries to read
> the reply from the dir. The dir hangs in a select() on the socket, and
> eventually the bconsole times out.
>
> -Jonathan Hankins
>
> On Fri, Sep 30, 2016 at 9:01 PM Hankins, Jonathan <
> jhank...@homewood.k12.al.us> wrote:
>
> Jan,
>
> I am assuming you're on the latest Mint (18) -- my Mint 18 workstation
> loaded bacula 7.0.5 when I installed it just now. I am having the same
> issue with the default config, so let me play with it and see what I can
> come up with.
>
> -Jonathan Hankins
>
> On Fri, Sep 30, 2016 at 6:29 PM Jan Martin  wrote:
>
> Hi,
>
> On my system, you are right.  dir runs as bacula:bacula, sd runs as
> bacula:tape, and fd runs as root:root
>
> trinity% bconsole -?
> Copyright (C) 2000-2014 Free Software Foundation Europe e.V.
>
> Version: 7.0.5 (28 July 2014) x86_64-pc-linux-gnu ubuntu 16.04
>
> Usage: bconsole [-s] [-c config_file] [-d debug_level]
> -D select a Director
> -l  list Directors defined
> -cset configuration file to file
> -d  set debug level to 
> -dt print timestamp in debug output
> -n  no conio
> -s  no signals
> -u  set command execution timeout to  seconds
> -t  test - read configuration and exit
> -?  print this message.
> So bconsole is definitely 7.0.5, and there is apparently only one, at
> /usr/sbin/bconsole.  Trying with -d 200 turned on, I get:
>
> trinity% sudo bconsole -d 200
> Connecting to Director localhost:9101
> bconsole: bsock.c:208-0 Current 127.0.0.1:9101 All 127.0.0.1:9101
> bconsole: bsock.c:137-0 who=Director daemon host=localhost port=9101
> bconsole: bsock.c:310-0 OK connected to server  Director daemon
> localhost:9101.
> Director authorization problem.
> Most likely the passwords do not agree.
> If you are using TLS, there may have