
#include "bacula_template.inc" title="Tips and Suggestions" num=15

<H1>Tips and Suggestions</H1>

<h2><a name="upgrading">Upgrading Bacula Versions</a></h2>
The first thing to do before upgrading from one version to 
another is to ensure that don't overwrite your production
(current) version of <b>Bacula</b> until you have tested that the
new version works.  
<p>If you have installed <b>Bacula</b> into a single directory,
this is simple: simply make a copy of your <b>Bacula</b> directory.
<p>If you have done a more typical Unix installation where the
binaries are placed in one directory and the configuration files
are placed in another, then the simplest way is to configure
your new <b>Bacula</b> to go into a single file. 
<p>Whatever your situation may be (one of the two just described),
you should probably start with the <b>defaultconf</b> script that
can be found in the <b>examples</b> subdirectory. Copy this script
to the main Bacula directory, modify it as necessary (there should
not need to be many modifications), configure Bacula, build it,
install it, then stop your production Bacula, copy all the
<b>*.conf</b> files from your production Bacula directory to
the test Bacula directory, start the test version,
and run a few test backups.  If all seems good, then you can
proceed to install the new Bacula in place of or possibly over
the old Bacula.  
<p>When installing a new <b>Bacula</b> you need not worry about
losing the changes you made to your configuration files as
the installation process will not overwrite them.

<h2><a name="notification">Getting Notified of Job Completion</a></h2>
One of the first things you should do is to ensure that you are being
properly notified of the status of each Job run by Bacula, or at a minimum
of each Job that terminates with an error.
<p>Until you are completely comfortable with <b>Bacula</b>, we recommend
that you send an email to yourself for each Job that is run. This is
most easily accomplished by adding an email notification address in
the <b>Messages</b> resource of your Director's configuration file.
An email is automatically configured in the default configuration files,
but you must ensure that the default <b>root</b> address is replaced
by your email address.
<p>
For examples of how I (Kern) configure my system, please take a look
at the <b>.conf</b> files found in the <b>examples</b> sub-directory.
We recommend the following configuration (where you change the
paths and email address to correspond to your setup). Note, the
<b>mailcommand</b> and <b>operatorcommand</b> should be on a single
line. They were split here for presentation:
<pre>
Messages {
  Name = Standard
  mailcommand = "/home/bacula/bin/smtp -h localhost -f \"\(Bacula\) %r\" 
                -s \"Bacula: %t %e of %c %l\" %r"
  operatorcommand = "/home/bacula/bin/smtp -h localhost -f \"\(Bacula\) %r\" 
                    -s \"Bacula: Intervention needed for %j\" %r"
  Mail = your-email-address = all, !skipped, !terminate
  append = "/home/bacula/bin/log" = all, !skipped, !terminate
  operator = your-email-address = mount
  console = all, !skipped, !saved
}
</pre>

You will need to ensure that the <b>/home/bacula/bin</b> path on the 
<b>mailcommand</b> and the <b>operatorcommand</b> lines points to your
<b>Bacula</b> binary directory where the <b>smtp</b> program will be
installed.  You will also want to ensure that the <b>your-email-address</b>
is replaced by your email address, and finally, you will also need to
ensure that the <b>/home/bacula/bin/log</b> points to the file where you
want to log all messages.
<p>With the above Messages resource, you will be notified by email of
every Job that ran, all the output will be appended to the <b>log</b>
file you specify, all output will be directed to the console program,
and all mount messages will be emailed to you. Note, some messages
will be sent to multiple destinations.
<p>The form of the mailcommand is a bit complicated, but it allows you
to distinguish whether the Job terminated in error or terminated normally.
Please see the <a href="messagesres.html#mailcommand">Mail Command</a>
section of the Messages Resource chapter of this manual for 
the details of the substitution characters used above.
<p>
Once you are totally comfortable with <b>Bacula</b> as I am, or if you
have a large number of nightly Jobs as I do (eight), you will 
probably want to change the <b>Mail</b> command to <b>Mail On Error</b>
which will generate an email message only if the Job terminates in 
error. If the Job terminates normally, no email message will be sent,
but the output will still be appended to the log file as well as sent to
the Console program.

<h2><a name="email">Getting Email Notification to Work</a></h2>
The section above describes how to get email notification of job
status. Occasionally, however, users have problems receiving any
email at all.  In that case, the things to check are the following:
<ul>
  <li>Ensure that you have a valid email address specified on your
      <b>Mail</b> record in the Director's Messages resource. The email
      address should be fully qualified. Simply using <b>root</b> generally
      will not work, rather you should use <b>root@localhost</b> or better
      yet your full domain.</li>
  <li>Ensure that you do not have a <b>Mail</b> record in the Storage
      daemon's or File daemon's configuration files. The only record
      you should have is <b>director</b>:
      <pre>
      director = director-name = all
      </pre>
   <li>If all else fails, try replacing the <b>mailcommand</b> with
      <pre>
      mailcommand = "mail -s test your-email@domain.com"
      </pre>
      </li>
   <li>Once the above is working, assuming you want to use <b>smtp</b>,
       submit the desired smtp command by hand and ensure that the email
       is delivered, then put that command into <b>Bacula</b>.  Small
       differences in things such as the parenthesis around the word
       Bacula can make a big difference to some smtp programs.
       For example, you might start simply by using:
       <pre>
         mailcommand = "/home/bacula/bin/smtp -f \"root@localhost\" %r"
       </pre>
       </li>
</ul>
     

<h2><a name="JobNotification">Getting Notified that Bacula is Running</h2>
If like me, you have setup <b>Bacula</b> so that email is sent
only when a Job has errors, as described in the previous section
of this chapter, inevitably, one day, something will go wrong and
<b>Bacula</b> can stall.      
This could be because <b>Bacula</b> crashes, which is
vary rare, or more likely the network has caused <b>Bacula</b>
to <b>hang</b> for some unknown reason.
<p>To avoid this, you can use the <b>RunAfterJob</b> command  
in the Job resource to schedule a Job nightly, or weekly that
simply emails you a message saying that <b>Bacula</b> is
still running.
For example, I have setup the following Job in my Director's configuration
file:
<pre>
Schedule {
  Name = "Watchdog"
  Run = Level=Full sun-sat at 6:05
}

Job {
  Name = "Watchdog"
  Type = Admin
  Client=Watchdog
  FileSet="Verify Set"
  Messages = Standard
  Storage = DLTDrive
  Pool = Default
  Schedule = "Watchdog"
  RunAfterJob = "/home/kern/bacula/bin/watchdog"
}

Client {
  Name = Watchdog
  Address = rufus
  FDPort = 9102
  Catalog = Verify
  Password = ""
  File Retention = 1d                 # 1 days
  Job Retention = 1m                  # 1 month
  AutoPrune = yes                     # Prune expired Jobs/Files
}
</pre>
Where I established a schedule to run the Job nightly. The
Job itself is type <b>Admin</b> which means that it doesn't
actually do anything, and I've defined a FileSet, Pool, Storage,
and Client, all of which are not really used (and probably don't
need to be specified).  The key aspect of this Job is the
command:
<pre>
  RunAfterJob = "/home/kern/bacula/bin/watchdog"
</pre> 
which runs my &quot;watchdog&quot; script. 
You can put anything in the watchdog scrip. In my case,
I like to monitor the size of my catalog to be sure that
<b>Bacula</b> is really pruning it.        
The following is my watchdog script:
<pre>
\#!/bin/sh
cd /home/kern/mysql/var/bacula
du . * |
/home/kern/bacula/bin/smtp -f "\(Bacula\) abuse@whitehouse.com" -h mail.yyyy.com \\
                           -s "Bacula running" abuse@whitehouse.com                 
</pre>

If you just wish to send yourself a message, you can do it with:
<pre>
\#!/bin/sh
cd /home/kern/mysql/var/bacula
/home/kern/bacula/bin/smtp -f "\(Bacula\) abuse@whitehouse.com" -h mail.yyyy.com \\
                           -s "Bacula running" abuse@whitehouse.com &lt;&lt;END-OF-DATA 
Bacula is still running!!!
END-OF-DATA
</pre>

<h2><a name="bootstrap">Maintaining a Valid Bootstrap File</h2>
By using a <a href="dirdconf.html#writebootstrap">
<b>WriteBootstrap</b></a> record in each of your Director's
Job resources, you can constantly maintain a 
<a href="bootstrap.html"><b>bootstrap</b></a> file that
will enable you to recover the state of your system as of the last
backup without having the Bacula catalog. This permits you to 
more easily recover from a disaster that destroys your Bacula catalog.
<p>When a Job resource has a <b>WriteBootstrap</b> record, <b>Bacula</b> will
maintain the designated file (normally on another system but mounted by
NSF) with up to date information necessary to restore your system.
For example, in my Director's configuration file, I have the following
record:
<pre>
 Write Bootstrap = "/mnt/deuter/files/backup/client-name.bsr"
</pre>
where I replace <b>client-name</b> by the actual name of
the client that is being
backed up. Thus, <b>Bacula</b> automatically maintains one file
for each of my clients. The necessary bootstrap information is
appended to this file during each <b>Incremental</b> backup, and
the file is totally rewritten during each <b>Full</b> backup.
<p>
Note, one major disadvantage of writing to a NFS mounted volume
as I do is that if the other machine goes down, the OS will wait
forever on the fopen() call that Bacula makes. As a consequence,
Bacula will completely stall until the machine exporting the NSF
mounts comes back up. If someone knows a way around this, please
let me know.
<p>
If you are starting off in the middle of a cycle (i.e. with
Incremental backups) rather than at the beginning (with a Full
backup), the <b>bootstrap</b> file will not be immediately valid
as it must always have the information from a Full backup as the
first record.  If you wish to synchronize your bootstrap file 
immediately, you can do so by running a <b>restore</b> command
for the client and selecting a full restoration, but when
the restore command asks for confirmation to run the restore Job,
you simply reply no, then copy the bootstrap file that was
written to the location specified on the <b>Write Bootstrap</b>
record. The restore bootstrap file can be found in <b>restore.bsr</b>
in the working directory that you defined.  In the example given
below for the client <b>rufus</b>, my input is shown in bold. Note,
the JobId output has been partially truncated to fit on the page 
here:
<pre>
(in the Console program)
*<b>restore</b>
First you select one or more JobIds that contain files
to be restored. You will be presented several methods
of specifying the JobIds. Then you will be allowed to
select which files from those JobIds are to be restored.

To select the JobIds, you have the following choices:
     1: List last 20 Jobs run
     2: List Jobs where a given File is saved
     3: Enter list of JobIds to select
     4: Enter SQL list command
     5: Select the most recent backup for a client
     6: Cancel
Select item:  (1-6): <b>5</b>
The defined Client resources are:
     1: Minimatou
     2: Rufus
     3: Timmy
Select Client (File daemon) resource (1-3): <b>2</b>
The defined FileSet resources are:
     1: Kerns Files
Item 1 selected automatically.
<font size=-2>
+-------+-------+----------+-----------+---------+---------+----------+------------+
| JobId | Level | JobFiles | StartTime | VolName | StrtFil | VolSesId | VolSesTime |
+-------+-------+----------+-----------+---------+---------+----------+------------+
| 2     | F     | 84       |  ...      | test1   | 0       | 1        | 1035645259 |
+-------+-------+----------+-----------+---------+---------+----------+------------+
</font>
You have selected the following JobId: 2
Building directory tree for JobId 2 ...

The defined Storage resources are:
     1: File
Item 1 selected automatically.

You are now entering file selection mode where you add and
remove files to be restored. All files are initially added.
Enter "done" to leave this mode.

cwd is: /
$ <b>done</b>

84 files selected to restore.

Run Restore job
JobName:    kernsrestore
Bootstrap:  /home/kern/bacula/working/restore.bsr
Where:      /tmp/bacula-restores
FileSet:    Kerns Files
Client:     Rufus
Storage:    File
JobId:      *None*
OK to run? (yes/mod/no): <b>no</b>
<b>quit</b>

(in a shell window)
<b>cp ../working/restore.bsr /mnt/deuter/files/backup/rufus.bsr</b>
</pre>


<h2><a name="RejectedVolumes">Rejected Volumes After a Crash</a></h2>
Bacula keeps the number of files on each Volume in its
Catalog database so that before appending to a tape,
it can verify that the number of files are correct, and
thus prevent overwriting valid data.  If the Director
or the Storage daemon crashes before the job has completed,
the tape will contain one more file than is noted in the
Catalog, and the next time you attempt to use the same
Volume, Bacula will reject it due to a mismatch between
the physical tape and the catalog.
<p>
The easiest solution to this problem is to label a new
tape and start fresh. If you wish to continue appending
to the current tape, you can do so by using the
<b>update</b> command in the console program to 
change the <b>Volume Files</b> entry in the catalog.
A typical sequence of events would go like the following:
<pre>
- Bacula crashes
- You restart Bacula
</pre>
Bacula then prints:
<pre>
17-Jan-2003 16:45 rufus-dir: Start Backup JobId 13, 
                  Job=kernsave.2003-01-17_16.45.46
17-Jan-2003 16:45 rufus-sd: Volume test01 previously written, 
                  moving to end of data.
17-Jan-2003 16:46 rufus-sd: kernsave.2003-01-17_16.45.46 Error: 
                  I cannot write on this volume because:
                  The number of files mismatch! Volume=11 Catalog=10
17-Jan-2003 16:46 rufus-sd: Job kernsave.2003-01-17_16.45.46 waiting. 
                   Cannot find any appendable volumes.
Please use the "label"  command to create a new Volume for:
    Storage:      SDT-10000
    Media type:   DDS-4
    Pool:         Default
</pre>
(note, lines wrapped for presentation)<br>
To get out of this situation and use the same tape, you do the
following:
<pre>
<b>update</b>
Update choice:
     1: Volume parameters
     2: Pool from resource
     3: Slots from autochanger
Choose catalog item to update (1-3): <b>1</b>
Defined Pools:
     1: Default
     2: File
Select the Pool (1-2): 
<font size=-2>
+---------+---------+-----------+-----------+-----------+------+----------+------+------+
| MediaId | VolName | MediaType | VolStatus | VolBytes  | Last | VolReten | Recy | Slot |
+---------+---------+-----------+-----------+-----------+------+----------+------+------+
| 1       | test01  | DDS-4     | Error     | 352427156 | ...  | 31536000 | 1    | 0    |
+---------+---------+-----------+-----------+-----------+------+----------+------+------+
</font>
Enter MediaId or Volume name: <b>1</b>
</pre>
(note table output truncated for presentation)
First, you chose to update the Volume parameters by entering
a <b>1</b>. In the volume listing that follows,
notice how the VolStatus is <b>Error</b>. We will correct
that after changing the Volume Files. Continuing, you respond 1,
<pre>
Updating Volume "test01"
Parameters to modify:
     1: Volume Status
     2: Volume Retention Period
     3: Volume Use Duration
     4: Maximum Volume Jobs
     5: Maximum Volume Files
     6: Maximum Volume Bytes
     7: Recycle Flag
     8: Slot
     9: Volume Files
    10: Pool
    11: Done
Select parameter to modify (1-11): <b>9</b>
Warning changing Volume Files can result
in loss of data on your Volume

Current Volume Files is: 10
Enter new number of Files for Volume: <b>11</b>
New Volume Files is: 11
Updating Volume "test01"
Parameters to modify:
     1: Volume Status
     2: Volume Retention Period
     3: Volume Use Duration
     4: Maximum Volume Jobs
     5: Maximum Volume Files
     6: Maximum Volume Bytes
     7: Recycle Flag
     8: Slot
     9: Volume Files
    10: Pool
    11: Done
Select parameter to modify (1-10): <b>1</b>
</pre>
Here, you have selected <b>9</b> in order to update the
Volume Files, then you changed it from <b>10</b> to <b>11</b>,
and you now answer <b>1</b> to change the Volume Status.
<pre>
Current Volume status is: Error
Possible Values are:
     1: Append
     2: Archive
     3: Disabled
     4: Full
     5: Used
     6: Read-Only
Choose new Volume Status (1-6): <b>1</b>
New Volume status is: Append
Updating Volume "test01"
Parameters to modify:
     1: Volume Status
     2: Volume Retention Period
     3: Volume Use Duration
     4: Maximum Volume Jobs
     5: Maximum Volume Files
     6: Maximum Volume Bytes
     7: Recycle Flag
     8: Slot
     9: Volume Files
    10: Pool
    11: Done
Select parameter to modify (1-11): <b>11</b>
Selection done.
</pre>
At this point, you have changed the Volume Files from <b>10</b>
to <b>11</b> to account for the last file being written but not
updated in the database, and you changed the Volume Status back
to <b>Append</b>.
<p>
This was a lot of words to describe something quite simple.
<p>
The <b>Volume Files</b> option exists only in version 1.29 and
later, and you should be careful using it. Generally, if you
set the value to that which Bacula said is on the tape, you
will be OK, especially if the value is one more than what is
in the catalog.
   
<h2><a name="security">Security Considerations</a></h2>
Only the File daemon needs to run with root permission (so that it can
access all files). As a consequence, you may run your Director, Storage
daemon, and MySQL database server as non-root processes. Version 1.30
has the <b>-u</b> and the <b>-g</b> options that allow you to specify
a userid and groupid on the command line to be used after Bacula 
starts.

<p>You should protect the <b>Bacula</b> port addresses (normally 9101,
9102, and 9103) from outside access by a firewall or other means of
protection to prevent unauthorized use of your daemons.

<p>You should ensure that the configuration files are not world readable
since they contain passwords that allow access to the daemons. Anyone
who can access the Director using a console program can restore
any file from a backup Volume.           
 
<p>You should protect your Catalog database. If you are using SQLite,
make sure that the working directory is readable only by root (or your
Bacula userid), and ensure that <b>bacula.db</b> has permissions
<b>-rw-r--r--</b> (i.e. 640) or more strict. If you are using MySQL,
please note that the Bacula setup procedure leaves the database open
to anyone. At a minimum, you should assign the user <b>bacula</b>
a userid and add it to your Director's configuration file in the
appropriate Catalog resource.

<h2><a name="holiday">Creating Holiday Schedules</h2>
If you normally change tapes every day or at least every Friday, but Thursday
is a holiday, you can use a trick proposed by Lutz Kittler to ensure
that no job runs on Thursday so that you can insert Friday's tape and be
sure it will be used on Friday. To do so, define a <b>RunJobBefore</b> script
that normally returns zero, so that the Bacula job will normally continue.
You can then modify the script to return non-zero on any day when you
do not want Bacula to run the job.

<h2><a name="autolabel">Automatic Labeling Using Your Autochanger</h2>
If you have an autochanger but it does not support barcodes, using a 
&quot;trick&quot; you can make <b>Bacula</b> automatically label all
the volumes in your autochanger's magazine.  
<p>
First create a file containing one line for each slot in your autochanger
that has a tape to be labeled. The line will contain the slot number a 
colon (:) then the Volume name you want to use. For example, create
a file named <b>volume-list</b>, which contains: 
<pre>
1:Volume001
2:TestVolume02
5:LastVolume
</pre>
The records do not need to be in any order and you don't need to mention
all the slots.  Normally, you will have a consistent set of Volume names
and a sequential set of numbers for each slot you want labeled. In the
example above, I've left out slots 3 and 4 just as an example.
Now, modify your <b>mtx-changer</b> script and comment
out all the lines in the <b>list)</b> case by putting a # in column 1.
Then add the following two lines:
<pre>
  cat &lt;absolute-path&gt;/volume-list
  exit 0
</pre>
so that the whole case looks like:
<pre>
  list)
\#
\# commented out lines
   cat &lt;absolute-path&gt;/volume-list
   exit 0
   ;;
</pre>
where you replace &lt;absolute-path&gt; with the full path to the
volume-list file.  Then using the console, you enter the following
command:
<pre>
   label barcodes
</pre>
and Bacula will proceed to mount the autochanger Volumes in the list and label
them with the Volume names you have supplied. Bacula will think that the
list was provided by the autochanger barcodes, but in reality, it was you
who supplied the &lt;barcodes&gt;. 
<p>
If it seems to work, when it finishes, enter:
<pre>
   list volumes
</pre> 
and you should see all the volumes nicely created.

<h2><a name="clocks">Keep Your Client Machines' Clocks Synchronized to the Director</h2>
Please ensure that the clocks on all your client machines are 
synchronized with the clock on the server (Director) machine.  If they
are not synchronized or close, it is possible during an Incremental or
Differential backup that a file changed during the time difference
of the machines will not be backed up.  This is because the Client
uses the timestamp provided by the Director to determine whether or
not the files should be backed up.

<h2><a name="DNS">Backing Up Portables Using DHCP</h2>
You may want to backup laptops or portables that are not
always connected to the network. If you are using
DHCP to assign an IP address to those machines when they connect,
you will need to use the Dynamic Update capability of DNS
to assign a name to those machines that can be used in the
Address field of the Client resource in the Director's conf
file.

<h2><a name="Vacation">Going on Vacation</h2>
At some point, you may want to be absent for a week
or two and you want to make sure Bacula has enough
tape left so that the backups will complete.  
You start by doing a <b>list volumes</b> in the 
Console program:

<pre>
<b>list volumes</b>
 
Using default Catalog name=BackupDB DB=bacula
Pool: Default
+---------+---------------+-----------+-----------+----------------+-
| MediaId | VolumeName    | MediaType | VolStatus |       VolBytes | 
+---------+---------------+-----------+-----------+----------------+-
|      23 | DLT-30Nov02   | DLT8000   | Full      | 54,739,278,128 | 
|      24 | DLT-21Dec02   | DLT8000   | Full      | 56,331,524,629 | 
|      25 | DLT-11Jan03   | DLT8000   | Full      | 67,863,514,895 | 
|      26 | DLT-02Feb03   | DLT8000   | Full      | 63,439,314,216 | 
|      27 | DLT-03Mar03   | DLT8000   | Full      | 66,022,754,598 | 
|      28 | DLT-04Apr03   | DLT8000   | Full      | 60,792,559,924 | 
|      29 | DLT-28Apr03   | DLT8000   | Full      | 62,072,494,063 | 
|      30 | DLT-17May03   | DLT8000   | Full      | 65,901,767,839 | 
|      31 | DLT-07Jun03   | DLT8000   | Used      | 56,558,490,015 | 
|      32 | DLT-28Jun03   | DLT8000   | Full      | 64,274,871,265 | 
|      33 | DLT-19Jul03   | DLT8000   | Full      | 64,648,749,480 | 
|      34 | DLT-08Aug03   | DLT8000   | Full      | 64,293,941,255 | 
|      35 | DLT-24Aug03   | DLT8000   | Append    |  9,999,216,782 | 
+---------+---------------+-----------+-----------+----------------+
</pre>

Note, I have truncated the output for presentation purposes.
What is significant for is that I can see that my current tape
has almost 10 Gbytes of data, and that the average amount
of data I get on my tapes is about 60 Gbytes.  So if I go
on vacation now, I don't need to worry about tape capacity
(at least not for short absences).  
<p>
Equally significant is the fact that I did go on vacation the
28th of June 2003, and when I did the <b>list volumes</b>
command, my current tape at that time, DLT-07Jun03 MediaId 31,
had 56.5 Gbytes written. I could see that the
tape would fill shortly.  Consequently, I manually marked it
as <b>Used</b> and replaced it with a fresh tape that
I labeled as DLT-28Jun03, thus assuring myself that the
backups would all complete without my intervention.

<h2><a name="Case">How to Excude File on Windows Regardless of Case</h2>
This tip was submitted by Marc Brueckner who wasn't sure of
the case of some of his files on Win32, which is case insensitive.
The problem is that Bacula thinks that <b>/UNIMPORTANT FILES</b> is
different from <b>/Unimportant Files</b>. Marc was aware that
the file exclusion permits wild-cards. So, he specified:
<pre>
"/[Uu][Nn][Ii][Mm][Pp][Oo][Rr][Tt][Aa][Nn][Tt] [Ff][Ii][Ll][Ee][Ss]"
</pre>
As a consequence, the above exclude works for files of any case.
<p>
Please note that this works only in Bacula Exclude statement and
not in Include.

<h2><a name="RemoteExecution">Executing Scripts on a Remote Machine</h2>
This tip also comes from Marc Brueckner.
First I thought the "Run Before Job" statement in the Job-resource is 
for executing a script on the remote machine(the machine to be backed
up).  It could be usefull to execute scripts on the remote machine e.g.
for stopping databases or other services while doing the backup.  (Of
cause I have to start the services again when the backup has finished) I
found the following solution:

Bacula could execute scrips on the remote machine by using ssh.
The authentication is done automatically using a private key.
First You have to generate a keypair.
I ve done this by:
<pre>
ssh-keygen -b 4096 -t dsa -f Bacula_key
</pre>
This statement may take a little time to run. It creates
a public/private key pair with no pass phrase.
You could save the keys in /etc/bacula.
Now you have two new files : Bacula_key which contains the private key
and Bacula_key.pub which contains the public key.
<p>
Now you have to append the Bacula_key.pub file to the file 
authorized_keys in
the \root\.ssh directory of the remote machine.
Then you have to add (or uncomment) the line
<pre>
AuthorizedKeysFile      %h/.ssh/authorized_keys
</pre>
to the sshd_config file on the remote machine.
Where the %h stands for the home-directory of the user (root in this case).
<p>
Assuming that your sshd is already running on the remove machine,
you can now enter the folloing 
on the machine where Bacula runs:
<pre>
ssh -i Bacula_key <ip of remote machine> -l root "ls -la"
</pre>
This should execute the "ls -la" command on the remote machine.
<p>
Now you could add lines like the following to your Director's conf
file:
<pre>
...
Run Before Job = ssh -i /etc/bacula/Bacula_key 192.168.1.1 \
                 "/etc/init.d/database stop"
Run After Job = ssh -i /etc/bacula/Bacula_key 192.168.1.1 \
                 "/etc/init.d/database start"
...
</pre>
Even though Bacula version 1.32 has a ClientRunBeforeJob,
the ssh method still could be useful for updating all the Bacula clients on 
several remote machines in a single script.

<hr>

<page_prev name="Using Autochangers" url="autochangers.html">
<page_next name="Utility Programs" url="progs.html">
