Re: RFC: collecting gnome-shell performance reports

[Owen Taylor <otaylor redhat com>]

I've now put a first cut of my performance report collector at:

Test deployment:
 http://shell-perf.fishsoup.net/

Source: 
 http://git.fishsoup.net/cgit/shell-perf-web

I'll move both to gnome.org ASAP, if people are OK with it.

Going over some topics of interest for newly deployed web services:

Security
========

Authorization: there are no accounts and no logins for the web service.
  When you register a system you provide an owner email. An activation
  link is sent to that address, and for subsequent changes to the
  system information, a confirmation link is sent to that address.

  The activation/confirmation links aren't 100% secure if they are
  used over HTTP rather than HTTPS, but the danger (someone convinces
  you to click on the confirmation link in the mail, then steals
  the authorization token and does the POST to confirm for you) seems
  small compared to the attractiveness of the target - hijacking a
  system that someone else registered to upload data. You could just
  register your own!

  The mail that contains the activation link also contains a secret key
  that is used by gnome-shell to sign uploaded posts. The signature
  is done roughly based on the way that requests are signed in OAuth
  and I believe it to be reasonable secure. (HMAC-SHA1 across the
  URL, URL parameters, and contents of the uploaded report.)

Cross-site-scripting: All content is generated through Django's
  template system, which seems to be good about escaping by
  default.
 
SQL injection: All SQL operations are done through Django's ORM,
  instead of building queries manually, so it should be hard to
  get malicious SQL executed.

Link spam: While anybody can register a system and put arbitrary
  text in the notes, the text isn't linkified, so shouldn't be
  interesting trying to improve search engine juice.

DOS and resource usage: Individual reports are limited to 4MB on
  upload (I expect them to be much smaller). There's no limit
  on how often you upload reports, so someone determined could
  fill up the disk space on the server with reports. I don't think
  it's a big deal. (We don't worry about similar things for
  bugzilla attachments.) You could theoretically use the upload
  mechanism as way of storing and retrieving data, but there are
  far easier ways to store a few gigs of data on the internet
  for free!

Privacy
=======

When you register a system, you provide an email address, and
it tells you that it will be publicly displayed on the system,
and it is. Without logins, there is no way to hide emails behind
a login barrier. We could theoretically use something like
reCAPTCHA's mailhide setup if people are concerned, but it
would be rather annoying in various ways.

The other privacy concern is the contents of the uploaded reports.
Currently they contain nothing personally identifiable at all -
just timing and memory usage data, but they do include a complete
event log of the performance run, so in the future we'll have
to be careful not to, say, include filenames of the user's files
in events recorded to the event log.

Style
=====

It's definitely "my first Django application" and I don't have a great
sense for code organization or how to do things in a Django-ish way.
And it was written to get something going quickly rather than to be
beautiful.

On the other hand, a reasonable amount of care was taken, and it's
not my first Python app or my first web application. I think the code is
OK. It could be made better if someone with interest/experience picked
it up.

Deployment
==========

My plan is to set this up has its own virtualhost as
shell-perf.gnome.org. 

I think the first choice for what system to install it on is the
wiki.gnome.org VM we created to move live.gnome.org to, but is so far
sitting empty. (The idea was that it would host multiple dynamic web
sites, and not exclusively Moin.)

The deployment on shell-perf.fishsoup.net is done using mod_wsgi,
and that's what I've documented in the README. If we put it on
wiki.gnome.org then deploying with mod_wsgi probably means deploying
Moin that way too once we move it over. I don't think we want to mix
mod_python and mod_wsgi in a single Apache instance. The general feeling
seems to be that mod_wsgi is better and more flexible than mod_python,
but I don't personally have much side-by-side experience.

License
=======

I put the code under the Affero GPLv3, since the GPL is a bit weak
for a web app. On the other hand there's pretty much nothing interesting
in this application so it could be switched to GPLv2+ or even a
Python-style BSD license if there was a reason.

Cross browser testing
=====================

It's all standard CSS/HTML - theoretically should work on anythign
modern. Haven't tested anything other than Firefox. Don't care about
anything other than Firefox and Webkit. Not even to the point of doing
the work to display "upgrade to a modern web browser" notices.

Future Work
===========

Plan is to mostly let it grow with our needs. Some things I'd like to do
on the web side:

 - Improve formatting of values - show units, etc.
 - Have additional views to be able to, for example, look at an
   individual performance reports
 - View changes in metrics over time as graphs (maybe using HTML canvas)
 - View uploaded event logs as graphs