A little more detail.
AMGH can't switch somebody based on their username until it knows their
username. It can't magically know this a-priori. Either it has to
determine it by prompting the user to enter their name, or you can
"teach" AMGH the username based on their token using your AMGH site
script. If you don't do the latter, it'll fall back on the former.
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:
insert_token=TOKEN_NAME username=USERNAME host=HOST
(for HA you can have multiple lines with the same TOKEN_NAME specifying
multiple HOSTs)
the TOKEN_NAME ought to have names in the format reported by utwho -c.
-Bob
Bob Doolittle wrote:
Scott L Riggen wrote:
Bob,
Yeah, I read the how-to and manual. It's still foreign to me. It
would help if I knew at what point things are executed.
This is covered in the "Technical Details for the Interminably
Curious" section of the How-To.
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.
What sort of "token maintenance" do you need to do? None is required,
unless you utilize the registration information somehow.
-Bob
I thought I had it working when I had it pointed to user. It seemed
silly to me that it would not switch the user until they had typed in
their login name. I think Token switching is where I really want to
be. I just don't see how the amgh script ties it all in. If I
wanted to write my own script what do I return so that it can switch
users to a particular FOG based on token install ?
In my configuration I currently have 3 (and might eventually have 4)
types of machine groups (But only 1 FOG). In the current SR3.1
install we are switching users to their correct group using a custom
Xsetup and utswitch. We switch users around because the machine
groups have a particular use such as regular users, special users,
qa, linux.
In the new 4.2 install I'd like to use amgh and I'm not sure if I
want 1 big failover group like I currently have or 4 smaller groups.
I like having 1 big FOG since it makes token maintenance a lot
easier. However, I might be mixing in some non-sparc machines and I
don't think I can have a mix in the same FOG.
I appreciate the response.
Regards,
Scott
Have you read my blog How-To?
This is all described in there:
http://blogs.sun.com/bobd
Look on the right frame for the link to the AMGH HOW-TO Guide.
NFS shared directory or rdist seem like good choices for keeping the
scripts synchronized.
-Bob
Scott L Riggen wrote:
First off I wanted to thank Willam Yang for all the help.
I adjusted amgh to use
/opt/SUNWutref/amgh/lib/libutamghref_token.so ->>
libutamghref_token.so.1
I also adjusted my file with the insert_token stuff and it seems to
be ok.
My question about the amgh stuff is.
If I wanted to create my own script and change amgh to use it at
what point does that get called. Can I somehow grab the token on
insert and lookup the desired host / FOG from something like a nis
map ? What does my script need to return in order to do some sort
of token_insert and move the users to the correct FOG ?
On tokens my question is more about having multiple masters (1 for
each FOG)
How are you keeping them all in sync (using scripts, etc)
Thanks for all the help so far. Sunrays and software can be a pain
but they also have alot of use with users moving all over the place :)
Regards,
Scott
Yep. And use insert_token= instead of token= since you are using
registered
tokens. Also you might need to use a different library or
script; it sounds
like from the filename of your library that you can only use
usernames with
that particular script.
_______________________________________________
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
