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.
>
> 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.
> privileges on a different node. To allow the tables to be locked down in
> this way, I would need to know which tables slony needs write access to and
> under what conditions.
The problem is that administration commands need to be able to write
on the system catalogue. So you _have_ to use a superuser.
But I still don't see why log shipping won't work for you. All you
really need to make it work is very small changesets.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
