Add Immich installer

antman commented

2026-08-12 06:19:51 +00:00

Owner

Motivation

We want to be able to specify applications for the server to install. The first application we're going to implement automatic installation for is Immich.

Ideally, we would have some external repository of installers. This way the server manager is not limited to only installing applications that were known at compile time. However, installing and configuring applications is an open ended problem. And however we solve this problem, it would benefit from being as declarative as possible; data, rather than scripts.

What we know at the moment:

Required: creating files such as .env and populate them with values derived from the ServerConfig
Required: creating systemd service unit definition files
Required: enabling systemd service units
Required: enabling service units as a user, e.g. systemctl --user -M runner@ enable --now podman.socket
Required: adding users, e.g. useradd --create-home runner
Required: configuring user groups, e.g. usermod -aG docker runner
Required: lingering users e.g. loginctl enable-linger runner
Likely: installing from dnf

A template language for populating files may be useful. So far all commands that need to be issued could be issued based on data, e.g. a list of packages to install, service units to enable, users to add and their groups and properties, etc.

One advantage of a declarative (data) approach is it allows the server manager to check if the current configuration matches target configuration. If an imperative script is partially executed, it may not be safely re executed. If a declarative data structure is partially applied, then declarations that match current state (the partially applied portion) can be ignored by the program and execution can continue from the unapplied portion of the target declaration. A declarative approach also facilitates drift detection and self healing

Solution

What I have learnt building an implementation for the above spec:

Declarative config via data in the manifest file has worked well in translation layer, but when that data is transformed into runtime implementation in code, it easily turns into a clumsy imperative implementation. Each piece of data in the application manifest needs to be transformed into runtime Resource entities that are stored in a ResourceTree. For example, resource types could include FileResource, FirewallResource, ServiceResource, etc.
Once we have a resource implementation, saving the state of these resources to disk becomes simpler
The simulation tests are incredibly slow, but they're also incredibly effective. We will need to parallelize these, as well as finding ways to improve execution speed. Might be worth getting the green server set up as a runner after all.

Currently the implementation doesn't open the firewall, it doesn't configure DNS (which is a big issue to figure out later), and it doesn't configure caddy. However, I think merging this code and then refactoring to the resource based implementation will be a better use of time

### Motivation We want to be able to specify applications for the server to install. The first application we're going to implement automatic installation for is Immich. Ideally, we would have some external repository of installers. This way the server manager is not limited to only installing applications that were known at compile time. However, installing and configuring applications is an open ended problem. And however we solve this problem, it would benefit from being as declarative as possible; data, rather than scripts. What we know at the moment: * Required: creating files such as `.env` and populate them with values derived from the ServerConfig * Required: creating systemd service unit definition files * Required: enabling systemd service units * Required: enabling service units as a user, e.g. `systemctl --user -M runner@ enable --now podman.socket` * Required: adding users, e.g. `useradd --create-home runner` * Required: configuring user groups, e.g. `usermod -aG docker runner` * Required: lingering users e.g. `loginctl enable-linger runner` * Likely: installing from `dnf` A template language for populating files may be useful. So far all commands that need to be issued could be issued based on data, e.g. a list of packages to install, service units to enable, users to add and their groups and properties, etc. One advantage of a declarative (data) approach is it allows the server manager to check if the current configuration matches target configuration. If an imperative script is partially executed, it may not be safely re executed. If a declarative data structure is partially applied, then declarations that match current state (the partially applied portion) can be ignored by the program and execution can continue from the unapplied portion of the target declaration. A declarative approach also facilitates drift detection and self healing ### Solution What I have learnt building an implementation for the above spec: * Declarative config via data in the manifest file has worked well in translation layer, but when that data is transformed into runtime implementation in code, it easily turns into a clumsy imperative implementation. Each piece of data in the application manifest needs to be transformed into runtime Resource entities that are stored in a ResourceTree. For example, resource types could include FileResource, FirewallResource, ServiceResource, etc. * Once we have a resource implementation, saving the state of these resources to disk becomes simpler * The simulation tests are incredibly slow, but they're also incredibly effective. We will need to parallelize these, as well as finding ways to improve execution speed. Might be worth getting the green server set up as a runner after all. Currently the implementation doesn't open the firewall, it doesn't configure DNS (which is a big issue to figure out later), and it doesn't configure caddy. However, I think merging this code and then refactoring to the resource based implementation will be a better use of time

antman added 1 commit

2026-08-12 06:19:51 +00:00