Обсуждение: Some suggestions for the non Linux installers
Hi, I have been actively recommending Postgres in my company but had now three people coming back to me because they couldn't manage to install Postgres on Windows or MacOS. The common sympton is always that the installer (the PG installer as well as the EnterpriseDB installers) suggests to place the datadir into the same directory as the Postgres binaries (the default for Windows is c:\Program Files\Postgres\8.3\data). Now when doing this on Windows this is *bound* to fail because the "Program Files" are usually not writeable for non-admin users. The directory is created during installation by the user running the installation (which is usually an admin user). The PG service runs under a regular user account and thus fails to write to the data directory. The sympton is that the service simply fails, but you can't see any errors because PG can't write to the log file as well. I have never used a Mac but from the description of two of my co-workers it seems that under MacOS the same is happening. I would suggest that the installers (PGinstaller _and_ EnterpriseDB) are changed so that the default for the data directory is /outside/ the Postgres installation path. If it's hard to find a good default for the datadir I suggest to leave it completely empty and actively ask the user to specify a directory and give a big hint that this directory must be writeable for the postgres user account. Additionally when creating the data dir from within the installer, it should set the permissions of that directory to make sure the postgres user can really write to it. Most of the people that asked me for help, could distinguish between the installer and the base product and they didn't "judge the book by its cover", but there were some comments like "Installing MySQL is a lot easier" (well I know that it is easier due to lack of security concerns in MySQL, but that doesn't matter in that discussion) After all the installer is the first impression a new user gets, and if it's too complicated he might not even take a second look. The installer(s) should also ask some question for the default configuration so that pg_hba.conf and postgres.conf can be pre-configured to e.g. accept connections from other computers. A simple checkbox during the installation wizard would be enough for this, which would then adjust listen_address in postgresql.conf and the host entries in pg_hba.conf Just to give you guys some impression on how things show up for not-so-advanced users: http://www.dbforums.com/postgresql/1640752-installation-wont-work-postgresql.html So I think with just a little tweaking, the installation experience for those trying out Postgres could be made a lot better. Regards Thomas
On Thu, Apr 9, 2009 at 6:02 PM, Thomas Kellerer <spam_eater@gmx.net> wrote: > Hi, > > I have been actively recommending Postgres in my company but had now three > people coming back to me because they couldn't manage to install Postgres on > Windows or MacOS. > > The common sympton is always that the installer (the PG installer as well as > the EnterpriseDB installers) suggests to place the datadir into the same > directory as the Postgres binaries (the default for Windows is c:\Program > Files\Postgres\8.3\data). > > Now when doing this on Windows this is *bound* to fail because the "Program > Files" are usually not writeable for non-admin users. The directory is > created during installation by the user running the installation (which is > usually an admin user). The PG service runs under a regular user account and > thus fails to write to the data directory. The sympton is that the service > simply fails, but you can't see any errors because PG can't write to the log > file as well. It's not bound to fail because part of the installation process is to grant the require permissions on whatever directory is chosen for the data. In the case of the one-click installers, this is tested extensively before every release on a range of clean and dirty virtual machines including XP, Vista, 2K3 and 2K8, and on the Mac on Leopard, Tiger and Leopard Server. Given that, and the thousands of downloads per week we get without problems being reported, I suspect if you are seeing multiple failures then it is likely a side effect of a local security policy or similar. If you can supply an installation log that would help diagnose the problem. > I have never used a Mac but from the description of two of my co-workers it > seems that under MacOS the same is happening. Unlikely to be the same as the installation process is quite different. > I would suggest that the installers (PGinstaller _and_ EnterpriseDB) are > changed so that the default for the data directory is /outside/ the Postgres > installation path. > > If it's hard to find a good default for the datadir I suggest to leave it > completely empty and actively ask the user to specify a directory and give a > big hint that this directory must be writeable for the postgres user > account. In the majority of installations the postgres account is created by the installer so it's not feasible to grant the permissions in advance. > Additionally when creating the data dir from within the installer, it should > set the permissions of that directory to make sure the postgres user can > really write to it. As I said above, they all do. I can point you at the code if you're interested. > After all the installer is the first impression a new user gets, and if it's > too complicated he might not even take a second look. > > The installer(s) should also ask some question for the default configuration > so that pg_hba.conf and postgres.conf can be pre-configured to e.g. accept > connections from other computers. A simple checkbox during the installation > wizard would be enough for this, which would then adjust listen_address in > postgresql.conf and the host entries in pg_hba.conf Well, we intentionally don't do that in the one-click installers for precisely the reason you give above! pgInstaller on Windows does have an option to enable listenaddresses = * though - we recommend that for advanced users that want the extra flexibility. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
>> Now when doing this on Windows this is *bound* to fail because the "Program >> Files" are usually not writeable for non-admin users. The directory is >> created during installation by the user running the installation (which is >> usually an admin user). The PG service runs under a regular user account and >> thus fails to write to the data directory. The sympton is that the service >> simply fails, but you can't see any errors because PG can't write to the log >> file as well. > > It's not bound to fail because part of the installation process is to > grant the require permissions on whatever directory is chosen for the > data. In the case of the one-click installers, this is tested > extensively before every release on a range of clean and dirty virtual > machines including XP, Vista, 2K3 and 2K8, and on the Mac on Leopard, > Tiger and Leopard Server. OK, that's good news, but then those failures need to have a different source. But interesting enough the problems were all caused by wrong permissions (just look at the thread I pointed to in dbforums). > If you can supply an installation log that would help diagnose the > problem. I'll ask them, but I doubt I can get hold of them. Where would the log be stored? >> If it's hard to find a good default for the datadir I suggest to leave it >> completely empty and actively ask the user to specify a directory and give a >> big hint that this directory must be writeable for the postgres user >> account. > > In the majority of installations the postgres account is created by > the installer so it's not feasible to grant the permissions in > advance. Yes, but the data dir is created *after* the acount is created, correct? But still: I think it is a much better strategy to *not* put the data dir into the program directory. >> Additionally when creating the data dir from within the installer, it should >> set the permissions of that directory to make sure the postgres user can >> really write to it. > > As I said above, they all do. I can point you at the code if you're interested. I believe you :) >> The installer(s) should also ask some question for the default configuration >> so that pg_hba.conf and postgres.conf can be pre-configured to e.g. accept >> connections from other computers. A simple checkbox during the installation >> wizard would be enough for this, which would then adjust listen_address in >> postgresql.conf and the host entries in pg_hba.conf > > Well, we intentionally don't do that in the one-click installers for > precisely the reason you give above! You mean for security reasons? Hmm. But isn't that essential to a DBMS to be able to be contacted from the outside? Thanks for the feedback. I finally see some people understanding the advantages Postgres has over other choices, but these situations surely weren't ideal to promote Postgres which is a bit sad.. Cheers Thomas
On Thu, Apr 9, 2009 at 6:59 PM, Thomas Kellerer <spam_eater@gmx.net> wrote: > OK, that's good news, but then those failures need to have a different > source. But interesting enough the problems were all caused by wrong > permissions (just look at the thread I pointed to in dbforums). Probably because on Windows they filesystem permissions have a million and one ways to be configured. >> If you can supply an installation log that would help diagnose the >> problem. > > I'll ask them, but I doubt I can get hold of them. > Where would the log be stored? /tmp on Mac, %TEMP% for the installing user on windows. >> Well, we intentionally don't do that in the one-click installers for >> precisely the reason you give above! > > You mean for security reasons? No, I mean for simplicity. > Hmm. But isn't that essential to a DBMS to be able to be contacted from the > outside? Not at all. Developer workstations, and even fairly busy websites might be confined to a single machine. I would wager that such installations might account for >50% of our installations. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Thu, Apr 9, 2009 at 7:59 AM, Thomas Kellerer <spam_eater@gmx.net> wrote: > > But still: I think it is a much better strategy to *not* put the data dir > into the program directory. > Microsoft abandoned that model after W95/98/(ME?). A new model came out in Win2000, but rarely followed. MS got out the big ruler and whacked peoples knuckles in Vista. That's why Vista is giving everyone fits. %ALLUSERSPROFILE% or %APPDATA% gives the proper starting locations for storing data. Unfortunately it seems like most Windows developers didn't get the memo, so it's not a unique issue to pgsql.
On Thu, 9 Apr 2009, Dave Page wrote: > I suspect if you are seeing multiple failures then it is likely a side > effect of a local security policy or similar. If you can supply an > installation log that would help diagnose the problem. If you look at the forum post Thomas referenced, the errors all look like variations on this during initdb: creating directory C:/Archivos de programa/PostgreSQL/8.3/data ... ok creating subdirectories ... ok selecting default max_connections ... 10 selecting default shared_buffers/max_fsm_pages ... 400kB/20000 creating configuration files ... ok creating template1 database in C:/Archivos de programa/PostgreSQL/8.3/data/base/1 ... child process exited with exit code 1 I'm not sure whether the install log will give you any additional detail beyond that, or if this is an installer issue at all. Looks to me like initdb is presuming the subdirectories it creates inside of PGDATA will inherit the permissions of the parent directory, but that isn't the case on this particular Windows system. I know it's possible to play with inheritance in ways that would give unexpected behavior (for those used to the UNIX model) on NTFS; see "Inherited vs. Explicit Permissions" at http://www.windowsecurity.com/articles/Understanding-Windows-NTFS-Permissions.html for background. While whether supporting odd configurations like that is deemed worthwhile or not, I think improving on only getting "child process exited" in this situation would help a lot of people out. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Thu, Apr 9, 2009 at 8:37 PM, Greg Smith <gsmith@gregsmith.com> wrote: > On Thu, 9 Apr 2009, Dave Page wrote: > >> I suspect if you are seeing multiple failures then it is likely a side >> effect of a local security policy or similar. If you can supply an >> installation log that would help diagnose the problem. > > If you look at the forum post Thomas referenced, the errors all look like > variations on this during initdb: I'm not interested in that case, but Thomas'. The forum post concerned some *very* different installer designs all of which gave the same initdb errors from what I can see, indicating an initdb issue. I'm interested in Thomas' case because he has multiple machines showing the same symptoms and I'm in contact with him so may be able to get more information and actually have a chance of figuring out what's going on. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Greg Smith <gsmith@gregsmith.com> writes:
> If you look at the forum post Thomas referenced, the errors all look like
> variations on this during initdb:
> creating directory C:/Archivos de programa/PostgreSQL/8.3/data ... ok
> creating subdirectories ... ok
> selecting default max_connections ... 10
> selecting default shared_buffers/max_fsm_pages ... 400kB/20000
> creating configuration files ... ok
> creating template1 database in
> C:/Archivos de programa/PostgreSQL/8.3/data/base/1 ...
> child process exited with exit code 1
> I'm not sure whether the install log will give you any additional detail
> beyond that, or if this is an installer issue at all. Looks to me like
> initdb is presuming the subdirectories it creates inside of PGDATA will
> inherit the permissions of the parent directory, but that isn't the case
> on this particular Windows system.
I think we've seen failures just like that in the buildfarm, so it's not
by any means an issue only for the installer. Have we determined why
nothing useful in the way of an error message gets printed?
regards, tom lane
On Thu, Apr 9, 2009 at 8:34 PM, Russell Hltn <russellhltn@gmail.com> wrote: > On Thu, Apr 9, 2009 at 7:59 AM, Thomas Kellerer <spam_eater@gmx.net> wrote: >> >> But still: I think it is a much better strategy to *not* put the data dir >> into the program directory. >> > > Microsoft abandoned that model after W95/98/(ME?). A new model came > out in Win2000, but rarely followed. MS got out the big ruler and > whacked peoples knuckles in Vista. That's why Vista is giving > everyone fits. > > %ALLUSERSPROFILE% or %APPDATA% gives the proper starting locations for > storing data. Unfortunately it seems like most Windows developers > didn't get the memo, so it's not a unique issue to pgsql. There are potential problems with storing data in such locations - they may be on network shares, or be roaming directories for example. It also makes it difficult for other users to edit the config files if they're tucked away in the service accounts profile directory. I imagine it is for similar reasons that Microsoft SQL Server also defaults to storing its data under the installation directory. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com