Thread: apple uses Postgres for RemoteDesktop 2
Hi, maybe anyone already knows that Apple is distributing Postgres 7.3.3 with RemoteDesktop 2. Its located in /System/Library/CoreServices/RemoteManagement/rmdb.bundle/ BUT... they did not do a good job: -their- installation is using the default port which means: either -their- version works or the one that the server owner maybe installed on the same server. In our case neither our Postgres nor the one from RemoteDesktop 2 did start up because of file conflicts. If anyone from the Postgres (or from whereever) team is in contact with apple about RemoteDesktop and Postgres it would be great it they could ask apple to change their port, its unbelievable that they did not care about this problem. regards David
David Teran <david.teran@cluster9.com> writes:
> maybe anyone already knows that Apple is distributing Postgres 7.3.3
> with RemoteDesktop 2. Its located in
> /System/Library/CoreServices/RemoteManagement/rmdb.bundle/
> BUT... they did not do a good job: -their- installation is using the
> default port which means: either -their- version works or the one that
> the server owner maybe installed on the same server. In our case
> neither our Postgres nor the one from RemoteDesktop 2 did start up
> because of file conflicts.
> If anyone from the Postgres (or from whereever) team is in contact with
> apple about RemoteDesktop and Postgres it would be great it they could
> ask apple to change their port, its unbelievable that they did not care
> about this problem.
Yikes. They need to get off of that badly broken PG version, too :-(
7.3.3 was about the worst choice they could have made in the past
several years ...
regards, tom lane
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: Tom> Yikes. They need to get off of that badly broken PG version, too :-( Tom> 7.3.3 was about the worst choice they could have made in the past Tom> several years ... At least they make a habit of that. If I recall correctly, OSX 10.1 and 10.2 froze in a bad beta of Perl 5.6.0 prerelease. Now it's been updated to at least a normal release (5.8.1, still a year behind, but that's life). -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
On Tue, 2004-08-17 at 05:22, David Teran wrote: > Hi, > > maybe anyone already knows that Apple is distributing Postgres 7.3.3 > with RemoteDesktop 2. Its located in > /System/Library/CoreServices/RemoteManagement/rmdb.bundle/ > > BUT... they did not do a good job: -their- installation is using the > default port which means: either -their- version works or the one that > the server owner maybe installed on the same server. In our case > neither our Postgres nor the one from RemoteDesktop 2 did start up > because of file conflicts. > > If anyone from the Postgres (or from whereever) team is in contact with > apple about RemoteDesktop and Postgres it would be great it they could > ask apple to change their port, its unbelievable that they did not care > about this problem. Why can't the user and the OS use the same server? I mean what's the reason not to, not the problems one might encounter that could be overcome? It would seem that by having one single server on a machine memory would be more effectively utilized and performance for both should be ok.
I usually get in trouble when I open my mouth, but ... On Tue, 17 Aug 2004 22:02:15 -0600 "Scott Marlowe" <smarlowe@qwest.net> wrote > On Tue, 2004-08-17 at 05:22, David Teran wrote: > > Hi, > > > > maybe anyone already knows that Apple is distributing Postgres 7.3.3 > > with RemoteDesktop 2. Its located in > > /System/Library/CoreServices/RemoteManagement/rmdb.bundle/ > > > > BUT... they did not do a good job: -their- installation is using the > > default port which means: either -their- version works or the one that > > the server owner maybe installed on the same server. In our case > > neither our Postgres nor the one from RemoteDesktop 2 did start up > > because of file conflicts. > > > > If anyone from the Postgres (or from whereever) team is in contact with > > apple about RemoteDesktop and Postgres it would be great it they could > > ask apple to change their port, its unbelievable that they did not care > > about this problem. > > Why can't the user and the OS use the same server? I mean what's the > reason not to, not the problems one might encounter that could be > overcome? It would seem that by having one single server on a machine > memory would be more effectively utilized and performance for both > should be ok. Apple does some "weird" stuff with things. Much of the configuration information will be found in proprietary xml files instead of the usual .conf style files we've all come to know and love, and they have their own view of where the various directories should go. It all makes sense, but it takes some figuring out to get an update in properly. One more bit of information, Remote Desktop is an app. I suppose that the best advice to give the OP on this is to point out how he can set up his own install of postgresql to use another port. (I should look that up, but it's not handy right now.) -- Joel <rees@ddcom.co.jp>
Joel <rees@ddcom.co.jp> writes:
> "Scott Marlowe" <smarlowe@qwest.net> wrote
>> Why can't the user and the OS use the same server?
> Apple does some "weird" stuff with things.
We learned this lesson from Cobalt, actually. Even if the OS installs
an absolutely vanilla version of Postgres, it's a bad idea. The first
problem is that the user may want to use a different PG version than the
OS does. ("Maybe not today, and maybe not tomorrow, but soon ... and
for the rest of your life ...") The second problem is that the user is
going to want superuser privs over his database, including the ability
to rm -rf it, initdb it, and possibly crash it if he's doing
development; this is not something you want happening to part of the
core GUI. (Cobalt had this problem in spades because their PG database
*was* part of the core GUI. Screw around with it, and you'd be lucky if
you could log in again. I trust that Remote Desktop isn't that core to
OS X, but I'd still not care to admin that database while logged in
through Remote Desktop.) Even if you think that Joe Average User won't
want to do this stuff, a Postgres developer who owns an Apple machine
(moi for instance) certainly will. Is it in Apple's interest to make
life hard for the developers of a technology they are depending on?
> I suppose that the best advice to give the OP on this is to point out
> how he can set up his own install of postgresql to use another port.
This is backwards. The OS should stay out of the user's way, not vice
versa. If the OS wants its own private PG server, I am surely all for
that ... but it should not commandeer the port the user would expect to
use for *his* PG server.
regards, tom lane
On Wed, 18 Aug 2004 03:22:17 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote
> Joel <rees@ddcom.co.jp> writes:
> > "Scott Marlowe" <smarlowe@qwest.net> wrote
> >> Why can't the user and the OS use the same server?
>
> > Apple does some "weird" stuff with things.
>
> We learned this lesson from Cobalt, actually. Even if the OS installs
> an absolutely vanilla version of Postgres, it's a bad idea.
Maybe vanilla is the problem?
> The first
> problem is that the user may want to use a different PG version than the
> OS does. ("Maybe not today, and maybe not tomorrow, but soon ... and
> for the rest of your life ...") The second problem is that the user is
> going to want superuser privs over his database, including the ability
> to rm -rf it, initdb it, and possibly crash it if he's doing
> development; this is not something you want happening to part of the
> core GUI. (Cobalt had this problem in spades because their PG database
> *was* part of the core GUI. Screw around with it, and you'd be lucky if
> you could log in again. I trust that Remote Desktop isn't that core to
> OS X, but I'd still not care to admin that database while logged in
> through Remote Desktop.)
I think it's a separate app that costs money. I suppose I should check
their web site to see if they bundle it with Mac OS X Server.
> Even if you think that Joe Average User won't
> want to do this stuff, a Postgres developer who owns an Apple machine
> (moi for instance) certainly will. Is it in Apple's interest to make
> life hard for the developers of a technology they are depending on?
>
> > I suppose that the best advice to give the OP on this is to point out
> > how he can set up his own install of postgresql to use another port.
I guess I should say, "... the best advice for now ...".
(I submitted the second post in this thread to Apple's bug reporting
system, by the way. I don't know if they'll be happy with that.)
> This is backwards. The OS should stay out of the user's way, not vice
> versa.
Agreed.
> If the OS wants its own private PG server, I am surely all for
> that ... but it should not commandeer the port the user would expect to
> use for *his* PG server.
I'm thinking there would be security issues, as well.
If PostGreSQL could be set up to run two servers at once on separate
ports from one binary image, it might be reasonable to use the same
binary, but then there's also the issue of patches, updates, and
upgrades.
If Apple hired me to fix that for them, I'd probably put a system-use
only copy in there that would not be visible in the normal user's path,
and tweak it to use some other port. But I can see why they would be a
bit wary of multiplying installs of what seems to be essentially the
same program.
--
Joel <rees@ddcom.co.jp>
Joel <rees@ddcom.co.jp> writes:
> ... If Apple hired me to fix that for them, I'd probably put a system-use
> only copy in there that would not be visible in the normal user's path,
Right, that's what they did (according to my understanding of the first
post in this thread).
> and tweak it to use some other port.
... but they forgot that part.
Another issue that I've pointed out to them off-list is that the default
SysV shared-memory limits need to be raised considerably. With OS X's
default SHMMAX it's practically impossible to start two concurrent
postmasters at all, and it's definitely impossible to do so with
reasonable shared_buffers values.
regards, tom lane