Re: Configurable path to look up dynamic libraries

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

On Tuesday 15 May 2001 18:23, Tom Lane wrote:
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)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-----