SinTan1729

joined 8 months ago
[–] SinTan1729@programming.dev 2 points 2 weeks ago (1 children)

Ah that makes sense. To be fair tho, there's a lot of unwarranted hate towards Rust so it can be hard to tell.

[–] SinTan1729@programming.dev 6 points 2 weeks ago* (last edited 2 weeks ago) (3 children)

I hope you're joking. If anything, Rust makes error handling easier by returning them as values using the Result monad. As someone else pointed out, they literally used unwrap in their code, which basically means "panic if this ever returns error". You don't do this unless it's impossible to handle the error inside the program, or if panicking is the behavior you want due to e.g. security reasons.

Even as an absolute amateur, whenever I post any Rust to the public, the first thing I do is get rid of unwrap as much as possible, unless I intentionally want the application to crash. Even then, I use expect instead of unwrap to have some logging. This is definitely the work of some underpaid intern.

Also, Python is sloooowwww.

[–] SinTan1729@programming.dev 1 points 1 month ago

I'm confused. What do you even mean?

[–] SinTan1729@programming.dev 1 points 1 month ago (1 children)

It seems that I'd still need to modify net.ipv4.ip_unprivileged_port_start=80 in sysctl, which I don't want to do. If I do it, the socket isn't even strictly necessary.

[–] SinTan1729@programming.dev 1 points 1 month ago (2 children)

Just a couple of friends use it. But I'd like to use this as a learning opportunity and do it the proper way. It seems that if I turn of masquerade in general, and use firewalld fine-grained rules to enable it when I actually need it, I might be able to achieve what I want. I'll post an update to the original post if I can get it to work.

[–] SinTan1729@programming.dev 1 points 1 month ago

This is interesting. I need to figure out how it works for podman and it'll be the perfect setup.

[–] SinTan1729@programming.dev 1 points 1 month ago

I think it's the masquerade that's causing problems for me. I have to keep it enabled since I'm running a tailscale exit node. But maybe I can selectively disable it here.

[–] SinTan1729@programming.dev 1 points 1 month ago (4 children)

But that just makes most ports unprivileged. That is a solution, but less preferred than my current one.

[–] SinTan1729@programming.dev 2 points 1 month ago (1 children)

I mentioned in the post that it seems to make the client IP opaque to caddy.

 

cross-posted from: https://programming.dev/post/39212874

I recently migrated my services from rootful docker to rootless podman quadlets. It went smoothly, since nothing I use actually needs to be rootful. Well, except for caddy. It needs to be able to attach to privileged ports 80 and 443.

My current way to bypass it is using HAProxy running as root and forwarding connections using proxy protocol. (Tried to use firewalld but that makes the client IP opaque to caddy.) But that adds an extra layer, which means extra latency. It's perfectly usable, but I'd like to get rid of it, if possible.

I'm willing to run caddy in rootful podman if needed. But from what I understand, that means I can't have it in the same rootless network as my other containers. I really don't wanna open most of my containers' ports, so that's not an option.

So, I'm asking whether any of these three things are possible.

  1. Use firewalld to forward ports to caddy without obscuring the client's IP.
  2. Make rootful caddy share a network with other rootless containers.
  3. Assign privileged ports to caddy somehow, in rootless mode. (I know there's a way to make all these ports unprivileged, but is it possible to only assign these 2 ports as unprivileged?)

Or maybe there's a fourth way that I'm missing. I feel like this is a common enough setup, that there must be a way to do it. Any pointers are appreciated, thanks.

 

This release adds the ability to edit existing links, show and download QR codes for easy sharing, and various improvements in the frontend. Check out the release note for a list of all changes.