One of the really nice side-effects of it running rootless is that you get all the benefits of it running as an actual Unix user.

For instance, you can set up wireguard with IP route to send all traffic from a given UID through the VPN.

Using that, I set up one user as the single user for running all the stuff I want to have VPN'd for outgoing connections, like *arr services, with absolutely no extra work. I don't need to configure a specific container, I don't need to change a docker-compose etc.

In rootful docker, I had to use a specific IP subnet to achieve the same, which was way more clunky.

Yeah sure.

I'm going to assume you're starting from the point of having a second linux user also set up to use rootless podman. That's just following the same steps for setting up rootless podman as any other user, so there shouldn't be too many problems there.

If you have wireguard set up and running already - i.e. with Mullvad VPN or your own VPN to a VPS - you should be able to run ip link to see a wireguard network interface. Mine is called wg. I don't use wg-quick, which means I don't have all my traffic routing through it by default. Instead, I use a systemd unit to bring up the WG interface and set up routing.

I'll also assume the UID you want to forward is 1001, because that's what I'm using. I'll also use enp3s0 as the default network link, because that's what mine is, but if yours is eth0, you should use that. Finally, I'll assume that 192.168.0.0 is your standard network subnet - it's useful to avoid routing local traffic through wireguard.

#YOUR_STATIC_EXTERNAL_IP# should be whatever you get by calling curl ifconfig.me if you have a static IP - again, useful to avoid routing local traffic through wireguard. If you don't have a static IP you can drop this line.

[Unit]
Description=Create wireguard interface
After=network-online.target

[Service]
RemainAfterExit=yes
ExecStart=/usr/bin/bash -c " \
        /usr/sbin/ip link add dev wg type wireguard || true; \
        /usr/bin/wg setconf wg /etc/wireguard/wg.conf || true; \
        /usr/bin/resolvectl dns wg #PREFERRED_DNS#; \
        /usr/sbin/ip -4 address add #WG_IPV4_ADDRESS#/32 dev wg || true; \
        /usr/sbin/ip -6 address add #WG_IPV6_ADDRESS#/128 dev wg || true; \
        /usr/sbin/ip link set mtu 1420 up dev wg || true; \
        /usr/sbin/ip rule add uidrange 1001-1001 table 200 || true; \
        /usr/sbin/ip route add #VPN_ENDPOINT# via #ROUTER_IP# dev enp3s0 table 200 || true; \
        /usr/sbin/ip route add 192.168.0.0/24 via 192.168.0.1 dev enp3s0 table 200 || true; \
        /usr/sbin/ip route add #YOUR_STATIC_EXTERNAL_IP#/32 via #ROUTER_IP# dev enp3s0 table 200 || true; \
        /usr/sbin/ip route add default via #WG_IPV4_ADDRESS# dev wg table 200 || true; \
"

ExecStop=/usr/bin/bash -c " \
        /usr/sbin/ip rule del uidrange 1001-1001 table 200 || true; \
        /usr/sbin/ip route flush table 200 || true; \
        /usr/bin/wg set wg peer '#PEER_PUBLIC_KEY#' remove || true; \
        /usr/sbin/ip link del dev wg || true; \
"

[Install]
WantedBy=multi-user.target

There's a bit to go through here, so I'll take you through why it works. Most of it is just setting up WG to receive/send traffic. The bits that are relevant are:

        /usr/sbin/ip rule add uidrange 1001-1001 table 200 || true; \
        /usr/sbin/ip route add #VPN_ENDPOINT# via #ROUTER_IP# dev enp3s0 table 200 || true; \
        /usr/sbin/ip route add 192.168.0.0/24 via 192.168.0.1 dev enp3s0 table 200 || true; \
        /usr/sbin/ip route add #YOUR_STATIC_EXTERNAL_IP#/32 via #ROUTER_IP# dev enp3s0 table 200 || true; \
        /usr/sbin/ip route add default via #WG_IPV4_ADDRESS# dev wg table 200 || true; \

ip rule add uidrange 1001-1001 table 200 adds a new rule where requests from UID 1001 go through table 200. A table is a subset of ip routing rules that are only relevant to certain traffic.

ip route add #VPN_ENDPOINT# ... ensures that traffic already going through the VPN - i.e. wireguard traffic - does. This is relevant for handshakes.

ip route add 192.168.0.0/24 via 192.168.0.1 ... is just excluding local traffic, as is ip route add #YOUR_STATIC_EXTERNAL_IP

Finally, we add ip route add default via #WG_IPV4_ADDRESS# ... which routes all traffic that didn't match any of the above rules (local traffic, wireguard) to go to the wireguard interface. From there, WG handles all the rest, and passes returning traffic back.

There's going to be some individual tweaking here, but the long and short of it is, UID 1001 will have all their external traffic routed through WG. Any internal traffic between docker containers in a docker-compose should already be handled by podman pods and never reach the routing rules. Any traffic aimed at other services in the network - i.e. sonarr calling sabnzbd or transmission - will happen with a relevant local IP of the machine it's hosted on, and so will also be skipped. Localhost is already handled by existing ip route rules, so you shouldn't have to worry about that either.

Hopefully that helps - sorry if it's a bit confusing. I learned to set up my own IP routing to avoid wg-quick so that I could have greater control over the traffic flow, so this is quite a lot of my learning that I'm attempting to distill into one place.

Yeah, there's an interesting flavour to it hey. One thing I've noticed is that I haven't paid any attention to votes on comments since I joined. It's refreshing to not have the top comment be a meme or joke about a typo. I'm commenting, too, which I very rarely did on Reddit. Perhaps it's less threatening at this stage, while it's new for people, and they're optimistic about it?

Nah, if you're using your instance as an essentially private one, you're not about to be blocked. If you're running communities on it that run counter to the basic ideals of other communities, you'll probably find yourself losing some federation however.

I run my own, and I'm not blocking anything yet because, honestly, I just won't be vising ones I'm not interested in. I'll probably block a few if I see things coming out of them that I really don't want to see, but at this point it doesn't affect anyone else.

I was thinking of running an instance which houses just bots. In theory, that'd make it easy to have an easy to remember URL and usernames, like !bgg@bot.pls or something. If I can get a URL that makes sense I might consider something like this. It'd keep it small enough to call, and make sure they're always 100% intentional.

This is mainly because I don't want to be a source of annoyance for anyone, and I've seen too many people annoyed at the "natural response" bots that pop in all the time on reddit.

If they're on their own instance, a whole instance can block that instance if they don't want bots, or block specific bots if they prefer.

https://mander.xyz/c/mycology

mander.xyz is an instance with a bunch of science based communities, and they have a mycology one.

Electronics. I'm a programmer by profession, but more and more I want to better understand the lowest level parts of things. Ben Eaters' videos have been a huge source on better understanding, but I'm desperately novice with it.

My favourite one is renaming a directory full of files in nnn. It opens in vim, and I'm in my happy place, where I really know how to edit text (or, in this case, filenames). Great when there's some minor variation between a lot of files. Full previewing before saving, multiple operations handled before doing anything etc.

Out of interest, is it better for server load to have new instances federating, or to have users using the instance directly? I assumed that the reliable way of handling this would be to run my own instance and keep it closed for friends I know in real life to use. I don't want to moderate a community, but I also like the reliability (and fun) of self-hosting, and knowing I can just stop using a server if their instance rules change to be against my own principals without losing my user history etc.

How does that mesh with what Lemmy is trying to do? I know I'm going to be in the vast minority here, but I'd like to know if I'm exacerbating load issues.

I'm also on Migadu for email, and I can say the experience has been pretty excellent. They have good instructions for setup stuff, and their pricing model is great. The pricing model has things in common with rsync.net, where they impose a soft limit on storage and reach out if you start exceeding it to talk about upgrading.

I do wonder if other mail providers will at some stage support jmap, it seems like it could take away some frustrations.

It's absurd how much better it makes the vacuums to use. Interaction through the Web UI is just instant, instead of having to bounce to servers halfway around the world before acting on it. It's the primary decider of which vacuum I consider now.

Up and down votes are federated with your username, along with posts and comments (obviously).

Clicking on links, favourites, email address (if you put one in when signing up), password and IP address are all only on your local instance.

Basically, unless another server needs to know about it for federation to work, it's going to be local to the instance you're using.

This is very well written and gets to the core of the issue. The aboriginal people have already spoken - years ago. The Uluru Statement from the Heart is the only piece of documentation anyone should need as to whether the aboriginal people as a representative body want this.

But their internet is down, so it'll fail to send to telegram. Realistically it needs to be an external system that is tracking when it receives pings from the home network, so it can show periods where the bash script didn't ping for a while.

You'll want to start here, but it depends how comfortable you are with self-hosting as to whether it'll be a walk in the park. I had good luck with it, but I self host a lot of stuff and know what kinds of pitfalls there are. The docs aren't totally up to par - I might take a look at contributing to improving them - so you may need to do some searching around if you have problems. There's a Lemmy Support community on lemmy.ml you could check out too.

This would make sense to me - I assume it's the equivalent of a single user seeing basically everything on a given community once, vs loading it from DB (or at least cache) for every request for each new individual user. Every time I load the front page on my server, it's just fetching stuff from my own instance, right?

EDIT: Looks like it does load things from other servers, but only images. Everything else comes from my own instance.

This actually already exists, it's just not in the UI yet. Hiding communities can be done via the API. I was planning on putting in a PR to expose the functionality on the front-end at some stage.

Personally, I've been thinking about bots, but I plan to run them on my own instance or their own dedicated instance. That way, they don't add any load at all with their interactions, and only their comments are synced to other instances. That also makes it easy for whole instances or communities to kick them if they don't want them there.

I don't see one - and also, this is hooked up to an AV in port. I've never seen a TV with 1/8" audio-in.

Nah, I believe it's just that a user that registered with lemmy.ml originally and is then banned in lemmy.ml can't interact with anyone. The instance basically stops supporting that user. That's kinda important, because an instance is in some ways responsible for their users.

If an instance gets a whole lot of brigading from users from a given instance, then they might consider blocking that instance. An instance blocking its own user is taking away their ability to represent that instance on any level.

They can obviously still go registered with another instance.