1. 02 Dec, 2014 1 commit
  2. 19 Nov, 2014 1 commit
    • Kirk Webb's avatar
      Sprinkle taint checks throughout tmcd to avert privilege escalation. · d9c27fac
      Kirk Webb authored
      Also add utility function to allow the node to get the exact details of
      the image it is running ('imageinfo').
      Some of the taint checks are rather heavy-handed presently.  Pretty much
      any vector that could be used by the user to do something as root has
      been severed right at the top of the relevant tmcd calls.
      Calls affected:
      manifest ('blackbox' and 'useronly' taintstates)
      rpms ('blackbox' and 'useronly' taintstates)
      tarballs ('blackbox' and 'useronly' taintstates)
      blobs ('blackbox' and 'useronly' taintstates)
      startupcmd ('blackbox' taintstate)
      mounts ('blackbox' taintstate)
      programs ('blackbox' taintstate)
      Taint handling for the 'accounts' call was dealt with in a prior commit.
  3. 14 Nov, 2014 1 commit
  4. 11 Nov, 2014 1 commit
    • Mike Hibler's avatar
      Attempt to prevent progmode capture from hanging on program death. · 07a25b09
      Mike Hibler authored
      I was attempting to read back any last words the program might have
      uttered, but if it said nothing, we would hang. I would not have
      expected this behavior from a pipe (actually, socketpair) when the
      other end has gone away! But, make it non blocking before we read
      to be safe.
  5. 10 Nov, 2014 1 commit
    • Mike Hibler's avatar
      Fix Linux MFS issue. · 254d0d6d
      Mike Hibler authored
      When locating the root device, if a BSD disk partition fills the entire
      DOS partition, then Linux will not create a separate /dev entry for it.
      In that case, we use the DOS partition device.
      Also, a couple of changes to resync with BSD slicefix.
  6. 09 Nov, 2014 1 commit
  7. 08 Nov, 2014 1 commit
  8. 07 Nov, 2014 2 commits
    • Mike Hibler's avatar
      The latest in logic to have findSpareDisks not use the system disk. · 2eab9b24
      Mike Hibler authored
      If an available partition device (aka, the 4th partition on the system disk)
      represents less than 5% of the spare space we have found, ignore it.
      This will allow us to continue to use the 4th partition on the system
      disk of the d710s (450GB or so) and the second disk (250GB), but not use
      the 2nd partition (3GB), which would make us thrash about on the system
      disk even more than usual.
      Mostly this is for the new HP server boxes, so it doesn't pick up the 10GB
      left over on the (virtual) system disk when we have 21TB available on the
      second (virtual) disk.
      Another hack til blockstores rule the world...
    • Mike Hibler's avatar
      Fix for CentOS. Liberalize an RE. · 2472e72a
      Mike Hibler authored
  9. 05 Nov, 2014 1 commit
  10. 23 Oct, 2014 1 commit
  11. 22 Oct, 2014 2 commits
  12. 21 Oct, 2014 7 commits
  13. 09 Oct, 2014 2 commits
    • Mike Hibler's avatar
      Rework client-side storage scripts to semi-coexist with mkextrafs uses. · 9cf8f9c6
      Mike Hibler authored
      Broke rc.storage into two phases, local blockstores and remote blockstores.
      Setup of the former will also pick a best candidate for an old-school
      "extrafs" and put the info in /var/emulab/boot/extrafs. This will be a
      single line with one of DISK=foo, PART=foo, or FS=foo depending on whether
      it found an available full disk, disk partition, or mounted filesystem
      that we can use for mkextrafs (in the first two cases) or where we can
      mooch off of (the last). This is only used in os_mountextrafs() right now;
      i.e., I have NOT changed the mkextrafs script. So explicit invocations
      by the user could still screw things up.
      I have tested this with local blockstores and a non-nfs experiment
      on both Linux and FreeBSD to make sure the most common sharing of space
      works. I have not made any new images and I have not yet tested to make
      sure I did not break non-blockstore, non-nfs experiments (i.e., where
      we really should run mkextrafs).
      So maybe don't make any new images til I get back, or else be prepared
      to clean up after me.
    • Kirk Webb's avatar
      Move vlan interface creation to vnodePreConfigExpNetwork() for blockstores. · 7999e43d
      Kirk Webb authored
      Also fix a couple of nits.
  14. 08 Oct, 2014 2 commits
    • Kirk Webb's avatar
      Fix vlan interface handling under FreeNAS 9. · d403580d
      Kirk Webb authored
      FreeNAS 9 has reached a new level of broken in its handling of network
      configuration. Essentially each time a vlan interface is added, or
      IP configuration is added, it wipes all existing vlan configurtion
      and recreates it from its database.  Worse, when IP addresses/aliases
      are removed, it completely shuts off all network interfaces and
      re-configures them from scratch. ALL interfaces.  All of them.
      Every last one. Even those that are not in scope for the current
      modification operation.
      So, we now do ALL network manipulation, including create/destroy
      vlan operations, behind FreeNAS's back.  As a consequence, FreeNAS's
      UI will often not show the actual network configuration - it will only
      list those things that have been set up statically through its
      interfaces (command line or UI).
    • Leigh B Stoller's avatar
  15. 07 Oct, 2014 2 commits
  16. 06 Oct, 2014 4 commits
  17. 04 Oct, 2014 4 commits
  18. 03 Oct, 2014 3 commits
  19. 02 Oct, 2014 3 commits
    • Mike Hibler's avatar
    • Mike Hibler's avatar
      Forgot a file that has been removed. · 97a27a03
      Mike Hibler authored
    • Mike Hibler's avatar
      FreeNAS 9 support, "improved" FreeNAS 8 support. · 23447d73
      Mike Hibler authored
      A clientside top-level "gmake freenas-tarball" will build everything and
      construct an appropriate tarball. You must either build on FreeBSD 8.3 or
      FreeBSD 9.2, depending on the version of FreeNAS you are targetting.
      This cannot be done native on the FreeNAS box! In part because there is
      no compiler there, but even if there was, the install target would wreak
      havoc on a full root filesystem; it assumes it is working on a skeleton
      FS with just the Emulab stuff in it.
      Mostly this commit is grotesque Makefile hacking due to our tragic
      client-side tmcc OS-specific directory structure. Hey, don't blame me!
      It was, um...okay DO blame me...