This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Thoughts Systemtap plugin for Eclipse


I have been looking over the SystemTap plugin for Eclipse (Red Hat
Bugzilla #483205)and the related systemtapgui-server(Red Hat Bugzilla
#483543). The plugin provides:

-list of probe location and available values at probe sites
-list of function
-syntax highlight editor
-assistance generating graphing scripts
-graphing of output

The plugin allows scripts to be run on either the local machine or
remotely on another machine. Both local and remote methods require
systemtapgui-server. The mechanism uses a scp to copy the file over
and then compile it on the target machien.  There are drawbacks to the
way the current mechanism is implemented:

  1) Need to have sshd running on target machine and allow ssh. (minor)

  2) The plugin stores the user ssh/scp password as plan text. (major)
     This file is world readable:
~/workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings/com.ibm.systemtapgui.generic.consolelog.prefs

  3) The plugin does syntax checking on the system eclipse is running
     on.  However, the system that server is running may be different.
     It is possible the script might check okay on plugin but not run
     on server due to those differences.

  4) The systemtapgui-server may allow other processes to connect up
     and run things on the target machine. Could be exploited for
     attacks on machine running systemtapgui-server.

Rethinking how the plugin and systemtap works. A couple possible use
cases for this functionality are:

1) Same person running everything on one machine to make use of the
   graphing and eclipse environment.

2) Person developing on one machine which has everything on it
   (systemtap, debuginfo, kernel-devel...) and sending the resulting
   instrumentation module to a stripped down machine.

The sysetmtapgui-server currently does the following:

-process management on remote machine
-build the instrumentation
-executes script
-collect stdout/stderr

The systemtap compile server does a portion of the work that the
systemtapguiserver does. However, the systemtap compile server doesn't
run the resulting script or send the output to a remote machine.  The
thought would be to minimize systemtapgui-server, so it only reports
the kernel being used (so compile server can build appropriate
instrumentation for target) and runs prebuilt modules with
staprun. Have this instrumentation server in the the systemtap source and
package it like the systemtap compile server and client.

-Will


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]