On 03/11/2014 05:25 AM, Dmitry Mescheryakov wrote:
For what it's worth in Sahara (former Savanna) we inject the second
key by userdata. I.e. we add
echo "${public_key}" >> ${user_home}/.ssh/authorized_keys
to the other stuff we do in userdata.
Dmitry
2014-03-10 17:10 GMT+04:00 Jiří Stránský <ji...@redhat.com>:
On 7.3.2014 14:50, Imre Farkas wrote:
On 03/07/2014 10:30 AM, Jiří Stránský wrote:
Hi,
there's one step in cloud initialization that is performed over SSH --
calling "keystone-manage pki_setup". Here's the relevant code in
keystone-init [1], here's a review for moving the functionality to
os-cloud-config [2].
You really should not be doing this. I should never have written
pki_setup: it is a developers tool: user a real CA and a real certificate.
The consequence of this is that Tuskar will need passwordless ssh key to
access overcloud controller. I consider this suboptimal for two reasons:
* It creates another security concern.
* AFAIK nova is only capable of injecting one public SSH key into
authorized_keys on the deployed machine, which means we can either give
it Tuskar's public key and allow Tuskar to initialize overcloud, or we
can give it admin's custom public key and allow admin to ssh into
overcloud, but not both. (Please correct me if i'm mistaken.) We could
probably work around this issue by having Tuskar do the user key
injection as part of os-cloud-config, but it's a bit clumsy.
This goes outside the scope of my current knowledge, i'm hoping someone
knows the answer: Could pki_setup be run by combining powers of Heat and
os-config-refresh? (I presume there's some reason why we're not doing
this already.) I think it would help us a good bit if we could avoid
having to SSH from Tuskar to overcloud.
Yeah, it came up a couple times on the list. The current solution is
because if you have an HA setup, the nodes can't decide on its own,
which one should run pki_setup.
Robert described this topic and why it needs to be initialized
externally during a weekly meeting in last December. Check the topic
'After heat stack-create init operations (lsmola)':
http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-12-17-19.02.log.html
Thanks for the reply Imre. Yeah i vaguely remember that meeting :)
I guess to do HA init we'd need to pick one of the controllers and run the
init just there (set some parameter that would then be recognized by
os-refresh-config). I couldn't find if Heat can do something like this on
it's own, probably we'd need to deploy one of the controller nodes with
different parameter set, which feels a bit weird.
Hmm so unless someone comes up with something groundbreaking, we'll probably
keep doing what we're doing. Having the ability to inject multiple keys to
instances [1] would help us get rid of the Tuskar vs. admin key issue i
mentioned in the initial e-mail. We might try asking a fellow Nova developer
to help us out here.
Jirka
[1] https://bugs.launchpad.net/nova/+bug/917850
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
