While we have IP restrictions, that doesn't stop someone on a, say, a
public server from sending up erroneous results.
I think I'll start with the unsolicited Messages, which is easy. For
"correctness", I'll handle "validity" and "error handling" next
(validity has to do with the unsolicited messages, since the Server has to perhaps handle the unsolicited
messages differently, though not necessarily consider them "invalid").
After that, I think I'll work on the Result
handling and Clients (they go hand-in-hand, almost; you
need one for the other).
I'm handling the multicasting second-to-last, even though it is an
important feature. This is because it will take a bit of reading to
learn how it works and how to program for it. It'll take some time,
where I can get most of a working system going now without it. We
just won't have any scalability to large networks.
The final thing will be the security. I have to give this some
thought to figure out what the best method will be. While a specific
installation might not have anything so sensitive that it can't be
viewed by anyone, or that there's no worry of malicious interference,
another installation may not be so carefree. Also, while we've only
really talked about Soigan as a information retrieval system, there's
no reason that it can't be existed to be a remote execution system.
It uses XML-RPC, after all -- Remote Procedure Call. The same tool
that finds runaway processes might also want to send a command to kill
it, or a tool that tracks down where a user is logged in might want to
boot them. Systems might be told to reboot, to start a service, or to
run an updater.
This makes me think of categorizing the different "kinds" of plugins
that might be written. As I've developed the first draft of Soigan,
the use of Nagios plugins seems to be less and less important, as
they're quite restricted compared to Soigan's abilities. Even so,
there's a certain need for "test" plugins, which test if a machine is
up, if a service is running, or if a package is installed. This is
what Nagios plugins do, for the most part. Then we have full-fledged
Soigan plugins, which return a large dataset. Call these "get"
plugins. We've also mentioned ones that aren't passive, but might
cause a change or event to occur. Perhaps "run" or "exec" plugins is
a good name for these. Are there other types? It's something to
consider in a bit.
As it stands, I've got a system that does a pretty good job of data
retrieval. But so what? What do we do with this data? So far all
I've done is dumped it to the screen, which was kind of exciting and
all, but we need something a little better, a little more useful.
Clients haven't really been discussed before.
These are programs that connect to the Server,
make Queries, and get Results. The Results
represent the data in the Responses that the
Server received from the Workers. Phew, that's a lot of terminology.
Currently I picture four types of Clients, three
are interactive and one is not. First the three interactive
A PHP (or similar) web interface where people can submit queries
through the Server, possibly set up new Services on the Server, and
see the Results in a variety of forms, such as
graphs or lists of problems. This could be a page that shows the info
about a given user (and the processes they've got running, the last 20
times they've logged in, their disk usage, etc); a page about a
machine (processes running, memory usage, /tmp and /var diskspace,
uptime, last 10 logins); or a page about the network (ping results,
ssh availability, number of users). The Query
might be static or adjustable by the user.
A graphical interface to the Server. It might
generate graphs or lists similar to the web interface above. It might
provide a way to submit Queries or might be a
statically designed application. For example, the program might allow
you to ask the Server anything ("How many
users are on host XYZ""), or might do plugin-specific Queries ("where is user FOO logged in?"), or
machine-specific Queries ("tell me everything
about machine XYZ"). This could be written in Java, GTK, QT, VB or
whatever is desired. Portability would, of course, be nice.
A command-line Client. The degree of
interactivity could vary -- it might be a fully interactive system, or
might just take its only input from parameters on the command line.
This would also have range in the strength of its Queries, from a fully definable set of questions to
something simple. For instance, you might be able to supply a
hostname, a plugin name, and all the parameters needed and add a new
Service to the Server,
or you might only be able to run the program with a user name and it
returns all the machines that user is logged into, or where that user
has processes running.
This is the "non-interactive" type of Client,
which could include daemons or cron jobs that run and make Queries, taking further action depending on the
Results; or full applications that have a
Soigan-aware component for whatever the application might need. These
tools would differ from the above three types of Clients in that the tools would act upon the Results returned, where the other three are there
solely for retrieval and display, leaving action up to the user.
There are a few things that we want Clients to
be able to do.
- Execute a one-time NEW Service on a Server
We might wish to know the users on a given host, but the Server isn't set up to automatically ask the Worker, nor is the Worker
set up to provid it unsolicited. This does, however, require that the
plugin exists on the Worker (or perhaps not --
it's entirely possible to extend the Worker
and Server to support uploading of plugins).
- Add a periodic Service to a
Similar to the previous one, this make the addition a permanent event on
the Server until it is shutdown (unless we add
the ability for the Server to edit its own config
file). The Results might be destined for this
Client, or may be intended for general consumption.
- Ask for data that has been previously retrieved
This assumes the Server keeps the information it
gets, which we've previously dismissed. The Client
can then ask for the last ten Responses from a
given Worker running a given Plugin, or all the
information since a certain date.
- Ask for a list of hosts (Workers) the Server communicates with
For interactive Clients, this would allow them to
offer up choices to the user on what is available.
- Ask for a list of Services the Server works with.
Again for interactive Clients, all available
Queries can be calculated from this.
- Ask for the parameters available for a Plugin on a
For Clients that allow a lot of interaction with
the user, this would allow the Client to ask about
the types of options a user would have available to them.
- Register the Client as something
interested in the Results from certain Workers
Clients can be set up to receive updates from
the Server as they come in.
Most of this functionality will work in the traditional XML-RPC way,
that is, the Client calls a function on the
Server, and the function's result is what the
Client is looking for. The exception is the
last one, where the Client is registered for
ongoing Results. Here the
Client will have to listen on a port for an XML-RPC call from
©2002-2018 Wayne Pearson