• 11 Posts
  • 164 Comments
Joined 1 year ago
cake
Cake day: June 19th, 2023

help-circle
  • Right now overlays requires elevated privilèges, but ideally it shouldn’t. Rewriting the Linux kernel to implement per user namespaces like plan9 does would allow unprivileged actions from any user (just like if any user was sitting in a container, overlayed from the base system).

    I know we’re not there, and that’s not the direction development is going, but this thread is about dreams, right ? 😉

    About the XDG specs, they serve a totally different purpose so they’re out of the discussion IMO. I’m not advocating against env variables. Just $PATH which is a workaround as I see it, but your mileage may vary. As for your “issue” with steam, of course this is the best way to solve it. Because of today’s OS limitation. My point is that with a better designed namespacing implementation, there would be more elegant solutions to solve it (and would get rid of the need to use LD_LIBRARY_PATH too, or literally any *_PATH env variable)





  • You missed my point. The reason $PATH exists in the first place is because binaries were too large to fit on a single disk, so they were scattered around multiple partitions (/bin, /sbin, /usr/bin, etc…). Now, all your binaries can easily fit on a single partition (weirdly enough, /usr/bin was chosen as the “best candidate” for it), but we still have all the other locations, symlinked there. It just makes no sense.

    As for the override mechanism you mention, there are much better tools nowadays to do that (overlayfs for example).

    This is what plan9 does for example. There is no need for $PATH because all binaries are in /bin anyways. And to override a binary, you simply “mount” it over the existing one in place.


  • $PATH shouldn’t even be a thing, as today disk space is cheap so there is no need to scatter binaries all over the place.

    Historically, /usr was created so that you could mount a new disk here and have more binaries installed on your system when the disk with /bin was full.

    And there are just so many other stuff like that which doesn’t make sense anymore (/var/tmp comes to mind, /opt, /home which was supposed to be /usr but name was already taken, etc …).









  • Keeping the source IP intact means you’ll have troubles routing back the traffic through host B.

    Basically host A won’t be able to access the internet without going through B, which could not be what you want.

    Here’s how it works:

    On host A:

    • add a /32 route to host B public IP through your local ISP gateway (eg. 192.168.1.1)
    • setup a wireguard tunnel between A and B
    • host A: 172.17.0.1/30
    • host B: 172.17.0.2/30
    • add a default route to host B wireguard IP

    On host B:

    • setup wireguard (same config)
    • add PAT rules to the firewall so to DNAT incoming requests on the ports you need to 172.17.0.1
    • add an SNAT masquerade rule so all outbound request from 172.17.0.1 are NATed with host B public address.

    This should do what you need. However, if I may comment it out, I’d say you should give up on carrying the source IP address down to host A. This setup I described is clunky and can fail in many ways. Also I can see no benefits of doing that besides having “pretty logs” on host A. If you really need good logs, I’d suggest setting up a good reverse proxy on host B and forwarding it’s logs to a collector on host A.


  • OpenBSD is the most pleasing expérience I’ve had with an OS. It’s fully contained and has all the tools you need without needing to install anything (eg a DNS, HTTP, SMTP servers, a proxy, a good firewall). All config files look alike and use the same keywords for the same things, making it straightforward to configure everything.

    And regarding RAID 1, I’ve never done it myself, but it totally works out of the box (as well as full disk encryption).