I have been scouring the internet to no avail for hooking up my iphone with my local development environment. My host computer is a mac running mavericks. The guest(vm) on vagrant is running ubuntu-precise12042-x64-vbox43. Anyone know how I can setup a testing environment where I can access all my vhosts on my iphone using this setup?
1 Like
Really more of a networking trick than a vagrant trick. I would advise skipping vhosts and just mapping to straight IP or port combinations as that takes out the whole “I need functioning DNS” thing off the table.
Presuming you can do that what you need to do is:
a) forward an appropriate port on your vagrant box to the host
b) punch appropriate firewall hole to this port
c) get the iphone on wifi on the same network as the computer so it can access it directly
d) browse to pc address / port combo (ie if your computer’s IP address is 192.168.10.1 and your sites are on port 10000 you would go to http://192.168.10.1:10000.
If you really need vhosts you’ll have to configure the wifi network with some custom DNS. Exactly how to do this (or if it is even possible) depends on the wifi networking setup. In a horrible pinch you could probably setup real domains with public dns. Vhosts suck for dev work once you get past a single computer / hosts file scenario.
Also note you can do lots of testing through the iOS emulator that gets installed with xcode. To get at it just make a new iOS project, run it on the emulator and then hit the home button and fire up Safari. This is running on your PC so it has access to any network resource your PC has.
In the next couple of days I will probably end up asking some people more familiar with networking than myself as this would really improve development/testing efficiency on remote devices.
Not sure I understand if that means I need to setup my guest (vhosts) and host (hosts file) machines differently of something else entirely. I’m currently using vhosts on my guest machine using apache. Than in the host machine hosts file mapping the guests ip to a server alias within the guest apache vhosts file.
I believe the puphpet and vagrant combo sets that up by default though it might actually be the other way around.
Not sure on that one. The remote device will be on the some network though. I don’t think there are any restrictions there.
Like I said above no issue there I believe.
This is the part that tripping me up. I see a lot online about doing this with ips but very few things about setting it up with vhosts and just about nothing with a vagrant/vm setup that has vhosts specified on the guest machine and forwarding on the host.
It would be ideal to use the vhosts as I have multiple sites attached to a single box. So will probably need to look into this some form or another.
I use the emulators and there are always those edge cases that the emulator doesn’t catch. I would prefer to be on a real device since I do have them available. I can easily test from our dev server but that is a little bit of a pain considering it involves a git workflow thus comiting “unstable” work to test on dev when really that should all be done on my local box. Though push comes to shove testing on our dev box does work it just is a pain and not nearly as efficient. Not to mention xdebug isn’t installed on any of our servers yet so I can’t really easily debug via remote, mobile devices if I really needed to. So if I could get the devices to access my local setup it would be a huge win for me.
For vagrant – you can not worry about that. Presuming you can get the wifi going and the port isn’t blocked for another reason (eg your firewall) the network continuity angle seems to be there.
All vagrant is doing is acting like a web server on your local machine at the prescribed port, the real problem is how to deal with vhosts. What I was hitting at is that the best answer is to avoid the question of using name based vhosts altogether and partition your web server by port – so app one is at http://localhost:10000 and app two is at http://localhost:10001, etc. Without the name-based vhost you don’t need to manage DNS infrastructure – or have to debug DNS related issues ever.
Does that make a bit more sense?
I have finally discovered a good solution to this problem using vagrant.
Essentially, all you need is to be be running vagrant 1.5+ and create an account on the vagrant cloud. Once that is done the command vagrant share can be used and will create a temporary public URL to your local box. The only catch is that a server alias then needs to be added to the vhost file to map the given host to the proper site directory.
Pretty awesome – yet another reason to use vagrant.
Perhaps. I don’t trust other folks with networking voodoo then again I do networking voodoo . . .