diff options
Diffstat (limited to 'doc/design/assistant')
-rw-r--r-- | doc/design/assistant/blog/day_70__adding_ssh_remotes.mdwn | 66 |
1 files changed, 66 insertions, 0 deletions
diff --git a/doc/design/assistant/blog/day_70__adding_ssh_remotes.mdwn b/doc/design/assistant/blog/day_70__adding_ssh_remotes.mdwn new file mode 100644 index 000000000..29a6737bc --- /dev/null +++ b/doc/design/assistant/blog/day_70__adding_ssh_remotes.mdwn @@ -0,0 +1,66 @@ +Today I built the UI in the webapp to set up a ssh or rsync remote. + +This is the most generic type of remote, and so it's surely got the most +complex description. I've tried to word it as clearly as I can; suggestions +most appreciated. Perhaps I should put in a diagram? + +[[!img /assistant/addsshserver.png]] + +The idea is that this will probe the server, using ssh. If `git-annex-shell` +is available there, it'll go on to set up a full git remote. If not, it'll +fall back to setting up a rsync special remote. It'll even fall all the way +back to using `rsync://` protocol if it can't connect by ssh. So the user +can just point it at a server and let it take care of the details, +generally. + +The trickiest part of this will be authentication, of course. I'm relying +on ssh using `ssh-askpass` to prompt for any passwords, etc, when there's +no controlling terminal. But beyond passwords, this has to deal with ssh +keys. + +I'm planning to make it check if you have a ssh key configured already. If +you do, it doesn't touch your ssh configuration. I don't want to get in the +way of people who have a manual configuration or are using MonkeySphere. + +But for a user who has never set up a ssh key, it will prompt asking if +they'd like a key to be set up. If so, it'll generate a key and configure +ssh to only use it with the server.. and as part of its ssh probe, that key +will be added to `authorized_keys`. + +(Obviously, advanced users can skip this entirely; `git remote add +ssh://...` still works..) + +---- + +Also today, fixed more UI glitches in the transfer display. I think +I have them all fixed now, except for the one that needs lots of javascript +to be written to fix it. + +Amusingly, while I was working on UI glitches, it turned out that all the +fixes involved 100% pure code that has nothing to do with UI. The UI was +actually just exposing bugs. + +For example, closing a running transfer +had a bug that weirdly reordered the queue. This turned out to be +due to the transfer queue actually maintaining two versions of the queue, +one in a TChan and one a list. Some unknown bugs caused these to get out of +sync. That was fixed very handily by deleting the TChan, so there's only +one copy of the data. + +I had only been using that TChan because I wanted a way to block while the +queue was empty. But now that I'm more comfortable with STM, I know how +to do that easily using a list: + +[[!format haskell "" + getQueuedTransfer q = atomically $ do + sz <- readTVar (queuesize q) + if sz < 1 + then retry -- blocks until size changes + else ... +""]] + +Ah, the times before [STM](http://en.wikipedia.org/wiki/Software_transactional_memory) +were dark times indeed. I'm writing more and more STM code lately, building +up more and more complicated and useful transactions. If you use threads and +don't know about STM, it's a great thing to learn, to get out of the dark ages +of dealing with priority inversions, deadlocks, and races. |