The script was created back when 8096 was opened by default. We should def. come up with more secure way for calling the Apis for system vms restart. We already have APIs for restarting the vms, they just have to be called against all system vms in cloudstack - therefore the script.
My suggestion would be: * create bash/python script that lists all the vms using official list* apis (instead of parsing the db records) * Preserve the same options for system vm restarts from the original scripts * Make the calls secure (read the api/secret keys from the file or stdin) -alena. From: Marcus Sorensen <shadow...@gmail.com<mailto:shadow...@gmail.com>> Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> Date: Monday, September 23, 2013 10:47 AM To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> Subject: Re: whoa! our official upgrade procedures require 8096? I don't think one example of abuse means we shouldn't have it altogether. I do agree that we can't have any customer procedures requiring it. I'm not really sure why this script even exists, it looks up the system vms in the database, then fires off calls to cloudstack to restart them, am I missing something? Why isn't there just an admin level api call for this that can be a button in the UI? It would probably be simpler than the bash script. On Mon, Sep 23, 2013 at 11:19 AM, Darren Shepherd <darren.s.sheph...@gmail.com<mailto:darren.s.sheph...@gmail.com>> wrote: I complained once before that I didn't like the existence of 8096 but then plenty responded that its an optional thing. I just noticed in another thread that cloud-sysvmadm requires 8096. This is exactly why 8096 should not exist. If we create an unauthenticated backdoor, its just too tempting to use it. So now as part of our official upgrade procedures we tell people to turn on 8096 on a production cloud to reboot the system VMs. I don't think that's acceptable. Darren
