Before posting this, I've done some research and tried different solutions. The question is how to configure a system so that it would be possible to SSH into it's vagrant box from external/different network?
I have a Windows machine at home. I have installed Vagrant and now able to access the contents both via HTTP and SSH from any device connected to very same network.
What I want to do is to be able to get a laptop, go to a nice little café just across the river, sit down and work on my project which sits in that Vagrant box on my home desktop PC.
I am quite terrible in networking and not sure what is the solution. Do I need to make my home desktop a server? If so, which steps should I take? Do I need to do configure something in my router software? Or do I need to create some kind of VPN stuff where Vagrant thinks I am actually requesting it's contents from the same home network or perhaps I just better give up and setup a droplet in the DigitalOcean instead?
To moderators: please don't shut this question because the answer is an opinion based. I am happy to listen to these opinions and I want to know which steps to follow to achieve what I want.
Thanks
Why not just copy your Vagrantfile to the laptop and spin up an instance there? It would be much less work, faster, and importantly much safer than opening up your desktop computer to the world.
I think your own suggestion of a remote server is also a valid option, although not quite as simple as just using the laptop.
I cant seem to access flutter.dev site, I tried from different browsers, devicesand networks but always get
This site can’t be reached
flutter.dev took too long to respond.
Tried tracert flutter.dev and only got to homerouter and started to timeout
I have am currently on a fresh install of windows 10.
any help please?
First of all, check if flutter.dev is reachable from other devices as smartphone, pc, etc. If other devices could reach flutter.dev from the same network, check DNS settings, look at "C:\Windows\System32\Drivers\etc\hosts". Perhaps you are using something for local development e.g dnsmasq, in this case, all .dev domains could be pointed to your local machine.
I hope, that my answer will be useful.
So i setup a virtual machine with vagrant using the virtual box container provided by laravel's homestead. (on my osx env)
I used the nfs option method of sharing my directories to my local environment and this speed up response times drastically. On a typical app, i'm getting like 20-40ms load per page. However, I noticed that file uploads are terribly slow. I can upload a 1MB file on a simple form that does nothing to the file and it will take about a 30seconds to a minute. Is this normal, or is there a way to speed things up even further besides using nfs shares.
This has been driving me crazy for some time, and no amount of toying with Vagrant's or VirtualBox's settings (sendfile, NFS, adjusting packet sizes, etc.) helped. But with the help of this answer on a similar problem relating to failed image uploads, I've finally cracked it:
The key, for me, was changing my hosts file to resolve my Homestead domains to the homestead VM's IP of 192.168.10.10, rather than to 127.0.0.1. (When doing this, you also drop the port :8000 from the URL, so you just navigate to homestead.app).
This changed my file upload speed from around 25 KB/sec to 5980 KB/sec!
It appears that the Laravel docs were updated a week ago to reflect this change. I wonder if your Yosemite install coincided with the docs change, and you set up your new box with 192.168.10.10 while your old hosts setup pointed to 127.0.0.1.
Even though the Laravel docs have been corrected—so this issue shouldn't present itself for new Homestead installs—there are still a lot of tutorials floating around in the wild that suggest resolving Homestead domains to 127.0.0.1. Hopefully this answer will help head off some aggravation!
Things that come to my mind:
Edit /etc/nginx/nginx.conf, find the "sendfile" setting and change it to "off" (I've seen some reports of people having some issues with it turned on when using NFS);
Having xdebug enabled slows things down, and although I wouldn't expect it to make such a huge difference as the one you're noticing, if nothing else works it might be worth disabling it and see if helps;
If none of these help, create a repo on github to recreate the issue and I'll have a look, see if I find anything.
I'm using SlikSVN's 64-bit subversion server for source control. I noticed that a few applications were taking a really long time to perform simple actions with repositories the other day, such as browsing the repository, committing etc, and I thought it was a fault within the applications themselves.
I tried the same actions logged into my network via VPN however, and they were all super-speedy. The only difference was that I was connecting to the subversion server via the IP address (v4) rather than hostname. After a few tests, I found that the problem seemed to have something to do with IPV6.
Disabling IPV6 made most of the performance issues disappear, but I'm not sure I want this to be the solution...
IPV6 seems to be supported by SlikSVN - it even has a -6 parameter (which I have tried) to make svnserve prefer ipv6 connections, but it doesn't seem to help the issue all that much. I'm also using the latest versions of the applications which are having issues (AnkhSVN is one of them), and believe them to also support IPv6.
I'd be tempted to add an entry to the hosts file so that name resolution for the SVN host always resolves to an IPv4 address, but this still feels a bit hacky to me.
Does anyone have any experience with this sort of issue?
Many thanks,
Nick
Firefox and Chrome are known to be slow on localhost when IP6 is enabled. In previous versions of Windows, the simplest fix is to comment out this line from the hosts file, as explained in the answer to this question.
::1 localhost
However, as noted in this question, in Windows 7 this line is already commented out:
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
Is there an alternative way to disable the ::1 localhost reference in Windows 7?
Turns out if you uncomment the 127.0.0.1 line in the hosts file, Chrome goes back to its snappy self on localhost URLs.
# localhost name resolution is handled within DNS itself.
127.0.0.1 localhost
The hosts file is typically at C:\WINDOWS\system32\drivers\etc\hosts. To edit it in Win7, you'll need to run Notepad as administrator.
It turns out that the slowness is caused by an IPv6 issue with DNS and can easily be resolved by turning IPv6 support off in Firefox while doing localhost testing. To make the change, type
about:config
in the address bar, locate the
network.dns.disableIPv6
setting and double-click on it to set it to true. This does the trick for the Firefox localhost issue on Vista and everything is running fast again.
http://kb.mozillazine.org/Network.dns.disableIPv6 has all the info you probably need - good luck!
I ran into a strange issue with only one of my local domains being slow while all the others responded just fine. Couldn't figure out why and finally put ::1 localhost at the bottom underneath my other ::1 something.local and it instantly cleared up, where previously I had it above the other entries. (I'm running OS X 10.8.3)
My final hosts file wound up looking something like this:
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 something.local
::1 something2.local
::1 something3.local
::1 localhost
fe80::1%lo0 localhost
I'd do what Tim Schneider mentioned. Also mentioned by this James here:
http://theycallmemrjames.blogspot.com/2010/09/firefox-is-really-slow-testing-sites-on.html
"Double-click on ipv4OnlyDomains, and type localhost "
Jay
I had several entries in hosts (because I'm running virtual servers). Previously I had
127.0.0.1 localhost
127.0.0.2 i.localhost
127.0.0.3 secure.localhost
What seems to work better but not perfect is this:
127.0.0.1 localhost secure.localhost i.localhost
I suggest closing browsers, shutting down Apache, the restarting in reverse order when testing.
So far none of the fixes have worked very well for me. The problem remains intermittent. ..
However I noticed something interesting and figured I'd share in hopes that someone else can add to this.
If you shut off WiFi (i.e. turn the external internet feed off), and if you have for example, Chrome, FireFox and possibly other browsers open at the same time, and if Chrome chokes on a page, and you get the spinning pin wheel, and you try at that moment to also load a file from another browser, (from localhost) it will also hang until chrome finally times out (or whatever) and finally finishes many seconds later, even for simple pages.
This also happens with IE choking and blocking accesses from other browsers. I've tried this many times and I'm convinced there is something very funny going on.
There seems to be a link between the different browser processes. I hate to say this but I suspect there is a bug in the windows IP stack, as impossible as that sounds. The other possibility is that chrome is just bogging down or hogging the ip stack, or locking some file, so that others can't use it.
Also very interesting to note, is that if while chrome is frozen up, you re-enable WiFi, just as soon as the internet connects then chrome or IE finishes, along with whatever other browsers are also blocked.
That's sort of strange if you ask me. If you are working off of localhost there should be NO interaction with the internet.
I've tried to use WireShark to see what's going on, but it's confusing and so far I have not been able to nail down any packets involved.
There is something very funny going on.
I've deleted my .htaccess, and put an httpd.conf in which has the very minimum changes from the defaults.
I'm running Win7x64Pro, Apache 2.4.7.
BTW, it's not a php thing. Am sure about that at this point.
Also the lock ups seem to happen on ^R (page reload), not on browse to page, and where other page components need to be checked for current, like menu sprites (images). This would be where there is a 304 status (use HttpFox to see these).
Also, if you quickly reload the same page the chance that it will work is much higher. If you wait for a minute then it often gags again. I suspect chrome is getting results out of a short term cashe which is partly masking a deeper issue.
A bit late for an answer but i tried all of the above and still it was slow for me on Windows 7. When I use localhost it took about 20+ secs for page load.
Firefox improved with #Mark Mayo's answer but not all the time and Chrome was still very slow.
I found a solution here
Basically, i added the following lines to Apache httpd.conf file (as they weren't there already)
AcceptFilter http none
AcceptFilter https none
EnableSendfile off
EnableMMAP off
Tested both Chrome and Firefox and the page loads instantly
As someone else noted in a different answer - if you have bitdefender, then that will merrily ruin your development experience.
Best to open the bit defender console, enter alt-shift-control-g (which puts it in "game mode") and run from there.
in game mode, bitdefender won't bollocks up your localhost!
This isn't a direct answer but I had the same problem and none of the above IPv6 or hosts file changes worked for me. My asp.net MVC4 project was really slow after hitting F5 to refresh js changes on localhost. It was happening across all browsers - Chrome, FF, and IE. Eventually I found out that IIS Express 8.0 got installed without me realising, and it turns out 8.0 is extremely slow when serving up js files and seems to be a bug. If I ran iisexpress on the command line and hit F5 I could see each js file took 4 or 5 seconds to load.
I ended up uninstalling IIS 8.0 and installing IIS express 7.5 and straight away the problem was fixed. Here are the steps I followed:
Uninstall IIS express 8.0
Delete the IISExpress folder (on Win 7 it's in My Documents\IISExpress)
Install IIS express 7.5 (Link to IIS Express 7.5 download)
IIS Express 8.0 seems to be installed with VS 2012 so if you had a new install or possibly a service pack update this might have upgraded your previous IIS express version.
Just Try "Incognito" mode on Chrome and "Private Mode" on Firefox.
I know this not should be a correct answer. But you can use this as a temporary solution.