better design

Avoids possible repeated password prompts, at the cost of a small bit of
locking complication.
This commit is contained in:
Joey Hess 2012-01-19 21:15:13 -04:00
parent 3783ccf252
commit e96726caa3

View file

@ -22,28 +22,22 @@ Simple, when performing various git annex command over ssh, in particular a mult
Slightly more elaborate design for using ssh connection caching: Slightly more elaborate design for using ssh connection caching:
* Per-uuid ssh socket in `.git/annex/ssh/user@host.socket` * Per-uuid ssh socket in `.git/annex/ssh/user@host.socket`
* Can be shared amoung concurrent git-annex processes. * Can be shared amoung concurrent git-annex processes as well as ssh
invocations inside the current git-annex.
* Also a lock file, `.git/annex/ssh/user@host.lock`.
Open and take shared lock before running ssh; store lock in lock pool.
(Not locking socket directly, because ssh might want to.)
* Run ssh like: `ssh -S .git/annex/ssh/user@host.socket -o ControlMaster=auto -o ControlPersist=yes user@host` * Run ssh like: `ssh -S .git/annex/ssh/user@host.socket -o ControlMaster=auto -o ControlPersist=yes user@host`
* At shutdown, enumerate all existing sockets, and on each: * At shutdown, enumerate all existing sockets, and on each:
1. Rename to .old (prevents various races) 1. Drop any shared lock.
2. `ssh -q -S .git/annex/ssh/user@host.old -o ControlMaster=auto -o ControlPersist=yes -O stop user@host` 2. Attempt to take an exclusive lock (non-blocking).
3. `ssh -q -S .git/annex/ssh/user@host.socket -o ControlMaster=auto -o ControlPersist=yes -O stop user@host`
(Will exit nonzero if ssh is not running on that socket.) (Will exit nonzero if ssh is not running on that socket.)
3. And then remove the socket. 4. And then remove the socket and the lock file.
* Do same *at startup*. Why? In case an old git-annex was interrupted * Do same *at startup*. Why? In case an old git-annex was interrupted
and left behind a ssh. May have moved to a different network and left behind a ssh. May have moved to a different network
in the meantime, etc, and be stalled waiting for a response from the in the meantime, etc, and be stalled waiting for a response from the
network, or talking to the wrong interface or something. network, or talking to the wrong interface or something.
(Ie, the reason why I don't use ssh connection caching by default.) (Ie, the reason why I don't use ssh connection caching by default.)
* This would stop ssh's used by a concurrently running git-annex,
but only after they finish servicing their current connection.
Could use locks to detect if another git-annex is using a ssh
socket, but concurrent git-annex is rare enough, and the impact small
enough (next ssh it runs needs to do a full connect), that
the locks are probably not justified. Could be added later if needed tho.
* Could also set ControlPersist to something like "1h", in order to
auto-terminate leftover ssh's when git-annex is ctrl-c'd or somehow
exits. When transferring big enough files that the next ssh doesn't
happen for an hour, the overhead of that ssh needing to reconnect is
not significant.
* User should be able to override this, to use their own preferred * User should be able to override this, to use their own preferred
connection caching setup. `annex.sshcaching=false` connection caching setup. `annex.sshcaching=false`