From duplicate bug 461301:
revno: 222
committer: Neil
branch nick: euca2ools-1.0
timestamp: Mon 2009-10-26 11:00:47 -0700
message:
fixes #461301
--
User data is not base64
From bug 461922 (which discusses a fix that did not make it into Ubuntu yet):
=
After applying the [proposed] fix, euca-run-instances will fail depending on
the user-data input. I found this while trying to provide a shell script as
user data input. The bug is
I am unable to reproduce this problem.
euca-run-instances -k mykey --kernel eki-0212156F --ramdisk eri-604B16B8
emi-97BE1397 -z mycluster2 --user-data FOO --addressing private
RESERVATION r-405607B1 admin admin-default
INSTANCEi-45F30812 emi-97BE13970.0.0.0
Hmm. I was using the latest karmic euca2ools package (bzr200) w/ just
euca-run-instances fixed. If anything else related to user data
handling changed in between, this might be the cause. I'll be able to
look into that tomorrow.
--
User data is not base64 decoded before being presented to the
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
I just verified that ec2-api-tools work with such user data when pointed at a
eucalyptus server:
$ ec2-run-instances -k mykey --user-data FOO emi-247011C0
RESERVATION r-45F60808 admin admin-default
INSTANCEi-523209EF emi-247011C00.0.0.0 0.0.0.0 pending mykey 0
I'm attaching a snippit from /var/log/eucalyptus/cloud-error.log, that
occurs when you run the failing euca-run-instances command above.
** Changed in: eucalyptus (Ubuntu Karmic)
Status: Invalid = Confirmed
** Changed in: eucalyptus (Ubuntu Karmic)
Milestone: None = karmic-updates
**
Scott, sorry I don't understand what you are saying.
You said I'm also unable to reproduce Markus's problems with --user-
data ' FOO ' and a patched euca2ools.
But you are still running into the User authentication failed issue?
I cannot reproduce this against the upsteam (current euca2ools or
On Tue, 27 Oct 2009, Neil Soman wrote:
You said I'm also unable to reproduce Markus's problems with --user-
data ' FOO ' and a patched euca2ools.
That should have said *able* to reproduce . I do see it.
To reproduce, you have to
a.) fix euca2ools so that it doesn't doubly encode user-data
Yep, I confirm that it is a bug against eucalyptus (not euca2ools). I
was using an older version of euca2ools that did double encoding of the
user data.
thanks.
** Changed in: eucalyptus
Status: Invalid = Confirmed
** Changed in: eucalyptus
Importance: Undecided = High
** Summary
Confirming this:
$ printf %s\n%s\n '#!/bin/sh' 'echo hello world /tmp/user-data.sh
$ euca-run-instances -k mykey --user-data-file /tmp/user-data.sh emi-220011A6
-t m1.small
$ euca-describe-instances
RESERVATION r-342805FE admin default
INSTANCEi-3BB70743 emi-220011A6
** Changed in: eucalyptus (Ubuntu)
Importance: Critical = High
** Changed in: eucalyptus (Ubuntu)
Milestone: None = ubuntu-9.10
--
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
Please also think of a workaround in ec2-init if fixing eucalyptus is no
longer a possibility.
** Changed in: eucalyptus (Ubuntu)
Assignee: (unassigned) = Thierry Carrez (ttx)
** Also affects: eucalyptus (Ubuntu Karmic)
Importance: High
Assignee: Thierry Carrez (ttx)
Status:
revno: 942
committer: Neil
branch nick: 1.6
timestamp: Mon 2009-10-26 09:36:30 -0700
message:
fixes #461156
** Changed in: eucalyptus
Status: New = Fix Committed
**
** Changed in: eucalyptus (Ubuntu Karmic)
Status: Confirmed = Triaged
** Changed in: ec2-init (Ubuntu Karmic)
Status: Confirmed = Invalid
** Changed in: eucalyptus (Ubuntu Karmic)
Milestone: ubuntu-9.10 = karmic-updates
--
User data is not base64 decoded before being
In my reproduction test I retrieve a string that is base64'd two times:
$ ssh -i mykey.priv ubu...@192.168.0.230 'wget -q
http://169.254.169.254/latest/user-data -O -'; echo
SXlFdlltbHVMM05vQ21WamFHOGdQVDA5UFQwOVBUMDlJRWhGVEV4UElEMDlQVDA50
Which base64-decodes to:
I believe I've verified that using euca-run-instances base64 encodes data 2
times rather than once.
For example, with euca2ools configured to run against ec2, I do:
$ euca-run-instances --user-data hello world --key ec2-keypair ami-ef00e386
$ ssh ${ec2_host} 'wget -q
A bit more data...
I'm fairly sure that the correct thing to do here is just to remove the
following two lines from main() in euca-run-instances:
|if user_data:
|user_data = base64.urlsafe_b64encode(user_data)
Also 'import base64' on line 37 could then be removed as this is
Turns out it is an issue with euca2ools and not eucalyptus. reverting.
revno: 943
committer: Neil
branch nick: 1.6
timestamp: Mon 2009-10-26 10:52:44 -0700
message:
reverting invalid fix in revno 942 (was not a bug).
See #461301
--
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
Server Team, which is subscribed to eucalyptus in ubuntu.
--
Ubuntu-server-bugs mailing list
** Changed in: euca2ools (Ubuntu Karmic)
Milestone: None = karmic-updates
** Changed in: eucalyptus (Ubuntu Karmic)
Milestone: karmic-updates = None
** Changed in: euca2ools (Ubuntu Karmic)
Assignee: (unassigned) = Scott Moser (smoser)
** Changed in: euca2ools (Ubuntu Karmic)
21 matches
Mail list logo
