ancorgs

<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>..."
  }
/&gt;

ancorgs

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

ancorgs

Tumbleweed and Leap roles

• kde
• gnome
• xfce
• generic_desktop
• server
• serverro

ancorgs

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.

ancorgs

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.

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.

class Settings

ancorgs

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 otherwise
• Y2S390::FormatProcess#running? Obvious
• Y2S390::FormatProcess#summary Status of all the DASDs requested to format
• Y2S390::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

ancorgs

• Storage proposal tweaks - openSUSE/agama#340
• ALP meeting
  • ALP products
  • Adjust name: ALP ContainerHost
  • No air-gap installer for December
  • Help with Live ISO and USB -> bootable images WG Friday
• Release of D-Installer agreed with Imo
  • Main features: FDE, LVM and aarch64 bootloader fix
  • Opportunity to ask for help with live ISO (and/or alternatives)
• Blog post draft

ancorgs

0. About the term FDE:

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:

ancorgs

The current implementation is the result of acknowledging the default DISA STIG policy:

• Contains rules that should be taken into account during installation since they cannot be easily remedied afterwards (eg. partitioning and encryption).
• Contains rules that could make the system unusable for its original purpose if a full remediation is blindly applied.

The first problem is addressed in both interactive and automated installations by issuing warnings the user must accept in order to finish the installation process. Interactive installation also includes links to the section of the installer where the configuration can be fixed.

ancorgs

The bold question

Is there any vision/plan/strategy on how handle firewall rules in a way that is integrated with the process of installing a package or deploying a containerized workload?

Practical example

• Cockpit is the chosen solution for 1:1 system management.
• Cockpit can only configure firewalld when firewalld is running.
• If you install firewalld in your ALP system and start it with the provided default configuration then it will block connections from other hosts to the Cockpit web interface.