I’ve been running straight Ubuntu with ZFS-on-Linux since 18.04, and it has been smooth sailing. If you’re running a lot of containerized things it’s very convenient to just be able to bind mount ZFS dataset into containers.
Normally I prefer CentOS/RockyLinux, or some other EL distribution, but in this case I really appreciate that Canonical isn’t purist enough to ship ZFS as a loadable kernel module that is guaranteed to be in sync with the shipped kernel. And don’t have to deal with DKMS.
I believe this doesn’t apply to the Linux kernel. I mean there is a lot of products that include a Linux kernel and runs proprietary code on top.
I’m not really certain about the legalities, but IIRC it has to do with Linux being licensed under GPLv2 instead of GPLv3(?)
You’re saying this as if there isn’t multiple piles mixed fresh and dirty clothes with an O(n^2) complexity to find something you want.
I personally prefer to have my clothes indexed in an ordered storage so I know exactly which row in the drawers clean shirts are in.
While I would say sending MAC Addresses and Wi-Fi names is very far from tracking everything you do on the internet, this highlight another very important point: The routers that provided by ISPs are usually very cheap and crappy, and this in itself security implications.
Like this example of pulling a script from an unverified HTTP source and executing it as root 🤯… Not to mention that firewalling and port forward configuration options may be pretty simplified and limited.
It’s extremely unlikely that they are going to do any kind of deep traffic inspection in the router/modem itself. Inspecting network traffic is very intensive though and gives very little value since almost all traffic is encrypted/HTTPS today, with all major browsers even showing scare warnings if’s regular unencrypted HTTP. Potentially they could track DNS queries, but you can mitigate this with DNS over TLS or DNS over HTTPS (For best privacy I would recommend Mullvad: https://mullvad.net/en/help/dns-over-https-and-dns-over-tls)
And of course, make sure that anything you are self-hosting is encrypted and using proper HTTPS certificates. I would recommend setting up a reverse proxy like Nginx or Traefik that you expose. Then you can route to different internal services over the same port based on hostname. Also make sure you have a good certificate from Letsencrypt
Imo the biggest problem with Teamspeak is that it still requires an active connection to the server at all time… So unless your computer is on with the app opened 24/7 you may miss messages. That may or may not be an issue, but you may miss messages that your friends send to the group when you aren’t actively online.
Frankly the UI of TeamSpeak is ageing as well, and there is value in for instance being able to simply attach a screenshot directly in a Discord chat without having to upload it to some external service.
I’m like 90% sure that this post is AI Slop, and I just love the irony.
First of all, the writing style reads a lot like AI… but that is not the biggest problem. None of the mitigations mentioned has anything to do with the Huntarr problem. Sure, they have their uses, but the problem with Huntarr was that it was a vibe coded piece of shit. Using immutable references, image signing or checking the Dockerfile would do fuck-all about the problem that the code itself was missing authentication on some important sensitive API Endpoints.
Also, Huntarr does not appear to be a Verified Publisher at all. Did their status get revoked, or was that a hallucination to begin with?
To be fair though the last paragraph does have a point, but for a homelab I don’t think it’s feasible to fully review the source code of everything you install. It would rather come down to being careful with things that are new and doesn’t have an established reputation, which is especially a problem in the era of AI coding. Like the rest of the *arr stack is probably much safer because it’s open source projects that have been around for a long time and had had a lot of eyes on it.
The free version is mainly just a number of user and device limit. Although the relaying service might be limited as well, but that should only matter if both of your clients have strict NAT, otherwise the Wireguard tunnels gets directly connected and no traffic goes through Netbirds managed servers.
You can also self-host the control plane with pretty much no limitations, and I believe you no longer need SSO (which increased the complexity a lot for homelab setups).
At some point I saw images posted on what was supposedly Epsteins server setup, and given the disgusting shit they were up to it’s not even a little surprising he would keep it on hardware he fully controls. So of course there will be some technical documentation in there.
At the same time I’m kind of shocked how much of these emails happens on seemingly regular @gmail.com or @yahoo.com addresses.
You can bind an exposed port to a specific IP by prefixing the IP address like this “-p xxx.xx.x.360:80:80”. Should work in a compose file “ports” list as well.
For outgoing traffic it’s a bit trickier, but if you create a separate network I think it should be possible to inject an iptables SNAT rule to use a specific source IP. Might be handy to make sure you’re sending emails from the correct IP but with your setup I would just make sure to use the primary IP as email egress…