Add a way to read PackageConfig config from an appended partition

[twitchyliquid64]

Usecase

As a software vendor of open-source Go software, I would love to be able to provide my software as an easy-to-download gokrazy Raspberry Pi image, with custom configuration (command-line flags, environment) already provided.

Feature request

Heavyweight generation of a customized raspberry pi image (such as via the gokrazy tooling) is a non-starter for something like a package server or CDN. Instead, I was wondering if it would be possible to generate a 'base' image which would be able to read the command-line flags and environment from somewhere at the end of the image, and then the only work for the package server would be yeeting the custom configuration at the end of the byte stream.

I imagine this can be achieved by having a final partition in the image, which is oversized (so we dont need to mess with the MBR/gpt table) and just contains JSON or a zip file or something. It should be trivial to generate this on the fly.

Maybe something like this?

{
    "Hostname": "ye",
    "Packages": [
        "tailscale.com/cmd/tailscaled",
        "tailscale.com/cmd/tailscale",
        "github.com/gokrazy/mkfs"
    ],
    "ExternalPackageConfig": {
        "tailscale.com/cmd/tailscale": "PARTUUID=SSSSSSSS-PP"
    }
}

Thoughts?

[twitchyliquid64]

Would you accept a PR along these lines?

[damdo]

Interesting.
I think this would somehow "morph" the assumption we have around full declarativeness of the gokrazy configuration, rendering for example the SBOM incomplete (as the SBOM generator wouldn't be able to compute at build time the configuration provided externally).

I wonder if it you be possible for your use case to achieve this by wrapping tailscale.com/cmd/tailscale{,d} in a binary that reads the config dynamically from somewhere else (e.g. the disk image)?

Also I know @stapelberg has been tinkering around the idea of a ""gokrazy image generator as a service thing"".
I wonder if this might be a good fit for that, or if at least its design (provided this is still in flux) could be influenced by this use case.

The concept of "layering" though, having a base image and inheriting from that and extending (ala. OCI(Docker) Images), is quite interesting to me in general :)

[twitchyliquid64]

It does mean that some things are no longer 100% static in the gokrazy configuration, but as long as the set of software doesn't change the SBOM shouldnt be incomplete.

The original issue suggests reading environment + args from a different partition, but still statically. The other extreme could be that we support calling some program to compute the args + environment.

[stapelberg]

Hey! Sorry for the late reply.

I have a design document for the gokrazy image daemon here: https://docs.google.com/document/d/1a7TXSxNgdR9pkz2KdZxG_gF01DTkneNwtDxLDXh8tkM/edit?usp=sharing

Here’s the corresponding source: https://github.com/gokrazy/imaged

It’s not that polished yet, but contributions are welcome.

Let me know if you have any questions on imaged — it should be exactly what you’re looking for.

Edit: related discussion: #201

[twitchyliquid64]

Looks good @stapelberg! a few comments:

• We should decide on what filesystem the appended partition is (in imaged it just yeets "hello world"), there are no details of the ABI that mkfs expects. Some thoughts:
  • This filesystem should be easy to generate programmatically, meaning we should use something like tar or stargz rather than something like ext4
  • This also means mutating the extra image data can be as simple as updating the offset in the GPT table and yeeting a tar or whatever
  • We should consider how mkfs detects the additional partition. Maybe just picking a specific partition GUID is good enough?
• The ability to add extra files to /perm is not enough today for binaries that get its configuration from environment variables (i.e. the use-case where we read the Tailscale auth-key from /perm). Maybe we can also add the ability for environment variables to be read from /perm?