phibid

Can't reproduce this issue again, will close this issue.

I re-open this issue because indeed, if `pam_tally2` is activated, the ssh user used to bootstrap a new Uyuni client is locked, and the bootstraping failed to successfully finish.

As mentioned by Simon Avery by mail, seems that now the `noexec` flag is not welcome on `/tmp` anymore. And the user used for registration (in my case I use...

Ah, found this (https://www.suse.com/releasenotes/x86_64/SUSE-MANAGER/4.3/index.html):  Have tried this: ``` [root@rocky8 tmp]# chown -R uyuni: /var/tmp/.*_salt ``` And the bootstrapping now works. Do you know if this has been corrected in...

As a working workaround, instead of having a first failed attempt, the creation of the empty salt thin directory with the correct ownership permissions works.

I was mistaken with the `noexec` flag. Issue during bootstrapping is when this flag is present on `/var/tmp` FS and not on `/tmp`.

@meaksh Sorry for the delay ! I have checked your link, and I confirm that pam_tally2 was not correctly configured ! Thanks !

I have just updated our preprod env to 2022.11, and I can still see the same behaviour. I have added the log4j debug, and here is what I can observe...

Sorry, please disregard my last message, this was related to https://github.com/uyuni-project/uyuni/issues/6193, I have applied the patch for 2022.11 and no more message in the logs.