The Agama profile should contain a storage section. If it's omitted, an alternative section called legacy_autoyast_storage can be specified instead.
That legacy_autoyast_storage is a 1:1 representation of the XML specification of AutoYaST. No json validation will be performed for it.
| # Class to calculate a storage proposal for autoinstallation | |
| # | |
| # @example Creating a proposal from the current AutoYaST profile | |
| # partitioning = Yast::Profile.current["partitioning"] | |
| # proposal = Y2Storage::AutoinstProposal.new(partitioning: partitioning) | |
| # proposal.proposed? # => false | |
| # proposal.devices # => nil | |
| # proposal.planned_devices # => nil | |
| # | |
| # proposal.propose # Performs the calculation |
<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>..."
}
/>
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.
Let's group them
A. No country, indeed
Agama can be controlled with two interfaces:
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.
This is a draft for a possible OOP solution for https://trello.com/c/drW2FI0q/165-agama-storage-proposal-settings, but certainly not the only one. The chosen solution must be discussed before progressing with the implementation.
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.
class Settings
I'm designing the D-Bus signals for DASD formatting.
They are based on the information provided by a Y2S390::FormatProcess object which provides:
Y2S390::FormatProcess#status exit code of the format process if it finished, nil otherwiseY2S390::FormatProcess#running? ObviousY2S390::FormatProcess#summary Status of all the DASDs requested to formatY2S390::FormatProcess#update_summary Triggers an update of #summary and also updates #updated (see below)Y2S390::FormatProcess#updated Subset of #summary with the entries that were modified by the latest call to #update_summary
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.
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: