Re: controlling the location of server-side SSL files - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: controlling the location of server-side SSL files
Date
Msg-id 1325633113.19883.13.camel@vanquo.pezone.net
Whole thread Raw
In response to Re: controlling the location of server-side SSL files  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: controlling the location of server-side SSL files  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On mån, 2012-01-02 at 23:42 -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > On mån, 2012-01-02 at 15:47 +0100, Magnus Hagander wrote:
> >> Were you thinking one option pointing to a directory or one option per
> >> file?
> 
> > One option per file:
> 
> That seems like serious overkill.  Why not one option specifying the
> directory?  What use-case is there for letting them be in different
> directories, let alone letting the DBA choose random names for each one?

Several consistency reasons:

- We provide the same per-file options in libpq.

- Indeed, if you use something like dblink or plproxy, these might even
point to the same files.

- We also have settings for hba_file and ident_file that point to a
file.

- All other daemons with SSL support known to me, such as mail and web
servers, have per-file options.

Also some practical reasons:

- Yes, choosing random names is important.  We have local naming
schemes.  And I would rather have a descriptive file name for the CA
than having them all named root.crt, and if I want to know which one it
is I have to look inside the file.

- You might not want all of the files in the same directory.  CA and CRL
might live elsewhere, for example.




pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: our buffer replacement strategy is kind of lame
Next
From: Tom Lane
Date:
Subject: Re: Should I implement DROP INDEX CONCURRENTLY?