Adjust epoch to release value, change into dir

Update libxcrypt package used for install

Grabbing the release version of the library removes the autotools requirement that is imposed when we fetch the tarball of the source code directly

Add script for building RPM package

Add helpers for setting up centos chroot

Add scripts for building centos substrate and install

Add workflow for building RPMs

Add dev workflow for rpms

Update commons library

Allow cross building for 32 bit

Use cacert bundle for install when available

Merge pull request #249 from hashicorp/rpm-pkgs

Add rpm packages to CI

Adds RPM package building to CI

Adds RPM package building to CI

Debug output

https://gist.github.com/rbudiharso/c93dbbd4660c905c8c89575ef41f964b

Expected behavior

Vagrant up successfully

Actual behavior

Vagrant received unknown output from docker build while building a container: sha256:bd07d17a485a2488972f0b6047109ef78984393b398445cf1f52aedae0485ca0

Reproduction information

run vagrant up

Vagrant version

Vagrant 2.3.4

Host operating system

Mac OS Ventura 13.3

Guest operating system

Ubuntu

Steps to reproduce

1. vagrant up

Vagrantfile

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

Vagrant.configure("2") do |config|
  config.vm.provider "docker" do |d|
    d.build_dir = "."
    d.build_args = ["--load", "--quiet"]
    d.remains_running = true
    d.has_ssh = true
  end
end

FROM ubuntu:lunar

ENV TZ=Asia/Jakarta
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

RUN apt-get update -y

RUN apt-get install -y --no-install-recommends ssh sudo

RUN useradd --create-home -s /bin/bash vagrant
RUN echo -n 'vagrant:vagrant' | chpasswd
RUN echo 'vagrant ALL = NOPASSWD: ALL' > /etc/sudoers.d/vagrant
RUN chmod 440 /etc/sudoers.d/vagrant
RUN mkdir -p /home/vagrant/.ssh
RUN chmod 700 /home/vagrant/.ssh
RUN echo "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA6NF8iallvQVp22WDkTkyrtvp9eWW6A8YVr+kz4TjGYe7gHzIw+niNltGEFHzD8+v1I2YJ6oXevct1YeS0o9HZyN1Q9qgCgzUFtdOKLv6IedplqoPkcmF0aYet2PkEDo3MlTBckFXPITAMzF8dJSIFo9D8HfdOV0IAdx4O7PtixWKn5y2hMNG0zQPyUecp4pzC6kivAIhyfHilFR61RGL+GPXQ2MWZWFYbAGjyiYJnAmCP3NOTd0jMZEnDkbUvxhMmBYSdETk1rRgm+R4LOzFUGaHqHDLKLX+FIPKcF96hrucXzcWyLbIbEgE98OHlnVYCzRdK8jlqm8tehUc9c9WhQ==" > /home/vagrant/.ssh/authorized_keys
RUN chmod 600 /home/vagrant/.ssh/authorized_keys
RUN chown -R vagrant:vagrant /home/vagrant/.ssh
RUN sed -i -e 's/Defaults.*requiretty/#&/' /etc/sudoers
RUN sed -i -e 's/\(UsePAM \)yes/\1 no/' /etc/ssh/sshd_config

RUN mkdir /var/run/sshd

RUN apt-get -y install openssh-client

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]

Similar to #12245

Hi there,

The docker provider uses the output provided by docker to determine the success of the command. The --quiet flag that you have added is removing some of the output that Vagrant is expecting and thus causing it to fail. If you remove the --quiet flag from your build_args then the Vagrant run should succeed. The --load flag also does not appear to be a valid flag, but from the output provided it is the --quiet flag that is causing the problem.

Cheers!

Hi there,

Would you please try using the generic/debian8 box and see if you still experience the same error. If you do, would you please provide a gist with the output from a fresh vagrant up --debug and vagrant ssh --debug so we can determine where the root of the issue may be?

Thanks!

I'm not sure if this a bug, a feature request or just a question. Anyways:

I have a multi-machine setup where I need "global" control over the order in which machine-scope provisioners are executed, i.e., I want to control not only the order of provisioners for each machine, but the global order regardless of which machine they belong to. This will probably be more clear by considering the following Vagrantfile, my goal there being that the provisioners run in order "1 2 3 4 5 6". So since the docs said that provisioners by default run in the order in which they are defined, at first I attempted the following:

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

  config.vm.box = "peru/ubuntu-20.04-server-amd64"

  config.vm.provider "libvirt" do |libvirt|
    libvirt.memory = 512
  end

  config.vm.define "alpha" do |alpha|
    alpha.vm.provision "shell", inline: 'echo "1"'
  end

  config.vm.define "beta" do |beta|
    beta.vm.provision "shell", inline: 'echo "2"'
  end

  config.vm.define "gamma" do |gamma|
    gamma.vm.provision "shell",
      inline: $script_demo, inline: 'echo "3"'
    gamma.vm.provision "shell",
      inline: $script_demo, inline: 'echo "4"'
  end

  config.vm.define "alpha" do |alpha|
    alpha.vm.provision "shell", inline: 'echo "5"'
  end

  config.vm.define "beta" do |beta|
    beta.vm.provision "shell",
      inline: $script_demo, inline: 'echo "6"'
  end

end

As the Vagrantfile indicates, I need to run some provisioners on alpha and beta, then some on gamma, and after that again some on alpha and beta. I thus attempted to "split" the definition of alpha and beta by just opening a block for them again after gamma. I didn't find anything in the docs or any question about such "split" machine definitions, so this is sort of a side question: Is this valid? If not, is there a proper way of doing this? I imagine an alternative could be to somehow keep a reference to the alpha and beta machines in a variable in the global scope and then use that later, instead of the second blocks for alpha and beta. But not sure, I'm pretty new to Ruby. As far as I can tell, my approach seems to work. Anyways, the main concern of this issue (inter-machine provisioner ordering) is independent of using split machine definitions.

So after running vagrant up and vagrant destroy many times with this Vagrantfile and observing the output, it seems that provisioners for each machine indeed run in the order they are defined, even when my approach to splitting definitions is used. In other words, I observed that 5 is always run after 1 (alpha), and that 6 is always run after 2 (beta), and of course that 4 is always run after 3 (gamma). But besides this, the order seems random, likely due to a race condition because no inter-machine provisioner order is enforced. This might be a bug by design, although I wish there was a way around this, or at least that it was mentioned in the docs.

I also tried to export VAGRANT_EXPERIMENTAL="dependency_provisioners" and ...

• ... set name: "foo" of the provisioner 3 and set after: "foo" of provisioner 5 and 6, but as the docs say (although you have to read quite carefully), this will result in an error because only referencing root-level provisioners is supported.
• ... play with after: :all on the provisioners 5 and 6, but it seems to have no effect, maybe because that's also only for provisioners of the same machine (and provisioners 5 and 6 are already last in their respective machine-scope)?

So it would be really awesome to be able to order provisioners "globally". Also, maybe the docs should be clearer about the current limitations. Is there any workaround though? Thanks in advance and sorry for the long issue description.

In case this is a bug:

• Host: Ubuntu 22.04.2 LTS
• Vagrant version: 2.3.4
• Provider: libvirt

Hi there,

The type of behavior you are expecting from Vagrant is not currently possible due to how the Vagrant configuration file is parsed and processed. When the Vagrantfile is loaded each guest's configuration is merged from all the blocks found in the Vagrantfile into a single configuration (which preserves the order of defined provisioners order for the specific guest). The global order of the provisioners is not recorded and is not known by Vagrant when the configuration is loaded. Provisioners are executed in order for a specific guest, but not in a global order when more than one guest has been configured. For providers which support parallel guest creation, multiple guests will be launched and provisioned simultaneously, however the order of the provisioning will be specific to each individual guest. This explains why you would see interleaving of the provisioners being executed during your vagrant up.

An alternative approach to this would be to run a vagrant up --no-provision to allow all the guest to be brought up to a running state. From this point, you can then run a separate script which would provision each guest in the order you would like to impose by using the vagrant provision command with the --provision-with flag. However, to be able to use the --provision-with flag effectively, you will need to name your provisioners so you can call them by name. For example:

Vagrant.configure("2") do |config|
  ...
  config.vm.define "alpha" do |alpha|
    alpha.vm.provision "shell", name: "script_1", inline: 'echo "1"'
  end
...

If you have any issues, please feel free to respond on this issue or create a new issue.

Cheers!

Adds arch linux package builds to CI

Remove launcher building and update naming

Update Makefile for better integration with CI

Update macos build workflow to accept inputs

Ubuntu chroot create and setup helpers

These scripts create the ubuntu chroot environment used for building the substrate and the installation artifacts

Add CI script for building the substrate artifact

Add CI script for building installation artifact

Add basic script for doing gem installation

Move common-setup up a directory for broader usage

Allow relative files without separators

Add script for building deb packages

Add script for deb information generation

Add workflow for building debs

Add dev workflow for deb packages

Merge pull request #247 from hashicorp/deb-packages

Add deb packages to CI

Update rpath value on linux builds

Set where libraries can be located during vagrant install

Add setup helper for archlinux

Add ci scripts for archlinux builds

Add package script for building archlinux package

Update ruby minimum version in PKGBUILD

Remove launcher building and update naming

Update Makefile for better integration with CI

Update macos build workflow to accept inputs

Ubuntu chroot create and setup helpers

These scripts create the ubuntu chroot environment used for building the substrate and the installation artifacts

Add CI script for building the substrate artifact

Add CI script for building installation artifact

Add basic script for doing gem installation

Move common-setup up a directory for broader usage

Allow relative files without separators

Add script for building deb packages

Add script for deb information generation

Add workflow for building debs

Add dev workflow for deb packages

Merge pull request #247 from hashicorp/deb-packages

Add deb packages to CI

Adds workflow and scripts for building deb packages. Includes workflow for building dev deb packages.

Add workflow for building debs

Add dev workflow for deb packages

Adds workflow and scripts for building deb packages. Includes workflow for building dev deb packages.

Add deb package building workflow

Add deb package building workflow

Reduce size for large file identification

Also add arguments to the correct place and increase number of retries before giving up.

Update launcher to remove versioned subdirectory

Also removes osext dependency as the stdlib provides everything we need to do this properly now.

Fix postinstall script to remove escapes

Remove gem fixes and add extension fixups

Fixes to the Ruby build allow google-protobuf and grpc gems to build properly using the ruby platform value. Retain the grcp gem cleanup as the intermediate build files still remain and need to be removed.

RubyGems relies on a touched file to determine if extensions have been built. This path includes the platform so it must be duplicated for the non-build host platform to ensure gems will behave properly on both platforms.

Set permissions on substrate directory

Since the permissions defined on the substate directory when packaging are used during the install, ensure the directory that was created to unpack into is properly accessible.

Fix Ruby builds on macOS, updates for linux substrate

The arch directory configurations for Ruby as they were set were causing problems when building extensions due to Ruby header directories being included in the default search path.

Updated architecture settings to always be explicit for macOS.

Added fix to linux substrate builds to force openssl libs into the ./lib directory and not ./lib64 along with removing flags for the lib64 directory.

Remove deprecated build workflow

Merge pull request #244 from hashicorp/universal-fixes

Updates for universal builds

Few updates for the universal builds:

• Launcher update to remove versioned subdirectory
• Fixed postinstall script
• Fixed Ruby install internal layout
• Fixed installed directory permissions
• Resolved gem extension validation on non-build platform

Update launcher to remove versioned subdirectory

Also removes osext dependency as the stdlib provides everything we need to do this properly now.

Fix postinstall script to remove escapes

Remove gem fixes and add extension fixups

Fixes to the Ruby build allow google-protobuf and grpc gems to build properly using the ruby platform value. Retain the grcp gem cleanup as the intermediate build files still remain and need to be removed.

RubyGems relies on a touched file to determine if extensions have been built. This path includes the platform so it must be duplicated for the non-build host platform to ensure gems will behave properly on both platforms.

Set permissions on substrate directory

Since the permissions defined on the substate directory when packaging are used during the install, ensure the directory that was created to unpack into is properly accessible.

Fix Ruby builds on macOS, updates for linux substrate

The arch directory configurations for Ruby as they were set were causing problems when building extensions due to Ruby header directories being included in the default search path.

Updated architecture settings to always be explicit for macOS.

Added fix to linux substrate builds to force openssl libs into the ./lib directory and not ./lib64 along with removing flags for the lib64 directory.

Remove deprecated build workflow

Remove deprecated build workflow

Few updates for the universal builds:

• Launcher update to remove versioned subdirectory
• Fixed postinstall script
• Fixed Ruby install internal layout
• Fixed installed directory permissions
• Resolved gem extension validation on non-build platform