Scott L Riggen wrote:
Bob,
I went ahead and set back up the syslog stuff the sunray way.
Had to clobber our syslog stuff in the process.
My guess is that tonight when our cfengine stuff takes off it will put it back
the old way. I'm assuming once I get this debugged it won't matter where my
syslog stuff goes.
That's what everyone things, until they have a problem. :) Often it's
too late to tell what happened if syslog was disabled.
The logs rotate and take care of themselves, so it seems harmless and
prudent to leave the logging on. Just my 2c...
Switching is still busted. When I put in my two test cards (both pointing at hosts in different FOGs I still stay on whatever host the sunray happens to connect to when it gets back it's dhcp answer.
the only thing I see in messages is that amgh is yes but that it has nothing in
the reply. The DETAILS section shows Details=AMGH lookup library did not
provide any target AMGH hosts, AMGH_Target=*NONE*
Also the token says user.1265220350-7053 (what is this......?)
Feb 8 15:21:55 bender.cesa.opbu.xerox.com utauthd: [ID 118791 user.info]
Worker2 NOTICE: MTU = 1500
Feb 8 15:21:56 bender.cesa.opbu.xerox.com utdtsession: [ID 702911 user.info]
Add (5,user.1265220350-7053,normal)
Feb 8 15:21:58 bender.cesa.opbu.xerox.com utauthd: [ID 988467 user.info]
Worker2 NOTICE: SESSION_OK user.1265220350-7053
Feb 8 15:22:00 bender.cesa.opbu.xerox.com dtlogin[2736]: [ID 118685 user.info]
pam_sunray_amgh::[DPY=5] AMGH_SUMMARY: token=user.1265220350-7053, username=,
AMGH_Done?=NO(Local Session), Details=AMGH lookup library did not provide any
target AMGH hosts, AMGH_Target=*NONE*
Feb 8 15:22:02 bender.cesa.opbu.xerox.com utauthd: [ID 140345 user.info]
Worker4 NOTICE: DISCONNECT IEEE802.0003ba3c12dd, user.1265220350-7053 token
removed
What does "utuser -p user.1265220350-7053" report? Does it match the
"Payflex.*" name reported in your back_end_db file?
A token of the form "user.*" is the "logical" name for the token. That's
an arbitrary name assigned at registration time, and it will vary from
FOG to FOG for the same card. That's why you use "insert_token" for the
match instead of just "token". The purpose of the logical name is so
that you can "alias" cards together to access a session (e.g. in case
you lose a card, you can use utuser -ai to create an aliased card to
access the existing session). All aliased cards share the same logical
name within a given FOG (when you run with a registered-only policy).
-Bob
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users