cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-8272) Improve password serving script by making it non-blocking non-locking concurrent server
Date Wed, 11 Mar 2015 07:35:39 GMT

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

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

Github user bhaisaab commented on the pull request:

    https://github.com/apache/cloudstack/pull/106#issuecomment-78217077
  
    @vincentbernat thanks for the snippets!
    
    @resmo in case the passwdsrvrtoken went missing (file does not exist), the script may
break, the || true is just so that it return 0 (exit 0). I guess your snippet is correct as
well (check and cat file), using that approach.
    
    @pdion891 looking at the code at least on the VR side there is no password expiry period
imposed by the server. I can sort of understand this, because someone could shutdown a server,
do a reset password and if the VM won't get started we should store the password in the VR.
But let's discuss the security aspects on what/how we should implement a self expiring cache.
I propose:
    1. if we have served the password at least once, let's expire it in 15-30 minutes
    2. else, expire all the passwords in next 1-24 hours whether they have been served to
user VMs (for resetting purposes) or not.
    
    Comments?


> Improve password serving script by making it non-blocking non-locking concurrent server
> ---------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-8272
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8272
>             Project: CloudStack
>          Issue Type: Improvement
>      Security Level: Public(Anyone can view this level - this is the default.) 
>    Affects Versions: 4.5.0, 4.6.0, 4.4.2, 4.3.2
>            Reporter: Rohit Yadav
>            Assignee: Rohit Yadav
>              Labels: virtualrouter
>             Fix For: 4.5.0, 4.6.0
>
>
> The current reset password server serves one user VM at a time, uses a global lock per
VR and slows up VM starting process for a VM that is created by a template with reset password
scripts. No only reset password option, but when the VM starts for the first time this happens.
The way it serves password uses forking the process/scripts which eats up resources in both
process table and memory. For a concurrent launch of 30+ VM the VR hangs/fails. Possible solution
in the past includes increase the VR memory.
> The solution would be to implement a concurrent single-process multi-threaded password
server that works both in basic/isolated network and in VPCs. It's hard to do this in bash,
so we can either implement a backward compatible python script that replaces the present bash
script, or a compiled program (like a native tool) in C/C++/Go/Rust.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message