Trying to get this to work with ESXi and /bin/sh

So ESXi does not have /bin/bash, it uses BusyBox, which uses ash, which equates to /bin/sh.

I’m currently using ESXi 6.7 Update 3, which has BusyBox 1.29.3 installed.

Back in the Octopus Deploy days of 2018.x, and maybe 2019.x, we were able to get around the need for bash by creating the /bin/bash file, making it executable, and then adding the below line into the file:

/bin/sh $1

This is not enough anymore. The above will not get around the initial health check that runs, where it runs the following command:

‘/bin/bash --version 2>/dev/null 1>&2 || (echo >&2 “/bin/bash shell missing.” && exit 1); if test “$?” -ne 0; then exit 127; fi;’

So I added some more logic into my /bin/bash to get around this…


if [ “${INCOMING}” == “–version” ]
echo “Version is whatever I want it to be”
exit 0

…and this was enough to then have Octopus SFTP to the machine and drop files into the .octopus folder.

It hung here for ~20mins, until I canceled the health check.

Looking at both the files that got copied over, and, these files look to be identical. Is this correct? Both these files got copied over with permissions set to 644 (rw-r–r--). I set one of them to be executable, and then ran it. It had an error on line 11. An array is being used, and guess what BusyBox doesn’t support, arrays :exploding_head:.

Also, in the commands asking to be checked, there is no base64 command in ESXi. It does have openssl, which can encode and decode base64.

I think I could work my way through this script, correcting everything to make it run on ESXi, but the fact that it was not copied over with proper permissions leads me to believe that something else was to occur which didn’t.

I’ve searched your, and everywhere else I could think of. Not getting anywhere.

Though, from searching, you were able to add support for OpenBSD:
Adding SSH Connection to OpenBSD

I guess at that time there was no bash available for OpenBSD. Which I don’t think is the case today.

Is there a way to get this to work, even by copying files over manually once, so the health check will pass, and the self-contained Calamari can get copied over?

I’m using Jenkins, and was hoping to use the Octopus Plugin so I can push new builds to these ESXi machines, and then kick off my automation. My application is a VIB, so it needs to be installed and uninstalled using the esxcli command. I haven’t got to that point yet with Octopus Deploy 2020.x, but I expect that to still work as it did before over SSH.

If all else fails, I still have an older method which I need to fix, which is the groovy script that was previously written some years ago.

Hi Trey,

I’ll admit up-front I have no experience with ESXi. It’s certainly not an environment we test against (as you can tell). I’ll also be as transparent as possible and say I’m not sure this story will have a good ending.

Octopus depends on bash to support Linux deployment targets. Even if you were successful in “tricking” it, there is no guarantee we wouldn’t inadvertently break this in a future release.

If you all wanted to do was execute scripts, there is an approach we refer to as raw scripts, which allows simply executing scripts, without any of the usual Octopus-sugar included.
And changing the health-check type of the machine policy to connection-only should get you past the health check.

If I understand correctly you want to deploy packages. I’m honestly not sure if this will succeed or not. It’s probably worth a try once you have changed the machine policy as linked to above, but I don’t want to mislead you :slight_smile:

I’d love to hear how you go, and I’m happy to provide whatever further help I can.



I actually found a post on here a few days after I posted this, which pointed me to what are you recommending. I was able to get the ESXi target to past the health check after setting the machine policy.

I’ve yet to get to the deploy steps, but I’ll post what works for me here when I am finished.


1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.