Yeah, that would be low hanging fruit as far as features go, since the API is already in place to set VM public keys.
On Tue, Aug 26, 2014 at 4:33 PM, Carlos Reategui <car...@reategui.com> wrote: > On Tue, Aug 26, 2014 at 3:04 PM, Marcus <shadow...@gmail.com> wrote: > > > I'm wondering how you keep the root password secure. Right now, it works > > similarly to userdata and metadata, in that the instance queries its > router > > as it boots, but then the password is wiped once queried. If this didn't > > happen, non-root users could query for the root password all day. Do you > > suggest this be special userdata that is handled like this after first > > access? Or is there another way this is normally handled? > > > > For that reason I prefer to set the meta-data/public-keys and not allow > password authentication. Cloud-init supports this. It would be nice if > the UI had a means to manage keys and an option to set the public-key for > an instance. > > > > > > Is the push for cloud-init just that it is easier to install than > > cloud-set-guest-password? > > > > > > > > On Tue, Aug 26, 2014 at 4:00 PM, Erik Weber <terbol...@gmail.com> wrote: > > > > > On Tue, Aug 26, 2014 at 11:44 PM, Nux! <n...@li.nux.ro> wrote: > > > > > > > Hi Erik and thanks for your effort. Using user data is a nice idea. > > > > Let's see what more experienced programmers have to say on this. > > > > > > > > > > > Sure thing > > > > > > One thing that I noticed; though it might have been OK in your > particular > > > > case, "rm -rf /var/lib/cloud/" is a bad idea as it can include > various > > > > useful scripts along that path. As you noticed I copy the > > > > cloudstack-set-password script in /var/lib/cloud/scripts/per-boot, so > > > > that's one example. :-) > > > > > > > > > > > > > Guess I should note that this was on a test vm, to force refreshing the > > > user-data. It can probably be done with in a less harmful way. > > > > > > DO NOT DO THIS ON ANYTHING IN PRODUCTION :-) > > > > > > -- > > > Erik > > > > > >
