webapp: When setting up a ssh remote, record it using initremote, so that it can be easily enabled elsewhere.

This is the capstone in making the webapp remember ssh remotes
so they can be easily enabled in other clones of the repository.

Currently, the user will need to enter a password to enable the ssh remote,
but everything else is filled in automatically.

This commit was sponsored by Peter Lloyd.

Assistant/WebApp/Configurators/Ssh.hs

@@ -517,21 +517,32 @@ prepSsh' needsinit origsshdata sshdata keypair a = sshSetup (mkSshInput origsshd
 
 makeSshRepo :: SshData -> Handler Html
 makeSshRepo sshdata
-	| onlyCapability sshdata RsyncCapable = setupCloudRemote TransferGroup Nothing go
+	| onlyCapability sshdata RsyncCapable = setupCloudRemote TransferGroup Nothing mk
-	| otherwise = makeSshRepoConnection go
+	| otherwise = makeSshRepoConnection mk setup
   where
-	go = makeSshRemote sshdata
+	mk = makeSshRemote sshdata
+	-- Record the location of the ssh remote in the remote log, so it
+	-- can easily be enabled elsewhere using the webapp.
+	setup r = do
+		m <- readRemoteLog
+		let c = fromMaybe M.empty (M.lookup (Remote.uuid r) m)
+		let c' = M.insert "location" (genSshUrl sshdata) $
+			M.insert "type" "git" $
+			M.insert "name" (fromMaybe (Remote.name r) (M.lookup "name" c)) c
+		configSet (Remote.uuid r) c'
 
-makeSshRepoConnection :: Annex RemoteName -> Handler Html
+makeSshRepoConnection :: Annex RemoteName -> (Remote -> Annex ()) -> Handler Html
-makeSshRepoConnection a = setupRemote postsetup TransferGroup Nothing a
+makeSshRepoConnection mk setup = setupRemote postsetup TransferGroup Nothing mk
   where
-	postsetup u = do
+	postsetup r = do
 		liftAssistant $ sendRemoteControl RELOAD
-		redirect $ EditNewRepositoryR u
+		liftAnnex $ setup r
+		redirect $ EditNewRepositoryR (Remote.uuid r)
 
 makeGCryptRepo :: KeyId -> SshData -> Handler Html
-makeGCryptRepo keyid sshdata = makeSshRepoConnection $ 
+makeGCryptRepo keyid sshdata = makeSshRepoConnection mk (const noop)
-	makeGCryptRemote (sshRepoName sshdata) (genSshUrl sshdata) keyid
+  where
+	mk = makeGCryptRemote (sshRepoName sshdata) (genSshUrl sshdata) keyid
 
 getAddRsyncNetR :: Handler Html
 getAddRsyncNetR = postAddRsyncNetR

Assistant/WebApp/MakeRemote.hs

@@ -31,13 +31,13 @@ import Utility.Yesod
  - This includes displaying the connectionNeeded nudge if appropariate.
  -}
 setupCloudRemote :: StandardGroup -> Maybe Cost -> Annex RemoteName -> Handler a
-setupCloudRemote = setupRemote $ redirect . EditNewCloudRepositoryR
+setupCloudRemote = setupRemote $ redirect . EditNewCloudRepositoryR . Remote.uuid
 
-setupRemote :: (UUID -> Handler a) -> StandardGroup -> Maybe Cost -> Annex RemoteName -> Handler a
+setupRemote :: (Remote -> Handler a) -> StandardGroup -> Maybe Cost -> Annex RemoteName -> Handler a
 setupRemote postsetup defaultgroup mcost getname = do
 	r <- liftAnnex $ addRemote getname
 	liftAnnex $ do
 		setStandardGroup (Remote.uuid r) defaultgroup
 		maybe noop (Config.setRemoteCost (Remote.repo r)) mcost
 	liftAssistant $ syncRemote r
-	postsetup $ Remote.uuid r
+	postsetup r

debian/changelog

@@ -9,6 +9,8 @@ git-annex (5.20140518) UNRELEASED; urgency=medium
     and enableremote setups up a remote using its stored location.
   * webapp: Support for enabling known git repositories on ssh servers.
     The repository must have been added using initremote.
+  * webapp: When setting up a ssh remote, record it using initremote,
+    so that it can be easily enabled elsewhere.
 
  -- Joey Hess <joeyh@debian.org>  Mon, 19 May 2014 15:59:25 -0400
 

doc/todo/ssh_special_remote.mdwn

@@ -7,15 +7,26 @@ Enabling such a special remote would just make a regular git remote, so
 there would be no need to implement the methods to get/put data. (Although
 it might need to provide stubs to appease the compiler.)
 
+> Above is done. The command line interface in initremote and enableremote
+> is not too easy or perhaps useful, but it works great in the webapp.
+> --[[Joey]]
+
 It could optionally embed the ssh private key into the git-annex branch as
 a credential, for when you want anyone who has access to the git repo to be
 able to use the (locked-down) git-annex-shell on that server.
 
+> Leaving this todo open for this ssh private key embedcreds part.
+> I think it makes sense to do, but it it probably not too easy.
+> ([[webapp_ssh_setup_should_work_with_locked_down_git-annex-shell_account]]
+> needs to be fixed first). --[[Joey]]
+
+[[!meta title="remember ssh remote including optionally ssh key"]]
+
+----
+
 I am on the fence about whether this would be useful, and would appreciate
 use cases.
 
----
-
 One use case I was thinking about was a LAN with a central server, with a
 shared account with a git-annex repository on it. But then I realized this
 wouldn't really help set up git-annex in that situation, most of the time,
@@ -28,3 +39,6 @@ that is unncessarily round-about most of the time.)
 It might help in a more complex situation, where the LAN is not the whole
 network an a client might come onto the LAN already knowing about the
 central server there. --[[Joey]]
+
+A very compelling use case is switching from XMPP to a ssh server,
+and wanting to make it easy for users. --[[Joey]]