----- Original Message -----
>
> Hi, Nathan -
>
Hey - thanks for reading.
>
> > My colleague Will Cohen recently floated the idea of using PCP to
> > carefully lift some permissions restrictions in tools like perf,
> > and to enable perf functionality to be injected into PCP to some
> > extent. [...]
>
> It seems to me that the perf angle to this is peripheral; the
> hypothetical new pcp capability is on-demand remote invocation of
> console programs and collection of their outputs.
Yep, certainly - I mention that only to give the background of where
Will's inspiration came from (and one extremely good use case).
> > [...] 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. The simple
"exec" doesn't express that flavour, which is really at the core of
the concept. Yes, you could simply exec something with this, but
there's not alot of point & the power comes from pmevent driving it.
> 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...?
> "ps -ef"
> "smartctl -a $1"
> "dmidecode"
> [...]
Many of these things seem more suited to that old pmdapaste concept
too, btw, which was more generalised again & without the restriction
of having to have thought about the need for certain commands well
ahead of needing to log 'em.
[ http://oss.sgi.com/archives/pcp/2013-09/msg00068.html ]
cheers.
--
Nathan
|