Uploaded image for project: 'Bigtop'
  1. Bigtop
  2. BIGTOP-2252

provisional hdfs ssh keys couldn't be found during deployment

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.0
    • Fix Version/s: 1.1.0
    • Component/s: deployment
    • Labels:
      None

      Description

      It seems that during some recent updates of the Puppet deployment we lost the ability to install testing ssh keys for 'hdfs' user. Needs to get fixed.

        Issue Links

          Activity

          Hide
          cos Konstantin Boudnik added a comment -

          Pushed to the master.

          Show
          cos Konstantin Boudnik added a comment - Pushed to the master.
          Hide
          cos Konstantin Boudnik added a comment - - edited

          Yeah, that what it does. Basically fixing something that was working before then got borked. Not the best idea ever (I agree, but seems to be harmless, really).
          And thanks - I will commit it later in the day

          Show
          cos Konstantin Boudnik added a comment - - edited Yeah, that what it does. Basically fixing something that was working before then got borked. Not the best idea ever (I agree, but seems to be harmless, really). And thanks - I will commit it later in the day
          Hide
          oflebbe Olaf Flebbe added a comment -

          Sorry, I only found tim to look into the patch. It only moves around files and does not introduce new concepts.... So let it in, if it fixes things.

          Show
          oflebbe Olaf Flebbe added a comment - Sorry, I only found tim to look into the patch. It only moves around files and does not introduce new concepts.... So let it in, if it fixes things.
          Hide
          cos Konstantin Boudnik added a comment -

          I am with you, really. And there's nothing preventing us from the dynamic keys generation. I am just don't see any dangers in doing static keys in this very narrow keys of virtual and well-isolated environments.

          Show
          cos Konstantin Boudnik added a comment - I am with you, really. And there's nothing preventing us from the dynamic keys generation. I am just don't see any dangers in doing static keys in this very narrow keys of virtual and well-isolated environments.
          Hide
          oflebbe Olaf Flebbe added a comment -

          Sorry had no time to work out an alternative solution, right now. Please do not use default keys, never. Please generate keys if needed on the fly and deploy them.

          Show
          oflebbe Olaf Flebbe added a comment - Sorry had no time to work out an alternative solution, right now. Please do not use default keys, never. Please generate keys if needed on the fly and deploy them.
          Hide
          cos Konstantin Boudnik added a comment -

          Olaf Flebbe, any reaction to my comment?

          Show
          cos Konstantin Boudnik added a comment - Olaf Flebbe , any reaction to my comment?
          Hide
          cos Konstantin Boudnik added a comment - - edited

          I agree that perhaps BIGTOP-2238 shouldn't be allowing this provision by default, but instead will check an env.var instead. So that if I need to provision these test keys i would be able to.

          However, and I am not saying this with an easy heart, my old-timer sysadmin paranoia is still strong with me: these keys aren't even provisioned for CI purposes. They are strictly limited to the vagrant toy-cluster (test-only) provisioning. Of course we have an option of not doing this. The only side effect right now would be a skipped TestBlockRecovery.

          Show
          cos Konstantin Boudnik added a comment - - edited I agree that perhaps BIGTOP-2238 shouldn't be allowing this provision by default, but instead will check an env.var instead. So that if I need to provision these test keys i would be able to. However, and I am not saying this with an easy heart, my old-timer sysadmin paranoia is still strong with me: these keys aren't even provisioned for CI purposes. They are strictly limited to the vagrant toy-cluster (test-only) provisioning. Of course we have an option of not doing this. The only side effect right now would be a skipped TestBlockRecovery .
          Hide
          oflebbe Olaf Flebbe added a comment -

          Please don't do this. Do not use default credentials , this is a security nightmare, even for CI.

          -1. Let me dig into alternatives.

          Show
          oflebbe Olaf Flebbe added a comment - Please don't do this. Do not use default credentials , this is a security nightmare, even for CI. -1. Let me dig into alternatives.
          Hide
          cos Konstantin Boudnik added a comment -

          I've tested this and everything works as expected. Would appreciate our Puppet experts' second look at it. Thanks!

          Show
          cos Konstantin Boudnik added a comment - I've tested this and everything works as expected. Would appreciate our Puppet experts' second look at it. Thanks!

            People

            • Assignee:
              cos Konstantin Boudnik
              Reporter:
              cos Konstantin Boudnik
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development