Scott,
2014-10-02 18:17 GMT+01:00 Nishimura, Scott L (ESS) <scott.nishim...@ngc.com
>:
> 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.
>
>
I've done a script with your notes and will do exactly what you proposed
(with rm and sed). I'll test it tomorrow and I'll post feedback, eventually
the script I've made in case it helps someone else.
Again, thanks for your help.
James
> 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
>
_______________________________________________
SunRay-Users mailing list
SunRay-Users@filibeto.org
http://www.filibeto.org/mailman/listinfo/sunray-users
