1. 27 Feb, 2013 1 commit
  2. 14 Feb, 2013 1 commit
  3. 05 Feb, 2013 1 commit
    • Kirk Webb's avatar
      Move storageconfig fetch/parse code to libsetup. · 53813c8e
      Kirk Webb authored
      Create "getstorageconfig" call in libsetup, following the tradition with
      other tmcc information fetching routines.  It's guts were yanked out of
      rc.storage.
      
      Outside of calling the moved code from libsetup, rc.storage was also
      changed slightly to store the returned information using "Storable"
      since it's now dealing with an array of hashes instead of raw lines
      of output from tmcc.
      53813c8e
  4. 12 Dec, 2012 1 commit
  5. 30 Nov, 2012 1 commit
    • Mike Hibler's avatar
      Plumb through an fs-install makefile target and fixes to ops-install. · 3cd66d51
      Mike Hibler authored
      This officially drops the pretense that fs nodes can operate with minimal
      Emulab software. If you have a seperate fs node, it had better be dedicated
      to Emulab!
      
      However, it still doesn't do everything. In particular, accounts are not
      installed. This has never been needed for serving NFS, but is needed for
      the samba stuff to work correctly.
      
      Also, you cannot do an fs node software install from boss yet as we do not
      mount fs filesystems on boss. You really cannot do a full ops install from
      boss either since we don't mount ops' /usr/local/etc/emulab directory.
      3cd66d51
  6. 14 Nov, 2012 1 commit
    • Mike Hibler's avatar
      Client half of the fetch-tarballs-via-the-web change. · 763c6aca
      Mike Hibler authored
      For every tarball and rpm, tmcd will now pass a SERVER= string as well
      telling the client where the file should be downloaded from (if using
      the web rather than NFS). Right now this value is the same for all
      tarballs and rpms, and is hardwired in tmcd as either "www" (if
      SPEWFROMOPS=0) or "users" (if 1). Note: BUMPED THE TMCC VERSION NUMBER
      for this.
      
      Made a common routine for doing an error-check-and-retry copy of a file
      across "racy" NFS. This is used by install-{tarfile,rpm} and rc.topomap.
      763c6aca
  7. 06 Nov, 2012 1 commit
  8. 30 Oct, 2012 2 commits
    • Mike Hibler's avatar
      Allow uppercase hex-digits in MAC addresses. · c69b02d1
      Mike Hibler authored
      c69b02d1
    • Mike Hibler's avatar
      Remaining infrastructure for control network "ARP lockdown". · 4b5e17b0
      Mike Hibler authored
      It works like this. Certain nodes that are on the node control net
      (right now just subbosses, but ops coming soon) can set static ARP entries
      for the nodes they serve. This raises the bar for (but does not eliminate
      the possibility of) nodes spoofing servers. Currently this is only for
      FreeBSD.
      
      When such a server boots, it will early on run /etc/rc.d/arplock.sh
      which will in turn run /usr/local/etc/emulab/fixarpinfo. fixarpinfo
      asks boss via an SSL tmcc call for "arpinfo" (using SSL ensures that the
      info coming back is really from boss). Tmcd on boss returns such arpinfo
      as appropriate for the node (subboss, ops, fs, etc.) along with the type
      of lockdown being done. The script uses this info to update the ARP
      cache on the machine, adding, removing, or making permanent entries
      as appropriate.
      
      fixarpinfo is intended to be called not just at boot, but also whenever
      we might need to update the ARP info on a server. The only other use right
      now is in subboss_dhcpd_makeconf which is called whenever DHCP info may
      need to be changed on a subboss (we hook this because a call to this script
      might also indicate a change in the set of nodes served by the subboss).
      In the future, fixarpinfo might be called from the newnode path (for ops/fs,
      when a node is added to the testbed), the deletenode path, or maybe from
      the watchdog (if we started locking down arp entries on experiment nodes)
      
      The type of the lockdown is controlled by a sitevar on boss,
      general/arplockdown, which can be set to 'none', 'static' or 'staticonly'.
      'none' means do nothing, 'static' means just create static arp entries
      for the given nodes but continue to dynamically arp for others, and
      'staticonly' means use only this set of static arp entries and disable
      dynamic arp on the control net interface. The last implies that the server
      will only be able to talk to the set of nodes for which it got ARP info.
      
      As mentioned, tmcd is responsible for returning the correct set of arp
      info for a given request. The logic currently is:
      
       * Only return ARP info to nodes which are on the CONTROL_NETWORK.
         If the requester is elsewhere (e.g., Utah's boss and ops are currently
         segregated on different IP subnets) then this whole infrastructure
         does not apply and nothing is returned.
      
       * If the requester is a subboss, return info for all other servers that
         are on the node control network as well as for the set of nodes
         which the subboss serves.
      
       * If the requester is an ops or fs node, again return info for all
         other servers and info for all testnodes or virtnodes whose control
         net IP is on the node control net.
      
       * Otherwise, return nothing.
      
      One final note is that the ARP info for servers such as boss/ops/fs or
      the gateway router is not readily available in most Emulab instances
      since those machines are not in the DB nodes or interfaces tables.
      Eventually we will fix that, but for now the info must come from new
      site variables. To help initially populate those variables, I added
      the utils/update_sitevars script which attempts to determine which
      servers are on the node control net and gathers the appropriate IP and
      MAC info from them.
      4b5e17b0
  9. 29 Oct, 2012 2 commits
  10. 25 Sep, 2012 1 commit
  11. 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
  12. 12 Sep, 2012 1 commit
  13. 29 May, 2012 1 commit
  14. 22 May, 2012 1 commit
  15. 14 Mar, 2012 1 commit
    • 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
  16. 20 Jan, 2012 1 commit
  17. 17 Jan, 2012 1 commit
  18. 12 Jan, 2012 1 commit
    • Ryan Jackson's avatar
      Initial client code and rules for Linux firewalls · 2690be45
      Ryan Jackson authored
      Made the following changes to the clientside code to support Linux
      firewalls:
      
      - Made os_fwconfig_line() actually do something.
      - getfwconfig() adds an 'IPS' hash to the fwinfo hash.  This contains
        the IP address for each host, much like how the 'MACS' hash contains
        the MAC address for each host.  This is needed because ebtables (which
        is needed for ARP proxying) doesn't resolve hostnames.
      
      Rules are stored in firewall/iptables-fw-rules.  Syntax is similar to
      fw-rules, but without the rule number (since iptables doesn't use rule
      numbers).  These should be equivalent to our ipfw-based rules, but I
      haven't tested every case yet to confirm this.  I'm sure some changes
      will be necessary.
      2690be45
  19. 04 Jan, 2012 2 commits
  20. 13 Dec, 2011 1 commit
  21. 28 Nov, 2011 1 commit
    • David Johnson's avatar
      Add build_fake_macs and use it in getifconfig. · fe6c2807
      David Johnson authored
      build_fake_macs generates fake mac addresses for the inside and outside
      halves of a veth.  For openvz vnodes, we have to uniquely address
      both halves.  tmcd gives us the vmac for the inside of the container;
      it is basically 00:00:ipOct0:ipOct1:ipOct2:ip0ct3.  Normally, for openvz
      veths, this works fine, because only the inside of the container ever sees
      the vmac.  BUT, if we're not using openvz veths (i.e., using macvlan devices),
      we might not have inside/outside halves of the veth.  Consequently, we
      have to give the device a unique mac addr that is unique in both the
      root and container contexts.  This is trivial for non-shared vhosts, but
      if the vhost is shared, we can't just use the vmac as specified above.  So,
      we do the following:
      
          # We have to set the locally administered bit (0x02) in the first
          # octet, and we can't set the unicast/multicast bit (0x01).  So
          # we have the first two octets to play with, minus those two bits,
          # leaving us with 14 total bits.  But then, for veths, we need a
          # a MAC for the root context, and for the container.  So there goes
          # another bit.
          #
          # So, what we're going to do is, if the vmid fits in 13 bits,
          # take the 5 MSB and shift them into bits 3-7 of the first octet,
          # and take the 8 LSB and make them the second octet.  Then, we
          # always set bit 2, and the container MAC gets bit 8 set.
      
      Of course, this requires getifconfig to check for these "hacked" vmacs
      when ifsetup configures interfaces inside the container -- so now
      getifconfig checks for these special hacked vmacs if it can't find
      a device with the vmac itself.  Good times...
      fe6c2807
  22. 19 Nov, 2011 1 commit
  23. 17 Nov, 2011 1 commit
  24. 15 Nov, 2011 1 commit
    • Mike Hibler's avatar
      Further overhaul of firewall code. NOTE: required bump of tmcd version to 34. · 6a26b246
      Mike Hibler authored
      Firewalls now work with nodes which require a subboss. Had to introduce new
      firewall rules which skipped around the checks that no packets to/from
      node control net IPs should pass through the firewall, if the IP in question
      belongs to a subboss (since subboss is on the node control network). It
      actually checks for all Emulab servers (boss, ops, fs or any subboss),
      so the code should work for an Emulab install which has a non-segmented
      control network in which all servers were in the same subnet as the nodes.
      
      In addition to the new rules, we also had to pass in additional information
      via "tmcc firewallinfo" giving the IP/MAC of those server nodes that are on
      the node control network. We use this to establish ARP entries on the
      inside network so that nodes can find the servers. Since the existing
      client-side firewall code in libsetup.pm would blow up if it got a line
      that it didn't recognize, I had to bump the tmcd version number and add
      some conditional code to tmcd.c:dofwinfo() to not return the extra info for
      old versions.
      
      Added a couple of new firewall variables EMULAB_BOSSES and EMULAB_SERVERS
      that are used in the new rules. Fixed the support scripts in firewall/
      to properly initialize these variables.
      
      IMPORTANT: tmcd looks up boss, ops, fs, and subbosses in the interfaces
      table to find their IPs and MAC addresses. By default, we do not create
      such interface table entries for boss/ops/fs. We have them at Utah for
      other reasons. These entries are only needed if you have a non-segmented
      control network (or a subboss) and you want to firewall such nodes.
      The script to initialize the firewall variables (initfwvars.pl) will
      print out a warning for configurations that are affected and don't have
      the entries.
      6a26b246
  25. 21 Jul, 2011 1 commit
  26. 29 Jun, 2011 1 commit
    • Mike Hibler's avatar
      Allow for more flexible setup of pxe_boot_path. · 2abf13da
      Mike Hibler authored
      If nodes.pxe_boot_path is set to '/tftpboot/pxelinux/<something>', then
      dhcpd_makeconf will set the (pxeboot) filename to /tftpboot/pxelinux.0
      and symlink the node's config file (/tftpboot/pxelinux.cfg/<mac>) to
      /tftpboot/pxelinux.cfg/<something>.
      
      In other words, we can customize pxelinux to some small degree, using one
      of some small number of pre-existing configurations. We were using pxelinux
      before for plab-in-elab and we will also need it for loading WinPE for
      configuring Windows7 images. For the latter we will set the pxe_boot_path
      to /tftpboot/pxelinux/winpe.
      
      Anyway, ideally we would allow the user to specify a pxelinux config file
      through the NS file, but need to think about the implications of that some
      more. Small steps...
      2abf13da
  27. 02 May, 2011 1 commit
  28. 25 Apr, 2011 1 commit
    • Mike Hibler's avatar
      Hopefully short-term fix to allow more general mixing of pnodes and vnodes. · bf0c2929
      Mike Hibler authored
      The current state of affairs is that you can only set the "link emulation"
      style at the experiment level, and that forces link emulation on physical
      nodes as well as virtual nodes. Thus you are forced into using either 802.11
      tagged vlan emulation or an OS that supports something called "veths" on
      physical nodes.
      
      From the comment:
      
         This is a very, very, very special case. If a non-encapsulating veth
         interface (veth-ne) maps 1-to-1 with an underlying physical interface,
         we want to just use the physical interface instead. This allows OSes
         (on physical nodes) which don't support a veth device (i.e., most of
         them) to talk to vnodes which are using veth-ne style.
      
         This can go away once we have separated the notion of multiplexing
         links from encapsulating links (a historical conflation) so that we
         don't have to force virtual devices onto physical nodes just because
         some virtual nodes in the same experiment require multiplexed links.
      bf0c2929
  29. 11 Apr, 2011 1 commit
  30. 03 Apr, 2011 1 commit
  31. 01 Feb, 2011 1 commit
    • Mike Hibler's avatar
      Implement limited backward compatibility with the old frisbee setup. · 1017ccce
      Mike Hibler authored
      The big backward compatibility issue is that we no longer store running
      frisbeed info in the DB.  This means that loadinfo could not return
      address:port info to clients and thus old frisbee MFSes could no longer
      work.  While not a show stopper to require people to update their MFS first,
      I made a token effort to implement backward compat as follows.
      
      When an old frisbee MFS does "tmcc loadinfo" (as identified by a tmcd
      version < 33), tmcd will invoke "frisbeehelper" to startup a daemon.
      Sound like frisbeelauncher?  Well sorta, but vastly simplified and I only
      want this to be temporary.  The helper just uses the frisbee client to make
      a "proxy" request to the localhost master server.  The Emulab configuration
      of the master server now allows requests from localhost to proxy for another
      node.
      
      frisbeehelper is also used by webfrisbeekiller to kill a running daemon
      (yes, just like frisbeelauncher).  It makes a proxy status request on
      localhost and uses the returned info to identify the particular instance
      and kill it.
      1017ccce
  32. 07 Dec, 2010 1 commit
  33. 20 Oct, 2010 1 commit
    • Mike Hibler's avatar
      Support for no shared filesystem (unsupport for shared filesystem?) and · c1c1bce2
      Mike Hibler authored
      (eventual) support for NFS servers without race conditions!
      
      This means no NFS between nodes and ops/fs. There are still NFS mounts of
      ops on boss however.
      
      Added new defs-* variable NOSHAREDFS, which when set non-zero will disable
      the export of NFS filesystems to nodes.  Involved lots of little changes:
      
       * /users, /proj, and /share filesystems are not exported to nodes.
      
       * Returned mount info now includes an FSTYPE key which will be set to "LOCAL"
         if NOSHAREDFS is in effect (by default it is set to "NFS-RACY"; more on
         this later).  In the case where it is set to LOCAL, the other mount lines
         no longer contain REMOTE=foo settings.  Because of this change,
         THE TMCD VERSION NUMBER HAS BEEN BUMPED TO 32.
      
       * The client rc.mounts script will now create local versions of /users/*,
         /proj/<pid>, and /share when FSTYPE=LOCAL.  It first runs mkextrafs to
         create a large partition for these, since someday we will likely want
         to pre-populate these with a non-trivial amount of data.  Right now,
         the only thing that is put in the user's homedir is the standard dotfiles
         for the OS and the Emulab authorized_keys file (so you can login).
      
       * Linktest had to be modified to fetch the various results files (via
         loghole) rather than just assuming they were in /proj.  And also changed
         to invoke tevc with the local copy of the event key so it won't try to
         read it over NFS.
      
       * create_image was modified to ssh to the node and run the imagezip
         command, capturing the output of ssh.  This is controlled via the "-s"
         option which defaults to on for a NOSHAREDFS system, but can also be
         used on a normal system.
      
       * elabinelab's can be configured with/without a shared FS via the
         CONFIG_SHAREDFS attribute (note polarity change) which defaults to 1.
      
      Another new defs-* variable, NFSRACY, will some day allow you to specify
      (by setting to 0) that your NFS server does NOT have the nefarious mountd
      race condition when changing /etc/exports.  Currently, this defaults to 1
      since all versions of FreeBSD supported as an "fs" node have this "feature."
      Rumor has it that FreeBSD 8 does not have this problem nor, presumably,
      would a Linux NFS server.
      
      The only use of this variable right now is to set the FSTYPE returned by the
      tmcd "mounts" call, which in turn is used by one client script, rc.topomap
      (via a libsetup function) to determine whether it should try copying
      the topo file multiple times.
      
      Random: add python2.6 to list of python's checked for in configure.
      Random: resync defs-example-privatecnet with defs-example.
      Random: did a little code-pissin here and there.
      c1c1bce2
  34. 29 Sep, 2010 1 commit
  35. 25 May, 2010 2 commits
  36. 15 Apr, 2010 1 commit