]> git.sur5r.net Git - bacula/docs/blobdiff - docs/manual-de/postgresql.tex
Eliminate compiler warnings
[bacula/docs] / docs / manual-de / postgresql.tex
index c5768c5d9f92d046d3c73fa4d7f0cb3e409cdd94..e8df71a732dccd239c069dfaceeaf7b368395185 100644 (file)
@@ -86,7 +86,7 @@ user).
    This script creates the PostgreSQL {\bf bacula} database.  
    If it fails, it is probably because the database is owned by a
    user other than yourself. On many systems, the database owner is
-   {\bf pgsql} and on others such as RedHat and Fedora it is {\bf postgre}.
+   {\bf pgsql} and on others such as RedHat and Fedora it is {\bf postgres}.
    You can find out which it is by examining your /etc/passwd file.
    To create a new user under either your name or with say the name
    {\bf bacula}, you can do the following:
@@ -94,10 +94,10 @@ user).
 \begin{verbatim}
    su
    (enter root password)
-   password pgsql (or postgre)
+   password pgsql (or postgres)
    (enter a password for this account)
    exit
-   su pgsql (or postgre)
+   su pgsql (or postgres)
    (enter password just created)
    createuser kern (or perhaps bacula)
    Shall the new user be allowed to create databases? (y/n) y
@@ -151,6 +151,73 @@ This solved the problem for me, but it is not always a good thing
 to do from a security standpoint.  However, it allowed me to run
 my regression scripts without having a password.
 
+A more secure way to perform database authentication is with md5
+password hashes.  Begin by editing the {\bf pg_hba.conf} file, and
+just prior the the existing ``local'' and ``host'' lines, add the line:
+
+\footnotesize
+\begin{verbatim}
+  local bacula bacula md5
+\end{verbatim}
+\normalsize
+
+and restart the Postgres database server (frequently, this can be done
+using "/etc/init.d/postgresql restart") to put this new authentication
+rule into effect.
+
+Next, become the Postgres administrator, postgres, either by logging
+on as the postgres user, or by using su to become root and then using
+su - postgres to become postgres.  Add a password to the bacula
+database for the bacula user using:
+
+\footnotesize
+\begin{verbatim}
+  \$ psql bacula
+  bacula=# alter user bacula with password 'secret';
+  ALTER USER
+  bacula=# \\q
+\end{verbatim}
+\normalsize
+
+Next, you'll have to add this password to two locations in the
+bacula-dir.conf file: once to the Catalog resource and once to the
+RunBeforeJob entry in the BackupCatalog Job resource.  With the
+password in place, these two lines should look something like:
+
+\footnotesize
+\begin{verbatim}
+  dbname = bacula; user = bacula; password = "secret"
+    ... and ...
+  RunBeforeJob = "/etc/make_catalog_backup bacula bacula secret"
+\end{verbatim}
+\normalsize
+
+Naturally, you should choose your own significantly more random
+password, and ensure that the bacula-dir.conf file containing this
+password is readable only by the root.
+
+Even with the files containing the database password properly
+restricted, there is still a security problem with this approach: on
+some platforms, the environment variable that is used to supply the
+password to Postgres is unavoidable made available to all users of the
+local system.  To eliminate this problem, the Postgres team have
+deprecated the use of the environment variable password-passing
+mechanism and recommend the use of a .pgpass file instead.  To use
+this mechanism, create a file named .pgpass containing the single
+line:
+
+\footnotesize
+\begin{verbatim}
+  localhost:5432:bacula:bacula:secret
+\end{verbatim}
+\normalsize
+
+This file should be copied into the home directory of all accounts
+that will need to gain access to the database: typically, root,
+bacula, and any users who will make use of any of the console
+programs.  The files must then have the owner and group set to match
+the user (so root:root for the copy in ~root, and so on), and the mode
+set to 600, limiting access to the owner of the file.
 
 \subsection*{Re-initializing the Catalog Database}
 \index[general]{Database!Re-initializing the Catalog }