Implement SSH connection caching and sharing for Conch
| Newsgroups | gmane.comp.python.twisted.bugs |
|---|---|
| Message-ID | <[email protected]> |
New submission from exarkun <[email protected]>: It is possible to reuse already-established SSH connections to satisfy new SSH connection attempts. Conch should provide APIs and command line options to allow this (and to explicitly avoid it). Prior to #3498, Conch included an attempt at this. The implementation mostly worked, but had little test coverage and had several known issues. This re-implementation of the feature should avoid those problems. In particular, it should have a test suite providing (at least) complete line execution coverage and should avoid these specific misbehaviors: * (#716) If the master connection being cached and shared is lost, if a process automatically reconnects it, it should be sure that the new connection can properly be shared by other processes. * (#3497) If two potential master connections are created near the same time, there should be no race in setting up whatever externally visible state (eg, a unix socket) is necessary to allow one of those connections to be shared. * (#3497) The code should not assume `IListeningPort.stopListening` always returns a `Deferred`. * (#3497) The master connection should be identified both by IP address and hostname, so that another connection is set up using either of those as input can re-use it. * (#3497) Any errors with the master connection should be reported to any other connections sharing it. * (#3497) Any externally visible state (eg, a unix socket) should be cleaned up when the master connection goes away. * (#3483) Any unix socket should be created in a directory with carefully controlled permissions to ensure its security. #3497 details many of the ways in which these misbehaviors could be triggered using the old implementation. ---------- Type : enhancement Component: conch Keywords : Priority : normal Nosy : ---------- http://twistedmatrix.com/trac/ticket/3797