Am 18.01.13 21:47, schrieb Nishimura, Scott L (ESS):
Both servers have 400 kiosk accounts provisioned. It's been this way
for months. No recent changes except server1 was patched the
previous week.
The UIDs are allocated in a contiguous range.
I set up the servers with 200 accounts originally. Then, other
programs took the next available UIDs so I had to move their UIDs to
#s below my utkus so I could expand the group to 400 in a contiguous
range. So if there was a UID problem, I would have expected it to
occur at 201, not 279.
BTW: With a local outage (restart all kiosk sessions on the host), you
can move and resize (grow or shrink) the kiosk uid range to an arbitrary
place in the uid space. If you create a 'guard' account at
kiosk-base-uid + 10000, you can prevent that the range is restricted by
other programs accidentally.
Prstat showed no unusual loading. I did not seem to be
resource-bound.
This is my typical patching scenario: offload all sessions to
server1 while doing Live Update and patching the ABE on server2.
Reboot, enable connections on server2 and repeat for server1. So I
always end up with one SRS handling all sessions and I've never had a
problem before.
This time, TCs started seeing
Error starting kiosk session: All kiosk accounts are in use.
/var/opt/SUNWut/log/messages showed
Jan 18 03:30:58 bctlsu01 dtlogin[11111]: [ID 476860 user.error]
pam_kiosk: pam_sm_authenticate: Allocating a Kiosk user failed:
Account is currently reserved
That is the error related to the preceding message. And yes, this would
indicate that all kiosk accounts are bound to a display number.
Jan 18 03:08:01 bctlsu01 utauthd: [ID 702911 user.info] read_config_file():
Could not open config file (/etc/opt/SUNWut/utadmin.conf), error 24
Jan 18 03:08:01 bctlsu01 utauthd: [ID 702911 user.info] ut_openDsConnection:
Could not read config file (/etc/opt/SUNWut/utadmin.conf)
Jan 18 03:08:01 bctlsu01 utauthd: [ID 501976 user.error] Crypto: FAIL to check
key status: Cannot connoct to Data Store: File access error
Jan 18 03:08:01 bctlsu01 utauthd: [ID 926371 user.info] Worker28 UNEXPECTED:
Crypto: Failed to update key status.
Jan 18 03:08:01 bctlsu01 utauthd: [ID 638413 user.info] Worker28 NOTICE:
Denying 155.104.201.253: key validation failed
That occurs much earlier in the connection lifecycle. If it reoccurs, it
is a serious problem that would prevent any client from connecting. If
this is a recurring problem, open a case with Oracle support. If it
occurred only once, it may be some sort of file system fluke. The
failing kiosk session (20 minutes later) got past this, apparently
without a hitch.
I can't tell whether it was trying to allocate the same kiosk account
or whether it was trying different ones.
So was it ultimately a data store error or a kiosk session allocation
error? Since I had plenty of unused kiosk sessions, I'm leaning
towards the data store issue.
The "Error starting kiosk session: All kiosk accounts are in use." is a
purely kiosk message and has no direct relation to the data store.
To view your kiosk account configuration look at
# /opt/SUNWkio/bin/kioskuseradm show
To check the status of kiosk session allocation, look at
# /opt/SUNWkio/bin/kioskuseradm status
If that shows surprising numbers of session in use, use
# /opt/SUNWkio/bin/kioskuseradm status -v
to get full detail and use output of
# /opt/SUNWut/sbin/utsession -p
or
# /opt/SUNWut/bin/utwho -a
to correlate the display numbers to SRS sessions.
If there is a significant number of kiosk accounts that are bound to a
display/session that does not exist any more, then you should also open
a case with Oracle support.
The utadmin.conf file in question is now readable but I didn't try
when the problem was occurring. Even though that error occurred
first in the log, I'm inclined to think it was a symptom, not a
cause.
Without more data store and kiosk error messages that change the
picture, I'm inclined to think it is completely unrelated.
Searching for the full string
"FAIL to check key status" crypto
Yielded no results.
Where did you search?
Best Regards
- Jörg Barfurth
--
Jörg Barfurth http://blogs.oracle.com/joergb
Disclaimer: I am employed by Oracle. The statements and opinions
expressed here are my own and do not necessarily represent those
of Oracle Corporation.
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
