Bug#1041900: cloud.debian.org: please publish arm64 vagrant boxes

[Ross Vandegrift]

Hi Lucas,

On Wed, Aug 02, 2023 at 10:38:24PM -0700, Ross Vandegrift wrote:
> The system tests need some easy fixes.  The end to end test tries to boot the
> image on the native arch.  It probably needs a feature to check if qemu is
> needed.  Time permitting, I plan to look at these in the next few days.

I have the tests fixed and added support for non-native arch E2E test runs with
qemu.  I've opened:
- system test fixes: 
https://salsa.debian.org/cloud-team/debian-vagrant-images/-/merge_requests/16
- arm64 pipeline support wip: 
https://salsa.debian.org/cloud-team/debian-vagrant-images/-/merge_requests/17

The first could be merged, the second needs some more work.

I'm not really clear on how to work on this pipeline - is the `debvagrant`
script available anywhere?

Ross

Bug#1041900: cloud.debian.org: please publish arm64 vagrant boxes

[Ross Vandegrift]

Hi Lucas,

On Wed, Jul 26, 2023 at 08:53:29PM +0200, Lucas Nussbaum wrote:
> On 24/07/23 at 22:00 -0700, Ross Vandegrift wrote:
> > I've been in touch with folks from the kdevops project [1].  They are 
> > looking
> > for more vagrant images for arm64.  Would it be possible to publish the 
> > arm64
> > boxes that debian-vagrant-images can build?
> > 
> > I started looking into this.  I'm pretty new to vagrant, but here's what I
> > learned so far:
> > 
> > - vagrant doesn't handle boxes with different architectures [2].  The advice
> >   seems to be to publish under a different name: e.g.  
> > "debian/testing-arm64".
> > 
> > - Building the arm64 box works just fine, and I can import it sucessfully.
> > 
> > - I'm trying to get vagrant to boot it, but still not quite there yet.
> 
> If you manage to get working images for arm64, I would then be happy to
> maintain them at the same time as the amd64 images.

I've confirmed the vagrant arm64 build works with qemu on amd64.  If you have
qemu-system-arm and qemu-efi-aarch64 installed, the following Vagrantfile
should boot up:

Vagrant.configure("2") do |config|
  config.vm.box = "debian/bookworm-arm64"

  config.vm.provider :libvirt do |libvirt|
libvirt.cpu_mode = "custom"
libvirt.cpu_model = "max"
libvirt.driver = "qemu"
libvirt.emulator_path = "/usr/bin/qemu-system-aarch64"
libvirt.graphics_type = "none"
libvirt.input :type => "mouse", :bus => "virtio"
libvirt.loader = "/usr/share/AAVMF/AAVMF_CODE.fd"
libvirt.nvram = "/var/lib/libvirt/qemu/nvram/vagrant.fd"
libvirt.machine_arch = "aarch64"
libvirt.machine_type = "virt"
libvirt.memory = 512
  end
end

The system tests need some easy fixes.  The end to end test tries to boot the
image on the native arch.  It probably needs a feature to check if qemu is
needed.  Time permitting, I plan to look at these in the next few days.

Ross

Bug#1041900: cloud.debian.org: please publish arm64 vagrant boxes

[Lucas Nussbaum]

Hi Ross,

On 24/07/23 at 22:00 -0700, Ross Vandegrift wrote:
> I've been in touch with folks from the kdevops project [1].  They are looking
> for more vagrant images for arm64.  Would it be possible to publish the arm64
> boxes that debian-vagrant-images can build?
> 
> I started looking into this.  I'm pretty new to vagrant, but here's what I
> learned so far:
> 
> - vagrant doesn't handle boxes with different architectures [2].  The advice
>   seems to be to publish under a different name: e.g.  "debian/testing-arm64".
> 
> - Building the arm64 box works just fine, and I can import it sucessfully.
> 
> - I'm trying to get vagrant to boot it, but still not quite there yet.

If you manage to get working images for arm64, I would then be happy to
maintain them at the same time as the amd64 images.

Lucas

Bug#1041900: cloud.debian.org: please publish arm64 vagrant boxes

[Ross Vandegrift]

Package: cloud.debian.org
Severity: wishlist
User: cloud.debian@packages.debian.org
Usertags: vagrant image
X-Debbugs-Cc: rvandegr...@debian.org

Hello,

I've been in touch with folks from the kdevops project [1].  They are looking
for more vagrant images for arm64.  Would it be possible to publish the arm64
boxes that debian-vagrant-images can build?

I started looking into this.  I'm pretty new to vagrant, but here's what I
learned so far:

- vagrant doesn't handle boxes with different architectures [2].  The advice
  seems to be to publish under a different name: e.g.  "debian/testing-arm64".

- Building the arm64 box works just fine, and I can import it sucessfully.

- I'm trying to get vagrant to boot it, but still not quite there yet.

Thanks,
Ross

[1] - https://github.com/mcgrof/kdevops/
[2] - https://github.com/hashicorp/vagrant/issues/12610

Re: Nightly Builds and Continous Delivery for Vagrant Boxes plans

[Emmanuel Kasper]

Le 06/06/2020 à 11:50, Bastian Blank a écrit :
> On Sat, Jun 06, 2020 at 11:00:36AM +0200, Emmanuel Kasper wrote:
>> Unfortunately the 250MB limit of artifacts prevent building a pipeline
>> with multiple stages like
>> create .box from raw -> test -> upload
>> as I hit the artifact limit size between each of these stages.
> 
> Please take a deeper look into what the rest of the cloud team image
> workflow does.  Maybe you find inspiration into how not to break
> everything.

Hi Bastian

I want to extend the following pipeline:
https://salsa.debian.org/cloud-team/debian-vagrant-images/pipelines/143272

'Build' stage is just a regular bin/debian-cloud-images fai build,
creating a tar.xz artifact.
In the 'Vagrant package' stage, I convert the raw disk image from the
tar.xz artifact to vmdk, add some Vagrant specific meta information, and
creates a tar.gz, as vmdk, tar and gzip are required by
VirtualBox/Vagrant for the .box format [1]

Due to
- more packages installed in the 'Build' stage
- tar.gz on a vmdk image being less efficient than tar.xz on a sparse
file, the .box files created by the 'Vagrant package' stage are bigger
than 250MB, in the 270MB-350MB range.

Where am I here breaking everything ? Am I missing something ?


> Now the important question, why do you want to clone everything?  Please
> work with the other people.

I cloned debian-cloud-images, among other reasons, because of the
points mentioned here
https://lists.debian.org/debian-cloud/2020/04/msg00034.html

But generally speaking since I am the one doing the Vagrant work, why
can't I choose in which repo I want to do that work ?

Emmanuel

[1] https://www.vagrantup.com/docs/boxes/format
-- 
You know an upstream is nice when they even accept m68k patches.
  - John Paul Adrian Glaubitz, Debian OpenJDK maintainer

Re: Nightly Builds and Continous Delivery for Vagrant Boxes plans

[Ross Vandegrift]

On Sat, Jun 06, 2020 at 11:50:39AM +0200, Bastian Blank wrote:
> On Sat, Jun 06, 2020 at 11:00:36AM +0200, Emmanuel Kasper wrote:
> > Unfortunately the 250MB limit of artifacts prevent building a pipeline
> > with multiple stages like
> > create .box from raw -> test -> upload
> > as I hit the artifact limit size between each of these stages.
> 
> Please take a deeper look into what the rest of the cloud team image
> workflow does.  Maybe you find inspiration into how not to break
> everything.

It would be more helpful to provide some info on how the workflow avoids the
salsa limits.  The only thing I know of is compressing the artifacts before
upload.  A brief description or a pointer to techniques in the source would be
enough to start.

> Now the important question, why do you want to clone everything?  Please
> work with the other people.

This isn't fair - our tools are not that easy to adopt.  If we want others to
adopt them, we need to work on improving the user experience for new folks that
just want to build images.

> > I will write the salsa admins if it's possible to increase the limit for the
> > two vagrant projects which would need it.
> 
> As Salsa admin I already told him that this is unlikely to happen.

I agree with this decision.  I've run into problems on my gitlab due to ci
artifact & job log storage - now I run into pain points due to this.

But is there a long term plan?  250M won't be enough forever.

> > As a solution of last resort, I've seen gitlab.com has an artifact limit of
> > 1GB. I would prefer of course to build on Debian infrastructure.
> 
> Well.  Dead cloud delegates, please tell Emmanuel about the rule set we
> developer over the last years.

I wish you had said what you were thinking instead of making me guess.  Here
goes anyway:

Emmanual, we decided that our workflow would build images on casulana and
upload them to pettersson or the providers for distribution.  I'm not sure why
Bastian thinks this is relevant, since you wouldn't us using our workflow.

Ross

Re: Nightly Builds and Continous Delivery for Vagrant Boxes plans

[Bastian Blank]

On Sat, Jun 06, 2020 at 11:00:36AM +0200, Emmanuel Kasper wrote:
> Unfortunately the 250MB limit of artifacts prevent building a pipeline
> with multiple stages like
> create .box from raw -> test -> upload
> as I hit the artifact limit size between each of these stages.

Please take a deeper look into what the rest of the cloud team image
workflow does.  Maybe you find inspiration into how not to break
everything.

Now the important question, why do you want to clone everything?  Please
work with the other people.

> I will write the salsa admins if it's possible to increase the limit for the
> two vagrant projects which would need it.

As Salsa admin I already told him that this is unlikely to happen.

> As a solution of last resort, I've seen gitlab.com has an artifact limit of
> 1GB. I would prefer of course to build on Debian infrastructure.

Well.  Dead cloud delegates, please tell Emmanuel about the rule set we
developer over the last years.

Regards,
Bastian

-- 
Spock: The odds of surviving another attack are 13562190123 to 1, Captain.

Re: Nightly Builds and Continous Delivery for Vagrant Boxes plans

[Emmanuel Kasper]

On 6/2/20 10:49 PM, Emmanuel Kasper wrote:

Hi

Now that I have working vagrant boxes with FAI, I'm starting to look at
nightly builds and continuous delivery of boxes to the vagrant cloud
(remember the "vagrant cloud" is just a disk image registry. The VMs are
run locally on your infrastructure)

Nightly Build:
--
I set a weekly build of Vagrant boxes at
https://salsa.debian.org/cloud-team/debian-vagrant-images/pipeline_schedules
which is working fine.
The only problem is that the boxes, which are gzip'ed qcow2 images, are
over the 250MB salsa artifact limit (they are around 300 MB) and thus
cannot be saved as artifacts when the build is complete.


Unfortunately the 250MB limit of artifacts prevent building a pipeline
with multiple stages like

create .box from raw -> test -> upload

as I hit the artifact limit size between each of these stages.

I will write the salsa admins if it's possible to increase the limit for 
the two vagrant projects which would need it.


As a solution of last resort, I've seen gitlab.com has an artifact limit 
of 1GB. I would prefer of course to build on Debian infrastructure.


--
You know an upstream is nice when they even accept m68k patches.
  - John Paul Adrian Glaubitz, Debian OpenJDK maintainer

Nightly Builds and Continous Delivery for Vagrant Boxes plans

[Emmanuel Kasper]

Hi

Now that I have working vagrant boxes with FAI, I'm starting to look at
nightly builds and continuous delivery of boxes to the vagrant cloud
(remember the "vagrant cloud" is just a disk image registry. The VMs are
run locally on your infrastructure)

Nightly Build:
--
I set a weekly build of Vagrant boxes at
https://salsa.debian.org/cloud-team/debian-vagrant-images/pipeline_schedules
which is working fine.
The only problem is that the boxes, which are gzip'ed qcow2 images, are
over the 250MB salsa artifact limit (they are around 300 MB) and thus
cannot be saved as artifacts when the build is complete.

I understand the 250MB is not something to negociate, as owtherwise
people would have already asked terabytes of artefacts, so what do you
people would advise me ?
Push those builds to https://cloud.debian.org/images/cloud/ ?
Find a VM under .debian.net to upload the boxes ?

Continuous Delivery:

I have set up a separate project, at
https://salsa.debian.org/vagrant-boxes-admin-team/debian-vagrant-boxes-release/
where the CI job will have an API key to upload testing boxes to the
Vagrant cloud.

I plan to run in these project every two week a build, which will push
testing boxes to the vagrant cloud ( Ubuntu is doing something similar)

Should I be worried when having the API key as a masked pipeline variable ?
Anything else I missed ?

Emmanuel

PS: Thanks to all involved in the gitlab setup of the cloud images, who
provided a great source of inspiration, and the bulk of the work.

-- 
You know an upstream is nice when they even accept m68k patches.
  - John Paul Adrian Glaubitz, Debian OpenJDK maintainer

Followup on Vagrant Boxes with debian cloud images

[Emmanuel Kasper]

Le 13/02/2020 à 14:17, Emmanuel Kasper a écrit :
> Hi
> 
> I had a look this week on how to add to Vagrant support to debian cloud
> images.
> The box users have been regularly complaining about a lack of up to
> dates box, and building and uploading for 2 hypervisors * 3
> distributions is a bit overkill to do at home on a ADSL connection.

So after a month of pushing things here or there I came to the
conclusion that it should be easier if I manage vagrant boxes
in a fork of debian-cloud-images

I noticed three things with makes creating vagrant boxes in the
debian-cloud-images repo difficult:

* first I stumbled in bin/debian-cloud-images in hard coded values. For
instance amd64 implies grub-cloud-amd64 as of
https://salsa.debian.org/cloud-team/debian-cloud-images/-/blob/master/src/debian_cloud_images/cli/build.py#L69

grub-cloud-amd64 is however not needed for Vagrant boxes, which do not
provide facility for a serial console, and Vagrant with the VirtualBox
provider does not even boot with our kernel when a serial console is
configured but a virtual serial port is missing (the default configuration)

* after the disk image creation, Vagrant needs a special packaging step,
before the box is booted in the hypervisor, but the python build script
only has such a converting step when uploading. Up to now I have been
running E2E tests on the created box before uploading. It is unclear how
this could fit in the current workflow.

* also a minor problem, the cloud images include a defined package set,
whereas I rely on package priorities to install what comes in a box.

The idea of having a common git repo is nice, but I think it is
better to have common practises ( building on salsa, pushing a
release build on cloud.debian.org ), rather than sharing a codebase I
would pollute with

if arch == 'amd64':
if vendor == 'vagrant':
return 'GRUB_PC'
else:
return 'GRUB_CLOUD_AMD64'

and waiting for merge requests to be rejected.

In the end it comes all about the destination of the disk image. With
Vagrant you're supposed to run the disk image locally as a portable dev
environment, so it differs a lot from the need of having a remote secure
minimal server.

So now that the initial fai work is done (I have working virtualbox and
libvirt vagrant images which build with the gitlab runners), my highest
priority will be to add the e2e testing suite I had with vagrant-boxes
and prepare a new upload so I can close
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930367

Emmanuel

-- 
You know an upstream is nice when they even accept m68k patches.
  - John Paul Adrian Glaubitz, Debian OpenJDK maintainer

Bug#940587: cloud.debian.org: additional Vagrant boxes with puppet/ansible pre-installed?

[Emmanuel Kasper]

Am 18.09.2019 um 21:08 schrieb Geert Stappers:

On Wed, Sep 18:

On 2019-09-18 1:36 a.m., Geert Stappers wrote:

On Tue, Sep 17, 2019 at 10:52:54AM -0400, Gabriel Filion wrote:

vagrant boxes images that would have puppet/ansible pre-installed



Hello Gabriel !

Thanks for your interest for the vagrant boxes.

Creating a different box for a single debian package is overkill IMHO,  
so for your use case, I suggest to add via apt-get puppet to a running 
instance of the box, then its only a single command (vagrant repackage) 
and you can distribute it via http or a shared file system ( the boxes 
don't need to be on the vagrant cloud)

Bug#940587: cloud.debian.org: additional Vagrant boxes with puppet/ansible pre-installed?

[Geert Stappers]

On Wed, Sep 18:
> On 2019-09-18 1:36 a.m., Geert Stappers wrote:
> > On Tue, Sep 17, 2019 at 10:52:54AM -0400, Gabriel Filion wrote:
> >> vagrant boxes images that would have puppet/ansible pre-installed
> > There is https://cloudinit.readthedocs.io/en/latest/
> > But it lacks what it makes it tick.
> > 
> > Nowhere is documented
> > * how it starts (what triggers the start)
> > * how "client" finds "server"
> > * why "client" trusts "server"
> 
} I don't quite understand how this is related to building Vagrant boxes.

It isn't indeed.  Now the uncensored version:

|It feels wrong to put specific orchestartion components in all images
|when one knowns there is a generic component (cloudinit) that solves
|the problem. Sadly is cloudinit poorly documented.
|So now to choose from two problems.
|My choice would be going for understanding "cloudinit"


Good luck with your approach.


Regards
Geert Stappers


signature.asc
Description: PGP signature

Bug#940587: cloud.debian.org: additional Vagrant boxes with puppet/ansible pre-installed?

[Gabriel Filion]

Hi,

On 2019-09-18 1:36 a.m., Geert Stappers wrote:
> On Tue, Sep 17, 2019 at 10:52:54AM -0400, Gabriel Filion wrote:
>> I was wondering if folks maintaining the vagrant boxes would be willing to
>> publish additional images that would have puppet/ansible pre-installed with
>> the debian packages from each release's package repository?
> 
> I also don't understand how cloudinit works.
> 
> There is https://cloudinit.readthedocs.io/en/latest/
> But it lacks what it makes it tick.
> 
> Nowhere is documented
> * how it starts (what triggers the start)
> * how "client" finds "server"
> * why "client" trusts "server"

I don't quite understand how this question is related to building
Vagrant boxes.

According to the documentation[0] the boxes are generated using a Packer
template, and cloudinit is mentioned nowhere on that wiki page.

[0]: https://wiki.debian.org/Teams/Cloud/VagrantBaseBoxes#Build_process



signature.asc
Description: OpenPGP digital signature

Bug#940587: cloud.debian.org: additional Vagrant boxes with puppet/ansible pre-installed?

[Geert Stappers]

On Tue, Sep 17, 2019 at 10:52:54AM -0400, Gabriel Filion wrote:
> I was wondering if folks maintaining the vagrant boxes would be willing to
> publish additional images that would have puppet/ansible pre-installed with
> the debian packages from each release's package repository?

I also don't understand how cloudinit works.

There is https://cloudinit.readthedocs.io/en/latest/
But it lacks what it makes it tick.

Nowhere is documented
* how it starts (what triggers the start)
* how "client" finds "server"
* why "client" trusts "server"


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#940587: cloud.debian.org: additional Vagrant boxes with puppet/ansible pre-installed?

[Gabriel Filion]

Package: cloud.debian.org
Severity: wishlist

Hi there,

I've been holding back on using the debian/* boxes with vagrant mostly since
there's no puppet pre-installed in the boxes.

I know that, as documented in the wiki, I can install puppet with a shell
provisioner, but doing that on every boot makes things very much slower.

I could also start from the vanilla box, install puppet and then repackage
into a new box locally, but the point of using a public box is so that other
contributers can start with exactly the same environment.

I'm also aware that pre-installing those would make the images much bigger,
and I can see the point of having a very tiny completely vanilla debian image.

I was wondering if folks maintaining the vagrant boxes would be willing to
publish additional images that would have puppet/ansible pre-installed with
the debian packages from each release's package repository?

cheers!

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.utf8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_CA.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Re: systemd-networkd and networking service in vagrant boxes

[Nicolas Quiniou-Briand]

Hello Emmanuel,

On 2019-06-08 11:24 a.m., Emmanuel Kasper wrote:

This is unfortunately a known behaviour and also a bug.
VirtualBoxes images use ifupdown for network configuration, and Libvirt
images use systemd-networkd, due to a bug in vmdeboostrap.

Can you submit a bug report against the
cloud.debian.org package so we can properly track the issue ?


Thanks for your feedback. Yes I will do it.
--
Nicolas Quiniou-Briand
Jabber/XMPP : n...@azyx.fr

Re: systemd-networkd and networking service in vagrant boxes

[Emmanuel Kasper]

Le 07/06/2019 à 16:30, Nicolas Quiniou-Briand a écrit :
> Hello,
> 
> I'm using Vanilla Debian base boxes from
> https://app.vagrantup.com/debian/ with libvirt and Virtualbox providers.
> 

> 
> I compared a fresh Debian stretch netinstall not managed by Vagrant and
> I saw that `systemd-networkd` service was disabled and stopped too.
> 
> I'm writing this email because I got a bug [0] when using Vanilla Debian
> base boxes with the DebOps project [1] and I think I found the root
> cause [2].
> 
> Thanks a lot.
> 
> [0] https://github.com/debops/debops/issues/629
> [1] https://debops.org
> [2] https://github.com/debops/debops/issues/629#issuecomment-499774400


Hi Nicolas
Thanks for your interest with the debian vagrant boxes, and thanks for
reaching upstream, always a nice thing to do :) ( i read your bug report
in details )

> I noticed a difference between providers for the same box
> (debian/stretch64).
> * with libvirt provider, `systemd-networkd` service is enabled and
> started after first boot of VM.
> * with virtualbox provider, `systemd-networkd` service is disabled and
> stopped after first boot of VM.
>
> I would like to know if this an expected behavior or a bug.


This is unfortunately a known behaviour and also a bug.
VirtualBoxes images use ifupdown for network configuration, and Libvirt
images use systemd-networkd, due to a bug in vmdeboostrap.

Can you submit a bug report against the
cloud.debian.org package so we can properly track the issue ?





-- 
You know an upstream is nice when they even accept m68k patches.
  - John Paul Adrian Glaubitz, Debian OpenJDK maintainer

systemd-networkd and networking service in vagrant boxes

[Nicolas Quiniou-Briand]

Hello,

I'm using Vanilla Debian base boxes from 
https://app.vagrantup.com/debian/ with libvirt and Virtualbox providers.


I noticed a difference between providers for the same box 
(debian/stretch64).
* with libvirt provider, `systemd-networkd` service is enabled and 
started after first boot of VM.
* with virtualbox provider, `systemd-networkd` service is disabled and 
stopped after first boot of VM.


I would like to know if this an expected behavior or a bug.

I compared a fresh Debian stretch netinstall not managed by Vagrant and 
I saw that `systemd-networkd` service was disabled and stopped too.


I'm writing this email because I got a bug [0] when using Vanilla Debian 
base boxes with the DebOps project [1] and I think I found the root 
cause [2].


Thanks a lot.

[0] https://github.com/debops/debops/issues/629
[1] https://debops.org
[2] https://github.com/debops/debops/issues/629#issuecomment-499774400
--
Nicolas Quiniou-Briand
Messagerie instantanée (Jabber) : n...@azyx.fr
Tél : 06 75 84 56 74

Re: Updated Vagrant Boxes for Wheezy

[Emmanuel Kasper]

>  Message transféré 
> Sujet : Debian Wheezy: Vagrant boxes
> Date : Thu, 30 May 2019 13:29:25 +0200
> De : Alexander Nitsche | e-pixler NEW MEDIA GmbH
> 
> Pour : m...@debian.org
> 
> Hello Emmanuel,
> 
> i am Alex, a PHP developer from Berlin and using your vagrant boxes
> heavily for local development. Thank you very much for your effort! Now,
> as i am maintaining projects for older web servers as well, i recently
> wanted to rebuild a local debian wheezy machine (vagrant+virtualbox) but
> for the first time in years it failed due to the change of repository
> urls of the debian sources for wheezy to
> http://archive.debian.org/debian/ . The current building process
> complains about
> 
> Reading package lists...
> Building dependency tree...
> Reading state information...
> ..
> After this operation, 115 MB of additional disk space will be used.
> Err http://security.debian.org/ wheezy/updates/main libc-dev-bin amd64
> 2.13-38+deb7u11
>   404  Not Found [IP: 151.101.12.204 80]
> ..

Hi Alex

First thanks for your interest for the Vagrant base boxes

Debian Wheezy is outside the scope of Debian and LTS releases
according to
https://wiki.debian.org/LTS
LTS supported finished in Mai 2018

time to upgrade your servers :)
remember debian supports inplace upgrade of servers ( no reinstall
necessary ) so it can be less hassle than expected

otherwise you would need to have a look at the vagrant-setup script
section in
https://salsa.debian.org/cloud-team/vagrant-boxes/blob/master/packer-virtualbox-vagrant/wheezy.json,
and update the script to select archive.debian.org as package repository

as this release is not supported by debian I can provide general
guidance but you'll have to do the changes yourself

I'll probably remove these non working boxes in a short while anyway (
they're not building anymore too)


Emmanuel

Updated Vagrant Boxes for Wheezy

[Emmanuel Kasper]

Forwarding to debian-cloud with original author agreement, so we can
have an open discussion.


 Message transféré 
Sujet : Debian Wheezy: Vagrant boxes
Date : Thu, 30 May 2019 13:29:25 +0200
De : Alexander Nitsche | e-pixler NEW MEDIA GmbH

Pour : m...@debian.org

Hello Emmanuel,

i am Alex, a PHP developer from Berlin and using your vagrant boxes
heavily for local development. Thank you very much for your effort! Now,
as i am maintaining projects for older web servers as well, i recently
wanted to rebuild a local debian wheezy machine (vagrant+virtualbox) but
for the first time in years it failed due to the change of repository
urls of the debian sources for wheezy to
http://archive.debian.org/debian/ . The current building process
complains about

Reading package lists...
Building dependency tree...
Reading state information...
..
After this operation, 115 MB of additional disk space will be used.
Err http://security.debian.org/ wheezy/updates/main libc-dev-bin amd64
2.13-38+deb7u11
  404  Not Found [IP: 151.101.12.204 80]
..

and then cancels.

Will you provide an adaption of the current wheezy vagrant box with
updated debian repository urls? I would be very happy about it.

Thank you and greetings
Alex

Re: Vagrant boxes for 9.5.0

[Emmanuel Kasper]

Le 19/08/2018 à 11:39, Carlos Rodrigues a écrit :
> Hi there,
> 
> Is there any reason for the "debian/stretch64" 9.4.0 boxes to remain
> tagged as the currently released version even though 9.5.0 has been
> there for a month?
> 
> Best regards,
> 

I just released 9.5.0 for virtualbox and libvirt.
Regards
Emmanuel

Re: Vagrant boxes for 9.5.0

[Emmanuel Kasper]

Am 19. August 2018 11:39:45 MESZ schrieb Carlos Rodrigues 
:
>Hi there,
>
>Is there any reason for the "debian/stretch64" 9.4.0 boxes to remain
>tagged as the currently released version even though 9.5.0 has been
>there for a month?
>
>Best regards,
>
>-- 
>Carlos Rodrigues

Hi Carlos
Thanks for bringing this up.
It looked like the 9.5 boxes where built and uploaded to the vagrant cloud 
backend, but we forgot the manual step of releasing them. I'll look into this 
next week, as I am away from keyboard and computer at the moment.
Manu

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: Problem creating Vagrant boxes

[Christopher Huhn]

Hi Emmanuel,


fai-cloud-images is rather a work in progress for Vagrant Images,
you> should look at debian-vm-templates for the working stuff.


OK, but my plan is to merge the config_space of fai-cloud-images into
our existing FAI config space to create custom VM images that match our
existing bare-metal and production VM images.
As a side effect this could serve as a CI setup for our FAI configs
which is a constant source of regression in our infrastructure management.


After the initial debootstrap further package installations fail
because DNS resolution does not work inside the chroot, eg.:

[..]

We are not using systemd-resolved in our setup and I cannot easily
test it at the moment.


vmdeboostrap has the unfornate choice of using systemd-networkd as
the default, when everything else is still us ifupdown, and I don't a
lot about about DNS resolution is supposed to take place.


fai-cloud-images can produce working VM images if I run it inside a
standard debian/stretch64 vagrant image (with systemd-resolved).
I assume that also applies to fai-cloud-images.

systemd-resolved runs a local DNS server on the private IP 127.0.0.53
(you can test it with `host www.debian.org 127.0.0.53`).
I assume that the debootstrapped system uses the parent hosts
systemd-resolved when available.

I added a small patch to vagrant-setup that copies the hosts resolv.conf
into the image. This fixes the issue for me and should work whether or
not systemd-resolved is used.

Kind regards

Christopher
diff --git a/helpers/vagrant-setup b/helpers/vagrant-setup
index 2754d41..4cd906f 100755
--- a/helpers/vagrant-setup
+++ b/helpers/vagrant-setup
@@ -19,6 +19,9 @@ fi
 
 set -x
 
+mkdir -p $fs/run/systemd/resolve
+cp /etc/resolv.conf $fs/run/systemd/resolve/resolv.conf
+
 ###
 # upgrade Debian images as the LXC template does not do it.
 ###
@@ -90,6 +93,7 @@ echo 'PasswordAuthentication no' >> $fs/etc/ssh/sshd_config
 ###
 chroot $fs apt-get clean
 rm -f $fs/usr/sbin/policy-rc.d
+rm -vf $fs/run/*
 
 # make sure /etc/machine-id is generated on next book
 # /etc/machine-id needs to be unique so multiple systemd-networkd dhcp clients

Re: Re: Problem creating Vagrant boxes

[Joonas Kylmälä]

Hi,

I couldn't reproduce the DNS resolution problem anymore. They both use
the same deb.debian.org package repository so when I noticed this
problem about ~1 month ago I ran "sudo apt update" on the 9.2.0 image it
wasn't able to fetch the packages but with 9.1.0 it was. I have no idea
what made it working now. Well, at least now I can start using the new
9.2 image :)

Joonas

Re: Problem creating Vagrant boxes

[Emmanuel Kasper]

Le 18/11/2017 à 23:50, Joonas Kylmälä a écrit :
> I had also the DNS resolution problem with the latest Debian Stretch
> VirtualBox image, 9.2, which was downloaded from the Vagrant Cloud.

Hi Joonas
Before uploading the boxes, we run a test suite, which among other
things, downloads a package from the debian repos, which should test
that the DNS resolution

If you can reproduce the issue, can you submit a bug report in the
debian-cloud package ?

Emmanuel

Re: Problem creating Vagrant boxes

[Joonas Kylmälä]

I had also the DNS resolution problem with the latest Debian Stretch
VirtualBox image, 9.2, which was downloaded from the Vagrant Cloud.

Emmanuel Kasper:
> Le 17/11/2017 à 12:53, Christopher Huhn a écrit :
>> Dear Debian Cloud Team,
>>
>> on the occasion of re-investigating vagrant I stumpled upon the
>> debian-vm-templates and the fai-cloud-images git repos.
>> Esp. the latter is exactly what I was looking for. Nice!> Anyhow I have the 
>> following problem (on a Stretch system) with both
>> `make stretch-image-vagrant`in fai-cloud-images and
>> `make -C vmdebootstrap-libvirt-vagrant stretch` in debian-vm-templates.
>> (This is no surprise as debian-vm-templates/helpers/vagrant-setup and
>> fai-cloud-images/config_space/scripts/VAGRANT/20-setup are more or less
>> identical.)
> 
> Hi Christopher
> fai-cloud-images is rather a work in progress for Vagrant Images, you
> should look at debian-vm-templates for the working stuff.
> I could not reproduce your problem with debian-vm-templates and
> vmdeboostrap 1.8-1 ( dpkg -l version)
> 
>>
>> After the initial debootstrap further package installations fail because
>> DNS resolution does not work inside the chroot, eg.:
>>
>>> Enabling systemctl-resolved for DNS
>>> Running customize script
>>> /data.local1/debian-vm-templates/vmdebootstrap-libvirt-vagrant/../helpers/vagrant-setup
>>>
>>> [..]
>>> + chroot /tmp/tmpUo5_fS apt-get update
>>> Err:1 http://httpredir.debian.org/debian stretch InRelease
>>>   Temporary failure resolving 'httpredir.debian.org'
>>> Reading package lists... Done
>>> W: Failed to fetch
>>> http://httpredir.debian.org/debian/dists/stretch/InRelease  Temporary
>>> failure resolving 'httpredir.debian.org'
>>> [..]
>>> + chroot /tmp/tmpUo5_fS apt-get install -qy dctrl-tools
>>> [..] > Err:1 http://httpredir.debian.org/debian stretch/main amd64 
>> dctrl-tools amd64 2.24-2+b1
>>>   Temporary failure resolving 'httpredir.debian.org'
>>> E: Failed to fetch
>>> http://httpredir.debian.org/debian/pool/main/d/dctrl-tools/dctrl-tools_2.24-2+b1_amd64.deb
>>>  
>>> Temporary failure resolving 'httpredir.debian.org'
>>> [..]
>>> EEEK! Something bad happened...
>>
>> Is that a known problem?
>>
>> My fix would be to drop the hosts /etc/resolv.conf to
>> /run/systemd/resolve/resolv.conf inside the image.
>>
>> Reading the manpage of systemd-resolved it looks like this problem may
>> be circumvented/hidden by running systemd-resolved on the host the image
>> is built on. Probably the client will implicitly use 127.0.0.53 as its
>> DNS server?
>>
>> We are not using systemd-resolved in our setup and I cannot easily test
>> it at the moment.
>> In general it would be nice if the scripts work without relying on a
>> specific host setup anyhow.
> 
> vmdeboostrap has the unfornate choice of using systemd-networkd as the
> default, when everything else is still us ifupdown, and I don't a lot
> about about DNS resolution is supposed to take place.
> 
> But I am not sure that the problem comes from having systemd-resolved on
> the host. I don't have it installed and it is working here ;)
> 
> Emmanuel
> 

Re: Problem creating Vagrant boxes

[Emmanuel Kasper]

Le 17/11/2017 à 12:53, Christopher Huhn a écrit :
> Dear Debian Cloud Team,
> 
> on the occasion of re-investigating vagrant I stumpled upon the
> debian-vm-templates and the fai-cloud-images git repos.
> Esp. the latter is exactly what I was looking for. Nice!> Anyhow I have the 
> following problem (on a Stretch system) with both
> `make stretch-image-vagrant`in fai-cloud-images and
> `make -C vmdebootstrap-libvirt-vagrant stretch` in debian-vm-templates.
> (This is no surprise as debian-vm-templates/helpers/vagrant-setup and
> fai-cloud-images/config_space/scripts/VAGRANT/20-setup are more or less
> identical.)

Hi Christopher
fai-cloud-images is rather a work in progress for Vagrant Images, you
should look at debian-vm-templates for the working stuff.
I could not reproduce your problem with debian-vm-templates and
vmdeboostrap 1.8-1 ( dpkg -l version)

> 
> After the initial debootstrap further package installations fail because
> DNS resolution does not work inside the chroot, eg.:
> 
>> Enabling systemctl-resolved for DNS
>> Running customize script
>> /data.local1/debian-vm-templates/vmdebootstrap-libvirt-vagrant/../helpers/vagrant-setup
>>
>> [..]
>> + chroot /tmp/tmpUo5_fS apt-get update
>> Err:1 http://httpredir.debian.org/debian stretch InRelease
>>   Temporary failure resolving 'httpredir.debian.org'
>> Reading package lists... Done
>> W: Failed to fetch
>> http://httpredir.debian.org/debian/dists/stretch/InRelease  Temporary
>> failure resolving 'httpredir.debian.org'
>> [..]
>> + chroot /tmp/tmpUo5_fS apt-get install -qy dctrl-tools
>> [..] > Err:1 http://httpredir.debian.org/debian stretch/main amd64 
> dctrl-tools amd64 2.24-2+b1
>>   Temporary failure resolving 'httpredir.debian.org'
>> E: Failed to fetch
>> http://httpredir.debian.org/debian/pool/main/d/dctrl-tools/dctrl-tools_2.24-2+b1_amd64.deb
>>  
>> Temporary failure resolving 'httpredir.debian.org'
>> [..]
>> EEEK! Something bad happened...
> 
> Is that a known problem?
> 
> My fix would be to drop the hosts /etc/resolv.conf to
> /run/systemd/resolve/resolv.conf inside the image.
> 
> Reading the manpage of systemd-resolved it looks like this problem may
> be circumvented/hidden by running systemd-resolved on the host the image
> is built on. Probably the client will implicitly use 127.0.0.53 as its
> DNS server?
> 
> We are not using systemd-resolved in our setup and I cannot easily test
> it at the moment.
> In general it would be nice if the scripts work without relying on a
> specific host setup anyhow.

vmdeboostrap has the unfornate choice of using systemd-networkd as the
default, when everything else is still us ifupdown, and I don't a lot
about about DNS resolution is supposed to take place.

But I am not sure that the problem comes from having systemd-resolved on
the host. I don't have it installed and it is working here ;)

Emmanuel

-- 
You know an upstream is nice when they even accept m68k patches.
  - John Paul Adrian Glaubitz

Problem creating Vagrant boxes

[Christopher Huhn]

Dear Debian Cloud Team,

on the occasion of re-investigating vagrant I stumpled upon the 
debian-vm-templates and the fai-cloud-images git repos.

Esp. the latter is exactly what I was looking for. Nice!

Anyhow I have the following problem (on a Stretch system) with both
`make stretch-image-vagrant`in fai-cloud-images and
`make -C vmdebootstrap-libvirt-vagrant stretch` in debian-vm-templates.
(This is no surprise as debian-vm-templates/helpers/vagrant-setup and 
fai-cloud-images/config_space/scripts/VAGRANT/20-setup are more or less 
identical.)


After the initial debootstrap further package installations fail because 
DNS resolution does not work inside the chroot, eg.:



Enabling systemctl-resolved for DNS
Running customize script 
/data.local1/debian-vm-templates/vmdebootstrap-libvirt-vagrant/../helpers/vagrant-setup

> [..]

+ chroot /tmp/tmpUo5_fS apt-get update
Err:1 http://httpredir.debian.org/debian stretch InRelease
  Temporary failure resolving 'httpredir.debian.org'
Reading package lists... Done
W: Failed to fetch http://httpredir.debian.org/debian/dists/stretch/InRelease  
Temporary failure resolving 'httpredir.debian.org'

> [..]

+ chroot /tmp/tmpUo5_fS apt-get install -qy dctrl-tools
[..] > Err:1 http://httpredir.debian.org/debian stretch/main amd64 

dctrl-tools amd64 2.24-2+b1

  Temporary failure resolving 'httpredir.debian.org'
E: Failed to fetch 
http://httpredir.debian.org/debian/pool/main/d/dctrl-tools/dctrl-tools_2.24-2+b1_amd64.deb
  Temporary failure resolving 'httpredir.debian.org'
[..]
EEEK! Something bad happened...


Is that a known problem?

My fix would be to drop the hosts /etc/resolv.conf to
/run/systemd/resolve/resolv.conf inside the image.

Reading the manpage of systemd-resolved it looks like this problem may 
be circumvented/hidden by running systemd-resolved on the host the image 
is built on. Probably the client will implicitly use 127.0.0.53 as its 
DNS server?


We are not using systemd-resolved in our setup and I cannot easily test 
it at the moment.
In general it would be nice if the scripts work without relying on a 
specific host setup anyhow.


Kind regards
Christopher

Re: Vagrant Boxes

[Joonas Kylmälä]

Hi,

Emmanuel Kasper:
> I see also that you expressed interess to create Vagrant Boxes for
> Docker. We haven't start anything there but I would be interesting to
> hear if such a thing is possible with fai[1] the tool we evaluate to use
> in the future for all boxes.
> If you want to play around with that, you can clone the git repo at
> https://anonscm.debian.org/cgit/cloud/fai-cloud-images.git/
> and start to hack.

I researched a bit on the topic. Vagrant Boxes seem useless because that
would mean there is some virtual machine running behind (like
Virtualbox), and <https://www.vagrantup.com/docs/docker/boxes.html>
states that Vagrant Boxes are not required for Docker images to be
running. However, it would still be nice to have such Debian Docker
*image* that supports all the same things that current Debian Vagrant
Boxes do (for example ssh so that vagrant provisioning could be used).
Images at <https://hub.docker.com/_/debian/> currently miss these features.

I will update you with more info if I think this is feasible to do and
also if with Fai or not.

Joonas

Re: Vagrant Boxes

[Emmanuel Kasper]

On 08/24/2017 06:25 AM, Joonas Kylmälä wrote:
> Antonio Terceiro:
>> https://app.vagrantup.com/debian/boxes/stretch64
>>
>> ^ libvirt and lxc are already available. what exactly are you missing?
> 
> Latest version of Jessie (and Testing) is missing them. I see there has
> been lxc and libvirt previously so I thought maybe something happened
> (like some incombability) with the image build scripts?
> 

Hi Joonas
There is work on progress building testing boxes, so it will happen at
some times, but probably not until we have continuous integration set up.

I see also that you expressed interess to create Vagrant Boxes for
Docker. We haven't start anything there but I would be interesting to
hear if such a thing is possible with fai[1] the tool we evaluate to use
in the future for all boxes.
If you want to play around with that, you can clone the git repo at
https://anonscm.debian.org/cgit/cloud/fai-cloud-images.git/
and start to hack.

[1]https://fai-project.org/

Re: Vagrant Boxes

[Joonas Kylmälä]

Antonio Terceiro:
> https://app.vagrantup.com/debian/boxes/stretch64
> 
> ^ libvirt and lxc are already available. what exactly are you missing?

Latest version of Jessie (and Testing) is missing them. I see there has
been lxc and libvirt previously so I thought maybe something happened
(like some incombability) with the image build scripts?

Joonas

Vagrant Boxes

[Joonas Kylmälä]

Hi,

In Vagrant Cloud I see mostly Virtualbox Vagrant Boxes. Can I somehow
help with getting some free providers working with the image, like
libvirt, lxc or docker? Is the problem that there is no packer setup for
the other Vagrant providers? So if I would create those packer setups
and send a patch would that be the way to go?

Also, is it possible to open the TODO list [1] with free software
somehow (or if someone could tell me what the items in that list are)?

Joonas

[1] https://trello.com/b/lVRI6QJt/offical-debian-vagrant-base-boxes

Bug#868679: marked as done (cloud.debian.org: Multiple identical vagrant boxes appear as the same machine to libvirt's dnsmasq dhcp provider)

[Debian Bug Tracking System]

Your message dated Thu, 27 Jul 2017 17:33:53 -0300
with message-id <20170727203353.sjz7v32dkqn44...@debian.org>
and subject line Re: Bug#868679: (no subject)
has caused the Debian Bug report #868679,
regarding cloud.debian.org: Multiple identical vagrant boxes appear as the same 
machine to libvirt's dnsmasq dhcp provider
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
868679: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868679
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: cloud.debian.org
Severity: important
Tags: newcomer

Dear Maintainer,

   * What led up to the situation?

I've been having problems using the supplied vagrant boxes in more complex
setups (where a Vagrantfile brings up more than one identical
machine). They effectively end up stealing each other's management IP
address (and potentially others that are DHCP managed).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Use a Vagrantfile a bit like this:

[[[
ENV['VAGRANT_DEFAULT_PROVIDER'] = 'libvirt'

def main()
  Vagrant.configure("2") do |config|
config.vm.box = "debian/stretch64"
config.vm.box_check_update = false

config.vm.provider :libvirt do |lv|
end
config.vm.synced_folder ".", "/vagrant", disabled: true
  end
  make_box "box-a"
  make_box "box-b"
end

def make_box(name)
  Vagrant.configure("2") do |config|
config.vm.define name do |box|
  box.vm.provider :libvirt do |lv|
lv.memory = 1024
lv.cpus = 2
  end
end
  end
end

main
]]]

Try bringing up both hosts at once. You might need to wait a bit.

   * What was the outcome of this action?

You'll see each host snaffle the allocated DHCP management address.

The same client-id is reported in dnsmasq's lease file on the host machine.

   * What outcome did you expect instead?

Each host should identify itself differently to dnsmasq; if you check the
leases file, each box appears to supply the same client-id (although
they have different MAC addresses).

   * Diagnosis:

It appears that the client-id is supplied by the systemd network client. This
is derived, I believe, from /etc/machine-id and in turn
/var/lib/dbus/machine-id. These files are present with *fixed
contents* on the box image that I've used; each instance gets the same
machine-id.

The box image should not include those files (it suffices to delete them prior
to packaging the image). This causes each instance to mint its own new
UUID, which in turn results in distinct client-ids being supplied by
systemd.

(I don't think systemd is strictly at fault here; the contents of machine-id
should be distinct per distinct host.)

Cheers,
jan


-- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On Fri, Jul 21, 2017 at 02:32:02PM -0300, Antonio Terceiro wrote:
> On Fri, Jul 21, 2017 at 03:42:21PM +0200, Emmanuel Kasper wrote:
> > I commited the fix above in
> > git.debian.org:/git/cloud/debian-vm-templates.git
> 
> Thanks!
> 
> > the next box rebuild will have this included.
> > 
> 
> FWIW, I am planning to rebuild boxes for libvirt and lxc over the
> weekend

Updated boxes including the have been uploaded, so I am closing this
bug.


signature.asc
Description: PGP signature
--- End Message ---

Bug#868679: Re: Bug#868679: cloud.debian.org: Multiple identical vagrant boxes appear as the same machine to libvirt's dnsmasq dhcp provider

[Jan Grant]

Having had a look: when I *remove* /var/lib/dbus/machine-id and leave
a 0-byte file in /etc/machine-id, the boot sequence completes and
generates a new machine-id.

I'm able to bring up multiple "identical" VMs at that point; dnsmasq
reports them all having different client IDs.

On Tue, Jul 18, 2017 at 10:58 PM, jan <j...@ioctl.org> wrote:
> Will run through this tomorrow to confirm, cheers.
>
>
>
> --
> Excuse typos. Phone screens don't make great ketbroads.
>
>
>  Original message 
> From: Emmanuel Kasper <emman...@libera.cc>
> Date: 18/07/2017 5:14 p.m. (GMT+00:00)
> To: Jan Grant <j...@ioctl.org>, 868...@bugs.debian.org,
> sub...@bugs.debian.org
> Subject: Re: Bug#868679: cloud.debian.org: Multiple identical vagrant boxes
> appear as the same machine to libvirt's dnsmasq dhcp provider
>
> On 07/17/2017 05:16 PM, Jan Grant wrote:
>> The box image should not include those files (it suffices to delete them
>> prior
>> to packaging the image). This causes each instance to mint its own new
>> UUID, which in turn results in distinct client-ids being supplied by
>> systemd.
>
> It does not seem to me that deleting /etc/machine-id and
> /var/lib/dbus/machine-id is enough to have each instance generating this
> on boot, you have to call dbus-uuidgen --ensure manually.
>
> Can you double check this ?

Bug#868679: cloud.debian.org: Multiple identical vagrant boxes appear as the same machine to libvirt's dnsmasq dhcp provider

[jan]

Will run through this tomorrow to confirm, cheers.


-- Excuse typos. Phone screens don't make great ketbroads. 

 Original message 
From: Emmanuel Kasper <emman...@libera.cc> 
Date: 18/07/2017  5:14 p.m.  (GMT+00:00) 
To: Jan Grant <j...@ioctl.org>, 868...@bugs.debian.org, sub...@bugs.debian.org 
Subject: Re: Bug#868679: cloud.debian.org: Multiple identical vagrant boxes
 appear as the same machine to libvirt's dnsmasq dhcp provider 

On 07/17/2017 05:16 PM, Jan Grant wrote:
> The box image should not include those files (it suffices to delete them prior
> to packaging the image). This causes each instance to mint its own new
> UUID, which in turn results in distinct client-ids being supplied by
> systemd.

It does not seem to me that deleting /etc/machine-id and
/var/lib/dbus/machine-id is enough to have each instance generating this
on boot, you have to call dbus-uuidgen --ensure manually.

Can you double check this ?

Bug#868679: cloud.debian.org: Multiple identical vagrant boxes appear as the same machine to libvirt's dnsmasq dhcp provider

[Emmanuel Kasper]

On 07/17/2017 05:16 PM, Jan Grant wrote:
> The box image should not include those files (it suffices to delete them prior
> to packaging the image). This causes each instance to mint its own new
> UUID, which in turn results in distinct client-ids being supplied by
> systemd.

It does not seem to me that deleting /etc/machine-id and
/var/lib/dbus/machine-id is enough to have each instance generating this
on boot, you have to call dbus-uuidgen --ensure manually.

Can you double check this ?

Bug#868679: cloud.debian.org: Multiple identical vagrant boxes appear as the same machine to libvirt's dnsmasq dhcp provider

[Jan Grant]

Package: cloud.debian.org
Severity: important
Tags: newcomer

Dear Maintainer,

   * What led up to the situation?

I've been having problems using the supplied vagrant boxes in more complex
setups (where a Vagrantfile brings up more than one identical
machine). They effectively end up stealing each other's management IP
address (and potentially others that are DHCP managed).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Use a Vagrantfile a bit like this:

[[[
ENV['VAGRANT_DEFAULT_PROVIDER'] = 'libvirt'

def main()
  Vagrant.configure("2") do |config|
config.vm.box = "debian/stretch64"
config.vm.box_check_update = false

config.vm.provider :libvirt do |lv|
end
config.vm.synced_folder ".", "/vagrant", disabled: true
  end
  make_box "box-a"
  make_box "box-b"
end

def make_box(name)
  Vagrant.configure("2") do |config|
config.vm.define name do |box|
  box.vm.provider :libvirt do |lv|
lv.memory = 1024
lv.cpus = 2
  end
end
  end
end

main
]]]

Try bringing up both hosts at once. You might need to wait a bit.

   * What was the outcome of this action?

You'll see each host snaffle the allocated DHCP management address.

The same client-id is reported in dnsmasq's lease file on the host machine.

   * What outcome did you expect instead?

Each host should identify itself differently to dnsmasq; if you check the
leases file, each box appears to supply the same client-id (although
they have different MAC addresses).

   * Diagnosis:

It appears that the client-id is supplied by the systemd network client. This
is derived, I believe, from /etc/machine-id and in turn
/var/lib/dbus/machine-id. These files are present with *fixed
contents* on the box image that I've used; each instance gets the same
machine-id.

The box image should not include those files (it suffices to delete them prior
to packaging the image). This causes each instance to mint its own new
UUID, which in turn results in distinct client-ids being supplied by
systemd.

(I don't think systemd is strictly at fault here; the contents of machine-id
should be distinct per distinct host.)

Cheers,
jan


-- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Init: systemd (via /run/systemd/system)

Vagrant Boxes images for Stretch released

[Emmanuel Kasper]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi List

Antonio and I uploaded Vagrant Boxes images for the Stretch release
this week end, enjoyable at

https://atlas.hashicorp.com/debian/boxes/stretch64

more info at

https://wiki.debian.org/Teams/Cloud/VagrantBaseBoxes

Thanks for the hard work of CD Team and Release Team on which we built
upon !

Emmanuel
-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE9iWN8r/5pz9bHhXDBkVt15HpV5EFAllGbJ4QHG1hbnVAZGVi
aWFuLm9yZwAKCRAGRW3XkelXkX91D/9vzx1V9ABzftkwRYAmWsBEntTke2VBcQdr
hgpRbgLT3IDR7W/nX9Wcr4HJd2ZEa6zr1dze99W5ASx3fbhwypN7+000VfIAC1aG
LuVv0gIW4HRO05bpHlWjJ76LyNtF8SbLggMhF2k1USzYTwy84dXsj6M0VlpMQEt1
HJBifJlXYjR8dEjaJdXyZ9X2WdC3tFflKIQMHz6Ztunn7XvG82+JZhQ0tkpmon3H
3Wd4LvJwHhGHMECyhKfdhWlz46Sfe+zY2W7ZSrJ3hRoQRBYKG4B6EAJHgu+3MQND
4Hg2ygInW+v1vqyYhjQBnZfyRIyGmoANrwbcvrGK8enr2rls+60aMM18mdy+S7Xn
ro9D8a52J4xJB0r/PJ4VPfoyM9ZX8Y8YRCKh5l8bzUOoqgoSk9A5rTEDzvlNP6yI
WlFXR+xQJhvB7VMNU/oduEkpCI0XTnS4L6x9IBUIuLr6sSRWEOn+tLXndKq4vNYS
ZBiszs/PjdXDE2jsaQBAUTKgyisnoKHdfhFTIKjztdOL6fOpz4DM8o0gH9AnymO4
K/I08iF71mD64yabCTwFnrFXaZNsuCQYScndbYLj9GXyaNohrV5/xquJ9AELlD7d
jr8hl9QujfvetcJ7DI7C199k8hRY/ersMZkmj51g3rTpAPbKvoXcch5am/UsUepu
p0MNqtjEng==
=hU0O
-END PGP SIGNATURE-

Re: Vagrant Boxes images release for Stretch

[Antonio Terceiro]

On Fri, Jun 16, 2017 at 11:18:33AM +0200, Emmanuel Kasper wrote:
> Hi Lists
> I will rebuild and upload Vagrant Boxes images on Sunday 18 June for the
> VirtualBox provider. I build from CD so I need the CD images to be
> already available on the webs.
> So it should be right in time for Ana's blog post on Tuesday.
> I'll be around in #debian-cloud on Sunday to report my progress.

I'm planning to do the same for the libvirt and lxc variants already on
the Saturday. Since they are both created with straight debootstrap I
don't need to wait for install media.


signature.asc
Description: PGP signature

Vagrant Boxes images release for Stretch

[Emmanuel Kasper]

Hi Lists
I will rebuild and upload Vagrant Boxes images on Sunday 18 June for the
VirtualBox provider. I build from CD so I need the CD images to be
already available on the webs.
So it should be right in time for Ana's blog post on Tuesday.
I'll be around in #debian-cloud on Sunday to report my progress.

Emmanuel

Bug#863580: cloud.debian.org: Vagrant boxes randomly fail to come up when additional networks are configured

[Emmanuel Kasper]

Le 30/05/2017 à 21:46, Branko Majic a écrit :
> On Tue, 30 May 2017 21:23:58 +0200
> Emmanuel Kasper  wrote:
> 
>> Than you for the detailed bug report.
>>
>> I understand the unstable network card ordering can perturbate the
>> network config if the NIC is assigned the name eth1 instead of eth0.
>> But I am wondering why is that changing the type of the second NIC
>> make the device ordering stable.
>> Are you sure this fixes the issue ?
> 
> I've been thinking about it a bit. It could be a "race" between which
> kernel module gets initialised first? This is highly hypothetical from
> my side, mind you, just one thing that pops to my mind. I would need to
> read up quite a bit on the topic to be sure.

Comparing the output of
dmesg | grep
between multiple boots it might very well be that, I was able to
reproduce the bug.

I have to think about the best way to solve this.

In theory udev persistent device naming should be here for this kind of
issues, but I don't use it since I build via qemu, and the devices on
Virtualbox get another position in the pci bus.

I will have a thought on using udev rules or setting all NICS to the
same hardware type.

Bug#863580: cloud.debian.org: Vagrant boxes randomly fail to come up when additional networks are configured

[Branko Majic]

On Tue, 30 May 2017 21:23:58 +0200
Emmanuel Kasper  wrote:

> Than you for the detailed bug report.
> 
> I understand the unstable network card ordering can perturbate the
> network config if the NIC is assigned the name eth1 instead of eth0.
> But I am wondering why is that changing the type of the second NIC
> make the device ordering stable.
> Are you sure this fixes the issue ?

I've been thinking about it a bit. It could be a "race" between which
kernel module gets initialised first? This is highly hypothetical from
my side, mind you, just one thing that pops to my mind. I would need to
read up quite a bit on the topic to be sure.

So, if you use same network adapter type everywhere, same module gets
used, and possibly the OS/kernel will always have the same ordering of
network cards. Or... It could be dependant on network module
implementation itself as well :)

As for the fix, I have been bringing machines up and down a bunch of
times since applying workaround in the Vagrantfile, and it has worked
flawlessly. The moment I remove the configuration, I start getting
failures. Practically no two consecutive "vagrant up" runs will
bring-up the network interfaces correctly in a batch of about 6-7
machines that get set-up.

Best regards

-- 
Branko Majic
XMPP: bra...@majic.rs
Please use only Free formats when sending attachments to me.

Бранко Мајић
XMPP: bra...@majic.rs
Молим вас да додатке шаљете искључиво у слободним форматима.

Bug#863580: cloud.debian.org: Vagrant boxes randomly fail to come up when additional networks are configured

[Emmanuel Kasper]

> After comparing the files in two boxes, turned out that
> debian/contrib-jessie64 defines different network adapter type for
> first network adapter and remaining ones (82540EM vs Am79C973). This
> probably results in somewhat random ordering in the VM itself when
> adapters are being named. Relevant file where this is defined is
> "box.ovf".

> One could work around this issue with private network definition as:
> 
> machine.vm.network "private_network", ip: "10.64.128.10", nic_type: "82540EM"

Than you for the detailed bug report.

I understand the unstable network card ordering can perturbate the
network config if the NIC is assigned the name eth1 instead of eth0.
But I am wondering why is that changing the type of the second NIC
make the device ordering stable.
Are you sure this fixes the issue ?

Bug#863580: cloud.debian.org: Vagrant boxes randomly fail to come up when additional networks are configured

[Branko Majic]

Package: cloud.debian.org
Severity: important

Dear Maintainer,

When additional networks are configured in Vagrantfile, this can
result in Vagrant boxes randomly failing while bringing them up. Issue
occurs both with debian/jessie64 and debian/contrib-jessie64.

Reproduction steps:

1. Install latest version of Vagrant and VirtualBox. Issue should be
   reproducible with older versions too.

2. Create a simple Vagrantfile with the following content:

%
# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  config.vm.box = "debian/contrib-jessie64"

  config.vm.define "machine" do |machine|
machine.vm.hostname = "machine"
machine.vm.network "private_network", ip: "10.64.128.10"
  end

end
%

3. Bring up and destroy the Vagrant machine repeatedly (several
   repetitions may be needed to reproduce the issue):

vagrant up && vagrant destroy -f


Expected results:

1. Step (3) of reproduction steps always succeeds.


Actual results:

1. Step (3) of reproduction steps intermittently fails, with error:

%
machine: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
%


Additional information:

Host environment is Gentoo x86_64, VirtualBox 5.1.18, Vagrant 1.9.5,
debian/contrib-jessie64 8.7.0.

Some testing was done with bento/debian-8.7 base box too, and the
issue could not be reproduced. After some troubleshooting, it turned
out that with debian/jessie64 box the network interfaces eth0 and eth1
may "swap places". E.g. instead of default (NAT) adapter being eth0
and private adapeter being eth1, default adapter would become available
as eth1, and private adapter would become available as eth0, making it
impossible for Vagrant to connect (no IP assigned, since
/etc/network/interfaces assumes eth0 is the NAT adapter for purpose of
getting address from built-in DHCP).

After comparing the files in two boxes, turned out that
debian/contrib-jessie64 defines different network adapter type for
first network adapter and remaining ones (82540EM vs Am79C973). This
probably results in somewhat random ordering in the VM itself when
adapters are being named. Relevant file where this is defined is
"box.ovf".

One could work around this issue with private network definition as:

machine.vm.network "private_network", ip: "10.64.128.10", nic_type: "82540EM"

The best way would be, however, to fix it in base box image instead,
similar to what the Bento box does (all the network interfaces, even
unused ones have 82540EM specified as adapter type). This is especially
true because of how hard it is to figure the issue out (took me a
while to realise what is happening).

Alternative would be to introduce udev rules that would ensure the NAT
network adapter always gets the same name based on MAC.


-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Re: Vagrant boxes debian 32 bits

[Romain Garbage]

Hi Emmanuel,

Le vendredi 24 février 2017, Emmanuel Kasper <m...@debian.org> a écrit :

> Hi Romain
>
> >> On 02/23/2017 12:39 AM, Romain Garbage wrote:
> >>> Hello,
> >>>
> >>> I would like to know if the TeamCloud plans to also provide 32 bit
> images
> >>> of Debian as Vagrant boxes on Atlas ?
> >>>
> >>> If it is of interest, I attach you a .json file that I adapted from
> >>> https://anonscm.debian.org/cgit/cloud/debian-vm-
> >> templates.git/tree/packer-virtualbox-vagrant/contrib-jessie.json
> >>> to make a 32 bit image. I couldn't test it as I don't have a 64 bit
> >> system
> >>> and the documentation states that a 64 bit system is necessary to use
> >>> import2vbox.
> >>>
> >>> Have a nice day,
> >>> Romain
> >>>
> >>
> >>
> >> Do you mind if we continue the discussion in public on the debian-cloud
> >> mailing list so people can give their feedback ?
> >>
>
> > No problem!! I didn't even think about sending that to the mailing list,
> I
> > just saw your name on the Debian Wiki and decided to write you about
> this!
> > Feel free to forward my mail to the mailing list! I will join it to
> follow
> > the discussion, can you put me in copy in the meantime so I don't miss
> > anything?
>
> Thank for your interest in Vagrant boxes.
>
> What is exactly your use case for 32 bits Vagrant boxes ?


The Yunohost project uses your Vagrant boxes as a base to build up
development boxes (see https://github.com/YunoHost/Vagrantfile repo). I
submitted a patch to add 32bit support to their environment, as I have an
oldish 32bit laptop and thus cannot run 64bit boxes. For now I built the
32bit boxes from the Bento image because I didn't find an official 32 bit
Debian. I was wondering why there were not such images, so I sent you an
email. As it looked to me very straightforward to adapt the json to 32bit,
I attached it with my first email in case it was of interest.

We currently build 7 Vagrant build images (3 VirtualBox, 2 LXC, 2
> Libvirt) all of them 64 bits. Adding 32 bits on top would be bit a bit
> of work, especially since not that much of the build process for new
> releases is automated.


I understand perfectly this issue and it answers all my interrogations.


>
> I see everyday more software dropping 32 bits support (RHEL 7, MongoDB,
> Proxmox PVE all require 64 bit hardware) so I am not that much looking
> forward having extra work which will be deprecated in two years.
>
> If the issue is important to you, open a bug on the debian-cloud pseudo
> package in the BTS with the wishlist priority so the issue is properly
> tracked.


As I said in the 1st paragraph, for the moment I don't have any
particularly urging need to have an official 32bit image, I think it will
be fine with the Bento image.

Thank you very much for your answer and for having brought up the existing
images !

Romain

>
>

Re: Vagrant boxes debian 32 bits

[Emmanuel Kasper]

Hi Romain

>> On 02/23/2017 12:39 AM, Romain Garbage wrote:
>>> Hello,
>>>
>>> I would like to know if the TeamCloud plans to also provide 32 bit images
>>> of Debian as Vagrant boxes on Atlas ?
>>>
>>> If it is of interest, I attach you a .json file that I adapted from
>>> https://anonscm.debian.org/cgit/cloud/debian-vm-
>> templates.git/tree/packer-virtualbox-vagrant/contrib-jessie.json
>>> to make a 32 bit image. I couldn't test it as I don't have a 64 bit
>> system
>>> and the documentation states that a 64 bit system is necessary to use
>>> import2vbox.
>>>
>>> Have a nice day,
>>> Romain
>>>
>>
>>
>> Do you mind if we continue the discussion in public on the debian-cloud
>> mailing list so people can give their feedback ?
>>

> No problem!! I didn't even think about sending that to the mailing list, I
> just saw your name on the Debian Wiki and decided to write you about this!
> Feel free to forward my mail to the mailing list! I will join it to follow
> the discussion, can you put me in copy in the meantime so I don't miss
> anything?

Thank for your interest in Vagrant boxes.

What is exactly your use case for 32 bits Vagrant boxes ?

We currently build 7 Vagrant build images (3 VirtualBox, 2 LXC, 2
Libvirt) all of them 64 bits. Adding 32 bits on top would be bit a bit
of work, especially since not that much of the build process for new
releases is automated.

I see everyday more software dropping 32 bits support (RHEL 7, MongoDB,
Proxmox PVE all require 64 bit hardware) so I am not that much looking
forward having extra work which will be deprecated in two years.

If the issue is important to you, open a bug on the debian-cloud pseudo
package in the BTS with the wishlist priority so the issue is properly
tracked.

Emmanuel

Re: 32 bits Jesssie Vagrant boxes ?

[Olivier Berger]

Hi Manu.

Emmanuel Kasper  writes:

> Le 20/01/2017 à 18:45, Olivier Berger a écrit :
>> Hi.
>> 
>> AFAICS on https://atlas.hashicorp.com/debian there are no 32 bits i686
>> stable/jessie images available for Vagrant.
>> 
>> Maybe that'd be important for VirtualBox so that one may test particular
>> environments where 64 bits isn't suitable (for instance if meant to be
>> run on end-user machines only installed with 32 bits OS).
>> 
>> Would it make sense ?
>> 
>
> Hi Olivier !
> 32bits require extra work for building and testing (we're still doing
> that locally) and have not been requested up to now IIRC.
> I think currently all cloud images are 64 bits only.
>
> Is the test use case you're mentioning a theoretical need or a practical
> one ?
>

Rather practical, even though still exploratory, without end-users in
the loop yet.

My aim is to create a VirtualBox Debian VM ready for students learning
network protocols, which would run a netkit(-ng) [0] lab that relies on
a 32 bits version of UML (User Mode Linux).

Until I'm ready to produce a full-fledged VirtualBox image, I'm trying
to experiment and automate using Vagrant and the VirtualBox provider.

The constraint on 32 bits is due to the fact that there would probably
be users of the VM on VirtualBox running over a 32 bits OS (we target a
MOOC with a very diverse audience).

But everything isn't really stabilised and it may happen that we choose
other means than a VirtualBox VM to run the UMLs... or another variant
of netkit that would support 64 bits UML... or... I don't know yet ;)

Hope this makes sense, a bit.

Best regards,

[0] https://netkit-ng.github.io/
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Re: 32 bits Jesssie Vagrant boxes ?

[Emmanuel Kasper]

Le 20/01/2017 à 18:45, Olivier Berger a écrit :
> Hi.
> 
> AFAICS on https://atlas.hashicorp.com/debian there are no 32 bits i686
> stable/jessie images available for Vagrant.
> 
> Maybe that'd be important for VirtualBox so that one may test particular
> environments where 64 bits isn't suitable (for instance if meant to be
> run on end-user machines only installed with 32 bits OS).
> 
> Would it make sense ?
> 

Hi Olivier !
32bits require extra work for building and testing (we're still doing
that locally) and have not been requested up to now IIRC.
I think currently all cloud images are 64 bits only.

Is the test use case you're mentioning a theoretical need or a practical
one ?

Emmanuel

32 bits Jesssie Vagrant boxes ?

[Olivier Berger]

Hi.

AFAICS on https://atlas.hashicorp.com/debian there are no 32 bits i686
stable/jessie images available for Vagrant.

Maybe that'd be important for VirtualBox so that one may test particular
environments where 64 bits isn't suitable (for instance if meant to be
run on end-user machines only installed with 32 bits OS).

Would it make sense ?

Thanks in advance.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Re: Debian Vagrant boxes and Virtualbox

[Tiago Ilieve]

Hi Chris,

On 22 February 2016 at 04:51, Chris Fordham  wrote:
> Needs to go on wiki?

That would be nice. Teams/Cloud/VagrantBaseBoxes[1] is the first
result on Google when someone searchs for "debian vagrant" (without
quotes), but there's no mention to the "debian/contrib-jessie64" box
at all. Extra work will be needed to update other parts of the article
that mentions the absent of VirtualBox Guest Additions.

I was hit by the problem with the rsync shared folder myself. Even
installing guest additions by hand didn't solved the problem. Then I
remembered the discussion started here by Asheesh[2] and the
announcement of the contrib boxes made by Emmanuel[3]. Using the
latter solved my problem, but I can't imagine how and end user who
does not follows this list would find it alone.

Regards,
Tiago.

[1]: https://wiki.debian.org/Teams/Cloud/VagrantBaseBoxes
[2]: https://lists.debian.org/debian-cloud/2015/12/msg3.html
[3]: https://lists.debian.org/debian-cloud/2015/12/msg00016.html

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Debian Vagrant boxes and Virtualbox

[Chris Fordham]

On Mon, Feb 22, 2016 at 5:12 PM, Benjamin Schubert <ben.c.schub...@gmail.com
> wrote:

> Hi,
>
> Thanks a lot, I spent about two hours searching for this and couldn't even
> find it...
>
Needs to go on wiki?


>
> Thank you for your work !
>
> Benjamin
>
> On Mon, Feb 22, 2016 at 3:22 AM Emmanuel Kasper <emman...@libera.cc>
> wrote:
>
>> Le 21/02/2016 22:18, Benjamin Schubert a écrit :
>> > Hi,
>> >
>> > First of all, thanks a lot for your awesome work on Debian vagrant
>> boxes.
>> > They work really well !
>> >
>> > I however stumble on a problem with the rsync synchronization used now
>> on
>> > these boxes and I'd need to use the Virtualbox shared folder feature.
>> >
>> > I therefore had a question about the license of the project. I'm quite
>> new
>> > to all this, so I don't really know what is licensed and how on Debian.
>> >
>> > What I'd like to do is fork the Debian Vagrant project, revert the
>> changes
>> > removing the virtualbox extensions and publish the new code on Github,
>> plus
>> > the box on Hashicorp, and I wanted to know if I was allowed to do this,
>> > mentioning that it is a fork and giving a link to the official project,
>> or
>> > if I needed something else.
>> >
>> > Could you please tell me what should I do ?
>> >
>> > Thanks a lot,
>> >
>> > Benjamin Schubert
>> >
>>
>> Hi Benjamin
>> We also offer a vagrant base box with Virtualbox shared folders now
>> it's called  contrib-jessie64
>> see https://atlas.hashicorp.com/debian/
>>
>> also our git repo has a LICENSE file if wou want to do and redistribute
>> your own modifications
>>
>> Emmanuel
>>
>>
>>
>>

Re: Debian Vagrant boxes and Virtualbox

[Benjamin Schubert]

Hi,

Thanks a lot, I spent about two hours searching for this and couldn't even
find it...

Thank you for your work !

Benjamin

On Mon, Feb 22, 2016 at 3:22 AM Emmanuel Kasper <emman...@libera.cc> wrote:

> Le 21/02/2016 22:18, Benjamin Schubert a écrit :
> > Hi,
> >
> > First of all, thanks a lot for your awesome work on Debian vagrant boxes.
> > They work really well !
> >
> > I however stumble on a problem with the rsync synchronization used now on
> > these boxes and I'd need to use the Virtualbox shared folder feature.
> >
> > I therefore had a question about the license of the project. I'm quite
> new
> > to all this, so I don't really know what is licensed and how on Debian.
> >
> > What I'd like to do is fork the Debian Vagrant project, revert the
> changes
> > removing the virtualbox extensions and publish the new code on Github,
> plus
> > the box on Hashicorp, and I wanted to know if I was allowed to do this,
> > mentioning that it is a fork and giving a link to the official project,
> or
> > if I needed something else.
> >
> > Could you please tell me what should I do ?
> >
> > Thanks a lot,
> >
> > Benjamin Schubert
> >
>
> Hi Benjamin
> We also offer a vagrant base box with Virtualbox shared folders now
> it's called  contrib-jessie64
> see https://atlas.hashicorp.com/debian/
>
> also our git repo has a LICENSE file if wou want to do and redistribute
> your own modifications
>
> Emmanuel
>
>
>
>

Bug#787298: providing base vagrant boxes that both minimal and featureful

[Antonio Terceiro]

On Tue, Jun 02, 2015 at 08:31:13AM +1000, Chris Fordham wrote:
 On 02/06/2015 7:12 AM, Emmanuel Kasper emman...@libera.cc wrote:
 
   The other point is that including (either) provisioner takes us further
   from the standard Debian image.
 
  BTW, Was is actually a standard Debian image ?
  To the best of my knowledge, I would define it as all the packages with
  Priority: required and important.
  According to the Debian Jessie installation guide [1], the *standard*
  task is also recommended.
 
  In server/containers environments it makes sense to restrict the list
  of packages installed.
  However the main aim of the Vagrant Virtualbox base boxes,are shareable
  development environments.
  In this kind of setup, I would expect the usual comfort of the debian
  experience, having for instance a mail server to send stuff,
  bash-completion or patch installed, all packages with come with the
  standard priority.

In my experience, having a minimal image helps you with figuring out
what are the actual dependencies of your application and making sure it
will work on whatever environment it is deployed to.

  So I am in favor of installing this task, which will bring aptitude as a
  side effect.
 
  Concerning the inclusion/removal of providers via specific boxes, why not.
 
  [1] https://www.debian.org/releases/jessie/i386/apbs04.html.en
  Section: Package selection
 Base boxes should be both provisionerless as well as stock as possible.
 
 Vagrant plugins should be used to look after installing provisioners such
 as your an ansible, puppet etc.
 
 Chef is already doing this where the bento boxes are provisionerless and
 the vagrant-omnibus plugin installs the version of Chef to your liking.

I agree, but I also agree that any provisioning should work out of the
box with the base box you provide. That said, it is possible to automate
the installation of all provisioners mentioned in /vagrant/Vagrantfile
when you bring the box up.

For example I have the following i my ~/.vagrant.d/Vagrantfile (which is
applied by Vagrant to every box I bring up):

888-
Vagrant.configure(2) do |config|
  config.vm.provision :shell do |shell|
shell.path = '/home/terceiro/bin/vm-bootstrap'
shell.keep_color = true
  end
end

# vim: ft=ruby
888-

that vm-bootstrap script sets up the box to use my local APT cache, and
installs vim, bash-completion and other goodies.

Last time I checked, every .box can also include a Vagrantfile which
will also be applied when it is brought up, before the
application-specific Vagrantfile. That could easily parse
/vagrant/Vagrantfile, figure out the provisioners used, and install them
with apt-get on the fly.

It could also install aptitude if that is needed for ansible (however
requiring aptitude when apt is already there is indeed odd IMO).

So I think we could have a base image that is both minimal and works out
of the box with whatever provisioner (provided it is available in the
archive, I guess).

-- 
Antonio Terceiro terce...@debian.org


signature.asc
Description: Digital signature

Bootstrap-vz to produce Debian testing Vagrant boxes

[Stéphane Germain]

Hello all,

Allow me to apologize for any mistakes as English is not my native language.

I'm currently working on creating a vagrant basebox using Debian and I plan
to use bootstrap-vz.
 
Is the script able to create a Debian testing Vagrant VM? 

Is there a huge difference between the master and development branches on
github?

Best regards,

Stéphane Germain


-- 
To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/loom.20140716t114646-...@post.gmane.org

Re: Bootstrap-vz to produce Debian testing Vagrant boxes

[Tiago Ilieve]

Hi Stéphane,

 Allow me to apologize for any mistakes as English is not my native
 language.

Don't worry. There is a lot of non-native English speakers here. I guess
that is fine as long as we could understand each other (and use a spell
checker, of course - but we should do that for any language anyway).

 Is the script able to create a Debian testing Vagrant VM?

Well, yes and no. We have spotted a bug last week (issue #121[1]) which
prevents the VirtualBox Guest Additions from being installed if the
kernel version of the image being bootstrapped is different from the one
running on the host machine. Until we figure out a way to fix that, yes
you are able to build a testing Vagrant box, but without Guest Additions
you can't share folders, forward ports, etc. - what makes the box a
little less useful and certainly prevents you from using all Vagrant
resources.

 Is there a huge difference between the master and development branches
 on github?

There is a difference, as the last merge between them happened more than
two months ago, but I can't say if it is huge or not. I would advise you
to use the development branch if you are looking for something that
isn't on master yet. It isn't supposed to be an unstable branch, but a
place where we could add new features and fix non-critical bugs.

Regards,
Tiago.

[1]: https://github.com/andsens/bootstrap-vz/issues/121

On 16 July 2014 06:48, Stéphane Germain
stephane.germ...@telecom-sudparis.eu wrote:
 Hello all,

 Allow me to apologize for any mistakes as English is not my native language.

 I'm currently working on creating a vagrant basebox using Debian and I plan
 to use bootstrap-vz.

 Is the script able to create a Debian testing Vagrant VM?

 Is there a huge difference between the master and development branches on
 github?

 Best regards,

 Stéphane Germain


 --
 To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/loom.20140716t114646-...@post.gmane.org




-- 
Tiago Myhro Ilieve
Blog: http://blog.myhro.info/
GitHub: https://github.com/myhro/
Montes Claros - MG, Brasil


--
To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALdTKe_utehxY0Q=cXayG3ou-weZ6Yu=tgo+r3kamrc_ynh...@mail.gmail.com

Re: providing official vagrant boxes of wheezy?

[olivier sallou]

2013/10/17 Adam Bolte abo...@systemsaviour.com

 On Thu, Oct 17, 2013 at 09:59:04AM +0600, Anders Ingemann wrote:
  On Thursday, October 17, 2013, Antoine Beaupré wrote:
   How hard would it be for the debian project to provide official vagrant
   images of wheezy alongside the regular .ISO images?
  
   Ubuntu has this place where they publish a bunch of similar images, how
   about us?
  
   http://cloud-images.ubuntu.com/
  
  Working on it:
 http://lists.debian.org/debian-cloud/2013/09/msg00038.html

 They mention limitations such as lack of file sharing and needing to
 use vmdk images.


Regarding vmdk file, it is a temporary limitation. The current script
generates the vmdk needed for vagrant box, but does not generate the
vagrant box itself (because it also requires VirtualBox locally installed
and Anders prefer to limit to main archive usage). I give however
instruction in README (a shell script) to transform the generated vmdk
disk file to a Vagrant box.




 I wonder if it would make more sense to support the
 vagrant-kvm plugin so we don't need to worry about the hassles of
 VirtualBox as a provider?

Limitations are related to VirtualBox guest additions not being installed
because those are in contrib and not in main.

If we want to provide official Vagrant images one could easily add guest
additions to the build scripts. This is not a technical limitation.

Regarding vagrant-kvm, this will not fit many desktop users using
VirtualBox on their computer but would rather fit server side usage (so it
means that rather both should be offered when vagrant-kvm is officially
released).


Olivier


 https://github.com/adrahon/vagrant-kvm

 This is not packaged yet however, and I only discovered the project
 this morning!




-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

providing official vagrant boxes of wheezy?

[Antoine Beaupré]

How hard would it be for the debian project to provide official vagrant
images of wheezy alongside the regular .ISO images?

Ubuntu has this place where they publish a bunch of similar images, how
about us?

http://cloud-images.ubuntu.com/

A.

PS: please cc.

-- 
It is a miracle that curiosity survives formal education
- Albert Einstein


pgpKhsRz9Vje8.pgp
Description: PGP signature

Re: providing official vagrant boxes of wheezy?

[Adam Bolte]

On Thu, Oct 17, 2013 at 09:59:04AM +0600, Anders Ingemann wrote:
 On Thursday, October 17, 2013, Antoine Beaupré wrote:
  How hard would it be for the debian project to provide official vagrant
  images of wheezy alongside the regular .ISO images?
 
  Ubuntu has this place where they publish a bunch of similar images, how
  about us?
 
  http://cloud-images.ubuntu.com/
 
 Working on it: http://lists.debian.org/debian-cloud/2013/09/msg00038.html

They mention limitations such as lack of file sharing and needing to
use vmdk images. I wonder if it would make more sense to support the
vagrant-kvm plugin so we don't need to worry about the hassles of
VirtualBox as a provider?

https://github.com/adrahon/vagrant-kvm

This is not packaged yet however, and I only discovered the project
this morning!


signature.asc
Description: Digital signature