From aff4690d1c6508b1a7d2311edabdeafc73049795 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 25 Jun 2013 15:23:46 -0400 Subject: webapp: Ensure that ssh keys generated for different directories on a server are always different. --- ...t_repository_on_the_server_don__39__t_work.mdwn | 30 ++++++++++++++++++++++ 1 file changed, 30 insertions(+) (limited to 'doc') diff --git a/doc/bugs/Use_a_git_repository_on_the_server_don__39__t_work.mdwn b/doc/bugs/Use_a_git_repository_on_the_server_don__39__t_work.mdwn index 0e950f360..a2fa6a9e5 100644 --- a/doc/bugs/Use_a_git_repository_on_the_server_don__39__t_work.mdwn +++ b/doc/bugs/Use_a_git_repository_on_the_server_don__39__t_work.mdwn @@ -12,3 +12,33 @@ Linux 64bit Please provide any additional information below. git and git-annex are available on the Remote Server +> While this bug report was about a server that did not get git-annex-shell +> installed in PATH (something trivially fixed by `apt-get install +> git-annex`), the comments below would like to turn this into a bug report about +> the error message "unknown UUID; cannot modify". All right then.. +> --[[Joey]] +> +> This can occur if a ssh key is locked down to use directory A, and a +> new repo is added in directory B which uses the same ssh key. Things will +> then fail when git-annex-shell rejects the attept to use directory B, and +> this results in the webapp displaying an internal server error of +> "unknown UUID; cannot modify" since NoUUID is retreived for the repo. +> +> In fact, I already dealt with this +> once in 79561774450c8abf7c2cb42b08575a3ca27010dc; it used to not use +> the directory name at all as part of the mangled hostname. Most of the +> "me too" responses" predate that fix. +> +> Now, this can only happen +> if the mangled hostname for directory A and B is the same. One way this can +> happen is if the directories are "annex" and "~/annex". In other words, +> I suspect that users are entering "annex" once, and "~/annex" another +> time, when setting up what they intend to be the same repo. Perhaps the +> first time something else fails (like the original problem of +> git-annex-shell not being in path), or they want to set it up again, +> and the next time the subtly different directory is entered. +> +> To fix this, +> `mangleSshHostName` would need to be changed to generate different mangled +> hostnames in all cases. Currently, it skips non-alpha-numeric +> characters in the directory. [[done]] --[[Joey]] -- cgit v1.2.3