Description of problem:
On my newly installed satellite, I have the following users:
There is an account restriction in system-auth which is only supposed to affect
regular users, hence it comes after:
account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
crond requires system-auth for its account check. cron jobs scheduled for
nocpulse do not run because the nocpulse user does not pass the user account
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Satellite 410
Users created with uids >= 500
Users created with uids < 500 (ie, useradd -r)
assigning to rhn415-triage for review by the release team, and re-assigned to
will attempt to fix this in 415
I found where to fix this in our code but I wanted to get more info on how to
setup a system to reproduce the failure so I could ensure that the changes I
make don't break any existing infrastructure. I'm not familar with system-auth
so I could use some info.
When we create the users (in the NPusers rpm) we are specifically setting the
UID to 502:
/usr/sbin/useradd -c 'NOCpulse user' -u 502 $wheel_group nocpulse
/usr/sbin/useradd -c "NOCpulse Ops" $wheel_group nocops
The engineers who built this RPM aren't around anymore so I don't know the
history around why it was specifically hard coded to 502.
Feel free to contact me on irc, #rhn or email or this BZ. Doesn't matter to me.
gotta move this to 420, no time left in this upcoming release to fix this.
If you stick the above line in /etc/pam.d/system-auth, it should do the trick
I expect they hardcoded it to 502 because on their development systems, uids for
regular users started at 500. Somebody created a regular user at some point for
nocpulse and nocops and it got assigned 502, then they stuck with it.
Duplicate of 202614
User nocops is not needed anymore.
User nocpulse is now system account with home in /var/lib/nocpulse/
*** This bug has been marked as a duplicate of bug 202614 ***