@Ian Gibbs, are you sure that your instance isn't simply running an end-
of-lifed Ubuntu release (such as 19.04 Disco)? That was the difficulty
when I was suffering just now from similar behavior as described in this
issue. Hope this helps.
--
You received this bug notification because you are a
This is still an issue. From reading the comments I'm not seeing a clear
"won't fix". It seems to have got lost?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/615545
Title:
Instances launched in a
13:50 smoser amazon has since changed some things, and the previous fix that
was in -proposed no longer actually fixes anything
13:51 smoser so i dropped it.
So the package in lucid-proposed will not be promoted to lucid-updates.
** Changed in: cloud-init (Ubuntu Lucid)
Status: Fix
13:50 smoser amazon has since changed some things, and the previous fix that
was in -proposed no longer actually fixes anything
13:51 smoser so i dropped it.
So the package in lucid-proposed will not be promoted to lucid-updates.
** Changed in: cloud-init (Ubuntu Lucid)
Status: Fix
I agree with Eric and cloudcontrol, for CNAMEs being the correct
solution.
In the meantime, there's a problem with using any debian package from
within ec2 instances - you can't contact the repository to install any
packages, so using a package to fix the problem presents something of a
Excerpts from Noah's message of Thu Jan 26 11:26:08 UTC 2012:
I agree with Eric and cloudcontrol, for CNAMEs being the correct
solution.
The S3 solution is coming very soon, and will negate the need for these
CNAME's, so all we can do is ask for your patience.
In the meantime, there's a
On Thu, 26 Jan 2012, Clint Byrum wrote:
Excerpts from Noah's message of Thu Jan 26 11:26:08 UTC 2012:
You can achieve this with a cloud-init userdata section by specifying the
apt mirror. This is all that is needed:
#cloud-config
apt_mirror: http://uk.archive.ubuntu.com/ubuntu/
Noah was
I agree with Eric and cloudcontrol, for CNAMEs being the correct
solution.
In the meantime, there's a problem with using any debian package from
within ec2 instances - you can't contact the repository to install any
packages, so using a package to fix the problem presents something of a
Excerpts from Noah's message of Thu Jan 26 11:26:08 UTC 2012:
I agree with Eric and cloudcontrol, for CNAMEs being the correct
solution.
The S3 solution is coming very soon, and will negate the need for these
CNAME's, so all we can do is ask for your patience.
In the meantime, there's a
On Thu, 26 Jan 2012, Clint Byrum wrote:
Excerpts from Noah's message of Thu Jan 26 11:26:08 UTC 2012:
You can achieve this with a cloud-init userdata section by specifying the
apt mirror. This is all that is needed:
#cloud-config
apt_mirror: http://uk.archive.ubuntu.com/ubuntu/
Noah was
The workaround used to know if the instance is inside a VPC isn't
working for me, I launched a EC2 instance and I assigned an Elastic IP
(all these using cloud formation), when cloud-init gets the metadata
this is what it gets:
# curl http://169.254.169.254/latest/meta-data/
ami-id
The workaround used to know if the instance is inside a VPC isn't
working for me, I launched a EC2 instance and I assigned an Elastic IP
(all these using cloud formation), when cloud-init gets the metadata
this is what it gets:
# curl http://169.254.169.254/latest/meta-data/
ami-id
Agree with Eric- this will be less expensive in the long run, though
potential to use CDN for the mirror is intriguing.
One last point in support of CNAMEs- in case there is unease with
relying on the CNAME solution (as Canonical does not control routing in
EC2), rest assured that this method is
Agree with Eric- this will be less expensive in the long run, though
potential to use CDN for the mirror is intriguing.
One last point in support of CNAMEs- in case there is unease with
relying on the CNAME solution (as Canonical does not control routing in
EC2), rest assured that this method is
I believe we talked once about doing the CNAME solution, and the
decision was made not to implement it. The reason was (from memory)
that if we did, all requests would then hit external mirrors, and
subsequently we would have to open up all traffic to the ec2 mirrors
that canonical IS is running.
Scott:
- With the CNAME solution, the requests still go to the internal IP
address for standard EC2 instances.
- I don't imagine that many non-EC2 people would try to configure their
Ubuntu systems to use the EC2 repositories.
- Canonical would get charged the same network fees for people
I believe we talked once about doing the CNAME solution, and the
decision was made not to implement it. The reason was (from memory)
that if we did, all requests would then hit external mirrors, and
subsequently we would have to open up all traffic to the ec2 mirrors
that canonical IS is running.
Scott:
- With the CNAME solution, the requests still go to the internal IP
address for standard EC2 instances.
- I don't imagine that many non-EC2 people would try to configure their
Ubuntu systems to use the EC2 repositories.
- Canonical would get charged the same network fees for people
Hi Folks,
To whoever manages DNS for this repository: a more elegant solution not
requiring an package patches would have been to follow this practice for
DNS on EC2.
Try to use CNAMES to the fully-qualified domain name EC2 instead of A
records. For example, at the moment you are using:
+1 for cloudcontrol's recommendation to use CNAMEs. I've been
recommending this to Canonical since we were discussing the initial
setup of EC2 dedicated repositories. It would have avoided a couple
issues that have happened since and would help prevent future problems
as AWS releases new
Excerpts from cloudcontrol's message of Thu Jan 12 23:27:07 UTC 2012:
Hi Folks,
To whoever manages DNS for this repository: a more elegant solution not
requiring an package patches would have been to follow this practice for
DNS on EC2.
Try to use CNAMES to the fully-qualified domain name
Excerpts from cloudcontrol's message of Thu Jan 12 23:27:07 UTC 2012:
Hi Folks,
To whoever manages DNS for this repository: a more elegant solution not
requiring an package patches would have been to follow this practice for
DNS on EC2.
Try to use CNAMES to the fully-qualified domain name
Hi Folks,
To whoever manages DNS for this repository: a more elegant solution not
requiring an package patches would have been to follow this practice for
DNS on EC2.
Try to use CNAMES to the fully-qualified domain name EC2 instead of A
records. For example, at the moment you are using:
+1 for cloudcontrol's recommendation to use CNAMEs. I've been
recommending this to Canonical since we were discussing the initial
setup of EC2 dedicated repositories. It would have avoided a couple
issues that have happened since and would help prevent future problems
as AWS releases new
Hello Gabriel, or anyone else affected,
Accepted cloud-init into lucid-proposed, the package will build now and
be available in a few hours. Please test and give feedback here. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed. Thank you in
Hello Gabriel, or anyone else affected,
Accepted cloud-init into lucid-proposed, the package will build now and
be available in a few hours. Please test and give feedback here. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed. Thank you in
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: cloud-init (Ubuntu Lucid)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
** Also affects: cloud-init (Ubuntu Lucid)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/615545
Title:
Instances launched in a VPC
** Description changed:
sources.list is helpfully configured to us-east-1.ec2.archive.ubuntu.com
for instances that I launch in US-EAST-1 on EC2. However, instances
launched in a Virtual Private Cloud (VPC) can only access machines in
their local subnet, private machines on the connected
** Changed in: cloud-init (Ubuntu Lucid)
Status: Confirmed = In Progress
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/615545
Title:
Instances launched in a VPC cannot
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: cloud-init (Ubuntu Lucid)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/615545
** Also affects: cloud-init (Ubuntu Lucid)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/615545
Title:
Instances launched in a VPC cannot access
** Description changed:
sources.list is helpfully configured to us-east-1.ec2.archive.ubuntu.com
for instances that I launch in US-EAST-1 on EC2. However, instances
launched in a Virtual Private Cloud (VPC) can only access machines in
their local subnet, private machines on the connected
** Changed in: cloud-init (Ubuntu Lucid)
Status: Confirmed = In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/615545
Title:
Instances launched in a VPC cannot access
Gabriel,
Could you try the attached deb and report back if it fixes the problem?
You can test this by:
- boot instance
- ssh instance
- get this deb (wget or scp)
- sudo dpkg -i cloud-init_0.5.15-0ubuntu3~ppa1_all.deb
- sudo rm /var/lib/cloud/sem/config-apt-update-upgrade.*
- sudo reboot
on
If you'd rather get it from a ppa, the deb attached should appear in my
ppa shortly. I just attached because its set to start building in 4
hours.
--
Instances launched in a VPC cannot access ec2.archive.ubuntu.com
https://bugs.launchpad.net/bugs/615545
You received this bug notification
Nice, it worked! After starting a maverick daily, applying the deb and
removing config-apt-update-upgrade.* and reboot my sources.list was
pointing to archive.ubuntu.com and and apt-get update worked.
Thanks!
--
Instances launched in a VPC cannot access ec2.archive.ubuntu.com
This bug was fixed in the package cloud-init - 0.5.15-0ubuntu3
---
cloud-init (0.5.15-0ubuntu3) maverick; urgency=low
* do not use ec2 ubuntu archive if instance is VPC (LP: #615545)
-- Scott Moser smo...@ubuntu.com Thu, 16 Sep 2010 04:28:55 -0400
** Branch linked:
@Gabriel
Could you comment with the output the following command from inside an VPC
instance:
python -c 'import boto.utils, pprint;
pprint.pprint(boto.utils.get_instance_metadata())'
--
Instances launched in a VPC cannot access ec2.archive.ubuntu.com
https://bugs.launchpad.net/bugs/615545
You
Sure:
{'ami-id': 'ami-328d655b',
'ami-launch-index': '0',
'ami-manifest-path': '(unknown)',
'block-device-mapping': {'ami': '/dev/sda1',
'root': '/dev/sda1',
'swap': 'sda3'},
'hostname': 'ip-10-10-11-5',
'instance-action': 'none',
** Package changed: linux-ec2 (Ubuntu) = cloud-init (Ubuntu)
** Changed in: cloud-init (Ubuntu)
Importance: Undecided = Medium
** Changed in: cloud-init (Ubuntu)
Status: New = Confirmed
--
Instances launched in a VPC cannot access ec2.archive.ubuntu.com
| posting from a mail from Gabriel:
|
| The design of VPC is that instances launched in VPC cannot communicate with
| the internal EC2 network. They can only communicate with other instances in
| the subnet, and the machines on the other end of the tunnel. All internet
| traffic is routed through
More information on VPC:
http://aws.amazon.com/vpc/
http://docs.amazonwebservices.com/AmazonVPC/2010-06-15/GettingStartedGuide/index.html?BriefIntroduction.html
--
Instances launched in a VPC cannot access ec2.archive.ubuntu.com
https://bugs.launchpad.net/bugs/615545
You received this bug
43 matches
Mail list logo
