VVV Monolithic Docker provider

Based on the work from @pentatonicfunk, I didn't have access to their github repo for this so here's a branch

Checks

[ ] I've updated the changelog.
[ ] I've tested this PR
[ ] This PR is for the develop branch not the stable branch.
[ ] This PR is complete and ready for review.

Sep 11 '22 16:09 tomjn

Thanks for opening this pull request! Make sure CHANGELOG.md gets updated with this change, additionally any docs that need updated can be found at https://github.com/Varying-Vagrant-Vagrants/varyingvagrantvagrants.org

GitHub
GitHub - Varying-Vagrant-Vagrants/varyingvagrantvagrants.org: The VVV docs and website
The VVV docs and website. Contribute to Varying-Vagrant-Vagrants/varyingvagrantvagrants.org development by creating an account on GitHub.

Sep 11 '22 16:09 update-docs[bot]

@tomjn so i've tested this branch, and it worked fine with docker you can view the generated log here: https://gist.github.com/pentatonicfunk/ae8a5d54a568dc65eeb77c7a9545ca40 , see if anything noticeable we should fix / improve.

verified, vvv.test, phpmyadmin and one.wordpress.test

tested wp-cli

hendrawan@ubuntu-builder-dump:~/vvv-local$ vagrant ssh
vagrant@vvv:~$ cd /srv/www/wordpress-one/public_html/
vagrant@vvv:/srv/www/wordpress-one/public_html$ wp --help
vagrant@vvv:/srv/www/wordpress-one/public_html$ wp user list
+----+------------+--------------+------------------+---------------------+---------------+
| ID | user_login | display_name | user_email       | user_registered     | roles         |
+----+------------+--------------+------------------+---------------------+---------------+
| 1  | admin      | admin        | [email protected] | 2022-09-13 16:33:32 | administrator |
+----+------------+--------------+------------------+---------------------+---------------+

tested php-debug

vagrant@vvv:/srv/www/wordpress-one/public_html$ switch_php_debugmod xdebug
 * Making sure log/php/xdebug-remote.log is readable and present
 * Enabling 'xdebug' for PHP v7.4
 * Restarting PHP FPM services so that the change takes effect
 * Restarting PHP 7.4 FastCGI Process Manager php-fpm7.4                                                                                                                                                                                                                                                                                                                                                                                                                             [ OK ]
 ✔ PHP Debug mod switch to xdebug on all available PHP versions complete.
vagrant@vvv:/srv/www/wordpress-one/public_html$ switch_php_debugmod none
Xdebug: [Log Files] File '/var/log/php/xdebug-remote.log' could not be opened.
 ✘ Disabling active PHP v7.4 debug mod: 'xdebug'
 * Restarting PHP FPM services so that the change takes effect
 * Restarting PHP 7.4 FastCGI Process Manager php-fpm7.4                                                                                                                                                                                                                                                                                                                                                                                                                             [ OK ]
 ✔ All PHP Debug mods are now turned off.

now couple of things that we might wanna improve

ntpdate

default: 13 Sep 16:34:08 ntpdate[29157]: Can't adjust the time of day: Operation not permitted
default:  - clock synchronisation failed

we might wanna exclude this for docker, as this isn't available in docker. I'll check tomorrow see if can patch the provision to skip it for docker

mysq/debian.cnf this file https://github.com/Varying-Vagrant-Vagrants/VVV/pull/2632/files#diff-8362b383445f6f81f9502cee31bd037fccbfe2ed2fa4073050a5d908635fa36e, we discussed in the past. and i still dont know why without it docker acted funky, i will try to debug this more, see if we can remove this requirement as its not the case on other provider
VVV_DOCKER anything we should do about this ?
MacOS specific provision test Since changes also has specific MacOS commands, should i give it a test ? im thinking to use scaleway, they provide mac mini m1 server. Not sure if we can integrate it into Github Actions ?

Gist
vvv-docker-1.log
GitHub Gist: instantly share code, notes, and snippets.

GitHub
Monolithic Docker provider by tomjn · Pull Request #2632 · Varying-Vagrant-Vagrants/VVV
Based on the work from @pentatonicfunk, I didn't have access to their github repo for this so here's a branch Checks
I've updated the changelog. I've tested this PR This PR is ...

Sep 13 '22 16:09 pentatonicfunk

VVV_DOCKER was what I used when I tried to run VVV provisioners with a docker config to indicate if the provisioner was in a docker environment, and if so to skip certain things

MacOS specific provision test

I can do this later in the week, I've 2 days off

mysq/debian.cnf

Lets keep it, but we need to make sure it only happens when docker is the provider, I don't know what impact this will have on non-docker users

ntpdate

agreed, we can skip this if we're running on docker

Sep 13 '22 17:09 tomjn

what do you think is the best to detect that we are running in docker here ? was thinking to add a provision helpers function

function vvv_is_in_docker() {
   if [ ! -f /.dockerenv ] && [ ! -f /run/.containerenv ]; then
       return 0
   fi
   return 1
}

or do you think adding env in Vagrantfile would be better something like VVV_PROVIDER ?, though im not sure it would work in trigger since it doesn't support env option in run

Sep 14 '22 13:09 pentatonicfunk

A vvv_provider function or an environment variable set from the vagrant file sounds ideal at the moment

Ideally we would be able to tell from the environment itself if a step is necessary without knowing the providers, eg detecting folders or systemd rather than docker itself

On Wed, 14 Sep 2022 at 14:30, Hendrawan Kuncoro @.***> wrote:

what do you think is the best to detect that we are running in docker here ? was thinking to add a provision helpers function

function vvv_is_in_docker() { if [ ! -f /.dockerenv ] && [ ! -f /run/.containerenv ]; then return 0 fi return 1 }

or do you think adding env in Vagrantfile would be better something like VVV_PROVIDER ?, though im not sure it would work in trigger since it doesn't support env option in run

— Reply to this email directly, view it on GitHub https://github.com/Varying-Vagrant-Vagrants/VVV/pull/2632#issuecomment-1246768930, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAOLZYY3YVHREZZNZPCGA3V6HHOTANCNFSM6AAAAAAQJ2265A . You are receiving this because you were mentioned.Message ID: @.***>

Sep 14 '22 13:09 tomjn

@pentatonicfunk I tried to test this, I changed provider: docker started up the docker engine, and ran vagrant up --provision. I ran into problems almost immediatley with networking and port 80 being in use.

Is there more to getting this running than the standard vagrant up? Are you trying to use sudo? To my knowledge applications can only bind to ports below 1000 on MacOS if they're the root user, but sudo vagrant is an eldritch horror to be avoided at all costs

Sep 16 '22 14:09 tomjn

We also need to resolve the docker image problem, we need either a generic image or one we can generate ourselves given steps

Sep 16 '22 14:09 tomjn

❯ vagrant up --provision       
__ __ __ __
\ V\ V\ V / v3.11 Ruby:2.7.6, Path:"/Users/tomjn/dev/vvvdocker"
 \_/\_/\_/  git::docker-provider(3ee80e47)

Platform: darwin19 shell:/bin/zsh vagrant-goodhosts shared_db_folder_disabled
Vagrant: v2.3.0, docker: v??

Docs:       https://varyingvagrantvagrants.org/
Contribute: https://github.com/varying-vagrant-vagrants/vvv
Dashboard:  http://vvv.test

Bringing machine 'default' up with 'docker' provider...
==> default: Running action triggers before up ...
==> default: Running trigger: VVV Setup docker local network before up...
    default: Running local: Inline script
    default: bash -c 'sudo ifconfig lo0 alias 192.168.56.4/24'
==> default: Creating and configuring docker networks...
Vagrant cannot forward the specified ports on this VM, since they
would collide with some other application that is already listening
on these ports. The forwarded port to 80 is already in use
on the host machine.

To fix this, modify your current project's Vagrantfile to use another
port. Example, where '1234' would be replaced by a unique host port:

  config.vm.network :forwarded_port, guest: 80, host: 1234

Sometimes, Vagrant will attempt to auto-correct this for you. In this
case, Vagrant was unable to. This is usually because the guest machine
is in a state which doesn't allow modifying port forwarding. You could
try 'vagrant reload' (equivalent of running a halt followed by an up)
so vagrant can attempt to auto-correct this upon booting. Be warned
that any unsaved work might be lost.

Sep 16 '22 14:09 tomjn

We also need to resolve the docker image problem, we need either a generic image or one we can generate ourselves given steps

yea for sure, it should be straightforward, this is the image that i've been using: https://github.com/pentatonicfunk/docker-vagrant-ubuntu-base-images/blob/main/20.04/Dockerfile we can maybe provide under VVV instead

for the failed provision. NO i dont use sudo for vagrant @tomjn is it maybe you already have another setup that using 192.168.56.4 ? i think i had similar issue in the past, even on linux, i tested vvv with VB, then destroy, after that switch to docker, it couldn't create the network, so its not mac specific. I think destroy still residue the VB network and need to be manually removed.

GitHub
docker-vagrant-ubuntu-base-images/Dockerfile at main · pentatonicfunk/docker-vagrant-ubuntu-base-images
Vagrant compatible Ubuntu docker images. Contribute to pentatonicfunk/docker-vagrant-ubuntu-base-images development by creating an account on GitHub.

Sep 16 '22 14:09 pentatonicfunk

vagrant global-status shows no active VMs or vagrant environments other than the docker environment which says preparing but never goes anywhere. I don't believe it even reaches the stage where it can do docker related things because of this. I can find no applications using port 80 on my machine

Of note I'm on an M1 machine so it's not possible to install VirtualBox, and Parallels is unlaunched

Sep 16 '22 14:09 tomjn

ah yea, no VB on M1 the port mapping is part of docker command

# Docker use image.
  config.vm.provider :docker do |d|
    d.image = 'pentatonicfunk/vagrant-ubuntu-base-images:20.04'
    d.has_ssh = true
    if Vagrant::Util::Platform.platform == 'darwin19'
      # Docker in mac need explicit ports publish to access
      d.ports = [ "#{vvv_config['vm_config']['private_network_ip']}:80:80" ]
      d.ports += [ "#{vvv_config['vm_config']['private_network_ip']}:443:443" ]
      d.ports += [ "#{vvv_config['vm_config']['private_network_ip']}:3306:3306" ]
      d.ports += [ "#{vvv_config['vm_config']['private_network_ip']}:8025:8025" ]
      d.ports += [ "#{vvv_config['vm_config']['private_network_ip']}:1025:1025" ]
    end
  end

so at least we know it attempt to execute docker command. its just can't bind to 80, so the most likely culprit is 80 already bind / opened by something, but you confirmed there is none

any chance you would try this ? see if maybe it shows something

❯ lsof -i -P | grep -i "listen" | grep -i ":80"
com.docke  1396 hendrawan  233u  IPv4 0x74827ad49f2952c9      0t0  TCP subdir.wordpress.test:80 (LISTEN)
com.docke  1396 hendrawan  236u  IPv4 0x74827ad49d6627f9      0t0  TCP subdir.wordpress.test:8025 (LISTEN)

Sep 16 '22 15:09 pentatonicfunk

launchd       1           root   19u  IPv6 0x1883043d49fd0667      0t0    TCP localhost:8021 (LISTEN)
launchd       1           root   20u  IPv4 0x188304507a810717      0t0    TCP localhost:8021 (LISTEN)
launchd       1           root   34u  IPv6 0x1883043d49fd0667      0t0    TCP localhost:8021 (LISTEN)
launchd       1           root   35u  IPv4 0x188304507a810717      0t0    TCP localhost:8021 (LISTEN)
prl_naptd   936           root   25u  IPv4 0x1883045072433177      0t0    TCP *:8000 (LISTEN)

Sep 16 '22 15:09 tomjn

alright, let me try m1 on scaleway, see if i can replicate

Sep 16 '22 15:09 pentatonicfunk

i was able to provision on M1

though it stopped in this step, probably need to enable new VM framework experimental on docker

but confirmed that docker container successfully created

Sep 16 '22 15:09 pentatonicfunk

hmm the dubious ownership issue should have been resolved in 3.9, I'm still no closer to identifying what has taken port 80 and have made no further progress

Sep 16 '22 16:09 tomjn

yea, that port 80 is annoying. since mojave, MacOS should allow binding lower ports without lifted privilege https://news.ycombinator.com/item?id=18302380

Now in 10.14, any application, regardless of the user's privileges, can bind to typical reserved ports, such as 22, 80, 443, etc. etc.

so shouldn't be about sudo thing

there is sample container in here: https://docs.docker.com/get-started/ that binding 80 port, see if its working on your setup. if it doesn't work, then we can pin down the issue is between docker and macos it self, not vvv / vagrant related.

docker run -d -p 80:80 docker/getting-started

MacOS Mojave 10.14 no longer enforces privileged ports | Hacker News

Docker Documentation
Orientation and setup
Get oriented on some basics of Docker and install Docker Desktop.

Sep 16 '22 17:09 pentatonicfunk

I can run Altis Local Server fine which relies on a Traefik proxy container, though I can confirm those containers or any others were not running.

I can get past this error if I use sudo vagrant up but then run into another problem:

vvvdocker on  docker-provider via ⍱ v2.3.0 
❯ sudo vagrant up
┌-──────────────────────────────────────────────────────────────────────────────┐
│                                                                               │
│  ⚠ DANGER DO NOT USE SUDO ⚠                                                   │
│                                                                               │
│ ! ▄▀▀▀▄▄▄▄▄▄▄▀▀▀▄ !  You should never use sudo or root with vagrant.          │
│  !█▒▒░░░░░░░░░▒▒█    It causes lots of problems :(                            │
│    █░░█░▄▄░░█░░█ !                                                            │
│     █░░█░░█░▄▄█    ! We're really sorry but you may need to do painful        │
│  !  ▀▄░█░░██░░█      cleanup commands to fix this.                            │
│                                                                               │
│  If vagrant does not work for you without sudo, open a GitHub issue instead   │
│  In the future, this warning will halt provisioning to prevent new users      │
│  making this mistake.                                                         │
│                                                                               │
│  ⚠ DANGER SUDO DETECTED!                                                      │
│                                                                               │
│  In the future the VVV team will be making it harder to use VVV with sudo.    │
│  We will require a config option so that users can do data recovery, and      │
│  disable sites and the dashboard.                                             │
│                                                                               │
│  DO NOT USE SUDO, use ctrl+c/cmd+c and cancel this command ASAP!!!            │
│                                                                               │
└───────────────────────────────────────────────────────────────────────────────┘
 
 ⚠ DANGER VAGRANT IS RUNNING AS ROOT/SUDO, DO NOT USE SUDO ⚠
 
__ __ __ __
\ V\ V\ V / v3.11 Ruby:2.7.6, Path:"/Users/tomjn/dev/vvvdocker"
 \_/\_/\_/  git::docker-provider(3ee80e47)

Platform: darwin19 shell:/bin/sh vagrant-goodhosts shared_db_folder_disabled
Vagrant: v2.3.0, docker: v??

Docs:       https://varyingvagrantvagrants.org/
Contribute: https://github.com/varying-vagrant-vagrants/vvv
Dashboard:  http://vvv.test

Bringing machine 'default' up with 'docker' provider...
==> default: Running action triggers before up ...
==> default: Running trigger: VVV Setup docker local network before up...
    default: Running local: Inline script
    default: bash -c 'sudo ifconfig lo0 alias 192.168.56.4/24'
==> default: Creating and configuring docker networks...
Traceback (most recent call last):
	126: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/batch_action.rb:86:in `block (2 levels) in run'
	125: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/machine.rb:203:in `action'
	124: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/machine.rb:203:in `call'
	123: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/environment.rb:631:in `lock'
	122: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/machine.rb:217:in `block in action'
	121: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/machine.rb:248:in `action_raw'
	120: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `run'
	119: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/util/busy.rb:19:in `busy'
	118: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `block in run'
	117: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builder.rb:180:in `call'
	116: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	115: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/delayed.rb:19:in `call'
	114: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	113: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/trigger.rb:32:in `call'
	112: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	111: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/call.rb:53:in `call'
	110: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `run'
	109: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/util/busy.rb:19:in `busy'
	108: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `block in run'
	107: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builder.rb:180:in `call'
	106: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	105: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
	104: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	103: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
	102: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	101: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
	100: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 99: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/host_machine.rb:18:in `call'
	 98: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 97: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/call.rb:53:in `call'
	 96: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `run'
	 95: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/util/busy.rb:19:in `busy'
	 94: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `block in run'
	 93: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builder.rb:180:in `call'
	 92: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 91: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
	 90: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 89: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
	 88: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 87: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/call.rb:53:in `call'
	 86: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `run'
	 85: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/util/busy.rb:19:in `busy'
	 84: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `block in run'
	 83: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builder.rb:180:in `call'
	 82: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 81: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
	 80: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 79: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/call.rb:53:in `call'
	 78: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `run'
	 77: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/util/busy.rb:19:in `busy'
	 76: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `block in run'
	 75: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builder.rb:180:in `call'
	 74: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 73: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
	 72: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 71: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/provision.rb:80:in `call'
	 70: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 69: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
	 68: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 67: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/call.rb:53:in `call'
	 66: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `run'
	 65: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/util/busy.rb:19:in `busy'
	 64: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `block in run'
	 63: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builder.rb:180:in `call'
	 62: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 61: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
	 60: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 59: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/env_set.rb:19:in `call'
	 58: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 57: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
	 56: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 55: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/host_machine_build_dir.rb:19:in `call'
	 54: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 53: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/host_machine_sync_folders.rb:23:in `call'
	 52: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 51: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/prepare_nfs_valid_ids.rb:14:in `call'
	 50: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 49: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/synced_folders/nfs/action_cleanup.rb:25:in `call'
	 48: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 47: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/synced_folder_cleanup.rb:28:in `call'
	 46: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 45: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/prepare_nfs_settings.rb:15:in `call'
	 44: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 43: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/prepare_networks.rb:364:in `call'
	 42: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 41: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/login.rb:32:in `call'
	 40: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 39: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/build.rb:24:in `call'
	 38: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 37: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/call.rb:53:in `call'
	 36: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `run'
	 35: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/util/busy.rb:19:in `busy'
	 34: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `block in run'
	 33: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builder.rb:180:in `call'
	 32: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 31: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
	 30: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 29: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/env_set.rb:19:in `call'
	 28: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 27: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/host_machine_port_warning.rb:11:in `call'
	 26: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 25: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/host_machine_port_checker.rb:14:in `call'
	 24: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 23: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/forwarded_ports.rb:28:in `call'
	 22: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 21: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/prepare_forwarded_port_collision_params.rb:36:in `call'
	 20: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
	 19: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:44:in `call'
	 18: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/environment.rb:631:in `lock'
	 17: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:45:in `block in call'
	 16: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:101:in `handle'
	 15: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:281:in `with_forwarded_ports'
	 14: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:281:in `each'
	 13: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:285:in `block in with_forwarded_ports'
	 12: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:124:in `block in handle'
	 11: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:293:in `call_port_checker'
	 10: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/prepare_forwarded_port_collision_params.rb:31:in `block in call'
	  9: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:276:in `port_check'
	  8: from /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/util/is_port_open.rb:17:in `is_port_open?'
	  7: from /opt/vagrant/embedded/lib/ruby/2.7.0/socket.rb:632:in `tcp'
	  6: from /opt/vagrant/embedded/lib/ruby/2.7.0/socket.rb:227:in `foreach'
	  5: from /opt/vagrant/embedded/lib/ruby/2.7.0/socket.rb:227:in `each'
	  4: from /opt/vagrant/embedded/lib/ruby/2.7.0/socket.rb:642:in `block in tcp'
	  3: from /opt/vagrant/embedded/lib/ruby/2.7.0/socket.rb:137:in `connect'
	  2: from /opt/vagrant/embedded/lib/ruby/2.7.0/socket.rb:56:in `connect_internal'
	  1: from /opt/vagrant/embedded/lib/ruby/2.7.0/socket.rb:1214:in `connect_nonblock'
/opt/vagrant/embedded/lib/ruby/2.7.0/socket.rb:1214:in `__connect_nonblock': Can't assign requested address - connect(2) for 127.0.0.1:2222 (Errno::EADDRNOTAVAIL)

vvvdocker on  docker-provider via ⍱ v2.3.0 took 3s 
❯

Sep 17 '22 21:09 tomjn

I'm getting that stack trace now wether I use sudo or not, which is frustrating. Can someone else confirm if it works for them? At this point any data is useful, MacOS or not.

Sep 17 '22 22:09 tomjn

okay one thing that we haven't tried --debug and finally i was able to replicate your 80 port conflict issue you had on scaleway. But its because i was having docker run -d -p 80:80 docker/getting-started running

....
 INFO warden: Calling IN action: #<VagrantPlugins::DockerProvider::Action::PrepareNFSValidIds:0x00007f906f0625c8>
 INFO subprocess: Starting process: ["/usr/local/bin/docker", "ps", "-a", "-q", "--no-trunc"]
....
 INFO subprocess: Starting process: ["/usr/local/bin/docker", "network", "ls", "--format={{.Name}}"]
....
 INFO subprocess: Starting process: ["/usr/local/bin/docker", "network", "inspect", "bridge", "host", "none"]
....
 INFO subprocess: Starting process: ["/usr/local/bin/docker", "network", "ls", "--format={{.Name}}"]
DEBUG subprocess: Command not in installer, not touching env vars.
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
 INFO subprocess: Starting process: ["/usr/local/bin/docker", "network", "inspect", "bridge", "host", "none"]
DEBUG subprocess: Command not in installer, not touching env vars.
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
 INFO subprocess: Starting process: ["/usr/local/bin/docker", "network", "ls", "--format={{.Name}}"]
DEBUG subprocess: Command not in installer, not touching env vars.
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
DEBUG preparenetworks: Creating network vagrant_network_192.168.56.0/24
 INFO subprocess: Starting process: ["/usr/local/bin/docker", "network", "create", "vagrant_network_192.168.56.0/24", "--subnet", "192.168.56.0/24"]
DEBUG subprocess: Command not in installer, not touching env vars.
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
 INFO environment: Released process lock: docker-network-create
...
 INFO subprocess: Starting process: ["/usr/local/bin/docker", "ps", "-a", "-q", "--no-trunc"]
....
 INFO subprocess: Starting process: ["/usr/local/bin/docker", "ps", "-a", "-q", "--no-trunc"]
...
 INFO subprocess: Starting process: ["/usr/local/bin/docker", "inspect", "6bc0b9f6a13a8bdf340c3b71c387c3743b1acc5b910717fe1bf040804a0c572e"]
DEBUG subprocess: Command not in installer, not touching env vars.
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
 INFO warden: Calling IN action: #<Vagrant::Action::Builtin::HandleForwardedPortCollisions:0x00007f904f736b30>
DEBUG environment: Attempting to acquire process-lock: fpcollision
DEBUG environment: Attempting to acquire process-lock: dotlock
 INFO environment: Acquired process lock: dotlock
 INFO environment: Released process lock: dotlock
 INFO environment: Acquired process lock: fpcollision
 INFO handle_port_collisions: Detecting any forwarded port collisions...
DEBUG handle_port_collisions: Extra in use: {"80"=>#<Set: {"*"}>}
DEBUG handle_port_collisions: Remap: {}
DEBUG handle_port_collisions: Repair: true
 INFO environment: Released process lock: fpcollision
ERROR warden: Error occurred: Vagrant cannot forward the specified ports on this VM, since they
would collide with some other application that is already listening
on these ports. The forwarded port to 80 is already in use
on the host machine.

To fix this, modify your current project's Vagrantfile to use another
port. Example, where '1234' would be replaced by a unique host port:

  config.vm.network :forwarded_port, guest: 80, host: 1234

Sometimes, Vagrant will attempt to auto-correct this for you. In this
case, Vagrant was unable to. This is usually because the guest machine
is in a state which doesn't allow modifying port forwarding. You could
try 'vagrant reload' (equivalent of running a halt followed by an up)
so vagrant can attempt to auto-correct this upon booting. Be warned
that any unsaved work might be lost.
 INFO warden: Beginning recovery process...
 INFO warden: Calling recover: #<Vagrant::Action::Builtin::HandleForwardedPortCollisions:0x00007f904f736b30>
 INFO warden: Recovery complete.
 INFO warden: Beginning recovery process...
 INFO warden: Recovery complete.
 INFO warden: Beginning recovery process...
 INFO warden: Recovery complete.
 INFO warden: Beginning recovery process...
 INFO warden: Recovery complete.
 INFO warden: Beginning recovery process...
 INFO warden: Recovery complete.
 INFO warden: Beginning recovery process...
 INFO warden: Recovery complete.
ERROR warden: Error occurred: Vagrant cannot forward the specified ports on this VM, since they
would collide with some other application that is already listening
on these ports. The forwarded port to 80 is already in use
on the host machine.

....
ERROR vagrant: /opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:129:in `block in handle'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:285:in `block in with_forwarded_ports'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:281:in `each'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:281:in `with_forwarded_ports'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:101:in `handle'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:45:in `block in call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/environment.rb:631:in `lock'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:44:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/prepare_forwarded_port_collision_params.rb:36:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/forwarded_ports.rb:28:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/host_machine_port_checker.rb:14:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/host_machine_port_warning.rb:11:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/env_set.rb:19:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builder.rb:180:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `block in run'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `run'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/call.rb:53:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/build.rb:24:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/login.rb:32:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/prepare_networks.rb:364:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/prepare_nfs_settings.rb:15:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/synced_folder_cleanup.rb:28:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/synced_folders/nfs/action_cleanup.rb:25:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/prepare_nfs_valid_ids.rb:14:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/host_machine_sync_folders.rb:23:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/host_machine_build_dir.rb:19:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/init_state.rb:15:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builder.rb:180:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `block in run'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `run'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/call.rb:53:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/provision.rb:80:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builder.rb:180:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `block in run'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `run'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/call.rb:53:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builder.rb:180:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `block in run'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `run'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/call.rb:53:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/destroy_build_image.rb:43:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_box.rb:25:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builder.rb:180:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `block in run'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `run'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/call.rb:53:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/plugins/providers/docker/action/host_machine.rb:18:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/handle_box.rb:25:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:127:in `block in finalize_action'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builder.rb:180:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `block in run'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `run'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/call.rb:53:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/trigger.rb:32:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builtin/delayed.rb:19:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/warden.rb:48:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/builder.rb:180:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `block in run'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/action/runner.rb:101:in `run'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/machine.rb:248:in `action_raw'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/machine.rb:217:in `block in action'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/environment.rb:631:in `lock'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/machine.rb:203:in `call'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/machine.rb:203:in `action'
/opt/vagrant/embedded/gems/2.3.0/gems/vagrant-2.3.0/lib/vagrant/batch_action.rb:86:in `block (2 levels) in run'
 INFO interface: error: Vagrant cannot forward the specified ports on this VM, since they
would collide with some other application that is already listening
on these ports. The forwarded port to 80 is already in use
on the host machine.

To fix this, modify your current project's Vagrantfile to use another
port. Example, where '1234' would be replaced by a unique host port:

  config.vm.network :forwarded_port, guest: 80, host: 1234

Sometimes, Vagrant will attempt to auto-correct this for you. In this
case, Vagrant was unable to. This is usually because the guest machine
is in a state which doesn't allow modifying port forwarding. You could
try 'vagrant reload' (equivalent of running a halt followed by an up)
so vagrant can attempt to auto-correct this upon booting. Be warned
that any unsaved work might be lost.
Vagrant cannot forward the specified ports on this VM, since they
would collide with some other application that is already listening
on these ports. The forwarded port to 80 is already in use
on the host machine.

....
 INFO interface: Machine: error-exit ["Vagrant::Errors::ForwardPortCollision", "Vagrant cannot forward the specified ports on this VM, since they\nwould collide with some other application that is already listening\non these ports. The forwarded port to 80 is already in use\non the host machine.\n\nTo fix this, modify your current project's Vagrantfile to use another\nport. Example, where '1234' would be replaced by a unique host port:\n\n  config.vm.network :forwarded_port, guest: 80, host: 1234\n\nSometimes, Vagrant will attempt to auto-correct this for you. In this\ncase, Vagrant was unable to. This is usually because the guest machine\nis in a state which doesn't allow modifying port forwarding. You could\ntry 'vagrant reload' (equivalent of running a halt followed by an up)\nso vagrant can attempt to auto-correct this upon booting. Be warned\nthat any unsaved work might be lost."]

after stopped that getting-started container, and then docker container prone + docker network prune i was able to run provision again, but still stopped at that dubious git thing, also annoying since i was able to help setup this completely on my mac on the past and my friend's mac couple of weeks ago 😓

Sep 18 '22 01:09 pentatonicfunk

so about detected dubious ownership

i found weird thing, so if i do this manually it works

root@vvv:/srv/provision/extensions/core# sudo -EH -u "vagrant" git pull origin master
From https://github.com/Varying-Vagrant-Vagrants/vvv-utilities
 * branch            master     -> FETCH_HEAD
Already up to date.

but if i put it to sh script, it doesn't

#ttt.sh
function noroot() {
  sudo -EH -u "vagrant" "$@";
}

noroot git pull origin "${BRANCH}" -q

-----

root@vvv:/srv/provision/extensions/core# bash ttt.sh
fatal: detected dubious ownership in repository at '/srv/provision/extensions/core'
To add an exception for this directory, call:

	git config --global --add safe.directory /srv/provision/extensions/core

pasting here, just in case anybody had any ideas. i need to setup my working env

Update

another interesting behavior

#ttt.sh
function noroot() {
  sudo -EH -u "vagrant" "$@";
}

#noroot ls -al
noroot git pull origin master

root@vvv:/srv/provision/extensions/core# bash ttt.sh
fatal: detected dubious ownership in repository at '/srv/provision/extensions/core'
To add an exception for this directory, call:

	git config --global --add safe.directory /srv/provision/extensions/core

BUT, enabling ls -al made it work

#ttt.sh
function noroot() {
  sudo -EH -u "vagrant" "$@";
}

noroot ls -al
noroot git pull origin master

root@vvv:/srv/provision/extensions/core# bash ttt.sh
total 24
drwxr-xr-x  32 vagrant vagrant 1024 Sep 29 22:19 .
drwxr-xr-x   3 root    root      96 Sep 29 21:34 ..
-rw-r--r--   1 vagrant vagrant   57 Sep 29 21:34 .codacy.yml
drwxr-xr-x  15 vagrant vagrant  480 Sep 29 22:16 .git
-rw-r--r--   1 vagrant vagrant   39 Sep 29 21:34 .gitignore
-rw-r--r--   1 vagrant vagrant 1594 Sep 29 21:34 CONTRIBUTING.md
-rw-r--r--   1 vagrant vagrant 1107 Sep 29 21:34 LICENSE
-rw-r--r--   1 vagrant vagrant 1380 Sep 29 21:34 README.md
drwxr-xr-x   4 vagrant vagrant  128 Sep 29 21:34 graphviz
drwxr-xr-x   4 vagrant vagrant  128 Sep 29 21:34 memcached-admin
drwxr-xr-x   7 vagrant vagrant  224 Sep 29 21:34 mongodb
drwxr-xr-x   4 vagrant vagrant  128 Sep 29 21:34 nvm
drwxr-xr-x   4 vagrant vagrant  128 Sep 29 21:34 opcache-gui
drwxr-xr-x   4 vagrant vagrant  128 Sep 29 21:34 opcache-status
drwxr-xr-x   3 vagrant vagrant   96 Sep 29 21:34 php
drwxr-xr-x   7 vagrant vagrant  224 Sep 29 21:34 php56
drwxr-xr-x   7 vagrant vagrant  224 Sep 29 21:34 php70
drwxr-xr-x   7 vagrant vagrant  224 Sep 29 21:34 php71
drwxr-xr-x   7 vagrant vagrant  224 Sep 29 21:34 php72
drwxr-xr-x   7 vagrant vagrant  224 Sep 29 21:34 php73
drwxr-xr-x   7 vagrant vagrant  224 Sep 29 21:34 php74
drwxr-xr-x   7 vagrant vagrant  224 Sep 29 21:34 php80
drwxr-xr-x   7 vagrant vagrant  224 Sep 29 21:34 php81
drwxr-xr-x   5 vagrant vagrant  160 Sep 29 21:34 phpmyadmin
drwxr-xr-x   4 vagrant vagrant  128 Sep 29 21:34 svn-folder-upgrade
drwxr-xr-x  10 vagrant vagrant  320 Sep 29 21:34 tideways
drwxr-xr-x   7 vagrant vagrant  224 Sep 29 21:34 tls-ca
drwxr-xr-x   5 vagrant vagrant  160 Sep 29 21:34 trusted-hosts
-rw-r--r--+  1 vagrant vagrant   97 Sep 29 22:19 ttt.sh
drwxr-xr-x   5 vagrant vagrant  160 Sep 29 21:34 webgrind
drwxr-xr-x   4 vagrant vagrant  128 Sep 29 21:34 wpcli-dev
drwxr-xr-x   3 vagrant vagrant   96 Sep 29 21:34 yarn
From https://github.com/Varying-Vagrant-Vagrants/vvv-utilities
 * branch            master     -> FETCH_HEAD
Already up to date.

what is happening 😿

Sep 29 '22 22:09 pentatonicfunk

Is there a vagrant user in the container that also owns all the mounted folders?

I rarely run vagrant with the debug flag as it has so much unnecessary information that it makes parsing anything useful out of it very difficult.

I also don’t have the getting started container running. I had Altis local server with traefik but I shut that down then restarted the docker engine with no difference. If we can’t run traefik or other equivalent proxies then this eliminates docker + vagrant as a viable option for many people

Is forwarding the ports absolutely necessary for provisioning? Can that be a separate task?

Sep 29 '22 22:09 tomjn

Is there a vagrant user in the container that also owns all the mounted folders? all dir in /srv owned by vagrant

vagrant@vvv:~$ cd /srv/
vagrant@vvv:/srv$ ls -al
total 8
drwxr-xr-x  1 root    root    4096 Sep 29 22:41 .
drwxr-xr-x  1 root    root    4096 Sep 29 22:41 ..
drwxr-xr-x  2 vagrant vagrant   64 Sep 29 21:29 certificates
drwxr-xr-x  9 vagrant vagrant  288 Sep 29 21:18 config
drwxr-xr-x  5 vagrant vagrant  160 Sep 26 15:02 database
drwxr-xr-x 13 vagrant vagrant  416 Sep 29 21:34 provision
drwxr-xr-x  5 vagrant vagrant  160 Sep 29 21:33 www

this noroot and git dubious issue didn't happen on my prev mac mini setup, no clue what happen here, could be docker side, or somewhere else

Is forwarding the ports absolutely necessary for provisioning? in the past i tried without port forward, it didn't work, i believe localhost worked, though our setup is vvv.test so its unable to understand localhost

Sep 29 '22 22:09 pentatonicfunk

so turns out in my prev setup there is gitconfig in home vagrant

root@vvv:/srv/provision/extensions/core# cat /home/vagrant/.gitconfig
[safe]
	directory = /srv/provision/extensions/core
	directory = /srv/www/default/dashboard
	directory = /srv/www/default/opcache-statu
	directory = /srv/www/default/opcache-status
	directory = /srv/www/wordpress-one
	directory = /srv/www/wordpress-two
	directory = /srv/www/wordpress-eight
	directory = /srv/www/wordpress-five
	directory = /srv/www/wordpress-four
	directory = /srv/www/wordpress-multi-subdir
	directory = /srv/www/wordpress-multi-subdir-five
	directory = /srv/www/wordpress-multi-subdir-four
	directory = /srv/www/wordpress-multi-subdir-three
	directory = /srv/www/wordpress-multi-subdir-two
	directory = /srv/www/wordpress-multi-subdom
	directory = /srv/www/wordpress-multi-subdom-five
	directory = /srv/www/wordpress-multi-subdom-four
	directory = /srv/www/wordpress-multi-subdom-three
	directory = /srv/www/wordpress-multi-subdom-two
	directory = /srv/www/wordpress-nine
	directory = /srv/www/wordpress-seven
	directory = /srv/www/wordpress-six
	directory = /srv/www/wordpress-ten
	directory = /srv/www/wordpress-three
	directory = /srv/www/wordpress-two
	directory = /srv/www/site-reports

meanwhile on my current setup, there is no gitconfig

root@vvv:/srv/provision/extensions/core# ls -al /home/vagrant/.gitconfig
ls: cannot access '/home/vagrant/.gitconfig': No such file or directory

i wonder is VVV supposed to maintain this gitconfig safe directory, or is it automatically added by something else ?

Sep 29 '22 23:09 pentatonicfunk

It’s not something VVV adds it may be something git is adding

Sep 30 '22 12:09 tomjn

@pentatonicfunk my suspicion is that the port 80 issue is related to Parallels, which is very unfortunate if that's the case.

Is there no way to remove the port 80 forward requirement? Even if it means changing URLs to use a different port or some other manual workaround? I'd like to get this to a point where I can actually start it, even if it's not a final setup

Oct 31 '22 17:10 tomjn

Noting that if I comment out the ports, it does create the container and start provisioning.

Is it possible Traefik could be used to handle the domain/routing?

Oct 31 '22 17:10 tomjn

@pentatonicfunk with https://developer.hashicorp.com/vagrant/docs/provisioning/docker it should be possible to use a generic ubuntu image, run an additional step to install missing packages and add the needed vagrant users, and others

This page details how to use a dockerfile https://developer.hashicorp.com/vagrant/docs/providers/docker/basics#dockerfiles

and networking info: https://developer.hashicorp.com/vagrant/docs/providers/docker/networking

Docker - Provisioning | Vagrant | HashiCorp Developer
Docker - Provisioning | Vagrant | HashiCorp Developer
The Vagrant Docker provisioner can automatically install Docker, pull Docker containers, and configure certain containers to run on boot.

Basic Usage - Docker Provider | Vagrant | HashiCorp Developer
Basic Usage - Docker Provider | Vagrant | HashiCorp Developer
The Docker provider in Vagrant behaves just like any other provider. If you are familiar with Vagrant already, then using the Docker provider should be intuitive and simple.

Networking - Docker Provider | Vagrant | HashiCorp Developer
Networking - Docker Provider | Vagrant | HashiCorp Developer
The Vagrant Docker provider supports using the private network using the `docker network` commands.

Nov 13 '22 17:11 tomjn

Ok, got it running on an M1 here, and did some "fancy" (not really) port mapping technique which should allow port mapping to work even if the default ones are used by parallels or something else.

What works or was fixed in this approach:

Provisioning
Docker version parser detected
Port Mapping when defaults are used.
HTTP (VVV default works)

What doesnt:

HTTPS (due to port mapping i assume)
IP Assignment does not work with Docker Desktop on mac ( see here ). That's why @pentatonicfunk had to do those complex ifconfig commands.
Due to the above, proper domain mapping without port forwarding cannot happen.

Ideas that I still don't fully know would work or fully tested:

Do not do domain mapping, and resort to lando's domains that point to 127.0.0.1?
Tweak nginx/mailhog/mariadb config to consider other ports than the native ones (80 or 443)? We would need to feed the "available ports" into the provisioner to tweak the ports used on provision time. Potentially on startup as well (in case these change across up/halts)?
Considering other docker engine providers for macos different to docker Desktop? I'd say this is highly unlikely to fix problems. Alternatives would be Podman (they have a desktop offering now here, Colima. These may or may not work due to licensing problems with Docker Desktop. That aside, they all have the same problem in MacOS that docker containers cannot properly get host accessible IPs assigned (based on what I read).
How are we doing on the Tart provider? Would work there be less conflictive than this?
Is libvirt even an option for VM management?

May 09 '23 18:05 msaggiorato

How are we doing on the Tart provider? Would work there be less conflictive than this?

Not quickly at all

Is libvirt even an option for VM management?

the instructions for how to install it on MacOS are far beyond the technical capabilities of almost our entire userbase. The vagrant plugin part is fine, but even I had trouble figuring out where to find the libvirt install instructions nevermind running what I found

May 09 '23 19:05 tomjn

What I had hoped is that we would use the same solution docker based systems use, aka a proxy such as Traefik or something based on Traefik

May 09 '23 19:05 tomjn

VVV VVV copied to clipboard

Monolithic Docker provider

Checks

Update

VVV
VVV copied to clipboard