Re: "1-Click" installer problems

Hi,

I have been trying to install 8.4 on my Vista without success. Earlier
I'd tried to install 8.3 and that failed too. I tried installing these
on other Vista machines and they failed too. I searched for google and
enterprisedb forums and there are innumerable requests like mine. Same
with Windows 7. It seems enterprisedb has no clue on what the problem is
and how to fix it. There is not even a guide on how to install
postgresql on Vista or Windows 7. Their 'guide' is only for MacOS. The
"one click" feels like a scam. Search for other threads on their forums
or on google. Their support staff want to be helpful but I think they
just lack the necessary expertise in solving such issues.

I was able to install 8.3 from postgresql.org download site and now I
see 8.4 is no longer supported. What are we windows users supposed to
do? Our production servers are linux based but our development
environment is Windows.

I have nothing against enterprisedb but the decision to 'leave out'
windows from postgresql.org download site seems political and will
simply alienate more people from postgresql. We advocate pgsql to all
our customers and help them in installation and training at no cost
because we believe that is some way of giving back. With the new
"1-click" we are not sure any more. I strongly recommend that you start
supporting the win32 binary on postgresql.org site again because that
used to work till 8.3 and enterprisedb is failing for a long time.

Regards,
Nikhil

Nikhil G. Daddikar wrote:
> Hi,
>
> I have been trying to install 8.4 on my Vista without success. Earlier
> I'd tried to install 8.3 and that failed too.

"Failed" how?

Installer logs?

Details?

> I tried installing these
> on other Vista machines and they failed too. I searched for google and
> enterprisedb forums and there are innumerable requests like mine.

... many of which will be completely unrelated to each other and
describe different issues, but be hard to differentiate because they
lack the detail required to tell what's actually going on.

I *have* seen odd Windows install issues mentioned here, but most of
them turn out to be:

- Installing on unsupported windows like WinXP Embedded
- Pre-existing postgres service accounts with lost passwords
- Damaged installers
- Damaged systems
- Braindead add-on software running on the system, like broken
antivirus or search/indexing tools.

There are also some unexplained issues. People often fail to follow them
up with the level of detail that'd be needed to track down what might be
going on.

I have seen issues get lost or peter out as the back-and-forth of
debugging info doens't achieve anything. Someone dedicated to win32
installer troubleshooting would certainly help - are you volunteering?

Part of the trouble is, frankly, that many people just don't like
working with Windows, particularly with messy things like Windows
installers. EDB is handy because it's hard to get people who'll
volunteer to work on this sort of thing.

> Same
> with Windows 7. It seems enterprisedb has no clue on what the problem is
> and how to fix it. There is not even a guide on how to install
> postgresql on Vista or Windows 7. Their 'guide' is only for MacOS. The
> "one click" feels like a scam. Search for other threads on their forums
> or on google. Their support staff want to be helpful but I think they
> just lack the necessary expertise in solving such issues.

They'd need psychic powers to help with the amount of detail you've
provided :-P

> I was able to install 8.3 from postgresql.org download site and now I
> see 8.4 is no longer supported.

eh? 8.4 no longer supported? That's absolutely not the case. Did you
mean 8.1 ?

> I have nothing against enterprisedb but the decision to 'leave out'
> windows from postgresql.org download site seems political and will
> simply alienate more people from postgresql.

The issue is that many people here don't use Windows and don't have the
expertise required to maintain a win32 installer. The EnterpriseDB folks
do. They were doing it anyway, and it seems pointless to duplicate the
effort producing another installer for the same product, so the old Pg
win32 installer was dropped.

Perhaps it'd be nice to mirror the EDB installer on the main pg site,
but that's a trivial issue.

> We advocate pgsql to all
> our customers and help them in installation and training at no cost
> because we believe that is some way of giving back. With the new
> "1-click" we are not sure any more. I strongly recommend that you start
> supporting the win32 binary on postgresql.org site again because that
> used to work till 8.3 and enterprisedb is failing for a long time.

OK, so let's look into WHY and figure out what's causing that failure.
It works for me on all my win32 systems, and it clearly works for a
significant majority (though I'm sure there are issues) so we need to
find out what makes your setup different and why it's breaking.

--
Craig Ringer

Nikhil G. Daddikar wrote:

> I strongly recommend that you start
> supporting the win32 binary on postgresql.org site again because that
> used to work till 8.3 and enterprisedb is failing for a long time.

Oh: As for the old installer - are you volunteering to maintain it? It
wasn't maintaining its self. Working with Windows installers is an ugly,
unrewarding job where you're constantly battling a new variety of weird
issues due to various breakage and brain-death on the systems the
installer is being used on. People complain "it doesn't work" and then
won't provide enough information to actually find out why - they expect
you to have psychic powers and/or a magic fix-it wand. They angrily
demand an instant fix, as if they'd paid for a product they had some
kind of right to support for.

No wonder nobody likes doing it!

Are you going to take up that workload? Or just demand that somebody
else does it?

--
Craig Ringer

On Thu, 2010-04-01 at 11:30 +0800, Craig Ringer wrote:
> Nikhil G. Daddikar wrote:
>
> > I strongly recommend that you start
> > supporting the win32 binary on postgresql.org site again because that
> > used to work till 8.3 and enterprisedb is failing for a long time.
>
> Oh: As for the old installer - are you volunteering to maintain it? It
> wasn't maintaining its self. Working with Windows installers is an ugly,
> unrewarding job where you're constantly battling a new variety of weird
> issues due to various breakage and brain-death on the systems the
> installer is being used on. People complain "it doesn't work" and then
> won't provide enough information to actually find out why - they expect
> you to have psychic powers and/or a magic fix-it wand. They angrily
> demand an instant fix, as if they'd paid for a product they had some
> kind of right to support for.
>
> No wonder nobody likes doing it!
>
> Are you going to take up that workload? Or just demand that somebody
> else does it?

Although I can understand the frustration, I think a more adequate
response would be:

If EDB was failing for a long time, we would hear a lot more about it.
They host the most downloaded installer .Org has.

Joshua D. Drake

>
> --
> Craig Ringer
>

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.

Joshua D. Drake wrote:

> If EDB was failing for a long time, we would hear a lot more about it.
> They host the most downloaded installer .Org has.

True. And sorry for grumping.

I've had the misfortune to maintain a win32 installer (in my own time)
before, so this is a bit of a hot button. Sure, it works on every system
I have access to without issues, but because your FarkWare 4000 Super
Privacy Nuker ZX software breaks everything that tries to set file
system permissions, the installer's clearly defective. Argh.

I still shouldn't let it get to me. My apologies to Nikhil.

In any case, while I the EDB installer works extremely well for the
clear majority, like anything it could use improvement, and detailed
constructive feedback on what exactly needs improvement can only be a
good thing. It's the *detailed* bit that needs work right now, though...

( For example, people _do_ get confused by its handling of the postgres
service account, especially during reinstall, and it'd be interesting to
see if there were other approaches taken by other software that avoided
needing to involve the user in working with the postgres service account
password directly. )

--
Craig Ringer

Folks,

Here is my original ticket. It has the screen shot as well as the logs.
Like many other threads on this forum it remains unresolved.

http://forums.enterprisedb.com/posts/list/2235.page

If you want to know the number of people who complain about this
one-click installer, just search that forum. The reason I posted in this
general news group is to make other people aware of the problems that
are being encountered.

And I am not the kind of person who will complain without reasons. I
have spent at least 3 man days trying to install the one-click installer
on multiple Vista machines and every time without success... trying to
find out the problem so that I could post the solution to the forum. I
have been using PG since the last 10 years and we think we do a pretty
good job of it. We have successfully converted people from SQL Server
and Oracle to PG and I think that in itself qualifies as some kind of
"giving back" to PG.

I don't like Windows and I don't like Linux and I don't like Mac. But
they are reality and in my opinion we need to live with it. If PG will
not support Windows Vista or 7, then it should simply say so and I will
keep my mouth shut.... like I did before 8.0. But to move from something
that works i.e PG 8.3 win32 binary to something that doesn't i.e the
1Click installer and then claiming that Windows sucks doesn't go down
well with me. I appreciate the volunteers that have made the database
and the installer till now.

What I would like from EDB is a list of instructions on how to install
it on Vista or Windows 7. I've asked this in the forum but I have not
received any response. Is this too much to ask?

-Nikhil

PS: It is the users that make or break the software not its developers.
So please think twice before asking users to go to hell. Other users
might think it will be their turn to hear this some day.

On 01-04-2010 09:41, Craig Ringer wrote:
> Joshua D. Drake wrote:
>
>
>> If EDB was failing for a long time, we would hear a lot more about it.
>> They host the most downloaded installer .Org has.
>>
> True. And sorry for grumping.
>
> I've had the misfortune to maintain a win32 installer (in my own time)
> before, so this is a bit of a hot button. Sure, it works on every system
> I have access to without issues, but because your FarkWare 4000 Super
> Privacy Nuker ZX software breaks everything that tries to set file
> system permissions, the installer's clearly defective. Argh.
>
> I still shouldn't let it get to me. My apologies to Nikhil.
>
> In any case, while I the EDB installer works extremely well for the
> clear majority, like anything it could use improvement, and detailed
> constructive feedback on what exactly needs improvement can only be a
> good thing. It's the *detailed* bit that needs work right now, though...
>
> ( For example, people _do_ get confused by its handling of the postgres
> service account, especially during reinstall, and it'd be interesting to
> see if there were other approaches taken by other software that avoided
> needing to involve the user in working with the postgres service account
> password directly. )
>
> --
> Craig Ringer
>
>

In about 30 seconds I found the following unanswered threads relating to
installation on Windows Vista. If anybody is interested I can find more.
And I can tell you that a lot of our customers are facing the same
problem with this 1-click gimmicky installer.. something that they never
faced till the 8.3 installer from postgresql.org. And not everybody is
going to post a forum ticket. We've convinced them install 8.3 instead
and that works. But their first experience has been bitter and it
lingers for a long time.

http://forums.enterprisedb.com/posts/list/1815.page

http://forums.enterprisedb.com/posts/list/1132.page

http://forums.enterprisedb.com/posts/list/2175.page

http://forums.enterprisedb.com/posts/list/2033.page

http://forums.enterprisedb.com/posts/list/1186.page

http://forums.enterprisedb.com/posts/list/1605.page

http://forums.enterprisedb.com/posts/list/1578.page

Nikhil G. Daddikar, 01.04.2010 08:04:
>
> In about 30 seconds I found the following unanswered threads relating to
> installation on Windows Vista. If anybody is interested I can find more.

The problem with this kind of statistics is that you will only find people who complain, you'll never find people who do not complain because they have no problems. Actually that's true for all internet forums or mailing lists: you'll seldomly find people posting something like "Hey everything works fine, I had no problems".

All the posts seem to share the same root cause: the data directory has been put into "c:\Program Files" but a regular user does not have write permissions on that directory. As the installer is usually run with Administrator rights, the directory can be created but the service (or initdb) runs under a normal user account that cannot write to that directory because.

I do not like the installer's suggestion to put the data directory into c:\Program Files either, I think this should default to %APPDATA% instead of %ProgramFile%. I bet half of the problems would go away if the installer refused to put the data directory into c:\Program Files.

Given the fact that Microsoft finally tries to enforce people not to work as Administrators makes this even more important.

My suggestion is to try to use a different data directory when installing Postgres and make sure that the postgres service account is allowed to read and write that directory.

Personally I switched to using the ZIP packages completely because it is so much easer (unzip, initdb, pg_ctl -register, done)

Thomas

On 01-04-2010 12:39, Thomas Kellerer wrote:
> Nikhil G. Daddikar, 01.04.2010 08:04:
>>
>> In about 30 seconds I found the following unanswered threads relating to
>> installation on Windows Vista. If anybody is interested I can find more.
>
> The problem with this kind of statistics is that you will only find
> people who complain, you'll never find people who do not complain
> because they have no problems. Actually that's true for all internet
> forums or mailing lists: you'll seldomly find people posting something
> like "Hey everything works fine, I had no problems".

I agree... but they are still unanswered. And what else can I do. I am
facing problems on multiple computers, my customers are facing problems
as well. NOBODY till date has managed to install 8.4 on Vista using the
1-click installer and EVERYBODY has managed to install the 8.3 installer
(from postgresql.org) on Vista. DOES THIS COUNT AS A VALID STATISTIC?
And yes, i have tried installing it in C:\Postgresql as well.
Interesting to note that 8.3 installer from postgresql.org installs
perfectly in 'C:\Program Files' even on Vista. No use blaming Windows
all the time. It is the installer that is buggy.

>
> All the posts seem to share the same root cause: the data directory
> has been put into "c:\Program Files" but a regular user does not have
> write permissions on that directory. As the installer is usually run
> with Administrator rights, the directory can be created but the
> service (or initdb) runs under a normal user account that cannot write
> to that directory because.
>
> I do not like the installer's suggestion to put the data directory
> into c:\Program Files either, I think this should default to %APPDATA%
> instead of %ProgramFile%. I bet half of the problems would go away if
> the installer refused to put the data directory into c:\Program Files.
>
> Given the fact that Microsoft finally tries to enforce people not to
> work as Administrators makes this even more important.
>
> My suggestion is to try to use a different data directory when
> installing Postgres and make sure that the postgres service account is
> allowed to read and write that directory.
>
> Personally I switched to using the ZIP packages completely because it
> is so much easer (unzip, initdb, pg_ctl -register, done)
>
> Thomas
>
>
>
>

Thomas Kellerer wrote:

> All the posts seem to share the same root cause: the data directory has
> been put into "c:\Program Files" but a regular user does not have write
> permissions on that directory.

Yep. They're also often confused by various steps people have tried
while attempting to get it working, making it very hard to trace what
actually happened initially and why.

> I do not like the installer's suggestion to put the data directory into
> c:\Program Files either, I think this should default to %APPDATA%

That seems fairly sensible *IF* it checks very carefully to make sure
the postgresql user does not have a roaming profile, ie they're a local
user not a domain user.

If the datadir was put in an account with roaming profiles enabled,
Windows would try to sync the datadir to and from the profile share on
the server at every user login/logout.

This could easily happen if the user overrode the usual account setup
and told the installer to just use their own account. So it needs to be
checked for and detected if %APPDATA% is to be used.

That said, C:\Users\postgresql\AppData\Local\Postgresql is indeed a very
good place to store the database.

> instead of %ProgramFile%. I bet half of the problems would go away if
> the installer refused to put the data directory into c:\Program Files.

Yep - it's not a clever place to put it.

> Given the fact that Microsoft finally tries to enforce people not to
> work as Administrators makes this even more important.

They also very strongly discourage storage of variable data in Program
Files. It's like Pg putting it's database in /usr/pgdata .

That said, on my Vista box (which has UAC fully enabled and on which Pg
runs as a normal user account) I had no problems with a default install
with datadir in program files. There's some other factor involved
causing this failure, such as a virus scanner or some funky option.

--
Craig Ringer

Craig Ringer, 01.04.2010 09:24:
>> I do not like the installer's suggestion to put the data directory into
>> c:\Program Files either, I think this should default to %APPDATA%
>
> That seems fairly sensible *IF* it checks very carefully to make sure
> the postgresql user does not have a roaming profile, ie they're a local
> user not a domain user.

I think the installer should simply not "suggest" any directory, but force the user to select one manually (maybe even activley prevent c:\Program Files). I don't know if this is possible (or how hard it would be) but I think a very useful feature for the installer would be to try to check the permissions that the service account has on the chosen data directory.

> If the datadir was put in an account with roaming profiles enabled,
> Windows would try to sync the datadir to and from the profile share on
> the server at every user login/logout.

Ah, didn't think of that one.

>such as a virus scanner or some funky option.

True.
In the german Postgres forum there are several posts regarding that topic.

It seems that especially Norton and the Windows built-in Antivirus do not work well with Postgres.
Personally I have no problems with Sophos and Avira

Thomas

I too much preferred the older installer to that oneclick thing, and
regret that we the users aren't at least given a choice.

On Thu, Apr 1, 2010 at 8:57 AM, John R Pierce <pierce(at)hogranch(dot)com> wrote:
> I too much preferred the older installer to that oneclick thing, and regret
> that we the users aren't at least given a choice.

You're free to maintain the old one if you like. Be warned though - it
had a much higher failure rate than the one-click installer (which
based on the ratio of downloads to bug reports, is down to something
like 45000:1 at this point, or a 99.997% success rate).

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On Thu, Apr 1, 2010 at 6:47 AM, Nikhil G. Daddikar <ngd(at)celoxis(dot)com> wrote:
> Folks,
>
> Here is my original ticket. It has the screen shot  as well as the logs.
> Like many other threads on this forum it remains unresolved.
>
> http://forums.enterprisedb.com/posts/list/2235.page
>
> What I would like from EDB is a list of instructions on how to install it on
> Vista or Windows 7. I've asked this in the forum but I have not received any
> response. Is this too much to ask?

Maybe I'm missing something, but I see 5 responses from 2 of our
engineers over the last 2 days on that thread, all asking valid
questions and trying to figure out why this is failing for you, when
it does not for the vast majority of other users. I appreciate that
you do not want to do a manual installation, but for us to understand
why it is failing in your particular case, we need to do some
exploration.

Sachin told you how to install in a nutshell, but I guess you missed
that so here are the detail walkthrough instructions:
http://www.enterprisedb.com/learning/pginst_guide.do

I don't think that's bad for *free* support.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On Thu, Apr 1, 2010 at 8:24 AM, Craig Ringer
<craig(at)postnewspapers(dot)com(dot)au> wrote:
> Thomas Kellerer wrote:
>
>> All the posts seem to share the same root cause: the data directory has
>> been put into "c:\Program Files" but a regular user does not have write
>> permissions on that directory.
>
> Yep. They're also often confused by various steps people have tried
> while attempting to get it working, making it very hard to trace what
> actually happened initially and why.

Actually, most errors used to happen when the user wasn't using that
directory. We finally tracked down what we believe to be the primary
outstanding cause of initdb failures and fixed it for 8.4.3/8.3.10 btw
- it took a brainstorming session and a great deal of thought from
Magnus and I, as well as the help of a user from a US .gov site with
very tight security procedures to track it down.

>> I do not like the installer's suggestion to put the data directory into
>> c:\Program Files either, I think this should default to %APPDATA%

The reasons why we do that have been discussed here before - check the archives.

As a point of reference - wanna guess where Microsoft SQL Server puts
it's data by default?

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

> Maybe I'm missing something, but I see 5 responses from 2 of our
> engineers over the last 2 days on that thread, all asking valid
> questions and trying to figure out why this is failing for you, when
> it does not for the vast majority of other users. I appreciate that
> you do not want to do a manual installation, but for us to understand
> why it is failing in your particular case, we need to do some
> exploration.
>

It is not the count that matters. It is the quality. Even after giving
logs, your folks are unable to figure out the problem. I am facing the
same problem that was faced by a lot of users on the forum and not one
was resolved successfully. Otherwise I would've moved ahead on my own. I
am interested in fixing the installer. I am not interested in manual
steps to get it working on my PC because there are a hundred other PCs
that I have to worry about and a fix in the installer would be right
step ahead. But someone has to admit that there is a problem in the
installer. All arguments in this thread are junk because 8.3 installer
for win32 from postgresql.org WORKS using the same conditions on
Vista/2003/7 everywhere. It is nothing to do with APPDATA or any such
thing. Something that worked was broken, it's that simple. And nobody
wants to know what was.

> Sachin told you how to install in a nutshell, but I guess you missed
> that so here are the detail walkthrough instructions:
> http://www.enterprisedb.com/learning/pginst_guide.do
>
>
> I don't think that's bad for *free* support.
>

If you mean the number of responses, yes it's great.

The reason I posted this in the general newsgroup is because I thought
others would like to know what's going on. But I think this is a
newsgroup with a bunch of inflated egos who want to do everything else
rather than address the problem. A typical open-source group.
Evangelizing PGSQL was a mistake.

Thanks for all your help and good luck to everyone!
-n.

If you really want to help and make the installer a better experience, i
asked for helping me out debug the issue
"Run the initcluster.vbs and let us know at what line number you are
getting the 'Object Required' error message".

But all you replied was : - " I need step by step procedure to install
it on Vista or Windows 7, I dont want bits and pieces stuff"..

And then you expect us to help out. If you really care then help out,
there is just no point saying, that was working and that's not again and
again.

> If you mean the number of responses, yes it's great.
>
> The reason I posted this in the general newsgroup is because I thought
> others would like to know what's going on. But I think this is a
> newsgroup with a bunch of inflated egos who want to do everything else
> rather than address the problem. A typical open-source group.
> Evangelizing PGSQL was a mistake.
>

> Thanks for all your help and good luck to everyone!
> -n.
>

--
Regards,
Sachin Srivastava
EnterpriseDB <http://www.enterprisedb.com>, the Enterprise Postgres
<http://www.enterprisedb.com> company.

2010/4/1 Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>:
>> instead of %ProgramFile%. I bet half of the problems would go away if
>> the installer refused to put the data directory into c:\Program Files.
>
> Yep - it's not a clever place to put it.

IIRC, that was modeled on where Microsofts own SQL Server put it's
data files by default. Does anybody know if that has changed recently?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Thu, Apr 1, 2010 at 10:35 AM, Nikhil G. Daddikar <ngd(at)celoxis(dot)com> wrote:
> It is not the count that matters. It is the quality. Even after giving logs,
> your folks are unable to figure out the problem.

No, because clearly it is not a simple issue.

> I am facing the same
> problem that was faced by a lot of users on the forum and not one was
> resolved successfully.

Actually, not you weren't. Of the cases you quoted, some were from
completely different pieces of software, one was a request for
information which a sales guy followed up, and the remaining ones
included some people for whom a fix was found, some for whom one
wasn't, and some who didn't provide the required information to
diagnose the problem.

Also, there are a number of different issues that can cause an initdb
failure. We've worked hard to work around as many of those as possible
in the installer, but some are just damn hard to track down - and
pretty much impossible if people won't help us when they see a
failure. Just because you see the same outward symptoms, it does not
mean that you have the same underlying problem.

> Otherwise I would've moved ahead on my own. I am
> interested in fixing the installer. I am not interested in manual steps to
> get it working on my PC because there are a hundred other PCs that I have to
> worry about and a fix in the installer would be right step ahead. But
> someone has to admit that there is a problem in the installer.

Noone has said there isn't some situation that the installer cannot
properly handle - I'm sure there are more than a few, knowing how
widely installations of Windows can vary from machine to machine, or
domain to domain.

We want to fix any issues in the installer - but we cannot simply
guess what's going wrong. That can take time and effort to understand.

> The reason I posted this in the general newsgroup is because I thought
> others would like to know what's going on. But I think this is a newsgroup
> with a bunch of inflated egos who want to do everything else rather than
> address the problem. A typical open-source group. Evangelizing PGSQL was a
> mistake.

You've had a people try to help you on the forum.

You've had people here try to suggest how you might help us to help you.

You've even had someone someone telephone your office to try to help
(again, for free), who you refused to talk to.

Unless you are prepared to help us understand exactly what is unique
about your systems so we can figure out what is going wrong, then we
cannot help you.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On Thu, Apr 1, 2010 at 10:50 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> 2010/4/1 Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>:
>>> instead of %ProgramFile%. I bet half of the problems would go away if
>>> the installer refused to put the data directory into c:\Program Files.
>>
>> Yep - it's not a clever place to put it.
>
> IIRC, that was modeled on where Microsofts own SQL Server put it's
> data files by default. Does anybody know if that has changed recently?

It hasn't. I checked 2008 this morning.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Magnus Hagander, 01.04.2010 11:50:
> 2010/4/1 Craig Ringer<craig(at)postnewspapers(dot)com(dot)au>:
>>> instead of %ProgramFile%. I bet half of the problems would go away if
>>> the installer refused to put the data directory into c:\Program Files.
>>
>> Yep - it's not a clever place to put it.
>
> IIRC, that was modeled on where Microsofts own SQL Server put it's
> data files by default.
>

Shouldn't Postgres make it better than Microsoft ;)

Folks,

I received a call from EnterpriseDB trying to understand what the
problem is. We are scheduled to meet on Monday. I will post the findings
as soon as I have something concrete.

Thank you all.
-n.

> Unless you are prepared to help us understand exactly what is unique
> about your systems so we can figure out what is going wrong, then we
> cannot help you.
>

> It is not the count that matters. It is the quality. Even after giving logs,
> your folks are unable to figure out the problem. I am facing the same
> problem that was faced by a lot of users on the forum and not one was
> resolved successfully. Otherwise I would've moved ahead on my own. I am
> interested in fixing the installer. I am not interested in manual steps to
> get it working on my PC because there are a hundred other PCs that I have to
> worry about and a fix in the installer would be right step ahead. But
> someone has to admit that there is a problem in the installer. All arguments
> in this thread are junk because 8.3 installer for win32 from postgresql.org
> WORKS using the same conditions on Vista/2003/7 everywhere. It is nothing to
> do with APPDATA or any such thing. Something that worked was broken, it's
> that simple. And nobody wants to know what was.

Are you sure about that? Have you actually tested that? Even if you
find that the old 8.3 pginstaller works where the EDB installer
failed, that doesn't actually demonstrate that pginstaller is
inherently superior to the EDB installer. It is likely due to a fluke.
Perhaps it is down to something vestigial from pginstaller remaining.

Your incredible sense of entitlement is very irritating. Your unctuous
statement that "Evangelizing PGSQL was a mistake", as if you expect a
contrite letter, is just too much to bear.

You're the one with the big ego. I think that people's responses so
far have been very subdued, considering how obnoxious you've been. In
your first e-mail, you called the EDB one click installer "a scam".

I think that the EDB one click installer for windows is a great piece
of software, and I'm very grateful to Dave and the EDB people for
maintaining it, as well as the stack builder that it comes with. I
think we could all do without hearing your idle whining and conspiracy
theories about the PostgreSQL global development group having an
anti-windows bias. In fact, the PostgreSQL devs regularly bend over
backwards to support windows.

Regards,
Peter Geoghegan

On Thu, Apr 1, 2010 at 12:15 PM, Peter Geoghegan
<peter(dot)geoghegan86(at)gmail(dot)com> wrote:
> I think that the EDB one click installer for windows is a great piece
> of software, and I'm very grateful to Dave and the EDB people for
> maintaining it, as well as the stack builder that it comes with.

Thank you Peter - we appreciate the thought.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Peter,

> Are you sure about that? Have you actually tested that? Even if you
> find that the old 8.3 pginstaller works where the EDB installer
> failed, that doesn't actually demonstrate that pginstaller is
> inherently superior to the EDB installer. It is likely due to a fluke.
> Perhaps it is down to something vestigial from pginstaller remaining.

All I am saying is that the folks check out what the diff between EDB
and the "old" installer is without jumping to conclusions about APPDATA
or whatever because the old installer worked. Maybe it is a fluke but
isn't it worth investigating in order to fix the installer?

> Your incredible sense of entitlement is very irritating. Your unctuous
> statement that "Evangelizing PGSQL was a mistake", as if you expect a
> contrite letter, is just too much to bear.
> You're the one with the big ego. I think that people's responses so
> far have been very subdued, considering how obnoxious you've been. In
> your first e-mail, you called the EDB one click installer "a scam".

Sometimes we say things that we don't actually mean and this was one of
them. I understand I have hurt some folks and I ask forgiveness from all
of them.

I look forward to working with EDB and help them in fixing the issues.

-n.

Dave,

> >
> > IIRC, that was modeled on where Microsofts own SQL Server put it's
> > data files by default. Does anybody know if that has changed recently?
>
> It hasn't. I checked 2008 this morning.
>
>
And how does SQL Server fiddle that with Windows 7? My experience is that W7
is "not amused" when trying to put data below Programs and Files (x86), as I
described within:

http://archives.postgresql.org/pgsql-general/2009-01/msg00783.php

The default as of know is \ProgramData\<application>

Best wishes,

Harald

--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
%s is too gigantic of an industry to bend to the whims of reality

On Thu, Apr 1, 2010 at 12:35 PM, Nikhil G. Daddikar <ngd(at)celoxis(dot)com> wrote:

> All I am saying is that the folks check out what the diff between EDB and
> the "old" installer is without jumping to conclusions about APPDATA or
> whatever because the old installer worked. Maybe it is a fluke but isn't it
> worth investigating in order to fix the installer?

The old installer used entirely different technology, which is not
easily comparable. It was also never tested on Windows 7.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On Thu, Apr 1, 2010 at 12:40 PM, Massa, Harald Armin <chef(at)ghum(dot)de> wrote:
> Dave,
>>
>> >
>> > IIRC, that was modeled on where Microsofts own SQL Server put it's
>> > data files by default. Does anybody know if that has changed recently?
>>
>> It hasn't. I checked 2008 this morning.
>>
>
> And how does SQL Server fiddle that with Windows 7? My experience is that W7
> is "not amused" when trying to put data below Programs and Files (x86), as I
> described within:
> http://archives.postgresql.org/pgsql-general/2009-01/msg00783.php

I have no idea how SQL Server does it. There was a minor amount of
magic required to get our installers to work without Windows trying to
redirect the writes, but I forget what that was exactly now.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

This is of interest to me, because something similar happens on the
Mac (with the one-click installer).

The data directory is placed in a file that user 'postgres' has
permission on. Of course, this is a new user, created by postgres,
but what it ends up meaning is that I run all my postgres files under
root instead of in my user directory.

Now, I know that is stupid, cludgy, and probably un-American, but it
was the simplest work-around I came up with.

I wonder if the problems arise because user 'postgres' is being
created on the Windows machine and no one expects him, knows he's
there, or has ever met him?

John

On Apr 1, 2010, at 9:09 AM, Thomas Kellerer wrote:

> Nikhil G. Daddikar, 01.04.2010 08:04:
>>
>> In about 30 seconds I found the following unanswered threads
>> relating to
>> installation on Windows Vista. If anybody is interested I can find
>> more.
>
> The problem with this kind of statistics is that you will only find
> people who complain, you'll never find people who do not complain
> because they have no problems. Actually that's true for all internet
> forums or mailing lists: you'll seldomly find people posting
> something like "Hey everything works fine, I had no problems".
>
> All the posts seem to share the same root cause: the data directory
> has been put into "c:\Program Files" but a regular user does not
> have write permissions on that directory. As the installer is
> usually run with Administrator rights, the directory can be created
> but the service (or initdb) runs under a normal user account that
> cannot write to that directory because.
>
> I do not like the installer's suggestion to put the data directory
> into c:\Program Files either, I think this should default to %APPDATA
> % instead of %ProgramFile%. I bet half of the problems would go away
> if the installer refused to put the data directory into c:\Program
> Files.
>
> Given the fact that Microsoft finally tries to enforce people not to
> work as Administrators makes this even more important.
>
> My suggestion is to try to use a different data directory when
> installing Postgres and make sure that the postgres service account
> is allowed to read and write that directory.
>
> Personally I switched to using the ZIP packages completely because
> it is so much easer (unzip, initdb, pg_ctl -register, done)
>
> Thomas
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

On 1/04/2010 3:19 PM, Nikhil G. Daddikar wrote:
>
>
>
> On 01-04-2010 12:39, Thomas Kellerer wrote:
>> Nikhil G. Daddikar, 01.04.2010 08:04:
>>>
>>> In about 30 seconds I found the following unanswered threads relating to
>>> installation on Windows Vista. If anybody is interested I can find more.
>>
>> The problem with this kind of statistics is that you will only find
>> people who complain, you'll never find people who do not complain
>> because they have no problems. Actually that's true for all internet
>> forums or mailing lists: you'll seldomly find people posting something
>> like "Hey everything works fine, I had no problems".
>
> I agree... but they are still unanswered. And what else can I do. I am
> facing problems on multiple computers, my customers are facing problems
> as well. NOBODY till date has managed to install 8.4 on Vista using the
> 1-click installer and EVERYBODY has managed to install the 8.3 installer
> (from postgresql.org) on Vista. DOES THIS COUNT AS A VALID STATISTIC?
> And yes, i have tried installing it in C:\Postgresql as well.
> Interesting to note that 8.3 installer from postgresql.org installs
> perfectly in 'C:\Program Files' even on Vista. No use blaming Windows
> all the time. It is the installer that is buggy.

Yet I can install 8.4 from the one-click on my Vista box with no issues.

So - what makes your systems different? Let's figure this out and fix
it. I'm going to provide a profile of my machine's configuration. Please
compare it with yours, focusing on common points across the machines
you've seen issues with.

OTHER PEOPLE, PLEASE CHIME IN WITH SIMILAR DETAILS. (Perhaps we need a
trouble-shooting data collector app. Hmm. I might be up to that...)

My Vista machine runs build 6002 (Service Pack 2) according to winver.exe .

I log in as an Administrator-enabled user, but have UAC turned on. This
means that in fact I'm using non-admin rights unless/until I accept a
UAC prompt.

For a virus scanner, it has Microsoft Security Essentials installed, but
real-time protection is turned off. There is no resident anti-spyware
software. It does not have 3rd-party desktop search installed.

It's never had 8.3 installed, by msi or oneclick. (When you provide
this, make sure to mention if/how you uninstalled 8.3 before installing
8.4, whether you removed the postgres user account, etc).

A running process list from Process Explorer is attached.

When I launch winver.exe there are no non-Microsoft DLLs loaded
according to Process Explorer. (View, Show lower pane, DLLs). So there's
nothing hooking into every process launched on the machine.

Please follow up with equivalent details on your systems. Meanwhile I'm
going to uninstall 8.4 and reinstall it. If that works I'll delete the
user account and all registry entries, install 8.3 .msi, uninstall that,
and then install 8.4. See what might be going on.

--
Craig Ringer

On 1/04/2010 5:35 PM, Nikhil G. Daddikar wrote:

> It is not the count that matters. It is the quality. Even after giving
> logs, your folks are unable to figure out the problem. I am facing the
> same problem that was faced by a lot of users on the forum and not one
> was resolved successfully. Otherwise I would've moved ahead on my own. I
> am interested in fixing the installer. I am not interested in manual
> steps to get it working on my PC because there are a hundred other PCs
> that I have to worry about and a fix in the installer would be right
> step ahead. But someone has to admit that there is a problem in the
> installer. All arguments in this thread are junk because 8.3 installer
> for win32 from postgresql.org WORKS using the same conditions on
> Vista/2003/7 everywhere. It is nothing to do with APPDATA or any such
> thing.

> Something that worked was broken, it's that simple. And nobody
> wants to know what was.

Actually, we all want to know what it was. But you're not helping us
find out - see Sachin's request that you run the initcluster.vbs script
to collect some debug info.

One thing you need to understand is that nothing has been "broken".
Here's how it was:

MSI INSTALLER ONECLICK INSTALLER
8.3 [available] [available]
8.4 [discontinued] [available]

The MSI installer is *completely* *different*. It's not like Pg switched
over. The .msi installer was dropped because it was silly to duplicate
work that EDB was going to do anyway.

You perceive something as having been broken, but in fact you're using a
_different_ _product_ now. It's not working for you, and that is
something that needs addressing, but it's not like there was some change
that can just be reverted.

Now, clearly there's something _different_ about your machines that
makes the EDB installer fail on them, and not most systems. Let's try to
figure out what it is.

> The reason I posted this in the general newsgroup is because I thought
> others would like to know what's going on. But I think this is a
> newsgroup with a bunch of inflated egos who want to do everything else
> rather than address the problem.

You're rather selectively ignoring the people who're asking you for more
details, and trying to explain that since it works for them, they need
to figure out what makes your setup different in order to fix the problem.

Nobody's claiming the EDB installer is perfect anyway. They're just
pointing out that "doesn't work for you" isn't the same as "doesn't work
for anyone, broken and awful".

--
Craig Ringer

I will bet a bucket of day-old squid that this is a user rights problem.

On Apr 2, 2010, at 6:43 AM, Craig Ringer wrote:

> I log in as an Administrator-enabled user, but have UAC turned on.
> This means that in fact I'm using non-admin rights unless/until I
> accept a UAC prompt.

The 8.4.2 documentation says:

"The default user name is your Unix user name, as is the default
database name."

Not so much. My one-click installer creates a user 'postgres' who
becomes the default user name...as well as the owner of the data file.

Is postgres arguing with itself here? Or at least in its one-click
incarnation on the Mac.

In Nikhil's world, I would say that the clients are pretty carefully
tightened down in terms of privileges. And apparently Vista has
enabled more tightening down.

John

On Apr 2, 2010, at 6:43 AM, Craig Ringer wrote:

> I log in as an Administrator-enabled user, but have UAC turned on.
> This means that in fact I'm using non-admin rights unless/until I
> accept a UAC prompt.

John Gage wrote:
> The 8.4.2 documentation says:
>
> "The default user name is your Unix user name, as is the default
> database name."

when you as a user connect to the database server the commands like
psql, pg_dump, etc all use your unix username as the default for the
database username, and your username as teh default for the database
name, unless you specify a different user and/or database on hte command
line.

Then I don't understand why the installer doesn't do the same thing.

Or, in the alternative, why it doesn't ask you what you want these
parameters to be.

I would say that, typically, someone installing postgres does it,
conceivably, as root or, more likely, as a user.

What he or she doesn't do is install it as user 'postgres'.

Yet, that is what the one-click installer does. I do not believe that
this is intuitive. What is more, gratuitiously adding a user to the
system doesn't seem to make a whole lot of sense.

In addition, all other one-click installations on the Mac either don't
ask for root privileges, because they don't need them, or ask for
them, but still install under the current user. Some installations
will even ask whether you want the application usable by all users of
the machine or just you.

But none, repeat none, create a new user.

What is more, through standard unix commands such as "who" or "cat /
etc/passwd", I cannot find the user 'postgres' on my machine...even
though he is the owner of the Postgres data files...on my machine.

There's the rub. 'postgres' owns files...my files...on my machine,
yet he is not on my machine. Not good.

I should add that I am an accolyte of Postgres and am only raising
this (possible) issue in the most positive spirit I am capable of. In
addition, I think that the people on this list are superb, and the
responses are unbelievably helpful and accurate.

John

On Apr 2, 2010, at 8:29 AM, John R Pierce wrote:

> John Gage wrote:
>> The 8.4.2 documentation says:
>>
>> "The default user name is your Unix user name, as is the default
>> database name."
>
> when you as a user connect to the database server the commands like
> psql, pg_dump, etc all use your unix username as the default for the
> database username, and your username as teh default for the database
> name, unless you specify a different user and/or database on hte
> command line.
>
>

There is a CLI option --serviceaccount <username> which a user can use
to make any user the owner of postgres service and data files.

Also, if you choose 'postgres' as the service account and the 'postgres'
user doesn't exist. The installer will create postgres as a 'locked'
user account. Thats the reason you dont see 'postgres' listed as any
other normal user. These steps were taken to enhance the security of the
data folder.

Again, anytime a user is free to use any account as the service account
and not use 'postgres'.

On 4/2/10 12:37 PM, John Gage wrote:
> Then I don't understand why the installer doesn't do the same thing.
>
> Or, in the alternative, why it doesn't ask you what you want these
> parameters to be.
>
> I would say that, typically, someone installing postgres does it,
> conceivably, as root or, more likely, as a user.
>
> What he or she doesn't do is install it as user 'postgres'.
>
> Yet, that is what the one-click installer does. I do not believe that
> this is intuitive. What is more, gratuitiously adding a user to the
> system doesn't seem to make a whole lot of sense.
>
> In addition, all other one-click installations on the Mac either don't
> ask for root privileges, because they don't need them, or ask for
> them, but still install under the current user. Some installations
> will even ask whether you want the application usable by all users of
> the machine or just you.
>
> But none, repeat none, create a new user.
>
> What is more, through standard unix commands such as "who" or "cat
> /etc/passwd", I cannot find the user 'postgres' on my machine...even
> though he is the owner of the Postgres data files...on my machine.
>
> There's the rub. 'postgres' owns files...my files...on my machine,
> yet he is not on my machine. Not good.
>
> I should add that I am an accolyte of Postgres and am only raising
> this (possible) issue in the most positive spirit I am capable of. In
> addition, I think that the people on this list are superb, and the
> responses are unbelievably helpful and accurate.
>
> John
>
>
> On Apr 2, 2010, at 8:29 AM, John R Pierce wrote:
>
>> John Gage wrote:
>>> The 8.4.2 documentation says:
>>>
>>> "The default user name is your Unix user name, as is the default
>>> database name."
>>
>> when you as a user connect to the database server the commands like
>> psql, pg_dump, etc all use your unix username as the default for the
>> database username, and your username as teh default for the database
>> name, unless you specify a different user and/or database on hte
>> command line.
>>
>>
>
>

--
Regards,
Sachin Srivastava
EnterpriseDB <http://www.enterprisedb.com>, the Enterprise Postgres
<http://www.enterprisedb.com> company.

John Gage wrote:
> Then I don't understand why the installer doesn't do the same thing.
>
> Or, in the alternative, why it doesn't ask you what you want these
> parameters to be.
>
> I would say that, typically, someone installing postgres does it,
> conceivably, as root or, more likely, as a user.
>
> What he or she doesn't do is install it as user 'postgres'.
>

but, thats exactly how most all data base servers operate. the server
daemon run as their own private user. Oracle runs under whatever DBA
account you configure it to run as (usually the user 'oracle').
Microsoft installs SQL Server's services with its own user account.
Apache HTTP is generally run as http or apache or webuser on unix
systems, not as one of the regular interactive users. etc etc.

> Yet, that is what the one-click installer does. I do not believe that
> this is intuitive. What is more, gratuitiously adding a user to the
> system doesn't seem to make a whole lot of sense.
>

maybe the documentation needs some more explanations, then.

> In addition, all other one-click installations on the Mac either don't
> ask for root privileges, because they don't need them, or ask for
> them, but still install under the current user. Some installations
> will even ask whether you want the application usable by all users of
> the machine or just you.
>

so on a mac, any server daemons you install run with your user
credentials? really?

> But none, repeat none, create a new user.
>
> What is more, through standard unix commands such as "who" or "cat
> /etc/passwd", I cannot find the user 'postgres' on my machine...even
> though he is the owner of the Postgres data files...on my machine.
>
> There's the rub. 'postgres' owns files...my files...on my machine,
> yet he is not on my machine. Not good.

thats not even possible unless the macos doesn't use /etc/passwd as its
user database. I dunno much about macosx, but everything I hear about
it sounds like they took unix and twisted it all around.

I lied. The Unix id command produces:

JohnGage:~ johngage$ id postgres
uid=502(postgres) gid=1(daemon) groups=1(daemon)

The one-click installer should be very clear about all this.

I think we are very close to Steve Jobs "Chain of Pain" here.

And, once again, I am absolutely dedicated to Postgres.

John

On Apr 2, 2010, at 8:29 AM, John R Pierce wrote:

> John Gage wrote:
>> The 8.4.2 documentation says:
>>
>> "The default user name is your Unix user name, as is the default
>> database name."
>
> when you as a user connect to the database server the commands like
> psql, pg_dump, etc all use your unix username as the default for the
> database username, and your username as teh default for the database
> name, unless you specify a different user and/or database on hte
> command line.
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

If I do cat /etc/passwd, I get the following, which does not include
'postgres'. Yet id knows about 'postgres'. And 'postgres' owns the
data.

nobody:*:-2:-2:Unprivileged User:/var/empty:/usr/bin/false
root:*:0:0:System Administrator:/var/root:/bin/sh
daemon:*:1:1:System Services:/var/root:/usr/bin/false
_uucp:*:4:4:Unix to Unix Copy Protocol:/var/spool/uucp:/usr/sbin/uucico
_lp:*:26:26:Printing Services:/var/spool/cups:/usr/bin/false
_postfix:*:27:27:Postfix Mail Server:/var/spool/postfix:/usr/bin/false
_mcxalr:*:54:54:MCX AppLaunch:/var/empty:/usr/bin/false
_pcastagent:*:55:55:Podcast Producer Agent:/var/pcast/agent:/usr/bin/
false
_pcastserver:*:56:56:Podcast Producer Server:/var/pcast/server:/usr/
bin/false
_serialnumberd:*:58:58:Serial Number Daemon:/var/empty:/usr/bin/false
_devdocs:*:59:59:Developer Documentation:/var/empty:/usr/bin/false
_sandbox:*:60:60:Seatbelt:/var/empty:/usr/bin/false
_mdnsresponder:*:65:65:mDNSResponder:/var/empty:/usr/bin/false
_ard:*:67:67:Apple Remote Desktop:/var/empty:/usr/bin/false
_www:*:70:70:World Wide Web Server:/Library/WebServer:/usr/bin/false
_eppc:*:71:71:Apple Events User:/var/empty:/usr/bin/false
_cvs:*:72:72:CVS Server:/var/empty:/usr/bin/false
_svn:*:73:73:SVN Server:/var/empty:/usr/bin/false
_mysql:*:74:74:MySQL Server:/var/empty:/usr/bin/false
_sshd:*:75:75:sshd Privilege separation:/var/empty:/usr/bin/false
_qtss:*:76:76:QuickTime Streaming Server:/var/empty:/usr/bin/false
_cyrus:*:77:6:Cyrus Administrator:/var/imap:/usr/bin/false
_mailman:*:78:78:Mailman List Server:/var/empty:/usr/bin/false
_appserver:*:79:79:Application Server:/var/empty:/usr/bin/false
_clamav:*:82:82:ClamAV Daemon:/var/virusmails:/usr/bin/false
_amavisd:*:83:83:AMaViS Daemon:/var/virusmails:/usr/bin/false
_jabber:*:84:84:Jabber XMPP Server:/var/empty:/usr/bin/false
_xgridcontroller:*:85:85:Xgrid Controller:/var/xgrid/controller:/usr/
bin/false
_xgridagent:*:86:86:Xgrid Agent:/var/xgrid/agent:/usr/bin/false
_appowner:*:87:87:Application Owner:/var/empty:/usr/bin/false
_windowserver:*:88:88:WindowServer:/var/empty:/usr/bin/false
_spotlight:*:89:89:Spotlight:/var/empty:/usr/bin/false
_tokend:*:91:91:Token Daemon:/var/empty:/usr/bin/false
_securityagent:*:92:92:SecurityAgent:/var/empty:/usr/bin/false
_calendar:*:93:93:Calendar:/var/empty:/usr/bin/false
_teamsserver:*:94:94:TeamsServer:/var/teamsserver:/usr/bin/false
_update_sharing:*:95:-2:Update Sharing:/var/empty:/usr/bin/false
_installer:*:96:-2:Installer:/var/empty:/usr/bin/false
_atsserver:*:97:97:ATS Server:/var/empty:/usr/bin/false
_unknown:*:99:99:Unknown User:/var/empty:/usr/bin/false

John

On Apr 2, 2010, at 9:29 AM, John R Pierce wrote:

> thats not even possible unless the macos doesn't use /etc/passwd as
> its user database. I dunno much about macosx, but everything I
> hear about it sounds like they took unix and twisted it all around.

There is a CLI option where? Forgive my ignorance, please. Does it
appear in the one-click installer?

John

On Apr 2, 2010, at 9:19 AM, Sachin Srivastava wrote:

> There is a CLI option --serviceaccount <username> which a user can
> use to make any user the owner of postgres service and data files.
>
> Also, if you choose 'postgres' as the service account and the
> 'postgres' user doesn't exist. The installer will create postgres as
> a 'locked' user account. Thats the reason you dont see 'postgres'
> listed as any other normal user. These steps were taken to enhance
> the security of the data folder.
>
> Again, anytime a user is free to use any account as the service
> account and not use 'postgres'.
>
> On 4/2/10 12:37 PM, John Gage wrote:
>>
>> Then I don't understand why the installer doesn't do the same thing.
>>
>> Or, in the alternative, why it doesn't ask you what you want these
>> parameters to be.
>>
>> I would say that, typically, someone installing postgres does it,
>> conceivably, as root or, more likely, as a user.
>>
>> What he or she doesn't do is install it as user 'postgres'.
>>
>> Yet, that is what the one-click installer does. I do not believe
>> that this is intuitive. What is more, gratuitiously adding a user
>> to the system doesn't seem to make a whole lot of sense.
>>
>> In addition, all other one-click installations on the Mac either
>> don't ask for root privileges, because they don't need them, or ask
>> for them, but still install under the current user. Some
>> installations will even ask whether you want the application usable
>> by all users of the machine or just you.
>>
>> But none, repeat none, create a new user.
>>
>> What is more, through standard unix commands such as "who" or "cat /
>> etc/passwd", I cannot find the user 'postgres' on my machine...even
>> though he is the owner of the Postgres data files...on my machine.
>>
>> There's the rub. 'postgres' owns files...my files...on my machine,
>> yet he is not on my machine. Not good.
>>
>> I should add that I am an accolyte of Postgres and am only raising
>> this (possible) issue in the most positive spirit I am capable of.
>> In addition, I think that the people on this list are superb, and
>> the responses are unbelievably helpful and accurate.
>>
>> John
>>
>>
>> On Apr 2, 2010, at 8:29 AM, John R Pierce wrote:
>>
>>> John Gage wrote:
>>>> The 8.4.2 documentation says:
>>>>
>>>> "The default user name is your Unix user name, as is the default
>>>> database name."
>>>
>>> when you as a user connect to the database server the commands
>>> like psql, pg_dump, etc all use your unix username as the default
>>> for the database username, and your username as teh default for
>>> the database name, unless you specify a different user and/or
>>> database on hte command line.
>>>
>>>
>>
>>
>
>
> --
> Regards,
> Sachin Srivastava
> EnterpriseDB, the Enterprise Postgres company.

Thats what i get:

edbs-MacBook:~ sachin$ hdiutil attach postgresql-8.4.3-1-osx.dmg
expected CRC32 $F9B026D4
/dev/disk1 Apple_partition_scheme
/dev/disk1s1 Apple_partition_map
/dev/disk1s2 Apple_HFS
/Volumes/PostgreSQL 8.4.3-1
edbs-MacBook:~ sachin$ sudo /Volumes/PostgreSQL\
8.4.3-1/postgresql-8.4.3-1-osx.app/Contents/MacOS/installbuilder.sh --help
Password:
PostgreSQL 8.4
Usage:

--help Display the list of valid options

--version Display product information

--optionfile <optionfile> Installation option file
Default:

--unattendedmodeui <unattendedmodeui> Unattended Mode UI
Default: none
Allowed: none minimal minimalWithDialogs

--debuglevel <debuglevel> Debug information level of verbosity
Default: 2
Allowed: 0 1 2 3 4

--mode <mode> Installation mode
Default: qt
Allowed: qt osx text unattended

--debugtrace <debugtrace> Debug filename
Default:

--installer-language <installer-language> Language selection
Default:
Allowed: en es

--extract-only <extract-only>
Default: 0

--superaccount <superaccount> Sets the user name of the database
superuser. Defaults to 'postgres'.
Default: postgres

--servicename <servicename> servicename.description
Default: postgresql-8.4

--serviceaccount <serviceaccount> Sets the operating system user
account that owns the server process. Defaults to 'postgres'.
Default: postgres

--create_shortcuts <create_shortcuts> Specifies whether or not menu
shortcuts should be created.
Default: 1

--prefix <prefix> Installation Directory
Default: /Library/PostgreSQL/8.4

--datadir <datadir> Data Directory
Default: /Library/PostgreSQL/8.4/data

--superpassword <superpassword> Password
Default:

--serverport <serverport> Port
Default: 5432

--locale <locale> Locale
Default:

--install_plpgsql <install_plpgsql> Install pl/pgsql in template1
database?
Default: 1

On 4/2/10 1:14 PM, John Gage wrote:
> There is a CLI option where? Forgive my ignorance, please. Does it
> appear in the one-click installer?
>
> John
>
>
> On Apr 2, 2010, at 9:19 AM, Sachin Srivastava wrote:
>
>> There is a CLI option --serviceaccount <username> which a user can
>> use to make any user the owner of postgres service and data files.
>>
>> Also, if you choose 'postgres' as the service account and the
>> 'postgres' user doesn't exist. The installer will create postgres as
>> a 'locked' user account. Thats the reason you dont see 'postgres'
>> listed as any other normal user. These steps were taken to enhance
>> the security of the data folder.
>>
>> Again, anytime a user is free to use any account as the service
>> account and not use 'postgres'.
>>
>> On 4/2/10 12:37 PM, John Gage wrote:
>>> Then I don't understand why the installer doesn't do the same thing.
>>>
>>> Or, in the alternative, why it doesn't ask you what you want these
>>> parameters to be.
>>>
>>> I would say that, typically, someone installing postgres does it,
>>> conceivably, as root or, more likely, as a user.
>>>
>>> What he or she doesn't do is install it as user 'postgres'.
>>>
>>> Yet, that is what the one-click installer does. I do not believe
>>> that this is intuitive. What is more, gratuitiously adding a user
>>> to the system doesn't seem to make a whole lot of sense.
>>>
>>> In addition, all other one-click installations on the Mac either
>>> don't ask for root privileges, because they don't need them, or ask
>>> for them, but still install under the current user. Some
>>> installations will even ask whether you want the application usable
>>> by all users of the machine or just you.
>>>
>>> But none, repeat none, create a new user.
>>>
>>> What is more, through standard unix commands such as "who" or "cat
>>> /etc/passwd", I cannot find the user 'postgres' on my machine...even
>>> though he is the owner of the Postgres data files...on my machine.
>>>
>>> There's the rub. 'postgres' owns files...my files...on my machine,
>>> yet he is not on my machine. Not good.
>>>
>>> I should add that I am an accolyte of Postgres and am only raising
>>> this (possible) issue in the most positive spirit I am capable of.
>>> In addition, I think that the people on this list are superb, and
>>> the responses are unbelievably helpful and accurate.
>>>
>>> John
>>>
>>>
>>> On Apr 2, 2010, at 8:29 AM, John R Pierce wrote:
>>>
>>>> John Gage wrote:
>>>>> The 8.4.2 documentation says:
>>>>>
>>>>> "The default user name is your Unix user name, as is the default
>>>>> database name."
>>>>
>>>> when you as a user connect to the database server the commands like
>>>> psql, pg_dump, etc all use your unix username as the default for
>>>> the database username, and your username as teh default for the
>>>> database name, unless you specify a different user and/or database
>>>> on hte command line.
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> Regards,
>> Sachin Srivastava
>> EnterpriseDB <http://www.enterprisedb.com>, the Enterprise Postgres
>> <http://www.enterprisedb.com> company.
>

--
Regards,
Sachin Srivastava
EnterpriseDB <http://www.enterprisedb.com>, the Enterprise Postgres
<http://www.enterprisedb.com> company.

On 2/04/2010 3:07 PM, John Gage wrote:

> Yet, that is what the one-click installer does. I do not believe that
> this is intuitive. What is more, gratuitiously adding a user to the
> system doesn't seem to make a whole lot of sense.

This is absolutely standard practice on UNIX systems, and on Windows
systems for secure server installations too. It allows the server to
isolate its self from the rest of the system, protecting both the system
and the server.

For example, every Windows XP system with the .NET framework 3.0
installed will have an ASPNET user on it. This user is used to run any
ASP.NET service processes so that Internet attackers can't overwrite
system files if they successfully exploit the asp.net services.

If PostgreSQL didn't add a user to the system, it'd have to:

a) Run as root. This is DANGEROUS as any security problem in PostgreSQL
that allows an attacker to force Pg to run code gets them root access.

b) Run as your user. What if you remove the user later - crunch, your
database just broke. If Pg was attacked successfully, the attacker
wouldn't get root ... but they would get the ability to access and
delete all your files.

Arguably (b) is an acceptable non-admin-install option for Mac OS X
systems for non-production use with unimportant test data you can afford
to lose. I'm not convinced it's a good idea, though.

Perhaps the PostgreSQL installer needs to inform users of this, though
(say a "help" button when asked about user account details).

> But none, repeat none, create a new user.

Most server products that attempt even the vaguest kind of security
should. Some even do ;-)

PostgreSQL isn't just a program, remember, it's a running database
service that might be network acecssible.

> What is more, through standard unix commands such as "who" or "cat
> /etc/passwd", I cannot find the user 'postgres' on my machine...even
> though he is the owner of the Postgres data files...on my machine.

Mac OS X isn't standard unix. Look in (depending on the Mac OS X
version) the NetInfo database, OpenDirectory, or whereever Apple hides
the user database this week.

You'll find that your own user account isn't in /etc/passwd either.

The postgres user *is* recognised by standard unix commands. "id
postgresql" will report its existence and details about it. It's just
not stored in /etc/passwd, because that's not how Mac OS X stores
account information (though there's some "legacy" stuff still in there).

> There's the rub. 'postgres' owns files...my files...on my machine, yet
> he is not on my machine. Not good.

Well, it's good for security. It also helps prevent people from
unwittingly going in and butchering the data directory - they're not
*meant* to be deleting things in there. This way they at least need
admin rights to do it.

What actual problem does it cause? Does the "postgres" user show up as
an additional login option on the login screen? Other than the notional
issue of not "owning" the files, what's the problem?

--
Craig Ringer

On 2/04/2010 3:42 PM, John Gage wrote:
> If I do cat /etc/passwd, I get the following, which does not include
> 'postgres'. Yet id knows about 'postgres'. And 'postgres' owns the data.

Try:

sudo dscl localhost -list NetInfo/Users

Apple don't use the usual UNIX utilities, they've got their own user
database. It's based on LDAP (as of 10.??'s OpenDirectory) and before
that was a more NIS-like service.

See dscl, netinfo, opendirectory documentation for more info.

--
Craig Ringer

On Fri, Apr 2, 2010 at 5:55 AM, John Gage <jsmgage(at)numericable(dot)fr> wrote:
> I will bet a bucket of day-old squid that this is a user rights problem.

They usually are, so I'm not taking that bet. We do see one regular
issue where Microsoft's cacl's command gives an unhelpful error for no
apparent reason: "The data is invalid." (usually when the user has
chosen a data directory *outside* of Program Files), but pretty much
everything else is in some way rights related. We just need to
understand what is different in each case...

FYI, as of 8.4.3/8.3.10, we know we do function correctly in the face
of a system secured according to the Federal Desktop Core
Configuration (FDCC) mandate
(http://www.microsoft.com/industry/government/federal/fdccdeployment.mspx),
but frankly Windows offers a million and one ways to tighten/screw up
security.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On Apr 2, 2010, at 10:28 AM, Craig Ringer wrote:

> b) Run as your user. What if you remove the user later - crunch,
> your database just broke. If Pg was attacked successfully, the
> attacker wouldn't get root ... but they would get the ability to
> access and delete all your files.
>
> Arguably (b) is an acceptable non-admin-install option for Mac OS X
> systems for non-production use with unimportant test data you can
> afford to lose. I'm not convinced it's a good idea, though.

First, I ask forgiveness for ignorance.

Second, the characterization in your second quoted paragraph is near-
sighted.

"Mac OS X systems for non-production use" means that I don't run a car
rental company. I don't. But "non-production"? Well, I use postgres
for things that are extremely important to me. What's more, I intend,
in the very near future, to have postgres as the back-end to an
internet system that will hopefully be in use by 85,000 French nursing
students, which I suppose is a form of "production". And when I load
the tables into the postgres implementation of whatever ISP I choose,
all the meshugas around permissions will disappear as far as I'm
concerned.

But "unimportant test data you can afford to lose"? Please. Anyone
who uses any database system for more than 10 minutes regards his or
her data as important and definitely not affordable to lose. I have
triply redundant back-up for my data. And the only reason I know that
'postgres' owns my data (or did) is that I wanted to back up the
files. Why else would I know?

Apple has a "database" product which is intended for individuals and
their data. It is called Bento. It has a charming interface and it
does what it does well. No chain of pain.

But there is one teeny, tiny problem. It's a ridiculous ersatz iTunes
clone that has nothing to do with databases. And, like everything
else in modern interfaces, the back-end is sqlite which doesn't cut it
one little bit. Bento files are sqlite files accessible by sqlite.
So you might as well run sqlite in the first place and get it over
with, but that's only if you're not really interested in a database.

Postgres, on the other hand, fully supports regular expressions, sql,
etc. etc. etc. etc. Postgres' clients psql and pgAdmin are perfectly
extraordinary. And finally the support in the embodiment of this list
is unbelievable. Incredible.

I don't think that b) is necessarily acceptable. But if it isn't,
then I really and truly wish that the very traditional way that
postgres wants to set itself up were more transparent and
controllable. It is a wish. Perhaps a fantasy. But a fantasy is a
wish (S. Freud).

I'm not quite as brain-dead as this statement makes me sound. I use
posgres' back-up system to back up the databases. I don't copy the
files.

On Apr 2, 2010, at 12:15 PM, John Gage wrote:

> And the only reason I know that 'postgres' owns my data (or did) is
> that I wanted to back up the files. Why else would I know?

I am incredibly interested in this.

In the first place, I did not load postgres from the command line as
you do here. I double-clicked. I also do not remember seeing the
usage options.

That being said, now that I have downloaded and installed the system,
how can I change:

>
> --serviceaccount <serviceaccount> Sets the operating system user
> account that owns the server process. Defaults to 'postgres'.
> Default: postgres

Or, in fact, must I re-install to change this? It looks like I have
to re-install.

Thank you very much for responding to my questions. I truly
appreciate it. Your support is welcome and superb.

John

On Apr 2, 2010, at 9:52 AM, Sachin Srivastava wrote:

> Thats what i get:
>
> edbs-MacBook:~ sachin$ hdiutil attach postgresql-8.4.3-1-osx.dmg
> expected CRC32 $F9B026D4
> /dev/disk1 Apple_partition_scheme
> /dev/disk1s1 Apple_partition_map
> /dev/disk1s2 Apple_HFS /Volumes/
> PostgreSQL 8.4.3-1
> edbs-MacBook:~ sachin$ sudo /Volumes/PostgreSQL\ 8.4.3-1/
> postgresql-8.4.3-1-osx.app/Contents/MacOS/installbuilder.sh --help
> Password:
> PostgreSQL 8.4
> Usage:
>
> --help Display the list of valid options
>
> --version Display product information
>
> --optionfile <optionfile> Installation option file
> Default:
>
> --unattendedmodeui <unattendedmodeui> Unattended Mode UI
> Default: none
> Allowed: none minimal
> minimalWithDialogs
>
> --debuglevel <debuglevel> Debug information level of verbosity
> Default: 2
> Allowed: 0 1 2 3 4
>
> --mode <mode> Installation mode
> Default: qt
> Allowed: qt osx text unattended
>
> --debugtrace <debugtrace> Debug filename
> Default:
>
> --installer-language <installer-language> Language selection
> Default:
> Allowed: en es
>
> --extract-only <extract-only>
> Default: 0
>
> --superaccount <superaccount> Sets the user name of the database
> superuser. Defaults to 'postgres'.
> Default: postgres
>
> --servicename <servicename> servicename.description
> Default: postgresql-8.4
>
> --serviceaccount <serviceaccount> Sets the operating system user
> account that owns the server process. Defaults to 'postgres'.
> Default: postgres
>
> --create_shortcuts <create_shortcuts> Specifies whether or not menu
> shortcuts should be created.
> Default: 1
>
> --prefix <prefix> Installation Directory
> Default: /Library/PostgreSQL/8.4
>
> --datadir <datadir> Data Directory
> Default: /Library/PostgreSQL/8.4/data
>
> --superpassword <superpassword> Password
> Default:
>
> --serverport <serverport> Port
> Default: 5432
>
> --locale <locale> Locale
> Default:
>
> --install_plpgsql <install_plpgsql> Install pl/pgsql in template1
> database?
> Default: 1
>
>
> On 4/2/10 1:14 PM, John Gage wrote:
>>
>> There is a CLI option where? Forgive my ignorance, please. Does
>> it appear in the one-click installer?
>>
>> John
>>
>>
>> On Apr 2, 2010, at 9:19 AM, Sachin Srivastava wrote:
>>
>>> There is a CLI option --serviceaccount <username> which a user can
>>> use to make any user the owner of postgres service and data files.
>>>
>>> Also, if you choose 'postgres' as the service account and the
>>> 'postgres' user doesn't exist. The installer will create postgres
>>> as a 'locked' user account. Thats the reason you dont see
>>> 'postgres' listed as any other normal user. These steps were taken
>>> to enhance the security of the data folder.
>>>
>>> Again, anytime a user is free to use any account as the service
>>> account and not use 'postgres'.
>>>
>>> On 4/2/10 12:37 PM, John Gage wrote:
>>>>
>>>> Then I don't understand why the installer doesn't do the same
>>>> thing.
>>>>
>>>> Or, in the alternative, why it doesn't ask you what you want
>>>> these parameters to be.
>>>>
>>>> I would say that, typically, someone installing postgres does it,
>>>> conceivably, as root or, more likely, as a user.
>>>>
>>>> What he or she doesn't do is install it as user 'postgres'.
>>>>
>>>> Yet, that is what the one-click installer does. I do not believe
>>>> that this is intuitive. What is more, gratuitiously adding a
>>>> user to the system doesn't seem to make a whole lot of sense.
>>>>
>>>> In addition, all other one-click installations on the Mac either
>>>> don't ask for root privileges, because they don't need them, or
>>>> ask for them, but still install under the current user. Some
>>>> installations will even ask whether you want the application
>>>> usable by all users of the machine or just you.
>>>>
>>>> But none, repeat none, create a new user.
>>>>
>>>> What is more, through standard unix commands such as "who" or
>>>> "cat /etc/passwd", I cannot find the user 'postgres' on my
>>>> machine...even though he is the owner of the Postgres data
>>>> files...on my machine.
>>>>
>>>> There's the rub. 'postgres' owns files...my files...on my
>>>> machine, yet he is not on my machine. Not good.
>>>>
>>>> I should add that I am an accolyte of Postgres and am only
>>>> raising this (possible) issue in the most positive spirit I am
>>>> capable of. In addition, I think that the people on this list
>>>> are superb, and the responses are unbelievably helpful and
>>>> accurate.
>>>>
>>>> John
>>>>
>>>>
>>>> On Apr 2, 2010, at 8:29 AM, John R Pierce wrote:
>>>>
>>>>> John Gage wrote:
>>>>>> The 8.4.2 documentation says:
>>>>>>
>>>>>> "The default user name is your Unix user name, as is the
>>>>>> default database name."
>>>>>
>>>>> when you as a user connect to the database server the commands
>>>>> like psql, pg_dump, etc all use your unix username as the
>>>>> default for the database username, and your username as teh
>>>>> default for the database name, unless you specify a different
>>>>> user and/or database on hte command line.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Sachin Srivastava
>>> EnterpriseDB, the Enterprise Postgres company.
>>
>
>
> --
> Regards,
> Sachin Srivastava
> EnterpriseDB, the Enterprise Postgres company.

Yes you need to re-install.. (uninstall and install again).
You can point the new installation to the old data directory if you want..

On 4/2/10 4:25 PM, John Gage wrote:
> I am incredibly interested in this.
>
> In the first place, I did not load postgres from the command line as
> you do here. I double-clicked. I also do not remember seeing the
> usage options.
>
> That being said, now that I have downloaded and installed the system,
> how can I change:
>
>>
>> --serviceaccount <serviceaccount> Sets the operating system user
>> account that owns the server process. Defaults to 'postgres'.
>> Default: postgres
>
> Or, in fact, must I re-install to change this? It looks like I have
> to re-install.
>
> Thank you very much for responding to my questions. I truly
> appreciate it. Your support is welcome and superb.
>
> John
>
>
>
>
>
> On Apr 2, 2010, at 9:52 AM, Sachin Srivastava wrote:
>
>> Thats what i get:
>>
>> edbs-MacBook:~ sachin$ hdiutil attach postgresql-8.4.3-1-osx.dmg
>> expected CRC32 $F9B026D4
>> /dev/disk1 Apple_partition_scheme
>> /dev/disk1s1 Apple_partition_map
>> /dev/disk1s2 Apple_HFS
>> /Volumes/PostgreSQL 8.4.3-1
>> edbs-MacBook:~ sachin$ sudo /Volumes/PostgreSQL\
>> 8.4.3-1/postgresql-8.4.3-1-osx.app/Contents/MacOS/installbuilder.sh
>> --help
>> Password:
>> PostgreSQL 8.4
>> Usage:
>>
>> --help Display the list of valid options
>>
>> --version Display product information
>>
>> --optionfile <optionfile> Installation option file
>> Default:
>>
>> --unattendedmodeui <unattendedmodeui> Unattended Mode UI
>> Default: none
>> Allowed: none minimal minimalWithDialogs
>>
>> --debuglevel <debuglevel> Debug information level of verbosity
>> Default: 2
>> Allowed: 0 1 2 3 4
>>
>> --mode <mode> Installation mode
>> Default: qt
>> Allowed: qt osx text unattended
>>
>> --debugtrace <debugtrace> Debug filename
>> Default:
>>
>> --installer-language <installer-language> Language selection
>> Default:
>> Allowed: en es
>>
>> --extract-only <extract-only>
>> Default: 0
>>
>> --superaccount <superaccount> Sets the user name of the database
>> superuser. Defaults to 'postgres'.
>> Default: postgres
>>
>> --servicename <servicename> servicename.description
>> Default: postgresql-8.4
>>
>> --serviceaccount <serviceaccount> Sets the operating system user
>> account that owns the server process. Defaults to 'postgres'.
>> Default: postgres
>>
>> --create_shortcuts <create_shortcuts> Specifies whether or not menu
>> shortcuts should be created.
>> Default: 1
>>
>> --prefix <prefix> Installation Directory
>> Default: /Library/PostgreSQL/8.4
>>
>> --datadir <datadir> Data Directory
>> Default: /Library/PostgreSQL/8.4/data
>>
>> --superpassword <superpassword> Password
>> Default:
>>
>> --serverport <serverport> Port
>> Default: 5432
>>
>> --locale <locale> Locale
>> Default:
>>
>> --install_plpgsql <install_plpgsql> Install pl/pgsql in template1
>> database?
>> Default: 1
>>
>>
>> On 4/2/10 1:14 PM, John Gage wrote:
>>> There is a CLI option where? Forgive my ignorance, please. Does it
>>> appear in the one-click installer?
>>>
>>> John
>>>
>>>
>>> On Apr 2, 2010, at 9:19 AM, Sachin Srivastava wrote:
>>>
>>>> There is a CLI option --serviceaccount <username> which a user can
>>>> use to make any user the owner of postgres service and data files.
>>>>
>>>> Also, if you choose 'postgres' as the service account and the
>>>> 'postgres' user doesn't exist. The installer will create postgres
>>>> as a 'locked' user account. Thats the reason you dont see
>>>> 'postgres' listed as any other normal user. These steps were taken
>>>> to enhance the security of the data folder.
>>>>
>>>> Again, anytime a user is free to use any account as the service
>>>> account and not use 'postgres'.
>>>>
>>>> On 4/2/10 12:37 PM, John Gage wrote:
>>>>> Then I don't understand why the installer doesn't do the same thing.
>>>>>
>>>>> Or, in the alternative, why it doesn't ask you what you want these
>>>>> parameters to be.
>>>>>
>>>>> I would say that, typically, someone installing postgres does it,
>>>>> conceivably, as root or, more likely, as a user.
>>>>>
>>>>> What he or she doesn't do is install it as user 'postgres'.
>>>>>
>>>>> Yet, that is what the one-click installer does. I do not believe
>>>>> that this is intuitive. What is more, gratuitiously adding a user
>>>>> to the system doesn't seem to make a whole lot of sense.
>>>>>
>>>>> In addition, all other one-click installations on the Mac either
>>>>> don't ask for root privileges, because they don't need them, or
>>>>> ask for them, but still install under the current user. Some
>>>>> installations will even ask whether you want the application
>>>>> usable by all users of the machine or just you.
>>>>>
>>>>> But none, repeat none, create a new user.
>>>>>
>>>>> What is more, through standard unix commands such as "who" or "cat
>>>>> /etc/passwd", I cannot find the user 'postgres' on my
>>>>> machine...even though he is the owner of the Postgres data
>>>>> files...on my machine.
>>>>>
>>>>> There's the rub. 'postgres' owns files...my files...on my
>>>>> machine, yet he is not on my machine. Not good.
>>>>>
>>>>> I should add that I am an accolyte of Postgres and am only raising
>>>>> this (possible) issue in the most positive spirit I am capable
>>>>> of. In addition, I think that the people on this list are superb,
>>>>> and the responses are unbelievably helpful and accurate.
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>> On Apr 2, 2010, at 8:29 AM, John R Pierce wrote:
>>>>>
>>>>>> John Gage wrote:
>>>>>>> The 8.4.2 documentation says:
>>>>>>>
>>>>>>> "The default user name is your Unix user name, as is the default
>>>>>>> database name."
>>>>>>
>>>>>> when you as a user connect to the database server the commands
>>>>>> like psql, pg_dump, etc all use your unix username as the default
>>>>>> for the database username, and your username as teh default for
>>>>>> the database name, unless you specify a different user and/or
>>>>>> database on hte command line.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Sachin Srivastava
>>>> EnterpriseDB <http://www.enterprisedb.com>, the Enterprise Postgres
>>>> <http://www.enterprisedb.com> company.
>>>
>>
>>
>> --
>> Regards,
>> Sachin Srivastava
>> EnterpriseDB <http://www.enterprisedb.com>, the Enterprise Postgres
>> <http://www.enterprisedb.com> company.
>

--
Regards,
Sachin Srivastava
EnterpriseDB <http://www.enterprisedb.com>, the Enterprise Postgres
<http://www.enterprisedb.com> company.

See attached attached OneClick_PG_Installer notes.

Igor Neyman

> -----Original Message-----
> From: John Gage [mailto:jsmgage(at)numericable(dot)fr]
> Sent: Friday, April 02, 2010 3:44 AM
> To: sachin(dot)srivastava(at)enterprisedb(dot)com
> Cc: pgsql-general(at)postgresql(dot)org
> Subject: Re: "1-Click" installer problems
>
> There is a CLI option where? Forgive my ignorance, please.
> Does it appear in the one-click installer?
>
> John
>
>
> On Apr 2, 2010, at 9:19 AM, Sachin Srivastava wrote:
>
>
> There is a CLI option --serviceaccount <username> which
> a user can use to make any user the owner of postgres service
> and data files.
>
> Also, if you choose 'postgres' as the service account
> and the 'postgres' user doesn't exist. The installer will
> create postgres as a 'locked' user account. Thats the reason
> you dont see 'postgres' listed as any other normal user.
> These steps were taken to enhance the security of the data folder.
>
> Again, anytime a user is free to use any account as the
> service account and not use 'postgres'.
>
> On 4/2/10 12:37 PM, John Gage wrote:
>
> Then I don't understand why the installer
> doesn't do the same thing.
>
> Or, in the alternative, why it doesn't ask you
> what you want these parameters to be.
>
> I would say that, typically, someone installing
> postgres does it, conceivably, as root or, more likely, as a user.
>
> What he or she doesn't do is install it as user
> 'postgres'.
>
> Yet, that is what the one-click installer does.
> I do not believe that this is intuitive. What is more,
> gratuitiously adding a user to the system doesn't seem to
> make a whole lot of sense.
>
> In addition, all other one-click installations
> on the Mac either don't ask for root privileges, because they
> don't need them, or ask for them, but still install under the
> current user. Some installations will even ask whether you
> want the application usable by all users of the machine or just you.
>
> But none, repeat none, create a new user.
>
> What is more, through standard unix commands
> such as "who" or "cat /etc/passwd", I cannot find the user
> 'postgres' on my machine...even though he is the owner of the
> Postgres data files...on my machine.
>
> There's the rub. 'postgres' owns files...my
> files...on my machine, yet he is not on my machine. Not good.
>
> I should add that I am an accolyte of Postgres
> and am only raising this (possible) issue in the most
> positive spirit I am capable of. In addition, I think that
> the people on this list are superb, and the responses are
> unbelievably helpful and accurate.
>
> John
>
>
> On Apr 2, 2010, at 8:29 AM, John R Pierce wrote:
>
>
>
> John Gage wrote:
>
>
> The 8.4.2 documentation says:
>
> "The default user name is your
> Unix user name, as is the default database name."
>
>
>
> when you as a user connect to the
> database server the commands like psql, pg_dump, etc all use
> your unix username as the default for the database username,
> and your username as teh default for the database name,
> unless you specify a different user and/or database on hte
> command line.
>
>
>
>
>
>
>
>
> --
> Regards,
> Sachin Srivastava
> EnterpriseDB <http://www.enterprisedb.com> , the
> Enterprise Postgres <http://www.enterprisedb.com> company.
>
>
>

Thanks very, very much for this. I am truly grateful.

On Apr 2, 2010, at 2:44 PM, Sachin Srivastava wrote:

> Yes you need to re-install.. (uninstall and install again).
> You can point the new installation to the old data directory if you
> want..
>
> On 4/2/10 4:25 PM, John Gage wrote:
>>
>> I am incredibly interested in this.
>>
>> In the first place, I did not load postgres from the command line
>> as you do here. I double-clicked. I also do not remember seeing
>> the usage options.
>>
>> That being said, now that I have downloaded and installed the
>> system, how can I change:
>>
>>>
>>> --serviceaccount <serviceaccount> Sets the operating system user
>>> account that owns the server process. Defaults to 'postgres'.
>>> Default: postgres
>>
>> Or, in fact, must I re-install to change this? It looks like I
>> have to re-install.

Nikhil,

Any movement on collecting some system comparision information so we can
start to figure out why the installer works on my systems, but not on yours?

I've just tested on a couple of other Vista systems (at work) without
problems, so there must be something different about your systems and
those of the others you've seen complain on the EDB forums. It'd be good
to find out what it is.

--
Craig Ringer

Hi Craig,

I have a call with EDB folks in an hour. I will post when I have
something concrete. Meanwhile, if you need anything specific about the
system, please let me know.

I have Vista Business x64 with Microsoft Security Essentials and UAC
turned ON. I have tried (at least) the following:

1. Default install of PG 8.4
2. Install of PG 8.4 in C:\Postgresql
3. Disable MS Security Essentials for C:\Postgresql and reinstall
4. Create a regular (non-admin) posgres user before installation
5. Delete that user and redo installation
6. Disable UAC and install in C:\Postgresql as well as in the default
directory
7. Enabled the "Administrator" user in Vista, logged in as that user
and installed

If you want me to try anything else, I can do that too.

Thanks,
Nikhil

On 06-04-2010 09:31, Craig Ringer wrote:
> Nikhil,
>
> Any movement on collecting some system comparision information so we can
> start to figure out why the installer works on my systems, but not on yours?
>
> I've just tested on a couple of other Vista systems (at work) without
> problems, so there must be something different about your systems and
> those of the others you've seen complain on the EDB forums. It'd be good
> to find out what it is.
>
> --
> Craig Ringer
>
>

Nikhil G. Daddikar wrote:
> Hi Craig,
>
> I have a call with EDB folks in an hour. I will post when I have
> something concrete. Meanwhile, if you need anything specific about the
> system, please let me know.
>
> I have Vista Business x64

Hmm. Your setup is the same as mine except that all the hosts I've
tested on are 32-bit installs. Interesting.

Unfortunately our friends at Microsoft don't let you simply re-install a
64-bit version, you have to go and buy the OS all over again at absurd
retail prices. I don't have an MSDN subscription at work. So I can't
personally test with x64 versions.

That's certainly something to start looking at, though. I'm sure that if
it was as simple as "the installer is broken on x64" it would've turned
up by now, but perhaps there's something else that only causes a problem
when installs are run on x64 hosts. Something to do with pathname
rewriting - Program Files (x86) for example?

--
Craig Ringer

I have tried earlier versions of 8.4 installer on Vista x32 and they'd
failed too. But let me try the latest installer again. I will let you know.

-n.

On 06-04-2010 10:09, Craig Ringer wrote:
> Nikhil G. Daddikar wrote:
>
>> Hi Craig,
>>
>> I have a call with EDB folks in an hour. I will post when I have
>> something concrete. Meanwhile, if you need anything specific about the
>> system, please let me know.
>>
>> I have Vista Business x64
>>
> Hmm. Your setup is the same as mine except that all the hosts I've
> tested on are 32-bit installs. Interesting.
>
> Unfortunately our friends at Microsoft don't let you simply re-install a
> 64-bit version, you have to go and buy the OS all over again at absurd
> retail prices. I don't have an MSDN subscription at work. So I can't
> personally test with x64 versions.
>
> That's certainly something to start looking at, though. I'm sure that if
> it was as simple as "the installer is broken on x64" it would've turned
> up by now, but perhaps there's something else that only causes a problem
> when installs are run on x64 hosts. Something to do with pathname
> rewriting - Program Files (x86) for example?
>
> --
> Craig Ringer
>

Nikhil G. Daddikar wrote:
>
>
> I have tried earlier versions of 8.4 installer on Vista x32 and they'd
> failed too. But let me try the latest installer again. I will let you know.

Any luck with the call? Or are we still at "it doesn't work on your
systems or some others but does on many, and we don't know why yet"?

I've managed to scrounge a win7 x64 license so I'll be having a play
with that when time permits. Unfortunately win7 doesn't run happily
under kvm so I can only really do it on my home desktop. I'd prefer
Vista but don't have x64 media.

--
Craig Ringer

On 07-04-2010 10:04, Craig Ringer wrote:
> Nikhil G. Daddikar wrote:
>
>>
>> I have tried earlier versions of 8.4 installer on Vista x32 and they'd
>> failed too. But let me try the latest installer again. I will let you know.
>>
> Any luck with the call? Or are we still at "it doesn't work on your
> systems or some others but does on many, and we don't know why yet"?
>

Yes, that's the current state. They found that the problem was with the
initcluster.vbs file and gave me a new file to run manually. I did and
it worked. They then gave me an updated installer with this new file.
However, it failed again in the same file. I ran that same file manually
again and it worked. Apparently there is a problem creating a
'FileSystemObject' from the installer.

We are going to have a webex session in a couple of hours where their
engineers will try out various things. I will post the results once I
have something concrete.

Thanks for your interest.

-ngd.

On Wed, Apr 7, 2010 at 5:41 AM, Nikhil G. Daddikar <ngd(at)celoxis(dot)com> wrote:
>
> We are going to have a webex session in a couple of hours where their
> engineers will try out various things. I will post the results once I have
> something concrete.

The problem appears to be that when using the (default) 64 bit script
interpreter (cscript.exe) on Nikhil's system, it cannot instantiate an
instance of Scripting.FileSystemObject, whilst if we call the 32 bit
interpreter, it works fine.

This is clearly something specific to Nikhil's machine configuration,
as the 64 bit interpreter works fine on all our test systems,
including 64 bit versions of XP, Vista, 7, 2003 and 2008. I will be
chatting with my colleagues later to try to figure out what the issue
may be, though a quick Google indicates there are a number of possible
causes for this issue. We'll also be looking for possible workarounds.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com