SearchFAQMemberlist Log in
Reply to topic Page 1 of 1
Authorization Errors after upgrade to 2.0.2 (Workaround)
Author Message
Post Authorization Errors after upgrade to 2.0.2 (Workaround) 
On Thursday 01 February 2007 18:02, Jeronimo Zucco wrote:

Someone pointed out how to modify the code recently on this list
(it involves
modifying the SD).

Another approach would be to run a "dummy" job that does the
ClientRunBefore -- it could be a Verify with an empty FileSet. The
real job
could then be scheduled after the dummy job using priorities or
whatever ...
============

Executive summary: Just a followup for the lurkers and archive-
readers... Here's a workaround for this problem based on a dummy-job
approach.

============
I encountered this problem too, when some DB prep scripts took too
long (~50 min) to run on some clients before the data transferring
phase, and editing the source seemed a bit of an invitation to
maintenance and future installation trouble.

My solution (which seems to work) is to have two jobs, a download-db-
dumps job, and a preparatory job. The prep job is scheduled a little
earlier and with a higher priority (smaller priority number) than the
main download job.

The prep job uses an empty fileset and runs the prep script *after*
the bulk of the job. If you run it before, then when it takes too
long it will generally result in failed job because the client can't
connect to the SD (despite having nothing to transfer), so you get
annoying emails even when everything actually worked fine. Prep Sample:

RunScript {
Command = "bash -c \"/etc/bacula/dbdiffs.py /var/
bacula/db_backups/; echo $? > /var/bacula/db_backups/rval.dat\""
RunsWhen = After
RunsOnClient = yes # BUG in Bacula 2.01, cannot use
uppercase Y in Yes for RunsOnClient.
}

So it runs the script and stores the return value ($?) into a file.
Then the real backup script checks that file, and if the file does
not exist or has a nonzero error code, the main backup will fail.
Main script sample:

RunScript {
Command = "/etc/bacula/exitval.sh /var/bacula/
db_backups/rval.dat"
AbortJobOnError = yes
RunsWhen = Before
RunsOnClient = yes # BUG in Bacula 2.01, cannot use
uppercase Y in Yes for RunsOnClient.
}

Exitval.sh reads the file and exits with the value contained therein.
In effect, this allows you to run scripts of >30 mins and still have
Bacula tell you when they fail. Furthermore, in case they corrupted
your database dumps at the same time, Bacula won't do the backup.

--
--Darien A. Hager
darien < at > et...
Mobile: (206) 734-5666

Post Authorization Errors after upgrade to 2.0.2 (Workaround) 
Hello,

This is a nice solution to the problem, and something that you might want to
keep indefinitely. However, the "problem" should be fixed in version 2.0.3.

Regards,

Kern

On Friday 16 March 2007 19:45, Darien Hager wrote:
On Thursday 01 February 2007 18:02, Jeronimo Zucco wrote:

Someone pointed out how to modify the code recently on this list
(it involves
modifying the SD).

Another approach would be to run a "dummy" job that does the
ClientRunBefore -- it could be a Verify with an empty FileSet. The
real job
could then be scheduled after the dummy job using priorities or
whatever ...
============

Executive summary: Just a followup for the lurkers and archive-
readers... Here's a workaround for this problem based on a dummy-job
approach.

============
I encountered this problem too, when some DB prep scripts took too
long (~50 min) to run on some clients before the data transferring
phase, and editing the source seemed a bit of an invitation to
maintenance and future installation trouble.

My solution (which seems to work) is to have two jobs, a download-db-
dumps job, and a preparatory job. The prep job is scheduled a little
earlier and with a higher priority (smaller priority number) than the
main download job.

The prep job uses an empty fileset and runs the prep script *after*
the bulk of the job. If you run it before, then when it takes too
long it will generally result in failed job because the client can't
connect to the SD (despite having nothing to transfer), so you get
annoying emails even when everything actually worked fine. Prep Sample:

RunScript {
Command = "bash -c \"/etc/bacula/dbdiffs.py /var/
bacula/db_backups/; echo $? > /var/bacula/db_backups/rval.dat\""
RunsWhen = After
RunsOnClient = yes # BUG in Bacula 2.01, cannot use
uppercase Y in Yes for RunsOnClient.
}

So it runs the script and stores the return value ($?) into a file.
Then the real backup script checks that file, and if the file does
not exist or has a nonzero error code, the main backup will fail.
Main script sample:

RunScript {
Command = "/etc/bacula/exitval.sh /var/bacula/
db_backups/rval.dat"
AbortJobOnError = yes
RunsWhen = Before
RunsOnClient = yes # BUG in Bacula 2.01, cannot use
uppercase Y in Yes for RunsOnClient.
}

Exitval.sh reads the file and exits with the value contained therein.
In effect, this allows you to run scripts of >30 mins and still have
Bacula tell you when they fail. Furthermore, in case they corrupted
your database dumps at the same time, Bacula won't do the backup.

--
--Darien A. Hager
darien < at > et...
Mobile: (206) 734-5666



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users


Post Authorization Errors after upgrade to 2.0.2 (Workaround) 
On Fri, 16 Mar 2007, Darien Hager wrote:

The prep job uses an empty fileset and runs the prep script *after*
the bulk of the job.

If you make the prep job an "admin" job instead of an "archive" job you
won't need to define an empty fileset. Smile

Display posts from previous:
Reply to topic Page 1 of 1
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
  


Magic SEO URL for phpBB