Erik, You can have a look here: http://dl.openvm.eu/cloudstack/centos/ks/vanilla/6/vanilla.ks
I just use virt-install with that ks. I have not yet modified them to do what i said above, but I'll make it happen this week. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ----- Original Message ----- > From: "Erik Weber" <terbol...@gmail.com> > To: users@cloudstack.apache.org > Sent: Wednesday, 8 April, 2015 22:57:16 > Subject: Re: cloud-init and password reset script > I guess that make sense. > > Do you keep your build scripts/kickstart files around to look? > > -- > Erik > > On Wed, Apr 8, 2015 at 11:43 PM, Nux! <n...@li.nux.ro> wrote: > >> After dealing with cloud-init for a while I have come to the conclusion >> that the cloudstack specific scripts should be left in /etc/init.d/ and set >> to run at every boot. I'm talking specifically about the >> cloudstack-set-password and cloudstack-set-sshkey scripts, otherwise reset >> key/password commands will fail. >> >> My next builds for the CentOS templates at dl.openvm.eu will reflect the >> above. >> >> Cloud-init is still very useful to run user data and various other stuff, >> but it seems like support for stuff other than EC2/openstack is not the >> best. >> >> Lucian >> >> -- >> Sent from the Delta quadrant using Borg technology! >> >> Nux! >> www.nux.ro >> >> ----- Original Message ----- >> > From: "Erik Weber" <terbol...@gmail.com> >> > To: users@cloudstack.apache.org >> > Sent: Wednesday, 8 April, 2015 20:49:14 >> > Subject: cloud-init and password reset script >> >> > Newer cloud-init versions have support for CloudStacks' password server, >> > but only applies it on the first boot. >> > >> > This is bad if you want to reset the password later. >> > >> > I've normally run the password reset script under the per-boot section of >> > cloud-init, but since cloud-init now requests the password first, >> discards >> > it and tells the password server it has been applied, the custom password >> > reset script no longer get any password. >> > >> > How do you handle this in your cases? I guess I could put it under >> > /etc/init and run it before cloud-init, but thought I'd check :-) >> > >> > -- >> > Erik