I got interested in Scotty/Tkined because I'm trying to make system
maintenance a little more sane around here, and it turns out that they
address many of the same issues that are necessary for performing
distributed operating system maintenance. I'm therefore a bit surprised
to encounter so little crossover on this mailing list between the network
management and system management cultures. Anyway, I hope that in raising
system issues here I will not be offending anyone with my lack of purity.
I would like to work on this project in a way that ends up being of benefit
to everyone. So I have a couple of questions for the developers on this
list. First though, it would probably help to provide a bit of background.
Basically what I'm developing is a framework for managing Unix hosts
or more generally, machines with similar capabilities. This consists
of:
1) A simple, extensible, interpreter on each target host which knows how to
perform various generic tests and operations (for example, check if any
users are logged in, attempt to remount filesystems, and so on).
I'd already settled on Tcl for this, because it fits well with the
existing command languages used by most systems. It's so great that
the socket stuff was finally moved into Tcl!
2) A user interface running at some management station, which knows how
to (a) form sets of hosts based on various criteria, (b) transmit
generic commands to such hosts and collect responses, and (c) manage
errors, timeouts, and other variability in how the hosts respond.
Scotty is a wonderful fit for the purpose, and I was delighted to
find that Tkined has most of the necessary user interface already
in place in a very clean form.
3) A secure protocol connecting the management station and managed hosts,
since the commands being sent out are extremely powerful and the data
itself often needs to be secure.
With that preamble I can now ask you folks about the following questions:
1) So far I've convinced myself that in order to represent the various
tools and other entities that are necessary for this kind of management,
the Tkined user interface has to be extended to allow Interpreters as
graphical objects. It was either that or introduce an entirely new ined
type that would be a graphical object capable of performing arbitrary
computations, and it seemed to me that the Interpreter type already had
everything but a graphical appearance.
The code changes are simple, computationally insignificant, but fairly
widespread, so for such an idea to be manageable in the long term, it
should really be folded into the Tkined distribution.
What do people think about this? Would it be a welcome enhancement to
Tkined generally, or is it not terribly interesting?
2) The netdb stuff in Scotty is useful but not a complete interface to
the NIS database. For system administration, it can be necessary for
some sites to use various standard maps such as netgroup (getnetgrent),
group (getgrent), passwd (getpwent), shadow (getspent) for which a
programmatic interface exists. Some sites may maintain additional NIS
maps for which the only access may be commands such as ypcat and ypmatch.
Would it be stylistically appropriate to extend the netdb code to include
these maps? Would it be better, or additionally useful, to supply
an interface to the yp commands?
3) Any preferences or comments concerning encryption?
4) Finally, as general guidance, how much do network administrators care
about system maintenance? If Tkined was capable of both, would you
rather try to keep them functionally separate or unified? Right now,
I have no idea what this would concretely mean, but I'm sure it will
have an influence on how I approach the design.
Please feel free to communicate directly with me, and I'll be happy to
post a summary to the list.
.^.^. Dan Razzell <razzell@cs.ubc.ca>
. o o . Laboratory for Computational Intelligence
. >v< . University of British Columbia
_____mm.mm_____ http://www.cs.ubc.ca/nest/lci