Re: exec.basic - comments please

[Gerry Duprey <gerry@xxxxxxxxxxx>]

Howdy,

>     pid=num       //integer identifier (<2^32)

Based on the comments below, any reason the pid has to be a number?  Since
it's meant to just be a unique identifier, why not let it be whatever the
initiator wants.  If they want a number, great.  If they want to use the
name of the program as a pid, great.  They important point, to me, is that
it's some sort of unique identifier with meaning only to the initiator and
as such, the xplExec service shouldn't impose any meaning (even that it has
to be numeric) on it -- just record it and spit it back in status/trigger
notes.

> Program is the name of the executable file to run, without any path.

Hmmm, I agree about the possibility of running unwanted programs.  Perhaps
the xPLExec program could have a series of config items that either listed
all possible executable programs (i.e. if the program is not listed, it
can't be run) or something like that.  I suspect being able to run an
arbitrary program isn't going to be a great thing, and the actual number of
programs to run is probably pretty low.

In terms of reconfiguring (a very good point), because of the sensitive
nature of this program, perhaps a list of machines (IPs) that can be
reconfigured can be a configurable item itself.  To bootstrap it, if there
are no configurable machines listed, anyone can configure it, but once
there
is 1 or more machines, only those machines can further reconfigure it.

Maybe as a reasonable security measure, the program will not actually
execute any program until there is at least one machine listed as
configurable (implying it has been configured).

It's not perfect, but given the environment, it should be pretty good.

I agree -- you really don't want folks to have to edit config files by
hand.

> The xPLExec application will attempt to spawn the executable, and
> will respond with a status messages containing either status=failed
> or status=started.  If status=failed, then the return item will be
> set to one of the following values:
>
> "argument list too long"
> "invalid argument"
> "program not found"
> "program not executable"
> "out of memory"

Hmmm, in the interests of cross platform use of this schema, perhaps the
actual error message contents shouldn't be declared here.  Different O/Ss
are going to have different failure codes/descriptions and they may not be
mappable (and in the case of a Java version, you'd have to build in every
conceivable platforms mappings so it could be cross platform and sort of
kills the xplatform idea :-)  Having an error message item is good as the
initiator can use it to log a message, display an error, etc.  But other
than it being present, implying meaning on it seems problematic to me.

Gerry
--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org