Regarding the recovery shell idea: some of us are developing security-sensitive appliances on top of these AMIs. Please make sure that any potential "backdoors" into the image have a well-defined, well documented way to disable them while customizing the image.<div><br></div><div>Thanks,</div><div>     Yaron<br><br>On Wednesday, May 2, 2012 8:43:11 PM UTC+3, Ben Howard wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">At UDS, we will holding a Ubuntu Cloud Image Round-table to discuss the
<br>state of the Cloud Images. In the interest of making this a productive
<br>session, I wanted to start an email discussion before UDS.
<br>(<a href="https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-cloud-images" target="_blank">https://blueprints.launchpad.<wbr>net/ubuntu/+spec/servercloud-<wbr>q-cloud-images</a>)
<br>
<br>* Addition of an SSH recovery Shell: Depending on the virtualization
<br>solution (i.e. EC2 EBS versus EC2 Instance-store versus OpenStack), the
<br>ability to recover from file system corruption is limited or
<br>non-existent. In order to support users across different virtualization
<br>solutions, it is proposed to introduce a SSH recovery method to assist
<br>users in recovering from file-system corruption or missing disks.
<br>
<br>  Proposal:
<br>    1. On failure of mount-all or on cloud-init failure to
<br>        mount all disks,a special SSH-session would be launched
<br>    2. Users would be forced into a screen session with an error
<br>        message.
<br>    3. Users would need to reboot.
<br>
<br></blockquote></div>