Hi, It’s best to make a change in the source of CloudStack, then send it as a Pull Request to get it included.
When you run: `mvn clean install -P systemvm` a new systemvm.iso is generated. However, the management server will check the systemvm.iso’s signature, so I’m not sure if replacing works without also copying it to the management server and restart it (so it generates a new signature). Another trick is to alter the scripts on live routers with Ansible. Regards, Remi On 09/04/16 03:42, "Simon Weller" <swel...@ena.com> wrote: > >Richard, > >The system vms are bootstrapped with an iso that is mounted and all the >scripts are installed from there. The reason for this is to reduce the number >of times you have to completely redeploy routers (we used to have to do it for >every release). >My guess is the file you need to change is within that iso. >The iso is part of the cloudstack-common package that is installed onto all >the hosts (along with the cloudstack-agent). >Take a look in /usr/share/cloudstack-common/vms. There should be an iso in >there called systemvm.iso > >You'll probably need to mount the iso make your changes to the filesystem, >rebuild the iso with mkisofs, copy that new iso to all of your hosts and then >stop and start your VR. > >Hope this helps. > >- Si > > > > >________________________________________ >From: Richard Klein (RSI) <rkl...@rsitex.com> >Sent: Friday, April 8, 2016 7:15 PM >To: users@cloudstack.apache.org >Subject: RE: Cloudstack 4.7 password reset issue. > >I found the password reset issue and it ended up being a Python script on the >VR. I ended up modifying the "/opt/cloud/bin/configure.py" to resolve the >issue. Basically there is a "/etc/cloud/vmpassword.json" file that is updated >with the IP/password pair when the GUI password change is performed. During >the power on process the VM configuration info is sent to the router which >reads the vmpassword.json file and sends the password changes to the password >server cache file. When the client retrieved the password it was cleared from >the password cache file but not the vmpassword.json file. So every time a VM >started the last password reset was sent to the password server again. > >The question I have now is how do I get the system VM template updated with >the change? Since we are using CS v4.7 we used the system template for v4.6 >per the installation instructions for CentOS7 and KVM. I performed the >following steps to use a new system VM template: > >* I copied the system vm template QCOW2 file from secondary storage to a work >server and made a backup of it. >* On the work server I mounted the QCOW2 template file using "guestmount" >tools and made the code changes to the template. >* I then copied this modified template file to a web server and registered the >template in cloudstack with all checkboxes off except for "routing". >* Then we set the cloudstack global value of "router.template.kvm" to the name >of the new template. >* The management services were restarted. >* I picked a test VR, powered it off, destroyed it then let the system >recreate it. >* When I look at the code I changed on the new VR it does not appear. > >I even doubled checked the database and the vm_instance table for the test VR >showed the new template ID. I must be missing something or I don't really >understand how the system templates are created. Any help/suggestions would >be appreciated. > > > >Richard Klein <rkl...@rsitex.com> >RSI >5426 Guadalupe, Suite 100 >Austin TX 78751 > > > >> -----Original Message----- >> From: Richard Klein (RSI) >> Sent: Tuesday, April 05, 2016 2:32 PM >> To: users@cloudstack.apache.org >> Subject: RE: Cloudstack 4.7 password reset issue. >> >> The snippets for before and after the reboot via console look the same so I >> pasted the 2nd set of message instead of the first. Sorry about that. I did >> discover that the /var/lib/dhclient/dhclient.leases existed but was empty. >> I've >> run across an issue with CentOS 7 where the lease file is missing so I wrote >> a >> "cloud-dhcp-check" service that makes sure it exists but now I need to >> validate >> its content. That being said, I have insured that the dhclient_leases was >> valid >> and replicated the problem. >> >> The cloud-set-guest-xxxx scripts are from the master branch GitHub repository >> for apaches/cloudstack using the >> "https://github.com/apache/cloudstack/blob/master/setup/bindir/cloud-set- >> guest-password.in" and the >> "https://github.com/apache/cloudstack/blob/master/setup/bindir/cloud-set- >> guest-sshkey.in" links. >> >> I have attached the entire log from the VR but have some snippets below along >> with the VM client logs and the issue still occurs after fixing the dhcp >> lease file. >> I did not perform any password resets via the GUI during this process. >> >
