Problems accessing MusicBrainz over local network

andreivolgin · February 5, 2017, 12:42am

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

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

chirlu · February 5, 2017, 3:13am

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

andreivolgin · February 5, 2017, 3:18am

Will do. Thanks!

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

Freso · February 5, 2017, 3:25pm

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”:

andreivolgin · February 5, 2017, 5:06pm

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

From: Freso

yvanzo · February 5, 2017, 5:48pm

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.

Freso · February 5, 2017, 5:53pm

«[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).

yvanzo · February 5, 2017, 6:38pm

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

andreivolgin · February 6, 2017, 4:53am

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.

chirlu · February 6, 2017, 6:30am

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.

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

Freso · February 6, 2017, 9:01am

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

andreivolgin · February 6, 2017, 2:43pm

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 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.

Freso · February 7, 2017, 7:35am

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:

yvanzo · February 7, 2017, 10:05am

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.

chirlu · February 7, 2017, 10:17am

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.

jesus2099 · December 5, 2020, 12:51pm

I need to change all //localhost:5000/ generated links to either //192.168.0.99:5000/:

Or, even better, to just /:

Even if I prefer the patch, to test it quicker first, I changed musicbrainz-server/lib/DBDefs/Default.pm:

github.com

metabrainz/musicbrainz-server/blob/d26817421ff6a632821a220c271221a43afc1793/lib/DBDefs/Default.pm#L102


      
          
          ################################################################################
          # HTTP Server Names
          ################################################################################
          
          # The host names used by the server.
          # To use a port number other than 80, add it like so: "myhost:8000"
          # Additionally you should set the environment variable
          # MUSICBRAINZ_USE_PROXY=1 when using a reverse proxy to make the server
          # aware of it when generating things like the canonical url in catalyst.
          sub WEB_SERVER                { "localhost:5000" }
          # Relevant only if SSL redirects are enabled
          sub WEB_SERVER_SSL            { "localhost" }
          sub SEARCH_SERVER             { "search.musicbrainz.org" }
          sub SEARCH_ENGINE             { "SOLR" }
          # Whether to use x-accel-redirect for webservice searches,
          # using /internal/search as the internal redirect
          sub SEARCH_X_ACCEL_REDIRECT   { 0 }
          # Used, for example, to have emails sent from the beta server list the
          # main server
          sub WEB_SERVER_USED_IN_EMAIL  { my $self = shift; $self->WEB_SERVER }

~~sub WEB_SERVER { "localhost:5000" }~~
sub WEB_SERVER { "192.168.0.99:5000" }

Then I restarted sudo docker-compose up but it was not enough.
What do I need to do first, so that my change to Default.pm is taken into account?

Would it be the same action for the @yvanzo patch to be taken into account, as well?

Sorry for newbie questions.

InvisibleMan78 · December 5, 2020, 1:21pm

I’m not sure if this is still true for the current musicbrainz docker environment.
(assuming from here, that you use the small server with sample data)

Maybe you can find the needed information in this section about Docker Compose overrides and this section about Docker environment variables including the docker-compose.yml file.

jesus2099 · December 5, 2020, 1:29pm

Wow!

Then I just did that Docker environment variables (.env) thing!

Test that I see localhost with sudo docker-compose config
Add MUSICBRAINZ_WEB_SERVER_HOST=192.168.0.99 to my musicbrainz-docker/.env file
Tests that I see 192.168.0.99 with sudo docker-compose config
Start the server with sudo docker-compose up (now I am starting to know this one

I can’t believe the knowledge all people have in #musicbrainz:devel!