You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
<Checkbox
label={_("Use the TPM to decrypt automatically on each boot")}
description={
_(The password will not be needed to boot or to access de data in the <abbr title=\"Trusted Platform Module\">TPM</abbr>..."
}
/>
Timezones known by Agama but not known by zone.tab
The file zone.tab allow us to map timezones to a representative country. Basically, the country in which the city mentioned
in the name of the timezone is located.
Good news - that mapping actually works for 434 of the timezones Agama offers.
Not so good, there are 39 missmatches. So there are timezones for which we cannot inferre the country.
Some fun ideas for using Agama from the installation media
Agama can be controlled with two interfaces:
A CLI (command-line interface) written in Rust
A web interface offering a more graphical and user-frienly way of doing things
Of course, to connect to the latter a browser is needed. Currently Agama-Live (the demo image for Agama) uses
a full screen Firefox. We are not sure if that will be the solution in the definitive installation-media for future
(open)SUSE distributions. It obviously has its drawbacks.
Representing the desired Agama behavior on Agama's storage backend
This shows how the classes at the storage backend of Agama could be organized. These classes may be exposed in the D-Bus interface as some kind of direct translation (having interfaces like Settings, EncryptionSettings, Volume, VolumeTemplate and so on) or with a more conservative interface similar to the current one that is based only on the interface Storage1.Proposal, which contains only a few properties and an array of volumes described as plain hashes.
This classes represent how the configuration of the Agama proposal could be represented in the Agama backend, to be consistent with the behavior described at the Trello card.
Full-Disk Encryption simply means that all the OS components are encrypted, with the unavoidable exception of the bootloader (and of the content of /boot/EFI if we are in a UEFI system). That is, a system is FDE as long as directories like /, /boot, /var, etcetera are stored within LUKS volume(s).
Then there are several approaches to do that and, as a consequence, several possible ways to unlock the volumes during boot.
1. Our current solution for image-based ALP:
Our image is an FDE system in which everything is contained in a LUKS2 volume. During first boot, an interactive wizard runs and, apart from re-encrypting the LUKS2 volume to make it secure, it configures it to be unlocked during subsequent boots using: