As far as the environmental variables are concerned, the datastore for
the fields you want are empty by default.
====================
Yep. My script checks for that and asks the Student what classroom and
seat are they in then uses utdesktop to update the SRDS. Shortens the
time it takes to locate a Student dramatically.
====================
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.
====================
For our purposes, this isn't an issue.
====================
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.
====================
DANG! I missed that memo big time! How do I get a look at the RFE?
====================
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)
====================
Thanks! I'll look around and see if the webcast is still available. Any clues?
====================
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.
====================
My current script only uses utdesktop -p <SR_MAC> with the output
parsed by nawk. In fact I just thought of a better way to use nawk
so I don't have to call utdesktop twice! Thanks for nudging me!
====================
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.
====================
Yep, I'm sure I'm sure I've done so many times.
====================
If this sounds like an unreasonable
policy, it's exactly the support arrangement once would find with
Microsoft or Citrix with their power shells.
====================
Not unreasonable at all. It would be nice though if we could nurture
a "Kiosk Developers Community" through which we could support each other.
====================
All that said, if the script can be sanitized, post it in the forum and I'll take a look.
====================
We'll have to do that offline. There's nothing classified, I just don't
feel like it's something I can post on such a large forum.
====================
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.
====================
32 worker threads if working fine. No negative impact. I'll re-visit the
blog to see if anything else might help.
====================
-CB
