Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
Jellyfin is very conveniently packaged in docker, so while it may seem daunting, I highly recommend at least trying that route.
Running an nfs mount, docker or not, should be perfectly fine. Jellyfin just uses normal storage so won't care if it's nfs. No real special considerations with proxmox either, especially without worrying about a dedicated GPU. Just spin up a Debian guest and go.
Jellyfin is also conveniently packaged as a .deb and provide a repo for Ubuntu/Debian. It's pretty easy to spin up a Debian container, add the repo, and apt install jellyfin, IMHO easier than doing the same thing with a VM, then docker...
Yes, but less portable. Harder to work with if you have to move stuff around, like migrate to a new VM.
The other comment made sense to me, why contain a container. But you are right, I will learn more about docker, it seems like a great tool.
Thank you for your confirmation with NFS. Just read about it yesterday, in search of an alternative to samba, what all the windows user seem to use.
You "contain the container" because the VM provides storage and compute for docker (the docker container needs to run "somewhere").
I use a VM on proxmox to run a jellyfin container. VM mounts needed NFS dirs for config and media. Then create a systemd service to start/stop the container.
I understand that I can use a VM to run docker, but:
Wouldn't make a LXC more sense than a VM with docker inside? And what are the advantages of running jellyfin in a container instead of a normal installation? The VM is already kind of a container, what benefits do I get from yet another container inside? I am curious to learn more!
Your head might be spinning from all the different advice you're getting - don't worry, there are a lot of options and lots of folk are jumping in with genuinely good (and well meaning) advice. I guess I'll add my two cents, but try and explain the 'why' of my thinking.
I'm assuming from your questions you know your way around a computer, can figure things out, but haven't done much self-hosting. If I'm wrong about that, go ahead and skip this suggestion.
That summarized my situation pretty good. Since a year now I switched everything to Linux, selfhosting seems to be a natural extension of that.
May I ask, since you have a very beginner-friendly way of writing:
Why did you choose SMB instead of NFS? I read here that NFS is very efficient and fast.
Many people here have very convincing arguments for docker. While checking it out I saw that it uses partly proprietary licenses. Why are so many people so sure that docker won't pull a 'Unity-stunt' and make their knowledge about docker obsolete?
I meant to install a Jellyfin LXC, if there is such a thing, without docker involved. Is that possible?
The Docker engine itself, meaning the
dockerd
daemon, its APIs and thedocker
CLI, are all under Apache 2.0. The non-free parts are mostly in their Docker Desktop offering, which is mostly a convenience GUI and not absolutely necessary (the easiest, on Windows and macOS, probably, but not the only one) to run Docker on most platforms.Docker lets the maintainers configure all of the dependencies for you. You then don't need to worry about whether you're using debian, ubuntu or even fedora. When you upgrade jellyfin you just pick the new tag to pull without worrying about whether it needs a new version of ffmpeg or if it works with avconv.
It gets you out of the business of trying to maintain compatibility and just keeping your os up to date.
Feel free to use lxc though. I had issues with using lxc that I couldn't work around so I use cloudinit ubuntu/debian images instead. I think the issue I had was actually using NFS but I don't remember...
My experience with LXC hasn't been ideal, but for reasons that are by design. The permissions make it complicated for the way I use it. Proxmox has all of the storage, which is shared with the LXC as a Mount Point. The LXC has unique user PIDs and GIDs, so if the LXC modifies a file, now none of my other stuff has permission to access it.
I had to add some config stuff to get around this problem, but in the end I just switched to VMs. I don't care about overhead that much.
Edit to add more info: I think the permissions problem is only if you make the container "unprivileged". The relevant config to add to /etc/pve/lxc/***.conf is as follows:
I have no clue why this works. I think I copied it from Proxmox documentation. It worked and I left it at that.
The user and group mapping for lxc is easy(ish) once you understand it.
The above breaks out as follows: lxc.idmap: [user/group] [beginning host UID/GID] [number of sequential IDs to map]
lxc.idmap: u 0 100000 1000 [maps LXC UIDs 0-999 to host UIDs 100000-100999]
lxc.idmap: g 0 100000 1000 [maps LXC GIDs 0-999 to host GIDs 100000-100999]
lxc.idmap: u 1000 1000 1 [maps LXC UID 1000 to host UID 1000]
lxc.idmap: g 1000 1000 1 [maps LXC GID 1000 to host GID 1000]
lxc.idmap: u 1001 101001 64535 [maps LXC UIDs 1001-65535 to host UIDs 101001-165535]
lxc.idmap: g 1001 101001 64535 [maps LXC GIDs 1001-65535 to host GIDs 101001-165535]
The last two lines are needed because a running Linux system needs access to a minimum of 65336 UIDs/GIDs (zero-indexed).
You can basically think of LXC as running everything on the host system itself, but running it all as UID/GID 100000-65535 by default. In an unprivileged container, you have to remap these to give access to resources not owned by that range.
I wonder, after making these changes is it the same security wise as making the container unprivileged=0?
Nope. It just maps a single user and group from the container to a regular user on the host. With the above config, root in the container has the "real" UID of 100000. It can't make changes to anything any other unprivileged user can. A privileged container otoh runs root as root. It can do a lot of damage. By running privileged containers you're kind of throwing out a good portion of LXC's benefits.
That makes sense. Thanks.