> 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.
Well, I did a lot of system management when I was working at the
University of Braunschweig. That is actually the reason why you see
many of the ONC RPC commands in the Tnm extension.
> 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?
Well, I did not touch the Tkined sources (other than porting it to new
Tcl/Tk versions) for quite some time now (just look at the changelog
file). There is a reason for this: I think that Tkined needs to be
re-written in large parts to 1) turn it into a real client-server
application and 2) to make better use of the new Tcl capabilities
(multiple and secure interpreters and dynamic loading). I also think
that the coding style I used for Tkined was not the best one (to say
it in nice words) and I would like to change to a more modular and
Tcl-like implementation.
I started to implement some new modules but I do not have much time
for it in the next couple of weeks. So don't expect a really new
version anytime soon.
> 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?
Support for getpwent et.al. is really a portability problem because
not all systems support these interfaces (this problem might have
become less important in the last months). I therefore think that a
more general interface to yp services would be the right way to go.
> 3) Any preferences or comments concerning encryption?
No.
> 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.
In many environments network management and system administration are
closely related, usually by having the same persons responsible for
both. Only big sites really separate these functions and I guess that
Tkined is more or less used in the smaller sites.
>From a functional point of view, there is some overlap in a network
management system and a system management system. However, there are
also areas where things are quite different. Tkined is just a GUI and
I am sure that it can be used at least for the overlapping area, but
there are things that might be easier to support with other
UIs. Scotty surely provides commands that can be used for both tasks.
Fortunately, Tcl7.5 allows to dynamically load extensions which makes
it really simple to extend scotty with exactly the things you need for
the task at hand. It is my intention to make use of this feature as
much as possible in the future to keep the scotty extension at a
reasonable size. I don't want to include all kind of new commands if
they can be provided easily as a loadable package. I even plan to
remove some previously supported Tcl extensions (e.g. msqltcl) since
they can be maintained now independent of scotty. (Watch for the
upcoming new version of msqltcl.)
Juergen
-- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)