search

Varying-Vagrant-Vagrants / VVV

An open source Vagrant configuration for developing with WordPress
https://varyingvagrantvagrants.org
MIT License
4.54k stars 848 forks source link

Tideways Provisioner Repeating "getcwd() failed: No such file or directory" error during installation on Arch Linux. #1762

Closed BobbyBabes closed 5 years ago

BobbyBabes commented 5 years ago

Expected Behavior

No errors during installation.

Current Behavior

One error (repeated 5 times) during installation. Exact same error on retry.

Possible Solution

No clue.

Steps to Reproduce (for bugs)

  1. Install Vagrant. I did from here : https://www.archlinux.org/packages/community/x86_64/vagrant/
  2. Follow installation instructions here : https://varyingvagrantvagrants.org/docs/en-US/installation/
  3. Error occurs while executing vagrant up in step 2 under Starting VVV. Towards the end.

Full log here : https://gist.github.com/BobbyBabes/c8da5939e051a6d5d356a07f362cb8ce This bit with errors, from line 1810 in the log :

    default: Setting up mongodb-org (3.4.20) ...
    default: Installing MongoDB for PHP 7.2
    default: Auto-removing mongoDB records older than 2592000 seconds (30 days)
    default: Restarting mongod
    default: mongod stop/waiting
    default: mongod start/running, process 5566
==> default: Running provisioner: utility-core-tideways (shell)...
    default: Running: /tmp/vagrant-shell20190423-3079-12jkya4.sh
    default: Installing Tideways & XHgui
    default: Cloning Tideways extension
    default: Cloning into '/var/local/tideways-php'...
    default: Installing Tideways for PHP 
    default: Copying tideways files for PHP 7.2
    default: Compiling Tideways for PHP 7.2
    default: sh: 0: 
    default: getcwd() failed: No such file or directory
    default: sh: 0: 
    default: getcwd() failed: No such file or directory
    default: sh: 0: 
    default: getcwd() failed: No such file or directory
    default: sh: 0: getcwd() failed: No such file or directory
    default: sh: 0: 
    default: getcwd() failed: No such file or directory
    default: sh: 0: getcwd() failed: No such file or directory
    default: sh: 0: 
    default: getcwd() failed: No such file or directory
    default: sh: 0: getcwd() failed: No such file or directory
    default: Git cloning xhgui from https://github.com/perftools/xhgui.git
    default: Cloning into 'xhgui'...
    default: Installing xhgui
    default: Downloading composer.
    default: All settings correct for using Composer
    default: Downloading...
    default: 
    default: Composer (version 1.8.5) successfully installed to: /srv/www/default/xhgui/composer.phar
    default: Use it: php composer.phar

EDIT 1: Added screenshot.

VVV-installation-error_20190423_202234

Context

The Dashboard at http://vvv.test/ looks OK. I'm trying to ascertain if I need to take any action before continuing with the installation of VV and VVV-Dashboard. Trying to prevent nasty surprises along the way. I already repeated the installation after cleaning up, which alas resulted in the exact same and only error.

Your Environment

tomjn commented 5 years ago

I don't know the cause, but those are all in the Tideways provisioner /cc @Mte90

The Dashboard at http://vvv.test/ looks OK.

And you're probably just fine except for Tideways/XHGui

This did catch my eye though:

I'm trying to ascertain if I need to take any action before continuing with the installation of VV and VVV-Dashboard. Trying to prevent nasty surprises along the way.

I can't vouch for VVV-Dashboard, but VV is a great way to give yourself nasty surprises, and I can guarantee it will cause problems.

The way it works was always flawed, it relies on SSH'ing into the VM and making manual changes. As a result its changes would always dissapear if you ran a vagrant destroy, but what it did was always fundamentally fragile, and caused many support issues over the years.

With the release of VVV 2, the vvv-config.yml based system was introduced, so it's super easy to add new sites. vv is no longer necessary, but as a result of the VVV 2 changes, it's not compatible. If you use vv, several things will happen:

  1. Any sites created with vv will not survive provisioning as the nginx configs get cleared out, but there is no provisioner to replace them
    1. Any sites that vv does create won't show up in the dashboard, and they won't work without being added to vvv-custom.yml
    2. Hosts won't be added unless they're in vvv-custom.yml

At which point you might as well use the far superior site template system, just add a site to the vvv-custom.yml file, and reprovision with vagrant reload --provision

Finally, to put the nail in the coffin,vv was abandoned many years ago.

I can't advise on wether VVV-Dashboard will work, but you can specify a git repo with a dashboard to clone from vvv-custom.yml

BobbyBabes commented 5 years ago

The 2 URLs that were added to /etc/hosts for Tideways and XHGui look OK in the browser though, displaying Looks like you haven't done any profiling To get started with XHGUI you'll need to collect some profiling data. etc. But of course the installation might still be borked when recording and providing profiling data.

But two of the other URLs vvv and vvv.dev have some issues in the browser though. See screenshots. No problem of course if they display the same info as vvv.test.

VVV_http-vvv_error_20190423_225627

VVV_http-vvv-dev_error_20190423_225809

Thanks for the heads up on VV. I'm trying to recreate, with newer versions, an ancient VVV with VV and VVV-Dasboard installed. I had not checked those two repos yet. Just did. And from several issues it's apparent that VV is abandoned, like you said. I'll stay away from both. ;-) I "inherited" this previously abandoned project. It's was abandoned by a volunteer/intern of a local charity, about 3 years ago. Never went live. They are trying to revive it now. This is the first of my (max 3 a year) pro deo projects. They get a free WP site, I learn my way around VVV.

tomjn commented 5 years ago

I've not seen someone go to http://vvv before, but some notes:

BobbyBabes commented 5 years ago

I'm not getting it. Then why add vvv.dev to the /etc/hosts file when it's going to be ignored? Allocating it a private IP address (192.168.50.4) in the range 192.168.0.0 - 192.168.255.255 is what sidetracked me. I just checked. And vvv.dev is indeed preloaded https://hstspreload.org/?domain=vvv.dev

And I was under the impression that a test site was created for vvv. Which clearly it is not. I only saw default, phpcs, wordpress-one, and wordpress-two in folder vagrant-local/www and assumed that vvv would go to default because vvv.test also does not have a similar named folder in vagrant-local/www/data So it makes me wonder which webroot folder vvv.test is serving it's pages from.

Here is what's added to /etc/hosts :

192.168.50.4  vvv  # VAGRANT: 254ecf5ed67f3f9bac659ec253835ee0 (default) / a0abbba7-eb55-4c6f-90f1-e3197ea18880
192.168.50.4  vvv.dev  # VAGRANT: 254ecf5ed67f3f9bac659ec253835ee0 (default) / a0abbba7-eb55-4c6f-90f1-e3197ea18880
192.168.50.4  vvv.test  # VAGRANT: 254ecf5ed67f3f9bac659ec253835ee0 (default) / a0abbba7-eb55-4c6f-90f1-e3197ea18880
192.168.50.4  vvv.local  # VAGRANT: 254ecf5ed67f3f9bac659ec253835ee0 (default) / a0abbba7-eb55-4c6f-90f1-e3197ea18880
192.168.50.4  vvv.localhost  # VAGRANT: 254ecf5ed67f3f9bac659ec253835ee0 (default) / a0abbba7-eb55-4c6f-90f1-e3197ea18880
192.168.50.4  one.wordpress.test  # VAGRANT: 254ecf5ed67f3f9bac659ec253835ee0 (default) / a0abbba7-eb55-4c6f-90f1-e3197ea18880
192.168.50.4  two.wordpress.test  # VAGRANT: 254ecf5ed67f3f9bac659ec253835ee0 (default) / a0abbba7-eb55-4c6f-90f1-e3197ea18880
192.168.50.4  tideways.vvv.test  # VAGRANT: 254ecf5ed67f3f9bac659ec253835ee0 (default) / a0abbba7-eb55-4c6f-90f1-e3197ea18880
192.168.50.4  xhgui.vvv.test  # VAGRANT: 254ecf5ed67f3f9bac659ec253835ee0 (default) / a0abbba7-eb55-4c6f-90f1-e3197ea18880
HSTS Preload List Submission
tomjn commented 5 years ago

Then why add vvv.dev to the /etc/hosts file when it's going to be ignored?

Because some people really like their .dev domains, others go straight to vvv.dev without thinking and would raise support tickets. In the future I'd like to auto-redirect visitors to .dev to .test for the dashboard. Additionally if you've added the root certificate then vvv.dev will work as expected

I just checked. And vvv.dev is indeed preloaded https://hstspreload.org/?domain=vvv.dev

All .dev domains are preloaded, it's a blanket rule added to the browsers by Google, and a pre-requirement of having a .dev TLD.

So it makes me wonder which webroot folder vvv.test is serving it's pages from.

A subfolder in www/default, the dashboard isn't a site template or a site, the same way PHPMyAdmin etc aren't site templates. But as I said, you control the repo the dashboard is cloned from via vvv-custom.yml

This is the default:

dashboard:
  repo: https://github.com/Varying-Vagrant-Vagrants/dashboard.git
  branch: master

Add the above and change it to another repo, then reprovision and that should change the dashboard. You might need to remove the existing checkout. I also can't confirm if the dashboard you've chosen to use instead will actually work as expected

HSTS Preload List Submission
BobbyBabes commented 5 years ago

I've not seen someone go to http://vvv before,

Then why is it in /etc/hosts?

Because some people really like their .dev domains,

Isn't the whole point of VVV to stay local? Let's not kid each other here. VirtualBox is desktop virtualisation. Type 2, running on top of a traditional OS. It is definitely not a Type 1 hypervisor (Bare metal). The first line of the README.md : Varying Vagrant Vagrants is an open source Vagrant configuration focused on WordPress development. development. Nobody, including aliens, in the whole universe and beyond, installs VirtualBox on a real server to develop remotely on their .dev domain. And then locks themselves out remotely, by adding an IP number from a private range to their real server's /etc/hosts file.

others go straight to vvv.dev without thinking and would raise support tickets.

vvv.dev That's just one domain. That would be owned by exactly one person, or one company. That's one ticket.

I'm having serious doubts about VVV and its goals (or implementation thereof). It seems that there hasn't been made a decision whether VVV is local, remote, or identical on local and remote. Thanks for your effort and time. But I'm skipping.

EDIT:

 bobbybabes  ladyluck  ~  dev  vagrant-local  master  $  vagrant halt
__ __ __ __
\ V\ V\ V / Varying Vagrant Vagrants
 \_/\_/\_/  v2.6.0-git::master

Platform:   platform-linux-gnu shell:/bin/bash systemd vagrant-hostsupdater CaseSensitiveFS 
Vagrant:    v2.2.4,     VirtualBox: v6.0.6r129722
VVV Path:   "/home/bobbybabes/dev/vagrant-local"

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

==> default: Running action triggers before halt ...
==> default: Running trigger: VVV Pre-Halt...
    default: Running: inline script
    default: /tmp/vagrant-shell: line 1: /vagrant/config/homebin/vagrant_halt: No such file or directory
==> default: Trigger run failed
==> default: The SSH command responded with a non-zero exit status. Vagrant
==> default: assumes that this means the command failed. The output for this command
==> default: should be in the log above. Please read the output to determine what
==> default: went wrong.
==> default: Attempting graceful shutdown of VM...
==> default: [vagrant-hostsupdater] Removing hosts
[sudo] password for bobbybabes:              
 bobbybabes  ladyluck  ~  dev  vagrant-local  master  $  vagrant destroy
==> default: Running action triggers before destroy ...
==> default: Running trigger: VVV Pre-Destroy...
==> default: Could not run remote script on default because its state is poweroff
==> default: Trigger configured to continue on error...
    default: Are you sure you want to destroy the 'default' VM? [y/N] Y
==> default: Destroying VM and associated drives...
==> default: [vagrant-hostsupdater] Removing hosts
 bobbybabes  ladyluck  ~  dev  vagrant-local  master  $  cd ..
 bobbybabes  ladyluck  ~  dev  $  rm -Rf vagrant-local
Mte90 commented 5 years ago

Sorry for the delay on reply. About the dev domain it is something that we cannot decide, all the .dev domains are redirect from the browser outside the intranet and is an exception as behavior compared to other domains (thanks google https://medium.engineering/use-a-dev-domain-not-anymore-95219778e6fd). We had to adapt to keep VVV working and move everything to .test like a year ago, and we wasn't the only one. We kept old urls for retro compatibility in the hosts with the plan to remove it.

So moving to the real question of the ticket seems something wrong with tideways that you can remove from the provision and VVV will works without any issue, if you are still interested on help us to identify the problem.

Medium Engineering
Use a .dev domain? Not anymore.
For years, programmers used .dev domains for testing their code. Those days are over.
tomjn commented 5 years ago

Oh it's definitely local, I don't know how you got the impression we supported remote.

Lots of people choose a .dev domain for their local sites because they're "dev"eloping their sites so yoursite.com in production, and in yoursite.dev locally. Then Google bought the right to sell that TLD and messed up everybody's plans. I switched is other to .test for everything as a result.

I actually tried and failed to buy vvv.dev during the sunrise period but somebody else spent several thousand $$$ and beat me to it with an earlier stage of the process

As for running VVV on a remote server, I strongly advise against that. To even do that you'd need to make vagrant file changes. This is a local project for local development.

As for existing sites that used .Dev already before Google started selling them, there's a problem that's harder to solve. Why not search replace them to .test domains? It sounds straight forward but it has issues. For example one plugin hashes URLs, and search replacing would destroy the data.

Additionally .test domains are protected by RFCs. Finally, all the splash screens, docs, and warnings point to vvv.test

So the TLDR: Use VVV.test for your dashboard

As an aside I think the plain vvv domain and vvv.local should be retired. A lot of people are in the habit of using vvv.dev though, I expect if we remove that host we'll get a lot of confused or frustrated people

On Wed, 24 Apr 2019 at 10:17, Daniele Scasciafratte < notifications@github.com> wrote:

Sorry for the delay on reply. About the dev domain it is something that we cannot decide, all the .dev domains are redirect from the browser outside the intranet and is an exception as behavior compared to other domains (thanks google https://medium.engineering/use-a-dev-domain-not-anymore-95219778e6fd). We had to adapt to keep VVV working and move everything to .test like a year ago, and we wasn't the only one. We kept old urls for retro compatibility in the hosts with the plan to remove it.

So moving to the real question of the ticket seems something wrong with tideways that you can remove from the provision and VVV will works without any issue, if you are still interested on help us to identify the problem.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/Varying-Vagrant-Vagrants/VVV/issues/1762#issuecomment-486139547, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAOLZ2WEFQQNKR3RUWTINTPSAQRZANCNFSM4HH5WR3Q .

tomjn commented 5 years ago

I'm reopening this so we can track the get_cwd issue. I've also started on a PR that removes all the dashboard domains except vvv.test. It appears that vvv is added by the hostsupdater plugin rather than explicitly added by the vagrantfile like the others

tomjn commented 5 years ago

So the getcwd issue appears to be isolated to the install_tideways_php bash function, specifically something in:

                cp -rf /var/local/tideways-php "/var/local/tideways-php$version"
                cd "/var/local/tideways-php${version}"
                update-alternatives --set php "/usr/bin/php$version" > /dev/null 2>&1
                update-alternatives --set php-config "/usr/bin/php-config$version" > /dev/null 2>&1
                update-alternatives --set phpize "/usr/bin/phpize$version" > /dev/null 2>&1
                phpize$version > /dev/null 2>&1
                ./configure --enable-tideways-xhprof --with-php-config=php-config$version > /dev/null 2>&1
                make > /dev/null 2>&1
                make install > /dev/null 2>&1
                rm -rf "/var/local/tideways-php$version"

My suspicion is that it's the configure or make scripts

BobbyBabes commented 5 years ago

I don't know how you got the impression we supported remote.

How about YOU:

Because some people really like their .dev domains, others go straight to vvv.dev without thinking and would raise support tickets.

All .dev domains are preloaded, it's a blanket rule added to the browsers by Google, and a pre-requirement of having a .dev TLD.

And the TLD .dev that your code adds to "/etc/hosts". And to make it even worse, with an IP number from a private IP address range allocated.

You should never need or want a .dev domain,

That is not for you to decide.

and all .dev sites VVV provided switched over to .test by default for this reason.

Such a lie. Because you wrote before :

In the future I'd like to auto-redirect visitors to .dev to .test for the dashboard.

AND this change you made after I reported that this was not the case :

removed 3 dashboard domains in favour of vvv.test #1763

Reread from the top. And comprehend this time.

So for the third time : If you knew that .dev TLDs are never going to work locally, because of preloading in browsers, why add one at all to /etc/hosts ? I asked this question twice before. And you just kept twisting and turning around, instead of giving a valid explanation. Simply because there isn't any reason to litter the /etc/hosts file with those entries.

And now you have the gonads to ask me how I got the impression that you supported remote. I didn't bring remote into the discussion. You did. And your code. I suggest that you stop twisting and turning, and start cleaning your own backyard. I'm done with you.

tomjn commented 5 years ago

And the TLD .dev that your code adds to "/etc/hosts".

It's not my code, we're a community open source project with many years of history and contributors

And to make it even worse, with an IP number from a private IP address range allocated.

That's how Vagrant and VirtualBox work, it's also how docker works. Each VM and container have their own private IP. Otherwise they'd need public IPs. If you're not keen on that, you'd have to take it up with those projects. If they all used 127.0.0.1 there'd be no way to route traffic to just one container without a complicated port forwarding setup

So for the third time : If you knew that .dev TLDs are never going to work locally, because of preloading in browsers, why add one at all to /etc/hosts ?

Lets summarize:

  1. When VVV was first created Google didn't own that TLD, there was no issue using it so it was used
  2. When Google did buy it we had to change everything over, we deprecated .dev domains and put warnings in the dashboard on sites using .dev, wrote docs about it etc. Note that we deprecated vvv.dev but we didn't remove it at the time, and said it would be removed in the future
  3. If you have SSL setup with VVV, then .dev domains still work, but not everybody does, and SSL wasn't added to VVV when this happened, it's a more recent addition and requires additional steps from the user
  4. It wasn't removed outright because lots of people still used vvv.dev out of habit, and we wanted a deprecation period. For a small while, it also worked on Firefox and only had the SSL requirement in Google Chrome, so those users could still use .dev issue free for a time
  5. We have no control over what hosts a user might choose to add. If they want to add a new site and give it the example.dev host, that's up to them
  6. I removed additional dashboard domains based on feedback here. In the next version of VVV there will only be .test
  7. .test is protected by an RFC, it's supposed to be used for the kinds of things we're doing, so all the default sites got switched to .test domains for new users. I personally went on a commenting and poking spree trying to get VVV tutorials to switch, and people to update gists to switch away from .dev, with some success

I'd like to note that this is an open source, volunteer community driven project. It isn't a commercial product, and you haven't paid for it, nobody here is paid either. We all have day jobs and do this in our own time. I don't appreciate your approach when several people have tried to help you and be nice