[
https://issues.apache.org/jira/browse/CLOUDSTACK-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15008865#comment-15008865
]
ASF GitHub Bot commented on CLOUDSTACK-9058:
--------------------------------------------
Github user dsclose commented on the pull request:
https://github.com/apache/cloudstack/pull/1062#issuecomment-157409534
This was tested situationally. Not perfect, but we don't have the
Cloudstack test-suite setup yet. Not sure I will have time to do that now.
The following steps were taken on a Cloudstack 4.5 router:
1. Demonstrate default response when no password is to be issued.
1. Open a session on a linux VM
2. Use the arp table to get the IP address of the master virtual router
(10.2.13.58 in my case)
3. Query the router for a password and save the result in pass.txt:
wget -t 3 -T 20 -O pass.txt --header 'DomU_Request:
send_my_password' 10.2.13.58:8080
4. Verify that pass.txt is empty, delete pass.txt
2. Demonstrate correct response when there is a password to be issued.
1. Obtain the IP address of a VM you want to issue a password for
(10.2.13.22 in my case)
2. Set up the router to serve a password.
1. Open a session on the router.
2. Save a password for the VM with the value of “test_password”:
1. /opt/cloud/bin/savepassword.sh –v 10.2.13.22 –p test_password
1. Verify that the password has been saved:
cat /var/cache/cloud/passwords-10.2.13.58
10.2.13.22=test
3. Query the router:
1. Open a session on the linux VM
2. Run the same query command as above:
wget -t 3 -T 20 -O pass.txt --header 'DomU_Request:
send_my_password' 10.2.13.58:8080
3. pass.txt should now contain test_password
Those same steps were followed for a Cloudstack 4.3 router (we upgraded
from 4.3 to 4.5). It was observed that the Cloudstack 4.3 router replied with
"saved_password" when there was no password to be served.
Once we established the difference in behaviour we implemented the given
fix, rebuilt the systemvm.iso and pushed it out to our hypervisors.
The solution was initially tested:
1. By rebuilding a test network, repeating the steps above to verify that
we got the expected behaviour.
2. By reproducing the password reset issue on a Windows guest VM running on
a network that used the Cloudstack 4.5 system VM. We then rebuilt that network
and observed that the Windows VM maintained its password.
1. We also observed that the windows VM repeatedly queried the password
server for 30 minutes.
2. This has been seen each time a network is rebuilt so far.
3. We restarted the cloud service on Windows Guest VMs to see if that would
cause the password to be lost. The password was maintained.
4. We manually set the administrative password on a windows guest VM and
then rebooted. The password was maintained.
5. We triggered a password reset on a windows guest VM, a new password was
assigned and adopted by the VM.
6. We repeated steps 4 and 5 on a linux VM. The Linux VM behaved as
expected.
Subsequent to this, we rebuilt all of our networks with the fixed router.
This rebuilt several-hundred virtual routers. There are several-hundred Windows
guests. Whereas we were getting alerted by our clients regularly about password
issues connected with reboots before the fix, we have not seen a repeat of the
behaviour since this fixed was rolled out.
> Password server causes Windows VMs to switch to blank passwords after each
> reboot
> ---------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-9058
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: ISO, Virtual Router
> Affects Versions: 4.5.2
> Reporter: dsclose
> Priority: Critical
>
> Previous versions of the systemvm.iso used a shell script to serve passwords.
> In response to a "send_my_password" query, if no password was to be served,
> the /opt/cloud/bin/serve_password.sh script would issue a response with
> "saved_password" in the body.
> The new version of the systemvm.iso supercedes serve_password.sh with a
> python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour
> is different to the original serve_password.sh. In response to a
> "send_my_password" query, if no password was to be served, the
> /opt/cloud/bin/passwd_server_ip.py script issues an empty response.
> Linux guests handle this appropriately. The cloud-set-guest-password init
> script uses a case statement to ignore blank responses. I've not been able to
> examine the code for the equivalent Windows guest service but it responds
> very differently.
> If a Windows guest receives a blank response from the password server then it
> assumes that the password needs to be blank. The log on the windows guest
> reports the following:
> [INFO] Need to set new password for this VM. First letter in password :
> [INFO] New password has been set for this VM
> The windows guest expects a "saved_password" response if a password isn't
> being issued. If it receives this response then it logs the following:
> [INFO] No need to set password, because http://10.1.1.1:8080/ said so with
> response saved_password
> Because the password server is queried every time the windows service starts,
> this will result in the guest adopting a blank password every time it is
> rebooted or the service is restarted. It's probably unrealistic to consider
> updating the Windows service in every guest currently running in cloudstack.
> As such it looks like the password server's behaviour needs to be adjusted to
> match the behaviour that guests expect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
