Skip to content
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

Deploy uses a large number of SSH connections #57

Closed
tilsammans opened this issue Dec 5, 2013 · 4 comments
Closed

Deploy uses a large number of SSH connections #57

tilsammans opened this issue Dec 5, 2013 · 4 comments

Comments

@tilsammans
Copy link
Contributor

Just tried to deploy using Capistrano 3. First of all it's a very sweet release, I am so happy this has finally come out. Well done!!

The new style is using a large number of separate SSH connections which were being flagged as potentially abusive by my server's firewall. I am using the standard ufw limit setting for SSH:

ufw will deny connections if an IP address has attempted to initiate 6 or more connections in the last 30 seconds

which is definitely the case. When I remove the limit, Capistrano goes through.

I would really like to keep the limit in the firewall and somehow reduce/queue the number of connections Capistrano is using. Is there a way?

@leehambley
Copy link
Member

Actually this issue belongs to sshkit the backend driver that Capistrano uses to connect to all the servers. The reason we don't maintain a connection is for the sake of code simplicity, and the difficulty in identifying reliably a single target server.

That said, in the net-ssh backend driver, you could easily add some trivial memoization. The connections are opened here https://github.com/capistrano/sshkit/blob/master/lib/sshkit/backends/netssh.rb#L167.

The instance of backend is a new instance for every call to on(). Probably a level above (somewhere between dsl.rb and one of the coordinators/runners) you would have to memoize the call to produce the backend. I would imagine that https://github.com/capistrano/sshkit/blob/master/lib/sshkit/runners/abstract.rb#L18 is the place to do it.

I'd be concerned with handling reconnects, incase the connection failed, I'm not sure how that should work (or even, how much the runners, and coordiantors should know about the backends) Probably it would be sufficient to memoize in https://github.com/capistrano/sshkit/blob/master/lib/sshkit/runners/abstract.rb#L18 and have the netssh backend handle reconnecting if it needed to.

I'd take a patch if you can try it (master has one failing test relating to newlines) - I've pushed a proof of concept to the following branch: https://github.com/capistrano/sshkit/tree/memoize-backend

You can use that in your Gemfile with

gem "sskit", github: 'capistrano/sshkit', ref: 'memoize-backend'

I've asked @seanhandley if he would mind taking an active role in curing this weirdness. (it is weird, right!)

@leehambley
Copy link
Member

Closing this issue here, if someone wants to pick that up at SSHKit, let's take the discussion there where it belongs!

@tilsammans
Copy link
Contributor Author

Actually this issue belongs to sshkit

Oops, did not realise I was in the documentation repo.

@leehambley
Copy link
Member

no sweat :) try my SSHKit stuff, and if it works, or doesn't work, whatever - open up an issue there, and mention me and @seanhandley

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants