Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Thu, 12 Nov 2015 13:35:11 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12912414.1447315424000.49737.1447335311667@Atlassian.JIRA>
In-Reply-To: <JIRA.12912414.1447315424000@Atlassian.JIRA>
References: <JIRA.12912414.1447315424000@Atlassian.JIRA>
 <JIRA.12912414.1447315424839@arcas>
Subject: [jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows
 VMs to switch to blank passwords after each reboot
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CLOUDSTACK-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002065#comment-15002065 ] 

ASF GitHub Bot commented on CLOUDSTACK-9058:
--------------------------------------------

Github user dsclose commented on the pull request:

    https://github.com/apache/cloudstack/pull/1062#issuecomment-156103338
  
    As with my other pull request, I only used situational tests for this. I'll look into the docs to get the marvin tests up and running and will update this issue in a few days.


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