Changing user's home supported?

[ldelossa]

Hello.

I have my work setup dependent on my home directories matching my remote servers. A lot of scripting is setup for this.

Inside the lima VM we always create a home directory of /home/user.linux. All my work machines just use the home directory /home/user.

I do the obvious thing, copy /home/user.linux to /home/user and update /etc/passwd and restart the box.

This all seems to work, except now when I shell in I always get this issue:

[systemd]
Failed Units: 1
  cloud-final.service

I tried disabling the systemd service, still see it.
I also removed it from the system all together, but then lima fails to enter the VM again, assumingly because its watching on this service for completion.

I'm not too familiar with cloud-init, but my assumption is it must be updated with the updated home directory name.
Maybe, it would be easiest if Lima allowed the home directory to be defined in the VM template, but a manual workaround is fine as well.

[afbjorklund]

I do the obvious thing, copy /home/user.linux to /home/user and update /etc/passwd and restart the box.

When running Lima on Linux, there is a path conflict between /home/user (host) and /home/user (guest).

It is less obvious when running Lima on a Mac host, since you have /Users/user (host) and /home/user (guest)

Scripts should be using $HOME (or ~), not $USER?

Since their values might differ, like they do here...

[jandubois]

Wouldn't the sanest thing be to allow us to set the HOME dir to some non-default value?

Can't you do this by creating a provisioning script that changes "$HOME"? Or is it important that getent returns the right home directory too when reading /etc/passwd?

provision:
- mode: system
  script: |
    mkdir -p "/home/{{.User}}"
- mode: user
  script: |
    if ! grep "export HOME" "$HOME/.profile"; then
      echo 'export HOME="/home/$USER"' >>"$HOME/.profile"
    fi

[jandubois]

It would be good to have it customizable

I'm not convinced yet this is necessary, and not just an edge case. Before we add a configuration settings, I would like to see a list of use-cases, and verify that they can't already be done with provisioning scripts (and maybe adding some more templating variables).

I think the "plain" mode is separate, and needs to be specced out first as well.

[ldelossa]

@jandubois I'm perfectly cool with this being done post-deploy and via some configuration. The issue with this, is that cloud-init seems to break if you do. If that little snag is cleared up, I think all is well.

[jandubois]

cloud-init had no issue with just updating HOME in ~/.profile as I've shown above (I've rebooted the instance several times). So I don't know if this is good enough for you, or if you need the /etc/passwd entry to match as well.

Another thing to try would be replacing the /home/$USER.linux directory with a symlink (or bind-mount) to /home/$USER and just leaving the HOME variable alone.

[ldelossa]

I will attempt the provision script with the fedora template when I get a chance. I wasn't quite sure if doing the same actions in a provision script made a difference to the cloud init process

ideally, hacks like symlinks and overriding the HOME env wouldn't be necessary. Changes like this tend to rear their head, in annoying and hard to find ways. (Some app breaks because it doesn't agree where HOME is)

[afbjorklund]

You need to look at the journal for the cloud-final.service, and possibly the /var/log/cloud-init-output.log to see what went wrong.

[afbjorklund]

One potential problem is that LIMA_CIDATA_HOME will still use .linux for scripts, even if you have changed HOME in the VM.

[ldelossa]

Yup, not much data in the journalctl output.

Before I upload the cloud-init logs, anything sensitive the output I should be aware of? I'm not uber-secure on my local VM but if anything comes to mind lmk so I can redact it before posting :)

[afbjorklund]

I could not reproduce the error, with the default template (without mounts) and the move of the home directory + reboot

The only thing I saw was that the containerd installation failed to verify OK, since it was using the $LIMA_CIDATA_HOME.

	if [ ! -e "${LIMA_CIDATA_HOME}/.config/systemd/user/containerd.service" ]; then

You forgot to mention which template you are using, like if you are using fedora and not the default (ubuntu)

[afbjorklund]

When using Fedora, you do get an error from the afore-mentioned containerd script - maybe for the reason mentioned.

Oct 08 09:03:09 lima-fedora cloud-init[1081]: Failed to enable unit: Refusing to operate on alias name or linked unit file: dbus.service
Oct 08 09:03:09 lima-fedora cloud-init[1081]: LIMA 2024-10-08T09:03:09+02:00| WARNING: Failed to execute /mnt/lima-cidata/boot/40-install-containerd.sh

Oct 08 09:03:09 lima-fedora systemd[1]: cloud-final.service: Main process exited, code=exited, status=1/FAILURE
Oct 08 09:03:09 lima-fedora systemd[1]: cloud-final.service: Failed with result 'exit-code'.

To be honest I don't know why the symlink is a problem after the rename. But I wouldn't say that it wasn't visible in the logs.

+ sudo -iu anders XDG_RUNTIME_DIR=/run/user/1000 systemctl --user enable --now dbus
Created symlink /home/anders.linux/.config/systemd/user/dbus.service → /usr/lib/systemd/user/dbus-broker.service.

+ sudo -iu anders XDG_RUNTIME_DIR=/run/user/1000 systemctl --user enable --now dbus
Failed to enable unit: Refusing to operate on alias name or linked unit file: dbus.service

[afbjorklund]

Ah, it is always a problem with systemd (running "enable" twice). Just that normally it doesn't. Need to check is-enabled.

[jandubois]

Changing the home directory via lima.yaml has been implemented in #2827.