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. >
