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: