Creating an appliance instance while preserving a preinstalled base system

[brainchild0]

I have been using a cloud virtualization service that specializes in simplifying installation and administration of guest systems.

The platform offers prepared images, with various operating systems preinstalled, and also preconfigured for close integration with the infrastructure.

While it is possible to install from boot media, or to launch external pre-built images, it is quite inconvenient on the platform, and largely defeats its advantages. Many manual steps are required, both in managing the infrastructure and in preparing the guest system.

The preferred course for provisioning a guest system is to add the desired additional software and configuration from within the system, following successful boot of the preconfigured base system. Such operations, of course, should preserve the low level configuration that facilities integration with the infrastructure.

Installing software to a live system, after it has booted, may seem to some as contrary to the objectives of Turnkey Linux.

However, appliances offer notable advantages in efficiency, stability, security, safety, and convenience, which are highly appealing, regardless of the process for an appliance instance being created.

As I find no support for such an approach documented in the basic literature, I am seeking an informed discussion of its viability.

[marcos-mendez]

Hi @brainchild0

Good question. As far as I know, TurnKey appliances are built whole: TKLDev assembles the root filesystem from a plan and conf scripts, and the result ships as an ISO or a container/VM image. Turning an already-running base system into an appliance isn't a supported path, which is probably why you found nothing in the docs. You can approximate it by reading an appliance's repository (its plan/ package list and conf.d/ scripts) and applying them by hand to a matching Debian release. But expect friction where the appliance and your provider's image both want control: networking, cloud-init vs. TurnKey's inithooks first boot, SSH and TLS keys, and the confconsole/Webmin layer.

Disclosure: I maintain Keel Linux, a Debian 13 derivative of TurnKey 19, and your use case is one of our design goals: every appliance component is a .deb, and the machine's state is declared in one YAML file that keel spec apply converges, so in principle it can be applied on top of an existing Debian 13. To be clear, that path isn't tested yet on provider images. What works today is keel-transition, which moves an existing TurnKey 19 appliance onto our archive. If you'd like to try the "apply onto a provider image" case, which provider and base image are you on? That's exactly the kind of report we need.

[brainchild0]

Thank you for mentioning the solution you are maintaining.

I would like to consider its suitability for my needs. Indeed, on the surface, it seems quite promising.

Yet, having reviewed the literature, though only briefly, I am left with some doubts regarding its compatibility with my target hosting environment.

Within the target environment, integration with infrastructure is dominantly through system customizations that the hosting provider applies over a more generic installation of a vendor's operating system. It is intended, in turn, that applications be installed over the image that combines the generic operating system with the provider customizations, while not disrupting the customizations.

In contrast, it seems that Keel Linux is designed to be the manager of system resources, such as network addresses. Unless it is able, simply and reliably, to use the addresses that have already have been configured on the host, I cannot readily identify a natural path for integration.

I certainly want to be informed if I have revealed any oversights or misunderstandings.

[brainchild0]

@marcos-mendez: Thank you for your previous response.

I still have not resolved a solution for my deployment, but I have been thinking about Keel Linux, and have many questions.

If it is compatible with preexisting infrastructure for managing network addresses, then it would be worthwhile for me consider seriously. I would happy for some assistance in understanding the relevant design.

[marcos-mendez]

Hi @brainchild0,

Thanks for coming back to this. Your reading is right for our images: on a Keel image, keel can own the network configuration. On an existing system, that part is optional.

• The network section of the spec is optional. If the spec declares no interfaces, keel spec apply plans nothing for networking. It does not touch the addresses, routes or files your provider set up. The other sections (packages, services, users, TLS, firewall and so on) converge on their own.
• You can declare addresses without letting keel write them. With managed_by: host, keel only reads: keel diff compares the declared addresses with the live ones and reports any difference. It never writes. Only managed_by: file makes keel write /etc/network/interfaces.
• keel only writes ifupdown configuration. It does not write netplan, systemd-networkd or cloud-init network configuration. So on a provider image that uses one of those, the only reasonable choice is to leave networking to the provider.

Some limits to be clear about:

• Keel targets Debian 13 (trixie), so the base image must be Debian 13.
• Some appliance components come from TurnKey's first-boot layer (inithooks, confconsole). On a provider image, that layer may compete with cloud-init for first-boot tasks such as SSH keys and passwords.
• We have not tested this path on any provider image yet.

If you can tell me which provider and base image you use, I'd be glad to try it on a matching Debian 13 image and report the results back here.

[brainchild0]

The provider is Linode, and the target application is Nextcloud.

I would be very happy for a solution in the spirit of "turnkey", since I have limited time for customization.

Thank you for your interest.