gencha

joined 1 year ago
[โ€“] gencha@lemm.ee 11 points 6 months ago

Knowing your gender is highly required? ๐Ÿ˜‚

[โ€“] gencha@lemm.ee 3 points 6 months ago

It is your content. But SE specifically only accepts CC licensed content, which makes you right.

[โ€“] gencha@lemm.ee 1 points 6 months ago

I feel like a lot of people don't understand the most basic things about the site. Any user with enough internet points can see deleted posts.

[โ€“] gencha@lemm.ee 4 points 6 months ago

At least he's passionate about Arch. I don't know his life beyond that. I don't need to know.

[โ€“] gencha@lemm.ee 1 points 6 months ago

Definitely. I can just write a log file myself, change the creation date in the filesystem if I have to. There are websites that generate images of DM conversations on a myriad of platforms online. Manipulation of these artifacts is beyond trivial

[โ€“] gencha@lemm.ee 9 points 6 months ago (5 children)

I still find it fascinating that you can go to jail because there's an IP address in a log file somewhere or because of a screenshot of a messenger communication.

[โ€“] gencha@lemm.ee 4 points 6 months ago (2 children)

PathPrefix no longer being regex stood out

[โ€“] gencha@lemm.ee 2 points 6 months ago* (last edited 6 months ago)

Sharing the network space with another container is the way to go IMHO. I use podman and just run the main application in one container, and then another VPN-enabling container in the same pod, which is essentially what you're achieving with with the network_mode: container:foo directive.

Ideally, exposing ports on the host node is not part of your design, so don't have any --port directives at all. Your host should allow routing to the hosted containers and, thus, their exposed ports. If you run your workloads in a dedicated network, like 10.0.1.0/24, then those addresses assigned to your containers need to be addressable. Then you just reach all of their exposed ports directly. Ultimately, you then want to control port exposure through services like firewalld, but that can usually be delayed. Just remember that port forwarding is not a security mechanism, it's a convenience mechanism.

If you want DLNA, forget about running that workload in a "proper" container. For DLNA, you need the ability to open random UDP ports for communication with consuming devices on the LAN. This will always require host networking.

Your DLNA-enabled workloads, like Plex, or Jellyfin, need a host networking container. Your services that require internet privacy, like qBittorrent, need their own, dedicated pod, on a dedicated network, with another container that controls their networking plane to redirect communication to the VPN. Ideally, all your manual configuration then ends up with a directive in the Wireguard config like:

PostUp = ip route add 192.168.1.0/24 via 192.168.19.1 dev eth0

Wireguard will likely, by default, route all traffic through the wg0 device. You just then tell it that the LAN CIDR is reachable through eth0 directly. This enables your communication path to the VPN-secured container after the VPN is up.

[โ€“] gencha@lemm.ee 6 points 7 months ago (3 children)

How exactly are they poisoning a pool of toxic waste?

[โ€“] gencha@lemm.ee 1 points 10 months ago (1 children)

Nobody will maintain any builds, because the restrictions are still ludicrous. Most people in the comments are missing the point entirely.

view more: โ€น prev next โ€บ