From 3503ea801587cdd16bbd06f5f96321f5ce3199f4 Mon Sep 17 00:00:00 2001 From: woffs Date: Wed, 29 Mar 2017 20:24:14 +0000 Subject: --- ...ote__58___every_sync_uploads_huge_manifest.mdwn | 28 ++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest.mdwn diff --git a/doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest.mdwn b/doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest.mdwn new file mode 100644 index 000000000..f136b25b3 --- /dev/null +++ b/doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest.mdwn @@ -0,0 +1,28 @@ +### Please describe the problem. + +every sync (without --content) to a gcrypt remote uploads huge amount of data (>100MB) when doing + + gcrypt: Requesting manifest signature + +It seems to upload a special git object every time, even if this object is apparently unchanged. An unencrypted, regular git remote is much faster and does not transfer such amounts of data. + +I wonder if this can be changed, because it renders that gcrypt remote almost unusable via ADSL upstream. In my case the sync duration was 36 Minutes, uploading ~250MB. + +### What steps will reproduce the problem? + +Have a (bare) gcrypt remote and a rather big (mine has 77668 keys, annexing 769GB of files) git-annex repository. Sync with the gcrypt remote. When pushing, the message "gcrypt: Requesting manifest signature" appears, and a very large amount of data is transferred to the remote, while the process chain + + git-remote-gcrypt mygcrypt ssh://mygcrypt/home/my/annex + git push --quiet -f ssh://mygcrypt/home/my/annex refs/gcrypt/gitception+:refs/heads/master + ssh mygcrypt git-receive-pack '/home/my/annex' + git pack-objects --all-progress-implied --revs --stdout --thin --delta-base-offset -q + +is running. The upload of the actual changeset starts after this, the processes look the same, transferring again a more or less big amount of data (depending on the changeset size, I guess). + +### What version of git-annex are you using? On what operating system? + +6.20170101-1 on Debian Stretch (9.0) + +### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) + +git-annex is great and revolutionized my file organization and backup structure (if they were even existing before) -- cgit v1.2.3 From 8a104e905c206164d9fa01685a632a1496cc8026 Mon Sep 17 00:00:00 2001 From: "oberix@c7a19cddb1663df0c612a979b9d13b0d67f1f69a" Date: Thu, 30 Mar 2017 10:43:19 +0000 Subject: Added a comment: autostart and foreground together doesn't seem to work --- ...ent_1_06399a293f08401032bef1b94f05547c._comment | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 doc/tips/Systemd_unit/comment_1_06399a293f08401032bef1b94f05547c._comment diff --git a/doc/tips/Systemd_unit/comment_1_06399a293f08401032bef1b94f05547c._comment b/doc/tips/Systemd_unit/comment_1_06399a293f08401032bef1b94f05547c._comment new file mode 100644 index 000000000..7af170ef1 --- /dev/null +++ b/doc/tips/Systemd_unit/comment_1_06399a293f08401032bef1b94f05547c._comment @@ -0,0 +1,25 @@ +[[!comment format=mdwn + username="oberix@c7a19cddb1663df0c612a979b9d13b0d67f1f69a" + nickname="oberix" + avatar="http://cdn.libravatar.org/avatar/e8b871f3d0bf96df9a3fc8cdca7abe09" + subject="autostart and foreground together doesn't seem to work" + date="2017-03-30T10:43:18Z" + content=""" +With systemd using `--autostart --foreground` either ignore foreground or quit immediatelly. + +I managed to have the process stay alive with `RemainAfterExit=on`: + + [Service] + User=%i + ExecStart=/usr/bin/git-annex assistant --autostart --foreground + ExecStop=/usr/bin/git-annex assistant --autostop + RemainAfterExit=on + Restart=on-failure + RestartSec=5 + +but git-annex processes does not maintain the `--foreground` option which is causing a lot of zombies in the long period (not totally clear why). + +My current solution is to have a service for each annex repository and avoid `--autosart` but this is annoying because it require to pass the path as `%I` and wrap git-annex in bash script to get the repo owner as the user. + + +"""]] -- cgit v1.2.3 From da97139d970e6fba38212272e1a30a6724d44b09 Mon Sep 17 00:00:00 2001 From: anarcat Date: Thu, 30 Mar 2017 14:49:13 +0000 Subject: Added a comment: onion-grater --- .../comment_3_9fc514cf5273dd4a29dfb3ab81346425._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/tips/peer_to_peer_network_with_tor/comment_3_9fc514cf5273dd4a29dfb3ab81346425._comment diff --git a/doc/tips/peer_to_peer_network_with_tor/comment_3_9fc514cf5273dd4a29dfb3ab81346425._comment b/doc/tips/peer_to_peer_network_with_tor/comment_3_9fc514cf5273dd4a29dfb3ab81346425._comment new file mode 100644 index 000000000..583495994 --- /dev/null +++ b/doc/tips/peer_to_peer_network_with_tor/comment_3_9fc514cf5273dd4a29dfb3ab81346425._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="anarcat" + avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7" + subject="onion-grater" + date="2017-03-30T14:49:12Z" + content=""" +you may want to consider using [onion-grater][] to limit possible escalations in the use of that control port: + + [onion-grater]: https://github.com/Whonix/onion-grater + +RFP: [[!debbug 859125]] +"""]] -- cgit v1.2.3