Chapter 1: A benign installation that couldn’t have any issues.

This blog started with an attempt to install owncast, which I intended to do for group movie viewing with friends. Owncast has a docker build, which is where I decided to start. I modified the command to docker run -v ./data:/app/data --network owncast -p 127.0.0.1:8081:8080 -p 1935:1935 -it owncast/owncast:latest. The change from pwd to ./ is purely an aesthetic choice, --network owncast is for security and -p 127.0.0.1:8081:8080 makes the http interface only available on the loopback so that it can’t be accessed without the reverse proxy I would later set up. I had to create the owncast network manually with docker network create owncast, a step that I seemed to have forgotten when documenting my work with vaultwarden. Once that was done, creating an nginx config as described here worked fine (a surprise) for getting the web portal accessible.

Once I could see the site, I logged into the admin panel, changed the credentials from default, then tried to set up a test stream. Surprisingly, everything worked out of the box with obs on the first try, so no problem.

After that, I found a ffmpeg command that I could run from my seedbox to stream to owncast from here:
ffmpeg -i file.mp4 -c:v libx264 -c:a aac -b:v 512K -maxrate 512K -bufsize 1M -f flv 'rtmp://owncast.gooberweb.xyz:1935/live/zS$&rXoNjzaEEsjLg1w1Avx8LaAdac'

With that working, I decided to stress test the instance and quickly found that it would not scale on the shit ass vps that I use, which caused a dramatic shift to chapter two of this project: fixing jason’s hosting stuff so we can use his less underpowered server.

Chapter 2: fixing jason’s hosting stuff so we can use his less underpowered server.

The problem with jason’s server was, thankfully, not that bad. He had nginx working for static html mosting and an installation of nextcloud which was disabled because it would fight with nginx for ports. The nextcloud install was a whole set of docker containers setup by a script we had found quite some time ago, so we decided to attempt to migrate to an official docker container. We moved the netcloud datadir away from the existing install, purged it and all of the relevant docker containers, then began to setup nextcloud AIO using docker. The docker run command that we created was:
sudo docker run \
--sig-proxy=false \
--name nextcloud-aio-mastercontainer \
--restart always \
--publish 8080:8080 \
--env APACHE_PORT=11000 \
--env APACHE_IP_BINDING=127.0.0.1 \
--volume nextcloud_aio_mastercontainer:/mnt/docker-aio-config \
--volume /var/run/docker.sock:/var/run/docker.sock:ro \
--env NEXTCLOUD_DATADIR="/opt/nextcloud/datadir/" \
nextcloud/all-in-one:latest
The only changes from default are creating the NEXTCLOUD_DATADIR env so that we could move the existing data files into the new install and binding apache to the loopback address because we were using nginx as a reverse proxy.

Note: It might still be wise to change --publish 8080:8080 \ to --publish 127.0.0.1:8080:8080 \

The two major challenges we faced were:
The given nginx configuration for using a reverse proxy does not make the AIO interface accessible at the same time as the apache interface on port 11000 on the loopback network. This wouldn’t be a problem, except for the fact that the AIO interface on port 8080 wants to be https. The solution we found was to remove the existing proxy pass and replace it with this block:
#proxy_pass https://127.0.0.1:8080$request_uri; # uncomment for AIO
proxy_pass http://127.0.0.1:11000$request_uri; #uncomment for regular use
Where one of the two lines is uncommented at any given time. This is inconvenient during setup because it involves a lot or nginx restarts, but it works and becomes much less annoying during regular use.
From what I can tell, this issue doesn’t exist if you are using caddy as your reverse proxy, as there is a special step at the above link that has a configuration for enabling https for AIO on caddy.
The format for storing files in a user’s directory had changed between the latest version of docker AIO and the version which Jason had previously used, which made the process of migrating a headache. If you know the differences, it’s fairly easy, the contents of oldNextcloud/data/user/ get moved into newNextcloud/data/user/files, but that isn’t documented (probably because it’s only a problem when migrating mismatched versions). You need to get this bit right for everything to scan and get added to the database using the migration instructions, so it took us quite a while.
After all that was dealt with, we had a working nextcloud config. And then Jason broke it within a few hours, while I slept.