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 _______________________________________________ linuxtools-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
