Re: Problem creating Vagrant boxes
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
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
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
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
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
