"Ellis, Mike" <[EMAIL PROTECTED]> wrote: > 4 SunRAY Servers (in a single "domain" / failover group): > SunRAY-Server1 (special class of system) > SunRAY-Server2 (special class of system) > SunRAY-Server3 (normal box...) > SunRAY-Server4 (normal box...) > > Various SunRAY Clients.... > > Various SunRAY Tokens(cards) say with the following users. > - Joe1 > - Joe2 > - Bob > - Tom > > =========================================== > > The trick is that under this scenario, load-balancing will basically > allow all 4 user to log into any machine...
If they have accounts on all machines, yes. > What I'm trying to do is ENSURE (enforce?) that Joe1 and Joe2 *ONLY* > login to Server1/Server2 (and they can load-balance between those all > they want... > > And that Bob and Tom, *ONLY* login into Server3/Server4. (and they can > loadbalance between those all they want.) > > -- > > You can easily do this, by essentially creating *TWO* separate > domains/fail-over groups.... But I think the problem there is that now > Bob and Tom can *NOT* use the SunRAY clients that are part of the > *other* failover group... Right, unless the users are allowed to redirect the Sun Ray to a host belonging to the group where the user belongs. > How have others on the list dealt with this type of situation... (asking > the users to use UTSELECT after they login somewhere doesn't sound like > the best way to go....) You can ask them to use utselect before they log in (there's a configuration option that will present utselect before a login greeter is shown) but that's not workable unless your users are technically sophisticated and willing to play by the rules. There's no easy way to solve this in 2.0. I'd probably set the hosts up in separate groups and use a site-specific Xsetup script on each host to examine the Sun Ray token and then 'utswitch -r -h <host>' to a host in the other group if the token shouldn't be allowed on this host. Be careful if you do this because Sun Ray edits stuff into the system Xsetup script and you don't want to lose those edits. Source'ing the system Xsetup (from /ust/dt) into your site Xsetup (in /etc/dt) before you do your additional processing is a good way to handle that complication. The next release should make this slightly easier, it's supposed to include a feature that will let you control this kind of thing. You can create a shared library that will get invoked at the appropriate point and can indicate whether the session should stay on the current host or go elsewhere. It'll be interesting to see how that works out during the 3.0 beta. OttoM. __ ottomeister Disclaimer: These are my opinions. I do not speak for my employer. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ SunRay-Users mailing list [EMAIL PROTECTED] http://www.filibeto.org/mailman/listinfo/sunray-users
