Hi Andrew,

Thanks for your reply.

> -----Original Message-----
> From: Andrew Sullivan [mailto:ajs at crankycanuck.ca]
> Sent: 23 January 2006 15:46
> To: Roger Lucas
> Cc: 'Andrew Sullivan'; slony1-general at gborg.postgresql.org
> Subject: Re: [Slony1-general] Security with slony
> 
> On Mon, Jan 23, 2006 at 12:30:53PM -0000, Roger Lucas wrote:
> > The network topology is very stable.  Once we have set up the node
> > master-slave topologies we want to:
> >  - Absolutely lock this configuration in concrete
> >  - Absolutely ensure that slony can never write to the master "primary"
> > namespace
> 
> I think that requirement 2 is unreasonable.  That's like saying you
> want to make sure that the VACUUM user can never write in the primary
> namespace.
> 
> If I were designing such a system, I'd do it with two steps: node A
> replicates to node B, and node B chains down to everything else.
> There should be no listen paths from A to {C. . . Z}.
> 
> But it sounds like what you need is a functional host-based ACL
> system grafted on top.  That is, events of type T can come only from
> nodes {some set of nodes}, and other events of type T' can come from,
> &c.
> 

That would be ideal... but I cannot find it in existance already.

> >
> > Looking at the slony documentation, it suggests that slonik would not be
> run
> > very often in the above scenario, so we could use ssltunnels to link the
> > sites for the configuration commands and then remove these tunnels to
> > prevent the node configuration from changing.  Firewalling of all
> incoming
> 
> No, you seem to misunderstand.  Slonik injects events, just like any
> other kinds of event, into the replica stream.

That confuses me, as I had read the information below to imply that the
network configuration commands (i.e. control messages from the
"administrative workstation" that set up the topology of the replication
network) were sent "out of band" using different links which could then be
shut down when not required.

http://linuxfinances.info/info/plainpaths.html
("ADMIN CONNINFO" section at the top)

I don't want to generate too much noise on this mailing list as it is
relatively low volume, however, so I'll dig through the code to try to
understand its workings in more detail rather than ask more questions.

Best regards,

Roger