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

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

2016-10-02 Thread Kern Sibbald

On 10/02/2016 09:03 PM, Jan Martin wrote:
> Hi,
>
> Well, if not Debian, maybe we can interest Ubuntu in fixing the 7.0.5
> bacula in their 16.04 distribution, since it's an LTS version.  That
> would help those distros that inherit from Ubuntu, like Mint, maybe?
>
> -Jan
>
> On 10/02/2016 09:58 AM, Sven Hartge wrote:
>> On 02.10.2016 09:08, Hankins, Jonathan wrote:
>>
>>> Even though it's fixed in the 7.4.x from Ubuntu (probably in debian
>>> too), if it's indeed broken in debian, I'm going to ask if they can
>>> release an update to their 7.0.5 package in testing, so that people who
>>> track that, or distros that are derived from it, don't get a broken
>>> bacula out of the box.
>> Testing no longer has 7.0.5 (since 2016-06-09), so there is no need to
>> release any fixed package. Any other derivative distribution using 7.0.5
>> will have to fix their package on their own.
If you submitted a bug report, they will probably fix it quickly because 
they already have the fix.
>>
>> 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
>


--
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

2016-10-02 Thread Sven Hartge

Um 12:03 Uhr am 02.10.16 schrieb Jan Martin:

> Well, if not Debian, maybe we can interest Ubuntu in fixing the 7.0.5 
> bacula in their 16.04 distribution, since it's an LTS version.  That 
> would help those distros that inherit from Ubuntu, like Mint, maybe?

No need to do this, there is already a fixed package in proposed-updates 
for Xenial:

https://launchpad.net/ubuntu/+source/bacula/7.0.5+dfsg-4ubuntu0.1

>From the Changelog:

"d/rules: do not use -Bsymoblic-functions when linking. Closes LP: 
#1553563, LP: #1567824."

Also: Looking at the build logs from Debian, it seems that the problematic 
linker flags are specific to Ubuntu, which would explain why Debian is 
unaffected.

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

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

2016-10-02 Thread Jan Martin

Hi,

Well, if not Debian, maybe we can interest Ubuntu in fixing the 7.0.5 
bacula in their 16.04 distribution, since it's an LTS version.  That 
would help those distros that inherit from Ubuntu, like Mint, maybe?

-Jan

On 10/02/2016 09:58 AM, Sven Hartge wrote:
> On 02.10.2016 09:08, Hankins, Jonathan wrote:
>
>> Even though it's fixed in the 7.4.x from Ubuntu (probably in debian
>> too), if it's indeed broken in debian, I'm going to ask if they can
>> release an update to their 7.0.5 package in testing, so that people who
>> track that, or distros that are derived from it, don't get a broken
>> bacula out of the box.
>
> Testing no longer has 7.0.5 (since 2016-06-09), so there is no need to
> release any fixed package. Any other derivative distribution using 7.0.5
> will have to fix their package on their own.
>
> 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

2016-10-02 Thread Sven Hartge

On 02.10.2016 09:08, Hankins, Jonathan wrote:

> Even though it's fixed in the 7.4.x from Ubuntu (probably in debian
> too), if it's indeed broken in debian, I'm going to ask if they can
> release an update to their 7.0.5 package in testing, so that people who
> track that, or distros that are derived from it, don't get a broken
> bacula out of the box.

Testing no longer has 7.0.5 (since 2016-06-09), so there is no need to
release any fixed package. Any other derivative distribution using 7.0.5
will have to fix their package on their own.

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

2016-10-02 Thread Kern Sibbald


  
  
On 10/02/2016 09:08 AM, Hankins,
  Jonathan wrote:


  I'll have to dig a bit, but I
know the package source in Mint 18 is unmodified from Ubuntu
xenial, and I didn't see any indication that it was different
than what's in debian.
  
  
  I think what may be happening is,
Ubuntu xenial (a LTS release IIRC) tracks something newer than
debian stable (maybe testing?) It has 7.0.5. Debian stable is
still on 5.x, with an older rules file that probably doesn't
have the linker flag that's causing trouble. Debian unstable,
and newer Ubuntu have 7.4.3 or 7.4.4, where Kern has worked
around the issue. I think people using the director are more
likely to be doing so on Debian and thus are getting the 5.x
code without the linker flag. Likewise, people's on the newest
Ubuntu probably have something >= 7.4.3, where it's worked
around. So I think only people on the Ubuntu LTS release
(xenial) or Mint 18 (brand new, but based on xenial) are getting
hit with it, and like Kern said, it may only manifest if certain
defaults are in use.


Yes, it is my understanding that Ubuntu (at least the Bacula
packager) is way ahead of Debian.


  
  Even though it's fixed in the 7.4.x
from Ubuntu (probably in debian too), if it's indeed broken in
debian, I'm going to ask if they can release an update to their
7.0.5 package in testing, so that people who track that, or
distros that are derived from it, don't get a broken bacula out
of the box.


Yes, please do so.  Thanks.


  
  I think compiler optimizations and
linker tweaks that change the fundamental functioning of your
code aren't great things to turn on by default :-/ It's hard
enough to develop and maintain software without your tools
fighting against you!


I don't have a big problem with compiler optimizations and linker
tweaks if packagers want to make them -- often they have "packaging
rules" that require those items.  However, where I am not happy for
the Bacula users is when packagers don't even test one execution and
so they change things, break them, and then make a bad release.  It
shouldn't work that way. 

To help resolve this problem, the Bacula project will shortly be
releasing binaries for as many common distros as we can handle, and
we do test our binaries :-)

Best regards,
Kern


  
  -Jonathan Hankins 
  
  
  
On Sun, Oct 2, 2016, 12:45 AM
  Kern Sibbald  wrote:


  
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

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

2016-10-02 Thread Kern Sibbald

Hello Jonathan,

  The only hope you have to get these changes made is to either
  submit a Feature Request in the bugs database for each one, or
  submit a patch -- also to the bugs database.

  With emails, these ideas disappear in about a half hour as our
  inboxes fill rapidly.

  Best regards,
  Kern

  On 10/02/2016 09:02 AM, Hankins, Jonathan wrote:

Kern,

  If there's any work to improve the error from bconsole when
the max console connections are exceeded, it may be helpful to
add a debug msg on the director indicating this too...i think
was running under debug level 9 and didn't see anything
indicating that condition.

For that matter, maybe the dir should refuse to
  start and explain when things like max dir connections = 0 are
  specified, since it is an invalid configuration (in spirit).

I think it'd also be useful if the daemons and
  bconsole dumped their entire config tree in debug, so you
  could see what final values are in effect, maybe noting which
  ones are set per defaults. (Maybe they already do?) 

-Jonathan Hankins 

  On Sun, Oct 2, 2016, 12:42 AM Kern Sibbald

wrote:

  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 wi

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

2016-10-02 Thread Hankins, Jonathan

I'll have to dig a bit, but I know the package source in Mint 18 is
unmodified from Ubuntu xenial, and I didn't see any indication that it was
different than what's in debian.

I think what may be happening is, Ubuntu xenial (a LTS release IIRC) tracks
something newer than debian stable (maybe testing?) It has 7.0.5. Debian
stable is still on 5.x, with an older rules file that probably doesn't have
the linker flag that's causing trouble. Debian unstable, and newer Ubuntu
have 7.4.3 or 7.4.4, where Kern has worked around the issue. I think people
using the director are more likely to be doing so on Debian and thus are
getting the 5.x code without the linker flag. Likewise, people's on the
newest Ubuntu probably have something >= 7.4.3, where it's worked around.
So I think only people on the Ubuntu LTS release (xenial) or Mint 18 (brand
new, but based on xenial) are getting hit with it, and like Kern said, it
may only manifest if certain defaults are in use.

Even though it's fixed in the 7.4.x from Ubuntu (probably in debian too),
if it's indeed broken in debian, I'm going to ask if they can release an
update to their 7.0.5 package in testing, so that people who track that, or
distros that are derived from it, don't get a broken bacula out of the box.

I think compiler optimizations and linker tweaks that change the
fundamental functioning of your code aren't great things to turn on by
default :-/ It's hard enough to develop and maintain software without your
tools fighting against you!

-Jonathan Hankins

On Sun, Oct 2, 2016, 12:45 AM Kern Sibbald wrote:

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
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

2016-10-02 Thread Hankins, Jonathan

Kern,

If there's any work to improve the error from bconsole when the max console
connections are exceeded, it may be helpful to add a debug msg on the
director indicating this too...i think was running under debug level 9
and didn't see anything indicating that condition.

For that matter, maybe the dir should refuse to start and explain when
things like max dir connections = 0 are specified, since it is an invalid
configuration (in spirit).

I think it'd also be useful if the daemons and bconsole dumped their entire
config tree in debug, so you could see what final values are in effect,
maybe noting which ones are set per defaults. (Maybe they already do?)

-Jonathan Hankins



On Sun, Oct 2, 2016, 12:42 AM Kern Sibbald  wrote:

> 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

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

2016-10-01 Thread 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

2016-10-01 Thread 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, but run ./configure my

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

2016-10-01 Thread 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

2016-10-01 Thread 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 additions with user-defi

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

2016-10-01 Thread 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 expec

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

2016-10-01 Thread 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

2016-10-01 Thread 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

2016-10-01 Thread 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] bconsole can't talk to bacula-dir

2016-09-30 Thread 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 been a certificate v

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

2016-09-30 Thread Hankins, Jonathan

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 been a certificate validation error
> during the TLS handshake.
>
> Just to be sure, I cut and pasted the Password entry from
> bacula-dir.conf directly into bconsole.conf.
>
> Thanks for the ideas, so far everything seems to be set up right.  The
> debug messages from the console really look as if something is not right
> in the authorization code since console connects to server OK.
>
> -Jan
>
> On 09/30/2016 03:44 PM, Hankins, Jonathan wrote:
> > I believe the FD is the inly thing that needs to run as root. I think on
> > Debian/Ubuntu/Mint, the dir runs as bacula:bacula and the SD as
> > bacula:tape, but I may be wrong.
> >
> > Are you sure that your bconsole is 7.0.5 as well? Check everything with:
> >
> > dpkg -l \*bacula\*
> >
> > and:
> >
> > which bconsole
> >
> > ...Just to make sure you don't have an old 5.x bconsole somewhere, and
> > that your dir is really 7.0.5.
> >
> > Also, bconsole has debug options. Note that, when I built 7.4.4 from
> > source, there is a .../sbin/bconsole, but also a wrapper in
> > .../etc/bconsole. If you want to specify debug flags, etc., you have to
> > run the real bconsole binary.
> >
> > bconsole -\?
> >
> >
> > On Fri, Sep 30, 2016 at 4:16 PM Elias Pereira  > > wrote:
> >
> > I'm not sure, but bacula services must be run as root both user and
> > group.
> >
> >
> > Em 30/09/2016 5:59 PM, "Jan Martin"  > > escreveu:
> >
> > Hi,
> >
> > OK, I just killed the currently running bacula-dir daemon (the
> > nice way, from the init.d script), and restarted it with the
> > same command line, but added -d200.  Got some extra stuff at the
> > beginning:
> >
> > trinity% sudo /usr/sbin/bacula-dir -d200 -c
> > /etc/bacula/bacula-dir.conf -u bacula -g bacula
> > bacula-dir: dird.c:194-0 Debug level = 200
> > bacula-dir: address_conf.c:264-0 Initaddr 0.0.0.0:9101
> > 
> > bacula-dir: runscript.c:284-0 runscript: debug
> > bacula-dir: runscript.c:285-0  --> RunScript
> > bacula-dir: runscript.c:286-0   -->
> > Comma

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

2016-09-30 Thread Hankins, Jonathan

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 been a certificate validation error
> during the TLS handshake.
>
> Just to be sure, I cut and pasted the Password entry from
> bacula-dir.conf directly into bconsole.conf.
>
> Thanks for the ideas, so far everything seems to be set up right.  The
> debug messages from the console really look as if something is not right
> in the authorization code since console connects to server OK.
>
> -Jan
>
> On 09/30/2016 03:44 PM, Hankins, Jonathan wrote:
> > I believe the FD is the inly thing that needs to run as root. I think on
> > Debian/Ubuntu/Mint, the dir runs as bacula:bacula and the SD as
> > bacula:tape, but I may be wrong.
> >
> > Are you sure that your bconsole is 7.0.5 as well? Check everything with:
> >
> > dpkg -l \*bacula\*
> >
> > and:
> >
> > which bconsole
> >
> > ...Just to make sure you don't have an old 5.x bconsole somewhere, and
> > that your dir is really 7.0.5.
> >
> > Also, bconsole has debug options. Note that, when I built 7.4.4 from
> > source, there is a .../sbin/bconsole, but also a wrapper in
> > .../etc/bconsole. If you want to specify debug flags, etc., you have to
> > run the real bconsole binary.
> >
> > bconsole -\?
> >
> >
> > On Fri, Sep 30, 2016 at 4:16 PM Elias Pereira  > > wrote:
> >
> > I'm not sure, but bacula services must be run as root both user and
> > group.
> >
> >
> > Em 30/09/2016 5:59 PM, "Jan Martin"  > > escreveu:
> >
> > Hi,
> >
> > OK, I just killed the currently running bacula-dir daemon (the
> > nice way, from the init.d script), and restarted it with the
> > same command line, but added -d200.  Got some extra stuff at the
> > beginning:
> >
> > trinity% sudo /usr/sbin/bacula-dir -d200 -c
> > /etc/bacula/bacula-dir.conf -u bacula -g bacula
> > bacula-dir: dird.c:194-0 Debug level = 200
> > bacula-dir: address_conf.c:264-0 Initaddr 0.0.0.0:9101
> > 
> > bacula-dir: runscript.c:284-0 runscript: debug
> > bacula-dir: runscript.c:285-0  --> RunScript
> > bacula-dir: runscript.c:286-0   -->
> > Command=/etc/bacula/scripts/make_catalog_backup.pl
> >  MyCatalog
> > bacula-dir: runscript.c:287-0   --> Target=
> > bacula-dir: runscript.c:288-0   --> RunOnSuccess=1
> > bacula-dir: runscript.c:289-0   --> RunOnFailure=0
> > bacula-dir: runscript.c:290-0   --> FailJobOnError=1
> > bacula-dir: runscript.c:291-0   --> RunWhen=2
> > bacula-dir: runscript.c:284-0 runscript: debug
> > bacula-dir: runscript.c:285-0  --> RunScript
> > bacula-dir: runscript.c:286-0   -->
> > Command=/etc/bacula/scripts/delete_catalog_backup
> > bacula-dir: runscript.c:287-0   --> Target=
> > bacula-dir: runscript.c:288-0   --> RunOnSuccess=1
> > bacula-dir: runscript.c:289-0   --> RunOnFailure=0
> > bacula-dir: runscript.c:290-0   --> FailJobOnError=1
> > bacula-dir: runscript.c:291-0   --> RunWhen=1
> > bacula-dir: jcr.c:128-0 read_last_jobs seek to 192
> > bacula-dir: jcr.c:135-0 Read num_items=0
> > bacula-dir: dir_plugins.c:148-0 Load dir plugins
> > bacula-dir: dir_plugins.c:150-0 No dir plugin dir!
> > trinit

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

2016-09-30 Thread Jan Martin

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 been a certificate validation error 
during the TLS handshake.

Just to be sure, I cut and pasted the Password entry from 
bacula-dir.conf directly into bconsole.conf.

Thanks for the ideas, so far everything seems to be set up right.  The 
debug messages from the console really look as if something is not right 
in the authorization code since console connects to server OK.

-Jan

On 09/30/2016 03:44 PM, Hankins, Jonathan wrote:
> I believe the FD is the inly thing that needs to run as root. I think on
> Debian/Ubuntu/Mint, the dir runs as bacula:bacula and the SD as
> bacula:tape, but I may be wrong.
>
> Are you sure that your bconsole is 7.0.5 as well? Check everything with:
>
> dpkg -l \*bacula\*
>
> and:
>
> which bconsole
>
> ...Just to make sure you don't have an old 5.x bconsole somewhere, and
> that your dir is really 7.0.5.
>
> Also, bconsole has debug options. Note that, when I built 7.4.4 from
> source, there is a .../sbin/bconsole, but also a wrapper in
> .../etc/bconsole. If you want to specify debug flags, etc., you have to
> run the real bconsole binary.
>
> bconsole -\?
>
>
> On Fri, Sep 30, 2016 at 4:16 PM Elias Pereira  > wrote:
>
> I'm not sure, but bacula services must be run as root both user and
> group.
>
>
> Em 30/09/2016 5:59 PM, "Jan Martin"  > escreveu:
>
> Hi,
>
> OK, I just killed the currently running bacula-dir daemon (the
> nice way, from the init.d script), and restarted it with the
> same command line, but added -d200.  Got some extra stuff at the
> beginning:
>
> trinity% sudo /usr/sbin/bacula-dir -d200 -c
> /etc/bacula/bacula-dir.conf -u bacula -g bacula
> bacula-dir: dird.c:194-0 Debug level = 200
> bacula-dir: address_conf.c:264-0 Initaddr 0.0.0.0:9101
> 
> bacula-dir: runscript.c:284-0 runscript: debug
> bacula-dir: runscript.c:285-0  --> RunScript
> bacula-dir: runscript.c:286-0   -->
> Command=/etc/bacula/scripts/make_catalog_backup.pl
>  MyCatalog
> bacula-dir: runscript.c:287-0   --> Target=
> bacula-dir: runscript.c:288-0   --> RunOnSuccess=1
> bacula-dir: runscript.c:289-0   --> RunOnFailure=0
> bacula-dir: runscript.c:290-0   --> FailJobOnError=1
> bacula-dir: runscript.c:291-0   --> RunWhen=2
> bacula-dir: runscript.c:284-0 runscript: debug
> bacula-dir: runscript.c:285-0  --> RunScript
> bacula-dir: runscript.c:286-0   -->
> Command=/etc/bacula/scripts/delete_catalog_backup
> bacula-dir: runscript.c:287-0   --> Target=
> bacula-dir: runscript.c:288-0   --> RunOnSuccess=1
> bacula-dir: runscript.c:289-0   --> RunOnFailure=0
> bacula-dir: runscript.c:290-0   --> FailJobOnError=1
> bacula-dir: runscript.c:291-0   --> RunWhen=1
> bacula-dir: jcr.c:128-0 read_last_jobs seek to 192
> bacula-dir: jcr.c:135-0 Read num_items=0
> bacula-dir: dir_plugins.c:148-0 Load dir plugins
> bacula-dir: dir_plugins.c:150-0 No dir plugin dir!
> trinity% bacula-dir: lockmgr.c:728-0 Exit check_deadlock.
> bacula-dir: sql_create.c:345-0 In create mediatype
> bacula-dir: sql_create.c:349-0 selectmediatype: SELECT
> MediaTypeId,MediaType FROM MediaType WHERE MediaType='File1'
> bacula-dir: sql_create.c:345-0 In create mediatype
> bacula-dir: sql_create.c:349-0 selectmediatype: SELECT
> MediaTypeId,MediaType FROM MediaType WHERE MediaType='File2'
> bacula-dir: sql_create.c:345-0 In create mediatype
> ba

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

2016-09-30 Thread Hankins, Jonathan

I believe the FD is the inly thing that needs to run as root. I think on
Debian/Ubuntu/Mint, the dir runs as bacula:bacula and the SD as
bacula:tape, but I may be wrong.

Are you sure that your bconsole is 7.0.5 as well? Check everything with:

dpkg -l \*bacula\*

and:

which bconsole

...Just to make sure you don't have an old 5.x bconsole somewhere, and that
your dir is really 7.0.5.

Also, bconsole has debug options. Note that, when I built 7.4.4 from
source, there is a .../sbin/bconsole, but also a wrapper in
.../etc/bconsole. If you want to specify debug flags, etc., you have to run
the real bconsole binary.

bconsole -\?


On Fri, Sep 30, 2016 at 4:16 PM Elias Pereira  wrote:

> I'm not sure, but bacula services must be run as root both user and group.
>
> Em 30/09/2016 5:59 PM, "Jan Martin"  escreveu:
>
>> Hi,
>>
>> OK, I just killed the currently running bacula-dir daemon (the nice way,
>> from the init.d script), and restarted it with the same command line, but
>> added -d200.  Got some extra stuff at the beginning:
>>
>> trinity% sudo /usr/sbin/bacula-dir -d200 -c /etc/bacula/bacula-dir.conf
>> -u bacula -g bacula
>> bacula-dir: dird.c:194-0 Debug level = 200
>> bacula-dir: address_conf.c:264-0 Initaddr 0.0.0.0:9101
>> bacula-dir: runscript.c:284-0 runscript: debug
>> bacula-dir: runscript.c:285-0  --> RunScript
>> bacula-dir: runscript.c:286-0   --> Command=/etc/bacula/scripts/
>> make_catalog_backup.pl MyCatalog
>> bacula-dir: runscript.c:287-0   --> Target=
>> bacula-dir: runscript.c:288-0   --> RunOnSuccess=1
>> bacula-dir: runscript.c:289-0   --> RunOnFailure=0
>> bacula-dir: runscript.c:290-0   --> FailJobOnError=1
>> bacula-dir: runscript.c:291-0   --> RunWhen=2
>> bacula-dir: runscript.c:284-0 runscript: debug
>> bacula-dir: runscript.c:285-0  --> RunScript
>> bacula-dir: runscript.c:286-0   -->
>> Command=/etc/bacula/scripts/delete_catalog_backup
>> bacula-dir: runscript.c:287-0   --> Target=
>> bacula-dir: runscript.c:288-0   --> RunOnSuccess=1
>> bacula-dir: runscript.c:289-0   --> RunOnFailure=0
>> bacula-dir: runscript.c:290-0   --> FailJobOnError=1
>> bacula-dir: runscript.c:291-0   --> RunWhen=1
>> bacula-dir: jcr.c:128-0 read_last_jobs seek to 192
>> bacula-dir: jcr.c:135-0 Read num_items=0
>> bacula-dir: dir_plugins.c:148-0 Load dir plugins
>> bacula-dir: dir_plugins.c:150-0 No dir plugin dir!
>> trinity% bacula-dir: lockmgr.c:728-0 Exit check_deadlock.
>> bacula-dir: sql_create.c:345-0 In create mediatype
>> bacula-dir: sql_create.c:349-0 selectmediatype: SELECT
>> MediaTypeId,MediaType FROM MediaType WHERE MediaType='File1'
>> bacula-dir: sql_create.c:345-0 In create mediatype
>> bacula-dir: sql_create.c:349-0 selectmediatype: SELECT
>> MediaTypeId,MediaType FROM MediaType WHERE MediaType='File2'
>> bacula-dir: sql_create.c:345-0 In create mediatype
>> bacula-dir: sql_create.c:349-0 selectmediatype: SELECT
>> MediaTypeId,MediaType FROM MediaType WHERE MediaType='File3'
>> trinity-dir: dird.c:323-0 Start UA server
>> trinity-dir: bnet_server.c:87-0 Addresses 127.0.0.1:9101
>> trinity-dir: job.c:1528-0 wstorage=File-trinity
>> trinity-dir: job.c:1537-0 wstore=File-trinity where=Job resource
>> trinity-dir: job.c:1211-0 JobId=0 created
>> Job=*JobMonitor*.2016-09-30_13.47.45_01
>> trinity-dir: dird.c:334-0 wait for next job
>>
>> and when I started up bconsole only one more line appeared:
>>
>> trinity-dir: bnet.c:566-0 who=client host=127.0.0.1 port=9101
>>
>> and that's it.  The same result from bconsole as below...
>>
>> Does any of this help?  Thanks.
>>
>> -Jan Martin
>>
>> On 09/30/2016 01:13 PM, Elias Pereira wrote:
>>
>>> You tried to execute bacula-dir in debug mode?
>>>
>>> # bacula-dir -d200
>>>
>>>
>>> Em 30/09/2016 4:49 PM, "Jan Martin" >> > escreveu:
>>>
>>> Hello bacula-users!
>>>
>>> I'm having a problem that I can't figure out, so I hope someone here
>>> can
>>> help out.
>>>
>>> I have been using bacula 5.2.x for backing up my Mint linux box and a
>>> couple of Macs.  The latest version of Mint goes to bacula v7.0.5,
>>> so I
>>> installed that after saving my old database and saving all the old
>>> *.conf files.
>>>
>>> After fixing up the new *.conf files so they were basically like the
>>> old
>>> ones (I didn't use any of the new virtual autochanger stuff), I
>>> reinstalled the *.conf files in /etc/bacula, and reconstituted the
>>> database in the usual way.  I'm using sqlite3 for the database.
>>>
>>> All the daemons start up fine, no errors, but when I try to start up
>>> bconsole, I get an authorization error:
>>>
>>> trinity% sudo bconsole
>>> [sudo] password for jmm:
>>> Connecting to Director localhost:9101
>>> Director authorization problem.
>>> Most likely the passwords do not agree.
>>> If you are using TLS, there may have been a certificate validation
>>> error
>>> during the TLS handshake.
>>> Please see
>>>
>>> http://www.bacula.org/en/re

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

2016-09-30 Thread Elias Pereira

I'm not sure, but bacula services must be run as root both user and group.

Em 30/09/2016 5:59 PM, "Jan Martin"  escreveu:

> Hi,
>
> OK, I just killed the currently running bacula-dir daemon (the nice way,
> from the init.d script), and restarted it with the same command line, but
> added -d200.  Got some extra stuff at the beginning:
>
> trinity% sudo /usr/sbin/bacula-dir -d200 -c /etc/bacula/bacula-dir.conf -u
> bacula -g bacula
> bacula-dir: dird.c:194-0 Debug level = 200
> bacula-dir: address_conf.c:264-0 Initaddr 0.0.0.0:9101
> bacula-dir: runscript.c:284-0 runscript: debug
> bacula-dir: runscript.c:285-0  --> RunScript
> bacula-dir: runscript.c:286-0   --> Command=/etc/bacula/scripts/ma
> ke_catalog_backup.pl MyCatalog
> bacula-dir: runscript.c:287-0   --> Target=
> bacula-dir: runscript.c:288-0   --> RunOnSuccess=1
> bacula-dir: runscript.c:289-0   --> RunOnFailure=0
> bacula-dir: runscript.c:290-0   --> FailJobOnError=1
> bacula-dir: runscript.c:291-0   --> RunWhen=2
> bacula-dir: runscript.c:284-0 runscript: debug
> bacula-dir: runscript.c:285-0  --> RunScript
> bacula-dir: runscript.c:286-0   --> Command=/etc/bacula/scripts/de
> lete_catalog_backup
> bacula-dir: runscript.c:287-0   --> Target=
> bacula-dir: runscript.c:288-0   --> RunOnSuccess=1
> bacula-dir: runscript.c:289-0   --> RunOnFailure=0
> bacula-dir: runscript.c:290-0   --> FailJobOnError=1
> bacula-dir: runscript.c:291-0   --> RunWhen=1
> bacula-dir: jcr.c:128-0 read_last_jobs seek to 192
> bacula-dir: jcr.c:135-0 Read num_items=0
> bacula-dir: dir_plugins.c:148-0 Load dir plugins
> bacula-dir: dir_plugins.c:150-0 No dir plugin dir!
> trinity% bacula-dir: lockmgr.c:728-0 Exit check_deadlock.
> bacula-dir: sql_create.c:345-0 In create mediatype
> bacula-dir: sql_create.c:349-0 selectmediatype: SELECT
> MediaTypeId,MediaType FROM MediaType WHERE MediaType='File1'
> bacula-dir: sql_create.c:345-0 In create mediatype
> bacula-dir: sql_create.c:349-0 selectmediatype: SELECT
> MediaTypeId,MediaType FROM MediaType WHERE MediaType='File2'
> bacula-dir: sql_create.c:345-0 In create mediatype
> bacula-dir: sql_create.c:349-0 selectmediatype: SELECT
> MediaTypeId,MediaType FROM MediaType WHERE MediaType='File3'
> trinity-dir: dird.c:323-0 Start UA server
> trinity-dir: bnet_server.c:87-0 Addresses 127.0.0.1:9101
> trinity-dir: job.c:1528-0 wstorage=File-trinity
> trinity-dir: job.c:1537-0 wstore=File-trinity where=Job resource
> trinity-dir: job.c:1211-0 JobId=0 created Job=*JobMonitor*.2016-09-30_13
> .47.45_01
> trinity-dir: dird.c:334-0 wait for next job
>
> and when I started up bconsole only one more line appeared:
>
> trinity-dir: bnet.c:566-0 who=client host=127.0.0.1 port=9101
>
> and that's it.  The same result from bconsole as below...
>
> Does any of this help?  Thanks.
>
> -Jan Martin
>
> On 09/30/2016 01:13 PM, Elias Pereira wrote:
>
>> You tried to execute bacula-dir in debug mode?
>>
>> # bacula-dir -d200
>>
>>
>> Em 30/09/2016 4:49 PM, "Jan Martin" > > escreveu:
>>
>> Hello bacula-users!
>>
>> I'm having a problem that I can't figure out, so I hope someone here
>> can
>> help out.
>>
>> I have been using bacula 5.2.x for backing up my Mint linux box and a
>> couple of Macs.  The latest version of Mint goes to bacula v7.0.5, so
>> I
>> installed that after saving my old database and saving all the old
>> *.conf files.
>>
>> After fixing up the new *.conf files so they were basically like the
>> old
>> ones (I didn't use any of the new virtual autochanger stuff), I
>> reinstalled the *.conf files in /etc/bacula, and reconstituted the
>> database in the usual way.  I'm using sqlite3 for the database.
>>
>> All the daemons start up fine, no errors, but when I try to start up
>> bconsole, I get an authorization error:
>>
>> trinity% sudo bconsole
>> [sudo] password for jmm:
>> Connecting to Director localhost:9101
>> Director authorization problem.
>> Most likely the passwords do not agree.
>> If you are using TLS, there may have been a certificate validation
>> error
>> during the TLS handshake.
>> Please see
>> http://www.bacula.org/en/rel-manual/Bacula_Freque_Asked_Ques
>> ti.html#SECTION0026
>> > sti.html#SECTION0026>
>> for help.
>>
>> Here are the relevant sections of bacula-dir.conf:
>>
>> Director {# define myself
>>Name = trinity-dir
>>DIRport = 9101# where we listen for UA connections
>>QueryFile = "/etc/bacula/scripts/query.sql"
>>WorkingDirectory = "/var/lib/bacula"
>>PidDirectory = "/var/run/bacula"
>>Maximum Concurrent Jobs = 20
>>Password = "xxxyyyzzz" # Console password
>>Messages = Daemon
>>DirAddress = 127.0.0.1
>> }
>>
>> and bconsole.conf:
>>
>> Director {
>>

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

2016-09-30 Thread Jan Martin

Hi,

OK, I just killed the currently running bacula-dir daemon (the nice way, 
from the init.d script), and restarted it with the same command line, 
but added -d200.  Got some extra stuff at the beginning:

trinity% sudo /usr/sbin/bacula-dir -d200 -c /etc/bacula/bacula-dir.conf 
-u bacula -g bacula
bacula-dir: dird.c:194-0 Debug level = 200
bacula-dir: address_conf.c:264-0 Initaddr 0.0.0.0:9101
bacula-dir: runscript.c:284-0 runscript: debug
bacula-dir: runscript.c:285-0  --> RunScript
bacula-dir: runscript.c:286-0   --> 
Command=/etc/bacula/scripts/make_catalog_backup.pl MyCatalog
bacula-dir: runscript.c:287-0   --> Target=
bacula-dir: runscript.c:288-0   --> RunOnSuccess=1
bacula-dir: runscript.c:289-0   --> RunOnFailure=0
bacula-dir: runscript.c:290-0   --> FailJobOnError=1
bacula-dir: runscript.c:291-0   --> RunWhen=2
bacula-dir: runscript.c:284-0 runscript: debug
bacula-dir: runscript.c:285-0  --> RunScript
bacula-dir: runscript.c:286-0   --> 
Command=/etc/bacula/scripts/delete_catalog_backup
bacula-dir: runscript.c:287-0   --> Target=
bacula-dir: runscript.c:288-0   --> RunOnSuccess=1
bacula-dir: runscript.c:289-0   --> RunOnFailure=0
bacula-dir: runscript.c:290-0   --> FailJobOnError=1
bacula-dir: runscript.c:291-0   --> RunWhen=1
bacula-dir: jcr.c:128-0 read_last_jobs seek to 192
bacula-dir: jcr.c:135-0 Read num_items=0
bacula-dir: dir_plugins.c:148-0 Load dir plugins
bacula-dir: dir_plugins.c:150-0 No dir plugin dir!
trinity% bacula-dir: lockmgr.c:728-0 Exit check_deadlock.
bacula-dir: sql_create.c:345-0 In create mediatype
bacula-dir: sql_create.c:349-0 selectmediatype: SELECT 
MediaTypeId,MediaType FROM MediaType WHERE MediaType='File1'
bacula-dir: sql_create.c:345-0 In create mediatype
bacula-dir: sql_create.c:349-0 selectmediatype: SELECT 
MediaTypeId,MediaType FROM MediaType WHERE MediaType='File2'
bacula-dir: sql_create.c:345-0 In create mediatype
bacula-dir: sql_create.c:349-0 selectmediatype: SELECT 
MediaTypeId,MediaType FROM MediaType WHERE MediaType='File3'
trinity-dir: dird.c:323-0 Start UA server
trinity-dir: bnet_server.c:87-0 Addresses 127.0.0.1:9101
trinity-dir: job.c:1528-0 wstorage=File-trinity
trinity-dir: job.c:1537-0 wstore=File-trinity where=Job resource
trinity-dir: job.c:1211-0 JobId=0 created 
Job=*JobMonitor*.2016-09-30_13.47.45_01
trinity-dir: dird.c:334-0 wait for next job

and when I started up bconsole only one more line appeared:

trinity-dir: bnet.c:566-0 who=client host=127.0.0.1 port=9101

and that's it.  The same result from bconsole as below...

Does any of this help?  Thanks.

-Jan Martin

On 09/30/2016 01:13 PM, Elias Pereira wrote:
> You tried to execute bacula-dir in debug mode?
>
> # bacula-dir -d200
>
>
> Em 30/09/2016 4:49 PM, "Jan Martin"  > escreveu:
>
> Hello bacula-users!
>
> I'm having a problem that I can't figure out, so I hope someone here can
> help out.
>
> I have been using bacula 5.2.x for backing up my Mint linux box and a
> couple of Macs.  The latest version of Mint goes to bacula v7.0.5, so I
> installed that after saving my old database and saving all the old
> *.conf files.
>
> After fixing up the new *.conf files so they were basically like the old
> ones (I didn't use any of the new virtual autochanger stuff), I
> reinstalled the *.conf files in /etc/bacula, and reconstituted the
> database in the usual way.  I'm using sqlite3 for the database.
>
> All the daemons start up fine, no errors, but when I try to start up
> bconsole, I get an authorization error:
>
> trinity% sudo bconsole
> [sudo] password for jmm:
> Connecting to Director localhost:9101
> Director authorization problem.
> Most likely the passwords do not agree.
> If you are using TLS, there may have been a certificate validation error
> during the TLS handshake.
> Please see
> 
> http://www.bacula.org/en/rel-manual/Bacula_Freque_Asked_Questi.html#SECTION0026
> 
> 
> for help.
>
> Here are the relevant sections of bacula-dir.conf:
>
> Director {# define myself
>Name = trinity-dir
>DIRport = 9101# where we listen for UA connections
>QueryFile = "/etc/bacula/scripts/query.sql"
>WorkingDirectory = "/var/lib/bacula"
>PidDirectory = "/var/run/bacula"
>Maximum Concurrent Jobs = 20
>Password = "xxxyyyzzz" # Console password
>Messages = Daemon
>DirAddress = 127.0.0.1
> }
>
> and bconsole.conf:
>
> Director {
>Name = trinity-dir
>DIRport = 9101
>address = localhost
>Password = "xxxyyyzzz"
> }
>
> The passwords are identical.  And the /etc/hosts file has the line
>
> 127.0.0.1   localhost
>
> And there is no firewall, so no port usage restrictions.  Besides, al

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

2016-09-30 Thread Elias Pereira

You tried to execute bacula-dir in debug mode?

# bacula-dir -d200

Em 30/09/2016 4:49 PM, "Jan Martin"  escreveu:

> Hello bacula-users!
>
> I'm having a problem that I can't figure out, so I hope someone here can
> help out.
>
> I have been using bacula 5.2.x for backing up my Mint linux box and a
> couple of Macs.  The latest version of Mint goes to bacula v7.0.5, so I
> installed that after saving my old database and saving all the old
> *.conf files.
>
> After fixing up the new *.conf files so they were basically like the old
> ones (I didn't use any of the new virtual autochanger stuff), I
> reinstalled the *.conf files in /etc/bacula, and reconstituted the
> database in the usual way.  I'm using sqlite3 for the database.
>
> All the daemons start up fine, no errors, but when I try to start up
> bconsole, I get an authorization error:
>
> trinity% sudo bconsole
> [sudo] password for jmm:
> Connecting to Director localhost:9101
> Director authorization problem.
> Most likely the passwords do not agree.
> If you are using TLS, there may have been a certificate validation error
> during the TLS handshake.
> Please see
> http://www.bacula.org/en/rel-manual/Bacula_Freque_Asked_Questi.html#
> SECTION0026
> for help.
>
> Here are the relevant sections of bacula-dir.conf:
>
> Director {# define myself
>Name = trinity-dir
>DIRport = 9101# where we listen for UA connections
>QueryFile = "/etc/bacula/scripts/query.sql"
>WorkingDirectory = "/var/lib/bacula"
>PidDirectory = "/var/run/bacula"
>Maximum Concurrent Jobs = 20
>Password = "xxxyyyzzz" # Console password
>Messages = Daemon
>DirAddress = 127.0.0.1
> }
>
> and bconsole.conf:
>
> Director {
>Name = trinity-dir
>DIRport = 9101
>address = localhost
>Password = "xxxyyyzzz"
> }
>
> The passwords are identical.  And the /etc/hosts file has the line
>
> 127.0.0.1   localhost
>
> And there is no firewall, so no port usage restrictions.  Besides, all
> this is taking place on one machine.  There are network clients, but are
> they relevant to this problem?
>
> I'm really confused.  I don't see how this can happen, but maybe there's
> something out there that is failing a check, or something.  I could
> really use some help - thanks in advance.
>
> You folks have always come through in the past, and I'm hoping I've just
> messed up something that's different for the new version.
>
> -Jan Martin
>
> 
> --
> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

24 matches

Site Navigation

Mail list logo

Footer information