Generate separate cloud-config.yaml for when not using cidata.iso

[afbjorklund]

Description

When looking at alternative implementations, such as Raspberry Pi or cloud instances, it could be useful to look at the generated basic cloud-init / cloud-config information. Without having it embedded as user-data, in the cidata.iso

Maybe we could also just create a stand-alone yaml file, like was done for the ignition yaml file. It doesn't include the boot scripts or the lima-guestagent/nerdctl-full, but does include basic stuff like the user and keys and so on (same args).

template: pkg/cidata/cidata.TEMPLATE.d/user-data

Especially when not generating a cidata.iso anymore

---

example (outdated) background reasoning https://blog.hypriot.com/post/cloud-init-cloud-on-hypriot-x64/

• #2109

• #2139

Lima wouldn't actually do anything with the file, it is just provided for the user to create their instance

[afbjorklund]

Something like

#cloud-config
# vim:syntax=yaml

growpart:
  mode: auto
  devices: ['/']

{{- if .UpgradePackages }}
package_update: true
package_upgrade: true
package_reboot_if_required: true
{{- end }}

{{- if .TimeZone }}
timezone: {{.TimeZone}}
{{- end }}

users:
  - name: "{{.User}}"
    uid: "{{.UID}}"
    homedir: "{{.Home}}"
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL
    lock_passwd: true
    ssh-authorized-keys:
    {{- range $val := .SSHPubKeys }}
      - {{ printf "%q" $val }}
    {{- end }}

[jandubois]

Why not just include user-data under a different name then? You can just ignore the data you don't need.

[afbjorklund]

Why not just include user-data under a different name then?

I think that is what I was trying to say 😀 Or it could be user-data

i.e. talking about the file name in the lima instance directory here

EDIT: will hack together some draft, maybe easier to reason about

• #2271

[jandubois]

i.e. talking about the file name in the lima instance directory here

Oh, I missed that this would be on the host and not inside the VM. In that case we do need to worry about including keys, or make sure we use 600 permissions for the file.

[afbjorklund]

In that case we do need to worry about including keys, or make sure we use 600 permissions for the file.

Something that would probably also apply to the cidata.iso file in that case, and could be done already now?

But since it is only the public keys, I don't think that is necessary... The password (from blog above) is outdated*

The original images (on https://blog.hypriot.com/) had:

users:
  - name: pirate
    gecos: "Hypriot Pirate"
    sudo: ALL=(ALL) NOPASSWD:ALL
    shell: /bin/bash
    groups: users,docker,video
    plain_text_passwd: hypriot
    lock_passwd: false
    ssh_pwauth: true
    chpasswd: { expire: false }

---

* the Raspberry Pi OS images no longer ship with a default user, but add one during first boot instead

• https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/

[afbjorklund]

https://www.digitalocean.com/community/tutorials/how-to-use-cloud-config-for-your-initial-server-setup

[jandubois]

But since it is only the public keys, I don't think that is necessary...

Yes, you are right; I was confused.

[afbjorklund]

Note: the new file is generated when the instance is created, since it is needed before it can be started

[jandubois]

Note: the new file is generated when the instance is created, since it is needed before it can be started

Shouldn't it be created every time before the instance is started, in case lima.yaml has changed?

I guess this becomes a chicken-and-egg problem now, as you would still need access to the updated file before starting the instance.

Something like limactl start INSTANCE --not-really-just-update-the-config --set …, but less awkward. 😄

[afbjorklund]

I added code to the hostagent, to (re)create the cloud-config.yaml file at the same time as the cidata.iso

[afbjorklund]

Note that as a side-effect, this will also generate the private/public ssh key in $LIMA_HOME/_config/user{,.pub}