1. 30 Jun, 2017 1 commit
  2. 29 Jun, 2017 7 commits
  3. 28 Jun, 2017 4 commits
  4. 26 Jun, 2017 6 commits
  5. 23 Jun, 2017 2 commits
  6. 22 Jun, 2017 2 commits
  7. 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.
        #
      a4ecb249
    • Mike Hibler's avatar
      407c901c
    • Mike Hibler's avatar
      Gen ecdsa and ed25519 host keys too. · f5dc43a5
      Mike Hibler authored
      f5dc43a5
    • 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.
      a44cc094
  8. 20 Jun, 2017 4 commits
  9. 19 Jun, 2017 4 commits
  10. 16 Jun, 2017 2 commits
  11. 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.
      1b71a72d
    • 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.
      340f1861
    • Leigh B Stoller's avatar
  12. 14 Jun, 2017 1 commit