[Infrastructures] Radmind vs. Isconf ?

[Steve Traugott]

On Tue, Apr 05, 2005 at 04:25:40PM -0400, Andrew Piskorski wrote:
> I think I have a decent picture of the design differences between
> Isconf and Cfengine.  But how is Radmind similar/different from either
> of those two tools, or from others?  What would you say are its
> advantages/disadvantages vs. other tools?
> 
>   http://rsug.itd.umich.edu/software/radmind/
> 
> (I've looked at the Radmind docs, but it's not entirely obvious to me
> how that translates to overall system-level comparisons with other
> tools.  It seems kind of like Isconf.  Also, I've never used any of
> these tools, so I'm most interested in feedback from you folks who
> have...)

(Andrew, I'm glad you asked; I was thinking a few days ago that you
might want to take a look at Radmind as well...)

David and/or Patrick will want to jump in here, but here's what little I
understand about it; I don't know how much of this is still true, more
true, or less true than it was 2 years ago...  A lot of what I'm saying
is probably wrong, either because I misunderstood or because it's
changed:

A bunch of us sat down at LISA 2003 and went over Radmind; Patrick had
presented it in the infrastructures workshop.  (Make sure to see the
Radmind paper from that year as well.)  The impression I came away with
was that Radmind gives you a way to maintain the baseline image, plus
any deltas, as rsync-like sets of changed files (not what they call it
-- I'm digging this out of my sieve-like memory).  

The main conceptual difference between Radmind and ISconf is that, while
ISconf expects to distribute native rpm, deb, tarballs, and other
packages from upstream, Radmind specializes in making it easy to
redistribute the results of applying a package, rather than the package
itself.  An overly simplistic way of looking at Radmind is that it's a
more granular version of systemimager, implements its own protocol
rather than using rsync (right guys?) with more tools for capturing and
managing deltas and exceptions.  (This is a horrible analogy, I'm gonna
get pummelled again). ;-)  Systemimager's optimized for image install,
Radmind is optimized for ongoing maintenance.  (What do most Radmind
users use for network install?)

A better analogy might be a R/W version of tripwire -- I think that idea
was some of the inspiration for radmind.

I remember we talked about how files get selected for change sets,
because I was concerned about (a) finding everything and (b) doing it
quickly, but they seemed to have that covered; I don't remember how.
One reason I'm still bothering to work on ISconf4 is that I want to get
rid of this extra discovery step, and I *like* being able to "fire and
forget" native packages and arbitrary commands.

Radmind also has a concept of excludes ("negative space"?) which have to
be managed, and probably a post-replication trigger facility for
per-host customizations like IP and hostname.  ISconf avoids having to
think about the excludes, but per-host cusomizations will be about the
same (or does a Radmind user usually just use a per-host file set for
per-host customizations?)

When talking to them I was being especially picky (i.e. a real a**)
about the ordering thing, because it sounded like a pretty good tool
otherwise, and they were saying things that made it sound to me like
they had managed to sidestep the whole issue.  I came away convinced
that radmind avoids most classes of ordering issues with the *possible*
exception of replacing the radmind client agent itself, or any prereqs,
though they might have avoided that too.  Here's why I think Radmind
works so well:

- It's overwriting files directly, like rsync, rather than relying on
  client-side installation of vendor packages or tarballs.  In turing
  terms, they're just overwriting sections of the tape rather than
  relying on the machine's own ruleset to do it.  This will always work
  as long as none of those deltas affects the operation of the client
  radmind agent itself (and I think I'm missing something here, because
  I don't remember them being worried about that).
- The way they list named file sets in an ordered high-level manifest
  file (again not what they call it) means that, even if more than one
  file set contains the same file, the same one (the last one?) always
  wins.  This will work as long as you only append to the manifest file,
  and never edit or remove an existing entry (it might work in other
  cases; need to think about it).  The manifest file plus the content of
  the individual file sets adds up to one big transaction log.  I don't
  remember (or never knew) if they're checkpointing that log at any
  point, or if the entire disk gets scanned/updated every run, or
  something else.
 
David/Patrick, what did I miss, and what did I say that's just plain
wrong?  ;-)

Steve
-- 
Stephen G. Traugott  (KG6HDQ)
UNIX/Linux Infrastructure Architect, TerraLuna LLC
stevegt@TerraLuna.Org 
http://www.stevegt.com -- http://Infrastructures.Org