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.
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
------------------------------
Message: 3
Date: Wed, 14 Sep 2005 02:47:20 +0000
From: [EMAIL PROTECTED]
Subject: Re: [SunRay-Users] THINC: can the Sun Ray be improved using
any of this?
To: "SunRay-Users mailing list" <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
"Christopher Saul" <[EMAIL PROTECTED]> wrote:
> "Curt Cox" <[EMAIL PROTECTED]> wrote:
>
> From the doc, THINC requires Xfree86 to be running and needs some
> kind of client software on the client device. This means it
> requires some kind of OS at this stage.
THINC needs an OS on the server to host its XFree86 X server, just as
Sun Ray needs an OS (Solaris or Linux) to host its X server and other
SRSS components. On the client side the THINC viewer was implemented
as an application over a traditional general-purpose OS but that's just
for convenience. It's no stretch at all to imagine a THINC viewer
running in dedicated hardware over a small embedded OS, just like Sun
Ray.
> > I wasn't talking about adopting the entire protocol, but merely
> > specific details from it.
> >
> > See page 11 for an example:
> > "While Sun Ray and THINC use a similar multicommand protocol, Sun
> > Ray is unable to leverage..."
The rest of that sentence happens to be wrong. I'm not sure whether
that makes this a good example or a bad one.
> > Is offscreen drawing somehow impossible within the current Sun
> > Ray architecture?
It's not impossible at all. Whether it's actually useful is a
different question. I can see how it could reduce latency, which
is that claim that THINC makes, but it's not free. The X server
ends up doing a lot of extra work, much of which may never be used.
Netscape and its heirs are very fond of creating huge numbers of
offscreen pixmaps, many of which never get drawn onto the screen.
Is it a good use of CPU time (and memory) to pre-render those
pixmaps just in case some of them do eventually get shown? What's
the impact of pre-rendering lots of pixmaps on a machine that is
hosting lots of sessions?
It's very hard to draw solid conclusions about the goodness of the
THINC approach versus the Sun Ray approach from that paper, there
are just so many factors that are different or are unaccounted-for.
One thing that is clear (it's been clear for a long time) is that
Sun Ray's video performance is weak. The reason is that the player
application ends up having to use ordinary X pixmaps to play the
video frames, and it has to send those pixmaps through the X server.
There's a ton of overhead in this process, it's just the wrong tool
for the job.
The annoying thing is that Sun Ray actually has some interesting
technology in this area; it supports the notion of having the player
application bypass the X server completely and render the video
directly to the Sun Ray. This is a huge win both for the performance
of that one video stream and for the number of concurrent streams you
can drive from one machine. The bad news is that this approach
requires getting into the guts of the player application and writing
an output codec specifically for Sun Ray. This turns out to be
impractical in the real world, it's been released only for Sun's
now-dead ShowMeTV product.
One of the things on the wish list for a future SRSS release is
to implement the XVideo extension in the Sun Ray X server. This
is the same extension THINC used, it allows the player to send
video data through the X server with far lower overhead than
using X pixmaps. It's not as good as rendering directly from
the player to the client but it has the huge advantage of being
supported by lots of players and not requiring a client-specific
codec for every player.
We're in the middle of haggling over the feature list for the
next release, so now would be an excellent time to let your Sun
contacts know what features are important to you. If lots of
people tell us that video is important then that increases the
chances of XVideo happening.
OttoM.
__
ottomeister
Disclaimer: These are my poinions. I do not speak for my employer.
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
------------------------------
Message: 4
Date: Wed, 14 Sep 2005 09:44:13 +0200
From: Ivar Janmaat <[EMAIL PROTECTED]>
Subject: Re: [SunRay-Users] THINC: can the Sun Ray be improved using
any of this?
To: SunRay-Users mailing list <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Hello Otto,
I reported it to Ken Pepple,Technology Director, Chief Technologist CSO
Global Desktop Practice at Sun.
Video is becoming more and more an issue in educational Sunray
implementations.
Video archives and broadcast companies are putting more and more
material online for students to use.
The current Sunray performance is not good enough to compete against
standard pc's in these situations and I can imagine that this might also
be an issue in other areas.
Another question I had is about bandwidth usage.
Will the use of XVideo extensions decrease the bandwidth usage between
the sunray and the server?
Our measurements show the following bandwidth usage for an mpeg1 video
in the JDS video player.
Half size: 9 Mb/s
Normal size: 10 Mb/s
Double size: 11 Mb/s
This is measured on Solaris 10 / SSRS 3.1 alpha / Sparc.
Thanks,
Ivar
[EMAIL PROTECTED] wrote:
>One thing that is clear (it's been clear for a long time) is that
>Sun Ray's video performance is weak. The reason is that the player
>application ends up having to use ordinary X pixmaps to play the
>video frames, and it has to send those pixmaps through the X server.
>There's a ton of overhead in this process, it's just the wrong tool
>for the job.
>
>The annoying thing is that Sun Ray actually has some interesting
>technology in this area; it supports the notion of having the player
>application bypass the X server completely and render the video
>directly to the Sun Ray. This is a huge win both for the performance
>of that one video stream and for the number of concurrent streams you
>can drive from one machine. The bad news is that this approach
>requires getting into the guts of the player application and writing
>an output codec specifically for Sun Ray. This turns out to be
>impractical in the real world, it's been released only for Sun's
>now-dead ShowMeTV product.
>
>One of the things on the wish list for a future SRSS release is
>to implement the XVideo extension in the Sun Ray X server. This
>is the same extension THINC used, it allows the player to send
>video data through the X server with far lower overhead than
>using X pixmaps. It's not as good as rendering directly from
>the player to the client but it has the huge advantage of being
>supported by lots of players and not requiring a client-specific
>codec for every player.
>
>We're in the middle of haggling over the feature list for the
>next release, so now would be an excellent time to let your Sun
>contacts know what features are important to you. If lots of
>people tell us that video is important then that increases the
>chances of XVideo happening.
>
>OttoM.
>__
>ottomeister
>
>Disclaimer: These are my poinions. I do not speak for my employer.
>
>
>
>
------------------------------
Message: 5
Date: Wed, 14 Sep 2005 09:08:47 +0200
From: Hagen Heiduck <[EMAIL PROTECTED]>
Subject: Re: [SunRay-Users] THINC: can the Sun Ray be improved using
any of this?
To: SunRay-Users mailing list <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
[EMAIL PROTECTED] wrote:
>
> We're in the middle of haggling over the feature list for the
> next release, so now would be an excellent time to let your Sun
> contacts know what features are important to you. If lots of
> people tell us that video is important then that increases the
> chances of XVideo happening.
IMHO, that would be a _very_ useful feature, being able to watch live
streams directly from a video conference, for example. If this is the
place where one can "vote" for then I do this hereby :)
Hagen
--
Umweltforschungszentrum Leipzig-Halle GmbH
Dept. WKDV
------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
End of SunRay-Users Digest, Vol 20, Issue 22
********************************************
“This e-mail is sent on the Terms and Conditions that can be accessed by
Clicking on this link http://www.vodacom.net/legal/email.aspx "
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
