Re: Minimising windows installer password confusion - Mailing list pgsql-hackers

From Dave Page
Subject Re: Minimising windows installer password confusion
Date
Msg-id CA+OCxoyv90Yp5_fUvveqQNkHLLjLydJBM70WY6+aXABDf-cVqg@mail.gmail.com
Whole thread Raw
In response to Re: Minimising windows installer password confusion  (Craig Ringer <craig@postnewspapers.com.au>)
Responses Re: Minimising windows installer password confusion
List pgsql-hackers
On Thu, Jun 14, 2012 at 12:55 AM, Craig Ringer
<craig@postnewspapers.com.au> wrote:
> On 06/13/2012 05:14 PM, Dave Page wrote:
>>
>> On Wed, Jun 13, 2012 at 2:18 AM, Craig Ringer
>> <craig@postnewspapers.com.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


pgsql-hackers by date:

Previous
From: Marco Nenciarini
Date:
Subject: Support for array_remove and array_replace functions
Next
From: Marco Nenciarini
Date:
Subject: Re: [PATCH] Support for foreign keys with arrays