problems with rdist

[Tom Christiansen]

I've looked at several alternatives to rdist (coda, track) and
I still like rdist best overall.  (Having to convert lots of Distfile,
some of ~1000 lines, has a little to do with it. :-)

Here's a list of bugs and wishes I've come up with for rdist.  I'm posting
it here and taking it off to LISA for brainstorming.  Additions or 
solutions welcome.  I'll check back in a week when I get back from LISA.

--tom

*    You have to have the master in everyone's /.rhosts files.  The
     master must initiate the connection, not vice versa.  I want
     a subscription service version of rdist VERY BADLY.  This is
     my number one wish.

*    It doesn't do the follow symlinks -- it clears them.  Sometimes 
     I like this, sometimes I don't.  The problem is that when space
     fills, the real executable is often replaced with a symlink
     on the host with problem, which rdist happily destoys.

*    There's no include file syntax, which makes it difficult for
     common definitions to be shared amongst various distfiles.

*    You can only do add to, never subtract from, lists.  I want
     to define host lists that have removals on them.  Like
	 PRODUCTION = ( ${ENGR} - ${LAB} )
     Or 
	${FILES} -> ( ${HOSTS} - {PRECIOUS} )
     If subtraction is used, it would be best if what got removed 
     were rememberd be remembered so that if you later say
	 TECH = ( ${PRODUCTION} ${SUPPORT} )
     That and ${LAB} machines wouldn't be added back in even if they
     were in ${SUPPORT}, since they'd been included in ${PRODUCTION}.
     I realize this is complex, but it's also very useful.

*    If the remote machine hangs (which seems to happen a lot),
     or the special command never returns, rdist can't recover from this. 

*    If a host is down and 30 targets go the that host, then 
     it'll try 30 times, wasting a lot of time and generating
     a lot of error messages.

*    It sends a zillion notifies to a user rather than bundling
     them all together.  That's because no state is kept between
     execution of targets; the same could also be said of the previous
     problem.

*    It forgets to set the access time.

*    If you are in the middle of executing a special clause on a remote
     host and hit ^C, the rdist returns but the command keeps running.  The
     signal should propagate as in rsh.

*    If you are rdisting some hard-linked pair of files /foo/bar/x and
     /foo/bar/y to a host on which /foo/bar is a symlink to a legitimate
     directory, then the install will fail saying:  "rdist: host:/foo/bar/y: 
     No such file or directory (no parent)".

*    If you execute rdist and specify a rule to perform that 
     does not exist in the rdistfile, then rdist does not print
     anything nor exit non-zero.  You cannot tell if there was nothing
     to rdist or if I made a mistake. Rdist should print a diagnostic
     that says "rdist: don't know how to rdist <target>".

*    When installing new directories, rdist does not (always) preserve the
     original's mode.  I haven't tracked this one down conclusively yet.

*    The install clause doesn't take -q like the command line.  It
     would be nice if it did.

*    When using the -v option of rdist to verify a distfile and your
     install rule specifies a different directory to place the files in,
     the "need to update" message indicates the wrong directory.

*    This distfile doesn't work:

	( /v8/foo ) -> ( hosts )
	    install /usr/local/bin;

     This does:

	( /v8/foo /v8/foo ) -> ( hosts )
	    install /usr/local/bin;

     It seems to care unduly much about having more than one element
     in its file list.

*    You can't make rdist work across several machines in parallel.
     It needs some kind of "go parallel" option that made rdist
     fork itself some number of times and have all files going
     to some host be handled by each child.  This would probably
     end up being faster as well, since due to lack of state, 
     it isn't keeping connections around to a host while it's
     off playing with a different one for a while.

*    It's hard to have a master with a set a several trees that go 
     to common subdirs depending on the machine.  For example,
     /usr/local/bin.v8 and /usr/local/bin.v9 should go to
     /usr/local/bin depending on which o/s I'm talking.  I've put
     something together, but it's pretty lame.  Perhaps there's a
     better way, but I don't know it.