no warning about decoy conf files

[Rick Graves]

Binary package hint: postgresql-8.1

The ubuntu install puts copies of the conf files in the data directory, and buries the real conf files in /etc/postgresql/8.1/main.

As an administrator, I found the conf files in the data directory, but I did not find the real conf files in /etc/postgresql/8.1/main -- too deep.

Editing the conf files in the data directory does not work; see:

http://ubuntuforums.org/showthread.php?p=3344958#post3344958

In an ideal world, if you are going to plant decoy copies of the configuration files in a location an administrator is likely to find, with the decoy copies should be a README that tells were the real conf files are located.

Thanks,

[Martin Pitt (pitti)]

What do you mean by 'decoy files'? There are no fake postgresql.conf etc. files in the data directory.

I am happy to add a small README.configuration to the data directory which points to the configuration files in /etc/. Do you mean that?

[Rick Graves (gravesricharde)]

Martin,

I installed postgresql 8.1, and there were duplicate copies of all the conf files (postgresql.conf, etc.) in the data directory.

They are "decoys" in the sense that I found those first, but editing them had no effect.

> I am happy to add a small README.configuration to
> the data directory
> which points to the configuration files in /etc/. Do
> you mean that?

That would solve the problem that I encountered.

Thanks,

Rick

[Rick Graves (gravesricharde)]

Martin,

> I am happy to add a small README.configuration to
> the data directory
> which points to the configuration files in /etc/.

Part of my problem was the conf files were not just in
/etc/postgresql, but in /etc/postgresql/8.1/main (so
deep, I found the conf files in the data directory
instead).

What installation instructions should I be following?

Thanks,

Rick

--- Martin Pitt <email address hidden> wrote:

> What do you mean by 'decoy files'? There are no fake
> postgresql.conf
> etc. files in the data directory.
>
> I am happy to add a small README.configuration to
> the data directory
> which points to the configuration files in /etc/. Do
> you mean that?
>
>
> ** Changed in: postgresql-common (Ubuntu)
> Sourcepackagename: postgresql-8.1 =>
> postgresql-common
> Importance: Undecided => Low
> Status: New => Incomplete
>
> --
> no warning about decoy conf files
> https://bugs.launchpad.net/bugs/138793
> You received this bug notification because you are a
> direct subscriber
> of the bug.
>

[Martin Pitt (pitti)]

Hi Rick,

Rick Graves [2007-10-24 3:34 -0000]:
> Part of my problem was the conf files were not just in
> /etc/postgresql, but in /etc/postgresql/8.1/main

This is because we support multiple versions in parallel, and also
multiple clusters (instances) of one version in parallel. Please see
/usr/share/doc/postgresql-common/README.gz.

> deep, I found the conf files in the data directory
> instead).

This would be one major part of the bug. It does not happen on Ubuntu
Feisty/Gutsy and Debian Etch/unstable. Please give me the output of

  dpkg -l 'postgres*' | grep ^ii
  lsb_release -d

Thanks,

Martin

[Rick Graves (gravesricharde)]

Martin,

> Please give me the output of
>
> dpkg -l 'postgres*' | grep ^ii
> lsb_release -d

I am traveling now (out of the office). I will get
back next week, and I can send the info then.

I did the installs from the 6.06 LTS server CD.

What installation instructions should I follow when I
set up a postgresql server using the 6.06 LTS server
CD?

Rick

--- Martin Pitt <email address hidden> wrote:

> Hi Rick,
>
> Rick Graves [2007-10-24 3:34 -0000]:
> > Part of my problem was the conf files were not
> just in
> > /etc/postgresql, but in /etc/postgresql/8.1/main
>
> This is because we support multiple versions in
> parallel, and also
> multiple clusters (instances) of one version in
> parallel. Please see
> /usr/share/doc/postgresql-common/README.gz.
>
> > deep, I found the conf files in the data directory
> > instead).
>
> This would be one major part of the bug. It does not
> happen on Ubuntu
> Feisty/Gutsy and Debian Etch/unstable. Please give
> me the output of
>
> dpkg -l 'postgres*' | grep ^ii
> lsb_release -d
>
> Thanks,
>
> Martin
>
> --
> no warning about decoy conf files
> https://bugs.launchpad.net/bugs/138793
> You received this bug notification because you are a
> direct subscriber
> of the bug.
>

[Rick Graves (gravesricharde)]

Martin,

Having just run this again, I can report that the conf
files are deposited in the data directory when you run
initdb.

Also, for the postgresql server to start, I must copy
server.crt, server.key and root.crt from
/var/lib/postgresql/8.1/main to the data directory,
and change the owner of those files to postgres.
Otherwise, no go.

> dpkg -l 'postgres*' | grep ^ii

I get postgresql-8.1, postgresql-client-8.1,
postgresql-common, and postgresql-client-common. The
first two are version 8.1.9-0ubuntu0.6.06.

> lsb_release -d

Ubuntu 6.06.1 LTS

> It does not happen on Ubuntu
> Feisty/Gutsy and Debian Etch/unstable.

For a database sever, I think most real database
administrators would choose a long term support
version over unstable!

Rick

--- Martin Pitt <email address hidden> wrote:

> Hi Rick,
>
> Rick Graves [2007-10-24 3:34 -0000]:
> > Part of my problem was the conf files were not
> just in
> > /etc/postgresql, but in /etc/postgresql/8.1/main
>
> This is because we support multiple versions in
> parallel, and also
> multiple clusters (instances) of one version in
> parallel. Please see
> /usr/share/doc/postgresql-common/README.gz.
>
> > deep, I found the conf files in the data directory
> > instead).
>
> This would be one major part of the bug. It does not
> happen on Ubuntu
> Feisty/Gutsy and Debian Etch/unstable. Please give
> me the output of
>
> dpkg -l 'postgres*' | grep ^ii
> lsb_release -d
>
> Thanks,
>
> Martin
>
> --
> no warning about decoy conf files
> https://bugs.launchpad.net/bugs/138793
> You received this bug notification because you are a
> direct subscriber
> of the bug.
>

[Martin Pitt (pitti)]

Hi,

Rick Graves [2007-10-31 9:11 -0000]:
> Having just run this again, I can report that the conf
> files are deposited in the data directory when you run
> initdb.

Ah, of course. If you run initdb manually, then you cannot expect the
postgresql-common integration scripts to work magically. The prefered
way is to use pg_createcluster, which will do all this shuffling for
you and register the cluster in the postgresql-common structure, init
scripts, enable the possibility to upgrade it painlessly with
pg_upgradecluster, etc.

But then I wonder how you managed to get the files in /etc/? It seems
that you once had the default 8.1/main cluster, deleted the data
directory in /var/lib, but not the configuration directory in /etc/,
and then used initdb to re-create the data dir in /var/?

> Also, for the postgresql server to start, I must copy
> server.crt, server.key and root.crt from
> /var/lib/postgresql/8.1/main to the data directory,
> and change the owner of those files to postgres.
> Otherwise, no go.

pg_createcluster does all this.

> For a database sever, I think most real database administrators
> would choose a long term support version over unstable!

Absolutely!

[Rick Graves (gravesricharde)]

Martin,

> The prefered way is to use pg_createcluster ....

What installation instructions should I be following?

I do not recall ever hearing of pg_createcluster.

Thanks,

Rick

--- Martin Pitt <email address hidden> wrote:

> Hi,
>
> Rick Graves [2007-10-31 9:11 -0000]:
> > Having just run this again, I can report that the
> conf
> > files are deposited in the data directory when you
> run
> > initdb.
>
> Ah, of course. If you run initdb manually, then you
> cannot expect the
> postgresql-common integration scripts to work
> magically. The prefered
> way is to use pg_createcluster, which will do all
> this shuffling for
> you and register the cluster in the
> postgresql-common structure, init
> scripts, enable the possibility to upgrade it
> painlessly with
> pg_upgradecluster, etc.
>
> But then I wonder how you managed to get the files
> in /etc/? It seems
> that you once had the default 8.1/main cluster,
> deleted the data
> directory in /var/lib, but not the configuration
> directory in /etc/,
> and then used initdb to re-create the data dir in
> /var/?
>
> > Also, for the postgresql server to start, I must
> copy
> > server.crt, server.key and root.crt from
> > /var/lib/postgresql/8.1/main to the data
> directory,
> > and change the owner of those files to postgres.
> > Otherwise, no go.
>
> pg_createcluster does all this.
>
> > For a database sever, I think most real database
> administrators
> > would choose a long term support version over
> unstable!
>
> Absolutely!
>
> --
> no warning about decoy conf files
> https://bugs.launchpad.net/bugs/138793
> You received this bug notification because you are a
> direct subscriber
> of the bug.
>

[Martin Pitt (pitti)]

Rick Graves [2007-10-31 13:27 -0000]:
> What installation instructions should I be following?
> I do not recall ever hearing of pg_createcluster.

Please see /usr/share/postgresql-common/README.Debian.gz for an intro.

[Rick Graves (gravesricharde)]

Martin,

> Please see
> /usr/share/postgresql-common/README.Debian.gz for an
> intro.

I find a file named README.Debian.gz here:

/usr/share/doc/postgresql-8.2/

I had to unzip it to a tmp directory to read it. It
mentions pg_createcluster, but in no way makes clear
that pg_createcluster should be used to set up a new
database, and gives no step-by-step instructions.

Pertaining to the instructions that I found and
followed, anyone can find those by googling "install
postgresql" without the quotes and hit "I'm feeling
lucky" (at least the "I'm feeling lucky" part is
working for me right now). That would be these:

http://www.postgresql.org/docs/8.0/interactive/installation.html

From there, one can also easily find these by filling
in the version number of your choice:

http://www.postgresql.org/docs/8.1/interactive/installation.html
http://www.postgresql.org/docs/8.2/interactive/install-short.html

So it seems the installation instructions one can
easily find don't work, and the installation
instructions one should follow are unclear and lost
somewhere in the directory structure anyway.

Should I file another bug on inadequate installation
instructions?

It seems adequate instructions are lacking, and if
that is the case, I would be willing to pitch in and
write better ones if arrangements could be made to get
the instructions in front of people actually when they
install postgresql on ubuntu and/or Debian.

Thanks,

Rick

--- Martin Pitt <email address hidden> wrote:

> Rick Graves [2007-10-31 13:27 -0000]:
> > What installation instructions should I be
> following?
> > I do not recall ever hearing of pg_createcluster.
>
> Please see
> /usr/share/postgresql-common/README.Debian.gz for an
> intro.
>
> --
> no warning about decoy conf files
> https://bugs.launchpad.net/bugs/138793
> You received this bug notification because you are a
> direct subscriber
> of the bug.
>

[Martin Pitt (pitti)]

Hi Rick,

Rick Graves [2007-11-01 21:28 -0000]:
> So it seems the installation instructions one can
> easily find don't work

Well, they do work. If you stay on upstream's path, then things will
work, but then of course you cannot expect the distro integration bits
to work (like automatic startup in the init scripts, upgrading,
logging into the proper places, default configuration for log
rotation, etc.).

> Should I file another bug on inadequate installation
> instructions?

You can do, or we just retitle this one (which is preferable, I
think).

> It seems adequate instructions are lacking, and if
> that is the case, I would be willing to pitch in and
> write better ones if arrangements could be made to get
> the instructions in front of people actually when they
> install postgresql on ubuntu and/or Debian.

I'd be absolutely happy to improve this. The question is, where to do
it? So far I deliberately don't put the initdb programs into the
$PATH, but pg_* tools are in the path. Would it have helped you if
there was an initdb in the path which told you about the distro tools?

We could also patch the upstream initdb itself to point out
pg_createcluster maybe.

Pitti

[Rick Graves (gravesricharde)]

Martin,

I would like to run my history by you. I was using
postgresql-7.4 before I switched to ubuntu (I am a
refugee from RedHat). After I upgraded my workstation
to the latest and greatest from ubuntu and installed
the postgresql client, I got messages that the version
8 client does not work right with the version 7
server. So when the data drive on my postgresql-7.4
server died, it seemed like an ideal time to set up a
new postgresql-8 server and migrate the data over
(yes, I was fully backed up, and you have to migrate
the data anyway when you upgrade postgresql).

As of Wednesday, my new postgresql-8 server is now
working. (My almost three week gap with no working
database server was mostly the fault of factors other
than less than ideal installation instructions.)

> > So it seems the installation instructions one can
> > easily find don't work
>
> Well, they do work.

I disagree. If you follow the instructions on the
postgresql.org site, the server cannot start. I had
to figure out from error messages to find server.crt,
server.key and root.crt, and that I had to copy them
to the data directory, etc. For my money, the
instructions on postgresql.org site do not work on an
install from the ubuntu 6.06 server CD.

You are assuming that one must set up a new cluster,
but (according to the pg_createcluster man page), "The
default cluster that is created on installation of a
server package is main." I want to use main -- I do
not want to set up a different cluster (such as
"testing" and the other examples on the man page do
not register for me).

I am not aware of any problem with using main (other
than there are no working installation instructions).
My new postgresql-8 server is using main and it seems
to be working OK.

So if there is no problem with using the main cluster,
there should be installation instructions for doing
that. That would be the simple server installation.
Setting up additional clusters is a more advanced
installation, and those instructions could be separate
from the simple install.

> So far I deliberately don't put the initdb
> programs into the
> $PATH, but pg_* tools are in the path. Would it have
> helped you if
> there was an initdb in the path which told you about
> the distro tools?

The postgresql.org instructions put the full path on
initdb, so I do not think that putting pg_* tools in
the path will be a clue to most administrators.
(Because the postgresql.org instructions put the full
path on initdb, it never occurred to me to examine
what was in the path.)

Perhaps the objective should be make the
postgresql.org instructions work using the main
cluster without having to figure out how to get the
server started. I think the vast majority of
administrators will know to ignore the part about
compiling the source, but I think the rest of the
instructions here should work:

http://www.postgresql.org/docs/8.0/interactive/installation.html

What do you think?

Thanks,

Rick

--- Martin Pitt <email address hidden> wrote:

> Hi Rick,
>
> Rick Graves [2007-11-01 21:28 -0000]:
> > So it seems the installation instructions one can
> > easily find don't work
>
> Well, they do work. If yo...

[Muhammad Takdir (muhammad-takdir)]

it's seem that the problem is solved. so we close this bug report. may be we can continue our discussion about postgre-sql in other thread. and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

[Martin Pitt (pitti)]

I think there is still at least a documentation problem here, so I reopen this.

[Launchpad Janitor (janitor)]

This bug was fixed in the package postgresql-common - 96

---------------
postgresql-common (96) unstable; urgency=low

  * debian/supported-versions: Add "Debian 5.0" aka Lenny.
    (Closes: #509144)
  * debian/README.Debian: Document port handling, and point to
    relevant manpages and tools. (Closes: #508977)
  * debian/README.Debian: Fix "confident" typo. (Closes: #512648)
  * Drop pg_autovacuum handling, which was only necessary for 7.4 (8.0
    and above have internal autovacuuming). This was kept for Lenny to
    allow Etch backports. This also gets rid of pg_maintenance and
    /etc/cron.d/postgresql-common. (Closes: #425914, #481025)
  * Add debian/postgresql-common.preinst: Remove obsolete conffiles
    (cronjob and /etc/postgresql-common/autovacuum.conf) on upgrade.
  * Drop support for pre-8.1 clusters, together with all hacks and
    workarounds for those. Add Conflicts: to postgresql-{7.4,8.0}, to
    ensure that this version isn't used with ancient servers any more.
  * t/030_errors.t: Check that clusters on the same port can run side
    by side if they are using different Unix socket directories and
    different TCP addresses. This reproduces #514132.
  * pg_ctlcluster: Replace overly harsh port conflict check (which
    broke clusters on the same port, but different Unix/TCP
    namespaces) with a more modest one which just checks conflict on
    the same Unix socket directory. Thanks to Bernd Helmle for the
    patch! (Closes: #514132, #472627)
  * debian/postgresql-common.postinst: Do not call pg_updatedicts with
    full path (DP 6.1).
  * pg_lsclusters, pg_upgradecluster: Fix forgotten "=back" after
    itemize list in the POD. Thanks lintian.
  * debian/compat, debian/control: Bump compat level to 6.
  * pg_updatedicts: Ensure generated tsearch dictionaries are world
    readable when being generated under umask 077.
  * debian/README.Debian: Point out incompatibility between using the
    upstream tools (initdb) and the Debian tools (pg_createcluster)
    and give some recommendations. (LP: #138793)
  * debian/maintscripts-functions: Unset $GREP_OPTIONS. Thanks to
    Carlo Calderoni for noticing!

 -- Martin Pitt <email address hidden> Thu, 19 Feb 2009 09:29:34 +0000