Has adding statically linked binary artifacts in the CI release builds been considered?
As a NixOS user, the available OpenZiti binary release builds don’t work out of the box because nix uses a filename hashed store for OS binaries and other artifacts to achieve various operational benefits.
To get the OpenZiti tunneler to work, for example, I need to manually patch the release binary from FHS paths to nix hashed store paths, example:
# Example patch required for release binary: # https://github.com/openziti/ziti-tunnel-sdk-c/releases/download/v0.19.11/ziti-edge-tunnel-Linux_x86_64.zip # Due to not found .so in ldd output patchelf --set-interpreter $(nix-build "<nixpkgs>" -A glibc --add-root ~/.cache/gcroots/glibc --indirect --no-out-link)/lib/ld-linux-x86-64.so.2 ./ziti-edge-tunnel # Due to errors in the client tunnel log about not being able to find a dynamically loaded systemd library: patchelf --add-needed $(nix-build "<nixpkgs>" -A systemd --add-root ~/.cache/gcroots/systemd --indirect --no-out-link)/lib/libsystemd.so.0 ./ziti-edge-tunnel
A static build, maybe with musl, and including all libs needed should be more portable and work directly on NixOS also.
As an alternative, we’re looking at doing some NixOS packaging for OpenZiti, but this probably won’t happen for a little while. So I’ll be using patched release builds for now, or running within docker on other OSs as a last option.