Using SRSS 2
I am running the Controlled Access Browser and want the browser to run
in a kiosk mode at 1024x768. The resolution on the Sunray is
1600x1200.The 1024x768 Netscape window runs inside this. I want it to
be full screen.

Using utxconfig -r -a 1024x768 successfully sets the resolution for
users on the Sunray for normal logins.
When I turn controlled access browsing on (which uses the special
dummy users) it reverts to 1600x1200.

How can I make utxconfig affect the controlled access browser users?
Alternatively, can I do something in Kiosk.conf?

Do I need -s off in utxconfig?

t100ss@hotmail.com (brian lockwood) wrote in message news:<c6170474.0311120450.73e7b4e6@posting.google. com>..

> I am running the Controlled Access Browser and want the browser to run
> in a kiosk mode at 1024x768. The resolution on the Sunray is
> 1600x1200. The 1024x768 Netscape window runs inside this. I want it to
> be full screen.
>
> Using utxconfig -r -a 1024x768 successfully sets the resolution for
> users on the Sunray for normal logins.
> When I turn controlled access browsing on (which uses the special
> dummy users) it reverts to 1600x1200.

(Actually it was lower than 1600x1200 but not as low as 1024x768)

It appears from further work that in order to use utxconfig -a I need
to be a root user and to be logged on at a Sunray. It is no good to be
logged in at the console.

The default install makes root login not work at a sunray.

To enable root login at a sunray, I need to edit /etc/default/login
and comment out the appropriate line.As follows

# If CONSOLE is set, root can only login on that device.
# Comment this line out to allow remote login by root.
#
# Brian bjl changed this 14/11/2003
#CONSOLE=/dev/console

I then could log in at a sunray and issue

/opt/SUNWut/bin/utxconfig -s off

Was that necessary I wonder?
and

/opt/SUNWut/bin/utxconfig -r 1024x768

and then

/opt/SUNWut/bin/utxconfig -a -r 1024x768

I can check this with

/opt/SUNWut/bin/utxconfig -l

Just doing

/opt/SUNWut/bin/utxconfig -a -r 1024x768

did not appear to work.

I hope that someone else finds this useful.

My next trick is to make Netscape 7 into the controlled access browser
rather than 4.78. If someone else has already done this then I would
appreciate any advice.

Brian L

t100ss@hotmail.com (brian lockwood) wrote in message news:<c6170474.0311130900.237dd2da@posting.google. com>...
that in order to use utxconfig -a I need

>
> My next trick is to make Netscape 7 into the controlled access browser
> rather than 4.78. If someone else has already done this then I would
> appreciate any advice.
>
> Brian L

I found this little gem abt NS 6.22 on the Web.
One slight change and putting it in /etc/dt/appconfig/types/C makes it
work for NS 7, system wide.
I marked the change below with *******
Run the following copy command:
Quote
################################################## #######################
% cp /usr/dt/appconfig/types/C/sdtweb.dt $HOME/.dt/types/sdtweb.dt

Look for the action "SDtWebClient" in the copied file. You will see
several instances of this action. Find the one with "ARG_COUNT" equals
to "0". Edit the "EXEC_STRING" so that it will look for the browser
which you have just installed. For example:

EXEC_STRING sh -c '\
***** lose this line sdtwebclient -b
***** on the next line I had to put a space before the || i.e. at the
end of ***** the path you need a space
</your/installed/path/of/Netscape6.2.2/netscape> ||
\{ \
$sdtwebclient_patherr ; \
\}'

Run the following command to reload the action:
% dtaction ReloadActions

You should now be able to invoke Netscape 6 by clicking on the Web
browser icon on the front panel or selecting Web browser from the
workspace menu.
################################################## ########################

So the script reads

EXEC_STRING sh -c '\
/usr/dt/appconfig/SUNWns/netscape ||
\{ \
$sdtwebclient_patherr ; \
\}'

t100ss@hotmail.com (brian lockwood) wrote in message news:<c6170474.0311130900.237dd2da@posting.google. com>...
> > I am running the Controlled Access Browser and want the browser to run
> > in a kiosk mode at 1024x768. The resolution on the Sunray is
> > 1600x1200. The 1024x768 Netscape window runs inside this. I want it to
> > be full screen.
> >
> > Using utxconfig -r -a 1024x768 successfully sets the resolution for
> > users on the Sunray for normal logins.
> > When I turn controlled access browsing on (which uses the special
> > dummy users) it reverts to 1600x1200.
>
> (Actually it was lower than 1600x1200 but not as low as 1024x768)

Probably 1280x1024. You'd need one of the new Sun Ray 1g models to
get anything bigger than that on-screen.

> It appears from further work that in order to use utxconfig -a I need
> to be a root user and to be logged on at a Sunray. It is no good to be
> logged in at the console.

If true then that would be a bug, you should be able to run
'utxconfig -a' from anywhere.

> The default install makes root login not work at a sunray.
>
> To enable root login at a sunray, I need to edit /etc/default/login
> and comment out the appropriate line.

The default disallows root logins from anywhere but the console.
Now that you've turned off that limitation you've allowed people
to try to use the root account via telnet, rlogin, ssh, XDMCP,
Sun Ray and any other non-console mechanism. Lots of people
believe that this is a bad idea. Lots of people believe that
you should never log in as root even on the console, you should
instead log in as yourself and then 'su' to root. This leaves a
better audit trail and reduces the possibility that you will
accidentally damage the system while working as root. Of course
it's your system so you get to make the rules.

> I then could log in at a sunray and issue
>
> /opt/SUNWut/bin/utxconfig -s off
>
> Was that necessary I wonder?

Yes, it's absolutely necessary. This is a huge wart in the
'utxconfig' syntax. If you leave '-s on' then nothing you do
with '-r' or '-g' has any effect. With a little luck this
will get fixed in the next release of Sun Ray.

However, without '-a' that command just modifies the settings
for the current Sun Ray session, it doesn't apply globally.
What you needed was 'utxconfig -a -s off -r 1024x768'. It
sounds as though you got there in the end but you may have
forced some other configuration changes for individual
sessions on the way. If 'utxconfig -o' shows settings for
access tokens other than "default" then you should look at
those extra settings and decide whether you really want to
keep them.

> My next trick is to make Netscape 7 into the controlled access browser
> rather than 4.78. If someone else has already done this then I would
> appreciate any advice.

Ask your SE, he might be able to get you a recipe for doing
that. I know that some people have managed to do this with
Mozilla. As soon as you get away from the canned 4.7 thing
it becomes even easier to break out of the browser, but that's
why the CAM subsystem runs applications in a chroot'ed area to
begin with.

OttoM.
--
ottomeister (no longer @my-deja.com, now @mail.com)

Disclaimer: These are my opinions. I do not speak for my employer.

Thanks for your comments
<snip.............>>
> > It appears from further work that in order to use utxconfig -a I need
> > to be a root user and to be logged on at a Sunray. It is no good to be
> > logged in at the console.
>
> If true then that would be a bug, you should be able to run
> 'utxconfig -a' from anywhere.

If I log on as root at the console and issue a utxconfig then I get a
complaint that a file related to X dsiplay:0 does not exist.
(Somewhere in temp). If I look in the place then ther is one relating
to the Sunray (display:2). If I copy 2 to make a 0 file then utxconfig
reacts as I would expect and says tha Xconfig has been changed.
However the required system wide effect does not happen. Hence the
business about enabling root login in order to effect the change.

> <Snip> .................
> Lots of people believe that
> you should never log in as root even on the console, you should
> instead log in as yourself and then 'su' to root. This leaves a
> better audit trail and reduces the possibility that you will
> accidentally damage the system while working as root. Of course
> it's your system so you get to make the rules.
>

I sympathise with this view and I have to say I am a bit too cavalier
about these things. I do sign any configuration changes I have made so
that people can find them. Having got the effect I want, and by way of
a salute to Solaris Professionals out there, I will disable root
logins again. The system is isolated from the internet mind.

> > I then could log in at a sunray and issue
> >
> > /opt/SUNWut/bin/utxconfig -s off
> >
> > Was that necessary I wonder?
>
> Yes, it's absolutely necessary. This is a huge wart in the
> 'utxconfig' syntax. If you leave '-s on' then nothing you do
> with '-r' or '-g' has any effect. With a little luck this
> will get fixed in the next release of Sun Ray.
>
> However, without '-a' that command just modifies the settings
> for the current Sun Ray session, it doesn't apply globally.
> What you needed was 'utxconfig -a -s off -r 1024x768'. It
> sounds as though you got there in the end but you may have
> forced some other configuration changes for individual
> sessions on the way. If 'utxconfig -o' shows settings for
> access tokens other than "default" then you should look at
> those extra settings and decide whether you really want to
> keep them.

Ah, now that is interesting. When I implemented the 7 Sunrays in the
library with the captive login I found that I had to visit each
separate workstation and issue the utxconfig commands.

Somewhere, each Sunray appears to have its own Xconfig?



> > My next trick is to make Netscape 7 into the controlled access browser
> > rather than 4.78. If someone else has already done this then I would
> > appreciate any advice.
>
> Ask your SE, he might be able to get you a recipe for doing
> that.
I am setting up a backup server for the library system and have
successfully made the default browser into Netscape 7, however I
haven't tried implementing it as a captive browser yet.

Brian L

t100ss@hotmail.com (brian lockwood) wrote in message news:<c6170474.0311160711.66331b78@posting.google. com>...
> > > It appears from further work that in order to use utxconfig -a I need
> > > to be a root user and to be logged on at a Sunray. It is no good to be
> > > logged in at the console.
> >
> > If true then that would be a bug, you should be able to run
> > 'utxconfig -a' from anywhere.
>
> If I log on as root at the console and issue a utxconfig then I get a
> complaint that a file related to X dsiplay:0 does not exist.
> (Somewhere in temp).

That will happen if you run 'utxconfig' without '-a' on the console.
There's a world of difference between 'utxconfig' and 'utxconfig -a'.

Without '-a' utxconfig will work on the Xserver preference settings
for the current session token only. If you run 'utxconfig' (without
'-a') outside a Sun Ray session -- for instance, in a console login
as you did -- then it can't do anything sensible and will fail.

With '-a' utxconfig works on the group-wide default Xserver
preference settings. In this case it doesn't care about the current
session at all, or even whether the current session is a Sun Ray
session, so it will succeed even when executed from a console login.

> If I look in the place then ther is one relating
> to the Sunray (display:2). If I copy 2 to make a 0 file then utxconfig
> reacts as I would expect and says tha Xconfig has been changed.
> However the required system wide effect does not happen. Hence the
> business about enabling root login in order to effect the change.

By copying the Xdisplay data for display 2 you might have tricked
utxconfig into establishing some Xserver preferences for whatever
session access token was in use on display :2 at that point in time.
The group-wide default would not have been affected, you need '-a'
to do that. 'utxconfig -a' is perfectly happy on the console, in
a telnet session, whereever, it doesn't care.

> > However, without '-a' that command just modifies the settings
> > for the current Sun Ray session, it doesn't apply globally.
> > What you needed was 'utxconfig -a -s off -r 1024x768'. It
> > sounds as though you got there in the end but you may have
> > forced some other configuration changes for individual
> > sessions on the way. If 'utxconfig -o' shows settings for
> > access tokens other than "default" then you should look at
> > those extra settings and decide whether you really want to
> > keep them.
>
> Ah, now that is interesting. When I implemented the 7 Sunrays in the
> library with the captive login I found that I had to visit each
> separate workstation and issue the utxconfig commands.

That sounds as though you never established a group-wide setting.
Instead you established 7 distinct settings, one for the access token
associated with each Sun Ray unit. That's OK, but if you now add or
replace a unit you'll find that the new unit will not behave the way
you want. Similarly if you present a new access token (one read from
a smartcard, or constructed for a non-smartcard mobile login) through
one of these units -- because the current settings preferences exist
specifically and solely for the built-in access tokens associated with
the 7 existing units. (Unsurprisingly the built-in token looks
remarkably similar to the unit's MAC address).

> Somewhere, each Sunray appears to have its own Xconfig?

Every access token (unit built-in token, smartcard, non-smartcard
login, ...) can have its own X preferences. If no specific
preference settings exist for the access token in use at Xserver
start time then the group-wide preference settings are used. If
no group-wide preferences settings have been defined (through
'utxconfig -a') then the hard-coded behaviour applies -- the X
desktop is sized to match the current monitor resolution, a
single 24-bit visual depth is offered, and so on.

OttoM.
--
ottomeister (no longer @my-deja.com, now @mail.com)

Disclaimer: These are my opinions. I do not speak for my employer.