Re: [linuxtools-dev] TCF and remote profiling/tracing

[Corey Ashford <cjashfor@xxxxxxxxxxxxxxxxxx>]

On 06/08/2011 10:14 AM, Jeff Johnston wrote:
> On 06/07/2011 09:51 PM, Corey Ashford wrote:
>> On 05/25/2011 02:52 PM, Jeff Johnston wrote:
>> ...
>>> 2. I would like to cease the shipping of the rpm over to the remote
>>> system.  Instead, I would like to create a new Fedora/RHEL package
>>> containing our TCF agent(s).  That way it can be installed from the
>>> remote side using the normal mechanisms.  This prevents the client from
>>> having to store rpms for all supported systems and platforms.  We can
>>> maintain the package for Fedora/RHEL.
>>>
>>> User's on other systems can pressure their maintainers to add the
>>> package or they can start the agent manually and do the manual
>>> specification using the environment variables as they can today.
>>>
>>
>> How do you handle the case where the user is running an older distro?
>> Let's say I'm targeting RHEL 6.0, which doesn't have this RPM?  There
>> should be a convenient place where I can download the package source and
>> build an RPM manually, or even better, pre-built RPM's for older distros.
>>
> 
> Remote start won't work for all platforms.  The idea is that we supply
> rpms for those RHEL and Fedora platforms we are willing to support and
> for other platforms/distros, the agent needs to be started manually by
> the end-user.  An end-user can always request the rpm be added on any
> platform that we don't initially supply.
> 
> The souce code for the agent(s) would be publicly available and would
> have documentation on how to build.  For older RHEL distros, we could
> add the packages here at Red Hat as errata.  I'm not sure if we want to
> get into maintaining our own rpm repository for unofficially-supported
> RHEL packages.

That sounds workable.  I assume SuSE might have a similar facility for SLES.

>>> 5. The tcf agent runs as a root daemon.  This is dangerous since the tcf
>>> agent has capability of doing just about anything (starting processes,
>>> moving files around).  Does Lttng require root access?  Valgrind does
>>> not, but OProfile for instance, does.  I have recently worked on setting
>>> up policy kit to run /usr/bin/opcontrol (using pkexec and having a
>>> policy file).
>>
>> The Linux "perf" tool requires root privilege if you perform a
>> system-wide measurement (per-cpu profiling or event counting).  So,
>> unlike OProfile, you only sometimes need root access.
> 
> That would be fine.  The idea would be that that you would establish
> special services withs commands for any tasks that require root access
> and use generic TCF agent services for those that don't.  The special
> service tasks would ultimately use pkexec and have policy files set up.
>  If you wanted to restrict usage to only some sub-options of perf, this
> could be done indirectly by having perf run from a module which you
> would set up a policy file for and install under root (i.e. instead of
> having pkexec run perf for any option and potentially cause problems,
> your module would only run perf with suboptions A, B, C, etc... options
> that you allow from the client dialog and are deemed ok).

The whole PolicyKit infrastructure is something I need to understand
better.  Time for study!

>>
>> On another subject, from our perspective, it would be nice if there were
>> some standardized way to extend the functionality of the target agent,
>> perhaps through .so plug-ins, so that custom tools can make use of the
>> agent.
>>
> 
> Are you referring to "on-the-fly" extensions?  There is already the
> ability to extend the agent with your own services with their own commands.
> 
> In addition, multiple agents can run on the same system and contribute
> different services.  They cooperate; to the client they appear as one
> remote agent.  So, if agent A is running already and agent B is started
> on the same machine, it can add additional services not found in A.

Great!  I wasn't aware of that.  I haven't studied TM.TCF much yet either.

- Corey