Nah just jam a screwdriver in there to jump the pins.

You shut down your PC though?

Through termux? You’re running this on an android phone? I didn’t know you could do that. What process did you follow? What happens if you rerun the installation process?

It’s a good option if you can’t do anything better, like a VPN. Because there is always the risk of an authentication bypass vulnerability. The less attack surface, the better.

That’s low utilization. If your ram was fully used and stuff was being frequently stopped, that’s when I would be concerned (and when you would experience wear on your SSD).

Right now you have less than a quarter used, and a couple things the kernel decided to swap out. Perfectly normal.

You should simulate a number of repos and users to produce a realistic estimate. I would find that extremely useful, as would some of my colleagues at work. You should be able to scale up to a few hundred of each without too much trouble, and there will be no risk to running into any limits. I’m looking forward to this!

Fifty pounds??? Yeah that’s not going to work with just front rack ears, even if the batteries were all the way to the front.

Measure the screw holes and check them against other ears. They might be a fairly common pattern.

Also make sure that the ears will properly support the weight of the UPS. Lead-acid batteries are hefty. I can’t tell from a quick search how it’s supposed to be set up. It might need ears front and back. Or, you might find full rails.

If all else fails, get a rack shelf and just let it sit on it. Or get some scrap wood and/or steel and fabricate something.

Can’t get any simpler than the terminal, can you? I just paste links into the terminal after a yt-dlp command.

You don’t need an external domain. Use .internal as your tld and you can use whatever domain your want. jellyfin.homelab.internal, for example.

I own a domain and run my internal stuff under internal records. Part of the reason for doing it this way is I can use the DNS challenge for issuing LE certs to the internal services automatically.

And no a reverse proxy will not expose anything to the Internet, unless you also open the port in your firewall (and forward it in NAT if it’s on the lan and you use NAT).

Check the Netbird relay setting and try toggling it. I recall some people mentioning it defaults to something that can cause slow connections.

You are welcome to expose it at your own risk. Assess you own tolerance for compromise (personal data compromise, becoming part of a botnet, becoming a host for spam or CSAM) and proceed accordingly.

Sure, any project designed to be exposed to the Internet. Web servers would be the most obvious.

That first page says exposing it to the Internet is “not recommended”. Putting a reverse proxy in front of it does not meaningfully change the security posture. A malicious request to http://jellyfin.homelab.com/exploitable-page will be sent to jellyfin in effectively the same way, whether through a reverse proxy or not. You would need a WAF set up specifically to look for relevant exploit attempts.

https://github.com/jellyfin/jellyfin/issues/5415

Those are some outstanding known vulnerabilities, most of them unfixed. They are not particularly severe, but it shows that thorough security is not a priority for the jellyfin devs.

There is no safe manner of exposing jellyfin.

There’s not nearly enough dog metrics on that dashboard

Please don’t expose jellyfin to the Internet. It is not hardened against attackers.

The code doesn’t really look AI generated, no.

What’s your backup strategy?

I would open an issue asking for documentation.

Yikes. If there’s no mainline support you’ll be stuck on whatever version the vendor gives you.