Hi Art,
As far as the environmental variables are concerned, the datastore for
the fields you want are empty by default. Which means you have to enter
the data, presumably because you want to act upon it. If a hot desk
occurs, you'd have to re-query and reset because env variables are
static. 6-of-1, half a dozen of the other really.
I think supported "utinfo" utility is more of what your after, an easy
to use, and non-invasive (not to mention uniform) method to find a
variety of information that could be deemed useful to
administrators/kiosk users. There is an RFE for this. We also have
some location based features in beta right now that I'm sure you'll find
useful (FYI, there was just a webcast related to healthcare that covered
the upcoming location based awareness features)
That said, the point about poorly written kiosk scripts still applies.
For instance, you can query the location field and depending on the
switch you give utdesktop you will either involve authd, or you will be
making a harmless ldap query. In almost all cases of the ut* commands
if you query only connected sessions, then you will be requiring authd
to get involved. If you just list, then it's almost always an ldap
call. If doubt and you have test system with few users, truss the authd
java process. If truss starts spewing data when you run your ut* query,
then you are involving authd.
FWIW, support is not in the business of reviewing custom kiosk scripts.
Oracle supports the kiosk framework and the ability for customers to
write their own script. However, Oracle can't support the actual script
written by the customer (or the 3rd party programs they call) since they
weren't developed in manner that involves a formal release process (i.e.
tech and functional specs, QA, documentation, etc). Not to mention the
proficiency with shell scripting varies greatly from customer to
customer. I know I've caused more than my share of facepalms for the
likes of Otto, BobD, Kent, etc. ;) If this sounds like an unreasonable
policy, it's exactly the support arrangement once would find with
Microsoft or Citrix with their power shells. All that said, if the
script can be sanitized, post it in the forum and I'll take a look.
Regarding the M4000, as beefy as they may be, all it takes is one of the
authd worker threads or something they interact with to be too busy at
the right time for certain things to fall apart. Especially if you
needed that information to proceed in a script. (This is why in most
kiosk environments, increasing the worker threads is a good idea). Good
chance you wouldn't even see a blip on the overall system monitoring.
-CB
On 2/19/12 8:34 AM, Art Peck wrote:
I'm starting a new thread on this topic as we seem to be hijacking the
other thread.
Thanks CB for your insightful and detailed comments on this topic. As
always, very informative.
Here are my responses:
KA_Warning messages:
These are warnings that the expected Keep Alive packet wasn't received.
The Sun Ray expects a keepalive message from the server every 20
seconds. Miss three of those in a row for the same DTU and it will
reboot. Note that the server also expects the same from the Sun Ray
every 240 seconds.
So the events would be:
20 second timer elapses with no KA ==> log it.
20 second timer elapses with no KA ==> log it.
20 second timer elapses with no KA ==> log it, reset.
I got a good lesson on KA_WARNINGs from our mutual friend Kent P so I am
aware of the 20 second interval for the DTU to hear from the SRS. I was not
aware of the 240 second interval.
While the knee jerk reaction to this would be a network problem, in my
experience it's usually due to server side issues caused by poorly
written kiosk scripts. The rationale for not pointing fingers at the
network is that the DTU has successfully sent the KA_WARNING messages
*and* syslog has logged them. That means packets are flowing over the
network and the server isn't hung.
My knees are not jerking ;-/. This issue has been discussed at length
with the network admin. Our only conclusion is that the network event
was of sufficient duration to trigger the KA_WARNING but recovered in
time for the log entry to be successful. Admittedly, that is pretty
weak. We know that if you step or stand on certain spots in a few of
the classrooms, the floor panels crush the network drop to at least 1
of the DTUs causing a lose of network connectivity. I have to assume
that if the instructor stood in one spot long enough, then moved, we
could see KA_WARNINGs and not resets. What is perplexing is the case
where we actually get a reset. How is the log entry being made??
A poorly(designed)Sun Ray Kiosk script that does things like invoke authd to
gather information can lead to these messages if authd gets too busy.
AHEM. OK. I will gladly submit my Kiosk script for a code review. I'll
open a service request on Tuesday when we return to work and suggest that
the Support Engineer get in touch with you to do so. Thanks in advance.
That said, I will point out, once again, that there are data elements from the
SRDS that would be very useful as shell variables passed in the environment
much as SUN_SUNRAY_TOKEN is passed. Things like the "Location" and "Other
Info" items from the Desktop tab in the webadmin interface. This would
reduce, possibly eliminate, the need for calls to various CLI utilities that
ultimately interrupt authd, perhaps at a busy time. If I missed the memo,
I apologize and request a re-send.
Remember that "TurboCAM" settings still apply when it comes to Kiosk
Mode and the changes to auth.props with regards to worker threads for
authd. The default of 8 just isn't enough in many, especially today,
when you can have a 300-500 Sun Rays on one server and they all start
their sessions/insert their cards around the same time.
Good point. We do tend to forget that your blog is still available and
very useful. In our case, I have raised the number of workers to 32. This
did seem to have a positive affect on the startup times during the login
storm each morning.
Our SRS are beefy M4000's. We have on average 100 to 120 sessions per
SRS. I see no signs of memory stress, however, at times I do see what I
think is quite a large run queue as reported by vmstat. The highest I've
seen is mid-20's. SYS/USR/IDL seem reasonable with a couple of SRS showing
zero idle at times.
LogXXX= key/value pairs:
You should see a lot of of messages, many of them useful, if you set
LogNet=7, some of them quite useful. 7 is the highest verbosity for the
LogXXX key/value pairs. I'll make sure we get the levels back in the
doc as they seemed to be missing.
Thanks for that tip. I have all the LogXXX=9 since I saw no
guidance in the docs. I will adjust that first thing Tuesday.
Also, don't forget to set LogHost=<IP Address> in the parms file as
well, otherwise the specification of just LogXXX= is useless.
Yep, got caught by that one! I have all the member's parms file pointing
at the same LogHost IP. I that a bad thing?? Easy enough to spread it around.
AP
--
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
