agama-product-registration.md

Agama And Product Registation

This document analyses different approaches for registering a product and exposes some possible solutions for implementing registration in Agama.

Installation Vs Registration (Chicken-egg Problem)

An installer like Agama (or YaST) needs to know any repository from which to get the packages of the product to install.

SUSE repositories are only known after registering a product, but SUSEConnect CLI (i.e., the official tool for registering) cannot register a product unless it is already installed. So, how is the system actually installed by YaST?

Summarizing a lot: YaST "workarounds" the registration system. YaST is actually registering the system that is running the installer program. Then, YaST manages to install the product packages on the root file system of the target system (chroot). And finally, YaST copies the repositories and everything needed into the target system.

Options For Registering

There are two options: a) registering before installating a system (YaST way) or b) registering after installing the system.

• Register a product before installing it.

  • Problems:
    • SUSEConnect expects to work on a system already installed.
    • The installer has to do quite some work in order to properly install the product on the target file system.
    • If the installation is aborted after the registration, then a ghost system is registed in SCC.
  • Advantages:
    • Updates (e.g., security fixes) and add-ons can be directly installed.
    • Add-ons can be selected at installation time.

• Register a product after installing it.

  • Problems:
    • At least a minimal product repo should be available without registration (by including the repo inside the iso or by providing a public online repo).
    • The minimal repo should be online accesible in order to provide updates (security fixes).
    • Add-ons have to be selected after installing and registering the system (*).
  • Advantages:
    • The system can be directly registered by SUSEConnect, without using any kind of installation magic.
    • SUSEConnect takes cares of adding repos, etc.
    • In case of aborting, no dead system is registered in SCC.
    • Auto-installable images could use the very same approach for registering on first boot.

(*) Note that booting is not required for registering the system. The system could be registered once the installation is done at some path (e.g., /tmp/chroot). SUSEconnect allows to indicate the target root with --root option.

That hypotetical minimal repositories for ALP products do no exist. So, let's assume that Agama is going to implement a similar approach to YaST. That is, the product is registered before installing.

Implementation

We plan to extend the current Software D-Bus service in Agama with a new D-Bus API. That new API would have methods for registering/deregistering a system.

There are three different options to communicate to SCC: a) using SUSEConnect ruby bindings, b) using libsuseconnect.so via FFI to implement rust bindings, c) directly calling to SUSEConnect CLI.

The option b) will not be done yet because the Software service is currently written in ruby. We could opt for that solution if we decide to migrate Software service to rust. Note that creating a separate service for registration probably does not work. Software service holds libzypp lock.

The option c) is also discarded because SUSEConnect CLI cannot register a product unless it is already installed. Note that SUSEConnect always registers the running base product (no way to indicate another product).

So far, SUSEConnect ruby bindings is the best approach that fits our needs. Note that most of the logic we need to implement is already provided by yast2-registration. Nevertheless, yast2-registration supports a lot of use cases that we don't need for Agama, and some parts of its code is coupled to the YaST UI.

Steps for registering

YaST currently does:

# Import certificate (if needed)
# * The certificate is imported into the running system.
# * YaST has to copy it to the target system (e.g., /tmp/chroot) once the system is installed.

SUSE::Connect::YaST.import_certificate(certificate)

# Obtain credentials

login, password = SUSE::Connect::YaST.announce_system(client_params, distro_target)

# Write the global credentials
# * YaST has to copy it to the target system (e.g., /tmp/chroot) once the system is installed.

SUSE::Connect::YaST.create_credentials_file(login, password)

# Register product
# * Repositories are added to the running system by SUSE::Connect (what else is done?).
# * YaST has to copy it to the target system (e.g., /tmp/chroot) once the system is installed.

service = SUSE::Connect::YaST.activate_product(product, client_params, email)

# YaST installs packages on the target file system (e.g., /tmp/chroot)

....

# YaST copies repositories, credentials, certificates (what else?) to the target system.

....

Note that at installation time we don't need to change repositories in the running system. Ideally, we would have a way for calling to #activate_product without doing changes into the system. But somehow it has to return the path of the repositories.

And the same for #deactivate_product. Doing changes in the running system is not needed at installation time.

# Register product (without changes)

service = SUSE::Connect::YaST.activate_product(product, client_params, email)
service.repos #=> ["https://...", ...]

D-Bus API

/org/opensuse/Agama/Software1
    org.opensuse.Agama.Software1
        #AvailableProducts
        #SelectProduct
        #SelectedProduct
        #AvailablePatterns
        #SelectedPatterns
        #AddPattern
        #RemovePattern
        #SetUserPatterns
        #ProvisionsSelected
        #IsPackageInstalled
        #UsedDiskSpace
        #Probe
        #Propose
        #Install
        #Finish

    org.opensuse.Agama1.Registration
        #RegCode (ro)
        #Email (ro)
        #URL (ro)
        #Certificate (ro)
        #State (ro) (0 DISABLED, 1 OPTIONAL, 2 MANDATORY)
        #Register(regcode s, options a{sv}) (options like email, url, certificate)
        #Deregister

Regarding API:

1. I think registration interface should not be under Software but standalone as it is not just about software and e.g. in future installer self update API can be added
2. I thinkg that patterns should not be under Product interface as patterns are not product specific. E.g. in Leap it is shared between Leap, Leap Micro and other possible products.

Regarding API:

1. I think registration interface should not be under Software but standalone as it is not just about software and e.g. in future installer self update API can be added
2. I thinkg that patterns should not be under Product interface as patterns are not product specific. E.g. in Leap it is shared between Leap, Leap Micro and other possible products.

How are patterns shared? Do all those products use a common patterns repo?

Question for open hands:

1. is planned to have fully offline installation even without RMT?
2. is planned to allow customer to modify iso for offline installation?
3. is planned to allow "full" medium that contain repositories, but allow registration for getting updates?
4. is installer self-update still wanted feature?
5. is quaterly update with respin of media planned for ALP or it will be more regular or not at all?

Implementation

To the b) implementation option: that could be possible if we extend the Software service API with methods like AddService, Disable/EnableRepository and similar.

Steps for registering

There is a missing part with extensions/modules:

1. After registering the base product YaST asks for the available modules/extensions SUSE::Connect::YaST.show_product(product, params).extensions (code)
2. User can select which ones to register
3. YaST displays the license (only if the selected extension has one and was not confirmed before)
4. YaST asks for the registration key (only if the selected extension needs one)
5. YaST Registers the extension

I'm not sure if it is still relevant for ALP or not. But unless someone makes that decision I'd suppose there will be some extensions, maybe just for some products.