frongt

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!

We are almost certainly an outlier.

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.

If it’s all internal (and you haven’t set up any extra firewall zones or rules) then you won’t need any firewall rules to allow it.

You should probably be able to just ping immich.homelab.internal right now, and make an http request and get something back too. Even if it’s an http error, that still means you’re talking to an http server successfully.

I haven’t used opnsense in years, and I’ve never used caddy, so I don’t know if the config is right, but it looks reasonable and the concepts are the same as what I’m used to.

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.

It sounds to me like you just have a higher risk tolerance, and if you accept that, that’s okay.

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.

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.

Or run an internal CA

You will.

Anything you expose should be designed for it (e.g. not jellyfin). You should have a WAF configured for the type of service you’re hosting. You can’t just drop one and have it magically protect you, they take configuration. Same with fail2ban.

And you should have these services in a DMZ, so that a compromise in one doesn’t provide an entry point to other resources on your network.

you really gonna tell us about your dogs and not share a pic?

There’s not nearly enough dog metrics on that dashboard

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.

No, if everything supports it, you can can get full gigabit line rate in both directions at the same time.

You don’t strictly need a managed switch, but I would recommend it for security.

But where are you getting half duplex from? I’ve never seen anything support half duplex gigabit Ethernet. A router on a stick is as fast as your adapter chipset can push packets.

I would recommend this over the M.2 adapter. USB3 goes up to 5 gbps, so gigabit Ethernet should be no problem. Just get an an adapter from any actual brand, even if it’s just tp-link. No junk non-brand ones because they’ll be unreliable or not work at all due to a bad chipset.

Rayon was patented in 1885

I don’t see it, but I do see plenty of criticism of the use of claude.

I searched issues for “compare-dest”, which seems to be the part they were complaining about being broken, and I didn’t see any issues that looked relevant. I also looked through the commit log between 3.4.1 and 3.4.3 for anything mentioning that option and didn’t see anything there either. So right now it just looks like fearmongering to me.

Fuck’s sake. What was the actual bug introduced? I skimmed the issues on GitHub and nothing jumped out at me.

This. Docker compose down, schlep the data over, update paths and permissions, docker compose up. Done.

Probably bring it up one step at a time so you can more easily identify anything you missed.

I mean at least one of them has to be record breaking by definition