<< Back to man.ChinaUnix.net

next up previous contents index
Next: The Bootstrap File Up: Bacula User's Guide Previous: Using Bacula to Improve   Contents   Index

Subsections


Bacula® - RPM Packaging FAQ

  1. How do I build Bacula for platform xxx?
  2. How do I control which database support gets built?

  3. What other defines are used?
  4. I'm getting errors about not having permission when I try to build the packages. Do I need to be root?
  5. I'm building my own rpms but on all platforms and compiles I get an unresolved dependancy for something called /usr/afsws/bin/pagsh.
  6. 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?

Answers

  1. How do I build Bacula for platform xxx? The bacula spec file contains defines to build for several platforms: RedHat 7.x (rh7), RedHat 8.0 (rh8), RedHat 9 (rh9), Fedora Core (fc1, fc3, fc4, fc5), Whitebox Enterprise Linux 3.0 (wb3), Red Hat Enterprise Linux (rhel3, rhel4), Mandrake 10.x (mdk), Mandriva 2006.x (mdv) CentOS (centos3, centos4) and SuSE (su9, su10). 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 RedHat 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
    

  2. 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
            

    to

            %define mysql 1
            OR
            %define mysql4 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
    

  3. 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.
  4. 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 supress the creation of debug rpm packages is:

            %debug_package %{nil}
            

  5. 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.

  6. 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.

  7. 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.

Build with one of these 3 commands:

rpmbuild --rebuild \
        --define "build_rhel4 1" \
        --define "build_sqlite 1" \
        bacula-1.38.3-1.src.rpm

rpmbuild --rebuild \
        --define "build_rhel4 1" \
        --define "build_postgresql 1" \
        bacula-1.38.3-1.src.rpm

rpmbuild --rebuild \
        --define "build_rhel4 1" \
        --define "build_mysql4 1" \
        bacula-1.38.3-1.src.rpm

For CentOS substitute '--define "build_centos4 1"' in place of rhel4.

For 64 bit support add '--define "build_x86_64 1"'

Build Options

The spec file currently supports building on the following platforms:
RedHat builds
--define "build_rh7 1"
--define "build_rh8 1"
--define "build_rh9 1"

Fedora Core build
--define "build_fc1 1"
--define "build_fc3 1"
--define "build_fc4 1"
--define "build_fc5 1"

Whitebox Enterprise build
--define "build_wb3 1"

RedHat Enterprise builds
--define "build_rhel3 1"
--define "build_rhel4 1"

CentOS build
--define "build_centos3 1"
--define "build_centos4 1"

SuSE build
--define "build_su9 1"
--define "build_su10 1"

Mandrake 10.x build
--define "build_mdk 1"

Mandriva build
--define "build_mdv 1"

MySQL support:
for mysql 3.23.x support define this
--define "build_mysql 1"
if using mysql 4.x define this,
currently: Mandrake 10.x, Mandriva 2006.0, SuSE 9.x & 10.0, FC4 & RHEL4
--define "build_mysql4 1"
if using mysql 5.x define this,
currently: SuSE 10.1 & FC5
--define "build_mysql5 1"

PostgreSQL support:
--define "build_postgresql 1"

Sqlite support:
--define "build_sqlite 1"

Build the client rpm only in place of one of the above database full builds:
--define "build_client_only 1"

X86-64 support:
--define "build_x86_64 1"

Supress build of gnome console:
--define "nobuild_gconsole 1"

Build the WXWindows console:
requires wxGTK >= 2.6
--define "build_wxconsole 1"

Build python scripting support:
--define "build_python 1"

Modify the Packager tag for third party packages:
--define "contrib_packager Your Name <youremail@site.org>"

RPM Install Problems

In general the RPMs, once properly built should install correctly. However, when attempting to run the daemons, a number of problems can occur:
Wrong /var/bacula Permissions
By default, the Director and Storage daemon do not run with root permission. If the /var/bacula is owned by root, then it is possible that the Director and the Storage daemon will not be able to access this directory, which is used as the Working Directory. To fix this, the easiest thing to do is:
  chown bacula:bacula /var/bacula
Note: as of 1.38.8 /var/bacula is installed root:bacula with permissions 770.
The Storage daemon cannot Access the Tape drive
This can happen in some older RPM releases where the Storage daemon ran under userid bacula, group bacula. There are two ways of fixing this: the best is to modify the /etc/init.d/bacula-sd file so that it starts the Storage daemon with group "disk". The second way to fix the problem is to change the permissions of your tape drive (usually /dev/nst0) so that Bacula can access it. You will probably need to change the permissions of the SCSI control device as well, which is usually /dev/sg0. The exact names depend on your configuration, please see the Tape Testing chapter for more information on devices.


next up previous contents index
Next: The Bootstrap File Up: Bacula User's Guide Previous: Using Bacula to Improve   Contents   Index
Kern Sibbald 2006-07-30