Entering a chroot (with schroot) on a remote machine (high-level)

Get Help
1

If I have added a chroot (using the Debian schroot package to enter it) on a remote machine, and I normally maintain that machine using the ssh connection plugin, and I want to maintain the chroot as well (it can be considered “as if” it was another machine of its own), then… I have a bit of a conundrum, right?

The Ansible chroot connection is for local chroots only (and only using the chroot(8) command, not schroot).

I think my best bet is to run an sshd in the chroot, on a separate port, and handle it as an actual different machine in the inventory, isn’t it?

Otherwise, I see the following options:

  • fork the ssh connection plugin and make the fork to use schroot; obviously no long-term sustainable option

  • write a become (!) plugin to use schroot -u root ipv sudo (and possibly contribute it, so it becomes long-term sustainable); this can then be used with the normal ssh connection plugin, but a lot of care must be taken that the directories like /home, /tmp, etc. are bind-mounted 1:1 into the chroot (and anything where anything-in-Ansible puts its files, temporary or not)

  • create a different remote user on the server whose shell is a shell script calling a shell in the chroot; this has the downside of that Ansible also uses SFTP to transfer files, so the filesystem hierarchy stuff will be an issue

Does anyone have a better idea?

2

There’s also Enrico Zini’s schroot connection plugin, which, again, has the problem that only one connection plugin can be used, so it’s only suitable for local chroots.

3

Another two options:

  1. Run Ansible on the server via Ansible and use the chroot connection plugin, I do this for installing and maintaining chroots on Debian, see this role and this repo for details.
  2. Use chroot /chroot apt-update via the command module, I do this for updates, see these tasks.
4

Hmm. Your 1 is no option, as it would require a lot of extra stuff on the system (plus an Ansible version that supports both the chroot host and the system in the chroot).

Your 2 would likely work for updates, but I’m fairly sure the customer wants to just run the same stuff they use for other systems (VMs) for the chroot.

(Back story, service has to be moved to a chroot due to lack of support for newer OS, but outside VM needs updating, and the services are intermingled and so need to run on the same VM. This is possibly only the first of such.)