Re: BUG #5475: Problem during Instalation

From: Joel Henrique <joel(at)cefet-al(dot)br>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5475: Problem during Instalation
Date: 2010-06-09 11:15:21
Message-ID: AANLkTilI0z7SiA9GGH-qUzcSQC4zxY0M3JEoAYBi25eF@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Thanks to EveryBody! =)

---
"Seja em você a mudança que quer para o mundo."
Mahatma Gandhi
"A mente que se abre a uma nova idéia jamais voltará ao seu tamanho
original."

Albert Einstein

JOwEL Henrique
(82) 8830-2627

2010/6/9 Dave Page <dpage(at)pgadmin(dot)org>

> On Wed, Jun 9, 2010 at 10:03 AM, Craig Ringer
> <craig(at)postnewspapers(dot)com(dot)au> wrote:
> > - During the install, test for the existence of a 'postgres' user
> > account before displaying the password prompt panel of the installer
> > "wizard".
> >
> > - If such an account does not exist, display the existing UI password
> > prompt ui with simplified language indicating that you're creating a new
> > password not entering one already set. People seem to struggle with this
> > at present.
> >
> > - If such an account already exists, tell the user that PostgreSQL has
> > been installed in the past or another version is currently installed, so
> > they must provide the password that was supplied during that prior
> > installation. If they do not know the password, they may press an
> > offered "reset password" button to enter a new one, but they're warned
> > that doing so will cause any other versions of PostgreSQL to stop
> working.
>
> The current message is:
>
> Please provide a password for the database superuser (${superaccount})
> and service account (${serviceaccount}). If the service account
> already exists in Windows, you must enter the current password for the
> account. If the account does not exist, it will be created when you
> click 'Next'.
>
> Or, in upgrade mode:
>
> Please provide a password for service account (${serviceaccount}).
>
> There is a point beyond which further simplification of text really
> doesn't help (because people just aren't reading it in the first
> place). Personally, I think we're pretty darn close to that point, but
> I'm open to better phrasing.
>
> I'm unconvinced that the extra complexity involved in checking the
> existence of the service account to tweak the message is worthwhile. I
> don't think it buys us extra simplicity that would suddenly make
> people understand.
>
> > ------ or possibly ..... --------
> >
> > - When the postgres user password is reset on the PostgreSQL service via
> > the Pg installer, update or offer to update *all* service registrations
> > for any service using the postgres account so that they use the same
> > password, thus avoiding breaking old versions when the user has
> > forgotten the service account password.
>
> That would break any of them that have implemented anything like your
> previous suggestion (with the password stored in the registry). Plus,
> an installation of PostgreSQL should never modify any other software
> that may be installed, imho.
>
> A hint, or button to fire up the computer management MMC might be
> feasible, but I'm not entirely sure. I've seen these sort of bug
> report from people who have never ventured into the stuff in the
> Administrative Tools folder, so even guiding them there may not help.
>
> >> So how would you install something like pgAgent, which you would most
> >> likely want to run under the same account?
> >
> > Installers run as admin; it'd read the registry key during installation
> > and use it for the CreateService call.
>
> That might work for one of our installers, but not if someone installs
> manually, or using a 3rd party package.
>
> > OTOH, if it's a generated password, leaking it has little effect as it's
> > unique to the machine and only grants access to a service account that
> > the admin user already has access to by virtue of their admin status on
> > that machine.
>
> Which breaks any audit trail because you have no way of knowing which
> admin may login as the service user.
>
> --
> Dave Page
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise Postgres Company
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Dean Rasheed 2010-06-09 11:23:03 Re: Invalid YAML output from EXPLAIN
Previous Message Robert Haas 2010-06-09 11:07:09 Re: Invalid YAML output from EXPLAIN