Vvv: SSL certificates not correctly added to Nginx site configs due to if [[ $(/srv/config/homebin/is_utility_installed core tls-ca) ]] always evaluating to false

Created on 13 Feb 2020  Â·  7Comments  Â·  Source: Varying-Vagrant-Vagrants/VVV



What was The Command Used To Provision

vagrant reload --provision

What Kind of VVV Provision Was This


This was an attempt to upgrade to a new version of VVV

Logs/What Broke

I've updated to VVV 3.3.0 and have been having issues with the provisioned SSLs on my sites. I'm getting the NET::ERR_CERT_COMMON_NAME_INVALID warning and when I examine the certificates in the browser, they're all issued to vvv.test instead of mysite.test. In other words, my sites are basically using the default SSL and the browser doesn't like the domain mismatch.

After digging into it a bit, I found out that the cert information is not correctly inserted into the Nginx site configs in /etc/nginx/custom-sites/. After some more digging, I found the block responsible for setting up the certs in provision/provision-site.sh:

  if [[ $(/srv/config/homebin/is_utility_installed core tls-ca) ]]; then
    sed -i "s#{vvv_tls_cert}#ssl_certificate /srv/certificates/${VVV_SITE_NAME}/dev.crt;#" "/etc/nginx/custom-sites/${DEST_NGINX_FILE}"
    sed -i "s#{vvv_tls_key}#ssl_certificate_key /srv/certificates/${VVV_SITE_NAME}/dev.key;#" "/etc/nginx/custom-sites/${DEST_NGINX_FILE}"
  else
    sed -i "s#{vvv_tls_cert}##" "/etc/nginx/custom-sites/${DEST_NGINX_FILE}"
    sed -i "s#{vvv_tls_key}##" "/etc/nginx/custom-sites/${DEST_NGINX_FILE}"
  fi

My bash knowledge is very limited, so I'm not sure if this is a bug, but it seems that the if [[ $(/srv/config/homebin/is_utility_installed core tls-ca) ]] statement always evaluates to false.

I have tls-ca added in the core utilities in my config.yml and if I run is_utility_installed core tls-ca from command line in vagrant directly, it correctly exits with 0 status. Likewise, if I run it with some non-existing utility, it exits with 1 status. So the is_utility_installed script itself is working correctly. It's only in the if statement in the provision-site.sh script where the output always evaluates to false, regardless of whether the utility is actually installed or not.

My config/config.yml:

...

utilities:
  core: # The core VVV utility
    - tls-ca # HTTPS SSL/TLS certificates
    - phpmyadmin # Web based database client 

...

Possible Solution

Is the syntax of the if statement in provision-site.sh correct? Does it need to be tweaked so that it correctly evaluates the result of the $(/srv/config/homebin/is_utility_installed core tls-ca) command?

The same syntax is also used in /config/homebin/tideways_on:

if [[ ! $(is_utility_installed core tideways) ]]; then
  echo "Tideways is not installed"
  exit 0
fi

and provision/provision.sh:

  if [[ $(is_utility_installed core tideways) ]]; then
    echo "127.0.0.1 tideways.vvv.test # vvv-auto" >> "/etc/hosts"
    echo "127.0.0.1 xhgui.vvv.test # vvv-auto" >> "/etc/hosts"
  fi

so if it indeed turns out to be a bug, these blocks would also need adjusting.

Steps to Reproduce (for bugs)


  1. Run vagrant reload --provision with VVV master 3.3.0.

Your Environment

Operating System: Windows 8.1

__ __ __ __
\ V\ V\ V / Varying Vagrant Vagrants
 \_/\_/\_/  v3.3.0-git::master

Platform: platform-mingw32 windows vagrant-hostsupdater vagrant-vbguest shared_db_folder_disabled , VVV Path: "D:/Web_Development/VMs/vvv3"
Vagrant: v2.2.7, VirtualBox: v6.0.16r135674

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

Thank you very much in advance.

bug

Most helpful comment

Thank you @h4r1m4u! I was just finishing up my own bug report about this, but the fix you provided worked.

For those following along at home, here are the exact steps I needed to take to get it working again:

  1. Made the edit to provision/provision-site.sh suggested by @h4r1m4u
  2. Deleted the VVV INTERNAL CA from Keychain Access
  3. Deleted the certificates folder from my local VVV directory
  4. Ran vagrant reload --provision from my local VVV directory
  5. Ran the MacOS steps from Trusting the Certificate Authority

All 7 comments

A quick follow up:

I tried changing the if statement in provision/provision-site.sh from

 if [[ $(/srv/config/homebin/is_utility_installed core tls-ca) ]]; then
   ...

to

 if /srv/config/homebin/is_utility_installed core tls-ca; then
   ...

based on this StackOverflow answer and it resolves the issue. So it indeed does seem like a problem with the currently used syntax.

I tried now with https://www.shellcheck.net/ and seems that both the code is right.
https://github.com/Varying-Vagrant-Vagrants/VVV/search?q=is_utility_installed&unscoped_q=is_utility_installed

Maybe we need more testing about it but is a change that we can do, can you do a pull requests?

ShellCheck finds bugs in your shell scripts

Thank you for the prompt response, @Mte90.

I think the syntax as such is fine in both cases, so it'll pass ShellCheck, but there's a difference in how the output of the is_utility_installed script is evaluated depending on the syntax used.

The pull request it ready.

Thank you @h4r1m4u! I was just finishing up my own bug report about this, but the fix you provided worked.

For those following along at home, here are the exact steps I needed to take to get it working again:

  1. Made the edit to provision/provision-site.sh suggested by @h4r1m4u
  2. Deleted the VVV INTERNAL CA from Keychain Access
  3. Deleted the certificates folder from my local VVV directory
  4. Ran vagrant reload --provision from my local VVV directory
  5. Ran the MacOS steps from Trusting the Certificate Authority

@kwaves Awesome, glad it helped.

Patch tested and merged

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rwrobe picture rwrobe  Â·  4Comments

pvanbavel picture pvanbavel  Â·  4Comments

tomjn picture tomjn  Â·  3Comments

joelworsham picture joelworsham  Â·  5Comments

robneu picture robneu  Â·  4Comments