%%
%%
-\section*{Bacula\raisebox{.6ex}{{\footnotesize
-\textsuperscript{\textregistered}}} - RPM Packaging FAQ}
-\label{_ChapterStart34}
+\chapter{Bacula RPM Packaging FAQ}
+\label{RpmFaqChapter}
\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
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}
+ unresolved dependency for something called
+ /usr/afsws/bin/pagsh.}{faq5}
+\item
+ \ilink{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?}{faq6}
+\item
+ \ilink{Is there an easier way than sorting out all these command line options?}{faq7}
+\item
+ \ilink{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?}{faq8}
+\item
+ \ilink{There are a lot of rpm packages. Which packages do I need for what?}{faq9}
\end{enumerate}
-\subsection*{Answers}
+\section{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), 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 dependancy 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:
+ 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
\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
+ OR
+ %define mysql5 0
\end{verbatim}
\normalsize
\footnotesize
\begin{verbatim}
%define mysql 1
+ OR
+ %define mysql4 1
+ OR
+ %define mysql5 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
+ rpmbuild -ba --define "build_rh7 1" --define "build_mysql5 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.
+ 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.
\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 it's
-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 suppress 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 dependancy 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 dependancies, 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.
+
+\item
+ \label{faq6}
+ {\bf 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.
+
+\item
+ \label{faq7}
+ {\bf 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.
+
+\item
+ \label{faq8}
+ {\bf 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:
+
+\footnotesize
+\begin{verbatim}
+ chown bacula.bacula /var/bacula/*
+ chown root.bacula /var/bacula/bacula-fd.9102.state
+ chown bacula.disk /var/bacula/bacula-sd.9103.state
+
+\end{verbatim}
+\normalsize
+
+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.
+
+\item
+ \label{faq9}
+ {\bf 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.
+
+
+
+\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.
\end{enumerate}
+
+\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
+
+\section{Build Options}
+\index[general]{Build Options}
+The spec file currently supports building on the following platforms:
+\footnotesize
+\begin{verbatim}
+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"
+
+Whitebox Enterprise build
+--define "build_wb3 1"
+
+Red Hat Enterprise builds
+--define "build_rhel3 1"
+--define "build_rhel4 1"
+
+CentOS build
+--define "build_centos3 1"
+--define "build_centos4 1"
+
+Scientific Linux build
+--define "build_sl3 1"
+--define "build_sl4 1"
+
+SuSE build
+--define "build_su9 1"
+--define "build_su10 1"
+--define "build_su102 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 bgnome-console:
+--define "nobuild_gconsole 1"
+
+Build the WXWindows console:
+requires wxGTK >= 2.6
+--define "build_wxconsole 1"
+
+Build the Bacula Administration Tool:
+requires QT >= 4
+--define "build_bat 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>"
+
+\end{verbatim}
+\normalsize
+
+\section{RPM Install Problems}
+\index[general]{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:
+\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}
+ Note: as of 1.38.8 /var/bacula is installed root:bacula with
+ permissions 770.
+\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