4 ms·

Edit: More context for the following text: https://utcc.utoronto.ca/~cks/space/blog/programming/GoWhyNotStaticLinked https://utcc.utoronto.ca/~cks/space/blog/p

by weitzj 3y ago

Edit: More context for the following text: https://utcc.utoronto.ca/~cks/space/blog/programming/GoWhyNotStaticLinked https://utcc.utoronto.ca/~cks/space/blog/programming/GoWhyNo... Interesting from a project I currently work on, we use a static compiled binary and I thought just the DNS resolver was a thing which needs to be switched and use the internal DNS resolver of the Go sdk. But as we noted, once you have something like PAM plugins and using ldap sssd to get users from your LDAP, the static Go binary cannot resolve the user IDs. So there is more to it and we have to decide whether we implement a user lookup natively in the Go binary or rely on libc and how the actual Linux system is configured to login users. Also I have not tested this hypothesis, but I assume that with all the troubles I have seen with a Linux vpn client pushing their resolvers into the Linux client and how systemd resolver and other kinds of resolvers mess up your DNS, I wonder if the Go internal DNS resolver implementation picks up on this mess. Anyways for the Go Compiler here this might not be such a big problem.

XorNot 3y ago
DNS is pretty straight forward though, because systemd-resolved runs the stub-resolver. So if your /etc/resolv.conf points to it (as it usually will) then everything will "just work" fine since it's all DNS requests. What we really need is something similar for doing users and groups when you get down to it: which we should have because at the end of the day we're really just asking the system tell us some UIDs and GIDs, or what names to assign to such things.
- arccy 3y ago
  The answer is, of course, more systemd: https://go.dev/issue/38810 https://go.dev/issue/38810
- aragilar 3y ago
  We do, it's nss (which you can configure via nsswitch.conf), which is what the go toolchain is no longer compiling against.
  - XorNot 3y ago
    But it's not an socket API you can talk to generically: NSS wants you to be linked into libc, is my point. The DNS situation you just implement the protocol and you're done.
    - aragilar 3y ago
      Except using a socket involves a different process, so you may get a different result than you expect (given namespaces). I'm not that familiar with plan9 (which is where I think most of the namespacing concepts came from), does it allow direct syscalls, or is linux the only system where you can syscall directly?

by weitzj 3y ago

XorNot 3y ago

DNS is pretty straight forward though, because systemd-resolved runs the stub-resolver. So if your /etc/resolv.conf points to it (as it usually will) then everything will "just work" fine since it's all DNS requests. What we really need is something similar for doing users and groups when you get down to it: which we should have because at the end of the day we're really just asking the system tell us some UIDs and GIDs, or what names to assign to such things.

arccy 3y ago
The answer is, of course, more systemd: https://go.dev/issue/38810 https://go.dev/issue/38810
aragilar 3y ago
We do, it's nss (which you can configure via nsswitch.conf), which is what the go toolchain is no longer compiling against.
- XorNot 3y ago
  But it's not an socket API you can talk to generically: NSS wants you to be linked into libc, is my point. The DNS situation you just implement the protocol and you're done.
  - aragilar 3y ago
    Except using a socket involves a different process, so you may get a different result than you expect (given namespaces). I'm not that familiar with plan9 (which is where I think most of the namespacing concepts came from), does it allow direct syscalls, or is linux the only system where you can syscall directly?