1. 02 Nov, 2012 5 commits
  2. 30 Oct, 2012 6 commits
    • Kirk Webb's avatar
      Shuffle some commands around. · 76c6b57d
      Kirk Webb authored
      Put fix up some ordering and change variable definitions a bit to be more
      amenable to autoconf.
    • Kirk Webb's avatar
      Add some WIP comments. · 635bcc77
      Kirk Webb authored
    • Mike Hibler's avatar
      Allow uppercase hex-digits in MAC addresses. · c69b02d1
      Mike Hibler authored
    • 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
      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.
    • Mike Hibler's avatar
    • Mike Hibler's avatar
  3. 29 Oct, 2012 3 commits
  4. 26 Oct, 2012 2 commits
  5. 25 Oct, 2012 1 commit
  6. 24 Oct, 2012 5 commits
  7. 17 Oct, 2012 1 commit
  8. 11 Oct, 2012 1 commit
  9. 10 Oct, 2012 2 commits
    • Leigh B Stoller's avatar
      Brutalize to use ipfw command line interface when > FreeBSD 8. · 1529f157
      Leigh B Stoller authored
      The socket interface changed and rather rewrite this client or try to
      figure out how to finish the "new" client, I whacked the crap out of
      this to use ipfw. This is of course more fragile since it depends on
      the input language of ipfw, and the especially the output from ipfw to
      determine the current settings. When upgrading, we must be sure to
      test this.
    • Mike Hibler's avatar
      Deal with some DHCP issues related to the nfe driver for Nvidia NICs. · 6904db1d
      Mike Hibler authored
      The Nvidia NICs on the PRObE machines will occassionally hang when dhclient
      is running. Gary Sandine came up with a work-around to keep things moving.
      This is my "re-interpretation" of his fix (i.e., if it doesn't work, don't
      blame him!)
  10. 07 Oct, 2012 2 commits
  11. 03 Oct, 2012 6 commits
  12. 02 Oct, 2012 4 commits
  13. 01 Oct, 2012 2 commits
    • Kirk Webb's avatar
      Setup EDSL can now add users and make them admin. Tweak actions. · 1092fadb
      Kirk Webb authored
      The Win7 setup EDSL can now add users and make them members of the
      Administrators group.  Tweaked the action files to create local root
      account, and introduced more constant definitions.
    • Kirk Webb's avatar
      Teach the Windows setup EDSL some new tricks. · 6628ade3
      Kirk Webb authored
      The setup EDSL can now edit and append to files.  It can also modify the
      system path environment variable.
      Unfortunately, since powershell really wants to use Windows line endings,
      the file editing stuff is currently only useful for Windows-style text