Roles in use in the YaST installer

roles.md

Tumbleweed and Leap roles

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

See details of each role

• Desktop with KDE Plasma
  • Redefines the list of default patterns
• Desktop with GNOME
  • Redefines the list of default patterns
• Desktop with Xfce
  • Redefines the list of default patterns
• Generic Desktop
  • Redefines the list of default patterns
• Server
  • Modifies installer settings: firewall, ssh
  • Redefines the list of default patterns
• Transactional Server
  • Modifies installer settings: firewall, ssh
  • Redefines the list of default patterns
  • Redefines partitioning
    • Mandatory Btrfs with ro root and snapshots,
    • Extra subvolume boot/writable

Summary:

• Roles are mainly used to modify the list of default patterns
• Server roles also enable ssh
• Transactional role also adjust partitioning
  • Mandatory Btrfs with ro root and snapshots
  • Extra subvolume boot/writable

openSUSE MicroOS roles

• micro_os_role
• container_host_role
• micro_os_gnome_desktop_role
• micro_os_kde_desktop_role
• micro_os_role_ra_agent
• micro_os_role_ra_verifier

See details of each role

• MicroOS
  • Additional dialog: inst_microos_role
• MicroOS Container Host
  • Additional dialog: inst_microos_role
  • Redefines the list of default patterns
• MicroOS Desktop (GNOME)
  • Additional dialogs: inst_microos_role, inst_user_first
  • Modifies installer settings: kdump, polkit, readonly_language
  • Redefines the list of default patterns
  • Redefines partitioning: do not propose a separate /var partition
• MicroOS Desktop (KDE Plasma)
  • Additional dialogs: inst_microos_role, inst_user_first
  • Modifies installer settings: kdump, polkit, readonly_language
  • Redefines the list of default patterns
  • Redefines partitioning: do not propose a separate /var partition
• MicroOS with Remote Attestation (Agent)
  • Additional dialog: inst_microos_role
  • Redefines the list of default patterns
• MicroOS with Remote Attestation (Verifier)
  • Additional dialog: inst_microos_role
  • Redefines the list of default patterns

Summary:

• All roles add the inst_microos_role dialog (apparently only used to configure NTP)
• All roles modify the list of default patterns
• Only the desktop roles modify installer settings (kdump, polkit, readonly_language)
• Only the desktop roles modify partitioning
  • Do NOT have a separate /var partition

SUSE Linux Enterprise roles

• basic-desktop
• common-criteria
• gnome
• gnome-x11
• ha
• geo
• hpc-compute
• hpc-server
• kvm
• minimal-desktop
• real-time-text-mode
• sap-business-one
• server-default
• sles4sap → there is a package, but it doesn’t seem to contain role
• text-mode
• transactional-server
• xen

See details of each role

• Gnome Desktop (basic):
  • Redefines the lists of default and optional patterns
• Common Criteria (SLE):
  • Adds a workflow step (asking for encryption password)
  • Modifies installer settings: booting kernel parameters, autologin, firewall, sshd, libzypp config…
  • Redefines the list of default patterns
  • Redefines partitioning
• Gnome Desktop:
  • Redefines the lists of default and optional patterns
• Gnome Desktop (X11):
  • Redefines the lists of default and optional patterns
• HA node
  • Modifies installer settings: firewall, sshd, NTP…
  • Redefines the lists of default and optional patterns
• HA GEO node
  • Modifies installer settings: firewall, sshd, NTP…
  • Redefines the lists of default and optional patterns
• HPC Compute Node
  • Modifies installer settings: autologin, firewall, sshd, kdump, display manager, dhclient, kdump, NTP, libzypp config, os-prober, local users…
  • Redefines the lists of default and optional patterns
  • Redefines partitioning
• HPC Management Server:
  • Modifies installer settings: autologin, firewall, sshd, kdump, display manager, dhclient, kdump, NTP, libzypp config, os-prober…
  • Redefines the lists of default and optional patterns
  • Redefines partitioning
• KVM Virtualization Host
  • Modifies installer settings: autologin, firewall, sshd, kdump, display manager, dhclient, kdump, NTP, libzypp config…
  • Redefines the lists of default and optional patterns
  • Redefines partitioning
• IceWM Desktop (Minimal)
  • Redefines the lists of default and optional patterns
• Real Time (Text Mode)
  • Redefines the lists of default and optional patterns
• SLES for SAP Business One Serve
  • Redefines the list of default patterns
  • Redefines partitioning
• SLES with Gnome
  • Redefines the lists of default and optional patterns
• Text mode:
  • Modifies one installer setting: default-target (multi-user)
  • Redefines the lists of default and optional patterns
• Transactional server:
  • Redefines the list of default patterns
  • Redefines partitioning
• XEN Virtualization Host:
  • Modifies installer settings: autologin, firewall, sshd, dhclient, kdump, NTP, libzypp config…
  • Redefines the lists of default and optional patterns
  • Redefines partitioning

Summary:

• Roles are more heterogeneous than in other cases (used for several unrelated things)
• The set of available roles depend on the activated modules and extensions (each role lives in its own package)
• There is only one role that adds a dialog - common-criteria for asking the encryption password
• There are two roles that add finish clients (common-criteria and sap-business-one)
• Several roles modify installer settings including autologin, firewall, sshd, kdump, display manager, dhclient, kdump, NTP, libzypp config, os-prober and/or local users.
• There are 6 roles that only modify the software selection (basic-desktop, gnome, gnome-x11, minimal-desktop, real-time-text-mode, server-default). Seven if we include text-mode (that also modifies default-target)
• There are 7 roles with impact in partitioning
  • Common criteria
    • Remove /tmp subvol (to configure /tmp as a tmpfs)
    • Many more UNINTENTIONAL changes since definitions has gone out of sync
  • HPC Management Server
    • Remove all pre-existing partitions (SLE default is to delete only what is needed)
    • Bigger root by default (min: 4, desired: 16, max: 32 vs SLE defaults 3, 5, 10).
    • Separate /var/tmp/ partition with unlimited max (instead of /home)
  • HPC Compute Node
    • Same changes than HPC Server
    • Additionally: root is xfs by default
  • KVM Virtualization Host
    • Windows delete mode: all
    • Bigger root by default (min: 5, desired: 10, max: 30 vs SLE defaults 3, 5, 10).
    • Separate /var/lib/libvirt partition with unlimited max (instead of /home)
  • SLES for SAP Business One Server
    • Remove all pre-existing partitions (SLE default is to delete only what is needed)
    • lvm_vg_strategy: :use_needed (instead of default :use_available)
    • Only root and swap (no optional home)
    • Root with mandatory btfs and snapshots but with a max of 80 GiB
  • Transactional Server
    • Mandatory Btrfs with ro root and snapshots
    • Some adjustments in volume sizes
  • XEN Virtualization Host
    • Identical to KVM Virtualization Host

Being transactional is actually a feature, not a role. But that is, in YaST, always controlled by the role/product.

My plan for Agama is to make the feature more visible and configurable in the storage section, just like any other feature related to the disk layout (eg. snapshots). And in the same way that enabling snapshots in the storage section drags the package "snapper" or choosing XFS drags "xfsprogs", enabling a transactional Btrfs would drag the package "transactional-update".

AFAIS, the current roles are used for doing any of the following things:

a) Select packages or patterns to install.
b) Apply some custom config (ssh, polkit, kdump, etc).
c) Configure storage partitioning.
d) Add some custom dialog.
e) Add some custom finish client.

IMHO, Agama products already support a) and c). And b) could be also covered if that configs are moved to some specific package/pattern (e.g., "opensuse-server-config.pkg").

In fact, I see that a), b) and c) are quite related. All of them are about configuring a "product". On the other hand, d) and e) are more about configuring the installer.

Custom dialogs

It seems there are only 2 custom dialogs till now: inst_microos_role for configuring NTP and Common Criteria for entering the encryption password.

I think that NTP could be generally available in Agama. We should not need a role to enable it. And for CC, maybe Agama could have a better way for configuring the security policies. Perhaphs, security policies could be offered as a section in the installer, with its own dialogs, options, etc. And products could be configured to enable and preconfigure security policies.

Custom finish clients

Maybe Agama could have some kind of "before install" and "after install" hooks which allows indicate a script to run in that point of the installation process.

SLES-15:
  software:
    mandatory_packages: "common-criteria"
  after_install: "common-criteria-finish"

I don't see why the openSUSE cases couldn't be resolved just by having pattern selection and making "transactional" a visible (maybe even prominent) setting in the storage section. Or maybe adding the setting there would make too easy for some users to screw things up (eg. by making a system transactional but installing packages that are actually not ready for that scenario).

In TW and Leap, all the kde, gnome, xfce, and generic_desktop roles can be directly translated into patterns. The same happens for server since the SSH and firewall configuration can also be moved to a package if needed. Last, but not least, serverro is likely just like server but with transactional updates. If we turn that "transactional system" into a feature that can be enabled at the storage section, the role can be implemented just by selecting the server software patterns and a transactional storage layout. For the same price we would also have transactional desktops (although they will very likely be highly problematic).

The openSUSE MicroOS case is similar. At first glance I would say everything can be solved via packages except the small change in partitioning layout desired for the roles micro_os_gnome_desktop_role and micro_os_gnome_desktop_role. But that's a pretty small change that maybe does not deserve the introduction of a whole new concept like system roles.

That been said, the SLE cases are way more complex. There are more interconnected aspects and maybe something similar to the system roles would be worth it. But we are REALLY far from having clear requisites for an installer for ALP Granite or ALP Slate.

There is another important aspect of system roles that I forgot to mention. Tumbleweed and openSUSE MicroOS share the same repositories, but they offer different roles because roles are defined in the control file of each product. So we have one set of repositories but two different products with their own sets of roles.