Page MenuHomePhabricator

Prepare SSH connections for proxying
ClosedPublic

Authored by epriestley on Jan 28 2015, 5:59 PM.
Tags
None
Referenced Files
F13345809: D11541.diff
Fri, Jun 21, 11:36 AM
F13313174: D11541.diff
Tue, Jun 11, 7:33 AM
F13299917: D11541.diff
Fri, Jun 7, 8:35 AM
F13281533: D11541.diff
Sun, Jun 2, 10:54 AM
F13269052: D11541.diff
Wed, May 29, 5:44 AM
F13256269: D11541.id27765.diff
Sat, May 25, 10:49 AM
F13252363: D11541.diff
Sat, May 25, 1:18 AM
F13239000: D11541.id27765.diff
May 21 2024, 11:16 PM
Subscribers
Tokens
"Mountain of Wealth" token, awarded by btrahan.

Details

Reviewers
btrahan
Maniphest Tasks
Restricted Maniphest Task
Commits
Restricted Diffusion Commit
rP9b359affe7b5: Prepare SSH connections for proxying
Summary

Ref T7034.

In a cluster environment, when a user connects with a VCS request over SSH (like git pull), the receiving server may need to proxy it to a server which can actually satisfy the request.

In order to proxy the request, we need to know which repository the user is interested in accessing.

Split the SSH workflow into two steps:

  1. First, identify the repository.
  2. Then, execute the operation.

In the future, this will allow us to put a possible "proxy the whole thing somewhere else" step in the middle, mirroring the behavior of Conduit.

This is trivially easy in git and hg. Both identify the repository on the commmand line.

This is fiendishly complex in svn, for the same reasons that hosting SVN was hard in the first place. Specifically:

  • The client doesn't tell us what it's after.
  • To get it to tell us, we have to send it a server capabilities string first.
  • We can't just start an svnserve process and read the repository out after a little while, because we may need to proxy the request once we figure out the repository.
  • We can't consume the client protocol frame that tells us what the client wants, because when we start the real server request it won't know what the client is after if it never receives that frame.
  • On the other hand, we must consume the second copy of the server protocol frame that would be sent to the client, or they'll get two "HELLO" messages and not know what to do.

The approach here is straightforward, but the implementation is not trivial. Roughly:

  • Start svnserve, read the "hello" frame from it.
  • Kill svnserve.
  • Send the "hello" to the client.
  • Wait for the client to send us "I want repository X".
  • Save the message it sent us in the "peekBuffer".
  • Return "this is a request for repository X", so we can proxy it.

Then, to continue the request:

  • Start the real svnserve.
  • Read the "hello" frame from it and throw it away.
  • Write the data in the "peekBuffer" to it, as though we'd just received it from the client.
  • State of the world is normal again, so we can continue.

Also fixed some other issues:

  • SVN could choke if repository.default-local-path contained extra slashes.
  • PHP might emit some complaints when executing the commit hook; silence those.
Test Plan

Pushed and pulled repositories in SVN, Mercurial and Git.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

epriestley retitled this revision from to Prepare SSH connections for proxying.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added a reviewer: btrahan.
epriestley added a task: Restricted Maniphest Task.

Hopefully, this was the hard part.

btrahan edited edge metadata.
btrahan added inline comments.
scripts/repository/commit_hook.php
4–11

Huh. Whoda thunk it.

This revision is now accepted and ready to land.Jan 28 2015, 6:10 PM
This revision was automatically updated to reflect the committed changes.