1. 02 Nov, 2016 1 commit
  2. 14 Oct, 2016 1 commit
    • Leigh Stoller's avatar
      Attempt to address the problem described in issue #166; that nodes fail · 5d7164b3
      Leigh Stoller authored
      to go from PXEBOOTING (pxewakeup) to actually booting, but we do not
      know that for a really long time cause we send a BOOTING event from
      bootinfo right after PXEBOOTING, since that was the only place to hook
      it in. Well Mike discovered the "on commit" support in dhcpd, and so
      that is what we are going to use now. Note that uboot nodes have been
      using on commit, now all nodes will when BOOTINFO_EVENTS=0.
      
      Mike's reportboot program is now a daemon, renamed to report_daemon.
      The original reportboot program is a little script that writes the
      arguments from dhcpd to a unix socket to be picked up by the daemon,
      which does the original work of mapping the IP/Mac to a node id and
      sending an event. The code has also been modified to run on a subboss
      using the same node mapping given to to dhcpd, reconstituted as DBM
      file by subboss_dhcpd_makeconf.
      
      The reason for using a daemon this way is so that we do not hang up
      dhcpd in case we cannot get to the event system. The unix domain
      socket will give us some amount of buffering, but I suspect that any
      event problem will eat that space up quickly, and I will be back to
      revisit this (probably want reportboot to not block on its write
      to the socket).
      
      pxeboot changed to not send PXEBOOTING or BOOTING when
      BOOTINFO_EVENTS=0.
      5d7164b3
  3. 08 Nov, 2012 1 commit
  4. 30 Oct, 2012 2 commits
    • Mike Hibler's avatar
      Doh, forgot to add the fixarpinfo script. · c1a7783a
      Mike Hibler authored
      Also, add verbose mode and log to /var/emulab/logs/fixarpinfo.log so we
      can track what changes.
      c1a7783a
    • 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
  5. 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
  6. 06 Jan, 2012 1 commit
  7. 22 Sep, 2011 1 commit
  8. 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
  9. 15 Apr, 2010 3 commits