Whirr
  1. Whirr
  2. WHIRR-158

Allow users to log into clusters as themselves

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.4.0
    • Component/s: core
    • Labels:
      None

      Description

      Currently you have to log on to cloud instances with a particular user name (e.g. ec2-user on Amazon Linux, root on Ubuntu on rackspace). It would be nice if you could use the same user as the one that launched the cluster.

      1. WHIRR-158.patch
        5 kB
        Adrian Cole
      2. WHIRR-158.patch
        10 kB
        Andrei Savu

        Activity

        Hide
        Tom White added a comment -

        There are three steps to achieve this:

        • Add the new user account on the instance
        • Add the user's key to authorized keys
        • Change /etc/sudoers to allow the launching user to run all commands with no password. Add the following line:
          <user>     ALL=(ALL) NOPASSWD: ALL
          
        Show
        Tom White added a comment - There are three steps to achieve this: Add the new user account on the instance Add the user's key to authorized keys Change /etc/sudoers to allow the launching user to run all commands with no password. Add the following line: <user> ALL=(ALL) NOPASSWD: ALL
        Hide
        Lars George added a comment -

        What is the plan here to handle this best? I thought maybe a simple scritps/util/add-user that takes a "-u <username> -c <credentials>" that does the above. Not sure how handing in the public key of the user is handled (in terms of doing it as a command line parameter). I had a look into the JClouds code and it really assumes you use the supplied user account (root or ubuntu, ec2-user etc.) as per the metadata. Adding a new user and setting the credentials right may be not possible right now?

        Show
        Lars George added a comment - What is the plan here to handle this best? I thought maybe a simple scritps/util/add-user that takes a "-u <username> -c <credentials>" that does the above. Not sure how handing in the public key of the user is handled (in terms of doing it as a command line parameter). I had a look into the JClouds code and it really assumes you use the supplied user account (root or ubuntu, ec2-user etc.) as per the metadata. Adding a new user and setting the credentials right may be not possible right now?
        Hide
        Lars George added a comment -

        Looking at AuthorizeRSAPublicKey and InstallRSAPrivateKey which are the classes being used internally, they use the node.getCredentials() call, which we could maybe override with the current username. But this must be an additional TemplateOption with a list of all nodes (cloned) plus the changed credential, which by default is set from the metadata of the provider. My knowledge of JClouds is still too limited to understand if this could be simply added at the TemplateBuilder level (BootstrapClusterAction.buildTemplate()). Since this is called per node we may simply be able to add it there as an additional step?

        Show
        Lars George added a comment - Looking at AuthorizeRSAPublicKey and InstallRSAPrivateKey which are the classes being used internally, they use the node.getCredentials() call, which we could maybe override with the current username. But this must be an additional TemplateOption with a list of all nodes (cloned) plus the changed credential, which by default is set from the metadata of the provider. My knowledge of JClouds is still too limited to understand if this could be simply added at the TemplateBuilder level (BootstrapClusterAction.buildTemplate()). Since this is called per node we may simply be able to add it there as an additional step?
        Hide
        Andrei Savu added a comment -

        I suggest that we should also add a new configuration parameter:

        whirr.ssh-user-name=${sys:user.name}
        
        Show
        Andrei Savu added a comment - I suggest that we should also add a new configuration parameter: whirr.ssh-user-name=${sys:user.name}
        Hide
        Andrei Savu added a comment -

        Lars, are you working on a patch? I could give it a try next week.

        Show
        Andrei Savu added a comment - Lars, are you working on a patch? I could give it a try next week.
        Hide
        Lars George added a comment -

        Hi Andrei, sorry, I missed your update.

        I just had a good chat with Adrian and added http://code.google.com/p/jclouds/issues/detail?id=438

        I am not working on this as I think having this in JClouds is much more universal than doing something from the outside.

        Show
        Lars George added a comment - Hi Andrei, sorry, I missed your update. I just had a good chat with Adrian and added http://code.google.com/p/jclouds/issues/detail?id=438 I am not working on this as I think having this in JClouds is much more universal than doing something from the outside.
        Hide
        Andrei Savu added a comment -

        Sounds like a great idea to have this in jclouds. I will keep an eye on that feature request.

        Show
        Andrei Savu added a comment - Sounds like a great idea to have this in jclouds. I will keep an eye on that feature request.
        Hide
        Tom White added a comment -

        It's not too hard to do this from Whirr, since it's just a question of running a script - as root, which jclouds supports - that takes the current username (from the Java system property user.name), and the public key (which is just a string to pass to the script). However, if this can be done in jclouds, that would be fine too.

        Show
        Tom White added a comment - It's not too hard to do this from Whirr, since it's just a question of running a script - as root, which jclouds supports - that takes the current username (from the Java system property user.name), and the public key (which is just a string to pass to the script). However, if this can be done in jclouds, that would be fine too.
        Hide
        Andrei Savu added a comment -

        I've done some work on this, should I continue working on a patch or wait for the changes in jclouds?

        Show
        Andrei Savu added a comment - I've done some work on this, should I continue working on a patch or wait for the changes in jclouds?
        Hide
        Adrian Cole added a comment -

        agreed this is not hard to do, and would be the identical logic that jclouds would contain. if possible, we should use a Statement object for this. In the future, jclouds will non-ssh script execution at bootstrap. Keeping this in the "runScript" template option, and in Statement form will allow jclouds to choose the best option to invoke the commands. For example, it could be executed on a spot instance via userData injection.

        At any rate, don't let this slow you down!

        Show
        Adrian Cole added a comment - agreed this is not hard to do, and would be the identical logic that jclouds would contain. if possible, we should use a Statement object for this. In the future, jclouds will non-ssh script execution at bootstrap. Keeping this in the "runScript" template option, and in Statement form will allow jclouds to choose the best option to invoke the commands. For example, it could be executed on a spot instance via userData injection. At any rate, don't let this slow you down!
        Hide
        Andrei Savu added a comment -

        Ok. I will try to provide a patch in the near future and we can update the code as needed later.

        Show
        Andrei Savu added a comment - Ok. I will try to provide a patch in the near future and we can update the code as needed later.
        Hide
        Lars George added a comment -

        I had also started whipping up an "add-user" script in scripts/util that would add the user and take the details as parameters. That is where I stopped thinking if it would be a good idea to send the SSH key in as a parameters (since it gets transferred, but that is SSH, so should be fine, but it also would get logged or written to some places during the install process etc.). I started looking into how JClouds does it assuming there is a smarter way. That in the end led me to talk to Adrian.

        Show
        Lars George added a comment - I had also started whipping up an "add-user" script in scripts/util that would add the user and take the details as parameters. That is where I stopped thinking if it would be a good idea to send the SSH key in as a parameters (since it gets transferred, but that is SSH, so should be fine, but it also would get logged or written to some places during the install process etc.). I started looking into how JClouds does it assuming there is a smarter way. That in the end led me to talk to Adrian.
        Hide
        Lars George added a comment - - edited

        Also, Adrian commented (http://code.google.com/p/jclouds/issues/detail?id=438#c5):

        should produce something like this:

        useradd --shell /bin/bash --create-home adriancole

        cat > /etc/sudoers <<EOF
        root ALL = (ALL) ALL
        %adm ALL = (ALL) ALL
        adriancole ALL = (ALL) NOPASSWD: ALL
        EOF

        chown 440 /etc/sudoers

        SSH_HOME=`getent passwd adriancole | cut -d: -f6`/.ssh
        mkdir -p ${SSH_HOME}

        cat > ${SSH_HOME}/authorized_keys <<EOF
        ssh-rsa....
        EOF

        chown -R adriancole ${SSH_HOME}

        Show
        Lars George added a comment - - edited Also, Adrian commented ( http://code.google.com/p/jclouds/issues/detail?id=438#c5): should produce something like this: useradd --shell /bin/bash --create-home adriancole cat > /etc/sudoers <<EOF root ALL = (ALL) ALL %adm ALL = (ALL) ALL adriancole ALL = (ALL) NOPASSWD: ALL EOF chown 440 /etc/sudoers SSH_HOME=`getent passwd adriancole | cut -d: -f6`/.ssh mkdir -p ${SSH_HOME} cat > ${SSH_HOME}/authorized_keys <<EOF ssh-rsa.... EOF chown -R adriancole ${SSH_HOME}
        Hide
        Roman Valls added a comment -

        How difficult would it be for whirr to drop root privileges altogether for custom university clusters ?:

        http://groups.google.com/group/jclouds-dev/browse_thread/thread/4ff2d82770a55a90?pli=1

        In other words: eliminate sysadmin dependency ;P

        Show
        Roman Valls added a comment - How difficult would it be for whirr to drop root privileges altogether for custom university clusters ?: http://groups.google.com/group/jclouds-dev/browse_thread/thread/4ff2d82770a55a90?pli=1 In other words: eliminate sysadmin dependency ;P
        Hide
        Adrian Cole added a comment -

        resolving this issue will get rid of many other problems that are state-related

        Show
        Adrian Cole added a comment - resolving this issue will get rid of many other problems that are state-related
        Hide
        Adrian Cole added a comment -

        this patch incorporates tested code from https://github.com/jclouds/jclouds-examples/tree/master/compute-basics

        which is scheduled to become a real part of jclouds in issue:

        http://code.google.com/p/jclouds/issues/detail?id=473

        Show
        Adrian Cole added a comment - this patch incorporates tested code from https://github.com/jclouds/jclouds-examples/tree/master/compute-basics which is scheduled to become a real part of jclouds in issue: http://code.google.com/p/jclouds/issues/detail?id=473
        Hide
        Adrian Cole added a comment -

        This patch will add a user of the same name as the system property "user.name" If your whirr configuration is set to your current ssh keys, you should be able to login like this:
        ssh ip_address_of_node

        Show
        Adrian Cole added a comment - This patch will add a user of the same name as the system property "user.name" If your whirr configuration is set to your current ssh keys, you should be able to login like this: ssh ip_address_of_node
        Hide
        Adrian Cole added a comment -

        tested with aws-ec2 and cloudservers-uk on zookeeper

        Show
        Adrian Cole added a comment - tested with aws-ec2 and cloudservers-uk on zookeeper
        Hide
        Adrian Cole added a comment -

        Note this patch does not change the fact that whirr installs things as root. It only addresses the login user concern, which would now be your userid, which would have sudo access to root, which is running the cluster. If we want to cage services to user accounts, that's a bigger change and would require another issue, IMHO.

        Show
        Adrian Cole added a comment - Note this patch does not change the fact that whirr installs things as root. It only addresses the login user concern, which would now be your userid, which would have sudo access to root, which is running the cluster. If we want to cage services to user accounts, that's a bigger change and would require another issue, IMHO.
        Hide
        Andrei Savu added a comment -

        I'm going to update (fix hadoop/hbase proxy scripts & add clusterspec property) and test the patch tomorrow morning. Thanks Adrian!

        Show
        Andrei Savu added a comment - I'm going to update (fix hadoop/hbase proxy scripts & add clusterspec property) and test the patch tomorrow morning. Thanks Adrian!
        Hide
        Andrei Savu added a comment -

        Updated patch.

        Show
        Andrei Savu added a comment - Updated patch.
        Hide
        Adrian Cole added a comment -

        +1 hadoop tests run fine on aws-ec2 and cloudservers-us

        Show
        Adrian Cole added a comment - +1 hadoop tests run fine on aws-ec2 and cloudservers-us
        Hide
        Andrei Savu added a comment -

        Moving to 0.4.0 as a fix for WHIRR-264

        Show
        Andrei Savu added a comment - Moving to 0.4.0 as a fix for WHIRR-264
        Hide
        Andrei Savu added a comment -

        I've just committed this to trunk and the 0.4 branch. Thanks Adrian!

        Show
        Andrei Savu added a comment - I've just committed this to trunk and the 0.4 branch. Thanks Adrian!

          People

          • Assignee:
            Adrian Cole
            Reporter:
            Tom White
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development