Hey John,
I finally had a chance to review the source code that handles this bit, my apologies for the delay.
After looking over the logical flow, I would’ve expected a release package to work using the libsystemd integration in the ziti-edge-tunnel. While libsystemd is needed as a build time dependency of this integration, it is the runtime dependency we are concerned with in this case.
If the binary can dlopen() libsystemd on your system, then the hard-coded path dependencies have no effect, except with regards to inspecting /etc/resolv.conf. After doing a quick test, it seems that realpath("/etc/resolv.conf", ...) should canonicalize through multiple levels of symbolic links. Are you seeing something different or perhaps I’m misunderstanding the problem space?
I saw in the https://openziti.discourse.group/t/static-binary-artifacts-for-ci-releases/790 thread, that you attempted to solve this by using patchelf --add-needed, but I’m wondering if this should’ve been some form of patchelf --add-rpath ...? After some googling, maybe the rpath here should be the same as the -L path which results from running nix-shell -p systemd pkg-config --run 'pkg-config --libs libsystemd'?
What was the error you were seeing after the patches you made in the other post?
With regards to the fallback to the binaries, as written, the easiest path would be to allow them to be overriden at build time. With the code as written, the idea of searching $PATH would have to be carefully implemented. Also, a major hurdle in our case is that we use CMake’s CPack to package the ZET for the other formats, and I couldn’t find a generator for NixOS format.
Thanks,
- Steven
FYI, the error in dlopen() results in the fallback to hard-coded paths, but does not interrupt application startup. In the case that the hardcoded paths cannot be found, it should still fallback to manipulating /etc/resolv.conf directly (though this portion is naive in flawed at this time).