[Spread-users] Desired features

[Jonathan Stanton]

I'm curious what application you are using/thinking of that motivates
these needs? Are you using George's mod_log_spread or is it some other
application? I'm very interested in new ways people have thought to use
Spread that we havn't heard of before.

We have thought about dynamic reconfiguration and do plan to add it (as
usual the real question is when...) The main difficulty is that although
Spread was definitely designed to allow dynamic membership changes (that
is the whole point after all), that problem was simplified somewhat by
assuming that the 'potential' configuration was fixed and identical at all
machines. Thus the configuration file (spread.conf). This limitation had a
minimal impact on the applications using spread initially, but we agree it
is becoming much more of a problem as Spread is used in places where it is
up all the time and the machine configuration changes over time.

To make the reconfiguration work we need to add a method to atomically
initiate a membership change which also rereads the config file just
before beginning. So something like a HUP signal probably won't work as
each daemon will get SIGHUP'd at a different time. I had envisoned
something more like 'a command is sent by the monitor to a daemon and that
daemon initiates a reconfiguration event as an ordered message to all the
daemons' Then there is a well defined 'virtual timestamp' when the
reconfiguration occurs so no daemons get mixed up by thinking the
configuration is different then it really is.

The security mechanisms are currently a higher priority and a large part
of it (a key infrastructure and message encryption implementation) is
working as a research version. Adding access control in some easily used
form is the next priority. 

Our approach to access control is to put hooks at relevant locations in
the Spread daemon codepath which call into an access control module. That
module can implement any decision making it wants. The default module
would probably do something simple initially but it should be fairly easy
to add more complex decision making.

For example, when someone goes to join a group, the relevant info will
be passed to
a function hook "access_group_join(groupname, joiner_name, ...)" which
will return either true or false to allow or disallow the join.

The daemons currently do protect themselves some from other daemons who
are not in the configuration file trying to communication with them. They
generally ignore the messages from other daemons who are not in the
configuration file. 

I hope this clarifies my thoughts on these issues at least. I'd be
interested on any feedback about whether these ideas would address your
needs.

To reiterate what George said, our best currently solution is to overfill
the configuration file and do access control at the network level
(router/firewall).

Jonathan

 On Wed, Aug 23, 2000 at 11:33:52AM -0400, Raymond S Brand wrote: 
> I'm aware of the 'overfilling' technique but it doesn't work with
> the types of configuration changes I wish to make. For example, move
> an IP address from one segment to another where a segment is defined
> by a multicast address. I also need to be able to add, currently
> unknown, addresses in the future as well as delete some subset of
> the current addresses.
> 
> 
> 	Raymond S Brand
> 
> 
> George Schlossnagle wrote:
> > 
> > In regards to 1), if you 'overfill' your configuration file with all the
> > members you might possibly add, the you can add the later (at runtime)
> > w/o affecting current members.
> > 
> > Raymond S Brand wrote:
> > >
> > > A couple of things that I'd like to see (soon) in Spread:
> > >
> > >         1) Dynamic reconfiguration. The ability to add or
> > >                 delete segments and segment members without
> > >                 impacting connected clients.
> > >
> > >         2) Security mechanisms. Keep non authorized clients
> > >                 or Spread daemons from joining.
> > >
> > > I'd be happy if 1) could be done by modifying all the configuration
> > > files and HUPing the daemons. But only if all the clients in both
> > > the old and the new configurations do not appear to have left and
> > > rejoined the groups.
> > >
> > > Raymond S Brand
> > >

-- 
-------------------------------------------------------
Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    
-------------------------------------------------------