Re: Minimising windows installer password confusion - Mailing list pgsql-hackers
From | Craig Ringer |
---|---|
Subject | Re: Minimising windows installer password confusion |
Date | |
Msg-id | 4FD92886.8040008@postnewspapers.com.au Whole thread Raw |
In response to | Re: Minimising windows installer password confusion (Dave Page <dpage@pgadmin.org>) |
Responses |
Re: Minimising windows installer password confusion
|
List | pgsql-hackers |
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? -- 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/
pgsql-hackers by date: