\chapter{\bacula{} \acs{RPM} Packaging FAQ}
\label{blb:RpmFaqChapter}
\index[general]{FAQ!\bacula{}\bregistered{} - \acs{RPM} Packaging }
\index[general]{\bacula{}\bregistered{} - \acs{RPM} Packaging FAQ }

\begin{benumerate}
\item 
   \bilink{How do I build \bacula{} for platform xxx?}{blb:faq1}  
\item 
   \bilink{How do I control which database support gets built?}{blb:faq2} 
\item 
   \bilink{What other defines are used?}{blb:faq3}  
\item 
   \bilink{I'm getting errors about not having permission when I try to build the packages. Do I need to be \texttt{root}?}{blb:faq4}  
\item 
   \bilink{I'm building my own rpms but on all platforms and compiles I get an unresolved dependency for something called \bfilename{/usr/afsws/bin/pagsh}.}{blb:faq5} 
\item 
   \bilink{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?}{blb:faq6} 
\item 
   \bilink{Is there an easier way than sorting out all these command line options?}{blb:faq7}
\item
   \bilink{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?}{blb:faq8}
\item
   \bilink{There are a lot of rpm packages. Which packages do I need for what?}{blb:faq9}
\item
   \bilink{What happened to the build switches for gnome console, wxconsole and bat?}{blb:faq10}
\end{benumerate}

\section{Answers}
\index[general]{Answers }

\begin{benumerate}
\item
   \label{blb:faq1}
   \textbf{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, fc8, fc9, fc10), \\
   Whitebox Enterprise Linux 3.0 (wb3), \\
   Red Hat Enterprise Linux (rhel3, rhel4, rhel5), \\
   Mandrake 10.x (mdk), Mandriva 2006.x (mdv), \\
   CentOS (centos3, centos4, centos5) \\
   Scientific Linux (sl3, sl4, sl5) and \\
   SuSE (su9, su10, su102, su103, su110, su111, su112). \\
   \\
   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

\begin{bVerbatim}
%define rh7 0
\end{bVerbatim}

and edit it to read

\begin{bVerbatim}
%define rh7 1
\end{bVerbatim}

Alternately you may pass the define on the command line when calling \btool{rpmbuild}:

\begin{bVerbatim}
rpmbuild -ba --define "build_rh7 1" bacula.spec
rpmbuild --rebuild --define build_rh7 1" bacula-x.x.x-x.src.rpm
\end{bVerbatim}

\item
   \label{blb:faq2}
   \textbf{How do I control which database support gets built?}
   Another mandatory build define controls which database support is compiled,
   one of  \texttt{build\_sqlite}, \texttt{build\_mysql} or \texttt{build\_postgresql}. To get the \mysql{}
   package and support either set the  

\begin{bVerbatim}
%define mysql 0
\end{bVerbatim}

to

\begin{bVerbatim}
%define mysql 1
\end{bVerbatim}

in the spec file directly or pass it to \btool{rpmbuild} on the command line:

\begin{bVerbatim}
rpmbuild -ba --define "build_rh7 1" --define "build_mysql 1" bacula.spec
\end{bVerbatim}

\item
   \label{blb:faq3}
   \textbf{What other defines are used?} \\
   One other building define of note is the \texttt{depkgs\_version}. This define is set with each release and must
   match the version of the source that is being used to build the packages.
   You would not ordinarily need to edit this.  See also the Build Options section
   below for other build time options that can be passed on the command line.
\item
   \label{blb:faq4}
   \textbf{I'm getting errors about not having permission when I try  to build the packages. Do I need to be \texttt{root}?} \\
   No, you do not need to be \texttt{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 (\bdirectoryname{/usr/src/redhat/}, \bdirectoryname{/usr/src/RPM} or \bdirectoryname{/usr/src/packages}).
   To accomplish this, execute the following command as \texttt{root}:

\begin{bVerbatim}
chmod -R 777 /usr/src/redhat
chmod -R 777 /usr/src/RPM
chmod -R 777 /usr/src/packages
\end{bVerbatim}

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 \bfilename{.rpmmacros}

in your home directory (or edit  the file if it already exists)
and add the following line:

\begin{bVerbatim}
%_topdir /home/myuser/redhat
%_tmppath /tmp
\end{bVerbatim}

It should be noted that Fedora from verion 10 and up is configured to build in
the directory \bdirectoryname{~/rpmbuild}.

Another handy directive for the \bfilename{.rpmmacros} file if you wish to suppress the
creation of debug rpm packages is:

\begin{bVerbatim}
%debug_package %{nil}
\end{bVerbatim}


\item
   \label{blb:faq5}
   \textbf{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 \bdirectoryname{docs/examples} directory in
   your package.  One of the example scripts in this directory is a \btool{pagsh}
   script.  \btool{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.

\item
   \label{blb:faq6}
   \textbf{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 \bdirectoryname{platforms/contrib-rpm} in the source code for
    further information.

\item
   \label{blb:faq7}
   \textbf{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
   \bfilename{platforms/contrib-rpm/rpm\_wizard.sh}.  This script will allow you to
   specify build options using GNOME dialog screens.  It requires zenity.

\item
   \label{blb:faq8}
   \textbf{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
   \texttt{root} and group \texttt{bacula}, the storage daemon as user \texttt{bacula} and group \texttt{disk},
   and the director as user \texttt{bacula} and group \texttt{bacula}.  If you are upgrading
   you will need to change some file permissions for things to work.
   Execute the following commands as \texttt{root}:

\begin{bVerbatim}
chown bacula.bacula /var/bacula/*
chown root.bacula /var/bacula/bacula-fd.9102.state
chown bacula.disk /var/bacula/bacula-sd.9103.state
\end{bVerbatim}

Further, if you are using File storage volumes rather than tapes those
files will also need to have ownership set to user \texttt{bacula} and group \texttt{bacula}.

\item
   \label{blb:faq9}
   \textbf{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 \texttt{bacula-mysql}, \texttt{bacula-postgresql} or
\texttt{bacula-sqlite}.  If your system does not provide an \mtx{} package you also
need \texttt{bacula-mtx} to satisfy that dependancy.  For a client machine you need
only install \texttt{bacula-client}.  Optionally, for either server or client
machines, you may install a graphical console \texttt{bacula-gconsole} and/or
\texttt{bacula-wxconsole}. The \acl{BAT} is installed with the
\texttt{bacula-bat} package.  One last package, \texttt{bacula-updatedb} is required only when
upgrading a server more than one database revision level.

\item
   \label{blb:faq10}
The gnome console and wxconsole software is deprecated in favor of \bat{}. The
\bat{} (\acl{BAT}) is now packaged in it's own source \acs{RPM}. There
are no command line switches to build it. The SRPM contains the current version
of QT that bat is developed against. Building the \acs{RPM} will build QT and then build
bat against it. It will not install QT on your system. The resulting bat binary
can then be installed on a system without QT or with a different version of QT as it
will not use the QT shared objects.


\item \textbf{Support for RHEL3/4/5, CentOS 3/4/5, Scientific Linux 3/4/5 and x86\_64} \\
   The examples below show
   explicit build support for RHEL4 and CentOS 4. Build support
   for \texttt{x86\_64} has also been added.
\end{benumerate}

\begin{bVerbatim}
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 Scientific Linux substitute '--define "build_sl4 1"' in place of rhel4.

For 64 bit support add '--define "build_x86_64 1"'
\end{bVerbatim}

\section{Build Options}
\index[general]{Build Options}
The spec file currently supports building on the following platforms:
\begin{bVerbatim}
Red Hat 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"
--define "build_fc6 1"
--define "build_fc7 1"
--define "build_fc8 1"
--define "build_fc9 1"
--define "build_fc10 1"

Whitebox Enterprise build
--define "build_wb3 1"

Red Hat Enterprise builds
--define "build_rhel3 1"
--define "build_rhel4 1"
--define "build_rhel5 1"

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

Scientific Linux build
--define "build_sl3 1"
--define "build_sl4 1"
--define "build_sl5 1"

SuSE build
--define "build_su9 1"
--define "build_su10 1"
--define "build_su102 1"
--define "build_su103 1"
--define "build_su110 1"
--define "build_su111 1"
--define "build_su112 1"

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

Mandriva build
--define "build_mdv 1"

MySQL support:
--define "build_mysql 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"

Build tcpwrappers support:
--define "build_tcpwrappers 1"

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

Install most files to /opt/bacula directory:
--define "single_dir_install 1"
\end{bVerbatim}

\section{\acs{RPM} Install Problems}
\index[general]{\acs{RPM} Install Problems}
In general the \acsp{RPM}, once properly built should install correctly.
However, when attempting to run the daemons, a number of problems
can occur:
\begin{bitemize}
\item Wrong \bdirectoryname{/var/bacula} permissions \\
  By default, the Director and Storage daemon do not run with
  \texttt{root} permission. If the \bdirectoryname{/var/bacula} is owned by \texttt{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:
\begin{bVerbatim}
chown bacula:bacula /var/bacula
\end{bVerbatim}
  Note: as of 1.38.8 /var/bacula is installed \texttt{root}:\texttt{bacula} with
  permissions 770.
\item The Storage daemon cannot Access the Tape drive \\
  This can happen in some older \acs{RPM} releases where the Storage
  daemon ran under userid \texttt{bacula}, group \texttt{bacula}.  There are two
  ways of fixing this: the best is to modify the \bfilename{/etc/init.d/bacula-sd}
  file so that it starts the Storage daemon with group \texttt{disk}.
  The second way to fix the problem is to change the permissions
  of your tape drive (usually \bfilename{/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 \bfilename{/dev/sg0}.  The exact names depend
  on your configuration, please see the Tape Testing chapter for
  more information on devices.
\end{bitemize}
