Re: location of the configuration files

> 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?"