We’ll be performing maintenance on our primary database starting at 15:00 UTC on February 2. It’ll take about 20 minutes to transfer services from our primary database server to our standby, after which normal service will resume. Thanks for your patience during this time.
Planned downtime for Thursday, April 14, 16:00 UTC
We’ll be taking all services down tomorrow, April 14, at 16:00 UTC (11 am CDT, 9 am PDT, 6 pm CEST) in order to reboot our primary database server. Downtime should be 10-15 minutes in duration. As usual, thanks for your patience!
Planned downtime for Wednesday, March 29, 16:00 UTC
We’ll be resuming maintenance on our database servers starting tomorrow, March 29, at 16:00 UTC. Like the previous downtime on March 2, we’ll need about 15 minutes to transfer services from our primary database server to our standby. Thanks again for your patience.
Planned downtime for Wednesday, March 2, 16:00 UTC
We’ll be performing some critical maintenance on our database server starting at 16:00 UTC on March 2. Some brief downtime (hopefully less than 15 minutes) will be required to transfer services from our primary database server to our standby, which will allow us to upgrade the primary’s system and perform hardware checks. Thanks for your patience during this time.
Kendraio Bounty: MusicBrainz integration
Our friends over at Kendraio want to integrate the MusicBrainz API into their app and are offering a bounty to a developer to help them do it. Kendraio App is a low-code bi-directional dashboard data browser. The aim is to enable Kendraio App users (including music artists) to search and browse, and also upload information to MusicBrainz. Here’s a ready-made example of how easy it is to create Kendraio Flows that connect to our API.
And within Kendraio App they’ve built Kendraio Player, a proof-of-concept for a multi-service music streaming player using web monetisation technology, funded by Grant for the Web.
The timeframe is about 2 weeks — start any time from now. The bounty is $500 USD (paid out via https://opencollective.com/kendraio – so you need to have an account there to be paid – but that’s easy). Please answer their bounty by replying to their GitHub issue.
See how their first bounty went at Kendraio Player Audiotarky integration. And see Radhy’s writeup of his experience at Afterthought on integrating Audiotarky API into Kendraio App.
Incident report: January 27th service outage
On January 27th, starting at 4:31UTC we were hit with increasing amounts of traffic from what appeared to be hundreds of different IP addresses mostly belonging to Amazon Web Service IP addresses. At 8:46UTC the inbound traffic overwhelmed our systems and brought nearly all of our services to a standstill.
After investigating the situation and receiving no meaningful assistance from Hetzner (our ISP who advertises DDoS mitigation services as part of their offerings) we blocked three subnets of IP addresses in order to restore our services. At 13:14UTC we put the block in place and our services started recovering.
We reported the issue to Hetzner and to AWS shortly after restoring our service. The next morning we received a friendly email from Andy, who works for one of our supporters at Plex, stating that they received a complaint from AWS. What happened next and how this matter was resolved is told by Andy himself:
Overnight on Wednesday, first thing Thursday morning, we received an abuse report that our servers were flooding an IP that corresponded to musicbrainz.org. We scrambled to investigate, as we are happy MusicBrainz partners, but it was a strange report because we run our MusicBrainz server and hit that instance rather than communicating with musicbrainz.org directly. And the IPs mentioned were specifically related to our metadata servers, not the IPs that would be receiving data updates from upstream. Just as some of our key engineering team members were starting to wake up and scrub in, it started to seem that it was a coincidence and we weren’t the actual source of the traffic and had simply been caught up in an overeager blocking of a large IP range to get the services back up. Never trust a coincidence. We continued to stay in touch with the team at MusicBrainz and within a few hours we had clear evidence that our IPs were the source of the traffic. We got the whole engineering team involved again to do some investigation, and we still couldn’t figure much out since we never make requests to musicbrainz.org and we had already worked to rule out the potential of any rogue access to our servers. By isolating our services and using our monitoring tools, we finally discovered that the issue was actually our traffic to coverartarchive.org, not musicbrainz.org, as they happen to be serviced by the same IP address. And this made much more sense, as we do depend on some API calls to the Cover Art Archive.
The root cause was an update to the Plex Media Server which had been released earlier in the week. There was a bug in that update that caused extra metadata requests to our own infrastructure. We had noticed the spike in our autoscaling to accommodate the extra traffic and already put together another update to fix the bug. That extra traffic on our infrastructure also translated to a more modest increase in requests to some of our metadata partners, including CAA. While the fix was already rolling out to Plex Media Servers, this provided a good opportunity to evaluate the CAA traffic and put our own rate limit in place to protect against future issues. We wrapped up that change in the afternoon on Thursday.
Throughout the ordeal, we appreciated the communication back and forth with our partners at MusicBrainz so that we could work together to investigate and follow leads to find a timely resolution.Andy from Plex
While this whole situation was very stressful and frustrating to us, in the end it was resolved by a very friendly and technical detective game to identify and resolve the issue. It is always nice when geeks talk to geeks to resolve issues and get services working again. Thank you to Andy and his team — let’s hope we can avoid an issue like this in the future.
We’d apologize for the trouble caused by our IP address block and for our services being unavailable for several hours.
EDIT: We should also mention that all of our services are served from one single gateway IP address, so coverartarchive.org and musicbrainz.org have the same IP address.
Leaked email address incident: 2020-11-23
We’re saddened to write that we’ve let some of our users down by accidentally leaking their email addresses and birth dates via a bug in the web pages of musicbrainz.org. This caused some users to receive unwanted spam emails.
However, we would like to emphasize that no passwords, passwords hashes or any other bits of private user information other than email addresses and birth dates were leaked.
If you have never added or edited an annotation on MusicBrainz, then your email address and birth date were never leaked and you can ignore this — your data has not leaked.
About two weeks ago a MusicBrainz editor contacted us to say that their email address that was in use only at MusicBrainz had received spam. The user changed the email address to a very distinct email address in order to rule out a spammer guessing the updated email address. But it happened again, and the user received email to the unguessable email address.
At this point we began an audit of the MusicBrainz server codebase in an attempt to find out where the leak was, patch it as soon as possible, and discover who was affected by it.
What we found
On 2019-04-26 we released a new version of the MusicBrainz server and in this version we added email addresses to the list of editor data we pass to our server to build MusicBrainz pages. The goal of this was to display them in admin-facing pages to, ironically, be able to fight spammers who were using MusicBrainz as a spamming tool. We also added the editor’s birth date, to be able to congratulate them on their birthday. Neither of these cases should have ever been a problem, since the private data should only be used on pages built and sent from our own server (where the data cannot be seen by anyone else), and any editor info sent to the users’ browser goes through a “sanitizing” process eliminating all this private information.
After some digging, we discovered that due to a bug we had overlooked in the code that stripped this data, the addresses and dates had started being sent to the browser whenever an entity page with an annotation was requested. The email address and birth date of the last person to have edited an annotation in MusicBrainz (any annotations, attached to any of our entities) was leaked on the page for the entities in question. This data was contained in a massive block of JSON data in the page source and was never shown on the web page for humans to see, which is why this issue went undetected for so long.
Who was affected
We looked at all editors who wrote any annotations that were displayed between the date the problematic code was released and the date the bug was fixed. This can mean either the annotation was written during this time period, or it was written before that but (being the latest version of the annotation for the entity) it was still displayed during this time period. This gave us a total of 17,644 editors whose data was at some point visible from the JSON block in at least one entity’s source code. We sadly do not have a way to know for sure how many of the affected were actually ever found and stored by spammers, since we attempt to block botnets as much as possible. As such, we simply have no way of knowing who was really affected by this leak — only who might have been.
What we’ve done
Once we detected the issue on November 22, we immediately put out a hotfix to all production (and beta) servers plugging the leak. The hotfix acted to sanitize the editor data by removing email addresses and birth dates from the JSON. We also deployed two additional changes that should help prevent similar issues from occurring, by avoiding sending sensitive editor data to our template renderer altogether. See all changes from the git tag
We are planning to improve our testing infrastructure to detect exposure of editor data — this will become a routine part of our continuous integration process. We are also going to ensure that any pull request dealing with editor data goes through a strict testing checklist.
How did spammers get these email addresses?
You might be wondering how such an obscure leak in a web page can end up in spammers finding and using your email — you’re not alone.
Our sites are under near constant traffic from seemingly random internet bots fetching thousands of our pages in a day, with no apparent goal. All of our metadata is available for download, so why would someone download pages from us at random?
Well, we now know — web pages can contain a whole host of random data that shouldn’t be there. Email addresses, birth dates and such are just the starting point — there have been websites that have leaked credit card numbers and even login passwords, possibly compromising the integrity of user accounts.
In this case it appears that a botnet kept downloading pages from musicbrainz.org and driving the load on our servers up. We’ve been trying to block botnets ever since they’ve come into existence, but this is a laborious task that is never complete.
It appears that spammers used the botnet to scour the internet for private data such as emails to then send out lovely spam emails to all compromised users.
We would like to wholeheartedly apologize for this data leak. We take data privacy seriously and we aim to have high standards about privacy and data security. We find ourselves frustrated by the endless data leaks that happen on the Internet on a seemingly continuous basis and work hard to avoid committing these mistakes in our domain. However, we’re also human and we do make mistakes periodically. As explained above, we’re working to improve our systems and processes in order to prevent this from happening again.
We hope that you accept our most sincere apologies for this leak.
Robert Kaye, Michael Wiencek, Nicolás Tamargo and Yvan Rivierre
Reminder: Upgrading to PostgreSQL 12 on May 18, 2020
As we announced in February, in two weeks time (May 18, 2020) we’ll be upgrading our production database server to PostgreSQL v12 (from v9.5). At the same time, v12 will become the minimum supported version for MusicBrainz Server, so we ask that you upgrade afterwards as soon as possible! If you’re still unsure, a Q&A is below.
When do I need to upgrade my postgres by?
As soon as possible after May 18 if you’d like to keep your musicbrainz-server code up to date.
How do I perform the upgrade?
We’ll provide instructions closer to May 18. It’s recommended that you don’t upgrade until then, since we’ll be providing scripts to resolve some issues.
Will the live data feed (replication packets) stop working right away if I don’t upgrade?
No, as long as you keep your musicbrainz-server code checkout on the
v-2020-05-11 tag (which will be the final release before May 18) or earlier. Future releases may work for a while too.
This is not a schema change release, so replication will continue to work smoothly until you upgrade. No tables or views will change.
However, to make the upgrade process smoother we’ll be dropping the musicbrainz-collate and musicbrainz-unaccent extensions, instead using PG’s builtin collation support for the former and replacing the latter with the unaccent extension from postgresql-contrib. A few SQL functions are being added to enable this, and some indexes need to be rebuilt. This will all happen as part of upgrade scripts we provide (or you can import from scratch). Some features of musicbrainz-server that use these old extensions may cease to work if you don’t apply them.
The extension changes above don’t actually make use of any new PG 12 features. We’ll avoid using such features for at least 1 month.
If I’m already running PostgreSQL 12, do I need to do anything?
Yes, but things will be easier for you. As mentioned in the previous answer, we’ll be dropping the musicbrainz-collate and musicbrainz-unaccent extensions to make the upgrade process smoother for pre-v12 instances. So you’ll only have to run some upgrade scripts we provide to replace those extensions and rebuild some indexes.
My host/distribution doesn’t have PostgreSQL 12 yet!
If you’re running Debian or Ubuntu, the PGDG maintains an APT repository with the latest versions. These are the same packages MetaBrainz uses in production.
Amazon RDS supports PostgreSQL 12 since March 31.
I absolutely cannot upgrade yet! What should I do?
You can stay on the
v-2020-05-11 release of musicbrainz-server or earlier until then. Replication packets (i.e. the live data feed) will continue to work until the next schema change on that tag, but you’ll have upgraded to v12 by then, right?
Instead of performing a
pg_upgrade and running these upgrade scripts you mentioned, can I just import fresh data dumps into a new v12 cluster?
Of course. Just make sure your musicbrainz-server git checkout is on the
v-2020-05-18 tag (once that’s released) or later before performing the import. And keep in mind it may be slower than a direct upgrade.
Upgrading Postgres instead of schema change: 18 May, 2020
We’ve long procrastinated upgrading our production Postgres installation and we’ve decided to forego a schema change upgrade and instead upgrade Postgres to version 12.x. (We will migrate to whatever the latest stable version in the 12.x series will be).
This means that on 18 May we will not make any changes to the MusicBrainz schema, but we will have some amount of down-time and/or read-only time while we upgrade Postgres on our production servers. We haven’t sorted out all of the exact details of how we will carry out this database upgrade, but the date is now confirmed.
If you operate a replicated instance of the MusicBrainz database we STRONGLY urge you to upgrade your installation shortly after we upgrade the production servers. After this release our team may start using Postgres features not available in Postgres 9.5.x, which is our current production version.
As usual for our releases that impact our downstream users, we will post many more details closer to the date and once the migration is complete, we will post detailed instructions on how you can upgrade your own installation.
Please post any questions you may have!
Planned downtime: Thursday, October 10, 15:00 UTC
We’ve scheduled downtime for all our services at 15:00 UTC on October 10 (8 am PDT, 11 am EDT, 5 pm CEST). The plan is to perform some database maintenance in under an hour. Here’s a handy countdown of when we’ll begin the downtime. Thank you for your patience!