[BUG] Salt-master 3006.3 can not be installed on RHEL system when salt user exists in ldap with sssd

[jeff350]

Description When attempting to install salt-master in an environment where accounts are stored in ldap to ensure consistent uid/gid across the environment, the install fails. the package install step on a RHEL the yum install salt-master fails due to the user already existing in ldap.

Setup (Please provide relevant configs and/or SLS files (be sure to remove sensitive info. There is no general set-up of Salt.)

• [X] on-prem machine
• [ ] VM (Virtualbox, KVM, etc. please specify)
• [ ] VM running on a cloud service, please be explicit and add details
• [ ] container (Kubernetes, Docker, containerd, etc. please specify)
• [ ] or a combination, please be explicit
• [ ] jails if it is FreeBSD
• [ ] classic packaging
• [X] onedir packaging
• [ ] used bootstrap to install

Steps to Reproduce the behavior

• Install a new RHEL/Rocky/Centos system
• connect to ldap infrastructure with sssd
• add a salt user to the ldap server
• install salt-master on the system

Transaction Summary
============================================================================================================================================================================================
Install  1 Package (+1 Dependent package)

Total download size: 61 M
Installed size: 174 M
Is this ok [y/d/N]: y
Downloading packages:
(1/2): salt-master-3006.3-0.x86_64.rpm                                                                                                                               | 3.4 MB  00:00:00     
(2/2): salt-3006.3-0.x86_64.rpm                                                                                                                                      |  58 MB  00:00:00     
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                                        81 MB/s |  61 MB  00:00:00     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
salt:*:11111:salt
usermod: user 'salt' does not exist in /etc/passwd
error: %pre(salt-3006.3-0.x86_64) scriptlet failed, exit status 6
Error in PREIN scriptlet in rpm package salt-3006.3-0.x86_64
error: salt-3006.3-0.x86_64: install failed
/var/tmp/rpm-tmp.uxN5o4: line 2: /opt/saltstack/salt/bin/python3: No such file or directory
  Installing : salt-master-3006.3-0.x86_64                                                                                                                                              2/2 
  Verifying  : salt-master-3006.3-0.x86_64                                                                                                                                              1/2 
  Verifying  : salt-3006.3-0.x86_64                                                                                                                                                     2/2 

Installed:
  salt-master.x86_64 0:3006.3-0                                                                                                                                                             

Failed:
  salt.x86_64 0:3006.3-0                                                                                                                                                                    

Complete!

Expected behavior Salt should install properly and run as the salt user from the ldap server.

Versions Report N/A salt fails to install

Additional context This appears to be referring to this line in the spec file https://github.com/saltstack/salt/blob/master/pkg/rpm/salt.spec#L417 it seems like the usermod should be moved into the above if statement.

[OrangeDog]

seems like the usermod should be moved into the above if statement

It's intentionally below it so that an existing user is also modified. This is related to #65264 and other issues where the package assumes everyone is using the defaults and nothing else.

Aside: If you have LDAP authentication configured correctly, usermod should be aware of it via applicable PAM hooks. However, the install would likely still fail as the package script is not providing LDAP credentials to make the change.

[jeff350]

That this is still happening on latest 3006