Calyptos: deployments via Bastion server

[dmccue]

In the below yaml file we require support for 2 nic deployments where the private nic is inaccessible from the calyptos client

https://eucalyptus.atlassian.net/secure/attachment/25625/environment_2nic.yml

e.g.

calyptos validate -e environment_2nic.yml
[VALIDATION FAILED   ] Ping to 10.105.10.67
[VALIDATION FAILED   ] Ping to 10.105.10.73
[VALIDATION FAILED   ] Ping to 10.105.1.209
[VALIDATION FAILED   ] Ping to 10.105.10.70
[VALIDATION FAILED   ] Ping to 10.105.10.78
[VALIDATION PASSED   ] Ping to 10.104.10.51
[VALIDATION FAILED   ] Ping to 10.105.10.44
--------------------------------------------------
Total successful pings: 1
Total failed pings: 6
--------------------------------------------------
Unable to reach all hosts, validation failed.

Can calyptos copy itself to the clc and run from there without prior setup or alternatively for each IP can we specify a public and private IP and have a property specifying which interface calyptos will attempt to connect over?

[viglesiasce]

@dmccue this is already supported you just need to run Calyptos from a machine that has access to the registration network.

The assumption is that in most cases the deployment machine will have access to the registration network and not necessarily the public network. cc @lwade to get his thoughts.

That having been said, I think we can make this happen and @bigschwan has already looked at this so will let him comment on the approach and coordinate with you on requirements and configuration.

[nephomaniac]

@viglesiasce for other setups with isolated networks (usually isolated cluster/AZ networks) I had played with adding options to define an ssh proxy host for each isolated network. The traffic to these isolated networks is then sudo-ssh-tunneled over auto-created connections through the proxy hosts to reach the specific nodes/networks. (This is similar to what we do in eutester for testing isolated clouds).
In almost all cases there's been a machine with access to the reg network so I didn't add this to the project, but can if it's desirable? Another temporary option would be to add the proxy options/cli-args to something like this script/wrapper I use to test calyptos branches/changes in our CI by running everything remotely... https://github.com/bigschwan/adminapi/blob/master/cloud_admin/cloudview/remote_calyptos.py Cheers, -M

[dmccue]

@bigschwan @viglesiasce I've been thinking that what's needed is bastion server support. There could be a workaround to use the ProxyCommand functionality but that will need to be setup for each host, maybe we could get ./calyptos bastion -e environment.yml which would read the yml file and produce the text that can be manually placed in ~/.ssh/config. There's a dependency on netcat installation on the bastion server to support this. http://backdrift.org/transparent-proxy-with-ssh

This would mean that calyptos could still be run from a remote workstation over VPN and not require much code alteration. The downside is that the validate code will need updated from ICMP (ping) test to a simple ssh test e.g. ssh 'uptime'.

[dmccue]

I've written a wrapper that performs the bastion function by copying across the environment.yml, installing calyptos and dependencies then logs locally. Just showing the use case not intended to merge. https://gist.github.com/1e64731ca5ae70e45614

[nephomaniac]

hi @dmccue @viglesiasce, Can you look over and/or test the changes in the 'gateway' branch. Attempting to use fabric's native gateway option. Using the -g, --gateway option to provide a hostname/ip should allow you to give a gateway host which all the ssh connections will be routed through.

https://github.com/eucalyptus/calyptos/tree/gateway

I've tried the following and sniffed the network to make sure traffic is routed, but haven't tried on a truly isolated network to test for the 'gotchas'. Example: calyptos provision -e environment.yml -p foobar -g 10.111.1.44

Thanks! -M