Hi -
> [...]
> > > [...] We could tackle this problem with a new pmdapipe(1) agent in
> > > PCP
> >
> > (Just toolshedding, but I'd suggest "pmdaexec" or similar instead of
> > "pipe", which reflects an internal implementation artifact.)
>
> Heh - "exec" seems far more the implementation detail (& only a small
> part of the picture) - the "pipe" here is more of the shell pipe (|)
> rather than the popen(3) vs exec(3) detail, reflecting that output
> from one command feeds back to another separate command. [...]
FWIW, I don't see the piping-into-separate-command angle here. The
configured command is EXECuted, and its output is collected, whether
by pipe, named-pipe, pty, socket. It's not sent to another program
for processing on its standard input. (pmevent's output is very noisy
to be used for piping, and it is just ONE client, so it doesn't
deserve to name the pmda.)
> > Consider also system overview type commands, which could be quite
> > informative if logged periodically, along with some crazier ideas:
> >
> > "kill $1"
> > "service $1 $2"
> Er, yep, thats pretty out there. Under what situations would it be
> desirable for a sysadmin to enable that level of crazy? Surely this
> is the realm of sudo, and noone would want to expose that kind of
> thing onto the network via PCP...?
Note that you introduced the notion of a deliberate privilege
escalation here (letting remote pcp clients invoke normally root-only
commands); I'm just showing some logical endpoints of that.
> > "ps -ef"
> > "smartctl -a $1"
> > "dmidecode"
> > [...]
>
> Many of these things seem more suited to that old pmdapaste concept
> too [...]
pmdapaste is indeed interesting, but it is not a way of *executing a
command on the pmcd server side*. You'd need remote execution widget
or a cron job, have it run the client side of pmdapaste. Whereas with
this scheme (adding ps -ef etc. as remote-execution commands for
pmdapipe), a remote client can log these on demand.
- FChE
|