cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
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


ASF GitHub Bot commented on CLOUDSTACK-8272:

Github user bhaisaab commented on the pull request:
    @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.

> Improve password serving script by making it non-blocking non-locking concurrent server
> ---------------------------------------------------------------------------------------
>                 Key: CLOUDSTACK-8272
>                 URL:
>             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

View raw message