ent-13848: fix cf-remote info and install commands broken when run via vagrant shell provisioner#176
Conversation
craigcomstock
commented
Apr 3, 2026
craigcomstock
commented
- fix: info and install commands fail when run with a vagrant shell provisioner
- fix: On windows clients the info and install commands will likely fail for having no role key in data
…visioner Due to some environment quirk that I did not completely track down the command "script -qec systeminfo /dev/null" gives a retcode=0 when cf-remote is run via a vagrant shell provisioner. This causes the get_info() function to consider the host a windows box and so loses all of the pertinent system info that could be retrieved. Ticket: ENT-13848 Changelog: title
…l for having no role key in data Sadly, I can't test this because the info command breaks earlier: https://northerntech.atlassian.net/browse/ENT-13849 Ticket: none Changelog: title
| systeminfo = ssh_cmd(connection, "systeminfo") | ||
| if systeminfo: | ||
| if systeminfo and "command not found" not in systeminfo: |
There was a problem hiding this comment.
Looking at this it looks like systeminfo should be None or empty, so the fix doesn't seem like the appropriate one.
There was a problem hiding this comment.
It really is the right one. I am not 100% sure why yet.. but... when run from a vagrant shell provisioner the environment is subtly different so that systeminfo ends up being the stderr which includes "command not found" and retcode = 0.
I did notice that SHLVL=3 in the env inside the shell provisioner so not sure if some options are set that change things... I am happy to add a comment... or dig further and try to find the 100% root cause. :)
| data["agent"] = agent | ||
| version_cmd = powershell("{} -V".format(agent)) | ||
| data["agent_version"] = parse_version(ssh_cmd(connection, version_cmd)) | ||
| data["role"] = "client" |
There was a problem hiding this comment.
I'm thinking role should not always be set, but only if CFEngine is installed, or if it is bootstrapped perhaps.
Looking at ENT-13849 it seems like the issue is that we run sudo bash -c 'bash nt-discovery.sh' on windows or that we don't treat the failure of that correctly.
Seems like we need to either ensure we run the windows command first (systeminfo), and then don't do bash stuff if it's windows. Or we do bash first, and then fall back to windows code if that fails.
There was a problem hiding this comment.
well, the non-windows code path ALWAYS sets role, just depending on the presence of cf-hub. So I suppose that is not correct either. :) We can fix that also.
2 participants
