Comment 13 for bug 461156

I'm also unable to reproduce Markus's problems with --user-data ' << FOO >' and a patched euca2ools.

I've built a ppa build of euca2ools with the patch at https://launchpad.net/~smoser/+archive/ppa .

I tested that the patch works against ec2 with user data of " << FOO >", and that it fails against eucalyptus as Markus said.

The issue is that boto (used by euca2ools) is encoding the supplied user-data in connection.py:run_instances with:
| base64.urlsafe_b64encode(user_data)

For many input strings it is true that:
  base64.b64decode(base64.urlsafe_b64encode(str)) == str

For '<< FOO >' it is not. It will throw an error.

My guess is that eucalyptus is taking the request from euca2ools and doing a b64decode rather than urlsafe_b64decode on it. This is throwing error and being returned to the user as a parse error.

Thus, I'm fairly sure that eucalyptus will have to be changed to expect user_data to be encoded via urlsafe_b64decode() rather than b64decode().

urlsafe_b64encode is explained at http://docs.python.org/library/base64.html as:
| Encode string s using a URL-safe alphabet, which substitutes - instead of +
| and _ instead of / in the standard Base64 alphabet. The result can still contain =.

I suspect that the eucalyptus