Index
Installing Bacula
通常必要になるのはBaculaのソースであり、またWindowsのクライアントマシンを動作させているなら、Bacula Windows バイナリが必要でしょう。また一方で、サードパーティのパッケージ（MySQL、PostgreSQL、SQLite）が、Baculaをビルドし、また指定したオプションに従って正しく動作させるのに必要になります。普通であれば、MySQLとPostgreSQLが使用しているディストリビューションにはインストールできるでしょう。ですが、それらを持っていない場合、面倒をひとつにまとめるために、プロジェクトではこれらのパッケージを3つのdepkgs （Dependency Packages）としてリリースしています。これによって、必要なパッケージがすべて手に入り、ウェブ上で探しロードし、インストールする面倒がなくなります。
Source Release Files
Bacula 1.38.0で始める場合、ソースコードは4つのtarファイルに分割されており、Bacula SVNの別々のモジュールに対応しています。リリースされているファイルは：
bacula-2.0.3.tar.gz
元になるBaculaのソースコード。リリースごとにバージョン番号（2.0.3）は更新されます。
bacula-docs-2.0.3.tar.gz
ビルド前に必要になるドキュメントを含んだdocsディレクトリのコピーを含む。英語版のHTMLディレクトリ、HTMLファイルがひとつ、それとpdfファイルです。フランス語とドイツ語版の翻訳は進行中ですが、完成していません。
bacula-gui-2.0.3.tar.gz
中核ではないGUIのプログラムを含む。現在の所、bacula-webという、ブラウザ越しにBaculaのジョブを管理するためのウィンドウを作成するPHPのプログラムです。
bacula-rescue-2.0.0.tar.gz
BaculaのレスキューCDのコードです。注意してほしいのは、Baculaのリリース版のバージョンとこのパッケージのバージョンは対応していない、ということです。おそらく異なるでしょう。このコードを使うと、システムの設定にスタティックにリンクされているファイルデーモンを含めてCDROMを作成することができます。このCDで、ハードディスクに不具合が起きた場合、パーティションを再度、容易に切ることができ、また、Baculaを使用してシステムをリロードすることができるようになります。
注意してほしいのは、このパッケージはBaculaのソースコードよりも更新が遅く、Baculaのコードにマイナーアップデートがあった場合、レスキューのための新しいパッケージが常に存在しているわけではないということです。例えば、Bacula 2.0.3がリリースされても、レスキューパッケージのバージョンはアップデートが行われなかった場合2.0.0のままの場合があります。
winbacula-2.0.3.exe
32bit版Windowsのためのインストーラで、WindowsのClient（Fileデーモン）をWindowsマシンにインストールするためのもの。Clientは64bitのWindowsマシンでも動作します。Bacula 1.39.20を使う場合、この実行ファイルはオプションとしてWin32版のDirectorとStorageデーモンをロードします。
Upgrading Bacula
Baculaをアップグレードする場合、アップグレード後とアップグレード前のバージョンの間にリリースされたメジャーバージョンのReleaseNotesを注意して読む必要があります。Baculaのカタログデータベースがアップグレードされていた場合（メジャーリリースごとにほぼ毎回おこなわれます）、データベースを再初期化してスクラッチから始める（賢明な方法ではありませんが）、もしくはデータベースのASCIIコピーをとって、アップグレードを行う、のどちらかです。メジャーバージョンを二段階アップグレードする場合（たとえば1.36から2.0）、2度のデータベースのアップグレードが必要になるため、大変複雑で苦労するでしょう。この点については、さらに、以下を参照してください。
カタログのアップグレードはBaculaがビルドされインストールされた後に行われます。
cd ≪installed-scripts-dir≫ (default /etc/bacula)
./update_bacula_tables
この更新スクリプトはBaculaのソースがあるsrc/catsディレクトリにも格納されています。
アップグレード先のバージョンと現在のバージョンの間にデータベースのアップグレードがいくつか存在する場合には、それぞれのデータベースに更新スクリプトを適用する必要があります。簡単のため、ソースコードのupgradedbディレクトリに古い更新スクリプトがすべて格納されています。使用中のシステムに対応するようにスクリプトを編集する必要があるでしょう。最後の更新スクリプトは、そういうものが仮にあったとして、上で述べたように適用することが可能です。
メジャーバージョンをアップグレードする場合、すべての構成要素を同時に置き換える必要があります。というのも、だいたいにおいてデーモン間の通信プロトコルが変更が施されている可能性があるからです。ですが、特定のリリース（たとえば1.32.x）の中で行う場合、ミスやバグが存在しない限り、デーモン間の通信プロトコルは変更されていることはないでしょう。ここを読んでいて混乱してしまったら、ReleaseNotesを注意深く読んでください。すべてのデーモンを同時にアップグレードする必要があるかどうかが書かれています。
おわりに、次のことに注意してください。一般に、インストールディレクトリが変わってしまわないように注意したい、という場合以外は、make uninstallを行う必要はありません。実際の所、それを行うと、すべてのconfファイルを削除され、惨劇とも言える状態に陥ることでしょう。通常のアップグレードの手順は単純に：
./configure (適当なオプション)
make
make install
通常、.confもしくは.sqlファイルが上書きされるということはありません。make、make installをこの順番で実行してください。make抜きにmake installを実行してもうまくいきません。
アップグレードについての更なる情報は、このマニュアルの"Tips"の章の"Upgrading Bacula Version"を参照してください。
Releases Numbering
リリースされるBaculaそれぞれについて、β版であっても製品版であっても、リリースされるものがビルドされた日付と一緒に、それぞれ違う番号がふってあります。番号をつける仕組みは、オープンソースの慣習に従っていて、次のようなものになっています。
メジャー.マイナー.リリース
たとえば、
1.38.11
です。
ここで、それぞれの要素major,minor,patchは、numberです。メジャー・ナンバーは、現在1で、通常、それほど頻繁にかわることはありません。マイナー・ナンバーは"0"から始まり、製品版のリリースごとに"2"ずつ増えます（すなわち、マイナー・ナンバーは常に、製品版においては偶数です）。また、パッチ・ナンバーは、マイナー・ナンバーの変更ごとに、"0"からカウントされるようになります。パッチ・ナンバーはバグフィックス（バグが複数ある場合もあります）が、製品版に対して行われると、その都度増えていきます。
従って、現在の日付、つまり2006年9月10日ですが、この時点での現行のBaculaの製品版リリースは、バージョン 1.38.11です。バグフィックスが行われた場合、次のリリースは1.38.12になります（すなわち、パッチナンバーがひとつあがります）。
マイナー・ナンバーが変更されずにパッチが当てられる場合、データベースとデーモンは引き続き互換性を保ちます。すなわち、1.38.0のDirectorを1.38.11のクライアントで安全に動作させることが可能です。
もちろんこの場合、Directorにはバグが残っている可能性があります。一般的に、マイナーリリース（そのうちいくつかは"マイナー"と言っていいのか微妙ですが）においては、パッチは製品版に対して当てられ番号がかわります。すなわち、Baculaの現行のバージョンが1.38.11の場合、1.38.0、1.38.1、…1.38.10がそれまでにリリースされています。
マイナー・ナンバーが奇数の場合、そのパッケージは現在開発段階にあり、安定性に欠けている可能性があることを示しています。例えば、現在、現行のBaculaの製品版のリリースが1.38.11の場合、現行の開発版は1.39.22になります。開発中のコードへパッチが当てられたバージョンはSVNというソース・リポジトリで入手できます。ですが、開発中のコード（すなわち奇数のマイナー・ナンバーを持っているもの）のすべてに対して、公式にパッチがリリースされている訳ではありません。リリースされた場合、それらはβ版としてリリースされます（Baculaのリリースにおいてβ版とは何か、については、下記参照）。
一般的に、マイナー・ナンバーがある製品版から次の製品版へと移行した場合（すなわち、1.38.x から 1.40.0へ）、カタログ・データベースをアップグレードしなければならず、また、DirectorとStorageデーモンも、常に同一のマイナー・ナンバーに統一し、Clientもまた同じように統一しておかなければなりません。どの場合においても、可能な限り、以前にリリースされたクライアントに対する下位互換性を保つようにつとめていますが、常にそれが可能である、とは言えません。リリースノートを読んでください。通常、すべてのコンポーネントを同一のマイナー・ナンバーにそろえておけば（すなわち、1.38.xか1.40.xのどちらかを使い、混在させずにおく）、ほとんど問題が起こることはないでしょう。
Beta Releases
開発サイクルを完結させるのに向けて、それは通常メジャーリリースごとにだいたい1年かかりますが、その間、製品版に先行して開発コードのβ版がいくつかリリースされます。上で述べたように、β版は奇数のマイナー・ナンバーをもちます（たとえば、1.37.xや1.39.x）。β版をリリースする目的は、現在Baculaをつかっているユーザが、新しいコードをテストできるようにするためです。β版は、以下のことを考慮して作成されています。すなわち、
・コードは、FreeBSD、Linux、Solarisのマシンでのリグレッションテストを通過している。
・大きなバグはない、もしくはあったとしてもおこる可能性は小さい。ドキュメントに記載されるか、すでにバグ・データベースに登録されている。
・新しいコードもしくは機能のいくつかは、テストされていない可能性がある。
・バグが見つかる可能性がある。特に最終的な製品版がリリースされる前の段階での、新しいコードでは可能性が高い。
・コードは、一カ所で（つまり筆者のところで）少なくとも一回、製作中にテストをする。
・Win32クライアントは、一つ上の項と同じように、少なくとも一晩、製作中に動作をさせている。
・マニュアルの記述が完全であることは期待できない。特に新しい機能に対してはそうである。またRelease Notesもきちんと整えられていない可能性がある。
・β版のコードは一般的に言って、誰にでもお勧めできるものではなく、むしろearly adoptersのためのものである。
Dependency Packages
上で述べたように、Baculaプロジェクトでは、Baculaを動かすのに必要なサードパーティのパッケージ群をdepkgsとしてまとめてリリースしています。もちろん、オリジナル版の作成者から、もしくはオペレーティング・システムの提供元から入手することも可能です。プロジェクトがどこからそれらのパッケージを入手したのかは、それぞれのパッケージに含まれるREADMEファイルに記載されています。しかしながら、depkgsファイルが含むパッケージはBaculaとの間の互換性テストが行われている、ということには注目しておいてください。
通常、dependency packageは、depkgs-ddMMMyy.tar.gzと名前がつけてあります。ddはリリースされた日にち、MMMは月の省略形（たとえば、"Jan"など）、yyは年を意味しています。実例：depkgs-07Apr02.tar.gz、のようになります。このパッケージをビルドするには（必要な場合）、次のように行ってください：
1. baculaディレクトリを作成し、Baculaのソースとdependency packageを配置してください。
2. depkgsファイルをtarでbaculaディレクトリに解凍してください。
3. cd bacula/dpkgs
4. make
dependency packageの構成は時を追ってかわります。現行の構成は以下の通りです。
（表がはいる）
注意してほしいのは、パッケージのうちのいくつかは非常に大きく、ビルドするのに時間がかかる可能性がある、ということです。上の指示に従った場合、ディレクトリに含まれるすべてのパッケージをビルドします。一方で、Baculaをビルドする場合には、必要なものだけがビルドされます。
代わりに、必要なパッケージだけmakeすることが可能です。たとえば、
cd bacula/depkgs
make sqlite
とした場合、SQLiteパッケージのみの設定とビルドが行われます。
depkgsの中で必要とするパッケージは、Baculaの設定とビルドを行うのに先立ってビルドする必要があります。というのも、Baculaをビルドする過程で必要になるからです。
depkgs-qtパッケージについての詳しい情報は、パッケージのメインディレクトリのなかにあるINSTALLファイルを読んでください。depkgs-qtを使ってQt4をビルドしようとする場合、Baculaをビルドする前にパッケージに含まれるqt4-pathsファイルを持ってきておく必要があります。詳細については、INSTALLファイルを読んでください。
SQLiteを使わない場合でも、mtxをビルドしておくのには意味があると思うことと思います。というのも、tapeinfoというプログラムがそれに付随してきますが、それを使うと、SCSIテープドライブについての有益な情報を提供してくれる可能性があるからです（すなわち、圧縮、min/max blockサイズ、…）。もっとも、ほとんどのディストリビューションにはmtxは含まれています。
depkgs1パッケージは、価値のないものになってしまったreadlineを以前は含んでいました。これはもはやすべてのオペレーティング・システムで普通に使用できるようになっていなければならないものです。
depkgs-win32パッケージも価値がなくなり、Bacula 1.39.x、もしくはそれ以降のバージョンでは使用されていません。以前は、Win32にネイティブなクライアントclientプログラムをビルドするのに使用されていました。ですが、このプログラムは現在ではLinuxシステム上でクロスコンパイルすることでビルドされます。ツールとサードパーティのライブラリはすべて、適切なスクリプトを実行することで自動的にダウンロードされます。詳細は src/win32/README.mingw32を参照してください。
Supported Operating Systems
"Quick Start"の章の、"Supported Operating Systems"の項を参照してください。
Building Bacula from Source
基本的なインストールは非常にシンプルです。
1. depkgsを上で述べたようにビルドしてインストールしてください。この作業は最近のほとんどのオペレーティング・システムでは必要ありません。
2. MySQLもしくはPostgreSQLをインストールし設定してください（必要なら）。"Installing and Configuring MySQL Phase Ⅰ"、もしくは"Installing and Configuring PostgreSQL Phase Ⅰ"を参照。rpmsからインストールしたMySQLを使用している場合、mysql-develを必ずインストールしてください。MySQLのヘッダーファイルがBaculaをコンパイルする際に必要です。さらに、MySQLクライアントのライブラリであるmysqlclientはgzip圧縮ライブラリであるlibz.aもしくはlibz.soを必要とします。rpmパッケージを使っている場合、これらのライブラリはlibz-develパッケージに含まれています。Debianを使っている場合、zlib1g-devパッケージをロードする必要があります。rpmsもdebsも使用していない場合、自分のシステムに合うパッケージを探してくる必要があります。
MySQLもしくはPostgreSQLをすでにシステム上で稼働させているなら、このフェーズをスキップすることができます。ただし、スレッドセーフなライブラリをすでにビルドしていることが必要です。さらに、上で述べた付加的なrpms(複数のrpmパッケージ)をロードする必要があります。
SQLiteはSolarisではサポートされていません。というのも、頻繁にバスエラーが発生するからです。ですがSQLite3は動作するかもしれません。
3. Baculaのソースコードを、できれば、上で述べたbaculaディレクトリに解凍してください。
4. cdコマンドでソースコードを含むディレクトリに移動してください。
5. ./configureコマンドを実行してください（適切なオプションをつけてください。オプションについては後述）。./configureに、オプションとして指定するパスは、相対パスでなく絶対パスで指定してください。
6. ./configureコマンドの出力を注意してチェックしてください。インストールバイナリとインストール設定ディレクトリ群には特別な注意を払ってください。間違っていた場合、./configureを正しい結果が出るまで実行してください。./configureからの出力はconfig.outに保存され、./configureを実行しなくても、"cat config.out" を実行することで再度表示することができます。
7. ./configureを一度実行した後、もう一度オプションを変えて実行するというのは、妥当な選択だと思いますが、その前に次のコマンドを実行してください。
make distclean
これで、ゼロから始めることができ、二つのオプション群は混ざりません。というのも、./configureは、大量の情報がキャッシュとして保存されるからです。make distclean は、ソースディレクトリを別のマシンへ移した場合にも必須のものになります。make distcleanが失敗した場合、無視して作業を続けてください。
8. make
makeを実行してください(make If you get errors）。Storageデーモンディレクトリの中でリンクを張る際にエラーがあった場合、おそらくスタティックライブラリをロードしていないことが原因だと考えられます。Solaris上でこの問題に気づきましたが、直すには、./configureコマンドに --enable-static-toolsオプションを追加してください。
このステップ（make）をスキップし、すぐにmake installを実行した場合、深刻なエラーが二つ発生します。1. Baculaはmake installの前にmakeを必要とするので、インストールに失敗する。 2. 次のことを確認するチャンスがない。すなわち、システムディレクトリにファイルを書き込む前に、エラーがないことを確認できない。
9. make installを実行してください。このコマンドを入力する前にmakeを実行したかどうかを確認し、また、すべて正しく、またエラーもなくコンパイルとリンクが行われたことを確認してください。
10. Baculaが初めてなら、Baculaプロジェクトは 、次のステップをスキップし、デフォルトの設定ファイルを使用することを強く推奨します。つづいて、次章で例としてあげるプログラムを走らせ、その後、ここに戻って必要に応じて設定を行ってください。
11. 3つのデーモン（Directory、File、Storage）それぞれ、およびConsoleプログラムの設定ファイルをカスタマイズしてください。これをどのように行うかについての詳細は"Configuration"の章の"Setting up Configuration Files"の項を参照してください。Baculaプロジェクトでは、はじめは、提供される設定ファイルに必要最小限の変更を加えることをお勧めします。パスワードは、ランダムに生成されますが、これを変更する場合は注意してください、パスワードと名前のためのNamesは、セキュリティ上の理由から、各設定ファイル間で一致していなければなりません。
12. Bacula用のMySQLのデータベースとテーブルを作成（MySQLを使用している場合）する。 "Installing and Configuring MySQL Phase II"を参照。もしくは、Bacula用のPostgreSQLデータベースとテーブルを作成する。"Configuring PostgreSQL II"を参照。また、代わりに、SQLiteを使用している場合、"Installing and Configuring SQLite Phase II"を参照してください。
13. Baculaを起動してください（./bacula start）。注：次章で方法についての詳細が示されます。
14. Consoleプログラムを使ってBaculaに接続してください。
15. 前2段のについては、このマニュアルの"Running Bacula"の章の指示に従ってください。単純なバックアップとリストア作業を行う場合でも。設定ファイルに大きな変更を施す前に必ずこの指示に従い、Baculaが動作していることを確認して、Baculaになじんでおいて下さい。そうしておけば、confファイルを変更することはより容易になります。
16. Baculaをインストールした後、それを”移動”することにした場合。すなわちそれは、別のディレクトリ・セットにインストールすることを意味します。次のように行ってください。
make uninstall
make distclean
./configure (your-new-options)
make
make install
成功した場合、./configureは、マシンでどのオペレーティング・システムが動作しているかを正しく確定し、ソースコードを正しく設定します。現在のところ、FreeBSD、Linux(Red Hat)、そしてSolarisがサポートされています。Baculaクライアント（Fileデーモン）は、Mac OS X 10.3で動作すると報告を受けています。ただし、クライアントをビルドする場合にreadlineサポートを切っている場合（デフォルトではそうなっています）、ということです。
Baculaを複数のシステムにインストールし、それらが全く同じものである場合、ソースツリーをそれらのシステムに移動して"make install"を実行してください。ですが一方で、ライブラリやOSのバージョンに違いがある場合、もしくは別のOSにインストールしたいという場合、オリジナルのtar圧縮ファイルから始める必要があります。もし、ソースツリーを移動し、以前に./configureコマンドを実行していた場合、必ず、次の作業を行ってください：
make distclean
これは新しく./configureを実行する前に行ってください。これは次のことによります。GNU autoconf ツールは、設定をキャッシュとして保存しているため、設定をLinux、もしくはSolarisマシンで再利用する場合、ビルドは確実に失敗するからです。これを避ける、上で述べたように、tarファイルから始めるか、"make distclean"を実行してください。
通常、より詳細なconfigureステートメントを使いたい、と考えるでしょう。そうすることで必要なモジュールがビルドされ、すべて[のファイルやディレクトリ]が正しいディレクトリに配置されるからです。
例えば、Fedora、Red Hat、もしくはSuSEでは、次のものを使うことができるでしょう。
CFLAGS="-g -Wall" \
./configure \
--sbindir=$HOME/bacula/bin \
--sysconfdir=$HOME/bacula/bin \
--with-pid-dir=$HOME/bacula/bin/working \
--with-subsys-dir=$HOME/bacula/bin/working \
--with-mysql \
--with-working-dir=$HOME/bacula/bin/working \
--with-dump-email=$USER
注意すべきは、上の設定を使って始めることの利点は、すべて[のファイルやディレクトリ]が、単一のディレクトリに配置され、次章で例としてあげるプログラムを走らせ、Baculaがどのように動作するのかについて学んだ後、削除することができることです。さらに、上の方法では、root権限なしでインストールと実行を行うことが可能です。
開発者の利便性のため、defaultconfigスクリプトをexamplesディレクトリに追加してあります。このスクリプトは通常使うステートメントを含んでおり、開発者もしくはユーザがそれぞれのニーズにあわせて変更することができるようになっています。また、このディレクトリの中には、役に立つ実例が他にも含まれています。
--enable-conioもしくは--enable-readlineオプションは利用価値があります。というのも、コマンドラインの履歴と編集機能をConsoleプログラムに与えるからです。どちらかのオプションをビルドに加えた場合、termcapもしくはncursesパッケージがリンクに必要です。ほとんどのシステムでは、Red HatやSuSEも含め、ncursesパッケージをインクルードする必要があります。Baculaの設定プロセスのなかでncursesライブラリが見つかった場合、termcapライブラリではなくこちらを使用します。いくつかのシステム、たとえばSuSEでは、termcapライブラリは標準的なライブラリディレクトリに含まれていません。結果、このオプションは使用できず、下のようなエラーメッセージが表示されます：
/usr/lib/gcc-lib/i586-suse-linux/3.3.1/.../ld:
cannot find -ltermcap
collect2: ld returned 1 exit status
次の場合にも、同じライブラリが必要になります。すなわち、readlineサブルーチンをコマンドライン編集と履歴機能のために使用したい場合、もしくは、暗号化を要求するMySQLのライブラリを使用する場合です。暗号化が必要な場合、上で述べた適切な、付加的なライブラリオプションを使用するか、また別の方法としては、./configure に直接、含めてしまうことが可能です。すなわち：
LDFLAGS="-lssl -lcyrpto" \
./configure ≪your-options≫
Mandrivaなどを含むいくつかのシステムでは、readlineはプロンプトを使い尽くしてしまって、使用不可能に。こういったことが起きる場合、disableオプションを使用するか、バージョン1.33を使用し、上述のように--enable-conioを使用してビルトインのreadlineの代わりとしてください。この場合でもtermcapもしくはncurseライブラリが必要になりますが、conioパッケージがプロンプトを埋め尽くすことはないでしょう。
readlineはバージョン1.34以降ではサポートされません。Bacula内部にはコードは残っているので、使用することは可能で、ユーザがパッチを提供してくれるなら、プロジェクトでは喜んでそれを適用します。ですが一方で、readlineのそれぞれのバージョンは、下位互換性がない、またシステム間で大きな違いが出るようなので、プロジェクトでサポートする余力が現在のところありません。
What Database to Use?
Baculaをビルドする前に、SQLite、MySQL、PostgreSQLのどれを使うかを決める必要があります。MySQLもしくはPostgreSQLをまだ使用していない場合、SQLiteでテストしてみたい、と考えるでしょう（ただしSolarisではサポートされていません）。こうすることで、セットアップが劇的にシンプルになります。というのも、SQLiteはBaculaに同梱されており、管理も必要ありません。SQLiteはパフォーマンスもよく、小規模から中規模のシステムへのインストールに向いています（最大で10～20台のマシン）。しかしながら、説明のつかないデータベースの破損がSQLiteでは起きることも付け加えておく必要があります。したがって、Baculaプロジェクトでは、製品としての信頼性が求められる状況では、MySQLもしくはPostgreSQLのどちらかをインストールすることをお勧めします。
MySQLをBaculaのカタログとして使用する場合、このマニュアルの"Installing and Configuring MySQL"の章を参照してください。Baculaの設定を続ける前に、MySQLをインストールする必要があります。MySQLは質の高いデータベースであり、効率的で、どの規模のシステムを組む際にも使うことができます。SQLiteよりも複雑な設定と管理が必要ですが、これはMySQLが非常に洗練された機能、たとえばuseridや、passwordなど、を持っているからです。MySQLは別のプロセスとして動作し、持ち分の作業に専念します。また、どんなサイズのデータベースも扱うことができます。
PostgreSQLをBaculaのカタログとして使用する場合、このマニュアルの"Installing and Configuring PostgreSQL"の章を参照してください。Baculaの設定を続ける前に、PostgreSQLをインストールする必要があります。PostgreSQLはMySQLと非常に似ていますが、一方で、SQL92の規格に従う傾向があり、トランザクション、ストアド・プロシージャ、などと言った非常に高度な機能も持っています。なおインストールとメンテナンスには一定の知識が必要です。
SQLiteをBaculaのカタログとして使用する場合、このマニュアルの"Installing and Configuring SQLite"の章を参照してください。SQLiteはSolarisではサポートされていません。
Quick Start
Baculaを上で述べた簡単な設定でビルドして問題がなかった場合、たくさんのオプションと考慮すべき事柄が下で述べてありますが、一旦は飛ばしてしまってかまいません。
./configureのプロセスで、特定のライブラリが見つからない、といった場合（たとえば、libintl)、適切なパッケージがシステムにインストールされているかどうか確認してください。別の場合、パッケージが（Baculaにとっての）標準的な場所にインストールされていない場合、通常そのためのオプションが下にリストアップされています（もしくは"./configure --help"と入力するとリストアップさます）。これはライブラリを探すディレクトリを自分で特定できるようにするためのものです。別のケースでは、機能を無効化するオプション（たとえば、--disable-nls）も存在します。
Configure Options
configureスクリプトに以下のコマンドラインオプションが容易されており、インストールのカスタマイズを行うことができます。
--sbindir=≪binary-path≫
Baculaのバイナリファイル（実行ファイル）が make install コマンドでどこに配置されるかを決めます。
--sysconfdir=≪config-path≫
Baculaの設定ファイルがどこに配置されるかを決めます。
--mandir=≪path≫
注意すべきは、Bacula バージョン 1.39.14では、このオプションで指定されたパスの意味が以前のバージョンと異なっているということです。現在では、トップレベルのmanディレクトリを指定します。以前は、mandirはmanファイルのインストール先のフルパスでした。manファイルはgzipで圧縮された状態で、mandir/man1とmandir/man8にインストールされます。インストールを首尾よく行うためには、gzipがシステムにインストールされている必要があります。
デフォルトでは、BaculaはUnixのmanページを/usr/share/man/man1と/usr/share/man/man8にインストールします。別の場所にmanページをインストールしたいという場合、このオプションを使ってパスを指定してください。メインのHTMLとPDFのBaculaに関するドキュメントは別のtarファイルに入っていて、ソースと一緒には配布されている、ということに注意してください。
--datadir=≪path≫
BaculaもしくはBaculaの一部を別の言語に翻訳する場合、poファイルの位置を--datadirオプションで指定します。poファイルはマニュアルでインストールする必要があります。Baculaは（今のところ）自動的にはインストールしません。
--disable-ipv6
--enable-smartalloc
このオプションはSmartalloc orphaned buffer detection code をインクルードします。このオプションは強く推奨されます。というのも、プロジェクトではこのオプションなしにビルドすることはなく、このオプションを有効にしなければ問題が発生と考えられます。問題が発生した場合、単純にこのオプションを追加してください。プロジェクトではこのオプションを常に有効(enabled)にして、メモリリークの探査の補助をさせるようにすることを推奨します。この設定パラメータはBaculaをビルドする際に使用されます。
--enable-bat
Qt4 4.2以降が、libqt4とlibqt4-devel（Debianではlibqt4-dev）ライブラリが含まれているコンピュータにインストールされている場合、またBacula Administration Tool （bat） GUI ConsoleをBaculaとの接続に使用したい、という場合、このオプションを指定する必要があります。そうすることで、必要なものすべてがsrc/qt-consoleディレクトリにビルドされます。このenable-batを有効にしてのビルドは、Baculaのビルド全体に対してしか機能しません。（すなわち、クライアントのみに対して機能させることはできません）。Qt4ライブラリに加えて、batをリンクするにはqwtパッケージが使用中のシステムにインストールしてある必要があります。
Qt4はOpenSUSE10.2、CentOS 5、Fedora、Debianで利用できます。使用中のシステムで利用できない場合、depkgs-qtをBacula Source Forgeからダウンロードして、qwtパッケージと一緒にビルドしてください。両方ともbatをビルドするのに必要です。詳細はパッケージに含まれるINSTALLファイルを参照してください。特にdepkg-qtからビルドされたQt4を使用する場合、you bf must source the file qt4-paths.
--with-qwt=≪path≫
batをビルドするためには、qwtグラフィックパッケージが使用中のシステムにインストールされている必要があります。ここで指定されるパスは相対パスでなく絶対パスです。
qwtパッケージはSource Forgeのqwtプロジェクトからダウンロードして入手可能です。必要なら、使用中のシステムにビルドしてインストールすることが可能です（デフォルトでは /usr/lib）。それが終わったら、次のようにオプションを指定してください：
--with-qwt=/usr/lib/qwt-5.0.2
その代わりに、Bacula depkgs package（現行バージョンは11Jul07）をダウンロードしてビルドすることが可能です。baculaという名前のディレクトリにそれを配置して、次のようにオプションを指定してください：
--with-qwt=$HOME/bacula/depkgs/qwt
Debianなどのパッケージは、libqwt.aとlibqwt.soといったライブラリに、標準的な名前の付け方をしていません。したがって、それらが使っている名前にソフトリンクを手動で張るか、もしくはdepgksバージョンを使ってください。この場合は正しく名前が付けられています。
--enable-batch-insert
カタログデータベースの属性レコード（デフォルトでは）のバッチ挿入を可能にするオプションです。これによって、このオプションをオフにしている場合に大量のファイルを扱う場合に比べてより高速な（10倍もしくはそれ以上）処理が可能です。
SQLite2はスレッドセーフではありません。バッチ挿入はSQLite2を使っている場合は有効にすることができません。
ほとんどのシステムで、MySQL、PostgreSQL、SQLiteはスレッドセーフです。
PostgreSQLがスレッドセーフであるかどうかを調べるには、以下を試してみてください（あなたがインストールしたlibpq.aを指定するようににパスを変更してください。以下のコマンドはFreeBSD6.2で実行されたものです）
$ nm /usr/local/lib/libpq.a | grep PQputCopyData
00001b08 T PQputCopyData
$ nm /usr/local/lib/libpq.a | grep mutex
U pthread_mutex_lock
U pthread_mutex_unlock
U pthread_mutex_init
U pthread_mutex_lock
U pthread_mutex_unlock
上の例ではlibpqは、必要な関数であるPQputCopyDataを含んでおり、スレッドが有効化されています（すなわち、pthread_mutex* のエントリ）。PQputCopyDataが見当たらない場合、PostgreSQLのバージョンが古くバッチ挿入に対応していません。またmutexエントリが見当たらない場合は、スレッドサポートが有効になっていません。Baculaプロジェクトでのテストで次のことが明らかになりました。すなわち、configurationのオプションを変更する必要があり、また、PostgreSQLクライアントをスレッドサポートにするためにPostgreSQLを再コンパイル/再インストールする必要があります。
一方、BaculaはつねにスレッドセーフなMySQLのライブラリにリンクを張っています。
デフォルトでは、BaculaはSQLite3をPRAGMA synchronous=OFFで動作させています。その方がパフォーマンスが30倍以上に上がるからです。ですが一方、そうすることでデータベースの破損の可能性が上がります。より高い安全性が必要な場合、src/version.hを適宜変更してください（ファイルを見れば一目でどうすればいいかわかると思います）。
Batch Insertを有効にして稼働させることが推奨されます。というのも、そうすることで属性の挿入にかかる時間が大きく改善するからです。しかしながら、そうすると作業の大半をSQLエンジンに負担させることになり、したがってそのチューニングに非常に注意をはらう必要があります。特にBatch Insertは大きな一時テーブルのためのスペースを必要とし、結果として、デフォルトの一時ファイル格納場所のままでは（通常 /tmp）スペースが足りなくなりエラーが発生する可能性があります。MySQLでは、一時ファイルの格納場所はmy.confの"tmpdir"で設定します。SQLエンジンへのメモリ割当を増やして、Batch Insertのパフォーマンスをよりいっそう向上させたい、ということもあるかと思います。
--enable-gnom
開発ライブラリを含むGNOMEが使用中のコンピュータにインストールされていて、GNOME GUI ConsoleをBaculaとの接続に使用したい、という場合、このオプションを指定してください。そうすることで、src/gnome2-consoleディレクトリにすべてビルドされます。
--enable-bwx-console
wxWidgetが使用中のコンピュータにインストールされていて、wxWidget GUI ConsoleをBaculaとの接続に使用したい、という場合、このオプションを指定(specify)してください。そうすることで、src/wx-consoleディレクトリにすべてビルドされます。GUIを使いたいけれども、GNOMEはインストールしたくない、という方にはこれはとても利用価値があります。というのも、wxWidgetはGTK+、MotifもしくはX11のライブラリを使っても動作するからです。
--enable-tray-monitor
GTKが使用中のコンピュータにインストールされている場合、グラフィック環境もしくはFreeDesktop system tray standardと互換性のあるウィンドウマネージャ（たとえばGNOMEやKDE）を使用していて、しかもBaculaのデーモン群をモニタするのにGUIを使用したい、という場合、このオプションを指定する必要があります。そうすることで、そうすることで、src/tray-monitorディレクトリにすべてビルドされます。Note, due to restrictions on what can be linked with GPLed code, we were forced to remove the egg code that dealt with the tray icons and replace it by calls to the GTK+ API, and unfortunately, the tray icon API necessary was not implemented until GTK version 2.10 or later
--enable-static-tools
このオプションを指定することで、リンカがStorageデーモン・ユーティリティツール（bls、bextract、bscan ）にスタティックリンクを張ります。これによって、共有ライブラリがロードされていなくても、それらツールを使用することが可能になります。src/storedディレクトリにリンクを張る際に問題が発生した場合、このオプションを有効にしていないことを確認するか、明示的に--disable-static-toolsオプションを指定してスタティクリンクをオフにしてください。
--enable-static-fd
このオプションを指定すると、通常のFileデーモンに加えてstatic-bacula-fdをビルドするためのmakeプロセスが動きます。このスタティックバージョンはスタティックリンクが張られたライブラリを含み、Bare Metalからのリカバリのためには必要です。このオプションは、src/filedディレクトリでmake static-bacula-fdを使うことで大部分代用されます。また、以下に記述のある--enable-client-onlyオプションを使うと、他のプログラムがコンパイルされていないままにしておいて、クライアントのみをビルドするために便利です。
スタティック・バイナリをリンクする時には、リンカは使用されるすべてのライブラリのスタティック・バージョンを必要とします。したがって、頻繁に、ユーザはこのオプションを使用するとリンクエラーに見舞われることになります。まず始めにするべきことは、使用中のシステムにglibcライブラリがインストールされていることを確認することです。次に、--opensslもしくは--with-pythonオプションを、./configureのステートメントに指定していないことを確認してください。これらのオプションは追加のライブラリを必要とします。これらのオプションを有効にすることはできますが、追加のスタティック・ライブラリをロードする必要があります。
--enable-static-sd
このオプションを指定すると、通常のStorageデーモンに加えてstatic-bacula-sdをビルドするためのmakeプロセスが動きます。ビルドされたスタティックバージョンはスタティック・リンク・ライブラリを含み、Bare Metal リカバリの際に利用できます。
スタティック・バイナリをリンクする時には、リンカは使用されるすべてのライブラリのスタティック・バージョンを必要とします。したがって、頻繁に、ユーザはこのオプションを使用するとリンクエラーに見舞われることになります。まず始めにするべきことは、使用中のシステムにglibcライブラリがインストールされていることを確認することです。次に、--opensslもしくは--with-pythonオプションを、./configureのステートメントに指定していないことを確認してください。これらのオプションは追加のライブラリを必要とします。これらのオプションを有効にすることはできますが、追加のスタティック・ライブラリをロードする必要があります。
--enable-static-dir
このオプションを指定すると、通常のDirectorに加えてstatic-bacula-dirをビルドするためのmakeプロセスが動きます。ビルドされたスタティックバージョンはスタティック・リンク・ライブラリを含み、Bare Metal リカバリの際に利用できます。
スタティック・バイナリをリンクする時には、リンカは使用されるすべてのライブラリのスタティック・バージョンを必要とします。したがって、頻繁に、ユーザはこのオプションを使用するとリンクエラーに見舞われることになります。まず始めにするべきことは、使用中のシステムにglibcライブラリがインストールされていることを確認することです。次に、--opensslもしくは--with-pythonオプションを、./configureのステートメントに指定していないことを確認してください。これらのオプションは追加のライブラリを必要とします。これらのオプションを有効にすることはできますが、追加のスタティック・ライブラリをロードする必要があります。
--enable-static-cons
このオプションを指定すると、通常のConsoleに加えてstatic-consoleとstatic-gnome-consoleをビルドするためのmakeプロセスが動きます。ビルドされたスタティックバージョンはスタティック・リンク・ライブラリを含み、Bare Metal リカバリの際に利用できます。
スタティック・バイナリをリンクする時には、リンカは使用されるすべてのライブラリのスタティック・バージョンを必要とします。したがって、頻繁に、ユーザはこのオプションを使用するとリンクエラーに見舞われることになります。まず始めにするべきことは、使用中のシステムにglibcライブラリがインストールされていることを確認することです。次に、--opensslもしくは--with-pythonオプションを、./configureのステートメントに指定していないことを確認してください。これらのオプションは追加のライブラリを必要とします。これらのオプションを有効にすることはできますが、追加のスタティック・ライブラリをロードする必要があります。
--enable-client-only
このオプションを指定すると、Fileデーモンとそのために必要なライブラリのみをビルドするためのmakeプロセスが動きます。他のデーモン、ストレージ・ツール、そしてコンソールもビルドされません。同様に、make install を実行してもFileデーモンのみがインストールされます。すべてのデーモンをビルドするには、このオプションなしでconfigurationを行う必要があります。このオプションは、クライアントとしてしか動作しないマシンで、Clientをビルドするのを容易にします。
スタティック・バイナリをリンクする時には、リンカは使用されるすべてのライブラリのスタティック・バージョンを必要とします。したがって、頻繁に、ユーザはこのオプションを使用するとリンクエラーに見舞われることになります。まず始めにするべきことは、使用中のシステムにglibcライブラリがインストールされていることを確認することです。次に、--opensslもしくは--with-pythonオプションを、./configureのステートメントに指定していないことを確認してください。これらのオプションは追加のライブラリを必要とします。これらのオプションを有効にすることはできますが、追加のスタティック・ライブラリをロードする必要があります。
--enable-build-dird
このオプションを指定すると、DirectorとDirectorのツールをビルドするmakeプロセスが動きます。デフォルトではこのオプションは有効になっていますが、Directorをビルドしないように--disable-build-dirdオプションでこれをオフにできます。
--enable-build-stored
このオプションを指定すると、Storageデーモンををビルドするmakeプロセスが動きます。デフォルトではこのオプションは有効になっていますが、Storageをビルドしないように--disable-build-storedオプションでこれをオフにできます。
--enable-largefile
このオプション（デフォルト）は、使用中のシステムで可能であれば、64ビットファイルアドレッシングを含めBaculaをビルドします。これによって、Baculaが2GBytes以上の大きさのファイルの読み書きを行えるようになります。この機能を切って32ビットファイルアドレッシングに戻すには、--disable-largefileオプションを使用します。
--disable-nls
デフォルトでは、BaculaはGNU Native Language Support ライブラリを使用します。これらのライブラリが存在しないか、（特にLinux以外の実装において）うまく働かないマシンが存在します。そういった場合、--disable-nlsオプションを指定することでで当該ライブラリを使用しないようにできます。その場合、Baculaは英語を使う状態に復帰します。
--disable-ipv6
デフォルトでは、BaculaはIPv6プロトコルを有効にしています。システムによっては、IPv6のためのファイルは存在していても、カーネルがその機能をオフにしている場合があります。その場合、Baculaを正しくビルドするためには、明示的にこのオプションを使って、Baculaが存在しないOSの関数の呼び出しを試みないようにする必要があります。
--with-sqlite=≪sqlite-path≫
SQLite version 2.8.x データベースを使用可能にします。sqlite-pathは、Baculaが必要なコンポーネントを探す通常の位置（depkgs/sqlite)に、通常設定されている訳ではありません。詳細はこのマニュアルの"Installing and Configuring SQLite"の章を参照してください。なお、SQLiteはSolarisでは動作しません。
--with-postgresqlの項の下にある注を参照。
--with-sqlite3=≪sqlite3-path≫
SQLite version 3.x データベースを使用可能にします。sqlite-pathは、Baculaが必要なコンポーネントを探す通常の位置（depkgs/sqlite3)に、通常設定されている訳ではありません。詳細はこのマニュアルの"Installing and Configuring SQLite"の章を参照してください。なお、SQLite3はSolarisでは動作しません。
--with-mysql=≪mysql-path≫
Bacula用のCatalogサービスをビルドできるようにします。これはMySQLが使用するシステムで稼働していることを前提とし、mysql-pathで指定されたパスにインストールされているものとします。通常、MySQLが標準的なシステム上の位置にインストールされている場合、簡単に--with-mysqlとしてパスを指定しないこともできます。このオプションをもし、使用するなら、設定に進む前に"Installing and Configuration MySQL"の章へ進んでMySQLのインストールしてください。
--with-postgresqlの項の下にある注を参照。
--with-postgresql=≪path≫
このオプションをつかうと、PostgreSQLのライブラリへのパスを明示します。これは、Baculaがデフォルトの位置を探して見つからなかった場合のためのものです。通常PostgreSQLを同時にビルドするには、簡単に--with-postgresqlを使ってください。
注。Baculaが正しく設定するためには、サポートされている4つのデータベースのうちの一つを指定しなければなりません。すなわち：--with-sqlite、--with-sqlite3、--with-mysql、--withpostgresqlのどれかを指定しなければ、./configureは失敗します。
--with-openssl=≪path≫
この設定オプションは、TLS（ssl）を有効にしてBacula内部での通信を暗号化する、もしくはFileデーモンのPKIデータ暗号化を使用する場合に必要になります。通常 path の設定は必須ではありません。というのも、コンフィギュレーションの際にはOpenSSLライブラリを標準的なシステム上の位置から探し出します。OpenSSLを有効にすることによって、Baculaはデーモン間の通信の暗号化、また/あるいは、Fileデーモンの内部でのデータの暗号化が可能になります。TLSの使用に関する情報は、このマニュアルの"Bacula TLS -- Communication Encryption"の章を参照してださい。PKIデータ暗号化については、"Bacula PKI -- Data Encryption"を参照してください。
--with-python=≪path≫
このオプションはBaculaのPythonへのサポートを有効にします。パスが与えられない場合、configureスクリプトは、Python 2.2、2.3、2.4、2.5の標準的なライブラリの位置を探します。ライブラリが見つからなかった場合、Pythonのライブラリ・ディレクトリへのパスを与える必要があります。Pythonによるスクリプティングについての詳細は、"Python chapter"を参照してください。
--with-libintl-prefix=≪DIR≫
Native Language Support (NLS)のために必要なlibintヘッダ、ライブラリ用のlDIR/includeとDIR/libをBaculaに伝えるのに使う可能性があります。
--enable-conio
Baculaに、より小さくて、軽量なreadlineの代替ルーチンをビルドするよう指示します。一般的にreadlineを設定するよりも簡単ですが、readlineと同様に、tercapもしくはncursesライブラリが必要です。
--with-readline=≪readline-path≫
Baculaにreadlineのインストール先を知らせます。通常、Baculaは標準ライブラリの中にあればreadlineを見つけ出します。見つからず、--with-readlineオプションが指定されていなかった場合、readlineは無効化されます。このオプションはBaculaのビルドに影響します。readlineはコマンドラインの履歴と変種機能を持つConsoleプログラムを提供しますが、現在ではサポートされていません。したがって、問題が発生した場合には自力で対処してください。
--enable-readline
Baculaにreadlineのサポートを有効にするように指示します。通常は、多数の設定上の問題とバージョン間で互換性がとれない形で変化するため、無効化されています。
--with-tcp-wrappers=≪path≫
TCP wrapper(man hosts_access(5))を一緒にコンパイルするかどうかを指定します。パスの指定は必須ではありません。Baculaはライブラリを通常、標準的な位置を探すからです。このオプションはBaculaのビルドに影響します。アクセス制限を/etc/hosts.allowもしくは/etc/hosts.denyで指定している場合は、twistオプション（hosts_options(5)）を使用しないでください。使用した場合、Baculaは停止します。注意すべきは、/etc/hosts.allowもしくは/etc/hosts.denyをセットアップする際、Baculaのデーモンを当該のデーモンに対してconfファイル内で与えた名前をつかって特定し、実行ファイルの名前で指定しないことです。
TCP wrapperの設定とテストについての情報は、"Security"の章の"Configuring and Testing TCP Wrappers"の項を参照してください。
SuSEでは、Baculaとリンクするのに必要なlibwrappersライブラリはtcpd-develパッケージに含まれています。Red Hatの場合、パッケージの名前はtcp_wrappersです。
--with-archivedir=≪path≫
ディスクベースのバックアップのために使われるディレクトリで、デフォルトでは/tmpです。このパラメータはデフォルト値をbacula-dir.confとbacula-sd.confの各設定ファイルで指定します。例えば、デフォルトのリストア・ジョブに対してWhereディレクティブを指定する、FileStorageデバイスにに対して、Archive Deviceディレクティブを指定する、など。
--with-working-dir=≪working-directory-path≫
このオプションは必須であり、Baculaがジョブを実行している際にファイルを安全に保持する場所を指定します。たとえば、internal databaseが使用されている場合、Baculaはそれらのファイルをこのディレクトリに保持します。このオプションはデーモンの設定ファイルを変更するためだけに使われます。したがって、同様のことを直接設定ファイルを編集することで実現できますが、ワーキング・ディレクトリはインストールの過程で自動的には作成されません。したがって、Baculaを最初に動かすときに、ワーキング・ディレクトリが存在することを必ず確認してください。
--with-base-port=≪port=number≫
Baculaを動作させるにあたって、Baculaには3つのTCP/IPポート（Bacula Console用、Storageデーモン用、Fileデーモン用）が必要です。--with-base-portオプションは、自動的に、指定された元になるポートのアドレスから始まる三つのポートを割当てます。結果生成されるファイルのなかのポート番号を変更することもできます。しかしながら、3つのデーモンの設定ファイルで、番号が一致するように注意してください。デフォルトの元になるポートは9101で、ポート9101から9103までを割り当てます。これらのポート（9101、9102、9103）は、Baculaに対して、IANAが公式に割り当てたポートです。このオプションはデーモンの設定ファイルを変更するためだけに使われます。したがって、同様のことを直接設定ファイルを編集することで実現できます。
--with-dump-email=≪email-address≫
コアダンプが送信されるemailアドレスを指定します。通常開発者のみが使用します。
--with-pid-dir=≪PATH≫
Baculaが実行されている間に、プロセスIDファイルをどこに配置するかを指定します。デフォルトは/var/runです。このディレクトリはインストールの過程で自動的には作成されません。したがって、Baculaを最初に動かすときに、存在することを必ず確認してください。
--with-subsys-dir=≪PATH≫
his specifies where Bacula should place the subsystem lock file during execution. The default is /var/run/subsys. Please make sure that you do not specify the same directory for this directory and for the sbindir directory. This directory is used only within the autostart scripts. The subsys directory is not created by the Bacula install, so you must be sure to create it before using Bacula.
--with-dir-password=≪Password≫
このオプションは、Directorに（通常Consoleプログラムから）アクセスする際のパスワードを設定します。指定しなかった場合、configure[スクリプト]は自動的にランダムなパスワードを生成します。
--with-fd-password=≪Password≫
このオプションは、（通常Directorから呼び出される）Fileデーモンにアクセスする際のパスワードを設定します。指定しなかった場合、configureスクリプトは自動的にランダムなパスワードを生成します。
--with-sd-password=≪Password≫
このオプションは、Storageデーモンにアクセスする（通常Directorから呼び出される）際のパスワードを設定します。指定しなかった場合、configureスクリプトは自動的にランダムなパスワードを生成します。
--with-dir-user=≪User≫
Directorを動作させる際のUserIDを指定する際に使用されるオプションです。Directorはroot権限で起動しなければなりませんが、rootとして走り続けなければならないということはなく、したがって、事前の初期化が終わった後は、このオプションで指定したIDに"落ちる"ようにできます。このオプションを指定した場合、make installを実行する前にユーザを作成してください。というのも、ワーキング・ディレクトリの持ち主はこのUser、になるからです。
--with-dir-group=≪Group≫
Directorを動作させる際のGroupIDを指定する際に使用されるオプションです。Directorはroot権限で起動しなければなりませんが、rootとして走り続けなければならないということはなく、したがって、事前の初期化が終わった後は、このオプションで指定したに"落ちる"ようにできます。このオプションを指定した場合、make installを実行する前にグループを作成してください。というのも、ワーキング・ディレクトリの所属グループはこのGroup、になるからです。
--with-sd-user=≪User≫
Storageデーモンを動作させる際のUSERIDを指定する際に使用されるオプションです。Storageデーモンはroot権限で起動しなければなりませんが、rootとして走り続けなければならないということはなく、したがって、事前の初期化が終わった後は、このオプションで指定したIDに"落ちる"ようにできます。このオプションを指定した場合、Strageデーモンを必要になるすべてのデバイス（テープドライブ、…）にアクセス可能な状態にしておくように注意してください。
--with-sd-group=≪Group≫
Storageデーモンを動作させる際のGROUPIDを指定する際に使用されるオプションです。Storageデーモンはroot権限で起動しなければなりませんが、rootとして走り続けなければならないということはなく、したがって、事前の初期化が終わった後は、このオプションで指定したIDに"落ちる"ようにできます。
--with-fd-user=≪User≫
Fileデーモンを動作させる際のUserIDを指定する際に使用されるオプションです。Fileデーモンはroot権限で起動しなければならず、ほとんどのケースでrootとして動作している必要があります。したがってこのプションが使用されるのは非常に特殊なケースです。事前の初期化が終わった後、このオプションで指定したIDに"落ちる"ようにできます。
--with-fd-group=≪Group≫
Fileデーモンを動作させる際のGroupIDを指定する際に使用されるオプションです。Fileデーモンはroot権限で起動しなければならず、ほとんどのケースでrootとして走る必要がありますが、事前の初期化が終わった後、このオプションで指定したIDに"落ちる"ようにできます。
--with-mon-dir-password=≪Password≫
Directorにモニタからアクセスする際のパスワードを指定します。指定しなかった場合、configureスクリプトはランダムなパスワードを自動的に生成します。
--with-mon-fd-password=≪Password≫
Fileデーモンにモニタからアクセスする際のパスワードを指定します。指定しなかった場合、configureスクリプトはランダムなパスワードを自動的に生成します。
--with-mon-sd-password=≪Password≫
Storageデーモンにモニタからアクセスする際のパスワードを指定します。指定しなかった場合、configureスクリプトはランダムなパスワードを自動的に生成します。
--with-db-name=≪database-name≫
confファイル内で使用されるデータベース名を指定します。デフォルト値はbaculaです。
--with-db-user=≪database-user≫
confファイル内で使用されるデータベースのユーザ名を指定します。デフォルト値はbaculaです。
注：他の多くのオプションは./configure --helpを実行すると表示されますが、実装されていません。
Recommended Options for Most Systems
ほとんどのシステムにおいて、次のオプションを有効にして起動することを推奨します。
./configure \
--enable-smartalloc \
--sbindir=$HOME/bacula/bin \
--sysconfdir=$HOME/bacula/bin \
--with-pid-dir=$HOME/bacula/bin/working \
--with-subsys-dir=$HOME/bacula/bin/working \
--with-mysql=$HOME/mysql \
--with-working-dir=$HOME/bacula/working
Baculaを、ビルドディレクトリの外ではなく、中にインストールしたい場合（開発者はほとんどの場合そうしています）、--sbindir と --sysconfdir オプションを適切なパスとともに追加してください。開発中の場合ではほとんどの場合そうですが、"make install"を実行しないときは両方とも必要ありません。インストールの過程でsibindir と sysconfdir は、存在しない場合、作成されます。一方でpid-dir、subsys-dir、working-dirは自動的には作成されず、したがって、Baculaを初めて稼働させる際にはそれらが存在することを必ず確認してください。
Red Hat
SQLiteを使用する場合:
CFLAGS="-g -Wall" ./configure \
--sbindir=$HOME/bacula/bin \
--sysconfdir=$HOME/bacula/bin \
--enable-smartalloc \
--with-sqlite=$HOME/bacula/depkgs/sqlite \
--with-working-dir=$HOME/bacula/working \
--with-pid-dir=$HOME/bacula/bin/working \
--with-subsys-dir=$HOME/bacula/bin/working \
--enable-bat \
--with-qwt=$HOME/bacula/depkgs/qwt \
--enable-conio
もしくは、
CFLAGS="-g -Wall" ./configure \
--sbindir=$HOME/bacula/bin \
--sysconfdir=$HOME/bacula/bin \
--enable-smartalloc \
--with-mysql=$HOME/mysql \
--with-working-dir=$HOME/bacula/working
--with-pid-dir=$HOME/bacula/bin/working \
--with-subsys-dir=$HOME/bacula/bin/working
--enable-gnome \
--enable-conio
最後、Red Hat Linuxの伝統に忠実にインストールを行う場合：
CFLAGS="-g -Wall" ./configure \
--prefix=/usr \
--sbindir=/usr/sbin \
--sysconfdir=/etc/bacula \
--with-scriptdir=/etc/bacula \
--enable-smartalloc \
--enable-bat \
--with-qwt=$HOME/bacula/depkgs/qwt \
--with-mysql \
--with-working-dir=/var/bacula \
--with-pid-dir=/var/run \
--enable-conio
注意すべきこととしては、Baculaは/var/bacula、/var/run、/var/lock/subsysが存在すると仮定しています。したがって、インストールの過程で自動的に生成されることはありません。
Solaris
ソースからBaculaをビルドするには、次に示すものがシステムにインストールされている必要があります（それらはデフォルトでインストールされているものではありません）：libiconv、 gcc 3.3.2、 stdc++、 libgcc (stdc++ と gcc_s ライブラリ用)、make 3.8 もしくはそれ以降のバージョン。
また次の作業も必要になるでしょう：/usr/local/binをPATHに加えること、および/usr/ccs/binをPATHに加えること
BaculaをSolaris上で、Soralisのコンパイラを用いてビルドすることは可能ですが、GNU C++ 使用が可能であるならそれをお勧めします。
一般的なconfigurationのコマンドは以下のようになるでしょう：
#!/bin/sh
CFLAGS="-g" ./configure \
--sbindir=$HOME/bacula/bin \
--sysconfdir=$HOME/bacula/bin \
--with-mysql=$HOME/mysql \
--enable-smartalloc \
--with-pid-dir=$HOME/bacula/bin/working \
--with-subsys-dir=$HOME/bacula/bin/working \
--with-working-dir=$HOME/bacula/working
上で述べたように、インストールの過程でsbindirとsysconfdirは、存在しない場合は自動的に作成されますが、pid-dir、subsys-dir、working-dirは自動的には作成されず、したがって、Baculaを初めて稼働させる際にはそれらが存在することを必ず確認してください。
注意。以下のパッケージがBaculaのインストールの際必要になるでしょう。
SUNWbinutils,
SUNWarc,
SUNWhea,
SUNWGcc,
SUNWGnutls
SUNWGnutls-devel
SUNWGmake
SUNWgccruntime
SUNWlibgcrypt
SUNWzlib
SUNWzlibs
SUNWbinutilsS
SUNWGmakeS
SUNWlibm
[さらにパスを通す作業]
export
PATH=/usr/bin::/usr/ccs/bin:/etc:/usr/openwin/bin:/usr/local/bin:/usr/sfw/bin:/opt/sfw/bin:/usr/ucb:/usr/sbin
通常Solarisにインストールされていない特殊なソフトウェア、例えばOpenSSL、もしくは上で示したパッケージなどをインストールしている場合、/usr/sfw/linbをライブラリ・サーチ・パスに追加する必要があります。おそらく最も簡単な方法は次のコマンドを実行することです。
setenv LDFLAGS "-L/usr/sfw/lib -R/usr/sfw/lib"
これらは./configureコマンドを実行する前に行ってください。
また、代わりに、LD_LIBRARY_PATH そして/あるいは LD_RUN_PATH 環境変数を適切に設定することも可能です。
crleプログラムをライブラリ・サーチ・パスを設定するのに使用することも可能ですが、注意して行ってください。
FreeBSD
次を参照：Baculaをmakeして使用中のシステムで稼働させるための詳細な説明については"The FreeBSD Diary"を参照。さらに、"FreeBSD 4.9-STABLE dated Mon Dec 29 15:18:01 2003 UTC"以前を使用していて、テープドライブの使用を計画している場合、このマニュアルの"Tape Testing Chapter"を参照してください。使用するテープドライブとBaculaとの互換性をどのように設定するかについての非常に重要な情報が書かれています。
MySQLとBaculaを組み合わせて使っている場合、LinuxThreadよりむしろFreeBSDにネイティブなスレッドでコンパイルするように注意してください。というのも、Baculaは通常LinuxThreadよりもむしろFreeBSDネイティブなスレッドでビルドされているからです。二つを混ぜてしまうとおそらく動作しないでしょう。
Win32
Win32バージョンのFileデーモン・バイナリをインストールするには、このマニュアルの"Win32 Installation Chapter"を参照してください。
One File Configure Script
以下のスクリプトは、やるべきことをすべて一つのファイルにおさめてしまいたいという人向けのものです。
#!/bin/sh
CFLAGS="-g -Wall" \
./configure \
--sbindir=$HOME/bacula/bin \
--sysconfdir=$HOME/bacula/bin \
--mandir=$HOME/bacula/bin \
--enable-smartalloc \
--enable-gnome \
--enable-bat \
--with-qwt=$HOME/bacula/depkgs/qwt \
--enable-bwx-console \
--enable-tray-monitor \
--with-pid-dir=$HOME/bacula/bin/working \
--with-subsys-dir=$HOME/bacula/bin/working \
--with-mysql \
--with-working-dir=$HOME/bacula/bin/working \
--with-dump-email=$USER@your-site.com \
--with-job-email=$USER@your-site.com \
--with-smtp-host=mail.your-site.com
exit 0
また、/etc/servicesファイルに以下のエントリを加え、Baculaによるネットワーク接続をしらべるのをより簡単でわかりやすくしたい、と考えるかもしれません（たとえば、netstat -aを実行する）：
bacula-dir 9101/tcp
bacula-fd 9102/tcp
bacula-sd 9103/tcp
Installing Bacula
設定ファイルをセットアップする前に、確定した位置にBaculaをインストールしたい、と思うでしょう。単純に、次のように入力してください:
make install
以前にBaculaをインストールしていたのであれば、古いバイナリは上書きされます。ですが、設定ファイルは変更されずにそのままのこり、"新しい（new）"設定ファイルが .newが付加された形で作成されます。一般的に、Baculaを以前にインストールして稼働させていた場合、.newが付加された新しい設定ファイルは捨ててしまいたいと考えるでしょう。
Building a File Daemon or Client
DirectorとStorageデーモンを単一のマシンで走らせていて、別のマシンをバックアップ対象にしている場合、そのマシンにFileデーモンのコピーをおいておく必要があります。そのマシンとオペレーティング・システムが同一性を担保するなら、単純にBacula Fileデーモンのバイナリファイルであるbacula-fdを設定ファイルであるbacula-fd.confと一緒にコピーし、しかる後にconfファイル内のnameとpasswordをユニークなものに設定すればよいでしょう。Directorの設定ファイル（bacula-dir.conf）に加えられるものと対応していることを確認してください。
FileデーモンはCatalogデータベースにアクセスしないため、--with-mysqlもしくは--with-sqliteオプションを削除し、--enable-client-onlyを加えてください。これによって、必要なライブラリとクライアント・プログラムだけがコンパイルされ、従って、何らかのデータベース・プログラムをFileデーモンをビルドする際にインストールしてしまうことをさけることができます。このオプションで、makeを入力すれば、クライアントがビルドされます。
Auto Starting the Daemons
システムが起動した時に自動的にデーモン群を起動させたい（いいアイディアです）という場合、もう一つステップを踏む必要があります。まず、./configureが使用中のシステムを認識すること -- すなわち、サポートされたプラットフォームであり、unknownホストでない、という状態でなければなりません。次に、プラットフォームに依存するファイルを以下のようにしてインストールしてください：
（root権限を取得後）
make install-autostart
以下のことに注意してください。auto-start機能はBaculaプロジェクトが公式にサポートするシステム（現在のところ、FreeBSD、Red Hat/Fedora Linux、Solaris）でのみ実装されているということです。また、完全なテストはFedora Linuxでしか行っていません。
make install-autostart は適切なスタートアップ・スクリプトを必須のシンボリックリンクを含めてインストールします。Red Hat/Fedora Linux システムでは、これらのスクリプトは/etc/rc.d/init.d/bacula-dir、/etc/rc.d/init.d/bacula-fd、/etc/rc.d/init.d/bacula-sdにそれぞれ格納されます。しかしながら正確な格納場所は使用しているオペレーティング・システムに依存します。
Fileデーモンについてのみインストールしたい、という場合は、以下のようにするとよいでしょう：
make install-autostart-fd
Other Make Notes
単純に新しい実行ファイルを、どんなディレクトリにでもいいのでビルドするには、以下のように入力してください：
make
objectsとバイナリ（1、2、もしくは3という名前のついたファイルを含んでいますが、これらは開発の際にできる一時ファイルです）を消去する場合、以下のように入力してください：
make clean
提供されたものすべてを消去する場合、以下のように入力してください：
make distclean
note, this cleans out the Makefiles and is normally done from the top level directory to prepare for distribution of the source. To recover from this state, you must redo the ./configure in the top level directory, since all the Makefiles will be deleted.
新しいファイルをサブディレクトリに格納するには、そのディレクトリ内のMakefile.inを編集し、makeを実行してください。ほとんどの場合、makeを実行することであたらしいMakefile.inファイルからMakefileがリビルドされます。二度makeを実行しなければならない場合もあり得ます。極端な場合、cdコマンドでトップレベルディレクトリに移動して、次のように入力することになります。make Makefiles
依存関係を追加するには：
make depend
The make depend appends the header file dependencies for each of the object files to Makefile and Makefile.in. This command should be done in each directory where you change the dependencies. Normally, it only needs to be run when you add or delete source or header files. make depend is normally automatically invoked during the configuration process.
To install:
make install
This not normally done if you are developing Bacula, but is used if you are going to run it to backup your system.
After doing a make install the following files will be installed on your system (more or less). The exact files and location (directory) for each file depends on your ./configure command (e.g. bgnome-console and bgnome-console.conf are not installed if you do not configure GNOME. Also, if you are using SQLite instead of MySQL, some of the files will be different).
注：以下のリストは現行のものと違っているかもしれませんが、出発点はこうでした。
bacula
bacula-dir
bacula-dir.conf
bacula-fd
bacula-fd.conf
bacula-sd
bacula-sd.conf
bacula-tray-monitor
tray-monitor.conf
bextract
bls
bscan
btape
btraceback
btraceback.gdb
bconsole
bconsole.conf
create_mysql_database
dbcheck
delete_catalog_backup
drop_bacula_tables
drop_mysql_tables
bgnome-console
bgnome-console.conf
make_bacula_tables
make_catalog_backup
make_mysql_tables
mtx-changer
query.sql
bsmtp
startmysql
stopmysql
bwx-console
bwx-console.conf
9 man pages
Installing Tray Monitor
Tray Monitorは --enable-tray-monitor オプションをつけてconfigureスクリプトを実行し、make installを実行した場合、すでにインストールされています。
グラフィック環境をroot権限で実行していないので（[root権限で実行するのは]良くない習慣なのでやめた方がいいですが）、tray-monitor.confの読み出し権限を自分が使用しているユーザに割当て、bacula-tray-monitorに実行権限を与えてください。
その後グラフィック環境（KDE、GNOME、もしくは他の何か）にログインし、bacula-tray-monitarを自分の使用しているユーザで実行し、カセットのアイコンがスクリーンのどこかに現れることを確認してください。通常タスクバーに出てきます。出て尾なかった場合、自分の環境もしくはウィンドウマネージャに関係している以下の指示に従ってください。
NOME
システムトレイ、もしくはGNOMEの用語では通知エリアは、 GNOME 2.2からサポートされるようになりました。アクティブな状態にするには、パネルを右クリックして、Add to this Panelのメニューをひらき、続いてUtilityをひらいて、最後にNotification Areaをクリックしてください。
KDE
システムトレイはKDE 3.1からサポートされるようになりました。アクティブな状態にするには、パネルを右クリックし、Addメニューを開き、続いてAppletをひらいて、最後にSystemTrayをクリックしてください。
Other window managers
自分の使用しているデスクトップマネージャがFreedesktop system tray standardに準拠していて、適用可能かどうか、アクティブにするにはどうしたらいいかをドキュメントを読んで調べてください。
Modifying the Bacula configuration Files
このマニュアルの"Configuring Bacula"の章を参照して、Baculaの設定ファイルを設定する方法を調べてください。