\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}
+ /usr/afsws/bin/pagsh.}{faq5}
\end{enumerate}
\subsection*{Answers}
\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), Whitebox
-Enterprise Linux (RHEL) 3.0 (wb3), Mandrake 10.x (mdk) and SuSE 9.x (su9).
-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.
-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
+ 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}
\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
+ 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
\footnotesize
\begin{verbatim}
%define mysql 1
+ OR
+ %define mysql4 1
\end{verbatim}
\normalsize
\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 tomsrtbt
-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.
+ 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/). To accomplish
-this, execute the following command as root:
+ 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 /usr/src/redhat 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)
+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
\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.
+ {\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 RHEL4, CentOS 4 and x86_64}
-The examples below
-explicit build support for RHEL4 (I think) and CentOS 4. Build support
-for x86_64 has also been added. Test builds have been done on CentOS but
-not RHEL4.
+\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}
rpmbuild --rebuild \
--define "build_rhel4 1" \
--define "build_sqlite 1" \
- bacula-1.36.2-4.src.rpm
+ bacula-1.38.3-1.src.rpm
rpmbuild --rebuild \
--define "build_rhel4 1" \
--define "build_postgresql 1" \
- bacula-1.36.2-4.src.rpm
+ bacula-1.38.3-1.src.rpm
rpmbuild --rebuild \
--define "build_rhel4 1" \
- --define "build_mysql 1" \
--define "build_mysql4 1" \
- bacula-1.36.2-4.src.rpm
+ bacula-1.38.3-1.src.rpm
For CentOS substitute '--define "build_centos4 1"' in place of rhel4.
--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 build
--define "build_mdk 1"
MySQL support:
+# for mysql 3.23.x support define this
--define "build_mysql 1"
-# if using mysql 4.x define this and mysql above
-# currently: Mandrake 10.x, SuSE 9.x, RHEL4
+# if using mysql 4.x define this
+# currently: Mandrake 10.x, SuSE 9.x & 10.x, FC4 & RHEL4
--define "build_mysql4 1"
PostgreSQL support:
\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}
+
+
projects / bacula / docs / blobdiff