From f98e333a7abe244def8f4ee63943c9e187201eee Mon Sep 17 00:00:00 2001 From: Kern Sibbald Date: Thu, 22 Aug 2013 15:51:22 +0200 Subject: [PATCH] Rework Install chapter --- docs/manuals/en/main/catmaintenance.tex | 2 +- docs/manuals/en/main/main.tex | 2 +- docs/manuals/en/main/quickstart.tex | 113 ++++--- docs/manuals/en/main/win32.tex | 2 +- docs/manuals/en/{main => misc}/install.tex | 376 ++------------------- docs/manuals/en/misc/misc.tex | 5 +- 6 files changed, 82 insertions(+), 418 deletions(-) rename docs/manuals/en/{main => misc}/install.tex (78%) diff --git a/docs/manuals/en/main/catmaintenance.tex b/docs/manuals/en/main/catmaintenance.tex index e498684b..90bb3750 100644 --- a/docs/manuals/en/main/catmaintenance.tex +++ b/docs/manuals/en/main/catmaintenance.tex @@ -575,7 +575,7 @@ restore from backup tapes, one of your first priorities will probably be to recover the database. Although Bacula will happily backup your catalog database if it is specified in the FileSet, this is not a very good way to do it, because the database will be saved while Bacula is modifying it. Thus the -database may be in an instable state. Worse yet, you will backup the database +database may be in an unstable state. Worse yet, you will backup the database before all the Bacula updates have been applied. To resolve these problems, you need to backup the database after all the backup diff --git a/docs/manuals/en/main/main.tex b/docs/manuals/en/main/main.tex index e9d8b8da..376f49fc 100644 --- a/docs/manuals/en/main/main.tex +++ b/docs/manuals/en/main/main.tex @@ -84,7 +84,7 @@ lscape,pdfpages,ifthen,setspace,colortbl,diagbox} \include{supporteddrives} \include{quickstart} % install -\include{install} % install +\include{pkg-install} % install \include{critical} % install \include{tutorial} diff --git a/docs/manuals/en/main/quickstart.tex b/docs/manuals/en/main/quickstart.tex index 1dcbbc59..080842c5 100644 --- a/docs/manuals/en/main/quickstart.tex +++ b/docs/manuals/en/main/quickstart.tex @@ -99,25 +99,22 @@ subject later. \index[general]{Setting Up Bacula Configuration Files } \index[general]{Files!Setting Up Bacula Configuration } -% TODO: this assumes installation from source: -After running the appropriate {\bf ./configure} command and doing -a {\bf make}, and a {\bf make install}, if this is the first time -you are running Bacula, you must create valid configuration files -for the Director, the File daemon, the Storage daemon, and the -Console programs. If you have followed our recommendations, -default configuration files as well as the daemon binaries will -be located in your installation directory. In any case, the -binaries are found in the directory you specified on the {\bf -\lstinline:--:sbindir} option to the {\bf ./configure} command, and -the configuration files are found in the directory you specified -on the {\bf \lstinline:--:sysconfdir} option. +Normally, if you are using the Bacula Enterprise version, you +will install it from packages (.deb, .rpm, .pkg, .dmg, ...), +in which case, default configuration files will already be +setup in {\bf /opt/bacula/etc}. However, you will need to +reconfigure these files to correspond to your production +environment including adding definitions of additional +Client machines to be backed up. When initially setting up Bacula you will need to invest a bit of time in modifying the default configuration files to suit your environment. This may entail starting and stopping Bacula a number of times until you get everything -right. Please do not despair. Once you have created your configuration files, -you will rarely need to change them nor will you stop and start Bacula very -often. Most of the work will simply be in changing the tape when it is full. +right. Please do not despair. Once you have created your production +configuration files, you will rarely need to change them nor will you stop +and start Bacula very often. Most of the work will simply be in +monitoring that there is sufficient disk space or tapes available and that +no jobs are failing. \subsection{Configuring the Console Program} \index[general]{Configuring the Console Program } @@ -140,36 +137,6 @@ defaults are set. Further details are in the \ilink{Console configuration}{ConsoleConfChapter} chapter. -\subsection{Configuring the Monitor Program} -\index[general]{Program!Configuring the Monitor } -\index[general]{Configuring the Monitor Program } - -The Monitor program is typically an icon in the system tray. However, once the -icon is expanded into a full window, the administrator or user can obtain -status information about the Director or the backup status on the local -workstation or any other Bacula daemon that is configured. - -\bsysimageH{Bacula-tray-monitor}{Bacula Tray Monitor}{figstart:baculatray} - -% TODO: image may be too wide for 6" wide printed page. -The image shows a tray-monitor configured for three daemons. By clicking on -the radio buttons in the upper left corner of the image, you can see the -status for each of the daemons. The image shows the status for the Storage -daemon (MainSD) that is currently selected. - -The Monitor configuration file is found in the directory specified on the {\bf -\lstinline:--:sysconfdir} option that you specified on the {\bf ./configure} command -and -by default is named {\bf tray-monitor.conf}. Normally, for first time users, -you just need to change the permission of this file to allow non-root users to -run the Monitor, as this application must run as the same user as the -graphical environment (don't forget to allow non-root users to execute {\bf -bacula-tray-monitor}). This is not a security problem as long as you use the -default settings. - -More information is in the -\ilink{Monitor configuration}{_MonitorChapter} chapter. - \subsection{Configuring the File daemon} \index[general]{Daemon!Configuring the File } \index[general]{Configuring the File daemon } @@ -264,6 +231,36 @@ Volumes will be created as files when you label the Volume. Further information is in the \ilink{Storage daemon configuration}{StoredConfChapter} chapter. +\subsection{Configuring the Monitor Program} +\index[general]{Program!Configuring the Monitor } +\index[general]{Configuring the Monitor Program } + +The Monitor program is typically an icon in the system tray. However, once the +icon is expanded into a full window, the administrator or user can obtain +status information about the Director or the backup status on the local +workstation or any other Bacula daemon that is configured. + +\bsysimageH{Bacula-tray-monitor}{Bacula Tray Monitor}{figstart:baculatray} + +% TODO: image may be too wide for 6" wide printed page. +The image shows a tray-monitor configured for three daemons. By clicking on +the radio buttons in the upper left corner of the image, you can see the +status for each of the daemons. The image shows the status for the Storage +daemon (MainSD) that is currently selected. + +The Monitor configuration file is found in the directory specified on the {\bf +\lstinline:--:sysconfdir} option that you specified on the {\bf ./configure} command +and +by default is named {\bf tray-monitor.conf}. Normally, for first time users, +you just need to change the permission of this file to allow non-root users to +run the Monitor, as this application must run as the same user as the +graphical environment (don't forget to allow non-root users to execute {\bf +bacula-tray-monitor}). This is not a security problem as long as you use the +default settings. + +More information is in the +\ilink{Monitor configuration}{_MonitorChapter} chapter. + \section{Testing your Configuration Files} \index[general]{Testing your Configuration Files } \index[general]{Files!Testing your Configuration } @@ -322,6 +319,10 @@ compatibility of Bacula and your system. \label{notls} \section{Get Rid of the /lib/tls Directory} \index[general]{Directory!Get Rid of the /lib/tls } \index[general]{Get Rid of the /lib/tls Directory } +This section only applies to really old 2.4.x kernel version, +which we hope you are no longer running. + +\smallskip The new pthreads library {\bf /lib/tls} installed by default on recent Red Hat systems running Linux kernel 2.4.x is defective. You must remove it or rename it, then reboot your system before running Bacula otherwise after a @@ -351,12 +352,13 @@ you will get detailed instructions on how to run Bacula. \section{Log Rotation} \index[general]{Rotation!Log } \index[general]{Log Rotation } -If you use the default {\bf bacula-dir.conf} or some variation of it, you will -note that it logs all the Bacula output to a file. To avoid that this file -grows without limit, we recommend that you copy the file {\bf logrotate} from -the {\bf scripts/logrotate} to {\bf /etc/logrotate.d/bacula}. This will cause -the log file to be rotated once a month and kept for a maximum of five months. -You may want to edit this file to change the default log rotation preferences. +If you use the default {\bf bacula-dir.conf} or some variation of it, you +will note that it logs all the Bacula output to a file. To avoid that this +file grows without limit, we recommend that you copy the file {\bf +logrotate} from the {\bf scripts/logrotate} to {\bf +/etc/logrotate.d/bacula}. This will cause the log file to be rotated once +a month and kept for a maximum of five months. You may want to edit this +file to change the default log rotation preferences. \section{Log Watch} \index[general]{Watch!Log} @@ -368,15 +370,14 @@ jobs in that report, please look in the {\bf scripts/logwatch} directory. The {\bf README} file in that directory gives a brief explanation on how to install it and what kind of output to expect. - \section{Disaster Recovery} \index[general]{Recovery!Disaster } \index[general]{Disaster Recovery } -If you intend to use Bacula as a disaster recovery tool rather than simply a -program to restore lost or damaged files, you will want to read the -\ilink{Disaster Recovery Using Bacula Chapter}{RescueChapter} of -this manual. +If you intend to use Bacula as a disaster recovery tool rather than simply +a program to restore lost or damaged files, you will want to read the +\ilink{Disaster Recovery Using Bacula Chapter}{RescueChapter} of this +manual. In any case, you are strongly urged to carefully test restoring some files that you have saved rather than wait until disaster strikes. This way, you diff --git a/docs/manuals/en/main/win32.tex b/docs/manuals/en/main/win32.tex index 04a8f4bd..cc3c8691 100644 --- a/docs/manuals/en/main/win32.tex +++ b/docs/manuals/en/main/win32.tex @@ -6,7 +6,7 @@ \index[general]{Windows Version of Bacula} At the current time only the File daemon or Client program has -been thouroughly tested on Windows and is suitable for a +been thoroughly tested on Windows and is suitable for a production environment. As a consequence, when we speak of the Windows version of Bacula below, we are referring to the File daemon (client) only. diff --git a/docs/manuals/en/main/install.tex b/docs/manuals/en/misc/install.tex similarity index 78% rename from docs/manuals/en/main/install.tex rename to docs/manuals/en/misc/install.tex index a28fb0b8..8afb0db8 100644 --- a/docs/manuals/en/main/install.tex +++ b/docs/manuals/en/misc/install.tex @@ -1,10 +1,10 @@ %% %% -\chapter{Installing Bacula} +\chapter{Manually Installing Bacula} \label{InstallChapter} -\index[general]{Bacula!Installing} -\index[general]{Installing Bacula} +\index[general]{Bacula!Installing Manually} +\index[general]{Manually Installing Bacula} In general, you will need the Bacula source release, and if you want to run a Windows client, you will need the Bacula Windows binary release. @@ -22,28 +22,28 @@ them. \section{Source Release Files} \index[general]{Source Files} \index[general]{Release Files} - Beginning with Bacula 1.38.0, the source code has been broken into + The Bacula source code has been broken into four separate tar files each corresponding to a different module in the Bacula SVN. The released files are: \begin{description} -\item [bacula-5.0.0.tar.gz] +\item [bacula-5.2.0.tar.gz] This is the primary source code release for Bacula. On each - release the version number (5.0.0) will be updated. + release the version number (5.2.0) will be updated. -\item [bacula-docs-5.0.0.tar.bz2] +\item [bacula-docs-5.2.0.tar.bz2] This file contains a copy of the docs directory with the documents prebuild. English HTML directory, single HTML file, and pdf file. The French, German, Spanish translations are in progress, but are not built. -\item [bacula-gui-5.0.0.tar.gz] +\item [bacula-gui-5.2.0.tar.gz] This file contains the non-core GUI programs. Currently, it contains bacula-web, a PHP program for producing management viewing of your Bacula job status in a browser; and bimagemgr a browser program for burning CDROM images with Bacula Volumes. -\item [bacula-rescue-5.0.0.tar.gz] +\item [bacula-rescue-5.2.0.tar.gz] This is the Bacula Rescue USB key code. Note, the version number of this package is not always tied to the Bacula release version, so it may be different. Using this code, you can create a USB key @@ -52,7 +52,7 @@ them. repartition and reformat your hard disks and reload your system with Bacula in the case of a hard disk failure. -\item [win32bacula-5.0.0.exe] +\item [win32bacula-5.2.0.exe] This file is the 32 bit Windows installer for installing the Windows client (File daemon) on a Windows machine. This client will also run on 64 bit Windows machines, but @@ -61,7 +61,7 @@ them. the Director and Storage daemon are not included. -\item [win64bacula-5.0.0.exe] +\item [win64bacula-5.2.0.exe] This file is the 64 bit Windows installer for installing the Windows client (File daemon) on a Windows machine. This client will only run on 64 bit Windows OS machines. @@ -74,300 +74,6 @@ them. \end{description} -\section{Upgrading Bacula}\label{upgrading1} -\index[general]{Bacula!Upgrading} -\index[general]{Upgrading Bacula} -\index[general]{Upgrading} - -If you are upgrading from one Bacula version to another, you should first -carefully read the ReleaseNotes of all major versions between your current -version and the version to which you are upgrading. In many upgrades, -especially for minor patch upgrades (e.g. between 3.0.0 and 3.0.1) there -will be no database upgrade, and hence the process is rather simple. - -With version 3.0.0 and later, you {\bf must} ensure that on any one -machine that all components of Bacula are running on exactly the -same version. Prior to version 3.0.0, it was possible to run a -lower level FD with a newer Director and SD. This is no longer the -case. - -As always, we attempt to support older File daemons. This avoids the -need to do a simultaneous upgrade of many machines. For exactly what -older versions of the FD are supported, please see the ReleaseNotes -for the new version. In any case, you must always upgrade both the -Director and the Storage daemon at the same time, and you must also -upgrade any File daemon that is running on the same machine as a Director -or a Storage daemon (see the prior paragraph). - -If the Bacula catalog -database has been upgraded (as it is almost every major release), you will -either need to reinitialize your database starting from scratch (not -normally a good idea), or save an ASCII copy of your database, then proceed -to upgrade it. If you are upgrading two major versions (e.g. 1.36 to 2.0) -then life will be more complicated because you must do two database -upgrades. See below for more on this. - -Upgrading the catalog is normally done after Bacula is build and installed -by: - -\begin{lstlisting} -cd (default /etc/bacula) -./update_bacula_tables -\end{lstlisting} - -This update script can also be find in the Bacula source src/cats -directory. - -If there are several database upgrades between your version and the -version to which you are upgrading, you will need to apply each database -upgrade script. For your convenience, you can find all the old upgrade scripts -in the {\bf upgradedb} directory of the source code. You will need to edit the -scripts to correspond to your system configuration. The final upgrade script, -if any, can be applied as noted above. - -If you are upgrading from one major version to another, you will need to -replace all your components at the same time as generally the inter-daemon -protocol will change. However, within any particular release (e.g. version -1.32.x) unless there is an oversight or bug, the daemon protocol will not -change. If this is confusing, simply read the ReleaseNotes very carefully as -they will note if all daemons must be upgraded at the same time. - -Finally, please note that in general it is not necessary or desirable -to do a {\bf make uninstall} before doing an upgrade providing you are careful -not to change the installation directories. In fact, if you do so, you will -most likely delete all your conf files, which could be disastrous. -The normal procedure during an upgrade is simply: - -\begin{lstlisting} -./configure (your options) -make -make install -\end{lstlisting} - -In general none of your existing .conf or .sql files will be overwritten, -and you must do both the {\bf make} and {\bf make install} commands, a -{\bf make install} without the preceding {\bf make} will not work. - -For additional information on upgrading, please see the \bsysxrlink{Upgrading Bacula Versions}{upgrading}{problems}{section} of the \problemsman{}. - -\section{Releases Numbering} -\index[general]{Release Numbering} -\index[general]{Version Numbering} -Every Bacula release whether beta or production has a different number -as well as the date of the release build. The numbering system follows -traditional Open Source conventions in that it is of the form. - -\begin{lstlisting} -major.minor.release -\end{lstlisting} - -For example: -\begin{lstlisting} -1.38.11 -\end{lstlisting} - -where each component (major, minor, patch) is a number. -The major number is currently 1 and normally does not change -very frequently. The minor number starts at 0 and increases -each for each production release by 2 (i.e. it is always an -even number for a production release), and the patch number is -starts at zero each time the minor number changes. The patch -number is increased each time a bug fix (or fixes) is released -to production. - -So, as of this date (10 September 2006), the current production Bacula -release is version 1.38.11. If there are bug fixes, the next release -will be 1.38.12 (i.e. the patch number has increased by one). - -For all patch releases where the minor version number does not change, -the database and all the daemons will be compatible. That means that -you can safely run a 1.38.0 Director with a 1.38.11 Client. Of course, -in this case, the Director may have bugs that are not fixed. Generally, -within a minor release (some minor releases are not so minor), all -patch numbers are officially released to production. This means that while -the current Bacula version is 1.38.11, versions 1.38.0, 1.38.1, ... 1.38.10 -have all been previously released. - -When the minor number is odd, it indicates that the package is under -development and thus may not be stable. For example, while the current -production release of Bacula is currently 1.38.11, the current development -version is 1.39.22. All patch versions of the development code are -available in the SVN (source repository). However, not all patch versions -of the development code (odd minor version) are officially released. When -they are released, they are released as beta versions (see below for a -definition of what beta means for Bacula releases). - -In general when the minor number increases from one production release -to the next (i.e. 1.38.x to 1.40.0), the catalog database must be upgraded, -the Director and Storage daemon must always be on the same minor release -number, and often (not always), the Clients must also be on the same minor -release. As often as possible, we attempt to make new releases that are -downwards compatible with prior clients, but this is not always possible. -You must check the release notes. In general, you will have fewer problems -if you always run all the components on the same minor version number (i.e. -all either 1.38.x or 1.40.x but not mixed). - - -\label{BetaReleases} -\section*{Beta Releases} -\index[general]{Beta Releases} -Towards the end of the development cycle, which typically runs -one year from a major release to another, there will be several beta -releases of the development code prior to a production release. -As noted above, beta versions always have odd minor version numbers -(e.g 1.37.x or 1.39.x). -The purpose of the beta releases is to allow early adopter users to test -the new code. Beta releases are made with the following considerations: - -\begin{bsysitemize} -\item The code passes the regression testing on FreeBSD, Linux, and Solaris - machines. - -\item There are no known major bugs, or on the rare occasion that - there are, they will be documented or already in the bugs database. - -\item Some of the new code/features may not yet be tested. - -\item Bugs are expected to be found, especially in the new - code before the final production release. - -\item The code will have been run in production in at least one small - site (mine). - -\item The Win32 client will have been run in production at least - one night at that small site. - -\item The documentation in the manual is unlikely to be complete especially - for the new features, and the Release Notes may not be fully - organized. - -\item Beta code is not generally recommended for everyone, but - rather for early adopters. -\end{bsysitemize} - - -\label{Dependency} -\section{Dependency Packages} -\index[general]{Dependency Packages} -\index[general]{Packages!Dependency} - -As discussed above, we have combined a number of third party packages that -Bacula might need into the {\bf depkgs} release. You can, -of course, get the latest packages from the original authors or -from your operating system supplier. The locations of -where we obtained the packages are in the README file in each package. -However, be aware that the packages in the depkgs files have been tested by us -for compatibility with Bacula. - -Typically, a dependency package will be named {\bf depkgs-ddMMMyy.tar.gz} -where {\bf dd} is the day we release it, {\bf MMM} -is the abbreviated month (e.g. Jan), and {\bf yy} is the year. An actual -example is: {\bf depkgs-18Dec.tar.gz}. To install and build this package (if -needed), you do the following: - -\begin{enumerate} -\item Create a {\bf bacula} directory, into which you will place both the - Bacula source as well as the dependency package. -\item Detar the {\bf depkgs} into the {\bf bacula} directory. -\item cd bacula/depkgs -\item make -\end{enumerate} - -Although the exact composition of the dependency packages may change from time -to time, the current makeup is the following: - -\LTXtable{0.95\linewidth}{table_dependencies} -Note, some of these packages are quite large, so that building them can be a -bit time consuming. The above instructions will build all the packages -contained in the directory. However, when building Bacula, it will take only -those pieces that it actually needs. - -Alternatively, you can make just the packages that are needed. For example, - -\footnotesize -\begin{lstlisting} -cd bacula/depkgs -make sqlite -\end{lstlisting} -\normalsize - -will configure and build only the SQLite package. - -You should build the packages that you will require in {\bf depkgs} a -prior to configuring and building Bacula, since Bacula will need -them during the build process. - -Note, the {\bf depkgs-qt} package is required for building bat, because -bat is currently built with Qt version 4.3.4. It can be built with other -Qt versions, but that almost always creates problems or introduces -instabilities. - -You can build the depkgs-qt with the following: - -\footnotesize -\begin{lstlisting} -cd bacula -tar xfvz depkgs-qt-28Jul09.tar.gz -cd depkgs-qt -make qt4 -source qt4-path -\end{lstlisting} -\normalsize - -Doing the {\bf source qt4-path} defines the following environment -variables: - -\footnotesize -\begin{lstlisting} -QTDIR -QTLIB -QTINC -\end{lstlisting} -\normalsize - -Each one should point to a specific location in the depkgs-qt package -that you loaded. It also puts the depkgs-qt/qt4/bin directory -on your path before all other directories. This ensures that -the bat build will use your Qt 4.3.4 library rather than any that -might be on your system. - -Before running your Bacula build, please make sure that -{\bf qmake-qt4} is not on your path. If it is please rename it. If -you don't do this, Bacula will attempt to build with any Qt4 package -installed on your system rather than the one you just built. -If you logoff and log back in, you must re-source the depkgs-qt/qt4-patch -file before attempting to rebuild the bat part of Bacula. - -For more information on the {\bf depkgs-qt} package, please read the -INSTALL file in the main directory of that package. If you are going to -build Qt4 using {\bf depkgs-qt}, you must source the {\bf qt4-paths} file -included in the package prior to building Bacula. Please read the INSTALL -file for more details. - -Even if you do not use SQLite, you might find it worthwhile to build {\bf mtx} -because the {\bf tapeinfo} program that comes with it can often provide you -with valuable information about your SCSI tape drive (e.g. compression, -min/max block sizes, ...). Note, most distros provide {\bf mtx} as part of -their release. - -The {\bf depkgs1} package is depreciated and previously contained -readline, which should be available on all operating systems. - -The {\bf depkgs-win32} package is deprecated and no longer used in -Bacula version 1.39.x and later. It was previously used to build -the native Win32 client program, but this program is now built on Linux -systems using cross-compiling. All the tools and third party libraries -are automatically downloaded by executing the appropriate scripts. See -src/win32/README.mingw32 for more details. - -\section{Supported Operating Systems} -\label{Systems} -\index[general]{Systems!Supported Operating} -\index[general]{Supported Operating Systems} - -Please see the -\ilink{ Supported Operating Systems}{SupportedOSes} section -of the QuickStart chapter of this manual. \section{Building Bacula from Source} \label{Building} @@ -610,50 +316,6 @@ readline seems to be incompatible with previous versions, and that there are significant differences between systems, we can no longer afford to support it. -\section{What Database to Use?} -\label{DB} -\index[general]{What Database to Use?} -\index[general]{Use!What Database to} - -Before building Bacula you need to decide if you want to use SQLite, MySQL, or -PostgreSQL. If you are not already running MySQL or PostgreSQL, you might -want to start by testing with SQLite (not supported on Solaris). -This will greatly simplify the setup for you -because SQLite is compiled into Bacula an requires no administration. It -performs well and is suitable for small to medium sized installations (maximum -10-20 machines). However, we should note that a number of users have -had unexplained database corruption with SQLite. For that reason, we -recommend that you install either PostgreSQL or MySQL for production -work. - -If you wish to use MySQL as the Bacula catalog, please see the -\ilink{Installing and Configuring MySQL}{MySqlChapter} chapter of this -manual. You will need to install MySQL prior to continuing with the -configuration of Bacula. MySQL is a high quality database that is very -efficient and is suitable for small and medium sized installation (up to -2,000,000 files per job). It is slightly more complicated than SQLite to setup -and administer because it has a number of sophisticated features such as -userids and passwords. It runs as a separate process, is truly professional and -can manage a database of any size. - -If you wish to use PostgreSQL as the Bacula catalog, please see the -\ilink{Installing and Configuring PostgreSQL}{PostgreSqlChapter} chapter of -this manual. You will need to install PostgreSQL prior to continuing with the -configuration of Bacula. PostgreSQL is very similar to MySQL, though it tends -to be slightly more SQL92 compliant and has many more advanced features such as -transactions, stored procedures, and the such. It requires a certain knowledge -to install and maintain. PostgreSQL is suitable for any sized installation -(some sites have much more than 1 billion objects in the Catalog). Bacula uses -many optimized PostgreSQL functions, and can run more than 10 time faster on -jobs having millions of files than MySQL (Specially in during restore, accurate -mode, bvfs queries and when the database server is not on the same host than -the Director). It's possible to switch from MySQL/SQLite to PostgreSQL, but it -requires some DBA knowledge. - -If you wish to use SQLite as the Bacula catalog, please see -\ilink{Installing and Configuring SQLite}{SqlLiteChapter} chapter of -this manual. SQLite is not supported on Solaris. - \section{Quick Start} \index[general]{Quick Start} \index[general]{Start!Quick} @@ -1267,14 +929,14 @@ For most systems, we recommend starting with the following options: \end{lstlisting} \normalsize -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 \lstinline:--:sbindir and \lstinline:--:sysconfdir options with appropriate -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 -running Bacula for the first time. +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 \lstinline:--:sbindir and \lstinline:--:sysconfdir +options with appropriate 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 running Bacula for the first time. \section{Red Hat} \index[general]{Red Hat} diff --git a/docs/manuals/en/misc/misc.tex b/docs/manuals/en/misc/misc.tex index 670b7591..98bff275 100644 --- a/docs/manuals/en/misc/misc.tex +++ b/docs/manuals/en/misc/misc.tex @@ -55,11 +55,12 @@ %\listoffigures \mainmatter +\include{install} \include{python} \include{vars} \include{stunnel} -\include{dvd} -\include{projects} +%\include{dvd} +%\include{projects} \include{internaldb} \begin{appendices} \begin{small} -- 2.39.5