On Thu, Aug 14, 2008 at 11:32 AM, Henry Zhang <Hua.Zhang at sun.com> wrote: > Brian, etc. all: > > See my answer in-line below. > > Please see the updated proposal according to all of the comments. > See the attchemnt. > > Thanks, > Henry > > Brian Cameron ??: >> >> Henry: >> >>>> Sections 3.1, 3.4, 4.1, and 4.4 all discuss that Gkrellm supports >>>> plugins, but there is no information about plugins in the exported >>>> interface table. How can it support a plugin framework without >>>> exporting any related interfaces? >>> >>> Sure, it export /usr/include/gkrellm2/gkrellm.h, in which the structure >>> GkrellmMonitor is listed, it's used to record all plugin relative functions. >>> I will add it to export interface of the proposal. >> >> After I've written a plugin, how do I integrate it into the GKrellM >> infrastructure. Do plugins have to be installed in a particular >> location, for example, for them to be loaded by the GKrellM daemon? >> >> If so, this plugin directory (or whatever interface is used) should be >> highlighted in the ARC materials and the manpage. > > Yes, generally the plugin is stroed under /usr/lib/gkrellm2/plugins, and I > have added it to the one-pager, and it have been in the manpage. >> >>>>> 4.11. Security Impact: >>>>> >>>>> There is no additional security impact for Solaris. >>>> >>>> How can something which uses OpenSSL, has a plugin framework, and allows >>>> remote observation of a network's health have no security impact? >>> >>> I think there is some general security problem when an application >>> connect to network, it may exist all applications using OpenSSL/plugin. >>> I will add some words to identify that this application is using OpenSSL, >>> and support plugin to transfer system status information. >> >> Is it possible for a person to write a plugin that does something >> malicious? What protects the system from malicious plugins? Can >> only the sysadmin install new plugins, for example? > > Yes, only sysadmin can install the plugins.
note: plugins can be installed in ~/.gkrellm2/plugins too >> >> What protects the traffic between the remote and local machine from >> malicious snooping? I'd guess OpenSSL is being used for this. I'm >> just saying that the answer should be more fleshed out. "None" isn't >> a good answer in this case. > > OK, I have added some words on it into the one-pager. >> > > Template Version: @(#)onepager.txt 1.29 04/11/15 SMI > > This information is Sun Proprietary/Confidential: Internal Use Only: > Engineering Need-to-Know > > 1. Introduction > > 1.1. Project/Component Working Name: > > GKrellM > > 1.2. Name of Document Author/Supplier: > > Henry Zhang (hua.zhang at sun.com) > > 1.3. Date of This Document: > > 30/07/08 > > 1.4. Name of Major Document Customer(s)/Consumer(s): > > 1.4.1. The PAC or CPT you expect to review your project: > > Solaris PAC > > 1.4.2. The ARC(s) you expect to review your project: > > LSARC > > 1.4.3. The Director/VP who is "Sponsoring" this project: > > Robert.Odea at Sun.Com > > 1.4.4. The name of your business unit: > > JDS Desktop Engineering, OPG > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: leo.binchy at Sun.COM > 1.5.2. Responsible Engineer: hua.zhang at Sun.COM > 1.5.3. Marketing Manager: jeff.mcmeekin at sun.com > 1.5.4. Interest List: gkrellm at sun.com > > 2. Project Summary > > 2.1. Project Description: > > GKrellM, GNU (or Gtk) Krell Monitors (or Meters), is a single process > stack of system monitors which supports applying themes to match its > appearance to your window manager, Gtk, or any other theme. The > current > version is 2.3.1. > > 2.2. Risks and Assumptions: > > 1. Temperature, fan, and voltage sensor monitors not support since > missing > libsensors. > > 2. APM laptop battery meter not support since no APM. > > 3. This application will depend on libgtop, which isn't engineered to > fully > or best support Solaris interfaces for getting system information > because > it was written from a more Linux perspective on system resources, and > some > system information can't get since not fully support from kernel, e.g. > some sensor monitor interfaces. > > 3. Business Summary > > 3.1. Problem Area: > > GKrell is a computer program based on the GTK+ toolkit that creates a > single process stack of system monitors. It can be used to monitor the > status of CPUs, main memory, hard disks, network interfaces, local and > remote mailboxes, and many other things. Plugin is supported. > > 3.2. Market/Requester: > > JDS Desktop group > > 3.3. Business Justification: > > For many users, it's nice to be able to see, real-time, what is > happening > on their system. There are ways to display memory usage, cpu usage, > network > traffic, available and used disk space, and a whole lot of other > similar > system statistics. This makes it easier to troubleshoot and notice > problems > as they come up. To be display these monitors, you will need gkrellm. > > It's a very useful monitoring tool, can replace a lots of the dock > applets, what's even better is that gkrellm supports a plugin > interface, > allowing vast expandability, it's also infinitely configurable and > themeable. > > Additionally Gkrellm is very easy on the CPU and packs a lot of > information > into a little bit of space. > > 3.4. Competitive Analysis: > > Windows XP has SysMetrix, Windows Vista has this type of side bar, > and GKrellM can run in Linux and other Unix-like operating systems. > > 3.5. Opportunity Window/Exposure: > > It is expected that this project will be integrated into Nevada B100 > > Note: this tool has GPL V3 license, it will not integrated into > Nevada until the license issue is solved. > > 3.6. How will you know when you are done?: > > When it is ported to Nevada and runs correctly. > > The project will be complete when there are no stoppers, P1 or P2 > bugs. > > 4. Technical Description: > > 4.1. Details: > > GKrellM is a GTK-based stacked monitor program that charts SMP CPUs, > disks, load, active net interfaces, and internet connections. There > are > also builtin monitors for memory and swap, file systems with > mount/umount > feature, mailbox checking including POP3 and IMAP, clock/calendar, > laptop > battery, sensors (temperatures, voltages, and fans), and uptime. It > has > LEDs for the net monitors and an on/off button and online timer for > PPP. > Multiple monitors managed by a single process to reduce system load. > There is a GUI popup for configuration, plugin extensions can be > installed, > and many themes are available. It also features a client/server > monitoring > capability. > > If you want to configure GkrellM, you can right-click on the monitor > and > select Configuration from the drop-down menu, or press the F1 key at > anytime while GKrellM has the focus. The configuration menu lets you > modify general options, built-in monitors, plug-ins, and themes. > > GKrellM consists of the gkrellm client and the gkrellmd server. > Gkrellm can > run in client mode and collect data from gkrellmd server running on a > remote > machine. In this way, the user can remotely monitor different > characteristics > of all the machines on their LAN, such as hits and load on the web > server, > disk usage on the mail server, and port traffic on the NAT. > > The gkrellm client gets data from gkrellmd through SSH. By default > gkrellmd > will not run by default, so the user need to start gkrellmd manually, > and optionally add options to configure gkrellmd. For example, > you can configure which port gkrellmd will use and which IP addresses > or > hostnames are allowed to connect to gkrellmd. gkrellm client will also > be > configured to use some port, this port is used to create the SSH > connection > with the gkrellmd server given port. Then you can start gkrellm on > another > system and get the remote data from gkrellmd. > > Both gkrellm and the gkrellmd server are plugin capable so special > interest > monitors can be coded. And in order to make install plugin, you should > be root, > and ensure the plugin will not add additional security issue. > > > 4.2. Bug/RFE Number(s): > > RFE 6732524 > > 4.3. In Scope: > > The system information we can get from Solaris > > 4.4. Out of Scope: > > The system information Solaris can't support, e.g. temperature. > All plugins that are installed by users themselves. > > 4.5. Interfaces: > > Imported Interfaces > Interface Stability Comments > ------------------- ----------- > ----------------------------------- > > /usr/lib/libkstat.so.1 Committed standard library > SUNWgettext Uncommitted > libgtop Volatile LSARC/2006/347/ > libOpenSSL Contract Private PSARC/2006/019/ > GNOME Committed Platform Libraries Committed LSARC/2007/520 GTK+ > library > GNOME 2.20 > > Exported Interfaces Stability Comments > ------------------------- ------------- > --------------------------------- > > /usr/bin/gkrellm Volatile > SUNWgkrellm Uncommitted Package name > SUNWgkrellm-devel Uncommitted Package name > /usr/include/gkrellm2/gkrellm.h Project Private > /usr/lib/gkrellm2/plugins Project Private Used to store plugins > > 4.6. Doc Impact: > > Man page will need to be added > > 4.7. Admin/Config Impact: > > There are no changes to the system administration and configuration. > > 4.8. HA Impact: > > N/A > > 4.9. I18N/L10N Impact: > > The JDS team and the G11N are working together to evaluate and provide > I18N/L10N support. > > > 4.10. Packaging & Delivery: > > The new packages are: > > - SUNWgkrellm > - SUNWgkrellm-devel > > 4.11. Security Impact: > > This application uses OpenSSL, and support plugins, it may cause some > security concern, but generally all data transfered through the > connection > is the system usage status information, and not very confidential, > addtionally in order to make the network connection more secure, > this application is using SSH and some configuration on IP/port to > use, > see 4.1 for details. > > 4.12. Dependencies: > > SUNWgettext.spec > Gtk+ 2.0 >= 2.0 > gdk 2.0 > glib 2.0 >= 2.0 > libgtop > libssl > > 5. Reference Documents: > > GKrellM main project page: > http://gkrellm.net > > GKrellM Wiki: > http://en.wikipedia.org/wiki/GKrellM > > GKrellM themes site: > http://www.muhri.net/gkrellm/ > > > 6. Resources and Schedule: > > 6.1. Projected Availability: > > Expect to integrated into Nevada in build 100 in Q3 2008 > > 6.2. Cost of Effort: > > Development 1.0 Engineers - 1 Months > Testing 0.5 Engineers - 1 Week > RE 0.5 Engineers - 1 Week > > 6.3. Cost of Capital Resources: > > N/A > > 6.4. Product Approval Committee requested information: > > 6.4.1. Consolidation or Component Name: > > JDS / OpenSolaris > > 6.4.3. Type of CPT Review and Approval expected: > > Standard > > 6.4.4. Project Boundary Conditions: > > None > > 6.4.5. Is this a necessary project for OEM agreements: > > No > > 6.4.6. Notes: > > N/A > > 6.4.7. Target RTI Date/Release: > > Nevada B100 - Sep. 2008 > > 6.4.8. Target Code Design Review Date: > > Sep. 2008 > > 6.4.9. Update approval addition: > > New project, no Solaris PAC approval yet > > 6.5. ARC review type: > > FastTrack > > 7. Prototype Availability: > > 7.1. Prototype Availability: > > Sep. 2008 > > 7.2. Prototype Cost: > > 1 engineer > 1 QA > 1 RE > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc at opensolaris.org > -- Andy http://blog.sartek.net
