git.sur5r.net Git - bacula/docs/blob - docs/manuals/en/problems/rpm-faq.tex

   1 %%
   2 %%
   3
   4 \chapter{Bacula RPM Packaging FAQ}
   5 \label{RpmFaqChapter}
   6 \index[general]{FAQ!Bacula\textsuperscript{\textregistered} - RPM Packaging }
   7 \index[general]{Bacula\textsuperscript{\textregistered} - RPM Packaging FAQ }
   8
   9 \begin{enumerate}
  10 \item
  11    \ilink{How do I build Bacula for platform xxx?}{faq1}
  12 \item
  13    \ilink{How do I control which database support gets built?}{faq2}
  14
  15 \item
  16    \ilink{What other defines are used?}{faq3}
  17 \item
  18    \ilink{I'm getting errors about not having permission when I try to build the packages. Do I need to be root?}{faq4}
  19 \item
  20    \ilink{I'm building my own rpms but on all platforms and compiles I get an unresolved dependency for something called /usr/afsws/bin/pagsh.}{faq5}
  21 \item
  22    \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}
  23 \item
  24    \ilink{Is there an easier way than sorting out all these command line options?}{faq7}
  25 \item
  26    \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}
  27 \item
  28    \ilink{There are a lot of rpm packages. Which packages do I need for what?}{faq9}
  29 \end{enumerate}
  30
  31 \section{Answers}
  32 \index[general]{Answers }
  33
  34 \begin{enumerate}
  35 \item
  36    \label{faq1}
  37    {\bf How do I build Bacula for platform xxx?}
  38    The bacula spec file contains defines to build for several platforms:
  39    Red Hat 7.x (rh7), Red Hat 8.0 (rh8), Red Hat 9 (rh9), Fedora Core (fc1,
  40    fc3, fc4, fc5, fc6, fc7), Whitebox Enterprise Linux 3.0 (wb3), Red Hat Enterprise Linux
  41    (rhel3, rhel4, rhel5), Mandrake 10.x (mdk), Mandriva 2006.x (mdv) CentOS (centos3, centos4, centos5)
  42    Scientific Linux (sl3, sl4, sl5) and SuSE (su9, su10, su102, su103). 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
  43    as any special configure options required.  The platform define may be edited
  44    in the spec file directly (by default all defines are set to 0 or "not set").
  45    For example, to build the Red Hat 7.x package find the line in the spec file
  46    which reads
  47
  48 \footnotesize
  49 \begin{verbatim}
  50         %define rh7 0
  51
  52 \end{verbatim}
  53 \normalsize
  54
  55 and edit it to read
  56
  57 \footnotesize
  58 \begin{verbatim}
  59         %define rh7 1
  60
  61 \end{verbatim}
  62 \normalsize
  63
  64 Alternately you may pass the define on the command line when calling rpmbuild:
  65
  66
  67 \footnotesize
  68 \begin{verbatim}
  69         rpmbuild -ba --define "build_rh7 1" bacula.spec
  70         rpmbuild --rebuild --define build_rh7 1" bacula-x.x.x-x.src.rpm
  71
  72 \end{verbatim}
  73 \normalsize
  74
  75 \item
  76    \label{faq2}
  77    {\bf How do I control which database support gets built?}
  78    Another mandatory build define controls which database support is compiled,
  79    one of  build\_sqlite, build\_mysql or build\_postgresql. To get the MySQL
  80    package and support either  set the
  81
  82 \footnotesize
  83 \begin{verbatim}
  84         %define mysql 0
  85         OR
  86         %define mysql4 0
  87         OR
  88         %define mysql5 0
  89
  90 \end{verbatim}
  91 \normalsize
  92
  93 to
  94
  95 \footnotesize
  96 \begin{verbatim}
  97         %define mysql 1
  98         OR
  99         %define mysql4 1
 100         OR
 101         %define mysql5 1
 102
 103 \end{verbatim}
 104 \normalsize
 105
 106 in the spec file directly or pass it to rpmbuild on the command line:
 107
 108 \footnotesize
 109 \begin{verbatim}
 110         rpmbuild -ba --define "build_rh7 1" --define "build_mysql 1" bacula.spec
 111         rpmbuild -ba --define "build_rh7 1" --define "build_mysql4 1" bacula.spec
 112         rpmbuild -ba --define "build_rh7 1" --define "build_mysql5 1" bacula.spec
 113
 114 \end{verbatim}
 115 \normalsize
 116
 117 \item
 118    \label{faq3}
 119    {\bf What other defines are used?}
 120    Three other building defines of note are the depkgs\_version, docs\_version and
 121    \_rescuever identifiers. These  two defines are set with each release and must
 122    match the version of those sources that are being used to build the packages.
 123    You would not ordinarily need to edit these.  See also the Build Options section
 124    below for other build time options that can be passed on the command line.
 125 \item
 126    \label{faq4}
 127    {\bf I'm getting errors about not having permission when I try  to build the
 128    packages. Do I need to be root?}
 129    No, you do not need to be root and, in fact, it is better practice to
 130    build rpm packages as a non-root user.  Bacula packages are designed to
 131    be built by a regular user but you must make a few changes on your
 132    system to do this.  If you are building on your own system then the
 133    simplest method is to add write permissions for all to the build
 134    directory (/usr/src/redhat/, /usr/src/RPM or /usr/src/packages).
 135    To accomplish this, execute the following command as root:
 136
 137 \footnotesize
 138 \begin{verbatim}
 139         chmod -R 777 /usr/src/redhat
 140         chmod -R 777 /usr/src/RPM
 141         chmod -R 777 /usr/src/packages
 142
 143 \end{verbatim}
 144 \normalsize
 145
 146 If you are working on a shared system where you can not use the method
 147 above then you need to recreate the appropriate above directory tree with all
 148 of its subdirectories inside your home directory.  Then create a file named
 149
 150 {\tt .rpmmacros}
 151
 152 in your home directory (or edit  the file if it already exists)
 153 and add the following line:
 154
 155 \footnotesize
 156 \begin{verbatim}
 157         %_topdir /home/myuser/redhat
 158         %_tmppath /tmp
 159
 160 \end{verbatim}
 161 \normalsize
 162
 163 Another handy directive for the .rpmmacros file if you wish to suppress the
 164 creation of debug rpm packages is:
 165
 166 \footnotesize
 167 \begin{verbatim}
 168         %debug_package %{nil}
 169
 170 \end{verbatim}
 171
 172 \normalsize
 173
 174 \item
 175    \label{faq5}
 176    {\bf I'm building my own rpms but on all platforms and compiles I get an
 177    unresolved dependency for something called /usr/afsws/bin/pagsh.} This
 178    is a shell from the OpenAFS (Andrew File System).  If you are seeing
 179    this then you chose to include the docs/examples directory in your
 180    package.  One of the example scripts in this directory is a pagsh
 181    script.  Rpmbuild, when scanning for dependencies, looks at the shebang
 182    line of all packaged scripts in addition to checking shared libraries.
 183    To avoid this do not package the examples directory. If you are seeing this
 184    problem you are building a very old bacula package as the examples have been
 185    removed from the doc packaging.
 186
 187 \item
 188    \label{faq6}
 189    {\bf I'm building my own rpms because you don't publish for my platform.
 190     Can I get my packages released to sourceforge for other people to use?} Yes,
 191     contributions from users are accepted and appreciated. Please examine the
 192     directory platforms/contrib-rpm in the source code for further information.
 193
 194 \item
 195    \label{faq7}
 196    {\bf Is there an easier way than sorting out all these command line options?} Yes,
 197     there is a gui wizard shell script which you can use to rebuild the src rpm package.
 198    Look in the source archive for platforms/contrib-rpm/rpm\_wizard.sh. This script will
 199    allow you to specify build options using GNOME dialog screens. It requires zenity.
 200
 201 \item
 202    \label{faq8}
 203    {\bf I just upgraded from 1.36.x to 1.38.x and now my director daemon
 204 won't start.  It appears to start but dies silently and I get a "connection
 205 refused" error when starting the console.  What is wrong?} Beginning with
 206 1.38 the rpm packages are configured to run the director and storage
 207 daemons as a non-root user.  The file daemon runs as user root and group
 208 bacula, the storage daemon as user bacula and group disk, and the director
 209 as user bacula and group bacula.  If you are upgrading you will need to
 210 change some file permissions for things to work.  Execute the following
 211 commands as root:
 212
 213 \footnotesize
 214 \begin{verbatim}
 215         chown bacula.bacula /var/bacula/*
 216         chown root.bacula /var/bacula/bacula-fd.9102.state
 217         chown bacula.disk /var/bacula/bacula-sd.9103.state
 218
 219 \end{verbatim}
 220 \normalsize
 221
 222 Further, if you are using File storage volumes rather than tapes those
 223 files will also need to have ownership set to user bacula and group bacula.
 224
 225 \item
 226    \label{faq9}
 227    {\bf There are a lot of rpm packages.  Which packages do I need for
 228 what?} For a bacula server you need to select the packsge based upon your
 229 preferred catalog database: one of bacula-mysql, bacula-postgresql or
 230 bacula-sqlite.  If your system does not provide an mtx package you also
 231 need bacula-mtx to satisfy that dependancy.  For a client machine you need
 232 only install bacula-client.  Optionally, for either server or client
 233 machines, you may install a graphical console bacula-gconsole and/or
 234 bacula-wxconsole. The Bacula Administration Tool is installed with the
 235 bacula-bat package.  One last package, bacula-updatedb is required only when
 236 upgrading a server more than one database revision level.
 237
 238
 239
 240 \item {\bf Support for RHEL3/4/5, CentOS 3/4/5, Scientific Linux 3/4/5 and x86\_64}
 241    The examples below show
 242    explicit build support for RHEL4 and CentOS 4. Build support
 243    for x86\_64 has also been added.
 244 \end{enumerate}
 245
 246 \footnotesize
 247 \begin{verbatim}
 248 Build with one of these 3 commands:
 249
 250 rpmbuild --rebuild \
 251         --define "build_rhel4 1" \
 252         --define "build_sqlite 1" \
 253         bacula-1.38.3-1.src.rpm
 254
 255 rpmbuild --rebuild \
 256         --define "build_rhel4 1" \
 257         --define "build_postgresql 1" \
 258         bacula-1.38.3-1.src.rpm
 259
 260 rpmbuild --rebuild \
 261         --define "build_rhel4 1" \
 262         --define "build_mysql4 1" \
 263         bacula-1.38.3-1.src.rpm
 264
 265 For CentOS substitute '--define "build_centos4 1"' in place of rhel4.
 266 For Scientific Linux substitute '--define "build_sl4 1"' in place of rhel4.
 267
 268 For 64 bit support add '--define "build_x86_64 1"'
 269 \end{verbatim}
 270 \normalsize
 271
 272 \section{Build Options}
 273 \index[general]{Build Options}
 274 The spec file currently supports building on the following platforms:
 275 \footnotesize
 276 \begin{verbatim}
 277 Red Hat builds
 278 --define "build_rh7 1"
 279 --define "build_rh8 1"
 280 --define "build_rh9 1"
 281
 282 Fedora Core build
 283 --define "build_fc1 1"
 284 --define "build_fc3 1"
 285 --define "build_fc4 1"
 286 --define "build_fc5 1"
 287 --define "build_fc6 1"
 288 --define "build_fc7 1"
 289
 290 Whitebox Enterprise build
 291 --define "build_wb3 1"
 292
 293 Red Hat Enterprise builds
 294 --define "build_rhel3 1"
 295 --define "build_rhel4 1"
 296 --define "build_rhel5 1"
 297
 298 CentOS build
 299 --define "build_centos3 1"
 300 --define "build_centos4 1"
 301 --define "build_centos5 1"
 302
 303 Scientific Linux build
 304 --define "build_sl3 1"
 305 --define "build_sl4 1"
 306 --define "build_sl5 1"
 307
 308 SuSE build
 309 --define "build_su9 1"
 310 --define "build_su10 1"
 311 --define "build_su102 1"
 312 --define "build_su103 1"
 313
 314 Mandrake 10.x build
 315 --define "build_mdk 1"
 316
 317 Mandriva build
 318 --define "build_mdv 1"
 319
 320 MySQL support:
 321 for mysql 3.23.x support define this
 322 --define "build_mysql 1"
 323 if using mysql 4.x define this,
 324 currently: Mandrake 10.x, Mandriva 2006.0, SuSE 9.x & 10.0, FC4 & RHEL4
 325 --define "build_mysql4 1"
 326 if using mysql 5.x define this,
 327 currently: SuSE 10.1 & FC5
 328 --define "build_mysql5 1"
 329
 330 PostgreSQL support:
 331 --define "build_postgresql 1"
 332
 333 Sqlite support:
 334 --define "build_sqlite 1"
 335
 336 Build the client rpm only in place of one of the above database full builds:
 337 --define "build_client_only 1"
 338
 339 X86-64 support:
 340 --define "build_x86_64 1"
 341
 342 Supress build of bgnome-console:
 343 --define "nobuild_gconsole 1"
 344
 345 Build the WXWindows console:
 346 requires wxGTK >= 2.6
 347 --define "build_wxconsole 1"
 348
 349 Build the Bacula Administration Tool:
 350 requires QT >= 4.2
 351 --define "build_bat 1"
 352
 353 Build python scripting support:
 354 --define "build_python 1"
 355
 356 Modify the Packager tag for third party packages:
 357 --define "contrib_packager Your Name <youremail@site.org>"
 358
 359 \end{verbatim}
 360 \normalsize
 361
 362 \section{RPM Install Problems}
 363 \index[general]{RPM Install Problems}
 364 In general the RPMs, once properly built should install correctly.
 365 However, when attempting to run the daemons, a number of problems
 366 can occur:
 367 \begin{itemize}
 368 \item [Wrong /var/bacula Permissions]
 369   By default, the Director and Storage daemon do not run with
 370   root permission. If the /var/bacula is owned by root, then it
 371   is possible that the Director and the Storage daemon will not
 372   be able to access this directory, which is used as the Working
 373   Directory. To fix this, the easiest thing to do is:
 374 \begin{verbatim}
 375   chown bacula:bacula /var/bacula
 376 \end{verbatim}
 377   Note: as of 1.38.8 /var/bacula is installed root:bacula with
 378   permissions 770.
 379 \item [The Storage daemon cannot Access the Tape drive]
 380   This can happen in some older RPM releases where the Storage
 381   daemon ran under userid bacula, group bacula.  There are two
 382   ways of fixing this: the best is to modify the /etc/init.d/bacula-sd
 383   file so that it starts the Storage daemon with group "disk".
 384   The second way to fix the problem is to change the permissions
 385   of your tape drive (usually /dev/nst0) so that Bacula can access it.
 386   You will probably need to change the permissions of the SCSI control
 387   device as well, which is usually /dev/sg0.  The exact names depend
 388   on your configuration, please see the Tape Testing chapter for
 389   more information on devices.
 390 \end{itemize}
 391