From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org> |
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-13 23:55:50 |
Message-ID: | 4FD92886.8040008@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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/
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-06-14 00:22:00 | Re: Ability to listen on two unix sockets |
Previous Message | Tom Lane | 2012-06-13 23:49:07 | Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation. |