Here's a concrete summary of the various proposals about the location of
configuration files and other things that have been discussed a while ago.
I think we pretty much came to agree -- if not, the rest could perhaps
better be discussed based on the following.  There are also a couple of
open items that need resolution.


* postgresql.conf configuration file

Default location: ${sysconfdir}/postgresql.conf (where ${sysconfdir}
defaults to /usr/local/pgsql/etc).  For those who don't know, --sysconfdir
is actually a configure option, so for "base-system" installs you can set
it to /etc if you prefer.

Overridable by:

- postmaster option -C FILENAME (not directory)


* pg_hba.conf, pg_ident.conf, secondary "password" files,  SSL
  certificates, all other configuration things formerly in $PGDATA

Default location: ${sysconfdir}

Overridable by postgresql.conf/GUC options (thus also
postmaster command-line options).  Proposed names:

hba_conf_file
ident_conf_file
password_file_dir
ssl_key_file
ssl_certificate_file

QUESTION:  Do we want to have the -C command-line option affect these
parameters in some way?  It would seem quite sensible.  But if -C denotes
a file name, as was requested, the location of say pg_hba.conf would be
"${directory part of -C}/pg_hba.conf" (base-name fixed), which might not
be the most elegant way.


* Permission of configuration files

By default, I like postgresql.conf, pg_hba.conf, and pg_ident.conf as
root-owned (or whatever the installer was) 0644 for ease of installation
and use.  Password files containing actual passwords and the SSL files
need to be postgres-owned 0600 (or less), which will require a chmod or
chown call or two in most installations, but setting up secondary
"password" files or SSL will take a few key strokes anyway.  We should
have run-time security checks that we don't use world-readable files that
contain secrets.


* Central database cluster storage area

Default location for postmaster and initdb: ${localstatedir}/data (which
defaults to /usr/local/pgsql/var/data).

Overridable by, in order of decreasing priority:
- -D option
- $PGDATA environment variable (perhaps obsolescent, but no reason to
remove it outright)
- postgresql.conf parameter


* Possible transitional aid

We could have an environment variable $PGCONF that overrides the location
of the postgresql.conf file (in some to be specified way), so those who
don't like the new setup can set PGCONF=$PGDATA or something like that.
However, since this would require the user to actually copy over all the
new configurations files from .../etc/ to $PGDATA, I don't know how many
would actually go for that.


Comments?  Better ideas?

-- 
Peter Eisentraut   peter_e@gmx.net


Wed, 6 Feb 2002 19:28:12 -0500 (EST)
Peter Eisentraut <peter_e@gmx.net>
Summary of new configuration file and data directory locations
Peter Eisentraut <peter_e@gmx.net> writes:
> * pg_hba.conf, pg_ident.conf, secondary "password" files,  SSL
>   certificates, all other configuration things formerly in $PGDATA
> Default location: ${sysconfdir}

This strikes me as a fairly BAD idea because of the security
implications of keeping these things in a world-accessible directory.
I'm willing to tolerate moving postgresql.conf but I am much less
willing to move anything that contains sensitive information.

I suggest that the default location of these things continue to be
$PGDATA (which as you note will be settable from postgresql.conf).

> QUESTION:  Do we want to have the -C command-line option affect these
> parameters in some way?  It would seem quite sensible.

Not necessary if done as above.

> Password files containing actual passwords and the SSL files
> need to be postgres-owned 0600 (or less), which will require a chmod or
> chown call or two in most installations, but setting up secondary
> "password" files or SSL will take a few key strokes anyway.  We should
> have run-time security checks that we don't use world-readable files that
> contain secrets.

While such a check is not a bad idea, it is really just locking the barn
door after the horse has been stolen.  Better to set up the default
configuration to make such errors difficult to commit in the first place.

> We could have an environment variable $PGCONF that overrides the location
> of the postgresql.conf file (in some to be specified way), so those who
> don't like the new setup can set PGCONF=$PGDATA or something like that.

The postmaster -C switch seems sufficient for this; I don't see a reason
to invent an environment var too.

			regards, tom lane

Thu, 07 Feb 2002 13:58:29 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Summary of new configuration file and data directory locations 