problems with rdist
Tom Christiansen
tchrist at convex.com
Tue Oct 16 05:27:51 AEST 1990
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.
More information about the Comp.unix.admin
mailing list