Sure. Basically both of these are working with an existing campus
environment which prevents remote root login over ssh. More detailed
answers inline
On 3/1/10 1:52 PM, Liz Wendland wrote:
Hi Aaron,
Thanks for your excellent description of how this should work. That
is very helpful. I hope you don't mind a couple more questions:
* Why are there two SSL ports required? For Linux at least I believe
that sshd can be restarted without severing current connections.
two ssh ports - historically we use a different ssh port for remote lab
machine management to cut done on the brute force sshd attempts. So it
was working with an existing lab machine configuration, set-up many
moons ago.... Then vclclientd is starting a sshd process with a
customized sshd_config to list on the default port 22 and a custom
AllowUsers directive(the requesting user).
* Why is there a requirement to run the vclclientd on the Client
computer? In other Linux modules we just ssh in and grant/revoke user
access with no such client running. I guess I'm just wondering why the
physical, lab case is different than the vm case.
vclclientd's purpose was to work around the need to have root login
enabled through ssh - this is also a reason for the non-root user
vclstaff account. Normal policy for our *nix lab machienes is to disable
root login for ssh. So vclclientd is running as root on each of the
machines and can make the necessary changes based on the
/home/vclstaff/clientdata file.
Lab.pm(or a new Lab.pm) could certainly be changed to login as root and
do the same actions as vclclientd, it would definitely be easier. This
was just our implementation based on our campus restrictions.
Aaron
Thanks again for all your help,
Liz
On 3/1/10 12:24 PM, Aaron Peeler wrote:
Hi Liz,
Just to clarify there are two things mentioned here that I'd like to
separate.
One is the provisioning of physical machines, this would include
using xcat.pm or some other provisioning module to load an image,
capture an image and broker access. Today we've only done/supported
xCAT, but there are a few other Bare-metal or physical machine
"deployers" available.
But I think at this time your more interested is the standalone lab
machines that can be used after "walk-in" hours, etc.
I need to document the Lab.pm, so this is as good as a time any. :)
The logic behind the Lab.pm is to only broker access to the
standalone lab machine.
There are four main parts needed to broker access:
1) an non-root account called vclstaff on the target machine.
2) ssh identity key for vclstaff that the vcl management node will
use to ssh into
3) ssh running on port 24
4) vclclientd running on the target standalone machine/s
Currently the Lab.pm and vclclientd only supports linux(rhel distros,
solaris) at some point we'd like to address standalone windows lab
machines as well.
Here is the flow.
1) User request lab machine image.
2) management node picks up the request
3) via ssh listening on port 24 on the remote lab machine.
vcld confirms the machine is up/accessible and vclclientd is running
4) vcld writes the following to /home/vclstaff/clientdata
state(new|timeout)
userid
remoteIP
5) vcld writes "1" to /home/vclstaff/flag to trigger vclclientd to do
something
6) vclclientd perl daemon polling /home/vclstaff/flag, sees the 1 and
processes the request based on the "state" in the clientdata file. by
opening or closing ssh on port 22, etc
The vclclientd and Lab.pm is pretty basic and hasn't been touched in
a awhile, but we are using it to broker access to about ~200
standalone linux and solaris lab machines.
Aaron
On 3/1/10 11:58 AM, Liz Wendland wrote:
Hi,
I know that the ability to reserve physical machines using VCL
exists. " VCL can also broker access to standalone machines such as
a lab computers on a university campus." I see there is a
provisioning module - Lab.pm. Are there any instructions on how to
get this set up? Why is a "VCLClient" required to run on the lab
machines? I was thinking that all one would need to do is to grant
and revoke access for users on the physical machine. Is this
hopelessly naive?
Thanks for any additional information!
Liz
--
Aaron Peeler
Program Manager
Virtual Computing Lab
NC State University
aaron_pee...@ncsu.edu
919-513-4571
