Although the exact composition of the dependency packages may change from time
to time, the current makeup is the following:
-\addcontentsline{lot}{table}{Depedency Packages}
+\addcontentsline{lot}{table}{Dependency Packages}
\begin{longtable}{|l|l|l|l|}
\hline
\multicolumn{1}{|c| }{\bf 3rd Party Package } & \multicolumn{1}{c| }{\bf
so that you are sure to start from scratch and not have a mixture of the two
options. This is because ./configure caches much of the information. The {\bf
-make distclean} is also critical if you move the source dirctory from one
+make distclean} is also critical if you move the source directory from one
machine to another. If the {\bf make distclean} fails, just ignore it and
continue on.
\item make
heavy modifications to the configuration files so that you are sure that
Bacula works and are familiar with it. After that changing the conf files
will be easier.
-\item If after installing Bacula, you decide to ``move it'', that is to
+\item If after installing Bacula, you decide to "move it", that is to
install it in a different set of directories, proceed as follows:
\footnotesize
If you install Bacula on more than one system, and they are identical, you can
-simply transfer the source tree to that other system and do a ``make
-install''. However, if there are differences in the libraries or OS versions,
+simply transfer the source tree to that other system and do a "make
+install". However, if there are differences in the libraries or OS versions,
or you wish to install on a different OS, you should start from the original
compress tar file. If you do transfer the source tree, and you have previously
done a ./configure command, you MUST do:
prior to doing your new ./configure. This is because the GNU autoconf tools
cache the configuration, and if you re-use a configuration for a Linux machine
on a Solaris, you can be sure your build will fail. To avoid this, as
-mentioned above, either start from the tar file, or do a ``make distclean''.
+mentioned above, either start from the tar file, or do a "make distclean".
In general, you will probably want to supply a more complicated {\bf
configure} statement to ensure that the modules you want are built and that
\index[general]{{-}{-}with-dir-user }
This option allows you to specify the Userid used to run the Director. The
Director must be started as root, but doesn't need to run as root, and after
- doing preliminary initializations, it can ``drop'' to the UserId specified on
+ doing preliminary initializations, it can "drop" to the UserId specified on
this option.
\item [ {-}{-}with-dir-group=\lt{}Group\gt{} ]
\index[general]{{-}{-}with-dir-group }
This option allows you to specify the GroupId used to run the Director. The
Director must be started as root, but doesn't need to run as root, and after
- doing preliminary initializations, it can ``drop'' to the GroupId specified
+ doing preliminary initializations, it can "drop" to the GroupId specified
on this option.
\item [ {-}{-}with-sd-user=\lt{}User\gt{} ]
\index[general]{{-}{-}with-sd-user }
This option allows you to specify the Userid used to run the Storage daemon.
The Storage daemon must be started as root, but doesn't need to run as root,
- and after doing preliminary initializations, it can ``drop'' to the UserId
+ and after doing preliminary initializations, it can "drop" to the UserId
specified on this option. If you use this option, you will need to take care
that the Storage daemon has access to all the devices (tape drives, ...) that
it needs.
\index[general]{{-}{-}with-sd-group }
This option allows you to specify the GroupId used to run the Storage daemon.
The Storage daemon must be started as root, but doesn't need to run as root,
- and after doing preliminary initializations, it can ``drop'' to the GroupId
+ and after doing preliminary initializations, it can "drop" to the GroupId
specified on this option.
\item [ {-}{-}with-fd-user=\lt{}User\gt{} ]
This option allows you to specify the Userid used to run the File daemon. The
File daemon must be started as root, and in most cases, it needs to run as
root, so this option is used only in very special cases, after doing
- preliminary initializations, it can ``drop'' to the UserId specified on this
+ preliminary initializations, it can "drop" to the UserId specified on this
option.
\item [ {-}{-}with-fd-group=\lt{}Group\gt{} ]
\index[general]{{-}{-}with-fd-group }
This option allows you to specify the GroupId used to run the File daemon.
The File daemon must be started as root, and in most cases, it must be run as
- root, however, after doing preliminary initializations, it can ``drop'' to
+ root, however, after doing preliminary initializations, it can "drop" to
the GroupId specified on this option.
\end{description}
If you want to install Bacula in an installation directory rather than run it
out of the build directory (as developers will do most of the time), you
should also include the \verb:--:sbindir and \verb:--:sysconfdir options with appropriate
-paths. Neither are necessary if you do not use ``make install'' as is the case
+paths. Neither are necessary if you do not use "make install" as is the case
for most development work. The install process will create the sbindir and
sysconfdir if they do not exist, but it will not automatically create the
pid-dir, subsys-dir, or working-dir, so you must ensure that they exist before
\index[general]{Kern's Configure Script }
\addcontentsline{toc}{subsection}{Kern's Configure Script}
-The script that I use for building on my ``production'' Linux machines is:
+The script that I use for building on my "production" Linux machines is:
\footnotesize
\begin{verbatim}
\normalsize
If you have previously installed Bacula, the old binaries will be overwritten,
-but the old configuration files will remain unchanged, and the ``new''
+but the old configuration files will remain unchanged, and the "new"
configuration files will be appended with a {\bf .new}. Generally if you have
previously installed and run Bacula you will want to discard or ignore the
configuration files with the appended {\bf .new}.