github-personal/incus-os
1
0
Fork 0
mirror of https://github.com/outbackdingo/incus-os.git synced 2026-01-27 10:19:24 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix IncusOS spelling

Browse Source 
Signed-off-by: Stéphane Graber <stgraber@stgraber.org>
This commit is contained in:
Stéphane Graber
2025-11-04 16:06:58 -05:00
parent 0330e816e6
commit b665e2a7e8
17 changed files with 99 additions and 99 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.github/workflows/tests.yml vendored
View File

@@ -122,7 +122,7 @@ jobs:
make generate-test-certs
make
- name: Start Incus OS
- name: Start IncusOS
run: |
qemu-img convert -f raw -O qcow2 $(ls mkosi.output/IncusOS_*.raw | grep -v usr | grep -v esp | sort | tail -1) os-image.qcow2
incus image import --alias incus-os test/metadata.tar.xz os-image.qcow2

22
README.md
View File

@@ -1,14 +1,14 @@
![Daily API tests](https://github.com/lxc/incus-os/actions/workflows/daily.yml/badge.svg)
# Introduction
Incus OS is a minimal immutable OS image dedicated to running [Incus](https://linuxcontainers.org/incus).
IncusOS is a minimal immutable OS image dedicated to running [Incus](https://linuxcontainers.org/incus).
It's based on [Debian](https://www.debian.org) trixie and built using [mkosi](https://github.com/systemd/mkosi).
Incus OS can be installed on modern amd64 (x86_64) and arm64 systems.
IncusOS can be installed on modern amd64 (x86_64) and arm64 systems.
This aims at providing a very fast, safe and reliable way to run an Incus server.
# Security features
Incus OS is designed to run on systems using UEFI with Secure Boot enabled.
IncusOS is designed to run on systems using UEFI with Secure Boot enabled.
On first boot, it will automatically add the relevant Secure Boot keys
(requires the system be in setup mode).
@@ -18,29 +18,29 @@ The image then uses dm-verity to validate every bit that's read from disk.
All throughout boot, artifacts get measured through the TPM with the TPM
state used to manage disk encryption.
This effectively ensures that the system can only boot valid Incus OS
This effectively ensures that the system can only boot valid IncusOS
images, that nothing can be altered on the system and that any
re-configuration of the system requires the use of a recovery key to
access the persistent storage.
When updating, Incus OS uses an A/B update mechanism to reboot onto the
When updating, IncusOS uses an A/B update mechanism to reboot onto the
newer version while keeping the previous version available should a
revert be needed.
# Status
Incus OS is still in early alpha development, which means it comes with some
IncusOS is still in early alpha development, which means it comes with some
important caveats:
* There can and will be breaking changes, which may ultimately require a
fresh reinstall. Therefore, DO NOT use Incus OS with any kind of important
fresh reinstall. Therefore, DO NOT use IncusOS with any kind of important
data.
* Currently all development and testing of Incus OS is done through Incus
VMs. While it should be possible to run Incus OS on physical hardware or
* Currently all development and testing of IncusOS is done through Incus
VMs. While it should be possible to run IncusOS on physical hardware or
other virtualization solutions (ie, Proxmox), support will be limited.
* Incus OS is intentionally opinionated and requires modern hardware to
enable its various security features. Incus OS will never be installable
* IncusOS is intentionally opinionated and requires modern hardware to
enable its various security features. IncusOS will never be installable
on systems without UEFI Secure Boot and a TPM.
# Documentation

12
doc/basic-install-steps.md
View File

@@ -1,6 +1,6 @@
# Basic install steps
This provides a brief, high-level overview of how one might install a stand-alone
Incus OS server, add its Incus as a remote, and retrieve the encryption
IncusOS server, add its Incus as a remote, and retrieve the encryption
recovery key.
## Install configuration
@@ -8,7 +8,7 @@ First, generate an Incus client certificate/key pair if needed:
incus remote generate-certificate
Using the web-based [Incus OS Customizer](https://incusos-customizer.linuxcontainers.org/ui/),
Using the web-based [IncusOS Customizer](https://incusos-customizer.linuxcontainers.org/ui/),
provide your client certificate and download the resulting installation image.
Alternatively, using the [flasher tool](flasher-tool.md), enable the Incus
@@ -37,12 +37,12 @@ preseed:
-----END CERTIFICATE-----
```
Once you have your Incus OS install media, install it on your selected system.
Once you have your IncusOS install media, install it on your selected system.
## Add remote Incus OS
## Add remote IncusOS
After the install completes, you will be shown a list of IP addresses in the
network configuration footer. Pick one and add Incus OS as a remote Incus
network configuration footer. Pick one and add IncusOS as a remote Incus
server:
```
@@ -88,7 +88,7 @@ $ incus list IncusOS:
## Fetching the encryption recovery key
Incus OS will warn you if you haven't retrieved the encryption recovery key.
IncusOS will warn you if you haven't retrieved the encryption recovery key.
You can do so with the following command. Make sure to store the key someplace
safe!

8
doc/flasher-tool.md
View File

@@ -1,6 +1,6 @@
# Flasher tool
The [flasher tool](https://github.com/lxc/incus-os/tree/main/incus-osd/cmd/flasher-tool)
is a user-friendly way to provide install configuration for Incus OS.
is a user-friendly way to provide install configuration for IncusOS.
## Usage
@@ -17,7 +17,7 @@ latest release.
Once downloaded, you will be presented with an interactive menu you can use to
customize the install options.
After writing the image and exiting, you can then install Incus OS from the
After writing the image and exiting, you can then install IncusOS from the
resulting image.
## Environment variables
@@ -25,11 +25,11 @@ resulting image.
Three special environment variables are recognized by the flasher tool, which can be
used to provide defaults:
- `INCUSOS_IMAGE`: Specifies a local Incus OS install image to work with, and will
- `INCUSOS_IMAGE`: Specifies a local IncusOS install image to work with, and will
disable checking the Linux Containers CDN for a newer version.
- `INCUSOS_IMAGE_FORMAT`: When downloading from the Linux Containers CDN, specifies
the Incus OS install image format (`iso` or `img`) to fetch, and will disable
the IncusOS install image format (`iso` or `img`) to fetch, and will disable
prompting the user for this information.
- `INCUSOS_SEED_TAR`: Specifies a user-created [install seed](install-seed.md)

36
doc/index.md
View File

@@ -1,11 +1,11 @@
# Incus OS documentation
Incus OS is still in early alpha development. The instructions below are
# IncusOS
IncusOS is still in early alpha development. The instructions below are
there to help try it out, mostly for testing purposes as new features get
added.
## System Requirements
Incus OS is designed to provide an extremely secure environment in which to
IncusOS is designed to provide an extremely secure environment in which to
run Incus. It requires a lot of modern system features and will not function
properly on older unsupported systems.
@@ -25,27 +25,27 @@ Minimum system requirements:
## Installation
ISO and raw images are distributed via the [Linux Containers {abbr}`CDN (Content Delivery Network)`](https://images.linuxcontainers.org/os/).
There are two more user-friendly methods to get an Incus OS install image: a
There are two more user-friendly methods to get an IncusOS install image: a
web-based customization tool and a command line flasher tool.
Incus OS doesn't feature a traditional installer, and relies on an [install seed](install-seed.md)
IncusOS doesn't feature a traditional installer, and relies on an [install seed](install-seed.md)
to provide configuration details and defaults during install. This install
seed can be manually crafted, or you can use either of the two utilities
described below to automate the process.
After configuring your Incus OS image, you can then boot and Incus OS will
automatically install itself. Upon reboot, Incus OS will automatically start
After configuring your IncusOS image, you can then boot and IncusOS will
automatically install itself. Upon reboot, IncusOS will automatically start
up and will by default check for updates every six hours.
If the raw image is written to a sufficiently large writable medium (at least
50GiB), such as a USB stick or hard drive, without any install seed Incus OS
50GiB), such as a USB stick or hard drive, without any install seed IncusOS
will automatically resize on first boot and start running directly from that
media.
### Incus OS customizer
### IncusOS customizer
The web-based [Incus OS customizer](https://incusos-customizer.linuxcontainers.org/ui/)
is the most user-friendly way to get an Incus OS install image. The web page
The web-based [IncusOS customizer](https://incusos-customizer.linuxcontainers.org/ui/)
is the most user-friendly way to get an IncusOS install image. The web page
will let you make a few simple selections, then directly download an install
image that's ready for immediate use.
@@ -56,8 +56,8 @@ to perform more customizations of the install seed than the web-based customizer
supports. The flasher can be built by running `go build ./cmd/flasher-tool/`.
## Building locally
You can build Incus OS locally. Only users specifically interested in the
development and testing of new Incus OS features should need to do this.
You can build IncusOS locally. Only users specifically interested in the
development and testing of new IncusOS features should need to do this.
Building your own images requires a current version of `mkosi`, and should work
on most Linux distributions, with Debian/Ubuntu being the most well-tested.
@@ -72,7 +72,7 @@ image if you need to boot from a (virtual) CD-ROM device:
make build-iso
## Testing
Currently all development and testing of Incus OS is done through Incus virtual machines.
Currently all development and testing of IncusOS is done through Incus virtual machines.
These instructions assume a functional Incus environment with virtual machine support.
### Local builds
@@ -80,7 +80,7 @@ To test a locally built raw image in an Incus virtual machine, run:
make test
After Incus OS has completed its installation and is running in the virtual machine, to load
After IncusOS has completed its installation and is running in the virtual machine, to load
applications run:
make test-applications
@@ -91,11 +91,11 @@ To test the update process, build a new image and update to it with:
make test-update
### Using official releases
A script is available to test Incus OS using the public releases. It depends on
the flasher tool being available to automate the download of the latest Incus OS
A script is available to test IncusOS using the public releases. It depends on
the flasher tool being available to automate the download of the latest IncusOS
release.
Creating a new Incus OS virtual machine can be done with:
Creating a new IncusOS virtual machine can be done with:
./scripts/spawn-image NAME

18
doc/install-seed.md
View File

@@ -1,6 +1,6 @@
# Install Seed
Incus OS depends on an "install seed" to automate the installation process. Most
users should either use the web-based [Incus OS customizer](https://incusos-customizer.linuxcontainers.org/ui/)
IncusOS depends on an "install seed" to automate the installation process. Most
users should either use the web-based [IncusOS customizer](https://incusos-customizer.linuxcontainers.org/ui/)
or the [flasher tool](flasher-tool.md) which provide a simple way to configure
the install seed without requiring detailed understanding of the technical details
below.
@@ -8,7 +8,7 @@ below.
## Format and location
The install seed is a simple tar archive consisting of one or more JSON or YAML
configuration files. The tar file is written directly to the start of the second
partition of the install image. At runtime, Incus OS will attempt to read the
partition of the install image. At runtime, IncusOS will attempt to read the
install seed from the second partition and use any data present during the
install process.
@@ -26,7 +26,7 @@ install, but we cannot do this with a user-provided seed.)
The following configuration files are currently recognized:
### `install.{json,yml,yaml}`
The presence of this file, even if empty, will trigger Incus OS to start the
The presence of this file, even if empty, will trigger IncusOS to start the
installation process.
The structure is defined in [`api/seed/install.go`](https://github.com/lxc/incus-os/blob/main/incus-osd/api/seed/install.go):
@@ -38,11 +38,11 @@ The structure is defined in [`api/seed/install.go`](https://github.com/lxc/incus
install media.
- `Target`: An optional selector used to determine the install target device.
If not specified, Incus OS will expect a single unused drive to be present
If not specified, IncusOS will expect a single unused drive to be present
during install.
### `applications.{json,yml,yaml}`
This file defines what applications should be installed after Incus OS is up and
This file defines what applications should be installed after IncusOS is up and
running.
The structure is defined in [`api/seed/applications.go`](https://github.com/lxc/incus-os/blob/main/incus-osd/api/seed/applications.go):
@@ -63,8 +63,8 @@ and references Incus' [`InitPreseed` API](https://github.com/lxc/incus/blob/main
install.
### `network.{json,yml,yaml}`
This file defines what network configuration should be applied when Incus OS
boots. If not specified, Incus OS will attempt automatic {abbr}`DHCP (Dynamic Host Configuration Protocol)`/{abbr}`SLAAC (Stateless Address Configuration)`
This file defines what network configuration should be applied when IncusOS
boots. If not specified, IncusOS will attempt automatic {abbr}`DHCP (Dynamic Host Configuration Protocol)`/{abbr}`SLAAC (Stateless Address Configuration)`
configuration on each network interface.
The structure used is the [network API struct](https://github.com/lxc/incus-os/blob/main/incus-osd/api/system_network.go).
@@ -83,6 +83,6 @@ and references Operations Center's [`system` API](https://github.com/FuturFusion
### `provider.{json,yml,yaml}`
This file provides preseed information to configure a given provider, which is used
to fetch Incus OS updates and applications.
to fetch IncusOS updates and applications.
The structure used is the [provider API struct](https://github.com/lxc/incus-os/blob/main/incus-osd/api/system_provider.go).

4
doc/rest-api.md
View File

@@ -1,6 +1,6 @@
# Incus OS API
# IncusOS API
**WARNING** The Incus OS debug API endpoints have no guarantee of API stability, and should not be used
**WARNING** The IncusOS debug API endpoints have no guarantee of API stability, and should not be used
in normal day-to-day operations.
## API

52
doc/secure-boot.md
View File

@@ -1,22 +1,22 @@
# Secure Boot details
This document outlines how Incus OS utilizes Secure Boot. A basic understanding of Secure Boot concepts and how a TPM works is assumed.
This document outlines how IncusOS utilizes Secure Boot. A basic understanding of Secure Boot concepts and how a TPM works is assumed.
## Assumptions
- Prior to installing Incus OS, Secure Boot on the server will be placed into Setup mode.
- If a specific PK or third-party db certificates are required, configuration of the PK/KEK/db certificates must be performed prior to starting the Incus OS install.
- If no PK/KEK/db certificates are present, Incus OS will auto-enroll the Secure Boot certificates as part of the install.
- Post-install Secure Boot will run in User mode. This will allow Incus OS to automatically apply db and dbx updates that have been signed by an Incus OS KEK certificate. If the Incus OS PK key is enrolled, we could also update the KEK keys, although this is expected to be an incredibly rare operation.
- Prior to installing IncusOS, Secure Boot on the server will be placed into Setup mode.
- If a specific PK or third-party db certificates are required, configuration of the PK/KEK/db certificates must be performed prior to starting the IncusOS install.
- If no PK/KEK/db certificates are present, IncusOS will auto-enroll the Secure Boot certificates as part of the install.
- Post-install Secure Boot will run in User mode. This will allow IncusOS to automatically apply db and dbx updates that have been signed by an IncusOS KEK certificate. If the IncusOS PK key is enrolled, we could also update the KEK keys, although this is expected to be an incredibly rare operation.
- Alternatively, if Secure Boot is in Deployed mode, db/dbx/KEK key updates will have to be applied out-of-band by IT staff. This will likely be an unsupported configuration.
- A new Incus OS Secure Boot Key will be created for each year and published well in advance.
- A new IncusOS Secure Boot Key will be created for each year and published well in advance.
- Keys will be valid for 18-24 months (TDB) to allow time for rollover. Secure Boot doesn't actually check expiry of certificates, but there is a simple check in `incus-osd` prior to applying an OS update.
- The first release of Incus OS after January 1st will pickup and use the new year's signing certificate. Some time after that has happened, the prior year's certificate can be invalidated and an update placing that certificate into dbx can be published via API.
- The first release of IncusOS after January 1st will pickup and use the new year's signing certificate. Some time after that has happened, the prior year's certificate can be invalidated and an update placing that certificate into dbx can be published via API.
## Certificate hierarchy
Incus OS relies on a hierarchy of TLS certificate authorities and certificates as shown below. Note that Secure Boot doesn't perform TLS-style validation of the certificates.
IncusOS relies on a hierarchy of TLS certificate authorities and certificates as shown below. Note that Secure Boot doesn't perform TLS-style validation of the certificates.
- Incus OS Root CA should use latest standards (ECDSA, etc)
- Incus OS PK CA and below certificates are limited to RSA 2048 due to the Secure Boot standard
- IncusOS Root CA should use latest standards (ECDSA, etc)
- IncusOS PK CA and below certificates are limited to RSA 2048 due to the Secure Boot standard
```
Incus OS - Secure Boot E1
@@ -34,12 +34,12 @@ Incus OS - Secure Boot 2025 R1 Incus OS - Secure Boot 2026 R1 ......
- PK: OEM/owner-provided or Incus OS Secure Boot PK R1
- KEK: Secure Boot KEK R1
- db: Incus OS signing key(s)
- db: IncusOS signing key(s)
- A new signing key will be generated each year and published in advance
- 6-12 month overlap after January 1st when new signing key is placed into service
- dbx: Old Incus OS signing key(s)
- After sufficient time for key rotation, old Incus OS signing keys will be revoked
- MOK: (not used/supported in Incus OS setup)
- dbx: Old IncusOS signing key(s)
- After sufficient time for key rotation, old IncusOS signing keys will be revoked
- MOK: (not used/supported in IncusOS setup)
### Implementation notes
@@ -47,11 +47,11 @@ Incus OS - Secure Boot 2025 R1 Incus OS - Secure Boot 2026 R1 ......
- Only replacing existing values or appending are supported
- Removal of a specific value requires local access to the KEK or PK private key
- Updates to KEK can be signed offline with an enrolled PK key, and then distributed like db and dbx updates
- If Incus OS PK isn't present, KEK updates will have to be applied out-of-band
- If IncusOS PK isn't present, KEK updates will have to be applied out-of-band
- KEK updates are expected to be extremely rare
- Incus OS will receive db/dbx/KEK updates via the configured Provider in a similar manner to OS and application updates
- An update to Incus OS signed with a key not yet in the db or present in dbx will not be allowed to install, since on reboot the system would refuse to boot the new image
- Updating a trusted signing key and applying an Incus OS update will be two distinct operations, with a reboot in between. This is because updating Secure Boot state and expected TPM PCR values is critical to get right, and it's much simpler logic to only allow one change (a new trusted key or an update with a changed signing key) at a time.
- IncusOS will receive db/dbx/KEK updates via the configured Provider in a similar manner to OS and application updates
- An update to IncusOS signed with a key not yet in the db or present in dbx will not be allowed to install, since on reboot the system would refuse to boot the new image
- Updating a trusted signing key and applying an IncusOS update will be two distinct operations, with a reboot in between. This is because updating Secure Boot state and expected TPM PCR values is critical to get right, and it's much simpler logic to only allow one change (a new trusted key or an update with a changed signing key) at a time.
## Secure Boot key updates
KEK, db, and dbx updates are signed offline and then made available via a Provider's API:
@@ -61,21 +61,21 @@ KEK, db, and dbx updates are signed offline and then made available via a Provid
- This naming convention makes it trivial for a client to quickly retrieve a list of all available keys, identify any missing ones, and then download needed updates
- Update check performed on same cadence as OS update checks (every six hours by default):
- Apply each UEFI variable update one at a time, starting with KEK, then db, then dbx
- Will need to reboot after each update; will automatically reboot if update applied during Incus OS startup, otherwise will require a user triggering a reboot
- Will need to reboot after each update; will automatically reboot if update applied during IncusOS startup, otherwise will require a user triggering a reboot
- Will not apply a dbx update if the current or backup image are signed by it to prevent bricking
### Update availability and integrity
- An attacker could block Incus OS update checks to prevent application of Secure Boot key updates
- Each `.auth` file is signed by a KEK certificate already enrolled on the machine Incus OS is running on. If the file is tampered with, enrollment will fail, so there is no special need to protect or checksum received updates.
- An attacker could block IncusOS update checks to prevent application of Secure Boot key updates
- Each `.auth` file is signed by a KEK certificate already enrolled on the machine IncusOS is running on. If the file is tampered with, enrollment will fail, so there is no special need to protect or checksum received updates.
## Use of TPM PCRs
Incus OS relies on two PCRs (7 & 11) to bind disk encryption keys.
IncusOS relies on two PCRs (7 & 11) to bind disk encryption keys.
### PCR 7
PCR 7 is computed based on the current Secure Boot state and PK/KEK/db/dbx values. The final value of this PCR is calculated by UEFI before the systemd-boot UEFI stub starts. Binding to this PCR allows us to ensure data is only available when Secure Boot is enabled and Incus OS certificates are present. (Prevents an attacker from unlocking the disk on a different machine or launching attacks via live boot media.)
PCR 7 is computed based on the current Secure Boot state and PK/KEK/db/dbx values. The final value of this PCR is calculated by UEFI before the systemd-boot UEFI stub starts. Binding to this PCR allows us to ensure data is only available when Secure Boot is enabled and IncusOS certificates are present. (Prevents an attacker from unlocking the disk on a different machine or launching attacks via live boot media.)
The calculation of PCR 7 is straightforward, and performed whenever a signing key is added or revoked, and when an Incus OS update is signed with a different key than the current running system:
The calculation of PCR 7 is straightforward, and performed whenever a signing key is added or revoked, and when an IncusOS update is signed with a different key than the current running system:
- Fetch TPM event log and verify that the recomputed PCR 7 value matches the current TPM PCR 7 value
- Apply UEFI variable update
@@ -85,12 +85,12 @@ The calculation of PCR 7 is straightforward, and performed whenever a signing ke
### PCR 11
PCR 11 is computed based on the running UKI, and computed at various points during the boot process. Combined with a properly signed UKI image, this allows us to detect any tampering of the UKI and refuse to unlock the encrypted disks. Computation of PCR 11 is complex; systemd has `systemd-measure` which we rely on to create the PCR 11 policy which is combined with the Secure Boot signing key to bind the TPM. The advantage is that this approach is much more flexible than an exact hash binding like we do with PCR 7, and allows the build process to fully predict PCR 11 values and embed those values into the resulting signed UKI images.
Incus OS only ever needs to worry about re-binding PCR 11 when the Secure Boot key used by an UKI is changed, such as the yearly key transition. This is because the PCR 11 policies are bound to the TPM using the current Secure Boot signing key, and if it changes on reboot the TPM state won't match and auto-unlock will fail. The steps taken when installing an Incus OS update with a different Secure Boot key are:
IncusOS only ever needs to worry about re-binding PCR 11 when the Secure Boot key used by an UKI is changed, such as the yearly key transition. This is because the PCR 11 policies are bound to the TPM using the current Secure Boot signing key, and if it changes on reboot the TPM state won't match and auto-unlock will fail. The steps taken when installing an IncusOS update with a different Secure Boot key are:
- Verify the key of the updated UKI is present in the UEFI db variable, and isn't in dbx. This prevents installing an update which will immediately fail to boot with a Secure Boot policy violation.
- Replace the existing systemd-boot UEFI stub with a newly signed one from the pending OS update. `systemd-sysupdate` doesn't typically update the systemd-boot stub, but we need to ensure it's updated to a version signed by the new key.
- Changing the signature on the systemd-boot stub will affect the PCR 7 value at next boot, so follow the steps outlined above to predict the new PCR 7 value.
- Re-bind the TPM PCR 11 policies with the new signing certificate and predicted PCR 7 value. Doing this invalidates the current TPM state, so we must rely on a recovery key known to Incus OS to update the LUKS header. The update is performed in as an atomic process as possible, to prevent having the LUKS header in a state where it doesn't have a TPM enrolled.
- Re-bind the TPM PCR 11 policies with the new signing certificate and predicted PCR 7 value. Doing this invalidates the current TPM state, so we must rely on a recovery key known to IncusOS to update the LUKS header. The update is performed in as an atomic process as possible, to prevent having the LUKS header in a state where it doesn't have a TPM enrolled.
### Implications
Any unexpected change to PCR values will cause auto-unlock to fail, and require the entry of a recovery password to boot the system. When a new Secure Boot key is used, after applying the update and rebooting, attempting to reboot into the backup image will always require the use of the recovery password. Attempting to apply a further OS update while running from the backup image will also very likely fail, since the TPM will be in an unusable state.

18
doc/system-recovery.md
View File

@@ -1,26 +1,26 @@
# Incus OS System Recovery
# IncusOS System Recovery
Incus OS is designed to be fairly resilient to failures, but there may be times when
IncusOS is designed to be fairly resilient to failures, but there may be times when
your system misbehaves. Here are some suggestions that might be useful if you ever
need to recover an Incus OS system.
need to recover an IncusOS system.
## Try booting into the previous image
Incus OS uses an A/B update mechanism to reboot onto the newer version while keeping
IncusOS uses an A/B update mechanism to reboot onto the newer version while keeping
the previous version available should a revert be needed. You can reboot your server
and select the prior version at the boot menu. If that works, it means that something
went wrong with the latest update -- please report a bug!
## Encryption recovery key(s)
Incus OS binds encryption of the install drive to the system's TPM state and stores any
IncusOS binds encryption of the install drive to the system's TPM state and stores any
additional local pool encryption keys on that encrypted drive. You can retrieve an
encryption recovery passphrase for the install drive as well as any local pool encryption
keys via the API. (You did do that and saved those somewhere safe _before_ we ended up here,
right?)
If something unexpectedly changes the TPM state of your system, you can still boot but
will need to manually provide an encryption recovery passphrase. After Incus OS starts
will need to manually provide an encryption recovery passphrase. After IncusOS starts
up, you can use the API to force-reset the TPM encryption bindings which should allow
automatic decryption of the install drive at boot time.
@@ -39,14 +39,14 @@ storage endpoint.
## Recovery mode
A special "recovery mode" can be triggered early in the Incus OS boot sequence if a data partition
labeled `RESCUE_DATA` and formatted as FAT or ISO is present. Incus OS will automatically
A special "recovery mode" can be triggered early in the IncusOS boot sequence if a data partition
labeled `RESCUE_DATA` and formatted as FAT or ISO is present. IncusOS will automatically
attempt to find and run a hot-fix script named `hotfix.sh.sig` at the root of that partition,
followed by any OS or application updates contained in an `update/` directory also at the root
of the recovery partition.
Both the hot-fix script and update metadata JSON file must be properly signed by the same
certificate used to distribute normal Incus OS updates. This prevents an attacker from simply
certificate used to distribute normal IncusOS updates. This prevents an attacker from simply
being able to connect a random USB stick and then running arbitrary commands with full
system access.

6
incus-osd/cmd/image-publisher/main.go
View File

@@ -15,11 +15,11 @@ type cmdGlobal struct {
func main() {
app := &cobra.Command{}
app.Use = "image-publisher"
app.Short = "Maintains an Incus OS update server"
app.Short = "Maintains an IncusOS update server"
app.Long = `Description:
Maintain an Incus OS update server
Maintain an IncusOS update server
This tool handles publishing, promotion and cleanup of Incus OS updates.
This tool handles publishing, promotion and cleanup of IncusOS updates.
`
app.SilenceUsage = true
app.CompletionOptions = cobra.CompletionOptions{DisableDefaultCmd: true}

2
incus-osd/cmd/incus-osd/main.go
View File

@@ -118,7 +118,7 @@ func main() {
}
func run(ctx context.Context, s *state.State, t *tui.TUI) error {
// Verify that the system meets minimum requirements for running Incus OS.
// Verify that the system meets minimum requirements for running IncusOS.
err := install.CheckSystemRequirements(ctx)
if err != nil {
modal := t.AddModal(s.OS.Name)

2
incus-osd/internal/install/install.go
View File

@@ -38,7 +38,7 @@ var cdromMappedDevice = "/dev/mapper/sr0"
var cdromRegex = regexp.MustCompile(`^/dev/sr(\d+)`)
// CheckSystemRequirements verifies that the system meets the minimum requirements for running Incus OS.
// CheckSystemRequirements verifies that the system meets the minimum requirements for running IncusOS.
func CheckSystemRequirements(ctx context.Context) error {
// Check if Secure Boot is enabled.
output, err := subprocess.RunCommandContext(ctx, "bootctl", "status")

2
incus-osd/internal/providers/structs.go
View File

@@ -20,7 +20,7 @@ dzfuFuN/tMIqY355bBYk3m6/UAIK5Pum/Q==
-----END CERTIFICATE-----
`
// Application represents an application to be installed on top of Incus OS.
// Application represents an application to be installed on top of IncusOS.
type Application interface {
Name() string
Version() string

4
incus-osd/internal/services/service_ovn.go
View File

@@ -12,7 +12,7 @@ import (
"github.com/lxc/incus-os/incus-osd/internal/systemd"
)
var ovnSystemdTLS = `# Systemd unit generated by Incus OS
var ovnSystemdTLS = `# Systemd unit generated by IncusOS
[Unit]
Description=Open Virtual Network host control daemon
@@ -21,7 +21,7 @@ ExecStart=/usr/bin/ovn-controller --private-key=/run/ovn/client.key --certificat
Restart=on-failure
`
var ovnSystemd = `# Systemd unit generated by Incus OS
var ovnSystemd = `# Systemd unit generated by IncusOS
[Unit]
Description=Open Virtual Network host control daemon

2
incus-osd/internal/storage/storage.go
View File

@@ -88,7 +88,7 @@ type smartOutput struct {
} `json:"smart_status"`
}
// GetUnderlyingDevice figures out and returns the underlying device that Incus OS is running from.
// GetUnderlyingDevice figures out and returns the underlying device that IncusOS is running from.
func GetUnderlyingDevice() (string, error) {
// We need to find a file that's on a device mapper device and not on overlayfs.
var rootDev string

2
mkosi.images/base/mkosi.extra/usr/lib/systemd/system/incus-osd.service
View File

@@ -1,5 +1,5 @@
[Unit]
Description=Incus OS - management daemon
Description=IncusOS - management daemon
Documentation=https://github.com/lxc/incus-os/
After=systemd-udevd.service
Before=network-pre.target

6
scripts/spawn-image
View File

@@ -22,7 +22,7 @@ INCUSOS_SEED_TAR=test/seed.install.tar INCUSOS_IMAGE_FORMAT=iso incus-osd/flashe
IMG_NAME=$(ls IncusOS_*.iso | grep -v usr | grep -v esp | sort | tail -1)
# Create an instance
echo "=> Creating an Incus OS instance"
echo "=> Creating an IncusOS instance"
incus create --vm --empty "${1}" \
-c security.secureboot=false \
-c limits.cpu=4 \
@@ -31,7 +31,7 @@ incus create --vm --empty "${1}" \
incus config device add "${1}" vtpm tpm
incus config device add "${1}" boot-media disk source="$(pwd)/${IMG_NAME}" boot.priority=10
echo "=> Starting Incus OS for installation"
echo "=> Starting IncusOS for installation"
incus start "${1}" --console
sleep 5
incus console "${1}"
@@ -43,5 +43,5 @@ incus stop -f "${1}"
incus config device remove "${1}" boot-media
# Start the installed system
echo "=> Starting installed Incus OS"
echo "=> Starting installed IncusOS"
incus start "${1}" --console