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

[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

[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

[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  <mailto:empbi...@gmail.com>> 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"  <mailto:fyzz...@gmail.com>> 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
> <http://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
> <http://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,Medi

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

[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"  <mailto:fyzz...@gmail.com>> 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
> 
> <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

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

[Jan Martin]

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

Re: [Bacula-users] database name is blank?

[Jan Martin]

Hello,

Thanks for your quick response.  Your answer, and the fact that there 
were no issues with the Catalog resource or multiple bacula-dir.conf 
files suggested some other error, and it turned out when I manually 
tried to run bacula-dir, it flagged a different error in the 
configuration file, which I then corrected, and all was well.

So, sorry for sending what turned out to be a red herring.  I don't know 
why I didn't get that message about the config error in the bacula log, 
but maybe it got sent somewhere else - I haven't been able to find it yet.

I will also gently suggest to the linux mint bacula package maintainer 
that we upgrade to 5.2.13, as you suggest, and ask about 7.0.5.

Thanks again for your help.

-Jan Martin

On 12/13/2014 09:55 PM, Kern Sibbald wrote:
> Hello,
>
> It looks to me like you either have a broken build of Bacula, or more
> likely, the conf file that the Director is using is not the one you have
> listed below, or possibly you have multiple Catalog resources in the
> conf file, and one of them seems to be broken.
>
> Since 5.2.6 is very old, you probably should move up to at least 5.2.13
> (no database change needed) -- and it would be better to get on 7.0.5,
> but I would not recommend a move to 7.0.5 until you resolve your
> database problem.
>
> Best regards,
> Kern
>
> On 12/13/2014 08:34 AM, Jan Martin wrote:
>> Hello all,
>>
>> I have been running bacula 5.2.6 on Linux Mint for a while, and just
>> installed it on the latest version, 17.1.  I'm getting an odd error -
>> the director won't start:
>>
>> 11-Dec 09:42 bacula-dir JobId 0: Fatal error: Could not open Catalog
>> "MyCatalog", database "".
>> 11-Dec 09:42 bacula-dir JobId 0: Fatal error: sqlite.c:182 Database
>> /var/lib/bacula/.db does not exist, please crea
>> te it.
>> 11-Dec 09:42 bacula-dir ERROR TERMINATION
>> Please correct configuration file: /etc/bacula/bacula-dir.conf
>>
>> Which is odd, since the bacula-dir.conf catalog resource is pretty much
>> plain vanilla:
>>
>> Catalog {
>> Name = MyCatalog
>> # Uncomment the following line if you want the dbi driver
>> # dbdriver = "dbi:postgresql"; dbaddress = 127.0.0.1; dbport =
>> dbname = "bacula"; dbuser = ""; dbpassword = ""
>> }
>>
>> I had some trouble with the catalog database file before installation.
>> I did a backup of another computer, and before I could back up the
>> database, the computer crashed, broke so bad I had to reload the OS from
>> dvd. That reload wiped out the bootstrap file, so I had to do the bls
>> and bextract by hand, but I got the old catalog back, then added in the
>> data from the last backup using bscan.  That all seemed to work pretty
>> well, so I was hopeful I could continue using this catalog.
>>
>> But now I get this odd error - anyone have any clues what I can do to
>> fix it?  Thanks much.
>>
>> -Jan
>>
>> --
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> ___
>> Bacula-users mailing list
>> Bacula-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>>
>


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

[Bacula-users] database name is blank?

[Jan Martin]

Hello all,

I have been running bacula 5.2.6 on Linux Mint for a while, and just 
installed it on the latest version, 17.1.  I'm getting an odd error - 
the director won't start:

11-Dec 09:42 bacula-dir JobId 0: Fatal error: Could not open Catalog 
"MyCatalog", database "".
11-Dec 09:42 bacula-dir JobId 0: Fatal error: sqlite.c:182 Database 
/var/lib/bacula/.db does not exist, please crea
te it.
11-Dec 09:42 bacula-dir ERROR TERMINATION
Please correct configuration file: /etc/bacula/bacula-dir.conf

Which is odd, since the bacula-dir.conf catalog resource is pretty much 
plain vanilla:

Catalog {
   Name = MyCatalog
# Uncomment the following line if you want the dbi driver
# dbdriver = "dbi:postgresql"; dbaddress = 127.0.0.1; dbport =
   dbname = "bacula"; dbuser = ""; dbpassword = ""
}

I had some trouble with the catalog database file before installation.
I did a backup of another computer, and before I could back up the 
database, the computer crashed, broke so bad I had to reload the OS from 
dvd. That reload wiped out the bootstrap file, so I had to do the bls 
and bextract by hand, but I got the old catalog back, then added in the 
data from the last backup using bscan.  That all seemed to work pretty 
well, so I was hopeful I could continue using this catalog.

But now I get this odd error - anyone have any clues what I can do to 
fix it?  Thanks much.

-Jan

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Director can't talk to storage daemon

[Jan Martin]

On 12/14/2012 10:16 AM, John Drescher wrote:
> On Fri, Dec 14, 2012 at 12:58 PM, Jan Martin  wrote:
>> Hello all,
>>
>> I'm having trouble with my new bacula setup.  I had it running fine on
>> Linux Mint 13, went to Mint 14, set up the configuration files as I had
>> them set up before, and now cannot talk to the storage daemon.  Here's
>> the status from bconsole:
>>
>> *status
>> Status available for:
>>1: Director
>>2: Storage
>>3: Client
>>4: All
>> Select daemon type for status (1-4): 2
>> Automatically selected Storage: File-trinity
>> Connecting to Storage daemon File-trinity at 192.168.0.4:9103
>>
>> Failed to connect to Storage daemon File-trinity.
>>
>> When I try to run a backup, I get a bunch of messages:
>>
>> 12-Dec 03:30 trinity-dir JobId 11: shell command: run BeforeJob
>> "/etc/bacula/scripts/make_catalog_backup.pl MyCatalog"
>> 12-Dec 03:30 trinity-dir JobId 11: Start Backup JobId 11,
>> Job=BackupCatalog.2012-12-12_03.30.00_03
>> 12-Dec 03:30 trinity-dir JobId 11: Warning: bsock.c:127 Could not
>> connect to Storage daemon on 192.168.0.4:9103. ERR=Connection refused
>> Retrying ...
>> 12-Dec 03:35 trinity-dir JobId 11: Warning: bsock.c:127 Could not
>> connect to Storage daemon on 192.168.0.4:9103. ERR=Connection refused
>> Retrying ...
>>
>>   A bunch of these, then it errors out:
>>
>> 12-Dec 04:00 trinity-dir JobId 11: Fatal error: bsock.c:133 Unable to
>> connect to Storage daemon on 192.168.0.4:9103. ERR=Connection refused
>> 12-Dec 04:00 trinity-dir JobId 11: Error: Bacula trinity-dir 5.2.6
>> (21Feb12):
>>
>>
>> bconsole connects to bacula-dir just fine, and it can talk to bacula-fd
>> just fine.  The passwords in the config files for dir and sd match, and
>> the names also match:
>> 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 = "/run/bacula"
>> Maximum Concurrent Jobs = 1
>> Password = "Y" # Console password
>> Messages = Daemon
>> DirAddress = 127.0.0.1
>> }
>>
>>
>> # Definition of file storage device
>> Storage {
>> Name = File-trinity
>> # Do not use "localhost" here
>> Address = 192.168.0.4# N.B. Use a fully qualified
>> name here
>> SDPort = 9103
>> Password = "X"
>> Device = FileStorage-trinity
>> Media Type = File1
>> }
>>
>> bacula-sd.conf:
>>
>> Storage { # definition of myself
>> Name = trinity-sd
>> SDPort = 9103  # Director's port
>> WorkingDirectory = "/var/lib/bacula"
>> Pid Directory = "/run/bacula"
>> Maximum Concurrent Jobs = 20
>> SDAddress = 127.0.0.1
>> }
>>
>> # List Directors who are permitted to contact Storage daemon
>> #
>> Director {
>> Name = trinity-dir
>> Password = "X"
>> }
>>
>> Device {
>> Name = FileStorage-trinity
>> Media Type = File1
>> Archive Device = /media/jmm/Backup/bacula
>> Device Type = File
>> LabelMedia = yes;   # lets Bacula label unlabeled media
>> Random Access = Yes;
>> RemovableMedia = no;
>> Requires Mount = no
>> }
>>
>> I am somewhat of a noob, but X is of course not actually the
>> password - but they do match!
>>
>> Does anyone here have any ideas why the director can't talk to the sd?
>> There's no firewall on this machine, ufw is inactive (this is a pretty
>> plain vanilla Mint 14 install).
>>
>> Many thanks for any and all help on this, since bacula has been my
>> primary backup method for the past several years, and has really saved
>> my butt a couple of times.
>>
> Get rid of 127.0.0.John Drescher 1 and replace it with 
> an external ipaddress.
>
> John
>


Bingo!  That was the location of the problem.  I just commented out the 
SDAddress line in the storage definition, and it ran and started 
communicating with the director.  Thanks very much!

-Jan

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

[Bacula-users] Director can't talk to storage daemon

[Jan Martin]

Hello all,

I'm having trouble with my new bacula setup.  I had it running fine on 
Linux Mint 13, went to Mint 14, set up the configuration files as I had 
them set up before, and now cannot talk to the storage daemon.  Here's 
the status from bconsole:

*status
Status available for:
  1: Director
  2: Storage
  3: Client
  4: All
Select daemon type for status (1-4): 2
Automatically selected Storage: File-trinity
Connecting to Storage daemon File-trinity at 192.168.0.4:9103

Failed to connect to Storage daemon File-trinity.

When I try to run a backup, I get a bunch of messages:

12-Dec 03:30 trinity-dir JobId 11: shell command: run BeforeJob 
"/etc/bacula/scripts/make_catalog_backup.pl MyCatalog"
12-Dec 03:30 trinity-dir JobId 11: Start Backup JobId 11, 
Job=BackupCatalog.2012-12-12_03.30.00_03
12-Dec 03:30 trinity-dir JobId 11: Warning: bsock.c:127 Could not 
connect to Storage daemon on 192.168.0.4:9103. ERR=Connection refused
Retrying ...
12-Dec 03:35 trinity-dir JobId 11: Warning: bsock.c:127 Could not 
connect to Storage daemon on 192.168.0.4:9103. ERR=Connection refused
Retrying ...

 A bunch of these, then it errors out:

12-Dec 04:00 trinity-dir JobId 11: Fatal error: bsock.c:133 Unable to 
connect to Storage daemon on 192.168.0.4:9103. ERR=Connection refused
12-Dec 04:00 trinity-dir JobId 11: Error: Bacula trinity-dir 5.2.6 
(21Feb12):


bconsole connects to bacula-dir just fine, and it can talk to bacula-fd 
just fine.  The passwords in the config files for dir and sd match, and 
the names also match:
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 = "/run/bacula"
   Maximum Concurrent Jobs = 1
   Password = "Y" # Console password
   Messages = Daemon
   DirAddress = 127.0.0.1
}


# Definition of file storage device
Storage {
   Name = File-trinity
# Do not use "localhost" here
   Address = 192.168.0.4# N.B. Use a fully qualified 
name here
   SDPort = 9103
   Password = "X"
   Device = FileStorage-trinity
   Media Type = File1
}

bacula-sd.conf:

Storage { # definition of myself
   Name = trinity-sd
   SDPort = 9103  # Director's port
   WorkingDirectory = "/var/lib/bacula"
   Pid Directory = "/run/bacula"
   Maximum Concurrent Jobs = 20
   SDAddress = 127.0.0.1
}

# List Directors who are permitted to contact Storage daemon
#
Director {
   Name = trinity-dir
   Password = "X"
}

Device {
   Name = FileStorage-trinity
   Media Type = File1
   Archive Device = /media/jmm/Backup/bacula
   Device Type = File
   LabelMedia = yes;   # lets Bacula label unlabeled media
   Random Access = Yes;
   RemovableMedia = no;
   Requires Mount = no
}

I am somewhat of a noob, but X is of course not actually the 
password - but they do match!

Does anyone here have any ideas why the director can't talk to the sd? 
There's no firewall on this machine, ufw is inactive (this is a pretty 
plain vanilla Mint 14 install).

Many thanks for any and all help on this, since bacula has been my 
primary backup method for the past several years, and has really saved 
my butt a couple of times.

-Jan Martin

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

[Bacula-users] Sustaining bacula across OS updates

[Jan Martin]

Hi,

I have been using bacula to back up my local linux machine (Mint 11) and
a Mac laptop for a couple of years now, and I would like to update my
linux OS to a new version.  To get a good, stable system, I have always
done a pretty clean install (basically only saved /home partition, and
installed a new set of system software in the / partition).  I'd like to
continue to use bacula after my new OS install, which will overwrite all
the bacula system files (not the backup files, of course - they are on a
separate drive, USB mounted).

I know I need to save the /etc/bacula configuration files, but what else
do I need to save?  I am using SQlite3 for the catalog.  I expect that I
will need to save that by dumping it to a file, like the catalog backup
script does.  Is there anything else I need to save, to save the state
of bacula and just continue on after I've loaded the new OS?

I looked around, but couldn't find a how-to on this, so many thanks for
any help.

-Jan

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users