1. 24 Sep, 2012 1 commit
    • Eric Eide's avatar
      Replace license symbols with {{{ }}}-enclosed license blocks. · 6df609a9
      Eric Eide authored
      This commit is intended to makes the license status of Emulab and
      ProtoGENI source files more clear.  It replaces license symbols like
      "EMULAB-COPYRIGHT" and "GENIPUBLIC-COPYRIGHT" with {{{ }}}-delimited
      blocks that contain actual license statements.
      
      This change was driven by the fact that today, most people acquire and
      track Emulab and ProtoGENI sources via git.
      
      Before the Emulab source code was kept in git, the Flux Research Group
      at the University of Utah would roll distributions by making tar
      files.  As part of that process, the Flux Group would replace the
      license symbols in the source files with actual license statements.
      
      When the Flux Group moved to git, people outside of the group started
      to see the source files with the "unexpanded" symbols.  This meant
      that people acquired source files without actual license statements in
      them.  All the relevant files had Utah *copyright* statements in them,
      but without the expanded *license* statements, the licensing status of
      the source files was unclear.
      
      This commit is intended to clear up that confusion.
      
      Most Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the Affero GNU General Public License, version 3
      (AGPLv3).
      
      Most Utah-copyrighted files related to ProtoGENI are distributed under
      the terms of the GENI Public License, which is a BSD-like open-source
      license.
      
      Some Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the GNU Lesser General Public License, version 2.1
      (LGPL).
      6df609a9
  2. 24 Jun, 2005 1 commit
  3. 11 May, 2005 1 commit
    • Leigh Stoller's avatar
      Aside from cleanup, the main change is that instead of using vlc to · 6dae341e
      Leigh Stoller authored
      transcode a motion jpeg into mpeg (very CPU intensive), I know know
      how to alter the camera frame rate on the fly using a wget call. The
      downside is that this affects the camera globally (mpeg rate), but
      thats okay since the grabwebcams script only allows itself to be run
      once at a time to avoid conflict.
      
      Still not hooked into experiment path; waiting for terrabytes of disk
      storage!
      6dae341e
  4. 22 Apr, 2005 1 commit
    • Leigh Stoller's avatar
      Pump up grabwebcam script. Actually, I threw out the existing code · 162036f5
      Leigh Stoller authored
      that picked up single images with scp, and replaced it with stuff that
      can be used to capture movies.
      
      	Usage: grabwebcams [-d] [-v] [-m] [-t timeout]
      	       grabwebcams [-d] [-v] [-t timeout] [-k] pid eid
      	switches and arguments:
      	-d      - Debug mode, use to prevent daemonization
      	-v      - Verbose mode (causes vlc to spit lots of goo)
      	-m      - Movie option; create a 10fps movie from each camera
      	-t <N>  - Terminate automatically and N seconds
      	-k      - Kill a daemonized grabwebcams (only use with pid/eid)
      	pid eid - Project and Experiment (for use with swapin)
      
      The first form allows you to capture a low frame rate movie from the
      webcams. Low means 2fps. The files are written in the current
      directory. Without the -d option, the script goes into the background
      and runs forever, unless you give it a -t option, in which case the
      movies will be terminated after that many seconds.
      
      Add the -m option, and you get 15fps movies, suitable for showing off
      to people. This option IS VERY CPU INTENSIVE. Use it sparingly. It
      might get better once I hear back from the axis people, telling me if
      there is a way to turn up the mpeg fps via a URL (like most everything
      else can be on these cameras). Until then, I am transcoding mjpeg into
      mpeg, and that sucks.
      
      The second form is for use from the swapexp path, to start capturing
      movies when an experiment is swapped in, and then to then to kill it
      off (-k) when the experiment is swapped out. At 2fps, it generates
      about 1MB per camera per minute. Thats a lot of data, so I am not
      hooking this in quite yet; want to give it some more thought.
      
      We may want to export an interface to the web (and commandline) to
      that people can take movies of their experiments at particular times.
      Not sure yet.
      162036f5
  5. 27 Jan, 2005 2 commits
  6. 10 Jan, 2005 1 commit
    • Leigh Stoller's avatar
      A quick hack job to get the webcams onto the web interface. · d46902e1
      Leigh Stoller authored
      * Add new DB table "webcams" which hold the id of the webcam, the
        server it is attached to, and the last update time.
      
      * Add new sitevars webcam/anyone_can_view and webcam/admins_can_view.
        Should be obvious what they mean.
      
      * Add trivial script grabwebcams (invoked from cron) to grab the images
        from the servers and stash in /usr/testbed/webcams. The images are
        grabbed with scp, protected by a 5 second timeout. Fine for a couple
        of cameras.
      
      * Add web page stuff to display webcams, linked from the robot mape page.
      
      Permission to view the webcams is currently admin, or in a project that is
      allowed to use a robot. We can tighten this up later as needed.
      d46902e1