1. 14 Oct, 2016 6 commits
    • 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
    • Leigh Stoller's avatar
      Install the event perl modules on subboss. Add MarkDaemon ultilties · fb247a24
      Leigh Stoller authored
      from boss libtestbed,pm into clientside version of same file.
    • Leigh Stoller's avatar
    • Leigh Stoller's avatar
    • Leigh Stoller's avatar
      Couple of tiny fixes that I made while stumbling around on a question · ae70d47f
      Leigh Stoller authored
      about nobwshaping from Kirk.
    • Mike Hibler's avatar
      Current config for lab.onelab.eu. · 3badea66
      Mike Hibler authored
  2. 13 Oct, 2016 2 commits
  3. 12 Oct, 2016 4 commits
  4. 11 Oct, 2016 2 commits
    • David Johnson's avatar
      Let experimenters customize prepare, and interface and hosts file setup. · dd4c67d0
      David Johnson authored
      The prepare script now supports pre and post hooks.  It runs all hooks
      in rc order, from the DYNRUNDIR/prepare.pre.d and BINDIR/prepare.pre.d
      dirs (rc order in this case is the BSD order, or my version of it ---
      any file prefixed with a number is run in numeric order; other files are
      run sorted alphabetically following numeric files).  Post hooks are in
      prepare.post.d, and are run at the end of prepare.
      (DYNRUNDIR is always /var/run/emulab .  STATICRUNDIR is usually
      /etc/emulab/run but could be /etc/testbed/run, depending on the
      clientside installation.)
      We now allow users to override our default interface configuration --
      and if they do, and tell us about it by writing a file in either
      $DYNRUNDIR or $STATICRUNDIR named interface-done-$mac , we will not
      attempt to configure it, and will assume they have done it!  If they are
      nice to us and write
        $iface $ipaddr $mac
      into the file, we will parse that and put it into the @ifacemap and
      %mac2iface structures in doboot().  We do *not* attempt to provide them
      the ifconfig info in env vars or anything; they have to grok our
      ifconfig file format, in all its potential glory.
      We read the hosts.head file(s) from /etc, DYNRUNDIR, and STATICRUNDIR,
      and prepend them to our Emulab hosts content.  Then, we append the
      content of the hosts.tail file(s) from /etc, DYNRUNDIR, and STATICDIR
      --- and that file becomes the new /etc/hosts file.
      getmanifest() has become getrcmanifest() to avoid confusion with the
      GENI manifest.  Also, it now supports local manifests embedded in the
      filesystem from $DYNRUNDIR and $STATICRUNDIR (priority is manifest from
      exp, then DYNRUNDIR, then STATICRUNDIR).  All manifests read and
      applied.  Local manifests may also reference local files instead of blob
      ids, of course.  It is important to support local manifests so that
      experimenters can hook our services by default in the disk image.
    • David Johnson's avatar
      Add Linux mkextrafs support for GPT partitions. · 73e5be91
      David Johnson authored
      This mostly involves handling GPT GUID types.  Oh, we *do* use sfdisk to
      set the part type for GPT disks.  We stopped doing it for MBR disks
      because there was an observed behavior that sfdisk would whack the BSD
      disklabel when setting the partition type.  But, I assume we'll never
      have a BSD-partitioned disk in a GPT table, given our current partition
      (I also added a few optional (off by default) partprobes to deal with
      some funny behavior when testing (i.e., setting part types from 0 to X
      to 0, over and over).  The kernel is currently kind of funny.  It
      creates /dev entries for block devices that have part type 0 at boot; it
      creates /dev entries for block devs that you haven't edited when you
      simply runs partprobe (or leaves them intact); but if you make a type
      change from 0 to X and back to 0, partprobe /dev/foo does *not* create
      the device.  I'm sure this behavior has to do with the limits the kernel
      will accept for making changes to a disk with mounted partitions; but it
      is nonetheless strange.  Anyway, this is optional because on some
      kernels, at least, a forced partprobe will result in any 0-typed
      partitions not showing up in /dev, which is not very helpful.  So it's
      there if it's helpful during testing, I guess.)
  5. 10 Oct, 2016 4 commits
  6. 07 Oct, 2016 3 commits
  7. 06 Oct, 2016 4 commits
  8. 05 Oct, 2016 5 commits
  9. 04 Oct, 2016 4 commits
  10. 03 Oct, 2016 6 commits