I have a pair of SRSs. Server2 was offline [utadm -f] and had no sessions on it [we were getting ready to patch]. Server1 was online and had every session [279].
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. 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 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 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 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. Searching for the full string "FAIL to check key status" crypto Yielded no results. Any ideas? Thanks. Scott _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
