Implement "data" provision mode

[jandubois]

These are data files copied to the guest filesystem. They are not scripts and are not being executed.

It is pretty similar to the write_files feature in cloud-init, but is completely implemented in our boot.sh, so works automatically with lima-init and other cloud-init alternatives.

provision:
- mode: data
  path: /etc/conf.d/example
  content: |
    VAR=VALUE
  overwrite: false
- mode: data
  path: "{{.Home}}/kubeadm.yaml"
  file: kubeadm.yaml
  owner: "{{.User}}"
  permissions: 0700

The file property works the same way it works for provision scripts and probes (during template embedding the file content is placed into content and the file property is removed, so the data is embedded in the instance directory).

[jandubois]

@nirs This is an evolved variant of the data mode scripts we talked about on Slack a few weeks ago. Instead of providing variables of the data file locations I thought it makes more sense to allow the user to specify the target path where the file should be installed, so you don't need a cp command in a script.

Example:

❯ cat inotify.yaml
base: template://ubuntu-24.04
provision:
- mode: data
  path: /etc/sysctl.d/99-inotify.conf
  file: sysctl.conf

❯ cat sysctl.conf
fs.inotify.max_user_watches = 524288
fs.inotify.max_user_instances = 512

❯ l tmpl copy --embed inotify.yaml -
WARN[0000] `provision[*].file` and `probes[*].file` are experimental
base: template://ubuntu-24.04
provision:
- mode: data
  path: /etc/sysctl.d/99-inotify.conf
  content: |
    fs.inotify.max_user_watches = 524288
    fs.inotify.max_user_instances = 512

[AkihiroSuda]

I don't think these ones have to be mixed in provision:.

Can we just have files: [] in the top-level ?

[jandubois]

The disjoint set of fields has bothered me too. But on the other hand, conceptually this is very similar to provisioning scripts; the main difference being that they are not executed. This

- mode: data
  path: /etc/sysctl.d/99-inotify.conf
  content: |
    fs.inotify.max_user_watches = 524288
    fs.inotify.max_user_instances = 512

is pretty much the same as¹:

- mode: system
  script: |
    cat <<EOF >/etc/sysctl.d/99-inotify.conf
    fs.inotify.max_user_watches = 524288
    fs.inotify.max_user_instances = 512
    EOF

So creating yet another top-level setting for it feels a bit unstructured.

And while not really a strong argument, creating another setting would also require a lot of code duplication for the template merging and file embedding code.

Footnotes

1. The main advantage (with external data files) is that you can create them easily with automation. E.g. you can use a YAML or JSON marshaler to create the file, but there is no default tooling to wrap them as here-documents in a script that writes the document to a file. ↩

[AkihiroSuda]

No strong opinion from me either

[AkihiroSuda]

Shouldn't this be int?

[jandubois]

I had it as an int first, but that makes it hard/impossible to verify that the user specified a leading 0 to make it octal, so you wouldn't get a validation error for permissions: 511¹. The string is always parsed as octal, so it doesn't matter if you specify the leading 0 or not.

I thought this could be a common cause of errors because chmod doesn't require the leading 0 either.

Footnotes

1. I just double-checked, and 511 is the same as 0777, so you can't tell if the user meant 0511 or not. ↩

[jandubois]

I just noticed that I didn't update the comments in default.yaml, which still claim that the leading 0 is required. That is a leftover from when the field was still an int.

[AkihiroSuda]

Can we just use an embedded struct?

type ProvisionData struct{
  Content *string `...`
  // ...
}

type Provision struct {
  Mode ProvisionMode `...`
  // ...
  *ProvisionData
}

[jandubois]

Sure, as long as it is transparent to YAML unmarshaling (I just don't know; will test). I wouldn't want to have an extra settings level for them in lima.yaml.

[jandubois]

This seems to break "strict" YAML mode:

time="2025-03-11T23:03:06-07:00" level=warning msg="Non-strict YAML detected; please check for typos" comment="main file \"lima.yaml\"" error="[1:26] unknown field \"path\"\n>  1 | provision: [{mode: data, path: /tmp, content: hello}]\n                                ^\n   2 | images: [{location: /}]"

It looks like go-yaml has a tag to flatten promoted fields, so I'm going to use that:

	*ProvisionData `yaml:",inline"` // Flatten fields for "strict" YAML mode

Not sure about making the embedded ProvisionData a pointer; it will just require additional checks, and validation already checks each individual field. But I'll try.

[AkihiroSuda]

The format should be clarified in a godoc comment. Does this accept numeric UIDs? Does this accept specifying groups? ("USER:GROUP")

[AkihiroSuda]

Non-absolute paths should be rejected here?

[jandubois]

Sorry, I also rebased the PR, so latest changes are hard to see. What I did:

• Added ProvisionData embedded struct
• Added comment to Owner field
• Add validation check that Path is absolute
• Changed Owner default from root to root:root
• Updated default.yaml with owner and permissions doc changes.

[AkihiroSuda]

Thanks