1. 28 Nov, 2016 4 commits
  2. 23 Nov, 2016 1 commit
  3. 22 Nov, 2016 1 commit
    • Mike Hibler's avatar
      Optimize the case of a "usermod -G" which changes only a few groups. · 9ab75810
      Mike Hibler authored
      The handling of group file changes via the -G option is abysmal.
      It creates a new copy of the installed group file on every group line
      changed, fsync'ing after the new copy is made. On top of that, it implements
      a new group list by first removing the user from all existing groups and then
      reading them to every group in the new list, thereby maximizing the number of
      group lines changed!
      On the Emulab mothership where, for example, the "geniuser" user is in
      some 450+ groups, adding them to a new group entailed changing 450+ lines
      twice, resulting in over 900 copies of the 2000 line group file being
      written. This took about 17 minutes.
      The change here is modest, just check where the group line needs to be
      changed or not before doing anything. In the case above, adding a single
      group for a user, we only write the group file once. This takes about 0.8
  4. 18 Nov, 2016 2 commits
    • Mike Hibler's avatar
      Hack dongle boot code to work in new !BOOTINFO_EVENTS world. · 18729d86
      Mike Hibler authored
      Since dongle boot does not PXE boot, we will not generate a PXEBOOTING
      event. We also were not generating SHUTDOWN events. So a typical case
      was that a wireless node would just straight from ISUP to BOOTING which
      is a case I now cleverly ignore so as not to start a reboot timer ticking
      if someone runs dhclient from their otherwise healthy node.
      Anyway, there has been a low-hanging-fruit update of the boot dongle to
      allow them to use subbosses for frisbee (otherwise they have to rely on
      flaky multicast from boss via the firewall), and to load an image with
      MBR3 (though newer Linux images don't work well because the FreeBSD 6.x
      on the dongle cannot mount a newer Linux root FS to "slicefix" it).
    • Mike Hibler's avatar
      Gruesome hack to allow adding extra vif devices to vnodes after config. · 102b649e
      Mike Hibler authored
      If you add an "extravifs" file in the same directory as the "xm.conf" file,
      they will get added to the dynamically created xm.conf file (which is why
      just adding them to the existing xm.conf doesn't work!)
  5. 17 Nov, 2016 2 commits
  6. 15 Nov, 2016 3 commits
  7. 14 Nov, 2016 7 commits
    • Mike Hibler's avatar
      Allow building of zapdisk without the disk erase feature. · 8e66ee84
      Mike Hibler authored
      Needed this for building zapdisk for a really old FreeBSD (6.3).
    • Mike Hibler's avatar
      Ignore state transitions from NORMALv2/ISUP -> BOOTING. · 990fcc0b
      Mike Hibler authored
      In the !BOOTINFO_EVENTS world, someone making a random DHCP request would
      cause a state transition to BOOTING which would start a timeout ticking and
      most likely would timeout in a couple of minutes and reboot the node.
    • Mike Hibler's avatar
      Fix obscure error with (not) invalidating disks during reload. · 4925a276
      Mike Hibler authored
      Our MBR/superblock/LVM/ZFS smashing code in rc.frisbee relied on dmesg
      output to determine the local disks to call zapdisk on. However, the RE we
      used assumed well ordered output like:
        da0 at mpt0 bus 0 scbus0 target 0 lun 0
        da0: <ATA WDC WD5003ABYZ-0 1S03> Fixed Direct Access SPC-3 SCSI device
        da0: Serial Number      WD-WMAYP0DPNFLM
        da0: 300.000MB/s transfers
        da0: Command Queueing enabled
        da0: 476940MB (976773168 512 byte sectors)
      where we matched that last line. But due to the asynchronous nature of disk
      initialization, probably due to some soon-to-be-failing disks on the d710s,
      the last line was delayed and came out mashed-up with the da1 output:
        da1: <ATA WDC WD5003ABYX-1 1S02> Fixed Direct Access SPC-3 SCSI device
        da1: Serial Number      WD-WMAYP4939538
        da1: 300.000MB/s transfersda0: 476940MB (976773168 512 byte sectors)
      so we didn't see da0 and didn't call zapdisk on it. This led to some LVM
      metadata on /dev/sda4 leaking through to a new experiment and if that experiment
      tried to setup LVM (e.g., a vnode host), it would blow up.
      Now we use a sysctl call (kern.disks) to get the disk names.
    • David Johnson's avatar
    • Jonathon Duerig's avatar
    • Jonathon Duerig's avatar
      All portals hosted from the main site should use the 'emulab.net' domain when... · 3d66b3f4
      Jonathon Duerig authored
      All portals hosted from the main site should use the 'emulab.net' domain when displaying URNs for images.
    • Mike Hibler's avatar
      Tweaks to the agreement between mkextrafs and the blockstore system. · 939b0ae7
      Mike Hibler authored
      For the case in which mkextrafs is used to create local homedirs/projdirs:
      Look for the desired mount point (/local) in /etc/fstab and use that if
      it exists (i.e., that FS was already setup by the blockstore system or a
      previous mkextrafs).
      Otherwise, look for /var/emulab/boot/extrafs which should contain info
      left behind by the local blockstore setup code indicating a FS or unused
      device to use. For an unused device, rc.storage will identify the largest
      available device that is at least 10MB.
  8. 13 Nov, 2016 1 commit
  9. 12 Nov, 2016 5 commits
  10. 11 Nov, 2016 6 commits
  11. 10 Nov, 2016 4 commits
  12. 09 Nov, 2016 3 commits
  13. 08 Nov, 2016 1 commit