Bacula-users

Re: [Bacula-users] How to configure atochanger on RD1000 usb devices

2013-11-21 18:39:25
Subject: Re: [Bacula-users] How to configure atochanger on RD1000 usb devices
From: Bill Arlofski <waa-bacula AT revpol DOT com>
To: bacula-users AT lists.sourceforge DOT net
Date: Thu, 21 Nov 2013 18:34:49 -0500
On 11/20/13 19:57, vlad wrote:
> Hi Bill, would you be able to share your Before and After scripts, I'm about
> to add this RD1000 to my bacula setup. Had been using regular external usb
> disk before which worked/triggered well with udev and vchanger. but now we
> have this device to integrate and I could use extra help.

Hi Vlad, yeah, the RD1000 was a bit of a PITA due to its nature of not
notifying on device inerts/removals.


In your RunBefore Script run this first

runbefore-createmapperdevice.sh script:
--[snip]--
#!/bin/bash
#
# waa - 20110822
# --------------
# Unlock the encrypted partition and create the RD1000 mapper device
# !!! Your device may NOT be /dev/sdb - Make sure to check !!!
# -------------------------------------------------------------------
cryptsetup luksOpen --key-file=/path/to/Bacula_Key_File /dev/sdb RD1000

# exit code 239 means the mapper device is already created.. This is OK
# otherwise exit script with actual reported error code. Job should be
# configured to "Fail Job on Error = Yes"
# ---------------------------------------------------------------------
if [ $? !=  "0" ] && [ $? != "239" ]; then
   exit $?
fi

# This is actually important
# --------------------------
echo Sleeping for 5 seconds after creating /dev/mapper/RD1000
sleep 5

# waa - 20130314 - WTF??? - Note to vlad: I _think_
# some permissions had been changed, so this may
# not pertain to you
# ------------------------------------------------
chown bacula:bacula /dev/mapper/RD1000

exit 0
--[snip]--



In your RunBefore Script, run this second

runbefore-updateslots.sh script:
--[snip]--
#!/bin/bash
#
# waa - 20110822
#
BC="/usr/sbin/bconsole"
CONF="/path/to/bconsole.conf"
STORAGE="c0"
DRIVES="0"   # If multiple drives are defined in the changer
             # device bconsole will ask for a drive number
             # using any drive # here will suffice

echo "update slots storage=$STORAGE drive=$DRIVE" | $BC -c $CONF
--[snip]--


In your RunAfter Script run the runafter-removemapperdevice.sh script with a
parameter of 90 like so:

Run Script {
   Runs When = After
   Runs On Client = no
   Fail Job on Error = yes
   Runs on Failure = yes   # If Job fails, still release the RD1000
   Command = "/etc/bacula/include/runafter-removemapperdevice.sh 90"
}


runafter-removemapperdevice.sh script:
--[snip]--
#!/bin/bash
#
# waa - 20110822
# --------------
# The /mnt/RD1000/<UUID> is controlled by autofs, so after 20 seconds
# of inactivity the file system will already be unmounted, so we just
# need to make sure that we wait a little longer than that and then remove
# the crypto mapper device
sleep $1
cryptsetup luksClose RD1000
--[snip]--


> also, you mention that issue was/is random, what sort of errors were you
> getting. were you able to finally fix it?
> Thx

The random part that I think I remember to finally tracking down was a simple
5 second sleep being required before the update slots script was run AND even
more important was the 90 second sleep after the last job finished in the
runafter-removemapperdevice.sh script. You could also hard-code the sleep in
the script - I did it as a paramter in the RunAftrer script while testing... I
could firce an automount of the device, then test with different parameteres
and see how long it really needed. (or, at the time, if the delay would help
at all... wow fun times. Not really :)

You are going to have to play with this and see what your results are.  When
pasting this info from the actual scripts, I see a LOT of things I had tried
were commented out because the way autofs worked changed after my initial
roll-out, which caused more testing etc, but as it turns out this RD1000 is
behaving very well with these two simple runbefore scripts and the one
runafter script.


I posted this in a rush, if I missed something I apologize. Please ask if you
have any questions.


P.S. When I say "this RD1000 is behaving very well"   I mean that in the sense
of this server is 2.5 drive time hours away, and the customer is responsible
for ejecting and instering the RD1000 modules and since I implemented the
sleeps into the scripts there has not been an issue. So "behaving very well"
means I do not get any phone calls. :)

/me knocks on wood


:)

-- 
Bill Arlofski
Reverse Polarity, LLC
http://www.revpol.com/
-- Not responsible for anything below this line --

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users