I upgraded to the new VM, and now I have problems accessing the service over the local network. It appears that half the links in the host page resolve to the correct IP address that I provide. For example:
Yes. A lot of the “static” resources on https://musicbrainz.org and other *brainz.org sites are now being served from https://staticbrainz.org (for several reasons). This means that the references to the resources can’t be served with relative links, as a relative link would not result in the browser looking at an external link.
http://192.168.1.12:5000 and http://localhost:5000 is the same port on the same web server It’s the difference between accessing it from the same machine or over the local network. When I type “http://192.168.1.12:5000” over the network, half of the home page loads (because they correctly resolve to 192.168.1.12), while 8 resources fail (because they resolve to localhost:5000). When I type “http://localhost:5000” on the same machine where VM is running, the page loads fine.
Again, if static resources resolve to an external URL (e.g. staticbrainz.org), there would be no problems to access the VM either from the same machine or over the network - and no change in settings would be required.
Some of the static resources (CSS, JS) get compiled per use. There’s no guarantee that the version of CSS and JS you (should) have locally are the same that are on StaticBrainz. (See the c9f2ad5685 and ee7ee655ac parts of the filenames in your original post.) Also, the StaticBrainz was made to lessen the load, if only slightly, especially for MusicBrainz. Even if it could work, I’m not sure it would have the desired effect on load/bandwidth if suddenly everyone using the VM or otherwise setting up their own instances would load all those resources from our servers. One of the reasons for the VM is exactly so people can play around with using and working on the website, without putting load on the server. (Not to mention that you would want to load local files if you’re using it on a machine shielded from outside networking or if you’re developing and need to see only local changes reflected.)
However, it is an issue that pops up now and then, so we will be looking into a way to resolve it. Either by changing the default way of looking up resources (e.g., like @yvanz’ patch (which I’m not sure he made a PR for)), or by changing the default setting specifically for/of the VM (as per @chirlu’s comment). The first step to this getting resolved is filing a ticket for it. I looked at the ticket tracker, and it doesn’t seem like this has been enough of a bother for anyone so far so that they actually reported it. But I went ahead and did so, feel free to watch the ticket to follow its progress and vote on it if you’d like to see it resolved sooner: https://tickets.metabrainz.org/browse/MBVM-30
The patch I linked to is made specifically for @andreivolgin. It was not intended to be merged as is.
Edit: Actually, it might be investigated for a pull request, depending on musicbrainz.org settings.
@chirlu: Relative URL/absolute path should probably be the default for MBS, not only for VMs, except when using a separate web server for static resources. This latter case (e.g. musicbrainz.org using staticbrainz.org) should be handled as well.