- How do I build Bacula for platform xxx?
The bacula spec file contains defines to build for several platforms:
Red Hat 7.x (rh7), Red Hat 8.0 (rh8), Red Hat 9 (rh9), Fedora Core (fc1,
fc3, fc4, fc5, fc6, fc7), Whitebox Enterprise Linux 3.0 (wb3), Red Hat Enterprise Linux
(rhel3, rhel4), Mandrake 10.x (mdk), Mandriva 2006.x (mdv) CentOS (centos3, centos4)
Scientific Linux (sl3, sl4) and SuSE (su9, su10, su102). The package build is controlled by a mandatory define set at the beginning of the file. These defines basically just control the dependency information that gets coded into the finished rpm package as well
as any special configure options required. The platform define may be edited
in the spec file directly (by default all defines are set to 0 or "not set").
For example, to build the Red Hat 7.x package find the line in the spec file
which reads
%define rh7 0
and edit it to read
%define rh7 1
Alternately you may pass the define on the command line when calling rpmbuild:
rpmbuild -ba --define "build_rh7 1" bacula.spec
rpmbuild --rebuild --define build_rh7 1" bacula-x.x.x-x.src.rpm
- How do I control which database support gets built?
Another mandatory build define controls which database support is compiled,
one of build_sqlite, build_mysql or build_postgresql. To get the MySQL
package and support either set the
%define mysql 0
OR
%define mysql4 0
OR
%define mysql5 0
to
%define mysql 1
OR
%define mysql4 1
OR
%define mysql5 1
in the spec file directly or pass it to rpmbuild on the command line:
rpmbuild -ba --define "build_rh7 1" --define "build_mysql 1" bacula.spec
rpmbuild -ba --define "build_rh7 1" --define "build_mysql4 1" bacula.spec
rpmbuild -ba --define "build_rh7 1" --define "build_mysql5 1" bacula.spec
- What other defines are used?
Three other building defines of note are the depkgs_version, docs_version and
_rescuever identifiers. These two defines are set with each release and must
match the version of those sources that are being used to build the packages.
You would not ordinarily need to edit these. See also the Build Options section
below for other build time options that can be passed on the command line.
- I'm getting errors about not having permission when I try to build the
packages. Do I need to be root?
No, you do not need to be root and, in fact, it is better practice to
build rpm packages as a non-root user. Bacula packages are designed to
be built by a regular user but you must make a few changes on your
system to do this. If you are building on your own system then the
simplest method is to add write permissions for all to the build
directory (/usr/src/redhat/, /usr/src/RPM or /usr/src/packages).
To accomplish this, execute the following command as root:
chmod -R 777 /usr/src/redhat
chmod -R 777 /usr/src/RPM
chmod -R 777 /usr/src/packages
If you are working on a shared system where you can not use the method
above then you need to recreate the appropriate above directory tree with all
of its subdirectories inside your home directory. Then create a file named
.rpmmacros
in your home directory (or edit the file if it already exists)
and add the following line:
%_topdir /home/myuser/redhat
Another handy directive for the .rpmmacros file if you wish to suppress the
creation of debug rpm packages is:
%debug_package %{nil}
- I'm building my own rpms but on all platforms and compiles I get an
unresolved dependency for something called /usr/afsws/bin/pagsh. This
is a shell from the OpenAFS (Andrew File System). If you are seeing
this then you chose to include the docs/examples directory in your
package. One of the example scripts in this directory is a pagsh
script. Rpmbuild, when scanning for dependencies, looks at the shebang
line of all packaged scripts in addition to checking shared libraries.
To avoid this do not package the examples directory. If you are seeing this
problem you are building a very old bacula package as the examples have been
removed from the doc packaging.
- I'm building my own rpms because you don't publish for my platform.
Can I get my packages released to sourceforge for other people to use? Yes,
contributions from users are accepted and appreciated. Please examine the
directory platforms/contrib-rpm in the source code for further information.
- Is there an easier way than sorting out all these command line options? Yes,
there is a gui wizard shell script which you can use to rebuild the src rpm package.
Look in the source archive for platforms/contrib-rpm/rpm_wizard.sh. This script will
allow you to specify build options using GNOME dialog screens. It requires zenity.
- I just upgraded from 1.36.x to 1.38.x and now my director daemon
won't start. It appears to start but dies silently and I get a "connection
refused" error when starting the console. What is wrong? Beginning with
1.38 the rpm packages are configured to run the director and storage
daemons as a non-root user. The file daemon runs as user root and group
bacula, the storage daemon as user bacula and group disk, and the director
as user bacula and group bacula. If you are upgrading you will need to
change some file permissions for things to work. Execute the following
commands as root:
chown bacula.bacula /var/bacula/*
chown root.bacula /var/bacula/bacula-fd.9102.state
chown bacula.disk /var/bacula/bacula-sd.9103.state
Further, if you are using File storage volumes rather than tapes those
files will also need to have ownership set to user bacula and group bacula.
- There are a lot of rpm packages. Which packages do I need for
what? For a bacula server you need to select the packsge based upon your
preferred catalog database: one of bacula-mysql, bacula-postgresql or
bacula-sqlite. If your system does not provide an mtx package you also
need bacula-mtx to satisfy that dependancy. For a client machine you need
only install bacula-client. Optionally, for either server or client
machines, you may install a graphical console bacula-gconsole and/or
bacula-wxconsole. The Bacula Administration Tool is installed with the
bacula-bat package. One last package, bacula-updatedb is required only when
upgrading a server more than one database revision level.
- Support for RHEL3/4, CentOS 3/4 and x86_64
The examples below show
explicit build support for RHEL4 and CentOS 4. Build support
for x86_64 has also been added. Test builds have been done on CentOS but
not RHEL4.