version after build fails

[dkebler]

After building xcaddy attempts to run the new build with version command and fails. There is nothing wrong with permissions of that binary on my system. I I assume fork/exec is some child process starter for Go? Therein lies the permission problem.

/opt/caddy2/amd64 version
2020/05/06 08:23:53 [FATAL] fork/exec /opt/caddy2/amd64: permission denied

BTW my script runs the version command afterwards fine. Is there really any reason that xcaddy needs to do this? My suggestion is to remove it if it's going to be problematic (point of confusion) for some users.

[mholt]

Hi David!

Is there really any reason that xcaddy needs to do this?

Not really, it is just to give you visual confirmation that the right binary was built and works. (When I do cross-platform builds, it also fails, of course, because it is built for another platform.)

I suppose we could be smarter about how/when we do that check, but in any case, it's not actually a failure, or an error that you need to worry about. We could return a different exit code maybe?

[mholt]

Closing due to inactivity. Feel free to continue discussion.

[traumweh]

I'm currently trying to reduce the number of capabilities needed for a kaniko container to automate buildng a customized caddy image using xcaddy (via the oci builder image) and ran into the same issue.

This version confirmation step requires the CAP_NET_BIND_SERVICE capibility (bind to ports < 1024), which isn't needed anywhere else during the build process and isn't restricted to cross-compilation as in #20.

Maybe it'd be possible to add a flag to xcaddy build, like --skip-version-check or something, to skip this step. But in case anyone else stumbles over this: Set --cap-add CAP_NET_BIND_SERVICE on your docker run / podman run.

[mohammed90]

@traumweh, you'll likely benefit from #271. We'll review it once we have a chance.

[traumweh]

@mohammed90 Awesome, that looks indeed like it would solve the issue. c: