--- /dev/null
+
+\section*{ANSI and IBM Tape Labels}
+\label{_ChapterStart62}
+\index[general]{ANSI and IBM Tape Labels}
+\index[general]{Labels!Tape}
+\addcontentsline{toc}{section}{ANSI and IBM Tape Labels}
+
+Bacula supports ANSI or IBM tape labels as long as you
+enable it. In fact, with the proper configuration, you can
+force Bacula to require ANSI or IBM labels.
+
+Bacula can create an ANSI or IBM label, but if Check Labels is
+enabled (see below), Bacula will look for an existing label, and
+if it is found, it will keep the label. Consequently, you
+can label the tapes with programs other than Bacula, and Bacula
+will recognize and support them.
+
+Even though Bacula will recognize and write ANSI and IBM labels,
+it always writes its own tape labels as well.
+
+When using ANSI or IBM tape labeling, you must restrict your Volume
+names to a maximum of 6 characters.
+
+If you have labeled your Volumes outside of Bacula, then the
+ANSI/IBM label will be recognized by Bacula only if you have created
+the HDR1 label with {\bf BACULA.DATA} in the Filename field (starting
+with character 5). If Bacula writes the labels, it will use
+this information to recognize the tape as a Bacula tape. This allows
+ANSI/IBM labeled tapes to be used at sites with multiple machines
+and multiple backup programs.
+
+
+\subsection*{Director Pool Directive}
+\addcontentsline{toc}{section}{Director Pool Directive}
+
+\begin{description}
+\item [ Label Type = ANSI | IBM | Bacula]
+ This directive is implemented in the Director Pool resource and in the SD Device
+ resource. If it is specified in the SD Device resource, it will take
+ precedence over the value passed from the Director to the SD. The default
+ is Label Type = Bacula.
+\end{description}
+
+\subsection*{Storage Daemon Device Directives}
+\addcontentsline{toc}{section}{Storage Daemon Device Directives}
+
+\begin{description}
+\item [ Label Type = ANSI | IBM | Bacula]
+ This directive is implemented in the Director Pool resource and in the SD Device
+ resource. If it is specified in the the SD Device resource, it will take
+ precedence over the value passed from the Director to the SD.
+
+\item [Check Labels = yes | no]
+ This directive is implemented in the the SD Device resource. If you intend
+ to read ANSI or IBM labels, this *must* be set. Even if the volume is
+ not ANSI labeled, you can set this to yes, and Bacula will check the
+ label type. Without this directive set to yes, Bacula will assume that
+ labels are of Bacula type and will not check for ANSI or IBM labels.
+ In other words, if there is a possibility of Bacula encountering an
+ ANSI/IBM label, you must set this to yes.
+\end{description}
--- /dev/null
+\subsection*{Autochanger Resource}
+\index[sd]{Autochanger Resource }
+\index[sd]{Resource!Autochanger }
+\addcontentsline{toc}{subsection}{Autochanger Resource}
+
+The Autochanger resource supports single or multiple drive
+autochangers by grouping one or more Device resources
+into one unit called an autochanger in Bacula (often referred to
+as a "tape library" by autochanger manufacturers).
+
+If you have an Autochanger, and you want it to function correctly,
+you {\bf must} have an Autochanger resource in your Storage
+conf file, and your Director's Storage directives that want to
+use an Autochanger {\bf must} refer to the Autochanger resource name.
+In previous versions of Bacula, the Director's Storage directives
+referred directly to Device resources that were autochangers.
+In version 1.38.0 and later, referring directly to Device resources
+will not work for Autochangers.
+
+\begin{description}
+\item [Name = \lt{}Autochanger-Name\gt{}]
+ \index[sd]{Name}
+ Specifies the Name of the Autochanger. This name is used in
+ the Director's Storage definition to refer to the autochanger.
+ This directive is required.
+
+\item [Device = \lt{}Device-name1, device-name2, ...\gt{}]
+ Specifies the names of the Device resource or
+ resources that correspond
+ to the autochanger drive. If you have a multiple drive
+ autochanger, you must specify multiple Device names, each
+ one referring to a separate Device resource that contains a the
+ Drive Index specification that corresponds to the drive
+ number. You may specify multiple device names on
+ a single line separated by commas, and/or you may specify
+ multiple Device directives.
+ This directive is required.
+
+\item [Changer Device = {\it name-string}]
+ \index[sd]{Changer Device}
+ The specified {\bf name-string} gives the system file name of the autochanger
+ device name. If specified in this resource, the Changer Device name
+ is not needed in the Device resource. If it is specified in the Device
+ resource (see above), it will take precedence over one specified in
+ the Autochanger resource.
+
+\item [Changer Command = {\it name-string}]
+ \index[sd]{Changer Command }
+ The {\bf name-string} specifies an external program to be called that will
+ automatically change volumes as required by {\bf Bacula}. Most frequently,
+ you will specify the Bacula supplied {\bf mtx-changer} script as follows.
+ If it is specified here, it need not be specified in the Device
+ resource. If it is also specified in the Device resource, it will take
+ precedence over the one specified in the Autochanger resource.
+
+\end{description}
+
+The following is an example of a valid Autochanger resource definition:
+
+\footnotesize
+\begin{verbatim}
+Autochanger {
+ Name = "DDS-4-changer"
+ Device = DDS-4-1, DDS-4-2, DDS-4-3
+ Changer Device = /dev/sg0
+ Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d"
+}
+Device {
+ Name = "DDS-4-1"
+ Drive Index = 0
+ Autochanger = yes
+ ...
+}
+Device {
+ Name = "DDS-4-2"
+ Drive Index = 1
+ Autochanger = yes
+ ...
+Device {
+ Name = "DDS-4-3"
+ Drive Index = 2
+ Autochanger = yes
+ Autoselect = no
+ ...
+}
+\end{verbatim}
+\normalsize
+
+Please note that it is important to include the {\bf Autochanger = yes} directive
+in each Device definition that belongs to an Autochanger. A device definition
+should not belong to more than one Autochanger resource. Also, your Device
+directive in the Storage resource of the Director's conf file should have
+the Autochanger's resource name rather than a name of one of the Devices.
+
+If you have a drive that physically belongs to an Autochanger but you don't want
+to have it automatically used when Bacula references the Autochanger for backups,
+for example, you want to reserve it for restores, you can add the directive:
+
+\footnotesize
+\begin{verbatim}
+Autoselect = no
+\end{verbatim}
+\normalsize
+
+to the Device resource for that drive. In that case, Bacula will not automatically
+select that drive when accessing the Autochanger. You can, still use the drive
+by referencing it by the Device name directly rather than the Autochanger name. An example
+of such a definition is shown above for the Device DDS-4-3, which will not be
+selected when the name DDS-4-changer is used in a Storage definition, but will
+be used if DDS-4-3 is used.
--- /dev/null
+%%
+%%
+%% The following characters must be preceded by a backslash
+%% to be entered as printable characters:
+%%
+%% # $ % & ~ _ ^ \ { }
+%%
+
+\subsection*{bimagemgr}
+\label{bimagemgr}
+\index[general]{Bimagemgr }
+\addcontentsline{toc}{subsection}{bimagemgr}
+
+{\bf bimagemgr} is a utility for those who backup to disk volumes in order to
+commit them to CDR disk, rather than tapes. It is a web based interface
+written in Perl and is used to monitor when a volume file needs to be burned to
+disk. It requires:
+
+\begin{itemize}
+\item A web server running on the bacula server
+\item A CD recorder installed and configured on the bacula server
+\item The cdrtools package installed on the bacula server.
+\item perl, perl-DBI module, and either DBD-MySQL DBD-SQLite or DBD-PostgreSQL modules
+ \end{itemize}
+
+DVD burning is not supported by {\bf bimagemgr} at this
+time, but both are planned for future releases.
+
+\subsubsection*{bimagemgr installation}
+\index[general]{bimagemgr!Installation }
+\index[general]{bimagemgr Installation }
+\addcontentsline{toc}{subsubsection}{bimagemgr Installation}
+
+Installation from tarball:
+1. Examine the Makefile and adjust it to your configuration if needed.
+2. Edit config.pm to fit your configuration.
+3. Do 'make install' as root.
+4. Edit httpd.conf and change the Timeout value. The web server must not time
+out and close the connection before the burn process is finished. The exact
+value needed may vary depending upon your cd recorder speed and whether you are
+burning on the bacula server on on another machine across your network. In my
+case I set it to 1000 seconds. Restart httpd.
+5. Make sure that cdrecord is setuid root.
+
+Installation from rpm package:
+1. Install the rpm package for your platform.
+2. Edit /cgi-bin/config.pm to fit your configuration.
+3. Edit httpd.conf and change the Timeout value. The web server must not time
+out and close the connection before the burn process is finished. The exact
+value needed may vary depending upon your cd recorder speed and whether you are
+burning on the bacula server on on another machine across your network. In my
+case I set it to 1000 seconds. Restart httpd.
+4. Make sure that cdrecord is setuid root.
+
+For bacula systems less than 1.36:
+1. Edit the configuration section of config.pm to fit your configuration.
+2. Run /etc/bacula/create\_cdimage\_table.pl from a console on your bacula
+server (as root) to add the CDImage table to your bacula database.
+
+Accessing the Volume files:
+The Volume files by default have permissions 640 and can only be read by root.
+The recommended approach to this is as follows (and only works if bimagemgr and
+apache are running on the same host as bacula.
+
+For bacula-1.34 or 1.36 installed from tarball -
+1. Create a new user group bacula and add the user apache to the group for
+Red Hat or Mandrake systems. For SuSE systems add the user wwwrun to the
+bacula group.
+2. Change ownership of all of your Volume files to root.bacula
+3. Edit the /etc/bacula/bacula startup script and set SD\_USER=root and
+SD\_GROUP=bacula. Restart bacula.
+
+Note: step 3 should also be done in /etc/init.d/bacula-sd but released versions
+of this file prior to 1.36 do not support it. In that case it would be necessary after
+a reboot of the server to execute '/etc/bacula/bacula restart'.
+
+For bacula-1.38 installed from tarball -
+1. Your configure statement should include:
+ --with-dir-user=bacula
+ --with-dir-group=bacula
+ --with-sd-user=bacula
+ --with-sd-group=disk
+ --with-fd-user=root
+ --with-fd-group=bacula
+2. Add the user apache to the bacula group for Red Hat or Mandrake systems.
+For SuSE systems add the user wwwrun to the bacula group.
+3. Check/change ownership of all of your Volume files to root.bacula
+
+For bacula-1.36 or bacula-1.38 installed from rpm -
+1. Add the user apache to the group bacula for Red Hat or Mandrake systems.
+For SuSE systems add the user wwwrun to the bacula group.
+2. Check/change ownership of all of your Volume files to root.bacula
+
+bimagemgr installed from rpm > 1.38.9 will add the web server user to the
+bacula group in a post install script. Be sure to edit the configuration
+information in config.pm after installation of rpm package.
+
+bimagemgr will now be able to read the Volume files but they are still not
+world readable.
+
+If you are running bimagemgr on another host (not recommended) then you will
+need to change the permissions on all of your backup volume files to 644 in
+order to access them via nfs share or other means. This approach should only
+be taken if you are sure of the security of your environment as it exposes
+the backup Volume files to world read.
+
+\subsubsection*{bimagemgr usage}
+\index[general]{bimagemgr!Usage }
+\index[general]{bimagemgr Usage }
+\addcontentsline{toc}{subsubsection}{bimagemgr Usage}
+
+Calling the program in your web browser, e.g. {\tt
+http://localhost/cgi-bin/bimagemgr.pl} will produce a display as shown below
+in Figure 1. The program will query the bacula database and display all volume
+files with the date last written and the date last burned to disk. If a volume
+needs to be burned (last written is newer than last burn date) a "Burn"
+button will be displayed in the rightmost column.
+
+\addcontentsline{lof}{figure}{Bacula CD Image Manager}
+\includegraphics{./bimagemgr1.eps} \\Figure 1
+
+Place a blank CDR disk in your recorder and click the "Burn" button. This will
+cause a pop up window as shown in Figure 2 to display the burn progress.
+
+\addcontentsline{lof}{figure}{Bacula CD Image Burn Progress Window}
+\includegraphics{./bimagemgr2.eps} \\Figure 2
+
+When the burn finishes the pop up window will display the results of cdrecord
+as shown in Figure 3. Close the pop up window and refresh the main window. The
+last burn date will be updated and the "Burn" button for that volume will
+disappear. Should you have a failed burn you can reset the last burn date of
+that volume by clicking its "Reset" link.
+
+\addcontentsline{lof}{figure}{Bacula CD Image Burn Results}
+\includegraphics{./bimagemgr3.eps} \\Figure 3
+
+In the bottom row of the main display window are two more buttons labeled
+"Burn Catalog" and "Blank CDRW". "Burn Catalog" will place a copy of
+your bacula catalog on a disk. If you use CDRW disks rather than CDR then
+"Blank CDRW" allows you to erase the disk before re-burning it. Regularly
+committing your backup volume files and your catalog to disk with {\bf
+bimagemgr} ensures that you can rebuild easily in the event of some disaster
+on the bacula server itself.
--- /dev/null
+%%
+%%
+
+\section*{DVD Volumes}
+\label{_DVDChapterStart}
+\index[general]{DVD Volumes}
+\index[general]{Writing DVDs}
+\index[general]{DVD Writing}
+\index[general]{Volumes!DVD}
+\addcontentsline{toc}{section}{DVD Volumes}
+
+Bacula allows you to specify that you want to write to DVD. However,
+this feature is implemented only in version 1.37 or later.
+You may in fact write to DVD+RW, DVD+R, DVD-R, or DVD-RW
+media. The actual process used by Bacula is to first write
+the image to a spool directory, then when the Volume reaches
+a certain size or, at your option, at the end of a Job, Bacula
+will transfer the image from the spool directory to the
+DVD. The actual work of transferring the image is done
+by a script {\bf dvd-handler}, and the heart of that
+script is a program called {\bf growisofs} which allows
+creating or adding to a DVD ISO filesystem.
+
+You must have {\bf dvd+rw-tools} loaded on your system for DVD writing to
+work. Please note that the original {\bf dvd+rw-tools} package does {\bf
+NOT} work with Bacula. You must apply a patch which can be found in the
+{\bf patches} directory of Bacula sources with the name
+{\bf dvd+rw-tools-5.21.4.10.8.bacula.patch}.
+
+The fact that Bacula cannot use the OS to write directly
+to the DVD makes the whole process a bit more error prone than
+writing to a disk or a tape, but nevertheless, it does work if you
+use some care to set it up properly. However, at the current time
+(28 October 2005) we still consider this code to be experimental and of
+BETA quality. As a consequence, please do careful testing before relying
+on DVD backups in production.
+
+The remainder of this chapter explains the various directives that you can
+use to control the DVD writing.
+
+\label{DVDdirectives}
+
+\subsection*{DVD Specific SD Directives}
+\index[general]{Directives!DVD}
+\index[general]{DVD Specific SD Directives }
+\addcontentsline{toc}{subsection}{DVD Specific SD Directives}
+
+The following directives are added to the Storage daemon's
+Device resource.
+
+\begin{description}
+
+\item [Requires Mount = {\it Yes|No}]
+ \index[sd]{Requires Mount }
+ You must set this directive to {\bf yes} for DVD-writers, and to {\bf no} for
+ all other devices (tapes/files). This directive indicates if the device
+ requires to be mounted using the {\bf Mount Command}.
+ To be able to write a DVD, the following directives must also be
+ defined: {\bf Mount Point}, {\bf Mount Command}, {\bf Unmount Command} and
+ {\bf Write Part Command}.
+
+\item [Mount Point = {\it directory}]
+ \index[sd]{Mount Point}
+ Directory where the device can be mounted.
+
+\item [Mount Command = {\it name-string}]
+ \index[sd]{Mount Command}
+ Command that must be executed to mount the device. Although the
+ device is written directly, the mount command is necessary in
+ order to determine the free space left on the DVD. Before the command is
+ executed, \%a is replaced with the Archive Device, and \%m with the Mount
+ Point.
+
+ Most frequently, you will define it as follows:
+
+\footnotesize
+\begin{verbatim}
+ Mount Command = "/bin/mount -t iso9660 -o ro %a %m"
+\end{verbatim}
+\normalsize
+
+\item [Unmount Command = {\it name-string}]
+ \index[sd]{Unmount Command}
+ Command that must be executed to unmount the device. Before the command is
+ executed, \%a is replaced with the Archive Device, and \%m with the Mount
+ Point.
+
+ Most frequently, you will define it as follows:
+
+\footnotesize
+\begin{verbatim}
+ Unmount Command = "/bin/umount %m"
+\end{verbatim}
+\normalsize
+
+\item [Write Part Command = {\it name-string}]
+ \index[sd]{Write Part Command }
+ Command that must be executed to write a part to the device. Before the
+ command is executed, \%a is replaced with the Archive Device, \%m with the
+ Mount Point, \%e is replaced with 1 if we are writing the first part,
+ and with 0 otherwise, and \%v with the current part filename.
+
+ For a DVD, you will most frequently specify the Bacula supplied {\bf
+ dvd-handler} script as follows:
+
+\footnotesize
+\begin{verbatim}
+ Write Part Command = "/path/dvd-handler %a write %e %v"
+\end{verbatim}
+\normalsize
+
+ Where {\bf /path} is the path to your scripts install directory, and
+ dvd-handler is the Bacula supplied script file.
+ This command will already be present, but commented out,
+ in the default bacula-sd.conf file. To use it, simply remove
+ the comment (\#) symbol.
+
+
+\item [Free Space Command = {\it name-string}]
+ \index[sd]{Free Space Command }
+ Command that must be executed to check how much free space is left on the
+ device. Before the command is executed,\%a is replaced with the Archive
+ Device, \%m with the Mount Point, \%e is replaced with 1 if we are writing
+ the first part, and with 0 otherwise, and \%v with the current part filename.
+
+ For a DVD, you will most frequently specify the Bacula supplied {\bf
+ dvd-handler} script as follows:
+
+\footnotesize
+\begin{verbatim}
+ Free Space Command = "/path/dvd-handler %a free"
+\end{verbatim}
+\normalsize
+
+ Where {\bf /path} is the path to your scripts install directory, and
+ dvd-freespace is the Bacula supplied script file.
+ If you want to specify your own command, please look at the code in
+ dvd-handler to see what output Bacula expects from this command.
+ This command will already be present, but commented out,
+ in the default bacula-sd.conf file. To use it, simply remove
+ the comment (\#) symbol.
+
+ If you do not set it, Bacula will expect there is always free space on the
+ device.
+
+\end{description}
+
+In addition to the directives specified above, you must also
+specify the other standard Device resource directives. Please see the
+sample DVD Device resource in the default bacula-sd.conf file. Be sure
+to specify the raw device name for {\bf Archive Device}. It should
+be a name such as {\bf /dev/cdrom} or {\bf /media/cdrecorder} or
+{\bf /dev/dvd} depending on your system. It will not be a name such
+as {\bf /mnt/cdrom}.
+
+
+\subsection*{DVD Specific Director Directives}
+\index[general]{Directives!DVD}
+\index[general]{DVD Specific Director Directives }
+\addcontentsline{toc}{subsection}{DVD Specific Director Directives}
+
+The following directives are added to the Director's Job resource.
+
+\label{WritePartAfterJob}
+\begin{description}
+\item [Write Part After Job = \lt{}yes|no\gt{}]
+ \index[dir]{Write Part After Job }
+ If this directive is set to {\bf yes} (default {\bf no}), the
+ Volume written to a temporary spool file for the current Job will
+ be written to the DVD as a new part file
+ will be created after the job is finished.
+
+ It should be set to {\bf yes} when writing to devices that require a mount
+ (for example DVD), so you are sure that the current part, containing
+ this job's data, is written to the device, and that no data is left in
+ the temporary file on the hard disk. However, on some media, like DVD+R
+ and DVD-R, a lot of space (about 10Mb) is lost everytime a part is
+ written. So, if you run several jobs each after another, you could set
+ this directive to {\bf no} for all jobs, except the last one, to avoid
+ wasting too much space, but to ensure that the data is written to the
+ medium when all jobs are finished.
+
+ This directive is ignored for devices other than DVDs.
+\end{description}
+
+
+
+\label{DVDpoints}
+\subsection*{Other Points}
+\index[general]{Points!Other }
+\index[general]{Other Points }
+\addcontentsline{toc}{subsection}{Other Points}
+
+\begin{itemize}
+\item Writing and reading of DVD+RW seems to work quite reliably
+ provided you are using the patched dvd+rw-mediainfo programs.
+ On the other hand, we do not have enough information to ensure
+ that DVD-RW or other forms of DVDs work correctly.
+\item DVD+RW supports only about 1000 overwrites. Every time you
+ mount the filesystem read/write will count as one write. This can
+ add up quickly, so it is best to mount your DVD+RW filesystem read-only.
+ Bacula does not need the DVD to be mounted read-write, since it uses
+ the raw device for writing.
+\item Reformatting DVD+RW 10-20 times can apparently make the medium
+ unusable. Normally you should not have to format or reformat
+ DVD+RW media. If it is necessary, current versions of growisofs will
+ do so automatically.
+\item We have had several problems writing to DVD-RWs (this does NOT
+ concern DVD+RW), because these media have two writing-modes: {\bf
+ Incremental Sequential} and {\bf Restricted Overwrite}. Depending on
+ your device and the media you use, one of these modes may not work
+ correctly (e.g. {\bf Incremental Sequential} does not work with my NEC
+ DVD-writer and Verbatim DVD-RW).
+
+ To retrieve the current mode of a DVD-RW, run:
+\begin{verbatim}
+ dvd+rw-mediainfo /dev/xxx
+\end{verbatim}
+ where you replace xxx with your DVD device name.
+
+ {\bf Mounted Media} line should give you the information.
+
+ To set the device to {\bf Restricted Overwrite} mode, run:
+\begin{verbatim}
+ dvd+rw-format /dev/xxx
+\end{verbatim}
+ If you want to set it back to the default {\bf Incremental Sequential} mode, run:
+\begin{verbatim}
+ dvd+rw-format -blank /dev/xxx
+\end{verbatim}
+
+\item Bacula only accepts to write to blank DVDs. To quickly blank a DVD+/-RW, run
+ this command:
+\begin{verbatim}
+ dd if=/dev/zero bs=1024 count=512 | growisofs -Z /dev/xxx=/dev/fd/0
+\end{verbatim}
+ Then, try to mount the device, if it cannot be mounted, it will be considered
+ as blank by Bacula, if it can be mounted, try a full blank (see below).
+
+\item If you wish to blank completely a DVD+/-RW, use the following:
+\begin{verbatim}
+ growisofs -Z /dev/xxx=/dev/zero
+\end{verbatim}
+ where you replace xxx with your DVD device name. However, note that this
+ blanks the whole DVD, which takes quite a long time (16 minutes on mine).
+\item DVD+RW and DVD-RW support only about 1000 overwrites (i.e. don't use the
+same medium for years if you don't want to have problems...).
+
+\item For more informations about DVD writing, please look at the
+\elink{dvd+rw-tools homepage}{http://fy.chalmers.se/~appro/linux/DVD+RW/}.
+\end{itemize}
--- /dev/null
+img20.png\ 1./tray-icon.eps
+img11.png\ 1./win32-nsis.eps
+img3.png\ 1./bacula-objects.eps
+img15.png\ 1./win32-service.eps
+img14.png\ 1./win32-location.eps
+img22.png\ 1./running.eps
+img21.png\ 1./menu.eps
+img10.png\ 1./bimagemgr3.eps
+img8.png\ 1./bimagemgr1.eps
+img28.png\ 1./confirm.eps
+img23.png\ 1./error.eps
+img25.png\ 1./view-only.eps
+img19.png\ 1./idle.eps
+img1.png\ 1./bacula-logo.eps
+img24.png\ 1./access-is-denied.eps
+img16.png\ 1./win32-service-ok.eps
+img6.png\ 1./Conf-Diagram.eps
+img13.png\ 1./win32-pkg.eps
+img4.png\ 1./flow.eps
+img12.png\ 1./win32-welcome.eps
+img26.png\ 1./properties-security.eps
+img17.png\ 1./win32-start.eps
+img9.png\ 1./bimagemgr2.eps
+img27.png\ 1./properties-security-advanced-owner.eps
+img18.png\ 1./win32-finish.eps
+img5.png\ 1./Bacula-tray-monitor.eps
+img2.png\ 1./bacula-applications.eps
\newcommand\lthtmlboxmathZ{\@next\next\@currlist{}{\def\next{\voidb@x}}%
\expandafter\box\next\egroup}%
\newcommand\lthtmlmathtype[1]{\gdef\lthtmlmathenv{#1}}%
-\newcommand\lthtmllogmath{\dimen0\ht\sizebox \advance\dimen0\dp\sizebox
- \ifdim\dimen0>.95\vsize
- \lthtmltypeout{%
-*** image for \lthtmlmathenv\space is too tall at \the\dimen0, reducing to .95 vsize ***}%
- \ht\sizebox.95\vsize \dp\sizebox\z@ \fi
- \lthtmltypeout{l2hSize %
+\newcommand\lthtmllogmath{\lthtmltypeout{l2hSize %
:\lthtmlmathenv:\the\ht\sizebox::\the\dp\sizebox::\the\wd\sizebox.\preveqno}}%
\newcommand\lthtmlfigureA[1]{\let\@savefreelist\@freelist
\lthtmlmathtype{#1}\lthtmlvboxmathA}%
% !!! IMAGES START HERE !!!
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap26326}%
+\lthtmlpictureA{tex2html_wrap27795}%
\includegraphics{./bacula-logo.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap26333}%
+\lthtmlpictureA{tex2html_wrap27802}%
\includegraphics{./bacula-applications.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap26335}%
+\lthtmlpictureA{tex2html_wrap27804}%
\includegraphics{./bacula-objects.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap26341}%
+\lthtmlpictureA{tex2html_wrap27810}%
\includegraphics{./flow.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap26542}%
+\lthtmlpictureA{tex2html_wrap28011}%
\includegraphics{./Bacula-tray-monitor.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap26681}%
+\lthtmlpictureA{tex2html_wrap28150}%
\includegraphics{./Conf-Diagram.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlinlinemathA{tex2html_wrap_inline6459}%
-$2^{31}$%
-\lthtmlinlinemathZ
-\lthtmlcheckvsize\clearpage}
-
-{\newpage\clearpage
-\lthtmlfigureA{center26724}%
-\begin{center}\vbox{\input{autochangerres}
-}\end{center}%
-\lthtmlfigureZ
-\lthtmlcheckvsize\clearpage}
-
-{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap26781}%
+\lthtmlpictureA{tex2html_wrap28250}%
\includegraphics{./bimagemgr1.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap26782}%
+\lthtmlpictureA{tex2html_wrap28251}%
\includegraphics{./bimagemgr2.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap26783}%
+\lthtmlpictureA{tex2html_wrap28252}%
\includegraphics{./bimagemgr3.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlfigureA{figure26784}%
-\begin{figure}\vbox{\include{bimagemgr-chapter}
-}\end{figure}%
-\lthtmlfigureZ
-\lthtmlcheckvsize\clearpage}
-
-{\newpage\clearpage
-\lthtmlfigureA{figure26815}%
-\begin{figure}\vbox{\include{dvd}
-}\end{figure}%
-\lthtmlfigureZ
-\lthtmlcheckvsize\clearpage}
-
-{\newpage\clearpage
-\lthtmlfigureA{figure27075}%
-\begin{figure}\vbox{\include{python}
-}\end{figure}%
-\lthtmlfigureZ
-\lthtmlcheckvsize\clearpage}
-
-{\newpage\clearpage
-\lthtmlfigureA{figure27076}%
-\begin{figure}\vbox{\include{ansi-labels}
-}\end{figure}%
-\lthtmlfigureZ
-\lthtmlcheckvsize\clearpage}
-
-{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27195}%
+\lthtmlpictureA{tex2html_wrap28681}%
\includegraphics{./win32-nsis.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27196}%
+\lthtmlpictureA{tex2html_wrap28682}%
\includegraphics{./win32-welcome.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27197}%
+\lthtmlpictureA{tex2html_wrap28683}%
\includegraphics{./win32-pkg.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27198}%
+\lthtmlpictureA{tex2html_wrap28684}%
\includegraphics{./win32-location.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27199}%
+\lthtmlpictureA{tex2html_wrap28685}%
\includegraphics{./win32-service.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27200}%
+\lthtmlpictureA{tex2html_wrap28686}%
\includegraphics{./win32-service-ok.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27201}%
+\lthtmlpictureA{tex2html_wrap28687}%
\includegraphics{./win32-start.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27202}%
+\lthtmlpictureA{tex2html_wrap28688}%
\includegraphics{./win32-finish.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27203}%
+\lthtmlpictureA{tex2html_wrap28689}%
\includegraphics{./idle.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27204}%
+\lthtmlpictureA{tex2html_wrap28690}%
\includegraphics{./tray-icon.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27205}%
+\lthtmlpictureA{tex2html_wrap28691}%
\includegraphics{./menu.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27206}%
+\lthtmlpictureA{tex2html_wrap28692}%
\includegraphics{./running.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27207}%
+\lthtmlpictureA{tex2html_wrap28693}%
\includegraphics{./error.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27288}%
+\lthtmlpictureA{tex2html_wrap28774}%
\includegraphics{./access-is-denied.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27289}%
+\lthtmlpictureA{tex2html_wrap28775}%
\includegraphics{./view-only.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27290}%
+\lthtmlpictureA{tex2html_wrap28776}%
\includegraphics{./properties-security.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27291}%
+\lthtmlpictureA{tex2html_wrap28777}%
\includegraphics{./properties-security-advanced-owner.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27292}%
+\lthtmlpictureA{tex2html_wrap28778}%
\includegraphics{./confirm.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
-{\newpage\clearpage
-\lthtmlfigureA{figure27456}%
-\begin{figure}\vbox{\include{fdl}
-}\end{figure}%
-\lthtmlfigureZ
-\lthtmlcheckvsize\clearpage}
-
\end{document}
--- /dev/null
+%%
+%%
+
+\section*{Python Scripting}
+\label{_ChapterStart60}
+\index[general]{Python Scripting}
+\index[general]{Scripting!Python}
+\addcontentsline{toc}{section}{Python Scripting}
+
+You may be asking what Python is and why a scripting language is
+needed in Bacula. The answer to the first question is that Python
+is an Object Oriented scripting language with features similar
+to those found in Perl, but the syntax of the language is much
+cleaner and simpler. The answer to why have scripting in Bacula is to
+give the user more control over the whole backup process. Probably
+the simplest example is when Bacula needs a new Volume name, with
+a scripting language such as Python, you can generate any name
+you want, based on the current state of Bacula.
+
+\subsection*{Python Configuration}
+\index[general]{Python Configuration}
+\index[general]{Configuration!Python}
+\addcontentsline{toc}{subsection}{Python Configuration}
+
+Python must be enabled during the configuration process by adding
+a \verb:--:with-python, and possibly specifying an alternate
+directory if your Python is not installed in a standard system
+location. If you are using RPMs you will need the python-devel package
+installed.
+
+When Python is configured, it becomes an integral part of Bacula and
+runs in Bacula's address space, so even though it is an interpreted
+language, it is very efficient.
+
+When the Director starts, it looks to see if you have a {\bf
+Scripts Directory} Directive defined (normal default {\bf
+/etc/bacula/scripts}, if so, it looks in that directory for a file named
+{\bf DirStartUp.py}. If it is found, Bacula will pass this file to Python
+for execution. The {\bf Scripts Directory} is a new directive that you add
+to the Director resource of your bacula-dir.conf file.
+
+Note: Bacula does not install Python scripts by default because these
+scripts are for you to program. This means that with a default
+installation with Python enabled, Bacula will print the following error
+message:
+
+\begin{verbatim}
+09-Jun 15:14 bacula-dir: ERROR in pythonlib.c:131 Could not import
+Python script /etc/bacula/scripts/DirStartUp. Python disabled.
+\end{verbatim}
+
+The source code directory {\bf examples/python} contains sample scripts
+for DirStartUp.py, SDStartUp.py, and FDStartUp.py that you might want
+to use as a starting point. Normally, your scripts directory (at least
+where you store the Python scripts) should be writable by Bacula, because
+Python will attempt to write a compiled version of the scripts (e.g.
+DirStartUp.pyc) back to that directory.
+
+When starting with the sample scripts, you can delete any part that
+you will not need, but you should keep all the Bacula Event and Job Event
+definitions. If you do not want a particular event, simply replace the
+existing code with a {\bf noop = 1}.
+
+\subsection*{Bacula Events}
+\index[general]{Bacula Events}
+\index[general]{Events}
+\addcontentsline{toc}{subsection}{Bacula Events}
+A Bacula event is a point in the Bacula code where Bacula
+will call a subroutine (actually a method) that you have
+defined in the Python StartUp script. Events correspond
+to some significant event such as a Job Start, a Job End,
+Bacula needs a new Volume Name, ... When your script is
+called, it will have access to all the Bacula variables
+specific to the Job (attributes of the Job Object), and
+it can even call some of the Job methods (subroutines)
+or set new values in the Job attributes, such as the
+Priority. You will see below how the events are used.
+
+\subsection*{Python Objects}
+\index[general]{Python Objects}
+\index[general]{Objects!Python}
+\addcontentsline{toc}{subsection}{Python Objects}
+
+There are four Python objects that you will need to work with:
+\begin{description}
+\item [The Bacula Object]
+ The Bacula object is created by the Bacula daemon (the Director
+ in the present case) when the daemon starts. It is available to
+ the Python startup script, {\bf DirStartup.py}, by importing the
+ Bacula definitions with {\bf import bacula}. The methods
+ available with this object are described below.
+
+\item [The Bacula Events Class]
+ You create this class in the startup script, and you pass
+ it to the Bacula Object's {\bf set\_events} method. The
+ purpose of the Bacula Events Class is to define what global
+ or daemon events you want to monitor. When one of those events
+ occurs, your Bacula Events Class will be called at the method
+ corresponding to the event. There are currently three events,
+ JobStart, JobEnd, and Exit, which are described in detail below.
+
+\item [The Job Object]
+ When a Job starts, and assuming you have defined a JobStart method
+ in your Bacula Events Class, Bacula will create a Job Object. This
+ object will be passed to the JobStart event. The Job Object has a
+ has good number of read-only members or attributes providing many
+ details of the Job, and it also has a number of writable attributes
+ that allow you to pass information into the Job. These attributes
+ are described below.
+
+\item [The Job Events Class]
+ You create this class in the JobStart method of your Bacula Events
+ class, and it allows you to define which of the possible Job Object
+ events you want to see. You must pass an instance of your Job Events
+ class to the Job Object set\_events() method.
+ Normally, you will probably only have one
+ Job Events Class, which will be instantiated for each Job. However,
+ if you wish to see different events in different Jobs, you may have
+ as many Job Events classes as you wish.
+\end{description}
+
+
+The first thing the startup script must do is to define what global Bacula
+events (daemon events), it wants to see. This is done by creating a
+Bacula Events class, instantiating it, then passing it to the
+{\bf set\_events} method. There are three possible
+events.
+
+\begin{description}
+\item [JobStart]
+ \index[dir]{JobStart}
+ This Python method, if defined, will be called each time a Job is started.
+ The method is passed the class instantiation object as the first argument,
+ and the Bacula Job object as the second argument. The Bacula Job object
+ has several built-in methods, and you can define which ones you
+ want called. If you do not define this method, you will not be able
+ to interact with Bacula jobs.
+
+\item [JobEnd]
+ This Python method, if defined, will be called each time a Job terminates.
+ The method is passed the class instantiation object as the first argument,
+ and the Bacula Job object as the second argument.
+
+\item [Exit]
+ This Python method, if defined, will be called when the Director terminates.
+ The method is passed the class instantiation object as the first argument.
+\end{description}
+
+Access to the Bacula variables and methods is done with:
+
+ import bacula
+
+The following are the read-only attributes provided by the bacula object.
+\begin{description}
+\item [Name]
+\item [ConfigFile]
+\item [WorkingDir]
+\item [Version] string consisting of "Version Build-date"
+\end{description}
+
+
+A simple definition of the Bacula Events Class might be the following:
+
+\footnotesize
+\begin{verbatim}
+import sys, bacula
+class BaculaEvents:
+ def JobStart(self, job):
+ ...
+\end{verbatim}
+\normalsize
+
+Then to instantiate the class and pass it to Bacula, you
+would do:
+
+\footnotesize
+\begin{verbatim}
+bacula.set_events(BaculaEvents()) # register Bacula Events wanted
+\end{verbatim}
+\normalsize
+
+And at that point, each time a Job is started, your BaculaEvents JobStart
+method will be called.
+
+Now to actually do anything with a Job, you must define which Job events
+you want to see, and this is done by defining a JobEvents class containing
+the methods you want called. Each method name corresponds to one of the
+Job Events that Bacula will generate.
+
+A simple Job Events class might look like the following:
+
+\footnotesize
+\begin{verbatim}
+class JobEvents:
+ def NewVolume(self, job):
+ ...
+\end{verbatim}
+\normalsize
+
+Here, your JobEvents class method NewVolume will be called each time
+the Job needs a new Volume name. To actually register the events defined
+in your class with the Job, you must instantiate the JobEvents class and
+set it in the Job {\bf set\_events} variable. Note, this is a bit different
+from how you registered the Bacula events. The registration process must
+be done in the Bacula JobStart event (your method). So, you would modify
+Bacula Events (not the Job events) as follows:
+
+\footnotesize
+\begin{verbatim}
+import sys, bacula
+class BaculaEvents:
+ def JobStart(self, job):
+ events = JobEvents() # create instance of Job class
+ job.set_events(events) # register Job events desired
+ ...
+\end{verbatim}
+\normalsize
+
+When a job event is triggered, the appropriate event definition is
+called in the JobEvents class. This is the means by which your Python
+script or code gets control. Once it has control, it may read job
+attributes, or set them. See below for a list of read-only attributes,
+and those that are writable.
+
+In addition, the Bacula {\bf job} obbject in the Director has
+a number of methods (subroutines) that can be called. They
+are:
+\begin{description}
+\item [set\_events] The set\_events method takes a single
+ argument, which is the instantation of the Job Events class
+ that contains the methods that you want called. The method
+ names that will be called must correspond to the Bacula
+ defined events. You may define additional methods but Bacula
+ will not use them.
+\item [run] The run method takes a single string
+ argument, which is the run command (same as in the Console)
+ that you want to submit to start a new Job. The value
+ returned by the run method is the JobId of the job that
+ started, or -1 if there was an error.
+\item [write] The write method is used to be able to send
+ print output to the Job Report. This will be described later.
+\item[cancel] The cancel method takes a single integer argument,
+ which is a JobId. If JobId is found, it will be canceled.
+\item [DoesVolumeExist] The DoesVolumeExist method takes a single
+ string argument, which is the Volume name, and returns
+ 1 if the volume exists in the Catalog and 0 if the volume
+ does not exist.
+\end{description}
+
+The following attributes are read/write within the Director
+for the {\bf job} object.
+
+\begin{description}
+\item [Priority] Read or set the Job priority.
+ Note, that setting a Job Priority is effective only before
+ the Job actually starts.
+\item [Level] This attribute contains a string representing the Job
+ level, e.g. Full, Differential, Incremental, ... if read.
+ The level can also be set.
+\end{description}
+
+The following read-only attributes are available within the Director
+for the {\bf job} object.
+
+\begin{description}
+\item [Type] This attribute contains a string representing the Job
+ type, e.g. Backup, Restore, Verify, ...
+\item [JobId] This attribute contains an integer representing the
+ JobId.
+\item [Client] This attribute contains a string with the name of the
+ Client for this job.
+\item [NumVols] This attribute contains an integer with the number of
+ Volumes in the Pool being used by the Job.
+\item [Pool] This attribute contains a string with the name of the Pool
+ being used by the Job.
+\item [Storage] This attribute contains a string with the name of the
+ Storage resource being used by the Job.
+\item [Catalog] This attribute contains a string with the name of the
+ Catalog resource being used by the Job.
+\item [MediaType] This attribute contains a string with the name of the
+ Media Type associated with the Storage resource being used by the Job.
+\item [Job] This attribute contains a string containing the name of the
+ Job resource used by this job (not unique).
+\item [JobName] This attribute contains a string representing the full
+ unique Job name.
+\item [JobStatus] This attribute contains a single character string
+ representing the current Job status. The status may change
+ during execution of the job. It may take on the following
+ values:
+ \begin{description}
+ \item [C] Created, not yet running
+ \item [R] Running
+ \item [B] Blocked
+ \item [T] Completed successfully
+ \item [E] Terminated with errors
+ \item [e] Non-fatal error
+ \item [f] Fatal error
+ \item [D] Verify found differences
+ \item [A] Canceled by user
+ \item [F] Waiting for Client
+ \item [S] Waiting for Storage daemon
+ \item [m] Waiting for new media
+ \item [M] Waiting for media mount
+ \item [s] Waiting for storage resource
+ \item [j] Waiting for job resource
+ \item [c] Waiting for client resource
+ \item [d] Waiting on maximum jobs
+ \item [t] Waiting on start time
+ \item [p] Waiting on higher priority jobs
+ \end{description}
+
+\item [Priority] This attribute contains an integer with the priority
+ assigned to the job.
+\item [CatalogRes] tuple consisting of (DBName, Address, User,
+ Password, Socket, Port, Database Vendor) taken from the Catalog resource
+ for the Job with the exception of Database Vendor, which is
+ one of the following: MySQL, PostgreSQL, SQLite, Internal,
+ depending on what database you configured.
+\item [VolumeName]
+ After a Volume has been purged, this attribute will contain the
+ name of that Volume. At other times, this value may have no meaning.
+\end{description}
+
+The following write-only attributes are available within the
+Director:
+
+\begin{description}
+\item [JobReport] Send line to the Job Report.
+\item [VolumeName] Set a new Volume name. Valid only during the
+ NewVolume event.
+\end{description}
+
+\subsection*{Python Console Command}
+\index[general]{Python Console Command}
+\index[general]{Console Command!Python}
+\addcontentsline{toc}{subsection}{Python Console Command}
+
+There is a new Console command named {\bf python}. It takes
+a single argument {\bf restart}. Example:
+\begin{verbatim}
+ python restart
+\end{verbatim}
+
+This command restarts the Python interpreter in the Director.
+This can be useful when you are modifying the DirStartUp script,
+because normally Python will cache it, and thus the
+script will be read one time.
+
+\subsection*{Debugging Python Scripts}
+\index[general]{Debugging Python Scripts}
+\addcontentsline{toc}{subsection}{Debugging Python Scripts}
+In general, you debug your Python scripts by using print statements.
+You can also develop your script or important parts of it as a
+separate file using the Python interpreter to run it. Once you
+have it working correctly, you can then call the script from
+within the Bacula Python script (DirStartUp.py).
+
+If you are having problems loading DirStartUp.py, you will probably
+not get any error messages because Bacula can only print Python
+error messages after the Python interpreter is started. However, you
+may be able to see the error messages by starting Bacula in
+a shell window with the {\bf -d1} option on the command line. That
+should cause the Python error messages to be printed in the shell
+window.
+
+If you are getting error messages such as the following when
+loading DirStartUp.py:
+
+\begin{verbatim}
+ Traceback (most recent call last):
+ File "/etc/bacula/scripts/DirStartUp.py", line 6, in ?
+ import time, sys, bacula
+ ImportError: /usr/lib/python2.3/lib-dynload/timemodule.so: undefined
+ symbol: PyInt_FromLong
+ bacula-dir: pythonlib.c:134 Python Import error.
+\end{verbatim}
+
+It is because the DirStartUp script is calling a dynamically loaded
+module (timemodule.so in the above case) that then tries to use
+Python functions exported from the Python interpreter (in this case
+PyInt_FromLong). The way Bacula is currently linked with Python does
+not permit this. The solution to the problem is to put such functions
+(in this case the import of time into a separate Python script, which
+will do your calculations and return the values you want. Then call
+(not import) this script from the Bacula DirStartUp.py script, and
+it all should work as you expect.
+
+
+
+
+
+\subsection*{Python Example}
+\index[general]{Python Example}
+\index[general]{Example!Python}
+\addcontentsline{toc}{subsection}{Python Example}
+
+An example script for the Director startup file is provided in
+{\bf examples/python/DirStartup.py} as follows:
+
+\footnotesize
+\begin{verbatim}
+#
+# Bacula Python interface script for the Director
+#
+
+# You must import both sys and bacula
+import sys, bacula
+
+# This is the list of Bacula daemon events that you
+# can receive.
+class BaculaEvents:
+ def __init__(self):
+ # Called here when a new Bacula Events class is
+ # is created. Normally not used
+ noop = 1
+
+ def JobStart(self, job):
+ """
+ Called here when a new job is started. If you want
+ to do anything with the Job, you must register
+ events you want to receive.
+ """
+ events = JobEvents() # create instance of Job class
+ events.job = job # save Bacula's job pointer
+ job.set_events(events) # register events desired
+ sys.stderr = events # send error output to Bacula
+ sys.stdout = events # send stdout to Bacula
+ jobid = job.JobId; client = job.Client
+ numvols = job.NumVols
+ job.JobReport="Python Dir JobStart: JobId=%d Client=%s NumVols=%d\n" % (jobid,client,numvols)
+
+ # Bacula Job is going to terminate
+ def JobEnd(self, job):
+ jobid = job.JobId
+ client = job.Client
+ job.JobReport="Python Dir JobEnd output: JobId=%d Client=%s.\n" % (jobid, client)
+
+ # Called here when the Bacula daemon is going to exit
+ def Exit(self, job):
+ print "Daemon exiting."
+
+bacula.set_events(BaculaEvents()) # register daemon events desired
+
+"""
+ These are the Job events that you can receive.
+"""
+class JobEvents:
+ def __init__(self):
+ # Called here when you instantiate the Job. Not
+ # normally used
+ noop = 1
+
+ def JobInit:
+ # Called when the job is first scheduled
+ noop = 1
+
+ def JobRun:
+ # Called just before running the job after initializing
+ # This is the point to change most Job parameters.
+ # It is equivalent to the JobRunBefore point.
+ noop = 1
+
+ def NewVolume(self, job):
+ # Called when Bacula wants a new Volume name. The Volume
+ # name returned, if any, must be stored in job.VolumeName
+ jobid = job.JobId
+ client = job.Client
+ numvol = job.NumVols
+ volname = "TestA-001"
+ job.JobReport = "JobId=%d Client=%s NumVols=%d VolumeName=%s" % (jobid, client, numvol,volname)
+ job.JobReport="Python before New Volume set for Job.\n"
+ job.VolumeName=volname
+
+ def VolumePurged(self, job):
+ # Called when a Volume is purged. The Volume name can be referenced
+ # with job.VolumeName
+ noop = 1
+
+
+
+\end{verbatim}
+\normalsize
projects / bacula / docs / commitdiff