1. 17 Apr, 2012 1 commit
  2. 11 Apr, 2012 1 commit
    • Leigh B Stoller's avatar
      So this commit allows a vlan to be "shared" bewteen experiments. By · dae29101
      Leigh B Stoller authored
      shared, I mean that an experiment can request that a port be put into
      a vlan belonging to another experiment. This started out as a hack to
      support openflow enabled vlans in Geni, but then I got a request to
      make it a little more general purpose. You all know how that goes.
      
      Okay, say you have an experiment E1 in some project and that
      experiment has a link or lan call "lan0". You want other experiments
      to be able to stick ports in that vlan. On boss, you would do this
      after E1 is swapped in:
      
      boss> wap sharevlan -o testbed,E1 lan0 mysharedlan
      
      The -o option says to make the vlan open to anyone; without that
      option, only admins can swap in an experiment that requests a port in
      lan0.  The token "mysharedlan" is just a level of indirection for the
      NS file (or rspec).
      
      Next you create a new experiment E2, and in your NS file:
      
      	$ns make-portinvlan $n1 "mysharedlan"
      
      which says to create a lan with a interface on node n1, in the vlan
      named by the token mysharedlan. The token keeps specific pid/eids out
      of the NS file. 
      
      When E2 is swapped in, assign does its thing, and the selected port is
      added to the members list for lan0 in testbed,E1 and then we call
      snmpit with the syncvlansfromtables (-X) option to get the port added.
      
      When E2 is swapped out, we undo the members list and call snmpit with
      the -X option again.
      
      The access issue is a bit of hack of course (open or admins) but I did
      not want to invent a new permission mechanism (yet).
      
      And of course, this is still a work in progress.
      dae29101
  3. 04 Apr, 2012 2 commits
  4. 27 Mar, 2012 1 commit
    • Leigh B Stoller's avatar
      Bunch of changes for "management" interfaces (ilo,drac,etc); make · 85b81867
      Leigh B Stoller authored
      management interfaces more of a first class citizen instead of a
      hack. New script:
      
      management_iface -t <type> -a [key|pswd] [-s <switchinfo>]
                              <node_id> mac IP arg1 arg2
      management_iface -r <node_id>
        -h       This message
        -t type  Management type; ilo, ilo2, drac
        -s info  Optional switch info; switch,card,port
        -s -     Search output of switchmac to find switch info
        -a pswd  Password auth; provide login and password.
        -a key   SSH key auth; provide login and key path.
        -r       Remove management interface from DB.
      
      which adds the management interface to the database (interfaces,
      outlets and outlets_remoteauth. Optionally adds the wires table
      entry if you add -s option. Uses switchmac to find the switch info or
      you can specify it on the command line. So for example, here is what I
      did to add the ilo2 interface for a node:
      
      management_iface -t ilo2 -a pswd -s - pc1 e8:39:35:ae:c9:7c \
                       155.98.34.100 elabman mypasswd
      or
      management_iface -t ilo2 -a key -s - pc1 e8:39:35:ae:c9:7c \
                       155.98.34.100 elabman /root/.ssh/somekey
      
      Of course someone had to have added the elabman user and key or
      password to the ilo config via its interface. 
      
      * dhcpd_makeconf will add local node management interfaces to the
        config file. We can set them to dhcp instead of hardwiring the IP in
        the management interface.
      
      * The DB changes add a management type to the enums in the interfaces
        and wires table, and updates the existing interface entries.
      85b81867
  5. 16 Mar, 2012 1 commit
  6. 15 Mar, 2012 1 commit
  7. 14 Mar, 2012 3 commits
    • Mike Hibler's avatar
      Minor syntax error in update script. · ceaa2539
      Mike Hibler authored
      ceaa2539
    • Mike Hibler's avatar
      Make the secure boot path work with PXEWAIT. · ceeede28
      Mike Hibler authored
      When a node with the secure boot dongle is freed, it goes into PXEWAIT in
      the context of the secure MFS. Previously we remained in "secure mode"
      (i.e., did not terminate with a TPMSIGNOFF) while a node was in this state.
      If the next use of the node, just booted from the OS that was already on
      the disk, then we never signed off properly.
      
      Now we sign off before entering PXEWAIT. I thought that this would be the
      easiest alternative to fixing the problem..HaHaHa..not! Because now we have
      to restart the secure boot path (i.e., reboot) if the result of coming out
      of PXEWAIT is a request to reload the disk (i.e., if we are continuing the
      secure disk load path).
      
      Ideally this would have required only modifications to the state machines
      for SECUREBOOT/LOAD, but as you can see by the presence of stated.in in the
      modified files, this was not the case. The change required some additional
      "finesse" to get it working. See the comments in stated.in and bootinfo_mysql.c
      if you really care.
      ceeede28
    • Mike Hibler's avatar
      Pass through bootinfo flags on tmcc "bootwhat" command. · 3ca3abf6
      Mike Hibler authored
      bootwhat will now return a FLAGS=%d value corresponding to the flags
      field in the boot_what struct.
      
      NOTE: THIS REQUIRED A TMCD VERSION BUMP. We are now at version 35.
      The issue was backward compatibility with existing CD/dongle boot images
      which are overly strict in their parsing of the returned bootwhat values.
      
      Added a new boot_what flag (the whole point of this) to signify if the
      entity being returned is part of the "secure boot" path. This is used
      by the gPXE dongle to determine whether it needs to do a trusted boot
      path "sign-off" for the MFS it downloads. We used to use the name of
      the MFS as our heuristic for this.
      
      bootinfo uses the new tbdb.os_info osfeature "ontrustedboot" to determine
      whether to set the flag.
      3ca3abf6
  8. 08 Mar, 2012 1 commit
  9. 29 Feb, 2012 1 commit
    • Leigh B Stoller's avatar
      Improve cross referencing between geni-cm and emulab datbases. · f1a659b8
      Leigh B Stoller authored
      Add a datetime form to the shownodehistory we page so that a testbed
      admin can plug in a specific date, and find out what that node was
      doing at the time. Changes in the backend (node_history script) to
      support this. Note that the table is hard to seach for such a case,
      and so need to let node_history do its thing and then port process the
      records list. Unfortunately, the timestamps are unsigned ints, but
      perl does not handle those properly, so had to pull in Math::BigInt to
      deal with it.
      
      On the output page, include a link to the genihistory page if a node
      was part of a slice.
      
      On the genihistory page, add a new argument, slice_uuid, to look for
      the records for a specific slice.
      f1a659b8
  10. 10 Feb, 2012 1 commit
  11. 02 Feb, 2012 1 commit
    • Leigh B Stoller's avatar
      Add a couple of changes for the GPO. · cfbcf2c4
      Leigh B Stoller authored
      1. Change default slice expiration to a new site variable called
         protogeni/default_slice_lifetime, defaults to six hours.
      
      2. Add a site variable (protogeni/warn_short_slices) to tell the
         sa_daemon if it should send email to war about short lived slices
         expiring, defaults to off.
      cfbcf2c4
  12. 30 Jan, 2012 2 commits
  13. 23 Jan, 2012 2 commits
    • Leigh B Stoller's avatar
      Minor fix. · 9e58c964
      Leigh B Stoller authored
      9e58c964
    • Leigh B Stoller's avatar
      Add support for disk agents. This is just the plumbing, Yathindra is · 95ada2d1
      Leigh B Stoller authored
      doing the real/hard work. Anyway, in your NS file you can do this:
      
      	set newdisk [new Disk $ns]
      	$newdisk set node $n0
      	$newdisk set type foo
      	$newdisk set mountpoint /qq
      	$newdisk set parameters "foo bar fee"
      	$newdisk set command "bla bla bla"
      
      The parameters and command are optional and default to null. Then on
      your node, tmcd returns:
      
      	DISK DISKNAME=newdisk DISKTYPE='foo' MOUNTPOINT='/qq' MOUNTPOINT='foo bar fee' PARAMETERS='bla bla bla'
      
      Note that there is no client support code in this commit.
      95ada2d1
  14. 19 Jan, 2012 1 commit
  15. 13 Jan, 2012 1 commit
  16. 12 Jan, 2012 2 commits
  17. 11 Jan, 2012 5 commits
  18. 02 Dec, 2011 2 commits
  19. 29 Nov, 2011 1 commit
  20. 07 Nov, 2011 1 commit
  21. 11 Oct, 2011 1 commit
    • Leigh B Stoller's avatar
      More work on image permissions; allow specification of pid/osname in · cfc9612a
      Leigh B Stoller authored
      NS files. Tweak permission check in Geni CM to also allow this,
      although at this time only global images from any project are allowed.
      The virt_nodes table has been changed to accommodate pid/osname
      syntax:
      
      	tb-set-node-os $nodeA somepid/someos
      
      Note: we are really exporting permission to use images, not entries in
      the os_info table (OSIDs) which is what the NS parser and protogeni CM
      are using. But in fact, an image is both an image descriptor and an OS
      descriptor linked together, so if you export an image or make it
      global, you are implicitly doing the same for the OS descriptor. As
      mentioned many times in the past, OSIDs suck.
      cfc9612a
  22. 10 Oct, 2011 1 commit
    • Leigh B Stoller's avatar
      Add support for sharing images between projects. New table called · 646b64f6
      Leigh B Stoller authored
      image_permissions stores access info for images. You can share an
      image with a user or a group (project), and you can specify write
      access to allow updating the image in place. Note that write access
      does not allow the descriptor to be modified, only the image itself.
      Well, that is how it will be after Mike changes mfrisbeed.
      
      The front end script to modify permissions is grantimage:
      
      	boss> grantimage -u stoller -w tbres,myimage
      	boss> grantimage -u stoller -w tbres,myimage
      
      which grants write access to stoller. Or:
      
      	boss> grantimage -g testbed,testbed tbres,myimage
      
      which grants access to the testbed project. Notice that you can
      specify subgroups this way.
      
      	boss> grantimage -l tbres,myimage
      
      will give you a list of current permissions. To revoke, just add -r
      option:
      
      	boss> grantimage -g testbed,testbed -r tbres,myimage
      
      Who is allowed to grant access to an image? 1) An adminstrator of
      course, 2) the image creator, and 3) any group_root in the group that
      the image belongs to. Being granted access to use an image does not
      confer permission to grant access to others.
      
      One last task; while the web interface displays the permissions, there
      is no web interface to modify the permissions; users will still have
      to ask us for now.
      646b64f6
  23. 04 Oct, 2011 1 commit
  24. 28 Sep, 2011 1 commit
  25. 14 Sep, 2011 1 commit
  26. 02 Sep, 2011 1 commit
  27. 01 Sep, 2011 1 commit
  28. 30 Aug, 2011 2 commits