• 5 Posts
  • 15 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 …).






  • A VPN is easy to setup (and I have it setup by the way), but no VPN is even easier. SSH by itself is sufficiently secure if you keep it up to date with a sane configuration. Bots poking at my ssh port is not something that bother me at all, and not part of any attack vector I want to be secure against.

    Out of all the services I expose to the clear web, SSH is probably the one I trust the most.



  • I get what you say, and you’re definitely not wrong to do it. But as I see it, you only saved ~80Kib of ingress and a few lines of logs in the end. From my monitoring I get ~5000 failed auth per day, which account for less than 1Mbps average bandwidth for the day.

    It’s not like it’s consuming my 1Gbps bandwidth or threatening me as I enforce ssh key login. I like to keep things simple, and ssh on port 22 over internet makes it easy to access my boxes from anywhere.


  • z3bra@lemmy.sdf.orgtoSelfhosted@lemmy.worldMy first E-Mail server
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 year ago

    Congratulations! A mail server is quite demanding in terms of initial setup, but it’s also very rewarding !

    Here are a few pointers I can give you:

    • Using a good domain is important, some provider block entire TLDs for cheap domains (eg. .tk or .pw). I learnt it the hard way…
    • Set your MX records to A records, not CNAME
    • Ensure your PTR records match your A records for the mail server
    • Learn about SPF and DKIM
    • Set them up, and verify with mxtoolbox
    • Use the ip4:<ipv4> and/or ip6:<ipv6> selectors for SPF
    • Setup a spamfilter (I like spamassassin)
    • Leave it all running for a few weeks/months
    • Publish a DMARC policy on your DNS, and verify with mxtoolbox

    This should limit a lot your likeliness to end up in spam folders (which is usually the hardest part about running your mail server)



  • ELI5

    So it’s saturday afternoon, a very hot one, so you ask your daddy for an ice cream (hosted service). The shop you go in is very bizarre though, as there is one vendor (TCP port) for each flavor (docker service/virtualhost). But it’s tricky because they’re all roaming in the shop, and you don’t know who’s responsible for each flavor. Your dad is also not very comfortable paying these vendors directly because they only accept cash and do not provide any receipt (self-signed certificate/no TLS).

    Hopefully, there is the manager (reverseproxy) ! This girl is right where you expect her: behind the counter (port 80/443), accept credit cards and has a receipt machine (Domain name + associated certificate). She also knows everyone on her team, and who’s responsible for each flavor !

    So you and your dad come to see the nice lady, ask for a strawberry + chocolate ice cream, and pay her directly. Once done, she forwards your request directly to the vendors responsible for each flavor, and give you back your ice cream + receipt. Life is good, and tasty !