I think the architecture should be changed from returning 1 complex shell script into 2 simple shell scripts:
curl <installer ip address>/myuser/myrepo
should return a simple script which fetches all of the OS information it can, and then repeats the call (Protocol + Host + path) except the call has extra fields added:
curl <installer ip address>/myuser/myrepo?os=linux&arch=arm64&tools=unzip,tar,gz
now that it has the minimum info (osarchtools) it can now do the checks in Go, and return a simple script which is effectively 1. curl to /tmp, 2. optional unpack, 3. chmod +x, 4. optionally mv to PATH. all the complex shell logic will move into go. second simple shell script does a minimal download and install. errors are just a one-liner echo "my error..."
subsequent improvements:
uses trap to better cleanup and show errors
for private installations, you can set a GH_TOKEN on your server and securely serve private binaries. this second script now knows exactly which file you need, and can get the presigned download URL: https://objects.githubusercontent.com/github-production-release-asset-2e65be/725845012/814abb0e-fc45-4965-be3b-24a0d6df38be?X-Amz-Algorithm=AWS4-HMAC-SHA256.....
this would not be feasible in the previous architecture as it would require installer to get the presigned URLs for all files, and there could be hundreds
second script should also allow the user to provide the asset url directly url=https://github... to installer to skip the asset discovery step (api.github.com calls). this would essentially just do the final GET + unarchive + move into PATH steps.
second script could support optional caching, through a Put / Get interface. which could support caching to disk, to s3, to artifactory, etc. user fetches URL x, and installer checks if x is cached, if not installer quickly downloads and caches it, and returns an installer download link instead of a GitHub content link
caveat:
this may break a small portion of users who go via a dumb proxy. if user goes server-a.com -> installer.internal, and server-a changes the user's request setting Host: installer.internal then the second script would incorrectly have installer.internal when it should have server-a.com
I think the architecture should be changed from returning 1 complex shell script into 2 simple shell scripts:
should return a simple script which fetches all of the OS information it can, and then repeats the call (
Protocol+Host+path) except the call has extra fields added:now that it has the minimum info (
osarchtools) it can now do the checks in Go, and return a simple script which is effectively 1.curlto/tmp, 2. optional unpack, 3.chmod +x, 4. optionallymvtoPATH. all the complex shell logic will move into go. second simple shell script does a minimal download and install. errors are just a one-linerecho "my error..."subsequent improvements:
trapto better cleanup and show errorsGH_TOKENon your server and securely serve private binaries. this second script now knows exactly which file you need, and can get the presigned download URL:https://objects.githubusercontent.com/github-production-release-asset-2e65be/725845012/814abb0e-fc45-4965-be3b-24a0d6df38be?X-Amz-Algorithm=AWS4-HMAC-SHA256.....url=https://github...to installer to skip the asset discovery step (api.github.comcalls). this would essentially just do the final GET + unarchive + move into PATH steps.Put/Getinterface. which could support caching to disk, to s3, to artifactory, etc. user fetches URLx, and installer checks ifxis cached, if not installer quickly downloads and caches it, and returns an installer download link instead of a GitHub content linkcaveat:
server-a.com->installer.internal, andserver-achanges the user's request settingHost: installer.internalthen the second script would incorrectly haveinstaller.internalwhen it should haveserver-a.com