I don't think we can/should depend on the 'who' output. I've experienced
some cases where 'who' cmd reported someone, but in-fact no-one was
connected. Maybe it's due to a zombie or orphaned process, I don't know.
But in any case I think the best thing is to first update the regex to
handle the case brought up, then plan moving to the OS modules - if needed.
Aaron
--On February 12, 2009 4:54:56 PM -0500 Andy Kurth <andy_ku...@ncsu.edu>
wrote:
Thanks for figuring out why the regex wasn't working. You're right,
check_connection() needs to be modularized and moved to OS modules.
Brian Bouterse wrote:
Problem 1) The linux portions of the utils.pm::check_connection()
function currently use two checks, one 'netstat' command check and one
'who' command check. With IPv6 hosts, the netstat returned lines don't
look the same, therefore the regex on the netstat return doesn't stand a
chance of working. I'm concerned that this type of regex is a losing
battle. What do you all think? The who seems to work more reliable,
could we just take netstat out?
Seems fine to me but modifications to the 'who' output checking will need
to be done. check_connection() is currently only searching the 'who'
output for the reservation username. netstat is checking for any
established connection to port 22.
If 'who' is the only method used, I think you would need to check its
output for *any* logged in user. An example where it would certainly
fail if the current 'who' code was used alone would be for images
configured with user groups. Anyone in the user group may be logged in
rather than the reservation user. It wouldn't catch this.
We definitely want to error on the lenient side. It may be safer to keep
both but loosen up the regex to something like this:
/tcp.*($ipaddress:22)\s+.*(ESTABLISHED)/
Problem 2) When a reservation is made, VCL gives us a username,
password, and an IP to log in with. We logon to the web portal with the
'admin' username, but when VCL goes to determine if the user has logged
in yet, it checks for the user "administrator". Why are they different?
How do we get it to use the same username that was given to the user?
This is due to the bug I noted earlier. If you make a Windows imaging
reservation, the username is always Administrator. If you make a Linux
imaging reservation, the username is always the normal reservation login
name (user.unityid).
reserved.pm is only checking the forimaging flag in order to determine
which username to pass to check_connection(). It should be checking both
the forimaging flag and the OS.
Current (bad):
if ($forimaging==1) {
check_connection(user='Administrator');
}
else {
check_connection(user=$user_unityid);
}
Should be:
if ($forimaging==1 && OS==Windows) {
check_connection(user='Administrator');
}
else {
check_connection(user=$user_unityid);
}
Hope this helps,
Andy
Aaron Peeler
OIT Advanced Computing
College of Engineering-NCSU
919.513.4571
http://vcl.ncsu.edu
