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