[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [linuxtools-dev] TCF and remote profiling/tracing
|
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.
...
4. The tcf agent requires port 1534 to be open. The current set-up
doesn't ensure this. I think that it should take care of this.
I think there should be an option to utilize an ssh tunnel for all of
the communication. In fact, I think this ought to be the default.
Opening holes in firewalls is troublesome and has security risks.
Agreed. I retract the original statement.
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).
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.
-- Jeff J.
- Corey
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
