Further Work

Further Work

History editor for command window

The present command window is a simple text editor with the ability to recognize a complete expression and dispatch it automatically. In addition to this simple behavior, it would be nice to have an enclosing history mechanism by which previous expressions could be retrieved and edited. This might include the ability to load and save the command history for use outside the current session.

Support for saving, organizing, and filtering history logs

The Starfish manager logs the expressions and results for each node in the current session. It may be useful to save these logs for later analysis. When there are many nodes, it would help to have some simple pattern matching tools in order to minimize the need to inspect each log individually.

Framework for host attribute databases

A general framework is needed in the Starfish manager to support modules which interoperate with site databases describing the systems to be managed. Different sites can be expected to have quite distinctive ways of organizing this information. Starfish can't anticipate what these might be, but it can at least provide a suitable customization interface. The existing "netdb" functionality should be moved into this framework.

Manager customization modules for compound expressions

The command window is used to hold expressions for remote execution by Starfish agents. In the simplest case, each complete expression is dispatched under operator control. We would also like to be able to control how the Starfish manager should process compound expressions and results under appropriate conditions. As always, our goal is to have predictable outcomes even when faced with unpredictable remote behaviors. Sometimes this requires operator control, and sometimes it can proceed automatically.

Starfish is potentially a framework for expressing system management tasks which are a mixture of operator control and automated evaluation. Its existing mechanisms for command filtering and object selection are a first step toward gaining experience with how this should work. What is needed is a notation for expressing control structure at the manager end. This might begin with a library of more primitive idioms such as "advance over successful nodes", "repeat over failed nodes", "split", "merge", "breakpoint", and so on. Sites could then develop their own management algorithms using these primitives.

Many of these primitives are reminiscent of symbolic debugging, and indeed debugging is an accurate metaphor for the control model we envision. In terms of implementation, the Starfish manager must first provide an interpreter which can load and save these control expressions in modular fashion. The next task is to implement a library of useful primitives.

Library of agent customization modules

The agent module framework exists, but contains only some initial examples to demonstrate how it can be used. Please see the Participation section for details.

Extensible help

Unify support for IPv4 and IPv6

Continued work on software refactoring

The principles of simplicity and clarity are extremely important in a product intended to perform secure remote system management. There is no security in blind trust, and so, unlike proprietary solutions, the Starfish software is licensed and distributed in source form so as to fully expose it to inspection.

We have designed Starfish so that a system professional can sit down with a cup of coffee and gain a comfortable understanding of any part of the source code before the coffee gets cold. As system professionals ourselves, we know that you want to have that kind of confidence in the tools you use.

Suggestions welcome!

	History editor for command window The present command window is a simple text editor with the ability to recognize a complete expression and dispatch it automatically. In addition to this simple behavior, it would be nice to have an enclosing history mechanism by which previous expressions could be retrieved and edited. This might include the ability to load and save the command history for use outside the current session.
	Support for saving, organizing, and filtering history logs The Starfish manager logs the expressions and results for each node in the current session. It may be useful to save these logs for later analysis. When there are many nodes, it would help to have some simple pattern matching tools in order to minimize the need to inspect each log individually.
	Framework for host attribute databases A general framework is needed in the Starfish manager to support modules which interoperate with site databases describing the systems to be managed. Different sites can be expected to have quite distinctive ways of organizing this information. Starfish can't anticipate what these might be, but it can at least provide a suitable customization interface. The existing "netdb" functionality should be moved into this framework.
	Manager customization modules for compound expressions The command window is used to hold expressions for remote execution by Starfish agents. In the simplest case, each complete expression is dispatched under operator control. We would also like to be able to control how the Starfish manager should process compound expressions and results under appropriate conditions. As always, our goal is to have predictable outcomes even when faced with unpredictable remote behaviors. Sometimes this requires operator control, and sometimes it can proceed automatically. Starfish is potentially a framework for expressing system management tasks which are a mixture of operator control and automated evaluation. Its existing mechanisms for command filtering and object selection are a first step toward gaining experience with how this should work. What is needed is a notation for expressing control structure at the manager end. This might begin with a library of more primitive idioms such as "advance over successful nodes", "repeat over failed nodes", "split", "merge", "breakpoint", and so on. Sites could then develop their own management algorithms using these primitives. Many of these primitives are reminiscent of symbolic debugging, and indeed debugging is an accurate metaphor for the control model we envision. In terms of implementation, the Starfish manager must first provide an interpreter which can load and save these control expressions in modular fashion. The next task is to implement a library of useful primitives.
	Library of agent customization modules The agent module framework exists, but contains only some initial examples to demonstrate how it can be used. Please see the Participation section for details.
	Extensible help
	Unify support for IPv4 and IPv6
	Continued work on software refactoring The principles of simplicity and clarity are extremely important in a product intended to perform secure remote system management. There is no security in blind trust, and so, unlike proprietary solutions, the Starfish software is licensed and distributed in source form so as to fully expose it to inspection. We have designed Starfish so that a system professional can sit down with a cup of coffee and gain a comfortable understanding of any part of the source code before the coffee gets cold. As system professionals ourselves, we know that you want to have that kind of confidence in the tools you use.