Re: location of the configuration files

Stephan Szabo wrote:

>On Thu, 13 Feb 2003, mlw wrote:
>
>
>
>>Stephan Szabo wrote:
>>
>>
>>>>>On Thu, 2003-02-13 at 09:23, mlw wrote:
>>>>>
>>>>>
>>>>>>I deal with a number of PG databases on a number of sites, and it is a
>>>>>>real pain in the ass to get to a PG box and hunt around for data
>>>>>>directory so as to be able to administer the system. What's really
>>>>>>annoying is when you have to find the data directory when someone else
>>>>>>set up the system.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>You realize that the actual code feature doesn't necessarily help this
>>>case, right? Putting configuration in /etc and having a configuration file
>>>option on the command line are separate concepts.
>>>
>>>
>
>Re-read my statement and yours about the case you were mentioning. ;)
>Sure, putting the files in /etc lets you find them easily. However, if
>you're doing things like finding configuration made by someone else and
>said configuration isn't in /etc (which if they wanted to they could do
>now with symlinks I believe - yes symlinks aren't a complete solution, but
>I think they're reasonable on most of our current ports) then you still
>have to search the system for the configuration file, except now it might
>not even be postgresql.conf. That's why I said the two issues aren't the
>same.
>
>
>
>>>I think the feature is worthwhile, but I have some initial condition
>>>functionality questions that may have been answered in the previous patch,
>>>but I don't remember at this point.
>>>
>>>Mostly these have to deal with initial creation. Does the user specify an
>>>output location to initdb, do they just specify a data dir as now where
>>>the configuration goes but then they need to move it somewhere, does
>>>initdb now do nothing relating to configuration file and the user should
>>>make one on his own. Related, is the admin expected to have already made
>>>(say) /etc/postgresql to stick the config in and set the permissions
>>>correctly (since initdb doesn't run as root)?
>>>
>>>
>>>
>>My patch only works on the PostgreSQL server code. No changes have been
>>made to the initialization scripts.
>>
>>The patch declares three extra configuration file parameters:
>>hbafile= '/etc/postgres/pg_hba.conf'
>>identfile='/etc/postgres/pg_ident.conf'
>>datadir='/RAID0/postgres'
>>
>>The command line option is a capital 'C,' as in:
>>postmaster -C /etc/postgresql.conf
>>
>>I have no problem leaving the default configuration files remaining in
>>the data directory as sort of a maintenance / boot strap sort of thing,
>>so I don't see any reason to alter the installation.
>>
>>
>>As for this feature helping or not, I think it will. I think it
>>accomplishes two things:
>>(1) Separates configuration from data.
>>(2) Allows an administrator to create a convention across multiple
>>systems regardless of the location and mount points of the database storage.
>>(3) Lastly, it is a familiar methodology to DBAs not familiar with
>>PostgreSQL.
>>
>>
>
>I agree on all these points ("I think the feature is worthwhile, but...").
>I just wonder if we were going to do this, we might as well look at all of
>the various things people want and decide what we want to do, for example,
>people commenting on default configuration locations through configure,
>how does this interact with what we have now, etc. I'd rather have a
>month spent arguing out a behavior rather than just adding a new behavior
>that we'll need to possibly revisit again in the future. :)
>

I have absolutely no problem debating and augmenting the feature. None
what so ever, I am more pushing to get momentum to actually do it. In
7.1 I proposed this, and was told that it wasn't needed because (a)
symlinks provide all the functionality you need and (b) that they were
going to redesign the configuration system. That was well over a year
ago (two?). I am willing to do the work, but what's the point if the
core group isn't even going to use it?

Most of the admins I know don't use symlinks as they can not carry
comments. Without knowing, you can change or delete a file that does
not appear to be in use but which kills a working server. Symlinks are
dangerous in production systems, it is easy to screw them up with scp
when administering a cluster of computers.

>
>