peter_blatherw...@mitel.com schrieb:
Fixed it. Thanks for the thoughts all.
Based on following down the thread pointed to below by Chuck, found
that there was a config file that was bad in our broken RHEL install.
(Fine on the others that are working happily). Specifically, the file
*/etc/pam.d/uthotdesk* needs to look something like:
* auth include system-auth *
* account include system-auth*
* password include system-auth*
* session include system-auth*
The file had lines of the form "*<blah> required pam_deny.so*" -- that
does not work, resulting in the card-based hotdesking lock-ups. Looks
like it was sending authorizations to oblivion (ie denying access,
returning an internal error)? Perhaps others deeper in this area could
explain.
Any thoughts on how our system might have gotten into this state would
be appreciated. Especially, what install process may have gone wrong.
One thing I noticed, gnome-screensaver was not installed on our busted
system. (This cam up as related in the other thread.) It generates a
file for itself in same pm.d directory, of exact form we are looking for
here. Could it be SRSS install tries to clone the screensaver file??
Yes. Essentially SRSS tries to clone the 'gnome-screensaver' file for
uthdlogin. It falls back to cloning the 'other' file, if that one isn't
there.
'Other' really is intended to provide the policy for any new
authentication services. If that policy is "don't let anyone in", that
is what you get. IMHO the paranoid 'other' file that is shipped recently
on Linux gets this wrong.
Do you have any kind of screen saver or screen lock installed on your
system? What is its pam.d file called? And would that file do the right
thing for Sun Ray re-login/unlock?
- Jörg
_______________________________________________
SunRay-Users mailing list
SunRay-Users@filibeto.org
http://www.filibeto.org/mailman/listinfo/sunray-users
