Re: Minimising windows installer password confusion

Probably the most common issue we see from Windows users of PostgreSQL
is confusion over the passwords the installer asks for during
installation and upgrade. I'd like to try to reduce that, but am
struggling to come up with clear, simple wording.

Some background: By default the installer will use 'postgres' for both
the service (OS) account, and the database superuser account. It will
use the same password for both (though, users have complete control at
the command line if they want it, which is why the account names are
shown in the installer). Unlike *nix installations, the service
account must have a password, which is required during both
installation and upgrade to configure the PostgreSQL service. We
therefore ask for the password during both installation and upgrade.
If the user account exists (which can happen if there has previously
been an installation of Postgres on the system), the user must specify
the existing password for the account during installation (and of
course, during all upgrades). This is where users normally get stuck,
as they've forgotten the password they set in the past.

Attached are some screenshots of the current installation and upgrade
steps in question, and the password incorrect message box. The
suggested new text for the steps that I've come up with is below. I'd
welcome suggestions or improvements to help reduce pgsql-bugs traffic!

Thanks.

Installation step:

*******************************
Please provide a password for the database superuser (postgres) and
service account (postgres). 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'.

Password [ ]
Retype password [ ]

If the service account already exists on your computer and you don't
know the password, you can reset it using the Computer Management tool
in the Administrative Tools section of the Control Panel. You may need
update any other services that are using this account with the new
password.

Note that this password is not related to any used on the PostgreSQL
or EnterpriseDB websites.
*******************************

Upgrade step:

*******************************
Please provide the password for the service account (postgres).

Password [ ]
Retype password [ ]

If you don't know the password, you can reset it using the Computer
Management tool in the Administrative Tools section of the Control
Panel. You may need update any other services that are using this
account with the new password.

Note that this password is not related to any used on the PostgreSQL
or EnterpriseDB websites.
*******************************

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 06/12/2012 08:08 PM, Dave Page wrote:
> Some background: By default the installer will use 'postgres' for both
> the service (OS) account, and the database superuser account. It will
> use the same password for both (though, users have complete control at
> the command line if they want it, which is why the account names are
> shown in the installer). Unlike *nix installations, the service
> account must have a password, which is required during both
> installation and upgrade to configure the PostgreSQL service. We
> therefore ask for the password during both installation and upgrade.
> If the user account exists (which can happen if there has previously
> been an installation of Postgres on the system), the user must specify
> the existing password for the account during installation (and of
> course, during all upgrades). This is where users normally get stuck,
> as they've forgotten the password they set in the past.
They may not even have set it, because the EnterpriseDB installer can be
run unattended and may've been used by some 3rd party package.

I'd be interested in seeing what Microsoft installers that create
isolated user accounts do. I think .NET creates one for ASP, so that'd
be one option to look into.

--
Craig Ringer

POST Newspapers
276 Onslow Rd, Shenton Park
Ph: 08 9381 3088 Fax: 08 9388 2258
ABN: 50 008 917 717
http://www.postnewspapers.com.au/

On Wed, Jun 13, 2012 at 2:18 AM, Craig Ringer
<craig(at)postnewspapers(dot)com(dot)au> wrote:
> On 06/12/2012 08:08 PM, Dave Page wrote:
>>
>> Some background: By default the installer will use 'postgres' for both
>> the service (OS) account, and the database superuser account. It will
>> use the same password for both (though, users have complete control at
>> the command line if they want it, which is why the account names are
>> shown in the installer). Unlike *nix installations, the service
>> account must have a password, which is required during both
>> installation and upgrade to configure the PostgreSQL service. We
>> therefore ask for the password during both installation and upgrade.
>> If the user account exists (which can happen if there has previously
>> been an installation of Postgres on the system), the user must specify
>> the existing password for the account during installation (and of
>> course, during all upgrades). This is where users normally get stuck,
>> as they've forgotten the password they set in the past.
>
> They may not even have set it, because the EnterpriseDB installer can be run
> unattended and may've been used by some 3rd party package.
>
> I'd be interested in seeing what Microsoft installers that create isolated
> user accounts do. I think .NET creates one for ASP, so that'd be one option
> to look into.

They tend to use the localsystem or networkservice accounts for most
things, which don't have passwords. The reason we don't do that is
that since the early days of 8.0 we've said we want to enable users to
use the service account as if it were a regular account, so that they
can do things like access network resources (useful for server-side
copy for example).

I wasn't overly convinced back then that that was necessary, and I'm
still not now. I suppose we potentially could use the networkservice
account by default, and let advanced users override that on the
command line if they need to. Then remembering the password becomes
their responsibility.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 06/13/2012 05:14 PM, Dave Page wrote:
> On Wed, Jun 13, 2012 at 2:18 AM, Craig Ringer
> <craig(at)postnewspapers(dot)com(dot)au> wrote:
>> On 06/12/2012 08:08 PM, Dave Page wrote:
>>> Some background: By default the installer will use 'postgres' for both
>>> the service (OS) account, and the database superuser account. It will
>>> use the same password for both (though, users have complete control at
>>> the command line if they want it, which is why the account names are
>>> shown in the installer). Unlike *nix installations, the service
>>> account must have a password, which is required during both
>>> installation and upgrade to configure the PostgreSQL service. We
>>> therefore ask for the password during both installation and upgrade.
>>> If the user account exists (which can happen if there has previously
>>> been an installation of Postgres on the system), the user must specify
>>> the existing password for the account during installation (and of
>>> course, during all upgrades). This is where users normally get stuck,
>>> as they've forgotten the password they set in the past.
>> They may not even have set it, because the EnterpriseDB installer can be run
>> unattended and may've been used by some 3rd party package.
>>
>> I'd be interested in seeing what Microsoft installers that create isolated
>> user accounts do. I think .NET creates one for ASP, so that'd be one option
>> to look into.
> They tend to use the localsystem or networkservice accounts for most
> things, which don't have passwords. The reason we don't do that is
> that since the early days of 8.0 we've said we want to enable users to
> use the service account as if it were a regular account, so that they
> can do things like access network resources (useful for server-side
> copy for example).
>
> I wasn't overly convinced back then that that was necessary, and I'm
> still not now. I suppose we potentially could use the networkservice
> account by default, and let advanced users override that on the
> command line if they need to. Then remembering the password becomes
> their responsibility.
+1 from me on this, though I think making the service account part of
the install process makes sense.

SERVICE ACCOUNT
-------------------------

You can probably just accept the default here.

PostgreSQL runs in the background as a network service in a user account
that
only has limited access to the files and programs on the computer. This
is fine
for most purposes, but will prevent certain operations like server-side
COPY and
direct access by the server to resources on shared folders from working.
If you
need these capabilities, we recommend that you create a "postgres" user
account
below and have the PostgreSQL server run in that instead of the default
NetworkService account.

-- [service account] -----------------------
| |
| [*] LocalService |
| |
| [ ] Custom Service Account |
| |
| -- [custom account]------------------| |
| | | |
| | Username: [ ] | |
| | Password: [ ] | |
| | Domain: [ THISCOMPUTER ] | |
| | | |
| |------------------------------------| |
|------------------------------------------|

Reasonable option?

--
Craig Ringer

POST Newspapers
276 Onslow Rd, Shenton Park
Ph: 08 9381 3088 Fax: 08 9388 2258
ABN: 50 008 917 717
http://www.postnewspapers.com.au/

On Thu, Jun 14, 2012 at 12:55 AM, Craig Ringer
<craig(at)postnewspapers(dot)com(dot)au> wrote:
> On 06/13/2012 05:14 PM, Dave Page wrote:
>>
>> On Wed, Jun 13, 2012 at 2:18 AM, Craig Ringer
>> <craig(at)postnewspapers(dot)com(dot)au> wrote:
>>>
>>> On 06/12/2012 08:08 PM, Dave Page wrote:
>>>>
>>>> Some background: By default the installer will use 'postgres' for both
>>>> the service (OS) account, and the database superuser account. It will
>>>> use the same password for both (though, users have complete control at
>>>> the command line if they want it, which is why the account names are
>>>> shown in the installer). Unlike *nix installations, the service
>>>> account must have a password, which is required during both
>>>> installation and upgrade to configure the PostgreSQL service. We
>>>> therefore ask for the password during both installation and upgrade.
>>>> If the user account exists (which can happen if there has previously
>>>> been an installation of Postgres on the system), the user must specify
>>>> the existing password for the account during installation (and of
>>>> course, during all upgrades). This is where users normally get stuck,
>>>> as they've forgotten the password they set in the past.
>>>
>>> They may not even have set it, because the EnterpriseDB installer can be
>>> run
>>> unattended and may've been used by some 3rd party package.
>>>
>>> I'd be interested in seeing what Microsoft installers that create
>>> isolated
>>> user accounts do. I think .NET creates one for ASP, so that'd be one
>>> option
>>> to look into.
>>
>> They tend to use the localsystem or networkservice accounts for most
>> things, which don't have passwords. The reason we don't do that is
>> that since the early days of 8.0 we've said we want to enable users to
>> use the service account as if it were a regular account, so that they
>> can do things like access network resources (useful for server-side
>> copy for example).
>>
>> I wasn't overly convinced back then that that was necessary, and I'm
>> still not now. I suppose we potentially could use the networkservice
>> account by default, and let advanced users override that on the
>> command line if they need to. Then remembering the password becomes
>> their responsibility.
>
> +1 from me on this, though I think making the service account part of the
> install process makes sense.
>
> SERVICE ACCOUNT
> -------------------------
>
> You can probably just accept the default here.
>
> PostgreSQL runs in the background as a network service in a user account
> that
> only has limited access to the files and programs on the computer. This is
> fine
> for most purposes, but will prevent certain operations like server-side COPY
> and
> direct access by the server to resources on shared folders from working. If
> you
> need these capabilities, we recommend that you create a "postgres" user
> account
> below and have the PostgreSQL server run in that instead of the default
> NetworkService account.
>
> -- [service account] -----------------------
> |                                          |
> | [*] LocalService                         |
> |                                          |
> | [ ] Custom Service Account               |
> |                                          |
> | -- [custom account]------------------|   |
> | |                                    |   |
> | | Username: [                 ]      |   |
> | | Password: [                 ]      |   |
> | | Domain:   [ THISCOMPUTER    ]      |   |
> | |                                    |   |
> | |------------------------------------|   |
> |------------------------------------------|
>
> Reasonable option?

Too complicated - it'll confuse users too (and it goes against the
primary goal of the installers which is to setup the server in a
suitable way for production use, with the absolute minimum of user
interaction). We try to provide more complex config options that 99%
of users won't need through the command line only (though, in the
future I guess it might make sense to have a "Show advanced options"
checkbox on the first page, though that's definitely out of scope for
9.2).

I'll have a play with it and see if a simple switch to NetworkService
seems feasible.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Thu, Jun 14, 2012 at 11:43 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
> I'll have a play with it and see if a simple switch to NetworkService
> seems feasible.

OK, I worked up a patch which uses "NT AUTHORITY\NetworkService" as
the service account by default. This doesn't need a password, so
allows us to simply prompt during installation for the superuser
password for the cluster, and not at all during upgrade. If you run
the installer from the command line with "--serviceaccount postgres"
(or some other account name), you get the current behaviour.

I've posted it on our internal ReviewBoard system for the rest of the
team to review and test on various platforms (I've only tried it on XP
so far). Now would be a very good time for people to yelp if they
think this is a bad idea (the only downside I can see if accessing
files for server-side copy etc, but users that want to do that can
install with a non-default account). If we go ahead, we'll include it
in 9.2.

Thanks for the feedback folks.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Thu, Jun 14, 2012 at 11:59 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> On Thu, Jun 14, 2012 at 11:43 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>> I'll have a play with it and see if a simple switch to NetworkService
>> seems feasible.
>
> OK, I worked up a patch which uses "NT AUTHORITY\NetworkService" as
> the service account by default. This doesn't need a password, so
> allows us to simply prompt during installation for the superuser
> password for the cluster, and not at all during upgrade. If you run
> the installer from the command line with "--serviceaccount postgres"
> (or some other account name), you get the current behaviour.
>
> I've posted it on our internal ReviewBoard system for the rest of the
> team to review and test on various platforms (I've only tried it on XP
> so far). Now would be a very good time for people to yelp if they
> think this is a bad idea (the only downside I can see if accessing
> files for server-side copy etc, but users that want to do that can
> install with a non-default account). If we go ahead, we'll include it
> in 9.2.

What happens if they try to use this to upgrade from the EDB 9.1 installers?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Thu, Jun 14, 2012 at 5:38 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Jun 14, 2012 at 11:59 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>> On Thu, Jun 14, 2012 at 11:43 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>
>>> I'll have a play with it and see if a simple switch to NetworkService
>>> seems feasible.
>>
>> OK, I worked up a patch which uses "NT AUTHORITY\NetworkService" as
>> the service account by default. This doesn't need a password, so
>> allows us to simply prompt during installation for the superuser
>> password for the cluster, and not at all during upgrade. If you run
>> the installer from the command line with "--serviceaccount postgres"
>> (or some other account name), you get the current behaviour.
>>
>> I've posted it on our internal ReviewBoard system for the rest of the
>> team to review and test on various platforms (I've only tried it on XP
>> so far). Now would be a very good time for people to yelp if they
>> think this is a bad idea (the only downside I can see if accessing
>> files for server-side copy etc, but users that want to do that can
>> install with a non-default account). If we go ahead, we'll include it
>> in 9.2.
>
> What happens if they try to use this to upgrade from the EDB 9.1 installers?

The installers don't support major version upgrades - it'll install
alongside 9.1.

If someone has an existing beta installation of 9.2, it'll use the
service account that was installed with, just as past minor-version
upgrades would (including asking for the password).

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 06/14/2012 11:59 PM, Dave Page wrote:
> On Thu, Jun 14, 2012 at 11:43 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>> I'll have a play with it and see if a simple switch to NetworkService
>> seems feasible.
> OK, I worked up a patch which uses "NT AUTHORITY\NetworkService" as
> the service account by default. This doesn't need a password, so
> allows us to simply prompt during installation for the superuser
> password for the cluster, and not at all during upgrade. If you run
> the installer from the command line with "--serviceaccount postgres"
> (or some other account name), you get the current behaviour.
>
> I've posted it on our internal ReviewBoard system for the rest of the
> team to review and test on various platforms (I've only tried it on XP
> so far).
Cool. Feel free to lob me a link if you want, I have several unimportant
systems I can test it on too.

--
Craig Ringer

POST Newspapers
276 Onslow Rd, Shenton Park
Ph: 08 9381 3088 Fax: 08 9388 2258
ABN: 50 008 917 717
http://www.postnewspapers.com.au/