location of the configuration files
The debate on the configuration file sparked a memory of an old patch I
submitted in 7.1 days.
One of the things I do not like about PostgreSQL is, IMHO, is a
backwards configuration process. Rather than specify a data directory,
the administrator should specify a database configuration file. Within
the configuration file is the location and names of the data directory
and other information. Most admins want a central location for this
information.
One of the things that is frustrating to me, is to have to hunt down
where the data directory is so that I can administrate a DB. It can be
anywhere, in any directory on any volume. If you had, say, a
/usr/local/pgsql/admin, then you could have mydb.conf which could then
be checked in to CVS. A standard location for configuration files is a
more normal process as the location of the data directory is less so. I
just don't think the PG data directory should not contain configuration
information.
The original patch allowed a user to specify the location of the
postgresql.conf file, rather than assuming it lived in $PGDATA
Also included in that patch, was the ability to specify the location of
the PGDATA directory as well as the names of the pg_hba.conf and other
configuration files.
It also allowed the user to use PG as it has always worked, The patch
was not applied because a better solution was supposedly coming, but
that was two major revisions ago. I would still like to see this
functionality. Would anyone else?
On Tue, 2003-02-11 at 13:44, mlw wrote:
The debate on the configuration file sparked a memory of an old patch I
submitted in 7.1 days.One of the things I do not like about PostgreSQL is, IMHO, is a
backwards configuration process. Rather than specify a data directory,
the administrator should specify a database configuration file. Within
the configuration file is the location and names of the data directory
and other information. Most admins want a central location for this
information.One of the things that is frustrating to me, is to have to hunt down
where the data directory is so that I can administrate a DB. It can be
anywhere, in any directory on any volume. If you had, say, a
/usr/local/pgsql/admin, then you could have mydb.conf which could then
be checked in to CVS. A standard location for configuration files is a
more normal process as the location of the data directory is less so. I
just don't think the PG data directory should not contain configuration
information.The original patch allowed a user to specify the location of the
postgresql.conf file, rather than assuming it lived in $PGDATA
Also included in that patch, was the ability to specify the location of
the PGDATA directory as well as the names of the pg_hba.conf and other
configuration files.It also allowed the user to use PG as it has always worked, The patch
was not applied because a better solution was supposedly coming, but
that was two major revisions ago. I would still like to see this
functionality. Would anyone else?
I'm going to be lazy and ask if you can post what the better solution
that was coming was (or a link to the thread). While I'll grant you that
the "it's coming" argument is pretty weak after two releases, that fact
that it may have been a better solution could still hold up.
Robert Treat
Robert Treat wrote:
I'm going to be lazy and ask if you can post what the better solution
that was coming was (or a link to the thread). While I'll grant you that
the "it's coming" argument is pretty weak after two releases, that fact
that it may have been a better solution could still hold up.Robert Treat
AFAIK it wasn't actually done. It was more of a, "we should do something
different" argument. At one point it was talked about rewriting the
configuration system to allow "include" and other things.
I, personally, also think it makes more sense to pass to the postmaster
a configuration file that contains all the rest of the information about
the database system, including the disk locations of the various data
directories and whatnot.
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
mlw wrote:
AFAIK it wasn't actually done. It was more of a, "we should do something
different" argument. At one point it was talked about rewriting the
configuration system to allow "include" and other things.
That seems like extreme overkill. The PostgreSQL configuration
mechanism doesn't seem to me to be anywhere near complicated enough to
justify an "include" mechanism.
I agree with you: you should be able to specify all of the base
configuration information (including the location of the data
directories) in one file, and it makes perfect sense to me for the
location of the data directory to be a GUC variable.
I'd say the only thing the postmaster needs to know prior to startup
is the directory containing the postgresql.conf file. An
administrator who wishes to set up multiple independent databases can
easily do so by using multiple config file directories. When
consistency is required, he can easily use symlinks to point to master
config files where appropriate.
I assume $PGDATA was around long before GUC?
--
Kevin Brown kevin@sysexperts.com
Kevin Brown <kevin@sysexperts.com> writes:
I assume $PGDATA was around long before GUC?
Yes, it was. But I have not yet seen an argument here that justifies
why $SOMECONFIGDIRECTORY/postgresql.conf is better than
$PGDATA/postgresql.conf. The latter keeps all the related files
together. The former seems only to introduce unnecessary complexity.
You can only justify it as simpler if you propose hardwiring a value for
$SOMECONFIGDIRECTORY ... which is a proposal that will not fly with any
of the core developers, because we all run multiple versions of Postgres
on our machines so that we can deal with back-version bug reports,
test installations, etc. It is unlikely to fly with any of the RPM
packagers either, due to the wildly varying ideas out there about the
One True Place where applications should put their config files.
(This point was pretty much why mlw's previous proposal was rejected,
IIRC.)
regards, tom lane
Tom Lane wrote:
Kevin Brown <kevin@sysexperts.com> writes:
I assume $PGDATA was around long before GUC?
Yes, it was. But I have not yet seen an argument here that justifies
why $SOMECONFIGDIRECTORY/postgresql.conf is better than
$PGDATA/postgresql.conf.
Okay, here's one: most Unix systems store all of the configuration
files in a well known directory: /etc. These days it's a hierarchy of
directories with /etc as the root of the hierarchy. When an
administrator is looking for configuration files, the first place he's
going to look is in /etc and its subdirectories. After that, he's
forced to look through the startup scripts to figure out where things
are located. And if those aren't revealing, then he has to read
manpages and hope they're actually useful. :-) And if that doesn't
work, then he has to resort to tricks like doing "strings" on the
binaries (he doesn't necessarily have access to the sources that the
binaries were compiled from, which is all that matters here).
The latter keeps all the related files together. The former seems
only to introduce unnecessary complexity.
Well, I'd say it's "unnecessary" only when you already know where the
data files are located -- which is true when you're a developer or
someone who is already familiar with the installation you're working
with. But if you're just getting started and installed it from a
package like an RPM file, then you have to look in the package to see
where it created the data file areas, or look at the startup scripts,
etc.
You can only justify it as simpler if you propose hardwiring a value
for $SOMECONFIGDIRECTORY ...
Making things simpler from the standpoint of the code isn't the point.
Making things simpler for the DBA and/or Unix sysadmin is.
I'd say $SOMECONFIGDIRECTORY should be a hardwired default with a
command line override.
I doubt you'll get a whole lot of argument from the general user
community if you say that the hard wired default should be
/etc/postgresql.
which is a proposal that will not fly with any of the core
developers, because we all run multiple versions of Postgres on our
machines so that we can deal with back-version bug reports, test
installations, etc.
I absolutely agree that the config directory to use should be
something that can be controlled with a command line option.
It is unlikely to fly with any of the RPM packagers either, due to
the wildly varying ideas out there about the One True Place where
applications should put their config files.
There seems to be substantial agreement among the distribution
maintainers that config files belong somewhere in /etc. At least,
I've seen very little disagreement with that idea except from people
who believe that each package should have its own, separate directory
hierarchy. And the fact that the vast majority of packages put their
config files somewhere in /etc supports this.
Debian, for instance, actually *does* put the PostgreSQL config files
in /etc/postgresql and creates symlinks in the data directory that
point to them. This works, but it's a kludge.
There are highly practical reasons for putting all the config files
under /etc, not the least of which is that it makes backing up files
that are *very* likely to change from the default, and which are also
highly critical to the operation of the system, very easy.
You'll get A LOT more disagreement about where to put data files than
config files, as standards go. And in the case of PostgreSQL, where
you put your data files is especially important for performance
reasons, so it therefore makes even less sense to put the config files
in the same location: it means that the config files could literally
be anywhere, and any administrator who is unfamiliar with the system
will have to dig through startup scripts (or worse!) to figure it out.
Oh, here's another reason $SOMECONFIGDIRECTORY is better than $PGDATA:
it allows much more appropriate separation of concern by default.
Most installations of PostgreSQL start the database from a startup
script that's run at boot time. With $PGDATA, changing the target
data directory requires changing the startup script, which requires
root access to the system -- if it didn't require root access then the
entire system is open to the possibility of a world of hurt because
the DBA isn't necessarily the same guy as the Unix sysadmin and
therefore doesn't necessarily know his way around shell scripts in
general, and rc scripts in particular, the way the Unix admin will.
The possibility of hurt comes from the fact that the rc script runs at
root, at a time that the system is hardest to work with in the event
of a failure (many systems haven't even put up any console login
prompts and may not have even started any remote login facilities
before the PostgreSQL startup script runs). A sufficiently bad
screwup on the part of the DBA with that kind of setup will require
the Unix sysadmin to go to single user mode or worse to fix it. So
unless the Unix sysadmin really trusts the DBA, he's not going to
allow the DBA that kind of access. Instead he'll kludge something
together so that the DBA can make the appropriate kinds of changes
without compromising the system. But every shop will do this a
different way. Even Debian, which usually is pretty good about
dealing with issues like these, doesn't address this.
But it shouldn't even be necessary for a shop to kludge around the
problem: with $SOMECONFIGDIRECTORY, the Unix sysadmin can safely give
write permissions to the DBA on the config files (and even on the
entire directory they reside in), the DBA can point the database at
whatever directory he wants the data to reside in, and the Unix admin
only has to set up the storage areas, set the permissions, and let the
DBA loose on it -- he doesn't have to touch the startup scripts at
all, the DBA doesn't have to be much of a shell script wizard, and
everyone is (relatively) happy. And, even better, the DBA will be
able to do this at most shops he works for because his knowledge will
be based on the standard PostgreSQL install.
If we want to get wider acceptance amongst the heavy database users
(which often *do* separate DBAs from Unix sysadmins), we may want to
think about things like this from time to time...
--
Kevin Brown kevin@sysexperts.com
On Wed, 2003-02-12 at 08:24, Kevin Brown wrote:
Tom Lane wrote:
You can only justify it as simpler if you propose hardwiring a value
for $SOMECONFIGDIRECTORY ...Making things simpler from the standpoint of the code isn't the point.
Making things simpler for the DBA and/or Unix sysadmin is.I'd say $SOMECONFIGDIRECTORY should be a hardwired default with a
command line override.I doubt you'll get a whole lot of argument from the general user
community if you say that the hard wired default should be
/etc/postgresql.which is a proposal that will not fly with any of the core
developers, because we all run multiple versions of Postgres on our
machines so that we can deal with back-version bug reports, test
installations, etc.I absolutely agree that the config directory to use should be
something that can be controlled with a command line option.It is unlikely to fly with any of the RPM packagers either, due to
the wildly varying ideas out there about the One True Place where
applications should put their config files.There seems to be substantial agreement among the distribution
maintainers that config files belong somewhere in /etc. At least,
I've seen very little disagreement with that idea except from people
who believe that each package should have its own, separate directory
hierarchy. And the fact that the vast majority of packages put their
config files somewhere in /etc supports this.Debian, for instance, actually *does* put the PostgreSQL config files
in /etc/postgresql and creates symlinks in the data directory that
point to them. This works, but it's a kludge.
Seems like a good compromise would be to make the hard wired default
$SOMECONFIGDIRECTORY be $PGDATA; this makes each version of the software
more self contained/ less likely to interfere with another installation.
(This becomes really handy when doing major upgrades). If you really
have a strong desire to change this, you can.
As I see it, this change would (should?) need to be something that could
be changed in the configure script when building postgresql, as well
changeable via a command line option, any other places?
Robert Treat
Okay, here's one: most Unix systems store all of the configuration
files in a well known directory: /etc. These days it's a hierarchy of
directories with /etc as the root of the hierarchy. When an
administrator is looking for configuration files, the first place he's
going to look is in /etc and its subdirectories. After that, he's
forced to look through the startup scripts to figure out where things
are located. And if those aren't revealing, then he has to read
manpages and hope they're actually useful. :-) And if that doesn't
work, then he has to resort to tricks like doing "strings" on the
binaries (he doesn't necessarily have access to the sources that the
binaries were compiled from, which is all that matters here).
No goddammit - /usr/local/etc. Why can't the Linux community respect
history!!!!
It is the ONE TRUE PLACE dammit!!!
Chris
(btw, there is humour + seriousness in above post...)
binaries (he doesn't necessarily have access to the sources that the
binaries were compiled from, which is all that matters here).No goddammit - /usr/local/etc. Why can't the Linux community respect
history!!!!
History? It's the only way to make a read-only / (enforced by
secure-level) and still be able to change the user applications.
I don't mind /usr/X11R6/etc either, but it's not exactly appropriate for
PostgreSQL ;)
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> wrote:
Okay, here's one: most Unix systems store all of the configuration
files in a well known directory: /etc. These days it's a hierarchy of
directories with /etc as the root of the hierarchy. When an
administrator is looking for configuration files, the first place he's
going to look is in /etc and its subdirectories.
No goddammit - /usr/local/etc. Why can't the Linux community respect
history!!!!It is the ONE TRUE PLACE dammit!!!
Well, to the extent that you're serious, you understand that
a lot of people feel that /usr/local should be reserved for
stuff that's installed by the local sysadmin, and your
vendor/distro isn't supposed to be messing with it.
Which means if the the vendor installed Postgresql (say, the
Red Hat Database) you'd expect config files to be in /etc.
If the postgresql is compiled from source by local admin,
you might look somewhere in /usr/local.
I've got the vauge feeling that this is all more than a
little silly... directory locations floating about depending
on who did what, as thought it were such a radical thing
to do a ./configure, make & make install. But this is a
pretty common feeling among the unix world (more wide spread
than just in the Linux world).
On Wednesday 12 February 2003 20:37, Christopher Kings-Lynne wrote:
Okay, here's one: most Unix systems store all of the configuration
files in a well known directory: /etc. These days it's a hierarchy of
No [snip] - /usr/local/etc. Why can't the Linux community respect
history!!!!
It is the ONE TRUE PLACE [snip]
If PostgreSQL is supported as a part of the base operating system in a Linux
distribution, and that distribution wishes to be Linux Standards Base
compliant (most do), then PostgreSQL cannot go in /usr/local -- period.
IDIC at work.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Tom Lane wrote:
Kevin Brown <kevin@sysexperts.com> writes:
I assume $PGDATA was around long before GUC?
Yes, it was. But I have not yet seen an argument here that justifies
why $SOMECONFIGDIRECTORY/postgresql.conf is better than
$PGDATA/postgresql.conf. The latter keeps all the related files
together. The former seems only to introduce unnecessary complexity.
You can only justify it as simpler if you propose hardwiring a value for
$SOMECONFIGDIRECTORY ... which is a proposal that will not fly with any
of the core developers, because we all run multiple versions of Postgres
on our machines so that we can deal with back-version bug reports,
test installations, etc. It is unlikely to fly with any of the RPM
packagers either, due to the wildly varying ideas out there about the
One True Place where applications should put their config files.(This point was pretty much why mlw's previous proposal was rejected,
IIRC.)
I wasn't talking about a "default directory" I was talking about
configuring a database in a configuration file.
While I accept that the PostgreSQL group can not be playing catch-up
with other databases, this does not preclude the notion accepting common
practices and adopting them.
Understand, I really like PostgreSQL. I like it better than Oracle, and
it is my DB of choice. That being said, I see what other DBs do right.
Putting the configuration in the data directory is "wrong," no other
database or service under UNIX or Windows does this, Period.
Does the PostgreSQL team know better than the rest of the world?
The idea that a, more or less, arbitrary data location determines the
database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the "right" way to do it. Regardless of where ever you choose
to put the default configuration file, it is EASIER to configure a
database by using a file in a standard configuration directory (/etc,
/usr/etc, /usr/local/etc, /usr/local/pgsql/conf or what ever). The data
directory should not contain configuration data as it is typically
dependent on where the admin chooses to mount storage.
I am astounded that this point of view is missed by the core group.
Mark.
mlw <pgsql@mohawksoft.com> writes:
The idea that a, more or less, arbitrary data location determines the
database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the "right" way to do it.
I guess I'm just dense, but I entirely fail to see why this is the One
True Way To Do It. What you seem to be proposing (ignoring
syntactic-sugar issues) is that we replace "postmaster -D
/some/data/dir" by "postmaster -config /some/config/file". I am not
seeing the nature of the improvement. It looks to me like the sysadmin
must now grant the Postgres DBA write access on *two* directories, viz
/some/config/ and /wherever/the/data/directory/is. How is that better
than granting write access on one directory? Given that we can't manage
to standardize the data directory location across multiple Unixen, how
is it that we will be more successful at standardizing a config file
location?
All I see here is an arbitrary break with our past practice. I do not
see any net improvement.
regards, tom lane
Tom Lane wrote:
mlw <pgsql@mohawksoft.com> writes:
The idea that a, more or less, arbitrary data location determines the
database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the "right" way to do it.I guess I'm just dense, but I entirely fail to see why this is the One
True Way To Do It. What you seem to be proposing (ignoring
syntactic-sugar issues) is that we replace "postmaster -D
/some/data/dir" by "postmaster -config /some/config/file". I am not
seeing the nature of the improvement. It looks to me like the sysadmin
must now grant the Postgres DBA write access on *two* directories, viz
/some/config/ and /wherever/the/data/directory/is. How is that better
than granting write access on one directory? Given that we can't manage
to standardize the data directory location across multiple Unixen, how
is it that we will be more successful at standardizing a config file
location?All I see here is an arbitrary break with our past practice. I do not
see any net improvement.
There is a pretty well understood convention that a configuration file
will be located in some standard location depending on your distro.
Would you disagree with that?
There is also a convention that most servers are configured by a
configuration file, located in a central location. Look at sendmail,
named,, et al.
Here is the test, configure a server, with sendmail, named, apache, and
PostgreSQL. Tell me which of these systems doesn't configure right.
At 12:31 AM -0500 2/13/03, mlw wrote:
The idea that a, more or less, arbitrary data location determines
the database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the "right" way to do it.
Isn't the database data itself a rather significant portion of the
'configuration' of the database?
What do you gain by having the postmaster config and the database
data live in different locations?
-pmb
Peter Bierman wrote:
At 12:31 AM -0500 2/13/03, mlw wrote:
The idea that a, more or less, arbitrary data location determines the
database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the "right" way to do it.Isn't the database data itself a rather significant portion of the
'configuration' of the database?What do you gain by having the postmaster config and the database data
live in different locations?
While I don't like to use another product as an example, I think amongst
the number of things Oracle does right is that it has a fairly standard
way for an admin to find everything. All one needs to do is find the
"ORACLE_HOME" directory, and everything can be found from there.
If, assume, PostgreSQL worked like every other system. It would have
either an entry in /etc or some other directory specified by configure.
Somene please tell me how what I'm proposing differs from things like
sendmail, named, or anyother standards based UNIX server?
Before I get started, I should note that it may be a good compromise
to have the data directory be the same as the config file directory,
when neither the config file nor the command line specify something
different. So the changes I think may make the most sense are:
1. We add a new GUC variable which specifies where the data is.
The data is assumed to reside in the same place the config files
reside unless the GUC variable is defined (either in
postgresql.conf or on the command line, as usual for a GUC
variable). Both -D and $PGDATA therefore retain their current
semantics unless overridden by the GUC variable, in which case
they fall back to the new semantics of specifying only where the
config files can be found.
2. We add a configure option that specifies what the hardcoded
fallback directory should be when neither -D nor $PGDATA are
specified: /etc/postgresql when the option isn't specified to
configure.
3. We supply a different default startup script and a different
default configuration file (but can make the older versions
available in the distribution as well if we wish). The former
uses neither $PGDATA nor -D (or uses /etc/postgresql for them),
and the latter uses the new GUC variable to specify a data
directory location (/var/lib/postgres by default?)
This combination should work nicely for transitioning and for package
builders. It accomplishes all of the goals mentioned in this thread
and will cause minimal pain for developers, since they can use their
current methods. Sounds like it'll make Tom happy, at least. :-)
Tom Lane wrote:
mlw <pgsql@mohawksoft.com> writes:
The idea that a, more or less, arbitrary data location determines the
database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the "right" way to do it.I guess I'm just dense, but I entirely fail to see why this is the One
True Way To Do It.
But we're not saying it's the One True Way, just saying that it's a
way that has very obvious benefits over the way we're using now, if
your job is to manage a system that someone else set up.
What you seem to be proposing (ignoring syntactic-sugar issues) is
that we replace "postmaster -D /some/data/dir" by "postmaster
-config /some/config/file". I am not seeing the nature of the
improvement.
The nature of the improvement is that the configuration of a
PostgreSQL install will becomes obvious to anyone who looks in the
obvious places. Remember, the '-D ...' is optional! The PGDATA
environment variable can be used instead, and *is* used in what few
installations I've seen. That's not something that shows up on the
command line when looking at the process list, which forces the
administrator to hunt down the data directory through other means.
It looks to me like the sysadmin must now grant the Postgres DBA
write access on *two* directories, viz /some/config/ and
/wherever/the/data/directory/is. How is that better than granting
write access on one directory?
The difference in where you grant write access isn't a benefit to be
gained here. The fact that you no longer have to give root privileges
to the DBA so that he can change the data directory as needed is the
benefit (well, one of them, at least). A standard packaged install
can easily set the /etc/postgresql directory up with write permissions
for the postgres user by default, so the sysadmin won't even have to
touch it if he doesn't want to.
A big production database box is usually managed by one or more system
administrators and one or more DBAs. Their roles are largely
orthogonal. The sysadmins have the responsibility of keeping the
boxes up and making sure they don't fall over or crawl to a
standstill. The DBAs have the responsibility of maximizing the
performance and availability of the database and *that's all*. Giving
the DBAs root privileges means giving them the power to screw up the
system in ways that they can't recover from and might not even know
about. The ways you can take down a system by misconfiguring the
database are bad enough. No sane sysadmin is going to give the DBA
the power to run an arbitrary script as root at a time during the boot
cycle that the system is the most difficult to manage unless he thinks
the DBA is *really* good at system administration tasks, too. And
that's assuming the sysadmin even *has* the authority to grant the DBA
that kind of access. Many organizations keep a tight rein on who can
do what in an effort to minimize the damage from screwups.
The point is that the DBA isn't likely to have root access to the box.
When the DBA lacks that ability, the way we currently do things places
greater demand on the sysadmin than is necessary, because root access
is required to change the startup scripts, as it should be, and the
location of the data, as it should *not* be.
Given that we can't manage to standardize the data directory
location across multiple Unixen, how is it that we will be more
successful at standardizing a config file location?
A couple of ways.
Firstly, as we mentioned before, just about every other daemon that
runs on a Unix system has its configuration file somewhere in the /etc
hierarchy. By putting our config files in that same hierarchy we'll
be *adhering* to a standard. We don't have to worry about
"standardizing" that config file location because it's *already* a
standard that we're currently ignoring.
Secondly, standards arise as a result of being declared standards and
by most people using them. So simply by making /etc/postgresql the
default configuration directory, *that* will become the standard
place. Most people won't mess with the default install if they don't
have to.
Right now they almost *have to* mess with the default install, because
there is no standard place on a Unix system for high speed, highly
reliable disk access. And that means that, right now, there *is* no
standard place for our config files -- it's wherever the person who
configured the database decided the data should be, and he made that
decision based on performance and reliability considerations, not on
any standards.
All I see here is an arbitrary break with our past practice. I do not
see any net improvement.
That's probably because you're looking at this from the point of view
of a developer. From that standpoint there really isn't any net
improvement, because *you* still have to specify something on the
command line to get your test databases going. As a developer you
*always* install and manage your own database installations, so *of
course* you'll always know where the config files are. But that's not
how it works in the production world.
The break we'd be making is *not* arbitrary, and that's much of the
point: it's a break towards existing standards, and there are good
reasons for doing it, benefits to be had by adhering to those
standards.
The way we currently handle configuration files is fine for research
and development use -- the environment from which PostgreSQL sprang.
But now we're talking about getting it used in production
environments, and their requirements are very different.
Since it is *we* who are not currently adhering to the standard,
shouldn't the burden of proof (so to speak) be on those who wish to
keep things as they are?
--
Kevin Brown kevin@sysexperts.com
Well, to the extent that you're serious, you understand that
a lot of people feel that /usr/local should be reserved for
stuff that's installed by the local sysadmin, and your
vendor/distro isn't supposed to be messing with it.Which means if the the vendor installed Postgresql (say, the
Red Hat Database) you'd expect config files to be in /etc.
If the postgresql is compiled from source by local admin,
you might look somewhere in /usr/local.
Indeed. For better or worse, there is a Filesystem Hierarcy Standard,
and most of the important Linux distros, BSDs and some legacy Unixen
stick to it, so so should we.
Configuration files should be in /etc/postgresql/, or at the very least
symlinked from there.
Martin
On Wed, 12 Feb 2003, J. M. Brenner wrote:
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> wrote:
Okay, here's one: most Unix systems store all of the configuration
files in a well known directory: /etc. These days it's a hierarchy of
directories with /etc as the root of the hierarchy. When an
administrator is looking for configuration files, the first place he's
going to look is in /etc and its subdirectories.No goddammit - /usr/local/etc. Why can't the Linux community respect
history!!!!It is the ONE TRUE PLACE dammit!!!
Well, to the extent that you're serious, you understand that
a lot of people feel that /usr/local should be reserved for
stuff that's installed by the local sysadmin, and your
vendor/distro isn't supposed to be messing with it.Which means if the the vendor installed Postgresql (say, the
Red Hat Database) you'd expect config files to be in /etc.
If the postgresql is compiled from source by local admin,
you might look somewhere in /usr/local.
Then why not ~postgres/etc ?? Or substitute ~postgres with the
db admin user you (or the distro) decided on at installation time.
Gives a common location no matter who installed it or where it was
installed.
Vince.
--
Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.
