Problems accessing MusicBrainz over local network


#1

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:

href=“http://192.168.1.12:5000/static/search_plugins/opensearch/musicbrainz_artist.xml

Unfortunately, the other half always resolve to http://localhost:5000, and, obviously, fail. For example:

href="//localhost:5000/static/build/styles/common-c9f2ad5685.css"
src="//localhost:5000/static/build/scripts/rev-manifest-ee7ee655ac.js"

I did not have the same problem with the latest VM, if I remember correctly :slight_smile:

Is there any reason why relative URLs are not used for all resources?


Anyone getting images in the web interface?
#2

You need to change WEB_SERVER in lib/DBDefs.pm.


#3

Will do. Thanks!

It might be helpful, though, to replace hardcoded URLs in the next release.


#4

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.

See the ticket for making “StaticBrainz”:
https://tickets.metabrainz.org/browse/MBH-413


#5

I refer to resources that resolve to http://localhost:5000. External resources such as staticbrainz.com are totally fine.


From: Freso

#6

The reason why relative URLs are not used for all resources is indeed the use of StaticBrainz.
That said, default settings can probably be improved to allow relative paths in development VM.


#7

«[R]esources that resolve to http://localhost:5000» are the resources that are hosted at staticbrainz.org for the *brainz.org sites. Hence why

if your server isn’t running on localhost:5000. For musicbrainz.org, WEB_SERVER is set to staticbrainz.org:443 (or whatever the format of WEB_SERVER is).


Anyone getting images in the web interface?
#8

@andreivolgin: You might want to test it: 8263bc2


#9

The “old” VM did not require any changes in settings, and my server is running on localhost:5000.

It appears, though, that this commit might fix the problem by removing hardcoded "localhost’.

Have you merged these changes into the main branch? Should I try this fork, or is the new version of the VM is coming soon? It was mentioned that the new versions would be released monthly.


#10

You are contradicting yourself; above, you said it is running on 192.168.1.12.

It is a configuration option. Configurable is the exact opposite of hardcoded.

Well, @rob may have been a bit optimistic there. :slight_smile:

@yvanz: I don’t think we should change MBS to accommodate some VM users. Instead, better change the default configuration in the VM.


#11

The old VM was from before staticbrainz.org was introduced into the mix.


#12

This is the line of code I refer to:

-exports.STATIC_RESOURCES_LOCATION = ‘{{key_or_default (print $DBDefs “STATIC_RESOURCES_LOCATION”) “//localhost:5000/static/build”}}’;

http://192.168.1.12:5000 and http://localhost:5000 is the same port on the same web server :slight_smile: 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.


#13

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


#14

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.


#15

Catalyst generates absolute URLs (though not based on the WEB_SERVER setting, but on the hostname reported by the web server). I don’t particularly like the idea of mixing absolute and relative URLs.