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.

* 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.

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




Reply via email to