Scott, AMGH is very easy and can give you the exact result you are
looking for. Perhaps not exactly the way you envision, but the result
will be the same. I think Bob D. has warned you against using the Sun
Ray Data Store. Early on, we all did that but soon discovered that for
"large" deployments with somewhat mobile users, i.e. lots of hotdesking,
the load created by utuser and other ut* utilities could slow down the
whole system. You wind up interrupting core processes at perhaps a busy
time.
SO, the architecture we are all suggesting is, in your case, 6 FOGs each
configured for a specific use case, a "landing zone" FOG to simply the
token registration process and a back end database for
token/username/host matching. I'd suggest OpenLDAP or MySQL or even
Postgre although I know very little about it. Is an Active Directory
available? That also would work for you. You mentioned NIS, that's also
a possibility, although a bit more complex as you'd need to create a
custom NIS map. I would craft my script to recognize "first time"
insertion of a token, i.e. it's not in the backend database, and gather
the username/host mapping at that time making the appropriate entries in
the backend database. This smooths the administrative burden of card
registration/maintenance. Finally, I would use the return home feature
of AMGH to return the user to the landing zone when the session is
closed. If you like the security offered by a registered card policy,
fine, enable it on the landing zone but ignore what SRSS is doing with
the tokens in the background. I know it's there, well maintained and
tempting, but just forget about it. Great for demos/POCs/etc but not
production.
I can contract to help with this implementation. Please contact me
offline to discuss.
Art Peck
Principal Consultant
Arthur H. Peck & Associates, LLC
[email protected]
[email protected] wrote:
Send SunRay-Users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.filibeto.org/mailman/listinfo/sunray-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of SunRay-Users digest..."
Today's Topics:
1. Re: More amgh and token questions (Scott L Riggen)
2. Re: More amgh and token questions (John Francis)
3. Re: More amgh and token questions (William Yang)
4. Re: More amgh and token questions (Bob Doolittle)
5. Re: More amgh and token questions (Scott L Riggen)
6. Re: More amgh and token questions (Bob Doolittle)
7. Re: sun ray subscription (Ivar Janmaat)
----------------------------------------------------------------------
Message: 1
Date: Fri, 05 Feb 2010 12:47:50 -0800
From: Scott L Riggen <[email protected]>
To: [email protected]
Subject: Re: [SunRay-Users] More amgh and token questions
Message-ID: <[email protected]>
Bob,
That helps some. Thanks for the information.
I don't see any issue on putting them in the same FOG since we are putting
users on there for a particular reason. The users don't expect things to be
the same....
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.
What sort of "token maintenance" do you need to do? None is required,
unless you utilize the registration information somehow.
The ldap server on the master has this information.
/opt/SUNWut/sbin $ sudo ./utuser -o | grep scottrig
Payflex.5011c7e600130100,,0,scottrig,Scott Riggen
My username is the 4th field. Thus on a token insert I was looking at writing
a script that would do something like.
Read token. Get username from ldap (utuser). Match a nis map with username to
get their machine. Switch based on the return from nis. I'd like to not have
to create a text file db to make this happen since it's one more thing to
create and store.
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. 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.
Scott
------------------------------
Message: 2
Date: Sat, 6 Feb 2010 08:02:35 +1100
From: John Francis <[email protected]>
To: SunRay-Users mailing list <[email protected]>
Subject: Re: [SunRay-Users] More amgh and token questions
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 6 February 2010 07:47, Scott L Riggen <[email protected]> wrote:
Bob,
That helps some. ?Thanks for the information.
I don't see any issue on putting them in the same FOG since we are putting
users on there for a particular reason. ?The users don't expect things to be
the same....
Not an AMGH expert by any stretch, but don't you really want to
separate your machine "groups" into separate FOGs and then decide
which FOG to send tokens to. So for e.g. you might have an
engineering FOG, a marketing FOG, etc.
--
Art Peck
Managing Partner & Principal Consultant
A rthur H. Peck & Associates, LLC
Cell: 904-614-7902 Skype: 904-638-5056
Email: [email protected] Website: http://artpeck.net
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
