1. 13 May, 2010 1 commit
    • Mike Hibler's avatar
      Add site variables to control image creation. · a3f42091
      Mike Hibler authored
      These variables were previously constants hardwired into create_image:
      
      images/create/maxwait:
          Max time (minutes) to allow for saving an image
      images/create/idlewait:
          Max time (minutes) to allow between periods of progress
          (image file getting larger) when saving an image (should be <= maxwait)
      images/create/maxsize:
          Max size (GB) of a created image
      a3f42091
  2. 16 Apr, 2010 1 commit
  3. 15 Apr, 2010 2 commits
  4. 14 Apr, 2010 1 commit
    • Mike Hibler's avatar
      Add some useful elabinelab sitevars. · 9bb38c10
      Mike Hibler authored
      New sitevars:
        elabinelab/singlenet     set the system-wide default for cnet implementation
        elabinelab/boss_osid     default OSID for boss node
        elabinelab/ops_osid      default OSID for ops node
        elabinelab/fs_osid       default OSID for fs node
      
      Also mark the various elabinelab/*pkg* sitevars as deprecated.  Package
      versions are just too dependent on the OS running and we almost always
      wind up overriding these sitevars in rc.mkelab anyway.
      9bb38c10
  5. 06 Apr, 2010 1 commit
  6. 31 Mar, 2010 1 commit
    • Srikanth Chikkulapelly's avatar
      Added 2 sitevar variables that help CM implement policies. · f87e07a3
      Srikanth Chikkulapelly authored
      1) max_ticket_lifetime : It determines how long a sliver can live. Default is set to 90 days.
      2) max_components : It limits the number of components that can be requested/allocated to a user. Default value -1 indicates that there is no limit. any number of components can be requested/allocated.
      f87e07a3
  7. 08 Feb, 2010 1 commit
  8. 02 Nov, 2009 1 commit
  9. 05 Aug, 2009 1 commit
  10. 04 Aug, 2009 2 commits
  11. 30 Jan, 2009 1 commit
  12. 07 Nov, 2008 1 commit
  13. 28 Jul, 2008 1 commit
    • Mike Hibler's avatar
      Update the sitevars. · d85eaf21
      Mike Hibler authored
      Build sitevars-create.sql with "insert ignore"
      
      NOTE: output of "gmake sitevars" must still be tweaked by hand!
      d85eaf21
  14. 17 Jul, 2008 1 commit
  15. 27 Apr, 2006 1 commit
    • Kirk Webb's avatar
      · 296da8ea
      Kirk Webb authored
      Switch around 'value' and 'defaultvalue' fields for "watchdog/rusage" and
      set value field to NULL.
      296da8ea
  16. 01 Mar, 2006 1 commit
    • Kirk Webb's avatar
      · 0314c0ef
      Kirk Webb authored
      Update description and defaults for the watchdog/rusage sitevar
      (now in terms of seconds instead of minutes).
      0314c0ef
  17. 23 Jan, 2006 1 commit
  18. 06 Dec, 2005 1 commit
  19. 29 Nov, 2005 1 commit
  20. 15 Nov, 2005 1 commit
  21. 12 Oct, 2005 1 commit
    • Leigh B. Stoller's avatar
      Add some hacky stuff to allow people in NSDI temporary project to · b538978f
      Leigh B. Stoller authored
      see experiments of other people in the NSDI project.
      
      Added sitevar "general/open_showexplist" which when set to the name of
      a project (NSDI), will allow users in that project to view all the
      experiments that are swapped in by other members of the project, even
      if the experiments are within another project.
      
      Also quickly hacked showuser page to only show project/group listing
      of overlapping projects, not all projects. This avoids some leakage.
      b538978f
  22. 06 Oct, 2005 2 commits
  23. 11 Aug, 2005 1 commit
  24. 22 Jun, 2005 1 commit
    • Leigh B. Stoller's avatar
      Added my simplistic link tracing and monitoring. Example usage and · 7942119e
      Leigh B. Stoller authored
      some details can be found in the advanced tutorial that I wrote up.
      See this link:
      
      http://www.emulab.net/tutorial/docwrapper.php3?docname=advanced.html#Tracing
      
      The basic idea is that each virt_lan entry gets a couple of new slots
      describing the type of tracing that is desired.
      
        traced tinyint(1) default '0',
        trace_type enum('header','packet','monitor') NOT NULL default 'header',
        trace_expr tinytext,
        trace_snaplen int(11) NOT NULL default '0',
        trace_endnode tinyint(1) NOT NULL default '0',
      
      There is a new physical table called "traces" that is a little bit
      like the current delays table. A new tmcd command returns the trace
      configuration to the client nodes (tmcd/common/config/rc.trace).
      
      The delays table got a new boolean called "noshaping" that tells the
      delay node to bridge, but not set up any pipes. This allows us to
      capture traffic at the delay node, but without much less overhead on
      the packets.
      
      The pcapper got bloated up to do packet capture and more event stuff.
      I also had to add some mutex locking around calls into the pcap
      library and around malloc, since the current setup used linuxthreads,
      which is not compatable with the standard libc_r library. I was
      getting all kinds of memory corruption, and I am sure that if someone
      breathes on the pcapper again, it will break in some new way.
      7942119e
  25. 15 Jun, 2005 1 commit
  26. 13 May, 2005 1 commit
    • Leigh B. Stoller's avatar
      Automate initial user/project setup from setup-db.txt. Rather then · dd1b57bc
      Leigh B. Stoller authored
      have the user go through a set of hard to explain steps, just push
      them through it using the web interface.
      
      * New sitevars to control a little state machine used by the web
        interface.
      
      * When first setting up a testbed, the sitevar value will force the
        web interface to present the user with a single menu option "Create
        New Project" and the "Home" link will take the user to that page.
        The user is instructed to login is as elabman.
      
      * The user fills in the form as directed in setup-ops.txt. Even though
        he is logged in as elabman, the newproject form has been altered to
        operate as if no one is logged in. I also default a bunch more of
        the fields in this case.
      
      * The user submits the form. Rather then pend the new project, just
        jump straight into approveproject. That grinds along as usual, and
        when it is done, the elabman account is frozen and the user logged
        out. The user gets a link inviting him to log back in as the user
        just created.
      
      * Side effects of this new process:
      
      	* The user is made an admin user (admin=1) automatically.
      	* The user is added to the emulab-ops project as group_root.
      	* The user verification process is skipped.
      	* The user is added to the unixgroups wheel and tbadmin.
      
      * I reworked this entire section of setup-db.txt ...
      
      * The user still needs to give himself a real shell and password on
        boss, but I left that for the user to do explicitly. I also drop in
        a pointer to the shellonboss.txt. I might automate this part too at
        some point. Not sure yet.
      dd1b57bc
  27. 06 May, 2005 1 commit
  28. 04 Feb, 2005 1 commit
  29. 27 Jan, 2005 1 commit
  30. 26 Jan, 2005 1 commit
    • Leigh B. Stoller's avatar
      The Robot Lab Monitor Daemon. A very silly script that looks at some · 4963660a
      Leigh B. Stoller authored
      sitevars to determine if the Robot Lab is open or closed. The sitevars:
      
      * 'robotlab/override' - Override other settings and forcibly turn the lab
        "on" or "off" (open or close). When the lab is turned off, new
        experiments cannot swap in and the current experiment is immediately
        swapped out.
      
      * 'robotlab/exclusive' - The robot lab is exclusive use. Best to not mess
        with this sitevar :-)
      
      * 'robotlab/opentime' - The time that the robot lab opens in the
        morning. The default is 07:00, but feel free to change this as you like.
      
      * 'robotlab/closetime' - The time that the robot lab closes in the
        evening. The default is 18:00, but feel free to change this as you like.
      
      * 'robotlab/open' - The robot lab is open or closed. DO NOT MESS WITH THIS!
        It is updated by the robomonitord script and intended to be used by
        admission control (not done yet).
      
      The robomonitord script runs and periodically (every 2 minutes) wakes up
      and looks at the various sitevars above. The lab is open during the day,
      Monday through Friday, and closed on weekends. It is also supposed to be
      closed on holidays, but I have not added that yet.
      
      15 minutes before the lab is to be closed, a warning message is sent to the
      swapper of the experiment running on the robot testbed, that their
      experiment is going to be swapped soon. When the Robot lab is closed
      (either cause the close time was reached, or because the lab was forcibly
      closed with the override), the current experiment is immediately swapped
      out.
      
      I know, this is hopelessly bogus, but it will do until we feel like adding
      a "Lab" datatype to the system.
      4963660a
  31. 18 Jan, 2005 1 commit
    • Leigh B. Stoller's avatar
      Here is a checkpoint of the admission control stuff I have been working on. · 54f55585
      Leigh B. Stoller authored
      The last part is the stuff to hook it in from assign_wrapper, and some
      additional support in assign that Rob is adding for me. This comment is
      from the top of new file db/libadminctrl.pm.in and describes everything in
      detail.
      
      # Admission control policies. These are the ones I could think of, although
      # not all of these are implemented.
      #
      #  * Number of experiments per type/class (only one expt using robots).
      #
      #  * Number of experiments per project
      #  * Number of experiments per subgroup
      #  * Number of experiments per user
      #
      #  * Number of nodes per project      (nodes really means pc testnodes)
      #  * Number of nodes per subgroup
      #  * Number of nodes per user
      #
      #  * Number of nodes of a class per project
      #  * Number of nodes of a class per group
      #  * Number of nodes of a class per user
      #
      #  * Number of nodes of a type per project
      #  * Number of nodes of a type per group
      #  * Number of nodes of a type per user
      #
      #  * Number of nodes with attribute(s) per project
      #  * Number of nodes with attribute(s) per group
      #  * Number of nodes with attribute(s) per user
      #
      # So we have group (pid/gid) policies and user policies. These are stored
      # into two different tables, group_policies and user_policies, indexed in
      # the obvious manner. Each row of the table defines a count (experiments,
      # nodes, etc) and a type of thing being counted (experiments, nodes, types,
      # classes, etc). When we test for admission, we look for each matching row
      # and test each condition. All conditions must pass. No conditions means a
      # pass. There is also some "auxdata" which holds extra information needed
      # for the policy (say, the type of node being restricted).
      #
      #      uid:     a uid
      #   policy:     'experiments', 'nodes', 'type', 'class', 'attribute'
      #    count:     a number
      #  auxdata:     a string (optional)
      #
      # Example: A user policy of ('mike', 'nodes', 10) says that poor mike is
      # not allowed to have more 10 nodes at a time, while ('mike', 'type',
      # '10', 'pc850') says that mike cannot allocate more than 10 pc850s.
      #
      # The group_policies table:
      #
      #      pid:     a pid
      #      gid:     a gid
      #   policy:     'experiments', 'nodes', 'type', 'class', 'attribute'
      #    count:     a number
      #  auxdata:     a string (optional)
      #
      # Example: A project policy of ('testbed', 'testbed', 'experiments', 10)
      # says that the testbed project may not have more then 10 experiments
      # swapped in at a time, while ('testbed', 'TG1', 'nodes', 10) says that the
      # TG1 subgroup of the testbed project may not use more than 10 nodes at
      # time.
      #
      # In addition to group and user policies (which are policies that apply to
      # specific users/projects/subgroups), we also need policies that apply to
      # all users/projects/subgroups (ie: do not want to specify a particular
      # restriction for every user!). To indicate such a policy, we use a special
      # tag in the tables (for the user or pid/gid):
      #
      #      '+'  -  The policy applies to all users (or project/groups).
      #
      # Example: ('+','experiments',10) says that no user may have more then 10
      # experiments swapped in at a time. The rule overrides anything more
      # specific (say a particular user is restricted to 20 experiments; the above
      # rule overrides that and the user (all users) is restricted to 10.
      #
      # Sometimes, you want one of these special rules to apply to everyone, but
      # *allow* it to be overridden by a more specific rule. For that we use:
      #
      #      '-'  -  The policy applies to all users (or project/groups),
      #              but can be overridden by a more specific rule.
      #
      # Example: The rules:
      #
      #	('-','type',0, 'garcia')
      #       ('testbed', 'testbed', 'type', 10, 'garcia')
      #
      # says that no one is allowed to allocate garcias, unless there is specific
      # rule that allows it; in this case the testbed project can allocate them.
      #
      # There are other global policies we would like to enforce. For example,
      # "only one experiment can be using the robot testbed." Encoding this kind
      # of policy is harder, and leads down a path that can get arbitrarily
      # complex. Tha path leads to ruination, and so we want to avoid it at
      # all costs.
      #
      # Instead we define a simple global policies table that applies to all
      # experiments currently active on the testbed:
      #
      #   policy:     'nodes', 'type', 'class', 'attribute'
      #     test:     'max', others I cannot think of right now ...
      #    count:     a number
      #  auxdata:     a string
      #
      # Example: A global policy of ('nodes', 'max', 10, '') say that the maximum
      # number of nodes that may be allocated across the testbed is 10. Thats not
      # a very realistic policy of course, but ('type', 'max', 1, 'garcia') says
      # that a max of one garcia can be allocated across the testbed, which
      # effectively means only one experiment will be able to use them at once.
      # This is of course very weak, but I want to step back and give it some
      # more thought before I redo this part.
      #
      # Is that clear? Hope so, cause it gets more complicated. Some admission
      # control tests can be done early in the swap phase, before we really do
      # anything (before assign_wrapper). Others (type and class) tests cannot
      # be done here; only assign can figure out how an experiment is going to map
      # to physical nodes (remember virtual types too), and in that case we need
      # to tell assign what the "constraints" are and let it figure out what is
      # possible.
      #
      # So, in addition to the simple checks we can do, we also generate an array
      # to return to assign_wrapper with the maximum counts of each node type and
      # class that is limited by the policies. assign_wrapper will dump those
      # values into the ptop file so that assign can enforce those maximum values
      # regardless of what hardware is actually available to use. As per discussion
      # with Rob, that will look like:
      #
      #	set-type-limit <type> <limit>
      #
      # and assign will spit out a new type of violation that assign_wrapper will
      # parse.
      #
      # NOTES:
      #
      #  1) Admission control is skipped in admin mode; returns okay.
      #  2) Admission control is skipped when the pid is emulab-ops; returns okay.
      #  3) When calculating current usage, nodes reserved to emulab-ops are
      #     ignored.
      #  4) The sitevar "swap/use_admission_control" controls the use of admission
      #     control; defaults to 1 (on).
      #  5) The current policies can be viewed in the web interface. See
      #     https://www.emulab.net/showpolicies.php3
      #  6) The global policy stuff is weak. I plan to step back and think about it
      #     some more before redoing it, but it will tide us over for now.
      #
      54f55585
  32. 10 Jan, 2005 1 commit
    • Leigh B. Stoller's avatar
      A quick hack job to get the webcams onto the web interface. · d46902e1
      Leigh B. 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
  33. 03 Jan, 2005 2 commits
  34. 22 Dec, 2004 1 commit
  35. 05 Oct, 2004 1 commit
  36. 22 Sep, 2004 1 commit
    • Kirk Webb's avatar
      · e5b8b23a
      Kirk Webb authored
      Made the message at the top of the plab_ez page a site var.
      e5b8b23a