Look at the very least you should write in the blogpost clearly which parts are generated by LLMs, so your readers can decide whether to trust them.
Idk man, it seems pretty irresponsible to me to write a blogpost with stuff that you got from ChatGPT without understanding it. People will assume that if you wrote a blogpost on this then you know what you're doing. ChatGPT gets stuff wrong all the time, and we're talking about firewall configuration here. If it misconfigured some stuff it could leave you and your readers vulnerable to all kinds of shit.
In this case it seems to me that (luckily) there's just a bunch of redundant routing, but the next time it could be leaking your and your readers' torrent traffic out of the VPN tunnel, leaving you vulnerable to legal repercussions for piracy.
Please don't authoritatively post stuff that you got from the automatic bullshit generator without understanding it.
Nice, I recently went through the same struggle of setting up this configuration based on that LinuxServer post. My main nitpick on this is that automating the ip route configuration for the qBittorrent container is a pretty important step which is not explained in the post. Leaving any manual steps in any Docker setup is pretty bad practice.
Since you're using LinuxServer's QBT image a good way to do this is to make use of their standard custom init scripts. You can just mount a script with the ip route commands to /custom-cont-init.d/my-routes.sh:ro on the container and it will be run automatically on each startup.
Another nitpick is that the PostDown commands in the wireguard configs are useless since you're running them in Docker.
Wow thank you, this is the most useful reply I've received so far!
This means I don't need to mess around with QBT's "proxy" settings? I was pretty confused since the only options available are SOCKS/SOCKS5 and HTTP, but I'm guessing that's a different kind of proxy than what I need...
I indeed have a domain name pointing to the VPS IP, with Caddy managing TLS. Other apps are exposed this way, and I will do the same for the qBittorrent WebUI as well. I like having Caddy as a single gateway where I can apply security configs and monitor all traffic, I was hoping I would be able to pass torrent traffic through it as well but everybody seems very much against it.
I already have wireguard setup as you describe so I guess I'll just give up on passing torrent traffic through the proxies and just open a localhost port on the qBittorrent container...
Resetting the "time since last being told I don't know shit on the internet" back to 0 once again...
I already have an existing and working setup used for other apps, it's close to the one described in this blogpost. Yes, it's complicated and inefficient, but it has reasons to be. I want to keep my qBittorrent configuration as close to this setup as reasonably possible for consistency. If your point is that it's counterproductive to follow this setup then... fair enough. I can just route traffic from the VPS to an exposed port on the local qBittorrent container over Wireguard, but that wasn't my preferred solution.
Running a torrent client through a proxy doesn’t isolated a process.
I was talking about network isolation, not process isolation.
make sure your traffic is routing there properly
That was pretty much what I was asking for help with.
I have already set up all of that. My setup is similar to the one in this blogpost and it's already working for various apps that only use HTTP. What I'm trying to do is to also route BitTorrent traffic (TCP/UDP) over the same setup without opening up entirely new paths.
Yes I already have that set up with Wireguard, what I'm figuring out is how to route traffic through it.
I'm guessing what you mean is setting up port forwarding in Wireguard...
The thing is ideally I would want all connections in and out of my homeserver's Docker network to go through the local Caddy proxy, so the app containers are isolated. That still means having at least the local Caddy acting as a TCP proxy, even if the VPS Caddy is bypassed. If that's too much of a hassle though I can instead just expose a port on the qBittorrent container directly to the homeserver's localhost, and forward that with wireguard to the VPS.
By "set up wireguard to route through the VPS" you mean having wireguard forward a port from the VPS to a port on the homeserver at its wireguard IP address?
qBittorrent will still need to publish the right IP address to peers though, right? So I will need to configure the proxy VPS's IP address in qBittorrent...
Also that means binding a port on the qBittorrent container directly to the homeserver localhost. I've managed to keep the app containers isolated so far and it'd be nice to keep that, but if proxying the traffic is too annoying I guess I can just say fuck it and go with it.
Proxying torrent traffic to homeserver
I'm setting up a self-hosted stack with a bunch of services running on a home device. I'm also tunneling all the traffic through a VPS in order to expose the services without exposing my home IP or opening ports on my local network. Currently all my traffic is HTTP, and its path looks like this:
- Caddy proxy on remote VPS (HTTPS, :80 & :443)
- Wireguard tunnel
- Caddy proxy in Docker on homeserver (HTTP, :80)
- app containers in separate isolated subnets, shared with Caddy
I want to set up qBittorrent and other torrent apps, and I want all their traffic to pass through the proxies. Proxying traffic to the WebUI is easy, there's plenty of tutorials; what I'm struggling with is proxying the torrent leeching and seeding traffic, which is the most important part since I live in a country that's not cool with piracy.
Unless I'm misunderstanding, BitTorrent traffic is TCP or UDP, so I'd need Caddy to act as a Layer 4 proxy. There's a community-maintained plugin that should support this. How would I configure it though? Do I need both instances to listen on a new port? Or can I open a new port on the VPS only, and forward traffic to the homeserver Caddy over the same port as the HTTP traffic (:80)? Are there nuances in proxying TCP traffic that I should be aware of?
The thing that pisses me off the most is that they are disingenuous almost to the point of lying in interpreting that survey's results. They say that 75% of users are interested in GenAI, when actually what they asked is whether people have used any GenAI at all in the recent past. And that still doesn't mean they want GenAI in Proton. That's a pretty significant sleight of hand. The more relevant question would have been the first one on what service people want the most. In that case only 29% asked for a writing assistant, which is still not the same thing as a full LLM. The most likely answer to "how many Proton customers want an LLM in Proton Mail" seems to be "few".
This is old drama at this point. I'll repeat what's been said the previous times this was posted.
Proton did what they were legally required to do in the jurisdiction where they operate as a legitimate business. As an encrypted email provider they offer privacy but not necessarily anonymity, and they're open about that. They even have multiple blogposts about how to use their service more anonymously. If you thought that by using ProtonMail you were getting full anonymity that's your mistake.
In both the cases mentioned the users made OpSec mistakes: not using a VPN in one and linking their personal Apple email as a recovery email in the other. In the first case Proton wasn't even logging the user's IP until the police forced them to.
Thank you for the links, I had found a few of these but some are new. The basic idea is there, I'll see if any of these can work for us. I'm growing more convinced though that hosting a whole app for this super simple use case might not be worth it, I think we might pivot to just hosting a really basic static page for it.
This is way too overkill for what we need. I'm sorry, I've been intentionally vague about the context for this but I guess it's too unclear. We're an activist group planning a protest. We might have to get this set up literally tomorrow and every penny comes out of (mostly my) pocket. We're also all paranoid about opsec and anonymity, which is why the requirement about avoiding corporate services is there. Perhaps I should have posted this in a privacy focused comm instead, I apologize.
It's pretty overkill for what we need, and it would still fall under "corporate" for us. At that point I could just go for the static Notion page which I can get live in 5m for free.
We can set up all of those but again, that's kinda expensive for us rn. What's the benefit of using a CMS like Joomla versus wishthis, or even a basic Caddy/Nginx webserver with a static page?
Hosting a public wishlist
I'm involved with an org that needs to set up a public wishlist for supplies for a project. The rough requirements are as follows:
- Public webpage with a static URL
- Can be easily edited by non-technical people
- Editing requires authentication
- Avoiding corporate services, especially avoiding tracking of both users and admins
- As cheap as reasonably possible
- As quick to set up as possible
Nice to have:
- Hosted under a custom domain
- Supports users "reserving" items so multiple people don't all supply the same stuff
One option I considered would be running something like wishthis in a VPS under our own domain, but this is kinda expensive, complex, and I don't trust wishthis' auth. A different option could be just having a static page in something like Notion or Github pages, which would be free but relies on corporate services we don't trust.
Is there a middle ground between the two previous options? Or a better solution that fits most of the requirements?
They're insufferable commies who keep attacking other parts of the Fediverse by... uh... commenting on posts and... ehm... responding aggressively to bigoted content. They've got all these sick ass stickers that we don't and they keep flexing them in our replies which drives me crazy.
Their instance is an authoritarian distopia where queer people feel safe and they don't waste time debating the same wrong liberal talking points every time. Also you can just call someone a dumbass if you disagree with them: a totalitarian nightmare.
Worst of all they go around straight up bullying other Fediverse users: right now I'm locked in a bathroom stall that a Hexbear user shoved me into. I've been here for an hour missing my maths class, and I've had to drink the toilet water. My tummy is starting to hurt. Stay away from Hexbear users...
Nice! Kudos to Proton for not abandoning their promise to publish their sources... Hoping to see Calendar on there soon too.
Instance blocks and Threads
With debate raging in the Fedi about Threads' federation, I was having a discussion with another user about the recently implemented instance blocks. They pointed out that, blocking an instance simply hides their content from your feed but doesn't prevent your posts from being sent to them. Firstly, is this correct? Is this how instance blocks are implemented in Lemmy? If not, has this been discussed before? I couldn't find such a discussion in Github issues...
It seems that many people have concerns about Meta's use of their data, and would like to opt out of sharing their content with Threads. Is there any way to do this in Lemmy right now, or any plan to implement such a feature?
Privacy-preserving solution for managing subscriptions
I'm looking for a way to keep track my recurring subscriptions. I just want a nice overview of recurring payments and where they come from, I don't need a solution to actively go and manage the subscriptions for me. Unfortunately my bank, despite being a trendy digital bank, does not have a good built-in tool for this.
There's a plethora of third party services I found for this (Truebill, TrackMySubs, Hiatus, etc.) but they require you to give them unrestricted access to your bank account activity which seems like a privacy nightmare. I've also found some less invasive apps, such as Subby for Android, but they're basically just nice views over manually entered data. The ones I've found also seem to be single-platform only: even if you can sync your data (not always the case) you can then only view it from the app on the same platform.
Do you have a good solution for this? Something that's a middle ground between giving your entire payment history to some random company and a good-looking local-only spreadsheet?
Defederare istanze neonaziste
Segnalo che tra le istanze federate con feddit.it ce n'è almeno una con contenuti apertamente neonazisti, e francamente rivoltanti.
ATTENZIONE: razzismo, omofobia, e odio in generale
detroitriotcity.com
Apprezzo che la nostra istanza abbia generalmente una policy di federazione rilassata, ma esporsi a contenuti simili è un rischio serio. E penso che la maggior parte di noi sia d'accordo sullo starne lontani.
Intanto, possiamo defederare da quello schifo di posto? E poi, abbiamo un canale stabilito per proposte di defederazione o no? È questa la comunità giusta per farlo?
Opinioni sul bot lemmit.online?
L'istanza lemmit.online è un bot che riposta contenuti da Reddit a Lemmy, con comunità corrispondenti a vari subreddit, popolate automaticamente dal bot con link ai post su reddit. Vorrei capire se qualcuno, qui su feddit.it, segue le comunità di lemmit.online o trova utile questo strumento.
Personalmente io trovo che sia solo spam: i post sono più frequenti di qualsiasi altra istanza, sempre deserti perché nessuno ci interagisce, e sono tutti comunque link a Reddit che preferirei evitare. Purtroppo a Lemmy manca ancora un'opzione per bloccare un'intera istanza, il che vuol dire che devo bloccare le singole comunità quando vedo i loro post nella feed globale. Il che, però, è praticamente come Acchiappa La Talpa, visto che nuove comunità vengono continuamente aggiunte all'istanza su richiesta. Questo sarebbe meno un problema se non fosse che la feed globale al momento è il miglior modo per esplorare Lemmy e scoprire nuove comunità.
Cosa ne pensate?