Self-Update Uses Cases and Error Handling

self-update-use-cases.md

Self-Update Use Cases and Error Handling

About this document

This document tries to define how self-update should behave in different scenarios. It contains also some information about which changes should be made.

Requeriments

1. Minimize the amount of error messages. In a nutshell, we should report problems only if the user explicitly set an URL for the registration server or the update repository.

2. Try to reduce the impact of timeouts. We should avoid using the fallback URL (defined in the control file) if the registration server is unreachable because most likely it will also fail.

3. Add an option to disable/enable self-update to Linuxrc boot menu (future).

4. Allow to set the default option in the distribution control file. The idea is to set the default value without modifying Linuxrc. allow enabling/disabling (future).

Self-Update steps

Self-Update comprises of three different steps:

1. Get the updates repository URL. When it comes to SLE, it may require contacting a registration server to get such an URL (unless another one is specified by the user).
2. Download and apply updates (if any) from the updates repository.
3. Restart YaST2 if any update was applied.

So when using SLE, it can require contacting two different servers and adding some software to the inst-sys, so a proper error handling is crucial.

NOTE: for openSUSE the first step is slightly simpler as the URL, if not specified by the user, it is read from the control file.

Use cases

Regular installation

With full network access

This is the 'happy' scenario. Network is fully working, registration server is available and updates can be cleanly applied.

1. YaST2 will contact the registration server (scc.suse.com) to get the URL of the self-update repository.
2. The repository will be added.
3. If some update is available, the installer will be updated and restarted.

Error handling: the user will be notified if:

• The registration server is unreachable although the network is configured and the system has an IP address (firewall, no route to host, DNS does not resolve the registration server name, etc.). In that case the self_update_url specified in the control file will be used.
• the server where the update repository lives cannot be reached. Note that no error will be shown if the repository is not found as we just consider that, in such a case, no updates are available.
• the repository is not valid

Proposed changes: do not warn the user and skip the self-update silently in case of the aforementioned errors.

With network but w/o access to registration server

If the network is enabled, YaST2 will try to perform the self-update as seen in the With full network access section. So, as the registration server is unreachable:

1. YaST2 will show an error pop-up regarding the communication with their registration server.
2. The self_update_url in the control file, if any, will be used as a updates repository.
3. If some update is available, the installer will be updated and restarted.

Error handling: same error handling than the With full network access. So the user will get three errors: one for the registration server timeout, a warning about not being able to determine the self-update URL and, finally, another error about not reaching the updates repository.

Proposed changes: do not warn the user and skip the self-update silently if the update repository cannot be found.

Using an SMT server

As the self-update is the very first step in the installation, the SMT server address should be specified as early as possible:

• via SLP. For security reasons, the user will be asked if at least one SMT server is found.
• using the regurl boot parameter.

1. YaST2 will contact the SMT server in order to obtain the URL of the self-update repository.
2. The repository will be added.
3. If some update is available, the installer will be updated and restarted.

Error handling: same error handling than With full network access.

Proposed changes: warn the user in case of connection problem.

Using a custom update repository

The user can provide an URL to a custom self-update repository. In this case, the registration server is not needed at all.

1. The repository will be added.
2. If some update is available, the installer will be updated and restarted.

Error handling: the user will be notified if:

• the server where the update repository lives cannot be reached.
• the repository is not found. It differs from the default error handling because the URL was specified by the user.
• the repository is not valid.

Without network

If network is not configured, the self-update will be silently skipped.

AutoYaST

Differences with the regular installation

Regarding the self-update feature, AutoYaST will work mostly as a regular installation. Additionally, an AutoYaST profile allows to specify:

• A registration server (reg_server element). Analogous to regurl boot parameter.
• A self-update updates repository (self_update_url). Analogous to specifying an URL for the self_update boot parameter.

Avoiding errors

In AutoYaST is specially important not to block the installation with error messages. If the registration or the updates repositories were not available, the only ways of avoiding error messages were:

• Disabling self-update through the self-update boot parameter.
• Customizing the report section of the AutoYaST profile to disable errors. Obsviously, that's a bad thing because you won't get errors for other real problems.

Fortunately, since version 3.2.8, self-update can be disabled using the general/self_update option in the AutoYaST profile.

Other considerations

• We considered informing the user about a successful self-update. However, as it should be the normal case, we considered is enough with showing the update progress and restarting the installer.

• For the future, we should consider adding some kind of "versioning" to the installer so the user can check it if needed. As the instsys contains several packages with their own versions, we could consider using a date from packages.

• Try to reduce timeouts when contacting the registration servers. For example, if the registration server could not be reached, do not use the fallback URL in the control file as it most likely will fail.

• Consider reporting an error when the self-update is only partially applied.

• Other kind of errors (SSL, API, incompatible SMT) are handled like a regular network error, so in the default case, the self-update will be skipped.

To security updates: Silently ignoring the self update errors is a generic problem, missing a security fix in the installer might be important, but normal bug fixes might be even more important is some cases (e.g. fix for a crash or segfault).

Moreover some security fixes might be tricky, imagine an openSSL fix - for downloading it from SCC via HTTPS you would need to use the old vulnerable openSSL version...

Because the error handling is a bit tricky (it depends whether the URL was entered by user or not, at which point the error happens, what kind of the error it is...) I'm thinking about a completely different approach.

Use the opposite approach - dot not show the errors but the inform the user about successfully updating the installer. This way we do not spam the users about false errors (expected) and on the other hand the user will know that something went wrong if there is no such info.

The question is how to report the self-update status (success/error, list of downloaded/installed packages,...). A popup would be too annoying...

• We could add a new button displaying the self update status into some step
• Or use similar solution as for the Relase Notes... button at the bottom
• We have Help button, so maybe we could include the self update status there?
• Or include it in the release notes text. We could add the self update status at the beginning, it's after all related to the product release...

What do you think about this approach?

I think that the alternative approach you propose worth a discussion. Maybe I would combine both approachs:

• With default URLs, making it clear that the installer was updated makes sense although I'm not sure what's the best way to do it. We'll need our UX expert here.
• But with custom URLs, I would like the system to stop so if I made a mistake so I can fix it before proceeding.

Good point, with custom URLs it makes sense to inform the user and possibly retry (e.g. a typo in the URL).

@imobachgs All fine, but I think that the document might be actually constructed vice versa. Currently it describes the current behavior, then proposes changes and then defines a Conclusion.

But the fact is, that we might look at it as a change-request document. In such case, this Conclusion would become Requirements and proposed changes would start to make sense. When I was reading it from the top to the bottom, I missed the info why, but when you change the order, it would start making more sense to me.

As pointed out by @lslezak, I like the idea of informing the user about successful self-update. Even having a report on request might be worth the effort. We do not want to hide what is happening and by showing that the installer has been updated, we can also tell the user that there is a way how to disable that. Moreover, we could show them what exactly happened.