[EMAIL PROTECTED] wrote:
Hi Bob,
I have 2 SunRay Server VM in FOG. They should be replicating data between
themselves as they share the user data. Regarding the monitor resolution
problem. When a DTU is restarted without a smart card inserted, it will use
the highest resolution the monitor can support (1280x1024 on a 17" CRT).
When a smart card is inserted, most of the time it does not re-set to
1024x768.
Aha. The utxconfig is setting a preference on the
*token*. When there is no smartcard inserted,
that token is essentially the DTU's MAC address
(pseudo.MAC). When there *is* a smartcard
inserted, it's the smartcard token that receives
the preference setting. There's no way to force
the utxconfig preference to pertain to the DTU
regardless of token, I'm afraid. It's a user
preference model, where we assume users have
separate smartcards (or fixed locations using
specific DTUs without smartcards).
So we had to set it to utxconfig -r '1024x768' in the
windows_connector CAM script in both servers in order to get the 1024x768
resolution.
This is basically just applying the preference to
all new tokens as they come through. Using the -a
option should make this unnecessary, and it's
certainly unnecessary (although harmless except
for overhead) to re-run it on subsequent token
insertions.
For your model, where you want the resolution
preferences to be sticky by DTU, and not by user,
I recommend a different approach which doesn't
involve utxconfig:
First, remove all your utxconfig preferences
(double-check with -o that you've cleared them
all). Then, use utresadm instead. It can be made
to apply to the DTU specifically, and doesn't have
to be token-specific.
To understand this, there's a somewhat subtle but
important distinction to understand: monitor
resolution, and desktop (X server) screen
dimensions. You want these to match in order to
avoid pan-and-scan type behaviors or wide black
bands around the desktop, so it's easy to confuse
these since typically they are set to the same
values.
In Sun Ray, you can drive each of these
independently, and by default we try to autosize
the "other" parameter to match.
utxconfig drives the X server screen dimension.
If there's a fixed dimension specified and DDC is
working, we'll choose the closest fit monitor
resolution to match the screen dimension.
utresadm drives the monitor resolution. When the
X server starts up, if there's no fixed dimension
specified it'll size the screen dimensions to match
the monitor resolution.
If neither the desktop dimension is specified (via
utxconfig), nor the screen resolution (via
utresadm), SRSS will attempt to use DDC to
determine the monitor's "preferred resolution",
use that, and size the X server screen dimensions
to match. If we can't use DDC, we'll choose a
resolution of 640x480 since that's the safest
assumption for all monitors.
So ... if you don't have any utxconfig preferences
set, and you have utresadm preferences set for all
DTUs, you should get a properly sized desktop on
all your DTUs. Like utxconfig, utresadm
preferences are persistent and shared across the
FOG. You set it once, and it's "sticky" until
changed explicitly.
The DTU may start up in 1280x1024 though.
And yes, I am using smart cards (GEMPlus, & ASK) to present the user's
virtual desktop, and each user is assigned his/her personal desktop. So a
user is also assigned his/her personal SunRay DTU. In a way, it is easier
to identify which DTU is connected with a bigger monitor. I guess we also
use the token ID to give users specific service like sound / usb disk?
The token ID identifies your desktop session.
It's how we do hotdesking (which apparently you
don't care about) and how we identify user
preferences e.g. utxconfig. Within the session,
we have a Session ID (SID) which is in an X
property which is used for all services - that's
more secure than the token, which is a publically
known entity.
So within a single windows_connector CAM script, I will have:
1) resolution for big monitors, else general resolution of 1024x768
2) specific users with sound else no sound
I will try out how the "-r sound:low" sounds like on a SunRay DTU.
I may have to use your 1st method of if-then-else because I am using "grep
"Other Info" | awk '{ print $4 }'` to map user's smart card to the user's
virtual desktop.
Careful, "Other Info" I presume you mean the
output of utdesktop. This can be a fairly
heavy-weight utility when the -c option is used,
and we've seen problems with large-scale CAM
deployments that attempt to use utdesktop during
CAM session startup. When you power up such a
deployment and all the CAM sessions startup at
once and they all call utdesktop they can really
hammer utauthd, which is a critical SRSS resource
responsible for connection establishment and
session creation. This can result in some "bad"
behaviors. Something to keep an eye on. Avoid -c
if you can in this context.
-Bob
Disclaimer: Opinions expressed in this mail are my own,
and are not necessarily shared by my employer
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
