Re: Virtual domains ?

On Mon, 9 Apr 2001, will trillich wrote:

> On Tue, Apr 03, 2001 at 05:41:54PM +0300, Kris Van Hulle wrote:
> > On 3 Apr 2001, at 10:31, Tom Lane wrote:
> >
> > > "Kris Van Hulle" <uxs@compulink.gr> writes:
> > > > Does PostgreSQL have support for virtual domains ?
> > >
> > > In 7.1 you can configure the postmaster to bind only to one specific IP
> > > address, if that helps.
> > >
> > Not really. I want to set up one SQL server, which should have a
> > different tablespace, userspace, whatever, depending on which
> > domain the user logs into. Every domain points to the same IP-
> > address, and the server is on that address.
> >
> > So, for example, one user connects to the server at
> > company1.com, and another to the one at company2.com, and
> > they see a different content, allthough the servers are actually the
> > same; it's only faking that they're different. (both company1.com
> > and company2.com point to to same IP)
> >
> > This is possible for http and ftp-servers, and email (allthough that
> > seems a bit more difficult), so I was wondering if it was possible for
> > SQL servers.
>
> from what i know of this, the reason HTTP works with virtual
> domains is because the recent web browsers know to send a HOST:
> mime header with their requests to the http servers. older web
> browsers don't include any such HOST: field, and so wind up
> getting the default domain for whatever IP they're requesting
> from. (serensoft.com -- to use my example -- serves
> dontUthink.com and others; without the HOST: field, my server
> will never know to delve into the dontUthink.com document tree,
> and would return serensoft.com stuff by default.)
>
> so postgres would then <if guess is correct> need to accomodate
> the mime fields in a similar fashion, and clients would need to
> generate them, likewise.

If you have a shortage of machines, but not of IP addresses, you can bind
multiple IP addresses to the same physical network device. A ipchains (or
whatever your OS calls it) script could then redirect requests for
192.168.0.1 to port X, and requests for 192.168.0.2 to port Y, which
different postmasters could hear.

(Even though many people virtual masquerade w/the same IP, if you have an
IP to spare, you should do this for web serving too, as it gives you a way
to make the (dwindling number of) HTTP/1.0 clients happy.

--
Joel Burton   <jburton@scw.org>
Director of Information Systems, Support Center of Washington