Nephele with SERVE_LISTINGS turned on and a read only mount.

It shows listings in the browser, just like Apache, but can also be accessed with a file browser, because it’s a WebDAV server.

Flatpaks are awesome. Flathub is awesome. :)

It’s their machine. It’s a front door.

That’s not a vulnerability. That’s intended and desired behavior. It was really useful in this case too.

I should mention that the WebDAV share is password protected, so only he has access to do that.

Something really fun I found out recently, when my friend lost all access to his system except for a single WebDAV share by accidentally turning off all his remote admin access:

If you write “b” to /proc/sysrq-trigger, it will immediately reboot the system (like holding down the reset button, so inherently a bit dangerous).

He was running Nephele with / mounted as the share, so luckily he just uploaded that file with a single “b” in it, and all his remote admin stuff came back up after the reboot.

This absolutely can happen to stable projects. This has happened with Mastodon many times, and Mastodon has been stable for years.

It also has happened with Nextcloud many times, and again, Nextcloud has been stable for years.

It’s not a stability thing, it’s an automation thing. We as devs can only automate so much. At a certain point, it becomes up to you, as the administrator, to manually change things. Things like infrastructure changes, and database migrations, where the potential downtime if we automate it is something we need to consider.

This is very cool, but also very dangerous. Many projects release versions that need some sort of manual intervention to be updated, and automatically updating to new versions on docker can lead to data loss in those situations.

Here’s a recent example from Immich:

https://github.com/immich-app/immich/releases/tag/v1.133.0

It is my humble opinion that teaching newbies to do automatic updates will cause them to lose data and break things, which will probably sour them from ever self hosting again.

Automatic OS updates are fine, and docker update notifications are fine, but automatic docker updates are just too dangerous.

I take it you’ve never even tried Linux before. Both of those things are not things that will hold you back. My mom uses Linux, and she barely knows what “right click” means.

With regard to your Steam games, as long as you don’t play games that use restrictive anticheat, you’ll be fine.

I have all Reolink cameras and they’re awesome. They have both indoor and outdoor cameras. They’re really expensive compared to other similar cameras, but the software is really good, and there’s no subscription. You don’t even need to log in. Everything is only stored locally, on either SD cards in the camera or a separate “home hub” (or both). They have motion and object detection built into the cameras.

The way I have them set up is every indoor camera is plugged into a smart outlet that disconnects their power through Home Assistant when either me or my wife are home.

The outdoor ones are connected to solar power, so I didn’t even have to run any wires.

I’d highly recommend them.

So, Jellyfin is one of those apps where the Docker documentation is really lacking. I’m gonna give you my docker-compose.yml file in case it helps:

services:
  jellyfin:
    image: jellyfin/jellyfin
    user: 0:0
    restart: 'unless-stopped'
    ports:
      - '8096:8096'
    environment:
      #- JELLYFIN_CACHE_DIR=/var/cache/jellyfin
      #- JELLYFIN_CONFIG_DIR=/etc/jellyfin
      - JELLYFIN_DATA_DIR=/var/lib/jellyfin
      - JELLYFIN_LOG_DIR=/var/log/jellyfin
    volumes:
      - ./config:/config
      - ./cache:/cache
      - ./data:/var/lib/jellyfin
      - ./log:/var/log/jellyfin
      - /data/jellyfin:/data/jellyfin
    devices:
      - /dev/dri

For me /data/ is my RAID array, which is why my jellyfin data directory is there. Everything else goes in the same directory as the compose file. My system has a graphics card that does transcoding (Arc A380), so I have /dev/dri under devices.

You should learn a lot about Docker Compose, because it will help you tremendously. I use Jellyfin behind an Nginx Proxy Manager reverse proxy. I’d highly recommend it. Here’s my compose file for that:

services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    network_mode: "host"
    #ports:
    #  - '80:80'
    #  - '81:81'
    #  - '443:443'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

Running in “host” mode is important, instead of just forwarding ports, because it lets you forward things to localhost, like pointing https://media/.[mydomain]/ to http://127.0.0.1:8096/ for Jellyfin.

Anyway, best of luck to you, and I hope that helps!

Use Portainer if you don’t want anything to be portable. There are other issues too. Just use Docker Compose.

Is there a reason you’re not using Docker?

Because the Android SDK is owned and controlled by Google. They’ve consistently made decisions to make it harder to stay out of their ecosystem (like the new “Integrity” API).

As consumers, we would vastly benefit from having another choice that isn’t controlled by one of the biggest tech companies in the world.

I like how their idea of entry level is a 16GB RAM phone for €890.

Fedora

That’s the thing though, free social media was giving them massive returns. But the line must go up. And once they completely saturated the market, there are only two ways to make the line go up: expand the market (give Internet to communities that didn’t have it), or extract more money from your existing users (enshittify). Facebook made a half assed attempt at the first one for a couple years, then pivoted hard to the second.

It’s simpler, there is a client for everything even mobile phones, it has a move command, it has props that can be edited without a copy command, pagination is however you set it up to be rather than a one size fits all approach, it can be just as scalable as S3 if you build it to be, it has much simpler locks that make them easier to use so you might actually use them, keys can be longer than 1024 characters, actual directories exist.

That’s just the protocol level. The biggest benefit for me isn’t really at the protocol level, but part of the design of my own WebDAV server: deduplication. I can throw the same file into my server with 50 different keys, and it will only take up the space of one copy on disk. This basically moved the logic of deduplication from my application to the blob store. Mountains easier from an application design perspective.

There are use cases where S3 is better, but they are few and far between. And, WebDAV is extensible. You can build whatever functionality you need into it, rather than using some proprietary protocol.

I’ve completely switched away from using Minio (and just the S3 protocol in general) in all of my projects.

I’ve found that the WebDAV protocol is better for object storage in almost every case. It’s also way simpler to use and understand.

Now it’s time for me to shill:

I wrote my own WebDAV server called Nephele. It’s free and open source, and you can run it on Docker. Probably doesn’t help if you’re using something that requires S3, but if you’re building something, I implore you to migrate away from S3.

A hosting provider is a business. If your dad is a business and you are buying hosting services from him, then yes, he is a hosting provider and you are not self hosting. But that’s not what you’re doing. You’re hosting on your own hardware on your family’s internet. That’s self hosting.

When you host on Hetzner, you’re hosting on their hardware using their internet. That’s not self hosting. It’s similar, cause like you said, you have to do a lot of the same administration work, but it’s not self hosting.

Where it gets a little murky is rack space providers. Then you’re hosting on your own hardware, but it’s not your own internet, and there’s staff there to help you… kinda iffy whether you’re self hosting, but I’d say yeah, since you own the hardware.

Their dad is not a hosting provider. I mean, maybe he is, but that would be really weird.