Copy out mechanism

[davidchisnall]

Is your feature request related to a problem? Please describe.

I want to build a container-like system where some of the container state needs to be initialised from within the container. Specifically, I am working on some pots for GitHub action runners and want to be able to recreate the pot and reimport the output of the one-time setup that registers the runner. My desired workflow is:

1. Create a new pot containing the action runner and register it.
2. Discover I want to update the runner or some of the other things in the jail.
3. Recreate the entire thing from a flavour describing the configuration of the pot and import the configuration.

Describe the feature you'd like to have

I would like a copy-out analogue of copy-in so that I can copy files out of the jail once the initial setup step has been done and reinject them.

Describe potential alternatives or workaround you've considered (if any)

I considered using mount-in, but I can't use environment variables inside the flavour file and I can't pass explicit arguments to flavours and so I can do this only with a single static location. I don't know if mount-in is preserved in the final pot either - it is not documented either way and there is no corresponding unmount-in, so I presume it isn't - this is the behaviour that I'd want, mount-in for a single invocation so that the setup script can run the configuration and copy it to the exported folder.

[bretton]

I'd like to be able to copy-out generated files for ssh keys, ssl certificates, or even backups. this sounds like a useful feature to have.

[pizzamig]

@davidchisnall mount-in is a static configuration parameter, the folder/dataset will be always mounted once the mount-in command is executed.
I guess you have already checked here and the explanation wasn't good enough. I'll rework it to make it clearer.
unmount-in is a missing feature (currently, I just modify the configuration file, but there is "room for improvements" 😅).

In your specific case, the container state needs to be initialised once. While recreating the container, instead of re-initlize it, you want to import the initialized state. Am I correct?

A secure/safe copy-out implementation is complicated, but however possible (probably without globbing, tho)

[davidchisnall]

In your specific case, the container state needs to be initialised once. While recreating the container, instead of re-initlize it, you want to import the initialized state. Am I correct?

Yes, exactly. The scripts are here if you want to look. The config.sh script configures the runner and extracts the config, the recreate-runner.sh script regenerates it.

I am currently just copying the files out of where pot happens to mount the filesystem in my host but I'd prefer to have a flavour that's the exact inverse of the one that imports the config from the host.

[pizzamig]

I've just wrote an implementation of copy-out.
For obvious reason, the source (inside the pot) needs to be an absolute pathname and it cannot support globbing (pot is a shell script!). You can copy out a single file or a directory.
I will run some further tests, but it seems working...

[davidchisnall]

That sounds great. Once that's in the version in packages, I can start using it in our CI system.