joseivanlopez/agama-product-registration.md

## agama-product-registration.md

      
    Raw
  

              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