This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] location of the configuration files Date: Wed, 12 Feb 2003 19:03:33 -0800 From: "J. M. Brenner" <doom@kzsu.stanford.edu> "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 though 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). === Subject: Re: [HACKERS] location of the configuration files From: Oliver Elphick <olly@lfix.co.uk> To: pgsql-hackers@postgresql.org Date: 13 Feb 2003 22:22:56 +0000 On Thu, 2003-02-13 at 21:21, Vince Vielhaber wrote: > I certainly wasn't trying to provoke anything. It just seems odd to me > that when the distribution installs a package and places it's config files > in /etc and later the admin happens to upgrade by the instructions with > the package, it's acceptable for the config files to now be in two places > and you don't find it confusing. What happens when a new admin comes on > and tries to figure out which config file is which? Ever try to figure > out where the hell Pine's config really is? I've not used pine, and there doesn't seem to be an official Debian package, (it doesn't allow any changes to its source, I believe, which makes it ineligible). But if it were an official package, I know I should look in /etc/pine. If the admin installs a local build of something he has installed as a package, he will presumably take care to separate the two. If his local build is to replace the package, he should purge the installed package, so that there are no traces of it left. Since he is administering a distribution installation, it is certainly his responsibility to understand the difference between local and distributed packages, as well as the different places that each should put their configuration files. (Incidentally, Debian's changes from the upstream configuration are documented in the package.) In the end, though, when we package for a distribution, we expect people to use the packages. If they want to build from source, the packages system lets them do it. Anyone who is building from the upstream source must be presumed to know what he is doing and take responsibility for it. 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 same standards. Messes arise when people ignore standards; we have all seen the dreadful examples of MySQL and the Beast, haven't we? === Date: Thu, 13 Feb 2003 18:07:46 -0500 (EST) From: Vince Vielhaber <vev@michvhf.com> To: <pgsql-hackers@postgresql.org> Subject: Re: [HACKERS] location of the configuration files 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. === From: cbbrowne@cbbrowne.com To: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] location of the configuration files In-Reply-To: Message from Vince Vielhaber <vev@michvhf.com> of "Thu, 13 Feb 2003 18:07:46 EST." <Pine.BSF.4.44.0302131805020.96761-100000@paprika.michvhf.com> References: <Pine.BSF.4.44.0302131805020.96761-100000@paprika.michvhf.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Feb 2003 21:45:47 -0500 Message-Id: <20030214024547.3BACD51DB9@cbbrowne.com> X-Virus-Scanned: by AMaViS new-20020517 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-UIDL: nK@"!:+G!!Bh%"!YlY!! > 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. ===