Re: BUG #5475: Problem during Instalation - Mailing list pgsql-bugs
From | Joel Henrique |
---|---|
Subject | Re: BUG #5475: Problem during Instalation |
Date | |
Msg-id | AANLkTilI0z7SiA9GGH-qUzcSQC4zxY0M3JEoAYBi25eF@mail.gmail.com Whole thread Raw |
In response to | Re: BUG #5475: Problem during Instalation (Dave Page <dpage@pgadmin.org>) |
List | pgsql-bugs |
Thanks to EveryBody! =3D) --- "Seja em voc=EA a mudan=E7a que quer para o mundo." Mahatma Gandhi "A mente que se abre a uma nova id=E9ia jamais voltar=E1 ao seu tamanho original." Albert Einstein JOwEL Henrique (82) 8830-2627 2010/6/9 Dave Page <dpage@pgadmin.org> > On Wed, Jun 9, 2010 at 10:03 AM, Craig Ringer > <craig@postnewspapers.com.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 >
pgsql-bugs by date: