An nginx config was not found at .vvv/vvv-nginx.conf provision/vvv-nginx.conf or vvv-nginx.conf

[derekmizak]

What was The Command Used To Provision

vagrant up --provision

What Kind of VVV Provision Was This

This was a fresh install

Logs/What Broke

Provisioning of either site one or two didnt work with the same result as below. vvv.test working OK.

[38;5;2m * Running provisioner for site wordpress-one[0m
 * Updating wordpress-one in /srv/www/wordpress-one...
 * Searching for a site template provisioner, vvv-init.sh
 * Found vvv-init.sh at /srv/www/wordpress-one/provision/vvv-init.sh
 * Script output will be logged to: log/provisioners/20200524-005849/provisioner-site-wordpress-one.log
 * Custom site template provisioner wordpress-one - downloads and installs a copy of WP stable for testing, building client sites, etc
 * Creating database 'wordpress-one' (if it's not already there)
 * Granting the wp user priviledges to the 'wordpress-one' database
 * DB operations done.
 * Setting up the log subfolder for Nginx logs
 * Creating public_html folder if it doesn't exist already
 * Install type is 'single'
 * Downloading WordPress version 'latest' locale: 'en_US'
PHP Fatal error:  Uncaught PharException: phar "/usr/local/bin/wp" SHA1 signature could not be verified: broken signature in /usr/local/bin/wp:3
Stack trace:
#0 /usr/local/bin/wp(3): Phar::mapPhar()
#1 {main}
  thrown in /usr/local/bin/wp on line 3
[38;5;9m---------------------------------------------[0m

[38;5;9m! Site provisioner failed! Check the full log for more details[0m

[38;5;9m---------------------------------------------[0m
 * Warning: An nginx config was not found at .vvv/vvv-nginx.conf provision/vvv-nginx.conf or vvv-nginx.conf, searching 3 folders down, please be patient...
[38;5;9m ! Warning: No nginx config was found, VVV will not know how to serve this site[0m
 * Adding domains to the virtual machine's /etc/hosts file...
 * Adding hosts from the VVV config entry
   - Added one.wordpress.test from /vagrant/config.yml
 * Reloading Nginx
[38;5;9m ! wordpress-one provisioning had some issues, check the log as the site may not function correctly, provisioning took 4 seconds[0m

---


sites:

  
  wordpress-one:
    skip_provisioning: false
    description: "A standard WP install, useful for building plugins, testing things, etc"
    repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git
    hosts:
      - one.wordpress.test
    custom:
      wpconfig_constants:
        WP_DEBUG: true
        WP_DEBUG_LOG: true
        WP_DISABLE_FATAL_ERROR_HANDLER: true # To disable in WP 5.2 the FER mode

  wordpress-two:
    skip_provisioning: false
    description: "A standard WP install, useful for building plugins, testing things, etc"
    repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git
    custom:
      # locale: it_IT
      delete_default_plugins: true
      install_plugins:
        - query-monitor
    hosts:
      - two.wordpress.test

  
  wordpress-trunk:
    skip_provisioning: true # provisioning this one takes longer, so it's disabled by default
    description: "An svn based WP Core trunk dev setup, useful for contributor days, Trac tickets, patches"
    repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template-develop.git
    hosts:
      - trunk.wordpress.test

  
  wordpress-meta-environment:
    skip_provisioning: true # disabled by default, this takes a long time to provision
    description: "An environment useful for contributions to the WordPress meta team."
    repo: https://github.com/WordPress/meta-environment.git
    hosts:
      - wp-meta.test
    custom:
      provision_site:
        "buddypressorg.test": true
        "jobs.wordpressnet.test": true
        "wordcamp.test": true
        "wordpressorg.test": true
        "wordpresstv.test": true

  
utilities:
  core: # The core VVV utility
    - tls-ca # HTTPS SSL/TLS certificates
    - phpmyadmin # Web based database client
    #- memcached-admin # Object cache management
    #- opcache-status # opcache management
    #- webgrind # PHP Debugging
    #- mongodb # needed for Tideways/XHGui
    #- tideways # PHP profiling tool, also installs xhgui check https://varyingvagrantvagrants.org/docs/en-US/references/tideways-xhgui/
    #- php56
    #- php70
    #- php71
    #- php72
    #- php73
    #- php74

# 

vm_config:
  
  memory: 2048
  cores: 2

  
general:
  # Backup the databases to the database/backups subfolder on halt/suspend/destroy, set to false to disable
  db_backup: true
  # Import the databases if they're missing from backups
  db_restore: true
  # set to true to use a synced shared folder for MariaDB database storage
  db_share_type: false
  # GitHub token to use from composer
  #github_token: xxxxxx

# Settings for the vagrant plugins supported by VVV
vagrant-plugins:
  disksize: 10GB # requires the disk size vagrant plugin

Possible Solution

Steps to Reproduce (for bugs)

Your Environment

Operating System: Windows 10, Vagrant: v2.2.9, VirtualBox: v6.1.8r137981, \ V\ V\ V / Varying Vagrant Vagrants _/_/_/ v3.3.0-git::master

[welcome[bot]]

Thanks for opening your first issue here! Be sure to follow the issue template and include your OS/Vagrant/VVV versions! Don't forget you can get support in the VVV slack at https://varyingvagrantvagrants.org/docs/en-US/slack/

[tomjn]

 * Downloading WordPress version 'latest' locale: 'en_US'
PHP Fatal error:  Uncaught PharException: phar "/usr/local/bin/wp" SHA1 signature could not be verified: broken signature in /usr/local/bin/wp:3
Stack trace:
#0 /usr/local/bin/wp(3): Phar::mapPhar()
#1 {main}
  thrown in /usr/local/bin/wp on line 3

There's the problem, it looks like WP CLI that was downloaded is broken. Either reprovision or destroy the VM and recreate it. If the problem persists then someone needs to have a word with the WP CLI people.

[derekmizak]

 * Downloading WordPress version 'latest' locale: 'en_US'
PHP Fatal error:  Uncaught PharException: phar "/usr/local/bin/wp" SHA1 signature could not be verified: broken signature in /usr/local/bin/wp:3
Stack trace:
#0 /usr/local/bin/wp(3): Phar::mapPhar()
#1 {main}
  thrown in /usr/local/bin/wp on line 3

There's the problem, it looks like WP CLI that was downloaded is broken. Either reprovision or destroy the VM and recreate it. If the problem persists then someone needs to have a word with the WP CLI people.

It looks like more than one provisioning is required at the moment. After two sets site one is operational

   default:  * Testing network connection
    default:  * Succesful Network connection to ppa.launchpad.net detected...
    default:
    default:  * Searching for SVN repositories that need upgrading
    default:
    default:  * Cleaning up Nginx configs
    default:  * Cleaning the virtual machine's /etc/hosts file...
    default:  -----------------------------
    default:  * Provisioning complete in 173 seconds
    default:  * For further setup instructions, visit http://vvv.test
==> default: Running provisioner: dashboard (shell)...
    default: Running: C:/Users/DEREKM~1/AppData/Local/Temp/vagrant-shell20200525-1544-r68nvf.sh
    default:  * Updating dashboard on the 'master' branch...
==> default: Running provisioner: utility-source-core (shell)...
    default: Running: C:/Users/DEREKM~1/AppData/Local/Temp/vagrant-shell20200525-1544-pl2kcl.sh
    default:  * Updating the "core" utility on the "master" branch...
==> default: Running provisioner: utility-core-tls-ca (shell)...
    default: Running: C:/Users/DEREKM~1/AppData/Local/Temp/vagrant-shell20200525-1544-1840heu.sh
    default:  * Running utility provisioner for 'core/tls-ca'
    default:  * The 'core/tls-ca' provisioner completed in 1 seconds
==> default: Running provisioner: utility-core-phpmyadmin (shell)...
    default: Running: C:/Users/DEREKM~1/AppData/Local/Temp/vagrant-shell20200525-1544-jqpnbr.sh
    default:  * Running utility provisioner for 'core/phpmyadmin'
    default:  * The 'core/phpmyadmin' provisioner completed in 0 seconds
==> default: Running provisioner: site-wordpress-one (shell)...
    default: Running: C:/Users/DEREKM~1/AppData/Local/Temp/vagrant-shell20200525-1544-11q4jlc.sh
    default:  * Running provisioner for site wordpress-one
    default:  * Updating wordpress-one in /srv/www/wordpress-one...
    default:  * Searching for a site template provisioner, vvv-init.sh
    default:  * Found vvv-init.sh at /srv/www/wordpress-one/provision/vvv-init.sh
    default:  * Script output will be logged to: log/provisioners/20200525-112049/provisioner-site-wordpress-one.log
    default:  * Site provisioner script finished successfully
    default:  * Adding domains to the virtual machine's /etc/hosts file...
    default:  * Adding hosts from the VVV config entry
    default:    - Added one.wordpress.test from /vagrant/config.yml
    default:  * Reloading Nginx
    default:  * wordpress-one provisioning finished in 69 seconds
==> default: Running provisioner: site-wordpress-two (shell)...
    default: Running: C:/Users/DEREKM~1/AppData/Local/Temp/vagrant-shell20200525-1544-12aied6.sh
    default:  * Running provisioner for site wordpress-two
    default:  * Updating wordpress-two in /srv/www/wordpress-two...
    default:  * Searching for a site template provisioner, vvv-init.sh
    default:  * Found vvv-init.sh at /srv/www/wordpress-two/provision/vvv-init.sh
    default:  * Script output will be logged to: log/provisioners/20200525-112049/provisioner-site-wordpress-two.log
    default: Error: The site you have requested is not installed.
    default: Run `wp core install` to create database tables.
    default: ---------------------------------------------
    default:
    default: ! Site provisioner failed! Check the full log for more details
    default:
    default: ---------------------------------------------
    default:  * Adding domains to the virtual machine's /etc/hosts file...
    default:  * Adding hosts from the VVV config entry
    default:    - Added two.wordpress.test from /vagrant/config.yml
    default:  * Reloading Nginx
    default:  ! wordpress-two provisioning had some issues, check the log as the site may not function correctly, provisioning took 39 seconds
==> default: Running action triggers after up ...
==> default: Running trigger: VVV Post-Up...
    default: Running: inline script
    default: Post Vagrant up script
    default: Restarting Nginx and MySQL
    default:
    default:          yay
    default:    ▄▀▀▀▄▄▄▄▄▄▄▀▀▀▄                __ __ __ __
    default:    █▒▒░░░░░░░░░▒▒█    Thanks for  \ V\ V\ V /
    default:     █░░█░░░░░█░░█     using        \_/\_/\_/
    default:  ▄▄  █░░░▀█▀░░░█  ▄▄
    default: █░░█ ▀▄░░░░░░░▄▀ █░░█ Vagrant Up has finished! Visit http://vvv.test
    default:

[tomjn]

At this point you can just delete the second site and reprovision, it thinks WP is installed because the files are present but that isn't the case

[tomjn]

@derekmizak quick follow up, can you get me a copy of log/provisioners/20200525-112049/provisioner-site-wordpress-two.log? Also, can you let me know what files are in www/wordpress-two/public_html?

[derekmizak]

@derekmizak quick follow up, can you get me a copy of log/provisioners/20200525-112049/provisioner-site-wordpress-two.log? Also, can you let me know what files are in www/wordpress-two/public_html?

@tomjn Please find the log/provisioners/20200525-112049/provisioner-site-wordpress-two.log below. I have already reprovisioned the site two so there are all of the default files in it.

[38;5;2m * Running provisioner for site wordpress-two[0m
 * Updating wordpress-two in /srv/www/wordpress-two...
 * Searching for a site template provisioner, vvv-init.sh
 * Found vvv-init.sh at /srv/www/wordpress-two/provision/vvv-init.sh
 * Script output will be logged to: log/provisioners/20200525-112049/provisioner-site-wordpress-two.log
 * Custom site template provisioner wordpress-two - downloads and installs a copy of WP stable for testing, building client sites, etc
 * Creating database 'wordpress-two' (if it's not already there)
 * Granting the wp user priviledges to the 'wordpress-two' database
 * DB operations done.
 * Setting up the log subfolder for Nginx logs
 * Creating public_html folder if it doesn't exist already
 * Install type is 'single'
 * Downloading WordPress version 'latest' locale: 'en_US'
Downloading WordPress 5.4.1 (en_US)...
Using cached file '/home/vagrant/.wp-cli/cache/core/wordpress-5.4.1-en_US.tar.gz'...
Success: WordPress downloaded.
 * Setting up wp-config.php
Success: Generated 'wp-config.php' file.
 * WordPress is present but isn't installed to the database, checking for SQL dumps in wp-content/database.sql or the main backup folder.
 * Found a database backup at /srv/database/backups/wordpress-two.sql. Restoring the site
Success: Updated the constant 'DB_USER' in the 'wp-config.php' file with the value 'wp'.
Success: Updated the constant 'DB_PASSWORD' in the 'wp-config.php' file with the value 'wp'.
Success: Updated the constant 'DB_HOST' in the 'wp-config.php' file with the value 'localhost'.
Success: Updated the constant 'DB_NAME' in the 'wp-config.php' file with the value 'wordpress-two'.
Success: Updated the variable 'table_prefix' in the 'wp-config.php' file with the value 'wp_'.
Success: Imported from '/srv/database/backups/wordpress-two.sql'.
 * Installed database backup
 * Copying the sites Nginx config template
 * Using the default vvv-nginx-default.conf, to customize, create a vvv-nginx-custom.conf
 * Installing/activating plugin: 'query-monitor'
Error: The site you have requested is not installed.
Run `wp core install` to create database tables.
[38;5;9m---------------------------------------------[0m

[38;5;9m! Site provisioner failed! Check the full log for more details[0m

[38;5;9m---------------------------------------------[0m
 * Adding domains to the virtual machine's /etc/hosts file...
 * Adding hosts from the VVV config entry
   - Added two.wordpress.test from /vagrant/config.yml
 * Reloading Nginx
[38;5;9m ! wordpress-two provisioning had some issues, check the log as the site may not function correctly, provisioning took 39 seconds[0m

[tomjn]

@msaggiorato looking at the above log, I suspect there's a database backup that's empty, what do you think we can do?

[msaggiorato]

This is interesting. It certainly seem that way. If the database backup is faulty for whatever reason, there's not much we can do without interaction form the user.

Ideally, we would be able to ask the user if they want to keep the "uninstalled" copy, and if so, avoid further CLI activity.

But without asking (we can't have interaction from the user while running provisioners), I wouldn't assume anything and just log a warning and avoid hard errors, as there could be cases where an uninstalled/partial backup is intentional.

[tomjn]

If the database was created but no tables were created due to WP CLI not being available, then that would explain the empty database. We need to check after a database restore if the site is installed or not, and do the classic install otherwise

[msaggiorato]

Hmm, i would not go as far as forcing install. We should just check if the database has some table, if not, then we can assume it's empty and therefore force install.

If we just install because WP CLI cannot detect an installed site, we may override some data that (for whatever reason) should not be overriden.

We can safely make that assumption for an empty database tho.

[tomjn]

Sounds fair, but lets still check WP CLI afterwards and report in the log if it says it isn't installed for debugging purposes

[derekmizak]

@tomjn @msaggiorato - it was during initial provisioning so there was no custom data yet. Another run of provisioning did fix it. Do you want me to do any testing?

[tomjn]

@derekmizak not just yet, current consensus of what happened there is:

• the first time it provisioned:
  • database was created
  • provisioner tries to run WP CLI to install the tables
  • WP CLI was broken, so provisioning ended, no tables
• the second time it provisioned:
  • ah the database already exists! we don't need to create the tables
  • provisioner tries to activate a plugin, but WP sees no tables, says you need to install

We know what to do to make sure that doesn't happen, just haven't had the time to get around to fixing it just yet. If you're okay for us to ping you to help test in the future though that'd be awesome :)

[derekmizak]

@tomjn I would be more than happy to do test

[tomjn]

@msaggiorato I'm assigning this to you as it's related to work you've done