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 -- User data is not base64 decoded before being presented to the instance https://bugs.launchpad.net/bugs/461156 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
