From: | Dave Page <dpage(at)pgadmin(dot)org> |
---|---|
To: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Sachin Srivastava <sachin(dot)srivastava(at)enterprisedb(dot)com>, Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com>, Dharmendra Goyal <dharmendra(dot)goyal(at)enterprisedb(dot)com> |
Subject: | Re: Minimising windows installer password confusion |
Date: | 2012-06-14 10:43:36 |
Message-ID: | CA+OCxoyv90Yp5_fUvveqQNkHLLjLydJBM70WY6+aXABDf-cVqg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Marco Nenciarini | 2012-06-14 10:52:25 | Re: [PATCH] Support for foreign keys with arrays |
Previous Message | Marco Nenciarini | 2012-06-14 10:41:53 | Support for array_remove and array_replace functions |