Gkrellm for OpenSolaris [LSARC/2008/513 FastTrack timeout 08/19/2008]
Andras Barna
andras.barna at gmail.com
Thu Aug 14 04:22:46 PDT 2008
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
More information about the opensolaris-arc
mailing list