]> git.sur5r.net Git - bacula/docs/blobdiff - docs/manuals/en/utility/rpm-faq.tex
Update for version 5.0.1
[bacula/docs] / docs / manuals / en / utility / rpm-faq.tex
index e880efc4207982565be26c259b41025cbf877707..36dbb88be378a8aa36a16f8025b2a41a437f0f92 100644 (file)
@@ -30,6 +30,8 @@
    \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}  
+\item 
+   \ilink{What happened to the build switches for gnome console, wxconsole and bat?}{faq10}  
 \end{enumerate}
 
 \section{Answers}
 \item 
    \label{faq1}
    {\bf 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), 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). 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 
+   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
@@ -86,10 +95,6 @@ Alternately you may pass the define on the command line when calling rpmbuild:
 \footnotesize
 \begin{verbatim}
         %define mysql 0
-        OR
-        %define mysql4 0
-        OR
-        %define mysql5 0
         
 \end{verbatim}
 \normalsize
@@ -99,10 +104,6 @@ to
 \footnotesize
 \begin{verbatim}
         %define mysql 1
-        OR
-        %define mysql4 1
-        OR
-        %define mysql5 1
         
 \end{verbatim}
 \normalsize
@@ -112,24 +113,21 @@ 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
-        rpmbuild -ba --define "build_rh7 1" --define "build_mysql5 1" bacula.spec
         
 \end{verbatim}
 \normalsize
 
 \item 
    \label{faq3}
-   {\bf 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 
+   {\bf What other defines are used?} \\
+   One other building define of note is the 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{faq4}
    {\bf I'm getting errors about not having permission when I try  to build the
-   packages. Do I need to be 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
@@ -164,6 +162,9 @@ and add the following line:
 \end{verbatim}
 \normalsize
 
+It should be noted that Fedora from verion 10 and up is configured to build in
+the directory ~/rpmbuild.
+
 Another handy directive for the .rpmmacros file if you wish to suppress the
 creation of debug rpm packages is:
 
@@ -178,41 +179,45 @@ creation of debug rpm packages is:
 \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
+   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.
+   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.
+    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.
+   {\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:
+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}
@@ -229,7 +234,8 @@ 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
+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
@@ -239,9 +245,19 @@ 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 
+   \label{faq10}
+The gnome console and wxconsole software is deprecated in favor of bat. The 
+bat (bacula administrative tool) is now packaged in it's own source 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 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 {\bf 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 x86\_64 has also been added. 
@@ -292,6 +308,7 @@ Fedora Core build
 --define "build_fc7 1"
 --define "build_fc8 1"
 --define "build_fc9 1"
+--define "build_fc10 1"
 
 Whitebox Enterprise build
 --define "build_wb3 1"
@@ -318,6 +335,7 @@ SuSE build
 --define "build_su103 1"
 --define "build_su110 1"
 --define "build_su111 1"
+--define "build_su112 1"
 
 Mandrake 10.x build
 --define "build_mdk 1"
@@ -326,14 +344,7 @@ 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"
@@ -347,29 +358,18 @@ Build the client rpm only in place of one of the above database full builds:
 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.2
---define "build_bat 1"
-
 Build python scripting support:
 --define "build_python 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"
 
-Build the rescue files:
---define "build_rescue 1"
-
 \end{verbatim}
 \normalsize
 
@@ -379,7 +379,7 @@ 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]
+\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
@@ -390,7 +390,7 @@ can occur:
 \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]
+\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