Thread

1. Explicit config patch 7.2B4

   mlw <markw@mohawksoft.com> — 2001-12-16T14:35:58Z

   I guess I will maintain this for people who want it.
   
   This allows
   
   postmaster -C /etc/pgsql/mydb.conf
   
   The "-C" option specifies a configuration file.
   
   In the config file there are two more options:
   
   datadir = '/u01/postgres'
   hbaconfig = '/etc/pgsql/pg_hba.conf'
   
   The "datadir" option specifies where the postgresql data directory resides. (My
   original patch used the setting "pgdatadir" in which the "pg" seemed
   redundant.)
   
   The "hbaconfig" specifies where postgresql will look for the pg_hba.conf file.
   
   If the "-D" option is specified on the command line, it overides the "datadir"
   option in the config file. (This is a different behavior than my original
   patch)
   
   If No "datadir" is specified, it must be specified either on the command line
   or the normal PGDATA environment variable.
   
   If no "hbaconfig" setting is set, the it will look for pg_hba.config in the
   data directory as always.
   
   One can start many databases with the same settings as:
   
   postmaster -C /path/default.conf -p 5432 -D /path/name1
   postmaster -C /path/default.conf -p 5433 -D /path/name2
   postmaster -C /path/default.conf -p 5434 -D /path/name3

2. Re: Explicit config patch 7.2B4

   Doug McNaught <doug@wireboard.com> — 2001-12-16T15:26:55Z

   mlw <markw@mohawksoft.com> writes:
   
   > I guess I will maintain this for people who want it.
   
   I'd definitely encourage you to try to get it into 7.3 when that
   opens--the list seems to be generally positive about it, and as long
   as existing setups work as-is (which seems to be the case) I think
   it's a valuable addition.
   
   -Doug
   -- 
   Let us cross over the river, and rest under the shade of the trees.
      --T. J. Jackson, 1863
   
   

3. Re: Explicit config patch 7.2B4

   Marko Kreen <marko@l-t.ee> — 2001-12-16T17:33:01Z

   On Sun, Dec 16, 2001 at 09:35:58AM -0500, mlw wrote:
   > This allows
   > 
   > postmaster -C /etc/pgsql/mydb.conf
   
   Nice.
   
   > In the config file there are two more options:
   > 
   > datadir = '/u01/postgres'
   > hbaconfig = '/etc/pgsql/pg_hba.conf'
   
   What about pg_ident.conf?
   
   -- 
   marko
   
   
   

4. Re: Explicit config patch 7.2B4

   Peter Eisentraut <peter_e@gmx.net> — 2001-12-16T22:23:39Z

   mlw writes:
   
   > This allows
   >
   > postmaster -C /etc/pgsql/mydb.conf
   >
   > The "-C" option specifies a configuration file.
   
   I'm still not happy about this, because given a pre-configured or already
   running system it is difficult or impossible to find out which
   configuration file is being used.  This offsets in many ways the improved
   usability you're trying to achieve.
   
   I think an 'include' directive for postgresql.conf would solve this
   problem more generally (since it allows many more sharing models) and
   would also give us a good tool when we get to the configuration of
   alternative storage locations.
   
   Probably a command-line option could prove useful for testing purposes,
   etc., but I feel that by default the configuration should be written down
   in some easy-to-find file.  This is consistent with the move away from
   command-line options that we have made with postgresql.conf.
   
   Probably we could make the option -C to mean "imagine an include directive
   written at the very start [or end?] of $PGDATA/postgresql.conf".  With the
   default empty file this would achieve exactly the same thing as you're
   trying.
   
   Comments?
   
   -- 
   Peter Eisentraut   peter_e@gmx.net
   
   
   

5. Re: Explicit config patch 7.2B4

   mlw <markw@mohawksoft.com> — 2001-12-16T22:37:13Z

   Peter Eisentraut wrote:
   > 
   > mlw writes:
   > 
   > > This allows
   > >
   > > postmaster -C /etc/pgsql/mydb.conf
   > >
   > > The "-C" option specifies a configuration file.
   > 
   > I'm still not happy about this, because given a pre-configured or already
   > running system it is difficult or impossible to find out which
   > configuration file is being used.  This offsets in many ways the improved
   > usability you're trying to achieve.
   
   I do not agree. A command line option which points to a configuration file IS
   the standard way to start a server under UNIX.
   
   > 
   > I think an 'include' directive for postgresql.conf would solve this
   > problem more generally (since it allows many more sharing models) and
   > would also give us a good tool when we get to the configuration of
   > alternative storage locations.
   
   An include directive would be useful, obviously, but it is not in exclusion of
   a more flexible configuration file.
   
   > 
   > Probably a command-line option could prove useful for testing purposes,
   > etc., but I feel that by default the configuration should be written down
   > in some easy-to-find file.  This is consistent with the move away from
   > command-line options that we have made with postgresql.conf.
   
   I am having the hardest time understanding your antipathy toward an explicit
   configuration file. I just don't have any idea of why you are fighting it so
   hardly. As far as I can see there is no reason not to do it, and every other
   important server on UNIX supports this construct.
   
   Again, I just don't get it. Standards are standards, and an explicit
   configuration file is a defacto standard.
   
   > 
   > Probably we could make the option -C to mean "imagine an include directive
   > written at the very start [or end?] of $PGDATA/postgresql.conf".  With the
   > default empty file this would achieve exactly the same thing as you're
   > trying.
   
   The WHOLE idea is to get away from a configuration file mixed with the data. I
   think the notion of having configuration contained in the same location as data
   is bad. Furthermore, forcing this construct is worse.
   > 
   > Comments?
   
   I really don't understand why you don't want this. There isn't a single
   important UNIX server which forces its configuration file to be contained
   within its data / operational directory. Not one. Why is postgresql "better"
   for being less flexible?
   
   What is the harm in including this functionality?
   
   

6. Re: Explicit config patch 7.2B4

   Lamar Owen <lamar.owen@wgcr.org> — 2001-12-17T02:43:17Z

   On Sunday 16 December 2001 05:23 pm, Peter Eisentraut wrote:
   > I'm still not happy about this, because given a pre-configured or already
   > running system it is difficult or impossible to find out which
   > configuration file is being used.  This offsets in many ways the improved
   > usability you're trying to achieve.
   
   Would -C and its argument not be written to $PGDATA/postmaster.opts if 
   started with pg_ctl?  I've not looked at the patch directly, but it would be 
   regular behaviour for that to show up, right?  If it's in postmaster.opts, 
   then it's trivial to examine and determin where things are coming from.
   
   > I think an 'include' directive for postgresql.conf would solve this
   > problem more generally (since it allows many more sharing models) and
   > would also give us a good tool when we get to the configuration of
   > alternative storage locations.
   
   I like an include directive.  But not for the reasons you like it.
   
   > Probably we could make the option -C to mean "imagine an include directive
   > written at the very start [or end?] of $PGDATA/postgresql.conf".  With the
   > default empty file this would achieve exactly the same thing as you're
   > trying.
   
   No -- he's trying to get the config out of $PGDATA.  The config 
   _does_not_belong_with_the_data_.  While it _could_ be put there if the admin 
   chooses, it should not be tied to $PGDATA.
   
   I'll have to echo Mark's query, though: Why are you fighting this, Peter?  
   This functionality mirrors the standard behaviour for daemons.  Name a 
   standard daemon package other than postgresql that automatically assumes the 
   config is with dynamic data, and overwrites an existing config when the 
   dynamic data area is reinitialized.
   
   I'm willing to compromise to a degree on this issue.  However, Mark already 
   has working code.  Sounds like a candidate for a patch -- maybe even a 
   feature patch.  And I'll admit to some desire to apply this patch for the 
   RPMset -- but I probably won't, as the RPMset shouldn't do anything that 
   drastic.  However, it wouldn't surprize me  in the least for a distributor 
   such as Red Hat to apply this patch.
   -- 
   Lamar Owen
   WGCR Internet Radio
   1 Peter 4:11
   
   

7. Re: Explicit config patch 7.2B4

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-12-17T04:13:12Z

   Lamar Owen <lamar.owen@wgcr.org> writes:
   > I'll have to echo Mark's query, though: Why are you fighting this, Peter?  
   
   Peter's not the only one who's unhappy.
   
   > This functionality mirrors the standard behaviour for daemons.
   
   That's been Mark's primary argument all along, and what it ignores is
   that the standard behavior for daemons is designed around the assumption
   that a system is running only one copy of any given daemon.  That's a
   fine assumption for most daemons but an unacceptable one for Postgres.
   
   I'm prepared to accept some kind of compromise on this issue, but I'm
   really tired of hearing the useless "other daemons do it this way"
   argument.  Could we hear some more-relevant argument?
   
   I rather liked Peter's idea of treating the feature as an implicit
   inclusion.  Maybe there's an even-better approach out there, but so far
   that's the best idea I've heard.
   
   > Name a standard daemon package other than postgresql that
   > automatically assumes the config is with dynamic data, and overwrites
   > an existing config when the dynamic data area is reinitialized.
   
   initdb will not overwrite an existing config.  Try it.
   
   > However, it wouldn't surprize me  in the least for a distributor 
   > such as Red Hat to apply this patch.
   
   Oh, I doubt it...
   
   			regards, tom lane
   			Red Hat Database project
   
   

8. Re: Explicit config patch 7.2B4

   Doug McNaught <doug@wireboard.com> — 2001-12-17T05:06:22Z

   Tom Lane <tgl@sss.pgh.pa.us> writes:
   
   > That's been Mark's primary argument all along, and what it ignores is
   > that the standard behavior for daemons is designed around the assumption
   > that a system is running only one copy of any given daemon.  That's a
   > fine assumption for most daemons but an unacceptable one for Postgres.
   
   I'd say that's not completely accurate.  I've seen and run sites with
   more than one {httpd, sendmail} running.  The basic idea is:
   
   * If no config file is specified, either look for it in a standard
     place, or complain bitterly.  Sendmail looks for /etc/sendmail.cf
     (usually); Apache looks in a place configured at compile time
     (/etc/httpd/conf/httpd.conf on RedHat systems).
   
   * If a config file *is* specified, use it.  It tells you where to look 
     for other stuff (queue directory, webserver root or whatever).
   
   The above scheme is used by many different daemons and is *perfectly*
   conducive to running multiple copies.  What makes you say it isn't?
   
   > I'm prepared to accept some kind of compromise on this issue, but I'm
   > really tired of hearing the useless "other daemons do it this way"
   > argument.  Could we hear some more-relevant argument?
   
   How is a patch that (a) perfectly preserves existing behavior, and (b) 
   allows for more flexibility in configuration, a bad thing?
   
   I'm not going to lose a lot of sleep if Mark's patch isn't adopted.  I
   will say, however, that as a long-time Un*x sysadmin (Ultrix, Irix,
   Solaris, BSD, Linux) PG's method of configuration struck me as a bit
   weird when I first saw it.  It obviously does the job, but I like the
   idea of giving users and packagers a configuration method that's still
   sufficiently flexible and is more familiar to some.
   
   My $0.02...
   
   -Doug
   -- 
   Let us cross over the river, and rest under the shade of the trees.
      --T. J. Jackson, 1863
   
   

9. Re: Explicit config patch 7.2B4

   mlw <markw@mohawksoft.com> — 2001-12-17T12:22:00Z

   Tom Lane wrote:
   > 
   > Lamar Owen <lamar.owen@wgcr.org> writes:
   > > I'll have to echo Mark's query, though: Why are you fighting this, Peter?
   > 
   > Peter's not the only one who's unhappy.
   
   I still do not understand why.
   
   > 
   > > This functionality mirrors the standard behaviour for daemons.
   > 
   > That's been Mark's primary argument all along, and what it ignores is
   > that the standard behavior for daemons is designed around the assumption
   > that a system is running only one copy of any given daemon.  That's a
   > fine assumption for most daemons but an unacceptable one for Postgres.
   
   It makes NO such argument at all! It allows an admin to explicitly share a
   configuration file (or not). I allows for one central place in which multiple
   configuration files can be stored and backed up. It allows for the explicit
   sharing of pg_hba.conf files. (It was noted that pg_ident.conf should be added,
   I am looking at it.)
   
   Most of all it does these things WITHOUT symlinks. Most admins I know like
   symlinks as a method of working around a short coming in a product, but would
   rather have the configurability designed into the product.
   
   I wrote this patch to make it easier for me to administer multiple databases on
   one machine. To make it easier for UNIX admins to follow the dba's trail. I
   wrote this so a system was a bit more self documenting without having to follow
   symlinks.
   
   > 
   > I'm prepared to accept some kind of compromise on this issue, but I'm
   > really tired of hearing the useless "other daemons do it this way"
   > argument.  Could we hear some more-relevant argument?
   
   This something else I don't understand. Why would you NOT give an admin the
   sort of configurability they expect?
   
   > 
   > I rather liked Peter's idea of treating the feature as an implicit
   > inclusion.  Maybe there's an even-better approach out there, but so far
   > that's the best idea I've heard.
   
   In my eyes, "implicit" means unexpected. I love the idea of an include
   directive, that is a great idea, but it does not address the separation of data
   and config.
   
   People new to PostgreSQL will look for he config in /usr/local/pgsql/etc, but
   it won't be there. You can specify the config directory with configure
   (sysconfdir), but it is never used.
   
   > 
   > > Name a standard daemon package other than postgresql that
   > > automatically assumes the config is with dynamic data, and overwrites
   > > an existing config when the dynamic data area is reinitialized.
   > 
   > initdb will not overwrite an existing config.  Try it.
   
   That's good to know.
   
   > 
   > > However, it wouldn't surprize me  in the least for a distributor
   > > such as Red Hat to apply this patch.
   > 
   > Oh, I doubt it...
   
   Tom, I really don't understand the resistance. It seem irrational to me, and I
   am really trying to figure it out.
   
   Obviously you must have your reasons, but all I've read thus far is the
   argument that "PostgreSQL is different than other daemons." Maybe I'm pushing
   too hard for this and making people defensive, but I just don't get it.
   
   The core reasons for this patch:
   (1) Move configuration out of $PGDATA and into some centralized location. I do
   not know of a single admin that would object to this.
   (2) Allow admins to share the pg_hba.conf file.
   
   I try to get pg_ident when I get a chance, that's a good idea.
   
   The one thing about this I do not like is that it is a "share all" or "share
   none" solution. An include directive would be helpful here, but I think it is a
   good start.
   
   

10. Re: Explicit config patch 7.2B4

    Trond Eivind Glomsrød <teg@redhat.com> — 2001-12-17T16:26:28Z

    Tom Lane <tgl@sss.pgh.pa.us> writes:
    
    > That's been Mark's primary argument all along, and what it ignores is
    > that the standard behavior for daemons is designed around the assumption
    > that a system is running only one copy of any given daemon.  That's a
    > fine assumption for most daemons but an unacceptable one for Postgres.
    
    I don't think there would be that much problems with it, but you can
    always have defaults in one location and allow them to be overridable.
    
    > > However, it wouldn't surprize me  in the least for a distributor 
    > > such as Red Hat to apply this patch.
    > 
    > Oh, I doubt it...
    > 
    > 			regards, tom lane
    > 			Red Hat Database project
    
    Don't. I'd do it in a heartbeat - I'd love to have /etc/postgresql/
    with defaults. Configuration files should not be located in /var.
    
    regards, Trond Eivind Glomsrød
    developer, Red Hat Linux developer
    -- 
    Trond Eivind Glomsrød
    Red Hat, Inc.
    
    

11. Re: Explicit config patch 7.2B4

    Oliver Elphick <olly@lfix.co.uk> — 2001-12-17T17:08:59Z

    On Mon, 2001-12-17 at 12:22, mlw wrote:
    > > That's been Mark's primary argument all along, and what it ignores is
    > > that the standard behavior for daemons is designed around the assumption
    > > that a system is running only one copy of any given daemon.  That's a
    > > fine assumption for most daemons but an unacceptable one for Postgres.
    > 
    > It makes NO such argument at all! It allows an admin to explicitly share a
    > configuration file (or not). I allows for one central place in which multiple
    > configuration files can be stored and backed up. It allows for the explicit
    > sharing of pg_hba.conf files. (It was noted that pg_ident.conf should be added,
    > I am looking at it.)
    > 
    > Most of all it does these things WITHOUT symlinks. Most admins I know like
    > symlinks as a method of working around a short coming in a product, but would
    > rather have the configurability designed into the product.
    > 
    > I wrote this patch to make it easier for me to administer multiple databases on
    > one machine. To make it easier for UNIX admins to follow the dba's trail. I
    > wrote this so a system was a bit more self documenting without having to follow
    > symlinks.
    
    As Debian packager I would very much like to see a more convenient and
    controllable configuration system.
    
    Ross described last week the Debian method of symlinking the real config
    files in /etc/postgresql to $PGDATA/; this method is forced on us by
    Debian policy, which requires that all config files be in /etc.  The
    undesired result is that it is not convenient to run multiple servers on
    a single machine using the Debian package.
    
    I am currently considering a method of getting round this by creating a
    subdirectory of /etc/postgresql for each server instance, but it would
    be nice to be able to share global options in more convenient ways than
    by multiplying symlinks.  
    
    -- 
    Oliver Elphick                                Oliver.Elphick@lfix.co.uk
    Isle of Wight                              http://www.lfix.co.uk/oliver
    GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
    
         "For I say, through the grace given unto me, to every 
          man that is among you: Do not think of yourself more 
          highly than you ought, but rather think of yourself 
          with sober judgement, in accordance with the measure 
          of faith God has given you."            Romans 12:3 
    

12. Re: Explicit config patch 7.2B4

    Lamar Owen <lamar.owen@wgcr.org> — 2001-12-17T17:30:14Z

    On Sunday 16 December 2001 11:13 pm, Tom Lane wrote:
    > Lamar Owen <lamar.owen@wgcr.org> writes:
    > > This functionality mirrors the standard behaviour for daemons.
    
    > That's been Mark's primary argument all along, and what it ignores is
    > that the standard behavior for daemons is designed around the assumption
    > that a system is running only one copy of any given daemon.  That's a
    > fine assumption for most daemons but an unacceptable one for Postgres.
    
    Really?  Most daemons allow a default config location, and then either allow 
    or require a config file path on the command line.  AOLserver _requires_ the 
    path on the command line; named allows it, sendmail allows it, etc.
    
    I routinely run multiple nameds on machines behind NAT.  Just a simple config 
    file path away.  I routinely run multiple instances of other programs as well.
    
    Note that neither I, Mark, Doug, or anyone else is asking for a change in the 
    default behavior.  I personally just want it to be _allowed_ behavior.  
    Nothing more; nothing less.
    
    > I rather liked Peter's idea of treating the feature as an implicit
    > inclusion.  Maybe there's an even-better approach out there, but so far
    > that's the best idea I've heard.
    
    I rather dislike the idea that $PGDATA is where the config file lives.  I 
    quite particularly dislike the 'implicit include' idea.
    
    > > Name a standard daemon package other than postgresql that
    > > automatically assumes the config is with dynamic data, and overwrites
    > > an existing config when the dynamic data area is reinitialized.
    
    > initdb will not overwrite an existing config.  Try it.
    
    Ok, I'll concede that.  But having postgresql.conf in $PGDATA makes it more 
    difficult for an admin to wipe $PGDATA and start over.  For that matter, 
    pg_hba.conf is there, too, and I disagree that users should be forced to put 
    it in $PGDATA.
    
    > > However, it wouldn't surprize me  in the least for a distributor
    > > such as Red Hat to apply this patch.
    
    > Oh, I doubt it...
    
    > 			regards, tom lane
    > 			Red Hat Database project
    
    Having seen Trond's reply, I have to laugh....as I _know_ he disagrees with 
    you (and knew such before he replied -- this has been a thorn in his side for 
    awhile.  Might prove to be an interesting 'discussion' inside RH over it.  
    But, again, an 'optional' command line switch should be a no-brainer.  It 
    just seems to me to be rather unproductive to not allow people more 
    flexibility in a regular way.  Symlinks are not the answer, either.
    
    But RH is not the only distributor of PostgreSQL. And, for the record, the 
    Debian packages already do something very similar.  Wouldn't it be better for 
    the core package to support this, rather than each distributor doing it 
    differently from each other?
    -- 
    Lamar Owen
    WGCR Internet Radio
    1 Peter 4:11
    
    

13. Re: Explicit config patch 7.2B4

    mlw <markw@mohawksoft.com> — 2001-12-17T17:56:53Z

    Marko Kreen wrote:
    > 
    > On Sun, Dec 16, 2001 at 09:35:58AM -0500, mlw wrote:
    > > This allows
    > >
    > > postmaster -C /etc/pgsql/mydb.conf
    > 
    > Nice.
    > 
    > > In the config file there are two more options:
    > >
    > > datadir = '/u01/postgres'
    > > hbaconfig = '/etc/pgsql/pg_hba.conf'
    > 
    > What about pg_ident.conf?
    
    I will submit a complete patch that includes pg_ident.conf as well.
    
    Here is a question for the great minds here:
    
    If a user has used the "-C" option, as in:
    
    postmaster -C /etc/pgsql/mydb.conf
    
    Should I then, and first, see if there is a "/etc/pgsql/pg_hba.conf" or
    "/etc/pgsql/pg_ident.conf" and use it as an explicit path?
    
    
    How about:
    
    postmaster -C /etc/pgsql
    
    Should I then look for:
    
    /etc/pgsql/postgresql.conf
    /etc/pgsql/pg_hba.conf
    /etc/pgsql/pg_ident.conf
    
    ?
    
    Just curious what you think.
    
    

14. Re: Explicit config patch 7.2B4

    Lamar Owen <lamar.owen@wgcr.org> — 2001-12-17T18:16:41Z

    On Monday 17 December 2001 12:56 pm, mlw wrote:
    > Here is a question for the great minds here:
    > If a user has used the "-C" option, as in:
    
    > postmaster -C /etc/pgsql/mydb.conf
    
    > Should I then, and first, see if there is a "/etc/pgsql/pg_hba.conf" or
    > "/etc/pgsql/pg_ident.conf" and use it as an explicit path?
    
    > How about:
    > postmaster -C /etc/pgsql
    
    I agree to both; of course, this should be overrideable in the conf file.
    -- 
    Lamar Owen
    WGCR Internet Radio
    1 Peter 4:11
    
    

15. Re: Explicit config patch 7.2B4, not "-C" ??

    mlw <markw@mohawksoft.com> — 2001-12-17T18:32:23Z

    I was looking around, and for this to be a good patch, I have to add it
    to "postgres" as well as "postmaster."
    
    
    In the 7.1.3 source, there is a command line option "-C" (don't show
    version number) which seems to have been depricated in 7.1.x (no longer
    documented, but still active.)
    
    Is is "-C" dangerous at this stage? Should I use another command line
    option?
    
    

16. Re: Explicit config patch 7.2B4

    Peter Eisentraut <peter_e@gmx.net> — 2001-12-17T20:58:01Z

    Trond Eivind Glomsrød writes:
    
    > Don't. I'd do it in a heartbeat - I'd love to have /etc/postgresql/
    > with defaults. Configuration files should not be located in /var.
    
    This problem has already been solved with symlinks a long time ago.
    Nothing new here.  In fact, for users that are accustomed to the
    "original" source distribution it'd be a much easier-to-understand
    approach.  (Whether it's "better" in the general sense is being
    discussed.)
    
    -- 
    Peter Eisentraut   peter_e@gmx.net
    
    
    

17. Re: Explicit config patch 7.2B4

    Lamar Owen <lamar.owen@wgcr.org> — 2001-12-17T20:59:34Z

    On Monday 17 December 2001 03:58 pm, Peter Eisentraut wrote:
    > Trond Eivind Glomsrød writes:
    > > Don't. I'd do it in a heartbeat - I'd love to have /etc/postgresql/
    > > with defaults. Configuration files should not be located in /var.
    
    > This problem has already been solved with symlinks a long time ago.
    > Nothing new here.
    
    Using symlinks is a workaround, not a solution.
    -- 
    Lamar Owen
    WGCR Internet Radio
    1 Peter 4:11
    
    

18. Re: Explicit config patch 7.2B4, not "-C" ??

    Peter Eisentraut <peter_e@gmx.net> — 2001-12-17T22:03:05Z

    mlw writes:
    
    > Is is "-C" dangerous at this stage? Should I use another command line
    > option?
    
    Use -C and eliminate/ignore the other use.
    
    -- 
    Peter Eisentraut   peter_e@gmx.net
    
    
    
    

19. Re: Explicit config patch 7.2B4

    Marko Kreen <marko@l-t.ee> — 2001-12-18T16:56:16Z

    On Mon, Dec 17, 2001 at 12:56:53PM -0500, mlw wrote:
    > Marko Kreen wrote:
    > > On Sun, Dec 16, 2001 at 09:35:58AM -0500, mlw wrote:
    > > > In the config file there are two more options:
    > > >
    > > > datadir = '/u01/postgres'
    > > > hbaconfig = '/etc/pgsql/pg_hba.conf'
    
    > I will submit a complete patch that includes pg_ident.conf as well.
    > 
    > Here is a question for the great minds here:
    > 
    > If a user has used the "-C" option, as in:
    > 
    > postmaster -C /etc/pgsql/mydb.conf
    > 
    > Should I then, and first, see if there is a "/etc/pgsql/pg_hba.conf" or
    > "/etc/pgsql/pg_ident.conf" and use it as an explicit path?
    
    It should search them only if they are not mentioned in .conf, I
    guess.
    
    > How about:
    > 
    > postmaster -C /etc/pgsql
    > 
    > Should I then look for:
    > 
    > /etc/pgsql/postgresql.conf
    > /etc/pgsql/pg_hba.conf
    > /etc/pgsql/pg_ident.conf
    
    One suggestion to you: try to think how different approaches
    look when documented.  User must be able to predict program
    behaviour only by looking at docs.  If 3 lines of C add
    2 messy paragraphs to docs, then it is probably unnecessary
    'feature'.  Also what if I say '-C /etc/pgsql/db.conf' and there 
    is no pg_hba.conf there.  It should give error, not go secretly
    searching it in $PGDATA.
    
    -- 
    marko
    
    
    

20. Re: Explicit config patch 7.2B4

    Peter Eisentraut <peter_e@gmx.net> — 2001-12-18T22:24:54Z

    mlw writes:
    
    > If a user has used the "-C" option, as in:
    >
    > postmaster -C /etc/pgsql/mydb.conf
    >
    > Should I then, and first, see if there is a "/etc/pgsql/pg_hba.conf" or
    > "/etc/pgsql/pg_ident.conf" and use it as an explicit path?
    
    > How about:
    >
    > postmaster -C /etc/pgsql
    >
    > Should I then look for:
    >
    > /etc/pgsql/postgresql.conf
    > /etc/pgsql/pg_hba.conf
    > /etc/pgsql/pg_ident.conf
    
    I like the latter better because of the symmetry of -C with -D.
    
    Btw., the following issues still need to be addressed:
    
    - Location of SSL certificate files (Are they appropriate for /etc?  What
      does Apache do?)
    
    - Location of secondary password files.  By default they should probably
      track pg_hba.conf.  Is that enough?
    
    - Location of charset.conf and the associated recode tables
    
    For a start, putting all of these under -C is probably sufficient.  More
    complicated setups can be achieved using symlinks. ;-)
    
    -- 
    Peter Eisentraut   peter_e@gmx.net
    
    
    

21. Re: Explicit config patch 7.2B4

    Andrew G. Hammond <drew@xyzzy.dhs.org> — 2001-12-19T00:29:17Z

    On Tue, 2001-12-18 at 17:24, Peter Eisentraut wrote:
    > - Location of SSL certificate files (Are they appropriate for /etc?  What
    >   does Apache do?)
    
    Using Apache and modssl under debian linux, the certs live in
    /etc/apache.  Similarly, crypto keys for Nessus live in /etc/nessusd.
    So /etc/postgresql would be reasonable.
    
    -- 
    Andrew G. Hammond     mailto:drew@xyzzy.dhs.org  
    http://xyzzy.dhs.org/~drew/
    56 2A 54 EF 19 C0 3B 43 72 69 5B E3 69 5B A1 1F                 
    613-389-5481
    5CD3 62B0 254B DEB1 86E0  8959 093E F70A B457 84B1
    "To blow recursion you must first blow recur" -- me
    

22. Re: Explicit config patch 7.2B4

    Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2001-12-19T02:45:55Z

    > Using Apache and modssl under debian linux, the certs live in
    > /etc/apache.  Similarly, crypto keys for Nessus live in /etc/nessusd.
    > So /etc/postgresql would be reasonable.
    
    Just a note from a FreeBSD (ie. a decent filesystem standard layout) it
    horrifies me to see post-install packages put stuff in /etc/.  Of course,
    whomever writes the FreeBSD port will override this default and put it in
    /usr/local/etc/pgsql.
    
    Chris
    
    
    

23. Re: Explicit config patch 7.2B4

    Vince Vielhaber <vev@michvhf.com> — 2001-12-19T03:27:02Z

    On Wed, 19 Dec 2001, Christopher Kings-Lynne wrote:
    
    > > Using Apache and modssl under debian linux, the certs live in
    > > /etc/apache.  Similarly, crypto keys for Nessus live in /etc/nessusd.
    > > So /etc/postgresql would be reasonable.
    >
    > Just a note from a FreeBSD (ie. a decent filesystem standard layout) it
    > horrifies me to see post-install packages put stuff in /etc/.  Of course,
    > whomever writes the FreeBSD port will override this default and put it in
    > /usr/local/etc/pgsql.
    
    Which is why I avoid rpm, deb, package, etc.  The support nightmare it
    causes when vendors start upchucking various bits and pieces of the
    program all over the drive.  Then the poor user tries explaining what
    he did or tried to do in /var, /etc, /opt and a bunch of other places
    (up to and not necessarily excluding the trunk of the car) and figuring
    out something as simple as where a certain file is so the permissions
    can be verified or where the include files and libraries happen to be
    hiding.
    
    No, this is not an invite for the discussion of whether or not vendors
    should or should not scatter files all over the filesystem.  It's only
    a statement of what it causes on the support end - no, not all people
    contact the vendor of the os when they have a problem with a program.
    
    Vince.
    -- 
    ==========================================================================
    Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
             56K Nationwide Dialup from $16.00/mo at Pop4 Networking
            Online Campground Directory    http://www.camping-usa.com
           Online Giftshop Superstore    http://www.cloudninegifts.com
    ==========================================================================
    
    
    
    
    

24. Re: Explicit config patch 7.2B4

    Andrew G. Hammond <drew@xyzzy.dhs.org> — 2001-12-19T20:41:38Z

    On Tue, 2001-12-18 at 22:27, Vince Vielhaber wrote:
    > On Wed, 19 Dec 2001, Christopher Kings-Lynne wrote:
    > 
    > > > Using Apache and modssl under debian linux, the certs live in
    > > > /etc/apache.  Similarly, crypto keys for Nessus live in /etc/nessusd.
    > > > So /etc/postgresql would be reasonable.
    > >
    > > Just a note from a FreeBSD (ie. a decent filesystem standard layout) it
    > > horrifies me to see post-install packages put stuff in /etc/.  Of course,
    > > whomever writes the FreeBSD port will override this default and put it in
    > > /usr/local/etc/pgsql.
    > 
    > Which is why I avoid rpm, deb, package, etc.  The support nightmare it
    > causes when vendors start upchucking various bits and pieces of the
    > program all over the drive.  Then the poor user tries explaining what
    > he did or tried to do in /var, /etc, /opt and a bunch of other places
    > (up to and not necessarily excluding the trunk of the car) and figuring
    > out something as simple as where a certain file is so the permissions
    > can be verified or where the include files and libraries happen to be
    > hiding.
    > 
    > No, this is not an invite for the discussion of whether or not vendors
    > should or should not scatter files all over the filesystem.  It's only
    > a statement of what it causes on the support end - no, not all people
    > contact the vendor of the os when they have a problem with a program.
    
    Funny, I have exactly the same opinion about stuff scattered all over
    the filesystem, but that's one of the reasons I like debian. They don't
    scatter stuff, they organize it.  And, at least to me things make sense
    that way.  Config files are under /etc.  All of them.  For every
    package.
    
    Since it's utterly impossible to get a whole bunch of different people
    to agree about where stuff belongs, or even to have a rational
    discussion on the topic, having the distros impose this sort of thing by
    fiat seems to be the only way to get any kind of consistency at all.
    
    Honestly, I really don't give a damn what filesystem layout I end up
    using, as long as it's reasonably simple and logical.
    
    However I will say that personally, I like having a path that's less
    than a gigabyte.  Debian delivers that for me.  But hey, to each their
    own.
    
    ObFlame: BSD sux.  That little devil looks kinda fruity to me, and I'll
    bet Tux could whup his ass.
    
    -- 
    Andrew G. Hammond     mailto:drew@xyzzy.dhs.org  
    http://xyzzy.dhs.org/~drew/
    56 2A 54 EF 19 C0 3B 43 72 69 5B E3 69 5B A1 1F                 
    613-389-5481
    5CD3 62B0 254B DEB1 86E0  8959 093E F70A B457 84B1
    "To blow recursion you must first blow recur" -- me
    

25. Re: Explicit config patch 7.2B4

    Vince Vielhaber <vev@michvhf.com> — 2001-12-19T21:17:14Z

    On 19 Dec 2001, Andrew G. Hammond wrote:
    
    > ObFlame: BSD sux.  That little devil looks kinda fruity to me, and I'll
    > bet Tux could whup his ass.
    
    I was going to respond until I saw this.  I don't waste my time with
    children.
    
    Vince.
    -- 
    ==========================================================================
    Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
             56K Nationwide Dialup from $16.00/mo at Pop4 Networking
            Online Campground Directory    http://www.camping-usa.com
           Online Giftshop Superstore    http://www.cloudninegifts.com
    ==========================================================================
    
    
    
    
    

26. Re: Explicit config patch 7.2B4

    Jason Earl <jason.earl@simplot.com> — 2001-12-19T22:22:41Z

    Vince Vielhaber <vev@michvhf.com> writes:
    
    > On 19 Dec 2001, Andrew G. Hammond wrote:
    > 
    > > ObFlame: BSD sux.  That little devil looks kinda fruity to me, and I'll
    > > bet Tux could whup his ass.
    > 
    > I was going to respond until I saw this.  I don't waste my time with
    > children.
    > 
    > Vince.
    
    What, you didn't see the ObFlame: disclosure.  It seemed like a fairly
    obvious joke to me.
    
    I agree with Andrew.  One of the things that I like about Debian is
    that all of the config files for every package that is installed via
    the Debian packaging system is somewhere in /etc.  Yes, this makes it
    difficult (sometimes) to translate the documentation for packages that
    expect to have that information somewhere else, but it is very useful
    for those cases (like PostgreSQL for example) that put the
    configuration files somewhere totally strange (the application's data
    directory is not where Unix admins start looking for config files).
    
    The long and the short of it is that pretty much every Unix has a
    preference for where the configuration files, data files, log files,
    etc, should go, and the various users probably aren't ever going to
    simply agree that one way is better than the rest.  After all, if
    there is one common trait among Unix admins it is the belief in a "one
    true way."  Unfortunately, that "one true way" seems to vary radically
    depending on which Unix admin you talk to.  I might agree with Debian
    that configuration files belong in /etc, you might feel that they
    belong somewhere else.  Currently, however, it doesn't matter what we
    want.  The configuration files end up in the PostgreSQL data directory
    whether we like it or not.  We can use symlinks to pretend that these
    files are somewhere else, but we can't really move them.
    
    Being able to configure the placement of these files would be a huge
    win.  We can always default to leaving the files right where they
    currently are, but making this configurable would help those people
    who package PostgreSQL for one organization or another tremendously.
    And since most of PostgreSQL's users end up using the version supplied
    by their vendor (whether it's a FreeBSD port or a RedHat RPM or
    whatever) it clearly is a win to give these packagers the flexibility
    they need.
    
    Not that any of you should listen to me, as I am just some random
    PostgreSQL user who happens to be subscribed to HACKERS because I
    wanted to see what the real scoop on 7.2 was :).
    
    Jason
    
    

27. Re: Explicit config patch 7.2B4

    Vince Vielhaber <vev@michvhf.com> — 2001-12-20T03:02:52Z

    On 19 Dec 2001, Jason Earl wrote:
    
    > Vince Vielhaber <vev@michvhf.com> writes:
    >
    > > On 19 Dec 2001, Andrew G. Hammond wrote:
    > >
    > > > ObFlame: BSD sux.  That little devil looks kinda fruity to me, and I'll
    > > > bet Tux could whup his ass.
    > >
    > > I was going to respond until I saw this.  I don't waste my time with
    > > children.
    > >
    > > Vince.
    >
    > What, you didn't see the ObFlame: disclosure.  It seemed like a fairly
    > obvious joke to me.
    
    I fail to see how it was appropriate to the subject or this list.
    And "ObFlame" means 'obligatory flame' meaning he was obligated to
    add the flame.  I fail to see why he'd be obliged to flame for no
    reason.
    
    
    Vince.
    -- 
    ==========================================================================
    Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
             56K Nationwide Dialup from $16.00/mo at Pop4 Networking
            Online Campground Directory    http://www.camping-usa.com
           Online Giftshop Superstore    http://www.cloudninegifts.com
    ==========================================================================