You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whirr.apache.org by "Adrian Cole (JIRA)" <ji...@apache.org> on 2010/08/13 00:14:16 UTC
[jira] Created: (WHIRR-70) decouple keypairs from the files that
hold them
decouple keypairs from the files that hold them
-----------------------------------------------
Key: WHIRR-70
URL: https://issues.apache.org/jira/browse/WHIRR-70
Project: Whirr
Issue Type: Improvement
Reporter: Adrian Cole
Currently, we have a method in ClusterSpec called setSecretKeyFile. The intention of this is to pass in the rsa identity used for ssh authentication on the cloud nodes. While this is generally on-disk, users may want to pass this in from another source, for example an encrypted databag.
I suggest we remove the methods in ClusterSpec that are File based, and push the responsibility for reading files to the user. Instead, I suggest we offer methods that accept PEM strings for the public and private keys. That way, the user can get their keys from files, remote servers, keystores, or anywhere, and we don't have an opinion precluding any of that. Moreover, we rid ourselves the need to write files.
ex.
instead of
clusterSpec.setSecretKeyFile(System.getProperty("user.home") + "/.ssh/id_rsa");
The user would do
clusterSpec.setPrivateKeyPem(Files.toString(new File(System.getProperty("user.home") + "/.ssh/id_rsa"), Charsets.UTF_8));
Or, we could have a utility method which would call Files.toString:
clusterSpec.setPrivateKeyPemFile(new File(System.getProperty("user.home") + "/.ssh/id_rsa"));
Bottom line is that we shouldn't require these pems to be on-disk, as they are not always on-disk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WHIRR-70) decouple keypairs from the files that
hold them
Posted by "Adrian Cole (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WHIRR-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adrian Cole updated WHIRR-70:
-----------------------------
Attachment: WHIRR-70.patch
updates to use payload object for keys and tested on cassandra, hadoop, and zookeeper
> decouple keypairs from the files that hold them
> -----------------------------------------------
>
> Key: WHIRR-70
> URL: https://issues.apache.org/jira/browse/WHIRR-70
> Project: Whirr
> Issue Type: Improvement
> Reporter: Adrian Cole
> Attachments: WHIRR-70.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, we have a method in ClusterSpec called setSecretKeyFile. The intention of this is to pass in the rsa identity used for ssh authentication on the cloud nodes. While this is generally on-disk, users may want to pass this in from another source, for example an encrypted databag.
> I suggest we remove the methods in ClusterSpec that are File based, and push the responsibility for reading files to the user. Instead, I suggest we offer methods that accept PEM strings for the public and private keys. That way, the user can get their keys from files, remote servers, keystores, or anywhere, and we don't have an opinion precluding any of that. Moreover, we rid ourselves the need to write files.
> ex.
> instead of
> clusterSpec.setSecretKeyFile(System.getProperty("user.home") + "/.ssh/id_rsa");
> The user would do
> clusterSpec.setPrivateKeyPem(Files.toString(new File(System.getProperty("user.home") + "/.ssh/id_rsa"), Charsets.UTF_8));
> Or, we could have a utility method which would call Files.toString:
> clusterSpec.setPrivateKeyPemFile(new File(System.getProperty("user.home") + "/.ssh/id_rsa"));
> Bottom line is that we shouldn't require these pems to be on-disk, as they are not always on-disk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WHIRR-70) decouple keypairs from the files that
hold them
Posted by "Tom White (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WHIRR-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom White resolved WHIRR-70.
----------------------------
Assignee: Adrian Cole
Fix Version/s: 0.1.0
Resolution: Fixed
I've just committed this. Thanks Adrian!
> decouple keypairs from the files that hold them
> -----------------------------------------------
>
> Key: WHIRR-70
> URL: https://issues.apache.org/jira/browse/WHIRR-70
> Project: Whirr
> Issue Type: Improvement
> Reporter: Adrian Cole
> Assignee: Adrian Cole
> Fix For: 0.1.0
>
> Attachments: WHIRR-70.patch, WHIRR-70.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, we have a method in ClusterSpec called setSecretKeyFile. The intention of this is to pass in the rsa identity used for ssh authentication on the cloud nodes. While this is generally on-disk, users may want to pass this in from another source, for example an encrypted databag.
> I suggest we remove the methods in ClusterSpec that are File based, and push the responsibility for reading files to the user. Instead, I suggest we offer methods that accept PEM strings for the public and private keys. That way, the user can get their keys from files, remote servers, keystores, or anywhere, and we don't have an opinion precluding any of that. Moreover, we rid ourselves the need to write files.
> ex.
> instead of
> clusterSpec.setSecretKeyFile(System.getProperty("user.home") + "/.ssh/id_rsa");
> The user would do
> clusterSpec.setPrivateKeyPem(Files.toString(new File(System.getProperty("user.home") + "/.ssh/id_rsa"), Charsets.UTF_8));
> Or, we could have a utility method which would call Files.toString:
> clusterSpec.setPrivateKeyPemFile(new File(System.getProperty("user.home") + "/.ssh/id_rsa"));
> Bottom line is that we shouldn't require these pems to be on-disk, as they are not always on-disk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WHIRR-70) decouple keypairs from the files that
hold them
Posted by "Tom White (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WHIRR-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12897980#action_12897980 ]
Tom White commented on WHIRR-70:
--------------------------------
+1 to this direction.
> decouple keypairs from the files that hold them
> -----------------------------------------------
>
> Key: WHIRR-70
> URL: https://issues.apache.org/jira/browse/WHIRR-70
> Project: Whirr
> Issue Type: Improvement
> Reporter: Adrian Cole
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, we have a method in ClusterSpec called setSecretKeyFile. The intention of this is to pass in the rsa identity used for ssh authentication on the cloud nodes. While this is generally on-disk, users may want to pass this in from another source, for example an encrypted databag.
> I suggest we remove the methods in ClusterSpec that are File based, and push the responsibility for reading files to the user. Instead, I suggest we offer methods that accept PEM strings for the public and private keys. That way, the user can get their keys from files, remote servers, keystores, or anywhere, and we don't have an opinion precluding any of that. Moreover, we rid ourselves the need to write files.
> ex.
> instead of
> clusterSpec.setSecretKeyFile(System.getProperty("user.home") + "/.ssh/id_rsa");
> The user would do
> clusterSpec.setPrivateKeyPem(Files.toString(new File(System.getProperty("user.home") + "/.ssh/id_rsa"), Charsets.UTF_8));
> Or, we could have a utility method which would call Files.toString:
> clusterSpec.setPrivateKeyPemFile(new File(System.getProperty("user.home") + "/.ssh/id_rsa"));
> Bottom line is that we shouldn't require these pems to be on-disk, as they are not always on-disk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WHIRR-70) decouple keypairs from the files that
hold them
Posted by "Adrian Cole (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WHIRR-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adrian Cole updated WHIRR-70:
-----------------------------
Attachment: WHIRR-70.patch
updated patch to address comments
> decouple keypairs from the files that hold them
> -----------------------------------------------
>
> Key: WHIRR-70
> URL: https://issues.apache.org/jira/browse/WHIRR-70
> Project: Whirr
> Issue Type: Improvement
> Reporter: Adrian Cole
> Attachments: WHIRR-70.patch, WHIRR-70.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, we have a method in ClusterSpec called setSecretKeyFile. The intention of this is to pass in the rsa identity used for ssh authentication on the cloud nodes. While this is generally on-disk, users may want to pass this in from another source, for example an encrypted databag.
> I suggest we remove the methods in ClusterSpec that are File based, and push the responsibility for reading files to the user. Instead, I suggest we offer methods that accept PEM strings for the public and private keys. That way, the user can get their keys from files, remote servers, keystores, or anywhere, and we don't have an opinion precluding any of that. Moreover, we rid ourselves the need to write files.
> ex.
> instead of
> clusterSpec.setSecretKeyFile(System.getProperty("user.home") + "/.ssh/id_rsa");
> The user would do
> clusterSpec.setPrivateKeyPem(Files.toString(new File(System.getProperty("user.home") + "/.ssh/id_rsa"), Charsets.UTF_8));
> Or, we could have a utility method which would call Files.toString:
> clusterSpec.setPrivateKeyPemFile(new File(System.getProperty("user.home") + "/.ssh/id_rsa"));
> Bottom line is that we shouldn't require these pems to be on-disk, as they are not always on-disk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WHIRR-70) decouple keypairs from the files that
hold them
Posted by "Tom White (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WHIRR-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899017#action_12899017 ]
Tom White commented on WHIRR-70:
--------------------------------
This looks good. Comments:
* The setPrivateKey/setPublicKey methods on ClusterSpec that take a Payload are not used and can be removed.
* There seem to be quite a lot of whitespace changes which make it hard to follow what's changed and make some lines more than 80 characters long. If there are formatting changes that need making it's often better to have a single wholesale patch for them. Also, it's worth running {{mvn checkstyle:checkstyle}} to be sure you haven't introduced any formatting problems.
* Nit. Can we organize the imports alphabetically?
> decouple keypairs from the files that hold them
> -----------------------------------------------
>
> Key: WHIRR-70
> URL: https://issues.apache.org/jira/browse/WHIRR-70
> Project: Whirr
> Issue Type: Improvement
> Reporter: Adrian Cole
> Attachments: WHIRR-70.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, we have a method in ClusterSpec called setSecretKeyFile. The intention of this is to pass in the rsa identity used for ssh authentication on the cloud nodes. While this is generally on-disk, users may want to pass this in from another source, for example an encrypted databag.
> I suggest we remove the methods in ClusterSpec that are File based, and push the responsibility for reading files to the user. Instead, I suggest we offer methods that accept PEM strings for the public and private keys. That way, the user can get their keys from files, remote servers, keystores, or anywhere, and we don't have an opinion precluding any of that. Moreover, we rid ourselves the need to write files.
> ex.
> instead of
> clusterSpec.setSecretKeyFile(System.getProperty("user.home") + "/.ssh/id_rsa");
> The user would do
> clusterSpec.setPrivateKeyPem(Files.toString(new File(System.getProperty("user.home") + "/.ssh/id_rsa"), Charsets.UTF_8));
> Or, we could have a utility method which would call Files.toString:
> clusterSpec.setPrivateKeyPemFile(new File(System.getProperty("user.home") + "/.ssh/id_rsa"));
> Bottom line is that we shouldn't require these pems to be on-disk, as they are not always on-disk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.