Обсуждение: "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 donot complain because they have no problems. Actually that's true for all internet forums or mailing lists: you'll seldomlyfind 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 userdoes not have write permissions on that directory. As the installer is usually run with Administrator rights, the directorycan be created but the service (or initdb) runs under a normal user account that cannot write to that directorybecause. I do not like the installer's suggestion to put the data directory into c:\Program Files either, I think this should defaultto %APPDATA% instead of %ProgramFile%. I bet half of the problems would go away if the installer refused to put thedata 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 serviceaccount 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 activleyprevent c:\Program Files). I don't know if this is possible (or how hard it would be) but I think a very useful featurefor 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@hogranch.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@celoxis.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@postnewspapers.com.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.
"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.
On Thu, Apr 1, 2010 at 10:35 AM, Nikhil G. Daddikar <ngd@celoxis.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
2010/4/1 Craig Ringer <craig@postnewspapers.com.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:50 AM, Magnus Hagander <magnus@hagander.net> wrote: > 2010/4/1 Craig Ringer <craig@postnewspapers.com.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@postnewspapers.com.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 ;)
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.
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.geoghegan86@gmail.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.
On Thu, Apr 1, 2010 at 12:35 PM, Nikhil G. Daddikar <ngd@celoxis.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@ghum.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
Dave,
--
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
>It hasn't. I checked 2008 this morning.
> 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?
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:
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
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@postgresql.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:
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.
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@postgresql.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.
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:
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?JohnOn 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.
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@numericable.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?JohnOn 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.
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:
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: postgresOr, 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.JohnOn 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?JohnOn 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.
See attached attached OneClick_PG_Installer notes. Igor Neyman > -----Original Message----- > From: John Gage [mailto:jsmgage@numericable.fr] > Sent: Friday, April 02, 2010 3:44 AM > To: sachin.srivastava@enterprisedb.com > Cc: pgsql-general@postgresql.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: postgresOr, 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:
Thanks,
Nikhil
On 06-04-2010 09:31, Craig Ringer wrote:
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:
- Default install of PG 8.4
- Install of PG 8.4 in C:\Postgresql
- Disable MS Security Essentials for C:\Postgresql and reinstall
- Create a regular (non-admin) posgres user before installation
- Delete that user and redo installation
- Disable UAC and install in C:\Postgresql as well as in the default directory
- Enabled the "Administrator" user in Vista, logged in as that user and installed
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
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: > 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@celoxis.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