Allow users to define custom environment variables to be loaded on VM start

[loganprice]

In many corporate environments proxy environment variables HTTPS_PROXY,HTTP_PROXY,NO_PROXY may need to be supplied to allow access to the internet. These changes would allow users too append any additional environment variables they may want at VM start.

[jandubois]

This isn't going to work; the lima.env file is only used during cloud-init; you still need to copy them into a profile script, e.g. /etc/profile.d/lima.sh.

In lima.env the variables should be defined like this (similar to how .Mounts are defined earlier):

LIMA_CIDATA_ENVS=2
LIMA_CIDATA_ENVS_0_NAME=http_proxy
LIMA_CIDATA_ENVS_0_VALUE=my.proxy.com:8080
LIMA_CIDATA_ENVS_1_NAME=https_proxy
LIMA_CIDATA_ENVS_1_VALUE=my.proxy.com:8080

and then in pkg/cidata/boot/25-guestagent-base.sh you need a loop that writes them to /etc/profile.d/lima.sh.

[AkihiroSuda]

/etc/profile.d/lima.sh

Should the path be /etc/environment?

[jandubois]

Should the path be /etc/environment?

I don't think it really matters. The only advantage I see for a profile script is that you can extend PATH:

env:
    PATH="/opt/bin:$PATH"

But you can always do this with a provisioning script as well.

Another thought: /etc/environment is not a POSIX feature but is implemented by PAM. So not sure if that always works. I guess I should try the minimal Alpine image...

[loganprice]

So I was thinking more during the cloud-init phase. In my local testing I added them directly to lima.env and was about resolve the issues I was having during the apt-get update and apt-get install. Anything after that I figured if a user needed them they could add anything they need during the provision stage.

But can add the additional logic so they can get added to the profile.

[jandubois]

So I was thinking more during the cloud-init phase.

Ah yes, thank you! I forgot that these also need to be in effect during cloud-init.

This could be done by sourcing /etc/profile.d/lima.sh in pkg/cidata/boot/30-install-packages.sh.

[jandubois]

But can add the additional logic so they can get added to the profile.

I would prefer this to be a global conf setting and not just for the cloud-init phase.

But wait for @AkihiroSuda to decide on /etc/environment vs. /etc/profile.d/lima.sh

[AkihiroSuda]

Either is fine, as long as we can have CI. The latter seems more friendly to Alpine.

[jandubois]

Yes, alpine-virt ignores /etc/environment because it doesn't use PAM by default.

limactl shell has a hardcoded exec bash --login, so using /etc/profile.d seems appropriate.

[AkihiroSuda]

The env vars here are only used for the init script of Lima.
To apply the env vars globally, /etc/environment need to be updated.

The file path may differ across guest distros, so we should have an integration test. (hack/test-example.sh)

[jandubois]

@loganprice Can you please make sure you sign your commits; we cannot merge PRs unless they pass the DCO check: https://github.com/lima-vm/lima/pull/195/checks?check_run_id=3503216089

Also maybe squash all the "chore" commits with the base commit while you are at it?

Finally, let me know if you prefer that I do the remaining changes that I asked about (setting the variables in /etc/profile.d/lima.sh). In that case we can merge this PR as-is once you have supplied the DCO signature(s).

[jandubois]

@AkihiroSuda I'm fine with merging this PR as-is, as it solves the problem of making proxy settings available during cloud-init processing.

I'll create a separate PR to make the variables available via /etc/profile.d/lima.sh once this PR is merged.

[AkihiroSuda]

@loganprice
Thanks.

Next time please consider cleaning up commit message.

@jandubois

Thanks