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 ch
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 use
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 euca2o
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
*
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 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 agains
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
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 0.
>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
>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
** 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)
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
Ubuntu-
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).
-
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
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 http://169.254.169.254/late
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:
IyEvYmluL3NoCmVjaG8gPT09PT09PT0
** 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 presen
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
**
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:
** 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
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
21 matches
Mail list logo