Allow providing scripts as separate files

[afbjorklund]

The "path" provided will be read, and used instead of the "script".

provision:
- mode: user
  path: foo.sh

probes:
- mode: readiness
  path: bar.sh

• #2441

---

There are some unsolved issues with this, regarding relative paths.

• https://github.com/lima-vm/lima/issues/893

Currently it requires that limactl is always run from the top directory.

The paths PWD should probably be recorded in the instance directory?

[afbjorklund]

There are some issues with relative paths for the scripts, as has been discussed before...

Note: all the files/paths used here are on the host, and nothing is copied to the instance

[afbjorklund]

The provision scripts are recorded in the cidata.iso, so they should be OK with changing directory.

But the probes are run from the hostagent, so they don't really record the "working directory" now.

EDIT: duh, the lima-hostagent does have a PWD environment variable, so this is a validation problem

If validate should look if the script files exist, then it must also know the current working directory...

[afbjorklund]

As noted in the older issue, this becomes extra interesting if lima.yaml is loaded from an URL.

limactl start https://raw.githubusercontent.com/lima-vm/lima/master/examples/default.yaml

[jandubois]

I think relative filenames should always be relative to the location of lima.yaml itself, and not depend on the cwd of the limactl process.

The proper way to handle local script files then is to copy them during limactl create into a subdirectory of the instance directory, e.g. ~/.lima/debian/scripts/foo.sh (with a mechanism to prevent collisions[^1]).

[^1]: E.g. a second foo.sh would become foo-2.sh etc.

Then lima.yaml is modified with updated relative pathnames:

provision:
- mode: user
  path: scripts/foo.sh

probes:
- mode: readiness
  path: scripts/bar.sh

This makes sure that when the user in the future runs limactl edit and the cidata.iso is re-created, that the instance will continue to use the original scripts used to create the instance, and not a modified version that exists elsewhere on the filesystem. Or fail because the original script files have since been deleted.

For these reasons I think even external scripts referenced by absolute filename (or URL) should be copied into the instance directory and decoupled from the original source.

I don't know how this would work for ansible playbooks, as they can in turn reference additional files, and parsing/rewriting the whole chain seems a bit too complex, but idk what else you can do.

I would still say that we copy the playbook itself, and if that in turn references additional files, then it is up to the user to keep track of them. We can try to display at least a warning when this happens.

I still don't know how external script files would be handled for templates loaded via template:// URL, but whatever the mechanism, they also need to be copied into the scripts/ subdirectory.

[jandubois]

For these reasons I think even external scripts referenced by absolute filename (or URL) should be copied into the instance directory and decoupled from the original source.

This is also a security concern because a hijacked domain could inject a malicious provisioning script into an existing instance.

[afbjorklund]

I think relative filenames should always be relative to the location of lima.yaml itself, and not depend on the cwd of the limactl process.

We can start with this change, and look at copying them from the template folder to the instance folder later.

EDIT: Then again, the LimaYAML does not know which file it originated from - so that path isn't known (either)

[jandubois]

@afbjorklund This functionality is now provided by #3072; I think this PR can be closed.