Issue Found with Federation via Redirect to a CDN

A follow up from « Optimising The Internet Pipes » with information I can't forget in the future

A little follow up from my previous post with a bit more information on what I did, what happened, and the solution. I’ll certainly need this in the future but maybe somebody else in the Fediverse using Plume could find this interesting.

The Beginning

My current Plume set up is a bit of a hash to make things work, right now the physical server this is hosted on is at Oracle. What I can’t get to work with Oracle is their god forsaken Firewall to open ports.

To get around this, I use Pagekite because it is also something I use for some self-hosted machines at home that I can’t pass through the front facing web server at oh.mg.

This adds a little level of latency and there is a bandwidth cap I can’t just blaze through. Before Plume was using a couple hundred Megabytes here and there and that was OK. Recently with it federating more, that has blown up into Gigabytes. When loading blog.sus.fr it lags because the assets are hanging on for the main server that isn’t exactly living its best life.

The Idea

Get Bunny to front the static media reducing the load on the server / connection. This is also a great stepping point to bring the Plume server back in to my apartment, where my current ADSL connection would struggle hard with this kind of usage.

Implementation

The easiest way I found is to break a hole in Apache’s proxy_pass and 301 redirect /static/* to a subdomain that bunny manages, in this case static.sus.fr.

The Problem

There were two issues here, first one was that Bunny was a bit too conservative with the cache and was still waiting on the server to dish back content it should already hold.

To rectify this, I switched on Perma-Cache using a storage zone that I have replicated everywhere possible. This will probably increase my monthly rate from 3¢ to 10¢ but make it less dependent on the home server. I can not stress how important this is behind my trash ADSL.

The second issue is that for unexplainable reason the header image wasn’t being successfully federated along with the post. The redirect was working, if you call from blog.sus.fr or any other federated instance with an image embedded in a post, the CDN was serving it with glee.

I did a bit of testing and I couldn’t work it out, so I asked the Plume Matrix channel.

¿Qué Pasa?

Trinity is the one who figured out what was happening, I think I’ll let them explain : trinity saves us all

hum that’s an interesting bug. We always add a header Host: <original domain> for some reason. It works fine if you don’t redirect, or you do redirect within the same domain, but it fails pretty bad for your setup. the server behind static.sus.fr receives a request for blog.sus.fr, and some bunny answers it doesn’t know that domain, fediverse.blog caches that error and serves it as an image, which the client can’t decode because it’s not actually a picture

Basically, other instances were recognising that the redirect was happening, so it requested the file from static.sus.fr while at the same time passing the hostname blog.sus.fr to Bunny. Bunny doesn’t have blog.sus.fr registered as an end point and returned an error that Plume saved the content thereof as if it was an image.

The Fix

Like with most things in our lives, lying our way out of a problem can be a surprisingly great option. I setup blog.sus.fr as an endpoint and skipped the verifications because I couldn’t repoint the subdomain there.

This left me with one loose end, no verification, no SSL.

Great news is that I was mulling over a wildcard cert for sus.fr to use on the home server when I came to set it up (long story, but the front facing server is a pain in the ass and I can’t use LE).

I uploaded the new cert to Bunny to avoid any SSL errors and now it is happily serving content for blog.sus.fr when it gets requested by a Plume instance.

proof from bunny