I've integrated VVV with the provider vagrant-aws but I had to override the SSH user from 'vagrant' to 'ubuntu' to be able to connect properly to the VM. This caused the 'ubuntu' user to be the active user running the provision scripts and led to several errors. I corrected these by forking VVV and modifying the username references. Is there a way correct this problem without forking VVV and changing the usernames from 'vagrant' to 'ubuntu'?
Not all boxes for all providers have an ubuntu user, so we switched to vagrant which fixed some issues specifically with hyperv. It also cropped up when we tried to build our own boxes.
The vagrant user should always be present, afterall mounted folders are owned by the vagrant user.
I've integrated VVV with the provider vagrant-aws
Some production sites run in VMs managed by Vagrant, and there are Vagrant boxes out there that excel at these things.
Keep in mind however that VVV is intended for local dev, which might sound obvious, but it hasn't been put through the full gamut of security hardening that would be needed to run on a server directly exposed to the internet. There are things you can do with VVV that are great for local development on a machine, but really awful for a server on the web. That's why we don't expose VVV on the local network by default in order to dissuade people from doing this, if not to stop them using it to setup their production websites (which does happen, and it's an awful idea).
E.g. memcached, mailhog, etc will all be directly accessible with default user/pass, and the default database credentials will be documented etc. Nor have any of the nginx of php configs gone through security hardening.
I know taking a local environment and exposing it to the web can make it easy to share mockups, but if you're following a modern version control based development flow, a staging or pre-production site setup on a proper host is always better.
As for solutions, perhaps add a vagrant provisioner that runs super early and adds the appropriate vagrant user?
@matthandus I would not recommend using VVV in production.
However this could be achieved by adding a cloud-config through user_data
Thank you @LoreleiAurora and @tomjn . We are launching on a private subnet in AWS only accessible by VPN. We are integrating with a lot of server applications... RabbitMQ, Solr, Redis, etc. We are able to share and demo our prototype so easily this way! We are doing quality control in AWS, before final delivery of our application. Don't worry, it will be installed on a good webhost with security in mind when it goes public.
@tomjn
As for solutions, perhaps add a vagrant provisioner that runs super early and adds the appropriate
vagrantuser?
Yes, I was hoping to do this without having to fork VVV codebase. Can this be done with a Vagrant Customfile? It seems to invoke Customfile too late during provision though.
@LoreleiAurora
However this could be achieved by adding a cloud-config through user_data
Thank you for sharing this solution. I am going to experiment with this.
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.