On Mon, May 18, 2020 at 02:59:50AM +, Cauã Siqueira wrote:
> My name's Cauã (Brazilian) and i use Debian for many years. I'm building a
> new infrastructure inside AWS with terraform. We're migrating from CoreOS to
> Debian (choice me), but we're having a problem with userdata to create
>
On Tue, May 12, 2020 at 06:57:06PM -0500, Ryan Belgrave wrote:
>After doing a bunch more digging it seems to be related to
>[1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947351
It certainly could be.
Can you test a sid or bullseye image? They have cloud-init 20.1.
Try
On Mon, May 11, 2020 at 07:18:08PM -0500, Ryan Belgrave wrote:
>What are the correct images to use for a baremetal cloud? The first ones I
>tried were the Openstack ones but those don't seem to have any drivers for
>physical machines. I couldn't get USB keyboards to work physically or
On Fri, May 08, 2020 at 11:41:55PM +0200, Bastian Blank wrote:
> > Does this seem sane? Any other ideas?
>
> Nope, it is not really. The daily and release projects needs to use
> current tools, without it diverging between the branches.
I'm not sure I agree. A lot of important details about
At some point, maintaining config for our stable images in the same
repository as our unstable/testing images is going to become
unmanageable. We'd like to be able to make changes targeting unstable
without worrying about breaking our stable builds.
Consider the following simple case. I'm
On Sat, May 02, 2020 at 11:24:59PM +0200, Bastian Blank wrote:
> cloud-init does some basic tasks, like
> - network config (currently completely shadowed by our own),
> - ssh host keys.
>
> I think the most sensible setup would always enable cloud-init, and if
> it only runs with the fallback
On Thu, Mar 26, 2020 at 09:01:00PM -0300, Antonio Terceiro wrote:
> > the instances were created by hand but their setup is automated.
> >
> > > For some background, the AWS account under which these instances are
> > > running is owned by an individual DD, not SPI/Debian. We have created a
> > >
On Mon, Apr 27, 2020 at 11:41:10PM +0100, Wookey wrote:
> > > > generic is most flexible, genericcloud has physical hardware drivers
> > > > disabled,
> > > > and nocloud is as minimal as possible. The tools, configs, and docs
> > > > are in
> > > > this repo:
On Mon, Apr 27, 2020 at 01:51:27PM +0200, Bastian Blank wrote:
> > It appears that a Debian AMI released by the Debian cloud team does not
> > exist on AWS GovCloud. While several options are provided in the AWS
> > GovCloud Marketplace by commercial vendors, having an AMI provided by the
> >
On Mon, Apr 27, 2020 at 01:05:34PM +0100, Wookey wrote:
> > > Someone asked me for a VM image recently, and I discovered we now
> > > make some available at: https://cloud.debian.org/images/cloud/
> >
> > There's new work in progress at: https://image-finder.debian.net/ That page
> > includes
On Tue, Apr 21, 2020 at 03:42:16PM -0700, Ihor Antonov wrote:
> - I often want to make sure that this is *really* the official AMI, some kind
> of
> link to the debian page that says "yes, this is indeed Debian's account ID
> would make me feel more reassured.
Yes, I agree that this is
On Tue, Apr 21, 2020 at 04:57:22PM +0200, Emmanuel Kasper wrote:
> YMMV, I use the following text in
> https://app.vagrantup.com/debian/
>
> Debian is a free Operating System for your laptop, server or embedded
> device. But it provides more than a pure OS: it comes with over 59000
> packages,
This is a continuation, in spirit, of a thread from last summer, but I'm
intentionally starting a new one here. [1]
This post will specifically focus on the Debian AWS Marketplace
listings, which are currently split across two AWS accounts [2][3]
We've got some inconsistencies between our
Package: cloud.debian.org
Severity: wishlist
As documented at
https://opensource.creativecommons.org/blog/entries/2020-04-03-nvmee-on-debian-on-aws/
and https://lists.debian.org/debian-cloud/2020/04/msg00015.html, it
would be helpful if we install meaningful /dev/xvd* or /dev/sd* symlinks
mapping
On Sat, Apr 04, 2020 at 10:17:20AM +0200, Thomas Goirand wrote:
> > The first two bugs are about nested virtualization. I like the idea of
> > deciding to support that or not. I don't know much about nested virt,
> > so I don't have a strong opinion. It seems pretty widely supported on
> > our
On Wed, Apr 01, 2020 at 03:15:37PM -0400, Noah Meyerhans wrote:
> There are open bugs against the cloud kernel requesting that
> configuration options be turned on there. [1][2][3]
> 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952108
> 2. https://bugs.debian.org/cgi-bin/b
On Fri, Apr 03, 2020 at 12:20:32PM +0200, Thomas Lange wrote:
> If adding a new kernel option does not change the boot time and the
> image size a lot and it's reasonable, then just go add it.
What I was trying to do was specifically define "a lot" and "it's
reasonable." I would rather not have
On Fri, Apr 03, 2020 at 06:16:33PM +0200, Jonathan Ballet wrote:
> On AWS Nitro instances, EBS volumes are exposed as NVMe block devices by
> the kernel on the /dev/nvme* paths.
>
> The AWS documentation "Identifying the EBS Device" says that the Linux
> kernel doesn't guarantee the creation
On Fri, Apr 03, 2020 at 02:03:16PM +, Jeremy Stanley wrote:
> And countless OpenStack service providers as well, though whether
> they do usually depends on if they've got new enough hardware, new
> enough host operating system, and what hypervisor backend they're
> using (for example,
On Thu, Apr 02, 2020 at 10:55:16AM -0700, Ross Vandegrift wrote:
> I don't think just saying "yes" automatically is the best approach. But
> I'm not sure we can come up with a clear set of rules. Evaluating the
> use cases will involve judgment calls about size vs functionality. I
> guess I
For buster, we generate a cloud kernel for amd64. For sid/bullseye,
we'll also support a cloud kernel for arm64. At the moment, the cloud
kernel is the only used in the images we generate for Microsoft Azure
and Amazon EC2. It's used in the GCE images we generate as well, but
I'm not sure
Control: tags -1 + upstream
> 2020-03-20 18:25:10,332 - url_helper.py[DEBUG]: [0/1] open
> 'http://169.254.169.254/latest/api/token' with {'url':
> 'http://169.254.169.254/latest/api/token', 'allow_redirects': True, 'method':
> 'PUT', 'timeout': 1.0, 'headers': {'User-Agent':
Package: cloud-init
Version: 20.1-1
Severity: important
Cloud-init 20.1 attempts to obtain an API token for use with Amazon EC2
instance metadata service (IMDS). On EC2, this operation should always
succeed, whether using IMDSv1 or v2, and cloud-init will always access
IMDS in v2 mode. However,
On Mon, Mar 16, 2020 at 10:46:49PM +0100, Thomas Goirand wrote:
> For the release team to accept a new version of 20.1, we need to test
> it. Happyaron already tested it with success on Aliyun, Tencent Cloud,
> and Huawei Cloud. We need to test it with Azure, GCE, AWS and OpenStack,
> with the
On Sat, Mar 07, 2020 at 05:56:43PM -0800, Noah Meyerhans wrote:
> > > So in case we'd be removing this dependency to satisfy your container
> > > use case (which is IMO very valid), we should carefully re-add a
> > > dependency on cloud-utils in our VM images.
> &g
On Sun, Mar 08, 2020 at 02:49:26AM +0100, Thomas Goirand wrote:
> On 3/7/20 11:53 PM, Thomas Goirand wrote:
> > So in case we'd be removing this dependency to satisfy your container
> > use case (which is IMO very valid), we should carefully re-add a
> > dependency on cloud-utils in our VM images.
Please see https://aws.amazon.com/marketplace/pp/B0859NK4HC for details.
Enjoy, and please leave reviews and ratings on the Marketplace.
noah
Package: src:cloud-utils
Version: 0.31-1
Severity: important
The ec2metadata command queries a well-known link-local endpoint
(169.254.169.254 in Amazon EC2) to obtain information about the instance
on which it runs. Last year, AWS released "IMDSv2" in an effort to
protect customers against some
On Fri, Jun 30, 2017 at 02:14:00PM +, Joonas Kylmälä wrote:
> We need to also take care of asking permission from the authors of
> Debian patches if they can be used under Apache v2 license.
I don't think there's anything copyrightable in any of those
contributions. Note that none of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Debian 9.12 (stretch) AMIs for Amazon EC2 are now available. See the 9.12
release announcement at https://www.debian.org/News/2020/2020020802 and
https://wiki.debian.org/Cloud/AmazonEC2Image/Stretch for more details.
The AMIs are owned by AWS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Debian 10.3 (buster) AMIs for Amazon EC2 are now available. See the 10.3
release announcement at https://www.debian.org/News/2020/20200208 and
https://wiki.debian.org/Cloud/AmazonEC2Image/Buster for more details.
The AMIs are owned by AWS accound
On Fri, Jan 24, 2020 at 12:39:53PM +, Marcin Kulisz wrote:
> I'd say in the worst case scenario you could host it on one of the old
> accounts
> and then migrate it out to the final one if it's not ready right now.
> Hopefully you've got this automated :-)
The only reason the old account
On Thu, Jan 23, 2020 at 10:15:33PM +0100, Andreas Tille wrote:
> > Currently the machine has 16GB memory 200GB sdd. From current usage
> > the minimum requirement is 8GB memory (16 is certainly better since
> > it is running a UDD clone and teammetrics database) and 80GB sdd.
> >
> > Is there
On Tue, Jan 14, 2020 at 11:56:14PM +0100, Tomasz Rybak wrote:
> Till now we were having meetings on Wednesdays, 19:00UTC.
> It was morning in USA, and evening (but after work) in Europe.
> Should we keep this time, or change it?
I am fairly flexible, at the moment. Any time within about ±3 hours
On Wed, Jan 22, 2020 at 05:15:55PM -0300, Sergio Morales wrote:
>Where I can find information about the release window for the official
>Debian AMI on AWS?
>Anyone knows of any blocker for this?
The AMIs are available today:
https://wiki.debian.org/Cloud/AmazonEC2Image/Buster
The
On Thu, Jan 09, 2020 at 05:22:17PM -0500, Noah Meyerhans wrote:
> I've confirmed that 4.19.87 with changes cherry-picked from 50ee7529ec45
> claims to have entropy at boot:
>
> admin@ip-172-31-49-239:~$ cloud-init analyze blame
> -- Boot Record 01 --
> 02.88900s (init-
On Tue, Jan 14, 2020 at 03:01:23PM +, Luca Filipozzi wrote:
> > If we want to extend the cloud kernel to support other services, we need
> > to do more than just enable virtio-rng. Somebody need to come up with a
> > complete list of devices that are needed for the service in question,
> >
On Fri, Jan 10, 2020 at 03:52:53AM +, Luca Filipozzi wrote:
> Two questions (pretend i'm 6yo):
>
> (1) why can't AWS offer virtio-rng support (other than "we already offer
> a RDRAND on amd64") and should Debian actively encourage their adding
> this support?
We can certainly ask. However,
On Thu, Jan 09, 2020 at 01:22:30PM -0500, Noah Meyerhans wrote:
> Our 5.4 kernel in sid does not suffer from a lack of entropy at boot on
> arm64 EC2 instances. I guess it could be due to the "random: try to
> actively add entropy rather than passively wait for it" that tytso
On Thu, Jan 09, 2020 at 04:57:24PM +, Luca Filipozzi wrote:
> > > >> I'd encourage those of you who are in position to make Amazon listen
> > > >> to get with the program and support virtio-rng. :-)
> > > > Noah: chances of AWS supporting virtio-rng?
> > > I wonder if the correct criterion
On Thu, Jan 09, 2020 at 01:18:24PM +0100, Adam Dobrawy wrote:
> >> I'd encourage those of you who are in position to make Amazon listen
> >> to get with the program and support virtio-rng. :-)
> > Noah: chances of AWS supporting virtio-rng?
> I wonder if the correct criterion for the cloud image
On Wed, Jan 08, 2020 at 07:18:33PM -0500, Theodore Y. Ts'o wrote:
> Another approach would be to cherry pick 50ee7529ec45 ("random: try to
> actively add entropy rather than passively wait for it"). I'm pretty
> confident that it's probably fine ("it's fine. it's fine. Really,
> it's fine") for
On Wed, Jan 08, 2020 at 07:18:33PM -0500, Theodore Y. Ts'o wrote:
> I was under the impression that Amazon provided virtio-rng support for
> its VM's? Or does that not apply for their arm64 Vm's? If they do
> support virtio-rng, it might just be an issue of building the cloud
> kernel with that
On Wed, Jan 08, 2020 at 09:24:25PM +, Jeremy Stanley wrote:
> > I've seen reactions like this, but never an explanation. Has anyone
> > written up the issues? Given that "fail to boot" isn't a workable
> > outcome, it'd be useful to know exactly what risks one accepts when
> > using haveged.
On Wed, Jan 08, 2020 at 12:50:04PM -0800, Ross Vandegrift wrote:
> I know of two other options:
> - pollinate
> - jitterentropy-rngd
>
> pollinate downloads seeds remotely, which feels wrong - and itself may
> require random numbers. I've never tried jitterentropy.
IMO these are roughly
On Wed, Jan 08, 2020 at 08:17:13PM +, Luca Filipozzi wrote:
> Every time I propose the use of haveged to resolve entropy starvation, I
> get reactions from crypto folks saying that it's not a valid solution.
> They invariably suggest that passing hardware RNG through to the VM is
> the
The buster arm64 images on Amazon EC2 appear to have insufficient
entropy at boot, and thus take several minutes to complete the boot
process.
There are a couple of potential fixes (or at least workarounds) for this
problem, but none is entirely perfect.
Option 1:
We add haveged to the arm64
On Sun, Dec 29, 2019 at 11:16:20PM +0100, Thomas Goirand wrote:
> >> Right, both bridge-utils and vlan are required to setup a bridge or
> >> vlan from *within* /etc/network/interfaces.
> >
> > That's not really true. bridge-utils and vlan add some additional
> > syntax, but everything can be
On Fri, Dec 27, 2019 at 10:33:16PM +0100, Christian Tramnitz wrote:
> Right, both bridge-utils and vlan are required to setup a bridge or
> vlan from *within* /etc/network/interfaces.
That's not really true. bridge-utils and vlan add some additional
syntax, but everything can be accomplished
On Sat, Dec 28, 2019 at 12:23:04PM +0100, Christian Tramnitz wrote:
> There is no workaround for the lack of vlan and bridge-utils though.
> It would be great it we could get those two included into the base
> image.
Both vlan and bridge-utils are legacy tools that are replaced by ip(8)
on modern
On Fri, Dec 27, 2019 at 11:39:00PM +0100, Thomas Goirand wrote:
> >> it is virtually impossible to use the image for cloud-init based
> >> deployment:
> >> While cloud-init can also install missing packages, the install would
> >> happen *after* package installation and network setup.
On Fri, Dec 27, 2019 at 02:16:05PM +0100, Christian Tramnitz wrote:
> However, I'm running into multiple problems staging a system through
> cloud-init.
> Without the packages
> - bridge-utils
> - vlan
> - gnupg2
> it is virtually impossible to use the image for cloud-init based deployment:
>
On Wed, Dec 25, 2019 at 12:39:19PM +0100, Thomas Goirand wrote:
> >> Though if we're to have a Buster branch, best would probably be to just
> >> call the branch debian/buster, and start the fork from the debian/18.3-6
> >> tag (so we have a meaningful history). I usually have the habit to never
>
On Wed, Dec 25, 2019 at 12:05:08PM +0100, Thomas Goirand wrote:
> I can see it, though I do expect we just work on a single Git
> repository, not with everyone forking everything. I've opened a buster
> branch on Salsa, using the debian/18.3-6 tag the entry point. We can
> start from there.
On Wed, Dec 25, 2019 at 12:42:49AM +0100, Thomas Goirand wrote:
> > In order to get that process started, I have constructed a "buster-p-u"
> > branch on salsa and begun testing cloud-init 19.3 on buster on AWS. [2]
>
> Though if we're to have a Buster branch, best would probably be to just
>
In our most recent meeting, we discussed possibly updating cloud-init in
stable. [1] This would be our first first time performing a
feature-update to a stable release, even though the stable release
managers some time ago indicated a willingness to let us do that.
In order to get that process
On Tue, Dec 10, 2019 at 08:46:08AM +0100, Tomasz Rybak wrote:
> I remind everyone that our next meeting will take place
> this Wednesday, 2019-12-11, at 19:00 UTC.
I won't be able to make this one because of work committments. Items
I would have wanted to discuss include:
1. Still no word on
On Mon, Dec 09, 2019 at 06:18:15PM +0200, Michael Kanchuker wrote:
>Is there an official image like with Jessie or Stretch?
Yes, details are at https://wiki.debian.org/Cloud/AmazonEC2Image/Buster
It is not yet available on the AWS Marketplace because we are still
blocked on some legal
On Fri, Dec 06, 2019 at 04:42:18PM +0100, Dick Visser wrote:
> I'm struggling to add custom nameservers to /etc/resolv.conf.
> The file gets overwritten on reboot, but I can't find out where this is done.
> Any ideas?
On our cloud images, resolv.conf is managed by dhclient, which is
invoked by
On Wed, Dec 04, 2019 at 01:16:27PM +1100, paul wrote:
> I'm reworking my old VPN server, and will use the Debian 10 AMI in AWS. I've
> noticed that predictable network interface names are enabled for t3 servers,
> but not t2 - I have test setup on a t2.micro and a t3.micro, and only the t3
> has
On Fri, Oct 18, 2019 at 08:35:34AM -0700, Ross Vandegrift wrote:
> On Fri, Oct 18, 2019 at 07:15:23AM +0200, Geert Stappers wrote:
> > Where to sent patches for `configure-pat.sh`?
>
> I don't know, I'm not familiar with it.
The canonical source for this script is the aws-vpc-nat package for
Hello.
On Fri, Oct 18, 2019 at 12:39:15AM +0200, Dick Visser wrote:
> I'm happily using the new Buster AMI, but I noticed that the image has
> consistent device naming enabled, so my instances have their single
> interface called "ens5".
Can you explain why this causes problems for you? We want
On Thu, Oct 10, 2019 at 03:02:48PM +0100, Marcin Kulisz wrote:
> > This is only email I got about this, so maybe I'm missing something
> > here. But - is this something we shold talk about during sprint next
> > week?
>
> IMO it makes sense to have a chat about it. If we want Debian to be more
>
On Tue, Oct 08, 2019 at 01:22:20PM -0400, Jonathan D. Proulx wrote:
> Do we have an attendee count for room setup, I've variously hear 13
> and 40...
The currently confirmed roster is at
https://wiki.debian.org/Sprints/2019/DebianCloud2019 and shows about 13
people. I wouldn't expect much
> Looking forward to official Buster image soon. Please let me know if I
> can be of any assistance.
Details about the official buster AMIs can be found at
https://wiki.debian.org/Cloud/AmazonEC2Image/Buster, and these AMIs are
available today.
The Marketplace listings, when they are available,
On Wed, Sep 18, 2019 at 10:22:17PM -0500, Stephen Gelman wrote:
> On Sun, Sep 08, 2019 at 07:49:45PM +0200, Bastian Blank wrote:
> > > If no-one shouts I will do the first release of Buster for AWS with both
> > > amd64 and arm64 tomorrow. Azure needs to be done anyway.
>
> Seems this didn’t
On Sun, Sep 08, 2019 at 07:49:45PM +0200, Bastian Blank wrote:
> If no-one shouts I will do the first release of Buster for AWS with both
> amd64 and arm64 tomorrow. Azure needs to be done anyway.
Do it. A lot of users will be happy to have buster AMIs. The remaining
points that were unresolved
On Tue, Sep 03, 2019 at 10:24:24AM +0100, kuLa wrote:
> > on my side I would have no objections with a removal.
>
> Should we actively ask for removal or wait till normal bugs will become RC and
> removal for all py2 packages is going to be compulsory?
> I personally am ok with both.
In my
On Mon, Sep 02, 2019 at 05:10:55PM +0200, Thomas Goirand wrote:
> State what? That we're supposed to build the cloud images on Casulana?
> As much as I know, that has always been what we were supposed to do. You
> alone decided that the gitlab's CI was the way to go.
Thomas, you seem to be under
On Sun, Sep 01, 2019 at 12:40:50PM +0200, Bastian Blank wrote:
> As mentioned during the last meeting, I would like to move the daily
> builds out of the main debian-cloud-images project. The new project
> reponsible for them would exist in a different group, so we don't longer
> need to guard
On Tue, Aug 27, 2019 at 10:32:41PM -0300, Antonio Terceiro wrote:
> > Do we have a list of stuff that runs on our old AWS account? As we need
> > to migrate all of this to our new engineering account, it would be nice
> > to actually know what runs there. It would be even better if we know
> >
On Sun, Aug 18, 2019 at 10:36:51AM +0100, Marcin Kulisz wrote:
> > I'm very much for sharing a big airbnb with any of you as well. I've
> > searched too, and it's a way cheaper than hotels indeed. I don't mind
> > walking a bit if it's to get the comfort of a private place. So, count
> > me in
On Sun, Aug 18, 2019 at 07:06:27AM +0100, kuLa wrote:
> >New regions on old AWS account: need root account for that.
>
> Above is not fully correct but anyway it's been sorted and Debian
> cloud images thanks to Noah should be now available in the new regions
> as well.
It's been sorted out for
On Thu, Aug 15, 2019 at 03:38:00PM -0400, Jonathan Proulx wrote:
> Accommodation
> -
> there's a lot of choice (and it is all fairly priicey
> unfortunately). As a visitor Noah may actually have better info than I
Last time I was in the neighborhood, I stayed at the Fairfield Inn &
On Thu, Aug 08, 2019 at 05:56:44PM -0700, Tarjei Husøy wrote:
> > The AMIs in the AWS marketplace should be launchable in the new regions.
> > See https://aws.amazon.com/marketplace/pp/B073HW9SP3 and let me know if
> > it'll work for you. The Marketplace AMIs are identical to the ones we
> >
> Amazon recently launched two new regions, Hong Kong (ap-east-1) and
> Bahrain (me-south-1). All new regions after March 20, 2019 come on a
> opt-in basis [1], thus you might not have seen them show up unless you
> saw the news when they were introduced. Would it be possible to have
> stretch
Package: cloud.debian.org
Severity: important
Control: submitter -1 Tarjei Husøy
Hi,
Amazon recently launched two new regions, Hong Kong (ap-east-1) and Bahrain
(me-south-1). All new regions after March 20, 2019 come on a opt-in basis [1],
thus you might not have seen them show up unless you
On Mon, Aug 05, 2019 at 05:57:57PM +0100, Marcin Kulisz wrote:
> > 1900 UTC makes it 2100 Geneva time. I'd very much prefer something
> > during work hours if possible. Or is it that the majority of us is doing
> > this away from office hours?
>
> I suggested this time having in mind that quite a
On Sun, Aug 04, 2019 at 10:15:32PM +0200, Tomasz Rybak wrote:
> > So I'd say Wednesday 7th of Aug at 1900UTC or maybe we could use
> > something like
> > doodle.com to coordinate this?
>
> I propose the same weekday (Wednesday) and hour (19:00 UTC),
> but let's move to next week (so 2019-08-14).
On Sat, Jul 20, 2019 at 11:26:38PM +0300, Mustafa Akdemir wrote:
>Can i use Debian GNU/Linux 9 (Stretch) AMI by upgrading to Debian
>GNU/Linux 10 (Buster) for Wordpress web site server until Debian GNU/Linux
>10 (Buster) AMI will be published. May it cause any problem by upgrading
>
On Wed, Jul 10, 2019 at 05:58:16PM +0300, Mustafa Akdemir wrote:
>When Debian 10 Buster AWS AMI will be created and added to AWS
>Marketplace?
Unfortunately, we have some administrative details to work out regarding
our publication account with AWS. It will be published as soon as we
On Sun, Jul 07, 2019 at 11:49:22PM +0200, Thomas Goirand wrote:
> Why must Debian users on Azure see the word "credativ"? To me, it's as
> if I uploaded the OpenStack image to cdimage.debian.org, with filename
> "openstack-debian-image-provided-by-zigo.qcow2". This feels completely
>
On Thu, Jul 04, 2019 at 11:49:13PM -0700, Noah Meyerhans wrote:
> amd64: ami-0776bf2e6645ef887
> arm64: ami-00781f5d2e3a6d2ab
Correction, the AMI IDs for ap-southeast-2 are:
amd64: ami-069a1bfa76dd19320
arm64: ami-00781f5d2e3a6d2ab
signature.asc
Description: PGP signature
On Tue, Jul 02, 2019 at 02:12:27PM -0700, Zach Marano wrote:
>I propose we start planning the next Debian Cloud Sprint.
Sounds like a plan. With DebConf coming up, I suspect there might be an
opportunity to do a bit of planning face-to-face, as well as via email
etc.
I've created a wiki
On Tue, May 21, 2019 at 11:14:02AM +0300, Eugeny Romanchenko wrote:
>Is it possible for you to add you current Marketplace image to the list of
>supported for t3a/m5a AWS instances?
I've submitted a request to update the AWS Marketplace listing. The new
listing will use the latest stretch
On Mon, May 20, 2019 at 03:38:25PM -0300, Arthur Diniz wrote:
>The first thing we did was a [2][1] [3]Low Fidelity Prototype, this was
>just a draft that we based to came up with the [4][2] [5]High Fidelity
>Prototype.
These look great!
>Also we think that is important that if
Control: severity -1 wishlist
> This is a historical convention, going back decades, that only the
> system administrators needs to run the programs in /sbin and
> /usr/sbin. So to avoid users getting confused when they might run
> those programs and get "permission denied", historically normal
On Mon, May 20, 2019 at 11:26:00AM +0200, Jorge Barata González wrote:
>Vagrant image debian/stretch64 v9.6.0
>/usr/sbin is not included by default in $PATH
>
>```
>vagrant@stretch:~$ service
>-bash: service: command not found
>vagrant@stretch:~$ /usr/sbin/service
>
Yesterday I published new stretch AMIs for Amazon EC2 for both arm64 and
amd64 architectures. The AMIs refresh all package version to those
included in Debian 9.9 (stretch), per the release announcement at
https://www.debian.org/News/2019/20190427
The AMI details, as usual, are available at
On Tue, Apr 30, 2019 at 06:25:47PM +0100, nSed rickm wrote:
>Hi my name is Sedrick I recently joined this mailing Iist to get to know
>more about the debian cloud team .I submited a proposal for GSoC with
>debian this year for the cloud image finder .I would like to catch up on
>
On Thu, Apr 04, 2019 at 07:51:22PM +0100, Marcin Kulisz wrote:
> > > > Let me know if this stalls; I can put you in touch with someone on
> > > > the Azure team.
> >
> > The Azure team asked some time ago for an email address to attach as
> > owner to those accounts. Also we need that to attach
On Thu, Apr 04, 2019 at 09:27:11AM +1300, Andrew Ruthven wrote:
> > > Would it be possible to move the Ec2 datasource up the list like "[
> > > NoCloud, AltCloud, ConfigDrive, OpenStack, Ec2, CloudStack,
> > > ${DIGITAL_OCEAN_SOURCE} MAAS, OVF, GCE, None ]"? This also seems to
> > > be in line
On Fri, Mar 29, 2019 at 03:09:50PM -0300, Lucas Kanashiro wrote:
> I think DebConf is the perfect place to share with the Debian community
> the work we have been doing and collect feedback :)
+1, this is a great idea. There should also be a BoF for people
interested in a more interactive
On Tue, Mar 26, 2019 at 12:25:12PM +0100, Lucas Nussbaum wrote:
> On https://hub.docker.com/_/debian, there's:
>
> > Where to file issues:
> > https://github.com/debuerreotype/docker-debian-artifacts/issues
>
> Are those official images? I'm surprised by official Debian images
> pointing to a
On Wed, Feb 20, 2019 at 05:17:11PM +0100, Konstantin wrote:
>Seems that Debian Stretch suffers from this
>bug [1]https://bugzilla.redhat.com/show_bug.cgi?id=1430511
>Please check if this patch can be added to cloud-init
>package
>
On Thu, Feb 07, 2019 at 10:17:53AM +0100, Thomas Goirand wrote:
> As a follow-up with the discussion about agent inside VMs, I wonder if
> we should install qemu-guest-agent inside our images. Normally, it
> provides what Ted was talking about: hooks for freezing filesystem,
> mysql, etc.
I don't
> > Noah
> > continue maintaining the stretch images for AWS
Still happening. I also did some driver backporting so we'll be able to
support the Amazon EC2 arm64-based instances with the next point
release. Buster will also support these instances.
> > developing buster aws images
Some progress
On Fri, Jan 25, 2019 at 02:56:53PM +0100, Bastian Blank wrote:
> While installing locales-all is pretty handy and avoids a lot of
> problems, I realized that is comes with a huge drawback: it makes the
> images a lot larger (230MB uncompressed and over 100MB compressed). It
> makes them so much
On Thu, Jan 10, 2019 at 07:22:18PM +0100, Lucas Nussbaum wrote:
> Would it make sense to publish an unofficial image and ask for feedback
> from users?
Let's wait until we have candidate stretch kernel packages that fix
#918330 and especially #918188. I believe at least the latter has a fix
on
On Thu, Jan 10, 2019 at 11:08:08AM +0100, Bastian Blank wrote:
> > > > Are there any plans to offer Debian AMIs for them?
> > > See
> > > https://salsa.debian.org/cloud-team/debian-cloud-images/merge_requests/46
> > I see that the MR has now been merged. What would be the next step?
>
> SPI
201 - 300 of 348 matches
Mail list logo
