• 0 Posts
  • 12 Comments
Joined 1 year ago
cake
Cake day: July 2nd, 2023

help-circle




  • I’m a big fan of cheap (as in ~$10/yr vps) and reverse proxy over wireguard. My home ip isn’t exposed and I’m able to quickly spin new containers up by updating my reverse proxy config and adding a wireguard peer.

    I keep two VPSs- one as reverse proxy for all my miscellaneous services and another solely for email. The latter port forwards raw traffic over wireguard to my email server container. That way, even if the VPS gets compromised, my personal data remains secure.

    I end up paying ~ $30/yr (+ whatever I’m paying in electricity) for domain + VPS. It’s a bit more involved than tailscale, etc, but I’m willing to put in a little extra work to make sure I’m not at the mercy of some company getting up to some rent-seeking bullshit.


  • The only option that fits your budget today I can think of would be picking up one of the old xeon combos off of AliExpress. I spent like $100 on a MB+CPU+64GB DDR4 combo with a 2880 v4 I think. 14c/28t at any rate. You can probably grab a case/power supply/video card used for under $50 on eBay.

    Please note that I’m not saying that this is a good option; it took a lot of fiddling for me to get mine running smoothly. But if you’ve got more time and patience than money, it might work for you.





  • I second this. I use a couple of dirt cheap VPSs from racknerd ($24/yr for 1 CPU/512Mb ram, but you can find coupons online to get them for $10/yr 1CPU/768mb ram) one does port forwarding over wireguard to my mail server so I can keep all my data in house, the other hosts an NGINX reverse proxy for all my web services. Works great. I use the reverse proxy for nextcloud and jellyfin for myself and 6 other users. Never had an issue. (Well, never had an issue I didn’t cause myself at any rate.)

    It’s a little harder to set up than some of the other suggestions, but it’s cheap, fully transparent to users, and doesn’t expose your home network to the outside world.


  • Nope. It just maps a single user and group from the container to a regular user on the host. With the above config, root in the container has the “real” UID of 100000. It can’t make changes to anything any other unprivileged user can. A privileged container otoh runs root as root. It can do a lot of damage. By running privileged containers you’re kind of throwing out a good portion of LXC’s benefits.


  • The user and group mapping for lxc is easy(ish) once you understand it.

    The above breaks out as follows: lxc.idmap: [user/group] [beginning host UID/GID] [number of sequential IDs to map]

    lxc.idmap: u 0 100000 1000 [maps LXC UIDs 0-999 to host UIDs 100000-100999]

    lxc.idmap: g 0 100000 1000 [maps LXC GIDs 0-999 to host GIDs 100000-100999]

    lxc.idmap: u 1000 1000 1 [maps LXC UID 1000 to host UID 1000]

    lxc.idmap: g 1000 1000 1 [maps LXC GID 1000 to host GID 1000]

    lxc.idmap: u 1001 101001 64535 [maps LXC UIDs 1001-65535 to host UIDs 101001-165535]

    lxc.idmap: g 1001 101001 64535 [maps LXC GIDs 1001-65535 to host GIDs 101001-165535]

    The last two lines are needed because a running Linux system needs access to a minimum of 65336 UIDs/GIDs (zero-indexed).

    You can basically think of LXC as running everything on the host system itself, but running it all as UID/GID 100000-65535 by default. In an unprivileged container, you have to remap these to give access to resources not owned by that range.