Hi All,
Hope someone can help me with this.
We've got a couple of users that's accessing some of our application via
Tarantella on Sunray. The user's are complaining of slow response when
using it on SunRay, but if they use the native client of any Windows
machine it's fine!
I've logged calls to both SUN and Tarantella, but it's just ended up in
finger-pointing...Wonder what they gonna do know that SUN has bought
Tarantella.
Sunray Version:
PKGINST: SUNWuto
NAME: Sun Ray server Core Software
CATEGORY: system, sunray
ARCH: sparc
VERSION: 2.0_37.b, REV=2002.12.19.07.46
BASEDIR: /opt
VENDOR: Sun Microsystems, Inc.
DESC: Sun Ray server, administration and user commands
PSTAMP: SunOS_5.8_20040612101906
INSTDATE: Jul 23 2004 02:41
HOTLINE: Please contact your local service provider
STATUS: completely installed
FILES: 165 installed pathnames
9 shared pathnames
16 directories
122 executables
4 setuid/setgid executables
13096 blocks used (approx)
SunOS 5.9 Generic_117171-02 sun4u sparc SUNW, Sun-Fire-480R
Tarantella Version:
Tarantella Enterprise 3 for SPARC Solaris 2.8+ (3.40.911)
Tarantella Enterprise 3 Andrew Fonts (3.40.911)
Tarantella Enterprise 3 Hangul Fonts (3.40.911)
Tarantella Enterprise 3 ICL Fonts (3.40.911)
Tarantella Enterprise 3 Oriental Fonts (3.40.911)
Tarantella Enterprise 3 SCO Term Fonts (3.40.911)
Tarantella Enterprise 3 Platform Identity Pack for SPARC Solaris 2.8+
(3.40.911)
Tarantella Enterprise 3 Security Pack for SPARC Solaris 2.8+ (3.40.911)
Tarantella Enterprise 3 Windows Connectivity Pack for SPARC Solaris 2.8+
(3.40.911)
Architecture code: spso0508
This host: SunOS 5.8 Generic_108528-27 sun4u sparc SUNW, Sun-Fire-280R
Regards,
Althea
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: 14 September 2005 11:02 AM
To: [email protected]
Subject: SunRay-Users Digest, Vol 20, Issue 22
Send SunRay-Users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.filibeto.org/mailman/listinfo/sunray-users
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of SunRay-Users digest..."
Today's Topics:
1. Re: screensaver behavior in NSCM ({Darkavich} Steven Misrack)
2. Re: screensaver behavior in NSCM ([EMAIL PROTECTED])
3. Re: THINC: can the Sun Ray be improved using any of this?
([EMAIL PROTECTED])
4. Re: THINC: can the Sun Ray be improved using any of this?
(Ivar Janmaat)
5. Re: THINC: can the Sun Ray be improved using any of this?
(Hagen Heiduck)
----------------------------------------------------------------------
Message: 1
Date: Tue, 13 Sep 2005 14:37:05 -0700
From: {Darkavich} Steven Misrack <[EMAIL PROTECTED]>
Subject: Re: [SunRay-Users] screensaver behavior in NSCM
To: SunRay-Users mailing list <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
This happened to me when I went from 3.0 to 3.1 beta.
I had to delete and re-install 3.1 beta fresh.
I think the problem is a corrupt LDAP entry.
The problem went away once I did that. (Although it may have been
because I trashed the entire install) ;-)
-Steve
On Sep 13, 2005, at 13:11, Neal A. Lucier 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.
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).
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.
I really think this should be user configurable, and not dependent
on PAM. A simple Detach_Upon_Lock variable would be nice.
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
- 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
- one user doesn't show up in 'utwho', but does show up in finger:
bessel ~ % finger | grep dtlocal
[snip]
uxxxxx William J Uxxxxx dtlocal 2 Mon 10:54 :17
[snip]
bessel ~ % utwho -aH
DISP Token User
[snip]
16 auth.kxxxxx kxxxxx
18 auth.wxxxxxx wxxxxxx
[snip]
The user uxxxxx has a complete CDE session running; however, SRSS
has no idea of its existance (it doesn't show up in the admin GUI
either), and it is now no longer attached to any DTU so the user
can't get it back.
- 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
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.)
Neal
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
------------------------------
Message: 2
Date: Wed, 14 Sep 2005 01:10:29 +0000
From: [EMAIL PROTECTED]
Subject: Re: [SunRay-Users] screensaver behavior in NSCM
To: "SunRay-Users mailing list" <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
"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.
