"Neal A. Lucier" <[EMAIL PROTECTED]> wrote:
> {Darkavich} Steven Misrack wrote:
> > I had this same problem. We had to disable all screen locking
> > because there was a nasty bug in SRSS2 patch -05 that causes the
> > session to be terminated upon detaching when the screen saver
> > was active.
Do you recall the bug ID? This doesn't sound familiar and none of the
bugs fixed in later revisions of the patch have descriptions that match
thst kind of problem.
Neal is running SRSS 3.0 so bugs in 2.0 patches shouldn't be a concern
for him.
> > GNOME seems to be very teprimental about when it does the right
> > thing or even listens to what is in the screen saver config. We
> > can't change it from GNOME. (Known bug that sun has not fixed
> > yet).
What's that bug ID? I haven't had any trouble with xscreensaver
keeping track of timeouts, maybe because I haven't been trying to do
anything adventurous with it.
xscreensaver's integration with PAM used to be dreadful. It's a lot
better now than it used to be but it still has at least one bug that
is extremely annoying for NSCM users. However, that affects what
happens when you reattach through NSCM. The symptom is that when
you reattach you see the screensaver, then when you hit a key or
move the mouse and immediately get kicked back out to the NSCM
greeter. The second time you reattach you get your desktop.
> > We have to tell our users to go into CDE, disable the screen
> > saver/ screen lock if they don't want to detach when it comes on.
dtsession (which does screen locking under CDE) used to have some
bugs in this area but they were all fixed a long time ago. It
still does have has some PAM-related bugs but none that have this
kind of symptom. Is your CDE/dtsession patch up to date?
> > I really think this should be user configurable, and not
> > dependent on PAM. A simple Detach_Upon_Lock variable would be
> > nice.
It has to be dependent on PAM to some degree. That's the hook that
tells NSCM that the screen has been locked. I suppose it'd be
possible to have some sort of user preference control whether a
detach happened at that point. It raises a security concern, which
is that if your session remains attached to the DTU after you've
walked away then anyone can kill that session. That's why NSCM
always wants to detach when the screen lock becomes active.
> We are having a whole slew of problems with NSCM. I just turned it
> on over the weeked to improve load balancing, which it has been
> doing an excellent job of; however...
>
> - with an extremely small subset of users after they enter in
> their login name, the password dialog box never appears, the DTU
> just sits there with a grey background and the dt "X" mouse
> cursour, the DTU needs to be power cycled
That sounds like something that happened in early 3.1 builds but
that particular bug wasn't ever in 3.0. I'll see if I can find
any reports of this happening in 3.0.
> - in xscreensaver prefences under GNOME, selecting the menu
> option, "blank now", detaches; unsetting the lock the screen option
> and waiting the n minutes, detaches; unsetting the lock the screen
> option and hitting the preview button, detaches; setting the blank
> at 10 minutes and the lock at 30 minutes, detaches after 10 minutes
As I said, xscreensaver's integration with PAM used to be awful.
What version of patch 115158 do you have?
> - one user doesn't show up in 'utwho', but does show up in finger:
'finger' basically dumps the utmp file so it doesn't always tell
the truth. Regardless of what finger says, if you have a Sun
Ray session that doesn't show up in 'utwho' output then something
is wrong. What does 'find /var/opt/SUNWut/session_proc/* -type f'
show on this machine?
> - we believe the auto-logout in tcsh is also causing issues,
> since some users with a fully disabled screensaver still get
> detached, though we haven't been able to fully isolate this as the
> cause yet
That would be very odd. 'tcsh' autologout just terminates that
shell, there's no reason why that would cause a detach. Do these
users have anything unusual in their ~/.logout scripts?
A detach can be caused by a loss of connectivity between the DTU
and the Sun Ray auth daemon. That would show up in the Sun Ray
auth_log as a disconnect followed shortly afterwards by a connect.
The user would see a flurry of on-screen icons on the DTU if that
was what was happening.
> I'm going to enable the "Allow Exit from Mobile Sessions" as a
> temporary fix and start a support call. (BTW, the "Allow Exit
> from Mobile Sessions" needs to be better documented, in the Admin
> Guide you have to infer what this option means by reading the
> entire NSCM chapter.)
Allowing Exit sessions is a fairly dangerous thing to do. They're
intended only for the case where you want to use NSCM but some of
your users don't have a smartcard and also don't have a login
account on the Sun Ray servers and therefore can't authenticate
to NSCM. The Exit session allows those users to get to a dtlogin
greeter and do a remote X login from there to some system where
they do have a login account.
The dangerous part is that Exit sessions do not get locked
automatically when they become detached, because they're showing a
remote X desktop that has no notion of lock-on-detach. It's very
easy for one of these users to walk away leaving an NSCM greeter on
the DTU and not realise that his Exit session is still there, still
logged in on the remote machine, and instantly accessible to anyone
who comes along and presses the Exit button. Exit sessions aren't
mobile either, they're tied to that specific DTU.
What I'm trying to say is that I don't see how Exit sessions are
going to help, and they have the potential to make things far worse.
If you're looking for something to do that might help until this
gets properly diagnosed and fixed then I'd suggest commenting
pam_sunray.so out of the PAM "auth" definitions for the screen
lockers. That'd be the "dtsession-SunRay auth" definitions for CDE
and the "dtsession auth" or "xscreensaver auth" definitions for
Gnome. pam_sunray is the module that detaches the session when the
screenlock invokes PAM to reauthenticate the user. A side effect
will be that when you reattach an NSCM session you'll then have to
dismiss the screenlock manually. That's because the other half of
pam_sunray's job is to dismiss the screensaver automatically when
you reauthenticate to NSCM.
OttoM.
__
ottomeister
Disclaimer: These are my opinions. I do not speak for my employer.
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
