Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 787D9200C3D for ; Tue, 14 Mar 2017 09:42:47 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 772D5160B7E; Tue, 14 Mar 2017 08:42:47 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id C0628160B7C for ; Tue, 14 Mar 2017 09:42:46 +0100 (CET) Received: (qmail 87903 invoked by uid 500); 14 Mar 2017 08:42:45 -0000 Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list issues@cloudstack.apache.org Received: (qmail 87891 invoked by uid 500); 14 Mar 2017 08:42:45 -0000 Delivered-To: apmail-incubator-cloudstack-issues@incubator.apache.org Received: (qmail 87882 invoked by uid 99); 14 Mar 2017 08:42:44 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Mar 2017 08:42:44 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id EDAC5184962 for ; Tue, 14 Mar 2017 08:42:43 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.452 X-Spam-Level: * X-Spam-Status: No, score=1.452 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.652, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id 6XK8vwER36fR for ; Tue, 14 Mar 2017 08:42:42 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 7F36F5FE31 for ; Tue, 14 Mar 2017 08:42:42 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id D52B0E08C3 for ; Tue, 14 Mar 2017 08:42:41 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 91EA1243AA for ; Tue, 14 Mar 2017 08:42:41 +0000 (UTC) Date: Tue, 14 Mar 2017 08:42:41 +0000 (UTC) From: "ASF GitHub Bot (JIRA)" To: cloudstack-issues@incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CLOUDSTACK-9727) Password reset discrepancy in RVR when one of the Router is not in Running state. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 14 Mar 2017 08:42:47 -0000 [ https://issues.apache.org/jira/browse/CLOUDSTACK-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15923799#comment-15923799 ] ASF GitHub Bot commented on CLOUDSTACK-9727: -------------------------------------------- Github user bvbharatk commented on the issue: https://github.com/apache/cloudstack/pull/1965 @ustcweizhou We are saving the password in the user_vm_details explicitly. We are not checking if ssh key pair is set for this vm or not. I agree that ideally we should sync the password between the master and backup, For any kind of sync to work we need to know if the password was read from one of the VRs and In cases when one of the Vr is Stopped we will have to clear the password from db when it is read from the other one. These type of changes add complexity to the simple task of setting a password. The next best thing is to make sure we save the same password in both the routers. This will fix will at least solve the problem of sending the correct password even if the master and backup change state before the VM starts. Yes like you pointed out this will lead to the problem that the user might receive the old password when he stop starts the VM, In this case the user will get a notification in the UI that his password will be changed. So he at least knows what the password is and so he can log into the VM. > Password reset discrepancy in RVR when one of the Router is not in Running state. > --------------------------------------------------------------------------------- > > Key: CLOUDSTACK-9727 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9727 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the default.) > Affects Versions: 4.9.0 > Reporter: Bharat Kumar > Assignee: Bharat Kumar > Fix For: 4.9.2.0 > > > - Deploy an instance and place " cloud-set-guest-password " script in the /etc/init.d location and provide the executable permission. > - Create a template from the above VM. > - Create a new network offering with RVR enabled. > - Deploy a new VM from the above created template and select the above RVR offering. > - Ensure that the password script is sucessfuly running. > - Put the backup router in stopped state and ensure only master is running. > - Now stop the VM and and Reset the password. > - DO not start the VM , Now Stop the current Master and start the Back up. > - Now the Back Up would be the Master. Now start the VM. > Observations: > - The password is saved onto only Master which is in stopped state now or either in backup if we start it. > - The current Master which was back up earlier do not have the new password. Hence user cannot now login with the new password. > - In this scenario there is disperancy in the password stored on both the RVR's. > The only way to sync both the passwords now is , ensure both the RVR are running and reset the password on VM. -- This message was sent by Atlassian JIRA (v6.3.15#6346)