Re: location of the configuration files - Mailing list pgsql-hackers

> On 13 Feb 2003, Oliver Elphick wrote:
> 
> > What your comments strongly suggest to me is that projects like
> > PostgreSQL and pine, along with everything else, should comply with FHS;
> > then there will be no confusion because everyone will be following the
> > smae standards.  Messes arise when people ignore standards; we have all
> > seen the dreadful examples of MySQL and the Beast, haven't we?
> 
> Actually FHS says the opposite.  If the distribution installs PostgreSQL
> then the config files belong in /etc/postgresql.  If the admin does then
> they belong in /usr/local/etc/postgresql.  FHS is out of their tree.  If
> PostgreSQL or any other package is not critical to the basic operation of
> the operating system, it's config files shouldn't be polluting /etc.

I suspect you may be conflating BSD usage with Linux usage here...

The point isn't of being "critical to basic operation of the operating 
system;" it is of whether or not the software is being "package-managed" or 
not.

One of the operating principles in FHS is that "/usr/local" is an area that 
the distribution should never "pollute."  And so, a "package-managed" 
PostgreSQL installation should never touch that area.

Looking at FHS, for a moment: http://www.pathname.com/fhs/2.2/

3.7.1 Purpose
/etc contains configuration files and directories that are specific to the 
current system.

3.7.4  Indicates that 

"Host-specific configuration files for add-on application software packages 
must be installed within the directory /etc/opt/<package>, where <package> is 
the name of the subtree in /opt where the static data from that package is 
stored."

3.12 indicates: /opt is reserved for the installation of add-on application 
software packages.

A package to be installed in /opt must locate its static files in a separate 
/opt/<package> directory tree, where <package> is a name that describes the 
software package.

Then comes 5.1, on /var

/var contains variable data files. This includes spool directories and files, 
administrative and logging data, and transient and temporary files.

It would make most sense, based on FHS, for PostgreSQL information to 
assortedly reside in:

- /etc/opt/postgresql or /etc/postgresql, for static config information;
- Binaries could assortedly live in /usr/bin or /opt/postgresql;
- Logs should live in /var/log or /var/log/postgresql;
- Data could assortedly live in /var/lib/postgresql, /var/opt/postgresql;
- PIDs should live in /var/lock or /var/lock/postgresql.

None of these choices should come as any spectacular shock to anyone; there 
are an assortment of sets of bigotry out there surrounding the Proper Purposes 
of /opt and /usr/local, and there's probably enough wriggle room there to 
avoid overly enraging anyone that (for instance) felt calling a directory 
"/opt" would make someone deserving of carpet bombing by B-52s.

Interestingly, the Debian install of PostgreSQL somewhat resembles this, with, 
assortedly:

/etc/postgresql
/etc/postgresql/postgresql.conf
/etc/postgresql/postmaster.conf
/etc/postgresql/pg_hba.conf
/etc/postgresql/pg_ident.conf
/etc/init.d/postgresql
/usr/share/doc/postgresql
/usr/share/man/man1/pg_ctl.1.gz
/usr/lib/postgresql
/usr/lib/postgresql/bin/postgres
/usr/lib/postgresql/bin/enable_lang
/usr/lib/postgresql/bin/initdb
/usr/lib/postgresql/bin/initlocation
/usr/lib/postgresql/bin/ipcclean
/usr/lib/postgresql/bin/pg_ctl
/usr/lib/postgresql/bin/pg_dumpall
/var/run/postgresql

(This is obviously incomplete; this just gives the flavor that there are files 
in a reasonably rational but diverse assortment of places.)

Note that the server software hides in /usr/lib/postgresql/bin; it's not stuff 
you should normally run from the command line, so, quel surprise, it is 
stashed somewhere that's unlikely to be in your $PATH.

Stashing _everything_ in /var/lib/postgres would seem a tad surprising.

Mind you, if I need to manage 4 instances on one box, I might very well 
install several instances some place custom, say /opt/postgres, or similar, 
and in that case, it's probably preferable for everything to reside clearly 
underneath that, and for my custom backup scripts to work in that area.

But if I'm managing 4 instances on one box, it should be quite evident that 
I'm going well beyond what any packaging system is likely to be prepared to 
handle.  Again, quel surprise.
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/linuxxian.html
"Of  _course_ it's the murder weapon.   Who would frame someone with a
fake?"