HI Charles,

Thanks for the suggestion.  Actually original we thought allow users put
ssh keys in config.yaml but afraid that is not good to exposed in there.
But re-think it and recommend by you and other's implementation we do it.
As set/get ssh keys with relation-set/get how can we guarantee only one
unit set this (we don't want every unit generate their own keys since in
practice user may have hundreds or thousands of units per cluster)?

If it is OK we only implement customized keys through config.yaml. If user
doesn't set it we will use default keys shipped with hpcc charm. In future
we can enhance this by dynamically generate keys.

Thanks


On Fri, Jan 31, 2014 at 3:03 PM, Charles Butler <
<email address hidden>> wrote:

> Greetings Xiaoming,
>
> Thank you for the speedy response in providing the fixes for the HPCC
> charm. This is really coming along nicely.  And I personally apologize
> for the confusion surrounding $CHARM_ROOT, what I had intended to write
> was $CHARM_DIR
>
>
> > We do not use $CHARM_DIR since we want this directory to have the same
> name for all nodes. - after re-reviewing the code submission, it appears to
> me that you need this data available outside of the execution run-time of
> Juju, and you have no guarantee that you can access the data in a
> consistent manner when using $CHARM_DIR. I don't want to nitpick for using
> /var/lib/juju, as you have satisfied the requirement of not caching in
> ephemeral storage, but I feel it would be better served in it's own
> location: /var/lib/hpcc, or /etc/hpcc, or /usr/share/hpcc. As this data is
> not related to Juju.
>
> > hpcc relation hook. - that's good to hear that you are looking into
> investigating further integration with other services like ganglia. I'm
> excited to see those as they land. Thank you for the clarification.
>
> > ssh keys - I'm not really familiar with the use of the SSH keys in
> this charm, however there are a few charms that use SSL key generation.
> For an example take a look at the Postfix charm written by a fellow
> community member:
> http://bazaar.launchpad.net/~jose/charms/precise/postfix/trunk/files/head:
>
> They provide a set of configuration fields for users to insert their .ca
> and .crt file contents,  and if not present they generate self signed
> certificates, or to generate a certificate based on provided .key and
> .crt files.
>
> My suggested implementation:
>
> Add a configuration option for a public/private key pair, so the SSH
> keys themselves are stored in the JUJU runtime environment. When the
> hook execution runs, if no user-configured ssh key is present, you can
> then generate them on the first host that gets deployed. As subsequent
> HPCC client's join the cluster, in the hpcc-relation-joined hook, read
> the contents of $USER/.ssh/id_rsa.pub and $USER/.ssh/id_rsa, and set
> those as configuration values that are part of the relationship. Example
> code follows:
>
> file: Install
>
> PUB_KEY = `config-get public_key`
> PRIV_KEY=`config-get private_key`
>
> if [ -z "$PUB_KEY" ] && [ -z "$PRIV_KEY" ]; then
>    ssh-keygen -b 2048 -t rsa -N "" -f $PATH_HOME/.ssh/id_rsa
> else
>   juju-log "Using User Defined Keys"
>   echo "$private_key" > $PATH_HOME/.ssh/id_rsa
>   echo "$public_key" >> $PATH_HOME/.ssh/id_rsa.pub
>  fi
>
>
> file:  hpcc-relationship-changed
>  *note* this won't work if you have a dependency on using these keys prior
> to the relationship-joined/changed hook execution.
> public_key=`relation-get public_key`
> private_key=`relation-get private_key`
>
> if [ -z "$public_key" ] || [ -z "$private_key" ]; then
>   if [ -f $PATH_HOME/.ssh/id_rsa ]; then
>     juju-log "Sending my keys for consideration"
>     relation-set private_key=`cat $PATH_HOME/.ssh/id_rsa`
>     relation-set public_key=`cat $PATH_HOME/.ssh/id_rsa.pub`
>   fi
> else
>   echo "$private_key" > $PATH_HOME/.ssh/id_rsa
>   echo "$public_key" >> $PATH_HOME/.ssh/id_rsa.pub
>   echo "$public_key" >> $PATH_HOME/.ssh/authorized_keys
> fi
>
> Hopefully this will help clarify some of the SSH key distribution
> issues, let me know how you feel about this provided solution, and if it
> does not work we can continue working towards a more secure goal than
> distributing ssh keys with the charm.
>
> I'm going to move the status of the open review back to "incomplete",
> and following the workflow if you require additional review feel free to
> move the status to "open" or "needs-review" and someone will be along
> shortly to reivew the submitted work.
>
> Thank you again for the excellent work on this charm, and the continued
> effort to make it amazing.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1272083
>
> Title:
>   HPCC Charm initial check-in for review
>
> Status in Juju Charms:
>   New
>
> Bug description:
>   A new Juju Charm - hpcc is submitted for review.
>   The README.md has the information for how to use the charm.
>
>   For charm code:
>     config.yaml:   there are parameters to control which HPCCSystems use
> can install. There are other parameters for how to configure
>                                the cluster.
>     bin/  : There are some help scripts we put here mainly for
> re-configure HPCC cluster. Default configuration may not meet user need.
>                 We understand it probably not recommend way for juju
> charm. But we want to give user convenient  way to access the tools.
>                 We are open for discuss these during the review process.
>     icon.svg: We haven't gotten which icon we should use. It is in our
> internal process.
>
>     Currently HPCC charm doesn't have related to any other charms.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/charms/+bug/1272083/+subscriptions
>