Scheduled service maintenance on November 22
On Friday, November 22, 2024, between 06:00 CET and 18:00 CET, GIN services will undergo planned maintenance. Extended service interruptions should be expected. We will try to keep downtimes to a minimum, but recommend that users avoid critical tasks, large data uploads, or DOI requests during this time.
We apologize for any inconvenience.
This is probably more of a clarification on how to use git-annex directly. If I manually add a file under a gin repository using git-annex, i.e.
I was unable to automatically sync it using
After some digging, it seems that the ssh-keys that gin manages under the hood are not forwarded to the underlying git-annex call. Only after explicitly adding new keys using ssh-keygen and then adding those to my ssh-agent did I manage to upload the files.
I should note that this is using a private G-node instance running in Docker on my local computer (purely for testing purposes).
gin upload
will (or should) use the ssh keys that were generated when you rangin login
for your particular server. If you look at the log file, do you see if it's trying to use the key or not?Yes, it looks like it's trying to use the appropriate key. Here are the relevant lines from the log
If I manually add the
diskstationback.key
key to the ssh agent, I can upload the file using git annex.I have an idea of what might be wrong:
It's setting two keys in the ssh command,
diskstationback.key
andlocalserver.key
. This should work fine in most cases but it will fail if both keys are configured on the same server but for different users. In that case, it will depend on which key is used first and if that user who owns the key has permission to write to the repository.Are those two keys for the same server?
This is really an oversight in the gin client. It should only be using the key for the specific server and user.
Hm, they are actually for two different servers. Is it possible that specifying two different keys confuses ssh somehow?
Possibly. We can debug the thing by replicating what gin-cli does:
GIT_SSH_COMMAND=ssh ...
like seen in the log, but also add-vvv
, soexport GIT_SSH_COMMAND="ssh -i /Users/roger/Library/Application\ Support/g-node/gin/diskstationback.key -i /Users/roger/Library/Application\ Support/g-node/gin/localserver.key -o IdentitiesOnly=yes"
git annex copy --json-progress --to=origin .
The verbose output will show which key it tried and why it failed. You can then remove the wrong key from the
GIT_SSH_COMMAND
and try again to see if it works.Hm, this is weird. According to the output, it is not even trying to use the key I specify in the -i argument. I think that suggests there is something wrong with my ssh config somehow. I'll have to do some investigations.