1. 29 Jun, 2017 4 commits
  2. 28 Jun, 2017 4 commits
  3. 26 Jun, 2017 6 commits
  4. 23 Jun, 2017 2 commits
  5. 22 Jun, 2017 2 commits
  6. 21 Jun, 2017 4 commits
    • Mike Hibler's avatar
      New strategy for deciding what root keys go in MFS: · a4ecb249
      Mike Hibler authored
        # Figure out what root pubkey(s) to use. Originally, we just copied over
        # *.pub, but that gets a whole lot of weird crap on the mothership. So now
        # we try to be more selective:
        # To keep up with the cool kids, we want to use an Ed25519 key
        # (id_ed25519.pub) if possible.
        # However since ed25519 is not supported by older sshds, we better have
        # an RSA alternative (id_rsa.pub) as well.
        # But that key may be really old and less than 2048 bits, so we may have
        # a bigger one as well (id_rsa_new.pub, note: requires changing the default
        # ssh_config on your boss since this is not a default key file name to try).
        # We really don't want to use a DSA key (id_dsa.pub) anymore unless there
        # is no alternative.
        # Finally, if we are an Elabinelab setup, include the outer boss root key.
    • Mike Hibler's avatar
    • Mike Hibler's avatar
      Gen ecdsa and ed25519 host keys too. · f5dc43a5
      Mike Hibler authored
    • Leigh B Stoller's avatar
      Throw some debugging in to try and catch idlestats stderr output · a44cc094
      Leigh B Stoller authored
      when null data is returned.
  7. 20 Jun, 2017 4 commits
  8. 19 Jun, 2017 4 commits
  9. 16 Jun, 2017 2 commits
  10. 15 Jun, 2017 3 commits
    • Mike Hibler's avatar
      Fix fixup of /etc/init/ttyS0.conf. · 1b71a72d
      Mike Hibler authored
      We were expecting it to always contain "ttyS0", but it could be
      "ttyS1" as well depending on where we last made the image.
    • Mike Hibler's avatar
      Fix a xenmode() bug exposed by a race condition. · 340f1861
      Mike Hibler authored
      The bug was that, even when the console pty device does not change,
      we still need to re-open the device since our caller has closed it.
      The race is that, on starting a domU, xenstore may briefly report the
      wrong device before finally reporting the correct one.
      On first call to xenmode, we recover from the race because we catch the
      attempt to open the non-existent device, but then when we retry the
      xenmode and we get back the same pty name, we would not do the open
      and the caller would then do a select/read on a closed fd. That is a
      fatal error. Now xenmode will report an error when it trys to reopen
      the bad pty and we will just keep calling xenmode until we finally get
      the right device.
      In theory.
    • Leigh B Stoller's avatar
  11. 14 Jun, 2017 1 commit
  12. 13 Jun, 2017 3 commits
    • David Johnson's avatar
      Make our systemd fstab-generator work with (bad?) systemds. · 58a03627
      David Johnson authored
      It seems that some systemds (i.e. 219) cannot handle by-uuid unitfile
      names (although they are happy to print them out via systemctl
      list-units).  So, in one place in the fstab-generator, just use the raw
      device naming convention.  systemd doesn't care what we use.  From the
        Ok, don't use the by-uuid method (dev-disk-by\\x2duuid-${transuuid}.swap).
        It seems to me that the vintage of systemd on Centos7
        (i.e. 219) doesn't correctly process dev-by-uuid filenames nor
        unitnames (even systemctl status <blah>, where <blah> is a
        by-uuid unit name reported by systemctl list-units, does not
        work!).  systemd 229 on Ubuntu seems happy to use the by-uuid
        unitfilename we generated above.
      (Perhaps I should have done this in all places in this script, but I
      didn't for now :(.  I believe my by-uuid encoding is correct, and I
      really don't want to rock a mostly-working boat.  This fix is enough for
      all the cases we have, I hope.)
    • David Johnson's avatar
      Workaround smart dhclient on centos7; fixes #54. · 095f2ce1
      David Johnson authored
      From the comments:
        Work around dhclient-scripts that forcibly set preferred_lft and
        valid_lft.  We cannot override the lease time sent from the server
        with a real infinite value (our best bet would be UINT32_MAX, and that
        sucks), so we intercept dhclient's name for the new lease time it's
        about to feed to the ip command.  Does this suck any less?  We cannot
        ex post facto run `ip addr change ...` just to reset the preferred_lft
        and valid_lft fields to "forever"; that seems to be tightly coupled
        with assigning an address to an interface (and we don't want to re-add
        the address; that is the whole point of dhclient-script!).  (Some
        dhclients also do not process "expire never" in dhclient.conf
        correctly, so this is what we are left with!)
    • Leigh B Stoller's avatar
  13. 12 Jun, 2017 1 commit