-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ProxyCommand support #227
ProxyCommand support #227
Conversation
b5ee7c9
to
025894b
Compare
NOTE This is just a simple wrapper which relies on the underlying support being added to train: inspec/train#227 Signed-off-by: Christian Becker <[email protected]>
025894b
to
3c9296f
Compare
…dy and Train::Transports::WinRM.wait_until_ready Signed-off-by: Christian Becker <[email protected]>
Signed-off-by: Christian Becker <[email protected]>
3c9296f
to
ee33440
Compare
@cbeckr - Thank you so much for your first contribution! Welcome to the family :) This looks great and I will test it out soon and get back to you! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work on this. Just a minor potential caching issue.
@@ -113,7 +114,7 @@ def wait_until_ready | |||
message: "Waiting for SSH service on #{@hostname}:#{@port}, " \ | |||
"retrying in #{delay} seconds", | |||
) | |||
execute(PING_COMMAND.dup) | |||
run_command(PING_COMMAND.dup) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we want to use the run_command_via_connection
here instead. The run_command has the potential for caching which could cause unexpected results.
@@ -80,7 +80,7 @@ def wait_until_ready | |||
retry_limit: @max_wait_until_ready / delay, | |||
retry_delay: delay, | |||
) | |||
execute(PING_COMMAND.dup) | |||
run_command(PING_COMMAND.dup) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above, I think it would be safer to run_command_via_connection
I think this looks good for now, I plan on updating all the "wait_until_ready" flags as its like this on other transports also. |
NOTE This is just a simple wrapper which relies on the underlying support being added to train: inspec/train#227 Signed-off-by: Christian Becker <[email protected]>
NOTE This is just a simple wrapper which relies on the underlying support being added to train: inspec/train#227 Signed-off-by: Christian Becker <[email protected]>
This adds basic support for connecting via jump hosts.