Write the docs for the Recurring actions feature

Things not to forget:

• For running an action, user is needed. If user get deleted -> action is deleted by cascade

Preference for menu behavior should be to go to intro page when clicked and not expanded to display the intro below.

For example (CORRECT):

* xref:client-config-overview.adoc[Client Configuration Guide]
** xref:supported-features.adoc[Supported Clients and Features]
*** xref:supported-features-sles.adoc[SLES Supported Features]

In the above the first level list item points to the client overview "introduction".

In this example... we only use a text string (INCORRECT):

* Installation Guide
** xref:install-intro.adoc[Introduction]
** Requirements

at the Moment the Online Docs at uyuni-docs didn't Show all Content for Uyuni Server; e.g.
the Debian Pages for Debian Systems aren't shown,

Could you please set "{uyuni-content} == true" as default in adoc files or Change the if clause to "{suma-content} == false"

Hallo Uyuni-Team,
Is there a reason why this feature is flagged "unknown" in Table 1. Supported Features on Ubuntu Operating Systems ?
https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/supported-features-ubuntu.html

It would be fine, if this feature would be marked as OK for salt minions

Best regards
Shirocco88

Hallo Uyuni-Team,
the following Link is not working:

A Uyuni Proxy is a SLE client with a special role. You can install it using AutoYaST.
Create an autoinstallation tree as outlined in [client-cfg-autoinstallation-prep].

https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/client-automating-preparation.html#client-cfg-autoinstallation-prep

Typo Error ?
Create an autoinstallation tree as outlined in <>.
https://raw.githubusercontent.com/uyuni-project/uyuni-docs/master/modules/client-configuration/pages/client-automating-preparation.adoc

Best regards.
Shirocco88

I got from the field a suggestion: unify suggested partition when installing Uyuni/SUSE Manager.

An example:

We start talking about "Partition permissions" https://documentation.suse.com/external-tree/en-us/suma/4.0/suse-manager/installation/general-requirements.html but the illustration of how to set up those partitions is illustrated later on only for public cloud: https://documentation.suse.com/external-tree/en-us/suma/4.0/suse-manager/installation/pubcloud-requirements.html#_separate_storage_volumes

IMHO I would unify everything into a general requirement:

• we require three different partitions
• we suggest using XFS as fstype for those partitions, backed by LVM
• only for public cloud: consider putting those partitions in a volume - not the root volume

Any suggestion welcome!

The current Uyuni docs haven't "Ubuntu 20.04" listed: https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/supported-features.html

Please add "Ubuntu 20.04".

see:
https://www.uyuni-project.org/pages/devel-version.html#documentation

it points to itself; this makes less sense;
please change the link to the correct location.

Best regards
Shirocco88

Hallo Uyuni-Team,
the hint "Traditional clients are not supported." is missing in clients-debian.html
see https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/clients-debian.html

Reference: https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/clients-ubuntu.html

Best regards
Shirocco88

Hallo Uyuni-Team,
Ubuntu 20.04 is missing in Table of Supported Features of Ubuntu Operating Systems;
https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/supported-features-ubuntu.html

Could you please add a colum with Ubuntu 20.04 Features.

Thanks in Advance.

Best regards
Shirocco

ATM, administration/pages/custom-channels.adoc is confusing for uyuni users. uyuni does not necessarily provide "all required channels". Thus this intro and maybe more must be adjusted:

While {productname} provides all required channels, you might find it useful to create custom channels specific to your environment.

I have noticed the link (see screenshot ) from Monitoring Tab to Prometheus is wrong.

Current:
https://uyuni.localdomain.com/docs/administration/pages/prometheus.html

Correct one should be:
https://uyuni.localdomain.com/docs/uyuni/administration/monitoring.html

Hallo Uyuni-Team,
why should I see https://documentation.suse.com/suma/ if I would have a look at Uyuni Docu ?

======================================================================
https://www.uyuni-project.org/uyuni-docs/uyuni/reference/help/documentation-version.html

For all versions and formats of the Uyuni documentation, see https://documentation.suse.com/suma/.

Best regards
Shirocco88

Reviewing pull requests in uyuni-docs is sometimes difficult because of the placeholders, replacements, lack of context, etc in the GitHub code review tool.

Would it be possible to use GitHub Actions to automatically build the docs in the PR branch and publish them to some place (e. g. uyuni-project.org/uyuni-docs-devel/prXXXX) so that the review is easier? After the PR is merged or closed, those can be removed again using GitHub Actions.

Could you please add "Debian Client Registration" to the Client Registration Navigation Page
https://github.com/uyuni-project/uyuni-docs/blob/master/modules/client-configuration/nav-client-configuration-guide.adoc

https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/clients-ubuntu.html
https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/clients-debian.html

OLD:
// Ubuntu Client Registration
** xref:registration-overview-ubuntu[Ubuntu Client Registration]
*** xref:clients-ubuntu.adoc[Ubuntu 20.04 Clients]
*** xref:clients-ubuntu-old.adoc[Ubuntu 16.04 and 18.04 Clients]
ifeval::[{uyuni-content} == true]
*** xref:clients-debian.adoc[Debian Clients]
endif::[]

NEW:
// Ubuntu Client Registration
** xref:registration-overview-ubuntu[Ubuntu Client Registration]
*** xref:clients-ubuntu.adoc[Ubuntu 20.04 Clients]
*** xref:clients-ubuntu-old.adoc[Ubuntu 16.04 and 18.04 Clients]
ifeval::[{uyuni-content} == true]
// Debian Client Registration
** xref:registration-overview-debian.adoc[Debian Client Registration]
*** xref:clients-debian.adoc[Debian Clients]
endif::[]

originally reported by @jorx-dev at doc-suse-com/site#43:

Hello,
In the Administration Guide of SUSE Manager's Users section there is an statement that I think is incomplete. At the beginning just after the 1st paragraph, it reads:

NOTE: The Users menu is only available if you are logged in with a SUSE Manager administrator account.

I think I should be:

NOTE: The Users menu is only available if you are logged in with a SUSE Manager administrator account or an Organization administrator account.

regards,

I suspect it's here because I needed a place to add them and couldn't find anywhere better. Might be better off in a troubleshooting section maybe?

Originally posted by @Loquacity in #36

keichwa: In client config, move registration-bootstrap.adoc[Package Locks] to tshoot-clients.adoc, or a better place.

Hallo Uyuni-Team,
the docu about Supported Migration paths is incomplete, e.g. SLES15 is missing

https://www.uyuni-project.org/uyuni-docs/uyuni/reference/systems/system-details/sd-sp-migration.html
e.g.
SLE 15 > SLE 15 SP1 > SLE 15 SP2

Could you please add Supported Migration paths for SLES15

Best regards
Shirocco88

Just noticed this question. I think we would need to define {smr} as "for Retail" and use it as {productname} {smr}.

Originally posted by @Loquacity in #487 (comment)

Situation

Just reading the terminology section in the Salt Guide. This is great that we have such a guide! 👍 Especially, as a newbie, I'm happy that I can use and educate myself when it comes to Salt.

Reading this terminology from a perspective as a newbie, I've observed these issues:

• Missing terms
• Indentation
• Mixing term definitions and user actions

Proposed Solution

• Missing terms
  I guess, we don't need to explain every term in our terminology section. Especially as there is a dedicated glossary section upstream (see link below). However, especially as a newbie looking at this section, I have the feeling there are some (important?) terms missing. For example "(Salt) Module", "Minion", "Formulas", "(Salt) Master", and probably more.

• Indentation
  It seems to me, the indentation for some terminology terms are off. For example, for the term "Grains", the second paragraph "When you run a Salt command..." starts unindented. For me, this gives me the feeling this is something new and doesn't belong to this term. However, IMHO, this paragraph belongs to this term and as such it should be indented. Other terms are also affected.

• Mixing term definitions and user actions
  IMHO a terminology is about terms and their definitions. It's an informative document. It's not a howto. Therefor, I'd avoid sentences like "List all available grains with the...". If you want to keep these things, I'd suggest to move them into a different section. You could still add a link (See section 123 about using...).

Hope that makes sense. 😉

Additional Links

• https://docs.saltstack.com/en/latest/glossary.html
• https://susedoc.github.io/doc-slesforsap/master/html/SLES-SAP-sol-automation/#sec-sol-autom-terms

We do not use SSH passwords anywhere. Since most of our servers are publicly available we only use SSH key based authentication. This is not an issue since we found the ssh key that we needed and added it to our servers. We had to bootstrap a test server and then grep for the SSh key on the SuMa file system. This is not a documented procedure, but I believe it should be. The key that was needed to bootstrap our server was in [1]. After adding this key to the bootstrap users authorized_keys, we were able to bootstrap without using a password. This was with both the web-ui and the xml-rpc api. The documentation should be attached to both bootstrapping methods.

[1] /srv/susemanager/salt/salt_ssh/mgr_ssh_id.pub

In uyuni-proxy-setup.adoc and proxy-setup.adoc, the "Replace a {susemgrproxy}" section need checking.
ATM, it's commented.

Could you please add Debian-9/10 Systems to the Table 1. Supported Client Systems
https://github.com/uyuni-project/uyuni-docs/blob/master/modules/client-configuration/pages/supported-features.adoc#supported-client-systems

see also:
https://www.uyuni-project.org/pages/stable-version.html
Each supported Operating System has a repository, for all supported architectures:
SNIP
• Debian 9 (x86_64, aarch64, armv7l, i586)
• Debian 10 (x86_64, aarch64, armv7l, i586)

https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/supported-features-debian.html

Release Notes:
https://www.uyuni-project.org/doc/2020.07/release-notes-uyuni-server.html

Version 2020.03
Debian client tools
We now offer Debian client tools that allow for easy onboarding of Debian as salt minions, as well as running spacecmd from them.
Check the Client Configuration Guide for information about how to configure Uyuni Server to work with Debian clients.
For now the following architectures are supported: x86_64, aarch64, armv7l, i586
We plan to continue improving Debian support in the future, including support for ppc64le and s390x Debian 10 clients.

https://www.uyuni-project.org/doc/2020.07/release-notes-uyuni-server.html#_enhanced_support_for_debian_and_ubuntu

We have a customer, were customer complain Problem with replacing certificate in SUSE Manager
how to replace customer certificate.

He wrote the problem is resolved. Customer asked to update documentation https://documentation.suse.com/external-tree/en-us/suma/4.0/suse-manager/administration/custom-ssl.html how to install a custom commercial certificate with intermediate CAs in the cert bundle.

Based on https://stackoverflow.com/questions/20409534/how-does-an-ssl-certificate-chain-bundle-work the proper order of certs in chain is important for openssl verify it properly. I discovered that command:

rhn-ssl-tool --gen-server --rpm-only --dir /root/ssl-build/

Didn’t create a proper format of server.pem that passes openssl verify. This is why customer ommited it in the steps and copied server.pem to /etc/pki/spacewalk/jabberd directly manually.
The second reason that Iz didn’t run the above command is that the format of server.crt for httpd is different than format of server.pem for spacewalk so he manually copied server.crt to /etc/apache2/ssl.crt/ directory.

Could you please update documentation as customer asked?
If better steps exist please modify them accordingly.
It would be nice to verify why server.pem is not correctly build following openssl verify requirements when using command rhn-ssl-tool --gen-server --rpm-only --dir /root/ssl-build/.

At this moment customer modified bootstrap script so that traditional client doesn’t install CA cert via rpm but by copying RHN-ORG-TRUSTED-SSL-CERT file.

New content will be added for large deployment in: #185
We need to create the targets in the makefile for PDF

On 2020-03-13 17:41, Julio González Gil wrote:

juliogonzalez approved this pull request.

Current PR should work, but I strongly suggest deciding what to use in
all places. Sometimes we have {productname} Proxy, sometimes
{susemgrproxy} and sometimes only Proxy :-)

Yes, agreed.

• I can probably merge all this and
• then have it in one file only again.

Originally posted by @keichwa in #130 (comment)

Going through https://documentation.suse.com/external-tree/en-us/suma/4.0/suse-manager/upgrade/proxy-update.html I noticed that one is supposed to execute the spacewalk-proxy command on the SUSE Manager Server:

--- cut here ---
On the SUSE Manager Server where the proxy is registered as a client, stop the proxy service:
spacewalk-proxy stop
[...]
On the SUSE Manager Server where the proxy is registered as a client, start the proxy service:
spacewalk-proxy start
--- cut here ---

I believe the spacewalk-proxy command is to be executed on the SUSE Manager Proxy

https://www.suse.com/support/kb/doc/?id=000018198 -> would it make sense to add that to our docu maybe?

A bit like https://documentation.suse.com/external-tree/en-us/suma/4.1/suse-manager/large-deployments/tuning.html maybe?

Also it would be good to add a note to that docu stating what (and "if") services need to be restarted (and "how")?

Hallo Uyuni-Team,
Please change Recommended OS for Uyuni Server/Proxy from "openSUSE Leap 15.1" to 15.2
see https://www.uyuni-project.org/uyuni-docs/uyuni/installation/uyuni-install-requirements.html

Best regards.
Shirocco88

I have checked the reference guide for Uyuni 4.0.2 and it seems to have a mistake:

Go to -> Help -> Reference Guide -> PDF.

In section WebUI (13/249) the guide claims that there is a:

State Catalog
Create, store, and manage states for your Salt clients from the State Catalog.

But it should be a 'Formula Catalog' instead.

Hi there,

In the docs Reference Book in Images / Store, there is a mismatched screenshot.
In "Create Store" Section there is a screen of "Create Profile".
https://documentation.suse.com/external-tree/en-us/suma/4.0/suse-manager/reference/images/images-stores.html

Reagrds

https://documentation.suse.com/external-tree/en-us/suma/4.1/suse-manager/installation/pubcloud-setup.html
This page says

"You can retrieve the instance name or ID from the public cloud instance web console, or from the command prompt:

Microsoft Azure:

azuremetadata --instance-name"

When I execute the command on my Azure SLES 15 SP2 VM it does not work:

usage: azuremetadata [-h] [-x] [-j] [-o OUTPUT] [-a API] [--device [DEVICE]]
                     [--listapis] [--billingTag [BILLINGTAG]]
                     [--location [LOCATION]] [--name [NAME]] [--offer [OFFER]]
                     [--osType [OSTYPE]]
                     [--platformFaultDomain [PLATFORMFAULTDOMAIN]]
                     [--platformUpdateDomain [PLATFORMUPDATEDOMAIN]]
                     [--publisher [PUBLISHER]] [--sku [SKU]]
                     [--version [VERSION]] [--vmId [VMID]] [--vmSize [VMSIZE]]
                     [--compute [COMPUTE]]
                     [--privateIpAddress [PRIVATEIPADDRESS]]
                     [--publicIpAddress [PUBLICIPADDRESS]]
                     [--ipAddress [IPADDRESS]] [--address [ADDRESS]]
                     [--prefix [PREFIX]] [--subnet [SUBNET]] [--ipv4 [IPV4]]
                     [--ipv6 [IPV6]] [--macAddress [MACADDRESS]]
                     [--interface [INTERFACE]] [--network [NETWORK]]
azuremetadata: error: unrecognized arguments: --instance-name

Checking the package which provides azuremetadata command is python3-azuremetadata-5.1.2-1.13.1.noarch.

Alternatively there is another package azuremetadata-4.0.1-1.17.noarch but attempting to install this makes the above python package conflict. Also the python package seems to have higher version of azuremetadata

# zypper in -y azuremetadata
Refreshing service 'Basesystem_Module_15_SP2_x86_64'.
Refreshing service 'Public_Cloud_Module_15_SP2_x86_64'.
Refreshing service 'Python_2_Module_15_SP2_x86_64'.
Refreshing service 'SUSE_Manager_Server_4.1_x86_64'.
Refreshing service 'SUSE_Manager_Server_Module_4.1_x86_64'.
Refreshing service 'Server_Applications_Module_15_SP2_x86_64'.
Refreshing service 'Web_and_Scripting_Module_15_SP2_x86_64'.
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: installed python3-azuremetadata-5.1.2-1.13.1.noarch obsoletes azuremetadata < 5.0.0 provided by azuremetadata-4.0.1-1.17.noarch
 Solution 1: deinstallation of python3-azuremetadata-5.1.2-1.13.1.noarch
 Solution 2: do not install azuremetadata-4.0.1-1.17.noarch

Choose from above solutions by number or cancel [1/2/c/d/?] (c): c

SOLUTION:
Reading the manpage running the command to get the instance name works.

# azuremetadata --compute --name
compute:
    name: sleshost01

Hallo Uyuni-Team,
there is a broken Broken link in salt-ssh-push.adoc
https://wiki.microfocus.com/index.php/SUSE_Manager/SaltSSHServerPush

Please fix Page:
https://github.com/uyuni-project/uyuni-docs/blob/master/modules/architecture/pages/salt-ssh-push.adoc#for-more-information

Best regards
Shirocco88

Documentation Release Checklist - Uyuni

Use this issue template for documentation releases.

Before Packaging Day

• Check for previous Uyuni versions in the text, and update where necessary.
• Check all outstanding pull requests, and ensure everything relevant is merged (and backported where required).
  Check with the docs squad coordinator for confirmation.

Packaging Day:

• Update entities to the current versions.
• For Uyuni, cut a new branch from master using syntax uyuni-YYYY-MM-pages based on the gh-pages branch. https://github.com/uyuni-project/uyuni-docs/tree/uyuni-2020.09
• Locally build docs from the release branch and visually check output. #543
• Package documentation and push SR to OBS: https://github.com/uyuni-project/uyuni-docs/wiki/building-suma-docs#building-suma-obs-packages https://build.opensuse.org/request/show/835198
• Notify Release Manager of SR.
• Release Manager accepts package.

Release Day:

• Build docs from release branch and visually check output.
• Publish Uyuni to gh-pages: https://github.com/uyuni-project/uyuni-docs/tree/gh-pages. Add Release Manager as the assignee, and use a label with current Uyuni version. #550
• When endpoints are live, visually check output.

According to the docs https://documentation.suse.com/external-tree/en-us/suma/4.0/suse-manager/administration/custom-ssl.html you can add a custom certificate. It says to set up the SUMA server like https://documentation.suse.com/external-tree/en-us/suma/4.0/suse-manager/installation/server-setup.html normal. And the run the yast2 susemanager_setup (the doc has a typo).

When I ran this, it wiped out the database, my organization credentials and all other customization. According to the docs you can set all these things up first.

Is there no other option? I have no salt-minions or systems registered to SUMA. But I don't want to lose the channels, etc.

If this is not possible the docs need to be corrected (and that typo)

Issue: The Uyuni word useage guide specifies "file system" as two words, and not one word.

Why we need this in an issue: For tracking the effort to change this across the docs projects. To address the concerns in the questions and concerns section of this issue.

How to fix the issue: I have a list of files to change. I also have a script file to iterate through the /modules/subdirs and change filesystem to file system.

Key: File location: number of uses of "filesystem"

modules/reference/pages/salt/salt-remote-commands.adoc:1
modules/administration/pages/public-cloud-azure.adoc:1
modules/administration/pages/public-cloud.adoc:1
modules/client-configuration/pages/clients-rh.adoc:1
modules/client-configuration/pages/tshoot-clients.adoc:1
modules/client-configuration/pages/client-automating-preparation.adoc:1
modules/salt/pages/formula-pxe.adoc:1
modules/architecture/pages/spacewalk-repo-sync.adoc:1
modules/upgrade/pages/proxy-x.adoc:1
modules/upgrade/pages/client-x.adoc:1
modules/upgrade/pages/server-x.adoc:1
modules/administration/pages/image-management.adoc:2
modules/salt/pages/formula-yomi.adoc:2
modules/salt/pages/yomi.adoc:4
modules/salt/pages/formula-saltboot.adoc:5

Questions and concerns: Which of the files above have filesystem in text as a noun, and which use filesystem as a command or line in a config file, where the word must not have a space?

Please corecct the following page:
https://www.uyuni-project.org/uyuni-docs/uyuni/architecture/salt-ssh-push.html
For more information about activation keys, see: xref:ref.webui.systems.activ-keys.

In the 4.0 release used to be a detailed section about how to set up the upstream content for the Ubuntu; that useful section has been dropped.

Also, I see here https://documentation.suse.com/external-tree/en-us/suma/4.1/suse-manager/client-configuration/clients-ubuntu-old.html the following note:
The mandatory channels do not contain Ubuntu upstream packages. The repositories and channels for synchronizing upstream content must be configured manually.
but I cannot find such a note in the docs in out GMC server.

Indeed, with the current documentation installed in our GMC server, I am not able to set up the upstream content; I am forced to look back in older versions of the doc to follow the manual steps referred above.

Hallo Uyuni-Team,
I don't know what "Packages Provided by {suse} Package Hub"
see:
https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/channels.html#_packages_provided_by_suse_package_hub

Maybe a Typo ?

Best Regards.
Shirocco88

Hallo Uyuni-Team,
Ubuntu 20.04 is missing in Table of Supported Operating Systems;
https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/supported-features.html

Could you please add Ubuntu 20.04 in Table of Supported Operating Systems.

Thanks in Advance.

Best regards
Shirocco88

We revisited the terminology in the Recurring Actions feature and did some
renaming (actions -> states).
I will open a PR to address this.

When following:
https://www.uyuni-project.org/pages/stable-version.html

Selecting:
Upgrade Guide

Hyperlink:
server-update.pdf (page 19) results in 404 error.

Create and Populate Configuration Channel rhn_proxy_config_1000010001?::
Accept default Y.

SUSE Manager Username::

Does the WebUI say this even for Uyuni?

@juliogonzalez This is not about the Web UI. Here we are trying to run the configure-proxy.sh script. Is this considered to work with Uyuni? Now trying and it prints:

g153:~ # configure-proxy.sh 
ERROR: This machine does not appear to be registered with SUSE Manager Server

All this needs serious re-testing. We should fix or re-write this with a separate PR.

Originally posted by @keichwa in #45

• modules/client-configuration/pages/registration-bootstrap.adoc (Editing a Bootstrap Script)
  I found confusing the sentence:
  "Scroll down and modify both lines marked in green."
  It's not clear if the green should appear in the web browser where I am reading the doc, or
  if they mean in your terminal.

• There are no green lines in my browser.

• Users accessing the bootstrap script from their terminals will see colors according to their editor of choice and customizations.

I recommend dropping such a mention to green color.

Docs say 'azuremetadata --internal-ip' which returns an error

azuremetadata --privateIpAddress appears to return the correct internal IP

Hallo Uyuni-Team,
Is there a reason why this feature is flagged "unknown" in Table 1. Supported Features on Debian Operating Systems ?
https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/supported-features-debian.html

It would be fine, if this feature would be marked as OK for salt minions
Best regards
Shirocco88

The SUMA 4.0 and 4.1 documentation contains this file path:

• https://documentation.suse.com/external-tree/en-us/suma/4.0/suse-manager/client-configuration/autoyast.html

• https://documentation.suse.com/external-tree/en-us/suma/4.1/suse-manager/client-configuration/autoyast.html

This AutoYaST section does not seem to be part of the Guide structure in the sidebar. Is that expected?

If you start at "https://www.uyuni-project.org/" and click "Documentation" in the top menu. It leads to: "https://www.uyuni-project.org/uyuni-docs/uyuni/index.html", from there using the tree menu on the left and navigating to "
Install Uyuni Server with openSUSE" does not appear to have the updated info for the installation guide. Recommends leap 15.1 etc...

The "real" docs for the stable branch appear to be here: https://www.uyuni-project.org/pages/stable-version.html --> I can't find a link to this anywhere on uyuni-project.org. I actually followed a link from the uyuni-project twitter account to https://lists.opensuse.org/uyuni-announce/2020-07/msg00000.html --> which lead me full circle to https://www.uyuni-project.org/pages/stable-version.html

Anyway... I'm trying to test this thing out since we might be migrating away from RHEL. Happy to help with docs or to keep the website links current, haven't gone through all the contributing docs yet. But I thought you all would like to know.

Hi Lana,

I went through a PDF document as that was easy. It is pretty well done and I wasn't able to find anything technically wrong. Just one comment from my side

On page 13, we mention that for more details about connect_timeout and read_write_timeout see the Large-deployments › Tuning ›. This is not a correct statement as that part doesn't have any information about these parameters. Here connect_timeout is the time when Hub API will try to connect in making the initial connection to the peripheral server while read_write_timeout comes into effect once the connection is already established(TCP handshake is done) but then server didn't respond in a timely manner.

I didn't go through all the parameters under Tuning Large Scale Deployments because I already reviewed last time. I still skimmed through it and it looks pretty good.

In https://documentation.suse.com/external-tree/en-us/suma/4.1/suse-manager/salt/large-scale-tuning.html, there's an unresolved link to an image:

https://documentation.suse.com/external-tree/en-us/suma/4.1/suse-manager/salt/_images/parameter_graph.svg

("The Tuning Process", right before "Key to the Dependency Graph")

The image is available for 4.0 (I checked by changing the URL from 4.1 to 4.0), so likely it's just some upload omission?