Hi Andrew, Thanks for your reply.
> -----Original Message----- > From: Andrew Sullivan [mailto:[EMAIL PROTECTED] > Sent: 23 January 2006 15:46 > To: Roger Lucas > Cc: 'Andrew Sullivan'; [email protected] > 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 _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
