Anyone know of a pre-built PHP7 vagrant box?

Horses for courses, I think.

Running one standard server from a single vagrant config file location puts you back to the one host for multiple projects scenario, albeit moved from your host machine and into the guest.

The environment setup for one project could pollute the environment setup for another.

Sure, you can commit an ansible playbook or a chef cookbook or whatever to each project, but then you’re parallelising the need to specify a certain something across each project.

That’s not very clear. Hang on.

Suppose you have six projects and only one needs to be on PHP5.5 due to the live server environment, whereas all of the rest can be running 5.6+. With a single, standardised server, you have to edit the playbook for all six, not just the one.

(I know the PHP version isn’t the best example since it should be uniformly set to the latest and greatest in all but it’s the idea I’m referring to)

In a team environment, the chances are not insignificant that a dev would a) modify the playbook for the project that he’s on but b) not uniformly make the changes across all projects. If another dev git pulls and vagrant ups his project, he’ll change the configuration of his one standardised server and not necessarily notice.

(the provisioning step is generally a good time to go make a cup of tea :wink: )

The one virtual server per project eliminates this problem, but also puts one virtual machine into virtualbox per project. (one vagrantfile = one virtualbox machine effectively)

So like I said, horses for courses. If a standardised server to run all of your projects under suits your needs, then @swader 's approach is certainly the much better one.

Once you have a need to customise the server environment for a particular project, I’d consider switching to providing a vagrant setup (and consequently, a dedicated virtual machine) for that project to avoid polluting the standard server for the other projects and/or other devs. From my perspective, maintaining the vagrant environment inside the project repo is less troublesome than maintaining a separate repo for that environment (and if the vagrant clutter in the project root is troubling, it can always be moved to its own folder).

For what I plan to use it for, his approach would be fine. But that definitely did answer my question on whether the complexity of a project (or the team environment) may establish a need to have the Vagrant file tightly coupled with their project.

Oh and it seems homestead isn’t happy on my work machine. I can’t get the SSL cert to be accepted, so I’ll have to play around with this some more when I get a chance later.

I haven’t tried setting up SSL on Homestead yet, thanks for reminding me, need to look into that. That’ll be a separate post.

Sorry, I’m not even that far yet. I can’t get it to download the VM here at work because the SSL cert for downloading the box was rejected… I still haven’t had a chance to investigate it, but maybe tomorrow I’ll get to it.

What do you mean by SSL cert for downloading?

Here is the output (I just haven’t had time to dig into it yet)

C:\HashiCorp\Vagrant\bin\vagrant.exe up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'laravel/homestead' could not be found. Attempting to find and
install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
The box 'laravel/homestead' could not be found or
could not be accessed in the remote catalog. If this is a private
box on HashiCorp's Atlas, please verify you're logged in via
`vagrant login`. Also, please double-check the name. The expanded
URL and error message are shown below:

URL: ["https://atlas.hashicorp.com/laravel/homestead"]
Error: SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Process finished with exit code 1

I’ve never seen this. You generally don’t need any SSL shenanigans in just grabbing a box. Do you have the latest version of Vagrant installed? Sometimes older versions will have outdated SSL certs due to Vagrant bundling its own curl.

Yes, I literally installed it today as I didn’t have it initially on my work box.

Strange. Let me know what you find out the trouble is if you look into it. Btw, you don’t need the full path to the Vagrant exe if it was added to your path. vagrant up is enough.

I actually didn’t run it manually, I let Intellij handle it. So it knows the path and just kicks it off. I do plan to get back to trying to figure out the SSL issue, I just haven’t had the opportunity to do so yet. I imagine the corporate firewall is playing a part in it.

Edit: It seems to function just fine on my home machine (which is Linux)

That’ll probably be it

Cool, I got homestead running at home. This should make things a bit nicer for me to play around! :smile:

Thanks for the article link and the better explanation of ways to use Vagrant that make it feel a bit “less complicated” to me.

Eventually, I’ll have to work on getting xDebug to work and things along that nature (when the need arises), but right now, this is enough for me to start playing.

So a temporary solution to my SSL problem at work was adding
config.vm.box_download_insecure = true to homestead.rb

For whatever reason, the SSL cert that I have either is invalid, or the company firewall is blocking it.

Well, now I’ve got another issue, VirtualBox seems to be ignoring my default setting for where to store VMs

C:\HashiCorp\Vagrant\bin\vagrant.exe up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'laravel/homestead'...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["import", "C:/Users/myuser/.vagrant.d/boxes/laravel-VAGRANTSLASH-home
stead/0.2.5/virtualbox/box.ovf", "--vsys", "0", "--vmname", "settler_default_142
5911633129_99583_1428063858658_56433", "--vsys", "0", "--unit", "7", "--disk", "
G:\\VirtualBox VMs\\settler_default_1425911633129_99583_1428063858658_56433\\box
-disk1.vmdk"]

Stderr: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Interpreting C:\Users\myuser\.vagrant.d\boxes\laravel-VAGRANTSLASH-homestead\0.
2.5\virtualbox\box.ovf...
OK.
0%...
Progress state: VBOX_E_FILE_ERROR
VBoxManage.exe: error: Appliance import failed
VBoxManage.exe: error: Could not create the clone medium 'G:\VirtualBox VMs\sett
ler_default_1425911633129_99583_1428063858658_56433\box-disk1.vmdk'.
VBoxManage.exe: error: VMDK: could not create new grain directory in 'G:\Virtual
Box VMs\settler_default_1425911633129_99583_1428063858658_56433/box-disk1.vmdk'
(VERR_DISK_FULL)
VBoxManage.exe: error: Details: code VBOX_E_FILE_ERROR (0x80bb0004), component A
ppliance, interface IAppliance
VBoxManage.exe: error: Context: "int __cdecl handleImportAppliance(struct Handle
rArg *)" at line 779 of file VBoxManageAppliance.cpp

I have the Default Machine Folder set to my C:\ but for whatever reason, it is attempting to clone the box to the G:\ drive :frowning:

More digging to do.

Okay, I solved it. I had to run the following (not sure why it doesn’t honor the preference set in the GUI for VirtualBox)

vboxmanage setproperty machinefolder /path/to/virtualbox

That’s some crazy problems you have there - thanks for posting the solutions to them, I’m sure they’ll be useful for other too!

1 Like

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.