e213ef310f
* Fix minor FD leak in journal code. Closes: #754608 * direct: Fix handling of case where a work tree subdirectory cannot be written to due to permissions. * migrate: Avoid re-checksumming when migrating from hashE to hash backend. * uninit: Avoid failing final removal in some direct mode repositories due to file modes. * S3: Deal with AWS ACL configurations that do not allow creating or checking the location of a bucket, but only reading and writing content to it. * resolvemerge: New plumbing command that runs the automatic merge conflict resolver. * Deal with change in git 2.0 that made indirect mode merge conflict resolution leave behind old files. * sync: Fix git sync with local git remotes even when they don't have an annex.uuid set. (The assistant already did so.) * Set gcrypt-publish-participants when setting up a gcrypt repository, to avoid unncessary passphrase prompts. This is a security/usability tradeoff. To avoid exposing the gpg key ids who can decrypt the repository, users can unset gcrypt-publish-participants. * Install nautilus hooks even when ~/.local/share/nautilus/ does not yet exist, since it is not automatically created for Gnome 3 users. * Windows: Move .vbs files out of git\bin, to avoid that being in the PATH, which caused some weird breakage. (Thanks, divB) * Windows: Fix locking issue that prevented the webapp starting (since 5.20140707). # imported from the archive
44 lines
1.9 KiB
Markdown
44 lines
1.9 KiB
Markdown
ssh:// remotes are not special remotes. Perhaps it would be useful to have
|
|
a special remote that wraps a ssh:// remote? This would allow setting up a
|
|
ssh:// remote that can be enabled using the webapp's normal UI for enabling
|
|
special remotes.
|
|
|
|
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,
|
|
because new clients would have the central server added as their first
|
|
remote.
|
|
|
|
(It would help if one client paired with another new client, but
|
|
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]]
|