fostermadeco / development-standard Goto Github PK

I spoke with @adam-winfree and he gave me a fix for this. This cropped up when I switched from trusty to 16.04. That being said, should we apply the fix to the default Vagrantfile, or just add info to the readme in case someone encounters the issue?

This was the fix:

config.vm.provider "virtualbox" do |vb| vb.customize ["modifyvm", :id, "--cableconnected1", "on"] end

Here is the issue thread regarding the fix: hashicorp/vagrant#8056

This repo needs a new name.

Message: RuntimeError: can't modify frozen String

/usr/local/etc/ must exists before the provisioner runs; it should be checked and created if necessary in the Vagrantfile.

Automatically run composer install if composer.lock exists.
Automatically run npm install if package-lock.json exists.

[DEPRECATION WARNING]: The use of 'include' for tasks has been deprecated. Use
'import_tasks' for static inclusions or 'include_tasks' for dynamic inclusions.
This feature will be removed in a future release. Deprecation warnings can be
disabled by setting deprecation_warnings=False in ansible.cfg.
[DEPRECATION WARNING]: include is kept for backwards compatibility but usage is
discouraged. The module documentation details page may explain more about this
rationale.. This feature will be removed in a future release. Deprecation
warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

Every time we go to work on a project we have to do vagrant ssh then cd /var/www/project. Can we automatically navigate to the project folder after sshing in? This would save an extra step every time. Also I get some questions of people forgetting to navigate to the folder and trying to run composer or npm commands.

Would it be appropriate for all projects? I can't think of one that I've worked on that it wouldn't be, but I'm assuming it would be easy to remove from the default setup for those projects it wouldn't make sense for.

Cisco AnyConnect presumably makes networking changes that cause all kinds of problems. Is it possible for them to work simultaneously?

I've noticed this file in a number of project repos lately. Should we recommend excluding this with gitignore?

Use security verify-cert -c /usr/local/etc/ssl/certs/{{ hostname }}.crt to determine if a certificate is already trusted. If it is, do not add it again.

Do we relent in the face of Google and change .dev to something else? We already have to change it for Mailhog to be accessible.

Add task to give "others" the permission to traverse /etc/ssl/private the directory and see the files inside it (sudo chmod o+x). This will allow browsersync to use /etc/ssl/private/{{ hostname }}.key so it will run with a valid ssl certificate.

This can be recreated by spinning up a box, then trying to re-provision.

This is the full error:

fatal: [default -> localhost]: FAILED! => {"changed": false, "failed": true, "module_stderr": "sudo: a password is required\n", "module_stdout": "", "msg": "MODULE FAILURE", "rc": 1}