Thank you for the input Bob. In regards to the work around I mentioned below, I first delete the multihead group from the server then I get the login screen on the secondary and after attaching the keyboard mouse to the secondary I can login and run utswitch. Works for so long as the secondary isn't powercycled.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bob Doolittle > Sent: Monday, July 16, 2007 2:53 PM > To: SunRay-Users mailing list > Subject: Re: [SunRay-Users] Multihead on non-failover group > > Bemis, Suzanna K wrote: > > I have a Solaris Sunray Server on the same LAN as a Linux Sunray > > Server with the Solaris Sunray Server acting as the dhcp > server too. > > They are not in failover. There are many multihead groups > configured > > on the Solaris Server which I've configured on the Linux > Server too. > > These multiheads are configured using Sunray 1's and 1G's. When a > > user switches from the Solaris server to the Linux server > by any means > > possible, i.e. utswitch, utselect (Enter Server), the > primary sunray > > switches to the Linux server but the secondary doesn't. > > Yes, this is "by design" to protect people against "roaming" > multihead groups among FOGs with potentially inconsistent > multihead configurations. > You could imagine forwarding a multihead group to a FOG > without a multihead configuration - you'd wind up with > secondary heads (typically with no > keyboards) showing greeter sessions > (i.e. individual sessions of their own) that were > inaccessible. This was considered sufficiently unpleasant to > warrant defeating multihead roaming entirely, back in the > days when we were first experimenting with roaming between FOGs. > > > Work around is > > done by plugging a keyboard/mouse into the secondary and running > > utswitch, etc to get to the Linux server. > > I don't see how this can work, if you have the same multihead > configuration everywhere. > Secondary heads will merely show the "wait for primary" icon > and you won't be able to run utswitch or anything else on them. > > I'm afraid there is no workaround for this situation, sorry. > I suppose if you had the new 4.0 manual configuration > firmware you could change the server list to the destination > group, but that would be very cumbersome and possibly risky > (a typo would prevent the Sun Ray from connecting anywhere > until somebody intervened). > > We do have an RFE (6581172) open and if there was sufficient > customer (or sales) interest we could implement it in a > future release. What has been considered is to allow > multihead groups to carry their own configuration information > along with them when "roaming" between FOGs, and use it in > preference to any local configuration (or lack thereof). > This would avoid inconsistencies in multihead configuration > in remote FOGs. > > -Bob > > > Whenever the secondary sunray > > server is power cycled or the Linux server is rebooted, then the > > secondary goes back to the Solaris Server. I realize that > if I broke > > up the addresses for DHCP and assigned IP's from the Linux sunray > > server to the secondary sunray's I'd get multihead on the > Linux sunray > > server, but what if I wanted then to go back to the Solaris sunray > > server at that workstation? I've tried changing "macros" in the > > dhcpmgr on the Solaris server but that seems to break the > authentication all together. > > 'utmhadm -a' command on the Linux sunray server indicates > > "<secondaryMAC> not in admin database", but 'utdesktop' > says it is. I > > deleted the utmhadm group and readded it, then it doesn't complain > > about "not in admin database". > > > > Point is I want to maintain both the Solaris Sunray Server > and Linux > > Sunray Server in non-failover but be able to switch back and forth > > between Solaris and Linux depending on user. Would AMGH > help at all? > > I will be deploying SunRay 2fs's soon, and they work great in the > > multihead capacity, but in the meantime I need the 1's and > 1G's to be > > flexible. > > > > Thanks, > > Suzie > > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > 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 > > _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
