| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
a remote ssh server to set environment variables in an alternative way that works with the non-POSIX fix shell, as well as POSIX shells.
|
| |
|
|
|
|
| |
git-annex-shell does not need a pty, so this speeds things up.
Also, it may avoid weird misconfigured systems that try to run screen or
tmux on every ssh login from doing so.
|
| |
|
|
|
|
|
| |
This reverts commit 07ab0b85ce375c1882e13780e525aba8918c6fdf.
Bug was fixed in -2 of debian package, and is fixed upstream
(unsure what upstream release specificically)
|
| |
|
|
|
| |
This avoids running into it for new setups, but does not transition old
setups. Just a quick fix; I hope to get ssh fixed.
|
| |
|
|
| |
world writable when writing to those files, as that can make ssh refuse to use them, if it allows another user to write to them.
|
| |
|
|
| |
it to the configuration for any ssh remotes previously created by the assistant. This avoids repeated prompts by ssh if the host key changes, instead syncing with such a remote will fail. Closes: #732602
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Improved probing the remote server, so it gathers a list of the
capabilities it has. From that list, we can determine which types
of remotes are supported, and display an appropriate UI.
The new buttons for making gcrypt repos don't work yet, but the old buttons
for unencrypted git repo and encrypted rsync repo have been adapted to the
new data types and are working.
This commit was sponsored by David Schmitt.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This includes recovery from the ssh-agent problem that led to many reporting
http://git-annex.branchable.com/bugs/Internal_Server_Error:_Unknown_UUID/
(Including fixing up .ssh/config to set IdentitiesOnly.)
Remotes that have no known uuid are now displayed in the webapp as
"unfinished". There's a link to check their status, and if the remote
has been set annex-ignore, a retry button can be used to unset that and
try again to set up the remote.
As this bug has shown, the process of adding a ssh remote has some failure
modes that are not really ideal. It would certianly be better if, when
setting up a ssh remote it would detect if it's failed to get the UUID,
and handle that in the remote setup process, rather than waiting until
later and handling it this way.
However, that's hard to do, particularly for local pairing, since the
PairListener runs as a background thread. The best it could do is pop up an
alert if there's a problem. This solution is not much different.
Also, this solution handles cases where the user has gotten their repo into
a mess manually and let's the assistant help with cleaning it up.
This commit was sponsored by Chia Shee Liang. Thanks!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When setting up a dedicated ssh key to access the annex on a host,
set IdentitiesOnly to prevent the ssh-agent from forcing use of a different
ssh key.
That behavior could result in unncessary password prompts. I remember
getting a message or two from people who got deluged with password
prompts and I couldn't at the time see why.
Also, it would prevent git-annex-shell from being run on the remote host,
when git-annex was installed there by unpacking the standalone tarball,
since the authorized_keys line for the dedicated ssh key, which sets
up calling git-annex-shell when it's not in path, wouldn't be used.
This fixes
http://git-annex.branchable.com/bugs/Internal_Server_Error:_Unknown_UUID
but I've not closed that bug yet since I should still:
1. Investigate why the ssh remote got set up despite being so broken.
2. Make the webapp not handle the NoUUID state in such an ugly way.
3. Possibly add code to fix up systems that encountered the problem.
Although since it requires changes to .ssh/config this may be one for
the release notes.
Thanks to TJ for pointing me in the right direction to understand what
was happening here.
|
| |
|
|
| |
Fix comment to not make cpp unhappy
|
| |
|
|
| |
are always different.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
on server
|
| |
|
|
|
| |
I think I've been looking for that function for some time.
Ie, I remember wanting to collapse Just Nothing to Nothing.
|
| |
|
|
| |
name, so that a locked down ssh key for one repository is not re-used when setting up additional repositories on the same server.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
assistant: Work around horrible, terrible, very bad behavior of
gnome-keyring, by not storing special-purpose ssh keys in ~/.ssh/*.pub.
Apparently gnome-keyring apparently will load and indiscriminately use such
keys in some cases, even if they are not using any of the standard ssh key
names. Instead store the keys in ~/.ssh/annex/, which gnome-keyring will
not check.
Note that neither I nor #debian-devel were able to quite reproduce this
problem, but I believe it exists, and that this fixes it. And it certianly
won't hurt anything..
|
| |
|
|
|
|
|
| |
not force a command.
Without a forced command, SSH_ORIGINAL_COMMAND is not set.
So instead, in this case, run $@
|
| |
|
|
|
|
|
|
|
| |
detection of appropriate build flags.
The only thing lost is ./ghci
Speed: make fast used to take 20 seconds here, when rebuilding from
touching Command/Unused.hs. With cabal, it's 29 seconds.
|
| |
|
|
| |
repository.
|
| |
|
|
|
|
| |
This is so gratutious and pointless. It's a shame that everything we
learned about Unix portability and the importance of standards has been
thrown out the window by these guys.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Wrote a better git remote name sanitizer. Git blows up on lots of weird
stuff, especially if it starts the remote name, but I managed to get
some common punctuation working.
|
| | |
|
| |
|
|
| |
which doesn't work with LDAP or NIS.
|
| | |
|
| |
|
|
| |
Yay, monadic Either!
|
| | |
|
| |
|
|
|
|
| |
This was needed for the OSX self-contained app, but is a generally good
idea. It avoids needing perl; is probably faster; and could eventually
be replaced by something faster yet.
|
| |
|
|
|
|
|
|
|
|
|
| |
Now other repositories can configure special remotes, and when their
configuration has propigated out, they'll appear in the webapp's list of
repositories, with a link to enable them.
Added support for enabling rsync special remotes, and directory special
remotes that are on removable drives. However, encrypted directory special
remotes are not supported yet. The removable drive configuator doesn't
support them yet anyway.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Finally.
Last bug fixes here: Send PairResp with same UUID in the PairReq.
Fix off-by-one in code that filters out our own pairing messages.
Also reworked the pairing alerts, which are still slightly buggy.
|
| |
|
|
|
| |
Including rollback of adding the key when a pairing response
gets canceled by the user.
|
| | |
|
| | |
|
| | |
|
|
|
I'd rather Utility.Ssh, but the SshData type is not sufficiently clean and
generic for Utility.
|
Joey Hess