If 'truncate' fails for /etc/machine-id during 'commit', attempt with 'sudo' before giving up

[mmguero]

If 'truncate' fails for /etc/machine-id during 'commit', attempt with 'sudo' before giving up.

Addresses #29. Tested locally with virter vm commit as well as virter image build.

Also, fixed a typo in some help messages (s/durign/during/).

[JoelColledge]

Thanks for the contribution!

There are alternatives to sudo that can be used to run a command with different privileges. ec768ad shows that this is a real concern. In that case the command is being run on the host rather than in the guest.

Could we change this so that, instead of doing a new provisioning step when the first truncate fails, we send a script that uses the appropriate tool? The script could use the same logic as ec768ad, just written as a shell script.

[mmguero]

Sure, I'll modify the PR to follow the pattern in the commit you linked.

[mmguero]

How would you feel about this being executed in the provisionshellstep:

		// Starting the VM creates a machine ID.
		// We want these IDs to be unique, so reset to empty.
		err = v.VMExecShell(
			ctx, []string{vmName},
			&ProvisionShellStep{Script: "CMD='truncate -c -s 0 /etc/machine-id'; [ \"$(id -u)\" -eq 0 ] && $CMD || { ESC=$(command -v sudo || command -v doas || command -v please || echo ''); $ESC $CMD; }"})
		if err != nil {
			return err
		}

[JoelColledge]

How would you feel about this being executed in the provisionshellstep:

Neat. I'm happy with that 👍

It breaks on a system where sudo is on a path containing spaces 🙈 I can't imagine anyone actually doing that. That could be fixed by quoting "$ESC", but then the fallback ESC='' doesn't work. The best I ended up with was:

CMD='truncate -c -s 0 /etc/machine-id'; [ "$(id -u)" -eq 0 ] && $CMD || { ESC=$(command -v sudo || command -v doas || command -v please); [ -n "$ESC" ] && "$ESC" $CMD || $CMD; }

But that said, I think your suggestion is better. It is easier to understand and I really don't think anyone has /usr/bin with spaces/sudo on their PATH.

[mmguero]

Sounds good. I've committed an update. I've tested it locally (I will admit only on images that do have sudo available, but I think the logic is sound) by building an image (both with the --user flag set and without it) and then spinning it up and down and checking /etc/machine-id and it seems to be doing what we'd expect.

[mmguero]

@JoelColledge not to be a pest, but what's y'all's release cadence like? I've got some coworkers I want to get this PR to. I could just build the binary for them myself, but if an official release is forthcoming I'll wait so they can just grab it from the official repo here.

[JoelColledge]

We don't have a regular release cadence. We release a new version when there is need. v0.28.0 released.

[mmguero]

Thanks, I appreciate it!