Jorg, Thanks for the feedback. I'm almost positive I ran "kioskuseradm extend" on both boxes and did NOT just copy /etc/passwd entries [I was successful doing an "extend" on a different FOG prior].
But, it's good to know at least how to fix the problem. Next time I run "extend" I'll know how to check that it really succeeded. Thanks again. Scott -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jörg Barfurth Sent: Wednesday, January 23, 2013 8:14 AM To: [email protected] Subject: EXT :Re: [SunRay-Users] "All kiosk accounts are in use" Hi Scott, Am 22.01.13 18:26, schrieb Nishimura, Scott L (ESS): > Additional info: > > 02 > /opt/SUNWkio/bin/kioskstatus -u utku200 > utku200: not active > > 01 > /opt/SUNWkio/bin/kioskstatus -u utku200 > utku200: not a kiosk account > > 01 > utku199:x:150199:102:KioskSessionServiceUser:/var/opt/SUNWkio/home/utk > u199:/bin/sh > utku200:x:150200:102:KioskSessionServiceUser:/var/opt/SUNWkio/home/utk > u200:/bin/sh > > 02 > utku199:x:150199:102:KioskSessionServiceUser:/var/opt/SUNWkio/home/utk > u199:/bin/sh > utku200:x:150200:102:KioskSessionServiceUser:/var/opt/SUNWkio/home/utk > u200:/bin/sh > > Both servers have intervening accounts defined in /etc/passwd that appear > between utku199 and utku200 [but not interfering with the contiguous UID > progression]. > This sounds as if the update on server 01 was made without properly using kioskuseradm extend (maybe by copying passwd file or entries?). In any case, kioskuseradm maintains its configuration metadata (the info shown by kioskuseradm show) in a separate place and that data was not updated when the extension accounts were added. kioskuseradm configuration is local to each host with no automatic replication of configuration or changes. > 02 > /opt/SUNWkio/bin/kioskuseradm leakcheck No lost Kiosk user accounts > found > > 01 > /opt/SUNWkio/bin/kioskuseradm leakcheck Stale Kiosk user entries: > utku200 > . > utku399 > > To fix this, should I delete all kiosk accounts and recreate or just delete > the ones that aren't recognized [200-399]? > The latter should be enough and can easily done by using kioskuseradm cleanup HTH - Jörg > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Nishimura, > Scott L (ESS) > Sent: Tuesday, January 22, 2013 8:37 AM > To: SunRay-Users mailing list > Subject: EXT :Re: [SunRay-Users] "All kiosk accounts are in use" > > Jorg, > > Your advice was spot on: "kioskuseradm show" revealed that, even though I > have 400 utkus defined in /etc/passwd, the output listed only 200. > > Do I have to delete the extra 200 kiosk accounts on 01 and re-run > "kioskuseradm extend"? Just run the "extend" command? > > Background > As I stated in the original problem description, I set these SRSs up with an > original allocation of 200 accounts. Later, I used "kioskuseradm extend" to > add 200 more [after first moving some recently-created accounts to different > UIDs so they didn't block my desired contiguous range for utku]. > > The reason I didn't think it was account-related was that, at the > time, all sessions were being directed to this SRS and I have 279. So > I reasoned that, if it was a kiosk allocation problem, I should have > seen it when I crossed the 200 threshold. I guess not all of the 279 > were connecting to the fully-loaded SRS > > I ran "kioskuseradm show" on a different FOG and it displayed the correct # > of kiosk sessions. I'm pretty sure I did the same "kioskuseradm extend" > command on both systems but obviously either I did not or something went > wrong on the second system. I guess part of my problem was when I ran the > "extend" command, my only method of verification was to look at /etc/passwd. > > Oh, and another interesting observation: the FOG with the problem has 2 > servers. 01 shows only 200 kiosk accounts. But 02 shows the correct 400. ?? > > -- 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 _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
