Depends on the drive too, I have some insanely loud Ironwolf drives and you would never guess they’re from the same manufacturer as my practically silent Exos X18s.

I think of it as a lab because it’s my sandbox for me to do crazy server stuff at home that I’d never do on my production network at work, and I think that’s why the name stuck, because back when systems were expensive as heck it was pretty much just us sysadmin guys hauling home old gear to mess with.

My bad. I misread your previous post, specifically around “I agree with the other guy”. That being said, anyone with a functional device that can compute any amount of monero hashes is a proven target, granted, not specifically.

People like you in this industry are legitimately the reason botnets and significant compromise still exists. “You don’t need to be a genius to do all this additional config to make this thing I’m referring to as secure, secure.” Do you even read your own writings before you hit post? Also your final argument is so slathered in whataboutism I can’t even. Yes, any internet connectivity is going to be less secure than an air gap, but when you’re advising implementations you should keep security posture and best practices in mind. What you’re speaking on is more complex than any one person’s understanding of it due to significant layers of abstraction. Exhibit a? Ssh is not a codebase. It’s a network protocol. The codebase is literally different depending on implementation yet you continue to talk about it as if it’s a single piece of software that has been reviewed and like all ssh shares the same vulns but the software is entirely different depending on who implemented it so you have no real clue what you’re talking about and it’s actually sad people will be misled by your nonsense and false bravado. (https://en.wikipedia.org/wiki/Secure_Shell)

I’ve always disliked IT discussions for reasons like this. Everyone who comments seems to think that the mitigations, security considerations, and security compromises (IE, not caring if your images are leaked online) they’ve made are common knowledge… But, this is a forum advising people on how to configure their home severs for hobbiest use. Best practices should be the mantra, “just raw dog ssh on the internet with your 443/80 port mapping and you’re g2g” [sic] shouldn’t be an acceptable answer to you. If they’d stated that there are security considerations, but they like to implement them and expose ssh to the net for management purposes I’d have nothing to say, but to just advise people who lack that extra experience, without helping them understand why you’re okay doing what you’re doing and what you’ve done to solve for specific issues that the default configuration does not seems unhelpful at best.

Agreed, but best practices are meant to deal with the very rare. They didn’t put the vulnerabilities in the software due to negligence or malice, it’s just an ever evolving arms race with cracks that show up due to layer upon layer of abstraction. Again I’m not saying to never expose ssh to the net, quite the opposite, but as a best practice you should never do it unless you fully understand the risk and are prepared to deal with any potential consequences. That’s just a core tenant of understanding security posture.

🤔🤔🤔🤔🤔

https://arstechnica.com/information-technology/2022/02/after-lying-low-ssh-botnet-mushrooms-and-is-harder-than-ever-to-take-down/

Are we living in the same universe? In mine software doesn’t get patched all the time, in fact it’s usually a lack of patches that lead to any significant system compromise… Which happens time and time again. Also you’re on a thread that is advising hobbiests on how to configure and maintain their personal server, not the engineering meeting for a fortune 500. Yes, you can make ssh very secure. Yes, it’s very secure even by default. In the same regard, new vulnerabilities/exploits will be found, and it remains best practice not to expose ssh to raw internet unless absolutely necessary and with the considerations required to mitigate risk. Ssh isn’t even implemented identically on every device, so you literally cannot talk about it like you are. Idk why you’re arguing against the industry standard for best practices decided by people who have far more experience and engineering time than you or I.

“This race condition affects sshd in its default configuration.” direct quote from the linked article, paragraph like… 3. I linked it so people could read, not speculate.

I linked a relevant vulnerability, but even ignoring that, pragmatically, you feel they’d be targeting specific targets instead of just what they currently do? (That, by the way, is automating the compromise of vulnerable clients in mass scale to power botnets). Any service you open on your device to the internet is inherently risky. Ssh best practices are, and have been since the early days, not to expose it to the internet directly.

It’s difficult to say exactly what all a reverse proxy adds to the security conversation for a handful of reasons, so I won’t touch on that, but the realistic risk of exposing your jellyfin instance to the internet is about the same as handing your jellyfin api over to every stranger globally without giving them your user account or password and letting them do whatever they’d like for as long as they’d like. This means any undiscovered or unintentional vulnerability in the api implementation could easily allow for security bypass or full rce (remote code execution, real examples of this can be found by looking at the history of WordPress), but by siloing it behind a vpn you’re far far far more secure because the internet at large cannot access the apis even if there is a known vulnerability. I’m not saying exposing jellyfin to the raw web is so risky it shouldn’t be done, but don’t buy into the misconception that it’s even nearly as secure as running a vpn. They’re entirely different classes of security posture and it should be acknowledged that if you don’t have actual use for internet level access to jellyfin (external users, etc, etc) a vpn like tailscale or zero tier is 100% best practice.

Honestly you can usually just static ip the reverse proxy and open up a 1:1 port mapping directly to that box for 80/443. Generally not relevant to roll a whole DMZ for home use and port mapping will be supported by a higher % of home routing infrastructure than DMZs.

Doesn’t take that to leverage an unknown vulnerability in ssh like:

https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server

That’s why it’s common best practice to never expose ssh to raw internet if you can help it; but yes it’s not the most risky thing ever either.

Size right for your setup and risk tolerance. Just know every outage can come with data loss. Most do not, but it is not a guarantee.

I hate having to run my own backups. That’s been a massively hidden cost behind self hosting that I did not originally account for. Anything sufficiently robust is expensive and anything cheap is unreliable (at least at the scales of data I have, 4k+ RAW videos and photos are massive).

Is this one of those old obscenely small obscenely underpowered net books?

Your pi is idling at 4w? That seems quite high. Does it have a nvme drive attached or something?

UPS systems are generally configured for 90 minutes of operation, depending on the criticality of the system they’re connected to. The best ones are programable and will actually send graceful shutdown signals (when configured to do so) to your server cluster to prevent data loss that occurs during system blackouts. You can emulate this behavior on your laptop with a script that checks battery% every 10-15 minutes, sending a shutdown signal if it falls below a treshhold you set.

You’re mistaken. Laptop cells do not behave in this way or use LiPo chemistries. They’re Lion chems and behave entirely different.

Some won’t boot without a detectable battery cell. Depends entirely on the laptop in question what the best course of action is. Most newer bios handle charge profiles automatically and will prevent ac related damage but it’s all dependant on how they were designed/made.

Laptops run on “burst” computing profiles in a lot of engineering situations, occasionally this applies to both the thermal design (runaway heatsoak if used at full tilt) but also battery design. I’ve seen several machines that will dip into their battery in addition to the charger to boost performance and dump wattage into the chips beyond what would be available from the adapter alone. I don’t necessarily think it’s good design, but modern battery chems don’t really give a shit about up/down momentary charge cycles. Also the Chem they’re using is not LiPo based as that chemistry while allowing for significant amperage to be drawn, is not stable enough for a laptop that is generally expected not to ignite.