%%
%%

\section*{Bacula\raisebox{.6ex}{{\footnotesize
\textsuperscript{\textregistered}}} - RPM Packaging FAQ}
\label{_ChapterStart34}
\index[general]{FAQ!Bacula\textsuperscript{\textregistered} - RPM Packaging }
\index[general]{Bacula\textsuperscript{\textregistered} - RPM Packaging FAQ }
\addcontentsline{toc}{section}{Bacula\textsuperscript{\textregistered} - RPM
Packaging FAQ}

\begin{enumerate}
\item 
   \ilink{How do I build Bacula for platform xxx?}{faq1}  
\item 
   \ilink{How do I control which database support gets built?}{faq2} 

\item 
   \ilink{What other defines are used?}{faq3}  
\item 
   \ilink{I'm getting errors about not having permission when I try to build the
   packages. Do I need to be root?}{faq4}  
\item 
   \ilink{I'm building my own rpms but on all platforms and compiles I get an
   unresolved dependancy for something called
   /usr/afsws/bin/pagsh.}{faq5} 
\end{enumerate}

\subsection*{Answers}
\index[general]{Answers }
\addcontentsline{toc}{subsection}{Answers}

\begin{enumerate}
\item 
   \label{faq1}
   {\bf 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), Whitebox Enterprise Linux 3.0 (wb3), Red Hat Enterprise Linux 
   (rhel3, rhel4), Mandrake 10.x (mdk), 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

\footnotesize
\begin{verbatim}
        %define rh7 0
        
\end{verbatim}
\normalsize

and edit it to read  

\footnotesize
\begin{verbatim}
        %define rh7 1
        
\end{verbatim}
\normalsize

Alternately you may pass the define on the command line when calling rpmbuild:
 

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

\item 
   \label{faq2}
   {\bf 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  

\footnotesize
\begin{verbatim}
        %define mysql 0
        OR
        %define mysql4 0
        
\end{verbatim}
\normalsize

to  

\footnotesize
\begin{verbatim}
        %define mysql 1
        OR
        %define mysql4 1
        
\end{verbatim}
\normalsize

in the spec file directly or pass it to rpmbuild on the command line:  

\footnotesize
\begin{verbatim}
        rpmbuild -ba --define "build_rh7 1" --define "build_mysql 1" bacula.spec
        rpmbuild -ba --define "build_rh7 1" --define "build_mysql4 1" bacula.spec
        
\end{verbatim}
\normalsize

\item 
   \label{faq3}
   {\bf What other defines are used?}
   Two other building defines of note are the depkgs\_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.  
\item 
   \label{faq4}
   {\bf 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:

\footnotesize
\begin{verbatim}
        chmod -R 777 /usr/src/redhat
        chmod -R 777 /usr/src/RPM
        chmod -R 777 /usr/src/packages
        
\end{verbatim}
\normalsize

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

{\tt .rpmmacros} 

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

\footnotesize
\begin{verbatim}
        %_topdir /home/myuser/redhat
        
\end{verbatim}
\normalsize

Another handy directive for the .rpmmacros file if you wish to supress the
creation of debug rpm packages is:

\footnotesize
\begin{verbatim}
        %debug_package %{nil}
        
\end{verbatim}

\normalsize

\item 
   \label{faq5}
   {\bf 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.
\end{enumerate}

\item {\bf 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.

\footnotesize
\begin{verbatim}
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"'
\end{verbatim}
\normalsize

\subsection*{Build Options}
\index[general]{Build Options}
\addcontentsline{toc}{subsection}{Build Options}
The spec file currently supports building on the following platforms:
\footnotesize
\begin{verbatim}
# 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"

# 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, SuSE 9.x & 10.x, FC4 & RHEL4
--define "build_mysql4 1"

PostgreSQL support:
--define "build_postgresql 1"

Sqlite support:
--define "build_sqlite 1"

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

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

\end{verbatim}
\normalsize

\subsection*{RPM Install Problems}
\index[general]{RPM Install Problems}
\addcontentsline{toc}{subsection}{RPM Install Options}
In general the RPMs, once properly built should install correctly.
However, when attempting to run the daemons, a number of problems
can occur:
\begin{itemize}
\item [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:
\begin{verbatim}
  chown bacula:bacula /var/bacula
\end{verbatim}
\item [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.
\end{itemize}
 

