diff options
10 files changed, 181 insertions, 0 deletions
diff --git a/doc/bugs/Cabal_cannot_solve_dependencies/comment_1_1d41ac79867226dcb71f1c7b38da062d._comment b/doc/bugs/Cabal_cannot_solve_dependencies/comment_1_1d41ac79867226dcb71f1c7b38da062d._comment new file mode 100644 index 000000000..91bcbe42f --- /dev/null +++ b/doc/bugs/Cabal_cannot_solve_dependencies/comment_1_1d41ac79867226dcb71f1c7b38da062d._comment @@ -0,0 +1,21 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 1" + date="2013-05-24T14:21:03Z" + content=""" +Since I tested this release in a clean system, I suspect you have a ~/.ghc and ~/.cabal with something installed that is causing this dependency problem for you. + +<pre> +# rm -rf .ghc .cabal +# cabal update +Config file path source is default config file. +Config file /root/.cabal/config not found. +Writing default configuration to /root/.cabal/config +Downloading the latest package list from hackage.haskell.org +# cabal install git-annex +Resolving dependencies... +Downloading HUnit-1.2.5.2... +Configuring HUnit-1.2.5.2... +</pre> +"""]] diff --git a/doc/bugs/Cabal_cannot_solve_dependencies/comment_2_50e72633a4462f6f6eb33d57b137fdcc._comment b/doc/bugs/Cabal_cannot_solve_dependencies/comment_2_50e72633a4462f6f6eb33d57b137fdcc._comment new file mode 100644 index 000000000..78faa6732 --- /dev/null +++ b/doc/bugs/Cabal_cannot_solve_dependencies/comment_2_50e72633a4462f6f6eb33d57b137fdcc._comment @@ -0,0 +1,48 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmu416zAYgYzbXVZAe30MiXoOWO4z6nGX8" + nickname="Johannes" + subject="comment 2" + date="2013-05-24T14:59:54Z" + content=""" +Thanks for the quick comment. I was already trying to build this on a clean cabal system. + +However, as of 4.20130521.2, I now get this: + +[[!format sh \"\"\" +Resolving dependencies... +cabal: Could not resolve dependencies: +trying: git-annex-4.20130521.2 +trying: git-annex-4.20130521.2:+webapp +rejecting: yesod-1.2.0.1, 1.2.0 (conflict: git-annex-4.20130521.2:webapp => +yesod(<1.2)) +trying: yesod-1.1.9.3 +trying: http-conduit-1.9.3 +trying: certificate-1.3.7 +rejecting: crypto-pubkey-types-0.4.0 (conflict: certificate => +crypto-pubkey-types>=0.3 && <0.4) +trying: crypto-pubkey-types-0.3.2 +trying: tls-extra-0.6.3 +rejecting: crypto-pubkey-0.1.4 (conflict: crypto-pubkey-types==0.3.2, +crypto-pubkey => crypto-pubkey-types>=0.4 && <0.5) +rejecting: crypto-pubkey-0.1.3, 0.1.2, 0.1.1, 0.1.0 (conflict: tls-extra => +crypto-pubkey>=0.1.4) +\"\"\"]] + +Also tried adding a --constraint='tls-extra<0.6.3' with the following result: +[[!format sh \"\"\" +Resolving dependencies... +cabal: Could not resolve dependencies: +trying: git-annex-4.20130521.2 +trying: git-annex-4.20130521.2:+webapp +trying: git-annex-4.20130521.2:+dns +trying: dns-0.3.6 +trying: binary-0.7.1.0/installed-caa... +rejecting: yesod-1.2.0.1, 1.2.0 (conflict: git-annex-4.20130521.2:webapp => +yesod(<1.2)) +trying: yesod-1.1.9.3 +trying: ghc-7.6.3/installed-875... +rejecting: bin-package-db-0.0.0.0/installed-608... (conflict: +binary==0.7.1.0/installed-caa..., bin-package-db => +binary==0.5.1.1/installed-72e...) +\"\"\"]] +"""]] diff --git a/doc/bugs/Cabal_cannot_solve_dependencies/comment_3_886f2d1f7c47a3973b8dc7d7c412289a._comment b/doc/bugs/Cabal_cannot_solve_dependencies/comment_3_886f2d1f7c47a3973b8dc7d7c412289a._comment new file mode 100644 index 000000000..a91a95953 --- /dev/null +++ b/doc/bugs/Cabal_cannot_solve_dependencies/comment_3_886f2d1f7c47a3973b8dc7d7c412289a._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 3" + date="2013-05-24T15:05:13Z" + content=""" +bin-package-db is shipped with ghc, so this may be down to your version of ghc. FWIW, I have tested .2 on OSX with ghc 7.4.2 & it works. + +(I can only support users cabal hell problems so far. Cabal is, unfortunately, basically buggy, and this is a large part of why I provide autobuilds.) +"""]] diff --git a/doc/bugs/git-annex:___60__socket:_16__62__:_hPutBuf:_resource_vanished___40__Broken_pipe__41__/comment_1_e962317a939bf76097ae1a3b53b146e6._comment b/doc/bugs/git-annex:___60__socket:_16__62__:_hPutBuf:_resource_vanished___40__Broken_pipe__41__/comment_1_e962317a939bf76097ae1a3b53b146e6._comment new file mode 100644 index 000000000..3300f17b9 --- /dev/null +++ b/doc/bugs/git-annex:___60__socket:_16__62__:_hPutBuf:_resource_vanished___40__Broken_pipe__41__/comment_1_e962317a939bf76097ae1a3b53b146e6._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 1" + date="2013-05-24T15:50:45Z" + content=""" +I have seen this once on a similar system (family computer; XMPP being used). Unfortunatly it could be coming from anywhere -- and it's not at all clear how a crash in one thread could take it all down, since there are global top-level per-thread exception handlers that should run and log which thread crashed -- and normally seem to do this quite well. + +I may need to make a management process that ensures the assistant stays alive. + +I have also seen this happen when a computer is shutting down. But presumably in that case it's not really a bug. + +One thing you might try is see what is using socket 16 when it's running, assuming the socket will be the same. (Also, if you've had repeated crashes, it would be good to know if it's 16 each time..). You could do this by looking at `/proc/$pid/fd/16` Also, check the old logs, `.git/annex/daemon.log.*` +"""]] diff --git a/doc/forum/Securing_a_shared_ssh_server/comment_1_ea971b57d94db5b8d487f728faa5e9a8._comment b/doc/forum/Securing_a_shared_ssh_server/comment_1_ea971b57d94db5b8d487f728faa5e9a8._comment new file mode 100644 index 000000000..f82a57295 --- /dev/null +++ b/doc/forum/Securing_a_shared_ssh_server/comment_1_ea971b57d94db5b8d487f728faa5e9a8._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 1" + date="2013-05-24T15:35:16Z" + content=""" +The git-annex assistant automatically sets up a ssh key that is locked down this way when you select \"ssh server\" in the webapp. + +The command you need to allow to run is git-annex-shell. This has been designed to be secure. +"""]] diff --git a/doc/forum/Securing_a_shared_ssh_server/comment_2_421a19f6e1fb40db6ee205daf8e3f867._comment b/doc/forum/Securing_a_shared_ssh_server/comment_2_421a19f6e1fb40db6ee205daf8e3f867._comment new file mode 100644 index 000000000..3d92c8b27 --- /dev/null +++ b/doc/forum/Securing_a_shared_ssh_server/comment_2_421a19f6e1fb40db6ee205daf8e3f867._comment @@ -0,0 +1,15 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkwjBDXkP9HAQKhjTgThGOxUa1B99y_WRA" + nickname="Franck" + subject="comment 2" + date="2013-05-24T15:47:36Z" + content=""" +Thanks for your quick answer! But this is true only for servers where git-annex is installed. On a server that just does SSH, things must be different. So, I've started to use the SSH `command=` mechanism to log the commands and discovered so far four of them: + + * `sh -c 'echo git-annex-probe...` and `sh -c 'mkdir -p ...` when the server is first connected by a client + * `rsync --server -vre.iLsf --partial-dir .rsync-partial . DIR/` and `rsync --server --sender -e31.14 --inplace . DIR//bd1/469/TEXT` when files are transfered between clients + +I want to derive patterns from this but if you could give them to me (ie, tell me which parts are fixed and which are variable) this will be safer. Moreover, I'm quite sure there are somme commands missing from my logs... By the way, parameter `-e31.14` to `rsync` surprises me because `-e` is supposed to set the remote shell (like `--rsh`). + +Cheers, Franck +"""]] diff --git a/doc/special_remotes/S3/comment_12_59c3ecab7dbc8be53258460473cac21c._comment b/doc/special_remotes/S3/comment_12_59c3ecab7dbc8be53258460473cac21c._comment new file mode 100644 index 000000000..47b0aaefa --- /dev/null +++ b/doc/special_remotes/S3/comment_12_59c3ecab7dbc8be53258460473cac21c._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 12" + date="2013-05-24T15:33:12Z" + content=""" +Ah -- No, your AWS creds are not stored. While some other special remotes, like webdav, can store all necessary credentials, it's not done for AWS. I didn't want git-annex to be responsible for someone accidentially publishing their AWS creds to their friends, since that could cost them a lot of money. +"""]] diff --git a/doc/special_remotes/S3/comment_13_0789a21d980825188bb09f7fc8bba8be._comment b/doc/special_remotes/S3/comment_13_0789a21d980825188bb09f7fc8bba8be._comment new file mode 100644 index 000000000..c8e84021b --- /dev/null +++ b/doc/special_remotes/S3/comment_13_0789a21d980825188bb09f7fc8bba8be._comment @@ -0,0 +1,33 @@ +[[!comment format=mdwn + username="basak" + ip="2001:8b0:1c8::2" + subject="comment 13" + date="2013-05-24T15:47:14Z" + content=""" +That's not what the documentation here says! It even warns me: \"Think carefully about who can access your repository before using embedcreds without gpg encryption.\" + +My use case: + +Occasional use of EC2, and a desire to store some persistent stuff in S3, since the dataset is large and I have limited bandwidth. I want to destroy the EC2 instance when I'm not using it, leaving the data in S3 for later. + +If I use git-annex to manage the S3 store, then I get the ability to clone the repository and destroy the instance. Later, I can start a new instance, push the repo back up, and would like to be able to then pull the data back out of S3 again. + +I'd really like the login credentials to persist in the repository (as the documentation here says it should). Even if I have to add a --yes-i-know-my-s3-credentials-will-end-up-available-to-anyone-who-can-see-my-git-repo flag. This is because I use some of my git repos to store private data, too. + +If I use an Amazon IAM policy as follows, I can generate a set of credentials that are limited to access to a particular prefix of a specific S3 bucket only - effectively creating a sandboxed area just for git-annex: + + { + \"Statement\": [{\"Sid\": \"Stmt1368780615583\", + \"Action\": [\"s3:GetObject\", \"s3:PutObject\", \"s3:DeleteObject\"], + \"Effect\": \"Allow\", + \"Resource\": [\"arn:aws:s3:::bucketname/prefix/*\"]} + ], + \"Statement\": [{\"Sid\": \"Stmt1368781573129\", + \"Action\": [\"s3:GetBucketLocation\"], + \"Effect\": \"Allow\", + \"Resource\": [\"arn:aws:s3:::bucketname\"]} + ] + } + +Doing this means that I have a different set of credentials for every annex, so it would be really useful to be able have these stored and managed within the repository itself. Each set is limited to what the annex stores, so there is no bigger compromise I have to worry about apart from the compromise of the data that the annex itself manages. +"""]] diff --git a/doc/special_remotes/S3/comment_14_29574a51d5831c51e2e765eb2c06e567._comment b/doc/special_remotes/S3/comment_14_29574a51d5831c51e2e765eb2c06e567._comment new file mode 100644 index 000000000..2285e9062 --- /dev/null +++ b/doc/special_remotes/S3/comment_14_29574a51d5831c51e2e765eb2c06e567._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 14" + date="2013-05-24T16:45:25Z" + content=""" +I apologise for incorrect information. I was thinking about defaults when using the webapp. + +I have verified that embedcreds=yes stores the AWS creds, always. + + +"""]] diff --git a/doc/todo/Build_for_Synology_DSM/comment_1_4059016fa8da6af7a3eba8966821e8eb._comment b/doc/todo/Build_for_Synology_DSM/comment_1_4059016fa8da6af7a3eba8966821e8eb._comment new file mode 100644 index 000000000..074ba998c --- /dev/null +++ b/doc/todo/Build_for_Synology_DSM/comment_1_4059016fa8da6af7a3eba8966821e8eb._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 1" + date="2013-05-24T15:55:42Z" + content=""" +There are already git-annex builds for arm available from eg, Debian. There's a good chance that, assuming you match up the arm variant (armel, armhf, etc) and that the NAS uses glibc and does not have too old a version, that the binary could just be copied in, possibly with some other libraries, and work. This is what's done for the existing Linux standalone builds. + +So, I look at this bug report as \"please add a standalone build for arm\", not as a request to support a specific NAS which I don't have ;) +"""]] |