Re: Configurable path to look up dynamic libraries - Mailing list pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 15 May 2001 18:23, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > We're one component of a system -- and the PostgreSQL Group has done such
> > a good job of being platform agnostic that the platform and systems
> > issues are almost second-class citizens.

> Indeed, that I think is the underlying issue here.  "It's FHS compliant"
> cuts no ice with people who don't run FHS-layout systems, and I don't
> want to improve FHS compliancy at the price of making life more
> difficult for others.  

But that's my point -- it wouldn't, AFAICT, make anyone's life more diffcult 
in the userbase. The existing layout would remain as the default, with the 
FHS behavior a configure-time or run-time option.  Even being configured in 
an FHS compliant mode would not need to force FHS-compliance, just allow it.

But we currently are forcing FHS noncompliance on people. 

>(Likewise for other RPM installation issues, as
> you well know ;-))

As well I know.... ;-)

> But that will require some thought about separating
> security-critical data from not-critical data.  I think we ought to keep
> pg_hba.conf and subsidiary files (especially password files!) in datadir
> *only*.  I'm not sure about the other config files; up to now no one's
> paid any attention to security issues for those files, knowing that they
> were all kept in the same place.  We might need to reorganize their
> contents.

Good points.  However, now that we have breached the issue, GUC in al reality 
doesn't 100% unify configuration.  There's the sticky pg_hba.conf issue, the 
password files issue, etc.

<BRAIN_STORM>

So, what you have are basically two sets of config data:
1.)    Sitewide multiple-postmaster settings
2.)    Per-postmaster (and therefore per-datadir) settings.

There can be overlap here.  While I might want the capability to syslog be 
sitewide, the syslog level and facility might be a per-postmaster thing.  I 
might not want any logging on certain thoroughly tested high-volume databases 
(such as those that back discussion forums on websites). Likewise with TCP 
connections.  address:port and datadir settings are of course a per-datadir 
setting.  

I personally like the config file structure for the web statistics package 
'analog'.  First, there are configured-in defaults set in a header file.  
Then there is the master config file.  But you can then specify a secondary 
config file on the command line that automatically includes the master 
config, but can then override any setting at will.  You can also specify 
where to find the master config.

HOWEVER, while we are somewhat unique amongst databases in that there is 
built-in tcp-wrappers-like functionality, maybe, just maybe, that needs to be 
looked at a little closer.

SO, if postgresql.conf is already sitting in datadir, why not include the 
pg_hba.conf settings in the GUC?  Passwords could be stored similarly to the 
/etc/passwd method in a postgresql.conf section.  If we're going to have 
Unified Configuration, why not go whole-hog on it and really unify the 
configuration?  The default will be to place this file in the datadir, which 
by default is mode 700, so, the default installation will be secure.

Of course, currently postgresql.conf doesn't really have 'sections' except in 
style.  The '.ini' format is well-known and easily parsed, and is common on 
multiple platforms.  But in today's climate, an XML config might be better 
received.  

All that's left to do to satisfy my wish-list is an include directive (which 
may already exist -- the similarity to C headers in that file is striking) 
and a command-line switch to postmaster (or pg_ctl) to grab this file from 
another location, with the default being $PGDATA or the -D setting, if 
specified. With an include directive, a master config setup is easily made 
without unnecessarily complicating matters.  Oh, and tell initdb to not 
overwrite a postgresql.conf that already exists. :-).

Making this work with a single master config and multiple postmasters would 
be easily accomplished by having the ability to 'name' the 'virtual' 
databases and specify the settings for that virtual database in its own named 
section.  You then can start postmaster with pg_ctl and specify a 
- --config=/etc/pgsql/postgresql.conf --name=client1 and get the right datadir 
and the right settings.  Default settings set in the unnamed portion would be 
overridden by the named section's settings.

But, you could just as easily use individual configs that included a master 
(or not) and not use 'named' posmasters.  And the config files could reside 
wherever the admin wanted them to reside.

It's not far from this to making pg_ctl have the ability to start all the 
postmasters in a given config file with one command.  Directives to initdb if 
the datadir doesn't have a database present would simplify installation and 
initial startup, particularly for newbies.

</BRAIN_STORM>

And all of this would be optional usage. You don't use the feature?  The 
existing behavior would be the only reasonable default.

And symlinks are just a Band-Aid patch, and not a solution, as trivial as 
they may be.
- --
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7Aqck5kGGI8vV9eERAjmfAKDPY2U41TA5rvxEzG/eyo2TfjknmQCeOpmx
1XzcsCRzQ7Eq9p3fagQJSVY=
=SOxC
-----END PGP SIGNATURE-----