Upcoming Rockbox.org unavailability due to hosting drama

[speachy]

Some of you may have heard that FOSSHost has run into some major operational problems.  The specifics don't matter (and are still developing as I type this) but the net result is the same.  At some unknown (but presumably soon) point in the future, the VPS hosting everything but our email and dns is going to be shut off.

So I'm scrambling right now to arrange new hosting and set up a migration.

The good news is that even if our host goes away without any further warning, we have nightly off-site backups of everything on rockbox.org, so at worst we'd lose a day of data (gerrit, irc logs, daily builds, and so forth), and it would take quite a bit longer to get going again (due to my _very_ poor upload speeds here -- the original reason I stopped hosting it myself!)

What will probably happen is that we'll move to a commercial VPS hosting provider, TBD. We have the funds to cover this for a couple of years, but obviously any donations we receive will help.

I'll post more information as the plans solidify, but just keep in mind that we could go dark at any point until we're on new hosting.

[Frankenpod]

Does that mean, until it's rehosted somewhere else, it will cease to be possible to install the RB bootloader on ipod classics?

What with there being no option for manual installation of the bootloader, and the utility insisting on downloading it?

[speachy]

Yeah, if the rug gets yanked out from underneath us, *.rockbox.org and everything hosted on it (including anything the Rockbox Utility fetches from download.rockbox.org) would become unavailable until we're migrated to the new host.

Manual installation is possible, but you'd have to compile the bootloader and the helper utilities yourself if *.rockbox.org is unavailable.  There's a source code mirror on github (and probably elsewhere).

Again, if we get the rug yanked out from underneath us before we're ready to migrate to a new host, and we consequently go dark with no notice, we will return, with basic www stuff back as soon as DNS can be switched, though it might take a few days to get full services restored.

[Frankenpod]

This prospect makes me want to request for RB utility to offer the option of selecting a locally-stored bootloader file.  Then I could pre-download the bootloader and not be dependent on the site still being up in order to install RB on an ipod in future.

  If I understand correctly, the bootloader is the one element that can't easily be installed manually (short of compiling it oneself, as you mention - which I guess would need me to get my linux PC working again, which I'm too lazy to do).

[Bilgus]

Request all you want but if you are too lazy why expect someone else to tfake the initiative?

[bluebrother]

Rockbox Utility did have an offline mode on the past. It always had problems, so ot was consciously decided to remove it. Also, the same would apply for all other bootloaders. Or builds, for that matter.

There's no problem in building the necessary command line tools and getting the necessary files. You just need to do it. Actually, installation was always first manually for all players. Only after that Rockbox Utility got the necessary support.

And it's not compiling the bootloader, you can download that. Rockbox Utility does the same. You need ipodpatcher or mks5lboot, depending on which Ipod you have. Which you can easily compile with cmake these days. And for ipodpatcher we have binaries available.

[speachy]

I think the point being that if download.rockbox.org is down, then there's no way to download anything. 

But again, you can compile everything needed from the source code, including the player firmware, bootloader, and the tools to manually install it.

[Frankenpod]

Request all you want but if you are too lazy why expect someone else to tfake the initiative?

I know, I know, I expected that response.  It is of course an entirely fair point.  (I had a dev environment set up once, but that computer had a hard-drive failure and haven't got round to getting it working again)

  Just that if RBUtility had that option it would be useful for all users, making installation of RB independent from having access to the site, once you'd downloaded the components. 

 It's just a mite frustrating to have a local copy of the bootloader but no way to tell RBUtility to use it instead of trying to download it.   I assume there were some technical issues that made using a local copy of the bootloader copy problematic, I just don't entirely grasp what makes it so different from downloading one, particularly as sometimes RBUtility uses cached copies of things.

Edit - answering my own question, I guess if someone were daft enough to select the wrong file as the bootloader they might brick their device?

[amachronic]

I think the point being that if download.rockbox.org is down, then there's no way to download anything. 

Couldn't this be easily solved by mirroring the bootloaders at a secondary site? Then RButil could just be pointed at an alternate server URL.

[speachy]

Couldn't this be easily solved by mirroring the bootloaders at a secondary site? Then RButil could just be pointed at an alternate server URL.

It's not just the bootloaders, it's potentially everything that rbutil could download.  That currently amounts to 80-odd GB.

Also, IIRC download.rockbox.org typically uses something like 400GB/month in bandwidth.

[speachy]

I'll post more information as the plans solidify, but just keep in mind that we could go dark at any point until we're on new hosting.

I now have a new VPS arranged, with considerably more oomph that we had before.  Over the next few days I will get it set up, along with an initial data transfer, and when things are ready, I'll announce the downtime window for the final switchover.

(The new VPS is beefier than what we had before, and will provide us with plenty of room for growth)

[speachy]

I'll post more information as the plans solidify, but just keep in mind that we could go dark at any point until we're on new hosting.

We've had a new host for a few weeks now, and I've been syncing it up every day.  What's left is to actually schedule a final switchover.

I currently intend to do this Christmas Day.  Shouldn't take more than a couple of hours, most of which will be due to DNS delays.

[speachy]

It's three months later than I'd hoped (yay, Life) but I'm _finally_ ready to perform the switchover to the new host.

So, this coming Sunday, March 26th, starting about 12:00PM (US Eastern Time) we're going to be offline for a couple of hours while I take things down, synchronize any remaining data, and wait for DNS to finish propagating.

The new VM has been running stably for three months, started from a complete snapshot of the current VM, and I've been keeping the data synchronized at least every few days (on top of the nightly backup of everything) so I expect overall downtime to be limited mostly to the time it takes to propogate DNS changes.

The new host will be paid for out of rockbox funds, and is about double the overall oomph of the current one.  And should be free of any drama.

I'll post a reminder closer to the date, but most folks will probably not even notice anything changing.

[speachy]

I'll post a reminder closer to the date, but most folks will probably not even notice anything changing.

Again, as a FYI, rockbox.org will be completely offline for an hour or so starting 12pm US Eastern time on 2022-03-26.

I expect downtime to be less, actually -- the long pole will probably be DNS Propagation.

[speachy]

Again, as a FYI, rockbox.org will be completely offline for an hour or so starting 12pm US Eastern time on 2022-03-26.
I expect downtime to be less, actually -- the long pole will probably be DNS Propagation.

If you're reading this, you're on the new server.

Everything went smoothly, at least on the rockbox side of things. 

(I got started late thanks to a network problem at home.  And now I can get back to dealing with that...)