Just for the record:
This VM returns JSON-Results muuuuuch faster in my local environment then the previous VMs.
I use it to tag my files with my own tagger and the speed gain with this VM is highly appreciated.
As you can see, the part with the CSS GUI doesn’t work for me (tried with yarn install)
How and where exactly should I delete and refresh/rebuild what?
Can you please provide the necessary commands?
For those repeating the steps:
Don’t forget to reboot your VM after executing the above (1 line!) command and maybe you have to clear the cache in your browser if you use the same search-URL again.
** there is some kind of typo in the make changes to the data, please.... URL
I assume everyone is clicking it away, so I don’t know how much work you have to fix it.
I started the VM (without display) from VirtualBox (5.2.16/Linux), logged in the guest, changed directory to musicbrainz/musicbrainz-docker and launched docker-compose up -d musicbrainz. Then, I can reach the local server at http://localhost:5000 from the host, with correct CSS.
Are you using another platform, or a custom VirtualBox setup, or other commands, or another URL to reach the local server at?
I try to access the GUI with the IP of the bridged (not NATted) VM. I use Google Chrome on another machine (never on the same VM machine with localhost:5000)
How can I check if the following "Building indexes complete" are fake news?
@yvanzo Where can I check if the index data was deleted completely before the new reindex process start? And how much space is available at this place?
It requires to set the variable WEB_SERVER accordingly and to rebuild static resources (js/css).
This can now be done by running the script set-web-server-name as follows:
I made it by opening an SSH console with PuTTY to the IP of the MB virtual machine on Port 22 (in my bridged environment actually 192.168.1.33). Then I entered: bin/set-web-server-name 192.168.1.33
without :5000 as port (the attempt with 192.168.1.33:5000 didn’t work)
The GUI appears nice and colored.
.
Then I entered bin/set-token myOfficialMB40characterReplicationToken
and bin/replicate now
everything works fine
.
The last step is now running for several hours: bin/reindex
I will let you know if the second and the following replication attempts will work without a disk space problem in a few days.
Today I tried to start my second replication attempt.
Unfortunately this doesn’t work with the following error:
Thu Aug 2 08:04:07 UTC 2018 : LoadReplicationChanges failed (rc=25) - see /musicbrainz-server/slave.log
Thu Aug 2 08:04:07 UTC 2018: Replication has been run successfully
vagrant@musicbrainz:~$ bin/tail-replication-log
Invalid or missing REPLICATION_ACCESS_TOKEN in DBDefs.pm -- get one at https://metabrainz.org at ./admin/replication/LoadReplicationChanges line 116.
No big thing just re-run bin/set-tokenmyOfficialMB40characterReplicationToken
I don’t know which of my commands to start and stop the VM let my token get lost.
And just to be sure:
There is no other way to only reindex the new replicated data?
We have to reindex always the complete set of existing data (delete the index data completely and then rebuild it)?
I ask because this reindex-job takes at least 5 hours even with 8GB RAM, 8 Cores and running on a SSD.
Fixed potential access token loss due to helper scripts reindex and turn-port;
Added helper script update-indexes to be automatically called after hourly replication;
Improved documentation.
Your token get lost when musicbrainz container is recreated. It may incidentally happen with docker-compose up. This command was called in scripts reindex and turn-port. That is most probably the reason CSS was gone after your successful reindex run. These scripts have been fixed to use option --no-recreate which prevents this issue.
reindex is usually not required at all, but it is the same as initial build of index data which is required and takes a very long time. Further updates of search indexes will be made upon existing index data. Helper script update-indexes has been added for this purpose. By default, it is automatically called at the end of replication cronjob.
Docker containers were not started on VM boot, it required to enter any docker command, such as docker ps, to start docker daemon. It has been fixed so as to start docker daemon (and containers) on VM boot. Normal start/shutdown should do now.