bootstrap new amazonlinux2 legacyx86 and aarch64 - Uyuni server 2022-08

[eins]

Problem description

Version of Uyuni Server

zypper info Uyuni-Server-release
Loading repository data...
Reading installed packages...


Information for package Uyuni-Server-release:
---------------------------------------------
Repository     : Uyuni Server Stable
Name           : Uyuni-Server-release
Version        : 2022.08-185.2.uyuni2
Arch           : x86_64
Vendor         : obs://build.opensuse.org/systemsmanagement:Uyuni
Support Level  : Level 3
Installed Size : 1.4 KiB
Installed      : Yes
Status         : up-to-date
Source package : Uyuni-Server-release-2022.08-185.2.uyuni2.src
Summary        : Uyuni Server
Description    :
    Uyuni lets you efficiently manage physical, virtual,
    and cloud-based Linux systems. It provides automated and cost-effective
    configuration and software management, asset management, and system
    provisioning.

Details about the issue

Hello there!

Today I bootstrap two amazonlinux2 minions, one x86 and the other ARM64 architecture.

the bootstrap process failed the first time because the user ec2-user doesn't have permission in /var/tmp/.ec2-user_95935b_salt

I fixed this issue by changing the permissions like so:

cd /var/tmp/
ls -latr
total 0
drwxr-xr-x 19 root     root     269 Aug 16 20:06 ..
drwx------  3 root     root      17 Aug 16 20:06 systemd-private-e8d0065597a845dba137bf20813d80a9-chronyd.service-6BL8HQ
drwxrwxr-x  5 ec2-user ec2-user 111 Aug 16 20:10 venv-salt-minion
drwxr-xr-x  3 root     root      40 Aug 16 20:10 .ec2-user_95935b_salt
drwxrwxrwt  5 root     root     138 Aug 16 20:10 .

chown -R ec2-user:ec2-user /var/tmp/.ec2-user_95935b_salt
ls -latr /var/tmp/
total 0
drwxr-xr-x 19 root     root     269 Aug 16 20:06 ..
drwx------  3 root     root      17 Aug 16 20:06 systemd-private-e8d0065597a845dba137bf20813d80a9-chronyd.service-6BL8HQ
drwxrwxr-x  5 ec2-user ec2-user 111 Aug 16 20:10 venv-salt-minion
drwxr-xr-x  3 ec2-user ec2-user  40 Aug 16 20:10 .ec2-user_95935b_salt

The second bootstrap process worked like a charm.
Is there any plan to fix to this ? I only found two tickets related to the same chown fix

ubuntu2004 01
ubuntu2004 02

[juliogonzalez]

@vzhestkov can you have a look?

[juliogonzalez]

Now that I see this...

Isn't this report https://www.uyuni-project.org/doc/2022.08/release-notes-uyuni-server.html#_bootstrap_with_web_ui_using_non_root_user ?

If so, it's a known issue, that should get fixed for 2022.09

[juliogonzalez]

@vzhestkov check the other tickets, maybe you need to reference the same link

[vzhestkov]

@juliogonzalez yes, just going to put almost the same comment. The problem that we are promoting the salt package to openSUSE from SLE and it's updated with the delay in this case.

Here is the PR with the fix: openSUSE/salt#534
@eins you can apply the patch from the PR directly on the server if you want to fix it asap, or try to install salt from this repo: https://download.opensuse.org/repositories/systemsmanagement:/saltstack:/products/15.4/

[juliogonzalez]

@eins you can apply the patch from the PR directly on the server if you want to fix it asap, or try to install salt from this repo: https://download.opensuse.org/repositories/systemsmanagement:/saltstack:/products/15.4/

I'd not recommend using the repository, as it has two consequences:

1. Vendor change, so the user will need to change the vendor back to openSUSE later
2. The release number at https://download.opensuse.org/repositories/systemsmanagement:/saltstack:/products/15.4/ is maybe bigger than what we have at our client tools, and since the version is the same, maybe the user will not even see the update from openSUSE later.

So the best approach is the workaround, otherwise bootstrapping with shell script, or otherwise applying the patch (be careful about it!)

[vzhestkov]

Totally agree, I just suggested as a workaround in case if there are significant number of such clients in the environment, in this case it's could be hard to use the workaround we suggested first (I mean with chaning ownership manually).

[eins]

@juliogonzalez @vzhestkov thanks again for all the replies.
is this fix going to be part of the next uyuni release?
do we have an estimate date for the next release ?

[vzhestkov]

I think Julio already pointed that the fix should be available with 2022.09: #5785 (comment)

[eins]

@vzhestkov excellent news! thanks again @vzhestkov @juliogonzalez
I'm closing this issue.
for uyuni 2208 the workaround is to manually run the chown command.
the fix will be add it to uyuni 2209. I will update to that version when it is ready and then I will boostrap amazonlinux2 minions again.