Scott,
You've responded with more detail about your config - 6 FOGs with pairs
of servers for HA/LB.
So more comments inline:
Scott L Riggen wrote:
It's OK to mix sparc and x86 in a single FOG, but think of your
application environment. Is it truly transparent? Or do users have to do
things somewhat differently on sparc and x86? Do users have their own
binaries (built for one specific platform)? These are the sorts of
considerations that will drive your decision.
For token maintenace I was really talking about issues with multiple failover groups. If
you have 1 token reader then when you register a new token you have to find the correct
sunray server so it can "read" that token to do an add user. then, you have to
copy that some token to all 3 other FOG. As I understood it all 4 FOG had to know about
all my tokens so that switching would work.
As you pointed out, local registration isn't really what you want. If I
were you, I'd simply use utuser -r to read the token, but send it
someplace central for registration (e.g. LDAP server or
remotely-accessible database).
I've seen people use Sun Ray registration usefully for two kinds of
purposes:
- Security so that people with unregistered smartcards can't access
systems in any way
- stuff like follow-me-printing that leverages information (typically in
the "other-info" field) to do useful stuff. In the case of
follow-me-printing you register the DTU and store the name of the
closest printer (I believe), then scripts can retrieve that info and use
it during printing.
If you're not doing either of the above, there's probably no point in
using registration at all. But I'm just a lowly developer, not an
enterprise sysadmin so maybe admins out there have other insights.
If you have a mapping somewhere of tokens to users, you can use one of
the supplied reference token-based scripts/programs, e.g.
/opt/SUNWutref/amgh/utamghref_script. For your purposes the back_end_db
script ought to have lines that look like this:
So, how does having multiple hosts for a given person affect the sunray server
load balancing stuff.
Not at all. AMGH uses the first responding host. It first asks that host
if there's a session for the token within its FOG. If there is it
redirects the DTU directly to the appropriate server. If not it sends
the DTU to that first host and let's it load balance (so there may be a
second redirection before a new session is first created).
The point to having more than one is just HA in case the first is down.
*Sometimes* people who are very paranoid^H^H^Hcautious will provide
hosts in different FOGs for things like disaster recovery (in case the
entire first FOG is down) but there are downsides to such an approach
(search the archives for discussions of pros/cons).
I'd really like to have a batch of users go to a matched pair of servers.
I'd hate to have to create a db file with 1/2 users pointing to 1 server first
then the other then flip that for the other half of the users. Seems like a
lot of maintenance. I'd like to switch them to the FOG and let it figure out
which machine to put them on based on load, etc.
Then AMGH seems like the ticket, but you do need to deal with managing a
central source of information for all users. You might get away with
some sort of kludgey propagation mechanism that spreads around the local
registration data to other servers but that doesn't sound advisable. You
might even be able to use the Automatic Token Importation (ATI) feature
to pull in registration data on demand from some central FOG where you
register everybody, but that also feels like a bit of a kludge to me and
we've certainly never tested it. See the ut_ati_script_interface man
page for details if you feel like pursuing that. On the plus side ATI
looks a lot like AMGH so it should be familiar.
Sun uses our badges as smartcards. When we are first badged the badging
office forwards their logs to some scripts that populate the enterprise
LDAP server(s) with the badge-id/token, and that server is used by AMGH
(it's posted on my blog as well, but it's fairly complex due to our
logic in determining the correct FOG for a user). You might find that
your enterprise server has other information that might help you
determine the correct FOG for a given user (in our case it's the campus
location or the user-specified preference, but in your case it might be
the user's department).
-Bob
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
