Re: [Ganglia-developers] Web 2.0 UI code freeze
On Wednesday 06 April 2011, Vladimir Vuksan wrote:
I spoke to Bernard and we are considering doing a code freeze of the Web
2.0 UI. I'd like to release it by the end of month so that people can start
using it.
Thoughts ?
Excellent work!
I did some small modifications:
- remove config option $conf['show_cores'] (There is no code which will use
it)
- link to the graph_all_periods.php at the grid overview (like at the cluster
overview)
- at graph_all_periods.php link the graphs to graph.php (like at the grid
overview)
monitor-web-2.0$ svn diff
Index: conf_default.php.in
===
--- conf_default.php.in (revision 2570)
+++ conf_default.php.in (working copy)
@@ -121,11 +121,6 @@
$conf['cpu_num_color'] = FF;
$conf['num_nodes_color'] = 00FF00;
-#
-# Display number of cores in LOAD report graph
-#
-$conf['show_cores'] = false;
-
# Other colors
$conf['jobstart_color'] = ff3300;
Index: templates/default/meta_view.tpl
===
--- templates/default/meta_view.tpl (revision 2570)
+++ templates/default/meta_view.tpl (working copy)
@@ -45,21 +45,21 @@
{if isset($source.self_summary_graphs)}
TD ALIGN=RIGHT VALIGN=TOP
-A HREF=./graph.php?{$source.graph_url}amp;g=load_reportamp;z=large
+A HREF=./graph_all_periods.php?
{$source.graph_url}amp;g=load_reportamp;z=large
IMG SRC=./graph.php?
{$source.graph_url}amp;g=load_reportamp;z=medium
ALT={$source.name} LOAD BORDER=0
/ABR
-A HREF=./graph.php?{$source.graph_url}amp;g=cpu_reportamp;z=large
+A HREF=./graph_all_periods.php?
{$source.graph_url}amp;g=cpu_reportamp;z=large
IMG SRC=./graph.php?
{$source.graph_url}amp;g=cpu_reportamp;z=medium
ALT={$source.name} CPU BORDER=0
/A
/TD
TD VALIGN=TOP
-A HREF=./graph.php?{$source.graph_url}amp;g=mem_reportamp;z=large
+A HREF=./graph_all_periods.php?
{$source.graph_url}amp;g=mem_reportamp;z=large
IMG SRC=./graph.php?
{$source.graph_url}amp;g=mem_reportamp;z=medium
ALT={$source.name} MEM BORDER=0
/ABR
-A HREF=./graph.php?
{$source.graph_url}amp;g=network_reportamp;z=large
+A HREF=./graph_all_periods.php?
{$source.graph_url}amp;g=network_reportamp;z=large
IMG SRC=./graph.php?
{$source.graph_url}amp;g=network_reportamp;z=medium
ALT={$source.name} NETWORK BORDER=0
/A
Index: graph_all_periods.php
===
--- graph_all_periods.php (revision 2570)
+++ graph_all_periods.php (working copy)
@@ -78,7 +78,7 @@
print 'div class=img_view' .
'a href=./graph.php?r=' . $key . $query_string .'csv=1img alt=Export
to CSV height=16 width=16 src=img/csv.png/a ' .
'a href=./graph.php?r=' . $key . $query_string .'json=1img
alt=Export to JSON height=16 width=16 src=img/js.png/a' .
- 'br /img alt=Last ' . $key . ' src=graph.php?r=' . $key . 'z=' .
$largesize . $query_string . '/div';
+ 'br /a href=./graph.php?r=' . $key . 'z=' . $xlargesize .
$query_string . 'img alt=Last ' . $key . ' src=graph.php?r=' .
$key . 'z=' . $largesize . $query_string . '/a/div';
}
// The div below needs to be added to clear float left since in aggregate
view things
Markus
--
Markus Köberl
Graz University of Technology
Signal Processing and Speech Communication Laboratory
E-mail: markus.koeb...@tugraz.at
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Web 2.0 UI code freeze
Here's what I've been working on:
1. Create a login.php script. This is protected by Apache authentication so
you can use htpasswd, LDAP, or whatever you want for authentication. If you're
able to access this page, your username + a shared secret is hashed stored in
a cookie. The shared secret is stored in Apache config ('SetEnv ganglia-secret
myreallysecretphrase'), so it can be read only by root. Users w/o root access
could still set it in .htaccess, but it wouldn't be as secure.
2. Using Zend_Acl to set up access controls.
- Anyone can view any public cluster without logging in.
- Private clusters don't appear until you log in and have permissions to view
them.
- You cannot save views or otherwise make changes unless you log in and have
appropriate permissions.
Basically, there are only 'view' and 'edit' privileges, applied on a
per-cluster basis. There's a 'guest' role which applies if you're not
authenticated, and there's an 'admin' role which has full access.
3. A ganglia-specific authorization system compares your cookie to the Zend_Acl
list, and decides whether you can or can't do a certain thing.
4. User-editable files like view definitions get moved to
/var/lib/ganglia/data. Keeping them out of the web root reduces the danger if
the code which does the writing is ever exploited.
I've got a lot of this created. It's rough, but coming together fairly quickly.
Should we maybe release a 'preview' of the new web UI without this stuff? I
agree we should get the new UI out in front of more people. But I do also
think we need to address the security implications of what we've currently got
before making an official release.
thoughts?
alex
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Web 2.0 UI code freeze
Seems like a plausible approach. I'd like to see a working version of it
:-). We should really classify usage scenarios ie.
1. Ganglia behind the firewall no access controls needed or Ganglia
protected using Basic Auth
2. Grainy access controls like the ones you have outlined
Beyond that we have potential issues like
1. Whether person has access sanitize input. Exposure here is on the Edit
Optional Graphs and Views and using things like ../.. etc. I already have
parts of input sanitization in edit optional graphs.
2. XSS and CSRF are dangers with XSS likely easy to fix.
Vladimir
On Thu, 14 Apr 2011 10:17:24 -0500, Alex Dean a...@crackpot.org wrote:
Here's what I've been working on:
1. Create a login.php script. This is protected by Apache
authentication
so you can use htpasswd, LDAP, or whatever you want for authentication.
If
you're able to access this page, your username + a shared secret is
hashed
stored in a cookie. The shared secret is stored in Apache config
('SetEnv ganglia-secret myreallysecretphrase'), so it can be read only
by
root. Users w/o root access could still set it in .htaccess, but it
wouldn't be as secure.
2. Using Zend_Acl to set up access controls.
- Anyone can view any public cluster without logging in.
- Private clusters don't appear until you log in and have permissions
to
view them.
- You cannot save views or otherwise make changes unless you log in and
have appropriate permissions.
Basically, there are only 'view' and 'edit' privileges, applied on a
per-cluster basis. There's a 'guest' role which applies if you're not
authenticated, and there's an 'admin' role which has full access.
3. A ganglia-specific authorization system compares your cookie to the
Zend_Acl list, and decides whether you can or can't do a certain thing.
4. User-editable files like view definitions get moved to
/var/lib/ganglia/data. Keeping them out of the web root reduces the
danger
if the code which does the writing is ever exploited.
I've got a lot of this created. It's rough, but coming together fairly
quickly.
Should we maybe release a 'preview' of the new web UI without this
stuff?
I agree we should get the new UI out in front of more people. But I do
also think we need to address the security implications of what we've
currently got before making an official release.
thoughts?
alex
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and
improve
application availability and disaster protection. Learn more about
boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Web 2.0 UI code freeze
On Apr 11, 2011, at 10:24 PM, Jesse Becker wrote: I think that we should punt authentication to other systems/modules that are dedicated to doing so. Yes, I agree that's a good solution. Dumping the ganglia-specific private_clusters database in favor of authentication provided by Apache is a good idea, and shouldn't be hard to do. We still need some sort of authorization mechanism though, mapping users-privileges or (as you suggest) groups-privileges. If a user wants to store custom views and such, push it into a cookie, and store it on the browser side. Under *NO* circumstances should we allow a user to write data to the server through Ganglia. I don't agree. Restricting to cookie-based storage means views can't be shared easily, and will be lost when you clear cookies. I think it's possible to safely allow web-based configuration of views, though I agree it's non-trivial. If it's filesystem access which is the red flag, maybe we look at something like sqlite (which is available by default in PHP5), and/or move the conf/ directory outside of the web root. I think it makes sense to ship the UI with a restrictive default access policy for people who don't want to allow web-based configuration. But we should implement code to make web-based config possible for those who do. I put together some idea-code for this last night, but it's all based on keeping a text file of users password like private_clusters. I'll need to take another pass at it to push all authentication back to Apache. (I agree that should be done.) https://github.com/alexdean/ganglia-misc/blob/add-acl/ganglia-web/auth.php alex -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Web 2.0 UI code freeze
I am not sure what the right approach is. We could provide optional authentication but this may be better addressed by people implementing access controls in Apache ie. adding Basic auth to particular URLs. You could certainly easily disable writing by setting proper permissions on conf/ directory. This may be a non-issue for lots of people who are behind firewalls and do not want an extra level of authentication. Perhaps we should just document some of these approaches instead of reinventing the authentication. Thoughts ? Vladimir On Sun, 10 Apr 2011, Alex Dean wrote: On Apr 6, 2011, at 1:34 PM, Bernard Li wrote: Hi all: On Wed, Apr 6, 2011 at 11:14 AM, Vladimir Vuksan vli...@veus.hr wrote: I spoke to Bernard and we are considering doing a code freeze of the Web 2.0 UI. I'd like to release it by the end of month so that people can start using it. Yeah, let's try to get this out soon. From the TODO https://sourceforge.net/apps/trac/ganglia/browser/branches/monitor-web-2.0/TODO, I'd like to get the following done before the code freeze: - Add back the Ganglia logo - Provide an easy method for user to add their organization's logo In my opinion, the new UI features which write to the file system on the web server (to save view definitions, etc) should require some kind of authentication. Allowing any random user to change the UI's configuration seems like a hole we should fill before releasing. Does anyone use the 'private clusters' feature which is implemented in auth.php? Seems like we could use this authentication mechanism, though I did have a few concerns. - The authentication database is a 'private_clusters' text file, stored in the same directory as auth.php. That means I could take a look at http://site.com/ganglia/private_clusters via my web browser and download the whole list of cluster names MD5 hashes. - I'm not a crypto guy, but I believe the MD5 algorithm is now widely considered to be insecure, and not something we should be relying on. http://en.wikipedia.org/wiki/MD5#Security Before release, I suggest we: - Move the private_clusters file outside Apache's DocumentRoot. Maybe @sysconfdir@/private_clusters? - Update auth.php to use a more secure (but still widely available) hashing algorithm. SHA1 or otherwise? - Require authentication for actions which can change UI configuration, like creating/altering views, or for any other action which might write user data to the web server's filesystem. - Support a wildcard cluster name in private_clusters, or a 'root' user, so an admin would only need to define 1 password to be able to edit anything in any cluster. Maybe that's what the 'control' context is for? alex -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Web 2.0 UI code freeze
On Apr 11, 2011, at 9:07 PM, Vladimir Vuksan wrote: I am not sure what the right approach is. We could provide optional authentication but this may be better addressed by people implementing access controls in Apache ie. adding Basic auth to particular URLs. You could certainly easily disable writing by setting proper permissions on conf/ directory. This may be a non-issue for lots of people who are behind firewalls and do not want an extra level of authentication. Perhaps we should just document some of these approaches instead of reinventing the authentication. Thoughts ? I agree about not wanting to overly complicate things. If we had some is_writable() checks, and didn't display links to actions which required write access (like updating a view) when that access wasn't available, that would probably be enough to implement a basic level of security. It seems a little clunky to have to chmod the filesystem, make some changes, and chmod it back, but it may be good enough for now. If we go that route, I think our Makefile ought to set the conf/ directory as read-only by default. I like the idea of using Apache's authentication mechanisms, but they may not be fine-grained enough in some cases. For example, view.php is used both to display a view and to modify it. How would you make it read-only for some users, but allow admins to edit views? You might be able to use a LocationMatch directive, but that seems likely to become a mess in a hurry. I think it would be pretty straightforward to take the concept already in auth.php, and add a distinction between 'view' (for private clusters) and 'edit' (for actions which change config) permissions. Collecting username password from the user could still be done via HTTP auth as is already done in auth.php, but you'd need to change the file to distinguish between those who can edit and those who can view. This doesn't feel overly complex to me, but I'm interested in what others have to say. I don't want to hold up a release if I'm the only one who's concerned. Any other opinions out there? alex -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Web 2.0 UI code freeze
I think that we should punt authentication to other systems/modules
that are dedicated to doing so. Apache (et al) have lots of ways of
handling authentication, and I don't see *any* reason to reinvent the
wheel here, and a lot of reasons not to.
If we want to provide hooks to allow for access based on a username,
that's fine (if (valid_auth(user) and (user in lis)t) { display
chart} sort of thing). This is even a useful trick, and could be
extended to groups (from /etc/group, AD, NIS, etc), if we so choose.
But punt the authentication stuff to something else entirely.
If a user wants to store custom views and such, push it into a cookie,
and store it on the browser side. Under *NO* circumstances should we
allow a user to write data to the server through Ganglia. Having a
canned view, created by the admin, stored in a config file on the
webserver is okay, so long as it is not possible to edit the file
through the web pages.
On Mon, Apr 11, 2011 at 22:38, Alex Dean a...@crackpot.org wrote:
On Apr 11, 2011, at 9:07 PM, Vladimir Vuksan wrote:
I am not sure what the right approach is. We could provide optional
authentication but this may be better addressed by people implementing
access controls in Apache ie. adding Basic auth to particular URLs. You
could certainly easily disable writing by setting proper permissions on
conf/ directory. This may be a non-issue for lots of people who are behind
firewalls and do not want an extra level of authentication. Perhaps we
should just document some of these approaches instead of reinventing the
authentication.
Thoughts ?
I agree about not wanting to overly complicate things.
If we had some is_writable() checks, and didn't display links to actions
which required write access (like updating a view) when that access wasn't
available, that would probably be enough to implement a basic level of
security. It seems a little clunky to have to chmod the filesystem, make
some changes, and chmod it back, but it may be good enough for now. If we go
that route, I think our Makefile ought to set the conf/ directory as
read-only by default.
I like the idea of using Apache's authentication mechanisms, but they may not
be fine-grained enough in some cases. For example, view.php is used both to
display a view and to modify it. How would you make it read-only for some
users, but allow admins to edit views? You might be able to use a
LocationMatch directive, but that seems likely to become a mess in a hurry.
I think it would be pretty straightforward to take the concept already in
auth.php, and add a distinction between 'view' (for private clusters) and
'edit' (for actions which change config) permissions. Collecting username
password from the user could still be done via HTTP auth as is already done
in auth.php, but you'd need to change the file to distinguish between those
who can edit and those who can view.
This doesn't feel overly complex to me, but I'm interested in what others
have to say. I don't want to hold up a release if I'm the only one who's
concerned. Any other opinions out there?
alex
--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
--
Jesse Becker
--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Web 2.0 UI code freeze
On Apr 6, 2011, at 1:34 PM, Bernard Li wrote: Hi all: On Wed, Apr 6, 2011 at 11:14 AM, Vladimir Vuksan vli...@veus.hr wrote: I spoke to Bernard and we are considering doing a code freeze of the Web 2.0 UI. I'd like to release it by the end of month so that people can start using it. Yeah, let's try to get this out soon. From the TODO https://sourceforge.net/apps/trac/ganglia/browser/branches/monitor-web-2.0/TODO, I'd like to get the following done before the code freeze: - Add back the Ganglia logo - Provide an easy method for user to add their organization's logo In my opinion, the new UI features which write to the file system on the web server (to save view definitions, etc) should require some kind of authentication. Allowing any random user to change the UI's configuration seems like a hole we should fill before releasing. Does anyone use the 'private clusters' feature which is implemented in auth.php? Seems like we could use this authentication mechanism, though I did have a few concerns. - The authentication database is a 'private_clusters' text file, stored in the same directory as auth.php. That means I could take a look at http://site.com/ganglia/private_clusters via my web browser and download the whole list of cluster names MD5 hashes. - I'm not a crypto guy, but I believe the MD5 algorithm is now widely considered to be insecure, and not something we should be relying on. http://en.wikipedia.org/wiki/MD5#Security Before release, I suggest we: - Move the private_clusters file outside Apache's DocumentRoot. Maybe @sysconfdir@/private_clusters? - Update auth.php to use a more secure (but still widely available) hashing algorithm. SHA1 or otherwise? - Require authentication for actions which can change UI configuration, like creating/altering views, or for any other action which might write user data to the web server's filesystem. - Support a wildcard cluster name in private_clusters, or a 'root' user, so an admin would only need to define 1 password to be able to edit anything in any cluster. Maybe that's what the 'control' context is for? alex -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
[Ganglia-developers] Web 2.0 UI code freeze
I spoke to Bernard and we are considering doing a code freeze of the Web 2.0 UI. I'd like to release it by the end of month so that people can start using it. Thoughts ? Vladimir -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Web 2.0 UI code freeze
Hi all: On Wed, Apr 6, 2011 at 11:14 AM, Vladimir Vuksan vli...@veus.hr wrote: I spoke to Bernard and we are considering doing a code freeze of the Web 2.0 UI. I'd like to release it by the end of month so that people can start using it. Yeah, let's try to get this out soon. From the TODO https://sourceforge.net/apps/trac/ganglia/browser/branches/monitor-web-2.0/TODO, I'd like to get the following done before the code freeze: - Add back the Ganglia logo - Provide an easy method for user to add their organization's logo Additionally: - Fix the graph titles (may be tough to test w/ Graphite integration as well) - In Cluster View, when user puts cursor on the Metric textfield, it should present a list of all metrics available - Add code to functions.php to determine whether a corresponding setting is defined in $user[] and thus overwrite the setting from $conf[] (eg. use case is the $hostcols setting) I would suggest everybody to provide feedback for what they want for *this* release, i.e. something essential for uptake of this release. We will continue to improve the code to make it better, but right now we should focus on packaging it up for consumption by the general Ganglia community. Thanks! Bernard -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
