James,
I found my notes and they match your results. And yes, the file to be edited
was also in /tmp/SUNWut.
cd /tmp
find . -name '*' -exec grep MAC {} \; -exec ls {} \;
rm SUNWut/config/displays/21
rm SUNWut/config/dispinfo/21
rm SUNWut/config/ctokens/pseudo.MAC
rm SUNWut/config/itokens/pseudo.MAC
rm SUNWut/config/idle/21.info
rm -r SUNWut/kiosk/:21
and also remove line containing the MAC from /tmp/SUNWut/config/xconfig/Xconfig.
Reboot the thin client and it should connect.
Scott
From: sunray-users-boun...@filibeto.org
[mailto:sunray-users-boun...@filibeto.org] On Behalf Of James Michels
Sent: Thursday, October 02, 2014 10:07 AM
To: SunRay-Users mailing list
Subject: EXT :Re: [SunRay-Users] 26D and ability to effectively erase sessions
Hello Scott,
2014-10-02 15:28 GMT+01:00 Nishimura, Scott L (ESS) <scott.nishim...@ngc.com>:
I ran into this problem in an older version of SRSS and found the only
solution, short of a server reboot, was to go into /tmp/SUNWut and delete
everything that had that thin client's MAC. There were about 6 files to delete
and also an entry in another file [which cautioned in the header "do not edit",
which I ignored : ) ].
Do you (by chance) remember if the "DO NOT EDIT" file was also under the
/tmp/SUNWut directory? As far I've been able to find those files:
config/dispinfo/27:TERMINAL_ID=IEEE802.00XXXXXXXXXX
config/ctokens/pseudo.00XXXXXXXXXX:TOKEN=pseudo.00XXXXXXXXXX
config/ctokens/pseudo.00XXXXXXXXXX:TOKEN_SET=pseudo.00XXXXXXXXXX
config/ctokens/pseudo.00XXXXXXXXXX:INSERT_TOKEN=pseudo.00XXXXXXXXXX
config/displays/27:TOKEN=pseudo.00XXXXXXXXXX
config/displays/27:TOKEN_SET=pseudo.00XXXXXXXXXX
config/displays/27:INSERT_TOKEN=pseudo.00XXXXXXXXXX
config/itokens/pseudo.00XXXXXXXXXX:TOKEN=pseudo.00XXXXXXXXXX
config/itokens/pseudo.00XXXXXXXXXX:TOKEN_SET=pseudo.00XXXXXXXXXX
config/itokens/pseudo.00XXXXXXXXXX:INSERT_TOKEN=pseudo.00XXXXXXXXXX
config/xconfig/Xconfig:DisplayManager.*_27.environment:
SUN_SUNRAY_TOKEN=pseudo.00XXXXXXXXXX CORONA_TOKEN=pseudo.00XXXXXXXXXX
But none of them contains such warning. Anyways, this is much more then I had
up until now, so I'll test it tomorrow and provide some feedback. Thank you
very much!
I don't remember if I had to do that on all FOG members; I don't think so.
YMMV
Use at your own risk
etc
Regards,
James
From: sunray-users-boun...@filibeto.org
[mailto:sunray-users-boun...@filibeto.org] On Behalf Of James Michels
Sent: Thursday, October 02, 2014 5:33 AM
To: sunray-users@filibeto.org
Subject: EXT :[SunRay-Users] 26D and ability to effectively erase sessions
Hello,
We're getting spotaneous and unpredictable 26D screens sometimes. This doesn't
happen quite often, but what's worrying is that we're unable to restore the
affected client's state to be reset.
We've tried to reset the client using the utsession -k -t command, also
utdisplay -d and both of them seem uneffective, as when rebooted, the client
remains in the same 26D state.
The only thing that helps is a complete server reboot.
When the client reconnects to the server we're seeing this in the log so maybe
it's related:
Oct 2 12:43:52 srss7 utauthd: search_for_entries(): Found multiple matching
entries, was expecting a single match
I deduce that the session is not being cleaned up entirely, so here's my
question:
Is there a effective way for completely wipe the information from a client?
Something like this must be possible, otherwise a complete server restart
wouldn't help either.
I don't mind connecting to the local LDAP server and deleting 'something' by
hand, but I'd like to know a way. We're running OL6.5.
Thank you.
James
_______________________________________________
SunRay-Users mailing list
SunRay-Users@filibeto.org
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
SunRay-Users@filibeto.org
http://www.filibeto.org/mailman/listinfo/sunray-users
