Adding Rendezvous support to postmaster

Chris Campbell <chris@bignerdranch.com> writes:

The attached diffs add Rendezvous support to postmaster when it's
running on Darwin (Mac OS X).

I'd object to adding a Microsoft-specific patch of this ilk, and so
I'm having a moral problem with approving of an Apple-specific one...
can you offer us a platform-independent solution?

In any case, a patch that adds a configuration variable and provides
no corresponding documentation is flat-out incomplete.

regards, tom lane

On Thursday, Mar 27, 2003, at 02:04 US/Eastern, Tom Lane wrote:

I'd object to adding a Microsoft-specific patch of this ilk, and so
I'm having a moral problem with approving of an Apple-specific one...
can you offer us a platform-independent solution?

Apple's Rendezvous implementation is open-source. Specifically, the
mDNSResponder program and associated API that makes ZEROCONF do its
thing. So this patch isn't platform-dependent but API-dependent, and
anyone could build mDNSResponder on their system to make this API
available.

Detecting the presence of this API simply requires some configure
script wizardry to look for the header files; however, a configure
script wizard I am not (which I why I just threw the #define in
darwin.h). Or maybe a configure --with-zeroconf flag?

At any rate, the list now has the code, so anyone interested in doing
the configure script modifications can run with it. Every Darwin
developer that uses postgresql that I've bounced this off of has
instantly replied, "Cool! Can I have the diffs?" so it's my impression
that this is a feature that users would love. And it's built on
open-source software, so perhaps that solves your moral problem? :)

Maybe the main source tree isn't the right place. Is there somewhere
else in the distribution for providing additional features that have to
be manually built and installed by the user?

Thanks!

- Chris

Chris Campbell <chris@bignerdranch.com> writes:

The attached diffs add Rendezvous support to postmaster when it's
running on Darwin (Mac OS X).

I'd object to adding a Microsoft-specific patch of this ilk, and so
I'm having a moral problem with approving of an Apple-specific one...
can you offer us a platform-independent solution?

I think you might be over-reacting here, Tom. It's a very small patch, is
incredibly useful for OS/X people and is a nice feature to have. Once we
have a Win32 port, I wouldn't be surprised if we had little bit of code for
running as a Windows service, etc.

Chris

On Thu, 2003-03-27 at 09:34, Chris Campbell wrote:

Detecting the presence of this API simply requires some configure
script wizardry to look for the header files; however, a configure
script wizard I am not (which I why I just threw the #define in
darwin.h). Or maybe a configure --with-zeroconf flag?

I agree -- IMHO, an implementation that used 'configure' would be
preferable to just assuming that (a) it's automatically available on
Darwin (b) it's *only* available on Darwin.

Cheers,

Neil

[Catching up on email after getting back in town]

Chris Campbell <chris@bignerdranch.com> writes:

On Thursday, Mar 27, 2003, at 02:04 US/Eastern, Tom Lane wrote:

I'd object to adding a Microsoft-specific patch of this ilk, and so
I'm having a moral problem with approving of an Apple-specific one...
can you offer us a platform-independent solution?

Apple's Rendezvous implementation is open-source. Specifically, the
mDNSResponder program and associated API that makes ZEROCONF do its
thing. So this patch isn't platform-dependent but API-dependent, and
anyone could build mDNSResponder on their system to make this API
available.

Well, fair enough. I concur with the other comment that the
appropriate configure test should be added, though.

regards, tom lane

I will apply this patch soon, and add a configure test looking for:

#include <DNSServiceDiscovery/DNSServiceDiscovery.h>

You reference that in your code, so it seems a logical way to set
HAVE_RENDEZVOUS.

---------------------------------------------------------------------------

Chris Campbell wrote:

The attached diffs add Rendezvous support to postmaster when it's
running on Darwin (Mac OS X).

Rendezvous allows services (such as a database server) to advertise
their availability to other hosts on their link-local network, and
client programs to browse the services on the network to see what's
available. It is Apple's implementation of ZEROCONF.

http://developer.apple.com/macosx/rendezvous/

This allows client programs running on computers that are on the same
link-local network as the postgresql server to automatically find the
server's IP address and port number. This adds great ease-of-use for
end users.

I propose adding a configuration variable to postgresql.conf called
"service_name" that allows the user to specify the name used to
advertise the database service. If this variable isn't defined in the
postgresql.conf file, then no service is advertised. If it is '', then
the computer's "Rendezvous Name" is used (this is similar to the
hostname, see the link below for more info). Otherwise, if it's a
non-empty string, that string is used as the name of the service.

http://developer.apple.com/qa/qa2001/qa1228.html

If there's already a service on the network with that name, then the
service registration silently fails and no service is registered.

Rendezvous also has the notion of a service type string. It's a bit
like a domain name: I suggest we use "_pgsql._tcp." (another example
would be "_ftp._tcp.").

There's very little code involved: just 1 function call in
PostmasterMain() after postmaster has started listening on a TCP
socket. And 1 addition to the GUC list of configuration variables.

All the code is #ifdef'ed inside HAVE_RENDEZVOUS, which is only defined
in src/include/port/darwin.h. Even once we know the OS is darwin, we
still need to check to make sure that Rendezvous is available, either
by OS version, or by checking for the existence of a needed header
file, etc.

I've included patches for CVS top-of-tree and postgresql-7.3.2.

Thanks!

- Chris

[ Attachment, skipping... ]

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I will apply this patch soon,

Chris Campbell wrote:

This allows client programs running on computers that are on the same
link-local network as the postgresql server to automatically find the
server's IP address and port number. This adds great ease-of-use for
end users.

Are there any security issues that we should be worrying about here?

Rendezvous also has the notion of a service type string. It's a bit
like a domain name: I suggest we use "_pgsql._tcp." (another example
would be "_ftp._tcp.").

Is there some central authority that we need to register this name
with?

regards, tom lane

Bruce Momjian writes:

I will apply this patch soon, and add a configure test looking for:

#include <DNSServiceDiscovery/DNSServiceDiscovery.h>

You reference that in your code, so it seems a logical way to set
HAVE_RENDEZVOUS.

I think there should be a configure switch to turn it on or off. Compare
handling of readline. Automatic discovery of optional features is evil.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut wrote:

Bruce Momjian writes:

I will apply this patch soon, and add a configure test looking for:

#include <DNSServiceDiscovery/DNSServiceDiscovery.h>

You reference that in your code, so it seems a logical way to set
HAVE_RENDEZVOUS.

I think there should be a configure switch to turn it on or off. Compare
handling of readline. Automatic discovery of optional features is evil.

Isn't "automatic discovery of optional features" what configure is all
about? We have a readline flag only because we want to force people to
know when they don't have it. I see this as similar to our move to make
syslog the default in all binaries that support it. I thought we were
avoiding additional configure flags.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian writes:

Isn't "automatic discovery of optional features" what configure is all
about?

Absolutely not. Configure chooses between alternative implementations of
a constant feature set.

--
Peter Eisentraut peter_e@gmx.net

On Tuesday, May 27, 2003, at 15:42 US/Eastern, Peter Eisentraut wrote:

Bruce Momjian writes:

Isn't "automatic discovery of optional features" what configure is all
about?

Absolutely not. Configure chooses between alternative implementations
of
a constant feature set.

If configure can properly set HAVE_RENDEZVOUS, but the feature isn't
enabled unless a GUC variable is set (and the variable is disabled in
the default configuration), is that OK? HAVE_RENDEZVOUS just enables
the GUC variable processing, and 1 line in postmaster's main() that is
executed if the variable is set.

I think it would be really nice to enable Rendezvous service
advertisement if the system supports it (e.g., "#ifdef HAVE_RENDEZVOUS"
is the way to determine whether or not to advertise the service), but
since people don't like that, we could go back to my original proposal
was for a GUC variable that was disabled by default.

E.g., if your OS supports Rendezvous, but "rendezvous_service_name"
isn't configured in your postgresql.conf, no Rendezvous-related
anything will happen. The optional feature is discovered, but not
enabled. And there is no run-time cost associated with the feature
being compiled in but disabled.

- Chris

Chris Campbell writes:

If configure can properly set HAVE_RENDEZVOUS, but the feature isn't
enabled unless a GUC variable is set (and the variable is disabled in
the default configuration), is that OK?

That isn't the point. But we need configure to produce constant results
for constant inputs, because we cannot expect users to read the configure
or make output to detect whether some optional package was actually
detected.

Then again, there are probably some security implications to this feature,
so an option to turn it off might be useful anyway.

In any case, this patch still needs documentation. At least, provide an
explanation of the configuration parameters you add, plus a paragraph or
three of whatever this feature gives to users.

--
Peter Eisentraut peter_e@gmx.net

Chris Campbell writes:

Rendezvous also has the notion of a service type string. It's a bit
like a domain name: I suggest we use "_pgsql._tcp." (another example
would be "_ftp._tcp.").

Maybe it would be better to use "_postgresql._tcp" for consistency with
the IANA service registration (which is "postgresql").

--
Peter Eisentraut peter_e@gmx.net

At 2:30 AM -0400 5/26/03, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I will apply this patch soon,

Chris Campbell wrote:

This allows client programs running on computers that are on the same
link-local network as the postgresql server to automatically find the
server's IP address and port number. This adds great ease-of-use for
end users.

Are there any security issues that we should be worrying about here?

Rendezvous is only a service discovery protocol. There are no
security issues beyond those inherent in making the postmaster
service available at all. Think nmap, simplified.

There could be security implications for clients that connect via the
Rendezvous name and use no other authentication to verify that they
are talking to the server they expect. These risks are similar to the
risks posed by DNS spoofing for example.

Rendezvous also has the notion of a service type string. It's a bit
like a domain name: I suggest we use "_pgsql._tcp." (another example
would be "_ftp._tcp.").

Is there some central authority that we need to register this name
with?

No, but using the IANA service registration "postgresql" would
probably be the best choice.

PS: It'd be nice to have a corresponding patch for psql that offered
a menu of available postmasters.

-pmb

Peter Eisentraut wrote:

Bruce Momjian writes:

I will apply this patch soon, and add a configure test looking for:

#include <DNSServiceDiscovery/DNSServiceDiscovery.h>

You reference that in your code, so it seems a logical way to set
HAVE_RENDEZVOUS.

I think there should be a configure switch to turn it on or off. Compare
handling of readline. Automatic discovery of optional features is evil.

OK, I will modify the rendezvous patch to be a configure switch, and
remove the GUC variable. If people want to specify the rendezvous, we
can add it later.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

I have applied the attached Rendezvous patch.

Per suggestion from Peter, a --with-rendezvous flag was added to
configure. This is similar to the PAM flag we already have.

I also _didn't_ add the Rendezvous GUC variable, so we default to the
host name. If there is need, we can add it later.

---------------------------------------------------------------------------

Chris Campbell wrote:

The attached diffs add Rendezvous support to postmaster when it's
running on Darwin (Mac OS X).

Rendezvous allows services (such as a database server) to advertise
their availability to other hosts on their link-local network, and
client programs to browse the services on the network to see what's
available. It is Apple's implementation of ZEROCONF.

http://developer.apple.com/macosx/rendezvous/

This allows client programs running on computers that are on the same
link-local network as the postgresql server to automatically find the
server's IP address and port number. This adds great ease-of-use for
end users.

I propose adding a configuration variable to postgresql.conf called
"service_name" that allows the user to specify the name used to
advertise the database service. If this variable isn't defined in the
postgresql.conf file, then no service is advertised. If it is '', then
the computer's "Rendezvous Name" is used (this is similar to the
hostname, see the link below for more info). Otherwise, if it's a
non-empty string, that string is used as the name of the service.

http://developer.apple.com/qa/qa2001/qa1228.html

If there's already a service on the network with that name, then the
service registration silently fails and no service is registered.

Rendezvous also has the notion of a service type string. It's a bit
like a domain name: I suggest we use "_pgsql._tcp." (another example
would be "_ftp._tcp.").

There's very little code involved: just 1 function call in
PostmasterMain() after postmaster has started listening on a TCP
socket. And 1 addition to the GUC list of configuration variables.

All the code is #ifdef'ed inside HAVE_RENDEZVOUS, which is only defined
in src/include/port/darwin.h. Even once we know the OS is darwin, we
still need to check to make sure that Rendezvous is available, either
by OS version, or by checking for the existence of a needed header
file, etc.

I've included patches for CVS top-of-tree and postgresql-7.3.2.

Thanks!

- Chris

[ Attachment, skipping... ]

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Peter Eisentraut wrote:

Bruce Momjian writes:

I will apply this patch soon, and add a configure test looking for:

#include <DNSServiceDiscovery/DNSServiceDiscovery.h>

You reference that in your code, so it seems a logical way to set
HAVE_RENDEZVOUS.

I think there should be a configure switch to turn it on or off. Compare
handling of readline. Automatic discovery of optional features is evil.

Peter, I assume you meant to add a specific flag to _enable_ Rendezvous,
which is how I handled it, rather than have it like readline where we
have a flag to disable readline.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I also _didn't_ add the Rendezvous GUC variable, so we default to the
host name. If there is need, we can add it later.

How do you figure there is not need for it? What about running more
than one postmaster at a time?

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I also _didn't_ add the Rendezvous GUC variable, so we default to the
host name. If there is need, we can add it later.

How do you figure there is not need for it? What about running more
than one postmaster at a time?

No one brought up that idea, and Chris agreed we could try it without
it. Chris, is that an issue? I see the port number in the Rendezvous
function call:

if (service_name != NULL)
{
DNSServiceRegistrationCreate(NULL, /* default to hostname */
"_postgresql._tcp.",
"",
htonl(PostPortNumber),
"",
(DNSServiceRegistrationReply)reg_reply,
NULL);

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073