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. a new 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.


Thanks again for all your help,

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 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,  so this is as good as a time any. :)

The logic behind the 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 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
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 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.


On 3/1/10 11:58 AM, Liz Wendland wrote:

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 - 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!


Aaron Peeler
Program Manager
Virtual Computing Lab
NC State University

Reply via email to